Well, that's definitely one solution :)
I'm not sure how well that would go when done from within a PAR
executable, since that would presumably lock its source files, and thus
the cache will not be deleted. Doing it within the executable is
simplest for the users, many of whom are unfamiliar with the temp folder
and its contents and tend to steer clear.
What I'm thinking of is some way for a PAR executable to detect if extra
files packed using -a are missing, and then unpack them. Handling of dll
and glue files can remain as-is (it seems they are re-extracted in any
case). Extra files could be explicitly checked for in the script and
then something like a PAR::reextract_extra_packed_files sub could
extract them. Possibly it could handle the existence checks as well.
Essentially it is the same approach I gave in my previous email, but
applied across all extra files.
If I get some pointers to the relevant part of the code base then I
could take a stab at it, without any promises of success of course.
Or have I misunderstood your point about open(), and that's how they are
currently extracted?
Regards,
Shawn.
On 16/12/2014 21:49, Roderich Schupp wrote:
On Tue, Dec 16, 2014 at 11:29 AM, Shawn Laffan
<[email protected] <mailto:[email protected]>> wrote:
For the more general case, is there a simple means to trigger the
re-extraction of all files packed using -a?
Simply delete the cache area :)
Sorry, for .pm and "glue" .dll files the check is automatic as PAR
intercepts module loading
and DynaLoader anyway. But all stuff packed with -a is accessed using
open() calls - I wouldn't want PAR to replace CORE::open.
Cheers, Roderich
--
Assoc Prof Shawn Laffan
School of Biological, Earth and Environmental Sciences
UNSW, Sydney 2052, Australia
Tel +61 2 9385 8093 Fax +61 2 9385 1558
http://www.bees.unsw.edu.au/staff/shawn-laffan
http://www.purl.org/biodiverse (free diversity analysis software)
http://www.tandf.co.uk/journals/ijgis
UNSW CRICOS Provider Code 00098G
