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: <g2z4ef8bec91003312019geee8036dxab46d37b2851d88a@mail.gmail.com>

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: <g2z4ef8bec91003312019geee8036dxab46d37b2851d88a@mail.gmail.com>
References: <g2z4ef8bec91003312019geee8036dxab46d37b2851d88a@mail.gmail.com>
Message-ID: <EFF14D58-DA6F-4C55-B860-E0A854334A8B@gmail.com>

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: <w2wa0e09d0d1004021210ic3676d9xbf8641c0f17bf5f5@mail.gmail.com>

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: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>

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: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>
References: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>
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:

<socinfo> "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: <g2n50a522ca1004080914w33f63fb7xdeb0300e611914b2@mail.gmail.com>

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 <arigo at tunes.org> 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: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>
References: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>
Message-ID: <o2ma0e09d0d1004081850q3f2e2c8ep950648a75d764fe9@mail.gmail.com>

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 <fijall at gmail.com> 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: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>
References: <x2u693bc9ab1004071730ia87b2bb2o2b2dc2fbbe181783@mail.gmail.com>
Message-ID: <h2q339296ce1004082114pf5ae29f2i4e213ac0f7a0b8d7@mail.gmail.com>

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" <fijall at gmail.com> 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: http://codespeak.net/pipermail/pypy-dev/attachments/20100408/c57b886f/attachment-0001.htm 

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: http://codespeak.net/pipermail/pypy-dev/attachments/20100409/10996294/attachment.htm 

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: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com>

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 "<string>", line 1, in <module>
  File "/home/ondrej/repos/sympy/sympy/__init__.py", line 43, in <module>
    from interactive import init_session, init_printing
  File "/home/ondrej/repos/sympy/sympy/interactive/__init__.py", line
5, in <module>
    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: <RuntimeError object at 0x868c778>




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: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com>
Message-ID: <o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com>

2010/4/10 Ondrej Certik <ondrej at certik.cz>:
> Hi,
Hi

> ? ?if hasattr(i, "__iter__"):
> RuntimeError: internal error: <RuntimeError object at 0x868c778>

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: <n2w1afaf6161004101220rf1114868l90fd20eb244ac01@mail.gmail.com>

2010/4/10 Renjie Xu <dustin.xu at 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?

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: <o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com>
	<o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com>
Message-ID: <s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com>

On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/4/10 Ondrej Certik <ondrej at certik.cz>:
>> Hi,
> Hi
>
>> ? ?if hasattr(i, "__iter__"):
>> RuntimeError: internal error: <RuntimeError object at 0x868c778>
>
> 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: <n2w1afaf6161004101220rf1114868l90fd20eb244ac01@mail.gmail.com>
References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com>
	<n2w1afaf6161004101220rf1114868l90fd20eb244ac01@mail.gmail.com>
Message-ID: <C255D094-B017-4F11-BDE2-C680697BBED3@gmail.com>

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 <dustin.xu at 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?
>
> 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: <C255D094-B017-4F11-BDE2-C680697BBED3@gmail.com>
References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com>
	<n2w1afaf6161004101220rf1114868l90fd20eb244ac01@mail.gmail.com>
	<C255D094-B017-4F11-BDE2-C680697BBED3@gmail.com>
Message-ID: <q2z1afaf6161004101332z49d03484r7d1714dfac3bd97f@mail.gmail.com>

2010/4/10 Renjie Xu <dustin.xu at gmail.com>:
> 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: <s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com> 
	<o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com> 
	<s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com>
Message-ID: <z2i693bc9ab1004112220nc9b52a02vc9990542373c5bf8@mail.gmail.com>

On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> 2010/4/10 Ondrej Certik <ondrej at certik.cz>:
>>> Hi,
>> Hi
>>
>>> ? ?if hasattr(i, "__iter__"):
>>> RuntimeError: internal error: <RuntimeError object at 0x868c778>
>>
>> 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: <z2i693bc9ab1004112220nc9b52a02vc9990542373c5bf8@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com> 
	<o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com> 
	<s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com> 
	<z2i693bc9ab1004112220nc9b52a02vc9990542373c5bf8@mail.gmail.com>
Message-ID: <n2k693bc9ab1004112222g4f770f25p51b70ecdc02dae2a@mail.gmail.com>

On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson <benjamin at python.org> wrote:
>>> 2010/4/10 Ondrej Certik <ondrej at certik.cz>:
>>>> Hi,
>>> Hi
>>>
>>>> ? ?if hasattr(i, "__iter__"):
>>>> RuntimeError: internal error: <RuntimeError object at 0x868c778>
>>>
>>> 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: <q2z1afaf6161004101332z49d03484r7d1714dfac3bd97f@mail.gmail.com>
References: <531B69FD-11F0-4089-B6C3-A914EA31549C@gmail.com> 
	<n2w1afaf6161004101220rf1114868l90fd20eb244ac01@mail.gmail.com> 
	<C255D094-B017-4F11-BDE2-C680697BBED3@gmail.com>
	<q2z1afaf6161004101332z49d03484r7d1714dfac3bd97f@mail.gmail.com>
Message-ID: <s2g693bc9ab1004112223q594c25f7ge115d77533f339ef@mail.gmail.com>

On Sat, Apr 10, 2010 at 2:32 PM, Benjamin Peterson <benjamin at python.org> wrote:
> 2010/4/10 Renjie Xu <dustin.xu at gmail.com>:
>> 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: <n2k693bc9ab1004112222g4f770f25p51b70ecdc02dae2a@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com>
	<o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com>
	<s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com>
	<z2i693bc9ab1004112220nc9b52a02vc9990542373c5bf8@mail.gmail.com>
	<n2k693bc9ab1004112222g4f770f25p51b70ecdc02dae2a@mail.gmail.com>
Message-ID: <m2r85b5c3131004112233p20eb7679nf77747da3f25d947@mail.gmail.com>

On Mon, Apr 12, 2010 at 6:22 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson <benjamin at python.org> wrote:
>>>> 2010/4/10 Ondrej Certik <ondrej at certik.cz>:
>>>>> Hi,
>>>> Hi
>>>>
>>>>> ? ?if hasattr(i, "__iter__"):
>>>>> RuntimeError: internal error: <RuntimeError object at 0x868c778>
>>>>
>>>> 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: <m2r85b5c3131004112233p20eb7679nf77747da3f25d947@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com> 
	<o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com> 
	<s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com> 
	<z2i693bc9ab1004112220nc9b52a02vc9990542373c5bf8@mail.gmail.com> 
	<n2k693bc9ab1004112222g4f770f25p51b70ecdc02dae2a@mail.gmail.com> 
	<m2r85b5c3131004112233p20eb7679nf77747da3f25d947@mail.gmail.com>
Message-ID: <x2g693bc9ab1004112244oabae3833n31a486c2579a60c1@mail.gmail.com>

On Sun, Apr 11, 2010 at 11:33 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> On Mon, Apr 12, 2010 at 6:22 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>>>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson <benjamin at python.org> wrote:
>>>>> 2010/4/10 Ondrej Certik <ondrej at certik.cz>:
>>>>>> Hi,
>>>>> Hi
>>>>>
>>>>>> ? ?if hasattr(i, "__iter__"):
>>>>>> RuntimeError: internal error: <RuntimeError object at 0x868c778>
>>>>>
>>>>> 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: <x2g693bc9ab1004112244oabae3833n31a486c2579a60c1@mail.gmail.com>
References: <i2y85b5c3131004100945j4ff9e8bfna82fccc23bc0120b@mail.gmail.com> 
	<o2w1afaf6161004101157q2b8b5684v61b14074068a8bdf@mail.gmail.com> 
	<s2z85b5c3131004101225l2a777861s60f9bfa178b2a0a@mail.gmail.com> 
	<z2i693bc9ab1004112220nc9b52a02vc9990542373c5bf8@mail.gmail.com> 
	<n2k693bc9ab1004112222g4f770f25p51b70ecdc02dae2a@mail.gmail.com> 
	<m2r85b5c3131004112233p20eb7679nf77747da3f25d947@mail.gmail.com> 
	<x2g693bc9ab1004112244oabae3833n31a486c2579a60c1@mail.gmail.com>
Message-ID: <o2h693bc9ab1004112245x4ed8b8feg4d25606640989dd6@mail.gmail.com>

On Sun, Apr 11, 2010 at 11:44 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Sun, Apr 11, 2010 at 11:33 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>> On Mon, Apr 12, 2010 at 6:22 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>> On Sun, Apr 11, 2010 at 11:20 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>>> On Sat, Apr 10, 2010 at 1:25 PM, Ondrej Certik <ondrej at certik.cz> wrote:
>>>>> On Sat, Apr 10, 2010 at 11:57 AM, Benjamin Peterson <benjamin at python.org> wrote:
>>>>>> 2010/4/10 Ondrej Certik <ondrej at certik.cz>:
>>>>>>> Hi,
>>>>>> Hi
>>>>>>
>>>>>>> ? ?if hasattr(i, "__iter__"):
>>>>>>> RuntimeError: internal error: <RuntimeError object at 0x868c778>
>>>>>>
>>>>>> 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: <j2n64ddb72c1004120720s640c999dm96cc99207f1f6254@mail.gmail.com>

On Sat, Apr 10, 2010 at 12:46 PM, Carl Friedrich Bolz <cfbolz at gmx.de> 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: http://codespeak.net/pipermail/pypy-dev/attachments/20100412/9bd3f54c/attachment.htm 

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: <j2n64ddb72c1004120720s640c999dm96cc99207f1f6254@mail.gmail.com>
References: <4BC0650D.4030209@gmx.de>
	<j2n64ddb72c1004120720s640c999dm96cc99207f1f6254@mail.gmail.com>
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: <s2o693bc9ab1004112318ue84f1a03v62a932bf1272e439@mail.gmail.com>
References: <20100410150756.60AD7282BAD@codespeak.net>
	<s2o693bc9ab1004112318ue84f1a03v62a932bf1272e439@mail.gmail.com>
Message-ID: <k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com>

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>
	<j2n64ddb72c1004120720s640c999dm96cc99207f1f6254@mail.gmail.com>
	<4BC32F93.4020108@gmx.de>
Message-ID: <o2q64ddb72c1004121000n9562cb36l5bdb00a0c41de48d@mail.gmail.com>

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: http://codespeak.net/pipermail/pypy-dev/attachments/20100412/f63507f4/attachment.htm 

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: <o2q64ddb72c1004121000n9562cb36l5bdb00a0c41de48d@mail.gmail.com>
References: <4BC0650D.4030209@gmx.de>
	<j2n64ddb72c1004120720s640c999dm96cc99207f1f6254@mail.gmail.com>
	<4BC32F93.4020108@gmx.de>
	<o2q64ddb72c1004121000n9562cb36l5bdb00a0c41de48d@mail.gmail.com>
Message-ID: <y2n693bc9ab1004121003hc3c71cb9k498e5cc826a93131@mail.gmail.com>

On Mon, Apr 12, 2010 at 11:00 AM, Ren? Dudfield <renesd at gmail.com> 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: <p2p693bc9ab1004121018u1b2f650ch2667a4dd39cb857f@mail.gmail.com>

Why? I think we do support that.

On Sat, Apr 10, 2010 at 8:31 AM,  <jandem at codespeak.net> 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: <k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com>
References: <20100410150756.60AD7282BAD@codespeak.net>	<s2o693bc9ab1004112318ue84f1a03v62a932bf1272e439@mail.gmail.com>
	<k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com>
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>
	<s2o693bc9ab1004112318ue84f1a03v62a932bf1272e439@mail.gmail.com>
	<k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com> 
	<4BC357E2.8090504@gmail.com>
Message-ID: <j2k693bc9ab1004121218p7935afc2idda64d34e6dcba40@mail.gmail.com>

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 <anto.cuni at gmail.com> 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: <k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com>
References: <20100410150756.60AD7282BAD@codespeak.net>
	<s2o693bc9ab1004112318ue84f1a03v62a932bf1272e439@mail.gmail.com>
	<k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com>
Message-ID: <n2xf25439871004121322ud45c2de5n822202892cc43f0c@mail.gmail.com>

Hi fijal,

On Mon, Apr 12, 2010 at 6:15 PM, Maciej Fijalkowski <fijall at gmail.com> 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: <p2p693bc9ab1004121018u1b2f650ch2667a4dd39cb857f@mail.gmail.com>
References: <20100410143123.D8EB1282BAD@codespeak.net>
	<p2p693bc9ab1004121018u1b2f650ch2667a4dd39cb857f@mail.gmail.com>
Message-ID: <q2sf25439871004121329s4c23d4cfxe1fa45e8e2c00e62@mail.gmail.com>

On Mon, Apr 12, 2010 at 7:18 PM, Maciej Fijalkowski <fijall at gmail.com> 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, ?<jandem at codespeak.net> 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: <q2sf25439871004121329s4c23d4cfxe1fa45e8e2c00e62@mail.gmail.com>
References: <20100410143123.D8EB1282BAD@codespeak.net>
	<p2p693bc9ab1004121018u1b2f650ch2667a4dd39cb857f@mail.gmail.com>
	<q2sf25439871004121329s4c23d4cfxe1fa45e8e2c00e62@mail.gmail.com>
Message-ID: <i2j693bc9ab1004121354w4e64183elfb9d6157caeec9d0@mail.gmail.com>

On Mon, Apr 12, 2010 at 2:29 PM, Jan de Mooij <jandemooij at gmail.com> wrote:
> On Mon, Apr 12, 2010 at 7:18 PM, Maciej Fijalkowski <fijall at gmail.com> 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, ?<jandem at codespeak.net> 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: <n2xf25439871004121322ud45c2de5n822202892cc43f0c@mail.gmail.com>
References: <20100410150756.60AD7282BAD@codespeak.net>
	<s2o693bc9ab1004112318ue84f1a03v62a932bf1272e439@mail.gmail.com>
	<k2w693bc9ab1004120915q7e61a4c7v83e8e0bd26854515@mail.gmail.com> 
	<n2xf25439871004121322ud45c2de5n822202892cc43f0c@mail.gmail.com>
Message-ID: <g2z693bc9ab1004121355qe5fb72f0ye1fc348ba2885817@mail.gmail.com>

Sounds reasonable to me.

On Mon, Apr 12, 2010 at 2:22 PM, Jan de Mooij <jandemooij at gmail.com> wrote:
> Hi fijal,
>
> On Mon, Apr 12, 2010 at 6:15 PM, Maciej Fijalkowski <fijall at gmail.com> 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>
	<p2p693bc9ab1004121018u1b2f650ch2667a4dd39cb857f@mail.gmail.com>
	<q2sf25439871004121329s4c23d4cfxe1fa45e8e2c00e62@mail.gmail.com>
	<i2j693bc9ab1004121354w4e64183elfb9d6157caeec9d0@mail.gmail.com>
Message-ID: <slrnhs74r8.c1r.2008a@tuxpaddy.alexanderweb.homeip.net>

On Mon, 12 Apr 2010 14:54:06 -0600, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Mon, Apr 12, 2010 at 2:29 PM, Jan de Mooij <jandemooij at gmail.com> wrote:
>> On Mon, Apr 12, 2010 at 7:18 PM, Maciej Fijalkowski <fijall at gmail.com> 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: <y2r693bc9ab1004132138w2a8d38a4y5908a952fe0c1be6@mail.gmail.com>

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: <y2u6f4025011004140459q6664c8aaxbe2e4210b4129f4b@mail.gmail.com>

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 <holger at merlinux.eu> 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: http://codespeak.net/pipermail/pypy-dev/attachments/20100414/f57ab33f/attachment.htm 

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: <z2h1afaf6161004181913ve40e9305mcdd90666e89fa4ab@mail.gmail.com>

2010/4/18 Terrence Cole <list-sink at trainedmonkeystudios.org>:
> 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: <z2h1afaf6161004181913ve40e9305mcdd90666e89fa4ab@mail.gmail.com>
References: <1271640671.26181.19.camel@localhost>
	<z2h1afaf6161004181913ve40e9305mcdd90666e89fa4ab@mail.gmail.com>
Message-ID: <1271644938.26181.78.camel@localhost>

On Sun, 2010-04-18 at 21:13 -0500, Benjamin Peterson wrote:
> 2010/4/18 Terrence Cole <list-sink at trainedmonkeystudios.org>:
> > 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: <hqhkt1$7n4$1@dough.gmane.org>

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: <hqhkt1$7n4$1@dough.gmane.org>
References: <hqhkt1$7n4$1@dough.gmane.org>
Message-ID: <i2le27efe131004190904w674692d3u7ad551d46ae182c0@mail.gmail.com>

Hello,

2010/4/19 Neal Becker <ndbecker2 at gmail.com>:
> 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: <x2lc561346d1004201014t912bceeah90c3c4e465062afd@mail.gmail.com>

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: http://codespeak.net/pipermail/pypy-dev/attachments/20100420/f9f2ba28/attachment.htm 

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: <x2lc561346d1004201014t912bceeah90c3c4e465062afd@mail.gmail.com>
References: <x2lc561346d1004201014t912bceeah90c3c4e465062afd@mail.gmail.com>
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: <x2lc561346d1004201014t912bceeah90c3c4e465062afd@mail.gmail.com> 
	<4BCDF288.8070901@gmx.de>
Message-ID: <q2w693bc9ab1004201141z4676fb3ewf65ea434d14fe48b@mail.gmail.com>

Hi Carl, Hi Miquel.

Cool job!

On Tue, Apr 20, 2010 at 12:29 PM, Carl Friedrich Bolz <cfbolz at gmx.de> 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: <q2w693bc9ab1004201141z4676fb3ewf65ea434d14fe48b@mail.gmail.com>
References: <x2lc561346d1004201014t912bceeah90c3c4e465062afd@mail.gmail.com>
	<4BCDF288.8070901@gmx.de>
	<q2w693bc9ab1004201141z4676fb3ewf65ea434d14fe48b@mail.gmail.com>
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: <q2w693bc9ab1004201141z4676fb3ewf65ea434d14fe48b@mail.gmail.com>
References: <x2lc561346d1004201014t912bceeah90c3c4e465062afd@mail.gmail.com>
	<4BCDF288.8070901@gmx.de>
	<q2w693bc9ab1004201141z4676fb3ewf65ea434d14fe48b@mail.gmail.com>
Message-ID: <q2mc561346d1004201150ub431e269q8f14b3a194d4cce1@mail.gmail.com>

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 <fijall at gmail.com>

> Hi Carl, Hi Miquel.
>
> Cool job!
>
> On Tue, Apr 20, 2010 at 12:29 PM, Carl Friedrich Bolz <cfbolz at gmx.de>
> 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: http://codespeak.net/pipermail/pypy-dev/attachments/20100420/11480d35/attachment.htm 

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: http://codespeak.net/pipermail/pypy-dev/attachments/20100421/e3bd386b/attachment-0001.htm 

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: <z2o693bc9ab1004210810o101544afp4f9cbe7d6614ae9d@mail.gmail.com>

Bah.

I think fixed, will try later.

2010/4/21 S?ren Laursen <sl at scrooge.dk>:
> 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: <RuntimeError object at 0x872e798>

[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: http://codespeak.net/pipermail/pypy-dev/attachments/20100425/d1a19ee8/attachment.htm 

From fijall at gmail.com  Wed May  5 03:59:17 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 4 May 2010 19:59:17 -0600
Subject: [pypy-dev] recent speed results
Message-ID: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>

Anyone has any clue where recent noise comes from? I could not
pinpoint any single revision.

From arigo at tunes.org  Thu May  6 13:05:50 2010
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 6 May 2010 13:05:50 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
Message-ID: <20100506110550.GA13412@code0.codespeak.net>

Hi,

On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
> Anyone has any clue where recent noise comes from? I could not
> pinpoint any single revision.

That really looks like some external factor, e.g. the machine is
overloaded.  Maybe we should move benchmarking to tannit.  It would mean
that the results cannot be followed across the move, but at least tannit
is a non-virtual machine on which we can ensure some consistent total
usage.

The drawback of picking tannit is that it's unclear what will occur to
it after the end of the current funding period.  Other choices have
other drawbacks -- e.g. wyvern is old (and not representative of today's
performance) and might die unexpectedly any year now.


A bientot,

Armin.

From tobami at googlemail.com  Thu May  6 14:08:51 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Thu, 6 May 2010 14:08:51 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <20100506110550.GA13412@code0.codespeak.net>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
	<20100506110550.GA13412@code0.codespeak.net>
Message-ID: <j2rc561346d1005060508rd3b21ef7x5714ad2556541bfb@mail.gmail.com>

Yeah, I would tend to agree with Armin, it does seem to be the VM.
Mmmh,  std dev does double compared to previous results, but it is still not
that huge.

Moving to a non-VM machine would be a bit plus IMHO.

Cheers,
Miquel


2010/5/6 Armin Rigo <arigo at tunes.org>

> Hi,
>
> On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
> > Anyone has any clue where recent noise comes from? I could not
> > pinpoint any single revision.
>
> That really looks like some external factor, e.g. the machine is
> overloaded.  Maybe we should move benchmarking to tannit.  It would mean
> that the results cannot be followed across the move, but at least tannit
> is a non-virtual machine on which we can ensure some consistent total
> usage.
>
> The drawback of picking tannit is that it's unclear what will occur to
> it after the end of the current funding period.  Other choices have
> other drawbacks -- e.g. wyvern is old (and not representative of today's
> performance) and might die unexpectedly any year now.
>
>
> A bientot,
>
> Armin.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100506/02525ae4/attachment.htm 

From exarkun at twistedmatrix.com  Thu May  6 15:51:31 2010
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Thu, 06 May 2010 13:51:31 -0000
Subject: [pypy-dev] recent speed results
In-Reply-To: <20100506110550.GA13412@code0.codespeak.net>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
	<20100506110550.GA13412@code0.codespeak.net>
Message-ID: <20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>

On 11:05 am, arigo at tunes.org wrote:
>Hi,
>
>On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
>>Anyone has any clue where recent noise comes from? I could not
>>pinpoint any single revision.
>
>That really looks like some external factor, e.g. the machine is
>overloaded.  Maybe we should move benchmarking to tannit.  It would 
>mean
>that the results cannot be followed across the move, but at least 
>tannit
>is a non-virtual machine on which we can ensure some consistent total
>usage.
>
>The drawback of picking tannit is that it's unclear what will occur to
>it after the end of the current funding period.  Other choices have
>other drawbacks -- e.g. wyvern is old (and not representative of 
>today's
>performance) and might die unexpectedly any year now.

What else is on the machine that's causing it to be overloaded now?

I'd suggest temporarily disabling or moving all of that first, getting a 
few benchmark runs that show there hasn't been a performance regression, 
and then considering moving the benchmarks to a new machine.  Otherwise 
if there has been a performance regression, the move will just hide it.

Jean-Paul

From arigo at tunes.org  Thu May  6 22:00:34 2010
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 6 May 2010 22:00:34 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
	<20100506110550.GA13412@code0.codespeak.net>
	<20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
Message-ID: <20100506200034.GA19308@code0.codespeak.net>

Hi,

On Thu, May 06, 2010 at 01:51:31PM -0000, exarkun at twistedmatrix.com wrote:
> What else is on the machine that's causing it to be overloaded now?

Hard to know: it's a virtual machine.  You would have to ask bigdog if
he has a clue about what has been running extra since a few days.  My
guess is that it's hard to know, unless maybe Maciek can be around and
monitor the various virtual machines when the benchmarking runs (between
7:29am and 9:08am CET roughly -- looks a bit late at night for him, and
a bit early in the morning for me...).


A bientot,

Armin.

From sl at scrooge.dk  Thu May  6 22:10:54 2010
From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=)
Date: Thu, 6 May 2010 22:10:54 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <20100506200034.GA19308@code0.codespeak.net>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>	
	<20100506110550.GA13412@code0.codespeak.net>	<20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
	<20100506200034.GA19308@code0.codespeak.net>
Message-ID: <d67048e3b9f0b9b822f78ce2b4d00fe3@mail.gmail.com>

Hi,

I do administrate a few vm based on VMWare ESX4i.

A few of them, random, blows out with a load around 30, and start to hit
the OOM killer. After 20-30 minutes everything settles down to normal.

Not a clue about what going on. All the servers are more or less the samme
32/64bit debian installations.

Regards

S?ren

-----Oprindelig meddelelse-----
Fra: pypy-dev-bounces at codespeak.net
[mailto:pypy-dev-bounces at codespeak.net] P? vegne af Armin Rigo
Sendt: 6. maj 2010 22:01
Til: exarkun at twistedmatrix.com
Cc: PyPy Dev
Emne: Re: [pypy-dev] recent speed results

Hi,

On Thu, May 06, 2010 at 01:51:31PM -0000, exarkun at twistedmatrix.com wrote:
> What else is on the machine that's causing it to be overloaded now?

Hard to know: it's a virtual machine.  You would have to ask bigdog if
he has a clue about what has been running extra since a few days.  My
guess is that it's hard to know, unless maybe Maciek can be around and
monitor the various virtual machines when the benchmarking runs (between
7:29am and 9:08am CET roughly -- looks a bit late at night for him, and
a bit early in the morning for me...).


A bientot,

Armin.
_______________________________________________
pypy-dev at codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

From zejn at kiberpipa.org  Thu May  6 22:50:50 2010
From: zejn at kiberpipa.org (Gasper Zejn)
Date: Thu, 6 May 2010 22:50:50 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <j2rc561346d1005060508rd3b21ef7x5714ad2556541bfb@mail.gmail.com>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
	<20100506110550.GA13412@code0.codespeak.net>
	<j2rc561346d1005060508rd3b21ef7x5714ad2556541bfb@mail.gmail.com>
Message-ID: <201005062250.50384.zejn@kiberpipa.org>

I think moving to a non-VM is the only option. In a company where I used to 
work we had similar problems. All of the virtualization solutions' clocks just 
keep drifting back and forth and no useful performance data could be gathered 
unless the execution time was really long.

Kr,
Ga?per

On Thursday 06 May 2010 14:08:51 Miquel Torres wrote:
> Yeah, I would tend to agree with Armin, it does seem to be the VM.
> Mmmh,  std dev does double compared to previous results, but it is still
> not that huge.
> 
> Moving to a non-VM machine would be a bit plus IMHO.
> 
> Cheers,
> Miquel
> 
> 
> 2010/5/6 Armin Rigo <arigo at tunes.org>
> 
> > Hi,
> > 
> > On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
> > > Anyone has any clue where recent noise comes from? I could not
> > > pinpoint any single revision.
> > 
> > That really looks like some external factor, e.g. the machine is
> > overloaded.  Maybe we should move benchmarking to tannit.  It would mean
> > that the results cannot be followed across the move, but at least tannit
> > is a non-virtual machine on which we can ensure some consistent total
> > usage.
> > 
> > The drawback of picking tannit is that it's unclear what will occur to
> > it after the end of the current funding period.  Other choices have
> > other drawbacks -- e.g. wyvern is old (and not representative of today's
> > performance) and might die unexpectedly any year now.
> > 
> > 
> > A bientot,
> > 
> > Armin.
> > _______________________________________________
> > pypy-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/pypy-dev

From fijall at gmail.com  Thu May  6 23:51:59 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 6 May 2010 15:51:59 -0600
Subject: [pypy-dev] recent speed results
In-Reply-To: <20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com> 
	<20100506110550.GA13412@code0.codespeak.net>
	<20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
Message-ID: <r2n693bc9ab1005061451x417feaceg3c908483227cba12@mail.gmail.com>

I looked at svn log, and the only coincidence I can find is upgrade of ubuntu.

On Thu, May 6, 2010 at 7:51 AM,  <exarkun at twistedmatrix.com> wrote:
> On 11:05 am, arigo at tunes.org wrote:
>>
>> Hi,
>>
>> On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
>>>
>>> Anyone has any clue where recent noise comes from? I could not
>>> pinpoint any single revision.
>>
>> That really looks like some external factor, e.g. the machine is
>> overloaded. ?Maybe we should move benchmarking to tannit. ?It would mean
>> that the results cannot be followed across the move, but at least tannit
>> is a non-virtual machine on which we can ensure some consistent total
>> usage.
>>
>> The drawback of picking tannit is that it's unclear what will occur to
>> it after the end of the current funding period. ?Other choices have
>> other drawbacks -- e.g. wyvern is old (and not representative of today's
>> performance) and might die unexpectedly any year now.
>
> What else is on the machine that's causing it to be overloaded now?
>
> I'd suggest temporarily disabling or moving all of that first, getting a few
> benchmark runs that show there hasn't been a performance regression, and
> then considering moving the benchmarks to a new machine. ?Otherwise if there
> has been a performance regression, the move will just hide it.
>
> Jean-Paul
>

From shadrin at yandex-team.ru  Tue May 11 14:08:53 2010
From: shadrin at yandex-team.ru (Shadrin Eugene)
Date: Tue, 11 May 2010 16:08:53 +0400
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <4BE9455E.9070600@yandex-team.ru>
References: <4BE9455E.9070600@yandex-team.ru>
Message-ID: <4BE948D5.1080700@yandex-team.ru>

Hi!

I tryed to build pypy on the freebsd, 64bit platform, but failed.

First of all I downloaded a 32bit-Python to run pypy.
And then:

[user at server_name ~/pypy-trunk/pypy/translator/goal]$ ~/py32/bin/python 
translate.py -Ojit
[translation:info] Translating target as defined by targetpypystandalone
[platform:execute] gcc -m32 -c -O3 -pthread -fomit-frame-pointer 
/var/tmp/usession-trunk-22/gcctest.c -o 
/var/tmp/usession-trunk-22/gcctest.o
[platform:WARNING] /var/tmp/usession-trunk-22/gcctest.c:28:2: warning: 
no newline at end of file
[platform:execute] gcc -m32 /var/tmp/usession-trunk-22/gcctest.o 
-L/lib32 -L/usr/lib32 -L`pwd`/lib32 -Wl,-rpath,/lib32 
-Wl,-rpath,/usr/lib32 -pthread -o /var/tmp/usession-trunk-22/gcctest
printf("sizeof short=%ld\n", (long)sizeof(short));
         printf("sizeof unsigned short=%ld\n", (long)sizeof(unsigned 
short));
         printf("sizeof int=%ld\n", (long)sizeof(int));
         printf("sizeof unsigned int=%ld\n", (long)sizeof(unsigned int));
         printf("sizeof long=%ld\n", (long)sizeof(long));
         printf("sizeof unsigned long=%ld\n", (long)sizeof(unsigned long));
         printf("sizeof signed char=%ld\n", (long)sizeof(signed char));
         printf("sizeof unsigned char=%ld\n", (long)sizeof(unsigned char));
         printf("sizeof long long=%ld\n", (long)sizeof(long long));
         printf("sizeof unsigned long long=%ld\n", (long)sizeof(unsigned 
long long));
         printf("sizeof size_t=%ld\n", (long)sizeof(size_t));
         printf("sizeof time_t=%ld\n", (long)sizeof(time_t));
         printf("sizeof wchar_t=%ld\n", (long)sizeof(wchar_t));
         printf("sizeof mode_t=%ld\n", (long)sizeof(mode_t));
         printf("sizeof pid_t=%ld\n", (long)sizeof(pid_t));
sizeof short=2
sizeof unsigned short=2
sizeof int=4
sizeof unsigned int=4
sizeof long=8
sizeof unsigned long=8
sizeof signed char=1
sizeof unsigned char=1
sizeof long long=8
sizeof unsigned long long=8
sizeof size_t=8
sizeof time_t=8
sizeof wchar_t=4
sizeof mode_t=2
sizeof pid_t=4

Traceback (most recent call last):
   File "translate.py", line 300, in <module>
     main()
   File "translate.py", line 205, in main
     targetspec_dic, translateconfig, config, args = 
parse_options_and_load_target()
   File "translate.py", line 153, in parse_options_and_load_target
     targetspec_dic = load_target(targetspec)
   File "translate.py", line 105, in load_target
     mod = __import__(specname)
   File "targetpypystandalone.py", line 5, in <module>
     from pypy.objspace.std.objspace import StdObjSpace
   File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/__init__.py", 
line 1, in <module>
     from pypy.objspace.std.objspace import StdObjSpace
   File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/objspace.py", 
line 3, in <module>
     from pypy.interpreter import pyframe, function, special
   File "/place/home/hitrobot/pypy-trunk/pypy/interpreter/pyframe.py", 
line 13, in <module>
     from pypy.rlib import jit, rstack
   File "/place/home/hitrobot/pypy-trunk/pypy/rlib/rstack.py", line 10, 
in <module>
     from pypy.rpython.lltypesystem import rffi, lltype
   File 
"/place/home/hitrobot/pypy-trunk/pypy/rpython/lltypesystem/rffi.py", 
line 824, in <module>
     sys.maxint, sizeof(lltype.Signed)))
AssertionError: Mixed configuration of the word size of the machine:
         the underlying Python was compiled with maxint=2147483647,
         but the C compiler says that 'long' is 8 bytes


I got this error, then I added "-m32" flag to gcc argument list (in the 
posix.py source file) , but error occured again :(
Does anybody tryed to build pypy-c on the 64bit FreeBsd?

Thank you for your answer!

-- 
Shadrin Eugene


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100511/a3ca1d80/attachment.htm 

From p.giarrusso at gmail.com  Tue May 11 18:38:09 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Tue, 11 May 2010 18:38:09 +0200
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <4BE948D5.1080700@yandex-team.ru>
References: <4BE9455E.9070600@yandex-team.ru> <4BE948D5.1080700@yandex-team.ru>
Message-ID: <AANLkTimm07OI2iagbJ-vnTk8MrrjX62sUQMI0S-YXkfp@mail.gmail.com>

On Tue, May 11, 2010 at 14:08, Shadrin Eugene <shadrin at yandex-team.ru> wrote:
> Hi!
>
> I tryed to build pypy on the freebsd, 64bit platform, but failed.
>
> First of all I downloaded a 32bit-Python to run pypy.
> And then:
>
> [user at server_name ~/pypy-trunk/pypy/translator/goal]$ ~/py32/bin/python
> translate.py -Ojit
> [translation:info] Translating target as defined by targetpypystandalone
> [platform:execute] gcc -m32 -c -O3 -pthread -fomit-frame-pointer
> /var/tmp/usession-trunk-22/gcctest.c -o /var/tmp/usession-trunk-22/gcctest.o
> [platform:WARNING] /var/tmp/usession-trunk-22/gcctest.c:28:2: warning: no
> newline at end of file
> [platform:execute] gcc -m32 /var/tmp/usession-trunk-22/gcctest.o -L/lib32
> -L/usr/lib32 -L`pwd`/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 -pthread
> -o /var/tmp/usession-trunk-22/gcctest
> printf("sizeof short=%ld\n", (long)sizeof(short));
> ??????? printf("sizeof unsigned short=%ld\n", (long)sizeof(unsigned short));
> ??????? printf("sizeof int=%ld\n", (long)sizeof(int));
> ??????? printf("sizeof unsigned int=%ld\n", (long)sizeof(unsigned int));
> ??????? printf("sizeof long=%ld\n", (long)sizeof(long));
> ??????? printf("sizeof unsigned long=%ld\n", (long)sizeof(unsigned long));
> ??????? printf("sizeof signed char=%ld\n", (long)sizeof(signed char));
> ??????? printf("sizeof unsigned char=%ld\n", (long)sizeof(unsigned char));
> ??????? printf("sizeof long long=%ld\n", (long)sizeof(long long));
> ??????? printf("sizeof unsigned long long=%ld\n", (long)sizeof(unsigned long
> long));
> ??????? printf("sizeof size_t=%ld\n", (long)sizeof(size_t));
> ??????? printf("sizeof time_t=%ld\n", (long)sizeof(time_t));
> ??????? printf("sizeof wchar_t=%ld\n", (long)sizeof(wchar_t));
> ??????? printf("sizeof mode_t=%ld\n", (long)sizeof(mode_t));
> ??????? printf("sizeof pid_t=%ld\n", (long)sizeof(pid_t));
> sizeof short=2
> sizeof unsigned short=2
> sizeof int=4
> sizeof unsigned int=4
> sizeof long=8
> sizeof unsigned long=8
> sizeof signed char=1
> sizeof unsigned char=1
> sizeof long long=8
> sizeof unsigned long long=8
> sizeof size_t=8
> sizeof time_t=8
> sizeof wchar_t=4
> sizeof mode_t=2
> sizeof pid_t=4
>
> Traceback (most recent call last):
> ? File "translate.py", line 300, in <module>
> ??? main()
> ? File "translate.py", line 205, in main
> ??? targetspec_dic, translateconfig, config, args =
> parse_options_and_load_target()
> ? File "translate.py", line 153, in parse_options_and_load_target
> ??? targetspec_dic = load_target(targetspec)
> ? File "translate.py", line 105, in load_target
> ??? mod = __import__(specname)
> ? File "targetpypystandalone.py", line 5, in <module>
> ??? from pypy.objspace.std.objspace import StdObjSpace
> ? File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/__init__.py", line
> 1, in <module>
> ??? from pypy.objspace.std.objspace import StdObjSpace
> ? File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/objspace.py", line
> 3, in <module>
> ??? from pypy.interpreter import pyframe, function, special
> ? File "/place/home/hitrobot/pypy-trunk/pypy/interpreter/pyframe.py", line
> 13, in <module>
> ??? from pypy.rlib import jit, rstack
> ? File "/place/home/hitrobot/pypy-trunk/pypy/rlib/rstack.py", line 10, in
> <module>
> ??? from pypy.rpython.lltypesystem import rffi, lltype
> ? File "/place/home/hitrobot/pypy-trunk/pypy/rpython/lltypesystem/rffi.py",
> line 824, in <module>
> ??? sys.maxint, sizeof(lltype.Signed)))
> AssertionError: Mixed configuration of the word size of the machine:
> ??????? the underlying Python was compiled with maxint=2147483647,
> ??????? but the C compiler says that 'long' is 8 bytes
>
>
> I got this error, then I added "-m32" flag to gcc argument list (in the
> posix.py source file) , but error occured again :(

Your fix was reasonably correct, and the printed command line shows an
-m32 flag passed to gcc, however the subsequent program listing still
says that sizeof(long) is 8 bytes. I'm assuming that the program
getting executed is the one compiled there (gcctest), can you please
verify?
I just double-checked that this result is unreasonable here on Linux
64bit (Ubuntu Karmic 9.10):

$ cat sizeof-long.c
#include <stdio.h>
int main(void) {
    printf("sizeof(long): %zd\n", sizeof(long));
    return 0;
}
$ gcc -m32    sizeof-long.c   -o sizeof-long
$ ./sizeof-long
sizeof(long): 4

That's what you need to get (i.e. sizeof(long) == 4 rather than 8).
Once you get it, you can fix the above error. I rechecked the above
messages, there's nothing strange. Maybe you have some gcc wrapper
silently forcing -m64 on the cmd line?

> Does anybody tryed to build pypy-c on the 64bit FreeBsd?
I didn't myself.
-- 
Paolo Giarrusso

From santagada at gmail.com  Tue May 11 19:31:53 2010
From: santagada at gmail.com (Leonardo Santagada)
Date: Tue, 11 May 2010 14:31:53 -0300
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <4BE948D5.1080700@yandex-team.ru>
References: <4BE9455E.9070600@yandex-team.ru> <4BE948D5.1080700@yandex-team.ru>
Message-ID: <FDAEDD80-889F-429F-BE50-5BD424D7D361@gmail.com>

On May 11, 2010, at 9:08 AM, Shadrin Eugene wrote:
> Hi! 
> 
> I tryed to build pypy on the freebsd, 64bit platform, but failed. 
> 
> First of all I downloaded a 32bit-Python to run pypy.

You need a 64 bit python to translate a 64bit pypy, so use a 64 bit cpython that comes with freebsd if you want to do the translation.

And remember, the JIT is 32bit only for now.

--
Leonardo Santagada
santagada at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100511/237451b9/attachment.htm 

From p.giarrusso at gmail.com  Tue May 11 19:35:28 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Tue, 11 May 2010 19:35:28 +0200
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <FDAEDD80-889F-429F-BE50-5BD424D7D361@gmail.com>
References: <4BE9455E.9070600@yandex-team.ru>
	<4BE948D5.1080700@yandex-team.ru> 
	<FDAEDD80-889F-429F-BE50-5BD424D7D361@gmail.com>
Message-ID: <AANLkTik7cjRBhDmUWhPx0E3Tt1OBarVD4egRdJUw9a8b@mail.gmail.com>

On Tue, May 11, 2010 at 19:31, Leonardo Santagada <santagada at gmail.com> wrote:
> On May 11, 2010, at 9:08 AM, Shadrin Eugene wrote:
>
> Hi!
>
> I tryed to build pypy on the freebsd, 64bit platform, but failed.
>
> First of all I downloaded a 32bit-Python to run pypy.
>
> You need a 64 bit python to translate a 64bit pypy, so use a 64 bit cpython
> that comes with freebsd if you want to do the translation.
> And remember, the JIT is 32bit only for now.
But can't one build, that way, a 32bit PyPy on a 64bit platform (to
use the JIT)? I remember seeing directions to use a 32bit Python on
the website.
-- 
Paolo Giarrusso

