Well, perhaps not directly related to add_function_constant(). I've got some code that generates programs dynamically, and it uses add_function_constant() to add methods to the program. The first odd behavior is that these functions are callable without instantiating the object. That's actually a useful property for me, as I can emulate class methods, and access them at My.Class.somefunc(). The odd part is that if I have code that makes calls to these "class" methods, and I use low_cast_to_program() to get that code, the calls to My.Class.somefunc() get executed at compile time, but not when the code that uses them is called.
Example:
void somefunc() { object panel = Cocoa.NSOpenPanel.openPanel(); // this method is executed at compile time, and not when somefunc() is called.
panel->run(); // this seems to work anyhow, so panel must be a valid object. }
Can anyone explain this? I realize it's possible that I'm improperly using an unintended side effect, in which case I'd voice my support for class (Java-static) methods.
Bill
I've done a little more experimenting with this problem and have narrowed it down a bit. It seems like there might be an over-optimization, as the following code works properly:
void myfunc() { function f = Cocoa.NSOpenPanel.openPanel; object o = f(); }
whereas this code causes the openPanel function to be called during compile time, rather than when the function myfunc is actually called:
void myfunc() { object o = Cocoa.NSOpenPanel.openPanel(); }
Similarly, the backtrace at the time of the incorrect call to openPanel() looks something like this (non-relevant frames removed):
#9 0x0001aeb0 in apply_low_safe_and_stupid (o=0x18144a8, offset=71) at /Users/hww3/Pike/7.7/src/interpret.c:2384 #10 0x00105390 in eval_low (n=0x1892f30, print_error=0) at /Users/hww3/Pike/7.7/src/las.c:5692 #11 0x0010aad0 in eval (n=0x7f5018) at /Users/hww3/Pike/7.7/src/las.c:5765 #12 0x0011026c in optimize (n=0x1892f00) at /Users/hww3/Pike/7.7/src/las.c:5494 #13 0x00110980 in dooptcode (name=0x1892f30, n=0x1892f00, type=0x47, modifiers=7361024) at /Users/hww3/Pike/7.7/src/las.c:5926 #14 0x00005ac8 in yyparse () at language.yacc:948 #15 0x000c6fbc in run_pass2 (c=0x1892f00) at /Users/hww3/Pike/7.7/src/program.c:6913 #16 0x000c7418 in compile (aprog=0x418, ahandler=0x219ca0, amajor=71, aminor=-1073751884, atarget=0x4, aplaceholder=0xbfffd8a8) at /Users/hww3/Pike/7.7/src/program.c:7127
I'm glad to try to work on solving this problem, but it's a little bit further down in the core than I'm accustomed, so I'll gladly take advice on this. So, anyone have any? :)
Bill
I've done a little more experimenting with this problem and have narrowed it down a bit. It seems like there might be an over-optimization, as the following code works properly:
void myfunc() { function f = Cocoa.NSOpenPanel.openPanel; object o = f(); }
whereas this code causes the openPanel function to be called during compile time, rather than when the function myfunc is actually called:
void myfunc() { object o = Cocoa.NSOpenPanel.openPanel(); }
Similarly, the backtrace at the time of the incorrect call to openPanel() looks something like this (non-relevant frames removed):
[...]
You probably want to declare the function as having OPT_SIDE_EFFECT.
I'm glad to try to work on solving this problem, but it's a little bit further down in the core than I'm accustomed, so I'll gladly take advice on this. So, anyone have any? :)
Bill
pike-devel@lists.lysator.liu.se
-
H. William Welliver III -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
hww3 ＠ Pike developers forum