AltME groups: search

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.

Try these 
a acute ˆ
e grave Ž
c circumflex 

we could use whatever is native for particular hosts,e .g.  DirectX 
for Windows ...

I've never seen a single font which didn't have at least a single 
letter which was grossely mis-AAed.  often its the s, the o, or the 
e..... they stick out in every word and its annoying.

I.e. that i can ship linux, windows and osx extensions along with 
a simple script, and use the proper extension on the proper platform

Example: Rebol code sends [a b [c d] [e [f g]] h i] to extension. 
The extension makes a string out of this and stores it. Later the 
extension should take the string and make block out of it, so that 
the script gets a block! and can do result/1, result/b etc.

Carl, by STDIO, I just mean the basics for writing pipe-and-filter 
apps. e.g. 

  while [data: input] [print data]


I just found http://www.rebol.net/cgi-bin/r3blog.r?view=0282so maybe 
we're close and just need to write up some examples and a doc page 
explaining limitations on different OSs. Gabriele has some things 
in his power-mezz package as well (chain, filter, pipe), which are 
worth keeping in mind. The blurring of lines between in-process and 
inter-process, and piping is where we need design direction from 
above. 


A REBOL way (passing around blocks of dialected data, i.e., messages) 
vital, but we also need gateways to other mechanisms. The REBOL way 
is critical because it reduces or eimilates external dependencies 
and provides a model for gatewys to emulate.

I.e. as soon as you use any of the RXI_* functions, as almost any 
"real" extension will, you'll have to recompile against the A102 
headers

I.e. if you have an RXIARG of of a series type (RXT_BINARY, RXT_STRING, 
etc), this arg also holds the index.

(I.e. define the order in which multiple extensions are attempted 
and define which extensions are attempted on each platform.)

C90 requires compilers to support _single_ string literals (i.e. 
one quote "...") of at least 509 characters.

Then there's also a limit how big concatenated strings can get (i.e. 
"..." "..." "..."). Which is 65k in MSVC, IIRC.

I realize the GUI is still a WIP ... but is the underlying [native] 
gob! system settled? (i.e. is it likely that the details of http://www.rebol.net/wiki/GOB
will change?).

The way I see it, there are at least four ways to build an R3 GUI 
[based on gobs]:


1) Heirarchical, where gobs are grouped into faces, which are in 
turn grouped into windows

2) Flat, where a DOM-like object maps all gobs (i.e. removes the 
need for intermediate faces/windows)

3) Draw-based, where each window consists of a single gob with the 
entire window rendered in a draw block

4) Image-based, similar, but the draw block is pre-rendered into 
an image.

Any other dialect word (e.g. scroll, size, bold, color) prevents 
caret from working (i.e. if you use caret you are forced to use font 
and para objects).

Also, it seems the caret object could be simplified down to:

	caret: make object [
		caret: start: end: none
	]


Are the blocks (caret/1 start/1 end/1) supposed to have any other 
values in them? (e.g. color tuple, 2nd string!, etc)

No, not wrong attitude. Styles are built by experts, i.e. people 
separated from those that build layouts. In VID, you don't have this 
distinction as you can manipulate styles directly in the layout, 
but you do, somewhat, in RebGUI.

Next step is to store the tab-face in the window face, some key event 
handling and GOB display of a tab frame to get actual tab navigation. 
I imagine it could be nice to stow away different items in the window 
face, i.e. window related information. Suggestions?

About my DISABLED it's true that i'ts only usefull at the construction. 
I.E When You want to construct a pannel from an existing one.

Yes, we are on the same page. I see this as built upon a messaging 
infrastructure. It doesn't need to be elaborate today, in what it 
supports, but the design should allow us to extend and build on it. 
i.e. we need a message bus that we can tap into, inside an app, interprocess, 
and distributed.

