From jcea at jcea.es Fri Nov 2 19:47:16 2012 From: jcea at jcea.es (Jesus Cea) Date: Fri, 02 Nov 2012 19:47:16 +0100 Subject: [pypy-dev] Solaris support is getting closer :-) Message-ID: <50941534.6070906@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have spend the afternoon trying to get pypy working on Solaris and derivaties and looks like this can be doable. Running the testsuite "translation/c/tests/", I get this: """ ===================================================== short test summary info ====================================================== FAIL test_extfunc.py::test_links FAIL test_extfunc.py::test_os_major_minor ================================= 2 failed, 768 passed, 146 skipped, 108 error in 2417.93 seconds ================================== """ Both fails look easy. The 108 errors are clustered in "newgc", I haven't investigated yet. PS: There is an openindiana (solaris derivative) buildbot too: . Make good use of it!! :) - -- Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQCVAwUBUJQVNJlgi5GaxT1NAQJy8AP/Umc5WbS6RcSxeOmu9zM4V+LwlIRnsoqm hsGtFhNTFUf3IowIvXuI5MmNnxpnBh86vfnygBu0fpu+w3DwnEosLWe3j0SQcmES I2DwJELdDSsf0PQu5WEoWLEvS+o0HkyWmduEE9Pk+scPLdUkxMCKXdnA+HKoTyX7 7rb7u7eJuQ0= =XxBH -----END PGP SIGNATURE----- From alepulver at gmail.com Fri Nov 2 21:00:20 2012 From: alepulver at gmail.com (Alejandro Pulver) Date: Fri, 02 Nov 2012 17:00:20 -0300 Subject: [pypy-dev] Excessive blocking in multiprocessing? Message-ID: <50942654.5020409@gmail.com> Hello, As part of an introductory course of computational neuroscience, we learned the basics of NLTK to analyze wikileaks. On my own, I tried PyPy 1.9 (under Ubuntu 12.04 64-bits) and a simple MapReduce scheme as an attempt to improve performance. There are 14266 files under "cable", adding up to 1.2GB. It can be downloaded as a 30MB compressed 7z here: http://www.dc.uba.ar/materias/incc/practicas/p2/nltk/wikis.7z The results are: $ time python test_mapreduce.py 170686 python test_mapreduce.py 1897.59s user 13.10s system 338% cpu 9:24.29 total $ time ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py 170685 ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py 573.78s user 15.64s system 170% cpu 5:46.41 total I find it strange that PyPy is using (about) 4 times less CPU than CPython, while only taking (about) half the time. Watching the CPU usage of my 4 cores confirms it: approximately half of the available cycles aren't used (sometimes it seems only 2 cores are used). As I'm not running another process that consumes them, I suspect PyPy is blocking for some reason (i.e. removed from the scheduling queue by waiting, or some other system call). It didn't improve by using 8 processes instead of 4. Do you think there is a problem with my code (actually, I'm new to Python)? Thanks in advance, Alejandro P.S.: please CC me because I'm not subscribed. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_mapreduce.py Type: text/x-python Size: 2591 bytes Desc: not available URL: From taavi.burns at gmail.com Fri Nov 2 22:40:07 2012 From: taavi.burns at gmail.com (Taavi Burns) Date: Fri, 2 Nov 2012 17:40:07 -0400 Subject: [pypy-dev] Excessive blocking in multiprocessing? In-Reply-To: <50942654.5020409@gmail.com> References: <50942654.5020409@gmail.com> Message-ID: <65B652F8-42AB-40F4-83F3-243AA8EAEDC2@gmail.com> I see that you're reading from the compressed zip file directly. That makes me suspect that your map/reduce is waiting for data from the single-CPU-bound job of zip decompression. Try decompressing the archive first, and make sure all the files fit into your OS' disk cache (or flush the cache between tests). -- taa /*eof*/ On 2012-11-02, at 16:00, Alejandro Pulver wrote: > Hello, > > As part of an introductory course of computational neuroscience, we > learned the basics of NLTK to analyze wikileaks. > > On my own, I tried PyPy 1.9 (under Ubuntu 12.04 64-bits) and a simple > MapReduce scheme as an attempt to improve performance. There are 14266 > files under "cable", adding up to 1.2GB. It can be downloaded as a 30MB > compressed 7z here: > http://www.dc.uba.ar/materias/incc/practicas/p2/nltk/wikis.7z > > The results are: > > $ time python test_mapreduce.py > 170686 > python test_mapreduce.py 1897.59s user 13.10s system 338% cpu 9:24.29 total > > $ time ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py > 170685 > ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py 573.78s user 15.64s > system 170% cpu 5:46.41 total > > I find it strange that PyPy is using (about) 4 times less CPU than > CPython, while only taking (about) half the time. Watching the CPU usage > of my 4 cores confirms it: approximately half of the available cycles > aren't used (sometimes it seems only 2 cores are used). As I'm not > running another process that consumes them, I suspect PyPy is blocking > for some reason (i.e. removed from the scheduling queue by waiting, or > some other system call). It didn't improve by using 8 processes instead > of 4. > > Do you think there is a problem with my code (actually, I'm new to Python)? > > Thanks in advance, > Alejandro > > P.S.: please CC me because I'm not subscribed. > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev From alepulver at gmail.com Fri Nov 2 23:36:14 2012 From: alepulver at gmail.com (Alejandro Pulver) Date: Fri, 02 Nov 2012 19:36:14 -0300 Subject: [pypy-dev] Excessive blocking in multiprocessing? In-Reply-To: <65B652F8-42AB-40F4-83F3-243AA8EAEDC2@gmail.com> References: <50942654.5020409@gmail.com> <65B652F8-42AB-40F4-83F3-243AA8EAEDC2@gmail.com> Message-ID: <50944ADE.5080801@gmail.com> On 11/02/2012 06:40 PM, Taavi Burns wrote: > I see that you're reading from the compressed zip file directly. That makes me suspect that your map/reduce is waiting for data from the single-CPU-bound job of zip decompression. > > Try decompressing the archive first, and make sure all the files fit into your OS' disk cache (or flush the cache between tests). Sorry for the confusion. I've also been testing that version (which actually runs a minute faster for CPython), but the times in my previous mail are from "test1" which reads from disk files. Also note that the zip is a 300MB file I created from the extracted files, not the 30MB 7z which would probably take too long to extract on the fly. Regards, Alejandro From alepulver at gmail.com Sat Nov 3 00:02:39 2012 From: alepulver at gmail.com (Alejandro Pulver) Date: Fri, 02 Nov 2012 20:02:39 -0300 Subject: [pypy-dev] Excessive blocking in multiprocessing? In-Reply-To: <50944ADE.5080801@gmail.com> References: <50942654.5020409@gmail.com> <65B652F8-42AB-40F4-83F3-243AA8EAEDC2@gmail.com> <50944ADE.5080801@gmail.com> Message-ID: <5094510F.7010109@gmail.com> On 11/02/2012 07:36 PM, Alejandro Pulver wrote: > On 11/02/2012 06:40 PM, Taavi Burns wrote: >> I see that you're reading from the compressed zip file directly. That makes me suspect that your map/reduce is waiting for data from the single-CPU-bound job of zip decompression. >> >> Try decompressing the archive first, and make sure all the files fit into your OS' disk cache (or flush the cache between tests). > Sorry for the confusion. I've also been testing that version (which > actually runs a minute faster for CPython), but the times in my previous > mail are from "test1" which reads from disk files. > > Also note that the zip is a 300MB file I created from the extracted > files, not the 30MB 7z which would probably take too long to extract on > the fly. > Well, now that I mention it, there is something strange in these results as well (using "test2", the version which reads from a ZIP archive): $ time python test_mapreduce.py 170686 python test_mapreduce.py 1869.19s user 11.44s system 357% cpu 8:46.44 total $ time ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py 170685 ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py 889.64s user 15.32s system 182% cpu 8:17.20 total So CPython seems to runs faster without consuming more CPU (which is strange since it's decompressing). And PyPy is taking about twice as before. In an earlier version, I used a global variable for opening the zip, and used it from "func_map"; CPython worked the same, but PyPy consumed all my RAM and ran faster (instead of slower like the previous result shows). BTW, the result is different between CPython and PyPy (counts one word less). This might point to a bug. Regards, Alejandro From fijall at gmail.com Sat Nov 3 14:47:42 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sat, 3 Nov 2012 15:47:42 +0200 Subject: [pypy-dev] Excessive blocking in multiprocessing? In-Reply-To: <5094510F.7010109@gmail.com> References: <50942654.5020409@gmail.com> <65B652F8-42AB-40F4-83F3-243AA8EAEDC2@gmail.com> <50944ADE.5080801@gmail.com> <5094510F.7010109@gmail.com> Message-ID: On Sat, Nov 3, 2012 at 1:02 AM, Alejandro Pulver wrote: > On 11/02/2012 07:36 PM, Alejandro Pulver wrote: >> On 11/02/2012 06:40 PM, Taavi Burns wrote: >>> I see that you're reading from the compressed zip file directly. That makes me suspect that your map/reduce is waiting for data from the single-CPU-bound job of zip decompression. >>> >>> Try decompressing the archive first, and make sure all the files fit into your OS' disk cache (or flush the cache between tests). >> Sorry for the confusion. I've also been testing that version (which >> actually runs a minute faster for CPython), but the times in my previous >> mail are from "test1" which reads from disk files. >> >> Also note that the zip is a 300MB file I created from the extracted >> files, not the 30MB 7z which would probably take too long to extract on >> the fly. >> > Well, now that I mention it, there is something strange in these results > as well (using "test2", the version which reads from a ZIP archive): > > $ time python test_mapreduce.py > 170686 > python test_mapreduce.py 1869.19s user 11.44s system 357% cpu 8:46.44 total > > $ time ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py > 170685 > ~/Downloads/pypy-1.9/bin/pypy test_mapreduce.py 889.64s user 15.32s > system 182% cpu 8:17.20 total > > So CPython seems to runs faster without consuming more CPU (which is > strange since it's decompressing). And PyPy is taking about twice as before. > In an earlier version, I used a global variable for opening the zip, and > used it from "func_map"; CPython worked the same, but PyPy consumed all > my RAM and ran faster (instead of slower like the previous result shows). > > BTW, the result is different between CPython and PyPy (counts one word > less). This might point to a bug. > > Regards, > Alejandro > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev I guess one thing I can say is that without looking at your algorithm it's impossible to say. PyPy will spend more time pickling and unpickling (since it's slower) but might be way faster at the actual processing. This might lead to different time reports (as the message transport time will be higher). For what is worth, maybe you should stop using multiprocessing (it's a giant hack) and use explicit socket-based communication? I suggest using something like twisted or execnet. You'll end up with a cleaner model and likely with a faster solution. Since the data is mostly read-only, you can also just run completely separate processes that mmap the same data. Cheers, fijal From alepulver at gmail.com Sat Nov 3 16:04:51 2012 From: alepulver at gmail.com (Alejandro Pulver) Date: Sat, 03 Nov 2012 12:04:51 -0300 Subject: [pypy-dev] Excessive blocking in multiprocessing? In-Reply-To: References: <50942654.5020409@gmail.com> <65B652F8-42AB-40F4-83F3-243AA8EAEDC2@gmail.com> <50944ADE.5080801@gmail.com> <5094510F.7010109@gmail.com> Message-ID: <50953293.5070803@gmail.com> On 11/03/2012 10:47 AM, Maciej Fijalkowski wrote: > > I guess one thing I can say is that without looking at your algorithm > it's impossible to say. The complete program is part of my first mail (there are two functions: "test1" and "test2", for individual files and zip, respectively). I've attached it again. > PyPy will spend more time pickling and unpickling (since it's slower) > but might be way faster at the actual processing. This might lead to > different time reports (as the message transport time will be higher). I see. But this still doesn't explain the difference between using many files and one big zip. Anyways the most important issue for me is the one mentioned in the original mail: the fact that the PyPy processes wait half of the time, while CPython runs (i.e.: PyPy could run faster in "wall clock" time than it is). > > For what is worth, maybe you should stop using multiprocessing (it's a > giant hack) and use explicit socket-based communication? I suggest > using something like twisted or execnet. You'll end up with a cleaner > model and likely with a faster solution. > > Since the data is mostly read-only, you can also just run completely > separate processes that mmap the same data. > > Cheers, > fijal I agree with you about multiprocessing and using explicit communication. The main reason to do this was to show some of my colleagues the difference between parallelism and concurrency, and that the first can be used without the latter (even if it's implemented using it), that's why I chose multiprocessing. I'll try to write (or Google) a MapReduce scheme as you suggested; in the zip case, I'll have to find a way to share cached pieces of the file (or mmap it to memory and share across processes, as you suggested). Thanks, Alejandro -------------- next part -------------- A non-text attachment was scrubbed... Name: test_mapreduce.py Type: text/x-python Size: 2591 bytes Desc: not available URL: From cfbolz at gmx.de Tue Nov 6 03:59:17 2012 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 05 Nov 2012 19:59:17 -0700 Subject: [pypy-dev] [pypy-commit] pypy default: Do sign checks directly. In-Reply-To: <20121105224302.A04EA1C0558@cobra.cs.uni-duesseldorf.de> References: <20121105224302.A04EA1C0558@cobra.cs.uni-duesseldorf.de> Message-ID: <50987D05.1040204@gmx.de> Hi Stian, Could the sign check be please put into a nice helper method on rbigint objects? I find it not so nice that longobject.py pokes around in the internals of the big integer implementation. Cheers, Carl Friedrich On 11/05/2012 03:43 PM, Stian Andreassen wrote: > Author: Stian Andreassen > Branch: > Changeset: r58761:bc1b37bec5b3 > Date: 2012-11-05 23:41 +0100 > http://bitbucket.org/pypy/pypy/changeset/bc1b37bec5b3/ > > Log: Do sign checks directly. > > diff --git a/pypy/objspace/std/longobject.py b/pypy/objspace/std/longobject.py > --- a/pypy/objspace/std/longobject.py > +++ b/pypy/objspace/std/longobject.py > @@ -251,7 +251,7 @@ > > def pow__Long_Long_Long(space, w_long1, w_long2, w_long3): > # XXX need to replicate some of the logic, to get the errors right > - if w_long2.num.lt(rbigint.fromint(0)): > + if w_long2.num.sign < 0: > raise OperationError( > space.w_TypeError, > space.wrap( > @@ -265,7 +265,7 @@ > > def pow__Long_Long_None(space, w_long1, w_long2, w_long3): > # XXX need to replicate some of the logic, to get the errors right > - if w_long2.num.lt(rbigint.fromint(0)): > + if w_long2.num.sign < 0: > raise FailedToImplementArgs( > space.w_ValueError, > space.wrap("long pow() too negative")) > @@ -288,7 +288,7 @@ > > def lshift__Long_Long(space, w_long1, w_long2): > # XXX need to replicate some of the logic, to get the errors right > - if w_long2.num.lt(rbigint.fromint(0)): > + if w_long2.num.sign < 0: > raise OperationError(space.w_ValueError, > space.wrap("negative shift count")) > try: > @@ -300,7 +300,7 @@ > > def rshift__Long_Long(space, w_long1, w_long2): > # XXX need to replicate some of the logic, to get the errors right > - if w_long2.num.lt(rbigint.fromint(0)): > + if w_long2.num.sign < 0: > raise OperationError(space.w_ValueError, > space.wrap("negative shift count")) > try: > _______________________________________________ > pypy-commit mailing list > pypy-commit at python.org > http://mail.python.org/mailman/listinfo/pypy-commit > From estama at gmail.com Wed Nov 7 18:25:50 2012 From: estama at gmail.com (Eleytherios Stamatogiannakis) Date: Wed, 07 Nov 2012 19:25:50 +0200 Subject: [pypy-dev] Questions about CFFI and JITted callbacks In-Reply-To: <50987D05.1040204@gmx.de> References: <20121105224302.A04EA1C0558@cobra.cs.uni-duesseldorf.de> <50987D05.1040204@gmx.de> Message-ID: <509A999E.3080609@gmail.com> Hello, I have some questions: - From what i understand, right now when a python function is called through a callback, the JIT compiler does not notice it, so it doesn't JIT the function at all. So is it possible to specify that some python function should always be JITted? - Is CFFI going to be integrated inside pypy? - Will CFFI support JITted callbacks? As you understand from above questions, my main remaining problem with pypy, is JITted callbacks. Best regards, lefteris. From arigo at tunes.org Wed Nov 7 19:24:24 2012 From: arigo at tunes.org (Armin Rigo) Date: Wed, 7 Nov 2012 19:24:24 +0100 Subject: [pypy-dev] Questions about CFFI and JITted callbacks In-Reply-To: <509A999E.3080609@gmail.com> References: <20121105224302.A04EA1C0558@cobra.cs.uni-duesseldorf.de> <50987D05.1040204@gmx.de> <509A999E.3080609@gmail.com> Message-ID: Hi Eleytherios, On Wed, Nov 7, 2012 at 6:25 PM, Eleytherios Stamatogiannakis wrote: > - From what i understand, right now when a python function is called through > a callback, the JIT compiler does not notice it, so it doesn't JIT the > function at all. So is it possible to specify that some python function > should always be JITted? No, It works better than that, but still not as well as it could. Right now, the Python function used as a callback will be JITted; but the problem is that it will only be JITted at the point of entering the Python function. What goes on before and after the actual call to the Python function is not JITted. So for example if your callback is of type "int callback(int)", then when called, it will go via libffi's callback mechanism (1st indirection), wrap the int argument in a W_IntObject (2nd indirection), and only then call the Python function (which will invoke JITted code). > - Is CFFI going to be integrated inside pypy? Yes. Right now only the "_cffi_backend" module is part of a recent "pypy" binary. We will also include the pure Python part of CFFI inside the next PyPy release, 2.0. > - Will CFFI support JITted callbacks? The situation described above will probably not be improved in time for the upcoming "2.0 beta", but some time later. A bient?t, Armin. From arigo at tunes.org Wed Nov 7 20:18:54 2012 From: arigo at tunes.org (Armin Rigo) Date: Wed, 7 Nov 2012 20:18:54 +0100 Subject: [pypy-dev] Is cffi fixed for win32? In-Reply-To: <50998708.8070303@gmail.com> References: <50998708.8070303@gmail.com> Message-ID: Hi Matti, hi all, On Tue, Nov 6, 2012 at 10:54 PM, Matti Picus wrote: > Are there anymore failing win32 tests for cffi, or is cffi fully supported > for windows now? There are no failure left from test_c, and running (manually) the full test suite from "cffi/testing" mostly passes now. The remaining issues don't show any serious problem. So CFFI seems to work on PyPy on Windows now :-) A bient?t, Armin. From fijall at gmail.com Thu Nov 8 09:19:48 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 8 Nov 2012 10:19:48 +0200 Subject: [pypy-dev] Is cffi fixed for win32? In-Reply-To: References: <50998708.8070303@gmail.com> Message-ID: On Wed, Nov 7, 2012 at 9:18 PM, Armin Rigo wrote: > Hi Matti, hi all, > > On Tue, Nov 6, 2012 at 10:54 PM, Matti Picus wrote: >> Are there anymore failing win32 tests for cffi, or is cffi fully supported >> for windows now? > > There are no failure left from test_c, and running (manually) the full > test suite from "cffi/testing" mostly passes now. The remaining > issues don't show any serious problem. So CFFI seems to work on PyPy > on Windows now :-) > > > A bient?t, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev cool :) From wiktor8010 at gmail.com Sat Nov 10 10:18:58 2012 From: wiktor8010 at gmail.com (Wiktor Mizdal) Date: Sat, 10 Nov 2012 10:18:58 +0100 Subject: [pypy-dev] pypy 2.0 Message-ID: When we will expect Pypy 2.0 release? From support at downloadroute.com Sun Nov 11 15:30:05 2012 From: support at downloadroute.com (DownloadRoute.com) Date: Sun, 11 Nov 2012 09:30:05 -0500 Subject: [pypy-dev] PyPy security report Message-ID: Hello, We would like to inform you that your program PyPy 1.9 has successfully passed antivirus and antispyware tests and were so impressed that we decided to give you our 100% CLEAN award! We use for scanning now four of the best antivirus engines available on the market. Place the following ready-to-use HTML code on your website to increase the trust for your program and let your visitors know that is Virus Free. You can use text version or image version (with your software name), both linking to your program details: Graphics award: PyPy - 100% Safe granted by DownloadRoute.com You must know that we've created the brand new and *absolutely real reports*. Other sites usually offers only fake awards. You may check your security reports on this URL: http://www.downloadroute.com/PyPy-PyPy-Development-Team/antivirus_report.html If you have any questions, don't hesitate to contact us. Best Regards, George Zubor - Senior Editor --------------------------------- e-mail: support at downloadroute.com web: http://www.downloadroute.com --------------------------------- Download Route is one of the biggest software archives on the internet with more than 73.500 software titles in archive. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: downloadroute_clean_award.png Type: image/png Size: 6320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: header.png Type: image/png Size: 11249 bytes Desc: not available URL: From editor at downloadatlas.com Sun Nov 11 15:20:02 2012 From: editor at downloadatlas.com (Vera Zubor - DownloadAtlas.com) Date: Sun, 11 Nov 2012 09:20:02 -0500 Subject: [pypy-dev] PyPy is 100% trusted ! Message-ID: <094a57154026536d31847bbf6c1169a4@saturn.euronetix.com> November 11, 2012 PyPy Development Team, we have done your NEW complete security tests. To assure our users that PyPy is clean and safe to install, we awarded your software with our DownloadAtlas.com *100% Safe Award*. If you want to notify your users about this certification, you can display this award on your website. You can visit now the awards section within our website and pick your award banner from there: http://www.downloadatlas.com/open-source-eac5cece.html Please, login for instructions. http://user.downloadatlas.com/?account=pypy-dev at python.org That's all for today. Cheers, Vera Zubor - webmaster e-mail: editor at downloadatlas.com ----------------------------------------------------------------------------------------------------------------------- To unsubscribe or change options please login to your account using email address pypy-dev at python.org or click here : http://user.downloadatlas.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trusted.png Type: image/png Size: 5815 bytes Desc: not available URL: From arigo at tunes.org Sun Nov 11 16:29:30 2012 From: arigo at tunes.org (Armin Rigo) Date: Sun, 11 Nov 2012 16:29:30 +0100 Subject: [pypy-dev] PyPy security report In-Reply-To: References: Message-ID: Hi, This was a spam, obviously. (Or if not, I will still consider it as such.) Sorry everybody that it went through the filters. A bient?t, Armin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From papito.dit at gmail.com Sun Nov 11 18:37:50 2012 From: papito.dit at gmail.com (Michael Sioutis) Date: Sun, 11 Nov 2012 18:37:50 +0100 Subject: [pypy-dev] Any publications regarding PyPy / trace-based JIT compiler? In-Reply-To: References: Message-ID: Hello all! I just wanted to inform the PyPy team that my paper got accepted in ICTAI 2012 , and I presented it a few days ago. You can find the paper hereand the presentation here . It felt good to disseminate a bit Python and PyPy :) My next (long term) step is to use PyPy to parallelize some graph operations. Regards, Mike On Tue, Jul 3, 2012 at 11:28 PM, Michael Sioutis wrote: > Dear PyPy team, > > I am in the process of writing a paper that will target some AI > conference, and I would like > to ask if there are any relevant publications of yours or in general that > showcase the possible advantages > of trace-based JIT compilation over method-based JIT compilation or static > compilation. > > I just want to use 2 or 3 of them as references when I explain why my > implementation is more scalable > and robust when compared to some C/C++/Java implementations (appart from > different data structures and > algorithms). > > Thank you :) > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at nyk.ch Tue Nov 13 02:26:21 2012 From: lists at nyk.ch (Nick Fankhauser) Date: Tue, 13 Nov 2012 02:26:21 +0100 Subject: [pypy-dev] pypq in RPython Message-ID: <50A1A1BD.3070306@nyk.ch> Hi! I'm trying to compile one of my python applications using "translate.py". Because the application needs access to postgreSQL, it's using pypq. The application runs fine in python, and pypy as well. Using the error messages from translate.py, I made a lot of changes to my program to make it as much RPython as I can make it. But even after changing the code many, many times, I never get past the following error message. It's from pypq and I'm not sure what command in my application triggers the error, but by looking at the pypq source, I assume it's from a pypq-"commit" command. My questions are: - Is it even possible to use pypq in RPython? - If not, is there any other postgreSQL adapter that works? - Is there example-code for connecting to a database in RPython? - Is it possible to find the command in my application that triggered the error? Thanks! This is the error message: [translation:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/opt/pypy_source/pypy/translator/goal/translate.py", line 303, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/opt/pypy_source/pypy/translator/driver.py", line 771, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/opt/pypy_source/pypy/translator/tool/taskengine.py", line 116, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/opt/pypy_source/pypy/translator/driver.py", line 283, in _do [translation:ERROR] res = func() [translation:ERROR] File "/opt/pypy_source/pypy/translator/driver.py", line 319, in task_annotate [translation:ERROR] s = annotator.build_types(self.entry_point, self.inputtypes) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 89, in build_types [translation:ERROR] return self.build_graph_types(flowgraph, inputcells, complete_now=complete_now) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 142, in build_graph_types [translation:ERROR] self.complete() [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 195, in complete [translation:ERROR] self.processblock(graph, block) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 340, in processblock [translation:ERROR] self.flowin(graph, block) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 399, in flowin [translation:ERROR] self.consider_op(block, i) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 577, in consider_op [translation:ERROR] argcells = [self.binding(a) for a in op.args] [translation:ERROR] File "/opt/pypy_source/pypy/annotation/annrpython.py", line 238, in binding [translation:ERROR] return self.bookkeeper.immutableconstant(arg) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/bookkeeper.py", line 314, in immutableconstant [translation:ERROR] return self.immutablevalue(const.value) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/bookkeeper.py", line 461, in immutablevalue [translation:ERROR] result = SomePBC([self.getdesc(x)]) [translation:ERROR] File "/opt/pypy_source/pypy/annotation/bookkeeper.py", line 535, in getdesc [translation:ERROR] raise Exception("%s: %r" % (msg, pyobj)) [translation:ERROR] Exception: object with a __call__ is not RPython: <_ctypes.function.CFuncPtrFast object at 0x000000001f11b6a0> [translation:ERROR] Processing block: [translation:ERROR] block at 9 is a [translation:ERROR] in (pypq.connection:68)Connection._get_transaction_status [translation:ERROR] containing the following operations: [translation:ERROR] v0 = getattr(self_0, ('_db')) [translation:ERROR] v1 = simple_call((CFuncPtrFast PQtransactionStatus), v0) [translation:ERROR] --end-- [translation] start debugger... > /opt/pypy_source/pypy/annotation/bookkeeper.py(535)getdesc() -> raise Exception("%s: %r" % (msg, pyobj)) My program is structured like this in respect to database access: database_connection=pypq.connect('connect_string') def foo(): dbc=database_connection.cursor() dbc.execute('SELECT what,val FROM some_table') some_dict={} for w,v in dbc.fetchall(): some_dict[w]=v dbc.close() return some_dict def maincode(args): Some code, which call foo, among other functions. def target(driver,args): return maincode,None From william.leslie.ttg at gmail.com Tue Nov 13 04:03:53 2012 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Tue, 13 Nov 2012 14:03:53 +1100 Subject: [pypy-dev] pypq in RPython In-Reply-To: <50A1A1BD.3070306@nyk.ch> References: <50A1A1BD.3070306@nyk.ch> Message-ID: On 13/11/2012, Nick Fankhauser wrote: > Hi! > > I'm trying to compile one of my python applications using "translate.py". > Because the application needs access to postgreSQL, it's using pypq. The > application runs fine in python, and pypy as well. > Using the error messages from translate.py, I made a lot of changes to > my program to make it as much RPython as I can make it. > > But even after changing the code many, many times, I never get past the > following error message. It's from pypq and I'm not sure what command in > my application triggers the error, but by looking at the pypq source, I > assume it's from a pypq-"commit" command. The pypy translation toolchain has never been intended to support translation of end-user programs. If at all possible, use the pypy python interpreter. It's often faster than rpython for real-world code, and a lot easier to use, too. > My questions are: > - Is it even possible to use pypq in RPython? No, it uses ctypes, which is only available at app-level. > - If not, is there any other postgreSQL adapter that works? No, you will have to use a low-level C interface; there are examples of this in pypy/modules. (I think this answers the remaining questions.) -- William Leslie From arigo at tunes.org Wed Nov 14 10:46:37 2012 From: arigo at tunes.org (Armin Rigo) Date: Wed, 14 Nov 2012 10:46:37 +0100 Subject: [pypy-dev] pypy 2.0 In-Reply-To: References: Message-ID: Hi Wiktor, On Sat, Nov 10, 2012 at 10:18 AM, Wiktor Mizdal wrote: > When we will expect Pypy 2.0 release? PyPy 2.0 beta 1 is going out any day now (maybe today). PyPy 2.0 final is still open. A bient?t, Armin. From phyo.arkarlwin at gmail.com Wed Nov 14 13:41:23 2012 From: phyo.arkarlwin at gmail.com (Phyo Arkar) Date: Wed, 14 Nov 2012 19:11:23 +0630 Subject: [pypy-dev] pypy 2.0 In-Reply-To: References: Message-ID: I can't wait the day that u guys implement STM . That will really change python :) and will make it only language that have STM , Right? On Wed, Nov 14, 2012 at 4:16 PM, Armin Rigo wrote: > Hi Wiktor, > > On Sat, Nov 10, 2012 at 10:18 AM, Wiktor Mizdal > wrote: > > When we will expect Pypy 2.0 release? > > PyPy 2.0 beta 1 is going out any day now (maybe today). > > PyPy 2.0 final is still open. > > > A bient?t, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kracethekingmaker at gmail.com Wed Nov 14 13:48:57 2012 From: kracethekingmaker at gmail.com (kracekumar ramaraju) Date: Wed, 14 Nov 2012 18:18:57 +0530 Subject: [pypy-dev] pypy 2.0 In-Reply-To: References: Message-ID: I can't wait the day that u guys implement STM . That will really change > python :) and will make it only language that have STM , Right? > > I don't think so Haskell already have one - http://www.haskell.org/haskellwiki/Software_transactional_memory According to wikipedia page - http://en.wikipedia.org/wiki/Software_transactional_memory clojure, c#, c++, Java, scala etc already have STM, but I have no clue how they are currently implemented/used/maintained. > > On Wed, Nov 14, 2012 at 4:16 PM, Armin Rigo wrote: > >> Hi Wiktor, >> >> On Sat, Nov 10, 2012 at 10:18 AM, Wiktor Mizdal >> wrote: >> > When we will expect Pypy 2.0 release? >> >> PyPy 2.0 beta 1 is going out any day now (maybe today). >> >> PyPy 2.0 final is still open. >> >> >> A bient?t, >> >> Armin. >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> http://mail.python.org/mailman/listinfo/pypy-dev >> > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > > -- * Thanks & Regards "Talk is cheap, show me the code" -- Linus Torvalds kracekumar www.kracekumar.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.poster at canonical.com Wed Nov 14 14:29:38 2012 From: gary.poster at canonical.com (Gary Poster) Date: Wed, 14 Nov 2012 08:29:38 -0500 Subject: [pypy-dev] pypy 2.0 In-Reply-To: References: Message-ID: <50A39CC2.8040106@canonical.com> On 11/14/2012 07:41 AM, Phyo Arkar wrote: > I can't wait the day that u guys implement STM . That will really change > python :) and will make it only language that have STM , Right? Clojure has it built in. I think Haskell folks would argue that the having it in the Haskell Platform is pretty darn close to having it in their language. http://en.wikipedia.org/wiki/Software_transactional_memory seems to show only libraries otherwise. Gary > > > On Wed, Nov 14, 2012 at 4:16 PM, Armin Rigo > wrote: > > Hi Wiktor, > > On Sat, Nov 10, 2012 at 10:18 AM, Wiktor Mizdal > > wrote: > > When we will expect Pypy 2.0 release? > > PyPy 2.0 beta 1 is going out any day now (maybe today). > > PyPy 2.0 final is still open. > > > A bient?t, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > > > > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > From cfbolz at gmx.de Fri Nov 16 16:19:48 2012 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 16 Nov 2012 08:19:48 -0700 Subject: [pypy-dev] [pypy-commit] pypy default: INSTANCE_PTR_{EQ, NE} also do not escape their arguments in the JIT In-Reply-To: <20121116151235.C28121C1EC4@cobra.cs.uni-duesseldorf.de> References: <20121116151235.C28121C1EC4@cobra.cs.uni-duesseldorf.de> Message-ID: <497e32d9-18c2-4ffe-8b65-3b2e55b3c35a@email.android.com> Hi Alex, Please write a test for this change. Cheers, Carl Friedrich alex_gaynor wrote: >Author: Alex Gaynor >Branch: >Changeset: r58945:e72d4f5b720e >Date: 2012-11-16 07:11 -0800 >http://bitbucket.org/pypy/pypy/changeset/e72d4f5b720e/ > >Log: INSTANCE_PTR_{EQ,NE} also do not escape their arguments in the JIT > >diff --git a/pypy/jit/metainterp/heapcache.py >b/pypy/jit/metainterp/heapcache.py >--- a/pypy/jit/metainterp/heapcache.py >+++ b/pypy/jit/metainterp/heapcache.py >@@ -74,7 +74,9 @@ > elif (opnum != rop.GETFIELD_GC and > opnum != rop.MARK_OPAQUE_PTR and > opnum != rop.PTR_EQ and >- opnum != rop.PTR_NE): >+ opnum != rop.PTR_NE and >+ opnum != rop.INSTANCE_PTR_EQ and >+ opnum != rop.INSTANCE_PTR_NE): > idx = 0 > for box in argboxes: > # setarrayitem_gc don't escape its first argument >_______________________________________________ >pypy-commit mailing list >pypy-commit at python.org >http://mail.python.org/mailman/listinfo/pypy-commit Carl Friedrich Bolz -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at python.org Mon Nov 19 16:09:04 2012 From: brian at python.org (Brian Curtin) Date: Mon, 19 Nov 2012 09:09:04 -0600 Subject: [pypy-dev] New Contributor Experience in Python and other FOSS Communities - A Survey Message-ID: Hi all, [note - this was originally sent to a few CPython places, but I told the surveyor that we should include the many new PyPy contributors as well, and he agreed] Along with a number of other free and open communities, Python is being included in a survey of new contributors since January 2010. The survey is being done by Kevin Carillo, a PhD student at Victoria University of Wellington who is studying various approaches that projects use to gain and work with new contributors. If you have written patches, reviewed issues, or done anything to contribute to the development of Python and you started this after January 2010, I hope you can spare around 20 minutes to complete this survey: https://limesurvey.sim.vuw.ac.nz/index.php?sid=65151&lang=en There's a longer blog post up at http://blog.python.org/2012/11/new-contributor-experience-in-python.html if you would like a bit more information. On behalf of Kevin Carillo, I thank you for your time and consideration of this survey. Thank, Brian Curtin From fijall at gmail.com Thu Nov 22 12:54:00 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 22 Nov 2012 12:54:00 +0100 Subject: [pypy-dev] PyPy 2.0 beta 1 released Message-ID: We're pleased to announce the 2.0 beta 1 release of PyPy. This release is not a typical beta, in a sense the stability is the same or better than 1.9 and can be used in production. It does however include a few performance regressions documented below that don't allow us to label is as 2.0 final. (It also contains many performance improvements.) The main features of this release are support for ARM processor and compatibility with CFFI. It also includes numerous improvements to the numpy in pypy effort, cpyext and performance. You can download the PyPy 2.0 beta 1 release here: http://pypy.org/download.html What is PyPy? ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7.3. It's fast (`pypy 2.0 beta 1 and cpython 2.7.3`_ performance comparison) due to its integrated tracing JIT compiler. This release supports x86 machines running Linux 32/64, Mac OS X 64 or Windows 32. It also supports ARM machines running Linux. Windows 64 work is still stalling, we would welcome a volunteer to handle that. .. _`pypy 2.0 beta 1 and cpython 2.7.3`: http://bit.ly/USXqpP How to use PyPy? ================ We suggest using PyPy from a `virtualenv`_. Once you have a virtualenv installed, you can follow instructions from `pypy documentation`_ on how to proceed. This document also covers other `installation schemes`_. .. _`pypy documentation`: http://doc.pypy.org/en/latest/getting-started.html#installing-using-virtualenv .. _`virtualenv`: http://www.virtualenv.org/en/latest/ .. _`installation schemes`: http://doc.pypy.org/en/latest/getting-started.html#installing-pypy .. _`PyPy and pip`: http://doc.pypy.org/en/latest/getting-started.html#installing-pypy Regressions =========== Reasons why this is not PyPy 2.0: * the ``ctypes`` fast path is now slower than it used to be. In PyPy 1.9 ``ctypes`` was either incredibly faster or slower than CPython depending whether you hit the fast path or not. Right now it's usually simply slower. We're probably going to rewrite ``ctypes`` using ``cffi``, which will make it universally faster. * ``cffi`` (an alternative to interfacing with C code) is very fast, but it is missing one optimization that will make it as fast as a native call from C. * ``numpypy`` lazy computation was disabled for the sake of simplicity. We should reenable this for the final 2.0 release. Highlights ========== * ``cffi`` is officially supported by PyPy. You can install it normally by using ``pip install cffi`` once you have installed `PyPy and pip`_. The corresponding ``0.4`` version of ``cffi`` has been released. * ARM is now an officially supported processor architecture. PyPy now work on soft-float ARM/Linux builds. Currently ARM processors supporting the ARMv7 and later ISA that include a floating-point unit are supported. * This release contains the latest Python standard library 2.7.3 and is fully compatible with Python 2.7.3. * It does not however contain hash randomization, since the solution present in CPython is not solving the problem anyway. The reason can be found on the `CPython issue tracker`_. * ``gc.get_referrers()`` is now faster. * Various numpy improvements. The list includes: * axis argument support in many places * full support for fancy indexing * ``complex128`` and ``complex64`` dtypes * `JIT hooks`_ are now a powerful tool to introspect the JITting process that PyPy performs. * ``**kwds`` usage is much faster in the typical scenario * operations on ``long`` objects are now as fast as in CPython (from roughly 2x slower) * We now have special strategies for ``dict``/``set``/``list`` which contain unicode strings, which means that now such collections will be both faster and more compact. .. _`cpython issue tracker`: http://bugs.python.org/issue14621 .. _`jit hooks`: http://doc.pypy.org/en/latest/jit-hooks.html Things we're working on ======================= There are a few things that did not make it to the 2.0 beta 1, which are being actively worked on. Greenlets support in the JIT is one that we would like to have before 2.0 final. Two important items that will not make it to 2.0, but are being actively worked on, are: * Faster JIT warmup time. * Software Transactional Memory. Cheers, Maciej Fijalkowski, Armin Rigo and the PyPy team From max.lavrenov at gmail.com Fri Nov 23 12:43:33 2012 From: max.lavrenov at gmail.com (Max Lavrenov) Date: Fri, 23 Nov 2012 14:43:33 +0300 Subject: [pypy-dev] problem with twisted in current pypy master Message-ID: Hello everyone I had got this error while installed twisted. I just built pypy from master, made virtual enviroment and pip install twisted. Traceback (most recent call last): File "app_main.py", line 51, in run_toplevel File "app_main.py", line 547, in run_it File "", line 1, in File "/home/e-max/.virtualenvs/pypy/build/twisted/setup.py", line 82, in main(sys.argv[1:]) File "/home/e-max/.virtualenvs/pypy/build/twisted/setup.py", line 77, in main setup(**setup_args) File "./twisted/python/dist.py", line 58, in setup return core.setup(**get_setup_args(**kw)) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/core.py", line 152, in setup dist.run_commands() File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/home/e-max/.virtualenvs/pypy/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/install.py", line 56, in run return _install.run(self) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/command/install.py", line 584, in run self.run_command(cmd_name) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/home/e-max/.virtualenvs/pypy/site-packages/setuptools-0.6c11-py2.7.egg/setuptools/command/install_lib.py", line 24, in run self.byte_compile(outfiles) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/command/install_lib.py", line 138, in byte_compile dry_run=self.dry_run) File "/home/e-max/workspace/pypy/lib-python/2.7/distutils/util.py", line 559, in byte_compile compile(file, cfile, dfile) File "/home/e-max/workspace/pypy/lib-python/2.7/py_compile.py", line 126, in compile marshal.dump(codeobject, fc) UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in position 0: surrogates not allowed Best regards, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Fri Nov 23 13:04:29 2012 From: arigo at tunes.org (Armin Rigo) Date: Fri, 23 Nov 2012 13:04:29 +0100 Subject: [pypy-dev] problem with twisted in current pypy master In-Reply-To: References: Message-ID: Hi Max, On Fri, Nov 23, 2012 at 12:43 PM, Max Lavrenov wrote: > marshal.dump(codeobject, fc) > UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in position 0: surrogates not allowed Works for me. Could you please: * open a bug on https://bugs.pypy.org/, reporting the platform too (Linux? OS/X?) * try to debug it with pdb, in case we cannot reproduce it: what arguments are passed to marshal.dump()? A bient?t, Armin. From amauryfa at gmail.com Fri Nov 23 13:32:21 2012 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 23 Nov 2012 13:32:21 +0100 Subject: [pypy-dev] problem with twisted in current pypy master In-Reply-To: References: Message-ID: 2012/11/23 Armin Rigo > Hi Max, > > On Fri, Nov 23, 2012 at 12:43 PM, Max Lavrenov > wrote: > > marshal.dump(codeobject, fc) > > UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in > position 0: surrogates not allowed > > Works for me. Could you please: > > * open a bug on https://bugs.pypy.org/, reporting the platform too > (Linux? OS/X?) > > * try to debug it with pdb, in case we cannot reproduce it: what > arguments are passed to marshal.dump()? > Also, which version of pypy are you using? (From a hg repo, you can do "hg id") A similar bug was fixed one month ago: https://bugs.pypy.org/issue1285 (with the exact same character!) -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lavrenov at gmail.com Fri Nov 23 15:07:44 2012 From: max.lavrenov at gmail.com (Max Lavrenov) Date: Fri, 23 Nov 2012 18:07:44 +0400 Subject: [pypy-dev] problem with twisted in current pypy master In-Reply-To: References: Message-ID: Hello Amaury [e-max at e-max pypy]$ hg id ded8ea86de4b [e-max at e-max pypy]$ hg log -v -r ded8ea86de4b ????? ?????????: 59040:ded8ea86de4b ????????????: Armin Rigo ????: Thu Nov 22 23:37:52 2012 +0100 ?????: pypy/config/translationoption.py ????????: Kill these options. They are not used anywhere else in the code :-( On Fri, Nov 23, 2012 at 4:32 PM, Amaury Forgeot d'Arc wrote: > 2012/11/23 Armin Rigo > >> Hi Max, >> >> On Fri, Nov 23, 2012 at 12:43 PM, Max Lavrenov >> wrote: >> > marshal.dump(codeobject, fc) >> > UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in >> position 0: surrogates not allowed >> >> Works for me. Could you please: >> >> * open a bug on https://bugs.pypy.org/, reporting the platform too >> (Linux? OS/X?) >> >> * try to debug it with pdb, in case we cannot reproduce it: what >> arguments are passed to marshal.dump()? >> > > > Also, which version of pypy are you using? (From a hg repo, you can do "hg > id") > A similar bug was fixed one month ago: https://bugs.pypy.org/issue1285 (with > the exact same character!) > > -- > Amaury Forgeot d'Arc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lavrenov at gmail.com Fri Nov 23 15:25:50 2012 From: max.lavrenov at gmail.com (Max Lavrenov) Date: Fri, 23 Nov 2012 18:25:50 +0400 Subject: [pypy-dev] problem with twisted in current pypy master In-Reply-To: References: Message-ID: I've created issue https://bugs.pypy.org/issue1335 On Fri, Nov 23, 2012 at 4:04 PM, Armin Rigo wrote: > Hi Max, > > On Fri, Nov 23, 2012 at 12:43 PM, Max Lavrenov > wrote: > > marshal.dump(codeobject, fc) > > UnicodeEncodeError: 'utf-8' codec can't encode character u'\udf42' in > position 0: surrogates not allowed > > Works for me. Could you please: > > * open a bug on https://bugs.pypy.org/, reporting the platform too > (Linux? OS/X?) > > * try to debug it with pdb, in case we cannot reproduce it: what > arguments are passed to marshal.dump()? > > > A bient?t, > > Armin. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sasikanth.ece at gmail.com Fri Nov 23 15:26:22 2012 From: sasikanth.ece at gmail.com (Sasikanth Eda) Date: Fri, 23 Nov 2012 19:56:22 +0530 Subject: [pypy-dev] Need help disutils module with PyPy Message-ID: Hi All, I am a newbie facing problem with utilization of disutils ( http://docs.python.org/2/distutils/introduction.html) module that helps in distributing python modules with PyPy. *content of demo.c:* #include #include int main (void) { printf("setup passed\n"); return 0; } *content of setup.py:* from distutils.core import setup, Extension module1 = Extension('demo', sources = ['demo.c']) setup (name = 'PackageName', version = '1.0', description = 'This is a demo package', ext_modules = [module1]) Now the problem is ; if this setup.py is compiled with Python, then I am able to successfully generate the '.so' [linux at localhost disutils_example]$ python setup.py build running build running build_ext building 'demo' extension creating build creating build/temp.linux-x86_64-2.7 gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python2.7 -c demo.c -o build/temp.linux-x86_64-2.7/demo.o creating build/lib.linux-x86_64-2.7 gcc -pthread -shared -Wl,-z,relro build/temp.linux-x86_64-2.7/demo.o -L/usr/lib64 -lpython2.7 -o build/lib.linux-x86_64-2.7/demo.so where as using PyPy, i am getting the following error [linux at localhost disutils_example]$ pypy setup.py build running build running build_ext building 'demo' extension cc -fPIC -Wimplicit -I/usr/lib64/pypy-1.9/include -c demo.c -o build/temp.linux-x86_64-2.7/demo.o demo.c:1:20: fatal error: Python.h: No such file or directory compilation terminated. error: command 'cc' failed with exit status 1 where as python-devel package which contains these header files is installed. Kindly suggest me the process to make this compile with PyPy. Thanking you, Sasikanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From amauryfa at gmail.com Fri Nov 23 15:46:54 2012 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Fri, 23 Nov 2012 15:46:54 +0100 Subject: [pypy-dev] Need help disutils module with PyPy In-Reply-To: References: Message-ID: 2012/11/23 Sasikanth Eda > [linux at localhost disutils_example]$ pypy setup.py build > running build > running build_ext > building 'demo' extension > cc -fPIC -Wimplicit -I/usr/lib64/pypy-1.9/include -c demo.c -o > build/temp.linux-x86_64-2.7/demo.o > demo.c:1:20: fatal error: Python.h: No such file or directory > compilation terminated. > error: command 'cc' failed with exit status 1 > > where as python-devel package which contains these header files is > installed. > PyPy does not use python-devel. The "Python.h" header provide the same interface, but with important differences in the implementation. There should be a "pypy-devel" package that you should install as well. -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From phyo.arkarlwin at gmail.com Fri Nov 23 16:51:39 2012 From: phyo.arkarlwin at gmail.com (Phyo Arkar) Date: Fri, 23 Nov 2012 22:21:39 +0630 Subject: [pypy-dev] PyPy 2.0 beta 1 released In-Reply-To: References: Message-ID: Hey , ARM Build! thats mean we can run Pypy in android now right? I am building my own Python for Android with required dependencies , i am gonna test pypy on android too! Thanks , good job pypy team! When do you think numpypy and pypy c extension is complete enought to support matplotlib/scipy/pylab kit (they have a lot of other C Dependencies ..) Thanks! On Thu, Nov 22, 2012 at 6:24 PM, Maciej Fijalkowski wrote: > We're pleased to announce the 2.0 beta 1 release of PyPy. This release is > not a typical beta, in a sense the stability is the same or better than 1.9 > and can be used in production. It does however include a few performance > regressions documented below that don't allow us to label is as 2.0 final. > (It also contains many performance improvements.) > > The main features of this release are support for ARM processor and > compatibility with CFFI. It also includes > numerous improvements to the numpy in pypy effort, cpyext and performance. > > You can download the PyPy 2.0 beta 1 release here: > > http://pypy.org/download.html > > What is PyPy? > ============= > > PyPy is a very compliant Python interpreter, almost a drop-in replacement > for > CPython 2.7.3. It's fast (`pypy 2.0 beta 1 and cpython 2.7.3`_ > performance comparison) due to its integrated tracing JIT compiler. > > This release supports x86 machines running Linux 32/64, Mac OS X 64 or > Windows 32. It also supports ARM machines running Linux. > Windows 64 work is still stalling, we would welcome a volunteer > to handle that. > > .. _`pypy 2.0 beta 1 and cpython 2.7.3`: http://bit.ly/USXqpP > > How to use PyPy? > ================ > > We suggest using PyPy from a `virtualenv`_. Once you have a virtualenv > installed, you can follow instructions from `pypy documentation`_ on how > to proceed. This document also covers other `installation schemes`_. > > .. _`pypy documentation`: > > http://doc.pypy.org/en/latest/getting-started.html#installing-using-virtualenv > .. _`virtualenv`: http://www.virtualenv.org/en/latest/ > .. _`installation schemes`: > http://doc.pypy.org/en/latest/getting-started.html#installing-pypy > .. _`PyPy and pip`: > http://doc.pypy.org/en/latest/getting-started.html#installing-pypy > > Regressions > =========== > > Reasons why this is not PyPy 2.0: > > * the ``ctypes`` fast path is now slower than it used to be. In PyPy > 1.9 ``ctypes`` was either incredibly faster or slower than CPython > depending whether > you hit the fast path or not. Right now it's usually simply slower. We're > probably going to rewrite ``ctypes`` using ``cffi``, which will make it > universally faster. > > * ``cffi`` (an alternative to interfacing with C code) is very fast, but > it is missing one optimization that will make it as fast as a native > call from C. > > * ``numpypy`` lazy computation was disabled for the sake of simplicity. > We should reenable this for the final 2.0 release. > > Highlights > ========== > > * ``cffi`` is officially supported by PyPy. You can install it normally by > using ``pip install cffi`` once you have installed `PyPy and pip`_. > The corresponding ``0.4`` version of ``cffi`` has been released. > > * ARM is now an officially supported processor architecture. > PyPy now work on soft-float ARM/Linux builds. Currently ARM processors > supporting the ARMv7 and later ISA that include a floating-point unit are > supported. > > * This release contains the latest Python standard library 2.7.3 and is > fully > compatible with Python 2.7.3. > > * It does not however contain hash randomization, since the solution > present > in CPython is not solving the problem anyway. The reason can be > found on the `CPython issue tracker`_. > > * ``gc.get_referrers()`` is now faster. > > * Various numpy improvements. The list includes: > > * axis argument support in many places > > * full support for fancy indexing > > * ``complex128`` and ``complex64`` dtypes > > * `JIT hooks`_ are now a powerful tool to introspect the JITting process > that > PyPy performs. > > * ``**kwds`` usage is much faster in the typical scenario > > * operations on ``long`` objects are now as fast as in CPython (from > roughly 2x slower) > > * We now have special strategies for ``dict``/``set``/``list`` which > contain > unicode strings, which means that now such collections will be both > faster > and more compact. > > .. _`cpython issue tracker`: http://bugs.python.org/issue14621 > .. _`jit hooks`: http://doc.pypy.org/en/latest/jit-hooks.html > > Things we're working on > ======================= > > There are a few things that did not make it to the 2.0 beta 1, which > are being actively worked on. Greenlets support in the JIT is one > that we would like to have before 2.0 final. Two important items that > will not make it to 2.0, but are being actively worked on, are: > > * Faster JIT warmup time. > > * Software Transactional Memory. > > Cheers, > Maciej Fijalkowski, Armin Rigo and the PyPy team > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > http://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Sat Nov 24 23:16:06 2012 From: drsalists at gmail.com (Dan Stromberg) Date: Sat, 24 Nov 2012 14:16:06 -0800 Subject: [pypy-dev] Surface-level Presentation about PyPy Message-ID: There's been some curiosity about PyPy at my local Python User Group (OCPUG), so I put together a brief, surface-level talk about PyPy, to be delivered on Tuesday evening (the 27th). If some of the more PyPy-knowledgeable people here could look it over for accuracy and omissions, that'd be awesome. It's #4 on the URL below: http://stromberg.dnsalias.org/~dstromberg/Python-Talks/ As I currently see it, the main omission at this point is how to install PyPy after building one from mercurial. I have a script I've been using for this, but I suspect there's a more official way of doing it that would be better for sharing with others. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Sun Nov 25 00:25:18 2012 From: arigo at tunes.org (Armin Rigo) Date: Sun, 25 Nov 2012 00:25:18 +0100 Subject: [pypy-dev] Surface-level Presentation about PyPy In-Reply-To: References: Message-ID: Hi Dan, On Sat, Nov 24, 2012 at 11:16 PM, Dan Stromberg wrote: > There's been some curiosity about PyPy at my local Python User Group > (OCPUG), so I put together a brief, surface-level talk about PyPy, to be > delivered on Tuesday evening (the 27th). Great :-) > If some of the more PyPy-knowledgeable people here could look it over for > accuracy and omissions, that'd be awesome. It's #4 on the URL below: PyPy 1.9 is not current any more: PyPy 2.0 beta1 is :-) Also, the danger in this kind of talk is in people confusing the two aspects of PyPy. They get from the talk "PyPy is a JIT compiler for RPython" or some similar amalgam. You should avoid mixing slides about RPython and the slide "using the JIT'd interpreter", but separate them more clearly, with a "First part" and "Second part" separation slides, for example, and insisting a bit more on the part "the second part is a PyPy that is almost a drop-in replacement for CPython", to differentiate it from RPython. A bient?t, Armin. From fijall at gmail.com Sun Nov 25 11:14:40 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 25 Nov 2012 11:14:40 +0100 Subject: [pypy-dev] PyPy 2.0 beta 1 released In-Reply-To: References: Message-ID: On Fri, Nov 23, 2012 at 4:51 PM, Phyo Arkar wrote: > Hey , > ARM Build! thats mean we can run Pypy in android now right? > I am building my own Python for Android with required dependencies , i am > gonna test pypy on android too! No, it works on ARM linux. I have no idea what it takes to make it work on Android (hopefully not much) > > Thanks , good job pypy team! > > When do you think numpypy and pypy c extension is complete enought to > support matplotlib/scipy/pylab kit (they have a lot of other C Dependencies > ..) > > Thanks! > > > On Thu, Nov 22, 2012 at 6:24 PM, Maciej Fijalkowski > wrote: >> >> We're pleased to announce the 2.0 beta 1 release of PyPy. This release is >> not a typical beta, in a sense the stability is the same or better than >> 1.9 >> and can be used in production. It does however include a few performance >> regressions documented below that don't allow us to label is as 2.0 final. >> (It also contains many performance improvements.) >> >> The main features of this release are support for ARM processor and >> compatibility with CFFI. It also includes >> numerous improvements to the numpy in pypy effort, cpyext and performance. >> >> You can download the PyPy 2.0 beta 1 release here: >> >> http://pypy.org/download.html >> >> What is PyPy? >> ============= >> >> PyPy is a very compliant Python interpreter, almost a drop-in replacement >> for >> CPython 2.7.3. It's fast (`pypy 2.0 beta 1 and cpython 2.7.3`_ >> performance comparison) due to its integrated tracing JIT compiler. >> >> This release supports x86 machines running Linux 32/64, Mac OS X 64 or >> Windows 32. It also supports ARM machines running Linux. >> Windows 64 work is still stalling, we would welcome a volunteer >> to handle that. >> >> .. _`pypy 2.0 beta 1 and cpython 2.7.3`: http://bit.ly/USXqpP >> >> How to use PyPy? >> ================ >> >> We suggest using PyPy from a `virtualenv`_. Once you have a virtualenv >> installed, you can follow instructions from `pypy documentation`_ on how >> to proceed. This document also covers other `installation schemes`_. >> >> .. _`pypy documentation`: >> >> http://doc.pypy.org/en/latest/getting-started.html#installing-using-virtualenv >> .. _`virtualenv`: http://www.virtualenv.org/en/latest/ >> .. _`installation schemes`: >> http://doc.pypy.org/en/latest/getting-started.html#installing-pypy >> .. _`PyPy and pip`: >> http://doc.pypy.org/en/latest/getting-started.html#installing-pypy >> >> Regressions >> =========== >> >> Reasons why this is not PyPy 2.0: >> >> * the ``ctypes`` fast path is now slower than it used to be. In PyPy >> 1.9 ``ctypes`` was either incredibly faster or slower than CPython >> depending whether >> you hit the fast path or not. Right now it's usually simply slower. >> We're >> probably going to rewrite ``ctypes`` using ``cffi``, which will make it >> universally faster. >> >> * ``cffi`` (an alternative to interfacing with C code) is very fast, but >> it is missing one optimization that will make it as fast as a native >> call from C. >> >> * ``numpypy`` lazy computation was disabled for the sake of simplicity. >> We should reenable this for the final 2.0 release. >> >> Highlights >> ========== >> >> * ``cffi`` is officially supported by PyPy. You can install it normally by >> using ``pip install cffi`` once you have installed `PyPy and pip`_. >> The corresponding ``0.4`` version of ``cffi`` has been released. >> >> * ARM is now an officially supported processor architecture. >> PyPy now work on soft-float ARM/Linux builds. Currently ARM processors >> supporting the ARMv7 and later ISA that include a floating-point unit >> are >> supported. >> >> * This release contains the latest Python standard library 2.7.3 and is >> fully >> compatible with Python 2.7.3. >> >> * It does not however contain hash randomization, since the solution >> present >> in CPython is not solving the problem anyway. The reason can be >> found on the `CPython issue tracker`_. >> >> * ``gc.get_referrers()`` is now faster. >> >> * Various numpy improvements. The list includes: >> >> * axis argument support in many places >> >> * full support for fancy indexing >> >> * ``complex128`` and ``complex64`` dtypes >> >> * `JIT hooks`_ are now a powerful tool to introspect the JITting process >> that >> PyPy performs. >> >> * ``**kwds`` usage is much faster in the typical scenario >> >> * operations on ``long`` objects are now as fast as in CPython (from >> roughly 2x slower) >> >> * We now have special strategies for ``dict``/``set``/``list`` which >> contain >> unicode strings, which means that now such collections will be both >> faster >> and more compact. >> >> .. _`cpython issue tracker`: http://bugs.python.org/issue14621 >> .. _`jit hooks`: http://doc.pypy.org/en/latest/jit-hooks.html >> >> Things we're working on >> ======================= >> >> There are a few things that did not make it to the 2.0 beta 1, which >> are being actively worked on. Greenlets support in the JIT is one >> that we would like to have before 2.0 final. Two important items that >> will not make it to 2.0, but are being actively worked on, are: >> >> * Faster JIT warmup time. >> >> * Software Transactional Memory. >> >> Cheers, >> Maciej Fijalkowski, Armin Rigo and the PyPy team >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> http://mail.python.org/mailman/listinfo/pypy-dev > > From stefan_ml at behnel.de Sun Nov 25 11:36:15 2012 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 25 Nov 2012 11:36:15 +0100 Subject: [pypy-dev] PyPy 2.0 beta 1 released In-Reply-To: References: Message-ID: Maciej Fijalkowski, 25.11.2012 11:14: > On Fri, Nov 23, 2012 at 4:51 PM, Phyo Arkar wrote: >> ARM Build! thats mean we can run Pypy in android now right? >> I am building my own Python for Android with required dependencies , i am >> gonna test pypy on android too! > > No, it works on ARM linux. I have no idea what it takes to make it > work on Android (hopefully not much) "Make it work" is different from "make it useful", though, especially on an embedded platform like Android. Porting kivy would be a way, for example. Stefan From fijall at gmail.com Sun Nov 25 11:41:21 2012 From: fijall at gmail.com (Maciej Fijalkowski) Date: Sun, 25 Nov 2012 11:41:21 +0100 Subject: [pypy-dev] PyPy 2.0 beta 1 released In-Reply-To: References: Message-ID: On Sun, Nov 25, 2012 at 11:36 AM, Stefan Behnel wrote: > Maciej Fijalkowski, 25.11.2012 11:14: >> On Fri, Nov 23, 2012 at 4:51 PM, Phyo Arkar wrote: >>> ARM Build! thats mean we can run Pypy in android now right? >>> I am building my own Python for Android with required dependencies , i am >>> gonna test pypy on android too! >> >> No, it works on ARM linux. I have no idea what it takes to make it >> work on Android (hopefully not much) > > "Make it work" is different from "make it useful", though, especially on an > embedded platform like Android. Porting kivy would be a way, for example. > > Stefan Definitely :-) That's one of the reasons why we target ARM linux for now, where it can be useful already. Cheers, fijal From techtonik at gmail.com Tue Nov 27 11:38:25 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 27 Nov 2012 13:38:25 +0300 Subject: [pypy-dev] Translation PDF link is broken Message-ID: This page - http://doc.pypy.org/en/latest/translation.html - links to http://doc.pypy.org/en/latest/image/translation.pdf which is 404. If you fixing that - is it possible to link PyGame viewer to more information as well? -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amauryfa at gmail.com Tue Nov 27 11:42:46 2012 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Tue, 27 Nov 2012 11:42:46 +0100 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: 2012/11/27 anatoly techtonik > If you fixing that - is it possible to link PyGame viewer to more > information as well? The command "python bin/translatorshell.py" has a nice help message on startup. Nothing needs to be installed, outside python-pygame. -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Tue Nov 27 11:56:03 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 27 Nov 2012 13:56:03 +0300 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: On Tue, Nov 27, 2012 at 1:42 PM, Amaury Forgeot d'Arc wrote: > 2012/11/27 anatoly techtonik > >> If you fixing that - is it possible to link PyGame viewer to more >> information as well? > > > The command "python bin/translatorshell.py" has a nice help message on > startup. > Nothing needs to be installed, outside python-pygame. > If I had PyPy checkout I could find it myself. =) I just wanted to take a look at the PyGame part, but the entrypoint is obscured, so I couldn't find it. https://bitbucket.org/pypy/pypy/src/default/pypy/bin/translatorshell.py -------------- next part -------------- An HTML attachment was scrubbed... URL: From amauryfa at gmail.com Tue Nov 27 12:14:59 2012 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Tue, 27 Nov 2012 12:14:59 +0100 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: 2012/11/27 anatoly techtonik > On Tue, Nov 27, 2012 at 1:42 PM, Amaury Forgeot d'Arc wrote: > >> 2012/11/27 anatoly techtonik >> >>> If you fixing that - is it possible to link PyGame viewer to more >>> information as well? >> >> >> The command "python bin/translatorshell.py" has a nice help message on >> startup. >> Nothing needs to be installed, outside python-pygame. >> > > If I had PyPy checkout I could find it myself. =) > If you want to try PyPy, you'd better have a checkout anyway. > I just wanted to take a look at the PyGame part, but the entrypoint is > obscured, so I > couldn't find it. > https://bitbucket.org/pypy/pypy/src/default/pypy/bin/translatorshell.py > See the Translator code, in pypy/translator/translator.py and the "dotviewer": dotviewer/graphpage.py dotviewer/drawgraph.py This last file imports pygame. Have fun! -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Wed Nov 28 19:33:26 2012 From: arigo at tunes.org (Armin Rigo) Date: Wed, 28 Nov 2012 10:33:26 -0800 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: Hi Anatoly, On Tue, Nov 27, 2012 at 2:38 AM, anatoly techtonik wrote: > This page - http://doc.pypy.org/en/latest/translation.html - links to > http://doc.pypy.org/en/latest/image/translation.pdf which is 404. Fixed, thanks. (Unsure what's the point of this pdf, as it's just the same as the image below, in color.) A bient?t, Armin. From techtonik at gmail.com Wed Nov 28 21:32:45 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 28 Nov 2012 23:32:45 +0300 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: On Wed, Nov 28, 2012 at 9:33 PM, Armin Rigo wrote: > Hi Anatoly, > > On Tue, Nov 27, 2012 at 2:38 AM, anatoly techtonik > wrote: > > This page - http://doc.pypy.org/en/latest/translation.html - links to > > http://doc.pypy.org/en/latest/image/translation.pdf which is 404. > > Fixed, thanks. (Unsure what's the point of this pdf, as it's just the > same as the image below, in color.) > This one is not too interesting, indeed. The point is that documentation generation process is probably broken and other PDF materials are 404 as well. BTW, is it possible to return different content-type for that files so that Chrome could render it inline instead downloading? -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Wed Nov 28 21:59:32 2012 From: arigo at tunes.org (Armin Rigo) Date: Wed, 28 Nov 2012 12:59:32 -0800 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: Hi Anatoly, On Wed, Nov 28, 2012 at 12:32 PM, anatoly techtonik wrote: > This one is not too interesting, indeed. The point is that documentation > generation process is probably broken and other PDF materials are 404 as > well. I think it's the only one in this situation. Not enough to care too much :-) A bient?t, Armin. From techtonik at gmail.com Wed Nov 28 22:05:24 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Thu, 29 Nov 2012 00:05:24 +0300 Subject: [pypy-dev] Translation PDF link is broken In-Reply-To: References: Message-ID: On Wed, Nov 28, 2012 at 11:59 PM, Armin Rigo wrote: > Hi Anatoly, > > On Wed, Nov 28, 2012 at 12:32 PM, anatoly techtonik > wrote: > > This one is not too interesting, indeed. The point is that documentation > > generation process is probably broken and other PDF materials are 404 as > > well. > > I think it's the only one in this situation. Not enough to care too much > :-) > Fair enough. =) -------------- next part -------------- An HTML attachment was scrubbed... URL: