AltME groups: search

henrik yes.  the openGL CGR use the "container" rendering mode which 
allocates a windows control from scratch and adds it to the window.


then when you call show, it gets notified of the change in size and 
automatically updates the control and gl viewport & camera

notice that I do not call show on it in animation.  I call refresh, 
which bypasses view and makes it *much* faster.

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 ?  ;-)

Just to be sure I understand: 0MQ makes async call however it does 
it, and between 0MQ and Rebol the async is that I have to poll from 
Rebol side to check if the call is already done?

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.

He has a ham radio call sign ... call him up!

Well, at 25 I could still remember library of congress call numbers 
for books I had read ...  now anything I don't use on a weekly basis 
is GONE unless it is from the period 1957 to 1965

Don't change anything for me. It's your call to choose how you want 
things to appear for the not yet initialized Rebol visitors. You 
already filter away the visitors pretty well by using AltME as the 
main forum ...

Better call him back, then :-)

- MAJOR ANNOUNCEMENT -  Custom Gob Renderers :  prototype released


After weeks of work at various levels, here is the first prototype 
release of my R3 host-kit running OpenGL in HW.

http://www.pointillistic.com/open-REBOL/moa/files/r3-cgr.zip


I updated it to A109 this week-end, I also completely rebuilt the 
file structure so that all of my tools are outside of the host tree.

only the actual host-code patches remain within the host.  the distribution 
includes compiled versions as well as the latest R2 2.7.7 unreleased 
patch.


note that the current OpenGL CGR is not currently very programmable 
a part from giving it polygons to view, you can't change anything.

the view will rotate by 1 degre everytime you call show or refresh 
on it  (so it can be used for model turntables).

resizing the window resizes the view.   notice that full-screen doesn't 
affect rendering that much.

open the readme file for more information


also note that the current geometry engine auto-calculates surface 
normals using face normals, so you'll have a faceted look.

next release I'll add support for vertex normals which will allow 
smooth shading (at no cost).


please reply in ann-reply, and report any problems you may have... 
I'll fix ASAP.Custom Gob RenderersCustom Gob Renderers

A call to french reboleur :

Nous cherchons a promouvoir REBOL au sein de la communauté developpez.com.

Nous sommes donc en quête de bonnes volonté pour écrire des cours/tutoriels, 
des articles sur REBOL, des critiques des livres, animer un blog, 
etc...
Les bonnes volontés peuvent se déclarer sur : 

http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C16Nov201014400973923100%3E


(we are seeking for french volunteers to promote REBOL on french 
programing site developpez.com)

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

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

so call it 'parts instead

faced are instance variables .. just call them locals

Henrik: make-gob is "complete" in the sense that it has all the features 
that were necessary for VID. I'm not sure I'd call it "finished" 
though - for example I wanted to add hinting, and a number of things 
may need improvements. Also, maybe the code can be cleaned up.

so, we should call subfaces goblets ?

yes, it might be useful there, but it seems that INACTIVE would be 
enough along with the original DISABLED. INACTIVE is what I call 
FROZEN.

On tooltips, we can call them something else, but the functionality 
is important. It's not just about where the mouse is hovering, but 
things like syntax completion, context aware help, etc. touch and 
multitouch apps may use them differently, just as they have evolved 
from simple yellow boxes to rich content.

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.

Moreover, you're using the graphic engine quite intensivly.
For each refresh:
-  2 calls to the draw the function + 2 shows


Maybe only one show of a composed gob (without the need to call draw 
seperatly) would increase the perfs.

Goal is to create all internal tools with R3 now (we call them Level-2 
= L2 tools) and build the Level-3 (libs, frameworks, extensions, 
...) in parallel.

it could probably be worked out with a small patch to the host-kit. 
 but we might be asking for crashes if any call to print is done.

CALL is important to me. Not sure where that stands.

CALL we can mostly do on our own, as extension.

I'm all for anything that moves us forward, but solutions like cURL 
and CALL via an extension means I know I'm going to have to change 
things later, or live with more pieces.

CALL via extension should ideally not require any changing later 
on.

