AltME groups: search

it doesn't really matter from the r3 script's point of view.   but 
MM timers are a bit more precise since they even allow for audio 
frequency precise timing.

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

I'll try whatever you want me to. As a point of note, it kind of 
looks like the animation is showing 1 in 10 to 30 frames or so. Also, 
I'm not sure that the colour rendering is OK - there seem to be too 
few colours used. Can you take a screen cap showing the torus on 
your end?

BTW, you might want to patch the 'button VID style to point to 'btn 
for this demo. "button" would be much better for the code demo, but 
the look of "btn" is way nicer (and more modern).

Good point. I'll change it right away.

Yes, Graham, my point is that I don't think this will be a priority 
for RT to address unless a hosted client has a big world.

I thought we had a Graphics group at one point, but maybe not.

Well... at this point... given that the more time goes on the harder 
it will be to fix this world, why don't we just make a new one?

So, we do have a single point of failure here...and no recovery plan

I want anyway to thank you all for your kindness, your time, your 
passion. But you have to see that small time, small means and lazyness 
don't build pyramids. You can't get to be productive and serrious 
and that's a pain to see. I tryed my best to get things moving around. 
I tryed my best to help. Even if  franckly my  center of interest 
was not on par with the topics. I tryed to give my point of view 
alway in the idea of making things better for us all and find ways 
to share the burden.

Wishing you good luck would be an insult to you all at this point.

But at this point I don't see the problem with excommunication.

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

Yes, we want REBOL being an ultimate media engine :-) Do you remember 
Carl stating Multimedia is his second name? One point at the time 
we were even teased with REBOL/Media :-)

We all agree on that, but I just want to raise the point that a lot 
of the short commings in view are based on some serious issues in 
VID.

I think R3-alpha is still alive as well, so Gab's GUI should be there 
too. It was many files IIRC. The question also is, if it will work 
with new R3 releases. So maybe it is easier for ppl to just get to 
r3-alpha ... I think each of us has access there :-) (note: I understand 
your message, why you want it in R3 chat, I just tried to point out, 
it is already available)

Someone should write a software book called 'The Joy of Naming'. 


We're used to 'facets, and I don't have anything against it, but 
it's telling that description for it uses both 'attributes and 'properties. 
I don't expect it will change at this point. We all just need to 
help new users learn what it means. 


'Template doesn't sound bad. It's funny, in OOP you have the concept 
of inheritance from a parent, but I don't know of a common term used 
for the view from the other direction. 'Attributes is probably the 
most common, but you don't hear it discussed as the base classing 
passing them on.

I thought that the whole point of Carl's GUI was to allow app developers 
ignore all of the little details about how the app looks and acts 
at runtime and just focus on the semantics. Let the stylist worry 
about the appearance, and let the infrastructre people worry about 
whether the input came from multitouch, mouse and keyboard, whatever. 
Separation of form and function.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

ok, but even if you generate own events you need to WAIT at some 
point so the CPU is not at 100% no?

Gabriele, that was my question too.  Currently If you have 'busy 
loop', no matter what technique you are using, you need to 'idle' 
at some point to give CPU some free time. Currently I don't know 
of a way how to do it in R3 as the CPU is getting high even on very 
long(in terms of CPU time) idle delays.

as I said, I will wait for the hostkit with view to be released before 
spending to much time on this... I really don't have time to go in 
depth with this... and I'm not even trying to convince anyone.  just 
replying to questions and I feel its being taken too seriously for 
now.   its possible, the better approach will be to have access to 
some of the AGG internals via the extensions and wrap these into 
generic objects, for example.


its still just an idea.  there is no point to going into details. 
 I need to see the view host kit first.

Steeve, ah, I see, you are basically processing your fake time events 
whenever other events happen (eg. mouse moves). But if that's the 
case, then there is absolutely no point in using those fake time 
events. Also, there is no guarantee you are going to get events...

no, the point is that this will be part of the main layout dialect, 
so it's important to consider now.

but I am a lamer, not a coder, so I can only bug you with many questions, 
and point out some things I eventually don't like (and in many case 
I don't like them because of my wrong understanding of the topic 
:-)

So i don"t see your point. To me, It's just doing the same thing 
you requested, but it seems you want something else.

Christian .. good point ...

