World: r3wp

not really sure what it does, but it's used for debugging

sets secret internal options.

:-)

REBOL 3 Alpha 2.100.10 Unicode
Init System Port
REBOL Host-Init
Built: 1-May-2008/21:33:53-7:00
Language: dansk - Denmark
56 datatypes, 68 actions, 141 natives
1021 words defined
>> stats
== 583680

How about wait 0?

I used it a few time just to be sure that an event got really triggered.

So, as we just decided to make Curl guys to close the Nitro doors, 
because R3 will be much cooler, the last phase of two months plan 
started just 5 minutes ago - http://www.rebol.com/rebol3/next.html
  .... yes, we are back to VID 3, with prior phases more or less 
finished .... just to let you know ....

Ah, I forgot to provide a smiley to the Curl remark :-)

.... or not? ;-)

Simple, Clean VID Requirements - http://www.rebol.net/r3blogs/0132.html

I added my 2 cents.

It would be really nice if Rebol 3 included some grid computing functionality 
out of the box. Something as simple to set up and get going as GridGain 
- http://www.gridgain.com.Or is it already very easy to achieve 
a master-worker kind of solution?

What about just support for EC2 etc?

What about just support for Gmail?

Henrik: Do the 56 datatypes include audio! and video! yet?

I know Pekr has talked about Rebol needing better multimedia support 
in the past ...I think he's right.

I'm also thinking about starting a save our hash! campaign - it's 
great for building unique lists.

map! will be used for fast unique lists. And it's too soon for multimedia 
datatypes... I think audio/video will not be datatype at all, rather 
a scheme I guess.

Don't forget user-defined datatypes, which will also be in R3. Some 
of the missing types will be added that way.

Will we be able to use find against a  map! ?

I think so, but you probably won't need to - map! is optimized for 
this kind of task without needing find.

There starts to be series of VID3 blogs. So - those who want to affect 
some design principles, can share their opinion there ....

Is there any way we can have a hybrid R2 with the new graphics system 
and the old core?

Some of us are tied to R2 because of networking

I wouldn't bet on it. That might be a month's worth of work, but 
I'll ask for an official statement.

At the moment, I'd like the opposite -- new core, current graphics 
: )  I don't want the new graphics system before it's ready.

I suspect the former would be more easily done than the latter

After all one starts with core and then builds view on top of it

Then how do you complete the new view without the new core underneath?

I suspect view is not really dependent on core

the event system is different, which I believe also has something 
to do with ports, which are a different concept in R3.

it's more for networking ( async ) and LNS

oh .. ok.

LNS is high priority for R3. Needed for Devbase.

Just seems to be a lack of participation in the R3 process ... and 
I'm wondering if it's because the changes are too great

If there were a way we could incorporate the changes into projects 
we are currently working on ... it just might make it easier

I think it's because the changes are very large, yes. It's rather 
impossible to do any real GUI work as long as VID3 is sitting in 
this current state, where we're trying to figure out how VID3 should 
work and that things might change from week to week.

What's the best way to get started?

with what part of R3?

There's just too much information there at present ...

playing with Vid3

I see Carl's current intention is to nail Vid3 down

probably get one of last year's builds and simply toy around with 
the layout dialect. current builds have VID3 left out.

yes, there are some design issues in that style creation is too complex 
and must be simplified. Carl and Gabriele are sorting that out in 
private.

we need an dummy's guide to vid3

we have one, but it's too complex :-)

well, actually I don't think it fits with the latest VID3 build

Ok, an idiot's guide then!

the dialect itself is easy enough.

it's probably a good idea to study it in order to find out how faces 
can work together and such.

I suspect we are only going to find it's limitation by starting to 
build small apps and see how it scales