World: r3wp

btw - one question - in above Rebolek's example - why when we reassing 
(reference) a block ('b in his example), index? refers to original 
block, whereas functions like 'length? behave locally to new referenced 
block? Just a question :-)

... is it just because it is usefull this way, even if not consistent?

'b is a block! type, so no excuse here that it just "points to original 
block at certain position" applies here :-)

It's perfectly consistent and useful for subblocks. If INDEX? was 
local to the block in use, a lot of things wouldn't be possible.

You would not be able to recall the position of the subblock. You 
would have to recalculate it every time.

If you want index to be zero, copy the block.

Petr, I have been proposing that new PICKZ and POKEZ functions be 
added to do a 0-based PICK/POKE, instead of having vector! be 0-based. 
This would give us 0-based referencing abilities for all series, 
not just vectors, then we could make vectors 1-based like the rest. 
There are real advantages to 0-based indexing so it would be good 
to have it, but consistency is better here.


Carl was not proposing to make a change to PICK and POKE in his blog: 
he already (half) made the change. He was asking us in his blog if 
he should change it  *back* to the old, buggy R2 behavior. I think 
he should finish fixing PICK, POKE and AT instead.


Henrik, INDEX? returns a 1-based index from the *head* of the series 
- that's why it's always positive.

Indexes are calculated by adding the base to the offset. The new 
behavior for PICK and POKE makes that consistent, though AT should 
be fixed as well as it is the only index-based native left (unless 
I've forgotten something). I've added bug tickets for all of this.

OK, thanks for explanation.

Personally I prefer 0-based indexing since it's more useful and less 
confusing, but we are stuck with 1-based.

Is there a way to control/stop a task by the calling process or shall 
the called task check a semaphore set by the calling process?

In R3? Tasks don't really work yet, and we may be changing the model. 
Aside from that, I don't know.

then I hope the final implementation will get something like freeze 
and kill

Tasks are really up in the air, especially since threads are being 
considered to be a bad model nowadays in the multitasking community. 
It would be good for REBOL to start with a good model now, before 
it becomes too late to change later. Maybe green processes like Erlang 
:)

whatever model gets chosen, some control would be good.

erlangs concurrency model, hot code loading, easy process communication, 
robust message passing 

and a nice database (let's call it rebnesia)...all ported to our 
fabulous rebol.
...when did you said you are ready with this brian? :-))

BrianH - weren't threads choosed because processors better optimise 
them?

Pekr, threads were chosen because the multi-core processor increase 
hadn't started yet when the initial task! model was created. Processors 
don't optimize threads better than green processes, or even regular 
processes on Linux. Windows regular processes are pretty heavy but 
Windows 7 is implementing green processes right in the OS. That doesn't 
mean Erlang would need to use them though.

I think special thing about erlang is that each green process has 
very very little memory overhead (just 16-32 words) that is why there 
can be soo many of processes and that it can switch between them 
very fast. I imagine Erlang vm spreads N green processes on some 
number of native threads/processes (but I am not sure)... Another 
interesting language to look in this regards is stackless python

Maarten? Calling Maarten. Erlang is being discussed. :-)

Erlang uses their own lightweight process implementation (like you 
could write in REBOL .... hint); remember that the first version 
were written in Prolog. The Erlang VM uses all cores on a machine. 
The "no shared memory" aprroach makes this easy.


R3 should be able to utilize multiple cores. Then with async networking 
and people finally understanding dialecting who needs tasks? Just 
roll your own.

Maarten - could you please explain your "who needs tasks" remark? 
You need some low level support, to be async, no? And by async I 
don't think only networking ....

IIRC, in R3, processes (threads) were not planned to share memory. 
ipc scheme was supposed to be provided ...

He might mean "who needs threads?", because "tasks" aren't defined 
yet. As Erlang proves, there are advantages to having both green 
processes and full processes, especially if they are basically interchangeable 
as far as the code running in them is concerned. You *could* just 
go with full processes like R2 does ("Just roll your own."), but 
that wouldn't be as efficient as a hybrid green/full approach, particularly 
on platforms like Windows that have huge creation and switching overhead 
for full processes.

Having to roll our own would be very cumbersome. It might be simple 
for Maarten who has written threading engines for R2, but for us 
lesser ones, it would be handy, if it was built in. I consider not 
having it a showstopper in many cases. AFAIR, threading was the original 
reason for starting R3 development?

No, it was the broken port model.

Henrik, everyone who can, please get into R3 chat and read messages 
#1786 and #1436. I need help.

Nail-biting, hair-loss inducing reply posted. :-)

Hope we get a GUI for R3 chat soon ... I find it just too hard to 
read it in a console.

One formatting fix they need to make for RebDev is to put a blank 
line as the first input of each post.  Makes it a bit more readable.

Also, maybe add an R options to automatically have the message prefixed 
with a REPLY to #XXXX where x is the message number.

Paul, the R option exists and works like you specify.

Ahhh, that must mean that me and the Great mind of Carl think alike. 
 ;-)

I'm still a noob to RebDev.

I'd be happy if they had word-wrap, as I've been manually word-wrapping 
my own posts.

Reply to your nail-biter Henrik: #1789.

I thought Henrik's R3 GUI skills would have manufactured a GUI for 
RebDev by now.

R3's GUI is missing some necessary styles for a RebDev client, notably 
grids. Filling in the blanks needs more programmers, so we are focussing 
on getting the file management portions of DevBase integrated first 
so we can get other people involved in the process. Priorities :(

Also I'm pressed for time for about another month.

This /into option proposal is based on profile-driven *language design*. 
It's a new approach to REBOL.

I like the idea Brian.  In fact, I use that manner often in the things 
I do.

But why not make the /into default behavior?  And then use /copy 
for the alternative?

Because the series creatiion builder model is easier for less advanced 
REBOL programmers to use. Buffers need management (as #1789 explains). 
This new model is for more advanced programming, such as mezzanine 
and library code.

Well, right now i need discussion and consensus. I have CureCode 
wishes, mezzanine modifications, new functions, and massive optimizations 
all waiting on this. I'm really blocked until this is decided on.

I guess, I don't follow.  Maybe, I'm jumping to conclusions about 
what /into actually implies.  To me, /into implies that the original 
series passed to the function is what is modified and not a copy 
of it.

No, that's the /no-copy option - it's a completely different thing. 
See #1789.

Well, then I'm in favor of the no-copy option as the default behavior.

Please read #1789 before you make that decision. The difference between 
/no-copy and /into is important.

So you mean something like:
rejoin/into [a b c] out
instead of:
append out rejoin [a b c]
? I think I like it.

Yes. But not for (RE)JOIN because JOIN or REJOIN /into is exactly 
the same as INSERT and INSERT REDUCE. What we *do* need to add /into 
to is (RE)MOLD, (RE)FORM, REDUCE, COMPOSE, READ, COLLECT (needs changes), 
MAP and EXTRACT.