didec windows console is boring and ugly now that i show agg could 
deal  pretty stuffs with text in color why don't we HTMLize our console 
and bring some new way to experience console direct code flow coding 
cause that was the strong point of R2 and that's the actual weak 
point of r3

Maybe there could be an alternative graphics framework at some point 
that could include WebKit modified to allow for the embedded browser's 
renderer to execute both JS and a REBOL dialect, the value of REBOL 
could become evident by way of conciseness, integration with full 
REBOL (and all the benefits that would bring).

Hosting Webkit wouldn't help here: The whole point to HTML5 etc. 
acceptance is that people don't have to install another program - 
they can just use their existing web browser. Hosting Webkit would 
only help us if we want to display existing web browser code; it 
wouldn't be necessary for generating code to run in Webkit, because 
the copy of Webkit that people would be displaying your GUI in would 
usually be a separate program, often on a separate computer. And 
HTML/JS/CSS is just text - we can generate text already.

Brian, my point with the embedded WebKit would be to have an alternative 
gui framework that has the capabilities people are used to from a 
browser. With a non-hosted WebKit (or any old browser), you couldn't 
have very close integration with the REBOL runtime.

Don't worry, I wasn't thinking of embedding R3 through anything other 
than browser plugin APIs, or Native Client. There's no point to trying 
to submit it into a particular browser unless it also exists as a 
plugin for other browsers.

Yes, point taken, but I don't expect those double check to be a big 
performance burden. First, it's still fast, and second, it probably 
is reserved for special needs only. Not every button with e.g. rounded 
borders needs to be detectable on a per pixel basis, often a rectangular 
region would suffix in most cases, I guess.

The only thing I can do right now is to point you to new GUI docs, 
maybe by reading the docs you will understand, how things are layered 
....

http://www.rebol.com/r3/docs/gui/gui.html

maxim not the same layers and they havec been separated in DX libraries 
well i can give you an article in tomshard ware with benchmark etc 
proving that point

From the API point-of-view, VID should not be affected, but - if 
you don't have all draw commands implemented yet, it can't work yet, 
no?

on a fonctionnality ground cairo have good point

Isn't it just simpler to introduce a new type ... fpair for floating 
point par

Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.

Yes, I realize ithe irony in using such a long post to argue for 
short words, but in some ways it illustrates my point :)

with rich text come a lot of  troubles like handling paragraphs resizing 
things etc... how and where images are inserted withing the text 
paragraphs etc ... Can at some point the image inserted within text 
can be a draw set instruction rendering (for graphics or SVG image 
rendering ) etc... how will that engine grow ?

but steeve have a point ...  it's ugly ... i don't know if that the 
antigrain thing but on the lower size fonts damn the rendering of 
the font is messed up ... you have on the same letter bigger and 
smaller parts... This was a problem we experienced on R2 too we noticed 
it. People said don't worry R3 is completly deferent etc... and in 
the result -> blured ugly fonts... like on R2  so wher is the gain 
?

shadwolf: if font rendering quality(or whatever else)  is so critical 
for you I think with R3 you have couple of options now:


1) wait until you get it for free (some day) while bitching at AltME 
about it
2) download the HostKit and improve the code yourself

3) pay(or overpersuade or whatever) someone else to improve the HostKit 
for your needs


So it looks you have at least 2 more ways(besides the 1. point) how 
to solve it comparing to R2 situation. Isn't that great?

it WON'T work... you guys are missing a point.  the coordinates have 
different origins.

Gobs are rectangular. A gob type that has an external origin point 
doesn't have to use that corner for its internal coordinates.

it won't add to the complexity.  that's the point of it being a switch.

Sorry, you lost me at "inherit". I'll have to let Cyphre chime in 
from this point.

robert said yesterday "Ok, latest host-kit compiled. Rich-text now 
included."....

I don't know guys you have a boring shadwolf  clamining rich text 
stuff you insult him you say he is nothing but a jerk a troll etc 
but anyway the week later you have it ready (proof that it was a 
point of interrest for you too ) then you don't say to shadwolf hey 
look at this maybe that will get you involved with us ? 


Naaaaaaaaah it's so much more fun to insult me and act like kids 
....

Bolek, I partially take back point 1. It seems that SPACING both 
does spacing outside the faces and between them. IMHO, they are two 
separate parameters.

