World: r3wp

An issue raised by Joe in Core group 26-Nov-2006:
	launch {my-script.r param}

Joe wanted param to be parsed out and appear in system/script/args, 
however, it looks like instead the whole string is converted to a 
file and rebol tries to DO it.

Hmm.. there seem to be a few other LAUNCH issues in the Rambo database. 
I guess it's not as important as it used to be, now we have CALL.

Did he try the /as-is refinement to launch? That should solve the 
problem.

i just tried launch/as-is %t.r test   -- where t.r prints the args 
and it doesn't work !!

Did you try:
    launch/as-is {%t.r test}

After trying it myself, I get "Script Error: Feature not available 
in this REBOL". Is /as-is SD_-specific?

hmm, /as-is could be a /Link thing maybe.

I've never seen documentation for LAUNCH.

http://www.rebol.com/docs/words/wlaunch.html

Yes I have.

Nope, that page doesn't explain that error message, and the /as-is 
refinement doesn't say "reserved" like some of the others. So, launch 
is still undocumented.

Hmm, so is it worth posting a ticket (given that CALL is for free 
?) I suppose we still need LAUNCH for some of those options...

I guess I should post a ticket asking for clarification of LAUNCH 
options, especially argument handling.

Well, the advantage to launch is that it knows where to find the 
REBOL executable, so you don't need to hard-code that in your scripts. 
That is enough of an advantage to me over call to make this worth 
complaining about.

Doesn't system/options/boot let you find the rebol executable?

It does, but I guess it's still handy not to have to put that detail 
in.

Ok, so I'll be putting in a rambo entry.

Wow, when did they add that system option? The things I miss...

Anton: I thinl you're right to add it to rambo

Brian: It's in Core 2.5.6 so I'd guess it was some time ago.

Showing my age again, I suppose :)

launch uses system/options/boot (so, it was there as long as launch 
;)

so, is launch just a short hand form of call ?

I don't think so, their different refinements seem to indicate they 
have different usages.

Ok, submitted a ticket.

short hand, yes.but also,  not blocked by security. since  you can 
only launch rebol-scripts.

I also recall reading that a launched script cannot launch a script 
of its own.  something about preventing scripts from the desktop 
to launch other scripts, as a security measure, IIRC.

That restriction was removed fairly recently (about a year ago ?).

eeek... make date allows 0 values !

>> make date! [0 0 0]
== 30-Nov-65535
>> make date! [0 0 1]
== 30-Nov-0000
>> make date! [75 0 1]
== 13-Feb-0001
>> make date! [01 0 75]
== 1-Dec-0074


sorry, but these make dates are just funny. 0 becomes a negative 
offset in time in some instances... like the last.  should I RAMBO 
this?  I would expect make date to accept only one 0 value, being 
the year... any other 0 makes no sense.

btw, I looked and didn't find this strange behaviour being notified 
on RAMBO...

Negative offsets can actually be very useful, when creating relative 
dates. The thing I don't like about the zero behavior is that it's 
non-intuitive. i.e. using zero produces a negative result, where 
you would think -1 would be what you want to use. Other than that, 
it's just something to be aware of, not a bug IMO.

Reading existing http url returns just empty string if exists? function 
is called on non existing url before - Rebol/View (1.3.2.3.1) Is 
this know bug?

>> system/version
== 1.3.2.3.1
>> exists? http://www.rebol.com/donwload/rebol3.exe
connecting to: www.rebol.com
== false
>> print read http://www.rebol.com/
connecting to: www.rebol.com

>>

oh.... you've just stumbled on something which might be related to 
something I  discovered last week on command!


but strangely, this is new behaviour for me... so it might be related 
to server swap. and the fact that now, an URL does not exist anymore! 
 you might just have resolved a clueless issue.  especially since 
the exists? command seemed to work on new console issues.  


I will make other tests and confirm is I just discovered the same 
bug than you!

(ignore "issues"  word above)

it's already fixed: http://www.rebol.net/cgi-bin/rambo.r?id=4039&

but btw... in my bug (which might or not be the same) it does not 
only corrupt the http protocol... the whole exists? cmd is down, 
since I am testing files in my case!

have you tried the same thing in 2.7?

Oldes, you're a year late with that bug report :)

Ok... now I don't know, what is worst - if I'm late or the fix is 
late?

Isn't it fixed??

I think he meant... its not in 1.3.2 release

well, it's likely to be a mezzanine .. ?

exists? is, we'd have to look closer to see if this can be applied... 
the port stuff itself is not always trivial to patch...

the fix for that is what "caused" the read/binary bug in 2.7. (rather 
than "caused", it exposed a native bug when calling handler functions.)

Regarding #3867 "feel/detect event/face should be target face, not 
face" 
http://www.rebol.net/cgi-bin/rambo.r?id=3867

I realised when mimicking the behaviour of DO EVENT, that the reason 
the target face is not given is because its impossible to know at 
the time DETECT is called. Events travel down through the face hierarchy 
through the DETECT functions, the evaluation of which could have 
an effect on the result. The DETECT function can block events or 
allow them through, depending on the result they return, which is 
programmable and therefore dynamic. So a DETECT function higher up 
in the face hierarchy which is evaluated before a DETECT lower in 
the face hierarchy cannot know which is the target-face, because 
the result of the lower DETECT may change the target-face.

Therefore, I now see this as either a major design issue or a documentation 
error requiring some clarification. I don't think it is likely to 
be implemented (not in R2, anyway) because that would probably require 
an overhaul of the event system, and would likely break a lot of 
stuff.

The question is: do we want determinism or dynamism in this case 
? :-/

I think we don't want to lose dynamism.

In most cases it is sufficient to know which face is under the mouse 
cursor at the time of the detect event. Coded as a mezz this is pretty 
slow.