From simon at arrowtheory.com  Fri Aug  1 04:59:29 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Fri, 1 Aug 2008 12:59:29 +1000
Subject: [pypy-dev] numpy and pypy : info required
In-Reply-To: <d75825660807271711r58b1f529o9559f69249360e92@mail.gmail.com>
References: <d75825660807271711r58b1f529o9559f69249360e92@mail.gmail.com>
Message-ID: <20080801125929.8937138a.simon@arrowtheory.com>

On Sun, 27 Jul 2008 18:11:15 -0600
"rahul garg" <whycode at gmail.com> wrote:

> Hi.
> 
> I am writing a compiler called unPython (http://code.google.com/p/unpython)
> a very young and immature compiler for compiling Python to C.
> I am presenting the compiler at SciPy conference and need to write a paper
> about it. Under related work, I want to describe PyPy and also the status of
> NumPy support in PyPy.
> Can someone comment on whats the status of NumPy support in PyPy?
> 
...

Do you still want this information ? I am largely responsible for the numpy
inspired code in pypy. So far it has turned out to be more of an experiment to get
to know the pypy codebase, than actual "numpy support".

Simon.


From arigo at tunes.org  Sun Aug  3 15:13:49 2008
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 3 Aug 2008 15:13:49 +0200
Subject: [pypy-dev] new -O option
Message-ID: <20080803131349.GA3155@code0.codespeak.net>

Hi all,

I'm going to merge the "opt-option" branch; I'll write a blog post entry
when it's done.  It removes the "--faassen" and "--allopts" options to
translate.py and adds instead the "--opt=#" option, which can also be
spelled "-O#", where "#" is one of 0, 1, size, mem, 2 or 3.  Levels from
0 to 3 are trade-offs between the time+memory it takes to translate, and
the efficiency of the produced executable.  Levels "size" and "mem" try
(or should try in the future) to minimize the executable size and the
runtime memory usage, respectively.  The level is a global option of
translate.py but it also influences PyPy-specific options in
targetpypystandalone.py; for example, a bit arbitrarily, geninterp is
disabled with -O0.  The specific config options enabled or disabled by
each level can depend on e.g. the selected backend; see the two
functions set_opt_level() and set_pypy_opt_level().

We have a number of open branches; does it make sense, in an effort to
reduce confusion, to apply this change to some of them too?


A bientot,

Armin


From lawfulfalafel at gmail.com  Mon Aug  4 00:11:08 2008
From: lawfulfalafel at gmail.com (lawful falafel)
Date: Sun, 3 Aug 2008 18:11:08 -0400
Subject: [pypy-dev] problem with svn-checkout pypy
Message-ID: <c22a4930808031511g73e6e3dbid021c8db8d06fa38@mail.gmail.com>

I checked out a copy of pypy today and upon trying to run "python
pypy-dist/pypy/bin/py.py" I get this error:

k at k-desktop:~$ python pypy-dist/pypy/bin/py.py
[cbuild:execute] cc -O3 -fomit-frame-pointer -pthread -c gcctest.c -o
gcctest.o
Traceback (most recent call last):
  File "pypy-dist/pypy/bin/py.py", line 147, in <module>
    sys.exit(main_(sys.argv))
  File "pypy-dist/pypy/bin/py.py", line 64, in main_
    space = option.make_objspace(config)
  File "/home/k/pypy-dist/pypy/tool/option.py", line 48, in make_objspace
    space = Space(config)
  File "/home/k/pypy-dist/pypy/interpreter/baseobjspace.py", line 237, in
__init__
    self.initialize()
  File "/home/k/pypy-dist/pypy/objspace/std/objspace.py", line 71, in
initialize
    self.model = StdTypeModel(self.config)
  File "/home/k/pypy-dist/pypy/objspace/std/model.py", line 88, in __init__
    import pypy.objspace.std.marshal_impl # install marshal multimethods
  File "/home/k/pypy-dist/pypy/objspace/std/marshal_impl.py", line 21, in
<module>
    from pypy.rlib.rstruct import ieee
  File "/home/k/pypy-dist/pypy/rlib/rstruct/__init__.py", line 8, in
<module>
    from pypy.rlib.rstruct.formatiterator import FormatIterator
  File "/home/k/pypy-dist/pypy/rlib/rstruct/formatiterator.py", line 2, in
<module>
    from pypy.rlib.rstruct.nativefmttable import native_is_bigendian
  File "/home/k/pypy-dist/pypy/rlib/rstruct/nativefmttable.py", line 8, in
<module>
    from pypy.rpython.tool import rffi_platform
  File "/home/k/pypy-dist/pypy/rpython/tool/rffi_platform.py", line 5, in
<module>
    from pypy.rpython.lltypesystem import rffi
  File "/home/k/pypy-dist/pypy/rpython/lltypesystem/rffi.py", line 338, in
<module>
    NUMBER_TYPES = setup()
  File "/home/k/pypy-dist/pypy/rpython/lltypesystem/rffi.py", line 330, in
setup
    tp = platform.inttype(name.upper(), c_name, signed)
  File "/home/k/pypy-dist/pypy/rpython/tool/rfficache.py", line 49, in
inttype
    bits = sizeof_c_type(c_name, **kwds) * 8
  File "/home/k/pypy-dist/pypy/rpython/tool/rfficache.py", line 38, in
sizeof_c_type
    return int(ask_gcc(question, **kwds))
  File "/home/k/pypy-dist/pypy/rpython/tool/rfficache.py", line 34, in
ask_gcc
    return build_executable_cache([c_file], eci)
  File "/home/k/pypy-dist/pypy/tool/gcc_cache.py", line 23, in
build_executable_cache
    result = py.process.cmdexec(build_executable(c_files, eci))
  File "/home/k/pypy-dist/pypy/translator/tool/cbuild.py", line 621, in
build_executable
    compiler.build(noerr=noerr)
  File "/home/k/pypy-dist/pypy/translator/tool/cbuild.py", line 574, in
build
    raise CompilationError(data)
pypy.translator.tool.cbuild.CompilationError: gcctest.c:3:20: error:
stdlib.h: No such file or directory
gcctest.c:4:23: error: sys/types.h: No such file or directory
gcctest.c: In function 'main':
gcctest.c:11: warning: incompatible implicit declaration of built-in
function 'printf'
gcctest.c:13:2: warning: no newline at end of file
command 'cc' failed with exit status 1

My gcc -v is this:
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

And my python version is this:
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2

Can anyone suggest how I might fix this?

Thanks!

p.s. I know this is a pretty noob question, and I am not sure if a
development mailing list is the right place to post it, but right now it
seems like the only potential place I can find. Am I wrong in this
assumption, and is there another list dedicated to people trying to get into
pypy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080803/274357a1/attachment.html>

From exarkun at divmod.com  Mon Aug  4 02:21:43 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Sun, 3 Aug 2008 20:21:43 -0400
Subject: [pypy-dev] problem with svn-checkout pypy
In-Reply-To: <c22a4930808031511g73e6e3dbid021c8db8d06fa38@mail.gmail.com>
Message-ID: <20080804002143.29191.961003596.divmod.quotient.10275@ohm>

On Sun, 3 Aug 2008 18:11:08 -0400, lawful falafel <lawfulfalafel at gmail.com> wrote:
>I checked out a copy of pypy today and upon trying to run "python
>pypy-dist/pypy/bin/py.py" I get this error:
>
>k at k-desktop:~$ python pypy-dist/pypy/bin/py.py
>[cbuild:execute] cc -O3 -fomit-frame-pointer -pthread -c gcctest.c -o
>gcctest.o
>Traceback (most recent call last):
> [snip]
>    raise CompilationError(data)
>pypy.translator.tool.cbuild.CompilationError: gcctest.c:3:20: error:
>stdlib.h: No such file or directory
>gcctest.c:4:23: error: sys/types.h: No such file or directory
>gcctest.c: In function 'main':
>gcctest.c:11: warning: incompatible implicit declaration of built-in
>function 'printf'
>gcctest.c:13:2: warning: no newline at end of file
>command 'cc' failed with exit status 1

Notice that the reason the cc command failed is that "sys/types.h" could
not be found.  This probably means you're on a system that lacks a full
"development environment".  As it seems you're on Ubuntu, a convenient
way to get a lot of the requirements for PyPy is probably this command,
run as root:

    apt-get build-dep python2.5

This is because a lot of the build dependencies of PyPy and CPython
overlap.  This won't necessarily give you everything you need to do
everything with PyPy (for example, it won't install libgc or libgc-dev,
which is needed in order for a boehm-based transation to work) but it's
probably a good start.

> [snip]
>
>p.s. I know this is a pretty noob question, and I am not sure if a
>development mailing list is the right place to post it, but right now it
>seems like the only potential place I can find. Am I wrong in this
>assumption, and is there another list dedicated to people trying to get into
>pypy?
>

I think this is a perfectly fine question for this list. :)

Jean-Paul


From holger at merlinux.eu  Mon Aug  4 09:03:01 2008
From: holger at merlinux.eu (holger krekel)
Date: Mon, 4 Aug 2008 09:03:01 +0200
Subject: [pypy-dev] new -O option
In-Reply-To: <20080803131349.GA3155@code0.codespeak.net>
References: <20080803131349.GA3155@code0.codespeak.net>
Message-ID: <20080804070301.GK9619@trillke.net>

Hi Armin, 

On Sun, Aug 03, 2008 at 15:13 +0200, Armin Rigo wrote:
> Hi all,
> 
> I'm going to merge the "opt-option" branch; I'll write a blog post entry
> when it's done.  It removes the "--faassen" and "--allopts" options to
> translate.py and adds instead the "--opt=#" option, which can also be
> spelled "-O#", where "#" is one of 0, 1, size, mem, 2 or 3.  Levels from
> 0 to 3 are trade-offs between the time+memory it takes to translate, and
> the efficiency of the produced executable.  Levels "size" and "mem" try
> (or should try in the future) to minimize the executable size and the
> runtime memory usage, respectively.  The level is a global option of
> translate.py but it also influences PyPy-specific options in
> targetpypystandalone.py; for example, a bit arbitrarily, geninterp is
> disabled with -O0.  The specific config options enabled or disabled by
> each level can depend on e.g. the selected backend; see the two
> functions set_opt_level() and set_pypy_opt_level().

