AltME groups: search

hehe.  if you look at the demo files, you will see how to specify 
a polygon primitive... its dead simple... a list of vertex... and 
a list of faces (which are indices to the vertices)

Robert: you have two primitives send & recv. Both _block_ per default: 
send until there it manages to enqueue the message in an internal 
buffer, recv until it fully read a message. You call both functions 
with a NOBLOCK flag, in which case they won't block but return immediately, 
with an EAGAIN status code in case they did not manage to write/read 
anything. Finally, you also have a poll primitive, to which you pass 
a list of sockets you are interested in and an (optional) timeout. 
Poll returns you a list of sockets which are "active", i.e. which 
can be safely read from (or written to) without blocking.

Kaj - I think  that you are not accurate, and that you even know 
it?. Codecs are useless, and even Carl later introduced the plan,of 
how to reimplement them. But devices? There is list of devices out 
there, no? http://www.rebol.net/wiki/DevicesThe other fact is, that 
those are not usable via extensions, but it does not mean the abstraction 
is not there?

you know.. managing a single dimension array is quite complex for 
programmers coming out of school nowadays.   


where is the iterator class for "update facebook users list" in jquery, 
 .net,  or java?    ;-)

http://www.fm.tul.cz/~ladislav/rebol/nistclock.r

updated, changes: - server list updated

GLASS RELEASE 002
---------------------------

released last week, but posting it here to make it easier to find, 
since the GLASS group has a lot of discussion in it....

http://www.pointillistic.com/open-REBOL/moa/files/glass-r002.zip


-adds the editor style, which is now able to show text and scroll 
in real-time, but still has no keyboard handling yet.
-adds a few new more advanced tutorials

-adds a new demo app which is the basis for a full text-editor in 
REBOL (you can use the load button which allows you to load text 
within the editor, it loads files almost instantaneously... I was 
surprised how quickly it loaded even 1MB files), file size doesn't 
change editor refresh speed..

very extensive history of changes, 
very extensive TO DO list

some improvements to libs here and there.

New RMA release of R3GUI is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release change notes:

- show-native recursive issue fixed
- enhancements to TEXT-LIST, TEXT-TABLE, TAB-BOX styles
- fixed DO reactor call
- fixed reactor actions handling
- optimized INIT-PANEL function
- added FOREACH-FACE function
- fixed internals of triggers subsystem
- optimized DRAW blocks handling
- optimized DO-STYLE and DO-TRIGGERS code
- added triggers handling to set/insert-panel-content
- lists.r3 code cleanup
- cleanup of unused/leaked variables

r3-gui demo updated. Present version : 0.5.0. New validated tests 
: drawing, clock, scroller, windows, text-list (simple system browser)

New RMA release of R3GUI version 3015 is available on:


http://www.rm-asset.com/code/downloads/files/r3-gui-src.zip- this 
is the full source version + docs


http://www.rm-asset.com/code/downloads/files/r3-gui.r3.zip- this 
is the 'classic' one file release

or just simply type LOAD-GUI in the RMA version of R3.exe


Feel free to try it and let us know in the R3GUI Altme group. Any 
feedback is appreciated.


NOTE: this version is compatible only with the RMA version of Rebol3. 
You can get it from: http://www.rm-asset.com/code/downloads/files/rma-r3-build.zip

Release notes(just the main changes):

-removed reactors
-udpated documentation
-reworked text-list, text-table styles
-new testing tool + basic tests included 
-improved keyboard handling
-many internal and style related fixes and improvements


for more details see r3-gui-changes.txt in the zip archive (the changelog 
will be updated on the RMA webpages soon as well)

Hi all, I updated

    http://www.fm.tul.cz/~ladislav/rebol/nistclock.r

Changes:

- server list updated

- "stronger" checks used to suppress some errors when invalid data 
are obtained

BrianH: I will not argue, I just don't know ... we need Henrik to 
post conscise list - he has it somewhere. If GUI would be useable, 
Henrik would not stop his work :-)

here is another version (more abstracted):

win: make gob! [
	size: 300x300
    draw: [
        fill-pen blue
        box 5x5 90x90
    ]
]