Defense of situation: Because the foremost thing that has been criticized, 
when posting screenshots is the appearance of the GUI, as I was experimenting 
with a skin early on, which was dropped. As creators of professional 
UI systems know, looks are secondary, while functionality and consistency 
is primary. This is a point, I've been trying to make with the VID 
Extension Kit.

The problem with creating artwork now is that there is not a good 
method to implement it, other than by having to get your hands dirty 
and write the styles. There's no easy way to shove photoshop images 
into the R3 GUI. Maybe that will happen at some point. Feel free 
to post imagery if you like, but I'm afraid it's a bit of a waste 
of time right now.

yeah, the way some people have worded things (don't want to name 
names, but we know who they are :-)  ), there was a critical tone 
- IMO, they missed the point of what was shown so far

BrianH: stop claiming we don't refer to R3 GUI as VID, please? Where 
did you find out such a claim? It was VID 3 (Gab's version), and 
Carl's version was marked as VID 3.4 by Carl himself imo. There is 
NO point to stop calling it a VID, unless we find another marketing 
name, just because the architecture changed ...

a question... is there a single place where a gob is destroyed (maybe 
a callback or some method) within the host-kit?  just so its more 
invisible, when I need to detach a gob from the OpenGL rendering 
context... at this point I have all I need to build an OpenGL gob.. 
but nothing to get it automatically cleaned up.

my goal is to allow an dynamic linking of any external gfx engine 
within the current system.   hopefully DirectX, Cairo and ImageMagic 
integrations will also be possible, but I have no idea about their 
API so it might still be a pipe dram at this point.

completely missing the point, as usual.

Maxim good idea to take as entry point for rendering display with 
other graphical libraries area the  Gob/IMAGE even if it's some what 
extrem at least using that kind of binding you can keep using natural 
R3 GUI  and even use draw over the rendering. I'm surprise Carl doesn't 
see the point ...

thxs


are the online docs usable for style definition or has it changed 
so much that there's no point in trying to make a custom style right 
now?

It looks like the feature for keeping several draw blocks in the 
same style was removed or changed by accident. this means that the 
validation icons won't work, so I have to find a different way to 
test validation. I want to separate the dialog code from validation 
and then make a proper validation test window, so you can look at 
the code and see how it works.


Furthermore, there is a database extension, I want to test more: 
Parts of validation (the scoping part) was inspired by this one and 
I think it would be good to get this out in the open, as it can be 
extended either to a file database or any SQL database by the community. 
The point of it is to make it very simple to connect the logic of 
a form to a database record and it works a bit differently from setting 
up a regular form.

I don't explicitely want to use a face within a face...  for graphics, 
I want multiple gobs in a single face... so event detection, which 
starts at the gob, should allow us to have a state where if its user 
data is none, its just ignored from the stand point of the generic 
face handler...  at some point, it will hit the actual parent gob 
which IS the face, and event handling should occur there.


just ignoring the none user data is all event detection rountines 
in the r3gui you posted, did just that. IIRC.

This brings up a good point though. Do we consider a function dialected 
if the behavior is controlled by datatypes? SPLIT does have the case 
of a block of integers having more fine-grained control, so there 
is a dialect option there that could easily be expanded.

reply to the statement of past month "No It's not in my imagination 
that rebol is a financial faillure. R3 isn't sold so how can it bring 
money ? r2 is less sold than 10 years ago it's a matter of fact...Last 
point Carl had no remorse to take another job and disapear without 
announcing it publically... This is just basic respect  you say goodbye 
 when you leave ..."

you take carl's abandon as you want so let me free to interprete 
it as I want too and on my own point of view what he did is a slap 
in our face ...

my point is that I really fear all the actual project to be nothing 
more than oneshots that runs short and disapear after Carl brillant 
return to announce on his all mighty goodness he will reboot rebol 
and do r4 :)

Or rather it's copied to system/contexts/user/a, but the point remains 
the same.

Now this looks completely weird:
>> #"a" + #"b"
== #"A"


Having ordinal values that you wouldn't think of being numbers act 
like numbers seems really weird to me. I can accept that #"a" > #"A", 
but treating them like numbers without explicit conversion seems 
strange to me. I get similarly creeped out by multiplying one money! 
by another; I have to remember that despite the "$", and "money!" 
name, they aren't really money (a measure of quantity), they are 
just another numeric encoding that enables more precise decimal math 
than decimal! (another name that seems off to me, since its values 
are floating-point binary, not decimal).

