Mailman 3 February 2011 - pypy-dev

Re: [pypy-dev] Fwd: [codespeak-ann] termination of codespeak.net services end FEB 2011
by Laura Creighton Feb. 10, 2011

Feb. 10, 2011

We can move things to Open End if people are interested. But there is a lot to be said for moving to a place where the whole hosting matter is somebody else's problem. Right now we seem awfully dependent on home-grown tools. Are there any that people cannot live without? Note: I am playing with Sphinx and liking it. It takes ReST as input. Georg Brandl is about to come out with a release that lets readers post notes on documentation pages, which I think would be a very neat feature to have. So'd I'd sort of like to be able to run sphinx wherever we go, and, at some point convert all of our documentation to use sphinx. Laura

3 2

Re: [pypy-dev] [pypy-svn] pypy jit-virtual_state: never retrace a loop more than 5 times
by Maciej Fijalkowski Feb. 9, 2011

Feb. 9, 2011

On Tue, Feb 8, 2011 at 8:42 PM, hakanardo <commits-noreply(a)bitbucket.org> wrote: > Author: Hakan Ardo <hakan(a)debian.org> > Branch: jit-virtual_state > Changeset: r41714:91586ef4b9c5 > Date: 2011-02-08 19:42 +0100 > http://bitbucket.org/pypy/pypy/changeset/91586ef4b9c5/ > > Log: never retrace a loop more than 5 times Is this always a good idea? Maybe we should have a configurable parameter for that (like threshold). > > diff --git a/pypy/jit/metainterp/optimizeopt/unroll.py b/pypy/jit/metainterp/optimizeopt/unroll.py > --- a/pypy/jit/metainterp/optimizeopt/unroll.py > +++ b/pypy/jit/metainterp/optimizeopt/unroll.py > @@ -671,7 +671,10 @@ > "jumping to preamble instead") > self.emit_operation(op) > return > - if not self.retraced: > + retraced_count = len(short) > + if descr.failed_states: > + retraced_count += len(descr.failed_states) > + if not self.retraced and retraced_count<5: > if not descr.failed_states: > raise RetraceLoop > for failed in descr.failed_states: > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

1 0

Re: [pypy-dev] Compat. in 1.4.1 __del__
by Christian Tismer Feb. 8, 2011

Feb. 8, 2011

On 2/8/11 9:25 PM, Philip Jenvey wrote: > On Feb 5, 2011, at 9:04 PM, Dino Viehland wrote: > >> Christianwrote: >>> Howdy, >>> >>> studying the differences of PyPy vs. CPython, most seem to be fine; one >>> thing where I an unsure is the __del__ behavior. >>> >>> I am not addressing its delayed call or the number it is called, this is similar to >>> Jython and IronPython. >>> >>> But assigning to __del__ after a class is created, is that so hard to implement? >> IronPython also doesn't handle assigning to __del__ after the class is created, and >> I'd be surprised if Jython did as well. To make this work we'd need to maintain a >> weak reference for every object of a user defined type and I think most users >> would rather not pay that expense for such a corner case. I've also never actually >> heard of this breaking compatibility anywhere. > Jython doesn't either. We've been meaning to add the same warning PyPy does when you create a __del__ after the fact. > > The feature is simply not worth the effort. > > -- > Philip Jenvey Fine with me! I just wanted to know the reasons why this is more problematic than I thought. Thanks to all who replied. cheers - chris -- Christian Tismer :^)<mailto:tismer@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/

1 0

Virtuals discoverd by bridge
by Hakan Ardo Feb. 6, 2011

Feb. 6, 2011