init-view-system

view/options win [
	title: "test"
	offset: 'center
	handler: [
		name: 'my-handler
		priority: 100
		handler: func [event] [
			if event/type = 'close [

    unhandle-events self ; Remove this handler from the global list.
				unview event/window
				quit
			]
			none
		]
	]
]

Is there a list somewhere?

graham, if you have an account to the r3-gui world, there is a list 
in there

But... the list is likely to change. I hope some of my ideas will 
be added.

there's only a single column list available at this time.

Does the text-list use a fixed font style?

so a text-list is now called a "style" ?

you can, if you can find where the font specification is used in 
the list, but you want to create a new style that uses that font.

http://www.mail-archive.com/[fedora-fonts-list-:-redhat-:-com]/msg00879.html

Did it expire?

Weighting happens by "pushing" other elements aside, like soap bubbles 
pushing against eachother. The bigger the element is, the more it 
pushes. But space is also divided between the number of elements 
available in a given group, so a group of 5 buttons takes a little 
more space than a group of 3 buttons.


That gives the problem you see with strange spacing before and after 
the vertical scroller, because it's size is not big enough to provide 
push. and the other elements are too small to provide enough push. 
Combining the size of the face and the push factor is why resizing 
is broken.

But there are more bugs in it than that. If you push too much, the 
elements overflow and will be clipped by the right and bottom edges. 
Furthermore, the calculation of space to the right edge and bottom 
edge is also broken. It's almost impossible to predict in your head 
how the layout will look.


I'd like to replace the resize engine with something more concrete, 
perhaps with springs instead and fixed pixel sizes (oh, maybe similarly 
to what the VID Extension Kit does) or depending on whether Carl 
get's started again with his specs list (which I unfortunately can't 
locate). I hope we'll get to start this month.

I could use text-list instead of table if that can be used with a 
monospaced font.

It looks I can use a monospaced font in a text list by changing the 
text-list-box face/text-style to 'code instead of 'list-item ... 
but quite unclear to me how one does this easily

Is there an easier way to do this than this?

    code-text-list: tight [

        about: "List of selectable text lines with scrollbar using a monospaced 
        font."
        facets: [
            max-size: 150x3000
        ]
        options: [
            list-data: [block!]
        ]
        content: [

            text-list-box :list-data :area-color options [ text-style: 'code 
            ]
            scroller
        ]
        actors: [
            on-init: [
                if select face 'reactors [
                    extend face/faces/1 'reactors face/reactors
                ]
            ]
            on-set: [
                set-face/list face/faces/1 arg
            ]
            on-get: [
                get-face face/faces/1
            ]
        ]
    ]

so, above it would be 

parameters: [
	list-data: [block!]
]

so that you know that text-list takes a block

or we could use 

text-list settings [ ... ]
insread of options

Answering my own question above .. this is shorter

code-text-list: text-list [
        content: [

            text-list-box :list-data :area-color options [ text-style: 'code 
            ]
            scroller
        ]
]

Graham, the word list is from the prototype, so "Not documented" 
would be accurate.

view/no-wait [ text-list []]
crashe if you try and use the mouse to close the window down

>> w: view [ tl: text-list []]
handler added

