World: r3wp

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

http://rebol.hmkdesign.dk/files/sysops.txt

I look forward to AltME 3.

I look forward to a VMWare with working copy/paste :-/

Does LAUNCH work for you?

It launches a script alright, but am not sure what proper behavior 
would be for returning.

NONE is returned, even though the script itself returns an integer. 
I suppose that's correct?

Yeah. CALL doesn't return a value yet. I'm waiting for the host source 
before I make proposals.

Or rather, CALL retrns none.

LAUNCH also returns none.

>> source launch
launch: make function! [[
    {Runs a script as a separate process; return immediately.}
    script [file! string! none!] "The name of the script"
    /args arg [string! block! none!] "Arguments to the script"
    /local exe
][
    if file? script [script: to-local-file clean-path script]
    exe: to-local-file system/options/boot
    args: to-string reduce [{"} exe {" "} script {" }]
    if arg [append args arg]
    call args
]]

oh

I see bugs already. LAUNCH could use a revamp like LOAD.

could you explain?

Not correct for script = none. Might be some other tweaks too.

Does R3 have a way to launch a Rebol console?

apart from calling the R3 binary.