We can fix CALL - it's in the host code.

7 crashes both after the third call.

Interesting point.  I would suspect the goal is to have the first, 
or top level be "code free", such that it is just settings.

But then, if you "want" you can call upon other files that contain 
code.

As a concept it sounds smart, which is unrelated to the reality that 
it might not be possible.

So, "is it" possible.

...and it surely does not make sense to call #[map! [...]] a "serialized 
constructor" - it is just a syntactic "construct" used as data by 
something.

yeah, but imagine a function call in stead of none in my code. A 
function, that returns none when failure (like no more data).

There are some real limits to op! evaluation that makes them unsafe 
for general use for now. For one thing, the type of the first argument 
is not checked at call time relative to the typespec by the evaluator 
- it has to be checked by the function itself internally. This is 
not a problem with most existing ops because they map to actions 
(which have their type compatibility handled by the action dispatcher), 
or in some cases natives that perform their own internal type checking. 
I believe this was a speeed tradeoff. If you allowed full user creation 
of ops even with their current restriction to actions and natives, 
you could bypass the typespecs of natives and corrupt R3's memory. 
Adding in that typespec check to the op! evaluator would slow down 
op! evaluation a little, but would be necessary if you really wanted 
to make user-defined ops possible.

The other trick that would need to be accounted for is that the actual 
process of calling functions is different for every function type, 
and afaict the differences are implemented in the evaluator itself 
rather than in some hidden action! of the function's datatype implementation. 
This is why I was glad to figure out that the command! type was sufficient 
to implement what we needed user-defined function types for, because 
it appears that user-defined function types are impossible in R3, 
even potentially. The op! redirector needs to be able to understand 
how to call the function types it supports. R2 ops only understood 
how to call actions (technically, DO did the redirection in R2, not 
the op! code itself). R3 ops can also redirect to natives, which 
is why some functions are native! now that were action! in R2. In 
order to support making ops from user-defined functions, the op! 
redirector code would need to be expanded to support calling those 
function types.

so we just need 'call

I noticed when you did the poll, you used a safe function that you 
knew the source of. Do the poll again with a function that deletes 
your hard drive, or even a block of code for some other dialect that 
will coincidentally do damage when interpreted by the DO dialect 
(since R2 does this with blocks and parens as well). Or even a function 
that takes an unknown number of parameters, and put the call in the 
middle of code that might be affected by evaluation order or get-word 
hacking.

Most of you might not remember this, but parens used to be treated 
as active values in R2. If you had a paren assigned to a word, putting 
that word inline in a DO dialect block would cause the paren to be 
executed. I used to use this as a way of having quick thunks (functions 
that take no parameters) without calling DO explicitly. However, 
this made it difficult to work with paren values, and was eventually 
removed for security reasons because it made screening for potentially 
dangerous values more difficult than a simple ANY-FUNCTION? call. 
It would be bad to make word! and path! values just as difficult 
to work with.

Now, for your questions, Kaj.


Mezzanines execute arbitrary code with DO. You can't even know if 
something is code or not until you pass it to a dialect interpreter 
like DO or PARSE - code is data. Blocks don't have bindings, only 
their any-word contents do, so the code blocks of functions are not 
bound to functions, only their contents are. The same goes for functions 
in modules or objects - they aren't bound to their objects or modules, 
only referenced by them.


(making this up on the fly) It could be possible to make the binding 
visibility of words be defined as a set of capability tokens as part 
of the object spec (in the SPEC-OF sense), and have the function 
spec dialect be extended to contain such tokens. This would have 
to be checked with every word access, and we would have to be careful 
to make the model in such a way to avoid unauthorized privilege escalation. 
Then changes in capabilities would happen on the function call stack, 
which is task-specific.


The problem with this is making sure code can't make functions with 
more capabilities than the code making them currently possesses. 
Though R3 doesn't really have a user model, it does have a task model 
and we could make the capability level task-specific. Code could 
constrain capabilities for code it calls, but we don't want privilege 
escalation at function creation time. It would be possible to have 
privilege escalation at function call time if the function called 
was created by something with the necessary capabilities.

Drawbacks:

- If we do this for binding visibility, this means a capabilities 
check would go into every word access. Word access would be SLOW.

- This doesn't add anything to the PROTECT/hide model, which handles 
binding visibility without the slowdown.


Capabilities would be like the SECURE model, but more flexible, so 
that's something to consider there. What SECURE protects is heavy 
enough that a capabilities check wouldn't add much to the overhead.

Of the 3, SECURE seems like the most likely to be enhanceable with 
capabilities. Functions could be enhanced by capabilities specs, 
where the function code could only create other functions of equal 
to or lesser capabilities than are currently available in the call 
stack. Once a function is created, it could run code with the capabilities 
that it was created with (with the exception of that function creation 
limitation earlier). There could be a function like DO that reduces 
capabilities and then does a block of code, and maybe MAKE module! 
could be made to use that function based on capabilities in the module 
spec.

Once again that "consistent" word. There is the main difference. 
I do not think you can call "inconsistency" any difference in the 
evaluation of the former and the latter expression, since the former 
expression is about handling lit-words as arguments of the DO function, 
while the latter is about handling words as inline block values, 
when they refer to lit-words.

I remember reading, parens are evaluated (an active type, I think 
you call it). It's a very fundamental thing. Breaking this rule make 
the code less readable. Is it really necessary? What natives or mezz 
have get-word arguments? Kinda the same with lit-word arguments (in 
the spec block). My guess is, Carl made those, so he could write:
help add
instead of
help 'add

right, what should we call them to not make confusion?

About unevaluated lit arguments (or literal arguments, as Carl call 
them), the functions FOR, FOREACH, REPEAT and maybe more use them 
(I couldn't remember earlier when I posted). And yes, it's more convenient 
to write
	repeat i 10 [...]
than
	repeat 'i 10 [...]


But used in some cases, it's probably easier to create less readable 
code. I can imagine a language, where this is different. About the 
other type of unevaluated arguments (get arguments as Carl call them), 
I haven't found other functions than QUOTE, that use it. There must 
be others!?

If you want a SECURE 'get-word constraint that you can apply after 
QUOTE is defined, that will block some but not all function hacking 
attempts using function values. The "but not all" part is critical 
though, so we are better off from a security standpoint if developers 
aren't allowed to think of function values as being safe to call 
without precautions, since the consistency of the need for that precaution 
makes it more commonly applied.

>> stats/series
== [16384 11618 4590 25 151 150 199]
>> a: [1 2 3]
== [1 2 3]
>> stats/series
== [16384 11623 4601 25 135 134 202]


Only one of those is the new block - the rest are overhead of either 
the STATS function or of the REPL loop itself, or runtime overhead, 
or call overhead, or assignment overhead. I'm starting to think that 
STATS/series isn't very useful.

Of course ++ and -- allocate error! values to trigger if they are 
called incorrectly, and the R2 version does a REDUCE as part of that 
error triggering call. But that's not the normal case.

Command call frames are not made up of 128bit values, afaik, they 
are 64bit unions.

I wouldn't have closure, but use object instead (or context, as I 
call them), if that functionality is wanted. And block content isn't 
bound to start with, so if I write:

>> f1: [a]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 2


because 'a' inside f1 is bound to local 'a' in f2, when evaluated. 
If I want another 'a', I could write:


