World: r3wp

Latest report: Nothing big has happened in a couple of days. Carl 
is buried in some work and bugfixing. I'm building the new requester 
system with the new way to parse dialects. 267 bug reports listed. 
Cyphre has talked about speed optimizations that will be made to 
the graphics system. Pekr is talking. A lot. :-) Gabriele is also 
busy coding.


There are many requests on ports for OSX and Linux as this Windows-only 
thing is getting rather old. Geomol has shown interest in the OSX 
port. Brian Tiffin has shown interest in the Linux port. Both, I'm 
sure, could use some help at some point, if anyone is interested. 
:-)

Why isn't Kaj clamouring to help with the Syllable port ?? :)

Maybe I'm more patient than the rest of you? :-)

I'll just wait for the Linux port, and then R3/Core will probably 
compile right away on Syllable, thank you very much :-)

Well, it will likely be a bit more work than that. Multi-threading 
may be a problem, depending on what features it will use

Building two operating systems also tends to take a fair amount of 
time, so I'm not clamouring for more work

How about porting it to a plugin that actually works?

There's a logical problem with what you say. According to you there 
apparently is not working plugin, so there's nothing to port to

plugin will eventually come, I'm sure. right now it's not very productive 
to have a linux/OSX version, due to the fact that most of the developers 
don't run Windows on their primary development box.

it's not very productive _not_ to have a linux/OSX version :-)

Henrik, does this mean that it is going to _much_ harder to port 
R3 than previous versions?  I realize it will be harder as there 
is likely more system dependant code than in the past?  I also realize 
there is going to more dependence on the community to kick-in for 
various platform ports.  I agree however that the linux and OSX versions 
should come after the windows, but the plugin needs to be within 
this calendar year.  [Unless R3 is going to be so good without it 
that the X-internet that was invisioned years ago will be more possible]

I thought one of the reasons behind the R3 re-write was to make it 
much easier to port Rebol to different platforms. I believe there 
is a complete segregation of 'core' and 'platform dependent code'.

Given that the Python team is planning on a 12 month beta for Python 
3.0, personally I think that it would be wise to expect something 
similiar for Rebol 3.

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 ....