World: r3wp

The revised mezz-series.r (relative to the 2.7.8 SDK source) is in 
R3 chat #8008 - that's the number of the particular version, which 
you can see by going to #41 (R2/Mezzanines) and doing a LF command.

these numbers are like the memory locations in home computers... 
spectrum, c64 (i didn't have an amiga..) in DOS 8000 was the HDD 
bios start, i think..

The chat interface uses numbers as a deliberate design choice because 
it is easier to memorize and refer to a number than it is to a path 
or message ID. You can even write a message number in #8008 form 
in another message and it can be followed like a hyperlink to the 
message of that number. You can also do the hyperlink trich to CureCode 
tickets using the bug#539 form, which will take you to http://issue.cc/r3/539
(that R3 bug I mentioned above).

Anyone have this ? http://www.fm.tul.cz/~ladislav/rebol/peekpoke.r

It's not on Ladislav's site anymore at that url

Is there a point in allowing refinements like this?

/1a

REBOL also allow decimal! refinements like:

/1.2

but treat it like an integer refinement.


Some further thoughts: Can refinements be categorized in two groups, 
integer refinements and word refinements? If yes, then the refinement 
datatype maybe should be two different datatypes?

Hm, maybe what I call integer refinements shouldn't be allowed at 
all, as I see no point in them. I can't get the desired path using 
integer refinements as in:

>> to-path [blk /2]
== blk//2

The correct way is:

>> to-path [blk 2]
== blk/2

So if integer refinements are useless, what's the point?

John, I'm not sure I understand. Aren't you confusing path with refinement?

No, they're different. I know. You can use refinements to build paths, 
else refinements are used in functions. REBOL allow what I call integer 
refinements, as the scanner doesn't give error. I ask why is that?

Or, maybe we can't actually use refinements to build paths, now I 
think of it. :-)

I can cook it down to: Why would REBOL allow refinements like:

/1
/1a
/1.2


My guess is, it's a side effect of how the scanner handle paths with 
integers, like: blk/1

So shouldn't refinements have the same rules as words, like the core 
manual suggest?

Ah, now I understand. It's probably a "bug" in scanner.

Because those refinements are allowed, you can write:

f: func [/2] [ ... ]

But that kinda makes no sense.

No kidden, people get confused:

>> f: func [/2] [if 2 [print "It's 2!"]]
>> f
It's 2!
>> f/2
It's 2!

I can even write

>> f/3
It's 2!

In R3, at least we get:

>> f: func [/2] [if 2 [print "It's 2!"]]
>> f
It's 2!
>> f/2
** Script error: incompatible refinement: 2

But the refinement is still valid.

Graham, see:

http://www.fm.tul.cz/~ladislav/rebol/library-utils.r

I'm having problems renaming a file on a USB stick with R2 under 
Windows. It reports "cannot access". R3 does not have this problem. 
Can anyone reproduce this?

I did this under OS X with R2:

>> write %/Volumes/NICOM/test.txt "Testing..."
(and the files was produced, then)
>> rename %/Volumes/NICOM/test.txt %/Volumes/NICOM/test2.txt
** Access Error: Cannot rename test.txt

So an error.

With R3, it works here.

ok, that is interesting. possibly file system related?

Possibly, as rename works on HD in R2.

the mezz source says that if the file is not found, then it can't 
be accessed.

Henrik, I have no problem with renaming a file on USB stick...tested 
under WindowsXP SP3

Henrik, I can read the file with REBOL command READ in R2.

perhaps it's a timing issue?

it works, if I open the port and find the file by hand

>> read %/f/
== [%data %KeePass/ %TrueCrypt/ %autorun.inf %test.r]
>> rename %/f/test.r %test2.r
>> read %/f/
== [%data %KeePass/ %TrueCrypt/ %autorun.inf %test2.r]
>>

RENAME uses OPEN, not READ.

Seems like, it's the CHANGE command, that rename it.

Reading the source for RENAME, it rename the file by changing its 
name in the directory file. And this doesn't work for some reason 
with USB sticks under OS X using R2.

it does not work for me under Windows either. seems like a port bug.

Cyphre, did you test with R2 or R3?

and yes, it is at the CHANGE on the port, that fails.

I tested with R2...no problems here. Henrik, maybe it has something 
to do with the fact you are emulating the Windows under OSX?

the CHANGE works, if I do it by hand. Then I can rename the file.

Cyphre, Robert reported this from a customer, who I assume is running 
Windows natively.

hmm, hard to say then.

testing one more timing issue...

does not help with timing, but I can still perform CHANGE outside 
the rename function

It works, if you don't give NEW as full path.

I see... testing that

that's how the HELP is telling you ;)

new -- new name (not a path)

:) funny it works on HD though.

Are you suggesting "RTFM!" ? ;)

ok, thanks... testing fix.

LOL, well, I remember I have been bitten by this many years ago so 
from that time I'm using it according to the help ;)

my excuse is that I could not probe the input values for RENAME :-) 
but true, this should not be standard behavior.

Best solution is probably, that it should just work with both ways.

rename capabilities in file handling do not normally allow paths 
to be used (in the OS itself).  otherwise these are a called 'move 
file operations. 


e.g. if you try using paths with rename in the DOS shell, you get 
errors.