Hi, at the sprint we talked about how to better handle boxes that become virtual in a bridge. In the jit-virtual_state branch there is now a first step towards that. Try: py.test test/test_virtual.py -k test_dual_counter --viewloops in pypy/jit/metainterp. The idea is compare the state of all the OptValues of the jump_args at the end of the bridge white all the OptValues of the jump_args at the end of the preamble. We will need this check anyway to be sure that it is safe to call the loop (just being able to inline the short preamble turned out not to be enough). When the states differ we have 3 options: - Force some of the virtuals to make the states match - Emitt guards to make the states match - Retrace the loop to form a new specialized version We will need some heuristic to choose between these. Currently I emit GUARD_CLASS if the boxes was of correct class during the current trace (box.value). In all other cases I retrace (which is probably too often). For the test above there are 2 virtuals, node1 and node2. There will be 3 specialized version of the loop generated: - node1 virtual, node2 allocated - node2 virtual, node1 allocated - both node1 and node2 virtuals The first 2 of these are currently generated. The last is not. For the last to be generated the retraced loop will need to inherit the virtuals from the bridge that causes it to be retraced (in the same manner as the bridges inherit the virtuals of their parent loops). -- Håkan Ardö

1 0

Compat. in 1.4.1 __del__
by Christian Tismer Feb. 6, 2011

Feb. 6, 2011

Howdy, studying the differences of PyPy vs. CPython, most seem to be fine; one thing where I an unsure is the __del__ behavior. I am not addressing its delayed call or the number it is called, this is similar to Jython and IronPython. But assigning to __del__ after a class is created, is that so hard to implement? It is clear to me that the existence of a __del__ heavily influences the whole code generation of a class. So as a naive thought, can we just abandon the whole compilation and start over (maybe even less)? The problem that I see is re-generation of already created instances, triggering some re-compilation. I would think of all compiled code always going through some "fuse code" that would trigger re-compilation if an assignment to __del__ happens. For me, this looks like a guard, that exists in other places of the JIT, where existing assumptions must check if they are still true, and otherwise start over. I have not read the current implementation, yet, because my reading is still quite impaired. But from the top of my head: Can it be that such a re-compile as I mentioned is not yet considered because that is not involving the JIT, but an already fixed part of the static compilation chain? I think not, since we are not in RPython, but at the translation of an applevel class, which is completely run-time compiled. So, where is my lack of seeing the problem? Or is it simply a lot of effort? If it is an efficiency concern, then my POV is: Better to be slow in a few cases of re-compilation, than to have to hunt for such delicate existing code. I would instead issue an optional warning to dynamic __del__ assignment instead, in order to let people avoid it in the future. regards, and thanks for correcting me - chris -- Christian Tismer :^)<mailto:tismer@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/

6 8

pypy jit
by Łukasz Ligowski Feb. 4, 2011

Feb. 4, 2011

Hi, First of all I'd like to thank all developers for good work on PyPy ;) I'd like to ask are there any rules of thumb to write code that PyPy JIT can easily optimize? Or maybe which constructs are hardly optimizable by JIT so it's better to avoid them? Best regards, Lukasz Ligowski

7 10

testing floating point
by Laura Creighton Feb. 4, 2011

Feb. 4, 2011

