[rt.cpan.org #72112] PAR::Dist META.json problem
Sat Nov 05 07:09:27 2011: Request 72112 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Dist Subject: PAR::Dist META.json problem Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: po...@dvo.ru Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=72112 > Thanks, applied. Will hit your CPAN mirrors soon as version 0.48. --Steffen
Re: [rt.cpan.org #72112] PAR::Dist META.json problem
Sat Nov 05 07:09:02 2011: Request 72112 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Dist Subject: Re: [rt.cpan.org #72112] PAR::Dist META.json problem Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: po...@dvo.ru Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=72112 > Hi, On 11/02/2011 06:39 AM, po...@dvo.ru via RT wrote: > I've started to use PAR::Dist::FromCPAN to create standalone repository > for my project, but during > compilation of some modules it fails. Some analysis show that this > modules do not have proper META.yml > file but have META.json. In building time as I can see some data from > this META.json are stored in MYMETA.yml. > In the code CPAN::Distribution module I have read that " # if MYMETA.yml > exists, that takes precedence over META.yml". > So I've wrote small patch to fix problem with installation. Indeed. MYMETA.yml is the authoritative source of any dependency information and other meta info. Its inception was after I last touched the PAR::Dist code and I don't think anybody else has since. The problem with MYMETA is ordinarily that it's not available before building, so most tools can't rely on it. This is different for the part of PAR::Dist that you care about as it comes in only after build time. Either way, we may have to eventually add META.json support to PAR::Dist. The modules currently does many nasty things in order not to require a YAML parser in order to work out of the box on old perls. Repeating that for JSON would be horrible. When I spent a bit of time to think about it, I couldn't come up with a very good solution. If it's the case that the recent toolchain will always generate MYMETA.yml even if there was a META.json, then we just bought some time. I'll upload a patched PAR::Dist 0.48 within the hour. Best regards, Steffen
Re: [rt.cpan.org #72112] PAR::Dist META.json problem
Hi, On 11/02/2011 06:39 AM, po...@dvo.ru via RT wrote: I've started to use PAR::Dist::FromCPAN to create standalone repository for my project, but during compilation of some modules it fails. Some analysis show that this modules do not have proper META.yml file but have META.json. In building time as I can see some data from this META.json are stored in MYMETA.yml. In the code CPAN::Distribution module I have read that " # if MYMETA.yml exists, that takes precedence over META.yml". So I've wrote small patch to fix problem with installation. Indeed. MYMETA.yml is the authoritative source of any dependency information and other meta info. Its inception was after I last touched the PAR::Dist code and I don't think anybody else has since. The problem with MYMETA is ordinarily that it's not available before building, so most tools can't rely on it. This is different for the part of PAR::Dist that you care about as it comes in only after build time. Either way, we may have to eventually add META.json support to PAR::Dist. The modules currently does many nasty things in order not to require a YAML parser in order to work out of the box on old perls. Repeating that for JSON would be horrible. When I spent a bit of time to think about it, I couldn't come up with a very good solution. If it's the case that the recent toolchain will always generate MYMETA.yml even if there was a META.json, then we just bought some time. I'll upload a patched PAR::Dist 0.48 within the hour. Best regards, Steffen
[rt.cpan.org #69560] PAR packed files are extracted to unsafe and predictable temporary directories
Sat Nov 05 06:04:02 2011: Request 69560 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: PAR packed files are extracted to unsafe and predictable temporary directories Broken in: (no value) Severity: Critical Owner: Nobody Requestors: j...@nixnuts.net Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=69560 > Presumably, one could at least have a build-time option for pp (not packaging time, but PAR::Packer compilation time) that enables some extra measures: perl Makefile.PL --paranoid make test && make install a) assert ownership of all directories and files under $TMPDIR/par-$USER b) assert that other can't write. (How portable would this be?) Doing this by default would make the cached-startup slow enough to not warrant caching at all. That would make PAR::Packer useless for all but the most trivial scripts. Think about it. If any other executable would have to scan the entire perl source tree before starting, it'd be slower to boot than java. Right now, the proper way to get entirely safe PAR'd executables is to set an alternate extraction/cache directory. See "man PAR::Environment".
Re: POE::Component::Resolver patch for PAR compatibility
Hi Markus, On 05/19/2011 10:35 AM, Markus Jansen wrote: Steffen and Roderich: could you please scrutinize my patch from a PAR perspective? I know that I have been a little bit more paranoid than necessary when trying to detect whether a) the script runs under PAR, and b) the "external Perl" version is wanted. Regarding the calling via --reuse - is there an easier/faster way? Keep in mind --reuse is a little bit experimental and has likely not been tested a huge lot. Worked for me, though. Regarding "paranoia", I think it's important to take care. Executing stuff from an environment variable... What would you suggest as an easier way? Best regards, Steffen
Re: Problem to execute "sidecar" Perl scripts when compilingPOE::Component::Resolver with PAR
Hi Markus, On 05/17/2011 05:48 PM, Markus Jansen wrote: Any hints appreciated. these are hints at best, but check the PAR list's archive and the PAR repository/history for 'reusable': Below's what I found with a svn log | grep, maybe that helps partially for the $^X problem. Beware, I haven't used this feature much. Cheers, Steffen svn diff -c1055 Index: trunk/lib/pp.pm === --- trunk/lib/pp.pm (revision 1054) +++ trunk/lib/pp.pm (revision 1055) @@ -358,6 +358,18 @@ Run the resulting packaged script after packaging it. +=item B<--reusable> + +B + +Make the packaged executable reusable for running arbitrary, external +Perl scripts as if they were part of the package: + + pp -o myapp --reusable someapp.pl + ./myapp --par-options --reuse otherapp.pl + +The second line will run F instead of F. + =item B<-S>, B<--save> Do not delete generated PAR file after packaging.
Re: [rt.cpan.org #63801] setuid pp'ed scripts: 1st invocation fails, 2nd+ call ok
Mon Dec 20 17:53:46 2010: Request 63801 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #63801] setuid pp'ed scripts: 1st invocation fails, 2nd+ call ok Broken in: 1.008 Severity: Wishlist Owner: Nobody Requestors: bitc...@post2.25u.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=63801 > On Dec 20, 2010, at 2:24 PM, Alexander Ost via RT wrote: > Queue: PAR-Packer > Ticket https://rt.cpan.org/Ticket/Display.html?id=63801 > > > On Mon Dec 20 07:51:04 2010, roderich.sch...@googlemail.com wrote: >> On Mon, Dec 20, 2010 at 12:28 PM, Alexander Ost via RT >>> 3/ it seems that PAR tries to put some file into the cache at a later >>> point during the program's lifetime >> >> Correct. Some stuff will only be extracted on demand. > > I just verified that (as suspected) this breaks any script that changes its > effective > uid during runtime, because it leads to ownership clashes in the cache > directory. > > No matter if the change is due to setuid or because of some the script itself > changes > the id. > > So... is there > a) any way to "request" that the whole archive is extracted *completely* into > the cache? > or > b) what would you think about a solution where all cache entry access (esp > writing) is > ONLY done with the real user id, not the effective user id? Try installing Archive::Unzip::Burst on the dev machine. If it succeeds, it will be packed into the executable and everything will be extracted on the first invocation. Roderich's concerns, however, remain valid. a setuid pp'd executable is not guaranteed safe.\ Best regards, Steffen
Re: Socket.dll is not packed - Why?
Hi Johannes, Johannes Kilian wrote: Thanks for your clear analysis! That's exactly the problem - never thought about this. In the described case, "socket.pm" (wrong case) is required by a CPAN module which is not in my hand (so I can point with my fingers to others ;-) ... It's great that for the first time in the history of the internet, everybody involved in a discussion agrees :) As a closing remark: Please file a bug report against said CPAN module! I'd suggest that afterwards, you should investigate using a different module for the same purpose (if there is one) since I have some superstitious doubts about the quality of a module that makes this particular mistake. Cheers, Steffen
Re: Socket.dll is not packed - Why?
Hi Roderich, thank you, once again, for your analysis of the problem! Roderich Schupp wrote: The module's name is actually Socket.pm (not the uppercase S). Usually you'll get away with "use socket;" because of Windows' case insensitive filesystem. But not in this case (note that a packed executable is also a zip file, you can just run unzip etc on it): While it'd be nice to do the user-friendly thing and warn about such issues whereever possible, I don't think this is a PAR bug. Loading a module using the wrong name is an accidental "feature" of the module loading mechanism. I vote "not a bug". --Steffen PS: IMNSHO case-insensitive file systems must die.
Re: par and devel::declare on win32
Roderich Schupp wrote: Why don't we get rid of the whole name mangling scheme and extract everything with its "original" pathname as given in the zip? This would eliminate a lot of (often duplicated) code. Even the ugly dynaloader hack could go or am I missing something here? At first glance, we have one of two simple choices: - Extract everything into the same directory: => dll's being named after the last part of the module in question, we will get lots of clashes of files called "XS.dll" (dll == so == ...) - Extract everything in the usual directory layout. Append all the directories to PATH or LD_LIBRARY_PATH. => limited env variable length is a problem. Now, the DLL's for XS modules needn't be in PATH/LD_LIBRARY_PATH. So if we do this: - extract those in the usual directory structure - extract /shared/*.dll and /*.dll to a special dir in PATH/LD_LIBRARY_PATH Then we should be fine, right? Of course, extraction will be a bit slower due to the extra directories. What else? You can't link against those XS libs with -lFoo. But I'm not aware of anyone doing that, but they all go via the name, right? Cheers, Steffen
Re: [rt.cpan.org #60697] Switch to pp pack only architecture-independent (pure-perl) code
Dorian Taylor (Lists) wrote: I sent a message two weeks ago that didn't get an answer. I rated the "bug" as "Wishlist". Did I misstep somehow? No. I think filing your wish as a "wishlist" type bug was perfectly fine. I do agree with Roderich, though. Adding another option to pp is likely not a good idea. I think you're having an X/Y problem. --Steffen
Re: [rt.cpan.org #60697] Switch to pp pack only architecture-independent (pure-perl) code
Tue Aug 24 15:52:08 2010: Request 60697 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #60697] Switch to pp pack only architecture-independent (pure-perl) code Broken in: (no value) Severity: Wishlist Owner: Nobody Requestors: dor...@cpan.org Status: open Ticket http://rt.cpan.org/Ticket/Display.html?id=60697 > Hi, > Tue Aug 24 14:07:40 2010: Request 60697 was acted upon. > I propose that PAR::Packer be given a switch to strip out > architecture-dependent (i.e. XS) modules from the dependency inclusion > list when packing a PAR. If I missed a method of doing this, then please > direct me to it. I suggest that you take a look at PAR::Dist::FromCPAN. It can generate individual .par files for CPAN distributions (and follow dependencies!). It can also merge the result. Since you want to exclude XS modules, you may want to skip the merging bit. Use the automatic detection of XS modules and then delete all produced .par files that aren't "anyarch". Thereafter, you can merge the remaining, pure-Perl .par's with, I believe, the merging function of PAR::Dist. Obviously, this is easily scripted. Best regards, Steffen
Re: [rt.cpan.org #59616] Can't spawn "parlGmV73vs.exe": No error at C:/Perl/site/lib/PAR/Packer.pm line 1
Thu Jul 22 08:23:05 2010: Request 59616 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: Re: [rt.cpan.org #59616] Can't spawn "parlGmV73vs.exe": No error at C:/Perl/site/lib/PAR/Packer.pm line 1 Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: christian.pe...@datenforensik.eu Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=59616 > Hi Chris, Christian Perst via RT wrote: > i tried to pack on a XP Pro with SP3: we'll need some more information. Consider the following: - What version of Perl are you running? Perl 5.10.0 is incompatible with PAR::Packer. If you're using that, you'll have to upgrade to 5.10.1 or 5.12.X. - Where did you install PAR::Packer from? Your screenshot shows you're using ActivePerl and PPM, but is the copy of PAR::Packer entirely compatible with your build of perl? It's usually a difficult question to answer unless you've compiler PAR::Packer yourself. You can install a C compiler from PPM by installing (I think) the MinGW package. Then simply use the normal CPAN client to install PAR::Packer "cpan PAR::Packer". - Try upgrading PAR and PAR::Packer to the most recent version Cheers, Steffen
Re: Compressing pp generated exes
Xaero wrote: > I dunno what this problem is: I wrote a simple test and would > appreciate if someone could provide feedback. > > #creating a.exe that prints: hello! pp -e "print q(hello!)" > > #timing 15runs perl -MBenchmark -e "$start=Benchmark->new;print > qx(aux1.exe hello) for > 1..15;$stop=Benchmark->new;print(timestr(timediff($stop,$start)))" Try re-running that after the initial run. The first run of PAR executables will be very slow. > Can someone test and let me know if they are seeing a 10 sec > difference? I guess it would be smaller on faster computers (mine is > quite old). 1.5 CPU seconds for the whole 15 runs, i.e. .1 s per invocation. Admittedly, this is a fast laptop. Cheers, Steffen
Re: Compressing pp generated exes
Xaero wrote: Good that it uses zip but it doesn't look like there is a way to make read from the par archive without creating a intermediate tempfile. Whether I use perl -MPAR or parl it always unpacks to the TEMP folder. Is there anyway to prevent decompression to TEMP? No. perl -MPAR=foo.par ... will only uncompress Perl code on demand. Shared libraries are (IIRC) always extracted That's as good as it'll get because you cannot portably load shared libraries from memory. There is a branch that loads pure-Perl modules from memory, but that cannot work in the general case. Sometimes, it even violates user expectations. Cheers, Steffen
Re: Compressing pp generated exes
Hi all, Roderich Schupp wrote: Steffen and I independently did some experiments that show that one can roughly half the size by simply storing it zipped (using zlib). [...] Fortunately, Compress::Raw::Zlib seems to have succeeded in doing this, so we might just steal their solution. But it's still the part that will consume the most tuits, so don't hold your breadth. For the record, I won't be able to work on my hacks in the next couple (3-4) weeks at all due to travel. I'll be mostly offline, too. Either way, my attempts were just checking whether there is an existing libz.a to link against. I wasn't even trying to build it myself. If somebody were to try and make it work for real, starting from Roderich's work would be better. Cheers, Steffen
Re: pp fails with IO::Socket::SSL on strawberry perl 5.12
Hi all,
Roderich Schupp wrote:
On Wed, Jun 9, 2010 at 7:20 PM, Xaero wrote:
You should read the pp pod which has a lot of useful options,
infact if you have a few minutes then there is some fantastic
documentation in the PAR-Packer tarball contrib folder by Alan
Stewart.
You mean contrib/docs/{where_is_it,who_am_i}.txt? I didn't know about
it either :(
You didn't? Wow! It really needs better advertisement then. contrib/ has
a bunch of useful things. Did you ever add your extraction script there?
That would be a good candidate for inclusion.
Is it anywhere else in more accessible location?
One should probably convert it to POD format and check for outdated
information (it appears to have been written in 2004). Patches
welcome in either case, of course .
There may be a few more modes of operation for the extraction nowadays.
I'm thinking of my Archive::Unzip::Burst shortcuts.
I'll try to mark it up correctly for the next release so that it will
be shown on the PAR::Packer CPAN page under the "Documentation"
section.
I totally agree. It's good documentation and I'm still sad that Alan
stopped participating in PAR.*.
The one gripe I have with the document is that it's talking about the
guts of how things work rather too much for most users. I'm guessing
that's why it's hidden in contrib (or because of licensing?). Then
again, the case at hand shows that users sometimes need to be aware of
the underlying mechanisms to address their needs.
It's a trade-off. But in the end, it's probably better to let the user
decide what part of the documentation he wants to read. PAR::Environment
leaks quite a few dirty secrets already.
Cheers,
Steffen
Re: pp fails with IO::Socket::SSL on strawberry perl 5.12
Hi Ulli, Ulli Horlacher wrote: My application (*) does https communication. How can I tell pp to include this libeay32_.dll? pp has the -l option for this purpose: -l, --link=FILE|LIBRARY Add the given shared library (a.k.a. shared object or DLL) into the packed file. Also accepts names under library paths; i.e. "-l ncurses" means the same thing as "-l libncurses.so" or "-l /usr/local/lib/libncurses.so" in most Unixes. May be specified multiple times. Maybe it's sufficient to add "-l eay32_" to the pp invocation? If not, you can try with the explicit path. Funny dll name, by the way. Cheers, Steffen
Re: [rt.cpan.org #57852] install PAR::Packer failed for strawberry perl 5.12.0.1
Hi all, I'm taking this reply off the bug tracker since this isn't related to the bug. Ulli Horlacher via RT wrote: I cannot see if the mail is coming from a maintainer or a user. I thought RT-replies are always from the maintainers? There is only a very fine line between a maintainer and a user when it comes to PAR. And this is coming from both a maintainer AND a user :) I'm more than half-serious. Roderich has been doing an incredible job at helping people, fixing bugs, and generally keeping the ball rolling for quite a while now. Some time back, I was doing a lot of that. Maybe in a half year, it'll be you or somebody else entirely? The reason I'm putting it this way is because there's no explicit nor implied responsibility of maintaining the software. That's why the term maintainer, though not entirely wrong, may be misleading. Anybody fixing bugs is making a donation of his time. The difference between the mailing list and the bug tracker is that in the latter, issues should be kept fairly separated. Otherwise it becomes extremely annoying to try and find out what the actual issue was and how it could be fixed. I'm not saying the following is the case here, but let me add that in general, bug reports which are really help requests from users can become fairly problematic from a maintainer point of view. That's what the mailing list is for. Best regards, Steffen
Re: compressed loadme
Hi all, Steffen Mueller via RT wrote: Except that statically linking a libz for some minor compression and reduction of the executable file size would be really cool. Not saying *you* should do that, mind you. I thought about this some more and did some experimenting. a) par.pl can't be (simply) compressed because its string is used in the signature generation, it seems. b) Just compressing libperl roughly halves the size of the resulting Hello World executable. We could save even more if we had to include another library (cf. the recent bug report). In my experiment, I got as far as finding the right libz options for static and dynamic linking, telling file2c to do compression, compressing the output in file2c using Compress::Zlib, and marking the binary blob in the resulting C code as compressed. I just read up on the zlib C interface and while it's conceptually the same as Compress::Zlib (surprise), it shows that C is a horrible language and my C even more so. That is to say it's too annoying to serve as a distraction from more important work, so I'll punt for now. I guess the only difficult part that remains to be done is to modify the WRITE_* macros that are generated by file2c so that they take into account the compression. This seems difficult only because of the obscure "chunk" logic. If anybody else would like to get a copy of my changes, let me know. I simply didn't commit them in a branch since they're really quite hackish. Cheers, Steffen
Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll
Tue Jun 01 05:01:25 2010: Request 57948 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #57948] Bug report: pp-generated executable and a missing dependency libgcc_s_sjlj-1.dll Broken in: (no value) Severity: (no value) Owner: RSCHUPP Requestors: m...@iki.fi Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=57948 > RSCHUPP via RT wrote: >Queue: PAR-Packer > Ticket https://rt.cpan.org/Ticket/Display.html?id=57948 > > > On Sun May 30 08:20:47 2010, mark.doot...@znix.com wrote: >> I don't think you can mix and match your linking model on Windows. So if >> you had a static perl.exe (or par.exe) you could not then load separate >> xs code dynamically - you would have to compile in all the xs modules >> you require. That's why, by default, you don't get a static perl built >> on MSWin. It is not generally useful. > > Thanks for the explanation, Mark. > I'll hold my nose and try the "load_me_3" approach then, stay tuned. Hey, I survived modifying the load_me stuff, too! But I probably have lower standards :) More seriously, I'm pretty sure you already know how it works, but it's just a vehicle of embedding an arbitrary file as a variable in C code & extracting it when run. I believe I refactored some of it to be slightly less insane a few years back. It's still totally a kludge, but alas, I don't have a good idea of how we could work around it. Except that statically linking a libz for some minor compression and reduction of the executable file size would be really cool. Not saying *you* should do that, mind you. Cheers, Steffen
Re: Is there something like --use in par?
Hi Ben, Ben Morrow wrote: It looks to me like -X, --exclude=MODULE Exclude the given module from the dependency search path and from the package. If the given file is a zip or par or par executable, all the files in the given file (except MANIFEST, META.yml and script/*) will be excluded and the output file will "use" the given file at runtime. is what you want. Geez, I think I wrote that bit way back and forgot about it. I'm closing in on 30 quickly. My memory is getting worse and worse. Thanks for pointing this out. Best regards, Steffen
Re: Is there something like --use in par?
Hi Daniel, Steffen Mueller wrote: Download the most recent release of PAR-Packer from CPAN, extract it and go to the contrib/ subdirectory. There is an old tool in there that should be able to make .par files (maybe not executables) dependent on one another. If it just works for .par files, you may have to use parl to generate an executable from the .par file(s) afterwards. I can't check the details right now, sorry. here it is: http://cpansearch.perl.org/src/RSCHUPP/PAR-Packer-1.004/contrib/pare/pare_readme.txt Best regards, Steffen
Re: Is there something like --use in par?
Hi Daniel, I'm on the run, so I'll just reply very briefly. Daniel Lemke wrote: I just discovered your wonderful tool and successfully created my first win32 executable with it. I used PerlApp before but as it is commercial software I'd like to use Par instead. However, I wonder if there's anything like --use in PerlApp, where you can specify another executable so the new executable is only packed with modules that aren't already packaged in the executable you specified in --use. To clarify, the scenario I've got with PerlApp: Foo.exe (contains all the modules I need, so its size is about several megabytes) Anotherfoo.exe (--use Foo.exe, while it's using nearly the same modules its size is only a few kilobytes) Download the most recent release of PAR-Packer from CPAN, extract it and go to the contrib/ subdirectory. There is an old tool in there that should be able to make .par files (maybe not executables) dependent on one another. If it just works for .par files, you may have to use parl to generate an executable from the .par file(s) afterwards. I can't check the details right now, sorry. Best regards, Steffen
Re: [rt.cpan.org #57494] JSON::Any doesn't package in PAR?
Sun May 16 10:22:54 2010: Request 57494 was acted upon.
Transaction: Correspondence added by SMUELLER
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #57494] JSON::Any doesn't package in PAR?
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: thakore.kar...@gmail.com
Status: open
Ticket https://rt.cpan.org/Ticket/Display.html?id=57494 >
Hi Roderich,
Roderich Schupp via RT wrote:
>Queue: PAR-Packer
> Ticket https://rt.cpan.org/Ticket/Display.html?id=57494 >
>
> Following up on my previous post:
>
> - JSON::XS needs "attributes.pm" which can't be autodetected.
> We could add a special rule to Module::ScanDeps for this.
Ah, another one of those ugly implicit dependencies.
> But as it turns out, "attributes.pm" is another one of those modules
> that might be implicitly require'd by the Perl runtime itself
> (like "Errno.pm" or "PerlIO.pm"), I'm inclined to add it to the
> list of "always pack" modules (cf. sub require_modules
> in PAR-Packer/script/par.pl).
>
> @Steffen: What do you think?
I don't think have have a choice other than to do that.
> - JSON needs a special rule in Module::ScanDeps to add all of
>
> JSON/PP.pm
> JSON/PP5005.pm
> JSON/PP58.pm
> JSON/PP
> JSON/PP/Boolean.pm
> JSON/PP56.pm
>
> This will do the trick:
>
> 'JSON.pm' => sub {
> # ignore other JSON::* modules (e.g. JSON::Syck, JSON::Any),
> # but accept JSON::XS (because JSON.pm might use it if present)
> return( grep /^JSON\/(PP|XS)/, _glob_in_inc('JSON', 1) );
> },
This looks correct.
Best regards,
Steffen
PAR::Packer .par binaries
Dear PAR users, for the past few PAR::Packer releases, we haven't bothered to upload new .par binaries for those win32 developers without a compiler. Now, to the best of my knowledge, there are three major win32 Perl distributions: - ActivePerl - Strawberry Perl - cygwin's perl cygwin and Strawberry come with C compilers and should be able to install PAR::Packer directly from CPAN. ActivePerl users can get a MinGW installation from PPM with a single command (citation needed). Do we still need the .par binaries on CPAN? They mean that somebody other than me has to compile then on win32, send them to me, and I upload them to my CPAN directory because the mechanism used by PAR::Packer searches one author directory only. I believe we can drop the binaries since with PAR::Packer, we are targeting developers, not end-users. What do you think? Users of the .par binaries, speak up! Cheers, Steffen
Re: Win32::Exe
Hi Mark, thank you for your work on Win32::Exe. Mark Dootson wrote: Just a note in case anyone is thinking of working on Win32::Exe and has progressed further than I have. I'm neither working on it nor in a position to comment. Win32 stuff is generally inaccessible to me. But I've gone forward and checked with Audrey whether she'd be okay if I assigned co-maintenance permissions for Win32::Exe(?:::.*)? to you. She is okay with that, so now you have the permissions to release Win32::Exe tarballs to CPAN at your discretion. Of course, any discussion and announcements are highly welcome on this list. Let me know if you hit any problems or would like me to do something. Best regards, Steffen
[rt.cpan.org #56442] [patch] 30-current_exec.t fails when the path contains RE meta characters
Sat Apr 10 10:16:12 2010: Request 56442 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: [patch] 30-current_exec.t fails when the path contains RE meta characters Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: d...@debian.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=56442 > Thanks for the report and the fix. I applied your patch. It will be in the upcoming release. --Steffen
[rt.cpan.org #55923] pp not packing distribution share dir contents
Sat Apr 10 10:54:30 2010: Request 55923 was acted upon. Transaction: Correspondence added by SMUELLER Queue: Module-ScanDeps Subject: pp not packing distribution share dir contents Broken in: (no value) Severity: Normal Owner: Nobody Requestors: k...@cpan.org Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=55923 > Thanks applied. Will be in the next Module::ScanDeps release! --Steffen
[rt.cpan.org #54484] Error during install of PAR PAR-0.994
Sat Apr 10 08:17:08 2010: Request 54484 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: Error during install of PAR PAR-0.994 Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: dpw@web.de Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=54484 > Rejected, since the required additional information wasn't given. A reply will reopen this ticket. If not, send me an email. --Steffen
[Fwd: CPAN Upload: S/SM/SMUELLER/PAR-Packer-1.003.tar.gz]
Dear PAR folks, FYI! --Steffen --- Begin Message --- The uploaded file PAR-Packer-1.003.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SM/SMUELLER/PAR-Packer-1.003.tar.gz size: 191376 bytes md5: c084a8ed6822c2d5a88b66151085ccc6 No action is required on your part Request entered by: SMUELLER (Steffen Müller) Request entered on: Sat, 10 Apr 2010 17:56:59 GMT Request completed: Sat, 10 Apr 2010 17:57:58 GMT Thanks, -- paused, v1049 --- End Message ---
PAR release
Dear all, I just uploaded PAR 1.000 to CPAN with a fix for a deprecation warning (defined %hash) for the upcoming perl 5.12.0. I'll try to do a PAR::Packer release later today. Don't hold your breath. Cheers, Steffen
Re: [rt.cpan.org #56171] Can't locate PerlIO.pm
Thu Apr 01 03:09:47 2010: Request 56171 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #56171] Can't locate PerlIO.pm Broken in: 1.002 Severity: Critical Owner: Nobody Requestors: dji...@cpan.org Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=56171 > Hi Roderich, RSCHUPP via RT wrote: > Hmmm... We had a similar problem with Errno.pm. This will > implicitly be require'd whenever someone treats $! as a string. > We ended up adding Errno.pm to the list of modules that > will always get packed in. Maybe we should do the same with > PerlIO.pm? This would add a paltry ~20 KB to every pp'ed executable. I agree that this is likely the cleanest solution. It's a problem that's easy to fix for us, easy to fix for users (-M), but very hard to actually track down for curious users and that's precisely the ones we don't want to punish :) Cheers, Steffen
Re: [rt.cpan.org #56171] Can't locate PerlIO.pm
Hi Roderich, RSCHUPP via RT wrote: Hmmm... We had a similar problem with Errno.pm. This will implicitly be require'd whenever someone treats $! as a string. We ended up adding Errno.pm to the list of modules that will always get packed in. Maybe we should do the same with PerlIO.pm? This would add a paltry ~20 KB to every pp'ed executable. I agree that this is likely the cleanest solution. It's a problem that's easy to fix for us, easy to fix for users (-M), but very hard to actually track down for curious users and that's precisely the ones we don't want to punish :) Cheers, Steffen
Re: [rt.cpan.org #55923] pp not packing distribution share dir contents
Thu Mar 25 09:52:46 2010: Request 55923 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #55923] pp not packing distribution share dir contents Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: k...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=55923 > Hi there, kmx via RT wrote: > I have tried to create a PAR archive from a perl script using a module with so > called share dir (see > http://search.cpan.org/dist/Module-Install/lib/Module/Install/Share.pm or > http://search.cpan.org/dist/File-ShareDir/lib/File/ShareDir.pm). > > What I have expected is that in my_perl_script.pl does "use > MyModule::WithShare;" that PAR packer will also include the content of > distribution share dir of the distribution containing MyModule::WithShare. > However the resulting PAR file does not seem to contain files installed into > dist share dir. > > I am not saying this is a bug; maybe I have not specified some necessary > parameter when running pp command (I simply run: pp -o test.par > my_perl_script.pl) or perhaps this issue should be discussed somewhere else > (Module::ScanDeps?). > > Some details about my test environment: > - Win32 Strawberry Perl 5.10.1 > - PAR::Packer 1.002 > - Module::ScanDeps 0.96 > > Could you please give me some hint on how to get share dir content into a PAR > archive? I gues that it should be possible as there exists File::ShareDir::PAR > that solves a problem how to find share dir inside PAR (I am currently not > even > able to create such a PAR). > > Thanks in advance for any feedback. Essentially, you'll have to use the -a (or -A) option of pp to manually add files to the .par file. Module::ScanDeps has no way to determine that/whether a given module has "share"-like data attached. Or maybe it could find out, but I don't think it does. (Patches welcome!) Cheers, Steffen
Re: [rt.cpan.org #55923] pp not packing distribution share dir contents
Thu Mar 25 10:54:08 2010: Request 55923 was acted upon.
Transaction: Correspondence added by SMUELLER
Queue: PAR-Packer
Subject: Re: [rt.cpan.org #55923] pp not packing distribution share dir
contents
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: k...@cpan.org
Status: open
Ticket https://rt.cpan.org/Ticket/Display.html?id=55923 >
Hi,
kmx via RT wrote:
> Well, let us say at some point we know that we need to bundle
> Some::Module IMHO it is quite straightforward to determine where is the
> sharedir corresponding to Some::Module - something like this: $dir =
> module_dir('File::ShareDir'); - via Find::ShareDir. Then we have just to
> decide where in PAR structure should the content of sharedir has to be
> copied (perhaps somewhere under lib/auto/share/...).
>
> Do I understand that it is more a question on Module::ScanDeps than
> PAR::Packer?
Hmm. Not really, it's both. IMHO M::SD should flag a module as "this has
share-type data!" and PAR::Packer needs to recognize that and pack it.
Maybe it should do so only if a specific option is present, but I think
it's a reasonable default.
Regarding the location inside the PAR:
A .par is more or less the same as a blib/ directory of a freshly-built
CPAN distribution. If you run "perl Makefile.PL && make" for something
that uses, eg., Module::Install::Share to handle share-type data, this
will tell you where the stuff should go in the PAR file. I believe it's
the same location as in the installed case.
Best regards,
Steffen
Re: [rt.cpan.org #55923] pp not packing distribution share dir contents
Hi there, kmx via RT wrote: I have tried to create a PAR archive from a perl script using a module with so called share dir (see http://search.cpan.org/dist/Module-Install/lib/Module/Install/Share.pm or http://search.cpan.org/dist/File-ShareDir/lib/File/ShareDir.pm). What I have expected is that in my_perl_script.pl does "use MyModule::WithShare;" that PAR packer will also include the content of distribution share dir of the distribution containing MyModule::WithShare. However the resulting PAR file does not seem to contain files installed into dist share dir. I am not saying this is a bug; maybe I have not specified some necessary parameter when running pp command (I simply run: pp -o test.par my_perl_script.pl) or perhaps this issue should be discussed somewhere else (Module::ScanDeps?). Some details about my test environment: - Win32 Strawberry Perl 5.10.1 - PAR::Packer 1.002 - Module::ScanDeps 0.96 Could you please give me some hint on how to get share dir content into a PAR archive? I gues that it should be possible as there exists File::ShareDir::PAR that solves a problem how to find share dir inside PAR (I am currently not even able to create such a PAR). Thanks in advance for any feedback. Essentially, you'll have to use the -a (or -A) option of pp to manually add files to the .par file. Module::ScanDeps has no way to determine that/whether a given module has "share"-like data attached. Or maybe it could find out, but I don't think it does. (Patches welcome!) Cheers, Steffen
"autoreply" spam
Dear all, recently, there was a lot of presumably unintentional "auto-reply" spam via the RT interface. But you knew that. It was hard to miss. Several people complained to the responsible party, including me. Their reaction was with apparent willingness to help, but no concrete action. The solution (from last night, on the perl.org side of things) has been to unsubscribe somebody. I hope this doesn't happen again and apologize for the time it's taken to resolve the issue. Best regards, Steffen
Re: [rt.cpan.org #55358] Cannot package GTK on Windows --> Ref #[1ML0X977iO03C4x]
Hi Dave, Dave Howorth wrote: announcement via RT wrote: Thank you for contacting NetZero. Thank you for spamming us. Could somebody unsubscribe this robot? I can't. It's not listed as a watcher! It shouldn't even be getting the mails unless David's (the requestor)'s address is somehow triggering that. Cheers, Steffen
Re: [rt.cpan.org #42986] PAR-based modules use system XS modules over included modules
Mon Feb 08 03:46:09 2010: Request 42986 was acted upon.
Transaction: Correspondence added by SMUELLER
Queue: PAR
Subject: Re: [rt.cpan.org #42986] PAR-based modules use system XS modules
over included modules
Broken in: 0.984
Severity: Important
Owner: Nobody
Requestors: t...@cpan.org
Status: open
Ticket http://rt.cpan.org/Ticket/Display.html?id=42986 >
Hi Toby, hi Roderich,
RSCHUPP via RT wrote:
>Queue: PAR
> Ticket https://rt.cpan.org/Ticket/Display.html?id=42986 >
> I think what happens is a kind of chicken and egg problem:
>
> - your .par contains different versions of File::Temp etc
> than installed on the target machine
>
> - conceptually we would like "perl -MPAR foo.par"
> to behave like
> - extract file.par into temporary directory /tmp/foo123
> - run "perl -I/tmp/foo123 /tmp/foo123/foo.pl"
> (i.e. "/tmp/foo123" is at the start of @INC)
>
> - in order to get to the modules in the .par file, PAR.pm
> needs some modules, e.g. File::Temp
>
> - hence it already has loaded the target system's File::Temp
> before it even gets to consider the (different) copy included
> in the .par
>
> All modules cited in your report are in this category
> "required by PAR.pm to extract stuff from a .par file".
> (Digest::SHA1 is a special case that's even weirder.)
>
> Sorry, I see no sane way to make this work.
I agree. No sane way. But you may try to do something like this. I would
probably not do it in production.
- Pack Class::Unload into your .par.
- Load the .par file (using system File::Temp)
- Load Class::Unload.
- Extract File/Temp.pm from the .par file into the appropriate location
of the temporary storage location. Just have a look, the layout is
basically a normal lib/ dir. PAR.pm has hooks for loading the contents
of a file from any loaded .par file.
- Run Class::Unload->unload('File::Temp')
- require File::Temp
This may or may not work. It's certainly one of the uglier hacks I've
suggested in the past.
Best regards,
Steffen
Re: [rt.cpan.org #54145] PAR::Dist does not try to verify that "Build" is not a directory before trying to execute it.
Sat Jan 30 10:35:19 2010: Request 54145 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Dist Subject: Re: [rt.cpan.org #54145] PAR::Dist does not try to verify that "Build" is not a directory before trying to execute it. Broken in: 0.46, 0.47 Severity: Normal Owner: Nobody Requestors: csjew...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=54145 > Hi Curtis, > Sat Jan 30 01:49:24 2010: Request 54145 was acted upon. > Transaction: Ticket created by CSJEWELL >Queue: PAR-Dist > Subject: PAR::Dist does not try to verify that "Build" is not a > directory > before trying to execute it. >Broken in: 0.46, 0.47 > Severity: Normal >Owner: Nobody > Requestors: csjew...@cpan.org > Status: new > Ticket https://rt.cpan.org/Ticket/Display.html?id=54145 > > > > This issue makes it impossible to package the current version of Wx > (0.96), as it includes a "build" directory, as per the output below. > > [output starts after "perl Makefile.PL" has been executed in that > directory.] > > This should be simple enough to fix that I can send a patch, if you'd > like and if it'd get fixed even faster. > > C:\Wx-0.96>perl -MPAR::Dist -eblib_to_par > Can't open perl script "Build": Permission denied > No such file or directory at C:/strawberry/perl/site/lib/PAR/Dist.pm > line 169. > > C:\Wx-0.96>dir B* > Volume in drive C has no label. > Volume Serial Number is 6C4E-EE8B > > Directory of C:\Wx-0.96 > > 01/29/2010 11:37 PM build >0 File(s) 0 bytes >1 Dir(s) 2,455,281,664 bytes free Damn case insensitive file systems :) I'd appreciate a patch. This weekend is quite busy, but I promise I'll try to apply&release next week. Thanks for bringing this up! Best regards, Steffen
Re: Problems building PAR::Packer on win32
hi Josh, jdwy...@joshua.raleigh.nc.us wrote: It's compiling as we speak, thanks for the help! I notice a lot of these details are missing from the documentation... I'd like to volunteer to update/generate some documentation, if possible. that would be great. I don't think we have a document that describes platform specific installation issues. Depending on the amount of information, we could either put things in a general INSTALL text file or into INSTALL.$platform ones. Thanks for volunteering! Best regards, Steffen
Re: Cannot locate own modules
Hi Nele, Nele Kosog wrote: Here is what I am trying to do: I would like to use "pp -o program.exe my_program.pl" in my_project folder to create an executable: my_project/ - my_program.pl - my_module.pm - my_sub_folder/ o my_other_module.pm My problem is: pp and the resulting program.exe can't locate "my_module.pm". It dies saying [...] I tried the following commands in directory my_project but the error messages doesn't change: pp -M my_module.pm -o program.exe my_program.pl pp -M my_project::my_module -o program.exe my_program.pl pp -l ./ -o program.exe my_program.pl The -l is only for shared libraries (dlls). The -M takes a module name, not a file name. So the "-M my_module.pm" is wrong. You want this: pp -I . -o my_program.exe my_program.pl Or possibly pp -I . -I my_sub_folder -o my_program.exe my_program.pl The latter applies if you want to load "use my_other_module" and not "use my_sub_folder::my_other_module". If you don't load some modules explicitly in your program (and neither in the modules it loads), then you may have to add a few -M directives. Again, -M takes module names, not file names. Thus also the "-I PATH" options. Best regards, Steffen
[rt.cpan.org #52407] pp creates par-/ in /, not /tmp
Thu Dec 17 16:01:48 2009: Request 52407 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: pp creates par-/ in /, not /tmp Broken in: 1.001 Severity: Normal Owner: RSCHUPP Requestors: sw...@cpan.org Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=52407 > Fixed PAR::Packer 1.002 was just uploaded to PAUSE. Thanks for reporting (and fixing!) this issue.
Re: [rt.cpan.org #52407] pp creates par-/ in /, not /tmp
Thu Dec 17 08:13:34 2009: Request 52407 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Re: [rt.cpan.org #52407] pp creates par-/ in /, not /tmp Broken in: 1.001 Severity: Normal Owner: RSCHUPP Requestors: sw...@cpan.org Status: resolved Ticket http://rt.cpan.org/Ticket/Display.html?id=52407 > RSCHUPP via RT wrote: >Queue: PAR-Packer > Ticket https://rt.cpan.org/Ticket/Display.html?id=52407 > > > On Wed Dec 16 11:17:59 2009, SWMCD wrote: >> On Mon Dec 07 11:02:34 2009, RSCHUPP wrote: >>> Steven, can you try the attached patch? >>> >>> It corrects the broken usage of sprintf in myldr/mktmpdir.c. >> This patch fixes the problem on our system. > > Thanks for testing. Patch committed, will be in the next release. ... which I'll try to push out ASAP, but not today. Thanks for fixing this particularly ugly issue. Best regards, Steffen
[rt.cpan.org #52407] pp creates par-/ in /, not /tmp
Sat Dec 05 06:41:48 2009: Request 52407 was acted upon.
Transaction: Correspondence added by SMUELLER
Queue: PAR-Packer
Subject: pp creates par-/ in /, not /tmp
Broken in: 1.001
Severity: Normal
Owner: RSCHUPP
Requestors: sw...@cpan.org
Status: open
Ticket https://rt.cpan.org/Ticket/Display.html?id=52407 >
Hi,
On Fri Dec 04 11:24:50 2009, RSCHUPP wrote:
> I know what's goin' on: does a C construct like
>
> sprintf(stmpdir, "%s other %stuff", stmpdir, ...);
>
> (in mlydr/mktempdir.c) ring a bell?
> The big question is: this code has been in there for ages -
> why does it break now?
Quite honestly... I have no good idea. Looking at the differences to
0.991, there is some change to myldr/mktempdir.c:
--- myldr/mktmpdir.c(revision 7467)
+++ myldr/mktmpdir.c(local)
@@ -160,6 +160,29 @@
if (progname == NULL)
progname = argv[0];
+/* If invoked as "/usr/bin/parl foo.par myscript.pl" then progname
should
+ * be ".../parl", and we don't want to base our checksum on that, but
+ * rather on "foo.par".
+ */
+{
+#ifdef WIN32
+#define STREQ(a,b) (strcasecmp(a,b) == 0)
+#else
+#define STREQ(a,b) (strcmp(a,b) == 0)
+#endif
+ int prog_len = strlen(progname);
+ int parl_len = strlen(PARL_EXE);
+
+ if (prog_len >= parl_len
+ && STREQ(progname + prog_len - parl_len, PARL_EXE)
+ && (prog_len == parl_len || progname[prog_len - parl_len -
1] == dir_sep[0])
+ && argv[1]
+ && strlen(argv[1]) >= 4
+ && STREQ(argv[1] + strlen(argv[1]) - 4, ".par"))
+ progname = argv[1];
+#undef STREQ
+}
+
if ( !par_env_clean() && (f = open( progname, O_RDONLY |
OPEN_O_BINARY ))) {
lseek(f, -18, 2);
read(f, buf, 6);
@@ -176,6 +199,7 @@
}
else {
/* "$TEMP/par-$USER/cache-$SHA1" */
+ lseek(f, 0, 0);
sha_init( &sha_info );
while( ( j = read( f, buf, sizeof( buf ) ) ) > 0 )
{
[rt.cpan.org #50641] Not recognized dependencies in Modules YAML and Maketext
Sun Nov 29 06:20:30 2009: Request 50641 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Not recognized dependencies in Modules YAML and Maketext Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: g...@transsolar.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=50641 > Marking as resolved. Just reply to reopen. --Steffen
[rt.cpan.org #51611] [Patch] POD nit
Sun Nov 29 06:36:52 2009: Request 51611 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Dist Subject: [Patch] POD nit Broken in: 0.46 Severity: (no value) Owner: Nobody Requestors: f...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=51611 > Thanks for the report and patch. I'll release a fixed PAR::Dist 0.47 shortly.
PAR::Packer release!
Dear all, I uploaded PAR::Packer 1.000 (what would have been 0.993) to PAUSE yesterday afternoon. Thanks to everyone who made this release possible. Specifically, thanks to Roderich for tracking down and fixing the latest bug. Best regards, Steffen PS: Yes. 1.000. No particular reason except this 0.X is getting silly.
Re: Help needed for PAR::Packer 0.993
Hi Roderich,
Roderich Schupp wrote:
Looks like I was ultimately responsible for this problem, because I made
packed executables ignore PERL5LIB, PERL5OPT etc and
myldr/par and myldr/static are just the prototypical packed executables.
That makes sense. I wouldn't simply put the blame on you, though. Fixing
bugs is so often a trade-off.
This sounds quite likely. I think adding PAR and friends to
configure_requires would be an acceptable workaround.
Or try the following patch, which defers adding -I options corresponding to @INC
to the invocation of myldr/static (and myldr/par) from "perl Makefile.PL" time
to "make" time. I had to add the two line script myldr/run_with_inc.pl because
inlining it ("perl -e ...") led to all kinds of quoting problems.
If you apply this patch: is there a deeper reason that (in the
original myldr/Makefile.PL)
$lib_path comes _before_ "-I../myldr/.. -I../blib/lib" in the command
"$par ...",
but _after_ in the command "$par_exe ..."? My patch treats both as in
the "before" case.
Everything works on my perls after applying (as before). For lack of a
better test, I'll upload a new dev release _06 in a minute.
Cheers,
Steffen
Re: Help needed for PAR::Packer 0.993
Hi Roderich, thanks a lot for your analysis! Roderich Schupp wrote: I had a brief look at the linux column., esp. the UNKNOWN: make failed with "Can't locate PAR/Heavy.pm in @INC" entries. Is it possible that the latest CPAN.pm has changed the way the configure_requires parameter works, i.e. when are missing requires/config_requires are resolved? It looks as if CPAN 1.9402 works this way: (1) satisfy all config_requires (2) perl Makefile.PL (3) satisfy requires (4) make Now "perl Makefile.PL" builds (from @INC) a list of -Idir options that are burned into Makefile. Later, these are passed to myldr/static which uses these directories to find modules like PAR::Heavy. Now PAR is _not_ listed in"configure_requires", hence its temporay build directory is not in @INC at (2). PAR _is_ listed in "requires", hence it is downloaded and built during (3) and its temporay build directory is in @INC at (4). But that's too late. To fix: either add PAR (and possibly others) to "config_requires" or generate the parameters for myldr/static dynamically at make time. This sounds quite likely. I think adding PAR and friends to configure_requires would be an acceptable workaround. Cheers, Steffen
Help needed for PAR::Packer 0.993
The last stable release of PAR::Packer was approximately eight months ago. Since then, various important bug fixes have accumulated and I made a total of five developer release. A new release is overdue. However, looking at the CPAN Testers Matrix for the last two dev releases, I see a lot of FAIL and UNKNOWN in the test reports. See for yourself: http://matrix.cpantesters.org/?dist=PAR-Packer 0.992_05 http://matrix.cpantesters.org/?dist=PAR-Packer 0.992_04 It's still fine in 0.992_03 and earlier: http://matrix.cpantesters.org/?dist=PAR-Packer 0.992_03 Now, I'm starved for time as usual. Are there any volunteers willing to check the FAIL and UNKOWN test reports against the changes between 0.992_03 and 0.992_04 to see what made PAR::Packer so fragile? Cheers, Steffen
[rt.cpan.org #49002] Event.pm dependency: pp fails to find Event/idle.pm
Fri Nov 13 05:16:06 2009: Request 49002 was acted upon. Transaction: Correspondence added by SMUELLER Queue: Module-ScanDeps Subject: Event.pm dependency: pp fails to find Event/idle.pm Broken in: 0.94 Severity: (no value) Owner: Nobody Requestors: jo...@pobox.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=49002 > This should be resolved in the current Module::ScanDeps release.
[rt.cpan.org #50641] Not recognized dependencies in Modules YAML and Maketext
Fri Nov 13 05:26:37 2009: Request 50641 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: Not recognized dependencies in Modules YAML and Maketext Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: g...@transsolar.com Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=50641 > Hi, On Mon Oct 19 06:11:09 2009, g...@transsolar.com wrote: > I have 2 problems with the pp tool on Windows xp. > First: I can't generate a par file if the Module YAML and Maketext are > used > > > 1. Problem: Dependencies are not recognised > > > I have a small test program, which shows this. > testparpacker.pl works > pp -p -o test.par testparpacker.pl > #no error message > parl test.par > # leads to an error: > The Modul Data::Dumper is not recognized. I can't reproduce this. Eventhough this is Linux (I have no win32), it seems unlikely to be a win32<->linux issue. > If I try to include it with pp -p -M Data::Dumper -o test.par > testparpacker.pl > There will be no error, but the same error message after program > start. Try extracting the par file (it's a ZIP). Does it have the Data::Dumper .pm and .dll files? Data::Dumper is a core modules. Does using the -B option help? > Can't locate Data/Dumper.pm in @INC (@INC contains: CODE(0x11490fc) > C:\DOKUME~1\mgut\LOKALE~1\Temp\par-mgut\cache- > 946ce7a4f68d72a75ac3d1ac3892bcbfb0f86d7d\inc\lib > C:\DOKUME~1\mgut\LOKALE~1\Temp\par-mgut\cache- > 946ce7a4f68d72a75ac3d1ac3892bcbfb0f86d7d\inc > CODE(0x1090ef4) . CODE(0x10910d4)) at YAML/Base.pm line 162. > Compilation failed in require at script/testparpacker.pl line 3. > BEGIN failed--compilation aborted at script/testparpacker.pl line 3. > > Also if I copy the modul by hand in the Par File (test2.par) I get a > similar error: > > Can't locate loadable object for module Data::Dumper in @INC (@INC Copying by hand is error prone for XS modules since you have to set up the correct shared library paths, etc. > Also the language-Files for the Module Maketext are not included in > the > par-File I'm not very familiar with the Locale::Maketext setup. I presume the language files are installed as some sort of "shared" data. You may have to add them manually to the package using the -a switch. I don't think there is a way for Module::ScanDeps to detect dependencies on non-Perl resources. > One problem seems to be, that scandeps.pl does not find the modules. ( > The result of scandeps.pl is included in the zip-file -> scan.txt) > 2. Problem: Can't generate exe files with ActiveState Perl version > v5.10.1 > > with Version v5.10.1 pp crashes if I want to generate a exe-file. > This seems to be a general problem. I found the same error message > when > I google the problem, but found no solution until now: > > Set up gcc environment - 3.4.5 (mingw-vista special r3) > Can't load 'C:/Programme/Perl/lib/auto/IO/IO.dll' for module IO: > load_file:Die angegebene Prozedur wurde nicht gefunden at > C:/Programme/Perl/lib/XSLoader.pm line 70. > at C:/Programme/Perl/lib/IO.pm line 11 > Compilation failed in require at C:/Programme/Perl/lib/IO/Handle.pm > line > 266. > BEGIN failed--compilation aborted at > C:/Programme/Perl/lib/IO/Handle.pm > line 266. > Compilation failed in require at C:/Programme/Perl/lib/IO/Seekable.pm > line 101. > BEGIN failed--compilation aborted at > C:/Programme/Perl/lib/IO/Seekable.pm line 101. > Compilation failed in require at C:/Programme/Perl/lib/IO/File.pm line > 133. > BEGIN failed--compilation aborted at C:/Programme/Perl/lib/IO/File.pm > line 133. > Compilation failed in require at -e line 448. > C:\Programme\Perl\site\bin/pp: Failed to extract a parl from > 'PAR::StrippedPARL::Static' to file 'parldHkYm2V.exe' at > C:/Programme/Perl/site/lib/PAR/Packer.pm line 1155, line 1. How did you install PAR::Packer? Your version of PAR::Packer has to be compatible with your perl build. Try installing PAR::Packer from source. It should fix your second problem. Cheers, Steffen
Re: [rt.cpan.org #50747]
Fri Nov 13 03:49:01 2009: Request 50747 was acted upon. Transaction: Correspondence added by nj88ud...@sneakemail.com Queue: PAR-Packer Subject: Re: [rt.cpan.org #50747] Broken in: 0.992_04 Severity: (no value) Owner: Nobody Requestors: pl...@patterner.de Status: new Ticket http://rt.cpan.org/Ticket/Display.html?id=50747 > Hi, Joerg Plate via RT wrote: > Thu Oct 22 07:26:04 2009: Request 50747 was acted upon. > Transaction: Ticket created by PATTERNER >Queue: PAR-Packer > Subject: (No subject given) >Broken in: 0.992_04 > Severity: (no value) >Owner: Nobody > Requestors: pl...@patterner.de > Status: new > Ticket https://rt.cpan.org/Ticket/Display.html?id=50747 > > > > In function 'open', > inlined from 'my_mkfile' at static.c:34: > /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' > declared with attribute error: open with O_CREAT in second argument > needs 3 arguments there is now a fix for this from Roderich in the trunk. Roderich's change (which goes back to Marcela Maslanova, if I'm not mistaken) uses 0777 for the permissions. It seems safer to use 0644 here as suggested by Jörg. I'll make a final dev release with 0777 and we can potentially change this before the next stable release. I want to push that out ASAP, though. Cheers, Steffen
PAR::Packer dev release 0.992_05
Dear PAR users, I just uploaded a new developer version of PAR::Packer to PAUSE. It contains important bug fixes that weren't part of the previous developer release. And the previous dev release contains myriads of improvements over the latest stable release. Please test! Cheers, Steffen
Re: Wxpar compiled on Linux RH4 generates errors when running on LinuxRH5
Hi David, Erez David wrote: I am trying to create an executable using wxpar which will work on both Linux RH4 and Linux RH5.. For this purpese I am using Linux RH4 32bit. Unfortunately, there's long been an issue with running PAR::Packer generated binaries from RH4 on RH5. It's a recurring one that's regularly raised on par@perl.org (including a recent post by yourself). It's also an issue that *seems* to be isolated to RedHat Linuxes. I've never used RedHat and do not plan to do so. Therefore, I can't debug it. Nobody else has managed to do so. Your specific issue may or may not be the same as the historic one since it's using tons of "external" Wx shared libraries. I'm sorry to be of so little help. I hope somebody else can fill the gap. Maybe Mark Dootson, the author of wxpar, has something to contribute to this? Best regards, Steffen
Re: [rt.cpan.org #49387] Should File::ShareDir::PAR build-require PAR?
Fri Sep 11 03:40:26 2009: Request 49387 was acted upon. Transaction: Correspondence added by nj88ud...@sneakemail.com Queue: File-ShareDir-PAR Subject: Re: [rt.cpan.org #49387] Should File::ShareDir::PAR build-require PAR? Broken in: 0.05 Severity: (no value) Owner: Nobody Requestors: alex.pet...@strategicdata.com.au Status: open Ticket http://rt.cpan.org/Ticket/Display.html?id=49387 > Hi Alex, http://alexpeters.net/ via RT wrote: > On Thu Sep 03 03:43:05 2009, SMUELLER wrote: >> I can see where you're coming from and I'd be willing to apply the >> patch, but it'll take at least a modification of the test suite to skip >> the PAR-related tests if PAR couldn't be loaded. If you could also >> provide that, I'll apply both patches and cut a release. > > Thanks, Steffen. I will get back to you soon with code, test and > document patches. not to rush you, but I'd hate if this got lost. Did you make any progress? Best regards, Steffen
Re: Please test PAR::Packer 0.992_04
Hi all, Steffen Mueller wrote: After a slight poke from Alexandr, I just uploaded PAR::Packer 0.992_04 to CPAN. Please give it a whirl so I can make it a stable release soonish. silly me. Forgot to mention you can also get it from svn: http://svn.openfoundry.org/par/PAR-Packer/tags/PAR-Packer-0.992_04 Cheers, Steffen
Please test PAR::Packer 0.992_04
Dear PAR users, After a slight poke from Alexandr, I just uploaded PAR::Packer 0.992_04 to CPAN. Please give it a whirl so I can make it a stable release soonish. Cheers, Steffen
Re: [rt.cpan.org #49387] Should File::ShareDir::PAR build-require PAR?
Hi Alex, http://alexpeters.net/ via RT wrote: On Thu Sep 03 03:43:05 2009, SMUELLER wrote: I can see where you're coming from and I'd be willing to apply the patch, but it'll take at least a modification of the test suite to skip the PAR-related tests if PAR couldn't be loaded. If you could also provide that, I'll apply both patches and cut a release. Thanks, Steffen. I will get back to you soon with code, test and document patches. not to rush you, but I'd hate if this got lost. Did you make any progress? Best regards, Steffen
[rt.cpan.org #49387] Should File::ShareDir::PAR build-require PAR?
Thu Sep 03 03:43:05 2009: Request 49387 was acted upon. Transaction: Correspondence added by SMUELLER Queue: File-ShareDir-PAR Subject: Should File::ShareDir::PAR build-require PAR? Broken in: 0.05 Severity: (no value) Owner: Nobody Requestors: alex.pet...@strategicdata.com.au Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=49387 > Hi Alex, I'll include a full copy of your bug report here since I only just added the PAR mailing list as CC. On Wed Sep 02 22:50:23 2009, http://alexpeters.net/ wrote: > Hello Steffen, > > I am working on code that we intend to deploy in two styles: > > 1. as a standard installation (/usr/share/perl5, etc.) > 2. as a stand-alone PAR > > Since this code uses shared files, File::ShareDir::PAR seems to be a > perfect tool to accommodate for both cases. > > My understanding is that File::ShareDir::PAR intends to be a drop-in > replacement for File::ShareDir--that is, if one is not operating under > PAR, File::ShareDir::PAR delegates to File::ShareDir. > > To me, this suggests that File::ShareDir::PAR should be able to operate > independently of PAR. However, File::ShareDir::PAR lists PAR as a build > dependency. > > I understand that when File::ShareDir::PAR actually needs to call PAR, > it requires a minimum PAR version. Therefore, I think I understand why > PAR is listed as a build dependency: you want to ensure that > File::ShareDir::PAR does not attempt to operate with an outdated version > of PAR. > > However, since my code uses File::ShareDir::PAR even when PAR is not in > use, PAR becomes a dependency for installations where it will never be > required. > > To work around this, I am continuing to use File::ShareDir and > dynamically requiring File::ShareDir::PAR when I detect that PAR is in > use. Consequently, I am also doing the PAR version checking myself. > > In order to Debian-package File::ShareDir::PAR for internal deployment, > I am also manually removing the PAR dependency. This feels like an > incorrect way to solve the problem, but it is necessary for me to ensure > that a Debian-packaged standard installation of my code does not depend > on libpar-perl. > > To cut to the chase: given my use case, do you feel that it could be > appropriate to change PAR from a required build dependency to a > conditional dynamic runtime dependency? This would make > File::ShareDir::PAR a true drop-in replacement for File::ShareDir, since > it would work as expected without a PAR installation. > > I don't know whether the attached modification of _par_in_use would be > sufficient, but your consideration and feedback would be much > appreciated. :) > > Best wishes from Melbourne, Australia. > > --Alex Peters I can see where you're coming from and I'd be willing to apply the patch, but it'll take at least a modification of the test suite to skip the PAR-related tests if PAR couldn't be loaded. If you could also provide that, I'll apply both patches and cut a release. Thanks for feeding your improvements back upstream! Best regards, Steffen
[rt.cpan.org #48027] MinGW main.o:main.c:(.text+0xe): undefined reference to `Perl_get_context'
Wed Aug 26 11:01:30 2009: Request 48027 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Packer Subject: MinGW main.o:main.c:(.text+0xe): undefined reference to `Perl_get_context' Broken in: 0.991, 0.992_01 Severity: Critical Owner: Nobody Requestors: Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=48027 > I just applied the supplied patch. Kludge or not, we're not magically growing a better fix. Cheers and thanks, Steffen
[rt.cpan.org #45403] Program too big to fit in memory
Wed Aug 26 10:01:41 2009: Request 45403 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: Program too big to fit in memory Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: richard@freescale.com Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=45403 > Hi Richard, apologies for the delay in replying. On Fri Apr 24 15:28:19 2009, richard@freescale.com wrote: > I'm running PAR & pp on Windows XP to generate a standalone .exe. > Resulting .exe runs on a different computer just fine, but gives a > "Program too big to fit in memory" error on another. Both computers are > running XP as well with at least 1GB RAM. Am running ActivePerl 5.10.0 > Build 1004. Is this a 32 vs. 64bit issue? > The test script is short: [snip test script] This is very, vry likely not at all related to your test script. > I've tried pp -m option without any success. I also tried the > evaluation version of perl2exe with no success. > > I have verified the paging file on both computers and they are bigger > than the 384MB I have. I have also tried running the .exe in > compatibility mode with no success. There doesn't appear to be any > differences for autoexec.nt and config.nt. >From my very distant and limited experience with Windows, you get similar errors if you try to run an executable that was not generated for the platform at hand. Actually, I wouldn't even be surprised if you could simply rename an arbitrary file to an .exe and run it to get the same error. I'll wager that this is not even a PAR bug at all but simply non-binary-compatible systems (and thus marking the bug as rejected, but feel free to reply with more input: It will be automatically reopened! The history of the ticket is NOT erased either!) This is supported by the fact that the entirely unrelated perl2exe tool produces the same problems. As an extra test, you can copy the parl.exe PAR loader from the source to the target machine and try running it. If it doesn't run, you at least know that your perl code is not at all involved in the issue, but that it's a problem with the binary/C/loader part of the tool chain. Cheers, Steffen
[rt.cpan.org #42666] PP on solaris
Wed Aug 26 10:32:09 2009: Request 42666 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: PP on solaris Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: yogesh_da...@i2.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=42666 > I'm marking the ticket as rejected since we never received the requested input. A reply should automatically reopen it, so no information is lost. Cheers, Steffen
[rt.cpan.org #45032] main.pl used as the root perl program for pp creates busy loop
Wed Aug 26 10:22:04 2009: Request 45032 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: main.pl used as the root perl program for pp creates busy loop Broken in: (no value) Severity: Normal Owner: Nobody Requestors: fr...@linux-tips-and-tricks.de Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=45032 > Sorry for the delay in replying. I just implemented this rejection for pp/PAR::Packer and committed it to the repository. It will be in the next release of the modules. Cheers, Steffen
[rt.cpan.org #47511] PAR Revisiion 984 breaks shared library loading
Wed Aug 26 09:41:39 2009: Request 47511 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: PAR Revisiion 984 breaks shared library loading Broken in: (no value) Severity: Critical Owner: Nobody Requestors: smuel...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=47511 > Duplicate of #48240.
[rt.cpan.org #49007] This module emits a lot of uninitialized value warnings
Wed Aug 26 09:35:06 2009: Request 49007 was acted upon. Transaction: Correspondence added by SMUELLER Queue: Module-ScanDeps Subject: This module emits a lot of uninitialized value warnings Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: drol...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=49007 > On Tue Aug 25 18:24:10 2009, DROLSKY wrote: > I've attached a patch which shuts up all the warnings I've seen. All > tests still pass. Hi Dave, thanks for stepping in and providing a patch. I applied it, but I new release will be blocking on another small, pending fix. Feel free to poke me in case I forget. Cheers, Steffen
Re: [rt.cpan.org #48770] $0 is not working when PAR is used
Wed Aug 19 07:37:25 2009: Request 48770 was acted upon. Transaction: Correspondence added by nj88ud...@sneakemail.com Queue: PAR Subject: Re: [rt.cpan.org #48770] $0 is not working when PAR is used Broken in: (no value) Severity: (no value) Owner: Nobody Requestors: mianro...@hotmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=48770 > Hi Miguel, Miguel Angel Rojas Gómez via RT wrote: >Queue: PAR > Ticket http://rt.cpan.org/Ticket/Display.html?id=48770 > >> In general, it is NOT reasonable to expect that a packed program >> will behave absoolutely identical to the original script. PAR tries >> hard and jumps thru several hoops to make some stupid constructs >> magically work out of the box. But there are known cases, where >> it doesn't work and you have to change your expectations and >> your code. > > > > Ok, that would mean that PAR a perl file is not really useful if, as > you mentioned, because perl code behaviour would change. Unless you > really know which functions/contructions are not affected. You're being a bit silly here. PAR's quite useful and employed for deployment of large applications to many tens of thousands of computers worldwide. > Is there a list in which we can take a look at? I think this is something > should be stated in the man pages and CPAN PAR web. There's actually rather few issues. They generally crop up when your code adds assumptions about being able to access the files that a package was loaded from via the file system. OTOH, these things are rarely necessary and usually constitute a code stink anyway. >> Patches welcome, the stuff is in myldr/*.c in the PAR::Packer source. >> You might want to consult the Perl source (mg.c and perl.c in >> particular) to study the contortions Perl has to go thru to >> implement the current behaviour. > > > Thanks! I took a look into it and the behaviour seems as you mentioned. > But anyway, I think argv and envp behaviour should not be changed in a PAR > executable (quite critical if you want to access these option in your code). > > Of course, it seems this is not something trivial but it is something is > impacting > perl coding, and if this is not fixed, it should be reflected somewhere. Documentation patches welcome. Cheers, Steffen
Re: [rt.cpan.org #48614] PAR must NOT evaluate PERL5OPT
Tue Aug 11 07:29:37 2009: Request 48614 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR Subject: Re: [rt.cpan.org #48614] PAR must NOT evaluate PERL5OPT Broken in: (no value) Severity: Important Owner: Nobody Requestors: yn...@mm.st Status: open Ticket http://rt.cpan.org/Ticket/Display.html?id=48614 > Hi, RSCHUPP via RT wrote: >Queue: PAR > Ticket https://rt.cpan.org/Ticket/Display.html?id=48614 > > > I concur, pp'ed executables should ignore PERL5OPT. > The patch below implements that. > Note: I only tested that on Linux. Also, it may now ignore > PERL5OPT where it shouldn't. I agree as well. It also seems unlikely that the change is unportable or otherwise problematic. Roderich, could you apply it to trunk? Cheers, Steffen
Re: Module::ScanDeps is really really slow on Windows + DateTime::Locale
Hi, Roderich Schupp wrote: On Wed, Aug 5, 2009 at 4:07 PM, Tom Koelman wrote: I am currently looking into the code to understand where the slowdown originates exactly, but must admit to having difficulties understanding what's it's doing exactly at all. Currently I determined that _add_info gets called a lot and takes a lot of time in total. If time permits I'll take a more thorough look at it tomorrow. There's definitely some speed to be gained if _get_preload could tell its caller: here are some modules to add to the dependencies, but I just know they don't "use" anything so you don't need to scan them. Besides DateTime::Locale this could probably used for the Unicode modules. *nod* I thought about passing the "skip" hash parameter of scan_deps_static down to _get_preload, so that a custom preload entry could add stuff to the "skip" hash. But the keys of the "skip" hash are of no use to _get_preload's world view: one uses module _names_ , while the other uses actual file paths. Yes, that's unfortunate. However, I think the current Module::ScanDeps is a little buggy, because strace shows that scandeps.pl -e "use DateTime::Locale" scans each DateTime/Locale/*.pm no less than six (6) times and each .../unicore/lib/**.pl four times. Wow! I knew it's buggy (there've been a couple of related bug reports, IIRC), but this is... wow. And ouch. I'd love to fix this, but I can't. Any volunteers? Cheers, Steffen
Re: Packaging a script's dependencies without compiling
Hi, Petar Shangov wrote: I have a script that uses only pure-perl non-core modules, and I would like to pack the script, together with all modules it uses, into a single .pl file. However, I want the modules to be retained in their source format, rather than be compiled to binary. Is this possible with PAR? No. This isn't generally possible at all. Some modules expect to be in their very own file scope. In fact, it's not even all that easy to do for something as simple as PAR::Dist. Cheers, Steffen
Re: Module::ScanDeps is really really slow on Windows + DateTime::Locale
Hi Tom, Tom Koelman wrote: I recently upgraded Module::ScanDeps from 0.89 to 0.90 and noticed a big hit in performance. For me (Windows XP, Strawberry Perl) the following command: scandeps -e "use DateTime" takes about 17 seconds with Module::ScanDeps 0.89 and about 306 seconds with Module::ScanDeps 0.90. Commenting out line 262 ( 'DateTime/Locale.pm' => 'sub', ) gives me back my original scanning time. I added some debug statements, which show me that scanning takes close to a second for every single Locale in DateTime. There's 469 Locales there now, hence the wait. Is there some way in which I can speed up this process? Yes. The easy way is to install the newest version of Module.:ScanDeps from CPAN and use the dependency caching. That means you will only have to bear with the slow DateTime::Locale scanning once. Conceptually, if we know the locales don't add any extra dependencies, we could possible add a special case to prevent it from even trying to scan the locale .pm files and just add them to the list of dependencies instead. For lack of time, I can only say: Patches welcome! Cheers, Steffen
Re: Shared library bug and reusable packaged applications
Hi all, Steffen Mueller wrote: The big news is that you can now use PAR-generated executables to run arbitrary external Perl programs as if they were part of the package. If that sounds to you like a glaring hole with respect to security, then rest assured that one has to enable the feature manually during packaging: pp --reusable -o myapp myapp.pl # works normally ./myapp # runs otherapp.pl with the library that myapp.pl uses ./myapp --par-options --reuse otherapp.pl The main reason for this feature is that it's rather common for programs written in Perl to expect a perl installation to be available. Using the new feature, it's possible to work around that. If you wonder why the command line to run another app looks that obscure, then think twice under which circumstances you would want to do that... Yes, exactly my thought: Obscure it should be. The use case that I had in mind for this whole thing unfortunately requires support for arbitrary perl options. This is much harder to do than simply running an external script because it'd have to be done from the C loader (which would have to parse the command line options) instead of simply patching the par.pl and main.pl loader stages. Furthermore, this is likely hard or impossible to enable or disable at packaging time unless we build multiple parl's and extract one according to whether the feature is desired or not. But down that route lies madness and I don't plan to go any further in the direction. Does anybody have an idea how this could be implemented at all? I would *at least* need the "-c" option which has a profound effect on how the later bootstrapping stages work (or rather don't in that case). Cheers, Steffen
Re: PAR/pp INC dir defect fixed
Hi Markus, Markus Jansen wrote: I have run into a defect others (e.g. Scott Stanton in May 2008) have experienced before. The symptom is "Can't locate IO/file.pm in @INC ..." when calling pp. In short, PAR::StrippedPARL::Base.pm::wirte_parl uses the current's Perl @INC members as -I"" as input to the freshly unpacked parl as part of the compilation process. Unfortunately, the quotes render this input completely useless (and is not needed since @args is later on passed to system() as array. wow, that's quite the embarrassing oversight on my part. Thanks for diagnosing and fixing it! I applied the patch to PAR::Packer trunk and will release a new developer version shortly. Best regards, Steffen
Re: Caching dependencies to speed up the packing process
Hi Christoph, hi all, Ch Lamprecht wrote: I just committed 'cachedeps' pod for pp and test for PAR::Packer to trunk. I just uploaded PAR 0.994 (bug fix), and PAR::Packe 0.992_02 (your cachedeps feature). Cheers, Steffen
Re: Shared library bug and reusable packaged applications
Hi Cosimo, Cosimo Streppone wrote: here's the results of my test run of Par-Packer-0.992_01. PAR-0.993 builds and tests fine for me. This is under Windows Vista, MSVC 2008, perl 5.10.0. Detailed test output follows, but I think the important part is: t/20-pp.31/34 Impossibile avviare l'applicazione specificata. La configura zione della modalità affiancata dell'applicazione non è corretta. Consultare il registro d egli eventi applicazioni per ulteriori informazioni. D:\dev\src\PAR-Packer-0.992_01\blib\script/pp: Cannot open hello.exe for reading: No such file or directory at D:\dev\src\PAR-Packer-0.992_01\blib\lib/PAR/Packer.pm line 1155. That in english should be something like: t/20-pp.31/34 Can't run the specified application. Application configuration "side-mode" ?? is incorrect. Check the application events log for more information. D:\dev\src\PAR-Packer-0.992_01\blib\script/pp: Cannot open hello.exe for reading: No such file or directory at D:\dev\src\PAR-Packer-0.992_01\blib\lib/PAR/Packer.pm line 1155. It refers to a "hello.exe", which is nowhere to be found in the unpacked folder of the distribution. Full test output below: t/00-podskipped: Set environment variable PERL_TEST_POD=1 to test POD t/10-parl-generationok t/20-pp.31/34 Impossibile avviare l'applicazione specificata. La configura zione della modalità affiancata dell'applicazione non è corretta. Consultare il registro d egli eventi applicazioni per ulteriori informazioni. D:\dev\src\PAR-Packer-0.992_01\blib\script/pp: Cannot open hello.exe for reading: No such file or directory at D:\dev\src\PAR-Packer-0.992_01\blib\lib/PAR/Packer.pm line 1155. # Failed test 'pp_gui_tests # amsg572: sub pp_gui_tests cannot system pp --gui --icon hi.ico -o hello.exe hello.pl:No such file or directory: # ' t/20-pp.32/34 # at automated_pp_test.pl line 8445. t/20-pp.34/34 # Looks like you failed 1 test of 34. t/20-pp. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/34 subtests t/30-current_exec...# Please wait t/30-current_exec...ok Test Summary Report --- t/20-pp (Wstat: 256 Tests: 34 Failed: 1) Failed test: 32 Non-zero exit status: 1 Files=4, Tests=69, 421 wallclock secs ( 0.08 usr + 0.03 sys = 0.11 CPU) Result: FAIL Failed 1/4 test programs. 1/69 subtests failed. NMAKE : fatal error U1077: 'C:\dev\perl510\bin\perl.exe' : return code '0xff' Stop. Puh. I have no idea what's happening. Could you try with the previous release of PAR::Packer to see whether it's actually something I broke in this version? Thanks a lot for your help! Cheers, Steffen
Re: Shared library bug and reusable packaged applications
Hi Mario, Mario Kemper wrote: Looks like a solution for this problem as well, right? http://www.nntp.perl.org/group/perl.par/2009/05/msg4070.html it might just be. I'll do some testing and let you know. Just in case anyone else might be interested in this too. That's great, thank you very much! Best regards, Steffen
Re: Caching dependencies to speed up the packing process
Hi, Ch Lamprecht wrote: I still do not know how the dependencies-cache-file option to pp should be named. I used cd|cachedeps but I think it's a poor choice because it's not obvious, that it requires a filename as an argument. I just merged the caching branch back to trunk with some minor changes. I couldn't think of a better option name, so I left it as cd|cachedeps. Unfortunately, my PAR time is running out for today, so I can't do thorough testing. It would be great to have some PAR::Packer tests for the new feature and we definitely need to document it. When that's done, I can't see a reason not to release it upon the unsuspecting world. Cheers, Steffen
Shared library bug and reusable packaged applications
Dear PAR folks, a while ago, when I was trying to fix an issue with PAR::Repository::Client "fallback" loading of shared libraries, I entirely broke the shared library handling of PAR::Packer trunk. After a very long debugging session this afternoon, it turns out that, as usual, the bug is a trivial one. I'm glad I could finally fix this, as there are other things waiting in the pipeline... One of those is merging Christoph's work on dependency caching into the main PAR::Packer release. This isn't done yet because it was blocking on my finishing the *other* significant feature, which in turn was blocking on the aforementioned bug. The big news is that you can now use PAR-generated executables to run arbitrary external Perl programs as if they were part of the package. If that sounds to you like a glaring hole with respect to security, then rest assured that one has to enable the feature manually during packaging: pp --reusable -o myapp myapp.pl # works normally ./myapp # runs otherapp.pl with the library that myapp.pl uses ./myapp --par-options --reuse otherapp.pl The main reason for this feature is that it's rather common for programs written in Perl to expect a perl installation to be available. Using the new feature, it's possible to work around that. If you wonder why the command line to run another app looks that obscure, then think twice under which circumstances you would want to do that... Yes, exactly my thought: Obscure it should be. I've uploaded a developer release of PAR::Packer (0.992_01) to PAUSE. It should propagate to your mirrors soon. I'd very much appreciate test reports. (Until it hits your mirror, you can fetch it and the corresponding PAR release from http://steffen-mueller.net/tmp/PAR-Packer-0.992_01.tar.gz http://steffen-mueller.net/tmp/PAR-0.993.tar.gz ) Cheers, Steffen
Re: Caching dependencies to speed up the packing process
Hi Christoph, apologies for the delay. I was away at a conference. Ch Lamprecht wrote: Steffen Mueller wrote: if anyone would like to take a look at this, checkout from http://svn.openfoundry.org/par/Module-ScanDeps/branches/caching I moved code to Module-ScanDeps, added tests and pod. The option for ScanDeps is now named 'cache_file', scandeps.pl gets a switch '-C CACHEFILE'. I still do not know how the dependencies-cache-file option to pp should be named. I used cd|cachedeps but I think it's a poor choice because it's not obvious, that it requires a filename as an argument. I just did the following: 1) Looked through your M::SD changes and ran tests. Everything seems to be fine. 2) Release Module::ScanDeps one last time without your changes. 3) Merged over intermediate M::SD changes to your branch. Next up are the following: 1) Merge over your M::SD changes to trunk and remove the branch. 2) Release a new Module::ScanDeps with caching capability. 3) Check the PAR::Packer changes and think about the pp option name. 4) Merge over your changes to PAR::Packer. 5) PAR::Packer developer release. 6) Wait. 7) Release stable PAR::Packer with caching. 8) Celebrate! Thanks for your contribution! It's a very good idea and the implementation is solid. The packaging process could really become unnervingly slow at times. Best regards, Steffen
Re: Caching dependencies to speed up the packing process
Hi Christoph, Ch Lamprecht wrote: I will wait until I hear some feedback here. I tested your patch (with slight modifications) and these initial, rough, tests seem to show everything is okay. The patch comes with no tests, however. I think we should figure out a way to add at least a few simple tests. To make all of this easier, I just created a Module::ScanDeps branch "caching" at Module-ScanDeps/tags/caching and the corresponding "caching" branch of PAR::Packer in PAR-Packer/tags/caching. I committed your patch there (including my small adjustments). Please just commit your changes to that branch at will and send a quick reminder to the list if you'd like review. When we (or more importantly you) think the feature is mature (, documented, and somewhat tested), we can just merge the changes over to trunk. There are some things I can think of improving: - Adding some kind of locking to the cache file. Yes, that would be nice. But in reality, I can see little reason to run multiple instances of Module::ScanDeps in parallel... except... can you imagine "pp -j3"? ;P - Loading the required Modules (Digest::MD5 and Storable) at runtime to avoid having to add these to PAR-Packer Prerequisites. Adding dependencies to PAR::Packer is not a problem, actually. It's a developer-only module. Digest::MD5 and Storable are actually core modules, too, so that's even less of a problem. On the other hand, adding dependencies to PAR(.pm) would be very bad. Adding dependencies to Module::ScanDeps is okay if they're not heavy-weight. Don't take this as gospel, though. Just apply reason! - Caching-code could go to a seperate module which would then be used by PAR-Packer - Using a system wide default dependency file. Then one could simply use it like pp --use_cache I'm not sure I like this last point. The caching seems like something the user (developer!) should be aware of. Without caching, we *know* everything is going to work. If the user wonders about the slowness, there should be a friendly hint that --use-cache will fix it. That's just my gut feeling, though. I'm open for discussion. Actually, one more thought: Couldn't a system-wide cache be a mechanism to inject arbitrary code from the system into the pp'd executable? Cheers, Steffen
Re: Caching dependencies to speed up the packing process
Hi Christoph, Ch Lamprecht wrote: if anyone is interested, here is what I am testing at the moment. Added cache_cb to M::SD as described before and using it from PAR-Packer. PAR-Packer gets a cd|cachedeps (filename) option. I use it like 'pp -cd deps.dat -more_options script.pl' or 'pp -cd deps.dat -o test.exe -e "use Tk; tkinit; MainLoop;" 'Works fine for me. I'll try to give it a whirl on the weekend. But no promises: In case I don't get to it then, I won't have any time at all for the next two weeks (conference). Cheers, Steffen
[rt.cpan.org #47511] PAR Revisiion 984 breaks shared library loading
Thu Jul 02 11:33:02 2009: Request 47511 was acted upon. Transaction: Ticket created by SMUELLER Queue: PAR Subject: PAR Revisiion 984 breaks shared library loading Broken in: (no value) Severity: Critical Owner: Nobody Requestors: smuel...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=47511 > Dear self, just a gentle reminder: While implementing reusable executables (./someapp --par-options --reuse FILETOEXECUTE.pl), I discovered that change 984 to PAR (Heavy) totally breaks the shared library loading from extracted executables. Yuck! Patches welcome, but I'll *try* to find some time to look at this painful issue on the weekend. -- Steffen
Re: Module::ScanDeps {type} bug
Hi Christoph, Ch Lamprecht wrote: I made it return 'data' now because it seems that this is what it was intended to return in the past. The bug was caused by a lexical declaration in combination with a conditional statement modifier inside a loop. Unless anybody has objections I'd commit this. seems about right. Thanks! Cheers, Steffen
Re: Caching dependencies to speed up the packing process
Hi Christoph, Ch Lamprecht wrote: There are a lot of dependencies in my app therefore the packing takes some minutes. Now I was making up my mind about the possibility to add a dependencies cache - most of the time my dependencies do not change - and just tried it. It's a quick hack: uses Storable to store/retrieve state inside the pack_manifest_hash method. However it works and I'd like to share it here, maybe as a feature suggestion rather than a patch... That's a wonderful idea! It speeds packing up from minutes to seconds in my case. Btw sorry: Diff is against $VERSION = '0.982' I didn't check before I started... No worries. Thanks for diving into the guts of PAR::Packer to implement the feature! My only criticism is that I somehow feel this would be better put into Module::ScanDeps which does the actual dependency checking. But I have no strong opinion on this. Maybe it's cleaner to keep the functionality in PAR::Packer. What do others think? Some random thoughts: - Would it be better to have only one option "dependency-cache" which will load the file if it exists and write it back to disk after the packer is done scanning the files that aren't covered by the cache? - Maybe use Storable's nstore() for portability of the dumped dependency cache to other computers and perls. Cheers, Steffen
[rt.cpan.org #47209] Missing dependencies with Tk::Widget -> setPalette() (patch)
Mon Jun 22 15:50:30 2009: Request 47209 was acted upon. Transaction: Correspondence added by SMUELLER Queue: Module-ScanDeps Subject: Missing dependencies with Tk::Widget -> setPalette() (patch) Broken in: 0.90 Severity: (no value) Owner: Nobody Requestors: lampre...@cpan.org Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=47209 > Hi Christoph, On Mon Jun 22 03:17:49 2009, ch.l.n...@online.de wrote: > Roderich Schupp via RT schrieb: > > Reading the source of setPalette (in Tk/Widget.pm) this patch > > misses a few widgets. It should look like: > the Modules I didn't include in the list are getting picked up anyway in > presence of 'use Tk': thank you for the patch. I opted for applying Roderich's version since having a few duplicates in @modules seems a better tradeoff than potentially breaking on a future change to Tk.pm. Of course, that can happen anyway, but the explicit dependencies for setPalette should minimize that. Cheers, Steffen
Re: Unable to compile in OS X Leopard (Intel)
Hi, Dodger wrote: It's correct. I can't find cc1 either. Of course, I am not sure why I would need to... I don't have a darwin system to reproduce the problem. Is it really PAR::Packer specific or do you also have problems with other XS modules? If it's PAR::Packer specific, maybe you can fix it by modifying the Makefile that's generated in the myldr subdirectory. Cheers, Steffen
[rt.cpan.org #46848] PAR::Dist fails to install when zip, unzip, and Archive::Zip are all unavailable
Thu Jun 11 03:54:31 2009: Request 46848 was acted upon. Transaction: Correspondence added by SMUELLER Queue: PAR-Dist Subject: PAR::Dist fails to install when zip, unzip, and Archive::Zip are all unavailable Broken in: 0.44 Severity: Normal Owner: Nobody Requestors: m...@cpan.org Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=46848 > Doh. This had been fixed in trunk a long while ago, but I forgot to make a release. Consider it done. Thanks for the bug report!
Re: "pp -B" uses local paths before the packaged script runs
Hi Dusty, Dusty Wilson [Megagram] wrote: With that change to my /usr/local/bin/par.pl (the only par.pl "find / -iname 'par.pl'" found), it still gives me this: Can't locate List/Util/PP.pm in @INC (@INC contains: CODE(0x1d205b0) /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/local/lib/perl/5.10.0/List/Util.pm line 38. Added info: I am testing with this build command: pp -e 'print 123' and then running it on a different box (the one with the seemingly local-perl-related weirdness). just a hunch. Can you try with a pp -e 'use strict; use warnings; print 123,"\n"' again? Shouldn't be different but I seem to recall a bug... Cheers, Steffen
Re: ExtUtils::PerlToExe, and binaries that don't need unpacking
Hi Ben, hi all, Ben Morrow ben-at-morrow.me.uk |newsgroups7| wrote: I'm not sure what you mean by adding features that require a compiler. PAR::Packer requires a compile and the perl headers to build alright. Can you elaborate? pl2exe, as currently implemented, compiles and links a new exe every time it is run. This means it needs a (the) compiler available at runtime, so it wouldn't be possible to make a PPM or some other binary package and install it on a machine without a compiler. PAR::Packer builds parldyn and the rest when the module is installed, so a PPM of PAR::Packer works perfectly well and doesn't require the user to have a compiler. That was quite a thinko on my part. Sorry, it's quite obvious you need a compiler at executable-generation time. I've just looked at it now... It looks as though it will do some of what I want, but I don't really like not being able to see what it's doing. I agree. I think I'll keep working on this stand-alone for now, but see if there is anything that could usefully go into PAR once I've got a bit more working. It might be sensible, for instance, to use pp as the front-end; and it ought to be straightforward to teach PAR to load at least pure-Perl files without unpacking them. That makes sense to me. What's the policy on committing to the par repository? Presumably changes should be discussed here first? (Not that I'm likely to be commiting anything for a while, but it's best to be clear :).) There is no clear policy. If you make any significant changes, it'd be nice if you sent a short mail to the list saying you did so and mentioning what you did. That helps keeping track. But other than that, we can always use the powers of our VCS to undo damage if it occurs. If you plan to do major patching, feel free to discuss it on the list simply because you may get valuable input. Cheers, Steffen
Re: ExtUtils::PerlToExe, and binaries that don't need unpacking
Hi Ben, please accept my apologies for taking such a long time to answer. Ben Morrow wrote: Quoth nj88ud...@sneakemail.com (Steffen Mueller): There's an experimental branch of PAR::Packer/PAR in the PAR repository that does not unpack any Perl modules courtesy of Scott Stanton. Naturally, this is a much bigger problem for shared libraries or arbitrary data files which might be packed alongside the Perl code, so we never managed to sanely merge that into the main line of development. OK, I've had a quick look at that (am I right that the relevant bits are the PerlIO::scalar stuff in /par/PAR-Packer/branches/fastio/script/ par.pl?) and it looks like the most important difference from what I have is that it unpacks into memory. I was trying to avoid that, as well, by using PerlIO::subfile like ex::lib::zip. This is why I'm CC'ing Scott who created the fastio branch. I'm not really all that familiar with his changes. What I have at the moment is up at http://github.com/mauzo/ExtUtils-PerlToExe , if anyone is interested. I've had a (very) quick look. At first sight, I didn't grok most of the code that relates to the ExtUtils::* modules you're using, but I haven't had the time to look at those either. You are right that I was intending to write more than a simple replacement for pl2bat :). My plans were - to write a Perl::Dist subclass that knows how to take a Perl application (in the form of a CPAN distribution) and build an MSI. The idea is to make this MSI behave as much like a generic Win32 application as possible, so it would install its own copy of perl and all needed libraries, and have an app.exe entry point (built with pl2exe). It would also need to be sure not to interfere with, or be interfered with by, any other perl installations on the same machine. To be useful, this would need to be a 'Portable'-type perl. It would also need to be able to work from a directory with spaces in its name. My intention was to start by unpicking the Perl::Dist stuff to understand how it works, and then work out what is currently possible and what isn't. I think a lot of that is still TODO: MSI (high up on Adam's todo list), the ability relocate the installation at will, and the spaces issue. - to extend pl2exe to allow it to create statically-linked executables. My idea was to get around the dll-loading problem by building all the needed extensions statically, then including a zip of the Perl code on the end of the exe the way PAR currently does. It's easy to read Perl from there without unpacking it, using PerlIO::subfile and the code from ex::lib::zip, though there are issues with taint mode. Since most perls in the wild aren't built for static linking, I was assuming I would need another Perl::Dist subclass here that knows how to build one. This would mean I would be using the Perl::Dist dependency logic (following the CPAN dependencies) rather than Module::ScanDeps. There is also the issue of teaching Module::Build how to do static linking, but I was planning to look at that when I got to it :). I don't know how well any of this meshes with what PAR is trying to achieve. For a start, I am assuming a C compiler and sources for everything will be available, which PAR goes to some trouble to *not* assume. I don't know whether maybe that decision could be reversed (or at least, whether features could be added that *do* require a compiler) now that Win32 users have Strawberry Perl: are there any other systems where a compiler is typically not available? (Could they get Strawberry- type distributions too? :) ) I do realise all this is likely to turn into a huge undertaking, but hey, I never got anywhere by being under-ambitious. This all sounds like a very useful tool. I asked you to come here and tell us about your plans in the hope that it may be useful to combine it with PAR. However, what you propose has the same general goal (deployment), but it goes about it quite differently. I'm not sure what you mean by adding features that require a compiler. PAR::Packer requires a compile and the perl headers to build alright. Can you elaborate? By the way, have you looked at Mark Dootson's Cava packager? It's essentially a tool to generate an executable with a lib/ that contains all that's necessary to run the perl app. It's closed source, though. PS: If you don't have write access to the PAR repository already and would like to get access, just let me know and I'll set you up. You'd need an openfoundry username. I don't. I've just signed up to openfoundry as mauzo. I added you as a project admin. Cheers, Steffen
Re: PAR::Repository::Web requires PAR::Repository::Query 0.13, but only 0.12 is available on CPAN
Hi Dusty, Dusty Wilson [Megagram] wrote: Thanks Steffen. If I happen to make any adjustments to it, I'll be sure to get those into the repository. I gave it a quick whirl this morning. I had to add a couple of prerequisites to Makefile.PL that were missing due to changes in Catalyst. It still doesn't pass the tests, also due to Catalyst changes, I presume. If you could track those errors down and fix them, I'd be really grateful. Anyhow: This is all to say you'll need to use the svn trunk version instead of the CPAN release. Cheers, Steffen
Re: PAR::Repository::Web requires PAR::Repository::Query 0.13, but only 0.12 is available on CPAN
Hi Dusty, Dusty Wilson [Megagram] wrote: Do you have a 0.13 version of PAR::Repository::Query? It's not up on the CPAN. Where could I get it otherwise? If possible, can you put it up on the CPAN? Sorry about that. I just uploaded PAR::R::Query 0.14. Thanks for your great code. For sure, PAR::Repository::Web is not great code, it's a proof-of-concept. In fact, I think it might not work with today's versions of Catalyst. Maybe the changes needed are minimal (or maybe it actually works out of the box). If you want to give it a shot and come up with patches, I'm more than willing to give you commit access to the repository. Simply sign up with openfoundry and send me your user name. I'll add you. Cheers, Steffen PS: svn checkout http://svn.openfoundry.org/par for all of PAR::* or svn checkout http://svn.openfoundry.org/par/PAR-Repository-Query svn checkout http://svn.openfoundry.org/par/PAR-Repository-Web for P::R::Query/Web
Re: Module submission ExtUtils::PerlToExe
Hi Ben, hi all, I'm both a PAR maintainer and a PAUSE admin. I'll try to keep the comments on the namespace and the general remarks separate. Perl Authors Upload Server wrote: modid: ExtUtils::PerlToExe description: Build a binary executable from a Perl script similar: PAR::Packer pl2bat Namespace: Depending on where you want to go with the project, maybe a "branded", probably top-level, namespace would be more appropriate. On the other hand, if you're really going to stick to having this a "pl2exe" tool, maybe one of these would be appropriate: ExtUtils::Pl2Exe (conveys the idea that it's about converting perl *scripts*) App::Pl2Exe (see above comment and also stresses that it's a tool similar to pl2bat) I'm also not sure about ExtUtils, but I guess if you don't like the App:: prefix or "branded" namespace ideas, it's as good a place as any. Please let me know what you think. I'm also willing to approve ExtUtils::PerlToExe. rationale: This module builds binary executables from Perl scripts. Unlike PAR, these executables don't need to unpack themselves before running. Currently the module can't pack up an @INC tree along with the script, so it's more of an alternative to pl2bat than to PAR. I'm not entirely convinced ExtUtils is the best place to put this (it hasn't really got anything to do with building extensions), but I couldn't see anywhere better. If you have any suggestions I'd be glad to hear them. I haven't uploaded it yet in case the name changes. Now speaking as "that PAR guy". There's an experimental branch of PAR::Packer/PAR in the PAR repository that does not unpack any Perl modules courtesy of Scott Stanton. Naturally, this is a much bigger problem for shared libraries or arbitrary data files which might be packed alongside the Perl code, so we never managed to sanely merge that into the main line of development. I really like the idea of NOT unpacking the stuff. This temporary storage thing has cost me more hair than my girl-friend likes and it just seems to be such a terrible hack to start with... My plea to you is that instead of starting from zero and then having to reinvent all of the wheels we've been working hard to provide with PAR, you could join the team and try to make it fit in with what we have. I'm actually not sure which way is easier. It's no secret that the PAR code is crufty, but it is for a reason: The problem is a difficult one. But maybe you're just the right guy to solve this? Cheers, Steffen PS: If you don't have write access to the PAR repository already and would like to get access, just let me know and I'll set you up. You'd need an openfoundry username.
Re: Possible issue with DynaLoader and 0.992 on x86_64
Hi Roderich,
CC'ing because my mails seem to take a long time to show up on @perl.org
mailing lists. My return address isn't subscribed.
Roderich Schupp wrote:
- If any repository that's checked for a particular module has it, the
corresponding par file will be downloaded to the computer and loaded with
PAR. Therefore, it'll feed back into the @PAR_INC or @PAR_INC_LAST lists of
loaded pars at that point (see above).
How does that "feeding back into @PAR_INC or @PAR_INC_LAST" work?
I don't see where these are augmented except during PAR.pm's import processing.
That's exactly it. PAR::Repository::Client does this to the downloaded
.par archives: (Client.pm, line 413)
PAR->import( { file => $local_par_file, fallback => ($fallback?1:0) } );
PAR::import pushes the Archive::Zip handles to @PAR_INC or @PAR_INC_LAST
depending on $fallback.
Also, can you explain the following call (in find_par() and find_par_last()):
_find_par_internals([$PAR_INC_LAST[-1]], @args);
What's so special about the last element of @PAR_INC_LAST?
The syntax for _find_par_internals is:
_find_par_internals(
$ary_ref_of_archive_zip_handles,
@stuff_that_relates_to_how_INC_hooks_are_called
);
Let's leave aside upgrading for a moment. It's
_find_par_internals([$PAR_INC[-1]], @args);
in find_par after having just loaded a new .par from a "fallback=>0"
repository. Which means the repository client called
PAR->import({file=>...,fallback=>0}). That call appended the new handle
to the @PAR_INC array. Thus, by selecting the last element, we get the
new A::Zip handle!
Similarly, it's
_find_par_internals([$PAR_INC_LAST[-1]], @args);
in find_par_last after having just (successfully) downloaded and
imported a new PAR archive from a fallback=>1 repository.
The oddball is the case of upgrade-repositories. Those get treated in
find_par (i.e. early in @INC) because they need to override anything on
disk if necessary.
This made me discover two more bugs. It's getting a bit embarrassing...
The wrong logic was: If a PAR archive has been loaded from an
upgrade-repository, it's appended to the fallback list of PAR archives
(wrong, it's not and should be. It's been installed if necessary and
loaded from disk regardless!)
The fix should be to simply remove the "if
($local_file){..._find_par_internals...}" code.
The other bug was that the priority/fallback=>0 repositories weren't
beeing disabled for the "system-local" require() in upgrade_module. This
is fixed in trunk now. Added a local $PAR::PriorityRepositories. A beer
for whoever manages to add tests for that!
Sorry for not getting back earlier on this, got distracted by work :)
I know how that feels!
Cheers,
Steffen
Re: Possible issue with DynaLoader and 0.992 on x86_64
Hi Darian, sorry for the delay in replying. I'm still more or less in bed with a cold. Darian Anthony Patrick wrote: Darian Anthony Patrick wrote: Undefined subroutine &PAR::Heavy::_find_par_internals called at /home/dapatrick/perl5/lib/perl5/PAR/Heavy.pm line 88 I fully qualified the calles to &PAR::_find_par_internals and now I get the following error: Sorry about that. The full qualification of the sub names is now in the trunk. Can't locate loadable object for module Term::ReadKey in @INC (@INC contains: /home/dapatrick/workspace/rentchaser-www/scripts/../lib/perl CODE(0x77ee60) /home/dapatrick/perl5/lib/perl5/x86_64-linux-gnu-thread-multi /home/dapatrick/perl5/lib/perl5 /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . CODE(0x78be90)) at /home/dapatrick/perl5/lib/perl5/PAR/Heavy.pm line 102 This is basically the same as the original error that I reported, except that I don't have Term::ReadKey deployed to both the filesystem and to a PAR repo, I just have it deployed to a PAR repo. So it seems the change didn't correct the issue. My brain's still not up to speed yet, but so far, I'm at a loss what's going wrong. But just to double check this: This is only a problem with fallback => 0? Or is it a "real" regression between 0.991 and 0.992 in that the default "fallback => 1" stopped working? Cheers, Steffen
Re: In pp-packed binary: "Can't locate object method ... Net::DNS::Resolver"
Hi Dusty,
Dusty Wilson [Megagram] wrote:
I get this error:
Can't locate object method "new" via package "Net::DNS::Resolver" at
C:\DOCUME~1\Dusty\LOCALS~1\Temp\par-Dusty\temp-268\7aXWrEXmk3 line 48.
Code: "test.pl" (this is the entire script)
use PAR {
repository => 'http://par.leafbridge.net/',
upgrade => 1,
dependencies => 1,
};
eval('use Megagram::ResolveSRV'); # intentionally don't want this
packaged in the test.exe binary, fails if I don't eval as well
my $rsrv = Megagram::ResolveSRV->new;
my @hosts = $rsrv->resolve('_xmpp-server._tcp.google.com');
use Data::Dumper;
print Dumper(\...@hosts);
Packaged on Windows XP Pro SP1 x86 (intentionally not upgraded for
testing purposes) with Strawberry Perl 5.10.0 x86 using this command:
pp -vvv -z 0 -c -C -M PAR::Repository::Client -M
PAR::Repository::Client::Util -M PAR::Repository::Client::DBM -o
test.exe test.pl
"test.exe" is tested on a separate computer with the same OS and arch.
No perl installation at all on this box.
The C:\strawberry\perl\lib contains "Net::DNS::Resolver" as expected.
The module (N::D::R) is installed via PAR::Repository::Client as
expected.
The par files were created with this command (on the WinXP dev box,
same that runs "pp" above):
cpan2par -v -f --no-docs Megagram::ResolveSRV
Then copied to my repository (Debian Lenny, Perl 5.10.0, Apache
2.2.11) via SCP and then installed into the repository with this
command:
for f in build/*; do parrepo inject -r . -f $f; done
My repository is in /var/www/par (which is also the docroot for this
domain within Apache) and the par files had been SCP'd to the
/var/www/par/build directory. My CWD was /var/www/par as one would
suspect.
Also (not sure if this is related), every time "test.exe" is ran, it
redownloads and reinstalls the modules as if they weren't there to
begin with (though they are there before it runs).
... and have the same version, I suppose.
Very strange indeed. It's not what should happen. If memory serves me
right, it should try to load the module locally, check the repository
index for the version in the repository, and only try to download a .par
file if the module in the repository is newer. Unfortunately, I can't
debug this now. Sorry.
On all non-test boxes (Win and Linux both), I'm using PAR 0.992
installed via CPAN directly (no PPM, DEB, or otherwise).
Am I forgetting to do something somewhere?
From the steps you describe, it seems you're doing everything the way
I'd do it, too.
Re: Possible issue with DynaLoader and 0.992 on x86_64
Hi all, I just committed potential fixes for the two bugs I described in my long mail from a couple of minutes ago. I'd appreciate if you have the trunk version of PAR a whirl. http://svn.openfoundry.org/par/trunk Cheers, Steffen PS: This made me think there's another, more delicate bug lurking in the code that implements static dependencies, but I'll have to think about it some more because I can't think of a simple fix.
Re: Possible issue with DynaLoader and 0.992 on x86_64
Hi Roderich, Roderich Schupp wrote: - How can modifying find_par_last help in implementing "fallback => 0", i.e. "prefer loading modules from a repository over the locally installed modules", when find_par_last is _appended_ to @INC: if a module is already found using the built-in @INC the find_par_last will not be called at all? - If find_par_last works as intended, why is there no corresponding modification for the code path dealing with bootstrapping DLLs, i.e. XS parts? The modification to find_par_last in 0.992 explicitly deals only with .pm files. The function in PAR.pm that replaces DynaLoader::bootstrap still calls _find_par_any. that's a good cue. I have been paying attention but I haven't had the time to debug this. I'll try to do so during this week. Cheers, Steffen