>> context [a: 1 set 'f1 compile [a]]	; f1 will be a block, [a], 
where the 'a' is bound to 'a' in the context
>> f2 f1
== 1

and the last result could be achieved:

>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


Calling f3 will be slower, as blk is recompiled each time. This language, 
I illustrate, isn't REBOL, but another with many similarities to 
REBOL, but with a compile function. Maybe kinda the same could be 
achieved in REBOL, if the binding rules was changed, and "compile" 
in my examples above was changed to a "rebind" function.

The PARSE statement in CLOSURE creates the code for a call to a function 
that the resulting outer function creates every time it is called. 
If you want to understand what the PARSE statement is doing, make 
a function with CLOSURE and look at its source.

Recursive functions in R2 work by pushing the block of values in 
a context onto a stack during the recursive calls, then popping them 
off on return. In R2, function contexts are stack-relative, which 
makes word dereferencing 27% slower relative to object contexts, 
but function calls in general faster. Closures bind to object contexts, 
which are recreated with every function call.

Jerry, the /local refinement is just another function option. If 
you provide that option when you call that function, you can provide 
initial values for the "local variables". In the case of sys/load-module, 
the security and control flow of that function depends on the local 
variables being initialized with the none value, so we want to avoid 
the /local option being used when the function is called. When a 
function refinement is not used its value is none, so if you want 
to ensure that it is none and trigger an error if it isn't, ASSERT/type 
[option none!] is the most efficient way to do this in R3.

I'm looking at what kind of functions, R3 has:
>> ? any-function!

ANY-FUNCTION! is a typeset of value: make typeset! [native! action! 
rebcode! command! op! closure! function!]


And then I come to think, if it's a problem having both native!, 
action! and function!. Should all 3 be seen as function! ? Having 
them all and now with the addition of closure, what if a native act 
like a closure? Should it then be a native-closure! ? Same with action! 
.


And what if it's possible one day to make operators, should we then 
call the current operators for nop! (or native-op!)? I guess, these 
types originated, because they're dealt with differently internally, 
but should the users have to deal with the differences?

ah, I see. (I even think, this was discussed somewhere.) Hm, not 
an easy call.

I'm not sure, and maybe it's a gray area. Are you familar with contracting 
between caller and function as described by Bertrand Meyer?


If you promise to call *r* with *pre* satisfied then I, in return, 
promise to deliver a final state in which *post* is satisfied.

*r* is a routine in his words.

Maxim, in your example, the user has access to the function f, can 
call it direcly. Let's say, we couldn't give the /local refinement, 
then I could just write:

	f evil-func "Print occurs as if nothing is wrong"


Why is it a problem, we can give the /local refinement? Isn't it 
false security, if it is changed, so we can't call with /local ?

Desiding what to do with block indexes out of range is a tough call, 
I think. I understand the argument not to cause errors, if it can 
be handled somehow, but I'm not sure, handling out-of-range problems 
is always good. What if it's a user bug in the code, that made the 
index get out of range? Then the user won't easily find that bug, 
as it causes no error.


It's not possible to index a block lower than 1 (first element). 
It's only possible to index out of range in the other end of the 
block, getting past the tail. And that can only be done by having 
an index there, and then remove something from earlier in the block. 
When the index is beyond the tail, then it has to be desided what 
to do with
	insert, remove, skip, next, back, pick, select, append
used on that index. (and maybe more like TAIL?, INDEX?, ...)

What does other languages do?

I'm not talking about calculating every time and changing of indexes 
being hold by variables and such. I only suggest, that INSERT does 
this:


If /only and if value being inserted is an index (or position or 
what we should call it) later in the same series, where we are inserting, 
add 1 to the index value and insert that.
In all other cases carrie on as usual.

This is by far the longest period of Carl's disappearance, IIRC. 
The reasons we can only speculate about - some personal/family difficulcies, 
burn-out to the REBOL topic, new daily job, which does not   left 
you with much energy and free time to do some other stuff, REBOL 
related.


We tried to get Carl's answer on R3 Chat, only with sporadic answer 
of recent Carl's job. But no answers to "what's next" for the REBOL. 
The reasons might be various again - Carl is willing to proceed, 
he just dosn't have time/energy. He is most probably not willing 
to open-source the project either, which gets us into kind of schizophrenic 
situation - no open-source, no progress either. If Carl would know 
the answer to what's next for REBOL question, he would already share 
it with us. But he did not do so, yet, which is a bit disappointing 
of course.


As for a phone call - I don't know - I would not call him, as it 
could get him into feeling, that we push him to give us an answer, 
which he might not have right now. But - I think that call from some 
friend, e.g. Reichart, would be accepted differently. But then - 
we can't push anyone to do anything, and from few weeks old discussion 
I think that Reichart does not necessarily feel urge to do such a 
thing, which is OK too.


So ... we wait ... and RED progresses at least, so hopefully in the 
end, there is still the chance that we will see the light in the 
end of the tunnel :-)

