World: r3wp

There's the minor issue that I still have to make them, so I hope 
it will work :-)

@Awi: http://www.rebol.org/view-script.r?script=threaddemo.r&sid=w2hg

Henrik, Kaj, Marco, thanks for the help, I will look into those. 
Sorry for the late reply.

@Kaj: Sorry, a little of the topic. For the future, I'm planning 
to replace the Rebol 2 UI side of my app to use libchamplain or osm-gps-map. 
Hopefully I can already use red by then (currently python is in my 
mind). Which one do you think is more mature and easy to use? My 
app would only display OSM tiles and draw some objects and lines 
on it. Thanks for your opinion and pointing me into these libraries.

Champlain is much more complete and generic, except maybe the GPS 
track functionality. However, it uses Clutter, so OpenGL, so that 
must be available on your target platform

OSM-GPS-Map is thus simpler to roll out, but it is GPL instead of 
LGPL, so it can't be used in closed applications

Thanks Kaj, I really appreciate it.

I don't know where to post this request, so I put it here:

I am translating some .h files of useful shared library to rebol 
( fmod,sdl,opengl) so if you know of a useful-multiplatform-publi-shared 
library

please give me lonks to binaries, .h files and test programs, thanks.

I thought someone had done fmod already ?  Was it pekr or anton ?

Oldes and R3 https://github.com/Oldes/R3-extension-FMOD

I'm mainly using ImageMagick in a real live (R2) - here is a minimal 
set of routines - https://github.com/Oldes/rs/blob/master/projects/imagick/minimal/imagick.r

For imageMagick you can find useful parsed specs for magick_wand 
and pixel_wand routines https://github.com/Oldes/R3-extension-iMagick

@Oldes: Is that set minimal ?! Are there much more things to translate? 
Why don't you put it on rebol.org?

I guess it could be even more minimalized.. this subset was enough 
for my needs. As you can see in the parsed routines, there is much 
more what can be done, but it requires time to work on it. Also I 
don't consider R3 evolving so I stoped experimenting with it and 
in the free time I would rather play with Red (but Red is missing 
decimal support so it cannot be used with bindings like FMOD or imageMagick)

Also for me it's more easier to put scripts on github than rebol.org 
as most of scripts are build from multiple files.

is there already any way to turn block to object like data: [ a 1 
b "c" ]  ===> data: make object! [ a: 1 b: "c" ] so I could >> do 
bind [ print a ] data ; or do I have to do that "manually" ?

One way:

	data: [ a 1 b "c" ]
	forskip data 2 [change data to set-word! data/1]
	data: make object! data


I don't know, if there is a simpler function call, but you could 
wrap that into your own new function.

ah.. i forgot about change function, so my solution was more ugly

and I was thinking that there has to be something default already 
made .. thanks! I will create some func our of your code

in R3:
>> append context [] [a 1 b "c"]
== make object! [
    a: 1
    b: "c"
]

btw, in R2, forskip is a mezz (may be slow)

Is there a easy way to set REBOL Console title other than "REBOL/View"?
I want to give output to console but cannot change the title.

There is already a ticket on RAMBO #3660. Any easy way?

http://www.rebol.org/view-script.r?script=window-util.r

Thanks a lot.

today I discovered maybe fairly obvious thing about rebol, that was 
bugging me for long time and I thought there is no solution:
compose [ ([]) ] == []
compose [ ([ 1 2 3 ]) ] == [ 1 2 3 ] 


I just assumed taht compose functions the same way as reduce and 
never looked in details. And there were many instances where I would 
need such behaviour and I had to invent worse solutions because I 
didn't think it was possible with rebol.


I had it as one sign that rebol is not as mature as lisps because 
there you have @to deconstruct list in such a manner. But now I see 
we have even cleaner solution also.

Yes, COMPOSE flattens outer blocks

I am using rebol for quite few years now and I didn't know it :)

I have one binding + object question that is beyond me.. .this code 
represents it:
> c2: make c1 [ a: [b] b: func a [ print b ] ]
>> c1/a
== [a]
>> c1/b
** Script Error: b is missing its a argument
** Where: open-proto
** Near: c1/b
>> c2/a
== [b]
>> c2/b
** Script Error: b is missing its b argument
** Where: open-proto
** Near: c2/b
>> c3: make c1 [ a: [b] ]
== [b]
>> c3/a
== [b]
>> c3/b
** Script Error: b is missing its a argument
** Where: open-proto
** Near: c3/b

ah .. I didn't copy the first line.. I will copy this to some page 
rather than again here.

Please look here instead: http://pastie.org/3065592-- the point 
is when I extend c1 with c3 and define a I want that b which I didn't 
redefine takes the a from c3 not c1 where it was created (which I 
do understand is normal behaviour). Is this even possible?

