World: r3wp

Keep in mind that the words local to a function's context are only 
really valid during the execution of the function. When referred 
to from outside the function, their bindings are valid but their 
assigned values are not, and will be overridden on next run.

This is even more the case in R3.

Much of the code in Ladislav's article wouldn't work in R3, because 
of the changes in functions and the different reflective accessors.

thanks Anton, I had tried that but I want to do something a bit differently. 
 I want to set a functions /local word instead of its arguments.

It's the same method; all of the words (including the /local refinement) 
in the following function spec are local to the function's context:

	func [arg /local var]

I tried it Anton and it didn't work.  I'm trying from within the 
same function.

I'm going to investigate other possible ways of doing it wonce I 
get a chance.

Ok, but did you navigate to the local word properly ?

Yes, but what I think the problem is that I need to do the setting 
of the word from within.

Perhaps you can show us the actual function, and the code which tries 
to set the word. I know this is entirely possible, and especially 
so if you are the author of the function involved.

I'm debugging my debugger right now. For some reason it does not 
log certain lines of debug information. The method I use is:

write/binary/append %debug-file.r string


By probing it in console, I get the correct output, but the same 
lines are always missing in the disk version. Would there be any 
time this write would not occur?

Maybe the write is occurring but the 'string is not containing anything?

I will check again with another probe

those lines are just not saved

write/binary/append %debug-file.r probe string

will print the string in the console, but it's not saved

You confirmed that 'string contains data and not just ""

this can't be... there _has_ to be something else wrong :-)

yes, but I have to check some other things now too

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.