Lightning flashed, thunder crashed and "Branden" [EMAIL PROTECTED] whisp
ered:
| For the list managers: Could we have a list apart from -language, so that we
| don't bother all with this `par'-issue ??? Please? Perhaps a list that
| includes the issue on directory structure, and other issues
On Fri, 16 Feb 2001, Stephen P. Potter wrote:
How about a perl6-install list? This discussion really doesn't fit into
any of the current top level lists, so we can make a new top level and
cover other installation issues as well. Ask, can you make this, if the
name is agreeable.
There
On Fri, 16 Feb 2001, Stephen P. Potter wrote:
Lightning flashed, thunder crashed and "Branden" [EMAIL PROTECTED] whisp
ered:
| For the list managers: Could we have a list apart from -language, so that we
| don't bother all with this `par'-issue ??? Please? Perhaps a list that
| includes
Hello.
I'm working on the PDD for par. I would like to propose a standard directory
structure for the files inside the archive, but I realise this depends
greatly upon the directory structure of Perl itself.
How does Perl 5 manage its directory structure?
Suppose $PERL is the base directory
John Porter wrote:
Branden wrote:
For example, with tgz it would be complex to deal
with running without extracting,
What? tar -z not good enough for you?
The problem is that we cannot access individual files inside the archive
without decompressing the whole archive, what is
On Mon, Feb 12, 2001 at 12:36:53PM -0300, Branden wrote:
John Porter wrote:
Branden wrote:
For example, with tgz it would be complex to deal
with running without extracting,
What? tar -z not good enough for you?
The problem is that we cannot access individual files inside
On Monday 12 February 2001 10:36, Branden wrote:
The problem is that we cannot access individual files inside the archive
without decompressing the whole archive, what is possible with .tar (not
..gz) and .zip. Then we can assign a perl filehandle to access a file from
inside the archive and
Bart Lateur wrote:
On Fri, 9 Feb 2001 21:18:55 +, Nicholas Clark wrote:
* Archive::Tar is part of the Perl 5.6.0 distributions for Win32
(Activestate and IndigoPerl)
* And I'd like the normal module distributions on CPAN to still work.
Those are all .tar.gz.
I actually don't
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
In http://www.w3.org/TR/NOTE-OSD.html#B they describe platform/cpu standard
names, and we'll definetly need those for checking target architecture. Can
we standardize upon those, or there's something missing? There's an issue
The
Bryan C. Warnock wrote:
Is that '.tar and .zip' as in '.tar and .zip' or '.tar or .zip'?
.tar or .zip
Aren't most tars still unindexed, requiring a full file scan anyway?
That was one I was not aware of... One more reason to use .zip!
Hey, .tgz people... Java's jar has used .zip as its
Jarkko Hietaniemi wrote:
On Mon, Feb 12, 2001 at 12:36:53PM -0300, Branden wrote:
The problem is that we cannot access individual files inside the archive
without decompressing the whole archive, what is possible with .tar (not
I do not see a huge problem in decompressing the whole archive
On Mon, Feb 12, 2001 at 05:45:17PM +, 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
[EMAIL PROTECTED] wrote:
I'm not planning on waiting for Perl 6 to start work on par, so Moore
isn't with us.
Agreed, with the condition that we all make the specification for it
together, and it remains compatible with `par' that will be shipped with
Perl 6.
And I'll probably ask you to
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
I put together a comparison table between par and rpm/jar.
You forgot deb, which I'd *much* rather deal with than rpm (if only
because I can point apt and dselect at CPAN). You also forgot the "Is
Vaporware?" category. ;)
| Available
On Sat, Feb 10, 2001 at 12:58:34AM +0100, Bart Lateur wrote:
* On a currently normal Pentium of 500MHz, 64Mb, ungzipping and
untarring a .tgz archive of 250k (the ungzipped file itself is roughly
1.5Mb) takes roughly 1 second. (ONE second!)
One second is too slow (for a Unix user it is,
On Mon, Feb 12, 2001 at 12:08:12PM -0500, [EMAIL PROTECTED] wrote:
On Sat, Feb 10, 2001 at 12:58:34AM +0100, Bart Lateur wrote:
* On a currently normal Pentium of 500MHz, 64Mb, ungzipping and
untarring a .tgz archive of 250k (the ungzipped file itself is roughly
1.5Mb) takes roughly 1
[EMAIL PROTECTED] wrote:
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
I put together a comparison table between par and rpm/jar.
You forgot deb, which I'd *much* rather deal with than rpm (if only
because I can point apt and dselect at CPAN). You also forgot the "Is
[EMAIL PROTECTED] wrote:
What are we doing with it? We are killing perl2exe.
Not exactly.
The niches of:
1. "I don't want to use modules because the end-user might not have
them installed"
Yes.
2. "My end-users might not have Perl installed" Bundling a Perl
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
I don't really see much _conceptual_ difference between rpm, deb, and the
other package formats used by Linux.
debs store alot of information that rpm doesn't, and it would be good
to look at to steal good ideas. Also, and most
On Mon, Feb 12, 2001 at 01:50:39PM -0500, [EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
Loading a Perl module from a filehandle might
screw with DATA.
As resource files can be attached to the archive, I think not allowing
__DATA__ wouldn't be
On Mon, Feb 12, 2001 at 06:35:17PM +, Nicholas Clark wrote:
"par" stood for what?
Perl ARchive, just like jar (Java ARchive). "par" will be the utility
to create pars. To run a par, you'd use a seperate utility (so an
end-user doesn't have to carry around all the extra junk associated
par can do something similar. It can slap a copy of pun (and thus
perl) onto the archive. Its not simple, and its platform dependent,
but its useful. I'm more and more seeing par as a way of
embrace/extend/destroying perl2exe.
And I think we could squeeze something into 5.8.
Careful
On Mon, Feb 12, 2001 at 04:50:53PM -0300, Branden wrote:
2. "My end-users might not have Perl installed" Bundling a Perl
interpretor with your program (until perlcc is viable)
No. I don't expect Perl installation or any other otherwise executable or
installation program to
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
We'll just have to use something other than RSA most likely.
Why? Problems with exporting cryptosystems? If that's it, how does
Java/Netscape do it?
Nah, it's a pattent issue. Netscape (and other .jar consumers, assumedly)
licenced
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries *and* shared libraries. In theory this is easy:
the portable (and
[EMAIL PROTECTED] wrote:
debs store alot of information that rpm doesn't, and it would be good
to look at to steal good ideas. Also, and most importantly, they have
dselect, which is similar, but much more powerful, than CPAN and the
CPAN shell. That's something to look at.
Could you
On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries
At 01:28 PM 2/12/2001 -0600, Jarkko Hietaniemi wrote:
On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote:
Perl binary with a built-in @INC prefix something like
"/tmp/XpErLXX" and then do some s/// madness over the
binary.
Anyhow, this is easily solved by
Oh, I fully realize that *none* of this "self-extracting" nonsense is
going to be cross-platform by any means. For each variation of Unix
you'll need a seperate par binary, but its no worse than C. But Unix
really isn't a problem. Any Unix dist worth its weight in snot comes
with Perl.
The
On Mon, Feb 12, 2001 at 02:41:01PM -0500, [EMAIL PROTECTED] wrote:
Oh, I fully realize that *none* of this "self-extracting" nonsense is
going to be cross-platform by any means. For each variation of Unix
Whew! I was starting to think I'm surrounded by tunnel visioned penguins.
you'll need
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries *and* shared libraries.
True enough. The way Linux package managers
James Mastros wrote:
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries *and* shared libraries.
True enough. The
On Mon, Feb 12, 2001 at 01:28:56PM -0600, Jarkko Hietaniemi wrote:
On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote:
You have to do that anyway to solve the "what version of glibc are you
using" problem (and others).
*minirant*
The world is not not glibc. The world is
On Mon, Feb 12, 2001 at 05:28:04PM -0300, Branden wrote:
Could you point me to some URLs? Like .deb file format? What's the good info
the have? What's dselect? How it works?
Start from sections 6, 7 and 8 of the Debian FAQ
http://www.debian.org/doc/FAQ/
dselect, aptitude and several other
You should probably also take a look a Debian's packaging, the .deb.
It consists of an ar archive containing three files: one for the magic
(named debian-binary, containing "2.0"), one for the filesystem image
(filesystem.tar.gz)
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
|
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
In http://www.w3.org/TR/NOTE-OSD.html#B they describe platform/cpu standard
names, and we'll definetly need those for checking target architecture. Can
we standardize upon those, or there's something missing? There's an issue
I take it
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.
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
Other important issue I don't know yet: Is there an Archive::Zip module for
Perl? How cross-platform is it? Can we bundle it with Perl (licensing
issues)? Is it stable? Will it give us the support we need (access to
individual files in
This is the alpha version of the PDD about archives. I actually didn't have
the time to format it as a POD, and probably won't have the time to do it
until Monday, I don't even think I'll have time to check the lists on the
weekend. Nevertheless, I'm sending it on mail-message format for your
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
Jarkko Hietaniemi wrote:
Whatever we do I would much prefer being package format agnostic
instead of tying ourselves too tightly with some single format.
Any ideas on how to do that? Without breaking requirements?
There isn't a
I had the time to do a research in Internet about rpm/jar. The correct URLs
are:
* http://www.rpm.org
* http://java.sun.com/products/jdk/1.1/docs/guide/jar/
I found great utilitaries in http://www.rpm.org/software.html, we could
probably steal some of them for `par'. I found out that most of
Jarkko Hietaniemi wrote:
(for those of you who didn't get the reference)
Well, I certainly heard the reference before even hearing of Perl or Tom...
I only ever saw it with his name on it.
So if he didn't coin it, then I think he "appropriated" it...
--
John Porter
Jarkko Hietaniemi wrote:
There isn't a software problem another abstraction layer can't fix...
"...except the problem of too many layers of abstraction". tchrist
(for those of you who didn't get the reference)
--
John Porter
At 11:32 AM 2/9/2001 -0200, Branden wrote:
Nicholas Clark wrote:
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
At 09:42 AM 2/9/2001 +, Michael G Schwern wrote:
On Thu, Feb 08, 2001 at 01:40:52PM -0500, Dan Sugalski wrote:
Seperated documentation is no documentation.
At some point things are going to get split out, unless you wedge the docs
into the actual program itself. (You were, after all,
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 02:53:43PM -0600, Jarkko Hietaniemi wrote:
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
problems (like `oh! I don't have bzip2 and the developper only supplied a
bzip2 version of the
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote:
Code to do unzip (yes, even including the whole of zlib just like gcc,
xfree86 and several other things I can't remember offhand that irritate
me as I have libz.so) is small enough to go in the perl core if needed.
Even after
On Thu, Feb 08, 2001 at 11:21:17AM -0500, Dan Sugalski wrote:
I'm not sure this is all necessary. Wouldn't we be reasonably better off if
we instead just shipped off bytecode compiled versions of the scripts?
Sure, except...
1) You lose your readable source code (discussions of
On Thu, Feb 08, 2001 at 05:39:01PM +, Nicholas Clark wrote:
Do we really want to use tar format (over say cpio) as tar rounds files
up to 512 block boundaries, and has some arbitrary restrictions on filename
lengths in the headers?
First cut will be tar. Why? Its simple, its common, and
Peter Scott wrote:
Eh? I thought PPM was simply "perl -MCPAN -e install" for Windows users,
pointed to a set of modules which have XS content that they'd had to fiddle
with to port to Win32.
Not by far. It is a replacment for CPAN that builds and
maintains its own local database
50 matches
Mail list logo
