World: r3wp

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?

Yes.

In cases where I need to launch REBOL from encapped, I have included 
config options; sometimes on a per-command basis, so I can launch 
a specific version of REBOL for different needs.

You put rebol.exe into your encapped file? Or into the same folder?
And how do you put license.key to enable /Pro features?

you don't need key if encapped.

I haven't done that for commercial products where I would have to 
redistribute REBOL; only systems where the environment is controlled 
and REBOL is in use/licensed.

Ok, now I see.

If I have a encapped script and need to launch a new REBOL process 
to execute another script (not encapped), is it the correct way, 
CALL my exe with a command-line argument to execute the other script?

I want to declare a function with several rafinments by only one 
can be selected :
myfunc: func [/r1 /r2] [...]
myfunc/f1 or myfunc/f2
I don't want to allow : myfunc/f1/f2

That is not possible, but you can determine presedence of use in 
the function body, so the outcome would be the same, or you could 
make an error, if both refinements are used.

>> a: func [/b /c] [if all [b c] [make error! "Only one refinement 
can be used."]]
>> a
== none
>> a/b
== none
>> a/c
== none
>> a/b/c
** User Error: Only one refinement can be used.
** Near: make error! "Only one refinement can be used."

Endo, launch with parameters stopped workng years ago.  So, we had 
to move to call instead

GrahamC: Thanks. I'll keep that in mind.

@Henrik : thanks a lot !

nve, there is a built-in error that might be better for you to use. 
Try this:
>> cause-error 'script 'bad-refines none
** script error: incompatible or invalid refinements

That error is apparently not in R2 though, sorry.

nve, there's TOO-MANY-REFINES in R2:

>> cause-error 'script 'too-many-refines none
** Script Error: Too many refinements

Is there a way to avoid conversion of numbers to scientific notation 
by mold?
>> mold 0.004
== "4E-3"


or have you a function to convert back a string representing a number 
with exponent to one eithout it?

eithout = without

You have to do it yourself.

Many people have examples and funcs out there for it.

http://www.rebol.org/view-script.r?script=format-decimal.r

I have a general FORMAT func I use, but it's quite heavy as it handles 
a lot of things.

Thanks. The one from Nick should be ok.

You can also check

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

I've also put a format-number function that I use on Checklists on 
Altme. It works well for me.
>> format-number 1 / 3
== "0.333333333333333"

Under Checklists / Code Snippets.

The function by Nick is a little slow since I have a lot of numbers. 
This is faster but not very fast:

format-decimal: func [x /local e q] [
	x: form x
    if find x "E-" [ 
		e: to-integer next next q: find x "E-"
		clear q
		remove find x "."
		if #"-" = first x [x: next x]
		insert/dup x "0" e
		insert next x "."
	]
	head x
]

The idea from Ladislav is nice but I would like most a more "rebol" 
solution.

Scientific notation of numbers and automatic reformating time! values 
(00:00:00 --> 0:00) are the most annoying parts of REBOL for me.
It would be more useful if it doesn't happen when FORMing.

Is there a possibility for cyrillic/Russian at Rebol/View except 
for pixelart drawing the characters?

In R3/View, but it's currently buggy and limited to Windows and Amiga

Since you'd have to switch languages anyway, you could also consider 
Red with the GTK+ binding

Uh. In Red, everything is possible with any bindings