When I call a callback from C to R3 can I return a result from R3 
to C from the R3 callback handler?

Any idea? The rebol call just returns a fixed a string at the end 
of the callback function.

do we have to buy rebol source code from carl like it was done from 
neogeo by blender ? if that the case I'm ready to give to taht purpose 
one moth of salary in full this is how commited I am to rebol cause 

I like rebol I always liked it and will always like it ... I'm just 
extermely sad that we can't organise a proper stuff to make rebol 
the gran scripting language it deserves to be 

We lack comitement we lack seriousnes and sorry to tell you this 
but rebol shouldn't be our hobby it should be our reason to very 
live 

You guys should be ashamed to see so much people leaving this community 
and instead of smugging them and ignoring them YOU (yeah you !  don't 
force me to call you by your name !) should be an offering  force 
to create main project AND WORK WITH THE OTHERS to make rebol something 
noticeable not just something to fill your spare time !

you shoudl be ashamed of this ... common are you so blind that you 
see rebol being abandonned and deserted more and more  RMA is faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar 
zillion light years of being as community moving as RebGUI and the 
main reason is that by abandoning REbGUI you slaped us in our faces 
and know what we don't like that we don't like the gurus selected 
fews we don't like RMA we don't like what rebol has become and the 
one more hating is is carl sassenrath  himself  we forced his hand 
to give us more  freedom and more action on rebol and WE WASTED IT 
purely and simply 


Then all we ever standed for is futile and void ... and what I see 
here is stupid comments about a dead product that it's main own and 
only author abandoned .

Instead of giving bucktracks that will never been read or take in 
considaration please the remaining of you the rebol community TAKE 
ACTION !!!

If you hate me if you dispise me then this is your chance to prouve 
me wrong and make miserable ! cause hey the mniserable ones til now 
are you the stupid tens thousand bugs founders that will never find 
a solution cause the main guy to  implement those fixe is gone since 
november 2010

That is what I call "annoying"

OK, so you don't have a solution to that problem (darn, I was looking 
forward to that), but you have a proposed proof that it doesn't matter 
because you can't exploit it until the function is running. And since 
the BIND restriction when the function isn't running doesn't apply 
when the function *is* running later, even when applied to the same 
word, then the ban on BIND to a function-context-bound word when 
the function isn't running has no security benefit.


But the ban on BIND to the function! value *itself* still has value, 
because it would defeat the efforts to prevent any bound words from 
leaking out of the function from helping. Otherwise it would be unsafe 
to let untrusted code call safe functions because they would need 
to have a reference to the function in order to call it.

Why are you stating disprovable statements, and when I call them 
as such, you invent completely unrelated statements requiring me 
to prove them?

Ignore the particular literal value there, and substitute it with 
something that outside code can't otherwise get access to, like the 
results of a call to a function that is referred to by a PROTECT/hide 
variable.

Here is my short list (I am sure I forgot to mention a lot of things 
other people may find important)

Advantages of R3:

- new datatypes

-- map!, money!, percent!, closure!, module!, typeset!, command!, 
get-path!, 
- enhanced objects
- enhanced errors
- support for UNICODE strings
- enhanced bitsets (support for UNICODE)
- enhanced pairs
- 64-bit integers

- better conversions (to binary! and back)

- enhanced PARSE
-- new keywords added
- enhanced MOLD
-- improved MOLD/ALL
- enhanced LOAD
- some functions became natives
-- native APPEND
- more complete set of comparison functions
-- EQUIV? added
- much better RANDOM

- enhanced loops (CONTINUE)

- enhanced debugging capabilities (call stack)
- enhanced protection (PROTECT)

- improved GC

- more open (the host-kit is open source)

Disadvantages:

- missing list! (the demand for the datatype was low)

- missing hash! (for the majority of applications map! should be 
faster and more comfortable)

