World: r3wp

;-) Thats something I never ued befor, I always thought that was 
for the use of nested blocks... Thanks !

Mmmmmm "/deep - Also copies series values within the block."  I cant 
say thats a realy clear eplenation ;-) never the less it works...

It is the most precise explanation.

Icarii, you can probably use bitsets for what you want. I did some 
bitset math stuff a while back, so Maarten could do 160-bit checksums 
(IIRC).

How about "Recursively copies series! values within the block." ?

That would be the most precise explanation.

unfortunately, it doesn't copy all series:
>> a: ["aa"]
== ["aa"]
>> b: copy/deep a
== ["aa"]
>> same? first a first b
== false

ah, sorry, actually, it did, in this case

yes its strange actualy to find this function under copy... I would 
expect a name like copy/static or someting..but whats in the name 
;-)

rebolinth, well, copy copies. copy/deep copies deeply. /static makes 
me think of the opposite (what does copy/static mean???)

hi, I want to call a rebol script in a separate process and pass 
parameters e.g.  launch {c:\script.r param} but does not set  system/script/args

what am i doing wrong ?

Ladislav, if a: 1x2 a/(a: 3x4 1): (a: 5x6 7) resulting in 7x2 is 
more than 2 times faster than the post-check method resulting in 
7x6, then that is a very good argument to have it that way. Anyway 
your example is something, that should be avoided (if you're a good 
developer, I guess), so speed is better than a "more natural" result. 
That's my view.

yes, but the crash can (and should) be eliminated

if it results in 7x2, does it mean that 'a in paren! is local?

(half-jokingly)

I think, that it really needs an explanation.

* The 7x2 evaluation can work as follows: 

1) the interpreter first sets its Path-start variable to 1x2 and 
its Path-variable to 'a

2) the evaluation of the paren changes the A variable, but that does 
not influence the interpreter Path-start variable, so the path will 
be evaluated as Path-start/1:

3) the argument is evaluated, which changes the A variable again, 
but not the Path-start. The argument value is 7
4) Path-start/1: 7 is evaluated, which yields Path-start = 7x2

5) The variable A is set to the new value of the Path-start variable


The same algorithm can be used for longer paths too and we do not 
have to remember the complete path - it always suffices to remember 
"where we are".


The 7x6 evaluation cannot work like that, since we never know "where 
we are" - the Path start can change anytime, so we cannot "traverse" 
the path when evaluating parens. We need to "rebuild the path" evaluating 
all parens and remembering all intermediate results. Only when done 
and when the argument is evaluated, we can start to traverse the 
rebuilt path knowing the Path start.

Joe, I can't get it to work either. It looks like LAUNCH always just 
converts its VALUE argument to a file and then tries to do it.

Anyone else ? Is this a RAMBOable offence ?

iskata: I  agree, the word "recursive" makes it more explicit or 
obvious.

I don't think we're about to change the spelling of COPY/DEEP.  "deep" 
is pretty good.

yess I meant the string doc.

if the string docs emphasizes the deep word, right now its not as 
obvious what deep implies.

Oh ok.

how can rebol be made to understand UNC filenames... currently, I 
can't seem to use %//host/  to list shares.  :-(

rebol replaces %// as the root of curent dir... such that %//host/ 
 becomes %/C/host/   for example  :-(

%/host/  ?

nope

%/host/shared/  works...  but  I want to list those shares?  just 
as listing %/ does for local drives

what happens if you change-dir to %/host/shared/  then change-dir 
to %..  ?

I was processing a Chinese text file using REBOL. The text file was 
in the Big5 Encoding, which is the de facto encoding we use in Taiwan. 
A Big5 character needs two bytes, so I used strings whose length 
is 2 to present Big5 characters. 


Something weird happened. After a while, I realized that REBOL treated 
two different characters as they were the same character.


Chinese-char1: to-string #{A4 68} ; Big5 Char for "Educated Person"
Chinese-char2: to-string #{A4 48} ; Big5 Char for "Human"

if Chinese-char1 = Chinese-char2 [
    print "This cannot not be happening..."
]
How would I fix my REBOL scrip? Thank you.

>> strict-equal? probe to-string join #{a4} #{68} probe to-string 
join #{a4} #{48}
¤h
¤H
== false

Sqlab, thank you.

= is case insensitive, but that only works with latin1. you should 
use binary!, not string!, to avoid any problems.

Is there any way that I could detect whether the Num Lock or the 
Caps Lock is on?

Not in Core ;-) and I from using Gabriele's keycode onle-line displayer 


view layout [box feel [engage: func [f a e] [switch a [up [focus 
f] key [print mold e/key]]]]]


It looks as though Rebol doesn't provide an event when Caps Lock 
is pressed or released.

I read here : http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-topic-index.r?i=k

It is possible to get keycodes(at least under Windows) even in Rebol/Core:

system-awake: func [port /local msg][
	msg: pick port 1
	print [
		switch msg/2 reduce [
			WM_KEYDOWN ["key down"]
			WM_KEYUP ["key up"]
		]
		"keycode:" msg/3
		"char:" mold to-char msg/3
	]
	return false
]

WM_KEYDOWN: 256
WM_KEYUP: 257

system/ports/system: open [scheme: 'system]
system/ports/system/awake: :system-awake

set-modes system/ports/system compose/deep [winmsg: [(WM_KEYDOWN) 
(WM_KEYUP)]]
append system/ports/wait-list system/ports/system

wait []

as you can see it is possible to catch also KEYUP events in Windows. 
What a pity system port has a bug under View so it works only when 
console window is activated.

Thanks for the enlightenment, Cyphre

Cyphre - so why not to fix that system port bug?! That would be nice, 
as old (pre R3) SDK could have fixed that bug

I have already posted the bug into RAMBO so it depends on Carl's 
decission now.

will system port exist in R3, or it will be done in other way?

You need to ask Carl, but I think system port should be in R3 too.

Can somebody explain to me, how does FIND work in file! ?

>> path: %/disk/drawer/
== %/disk/drawer/
>> file: %/disk/drawer/file
== %/disk/drawer/file
>> find/match file path
== %file
>> find/match file %/disk
== %/drawer/file
>> find/match file %/disk/
== %drawer/file
>> find/match file %disk/
== none
>> find/match file %drawer
== none


It seems to work only if the searched string stars on begining of 
file!

That's right, the /MATCH refinement causes exact matching to occur 
from the position you specify (eg. the start). I was a bit confused 
by this at first too. What you probably want is the /ANY refinement, 
which switches on wildcards. So use /ANY instead of /MATCH and you'll 
be alright.

There's nothing special about FIND's treatment of FILE! datatype 
here. It's just another any-string!

I'm using /MATCH because I want to strip part of path. I'll probably 
make parse rule for it :/

Ah.. maybe you want FIND/ANY/TAIL