World: r3wp

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.

LAUNCH, perhaps?

I don't get the question, sorry. Please explain what you want.

sometimes you want to start a Rebol console from an encapped application.

but you don't want to have to need to have rebol.exe locally.

That can be used to debug the application with access to all the 
variables etc.

Encapping is going to be different in R3, as is the console. It is 
intended that a graphical console will be developed, and callable 
from any graphical host. Hosts will be the new encapped apps.

a graphical console will be good.

We want our REPL :)

How is error handling handled?

I suppose that restricting console access for encapped apps would 
involve simply not including console code?

Similar to R2, though the errors start disarmed and need to be armed 
with DO. CAUSE-ERROR wraps this.

Henrik, sure :)

I have some radical ideas for a console. Carl will hate them. :-)

Carl doesn't have to use them - behold the power of modules.

That's good. Perhaps for R3/Plus

Ah, vector! fixed, great! :)

#460 not fixed

Now it's not possible to make signed/unsigned vectors using "make 
vector! [- 16 integer! 100]" ? Or is the syntax different? I cannot 
find it anywhere.

Ah, #460 is not fixed because maximum-of doesn't work at all. This 
should be first line in the 'maximum-of function: "if not skip [size: 
1]"

Rebolek - by testing in console - you have wrong order of arguments, 
try:

make vector! [integer! 16 100]

make vector! [unsigned integer! 16 100] ; there was change from hyphen 
to work "unsigned", dunno why - http://curecode.org/rebol3/ticket.rsp?id=350

The new syntax for unsigned vectors is to use the 'unsigned word, 
not the '+ word. The optional '- word for signed vectors is gone 
too.

The reason why is because people didn't understand that '+ was for 
unsigned, and '- was forr signed.

Bug #460 was a FORSKIP bug, not a MAXIMUM-OF bug. FORSKIP now works 
with vectors, so the bug is now fixed.

why + was for unsigned and not the reverse? :-)

Are you aware of any negative unsigned numbers? :)

I don't work at that level of REBOL. So we now have vector! datatype 
mostly fixed. One thing I don't understand is, that we are heading 
for performance, and then we can see minimum-of and maximum-of becoming 
mezzanines. The other thing is - what now? What is now available 
at practical level? What can we do with vector! type?

They can be mezzanines and still be as fast because FORSKIP is now 
native. Making the looping functions native makes REBOL faster overall. 
One thing people don't get is that mezzannes can be really fast in 
R3.

Vector types take up less space for the same data, and you don't 
have to use type tests when working on them. They're for fast processing 
of numeric data, conversions, all sorts of low-level goodness.

Could vector type help with stuff like DLL interfacing?

We could use some practical vector! recipes in the cookbook list. 
This will give people a good idea for what they can do.

I suspect things like audio samples and very large data sets (geographical 
data, 16-bit image data) could be used for this.