- no adequate substitute for the [throw] function attribute exists 
yet
- missing struct! (for substitute, see extensions)

I would add following "negatives" (depends upon how you look into 
it):


- no /libary extension and easy wrapping of DLLs. There was a bounty 
started to bring in kind of R2 DLL capabilities using extensions, 
Max was working on something, but did not deliver. Some ppl claim, 
that working with extensions is easy enough, much more powerfull, 
and that in fact R2 /library interface was weak in comparison in 
capabilities.


- weak and underpowered CALL.No /output or /wait parameter IIRC. 
Carl said, that R2 C code to it was complex, and that the code is 
eventually awailable for volunteer to bring in to R3. The outcome 
is - CALL is limited in usage in comparison to what can be easily 
achieved in R2.


- protocols. The only protocol IIRC was available was HTTP, done 
by Gabriele. It was HTTP 1.1 compatible, but due to some bug (?) 
it was downgraded to 1.0 version. No proxy support. Other protocols 
were done by some other ppl, I do remember Graham doing some work 
here. In regards to protocols, IIRC there was some work done by Kaj, 
who brought Curl networking extension to R3.


- under Windows console is a bit more inconvenient in usage than 
in R2, we use native Windows console, yet we don't have full console 
support, so we can't replace the native R3 one by e.g. Console2 or 
some other version ...


- DBAccess - forget R2 protocols available. The rescue is ODBC extension 
for R3


- CGI - no native CGI support in R3, though it should not be difficult 
to emulate


- Sorting & Unicode - althought we have Unicode strings available, 
sort is not adapted to that, and the question is, if it can be easily 
done ...

weak and underpowered CALL.No /output or /wait parameter IIRC.


I agree with the general notion (that CALL is weak, atm), but: /wait 
is there (albeit not working on Linux, IIRC). /output is missing 
indeed.


But CALL is fully doable as extension or from within the hostkit. 
So if anyone really needs it, it's a matter of either developing 
it yourself or funding the development. (Feel free to contact me, 
if interested in the latter.)

With R3 you can just callback functions if you want a synchronous 
call, or callback through an event if you want to go asynchronous.

But R3 can't deal very good with multi-threaded libs. You need to 
trick it: Use async with non or integer value to trigger a sync call 
on Rebol side.

I did put a 'wait in one of the examples used to download a timeline 
- Twitter does restrict the number of times you can call their API 
so if you're copying a large timeline, then I put an optional 'wait 
parameter in the export function to allow a break between each call.

Recorded on film, video taped. What do you call it?

people who take videos for weddings call themselves videographers 
... so the verb would be videograp ?

I think we need to consider what the MOLD output looks like, though 
I'm not sure about Oldes's suggestion of a /heredoc refinement. And 
while I like Ladislav's serialized rebol syntax, I wonder if there 
are other possibilities. Could we leverage the << heredoc standard, 
and would that be better or more confusing with the tag! type as 
a close relative. It also makes me think more generally about where 
it fits in the rebol lexicon. Is it still just a string!, or are 
there wider implications? What do we call it? Is its main purpose 
to make dealing with curly-brace languages easier, and is that just 
a vague "nicer thing" or are there specific cases we have in mind 
(e.g., test cases :-) ? If rebol is still at its heart a messaging 
language, how would we leverage this type of "payload"?

What do we call it?
 - I propose "the heredoc syntax"

Regarding the syntax name - if we want to use a scientific one, we 
can call the syntaxes "single-line syntax with escaping", "multi-line 
syntax with escaping", and "multi-line syntax without escaping".

And finally, it doesn't matter what we call it. The names of these 
syntax types won't appear in code, just in docs. So stick to the 
standard.

Actually, I think a pre is closer to heredoc than CDATA.
CDATA is strictly speaking for XML or XHTML. not HTML.

And CDATA only, in effect, protects unescaped <, > and & from being 
interpreted as mark-up.

Perhaps, more importantly for the heredoc issue, whitespace is not 
guaranteed to be left as-is in CDATA:
   http://www.w3.org/TR/html4/types.html#h-6.2
