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://mail.python.org/pipermail/pypy-dev/attachments/20100506/02525ae4/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100511/a3ca1d80/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100511/237451b9/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100512/7420d771/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100513/350f29da/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100518/abce5c60/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100521/f96bd668/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20100521/e92e3190/attachment.html>

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
>