World: r3wp

If you choose to upgrade to 3, then cool. Otherwise, 2 will still 
be there. Still, conversion shouldn't be too difficult, even automatically. 
You'd be surprised at how similar R2 and R3 are on the surface language 
level.

I do hope they get parallel versions working right, and then update 
2 to fit. That would make it easier to work with multiple versions.

Brian - are you in 1.June group of early release developers?

How would I know? Noone has told me either way.

I couldn't make it to DevCon, even remotely. I'm still waiting for 
the material from the talks, though Carl's seems cool.

Brian.  Check the DevCon group.  Videos are posted.

And Carl's presentations are online as REBOL script aswell. (The 
slides.)

Those I've seen. R3 looks interesting. Hopefully I can figure out 
how to download the streams, as my download manager's RTSP support 
seems to be more specific to RealPlayer streams. I can't hear them 
right now - I'm in a server room - so I must download them for later.

can anybody send a ponter to the video streams ? thxs

ponter -> pointer

http://www.sahores-conseil.com/?q=node/2

Second try, sorry if this repeats.  Has RT given out any more details 
on the database or indexed files mentioned in one of Carl's blog 
entries about R3?

Yes: They say they aren't done with them, and may not be by the first 
release of R3.

thanks, any idea what approach or features they are aiming at?

Take a look at Carl's presentations from the DevCon - between that 
and the blogs, they pretty much lay things out. For more, wait and 
see.

I meant specific to the database indexed files part, have read the 
presentation and many of the blog posts already.  Waiting is tough 
:-) but was just checking.

I think Ladislav has been given responsibilty for RIF.  afaik.  If 
that is the case, expect
a simple to grok, but powerful little engine.  :)

Geomol, the changes in R3 are being done so that there should be 
no need to change in incompatible ways later. but of course we don't 
know the future so it's impossible to tell. if we get to the point 
where there are many useful libraries and many users, compatibility 
will be given more importance than "doing things right".

Geomol, I have a few quite complex scripts (~300kB) and I'm looking 
forward to rewrite them for R3. If it will speed up, why not, it 
will not be difficult imho. And if you don't want to use new features 
of R3 you can still use R2 as mentioned Brian.

sqlab: I did find REBOL through an Amiga magazine (Amiga Format), 
but it is not the Amiga connection (or Carl) that drives my interest 
in Rebol.

In order to continue using R2 once R3 comes out, three things must 
happen:

- View installation needs to be changed to allow multiple versions 
to be installed in parallel.
- These installation changes need to be backported to R2.

- Any changes to REBOL/Services that come with R3 need to be backported 
to R2, at least those that affect the line protocol.

That last one is for mixed version projects.

And, even then you need to tidy your code up so projects are "pure 
R2" or "pure R3".

You cannot go to R3 until all third party components have been converted.

Yet it may be hard to stay on R2 if a crucial component has been 
converted to R3 and the developer no longer offers R2 support.

Or break up the projects into R2 and R3 modules, not so easy with 
GUI widgets.

You'd then need to somehow run both scripts under separate versions 
of View.exe, and have the interacting in the way they did under a 
single image. 

Perhaps by reengineering  the components talk across third-party 
 port.
Could be tricky!

It's a lot easier for me - I almost never do GUI code with REBOL.

No dis on REBOL - it's just rare that I need to do GUIs at all. No 
interface is easier to use than no interface.

I don't plan to mix R2 and R3 projects. I do have prototypes of things 
written in R2 that will be rewritten for R3.

It will be interesting to see how much compatibility can be achieved, 
if anyone bothers. I think all those fundamental changes will make 
it hard to do. I'm not expecting to be able to stay backwards compatible, 
either.

I think most of my scripts will be mostly compatible. A lot of current 
REBOL code would still run on R1, and that was based on a different 
execution model. Internal changes don't have to mean surface changes 
- the dialects we write in are just skins.

I live mostly in View/VID land..

I decided not to use anything of VID for elixir and instead base 
the whole architecture on liquids.

that allows me to replace the underlying engine at will, with no 
effect on the top level view of the engine.

you see only simple little nodes and have pretty much no clue what 
changing the cursor node of a field will have as effect.

you only know that the cursor will have (possibly) moved by one.. 
but it might actually refuse to advance if your at the end :-)  so 
you cannot break the cursor.

the other pov of this is that the underlying engine does not have 
to be aware why its changing or where that occured... it only knows 
that the cursor really DID change. so it has to reflect itself.

so for elixir, I am thinking of building an OpenGL interface AND 
an AGG view based one using the same software. in fact, we could 
even have two simultaneous symmetric windows running and 0% code 
to add in the software :-)

(one in AGG and one in OpenGL, to compare them)

that is in R3.

part of what I am hoping will be possible anyways.

I've been interested in your Liquid developments. Can it handle non-graphical 
data flow?

liquid is not graphical.   elixir is an attempt at adding a high-level 
editor to liquid, but its actually adding some limitations to what 
can be done with nodes, in order to add structure and reloadability.

but in reality, elixir is not really a *liquid* graph editor.  its 
a graph editor which *USES* liquid.

Can you map nodes to physical world objects?

hum... move to !liquid group?

I don't like how RT will cook new VID behind close doors, period.

That was the whole RAMBO group chat made short :-) Now the longer 
version ....

Gabriele - I EXACTLY expected, you will mention 1.3 open project. 
And I can tell you, why it particularly failed. Not that group could 
not come to some consensus, but also because of Carl himself. Because 
- Carl disappeared from IOS for nearly 3 months, and it was frustrating 
... no reactions to private messages etc. That is not how things 
should work.

And hence - I will never take ANY position, if things are not outlined 
the way I need them to be ... one of the most important thing is 
- communication channel.

Pekr;  The User Group will follow Bob's Rules.  The name is Item 
1 on the agenda.

Open for debate and then (a possibly unfortunate side effect of democracy) 
the vote

of the assembly is the final word.  I'm suggesting [RIG], but lots 
of names will hit the 
floor before the vote.  :)