so if Liquid is perfect, what's the next step? Henrik needs to evaluate 
it? Does that mean that Maxim needs to spend time going over things 
with Henrik? Does Carl have to approve it himself - i.e. does he 
need to spend some time looking it over?

Robert and I are discussing field persistence, i.e. tieing fields 
directly to database tables in a layout. Going to be a bit about 
our conclusions in the R3 GUI specs soon.

recycle/ballast 50000
screen: system/view/screen-gob
system/view/event-port: open event://
font1: make system/standard/font [size: 20]
fire: [
	line-width 0.5 pen black fill-pen white line-pattern white 
	text vectorial 0x70 [font font1 bold "F I R E !!!"]
]

insert strokes: skip find fire 'line-pattern 2 rand: [0 0 1 1 2 3 
3 4 4 5]
img: make image! xy: 100x100

show append screen gob: make gob! [offset: xy size: xy image: img]

forever [
	change img copy/part skip img 0x1 100x76
	change strokes random rand
	draw img fire
	effect img [blur difference 2.5.10]
	wait 0.03
	show gob
]

recycle/ballast 50000
screen: system/view/screen-gob
system/view/event-port: open event://
font1: make system/standard/font [size: 20]
insert strokes: skip fire: [
	image img (first random [1x-2 0x-2 1x-2 0x-2 -1x-2])
	line-width 0.5 pen red fill-pen white line-pattern black 
	text vectorial 0x40 [font font1 bold "F I R E !!!"]
] 'line-pattern 2 rand: [0 1 1 1 2 5 ]
img: make image! xy: 100x70

show append screen gob: make gob! [offset: xy size: xy image: img]
forever [
	change strokes random rand
	draw img fire
	effect img [difference 3.5.8 blur img]
	wait 0.05 show gob
]

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

Maybe Lotus notes is looking good now, Maybe.... 

But I had so many bad experiences with that crappy app, in the past.
No respect of the GUI santards. (F5 to quit).
No drag and drop.
Lof of useless confirmation boxes.
Useful actions hidden in deepest menus I ever seen.
etc...
It was a pain in the ass just to write a simple e-mail.

as it is now, the dialog system "forces" some specific routes. the 
intent is that dialogs must allow dozens of different standard dialog 
layouts and standard buttons. combined, forms in layouts would automatically 
be validated and the dialog would behave appropriately, i.e. not 
closing if the form and provide warnings is invalid. this works now 
in the prototype, and the end user won't have to do anything to use 
it in the standard dialogs.

in group the objects are organized into either rows or columns (internally 
lines all the time), i.e. XY is misleading

and by main function, the idea is that faces can be accessed on multiple 
levels, i.e. you can also just run a single reactor in the face.

I.E. 2-5 lines of code in the right spots. Of course preferrably 
with minimum performance loss.

The dialect is low level, i.e. not a mezzanine, so I guess some conversion 
work needs to be done.

Some time ago, I seem to remember some talk of masks to be used with 
styles for pixel accurate hit detection of non rectangular shapes, 
allowing for holes in styles, etc. Is this (still?) planned? If the 
framework allows for both bitmap and vector definition of styles, 
will any accompanying mask match the implementation? i.e. anywhere 
a bitmap is used, an optional bitmap mask could be used and where 
vector elements are used, a set of bezier (or other type) of curves 
would be optionally used for masking. If a particular style uses 
both bitmap and vector elements in its definition, would some data 
structure hold both types of masks?

Henrik, thanks for posting your db-reactor ideas. Is there a reason 
not to use the standard REBOL series func names for actions. i.e. 
insert/change/remove/select rather than add/update/delete/get? Another 
option would be the names from CRUD. 


What does the underscore in your _data naming convention indicate?


I need to look at your validation design again, to see how things 
work together.

This is more a dialect design problem, i.e. what will be more "intuitive" 
for the user

Aha, so you want the layout to be always related to the source, i.e. 
the second graphic object to be to the right of the first one? (assuming 
that the position below the first one as well as the position to 
the right of the first one are both available)

