World: r3wp

(so I saw it as a kind of debugging help)

but that depends where the "" comes from... your human sense sees 
this as a bug, but an algorythm merging a set of series of abstract 
types would not...  ;-)

well, if that algorithm really *needs* the string to occupy just 
one "place" in another string, then it may contain a bug, which may 
be revealed by testing, but not by evaluating this suspicious code

(Ladislav is the one thinking this to be suspicious ;-)  I have a 
merge func which could not care less, all it wants is to make sure 
that equal things get inserted equaly, string into string, blocks 
into blocks...  so in that sense, the above is not suspicious at 
all.  but if only reacted differently for string, then I'd have to 
add an ugly escape route for that case ;-)

But if  /ONLY reacted ...

but if you really want to do what you said, then you probably don't 
use the /only refinement, do you?

(just curious)

back later... off to lunch !

(well that was diner actually... but anyways ;-)

yes, cause I don't want merge to insert the content of the block 
which is being merged, I want it to merge the block itself... (if 
that is what is submitted) ex:


[ 1 2 3 ] [["one"] ["two"] ["three"]]  == [ 1 ["one"] 2 ["two"]  
3 ["three"]]

I see both possible behaviours balanced close to equally, except 
that keeping the "loose" behaviour is already here and has the benefit 
of not needing any changes.

this behaviour of tags differs from string behaviour:

    a: <0> 
    b: make tag! 0 
    insert b a 
    a == b ; == false

do you like it?

hum good catch. internally tags can hold other types, but I think 
it should be converted to string... for consistencie's sake.

>> a
== <0>
>> b
== <<0>>

>> insert b 1.000000
== <<0>>
>> b
== <1.0<0>>

Ok for me. datatype is translated to string, a tagto"<something>". 
and then inserted.

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)