On Mon, Feb 12, 2001 at 01:14:58PM -0500, [EMAIL PROTECTED] wrote:
> On Mon, Feb 12, 2001 at 05:45:17PM +0000, Nicholas Clark wrote:
> > When I last tried it (over a year ago) running the 5.005 regression tests
> > with the standard libraries coming out of a zip file took about the same
> > time as running the regression tests with the standard libraries on disk.
> >
> > [x86 BSD unix, fairly big machine, SCSI disks - something I'd expect to
> > be good at IO]
>
> Alot of spare memory? I'd suspect it probably just tossed everything
> into the cache. Windows is fairly awful at doing that sort of thing.
> Also, did you decompress the libraries once at the start of the test
> and then throw them on disk? Or did you decompress for each and every
> test script?
See
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-02/msg01379.html
for go three
In answers to questions
1: I can remember when plum.flirble.org had 196Mb, and when it got upgraded
to 640Mb. Either way, I think that counts as "a lot of spare memory"
2: No, libraries didn't get thrown out to disk. No temporary files or child
processes of any sort were used [no camels were harmed in the making of...]
Include files got decompressed as needed. There was a single linear
pass of the zip central directory, which was used to build a hash of
files in that zip (which lasted for the duration of that perl
interpreter). You look in the hash - if you find that file there, great
[seek direct to correct point in zip file, validate local header, start
decompressing]. Else resume linear search of the central directory where
you left off before, until you find the file you are interested in.
If you hit the end of the central directory, mark the hash as complete
[so as not to bother with any more scanning] and return not found
The only things that I know I should change are
a: It's not thread safe
b: It didn't store the last modified time of the zip, and chuck the cashed
central directory and restart from the beginning if someone modified the
zip file underneath it
> 1. "I don't want to use modules because the end-user might not have
> them installed"
yes, you can stick a zip file on the end of your perl script.
> 2. "My end-users might not have Perl installed" Bundling a Perl
> interpretor with your program (until perlcc is viable)
yes, you can stick a zip file on the end of your perl interpreter.
Not sure if you get needless waste of memory like this
[I believe on Unix the pages of the file that aren't really the executable
don't ever come in from disk, so there's no waste of effort when you open
the file a second time to read it as a zip. If there is, cunning tricks
with symbol tables to treat the zip "file" as a big void* blob in the
executable would be needed. This also is potentially something commercial]
> 3. "I want to hide my source code from Evil Vicious Users!" A
> consequence of #2, however we can make the "hiding" very, very
> cheesy and pun can "decompile". But that's good enough for most.
can't do this
> Unfortunately, this might hurt IndigoSTAR (makers of perl2exe) and the
> last thing I want to do with par is damage a Perl-friendly business.
> I'm not entirely sure how to approach them on this.
they still have a selling point on number 3. And for practical purposes
they aren't vapourware. [IIRC the URL I quoted needed a perl built with
sfio. As I understand it, fine for MacPerl, which already defaults to sfio.
Not the default anywhere else. PerlIO in perl 5.7 will probably be the
default in perl 5.8, and I'm currently playing with that]
> > 2: Is this really still language? If not, where should we be discussing it?
>
> [EMAIL PROTECTED] anyone?
"par" stood for what?
I'm assuming it's seen as a general (not just perl6) thing?
Nicholas Clark
