World: r3wp

http://rebol.net/wiki/Brian%27s_Take_on_Context  Docbase Link of 
above.  It's beefee.  Thanks Brian.

I expanded the above article, making it easier to understand and 
with more information.
http://rebol.net/wiki/R2_vs._R3_Contexts

By the way, it turns out that function! word references are around 
28% slower than closure! or object! word references.

BrianH, thanks for that context information, very good to keep in 
mind in both R2 and R3.

I'm struggling a bit with the closure! specifics.  I have used closures 
in Ruby (though I'm not clear on the difference between a block using 
yield and a closure at this point) and part of what I thought made 
valuable was the connection to the context they were formed with 
that persists.  I'm probably getting this all wrong but what does 
"next time tthe closure runs it will create a new context" imply 
on that front?

If Ruby is as much like Smalltalk as I remember, a block is like 
an anonymous function, and functions in Ruby are more like closures 
in REBOL. There is nothing like yield in REBOL yet, though I don't 
know whether Ruby's yield is a cooperative multitasking thing or 
an Icon-style resumable return for generators.

Ruby has the general overhead of indirect word binding so it can 
support things like closures directly, which is why it is slower 
than REBOL overall. On the other hand, REBOL has a lot of overhead 
when creaing closures because of its direct binding, but that same 
direct binding is part of what makes REBOL so fast otherwise. It's 
a tradeoff.

That sounds about right

I think Ruby's yield is both for cooperative multi-tasking and generators

Some languages use multitasking for generators - Icon doesn't. Does 
Ruby have Icon-style resumable return?

I daren't say. I don't know Icon

I don't know Icon either and I'm not sure about the cooperative multi-tasking 
part for Ruby, only seen the generators use so far.

A tiny bit of status report:


- Working on ports now. It's a very straight forward system, if you've 
been reading the docs.

- Carl found a bug in the garbage collector that would speed up a 
loop test case from 35.2 seconds to 6.4 seconds.

- After a while of core unicode testing, graphics is finally going 
back in. The third test version of View with unicode is going to 
be released soon.
- Still no unicode support inside View graphics, though.
- 445 bug reports so far.

- HTTP protocol recently done (IMHO a very nice and super-clean implementation 
of http1.1 by Gabriele).

- Test case system temporarily put on hold. Ports are more interesting. 
:-)

- WAIT now switches between efficiency and accuracy. It's accurate 
but CPU intensive when selecting a WAIT lower than 1 ms, because 
in those cases it uses it's own routine for waiting, but it can be 
done much more accurately than the OS timer. When above 1 second, 
it uses the OS timer.

oops, in the last line it should read "WAIT lower than 1 second", 
not 1 ms. :-)

Henrik, sounds interesting.  Thanks for the status report.

note, afaik the wait < 1 s problem only applies to windows. (although, 
other oses may have long context switches too)

>> ? evoke
USAGE:
        EVOKE chant

DESCRIPTION:
        Special guru meditations. (Not for beginners.)
        EVOKE is a native value.

ARGUMENTS:

        chant -- Single or block of words ('? to list) (word! block!)

:-)

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.