looks good.  i particularly like that a single "-O#" sets
things nicely both for translation and the target. 

> We have a number of open branches; does it make sense, in an effort to
> reduce confusion, to apply this change to some of them too?

Maybe, yes.  Reminds me: I'd really like to see better tool 
support for working with branches. eazysvn from Marius Gedminas 
might help a bit (haven't tried) but i am rather thinking of
something that helps me efficiently managing 
e.g. my "codespeak.net/svn/pypy" checkout, including quick
overviews of active branches, easy merging (without knowing
numbers) etc.  Some might think "dvcs!" here but it's a while
until we go there, i think, and i even consider somewhat orthogonal 
to having support for my particular work flow. 

cheers, 

holger


From exarkun at divmod.com  Mon Aug  4 13:29:33 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Mon, 4 Aug 2008 07:29:33 -0400
Subject: [pypy-dev] new -O option
In-Reply-To: <20080804070301.GK9619@trillke.net>
Message-ID: <20080804112933.29191.2084489418.divmod.quotient.10437@ohm>

On Mon, 4 Aug 2008 09:03:01 +0200, holger krekel <holger at merlinux.eu> wrote:
>Hi Armin,
>
>On Sun, Aug 03, 2008 at 15:13 +0200, Armin Rigo wrote:
>> Hi all,
>>
>> I'm going to merge the "opt-option" branch; I'll write a blog post entry
>> when it's done.  It removes the "--faassen" and "--allopts" options to
>> translate.py and adds instead the "--opt=#" option, which can also be
>> spelled "-O#", where "#" is one of 0, 1, size, mem, 2 or 3.  Levels from
>> 0 to 3 are trade-offs between the time+memory it takes to translate, and
>> the efficiency of the produced executable.  Levels "size" and "mem" try
>> (or should try in the future) to minimize the executable size and the
>> runtime memory usage, respectively.  The level is a global option of
>> translate.py but it also influences PyPy-specific options in
>> targetpypystandalone.py; for example, a bit arbitrarily, geninterp is
>> disabled with -O0.  The specific config options enabled or disabled by
>> each level can depend on e.g. the selected backend; see the two
>> functions set_opt_level() and set_pypy_opt_level().
>
>looks good.  i particularly like that a single "-O#" sets
>things nicely both for translation and the target.
>
>> We have a number of open branches; does it make sense, in an effort to
>> reduce confusion, to apply this change to some of them too?
>
>Maybe, yes.  Reminds me: I'd really like to see better tool
>support for working with branches. eazysvn from Marius Gedminas
>might help a bit (haven't tried) but i am rather thinking of
>something that helps me efficiently managing
>e.g. my "codespeak.net/svn/pypy" checkout, including quick
>overviews of active branches, easy merging (without knowing
>numbers) etc.  Some might think "dvcs!" here but it's a while
>until we go there, i think, and i even consider somewhat orthogonal
>to having support for my particular work flow.
>

Combinator does some of these things.

http://divmod.org/trac/wiki/DivmodCombinator

Jean-Paul


From arigo at tunes.org  Mon Aug  4 16:17:36 2008
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 4 Aug 2008 16:17:36 +0200
Subject: [pypy-dev] new -O option
In-Reply-To: <20080803131349.GA3155@code0.codespeak.net>
References: <20080803131349.GA3155@code0.codespeak.net>
Message-ID: <20080804141736.GA7151@code0.codespeak.net>

reHi,

On Sun, Aug 03, 2008 at 03:13:49PM +0200, Armin Rigo wrote:
> I'm going to merge the "opt-option" branch; I'll write a blog post entry
> when it's done.

While I'm at it, should I remove --allworkingmodules and make it the
default?  Should this also include the thread module?  If additionally
the default value for --opt would be 3, then just typing ./translate.py
would produce a pypy-c executable of the "most recommended and most
useful" kind.


A bientot,

Armin.


From anto.cuni at gmail.com  Mon Aug  4 16:23:29 2008
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 04 Aug 2008 16:23:29 +0200
Subject: [pypy-dev] new -O option
In-Reply-To: <20080804141736.GA7151@code0.codespeak.net>
References: <20080803131349.GA3155@code0.codespeak.net>
	<20080804141736.GA7151@code0.codespeak.net>
Message-ID: <489710E1.7020802@gmail.com>

Armin Rigo wrote:


> While I'm at it, should I remove --allworkingmodules and make it the
> default?  Should this also include the thread module?  If additionally
> the default value for --opt would be 3, then just typing ./translate.py
> would produce a pypy-c executable of the "most recommended and most
> useful" kind.

+1

The only drawback I see is that with --allworkingmodules the 
translations takes longer to complete, but I agree that the casual user 
probably cares more about functionality than translation speed.

Does --allworkingmodules also increase the ram usage?

ciao,
anto


From santagada at gmail.com  Mon Aug  4 16:49:59 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Mon, 4 Aug 2008 11:49:59 -0300
Subject: [pypy-dev] new -O option
In-Reply-To: <489710E1.7020802@gmail.com>
References: <20080803131349.GA3155@code0.codespeak.net>
	<20080804141736.GA7151@code0.codespeak.net>
	<489710E1.7020802@gmail.com>
Message-ID: <0E2AF1A2-934D-423E-BBEE-3294647CC100@gmail.com>


On 04/08/2008, at 11:23, Antonio Cuni wrote:

> Armin Rigo wrote:
>
>
>> While I'm at it, should I remove --allworkingmodules and make it the
>> default?  Should this also include the thread module?  If  
>> additionally
>> the default value for --opt would be 3, then just typing ./ 
>> translate.py
>> would produce a pypy-c executable of the "most recommended and most
>> useful" kind.
>
> +1
>
> The only drawback I see is that with --allworkingmodules the
> translations takes longer to complete, but I agree that the casual  
> user
> probably cares more about functionality than translation speed.
>
> Does --allworkingmodules also increase the ram usage?


just do a reverse switch, --withoutextramodules or something.

--
Leonardo Santagada





From cfbolz at gmx.de  Wed Aug  6 20:57:36 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 06 Aug 2008 20:57:36 +0200
Subject: [pypy-dev] Stdlib porting
In-Reply-To: <b27f1a340808060958v3c1b6e7m44ecf09ca38bc74c@mail.gmail.com>
References: <b27f1a340808060958v3c1b6e7m44ecf09ca38bc74c@mail.gmail.com>
Message-ID: <4899F420.90205@gmx.de>

Hi Bruno (ccing pypy-dev)!


Bruno Gola wrote:
> After having some problems I finished PEP 328 and I'm starting to work
> on stdlib now.
> 
> However, there is one test that's still failing and I can't fix it :(.
> It's in interpreter/test/test_nestedscope.py (lambda_in_genexpr), any
> hints?

No clue yet, will take a look.

> About the stdlib, do you have any suggestion about how/where to begin?
> 
> I'm looking at http://docs.python.org/whatsnew/modules.html but it
> seems that most of the changes will not affect my work (as most of the
> modules are written in pure python).
> 
> My plans initially are:
>  - copy the stdlib from CPython 2.5.2
>  - apply the changes from modified-2.4.1

Yes, exactly. You should add a new directory lib-python/2.5.2 and import
CPython's stdlib there. Then you need to carefully look at the changes
in modified-2.4.1 and check how they need to be applied to the relevant
2.5.2 module.

>  - rewrite any new module written in C*

This one has a much lower priority than getting the pure-Python modules
to a sensible state.

> * well, taking a better look, it seems that the new modules are
> wsgiref, xml.etree package, hashlib (all in python), ctypes and
> sqlite3 (in C, but it seems too that there are some work already done
> on those two modules, am I right?).

sqlite3 and ctypes should be done already. Some work on hashlib was
started, afair. It is in the lib dir, I think?

> Of course tests are in my plan as well.

They'd better be :-). I guess part of the porting work should really be
to check that the stdlib tests keep passing, which is quite important
because they also check the other 2.5 features that you implemented.

> Sorry for not being online on IRC today while working, I'm behind a
> proxy and it isn't a friendly proxy :-)

You know that you can use other ports to connect to freenode? I think
even 8000 works, which most procies let through.

Cheers,

Carl Friedrich


From santagada at gmail.com  Wed Aug  6 22:43:54 2008
From: santagada at gmail.com (Leonardo Santagada)
Date: Wed, 6 Aug 2008 17:43:54 -0300
Subject: [pypy-dev] Stdlib porting
In-Reply-To: <4899F420.90205@gmx.de>
References: <b27f1a340808060958v3c1b6e7m44ecf09ca38bc74c@mail.gmail.com>
	<4899F420.90205@gmx.de>
Message-ID: <7BB313A8-F49F-42C3-BFB6-36BCA69F5F44@gmail.com>


On 06/08/2008, at 15:57, Carl Friedrich Bolz wrote:

>>
>> Sorry for not being online on IRC today while working, I'm behind a
>> proxy and it isn't a friendly proxy :-)
>
> You know that you can use other ports to connect to freenode? I think
> even 8000 works, which most procies let through.


There are many ports, but to really get trough stupid proxies I've  
been using mibbit[1][2] a web client for irc.

[1] http://www.mibbit.com/
[2] https://www.mibbit.com/
--
Leonardo Santagada





From rajb at rice.edu  Thu Aug 14 20:36:23 2008
From: rajb at rice.edu (Raj Bandyopadhyay)
Date: Thu, 14 Aug 2008 13:36:23 -0500
Subject: [pypy-dev] Building pypy-c on mac os x
Message-ID: <48A47B27.8040202@rice.edu>

Hi all

I was wondering if pypy-c can be built on Mac OS X, and if there are any 
special options to use? I tried building it on a Linux/x86 machine and 
it worked fine (took a while to build), but on a mac, it seems to bring 
the machine down completely (the machine becomes non-responsive during 
the process).

This is a mac running Leopard with Intel core-duo processors.

Is this a known issue?

Thanks
Raj


From fijall at gmail.com  Thu Aug 14 21:14:29 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 14 Aug 2008 21:14:29 +0200
Subject: [pypy-dev] Building pypy-c on mac os x
In-Reply-To: <48A47B27.8040202@rice.edu>
References: <48A47B27.8040202@rice.edu>
Message-ID: <693bc9ab0808141214n28c140a8r483d432947ff5817@mail.gmail.com>

You need about 1.1-1.2G of RAM (double for 64 bit machine) and it
should work fine on Mac OS X. (This is more or less the same for
linux).

Cheers,
fijal

On Thu, Aug 14, 2008 at 8:36 PM, Raj Bandyopadhyay <rajb at rice.edu> wrote:
> Hi all
>
> I was wondering if pypy-c can be built on Mac OS X, and if there are any
> special options to use? I tried building it on a Linux/x86 machine and
> it worked fine (took a while to build), but on a mac, it seems to bring
> the machine down completely (the machine becomes non-responsive during
> the process).
>
> This is a mac running Leopard with Intel core-duo processors.
>
> Is this a known issue?
>
> Thanks
> Raj
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>


From paskma at gmail.com  Fri Aug 15 00:35:45 2008
From: paskma at gmail.com (=?WINDOWS-1252?Q?Marek_Pa=9Aka?=)
Date: Fri, 15 Aug 2008 00:35:45 +0200
Subject: [pypy-dev] Unable to translate locks
In-Reply-To: <4ddb710e0807300910t454c1b97keee3096b72d56832@mail.gmail.com>
References: <4ddb710e0807290355qe2454c8kdcdaa86d3c1fa2f6@mail.gmail.com>
	<20080730073454.GB662@code0.codespeak.net>
	<4ddb710e0807300910t454c1b97keee3096b72d56832@mail.gmail.com>
Message-ID: <4ddb710e0808141535l2cdf143ar5b14fc0d68c5f9fa@mail.gmail.com>

Hi,

well, I've solved this problem. The point is that the lock in my
example is created at import time, before translation. Works fine if
the initialization is moved into a function that can be translated.

Marek Pa?ka

On Wed, Jul 30, 2008 at 18:10, Marek Pa?ka <paskma at gmail.com> wrote:
> Hi!
>
> I tried this option and it does not change anything. In fact, this
> option is not even needed for pypy interpreter translation, with
> --withmod-thread the pypy interpreter is compiled successfully and the
> thread module is usable regardless of the --thread option. As I
> understand, the --thread option only affects runtime behavior, e.g.,
> ensures that GC is aware of multiple threads or so. Or am I wrong?
>
> It seems, there is some magic used when the thread module is
> translated. Something that affects annotation... I don't know. I spent
> several days debugging it but PyPy is rather complex.
>
> Cheers,
>
> Marek Pa?ka
>
> On Wed, Jul 30, 2008 at 09:34, Armin Rigo <arigo at tunes.org> wrote:
>> Hi,
>>
>> On Tue, Jul 29, 2008 at 12:55:33PM +0200, Marek Pa?ka wrote:
>>> paskma at paskma:goal$ ./translate.py mytasks_err.py
>>
>> I think you need to specify the --thread option:
>>
>>    ./translate.py --thread mytasks_err.py
>>
>>
>> A bientot,
>>
>> Armin
>>
>


From me at andy.durdin.net  Sat Aug 16 02:44:22 2008
From: me at andy.durdin.net (Andrew Durdin)
Date: Fri, 15 Aug 2008 17:44:22 -0700
Subject: [pypy-dev] Building pypy-c on mac os x
In-Reply-To: <693bc9ab0808141214n28c140a8r483d432947ff5817@mail.gmail.com>
References: <48A47B27.8040202@rice.edu>
	<693bc9ab0808141214n28c140a8r483d432947ff5817@mail.gmail.com>
Message-ID: <AAD89E76-0BD1-4DDB-A1B0-E11C5A7A67D3@andy.durdin.net>

On 14 Aug 2008, at 12:14, "Maciej Fijalkowski" <fijall at gmail.com> wrote:

> You need about 1.1-1.2G of RAM (double for 64 bit machine) and it
> should work fine on Mac OS X
>>
>>
>>
>>
>>

On my iBook with 1.25G total RAM, it ran out of free RAM and started  
swapping heavily, so I killed it. On my iMac (core duo, Leopard, 2G  
RAM) it built successfully in a reasonable time; however I was not  
trying to do anything else at the time. It used about 1.1G of RAM and  
about the same of virtual memory IIRC.

Andrew.


From brunogola at gmail.com  Tue Aug 19 05:49:23 2008
From: brunogola at gmail.com (Bruno Gola)
Date: Tue, 19 Aug 2008 00:49:23 -0300
Subject: [pypy-dev] Translate pypy-c
Message-ID: <b27f1a340808182049n5955e833pf483c45ef461b99c@mail.gmail.com>

Hi!

I'm working on branch 2.5-features and trying to translate pypy-c.
Probably some of the changes I made are not RPython and the translator
crashes.

Some of theses changes I've already found and fixed, but now I can't
find out how to fix this error (traceback
http://paste.pocoo.org/show/82666/).

The traceback points to checkFlag() in pyassem.py, but it's identical
to trunk. I've written some code that uses this method (visitImport()
and visitFrom() in pycodegen.py).

I don't know much about the translator. Does anyone have any idea
about what's wrong?

Thanks,
--
Bruno Fialho Marques Gola <brunogola at gmail.com>
http://www.brunogola.com.br
Cel: (11) 9294-5883


From brunogola at gmail.com  Tue Aug 19 06:17:52 2008
From: brunogola at gmail.com (Bruno Gola)
Date: Tue, 19 Aug 2008 01:17:52 -0300
Subject: [pypy-dev] Translate pypy-c
In-Reply-To: <b27f1a340808182049n5955e833pf483c45ef461b99c@mail.gmail.com>
References: <b27f1a340808182049n5955e833pf483c45ef461b99c@mail.gmail.com>
Message-ID: <b27f1a340808182117w56e2c1bcra4306e2d652d3a8d@mail.gmail.com>

Sorry, the right traceback: http://paste.pocoo.org/show/82667/

Anyway, mwhudson pointed that it's maybe a bug in checkFlag() (that
wasn't called until now). It returns 1 or None. Trying to translate
again.
--
Bruno Fialho Marques Gola <brunogola at gmail.com>
http://www.brunogola.com.br
Cel: (11) 9294-5883

On Tue, Aug 19, 2008 at 12:49 AM, Bruno Gola <brunogola at gmail.com> wrote:
> Hi!
>
> I'm working on branch 2.5-features and trying to translate pypy-c.
> Probably some of the changes I made are not RPython and the translator
> crashes.
>
> Some of theses changes I've already found and fixed, but now I can't
> find out how to fix this error (traceback
> http://paste.pocoo.org/show/82666/).
>
> The traceback points to checkFlag() in pyassem.py, but it's identical
> to trunk. I've written some code that uses this method (visitImport()
> and visitFrom() in pycodegen.py).
>
> I don't know much about the translator. Does anyone have any idea
> about what's wrong?
>
> Thanks,
> --
> Bruno Fialho Marques Gola <brunogola at gmail.com>
> http://www.brunogola.com.br
> Cel: (11) 9294-5883
>


From cfbolz at gmx.de  Tue Aug 19 11:40:25 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 19 Aug 2008 11:40:25 +0200
Subject: [pypy-dev] Translate pypy-c
In-Reply-To: <b27f1a340808182117w56e2c1bcra4306e2d652d3a8d@mail.gmail.com>
References: <b27f1a340808182049n5955e833pf483c45ef461b99c@mail.gmail.com>
	<b27f1a340808182117w56e2c1bcra4306e2d652d3a8d@mail.gmail.com>
Message-ID: <48AA9509.90705@gmx.de>

Bruno Gola wrote:
> Sorry, the right traceback: http://paste.pocoo.org/show/82667/
> 
> Anyway, mwhudson pointed that it's maybe a bug in checkFlag() (that
> wasn't called until now). It returns 1 or None. Trying to translate
> again.

checkFlag was rather silly, it should just return a boolean, but it
returned 1 or None, which isn't possible in RPython. I changed it. There
are more problems along the lines of the first problem you had, maybe
I'll fix those if I have time.

Cheers,

Carl Friedrich


From holger at merlinux.eu  Fri Aug 22 13:08:14 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 22 Aug 2008 13:08:14 +0200
Subject: [pypy-dev] ANN: pylib/pytest 0.9.2 released
Message-ID: <20080822110814.GQ9619@trillke.net>


Welcome to the 0.9.2 py lib and py.test release -
mainly fixing Windows issues, providing better
packaging and integration with setuptools.

Summry of main features:

* py.test: cross-project testing tool with many advanced features
* py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes
* py.magic.greenlet: micro-threads on standard CPython ("stackless-light")
* py.path: path abstractions over local and subversion files
* rich documentation of py's exported API
* tested against Linux, Win32, OSX, works on python 2.3-2.6

good entry points: 

Pypi pages: http://pypi.python.org/pypi/py/
Download/Install: http://codespeak.net/py/0.9.2/download.html
Documentation/API:  http://codespeak.net/py/0.9.2/index.html

the CHANGELOG excerpt for the 0.9.1 -> 0.9.2 transition: 

* refined installation and metadata, created new setup.py, 
  now based on setuptools/ez_setup (thanks to Ralf Schmitt 
  for his support).

* improved the way of making py.* scripts available in 
  windows environments, they are now added to the 
  Scripts directory as ".cmd" files. 

* py.path.svnwc.status() now is more complete and 
  uses xml output from the 'svn' command if available
  (Guido Wesdorp)

* fix for py.path.svn* to work with svn 1.5
  (Chris Lamb)

* fix path.relto(otherpath) method on windows to 
  use normcase for checking if a path is relative.

* py.test's traceback is better parseable from editors 
  (follows the filenames:LINENO: MSG convention)
  (thanks to Osmo Salomaa)

* fix to javascript-generation, "py.test --runbrowser" 
  should work more reliably now

* removed previously accidentally added 
  py.test.broken and py.test.notimplemented helpers. 

* there now is a py.__version__ attribute


best and have fun,

holger krekel

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org 


From ondrej at certik.cz  Sun Aug 24 16:08:29 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Sun, 24 Aug 2008 16:08:29 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
Message-ID: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>

Hi,

I am using pypy in Debian:

ondra at fuji:~/sympy$ python2.4
Python 2.4.5 (#2, Jul 20 2008, 20:55:34)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sympy
>>>
ondra at fuji:~/sympy$ pypy
Python 2.4.1 (pypy 1.0.0 build 55235) on linux2
Type "help", "copyright", "credits" or "license" for more information.
``the 'super' keyword is not that huggable''
>>>> import sympy
Traceback (most recent call last):
  File "<console>", line 1, in <interactive>
  File "/home/ondra/sympy/sympy/__init__.py", line 16, in <module>
    from sympy.core import *
  File "/home/ondra/sympy/sympy/core/__init__.py", line 13, in <module>
    from function import Lambda, WildFunction, Derivative, diff,
FunctionClass, \
  File "/home/ondra/sympy/sympy/core/function.py", line 361, in <module>
    class WildFunction(Function, Atom):
  File "/home/ondra/sympy/sympy/core/function.py", line 68, in __new__
    return type.__new__(cls, name, bases, attrdict)
TypeError: instance layout conflicts in multiple inheritance
>>>>


Do you know what this error means and how should we fix sympy so that
it works on top of pypy?

Ondrej


From fijall at gmail.com  Mon Aug 25 10:23:55 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 10:23:55 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
Message-ID: <693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>

Works for me:

fijal at zygfryd:~$ pypy-c
Python 2.4.1 (pypy 1.0.0 build 57237) on linux2
Type "help", "copyright", "credits" or "license" for more information.
Welcome to rlcompleter2 0.96
for nice experiences hit <tab> multiple times
And now for something completely different: ``"peephope" optimizations are what
an optimistic Compiler uses''
>>>> import sympy
>>>>

If you have old pypy build try pypy-c --oldstyle, otherwise you can
retranslate pypy.

On Sun, Aug 24, 2008 at 4:08 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> Hi,
>
> I am using pypy in Debian:
>
> ondra at fuji:~/sympy$ python2.4
> Python 2.4.5 (#2, Jul 20 2008, 20:55:34)
> [GCC 4.3.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import sympy
>>>>
> ondra at fuji:~/sympy$ pypy
> Python 2.4.1 (pypy 1.0.0 build 55235) on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> ``the 'super' keyword is not that huggable''
>>>>> import sympy
> Traceback (most recent call last):
>  File "<console>", line 1, in <interactive>
>  File "/home/ondra/sympy/sympy/__init__.py", line 16, in <module>
>    from sympy.core import *
>  File "/home/ondra/sympy/sympy/core/__init__.py", line 13, in <module>
>    from function import Lambda, WildFunction, Derivative, diff,
> FunctionClass, \
>  File "/home/ondra/sympy/sympy/core/function.py", line 361, in <module>
>    class WildFunction(Function, Atom):
>  File "/home/ondra/sympy/sympy/core/function.py", line 68, in __new__
>    return type.__new__(cls, name, bases, attrdict)
> TypeError: instance layout conflicts in multiple inheritance
>>>>>
>
>
> Do you know what this error means and how should we fix sympy so that
> it works on top of pypy?
>
> Ondrej
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>


From fijall at gmail.com  Mon Aug 25 10:24:30 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 10:24:30 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
Message-ID: <693bc9ab0808250124uc4d3765w767c962f65e8e79d@mail.gmail.com>

Ah, sorry misread. Your pypy (from debian) seems to be a bit old.
Please use svn version.

On Sun, Aug 24, 2008 at 4:08 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> Hi,
>
> I am using pypy in Debian:
>


From ondrej at certik.cz  Mon Aug 25 10:44:47 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 25 Aug 2008 10:44:47 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
Message-ID: <85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>

On Mon, Aug 25, 2008 at 10:23 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Works for me:
>
> fijal at zygfryd:~$ pypy-c
> Python 2.4.1 (pypy 1.0.0 build 57237) on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> Welcome to rlcompleter2 0.96
> for nice experiences hit <tab> multiple times
> And now for something completely different: ``"peephope" optimizations are what
> an optimistic Compiler uses''
>>>>> import sympy
>>>>>

Hm, doesn't seem to work for me:

$ svn co http://codespeak.net/svn/pypy/dist pypy-dist
$ cd sympy/
$ python ~/repos/pypy-dist/pypy/bin/py.py
faking <type 'module'>
PyPy 1.0.0 in StdObjSpace on top of Python 2.5.2 (startuptime: 10.83 secs)
>>>> import sympy
Traceback (application-level):
  File "<inline>", line 1 in <interactive>
    import sympy
  File "/home/ondra/sympy/sympy/__init__.py", line 16 in <module>
    from sympy.core import *
  File "/home/ondra/sympy/sympy/core/__init__.py", line 13 in <module>
    from function import Lambda, WildFunction, Derivative, diff,
FunctionClass, \
  File "/home/ondra/sympy/sympy/core/function.py", line 361 in <module>
    class WildFunction(Function, Atom):
  File "/home/ondra/sympy/sympy/core/function.py", line 68 in __new__
    return type.__new__(cls, name, bases, attrdict)
TypeError: instance layout conflicts in multiple inheritance
>>>>


>
> If you have old pypy build try pypy-c --oldstyle, otherwise you can
> retranslate pypy.

Old pypy + oldstyle doesn't seem to help:

$ pypy --oldstyle
Python 2.4.1 (pypy 1.0.0 build 55235) on linux2
Type "help", "copyright", "credits" or "license" for more information.
``I'm sorry, could you please not agree with the cat as well?''
>>>> import sympy
Traceback (most recent call last):
  File "<console>", line 1, in <interactive>
  File "/home/ondra/sympy/sympy/__init__.py", line 16, in <module>
    from sympy.core import *
  File "/home/ondra/sympy/sympy/core/__init__.py", line 13, in <module>
    from function import Lambda, WildFunction, Derivative, diff,
FunctionClass, \
  File "/home/ondra/sympy/sympy/core/function.py", line 361, in <module>
    class WildFunction(Function, Atom):
  File "/home/ondra/sympy/sympy/core/function.py", line 68, in __new__
    return type.__new__(cls, name, bases, attrdict)
TypeError: instance layout conflicts in multiple inheritance
>>>>


So now I am trying to compile pypy-svn, but I doubt it will work if it
doesn't work on top of python. Which sympy version are you using?

Ondrej


From fijall at gmail.com  Mon Aug 25 10:51:18 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 10:51:18 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
Message-ID: <693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>

>
>
> So now I am trying to compile pypy-svn, but I doubt it will work if it
> doesn't work on top of python. Which sympy version are you using?
>
> Ondrej
>

0.4.2-1, I'll try newer one.


From fijall at gmail.com  Mon Aug 25 11:19:20 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 11:19:20 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
Message-ID: <693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>

Ok, I can reproduce it with newer version of sympy. Not sure what's wrong yet.

On Mon, Aug 25, 2008 at 10:51 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>>
>> So now I am trying to compile pypy-svn, but I doubt it will work if it
>> doesn't work on top of python. Which sympy version are you using?
>>
>> Ondrej
>>
>
> 0.4.2-1, I'll try newer one.
>


From ondrej at certik.cz  Mon Aug 25 11:45:26 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 25 Aug 2008 11:45:26 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
Message-ID: <85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>

On Mon, Aug 25, 2008 at 11:19 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Ok, I can reproduce it with newer version of sympy. Not sure what's wrong yet.

Exactly. That's what I wanted to ask you what's wrong. :)

I think we are using some stupid hacks, but if you could enlighten me
how to fix sympy so that it works on pypy, it'd be awesome.

Ondrej


From fijall at gmail.com  Mon Aug 25 12:08:19 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 12:08:19 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
Message-ID: <693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>

I'm not sure whether it's sympy's fault or pypy's fault. It might be
that pypy is too strict about that.

Arguments look like this:

(Pdb++) bases[0].__mro__
(Function, <class 'sympy.core.basic.Basic'>, <class
'sympy.core.assumptions.AssumeMeths'>, <type 'object'>)
(Pdb++) bases[1].__mro__
(<class 'sympy.core.basic.Atom'>, <class 'sympy.core.basic.Basic'>,
<class 'sympy.core.assumptions.AssumeMeths'>, <type 'object'>)
(Pdb++) cls
<class 'sympy.core.function.FunctionClass'>
(Pdb++) cls.__mro__
(<class 'sympy.core.function.FunctionClass'>, <class
'sympy.core.basic.BasicMeta'>, <class 'sympy.core.basic.BasicType'>,
<type 'type'>, <type 'object'>)
(Pdb++)

And it seems that bases[0] and bases[1] are incompatible (why?)

On Mon, Aug 25, 2008 at 11:45 AM, Ondrej Certik <ondrej at certik.cz> wrote:
> On Mon, Aug 25, 2008 at 11:19 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>> Ok, I can reproduce it with newer version of sympy. Not sure what's wrong yet.
>
> Exactly. That's what I wanted to ask you what's wrong. :)
>
> I think we are using some stupid hacks, but if you could enlighten me
> how to fix sympy so that it works on pypy, it'd be awesome.
>
> Ondrej
>


From ondrej at certik.cz  Mon Aug 25 12:50:35 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 25 Aug 2008 12:50:35 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
Message-ID: <85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>

On Mon, Aug 25, 2008 at 12:08 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> I'm not sure whether it's sympy's fault or pypy's fault. It might be
> that pypy is too strict about that.
>
> Arguments look like this:
>
> (Pdb++) bases[0].__mro__
> (Function, <class 'sympy.core.basic.Basic'>, <class
> 'sympy.core.assumptions.AssumeMeths'>, <type 'object'>)
> (Pdb++) bases[1].__mro__
> (<class 'sympy.core.basic.Atom'>, <class 'sympy.core.basic.Basic'>,
> <class 'sympy.core.assumptions.AssumeMeths'>, <type 'object'>)
> (Pdb++) cls
> <class 'sympy.core.function.FunctionClass'>
> (Pdb++) cls.__mro__
> (<class 'sympy.core.function.FunctionClass'>, <class
> 'sympy.core.basic.BasicMeta'>, <class 'sympy.core.basic.BasicType'>,
> <type 'type'>, <type 'object'>)
> (Pdb++)
>
> And it seems that bases[0] and bases[1] are incompatible (why?)

Don't know. This patch fixes it:

diff --git a/sympy/core/function.py b/sympy/core/function.py
index 76a0f5b..a99c21d 100644
--- a/sympy/core/function.py
+++ b/sympy/core/function.py
@@ -362,7 +362,7 @@ class Function(Basic):
         x = sympify(x)
         return cls(x).diff(x, n).subs(x, 0) * x**n / C.Factorial(n)

-class WildFunction(Function, Atom):
+class WildFunction(Function):
     """
     WildFunction() matches any expression but another WildFunction()
     XXX is this as intended, does it work ?


But now there is this problem:

>>>> import sympy
Traceback (most recent call last):
  File "<console>", line 1, in <interactive>
  File "/home/ondra/repos/sympy/sympy/__init__.py", line 22, in <module>
    from concrete import *
  File "/home/ondra/repos/sympy/sympy/concrete/__init__.py", line 2, in <module>
    from products import product, Product
  File "/home/ondra/repos/sympy/sympy/concrete/products.py", line 5, in <module>
    from sympy.simplify import powsimp
  File "/home/ondra/repos/sympy/sympy/simplify/__init__.py", line 10,
in <module>
    from rewrite import cancel, trim, apart
  File "/home/ondra/repos/sympy/sympy/simplify/rewrite.py", line 22, in <module>
    def cancel(f, *symbols):
TypeError: threaded() takes no non-keyword argument (1 given)


Any idea what's wrong here? Here is the code:

@threaded()
def cancel(f, *symbols):
    """Cancel common factors in a given rational function.

and:

def threaded(**flags):


Seems a-ok to me. Is pypy using some strict things? I don't know, but
this patch fixes it:

diff --git a/sympy/utilities/decorator.py b/sympy/utilities/decorator.py
index 0043de1..f812b51 100644
--- a/sympy/utilities/decorator.py
+++ b/sympy/utilities/decorator.py
@@ -3,7 +3,7 @@ from sympy.core.add import Add
 from sympy.core.sympify import sympify
 from sympy.core.relational import Relational

-def threaded(**flags):
+def threaded(*args, **flags):


Now it imports. Wow!

>>>> import sympy
>>>> from sympy import var
>>>> var("x y z")
(x, y, z)
>>>> x**2
x**2
>>>> from sympy import sin
>>>> e = sin(x)
>>>> e.series(x, 0, 5)
x - 1/6*x**3 + O(x**5)

Guys, this is awesome!

I did some timings:

$ ~/repos/pypy-dist/pypy/translator/goal/pypy-c
Python 2.4.1 (pypy 1.0.0 build 57617) on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``Python 300''
>>>> from sympy import *
>>>> var("x")
x
>>>> from timeit import default_timer as clock
>>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
3.31447815895

Compare to python:

$ python
Python 2.5.2 (r252:60911, Aug  8 2008, 09:22:44)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import *
>>> var("x")
x
>>> from timeit import default_timer as clock
>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
0.704444885254


So pypy is roughly 4.7x slower on this particular thing.

Do you have any plans to release pypy? I think it's getting very useful.

Ondrej


From fijall at gmail.com  Mon Aug 25 13:04:34 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 13:04:34 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
	<85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
Message-ID: <693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>

>
> So pypy is roughly 4.7x slower on this particular thing.
>
> Do you have any plans to release pypy? I think it's getting very useful.
>
> Ondrej
>

Yes, we have some plans to have a release at some point soon. There
are no details though. Note that if you do this:

from sympy import *
var('x')
from timeit import default_timer as clock
t = clock(); a= sin(x).series(x, 0, 100); t = clock()-t; print t
var('y')
t = clock(); a= sin(y).series(y, 0, 100); t = clock()-t; print

gap between pypy and cpython is getting smaller (some startup time is
particularly large). I can do a bit profiling if you like.

Regarding threaded - I think you should not assume that your argument
is passed as keyword arg when using decorator I think. The other one
looks like bug in pypy, but I'm not 100% sure.

Cheers,
fijal


From ondrej at certik.cz  Mon Aug 25 13:28:49 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 25 Aug 2008 13:28:49 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
	<85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
	<693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>
Message-ID: <85b5c3130808250428i78d05763wc9a2bda072e98a70@mail.gmail.com>

On Mon, Aug 25, 2008 at 1:04 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>> So pypy is roughly 4.7x slower on this particular thing.
>>
>> Do you have any plans to release pypy? I think it's getting very useful.
>>
>> Ondrej
>>
>
> Yes, we have some plans to have a release at some point soon. There
> are no details though. Note that if you do this:
>
> from sympy import *
> var('x')
> from timeit import default_timer as clock
> t = clock(); a= sin(x).series(x, 0, 100); t = clock()-t; print t
> var('y')
> t = clock(); a= sin(y).series(y, 0, 100); t = clock()-t; print
>
> gap between pypy and cpython is getting smaller (some startup time is
> particularly large). I can do a bit profiling if you like.

Use SYMPY_USE_CACHE=no when doing repeated profiling, otherwise you
are just measuring how fast our cache is.

ondra at pc232:~/repos/sympy$ SYMPY_USE_CACHE=no
~/repos/pypy-dist/pypy/translator/goal/pypy-c
Python 2.4.1 (pypy 1.0.0 build 57617) on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``- PyPy status blog:
http://morepypy.blogspot.com/''
>>>> from sympy import *
>>>> var('x')
x
>>>> from timeit import default_timer as clock
>>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
3.56681609154
>>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
3.2662088871
>>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
3.22522711754
>>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
3.24221301079
>>>>


ondra at pc232:~/repos/sympy$ SYMPY_USE_CACHE=no python
Python 2.5.2 (r252:60911, Aug  8 2008, 09:22:44)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import *
>>> var('x')
x
>>> from timeit import default_timer as clock
>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
0.83996295929
>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
0.739042043686
>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
0.73944401741
>>> t = clock(); a= sin(x).series(x, 0, 1000); t = clock()-t; print t
0.739789009094


We are in the process of speeding up sympy, you can also play with our
experimental core that doesn't use caching:

$ git clone git://github.com/certik/sympyx.git
$ cd sympyx
$ ~/repos/pypy-dist/pypy/translator/goal/pypy-c
Python 2.4.1 (pypy 1.0.0 build 57617) on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``"peephope" optimizations are what
an optimistic Compiler uses''
>>>> from sympy import var
I: import sympy_pyx ... fail  (No module named sympy_pyx)
W: can't import sympy_pyx -- will be pure python
>>>> var("x y z")
(x, y, z)
>>>> e = (x+y+z+1)**40
>>>> from timeit import default_timer as clock
>>>> t = clock(); a= e.expand(); t = clock()-t; print t
2.6539349556
>>>> t = clock(); a= e.expand(); t = clock()-t; print t
2.73331212997
>>>> t = clock(); a= e.expand(); t = clock()-t; print t
2.76934981346
>>>>

$ python
Python 2.5.2 (r252:60911, Aug  8 2008, 09:22:44)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import var
I: import sympy_pyx ... fail  (No module named sympy_pyx)
W: can't import sympy_pyx -- will be pure python
>>> var("x y z")
(x, y, z)
>>> e = (x+y+z+1)**40
>>> from timeit import default_timer as clock
>>> t = clock(); a= e.expand(); t = clock()-t; print t
0.867521047592
>>> t = clock(); a= e.expand(); t = clock()-t; print t
1.13780593872
>>> t = clock(); a= e.expand(); t = clock()-t; print t
1.13062214851
>>> t = clock(); a= e.expand(); t = clock()-t; print t
1.14683890343
>>> t = clock(); a= e.expand(); t = clock()-t; print t
1.17529797554


So for that pypy is only 2x to 3x slower.

BTW, when you compile our core using Cython, it get's way faster:

$ make
cython --convert-range sympy_pyx.pyx
gcc -I/usr/include/python2.5 -I/usr/include/python2.5	 -g -O0 -fPIC
-c -o sympy_pyx.o sympy_pyx.c
gcc  -shared sympy_pyx.o -o sympy_pyx.so
$ python
Python 2.5.2 (r252:60911, Aug  8 2008, 09:22:44)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy import var
I: import sympy_pyx ... ok
>>> var("x y z")
(Symbol(x), Symbol(y), Symbol(z))
>>> e = (x+y+z+1)**40
>>> from timeit import default_timer as clock
>>> t = clock(); a= e.expand(); t = clock()-t; print t
0.214432001114
>>> t = clock(); a= e.expand(); t = clock()-t; print t
0.271343946457
>>> t = clock(); a= e.expand(); t = clock()-t; print t
0.239308834076



Do you have any plans for supporting writing C extensions to pypy?
Because as you can see above, the speed is imho only possible when
writing it in C. Well, if RPython could produce as optimized code as
Cython, then it could be an option. Any ideas on that?


Ondrej


From arigo at tunes.org  Mon Aug 25 16:04:57 2008
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 25 Aug 2008 16:04:57 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
Message-ID: <20080825140456.GA17156@code0.codespeak.net>

Hi Ondrej,

On Sun, Aug 24, 2008 at 04:08:29PM +0200, Ondrej Certik wrote:
> TypeError: instance layout conflicts in multiple inheritance

Not completely surprizingly, our multiple inheritance "instance layout
conflict" condition is not 100% the same as CPython's (as the latter is
really obscure and based on conditions like the size of C-level
structures).  Still, I think that this case should work, so it looks
like a bug in PyPy.

Filed issue #390: https://codespeak.net/issue/pypy-dev/issue390


Armin


From ondrej at certik.cz  Mon Aug 25 16:20:40 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 25 Aug 2008 16:20:40 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <20080825140456.GA17156@code0.codespeak.net>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<20080825140456.GA17156@code0.codespeak.net>
Message-ID: <85b5c3130808250720l303ef822s20f0707e791558ba@mail.gmail.com>

On Mon, Aug 25, 2008 at 4:04 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Ondrej,
>
> On Sun, Aug 24, 2008 at 04:08:29PM +0200, Ondrej Certik wrote:
>> TypeError: instance layout conflicts in multiple inheritance
>
> Not completely surprizingly, our multiple inheritance "instance layout
> conflict" condition is not 100% the same as CPython's (as the latter is
> really obscure and based on conditions like the size of C-level
> structures).  Still, I think that this case should work, so it looks
> like a bug in PyPy.
>
> Filed issue #390: https://codespeak.net/issue/pypy-dev/issue390

Thanks Armin for looking into this. Btw, if it helps, ironpython also
fails on conflict1.py from #390:

$ ipy conflict1.py
Traceback (most recent call last):
  File conflict1, line unknown, in Initialize
  File mscorlib, line unknown, in get_Item
KeyError: The given key was not present in the dictionary.

Also I don't like mutliple inheritance, so we should just fix sympy
and be done with it.

Unfortunately IronPython fails later too and Jython as well:

$ /home/ondra/ext/jython/jython
Jython 2.5a1+ (asm:4943:4945, Jul 15 2008, 15:30:04)
[Java HotSpot(TM) Server VM (Sun Microsystems Inc.)] on java1.5.0_15
Type "help", "copyright", "credits" or "license" for more information.
>>> import sympy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sympy/__init__.py", line 16, in <module>
    from sympy.core import *
  File "sympy/core/__init__.py", line 4, in <module>
    from basic import Basic, S, C, sympify
  File "sympy/core/basic.py", line 236, in <module>
    class Basic(AssumeMeths):
TypeError: Error when calling the metaclass bases
    mro() returned base with unsuitable layout ('Basic')

So this suggests that sympy code is not standard.

Ondrej


From fijall at gmail.com  Mon Aug 25 22:26:00 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 25 Aug 2008 22:26:00 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808250428i78d05763wc9a2bda072e98a70@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250123n4bca4adfr69020b01d331d96a@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
	<85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
	<693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>
	<85b5c3130808250428i78d05763wc9a2bda072e98a70@mail.gmail.com>
Message-ID: <693bc9ab0808251326n6f2acf35la4b4c73b3194db94@mail.gmail.com>

>
>
>
> Do you have any plans for supporting writing C extensions to pypy?
> Because as you can see above, the speed is imho only possible when
> writing it in C. Well, if RPython could produce as optimized code as
> Cython, then it could be an option. Any ideas on that?
>
>
> Ondrej
>

There are no immediate plans for supporting C extensions to pypy
besides via ctypes or rpython. RPython is fairly fast these days, try
it out if you like (big fat warning, rpython is an obscure language).
Also usecases like sympy one should see relatively good speedups via
JIT. Did you try using psyco?

Cheers,
fijal


From ondrej at certik.cz  Mon Aug 25 23:29:03 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 25 Aug 2008 23:29:03 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <693bc9ab0808251326n6f2acf35la4b4c73b3194db94@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
	<85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
	<693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>
	<85b5c3130808250428i78d05763wc9a2bda072e98a70@mail.gmail.com>
	<693bc9ab0808251326n6f2acf35la4b4c73b3194db94@mail.gmail.com>
Message-ID: <85b5c3130808251429r6c16dc6an355c4ed872bb974@mail.gmail.com>

On Mon, Aug 25, 2008 at 10:26 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>>
>>
>> Do you have any plans for supporting writing C extensions to pypy?
>> Because as you can see above, the speed is imho only possible when
>> writing it in C. Well, if RPython could produce as optimized code as
>> Cython, then it could be an option. Any ideas on that?
>>
>>
>> Ondrej
>>
>
> There are no immediate plans for supporting C extensions to pypy
> besides via ctypes or rpython. RPython is fairly fast these days, try
> it out if you like (big fat warning, rpython is an obscure language).
> Also usecases like sympy one should see relatively good speedups via
> JIT. Did you try using psyco?

Psyco gives pretty good results (but not as good as Cython), but as I
understood, it is not developed anymore as I thought pypy is the way
to go.

Yes, Cython is also a new language basically, but it's very easy to
learn and easy to debug, easy to compile and one is able to blend C
and Python very easily and naturally, so it's my choice. But on the
other hand, I really think that one should just write what he wants in
Python, maybe give it couple hints and pypy (or anything else) should
be clever enough to optimize it.
Cython is not perfect, but one can get C level speed now. They plan to
allow a pure python syntax, so that the same code actually also runs
in Python.

But anyway, pypy has my thumbs up. 3x slower than CPython is not
*that* bad, so imho if you could release, it'd be awesome.

Ondrej


From seob at gmx.ch  Tue Aug 26 17:35:06 2008
From: seob at gmx.ch (Severin)
Date: Tue, 26 Aug 2008 17:35:06 +0200
Subject: [pypy-dev] master thesis with pypy
Message-ID: <a3ea99f80808260835g71de645q3152c6c0c0a458de@mail.gmail.com>

Hello everybody,

I am Severin - a student at ETH in Zurich. Currently i'm enrolled at the
Masters program in computer science. The next 6 month, starting from the
15th of September I will do my thesis. This more or less means working on a
project. Since me and my mentor (Nicholas Matsakis) both share interest in
python we came up with the idea to do some work with the pypy project.

We started to talk about what we could do and what would be interesting for
us. In some way we wanted to '*improve multiprocessor capabilities*' in
pypy. We had some ideas so far, but we are not yet fixed on something.

I was wondering if somebody of you has something that is of particular
interest to the pypy community. Some ideas that might be interesting to look
at for me. Any kind of input or idea is welcome...

Best regards,
Severin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080826/c67cc772/attachment.html>

From sanxiyn at gmail.com  Tue Aug 26 18:21:50 2008
From: sanxiyn at gmail.com (Seo Sanghyeon)
Date: Wed, 27 Aug 2008 01:21:50 +0900
Subject: [pypy-dev] master thesis with pypy
In-Reply-To: <a3ea99f80808260835g71de645q3152c6c0c0a458de@mail.gmail.com>
References: <a3ea99f80808260835g71de645q3152c6c0c0a458de@mail.gmail.com>
Message-ID: <5b0248170808260921j7c2e4bb4hb97980d7e10d8818@mail.gmail.com>

2008/8/27 Severin <seob at gmx.ch>:
> We started to talk about what we could do and what would be interesting for
> us. In some way we wanted to 'improve multiprocessor capabilities' in pypy.
> We had some ideas so far, but we are not yet fixed on something.
>
> I was wondering if somebody of you has something that is of particular
> interest to the pypy community. Some ideas that might be interesting to look
> at for me. Any kind of input or idea is welcome...

A random idea. Implementing python-safethread monitors for PyPy?
http://code.google.com/p/python-safethread/wiki/Monitors

-- 
Seo Sanghyeon


From fijall at gmail.com  Tue Aug 26 18:30:56 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 26 Aug 2008 18:30:56 +0200
Subject: [pypy-dev] master thesis with pypy
In-Reply-To: <a3ea99f80808260835g71de645q3152c6c0c0a458de@mail.gmail.com>
References: <a3ea99f80808260835g71de645q3152c6c0c0a458de@mail.gmail.com>
Message-ID: <693bc9ab0808260930u74ea5ed8k8fbed6869d0d7d32@mail.gmail.com>

Hello.

Can you explain a bit in which direction would you like to go? Or is
the topic vague for a reason to experiment a bit? Would you rather
want say, create some GILless locking mechanism in pypy or rather
implement some cool multi-process framework based on what is done
already?

Cheers,
fijal

On Tue, Aug 26, 2008 at 5:35 PM, Severin <seob at gmx.ch> wrote:
> Hello everybody,
>
> I am Severin - a student at ETH in Zurich. Currently i'm enrolled at the
> Masters program in computer science. The next 6 month, starting from the
> 15th of September I will do my thesis. This more or less means working on a
> project. Since me and my mentor (Nicholas Matsakis) both share interest in
> python we came up with the idea to do some work with the pypy project.
>
> We started to talk about what we could do and what would be interesting for
> us. In some way we wanted to 'improve multiprocessor capabilities' in pypy.
> We had some ideas so far, but we are not yet fixed on something.
>
> I was wondering if somebody of you has something that is of particular
> interest to the pypy community. Some ideas that might be interesting to look
> at for me. Any kind of input or idea is welcome...
>
> Best regards,
> Severin
>
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>


From simon at arrowtheory.com  Tue Aug 26 22:27:15 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Tue, 26 Aug 2008 16:27:15 -0400
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808251429r6c16dc6an355c4ed872bb974@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<85b5c3130808250144h7491af7ct44466b50eb5e6afa@mail.gmail.com>
	<693bc9ab0808250151h70833903ub9a4d28476ebc90d@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
	<85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
	<693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>
	<85b5c3130808250428i78d05763wc9a2bda072e98a70@mail.gmail.com>
	<693bc9ab0808251326n6f2acf35la4b4c73b3194db94@mail.gmail.com>
	<85b5c3130808251429r6c16dc6an355c4ed872bb974@mail.gmail.com>
Message-ID: <20080826162715.e67b96ed.simon@arrowtheory.com>

On Mon, 25 Aug 2008 23:29:03 +0200
"Ondrej Certik" <ondrej at certik.cz> wrote:

> Cython is not perfect, but one can get C level speed now. They plan to
> allow a pure python syntax, so that the same code actually also runs
> in Python.

What do you mean here ? Cython already allows pure python syntax.

Simon.


From ondrej at certik.cz  Wed Aug 27 00:19:06 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Wed, 27 Aug 2008 00:19:06 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <20080826162715.e67b96ed.simon@arrowtheory.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<693bc9ab0808250219o5e409d6am126cca7e62c126aa@mail.gmail.com>
	<85b5c3130808250245mf171848q6dc4d336d3fc01@mail.gmail.com>
	<693bc9ab0808250308u57e9efb2obf67781ddd7ebcf3@mail.gmail.com>
	<85b5c3130808250350k48495900xdafc1db237c50f4b@mail.gmail.com>
	<693bc9ab0808250404n2019ecc7k7e2231cea3af6cad@mail.gmail.com>
	<85b5c3130808250428i78d05763wc9a2bda072e98a70@mail.gmail.com>
	<693bc9ab0808251326n6f2acf35la4b4c73b3194db94@mail.gmail.com>
	<85b5c3130808251429r6c16dc6an355c4ed872bb974@mail.gmail.com>
	<20080826162715.e67b96ed.simon@arrowtheory.com>
Message-ID: <85b5c3130808261519s12942b34na75f98fe0660a45c@mail.gmail.com>

On Tue, Aug 26, 2008 at 10:27 PM, Simon Burton <simon at arrowtheory.com> wrote:
> On Mon, 25 Aug 2008 23:29:03 +0200
> "Ondrej Certik" <ondrej at certik.cz> wrote:
>
>> Cython is not perfect, but one can get C level speed now. They plan to
>> allow a pure python syntax, so that the same code actually also runs
>> in Python.
>
> What do you mean here ? Cython already allows pure python syntax.

Does it? Wow, didn't know about it. How do you write this in pure python syntax?

def f(int i, int j):
    return i*j

?

What I mean is to use some decorator, or some other (python) syntax to
represent the "int" in there.

Ondrej


From pedronis at openend.se  Wed Aug 27 11:23:35 2008
From: pedronis at openend.se (Samuele Pedroni)
Date: Wed, 27 Aug 2008 11:23:35 +0200
Subject: [pypy-dev] Pypy IRC meeting fri 17:00 UTC on #pypy (freenode.net)
Message-ID: <48B51D17.9020201@openend.se>

Hi all,

since EuroPython there's been some thinking and planning about doing a 
new release of PyPy 1.1 before the end of the year with a focus related 
to the recent work on compatibility  with applications and CPython and 
stability.

We think that an important step in the process is to improve and 
consolidate our testing infrastructure with the goal of making it easy 
to spot regressions.

After some people availability checking on #pypy we agreed on scheduling 
a meeting:

this Friday 29 Aug at 17:00 UTC (19:00 CEST)
on #pypy IRC channel (freenode.net)

The topics to discuss are:

- which machines do we have available or we need (we would like at least to cover Linux x86-32 and windows 32bits)
- requirements for our testing infrastructure
- status of buildbot related work, what would it take to use buildbot for all out testing needs?
- things to do first

This is an open meeting, anybody interested in topics is invited to participate. It should not last more than 1 hour.

We are also planning on having a sprint in October around the testing/release topics and others, we may also try at this meeting to finalize location and dates for that.

regards.



From arigo at tunes.org  Thu Aug 28 13:44:42 2008
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 28 Aug 2008 13:44:42 +0200
Subject: [pypy-dev] Pypy IRC meeting fri 17:00 UTC on #pypy
	(freenode.net)
In-Reply-To: <48B51D17.9020201@openend.se>
References: <48B51D17.9020201@openend.se>
Message-ID: <20080828114442.GA20581@code0.codespeak.net>

Hi all,

On Wed, Aug 27, 2008 at 11:23:35AM +0200, Samuele Pedroni wrote:
> this Friday 29 Aug at 17:00 UTC (19:00 CEST)

Let me point out that time again, as it's not at 17:00 CEST as it
usually was: it is at 19:00 CEST.


Armin


From paskma at gmail.com  Thu Aug 28 16:05:37 2008
From: paskma at gmail.com (=?WINDOWS-1252?Q?Marek_Pa=9Aka?=)
Date: Thu, 28 Aug 2008 16:05:37 +0200
Subject: [pypy-dev] pypy-jvm translation, patch
Message-ID: <4ddb710e0808280705r768d68e3h3316a11382e9db30@mail.gmail.com>

Hi,

today, I tried to translate pypy-jvm, but the translation failed with
the trace below. The following patch makes the translation to be
completed:

Index: pypy/translator/jvm/metavm.py
===================================================================
--- pypy/translator/jvm/metavm.py       (revision 57667)
+++ pypy/translator/jvm/metavm.py       (working copy)
@@ -93,6 +93,7 @@
     (ootype.Signed,           ootype.UnsignedLongLong): jvm.I2L,
     (ootype.SignedLongLong,   ootype.Signed):           jvm.L2I,
     (ootype.UnsignedLongLong, ootype.SignedLongLong):   None,
+    (ootype.UnsignedLongLong, ootype.Unsigned):         jvm.L2I,
     }

 class _CastPrimitive(MicroInstruction):

However, I am not really sure whether the patch is really correct :-)
Pypy-jvm does not work anyway, it is the problem I reported several
weeks ago:

