On 07.05.2011 01:25, Greg Ewing wrote:
Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
There, Linus says
For example, if you have an _explicit_ refcounting system, then it is
quite natural to have operations like ...
note_t *node = *np;
if
Greg Ewing, 07.05.2011 02:26:
Stefan Behnel wrote:
After all, the described crash case indicates that the Document
destructor was called before all of the Element destructors had been
called, although all Elements reference their Document, but the Document
does not refer to any of the Elements,
Stefan Behnel wrote:
It's a dead-end that is referenced by a cycle, that's all.
But shouldn't it be breaking the cycle by clearing one
of the objects that's actually part of the cycle, rather
than part of the dead-end?
I can't see how the Document could get picked for clearing
unless it was
On Fri, 6 May 2011 21:39:10 -0400
Glyph Lefkowitz gl...@twistedmatrix.com wrote:
The assertion that modern hardware is not designed for big data-structure
pointer-chasing is also a bit silly. On the contrary, modern hardware has
evolved staggeringly massive caches, specifically because
On 2011-05-07, at 03:39 , Glyph Lefkowitz wrote:
I don't know if there's a programming language and runtime with a real-time,
VM-cooperating garbage collector that actually exists today which has all the
bells and whistles required to implement an OS kernel, so I wouldn't give the
Linux
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, 06 May 2011 10:04:09 -0400
Neal Becker ndbeck...@gmail.com wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Since we're sharing links, here's Matt Mackall's take:
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
cheers
Antoine.
Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Being famous does not necessarily make you right.
OS kernels are pretty atypical software,
even if Linus is right about Linux, it doesn't apply to Python.
I have empirical evidence, not opinion, that PyPy and my own HotPy
On Fri, 06 May 2011 15:46:08 +0100
Mark Shannon ma...@dcs.gla.ac.uk wrote:
Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Being famous does not necessarily make you right.
OS kernels are pretty atypical software,
even if Linus is right about Linux, it doesn't apply
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is undefined. And going-out-of-scope
On 06/05/2011 17:18, s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
On Fri, May 6, 2011 at 9:18 AM, s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is undefined. And
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is
On 06/05/2011 17:32, Gregory P. Smith wrote:
On Fri, May 6, 2011 at 9:18 AM,s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful
On May 6, 2011, at 12:31 PM, Michael Foord wrote:
pypy and .NET choose to arbitrarily break cycles rather than leave objects
unfinalised and memory unreclaimed. Not sure what Java does.
I think that's a mischaracterization of their respective collectors;
arbitrarily break cycles implies that
Mark Shannon writes:
Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Being famous does not necessarily make you right.
No, but being a genius sure helps you beat the odds.
OS kernels are pretty atypical software,
even if Linus is right about Linux, it
On 06/05/2011 18:07, Glyph Lefkowitz wrote:
On May 6, 2011, at 12:31 PM, Michael Foord wrote:
pypy and .NET choose to arbitrarily break cycles rather than leave
objects unfinalised and memory unreclaimed. Not sure what Java does.
I think that's a mischaracterization of their respective
Michael Foord wrote:
On 06/05/2011 18:26, Mark Shannon wrote:
Michael Foord wrote:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
Michael Therefore we decided to break such a cycle at an arbitrary
Michael place, which doesn't sound too insane.
I trust arbitrary != random?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
Michael Foord, 06.05.2011 19:06:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1:
Stefan Behnel wrote:
Michael Foord, 06.05.2011 19:06:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
Mark Shannon, 06.05.2011 20:45:
Stefan Behnel wrote:
Michael Foord, 06.05.2011 19:06:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
On Fri, May 6, 2011 at 7:04 AM, Neal Becker ndbeck...@gmail.com wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Of course, a generational GC improves locality of reference.
___
Python-Dev mailing list
Python-Dev@python.org
Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
There, Linus says
For example, if you have an _explicit_ refcounting system, then it is
quite natural to have operations like ...
note_t *node = *np;
if (node-count 1)
Antoine http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is undefined. And going-out-of-scope destructors are extremely
useful. Python is already a rather broken in
Mark Shannon wrote:
For example, a file object will close itself during finalization,
but its still a valid object, just a closed file rather than an open one.
It might be valid in the sense that you won't get a segfault.
But the point is that the destructors of some objects may be
relying on
Even if he's right (and he probably is) manual memory management is still a
premature optimization for most applications. C and C++ data structures are a
PITA because you have to be so careful to avoid leaks and double-frees, so
people end up using dumb algorithms. Worrying about losing cycles
Mark Shannon wrote:
With a tracing GC:
While the Elements are finalized, the Document is still alive.
While the Document is finalized, the Elements are still alive.
Then, and only then, is the whole lot reclaimed.
One problem is that, at the C level in CPython, you can't separate
finalisation
Stefan Behnel wrote:
After all, the described crash case indicates that
the Document destructor was called before all of the Element destructors
had been called, although all Elements reference their Document, but the
Document does not refer to any of the Elements,
In that case, why was the
Apologies in advance for contributing to an obviously and increasingly
off-topic thread, but this kind of FUD about GC is a pet peeve of mine.
On May 6, 2011, at 10:04 AM, Neal Becker wrote:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Counterpoint: http://lwn.net/Articles/268783/. Sorry
32 matches
Mail list logo
