From tracker at bugs.pypy.org Wed Jun 1 10:07:06 2011 From: tracker at bugs.pypy.org (Gontran) Date: Wed, 01 Jun 2011 08:07:06 +0000 Subject: [pypy-issue] [issue734] bz2 seek rewinds unnecessarily In-Reply-To: <1306915626.9.0.456152379219.issue734@bugs.pypy.org> Message-ID: <1306915626.9.0.456152379219.issue734@bugs.pypy.org> New submission from Gontran : bz2 rewinds are costly, here is a fix to avoid them when seeking forward. This makes tarfile.getmembers linear instead of quadratic, and much faster on large files. pip installs suffered without this. I haven't been able to translate pypy, so I'd be grateful for some testing. Long-term, the cpython stdlib has a mostly-python implementation of bz2 that could be interesting to reuse: http://hg.python.org/cpython/file/tip/Lib/bz2.py ---------- assignedto: Gontran files: bz2_seek.patch messages: 2577 nosy: pypy-issue priority: bug release: 1.5.1 status: in-progress title: bz2 seek rewinds unnecessarily ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 11:13:36 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 01 Jun 2011 09:13:36 +0000 Subject: [pypy-issue] [issue734] bz2 seek rewinds unnecessarily In-Reply-To: <1306915626.9.0.456152379219.issue734@bugs.pypy.org> Message-ID: <1306919616.93.0.689418618356.issue734@bugs.pypy.org> Armin Rigo added the comment: Argh. Well spotted, thank you. Translation-wise, we need to initialize the 'read' variable with an r_longlong(0), to ensure that it is translated as a long long. Testing translation now. ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 15:18:34 2011 From: tracker at bugs.pypy.org (Vetoshkin Nikita) Date: Wed, 01 Jun 2011 13:18:34 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306934314.65.0.815186971099.issue729@bugs.pypy.org> Vetoshkin Nikita added the comment: [root at minefield tmp]# time /opt/pypy-1.6a-linux32/bin/pypy zipread.py 20096 real 0m1.507s user 0m0.423s sys 0m1.072s #### add bufsize=-1 to args of Popen [root at minefield tmp]# time /opt/pypy-1.6a-linux32/bin/pypy zipread.py 20096 real 0m0.063s user 0m0.031s sys 0m0.019s Here you go! =) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 15:28:31 2011 From: tracker at bugs.pypy.org (viktiglemma) Date: Wed, 01 Jun 2011 13:28:31 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306934911.29.0.722835273056.issue729@bugs.pypy.org> viktiglemma added the comment: OK, with the bufsize=-1 option to Popen I got the same speed, still slow though, but I think pypy might have been compiled the wrong way. I didn't do it myself, this is at work. Markig it as resolved! Thanks! ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 17:22:18 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 01 Jun 2011 15:22:18 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306941738.13.0.720864382751.issue729@bugs.pypy.org> Armin Rigo added the comment: Re-opening. I'm not completely sure I follow, but it seems that Popen created without bufsize=-1 are incredibly slower on PyPy; if so then it is definitely worth a bug report. ---------- nosy: +arigo status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 17:31:40 2011 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Wed, 01 Jun 2011 15:31:40 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306942300.76.0.620602123508.issue729@bugs.pypy.org> Amaury Forgeot d Arc added the comment: FWIW, CPython documentation says: http://docs.python.org/library/subprocess.html#using-the-subprocess-module If you experience performance issues, it is recommended that you try to enable buffering by setting bufsize to either -1 or a large enough positive value (such as 4096). ---------- nosy: +afa ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 17:51:38 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Wed, 01 Jun 2011 15:51:38 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306943498.06.0.910410875225.issue729@bugs.pypy.org> Da_Blitz added the comment: running the benchmark through strace for the zipfile case shows pypy doing alot of single byte reads and python doing reads of 10240 bytes. this would explain why manually forcing the buffer size speeds up the subprocess module taking a look into the subprocess module now to see what i can find ---------- nosy: +dablitz ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 18:53:39 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Wed, 01 Jun 2011 16:53:39 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306947219.45.0.278041108031.issue729@bugs.pypy.org> Da_Blitz added the comment: opening a file descriptor with a buffersize of "0" causes pypy to read a byte at a time whereas python will default to 8192 bytes on my system confirmed this behavior for both pipes and files subprocess sets bufsize to 0 in the __init__ of Popen, meaning if buffering is not specified as an arg the unwanted behavior happens ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 1 19:17:23 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Wed, 01 Jun 2011 17:17:23 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1306948643.4.0.729448285021.issue729@bugs.pypy.org> Da_Blitz added the comment: looking deeper and without looking at python's src, it appears to allocate a buffer for the file that is 10x the specified buffer size. setting the buffer appears to only limit the length of the returned item and not the length of the actual os level read call pypy differs in that it limits the read syscall to the specified buffer length and i assume just returns that instead of performing actual buffering could be diffrent, please flame me. this was just inferring from syscalls one quick way to see this is with strace -e read to dump the read syscalls and their args and look at the requested read size simple test program: #!/usr/bin/env python """Uncomment the print line to confirm the length of the returned data (without strace'ing) run with "strace -e read " where is either python or pypy and is a textfile from allfiles.zip or similar large (> 20kB) file length of the requested read is the third field """ import sys import os fd = os.open(sys.argv[1], os.RD_ONLY) f = os.open(fd, "r", 1000) for line in f: # print len(line) pass ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 2 12:32:13 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 02 Jun 2011 10:32:13 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1307010733.1.0.465672494721.issue729@bugs.pypy.org> Armin Rigo added the comment: Da_Blitz: ah, it's because CPython has special code for iterating over a file. It's not equivalent to calling f.readline() to get the next line. It's doing some read-ahead and caching on its own... ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 2 13:06:46 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Thu, 02 Jun 2011 11:06:46 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1307012806.59.0.906759256211.issue729@bugs.pypy.org> Da_Blitz added the comment: arigo: after changing to a while loop and using readline directly i can confirm you are correct. pypy and python have the same behavior when passing small values of bufsize to fdopen when using readline direct but not when using iteration i assume it would be best to match cpython's implementation for iteration as it is both a common idiom and using that pattern it is likely you will be reading the file in its entirety due to the nature of the idiom. this should hopefully get rid of some of those "fileio is slow in pypy" complaints ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 2 13:43:38 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 02 Jun 2011 11:43:38 +0000 Subject: [pypy-issue] [issue729] Pypy strangely slow when reading files In-Reply-To: <1306411206.33.0.468077278939.issue729@bugs.pypy.org> Message-ID: <1307015018.36.0.692175471927.issue729@bugs.pypy.org> Armin Rigo added the comment: I did that in the branch 'buffer-readline', but did not test it much so far. Due to the different levels we use, it needs a new layer in streamio.py that does minimal buffering for readline() even in otherwise non-buffered streams. As a side-effect, the app-level readline() is faster too, not just iteration (i.e. next()). It needs careful review, and also thinking if doing buffering when the app-level readline() is called is reasonable, or potentially breaks subtle cases. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 2 23:47:59 2011 From: tracker at bugs.pypy.org (Jacek Furmankiewicz) Date: Thu, 02 Jun 2011 21:47:59 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> New submission from Jacek Furmankiewicz : Installed latest Pypy 1.5 on Ubuntu 10.10: Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:38) [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2 Then installed 'pypy distribute_setup.py' to get easy_install. Next tried to install twisted 'pypy -m easy_install twisted' Gets to download it, but hangs at the very end and never completes. Verified this on one PC with Ubuntu 10.10 and on a laptop with 11.04 pypy -m easy_install twisted Searching for twisted Reading http://pypi.python.org/simple/twisted/ Reading http://twistedmatrix.com/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/ Reading http://www.twistedmatrix.com Reading http://twistedmatrix.com/products/download Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/ Reading http://twistedmatrix.com/projects/core/ Best match: Twisted 11.0.0 Downloading http://pypi.python.org/packages/source/T/Twisted/Twisted- 11.0.0.tar.bz2#md5=d7f94a1609a1b8f3b8c8d0146d4cfe54 Processing Twisted-11.0.0.tar.bz2 Just hangs on that last line, never completes ---------- messages: 2589 nosy: jfurmankiewicz, pypy-issue priority: bug status: unread title: Unable to install Twisted via easy_install ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 00:03:10 2011 From: tracker at bugs.pypy.org (Jacek Furmankiewicz) Date: Thu, 02 Jun 2011 22:03:10 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307052190.66.0.116247403893.issue735@bugs.pypy.org> Jacek Furmankiewicz added the comment: Messages msg2589 (view) Author: jfurmankiewicz Date: 2011-06-02.21:47:59 Installed latest Pypy 1.5 on Ubuntu 10.10: Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:38) [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2 Then installed 'pypy distribute_setup.py' to get easy_install. Next tried to install twisted 'pypy -m easy_install twisted' Gets to download it, but hangs at the very end and never completes. Verified this on one PC with Ubuntu 10.10 and on a laptop with 11.04 pypy -m easy_install twisted Searching for twisted Reading http://pypi.python.org/simple/twisted/ Reading http://twistedmatrix.com/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/ Reading http://www.twistedmatrix.com Reading http://twistedmatrix.com/products/download Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/ Reading http://twistedmatrix.com/projects/core/ Best match: Twisted 11.0.0 Downloading http://pypi.python.org/packages/source/T/Twisted/Twisted- 11.0.0.tar.bz2#md5=d7f94a1609a1b8f3b8c8d0146d4cfe54 Processing Twisted-11.0.0.tar.bz2 Just hangs on that last line, never completes. Checked via htop, was running a long time, very busy consuming 80/90% CPU...but never actually completing ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 15:07:37 2011 From: tracker at bugs.pypy.org (Jonas H.) Date: Fri, 03 Jun 2011 13:07:37 +0000 Subject: [pypy-issue] [issue736] 'finally' suite not invoked in generator function In-Reply-To: <1307106457.85.0.861166231957.issue736@bugs.pypy.org> Message-ID: <1307106457.85.0.861166231957.issue736@bugs.pypy.org> New submission from Jonas H. : Consider this code sample: def g(): try: yield 1 finally: print 'finally' g().next() CPython behaves differently from PyPy: $ python2.7 asd.py finally --- $ pypy asd.py --- The finally suite is executed only if the generator is exhausted in such way that StopIteration is raised. ---------- messages: 2591 nosy: jonash, pypy-issue priority: bug status: unread title: 'finally' suite not invoked in generator function ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 15:11:12 2011 From: tracker at bugs.pypy.org (Antonio Cuni) Date: Fri, 03 Jun 2011 13:11:12 +0000 Subject: [pypy-issue] [issue736] 'finally' suite not invoked in generator function In-Reply-To: <1307106457.85.0.861166231957.issue736@bugs.pypy.org> Message-ID: <1307106672.15.0.817022223892.issue736@bugs.pypy.org> Antonio Cuni added the comment: The finally is printed when the generator object is garbage collected. Since CPython has reference counting, the generator is collected immediately, while on PyPy is not. If you add "import gc; gc.collect()" at the end of the script, the "finally" is printed also on Pypy ---------- status: unread -> wontfix ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 15:22:09 2011 From: tracker at bugs.pypy.org (Jean-Paul Calderone) Date: Fri, 03 Jun 2011 13:22:09 +0000 Subject: [pypy-issue] [issue737] Crash on OS X, maybe in RPyThreadAfterFork In-Reply-To: <1307107329.87.0.9341809675.issue737@bugs.pypy.org> Message-ID: <1307107329.87.0.9341809675.issue737@bugs.pypy.org> New submission from Jean-Paul Calderone : I tried to deploy a BuildBot slave on PyPy, but found the processes it was trying to run would crash seemingly at random. I managed to reproduce the behavior with this short Twisted-using example: from twisted.python.log import err from twisted.internet import reactor from twisted.internet.utils import getProcessValue from twisted.internet.task import LoopingCall def main(): def launch(): print 'Launching' d = getProcessValue("/bin/bash", ["-c", "echo $((1+2))"]) def report(result): assert result == 0 return d.addCallback(report) call = LoopingCall(launch) call.start(0.01).addErrback(err) reactor.resolve("www.google.com") reactor.run() if __name__ == '__main__': main() The expected correct behavior is for it to run forever launching short-lived bash children. The observed behavior is that after 5 or 10 seconds the assertion fails, indicating that the child process exited with either a non-zero exit status or due to a signal. OS X generates a crash report at the same time indicating that the child process crashed before it had exec'd bash due to either SIGSEGV or SIGBUS (sometimes one, sometimes the other). ---------- messages: 2593 nosy: calderone, pypy-issue priority: bug release: 1.5 status: unread title: Crash on OS X, maybe in RPyThreadAfterFork ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 15:57:56 2011 From: tracker at bugs.pypy.org (Jacek Furmankiewicz) Date: Fri, 03 Jun 2011 13:57:56 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307109476.67.0.381442878506.issue735@bugs.pypy.org> Jacek Furmankiewicz added the comment: Tried again with latest nightly build (Jun 03). Does not hang any more, but fails to install: pypy -m easy_install twisted cyclone Searching for twisted Reading http://pypi.python.org/simple/twisted/ Reading http://twistedmatrix.com/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/ Reading http://www.twistedmatrix.com Reading http://twistedmatrix.com/products/download Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/ Reading http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/ Reading http://twistedmatrix.com/projects/core/ Best match: Twisted 11.0.0 Downloading http://pypi.python.org/packages/source/T/Twisted/Twisted- 11.0.0.tar.bz2#md5=d7f94a1609a1b8f3b8c8d0146d4cfe54 Processing Twisted-11.0.0.tar.bz2 Running Twisted-11.0.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install- P4fjcj/Twisted-11.0.0/egg-dist-tmp-NUcbfK twisted/test/raiser.c: In function ?__Pyx_ErrRestore?: twisted/test/raiser.c:672: warning: implicit declaration of function ?PyThreadState_GET? twisted/test/raiser.c:672: warning: initialization makes pointer from integer without a cast twisted/test/raiser.c:674: error: ?PyThreadState? has no member named ?curexc_type? twisted/test/raiser.c:675: error: ?PyThreadState? has no member named ?curexc_value? twisted/test/raiser.c:676: error: ?PyThreadState? has no member named ?curexc_traceback? twisted/test/raiser.c:677: error: ?PyThreadState? has no member named ?curexc_type? twisted/test/raiser.c:678: error: ?PyThreadState? has no member named ?curexc_value? twisted/test/raiser.c:679: error: ?PyThreadState? has no member named ?curexc_traceback? twisted/test/raiser.c: In function ?__Pyx_ErrFetch?: twisted/test/raiser.c:686: warning: initialization makes pointer from integer without a cast twisted/test/raiser.c:687: error: ?PyThreadState? has no member named ?curexc_type? twisted/test/raiser.c:688: error: ?PyThreadState? has no member named ?curexc_value? twisted/test/raiser.c:689: error: ?PyThreadState? has no member named ?curexc_traceback? twisted/test/raiser.c:691: error: ?PyThreadState? has no member named ?curexc_type? twisted/test/raiser.c:692: error: ?PyThreadState? has no member named ?curexc_value? twisted/test/raiser.c:693: error: ?PyThreadState? has no member named ?curexc_traceback? twisted/test/raiser.c: In function ?__Pyx_Raise?: twisted/test/raiser.c:707: warning: implicit declaration of function ?PyTraceBack_Check? twisted/test/raiser.c: In function ?__Pyx_FindPy2Metaclass?: twisted/test/raiser.c:819: error: ?PyClass_Type? undeclared (first use in this function) twisted/test/raiser.c:819: error: (Each undeclared identifier is reported only once twisted/test/raiser.c:819: error: for each function it appears in.) twisted/test/raiser.c: In function ?__Pyx_AddTraceback?: twisted/test/raiser.c:1312: warning: passing argument 1 of ?PyFrame_New? makes pointer from integer without a cast /home/jacekf/bin/pypy/include/pypy_decl.h:127: note: expected ?struct PyThreadState *? but argument is of type ?int? twisted/test/raiser.c: In function ?__Pyx_PyIndex_AsSsize_t?: twisted/test/raiser.c:1409: warning: implicit declaration of function ?PyNumber_Index? twisted/test/raiser.c:1409: warning: initialization makes pointer from integer without a cast twisted/test/raiser.c: In function ?__Pyx_PyInt_FromSize_t?: twisted/test/raiser.c:1426: warning: implicit declaration of function ?PyInt_FromSize_t? twisted/test/raiser.c:1426: warning: return makes pointer from integer without a cast error: Setup script exited with error: command 'cc' failed with exit status 1 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 16:06:21 2011 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Fri, 03 Jun 2011 14:06:21 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307109981.97.0.862576799149.issue735@bugs.pypy.org> Amaury Forgeot d Arc added the comment: It does not "hang" anymore probably thanks to a recent optimization in the bz2 module: https://bitbucket.org/pypy/pypy/changeset/1dc4d44ed272 Now, PyPy does not work with Pyrex modules. Is it possible to disable it? This one is a test module after all... ---------- nosy: +afa, calderone ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 16:19:42 2011 From: tracker at bugs.pypy.org (Jacek Furmankiewicz) Date: Fri, 03 Jun 2011 14:19:42 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307110782.95.0.931459639449.issue735@bugs.pypy.org> Jacek Furmankiewicz added the comment: how do you guys install twisted for your benchmarks using recent pypy builds? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 16:23:53 2011 From: tracker at bugs.pypy.org (Fijal) Date: Fri, 03 Jun 2011 14:23:53 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307111033.6.0.596261259826.issue735@bugs.pypy.org> Fijal added the comment: By setting PYTHONPATH ---------- nosy: +fijal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 19:08:27 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 03 Jun 2011 17:08:27 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307120907.72.0.977781435282.issue735@bugs.pypy.org> Armin Rigo added the comment: I think that fijal's extremely verbose answer means: we don't actually install it with easy_install on top of pypy, but instead we just point pypy to an existing installation of twisted, using PYTHONPATH. (This does not mean that this bug is irrelevant, though.) ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 19:20:41 2011 From: tracker at bugs.pypy.org (Jacek Furmankiewicz) Date: Fri, 03 Jun 2011 17:20:41 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307121641.39.0.116975060248.issue735@bugs.pypy.org> Jacek Furmankiewicz added the comment: Yes, I understood that :-) it's just that easy_install is probably the first thing a new user would trying to evaluate pypy vs cpython. We are evaluating adopting Twisted/Cyclone for some of our server-side work and wanted to compare it against some of our existing Java solutions. In case we found significant perf differences I wanted to know if I have the option of running the Cyclone app via pypy and reducing any raw code performance issues between Java and Python. It also makes it easier for deployment for our Ops team, which is an important consideration as well. Thank you for all your replies ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 3 23:37:07 2011 From: tracker at bugs.pypy.org (behackett) Date: Fri, 03 Jun 2011 21:37:07 +0000 Subject: [pypy-issue] [issue738] utcfromtimestamp handles time before the epoch differently in pypy and cpython In-Reply-To: <1307137027.04.0.840663501808.issue738@bugs.pypy.org> Message-ID: <1307137027.04.0.840663501808.issue738@bugs.pypy.org> New submission from behackett : pypy 1.5: >>>> datetime.datetime.utcfromtimestamp(-62135593139.0) datetime.datetime(1, 1, 1, 1, 1) cpython 2.7: >>> datetime.datetime.utcfromtimestamp(-62135593139.0) datetime.datetime(1, 1, 1, 1, 1, 1) ---------- messages: 2600 nosy: behackett, pypy-issue priority: bug status: unread title: utcfromtimestamp handles time before the epoch differently in pypy and cpython ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 4 09:12:21 2011 From: tracker at bugs.pypy.org (Fijal) Date: Sat, 04 Jun 2011 07:12:21 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307171541.78.0.192736487772.issue735@bugs.pypy.org> Fijal added the comment: In my opinion this is really twisted's bug. It should be able to install itself somehow without (optional) C extensions, like for example zope.interface does. On the other hand, convincing setup.py to do that is not particularly easy :-/ ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 6 15:12:04 2011 From: tracker at bugs.pypy.org (Jacek Furmankiewicz) Date: Mon, 06 Jun 2011 13:12:04 +0000 Subject: [pypy-issue] [issue735] Unable to install Twisted via easy_install In-Reply-To: <1307051279.56.0.530071542923.issue735@bugs.pypy.org> Message-ID: <1307365924.21.0.110528981762.issue735@bugs.pypy.org> Jacek Furmankiewicz added the comment: I can understand the challenge. Maybe a simple solution (more than acceptable for an end user like me) is creating a section on the main Twisted page with a list of common packages that work with Twisted but cannot be installed via pip or easy_install? We understand PyPy's limitations in regards to C extensions, so as long as it is clearly documented somewhere that for running Twisted we need to install it via a separate Python interpreter and then modify the PyPy PYTHONPATH I think that is an acceptable workaround. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 6 15:56:14 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Mon, 06 Jun 2011 13:56:14 +0000 Subject: [pypy-issue] [issue739] os.tmpname does not produce a RuntimeWarning In-Reply-To: <1307368574.32.0.161625132158.issue739@bugs.pypy.org> Message-ID: <1307368574.32.0.161625132158.issue739@bugs.pypy.org> New submission from Da_Blitz : when using os.tmpnam or os.tempnam on cpython a runtime warning is produced warning about the security risks of using the function. pypy-1.5 does not produce this warning. a patch to change this behavior in pypy to match cpython is attached also a thanks to Benjamin Peterson for pointing out that RuntimeWarning is a builtin ---------- messages: 2603 nosy: dablitz, pypy-issue priority: bug status: unread title: os.tmpname does not produce a RuntimeWarning ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 6 15:57:15 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Mon, 06 Jun 2011 13:57:15 +0000 Subject: [pypy-issue] [issue740] os.tmpname does not produce a RuntimeWarning In-Reply-To: <1307368635.52.0.0825586342258.issue740@bugs.pypy.org> Message-ID: <1307368635.52.0.0825586342258.issue740@bugs.pypy.org> New submission from Da_Blitz : when using os.tmpnam or os.tempnam on cpython a runtime warning is produced warning about the security risks of using the function. pypy-1.5 does not produce this warning. a patch to change this behavior in pypy to match cpython is attached also a thanks to Benjamin Peterson for pointing out that RuntimeWarning is a builtin ---------- files: patch.txt messages: 2604 nosy: dablitz, pypy-issue priority: bug status: unread title: os.tmpname does not produce a RuntimeWarning ________________________________________ PyPy bug tracker ________________________________________ -------------- next part -------------- diff -r b590cf6de419 pypy/module/posix/app_posix.py --- a/pypy/module/posix/app_posix.py Fri Apr 29 17:42:40 2011 +0200 +++ b/pypy/module/posix/app_posix.py Mon Jun 06 23:52:07 2011 +1000 @@ -107,6 +107,10 @@ def tmpnam(): """Return an absolute pathname of a file that did not exist at the time the call is made.""" + from warnings import warn + warn(RuntimeWarning("tmpnam is a potential security risk to your program")) + import tempfile return tempfile.mktemp() @@ -114,6 +118,10 @@ """Return an absolute pathname of a file that did not exist at the time the call is made. The directory and a prefix may be specified as strings; they may be omitted or None if not needed.""" + from warnings import warn + warn(RuntimeWarning("tempnam is a potential security risk to your program")) + import tempfile return tempfile.mktemp('', prefix or 'tmp', dir) From tracker at bugs.pypy.org Mon Jun 6 15:58:53 2011 From: tracker at bugs.pypy.org (Da_Blitz) Date: Mon, 06 Jun 2011 13:58:53 +0000 Subject: [pypy-issue] [issue739] os.tmpname does not produce a RuntimeWarning In-Reply-To: <1307368574.32.0.161625132158.issue739@bugs.pypy.org> Message-ID: <1307368733.77.0.558274079261.issue739@bugs.pypy.org> Da_Blitz added the comment: issue740 is the same ticket with more info ---------- status: unread -> duplicate ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 7 19:04:25 2011 From: tracker at bugs.pypy.org (Jose Antonio Martin H.) Date: Tue, 07 Jun 2011 17:04:25 +0000 Subject: [pypy-issue] [issue741] nightly build for windows In-Reply-To: <1307466265.62.0.905331161874.issue741@bugs.pypy.org> Message-ID: <1307466265.62.0.905331161874.issue741@bugs.pypy.org> New submission from Jose Antonio Martin H. : Please, I want an updated build for windows,there are many bugs that have been corrected since the last windows build. ---------- messages: 2606 nosy: jamartinh, pypy-issue priority: wish status: unread title: nightly build for windows ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 7 19:07:27 2011 From: tracker at bugs.pypy.org (Fijal) Date: Tue, 07 Jun 2011 17:07:27 +0000 Subject: [pypy-issue] [issue717] missing codecs In-Reply-To: <1304940943.84.0.976581533442.issue717@> Message-ID: <1307466447.4.0.676589596415.issue717@bugs.pypy.org> Fijal added the comment: Is this fixed by now? ---------- nosy: +fijal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 7 20:07:24 2011 From: tracker at bugs.pypy.org (Fijal) Date: Tue, 07 Jun 2011 18:07:24 +0000 Subject: [pypy-issue] [issue742] pyrepl bug with tuple.__ In-Reply-To: <1307470044.73.0.248410014433.issue742@bugs.pypy.org> Message-ID: <1307470044.73.0.248410014433.issue742@bugs.pypy.org> New submission from Fijal : Run pypy. Do as in title. My traceback: http://paste.pocoo.org/show/402282/ ---------- messages: 2608 nosy: fijal, pypy-issue priority: bug status: unread title: pyrepl bug with tuple.__ ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 7 22:09:24 2011 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Tue, 07 Jun 2011 20:09:24 +0000 Subject: [pypy-issue] [issue717] missing codecs In-Reply-To: <1304940943.84.0.976581533442.issue717@> Message-ID: <1307477364.14.0.882897816147.issue717@bugs.pypy.org> Alex Gaynor added the comment: Yes, we support all of these, not incremental encode/decode but that's even less used, and I might work on it. File a seperate ticket for that if you need it. ---------- nosy: +agaynor ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 8 12:28:28 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 08 Jun 2011 10:28:28 +0000 Subject: [pypy-issue] [issue742] pyrepl bug with tuple.__ In-Reply-To: <1307470044.73.0.248410014433.issue742@bugs.pypy.org> Message-ID: <1307528908.6.0.416330978065.issue742@bugs.pypy.org> Armin Rigo added the comment: You are running a PyPy with extra stuff installed, because my own PyPy does not print "Welcome to rlcompleter2 0.96" when you start. I cannot reproduce it on a plain PyPy. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 8 12:30:08 2011 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Wed, 08 Jun 2011 10:30:08 +0000 Subject: [pypy-issue] [issue742] pyrepl bug with tuple.__ In-Reply-To: <1307470044.73.0.248410014433.issue742@bugs.pypy.org> Message-ID: <1307529008.75.0.548597641999.issue742@bugs.pypy.org> Alex Gaynor added the comment: I think fijal is saying we have a bug in pyrepl that causes it. I don't have issues with ipython ATM so it's something obscure of course. ---------- nosy: +agaynor ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 8 12:56:05 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 08 Jun 2011 10:56:05 +0000 Subject: [pypy-issue] [issue742] pyrepl bug with tuple.__ In-Reply-To: <1307470044.73.0.248410014433.issue742@bugs.pypy.org> Message-ID: <1307530565.58.0.785681325432.issue742@bugs.pypy.org> Armin Rigo added the comment: Fijal, please be more precise :-) Explaining how we can reproduce the bug from a plain PyPy would be a really excellent start. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 9 07:30:19 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 09 Jun 2011 05:30:19 +0000 Subject: [pypy-issue] [issue740] os.tmpname does not produce a RuntimeWarning In-Reply-To: <1307368635.52.0.0825586342258.issue740@bugs.pypy.org> Message-ID: <1307597419.02.0.953359402459.issue740@bugs.pypy.org> Armin Rigo added the comment: Thanks. 7b32ed6e8374 ---------- nosy: +arigo status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 9 16:44:06 2011 From: tracker at bugs.pypy.org (Thomas Heller) Date: Thu, 09 Jun 2011 14:44:06 +0000 Subject: [pypy-issue] [issue743] Patch: comtypes works with these changes In-Reply-To: <1307630646.08.0.209251613631.issue743@bugs.pypy.org> Message-ID: <1307630646.08.0.209251613631.issue743@bugs.pypy.org> New submission from Thomas Heller : This patch is against the 1.5 released windows version. ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 10 00:05:52 2011 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Thu, 09 Jun 2011 22:05:52 +0000 Subject: [pypy-issue] [issue744] try/finally in not fully consumed generator In-Reply-To: <1307657152.57.0.0663906266149.issue744@bugs.pypy.org> Message-ID: <1307657152.57.0.0663906266149.issue744@bugs.pypy.org> New submission from Alex Gaynor : When you write a generator with a try/finally and it will not be fully consumed (e.g. https://github.com/mitsuhiko/django-template- compilation/commit/7900c4d98f2021ec8e15c681a2892f54b347eb38) this is bad on pypy, finally is only called on GC. We need a clear explanation on the website of how people should fix this in their code. ---------- messages: 2615 nosy: agaynor, pypy-issue priority: wish status: unread title: try/finally in not fully consumed generator ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 10 08:52:56 2011 From: tracker at bugs.pypy.org (Fijal) Date: Fri, 10 Jun 2011 06:52:56 +0000 Subject: [pypy-issue] [issue744] try/finally in not fully consumed generator In-Reply-To: <1307657152.57.0.0663906266149.issue744@bugs.pypy.org> Message-ID: <1307688776.24.0.255139462207.issue744@bugs.pypy.org> Fijal added the comment: Already documented: http://pypy.readthedocs.org/en/latest/cpython_differences.html#differences- related-to-garbage-collection-strategies ---------- nosy: +fijal status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 10 09:53:49 2011 From: tracker at bugs.pypy.org (Jonas H.) Date: Fri, 10 Jun 2011 07:53:49 +0000 Subject: [pypy-issue] [issue745] datetime microseconds rounded differently in CPython In-Reply-To: <1307692429.43.0.0957017155516.issue745@bugs.pypy.org> Message-ID: <1307692429.43.0.0957017155516.issue745@bugs.pypy.org> New submission from Jonas H. : from https://jira.mongodb.org/browse/PYTHON-254? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel&focusedCommentId=36896#comment-36896 cpython: >>> datetime.datetime.fromtimestamp(1293843661.191) datetime.datetime(2010, 12, 31, 20, 1, 1, 191000) pypy: >>>> datetime.datetime.fromtimestamp(1293843661.191) datetime.datetime(2010, 12, 31, 20, 1, 1, 190999) ---------- messages: 2617 nosy: jonash, pypy-issue priority: bug status: unread title: datetime microseconds rounded differently in CPython ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 10 10:05:00 2011 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Fri, 10 Jun 2011 08:05:00 +0000 Subject: [pypy-issue] [issue744] try/finally in not fully consumed generator In-Reply-To: <1307657152.57.0.0663906266149.issue744@bugs.pypy.org> Message-ID: <1307693100.7.0.351084806589.issue744@bugs.pypy.org> Alex Gaynor added the comment: It's actually a little more subtle than that, if the generator isn't fully consumed because it exits via an exception stuff still works. Anyway mostly I was looking for documentation on how to fix code, which is still not obvious IMO. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 10 10:12:20 2011 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Fri, 10 Jun 2011 08:12:20 +0000 Subject: [pypy-issue] [issue745] datetime microseconds rounded differently in CPython In-Reply-To: <1307692429.43.0.0957017155516.issue745@bugs.pypy.org> Message-ID: <1307693540.99.0.140501793529.issue745@bugs.pypy.org> Alex Gaynor added the comment: For funsies I downloaded the datetime.py from CPython 3.2, after changing a few things (making all classes newstyle) it runs this code correctly. Perhaps we should replace our version with the upstream one? ---------- nosy: +agaynor status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 11 09:03:22 2011 From: tracker at bugs.pypy.org (Nirbheek Chauhan) Date: Sat, 11 Jun 2011 07:03:22 +0000 Subject: [pypy-issue] [issue747] fcntl.lockf() is broken with (fcntl.LOCK_EX | fcntl.LOCK_NB) In-Reply-To: <1307775802.38.0.717100903574.issue747@bugs.pypy.org> Message-ID: <1307775802.38.0.717100903574.issue747@bugs.pypy.org> New submission from Nirbheek Chauhan : While trying to lock a file with a pre-existing lock on it, lockf() doesn't raise EACCESS, and just silently returns instead. This behaviour is both wrong, and inconsistent with PyPy's flock() behaviour, and CPython's lockf() and flock() behaviour. The script attached should demonstrate the problem. Run it under CPython, and it'll exit fine, execute with PyPy, and it fails. Replace fcntl.lockf with fcntl.flock and it works fine again. ---------- files: test_lock_nonblock.py messages: 2621 nosy: nirbheek, pypy-issue priority: bug release: 1.5 status: unread title: fcntl.lockf() is broken with (fcntl.LOCK_EX | fcntl.LOCK_NB) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 11 21:39:55 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 11 Jun 2011 19:39:55 +0000 Subject: [pypy-issue] [issue745] datetime microseconds rounded differently in CPython In-Reply-To: <1307692429.43.0.0957017155516.issue745@bugs.pypy.org> Message-ID: <1307821195.83.0.391607674378.issue745@bugs.pypy.org> Armin Rigo added the comment: I just went ahead and fixed this particular issue in c5617952be56. Alex: this might be a good idea, but I don't feel like making sure there are really no differences between 3.2 and 2.7... :-/ ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 12 12:26:27 2011 From: tracker at bugs.pypy.org (squiddy) Date: Sun, 12 Jun 2011 10:26:27 +0000 Subject: [pypy-issue] [issue748] Failure in sqlite3 fetchall In-Reply-To: <1307874387.72.0.702167811825.issue748@bugs.pypy.org> Message-ID: <1307874387.72.0.702167811825.issue748@bugs.pypy.org> New submission from squiddy : sqlite3 fails with "AttributeError: 'Statement' object has no attribute 'item'" when using fetchall. Find attached a simple test. ---------- files: sqlite_fetchall_failure.py messages: 2623 nosy: pypy-issue, squiddy priority: bug status: unread title: Failure in sqlite3 fetchall ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 12 15:59:18 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 12 Jun 2011 13:59:18 +0000 Subject: [pypy-issue] [issue749] "-Ojit no-allworkingmodules" fails In-Reply-To: <1307887158.99.0.818878124685.issue749@bugs.pypy.org> Message-ID: <1307887158.99.0.818878124685.issue749@bugs.pypy.org> New submission from Armin Rigo : ./translate.py -Ojit targetpypystandalone.py --no-allworkingmodules ...fails at compilation-time because "ffi_type" is not defined. It is used in a few functions coming from metainterp/optimizeopt/fficall.py, but the #include is not there (correctly). I suppose we need to remove OptFfiCall from the list ALL_OPTS depending on the config. ---------- messages: 2624 nosy: arigo, pypy-issue priority: bug status: unread title: "-Ojit no-allworkingmodules" fails ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 13 16:03:23 2011 From: tracker at bugs.pypy.org (ayanamist) Date: Mon, 13 Jun 2011 14:03:23 +0000 Subject: [pypy-issue] [issue750] sqlite3.connect dont accept argument "check_same_thread" In-Reply-To: <1307973803.42.0.628691373824.issue750@bugs.pypy.org> Message-ID: <1307973803.42.0.628691373824.issue750@bugs.pypy.org> New submission from ayanamist : in CPython 2.7.1, sqlite3.connect can accept an undocumented argument "check_same_thread". can pypy support it? ---------- messages: 2625 nosy: ayanamist, pypy-issue priority: bug status: unread title: sqlite3.connect dont accept argument "check_same_thread" ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 13 16:58:20 2011 From: tracker at bugs.pypy.org (Irmen de Jong) Date: Mon, 13 Jun 2011 14:58:20 +0000 Subject: [pypy-issue] [issue751] Pypy doesn't allow some unicode keyword arguments In-Reply-To: <1307977100.79.0.446667423654.issue751@bugs.pypy.org> Message-ID: <1307977100.79.0.446667423654.issue751@bugs.pypy.org> New submission from Irmen de Jong : There is a small problem with Pypy and unicode keyword arguments: >>>> def f(**kwargs): .... print kwargs .... >>>> f(**{'foo':42}) {'foo': 42} >>>> f(**{u'foo':42}) {'foo': 42} >>>> f(**{u'\u20ac':42}) Traceback (most recent call last): File "", line 1, in TypeError: keyword cannot be encoded to ascii u'foo' works fine, however u'\u20ac' (the Euro-currency sign) fails. This works fine on CPython 2.6.5 and newer. ---------- messages: 2626 nosy: irmen, pypy-issue priority: bug status: unread title: Pypy doesn't allow some unicode keyword arguments ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 13 20:37:30 2011 From: tracker at bugs.pypy.org (Antonio Cuni) Date: Mon, 13 Jun 2011 18:37:30 +0000 Subject: [pypy-issue] [issue749] "-Ojit no-allworkingmodules" fails In-Reply-To: <1307887158.99.0.818878124685.issue749@bugs.pypy.org> Message-ID: <1307990250.57.0.192904566907.issue749@bugs.pypy.org> Antonio Cuni added the comment: fixed by 8d6cdc44d544 ---------- status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 14 01:33:08 2011 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Mon, 13 Jun 2011 23:33:08 +0000 Subject: [pypy-issue] [issue750] sqlite3.connect dont accept argument "check_same_thread" In-Reply-To: <1307973803.42.0.628691373824.issue750@bugs.pypy.org> Message-ID: <1308007988.29.0.777471590264.issue750@bugs.pypy.org> Amaury Forgeot d Arc added the comment: Done in 0a6cc0d7268e, thanks for the report! ---------- nosy: +afa status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 14 03:18:24 2011 From: tracker at bugs.pypy.org (Benjamin Peterson) Date: Tue, 14 Jun 2011 01:18:24 +0000 Subject: [pypy-issue] [issue751] Pypy doesn't allow some unicode keyword arguments In-Reply-To: <1307977100.79.0.446667423654.issue751@bugs.pypy.org> Message-ID: <1308014304.1.0.978206334052.issue751@bugs.pypy.org> Benjamin Peterson added the comment: 2978e535782d ---------- nosy: +benjamin status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 14 16:33:55 2011 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Tue, 14 Jun 2011 14:33:55 +0000 Subject: [pypy-issue] [issue748] Failure in sqlite3 fetchall In-Reply-To: <1307874387.72.0.702167811825.issue748@bugs.pypy.org> Message-ID: <1308062035.21.0.922126501358.issue748@bugs.pypy.org> Amaury Forgeot d Arc added the comment: Of course, normally you don't need to fetch data after a "create table"! The dbapi doc says: "An Error (or subclass) exception is raised if the previous call to .execute*() did not produce any result set". But if CPython says so, PyPy should follow... ---------- nosy: +afa status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 14 17:11:42 2011 From: tracker at bugs.pypy.org (squiddy) Date: Tue, 14 Jun 2011 15:11:42 +0000 Subject: [pypy-issue] [issue748] Failure in sqlite3 fetchall In-Reply-To: <1307874387.72.0.702167811825.issue748@bugs.pypy.org> Message-ID: <1308064302.45.0.528514361323.issue748@bugs.pypy.org> squiddy added the comment: I totally agree. But I've tried to get a different project running with PyPy, and they have a thin wrapper around sqlite3, that does some stuff with the results, no matter what query was executed. I'll probably fix it there, but thought I should mention it anyway. Even if PyPy was not to mimic CPython, it probably should throw a prettier exception. :-) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 14 22:29:52 2011 From: tracker at bugs.pypy.org (Todd Letsche) Date: Tue, 14 Jun 2011 20:29:52 +0000 Subject: [pypy-issue] [issue752] Support for dtypes in numpy-exp branches' micronumpy In-Reply-To: <1308083392.77.0.675236112429.issue752@bugs.pypy.org> Message-ID: <1308083392.77.0.675236112429.issue752@bugs.pypy.org> New submission from Todd Letsche : Hi, I ported the older micronumpy dtype stuff to the numpy-exp branch. At the moment, all tests pass (and pypy is buildable) except for a problem with the fake space in test_zjit.py. A diff against 44238:dd3bcd84b145 is attached. Posting here as suggest on IRC (and because I don't have commit privs). ---------- files: micronumpy.patch messages: 2632 nosy: letsche, pypy-issue priority: feature status: unread title: Support for dtypes in numpy-exp branches' micronumpy ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 15 19:46:26 2011 From: tracker at bugs.pypy.org (Stephen Bell) Date: Wed, 15 Jun 2011 17:46:26 +0000 Subject: [pypy-issue] [issue753] pypy python interpreter MemoryError/crash In-Reply-To: <1308159986.79.0.719588073362.issue753@bugs.pypy.org> Message-ID: <1308159986.79.0.719588073362.issue753@bugs.pypy.org> New submission from Stephen Bell : I'm not sure if this is the correct place to ask this, so please forgive me if this should be somewhere else. I'm trying out pypy on my Windows XP 32 bit machine but when I run a simple benchmark script, PyPy keeps crashing on me. Specifically: * the pypy process balloons up to ~2GB in size * I see the following traceback: RPython traceback: File "implement.c", line 839, in entry_point File "implement_5.c", line 5243, in funccall__star_1 File "implement_5.c", line 5272, in funccall__star_1 File "implement_5.c", line 7266, in MiniMarkGC_collect_and_reserve File "implement_5.c", line 3243, in MiniMarkGC_minor_collection File "implement_6.c", line 36662, in MiniMarkGC_collect_oldrefs_to_nursery File "implement_7.c", line 43701, in trace___trace_drag_out File "implement_7.c", line 43222, in MiniMarkGC__trace_drag_out File "implement_6.c", line 43542, in ArenaCollection_malloc File "implement_7.c", line 54691, in ArenaCollection_allocate_new_page File "implement_13.c", line 43205, in ArenaCollection_allocate_new_arena Fatal RPython error: MemoryError * My Visual Studio Just-In-Time Debugger appears telling me that there was an unhandled exception in pypy.exe, and asks me if I want to debug it This script I'm running is attached (it is a slightly modified version of what is found here: http://txzone.net/2010/04/python-is-x-is-better-than-y-round-1- deque- vs-list/ ). If I reduce the number of iterations to 1000, the script works fine. Should I be doing something to tell pypy to tweak the JIT compiler for the larger number of iterations? I installed using the pypy1.5 windows installer. My questions are: * can anyone help me out with this error? * In trying to trouble shoot the problem, I noticed several --jit command line options, but can't find documentation for these anywhere. How do I use these? ---------- messages: 2633 nosy: bahejl, pypy-issue priority: bug status: unread title: pypy python interpreter MemoryError/crash ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 15 23:36:55 2011 From: tracker at bugs.pypy.org (Vincent Legoll) Date: Wed, 15 Jun 2011 21:36:55 +0000 Subject: [pypy-issue] [issue653] fix for test_absolute_import_without_future In-Reply-To: <1298997204.59.0.724697529998.issue653@> Message-ID: <1308173815.16.0.571471753985.issue653@bugs.pypy.org> Vincent Legoll added the comment: looks fixed ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 16 03:41:35 2011 From: tracker at bugs.pypy.org (Fabio Zadrozny) Date: Thu, 16 Jun 2011 01:41:35 +0000 Subject: [pypy-issue] [issue754] ImportError expected but KeyError given instead on import fail. In-Reply-To: <1308188495.68.0.949527285764.issue754@bugs.pypy.org> Message-ID: <1308188495.68.0.949527285764.issue754@bugs.pypy.org> New submission from Fabio Zadrozny : Happens on pypy-1.5.0a0-win32. To reproduce, create 2 modules: mod1: import mod2 <-- ImportError expected here (KeyError raised instead) mod2: import sys del sys.modules['mod2'] #Remove itself from the modules ---------- messages: 2635 nosy: fabioz, pypy-issue priority: bug release: 1.5 status: unread title: ImportError expected but KeyError given instead on import fail. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 16 09:09:04 2011 From: tracker at bugs.pypy.org (Fijal) Date: Thu, 16 Jun 2011 07:09:04 +0000 Subject: [pypy-issue] [issue653] fix for test_absolute_import_without_future In-Reply-To: <1298997204.59.0.724697529998.issue653@> Message-ID: <1308208144.64.0.758481831452.issue653@bugs.pypy.org> Fijal added the comment: Closing then ---------- nosy: +fijal status: testing -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 16 09:48:59 2011 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 16 Jun 2011 07:48:59 +0000 Subject: [pypy-issue] [issue753] pypy python interpreter MemoryError/crash In-Reply-To: <1308159986.79.0.719588073362.issue753@bugs.pypy.org> Message-ID: <1308210539.95.0.301674250558.issue753@bugs.pypy.org> Armin Rigo added the comment: I see no attachment, can you try again? Moreover, how much memory does running exactly the same script uses on top of CPython? If the answer is more than 1.5GB, then yes, it's reasonable that on top of PyPy it goes up to 2GB, and it's the maximum on Win32. (I agree that it should try to crash more cleanly than the fatal RPython traceback; even if it's hard to guarantee in all cases, we should really try.) ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 16 10:21:36 2011 From: tracker at bugs.pypy.org (Radu Voicilas) Date: Thu, 16 Jun 2011 08:21:36 +0000 Subject: [pypy-issue] [issue747] fcntl.lockf() is broken with (fcntl.LOCK_EX | fcntl.LOCK_NB) In-Reply-To: <1307775802.38.0.717100903574.issue747@bugs.pypy.org> Message-ID: <1308212496.14.0.713918570432.issue747@bugs.pypy.org> Radu Voicilas added the comment: I can confirm that this is happening. I tried to see why it is happening, but I didn't get to any resolution. As far as I can tell, this seems to be happening with fcntl.flock() as well, when the platform running has no C flock. ---------- nosy: +rvoicilas status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 16 14:41:55 2011 From: tracker at bugs.pypy.org (Stephen Bell) Date: Thu, 16 Jun 2011 12:41:55 +0000 Subject: [pypy-issue] [issue753] pypy python interpreter MemoryError/crash In-Reply-To: <1308159986.79.0.719588073362.issue753@bugs.pypy.org> Message-ID: <1308228115.44.0.605051375747.issue753@bugs.pypy.org> Stephen Bell added the comment: Sorry, I've attached the file now. For some stupid reason, I never thought to test on CPython after I saw this problem. Running the script on CPython, the script balloons up to the same size (~2GB) and also crashes. Looks like it's my problem ;) Sorry for the confusion ---------- status: chatting -> wontfix ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 17 09:41:43 2011 From: tracker at bugs.pypy.org (Fijal) Date: Fri, 17 Jun 2011 07:41:43 +0000 Subject: [pypy-issue] [issue752] Support for dtypes in numpy-exp branches' micronumpy In-Reply-To: <1308083392.77.0.675236112429.issue752@bugs.pypy.org> Message-ID: <1308296503.3.0.276984890866.issue752@bugs.pypy.org> Fijal added the comment: Hi. Thanks for porting this stuff. Unfortunately the patch as it is has a very adverse effect on performance - and this would likely be caught by test_zjit, even if fake space was not a problem. Essentially passing around wrapped types in things like initializers should be avoided, because it creates a massive performance hit. I suggest starting from scratch (or some heavy refactoring). Feel free to ask questions on IRC. Cheers, fijal ---------- nosy: +fijal status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 17 11:15:47 2011 From: tracker at bugs.pypy.org (Radu Voicilas) Date: Fri, 17 Jun 2011 09:15:47 +0000 Subject: [pypy-issue] [issue747] fcntl.lockf() is broken with (fcntl.LOCK_EX | fcntl.LOCK_NB) In-Reply-To: <1307775802.38.0.717100903574.issue747@bugs.pypy.org> Message-ID: <1308302147.81.0.239284891166.issue747@bugs.pypy.org> Radu Voicilas added the comment: I've made some changes to the interp_fcntl.py that would help nail this problem down. You can pull the changes from https://bitbucket.org/rvoicilas/pypy (especially commit 6f93f08b59a6). ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 17 14:39:39 2011 From: tracker at bugs.pypy.org (Attila Nagy) Date: Fri, 17 Jun 2011 12:39:39 +0000 Subject: [pypy-issue] [issue755] pypy trunk fails to build/run on FreeBSD In-Reply-To: <1308314379.97.0.0230222296775.issue755@bugs.pypy.org> Message-ID: <1308314379.97.0.0230222296775.issue755@bugs.pypy.org> New submission from Attila Nagy : I'm trying to build pypy trunk (changeset: 44937:17cc5ab72684) on the following FreeBSD: FreeBSD buildervm 8.2-STABLE FreeBSD 8.2-STABLE #2: Sat May 21 22:05:26 CEST 2011 root at buildervm:/data/usr/obj/data/usr/src/sys/BOOTCLNT amd64 gcc is the standard system compiler: Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] python is 64 bit 2.7.1 Compiling with python translate.py -Ojit fails with the following errors at the end of the build process (skip to ---8<---, it marks the end of the log): [c] 599328 nodes [ array: 85726 framework rtti: 1879 func: 22277 group: 1 struct: 489445 ] [c:database] Completed [translation:info] database for generating C source was created [translation:info] Generating c source... [c:writing] structdef.h [c:writing] forwarddecl.h [c:writing] structimpl.c [c:writing] nonfuncnodes.c [c:writing] nonfuncnodes_1.c [c:writing] nonfuncnodes_2.c [c:writing] nonfuncnodes_3.c [c:writing] nonfuncnodes_4.c [c:writing] nonfuncnodes_5.c [c:writing] nonfuncnodes_6.c [platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -DPy_BUILD_CORE -I/data/pypy/pypy/module/cpyext/include -I/tmp/usession-unknown-8 -I/usr/local/include /tmp/usession-unknown-8/platcheck_45.c -o /tmp/usession-unknown-8/platcheck_45.o [platform:execute] gcc /tmp/usession-unknown-8/platcheck_45.o -L/usr/local/lib -pthread -o /tmp/usession-unknown-8/platcheck_45 [c:writing] nonfuncnodes_7.c [c:writing] nonfuncnodes_8.c [c:writing] nonfuncnodes_9.c [c:writing] nonfuncnodes_10.c [c:writing] nonfuncnodes_11.c [platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -I/usr/local/include -I/usr/local/include /tmp/usession-unknown-8/platcheck_46.c -o /tmp/usession-unknown-8/platcheck_46.o [platform:execute] gcc /tmp/usession-unknown-8/platcheck_46.o -L/usr/local/lib -L/usr/local/lib -pthread -lffi -o /tmp/usession-unknown-8/platcheck_46 [c:writing] nonfuncnodes_12.c [c:writing] nonfuncnodes_13.c [c:writing] nonfuncnodes_14.c [c:writing] nonfuncnodes_15.c [c:writing] nonfuncnodes_16.c [c:writing] nonfuncnodes_17.c [c:writing] nonfuncnodes_18.c [c:writing] nonfuncnodes_19.c [c:writing] nonfuncnodes_20.c [c:writing] nonfuncnodes_21.c [c:writing] nonfuncnodes_22.c [c:writing] nonfuncnodes_23.c [c:writing] nonfuncnodes_24.c [c:writing] nonfuncnodes_25.c [c:writing] nonfuncnodes_26.c [c:writing] nonfuncnodes_27.c [c:writing] nonfuncnodes_28.c [c:writing] nonfuncnodes_29.c [platform:execute] gcc -c -O3 -pthread -fomit-frame-pointer -I/usr/local/include /tmp/usession-unknown-8/platcheck_47.c -o /tmp/usession-unknown-8/platcheck_47.o [platform:execute] gcc /tmp/usession-unknown-8/platcheck_47.o -L/usr/local/lib -pthread -o /tmp/usession-unknown-8/platcheck_47 [c:writing] nonfuncnodes_30.c [c:writing] nonfuncnodes_31.c [c:writing] nonfuncnodes_32.c [c:writing] nonfuncnodes_33.c [c:writing] nonfuncnodes_34.c [c:writing] nonfuncnodes_35.c [c:writing] nonfuncnodes_36.c [c:writing] nonfuncnodes_37.c [c:writing] nonfuncnodes_38.c [c:writing] nonfuncnodes_39.c [c:writing] nonfuncnodes_40.c [c:writing] nonfuncnodes_41.c [c:writing] nonfuncnodes_42.c [c:writing] nonfuncnodes_43.c [c:writing] nonfuncnodes_44.c [c:writing] nonfuncnodes_45.c [c:writing] nonfuncnodes_46.c [c:writing] implement.c [backendopt:WARNING] constant-folding v0 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v1 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v3 = gc_gettypeptr_group(v4, (<* >), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), (()): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v14 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v17 = gc_gettypeptr_group(v18, (<* >), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), (()): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v19 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v22 = gc_gettypeptr_group(v23, (<* >), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), (()): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v31 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v33 = gc_gettypeptr_group(v34, (<* >), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), (()): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v35 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v38 = gc_gettypeptr_group(v39, (<* >), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), (()): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v55 = cast_pointer((<* struct object { typ...=... }>)): [backendopt:WARNING] RuntimeError: widening <* GcStruct object { typeptr }> inside instead of [backendopt:WARNING] constant-folding v58 = gc_gettypeptr_group(v59, (<* >), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((>), ( 1>), ((