2014-03-08 1:14 GMT+01:00 Jim Jewett jimjjew...@gmail.com:
Could you clarify what the problem actually is?
Please see:
http://bugs.python.org/file33238/never_deleted.py
I would not expect it to be cleared at least until go runs ... and reading
the ticket, it sounds like it is cleared then.
Hello everybody,
I'm getting back into some Java game programming using the (excellent)
libgdx library. It's been a couple years since I've written Java
classes from scratch and it's got me thinking.
The Java code I'm going through has lots 'final' and 'static' variable
declarations, along with
On Sat, Mar 8, 2014 at 9:06 PM, Victor Stinner victor.stin...@gmail.com wrote:
And MyObject is not destroyed which is an obvious memory leak, beause
there is no more explicit reference to it.
And it doesn't seem to be getting put into gc.garbage, either, which
is probably worth mentioning. You
On 8 March 2014 20:27, Sean Felipe Wolfe ether@gmail.com wrote:
Hello everybody,
I'm getting back into some Java game programming using the (excellent)
libgdx library. It's been a couple years since I've written Java
classes from scratch and it's got me thinking.
Sean, did you mean to
On Sat, 8 Mar 2014 11:06:54 +0100
Victor Stinner victor.stin...@gmail.com wrote:
Attached script: never_deleted2.py, it's almost the same but it
explains better the problem. The script creates MyObject and Future
objects which are never deleted. Calling gc.collect() does *not* break
the
2014-03-08 12:45 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Attached script: never_deleted2.py, it's almost the same but it
explains better the problem. The script creates MyObject and Future
objects which are never deleted. Calling gc.collect() does *not* break
the reference cycle (between
On 8 March 2014 23:01, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 12:45 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Attached script: never_deleted2.py, it's almost the same but it
explains better the problem. The script creates MyObject and Future
objects which are never
On Sat, 8 Mar 2014 23:16:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 8 March 2014 23:01, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 12:45 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Attached script: never_deleted2.py, it's almost the same but it
explains better the
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange for it to be disposed of:
fut = asyncio.Future()
asyncio.Task(func(fut))
del fut
[etc.]
then the problem
On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange for it to be disposed of:
fut =
Hi All,
This is my first time on any mailing list... Please point out any mistakes..
I had a suggestion about the implementation of
unittest.TestCase.assert* methods. They all call failureException
separately. This is also what the unittest.TestCase.fail method does.
Is there any specific
On Sat, 8 Mar 2014 16:14:23 +0100
Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange for it to be disposed of:
fut =
Oops sorry I meant to send it elsewhere. Stupid auto complete :P
On Sat, Mar 8, 2014 at 3:25 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 8 March 2014 20:27, Sean Felipe Wolfe ether@gmail.com wrote:
Hello everybody,
I'm getting back into some Java game programming using the (excellent)
13 matches
Mail list logo
