Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Interesting behavior in eval block

by l2kashe (Deacon)
on Jun 19, 2008 at 18:25 UTC ( #692982=perlquestion: print w/ replies, xml ) Need Help??
l2kashe has asked for the wisdom of the Perl Monks concerning the following question:

I have run into a situation with dynamically load available modules at runtime via eval. There is magic afoot I don't fully appreciate, so I am hoping someone can point to the right doc/direction on what is going on.

I have a fairly large codebase which needs to be deployed in a variety of situations/environments. Given the nature of the code, it can have an excessive number of module requirements to cover all the scenarios it can be leveraged for. Instead of doing some type of preinspection of the available modules and then reconfiguring the codebase on the fly or trying to download modules from CPAN, I wanted to wait until runtime and let user configurable data drive what modules should be loaded.

There are 2 main usage patterns, simply use()ing a module, and use()ing a module with a list of keywords to import into the application (IE. use Time::HiRes; vs use Time::HiRes qw(gettimeofday tv_interval). So a simple hash gets the trick done in terms of handling the data requirements The issue comes in with using eval causing keywords to not be imported into the namespace cleanly as far as I can tell.

After a number of posts about the syntax of the code not being valid I have replaced the code with the actual method being used. This is within a package which uses strict. I have added a third example which a contrived object using this information

#!/path/to/perl # This snippet works as expected use strict; use Time::HiRes qw(gettimeofday tv_interval); my $now = [gettimeofday]; sleep 2; # The below produces "Elapsed: 2.01233" print "Elapsed: ", tv_interval($now, [gettimeofday]), "\n";
#!/path/to/perl # This snippet *DOES NOT* work as expected use strict; my $toLoad = { 'CGI' => '1', 'Time::HiRes' => 'gettimeofday tv_interval', }; while ( my($module, $args) = each %$toLoad) { my $str = "use $module"; $str .= 'qw(' . $args . ')' if $args ne '1'; eval $str; # also tried eval {}, eval "", etc... } # END while each %$toLoad my $now = [gettimeofday]; sleep 2; # The below produces Elapsed: 0, print "Elapsed: ", tv_interval($now, [gettimeofday]), "\n";

Changing the line now = line to [gettimeofday()] it works, I assume by hinting to the runtime environment that this is in fact a routine and not a string.

So what is different within the eval expression that isn't within the standard use EXPR line?

#!/path/to/perl use strict; my $obj = {}; # For this example bless($obj, 'main'); # get some data via config and then my $status = $obj->loadPerlModule($configData); # Prints no warnings or errors under strict.. foreach my $module ( keys %$status ) { print "$module status: $status->{$module}\n"; } # This fails.. my $now = [gettimeofday]; sleep 2; # The below produces Elapsed: 0, print "Elapsed: ", tv_interval($now, [gettimeofday]), "\n"; # This succeeds my $newNow = [gettimeofday()]; sleep 2; # The below produces Elapsed: 2.02313, print "Elapsed: ", tv_interval($now, [gettimeofday()]), "\n"; # This is the actual method that loads the module. sub loadPerlModule { my $self = shift; my $modules = $self->asHash(@_); my $return = {}; foreach my $module ( keys %$modules ) { if ( $modules->{ $module } ne '1' ) { eval "use $module " . 'qw(' . $modules->{$module} . ');'; } else { eval "use $module"; } $return->{ $module } = ( $@ ) ? "Failed to use module: $@" : "Module loaded"; $@ = undef; } # END foreach my $module return $return; } # END sub loadPerlModule

use perl;
Everyone should spend some time pounding nails with their forehead for a while before they graduate to complicated stuff like hammers. - Dominus

Comment on Interesting behavior in eval block
Select or Download Code
Re: Interesting behavior in eval block
by moritz (Cardinal) on Jun 19, 2008 at 18:33 UTC
    my $str = "use $module"; $str .= 'qw(' . $args . ')' if $args ne '1';
    There's a space missing, which causes perl to try to load Time::HiResqw

    I recommend a warn $@ if $@; after your eval.

Re: Interesting behavior in eval block
by ikegami (Pope) on Jun 19, 2008 at 18:33 UTC

    Outside a situation that expects a bareword (such as the LHS of => and print's first argument), a bareword is compiled into a function call only if a function by that name exists at that time. Otherwise, it is compiled as a string constant (strict off) or results in an error (strict on).

    use executes as soon as it compiles, so the function it imports are present before the rest of the file is compiled. However, you deferred the execution of use to when the eval is executed, which is only after the entire file (including what you want to be a call to gettimeofday) has been compiled.

    Remember that use Module; is the same as BEGIN { require Module; import Module; }, so the solution is to reintroduce BEGIN. Put a BEGIN block around the while and you'll get the desired behaviour. The loop will execute as soon as it finishes compiling, which is before the compiler reaches "gettimeofday".

    Update: Reorganized text to improve readability.

      That makes sense, but this is a contrived minimal example of the implementation. This will be run well after compile time off of config data, or object instantiation values. So the questions is can I somehow muck with the symbol table to get where I want to be? Maybe something like
      while ( my($module, $args) = each %$toLoad ) { my $str = "use $module "; # to fix typo in example $str .= 'qw(' . $args . ')' if $args ne '1'; eval $str; # Try and remap symbol tables to the right spot unless ( $args eq '1' ) { no strict 'refs'; foreach my $key ( split/\s+/, $args ) { *$key = *$module::$key; } } # END unless args eq 1 } # END while each toLoad

      This would cover the standard cases but fail for things like use CGI qw(:all); and similar megaKeywords

      I imagine this is a standard pattern, I just don't know where to look for the docs to get at what I want without potentially digging into other modules EXPORT_* variables, which doesn't seem right either

      use perl;
      Everyone should spend some time pounding nails with their forehead for a while before they graduate to complicated stuff like hammers. - Dominus

        Your "trick" doesn't work. You're just duplicating the work the implicit import in use already does. Like I said in my original post, it's *when* it happens that's important.

        You have the right idea, but it needs to be done at compile-time. Fortunately, it's very simple since Perl already provides a means of declaring a function that's to be defined at a later time.

        sub gettimeofday(); # Eventually. eval "use Time::HiRes qw( gettimeofday ); 1" or die "Unable to load Time::HiRes: $@\n"; print(gettimeofday);

        The parens in "sub gettimeofday();" are only there because Time::HiRes declares the function using that prototype.

Re: Interesting behavior in eval block
by jettero (Monsignor) on Jun 19, 2008 at 18:33 UTC
    It might even say why it doesn't work if you did something like this:
    eval "use something"; die $@ if $@;

    -Paul

Re: Interesting behavior in eval block
by Fletch (Chancellor) on Jun 19, 2008 at 18:37 UTC

    Erm, that code doesn't compile because you have a bareword "gettimeofday". Since the importing hasn't taken place when the code in question is compiled it's not a valid sub name and is causing strict to complain.

    Bareword "gettimeofday" not allowed while "strict subs" in use at - li +ne 17. Bareword "gettimeofday" not allowed while "strict subs" in use at - li +ne 21.

    As for why you're getting 0, since both instances of the string "gettimeofday" are treated as "0" when used as a number (which would have gotten you more gripes had you used warnings, but I digress) the difference between them is understandably also 0.

    Additionally: you might be interested in the if pragma to conditionally load things in a saner manner.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

Re: Interesting behavior in eval block
by kyle (Abbot) on Jun 19, 2008 at 18:44 UTC

    After any eval, you should check to see whether it failed or not. Right after yours, I slipped in this line:

    die $@ if $@;

    It's also useful when debugging to print out the string you're trying to eval in case it has an obvious error. Here's the string you're using:

    use Time::HiResqw(gettimeofday tv_interval)

    ...so I stuck a space in this line:

    $str .= ' qw(' . $args . ')' if $args ne '1'";

    The error you get about "gettimeofday" and "strict subs" is because you've told Perl that the bareword "gettimeofday" is a function call rather than just some string. If Time::HiRes doesn't load, you'll still get another error:

    Undefined subroutine &main::gettimeofday called at ...

    If Time::HiRes does load, "gettimeofday" without the parentheses is fine because—I'm guessing a little here—it has a prototype.

    Anyway, always check your evals.

Re: Interesting behavior in eval block
by dragonchild (Archbishop) on Jun 19, 2008 at 20:49 UTC
    I have a fairly large codebase which needs to be deployed in a variety of situations/environments. Given the nature of the code, it can have an excessive number of module requirements to cover all the scenarios it can be leveraged for. Instead of doing some type of preinspection of the available modules and then reconfiguring the codebase on the fly or trying to download modules from CPAN, I wanted to wait until runtime and let user configurable data drive what modules should be loaded.

    While you can do what you're trying to do, that way will generally lead to insanity. It is much much saner to manage dependencies at the time the dependency is now needed. This generally comes down to two places:

    • Upon installation or deployment
    • When a new feature is enabled

    In the case of the second, I would have both a config file and a UI. If the user directly edits the config file, they are responsible for the dependencies (superuser mode). If the UI is used, then whatever code backs the UI should make sure the dependency is met, either by alerting the user to tell the sysadmin or (preferable) installing the dependency itself.

    Before you say "But you need root!", I say you don't. Check out Perl::Install for an easy way to install Perl anywhere you want. This is what I do when I have an application - it literally has its own Perl installation along with its own modules. That way, I know exactly what user permissions are required to update the install.

    Before you complain about space, remember that disk space is much much cheaper than people time.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://692982]
Approved by jettero
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2014-07-12 05:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (238 votes), past polls