World: r3wp

definitely not being saved

I'm suspecting a file lock problem, but if it was locked, one would 
think that REBOL would return an error on write.

Yeah I think it would.

is some lines writing while others aren't?

yes, it's always the same lines

Change the order of the lines and see if the same lines fail.

I was wondering why there was a "black hole" in the log where I expected 
something important to happen.

Maybe even number them to see if there is a pattern to what lines 
are not being saved.

good idea

ah

the 11th commandment: thou shalt not change-dir in the middle of 
a file save. :-)

lol

its always something simple like that.

and so easy to overlook. I'm glad that WRITE was innocent and just 
doing its job.

Me also.

perfect. bug fixed.

woohoo!

now I can look at the bug I was originally going to fix...

are there any limitations for renaming dirs? I keep getting access 
error, whenever I try it on OSX even when the permissions are 777.

and I'm sure the dir is not in use, since I can delete it just fine

never mind figured it out

interesting. the help states that the target must not be a path and 
that the function can't be used to move files, but if I supply a 
relative path as target as part of the new name, the file is in fact 
moved to the target under the new name. is that intentional?

sorry, forgot to say, it's the RENAME function

I don't know the answer, Henrik, but since you mention it, I really 
think that the act of moving a file should be invoked by a function 
named something like "MOVE" or "MOVE-FILE", regardless of whether 
its implementation in the OS is by a "rename" function.

Anton, I haven't tested it under Windows though, so it could be a 
Linux/OSX side effect since rename usually equals move here.

Yes, POSIX rename can do moves:
http://en.wikipedia.org/wiki/Rename_(C)

but I agree that a rename should behave identically under all OSes 
and that move should be a separate function.

Post it as a question for Carl. I imagine it's an implementation 
side effect.

I think I know what the trouble is - it's not easy to know whether 
a host OS rename can support move or not. Therefore rebol can't choose 
beforehand between rename and copy+delete.

A workaround to that might be to try the rename first and see if 
it works (does not return an error message), but that adds complexity 
and performance problems. It could be done once at rebol startup 
in a temp directory, though it still seems a bit messy.

(The real solution seems to be to go back in time and define POSIX 
rename and move properly.)

anyone have an idea on when and why exactly system/options/script 
is none? I'm running a simple script in OSX, and it seems to always 
return none.

It is none when you are running at the top level interpreter.

In theory, it shouldn't be none during the running of a script.

not sure I understand why that is so

well, it is none here in my tests. rather useless, I think.

When you are running the REBOL interpreter straight, you are not 
running a script, so it is none. This can be useful to know.

by straight, you mean, I'm typing system/options/script in the console? 
because that's not what I'm doing. I'm running a script that probes 
that path and it returns none.

or do you mean, it returns none, when you say "do %script.r" ?

rather than "rebol -qs script.r"?

Yes.

You probably want to be looking at system/script instead.

system/script doesn't tell the name of the script.

I had hoped to be at any time able to identify the running script 
by filename

I believe that is what the file: header field is for.

the trouble is that the header information may not be correct

and File: also says none

You set the File: header in the script. For that matter, since the 
check of the script settings is specific to the currently running 
script, you have to add them to the script anyways, so why not correct 
the header while you're at it?

Another interesting one is the Content: header. Try this script:
REBOL [content: true] print mold system/script

still returns none.

but my issue is that I have over 100 scripts for this project. there 
might be an error in one of them, if I forget changing the header 
when cloning a script. If it really is impossible for rebol to determine 
the script name (which I highly doubt), then so be it, but it's inconvenient 
not to have the script name available at all times.

I said Content: would be interesting, not that it would solve your 
problem.