World: r3wp

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

makes problems with prebol and friends

Doesn't do that on windows -- so definitely a cross-platform problem.

posted it to rambo

;Rebol is gong into limbo with this code. I don't think it should 
happen.
parse {my infinte parse loop} [any [string!]]

The interpreter stops respondin and start consuming a lot of cpu 
cycles.

Don't know about regular apps, but in the console I can interrupt 
that with the Escape key (as of 1.3)

whoa - doesn't let go of the memory, though. I ended up getting a 
Virtual Memory warning from Windows after doing that a few times. 
Memory consumption went down as soon as I quit the Rebol console.

Is there any knowledge when the Problem with open/direct will be 
fixed or what prio this has at RT? I already asked in the Mailinglist 
but got no answer. There was only mentioned that in one Beta it might 
be fixed.  The thing that i always don't understand with Software 
vendors of all kinds is that they always focus more on new features 
than on stability and perfectly working already built in features