You need to provide parameters to those /b functions.

In C1 and C2 you are creating new functions and assigning them to 
their 'b fields. In C3 you are just making a rebound copy of the 
function created in C1, which still has an [a] argument block. Changing 
the value of the object field a doesn't change the argument list 
of the function assigned to the object field b after that function 
has been created.

What's weirder (only tested in R3 so far): Once the function is created 
its argument words are bound to the internal function context, and 
bindings are by position in the context (though BIND determines this 
position from the name at binding time). That means that after the 
function is created, the displayed argument block is just documentation 
- the real argument list is the function context. This means that 
if you create the function using MAKE directly and keep a reference 
to the spec block, then change that spec block, the changes don't 
affect the function's behavior or what WORDS-OF returns. Like this:

>> a: [a] b: make function! reduce [a [print a]]
>> b 1
1
>> change a 'b
== []
>> b 1
1
>> source b
b: make function! [[b][print a]]
>> words-of :b
== [a]

>> help b
USAGE:
        B a

DESCRIPTION:
        (undocumented)
        B is a function value.

ARGUMENTS:
        b

Note the inconsistency in the help? That's the weird part.

It doesn't work that way in R2. Changes to a reference to the argument 
spec block don't change the function after it's created. Like this:
>> a: [a] b: make function! a [print a]
>> change a 'b
== []
>> source b
b: func [a][print a]
>> words-of :b
== [a]

Note: In R2, if you use the old-style reflectors to get at the spec 
then you can replicate the R3 weirdness because it returns a reference 
to the original spec. The SPEC-OF reflector is much safer, even in 
R2, because it returns a deep copy instead. Have I mentioned lately 
just how bad it is to use the R2-style ordinal reflectors instead 
of the R3 style *-OF reflectors?

Brian: interesting inconsistency. I have no idea how come it happens, 
I would assume help somehow uses words-of to show arguments so it 
couldn't happen :)

about my example code, I didn't explain it good enough. I am not 
giving them arguments intentionally .. I will make better example.

in R2, one can't prevent MAKE to reconstruct functions.
in R3 you,can do such by using COPY instead.

Janko, don't worry, I got it. The message beginning with "In C1 and 
C2 you are " was in answer to your question.

HELP uses WORDS-OF to show the arguments at the top, but uses SPEC-OF 
to get the detailed argument help below. The spec returned by SPEC-OF 
doesn't have any effect on the execution of the function - it's just 
documentation.

The inconsistency between R2 and R3 is because R3's reflection model 
was changed to be more secure, and easier to sandbox. In R3 you can't 
get a reference to the real spec and body of a function after the 
function is created, at least from non-native, non-debug code. That 
is why the hack above required saving a reference to the spec from 
before the function was created; if you don't do that, you won't 
be able to get at the spec or body afterwards if your security settings 
are set to the defaults (and turned on - that's another story).

The inconsistency between R2's and R3's spec and body copying behavior 
during MAKE function! was an efficiency issue. The startup code of 
R3 uses a non-copying version of FUNC, and this speeds up startup 
quite a bit. However, the function builder mezzanines copy the spec 
and body, moving the copying behavior from the MAKE action to the 
mezzanine code - it's still about as fast because the actual copying 
is done by the same native code. As a side benefit, we get a bit 
more flexibility when we need it, especially when you don't leak 
references to the original spec and body that were passed to the 
MAKE action. MAKE module! does the same non-copying behavior for 
the same reason, though MODULE doesn't make a copy because the body 
is generally even bigger, and is not saved at all in the constructed 
module.

The main built-in function that takes advantage of the flexibility 
is FUNCT, which copies the spec and body before it does its collection 
of locals and binding to the static local object. In R2, the spec 
and body are copied again after that by the MAKE action, doubling 
the copying overhead. In R3, they aren't.

Is it possible to send command -line arguments to the new REBOL process 
using LAUNCH?
launch "test.r" ;this one works

launch "-s test.r" ;REBOL starts in TRACE ON mode (I don't know if 
%test.r will start or not, too much trace log to wait)

launch "--secure allow test.r" ;shows USAGE and doesn't start %test.r
launch "-q test.r" ; trace mode again.

I'm using R2 2.7.8.3.1

Not sure launch can do that, or if there was not related any bug. 
But - you might use CALL, it is now free ....

I standardized on using CALL some time back, as RUN and LAUNCH weren't 
available or consistent in all REBOL versions. system/options/boot 
makes using CALL easy for LAUNCH-like behavior.

@Pekr - @Gregg: Thank you. For encapped files, system/options/boot 
points to encapped .exe right?