From qbproger at gmail.com Thu Apr 1 05:19:01 2010 From: qbproger at gmail.com (Joe) Date: Wed, 31 Mar 2010 23:19:01 -0400 Subject: [pypy-dev] Some Python Benchmarks Message-ID: Saw this on reddit, thought it might interest you: http://www.ripton.net/blog/?p=51 Joe From santagada at gmail.com Thu Apr 1 08:44:54 2010 From: santagada at gmail.com (Leonardo Santagada) Date: Thu, 1 Apr 2010 03:44:54 -0300 Subject: [pypy-dev] Some Python Benchmarks In-Reply-To: References: Message-ID: Very interesting, the second example, euler135.py I have no idea why it is slower in pypy. On Apr 1, 2010, at 12:19 AM, Joe wrote: > Saw this on reddit, thought it might interest you: > http://www.ripton.net/blog/?p=51 > > Joe > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev -- Leonardo Santagada santagada at gmail.com From historium at gmail.com Fri Apr 2 21:10:58 2010 From: historium at gmail.com (Tamreen Khan) Date: Fri, 2 Apr 2010 15:10:58 -0400 Subject: [pypy-dev] GSoC Project idea Message-ID: Hi everyone, my name is Tamreen Khan (Scriptor on IRC) and I'm interested in working on PyPy for Google's Summer of Code. I have experience in Python, basic knowledge of assembly, and I'm interested in language implementation. Otherwise, I'll have to learn much of the rest myself. I'm currently working on an abstract register allocator (doesn't deal with actual CPU registers) that fijal asked me to write before I apply. However, I would like to start getting figuring out what I would do for my actual summer project. I understand that the JIT is a priority spot for development right now. Also, on the ideas page, I saw that integrating Stackless better is a possible project and I'd like to work on that, although I think someone on IRC was already doing that.Besides what's on the ideas page, does anyone have any suggestions for areas in PyPy that I could pick to create my own idea if needed? -- Thanks, Tamreen Khan From fijall at gmail.com Thu Apr 8 02:30:21 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 7 Apr 2010 18:30:21 -0600 Subject: [pypy-dev] Student application deadline on friday for SoC Message-ID: Hello. All students should submit their application ASAP. There is no point in waiting for friday IMO, especially that you can change it afterwards. Cheers, fijal From jcreigh at gmail.com Thu Apr 8 06:07:52 2010 From: jcreigh at gmail.com (Jason Creighton) Date: Wed, 07 Apr 2010 22:07:52 -0600 Subject: [pypy-dev] Student application deadline on friday for SoC In-Reply-To: References: Message-ID: <4BBD5698.2070205@gmail.com> Maciej Fijalkowski wrote: > Hello. > > All students should submit their application ASAP. There is no point > in waiting for friday IMO, especially that you can change it > afterwards. Just FYI so there aren't any unpleasant surprises for someone, my understanding is that you *can't* edit it afterwards. A tidbit from the resident bot in the #gsoc channel: "edit" is You can submit your application early and edit it up until the deadline (April 9). Once the deadline passes, you cannot edit it. Instead, leave comments. But in any case, students should definitely submit their applications right away. Jason From micktwomey at gmail.com Thu Apr 8 18:14:12 2010 From: micktwomey at gmail.com (Michael Twomey) Date: Thu, 8 Apr 2010 17:14:12 +0100 Subject: [pypy-dev] Python Ireland Conference In-Reply-To: <20100325120932.GC10602@code0.codespeak.net> References: <50a522ca1003190709k5f26aa67s31f0502c6791dd70@mail.gmail.com> <20100325120932.GC10602@code0.codespeak.net> Message-ID: Hi, Apologies for the late response, I picked a good time to go on holidays :) We don't have a fixed deadline defined at the moment, so I'd say you'd get away with the end of June before making a firm decision. Hope you can make it! cheers, Michael On Thu, Mar 25, 2010 at 12:09, Armin Rigo wrote: > Hi Michael, > > On Fri, Mar 19, 2010 at 02:09:27PM +0000, Michael Twomey wrote: >> I'm one of the folks involved in organising the first python Ireland >> conference, to be held in Dublin on Saturday 17th of July (with >> sprints on Sunday). >> >> We'd love it if someone from PyPy could make it over to give a talk. >> The audience is your typical spread of python developers, many of whom >> haven't been exposed to PyPy and what it can do. An introduction to >> PyPy and the benefits it offers would go down very well. > > Thanks for the invitation. ?I think that the general "no-answer-coming- > so-far" situation means that we don't really know. ?I would be > interested in coming myself, but I cannot give any more precise answer > right now. ?Is there a deadline for you to get a more definite yes/no? > > > A bientot, > > Armin. > From historium at gmail.com Fri Apr 9 03:50:44 2010 From: historium at gmail.com (Tamreen Khan) Date: Thu, 8 Apr 2010 21:50:44 -0400 Subject: [pypy-dev] Student application deadline on friday for SoC In-Reply-To: References: Message-ID: Hi, after thinking this through I've decided that I won't apply for Summer of Code, mainly because I don't think I'll be able to make the full-time commitment needed. I would still like to continue to work on the project, however. On Wed, Apr 7, 2010 at 8:30 PM, Maciej Fijalkowski wrote: > Hello. > > All students should submit their application ASAP. There is no point > in waiting for friday IMO, especially that you can change it > afterwards. > > Cheers, > fijal > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- Thanks, Tamreen Khan From ademan555 at gmail.com Fri Apr 9 06:14:18 2010 From: ademan555 at gmail.com (Dan Roberts) Date: Thu, 8 Apr 2010 21:14:18 -0700 Subject: [pypy-dev] Student application deadline on friday for SoC In-Reply-To: References: Message-ID: I haven't submitted yet, but here's what should be very close to the finished proposal: http://codespeak.net/~dan/gsoc/micronumpy.html Any and all comments and suggestions are welcome. Please ignore the ugly feature list though... I don't think it will be in the final revision. On Apr 7, 2010 5:37 PM, "Maciej Fijalkowski" wrote: Hello. All students should submit their application ASAP. There is no point in waiting for friday IMO, especially that you can change it afterwards. Cheers, fijal _______________________________________________ pypy-dev at codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From sl at scrooge.dk Fri Apr 9 15:50:41 2010 From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=) Date: Fri, 9 Apr 2010 15:50:41 +0200 Subject: [pypy-dev] vfs.py - sandboxing with option to write Message-ID: <638ed4c7bdbf5fbed9d49b18344ad451@mail.gmail.com> Hi, I have been tracing: vfs.py, pypy_interact.py and sandlib.py. Just to make sure that I got it right. * The object RealFile in vfs.py is first used then we know that here is a RealFile on the real system that is the --tmp=directory, the method is also use on python files I can see from my trace? * The join method in RealDir is the key, because it maps (join) the virtual filename to a real filename og real directory So if I want to expand the vfs.py I need to modify RealDir to allow to return RealFile for files that are new, that is that they are not part of names. On files that do exist and I want to write to then, I do not have a clue. As I can see I get the error even then I open the file using open( "myFile", "w"). And because of that I am not sure about my previous statement " So if I want to expand the vfs.py I need to modify RealDir to allow to return RealFile for files that are new, that is that they are not part of names." Regards, S?ren Laursen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Sat Apr 10 13:46:21 2010 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 10 Apr 2010 13:46:21 +0200 Subject: [pypy-dev] mozilla speed website Message-ID: <4BC0650D.4030209@gmx.de> Hi all, Just wanted to point out the website Mozilla is using to track their JIT's progress (it's quite a bit less polished then what we have, but still): http://arewefastyet.com/ As a reference "jaeger" refers to the new per-method JIT compiler Mozilla is writing, that is supposed to run before tracing kicks in. Right now it doesn't seem to help much, even over interpretation. Cheers, Carl Friedrich From ondrej at certik.cz Sat Apr 10 18:45:44 2010 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 10 Apr 2010 09:45:44 -0700 Subject: [pypy-dev] sympy fails to import Message-ID: Hi, I tried the pypy 1.2 linux binary with our latest sympy git and this is what I got: $/tmp/pypy-1.2/bin/pypy -c "import sympy" 'import site' failed Traceback (most recent call last): File "?", line 33, in run_toplevel File "?", line 369, in run_it File "", line 1, in File "/home/ondrej/repos/sympy/sympy/__init__.py", line 43, in from interactive import init_session, init_printing File "/home/ondrej/repos/sympy/sympy/interactive/__init__.py", line 5, in f, g, h = map(Function, 'fgh') File "/home/ondrej/repos/sympy/sympy/core/multidimensional.py", line 122, in wrapper args[n] = structure_copy(entry) File "/home/ondrej/repos/sympy/sympy/core/multidimensional.py", line 54, in structure_copy return iter_copy(structure) File "/home/ondrej/repos/sympy/sympy/core/multidimensional.py", line 43, in iter_copy l.append(iter_copy(i)) File "/home/ondrej/repos/sympy/sympy/core/multidimensional.py", line 43, in iter_copy l.append(iter_copy(i)) [...] File "/home/ondrej/repos/sympy/sympy/core/multidimensional.py", line 43, in iter_copy l.append(iter_copy(i)) File "/home/ondrej/repos/sympy/sympy/core/multidimensional.py", line 42, in iter_copy if hasattr(i, "__iter__"): RuntimeError: internal error: It seems like some infinite recursion causes by some incompatibilities between python and pypy. (sympy is tested on all python 2.4, 2.5 and 2.6 and it works). Ondrej From benjamin at python.org Sat Apr 10 20:57:05 2010 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 10 Apr 2010 13:57:05 -0500 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: 2010/4/10 Ondrej Certik : > Hi, Hi > ? ?if hasattr(i, "__iter__"): > RuntimeError: internal error: Your code is probably assuming that strings don't have __iter__. They do in PyPy. -- Regards, Benjamin From dustin.xu at gmail.com Sat Apr 10 20:54:18 2010 From: dustin.xu at gmail.com (Renjie Xu) Date: Sat, 10 Apr 2010 11:54:18 -0700 Subject: [pypy-dev] IO operations capture Message-ID: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com> Hello everyone, A simple question: if I want to capture some IO operations in Pypy, do I need to dive into JIT code and modify something there? Thanks, Dustin From benjamin at python.org Sat Apr 10 21:20:30 2010 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 10 Apr 2010 14:20:30 -0500 Subject: [pypy-dev] IO operations capture In-Reply-To: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com> References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com> Message-ID: 2010/4/10 Renjie Xu : > Hello everyone, > > ? ? ?A simple question: if I want to capture some IO operations in > Pypy, do I need to dive into JIT code and modify something there? What do you mean IO operations? App level ones? > > > ? ? Thanks, > > ? ? Dustin > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- Regards, Benjamin From ondrej at certik.cz Sat Apr 10 21:25:35 2010 From: ondrej at certik.cz (Ondrej Certik) Date: Sat, 10 Apr 2010 12:25:35 -0700 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson wrote: > 2010/4/10 Ondrej Certik : >> Hi, > Hi > >> ? ?if hasattr(i, "__iter__"): >> RuntimeError: internal error: > > Your code is probably assuming that strings don't have __iter__. They > do in PyPy. That could be it. I'll investigate it and report later. Thanks for the tip. Ondrej From dustin.xu at gmail.com Sat Apr 10 21:39:07 2010 From: dustin.xu at gmail.com (Renjie Xu) Date: Sat, 10 Apr 2010 12:39:07 -0700 Subject: [pypy-dev] IO operations capture In-Reply-To: References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com> Message-ID: Not limit to that, I also want to monitor some system level status, such as the network flows, memory changes, even thread/process situation(I am not sure if I can do this even in JIT) . I just want to know if JIT has processed some exceptions so that only based-on python code I cannot see them. Hope this can make sense somehow, Thanks, Dustin On Apr 10, 2010, at 12:20 PM, Benjamin Peterson wrote: > 2010/4/10 Renjie Xu : >> Hello everyone, >> >> A simple question: if I want to capture some IO operations in >> Pypy, do I need to dive into JIT code and modify something there? > > What do you mean IO operations? App level ones? > >> >> >> Thanks, >> >> Dustin >> _______________________________________________ >> pypy-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev >> > > > > -- > Regards, > Benjamin From benjamin at python.org Sat Apr 10 22:32:35 2010 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 10 Apr 2010 15:32:35 -0500 Subject: [pypy-dev] IO operations capture In-Reply-To: References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com>