you have to keep the deletions active in you record

lets say the user does:

insert "a", insert "b", insert "e", backspace "e", insert "c" then 
the concataining algorythm have to merge insert "a" and insert "b" 
into insert "ab", but need to keep record of the actions insert "e", 
backspace "e", insert "c" in order to unpile it properly.

A show face user poll:


We decided to introduce a face attribute allowing to implement the 
following show states of a child face of a panel (or, eventually, 
other container):


1) the face is visible and it resizes/repositions together with its 
parent panel

2) the face is invisible, but it resizes/repositions together with 
its parent panel, reserving the appropriate amount of empty space 
for itself

3) the face is invisible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

4) the face is visible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

Possible implementations:

===A


Define a new SHOW? facet (you may indicate your preference to use 
a different attribute name, if you like), which could be set to one 
of the following four REBOL words, corresponding to the above defined 
face show states:

A.1) VISIBLE
B.2) HIDDEN
C.3) IGNORED
D.4) FIXED


(you may indicate your preference to use different words, if you 
like)

---Advantages


*The user can to determine the show state of the face by examining 
just one attribute, the SHOW? attribute.

*When using an appropriate function, the user will be able to change 
the show state of a face by evaluating a

    SHOW-FACE state

expression.

---Disadvantages


*Data are not normalized, seen from a data-related point of view 
- if a user sets the FACE/GOB/SIZE value inappropriately (e.g. if 
FACE/GOB/SIZE is 0x0, while the SHOW? attribute is set to FIXED, 
or, if the FACE/GOB/SIZE is non 0x0, while the SHOW? attribute is 
set to HIDDEN), the state he obtains will not be consistent.

*Speed - since it is necessary to test which of the four variants 
has been chosen, we need to use four tests in resizing code, i.e. 
the code becomes slower.

*More complicated code - it is necessary to take care the state is 
consistent, which may require more complicated code, maintaining 
state consistency.

*Documentation - the users need to be aware, that not all changes 
produce consistent state.

===B


Since the invisibility of faces is already implemented by setting 
the FACE/GOB/SIZE value to 0x0, we need to implement only an attribute 
telling, whether the face resizes/repositions with its parent. A 
RESIZES? attribute (you may indicate your preference to use a different 
name of this attribute) is used for the purpose in this variant, 
possible values will be TRUE and FALSE.

---Advantages


*Normalized data - all four possible state combinations are meaningful, 
and consistent.

*Speed - when needing to test whether the face needs resizing, only 
the RESIZES? attribute needs to be checked.
*Code simplicity

*Documentation - the user does not need to memorize the possible 
inconsistencies

---Disadvantages


*The user does not have the SHOW-FACE function, but, if required, 
it can be implemented easily, it can even use the keywords mentioned 
in the A variant, just translate the state to respect the B implementation.

*The user will not find the keywords in the face data, but it does 
not look like a disadvantage one should be afraid of.


So, please, indicate your preferences for the show state implementation. 
As far as I am concerned, I am strongly in favour of B, so the initial 
score of the show face poll is:

A:B = 0:1

hmm, regarding your question: the VISIBLE is OK. The initialization 
of HIDDEN is probably not, since 0x0 sets up the INIT-SIZE, which 
is needed for resizing, i.e. it should be nonzero even for HIDDEN, 
I guess

In the code, why does it need to check if the contained gobs have 
a consistent data/face/gob ?

 - because we had problems with text-faces, which contain a face-less 
 gob, i.e. a gob for which gob/data is a face, which does not have 
 face/data = gob. This caused a cycle for faceless gobs.

(i.e. can we expect some gobs to not refer to any face?)

That being the case, it is necessary for the three dimensions to 
be independent, in that it has to be allowed to set the INIT-SIZE 
outside of the range, i.e. set all three dimensions independently.

yes, you shall find out, in general, "floating" means - the resizing 
algorithm influences neither the size nor the position in any way, 
i.e. the element "floats unnoticed by the resizing algorithm"

Wrong, reasons: 

- those values clearly *are* options the user specifies

- the fact that some options may be inlined (i.e. the name may be 
used in another context) does not change that in any way

- what is "deep" about saying you don't like a name (in an arguable 
case) is beyond my understanding

- renaming to "facets" would not help anybody including Pekr as he 
surely knows

OK, and I think you are wrong too, and we can let it that way :-)


the fact that some options may be inlined (i.e. the name may be used 
in another context) does not change that in any way

 - yes, it does. So far I can only follow my brain logic, which simply 
 was confused. Well, I could admit, that I am dumb :-) But the chances 
 are, that some other ppl might be confused too, so my answer is:


- style/options does NOT clearly define, what options user can set 
in dialect options block, because that block, is SUPERSET of the 
style/options. It allows you even to define whatever word, without 
the word being a regular facet field:


>> view [b: button options [ble: func [][print "huh?"]] do [b/facets/ble]]
huh?


I wonder if that might even be a security issue, to pass such a function 
via the options block? So - how is that options block even closely 
similar to what style/options is? Those two have completly different 
meaning/functionality :-)

I may have missed the latest version, but the one in my zip has the 
same date as the one at this link. http://www.rm-asset.com/code/downloads/files/r3-gui.r3
.i.e; 9-Dec-2010/10:32:04+1:00. May I suggest to put a version nr 
to r3-gui in order to avoid any mistake ?

jocko, the fix is in view-show.r


; this is a run-once-code, i.e. it causes problems when LOAD-GUI 
is run twice
;show-native: :show

; this is a way how it can be corrected:
if command? :show [show-native: :show]

