From poelzi at poelzi.org Sat Aug 1 01:20:57 2009 From: poelzi at poelzi.org (poelzi) Date: Sat, 01 Aug 2009 01:20:57 +0200 Subject: [pypy-dev] supporting new libraries Message-ID: <4A737C59.3040602@poelzi.org> Hi, i personally have made quite bad experice with swig and mostly not so good with most bindings generators so far. recently i found http://code.google.com/p/pybindgen/ and found the quality of the the generator really a good starting point; also that it uses gccxml for itrospection for auto generated bindings removes a lot of pain :-) i started making me thoughts to refactor pybindgen to generate not only python wrappers ( i need lua wrappers sometimes, too). While beeing at it i thought, why not use it to generate pypy wrapping code, too. So python_c is just another target same as pypy. maybe some code can be shared between such same language, different interpreter backends. maybe the frontend could be abstracted a bit, too. so if someone writes a defs parser the gtk python definitions could be used and only the overloaded functions need customizations, same goes for the qt4 sip stuff i think. what do you think ? kindly regards poelzi PS: sorry for breaking the thread, i just subscribed :-) From arigo at tunes.org Sat Aug 1 15:32:05 2009 From: arigo at tunes.org (Armin Rigo) Date: Sat, 1 Aug 2009 15:32:05 +0200 Subject: [pypy-dev] supporting new libraries In-Reply-To: References: <4727185d0907290738x7f8b4d7cy8ab580204b46ce7f@mail.gmail.com> <1248915553.14892.10.camel@localhost> <20090731120437.GA15676@code0.codespeak.net> <4727185d0907310514u75326721jf4eab60abd1d0b10@mail.gmail.com> <20090731130633.GA20493@code0.codespeak.net> Message-ID: <20090801133205.GA19829@code0.codespeak.net> Hi Thomas, On Fri, Jul 31, 2009 at 06:27:22PM +0200, Thomas Heller wrote: > > We have vague plans for a public sprint around october in D?sseldorf, > > Germany, which would probably be a better place to be in :-) > > That would be interesting to me! Are you doing your sprints over weekends, or > in the week? It's typically 7 days, so that includes both a week and the following weekend (or the other way around). A bientot, Armin. From list-sink at trainedmonkeystudios.org Sun Aug 9 01:26:01 2009 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Sat, 08 Aug 2009 16:26:01 -0700 Subject: [pypy-dev] befunge Message-ID: <1249773961.5218.9.camel@localhost> I have built an RPython implementation of befunge98 on top of pypy. It took about a week at 30%, and about half of that was spent writing a befunge implementation of pidigits[1]. I honestly expected to have more trouble getting this working, which is one of the reasons I chose something as simple as befunge. There were some hiccups, certainly, but compared to working with parrot and llvm, pypy was startlingly easy to get up and running. On to benchmarks. Time taken to compute the first 1,000 digits of pi: befunge.py: 3:03.18 befunge-c: 0:02.76 As advertised, I was able to write and test in python and run it through the translator to get... the wrong test output. This was, naturally, my own fault. As it turns out, pidigits requires arbitrary precision integer support. A quick skim of rarithmatic and rbignum and a bit of hacking later, and I got the awesomely cool results you see above. It was my plan at this point to lay down some benchmarks against other language implementations of pidigits showing how awesome pypy is. Unfortunately, the pidigits test is basically entirely limited by the performance of the bignum library in use. This effectively means that every language that can use gmp does, and gets a result of 3-7 seconds, which makes the pidigits test basically useless for meaningful interpreter benchmarking. That said, it is still a good benchmark for bignum libraries, so here goes: Time taken to compute the first 10,000 digits of pi: befunge-c: 5:22.13 pypy-c [2]: 5:35.26 python-2.5 [2]: 1:31.56 python-2.5(gmp) [3]: 0:10.22 >From what I see on the pyjitpl5 branch, jit support seems to be wildly in flux at the moment. I'm thinking I probably want to put jit support on hold until things settle down, although it's definitely on my todo list. Supporting jit on top of befunge will, I think, be an interesting edge case because the language was specifically designed to be hard to compile. Does pypy want a befunge interpreter? It is a rather easier to read interpreter than malbolge or javascript, although I did write it myself, so I may be biased. Some of the more esoteric instructions and edge cases are still missing, and there are several improvements that I would still like to try, but it basically works now, so I figured I would throw it out there. Pypy isn't using a DVCS, so I'm not sure what the best way is for me to share this code. For now I've just attached it inline -- it's only 12KiB, packed up. Untar it into the lang directory and it will create a befunge subdirectory. Let me know if there is a better way to share code. -Terrence Cole [1] - http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=all#about [2] - http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=python&id=1 [3] - http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=python&id=3 -------------- next part -------------- A non-text attachment was scrubbed... Name: befunge98-20090808.tar.bz2 Type: application/x-bzip-compressed-tar Size: 11696 bytes Desc: not available URL: From pedronis at openend.se Sun Aug 9 12:12:51 2009 From: pedronis at openend.se (Samuele Pedroni) Date: Sun, 09 Aug 2009 12:12:51 +0200 Subject: [pypy-dev] have pypy active branches use py.lib 1.0 final Message-ID: <4A7EA123.20000@openend.se> Given that py.lib 1.0 final is out, I think it makes sense to switch pypy active branches starting from trunk to use an external pointing to that. There are going to be some changes and possibly issues that will need addressing, the work may need to happen on a branch at first. I plan to work on this middle of next week if there are no objections. Samuele PS: the window buildbot is also down, given that we host it we will look into that From cfbolz at gmx.de Sun Aug 9 13:14:04 2009 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 09 Aug 2009 13:14:04 +0200 Subject: [pypy-dev] have pypy active branches use py.lib 1.0 final In-Reply-To: <4A7EA123.20000@openend.se> References: <4A7EA123.20000@openend.se> Message-ID: <4A7EAF7C.40405@gmx.de> Hi Samuele, Samuele Pedroni wrote: > Given that py.lib 1.0 final is out, I think it makes sense to switch > pypy active branches starting from trunk to use an external pointing to > that. I've thought about this as well, makes sense to me! I guess at a later point we can also think about using some of the more recent features. xfail comes to mind. > There are going to be some changes and possibly issues that will need > addressing, the work may need to happen on a branch at first. > > I plan to work on this middle of next week if there are no objections. Great! Carl Friedrich From holger at merlinux.eu Mon Aug 10 01:25:46 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 10 Aug 2009 01:25:46 +0200 Subject: [pypy-dev] have pypy active branches use py.lib 1.0 final In-Reply-To: <4A7EA123.20000@openend.se> References: <4A7EA123.20000@openend.se> Message-ID: <20090809232546.GK31589@trillke.net> Hi Samuele, all, On Sun, Aug 09, 2009 at 12:12 +0200, Samuele Pedroni wrote: > Given that py.lib 1.0 final is out, I think it makes sense to switch > pypy active branches starting from trunk to use an external pointing to > that. good that you mention it - here are some py.test/pylib infos from my side: - svn/py/dist is readonly and points to 1.0.0 and subsequent releases - svn/py/trunk is removed - main development takes place at: http://bitbucket.org/hpk42/py-trunk/ which contains a "1.0.x" branch and a "trunk" branch. to everyone: please don't hesitate to file issues, send questions or patches. > There are going to be some changes and possibly issues that will need > addressing, the work may need to happen on a branch at first. > > I plan to work on this middle of next week if there are no objections. I'll see to be around as well mid week. best, holger From fijall at gmail.com Tue Aug 11 11:16:25 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 11 Aug 2009 03:16:25 -0600 Subject: [pypy-dev] befunge In-Reply-To: <1249773961.5218.9.camel@localhost> References: <1249773961.5218.9.camel@localhost> Message-ID: <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> Hi. It's really cool that you find pypy as a good platform for writing interpreters, we're definitely happy with that :-) In general, we try to remove stuff from lang rather then put more of it there. So js/smalltalk/befunge interpreters would hopefully soon become projects on its own. On the other hand, we would be happy to give you commit access on codespeak so you can check stuff in somewhere there. The exact directory layout where to put other interpreters (and how to make different pages for them etc.) is yet to be determined. In case you want to use some other hosting service, like google code, feel free to do so as well. We would be more than happy to reference it from our web page. Cheers, fijal PS. Everybody is more or less on holiday right now, at least until next week, hence late response, sorry for that. PPS. If you check this stuff somewhere, I think it makes sense to mention it on the pypy blog, so please keep us updated. On Sat, Aug 8, 2009 at 5:26 PM, Terrence Cole wrote: > I have built an RPython implementation of befunge98 on top of pypy. ?It > took about a week at 30%, and about half of that was spent writing a > befunge implementation of pidigits[1]. ?I honestly expected to have more > trouble getting this working, which is one of the reasons I chose > something as simple as befunge. ?There were some hiccups, certainly, but > compared to working with parrot and llvm, pypy was startlingly easy to > get up and running. > > On to benchmarks. > > Time taken to compute the first 1,000 digits of pi: > befunge.py: 3:03.18 > befunge-c: 0:02.76 > > As advertised, I was able to write and test in python and run it through > the translator to get... the wrong test output. ?This was, naturally, my > own fault. ?As it turns out, pidigits requires arbitrary precision > integer support. ?A quick skim of rarithmatic and rbignum and a bit of > hacking later, and I got the awesomely cool results you see above. > > It was my plan at this point to lay down some benchmarks against other > language implementations of pidigits showing how awesome pypy is. > Unfortunately, the pidigits test is basically entirely limited by the > performance of the bignum library in use. ?This effectively means that > every language that can use gmp does, and gets a result of 3-7 seconds, > which makes the pidigits test basically useless for meaningful > interpreter benchmarking. ?That said, it is still a good benchmark for > bignum libraries, so here goes: > > Time taken to compute the first 10,000 digits of pi: > befunge-c: 5:22.13 > pypy-c [2]: 5:35.26 > python-2.5 [2]: 1:31.56 > python-2.5(gmp) [3]: 0:10.22 > > >From what I see on the pyjitpl5 branch, jit support seems to be wildly > in flux at the moment. ?I'm thinking I probably want to put jit support > on hold until things settle down, although it's definitely on my todo > list. ?Supporting jit on top of befunge will, I think, be an interesting > edge case because the language was specifically designed to be hard to > compile. > > Does pypy want a befunge interpreter? ?It is a rather easier to read > interpreter than malbolge or javascript, although I did write it myself, > so I may be biased. Some of the more esoteric instructions and edge > cases are still missing, and there are several improvements that I would > still like to try, but it basically works now, so I figured I would > throw it out there. ?Pypy isn't using a DVCS, so I'm not sure what the > best way is for me to share this code. ?For now ?I've just attached it > inline -- it's only 12KiB, packed up. ?Untar it into the lang directory > and it will create a befunge subdirectory. ?Let me know if there is a > better way to share code. > > -Terrence Cole > > [1] - > http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=all#about > [2] - > http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=python&id=1 > [3] - > http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits&lang=python&id=3 > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev > From list-sink at trainedmonkeystudios.org Thu Aug 13 02:44:02 2009 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Wed, 12 Aug 2009 17:44:02 -0700 Subject: [pypy-dev] befunge In-Reply-To: <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> References: <1249773961.5218.9.camel@localhost> <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> Message-ID: <1250124242.5102.152.camel@localhost> On Tue, 2009-08-11 at 03:16 -0600, Maciej Fijalkowski wrote: > Hi. > > It's really cool that you find pypy as a good platform for writing > interpreters, we're definitely > happy with that :-) In general, we try to remove stuff from lang > rather then put more of it > there. So js/smalltalk/befunge interpreters would hopefully soon > become projects on > its own. Thank you for the reply. I was thinking that the current situation in the lang directory would be unmanagable and I was wondering what I was missing :-). I have not run into any documentation on making the pypy toolchain run from an installed location, rather than from the svn checkout dir. Since I don't even understand how autopath works yet, I figured that getting something more sophisticated working than what everyone else is doing in the lang directory would be an adventure better left for later. Is there a plan for making pypy installable? Is it already possible and I just haven't looked hard enough? > On the other hand, we would be happy to give you commit > access on codespeak > so you can check stuff in somewhere there. The exact directory layout > where to put > other interpreters (and how to make different pages for them etc.) is > yet to be determined. That project would be more worthy of commit access than a befunge interpreter, I think. Maybe I should go look at how py's installer works. > In case you want to use some other hosting service, like google code, > feel free to do so > as well. We would be more than happy to reference it from our web page. I'll check out my options when I get some freetime. If pypy gets good support for hosting language implementations worked out at some point in the future, we can always move it. > Cheers, > fijal > > PS. Everybody is more or less on holiday right now, at least until > next week, hence late > response, sorry for that. > > PPS. If you check this stuff somewhere, I think it makes sense to > mention it on the pypy > blog, so please keep us updated. Will do! -Terrence > On Sat, Aug 8, 2009 at 5:26 PM, Terrence > Cole wrote: > > I have built an RPython implementation of befunge98 on top of pypy. It > > took about a week at 30%, and about half of that was spent writing a > > befunge implementation of pidigits[1]. I honestly expected to have more > > trouble getting this working, which is one of the reasons I chose > > something as simple as befunge. There were some hiccups, certainly, but > > compared to working with parrot and llvm, pypy was startlingly easy to > > get up and running. > > > > On to benchmarks. > > > > Time taken to compute the first 1,000 digits of pi: > > befunge.py: 3:03.18 > > befunge-c: 0:02.76 > > > > As advertised, I was able to write and test in python and run it through > > the translator to get... the wrong test output. This was, naturally, my > > own fault. As it turns out, pidigits requires arbitrary precision > > integer support. A quick skim of rarithmatic and rbignum and a bit of > > hacking later, and I got the awesomely cool results you see above. > > > > It was my plan at this point to lay down some benchmarks against other > > language implementations of pidigits showing how awesome pypy is. > > Unfortunately, the pidigits test is basically entirely limited by the > > performance of the bignum library in use. This effectively means that > > every language that can use gmp does, and gets a result of 3-7 seconds, > > which makes the pidigits test basically useless for meaningful > > interpreter benchmarking. That said, it is still a good benchmark for > > bignum libraries, so here goes: > > > > Time taken to compute the first 10,000 digits of pi: > > befunge-c: 5:22.13 > > pypy-c [2]: 5:35.26 > > python-2.5 [2]: 1:31.56 > > python-2.5(gmp) [3]: 0:10.22 > > > > >From what I see on the pyjitpl5 branch, jit support seems to be wildly > > in flux at the moment. I'm thinking I probably want to put jit support > > on hold until things settle down, although it's definitely on my todo > > list. Supporting jit on top of befunge will, I think, be an interesting > > edge case because the language was specifically designed to be hard to > > compile. > > > > Does pypy want a befunge interpreter? It is a rather easier to read > > interpreter than malbolge or javascript, although I did write it myself, > > so I may be biased. Some of the more esoteric instructions and edge > > cases are still missing, and there are several improvements that I would > > still like to try, but it basically works now, so I figured I would > > throw it out there. Pypy isn't using a DVCS, so I'm not sure what the > > best way is for me to share this code. For now I've just attached it > > inline -- it's only 12KiB, packed up. Untar it into the lang directory > > and it will create a befunge subdirectory. Let me know if there is a > > better way to share code. > > > > -Terrence Cole > > > > [1] - > > http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits?=all#about > > [2] - > > http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits?=python&id=1 > > [3] - > > http://shootout.alioth.debian.org/u32q/benchmark.php?test=pidigits?=python&id=3 > > > > > > _______________________________________________ > > pypy-dev at codespeak.net > > http://codespeak.net/mailman/listinfo/pypy-dev > > > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From cumber at netspace.net.au Thu Aug 13 04:27:06 2009 From: cumber at netspace.net.au (Ben Mellor) Date: Thu, 13 Aug 2009 12:27:06 +1000 Subject: [pypy-dev] running the pypy toolchain In-Reply-To: <1250124242.5102.152.camel@localhost> References: <1249773961.5218.9.camel@localhost> <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> <1250124242.5102.152.camel@localhost> Message-ID: <20090813122706.52d91ca1@intyalie> On Wed, 12 Aug 2009 17:44:02 -0700 Terrence Cole wrote: > On Tue, 2009-08-11 at 03:16 -0600, Maciej Fijalkowski wrote: > > Hi. > > > > It's really cool that you find pypy as a good platform for writing > > interpreters, we're definitely > > happy with that :-) In general, we try to remove stuff from lang > > rather then put more of it > > there. So js/smalltalk/befunge interpreters would hopefully soon > > become projects on > > its own. > > Thank you for the reply. I was thinking that the current situation in > the lang directory would be unmanagable and I was wondering what I was > missing :-). > > I have not run into any documentation on making the pypy toolchain run > from an installed location, rather than from the svn checkout dir. > Since I don't even understand how autopath works yet, I figured that > getting something more sophisticated working than what everyone else is > doing in the lang directory would be an adventure better left for later. > Is there a plan for making pypy installable? Is it already possible and > I just haven't looked hard enough? What I'm currently doing with an interpreter I'm messing around with is to just put the path to PyPy in my PYTHONPATH (I'm using the 1.1.0 release right now, but I think it would work for an svn checkout as well). That works for running on top of CPython, even with my interpreter project directory completely outside of the PyPy tree. Translating is a little less satisfactory. I have a makefile with the following: # Defualt place to look for PyPy being installed. PYPY_DIR := ~/pypy-1.1.0/ # Set target-specific variable to set the translation backend based on the name # of the target, e.g. fundy-jvm uses the jvm backend. fundy-%: BACKEND = --backend=$(@:fundy-%=%) # Default target: fundy translated with the C backend. .PHONY: default default: fundy-c fundy-%: *.py fundy.grammar python $(PYPY_DIR)/pypy/translator/goal/translate.py $(OPT) $(BACKEND) $(BATCH) $(TRANSLATE_FLAGS) target_fundy (plus a few default settings for the variables I haven't defined here, but they're pretty trivial), and a target_fundy.py file that provides the target(driver, args) function. Then I can just type make, or make fundy-jvm, etc, to get the interpreter translated for any backend (although the C one is the only one working on my system). I started with this project in the lang directory of a PyPy svn checkout, but when the 1.1.0 release was made and I ended up using my interpreter as the basis for a university essay on programming languages, it spurred me to figure out how to get it working as a more independent project. I didn't find much information in the PyPy docs on how to do this, I just hacked it together. If there are better ways of going about it, I'd like to know! I do have ~/pypy-1.1.0/pypy/bin in my PATH (translatorshell.py is just too nifty), and I have thought it would be handy if there were an entry point executable for the translation process in there as well. If translate.py or something equivalent was there, then installing PyPy would consist of untarring it, setting PYTHONPATH and PATH, and then interpreter projects could just use it a little more easily. I guess there's a difference between people who are installing the PyPy python interpreter, and those who are installing the PyPy translation toolchain. But what the docs say now about how to build things with the PyPy toolchain is to cd to pypy/bin/translator/goal and run translate.py targetfile, which looks a bit like to make things able to be translated you have to put a targetfile there (and it has to be able to import the rest of your project, which means either your project is in the PyPy tree, or it's on your PYTHONPATH). -- Ben From fijall at gmail.com Fri Aug 14 15:25:04 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Fri, 14 Aug 2009 07:25:04 -0600 Subject: [pypy-dev] befunge In-Reply-To: <1250124242.5102.152.camel@localhost> References: <1249773961.5218.9.camel@localhost> <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> <1250124242.5102.152.camel@localhost> Message-ID: <693bc9ab0908140625k2313ae2cp8d0db5ed8e891b2a@mail.gmail.com> On Wed, Aug 12, 2009 at 6:44 PM, Terrence Cole wrote: > On Tue, 2009-08-11 at 03:16 -0600, Maciej Fijalkowski wrote: >> Hi. >> >> It's really cool that you find pypy as a good platform for writing >> interpreters, we're definitely >> happy with that :-) In general, we try to remove stuff from lang >> rather then put more of it >> there. So js/smalltalk/befunge interpreters would hopefully soon >> become projects on >> its own. > > Thank you for the reply. ?I was thinking that the current situation in > the lang directory would be unmanagable and I was wondering what I was > missing :-). > > I have not run into any documentation on making the pypy toolchain run > from an installed location, rather than from the svn checkout dir. > Since I don't even understand how autopath works yet, I figured that > getting something more sophisticated working than what everyone else is > doing in the lang directory would be an adventure better left for later. > Is there a plan for making pypy installable? ?Is it already possible and > I just haven't looked hard enough? > We should make it installable by say easy_install at some point, but for now you either need to set PYTHONPATH env variable, or simply add something like: import sys sys.path.insert(0, ) on top of your script. Cheers, fijal From list-sink at trainedmonkeystudios.org Fri Aug 14 23:44:15 2009 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Fri, 14 Aug 2009 14:44:15 -0700 Subject: [pypy-dev] running the pypy toolchain In-Reply-To: <20090813122706.52d91ca1@intyalie> References: <1249773961.5218.9.camel@localhost> <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> <1250124242.5102.152.camel@localhost> <20090813122706.52d91ca1@intyalie> Message-ID: <1250286255.5167.29.camel@localhost> On Thu, 2009-08-13 at 12:27 +1000, Ben Mellor wrote: > On Wed, 12 Aug 2009 17:44:02 -0700 > Terrence Cole wrote: > > > On Tue, 2009-08-11 at 03:16 -0600, Maciej Fijalkowski wrote: > > > Hi. > > > > > > It's really cool that you find pypy as a good platform for writing > > > interpreters, we're definitely > > > happy with that :-) In general, we try to remove stuff from lang > > > rather then put more of it > > > there. So js/smalltalk/befunge interpreters would hopefully soon > > > become projects on > > > its own. > > > > Thank you for the reply. I was thinking that the current situation in > > the lang directory would be unmanagable and I was wondering what I was > > missing :-). > > > > I have not run into any documentation on making the pypy toolchain run > > from an installed location, rather than from the svn checkout dir. > > Since I don't even understand how autopath works yet, I figured that > > getting something more sophisticated working than what everyone else is > > doing in the lang directory would be an adventure better left for later. > > Is there a plan for making pypy installable? Is it already possible and > > I just haven't looked hard enough? > > What I'm currently doing with an interpreter I'm messing around with is to just > put the path to PyPy in my PYTHONPATH (I'm using the 1.1.0 release right now, > but I think it would work for an svn checkout as well). That works for running > on top of CPython, even with my interpreter project directory completely > outside of the PyPy tree. That did the trick! My test suite is a bit of a kludge now though since I can't reference my interpreter from an absolute pypy path. I have added .. to my sys.path manually to get them working again, but it's very ugly. Is there a better way to handle this? > Translating is a little less satisfactory. I have a makefile with the following: > > > # Defualt place to look for PyPy being installed. > PYPY_DIR := ~/pypy-1.1.0/ > > # Set target-specific variable to set the translation backend based on the name > # of the target, e.g. fundy-jvm uses the jvm backend. > fundy-%: BACKEND = --backend=$(@:fundy-%=%) > > # Default target: fundy translated with the C backend. > .PHONY: default > default: fundy-c > > fundy-%: *.py fundy.grammar > python $(PYPY_DIR)/pypy/translator/goal/translate.py $(OPT) $(BACKEND) > $(BATCH) $(TRANSLATE_FLAGS) target_fundy > > > (plus a few default settings for the variables I haven't defined here, but > they're pretty trivial), and a target_fundy.py file that provides the > target(driver, args) function. > > Then I can just type make, or make fundy-jvm, etc, to get the interpreter > translated for any backend (although the C one is the only one working on my > system). > > I started with this project in the lang directory of a PyPy svn checkout, but > when the 1.1.0 release was made and I ended up using my interpreter as the > basis for a university essay on programming languages, it spurred me to figure > out how to get it working as a more independent project. > > I didn't find much information in the PyPy docs on how to do this, I just > hacked it together. If there are better ways of going about it, I'd like to > know! I suppose using PYTHONPATH should be obvious, in retrospect. Usually, when I have these sorts of problems, I create a setup.py and just get everything installed into site-packages. In fact, I do think that having pypy in an installed location would be more satisfying than messing with the path, but I suppose this works for now. > I do have ~/pypy-1.1.0/pypy/bin in my PATH (translatorshell.py is just too > nifty), and I have thought it would be handy if there were an entry point > executable for the translation process in there as well. If translate.py or > something equivalent was there, then installing PyPy would consist of untarring > it, setting PYTHONPATH and PATH, and then interpreter projects could just use > it a little more easily. Agreed. It would be very nice to have a pypy.translate program in /usr/bin. There are some (non-interpreter) projects I would consider writing in RPython just for the performance benefits of translation. > I guess there's a difference between people who are installing the PyPy python > interpreter, and those who are installing the PyPy translation toolchain. Very true. If all you want is pypy-*, how much more do you need installed than the executable and the modules directory? > But > what the docs say now about how to build things with the PyPy toolchain is to > cd to pypy/bin/translator/goal and run translate.py targetfile, which > looks a bit like to make things able to be translated you have to put a > targetfile there (and it has to be able to import the rest of your project, > which means either your project is in the PyPy tree, or it's on your > PYTHONPATH). That was exactly my thinking as well. > -- Ben Thank you for the help. That was exactly what I needed and I'm very glad I did not have to go blundering about relearning all of that for myself. - Terrence > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From fijall at gmail.com Mon Aug 17 22:51:50 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Mon, 17 Aug 2009 14:51:50 -0600 Subject: [pypy-dev] running the pypy toolchain In-Reply-To: <1250286255.5167.29.camel@localhost> References: <1249773961.5218.9.camel@localhost> <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> <1250124242.5102.152.camel@localhost> <20090813122706.52d91ca1@intyalie> <1250286255.5167.29.camel@localhost> Message-ID: <693bc9ab0908171351j9cda52cyf37f590d31cbfbb@mail.gmail.com> On Fri, Aug 14, 2009 at 3:44 PM, Terrence Cole wrote: > On Thu, 2009-08-13 at 12:27 +1000, Ben Mellor wrote: >> On Wed, 12 Aug 2009 17:44:02 -0700 >> Terrence Cole wrote: >> >> > On Tue, 2009-08-11 at 03:16 -0600, Maciej Fijalkowski wrote: >> > > Hi. >> > > >> > > It's really cool that you find pypy as a good platform for writing >> > > interpreters, we're definitely >> > > happy with that :-) In general, we try to remove stuff from lang >> > > rather then put more of it >> > > there. So js/smalltalk/befunge interpreters would hopefully soon >> > > become projects on >> > > its own. >> > >> > Thank you for the reply. ?I was thinking that the current situation in >> > the lang directory would be unmanagable and I was wondering what I was >> > missing :-). >> > >> > I have not run into any documentation on making the pypy toolchain run >> > from an installed location, rather than from the svn checkout dir. >> > Since I don't even understand how autopath works yet, I figured that >> > getting something more sophisticated working than what everyone else is >> > doing in the lang directory would be an adventure better left for later. >> > Is there a plan for making pypy installable? ?Is it already possible and >> > I just haven't looked hard enough? >> >> What I'm currently doing with an interpreter I'm messing around with is to just >> put the path to PyPy in my PYTHONPATH (I'm using the 1.1.0 release right now, >> but I think it would work for an svn checkout as well). That works for running >> on top of CPython, even with my interpreter project directory completely >> outside of the PyPy tree. > > That did the trick! ?My test suite is a bit of a kludge now though since > I can't reference my interpreter from an absolute pypy path. ?I have > added .. to my sys.path manually to get them working again, but it's > very ugly. ?Is there a better way to handle this? > I'm not sure, but PYTHONPATH can handle multiple paths, like: PYTHONPATH=path_a:path_b is this what you wanted? Cheers, fijal From glavoie at gmail.com Tue Aug 18 04:55:08 2009 From: glavoie at gmail.com (Gabriel Lavoie) Date: Mon, 17 Aug 2009 22:55:08 -0400 Subject: [pypy-dev] sys.prefix Message-ID: Hello, I have this tool to test on PyPy: http://furius.ca/snakefood/ It seems the code requires "sys.prefix" but it seems it doesn't exists on PyPy. Is it normal? I will probably be able to make the code work without this. >>>> import sys >>>> sys.prefix Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'prefix' Thank you, Gabriel -- Gabriel Lavoie glavoie at gmail.com From list-sink at trainedmonkeystudios.org Thu Aug 20 09:30:20 2009 From: list-sink at trainedmonkeystudios.org (Terrence Cole) Date: Thu, 20 Aug 2009 00:30:20 -0700 Subject: [pypy-dev] running the pypy toolchain In-Reply-To: <693bc9ab0908171351j9cda52cyf37f590d31cbfbb@mail.gmail.com> References: <1249773961.5218.9.camel@localhost> <693bc9ab0908110216g502d4535q10d19bcbe2a03f9f@mail.gmail.com> <1250124242.5102.152.camel@localhost> <20090813122706.52d91ca1@intyalie> <1250286255.5167.29.camel@localhost> <693bc9ab0908171351j9cda52cyf37f590d31cbfbb@mail.gmail.com> Message-ID: <1250753420.22582.32.camel@localhost> On Mon, 2009-08-17 at 14:51 -0600, Maciej Fijalkowski wrote: > On Fri, Aug 14, 2009 at 3:44 PM, Terrence > Cole wrote: > > On Thu, 2009-08-13 at 12:27 +1000, Ben Mellor wrote: > >> On Wed, 12 Aug 2009 17:44:02 -0700 > >> Terrence Cole wrote: > >> > >> > On Tue, 2009-08-11 at 03:16 -0600, Maciej Fijalkowski wrote: > >> > > Hi. > >> > > > >> > > It's really cool that you find pypy as a good platform for writing > >> > > interpreters, we're definitely > >> > > happy with that :-) In general, we try to remove stuff from lang > >> > > rather then put more of it > >> > > there. So js/smalltalk/befunge interpreters would hopefully soon > >> > > become projects on > >> > > its own. > >> > > >> > Thank you for the reply. I was thinking that the current situation in > >> > the lang directory would be unmanagable and I was wondering what I was > >> > missing :-). > >> > > >> > I have not run into any documentation on making the pypy toolchain run > >> > from an installed location, rather than from the svn checkout dir. > >> > Since I don't even understand how autopath works yet, I figured that > >> > getting something more sophisticated working than what everyone else is > >> > doing in the lang directory would be an adventure better left for later. > >> > Is there a plan for making pypy installable? Is it already possible and > >> > I just haven't looked hard enough? > >> > >> What I'm currently doing with an interpreter I'm messing around with is to just > >> put the path to PyPy in my PYTHONPATH (I'm using the 1.1.0 release right now, > >> but I think it would work for an svn checkout as well). That works for running > >> on top of CPython, even with my interpreter project directory completely > >> outside of the PyPy tree. > > > > That did the trick! My test suite is a bit of a kludge now though since > > I can't reference my interpreter from an absolute pypy path. I have > > added .. to my sys.path manually to get them working again, but it's > > very ugly. Is there a better way to handle this? > > > > I'm not sure, but PYTHONPATH can handle multiple paths, like: > PYTHONPATH=path_a:path_b > > is this what you wanted? I think it would work, but maybe I should just describe what I'm trying to do. My tests are in befunge/tests/. I need to import the interpreter from befunge/Interpreter.py. Before, I just dropped autopath.py into tests and did 'import pypy.lang.befunge.Interpreter'. Now that autopath is not an option, I need some way to tell my tests to look in ../ for interpreter sources. I was hoping there was a common idiom less cringeworthy than sys.path=['..']+sys.path. It seems like this would be a common problem, but maybe I'm just over-thinking it. > Cheers, > fijal Thanks, Terrence From lac at openend.se Wed Aug 26 20:05:13 2009 From: lac at openend.se (Laura Creighton) Date: Wed, 26 Aug 2009 20:05:13 +0200 Subject: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been Message-ID: <200908261805.n7QI5D6Z012094@theraft.openend.se> delayed by one day. KLM is putting him up someplace. So says his mother in email to me. Laura From fijall at gmail.com Thu Aug 27 00:38:29 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Wed, 26 Aug 2009 16:38:29 -0600 Subject: [pypy-dev] [pypy-svn] r67223 - pypy/build/bot2/pypybuildbot In-Reply-To: <20090826200940.6104F168032@codespeak.net> References: <20090826200940.6104F168032@codespeak.net> Message-ID: <693bc9ab0908261538o8ed7252l5db2919e7c954dc1@mail.gmail.com> Are you aware that this breaks some other tests, because our asmgcc does not provide a way to have a callback (and ie xml parser is based on ctypes & callbacks). Cheers, fijal On Wed, Aug 26, 2009 at 2:09 PM, wrote: > Author: arigo > Date: Wed Aug 26 22:09:39 2009 > New Revision: 67223 > > Modified: > ? pypy/build/bot2/pypybuildbot/builds.py > Log: > Translate pypy-c-jit with our own GC now, to avoid seeing in lib-python > the memory-not-freed-early-enough bugs common to pypy-c-boehm. > > > Modified: pypy/build/bot2/pypybuildbot/builds.py > ============================================================================== > --- pypy/build/bot2/pypybuildbot/builds.py ? ? ?(original) > +++ pypy/build/bot2/pypybuildbot/builds.py ? ? ?Wed Aug 26 22:09:39 2009 > @@ -200,7 +200,7 @@ > > ? ? ? ? setup_steps(platform, self) > > - ? ? ? ?self.addStep(Translate(['-Ojit', '--gc=boehm'], > + ? ? ? ?self.addStep(Translate(['-Ojit', '--gc=hybrid','--gcrootfinder=asmgcc'], > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?['--withoutmod-thread'])) > > ? ? ? ? self.addStep(ShellCmd( > _______________________________________________ > pypy-svn mailing list > pypy-svn at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn > From jacob at openend.se Thu Aug 27 13:14:15 2009 From: jacob at openend.se (Jacob =?utf-8?q?Hall=C3=A9n?=) Date: Thu, 27 Aug 2009 13:14:15 +0200 Subject: [pypy-dev] New performance monitoring functionality in Linux kernel 2.6.31 Message-ID: <200908271314.15330.jacob@openend.se> The upcoming Linux kernel release has functionality for monitoring low level events like cache misses, page faults, instructions and cycles. It may be useful in future development and debugging of the PyPy JIT. The new kernel is expected to be released in about 2 weeks. All relevant links can be found in this article: http://www.h-online.com/open/Kernel-Log-Coming-in-2-6-31-Part-4-Tracing- architecture-virtualisation--/news/114082 Jacob From benjamin at python.org Thu Aug 27 23:12:52 2009 From: benjamin at python.org (Benjamin Peterson) Date: Thu, 27 Aug 2009 16:12:52 -0500 Subject: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been In-Reply-To: <200908261805.n7QI5D6Z012094@theraft.openend.se> References: <200908261805.n7QI5D6Z012094@theraft.openend.se> Message-ID: <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> 2009/8/26 Laura Creighton : > delayed by one day. ?KLM is putting him up someplace. ?So says his > mother in email to me. Is this information really relevant to PyPy development? Even if my mother decides to send my "personal" messages to half the world, you don't have to help her. :) -- Regards, Benjamin From phyo.arkarlwin at gmail.com Fri Aug 28 04:45:30 2009 From: phyo.arkarlwin at gmail.com (Phyo Arkar) Date: Fri, 28 Aug 2009 02:45:30 +0000 Subject: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been In-Reply-To: <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> References: <200908261805.n7QI5D6Z012094@theraft.openend.se> <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> Message-ID: LOL On 8/27/09, Benjamin Peterson wrote: > 2009/8/26 Laura Creighton : >> delayed by one day. ?KLM is putting him up someplace. ?So says his >> mother in email to me. > > Is this information really relevant to PyPy development? Even if my > mother decides to send my "personal" messages to half the world, you > don't have to help her. :) > > > > -- > Regards, > Benjamin > _______________________________________________ > pypy-dev at codespeak.net > http://codespeak.net/mailman/listinfo/pypy-dev From lac at openend.se Fri Aug 28 06:19:44 2009 From: lac at openend.se (Laura Creighton) Date: Fri, 28 Aug 2009 06:19:44 +0200 Subject: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been In-Reply-To: Message from Benjamin Peterson of "Thu, 27 Aug 2009 16:12:52 CDT." <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> References: <200908261805.n7QI5D6Z012094@theraft.openend.se> <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> Message-ID: <200908280419.n7S4Jis4009242@theraft.openend.se> In a message of Thu, 27 Aug 2009 16:12:52 CDT, Benjamin Peterson writes: >2009/8/26 Laura Creighton : >> delayed by one day. ??KLM is putting him up someplace. ??So says his >> mother in email to me. > >Is this information really relevant to PyPy development? Even if my >mother decides to send my "personal" messages to half the world, you >don't have to help her. :) > > > >-- >Regards, >Benjamin Sorry, I meant to sent that to pypy-z. My fault. Laura From holger at merlinux.eu Fri Aug 28 09:12:27 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 28 Aug 2009 09:12:27 +0200 Subject: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been In-Reply-To: <200908280419.n7S4Jis4009242@theraft.openend.se> References: <200908261805.n7QI5D6Z012094@theraft.openend.se> <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> <200908280419.n7S4Jis4009242@theraft.openend.se> Message-ID: <20090828071227.GT15455@trillke.net> On Fri, Aug 28, 2009 at 06:19 +0200, Laura Creighton wrote: > Sorry, I meant to sent that to pypy-z. My fault. to clarify what laura refers to here: pypy-z is an internal mailing list for discussing pypy funding, contracts, proposals and such. Most who are regular pypy contributors are members of that list. best, holger From lac at openend.se Fri Aug 28 10:16:59 2009 From: lac at openend.se (Laura Creighton) Date: Fri, 28 Aug 2009 10:16:59 +0200 Subject: [pypy-dev] Benjamin's flight from Amsterdam to Minneapolis has been In-Reply-To: Message from holger krekel of "Fri, 28 Aug 2009 09:12:27 +0200." <20090828071227.GT15455@trillke.net> References: <200908261805.n7QI5D6Z012094@theraft.openend.se> <1afaf6160908271412s2a772dd8r1bdee11248a65b8f@mail.gmail.com> <200908280419.n7S4Jis4009242@theraft.openend.se> <20090828071227.GT15455@trillke.net> Message-ID: <200908280816.n7S8GxpN024517@theraft.openend.se> In a message of Fri, 28 Aug 2009 09:12:27 +0200, holger krekel writes: >On Fri, Aug 28, 2009 at 06:19 +0200, Laura Creighton wrote: >> Sorry, I meant to sent that to pypy-z. My fault. > >to clarify what laura refers to here: pypy-z is an internal >mailing list for discussing pypy funding, contracts, >proposals and such. Most who are regular pypy >contributors are members of that list. > >best, >holger Ah yes, thanks for the clarification, Holger. Laura