Oops sorry I meant to send it elsewhere. Stupid auto complete :P
On Sat, Mar 8, 2014 at 3:25 AM, Nick Coghlan wrote:
> On 8 March 2014 20:27, Sean Felipe Wolfe wrote:
>> Hello everybody,
>>
>> I'm getting back into some Java game programming using the (excellent)
>> libgdx library. It's been a c
On Sat, 8 Mar 2014 16:14:23 +0100
Victor Stinner wrote:
> 2014-03-08 14:33 GMT+01:00 Antoine Pitrou :
> > 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(fu
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 reason
On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner wrote:
> 2014-03-08 14:33 GMT+01:00 Antoine Pitrou :
>> 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)
2014-03-08 14:33 GMT+01:00 Antoine Pitrou :
> 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 disappears: as s
On Sat, 8 Mar 2014 23:16:07 +1000
Nick Coghlan wrote:
> On 8 March 2014 23:01, Victor Stinner wrote:
> > 2014-03-08 12:45 GMT+01:00 Antoine Pitrou :
> >>> Attached script: never_deleted2.py, it's almost the same but it
> >>> explains better the problem. The script creates MyObject and Future
> >>
On 8 March 2014 23:01, Victor Stinner wrote:
> 2014-03-08 12:45 GMT+01:00 Antoine Pitrou :
>>> 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
2014-03-08 12:45 GMT+01:00 Antoine Pitrou :
>> 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 the future,
On Sat, 8 Mar 2014 11:06:54 +0100
Victor Stinner 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 reference cycle (between
On 8 March 2014 20:27, Sean Felipe Wolfe 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 send this to core
On Sat, Mar 8, 2014 at 9:06 PM, Victor Stinner 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 have __del__ in there,
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 p
2014-03-08 1:14 GMT+01:00 Jim Jewett :
>>> 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.
Attached
13 matches
Mail list logo
