rootcho has asked for the wisdom of the Perl Monks concerning the following question:

hi
I was experimenting with PAR module..and have a problem.
What I want to do is to make a .par arhive from all depencities of a script myscript.pl and MyModule.pm (i even dont want to include these files into the .par just their depencities)
So I do this to create the .par :
 pp -v -p -o test.par myscript.pl -M lib/MyModule.pm

[download]
Ok now if I start the script like this : 
pp -r test.par

[download]
Everything goes fine, the problem is that myscript.pl and MyModule will be changed often and not only be me, so I want them to be saparate not included in the .par
Now when I try to run myscript.pl standalone, like this : 
./myscript.pl

[download]
Where inside the script i have : 
use FindBin qw($Bin);
use lib $Bin . "lib";
use MyModule;
use PAR '/path/to/test.par';
...

[download]
The script executes a little bit and then cpu goes to 100%. When I strace it I'm getting this : 
stat64("1/cache-0258711d093381286af15b1cbad893d630bd9e91/1ec196d6.pm",
+ {st_mode=S_IFREG|0644, st_size=3336, ...}) = 0
stat64("1/cache-0258711d093381286af15b1cbad893d630bd9e91/1ec196d6.pm",
+ {st_mode=S_IFREG|0644, st_size=3336, ...}) = 0
stat64("1/cache-0258711d093381286af15b1cbad893d630bd9e91/1ec196d6.pm",
+ {st_mode=S_IFREG|0644, st_size=3336, ...}) = 0
....and the same non stop..

[download]
Any idea how to solve this problem !?? (i dont want/need to include myscript.pl and MyModule.pm inside the .par)

Replies are listed 'Best First'.
Re: PAR packaging
by bobf (Monsignor) on Jun 20, 2006 at 03:29 UTC

    the problem is that myscript.pl and MyModule will be changed often and not only be me, so I want them to be saparate not included in the .par
    I'm afraid I can't answer your specific question, but this phrase got me thinking. If the reason you want to keep these files out of the PAR file is so they can be modified, perhaps a different approach would work. Would it be possible to use a config file that contains the data that will be modified rather than hard-coding it? That would not only clean up the overall program, but it would allow you to use PAR in the traditional manner. There are several modules related to config files on CPAN: Config::General, Config::IniFiles, Config::Simple, etc. If you need to modify code (rather than simply parameters), you could provide a separate file that could be used (via do? Another monk might be able to confirm that) to add methods to any package in the program.

    Just some things to consider. If you can't solve the problem, try to go around it. :-)

[reply]
      Just some things to consider. If you can't solve the problem, try to go around it. :-)

      I find, so consistantly that it is frightning, that businesses love to do this. They end up going around in circles, me in the middle shouting 'Meet the problem head on!'.

      -=( Graq )=-

[reply]
        well said ;)
[reply]
      i can't ;(, the scripts itself are changed.
      and the bad thing is there is not one but at least 20 scripts on a box... ~10 boxes
[reply]
Re: PAR packaging
by tsee (Curate) on Jun 21, 2006 at 09:49 UTC

    Hi,

    I have constructed a simple test which does what you want but does not reproduce your problem:

    Put this in t.pl: 

    #!/usr/bin/perl
use strict;
use warnings;
use lib '.';
use PAR qw/t.par/;
use MyModule;

print "\nbar\n";

    [download]

    And put this in the subdirectory lib in the file MyModule.pm 

    package MyModule;

print "foo";

1;

    [download]

    Now run this command:

    PERL5LIB=lib pp -o t.par -p -v t.pl -M MyModule

    [download]

    Explanation:

    • If you just execute t.pl before running the pp command, MyModule.pm will not be found because it is in the lib/ subdirectory.
    • If you run the pp command, it temporarily uses lib/ as a perl library directory so pp can find and package MyModule.pm. (That's the PERL5LIB=... part.)
    • It puts MyModule.pm into the t.par archive.
    • Subsequent execution of t.pl will use t.par as a PAR archive and load MyModule.pm from there.

    Does this work for you? If not, please tell me what OS you are on, what version of PAR you are using and what version of perl you have. This was PAR 0.941, perl 5.8.7 on kubuntu/dapper/x86_64.

    Finally a little explanation of your strace output. (I'm not an expert on strace, though.) The file 1ec196d6.pm is a filename-mangled version of one of the modules PAR uses internally. To find out which one it is, open it with an editor and look for the "package" declaration. Now, the fact that it is put into the 1/ subdirectory of the cwd() is most certainly a PAR bug. I will investigate that and appreciate any feedback.

    Hope this helps,
    Steffen

[reply]
[d/l]
[select]
      ok...thank you very much, will try your suggestions and will post the results..
[reply]
      hmm, now after i read more carefully what u wrote.. i don't want to do exacactly what u specify
      I want MyModule.pm and myscript.pl to be outside of the .PAR so that i can change them often. And i want to use the .PAR for all of the CPAN modules we use.
      'Cause we don't own the boxes were the scripts will be, it will be alot easier for use to deploy the scripts if common CPAN modules can be in a .par.
      Now on the script...just for this reason I first use : 
      use FindBin qw($Bin);
use lib $Bin . "lib";
use MyModule;

      [download]
      and then : 
      use PAR '/path/to/test.par';

      [download]
      So that the script can find the module, outside the .par.
      But as I already said when I execute the script outside the .par, I'm getting this 100%-cpu usage on stat64() call.
      OK, i contunued my investigation to see exactly which is this 1ec196d6.pm module, after I checked the cache the file is the HTML::HeadParser module.
      Now the more interesting part ;) If i go into the .par, delete this module from archive and start myscript.pl runs w/o a problem
[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom