Front page | perl.perl6.language |
Postings from February 2001
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. - BrandenThread Previous | Thread Next