Can I load a package"s Autoload-able subs without executing them?

I want to be able to really load all subs in a given package,
including all load-on-demand subs. I don't want to execute them in the
process. Ideally it should work irrespective of the mechanism (e.g.
AutoLoader, SelfLoader, load-pragma) used inside the module. But the
next best thing would be a solution just for "use AutoLoader"-modules.

I could manually look for ".al"-files and require them but that's not
very elegant as it uses knowledge about internals I shouldn't need to
have.

Why do I want to do this? I'm deriving from Devel::TraceCalls to see
what's going on inside my Perl/Tk application. For a while I wondered
why some functions never got traced. Well, when the tracer is
instantiated they are not there -- they are autoloaded later -- so the
tracer can't wrap them...

Thanks,
Wolfram

Re: Can I load a package"s Autoload-able subs without executing them?

wrote in comp.lang.perl.misc:
> I want to be able to really load all subs in a given package,
> including all load-on-demand subs. I don't want to execute them in the
> process. Ideally it should work irrespective of the mechanism (e.g.
> AutoLoader, SelfLoader, load-pragma) used inside the module. But the
> next best thing would be a solution just for "use AutoLoader"-modules.
>
> I could manually look for ".al"-files and require them but that's not
> very elegant as it uses knowledge about internals I shouldn't need to
> have.

That would only cover cases where an external *.al file is used.

> Why do I want to do this? I'm deriving from Devel::TraceCalls to see
> what's going on inside my Perl/Tk application. For a while I wondered
> why some functions never got traced. Well, when the tracer is
> instantiated they are not there -- they are autoloaded later -- so the
> tracer can't wrap them...

Programmers frequently would like to do that. Yours is as good a reason
as any.

The sad truth is that it can't be done. All the mechanisms you mention
are based on the behavior of the AUTOLOAD routine, which is called
before the interpreter gives up on a sub name. This is described
in perlsub. One fact is that AUTOLOAD doesn't even have to define
the function it is called to "autoload". It could perform the
function directly, depending on the sub name, and never leave a trace.

Anno

Re: Can I load a package"s Autoload-able subs without executing them?

Quoth anno4000@radom.zrz.tu-berlin.de:
> wrote in comp.lang.perl.misc:
> > I want to be able to really load all subs in a given package,
> > including all load-on-demand subs.

> > Why do I want to do this? I'm deriving from Devel::TraceCalls to see
> > what's going on inside my Perl/Tk application. For a while I wondered
> > why some functions never got traced. Well, when the tracer is
> > instantiated they are not there -- they are autoloaded later -- so the
> > tracer can't wrap them...
>
> Programmers frequently would like to do that. Yours is as good a reason
> as any.
>
> The sad truth is that it can't be done. All the mechanisms you mention
> are based on the behavior of the AUTOLOAD routine, which is called
> before the interpreter gives up on a sub name. This is described
> in perlsub. One fact is that AUTOLOAD doesn't even have to define
> the function it is called to "autoload". It could perform the
> function directly, depending on the sub name, and never leave a trace.

One solution would be to have your tracer install a trace on AUTOLOAD as
well, and handle it specially (noting the value of $AUTOLOAD, for
instance; and probably trying to install a trace on the autoloaded sub,
if it exists, after AUTOLOAD returns). Note that your problem here isn't
strictly autoloading: it's the fact that Perl allows you to modify the
symbol table at runtime. And there's no way around that: if a program
randomly inserts a new sub into the symbol table, there's no way for you
to find out.

Ben

--
The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching.
Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
--
The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching.
Assyrian stone tablet, c.2800 BC ben@morrow.me.uk

Re: Can I load a package"s Autoload-able subs without executing them?

On Thu, 23 Aug 2007 15:13:04 +0100, Ben Morrow
wrote:

>strictly autoloading: it's the fact that Perl allows you to modify the
>symbol table at runtime. And there's no way around that: if a program
>randomly inserts a new sub into the symbol table, there's no way for you
>to find out.

It would be nice if there were a hook to trigger say a sub, each time
something like this happens. It would probably be passed a copy of the
symtable as a hashref before the modification takes place and a copy
of it *after* it has.


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: Can I load a package"s Autoload-able subs without executing them?

On 23 Aug., 16:13, Ben Morrow wrote:
>
> > wrote in comp.lang.perl.misc:
> > > I want to be able to really load all subs in a given package,
> > > including all load-on-demand subs.
>
> One solution would be to have your tracer install a trace on AUTOLOAD as
> well, and handle it specially (noting the value of $AUTOLOAD, for
> instance; and probably trying to install a trace on the autoloaded sub,
> if it exists, after AUTOLOAD returns). Note that your problem here isn't
> strictly autoloading: it's the fact that Perl allows you to modify the
> symbol table at runtime. And there's no way around that: if a program
> randomly inserts a new sub into the symbol table, there's no way for you
> to find out.
>
That's a nice idea but with a few problems:
- It involves a lot of bookkeeping. I need to remember every category
of
things that a user wanted to trace and see if a matching autoload
comes around.
- It prevent me from notifying the user of misspelled function names.
If
the user wants to trace "Tk::FocusNext" (which really should be
spelled
"Tk::focusNext") I can't tell him there's no such function, cause it
might be autoloaded any time...

(I might still give it a try...)

Wolfram