Re: [pypy-dev] Trunk failing to build?
Hi, On Sat, Dec 11, 2010 at 5:46 AM, Benjamin Peterson benja...@python.org wrote: Yep. Hopefully fixed in r79965. Sorry, my fault. Armin ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm and dbm merge - ctypes bug?
On Thu, Dec 9, 2010 at 10:05 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Hi
2010/12/9 Dan Stromberg drsali...@gmail.com
Is there a known problem with pypy's ctypes?
Yes, several of them have already been fixed in trunk, especially
about memory chunks being freed too early.
--
Amaury Forgeot d'Arc
Using a trunk from late in the day yesterday, my gdbm_ctypes module is
still giving gibberish keys sometimes, but only with pypy:
find /usr/share/jpilot -print0 | (export dir=$(pwd)/save-dir-pypy; cd
../..; ./this-pypy ./backshift --save-directory $dir --backup)
Using gdbm_ctypes
/home/dstromberg/src/home-svn/backshift/trunk/treap.py:40:
DeprecationWarning: setrecursionlimit deprecated
sys.setrecursionlimit(min_heap_size)
Creating backup id
1292083099.51-benchbox-Sat_Dec_11_07_58_19_2010-7bada40ed14b282b
Inhaling filenames, readline0.__file__: /home/dstromberg/lib/readline0.py
processing directory /usr/share/jpilot
processing regular file /usr/share/jpilot/CalendarDB-PDat.pdb
5.88% done, 3.61 files/second, ETA Sat Dec 11 07:58:24 2010,
processing regular file /usr/share/jpilot/MañanaDB.pdb
11.76% done, 5.55 files/second, ETA Sat Dec 11 07:58:22 2010,
processing regular file /usr/share/jpilot/jpilotrc.green
17.65% done, 6.17 files/second, ETA Sat Dec 11 07:58:22 2010,
processing regular file /usr/share/jpilot/jpilotrc.purple
23.53% done, 6.63 files/second, ETA Sat Dec 11 07:58:22 2010,
processing regular file /usr/share/jpilot/ContactsDB-PAdd.pdb
29.41% done, 7.37 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/MemoDB.pdb
35.29% done, 8.03 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/jpilotrc.blue
41.18% done, 8.59 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/ExpenseDB.pdb
47.06% done, 8.74 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/jpilotrc.default
52.94% done, 8.86 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/AddressDB.pdb
58.82% done, 8.89 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/ToDoDB.pdb
64.71% done, 9.23 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/TasksDB-PTod.pdb
70.59% done, 9.53 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/DatebookDB.pdb
76.47% done, 9.80 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/Memo32DB.pdb
82.35% done, 9.99 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/MemosDB-PMem.pdb
88.24% done, 10.21 files/second, ETA Sat Dec 11 07:58:21 2010,
processing regular file /usr/share/jpilot/jpilotrc.steel
94.12% done, 10.36 files/second, ETA Sat Dec 11 07:58:21 2010,
! ../../dumpdb $(ls -td save-dir-pypy/files/1* | head
-1)/dir-usr/dir-share/dir-jpilot/files | egrep --binary-files=text --
'-' | awk ' { print $2 }' | tr -d '[A-Za-z0-9\._\-]' | sed '/^$/d' |
egrep --binary-files=text .
`
ñ
`
�...@à
make[2]: *** [go] Error 1
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] setrecursionlimit deprecation?
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
Re: [pypy-dev] setrecursionlimit deprecation?
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 drsali...@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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] setrecursionlimit deprecation?
2010/12/11 Dan Stromberg drsali...@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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] setrecursionlimit deprecation?
Hi Benjamin, On Sat, Dec 11, 2010 at 6:10 PM, Benjamin Peterson benja...@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. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] setrecursionlimit deprecation?
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
Re: [pypy-dev] setrecursionlimit deprecation?
On Sat, Dec 11, 2010 at 1:16 PM, Antonio Cuni anto.c...@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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Trunk failing to build?
On Sat, Dec 11, 2010 at 3:05 AM, Armin Rigo ar...@tunes.org wrote: Hi, On Sat, Dec 11, 2010 at 5:46 AM, Benjamin Peterson benja...@python.org wrote: Yep. Hopefully fixed in r79965. Sorry, my fault. Armin Looks fixed. Thanks. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] setrecursionlimit deprecation?
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 santag...@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 drsali...@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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] setrecursionlimit deprecation?
On Sat, Dec 11, 2010 at 19:16, Antonio Cuni anto.c...@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/ ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] setrecursionlimit deprecation?
2010/12/11 Paolo Giarrusso p.giarru...@gmail.com: On Sat, Dec 11, 2010 at 19:16, Antonio Cuni anto.c...@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 ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
