develooper Front page | perl.perl6.language | Postings from February 2001

Re: Auto-install (was autoloaded...)

Thread Previous | Thread Next
February 9, 2001 05:32
Re: Auto-install (was autoloaded...)
Message ID:
Nicholas Clark wrote:
> I take it "Lunix" is Linux.
> BSDi isn't FreeBSD, NetBSD or OpenBSD
> Nothing they list seems to be VMS
> Pace are still developing variants of Acorn's RISC OS to run set top boxes
> As I understood it there were about 39 variants of Unix ever, and they
> to have 12 listed.
> [snip]
> The ommission of pa risc makes me wonder about quality of the rest of this
> document.

Clearly an article of Microsoft...

> > that I really don't know: in the same platform, different compilers
 > > incompatible binaries? Because if this happens (and will still happen
> > Perl 6) the platform identification should be os/cpu/compiler. Perhaps
> on perl 5 different configure options generate different binaries.

Can this be standardized somehow? Perl 6 binary level compatibility, for
extensions? In a way that distributing binary modules would be at least
possible? It's already a big trouble to consider the various different
os/cpu combinations, configure options is not feasible at all! Compilers I
can take, I don't actually expect gcc/MS VC++ generating compatible dlls,
althought I think it could be possible...

> I don't know the answers to the other questions. However, I was intending
> to write a layer for perl 5.7 that can access zip entries via regular
> perl filehandles. (In theory this could let you run scripts direct out of
> zip without actually unpacking them anywhere)

This seems like an issue that will not only be used by `par', as I see it
brought up many times now and then. Probably should be encapsulated in a
generic module and be bundled in Perl 6's standard distribution.

> Layers of some form are needed in perl6 to cope with utf8 and other
> encodings, so I would expect the perl6 layer functionality can also be
> extended to zip manipulations.
> Nicholas Clark

AFAIK, Perl 6 will have a translation layer from bytes to the encoding, and
one of the encodings would be `binary', that would just pass the bytes
through. This is what should probably be used for zip. If you mean the
uncompress-on-the-fly thing I think it would be handled like source filters
are today. In Perl 5.7 you can even have a source filter that decompresses a
.gzipped script and runs it, by using a source filter. I believe zip could
be handled by this also in 5.7. Perl 6 will certainly improve this area very

- Branden

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