World: r3wp

Btw - who cares of SlahDots at all? I don't visit if for so long 
already. Those ppl are real idiots ...

BrianH: what are your plans on task related stuff? Do you mean reworking 
highere level, or even low level? So far R3 uses threads, no? Are 
we after Eiffel model?

Found this presentation - http://www.cse.yorku.ca/~eiffel/cs_eiffel/scoop_slides/Concurrency.ppt

At least don't call it a "chat system" without the description "direct 
hotline to the main developer", as that line would stand out and 
make people think it's a joke

So far, R3 tasks don't work properly and should be considered a placeholder. 
We can't do a proper task model until there are changes to the basic 
semantics of REBOL. Fortunately most of those changes were done in 
the last month.

Main developers. Carl isn't the only one working on R3. Good to emphasize 
that too.

Pekr, the concurrency model to beat nowadays in the Erlang model, 
not Eiffel.

Perhaps thorough wiki-based documentation should be mentioned as 
well.

could this be helpful in R3? http://www.gearman.org/doku.php

Steeve, apparently Carl is working on vector! for the next release. 
Enjoy :)

Ladislav, I implemented your proposed changes to FUNCTOR, then enhanced 
them. New versions posted to DevBase. Enjoy :)

Any specs on MakeDoc3...
i do not see anything in the Wiki about it..

Well, it appears that Carl has handled *all* of the vector! bugs 
today. It looks like another good release is coming this week.

and almost all skip bugs too

Except MOVE/skip - I did that one :)

we are generally ending up with error for skip < 1?

How do you know? CureCode reports?

Is Vector really so important? I am just asking, as I don't precisely 
understand, what is the datatype good for, except one note from Carl, 
when I requested some better binary conversions, so that he said 
that it should be available via the cector! type.

for one, arrays of tightly-packed values we can use in external calls 
directly... like matrix transformations.

It's good for speed and memory saving, and better binary conversions. 
Once we have vectors, we will have less people complaining about 
the lack of rebcode, except for the people who never take good enough 
for an answer :(

And yes, Carl marks the native changes as done in CureCode the moment 
he gets a working build. I mark mezzanine changes as pending as soon 
as they are submitted to DevBase, then as build when they are released.

Perhaps vector is a requirement for rebin.

Sorry, Carl marks them as "built", even before they are released. 
A release usally comes within a day of that.

this also means we should be able to use STL  in rebol   :-)

so we can do array transformations in REAL TIME for things like polygons 
and 3d objects  :-)

Yes, we would likely have to nail down the semantics of the basic 
types before we could specify Rebin.

Maxim, there are much better array transform libraries than STL.

Ones that aren't as huge either, and that can be accessed through 
a C API.

maybe, but STL already allows us to do 3d object things like inverse 
IK for games or 3D modeling applications ... that is what one of 
the engineers was using to build plugins for Maya.

(where I used to work)

now if we can be the go-between things like these libs and opengl 
.....   :-D  can you see where I'm going ?  we already have a dataflow 
engine which could act as the kernel for managing when updates need 
to occur, and all rebol is doing is the whiping, while the grunt 
work is done by the various libs out there  ...

seems like I'll have to port liquid sooner than later  hehehe

brian, does R3 have manual alloc/de-alloc functions for level library 
work...  I mean, access to memory which isn't part of the garbage 
pool?

level library == library-level

GC, library interface, rebin, plug-ins- those topis are still kind 
of foggy - I think that no decision was made so far.

Alpha 51 released with lots of Vector! fixes. Steeve? :-)

Henrik, could you test ticket 744? I don't have a Mac.

Re: #744. They no longer crash but the "launched" script uses the 
same console session as the original script so keyboard input and 
screen output gets mixed up. This is different from the behaviour 
under Windows where R3 opens a new console session for the "launched" 
script.

The following session shows that launch does not effectively run 
a script as a separate process and return immediately.

>> ans: "yes"      

== "yes"

 >> do [ while [ans <> "no"] [ans: ask "(l)aunch, yes or no ?" if 
 ans = "l" [launch %launched.r]]]
(l)aunch, yes or no ?l
Checking for rebol.r file in /Users/peter/Desktop/Rebol3/
Checking for user.r file in /Users/peter/Desktop/Rebol3/


Evaluating: /Users/peter/Desktop/Rebol3/launched.r

launched script
Do you want to continue running the launched script?yes

yes

Do you want to continue running the launched script?yes
yes
Do you want to continue running the launched script?yes
yes
Do you want to continue running the launched script?no
no
(l)aunch, yes or no ?y
(l)aunch, yes or no ?y
(l)aunch, yes or no ?no
== none

The source of %launched.r is:

REBOL []

print "launched script"

ans: ""
while [ans <> "no"] [

   print ans: ask "Do you want to continue running the launched script?"
]

Same problem with call:

>> call "pwd"

/Users/peter/Desktop/Rebol3

== none

I'll mark it as tested then, and we can post any tweaks to the behavior 
as new tickets.

Would you like me to open a new ticket for the above?

I checked call on Windows and it doesn't work either. I opened ticket 
757.

CALL works correctly on Windows. The behavior you describe in ticket 
757 is by design. See the comments for that ticket.

The Mac version should work like the Windows version does.

I am not assuming that it does though - I can't test it.

The mac version appears to be working. At least call "ls" gives me 
a directory listing.

and returns none

Could you post system/options from R3 on Mac? Just run R3 and type 
in system/options

I can't paste here, as copy/paste is broken. Will be a couple of 
minutes...