From fijall at gmail.com  Tue May 11 19:52:52 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 11 May 2010 11:52:52 -0600
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <AANLkTik7cjRBhDmUWhPx0E3Tt1OBarVD4egRdJUw9a8b@mail.gmail.com>
References: <4BE9455E.9070600@yandex-team.ru>
	<4BE948D5.1080700@yandex-team.ru> 
	<FDAEDD80-889F-429F-BE50-5BD424D7D361@gmail.com>
	<AANLkTik7cjRBhDmUWhPx0E3Tt1OBarVD4egRdJUw9a8b@mail.gmail.com>
Message-ID: <AANLkTikQVEszh0ToRaWYxrG5X4SctWSxtF1C5Wdp6G1i@mail.gmail.com>

On Tue, May 11, 2010 at 11:35 AM, Paolo Giarrusso <p.giarrusso at gmail.com> wrote:
> On Tue, May 11, 2010 at 19:31, Leonardo Santagada <santagada at gmail.com> wrote:
>> On May 11, 2010, at 9:08 AM, Shadrin Eugene wrote:
>>
>> Hi!
>>
>> I tryed to build pypy on the freebsd, 64bit platform, but failed.
>>
>> First of all I downloaded a 32bit-Python to run pypy.
>>
>> You need a 64 bit python to translate a 64bit pypy, so use a 64 bit cpython
>> that comes with freebsd if you want to do the translation.
>> And remember, the JIT is 32bit only for now.
> But can't one build, that way, a 32bit PyPy on a 64bit platform (to
> use the JIT)? I remember seeing directions to use a 32bit Python on
> the website.

Yes, that's the way.

From santagada at gmail.com  Tue May 11 19:49:15 2010
From: santagada at gmail.com (Leonardo Santagada)
Date: Tue, 11 May 2010 14:49:15 -0300
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <AANLkTik7cjRBhDmUWhPx0E3Tt1OBarVD4egRdJUw9a8b@mail.gmail.com>
References: <4BE9455E.9070600@yandex-team.ru> <4BE948D5.1080700@yandex-team.ru>
	<FDAEDD80-889F-429F-BE50-5BD424D7D361@gmail.com>
	<AANLkTik7cjRBhDmUWhPx0E3Tt1OBarVD4egRdJUw9a8b@mail.gmail.com>
Message-ID: <03FFF47E-E2D9-4D9B-A8CF-D0027AD1DC36@gmail.com>


On May 11, 2010, at 2:35 PM, Paolo Giarrusso wrote:

> On Tue, May 11, 2010 at 19:31, Leonardo Santagada <santagada at gmail.com> wrote:
>> On May 11, 2010, at 9:08 AM, Shadrin Eugene wrote:
>> 
>> Hi!
>> 
>> I tryed to build pypy on the freebsd, 64bit platform, but failed.
>> 
>> First of all I downloaded a 32bit-Python to run pypy.
>> 
>> You need a 64 bit python to translate a 64bit pypy, so use a 64 bit cpython
>> that comes with freebsd if you want to do the translation.
>> And remember, the JIT is 32bit only for now.
> But can't one build, that way, a 32bit PyPy on a 64bit platform (to
> use the JIT)? I remember seeing directions to use a 32bit Python on
> the website.
> -- 
> Paolo Giarrusso

Ahh I didn't understod that the poster wanted a 32 bit pypy.

If that is the case then you need to do all that is necessary to compile 32 bit binaries in your system. I don't know how that works in freebsd but it can involve having another compiler, a 32bit python, and a ton o 32bit libraries (maybe even a 32bit chroot). I found this on google but seems pretty old:

http://lists.freebsd.org/pipermail/freebsd-amd64/2007-November/010466.html

[]'s

--
Leonardo Santagada
santagada at gmail.com




From camillobruni at gmail.com  Tue May 11 23:22:04 2010
From: camillobruni at gmail.com (Camillo Bruni)
Date: Tue, 11 May 2010 23:22:04 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <r2n693bc9ab1005061451x417feaceg3c908483227cba12@mail.gmail.com>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com>
	<20100506110550.GA13412@code0.codespeak.net>
	<20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
	<r2n693bc9ab1005061451x417feaceg3c908483227cba12@mail.gmail.com>
Message-ID: <7D4EC3FF-AA40-47E3-B921-390DC128039B@gmail.com>

What about normalizing the results upon one certain fixed benchmark?
This avoids the fact that the results are times but rather relative values.
At least thats what we did to make benchmarks a bit more portable in general.
Plus if you depend on the time's 'user'-time the load of the machine doesn't affect the results (Although I guess you are aware of that fact :P).

btw. we abused your benchmarking site ;)

cheers cami

On 06.05.2010, at 23:51, Maciej Fijalkowski wrote:

> I looked at svn log, and the only coincidence I can find is upgrade of ubuntu.
> 
> On Thu, May 6, 2010 at 7:51 AM,  <exarkun at twistedmatrix.com> wrote:
>> On 11:05 am, arigo at tunes.org wrote:
>>> 
>>> Hi,
>>> 
>>> On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
>>>> 
>>>> Anyone has any clue where recent noise comes from? I could not
>>>> pinpoint any single revision.
>>> 
>>> That really looks like some external factor, e.g. the machine is
>>> overloaded.  Maybe we should move benchmarking to tannit.  It would mean
>>> that the results cannot be followed across the move, but at least tannit
>>> is a non-virtual machine on which we can ensure some consistent total
>>> usage.
>>> 
>>> The drawback of picking tannit is that it's unclear what will occur to
>>> it after the end of the current funding period.  Other choices have
>>> other drawbacks -- e.g. wyvern is old (and not representative of today's
>>> performance) and might die unexpectedly any year now.
>> 
>> What else is on the machine that's causing it to be overloaded now?
>> 
>> I'd suggest temporarily disabling or moving all of that first, getting a few
>> benchmark runs that show there hasn't been a performance regression, and
>> then considering moving the benchmarks to a new machine.  Otherwise if there
>> has been a performance regression, the move will just hide it.
>> 
>> Jean-Paul
>> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev


From shadrin at yandex-team.ru  Wed May 12 12:34:50 2010
From: shadrin at yandex-team.ru (Shadrin Eugene)
Date: Wed, 12 May 2010 14:34:50 +0400
Subject: [pypy-dev] Building pypy on freebsd 64bit
In-Reply-To: <AANLkTimm07OI2iagbJ-vnTk8MrrjX62sUQMI0S-YXkfp@mail.gmail.com>
References: <4BE9455E.9070600@yandex-team.ru> <4BE948D5.1080700@yandex-team.ru>
	<AANLkTimm07OI2iagbJ-vnTk8MrrjX62sUQMI0S-YXkfp@mail.gmail.com>
Message-ID: <4BEA844A.8060200@yandex-team.ru>

Thank you!
Probably I think that I have some problems with my compiler. So that 
because:

[user at server_name ~/test]$ gcc -m32 sizeof-long.c -o sizeof-long
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for 
-lgcc
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for 
-lgcc
/usr/bin/ld: cannot find -lgcc

I thought that 32 bit doesn't work because gcc doesn't look under 
/usr/lib32, so I added lib32 path, but I failed again:

[user at server_name ~/test]$ gcc -m32 sizeof-long.c -L/lib32 -L/usr/lib32 
-L`pwd`/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 -pthread 
-fomit-frame-pointer -o sizeof-long
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/lib/crt1.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/lib/crti.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/lib/crtbegin.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/lib/crtend.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file 
`/usr/lib/crtn.o' is incompatible with i386 output
/usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 internal error, aborting at 
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/reloc.c 
line 4274 in bfd_generic_get_relocated_section_contents

/usr/bin/ld: Please report this bug.

Then I tryed to link the binary myself explicitly against /usr/lib32, 
and it works:

[user at server_name ~/test]$ gcc -c -m32 -o sizeof-long.o sizeof-long.c
[user at server_name ~/test]$ /usr/bin/ld --eh-frame-hdr -m elf_i386_fbsd 
-V -dynamic-linker /libexec/ld-elf32.so.1 -o sizeof-long 
/usr/lib32/crt1.o /usr/lib32/crti.o /usr/lib32/crtbegin.o -L/usr/lib32 
sizeof-long.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc 
--as-needed -lgcc_s --no-as-needed /usr/lib32/crtend.o /usr/lib32/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
   Supported emulations:
    elf_i386_fbsd
    elf_x86_64_fbsd
[user at server_name ~/test]$ file sizeof-long
sizeof-long: ELF 32-bit LSB executable, Intel 80386, version 1 
(FreeBSD), for FreeBSD 7.3, dynamically linked (uses shared libs), 
FreeBSD-style, not stripped
[user at server_name ~/test]$ ./sizeof-long
*sizeof(long): 4*

Now I'm thinking about how cat I patch pypy source code to compile it 
with described below "manual" method =)



11.05.2010 20:38, Paolo Giarrusso ?????:
> On Tue, May 11, 2010 at 14:08, Shadrin Eugene<shadrin at yandex-team.ru>  wrote:
>    
>> Hi!
>>
>> I tryed to build pypy on the freebsd, 64bit platform, but failed.
>>
>> First of all I downloaded a 32bit-Python to run pypy.
>> And then:
>>
>> [user at server_name ~/pypy-trunk/pypy/translator/goal]$ ~/py32/bin/python
>> translate.py -Ojit
>> [translation:info] Translating target as defined by targetpypystandalone
>> [platform:execute] gcc -m32 -c -O3 -pthread -fomit-frame-pointer
>> /var/tmp/usession-trunk-22/gcctest.c -o /var/tmp/usession-trunk-22/gcctest.o
>> [platform:WARNING] /var/tmp/usession-trunk-22/gcctest.c:28:2: warning: no
>> newline at end of file
>> [platform:execute] gcc -m32 /var/tmp/usession-trunk-22/gcctest.o -L/lib32
>> -L/usr/lib32 -L`pwd`/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 -pthread
>> -o /var/tmp/usession-trunk-22/gcctest
>> printf("sizeof short=%ld\n", (long)sizeof(short));
>>          printf("sizeof unsigned short=%ld\n", (long)sizeof(unsigned short));
>>          printf("sizeof int=%ld\n", (long)sizeof(int));
>>          printf("sizeof unsigned int=%ld\n", (long)sizeof(unsigned int));
>>          printf("sizeof long=%ld\n", (long)sizeof(long));
>>          printf("sizeof unsigned long=%ld\n", (long)sizeof(unsigned long));
>>          printf("sizeof signed char=%ld\n", (long)sizeof(signed char));
>>          printf("sizeof unsigned char=%ld\n", (long)sizeof(unsigned char));
>>          printf("sizeof long long=%ld\n", (long)sizeof(long long));
>>          printf("sizeof unsigned long long=%ld\n", (long)sizeof(unsigned long
>> long));
>>          printf("sizeof size_t=%ld\n", (long)sizeof(size_t));
>>          printf("sizeof time_t=%ld\n", (long)sizeof(time_t));
>>          printf("sizeof wchar_t=%ld\n", (long)sizeof(wchar_t));
>>          printf("sizeof mode_t=%ld\n", (long)sizeof(mode_t));
>>          printf("sizeof pid_t=%ld\n", (long)sizeof(pid_t));
>> sizeof short=2
>> sizeof unsigned short=2
>> sizeof int=4
>> sizeof unsigned int=4
>> sizeof long=8
>> sizeof unsigned long=8
>> sizeof signed char=1
>> sizeof unsigned char=1
>> sizeof long long=8
>> sizeof unsigned long long=8
>> sizeof size_t=8
>> sizeof time_t=8
>> sizeof wchar_t=4
>> sizeof mode_t=2
>> sizeof pid_t=4
>>
>> Traceback (most recent call last):
>>    File "translate.py", line 300, in<module>
>>      main()
>>    File "translate.py", line 205, in main
>>      targetspec_dic, translateconfig, config, args =
>> parse_options_and_load_target()
>>    File "translate.py", line 153, in parse_options_and_load_target
>>      targetspec_dic = load_target(targetspec)
>>    File "translate.py", line 105, in load_target
>>      mod = __import__(specname)
>>    File "targetpypystandalone.py", line 5, in<module>
>>      from pypy.objspace.std.objspace import StdObjSpace
>>    File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/__init__.py", line
>> 1, in<module>
>>      from pypy.objspace.std.objspace import StdObjSpace
>>    File "/place/home/hitrobot/pypy-trunk/pypy/objspace/std/objspace.py", line
>> 3, in<module>
>>      from pypy.interpreter import pyframe, function, special
>>    File "/place/home/hitrobot/pypy-trunk/pypy/interpreter/pyframe.py", line
>> 13, in<module>
>>      from pypy.rlib import jit, rstack
>>    File "/place/home/hitrobot/pypy-trunk/pypy/rlib/rstack.py", line 10, in
>> <module>
>>      from pypy.rpython.lltypesystem import rffi, lltype
>>    File "/place/home/hitrobot/pypy-trunk/pypy/rpython/lltypesystem/rffi.py",
>> line 824, in<module>
>>      sys.maxint, sizeof(lltype.Signed)))
>> AssertionError: Mixed configuration of the word size of the machine:
>>          the underlying Python was compiled with maxint=2147483647,
>>          but the C compiler says that 'long' is 8 bytes
>>
>>
>> I got this error, then I added "-m32" flag to gcc argument list (in the
>> posix.py source file) , but error occured again :(
>>      
> Your fix was reasonably correct, and the printed command line shows an
> -m32 flag passed to gcc, however the subsequent program listing still
> says that sizeof(long) is 8 bytes. I'm assuming that the program
> getting executed is the one compiled there (gcctest), can you please
> verify?
> I just double-checked that this result is unreasonable here on Linux
> 64bit (Ubuntu Karmic 9.10):
>
> $ cat sizeof-long.c
> #include<stdio.h>
> int main(void) {
>      printf("sizeof(long): %zd\n", sizeof(long));
>      return 0;
> }
> $ gcc -m32    sizeof-long.c   -o sizeof-long
> $ ./sizeof-long
> sizeof(long): 4
>
> That's what you need to get (i.e. sizeof(long) == 4 rather than 8).
> Once you get it, you can fix the above error. I rechecked the above
> messages, there's nothing strange. Maybe you have some gcc wrapper
> silently forcing -m64 on the cmd line?
>
>    
>> Does anybody tryed to build pypy-c on the 64bit FreeBsd?
>>      
> I didn't myself.
>    


-- 
?????? ???????
?????? ?????????? ???????? ???????
????? ?????????? ?????????
???????????

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100512/7420d771/attachment.htm 

From p.giarrusso at gmail.com  Wed May 12 12:58:19 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Wed, 12 May 2010 12:58:19 +0200
Subject: [pypy-dev] recent speed results
In-Reply-To: <7D4EC3FF-AA40-47E3-B921-390DC128039B@gmail.com>
References: <z2l693bc9ab1005041859g545f2b6bmef42f6347a35d00a@mail.gmail.com> 
	<20100506110550.GA13412@code0.codespeak.net>
	<20100506135131.1681.664697311.divmod.xquotient.2@localhost.localdomain>
	<r2n693bc9ab1005061451x417feaceg3c908483227cba12@mail.gmail.com> 
	<7D4EC3FF-AA40-47E3-B921-390DC128039B@gmail.com>
Message-ID: <AANLkTinXKSHuCM8d2FdjqPx9VV6cpMCgF_nAlv999yS4@mail.gmail.com>

On Tue, May 11, 2010 at 23:22, Camillo Bruni <camillobruni at gmail.com> wrote:
> What about normalizing the results upon one certain fixed benchmark?
> This avoids the fact that the results are times but rather relative values.
> At least thats what we did to make benchmarks a bit more portable in general.
> Plus if you depend on the time's 'user'-time the load of the machine doesn't affect the results (Although I guess you are aware of that fact :P).

That's just theoretically true - the more context switches you have,
the more cache misses you have (and this is not accounted by user
time). And system time also needs to be accounted, so one should at
least use user+sys. Btw, system time is probably negatively affected
by in-kernel contention for mutexes and spinlocks. Again the same
story.

Bye
> On 06.05.2010, at 23:51, Maciej Fijalkowski wrote:
>
>> I looked at svn log, and the only coincidence I can find is upgrade of ubuntu.
>>
>> On Thu, May 6, 2010 at 7:51 AM, ?<exarkun at twistedmatrix.com> wrote:
>>> On 11:05 am, arigo at tunes.org wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Tue, May 04, 2010 at 07:59:17PM -0600, Maciej Fijalkowski wrote:
>>>>>
>>>>> Anyone has any clue where recent noise comes from? I could not
>>>>> pinpoint any single revision.
>>>>
>>>> That really looks like some external factor, e.g. the machine is
>>>> overloaded. ?Maybe we should move benchmarking to tannit. ?It would mean
>>>> that the results cannot be followed across the move, but at least tannit
>>>> is a non-virtual machine on which we can ensure some consistent total
>>>> usage.
>>>>
>>>> The drawback of picking tannit is that it's unclear what will occur to
>>>> it after the end of the current funding period. ?Other choices have
>>>> other drawbacks -- e.g. wyvern is old (and not representative of today's
>>>> performance) and might die unexpectedly any year now.
>>>
>>> What else is on the machine that's causing it to be overloaded now?
>>>
>>> I'd suggest temporarily disabling or moving all of that first, getting a few
>>> benchmark runs that show there hasn't been a performance regression, and
>>> then considering moving the benchmarks to a new machine. ?Otherwise if there
>>> has been a performance regression, the move will just hide it.
>>>
>>> Jean-Paul
>>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>



-- 
Paolo Giarrusso

From cfbolz at gmx.de  Thu May 13 11:29:44 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 13 May 2010 11:29:44 +0200
Subject: [pypy-dev] Call for Papers: Workshop on Self-sustaining Systems
	(S3) 2010
Message-ID: <4BEBC688.8030808@gmx.de>

*** Workshop on Self-sustaining Systems (S3) 2010 ***

September 27-28, 2010
The University of Tokyo, Japan
http://www.hpi.uni-potsdam.de/swa/s3/s3-10/

In cooperation with ACM SIGPLAN

=== Call for papers ===

The Workshop on Self-sustaining Systems (S3) is a forum for discussion 
of topics relating to computer systems and languages that are able to 
bootstrap, implement, modify, and maintain themselves. One property of 
these systems is that their implementation is based on small but 
powerful abstractions; examples include (amongst others) 
Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and 
Lisp. Such systems are the engines of their own replacement, giving 
researchers and developers great power to experiment with, and explore 
future directions from within, their own small language kernels.

S3 will be take place September 27-28, 2010 at The University of Tokyo, 
Japan. It is an exciting opportunity for researchers and practitioners 
interested in self-sustaining systems to meet and share their knowledge, 
experience, and ideas for future research and development.

--- Submissions and proceedings ---

S3 invites submissions of high-quality papers reporting original 
research, or describing innovative contributions to, or experience with, 
self-sustaining systems, their implementation, and their application. 
Papers that depart significantly from established ideas and practices 
are particularly welcome.

Submissions must not have been published previously and must not be 
under review for any another refereed event or publication. The program 
committee will evaluate each contributed paper based on its relevance, 
significance, clarity, and originality. Revised papers will be published 
as post-proceedings in the ACM Digital Library.

Papers should be submitted electronically via EasyChair at 
http://www.easychair.org/conferences/?conf=s32010 in PDF format. 
Submissions must be written in English (the official language of the 
workshop) and must not exceed 10 pages. They should use the ACM SIGPLAN 
10 point format, templates for which are available at 
http://www.acm.org/sigs/sigplan/authorInformation.htm.

--- Venue ---

The University of Tokyo, Komaba Campus, Japan

--- Important dates ---

Submission of papers: July 30, 2010
Author notification: August 27, 2010
Early registration: September 3, 2010
Revised papers: September 10, 2010
S3 workshop: September 27-28, 2010
Final papers for ACM-DL post-proceedings: October 15, 2010

--- Chairs ---

Robert Hirschfeld (Hasso-Plattner-Institut Potsdam, Germany)
hirschfeld at hpi.uni-potsdam.de
Hidehiko Masuhara (The University of Tokyo, Japan)
masuhara at graco.c.u-tokyo.ac.jp
Kim Rose (Viewpoints Research Institute, USA)
kim.rose at vpri.org

--- Program committee ---

Carl Friedrich Bolz, University of Duesseldorf, Germany
Johan Brichau, Universite Catholique de Louvain, Belgium
Shigeru Chiba, Tokyo Institute of Technology, Japan
Brian Demsky, University of California, Irvine, USA
Marcus Denker, INRIA Lille, France
Richard P. Gabriel, IBM Research, USA
Michael Haupt, Hasso-Plattner-Institut, Germany
Robert Hirschfeld, Hasso-Plattner-Institut, Germany (co-chair)
Atsushi Igarashi, University of Kyoto, Japan
David Lorenz, The Open University, Israel
Hidehiko Masuhara, University of Tokyo, Japan (co-chair)
Eliot Miranda, Teleplace, USA
Ian Piumarta, Viewpoints Research Institute, USA
Martin Rinard, MIT, USA
Antero Taivalsaari, Nokia, Finland
David Ungar, IBM, USA

From tobami at googlemail.com  Thu May 13 21:36:55 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Thu, 13 May 2010 21:36:55 +0200
Subject: [pypy-dev] PySide Benchmarks
Message-ID: <AANLkTinnejG7DwVLaRr5M6GSSEnoDpy9kmKs8igEknJx@mail.gmail.com>

Hi all,

just wanted to link a post by the guys that are implementing the new Python
Qt bindings:
http://www.pyside.org/pyside-v0-3-benchmarks/

They perform quite a lot of different benchmarks, and I thought you may find
it interesting and may get some ideas of things you want to measure for
PyPy, or/and new views/graphs you may want for speed.pypy.org

Cheers!
Miquel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100513/350f29da/attachment.htm 

From p.giarrusso at gmail.com  Sat May 15 00:23:04 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Sat, 15 May 2010 00:23:04 +0200
Subject: [pypy-dev] Fwd: [#24493678] Re:  recent speed results
In-Reply-To: <4ab64c36e13890af3c3c845d01406df5@secure.mpcustomer.com>
References: <4ab64c36e13890af3c3c845d01406df5@secure.mpcustomer.com>
Message-ID: <AANLkTinaVO3l2ZJ_CtsYI3YGg9voQqTyX2Wae9xUxXYx@mail.gmail.com>

What's happening? What are this messages? I'm getting one in reply for
every email I send to the list (and to anybody I send it).
Look for '====== ANOTHER EMAIL - HEADERS =========' below to find the
other mail.
Can you unsubscribe this annoying bot?

Headers:
Delivered-To: p.giarrusso at gmail.com
Received: by 10.102.218.1 with SMTP id q1cs12764mug;
        Wed, 12 May 2010 04:04:14 -0700 (PDT)
Received: by 10.224.34.135 with SMTP id l7mr4838966qad.341.1273662252962;
        Wed, 12 May 2010 04:04:12 -0700 (PDT)
Return-Path: <camillobruni at gmail.com>
Received: from secure.mpcustomer.com (secure.mpcustomer.com [208.43.146.75])
        by mx.google.com with ESMTP id fo28si43328qcb.19.2010.05.12.04.04.12;
        Wed, 12 May 2010 04:04:12 -0700 (PDT)
Received-SPF: neutral (google.com: 208.43.146.75 is neither permitted
nor denied by domain of camillobruni at gmail.com)
client-ip=208.43.146.75;
Authentication-Results: mx.google.com; spf=neutral (google.com:
208.43.146.75 is neither permitted nor denied by domain of
camillobruni at gmail.com) smtp.mail=camillobruni at gmail.com
Received: by secure.mpcustomer.com (Postfix, from userid 99)
	id D901B1530002; Wed, 12 May 2010 06:04:11 -0500 (CDT)
To: Paolo Giarrusso <p.giarrusso at gmail.com>
Subject: [#24493678] Re: [pypy-dev] recent speed results
Date: Wed, 12 May 2010 06:04:11 -0500
From: Camillo Bruni <camillobruni at gmail.com>
Reply-To: support at mpcustomer.com
Message-ID: <4ab64c36e13890af3c3c845d01406df5 at secure.mpcustomer.com>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
X-Uberinst: uber_phase-support
X-Mailer: Ubersmith
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
---------- Forwarded message ----------
From: Camillo Bruni <camillobruni at gmail.com>
Date: Wed, May 12, 2010 at 13:04
Subject: [#24493678] Re: [pypy-dev] recent speed results
To: Paolo Giarrusso <p.giarrusso at gmail.com>


Hello,

This is an automated response to inform you that your question has
been entered into our system, and will be reviewed shortly. Your
ticket has been submitted into the "General Support" department.

We will respond to you as soon as possible.

==============
Please keep this information, and use it when refering to your ticket:

Ticket subject: Re: [pypy-dev] recent speed results
Ticket number: 24493678
Ticket link: https://secure.mpcustomer.com/ticket.php?ticket=24493678
Ticket body: On Tue, May 11, 2010 at 23:22, Camillo Bruni
<camillobruni at gmail.com> wrote:
> What about normalizing the results upon one certain fixed benchmark?
> This avoids the fact that the results are times but rather relative values.
> At least thats what we did to make benchmarks a bit more portable in general.
> Plus if you depend on the time's 'user'-time the load of the machine doesn't affect the results (Although I guess you are aware of that fact :P).
[...]

====== ANOTHER EMAIL - HEADERS =========
Delivered-To: p.giarrusso at gmail.com
Received: by 10.102.218.1 with SMTP id q1cs125356mug;
        Tue, 11 May 2010 09:46:58 -0700 (PDT)
Received: by 10.231.183.134 with SMTP id cg6mr741519ibb.25.1273596417616;
        Tue, 11 May 2010 09:46:57 -0700 (PDT)
Return-Path: <shadrin at yandex-team.ru>
Received: from secure.mpcustomer.com (secure.mpcustomer.com [208.43.146.75])
        by mx.google.com with ESMTP id gu37si1275370ibb.88.2010.05.11.09.46.56;
        Tue, 11 May 2010 09:46:57 -0700 (PDT)
Received-SPF: fail (google.com: domain of shadrin at yandex-team.ru does
not designate 208.43.146.75 as permitted sender)
client-ip=208.43.146.75;
Authentication-Results: mx.google.com; spf=hardfail (google.com:
domain of shadrin at yandex-team.ru does not designate 208.43.146.75 as
permitted sender) smtp.mail=shadrin at yandex-team.ru
Received: by secure.mpcustomer.com (Postfix, from userid 99)
	id B93562781B8; Tue, 11 May 2010 11:46:56 -0500 (CDT)
To: Paolo Giarrusso <p.giarrusso at gmail.com>
Subject: [#24492200] Re: [pypy-dev] Building pypy on freebsd 64bit
Date: Tue, 11 May 2010 11:46:56 -0500
From: Shadrin Eugene <shadrin at yandex-team.ru>
Reply-To: support at mpcustomer.com
Message-ID: <8423708fe6db23baafcc8eadf3a6622d at secure.mpcustomer.com>
X-Priority: 3
X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4]
X-Uberinst: uber_phase-support
X-Mailer: Ubersmith
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"

Hello,

This is an automated response to inform you that your question has
been entered into our system, and will be reviewed shortly. Your
ticket has been submitted into the "General Support" department.

We will respond to you as soon as possible.

==============
Please keep this information, and use it when refering to your ticket:

Ticket subject: Re: [pypy-dev] Building pypy on freebsd 64bit
Ticket number: 24492200
Ticket link: https://secure.mpcustomer.com/ticket.php?ticket=24492200
Ticket body: On Tue, May 11, 2010 at 14:08, Shadrin Eugene
<shadrin at yandex-team.ru> wrote:
-- 
Paolo Giarrusso

From arigo at tunes.org  Sat May 15 14:48:02 2010
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 15 May 2010 14:48:02 +0200
Subject: [pypy-dev] Fwd: [#24493678] Re:  recent speed results
In-Reply-To: <AANLkTinaVO3l2ZJ_CtsYI3YGg9voQqTyX2Wae9xUxXYx@mail.gmail.com>
References: <4ab64c36e13890af3c3c845d01406df5@secure.mpcustomer.com>
	<AANLkTinaVO3l2ZJ_CtsYI3YGg9voQqTyX2Wae9xUxXYx@mail.gmail.com>
Message-ID: <20100515124801.GA9264@code0.codespeak.net>

Hi Paolo,

On Sat, May 15, 2010 at 12:23:04AM +0200, Paolo Giarrusso wrote:
> What's happening? What are this messages? I'm getting one in reply for
> every email I send to the list (and to anybody I send it).

That's a spam.  It's not coming from us at all.  It's not like we have a
"General support" departement, or any other departements.


A bientot,

Armin.

From holger at merlinux.eu  Mon May 17 11:38:47 2010
From: holger at merlinux.eu (holger krekel)
Date: Mon, 17 May 2010 11:38:47 +0200
Subject: [pypy-dev] access to pypy version info, internals
Message-ID: <20100517093847.GM17693@trillke.net>

Hi, 

i'd like an easy way to test for a) are we running on pypy? 
b) what is the pypy version. c) access pypy internals such
as transparent proxies. 

Today, it is possible to check for 

    a) via "'__pypy__' in sys.builtin_module_names" and for 
    b) with "sys.pypy_version_info >= (x,y)".  There are also a 
       couple of other 'sys.pypy_*' variables.  
    c) can be done by (trying to) import __pypy__. 

What about rather doing a single clean 'sys.pypy' module namespace such 
that we can do: 

    a) hasattr(sys, 'pypy')
    b) sys.pypy.version_info >= (x,y)
    c) expose the __pypy__ builtin module as sys.pypy?  

Semantically, the sys module already presents an interaction 
API with the interpreter.  Doing a single namespace looks more
elegant to me than of cluttering sys with an artifical 'pypy_*' 
prefixed namespace and having to (try-except)import __pypy__. 

best,
holger


From tobami at googlemail.com  Tue May 18 11:22:10 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Tue, 18 May 2010 11:22:10 +0200
Subject: [pypy-dev] State of speed.pypy.org
Message-ID: <AANLkTilcLn7jYtzGWeZUeyQ3DXAedaqK36gNk2LJGwcu@mail.gmail.com>

Hi all,

in the last week there have been several problems with the speed site, I'll
sum them up here for those not up to date.

The first one was that the tests were no longer reliable, showing huge
variation between runs. A possible cause was that they were running inside a
VM, and it may have reached its resource limits, or even worse, that the
virtual environment was causing strange behavior. So it was decided to move
benchmarks to tannit, a non virtualized Xeon W3580 with 12Gigs of RAM and
running a 2.6.31 server kernel.

Having now results for two different environment raised the need to upgrade
codespeed to the latest version (older versions did not really allow to
change host). Along the way the server hosting speed was down, and the bench
runs continued to stubbornly save result data against the old host. So all
in all it has been nearly a week without a properly working site. It should
be fixed now.

There are not a lot of visible new features in this version of the site
apart from minor touches (and a working multiple host implementation, of
course!). For example the overview-timeline cross-integration is complete.
You may now click on a data point, and you'll be taken to the corresponding
revision and executable overview table. This allows for back and forth
exploration of the data.

That's all I think.

Cheers!
Miquel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100518/abce5c60/attachment.htm 

From giallu at gmail.com  Fri May 21 19:56:11 2010
From: giallu at gmail.com (Gianluca Sforna)
Date: Fri, 21 May 2010 19:56:11 +0200
Subject: [pypy-dev] PyPy in the news
In-Reply-To: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
References: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
Message-ID: <AANLkTimjgDJTeJvmnmuYHH2dm5VmEHPaOn1uRnSsj140@mail.gmail.com>

Hi all,
I am not sure if you noticed, so I'd like to point out this LWN
article about PyPy

http://lwn.net/Articles/387561/

If you haven't a LWN subscription you need to either wait a few days for the
article to became free or ask me a subscriber link (I can't post it to the
ML, sorry)

Great job guys

Gianluca

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

From fuzzyman at voidspace.org.uk  Fri May 21 20:56:48 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 21 May 2010 19:56:48 +0100
Subject: [pypy-dev] PyPy in the news
In-Reply-To: <AANLkTimjgDJTeJvmnmuYHH2dm5VmEHPaOn1uRnSsj140@mail.gmail.com>
References: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
	<AANLkTimjgDJTeJvmnmuYHH2dm5VmEHPaOn1uRnSsj140@mail.gmail.com>
Message-ID: <AANLkTinrxuVg0BxxEPotp2mSPcUd2gHj9_y1P1cGa7zt@mail.gmail.com>

On 21 May 2010 18:56, Gianluca Sforna <giallu at gmail.com> wrote:

> Hi all,
> I am not sure if you noticed, so I'd like to point out this LWN
> article about PyPy
>
> http://lwn.net/Articles/387561/
>
> If you haven't a LWN subscription you need to either wait a few days for
> the
> article to became free or ask me a subscriber link (I can't post it to the
> ML, sorry)
>


Is it this?

https://lwn.net/SubscriberLink/388160/7bf6baf1004c75d3/

Google seems to pickup these subscriber links easily, so I don't think it
can be bad to post one that easily found(?).

Michael



>
> Great job guys
>
> Gianluca
>
> --
> Gianluca Sforna
>
> http://morefedora.blogspot.com
> http://www.linkedin.com/in/gianlucasforna
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100521/f96bd668/attachment.htm 

From fuzzyman at voidspace.org.uk  Fri May 21 20:57:31 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 21 May 2010 19:57:31 +0100
Subject: [pypy-dev] PyPy in the news
In-Reply-To: <AANLkTinrxuVg0BxxEPotp2mSPcUd2gHj9_y1P1cGa7zt@mail.gmail.com>
References: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
	<AANLkTimjgDJTeJvmnmuYHH2dm5VmEHPaOn1uRnSsj140@mail.gmail.com>
	<AANLkTinrxuVg0BxxEPotp2mSPcUd2gHj9_y1P1cGa7zt@mail.gmail.com>
Message-ID: <AANLkTinD6gew5T2KW3ZtUxIjVKhxmZj0d4ZyDoa81cs0@mail.gmail.com>

On 21 May 2010 19:56, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

>
>
> On 21 May 2010 18:56, Gianluca Sforna <giallu at gmail.com> wrote:
>
>> Hi all,
>> I am not sure if you noticed, so I'd like to point out this LWN
>> article about PyPy
>>
>> http://lwn.net/Articles/387561/
>>
>> If you haven't a LWN subscription you need to either wait a few days for
>> the
>> article to became free or ask me a subscriber link (I can't post it to the
>> ML, sorry)
>>
>
>
> Is it this?
>
> https://lwn.net/SubscriberLink/388160/7bf6baf1004c75d3/
>


Hmmm... judging by the article numbers in the URL it probably isn't that
one. Sorry for the noise.

Michael



>
> Google seems to pickup these subscriber links easily, so I don't think it
> can be bad to post one that easily found(?).
>
> Michael
>
>
>
>>
>> Great job guys
>>
>> Gianluca
>>
>> --
>> Gianluca Sforna
>>
>> http://morefedora.blogspot.com
>> http://www.linkedin.com/in/gianlucasforna
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> http://www.ironpythoninaction.com/
>
>
>


-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100521/e92e3190/attachment-0001.htm 

From jacob at openend.se  Fri May 21 21:23:44 2010
From: jacob at openend.se (Jacob =?iso-8859-15?q?Hall=E9n?=)
Date: Fri, 21 May 2010 21:23:44 +0200
Subject: [pypy-dev] PyPy in the news
In-Reply-To: <AANLkTinD6gew5T2KW3ZtUxIjVKhxmZj0d4ZyDoa81cs0@mail.gmail.com>
References: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
	<AANLkTinrxuVg0BxxEPotp2mSPcUd2gHj9_y1P1cGa7zt@mail.gmail.com>
	<AANLkTinD6gew5T2KW3ZtUxIjVKhxmZj0d4ZyDoa81cs0@mail.gmail.com>
Message-ID: <201005212123.44628.jacob@openend.se>

I was interviewed in Copmuter Sweden concerning PyPy this week. This is an IT 
business and gossip tabloid. I was not allowed to use the term Just-In-Time 
Compiler, so what we have actually done is quite cryptic. However, it is clear 
from the article that we can make Python ryn faster.

The interview is in Swedish.

http://www.idg.se/2.1085/1.319775/upp-till-50-ganger-snabbare

From arigo at tunes.org  Fri May 21 21:35:46 2010
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 21 May 2010 21:35:46 +0200
Subject: [pypy-dev] PyPy in the news
In-Reply-To: <201005212123.44628.jacob@openend.se>
References: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
	<AANLkTinrxuVg0BxxEPotp2mSPcUd2gHj9_y1P1cGa7zt@mail.gmail.com>
	<AANLkTinD6gew5T2KW3ZtUxIjVKhxmZj0d4ZyDoa81cs0@mail.gmail.com>
	<201005212123.44628.jacob@openend.se>
Message-ID: <20100521193546.GA9967@code0.codespeak.net>

Hi Jacob,

On Fri, May 21, 2010 at 09:23:44PM +0200, Jacob Hall?n wrote:
> I was interviewed in Copmuter Sweden concerning PyPy this week. This
> is an IT business and gossip tabloid. I was not allowed to use the
> term Just-In-Time Compiler, so what we have actually done is quite
> cryptic.

It is of course your choice and I have nothing to say against it, but in
the same position of being interviewed under the condition that I don't
use this or that term (whether it's appropriate or not), I would decline
to make any comment, whoever the interviewer is.


Armin

From holger at merlinux.eu  Tue May 25 22:22:20 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 25 May 2010 22:22:20 +0200
Subject: [pypy-dev] xfail versus skips
Message-ID: <20100525202220.GO17693@trillke.net>

hi all,

i just released py.test-1.3.1 [1] which is inlined as svn/pypy/trunk/py 
and the pypy/test_all.py script is an alias for "py.test".  This release
particularly refines "expected-to-fail" aka "xfail" semantics: 

    # abort setup or test function, reporting as "expected to fail", or 'x'
    py.test.xfail() or py.test.xfail(reason)  

see http://codespeak.net/py/dist/test/plugin/skipping.html
for more details.  Marking tests as 'xfail' is also good for
tests that *sometimes* fail.  

I just did a grep of "py.test.skip" in pypy/trunk/pypy and 
there are 468 occurences [2].  Many of these skips seem to be because 
of implementation issues rather than platform/dependency mismatches 
and should thus rather use py.test.xfail.  Being Skips kind of hides
those issues between the rightful skips.  The xfail/skip distinction is 
something that is happening in other parts of the Python world as well
and i hope you find it useful as well. 

best,
holger


[1] http://codespeak.net/py/dist/announce/release-1.3.1.html
[2] the gory list of py.test.skip's in trunk/pypy

objspace/std/test/test_proxy_usercreated.py:27:             py.test.skip("Impossible to run on appdirect")
objspace/std/test/test_longobject.py:27:         py.test.skip("XXX broken!")
objspace/std/test/test_userobject.py:289:             py.test.skip("Cannot run different installers when runappdirect")
objspace/std/test/test_smallintobject.py:5: #    py.test.skip("WITHSMALLINT is not enabled")
objspace/std/test/test_typeobject.py:65:         py.test.skip("Not implemented yet")
objspace/std/test/test_proxy_internals.py:28:             py.test.skip("interp only test")
objspace/std/test/test_rangeobject.py:9:             py.test.skip("__pypy__.internal_repr() cannot be used to see "
objspace/fake/test/test_checkmodule.py:6:     py.test.skip('fixme')
objspace/flow/test/test_objspace.py:721:         py.test.skip("not working")
objspace/flow/test/test_objspace.py:728:         py.test.skip("not working for now")
doc/conftest.py:22:         py.test.skip("specify --pypy-doctests to run doctests")
config/test/test_makerestdoc.py:11:     py.test.skip("don't have docutils")
jit/backend/x86/test/test_zrpy_platform.py:15:         py.test.skip("tests darwin only stack alignment requirements")
jit/backend/x86/test/test_virtualizable.py:8:         py.test.skip("Assertion error & llinterp mess")
jit/backend/x86/test/test_tlc.py:12:         py.test.skip("investigate, maybe")
jit/backend/x86/test/test_tlc.py:21:         py.test.skip("investigate, maybe")
jit/backend/x86/test/conftest.py:7:         py.test.skip("x86 directory skipped: cpu is %r" % (cpu,))
jit/backend/x86/test/test_basic.py:38:         py.test.skip("issue with ll2ctypes")
jit/backend/x86/test/test_basic.py:41:         py.test.skip("issue of freeing, probably with ll2ctypes")
jit/backend/x86/test/test_ri386_auto_encoding.py:306:         py.test.skip("full tests require the GNU 'as' assembler")
jit/backend/x86/test/test_ri386_auto_encoding.py:311:             py.test.skip("why doesn't 'as' know about CMOVPE/CMOVPO?")
jit/backend/x86/test/test_exception.py:11:         py.test.skip("Widening to trash")
jit/backend/x86/test/test_slist.py:9:         py.test.skip("list of voids unsupported by ll2ctypes")
jit/backend/llvm/test/conftest.py:4:     py.test.skip("llvm backend tests skipped for now")
jit/backend/llvm/llvm_rffi.py:7:     py.test.skip("Linux only for now")
jit/backend/llvm/llvm_rffi.py:27:         py.test.skip("llvm (version 2) is required")
jit/backend/cli/test/test_runner.py:26:         py.test.skip("not supported in non-translated version")
jit/backend/cli/test/test_runner.py:37:         py.test.skip('fixme! max 32 inputargs so far')
jit/backend/cli/test/test_runner.py:43:         py.test.skip('fixme!')
jit/backend/cli/test/test_runner.py:46:         py.test.skip('fixme!')
jit/backend/cli/test/conftest.py:4:     py.test.skip("CLI backend tests skipped for now")
jit/backend/cli/test/test_basic.py:16:         py.test.skip("works only after translation")
jit/backend/cli/test/test_loop.py:11:         py.test.skip("works only after translation")
jit/backend/cli/test/test_list.py:11:         py.test.skip("works only after translation")
jit/backend/cli/test/test_zrpy_send.py:11:         py.test.skip('string return values are not supported')
jit/backend/cli/test/test_exception.py:11:         py.test.skip("works only after translation")
jit/backend/cli/test/test_zrpy_basic.py:20:         py.test.skip('mono bug?')
jit/backend/cli/test/test_zrpy_basic.py:23:         py.test.skip('in-progress')
jit/backend/cli/test/test_zrpy_basic.py:36:         py.test.skip("it seems to fail even with the x86 backend, didn't investigate the problem")
jit/backend/cli/test/test_zrpy_slist.py:2: py.test.skip('decide what to do')
jit/backend/cli/test/test_zrpy_loop.py:11:         py.test.skip('in-progress')
jit/backend/test/runner_test.py:931:             py.test.skip("requires floats")
jit/backend/test/runner_test.py:1012:             py.test.skip("requires floats")
jit/backend/test/runner_test.py:1825:         py.test.skip("implement me")
jit/backend/test/runner_test.py:1828:         py.test.skip("implement me")
jit/backend/test/runner_test.py:1831:         py.test.skip("implement me")
jit/backend/test/support.py:108:         py.test.skip("interp_operations test skipped")
jit/backend/test/support.py:119:                 py.test.skip("use --slow to execute this long-running test")
jit/backend/llsupport/test/test_runner.py:12:         py.test.skip("llsupport test: cannot compile operations")
jit/backend/llgraph/llimpl.py:793:         py.test.skip("cond_call_gc_wb not supported")
jit/tl/tla/test_tla.py:114:     py.test.skip('exercise!')
jit/tl/tla/test_tla.py:126:     py.test.skip('exercise!')
jit/tl/tla/test_tla.py:136:     py.test.skip('exercise!')
jit/tl/tla/test_tla.py:146:     py.test.skip('exercise!')
jit/tl/test/test_pypyjit.py:12:     py.test.skip("no JIT executable")
jit/tl/test/test_tlr.py:15:         py.test.skip("?")
jit/tl/test/test_tl.py:227:         py.test.skip("?")
jit/metainterp/test/test_executor.py:254:         py.test.skip("requires float support from the backend")
jit/metainterp/test/test_send.py:354:         py.test.skip("XXX fix me!!!!!!! problem in optimize.py")
jit/metainterp/test/test_optimizeopt.py:413:         py.test.skip("too bad")
jit/metainterp/test/test_optimizeopt.py:1819:         py.test.skip("this would fail if we had Fixed again in the specnodes")
jit/metainterp/test/test_virtualizable.py:1197:             py.test.skip("purely frontend test")
jit/metainterp/test/test_tlc.py:46:         py.test.skip("buggy interpreter")
jit/metainterp/test/test_basic.py:157:         py.test.skip("ootype tests skipped for now")
jit/metainterp/test/test_basic.py:1442:             py.test.skip("test written in a style that "
jit/metainterp/test/test_warmspot.py:135:         py.test.skip("debug_level is being deprecated")
jit/metainterp/test/test_warmspot.py:177:         py.test.skip("debug_level is being deprecated")
jit/metainterp/test/test_list.py:78:         py.test.skip("Constant propagation of length missing")
jit/metainterp/test/test_list.py:119:         py.test.skip("'[non-null] * n' gives a residual call so far")
jit/metainterp/test/test_virtualref.py:40:             py.test.skip("purely frontend test")
jit/metainterp/test/test_dlist.py:5: py.test.skip("Disabled")
jit/metainterp/test/test_dlist.py:142:         py.test.skip("I suspect bug somewhere outside of the JIT")
jit/metainterp/test/test_slist.py:9:         py.test.skip("not yet")
jit/metainterp/test/test_del.py:109:         py.test.skip("XXX dels are not implemented in the"
jit/metainterp/warmspot.py:670:             py.test.skip("rewrite_force_virtual: port it to ootype")
jit/metainterp/virtualizable.py:23:             py.test.skip("ootype: fix virtualizables")
rlib/parsing/test/test_pythonparse.py:215:         py.test.skip("in progress")
rlib/parsing/test/test_deterministic.py:31:         py.test.skip("pypy not found on path")
rlib/parsing/test/test_deterministic.py:113:     #py.test.skip("optimize not working yet")
rlib/parsing/test/test_ebnfparse.py:277:     #py.test.skip("This needs to be fixed - generated transformer is buggy")
rlib/parsing/test/test_ebnfparse.py:443:     py.test.skip("fix me somehow")
rlib/parsing/test/test_pcre_regtest.py:90: #py.test.skip("Still in progress")
rlib/parsing/test/test_regex.py:8:         py.test.skip("pypy not found")
rlib/rsdl/test/test_video.py:19:             py.test.skip("'--view' not specified, "
rlib/rsdl/test/test_video.py:54:             py.test.skip("interactive test only")
rlib/rsdl/test/test_video.py:82:             py.test.skip("interactive test only")
rlib/rsdl/test/test_video.py:114:             py.test.skip("interactive test only")
rlib/rsdl/test/test_video.py:148:             py.test.skip("interactive test only")
rlib/rsdl/test/conftest.py:8:         py.test.skip("SDL not installed(?): %s" % (e,))
rlib/test/test_rjvm.py:5:     py.test.skip("In Progress...")
rlib/test/test_rjvm.py:25:     py.test.skip('in progress')
rlib/test/test_rgc.py:24:         py.test.skip("requires Python 2.5 to call gc.collect() with an arg")
rlib/test/test_rgc.py:140:     py.test.skip("implement ll_shrink_array for GcStructs or GcArrays that "
rlib/test/test_rsocket.py:31:         py.test.skip('AF_UNIX not supported.')
rlib/test/test_rsocket.py:37:         py.test.skip('AF_NETLINK not supported.')
rlib/test/test_rsocket.py:108:         py.test.skip('No socketpair on Windows')
rlib/test/test_rsocket.py:129:         py.test.skip('No socketpair on Windows')
rlib/test/test_rsocket.py:380:         py.test.skip("no inet_pton()")
rlib/test/test_rsocket.py:386:         py.test.skip("no inet_ntop()")
rlib/test/test_rsocket.py:391:         py.test.skip('AF_UNIX not supported.')
rlib/test/test_libffi.py:203:         py.test.skip("Segfaulting test, skip")
rlib/test/test_libffi.py:417:             py.test.skip("Handle to libc library, Win-only test")
rlib/test/test_runicode.py:212:             py.test.skip("mbcs encoding is win32-specific")
rlib/test/test_runicode.py:233:             py.test.skip("Narrow unicode build")
rlib/test/test_rope.py:447:     py.test.skip("fix me!")
rlib/test/test_rope.py:500:         py.test.skip("bug in unicode.find that was fixed in 2.5")
rlib/test/test_rlocale.py:14:             py.test.skip("polish locale unsupported")
rlib/test/test_rstackovf.py:28:     py.test.skip("not RPython code...")
rlib/test/test_rstackovf.py:35:         py.test.skip("interpreter is not badly behaved")
rlib/test/test_objectmodel.py:136:     py.test.skip("xxx no test here")
rlib/test/test_rzipfile.py:13:     py.test.skip("zlib not installed: %s " % (e, ))
tool/pytest/test/test_overview.py:9:             py.test.skip("testresult directory not checked out")
tool/pytest/htmlreport.py:218:         py.test.skip('needs move to own test file')
tool/pytest/appsupport.py:252:     py.test.skip(msg)
tool/pytest/modcheck.py:6:         py.test.skip("cannot import %r module" % (name,))
tool/test/test_runsubprocess.py:12:         py.test.skip("there is no /bin/echo")
tool/test/test_runsubprocess.py:20:         py.test.skip("there is no /bin/false")
tool/test/test_runsubprocess.py:28:         py.test.skip("there is no /bin/cat")
tool/bench/test/test_benchmark_report.py:7:     py.test.skip(str(e))
tool/package.py:17: if sys.version_info < (2,6): py.test.skip("requires 2.6 so far")
rpython/ootypesystem/test/test_ooann.py:290:     py.test.skip("Maybe we want this to work")
rpython/ootypesystem/test/test_ooclean.py:456:     py.test.skip("hash is not preserved during an ootype translation")
rpython/ootypesystem/test/test_ootype.py:407:         py.test.skip("static types not enforced in ootype")
rpython/lltypesystem/test/test_ll2ctypes.py:330:             py.test.skip("No gettimeofday on win32")
rpython/lltypesystem/test/test_ll2ctypes.py:764:             py.test.skip("No fcntl on win32")
rpython/lltypesystem/test/test_ll2ctypes.py:1267:             py.test.skip("Not supported")
rpython/lltypesystem/test/test_llarena.py:217:     py.test.skip("cast_adr_to_int() is hard to get consistent")
rpython/lltypesystem/test/test_llmemory.py:599:     py.test.skip("Fails")
rpython/lltypesystem/test/test_lltype.py:212:     py.test.skip("test not relevant any more")
rpython/lltypesystem/test/test_lltype.py:227:     py.test.skip("test not relevant any more")
rpython/lltypesystem/test/test_rffi.py:336:         py.test.skip("Think how to do it sane")
rpython/lltypesystem/test/test_rffi.py:646:             py.test.skip('No pipes on windows')
rpython/lltypesystem/test/test_rffi.py:703:             py.test.skip("Cannot test without ctypes")
rpython/lltypesystem/test/test_rffi.py:768:         py.test.skip("GenC does not handle char return values correctly")
rpython/tool/test/test_rffi_platform.py:13:         py.test.skip("this test requires ctypes")
rpython/test/test_rdict.py:648:             py.test.skip("make dict tests more indepdent from initsize")
rpython/test/test_runicode.py:65:         py.test.skip("do we want this test to pass?")
rpython/test/test_runicode.py:199:         py.test.skip("not supported")
rpython/test/tool.py:41:             py.test.skip("lltypesystem doesn't support %s, yet" % reason)        
rpython/test/tool.py:43:             py.test.skip("ootypesystem doesn't support %s, yet" % reason)    
rpython/test/test_llann.py:375:         py.test.skip("annotation crash")
rpython/test/test_rpbc.py:1570:         py.test.skip("Should explode or give some warning")
rpython/numpy/test/test_array.py:826:         py.test.skip('not implemented')
rpython/numpy/test/test_array.py:838:         py.test.skip('not implemented')
rpython/numpy/test/test_array.py:860:             py.test.skip("c compilation disabled")
rpython/memory/gc/test/test_direct.py:428:         py.test.skip("does not support raw_mallocs(sizeof(S)+sizeof(hash))")
rpython/memory/gc/markcompact.py:93:         import py; py.test.skip("Disabled for now, sorry")
rpython/memory/gctransform/test/test_refcounting.py:51:         py.test.skip("a probably-illegal test")
rpython/memory/test/test_gc.py:644:         py.test.skip("Not implemented yet")
rpython/memory/test/test_gc.py:715:         py.test.skip("Not supported")
rpython/memory/test/test_gc.py:764:         py.test.skip("Not supported")
rpython/memory/test/test_transformed_gc.py:258:         py.test.skip("doesn't fit in the model, tested elsewhere too")
rpython/memory/test/test_transformed_gc.py:713:         py.test.skip("fails for bad reasons in lltype.py :-(")
rpython/memory/test/test_transformed_gc.py:848:         py.test.skip("this test makes the following test crash.  Investigate.")
rpython/memory/test/test_transformed_gc.py:1142:         py.test.skip("Disabled for now, sorry")
rpython/memory/test/test_transformed_gc.py:1444:         py.test.skip("not supported")
rpython/module/test/test_posix.py:47:         import py; py.test.skip("llinterp does not like tuple returns")
rpython/module/test/test_posix.py:195:         py.test.skip("ootypesystem does not support os.fstat")
rpython/module/test/test_posix.py:198:         py.test.skip("ootypesystem does not support os.chroot")
rpython/module/test/test_posix.py:201:         py.test.skip("ootypesystem does not support os.stat")
rpython/module/test/test_posix.py:204:         py.test.skip("ootypesystem does not support os.chown")
rpython/module/test/test_ll_os_stat.py:8:             py.test.skip("win32 specific tests")
rpython/module/test/test_ll_os.py:40:         py.test.skip('Windows specific feature')
rpython/module/test/test_ll_os.py:53:         py.test.skip('nt specific function')
rpython/module/test/test_ll_os.py:83:         py.test.skip('posix specific function')
rpython/module/test/test_ll_os.py:154:             py.test.skip("no ttyname")
rpython/module/test/test_ll_termios.py:9:         py.test.skip("termios not found")
rpython/module/test/test_ll_os_path.py:37:         py.test.skip("XXX cannot run os.stat() on the llinterp yet")
lib/test2/test_array.py:37:             py.test.skip("array.array not picklable before python 2.5")
lib/test2/test_array.py:49:             py.test.skip("array.array constructor changed in 2.5")
lib/test2/test_array.py:78:             py.test.skip("requires CPython >= 2.5")
lib/test2/test_array.py:86:         py.test.skip("no 'u' type code in CPython's struct module")
lib/test2/test_array.py:89:         py.test.skip("pickle getting confused by the hack in setup_class()")
lib/test2/test_grp_extra.py:5:     py.test.skip("No grp module on this platform")
lib/distributed/test/test_greensock.py:11:             py.test.skip("Cannot run this on top of py.py because of PopenGateway")
lib/py/_test/pycollect.py:152:             py.test.skip("%r is disabled" %(self.obj,))
lib/py/_test/pycollect.py:184:             py.test.skip("%r is disabled" %(self.obj,))
lib/py/_test/config.py:221:         """ return getvalue() or call py.test.skip if no value exists. """
lib/py/_test/config.py:228:             py.test.skip("no %r value found" %(name,))
lib/py/_test/pluginmanager.py:69:             py.test.skip("plugin %r is missing" % name)
lib/py/_test/pluginmanager.py:140:         except py.test.skip.Exception:
lib/py/_plugin/pytest_capture.py:266:         py.test.skip("capfd funcarg needs os.dup")
lib/py/_plugin/pytest_restdoc.py:195:                     py.test.skip("html file is up to date, use --forcegen to regenerate")
lib/py/_plugin/pytest_restdoc.py:309:             py.test.skip("%s: %s" %(tryfn, str(e)))
lib/py/_plugin/pytest_skipping.py:146:             py.test.skip("unsuppored configuration")
lib/py/_plugin/pytest_skipping.py:205:         py.test.skip(evalskip.getexplanation())
lib/py/_plugin/pytest_skipping.py:210:                 py.test.skip("xfail")
lib/py/_plugin/pytest_pytester.py:274:             py.test.skip("no subprocess module")
lib/py/_plugin/pytest_pytester.py:358:             py.test.skip("need --tools-on-path to run py.test script")
lib/py/_plugin/pytest_runner.py:153:             elif excinfo.errisinstance(py.test.skip.Exception):
lib/py/_plugin/pytest_runner.py:196:             if excinfo.errisinstance(py.test.skip.Exception):
lib/py/_plugin/pytest_runner.py:398:     optionally specified 'minversion' - otherwise call py.test.skip() 
lib/py/_plugin/pytest_runner.py:405:         py.test.skip("could not import %r" %(modname,))
lib/py/_plugin/pytest_runner.py:414:         py.test.skip("module %r has __version__ %r, required is: %r" %(
lib/py/_plugin/pytest_nose.py:48:             # let's substitute the excinfo with a py.test.skip one 
lib/py/_plugin/pytest_nose.py:49:             call2 = call.__class__(lambda: py.test.skip(str(call.excinfo.value)), call.when)
lib/py/_plugin/pytest_pdb.py:20:            call.excinfo.errisinstance(py.test.skip.Exception): 
lib/app_test/ctypes_tests/test_win32.py:11:     py.test.skip("win32-only tests")
lib/app_test/ctypes_tests/test_cast.py:38:         py.test.skip("we make copies of strings")
lib/app_test/ctypes_tests/test_parameters.py:66:         py.test.skip("testing implementation internals")
lib/app_test/ctypes_tests/test_parameters.py:86:         py.test.skip("testing implementation internals")
lib/app_test/ctypes_tests/test_parameters.py:166:         py.test.skip("we implement details differently")
lib/app_test/ctypes_tests/test_keepalive.py:101:             py.test.skip("pypy white-box test")
lib/app_test/ctypes_tests/test_struct_fields.py:29:         py.test.skip("absent _fields_ semantics not implemented")
lib/app_test/ctypes_tests/test_struct_fields.py:36:         py.test.skip("subclassing semantics not implemented")
lib/app_test/ctypes_tests/test_struct_fields.py:44:         py.test.skip("subclassing semantics not implemented")
lib/app_test/ctypes_tests/test_keeprefs.py:14:         py.test.skip("we make copies of strings")
lib/app_test/ctypes_tests/test_keeprefs.py:35:         py.test.skip("we make copies of strings")        
lib/app_test/ctypes_tests/test_callbacks.py:92:         py.test.skip("we are less strict about callback return type sanity")
lib/app_test/ctypes_tests/test_callbacks.py:140:         py.test.skip("callbacks with struct arguments not implemented yet")
lib/app_test/ctypes_tests/test_structures.py:164:         py.test.skip("custom alignment not supported")
lib/app_test/ctypes_tests/test_structures.py:266:         py.test.skip("need unicode support on _rawffi level")
lib/app_test/ctypes_tests/test_structures.py:287:         py.test.skip("not implemented error details")
lib/app_test/ctypes_tests/test_structures.py:335:         py.test.skip("_abstract_ semantics not implemented")
lib/app_test/ctypes_tests/test_structures.py:361:         py.test.skip("subclassing semantics not implemented")
lib/app_test/ctypes_tests/test_structures.py:482:         py.test.skip("mutually dependent lazily defined structures error semantics")
lib/app_test/ctypes_tests/test_values.py:35:         py.test.skip("tests expect and access cpython dll")
lib/app_test/ctypes_tests/test_bitfields.py:8: py.test.skip("bitfields not supported")
lib/app_test/ctypes_tests/test_guess_argtypes.py:11:         py.test.skip("pypy white-box test")
lib/app_test/ctypes_tests/test_guess_argtypes.py:32:         py.test.skip("CPython segfaults: see http://bugs.python.org/issue5203")
lib/app_test/ctypes_tests/test_repr.py:21:         py.test.skip("reprs not implemented")
lib/app_test/ctypes_tests/test_repr.py:28:         py.test.skip("reprs not implemented")
lib/app_test/ctypes_tests/test_funcptr.py:45:         py.test.skip("cdecl funcptrs ignoring extra args is not implemented")
lib/app_test/ctypes_tests/test_funcptr.py:52:             py.test.skip("win32 related")
lib/app_test/ctypes_tests/test_funcptr.py:134:         py.test.skip("This test needs mmap to make sure the"
lib/app_test/ctypes_tests/conftest.py:6:         py.test.skip("these tests are meant to be run on top of pypy-c")
lib/app_test/ctypes_tests/test_numbers.py:81:         py.test.skip("testing implementation internals")
lib/app_test/ctypes_tests/test_numbers.py:87:         py.test.skip("testing implementation internals")
lib/app_test/ctypes_tests/test_init.py:4: py.test.skip("subclassing semantics and implementation details not implemented")
lib/app_test/ctypes_tests/test_simplesubclasses.py:29:         py.test.skip("subclassing semantics and implementation details not implemented")
lib/app_test/ctypes_tests/test_simplesubclasses.py:46:         py.test.skip("subclassing semantics and implementation details not implemented")
lib/app_test/ctypes_tests/test_varsize_struct.py:7:         py.test.skip("resizing not implemented")
lib/app_test/ctypes_tests/support.py:15:             py.test.skip("white-box tests for pypy _rawffi based ctypes impl")
lib/app_test/ctypes_tests/test_functions.py:396:         py.test.skip("we are less strict in checking callback parameters")
lib/app_test/ctypes_tests/test_stringptr.py:34:         py.test.skip("test passes! but modified to avoid getrefcount and detail issues")
lib/app_test/ctypes_tests/test_stringptr.py:50:         py.test.skip("test passes! but modified to avoid detail issues")
lib/app_test/test_marshal_extra.py:76:         py.test.skip("this version of CPython doesn't support this object") 
lib/app_test/test_marshal_extra.py:85:         py.test.skip("this version of CPython doesn't support this object") 
lib/app_test/test_marshal_extra.py:96:         py.test.skip("this version of CPython doesn't support this object") 
lib/app_test/test_marshal_extra.py:111:         py.test.skip("this version of CPython doesn't support this object") 
lib/app_test/test_marshal_extra.py:125:         py.test.skip("this version of CPython doesn't support this object") 
lib/app_test/test_marshal_extra.py:135:         py.test.skip("this version of CPython doesn't support this object") 
lib/app_test/test_locale.py:12:         py.test.skip("Locale support on MacOSX is minimal and cannot be tested")
lib/app_test/test_locale.py:26:             py.test.skip("test locale %s not supported" % cls.tloc)
lib/app_test/test_locale.py:32:         py.test.skip("XXX fix or kill me")
lib/app_test/test_locale.py:52:         py.test.skip("XXX fix or kill me")
lib/app_test/test_ctypes_support.py:11:     py.test.skip("this is expected on top of pypy, we need to fix ctypes in a way that is now in 2.6 in order to make this reliable")
lib/app_test/test_pyexpat.py:347:         py.test.skip("Not working")
lib/app_test/test_defaultdict.py:9:     py.test.skip("these tests only run on top of CPython 2.5")
lib/app_test/test_pickle_extra.py:6:         py.test.skip("test the _pickle_moduledict() addition to pickle.py")
lib/app_test/test_dbm_extra.py:6:     py.test.skip(e)
lib/pyrepl/test/test_functional.py:11:             py.test.skip(str(e))
interpreter/test/test_executioncontext.py:250:             py.test.skip("test is meant for running with py.test -A")
interpreter/test/test_zpy.py:95:         py.test.skip("cannot detect process exit code for now")
interpreter/test/test_compiler.py:712: ##        py.test.skip("unsupported")
interpreter/pyparser/test/test_parsestring.py:73:         #py.test.skip("crashes in app_codecs, but when cheating using .encode at interp-level passes?!")
translator/platform/test/test_distutils.py:10:         py.test.skip("Unsupported")
translator/platform/test/test_maemo.py:16:         py.test.skip("TestMaemo: tests skipped for now")
translator/platform/test/test_maemo.py:37:         py.test.skip("FIXME")
translator/platform/test/test_darwin.py:7:     py.test.skip("Darwin only")
translator/platform/test/test_darwin.py:52:             py.test.skip("i386 only")
translator/platform/test/test_darwin.py:76:             py.test.skip("i386 only")
translator/platform/test/test_darwin.py:94:             py.test.skip("i386 only")
translator/platform/maemo.py:11:         py.test.skip("No scratchbox detected")
translator/c/gcc/test/test_thread.py:9:             py.test.skip("mingw32 and MSYS are required for asmgcc on Windows")
translator/c/gcc/test/conftest.py:7:         py.test.skip("x86 directory skipped: cpu is %r" % (cpu,))
translator/c/gcc/test/test_asmgcroot.py:108:             py.test.skip("No libffi yet with mingw32")
translator/c/gcc/test/test_asmgcroot.py:217:             py.test.skip("mingw32 specific test")
translator/c/gcc/test/test_asmgcroot.py:220:             py.test.skip("mingw32 and MSYS are required for this test")
translator/c/gcc/test/test_asmgcroot.py:232:         py.test.skip("No libffi yet with mingw32")
translator/c/test/test_stackless.py:21:             py.test.skip("stackless + refcounting doesn't work any more for now")
translator/c/test/test_stackless.py:28:                 py.test.skip("Boehm GC not present")
translator/c/test/test_lltyped.py:253:         py.test.skip("we no longer pad our RPython strings with a final NUL")
translator/c/test/test_lltyped.py:723:             py.test.skip("not easy to test groups too big on 64-bit platforms")
translator/c/test/test_newgc.py:1062:         py.test.skip("not implemented")
translator/c/test/test_newgc.py:1076:         py.test.skip("Disabled for now")
translator/c/test/test_newgc.py:1079:         py.test.skip("not implemented")
translator/c/test/test_newgc.py:1082:         py.test.skip("not implemented")
translator/c/test/test_boehm.py:16:         py.test.skip("Boehm GC not present")
translator/c/test/test_lladdresses.py:158:         py.test.skip("'boehm' may crash")
translator/c/test/test_dlltool.py:5: py.test.skip("fix this if needed")
translator/c/test/test_standalone.py:108:             py.test.skip("instrumentation support is unix only for now")
translator/c/test/test_standalone.py:186:             py.test.skip("no profopt on win32")
translator/c/test/test_standalone.py:486:         py.test.skip("not implemented: "
translator/c/test/test_standalone.py:567:         py.test.skip("implement later, maybe: tracebacks even with ll_assert")
translator/c/test/test_standalone.py:608:         py.test.skip("TestMaemo: tests skipped for now")
translator/c/test/test_standalone.py:617:         py.test.skip("Unsupported")
translator/c/test/test_standalone.py:620:         py.test.skip("Unsupported")
translator/c/test/test_extfunc.py:97:         py.test.skip("this os has no ftruncate :-(")
translator/c/test/test_extfunc.py:115:         py.test.skip("this os has no ftruncate :-(")
translator/c/test/test_extfunc.py:178:         py.test.skip("no WindowsError on this platform")
translator/c/test/test_extfunc.py:191:         py.test.skip("segfault with tcc :-(")
translator/backendopt/test/test_canraise.py:207:         py.test.skip("ootype: no explicit stack checks raising RuntimeError")
translator/backendopt/test/test_constfold.py:189:     py.test.skip("do we want partial folding of getinteriorfield?")
translator/backendopt/test/test_mallocv.py:31:             py.test.skip(msg)
translator/backendopt/test/test_mallocv.py:632:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:644:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:662:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:751:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:762:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:818:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:828:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:838:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_mallocv.py:848:         py.test.skip("llptr support not really useful any more")
translator/backendopt/test/test_inline.py:60:             py.test.skip("ootypesystem doesn't support %s, yet" % reason)
translator/backendopt/test/test_malloc.py:19:             py.test.skip(msg)
translator/backendopt/test/test_malloc.py:220:         py.test.skip("fails because of the interior structure changes")
translator/backendopt/test/test_malloc.py:233:         py.test.skip("fails because of the interior structure changes")
translator/backendopt/test/test_malloc.py:287:         py.test.skip("fails because of the interior structure changes")
translator/backendopt/test/test_malloc.py:317:         py.test.skip("fails because of the interior structure changes")
translator/backendopt/test/test_malloc.py:372:         py.test.skip("fails")
translator/backendopt/test/test_malloc.py:436:         py.test.skip("oosend prevents malloc removal")
translator/backendopt/test/test_malloc.py:439:         py.test.skip("oosend prevents malloc removal")
translator/jvm/test/test_rarithmetic.py:40:         py.test.skip("rpython has no ** on ints")
translator/jvm/test/test_rarithmetic.py:45:         py.test.skip("divmod not fully supported by rtyper")
translator/jvm/test/test_rarithmetic.py:50: #        py.test.skip("rpython has no ** on ints")
translator/jvm/test/test_rarithmetic.py:52: #        py.test.skip("divmod not fully supported by rtyper")
translator/jvm/test/test_dict.py:7:         py.test.skip("test_resize_during_iteration() doesn't work yet")
translator/jvm/test/test_dict.py:10:         py.test.skip("fixme: the hashCode method of Records is not good enough")
translator/jvm/test/test_dict.py:13:         py.test.skip("JVM doesn't support recursive dicts")
translator/jvm/test/test_backendopt.py:13:         py.test.skip('fixme!')
translator/jvm/test/test_backendopt.py:16:         py.test.skip('fixme!')
translator/jvm/test/test_class.py:7:         py.test.skip("JVM doesn't support overridden default value yet")
translator/jvm/test/test_class.py:28:         py.test.skip('ABSTRACT METHOD FIX: RE-TEST AFTER MERGE')
translator/jvm/test/runtest.py:65:             py.test.skip("Assembly disabled")
translator/jvm/test/runtest.py:68:             py.test.skip("Execution disabled")
translator/jvm/test/runtest.py:71: #            py.test.skip("Compilation disabled")
translator/jvm/test/runtest.py:74: #            py.test.skip("Execution disabled")
translator/jvm/test/runtest.py:81:             py.test.skip("Assembly disabled")
translator/jvm/test/runtest.py:84:             py.test.skip("Execution disabled")
translator/jvm/test/runtest.py:122:             py.test.skip('Windows --> %s' % reason)
translator/jvm/test/runtest.py:126:             py.test.skip('PowerPC --> %s' % reason)
translator/jvm/test/runtest.py:175:         py.test.skip("read_attr not supported on JVM")
translator/jvm/test/test_unicode.py:17:         py.test.skip("JVM doesn't support unicode for command line arguments")
translator/jvm/test/test_unicode.py:24:         py.test.skip('fixme!')
translator/jvm/test/test_runtest.py:7:         py.test.skip('fixme!')
translator/jvm/test/test_builtin.py:13:         py.test.skip("fails in annotation stage, unrelated to JVM I think")
translator/jvm/test/test_builtin.py:16:         py.test.skip("fails in annotation stage, unrelated to JVM I think")
translator/jvm/test/test_builtin.py:19:         py.test.skip("test N/A to jvm: replaced by test_os_dup_oo")
translator/jvm/test/test_builtin.py:22:         py.test.skip('fixme! how to set environment variables in Java?') 
translator/jvm/test/test_builtin.py:25:         py.test.skip('fixme!')
translator/jvm/test/test_builtin.py:28:         py.test.skip("so far, debug_llinterpcall is only used on lltypesystem")
translator/jvm/test/test_builtin.py:33:             py.test.skip('bug in JDK when run headless: ' +
translator/jvm/test/test_builtin.py:38:         py.test.skip('fixme!')
translator/jvm/test/test_string.py:10:         py.test.skip("JVM doesn't support unicode for command line arguments")
translator/jvm/test/test_string.py:18:         py.test.skip("eval has trouble with evaluation of null literals")
translator/jvm/test/test_string.py:26:         py.test.skip("test fails in JVM specific way")
translator/jvm/test/test_float.py:24:         py.test.skip("not implemented: single-precision floats")
translator/jvm/test/test_list.py:7:         py.test.skip("JVM doesn't support recursive lists")
translator/jvm/test/test_list.py:10:         py.test.skip('fixme!')
translator/jvm/test/test_list.py:13:         py.test.skip('fixme!')
translator/jvm/conftest.py:6:         py.test.skip("jvm backend on 64bit unsupported")
translator/jvm/genjvm.py:228:             py.test.skip("%s is not on your path" % exechelper)
translator/cli/test/test_dict.py:7:         py.test.skip("CLI doesn't support recursive dicts")
translator/cli/test/test_dict.py:10:         py.test.skip("CLI doesn't support recursive dicts")
translator/cli/test/test_op.py:11:         py.test.skip('fixme!')
translator/cli/test/runtest.py:220:             py.test.skip("Compilation disabled")
translator/cli/test/runtest.py:223:             py.test.skip("Execution disabled")
translator/cli/test/runtest.py:305:             py.test.skip('Windows --> %s' % reason)
translator/cli/test/runtest.py:309:             py.test.skip('PowerPC --> %s' % reason)
translator/cli/test/runtest.py:361:         py.test.skip('read_attr not supported on gencli tests')
translator/cli/test/test_dotnet.py:279:         py.test.skip('Mono bug :-(')
translator/cli/test/test_dotnet.py:560:         py.test.skip("broken test, but this feature is unused so far, so it's not worth fixing it")
translator/cli/test/test_dotnet.py:715:         py.test.skip(msg)
translator/cli/test/test_unicode.py:12:         py.test.skip("CLI interpret doesn't support unicode for input arguments")
translator/cli/test/test_unicode.py:20:         py.test.skip('fixme!')
translator/cli/test/test_unicode.py:23:         py.test.skip("CLI tests can't have string as input arguments")
translator/cli/test/test_builtin.py:8:     py.test.skip("CLI doesn't support the os module, yet")
translator/cli/test/test_builtin.py:12:         py.test.skip("Doesn't work on Windows, yet")
translator/cli/test/test_builtin.py:25:         py.test.skip("so far, debug_llinterpcall is only used on lltypesystem")
translator/cli/test/test_string.py:10:         py.test.skip("CLI interpret doesn't support unicode for input arguments")
translator/cli/test/test_string.py:18:         py.test.skip("CLI doens't support backquotes inside string literals")
translator/cli/test/test_string.py:22:         py.test.skip("CLI tests can't have string as input arguments")
translator/cli/test/test_string.py:27:         py.test.skip('fixme!')
translator/cli/test/test_float.py:26:         py.test.skip("not implemented: single-precision floats")
translator/cli/test/test_list.py:8:         py.test.skip("CLI doesn't support recursive lists")
translator/cli/test/test_list.py:11:         py.test.skip('fixme!')
translator/cli/test/test_snippet.py:7:         py.test.skip('llshl currently broken on CLI')
translator/cli/test/test_carbonpython.py:2: py.test.skip("it passes usually, but fails on buildbot, no clue why")
translator/cli/test/test_carbonpython.py:111:         py.test.skip('This test fails every other day. No clue why :-(')
translator/cli/test/test_carbonpython.py:132:         py.test.skip('it fails every other day on builbot, no clue why')
translator/cli/test/test_carbonpython.py:150:         py.test.skip('This test fails every other day. No clue why :-(')
translator/cli/test/test_objectmodel.py:7:     py.test.skip('r_dict support is still incomplete')
translator/cli/sdk.py:8:             py.test.skip("%s is not on your path." % helper)
translator/cli/support.py:16:             py.test.skip('Must use pythonnet for being able to access .NET libraries')
translator/tool/test/test_cbuild.py:99:             py.test.skip("Need ctypes for that test")
translator/tool/test/test_cbuild.py:127:             py.test.skip("sdl-config not installed")
translator/test/test_exceptiontransform.py:16:         py.test.skip("test needs a debug build of Python")
translator/sandbox/test/test_sandlib.py:64:     py.test.skip("to be updated")
translator/sandbox/test/test_sandbox.py:177:     py.test.skip("Since this stuff is unimplemented, it won't work anyway "
translator/goal/test2/test_targetpypy.py:11:         py.test.skip("not working so far")
translator/goal/test2/test_app_main.py:66:             py.test.skip(str(e))
translator/goal/test2/test_app_main.py:78:                 py.test.skip(
translator/goal/test2/test_app_main.py:270:         py.test.skip("this can only work if readline is enabled")
translator/goal/test2/test_app_main.py:302:         py.test.skip("obscure difference with CPython -- do we care?")
translator/oosupport/test/test_treebuilder.py:45:     py.test.skip('fixme!')
translator/oosupport/test_template/class_.py:68:         py.test.skip('cannot return ootype.NULL from translated functions')
translator/stackless/test/test_clone.py:7:     import py; py.test.skip("to be rewritten with gc_x_clone")
translator/stackless/test/test_resume_point.py:254:     py.test.skip("please don't write code like this")
module/zipimport/test/test_zipimport.py:271:             py.test.skip("zlib not available, cannot test compressed zipfiles")
module/posix/test/test_posix2.py:37:         py.test.skip("no sparse files on default Mac OS X file system")
module/posix/test/test_posix2.py:39:         py.test.skip("no sparse files on Windows")
module/posix/test/test_posix2.py:671:                 py.test.skip("encoding not good enough")
module/posix/test/test_posix2.py:710:             py.test.skip("pexpect not found")
module/_winreg/test/test_winreg.py:7:     py.test.skip("_winreg is a win32 module")
module/_locale/test/test_locale.py:38:                 py.test.skip("necessary locales not installed")
module/pypyjit/test/test_pypy_c.py:112:             py.test.skip("XXX this is not Windows-friendly")
module/pypyjit/test/test_pypy_c.py:489:         py.test.skip("exceptions: in-progress")
module/pypyjit/test/test_pypy_c.py:511:         py.test.skip("exceptions: in-progress")
module/pypyjit/test/test_pypy_c.py:621:             py.test.skip("meant only for pypy-c")
module/pypyjit/test/test_pypy_c.py:632:             py.test.skip("pass --pypy!")
module/pypyjit/test/test_pypy_c.py:634:             py.test.skip("must give a pypy-c with the jit enabled")
module/signal/test/test_interp_signal.py:8:         py.test.skip("requires os.kill() and os.getpid()")
module/signal/test/test_signal.py:8:             py.test.skip("requires os.kill() and os.getpid()")
module/pyexpat/test/test_build.py:12:     py.test.skip("No module expat")
module/pyexpat/test/test_build.py:17:     py.test.skip("Expat not installed")
module/_minimal_curses/test/test_curses.py:13:         py.test.skip("Cannot test this here")
module/_minimal_curses/test/test_curses.py:34:             py.test.skip('pexpect not found')
module/_minimal_curses/__init__.py:7:         import py; py.test.skip("no _curses module")    # no _curses at all
module/math/test/test_direct.py:216:             py.test.skip("inconsistent behavior before 2.6")
module/__pypy__/test/test_special.py:7:             py.test.skip("does not make sense on pypy-c")
module/clr/test/test_clr.py:9:         py.test.skip('Must use pythonnet to access .NET libraries')
module/termios/test/test_termios.py:13:             py.test.skip("Pexpect not found")
module/termios/test/test_termios.py:17:             py.test.skip("termios not found")
module/readline/test/test_c_readline.py:12:     py.test.skip(e)
module/readline/test/test_with_pypy.py:13:     py.test.skip(e)
module/oracle/test/test_connect.py:16:             py.test.skip(
module/_socket/test/test_sock_app.py:14:     mod.skip = py.test.skip
module/_socket/test/test_sock_app.py:55:         py.test.skip("getservbyname second argument is not optional before python 2.4")
module/_socket/test/test_sock_app.py:62:         py.test.skip("getservbyport does not exist before python 2.4")
module/_socket/test/test_sock_app.py:90:         py.test.skip("No socket.fromfd on this platform")
module/_socket/test/test_sock_app.py:150:         py.test.skip('No socket.inet_pton on this platform')
module/_socket/test/test_sock_app.py:166:         py.test.skip('No socket.inet_pton on this platform')
module/_socket/test/test_sock_app.py:168:         py.test.skip("No IPv6 on this platform")
module/_socket/test/test_sock_app.py:187:         py.test.skip('No socket.inet_pton on this platform')
module/_socket/test/test_sock_app.py:189:         py.test.skip("No IPv6 on this platform")
module/_socket/test/test_sock_app.py:208:     py.test.skip("has_ipv6 is always True on PyPy for now")
module/_socket/test/test_sock_app.py:219:     py.test.skip("Unicode conversion is too slow")
module/cpyext/test/test_unicodeobject.py:137:             py.test.skip("mcbs encoding only exists on Windows")
module/cpyext/test/conftest.py:6:         py.test.skip("cannot be run by py.test -A")
module/_file/test/test_file.py:172:             py.test.skip("likely to deadlock when interpreted by py.py")
module/imp/test/test_import.py:772:         py.test.skip("unresolved issues with win32 shell quoting rules")
module/select/test/test_select.py:217:             py.test.skip("select() doesn't work with pipes on win32")
module/__builtin__/test/test_classobj.py:774:             py.test.skip("can only be run on py.py")
module/__builtin__/test/test_classobj.py:794:             py.test.skip("can only be run on py.py")
module/_stackless/test/test_choicepoint.py:1: import py; py.test.skip("clonable coroutines not really maintained any more")
module/_stackless/test/test_clonable.py:1: import py; py.test.skip("clonable coroutines not really maintained any more")
module/_stackless/test/test_clonable.py:12:             py.test.skip('pure appdirect test (run with -A)')
module/_stackless/test/test_clonable.py:18:             py.test.skip('no _stackless.clonable')
module/_stackless/test/test_interp_clonable.py:4: import py; py.test.skip("clonable coroutines not really maintained any more")
module/_stackless/test/test_pickle.py:23:             py.test.skip('pure appdirect test (run with -A)')
module/zlib/test/test_zlib.py:9:     import py; py.test.skip("no zlib module on this host Python")
module/zlib/test/test_zlib.py:14:     import py; py.test.skip("no zlib C library on this machine")
module/_sre/test/test_app_sre.py:291:         except py.test.skip.Exception:
module/_sre/test/test_app_sre.py:551:         except py.test.skip.Exception:
annotation/test/test_signature.py:11:     py.test.skip("this two annotations should be equal - fix!")
annotation/test/test_annrpython.py:2585:         py.test.skip("_annenforceargs_ does not work for default arguments")
conftest.py:58:         py.test.skip(str(e))
conftest.py:67:                     py.test.skip("cannot runappdirect test: "
conftest.py:116:                             py.test.skip("cannot runappdirect test: "
conftest.py:120:                         py.test.skip("no module __pypy__ on top of CPython")
conftest.py:123:                 py.test.skip("cannot runappdirect this test on top of CPython")
conftest.py:127:                 py.test.skip("cannot runappdirect test: space needs %s = %s, "\
conftest.py:176:         py.test.skip("translation test, skipped for appdirect")
conftest.py:285:         py.test.skip("not running on translated pypy "
conftest.py:293:     py.test.skip("need translated pypy with: %s, got %s" 
conftest.py:360:                         py.test.skip('%s: %s' % (e.__class__.__name__, e))
conftest.py:536:             py.test.skip("pexpect not found")

From anto.cuni at gmail.com  Wed May 26 16:55:07 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 26 May 2010 16:55:07 +0200
Subject: [pypy-dev] virtualenv support and directory hierarchy
Message-ID: <4BFD364B.5030903@gmail.com>

Hi all,

I am investigating how to make virtualenv working on pypy and I'm running into 
a couple of issues: the most important one is that virtualenv relies on 
sys.prefix (which does not exists in pypy) to find the standard library, and 
the other is that the standard library of pypy is supposed to be put in 
/usr/share instead of /usr/lib (or /usr/local/*).

Currently, a pypy installation is supposed to have this structure:
         /usr/bin/pypy-c
         /usr/share/pypy-1.2/pypy/lib/
         /usr/share/pypy-1.2/lib-python/modified-2.5.2
         /usr/share/pypy-1.2/lib-python/2.5.2

In such a situation, sys.pypy_prefix is set to '/usr/share/pypy-1.2'.

I propose to change it in this way:
         /usr/bin/pypy-c
         /usr/lib/pypy1.2/lib-pypy/
         /usr/lib/pypy1.2/lib-python/modified-2.5.2
         /usr/lib/pypy1.2/lib-python/2.5.2

where lib-pypy contains what it's now in pypy/lib.
In such a situation, sys.prefix would be set to '/usr', in a similar way as 
cpython.  Also, we should also add a sys.exec_prefix which is meant to be 
always equal to sys.prefix (at least for now).
(I removed the dash in pypy-1.2 for consistency with cpython, which uses 
something like lib/python2.6).


Moreover, I would also like virtualenv to work from an svn checkout/source 
tarball of pypy, without any needing of installing it system-wide. To do so, 
we need to find a sensible value for sys.prefix, considering that tools like 
virtualenv suppose to find the stdlib under sys.prefix+'lib/'+something_else.

So, the proposed new structure is this:

         /path/to/pypy-trunk/
         /path/to/pypy-trunk/lib/pypy1.2/{lib-pypy,modified-2.5.2,2.5.2}
         sys.prefix == '/path/to/pypy-trunk'

The drawback is that before getting to the real files you have to walk a lot 
of empty directories, and that we should manually change the name of pypy1.2 
each time we increase the version number (not that it happens very often :-)).
One side-advantage is that in this way we would move pypy/lib outside the main 
pypy package, which is good because it's not really a part of it.

Finally, we should probably think of where to put the include/ directory (plus 
other that might be needed to build extension), but I'll let cpyext experts to 
say what it's better :-)

What do you think? Any comment/suggestion/problem that I overlooked?

ciao,
Anto

From arigo at tunes.org  Thu May 27 11:40:43 2010
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 27 May 2010 11:40:43 +0200
Subject: [pypy-dev] PyPy in the news
In-Reply-To: <20100521193546.GA9967@code0.codespeak.net>
References: <AANLkTin0h9JjlUZunDQ5o_TqvK_O34sOu7dWmBMU36T_@mail.gmail.com>
	<AANLkTinrxuVg0BxxEPotp2mSPcUd2gHj9_y1P1cGa7zt@mail.gmail.com>
	<AANLkTinD6gew5T2KW3ZtUxIjVKhxmZj0d4ZyDoa81cs0@mail.gmail.com>
	<201005212123.44628.jacob@openend.se>
	<20100521193546.GA9967@code0.codespeak.net>
Message-ID: <20100527094043.GA9763@code0.codespeak.net>

Hi Jacob,

On Fri, May 21, 2010 at 09:35:46PM +0200, Armin Rigo wrote:
> > I was not allowed to use the
> > term Just-In-Time Compiler, so what we have actually done is quite
> > cryptic.
> 
> It is of course your choice and I have nothing to say against it, but in
> the same position of being interviewed under the condition that I don't
> use this or that term (whether it's appropriate or not), I would decline
> to make any comment, whoever the interviewer is.

Sorry about that comment.  I learned later that the reason is actually
just that it's really a computer tabloid style of magazine -- you were
not allowed to mention "Just-in-Time Compiler" just because it would
sound far too technical.


A bientot,

Armin.

From arigo at tunes.org  Thu May 27 11:52:20 2010
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 27 May 2010 11:52:20 +0200
Subject: [pypy-dev] access to pypy version info, internals
In-Reply-To: <20100517093847.GM17693@trillke.net>
References: <20100517093847.GM17693@trillke.net>
Message-ID: <20100527095220.GA10535@code0.codespeak.net>

Hi Holger,

On Mon, May 17, 2010 at 11:38:47AM +0200, holger krekel wrote:
> What about rather doing a single clean 'sys.pypy' module namespace such 
> that we can do: 
> 
>     a) hasattr(sys, 'pypy')
>     b) sys.pypy.version_info >= (x,y)
>     c) expose the __pypy__ builtin module as sys.pypy?  
> 
> Semantically, the sys module already presents an interaction 
> API with the interpreter.  Doing a single namespace looks more
> elegant to me than of cluttering sys with an artifical 'pypy_*' 
> prefixed namespace and having to (try-except)import __pypy__. 

You don't have to put the "import __pypy__" in a try-except, if you
already checked that "__pypy__" in sys.builtin_module_names.  But your
solution looks clean, and the point a) becomes shorter too :-)

I would like to avoid having the semi-internal interface of PyPy change
nearly as much as, say, the one from the py lib one (and I'm not
exagerating there: there are *6* different versions of "try: from
py.internal.stuff import x" in my own conftest.py :-) .  That said, your
suggestion seems nice enough.  Comments from others?


A bientot,

Armin.

From holger at merlinux.eu  Thu May 27 11:57:07 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 27 May 2010 11:57:07 +0200
Subject: [pypy-dev] access to pypy version info, internals
In-Reply-To: <20100527095220.GA10535@code0.codespeak.net>
References: <20100517093847.GM17693@trillke.net>
	<20100527095220.GA10535@code0.codespeak.net>
Message-ID: <20100527095707.GW17693@trillke.net>

On Thu, May 27, 2010 at 11:52 +0200, Armin Rigo wrote:
> I would like to avoid having the semi-internal interface of PyPy change
> nearly as much as, say, the one from the py lib one (and I'm not
> exagerating there: there are *6* different versions of "try: from
> py.internal.stuff import x" in my own conftest.py :-) .  

Hehe, how many years worth of versions do you use of pylib?  
To my defense I'd like to note that through all those years 
the documented/public API hardly changed, though :)

holger

From cfbolz at gmx.de  Thu May 27 16:34:09 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 27 May 2010 16:34:09 +0200
Subject: [pypy-dev] xfail versus skips
In-Reply-To: <20100525202220.GO17693@trillke.net>
References: <20100525202220.GO17693@trillke.net>
Message-ID: <4BFE82E1.1000203@gmx.de>

Hi all,

On 05/25/2010 10:22 PM, holger krekel wrote:
> i just released py.test-1.3.1 [1] which is inlined as svn/pypy/trunk/py
> and the pypy/test_all.py script is an alias for "py.test".  This release
> particularly refines "expected-to-fail" aka "xfail" semantics:
>
>      # abort setup or test function, reporting as "expected to fail", or 'x'
>      py.test.xfail() or py.test.xfail(reason)
>
> see http://codespeak.net/py/dist/test/plugin/skipping.html
> for more details.  Marking tests as 'xfail' is also good for
> tests that *sometimes* fail.
>
> I just did a grep of "py.test.skip" in pypy/trunk/pypy and
> there are 468 occurences [2].  Many of these skips seem to be because
> of implementation issues rather than platform/dependency mismatches
> and should thus rather use py.test.xfail.  Being Skips kind of hides
> those issues between the rightful skips.  The xfail/skip distinction is
> something that is happening in other parts of the Python world as well
> and i hope you find it useful as well.

I think another thing is that many of the tests that are now skipped 
should really be deleted, because they are completely outdated or 
because it just does not make sense to support them.

Cheers,

Carl Friedrich

From fijall at gmail.com  Thu May 27 16:45:07 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 27 May 2010 08:45:07 -0600
Subject: [pypy-dev] xfail versus skips
In-Reply-To: <4BFE82E1.1000203@gmx.de>
References: <20100525202220.GO17693@trillke.net> <4BFE82E1.1000203@gmx.de>
Message-ID: <AANLkTimsHgHEYh9GkblNUYNG6CtAoC2qQF4SlS5dfxUd@mail.gmail.com>

On Thu, May 27, 2010 at 8:34 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Hi all,
>
> On 05/25/2010 10:22 PM, holger krekel wrote:
>> i just released py.test-1.3.1 [1] which is inlined as svn/pypy/trunk/py
>> and the pypy/test_all.py script is an alias for "py.test". ?This release
>> particularly refines "expected-to-fail" aka "xfail" semantics:
>>
>> ? ? ?# abort setup or test function, reporting as "expected to fail", or 'x'
>> ? ? ?py.test.xfail() or py.test.xfail(reason)
>>
>> see http://codespeak.net/py/dist/test/plugin/skipping.html
>> for more details. ?Marking tests as 'xfail' is also good for
>> tests that *sometimes* fail.
>>
>> I just did a grep of "py.test.skip" in pypy/trunk/pypy and
>> there are 468 occurences [2]. ?Many of these skips seem to be because
>> of implementation issues rather than platform/dependency mismatches
>> and should thus rather use py.test.xfail. ?Being Skips kind of hides
>> those issues between the rightful skips. ?The xfail/skip distinction is
>> something that is happening in other parts of the Python world as well
>> and i hope you find it useful as well.
>
> I think another thing is that many of the tests that are now skipped
> should really be deleted, because they are completely outdated or
> because it just does not make sense to support them.
>

... but the sheer number of skips means that we don't even want to
look at them (which was the xfail part trying to mitigate).

Cheers,
fijal

From giallu at gmail.com  Sat May 29 16:38:52 2010
From: giallu at gmail.com (Gianluca Sforna)
Date: Sat, 29 May 2010 16:38:52 +0200
Subject: [pypy-dev] PyPy in Fedora
Message-ID: <AANLkTimsj6sU6qrdFm7MKU4r8NE96U8BX_y6bYB8w_EW@mail.gmail.com>

Fedora is working to include PyPy in the distribution, I guess some of
you may be interested in some pointers:

Review request for the PyPy package:
https://bugzilla.redhat.com/show_bug.cgi?id=588941

Possible feature targeting Fedora 14:
https://fedoraproject.org/wiki/Features/PyPyStack

Fedora Python SIG:
http://fedoraproject.org/wiki/SIGs/Python

Cheers

G.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

From fijall at gmail.com  Sat May 29 17:24:50 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 29 May 2010 09:24:50 -0600
Subject: [pypy-dev] PyPy in Fedora
In-Reply-To: <AANLkTimsj6sU6qrdFm7MKU4r8NE96U8BX_y6bYB8w_EW@mail.gmail.com>
References: <AANLkTimsj6sU6qrdFm7MKU4r8NE96U8BX_y6bYB8w_EW@mail.gmail.com>
Message-ID: <AANLkTikglZCukpALyOcIYpWIkzaaBL7WHinjd_eLJ7uH@mail.gmail.com>

Hello.

It's great that fedora is doing that! However, is it possible to delay
it until we have 1.2.1 release? It will contain some important
bugfixes.

On Sat, May 29, 2010 at 8:38 AM, Gianluca Sforna <giallu at gmail.com> wrote:
> Fedora is working to include PyPy in the distribution, I guess some of
> you may be interested in some pointers:
>
> Review request for the PyPy package:
> https://bugzilla.redhat.com/show_bug.cgi?id=588941
>
> Possible feature targeting Fedora 14:
> https://fedoraproject.org/wiki/Features/PyPyStack
>
> Fedora Python SIG:
> http://fedoraproject.org/wiki/SIGs/Python
>
> Cheers
>
> G.
>
> --
> Gianluca Sforna
>
> http://morefedora.blogspot.com
> http://www.linkedin.com/in/gianlucasforna
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Sat May 29 17:35:36 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 29 May 2010 09:35:36 -0600
Subject: [pypy-dev] PyPy in Fedora
In-Reply-To: <AANLkTikglZCukpALyOcIYpWIkzaaBL7WHinjd_eLJ7uH@mail.gmail.com>
References: <AANLkTimsj6sU6qrdFm7MKU4r8NE96U8BX_y6bYB8w_EW@mail.gmail.com> 
	<AANLkTikglZCukpALyOcIYpWIkzaaBL7WHinjd_eLJ7uH@mail.gmail.com>
Message-ID: <AANLkTikw6lweW3gp57HhDUwvRJTBGzj9EqYLTY4JAJrs@mail.gmail.com>

Ah, ok, didn't read the post in details. You're targeting svn trunk.
That has a bit of it's own problems, but it's probably slightly better
than using 1.2

On Sat, May 29, 2010 at 9:24 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Hello.
>
> It's great that fedora is doing that! However, is it possible to delay
> it until we have 1.2.1 release? It will contain some important
> bugfixes.
>
> On Sat, May 29, 2010 at 8:38 AM, Gianluca Sforna <giallu at gmail.com> wrote:
>> Fedora is working to include PyPy in the distribution, I guess some of
>> you may be interested in some pointers:
>>
>> Review request for the PyPy package:
>> https://bugzilla.redhat.com/show_bug.cgi?id=588941
>>
>> Possible feature targeting Fedora 14:
>> https://fedoraproject.org/wiki/Features/PyPyStack
>>
>> Fedora Python SIG:
>> http://fedoraproject.org/wiki/SIGs/Python
>>
>> Cheers
>>
>> G.
>>
>> --
>> Gianluca Sforna
>>
>> http://morefedora.blogspot.com
>> http://www.linkedin.com/in/gianlucasforna
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>

From fijall at gmail.com  Sat May 29 19:32:42 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 29 May 2010 11:32:42 -0600
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
	pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
	pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <20100528135356.6E7D6282BD6@codespeak.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
Message-ID: <AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>

Hm.

I might be missing something, but I thought sys.prefix is only meant
for stuff after installation. If this is true (my CPython trunk build
has sys.prefix == '/usr/local'), then modifying source checkout does
not make any sense, since it's only about installation (which we don't
really support anyway).

On Fri, May 28, 2010 at 7:53 AM,  <antocuni at codespeak.net> wrote:
> Author: antocuni
> Date: Fri May 28 15:53:54 2010
> New Revision: 74850
>
> Added:
> ? pypy/branch/sys-prefix/lib/
> ? pypy/branch/sys-prefix/lib/README
> ? pypy/branch/sys-prefix/lib/pypy1.2/
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/
> ? ? ?- copied from r74817, pypy/branch/sys-prefix/pypy/lib/
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/_sre.py
> ? ? ?- copied unchanged from r74837, pypy/branch/sys-prefix/pypy/lib/_sre.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/py ? (contents, props changed)
> Removed:
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/autopath.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/identity_dict.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/test2/test_identitydict.py
> Modified:
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/__init__.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/inprogress_test_binascii_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_binascii.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_coroutine.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_ctypes_support.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_datetime.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_dbm_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_defaultdict.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_deque_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_exception_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_functools.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_hashlib.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_locale.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_marshal_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_md5_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_pyexpat.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_resource.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_runpy.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_sha_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_stackless.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_stackless_pickling.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_struct_extra.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_structseq.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_syslog.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/hashlib.ctc.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/locale.ctc.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/pyexpat.ctc.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/rebuild.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/resource.ctc.py
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/syslog.ctc.py
> Log:
> move pypy/lib/ to lib/pypy1.2/lib_pypy (part 1 of many).
> The final goal is to be able to use pypy-trunk as sys.prefix, so
> pypy-trunk/lib plays the role of /usr/lib in a normal system-wide installation.
>
> Since pypy.lib is no longer directly importable, all the tests in app_test now
> rely on relative imports to import the modules they are testing.
>
> There are still issues left; e.g., test_runpy fails, and the app-level tests
> in test2 should be moved somewhere else, because they need pypy/conftest.py to
> work
>
>
>

From holger at merlinux.eu  Sat May 29 22:25:21 2010
From: holger at merlinux.eu (holger krekel)
Date: Sat, 29 May 2010 22:25:21 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:	.
	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
Message-ID: <20100529202521.GA17693@trillke.net>

On Sat, May 29, 2010 at 11:32 -0600, Maciej Fijalkowski wrote:
> Hm.
> 
> I might be missing something, but I thought sys.prefix is only meant
> for stuff after installation. If this is true (my CPython trunk build
> has sys.prefix == '/usr/local'), then modifying source checkout does
> not make any sense, since it's only about installation (which we don't
> really support anyway).

I think the idea is to make sys.prefix (and thus virtualenv) work 
even with a translation in a checkout, i.e. not forcing to copy 
things to another location (which virtualenv partly does on its own).  
Moreover, keeping app-level modules (and maybe pypy/module at some point)
outside the main (interpreter, objspaces, translation and JIT) PyPy tree 
makes sense to me.  e.g. pypy/lang would probably not need to access anything
outside such a pypy tree, for example, or am i mistaken? 

best,
holger
 
> On Fri, May 28, 2010 at 7:53 AM,  <antocuni at codespeak.net> wrote:
> > Author: antocuni
> > Date: Fri May 28 15:53:54 2010
> > New Revision: 74850
> >
> > Added:
> > ? pypy/branch/sys-prefix/lib/
> > ? pypy/branch/sys-prefix/lib/README
> > ? pypy/branch/sys-prefix/lib/pypy1.2/
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/
> > ? ? ?- copied from r74817, pypy/branch/sys-prefix/pypy/lib/
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/_sre.py
> > ? ? ?- copied unchanged from r74837, pypy/branch/sys-prefix/pypy/lib/_sre.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/py ? (contents, props changed)
> > Removed:
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/autopath.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/identity_dict.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/test2/test_identitydict.py
> > Modified:
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/__init__.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/inprogress_test_binascii_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_binascii.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_coroutine.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_ctypes_support.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_datetime.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_dbm_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_defaultdict.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_deque_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_exception_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_functools.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_hashlib.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_locale.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_marshal_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_md5_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_pyexpat.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_resource.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_runpy.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_sha_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_stackless.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_stackless_pickling.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_struct_extra.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_structseq.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/app_test/test_syslog.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/hashlib.ctc.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/locale.ctc.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/pyexpat.ctc.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/rebuild.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/resource.ctc.py
> > ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/syslog.ctc.py
> > Log:
> > move pypy/lib/ to lib/pypy1.2/lib_pypy (part 1 of many).
> > The final goal is to be able to use pypy-trunk as sys.prefix, so
> > pypy-trunk/lib plays the role of /usr/lib in a normal system-wide installation.
> >
> > Since pypy.lib is no longer directly importable, all the tests in app_test now
> > rely on relative imports to import the modules they are testing.
> >
> > There are still issues left; e.g., test_runpy fails, and the app-level tests
> > in test2 should be moved somewhere else, because they need pypy/conftest.py to
> > work
> >
> >
> >
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
-- 

From anto.cuni at gmail.com  Sat May 29 23:57:16 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 29 May 2010 23:57:16 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
 pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
 pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
Message-ID: <4C018DBC.90404@gmail.com>

Hi Maciek,

On 29/05/10 19:32, Maciej Fijalkowski wrote:
> Hm.
> 
> I might be missing something, but I thought sys.prefix is only meant
> for stuff after installation. If this is true (my CPython trunk build
> has sys.prefix == '/usr/local'), then modifying source checkout does
> not make any sense, since it's only about installation (which we don't
> really support anyway).

you are partly right. In CPython, sys.prefix is just an hard-coded string that
represent what was passed to ./configure; tools like virtualenv use it to find
the directories containing the stdlib, include files, etc. on the filesystem
(I'm not sure it's an entirely good idea, but this is the state of the things
and we have to face it).

However, nothing prevents the interpreter to set sys.prefix dynamically, e.g.
by searching for the directory that contains the stdlib in some location
relative to the pypy-c binary; this is what pypy-c does it already to set
sys.path.

The point of this branch is both:

1) to make it easier to install pypy system-wide: it will be enough to copy
pypy-c in /usr/bin and lib/pypy1.2 in /usr/lib (and of course we can automate
this with a script, if we want)

2) as holger pointed out, to make it possible to use virtualenv *without*
having to install pypy system-wide (which you cannot do with cpython, for
example): this will be possible because the directory hierarchy of the svn
checkout is designed in a way that setting sys.prefix to the the root of the
svn checkout will "just work"

ciao,
Anto

From anto.cuni at gmail.com  Sat May 29 23:59:25 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 29 May 2010 23:59:25 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
 pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
 pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <20100529202521.GA17693@trillke.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net>
Message-ID: <4C018E3D.1070705@gmail.com>

Hi holger,

On 29/05/10 22:25, holger krekel wrote:

> I think the idea is to make sys.prefix (and thus virtualenv) work 
> even with a translation in a checkout, i.e. not forcing to copy 
> things to another location (which virtualenv partly does on its own).  

yes

> Moreover, keeping app-level modules (and maybe pypy/module at some point)
> outside the main (interpreter, objspaces, translation and JIT) PyPy tree 
> makes sense to me.  e.g. pypy/lang would probably not need to access anything
> outside such a pypy tree, for example, or am i mistaken? 

I agree that keeping app-level modules out of pypy is a good idea (this is
what I'm doing it, of course :-)), but I don't get what does the reference to
pypy/lang mean in this context.

ciao,
Anto

From fijall at gmail.com  Sun May 30 00:08:42 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 29 May 2010 16:08:42 -0600
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
	pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
	pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <4C018DBC.90404@gmail.com>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com> 
	<4C018DBC.90404@gmail.com>
Message-ID: <AANLkTimofUoFXxcKBq6iHEXo3Iw_qYNrmOpYkhaBIy71@mail.gmail.com>

My concern is mostly that we should not over engineer things and be
smarter than CPython (at least in this respect). There is a whole
variety of reasons why it would not work in the end.

Point 2) talks about superset of CPython funcionality. How for example
this would work with compiled cpython extensions that has setup.py
install run?

On smaller issue, I don't like pypy1.2. Both because it contains a dot
and because it contains a revision number. Why we need that?

Cheers,
fijal


On Sat, May 29, 2010 at 3:57 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Hi Maciek,
>
> On 29/05/10 19:32, Maciej Fijalkowski wrote:
>> Hm.
>>
>> I might be missing something, but I thought sys.prefix is only meant
>> for stuff after installation. If this is true (my CPython trunk build
>> has sys.prefix == '/usr/local'), then modifying source checkout does
>> not make any sense, since it's only about installation (which we don't
>> really support anyway).
>
> you are partly right. In CPython, sys.prefix is just an hard-coded string that
> represent what was passed to ./configure; tools like virtualenv use it to find
> the directories containing the stdlib, include files, etc. on the filesystem
> (I'm not sure it's an entirely good idea, but this is the state of the things
> and we have to face it).
>
> However, nothing prevents the interpreter to set sys.prefix dynamically, e.g.
> by searching for the directory that contains the stdlib in some location
> relative to the pypy-c binary; this is what pypy-c does it already to set
> sys.path.
>
> The point of this branch is both:
>
> 1) to make it easier to install pypy system-wide: it will be enough to copy
> pypy-c in /usr/bin and lib/pypy1.2 in /usr/lib (and of course we can automate
> this with a script, if we want)
>
> 2) as holger pointed out, to make it possible to use virtualenv *without*
> having to install pypy system-wide (which you cannot do with cpython, for
> example): this will be possible because the directory hierarchy of the svn
> checkout is designed in a way that setting sys.prefix to the the root of the
> svn checkout will "just work"
>
> ciao,
> Anto
>

From holger at merlinux.eu  Sun May 30 00:38:42 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 30 May 2010 00:38:42 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:	.
	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <4C018E3D.1070705@gmail.com>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net> <4C018E3D.1070705@gmail.com>
Message-ID: <20100529223842.GB17693@trillke.net>

On Sat, May 29, 2010 at 23:59 +0200, Antonio Cuni wrote:
> On 29/05/10 22:25, holger krekel wrote:
> 
> > I think the idea is to make sys.prefix (and thus virtualenv) work 
> > even with a translation in a checkout, i.e. not forcing to copy 
> > things to another location (which virtualenv partly does on its own).  
> 
> yes
> 
> > Moreover, keeping app-level modules (and maybe pypy/module at some point)
> > outside the main (interpreter, objspaces, translation and JIT) PyPy tree 
> > makes sense to me.  e.g. pypy/lang would probably not need to access anything
> > outside such a pypy tree, for example, or am i mistaken? 
> 
> I agree that keeping app-level modules out of pypy is a good idea (this is
> what I'm doing it, of course :-)), but I don't get what does the reference to
> pypy/lang mean in this context.

pyrolog for example doesn't use lib_pypy or pypy/module, does it? 

holger

From holger at merlinux.eu  Sun May 30 00:43:04 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 30 May 2010 00:43:04 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:	.
	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <20100529223842.GB17693@trillke.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net> <4C018E3D.1070705@gmail.com>
	<20100529223842.GB17693@trillke.net>
Message-ID: <20100529224304.GC17693@trillke.net>

On Sun, May 30, 2010 at 00:38 +0200, holger krekel wrote:
> On Sat, May 29, 2010 at 23:59 +0200, Antonio Cuni wrote:
> > On 29/05/10 22:25, holger krekel wrote:
> > 
> > > I think the idea is to make sys.prefix (and thus virtualenv) work 
> > > even with a translation in a checkout, i.e. not forcing to copy 
> > > things to another location (which virtualenv partly does on its own).  
> > 
> > yes
> > 
> > > Moreover, keeping app-level modules (and maybe pypy/module at some point)
> > > outside the main (interpreter, objspaces, translation and JIT) PyPy tree 
> > > makes sense to me.  e.g. pypy/lang would probably not need to access anything
> > > outside such a pypy tree, for example, or am i mistaken? 
> > 
> > I agree that keeping app-level modules out of pypy is a good idea (this is
> > what I'm doing it, of course :-)), but I don't get what does the reference to
> > pypy/lang mean in this context.
> 
> pyrolog for example doesn't use lib_pypy or pypy/module, does it? 

sorry, i meant prolog, gameboy, etc ... i.e. the projects in pypy/lang

holger

From anto.cuni at gmail.com  Sun May 30 08:48:35 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 30 May 2010 08:48:35 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
 pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
 pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <20100529224304.GC17693@trillke.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net> <4C018E3D.1070705@gmail.com>
	<20100529223842.GB17693@trillke.net>
	<20100529224304.GC17693@trillke.net>
Message-ID: <4C020A43.6090100@gmail.com>

On 30/05/10 00:43, holger krekel wrote:

>> pyrolog for example doesn't use lib_pypy or pypy/module, does it? 
> 
> sorry, i meant prolog, gameboy, etc ... i.e. the projects in pypy/lang

yes, indeed. That's why I think it's a good idea to move pypy/lib outside pypy.

From anto.cuni at gmail.com  Sun May 30 08:58:46 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 30 May 2010 08:58:46 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
 pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
 pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <AANLkTimofUoFXxcKBq6iHEXo3Iw_qYNrmOpYkhaBIy71@mail.gmail.com>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<4C018DBC.90404@gmail.com>
	<AANLkTimofUoFXxcKBq6iHEXo3Iw_qYNrmOpYkhaBIy71@mail.gmail.com>
Message-ID: <4C020CA6.9030707@gmail.com>

On 30/05/10 00:08, Maciej Fijalkowski wrote:
> My concern is mostly that we should not over engineer things and be
> smarter than CPython (at least in this respect). 

well, if we want sys.prefix we *need* to be smarter than CPython, as we don't
have any ./configure where take it from. The alternative would be to pass
--prefix to translate.py: do you *really* want to do it?

> There is a whole
> variety of reasons why it would not work in the end.

like?

> Point 2) talks about superset of CPython funcionality. How for example
> this would work with compiled cpython extensions that has setup.py
> install run?

if you use virtualenv, there should be no problem, as it recreates the whole
environment needed.
If you are talking about running ./translator/goal/pypy-c
/my/extension/setup.py install, well, in that case I guess that what happens
is just that your extension will be installed inside
pypy-trunk/lib/pypy1.2/site-packages or some path like this.  Well, too bad
for you, I would say.

> On smaller issue, I don't like pypy1.2. Both because it contains a dot
> and because it contains a revision number. Why we need that?

CPython has the standard lib in $PREFIX/lib/python2.6, so for consistency we
want ours to reside in $PREFIX/lib/pypy1.2.  I know, the drawback of this is
that we need to manually rename it every time we change version number, but
it's also true that it does not happens often.

If you have an alternative solution, I'd like to hear that.  Note that I don't
think that "don't care about using virtualenv from trunk" is a good
alternative solution :-).

ciao,
Anto

From giallu at gmail.com  Sun May 30 09:29:32 2010
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 30 May 2010 09:29:32 +0200
Subject: [pypy-dev] PyPy in Fedora
In-Reply-To: <AANLkTikw6lweW3gp57HhDUwvRJTBGzj9EqYLTY4JAJrs@mail.gmail.com>
References: <AANLkTimsj6sU6qrdFm7MKU4r8NE96U8BX_y6bYB8w_EW@mail.gmail.com> 
	<AANLkTikglZCukpALyOcIYpWIkzaaBL7WHinjd_eLJ7uH@mail.gmail.com> 
	<AANLkTikw6lweW3gp57HhDUwvRJTBGzj9EqYLTY4JAJrs@mail.gmail.com>
Message-ID: <AANLkTikeE8eomLwebuB7LrcES5RsF9xVHmvw2W_QhwR-@mail.gmail.com>

On Sat, May 29, 2010 at 5:35 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Ah, ok, didn't read the post in details. You're targeting svn trunk.
> That has a bit of it's own problems, but it's probably slightly better
> than using 1.2

It seems to me that the current RPM in review is really based on 1.2
with only one patch backported from trunk to address a build failure
with python 2.6.5.

That said, I don't think updating to 1.2.1 will be a problem when you
release it (talking about this, is three any timeline for the
release?)

Of course, I will be happy to forward any suggestion you may have
about the packaging effort.

Cheers

G.

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna

From arigo at tunes.org  Sun May 30 12:16:57 2010
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 30 May 2010 12:16:57 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:	.
	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <20100529202521.GA17693@trillke.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net>
Message-ID: <20100530101657.GA32388@code0.codespeak.net>

Hi Holger,

On Sat, May 29, 2010 at 10:25:21PM +0200, holger krekel wrote:
> makes sense to me.  e.g. pypy/lang would probably not need to access anything
> outside such a pypy tree, for example, or am i mistaken? 

I guess you missed the fact that pypy/lang was moved away from the pypy
trunk altogether.  Apart from that, you are right: one point of view
would be to move pypy/module into /svn/pypy/lang/pypy or something like
that.  In practice I don't really see the point to increase confusion to
that level :-/


Armin

From holger at merlinux.eu  Sun May 30 12:25:07 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 30 May 2010 12:25:07 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:
	.	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <20100530101657.GA32388@code0.codespeak.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net>
	<20100530101657.GA32388@code0.codespeak.net>
Message-ID: <20100530102507.GE17693@trillke.net>

On Sun, May 30, 2010 at 12:16 +0200, Armin Rigo wrote:
> Hi Holger,
> 
> On Sat, May 29, 2010 at 10:25:21PM +0200, holger krekel wrote:
> > makes sense to me.  e.g. pypy/lang would probably not need to access anything
> > outside such a pypy tree, for example, or am i mistaken? 
> 
> I guess you missed the fact that pypy/lang was moved away from the pypy
> trunk altogether.  

sure, it is svn/pypy/lang as opposed to svn/pypy/trunk - it was actually
my point, see the other mail :)

> Apart from that, you are right: one point of view
> would be to move pypy/module into /svn/pypy/lang/pypy or something like
> that.  In practice I don't really see the point to increase confusion to
> that level :-/

Sure, I don't see the need for such an extreme - would complicate working for most
people involved with PyPy at the moment.  However, going for separating things 
incrementally if there are other supporting reasons (in this case making
sys.prefix work inline in a checkout) makes sense to me. 

best,
holger

From arigo at tunes.org  Sun May 30 12:36:13 2010
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 30 May 2010 12:36:13 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:
	.	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <20100530102507.GE17693@trillke.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net>
	<20100530101657.GA32388@code0.codespeak.net>
	<20100530102507.GE17693@trillke.net>
Message-ID: <20100530103613.GA2238@code0.codespeak.net>

Hi Holger,

On Sun, May 30, 2010 at 12:25:07PM +0200, holger krekel wrote:
> > I guess you missed the fact that pypy/lang was moved away from the pypy
> > trunk altogether.  
> 
> sure, it is svn/pypy/lang as opposed to svn/pypy/trunk - it was actually
> my point, see the other mail :)

Ah, sorry.  I understood it as meaning "svn/pypy/trunk/pypy/lang",
because you are talking in the same mail about both "pypy/lang" and
"pypy/module", in the second case with the meaning
"svn/pypy/trunk/pypy/module".

> However, going for separating things 
> incrementally if there are other supporting reasons (in this case making
> sys.prefix work inline in a checkout) makes sense to me. 

I don't think there is any relationship between sys.prefix and the
location of pypy/module (that's what I was talking about, sorry if it
was unclear).


A bientot,

Armin.

From holger at merlinux.eu  Sun May 30 12:51:28 2010
From: holger at merlinux.eu (holger krekel)
Date: Sun, 30 May 2010 12:51:28 +0200
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib:	.
	pypy1.2 pypy1.2/lib_pypy
	pypy1.2/lib_pypy/app_test	pypy1.2/lib_pypy/ctypes_config_cache
	pypy1.2/lib_pypy/test2
In-Reply-To: <20100530103613.GA2238@code0.codespeak.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com>
	<20100529202521.GA17693@trillke.net>
	<20100530101657.GA32388@code0.codespeak.net>
	<20100530102507.GE17693@trillke.net>
	<20100530103613.GA2238@code0.codespeak.net>
Message-ID: <20100530105128.GF17693@trillke.net>

On Sun, May 30, 2010 at 12:36 +0200, Armin Rigo wrote:
> > However, going for separating things 
> > incrementally if there are other supporting reasons (in this case making
> > sys.prefix work inline in a checkout) makes sense to me. 
> 
> I don't think there is any relationship between sys.prefix and the
> location of pypy/module (that's what I was talking about, sorry if it
> was unclear).

Probably right, and indeed, i was talking primarily about pypy/lib -> lib_pypyXYZ,
the change that Maciej questioned.  

Btw, I actually wonder about how cpyext, sys.prefix and compilation after-install 
(possibly in a virtualenv) interact.  Mabe not of concern for the immediate
release but maybe good to know already. 

cheers,
holger

From fijall at gmail.com  Sun May 30 16:04:13 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 30 May 2010 08:04:13 -0600
Subject: [pypy-dev] [pypy-svn] r74850 - in pypy/branch/sys-prefix/lib: .
	pypy1.2 pypy1.2/lib_pypy pypy1.2/lib_pypy/app_test
	pypy1.2/lib_pypy/ctypes_config_cache pypy1.2/lib_pypy/test2
In-Reply-To: <20100530105128.GF17693@trillke.net>
References: <20100528135356.6E7D6282BD6@codespeak.net>
	<AANLkTineQG6q7aXlGviB5L03mf0xX-cbdngqg5zLK0A2@mail.gmail.com> 
	<20100529202521.GA17693@trillke.net>
	<20100530101657.GA32388@code0.codespeak.net> 
	<20100530102507.GE17693@trillke.net>
	<20100530103613.GA2238@code0.codespeak.net> 
	<20100530105128.GF17693@trillke.net>
Message-ID: <AANLkTilDrjWZCA7U5SJVRuCbSUsWhPBzAUP33LnDcHiq@mail.gmail.com>

What's precisely the point of having pypy version number there?

On Sun, May 30, 2010 at 4:51 AM, holger krekel <holger at merlinux.eu> wrote:
> On Sun, May 30, 2010 at 12:36 +0200, Armin Rigo wrote:
>> > However, going for separating things
>> > incrementally if there are other supporting reasons (in this case making
>> > sys.prefix work inline in a checkout) makes sense to me.
>>
>> I don't think there is any relationship between sys.prefix and the
>> location of pypy/module (that's what I was talking about, sorry if it
>> was unclear).
>
> Probably right, and indeed, i was talking primarily about pypy/lib -> lib_pypyXYZ,
> the change that Maciej questioned.
>
> Btw, I actually wonder about how cpyext, sys.prefix and compilation after-install
> (possibly in a virtualenv) interact. ?Mabe not of concern for the immediate
> release but maybe good to know already.
>
> cheers,
> holger
>

From stuaxo2 at yahoo.com  Mon May 31 07:45:23 2010
From: stuaxo2 at yahoo.com (Stuart Axon)
Date: Sun, 30 May 2010 22:45:23 -0700 (PDT)
Subject: [pypy-dev] Running speed.pypy tests?
Message-ID: <41045.95283.qm@web112101.mail.gq1.yahoo.com>

Is there an easy way to run the same set of tests that speed.pypy does?

I'm thinking of testing not pypy, but possibly some of the python newgil patches with the same battery of tests.
(maybe setting up the different pythons in different chroots) ?

 S++



      

From fijall at gmail.com  Mon May 31 18:43:49 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 31 May 2010 10:43:49 -0600
Subject: [pypy-dev] Running speed.pypy tests?
In-Reply-To: <41045.95283.qm@web112101.mail.gq1.yahoo.com>
References: <41045.95283.qm@web112101.mail.gq1.yahoo.com>
Message-ID: <AANLkTinx1p59puk5AsDSswJp9JQM3UffKNjKiKcnquTU@mail.gmail.com>

Hello.

Basically running those tests is fairly simple. You need a checkout of
our benchmarks: http://codespeak.net/svn/pypy/benchmarks/ and run
runner.py with correct options. This can only compare two python
interpreters, so you might want to run it multiple times. Also, please
don't upload results to speed.pypy.org :) (one of the options).

To have a webserver to display it (instead of text backend), you need
to checkout speed source, they can be found in about on
speed.pypy.org.

Cheers,
fijal

On Sun, May 30, 2010 at 11:45 PM, Stuart Axon <stuaxo2 at yahoo.com> wrote:
> Is there an easy way to run the same set of tests that speed.pypy does?
>
> I'm thinking of testing not pypy, but possibly some of the python newgil patches with the same battery of tests.
> (maybe setting up the different pythons in different chroots) ?
>
> ?S++
>
>
>
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Tue Jun  1 06:00:17 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 31 May 2010 22:00:17 -0600
Subject: [pypy-dev] [pypy-svn] r74976 - in pypy/branch/sys-prefix:
	lib/pypy1.2/lib_pypy/ctypes_config_cache
	pypy/interpreter/test pypy/rlib pypy/tool pypy/tool/test
	pypy/translator/goal pypy/translator/sandbox
In-Reply-To: <20100531150223.33D88282B90@codespeak.net>
References: <20100531150223.33D88282B90@codespeak.net>
Message-ID: <AANLkTikr3Np5AQ_Qqexgg5mD-FT_v2JCZ-WhWMrJ0TIa@mail.gmail.com>

A bit about directory structure:

Can you explain to me a bit?

What's in lib except pypy1.2?
Why pypy1.2? Do we have any reason? Do we ever need to keep more than one?
What's in pypy1.2 except lib_pypy?

On Mon, May 31, 2010 at 9:02 AM,  <antocuni at codespeak.net> wrote:
> Author: antocuni
> Date: Mon May 31 17:02:20 2010
> New Revision: 74976
>
> Modified:
> ? pypy/branch/sys-prefix/lib/pypy1.2/lib_pypy/ctypes_config_cache/rebuild.py
> ? pypy/branch/sys-prefix/pypy/interpreter/test/test_module.py
> ? pypy/branch/sys-prefix/pypy/rlib/rmd5.py
> ? pypy/branch/sys-prefix/pypy/rlib/rsha.py
> ? pypy/branch/sys-prefix/pypy/rlib/rzipfile.py
> ? pypy/branch/sys-prefix/pypy/tool/compat.py
> ? pypy/branch/sys-prefix/pypy/tool/lib_pypy.py
> ? pypy/branch/sys-prefix/pypy/tool/test/test_lib_pypy.py
> ? pypy/branch/sys-prefix/pypy/translator/goal/targetpypystandalone.py
> ? pypy/branch/sys-prefix/pypy/translator/sandbox/pypy_interact.py
> ? pypy/branch/sys-prefix/pypy/translator/sandbox/sandlib.py
> Log:
> remove most of the remaining references to pypy/lib, and make them pointing to lib_pypy
>

From anto.cuni at gmail.com  Tue Jun  1 10:05:22 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 01 Jun 2010 10:05:22 +0200
Subject: [pypy-dev] [pypy-svn] r74976 - in pypy/branch/sys-prefix:
 lib/pypy1.2/lib_pypy/ctypes_config_cache pypy/interpreter/test pypy/rlib
 pypy/tool pypy/tool/test pypy/translator/goal pypy/translator/sandbox
In-Reply-To: <AANLkTikr3Np5AQ_Qqexgg5mD-FT_v2JCZ-WhWMrJ0TIa@mail.gmail.com>
References: <20100531150223.33D88282B90@codespeak.net>
	<AANLkTikr3Np5AQ_Qqexgg5mD-FT_v2JCZ-WhWMrJ0TIa@mail.gmail.com>
Message-ID: <4C04BF42.5060304@gmail.com>

On 01/06/10 06:00, Maciej Fijalkowski wrote:
> A bit about directory structure:

I think I have explained everything in my original email to pypy-dev:
http://codespeak.net/pipermail/pypy-dev/2010q2/005854.html

> Can you explain to me a bit?
> 
> What's in lib except pypy1.2?

nothing. It really plays the same role as /usr/lib. We need it because in this
way we can have sys.prefix == '/path/to/pypy-trunk' and still have the lib in
join(sys.prefix, 'lib', 'pypy%d.%d')

> Why pypy1.2? Do we have any reason?

yes. When we install pypy system wide, we really want to have a version number
in the directory that contains the stdlib; also, it is consistent with
cpython, which puts it into e.g. /usr/lib/python2.6

> Do we ever need to keep more than one?

no. We will rename it every time we do a new release.

> What's in pypy1.2 except lib_pypy?

there will be also lib-python, although I've not moved it yet.

ciao,
Anto

From andrewfr_ice at yahoo.com  Tue Jun  1 19:57:46 2010
From: andrewfr_ice at yahoo.com (Andrew Francis)
Date: Tue, 1 Jun 2010 10:57:46 -0700 (PDT)
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
Message-ID: <324283.30017.qm@web111720.mail.gq1.yahoo.com>

Hi Folks:

I understand that stackless is not high on the pypy team priority list but here goes....

My talk "Prototyping Go's Select for Stackles Python in Stackless.py" was accepted. I have never been to Europe. To date, I have been able to implement the Go Select like capability in a number of ways. Most recently I emulated the Plan9 approach which is pretty straight forward. I need to add the code for channel preferences and the channel callback so it is on par with the old stackless.py

Questions:

Where should I put the new code?
Are there regression tests for stackless.py

Right now, I am taking Stephan Diehl and Carl Bolz's good advice and using stackless.py with greenlets. 

However for completeness, I would like to run through the exercise of using the translate tool chain. Right now, select is a function. I figure implementing Select as a language feature would be a good way to familarise myself better with the PyPy framework at a deeper level. However I am not sure where to start. Where is the parser? Do I create new opt codes? Is this doable for a newbie in a month?

Cheers,
Andrew





      

From fijall at gmail.com  Wed Jun  2 06:51:30 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 1 Jun 2010 22:51:30 -0600
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <324283.30017.qm@web111720.mail.gq1.yahoo.com>
References: <324283.30017.qm@web111720.mail.gq1.yahoo.com>
Message-ID: <AANLkTimDJk5zCz7aDs1-Q6kr0Dh6MdHreT6AYhBs8HlG@mail.gmail.com>

On Tue, Jun 1, 2010 at 11:57 AM, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
> Hi Folks:
>
> I understand that stackless is not high on the pypy team priority list but here goes....
>

Completely not answering your question (I don't know), but clarifying.
PyPy has no active developer working on stackless features. However,
that does not mean that pypy's priority for stackless features is low.
We're definitely going to support developments in that direction (at
least those that make sense in our opinion of course :)

Cheers,
fijal

From andrewfr_ice at yahoo.com  Wed Jun  2 15:49:18 2010
From: andrewfr_ice at yahoo.com (Andrew Francis)
Date: Wed, 2 Jun 2010 06:49:18 -0700 (PDT)
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <AANLkTimDJk5zCz7aDs1-Q6kr0Dh6MdHreT6AYhBs8HlG@mail.gmail.com>
Message-ID: <71820.75955.qm@web111725.mail.gq1.yahoo.com>

Hi Maciej:

--- On Tue, 6/1/10, Maciej Fijalkowski <fijall at gmail.com> wrote:

> Completely not answering your question (I don't know), but
> clarifying.PyPy has no active developer working on stackless features.
> However, that does not mean that pypy's priority for stackless
> features is low. We're definitely going to support developments in that
> direction (at least those that make sense in our opinion of course :)

I don't know if this clarifies things but my changes have been to 
stackless.py, the API. I added the ability to monitor many channels at
once, a la Newsqueak/Limbo/Go. This should not break existing code (so far it doesn't but I need to write more tests). I also want to starting to play with join conditions (http://en.wikipedia.org/wiki/Join-calculus) and pattern matching. 

However I want to get deeper into PyPy. I would like to implement Select as a language feature as an exercise rather than an actual change to the language. I am looking the Javascript and Smalltalk VMs but I don't know where to start for Python itself. Also I wouldn't mind learning more about the stackless transform. 

Cheers,
Andrew










      

From cfbolz at gmx.de  Wed Jun  2 15:59:21 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 02 Jun 2010 15:59:21 +0200
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <71820.75955.qm@web111725.mail.gq1.yahoo.com>
References: <71820.75955.qm@web111725.mail.gq1.yahoo.com>
Message-ID: <4C0663B9.8080109@gmx.de>

On 06/02/2010 03:49 PM, Andrew Francis wrote:
> Hi Maciej:
>
> --- On Tue, 6/1/10, Maciej Fijalkowski<fijall at gmail.com>  wrote:
>
>> Completely not answering your question (I don't know), but
>> clarifying.PyPy has no active developer working on stackless
>> features. However, that does not mean that pypy's priority for
>> stackless features is low. We're definitely going to support
>> developments in that direction (at least those that make sense in
>> our opinion of course :)
>
> I don't know if this clarifies things but my changes have been to
> stackless.py, the API. I added the ability to monitor many channels
> at once, a la Newsqueak/Limbo/Go. This should not break existing code
> (so far it doesn't but I need to write more tests). I also want to
> starting to play with join conditions
> (http://en.wikipedia.org/wiki/Join-calculus) and pattern matching.
>
> However I want to get deeper into PyPy. I would like to implement
> Select as a language feature as an exercise rather than an actual
> change to the language.

What exactly do you mean by "language feature"? I assume that select is 
so far simply a function that lives in stackless.py, right? I don't 
really see what other form select could take, so I also don't see in 
what way you want to change the language.

> I am looking the Javascript and Smalltalk VMs
> but I don't know where to start for Python itself.

The bytecode interpreter and the parser live in interpreter/, the object 
implementations in objspace/std/ and the modules in modules/.

> Also I wouldn't
> mind learning more about the stackless transform.

Again, the stackless transformation doesn't really need to be touched to 
implement select.

Cheers,

Carl Friedrich

From arigo at tunes.org  Wed Jun  2 16:19:56 2010
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 2 Jun 2010 16:19:56 +0200
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <4C0663B9.8080109@gmx.de>
References: <71820.75955.qm@web111725.mail.gq1.yahoo.com>
	<4C0663B9.8080109@gmx.de>
Message-ID: <20100602141956.GA7829@code0.codespeak.net>

Hi Andrew,

On Wed, Jun 02, 2010 at 03:59:21PM +0200, Carl Friedrich Bolz wrote:
> > However I want to get deeper into PyPy. I would like to implement
> > Select as a language feature as an exercise rather than an actual
> > change to the language.
> 
> What exactly do you mean by "language feature"?

More precisely, I should say that this kind of changes to the syntax and
bytecode compiler are *really* uninteresting from our point of view.
PyPy is indeed about language implementations, but not about the
syntactic level.  There are nice existing tools about generating parsers
in various languages; and as each of them has some issues with the
Python language, we just wrote the parser and compiler by hand and
happily forgot about it.  Instead, PyPy is about implementation
features.  Moreover, it focuses more on features that can be
meta-programmed, like the stackless transformation (which works fine so
far, and which does not need any change to support e.g. various kinds of
Select).


A bientot,

Armin.

From arigo at tunes.org  Tue Jun  8 14:41:12 2010
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 8 Jun 2010 14:41:12 +0200
Subject: [pypy-dev] Merging branch/blackhole-improvements
Message-ID: <20100608124112.GA20901@code0.codespeak.net>

Hi Fijal,

The branch/blackhole-improvement is ready to be merged as far as I can
tell.  Do you have any issue (as release manager) if I try to merge it
now?


A bientot,

Armin.

From anto.cuni at gmail.com  Thu Jun 10 00:26:07 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 10 Jun 2010 00:26:07 +0200
Subject: [pypy-dev] [pypy-svn] r75220 - in pypy/trunk/pypy: annotation
 annotation/test jit/backend jit/backend/llgraph jit/backend/llgraph/test
 jit/backend/llsupport jit/backend/llsupport/test jit/backend/test
 jit/backend/x86 jit/backend/x86/test jit/codewriter jit/codewriter/test
 jit/metainterp jit/metainterp/test jit/tl jit/tl/spli jit/tl/tla jit/tool
 jit/tool/test module/pypyjit module/pypyjit/test objspace/flow rpython
 rpython/lltypesystem rpython/lltypesystem/test
 rpython/memory/gctransform/test rpython/memory/test rpython/test tool/algo
 tool/algo/test translator/c translator/c/src translator/c/test
 translator/tool
In-Reply-To: <20100608214258.3E44E282BDE@codespeak.net>
References: <20100608214258.3E44E282BDE@codespeak.net>
Message-ID: <4C1014FF.4040902@gmail.com>

On 08/06/10 23:42, arigo at codespeak.net wrote:
> The number of changes is a bit huge though.  The
> format of the static bytecodes used by the jit
> changed completely, and codewriter.py is now split
> among many files in the new directory pypy.jit.codewriter.
> There is also no longer ConstAddr, only ConstInt: prebuilt
> addresses are now turned into integers (which are
> symbolic, with the new class AddressAsInt, so they can
> be rendered by the C translation backend).  Various
> related changes occurred here and there.

I didn't look at the branch deeply, but the last sentence looks suspiciously 
hard/impossible to implement in ootype.  Could you explain why ConstAdrr were 
bad please?

ciao,
Anto

From arigo at tunes.org  Sun Jun 13 08:46:41 2010
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 13 Jun 2010 08:46:41 +0200
Subject: [pypy-dev] [pypy-svn] r75220 - in pypy/trunk/pypy: annotation
	annotation/test jit/backend jit/backend/llgraph
	jit/backend/llgraph/test jit/backend/llsupport
	jit/backend/llsupport/test jit/backend/test jit/backend/x86
	jit/backend/x86/test jit/codewriter jit/codewriter/test
	jit/metainterp jit/metainterp/test jit/tl jit/tl/spli
	jit/tl/tla jit/tool jit/tool/test module/pypyjit
	module/pypyjit/test objspace/flow rpython
	rpython/lltypesystem rpython/lltypesystem/test
	rpython/memory/gctransform/test rpython/memory/test
	rpython/test tool/algo tool/algo/test translator/c
	translator/c/src translator/c/test translator/tool
In-Reply-To: <4C1014FF.4040902@gmail.com>
References: <20100608214258.3E44E282BDE@codespeak.net>
	<4C1014FF.4040902@gmail.com>
Message-ID: <20100613064641.GA7722@code0.codespeak.net>

Hi Anto,

On Thu, Jun 10, 2010 at 12:26:07AM +0200, Antonio Cuni wrote:
> I didn't look at the branch deeply, but the last sentence looks 
> suspiciously hard/impossible to implement in ootype.  Could you explain why 
> ConstAdrr were bad please?

Because the blackhole interpreter doesn't use ConstXxx at all.  The
constants are now encoded directly in the jitcode -- in three lists, a
list of integers, a list of references, and a list of float.  There is
almost no ConstXxx prebuilt any more.  It seemed like a waste to need a
fourth list just for addresses when they would fit in the list of
integer constants too, hence I did AddressAsInt.  It's a rather natural
thing to do for lltype, given that we could already convert between
addresses and integers at runtime.

I'm a bit confused, btw: I thought that ootype did not need ConstAddr at
all, because it used ConstObj for all pointer-ish things.


A bientot,

Armin.

From anto.cuni at gmail.com  Sun Jun 13 09:40:24 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 13 Jun 2010 09:40:24 +0200
Subject: [pypy-dev] [pypy-svn] r75220 - in pypy/trunk/pypy: annotation
 annotation/test jit/backend jit/backend/llgraph jit/backend/llgraph/test
 jit/backend/llsupport jit/backend/llsupport/test jit/backend/test
 jit/backend/x86 jit/backend/x86/test jit/codewriter jit/codewriter/test
 jit/metainterp jit/metainterp/test jit/tl jit/tl/spli jit/tl/tla jit/tool
 jit/tool/test module/pypyjit module/pypyjit/test objspace/flow rpython
 rpython/lltypesystem rpython/lltypesystem/test
 rpython/memory/gctransform/test rpython/memory/test rpython/test tool/algo
 tool/algo/test translator/c translator/c/src translator/c/test
 translator/tool
In-Reply-To: <20100613064641.GA7722@code0.codespeak.net>
References: <20100608214258.3E44E282BDE@codespeak.net>
	<4C1014FF.4040902@gmail.com>
	<20100613064641.GA7722@code0.codespeak.net>
Message-ID: <4C148B68.7030707@gmail.com>

On 13/06/10 08:46, Armin Rigo wrote:

> I'm a bit confused, btw: I thought that ootype did not need ConstAddr at
> all, because it used ConstObj for all pointer-ish things.

ah sorry. You wrote ConstAddr but I actually read ConstPtr (i.e., ConstObj for 
ootype). Indeed, ConstAddr is not used at all by ootype, so there should be no 
problem (at least in this respect :-)).

ciao,
Anto

From holger at merlinux.eu  Tue Jun 15 11:37:59 2010
From: holger at merlinux.eu (holger krekel)
Date: Tue, 15 Jun 2010 11:37:59 +0200
Subject: [pypy-dev] can somebody talk at DZUG/Dresden?
Message-ID: <20100615093759.GL17693@trillke.net>

Hi all, 

i have been asked to talk at 

    http://new.zope.de/tagung/Dresden_2010

about PyPy.  But i can't make it there.  Anybody interested in giving a talk
about PyPy?  Giving english talks is fine and happens a lot there. 

I think we have good base material from past conferences so if
you are an informed follower of the project and are interested - drop
me a note. 

best,
holger

From tom at tomlocke.com  Thu Jun 17 10:21:53 2010
From: tom at tomlocke.com (Tom Locke)
Date: Thu, 17 Jun 2010 09:21:53 +0100
Subject: [pypy-dev] Seeking advice re. implementing an interpreter in RPython
Message-ID: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>

Hi Folks

I'm probably in the wrong place, so I'll make this quick : )

I am working on an experimental programming language, and am considering building the next prototype of the interpreter in RPython. I just wanted to ask which mailing-list is the best one to join for help and advice on this topic?

Thanks

Tom


From arigo at tunes.org  Thu Jun 17 10:34:58 2010
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 17 Jun 2010 10:34:58 +0200
Subject: [pypy-dev] Seeking advice re. implementing an interpreter in
	RPython
In-Reply-To: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>
References: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>
Message-ID: <20100617083458.GA22461@code0.codespeak.net>

Hi Tom,

On Thu, Jun 17, 2010 at 09:21:53AM +0100, Tom Locke wrote:
> I'm probably in the wrong place, so I'll make this quick : )

You are not :-)  Welcome.  Feel free to ask here about RPython.  You can
also join #pypy on irc.freenode.net.


A bientot,

Armin.

From tom at tomlocke.com  Thu Jun 17 11:19:19 2010
From: tom at tomlocke.com (Tom Locke)
Date: Thu, 17 Jun 2010 10:19:19 +0100
Subject: [pypy-dev] Seeking advice re. implementing an interpreter in
	RPython
In-Reply-To: <20100617083458.GA22461@code0.codespeak.net>
References: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>
	<20100617083458.GA22461@code0.codespeak.net>
Message-ID: <C42E2CF8-847F-4B91-9B67-5542FE9D4677@tomlocke.com>

Thanks for the welcome, and how nice it is to find a project on a European time-zone, and not have to wait for those sleepy Americans to wake up : ) By way of an introduction, did any of you guys notice "Logix" a few years back? On-the-fly syntax extension and lisp-ish macros for Python. I'm the guy that did that. Now abandoned sadly.

I am building what you might call a macro language or a template language for code-generation. It is up and running in prototype form, but way too slow.

I must confess to having jumped ship - I am mainly a Ruby guy these days, and the prototype is in Ruby. But RPython is interesting enough to perhaps bring me back - for this project at least - so congratulations for that. Amazing project.

OK, to get down to business - I'll be starting with the parser. I notice there is a packrat parser in the rlib directory. If that is in a working state I'll be a happy man, as my existing grammar is for a Ruby packrat parser (Treetop). I am guessing that the 'r' in 'rlib' means RPython? Which I'm hoping means the packrat parser might be reasonably fast?

Any pointers to getting started with the packrat parser (or some other if you don't advise that) much appreciated!

Tom


From william.leslie.ttg at gmail.com  Thu Jun 17 10:29:24 2010
From: william.leslie.ttg at gmail.com (William Leslie)
Date: Thu, 17 Jun 2010 18:29:24 +1000
Subject: [pypy-dev] Seeking advice re. implementing an interpreter in
	RPython
In-Reply-To: <AANLkTimybmRICZhd3owm8PgjHhFrqySBMFyrxmh1GbNR@mail.gmail.com>
References: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>
	<AANLkTimxzEikCX6W2lXgyCLmRUtTw4ndMzy4oXPEsjF_@mail.gmail.com>
	<AANLkTimybmRICZhd3owm8PgjHhFrqySBMFyrxmh1GbNR@mail.gmail.com>
Message-ID: <AANLkTiknNDhFVZfK9Qpttz5kXwRHTpaD8RnkIFEkwjN9@mail.gmail.com>

This is the right mailing list. You might like to join us on irc for more
involved questions, too. What are you working on?

On 17/06/2010 6:22 PM, "Tom Locke" <tom at tomlocke.com> wrote:

Hi Folks

I'm probably in the wrong place, so I'll make this quick : )

I am working on an experimental programming language, and am considering
building the next prototype of the interpreter in RPython. I just wanted to
ask which mailing-list is the best one to join for help and advice on this
topic?

Thanks

Tom

_______________________________________________
pypy-dev at codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100617/63b251e0/attachment-0001.htm 

From ryan at rfk.id.au  Thu Jun 17 12:02:55 2010
From: ryan at rfk.id.au (Ryan Kelly)
Date: Thu, 17 Jun 2010 20:02:55 +1000
Subject: [pypy-dev] using libffi from rpython - a better way?
Message-ID: <1276768975.2069.122.camel@durian>


Hi All,


  First, let me say that PyPy just rocked my world.  I develop an
auto-update framework for frozen python applications [1] and have
started using PyPy to compile parts of the app into stand-alone
executables.  I got it up and running in under two days, and it shaves
several MB off the size of my frozen apps - so thanks for some awesome
tech!

  I'm currently using libffi to dynamically find and load a python DLL
from within an RPython program.  It works well but the code seems very
verbose to someone who's used to working with ctypes.  I'm hoping
there's a better way...

  Here's a trimmed-down example of the sort of thing I'm doing::


      import ctypes.util
      libpython = ctypes.util.find_library("python2.6")

      from pypy.rlib.libffi import *
      from pypy.rpython.lltypesystem import rffi, lltype

      def target(*args):
          def entry_point(argv):

              #  Find the python DLL and extract needed functions
              py = CDLL(libpython)
              Py_Initialize = py.getpointer("Py_Initialize",[],ffi_type_void)
              Py_Finalize = py.getpointer("Py_Finalize",[],ffi_type_void)
              PyRun_SimpleString = py.getpointer("PyRun_SimpleString",[ffi_type_pointer],ffi_type_sint)

              #  Bootstrap into running a python program
              Py_Initialize.call(lltype.Void)
              buf = rffi.str2charp("print 'hello from python!'")
              PyRun_SimpleString.push_arg(buf)
              PyRun_SimpleString.call(rffi.INT)
              rffi.free_charp(buf)
              Py_Finalize.call(lltype.Void)
              return 0

          return entry_point,None


  As you can imagine, the real application has a lot more of these
boilerplate declarations.  Any suggestions on how to do this in
less/cleaner code?


   Thanks,

      Ryan


[1]  http://pypi.python.org/pypi/esky/


-- 
Ryan Kelly
http://www.rfk.id.au  |  This message is digitally signed. Please visit
ryan at rfk.id.au        |  http://www.rfk.id.au/ramblings/gpg/ for details

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/pypy-dev/attachments/20100617/8dd79090/attachment.pgp 

From amauryfa at gmail.com  Thu Jun 17 13:35:03 2010
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Thu, 17 Jun 2010 13:35:03 +0200
Subject: [pypy-dev] using libffi from rpython - a better way?
In-Reply-To: <1276768975.2069.122.camel@durian>
References: <1276768975.2069.122.camel@durian>
Message-ID: <AANLkTiklbukGsVDO9i9nuu3xIde4Fx6FU8EAQdIuPKed@mail.gmail.com>

Hi,

2010/6/17 Ryan Kelly <ryan at rfk.id.au>:
>
> ? ? ? ? ? ? ?# ?Find the python DLL and extract needed functions
> ? ? ? ? ? ? ?py = CDLL(libpython)
> ? ? ? ? ? ? ?Py_Initialize = py.getpointer("Py_Initialize",[],ffi_type_void)
> ? ? ? ? ? ? ?Py_Finalize = py.getpointer("Py_Finalize",[],ffi_type_void)
> ? ? ? ? ? ? ?PyRun_SimpleString = py.getpointer("PyRun_SimpleString",[ffi_type_pointer],ffi_type_sint)
>
> ?As you can imagine, the real application has a lot more of these
> boilerplate declarations. ?Any suggestions on how to do this in
> less/cleaner code?

For the cpyext module, we used the documentation to generate stubs for
every function of the API.
It's easy to write a sphinx extension that processes every "cfunction"
directive in the documentation.

You could start with pypy/module/cpyext/stubgen.py and modify it for
your needs, which are
obviously different.

It's poorly documented, but the comment for r72933 says:
The stub generator works as follows:
 1. Go to Doc (in your CPython checkout).
 2. Run make text and stop it after it downloaded the prerequisites.
 3. Apply the patch Doc_stubgen_enable.patch in your CPython checkout
 4. Run make text again with PyPy in your Python path.
 5. Voila, the stubs.py file will be updated.


-- 
Amaury Forgeot d'Arc

From cfbolz at gmx.de  Thu Jun 17 13:40:10 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 17 Jun 2010 13:40:10 +0200
Subject: [pypy-dev] Seeking advice re. implementing an interpreter in
 RPython
In-Reply-To: <C42E2CF8-847F-4B91-9B67-5542FE9D4677@tomlocke.com>
References: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>	<20100617083458.GA22461@code0.codespeak.net>
	<C42E2CF8-847F-4B91-9B67-5542FE9D4677@tomlocke.com>
Message-ID: <4C1A099A.4040806@gmx.de>

Hi Tom,

On 06/17/2010 11:19 AM, Tom Locke wrote:
> Thanks for the welcome, and how nice it is to find a project on a
> European time-zone, and not have to wait for those sleepy Americans
> to wake up : ) By way of an introduction, did any of you guys notice
>  "Logix" a few years back? On-the-fly syntax extension and lisp-ish
> macros for Python. I'm the guy that did that. Now abandoned sadly.
>
> I am building what you might call a macro language or a template
> language for code-generation. It is up and running in prototype form,
> but way too slow.
>
> I must confess to having jumped ship - I am mainly a Ruby guy these
> days, and the prototype is in Ruby. But RPython is interesting enough
> to perhaps bring me back - for this project at least - so
> congratulations for that. Amazing project.
>
> OK, to get down to business - I'll be starting with the parser.

In general the PyPy attitude is that parsers are totally uninteresting.

> I notice there is a packrat parser in the rlib directory. If that is
> in a working state I'll be a happy man, as my existing grammar is
> for a Ruby packrat parser (Treetop). I am guessing that the 'r' in
> 'rlib' means RPython?

Yes, that's correct.

> Which I'm hoping means the packrat parser might be reasonably fast?

As I am wrote the stuff in the rlib/parsing directory I guess I should
answer that. There are actually two different packrat-parsing approaches 
in the parsing directory. Both of them are not particularly polished or 
particularly fast. They might still be useful for you, but you have to 
try and see.

> Any pointers to getting started with the packrat parser (or some
> other if you don't advise that) much appreciated!

There is this:

http://codespeak.net/pypy/dist/pypy/doc/rlib.html#parsing

Apart from that, you probably have to look at the code or the tests in 
rlib/parsing.

Cheers,

Carl Friedrich

From holger at merlinux.eu  Thu Jun 17 13:46:41 2010
From: holger at merlinux.eu (holger krekel)
Date: Thu, 17 Jun 2010 13:46:41 +0200
Subject: [pypy-dev] Seeking advice re. implementing an interpreter
	in	RPython
In-Reply-To: <4C1A099A.4040806@gmx.de>
References: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>
	<20100617083458.GA22461@code0.codespeak.net>
	<C42E2CF8-847F-4B91-9B67-5542FE9D4677@tomlocke.com>
	<4C1A099A.4040806@gmx.de>
Message-ID: <20100617114641.GW17693@trillke.net>

On Thu, Jun 17, 2010 at 13:40 +0200, Carl Friedrich Bolz wrote:
> On 06/17/2010 11:19 AM, Tom Locke wrote:
> > OK, to get down to business - I'll be starting with the parser.
> 
> In general the PyPy attitude is that parsers are totally uninteresting.

Luckily from time to time we have people who care, though.  

holger

From cfbolz at gmx.de  Thu Jun 17 13:48:34 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 17 Jun 2010 13:48:34 +0200
Subject: [pypy-dev] Seeking advice re. implementing an interpreter in
 RPython
In-Reply-To: <20100617114641.GW17693@trillke.net>
References: <BFB786AE-0378-4A9B-8626-50A71545DB14@tomlocke.com>
	<20100617083458.GA22461@code0.codespeak.net>
	<C42E2CF8-847F-4B91-9B67-5542FE9D4677@tomlocke.com>
	<4C1A099A.4040806@gmx.de> <20100617114641.GW17693@trillke.net>
Message-ID: <4C1A0B92.1060707@gmx.de>

On 06/17/2010 01:46 PM, holger krekel wrote:
> On Thu, Jun 17, 2010 at 13:40 +0200, Carl Friedrich Bolz wrote:
>> On 06/17/2010 11:19 AM, Tom Locke wrote:
>>> OK, to get down to business - I'll be starting with the parser.
>>
>> In general the PyPy attitude is that parsers are totally uninteresting.
>
> Luckily from time to time we have people who care, though.

Yes, luckily. Occasionally I am even one of them :-).

Carl Friedrich

From andrewfr_ice at yahoo.com  Thu Jun 17 14:39:53 2010
From: andrewfr_ice at yahoo.com (Andrew Francis)
Date: Thu, 17 Jun 2010 05:39:53 -0700 (PDT)
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <mailman.103.1276766835.6194.pypy-dev@codespeak.net>
Message-ID: <508973.72046.qm@web120005.mail.ne1.yahoo.com>

Hi Carl:

Message: 2
Date: Wed, 02 Jun 2010 15:59:21 +0200
From: Carl Friedrich Bolz <cfbolz at gmx.de>
Subject: Re: [pypy-dev] EuroPython Talk on Stackless.py and Questions
To: pypy-dev at codespeak.net
Message-ID: <4C0663B9.8080109 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

>What exactly do you mean by "language feature"?

As in alter the syntax of Python

> I assume that select is so far simply a function that lives in >stackless.py, right?

Yes.

> I don't really see what other form select could take, so I also
> don't see in what way you want to change the language.

The Newsqueak/Limbo/Go family of languages show select and channels
can be implemented as language features. It is from Limbo, where 
Stackless Python gets channels.

>The bytecode interpreter and the parser live in interpreter/, the object
>implementations in objspace/std/ and the modules in modules/.

Thanks. I found it and started to look at it.

> Also I wouldn't
> mind learning more about the stackless transform.

>Again, the stackless transformation doesn't really need to be touched to
>implement select.

True. However I would like to learn how the stackless transform works.

Cheers,
Andrew


      

From andrewfr_ice at yahoo.com  Thu Jun 17 15:13:26 2010
From: andrewfr_ice at yahoo.com (Andrew Francis)
Date: Thu, 17 Jun 2010 06:13:26 -0700 (PDT)
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <mailman.103.1276766835.6194.pypy-dev@codespeak.net>
Message-ID: <964940.80590.qm@web120017.mail.ne1.yahoo.com>

Hi Armin:

Message: 3
Date: Wed, 2 Jun 2010 16:19:56 +0200
From: Armin Rigo <arigo at tunes.org>
Subject: Re: [pypy-dev] EuroPython Talk on Stackless.py and Questions
To: Carl Friedrich Bolz <cfbolz at gmx.de>
Cc: pypy-dev at codespeak.net
Message-ID: <20100602141956.GA7829 at code0.codespeak.net>
Content-Type: text/plain; charset=us-ascii

Hi Andrew,

On Wed, Jun 02, 2010 at 03:59:21PM +0200, Carl Friedrich Bolz wrote:

> > However I want to get deeper into PyPy. I would like to implement
> > Select as a language feature as an exercise rather than an actual
> > change to the language.
>
>> What exactly do you mean by "language feature"?

>More precisely, I should say that this kind of changes to the syntax and
>bytecode compiler are *really* uninteresting from our point of view.
>PyPy is indeed about language implementations, but not about the
>syntactic level.  There are nice existing tools about generating parsers
>in various languages; and as each of them has some issues with the
Python language, we just wrote the parser and compiler by hand and
>happily forgot about it.

Armin, I understand. However I am approaching this from another angle. I
view myself as an application programmer. I know the Stackless API
relatively well and its algorithms. Enough to implement select (not
hard). Outside of selecting the right switches for translate.py or just
sticking to greenlets, there really isn't much PyPy to learn, unless
I decide to re-write parts specifically in RPython for speed. I may
do this so I can better acquaint myself with PyPy.

Implementing select is an important exercise because it is a stepping stone for me (and hopefully others) to experiment with more
exotic features. For example, I am becoming interested in Complex Event
Processing that has pattern matching rules. One may want language features to support those. So I am interested in the low level details of how to alter PyPy's implementation of Python syntax. Maybe to help in the exercise, it would be nice if I can get advice about what exactly what 
I needed to change. Getting advice from Carl and Stephan about using 
greenlets *radically* speed up my ability to implement stackless.py -
I would never figure that out on my own. 

Cheers,
Andrew







      

From arigo at tunes.org  Thu Jun 17 15:36:35 2010
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 17 Jun 2010 15:36:35 +0200
Subject: [pypy-dev] EuroPython Talk on Stackless.py and Questions
In-Reply-To: <964940.80590.qm@web120017.mail.ne1.yahoo.com>
References: <mailman.103.1276766835.6194.pypy-dev@codespeak.net>
	<964940.80590.qm@web120017.mail.ne1.yahoo.com>
Message-ID: <20100617133635.GA11503@code0.codespeak.net>

Hi Andrew,

On Thu, Jun 17, 2010 at 06:13:26AM -0700, Andrew Francis wrote:
> (...) One may want language features to support those. So I am
> interested in the low level details of how to alter PyPy's
> implementation of Python syntax.

Sure, feel free to ask, here or on the #pypy channel of
irc.freenode.net.  I suppose that you have got the point
"we are generally not interested in syntax changes" by
now, but we should still be around to give you some help.


A bientot,

Armin.

From alexander.belopolsky at gmail.com  Fri Jun 18 02:50:59 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Thu, 17 Jun 2010 20:50:59 -0400
Subject: [pypy-dev] Adding pure python implementation of datetime to CPython
	3.x
Message-ID: <AANLkTimlPqktn5i1B-TEVDVC4p-0mOO754rgaorKJwAf@mail.gmail.com>

Dear PyPy-Dev,

I have started porting PyPy implementation of datetime.py to CPython
3.x with a goal of distributing it together with C implementation.
The idea is for C and Python modules to share most of the regression
test cases and allow platforms that cannot use C modules use python
implementation.  The benefit for CPython developers is that this will
allow rapid prototyping and experimentation with new features.  The
benefit for CPython users is that they will be able to consult python
implementation as ultimately detailed documentation.

Since your project did an admirable job maintaining datetime.py in
recent years, your input will be very much appreciated.  Please see
CPython tracker issue 7989 [1] for details and to leave comments.  I
already have a patch there which updates PyPy datetime.py to Python
2.7.  You should be able to apply it to your tree when you upgrade to
2.7.

--
[1] http://bugs.python.org/issue7989

From ademan555 at gmail.com  Fri Jun 18 05:16:37 2010
From: ademan555 at gmail.com (Dan Roberts)
Date: Thu, 17 Jun 2010 20:16:37 -0700
Subject: [pypy-dev] lltype Questions
Message-ID: <1276830997.3153.8.camel@StormEagle>

Hey Everybody,
	It seems no one's in #pypy at the moment, so I figured I'd post to the
mailing list for non-realtime questioning.  I wrote my implementation of
PyUnicode_DecodeUTF16() which is correct as best I can tell (and it
passes its test, but I wrote the test too :-) ).
	The code is here: http://paste.pocoo.org/show/226753/ and its test is
here: http://paste.pocoo.org/show/226752/ . I have a few questions, like
I said, the test passes, but I'm unsure of some of the code I've
written.  There are XXX and FIXME and other comments throughout the
code, those represent places where I'm unsure.
   In the test code, line 6 I'm not sure if that malloc() is correct,
and even if it is, would it have been better (and also valid) to
lltype.malloc(lltype.Signed, ...) ?  Then from line 7 to 12 I assign
"native" integers to the malloc-ed memory, is this done correctly? ex.
pendian[0] = -1 or should it be pendian[0] = rffi.cast(lltype.Signed,
-1) ?
   In the implementation, I'm fairly certain I've marked everything with
FIXME or XXX, so there's not much more to say about that...  I'd really
appreciate anyone who's willing to take a look.

Thanks,
Dan


From amauryfa at gmail.com  Fri Jun 18 10:19:07 2010
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Fri, 18 Jun 2010 10:19:07 +0200
Subject: [pypy-dev] lltype Questions
In-Reply-To: <1276830997.3153.8.camel@StormEagle>
References: <1276830997.3153.8.camel@StormEagle>
Message-ID: <AANLkTil_oY8Qh0LKzyo7eLMNDsu_aD0LfyCBxwuO5xL2@mail.gmail.com>

Hi,

2010/6/18 Dan Roberts <ademan555 at gmail.com>:
> Hey Everybody,
> ? ? ? ?It seems no one's in #pypy at the moment, so I figured I'd post to the
> mailing list for non-realtime questioning. ?I wrote my implementation of
> PyUnicode_DecodeUTF16() which is correct as best I can tell (and it
> passes its test, but I wrote the test too :-) ).
> ? ? ? ?The code is here: http://paste.pocoo.org/show/226753/ and its test is
> here: http://paste.pocoo.org/show/226752/ . I have a few questions, like
> I said, the test passes, but I'm unsure of some of the code I've
> written. ?There are XXX and FIXME and other comments throughout the
> code, those represent places where I'm unsure.
> ? In the test code, line 6 I'm not sure if that malloc() is correct,
> and even if it is, would it have been better (and also valid) to
> lltype.malloc(lltype.Signed, ...) ? ?Then from line 7 to 12 I assign
> "native" integers to the malloc-ed memory, is this done correctly? ex.
> pendian[0] = -1 or should it be pendian[0] = rffi.cast(lltype.Signed,
> -1) ?
> ? In the implementation, I'm fairly certain I've marked everything with
> FIXME or XXX, so there's not much more to say about that... ?I'd really
> appreciate anyone who's willing to take a look.

All this looks quite good, except for the second cast - it should be
    pbyteorder[0] = rffi.cast(rffi.INT, byteorder)

And I suggest to add another test: automatic detection of byte order
when a Byte Order Mark is present.

-- 
Amaury Forgeot d'Arc

From fijall at gmail.com  Fri Jun 18 19:01:44 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 18 Jun 2010 11:01:44 -0600
Subject: [pypy-dev] virtualenv support and directory hierarchy
In-Reply-To: <4BFD364B.5030903@gmail.com>
References: <4BFD364B.5030903@gmail.com>
Message-ID: <AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com>

Hey anto.

I expressed my concerns already, but I'm going to express them once
again, since amaury also said that on IRC.

I really dislike having version number hardcoded in source checkout
for a whole variety of reasons. I don't think need to have virtualenv
working from source checkout is enough to push that through.

How about install script that does that maybe?

Cheers,
fijal

On Wed, May 26, 2010 at 8:55 AM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Hi all,
>
> I am investigating how to make virtualenv working on pypy and I'm running into
> a couple of issues: the most important one is that virtualenv relies on
> sys.prefix (which does not exists in pypy) to find the standard library, and
> the other is that the standard library of pypy is supposed to be put in
> /usr/share instead of /usr/lib (or /usr/local/*).
>
> Currently, a pypy installation is supposed to have this structure:
> ? ? ? ? /usr/bin/pypy-c
> ? ? ? ? /usr/share/pypy-1.2/pypy/lib/
> ? ? ? ? /usr/share/pypy-1.2/lib-python/modified-2.5.2
> ? ? ? ? /usr/share/pypy-1.2/lib-python/2.5.2
>
> In such a situation, sys.pypy_prefix is set to '/usr/share/pypy-1.2'.
>
> I propose to change it in this way:
> ? ? ? ? /usr/bin/pypy-c
> ? ? ? ? /usr/lib/pypy1.2/lib-pypy/
> ? ? ? ? /usr/lib/pypy1.2/lib-python/modified-2.5.2
> ? ? ? ? /usr/lib/pypy1.2/lib-python/2.5.2
>
> where lib-pypy contains what it's now in pypy/lib.
> In such a situation, sys.prefix would be set to '/usr', in a similar way as
> cpython. ?Also, we should also add a sys.exec_prefix which is meant to be
> always equal to sys.prefix (at least for now).
> (I removed the dash in pypy-1.2 for consistency with cpython, which uses
> something like lib/python2.6).
>
>
> Moreover, I would also like virtualenv to work from an svn checkout/source
> tarball of pypy, without any needing of installing it system-wide. To do so,
> we need to find a sensible value for sys.prefix, considering that tools like
> virtualenv suppose to find the stdlib under sys.prefix+'lib/'+something_else.
>
> So, the proposed new structure is this:
>
> ? ? ? ? /path/to/pypy-trunk/
> ? ? ? ? /path/to/pypy-trunk/lib/pypy1.2/{lib-pypy,modified-2.5.2,2.5.2}
> ? ? ? ? sys.prefix == '/path/to/pypy-trunk'
>
> The drawback is that before getting to the real files you have to walk a lot
> of empty directories, and that we should manually change the name of pypy1.2
> each time we increase the version number (not that it happens very often :-)).
> One side-advantage is that in this way we would move pypy/lib outside the main
> pypy package, which is good because it's not really a part of it.
>
> Finally, we should probably think of where to put the include/ directory (plus
> other that might be needed to build extension), but I'll let cpyext experts to
> say what it's better :-)
>
> What do you think? Any comment/suggestion/problem that I overlooked?
>
> ciao,
> Anto
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From anto.cuni at gmail.com  Sat Jun 19 10:29:58 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 19 Jun 2010 10:29:58 +0200
Subject: [pypy-dev] virtualenv support and directory hierarchy
In-Reply-To: <AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com>
References: <4BFD364B.5030903@gmail.com>
	<AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com>
Message-ID: <4C1C8006.1030009@gmail.com>

Hi,

I also don't like too much to have a hardcoded version number, but when I 
asked for alternatives nobody suggested anything.

On IRC, amaury suggested to install the whole pypy distribution in its 
self-contained directory, more or less as cpython does on windows.
I didn't think about this solution, but now I see that it might be a good one, 
as it would allow to have the same hierarchy on svn checkouts, user-specific 
installations and system-wide installations.

The drawback is that it's a bit non-standard on unix; moreover, if we install 
pypy in say /opt/pypy1.2, it would be hard to put a binary in /usr/bin without 
hardcoding the path to pypy1.2 somewhere.

So, for me there are four possible solutions:

1) leave things as they are on branch/sys-prefix and have the version number 
hardcoded in svn

2) put the whole distribution in its own directory, as jython or cpython on 
windows.  This has the open problem of determining where the directory is, as 
described above

3) don't hardcode the version number in svn, but add a special case to 
virtualenv to detect if we are inside a pypy checkout to handle it specially

4) don't care about running virtualenv inside a pypy checkout

Personally, I would exclude (4): I think that it would be very cool for people 
to try pypy in a sandboxed virtualenv without having to install it, and it 
would be useful to us too.

So, before I do more work, I'd like to hear what people think and which of the 
alternatives they prefer.

ciao,
Anto

On 18/06/10 19:01, Maciej Fijalkowski wrote:
> Hey anto.
>
> I expressed my concerns already, but I'm going to express them once
> again, since amaury also said that on IRC.
>
> I really dislike having version number hardcoded in source checkout
> for a whole variety of reasons. I don't think need to have virtualenv
> working from source checkout is enough to push that through.
>
> How about install script that does that maybe?
>
> Cheers,
> fijal


From arigo at tunes.org  Sat Jun 19 10:36:31 2010
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 19 Jun 2010 10:36:31 +0200
Subject: [pypy-dev] virtualenv support and directory hierarchy
In-Reply-To: <4C1C8006.1030009@gmail.com>
References: <4BFD364B.5030903@gmail.com>
	<AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com>
	<4C1C8006.1030009@gmail.com>
Message-ID: <20100619083631.GA31070@code0.codespeak.net>

Hi Anto,

On Sat, Jun 19, 2010 at 10:29:58AM +0200, Antonio Cuni wrote:
> The drawback is that it's a bit non-standard on unix; moreover, if we
> install pypy in say /opt/pypy1.2, it would be hard to put a binary in
> /usr/bin without hardcoding the path to pypy1.2 somewhere.

No, we can put a symlink in /usr/bin going to /opt/pypy1.2/bin/pypy.  I
have seen a few projects do that and it would just work (the current
logic to search for the pypy directory follows symlinks).


A bientot,

Armin.

From amauryfa at gmail.com  Sat Jun 19 11:00:10 2010
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Sat, 19 Jun 2010 11:00:10 +0200
Subject: [pypy-dev] virtualenv support and directory hierarchy
In-Reply-To: <4C1C8006.1030009@gmail.com>
References: <4BFD364B.5030903@gmail.com>
	<AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com>
	<4C1C8006.1030009@gmail.com>
Message-ID: <AANLkTik52rQO-IYw3nfe_sonxqUgFrswomE6WZYytS7S@mail.gmail.com>

Hi,

2010/6/19 Antonio Cuni <anto.cuni at gmail.com>:
> I also don't like too much to have a hardcoded version number, but when I
> asked for alternatives nobody suggested anything.
>
> On IRC, amaury suggested to install the whole pypy distribution in its
> self-contained directory, more or less as cpython does on windows.
> I didn't think about this solution, but now I see that it might be a good one,
> as it would allow to have the same hierarchy on svn checkouts, user-specific
> installations and system-wide installations.
>
> The drawback is that it's a bit non-standard on unix; moreover, if we install
> pypy in say /opt/pypy1.2, it would be hard to put a binary in /usr/bin without
> hardcoding the path to pypy1.2 somewhere.

Is it possible to just put a symlink, or a small script in /usr/bin?

-- 
Amaury Forgeot d'Arc

From anto.cuni at gmail.com  Sat Jun 19 11:07:29 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 19 Jun 2010 11:07:29 +0200
Subject: [pypy-dev] virtualenv support and directory hierarchy
In-Reply-To: <AANLkTik52rQO-IYw3nfe_sonxqUgFrswomE6WZYytS7S@mail.gmail.com>
References: <4BFD364B.5030903@gmail.com>	<AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com>	<4C1C8006.1030009@gmail.com>
	<AANLkTik52rQO-IYw3nfe_sonxqUgFrswomE6WZYytS7S@mail.gmail.com>
Message-ID: <4C1C88D1.20308@gmail.com>

On 19/06/10 11:00, Amaury Forgeot d'Arc wrote:

>> The drawback is that it's a bit non-standard on unix; moreover, if we install
>> pypy in say /opt/pypy1.2, it would be hard to put a binary in /usr/bin without
>> hardcoding the path to pypy1.2 somewhere.
>
> Is it possible to just put a symlink, or a small script in /usr/bin?

yes, the symlink should be possible, as armin also points out. I already 
thought about it, but I was not sure that distributions like ubuntu allows to 
put a symlink in /usr/bin to something external.  But indeed, looking at my 
/usr/bin it seems that symlinks are used a lot, so it should be fine.

So, does this mean that we are going for solution number 2?




From fijall at gmail.com  Sat Jun 19 18:07:52 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 19 Jun 2010 10:07:52 -0600
Subject: [pypy-dev] virtualenv support and directory hierarchy
In-Reply-To: <4C1C88D1.20308@gmail.com>
References: <4BFD364B.5030903@gmail.com>
	<AANLkTiltAyA2_19AamEPmznhNkTDoCT9KGagmHWzHVrs@mail.gmail.com> 
	<4C1C8006.1030009@gmail.com>
	<AANLkTik52rQO-IYw3nfe_sonxqUgFrswomE6WZYytS7S@mail.gmail.com> 
	<4C1C88D1.20308@gmail.com>
Message-ID: <AANLkTinU39DVW6a0AfGVUbI7S7f32hJ4JRaVCObtLn2H@mail.gmail.com>

Personally, if given such choice I would go with 4) (don't care about
virtualenv from source checkout). I don't care myself and I don't
think many people would care (since they'll get pypy installed from
say ubuntu or fedora most likely).

Cheers,
fijal

On Sat, Jun 19, 2010 at 3:07 AM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> On 19/06/10 11:00, Amaury Forgeot d'Arc wrote:
>
>>> The drawback is that it's a bit non-standard on unix; moreover, if we
>>> install
>>> pypy in say /opt/pypy1.2, it would be hard to put a binary in /usr/bin
>>> without
>>> hardcoding the path to pypy1.2 somewhere.
>>
>> Is it possible to just put a symlink, or a small script in /usr/bin?
>
> yes, the symlink should be possible, as armin also points out. I already
> thought about it, but I was not sure that distributions like ubuntu allows
> to put a symlink in /usr/bin to something external. ?But indeed, looking at
> my /usr/bin it seems that symlinks are used a lot, so it should be fine.
>
> So, does this mean that we are going for solution number 2?
>
>
>
>

From tobami at googlemail.com  Fri Jun 25 13:08:06 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Fri, 25 Jun 2010 13:08:06 +0200
Subject: [pypy-dev] New speed.pypy.org version
Message-ID: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>

Hi all!,

I want to announce a new version of the benchmarks site speed.pypy.org.

After about 6 months, it finally shows the vision I had for such a website:
usefull for pypy developers but also for the general public following pypy's
or even other python implementation's development. On to the changes.

There are now three views: "Changes", "Timeline" and "Comparison":

The Overview was renamed to Changes, and its inline plot bars got removed
because you can get the exact same plot in the Comparison view now (and then
some).

The Timeline got selectable baseline and "humanized" date labels for the x
axis.

The new Comparison view allows, well, comparing of "competing" interpreters,
which will also be of interest to the wider Python community (specially if
we can add unladen, ironpython and JPython results).


Two examples of interesting comparisons are:

- relative bars (
http://speed.pypy.org/comparison/?bas=2%2B35&chart=relative+bars): here we
see that the jit is faster than psyco in all cases except spambayes and
slowspitfire, were the jit cannot make up for pypy-c's abismal performance.
Interestingly, in the only other case where the jit is slower than cpython,
the ai benchmark, psyco performs even worse.

- stacked bars horizontal(
http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
This is not meant to "demonstrate" that overall the jit is over two times
faster than cpython. It is just another way for a developer to picture how
long a programme would take to complete if it were composed of 21 such
tasks. You can see that cpython's (the normalization chosen) benchmarks all
take 1"relative" second. pypy-c needs more or less the same time, some
"tasks" being slower and some faster. Psyco shows an interesting picture:
>From meteor-contest downwards (fortuitously) , all benchmarks are extremely
"compressed", which means they are speeded up by psyco quite a lot. But any
further speed up wouldn't make overall time much shorter because the first
group of benchmarks now takes most of the time to complete. pypy-c-jit is a
more extreme case of this: If the jit accelerated all "fast" benchmarks to 0
seconds (infinitely fast), it would only get about twice as fast as now
because ai, slowspitfire, spambayes and twisted_tcp now need half the entire
execution time. An good demonstration of "you are only as fast as your
slowest part". Of course the aggregate of all benchmarks is not a real app,
but it is still fun.

I hope you find the new version useful, and as always any feedback is
welcome.

Cheers!
Miquel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100625/3696287a/attachment.htm 

From anto.cuni at gmail.com  Fri Jun 25 13:43:25 2010
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Fri, 25 Jun 2010 13:43:25 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
Message-ID: <4C24965D.2030808@gmail.com>

Hi Miquel,

On 25/06/10 13:08, Miquel Torres wrote:
> Hi all!,

[cut]
> I hope you find the new version useful, and as always any feedback is
> welcome.

well... what to say? I simply like it *a lot*. Thank you :-)

I especially think that the "Changes" view is very useful for us developers, 
in particular the fact that you can see the log for all the revisions that 
affected the change: it is something that we did tons of time manually, it's 
nice to see it automated :-).

ciao,
Anto

From p.giarrusso at gmail.com  Fri Jun 25 14:07:44 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Fri, 25 Jun 2010 14:07:44 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
Message-ID: <AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com>

Hi!
First, I want to restate the obvious, before pointing out what I think
is a mistake: your work on this website is great and very useful!

On Fri, Jun 25, 2010 at 13:08, Miquel Torres <tobami at googlemail.com> wrote:
> - stacked bars
Here you are summing up normalized times, which is more or less like
taking their arithmetic average. And that doesn't work at all: in many
cases you can "show" completely different results by normalizing
relatively to another item. Even the simple question "who is faster?"
can be answered in different ways
So you should use the geometric mean, even if this is not so widely
known. Or better, it is known by benchmarking experts, but it's
difficult to become so.

Please, have a look at the short paper:
"How not to lie with statistics: the correct way to summarize benchmark results"
http://scholar.google.com/scholar?cluster=1051144955483053492&hl=en&as_sdt=2000
I downloaded it from the ACM library, please tell me if you can't find it.

> horizontal(http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
> This is not meant to "demonstrate" that overall the jit is over two times
> faster than cpython. It is just another way for a developer to picture how
> long a programme would take to complete if it were composed of 21 such
> tasks.

You are not summing up absolute times, so your claim is incorrect. And
the error is significant, given the above paper.
A sum of absolute times would provide what you claim.

> You can see that cpython's (the normalization chosen) benchmarks all
> take 1"relative" second.
Here, for instance, I see that CPython and pypy-c take more or less
the same time, which surprises me (since the PyPy interpreter was
known to be slower than CPython). But given that the result is
invalid, it may well be an artifact of your statistics.

> pypy-c needs more or less the same time, some
> "tasks" being slower and some faster. Psyco shows an interesting picture:
> From meteor-contest downwards (fortuitously) , all benchmarks are extremely
> "compressed", which means they are speeded up by psyco quite a lot. But any
> further speed up wouldn't make overall time much shorter because the first
> group of benchmarks now takes most of the time to complete. pypy-c-jit is a
> more extreme case of this: If the jit accelerated all "fast" benchmarks to 0
> seconds (infinitely fast), it would only get about twice as fast as now
> because ai, slowspitfire, spambayes and twisted_tcp now need half the entire
> execution time. An good demonstration of "you are only as fast as your
> slowest part". Of course the aggregate of all benchmarks is not a real app,
> but it is still fun.

This could maybe be still true, at least in part, but you have to do
this reasoning on absolute times.

Best regards, and keep up the good work!
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/

From fijall at gmail.com  Fri Jun 25 17:42:13 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 25 Jun 2010 09:42:13 -0600
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
Message-ID: <AANLkTikiQf_4QHtPJsyecdyI9JgPTOZ0cLC1lwYWSzjc@mail.gmail.com>

On Fri, Jun 25, 2010 at 5:08 AM, Miquel Torres <tobami at googlemail.com> wrote:
> Hi all!,
>
> I want to announce a new version of the benchmarks site speed.pypy.org.
>
> After about 6 months, it finally shows the vision I had for such a website:
> usefull for pypy developers but also for the general public following pypy's
> or even other python implementation's development. On to the changes.
>
> There are now three views: "Changes", "Timeline" and "Comparison":
>
> The Overview was renamed to Changes, and its inline plot bars got removed
> because you can get the exact same plot in the Comparison view now (and then
> some).
>
> The Timeline got selectable baseline and "humanized" date labels for the x
> axis.
>
> The new Comparison view allows, well, comparing of "competing" interpreters,
> which will also be of interest to the wider Python community (specially if
> we can add unladen, ironpython and JPython results).
>
>
> Two examples of interesting comparisons are:
>
> - relative bars
> (http://speed.pypy.org/comparison/?bas=2%2B35&chart=relative+bars): here we
> see that the jit is faster than psyco in all cases except spambayes and
> slowspitfire, were the jit cannot make up for pypy-c's abismal performance.
> Interestingly, in the only other case where the jit is slower than cpython,
> the ai benchmark, psyco performs even worse.
>
> - stacked bars
> horizontal(http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
> This is not meant to "demonstrate" that overall the jit is over two times
> faster than cpython. It is just another way for a developer to picture how
> long a programme would take to complete if it were composed of 21 such
> tasks. You can see that cpython's (the normalization chosen) benchmarks all
> take 1"relative" second. pypy-c needs more or less the same time, some
> "tasks" being slower and some faster. Psyco shows an interesting picture:
> From meteor-contest downwards (fortuitously) , all benchmarks are extremely
> "compressed", which means they are speeded up by psyco quite a lot. But any
> further speed up wouldn't make overall time much shorter because the first
> group of benchmarks now takes most of the time to complete. pypy-c-jit is a
> more extreme case of this: If the jit accelerated all "fast" benchmarks to 0
> seconds (infinitely fast), it would only get about twice as fast as now
> because ai, slowspitfire, spambayes and twisted_tcp now need half the entire
> execution time. An good demonstration of "you are only as fast as your
> slowest part". Of course the aggregate of all benchmarks is not a real app,
> but it is still fun.
>
> I hope you find the new version useful, and as always any feedback is
> welcome.
>
> Cheers!
> Miquel
>

Wow, I really like it, great job.

Can we see how we can use this features for branches?

Cheers,
fijal

From fijall at gmail.com  Fri Jun 25 17:53:45 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 25 Jun 2010 09:53:45 -0600
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com> 
	<AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com>
Message-ID: <AANLkTikq3ECxv84eTosDRmiCVO1u2qmmaBc23SdQIG2T@mail.gmail.com>

Hey Paolo.

While in general I agree with you, this is not exactly science, I
still think it's giving somewhat an impression what's going on to
outsiders. Inside, we still look mostly at particular benchmarks. I'm
not sure having any convoluted (at least to normal people) metric
while summarizing would help, maybe. Speaking a bit on Miguel's
behalf, feel free to implement this as a feature on codespeed (it's an
open source project after all), you can fork it on github
http://github.com/tobami/codespeed.

Cheers,
fijal

On Fri, Jun 25, 2010 at 6:07 AM, Paolo Giarrusso <p.giarrusso at gmail.com> wrote:
> Hi!
> First, I want to restate the obvious, before pointing out what I think
> is a mistake: your work on this website is great and very useful!
>
> On Fri, Jun 25, 2010 at 13:08, Miquel Torres <tobami at googlemail.com> wrote:
>> - stacked bars
> Here you are summing up normalized times, which is more or less like
> taking their arithmetic average. And that doesn't work at all: in many
> cases you can "show" completely different results by normalizing
> relatively to another item. Even the simple question "who is faster?"
> can be answered in different ways
> So you should use the geometric mean, even if this is not so widely
> known. Or better, it is known by benchmarking experts, but it's
> difficult to become so.
>
> Please, have a look at the short paper:
> "How not to lie with statistics: the correct way to summarize benchmark results"
> http://scholar.google.com/scholar?cluster=1051144955483053492&hl=en&as_sdt=2000
> I downloaded it from the ACM library, please tell me if you can't find it.
>
>> horizontal(http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
>> This is not meant to "demonstrate" that overall the jit is over two times
>> faster than cpython. It is just another way for a developer to picture how
>> long a programme would take to complete if it were composed of 21 such
>> tasks.
>
> You are not summing up absolute times, so your claim is incorrect. And
> the error is significant, given the above paper.
> A sum of absolute times would provide what you claim.
>
>> You can see that cpython's (the normalization chosen) benchmarks all
>> take 1"relative" second.
> Here, for instance, I see that CPython and pypy-c take more or less
> the same time, which surprises me (since the PyPy interpreter was
> known to be slower than CPython). But given that the result is
> invalid, it may well be an artifact of your statistics.
>
>> pypy-c needs more or less the same time, some
>> "tasks" being slower and some faster. Psyco shows an interesting picture:
>> From meteor-contest downwards (fortuitously) , all benchmarks are extremely
>> "compressed", which means they are speeded up by psyco quite a lot. But any
>> further speed up wouldn't make overall time much shorter because the first
>> group of benchmarks now takes most of the time to complete. pypy-c-jit is a
>> more extreme case of this: If the jit accelerated all "fast" benchmarks to 0
>> seconds (infinitely fast), it would only get about twice as fast as now
>> because ai, slowspitfire, spambayes and twisted_tcp now need half the entire
>> execution time. An good demonstration of "you are only as fast as your
>> slowest part". Of course the aggregate of all benchmarks is not a real app,
>> but it is still fun.
>
> This could maybe be still true, at least in part, but you have to do
> this reasoning on absolute times.
>
> Best regards, and keep up the good work!
> --
> Paolo Giarrusso - Ph.D. Student
> http://www.informatik.uni-marburg.de/~pgiarrusso/
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Fri Jun 25 18:16:01 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 25 Jun 2010 10:16:01 -0600
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
Message-ID: <AANLkTilZOujLAtcn56Ed0dFSAO_agkpAsvhyZTpVQ16F@mail.gmail.com>

Hey.

A bit more important problem - results seem to be messed up. I think
there is something wrong with baselines. Look here:
http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-32/builds/358/steps/shell_2/logs/stdio

on twisted_tcp

vs

http://speed.pypy.org/timeline/?exe=1,3&base=2%2B35&ben=twisted_tcp&env=tannit&revs=200

On Fri, Jun 25, 2010 at 5:08 AM, Miquel Torres <tobami at googlemail.com> wrote:
> Hi all!,
>
> I want to announce a new version of the benchmarks site speed.pypy.org.
>
> After about 6 months, it finally shows the vision I had for such a website:
> usefull for pypy developers but also for the general public following pypy's
> or even other python implementation's development. On to the changes.
>
> There are now three views: "Changes", "Timeline" and "Comparison":
>
> The Overview was renamed to Changes, and its inline plot bars got removed
> because you can get the exact same plot in the Comparison view now (and then
> some).
>
> The Timeline got selectable baseline and "humanized" date labels for the x
> axis.
>
> The new Comparison view allows, well, comparing of "competing" interpreters,
> which will also be of interest to the wider Python community (specially if
> we can add unladen, ironpython and JPython results).
>
>
> Two examples of interesting comparisons are:
>
> - relative bars
> (http://speed.pypy.org/comparison/?bas=2%2B35&chart=relative+bars): here we
> see that the jit is faster than psyco in all cases except spambayes and
> slowspitfire, were the jit cannot make up for pypy-c's abismal performance.
> Interestingly, in the only other case where the jit is slower than cpython,
> the ai benchmark, psyco performs even worse.
>
> - stacked bars
> horizontal(http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
> This is not meant to "demonstrate" that overall the jit is over two times
> faster than cpython. It is just another way for a developer to picture how
> long a programme would take to complete if it were composed of 21 such
> tasks. You can see that cpython's (the normalization chosen) benchmarks all
> take 1"relative" second. pypy-c needs more or less the same time, some
> "tasks" being slower and some faster. Psyco shows an interesting picture:
> From meteor-contest downwards (fortuitously) , all benchmarks are extremely
> "compressed", which means they are speeded up by psyco quite a lot. But any
> further speed up wouldn't make overall time much shorter because the first
> group of benchmarks now takes most of the time to complete. pypy-c-jit is a
> more extreme case of this: If the jit accelerated all "fast" benchmarks to 0
> seconds (infinitely fast), it would only get about twice as fast as now
> because ai, slowspitfire, spambayes and twisted_tcp now need half the entire
> execution time. An good demonstration of "you are only as fast as your
> slowest part". Of course the aggregate of all benchmarks is not a real app,
> but it is still fun.
>
> I hope you find the new version useful, and as always any feedback is
> welcome.
>
> Cheers!
> Miquel
>
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From tobami at googlemail.com  Fri Jun 25 19:08:23 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Fri, 25 Jun 2010 19:08:23 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
	<AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com>
Message-ID: <AANLkTinQrHMlLILHkEZzJWflcKCA2MHS3AcKuwAZ8wfc@mail.gmail.com>

Hi Paolo,

I am aware of the problem with calculating benchmark means, but let me
explain my point of view.

You are correct in that it would be preferable to have absolute times. Well,
you actually can, but see what it happens:
http://speed.pypy.org/comparison/?hor=true&bas=none&chart=stacked+bars

Absolute values would only work if we had carefully chosen benchmaks
runtimes to be very similar (for our cpython baseline). As it is, html5lib,
spitfire and spitfire_cstringio completely dominate the cummulative time.
And not because the interpreter is faster or slower but because the
benchmark was arbitrarily designed to run that long. Any improvement in the
long running benchmarks will carry much more weight than in the short
running.

What is more useful is to have comparable slices of time so that the
improvements can be seen relatively over time. Normalizing does that i
think. It just says: we have 21 tasks which take 1 second to run each on
interpreter X (cpython in the default case). Then we see how other
executables compare to that. What would the geometric mean achieve here,
exactly, for the end user?

I am not really calculating any mean. You can see that I carefully avoided
to display any kind of total bar which would indeed incur in the problem you
mention. That a stacked chart implicitly displays a total is something you
can not avoid, and for that kind of chart I still think normalized results
is visually the best option.

Still, i would very much like to read the paper you cite, but you need a
login for it.

Cheers,
Miquel


2010/6/25 Paolo Giarrusso <p.giarrusso at gmail.com>

> Hi!
> First, I want to restate the obvious, before pointing out what I think
> is a mistake: your work on this website is great and very useful!
>
> On Fri, Jun 25, 2010 at 13:08, Miquel Torres <tobami at googlemail.com>
> wrote:
> > - stacked bars
> Here you are summing up normalized times, which is more or less like
> taking their arithmetic average. And that doesn't work at all: in many
> cases you can "show" completely different results by normalizing
> relatively to another item. Even the simple question "who is faster?"
> can be answered in different ways
> So you should use the geometric mean, even if this is not so widely
> known. Or better, it is known by benchmarking experts, but it's
> difficult to become so.
>
> Please, have a look at the short paper:
> "How not to lie with statistics: the correct way to summarize benchmark
> results"
>
> http://scholar.google.com/scholar?cluster=1051144955483053492&hl=en&as_sdt=2000
> I downloaded it from the ACM library, please tell me if you can't find it.
>
> > horizontal(
> http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
> > This is not meant to "demonstrate" that overall the jit is over two times
> > faster than cpython. It is just another way for a developer to picture
> how
> > long a programme would take to complete if it were composed of 21 such
> > tasks.
>
> You are not summing up absolute times, so your claim is incorrect. And
> the error is significant, given the above paper.
> A sum of absolute times would provide what you claim.
>
> > You can see that cpython's (the normalization chosen) benchmarks all
> > take 1"relative" second.
> Here, for instance, I see that CPython and pypy-c take more or less
> the same time, which surprises me (since the PyPy interpreter was
> known to be slower than CPython). But given that the result is
> invalid, it may well be an artifact of your statistics.
>
> > pypy-c needs more or less the same time, some
> > "tasks" being slower and some faster. Psyco shows an interesting picture:
> > From meteor-contest downwards (fortuitously) , all benchmarks are
> extremely
> > "compressed", which means they are speeded up by psyco quite a lot. But
> any
> > further speed up wouldn't make overall time much shorter because the
> first
> > group of benchmarks now takes most of the time to complete. pypy-c-jit is
> a
> > more extreme case of this: If the jit accelerated all "fast" benchmarks
> to 0
> > seconds (infinitely fast), it would only get about twice as fast as now
> > because ai, slowspitfire, spambayes and twisted_tcp now need half the
> entire
> > execution time. An good demonstration of "you are only as fast as your
> > slowest part". Of course the aggregate of all benchmarks is not a real
> app,
> > but it is still fun.
>
> This could maybe be still true, at least in part, but you have to do
> this reasoning on absolute times.
>
> Best regards, and keep up the good work!
> --
> Paolo Giarrusso - Ph.D. Student
> http://www.informatik.uni-marburg.de/~pgiarrusso/<http://www.informatik.uni-marburg.de/%7Epgiarrusso/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100625/ca26fe45/attachment-0001.htm 

From tobami at googlemail.com  Fri Jun 25 19:14:23 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Fri, 25 Jun 2010 19:14:23 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTilZOujLAtcn56Ed0dFSAO_agkpAsvhyZTpVQ16F@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
	<AANLkTilZOujLAtcn56Ed0dFSAO_agkpAsvhyZTpVQ16F@mail.gmail.com>
Message-ID: <AANLkTilp0M-3258hnN-pYNpBBZua5mbr8Y_W88RdETAn@mail.gmail.com>

Hey fijal,

the baseline problem you mention only happens with some benchmarks, so I
will risk the guess that the cpython results currently present are not from
the last one, and that in the case you point out (only for twisted_tcp) it
changed quite a bit. If the next results overwrite cpython's results, we'll
see if that has been the case.


2010/6/25 Maciej Fijalkowski <fijall at gmail.com>

> Hey.
>
> A bit more important problem - results seem to be messed up. I think
> there is something wrong with baselines. Look here:
>
> http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-32/builds/358/steps/shell_2/logs/stdio
>
> on twisted_tcp
>
> vs
>
>
> http://speed.pypy.org/timeline/?exe=1,3&base=2%2B35&ben=twisted_tcp&env=tannit&revs=200
>
> On Fri, Jun 25, 2010 at 5:08 AM, Miquel Torres <tobami at googlemail.com>
> wrote:
> > Hi all!,
> >
> > I want to announce a new version of the benchmarks site speed.pypy.org.
> >
> > After about 6 months, it finally shows the vision I had for such a
> website:
> > usefull for pypy developers but also for the general public following
> pypy's
> > or even other python implementation's development. On to the changes.
> >
> > There are now three views: "Changes", "Timeline" and "Comparison":
> >
> > The Overview was renamed to Changes, and its inline plot bars got removed
> > because you can get the exact same plot in the Comparison view now (and
> then
> > some).
> >
> > The Timeline got selectable baseline and "humanized" date labels for the
> x
> > axis.
> >
> > The new Comparison view allows, well, comparing of "competing"
> interpreters,
> > which will also be of interest to the wider Python community (specially
> if
> > we can add unladen, ironpython and JPython results).
> >
> >
> > Two examples of interesting comparisons are:
> >
> > - relative bars
> > (http://speed.pypy.org/comparison/?bas=2%2B35&chart=relative+bars): here
> we
> > see that the jit is faster than psyco in all cases except spambayes and
> > slowspitfire, were the jit cannot make up for pypy-c's abismal
> performance.
> > Interestingly, in the only other case where the jit is slower than
> cpython,
> > the ai benchmark, psyco performs even worse.
> >
> > - stacked bars
> > horizontal(
> http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
> > This is not meant to "demonstrate" that overall the jit is over two times
> > faster than cpython. It is just another way for a developer to picture
> how
> > long a programme would take to complete if it were composed of 21 such
> > tasks. You can see that cpython's (the normalization chosen) benchmarks
> all
> > take 1"relative" second. pypy-c needs more or less the same time, some
> > "tasks" being slower and some faster. Psyco shows an interesting picture:
> > From meteor-contest downwards (fortuitously) , all benchmarks are
> extremely
> > "compressed", which means they are speeded up by psyco quite a lot. But
> any
> > further speed up wouldn't make overall time much shorter because the
> first
> > group of benchmarks now takes most of the time to complete. pypy-c-jit is
> a
> > more extreme case of this: If the jit accelerated all "fast" benchmarks
> to 0
> > seconds (infinitely fast), it would only get about twice as fast as now
> > because ai, slowspitfire, spambayes and twisted_tcp now need half the
> entire
> > execution time. An good demonstration of "you are only as fast as your
> > slowest part". Of course the aggregate of all benchmarks is not a real
> app,
> > but it is still fun.
> >
> > I hope you find the new version useful, and as always any feedback is
> > welcome.
> >
> > Cheers!
> > Miquel
> >
> >
> > _______________________________________________
> > pypy-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/pypy-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100625/5981f42a/attachment.htm 

From tobami at googlemail.com  Fri Jun 25 19:23:13 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Fri, 25 Jun 2010 19:23:13 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTikiQf_4QHtPJsyecdyI9JgPTOZ0cLC1lwYWSzjc@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
	<AANLkTikiQf_4QHtPJsyecdyI9JgPTOZ0cLC1lwYWSzjc@mail.gmail.com>
Message-ID: <AANLkTin5ddE4Qh8GvI4rU_c_NXRRBzswfp4NZongbiM2@mail.gmail.com>

There is no problem in running tests for branches. What other branches or
interpreters would you for example run?


2010/6/25 Maciej Fijalkowski <fijall at gmail.com>

> On Fri, Jun 25, 2010 at 5:08 AM, Miquel Torres <tobami at googlemail.com>
> wrote:
> > Hi all!,
> >
> > I want to announce a new version of the benchmarks site speed.pypy.org.
> >
> > After about 6 months, it finally shows the vision I had for such a
> website:
> > usefull for pypy developers but also for the general public following
> pypy's
> > or even other python implementation's development. On to the changes.
> >
> > There are now three views: "Changes", "Timeline" and "Comparison":
> >
> > The Overview was renamed to Changes, and its inline plot bars got removed
> > because you can get the exact same plot in the Comparison view now (and
> then
> > some).
> >
> > The Timeline got selectable baseline and "humanized" date labels for the
> x
> > axis.
> >
> > The new Comparison view allows, well, comparing of "competing"
> interpreters,
> > which will also be of interest to the wider Python community (specially
> if
> > we can add unladen, ironpython and JPython results).
> >
> >
> > Two examples of interesting comparisons are:
> >
> > - relative bars
> > (http://speed.pypy.org/comparison/?bas=2%2B35&chart=relative+bars): here
> we
> > see that the jit is faster than psyco in all cases except spambayes and
> > slowspitfire, were the jit cannot make up for pypy-c's abismal
> performance.
> > Interestingly, in the only other case where the jit is slower than
> cpython,
> > the ai benchmark, psyco performs even worse.
> >
> > - stacked bars
> > horizontal(
> http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
> > This is not meant to "demonstrate" that overall the jit is over two times
> > faster than cpython. It is just another way for a developer to picture
> how
> > long a programme would take to complete if it were composed of 21 such
> > tasks. You can see that cpython's (the normalization chosen) benchmarks
> all
> > take 1"relative" second. pypy-c needs more or less the same time, some
> > "tasks" being slower and some faster. Psyco shows an interesting picture:
> > From meteor-contest downwards (fortuitously) , all benchmarks are
> extremely
> > "compressed", which means they are speeded up by psyco quite a lot. But
> any
> > further speed up wouldn't make overall time much shorter because the
> first
> > group of benchmarks now takes most of the time to complete. pypy-c-jit is
> a
> > more extreme case of this: If the jit accelerated all "fast" benchmarks
> to 0
> > seconds (infinitely fast), it would only get about twice as fast as now
> > because ai, slowspitfire, spambayes and twisted_tcp now need half the
> entire
> > execution time. An good demonstration of "you are only as fast as your
> > slowest part". Of course the aggregate of all benchmarks is not a real
> app,
> > but it is still fun.
> >
> > I hope you find the new version useful, and as always any feedback is
> > welcome.
> >
> > Cheers!
> > Miquel
> >
>
> Wow, I really like it, great job.
>
> Can we see how we can use this features for branches?
>
> Cheers,
> fijal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100625/2d3237a5/attachment.htm 

From fijall at gmail.com  Fri Jun 25 19:28:21 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 25 Jun 2010 11:28:21 -0600
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTin5ddE4Qh8GvI4rU_c_NXRRBzswfp4NZongbiM2@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com> 
	<AANLkTikiQf_4QHtPJsyecdyI9JgPTOZ0cLC1lwYWSzjc@mail.gmail.com> 
	<AANLkTin5ddE4Qh8GvI4rU_c_NXRRBzswfp4NZongbiM2@mail.gmail.com>
Message-ID: <AANLkTilu5sm4WqUyrwP5azhbIISHFsEOHk8TIEghm_1G@mail.gmail.com>

PyPy branches mostly (did this improve or not really kind of question)

On Fri, Jun 25, 2010 at 11:23 AM, Miquel Torres <tobami at googlemail.com> wrote:
> There is no problem in running tests for branches. What other branches or
> interpreters would you for example run?
>
>
> 2010/6/25 Maciej Fijalkowski <fijall at gmail.com>
>>
>> On Fri, Jun 25, 2010 at 5:08 AM, Miquel Torres <tobami at googlemail.com>
>> wrote:
>> > Hi all!,
>> >
>> > I want to announce a new version of the benchmarks site speed.pypy.org.
>> >
>> > After about 6 months, it finally shows the vision I had for such a
>> > website:
>> > usefull for pypy developers but also for the general public following
>> > pypy's
>> > or even other python implementation's development. On to the changes.
>> >
>> > There are now three views: "Changes", "Timeline" and "Comparison":
>> >
>> > The Overview was renamed to Changes, and its inline plot bars got
>> > removed
>> > because you can get the exact same plot in the Comparison view now (and
>> > then
>> > some).
>> >
>> > The Timeline got selectable baseline and "humanized" date labels for the
>> > x
>> > axis.
>> >
>> > The new Comparison view allows, well, comparing of "competing"
>> > interpreters,
>> > which will also be of interest to the wider Python community (specially
>> > if
>> > we can add unladen, ironpython and JPython results).
>> >
>> >
>> > Two examples of interesting comparisons are:
>> >
>> > - relative bars
>> > (http://speed.pypy.org/comparison/?bas=2%2B35&chart=relative+bars): here
>> > we
>> > see that the jit is faster than psyco in all cases except spambayes and
>> > slowspitfire, were the jit cannot make up for pypy-c's abismal
>> > performance.
>> > Interestingly, in the only other case where the jit is slower than
>> > cpython,
>> > the ai benchmark, psyco performs even worse.
>> >
>> > - stacked bars
>> >
>> > horizontal(http://speed.pypy.org/comparison/?hor=true&bas=2%2B35&chart=stacked+bars):
>> > This is not meant to "demonstrate" that overall the jit is over two
>> > times
>> > faster than cpython. It is just another way for a developer to picture
>> > how
>> > long a programme would take to complete if it were composed of 21 such
>> > tasks. You can see that cpython's (the normalization chosen) benchmarks
>> > all
>> > take 1"relative" second. pypy-c needs more or less the same time, some
>> > "tasks" being slower and some faster. Psyco shows an interesting
>> > picture:
>> > From meteor-contest downwards (fortuitously) , all benchmarks are
>> > extremely
>> > "compressed", which means they are speeded up by psyco quite a lot. But
>> > any
>> > further speed up wouldn't make overall time much shorter because the
>> > first
>> > group of benchmarks now takes most of the time to complete. pypy-c-jit
>> > is a
>> > more extreme case of this: If the jit accelerated all "fast" benchmarks
>> > to 0
>> > seconds (infinitely fast), it would only get about twice as fast as now
>> > because ai, slowspitfire, spambayes and twisted_tcp now need half the
>> > entire
>> > execution time. An good demonstration of "you are only as fast as your
>> > slowest part". Of course the aggregate of all benchmarks is not a real
>> > app,
>> > but it is still fun.
>> >
>> > I hope you find the new version useful, and as always any feedback is
>> > welcome.
>> >
>> > Cheers!
>> > Miquel
>> >
>>
>> Wow, I really like it, great job.
>>
>> Can we see how we can use this features for branches?
>>
>> Cheers,
>> fijal
>
>

From p.giarrusso at gmail.com  Fri Jun 25 22:48:59 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Fri, 25 Jun 2010 22:48:59 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTikq3ECxv84eTosDRmiCVO1u2qmmaBc23SdQIG2T@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com> 
	<AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com> 
	<AANLkTikq3ECxv84eTosDRmiCVO1u2qmmaBc23SdQIG2T@mail.gmail.com>
Message-ID: <AANLkTikurZHrEgbxpldA-4ZbWFYrAdSi7E2orJqqEAcB@mail.gmail.com>

On Fri, Jun 25, 2010 at 17:53, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Hey Paolo.
>
> While in general I agree with you, this is not exactly science, I
> still think it's giving somewhat an impression what's going on to
> outsiders.
As long as no important scholars look at that part, and it's just me,
yes. When that happen, you probably lose some credibility. No matter
if speed.pypy.org is made by people external to the team.

> Inside, we still look mostly at particular benchmarks.

But if a change improves one benchmark and worsens another, you need
some summary.

> I'm
> not sure having any convoluted (at least to normal people) metric
> while summarizing would help, maybe.
You're talking to programmers, not to street people. Even before
knowing why I should use the geomean here, I never felt too confused
by people using it, even without explanation.

The geometric mean is just a mean. And it's the only way to get an
average performance ratio: how much faster is PyPy than CPython, on
these benchmarks, considered all with equal weight? If you want, put
just this on the graph, and the term "geometric mean" in some note.

> Speaking a bit on Miguel's
> behalf, feel free to implement this as a feature on codespeed (it's an
> open source project after all), you can fork it on github
> http://github.com/tobami/codespeed.

Of course I can, so your answer is valid, but that's not my plan,
sorry - the difference of effort needed to me and to him is huge. If I
had time to spend, I'd hack PyPy itself instead.

Best regards
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/

From p.giarrusso at gmail.com  Fri Jun 25 22:50:39 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Fri, 25 Jun 2010 22:50:39 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTinQrHMlLILHkEZzJWflcKCA2MHS3AcKuwAZ8wfc@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com> 
	<AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com> 
	<AANLkTinQrHMlLILHkEZzJWflcKCA2MHS3AcKuwAZ8wfc@mail.gmail.com>
Message-ID: <AANLkTinqbrpWH-_pujnDtBarHHfDK7kl-oQY95BwW2LC@mail.gmail.com>

On Fri, Jun 25, 2010 at 19:08, Miquel Torres <tobami at googlemail.com> wrote:
> Hi Paolo,
>
> I am aware of the problem with calculating benchmark means, but let me
> explain my point of view.
>
> You are correct in that it would be preferable to have absolute times. Well,
> you actually can, but see what it happens:
> http://speed.pypy.org/comparison/?hor=true&bas=none&chart=stacked+bars

Ahah! I didn't notice that I could skip normalization! This does not
fully invalidate my point, however.

> Absolute values would only work if we had carefully chosen benchmaks
> runtimes to be very similar (for our cpython baseline). As it is, html5lib,
> spitfire and spitfire_cstringio completely dominate the cummulative time.

I acknowledge that (btw, it should be cumulative time, with one 'm',
both here and in the website).

> And not because the interpreter is faster or slower but because the
> benchmark was arbitrarily designed to run that long. Any improvement in the
> long running benchmarks will carry much more weight than in the short
> running.

> What is more useful is to have comparable slices of time so that the
> improvements can be seen relatively over time.

If you want to sum up times (but at this point, I see no reason for
it), you should rather have externally derived weights, as suggested
by the paper (in Rule 3).
As soon as you take weights from the data, lots of maths that you need
is not going to work any more - that's generally true in many cases in
statistics.
And the only way making sense to have external weights is to gather
them from real world programs. Since that's not going to happen
easily, just stick with the geometric mean. Or set an arbitrarily low
weight, manually, without any math, so that the long-running
benchmarks stop dominating the res. It's no fraud, since the current
graph is less valid anyway.

> Normalizing does that i
> think.
Not really.

> It just says: we have 21 tasks which take 1 second to run each on
> interpreter X (cpython in the default case). Then we see how other
> executables compare to that. What would the geometric mean achieve here,
> exactly, for the end user?

You actually need the geomean to do that. Don't forget that the
geomean is still a mean: it's a mean performance ratio which averages
individual performance ratios.
If PyPy's geomean is 0.5, it means that PyPy is going to run that task
in 11.5 seconds instead of 21. To me, this sounds exactly like what
you want to achieve. Moreover, it actually works, unlike what you use.

For instance, ignore PyPy-JIT, and look only CPython and pypy-c (no
JIT). Then, change the normalization among the two:
http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=2%2B35&chart=stacked+bars
http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=3%2BL&chart=stacked+bars
with the current data, you get that in one case cpython is faster, in
the other pypy-c is faster.
It can't happen with the geomean. This is the point of the paper.

I could even construct a normalization baseline $base such that
CPython seems faster than PyPy-JIT. Such a base should be very fast
on, say, ai (where CPython is slower), so that $cpython.ai/$base.ai
becomes 100 and $pypyjit.ai/$base.ai becomes 200, and be very slow on
other benchmarks (so that they disappear in the sum).

So, the only difference I see is that geomean works, arithm. mean
doesn't. That's why Real Benchmarkers use geomean.

Moreover, you are making a mistake quite common among non-physicists.
What you say makes sense under the implicit assumption that dividing
two times gives something you can use as a time. When you say "Pypy's
runtime for a 1 second task", you actually want to talk about a
performance ratio, not about the time. In the same way as when you say
"this bird runs 3 meters long in one second", a physicist would sum
that up as "3 m/s" rather than "3 m".

> I am not really calculating any mean. You can see that I carefully avoided
> to display any kind of total bar which would indeed incur in the problem you
> mention. That a stacked chart implicitly displays a total is something you
> can not avoid, and for that kind of chart I still think normalized results
> is visually the best option.

But on a stacked bars graph, I'm not going to look at individual bars
at all, just at the total: it's actually less convenient than in
"normal bars" to look at the result of a particular benchmark.

I hope I can find guidelines against stacked plots, I have a PhD
colleague reading on how to make graphs.

Best regards
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/

From fijall at gmail.com  Sat Jun 26 01:27:52 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 25 Jun 2010 17:27:52 -0600
Subject: [pypy-dev] PyPy 1.3 released
Message-ID: <AANLkTikaN3p6BNFUfXL4RlWB28ZwjrajeUb34r8SGvdy@mail.gmail.com>

=======================
PyPy 1.3: Stabilization
=======================

Hello.

We're please to announce release of PyPy 1.3. This release has two major
improvements. First of all, we stabilized the JIT compiler since 1.2 release,
answered user issues, fixed bugs, and generally improved speed.

We're also pleased to announce alpha support for loading CPython extension
modules written in C. While the main purpose of this release is increased
stability, this feature is in alpha stage and it is not yet suited for
production environments.

Highlights of this release
==========================

* We introduced support for CPython extension modules written in C. As of now,
  this support is in alpha, and it's very unlikely unaltered C extensions will
  work out of the box, due to missing functions or refcounting details. The
  support is disable by default, so you have to do::

   import cpyext

  before trying to import any .so file. Also, libraries are source-compatible
  and not binary-compatible. That means you need to recompile binaries, using
  for example::

   python setup.py build

  Details may vary, depending on your build system. Make sure you include
  the above line at the beginning of setup.py or put it in your PYTHONSTARTUP.

  This is alpha feature. It'll likely segfault. You have been warned!

* JIT bugfixes. A lot of bugs reported for the JIT have been fixed, and its
  stability greatly improved since 1.2 release.

* Various small improvements have been added to the JIT code, as well as a great
  speedup of compiling time.

Cheers,
Maciej Fijalkowski, Armin Rigo, Alex Gaynor, Amaury Forgeot d'Arc and
the PyPy team

From tobami at googlemail.com  Sat Jun 26 09:16:52 2010
From: tobami at googlemail.com (Miquel Torres)
Date: Sat, 26 Jun 2010 09:16:52 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTinqbrpWH-_pujnDtBarHHfDK7kl-oQY95BwW2LC@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com>
	<AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com>
	<AANLkTinQrHMlLILHkEZzJWflcKCA2MHS3AcKuwAZ8wfc@mail.gmail.com>
	<AANLkTinqbrpWH-_pujnDtBarHHfDK7kl-oQY95BwW2LC@mail.gmail.com>
Message-ID: <AANLkTilgNm7a3o9pSUDgbHwxJ2bNqsYNajUK21JnFBT7@mail.gmail.com>

Hi Paolo,

well, you are right of course. I had forgotten about the real problem, which
you actually demonstrate quite well with your CPython and pypy-c case:
depending on the normalization you can make any stacked series look faster
than the others.

I will have a look at the literature and modify normalized stacked plots
accordingly.

Thanks for taking the time to explain things in such detail.

Regards,
Miquel


2010/6/25 Paolo Giarrusso <p.giarrusso at gmail.com>

> On Fri, Jun 25, 2010 at 19:08, Miquel Torres <tobami at googlemail.com>
> wrote:
> > Hi Paolo,
> >
> > I am aware of the problem with calculating benchmark means, but let me
> > explain my point of view.
> >
> > You are correct in that it would be preferable to have absolute times.
> Well,
> > you actually can, but see what it happens:
> > http://speed.pypy.org/comparison/?hor=true&bas=none&chart=stacked+bars
>
> Ahah! I didn't notice that I could skip normalization! This does not
> fully invalidate my point, however.
>
> > Absolute values would only work if we had carefully chosen benchmaks
> > runtimes to be very similar (for our cpython baseline). As it is,
> html5lib,
> > spitfire and spitfire_cstringio completely dominate the cummulative time.
>
> I acknowledge that (btw, it should be cumulative time, with one 'm',
> both here and in the website).
>
> > And not because the interpreter is faster or slower but because the
> > benchmark was arbitrarily designed to run that long. Any improvement in
> the
> > long running benchmarks will carry much more weight than in the short
> > running.
>
> > What is more useful is to have comparable slices of time so that the
> > improvements can be seen relatively over time.
>
> If you want to sum up times (but at this point, I see no reason for
> it), you should rather have externally derived weights, as suggested
> by the paper (in Rule 3).
> As soon as you take weights from the data, lots of maths that you need
> is not going to work any more - that's generally true in many cases in
> statistics.
> And the only way making sense to have external weights is to gather
> them from real world programs. Since that's not going to happen
> easily, just stick with the geometric mean. Or set an arbitrarily low
> weight, manually, without any math, so that the long-running
> benchmarks stop dominating the res. It's no fraud, since the current
> graph is less valid anyway.
>
> > Normalizing does that i
> > think.
> Not really.
>
> > It just says: we have 21 tasks which take 1 second to run each on
> > interpreter X (cpython in the default case). Then we see how other
> > executables compare to that. What would the geometric mean achieve here,
> > exactly, for the end user?
>
> You actually need the geomean to do that. Don't forget that the
> geomean is still a mean: it's a mean performance ratio which averages
> individual performance ratios.
> If PyPy's geomean is 0.5, it means that PyPy is going to run that task
> in 11.5 seconds instead of 21. To me, this sounds exactly like what
> you want to achieve. Moreover, it actually works, unlike what you use.
>
> For instance, ignore PyPy-JIT, and look only CPython and pypy-c (no
> JIT). Then, change the normalization among the two:
>
> http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=2%2B35&chart=stacked+bars
>
> http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=3%2BL&chart=stacked+bars
> with the current data, you get that in one case cpython is faster, in
> the other pypy-c is faster.
> It can't happen with the geomean. This is the point of the paper.
>
> I could even construct a normalization baseline $base such that
> CPython seems faster than PyPy-JIT. Such a base should be very fast
> on, say, ai (where CPython is slower), so that $cpython.ai/$base.ai
> becomes 100 and $pypyjit.ai/$base.ai becomes 200, and be very slow on
> other benchmarks (so that they disappear in the sum).
>
> So, the only difference I see is that geomean works, arithm. mean
> doesn't. That's why Real Benchmarkers use geomean.
>
> Moreover, you are making a mistake quite common among non-physicists.
> What you say makes sense under the implicit assumption that dividing
> two times gives something you can use as a time. When you say "Pypy's
> runtime for a 1 second task", you actually want to talk about a
> performance ratio, not about the time. In the same way as when you say
> "this bird runs 3 meters long in one second", a physicist would sum
> that up as "3 m/s" rather than "3 m".
>
> > I am not really calculating any mean. You can see that I carefully
> avoided
> > to display any kind of total bar which would indeed incur in the problem
> you
> > mention. That a stacked chart implicitly displays a total is something
> you
> > can not avoid, and for that kind of chart I still think normalized
> results
> > is visually the best option.
>
> But on a stacked bars graph, I'm not going to look at individual bars
> at all, just at the total: it's actually less convenient than in
> "normal bars" to look at the result of a particular benchmark.
>
> I hope I can find guidelines against stacked plots, I have a PhD
> colleague reading on how to make graphs.
>
> Best regards
> --
> Paolo Giarrusso - Ph.D. Student
> http://www.informatik.uni-marburg.de/~pgiarrusso/<http://www.informatik.uni-marburg.de/%7Epgiarrusso/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100626/e7965f36/attachment.htm 

From arigo at tunes.org  Sat Jun 26 10:34:57 2010
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 26 Jun 2010 10:34:57 +0200
Subject: [pypy-dev] PyPy 1.3 released
In-Reply-To: <AANLkTikaN3p6BNFUfXL4RlWB28ZwjrajeUb34r8SGvdy@mail.gmail.com>
References: <AANLkTikaN3p6BNFUfXL4RlWB28ZwjrajeUb34r8SGvdy@mail.gmail.com>
Message-ID: <20100626083457.GA14816@code0.codespeak.net>

Hi,

On Fri, Jun 25, 2010 at 05:27:52PM -0600, Maciej Fijalkowski wrote:
>    python setup.py build

As corrected on the blog (http://morepypy.blogspot.com/), this line
should read:

     pypy setup.py build


Armin.

From cfbolz at gmx.de  Mon Jun 28 15:08:08 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 28 Jun 2010 15:08:08 +0200
Subject: [pypy-dev] PyPy Master thesis sandboxing
Message-ID: <4C289EB8.4090702@gmx.de>

Hi all,

just wanted to point this Master thesis using PyPy out:

http://www.diku.dk/english/Calendar/masters_defence_soeren/

Didn't know about this, but interesting anyway.

Cheers,

Carl Friedrich

From fijall at gmail.com  Mon Jun 28 17:51:37 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 28 Jun 2010 09:51:37 -0600
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <4C289EB8.4090702@gmx.de>
References: <4C289EB8.4090702@gmx.de>
Message-ID: <AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com>

On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Hi all,
>
> just wanted to point this Master thesis using PyPy out:
>
> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>
> Didn't know about this, but interesting anyway.
>
> Cheers,
>
> Carl Friedrich

According to the abstract it was a poor choice :)

From cfbolz at gmx.de  Mon Jun 28 17:56:55 2010
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 28 Jun 2010 17:56:55 +0200
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com>
Message-ID: <4C28C647.2000008@gmx.de>

On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>  wrote:
>> Hi all,
>>
>> just wanted to point this Master thesis using PyPy out:
>>
>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>
>> Didn't know about this, but interesting anyway.
>>
>> Cheers,
>>
>> Carl Friedrich
>
> According to the abstract it was a poor choice :)

So it says. He never wrote anything on the mailing list though, I assume 
he showed up on IRC?

Cheers,

Carl Friedrich

From fijall at gmail.com  Mon Jun 28 18:00:45 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 28 Jun 2010 10:00:45 -0600
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <4C28C647.2000008@gmx.de>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com> 
	<4C28C647.2000008@gmx.de>
Message-ID: <AANLkTikb2hdzl4-_CU3QbvQ3VvLRh8plVvBnWaLRm4OL@mail.gmail.com>

On Mon, Jun 28, 2010 at 9:56 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>>
>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
>> ?wrote:
>>>
>>> Hi all,
>>>
>>> just wanted to point this Master thesis using PyPy out:
>>>
>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>
>>> Didn't know about this, but interesting anyway.
>>>
>>> Cheers,
>>>
>>> Carl Friedrich
>>
>> According to the abstract it was a poor choice :)
>
> So it says. He never wrote anything on the mailing list though, I assume he
> showed up on IRC?
>
> Cheers,
>
> Carl Friedrich
>

I don't honestly remember anyone showing up and speaking about that,
but well. Anyone?

Cheers,
fijal

From sl at scrooge.dk  Mon Jun 28 19:50:57 2010
From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=)
Date: Mon, 28 Jun 2010 19:50:57 +0200
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <4C28C647.2000008@gmx.de>
References: <4C289EB8.4090702@gmx.de>	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com>
	<4C28C647.2000008@gmx.de>
Message-ID: <7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com>

-----Oprindelig meddelelse-----
Fra: pypy-dev-bounces at codespeak.net
[mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
Sendt: 28. juni 2010 17:57
Til: Maciej Fijalkowski
Cc: PyPy Dev
Emne: Re: [pypy-dev] PyPy Master thesis sandboxing

On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
wrote:
>> Hi all,
>>
>> just wanted to point this Master thesis using PyPy out:
>>
>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>
>> Didn't know about this, but interesting anyway.
>>
>> Cheers,
>>
>> Carl Friedrich
>
> According to the abstract it was a poor choice :)

>So it says. He never wrote anything on the mailing list though, I assume
>he showed up on IRC?

I did wrote on the mailinglist:
http://permalink.gmane.org/gmane.comp.python.pypy/5987

This error was a show stopper, and some other strange errors using the
pickle module.

Regards,

S?ren

From fijall at gmail.com  Mon Jun 28 19:58:37 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 28 Jun 2010 11:58:37 -0600
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com> 
	<4C28C647.2000008@gmx.de>
	<7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com>
Message-ID: <AANLkTimupTnL5_wyQCzv-QdUm5Osrl6hnClfuzo97AeA@mail.gmail.com>

Bah, indeed you did.

Well, I can answer that now :)

The level of sandboxing is the level on which RPython operates - it
does not necesarilly relate 1:1 to os module functions. You would need
to look at implementation of os.listdir which C functions it calls. If
you enable debug (is it on by default?) it'll give you what functions
are called with what parameters. Also a pdb would help there. I can
look at those errors precisely if you want me to.

2010/6/28 S?ren Laursen <sl at scrooge.dk>:
> -----Oprindelig meddelelse-----
> Fra: pypy-dev-bounces at codespeak.net
> [mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
> Sendt: 28. juni 2010 17:57
> Til: Maciej Fijalkowski
> Cc: PyPy Dev
> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>
> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
> wrote:
>>> Hi all,
>>>
>>> just wanted to point this Master thesis using PyPy out:
>>>
>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>
>>> Didn't know about this, but interesting anyway.
>>>
>>> Cheers,
>>>
>>> Carl Friedrich
>>
>> According to the abstract it was a poor choice :)
>
>>So it says. He never wrote anything on the mailing list though, I assume
>>he showed up on IRC?
>
> I did wrote on the mailinglist:
> http://permalink.gmane.org/gmane.comp.python.pypy/5987
>
> This error was a show stopper, and some other strange errors using the
> pickle module.
>
> Regards,
>
> S?ren
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From maloneymr at gmail.com  Mon Jun 28 19:59:00 2010
From: maloneymr at gmail.com (Michael Maloney)
Date: Mon, 28 Jun 2010 12:59:00 -0500
Subject: [pypy-dev] Unsubscribe
Message-ID: <AANLkTilRIhaffIuK2AITl2JariS4EvioTRGraG6yW_dx@mail.gmail.com>

On Mon, Jun 28, 2010 at 12:51 PM,  <pypy-dev-request at codespeak.net> wrote:
> Send pypy-dev mailing list submissions to
> ? ? ? ?pypy-dev at codespeak.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> ? ? ? ?http://codespeak.net/mailman/listinfo/pypy-dev
> or, via email, send a message with subject or body 'help' to
> ? ? ? ?pypy-dev-request at codespeak.net
>
> You can reach the person managing the list at
> ? ? ? ?pypy-dev-owner at codespeak.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pypy-dev digest..."
>
>
> Today's Topics:
>
> ? 1. PyPy 1.3 released (Maciej Fijalkowski)
> ? 2. Re: New speed.pypy.org version (Miquel Torres)
> ? 3. Re: PyPy 1.3 released (Armin Rigo)
> ? 4. PyPy Master thesis sandboxing (Carl Friedrich Bolz)
> ? 5. Re: PyPy Master thesis sandboxing (Maciej Fijalkowski)
> ? 6. Re: PyPy Master thesis sandboxing (Carl Friedrich Bolz)
> ? 7. Re: PyPy Master thesis sandboxing (Maciej Fijalkowski)
> ? 8. Re: PyPy Master thesis sandboxing (S?ren Laursen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 25 Jun 2010 17:27:52 -0600
> From: Maciej Fijalkowski <fijall at gmail.com>
> Subject: [pypy-dev] PyPy 1.3 released
> To: PyPy Dev <pypy-dev at codespeak.net>, ?"<python-dev at python.org>"
> ? ? ? ?<python-dev at python.org>, ? ? ? ?python-announce at python.org
> Message-ID:
> ? ? ? ?<AANLkTikaN3p6BNFUfXL4RlWB28ZwjrajeUb34r8SGvdy at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> =======================
> PyPy 1.3: Stabilization
> =======================
>
> Hello.
>
> We're please to announce release of PyPy 1.3. This release has two major
> improvements. First of all, we stabilized the JIT compiler since 1.2 release,
> answered user issues, fixed bugs, and generally improved speed.
>
> We're also pleased to announce alpha support for loading CPython extension
> modules written in C. While the main purpose of this release is increased
> stability, this feature is in alpha stage and it is not yet suited for
> production environments.
>
> Highlights of this release
> ==========================
>
> * We introduced support for CPython extension modules written in C. As of now,
> ?this support is in alpha, and it's very unlikely unaltered C extensions will
> ?work out of the box, due to missing functions or refcounting details. The
> ?support is disable by default, so you have to do::
>
> ? import cpyext
>
> ?before trying to import any .so file. Also, libraries are source-compatible
> ?and not binary-compatible. That means you need to recompile binaries, using
> ?for example::
>
> ? python setup.py build
>
> ?Details may vary, depending on your build system. Make sure you include
> ?the above line at the beginning of setup.py or put it in your PYTHONSTARTUP.
>
> ?This is alpha feature. It'll likely segfault. You have been warned!
>
> * JIT bugfixes. A lot of bugs reported for the JIT have been fixed, and its
> ?stability greatly improved since 1.2 release.
>
> * Various small improvements have been added to the JIT code, as well as a great
> ?speedup of compiling time.
>
> Cheers,
> Maciej Fijalkowski, Armin Rigo, Alex Gaynor, Amaury Forgeot d'Arc and
> the PyPy team
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 26 Jun 2010 09:16:52 +0200
> From: Miquel Torres <tobami at googlemail.com>
> Subject: Re: [pypy-dev] New speed.pypy.org version
> To: Paolo Giarrusso <p.giarrusso at gmail.com>
> Cc: pypy-dev <pypy-dev at codespeak.net>
> Message-ID:
> ? ? ? ?<AANLkTilgNm7a3o9pSUDgbHwxJ2bNqsYNajUK21JnFBT7 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Paolo,
>
> well, you are right of course. I had forgotten about the real problem, which
> you actually demonstrate quite well with your CPython and pypy-c case:
> depending on the normalization you can make any stacked series look faster
> than the others.
>
> I will have a look at the literature and modify normalized stacked plots
> accordingly.
>
> Thanks for taking the time to explain things in such detail.
>
> Regards,
> Miquel
>
>
> 2010/6/25 Paolo Giarrusso <p.giarrusso at gmail.com>
>
>> On Fri, Jun 25, 2010 at 19:08, Miquel Torres <tobami at googlemail.com>
>> wrote:
>> > Hi Paolo,
>> >
>> > I am aware of the problem with calculating benchmark means, but let me
>> > explain my point of view.
>> >
>> > You are correct in that it would be preferable to have absolute times.
>> Well,
>> > you actually can, but see what it happens:
>> > http://speed.pypy.org/comparison/?hor=true&bas=none&chart=stacked+bars
>>
>> Ahah! I didn't notice that I could skip normalization! This does not
>> fully invalidate my point, however.
>>
>> > Absolute values would only work if we had carefully chosen benchmaks
>> > runtimes to be very similar (for our cpython baseline). As it is,
>> html5lib,
>> > spitfire and spitfire_cstringio completely dominate the cummulative time.
>>
>> I acknowledge that (btw, it should be cumulative time, with one 'm',
>> both here and in the website).
>>
>> > And not because the interpreter is faster or slower but because the
>> > benchmark was arbitrarily designed to run that long. Any improvement in
>> the
>> > long running benchmarks will carry much more weight than in the short
>> > running.
>>
>> > What is more useful is to have comparable slices of time so that the
>> > improvements can be seen relatively over time.
>>
>> If you want to sum up times (but at this point, I see no reason for
>> it), you should rather have externally derived weights, as suggested
>> by the paper (in Rule 3).
>> As soon as you take weights from the data, lots of maths that you need
>> is not going to work any more - that's generally true in many cases in
>> statistics.
>> And the only way making sense to have external weights is to gather
>> them from real world programs. Since that's not going to happen
>> easily, just stick with the geometric mean. Or set an arbitrarily low
>> weight, manually, without any math, so that the long-running
>> benchmarks stop dominating the res. It's no fraud, since the current
>> graph is less valid anyway.
>>
>> > Normalizing does that i
>> > think.
>> Not really.
>>
>> > It just says: we have 21 tasks which take 1 second to run each on
>> > interpreter X (cpython in the default case). Then we see how other
>> > executables compare to that. What would the geometric mean achieve here,
>> > exactly, for the end user?
>>
>> You actually need the geomean to do that. Don't forget that the
>> geomean is still a mean: it's a mean performance ratio which averages
>> individual performance ratios.
>> If PyPy's geomean is 0.5, it means that PyPy is going to run that task
>> in 11.5 seconds instead of 21. To me, this sounds exactly like what
>> you want to achieve. Moreover, it actually works, unlike what you use.
>>
>> For instance, ignore PyPy-JIT, and look only CPython and pypy-c (no
>> JIT). Then, change the normalization among the two:
>>
>> http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=2%2B35&chart=stacked+bars
>>
>> http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=3%2BL&chart=stacked+bars
>> with the current data, you get that in one case cpython is faster, in
>> the other pypy-c is faster.
>> It can't happen with the geomean. This is the point of the paper.
>>
>> I could even construct a normalization baseline $base such that
>> CPython seems faster than PyPy-JIT. Such a base should be very fast
>> on, say, ai (where CPython is slower), so that $cpython.ai/$base.ai
>> becomes 100 and $pypyjit.ai/$base.ai becomes 200, and be very slow on
>> other benchmarks (so that they disappear in the sum).
>>
>> So, the only difference I see is that geomean works, arithm. mean
>> doesn't. That's why Real Benchmarkers use geomean.
>>
>> Moreover, you are making a mistake quite common among non-physicists.
>> What you say makes sense under the implicit assumption that dividing
>> two times gives something you can use as a time. When you say "Pypy's
>> runtime for a 1 second task", you actually want to talk about a
>> performance ratio, not about the time. In the same way as when you say
>> "this bird runs 3 meters long in one second", a physicist would sum
>> that up as "3 m/s" rather than "3 m".
>>
>> > I am not really calculating any mean. You can see that I carefully
>> avoided
>> > to display any kind of total bar which would indeed incur in the problem
>> you
>> > mention. That a stacked chart implicitly displays a total is something
>> you
>> > can not avoid, and for that kind of chart I still think normalized
>> results
>> > is visually the best option.
>>
>> But on a stacked bars graph, I'm not going to look at individual bars
>> at all, just at the total: it's actually less convenient than in
>> "normal bars" to look at the result of a particular benchmark.
>>
>> I hope I can find guidelines against stacked plots, I have a PhD
>> colleague reading on how to make graphs.
>>
>> Best regards
>> --
>> Paolo Giarrusso - Ph.D. Student
>> http://www.informatik.uni-marburg.de/~pgiarrusso/<http://www.informatik.uni-marburg.de/%7Epgiarrusso/>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100626/e7965f36/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Sat, 26 Jun 2010 10:34:57 +0200
> From: Armin Rigo <arigo at tunes.org>
> Subject: Re: [pypy-dev] PyPy 1.3 released
> To: Maciej Fijalkowski <fijall at gmail.com>
> Cc: python-announce at python.org, PyPy Dev <pypy-dev at codespeak.net>,
> ? ? ? ?"<python-dev at python.org>" <python-dev at python.org>
> Message-ID: <20100626083457.GA14816 at code0.codespeak.net>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> On Fri, Jun 25, 2010 at 05:27:52PM -0600, Maciej Fijalkowski wrote:
>> ? ?python setup.py build
>
> As corrected on the blog (http://morepypy.blogspot.com/), this line
> should read:
>
> ? ? pypy setup.py build
>
>
> Armin.
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 28 Jun 2010 15:08:08 +0200
> From: Carl Friedrich Bolz <cfbolz at gmx.de>
> Subject: [pypy-dev] PyPy Master thesis sandboxing
> To: PyPy Dev <pypy-dev at codespeak.net>
> Message-ID: <4C289EB8.4090702 at gmx.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi all,
>
> just wanted to point this Master thesis using PyPy out:
>
> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>
> Didn't know about this, but interesting anyway.
>
> Cheers,
>
> Carl Friedrich
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 28 Jun 2010 09:51:37 -0600
> From: Maciej Fijalkowski <fijall at gmail.com>
> Subject: Re: [pypy-dev] PyPy Master thesis sandboxing
> To: Carl Friedrich Bolz <cfbolz at gmx.de>
> Cc: PyPy Dev <pypy-dev at codespeak.net>
> Message-ID:
> ? ? ? ?<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> Hi all,
>>
>> just wanted to point this Master thesis using PyPy out:
>>
>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>
>> Didn't know about this, but interesting anyway.
>>
>> Cheers,
>>
>> Carl Friedrich
>
> According to the abstract it was a poor choice :)
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 28 Jun 2010 17:56:55 +0200
> From: Carl Friedrich Bolz <cfbolz at gmx.de>
> Subject: Re: [pypy-dev] PyPy Master thesis sandboxing
> To: Maciej Fijalkowski <fijall at gmail.com>
> Cc: PyPy Dev <pypy-dev at codespeak.net>
> Message-ID: <4C28C647.2000008 at gmx.de>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de> ?wrote:
>>> Hi all,
>>>
>>> just wanted to point this Master thesis using PyPy out:
>>>
>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>
>>> Didn't know about this, but interesting anyway.
>>>
>>> Cheers,
>>>
>>> Carl Friedrich
>>
>> According to the abstract it was a poor choice :)
>
> So it says. He never wrote anything on the mailing list though, I assume
> he showed up on IRC?
>
> Cheers,
>
> Carl Friedrich
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 28 Jun 2010 10:00:45 -0600
> From: Maciej Fijalkowski <fijall at gmail.com>
> Subject: Re: [pypy-dev] PyPy Master thesis sandboxing
> To: Carl Friedrich Bolz <cfbolz at gmx.de>
> Cc: PyPy Dev <pypy-dev at codespeak.net>
> Message-ID:
> ? ? ? ?<AANLkTikb2hdzl4-_CU3QbvQ3VvLRh8plVvBnWaLRm4OL at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jun 28, 2010 at 9:56 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>>>
>>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
>>> ?wrote:
>>>>
>>>> Hi all,
>>>>
>>>> just wanted to point this Master thesis using PyPy out:
>>>>
>>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>>
>>>> Didn't know about this, but interesting anyway.
>>>>
>>>> Cheers,
>>>>
>>>> Carl Friedrich
>>>
>>> According to the abstract it was a poor choice :)
>>
>> So it says. He never wrote anything on the mailing list though, I assume he
>> showed up on IRC?
>>
>> Cheers,
>>
>> Carl Friedrich
>>
>
> I don't honestly remember anyone showing up and speaking about that,
> but well. Anyone?
>
> Cheers,
> fijal
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 28 Jun 2010 19:50:57 +0200
> From: S?ren Laursen <sl at scrooge.dk>
> Subject: Re: [pypy-dev] PyPy Master thesis sandboxing
> To: pypy-dev at codespeak.net
> Message-ID: <7e69406314220d0a6655e8a6f2fe70b4 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----Oprindelig meddelelse-----
> Fra: pypy-dev-bounces at codespeak.net
> [mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
> Sendt: 28. juni 2010 17:57
> Til: Maciej Fijalkowski
> Cc: PyPy Dev
> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>
> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
> wrote:
>>> Hi all,
>>>
>>> just wanted to point this Master thesis using PyPy out:
>>>
>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>
>>> Didn't know about this, but interesting anyway.
>>>
>>> Cheers,
>>>
>>> Carl Friedrich
>>
>> According to the abstract it was a poor choice :)
>
>>So it says. He never wrote anything on the mailing list though, I assume
>>he showed up on IRC?
>
> I did wrote on the mailinglist:
> http://permalink.gmane.org/gmane.comp.python.pypy/5987
>
> This error was a show stopper, and some other strange errors using the
> pickle module.
>
> Regards,
>
> S?ren
>
>
> ------------------------------
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
>
> End of pypy-dev Digest, Vol 359, Issue 7
> ****************************************
>

From sl at scrooge.dk  Mon Jun 28 20:01:45 2010
From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=)
Date: Mon, 28 Jun 2010 20:01:45 +0200
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <AANLkTimupTnL5_wyQCzv-QdUm5Osrl6hnClfuzo97AeA@mail.gmail.com>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com> 
	<4C28C647.2000008@gmx.de>
	<7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com> 
	<AANLkTimupTnL5_wyQCzv-QdUm5Osrl6hnClfuzo97AeA@mail.gmail.com>
Message-ID: <afa6f13c3bc44f2aea85b7a38109a38d@mail.gmail.com>

Thanks,

The project is not stoppede, but the thesis had to be handed in.

Regards,

s?ren

-----Oprindelig meddelelse-----
Fra: Maciej Fijalkowski [mailto:fijall at gmail.com]
Sendt: 28. juni 2010 19:59
Til: S?ren Laursen
Cc: pypy-dev at codespeak.net
Emne: Re: [pypy-dev] PyPy Master thesis sandboxing

Bah, indeed you did.

Well, I can answer that now :)

The level of sandboxing is the level on which RPython operates - it
does not necesarilly relate 1:1 to os module functions. You would need
to look at implementation of os.listdir which C functions it calls. If
you enable debug (is it on by default?) it'll give you what functions
are called with what parameters. Also a pdb would help there. I can
look at those errors precisely if you want me to.

2010/6/28 S?ren Laursen <sl at scrooge.dk>:
> -----Oprindelig meddelelse-----
> Fra: pypy-dev-bounces at codespeak.net
> [mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
> Sendt: 28. juni 2010 17:57
> Til: Maciej Fijalkowski
> Cc: PyPy Dev
> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>
> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
> wrote:
>>> Hi all,
>>>
>>> just wanted to point this Master thesis using PyPy out:
>>>
>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>
>>> Didn't know about this, but interesting anyway.
>>>
>>> Cheers,
>>>
>>> Carl Friedrich
>>
>> According to the abstract it was a poor choice :)
>
>>So it says. He never wrote anything on the mailing list though, I assume
>>he showed up on IRC?
>
> I did wrote on the mailinglist:
> http://permalink.gmane.org/gmane.comp.python.pypy/5987
>
> This error was a show stopper, and some other strange errors using the
> pickle module.
>
> Regards,
>
> S?ren
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Mon Jun 28 20:03:22 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 28 Jun 2010 12:03:22 -0600
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <afa6f13c3bc44f2aea85b7a38109a38d@mail.gmail.com>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com> 
	<4C28C647.2000008@gmx.de>
	<7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com> 
	<AANLkTimupTnL5_wyQCzv-QdUm5Osrl6hnClfuzo97AeA@mail.gmail.com> 
	<afa6f13c3bc44f2aea85b7a38109a38d@mail.gmail.com>
Message-ID: <AANLkTim2-i-KjKdB6upSggNwTzU1cRiOqKttaikWKAuV@mail.gmail.com>

Does it mean "yes" or "no"? :-)

2010/6/28 S?ren Laursen <sl at scrooge.dk>:
> Thanks,
>
> The project is not stoppede, but the thesis had to be handed in.
>
> Regards,
>
> s?ren
>
> -----Oprindelig meddelelse-----
> Fra: Maciej Fijalkowski [mailto:fijall at gmail.com]
> Sendt: 28. juni 2010 19:59
> Til: S?ren Laursen
> Cc: pypy-dev at codespeak.net
> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>
> Bah, indeed you did.
>
> Well, I can answer that now :)
>
> The level of sandboxing is the level on which RPython operates - it
> does not necesarilly relate 1:1 to os module functions. You would need
> to look at implementation of os.listdir which C functions it calls. If
> you enable debug (is it on by default?) it'll give you what functions
> are called with what parameters. Also a pdb would help there. I can
> look at those errors precisely if you want me to.
>
> 2010/6/28 S?ren Laursen <sl at scrooge.dk>:
>> -----Oprindelig meddelelse-----
>> Fra: pypy-dev-bounces at codespeak.net
>> [mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
>> Sendt: 28. juni 2010 17:57
>> Til: Maciej Fijalkowski
>> Cc: PyPy Dev
>> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>>
>> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
>> wrote:
>>>> Hi all,
>>>>
>>>> just wanted to point this Master thesis using PyPy out:
>>>>
>>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>>
>>>> Didn't know about this, but interesting anyway.
>>>>
>>>> Cheers,
>>>>
>>>> Carl Friedrich
>>>
>>> According to the abstract it was a poor choice :)
>>
>>>So it says. He never wrote anything on the mailing list though, I assume
>>>he showed up on IRC?
>>
>> I did wrote on the mailinglist:
>> http://permalink.gmane.org/gmane.comp.python.pypy/5987
>>
>> This error was a show stopper, and some other strange errors using the
>> pickle module.
>>
>> Regards,
>>
>> S?ren
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From sl at scrooge.dk  Mon Jun 28 20:08:50 2010
From: sl at scrooge.dk (=?ISO-8859-1?Q?S=F8ren_Laursen?=)
Date: Mon, 28 Jun 2010 20:08:50 +0200
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <AANLkTim2-i-KjKdB6upSggNwTzU1cRiOqKttaikWKAuV@mail.gmail.com>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com> 
	<4C28C647.2000008@gmx.de>
	<7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com> 
	<AANLkTimupTnL5_wyQCzv-QdUm5Osrl6hnClfuzo97AeA@mail.gmail.com> 	
	<afa6f13c3bc44f2aea85b7a38109a38d@mail.gmail.com>
	<AANLkTim2-i-KjKdB6upSggNwTzU1cRiOqKttaikWKAuV@mail.gmail.com>
Message-ID: <66fb452a52c4f0d736a63b961557676b@mail.gmail.com>

Yes! :-)

I would like some help.

Regards,

S?ren


-----Oprindelig meddelelse-----
Fra: Maciej Fijalkowski [mailto:fijall at gmail.com]
Sendt: 28. juni 2010 20:03
Til: S?ren Laursen
Cc: pypy-dev at codespeak.net
Emne: Re: [pypy-dev] PyPy Master thesis sandboxing

Does it mean "yes" or "no"? :-)

2010/6/28 S?ren Laursen <sl at scrooge.dk>:
> Thanks,
>
> The project is not stoppede, but the thesis had to be handed in.
>
> Regards,
>
> s?ren
>
> -----Oprindelig meddelelse-----
> Fra: Maciej Fijalkowski [mailto:fijall at gmail.com]
> Sendt: 28. juni 2010 19:59
> Til: S?ren Laursen
> Cc: pypy-dev at codespeak.net
> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>
> Bah, indeed you did.
>
> Well, I can answer that now :)
>
> The level of sandboxing is the level on which RPython operates - it
> does not necesarilly relate 1:1 to os module functions. You would need
> to look at implementation of os.listdir which C functions it calls. If
> you enable debug (is it on by default?) it'll give you what functions
> are called with what parameters. Also a pdb would help there. I can
> look at those errors precisely if you want me to.
>
> 2010/6/28 S?ren Laursen <sl at scrooge.dk>:
>> -----Oprindelig meddelelse-----
>> Fra: pypy-dev-bounces at codespeak.net
>> [mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
>> Sendt: 28. juni 2010 17:57
>> Til: Maciej Fijalkowski
>> Cc: PyPy Dev
>> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>>
>> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
>> wrote:
>>>> Hi all,
>>>>
>>>> just wanted to point this Master thesis using PyPy out:
>>>>
>>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>>
>>>> Didn't know about this, but interesting anyway.
>>>>
>>>> Cheers,
>>>>
>>>> Carl Friedrich
>>>
>>> According to the abstract it was a poor choice :)
>>
>>>So it says. He never wrote anything on the mailing list though, I assume
>>>he showed up on IRC?
>>
>> I did wrote on the mailinglist:
>> http://permalink.gmane.org/gmane.comp.python.pypy/5987
>>
>> This error was a show stopper, and some other strange errors using the
>> pickle module.
>>
>> Regards,
>>
>> S?ren
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Mon Jun 28 20:37:58 2010
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 28 Jun 2010 12:37:58 -0600
Subject: [pypy-dev] PyPy Master thesis sandboxing
In-Reply-To: <66fb452a52c4f0d736a63b961557676b@mail.gmail.com>
References: <4C289EB8.4090702@gmx.de>
	<AANLkTil7nCBB6gf1l3MacpSXhTs2YiRdiBZiWNienuun@mail.gmail.com> 
	<4C28C647.2000008@gmx.de>
	<7e69406314220d0a6655e8a6f2fe70b4@mail.gmail.com> 
	<AANLkTimupTnL5_wyQCzv-QdUm5Osrl6hnClfuzo97AeA@mail.gmail.com> 
	<afa6f13c3bc44f2aea85b7a38109a38d@mail.gmail.com>
	<AANLkTim2-i-KjKdB6upSggNwTzU1cRiOqKttaikWKAuV@mail.gmail.com> 
	<66fb452a52c4f0d736a63b961557676b@mail.gmail.com>
Message-ID: <AANLkTikYgl2Rvgf06FyiZEl4WbjpTxdpnfDPe7_tY5yy@mail.gmail.com>

Cool, will look at it as soon as I can (still will take a bit, moving around).

2010/6/28 S?ren Laursen <sl at scrooge.dk>:
> Yes! :-)
>
> I would like some help.
>
> Regards,
>
> S?ren
>
>
> -----Oprindelig meddelelse-----
> Fra: Maciej Fijalkowski [mailto:fijall at gmail.com]
> Sendt: 28. juni 2010 20:03
> Til: S?ren Laursen
> Cc: pypy-dev at codespeak.net
> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>
> Does it mean "yes" or "no"? :-)
>
> 2010/6/28 S?ren Laursen <sl at scrooge.dk>:
>> Thanks,
>>
>> The project is not stoppede, but the thesis had to be handed in.
>>
>> Regards,
>>
>> s?ren
>>
>> -----Oprindelig meddelelse-----
>> Fra: Maciej Fijalkowski [mailto:fijall at gmail.com]
>> Sendt: 28. juni 2010 19:59
>> Til: S?ren Laursen
>> Cc: pypy-dev at codespeak.net
>> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>>
>> Bah, indeed you did.
>>
>> Well, I can answer that now :)
>>
>> The level of sandboxing is the level on which RPython operates - it
>> does not necesarilly relate 1:1 to os module functions. You would need
>> to look at implementation of os.listdir which C functions it calls. If
>> you enable debug (is it on by default?) it'll give you what functions
>> are called with what parameters. Also a pdb would help there. I can
>> look at those errors precisely if you want me to.
>>
>> 2010/6/28 S?ren Laursen <sl at scrooge.dk>:
>>> -----Oprindelig meddelelse-----
>>> Fra: pypy-dev-bounces at codespeak.net
>>> [mailto:pypy-dev-bounces at codespeak.net] P? vegne af Carl Friedrich Bolz
>>> Sendt: 28. juni 2010 17:57
>>> Til: Maciej Fijalkowski
>>> Cc: PyPy Dev
>>> Emne: Re: [pypy-dev] PyPy Master thesis sandboxing
>>>
>>> On 06/28/2010 05:51 PM, Maciej Fijalkowski wrote:
>>>> On Mon, Jun 28, 2010 at 7:08 AM, Carl Friedrich Bolz<cfbolz at gmx.de>
>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> just wanted to point this Master thesis using PyPy out:
>>>>>
>>>>> http://www.diku.dk/english/Calendar/masters_defence_soeren/
>>>>>
>>>>> Didn't know about this, but interesting anyway.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Carl Friedrich
>>>>
>>>> According to the abstract it was a poor choice :)
>>>
>>>>So it says. He never wrote anything on the mailing list though, I assume
>>>>he showed up on IRC?
>>>
>>> I did wrote on the mailinglist:
>>> http://permalink.gmane.org/gmane.comp.python.pypy/5987
>>>
>>> This error was a show stopper, and some other strange errors using the
>>> pickle module.
>>>
>>> Regards,
>>>
>>> S?ren
>>> _______________________________________________
>>> pypy-dev at codespeak.net
>>> http://codespeak.net/mailman/listinfo/pypy-dev
>>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
>
>
>

From phyo.arkarlwin at gmail.com  Tue Jun 29 02:55:40 2010
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Tue, 29 Jun 2010 00:55:40 +0000
Subject: [pypy-dev] Is MySQLdb Working?
Message-ID: <AANLkTinCAEQZr8RRjCdB5k9lJOcz4C8poFHLl-rBW4vz@mail.gmail.com>

Hello Pypy team.

Thank you for the Greatest project every happen  to Programming World.

I am trying to run web2py  - http://www.web2py.com on pypy , everything
working fine except MySQLdb , which i installed over easy_install .

>>>> import MySQLdb
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ZipImportError: No module named pkg_resources


I saw the patch for mysqldb in the trunk , so i have to apply it on mysqldb
?  Which version for it ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100629/473dae83/attachment.htm 

From glavoie at gmail.com  Tue Jun 29 21:09:40 2010
From: glavoie at gmail.com (Gabriel Lavoie)
Date: Tue, 29 Jun 2010 15:09:40 -0400
Subject: [pypy-dev] Improving Stackless/Coroutines implementation
Message-ID: <AANLkTinATaawid8209DXb_6SlMd3gaCUahvikBiC3dzS@mail.gmail.com>

Hello everyone,
     as a few knows here, I'm working heavily with PyPy's "stackless" module
for my Master degree project to make it more distributed. Since I started to
work full time on this project I've encountered a few bugs (mostly related
to pickling of tasklets) and missing implementation details in the module.
The latest problem I've encountered is to be able to detect when
tasklet.kill() is called, within the tasklet being killed. With Stackless
CPython, TaskletExit is raised and can be caught but this part wasn't really
implemented in PyPy's stackless module. Since the module is implemented on
top of coroutines and since coroutine.kill() is called within
tasklet.kill(), the exception thrown by the coroutine implementation needs
to be caught. Here's the problem:

http://codespeak.net/pypy/dist/pypy/doc/stackless.html#coroutines

   -

   coro.kill()

   Kill coro by sending an exception to it. (At the moment, the exception is
   not visible to app-level, which means that you cannot catch it, and that
   try: finally: clauses are not honored. This will be fixed in the future.)


The exception is not thrown at app level and a coroutine dies silently. Took
a look at the code and I've been able to expose a CoroutineExit exception to
app level on which I intend implementing TaskletExit correctly. I'm also
able to catch the exception as expected but the code is not yet complete.

Right now, I have a question on how to expose correctly the CoroutineExit
and TaskletExit exceptions to app level. Here's what I did:

W_CoroutineExit = _new_exception('CoroutineExit', W_Exception, 'Exit
requested...')

class AppCoroutine(Coroutine): # XXX, StacklessFlags):

    def __init__(self, space, state=None):
        # Some other code here

        # Exporting new exception to __builtins__ and "exceptions" modules
        self.w_CoroutineExit = space.gettypefor(W_CoroutineExit)
        space.setitem(
                      space.exceptions_module.w_dict,
                      space.new_interned_str('CoroutineExit'),
                      self.w_CoroutineExit)
        space.setitem(space.builtin.w_dict,
                      space.new_interned_str('CoroutineExit'),
                      self.w_CoroutineExit)

I talked about this on #pypy (IRC) but people weren't sure about exporting
new names to __builtins__. On my side I wanted to make it look as most as
possible as how Stackless CPython did it with TaskletExit, which is directly
available in __builtins__. This would make code compatible with both
Stackless Python and PyPy's stackless module. Also, exporting names this way
would only make them appear in __builtins__ when the "_stackless" module is
enabled (pypy-c built with --stackless).

What are your opinions about it? (Maciej, I already know about yours! ;)

Thank you very much,

Gabriel (WildChild)

-- 
Gabriel Lavoie
glavoie at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100629/846b5dff/attachment.htm 

From p.giarrusso at gmail.com  Wed Jun 30 10:11:33 2010
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Wed, 30 Jun 2010 10:11:33 +0200
Subject: [pypy-dev] New speed.pypy.org version
In-Reply-To: <AANLkTikHEBQPPwGd4EeT4CziGOwA01CUOg6t2_I2RWui@mail.gmail.com>
References: <AANLkTilOe6sZZo21eBuaMLUZjOeXRqd36HJkyjeGx3i3@mail.gmail.com> 
	<AANLkTikHi12NX7NErE2R4p8qHnZWolI6c3O8Uhc1kklP@mail.gmail.com> 
	<AANLkTinQrHMlLILHkEZzJWflcKCA2MHS3AcKuwAZ8wfc@mail.gmail.com> 
	<AANLkTinqbrpWH-_pujnDtBarHHfDK7kl-oQY95BwW2LC@mail.gmail.com> 
	<AANLkTikHEBQPPwGd4EeT4CziGOwA01CUOg6t2_I2RWui@mail.gmail.com>
Message-ID: <AANLkTikY8mceWGE5FjOGJTJuYRfGC-wisKWPaYlbYDJJ@mail.gmail.com>

Hi Miquel,
I'm quite busy (because of a paper deadline next Tuesday), sorry for
not answering earlier.

I was just struck by an idea: there is a stacked bar plot where the
total bar is related to the geometric mean, such that it is
normalization-invariant. But this graph _is_ complicated.

It is a stacked plot of _logarithms_ of performance ratios? This way,
the complete stacked bar shows the logarithm of the product, rather
than their sum, i.e. the log of the (geometric mean)^N rather than
their arithmetic mean. log of the (geometric mean)^N = N*log of the
(geometric mean).

Some simple maths (I didn't write it out, so please recheck!) seems to
show that showing (a+b*log (ratio)), instead of log(ratio), gives
still a fair comparison, obtaining N*a+b*N*log(geomean) =
\Theta(log(geomean)). You need to put a and b because showing if the
ratio is 1, log(1) is zero (b is the representation scale which is
always there).

About your workaround: I would like a table with the geometric mean of
the ratios, where we get the real global performance ratio among the
interpreters. As far as the results of your solution do not contradict
that _real_ table, it should be a reasonable workaround (but I would
embed the check in the code - otherwise other projects _will be_
bitten by that). Probably, I would like the website to offer such a
table to users, and I would like a graph of the overall performance
ratio over time (actually revisions).

Finally, the docs of your web application should at the very least
reference the paper and this conversation (if there's a public archive
of the ML, as I think), and ideally explain the issue.

Sorry for being too dense, maybe - if I was unclear, please tell me
and I'll answer next week.

Best regards,
Paolo

On Mon, Jun 28, 2010 at 11:21, Miquel Torres <tobami at googlemail.com> wrote:
> Hi Paolo,
>
> I read the paper, very interesting. It is perfectly clear that to
> calculate a normalized total only the geometric mean makes sense.
>
> However, a stacked bars plot shows the individual benchmarks so it
> implicitly is an arithmetic mean. The only solution (apart from
> removing the stacked charts and only offering total bars) is the
> weighted approach.
>
> External weights are not very practical though. Codespeed is used by
> other projects so an extra option would need to be added to the
> settings to allow the introducing of arbitrary weights to benchmarks.
> A bit cumbersome. I have an idea that may work. Take the weights from
> a defined baseline so that the run times are equal, which is the same
> as normalizing to a baseline. It would be the same as now, only that
> you can't choose the normalization, it will be weighted (normalized)
> according the default baseline (which you already can already
> configure in the settings).
>
> You may say that it is still an arithmetic mean, but there won't be
> conflicting results because there is only a single normalization. For
> PyPy that would be cpython, and everything would make sense.
> I know it is a work around, not a solution. If you think it is a bad
> idea, the only other possibility is not to have stacked bars (as in
> "showing individual benchmarks"). But I find them useful. Yes you can
> see the individual benchmark results better in the normal bars chart,
> but there you don't see visually which benchmarks take the biggest
> part of the pie, which helps visualize what parts of your program need
> most improving.
>
> What do you think?
>
> Regards,
> Miquel
>
>
> 2010/6/25 Paolo Giarrusso <p.giarrusso at gmail.com>:
>> On Fri, Jun 25, 2010 at 19:08, Miquel Torres <tobami at googlemail.com> wrote:
>>> Hi Paolo,
>>>
>>> I am aware of the problem with calculating benchmark means, but let me
>>> explain my point of view.
>>>
>>> You are correct in that it would be preferable to have absolute times. Well,
>>> you actually can, but see what it happens:
>>> http://speed.pypy.org/comparison/?hor=true&bas=none&chart=stacked+bars
>>
>> Ahah! I didn't notice that I could skip normalization! This does not
>> fully invalidate my point, however.
>>
>>> Absolute values would only work if we had carefully chosen benchmaks
>>> runtimes to be very similar (for our cpython baseline). As it is, html5lib,
>>> spitfire and spitfire_cstringio completely dominate the cummulative time.
>>
>> I acknowledge that (btw, it should be cumulative time, with one 'm',
>> both here and in the website).
>>
>>> And not because the interpreter is faster or slower but because the
>>> benchmark was arbitrarily designed to run that long. Any improvement in the
>>> long running benchmarks will carry much more weight than in the short
>>> running.
>>
>>> What is more useful is to have comparable slices of time so that the
>>> improvements can be seen relatively over time.
>>
>> If you want to sum up times (but at this point, I see no reason for
>> it), you should rather have externally derived weights, as suggested
>> by the paper (in Rule 3).
>> As soon as you take weights from the data, lots of maths that you need
>> is not going to work any more - that's generally true in many cases in
>> statistics.
>> And the only way making sense to have external weights is to gather
>> them from real world programs. Since that's not going to happen
>> easily, just stick with the geometric mean. Or set an arbitrarily low
>> weight, manually, without any math, so that the long-running
>> benchmarks stop dominating the res. It's no fraud, since the current
>> graph is less valid anyway.
>>
>>> Normalizing does that i
>>> think.
>> Not really.
>>
>>> It just says: we have 21 tasks which take 1 second to run each on
>>> interpreter X (cpython in the default case). Then we see how other
>>> executables compare to that. What would the geometric mean achieve here,
>>> exactly, for the end user?
>>
>> You actually need the geomean to do that. Don't forget that the
>> geomean is still a mean: it's a mean performance ratio which averages
>> individual performance ratios.
>> If PyPy's geomean is 0.5, it means that PyPy is going to run that task
>> in 11.5 seconds instead of 21. To me, this sounds exactly like what
>> you want to achieve. Moreover, it actually works, unlike what you use.
>>
>> For instance, ignore PyPy-JIT, and look only CPython and pypy-c (no
>> JIT). Then, change the normalization among the two:
>> http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=2%2B35&chart=stacked+bars
>> http://speed.pypy.org/comparison/?exe=2%2B35,3%2BL&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21&env=1&hor=true&bas=3%2BL&chart=stacked+bars
>> with the current data, you get that in one case cpython is faster, in
>> the other pypy-c is faster.
>> It can't happen with the geomean. This is the point of the paper.
>>
>> I could even construct a normalization baseline $base such that
>> CPython seems faster than PyPy-JIT. Such a base should be very fast
>> on, say, ai (where CPython is slower), so that $cpython.ai/$base.ai
>> becomes 100 and $pypyjit.ai/$base.ai becomes 200, and be very slow on
>> other benchmarks (so that they disappear in the sum).
>>
>> So, the only difference I see is that geomean works, arithm. mean
>> doesn't. That's why Real Benchmarkers use geomean.
>>
>> Moreover, you are making a mistake quite common among non-physicists.
>> What you say makes sense under the implicit assumption that dividing
>> two times gives something you can use as a time. When you say "Pypy's
>> runtime for a 1 second task", you actually want to talk about a
>> performance ratio, not about the time. In the same way as when you say
>> "this bird runs 3 meters long in one second", a physicist would sum
>> that up as "3 m/s" rather than "3 m".
>>
>>> I am not really calculating any mean. You can see that I carefully avoided
>>> to display any kind of total bar which would indeed incur in the problem you
>>> mention. That a stacked chart implicitly displays a total is something you
>>> can not avoid, and for that kind of chart I still think normalized results
>>> is visually the best option.
>>
>> But on a stacked bars graph, I'm not going to look at individual bars
>> at all, just at the total: it's actually less convenient than in
>> "normal bars" to look at the result of a particular benchmark.
>>
>> I hope I can find guidelines against stacked plots, I have a PhD
>> colleague reading on how to make graphs.
>>
>> Best regards
>> --
>> Paolo Giarrusso - Ph.D. Student
>> http://www.informatik.uni-marburg.de/~pgiarrusso/
>>
>



-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/

From phyo.arkarlwin at gmail.com  Wed Jun 30 23:24:20 2010
From: phyo.arkarlwin at gmail.com (Phyo Arkar)
Date: Wed, 30 Jun 2010 21:24:20 +0000
Subject: [pypy-dev] PyPy 1.3 released
In-Reply-To: <AANLkTikaN3p6BNFUfXL4RlWB28ZwjrajeUb34r8SGvdy@mail.gmail.com>
References: <AANLkTikaN3p6BNFUfXL4RlWB28ZwjrajeUb34r8SGvdy@mail.gmail.com>
Message-ID: <AANLkTilLUMLMKFdwoFoY3f3Stc4DflBgPH6LBTal9pZi@mail.gmail.com>

So far , python-mysql still not working..

Anyone had sucessfully got it work?

On Fri, Jun 25, 2010 at 11:27 PM, Maciej Fijalkowski <fijall at gmail.com>wrote:

> =======================
> PyPy 1.3: Stabilization
> =======================
>
> Hello.
>
> We're please to announce release of PyPy 1.3. This release has two major
> improvements. First of all, we stabilized the JIT compiler since 1.2
> release,
> answered user issues, fixed bugs, and generally improved speed.
>
> We're also pleased to announce alpha support for loading CPython extension
> modules written in C. While the main purpose of this release is increased
> stability, this feature is in alpha stage and it is not yet suited for
> production environments.
>
> Highlights of this release
> ==========================
>
> * We introduced support for CPython extension modules written in C. As of
> now,
>  this support is in alpha, and it's very unlikely unaltered C extensions
> will
>  work out of the box, due to missing functions or refcounting details. The
>  support is disable by default, so you have to do::
>
>   import cpyext
>
>  before trying to import any .so file. Also, libraries are
> source-compatible
>  and not binary-compatible. That means you need to recompile binaries,
> using
>  for example::
>
>   python setup.py build
>
>  Details may vary, depending on your build system. Make sure you include
>  the above line at the beginning of setup.py or put it in your
> PYTHONSTARTUP.
>
>  This is alpha feature. It'll likely segfault. You have been warned!
>
> * JIT bugfixes. A lot of bugs reported for the JIT have been fixed, and its
>  stability greatly improved since 1.2 release.
>
> * Various small improvements have been added to the JIT code, as well as a
> great
>  speedup of compiling time.
>
> Cheers,
> Maciej Fijalkowski, Armin Rigo, Alex Gaynor, Amaury Forgeot d'Arc and
> the PyPy team
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20100630/70b112f1/attachment-0001.htm