On Sunday 11 February 2001 22:48, Jan Dubois wrote:
> Doing full GC in this fashion after failed API calls will probably wipe
> out any performance gain mark-and-sweep has over reference counting.
Well, after select failed API calls, not every call. And mark-and-sweep,
if that's the GC scheme u
On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
>
> >On the other side, for a string that is matched against regexps, it doesn't
> >matter much if it has variable character length, since regexps normally read
> >all the string anyway, and indexing characters isn't much of a concern.
[moved to -internals]
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Perl needs some level of tracking for objects with finalization attached to
>them. Full refcounting isn't required, however. Also, the vast majority of
>perl variables have no finalization attach
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
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
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 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
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
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 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
Jan Dubois wrote:
> On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >Perl needs some level of tracking for objects with finalization attached
to
> >them. Full refcounting isn't required, however. Also, the vast majority
of
> >perl variables have no finalization attach
How much can we do in the compiler, and how much can we do in the
interpreter? If we're having cached bytecode, it makes sense to do
as much optimization as we can in the compiler. If not, we might
as well brute force things to conserve compilation time. Or should
this be user-selectable with "us
Simon:
> This is much harder than doing the Perl 5 summaries, because I have to
> watch over a lot more things. I'd appreciate some help; if you feel this
> is a useful exercise and you can spare about an hour a week, please get
> in touch with me and I'll tell you how you can help me. Alternative
On Mon, Feb 12, 2001 at 11:26:54AM -0500, Bryan C. Warnock wrote:
> It also sounds like a good task for the PAWBs[1] - perhaps as contributors
> while you handle the editing?
Very good thinking! I've already had a couple of volunteers (Thanks guys!)
so to save me sending out the same mail over a
Simon Cozens wrote:
> Edward Peschko wrote:
> > And PR is a function of people listening to people that they know (and
> > presumably respect). As much as we make summaries, et al, it is Larry that
> > they primarily know. And Larry saying something will get it put on slashdot.
>
> If we had mo
Alan Burlison wrote:
> Branden wrote:
> > Any suggestions?
> Yes, but none of them polite.
> You might do well to study the way perl5 handles these issues.
Perl 5 basically clones on every assignment. As it uses refcounting, it
knows it doesn't need to clone a string if its refcount=1 and it's ma
On Monday 12 February 2001 12:40, Branden wrote:
> Probably Perl 6 programs will be cached/distributed in optimized byte code
> format.
I'm not sure about the leading 'probably'. Perl 6 programs will most likely
be like most other open-source programs in other languages - either source,
which
On Mon, 12 Feb 2001 15:18:47 -0300, "Branden" <[EMAIL PROTECTED]>
wrote:
>Alan Burlison wrote:
>> Branden wrote:
>> > Any suggestions?
>> Yes, but none of them polite.
I do think this rudeness is uncalled for.
>> You might do well to study the way perl5 handles these issues.
>
>Perl 5 basically
On Mon, 12 Feb 2001 16:13:10 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
>How much can we do in the compiler, and how much can we do in the
>interpreter? If we're having cached bytecode, it makes sense to do
>as much optimization as we can in the compiler. If not, we might
>as well brute forc
At 01:45 PM 02-12-2001 -0300, Branden wrote:
>I think having both copying-GC and refcounting-GC is a good idea. I may be
>saying a stupid thing, since I'm not a GC expert, but I think objects that
>rely on having their destructors called the soonest possible for resource
>cleanup could use a refco
Simon Cozens wrote:
> How much can we do in the compiler, and how much can we do in the
> interpreter? If we're having cached bytecode, it makes sense to do
> as much optimization as we can in the compiler.
I thought, by PDD 1
(http:[EMAIL PROTECTED]/msg02116.html), it
was:
SOURCE CODE
Buddha Buck wrote:
> At 01:45 PM 02-12-2001 -0300, Branden wrote:
> >Am I too wrong here?
>
> It's... complicated...
>
Agreed.
> Here's an example of where things could go wrong:
>
> sub foo {
> my $destroyme1 = new SomeClass;
> my $destroyme2 = new SomeClass;
> my @pr
At 11:16 AM 2/12/2001 +, Tim Bunce wrote:
>On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
> >
> > >On the other side, for a string that is matched against regexps, it
> doesn't
> > >matter much if it has variable character length, since regexps
> normally read
> > >all the str
At 12:25 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
>On Monday 12 February 2001 12:40, Branden wrote:
> > Probably Perl 6 programs will be cached/distributed in optimized byte code
> > format.
>
>I'm not sure about the leading 'probably'. Perl 6 programs will most likely
>be like most other open
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 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
Just for those who don't read perl6-language, ESR has come on and is
reevaluating his statements. For the record, he gave Java and TCL a
much harder time.
At 04:13 PM 2/12/2001 +, Simon Cozens wrote:
>How much can we do in the compiler, and how much can we do in the
>interpreter? If we're having cached bytecode, it makes sense to do
>as much optimization as we can in the compiler. If not, we might
>as well brute force things to conserve compilat
At 11:01 PM 2/11/2001 -0800, Jan Dubois wrote:
>[moved to -internals]
>
>On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >Perl needs some level of tracking for objects with finalization attached to
> >them. Full refcounting isn't required, however. Also, the vast ma
At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
>wrote:
>
> >Actually I was thinking something like PMCs ($@%) being copy-GCed and
> >referred objects (new SomeClass) being refcounted. In this case above, every
> >operation would us
At 09:34 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 16:13:10 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> >How much can we do in the compiler, and how much can we do in the
> >interpreter? If we're having cached bytecode, it makes sense to do
> >as much optimization as we can
On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
wrote:
>Actually I was thinking something like PMCs ($@%) being copy-GCed and
>referred objects (new SomeClass) being refcounted. In this case above, every
>operation would use refcount's, since they're storing objects in PMCs. Wha
Jan Dubois wrote:
> >Perl 5 basically clones on every assignment. As it uses refcounting, it
> >knows it doesn't need to clone a string if its refcount=1 and it's marked
as
> >temporary, i.e., only a temporary that will go away anyway knows about
this
> >string, so it's guaranteed no other referen
At 04:21 PM 2/12/2001 -0300, Branden wrote:
>Jan Dubois wrote:
>You point out two disadvantages:
>
> > - It steal 2 bits from the SvTYPE flags. Flags are a *very* scarce
> > resource and shouldn't be used up unless there are very good reasons
> > for it.
> >
> > - Using shared strings is 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
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
> 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, 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
Dan Sugalski wrote:
> ...
> doing software copy-on-write stuff, along with having to make the garbage
> collector smart enough to deal with multiple PMCs pointing to identical
memory.
???
I thought that was the big deal of GC! Dealing with many references to the
same thing and free the thing whe
At 04:57 PM 2/12/2001 -0300, Branden wrote:
>Dan Sugalski wrote:
> > ...
> > doing software copy-on-write stuff, along with having to make the garbage
> > collector smart enough to deal with multiple PMCs pointing to identical
>memory.
>
>???
>
>I thought that was the big deal of GC! Dealing with
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
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
> Language design is a very tough nut to crack, and we decided (as
> a group) that we don't want a language designed by committee, we
> want a languaged designed by Larry.
Right, but does it hurt to give general guide-posts on how the language is to
operate? If everybody knows that it is going
At 11:48 AM 2/12/2001 -0800, Edward Peschko wrote:
> > Rushing the process because of intermittent PR problems isn't going
> > to make Perl6 any better at achieving it's goal - solving tomorrow's
> > problems better than Perl5.
>
>Again, I don't think that this would be rushing things at all. Give
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
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
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.
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
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
> While I'm not in a position to rush Larry, we are starting in on the bits
> of the internals that we can do without much input from him. It's slow
> going (mainly because we've been waiting) but it has started.
well, I don't think that anyone should be in the position to 'rush' anyone else,
b
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
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
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 Monday 12 February 2001 16:54, Dan Sugalski wrote:
> >Could you guys please use "destruction" or "cleanup" as the term for the
> >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> >else to mean: called by GC before the memory is released (see e.g
> >Java/C#).
>
> Corre
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
98 matches
Mail list logo
