BTW, what's going on with the deprecation of sys.setrecursionlimit? What should I use instead? /home/dstromberg/src/home-svn/backshift/trunk/treap.py:40: DeprecationWarning: setrecursionlimit deprecated sys.setrecursionlimit(min_heap_size)
IIRC nothing, pypy knows how big the stack is (if you are using it limit stack size and not get a core dump). On Sat, Dec 11, 2010 at 2:41 PM, Dan Stromberg <drsalists@gmail.com> wrote:
BTW, what's going on with the deprecation of sys.setrecursionlimit? What should I use instead?
/home/dstromberg/src/home-svn/backshift/trunk/treap.py:40: DeprecationWarning: setrecursionlimit deprecated sys.setrecursionlimit(min_heap_size) _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- Leonardo Santagada
I originally wrote the code ( http://stromberg.dnsalias.org/~strombrg/treap/ ) for CPython, where the recursion depth was too low out of the box. It sounds like on pypy, I might actually be decreasing the recursion depth. There probably should be a "set recursion depth to at least..." function. Or I should getrecursiondepth and inspect before "increasing". On Sat, Dec 11, 2010 at 9:10 AM, Leonardo Santagada <santagada@gmail.com> wrote:
IIRC nothing, pypy knows how big the stack is (if you are using it limit stack size and not get a core dump).
On Sat, Dec 11, 2010 at 2:41 PM, Dan Stromberg <drsalists@gmail.com> wrote:
BTW, what's going on with the deprecation of sys.setrecursionlimit? What should I use instead?
/home/dstromberg/src/home-svn/backshift/trunk/treap.py:40: DeprecationWarning: setrecursionlimit deprecated sys.setrecursionlimit(min_heap_size) _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
-- Leonardo Santagada
Hi Dan, On Sat, Dec 11, 2010 at 8:17 PM, Dan Stromberg <drsalists@gmail.com> wrote:
I originally wrote the code ( http://stromberg.dnsalias.org/~strombrg/treap/ ) for CPython, where the recursion depth was too low out of the box. It sounds like on pypy, I might actually be decreasing the recursion depth.
There probably should be a "set recursion depth to at least..." function. Or I should getrecursiondepth and inspect before "increasing".
PyPy throws a RuntimeError anyway when the stack is getting too big, i.e. when it uses more than N kilobytes. On the other hand, setrecursiondepth() on CPython (and previously on PyPy) is based on counting the recursion depth, which is a different measure which only approximates the real stack size. We decided that it doesn't make sense to provide both on PyPy, so we killed the one that is an approximation (and makes the JIT a little bit slower). That's all. A bientôt, Armin.
2010/12/11 Dan Stromberg <drsalists@gmail.com>:
BTW, what's going on with the deprecation of sys.setrecursionlimit? What should I use instead?
You shouldn't use anything. It has no affect on pypy. FWIW, I disagree with the deprecation. I think should just be a no-op. -- Regards, Benjamin
Hi Benjamin, On Sat, Dec 11, 2010 at 6:10 PM, Benjamin Peterson <benjamin@python.org> wrote:
FWIW, I disagree with the deprecation. I think should just be a no-op.
But then people are going to complain that their app seems to hang up on pypy, and neither they nor we have any clue what is going on --- until we figure out that they used sys.setrecursionlimit() to put a bound on recursion and catch the RuntimeError. That's at least the reason for which I suggested that calling sys.setrecursionlimit() should at least print a warning. Now I agree that maybe the message of the warning is not the clearest one. A bientôt, Armin.
On 11/12/10 18:32, Armin Rigo wrote:
But then people are going to complain that their app seems to hang up on pypy, and neither they nor we have any clue what is going on --- until we figure out that they used sys.setrecursionlimit() to put a bound on recursion and catch the RuntimeError. That's at least the reason for which I suggested that calling sys.setrecursionlimit() should at least print a warning. Now I agree that maybe the message of the warning is not the clearest one.
I was about to propose to change the message into something like "sys.setrecursionlimit is ignored by PyPy". I think this is already an improvement over the current message, but has the drawback than then people will complain that pypy might run out of stack (which is false, but not apparent by the warning message). Also, we should maybe change the class of the Warning. IIRC, DeprecationWarning is going to be ignored by default on python2.7, which means that most people won't see the warning at all once we merge fast-forward. ciao, Anto
On Sat, Dec 11, 2010 at 1:16 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
On 11/12/10 18:32, Armin Rigo wrote:
But then people are going to complain that their app seems to hang up on pypy, and neither they nor we have any clue what is going on --- until we figure out that they used sys.setrecursionlimit() to put a bound on recursion and catch the RuntimeError. That's at least the reason for which I suggested that calling sys.setrecursionlimit() should at least print a warning. Now I agree that maybe the message of the warning is not the clearest one.
I was about to propose to change the message into something like "sys.setrecursionlimit is ignored by PyPy". I think this is already an improvement over the current message, but has the drawback than then people will complain that pypy might run out of stack (which is false, but not apparent by the warning message).
Also, we should maybe change the class of the Warning. IIRC, DeprecationWarning is going to be ignored by default on python2.7, which means that most people won't see the warning at all once we merge fast-forward.
ciao, Anto _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Indeed, perhaps RuntimeWarning is more approrpiate? -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me
On Sat, Dec 11, 2010 at 19:16, Antonio Cuni <anto.cuni@gmail.com> wrote:
On 11/12/10 18:32, Armin Rigo wrote:
But then people are going to complain that their app seems to hang up on pypy, and neither they nor we have any clue what is going on --- until we figure out that they used sys.setrecursionlimit() to put a bound on recursion and catch the RuntimeError. That's at least the reason for which I suggested that calling sys.setrecursionlimit() should at least print a warning. Now I agree that maybe the message of the warning is not the clearest one.
I was about to propose to change the message into something like "sys.setrecursionlimit is ignored by PyPy". I think this is already an improvement over the current message, but has the drawback than then people will complain that pypy might run out of stack (which is false, but not apparent by the warning message).
Do you mean that the stack size on Python is not limited (which has its problems for infinite-recursion bugs), or just that stack overflow is handled gracefully by throwing an exception? In the first case, I'd propose "stack size on PyPy cannot be limited" (and maybe additionally "sys.setrecursionlimit is ignored by PyPy"). In the second case, I'd propose "recursion depth is only limited by stack size". Maybe the call should try adjusting the stack size? However, reading os_thread.py:stack_size() [1] suggests that the stack size _is_ limited for a thread, so I guess you're in the second case. [1] codespeak.net/pypy/dist/pypy/module/thread/os_thread.py Best regards -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/
2010/12/11 Paolo Giarrusso <p.giarrusso@gmail.com>:
On Sat, Dec 11, 2010 at 19:16, Antonio Cuni <anto.cuni@gmail.com> wrote:
On 11/12/10 18:32, Armin Rigo wrote:
But then people are going to complain that their app seems to hang up on pypy, and neither they nor we have any clue what is going on --- until we figure out that they used sys.setrecursionlimit() to put a bound on recursion and catch the RuntimeError. That's at least the reason for which I suggested that calling sys.setrecursionlimit() should at least print a warning. Now I agree that maybe the message of the warning is not the clearest one.
I was about to propose to change the message into something like "sys.setrecursionlimit is ignored by PyPy". I think this is already an improvement over the current message, but has the drawback than then people will complain that pypy might run out of stack (which is false, but not apparent by the warning message).
Do you mean that the stack size on Python is not limited (which has its problems for infinite-recursion bugs), or just that stack overflow is handled gracefully by throwing an exception?
The latter. -- Regards, Benjamin
participants (7)
-
Alex Gaynor -
Antonio Cuni -
Armin Rigo -
Benjamin Peterson -
Dan Stromberg -
Leonardo Santagada -
Paolo Giarrusso