tab-box [
			"tab" [
				title "tab 1"
						text-table ["1" "2" "3"][
			["text table" "a" "10"]
			["line 2" "b" "9"]
			["line 3" "c" "8"]
			["line 4" "d" "7"]
			["line 5" "e" "6"]
			["line 6" "f" "5"]
			["line 7" "g" "4"]
			["line 8" "h" "3"]
			["line 9" "i" "2"]
			["last line" "j" "1"]
		]

(i.e. the other way than you guessed)

UPDATE-FACE/RECURSIVE
- this is a misunderstanding, as I said.


- UPDATE-FACE if always recursive, i.e. the it updates all the parents 
as well.
- UPDATE-FACE does not "recurse to children"

For example,(this is not much a documentation issue, it is a coding 
issue, in fact): There is an INSERT-PANEL-CONTENT function. The function 
is supposed to insert contents to any layout face, i.e. the name 
is inadequate, in fact, and it should preferably be renamed to INSERT-LAYOUT-CONTENT 
(or INSERT-LAYOUT-CONTENTS, respecting the results of some of the 
previous polls).

et-panel-content
clear-panel-content
insert-panel-content
append-panel-content
change-panel-content
remove-panel-content

set-content
clear-content
insert-content
append-content
change-content
remove-content


; Disadvantage of following group is, that it does not relate to 
the content, and hence we are reserving/blocking those names for 
our particular purpose.
set-in
clear-in
insert-into
append-into
change-in
remove-from

Think about them in the usage scenario,e .g.:

insert-content my-panel [content here]
insert-into my-panel [content here]

Rather it can be called a "Performace pricing" program, i.e. a program 
implementing a performance pricing methodology.

For E, these capabilities can basically be resolved statically in 
a lot of cases by the compiler. For REBOL, every capabilities check 
would need to happen at runtime.

From http://erights.org/history/original-e/programmers/Econcepts.html

I hadn't checked E for a long time, but they are now implementing 
capabilities in JavaScript for Google, so we're going to hear from 
it whether we want or not:

, i.e. I see a greater difference between direct and indirect evaluation, 
than between inline and explicit evaluation.

Then you can put your preferred behavior model (with that i.e. justification) 
in your comment, and we can get a consensus there through people 
agreeing with you. This would be the code:

>> 'a
== a
>> b: quote 'a  b
== 'a 
>> do quote 'a
== a
>> 'a/1
== a/1 
>> b: quote 'a/1  b
== 'a/1 
>> do quote 'a/1
== a/1

do-paren: [:p] [do p] - the only problem with the function is, that 
the function is so, that it can "do a paren", but only if that "paren" 
is already supplied as a value, i.e. not as an expression

I understand, what happens, that it's a position in a series, I try 
to insert earlier in the same series. I just find it a bit confusing, 
it works as it does. Woldn't it be more logical, if it's the position 
+ 1, that is inserted in such cases? I think, this looks strange:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert/only s find s 'd
== [a b c d e f g h]
>> s/1
== [c d e f g h]

It seems more logical to me, if it does this:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert/only s next find s 'd
== [a b c d e f g h]
>> s/1
== [d e f g h]

It's also interesting, that if /only isn't used, the result is what 
I first would expect:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert s find s 'd
== [a b c d e f g h]
>> s
== [d e f g h a b c d e f g h]

Geomol, refering to your example above:

>> s: [a b c d e f g h]
== [a b c d e f g h]

>> p: find s 'd
== [d e f g h]

>> insert s 42
== [a b c d e f g h]

>> p
== [c d e f g h]

I see no problem with your example. I'm surprised, you find my suggestion 
"awful". What's awful about this:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> p: find s 'd
== [d e f g h]
>> insert/only s p
== ....
>> s/1
== [d e f g h]
>> p
== [c d e f g h]

The awful property is as follows:

s: [a b c d e f g h]
t: [a b c d e f g h]
p: find s 'd
insert/only s p
insert/only t p
same? first s p ; == false !
same? first t p ; == true

Geomol, yes, the "!REBOL3 /library" group is about R2/Library-style 
access to DSOs. I.e. using pre-existing DSOs from within REBOL.


The "!REBOL3 Extensions" group is for discussion about native R3 
 extensions. I.e. writing special-purpose DSOs which can export native-like 
functions into R3.

ROUND not returning an integer broke some things too. i.e. currently 
broken.

split: func [

    "Split a series into pieces; fixed or variable size, fixed number, 
    or at delimiters"
    series	[series!] "The series to split"

    dlm		[block! integer! char! bitset! any-string!] "Split size, delimiter(s), 
    or rule(s)." 

    /into	"If dlm is an integer, split into n pieces, rather than pieces 
    of length n."

    /local size piece-size count mk1 mk2 res fill-val add-fill-val
][
    either all [block? dlm  parse dlm [some integer!]] [
        map-each len dlm [
            either positive? len [
                copy/part series series: skip series len
            ] [
                series: skip series len
                ; return unset so that nothing is added to output
                ()
            ]
        ]
    ][
        size: dlm   ; alias for readability
        res: collect [
            parse/all series case [
                all [integer? size  into] [

                    if size < 1 [cause-error 'Script 'invalid-arg size]
                    count: size - 1

                    piece-size: to integer! round/down divide length? series size
                    if zero? piece-size [piece-size: 1]
                    [

                        count [copy series piece-size skip (keep/only series)]
                        copy series to end (keep/only series)
                    ]
                ]
                integer? dlm [

                    if size < 1 [cause-error 'Script 'invalid-arg size]

                    [any [copy series 1 size skip (keep/only series)]]
                ]

                'else [ ; = any [bitset? dlm  any-string? dlm  char? dlm]

                    [any [mk1: some [mk2: dlm break | skip] (keep/only copy/part mk1 
                    mk2)]]
                ]
            ]
        ]

        ;-- Special processing, to handle cases where the spec'd more items 
        in

        ;   /into than the series contains (so we want to append empty items),

        ;   or where the dlm was a char/string/charset and it was the last 
        char

        ;   (so we want to append an empty field that the above rule misses).
        fill-val: does [copy either any-block? series [[]] [""]]
        add-fill-val: does [append/only res fill-val]
        case [
            all [integer? size  into] [

                ; If the result is too short, i.e., less items than 'size, add
                ; empty items to fill it to 'size.

                ; We loop here, because insert/dup doesn't copy the value inserted.
                if size > length? res [
                    loop (size - length? res) [add-fill-val]
                ]
            ]
            ; integer? dlm [
            ; ]

            'else [ ; = any [bitset? dlm  any-string? dlm  char? dlm]

                ; If the last thing in the series is a delimiter, there is an

                ; implied empty field after it, which we add here.
                case [
                    bitset? dlm [

                        ; ATTEMPT is here because LAST will return NONE for an 

                        ; empty series, and finding none in a bitest is not allowed.

                        if attempt [find dlm last series] [add-fill-val]
                    ]
                    char? dlm [
                        if dlm = last series [add-fill-val]
                    ]
                    string? dlm [
                        if all [
                            find series dlm
                            empty? find/last/tail series dlm
                        ] [add-fill-val]
                    ]
                ]
            ]
        ]
                
        res
    ]
]