== make gob! [offset: 569x340 size: 142x120 alpha: 0 text: "REBOL: 
untitle

>> value? 'tl
== false

so how do you access the faces ?

http://rebol.net/wiki/R3_GUI_Specs

This is not the list Carl made.

Henrik - who made that list, and how old is that?

Henrik... great list ... not sure that the problem with field tabbing 
is in it or not.  In R2 tabbing went to hidden fields which made 
them visible.

I'm starting to think that keeping a set of rules to parse for tags, 
may not be a great idea after all:

- Each rule is largely used only once.

- The rule list is quite short and there are not that many places 
to use rules.
- Building the parser is complex.

- The rule would have to be parsed on each invocation of a function 
which takes longer than simply searching for a tag. This would have 
to be done potentially hundreds or thousands of times on opening 
a single window and just consumes more memory.

- Setting and unsetting tags by using the rules as part of a state 
machine just leaves a new need for further processing the result 
where you use it, and perhaps slows it even more down, because you 
need a state machine engine to drive it.


The list of rules is good as a design guideline as I've used it for 
the VID Extension Kit, but no further than that. Tags are of course 
still needed.


I think I'll reduce today's prototype not to include rules, but simply 
manage tags directly.

I posted Carl a list of main topics. IMO the goal is to sort our 
what Carl really can do only by himself. All the rest can be done 
by a group of people. The main effort will be to get the design right. 
If this is done, the rest is "only"  implementation

What I've noticed about Carl's styles is that he tries to do as much 
of that intra-face communication inside the styles.


That is simple to do at first, but doesn't scale very well, because 
we will have a lot of different styles.


Still, some parts could be inherent to the face or style, in that 
the face or style holds a list of actions to perform and then some 
type of evaluator (I've never built these things, so I don't know 
what to call it). There is DO-STYLE, but a formalization of how to 
store the actions inside the face is needed, both when specifying 
face attachments in the layout and when accessing the face attachments 
using a general access function like DO-STYLE or DO-FACE.


The formalization is needed to allow a scalable number of actions 
or attachments stored in each face. This could simply be a block 
of blocks or functions that are bound to both source and target face. 
In order to trigger the action, just DO the block or function and 
the magic unfolds.

but within REBOL, so you can create a bspline by adding some some 
sort of object in a list of visible graphic elements which have properties.

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

Btw i think the throwing of time events can be optimized by modifying, 
the system handler:

>> ? :system/ports/system/awake
make function! [[
    sport "System port (State block holds events)"
    ports "Port list (Copy of block passed to WAIT)"
    /local event port waked
][
    waked: sport/data
    loop 8 [
        if not event: take sport/state [break]
        port: event/port
        if wake-up port event [
            if not find waked port [append waked port]
        ]
    ]
    if not block? ports [return none]
    forall ports [
        if find waked first ports [return true]
    ]
    false

the second categories countains the set of high level widget wich 
include a lot of time of  developement and though about how to give 
them flexibilities and extensibilities  not to end with a list-view 
widget that is able to display nothing but text like in R2.  Those 
widgets and widget set should be able to evolve in time and ofcourse 
without impling a redistribution of the complete R3 view stuff.exe

Screenshots will be available when there is something to show. Worked 
out a few bugs regarding tab navigation yesterday and there is work 
being done on the basis for a grid system that will be used for tables, 
dropdowns, menus, etc. Someone has been added to the list of developers, 
as I don't have much time right now to do GUI work. He may speak 
up if he wants to. :-)

That someone is me and in this exact minute I just finished auto-completition 
for the text-list. Yea! :)

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

a good list here:

http://trac.webkit.org/wiki/Applicationsusing WebKit

each reactor is converted to a function, where the first argument 
is the face and the remaining arguments are as shown in the argument 
list above

for cross-linking GUI elements, it might be sufficient, but for overall 
app logic? There would have to be list of possible update actions 
for each element possible change. The system I used in DOS ere had 
it exactly like that. And it worked even with grid for e.g. You deleted 
an item, and the update action was able to update your stock DB item 
related amount. The mechanism would have to be universal enough, 
because if it will not cover enough cases, it will not be used by 
developers, and will bloat the GUI code, as everybody will replace 
it with own version ..

 There would have to be list of possible update actions for each element 
 possible change.
 Could you give an example? Thanks.

It just looked different to what I've seen before posted to the OCR 
mailing list I subscribe to.

font quality code - that will have to be done one day, as the View 
app font quality is really not nice. So let's hope that one day it 
will move up in the priority list :-)

Yes, effects are next on the list. Hope I'll get to them during today.

i can make a basic list of gobs i want 
treeview
menu bar
tab panel
menu popup

list  (for text images other gobs ?.... with resizable columns auto 
sort etc...)
checkbox /groups

radio button/ groups  ( in a group with many radio button only 1 
radio button can be activated at a time that's the difference with 
a checkbox group)
status bar
tools bar 
splitter bar (to separate elements and dynanmically resize time)