paskma at paskma:goal$ ./pypy-jvm
'import site' failed
Python 2.4.1 (pypy 1.0.0 build 100000) on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``nothing is true''
Error calling sys.excepthook:
debug: OperationError:
debug:  operror-type: ImportError
debug:  operror-value: cannot import name 'curdir'

(Don't be confused by the build number, I am using git-svn.)

Marek Pa?ka

The traceback:

[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "translate.py", line 278, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/driver.py", line
797, in proceed
[translation:ERROR]     return self._execute(goals, task_skip =
self._maybe_skip())
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/tool/taskengine.py",
line 116, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/driver.py", line
268, in _do
[translation:ERROR]     res = func()
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/driver.py", line
709, in task_source_jvm
[translation:ERROR]     self.jvmsource = self.gen.generate_source()
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/genjvm.py",
line 266, in generate_source
[translation:ERROR]     GenOO.generate_source(self)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/genoo.py",
line 68, in generate_source
[translation:ERROR]     self.gen_pendings()
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/genoo.py",
line 83, in gen_pendings
[translation:ERROR]     node.render(self.ilasm)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/node.py",
line 899, in render
[translation:ERROR]     method.render(gen)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/function.py",
line 129, in render
[translation:ERROR]     self.render_normal_block(block)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/node.py",
line 473, in render_normal_block
[translation:ERROR]     return OOFunction.render_normal_block(self, block)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/function.py",
line 218, in render_normal_block
[translation:ERROR]     self._render_op(op)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/node.py",
line 574, in _render_op
[translation:ERROR]     OOFunction._render_op(self, op)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/function.py",
line 351, in _render_op
[translation:ERROR]     instr_list.render(self.generator, op)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/metavm.py",
line 247, in render
[translation:ERROR]     instr.render(generator, op)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/metavm.py",
line 62, in render
[translation:ERROR]     jmethod.return_type, op.result)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/metavm.py",
line 21, in _invoke_method
[translation:ERROR]     gen.load(arg)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/generator.py",
line 495, in load
[translation:ERROR]     return render_sub_op(value, self.db, self)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/function.py",
line 24, in render_sub_op
[translation:ERROR]     instr_list.render(generator, op)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/oosupport/metavm.py",
line 247, in render
[translation:ERROR]     instr.render(generator, op)
[translation:ERROR]    File
"/home/data/opt/svnpypy/vanilla-dist/pypy/translator/jvm/metavm.py",
line 102, in render
[translation:ERROR]     opcode = CASTS[(FROM, TO)]
[translation:ERROR]  KeyError: (<UnsignedLongLong>, <Unsigned>)


From nvetoshkin at naumen.ru  Thu Aug 28 17:13:58 2008
From: nvetoshkin at naumen.ru (=?UTF-8?B?0JLQtdGC0L7RiNC60LjQvSDQndC40LrQuNGC0LA=?=)
Date: Thu, 28 Aug 2008 21:13:58 +0600
Subject: [pypy-dev] translate.py failes
Message-ID: <48B6C0B6.6060802@naumen.ru>

Hi, everybody.
Tried to play with pypy, but translating to c failes because of lack of 
memory.
Used command: python translate.py.
OS: gentoo linux, amd64
RAM: 4Gb
Traceback attached to the letter.

nekto0n
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080828/74ef7df2/attachment.ksh>

From arigo at tunes.org  Thu Aug 28 17:31:10 2008
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 28 Aug 2008 17:31:10 +0200
Subject: [pypy-dev] translate.py failes
In-Reply-To: <48B6C0B6.6060802@naumen.ru>
References: <48B6C0B6.6060802@naumen.ru>
Message-ID: <20080828153110.GA8912@code0.codespeak.net>

Hi,

On Thu, Aug 28, 2008 at 09:13:58PM +0600, ???????????????? ???????????? wrote:
> Tried to play with pypy, but translating to c failes because of lack of 
> memory.

This is a known issue.  We will try to implement a workaround.  For now
you need to have more swap available.  Note that the swap will not
actually be used if you have >= 2GB of RAM; it is really a limitation of
some Linux configurations in which a process that consumes about half of
the total amount of memory+swap cannot spawn new processes because
os.fork() fails.


A bientot,

Armin.


From nvetoshkin at naumen.ru  Thu Aug 28 18:34:51 2008
From: nvetoshkin at naumen.ru (Vetoshkin Nikita)
Date: Thu, 28 Aug 2008 22:34:51 +0600
Subject: [pypy-dev] translate.py failes
In-Reply-To: <20080828153110.GA8912@code0.codespeak.net>
References: <48B6C0B6.6060802@naumen.ru>
	<20080828153110.GA8912@code0.codespeak.net>
Message-ID: <48B6D3AB.4050801@naumen.ru>

Is there a direction, where I could digg to help? Something to begin with.
I don't have enough experience but I'd like to take part (even very 
small) in this project.

Armin Rigo wrote:
> Hi,
>
> On Thu, Aug 28, 2008 at 09:13:58PM +0600, ???????????????? ???????????? wrote:
>> Tried to play with pypy, but translating to c failes because of lack of
>> memory.
>
> This is a known issue.  We will try to implement a workaround.  For now
> you need to have more swap available.  Note that the swap will not
> actually be used if you have>= 2GB of RAM; it is really a limitation of
> some Linux configurations in which a process that consumes about half of
> the total amount of memory+swap cannot spawn new processes because
> os.fork() fails.
>
>
> A bientot,
>
> Armin.

-- 
---
? ?????????,
???????? ??????

??????? ????????? ?????? IP-?????????
????????? ?????
???????? Naumen


From fijall at gmail.com  Fri Aug 29 12:09:20 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 29 Aug 2008 12:09:20 +0200
Subject: [pypy-dev] commit bot
Message-ID: <693bc9ab0808290309o78597f4fi4c4fe961ceef5828@mail.gmail.com>

what about moving from CIA to keenan (the bot that is sitting on
#pypy-commits and did not have a single downtime since last few
months) for commit messages on #pypy? CIA was down again yesterday.

cheers,
fijal


From tismer at stackless.com  Fri Aug 29 17:02:49 2008
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 29 Aug 2008 17:02:49 +0200
Subject: [pypy-dev] Pypy IRC meeting fri 17:00 UTC on
	#pypy	(freenode.net)
In-Reply-To: <20080828114442.GA20581@code0.codespeak.net>
References: <48B51D17.9020201@openend.se>
	<20080828114442.GA20581@code0.codespeak.net>
Message-ID: <48B80F99.6050300@stackless.com>

Armin Rigo wrote:
> Hi all,
> 
> On Wed, Aug 27, 2008 at 11:23:35AM +0200, Samuele Pedroni wrote:
>> this Friday 29 Aug at 17:00 UTC (19:00 CEST)
> 
> Let me point out that time again, as it's not at 17:00 CEST as it
> usually was: it is at 19:00 CEST.

I have to say that it would be extremely helpful NOT to repeat
the wrong time in the unchanged subject line. Recognized that too
late and made appointments.
Really wanted to attend, but I'm reading IRC rarely in the hospital.

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Fri Aug 29 17:47:08 2008
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 29 Aug 2008 17:47:08 +0200
Subject: [pypy-dev] Pypy IRC meeting fri 17:00 UTC
	on	#pypy	(freenode.net)
In-Reply-To: <48B80F99.6050300@stackless.com>
References: <48B51D17.9020201@openend.se>	<20080828114442.GA20581@code0.codespeak.net>
	<48B80F99.6050300@stackless.com>
Message-ID: <48B819FC.60209@stackless.com>

Christian Tismer wrote:
> Armin Rigo wrote:
>> Hi all,
>>
>> On Wed, Aug 27, 2008 at 11:23:35AM +0200, Samuele Pedroni wrote:
>>> this Friday 29 Aug at 17:00 UTC (19:00 CEST)
>> Let me point out that time again, as it's not at 17:00 CEST as it
>> usually was: it is at 19:00 CEST.
> 
> I have to say that it would be extremely helpful NOT to repeat
> the wrong time in the unchanged subject line. Recognized that too
> late and made appointments.
> Really wanted to attend, but I'm reading IRC rarely in the hospital.

Argh.
Argh Argh, of course.
Nothing was wrong with the title of this posting,
but still it was extremely misleading for me.

Will be more careful next time, but this one went wrong, sorry.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/


From arigo at tunes.org  Fri Aug 29 17:55:11 2008
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 29 Aug 2008 17:55:11 +0200
Subject: [pypy-dev] translate.py failes
In-Reply-To: <48B6D3AB.4050801@naumen.ru>
References: <48B6C0B6.6060802@naumen.ru>
	<20080828153110.GA8912@code0.codespeak.net>
	<48B6D3AB.4050801@naumen.ru>
Message-ID: <20080829155511.GA9583@code0.codespeak.net>

Hi,

On Thu, Aug 28, 2008 at 10:34:51PM +0600, Vetoshkin Nikita wrote:
> Is there a direction, where I could digg to help? Something to begin with.
> I don't have enough experience but I'd like to take part (even very 
> small) in this project.

Sure.  Do you understand the issue?  It's related to the way a Unix
process starts a new subprocess: os.fork() followed by os.execv() in the
child process.  The issue is that os.fork() fails if the parent process'
total memory is more than half of your RAM+swap, because it tries to
create a copy of the process, and the copy would also need more than
half of your RAM+swap.  (In reality, os.fork() doesn't copy the memory
at all, but creates "shared pages" of memory so that memory pages are
duplicated only when one of the two processes really modifies it; but
still os.fork() has to mark all the memory as *potentially* used, and
raises MemoryError if there isn't enough.)

A solution might be to split translate.py in two processes: translate.py
would start a subprocess when it starts, and then do all the work
(consuming a lot of RAM); but when it needs to start new processes, e.g.
call gcc, it would instead ask the subprocess to start the new
processes.  More precisely, the code in pypy.translator.tool.cbuild
would stop using distutils directly, and instead ask the subprocess to
use distutils.  It looks even easy to do with the help of a
py.execnet.PopenGateway() created when translate.py starts (see the py
lib documentation at http://codespeak.net/py/).


A bientot,

Armin


From arigo at tunes.org  Fri Aug 29 18:00:55 2008
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 29 Aug 2008 18:00:55 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <85b5c3130808250720l303ef822s20f0707e791558ba@mail.gmail.com>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<20080825140456.GA17156@code0.codespeak.net>
	<85b5c3130808250720l303ef822s20f0707e791558ba@mail.gmail.com>
Message-ID: <20080829160055.GB9583@code0.codespeak.net>

Hi Ondrej,

On Mon, Aug 25, 2008 at 04:20:40PM +0200, Ondrej Certik wrote:
>     class Basic(AssumeMeths):
> TypeError: Error when calling the metaclass bases
>     mro() returned base with unsuitable layout ('Basic')
> 
> So this suggests that sympy code is not standard.

That's obscure.  It probably points to a bug in Jython and IronPython,
or just some feature that is really obscure but that PyPy implements
like CPython by chance.

I fixed the multiple inheritance bug as well as the bug shown by the
@threaded() decorator.  Since rev 57656, pypy-c can import sympy.  (I
didn't try to do anything with it, though.)


A bientot,

Armin.


From holger at merlinux.eu  Fri Aug 29 20:38:01 2008
From: holger at merlinux.eu (holger krekel)
Date: Fri, 29 Aug 2008 20:38:01 +0200
Subject: [pypy-dev] commit bot
In-Reply-To: <693bc9ab0808290309o78597f4fi4c4fe961ceef5828@mail.gmail.com>
References: <693bc9ab0808290309o78597f4fi4c4fe961ceef5828@mail.gmail.com>
Message-ID: <20080829183801.GD9619@trillke.net>

Hi Maciej, 

On Fri, Aug 29, 2008 at 12:09 +0200, Maciej Fijalkowski wrote:
> what about moving from CIA to keenan (the bot that is sitting on
> #pypy-commits and did not have a single downtime since last few
> months) for commit messages on #pypy? CIA was down again yesterday.

I think we should give CIA some more chances 
to recover from the resource problem they have.  
it's a bit of effort to move to yet another solution (roundup
detectors, changing/testing codespeak config etc.). 

but good to know that on #pypy-commits 
one can get reliable dedicated pypy commits.

holger


From ondrej at certik.cz  Fri Aug 29 21:11:31 2008
From: ondrej at certik.cz (Ondrej Certik)
Date: Fri, 29 Aug 2008 21:11:31 +0200
Subject: [pypy-dev] works in python2.4, fails in pypy
In-Reply-To: <20080829160055.GB9583@code0.codespeak.net>
References: <85b5c3130808240708h20845b41y9b4db4627f5964dc@mail.gmail.com>
	<20080825140456.GA17156@code0.codespeak.net>
	<85b5c3130808250720l303ef822s20f0707e791558ba@mail.gmail.com>
	<20080829160055.GB9583@code0.codespeak.net>
Message-ID: <85b5c3130808291211q217785d9s4539f1bc1eb94ecd@mail.gmail.com>

On Fri, Aug 29, 2008 at 6:00 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Ondrej,
>
> On Mon, Aug 25, 2008 at 04:20:40PM +0200, Ondrej Certik wrote:
>>     class Basic(AssumeMeths):
>> TypeError: Error when calling the metaclass bases
>>     mro() returned base with unsuitable layout ('Basic')
>>
>> So this suggests that sympy code is not standard.
>
> That's obscure.  It probably points to a bug in Jython and IronPython,
> or just some feature that is really obscure but that PyPy implements
> like CPython by chance.

Yeah. We should try to fix sympy, so that we don't use obscure features.

>
> I fixed the multiple inheritance bug as well as the bug shown by the
> @threaded() decorator.  Since rev 57656, pypy-c can import sympy.  (I
> didn't try to do anything with it, though.)

Thanks for fixing it.

Ondrej


From fijall at gmail.com  Sat Aug 30 10:29:35 2008
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 30 Aug 2008 10:29:35 +0200
Subject: [pypy-dev] commit bot
In-Reply-To: <20080829183801.GD9619@trillke.net>
References: <693bc9ab0808290309o78597f4fi4c4fe961ceef5828@mail.gmail.com>
	<20080829183801.GD9619@trillke.net>
Message-ID: <693bc9ab0808300129r110f070ax4306204d346e7dec@mail.gmail.com>

On Fri, Aug 29, 2008 at 8:38 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Maciej,
>
> On Fri, Aug 29, 2008 at 12:09 +0200, Maciej Fijalkowski wrote:
>> what about moving from CIA to keenan (the bot that is sitting on
>> #pypy-commits and did not have a single downtime since last few
>> months) for commit messages on #pypy? CIA was down again yesterday.
>
> I think we should give CIA some more chances
> to recover from the resource problem they have.
> it's a bit of effort to move to yet another solution (roundup
> detectors, changing/testing codespeak config etc.).

Personally I think we gave it too much chances. Also I would like to
rely on roundup detectors etc via CIA and only do:

1. disable commit messages from CIA
2. move keenan from #pypy-commits to #pypy

that's super easy and simplifies stuff already.

>
> but good to know that on #pypy-commits
> one can get reliable dedicated pypy commits.
>
> holger
>