perl.par http://www.nntp.perl.org/group/perl.par/ ... Copyright 1998-2014 perl.org Sat, 20 Dec 2014 22:38:12 +0000 ask@perl.org RE: [rt.cpan.org #101000] Perl pp error: Nested packages by Jayapal, Pradeep Kumar Hi Roderich, <br/> <br/>Let me try to give a clear picture of my scenario, <br/> <br/>I have a perl script which I am compiling using pp. In the executable returned as output by pp we see few Intel specific paths being mentioned (eg: /&lt;prefix&gt;/intel/&lt;suffix&gt;). To keep it generic and to ensure that Intel specific paths are not used we replace all the occurrence of &quot;intel&quot; with &quot;dummy&quot; in the PP output executable file. <br/>But we see that when we run the executable and another Perl script is called from inside this executable (system call in the original Perl script) we get an error in the lines of, <br/> <br/>Can&#39;t locate warnings.pm in @INC (@INC contains: /&lt;prefix&gt;/dummy/&lt;suffix&gt;) at &lt;perl_script_called_using_systemcall&gt; at line &lt;line_no&gt;. <br/>BEGIN failed--compilation aborted at &lt;perl_script_called_using_systemcall&gt; at line &lt;line_no&gt;. <br/> <br/>The &lt;line_no&gt; and warnings.pm points to &quot;use warnings;&quot; line in the Perl script called from the executable using system calls. Is there way to prevent the PP output executable from controlling @INC for the system calls of Perl scripts inside the executable? <br/> <br/>Regards, <br/>Pradeep <br/> <br/> <br/>-----Original Message----- <br/>From: Das, Angan <br/>Sent: Friday, December 19, 2014 10:56 AM <br/>To: bug-PAR-Packer@rt.cpan.org <br/>Cc: Jayapal, Pradeep Kumar <br/>Subject: RE: [rt.cpan.org #101000] Perl pp error: Nested packages <br/> <br/>Roderich, <br/> <br/>Thanks. I am not sure why Pradeep got stripped off from the mail thread. Anyways, looks like a &#39;bug&#39; to us (from the what we could decipher from the user guide). Now, whether it is a real bug to be fixed or is there is some work around -- I will let you decide. <br/> <br/>Pradeep, could you kindly give some snippets of the error messages you got (hiding relevant Intel IP information) that might help Roderich to give some pointers. Also, please send the same email to &quot;par@perl.org&quot; so that we might get some help from there as well. <br/> <br/>- Angan <br/> <br/>-----Original Message----- <br/>From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] <br/>Sent: Friday, December 19, 2014 4:09 AM <br/>To: Das, Angan <br/>Subject: [rt.cpan.org #101000] Perl pp error: Nested packages <br/> <br/>&lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt; <br/> <br/>On 2014-12-18 16:15:48, angan.das@intel.com wrote: <br/>&gt; Pradeep (from our team) has a recent issue with &#39;pp&#39; -- nested Perl <br/>&gt; packages (used within &#39;included/called&#39; Perl scripts from parent Perl <br/>&gt; script) complain being not found. Environment does not seem to be an <br/>&gt; issue over here, and including all packages within the parent script <br/>&gt; does not help. <br/>&gt; <br/>&gt; Could you kindly help? <br/> <br/>Sorry, rt.cpan.org is a *bug* tracker: clearly state what you were trying to do, what you expected and what you got instead. Your report does not contain anything base a diagnosis on. <br/>Stuff like &quot;need some help&quot; do not belong on the bug tracker, please take them to the PAR mailing list, par@perl.org, instead. <br/> <br/>Cheers, Roderich <br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5935.html Sat, 20 Dec 2014 10:12:55 +0000 Re: Problem with cache files being deleted by Shawn Laffan Thanks for the clarifications about Archive::Unzip::Burst and the lock <br/>process.<br/><br/><br/>The example I was (unclearly) referring to is one where the PAR packed <br/>script tries to re-access packed files which were purged by a clean-up <br/>while the the PAR process is running. An example from my use-case is <br/>when a now-deleted glade file is re-accessed to initialise some new <br/>widgets, and thus would cause exceptions in the application.<br/><br/>There is nothing PAR can do automatically in this case, and nor should <br/>it. It is best left to any packed script and modules to trigger a <br/>re-extraction, or lock these files in the first place. The developer <br/>packing the script can easily adjust their own code to allow for these <br/>cases, but the addition of such re-extraction to dependencies maintained <br/>by others would be more involved or simply unlikely. Any PAR-automated <br/>approach would be fraught and probably fragile. I think this last point <br/>relates back to your earlier comment about not wanting PAR to override <br/>CORE::open, with which I agree.<br/><br/><br/>Regards,<br/>Shawn.<br/><br/><br/>On 19/12/2014 22:57, Roderich Schupp wrote:<br/>&gt;<br/>&gt; On Thu, Dec 18, 2014 at 10:22 PM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt;<br/>&gt; The extractions currently use Archive::Unzip::Burst as the first<br/>&gt; attempt. I don&#39;t know its behaviour, but I assume that if some<br/>&gt; files exist and are locked then it will fail. <br/>&gt;<br/>&gt;<br/>&gt; It&#39;s also protected by the $inc.lock &quot;mutex&quot;, just like the slow path <br/>&gt; (using Archive::Zip).<br/>&gt;<br/>&gt; In that event the approach switches to iterating over<br/>&gt; $zip-&gt;memberNames, so it will still work. (Actually,<br/>&gt; Archive::Unzip::Burst seems not to install on Windows, so the<br/>&gt; latter approach will be the norm on that OS).<br/>&gt;<br/>&gt;<br/>&gt; Probably very few people use it. It&#39;s just a Perl small wrapper around <br/>&gt; InfoZip unzip.<br/>&gt;<br/>&gt; Of course, this won&#39;t fix the issues where files are cleaned up<br/>&gt; while a PAR is running process, <br/>&gt;<br/>&gt;<br/>&gt; Obviously we will only re-extract *missing* files, so no problem with <br/>&gt; locked files here.<br/>&gt;<br/>&gt; so some sort of API sub would still be useful to allow scripts to<br/>&gt; re-extract if file opens fail.<br/>&gt;<br/>&gt;<br/>&gt; That would imply that you are able to know when opening a file from <br/>&gt; &quot;deep inside third party modules&quot; fails - how?<br/>&gt;<br/>&gt; WRT the different cache areas, PAR::_extract_inc currently spends<br/>&gt; up to 10 seconds trying to create a lock file, so that line needs<br/>&gt; to be modified. <br/>&gt;<br/>&gt;<br/>&gt; Nope. It&#39;s not a lock file, it&#39;s a lock *directory*. That&#39;s because <br/>&gt; creation of a directory is the only portable (even network filesystem <br/>&gt; safe)<br/>&gt; filesystem mutex operation. The up to 10 second delay comes only into <br/>&gt; play in the contended case.<br/>&gt;<br/>&gt; Adding a check for -w on the target temp location should be enough<br/>&gt; to avoid that when the exe file is in a non-writable directory.<br/>&gt;<br/>&gt;<br/>&gt; The parent directory of $inc in _extract_inc is writable by <br/>&gt; construction.<br/>&gt;<br/>&gt; Cheers, Roderich<br/>&gt;<br/>&gt;<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5934.html Sat, 20 Dec 2014 02:53:51 +0000 RE: [rt.cpan.org #101000] Perl pp error: Nested packages by Jayapal, Pradeep Kumar via RT Fri Dec 19 18:52:40 2014: Request 101000 was acted upon.<br/>Transaction: Correspondence added by pradeep.kumar.jayapal@intel.com<br/> Queue: PAR-Packer<br/> Subject: RE: [rt.cpan.org #101000] Perl pp error: Nested packages<br/> Broken in: (no value)<br/> Severity: (no value)<br/> Owner: Nobody<br/> Requestors: angan.das@intel.com<br/> Status: rejected<br/> Ticket &lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt;<br/><br/><br/>Hi Roderich,<br/><br/>Let me try to give a clear picture of my scenario,<br/><br/>I have a perl script which I am compiling using pp. In the executable returned as output by pp we see few Intel specific paths being mentioned (eg: /&lt;prefix&gt;/intel/&lt;suffix&gt;). To keep it generic and to ensure that Intel specific paths are not used we replace all the occurrence of &quot;intel&quot; with &quot;dummy&quot; in the PP output executable file.<br/>But we see that when we run the executable and another Perl script is called from inside this executable (system call in the original Perl script) we get an error in the lines of,<br/><br/>Can&#39;t locate warnings.pm in @INC (@INC contains: /&lt;prefix&gt;/dummy/&lt;suffix&gt;) at &lt;perl_script_called_using_systemcall&gt; at line &lt;line_no&gt;.<br/>BEGIN failed--compilation aborted at &lt;perl_script_called_using_systemcall&gt; at line &lt;line_no&gt;.<br/><br/>The &lt;line_no&gt; and warnings.pm points to &quot;use warnings;&quot; line in the Perl script called from the executable using system calls. Is there way to prevent the PP output executable from controlling @INC for the system calls of Perl scripts inside the executable? <br/><br/>Regards,<br/>Pradeep<br/><br/><br/>-----Original Message-----<br/>From: Das, Angan<br/>Sent: Friday, December 19, 2014 10:56 AM<br/>To: bug-PAR-Packer@rt.cpan.org<br/>Cc: Jayapal, Pradeep Kumar<br/>Subject: RE: [rt.cpan.org #101000] Perl pp error: Nested packages<br/><br/>Roderich,<br/><br/>Thanks. I am not sure why Pradeep got stripped off from the mail thread. Anyways, looks like a &#39;bug&#39; to us (from the what we could decipher from the user guide). Now, whether it is a real bug to be fixed or is there is some work around -- I will let you decide.<br/><br/>Pradeep, could you kindly give some snippets of the error messages you got (hiding relevant Intel IP information) that might help Roderich to give some pointers. Also, please send the same email to &quot;par@perl.org&quot; so that we might get some help from there as well.<br/><br/>- Angan<br/><br/>-----Original Message-----<br/>From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org]<br/>Sent: Friday, December 19, 2014 4:09 AM<br/>To: Das, Angan<br/>Subject: [rt.cpan.org #101000] Perl pp error: Nested packages<br/><br/>&lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt;<br/><br/>On 2014-12-18 16:15:48, angan.das@intel.com wrote:<br/>&gt; Pradeep (from our team) has a recent issue with &#39;pp&#39; -- nested Perl <br/>&gt; packages (used within &#39;included/called&#39; Perl scripts from parent Perl<br/>&gt; script) complain being not found. Environment does not seem to be an <br/>&gt; issue over here, and including all packages within the parent script <br/>&gt; does not help.<br/>&gt; <br/>&gt; Could you kindly help?<br/><br/>Sorry, rt.cpan.org is a *bug* tracker: clearly state what you were trying to do, what you expected and what you got instead. Your report does not contain anything base a diagnosis on.<br/>Stuff like &quot;need some help&quot; do not belong on the bug tracker, please take them to the PAR mailing list, par@perl.org, instead.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5933.html Fri, 19 Dec 2014 23:52:49 +0000 RE: [rt.cpan.org #101000] Perl pp error: Nested packages by Das, Angan via RT Fri Dec 19 13:56:16 2014: Request 101000 was acted upon.<br/>Transaction: Correspondence added by angan.das@intel.com<br/> Queue: PAR-Packer<br/> Subject: RE: [rt.cpan.org #101000] Perl pp error: Nested packages<br/> Broken in: (no value)<br/> Severity: (no value)<br/> Owner: Nobody<br/> Requestors: angan.das@intel.com<br/> Status: rejected<br/> Ticket &lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt;<br/><br/><br/>Roderich,<br/><br/>Thanks. I am not sure why Pradeep got stripped off from the mail thread. Anyways, looks like a &#39;bug&#39; to us (from the what we could decipher from the user guide). Now, whether it is a real bug to be fixed or is there is some work around -- I will let you decide.<br/><br/>Pradeep, could you kindly give some snippets of the error messages you got (hiding relevant Intel IP information) that might help Roderich to give some pointers. Also, please send the same email to &quot;par@perl.org&quot; so that we might get some help from there as well.<br/><br/>- Angan<br/><br/>-----Original Message-----<br/>From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] <br/>Sent: Friday, December 19, 2014 4:09 AM<br/>To: Das, Angan<br/>Subject: [rt.cpan.org #101000] Perl pp error: Nested packages<br/><br/>&lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt;<br/><br/>On 2014-12-18 16:15:48, angan.das@intel.com wrote:<br/>&gt; Pradeep (from our team) has a recent issue with &#39;pp&#39; -- nested Perl <br/>&gt; packages (used within &#39;included/called&#39; Perl scripts from parent Perl<br/>&gt; script) complain being not found. Environment does not seem to be an <br/>&gt; issue over here, and including all packages within the parent script <br/>&gt; does not help.<br/>&gt; <br/>&gt; Could you kindly help?<br/><br/>Sorry, rt.cpan.org is a *bug* tracker: clearly state what you were trying to do, what you expected and what you got instead. Your report does not contain anything base a diagnosis on.<br/>Stuff like &quot;need some help&quot; do not belong on the bug tracker, please take them to the PAR mailing list, par@perl.org, instead.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5932.html Fri, 19 Dec 2014 18:56:24 +0000 [rt.cpan.org #101000] Perl pp error: Nested packages by Roderich Schupp via RT Fri Dec 19 07:08:29 2014: Request 101000 was acted upon.<br/>Transaction: Correspondence added by RSCHUPP<br/> Queue: PAR-Packer<br/> Subject: Perl pp error: Nested packages<br/> Broken in: (no value)<br/> Severity: (no value)<br/> Owner: Nobody<br/> Requestors: angan.das@intel.com<br/> Status: new<br/> Ticket &lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt;<br/><br/><br/>On 2014-12-18 16:15:48, angan.das@intel.com wrote:<br/>&gt; Pradeep (from our team) has a recent issue with &#39;pp&#39; -- nested Perl<br/>&gt; packages (used within &#39;included/called&#39; Perl scripts from parent Perl<br/>&gt; script) complain being not found. Environment does not seem to be an<br/>&gt; issue over here, and including all packages within the parent script<br/>&gt; does not help.<br/>&gt; <br/>&gt; Could you kindly help?<br/><br/>Sorry, rt.cpan.org is a *bug* tracker: clearly state what you were trying to do,<br/>what you expected and what you got instead. Your report does not contain anything<br/>base a diagnosis on.<br/>Stuff like &quot;need some help&quot; do not belong on the bug tracker,<br/>please take them to the PAR mailing list, par@perl.org, instead.<br/><br/>Cheers, Roderich<br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5931.html Fri, 19 Dec 2014 12:08:42 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Thu, Dec 18, 2014 at 10:22 PM, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/>wrote:<br/>&gt;<br/>&gt;<br/>&gt; The extractions currently use Archive::Unzip::Burst as the first attempt.<br/>&gt; I don&#39;t know its behaviour, but I assume that if some files exist and are<br/>&gt; locked then it will fail.<br/><br/><br/>It&#39;s also protected by the $inc.lock &quot;mutex&quot;, just like the slow path<br/>(using Archive::Zip).<br/><br/><br/>&gt; In that event the approach switches to iterating over $zip-&gt;memberNames,<br/>&gt; so it will still work. (Actually, Archive::Unzip::Burst seems not to<br/>&gt; install on Windows, so the latter approach will be the norm on that OS).<br/>&gt;<br/><br/>Probably very few people use it. It&#39;s just a Perl small wrapper around<br/>InfoZip unzip.<br/><br/>Of course, this won&#39;t fix the issues where files are cleaned up while a PAR<br/>&gt; is running process,<br/><br/><br/>Obviously we will only re-extract *missing* files, so no problem with<br/>locked files here.<br/><br/><br/>&gt; so some sort of API sub would still be useful to allow scripts to<br/>&gt; re-extract if file opens fail.<br/><br/><br/>That would imply that you are able to know when opening a file from &quot;deep<br/>inside third party modules&quot; fails - how?<br/><br/>WRT the different cache areas, PAR::_extract_inc currently spends up to 10<br/>&gt; seconds trying to create a lock file, so that line needs to be modified.<br/><br/><br/>Nope. It&#39;s not a lock file, it&#39;s a lock *directory*. That&#39;s because<br/>creation of a directory is the only portable (even network filesystem safe)<br/>filesystem mutex operation. The up to 10 second delay comes only into play<br/>in the contended case.<br/><br/>Adding a check for -w on the target temp location should be enough to avoid<br/>&gt; that when the exe file is in a non-writable directory.<br/><br/><br/>The parent directory of $inc in _extract_inc is writable by construction.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5930.html Fri, 19 Dec 2014 11:57:25 +0000 Re: Problem with cache files being deleted by Shawn Laffan The rearguard idea is appealing.<br/><br/>The extractions currently use Archive::Unzip::Burst as the first <br/>attempt. I don&#39;t know its behaviour, but I assume that if some files <br/>exist and are locked then it will fail. In that event the approach <br/>switches to iterating over $zip-&gt;memberNames, so it will still work. <br/>(Actually, Archive::Unzip::Burst seems not to install on Windows, so the <br/>latter approach will be the norm on that OS).<br/><br/>Of course, this won&#39;t fix the issues where files are cleaned up while a <br/>PAR is running process, so some sort of API sub would still be useful to <br/>allow scripts to re-extract if file opens fail. This would not be <br/>simple to apply where file opens are called deep inside third party <br/>modules, but will still benefit the simpler cases.<br/><br/><br/>WRT the different cache areas, PAR::_extract_inc currently spends up to <br/>10 seconds trying to create a lock file, so that line needs to be <br/>modified. Adding a check for -w on the target temp location should be <br/>enough to avoid that when the exe file is in a non-writable directory.<br/><br/>Apart from possible security issues, this approach could also lead to <br/>multiple par temp folders which could confuse users. Of course, being <br/>&quot;up front&quot; about files could be a useful thing to do.<br/><br/><br/>Regards,<br/>Shawn.<br/><br/><br/>On 18/12/2014 19:02, Roderich Schupp wrote:<br/>&gt; Here are two other ideas for a workaround for &quot;some cleanup program <br/>&gt; purged some files in my cache area&quot;.<br/>&gt; The rearguard hack:<br/>&gt;<br/>&gt; * make sure extracted files get the timestamp of extraction, not the<br/>&gt; timestamp recorded in the zip archive<br/>&gt; * add a dummy file, say REARGUARD.txt, at the top of the cache area<br/>&gt; * extract it as the first file (so that it becomes the oldest<br/>&gt; extracted file)<br/>&gt; * at packed executable startup, check that REARGUARD.txt exists,<br/>&gt; otherwise re-extract all files<br/>&gt;<br/>&gt; Different location for the cache area:<br/>&gt;<br/>&gt; * when the packed executable foo.exe is installed as<br/>&gt; /some/path/foo.exe, extract to /some/path/foo.unpacked if this<br/>&gt; directory can be created<br/>&gt; * otherwise fall back to current behaviour, ie. extract to $TMP/par-USER<br/>&gt; * I&#39;m not sure about the security implications<br/>&gt;<br/>&gt; Cheers, Roderich<br/><br/>-- <br/>Assoc Prof Shawn Laffan<br/> School of Biological, Earth and Environmental Sciences<br/> UNSW, Sydney 2052, Australia<br/> Tel +61 2 9385 8093 Fax +61 2 9385 1558<br/> http://www.bees.unsw.edu.au/staff/shawn-laffan<br/> http://www.purl.org/biodiverse (free diversity analysis software)<br/> http://www.tandf.co.uk/journals/ijgis<br/><br/> UNSW CRICOS Provider Code 00098G<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5929.html Thu, 18 Dec 2014 21:23:35 +0000 [rt.cpan.org #101000] Perl pp error: Nested packages by Das, Angan via RT Thu Dec 18 16:15:48 2014: Request 101000 was acted upon.<br/>Transaction: Ticket created by angan.das@intel.com<br/> Queue: PAR-Packer<br/> Subject: Perl pp error: Nested packages<br/> Broken in: (no value)<br/> Severity: (no value)<br/> Owner: Nobody<br/> Requestors: angan.das@intel.com<br/> Status: new<br/> Ticket &lt;URL: https://rt.cpan.org/Ticket/Display.html?id=101000 &gt;<br/><br/><br/>Hi Roderich,<br/><br/>Pradeep (from our team) has a recent issue with &#39;pp&#39; -- nested Perl packages (used within &#39;included/called&#39; Perl scripts from parent Perl script) complain being not found. Environment does not seem to be an issue over here, and including all packages within the parent script does not help. <br/><br/>Probably the main code spawns off a separate process from &#39;pp&#39;-transformed code, and it does not have much clue where to pick up the package from. <br/><br/>Could you kindly help?<br/><br/>- Angan<br/><br/>-----Original Message-----<br/>From: Roderich Schupp via RT [mailto:bug-PAR-Packer@rt.cpan.org] <br/>Sent: Sunday, November 02, 2014 5:54 AM<br/>To: Das, Angan<br/>Subject: [rt.cpan.org #95417] Resolved: Perl pp error: Seeking some info<br/><br/>&lt;URL: https://rt.cpan.org/Ticket/Display.html?id=95417 &gt;<br/><br/>According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message.<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5928.html Thu, 18 Dec 2014 21:15:55 +0000 Re: Problem with cache files being deleted by Shawn Laffan In that case I&#39;ll just skip inc/lib and inc/script, which is simpler <br/>anyway.<br/><br/>Regards,<br/>Shawn.<br/><br/><br/><br/>On 18/12/2014 18:39, Roderich Schupp wrote:<br/>&gt; On Thu, Dec 18, 2014 at 12:18 AM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt; It boils down to checking for par_tmp/inc/MANIFEST and unzipping<br/>&gt; it if needed. None of the -a packed files are listed in the<br/>&gt; manifest, <br/>&gt;<br/>&gt;<br/>&gt; Ooops, that might be considered a bug...<br/>&gt; Cheers, Roderich<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5927.html Thu, 18 Dec 2014 20:50:39 +0000 Re: Problem with cache files being deleted by Roderich Schupp Here are two other ideas for a workaround for &quot;some cleanup program purged<br/>some files in my cache area&quot;.<br/><br/>The rearguard hack:<br/><br/> - make sure extracted files get the timestamp of extraction, not the<br/> timestamp recorded in the zip archive<br/> - add a dummy file, say REARGUARD.txt, at the top of the cache area<br/> - extract it as the first file (so that it becomes the oldest extracted<br/> file)<br/> - at packed executable startup, check that REARGUARD.txt exists,<br/> otherwise re-extract all files<br/><br/>Different location for the cache area:<br/><br/> - when the packed executable foo.exe is installed as /some/path/foo.exe,<br/> extract to /some/path/foo.unpacked if this directory can be created<br/> - otherwise fall back to current behaviour, ie. extract to $TMP/par-USER<br/> - I&#39;m not sure about the security implications<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5926.html Thu, 18 Dec 2014 08:02:53 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Thu, Dec 18, 2014 at 12:18 AM, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/>wrote:<br/>&gt;<br/>&gt; It boils down to checking for par_tmp/inc/MANIFEST and unzipping it if<br/>&gt; needed. None of the -a packed files are listed in the manifest,<br/><br/><br/>Ooops, that might be considered a bug...<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5925.html Thu, 18 Dec 2014 07:39:47 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Thu, Dec 18, 2014 at 12:37 AM, Ron W &lt;ronw.mrmx@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; So, my idea of inserting a BEGIN block, in the program.pl to be packaged,<br/>&gt; that adds files to %INC should work. Then run pp with the -c (or -x)<br/>&gt; option, then those files will be &quot;picked up&quot; by ScanDeps. And the packaged<br/>&gt; program.pl would have a list of the files it might need to re-extract.<br/><br/><br/>Don&#39;t. %INC is for recording loaded _modules_, don&#39;t abuse it that way.<br/><br/>If you are simply looking for a way to record files to be added with -a _in<br/>your script_<br/>(as opposed to remember them in a separate packing recipe) I suggest a<br/>special<br/><br/>=for pp options...<br/><br/>POD command. This idea was tossed around a few years back but AFAICT nobody<br/>stepped up to implement it.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5924.html Thu, 18 Dec 2014 07:38:47 +0000 Re: Problem with cache files being deleted by Shawn Laffan Thanks for clarifying Roderich.<br/><br/>I&#39;ve had a look at sub PAR::_extract_inc and have a plan for a separate <br/>sub which a script can call to re-extract all the files packed using -a.<br/><br/>It boils down to checking for par_tmp/inc/MANIFEST and unzipping it if <br/>needed. None of the -a packed files are listed in the manifest, so we <br/>can then iterate over the inc directory in the zip archive and, if a <br/>file or folder is not in the manifest and is not in par_tmp/inc, then it <br/>can be re-extracted.<br/><br/>If this passes the sanity check then I&#39;ll code something up.<br/><br/><br/>Regards,<br/>Shawn.<br/><br/><br/><br/>On 17/12/2014 20:12, Roderich Schupp wrote:<br/>&gt; On Tue, Dec 16, 2014 at 10:35 PM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt; PAR does add itself to @INC at run time (see example below), so<br/>&gt; maybe adding a packed data folder to %INC, or the end of @INC to<br/>&gt; avoid name clashes, in a BEGIN block the script would be a viable<br/>&gt; workaround. Please do post the results.<br/>&gt;<br/>&gt; That won&#39;t work. @INC is relevant for _loading modules_, ie. &quot;require <br/>&gt; something&quot; (or &quot;use something&quot;, as this impies the former). PAR does <br/>&gt; indeed add itself to @INC, by adding some directories in the cache <br/>&gt; area and by adding a CODE ref that can load modules from the packed <br/>&gt; executable (the zip part) itself.<br/>&gt; But all icons, data files etc are read by the modules themselves using <br/>&gt; standard file reading ops.<br/>&gt; PAR cannot detect this (and hence intercept this). Depending on how <br/>&gt; these modules determine the filesystem location of their data <br/>&gt; (unfortunately there&#39;s no universally adopted approach here) these <br/>&gt; calls _may_<br/>&gt; succeed if the data files have been explicitly packed (with -a).<br/>&gt; Module::ScanDeps also cannot detect this data when it parses your <br/>&gt; script and all required modules.<br/>&gt; It has list of well known modules and their data, though, for example <br/>&gt; all the Unicode data is packed and extracted to the correct location.<br/>&gt; Cheers, Roderich<br/>&gt;<br/>&gt;<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5923.html Wed, 17 Dec 2014 23:18:58 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Tue, Dec 16, 2014 at 10:35 PM, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/>wrote:<br/>&gt;<br/>&gt; PAR does add itself to @INC at run time (see example below), so maybe<br/>&gt; adding a packed data folder to %INC, or the end of @INC to avoid name<br/>&gt; clashes, in a BEGIN block the script would be a viable workaround. Please<br/>&gt; do post the results.<br/>&gt;<br/><br/>That won&#39;t work. @INC is relevant for _loading modules_, ie. &quot;require<br/>something&quot; (or &quot;use something&quot;, as this impies the former). PAR does<br/>indeed add itself to @INC, by adding some directories in the cache area and<br/>by adding a CODE ref that can load modules from the packed executable (the<br/>zip part) itself.<br/>But all icons, data files etc are read by the modules themselves using<br/>standard file reading ops.<br/>PAR cannot detect this (and hence intercept this). Depending on how these<br/>modules determine the filesystem location of their data (unfortunately<br/>there&#39;s no universally adopted approach here) these calls _may_<br/>succeed if the data files have been explicitly packed (with -a).<br/>Module::ScanDeps also cannot detect this data when it parses your script<br/>and all required modules.<br/>It has list of well known modules and their data, though, for example all<br/>the Unicode data is packed and extracted to the correct location.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5922.html Wed, 17 Dec 2014 09:12:29 +0000 Re: Problem with cache files being deleted by Kime Philip This makes sense - the file that was always mentioned was packed with &mdash;addlist which I assume is the same mechanism as -a.<br/><br/>PK<br/><br/>&gt; On 16 Dec 2014, at 11:29 am, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt; wrote:<br/>&gt; <br/>&gt; I had a similar case recently where a user ran CCleaner on the temp folder while the application was open. It deleted everything in the cache folder that was not file locked, so the cache folder still exists, along with several of the component files.<br/>&gt; <br/>&gt; A bit of testing showed the .pm and other perl files are re-extracted the next time the PAR is run, but none of the files packed using -a (an icon file and a glade file in my case).<br/>&gt; <br/>&gt; I ended up adding code to the script to manually check for file existence and, if needed, unpacking from the PAR. It&#39;s not a solution that will scale well, but I only have two such files. Example code is below, but PAR::par_handle is probably simpler now I look at the docs again.<br/>&gt; <br/>&gt; For the more general case, is there a simple means to trigger the re-extraction of all files packed using -a?<br/>&gt; <br/>&gt; Regards,<br/>&gt; Shawn.<br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; ###<br/>&gt; require Archive::Zip;<br/>&gt; my $icon = Path::Class::file ($ENV{PAR_TEMP}, &#39;inc&#39;, &#39;Biodiverse_icon.ico&#39;);<br/>&gt; my $icon_str = $icon-&gt;stringify;<br/>&gt; <br/>&gt; my $folder = $icon-&gt;dir;<br/>&gt; my $fname = $icon-&gt;basename;<br/>&gt; my $zip = Archive::Zip-&gt;new($ENV{PAR_PROGNAME})<br/>&gt; or die &quot;Unable to open $ENV{PAR_PROGNAME}&quot;;<br/>&gt; <br/>&gt; my $success = $zip-&gt;extractMember ( $fname, $icon_str );<br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; On 16/12/2014 21:06, Kime Philip wrote:<br/>&gt;&gt; Yes, that&rsquo;s what I though, just scheduled /tmp cleanup etc. but in fact it seems to happen more often on non-Unix &hellip;<br/>&gt;&gt; Certainly some cases were due to users Ctrl-Cing a first .exe run because they thought it was taking too long (normal for it to take longer on first run of a new version of course, due to unpacking) and then the cache building was incomplete. However, most reports are, they say, &ldquo;suddenly&rdquo; it no longer works and complains about missing files. I can&rsquo;t really explain it. Deleting the cache and running again always fixes it.<br/>&gt;&gt; <br/>&gt;&gt; PK<br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt;&gt; On 16 Dec 2014, at 11:02 am, Roderich Schupp &lt;roderich.schupp@googlemail.com&gt; wrote:<br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; On Mon, Dec 15, 2014 at 9:15 PM, Kime Philip &lt;philkime@kime.org.uk&gt; wrote:<br/>&gt;&gt;&gt; ...regularly we get an error report from users that after a while using the tool, a particular file disappears from the cache and the cache has to be deleted and the binary unpacked again. I have never worked out why this is and it has been a problem for a few years, through many PP versions. You can see the general issue reported here:<br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file<br/>&gt;&gt;&gt; <br/>&gt;&gt;&gt; From what I have seen, when this file is missing, all of the .pm files in inc/ are missing too although I cannot reliably reproduce this. It is a very frequent error from many users on various platforms and I&rsquo;d very much like to find out why it happens &hellip;<br/>&gt;&gt;&gt; I&#39;m fairly confident that PAR::Packer doesn&#39;t meddle with the files in the cache area of<br/>&gt;&gt;&gt; a pp-packed executable. AFAICT there&#39;s nothing in the code to delete files there (except<br/>&gt;&gt;&gt; to purge the whole cache area immediatly after running the executable).<br/>&gt;&gt;&gt; At least for *nix installations I can think of an explanation: administrative cron jobs that clean up<br/>&gt;&gt;&gt; /tmp, /var/tmp etc by purging files not modified for some time. Dunno for Windows, esp.<br/>&gt;&gt;&gt; since the &quot;temp&quot; directories there are typically specific to each user.<br/>&gt;&gt;&gt; Cheers, Roderich<br/>&gt;&gt;&gt; <br/>&gt;&gt; --<br/>&gt;&gt; Dr Philip Kime<br/>&gt;&gt; <br/>&gt; <br/><br/>--<br/>Dr Philip Kime<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5921.html Wed, 17 Dec 2014 00:44:45 +0000 Fwd: Problem with cache files being deleted by Ron W ---------- Forwarded message ----------<br/>From: Ron W &lt;ronw.mrmx@gmail.com&gt;<br/>Date: Tue, Dec 16, 2014 at 10:39 AM<br/>Subject: Re: Problem with cache files being deleted<br/>To: Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/><br/>On Tue, Dec 16, 2014 at 6:16 AM, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/>wrote:<br/>&gt;<br/>&gt; What I&#39;m thinking of is some way for a PAR executable to detect if extra<br/>&gt; files packed using -a are missing, and then unpack them.<br/>&gt;<br/><br/>I just had a thought for a work-around.<br/><br/>When pp script.pl is run, the script is &quot;statically scanned&quot; for<br/>dependencies.<br/><br/>When pp -c script.pl is run, after the static scan, the script is compiled<br/>(like perl -c script.pl). I am thinking that %INC is then inspected for<br/>additional libraries.<br/><br/>So, my idea is, after identifying all the extra files to be included with<br/>-a, go back to the main .pl file and add a BEGIN block that adds those<br/>library names to %INC. Then run &quot;pp -c main.pl&quot; - without any -a options -<br/>then verify the created executable runs correctly.<br/><br/>As I said, I see this as a work-around.<br/><br/>A better solution would be for pp to save the names of all the files<br/>included via -a just as it saves the ones it detects.<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5920.html Tue, 16 Dec 2014 21:44:07 +0000 Re: Problem with cache files being deleted by Shawn Laffan On 17/12/2014 7:50, Ron W wrote:<br/>&gt; On Tue, Dec 16, 2014 at 3:29 PM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt; The issue is that these files are usually not additional<br/>&gt; libraries. They are typically extra files for icons, config,<br/>&gt; data, and the like. That said, they don&#39;t tend to have .pm or .pl<br/>&gt; extensions so maybe this could work.<br/>&gt;<br/>&gt;<br/>&gt; Yes, I&#39;ve had to use -a for icons, config files, etc. The new thing <br/>&gt; (to me) is the partial removal of cached files.<br/>&gt;<br/>&gt; It just occurred to me that %INC was the obvious variable that would <br/>&gt; get updated by &quot;perl -c script.pl &lt;http://script.pl&gt;&quot;. Of course, pp&#39;s <br/>&gt; scanner could be adding its own &quot;instrumentation&quot;, but if that&#39;s the <br/>&gt; case, should not be too hard to see how that works. And then determine <br/>&gt; if a BEGIN block in the script being &quot;scanned&quot; can safely insert <br/>&gt; additional files.<br/>&gt;<br/>&gt; I did do an experiment. I added a BEGIN block to an existing script to <br/>&gt; add an arbitrary file to %INC. As best I can determine, Perl did not <br/>&gt; care. The script ran normally, including all the modules it uses.<br/>&gt;<br/>&gt; I will experiment more. If this does work, then the script will <br/>&gt; contain the list of other resources used both for generating the <br/>&gt; executable and for re-extracting when necessary, at run time.<br/>&gt;<br/><br/>PAR does add itself to @INC at run time (see example below), so maybe <br/>adding a packed data folder to %INC, or the end of @INC to avoid name <br/>clashes, in a BEGIN block the script would be a viable workaround. <br/>Please do post the results.<br/><br/>(BTW, your replies aren&#39;t going to the list).<br/><br/><br/>@INC when running a par exe:<br/>C:\user\svn\bd_releases\biodiverse_0.99_007_win64\lib CODE(0x3289f10) <br/>C:\Users\user\AppData\Local\Temp\par-736861776e\cache-b078428bc6c4b872664f757140eea943a5fb10a3\inc\lib <br/>C:\Users\user\AppData\Local\Temp\par-736861776e\cache-b078428bc6c4b872664f757140eea943a5fb10a3\inc <br/>CODE(0x2f57670) CODE(0x2f57bc8)<br/><br/>Regards,<br/>Shawn.<br/><br/><br/><br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5919.html Tue, 16 Dec 2014 21:37:08 +0000 Re: Problem with cache files being deleted by Shawn Laffan Thanks Ron,<br/><br/>The issue is that these files are usually not additional libraries. They <br/>are typically extra files for icons, config, data, and the like. That <br/>said, they don&#39;t tend to have .pm or .pl extensions so maybe this could <br/>work.<br/><br/>I&#39;ll keep it in mind as I try the explicit approach.<br/><br/>Regards,<br/>Shawn.<br/><br/><br/><br/>On 17/12/2014 2:39, Ron W wrote:<br/>&gt; On Tue, Dec 16, 2014 at 6:16 AM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt; What I&#39;m thinking of is some way for a PAR executable to detect if<br/>&gt; extra files packed using -a are missing, and then unpack them.<br/>&gt;<br/>&gt;<br/>&gt; I just had a thought for a work-around.<br/>&gt;<br/>&gt; When pp script.pl &lt;http://script.pl&gt; is run, the script is &quot;statically <br/>&gt; scanned&quot; for dependencies.<br/>&gt;<br/>&gt; When pp -c script.pl &lt;http://script.pl&gt; is run, after the static scan, <br/>&gt; the script is compiled (like perl -c script.pl &lt;http://script.pl&gt;). I <br/>&gt; am thinking that %INC is then inspected for additional libraries.<br/>&gt;<br/>&gt; So, my idea is, after identifying all the extra files to be included <br/>&gt; with -a, go back to the main .pl file and add a BEGIN block that adds <br/>&gt; those library names to %INC. Then run &quot;pp -c main.pl &lt;http://main.pl&gt;&quot; <br/>&gt; - without any -a options - then verify the created executable runs <br/>&gt; correctly.<br/>&gt;<br/>&gt; As I said, I see this as a work-around.<br/>&gt;<br/>&gt; A better solution would be for pp to save the names of all the files <br/>&gt; included via -a just as it saves the ones it detects.<br/>&gt;<br/><br/>-- <br/>Assoc Prof Shawn Laffan<br/> School of Biological, Earth and Environmental Sciences<br/> UNSW, Sydney 2052, Australia<br/> Tel +61 2 9385 8093 Fax +61 2 9385 1558<br/> http://www.bees.unsw.edu.au/staff/shawn-laffan<br/> http://www.purl.org/biodiverse (free diversity analysis software)<br/> http://www.tandf.co.uk/journals/ijgis<br/><br/> UNSW CRICOS Provider Code 00098G<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5918.html Tue, 16 Dec 2014 20:29:18 +0000 Re: Problem with cache files being deleted by Shawn Laffan Thanks Roderich.<br/><br/>Given the brittleness I&#39;ll aim for a separate sub that would be <br/>explicitly called by the packed script.<br/><br/>Now to find the time to do it...<br/><br/>Regards,<br/>Shawn.<br/><br/><br/>On 17/12/2014 0:04, Roderich Schupp wrote:<br/>&gt; On Tue, Dec 16, 2014 at 12:16 PM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt; What I&#39;m thinking of is some way for a PAR executable to detect if<br/>&gt; extra files packed using -a are missing, and then unpack them.<br/>&gt;<br/>&gt;<br/>&gt; Such a check would defeat the &quot;if the cache area exists, skip <br/>&gt; extracting stuff&quot; logic, so you&#39;ll<br/>&gt; take a hit when starting up. Also there&#39;s a (somewhat crude) lock <br/>&gt; against concurrent<br/>&gt; unpacking of the cache area that you have to keep in mind.<br/>&gt; But most of all: the code base is very brittle and prone to breaking <br/>&gt; stuff at a distance,<br/>&gt; hence I myself won&#39;t touch certain parts unless it&#39;s absolutely <br/>&gt; necessary.<br/>&gt; But if you want to try your hand at hacking: the code that extracts <br/>&gt; all packed files<br/>&gt; (excpet DLLs) into &lt;cache area&gt;/inc is sub _extract_inc in PAR.pm<br/>&gt; Cheers, Roderich<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5917.html Tue, 16 Dec 2014 20:27:59 +0000 Re: PAR and the rest by Juan José 'Peco' San Martín Hi,<br/><br/>In my case:<br/><br/> with --clear =&gt; the first start is faster, but the following are slow<br/> without =&gt; the first start is slower, but the others are very fast<br/><br/>So, in my case it&#39;s better the second option because the application is<br/>executed several times a day.<br/><br/>Thanks!!<br/>Peco<br/><br/>2014-12-16 13:22 GMT+01:00 Ch Lamprecht &lt;ch.l.ngre@online.de&gt;:<br/>&gt;<br/>&gt; Am 16.12.2014 12:57, schrieb Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n:<br/>&gt;<br/>&gt; that the .exe generated is much smaller (and faster in the first run).<br/>&gt;&gt;<br/>&gt;<br/>&gt; Hi,<br/>&gt;<br/>&gt; did you compare with a PAR-exe built with --clean? Startup time on the<br/>&gt; first run is about 3 times faster with --clean than without.<br/>&gt;<br/>&gt; Cheers, Christoph<br/>&gt;<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5916.html Tue, 16 Dec 2014 17:13:43 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Tue, Dec 16, 2014 at 12:16 PM, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/>wrote:<br/>&gt;<br/>&gt; What I&#39;m thinking of is some way for a PAR executable to detect if extra<br/>&gt; files packed using -a are missing, and then unpack them.<br/><br/><br/>Such a check would defeat the &quot;if the cache area exists, skip extracting<br/>stuff&quot; logic, so you&#39;ll<br/>take a hit when starting up. Also there&#39;s a (somewhat crude) lock against<br/>concurrent<br/>unpacking of the cache area that you have to keep in mind.<br/><br/>But most of all: the code base is very brittle and prone to breaking stuff<br/>at a distance,<br/>hence I myself won&#39;t touch certain parts unless it&#39;s absolutely necessary.<br/>But if you want to try your hand at hacking: the code that extracts all<br/>packed files<br/>(excpet DLLs) into &lt;cache area&gt;/inc is sub _extract_inc in PAR.pm<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5915.html Tue, 16 Dec 2014 13:04:46 +0000 PAR and the rest by Juan José 'Peco' San Martín I use PAR::Packer as the best solution for deployment and distribution.<br/>Currently ~ 10.000 distributions and more to come.<br/><br/>The 3 main advantages that I see (reasons to choose PAR versus others)<br/><br/>1) Free software (freedom) and community.<br/>2) I need to deploy the distribution easily (avoid the Perl installation)<br/>but not close the sources. The users can unzip the exe to take a look.<br/>3) Multiplatform, I can PAR-exe for all the platforms I need (Linux,<br/>Windows, OSX and other Unix*s)<br/><br/>Yep, in the other side I see some enhancements opportunities. But this is<br/>good :-)<br/><br/>Somebody know how PerlApp (from ActiveState) works?. I see (at least in my<br/>case) that the .exe generated is much smaller (and faster in the first run).<br/>It seems to have a similar idea but maybe with a better compressor :-?<br/><br/>Peco<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5914.html Tue, 16 Dec 2014 11:58:09 +0000 Re: Problem with cache files being deleted by Shawn Laffan Well, that&#39;s definitely one solution :)<br/><br/>I&#39;m not sure how well that would go when done from within a PAR <br/>executable, since that would presumably lock its source files, and thus <br/>the cache will not be deleted. Doing it within the executable is <br/>simplest for the users, many of whom are unfamiliar with the temp folder <br/>and its contents and tend to steer clear.<br/><br/>What I&#39;m thinking of is some way for a PAR executable to detect if extra <br/>files packed using -a are missing, and then unpack them. Handling of dll <br/>and glue files can remain as-is (it seems they are re-extracted in any <br/>case). Extra files could be explicitly checked for in the script and <br/>then something like a PAR::reextract_extra_packed_files sub could <br/>extract them. Possibly it could handle the existence checks as well. <br/>Essentially it is the same approach I gave in my previous email, but <br/>applied across all extra files.<br/><br/>If I get some pointers to the relevant part of the code base then I <br/>could take a stab at it, without any promises of success of course.<br/><br/><br/>Or have I misunderstood your point about open(), and that&#39;s how they are <br/>currently extracted?<br/><br/>Regards,<br/>Shawn.<br/><br/><br/><br/>On 16/12/2014 21:49, Roderich Schupp wrote:<br/>&gt; On Tue, Dec 16, 2014 at 11:29 AM, Shawn Laffan <br/>&gt; &lt;shawn.laffan@unsw.edu.au &lt;mailto:shawn.laffan@unsw.edu.au&gt;&gt; wrote:<br/>&gt;<br/>&gt; For the more general case, is there a simple means to trigger the<br/>&gt; re-extraction of all files packed using -a?<br/>&gt;<br/>&gt; Simply delete the cache area :)<br/>&gt; Sorry, for .pm and &quot;glue&quot; .dll files the check is automatic as PAR <br/>&gt; intercepts module loading<br/>&gt; and DynaLoader anyway. But all stuff packed with -a is accessed using<br/>&gt; open() calls - I wouldn&#39;t want PAR to replace CORE::open.<br/>&gt; Cheers, Roderich<br/>&gt;<br/>&gt;<br/><br/>-- <br/>Assoc Prof Shawn Laffan<br/> School of Biological, Earth and Environmental Sciences<br/> UNSW, Sydney 2052, Australia<br/> Tel +61 2 9385 8093 Fax +61 2 9385 1558<br/> http://www.bees.unsw.edu.au/staff/shawn-laffan<br/> http://www.purl.org/biodiverse (free diversity analysis software)<br/> http://www.tandf.co.uk/journals/ijgis<br/><br/> UNSW CRICOS Provider Code 00098G<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5913.html Tue, 16 Dec 2014 11:17:44 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Tue, Dec 16, 2014 at 11:29 AM, Shawn Laffan &lt;shawn.laffan@unsw.edu.au&gt;<br/>wrote:<br/>&gt;<br/>&gt; For the more general case, is there a simple means to trigger the<br/>&gt; re-extraction of all files packed using -a?<br/>&gt;<br/><br/>Simply delete the cache area :)<br/>Sorry, for .pm and &quot;glue&quot; .dll files the check is automatic as PAR<br/>intercepts module loading<br/>and DynaLoader anyway. But all stuff packed with -a is accessed using<br/>open() calls - I wouldn&#39;t want PAR to replace CORE::open.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5912.html Tue, 16 Dec 2014 10:49:33 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Tue, Dec 16, 2014 at 11:06 AM, Kime Philip &lt;philkime@kime.org.uk&gt; wrote:<br/>&gt;<br/>&gt; Certainly some cases were due to users Ctrl-Cing a first .exe run because<br/>&gt; they thought it was taking too long (normal for it to take longer on first<br/>&gt; run of a new version of course<br/><br/><br/>Sure - if the next run sees that the cache area (ie. its top level<br/>directory) already exists it assumes<br/>that it is complete and skips the &quot;unpack to cache area&quot; step.<br/><br/>For Windows: Shawn just mentioned CCleaner. Windows itself comes with &quot;Disk<br/>Cleanup&quot; that<br/>will delete &quot;Temporary files&quot; not modified in the last 7 days...<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5911.html Tue, 16 Dec 2014 10:37:21 +0000 Re: Problem with cache files being deleted by Shawn Laffan I had a similar case recently where a user ran CCleaner on the temp <br/>folder while the application was open. It deleted everything in the <br/>cache folder that was not file locked, so the cache folder still exists, <br/>along with several of the component files.<br/><br/>A bit of testing showed the .pm and other perl files are re-extracted <br/>the next time the PAR is run, but none of the files packed using -a (an <br/>icon file and a glade file in my case).<br/><br/>I ended up adding code to the script to manually check for file <br/>existence and, if needed, unpacking from the PAR. It&#39;s not a solution <br/>that will scale well, but I only have two such files. Example code is <br/>below, but PAR::par_handle is probably simpler now I look at the docs again.<br/><br/>For the more general case, is there a simple means to trigger the <br/>re-extraction of all files packed using -a?<br/><br/>Regards,<br/>Shawn.<br/><br/><br/><br/>###<br/>require Archive::Zip;<br/>my $icon = Path::Class::file ($ENV{PAR_TEMP}, &#39;inc&#39;, &#39;Biodiverse_icon.ico&#39;);<br/>my $icon_str = $icon-&gt;stringify;<br/><br/>my $folder = $icon-&gt;dir;<br/>my $fname = $icon-&gt;basename;<br/>my $zip = Archive::Zip-&gt;new($ENV{PAR_PROGNAME})<br/> or die &quot;Unable to open $ENV{PAR_PROGNAME}&quot;;<br/><br/>my $success = $zip-&gt;extractMember ( $fname, $icon_str );<br/><br/><br/><br/>On 16/12/2014 21:06, Kime Philip wrote:<br/>&gt; Yes, that&acirc;&#128;&#153;s what I though, just scheduled /tmp cleanup etc. but in fact it seems to happen more often on non-Unix &acirc;&#128;&brvbar;<br/>&gt; Certainly some cases were due to users Ctrl-Cing a first .exe run because they thought it was taking too long (normal for it to take longer on first run of a new version of course, due to unpacking) and then the cache building was incomplete. However, most reports are, they say, &acirc;&#128;&#156;suddenly&acirc;&#128;&#157; it no longer works and complains about missing files. I can&acirc;&#128;&#153;t really explain it. Deleting the cache and running again always fixes it.<br/>&gt;<br/>&gt; PK<br/>&gt;<br/>&gt;<br/>&gt;&gt; On 16 Dec 2014, at 11:02 am, Roderich Schupp &lt;roderich.schupp@googlemail.com&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt; On Mon, Dec 15, 2014 at 9:15 PM, Kime Philip &lt;philkime@kime.org.uk&gt; wrote:<br/>&gt;&gt; ...regularly we get an error report from users that after a while using the tool, a particular file disappears from the cache and the cache has to be deleted and the binary unpacked again. I have never worked out why this is and it has been a problem for a few years, through many PP versions. You can see the general issue reported here:<br/>&gt;&gt;<br/>&gt;&gt; http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file<br/>&gt;&gt;<br/>&gt;&gt; From what I have seen, when this file is missing, all of the .pm files in inc/ are missing too although I cannot reliably reproduce this. It is a very frequent error from many users on various platforms and I&acirc;&#128;&#153;d very much like to find out why it happens &acirc;&#128;&brvbar;<br/>&gt;&gt; <br/>&gt;&gt; I&#39;m fairly confident that PAR::Packer doesn&#39;t meddle with the files in the cache area of<br/>&gt;&gt; a pp-packed executable. AFAICT there&#39;s nothing in the code to delete files there (except<br/>&gt;&gt; to purge the whole cache area immediatly after running the executable).<br/>&gt;&gt; <br/>&gt;&gt; At least for *nix installations I can think of an explanation: administrative cron jobs that clean up<br/>&gt;&gt; /tmp, /var/tmp etc by purging files not modified for some time. Dunno for Windows, esp.<br/>&gt;&gt; since the &quot;temp&quot; directories there are typically specific to each user.<br/>&gt;&gt; <br/>&gt;&gt; Cheers, Roderich<br/>&gt;&gt; <br/>&gt; --<br/>&gt; Dr Philip Kime<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5910.html Tue, 16 Dec 2014 10:30:11 +0000 Re: Problem with cache files being deleted by Kime Philip Yes, that&rsquo;s what I though, just scheduled /tmp cleanup etc. but in fact it seems to happen more often on non-Unix &hellip;<br/>Certainly some cases were due to users Ctrl-Cing a first .exe run because they thought it was taking too long (normal for it to take longer on first run of a new version of course, due to unpacking) and then the cache building was incomplete. However, most reports are, they say, &ldquo;suddenly&rdquo; it no longer works and complains about missing files. I can&rsquo;t really explain it. Deleting the cache and running again always fixes it.<br/><br/>PK<br/><br/><br/>&gt; On 16 Dec 2014, at 11:02 am, Roderich Schupp &lt;roderich.schupp@googlemail.com&gt; wrote:<br/>&gt; <br/>&gt; On Mon, Dec 15, 2014 at 9:15 PM, Kime Philip &lt;philkime@kime.org.uk&gt; wrote:<br/>&gt; ...regularly we get an error report from users that after a while using the tool, a particular file disappears from the cache and the cache has to be deleted and the binary unpacked again. I have never worked out why this is and it has been a problem for a few years, through many PP versions. You can see the general issue reported here:<br/>&gt; <br/>&gt; http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file<br/>&gt; <br/>&gt; From what I have seen, when this file is missing, all of the .pm files in inc/ are missing too although I cannot reliably reproduce this. It is a very frequent error from many users on various platforms and I&rsquo;d very much like to find out why it happens &hellip;<br/>&gt; <br/>&gt; I&#39;m fairly confident that PAR::Packer doesn&#39;t meddle with the files in the cache area of<br/>&gt; a pp-packed executable. AFAICT there&#39;s nothing in the code to delete files there (except<br/>&gt; to purge the whole cache area immediatly after running the executable).<br/>&gt; <br/>&gt; At least for *nix installations I can think of an explanation: administrative cron jobs that clean up<br/>&gt; /tmp, /var/tmp etc by purging files not modified for some time. Dunno for Windows, esp.<br/>&gt; since the &quot;temp&quot; directories there are typically specific to each user.<br/>&gt; <br/>&gt; Cheers, Roderich<br/>&gt; <br/><br/>--<br/>Dr Philip Kime<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5909.html Tue, 16 Dec 2014 10:06:32 +0000 Re: Problem with cache files being deleted by Roderich Schupp On Mon, Dec 15, 2014 at 9:15 PM, Kime Philip &lt;philkime@kime.org.uk&gt; wrote:<br/>&gt;<br/>&gt; ...regularly we get an error report from users that after a while using<br/>&gt; the tool, a particular file disappears from the cache and the cache has to<br/>&gt; be deleted and the binary unpacked again. I have never worked out why this<br/>&gt; is and it has been a problem for a few years, through many PP versions. You<br/>&gt; can see the general issue reported here:<br/>&gt;<br/>&gt;<br/>&gt; http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file<br/>&gt;<br/>&gt; From what I have seen, when this file is missing, all of the .pm files in<br/>&gt; inc/ are missing too although I cannot reliably reproduce this. It is a<br/>&gt; very frequent error from many users on various platforms and I&rsquo;d very much<br/>&gt; like to find out why it happens &hellip;<br/><br/><br/>I&#39;m fairly confident that PAR::Packer doesn&#39;t meddle with the files in the<br/>cache area of<br/>a pp-packed executable. AFAICT there&#39;s nothing in the code to delete files<br/>there (except<br/>to purge the whole cache area immediatly after running the executable).<br/><br/>At least for *nix installations I can think of an explanation:<br/>administrative cron jobs that clean up<br/>/tmp, /var/tmp etc by purging files not modified for some time. Dunno for<br/>Windows, esp.<br/>since the &quot;temp&quot; directories there are typically specific to each user.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5908.html Tue, 16 Dec 2014 10:03:03 +0000 Re: par now a virus? by Juan José 'Peco' San Martín Hi,<br/><br/>In my case depends on the usage of PC where the Antivirus and the PAR-exe<br/>files resides.<br/>If the PC is widely used to surf the web (with much javascripts, applets,<br/>etc), downloading large amount of data, then the virus becomes extremely<br/>picky so any PAR (including any .exe) is treated as a risk.<br/><br/>For me it&#39;s common that the PARexe is detected as a virus on a PC, but not<br/>in a Server, with exactly the same antivirus software.<br/><br/>Peco<br/><br/>2014-12-15 3:06 GMT+01:00 Jeremy A &lt;jeremygwa@hotmail.com&gt;:<br/>&gt;<br/>&gt; All,<br/>&gt;<br/>&gt;<br/>&gt; My Avast Anti-virus which I always keep up to date, always blocks exe from<br/>&gt; being compiled using pp,<br/>&gt; and deletes previously built executables on invoke, say it is a virus of<br/>&gt; some sort.<br/>&gt;<br/>&gt; Has anybody experienced this. is this something I should be concerned<br/>&gt; about?<br/>&gt;<br/>&gt; Thanks in advance for your attention.<br/>&gt;<br/>&gt; Jeremy,<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5907.html Tue, 16 Dec 2014 09:46:59 +0000 Re: From ActiveState to Strawberry Perl by Juan José 'Peco' San Martín I write just to say thank you to Roderich for the time, effort and patience<br/>in supporting PAR.<br/><br/>Clap-clap<br/><br/>Peco<br/><br/>2014-12-16 8:55 GMT+01:00 Roderich Schupp &lt;roderich.schupp@googlemail.com&gt;:<br/>&gt;<br/>&gt;<br/>&gt; On Mon, Dec 15, 2014 at 6:15 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>&gt; jsanmartin@gmail.com&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt; I found that INET6 seems to be broken in some way.<br/>&gt;&gt; See this: https://rt.cpan.org/Ticket/Display.html?id=83967<br/>&gt;&gt;<br/>&gt;<br/>&gt; Unfortunately it seems this ticket didn&#39;t result in a ticket for<br/>&gt; IO::Socket::INET6 to fix this strange behaviour :(<br/>&gt;<br/>&gt;<br/>&gt;&gt; If I rename INET6 to whatever, and PAR it, then it seems to work (I&#39;m<br/>&gt;&gt; checking).<br/>&gt;&gt; What I do not understand is why it works executing .pl and not the<br/>&gt;&gt; PAR-exe...<br/>&gt;&gt;<br/>&gt;<br/>&gt; Me neither, but I&#39;ll leave that to another day.<br/>&gt;<br/>&gt; Cheers, Roderich<br/>&gt;<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5906.html Tue, 16 Dec 2014 09:39:08 +0000 Re: From ActiveState to Strawberry Perl by Roderich Schupp On Mon, Dec 15, 2014 at 6:15 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>jsanmartin@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; I found that INET6 seems to be broken in some way.<br/>&gt; See this: https://rt.cpan.org/Ticket/Display.html?id=83967<br/>&gt;<br/><br/>Unfortunately it seems this ticket didn&#39;t result in a ticket for<br/>IO::Socket::INET6 to fix this strange behaviour :(<br/><br/><br/>&gt; If I rename INET6 to whatever, and PAR it, then it seems to work (I&#39;m<br/>&gt; checking).<br/>&gt; What I do not understand is why it works executing .pl and not the<br/>&gt; PAR-exe...<br/>&gt;<br/><br/>Me neither, but I&#39;ll leave that to another day.<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5905.html Tue, 16 Dec 2014 07:55:35 +0000 Problem with cache files being deleted by Kime Philip I am the maintainer of biber, a backend for the latex biblatex system which is distributed using PAR::Packer. This works fine but regularly we get an error report from users that after a while using the tool, a particular file disappears from the cache and the cache has to be deleted and the binary unpacked again. I have never worked out why this is and it has been a problem for a few years, through many PP versions. You can see the general issue reported here:<br/><br/>http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file<br/><br/>From what I have seen, when this file is missing, all of the .pm files in inc/ are missing too although I cannot reliably reproduce this. It is a very frequent error from many users on various platforms and I&rsquo;d very much like to find out why it happens &hellip;<br/><br/><br/>PK<br/>--<br/>Dr Philip Kime<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5904.html Mon, 15 Dec 2014 20:15:22 +0000 Re: From ActiveState to Strawberry Perl by Juan José 'Peco' San Martín Hello.<br/><br/>I found that INET6 seems to be broken in some way.<br/>See this: https://rt.cpan.org/Ticket/Display.html?id=83967<br/><br/>If I rename INET6 to whatever, and PAR it, then it seems to work (I&#39;m<br/>checking).<br/>What I do not understand is why it works executing .pl and not the<br/>PAR-exe...<br/><br/>Thanks<br/>Peco<br/><br/><br/>2014-12-15 17:40 GMT+01:00 Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;jsanmartin@gmail.com<br/>&gt;:<br/>&gt;<br/>&gt; Hi,<br/>&gt;<br/>&gt; $status_line is: 500 write failes: Bad file descriptor<br/>&gt;<br/>&gt; $@ is write failed: Bad file descriptor at LWP/Protocolo/http.pm line 291<br/>&gt;<br/>&gt; Thanks!<br/>&gt; Peco<br/>&gt;<br/>&gt; 2014-12-15 16:52 GMT+01:00 Roderich Schupp &lt;roderich.schupp@googlemail.com<br/>&gt; &gt;:<br/>&gt;&gt;<br/>&gt;&gt; On Sun, Dec 14, 2014 at 6:30 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>&gt;&gt; jsanmartin@gmail.com&gt; wrote:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; Simple script to do wget:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; *use strict;use warnings;*<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; *use LWP::UserAgent;*<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; *my $browser = LWP::UserAgent-&gt;new();*<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; *my $echo=$browser-&gt;get(&#39;http://google.com &lt;http://google.com&gt;&#39;);*<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; *if (not $echo-&gt;is_success) { print &quot;no connection\n&quot;;}*<br/>&gt;&gt;&gt; *else { print &quot;connected\&quot;;}*<br/>&gt;&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; What is the actual error message when it fails, e.g. try<br/>&gt;&gt;<br/>&gt;&gt; *if (not $echo-&gt;is_success) { print &quot;no connection: &quot;,<br/>&gt;&gt; $echo-&gt;status_line, &quot;\n&quot;;}*<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; Cheers, Roderich<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5903.html Mon, 15 Dec 2014 17:16:01 +0000 Re: From ActiveState to Strawberry Perl by Juan José 'Peco' San Martín Hi,<br/><br/>$status_line is: 500 write failes: Bad file descriptor<br/><br/>$@ is write failed: Bad file descriptor at LWP/Protocolo/http.pm line 291<br/><br/>Thanks!<br/>Peco<br/><br/>2014-12-15 16:52 GMT+01:00 Roderich Schupp &lt;roderich.schupp@googlemail.com&gt;:<br/>&gt;<br/>&gt; On Sun, Dec 14, 2014 at 6:30 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>&gt; jsanmartin@gmail.com&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt; Simple script to do wget:<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; *use strict;use warnings;*<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; *use LWP::UserAgent;*<br/>&gt;&gt;<br/>&gt;&gt; *my $browser = LWP::UserAgent-&gt;new();*<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; *my $echo=$browser-&gt;get(&#39;http://google.com &lt;http://google.com&gt;&#39;);*<br/>&gt;&gt;<br/>&gt;&gt; *if (not $echo-&gt;is_success) { print &quot;no connection\n&quot;;}*<br/>&gt;&gt; *else { print &quot;connected\&quot;;}*<br/>&gt;&gt;<br/>&gt;<br/>&gt; What is the actual error message when it fails, e.g. try<br/>&gt;<br/>&gt; *if (not $echo-&gt;is_success) { print &quot;no connection: &quot;, $echo-&gt;status_line,<br/>&gt; &quot;\n&quot;;}*<br/>&gt;<br/>&gt;<br/>&gt; Cheers, Roderich<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5902.html Mon, 15 Dec 2014 16:40:17 +0000 Re: From ActiveState to Strawberry Perl by Roderich Schupp On Sun, Dec 14, 2014 at 6:30 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>jsanmartin@gmail.com&gt; wrote:<br/>&gt;<br/>&gt; Simple script to do wget:<br/>&gt;<br/>&gt;<br/>&gt; *use strict;use warnings;*<br/>&gt;<br/>&gt;<br/>&gt; *use LWP::UserAgent;*<br/>&gt;<br/>&gt; *my $browser = LWP::UserAgent-&gt;new();*<br/>&gt;<br/>&gt;<br/>&gt; *my $echo=$browser-&gt;get(&#39;http://google.com &lt;http://google.com&gt;&#39;);*<br/>&gt;<br/>&gt; *if (not $echo-&gt;is_success) { print &quot;no connection\n&quot;;}*<br/>&gt; *else { print &quot;connected\&quot;;}*<br/>&gt;<br/><br/>What is the actual error message when it fails, e.g. try<br/><br/>*if (not $echo-&gt;is_success) { print &quot;no connection: &quot;, $echo-&gt;status_line,<br/>&quot;\n&quot;;}*<br/><br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5901.html Mon, 15 Dec 2014 15:52:29 +0000 Re: From ActiveState to Strawberry Perl by Roderich Schupp On Sun, Dec 14, 2014 at 7:49 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>jsanmartin@gmail.com&gt; wrote:<br/>&gt;<br/>&gt;<br/>&gt; The one that fails, it&#39;s little bit bigger (as expected) and includes<br/>&gt; these extra files that make the exe doesn&#39;t work<br/>&gt; /lib/auto/Digest:SHA<br/>&gt; /lib/auto/Net:DNS<br/>&gt; /lib/Digest:SHA.pm<br/>&gt; /lib/IO/Socket:INET6.pm<br/>&gt; /lib/Net:Bonjour<br/>&gt; /lib/Net:Bonjour.pm<br/>&gt; /lib/Net:DNS<br/>&gt; /lib/Net:DNS.pm<br/>&gt;<br/><br/>No suprise here: Net::Bonjour depends on Net::DNS which in turn depends on<br/>Digest::SHA and IO::Socket...<br/><br/>Cheers, Roderich<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5900.html Mon, 15 Dec 2014 14:14:41 +0000 par now a virus? by Jeremy A All,<br/><br/>My Avast Anti-virus which I always keep up to date, always blocks exe from being compiled using pp,and deletes previously built executables on invoke, say it is a virus of some sort.<br/>Has anybody experienced this. is this something I should be concerned about?<br/>Thanks in advance for your attention.<br/>Jeremy, <br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5899.html Mon, 15 Dec 2014 02:06:10 +0000 Re: From ActiveState to Strawberry Perl by Juan José 'Peco' San Martín Hi,<br/><br/>Good point, but unfortunately it has not worked.<br/>I disabled the Windows Firewall (to avoid errors) and the behaviour is the<br/>same.<br/><br/>Thank you<br/>Peco<br/><br/>2014-12-14 19:11 GMT+01:00 Pascal Fleer &lt;pascal.fleer@gmail.com&gt;:<br/>&gt;<br/>&gt;<br/>&gt; Hi,<br/>&gt;<br/>&gt; with tools like sysinternals process explorer or process monitor check if<br/>&gt; your application does open a socket - you should see something like<br/>&gt; &quot;SYN_SENT&quot;.<br/>&gt;<br/>&gt; If this is the case check your local firewall settings if your executable<br/>&gt; is blocked. Add an exception for your executable.<br/>&gt;<br/>&gt; This is very common with Windows 7.<br/>&gt;<br/>&gt; Pascal<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; On 14.12.2014 18:30, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n wrote:<br/>&gt;<br/>&gt; Thank you Roderich. Really appreciate your guide.<br/>&gt;<br/>&gt; I&#39;m on this during the last xxx hours and now I think I&#39;m in front of a<br/>&gt; new issue or completely lost.<br/>&gt;<br/>&gt; Let me try to summarize:<br/>&gt;<br/>&gt; Virtual machine with Windows 7 + Strawberry Perl 5.20 with the latest PAR.<br/>&gt;<br/>&gt; Simple script to do wget:<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; *use strict; use warnings; *<br/>&gt;<br/>&gt;<br/>&gt; *use LWP::UserAgent; *<br/>&gt;<br/>&gt; *my $browser = LWP::UserAgent-&gt;new(); *<br/>&gt;<br/>&gt;<br/>&gt; *my $echo=$browser-&gt;get(&#39;http://google.com &lt;http://google.com&gt;&#39;); *<br/>&gt;<br/>&gt; *if (not $echo-&gt;is_success) { print &quot;no connection\n&quot;;} *<br/>&gt; *else { print &quot;connected\&quot;;}*<br/>&gt;<br/>&gt; It works as .pl, it works as .exe with PAR<br/>&gt; Both executions return &quot;connected&quot;<br/>&gt;<br/>&gt; To this simple script, I add &quot;use XX&quot; (where XX is the main module of my<br/>&gt; real application)<br/>&gt; Please, note that I&#39;m only doing &quot;use&quot; but I&#39;m not explicitly calling any<br/>&gt; subroutine (the module ends with 1;)<br/>&gt;<br/>&gt;<br/>&gt; *use strict; *<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; *use warnings; use XX; use LWP::UserAgent; *<br/>&gt;<br/>&gt; *my $browser.... *<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; * It works as .pl, it works as .exe with PAR BUT each execution returns<br/>&gt; different result - .pl =&gt; connected - .exe =&gt; not connected *<br/>&gt; :-??<br/>&gt;<br/>&gt; I think PAR (Module-ScanDeps) detects &quot;use XX&quot; pushing the needed<br/>&gt; modules into the EXE, but why this change the behaviour of the script?<br/>&gt;<br/>&gt; It&#39;s not sane, but at this point my pp line includes all the DLLs/.a<br/>&gt; libraries that exist (double checked with the list of Roderich). The exe is<br/>&gt; well created, but with the same results<br/>&gt;<br/>&gt; Thanks for reading this far :-)<br/>&gt; Peco<br/>&gt;<br/>&gt; 2014-12-14 17:45 GMT+01:00 Roderich Schupp &lt;roderich.schupp@googlemail.com<br/>&gt; &gt;:<br/>&gt;&gt;<br/>&gt;&gt; On Fri, Dec 12, 2014 at 11:18 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>&gt;&gt; jsanmartin@gmail.com&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt;&gt; I&#39;m looping on the points 1 to 4 without luck, yet. All the DLL of the<br/>&gt;&gt;&gt; world appear to be linked :-P<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; Don&#39;t dispair, FYI here&#39;s a list of Perl modules with &quot;glue&quot; DLLs that<br/>&gt;&gt; are linked against external DLLs.<br/>&gt;&gt; This was culled from Strawberry 5.20, In addition, modules Tk,<br/>&gt;&gt; Alien::wxWidgets and Wx were installed.<br/>&gt;&gt; Note that I suppressed<br/>&gt;&gt;<br/>&gt;&gt; - Windows system DLLs, e.g. KERNEL32.dll, because you obviously don&#39;t<br/>&gt;&gt; need to pack them<br/>&gt;&gt; - DLLs that perl.exe itself recursively depends on, e.g libgcc*.dll<br/>&gt;&gt; and libstdc++*.dll, which PAR::Packer takes care of automatically<br/>&gt;&gt;<br/>&gt;&gt; How to read this list: if your script uses XML::LibXML, find the<br/>&gt;&gt; corresponding entry:<br/>&gt;&gt;<br/>&gt;&gt; XML::LibXML (E:/Strawberry/perl/vendor/lib/auto/XML/LibXML/LibXML.xs.dll)<br/>&gt;&gt; libxml2-2_.dll<br/>&gt;&gt; libiconv-2_.dll<br/>&gt;&gt; liblzma-5_.dll<br/>&gt;&gt; zlib1_.dll<br/>&gt;&gt;<br/>&gt;&gt; This tells you that you need to add<br/>&gt;&gt;<br/>&gt;&gt; -l libxml2-2_.dll -l libiconv-2_.dll -l liblzma-5_.dll -l zlib1_.dll<br/>&gt;&gt;<br/>&gt;&gt; to the pp command line.<br/>&gt;&gt;<br/>&gt;&gt; Cheers, Roderich<br/>&gt;&gt;<br/>&gt;<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5898.html Sun, 14 Dec 2014 18:51:48 +0000 Re: From ActiveState to Strawberry Perl by Juan José 'Peco' San Martín Thank you Roderich.<br/><br/>Interesting!<br/><br/>a) Instead of *use XX,* I looked the dependencies (the &quot;use YYY&quot; inside the<br/>XX module) to find the origin.<br/>Catched: *Net::Bonjour*<br/><br/>b) I have a simple script that works (without *use Net::Bonjour*) and fails<br/>(with *use Net::Bonjour*)<br/>Then I did what you said, Par-exe both and compare.<br/><br/>The one that fails, it&#39;s little bit bigger (as expected) and includes these<br/>extra files that make the exe doesn&#39;t work<br/><br/>/lib/auto/Digest:SHA<br/>/lib/auto/Net:DNS<br/>/lib/Digest:SHA.pm<br/>/lib/IO/Socket:INET6.pm<br/>/lib/Net:Bonjour<br/>/lib/Net:Bonjour.pm<br/>/lib/Net:DNS<br/>/lib/Net:DNS.pm<br/><br/>My current pp line is<br/><br/>pp -I lib -l libxml2-2_.dll -l ssleay32_.dll -l zlib1_.dll -M<br/>XML::SAX::PurePerl -M XML::LibXML::SAX -M Net::SSL -M Crypt::Blowfish -0<br/>test.exe test.pl<br/><br/>Although we can reproduce the issue with pp -o sample.exe sample.pl<br/><br/>Thanks<br/><br/>Peco<br/><br/><br/>2014-12-14 19:04 GMT+01:00 Roderich Schupp &lt;roderich.schupp@googlemail.com&gt;:<br/>&gt;<br/>&gt; On Sun, Dec 14, 2014 at 6:30 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n &lt;<br/>&gt; jsanmartin@gmail.com&gt; wrote:<br/>&gt;<br/>&gt;&gt; I think PAR (Module-ScanDeps) detects &quot;use XX&quot; pushing the needed modules<br/>&gt;&gt; into the EXE, but why this change the behaviour of the script?<br/>&gt;&gt;<br/>&gt;<br/>&gt; Correct, so the executable should just contain some more modules which<br/>&gt; can&#39;t hurt, right?<br/>&gt; But stranger things have happened...<br/>&gt;<br/>&gt; Try to figure out the difference: create your excutable both with and<br/>&gt; without &quot;use XX&quot;,<br/>&gt; run &quot;unzip -l your.exe&quot; on them (a pp&#39;ed executable is also a zip file),<br/>&gt; sort the outputs and run diff on them.<br/>&gt;<br/>&gt;<br/>&gt;&gt; It&#39;s not sane, but at this point my pp line includes all the DLLs/.a<br/>&gt;&gt; libraries that exist (double checked with the list of Roderich).<br/>&gt;&gt;<br/>&gt;<br/>&gt; Note that adding *.a libraries is useless in this context. And do NOT<br/>&gt; simply add &quot;all DLLs that exist&quot;, esp. do NOT add perl520.dll, libgcc*.dll,<br/>&gt; libstdc++*.dll, libwinpthread*.dll.<br/>&gt;<br/>&gt; Cheers, Roderich<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5897.html Sun, 14 Dec 2014 18:49:46 +0000 Re: From ActiveState to Strawberry Perl by Pascal Fleer <br/>Hi,<br/><br/>with tools like sysinternals process explorer or process monitor check <br/>if your application does open a socket - you should see something like <br/>&quot;SYN_SENT&quot;.<br/><br/>If this is the case check your local firewall settings if your <br/>executable is blocked. Add an exception for your executable.<br/><br/>This is very common with Windows 7.<br/><br/>Pascal<br/><br/><br/>On 14.12.2014 18:30, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n wrote:<br/>&gt; Thank you Roderich. Really appreciate your guide.<br/>&gt;<br/>&gt; I&#39;m on this during the last xxx hours and now I think I&#39;m in front of <br/>&gt; a new issue or completely lost.<br/>&gt;<br/>&gt; Let me try to summarize:<br/>&gt;<br/>&gt; Virtual machine with Windows 7 + Strawberry Perl 5.20 with the latest <br/>&gt; PAR.<br/>&gt;<br/>&gt; Simple script to do wget:<br/>&gt;<br/>&gt; /use strict;<br/>&gt; use warnings;<br/>&gt; /<br/>&gt; /use LWP::UserAgent;<br/>&gt;<br/>&gt; /<br/>&gt; /my $browser = LWP::UserAgent-&gt;new();<br/>&gt; /<br/>&gt; /my $echo=$browser-&gt;get(&#39;http://google.com&#39;);<br/>&gt;<br/>&gt; /<br/>&gt; /if (not $echo-&gt;is_success) { print &quot;no connection\n&quot;;}<br/>&gt; /<br/>&gt; /else { print &quot;connected\&quot;;}/<br/>&gt;<br/>&gt; It works as .pl, it works as .exe with PAR<br/>&gt; Both executions return &quot;connected&quot;<br/>&gt;<br/>&gt; To this simple script, I add &quot;use XX&quot; (where XX is the main module of <br/>&gt; my real application)<br/>&gt; Please, note that I&#39;m only doing &quot;use&quot; but I&#39;m not explicitly calling <br/>&gt; any subroutine (the module ends with 1;)<br/>&gt;<br/>&gt; /use strict;<br/>&gt; /<br/>&gt; /use warnings;<br/>&gt; *use XX;*<br/>&gt; use LWP::UserAgent;<br/>&gt;<br/>&gt; /<br/>&gt; /my $browser....<br/>&gt; /<br/>&gt; /<br/>&gt; It works as .pl, it works as .exe with PAR BUT<br/>&gt; each execution returns different result<br/>&gt; - .pl =&gt; connected<br/>&gt; - .exe =&gt; not connected<br/>&gt; /<br/>&gt; :-??<br/>&gt;<br/>&gt; I think PAR (Module-ScanDeps) detects &quot;use XX&quot; pushing the needed <br/>&gt; modules into the EXE, but why this change the behaviour of the script?<br/>&gt;<br/>&gt; It&#39;s not sane, but at this point my pp line includes all the DLLs/.a <br/>&gt; libraries that exist (double checked with the list of Roderich). The <br/>&gt; exe is well created, but with the same results<br/>&gt;<br/>&gt; Thanks for reading this far :-)<br/>&gt; Peco<br/>&gt;<br/>&gt; 2014-12-14 17:45 GMT+01:00 Roderich Schupp <br/>&gt; &lt;roderich.schupp@googlemail.com &lt;mailto:roderich.schupp@googlemail.com&gt;&gt;:<br/>&gt;<br/>&gt; On Fri, Dec 12, 2014 at 11:18 PM, Juan Jos&eacute; &#39;Peco&#39; San Mart&iacute;n<br/>&gt; &lt;jsanmartin@gmail.com &lt;mailto:jsanmartin@gmail.com&gt;&gt; wrote:<br/>&gt;<br/>&gt; I&#39;m looping on the points 1 to 4 without luck, yet. All the<br/>&gt; DLL of the world appear to be linked :-P<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; Don&#39;t dispair, FYI here&#39;s a list of Perl modules with &quot;glue&quot; DLLs<br/>&gt; that are linked against external DLLs.<br/>&gt; This was culled from Strawberry 5.20, In addition, modules Tk,<br/>&gt; Alien::wxWidgets and Wx were installed.<br/>&gt; Note that I suppressed<br/>&gt;<br/>&gt; * Windows system DLLs, e.g. KERNEL32.dll, because you obviously<br/>&gt; don&#39;t need to pack them<br/>&gt; * DLLs that perl.exe itself recursively depends on, e.g<br/>&gt; libgcc*.dll and libstdc++*.dll, which PAR::Packer takes care<br/>&gt; of automatically<br/>&gt;<br/>&gt; How to read this list: if your script uses XML::LibXML, find the<br/>&gt; corresponding entry:<br/>&gt;<br/>&gt; XML::LibXML<br/>&gt; (E:/Strawberry/perl/vendor/lib/auto/XML/LibXML/LibXML.xs.dll)<br/>&gt; libxml2-2_.dll<br/>&gt; libiconv-2_.dll<br/>&gt; liblzma-5_.dll<br/>&gt; zlib1_.dll<br/>&gt;<br/>&gt; This tells you that you need to add<br/>&gt;<br/>&gt; -l libxml2-2_.dll -l libiconv-2_.dll -l liblzma-5_.dll -l zlib1_.dll<br/>&gt;<br/>&gt; to the pp command line.<br/>&gt;<br/>&gt; Cheers, Roderich<br/>&gt;<br/><br/><br/> http://www.nntp.perl.org/group/perl.par/2014/12/msg5896.html Sun, 14 Dec 2014 18:11:59 +0000