being able to have docking system  being able of having subwindows 
in the main windows then you can arrange the child windows easyly 
(one on top full, cascade, tiles etc...)


the graphical style should be pure enough to have an attractive look 
and a one eye shot notice and recognize style without looking kidish 
or like in 1979 first intent of  graphical interface made by Xeros 
labs in palo alto ....

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

As for business apps - that sounds fine, it is just that we did not 
see e.g. list of styles, you might need. Is there e.g. a tree-view? 
Tabs? Table is there IIRC (there is a screenshot on henrik's site)

when is validation triggered? In DOS app generator I mentioned, there 
was such a functionality, that you could limit values to type - it 
was called 'vtg - variable-to-get, and it was used e.g. when you 
wanted to limit selection to floppy drive A, B values, etc. :-) Nowadays 
we have list-boxes, but I still can imagine special kind of fields, 
e.g. Date, IP field with various masks, allowing to type only numbers 
for e.g. But that would require validation being triggered on per-press 
basis ... just thinking out loudly ....

Pekr, the basic usage is this: set-material face material. Where 
material is name from list of predefined materials. Of course you 
can add your own materials.

btw - is there some easy way to list the widgets/styles available?

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

Is there some easy way of of hot obtain list of available styles? 
Are styles somehow divided upon internal (thsoe are more of classes 
you use to construct other styles) and user useable styles?

is there anything like 'flags item in new VID? I find tagging very 
usefull technique. That way you could simply add a tag, e.g. 'internal, 
and such style would not appear int he list of styles for something 
like get-styles function. Simply put - only styles/widgets which 
are able to function on their own, would be shown ...

there definitely have to be accessors like get-styles (get-style-list) 
or something like that. Playing in console and trying to display 
tabbox, container, errors out ...

OK, so there's recently no way of how to programatically cycle via 
available and displayable widgets, and put them on screen. Just remember 
my request for the tagging and obtaining the list of usefull styles/widgets 
:-)

good then. One other thing - I am seeming table related styles there, 
which surely are not displayable on their own, yet those are legitimate 
styles - table-row, table-cell, table-header ... that is why I think 
we really need get-styles or similar function, which depending upon 
the tag, would get you list of only ready-to-use on the form styles 
... but that can come later ...

Must have selected value

 in item list 1, but doesn't mark a non-selection as invalid after 
 marking a selected item as valid and deselecting it by clicking in 
 the list-view somewhere below item "3".

ChristianE, ok, bug in TEXT-LIST.

hrm... I responded and it showed up on the list, saying that my mail 
address is blocked due to spam. Did it show up?

Henrik - the style browser text-list is somehow flawed :-) I can't 
e.g. see area there - when you drag a scroller a bit, you can see, 
that the list changes, listing styles, which were not available in 
previous view :-)

Henrik - the style browser text-list is somehow flawed :-)

 The correct phrase would be: "Henrik - The style browser shows a 
 problem in the text-list style, which is a good thing, because it 
 means Rebolek can fix it. :-)"

Henrik - I said nothing. Maybe it is incorrect wording, dunno. What 
is more I even said "text-list is somehow flawed", not that style 
browser is flawed. It took me 3 min. to find a problem, so keep it 
coming ....

New R3 GUI which fixes a few styles, like text list, although text 
list will eventually be rewritten:

http://94.145.78.91/files/r3/gui/r3-gui.r3


Style browser now shows style options, alphabetic sorting of style 
names, face debug option (currently broken in the R3 GUI):

http://94.145.78.91/files/r3/gui/style-browser.r3

I am not sure I like tabs in multiple rows :-) What .e.g Mikrotik 
does is, that they add small button right after the arrows, which 
reads "...", and it displays menu (we could use listbox), showing 
list of all tabs ...

I prefer flat list that can be searched, when there are no other 
options. Old MUI preferences windows on the Amiga and the KDE configuration 
or MacOSX settings program comes to mind.

The modern version of the system dialog does a list on the left instead 
of tabs. It might look like a column of links in a left-side navbar, 
but it is basically the replacement for the tabs.