I may be completely missing the point, Steeve. How exactly can the 
source of the INTERN function help with detection?

I guess the point is that "conversations" between people usually 
don't have a meaning.

Yes, my point is exactly the same, even without any new datatype, 
etc., having just a new syntax to specify strings will be of advantage.

You're missing my point Max. I'm saying it doesn't need to be optimal 
yet, because we have no idea if it's worth optimizing.

You are also missing another point. Graham's original statement was 
meant to be ironic :)

The point is not polluting CATCH with options that are better placed 
elsewhere.

yes my point to.

why would sandbox *have* to be mezz?

ok, good point.  this even adds some strength to my extension module 
  /pre   wish for allowing exported words not to be overwritten by 
standard mezz code.

That wouldn't work, because you would have to ask user permission 
to pop, at which point we are back in the same situation.

Brian, in

http://www.curecode.org/rebol3/ticket.rsp?id=1744&cursor=2

you wrote: "We already have local THROW and RETURN"


If we do, I must have missed them, knowing only the global variants. 
Can you point me to them?

heapify: func [s start len comp /local child sav][
	;-- search terminal leaf.
	child: start
	while [2 * child < len][
		child: 2 * child
		unless (comp s/(++ child) s/:child) [-- child]
	]
	if 2 * child = len [child: len]

	;-- bottom-up, search insertion point
	while [comp s/:child s/:start][child: shift child -1]
		
	;-- bottom-up swap
	sav: s/:start
	while [child > start][
			s/:child: also sav sav: s/:child
			child: shift child -1
	]
	s/:child: sav
]

heapsort: func [serie comp /local len][
	len: length? serie
	;-- build heap
	for i shift len -1 1 -1 [heapify serie i len :comp]
	;-- sort
	for i len 1 -1 [
		swap serie at serie i
		heapify serie 1 i - 1 :comp
	]
	serie
]

heapify: func [s start len comp /local step sav inc][
	inc: 0
	
	;-- search terminal leaf.
	step: start
	while [2 * step < len][
		++ inc
		step: 2 * step
		unless (comp s/(++ step) s/:step) [-- step]
	]
	if 2 * step = len [++ inc step: len]

	;-- bottom-up, search insertion point
	loop inc [
		unless (comp s/:step s/:start) [break] 
		step: shift step -1
		-- inc
	]
	
	;-- bottom-up swap
	switch/default inc [
		1 [swap at s start at s step]	;-- single swap
		0 []							;-- no swap
	][
		sav: s/:start					;-- chain swap
		loop inc [
				s/:step: also sav sav: s/:step
				step: shift step -1
		]
		s/:step: sav
	]
]

heapsort: func [serie comp /local len][
	len: length? serie
	
	;-- build heap
	for i shift len -1 1 -1 [heapify serie i len :comp]
	
	;-- sort
	for i len 1 -1 [
		swap serie at serie i
		heapify serie 1 i - 1 :comp
	]
	serie
]

Normally I would like to limit the occasions where an unset! can 
get through without errors triggered (those errors are the whole 
point to the unset! type), but in this case the other series manipulation 
functions accept any-type!, so consistency wins here. +1 any-type!.

Steeve, triggering an error is the point of unset!. The none! type 
is for when non-values aren't an error.

ok, so where there isn't a 255 in the mask, then replace the same 
point in the ip address with a *

Here's a working version:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

The bahaviour of my-code-a is confusing... What could be the point 
to do a: "" then?

First proposal (by Sunanda, copied from some other group): SECURE/do 
block!


SECURE/do would take a block of code to do in a different set of 
security constraints, and then return the security constraints to 
what they were before upon the return of the function. If the security 
constraints are more relaxed then the user would have to be asked, 
or whatever the security settings are. If they are more constrained, 
the user won't have to be asked. And the user won't be asked upon 
returning the constraints to their previous setting when SECURE/do 
returns - this is the whole point to the proposal.


SECURE/do would need to be task-local because its scope would be 
calling and returning from a function, a task-local operation.

But SECURE doesn't protect from those kind of security issues anyways, 
so this may be not a problem that we have to worry about here. However, 
normally the security prompt will protect against this kind of thing, 
and the whole point of SECURE/do is to get rid of that prompt.

since as part of the new task, there is an implicit "clone-user-context" 
step at some point...   maybe that could be something we can actually 
use manually within a script?

