From ndbecker2 at gmail.com Thu Jun 1 06:52:18 2017 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Jun 2017 06:52:18 -0400 Subject: [pypy-dev] Integer division References: Message-ID: Tuom Larsen wrote: > Dear list! > > I noticed that integer division (`//`) is slower than floating-point > division and integer cast. For example: > > from __future__ import division > from time import time > t = time() > for i in range(1, 10000): > for j in range(1, 10000): > # k = i//j # 2.12 seconds > k = int(i/j) # 0.98 seconds > print time() - t > > I now integer division should be slower, but I thought that the > `int()` would make floating division even slower. > > Please, can someone explain what is going on? Is this expected behaviour? > > Thank you! I don't know about behavior in pypy, but in terms of basic CPU performance, my understanding is that this is expected. From armin.rigo at gmail.com Thu Jun 1 06:53:55 2017 From: armin.rigo at gmail.com (Armin Rigo) Date: Thu, 1 Jun 2017 12:53:55 +0200 Subject: [pypy-dev] Integer division In-Reply-To: References: Message-ID: Hi, On 31 May 2017 at 17:11, Tuom Larsen wrote: > # k = i//j # 2.12 seconds > k = int(i/j) # 0.98 seconds Note first that if you don't do anything with 'k', it might be optimized away. I just wrote a pure C example doing the same thing, and indeed converting the integers to float, dividing, and then converting back to integer... is 2.2x times faster there too. Go figure it out. I have no idea why the CPU behaves like that. Maybe Neal can provide a clue. A bient?t, Armin. From william.leslie.ttg at gmail.com Thu Jun 1 07:25:52 2017 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Thu, 1 Jun 2017 21:25:52 +1000 Subject: [pypy-dev] Integer division In-Reply-To: References: Message-ID: On 1 June 2017 at 20:53, Armin Rigo wrote: > Hi, > > On 31 May 2017 at 17:11, Tuom Larsen wrote: > > # k = i//j # 2.12 seconds > > k = int(i/j) # 0.98 seconds > > Note first that if you don't do anything with 'k', it might be optimized > away. > > I just wrote a pure C example doing the same thing, and indeed > converting the integers to float, dividing, and then converting back > to integer... is 2.2x times faster there too. > > Go figure it out. I have no idea why the CPU behaves like that. > Maybe Neal can provide a clue. > ?I took a look at this earlier today. It turns out that, on Skylake (and I think it's similar on other recent x86_64 implementations), 80-bit floating point division has a latency of 14 cycles, where 32 bit integer division has a latency of 26 cycles.? I expect this is because there are only two hardware division units, and both are on the floating point path. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer.drow at gmail.com Sun Jun 4 02:29:03 2017 From: omer.drow at gmail.com (Omer Katz) Date: Sun, 04 Jun 2017 06:29:03 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 Message-ID: Hi guys, The latest cppyy package doesn't seem to ship with cling 0.3 which supports both of those compilers. I can't find the repository for the package to attempt to contribute myself. Can you direct me to the repository or upgrade to the latest cling? Best Regards, Omer Katz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omer.drow at gmail.com Sun Jun 4 10:30:26 2017 From: omer.drow at gmail.com (Omer Katz) Date: Sun, 04 Jun 2017 14:30:26 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: I downloaded the tarball from PyPi and tried upgrading. I'm stuck with some cmake dependencies that seem to be missing. See build log https://gist.github.com/thedrow/5eb31d5880b8ededc45466f8bedf6a76 Any instruction on how to proceed will be greatly appreciated. Best Regards, Omer Katz. ??????? ??? ??, 4 ????? 2017 ?-9:29 ??? ?Omer Katz?? :? > Hi guys, > The latest cppyy package doesn't seem to ship with cling 0.3 which > supports both of those compilers. > I can't find the repository for the package to attempt to contribute > myself. > Can you direct me to the repository or upgrade to the latest cling? > > Best Regards, > Omer Katz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlavrijsen at lbl.gov Mon Jun 5 15:57:47 2017 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Mon, 5 Jun 2017 12:57:47 -0700 (PDT) Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Omar, > See build log > https://gist.github.com/thedrow/5eb31d5880b8ededc45466f8bedf6a76 I don't understand this one, as these dependencies are part of the package. Are there any further details in any logs? Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From wlavrijsen at lbl.gov Mon Jun 5 15:58:44 2017 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Mon, 5 Jun 2017 12:58:44 -0700 (PDT) Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Omer, > Omar, sorry, did it again. :P Should stick a note to my laptop ... Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From omer.drow at gmail.com Mon Jun 5 16:53:42 2017 From: omer.drow at gmail.com (Omer Katz) Date: Mon, 05 Jun 2017 20:53:42 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: These logs are printed once I try to upgrade cling and llvm from their respective repositories. There are multiple problems with compiling the current version of cppyy. First of all, the distributed cling version is too old and doesn't support the GCC 5 ABI which means that you can't compile it with the GCC version I have. This can be fixed by upgrading cling to 0.3 or higher. Second of all, there's a bug in clang that doesn't allow to compile llvm with the clib headers that are distributed with GCC 6. I can download and install an older compiler but I don't see a reason since upgrading cling will fix the issue. I tried to find the source code repository for the package in order to try to share my contributions to upgrade cling to 0.3 but I could not find it. If it doesn't exist can you please create one, preferably under the pypy project in Bitbucket? On Mon, Jun 5, 2017, 22:58 wrote: > Omer, > > > Omar, > > sorry, did it again. :P Should stick a note to my laptop ... > > Best regards, > Wim > -- > WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlavrijsen at lbl.gov Mon Jun 5 17:09:45 2017 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Mon, 5 Jun 2017 14:09:45 -0700 (PDT) Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Omer, > I tried to find the source code repository for the package in order to try > to share my contributions to upgrade cling to 0.3 but I could not find it. > If it doesn't exist can you please create one, preferably under the pypy > project in Bitbucket? the current version still has some dependencies left on ROOT: I thus used a stripped-down version of it, mostly by removing sub-directories, but also by trimming the modules (such as IO) that are still needed. I then added the cppyy cxx sources from the PyPy repo. The Cling standalone release is not yet used. The numbering of 6.6.9 in PyPi refers to ROOT 6.06/09, so it's a release behind current. I don't know whether current solves the compilation issues, though, and I don't know whether standalone cling easily drops in there. Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From omer.drow at gmail.com Mon Jun 5 17:22:28 2017 From: omer.drow at gmail.com (Omer Katz) Date: Mon, 05 Jun 2017 21:22:28 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: The latest release of ROOT v6-09-04 released 18 days ago. It contains cling 0.4-dev. See https://github.com/root-project/root/blob/v6-09-04/interpreter/cling/VERSION The release notes for cling 0.3 specify that the GCC 5 ABI is now supported. See https://github.com/root-project/cling/releases/tag/v0.3 So upgrading will surely help. Even if you just stripped down the original ROOT version it's still useful to have a code repository that will record the changes so that others can help upgrade and maintain cppyy if necessary. Source Control allows you to view the changes and extract patches to automate some of the repeated work of stripping down ROOT during upgrades. On Tue, Jun 6, 2017, 00:10 wrote: > Omer, > > > I tried to find the source code repository for the package in order to > try > > to share my contributions to upgrade cling to 0.3 but I could not find > it. > > If it doesn't exist can you please create one, preferably under the pypy > > project in Bitbucket? > > the current version still has some dependencies left on ROOT: I thus used a > stripped-down version of it, mostly by removing sub-directories, but also > by trimming the modules (such as IO) that are still needed. I then added > the cppyy cxx sources from the PyPy repo. The Cling standalone release is > not yet used. > > The numbering of 6.6.9 in PyPi refers to ROOT 6.06/09, so it's a release > behind current. I don't know whether current solves the compilation issues, > though, and I don't know whether standalone cling easily drops in there. > > Best regards, > Wim > -- > WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Tue Jun 6 03:01:32 2017 From: matti.picus at gmail.com (Matti Picus) Date: Tue, 6 Jun 2017 10:01:32 +0300 Subject: [pypy-dev] Release 5.8.0 is getting closer Message-ID: <1eb3001d-259b-f2c7-f253-2683428e32d9@gmail.com> An HTML attachment was scrubbed... URL: From omer.drow at gmail.com Wed Jun 7 03:55:40 2017 From: omer.drow at gmail.com (Omer Katz) Date: Wed, 07 Jun 2017 07:55:40 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: I was able to follow your lead for the most part. I'm stuck right now with cmake. See https://gist.github.com/thedrow/7c9f253d21e16c90547ecfb3538723b0 The diff for ROOTNewMacros.cmake can be found here https://www.diffchecker.com/Ff7UD7lG ??????? ??? ??, 6 ????? 2017 ?-0:22 ??? ?Omer Katz?? :? > The latest release of ROOT v6-09-04 released 18 days ago. > It contains cling 0.4-dev. See > https://github.com/root-project/root/blob/v6-09-04/interpreter/cling/VERSION > The release notes for cling 0.3 specify that the GCC 5 ABI is now > supported. See https://github.com/root-project/cling/releases/tag/v0.3 > So upgrading will surely help. > > Even if you just stripped down the original ROOT version it's still useful > to have a code repository that will record the changes so that others can > help upgrade and maintain cppyy if necessary. Source Control allows you to > view the changes and extract patches to automate some of the repeated work > of stripping down ROOT during upgrades. > > On Tue, Jun 6, 2017, 00:10 wrote: > >> Omer, >> >> > I tried to find the source code repository for the package in order to >> try >> > to share my contributions to upgrade cling to 0.3 but I could not find >> it. >> > If it doesn't exist can you please create one, preferably under the pypy >> > project in Bitbucket? >> >> the current version still has some dependencies left on ROOT: I thus used >> a >> stripped-down version of it, mostly by removing sub-directories, but also >> by trimming the modules (such as IO) that are still needed. I then added >> the cppyy cxx sources from the PyPy repo. The Cling standalone release is >> not yet used. >> >> The numbering of 6.6.9 in PyPi refers to ROOT 6.06/09, so it's a release >> behind current. I don't know whether current solves the compilation >> issues, >> though, and I don't know whether standalone cling easily drops in there. >> >> Best regards, >> Wim >> -- >> WLavrijsen at lbl.gov -- +1 (510) 486 6411 <+1%20510-486-6411> -- >> www.lavrijsen.net >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Wed Jun 7 11:38:05 2017 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 7 Jun 2017 18:38:05 +0300 Subject: [pypy-dev] PyPy 5.8.0 release candidates now up on bitbucket Message-ID: <27a11e68-fae1-fda7-5071-51d314da2c53@gmail.com> An HTML attachment was scrubbed... URL: From wlavrijsen at lbl.gov Wed Jun 7 11:44:15 2017 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Wed, 7 Jun 2017 08:44:15 -0700 (PDT) Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Omer, in response to your last mail, I started a script to strip ROOT and build the package. Will get to that and that should refresh my memory enough to see what is going on (I don't remember having to make the changes that you posted in the diff, but that may be just my (lack of) memory). In your case, I'd recommend to simply build ROOT using '-Dminimal=ON' as an argument to cmake, which will already greatly reduce things. Then build the cling wrapper from the PyPy repository (is a single .cxx) following its make fragment. That should be enough: with the .so's in place, PyPy's cppyy should work out-of-the-box. Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From omer.drow at gmail.com Wed Jun 7 11:59:04 2017 From: omer.drow at gmail.com (Omer Katz) Date: Wed, 07 Jun 2017 15:59:04 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Ok, thanks. Maybe the documentation should contain something about building from source. The diff I posted is just what changed in that file between the versions. I thought that maybe you could recognize what went wrong and why rootcling is not a valid target. ??????? ??? ??, 7 ????? 2017 ?-18:44 ??? :? > Omer, > > in response to your last mail, I started a script to strip ROOT and build > the package. Will get to that and that should refresh my memory enough to > see what is going on (I don't remember having to make the changes that you > posted in the diff, but that may be just my (lack of) memory). > > In your case, I'd recommend to simply build ROOT using '-Dminimal=ON' as > an argument to cmake, which will already greatly reduce things. Then build > the cling wrapper from the PyPy repository (is a single .cxx) following > its make fragment. That should be enough: with the .so's in place, PyPy's > cppyy should work out-of-the-box. > > Best regards, > Wim > -- > WLavrijsen at lbl.gov -- +1 (510) 486 6411 <+1%20510-486-6411> -- > www.lavrijsen.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matti.picus at gmail.com Wed Jun 7 12:02:34 2017 From: matti.picus at gmail.com (Matti Picus) Date: Wed, 7 Jun 2017 19:02:34 +0300 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: On 07/06/17 18:44, wlavrijsen at lbl.gov wrote: > Omer, > > ... > Then build > the cling wrapper from the PyPy repository (is a single .cxx) following > its make fragment. That should be enough: with the .so's in place, PyPy's > cppyy should work out-of-the-box. > > Best regards, > Wim FWIW, when I download the latest cppyy backend from PyPI, there seems to be a different version of clingwrapper.cxx: diff PyPy-cppyy-backend-6.6.9.0/src/backend/cppyy/src/clingcwrapper.cxx pypy/pypy/module/cppyy/src/clingcwrapper.cxx 525c525 < cppresult->std::string::~string(); --- > cppresult->std::string::~basic_string(); 715c715 < std::cerr << "Warning: " << msg << '\n'; --- > std::cerr << "Warning: " << msg.str() << '\n'; 939c939 < // TClassRef& cr = type_from_handle( scope ); --- Disclaimer: I have not tried to use any of this, I'm just wondering which one is correct Matti From wlavrijsen at lbl.gov Wed Jun 7 12:11:43 2017 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Wed, 7 Jun 2017 09:11:43 -0700 (PDT) Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Matti, > FWIW, when I download the latest cppyy backend from PyPI, there seems to > be a different version of clingwrapper.cxx: yes. The one in the PyPy repository is the newer and has Ryan's fixes in it. I haven't had time to update the PyPI package. Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From matti.picus at gmail.com Thu Jun 8 18:25:52 2017 From: matti.picus at gmail.com (Matti Picus) Date: Fri, 9 Jun 2017 01:25:52 +0300 Subject: [pypy-dev] PyPy v5.8 released Message-ID: An HTML attachment was scrubbed... URL: From kostia.lopuhin at gmail.com Fri Jun 9 02:53:29 2017 From: kostia.lopuhin at gmail.com (Konstantin Lopuhin) Date: Fri, 9 Jun 2017 09:53:29 +0300 Subject: [pypy-dev] PyPy v5.8 released In-Reply-To: References: Message-ID: Congrats on the release and thanks a lot everyone for your hard work! Just noticed that the link for PyPy 3 on http://pypy.org/download.html gives a 404, and I don't see pypy3 5.8 here https://bitbucket.org/pypy/pypy/downloads/ either. 2017-06-09 1:25 GMT+03:00 Matti Picus : > https://morepypy.blogspot.com/2017/06/pypy-v58-released.html > > Please update > Thanks to all who contribute and continue to make this a fun project > Matti > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > From omer.drow at gmail.com Tue Jun 13 09:48:34 2017 From: omer.drow at gmail.com (Omer Katz) Date: Tue, 13 Jun 2017 13:48:34 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: By the way, can't we ship a wheel for cppyy so that people won't have to compile it? We can instruct users to pip install --no-wheel if cppyy doesn't work for them. On Wed, Jun 7, 2017, 19:12 wrote: > Matti, > > > FWIW, when I download the latest cppyy backend from PyPI, there seems to > > be a different version of clingwrapper.cxx: > > yes. The one in the PyPy repository is the newer and has Ryan's fixes in > it. > I haven't had time to update the PyPI package. > > Best regards, > Wim > -- > WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fijall at gmail.com Tue Jun 13 13:03:38 2017 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 13 Jun 2017 19:03:38 +0200 Subject: [pypy-dev] Suggestion : Build Using PyPy page to showcase. In-Reply-To: References: Message-ID: Hey Phyo Good job, thanks for the feedback! On Tue, May 30, 2017 at 9:47 AM, Phyo Arkar wrote: > We had launched our chat-room for medical consultation , in our country. > It is reaching 5000 users in first month and growing fast with 400 > concurrent user max , daily. > > We need a page to showcase projects running 100% on pypy runtime! > > Regards > > Phyo. > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > From omer.drow at gmail.com Thu Jun 15 14:04:25 2017 From: omer.drow at gmail.com (Omer Katz) Date: Thu, 15 Jun 2017 18:04:25 +0000 Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 In-Reply-To: References: Message-ID: Wim do you need my help with the script? On Tue, Jun 13, 2017, 16:48 Omer Katz wrote: > By the way, can't we ship a wheel for cppyy so that people won't have to > compile it? > We can instruct users to pip install --no-wheel if cppyy doesn't work for > them. > > On Wed, Jun 7, 2017, 19:12 wrote: > >> Matti, >> >> > FWIW, when I download the latest cppyy backend from PyPI, there seems to >> > be a different version of clingwrapper.cxx: >> >> yes. The one in the PyPy repository is the newer and has Ryan's fixes in >> it. >> I haven't had time to update the PyPI package. >> >> Best regards, >> Wim >> -- >> WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net >> _______________________________________________ >> pypy-dev mailing list >> pypy-dev at python.org >> https://mail.python.org/mailman/listinfo/pypy-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tinysnippets at gmail.com Mon Jun 19 07:52:06 2017 From: tinysnippets at gmail.com (Aleksandr Koshkin) Date: Mon, 19 Jun 2017 14:52:06 +0300 Subject: [pypy-dev] Exposing rpython based functions to cpython vm. Message-ID: Hello, folks) I have been tinkering with pypy source tree for a week now and came up with a following question - is there any way to build a rpython program as a shared object which exposes some of its functionality (say a list of functions) for standard cpython vm, in other words I want this functions to be invokable from python script via shared object import. When I try to build my program like so: python rpython --shared -O2 some_program.py libmyprogram-c.so actually gets generated, unimportable from cpython though. Should I use CFFI for cpython next or there is some sort of facility (decorator or something)? -- Kind regards, Aleksandr Koshkin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Mon Jun 19 15:42:10 2017 From: armin.rigo at gmail.com (Armin Rigo) Date: Mon, 19 Jun 2017 21:42:10 +0200 Subject: [pypy-dev] Exposing rpython based functions to cpython vm. In-Reply-To: References: Message-ID: Hi, On 19 June 2017 at 13:52, Aleksandr Koshkin wrote: > I have been tinkering with pypy source tree for a week now and came up with > a following question - is there any way to build a rpython program as a > shared object which exposes some of its functionality (say a list of Answered on https://stackoverflow.com/questions/44629893/invoke-rpython-based-functions-from-standard-python-code . A bient?t, Armin. From yury at shurup.com Mon Jun 19 15:55:12 2017 From: yury at shurup.com (Yury V. Zaytsev) Date: Mon, 19 Jun 2017 21:55:12 +0200 (CEST) Subject: [pypy-dev] Exposing rpython based functions to cpython vm. In-Reply-To: References: Message-ID: On Mon, 19 Jun 2017, Armin Rigo wrote: > Answered on https://stackoverflow.com/questions/44629893/invoke-rpython-based-functions-from-standard-python-code I would add to that that in the case that the idea was to take some code out of hot loops, translate it into RPython so that it runs faster, and finally import it into cPython, then (as Armin elaborated) you're missing the point of RPython. However, here are few alternatives to consider: One go-to solution would be to use Cython which lets you easily blend Python / C up to the point of writing restricted C with Python syntax, and import resulting Cython modules into your program running under cPython. A more principled solution would be to port your application to PyPy (if any porting would be required at all), and enjoy the JIT, or else dig around trying to figure out why exactly is that you're not getting the speedups you were hoping for, and make PyPy better in the process! -- Sincerely yours, Yury V. Zaytsev From tinysnippets at gmail.com Mon Jun 19 18:36:03 2017 From: tinysnippets at gmail.com (Aleksandr Koshkin) Date: Tue, 20 Jun 2017 01:36:03 +0300 Subject: [pypy-dev] Exposing rpython based functions to cpython vm. In-Reply-To: References: Message-ID: Thank you guys for your responses, appreciated. So as a study case I am building custom JIT powered regex matcher (somewhat more or less compatible with pcre). It is not a problem to build one as a stand alone application but I want it as a shared library and ultimately as a python compatible module. As a interface between rpython (C, really) and python for input I see a tuple - (program::bytes, input_string::unicode) and for output [(group0::unicode, value0::unicode), ..., ]. 1. Is it even a sane idea to use rpython toolchain to handle such task? I mean specifically embedding problem, because again as a stand alone app it is not a big deal and worth nothing. 2. Why some valid rpython code fails inside a function decorated with an entrypoint_highlevel (e.g. os.write(1, "hello world") would fail with segfault at runtime). And are there any dedicated docs describing such limitations? Cheers, magniff. 2017-06-19 22:55 GMT+03:00 Yury V. Zaytsev : > On Mon, 19 Jun 2017, Armin Rigo wrote: > > Answered on https://stackoverflow.com/questions/44629893/invoke-rpython- >> based-functions-from-standard-python-code >> > > I would add to that that in the case that the idea was to take some code > out of hot loops, translate it into RPython so that it runs faster, and > finally import it into cPython, then (as Armin elaborated) you're missing > the point of RPython. However, here are few alternatives to consider: > > One go-to solution would be to use Cython which lets you easily blend > Python / C up to the point of writing restricted C with Python syntax, and > import resulting Cython modules into your program running under cPython. > > A more principled solution would be to port your application to PyPy (if > any porting would be required at all), and enjoy the JIT, or else dig > around trying to figure out why exactly is that you're not getting the > speedups you were hoping for, and make PyPy better in the process! > > -- > Sincerely yours, > Yury V. Zaytsev > -- Kind regards, Aleksandr Koshkin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tinysnippets at gmail.com Tue Jun 20 06:35:38 2017 From: tinysnippets at gmail.com (Aleksandr Koshkin) Date: Tue, 20 Jun 2017 13:35:38 +0300 Subject: [pypy-dev] os.write segfaults Message-ID: Sup, folks!) I have yet another question on SO, bump it here. https://stackoverflow.com/questions/44649591/rpython-segfaults-on-os-write -- Kind regards, Aleksandr Koshkin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tinysnippets at gmail.com Tue Jun 20 10:40:26 2017 From: tinysnippets at gmail.com (Aleksandr Koshkin) Date: Tue, 20 Jun 2017 17:40:26 +0300 Subject: [pypy-dev] os.write segfaults In-Reply-To: References: Message-ID: It seams that the problem lies in default GC (minimark), for some reason it frees memory a bit in advance. By setting --gc=ref it runs correctly. Is it a bug? 2017-06-20 13:35 GMT+03:00 Aleksandr Koshkin : > Sup, folks!) > I have yet another question on SO, bump it here. > https://stackoverflow.com/questions/44649591/rpython-segfaults-on-os-write > > -- > Kind regards, Aleksandr Koshkin. > -- Kind regards, Aleksandr Koshkin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.rigo at gmail.com Tue Jun 20 17:13:53 2017 From: armin.rigo at gmail.com (Armin Rigo) Date: Tue, 20 Jun 2017 23:13:53 +0200 Subject: [pypy-dev] os.write segfaults In-Reply-To: References: Message-ID: Hi, On 20 June 2017 at 12:35, Aleksandr Koshkin wrote: > I have yet another question on SO, bump it here. > https://stackoverflow.com/questions/44649591/rpython-segfaults-on-os-write The library is supposed to be initialized first. I think you need to call rpython_startup_code() first to do that. A bient?t, Armin. From wlavrijsen at lbl.gov Fri Jun 23 17:09:50 2017 From: wlavrijsen at lbl.gov (wlavrijsen at lbl.gov) Date: Fri, 23 Jun 2017 14:09:50 -0700 (PDT) Subject: [pypy-dev] Unable to compile cppyy with clang 4.0 or GCC 5.0 Message-ID: Omer, replying to this older mail, just so that it is seen on the list as well: version '6.10.0.0' (is latest as of a week or so) has been uploaded to PyPI. Best regards, Wim -- WLavrijsen at lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net From william.leslie.ttg at gmail.com Thu Jun 29 11:26:55 2017 From: william.leslie.ttg at gmail.com (William ML Leslie) Date: Fri, 30 Jun 2017 01:26:55 +1000 Subject: [pypy-dev] Fwd: [CfP][Meta'17] Workshop on Meta-Programming Techniques and Reflection In-Reply-To: <423FB430-79F0-4ADE-8826-AB267F370737@stefan-marr.de> References: <423FB430-79F0-4ADE-8826-AB267F370737@stefan-marr.de> Message-ID: ---------- Forwarded message ---------- From: Stefan Marr Date: 29 June 2017 at 23:22 Subject: [CfP][Meta'17] Workshop on Meta-Programming Techniques and Reflection To: mlvm-dev at openjdk.java.net Call for Papers: Meta?17 ======================== Workshop on Meta-Programming Techniques and Reflection Co-located with SPLASH 2017 October 22, 2017, Vancouver, Canada Twitter @MetaAtSPLASH http://2017.splashcon.org/track/meta-2017 The heterogeneity of mobile computing, cloud applications, multicore architectures, and other systems leads to increasing complexity of software and requires new approaches to programming languages and software engineering tools. To manage the complexity, we require generic solutions that can be adapted to specific application domains or use cases, making metaprogramming an important topic of research once more. However, the challenges with metaprogramming are still manifold. They start with fundamental issues such as typing of reflective programs, continue with practical concerns such as performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. Thus, while industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript and others, academia still needs to answer a wide range of questions to bring it to the same level of convenience, tooling, and programming styles to cope with the increasing complexity of software systems. This workshop aims to explore meta-level technologies that help tackling the heterogeneity, scalability and openness requirements of emerging computations platforms. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming: - from static to dynamic techniques - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques to minimize runtime overhead - contract systems, or typing of reflective programs reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, and taxonomization of existing approaches In short, we invite contributions to the workshop on a wide range of topics related to design, implementation, and application of reflective APIs and meta-programming techniques, as well as empirical studies and typing for such systems and languages. ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. The workshop papers will be published in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. Therefore, papers are to be submitted using the SIGPLAN acmart style: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex http://www.sigplan.org/sites/default/files/acmart/current/ acmart-sigplanproc-template.tex) or Word http://www.acm.org/publications/proceedings-template. - technical paper: max. 8 pages, excluding references - position and work-in-progress paper: 1-4 pages, excluding references - technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work. For the submission, please use the submission system at: https://meta17.hotcrp.com/ ### Important Dates Abstract Submission: 07 August 2017 Paper Submission: 14 August 2017 Author Notification: 06 September 2017 Position/WIP Paper Deadline: 08 September 2017 Camera Ready Deadline: 18 September 2017 Position/WIP Notification: 21 September 2017 ### Program Committee The program committee consists of the organizers and the following reviewers: Anya Helen Bagge, University of Bergen, Norway Daniele Bonetta, Oracle Labs, Austria Nicolas Cardozo, Universidad de los Andes, Colombia Sebastian Erdweg, TU Delf, The Nederlands Robert Hirschfeld, HPI, Germany Roberto Ierusalimschy, PUC-Rio, Brazil Pablo Inostroza, CWI, The Nederlands Kim Mens, Universite Catholique de Louvain, Belgium Cyrus Omar, Carnegie Mellon University, USA Guillermo Polito, CNRS, France Tiark Rompf, Purdue University, USA Tom Van Cutsem, Nokia Bell Labs, Belgium Takuo Watanabe, Tokyo Institute of Technology, Japan ### Workshop Organizers Shigeru Chiba, University of Tokyo Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, Johannes Kepler University Linz _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phyo.arkarlwin at gmail.com Fri Jun 30 13:09:51 2017 From: phyo.arkarlwin at gmail.com (Phyo Arkar) Date: Fri, 30 Jun 2017 10:09:51 -0700 Subject: [pypy-dev] Suggestion : Build Using PyPy page to showcase. In-Reply-To: References: Message-ID: Thanks, any plans for showcase site? We can build one, if you need help. On Jun 13, 2017 11:33 PM, "Maciej Fijalkowski" wrote: > Hey Phyo > > Good job, thanks for the feedback! > > On Tue, May 30, 2017 at 9:47 AM, Phyo Arkar > wrote: > > We had launched our chat-room for medical consultation , in our country. > > It is reaching 5000 users in first month and growing fast with 400 > > concurrent user max , daily. > > > > We need a page to showcase projects running 100% on pypy runtime! > > > > Regards > > > > Phyo. > > > > _______________________________________________ > > pypy-dev mailing list > > pypy-dev at python.org > > https://mail.python.org/mailman/listinfo/pypy-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmludo at gmail.com Fri Jun 30 16:19:50 2017 From: gmludo at gmail.com (Ludovic Gasc) Date: Fri, 30 Jun 2017 22:19:50 +0200 Subject: [pypy-dev] Suggestion : Build Using PyPy page to showcase. In-Reply-To: References: Message-ID: +1 for the show case. -- Ludovic Gasc (GMLudo) Lead Developer Architect at ALLOcloud https://be.linkedin.com/in/ludovicgasc 2017-06-30 19:09 GMT+02:00 Phyo Arkar : > Thanks, any plans for showcase site? > We can build one, if you need help. > > On Jun 13, 2017 11:33 PM, "Maciej Fijalkowski" wrote: > >> Hey Phyo >> >> Good job, thanks for the feedback! >> >> On Tue, May 30, 2017 at 9:47 AM, Phyo Arkar >> wrote: >> > We had launched our chat-room for medical consultation , in our country. >> > It is reaching 5000 users in first month and growing fast with 400 >> > concurrent user max , daily. >> > >> > We need a page to showcase projects running 100% on pypy runtime! >> > >> > Regards >> > >> > Phyo. >> > >> > _______________________________________________ >> > pypy-dev mailing list >> > pypy-dev at python.org >> > https://mail.python.org/mailman/listinfo/pypy-dev >> > >> > > _______________________________________________ > pypy-dev mailing list > pypy-dev at python.org > https://mail.python.org/mailman/listinfo/pypy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: