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
> | inclu
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
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 re
On Tue, 13 Feb 2001, Branden wrote:
> 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
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 whe
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
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 ut
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
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 abo
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 it
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.
<[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 weigh
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 manage
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 ne
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 rea
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 solv
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 lib
<[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 yo
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
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 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 prog
> 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.
Caref
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
wit
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 .
> >
> > As resource files can be attached to the archive, I think not allowing
> > __DATA__ wouldn
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 importa
[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 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 a
[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 t
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.
>
> [x
[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
> Vap
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
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, ma
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
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 for
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 a
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 info
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 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 a
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 indi
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 i
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:
> | Pla
On Sat, 10 Feb 2001, Branden wrote:
> Another advantage I see on tar and gzip is that they are used by GNU, so I'm
> pretty sure there probably wouldn't be any licensing issues, and I'm not
> quite sure .zip doesn't use LZW, the same compression method of GIF...
Zip uses the same compress method
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 bre
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 st
On Fri, 9 Feb 2001 21:18:55 +, Nicholas Clark wrote:
>> What? tar -z not good enough for you?
>
>I believe that that wognt work ugnless you have gnu tar.
As a Windows user, I should add:
* Archive::Tar is part of the Perl 5.6.0 distributions for Win32
(Activestate and IndigoPerl)
* On a
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 aft
On Fri, Feb 09, 2001 at 03:25:42PM -0600, Jarkko Hietaniemi wrote:
> I assume the next logical thing to add would be MD5?
Yes, well before zip (IMHO). It would make CPAN.pm a happy bunny, and should
make the world (feel) more secure.
This is now really perl5 isn't it?
Nicholas Clark
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 t
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?
>
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 vers
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, af
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
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 firs
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"
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
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,
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
> b
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
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 i
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: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 co
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 the
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
appr
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
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 li
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 i
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.
> Informat
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 t
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, 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 distributio
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 databas
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 actual
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 the
At 05:00 PM 2/8/01 -0200, Branden wrote:
>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-
I'm writing a PDD on the subject, as suggested by Dan, and I intend to post
it by tomorrow. In the lack of a better list, I think we stick
with -language. If someone can suggest a better one, please do it.
- Branden
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 Act
Dan Sugalski wrote:
> At 05:58 PM 2/8/2001 +, Nicholas Clark wrote:
> >\zip's better in that it allows easy random access to a compressed file,
> >[without having to compress everything else first] but worse for the
> >same reason because you don't get as good a compression ratio by
> >compres
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 generate
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 arbitr
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?
>
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, a
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 bytecode stream.
Clever dog!
> > 2) You have to m
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
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, a
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
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...
>
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 B::Depar
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
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
>
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.
>
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" uti
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
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 g
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 li
94 matches
Mail list logo