There is now Carl's blog upon how to easily list styles in R2. I 
posted corresponding R3 code, although it might be preliminary:

foreach [name obj] guie/styles [print [name "-" obj/about]]

But - I would like the GUI team to think about following aspects:


Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed. OTOH those are legitimate styles, from which you might 
want to derive something, or just being able to change their aspects. 


So, I propose to resolve this situation somehow. The implementation 
is up to gurus, just few wild ideas:


- use tagging - tag style as 'main/root/parent, whatever - but - 
that introduces another field to the styles? Maybe not, because I 
expect some tagging system being available anyway?


- create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header 
table-row] - that way we will be able to list just/only widgets as 
table, not having the list poluted with widget internals


- the above aproach might not work well in the case, when you aproach 
styles more as a CSS, not as widgets. Because - even e.g. 'table-cell 
might be derived from a totally different style, e.g. a box, or field, 
so I have no idea of how to keep track of those dependencies, but 
this is the area I leave for gurus to think about. E.g. someone changes 
box style and your table is influenced and user might be confused, 
why it happened. But I expect style/parent or something like that 
being available?

Tags can be used, they are implemented.But, IMO, if you need a list 
of styles for a GUI builder, you better make a list manually.

> Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed.


We already have and use tagging. The styles you mention should be 
tagged INTERNAL, if they are not already, as they are part of compound 
styles. So it's up to an IDE to discern that properly 


It might be possible to make a helper function that filters in only 
end-user styles, but we'll see how important that becomes.

Rebolek - making list of styles manually is not imo acceptable. It 
should be auto-inspectable.

Current list of tags (subject to change):

; set at stylize time
style-tags: [
	internal		; the style is intended for internal use
	panel			; the style is panel of other faces
	compound		; the style is a compound of part styles
	field			; the style is a field with editable text
	state			; the style is a user interactive state changing item
	action			; the style is a user interactive action item
	info			; the style is an indicator
	tab			; the style is part of tab navigtion

 auto-tab		; the style automatically tabs away on a specific event
	select			; the style contains user selectable text

 keep			; the style retains highlighting and caret after unfocusing
]

; set at layout and any other time
face-tags: [
	default			; the face is the window default
	focus			; the face is in focus
	disabled		; the face is disabled
	frozen			; the face is frozen
	dirty			; the face is dirty
]

; set at window creation time
window-tags: [

 form			; windows containing a validatable form or other field or 
 state faces

 inform			; windows containing only text or images and no validatable 
 faces

 popup			; windows containing a menu or selection, which when interacted 
 with, results in immediate return of a value
]

ad 1) I can understand that, and that was also one of my worries 
in my initial post. However, as a designer/programmer, wouldn't you 
find usefull to have:


- something like tree-view (or node based visual display) of styles 
and their dependencies?


- wouldn't it help your orientation to have some list like guie/widgets, 
grouping particular styles, just for your info? So that you know 
that e.g. table is being built using xyz styles?

I am just asking - so no offense please :-)

Tags are really trivial. They are just a list of words and we have 
a few TAG functions to set/unset/inspect them during runtime. It's 
entirely up to styles or the higher level code to use tags correctly 
and this is for example done with face navigation.

I'll post a small list...

To have event transparent gobs is on my wish list for a very long 
time already.

mouse wheel scrolling works only upon the scroller of list. It should 
imo work even when upon the list itself ....

mouse wheel scrolling works only upon the scroller of list
 - bug, I'll fix it.

Kaj, if you have any links to fully native GUI applications for Android 
that don't use any Java or Dalvik at all, please post them. I have 
been looking for any indications that such things are possible, and 
haven't found any yet. The SDL seems to be linked as an NDK library, 
not as something used to make native apps. All of the native apps 
I've seen are command-line only and not runnable from an icon in 
the applications list. I'll keep looking.

Or write them, for that matter. I lost track of where the docs were 
in the various wiki reorganizations. Right now the definitive docs 
on the subtleties of the module system (beyond the official docs 
Carl wrote) are still in the CureCode tickets related to them, and 
their comments. I'll try to track down a list of the relevant tickets 
and post them here.

