Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: undump
Message-ID: <9064@jpl-devvax.JPL.NASA.GOV>
Date: 8 Aug 90 21:36:54 GMT
References: <104716@convex.convex.com>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 26

In article <104716@convex.convex.com> tchrist@convex.Com (Tom Christiansen) writes:
: I was wondering why perl's dump operator didn't just
: write out its dataspace something like the way (I imagine) 
: sendmail does to make its freeze-config file.  Let's
: say it generate something like $0.out; then on startup
: you could do 'perl -R /path/script.out' to restart.  
: I'll give 10 to 1 odds Larry's thought this out and discounted
: it, but I was wondering why.  Because it might not work on 
: all possible systems?  Wouldn't that be better than making
: people find an undump, and save disk space too?

The main problem with that approach is that all your compiled scripts
stand a good chance of busting whenever you recompile Perl.  A secondary
problem is that you still have to invoke a separate executable on the file,
though you could perform trickery with #!.

Yes it would save some disk space.  With care we could even set up a way
to make it redump automatically whenever Perl is recompiled--though the
problem of unwritable executables rears its ugly little head.  The alternative
is to keep all your old versions of Perl around.

What would be way cool is if we could find a way to compile into an
architecture independent format without much load-time penalty.  Seems
difficult, though, without extensive changes to the runtime system.

Larry