World: r3wp

On the other hand we can be confident that Rebol 3 won't take as 
logn as Perl 6 :-)

Brock; To add to what Peter said, it might be hard to say whether 
a port will be much harder, but there will be a far greater potential 
for getting more people involved.  So we are faced with the unknown 
of whether random masses can produce more than a select few; in term 
of better, stronger, faster.  Will opening the OS specific side free 
RT to focus on the core technology or saddle them with testing,  
filtering the various ports and spending all day answering developer 
questions?  Soon to be seen.  I'd hedge on the former and look forward 
to a tide of momentum.

Brock, it's mostly a time issue right now. Still a lot of loose ends. 
I have no idea of the porting process as it's not documented yet, 
and I don't expect to be doing the porting. I do expect that as soon 
the process is properly documented, anyone with experience in C-programming, 
will be able to do a port.

harder to port: no, it's the opposite, it's much easier than R2.

I think that would only be true if R3 can also be ported without 
implementing the multi-threading. Can it run single-threaded, like 
R2?

Kaj, Syllable does not support threading? I am curious, what REBOL 
threading strategy is, or how is IO solved in general. We know we've 
got devices. Do thouse run as threads? Or how does typical async 
network communication happen for e.g.?

Syllable has extra-special threading, like BeOS. Threaded applications 
need to be ported. We do have a PThreads implementation for portable 
threading, but it's incomplete

Syllable/BeOS threading is much more like Amiga threading than like 
Unix threading

Amiga had threading? I thought it has only tasks?

The terminology that exists today wasn't used at the time. It's vague 
whether you should call Amiga a microkernel, or it's tasking multi-threading, 
but it basically was

Unix has a rather big separation between heavy-weight processes and 
light-weight threads. Threads may only be implemented in userspace. 
On Amiga/BeOS/Syllable, threads are light-weight and are based on 
kernel tasks

kaj, i think it's still easier to port R3 even with threads.

Show us the code :-)

i'm sure it will be shown soon :)

For which definition of "soon"? ;-)

he's just teasing...

... Well, hope dies last ;-) ...

Beta coming soon?

As most ppl from here are already in alpha world, I suggest releasing 
for the rest of this world. I could even imagine voluntarily prepare 
some summary of tests/opinions/bugs in special channel here, so that 
Gabriele or others could bring it to alpha world, to prevent flooding 
main testing group with lots of chat ....

So, would you guys welcome to particiapate? Note: I have no mandate 
to promise you any such thing, I am just investigating possibilities 
of how to help others to get in and eventually help ....

Personally I feel that adding extra testers at this stage would probably 
be a mistake. This feeling is not based just on my own experience 
or the observation that those currently in the team keep asking for 
the space they need to get things done. It is also the advice on 
the seminal work on managing software product development - Fred 
Brooks's The Mythical Man-Month.

Saying that I share everybodies frustration .....but as the saying 
goes "patience is a virtue".

Testing is one thing, developing is another.

I am curious if they fixed a bug that exposes source code that I 
never put in RAMBO because of the sensitivity of it.

never heard about that?

Yeah I only sent an email to Carl long ago

has to do with ports

well, R3 ports are completely different so that's probably rewritten.

Yeah that is what I'm hoping.

>> map [where:] [1 2 3 4 5 6] [take/part where 2]
== [[1 2] [3 4] [5 6]]

I'm beginning to like this MAP function :-)

hardly intuitive though

I don't like non-advancing set-word index ...

The discussion was deeper.

foreach [where:] data [change where 1]

above is na infinite loop. Normal variables are applied to data block 
advancing, set-words non advancing. It allows for easier constructs 
on one hand, but ppl will have to be sure to understand the difference 
of set-words ...

I correct myself, now as Gabriele explained it ....

Graham, it needs a little context. The set-word in the word block 
points to the current position in the series. The behaviour has also 
been introduced with FOREACH. Before, there was no other way to grab 
the series itself (only its values) at it's current index inside 
the loop block.

you can freely use words with set-words in the block:

>> b: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> foreach [pos: val] b [?? pos ?? val]
pos: [1 2 3 4 5 6 7 8 9 10]
val: 1
pos: [2 3 4 5 6 7 8 9 10]
val: 2
pos: [3 4 5 6 7 8 9 10]
val: 3
etc..

yes, that is usefull, especially if you want to change elements in 
original series ....

Hi Pekr, I'd love to get my hands on an R3 alpha ... and I maybe 
would even have the time to play with it, but at the moment I don't 
feel like I'd have the resources to do some serieous testing. 

So, on the plus side, you don't have to expect a flood of error reports 
from my part ;-)

sorry I forgot to put an "a" into serieous ;-)

My guess is we won't see beta before Xmas.

this is based purely on RTs ability to keep to previous schedules 
:)

Gab, do you think Rebol could support one of those online real time 
multi-player sites with chat like Yahoogames?  Perhaps using LNS 
?

maybe time for a status update on Carl blog? 8-)

Good news: Bugs are being fixed.
Bad news: More bug reports in bugtracker.

:-)

Today Carl stated that we are probably close to public beta release. 
What "close" does mean, noone but Carl knows, though :-) But please, 
expect, well, a beta version, hmm, maybe even alpha :-)

close?: func [ release-date [ date! ] ] [
    ( release-date - now ) < 365
]

soon?: :close?

:-)