r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

btiffin
9-Apr-2008
[10217]
Paul; you've read through the Ladislav articles?  tfunc and lfunc 
and his Bindology paper?   http://www.fm.tul.cz/~ladislav/rebol/
[unknown: 5]
9-Apr-2008
[10218]
I have read a lot of his stuff but not sure I ever read this.  I'll 
take a look into it.  Thanks Brian.
Anton
10-Apr-2008
[10219x2]
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.
BrianH
11-Apr-2008
[10221x3]
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.
[unknown: 5]
11-Apr-2008
[10224]
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.
Anton
12-Apr-2008
[10225]
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]
[unknown: 5]
12-Apr-2008
[10226x2]
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.
Anton
12-Apr-2008
[10228]
Ok, but did you navigate to the local word properly ?
[unknown: 5]
12-Apr-2008
[10229]
Yes, but what I think the problem is that I need to do the setting 
of the word from within.
Anton
12-Apr-2008
[10230]
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.
Henrik
17-Apr-2008
[10231]
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?
[unknown: 5]
17-Apr-2008
[10232]
Maybe the write is occurring but the 'string is not containing anything?
Henrik
17-Apr-2008
[10233x3]
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
[unknown: 5]
17-Apr-2008
[10236]
You confirmed that 'string contains data and not just ""
Henrik
17-Apr-2008
[10237x4]
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.
[unknown: 5]
17-Apr-2008
[10241x2]
Yeah I think it would.
is some lines writing while others aren't?
Henrik
17-Apr-2008
[10243]
yes, it's always the same lines
[unknown: 5]
17-Apr-2008
[10244]
Change the order of the lines and see if the same lines fail.
Henrik
17-Apr-2008
[10245]
I was wondering why there was a "black hole" in the log where I expected 
something important to happen.
[unknown: 5]
17-Apr-2008
[10246]
Maybe even number them to see if there is a pattern to what lines 
are not being saved.
Henrik
17-Apr-2008
[10247x3]
good idea
ah
the 11th commandment: thou shalt not change-dir in the middle of 
a file save. :-)
[unknown: 5]
17-Apr-2008
[10250x2]
lol
its always something simple like that.
Henrik
17-Apr-2008
[10252]
and so easy to overlook. I'm glad that WRITE was innocent and just 
doing its job.
[unknown: 5]
17-Apr-2008
[10253]
Me also.
Henrik
17-Apr-2008
[10254]
perfect. bug fixed.
[unknown: 5]
17-Apr-2008
[10255]
woohoo!
Henrik
17-Apr-2008
[10256]
now I can look at the bug I was originally going to fix...
Henrik
21-Apr-2008
[10257x5]
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
Anton
21-Apr-2008
[10262]
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.
Henrik
21-Apr-2008
[10263]
Anton, I haven't tested it under Windows though, so it could be a 
Linux/OSX side effect since rename usually equals move here.
Anton
21-Apr-2008
[10264]
Yes, POSIX rename can do moves:
http://en.wikipedia.org/wiki/Rename_(C)
Henrik
21-Apr-2008
[10265]
but I agree that a rename should behave identically under all OSes 
and that move should be a separate function.
Gregg
21-Apr-2008
[10266]
Post it as a question for Carl. I imagine it's an implementation 
side effect.