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
Branden wrote:
And I'll probably ask you to use another naming/extension, like pp5 (par for
perl 5), so that modules for both versions don't get mixed up (since they'll
be incompatible).
That doesn't make sense. Either your script or your archive
tool (par, pun, or CPAN or whatever)
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 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
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
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
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 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
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 Mon, Feb 12, 2001 at 01:14:58PM -0500, [EMAIL PROTECTED] wrote:
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
[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
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
[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
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
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 06:56:47PM -0300, Branden wrote:
James Mastros wrote:
magical "install" script in them that knows how to do special things with
files in that directory (like set up symlinks from the normal man dirs).
That probably should be in Perl's Config.pm, since Perl itself
On Mon, Feb 12, 2001 at 06:56:47PM -0300, Branden wrote:
I'd rather not have any kind of `script' that would be run on an
installation, to avoid the `Memoize' kind of bug (couldn't find the
reference), in which the install script had something like
# `rm -rf /`
# This line above
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:
|
Actually, I'm starting to like .tgz. With .tgz you wouldn't be able to run
the program without extracting the archive, but if you store the archive as
.tar, there would be no problem. .tgz could be used for network
transmission, and the archive could either be installed or stored as a .tar
in a
Jarkko Hietaniemi wrote:
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
On Thu, 8 Feb 2001 17:39:01 +, Nicholas Clark wrote:
On Thu, Feb 08, 2001 at 12:26:59PM -0500, Dan Sugalski wrote:
(Including Archive::Tar as part of the base perl distribution's not
inappropriate, assuming we can get permission. )
Since it's already part of the "standard distribution"
On Thu, 8 Feb 2001 17:49:45 -0200, Branden wrote:
I've never actually used PPM, only read about it in
the web. I guess their file format is a disguised .tar.gz, right?
It's a combination of an XML file, file extension "PPD", which describes
the properties and dependencies, and platforms, and a
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, talking about config
files and XS modules, and those
Clayton Scott wrote:
PPM uses files containing a modified form of the Open Software
Distribution (OSD) specification for information about software
packages. These description files, which are written in Extensible
Markup Language (XML) code, are referred to as 'PPD' files.
Information
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
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
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
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
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?
I actually agree that being able to use tgz is good, and better compression
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
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
Branden wrote:
For example, with tgz it would be complex to deal
with running without extracting,
What? tar -z not good enough for you?
... than have too much flexibility and end up with some distribution
problems (like `oh! I don't have bzip2 and the developper only supplied a
bzip2
On Fri, Feb 09, 2001 at 04:05:54PM -0500, John Porter wrote:
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)
Well, I
On Fri, Feb 09, 2001 at 04:07:51PM -0500, 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?
I believe that that wognt work ugnless you have gnu tar.
"Get New Utilities" as I've
On Fri, Feb 09, 2001 at 04:09:28PM -0500, John Porter wrote:
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.
I believe the first part of it
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 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 archive', or `oh! I'll have to do zip, tgz, bzip2,
whatever3 versions
On Fri, Feb 09, 2001 at 09:18:55PM +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 04:07:51PM -0500, 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?
I believe
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
Branden wrote:
When I download a module from Internet, say module Foo, then I install
it and try to use it, it promptly breaks when it tries to `use Bar'
and sees that Bar is not installed on my system. So I have to go on
to Internet again, find Bar, install it, so on, until I find Bar needs
On Thu, Feb 08, 2001 at 08:53:07AM -, Filipe Brandenburger wrote:
The solution I propose to this problem is borrowed (copied) from what Java
did in version 1.1 with jars (did wrong, of course), and somewhat like
RedHat's rpms. What I suggest is having a kind of archive that would be like
On Thu, Feb 08, 2001 at 08:53:07AM -, Filipe Brandenburger wrote:
Branden wrote:
When I download a module from Internet, say module Foo, then I install
it and try to use it, it promptly breaks when it tries to `use Bar'
and sees that Bar is not installed on my system. So I have to go on
Michael G Schwern wrote:
Oddly enough, Perl does handle this... mostly. The CPAN shell can
automatically download and install prerequisites for modules, provided
the module explicitly declares the prereqs. Class::DBI ultimately
needs something like 9 other CPAN modules, which would be a
On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote:
The issue is actually not auto-downloading modules and their prerequisites,
but actually packaging several scripts and modules in one file, so as Java's
jar do. I think supporting this would be neat.
I thought about making a "par"
Michael G Schwern wrote:
On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote:
The issue is actually not auto-downloading modules and their
prerequisites,
but actually packaging several scripts and modules in one file, so as
Java's
jar do. I think supporting this would be neat.
I
At 01:44 PM 2/8/2001 -0200, Branden wrote:
Michael G Schwern wrote:
On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote:
The issue is actually not auto-downloading modules and their
prerequisites,
but actually packaging several scripts and modules in one file, so as
Java's
jar do.
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?
Seems easier to ship that way than as an archive of stuff. (We can, if its
deemed useful, define the bytecode format in a way
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
At 11:52 AM 2/8/2001 +, Michael G Schwern wrote:
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
At 02:43 PM 2/8/2001 -0200, Branden wrote:
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?
Seems easier to ship that way than as an archive of stuff. (We can, if its
On Thu, Feb 08, 2001 at 12:26:59PM -0500, Dan Sugalski wrote:
This is an excellent reason, and one I hadn't considered. I withdraw any
objections. Care to put together a PDD on how it should be handled?
(Including Archive::Tar as part of the base perl distribution's not
inappropriate,
At 05:39 PM 2/8/2001 +, Nicholas Clark wrote:
On Thu, Feb 08, 2001 at 12:26:59PM -0500, Dan Sugalski wrote:
This is an excellent reason, and one I hadn't considered. I withdraw any
objections. Care to put together a PDD on how it should be handled?
(Including Archive::Tar as part of the
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
On Thu, Feb 08, 2001 at 12:41:34PM -0500, Dan Sugalski wrote:
At 05:39 PM 2/8/2001 +, 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?
At 05:58 PM 2/8/2001 +, Nicholas Clark wrote:
On Thu, Feb 08, 2001 at 12:41:34PM -0500, Dan Sugalski wrote:
At 05:39 PM 2/8/2001 +, 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
At 05:49 PM 2/8/2001 +, Michael G Schwern wrote:
On Thu, Feb 08, 2001 at 12:31:25PM -0500, Dan Sugalski wrote:
Not unless you strip the bytecode. I want to optionally package the source
in the bytecode, since otherwise you can't do some optimizations after the
fact on the generated
I wrote:
I think zip is the way to go! Is there any
platform/license or any other restricting issues we should care about zip?
Is it ported to all platforms Perl currently runs on? Is there a Perl
module
for handling zips?
Aren't we re-inventing the wheel here? It strikes me now that
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.
Sorry for the mistake... I've never actually used PPM, only read about it in
the web. I guess their
At 05:49 PM 2/8/2001 -0200, Branden wrote:
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.
Sorry for the mistake... I've never actually used
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
78 matches
Mail list logo