Pat, remember that you can replace the function building mezz code 
like funct and func.   though its not for novice users, since you 
do have the source when you 'SOURCE these builders, it can be quite 
easy to tweak them so they do a few things more...  like add a little 
break point at the end of each func and probe all the collected words, 
in FUNCT.


with a global word you could control if this tracing occurs, just 
by setting it to true or false, dynamically.

Making definitional return optional means that this option would 
need to be specified in the code that ''calls'' the functions that 
would benefit from it, rather than the functions themselves. This 
means that the option would need to be specified a lot.

What is that supposed to mean?


With optional definitional-return-only functions I would simply define 
a mezzanine USE with a definitional return, at which point it no 
longer swallows dynamic return. A caller of USE then does not have 
to worry about this at all.

you have no recourse

 is a polite way of saying "you are out of luck". At least regular 
 programmers would be out of luck there - I'm sure someone like Ladislav 
 could come up with an arcane workaround, or you could give up on 
 RETURN and EXIT and use another escape function instead, like THROW. 
 But I assume that you know what I meant by "recourse", and want the 
 point explained.


Pardon me, that question needs some background info. The return models 
are being used to deal with a basic problem of functions catching 
RETURN and EXIT when you don't want them to. This is the case with 
many mezzanine control functions which take and execute a block of 
code. We have been putting requests for new mezzanine control functions 
on hold for quite a while because they can't currently be made to 
pass through RETURN and EXIT, but USE and COLLECT got through before 
we started that, and the restriction is lifted now.


Let's use USE to illustrate, ignoring for the moment that USE *can* 
be rewritten so it doesn't use an inner function.

use: func [
    "Defines words local to a block."
    vars [block! word!] "Local word(s) to the block"
    body [block!] "Block to evaluate"
][
    apply make closure! reduce [to block! vars copy/deep body] []
]


USE uses an inner function to create a binding for its words (the 
closure!). For the dynamic return we have now, the inner function 
catches returns from the body, but even if it didn't the USE function 
itself would catch those returns as well.


One proposal to solve this would be to switch to definitional return, 
which means that RETURN and EXIT would be redefined in the code block 
of a function to return directly to that function, not any intermediate 
function in the call chain. This would solve returns being caught 
by the USE function itself, because the body of code that contains 
the 'return or 'exit words is not physically in the code of the USE 
function, it is only referenced by word. However, that block of code 
is used by the inner function as its code block, so the inner function 
would redefine those words and catch the returns.


If your function uses inner functions like USE does, and can't be 
rewritten to not use them, and you are using definitional return 
without the option to turn it off, then the inner function will localize 
RETURN and EXIT every time.


As a caveat, I wrote that phrase before I came up with the workaround 
in the next section of using direct references to the RETURN and 
EXIT function values instead of referring to them by name, which 
avoids the rebinding issues because no words are involved. See the 
code in http://curecode.org/rebol3/ticket.rsp?id=637to see what 
that workaround makes your code look like.

Of course, at this point you don't need to use an inner function 
at all, you just use bind + do.

USE's inner function is not erroneous, not in the slightest bit. 
The whole point of it is to rebind the code block passed to USE.

Fortunately, functions are built with nested blocks, though that 
is partly enhanced in R3 by tasking issues. And while loops are also 
build with nested blocks, 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), so we still need dynamic BREAK. 
Dynamic THROW is just a good idea because of all the capabilities 
that would give us.

Point is: the behaviour of BREAK in PARSE is not a strong argument 
at all when considering the behaviour of BREAK in loops.

Yes, based on varying levels of information. My statement is objective. 
It is all a tradeoff, and I have not at any point tried to hide the 
upsides and downsides of both approaches.

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

It's cool. Your point was made, and the disadvantages of definitional 
break that you hadn't gotten around to adding to the page yet are 
stated above in that big message.

the selfless object would be class and its self would point to the 
instance... something which is impossible with selfish contexts.

You can add a self field to a selfless context and it can be used 
like any other field. That is the whole point to selfless contexts.

yeah, but using bind is an inherently advanced use.  though like 
you, I understand that its just comparison.  


I'm in favor of 'SELF simply because I woudn't want REBOL code to 
become riddled with binds for such simple things. 


AFAIK bind doesn't scale well, in the sense that when you are playing 
around a lot with your code, bind will often become a point of failure, 
since the littlest change will quickly change what BIND does.