World: r3wp

It should. It does on R3. Let me try it on R2.

Yup. On R3 it's slower though, sincee clean-path is mezz.

On R3 the fastest way is this: head clear find/tail next what-dir 
"/"

http://rebol.wik.is/Cheyenne/Upload-file.rsp

don't think I'll need UNC path support :)

I use it a lot :)

on a web server?

Nope - remote file manipulation. UNC paths are for Windows shares, 
not web shares.

Ratio is giving me good opportunities to sharpen my skills. While 
writing a post, I bumped into this:

http://www.rebol.org/view-script.r?script=substr.r

What do you think? :-)

From the script header: Purpose: "Working around string series"...I 
think that this is shooting yourself in the foot.

Don't you think this is a little inconsistent?

>> a: ""
== ""
>> a/1
== none
>> last a
** Script Error: Out of range or past end
** Near: last a
>>

IIRC, Carl explained (at least) once that this behaviour is different 
on purpose. Using path notation with an index value or PICK should 
return NONE while using the prefix notation FIRST, SECOND,...LAST 
should return an error. So you have the choice to either silently 
handle missing values in series or raise an error!.

In R3 it is consistent.

>> a: ""
== ""
>> a/1
== none
>> last a
== none

SYSTEM/SCHEMES/FTP/PASS is a none of value: none
  set-net ['abc]
  ? system/schemes/ftp/pass
SYSTEM/SCHEMES/FTP/PASS is a string of value: "abc"

the documentation says "The first value is your email address and 
it is used when sending email and connecting to FTP. This value is 
stored in the REBOL system object at: SYSTEM/USER/EMAIL".

I don't think it's a good idea that the ftp password will be set 
to the email address as well, "used when connecting to FTP" maybe 
it should set the user instead

that's the way it used to be done

the convention for anonymous FTP is to provide "anonymous" as the 
user and the email address as the password.

I am having a very hard time build a low-level function which reduces 
only bound words.

the bound? function is useless, it returns the global context when 
it hits a new word, cause it defines the word as it scans it.

value? doesn't see the word, only its label, which in parse rules 
collides heavily with standard rules.

any one can give me ideas?

unset? always returns false, cause it pretty much only matches non-returning 
functions like print, but you have to evaluate them to know, so its 
useless again.

so far this seems to be impossible to resolve in R2    >:-(

can you give an example of the expected result ?

false == (some magic trick) first load "[any]"
true == (same magic trick) first append [] in system/words 'any


the first is just an unbound word, using the string just makes this 
explicit beyond doubt.
the second is the actual word func. added to a block.

or are all words bound to the global context by default, making this 
impossible... as I think.

you mea, you want to construct a block with ANY unbound to a context 
?

maybe I can just do this :

same? bound? first load "[any]" system/words 

 and assume I'm not actually using global words in my blocks...

>> value? first to-block "any"
== false

in that exemple, ANY is not bound

let me check something... it might add to the confusion  :-)

to-block, do like LOAD, except it doesn't bound the words in the 
global context

>> do probe to-block "1 + 1"
[1 + 1]
** Script Error: + word has no context
** Near: 1 + 1

>> value? first to-block "[any {a}]"
== true

this is whacky

lol

>> value? first to-block "any {a}"
== false

I know... very broken.

No,  you must remove the brackets

but my data HAS inner blocks.

this is just plain dumb.

the result is of course correct ..

So, do a double first

>> value? first first to-block "[any {a}]"
== false

and? 'any is a word. It surely does not have a value. What are you 
wondering about?

pekr it aint. if to-block doesn't bind words... it just shouldn't 
.  how am I going to manage loading data from disk and hope it doesn't 
collide with some stray global word

but I realize that all words are bound.

Actually, to-block doesn't bound anything, what the problem so ?

ok, let me try something then.

In the old past days, 
to-block "[any]" was returning only one block.

It's returning a double block since some versions, never understood 
the interest of such change.
>> to-block "[any]"
== [[any]]