split: func [

    "Split a series into pieces; fixed or variable size, fixed number, 
    or at delimiters"
    series	[series!] "The series to split"

    dlm		[block! integer! char! bitset! any-string!] "Split size, delimiter(s), 
    or rule(s)." 

    /into	"If dlm is an integer, split into n pieces, rather than pieces 
    of length n."

    /local size piece-size count mk1 mk2 res fill-val add-fill-val
][
    either all [block? dlm  parse dlm [some integer!]] [
        map-each len dlm [
            either positive? len [
                copy/part series series: skip series len
            ] [
                series: skip series negate len
                ; return unset so that nothing is added to output
                ()
            ]
        ]
    ][
        size: dlm   ; alias for readability
        res: collect [
            parse/all series case [
                all [integer? size  into] [

                    if size < 1 [cause-error 'Script 'invalid-arg size]
                    count: size - 1

                    piece-size: to integer! round/down divide length? series size
                    if zero? piece-size [piece-size: 1]
                    [

                        count [copy series piece-size skip (keep/only series)]
                        copy series to end (keep/only series)
                    ]
                ]
                integer? dlm [

                    if size < 1 [cause-error 'Script 'invalid-arg size]

                    [any [copy series 1 size skip (keep/only series)]]
                ]

                'else [ ; = any [bitset? dlm  any-string? dlm  char? dlm]

                    [any [mk1: some [mk2: dlm break | skip] (keep/only copy/part mk1 
                    mk2)]]
                ]
            ]
        ]

        ;-- Special processing, to handle cases where the spec'd more items 
        in

        ;   /into than the series contains (so we want to append empty items),

        ;   or where the dlm was a char/string/charset and it was the last 
        char

        ;   (so we want to append an empty field that the above rule misses).
        fill-val: does [copy either any-block? series [[]] [""]]
        add-fill-val: does [append/only res fill-val]
        case [
            all [integer? size  into] [

                ; If the result is too short, i.e., less items than 'size, add
                ; empty items to fill it to 'size.

                ; We loop here, because insert/dup doesn't copy the value inserted.
                if size > length? res [
                    loop (size - length? res) [add-fill-val]
                ]
            ]
            ; integer? dlm [
            ; ]

            'else [ ; = any [bitset? dlm  any-string? dlm  char? dlm]

                ; If the last thing in the series is a delimiter, there is an

                ; implied empty field after it, which we add here.
                case [
                    bitset? dlm [

                        ; ATTEMPT is here because LAST will return NONE for an 

                        ; empty series, and finding none in a bitest is not allowed.

                        if attempt [find dlm last series] [add-fill-val]
                    ]
                    char? dlm [
                        if dlm = last series [add-fill-val]
                    ]
                    string? dlm [
                        if all [
                            find series dlm
                            empty? find/last/tail series dlm
                        ] [add-fill-val]
                    ]
                ]
            ]
        ]
                
        res
    ]
]

