develooper Front page | perl.par | Postings from September 2008

Re: PAR and modules, accessing the lib directory

Thread Previous | Thread Next
Alvar Freude
September 1, 2008 13:47
Re: PAR and modules, accessing the lib directory
Message ID:
Hash: SHA1

Hi Steffen,

- -- Steffen Mueller <> wrote:

> I just spent my spare time budget for the day on the Storable/pp --clean
> thread, so I'll have to be very brief.

oh, it's OK and not too brief ;-)

> That depends on how you use it. If you use it with .par files, or with
> standalone exes *AND* --clean, then you're right.

in my case with .par files, yes.

> There isn't. This discussion comes up a lot. There were a couple of
> reasons for the behaviour, but nowadays, I just wish it wasn't so.


> The main problem with changing the behaviour is that nobody has the time
> to do it.

depending on how much it is, I can help. But I have no real knowledge of 
all the PAR internals!

> It potentially breaks all kinds of things, so it's not *only*
> a matter of patching the source in many places, but also a question of
> who's going to deal with the fallout.

hmmm ...

> One problem is that in those scenarios, PAR does extraction on demand
> only -- sort of like lazy evaluation. So if we change to the normal file
> naming scheme for extraction, little is gained for those modules which
> scan @INC manually, since what they're searching for might not be there
> yet (or at all).

one solution may be to have the possibility to extract some paths or 
files; e.g. PAR::extract_path("path/in/the/par-files")

> Then again, switching to burst-extracting all loaded .par files may be a
> bad idea in the advertised "use PAR '/foo/bar/*.par';" chainsaw
> approach. It implicitly assumes that opening a bunch of .par files at
> startup isn't prohibitively expensive.

yes, but it depends on the application if this is a problem. I have an 
application which spends a lot more time in other things, so if it takes 
one second more or less, it doesn't matter ;-)

> All this is conceptually fixable, I think, but it takes a lot of work
> that nobody is currently able to do.

Now I have one idea, which seems to be relatively easy:

A new PAR::ExtractAll (or something like that) module unpacks everything 
into a temp dir (File::Temp), which gets cleaned after the run, or as 
alternative into a given directory. The lib directory/directories of the 
are added to @INC and it works.

I don't know yet which probems this might bring in a real application, 
but it seems to be a short and relatively simple module, but helpful at 
least in my case. And it seems to me, that it may be less work then 
changing some modules from the colleagues ... ;-)

> Actually, now that I think about this some more: Scott Stanton put in
> some work to load Perl modules from memory instead of extracting them at
> all. This isn't in the main line but in a branch because it creates
> other problems. However, this also speeds up PAR operation in --clean
> mode a lot, but totally breaks the manual @INC scans.

I read about this, this sounds very cool. And for a lot of usages it may 
be a good choice.


- -- 
** Alvar C.H. Freude,
Version: GnuPG v1.4.9 (Darwin)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About