running the test suite of this package might be useful. Laura ------- Forwarded Message Return-Path: python-announce-list-bounces+lac=openend.se(a)python.org Delivery-Date: Wed Feb 2 00:29:19 2011 Return-Path: <python-announce-list-bounces+lac=openend.se(a)python.org> Received: from mail.python.org (mail.python.org [82.94.164.166]) by theraft.openend.se (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p11NTCgZ009584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <lac(a)openend.se>; Wed, 2 Feb 2011 00:29:14 +0100 Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 1089FEE9C0 for <lac(a)openend.se>; Wed, 2 Feb 2011 00:29:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1296602952; bh=SjeURYFJ0JANVg28+rd+7SNHYu2uW4+khr521TTR24c=; h=MIME-Version:Date:Message-ID:Subject:From:To:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=u3Vd1rser4Yn6sV8mw8GsXc9yRHbfI8ct22qpxaml8r0lxcbKfbHnjjLVdST1kZY3 0MKS5mryz3ElA42r6P3S60hM+tWW0uz4xFk2AVUCrIeWt3+tpHWgYx3oXKHdTtdKRN ZgYWWK3rX3RoCiBOhAKDddtq25GWXs4jg2p75OVc= X-Original-To: python-announce-list(a)python.org Delivered-To: python-announce-list(a)mail.python.org Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 51C0CEE9B8 for <python-announce-list(a)python.org>; Tue, 1 Feb 2011 23:11:46 +0100 (CET) X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'bug': 0.02; 'subject:ANN': 0.02; 'subject:Python': 0.05; '2.x': 0.05; 'implements': 0.05; 'library': 0.06; '3.x': 0.07; 'derivatives': 0.07; 'tracker': 0.07; 'url:googlecode': 0.07; 'python': 0.08; 'url:pypi': 0.08; 'arithmetic': 0.09; 'url:code': 0.15; '0.17': 0.16; 'codebase,': 0.16; 'subject:0.17': 0.16; 'url:changes': 0.16; 'url:issues': 0.16; 'url:svn': 0.16; 'url:trunk': 0.16; 'downloaded': 0.17; 'url:doc': 0.19; '2.4': 0.23; 'version': 0.24; 'url:group': 0.25; 'function': 0.27; 'functions.': 0.28; 'project': 0.29; 'message- id:@mail.gmail.com': 0.29; 'url:)': 0.29; 'thanks': 0.30; 'dropped': 0.30; 'standalone': 0.30; 'all,': 0.30; 'contributed': 0.31; 'requires': 0.33; 'version.': 0.34; 'url:google': 0.34; '2.5': 0.36; 'mathematical': 0.36; 'to:addr:python-announce-list': 0.36; 'used': 0.36; 'set': 0.37; 'list:': 0.37; 'works': 0.38; 'received:209.85': 0.38; 'received:google.com': 0.38; 'zero': 0.38; 'url:org': 0.38; 'subject:: ': 0.39; 'url:python': 0.39; 'to:addr:python.org': 0.40; 'comments': 0.40; 'url:p': 0.60; 'to:2**2': 0.64; 'url:0': 0.64; 'details,': 0.65; 'website:': 0.71; 'to:no real name:2**2': 0.75; 'url:17': 0.76; 'news': 0.78; 'fredrik': 0.91 Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 01 Feb 2011 23:11:46 +0100 Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for <python-announce-list(a)python.org>; Tue, 1 Feb 2011 23:11:45 +0100 (CET) Received: by qwa26 with SMTP id 26so7212791qwa.19 for <python-announce-list(a)python.org>; Tue, 01 Feb 2011 14:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=6yZ49a5xiXwaVsySNvnihUrvwjNRAycqDeQTj98mFN4=; b=TFkhQdC5AeC7EecRVy8bO+ZVjyDOniTJB9u5S4BVnuXSAIAa8U58xnIPqCNAEojT5M 2bA2NizGpC/zHNyQLa/yu92nhY85wb2Wv5FW72QkL9kklUpzkYFZp4/vi4nidCwFoA2R 7qa0fa3fksMnYLpIyfOE5Vv0NeyWrZKmxt/Jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qdEow0h50/OGUU89qp7muEE5FACELAhcuIpeNUeeV8srLOc4roz/kZHOS7NooIktaG 8lMo4dIEgm6aPAqeAxssYBAiQ5YDk/k0YxSsZovPJFV1incJEWpc9HIuuS9922zQUHeW J9J1GUwfUr/2QjPYed8ZCEQJkzSyAaSvGNFpI= MIME-Version: 1.0 Received: by 10.229.236.134 with SMTP id kk6mr7177714qcb.93.1296598304793; Tue, 01 Feb 2011 14:11:44 -0800 (PST) Received: by 10.229.245.209 with HTTP; Tue, 1 Feb 2011 14:11:44 -0800 (PST) Date: Tue, 1 Feb 2011 23:11:44 +0100 Message-ID: <AANLkTinnjWyQ3U0MYMRn7+dmRVtwUAmpPrZZiz7QDt_=(a)mail.gmail.com> Subject: ANN: mpmath 0.17 (Python 3 support and more) From: Fredrik Johansson <fredrik.johansson(a)gmail.com> To: mpmath(a)googlegroups.com, sympy(a)googlegroups.com, sage-devel(a)googlegroups.com, python-announce-list(a)python.org X-Mailman-Approved-At: Wed, 02 Feb 2011 00:22:14 +0100 X-BeenThere: python-announce-list(a)python.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: python-list(a)python.org List-Id: Announcement-only list for the Python programming language <python-announce-list.python.org> List-Unsubscribe: <http://mail.python.org/mailman/options/python-announce-list>, <mailto:python-announce-list-request@python.org?subject=unsubscribe> List-Archive: <http://mail.python.org/pipermail/python-announce-list> List-Post: <mailto:python-announce-list@python.org> List-Help: <mailto:python-announce-list-request@python.org?subject=help> List-Subscribe: <http://mail.python.org/mailman/listinfo/python-announce-list>, <mailto:python-announce-list-request@python.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: python-announce-list-bounces+lac=openend.se(a)python.org Errors-To: python-announce-list-bounces+lac=openend.se(a)python.org X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (theraft.openend.se [83.140.78.130]); Wed, 02 Feb 2011 00:29:14 +0100 (CET) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Feb 2 00:29:19 2011 X-DSPAM-Confidence: 0.9994 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1004,4d48974f95865701517258 Hi all, Version 0.17 of mpmath is now available on the project website: http://code.google.com/p/mpmath/ It can also be downloaded from the Python Package Index: http://pypi.python.org/pypi/mpmath/0.17 Mpmath is a pure-Python library for arbitrary-precision floating-point arithmetic that implements an extensive set of mathematical functions. It can be used as a standalone library or via SymPy (http://code.google.com/p/sympy/), and is also available as a standard component of Sage (http://sagemath.org/). The major news in 0.17 is that mpmath now works with Python 3. To support both Python 2.x and 3.x with the same codebase, compatibility with Python 2.4 has been dropped (mpmath now requires 2.5 or higher). New functionality in mpmath 0.17 includes an implementation of the Lerch transcendent, Riemann zeta zero counting, and improved support for evaluating derivatives of the Hurwitz zeta function and related functions. Many thanks to Juan Arias de Reyna and Case Vanhorsen who contributed to this version. For more details, see the changelog: http://mpmath.googlecode.com/svn/tags/0.17/CHANGES Extensive documentation is available at: http://mpmath.googlecode.com/svn/trunk/doc/build/index.html or http://mpmath.googlecode.com/svn/tags/0.17/doc/build/index.html Bug reports and other comments are welcome on the issue tracker at http://code.google.com/p/mpmath/issues/list or the mpmath mailing list: http://groups.google.com/group/mpmath Enjoy, Fredrik Johansson - -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/ ------- End of Forwarded Message

8 20

Link errors while translating with VS2010 and 64bit
by Tasos Vogiatzoglou Feb. 3, 2011

Feb. 3, 2011

Amaury, It seems that there is a general issue with the compiler/link . I did the translations without the _hashlib and ssl and after a while I got the following errors. [platform:ERROR] Creating library c:\users\flatline\appdata\local\temp\usessi on-default-57\testing_1\libpypy-c.lib and object c:\users\flatline\appdata\local\temp\usession-default-57\testing_1\libpypy-c.exp [platform:ERROR] implement_52.obj : error LNK2019: unresolved external symbol _inflateEnd referenced in function _pypy_g_ccall_inflateEnd__z_streamPtr [platform:ERROR] implement_64.obj : error LNK2019: unresolved external symbol _inflateInit2_ referenced in function _pypy_g_ccall_inflateInit2___z_streamPtr_Sig ned_arrayPtr [platform:ERROR] implement_64.obj : error LNK2019: unresolved external symbol _inflate referenced in function _pypy_g_ccall_inflate__z_streamPtr_Signed [platform:ERROR] implement_67.obj : error LNK2019: unresolved external symbol _deflateEnd referenced in function _pypy_g_ccall_deflateEnd__z_streamPtr [platform:ERROR] implement_69.obj : error LNK2019: unresolved external symbol _deflate referenced in function _pypy_g_ccall_deflate__z_streamPtr_Signed [platform:ERROR] implement_70.obj : error LNK2019: unresolved external symbol _adler32 referenced in function _pypy_g_ccall_adler32__Unsigned_arrayPtr_Unsigned [platform:ERROR] implement_71.obj : error LNK2019: unresolved external symbol _deflateInit2_ referenced in function _pypy_g_ccall_deflateInit2___z_streamPtr_Sig ned_Signed_S [platform:ERROR] implement_71.obj : error LNK2019: unresolved external symbol _crc32 referenced in function _pypy_g_ccall_crc32__Unsigned_arrayPtr_Unsigned [platform:ERROR] c:\users\flatline\appdata\local\temp\usession-default-57\testing_1\libpypy-c.dll : fatal error LNK1120: 8 unresolved externals [Timer] Timings: [Timer] annotate --- 1447.8 s [Timer] rtype_lltype --- 768.2 s [Timer] backendopt_lltype --- 415.9 s [Timer] stackcheckinsertion_lltype --- 60.1 s [Timer] database_c --- 498.3 s [Timer] source_c --- 1190.5 s [Timer] compile_c --- 216.4 s [Timer] =========================================== [Timer] Total: --- 4597.3 s [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "translate.py", line 290, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\driver.py", line 812, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\tool\taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\driver.py", line 288, in _do [translation:ERROR] res = func() [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\driver.py", line 575, in task_compile_c [translation:ERROR] cbuilder.compile(**kwds) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\c\genc.py", line 527, in compile [translation:ERROR] self.executable_name = compiler.build(shared=shared) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\c\genc.py", line 95, in build [translation:ERROR] return self._build(shared=shared) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\c\genc.py", line 90, in _build [translation:ERROR] standalone=not shared) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\platform\__init__.py", line 52, in compile [translation:ERROR] return self._finish_linking(ofiles, eci, outputfilename, standalone) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\platform\__init__.py", line 194, in _finish_linking [translation:ERROR] return self._link(cc_link, ofiles, largs, standalone, exe_name) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\platform\windows.py", line 176, in _link [translation:ERROR] self._execute_c_compiler(self.link, args, exe_name) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\platform\__init__.py", line 118, in _execute_c_compiler [translation:ERROR] self._handle_error(returncode, stderr, stdout, outname) [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\translator\platform\windows.py", line 199, in _handle_error [translation:ERROR] raise CompilationError(stdout, stderr) [translation:ERROR] CompilationError: <CompilationError err=' Creating library c:\\users\\flatline\\appdata\\local\\temp\\usession-default-57\\testing_1\\lib pypy-c.lib and obje...e\\appdata\\local\\temp\\usession-default-57\\testing_1\\libpypy-c.dll : fatal error LNK1120: 8 unresolved externals\n'> Thanks, Tasos On Mon, Jan 31, 2011 at 11:48 PM, Tasos Vogiatzoglou <tvoglou(a)gmail.com> wrote: > Amaury, > > Isn't there a way to fix the SSL issue? I was looking checking for > name decoration issues or call-conv issues but there seems none. > > Is there any guess why it fails from the translation procedure but > works when I execute the commands in cmd prompt ? > > (I also tried disabling the env processing that is happening, leaving > POpen to get the default one but nothing :( ) > > Thanks, > Tasos > > > > On Mon, Jan 31, 2011 at 11:44 PM, Amaury Forgeot d'Arc > <amauryfa(a)gmail.com> wrote: >> 2011/1/31 Tasos Vogiatzoglou <tvoglou(a)gmail.com>: >>> Hello Amaury, >>> >>> Yes. It's the same compiler error : >> >>> [translation:ERROR] File "c:\Users\flatline\development\pypy\src\pypy\module\_hashlib\interp_hashlib.py", >> >> Ah, indeed the _hashlib module should be disabled when openssl cannot >> be processed. >> I'll try to fix it, in the meantime I suggest you to skip this module: >> >> python translate.py targetpypystandalone --withoutmod-_hashlib >> >> >> -- >> Amaury Forgeot d'Arc >> >

6 11

Worrying set of checkins
by Maciej Fijalkowski Feb. 1, 2011

Feb. 1, 2011

Anyone feeling like looking into this: http://speed.pypy.org/changes/?tre=10&rev=41510:77f94f44989a&exe=3&env=tann… ?

2 3