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
seem
> 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
generate
> > incompatible binaries? Because if this happens (and will still happen
on
> > Perl 6) the platform identification should be os/cpu/compiler. Perhaps
each
>
> 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
a
> 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
much.
- Branden
