I just checked in a patch to Pike to get rid of that silly "Expected efun constan" in the logfile. The patch works, I'm just wondering if the patch doesn't have any other unexpected side-effects.
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
The loading is so much faster now, the memory usage is down, the logfiles are clean(er).
The logfiles are cleaner as long as those werrors aren't called...
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-03 02:43: Subject: Warnings from startup script
I just checked in a patch to Pike to get rid of that silly "Expected efun constan" in the logfile. The patch works, I'm just wondering if the patch doesn't have any other unexpected side-effects.
The loading is so much faster now, the memory usage is down, the logfiles are clean(er).
/ Stephen R. van den Berg
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
I tried to decypher the definition in interpret_functions_fixed.h I failed :-). Sorry, my knowledge of Pike internals is not enough (yet) to understand the implications.
The loading is so much faster now, the memory usage is down, the logfiles are clean(er).
The logfiles are cleaner as long as those werrors aren't called...
Ok, fair enough. I'll exercise some of these, and will let you know what happens.
The reasons why I suspect the change is correct anyway, is because: - We don't do anything funny in feeding the encoder/compiler. - All we feed it is: add_constant("werror", roxen_werror); which, when addressed from within another module as werror() produces the warning mentioned (and hence, the compiled object is discarded).
But, we'll see.
Stephen R. van den Berg wrote:
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
The logfiles are cleaner as long as those werrors aren't called...
Ok, fair enough. I'll exercise some of these, and will let you know what happens.
I tried it. You were right. It segfaults upon execution of the aliased werror. In the runtime-compiled version, it doesn't segfault. I'm not sure what this implies; that the static compiler is at fault here (indeed, the encode routine, most likely)?
The reasons why I suspect the change is correct anyway, is because:
- All we feed it is: add_constant("werror", roxen_werror);
I presume this still is correct (given that the run-time compiler works fine with it, I'd say yes). So, what needs to be fixed instead then?
Is werror added as the constant roxen_werror when the programs are compiled for dumping purposes as well?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 11:58: Subject: Re: Warnings from startup script
Stephen R. van den Berg wrote:
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
The logfiles are cleaner as long as those werrors aren't called...
Ok, fair enough. I'll exercise some of these, and will let you know what happens.
I tried it. You were right. It segfaults upon execution of the aliased werror. In the runtime-compiled version, it doesn't segfault. I'm not sure what this implies; that the static compiler is at fault here (indeed, the encode routine, most likely)?
The reasons why I suspect the change is correct anyway, is because:
- All we feed it is: add_constant("werror", roxen_werror);
I presume this still is correct (given that the run-time compiler works fine with it, I'd say yes). So, what needs to be fixed instead then? -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
The problem is that it's attempting to decode modules dumped at Pike install time with the wrong codec.
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-04 12:17: Subject: Re: Warnings from startup script
Is werror added as the constant roxen_werror when the programs are compiled for dumping purposes as well?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Please explain how the codec can fix this problem, which is that F_CALL_BUILTIN opcodes have been generated, although the function that should be called is not a builtin. This has to be fixed during the compilation phase, not the encode or decode phase, IMHO.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 12:21: Subject: Re: Warnings from startup script
The problem is that it's attempting to decode modules dumped at Pike install time with the wrong codec.
/ Henrik Grubbström (Lysator)
By providing a Codec that actually can manage to return the efun werror().
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-04 12:27: Subject: Re: Warnings from startup script
Please explain how the codec can fix this problem, which is that F_CALL_BUILTIN opcodes have been generated, although the function that should be called is not a builtin. This has to be fixed during the compilation phase, not the encode or decode phase, IMHO.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
But that's not the function that the code is supposed to use, if I understand the problem correctly.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 12:29: Subject: Re: Warnings from startup script
By providing a Codec that actually can manage to return the efun werror().
/ Henrik Grubbström (Lysator)
Stephen R. van den Berg wrote:
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
The logfiles are cleaner as long as those werrors aren't called...
Ok, fair enough. I'll exercise some of these, and will let you know what happens.
I tried it. You were right. It segfaults upon execution of the aliased werror.
The reason is that the compiler emits different code for true efuns than for regular functions (ie methods).
In the runtime-compiled version, it doesn't segfault.
Naturally, since you will get different byte code in that case.
I'm not sure what this implies; that the static compiler is at fault here (indeed, the encode routine, most likely)?
The reasons why I suspect the change is correct anyway, is because:
- All we feed it is: add_constant("werror", roxen_werror);
Yes, but you don't adapt the Codec to correct for the change.
I presume this still is correct (given that the run-time compiler works fine with it, I'd say yes). So, what needs to be fixed instead then?
You need to provide the codec with a way to find the true werror efun.
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-04 11:58: Subject: Re: Warnings from startup script
Stephen R. van den Berg wrote:
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
The logfiles are cleaner as long as those werrors aren't called...
Ok, fair enough. I'll exercise some of these, and will let you know what happens.
I tried it. You were right. It segfaults upon execution of the aliased werror. In the runtime-compiled version, it doesn't segfault. I'm not sure what this implies; that the static compiler is at fault here (indeed, the encode routine, most likely)?
The reasons why I suspect the change is correct anyway, is because:
- All we feed it is: add_constant("werror", roxen_werror);
I presume this still is correct (given that the run-time compiler works fine with it, I'd say yes). So, what needs to be fixed instead then? -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
How can the Codec affect whether F_CALL_BUILTIN or F_CALL_OTHER opcodes are generated by the compiler? When the Codec is called, the program is already compiled, no?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 12:19: Subject: Re: Warnings from startup script
Stephen R. van den Berg wrote:
The check is there for a reason...
Hint: Check the macro DO_CALL_BUILTIN in interpret_functions.h. What do you think happens if s->subtype isn't FUNCTION_BUILTIN?
The logfiles are cleaner as long as those werrors aren't called...
Ok, fair enough. I'll exercise some of these, and will let you know what happens.
I tried it. You were right. It segfaults upon execution of the aliased werror.
The reason is that the compiler emits different code for true efuns than for regular functions (ie methods).
In the runtime-compiled version, it doesn't segfault.
Naturally, since you will get different byte code in that case.
I'm not sure what this implies; that the static compiler is at fault here (indeed, the encode routine, most likely)?
The reasons why I suspect the change is correct anyway, is because:
- All we feed it is: add_constant("werror", roxen_werror);
Yes, but you don't adapt the Codec to correct for the change.
I presume this still is correct (given that the run-time compiler works fine with it, I'd say yes). So, what needs to be fixed instead then?
You need to provide the codec with a way to find the true werror efun.
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
/ Henrik Grubbström (Lysator)
Correct. The Codec thus has to provide efuns were there were efuns in the original.
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-04 12:24: Subject: Re: Warnings from startup script
How can the Codec affect whether F_CALL_BUILTIN or F_CALL_OTHER opcodes are generated by the compiler? When the Codec is called, the program is already compiled, no?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Please say "builtin" when you mean builtin. As I said before, the term "efun" now has a different meaning in many contexts, namely "a function in the global scope".
You're missing the point. The problem is not that the Codec does not provide a builtin. The problem is that it was a builtin in the original.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 12:27: Subject: Re: Warnings from startup script
Correct. The Codec thus has to provide efuns were there were efuns in the original.
/ Henrik Grubbström (Lysator)
True, another way to workaround the problem is to redump the program with the new definition of werror().
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-04 12:29: Subject: Re: Warnings from startup script
Please say "builtin" when you mean builtin. As I said before, the term "efun" now has a different meaning in many contexts, namely "a function in the global scope".
You're missing the point. The problem is not that the Codec does not provide a builtin. The problem is that it was a builtin in the original.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Recompile, rather. I wonder what differences in load order causes different werrors to be installed when compiling from source and when decoding dumps.
Still, load order is typically fragile, so fixing the codec is the robust approach. That requires a new lookup method for efuns, though.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 12:31: Subject: Re: Warnings from startup script
True, another way to workaround the problem is to redump the program with the new definition of werror().
/ Henrik Grubbström (Lysator)
Recompile, rather. I wonder what differences in load order causes different werrors to be installed when compiling from source and when decoding dumps.
The module already gets recompiled in the code that emits the warning. The change would be to dump the new module.
The main reason as I said earlier is that the modules were dumped during the *PIKE* install, and not by Roxens dumper.
Still, load order is typically fragile, so fixing the codec is the robust approach. That requires a new lookup method for efuns, though.
Well, detecting if something is a FUNCTION_BUILTIN is easy:
Pike v7.7 release 5 running Hilfe v3.5 (Incremental Pike Frontend)
functionp(werror);
(1) Result: 1
function_object(werror);
(2) Result: 0
werror || 0;
(3) Result: werror
cf:
object o = class { function foo(){} }(); function f = o->foo; functionp(f);
(4) Result: 1
function_object(f);
(5) Result: HilfeInput()->__class_65693_0_line_1()
destruct(o);
(6) Result: 0
functionp(f);
(7) Result: 0
function_object(f);
Bad argument 1 to function_object(). Expected function. Unknown program: function_object(0) HilfeInput:1: HilfeInput()->___HilfeWrapper()
f;
(8) Result: 0
/ Henrik Grubbström (Lysator)
Previous text:
2004-07-04 12:38: Subject: Re: Warnings from startup script
Recompile, rather. I wonder what differences in load order causes different werrors to be installed when compiling from source and when decoding dumps.
Still, load order is typically fragile, so fixing the codec is the robust approach. That requires a new lookup method for efuns, though.
/ Martin Stjernholm, Roxen IS
Ideally, modules dumped by Pike should be decoded by Pike's codec, not the Roxen one. Is there no support for switching codecs when resolving dependencies?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 12:50: Subject: Re: Warnings from startup script
Recompile, rather. I wonder what differences in load order causes different werrors to be installed when compiling from source and when decoding dumps.
The module already gets recompiled in the code that emits the warning. The change would be to dump the new module.
The main reason as I said earlier is that the modules were dumped during the *PIKE* install, and not by Roxens dumper.
Still, load order is typically fragile, so fixing the codec is the robust approach. That requires a new lookup method for efuns, though.
Well, detecting if something is a FUNCTION_BUILTIN is easy:
Pike v7.7 release 5 running Hilfe v3.5 (Incremental Pike Frontend)
functionp(werror);
(1) Result: 1
function_object(werror);
(2) Result: 0
werror || 0;
(3) Result: werror
cf:
object o = class { function foo(){} }(); function f = o->foo; functionp(f);
(4) Result: 1
function_object(f);
(5) Result: HilfeInput()->__class_65693_0_line_1()
destruct(o);
(6) Result: 0
functionp(f);
(7) Result: 0
function_object(f);
Bad argument 1 to function_object(). Expected function. Unknown program: function_object(0) HilfeInput:1: HilfeInput()->___HilfeWrapper()
f;
(8) Result: 0
/ Henrik Grubbström (Lysator)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Ideally, modules dumped by Pike should be decoded by Pike's codec, not the Roxen one. Is there no support for switching codecs when resolving dependencies?
I'm not sure that this will fix the problem.
As far as my limited understanding of the problem thus far can tell me: - werror() appears to be a Pike builtin function. - Therefore it compiles into a different bytecode especially reserved for builtins. - Therefore, dumping a module at Pike install time (because it's a Pike lib) will cause the bytecode for builtins to be used. - Hence, any attempt to cause werror() to be overloaded with a different function (roxen_werror()) just by changing the load/link order will fail miserably, since it then needs an opcode that addresses a user-defined function instead of a builtin. - But, since this is in a Pike lib, we do *not* want to have to redump the module using a different dumper or recompile it. Pike should be able to be preinstalled on a system where you add Roxen/ChiliMoon later.
So, IMO, the simplest solution would be to do what C does to solve this: Create a _werror() which is the actual builtin, then use a normal werror() definition which simply calls _werror() in the standard lib, and allow this werror() to be overridden by roxen_werror().
Or is this a wrong/too simplistic account of situation?
It will not fix the problem in itself, but it will make it the responsibility of the Pike codec to make sure that it produces the same entitity (i.e. the builtin werror()) as was encoded. A custom codec should not have to be 100% compatible with the Pike codec (that would be rather pointless, since then you could just use the Pike one) just to be able to encode/decode programs which depend on stuff dumped by Pike at installation.
Your "solution" would make all calls to builtins slower, I'm afraid.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 13:53: Subject: Re: Warnings from startup script
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Ideally, modules dumped by Pike should be decoded by Pike's codec, not the Roxen one. Is there no support for switching codecs when resolving dependencies?
I'm not sure that this will fix the problem.
As far as my limited understanding of the problem thus far can tell me:
- werror() appears to be a Pike builtin function.
- Therefore it compiles into a different bytecode especially reserved
for builtins.
- Therefore, dumping a module at Pike install time (because it's a Pike
lib) will cause the bytecode for builtins to be used.
- Hence, any attempt to cause werror() to be overloaded with a different
function (roxen_werror()) just by changing the load/link order will fail miserably, since it then needs an opcode that addresses a user-defined function instead of a builtin.
- But, since this is in a Pike lib, we do *not* want to have to redump the
module using a different dumper or recompile it. Pike should be able to be preinstalled on a system where you add Roxen/ChiliMoon later.
So, IMO, the simplest solution would be to do what C does to solve this: Create a _werror() which is the actual builtin, then use a normal werror() definition which simply calls _werror() in the standard lib, and allow this werror() to be overridden by roxen_werror().
Or is this a wrong/too simplistic account of situation?
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
So, IMO, the simplest solution would be to do what C does to solve this: Create a _werror() which is the actual builtin, then use a normal werror() definition which simply calls _werror() in the standard lib, and allow this werror() to be overridden by roxen_werror().
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Your "solution" would make all calls to builtins slower, I'm afraid.
Well, just the calls to werror(), which, as it happens, is a function which is only called in case of an error, and therefore, is timing uncritical. In general, there's almost no need to override Pike builtins used in the Pike libs. The only case, is exactly this one, the werror() builtin, which is overridden to allow the error output to be postformatted. IMO it's acceptable to slow this one done and make an exception.
I thought you were adressing the general problem, as opposed to ad-hockery for your special case.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 14:44: Subject: Re: Warnings from startup script
So, IMO, the simplest solution would be to do what C does to solve this: Create a _werror() which is the actual builtin, then use a normal werror() definition which simply calls _werror() in the standard lib, and allow this werror() to be overridden by roxen_werror().
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Your "solution" would make all calls to builtins slower, I'm afraid.
Well, just the calls to werror(), which, as it happens, is a function which is only called in case of an error, and therefore, is timing uncritical. In general, there's almost no need to override Pike builtins used in the Pike libs. The only case, is exactly this one, the werror() builtin, which is overridden to allow the error output to be postformatted. IMO it's acceptable to slow this one done and make an exception. -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I thought you were adressing the general problem, as opposed to ad-hockery for your special case.
I don't have enough Pike-byte-code knowledge to address the general problem (not even to understand the general problem completely). I'm just making a suggestion, because to me it wasn't sure if there even was a general problem. It could have been related to werror only. I understand now, that the problem has larger implications than apparent at first. So I'll fold. Please view my attempt to fix it as a polite request for someone more knowledgeable to fix it instead :-).
Note that noone has objected to your ad-hoc solution regarding werror. I think it would serve fine as a short term fix.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 15:32: Subject: Re: Warnings from startup script
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
I thought you were adressing the general problem, as opposed to ad-hockery for your special case.
I don't have enough Pike-byte-code knowledge to address the general problem (not even to understand the general problem completely). I'm just making a suggestion, because to me it wasn't sure if there even was a general problem. It could have been related to werror only. I understand now, that the problem has larger implications than apparent at first. So I'll fold. Please view my attempt to fix it as a polite request for someone more knowledgeable to fix it instead :-). -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
Actually, I used to assume that werror() was already a wrapper, since it handles sprintf() style formatting, something which doesn't really need to be part of the builtin function.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 15:37: Subject: Re: Warnings from startup script
Note that noone has objected to your ad-hoc solution regarding werror. I think it would serve fine as a short term fix.
/ Martin Stjernholm, Roxen IS
It can be made just as fast by introducing a simple optimization pass as the last step of the decoding of code.
Simply replace F_CALL <builtin_function> with F_CALL_BUILTIN <index>
The ideal solution would probably be portable bytecode that is converted into the internal represenation when the object file is loaded.
/ Per Hedbor ()
Previous text:
2004-07-04 14:51: Subject: Re: Warnings from startup script
I thought you were adressing the general problem, as opposed to ad-hockery for your special case.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Simply replace F_CALL <builtin_function> with F_CALL_BUILTIN <index>
Not so simple when --use-machinecode is active.
The ideal solution would probably be portable bytecode that is converted into the internal represenation when the object file is loaded.
Yup.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 15:28: Subject: Re: Warnings from startup script
It can be made just as fast by introducing a simple optimization pass as the last step of the decoding of code.
Simply replace F_CALL <builtin_function> with F_CALL_BUILTIN <index>
The ideal solution would probably be portable bytecode that is converted into the internal represenation when the object file is loaded.
/ Per Hedbor ()
Stephen R. van den Berg wrote:
So, IMO, the simplest solution would be to do what C does to solve this: Create a _werror() which is the actual builtin, then use a normal werror() definition which simply calls _werror() in the standard lib, and allow this werror() to be overridden by roxen_werror().
I'm willing to create the patch for this, however...
Could someone point me to a function which already is implemented in the global context so I can learn how to program this?
Anything I check so far, is already a builtin (like closelog or sleep).
Could someone point me to a function which already is implemented in the global context so I can learn how to program this?
Found something, I think, backend.cmod: call_out() for instance. I'll try and model it after that.
The easiest way is probably to remove the werror() efun altogether, and then in master.pike.in add something like
function werror = Files()->_stderr->write;
towards the beginning, and add_constant( "werror", werror ); close to the 'add_constant("write", ... )' code.
/ Per Hedbor ()
Previous text:
2004-07-04 17:41: Subject: Re: Warnings from startup script
Could someone point me to a function which already is implemented in the global context so I can learn how to program this?
Found something, I think, backend.cmod: call_out() for instance. I'll try and model it after that. -- Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
Per Hedbor () @ Pike (-) developers forum wrote:
The easiest way is probably to remove the werror() efun altogether, and then in master.pike.in add something like
function werror = Files()->_stderr->write;
towards the beginning, and add_constant( "werror", werror ); close to the 'add_constant("write", ... )' code.
Well, close. I've already produced something that works. Checking it in now. I'll see if it can be even further reduced.
Stephen R. van den Berg wrote:
Per Hedbor () @ Pike (-) developers forum wrote:
The easiest way is probably to remove the werror() efun altogether, and then in master.pike.in add something like function werror = Files()->_stderr->write;
Reduced it further according to your suggestion. Added some prototypes. Looks good.
Per Hedbor () @ Pike (-) developers forum wrote:
function werror = Files()->_stderr->write;
towards the beginning, and add_constant( "werror", werror ); close to the 'add_constant("write", ... )' code.
What is the advantage of defining function werror first? Why not simply use:
add_constant("werror", Files()->_stderr->write);
?
towards the beginning, and add_constant( "werror", werror ); close to the 'add_constant("write", ... )' code.
What is the advantage of defining function werror first?
Ok, figured it out :-), sorry for the noise.
If f_werror is removed, all code using it will break.
/ Martin Nilsson (räfsfiskal)
Previous text:
2004-07-04 19:31: Subject: Re: Warnings from startup script
towards the beginning, and add_constant( "werror", werror ); close to the 'add_constant("write", ... )' code.
What is the advantage of defining function werror first?
Ok, figured it out :-), sorry for the noise.
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
By the way, I really think the error messages when giving pike bad parameters could be improved a bit...
| % pike gruk.pike | Pike: Failed to compile script: | Cast "/home/mirar/gruk.pike" to program failed in "/usr/local/pike/7.7.3/lib/master.pike". | | /usr/local/pike/7.7.3/lib/master.pike:2634: | master()->_main(({"pike","gruk.pike"}),({"INFODIR=/usr...
| % pike -m . | /home/mirar/pike/src/object.c:477: Fatal error: | low_read_file(.) failed, errno=21 | No stack - no backtrace.
Are those tested in the testsuite, by the way?
/ Mirar
Previous text:
2004-07-04 19:43: Subject: Re: Warnings from startup script
If f_werror is removed, all code using it will break.
/ Martin Nilsson (räfsfiskal)
You are running without master?
/ Martin Nilsson (räfsfiskal)
Previous text:
2004-07-04 19:45: Subject: Re: Warnings from startup script
By the way, I really think the error messages when giving pike bad parameters could be improved a bit...
| % pike gruk.pike | Pike: Failed to compile script: | Cast "/home/mirar/gruk.pike" to program failed in "/usr/local/pike/7.7.3/lib/master.pike". | | /usr/local/pike/7.7.3/lib/master.pike:2634: | master()->_main(({"pike","gruk.pike"}),({"INFODIR=/usr...
| % pike -m . | /home/mirar/pike/src/object.c:477: Fatal error: | low_read_file(.) failed, errno=21 | No stack - no backtrace.
Are those tested in the testsuite, by the way?
/ Mirar
I strongly agree about that.
/ Per Hedbor ()
Previous text:
2004-07-04 19:45: Subject: Re: Warnings from startup script
By the way, I really think the error messages when giving pike bad parameters could be improved a bit...
| % pike gruk.pike | Pike: Failed to compile script: | Cast "/home/mirar/gruk.pike" to program failed in "/usr/local/pike/7.7.3/lib/master.pike". | | /usr/local/pike/7.7.3/lib/master.pike:2634: | master()->_main(({"pike","gruk.pike"}),({"INFODIR=/usr...
| % pike -m . | /home/mirar/pike/src/object.c:477: Fatal error: | low_read_file(.) failed, errno=21 | No stack - no backtrace.
Are those tested in the testsuite, by the way?
/ Mirar
The two cases in Pike can easily be removed though: in f_exit in builtin_functions.c an apply call can be made. in main.c, using e.g. Pike_vsnprintf instead might work.
The question is if any external C modules uses f_werror.
/ Martin Nilsson (räfsfiskal)
Previous text:
2004-07-04 19:43: Subject: Re: Warnings from startup script
If f_werror is removed, all code using it will break.
/ Martin Nilsson (räfsfiskal)
There shouldn't be, since the prototype of f_werror() does not include PMOD_EXPORT.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 19:50: Subject: Re: Warnings from startup script
The two cases in Pike can easily be removed though: in f_exit in builtin_functions.c an apply call can be made. in main.c, using e.g. Pike_vsnprintf instead might work.
The question is if any external C modules uses f_werror.
/ Martin Nilsson (räfsfiskal)
What is the advantage of defining function werror first?
werror is used here and there in the master itself, which would not see the add_constant.
/ Per Hedbor ()
Previous text:
2004-07-04 18:40: Subject: Re: Warnings from startup script
Per Hedbor () @ Pike (-) developers forum wrote:
function werror = Files()->_stderr->write;
towards the beginning, and add_constant( "werror", werror ); close to the 'add_constant("write", ... )' code.
What is the advantage of defining function werror first? Why not simply use:
add_constant("werror", Files()->_stderr->write);
?
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless).
"Good moaning!"
/ Brevbäraren
I don't think I would like an error in Stdio.stderr->_write go into the bitbucket either...
/ Mirar
Previous text:
2004-07-04 19:20: Subject: Re: Warnings from startup script
What is the advantage of defining function werror first?
werror is used here and there in the master itself, which would not see the add_constant.
/ Per Hedbor ()
Another solution would be for roxen to maintain it's own set of dumped .o files. These files would be dumped in the same environment as the files are loaded, and thus wouldn't have this problem.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2004-07-04 12:53: Subject: Re: Warnings from startup script
Ideally, modules dumped by Pike should be decoded by Pike's codec, not the Roxen one. Is there no support for switching codecs when resolving dependencies?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:
Another solution would be for roxen to maintain it's own set of dumped .o files. These files would be dumped in the same environment as the
This is not my idea of a library. A preinstalled pike with all its precompiled library modules should be able to be used as is, IMHO.
The main reason as I said earlier is that the modules were dumped during the *PIKE* install, and not by Roxens dumper.
I can't image it's hard to make the roxen decoder only handle dumps in the roxen dump database.
Well, detecting if something is a FUNCTION_BUILTIN is easy:
Yes, but finding one that no longer is in builtin_constants is difficult.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 12:50: Subject: Re: Warnings from startup script
Recompile, rather. I wonder what differences in load order causes different werrors to be installed when compiling from source and when decoding dumps.
The module already gets recompiled in the code that emits the warning. The change would be to dump the new module.
The main reason as I said earlier is that the modules were dumped during the *PIKE* install, and not by Roxens dumper.
Still, load order is typically fragile, so fixing the codec is the robust approach. That requires a new lookup method for efuns, though.
Well, detecting if something is a FUNCTION_BUILTIN is easy:
Pike v7.7 release 5 running Hilfe v3.5 (Incremental Pike Frontend)
functionp(werror);
(1) Result: 1
function_object(werror);
(2) Result: 0
werror || 0;
(3) Result: werror
cf:
object o = class { function foo(){} }(); function f = o->foo; functionp(f);
(4) Result: 1
function_object(f);
(5) Result: HilfeInput()->__class_65693_0_line_1()
destruct(o);
(6) Result: 0
functionp(f);
(7) Result: 0
function_object(f);
Bad argument 1 to function_object(). Expected function. Unknown program: function_object(0) HilfeInput:1: HilfeInput()->___HilfeWrapper()
f;
(8) Result: 0
/ Henrik Grubbström (Lysator)
I can't image it's hard to make the roxen decoder only handle dumps in the roxen dump database.
I expect problems can occur if decoding a dumped program causes modules to be resolved, which have been dumped by the Pike codec, if the roxen codec will be used to decode those as well. Can the selection of codec for implicitly decoded programs be controlled?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 14:00: Subject: Re: Warnings from startup script
The main reason as I said earlier is that the modules were dumped during the *PIKE* install, and not by Roxens dumper.
I can't image it's hard to make the roxen decoder only handle dumps in the roxen dump database.
Well, detecting if something is a FUNCTION_BUILTIN is easy:
Yes, but finding one that no longer is in builtin_constants is difficult.
/ Martin Stjernholm, Roxen IS
As opposed to a compilation handler, the codec isn't inherited when modules are resolved recursively. A codec is always chosen for decoding each string, so you can always select a suitable one depending on the source of the string.
Anyway, my point wasn't valid since the pike codec doesn't have any greater luck getting the real werror efun even if it's used on the pike dumps.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 14:04: Subject: Re: Warnings from startup script
I can't image it's hard to make the roxen decoder only handle dumps in the roxen dump database.
I expect problems can occur if decoding a dumped program causes modules to be resolved, which have been dumped by the Pike codec, if the roxen codec will be used to decode those as well. Can the selection of codec for implicitly decoded programs be controlled?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
As opposed to a compilation handler, the codec isn't inherited when modules are resolved recursively. A codec is always chosen for decoding each string, so you can always select a suitable one depending on the source of the string.
Ok. The Pike codec seems to select "this" unconditionally though, so one needs to watch out if inheriting it as a base for a custom codec. (Hm, shouldn't it pass "this" to resolv() for the 'r' case as well? It seems inconsitent to do it only for 'p', 'o' and 'f'...)
Anyway, my point wasn't valid since the pike codec doesn't have any greater luck getting the real werror efun even if it's used on the pike dumps.
Yes, but that's an orthogonal problem. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 14:10: Subject: Re: Warnings from startup script
As opposed to a compilation handler, the codec isn't inherited when modules are resolved recursively. A codec is always chosen for decoding each string, so you can always select a suitable one depending on the source of the string.
Anyway, my point wasn't valid since the pike codec doesn't have any greater luck getting the real werror efun even if it's used on the pike dumps.
/ Martin Stjernholm, Roxen IS
It's a bit ugly that it passes "this" in any of those cases since it's a codec and not a compilation handler. I'm not sure why it does that. Maybe it's to ensure that the __register_new_program callback can be called later on, but that's done through the codec object anyway. So I'd say the "this" passing should go away in the 'p', 'f' and 'o' cases instead.
One thing that perhaps should be done there is to add a compilation handler slot to the codec, so that one can be instantiated with a specific handler that it will pass on in those cases. I.e. so that the handler in effect in low_findprog also will be used in later resolv/findmodule/etc calls from the codec.
But how does the "this" passing complicate inheritance? If an inherited object instance is used then that one will also be passed on, which seems like the right thing to me.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 14:14: Subject: Re: Warnings from startup script
As opposed to a compilation handler, the codec isn't inherited when modules are resolved recursively. A codec is always chosen for decoding each string, so you can always select a suitable one depending on the source of the string.
Ok. The Pike codec seems to select "this" unconditionally though, so one needs to watch out if inheriting it as a base for a custom codec. (Hm, shouldn't it pass "this" to resolv() for the 'r' case as well? It seems inconsitent to do it only for 'p', 'o' and 'f'...)
Anyway, my point wasn't valid since the pike codec doesn't have any greater luck getting the real werror efun even if it's used on the pike dumps.
Yes, but that's an orthogonal problem. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
But how does the "this" passing complicate inheritance? If an inherited object instance is used then that one will also be passed on, which seems like the right thing to me.
It's the wrong thing to do when the dependency is to a program dumped with another codec, such as a module dumped by the pike installer. The choice must be made on a program-by-program basis.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-07-04 14:37: Subject: Re: Warnings from startup script
It's a bit ugly that it passes "this" in any of those cases since it's a codec and not a compilation handler. I'm not sure why it does that. Maybe it's to ensure that the __register_new_program callback can be called later on, but that's done through the codec object anyway. So I'd say the "this" passing should go away in the 'p', 'f' and 'o' cases instead.
One thing that perhaps should be done there is to add a compilation handler slot to the codec, so that one can be instantiated with a specific handler that it will pass on in those cases. I.e. so that the handler in effect in low_findprog also will be used in later resolv/findmodule/etc calls from the codec.
But how does the "this" passing complicate inheritance? If an inherited object instance is used then that one will also be passed on, which seems like the right thing to me.
/ Martin Stjernholm, Roxen IS
It still is. That argument is never used as a codec afaics. As a compilation handler it's largely a NOP since the decoder doesn't contain any of the functions that a compilation handler should, so the safe_apply_handler calls falls back to the compat and standard handlers anyway.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 14:50: Subject: Re: Warnings from startup script
But how does the "this" passing complicate inheritance? If an inherited object instance is used then that one will also be passed on, which seems like the right thing to me.
It's the wrong thing to do when the dependency is to a program dumped with another codec, such as a module dumped by the pike installer. The choice must be made on a program-by-program basis.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
I've corrected the handler confusion now. Seems to work.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 14:37: Subject: Re: Warnings from startup script
It's a bit ugly that it passes "this" in any of those cases since it's a codec and not a compilation handler. I'm not sure why it does that. Maybe it's to ensure that the __register_new_program callback can be called later on, but that's done through the codec object anyway. So I'd say the "this" passing should go away in the 'p', 'f' and 'o' cases instead.
One thing that perhaps should be done there is to add a compilation handler slot to the codec, so that one can be instantiated with a specific handler that it will pass on in those cases. I.e. so that the handler in effect in low_findprog also will be used in later resolv/findmodule/etc calls from the codec.
But how does the "this" passing complicate inheritance? If an inherited object instance is used then that one will also be passed on, which seems like the right thing to me.
/ Martin Stjernholm, Roxen IS
But we don't want to use the efun werror. Ever. At least I don't when I overload werror. I usually do so for a reason.
I think it would be way better to do the resolving runtime, as in, when the dumped modules are loaded.
/ Per Hedbor ()
Previous text:
2004-07-04 12:38: Subject: Re: Warnings from startup script
Recompile, rather. I wonder what differences in load order causes different werrors to be installed when compiling from source and when decoding dumps.
Still, load order is typically fragile, so fixing the codec is the robust approach. That requires a new lookup method for efuns, though.
/ Martin Stjernholm, Roxen IS
You're right, but note that it might not be enough to do the resolving module load time since some modules are invariably loaded before the add_constant call is done. To make it work really correctly, all calls to globals would have to do lookups in the builtin_constants mapping.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-07-04 15:26: Subject: Re: Warnings from startup script
But we don't want to use the efun werror. Ever. At least I don't when I overload werror. I usually do so for a reason.
I think it would be way better to do the resolving runtime, as in, when the dumped modules are loaded.
/ Per Hedbor ()
pike-devel@lists.lysator.liu.se
-
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (r�fsfiskal) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Stephen R. van den Berg