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 Mon, Feb 12, 2001 at 12:11:19AM -0800, yaphet jones wrote:
[Ruby]
*no god complex
*no high priests
I'll tell Matz you said that.
--
hantai mo hantai aru:
The reverse side also has a reverse side.
-- Japanese proverb
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
Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Also, the vast majority of perl variables have no finalization
attached to them.
That's true, but without static typing don't you have to treat them as if
they did? At the very least you need to do a "is it an object with a
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
i think Matz will agree with me...
(consider telling dave thomas and andy hunt, too...)
"a language author does not a god make"
-- a proverb from the days of cobol
On Mon, Feb 12, 2001 at 12:11:19AM -0800, yaphet jones wrote:
[Ruby]
*no god complex
*no high priests
I'll tell
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
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however.
I think I've heard you state that before. Can you be more specific? What
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
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other two
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however.
I
On Mon, Feb 12, 2001 at 01:33:52PM -0500, Sam Tregar wrote:
Perhaps. It's not rare in OO Perl which is coincidentally one area in
serious need of a speedup. I suppose I'm warped by my own experience -
all the code I see every day is filled with references and objects.
That's probably not
[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, 12 Feb 2001 13:33:52 -0500 (EST), Sam Tregar [EMAIL PROTECTED]
wrote:
It's reasonably obvious (which is to say "cheap") which variables aren't
involved with anything finalizable.
Probably a simple bit check and branch. Is that cheap? I guess it must
be.
Yes, but incrementing the
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
At 01:33 PM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the
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
Tony Olekshy wrote:
Damian Conway wrote:
Actually, I do agree that Perl 6 ought to provide a universal
"destructor" mechanism on *any* block. For historical reasons, I
suppose it should be Ccontinue, though I would much prefer a
more generic name, such as Ccleanup.
Perl 6 ought to
John Porter wrote:
Tony Olekshy wrote:
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause.
Why?
There's an old engineering joke about instructions that go on and on
for pages about
Nicholas Clark wrote:
It makes them far more useful as tidy up things if they are tacked
on at runtime, not compile time.
If I understand, it is proposed that code like this:
{
Alpha;
POST { Beta };
Gamma;
POST { Delta };
Epsilon;
}
will
I have extended the RFC 88 Perl 5 reference implementation to
support rudimentary POST and CATCH blocks, for which I've used
"always" and "except" as the keywords.
The new version is http://www.avrasoft.com/perl6/try6-2021.txt
Save that file as Try.pm and perl -we "use Try regress = 1"
to run
Johan Vromans wrote:
[...] As a result, error messages become utterly useless. I almost
never see a Java program that reports "Cannot open file foo".
Instead, it reports a java.lang.ioerrorexception and a stracktrace
of several pages. Useless if you do not have the source, often
even if you
John Porter wrote:
There is no try, there is only do. :-)
Nonsense.
Traditionally Perl has had both the "do" and the "eval" block
forms, the latter which traps, the former which doesn't.
"try" is just a slightly souped-up "eval" that better handles the
class of problems introduced when
Dan Sugalski wrote:
I do wish people would get garbage collection and finalization split in
their minds. They are two separate things which can, and will, be dealt
with separately.
For the record:
THE GARBAGE COLLECTOR WILL HAVE NOTHING TO DO WITH FINALIZATION, AND
NO PERL OBJECT CODE
Dan Sugalski [EMAIL PROTECTED] writes:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however.
I think I've heard you state
At 01:59 PM 2/12/2001 -0700, Tony Olekshy wrote:
Dan Sugalski wrote:
I do wish people would get garbage collection and finalization split in
their minds. They are two separate things which can, and will, be dealt
with separately.
For the record:
THE GARBAGE COLLECTOR WILL HAVE
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
At 09:08 PM 2/12/2001 +, Piers Cawley wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization
attached to
them. Full refcounting
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, 12 Feb 2001 16:28:00 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Yep, that's another issue, and one I keep forgetting about, though the fact
that we don't do predictable finalization on some objects isn't a good
Yes, I know I promised to shut up until you come up with a spec, but
At 01:44 PM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Yep, that's another issue, and one I keep forgetting about, though the fact
that we don't do predictable finalization on some objects isn't a good
Yes, I know I promised to
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization
attached to
At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
It *is* rare in OO perl, though. How many of the variables you use are
really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
forget that you need to count every scalar in every array or hash, and
every iteration over a block
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
It *is* rare in OO perl, though. How many of the variables you use are
really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
forget that you need to count every scalar in every
On Mon, Feb 12, 2001 at 01:58:57PM -0700, Tony Olekshy wrote:
- It does have in-flow presence, so it doesn't suffer from the
problem that "always" has; POST is a statement, not a dangling
clause. That fixes my main complaint with RFC 119. On the
other hand, now there's nothing
At 17:33 12/02/2001 -0500, Dan Sugalski wrote:
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
Couldn't we simply (for non-implementer values of simply) provide a way for
people to ask for finalization on an object ? Given that most of the time
it isn't needed, it wouldn't be too much of a
Dan Sugalski wrote:
[...] I wasn't talking about try{}/finally{} stuff. I was talking
about DESTROY (or its equivalent) for objects, which unfortunately
can't be tied to any one particular place in the code.
and, from another thread:
I really don't want to guarantee predictable
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
package foo;
use attrs qw(cleanup_sub);
would be nice, but I don't know that he'll go for it. (Though it's the only
way I can think of to avoid AUTOLOAD being considered a potential destructor)
Fiat?
It's pretty hard (for
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
James Mastros wrote:
You seem to like a /lot/ of context markers for
line-of-flow-control. I think that's somwhat misguided.
I have not anywhere suggested that I'm against POST blocks; in fact
RFC 88 supports the similar "always" concept mentioned by RFC 119.
I'm just trying to figure out
"David L. Nicol" wrote:
POST{stuff} is a macro for
push (my) @Deferred_stuff, sub {stuff}; # my on first use in a space
Since the reference implementation requires try, @Deferred_stuff is
actually try's argument list (a bunch of tagged catch and finally
blocks). The "my" is provided by
I've been thinking about the effect of the minimalist changes I
made to the RFC 88 reference implementation, and I don't see any
good reason not to support both the static and the dynamic forms
of end-of-block-scope actions. Consider the following proposal.
1. Support a try statement (a
61 matches
Mail list logo
