gentlemen (a small liberty, i admit) -
all of this *pointless* debate could be set aside - if all of you
would just renounce perl - and adopt ruby as your language
it's why larry has shut himself up in silence - feigning illness:
*true (not bolted-on) oo language
*modern (not post-mod
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
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
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
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 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 info
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
alternate system do you have in mind? Is this just
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
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
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
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, ma
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
[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
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
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:
>
> 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
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? Wh
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
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
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, ho
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 incrementin
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
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 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
> 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 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
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 yo
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
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
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
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
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
<[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
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
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.
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 C, though I would much prefer a
> > more generic name, such as C.
>
> Perl 6 ought to p
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 pag
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;
}
wil
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 th
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 i
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 exc
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 OBJ
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 hea
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 COLLECT
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
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. F
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, 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 pr
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
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 blo
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
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 noth
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 end-of
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
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 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
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 modifie
67 matches
Mail list logo
