Mark Matusevich mark...@users.sourceforge.net added the comment:
This is what I got on computer with 512 MB RAM:
Mandriva Linux 2009.1
=
Python 2.6.1 (r261:67515, Jul 14 2010, 09:23:11) [GCC 4.3.2]
- Python process killed by operating system after 14
Microsoft
Martin v. Löwis mar...@v.loewis.de added the comment:
Ok, I'm closing this as won't fix. The OP doesn't have the issue anymore;
anybody else having some issue please report that separately (taking into
account that you are likely asked to provide a patch as well).
--
resolution: -
Swapnil Talekar swapnil...@gmail.com added the comment:
Mark, are you sure that the above program is sure to cause a crash. I had
absolutely no problem running it with Python 3.1.2. With Python 2.6.5, PC went
terribly slow but the program managed to run till i==14 without crashing. I did
not
Brian Curtin cur...@acm.org added the comment:
(not sure its for this thread though but...) Windows on default limits
the amount of memory for 32 bit processes to 2GB. There's a bit in
the PE image which tells 64 bit windows to give it 4GB (on 32 bit
windows PAE needs to be enabled too)
Itai itai...@gmail.com added the comment:
You are right, ofcourse... I haven't got the time for doing the right thing,
But I've found another workaround that helped me though and might be helpful
to others.
(not sure its for this thread though but...) Windows on default limits the
amount of
Itai i itai...@gmail.com added the comment:
Hi all,
I'm joining Mark's assertion - this is a real issue for me too. I've stumbled
into this problem too.
I have a numpy/scipy kind of application (about 6000+ lines so far) which needs
to allocate alot of memory for statistics derived from real
Ray.Allen ysj@gmail.com added the comment:
How about calling gc.collect() explicitly in the loop?
--
nosy: +ysj.ray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1524938
___
Itai itai...@gmail.com added the comment:
Sure, that's what i'll do for now. Its an ok workaround for me, I was just
posting to support the
notion that its a bug (lets call it usability bug) and something that people
out there do run into.
There's also a scenerio where you couldn't use this
Martin v. Löwis mar...@v.loewis.de added the comment:
Anybody *really* interested in this issue: somebody will need to write a PEP,
get it accepted, and provide an implementations. Open source is about
scratching your own itches: the ones affected by a problems are the ones which
are also
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file18568/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1524938
___
Antoine Pitrou pit...@free.fr added the comment:
I'm not sure what we should do anyway. Your program will first swap out
and thrash before the MemoryError is raised. Invoking the GC when memory
allocation fails would avoid the MemoryError, but not the massive
slowdown due to swapping.
Mark Matusevich mark...@users.sourceforge.net added the comment:
It looks like the severity of this problem is underestimated here.
A programmer working with a significant amount of data (e.g SciPy user)
and uses OOP will face this problem. Most OOP designs result in
existence of some loops
Antoine Pitrou pit...@free.fr added the comment:
Lowering priority since, as Martin said, it shouldn't be needed in
real-life situations.
--
nosy: +pitrou
priority: high - low
stage: - needs patch
type: feature request - resource usage
___
Python
Changes by Daniel Diniz aja...@gmail.com:
--
versions: +Python 2.7, Python 3.1 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1524938
___
Changes by Christian Heimes:
--
priority: normal - high
versions: +Python 2.6
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1524938
_
___
Python-bugs-list
15 matches
Mail list logo
