World: r3wp

So - if most ppl agree, that starting desktop and trying to connect 
to internet directly is good thing (with auto proxy detection it 
could be, without it it simply is not), then I want -i and --noinstall 
to skip Desktop launch phase - and that is what I am about to submit 
as a request, or as a bug report ...

I think you could launch rebol with the -sqw switches and don't have 
the above problem.

(Not sure though)

it does not work - desktop appears, imo -w is for windowless scripts, 
running in background ...

rebol your-script.r

in your case, rebol -i your-script.r

if this does not work, then it's a bug. otherwise, it's your wish, 
which may or may not taken into consideration.

but i'm not completely sure i understand your case. if you want to 
just launch a script, you should 1) launch the script like above, 
2) use the sdk to encap it so that you just have an exe. if you launch 
rebol by itself, it's obvious to me that it starts the desktop unless 
you have specified otherwise (user prefs).

I want to launch the scrip, without Desktop popping-up, if I use 
-i option, but that is not the case. I also want it to work, without 
choosing or not to install rebol first, simply on new computer, untouched 
by rebol yet ...

Also - once Desktop launches, it tries to connect to internet. As 
most users are behind proxy, I can bet they will be annoyed, because 
Rebol is completly blocked and does not react to system buttons, 
you can't even shut down the app...

so, you're saying that rebol -i your-script.r does not work?

no, it starts desktop ...

it might be related to this problem: http://www.rebol.net/cgi-bin/rambo.r?id=3842&

yes, maybe so, but I don't need to use --do, do I? At least according 
to what 'usage output shows me in console. Just try to uninstall 
rebol and try to type rebol.exe my-script.r in OS console .... desktop 
will pop-up.

it would not be so denerving, if I could imediatelly shut down desktop, 
but it blocks and it feels like hours ;-) We should do something 
about that too. Either we learn how to read proxy settings properly, 
or don't try to connect to internet by default!

i think this is just a bug in the desktop startup code.

it should not start the desktop if you provide a script in the command 
line.

OK, that is what I tried to say - should I fill-in RAMBO entry? :-)

write-net ? i need my callback on writing operations too ! just like 
read can i've this cookie ?

The only callbacks i know are by using async. Gabriele and Romano 
have protocolls to do that.

all 'read based functions are weak - they are not async ...

using link and 1.3 on linux, workaround: export HOME=/home/volker/ios 
. solves the .rebol-nameclash and works.

I found one GC problem:

g: does [o/f: does [recycle print "o/f"] o/f]
o: make object! [f: does [g print mold disarm try [1 / 0]]]

now doing:

    o/f

reliably crashes the interpreter

posted under name: "GC Crash - Object&Function"

simplification:

o: make object! [f: does [g print "version 1"]]
g: does [o/f: does [print "version 2"] recycle]
o/f

this looks like being enough too:

f: does [g print "version 1"]
g: does [f: does [print "version 2"] recycle]
f

or shorter:

f: does [g print "version 1"]
g: does [unset 'f recycle]
f

the crash observed in Linux View 1.3 too

...and under OpenBSD

the problem can be "circumvented" as follows:

f: does [g print "version 1"]
g: does [unset 'f recycle]

doer: func [f [function!]] [f]
doer :f

Nice work Ladislav.

Cool reduced. I have that bug sometimes when redoing scriptsbut never 
nailed it really. Never thought to use recyle. my workaround:  f: 
func[][dont-gc-me: :f reload-me]

There is a problem with the issue! type. It doesn't accept the slash 
character as the example in the rebol core manual says.

>> value: #MG82/32-7
== /32-7
>> probe value
#MG82
== #MG82 ;; It droped the 32-7 part.

regarding the above GC crash (and to Volker): I think, that the best 
workaround is

    do :f

instead of just 

    f

Eeks. should this happen?
  echo -e "these are\nsome words" | rebol -q scratch.r
the script contains an error, an undefined word bang
** Script Error: bang has no value
** Near: bang
** Script Error: these has no value
** Near: these are
** Script Error: some has no value
** Near: some words

input is executed. its clear, there is an error, so go to console 
for input. but this time the console is data. maybe with pipes that 
should be changed?

workaround is: run as cgi, rebol -qc . but this is easy to overlook.

if you look in svv/vid-feel, you can see many of the 
OVER functions have arguments like:

	over: func [face action event] ...

but according to old feel doc, they should better be:

	over: func [face action position]

or according to new view system doc:

	over: func [face into position]


This is to avoid misleading error messages such as:   ** Script Error: 
over is missing its event argument

Should I post a report ?

Yes please. These may not be "errors" in and of themselves, but such 
inconsistencies have a ripple effect as you've identified that make 
REBOL harder to use / understand (especially when compounded with 
other inconsistencies). BTW, the other inconsistency I've noted in 
the past in this area is the use of "face action" versus "face act" 
versus "f a" in some places. It would be nice (if not already so) 
if this was sorted out.

Ok, posted it. But on consideration of the issue of abbreviated argument 
names, I don't feel strongly enough that it's so bad. In some cases 
it looks justified to abbreviate FACE to F, like when there are a 
gazillion references to the face. In some cases, the arguments are 
only used once each so there's not much advantage in abbreviating 
them (but they are anyway).

It depends ... if you know enough about Rebol, then "over is missing 
its 'p argument" may be enough. 

On the other hand, if you are just starting, then 'position may help 
you more ...

on linux:
!>load probe mold load "1e-50"
1E-50.0
** Syntax Error: Invalid decimal -- 1E-50.0
** Near: (line 1) 1E-50.0