But it certainly does not matter to me what we call it :)

:-) It was more like "you call yourself a reboller?"

CC makes me think of "Call with Continuation", but I agree that MAKE-CONTINUABLE 
is a little long. Just CONTINUABLE? Without 'continue in the name 
somehow, even if abbreviated, you lost the connection to the keyword.

I don't care if it is a separate function, I am just using those 
names for the concept. There are practical reasons to put these in 
CATCH, but it's not strictly necessary. But SANDBOX would *have to 
be mezzanine* to be able to do its job, so we need native functions 
or options for it to call.

The only way to get around SECURE's user request thing securely is 
to do it within SECURE, and restore it before the initial call to 
SECURE returns.

Andreas, the recent SQL standards call this operation MERGE, partly 
because UPSERT sounds terrible.

But it looks like the error is triggered before the SQL call, so 
it looks like either the db or counter variables are none.

There is nothing special there related to the function definition. 
The 'db and 'counter vars are global. It looks like the initial
    db: SQL "select * from customer" 
call is failing, and 'db is set to none. Test for that.

If you want a file requester: request-file, if you just want to spawn 
a new Explorer window for the user, this should work: call "explorer".

do you know if the call method works under win7?

And you're right, there is probably something else going on. I am 
at least getting part of the message. A successful .xml call looks 
like this:

a: http-tools http://192.168.1.62/user/StorageEventMode.xml[] probe 
a
make object! [
    HTTP-Response: "HTTP/1.1 200 OK"
    Date: none
    Server: "Mango DSP - HTTP Server (v2.34)"
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: "text/xml"
    Content-Length: "270"
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
    Cache-Control: "no-store"
    content: {<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="StorageEventMode.xsl"?>
<StorageEventMode>
^-<RecOnNetworkFailure id="RecOnNetworkFailure" checked="true"/>
^-<PreEventBufferTime id="PreEventBufferTime" value="20"/>
</StorageEventMode>
}
]

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.

For that matter, that is what the call for idioms is for.

(phone call)

Well it comes down to this: Functions are defined lexically. Though 
they are called dynamically, they aren't called until after they 
have already been bound, definitionally. But as a side effect of 
tasking, those bindings are stack-relative, and those stacks are 
task-local. But random blocks of code outside of functions are bound 
to object contexts, and those are *not* task-local. So that means 
that the old R2 practice of calling shared blocks of code is a really 
bad idea in R3 if any words are modified, unless there is some kind 
of locking or synchronization. This means that those blocks need 
to be moved into functions if their code is meant to be sharable, 
which means that at least as far as RETURN and EXIT are concerned, 
they can be considered lexically scoped. The advantage that we would 
get from being able to call a shared block of code and explicitly 
return in that block is moot, because we can't really do that much 
anymore. This means that we don't lose anything by switching to definitional 
code that we haven't already lost for other reasons. At least as 
far as functions are concerned, all task-safe code is definitional.


Loops are also defined lexically, more or less, and the rebinding 
ones are also task-safe because they are BIND/copy'd to a selfless 
object context that is only used for that one call and thrown away 
afterwards. And most calls to loops are task-safe anyways because 
they are contained in functions. However, the LOOP, FORALL, FORSKIP 
and WHILE loops do not rebind at the moment. We actually prefer to 
use those particular loops sometimes in R3 code because they can 
be more efficient than *EACH and REPEAT, because they don't have 
that BIND/copy overhead. Other times we prefer to use *EACH or REPEAT, 
in case particular loop fits better, or has high-enough repetitions 
and enough word references that the 27% overhead for stack-local 
word reference is enough to be more than the once-per-loop BIND/copy 
overhead. Since you don't have to move blocks into *loops* to make 
them task-safe, you can use blocks referred to by word to hold code 
that would be shared between different bits of code in the same function. 
This is called manual common subexpression elimination (CSE), and 
is a common optimization trick in advanced REBOL code, because we 
have to hand-optimize REBOL using tricks that the compiler would 
do for us if we were using a compiled language. Also, PARSE rules 
are often called from loops, and they are frequently (and in specific 
cases necessarily) referred to by word instead of lexically nested; 
most of the time these rules can be quite large, maximizing BIND/copy 
overhead, so you definitely don't want to put the extensive ones 
in a FOREACH or a closure.