Everything specified, as of alpha 97, even the 'export keyword Carl 
requested. Compressed scripts/modules have been submitted and are 
being reviewed now.

What doesn't work:

- Selective import is possible but needs mezzanine wrappers (and 
a model for their behavior).

- Delayed init is just a dream now; Carl hasn't even elaborated on 
what he means by that.

- System modules might need a little tweaking to the model (by Carl).

- We need better checking of extensions before loading (authenticode?).

- A module-aware version of prebol is still needed (it's on my list).

Excellent, we'll put you on our stay-in-touch list

I've added a speakers list to the ReBorCon web site

Ladislav: I was going to suggest something similar as Sunanda, except 
by using [sort read %.] instead of [what-dir], then checking the 
first file with alphanumeric characters.  That way, if both upper 
and lowercase do exist separately, they'd show up in the list and 
can be adjusted for

I was going crazy trying to send to a long list getting errors...finally 
found the faulty address...how do you validate email then?

maybe we could start thinking about using a new word for what we 
are talking about extending CATCH to do... its starting to look like 
a long list of groceries for a single word.


reading Andreas' notes on 'CATCH I agree that it should only manage 
throws.  

/all  should mean catch any named or unnamed throw


/quit /unwind and other proposals should fall into another function.

To read the content of a shared folder on a machine, it's :
	read %/machinename/sharename/


But how (if its possible) can I read the list of the shared folders 
?

	read %/machine/		...does not work !!

Just for starters.....This does it with 12 XORs (three per swap).

But the tricky bit may be pre-computing the from-list and to-list 
mapping

;; function to do the swap

swap-items: func [
   data [block!]
   from-list [block!]
   to-list [block!]
   /local
    ind1
    ind2
 ][
 for n 1 length? from-list 1 [
     ind1: from-list/:n
     ind2: to-list/:n
 
     data/:ind1: xor data/:ind1 data/:ind2
     data/:ind2: xor data/:ind1 data/:ind2
     data/:ind1: xor data/:ind1 data/:ind2
     ]
     return data
    ]

;; Sample run    
     block: [4 5 6 1 2]
     probe swap-items block [1 2  1 1] [3 4 5 2]
    [1 2 4 5 6]

Oh, nice. Yes, that's worth doing, and fits within the rules. For 
that matter, it's worth adding to the R2 bug list.

Rebol []

make-obj: func [
	"Créé un objet en sauvant son nom dedans."
	'name "Nom de l'objet à créer."
	obj "Objet de base à instancier."
	spec "extension de l'objet de base."
] [

 set name make obj append reduce [to-set-word 'obj-name to-string 
 name] spec
]


save-obj: func [
	"Sauvegarde un objet selon son propre nom."
	'obj "Objet à sauvegarder."
	/local name
] [

 name: any [all [word? obj  object? get obj  get in get obj 'obj-name] 
 join "objet" random 10000]
	save/all to-file join name ".r" get obj
]

load-obj: func [

 "Recharge un objet et l'intancie selon son propre nom s'il en a un."
	file "Nom du fichier à charger."
	/local obj
] [
	if exists? file [
		obj: load file
		probe bind next first obj obj
		probe get in obj 'list
		all [in obj 'obj-name  set to-word get in obj 'obj-name obj]
	]
	obj
]

task: make object! [
  list: copy []
  add: funct [t [block!]] [
    append list t
  ]
  save: does [
    save-obj self
  ]
  run: does [
    do list
  ]  
]

make-obj task1 task []
task1/add [a: 0 a: a + 1]
task1/add [print a]
task1/run
task1/save

task1: none

load-obj %task1.r
task1/run

Using SAVE ensures that you have a list of symbols in unevaluated 
form more suitable for object reconstruction and proper binding.

it should return the time, I've got ftp synching routines which use 
info? and use date/time.   so I'd bet its a limitation on the server, 
or its using a non-standard date string in its LIST command.

Maybe around 2001, on the mailing list.