World: r3wp

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?

:-)

I did not read anything about "Threading" in R3.. Is there any news 
on that part.. or will R3 just do more flexible 'event handling? 
(as an alternative)

Pekr.. I hope its a public Beta..but i do think is an improved closed 
alpha release...

threading is there, but is not yet tested very much.

or tasks, as it's called.

tasks is the word architects seem to prefer to use these days -- 
glad that is the choice -- getting each of these little things right 
 adds up ...  I hope

Do VID3 buttons appropriately resize themselves to contain their 
text?  usually we have specify the size of the button now.

BUTTON doesn't. BTN does.

Know why the difference?

has something to do with the resizing algorithm in the new layout 
scheme

So, with 'btn I can have text ranging from 1 char to 100 chars?

And it will resize appropriately?

yes, but it still depends also on the size of the layout, I believe

checked. it doesn't.

Hmm.

Seems a simple requirement .. needed for localisation etc

shouldn't be a problem

to implement?

gabriele has a localization system that we might use

localisation was just an example

we're keeping the VID1 naming here, although we can change that. 
BUTTON in VID1 was fixed size while BTN was variable size. in many 
cases, you want all buttons with more or less the same size, so you 
use BUTTON; when you want them to adapt to the text size, you use 
BTN.