Switching to definitional break would have three real downsides:

* Every loop would need to BIND/copy, every time the loop is called, 
including the loops that we were explicitly using because they *don't* 
BIND/copy.

* Code that is not nested in the main loop block would not be able 
to break from that loop. And code that is nested in the main loop 
would BIND/copy.

* We can in theory catch unwinds, run some recovery code, and send 
them on their way (hopefully only in native code, see #1521). Definitional 
escapes might be hard or impossible to catch in this way, depending 
on how they are implemented, and that would mean that you couldn't 
recover from breaks anymore.


The upside to definitional break would be that you could skip past 
a loop or two if you wanted to, something you currently can't do. 
Another way to accomplish that would be to add /name options to all 
the loop functions, and that wouldn't have the BIND/copy overhead. 
Or to use THROW or THROW/name.


The situation with THROW is similar to that of the non-binding loops, 
but more so, still task-safe because of functions. But CATCH and 
THROW are typically the most useful in two scenarios:

* Escaping through a lot of levels that would catch dynamic breaks 
or returns.

* Premade custom escape functions that might need to enforce specific 
semantics.


Both of these uses can cause a great deal of difficulty if we switched 
to definitional throw. In the first case, the code is often either 
broken into different functions (and thus not nested), or all dumped 
into a very large set of nested code that we wouldn't want to BIND/copy. 
Remember, the more levels we want to throw past, the more code that 
goes into implementing those levels. In the second case definitional 
throw would usually not work at all because the CATCH and the THROW 
would contained in different functions, and the code that calls the 
function wrapping the THROW would not be nested inside the CATCH. 
So you would either need to rebind every bit of code that called 
the THROW, or the definitional THROW would need to be passed to the 
code that wants to call it like a continuation (similar concept). 
Either way would be really awkward.


On the plus side of dynamic (whatever), at least it's easy to catch 
an unwind for debugging, testing or recovery purposes. For that matter, 
the main advantage of using THROW/name as the basic operation that 
developers can use to make custom dynamic escape functions is that 
we can build in a standard way to catch it and that will work for 
every custom escape that is built with it. The end to the arms race 
of break-through and catch.

Yeah :) And I had another phone call.

The BREAK keyword does not break out of the nearest loop lexically, 
it breaks out of the nearest in the (PARSE equivalent of the) call 
chain. It is dynamic in scope, which can easily be demonstrated with 
ANY, SOME or WHILE with a named rule with a BREAK in it, instead 
of an inline block.

If you call a rule through a name, you are using dynamic scope. If 
the rule is inline then it is lexical scope.

DO (or IF, or ALL, ...) of a block by name tends to only show up 
in advanced code. That code tends to be critical, and we usually 
can't afford to make it non-working, but not many people do that 
level of hand-optimization of their code, mostly because their code 
isn't that speed or size critical, or they don't know how (or they 
don't like that technique). On the other hand, PARSE rules called 
from loops are often referred to by name and are moved physically 
outside of the loops that call them for really good reasons, some 
of which I mentioned above.

As far as the DO FUNC examples go, they are just equivalent to the 
LET examples, as is quite obvious. The distinctions are rather small, 
like the fact, that you do not need to create a function and then 
call DO

the case would be that 'x is defined dynamically. I suppose I'm confused 
by the use of system/contexts/user/x. would you call the user context 
'x that way?

less overhead for the user (does not have to call DO), less overhead 
for the interpreter (does not have to create the function), and a 
couple more quirks like RETURN and EXIT handling

oooh... sorry I didn't see that nuance (my fault) ... I didn't even 
realize we had bind? in R3.   hum.  this opens up many doors.  I 
think my mind mistook every use of BIND? as a  call to  [ not not 
BIND? word].  

(like   found?  vs  find)