World: r3wp

I found, that making my own version of LOAD in a context in another 
way worked:

>> c: context [print: "local" my-load: :load w: my-load print]
>> c/w
== local
>> type? c/w
== word!

But it doesn't work as Henrik would like in a REPEAT block:

>> a: [(i)]
== [(i)]
>> repeat i 5 [print i my-load: :load compose my-load mold/all a]
1
** Script Error: i has no value

Paul; you've read through the Ladislav articles?  tfunc and lfunc 
and his Bindology paper?   http://www.fm.tul.cz/~ladislav/rebol/

I have read a lot of his stuff but not sure I ever read this.  I'll 
take a look into it.  Thanks Brian.

Paul, you need to do something like this:
	parse a compose [set (first second :f ) integer!]

where f is a function, second :f gives you the function's body, and 
FIRST picks a local word which just happens to be in first position 
in the body block. You will have to change FIRST to whatever navigates 
to a local word.

Example, given a function:
	f: func [var][
		print var: 10
	]

then you will navigate to the 'var: set-word in the function body 
like so:
	second second :f
because 'var: is in second position, after the 'print word.

(it doesn't matter that it's a set-word and not a word, you can still 
set it and bind to it, etc)

We can test this:
	set second second :f 20
	get second second :f
	; == 20
	?? f
	f: func [var][
		print var: 10
	]

Notice the 10 value is still the same (we didn't touch it.) But we 
know the 'var: set-word is 20 thanks to our setting it above. If 
the function is now evaluated it will not stay that way, obviously.

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.