i.e. you're not looking for token separators in all cases.

Well, for me, that is better than the R2 approach, where it actually 
is the other way around, i.e. insecure.

wish for R3 / Topaz / Red / World:
Add common charsets and parsing rules to system object:
system/parse: context [
	digit: charset [#"0" - #"9"]
	upper: charset [#"A" - #"Z"]
	lower: charset [#"a" - #"z"]
	alpha: union upper lower
	hexdigit: union digit charset "abcdefABCDEF"
	bindigit: charset "01"
	space: charset " ^-^/"
	digits: [some digit]
	decimal: [opt digits "." digits | digits "." ]
	exponent: [ [ "e" | "E" ] opt ["+" | "-"] digits]
	float: [opt "-" [decimal | digits] opt exponent]
	email:...
	...etc.
]

This all seems very cutting edge so I expect anything could change 
(i.e. alpha).

if a data change takes more time than a single refresh interval, 
(i.e. the change is still occuring when the renderer awakes for its 
next refresh) then the renderer simply reuses the previous internal 
data. while its new user data is being setup.

Maxim, this is the hostlib, i.e. the OS_* functions, not the extension 
stuff.

I.e.:
  ld -r -o lib.o a.o b.o
  gcc -dynamiclib -o lib.so lib.o
  strip -x lib.so

(I.e. on Win32.)

First, all make-* build methods except make-gcc are community contributed 
and not officially (i.e. by Carl) maintained. Therefore they may 
get out of sync, until someone in the community steps up and fixes 
them.

(This should be in the !REBOL3 Graphics group, where it will b e 
useful)

Or let's add, E: "Exactly one of A, B, or C", assume you chose E 
and be done with it.

I.e. either isolate for both, or no-share for both, or something 
else for both (like "private").

Module path searching only works with non-file! module names. I.e.
import 'foo

will search the system/options/module-paths for a file name %foo.reb. 
This search is a _very_ useful feature which we shouldn't rid ourselves 
of by stupid wars over which suffix to use.


As a module author, I want to use a suffix which I know will make 
using the module easiest for my target audience.


As a module distributor, I also want to make it easiest for my target 
audience to use the modules _and_ I need to enforce consistency within 
my distribution.


The only one who does not really care about the suffix is the actual 
user. The user just wants to use third-party modules without having 
to homogenise their suffixes first. But the burden of choosing a 
sensible suffix is currently imposed on the user. This does not make 
much sense.

James, here is another way, if you know the words you want to remove, 
rather than the words you want to keep.

remove-words: func [

    "Returns a copy of the object with the specified words removed."
    object [object!]
    words  [word! block!] "The word, or words, to remove"
    /local spec
][
    spec: third object
    foreach word compose [(words)] [
        remove/part find/skip spec to set-word! word 2 2
    ]
    make object! spec
]

o: context [a: 1 b: 2 c: 3 d: 4 e: 5]
probe remove-words o 'c
probe remove-words o [a e]

(i.e. no refinement is needed)

>> a: [ b [ c [ 1 ]]]
== [b [c [1]]]
>> d: 'b
== b
>> e: 'c
== c

using a, d, and e, how would I get the value "1" ?

There may be better ways:
   first do to-path reduce ['a get 'd get 'e]

>> a/:d/:e/1
== 1

What is the best way to form decimal and avoid the E notation?
>> form .02
== "2E-2"

Thanks for your hard work.
I didn't read your proposals yet, though.

I think I found the optimal way. As you noticed, it involves modulo 
maths.

swap-sub: func [s pos /local len e sav][
	-- pos
	sav: s
	forever [
		e: skip s pos
		len: length? s
		loop len - pos [swap ++ s ++ e]
		if zero? len // pos [break]
		pos: pos - (len // pos)
	]
	sav
]

E.g. if you want such a behaviour, i.e. if the effect is desired.

I.e. a 'Linux" repository and a "Win32" repository where you manually 
do merges (or copy/paste) in between will only lead to trouble.

The same post-commit hook then:

- moves the export to someplace public (i.e. another public VCS like 
Github or Google Code; or simply uploading them to rebol.net/rebol.com),
- and somehow notifies anyone interested of the new upload.

But you do not get that if you just clone someone else's repository 
in a read-only fashion... i.e. with the clone command " git clone 
git://github.com/rebolsource/r3-hostkit.git ".  It's easy enough 
to fix later, but you can do it up front by starting with a fork 
if you know you are planning on making changes and sending them back 
to the project.

(i.e. dapper, hardy, intrepid, jaunty)

When I say git-push, you actually writ e `git push`.

fetch

 just downloads the latest stuff into your local repository, but does 
 not actually touch your working copy (i.e. your files)

ok, I've read the whole exceptions document and a few (very old!) 
tickets at least 3 times now.


I'll start by being honest and saying that some of this is going 
a bit deep into some details and I'm pretty sure that I'm not graping 
all implications.  The background for all the discussion hasn't "sinked 
in" yet, so its a bit hard to be totally conclusive about my evaluation 
thus far.


this being said... when I arrived at 5, i.e. "Definitional return 
only, with an option to not redefine RETURN and EXIT", it suddently 
starts making sense overall.  6. seems to be redundant and maybe 
even harmfull if we keep THROW dynamic.  This is scaled with CC#1744 
"fixed" and a wider use of THROW, encouraged, since it now allows 
custom escape/exception modeling by non guru-level Rebolers (and 
by guru I mean one of 3-4 rebolers on the earth... maybe not even 
including Carl ;-).


this means, that return does one thing, throw does another.  they 
become two completely different things, clear and conscice in all 
code.


the only real issue I have is that we seem to loose return in parse, 
 but if we keep throw dynamic, then that is moot, and we can just 
use THROW instead.  In fact, woudn't that be preferable, since its 
more accurate?  we are pre-empting the parse return and providing 
our own... which is what throw should be doing ... its more consistent 
overall.


so go ahead rip my arguments appart... it will only help me understand 
this completely.  :-)

A description of the difference between the definitional and dynamic 
return:


*the dynamic return returns to the dynamically closest function (i.e. 
to the function that was called as the last one)

*the definitional return returns to the definitionally closest function 
(i.e. to the function that was defined as the last one and contained 
the return in question)

Brian wrote: "BREAK also applies to PARSE, which relies on dynamic 
scope (and yes, I can point you to mathematical proofs of this, though 
there's no point)" - I *must* correct this! Parse break is:

- neither dynamic
- nor definitional

it is a third kind:

parse break is lexical

Here is why:


1) It is stated in the documentation, that "parse break is a keyword", 
i.e. it it lexically defined to be a keyword of the dialect

2) it is stated in the documentation, that it "breaks out from the 
nearest loop", which is true, but it the lexical sense again

...which proves, that break breaks out from A actually, i.e. from 
the lexically closest construct

, i.e. it is more appropriate in for the documentation purposes, 
than as a function name

Giving the 'self issue in objects another thought. It occurs to me, 
that we could be better off not having it at all, i.e. having all 
contexts seflless. An object method can refer to the object without 
using 'self anyway. E.g.:

o: make object! [this: does [bind? 'this]]
same? o o/this
== true

this is the easiest way to know if a data element can be traversed 
via pick without having to first know if the datatype can be traversed.


the issue is that many types have indexed content but are not series 
(i.e. no "current" index).  so we can get the value or deny listing 
in one function call.

ex:

print-tree: funct  [data][
	i: 0
	either len: length? :data [
		repeat i len [print-tree pick :data i]
	][
		print mold/all :data
	]
]