Message-ID: 2010/4/10 Renjie Xu : > Not limit to that, I also want to monitor some system level status, such as > the network flows, memory changes, even thread/process situation(I am not > sure if I can do this even in JIT) . > I just want to know if JIT has processed some exceptions so that only > based-on python code I cannot see them. I think you want to look at the PyPy sandbox. (which at the moment is not compatible with the JIT) -- Regards, Benjamin From fijall at gmail.com Mon Apr 12 07:20:34 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 11 Apr 2010 23:20:34 -0600 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik wrote: > On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson wrote: >> 2010/4/10 Ondrej Certik : >>> Hi, >> Hi >> >>> ? ?if hasattr(i, "__iter__"): >>> RuntimeError: internal error: >> >> Your code is probably assuming that strings don't have __iter__. They >> do in PyPy. > > That could be it. I'll investigate it and report later. > > Thanks for the tip. > > Ondrej > _______________________________________________ Didn't we remove __iter__ after the release from strings? From fijall at gmail.com Mon Apr 12 07:22:31 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 11 Apr 2010 23:22:31 -0600 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski wrote: > On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik wrote: >> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson wrote: >>> 2010/4/10 Ondrej Certik : >>>> Hi, >>> Hi >>> >>>> ? ?if hasattr(i, "__iter__"): >>>> RuntimeError: internal error: >>> >>> Your code is probably assuming that strings don't have __iter__. They >>> do in PyPy. >> >> That could be it. I'll investigate it and report later. >> >> Thanks for the tip. >> >> Ondrej >> _______________________________________________ > > Didn't we remove __iter__ after the release from strings? > Yop we did. Ondrej: you can build new pypy and it should work (we also should do 1.2.1 release some time soon I believe). Also, I don't think it's wise to use hasattr(x, '__iter__') to decide whether stuff is string or not. Cheers, fijal From fijall at gmail.com Mon Apr 12 07:23:45 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 11 Apr 2010 23:23:45 -0600 Subject: [pypy-dev] IO operations capture In-Reply-To: References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com>

