"TB" == Tim Bunce [EMAIL PROTECTED] writes:
TB On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
"TB" == Tim Bunce [EMAIL PROTECTED] writes:
TB As a part of that the weak reference concept, bolted recently into
TB perl5, could be made more central in perl6.
TB
Damien Neil wrote:
Using object lifetime to control state is almost never a good idea,
even if you have deterministic finalization. A much better approach
is to have methods which allow holders of the object to control it,
and a finalizer (DESTROY method) which cleans up only if necessary.
Hong Zhang
A deterministic finalization means we shouldn't need to force
programmers
to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Either doesn't exist, or is more expensive than refcounting. I guess we
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
Hong Zhang
A deterministic finalization means we shouldn't need to force
programmers
to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Either
Tim Bunce wrote:
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
And don't forget that if we stick with refcounting, we should try to
find a
way to break circular references, too.
As a part of that the weak reference concept, bolted recently into perl5,
could be made more central
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
I think you just said all about why we shouldn't bother giving objects
deterministic finalization, and I agree with you. If we explicitly want to
free resources (files, database connections), then we explicitly call close.
Otherwise, it
Damien Neil wrote:
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
I think you just said all about why we shouldn't bother giving objects
deterministic finalization, and I agree with you. If we explicitly want
to
free resources (files, database connections), then we explicitly
Branden wrote:
Just set autoflush, if you're lazy...
And say goodbye to performance...
The problem is
that you can not only count on $fh's DESTROY being called at the end of
the block, you often can't count on it ever happening.
Anyway, the file would be flushed and closed...
That's
Hong Zhang wrote:
This code should NEVER work, period. People will just ask for trouble
with this kind of code.
Actually I meant to have specified "" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl
Hong Zhang wrote:
This code should NEVER work, period. People will just ask for trouble
with this kind of code.
Actually I meant to have specified "" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl
Hong Zhang wrote:
That was not what I meant. Your code already assume the existence of
reference counting. It does not work well with any other kind of garbage
collection. If you translate the same code into C without putting in
the close(), the code will not work at all.
Wrong, it does
Alan Burlison wrote:
I think you'll find that both GC *and* reference counting scheme will
require the heay use of mutexes in a MT program.
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to implement. Making them run
well always requires help from the OS memory manager and that
would hurt portability. (If we don't have OS
Hong Zhang wrote:
The memory barriers are always needed on SMP, whatever algorithm
we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
The memory barrier can be easily coded in assembly, or intrinsic
At 02:08 PM 2/15/2001 -0800, Hong Zhang wrote:
Hong Zhang wrote:
This code should NEVER work, period. People will just ask for trouble
with this kind of code.
Actually I meant to have specified "" as the mode, i.e. append, then
what I originally said holds true. This behaviour is
At 09:13 PM 2/15/2001 -0500, Ken Fox wrote:
Hong Zhang wrote:
The memory barriers are always needed on SMP, whatever algorithm
we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
Not really they
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 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
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 NuclearReactor::CoolingRod;
sub new {
[[ reply goes to -internals ]]
OK. Let's clear it up all at once from start. Below is the lifecycle of an
object (in Perl). A reference is blessed, and an object is the result of
this blessing. During the object's life, several methods of it are called,
but independent of which are called, it
[trimming distribution to -internals only]
On Wed, Feb 14, 2001 at 07:44:53PM +, Simon Cozens wrote:
package NuclearReactor::CoolingRod;
sub new {
Reactor-decrease_core_temperature();
bless {}, shift
}
sub DESTROY {
Reactor-increase_core_temperature();
}
A better
On Wed, Feb 14, 2001 at 01:24:34PM -0800, Damien Neil wrote:
Using object lifetime to control state is almost never a good idea,
even if you have deterministic finalization.
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy, remember?
On Thu, Feb 15, 2001 at 12:11:27AM +, Simon Cozens wrote:
Using object lifetime to control state is almost never a good idea,
even if you have deterministic finalization.
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy,
[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 attached
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
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
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 attached to
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
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 @processme1;
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
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 majority of
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 use
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. What
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, 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
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
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
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
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
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 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
On Sun, 11 Feb 2001, 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 resources
At 11:36 PM 2/11/2001 -0500, Sam Tregar wrote:
On Sun, 11 Feb 2001, 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
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
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 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 recycling. What's true for tin cans is true for memory.
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.
[EMAIL PROTECTED] wrote:
So, it's more a data preserver than a garbage collector ;-)
Abigail
I find it odd that perl mallocs each string individually, for instance;
I had thought that it would only malloc massive pieces and do its own
allocation and freeing of it. Its laziness, of
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 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
At 04:53 PM 2/9/2001 -0500, Ken Fox wrote:
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
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:
Sorry, I misunderstood you. I think in fact we agree! What I was
advocating was that Perl should automatically make accesses to
individual shared variables safe, so 2 threads executing
1: $shared = 10; 2: $shared = 20;
wont guarantee whether $shared ends up as 10 or
We seem to have gotten away from the subject at hand (what jwz, who doesn't
like to use Perl, doesn't like about Java, and how those Java deficiencies
will make Perl more likeable to others who don't like to use Perl, either) to
peripheral, unimportant, non-topical things... like Perl 6
"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
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
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:
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.
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.
On Mon, Jan 29, 2001 at 03:14:04PM -0200, Branden wrote:
Well, if a compiler can't figure it out that the types of the
variables "Object" and "int" are different and it should make
a conversion to assign one from the other, well, then the
compiler writers are damn bad programmers!
The
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
:
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 [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
"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
Tony Bowden pointed out a JWZ rant simply entitled 'java sucks'. He
makes a number of specific, solid technical points about Java which I
think have relevance to Perl.
http://www.jwz.org/doc/java.html
What follows are some of the more interesting excerpts. **These are
my comments***
Here's
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**
And $^O =~ /win/i broke recently when Apple introduced Darwin.
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
85 matches
Mail list logo
