cast_to_program() and CompilationHandlers

[Bill Welliver-2]

At the conference in November, we had the following conversation (to quote
mast's report):

"Bill talked about his attempts to separate resolver contexts, to be able
to run different versions of an application in the same pike process. He
would try to solve this with separate compilation handlers, similar to how
the #pike compat system works."

Over the last few days, I've been playing with this idea a little bit
more, and I think I can get at least part of the way to where I need with
passing a CompatResolver object to compile() and friends.

One problem that I've noticed is that the compilation handler doesn't seem
to concern itself with program loading (as opposed to loading from
modules). Specifically, cast_to_program() consults the program path
defined in the master and not the one that's used in the CompatResolver.
Is that an oversight, or is that by design?

That is, shouldn't the following line:

  foreach(pike_program_path, string path)
       if(program ret=findprog(combine_path(path,pname),ext,handler,mkobj))
         return ret;

be something like:

  foreach(handler->pike_program_path||pike_program_path, string path)
       if(program ret=findprog(combine_path(path,pname),ext,handler,mkobj))
         return ret;

?

Secondly, I'm not sure if there's a way to completely override compile()
and the like, as it seems as though the system prefers to use the
originally defined efun even after I've added compile using add_constant.
It does get used in the rare cases where my code calls compile()
explicitly, but otherwise it seems as though that's not the case (and I've
made sure that there aren't any cached copies of programs in the programs
mapping in master().

Any thoughts?

Bill

[Martin Stjernholm]

Bill Welliver <[hidden email]> wrote:

> One problem that I've noticed is that the compilation handler doesn't
> seem to concern itself with program loading (as opposed to loading
> from modules). Specifically, cast_to_program() consults the program
> path defined in the master and not the one that's used in the
> CompatResolver. Is that an oversight, or is that by design?

Seems like an oversight to me.

> Secondly, I'm not sure if there's a way to completely override
> compile() and the like, as it seems as though the system prefers to
> use the originally defined efun even after I've added compile using
> add_constant. It does get used in the rare cases where my code calls
> compile() explicitly, but otherwise it seems as though that's not the
> case (and I've made sure that there aren't any cached copies of
> programs in the programs mapping in master().
>
> Any thoughts?

When you use add_constant, you only override calls in code being
compiled later, so compile() calls in the original master object will
not be affected, for instance.

But otoh, why do you need to override them? If it's to pass your own
handler then the calls in the master shouldn't be a problem since the
incoming handler always is propagated there.