Message-ID: On Sat, Apr 10, 2010 at 2:32 PM, Benjamin Peterson wrote: > 2010/4/10 Renjie Xu : >> Not limit to that, I also want to monitor some system level status, such as >> the network flows, memory changes, even thread/process situation(I am not >> sure if I can do this even in JIT) . >> I just want to know if JIT has processed some exceptions so that only >> based-on python code I cannot see them. > > I think you want to look at the PyPy sandbox. (which at the moment is > not compatible with the JIT) > Stop spreading FUD, it is compatible :) Renje: if you want to write a python program, JIT is completely opaque. It'll work with and without JIT the same way. From ondrej at certik.cz Mon Apr 12 07:33:06 2010 From: ondrej at certik.cz (Ondrej Certik) Date: Mon, 12 Apr 2010 06:33:06 +0100 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: On Mon, Apr 12, 2010 at 6:22 AM, Maciej Fijalkowski wrote: > On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski wrote: >> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik wrote: >>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson wrote: >>>> 2010/4/10 Ondrej Certik : >>>>> Hi, >>>> Hi >>>> >>>>> ? ?if hasattr(i, "__iter__"): >>>>> RuntimeError: internal error: >>>> >>>> Your code is probably assuming that strings don't have __iter__. They >>>> do in PyPy. >>> >>> That could be it. I'll investigate it and report later. >>> >>> Thanks for the tip. >>> >>> Ondrej >>> _______________________________________________ >> >> Didn't we remove __iter__ after the release from strings? >> > > Yop we did. > > Ondrej: you can build new pypy and it should work (we also should do > 1.2.1 release some time soon I believe). Does anyone have a recent git repository of pypy that I could pull from? If not, I'll just use the svn. > > Also, I don't think it's wise to use hasattr(x, '__iter__') to decide > whether stuff is string or not. I think it's not wise at all, I agree. We should fix it. Ondrej From fijall at gmail.com Mon Apr 12 07:44:52 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 11 Apr 2010 23:44:52 -0600 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: On Sun, Apr 11, 2010 at 11:33 PM, Ondrej Certik wrote: > On Mon, Apr 12, 2010 at 6:22 AM, Maciej Fijalkowski wrote: >> On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski wrote: >>> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik wrote: >>>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson wrote: >>>>> 2010/4/10 Ondrej Certik : >>>>>> Hi, >>>>> Hi >>>>> >>>>>> ? ?if hasattr(i, "__iter__"): >>>>>> RuntimeError: internal error: >>>>> >>>>> Your code is probably assuming that strings don't have __iter__. They >>>>> do in PyPy. >>>> >>>> That could be it. I'll investigate it and report later. >>>> >>>> Thanks for the tip. >>>> >>>> Ondrej >>>> _______________________________________________ >>> >>> Didn't we remove __iter__ after the release from strings? >>> >> >> Yop we did. >> >> Ondrej: you can build new pypy and it should work (we also should do >> 1.2.1 release some time soon I believe). > > Does anyone have a recent git repository of pypy that I could pull > from? If not, I'll just use the svn. svn sounds safer (I know problems with git mirrors) > >> >> Also, I don't think it's wise to use hasattr(x, '__iter__') to decide >> whether stuff is string or not. > > I think it's not wise at all, I agree. We should fix it. > > Ondrej > From fijall at gmail.com Mon Apr 12 07:45:36 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 11 Apr 2010 23:45:36 -0600 Subject: [pypy-dev] sympy fails to import In-Reply-To: References: Message-ID: On Sun, Apr 11, 2010 at 11:44 PM, Maciej Fijalkowski wrote: > On Sun, Apr 11, 2010 at 11:33 PM, Ondrej Certik wrote: >> On Mon, Apr 12, 2010 at 6:22 AM, Maciej Fijalkowski wrote: >>> On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski wrote: >>>> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik wrote: >>>>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson wrote: >>>>>> 2010/4/10 Ondrej Certik : >>>>>>> Hi, >>>>>> Hi >>>>>> >>>>>>> ? ?if hasattr(i, "__iter__"): >>>>>>> RuntimeError: internal error: >>>>>> >>>>>> Your code is probably assuming that strings don't have __iter__. They >>>>>> do in PyPy. >>>>> >>>>> That could be it. I'll investigate it and report later. >>>>> >>>>> Thanks for the tip. >>>>> >>>>> Ondrej >>>>> _______________________________________________ >>>> >>>> Didn't we remove __iter__ after the release from strings? >>>> >>> >>> Yop we did. >>> >>> Ondrej: you can build new pypy and it should work (we also should do >>> 1.2.1 release some time soon I believe). >> >> Does anyone have a recent git repository of pypy that I could pull >> from? If not, I'll just use the svn. > > svn sounds safer (I know problems with git mirrors) > >> >>> >>> Also, I don't think it's wise to use hasattr(x, '__iter__') to decide >>> whether stuff is string or not. >> >> I think it's not wise at all, I agree. We should fix it. >> >> Ondrej >> > Oh, and btw, there are nightly builds here: http://buildbot.pypy.org/nightly/ you have to download it into a checkout somewhere below root of checkout. From renesd at gmail.com Mon Apr 12 16:20:31 2010 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 12 Apr 2010 15:20:31 +0100 Subject: [pypy-dev] mozilla speed website In-Reply-To: <4BC0650D.4030209@gmx.de> References: <4BC0650D.4030209@gmx.de> Message-ID: On Sat, Apr 10, 2010 at 12:46 PM, Carl Friedrich Bolz wrote: > Hi all, > > Just wanted to point out the website Mozilla is using to track their > JIT's progress (it's quite a bit less polished then what we have, but > still): > > http://arewefastyet.com/ > > As a reference "jaeger" refers to the new per-method JIT compiler > Mozilla is writing, that is supposed to run before tracing kicks in. > Right now it doesn't seem to help much, even over interpretation. > > Cheers, > > Carl Friedrich > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > Hi, cool. Just a little note... On ARM they are faster with the combo of jager+tracing http://arewefastyet.com/?machine=3 cu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Mon Apr 12 16:34:59 2010 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 12 Apr 2010 16:34:59 +0200 Subject: [pypy-dev] mozilla speed website In-Reply-To: References: <4BC0650D.4030209@gmx.de> Message-ID: <4BC32F93.4020108@gmx.de> On 04/12/2010 04:20 PM, Ren? Dudfield wrote: > cool. Just a little note... On ARM they are faster with the combo of > jager+tracing http://arewefastyet.com/?machine=3 I read the graphs differently: Both on ARM and on the default machine the orange line ("tracing") is a bit below the purple line ("jaeger+tracing"), i.e. tracing is faster. Cheers, Carl Friedrich From fijall at gmail.com Mon Apr 12 18:15:50 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 12 Apr 2010 10:15:50 -0600 Subject: [pypy-dev] [pypy-svn] r73628 - in pypy/branch/cpython-extension/pypy/module/cpyext: . test In-Reply-To: References: <20100410150756.60AD7282BAD@codespeak.net> Message-ID: I probably have missed some part of discussion, but - shouldn't we have it present the same interface as lib/array.py? If lib/array.py is not needed, since we use the C version, how about killing lib/array? From renesd at gmail.com Mon Apr 12 19:00:07 2010 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 12 Apr 2010 18:00:07 +0100 Subject: [pypy-dev] mozilla speed website In-Reply-To: <4BC32F93.4020108@gmx.de> References: <4BC0650D.4030209@gmx.de> <4BC32F93.4020108@gmx.de> Message-ID: ah, indeed. oops. It looks like (jager+tracing) is now similar in speed to tracing (still a bit slower), whereas (jager+tracing) used to be closer to the interpreter speed. Whereas jager is only slightly faster than the base interpreter. cu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Mon Apr 12 19:03:26 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 12 Apr 2010 11:03:26 -0600 Subject: [pypy-dev] mozilla speed website In-Reply-To: References: <4BC0650D.4030209@gmx.de> <4BC32F93.4020108@gmx.de> Message-ID: On Mon, Apr 12, 2010 at 11:00 AM, Ren? Dudfield wrote: > ah, indeed.? oops. > > It looks like (jager+tracing) is now similar in speed to tracing (still a > bit slower), whereas (jager+tracing) used to be closer to the interpreter > speed.? Whereas jager is only slightly faster than the base interpreter. > > cu. > Please note that those benchmarks are extremely JIT-friendly in general. They have very tight loops doing one operation or mostly something like that. From fijall at gmail.com Mon Apr 12 19:18:53 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 12 Apr 2010 11:18:53 -0600 Subject: [pypy-dev] [pypy-svn] r73627 - pypy/branch/cpython-extension/pypy/module/cpyext/include In-Reply-To: <20100410143123.D8EB1282BAD@codespeak.net> References: <20100410143123.D8EB1282BAD@codespeak.net> Message-ID: Why? I think we do support that. On Sat, Apr 10, 2010 at 8:31 AM, wrote: > Author: jandem > Date: Sat Apr 10 16:31:22 2010 > New Revision: 73627 > > Modified: > ? pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h > Log: > Comment out PyObject_REALLOC > > > Modified: pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h > ============================================================================== > --- pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h ? ?(original) > +++ pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h ? ?Sat Apr 10 16:31:22 2010 > @@ -7,7 +7,8 @@ > > ?/* XXX use obmalloc like cpython and pypy do, otherwise we might get segfaults */ > ?#define PyObject_MALLOC ? ? ? ? ? ? ? ?PyMem_MALLOC > -#define PyObject_REALLOC ? ? ? PyMem_REALLOC > +// we won't support this > +// #define PyObject_REALLOC ? ?PyMem_REALLOC > ?#define PyObject_FREE ? ? ? ? ?PyMem_FREE > > ?#define PyMem_Malloc PyMem_MALLOC > _______________________________________________ > pypy-svn mailing list > pypy-svn at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn > From anto.cuni at gmail.com Mon Apr 12 19:26:58 2010 From: anto.cuni at gmail.com (Antonio Cuni) Date: Mon, 12 Apr 2010 19:26:58 +0200 Subject: [pypy-dev] [pypy-svn] r73628 - in pypy/branch/cpython-extension/pypy/module/cpyext: . test In-Reply-To: References: <20100410150756.60AD7282BAD@codespeak.net> Message-ID: <4BC357E2.8090504@gmail.com> Maciej Fijalkowski wrote: > I probably have missed some part of discussion, but - shouldn't we > have it present the same interface as lib/array.py? If lib/array.py is > not needed, since we use the C version, how about killing lib/array? lib/array is needed by OO backends, which can't use the C version From fijall at gmail.com Mon Apr 12 21:18:34 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 12 Apr 2010 13:18:34 -0600 Subject: [pypy-dev] [pypy-svn] r73628 - in pypy/branch/cpython-extension/pypy/module/cpyext: . test In-Reply-To: <4BC357E2.8090504@gmail.com> References: <20100410150756.60AD7282BAD@codespeak.net> <4BC357E2.8090504@gmail.com> Message-ID: Good point. But anyway we should not expose 2 different array types on C version. On Mon, Apr 12, 2010 at 11:26 AM, Antonio Cuni wrote: > Maciej Fijalkowski wrote: >> I probably have missed some part of discussion, but - shouldn't we >> have it present the same interface as lib/array.py? If lib/array.py is >> not needed, since we use the C version, how about killing lib/array? > > lib/array is needed by OO backends, which can't use the C version > From jandemooij at gmail.com Mon Apr 12 22:22:34 2010 From: jandemooij at gmail.com (Jan de Mooij) Date: Mon, 12 Apr 2010 22:22:34 +0200 Subject: [pypy-dev] [pypy-svn] r73628 - in pypy/branch/cpython-extension/pypy/module/cpyext: . test In-Reply-To: References: <20100410150756.60AD7282BAD@codespeak.net> Message-ID: Hi fijal, On Mon, Apr 12, 2010 at 6:15 PM, Maciej Fijalkowski wrote: > > I probably have missed some part of discussion, but - shouldn't we > have it present the same interface as lib/array.py? If lib/array.py is > not needed, since we use the C version, how about killing lib/array? I added it only to the test directory as it's not yet ready. We need suport for __setitem__ and iterators (should be easy though) and some other pieces. Once that's done it can probably replace lib/array.py on pypy-c. It would be interesting to benchmark it against CPython to test cpyext overhead. > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From jandemooij at gmail.com Mon Apr 12 22:29:59 2010 From: jandemooij at gmail.com (Jan de Mooij) Date: Mon, 12 Apr 2010 22:29:59 +0200 Subject: [pypy-dev] [pypy-svn] r73627 - pypy/branch/cpython-extension/pypy/module/cpyext/include In-Reply-To: References: <20100410143123.D8EB1282BAD@codespeak.net> Message-ID: On Mon, Apr 12, 2010 at 7:18 PM, Maciej Fijalkowski wrote: > Why? I think we do support that. On IRC xorAxAx asked me to comment it out again. I don't know the exact reason, he can probably tell you more about it :) > > On Sat, Apr 10, 2010 at 8:31 AM, ? wrote: >> Author: jandem >> Date: Sat Apr 10 16:31:22 2010 >> New Revision: 73627 >> >> Modified: >> ? pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h >> Log: >> Comment out PyObject_REALLOC >> >> >> Modified: pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h >> ============================================================================== >> --- pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h ? ?(original) >> +++ pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h ? ?Sat Apr 10 16:31:22 2010 >> @@ -7,7 +7,8 @@ >> >> ?/* XXX use obmalloc like cpython and pypy do, otherwise we might get segfaults */ >> ?#define PyObject_MALLOC ? ? ? ? ? ? ? ?PyMem_MALLOC >> -#define PyObject_REALLOC ? ? ? PyMem_REALLOC >> +// we won't support this >> +// #define PyObject_REALLOC ? ?PyMem_REALLOC >> ?#define PyObject_FREE ? ? ? ? ?PyMem_FREE >> >> ?#define PyMem_Malloc PyMem_MALLOC >> _______________________________________________ >> pypy-svn mailing list >> pypy-svn at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-svn >> > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From fijall at gmail.com Mon Apr 12 22:54:06 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 12 Apr 2010 14:54:06 -0600 Subject: [pypy-dev] [pypy-svn] r73627 - pypy/branch/cpython-extension/pypy/module/cpyext/include In-Reply-To: References: <20100410143123.D8EB1282BAD@codespeak.net> Message-ID: On Mon, Apr 12, 2010 at 2:29 PM, Jan de Mooij wrote: > On Mon, Apr 12, 2010 at 7:18 PM, Maciej Fijalkowski wrote: >> Why? I think we do support that. > > On IRC xorAxAx asked me to comment it out again. I don't know the > exact reason, he can probably tell you more about it :) Fair enough :) Maybe he can speak up here. > >> >> On Sat, Apr 10, 2010 at 8:31 AM, ? wrote: >>> Author: jandem >>> Date: Sat Apr 10 16:31:22 2010 >>> New Revision: 73627 >>> >>> Modified: >>> ? pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h >>> Log: >>> Comment out PyObject_REALLOC >>> >>> >>> Modified: pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h >>> ============================================================================== >>> --- pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h ? ?(original) >>> +++ pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h ? ?Sat Apr 10 16:31:22 2010 >>> @@ -7,7 +7,8 @@ >>> >>> ?/* XXX use obmalloc like cpython and pypy do, otherwise we might get segfaults */ >>> ?#define PyObject_MALLOC ? ? ? ? ? ? ? ?PyMem_MALLOC >>> -#define PyObject_REALLOC ? ? ? PyMem_REALLOC >>> +// we won't support this >>> +// #define PyObject_REALLOC ? ?PyMem_REALLOC >>> ?#define PyObject_FREE ? ? ? ? ?PyMem_FREE >>> >>> ?#define PyMem_Malloc PyMem_MALLOC >>> _______________________________________________ >>> pypy-svn mailing list >>> pypy-svn at codespeak.net >>> http://codespeak.net/mailman/listinfo/pypy-svn >>> >> _______________________________________________ >> pypy-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev > From fijall at gmail.com Mon Apr 12 22:55:01 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 12 Apr 2010 14:55:01 -0600 Subject: [pypy-dev] [pypy-svn] r73628 - in pypy/branch/cpython-extension/pypy/module/cpyext: . test In-Reply-To: References: <20100410150756.60AD7282BAD@codespeak.net> Message-ID: Sounds reasonable to me. On Mon, Apr 12, 2010 at 2:22 PM, Jan de Mooij wrote: > Hi fijal, > > On Mon, Apr 12, 2010 at 6:15 PM, Maciej Fijalkowski wrote: >> >> I probably have missed some part of discussion, but - shouldn't we >> have it present the same interface as lib/array.py? If lib/array.py is >> not needed, since we use the C version, how about killing lib/array? > > I added it only to the test directory as it's not yet ready. We need > suport for __setitem__ and iterators (should be easy though) and some > other pieces. Once that's done it can probably replace lib/array.py on > pypy-c. It would be interesting to benchmark it against CPython to > test cpyext overhead. >> _______________________________________________ >> pypy-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/pypy-dev > From 2008a at usenet.alexanderweb.de Mon Apr 12 23:40:56 2010 From: 2008a at usenet.alexanderweb.de (Alexander Schremmer) Date: Mon, 12 Apr 2010 23:40:56 +0200 Subject: [pypy-dev] [pypy-svn] r73627 - pypy/branch/cpython-extension/pypy/module/cpyext/include References: <20100410143123.D8EB1282BAD@codespeak.net> Message-ID: On Mon, 12 Apr 2010 14:54:06 -0600, Maciej Fijalkowski wrote: > On Mon, Apr 12, 2010 at 2:29 PM, Jan de Mooij wrote: >> On Mon, Apr 12, 2010 at 7:18 PM, Maciej Fijalkowski wrote: >>> Why? I think we do support that. >> >> On IRC xorAxAx asked me to comment it out again. I don't know the >> exact reason, he can probably tell you more about it :) > > Fair enough :) Maybe he can speak up here. PyObject_* need to go through lltype.malloc, unlike they do now (as PyObject_New also uses lltype.malloc). Because there is no realloc operation in PyPy, we cannot support it. Kind regards, Alexander From arigo at tunes.org Tue Apr 13 10:12:25 2010 From: arigo at tunes.org (Armin Rigo) Date: Tue, 13 Apr 2010 10:12:25 +0200 Subject: [pypy-dev] vfs.py - sandboxing with option to write In-Reply-To: <638ed4c7bdbf5fbed9d49b18344ad451@mail.gmail.com> References: <638ed4c7bdbf5fbed9d49b18344ad451@mail.gmail.com> Message-ID: <20100413081225.GA24281@code0.codespeak.net> Hi Soren, On Fri, Apr 09, 2010 at 03:50:41PM +0200, S?ren Laursen wrote: > On files that do exist and I want to write to then, I do not have a clue. As > I can see I get the error even then I open the file using open( "myFile", > "w"). The basics is what occurs when you do open("myfile","w") in the sandboxed interpreter. First, the interpreter itself translates your call to a call to the Posix function (man 2 open). That call is intercepted by the sandboxing mechanism, and translated in sandlib.py in a call to do_ll_os__ll_os_open(). That's where you can start tweaking. So far, do_ll_os__ll_os_open() checks that we are calling it with O_RDONLY and always raises EPERM otherwise. You need to change that by carefully adding more cases there. Note that the get_node() method in sandlib.py translates a Posix path given by do_ll_os__ll_os_open() -- which is the "myfile" specified in the interpreter -- into a "node", which is so far a VFS File or Dir. You also need to add a few method, at least do_ll_os__ll_os_write(), to handle writes. A bientot, Armin. From fijall at gmail.com Wed Apr 14 06:38:26 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 13 Apr 2010 22:38:26 -0600 Subject: [pypy-dev] 64bit nightly failures Message-ID: Are caused by me installing java on tannit. We should probably fix/skip them From holger at merlinux.eu Wed Apr 14 13:51:53 2010 From: holger at merlinux.eu (holger krekel) Date: Wed, 14 Apr 2010 13:51:53 +0200 Subject: [pypy-dev] three pathological cases for the JIT (pointer) Message-ID: <20100414115153.GP26514@trillke.net> Hi, just came across this post which highlights three pathological JIT cases: http://www.ripton.net/blog/?p=51 has this received some analysis already, maybe on IRC? cheers, holger From fuzzyman at gmail.com Wed Apr 14 13:59:08 2010 From: fuzzyman at gmail.com (Michael Foord) Date: Wed, 14 Apr 2010 13:59:08 +0200 Subject: [pypy-dev] three pathological cases for the JIT (pointer) In-Reply-To: <20100414115153.GP26514@trillke.net> References: <20100414115153.GP26514@trillke.net> Message-ID: Benjamin Peterson definitely looked at it. He posted a comment on the (short) reddit thread: http://www.reddit.com/r/Python/comments/bkyl1/3_pathological_cases_for_the_pypy_jit/ Michael On 14 April 2010 13:51, holger krekel wrote: > Hi, > > just came across this post which highlights three pathological JIT cases: > > http://www.ripton.net/blog/?p=51 > > has this received some analysis already, maybe on IRC? > > cheers, > holger > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -- http://www.ironpythoninaction.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From list-sink at trainedmonkeystudios.org Mon Apr 19 03:31:11 2010 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Sun, 18 Apr 2010 18:31:11 -0700 Subject: [pypy-dev] undefined symbol in ParserGenerator Message-ID: <1271640671.26181.19.camel@localhost> In pypy/interpreter/pyparser/metaparser.py in get_first on line 233: the name 'symbol' is undefined. I hit this when parsing the python grammar from the 3.1.2 release. Oddly, the current py3k trunk does not hit this. I'll dig more to see if I can figure out why the grammar is causing this, but the error handling here is obviously bogus, so I thought I'd go ahead and report it. -Terrence From benjamin at python.org Mon Apr 19 04:13:13 2010 From: benjamin at python.org (Benjamin Peterson) Date: Sun, 18 Apr 2010 21:13:13 -0500 Subject: [pypy-dev] undefined symbol in ParserGenerator In-Reply-To: <1271640671.26181.19.camel@localhost> References: <1271640671.26181.19.camel@localhost> Message-ID: 2010/4/18 Terrence Cole : > In pypy/interpreter/pyparser/metaparser.py in get_first on line 233: > the name 'symbol' is undefined. > > I hit this when parsing the python grammar from the 3.1.2 release. > Oddly, the current py3k trunk does not hit this. ?I'll dig more to see > if I can figure out why the grammar is causing this, but the error > handling here is obviously bogus, so I thought I'd go ahead and report > it. This is because the 3.1.2 grammar is incorrect, and CPython's parser generator accepts it. See http://svn.python.org/view?view=rev&revision=75080. It's safe to use the py3k branch one, since it hasn't changed. -- Regards, Benjamin From list-sink at trainedmonkeystudios.org Mon Apr 19 04:42:17 2010 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Sun, 18 Apr 2010 19:42:17 -0700 Subject: [pypy-dev] undefined symbol in ParserGenerator In-Reply-To: References: <1271640671.26181.19.camel@localhost> Message-ID: <1271644938.26181.78.camel@localhost> On Sun, 2010-04-18 at 21:13 -0500, Benjamin Peterson wrote: > 2010/4/18 Terrence Cole : > > In pypy/interpreter/pyparser/metaparser.py in get_first on line 233: > > the name 'symbol' is undefined. > > > > I hit this when parsing the python grammar from the 3.1.2 release. > > Oddly, the current py3k trunk does not hit this. I'll dig more to see > > if I can figure out why the grammar is causing this, but the error > > handling here is obviously bogus, so I thought I'd go ahead and report > > it. > > This is because the 3.1.2 grammar is incorrect, and CPython's parser > generator accepts it. See > http://svn.python.org/view?view=rev&revision=75080. It's safe to use > the py3k branch one, since it hasn't changed. Awesome! You've just saved me a lot of difficult, pointless work. Below is the svn diff I ended up with when testing. -Terrence Index: pypy/interpreter/pyparser/metaparser.py =================================================================== --- pypy/interpreter/pyparser/metaparser.py (revision 73878) +++ pypy/interpreter/pyparser/metaparser.py (working copy) @@ -230,7 +230,8 @@ for label, their_first in overlap_check.iteritems(): for sub_label in their_first: if sub_label in inverse: - raise PgenError("ambiguous symbol %s" % (symbol,)) + raise PgenError("ambiguous symbol at '%s': %s" % (label, + sub_label)) inverse[sub_label] = label self.first[name] = all_labels return all_labels From ndbecker2 at gmail.com Mon Apr 19 15:13:05 2010 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 19 Apr 2010 09:13:05 -0400 Subject: [pypy-dev] support for boost::python? Message-ID: How close is pypy to being able to support extensions written for boost::python? From amauryfa at gmail.com Mon Apr 19 18:04:53 2010 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Mon, 19 Apr 2010 18:04:53 +0200 Subject: [pypy-dev] support for boost::python? In-Reply-To: References: Message-ID: Hello, 2010/4/19 Neal Becker : > How close is pypy to being able to support extensions written for > boost::python? It's not extraordinary difficult, but there are many things to do. At least this target is inside the scope of the cpyext module. I tried to compile boost::python using pypy headers. They are many missing functions, most of them are easy to implement; but PyRun_File and PySliceObject will be more difficult. Volunteers are welcome! In case you want to start, here are the compilation errors I got: http://paste.pocoo.org/show/203663/ The missing PyList_, PyDict_ and PyComplex_ functions are probably the most easy to implement, and a good way to enter the code of the cpyext module. -- Amaury Forgeot d'Arc From tobami at googlemail.com Tue Apr 20 19:14:23 2010 From: tobami at googlemail.com (Miquel Torres) Date: Tue, 20 Apr 2010 19:14:23 +0200 Subject: [pypy-dev] speed.pypy.org changes Message-ID: Hi all, there have been pretty big changes under the hood of (they were implemented for some time now, but I didn't have time to migrate the site) in order to accomodate a couple of new features. One of them doesn't affect pypy for the moment, which is allowing revisions to be actually strings (it allows to change to git, for example), and consecuently basing revision ordering on date, rather than on rev number. Changes you may notice are geared towards easing the identification of the cause of performance changes: - Std deviation was added to the DB, overview table and timeline tooltips. This way we can rule out fluctuations in the measuring as a cause for a big change. It has to be pointed out though, that this is only as useful as the way the std dev is being computed. (there you go, Carl Friedrich ;-) - SVN integration: Under the overview table, the commit logs starting after the last tested revision are shown. It should help quickly identify which commits should take the blame for a regression. I hope you find it useful! If anyone thinks about any way to improve on those two features please say so. Cheers, Miquel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfbolz at gmx.de Tue Apr 20 20:29:28 2010 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 20 Apr 2010 20:29:28 +0200 Subject: [pypy-dev] speed.pypy.org changes In-Reply-To: References: Message-ID: <4BCDF288.8070901@gmx.de> Hi Miquel, On 04/20/2010 07:14 PM, Miquel Torres wrote: > Changes you may notice are geared towards easing the identification of > the cause of performance changes: > - Std deviation was added to the DB, overview table and timeline > tooltips. This way we can rule out fluctuations in the measuring as a > cause for a big change. It has to be pointed out though, that this is > only as useful as the way the std dev is being computed. (there you go, > Carl Friedrich ;-) Yay, that's incredibly cool! Let's hope that eventually the graph library supports errors too, so we can add them graphically. Anyway, I already found some fun things about the benchmarks, so thanks a lot! (e.g. the std dev of chaos is very large, which is not really a good thing) > - SVN integration: Under the overview table, the commit logs starting > after the last tested revision are shown. It should help quickly > identify which commits should take the blame for a regression. That's a very clever idea. Cheers, Carl Friedrich From fijall at gmail.com Tue Apr 20 20:41:19 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 20 Apr 2010 12:41:19 -0600 Subject: [pypy-dev] speed.pypy.org changes In-Reply-To: <4BCDF288.8070901@gmx.de> References: <4BCDF288.8070901@gmx.de> Message-ID: Hi Carl, Hi Miquel. Cool job! On Tue, Apr 20, 2010 at 12:29 PM, Carl Friedrich Bolz wrote: > Hi Miquel, > > On 04/20/2010 07:14 PM, Miquel Torres wrote: >> Changes you may notice are geared towards easing the identification of >> the cause of performance changes: >> - Std deviation was added to the DB, overview table and timeline >> tooltips. This way we can rule out fluctuations in the measuring as a >> cause for a big change. It has to be pointed out though, that this is >> only as useful as the way the std dev is being computed. (there you go, >> Carl Friedrich ;-) > > Yay, that's incredibly cool! Let's hope that eventually the graph > library supports errors too, so we can add them graphically. Anyway, I > already found some fun things about the benchmarks, so thanks a lot! > (e.g. the std dev of chaos is very large, which is not really a good thing) Of course it's large, because as mentioned above the way we compute it doesn't make sense. We have an average over consecutive runs which include warmup (less and less so over the course). Cheers, fijal From cfbolz at gmx.de Tue Apr 20 20:49:01 2010 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 20 Apr 2010 20:49:01 +0200 Subject: [pypy-dev] speed.pypy.org changes In-Reply-To: References: <4BCDF288.8070901@gmx.de> Message-ID: <4BCDF71D.70705@gmx.de> Hi Maciek, On 04/20/2010 08:41 PM, Maciej Fijalkowski wrote: >> (e.g. the std dev of chaos is very large, which is not really a good thing) > > Of course it's large, because as mentioned above the way we compute it > doesn't make sense. We have an average over consecutive runs which > include warmup (less and less so over the course). Hm, you're right. Seems chaos is really not doing any warmup, which is of course silly. I guess we should do something systematic about warmup at some point soon, also because it affects the blackhole-improvements Armin is working on. Cheers, Carl Friedrich From tobami at googlemail.com Tue Apr 20 20:50:45 2010 From: tobami at googlemail.com (Miquel Torres) Date: Tue, 20 Apr 2010 20:50:45 +0200 Subject: [pypy-dev] speed.pypy.org changes In-Reply-To: References: <4BCDF288.8070901@gmx.de> Message-ID: Yeah, that can be seen in the fact that chaos's std dev for pypy-c is not as large as for pypy-c-jit, in fact it is perfectly normal. Btw. for easily spotting big std dev values maybe they should be highlighted in red. What would a maximum reasonable value for std dev would be (compared to total time)? 2010/4/20 Maciej Fijalkowski > Hi Carl, Hi Miquel. > > Cool job! > > On Tue, Apr 20, 2010 at 12:29 PM, Carl Friedrich Bolz > wrote: > > Hi Miquel, > > > > On 04/20/2010 07:14 PM, Miquel Torres wrote: > >> Changes you may notice are geared towards easing the identification of > >> the cause of performance changes: > >> - Std deviation was added to the DB, overview table and timeline > >> tooltips. This way we can rule out fluctuations in the measuring as a > >> cause for a big change. It has to be pointed out though, that this is > >> only as useful as the way the std dev is being computed. (there you go, > >> Carl Friedrich ;-) > > > > Yay, that's incredibly cool! Let's hope that eventually the graph > > library supports errors too, so we can add them graphically. Anyway, I > > already found some fun things about the benchmarks, so thanks a lot! > > (e.g. the std dev of chaos is very large, which is not really a good > thing) > > Of course it's large, because as mentioned above the way we compute it > doesn't make sense. We have an average over consecutive runs which > include warmup (less and less so over the course). > > Cheers, > fijal > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sl at scrooge.dk Wed Apr 21 12:31:00 2010 From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=) Date: Wed, 21 Apr 2010 12:31:00 +0200 Subject: [pypy-dev] Sandboxing - trunk - external function 'setlocale' Message-ID: <24154eb5d2760a17bda11d3dea9023e6@mail.gmail.com> Hi, The last 4-6 days the sandboxing pypy in trunk is not running. Running trunk and compiled the "latest" pypy, got this error when running the sandbox: Warning: cannot find your CPU L2 cache size in /proc/cpuinfo Not Implemented: sandboxing for external function 'setlocale' RPython traceback: File "implement.c", line 2383, in entry_point File "implement.c", line 27299, in PyFrame_execute_frame File "implement.c", line 46059, in PyFrame_dispatch File "implement.c", line 64153, in PyFrame_handle_bytecode File "implement.c", line 93878, in PyFrame_dispatch_bytecode File "implement.c", line 138371, in PyFrame_call_function File "implement.c", line 43324, in BuiltinCode_funcrun_obj File "implement.c", line 43873, in BuiltinCode_handle_exception Fatal RPython error: LocaleError uname -a: Linux mig 2.6.26-2-686 #1 SMP Wed Feb 10 08:59:21 UTC 2010 i686 GNU/Linux Debian lenny 32bit, x86. Regards S?ren -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Wed Apr 21 17:10:21 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 21 Apr 2010 09:10:21 -0600 Subject: [pypy-dev] Sandboxing - trunk - external function 'setlocale' In-Reply-To: <24154eb5d2760a17bda11d3dea9023e6@mail.gmail.com> References: <24154eb5d2760a17bda11d3dea9023e6@mail.gmail.com> Message-ID: Bah. I think fixed, will try later. 2010/4/21 S?ren Laursen : > Hi, > > > > The last 4-6 days the sandboxing pypy in trunk is not running. > > > > Running trunk and compiled the "latest" pypy, got this error when running > the sandbox: > > Warning: cannot find your CPU L2 cache size in /proc/cpuinfo > > Not Implemented: sandboxing for external function 'setlocale' > > RPython traceback: > > ? File "implement.c", line 2383, in entry_point > > ? File "implement.c", line 27299, in PyFrame_execute_frame > > ? File "implement.c", line 46059, in PyFrame_dispatch > > ? File "implement.c", line 64153, in PyFrame_handle_bytecode > > ? File "implement.c", line 93878, in PyFrame_dispatch_bytecode > > ? File "implement.c", line 138371, in PyFrame_call_function > > ? File "implement.c", line 43324, in BuiltinCode_funcrun_obj > > ? File "implement.c", line 43873, in BuiltinCode_handle_exception > > Fatal RPython error: LocaleError > > > > uname -a: > > Linux mig 2.6.26-2-686 #1 SMP Wed Feb 10 08:59:21 UTC 2010 i686 GNU/Linux > > > > Debian lenny 32bit, x86. > > > > Regards > > > > S?ren > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From sl at scrooge.dk Sun Apr 25 15:14:56 2010 From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=) Date: Sun, 25 Apr 2010 15:14:56 +0200 Subject: [pypy-dev] Sandbox - os. functions remove, rename and others? Message-ID: <699565aa6c7f8e0d9c91a688a8cc0205@mail.gmail.com> Hi all, I have more or less implemented a read/write filesystem in pypy sandbox. Right now I am extending it with os functions. For example os.rename and os.remove. I have followed the direction, that is extend sandlib.py and vfs.py files with the new functions a la def do_ll_os__ll_os_remove and def do_ll_os__ll_os_rename But I get an error when running a small test: import os os.remove( "aFil" ) Error: os.remove( "aFil" ) RuntimeError: internal error: [Subprocess exit code: 1] To verify that I understand the design correct, I added a new listdir function: do_ll_os__ll_os_listsdir(self, vpathname): It is a copy paste from the original: do_ll_os__ll_os_listdir(self, vpathname): This also gives an error, but it is different: for file in os.listsdir('.'): AttributeError: 'module' object has no attribute 'listsdir' I interpreted that, as I need, somewhere to define that I have implemented the remove function to the sandbox. The new listsdir is not defined in the os module, as expected. Regards S?ren -------------- next part -------------- An HTML attachment was scrubbed... URL: