James Mastros [EMAIL PROTECTED] wrote:
The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
do refcounting (or somthing like it) for DESTROY to get called at the right
time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway
David Mitchell wrote:
James Mastros [EMAIL PROTECTED] wrote:
... do refcounting (or somthing like it) for DESTROY to get called at
the right
time if the class (or any superclass) has an AUTOLOAD, which is
expensive.
... the above seems to imply a discussion that you only need to do
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
David Mitchell wrote:
... the above seems to imply a discussion that you only need to do
expensive
ref-counting (or whatever) on objects which have a DESTROY method.
However, since you dont know in advance what class(es), if any, a
James Mastros wrote:
I'd think that an extension to delete is in order here. Basicly, delete
should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not C++.
...and trigger a GC that will get rid of the arg.
No. Perl decides for itself
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
James Mastros wrote:
I'd think that an extension to delete is in order here. Basicly, delete
should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not C++.
Umm, perldoc -f
James Mastros [EMAIL PROTECTED] wrote:
[snip about DESTORY predictablity not being neccessary]
You're probably right about that, Branden. Quite nice, but not neccessary.
Hmm, I'd have to say that predictability is very, *very* nice,
and we shouldnt ditch it unless we *really* have to.
[ lots
James Mastros wrote:
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
Also, I think it would be valid for the programmer to explicitly say ``I
would like to DESTROY this object now'',
I'd think that an extension to delete is in order here. Basicly, delete
should DESTROY the arg,
John Porter wrote:
James Mastros wrote:
I'd think that an extension to delete is in order here. Basicly, delete
should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not C++.
Agreed, definitely Perl is not C++.
...and trigger a
James Mastros wrote:
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
Huh? What delete are you thinking of? This is Perl, not C++.
Umm, perldoc -f delete?
Come to think of it, this doesn't mesh purticularly well with the current
meaning of delete. It does, however, with
[[ reply to this goes only to -internals ]]
Dan Sugalski wrote:
*) People like it
Well, if people liking it is the only reason (either is the only on or
appears 3 times in a 5 item list, what is pretty much the same to me ;-)
[... the only reason] to add a feature to Perl, we'll probably end
On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote:
As I wrote in the last post, this isn't what I'm talking about. I'm talking
about destroying the object before the GC does.
Yah, so am I. I'm just saying that after the object is destroyed, don't
keep it around.
Yeah, what about a
On Wed, Feb 14, 2001 at 01:25:26PM -0300, Branden wrote:
The problem is when objects are shared by
many variables. For example:
$a = new Object();
$b = $a;
...
destroy $a; ## would call $a-DESTROY()
...
$b-doSomething();## should die. Note that $b
Branden wrote:
John Porter wrote:
...and trigger a GC that will get rid of the arg.
No. Perl decides for itself when to do GC.
The idea is to *allow* a programmer to explicitly destroy an object, for
better (and sooner) resource disposal. The programmer wouldn't have to do it
(and
On Wed, Feb 14, 2001 at 01:30:03PM -0300, Branden wrote:
John Porter wrote:
James Mastros wrote:
I'd think that an extension to delete is in order here. Basicly, delete
should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote:
Dan Sugalski wrote:
Plus there's nothing stopping you from having $obj-DESTROY in your own
code, though it may be inadvisable.
It is (mainly) inadvisable because:
1. GC will call DESTROY when it collects the memory, so DESTROY
At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
DESTROY would get called twice, which is VERY BAD.
*blink*
It is? Why?
I grant you it isn't the clearest way of programming, but "VERY BAD"?
package
On Tue, Feb 13, 2001 at 10:32:26AM -0800, Peter Scott wrote:
At 01:16 PM 2/13/01 -0500, James Mastros wrote:
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
Certainly AUTOLOAD gets
called if DESTROY is called but not defined ... just
like any other method.
The idea is [for
At 10:32 AM 2/13/2001 -0800, Peter Scott wrote:
At 01:16 PM 2/13/01 -0500, James Mastros wrote:
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
Certainly AUTOLOAD gets
called if DESTROY is called but not defined ... just
like any other method.
The idea is [for Larry] to declare
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
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
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
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, 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
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
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
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 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, 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
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 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 Fri, 9 Feb 2001 16:14:34 -0800, Mark Koopman wrote:
but is this an example of the way people SHOULD code, or simply are ABLE to
code this. are we considering to deprecate this type of bad style, and force
to a programmer to, in this case, supply a ref to %baz in the arguements to
this sub?
Bart Lateur wrote:
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
1. Cheap allocations. Most fast collectors have a one or two
instruction malloc. In C it looks like this:
void *malloc(size) { void *obj = heap; heap += size; return obj; }
...
That is not a garbage
[Please be careful with attributions -- I didn't write any
of the quoted material...]
Russ Allbery wrote:
sub test {
my($foo, $bar, %baz);
...
return \%baz;
}
That's a pretty fundamental aspect of the Perl language; I use that sort
of construct
On Fri, 09 Feb 2001 13:19:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Almost all refcounting schemes are messy. That's one of its problems. A
mark and sweep GC system tends to be less prone to leaks because of program
bugs, and when it *does* leak, the leaks tend to be large. Plus the code
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
However, I couldn't solve the problem of "deterministic destruction
behavior": Currently Perl will call DESTROY on any object as soon as the
last reference to it goes out of scope. This becomes important if the
object own scarce external
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock"
[EMAIL PROTECTED] wrote:
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
However, I couldn't solve the problem of "deterministic destruction
behavior": Currently Perl will call DESTROY on any object as soon as the
last reference to it
At 01:05 AM 2/10/2001 +0100, Bart Lateur wrote:
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to
Mark Koopman [EMAIL PROTECTED] writes:
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
That may work for C, but not for Perl.
sub test {
my($foo, $bar, %baz);
...
return \%baz;
}
You may notice that only PART of the locally malloced
At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
Branden wrote:
I actually don't understand how traversing a graph can be faster than
incrementing/decrementing/testing for zero on a refcount.
There are two main reasons advanced garbage collectors are fast:
1. Cheap allocations. Most fast
Dan Sugalski wrote:
At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or
On Fri, Feb 09, 2001 at 12:06:12PM -0500, Ken Fox wrote:
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or reachable, data.
At 05:29 PM 2/9/2001 -0200, Branden wrote:
Ken Fox wrote:
2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or reachable,
At 06:30 PM 2/9/2001 +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
The less memory you chew through the faster your code will probably be (or
at least you'll have less overhead). Reuse is generally faster and less
resource-intensive than
Branden wrote:
Ken Fox wrote:
Some researchers have estimated that 90% or
more of all allocated data dies (becomes unreachable) before the
next collection. A ref count system has to work on every object,
but smarter collectors only work on 10% of the objects.
Does this 90/10 ratio
At 16:16 09/02/2001 -0500, Ken Fox wrote:
The general rule is the more space you "waste" the faster the collector
is. If you have memory to spare, then don't run the garbage collector as
often and your program will spend less total time garbage collecting.
In other words, the collection cost per
Dan Sugalski wrote:
At 04:09 PM 2/9/2001 -0200, Branden wrote:
If I change the way some objects are used so
that I tend to create other objects instead of reusing the old ones, I'm
actually not degrading GC performance, since its work is proportional to
live data. Right?
Correct.
At 10:21 PM 2/9/2001 +0100, Robin Berjon wrote:
At 16:16 09/02/2001 -0500, Ken Fox wrote:
The general rule is the more space you "waste" the faster the collector
is. If you have memory to spare, then don't run the garbage collector as
often and your program will spend less total time garbage
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
There are two main reasons advanced garbage collectors are fast:
1. Cheap allocations. Most fast collectors have a one or two
instruction malloc. In C it looks like this:
void *malloc(size) { void *obj = heap; heap += size; return
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
That may work for C, but not for Perl.
sub test {
my($foo, $bar, %baz);
...
return \%baz;
}
You may notice that only PART of the locally malloced memory, gets
freed. the memory of %baz
"Branden" [EMAIL PROTECTED] writes:
Piers Cawley wrote:
"Branden" [EMAIL PROTECTED] writes:
Of course, C++ has no GC, which is a good thing, but you can always
fake it with Refcounts, which is much more efficient, and easily
feasable with C++.
Err... current research shows that the
"Branden" [EMAIL PROTECTED] wrote:
Well, mandatory locking is something we should definetly NOT have in Perl6.
Most of perl's code today is not threaded, and I believe much of it will
continue to be this way. The pseudo-fork thread behaviour that is being
proposed also makes this ok. Even if
David Mitchell wrote:
I let the Perl developers do all
the hard locking code behind the scenes, and I don't have to worry my
pretty
little head about it.
Now, there may be practical reasons why it isnt possible for perl to do
this for me automatically (reasons, anyone?), but it's a nice
"Branden" [EMAIL PROTECTED] wrote:
The thing with mandatory locks per variable, is that as long as you only
want to access _that_ variable, it's ok, but if you want to make several
uses of several variables and want to do it all at once, you've got a
problem.
[ big snip ]
Sorry, I
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote:
On Sun, Jan 28, 2001 at 08:56:33PM -0500, Michael G Schwern wrote:
On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote:
Uhm, I'm sorry, but that's not good enough. You cannot distinguish
between Windows 95/98/ME
On Sun, Jan 28, 2001 at 11:07:10PM -0700, Nathan Torkington wrote:
Jarkko Hietaniemi writes:
True, but you can't do any of all that without knowing the platform
accurately (nontrivial and requires core mod or XS). Once that's
done, the rest is just a matter of extending File::Spec
J. David Blackstone wrote:
Yeah, that was one of my disappointments when I finally made the
Java plunge last month. I kind of expected integers to be objects in
what I had heard was the "perfect, pure" OO language.
Everybody seems to be missing the fact that jwz bitching about Java's
"32 bit
Jeanna FOx [EMAIL PROTECTED] wrote:
Everybody seems to be missing the fact that jwz bitching about Java's
"32 bit non-object ints" means that at least he thinks they could be
salvaged. What would he think of Perl's "224 bit non-object ints"?!
Don't get smug because Perl can iterate over an
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
The desire to know the name of the runtime platform is a misdirected
desire.
What you really want to know is whether function Foo will be there,
what
kind of signature it has, whether file Bar will be there, what kind of
format it has, and so
Jeanna FOx wrote:
Everybody seems to be missing the fact that jwz bitching about Java's
"32 bit non-object ints" means that at least he thinks they could be
salvaged. What would he think of Perl's "224 bit non-object ints"?!
Don't get smug because Perl can iterate over an array of anything.
Perhaps you meant that Perl 6 is going to have homogeneous arrays, in
which case an array of ints would keep 32 bits (per value) of int data in
the array and auto-generate the extra flags and stuff when a value is
extracted from the array. That's possible, but it's a special case of small
David Mitchell wrote:
Jeanna FOx [EMAIL PROTECTED] wrote:
Everybody seems to be missing the fact that jwz bitching about Java's
"32 bit non-object ints" means that at least he thinks they could be
salvaged. What would he think of Perl's "224 bit non-object ints"?!
Don't get smug because
Jeanna FOx wrote:
It also looks like some features are impossible to turn off -- like the
mandatory locking that jwz hates about Java. It's not safe to turn it
off, but it's not really safe with it on either. Some people would rather
loose the illusion of safety to get better performance.
At 12:20 PM 1/29/2001 -0500, Jeanna FOx wrote:
David Mitchell wrote:
Jeanna FOx [EMAIL PROTECTED] wrote:
Everybody seems to be missing the fact that jwz bitching about Java's
"32 bit non-object ints" means that at least he thinks they could be
salvaged. What would he think of Perl's
: Jeanna FOx wrote:
: It also looks like some features are impossible to turn off -- like the
: mandatory locking that jwz hates about Java. It's not safe to turn it
: off, but it's not really safe with it on either. Some people would rather
: loose the illusion of safety to get better
At 12:54 PM 1/29/2001 -0800, Thomas Butler wrote:
: Jeanna FOx wrote:
: It also looks like some features are impossible to turn off -- like the
: mandatory locking that jwz hates about Java. It's not safe to turn it
: off, but it's not really safe with it on either. Some people would rather
:
"Branden" [EMAIL PROTECTED] writes:
Of course, C++ has no GC, which is a good thing, but you can always
fake it with Refcounts, which is much more efficient, and easily
feasable with C++.
Err... current research shows that the refcount approach is one of the
slowest forms of GC, and it
On Sat, 27 Jan 2001 18:16:52 -0500, Michael G Schwern wrote:
o The architecture-interrogation primitives are inadequate; there is no
robust way to ask ``am I running on Windows'' or ``am I running on
Unix.''
**We have $^O, but it requires parsing every time**
Uhm, I'm
On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote:
Uhm, I'm sorry, but that's not good enough. You cannot distinguish
between Windows 95/98/ME on one side, and NT/2k on the other, using $^O
alone. After all, $^O is just a constant burnt into the executable when
perl was compiled.
On Sun, Jan 28, 2001 at 08:56:33PM -0500, Michael G Schwern wrote:
On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote:
Uhm, I'm sorry, but that's not good enough. You cannot distinguish
between Windows 95/98/ME on one side, and NT/2k on the other, using $^O
alone. After all, $^O
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote:
The desire to know the name of the runtime platform is a misdirected desire.
What you really want to know is whether function Foo will be there, what
kind of signature it has, whether file Bar will be there, what kind of
On Mon, Jan 29, 2001 at 01:08:21AM -0500, Michael G Schwern wrote:
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote:
The desire to know the name of the runtime platform is a misdirected desire.
What you really want to know is whether function Foo will be there, what
kind
Jarkko Hietaniemi writes:
True, but you can't do any of all that without knowing the platform
accurately (nontrivial and requires core mod or XS). Once that's
done, the rest is just a matter of extending File::Spec
(trivial and pure Perl).
Trivial? *cough* *snigger*
If it was
On Mon, Jan 29, 2001 at 12:10:31AM -0600, Jarkko Hietaniemi wrote:
Trivial? *cough* *snigger*
I'd write it up for you right now, but its too big to fit in the
margin.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Skrewtape I've heard that semen tastes
I like the final point:
Stay tuned, I'm sure I'll have found something new to hate by tomorrow.
(Well, that's how this document originally ended. But it's not true,
because I'm back to hacking in C, since it's the still only way to
ship portable programs.)
--
$jhi++; #
J. David Blackstone wrote:
And in related news, it's a total pain that one can't iterate over the
contents of an array without knowing intimate details about its
contents: you have to know whether it's byte[], or int[], or Object[].
That's one nice thing about Perl; you can foreach
J. David Blackstone wrote:
That's one nice thing about Perl; you can foreach over
an array of all sorts of different things. In fact, being able to
just have an array of all sorts of different things is something Perl
still has over Java, C, and the like.
It's not that big a deal. An
82 matches
Mail list logo
