From hpk at trillke.net Tue Nov 1 09:31:03 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 1 Nov 2005 08:31:03 +0000 Subject: [pypy-dev] Re: [pypy-svn] r19249 - pypy/release/0.8.x/pypy/doc In-Reply-To: <20051031154524.BE85127B64@code1.codespeak.net> References: <20051031154524.BE85127B64@code1.codespeak.net> Message-ID: <20051101083103.GI5863@hpk.local> On Mon, Oct 31, 2005 at 16:45 +0100, ale at codespeak.net wrote: > Author: ale > Date: Mon Oct 31 16:45:24 2005 > New Revision: 19249 > > Modified: > pypy/release/0.8.x/pypy/doc/release-0.8.0.txt > Log: > First draft of release announcement. > > I have trunkated the contributor list to the 6 most active developer and point to contributor.html for the rest. > > Please comment I think at least 8 or 10 people should be listed. Btw, I once had a different (half-manual) process of determining contributions by using "svn blame" and counting the lines. One has to be careful, though, because we have some large files (like the unicode-database) which are not really programmed code and distort the statistics. cheers, holger From hpk at trillke.net Tue Nov 1 09:36:11 2005 From: hpk at trillke.net (holger krekel) Date: Tue, 1 Nov 2005 08:36:11 +0000 Subject: [pypy-dev] rel 0.8 coord meeting, 2pm GMT+1 monday 31 Oct 2005 on #pypy In-Reply-To: <43652AD0.2020002@strakt.com> References: <43652AD0.2020002@strakt.com> Message-ID: <20051101083611.GJ5863@hpk.local> Hi Samuele, hi all, On Sun, Oct 30, 2005 at 21:19 +0100, Samuele Pedroni wrote: > As already pointed out the scope of the 0.8 release is mainly: > > - Ship our integrated and now translated AST compiler There is one thing i see missing and i think it wasn't discussed at the release meeting: (more) documentation about the AST compiler. This seems sensible especially if the focus of the release is the AST compiler ... Adrien, Ludovic, do you already have something? ASFAIK we only have rough documentation on the Parser (in parser.txt) but none on the compiler?! Maybe we can take a bit from CPython and amend it to include references to our file locations and some translation aspects/motivations for our changes? > - Ship the speed improvements we had since 0.7, which mainly > means updating the documentation that discuss current speed also here i believe it should be explained what the main steps were to obtain the major speed improvements. cheers, holger From pedronis at strakt.com Tue Nov 1 19:00:55 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Tue, 01 Nov 2005 19:00:55 +0100 Subject: [pypy-dev] I have updated the LICENSE file for 0.8 and copyright holders list Message-ID: <4367AD57.6030909@strakt.com> http://codespeak.net/pipermail/pypy-svn/2005-November/009556.html this lists the copyright holders (we have a different list of contributor that contains all contributors, including people that just did small contributions or didn't want to be listed as copyright holders). The additions are mostly people that were at the Paris sprint and contributed there. If people don't want to be listed please tell us so, as people did in the past. regards, Samuele Pedroni. From cfbolz at gmx.de Thu Nov 3 00:56:54 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 03 Nov 2005 00:56:54 +0100 Subject: [pypy-dev] pypy sync meeting on 3th November, 2005 Message-ID: <43695246.6040801@gmx.de> Hi PyPy-dev! yet another wonderful pypy-sync meeting is coming! Please be all there and send me a mail with your activity report if you cannot come. ========================================= pypy-sync developer meeting 3th November ========================================= Time & location: 1.00 - 1.30 pm (GMT+2) at #pypy-sync Regular Topics ==================== - activity reports (3 prepared lines of info, LAST/NEXT/BLOCKERS). - resolve conflicts/blockers Annotated Topics of the week ================================= gothenburg sprint top.ics -------------------------- (topic suggested by Bea, moved over from last week) We have a sprint planned at the beginning of December in Gothenburg. What should the topics of the sprint be? Will it be a more open sprint or more rather targeted at core developpers? finalizing the release -------------------------- The release seems to be progressing very well, there are some small final tasks to be distributed, like who sends out the announcement mails, etc. See you all tomorrow, Carl Friedrich From cfbolz at gmx.de Thu Nov 3 12:04:55 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 03 Nov 2005 12:04:55 +0100 Subject: [pypy-dev] pypy sync meeting on 3th November, 2005 In-Reply-To: <43695246.6040801@gmx.de> References: <43695246.6040801@gmx.de> Message-ID: <4369EED7.7070201@gmx.de> Carl Friedrich Bolz wrote: > ========================================= > pypy-sync developer meeting 3th November > ========================================= > > Time & location: 1.00 - 1.30 pm (GMT+2) at #pypy-sync argh! I missed the daylight saving time change. the meeting will be 1.00-1.30 pm (GMT+1). sorry for the confusion (and thanks michael for telling me). cheers, Carl Friedrich From pedronis at strakt.com Thu Nov 3 14:09:14 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Thu, 03 Nov 2005 14:09:14 +0100 Subject: [pypy-dev] PyPy 0.8.0 just released Message-ID: <436A0BFA.2010307@strakt.com> Thanks to all the people that contributed so far to PyPy and especially to the people that helped on this release. pypy-0.8.0: Translatable compiler/parser and some more speed ============================================================== The PyPy development team has been busy working and we've now packaged our latest improvements, completed work and new experiments as version 0.8.0, our third public release. The highlights of this third release of PyPy are: - Translatable parser and AST compiler. PyPy now integrates its own compiler based on Python own 'compiler' package but with a number of fixes and code simplifications in order to get it translated with the rest of PyPy. This makes using the translated pypy interactively much more pleasant, as compilation is considerably faster than in 0.7.0. - Some Speed enhancements. Translated PyPy is now about 10 times faster than 0.7 but still 10-20 times slower than CPython on pystones and other benchmarks. At the same time, language compliancy has been slightly increased compared to 0.7 which had already reached major CPython compliancy goals. - Some experimental features are now translateable. Since 0.6.0, PyPy shipped with an experimental Object Space (the part of PyPy implementing Python object operations and manipulation) implementing lazily computed objects, the "Thunk" object space. With 0.8.0 this object space can also be translated preserving its feature additions. What is PyPy (about)? ------------------------------------------------ PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, Memory and Threading models are to become aspects of the translation process - as opposed to encoding low level details into a language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. PyPy is partially funded as a research project under the European Union's IST programme. Where to start? ----------------------------- Getting started: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.8 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals --------------------------------- At the last sprint in Paris we started exploring the new directions of our work, in terms of extending and optimising PyPy further. We started to scratch the surface of Just-In-Time compiler related work, which we still expect will be the major source of our future speed improvements and some successful amount of work has been done on the support needed for stackless-like features. This release also includes the snapshots in preliminary or embryonic form of the following interesting but yet not completed sub projects: - The OOtyper, a RTyper variation for higher-level backends (Squeak, ...) - A JavaScript backend - A limited (PPC) assembler backend (this related to the JIT) - some bits for a socket module PyPy has been developed during approximately 16 coding sprints across Europe and the US. It continues to be a very dynamically and incrementally evolving project with many of these one-week workshops to follow. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html have fun, the pypy team, (Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz, Michael Hudson, and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html) PyPy development and activities happen as an open source project and with the support of a consortium partially funded by a two year European Union IST research grant. The full partners of that consortium are: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH (Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden), Impara (Germany) From mwh at python.net Fri Nov 4 12:45:39 2005 From: mwh at python.net (Michael Hudson) Date: Fri, 04 Nov 2005 11:45:39 +0000 Subject: [pypy-dev] This Week in PyPy 1 Message-ID: <2m4q6s3acc.fsf@starship.python.net> (this summary is also on the web at http://codespeak.net/pypy/dist/pypy/doc/weekly/summary-2005-11-04.html) Introduction ============ This is the first of what will hopefully be many summaries of what's been going on in the world of PyPy in the last week. First, I'd like to make a request: help me write these things. As is mentioned in the page about This Week in PyPy: http://codespeak.net/pypy/dist/pypy/doc/weekly/ as and when something worth summarizing happens, be it on IRC, on a mailing list or off in the blogosphere, add an entry to this file: http://codespeak.net/pypy/dist/pypy/doc/weekly/log (if you can) or email me about it (if you can't). This week noone at all has done anything like this, which I'll forgive because it's the first week :) Please, please do get into the habit of doing this though, at least if you think writing this summary isn't a complete waste of time. Release of PyPy 0.8.0 ===================== The biggest thing that's happened in the past week was clearly the release of PyPy 0.8.0. You can read the release announcement at: http://codespeak.net/pypy/dist/pypy/doc/release-0.8.0.html This release went fairly smoothly compared to some releases, mainly because we weren't rushing to get some feature or other into the release. Import Analysis =============== In an effort to understand what code is used where in PyPy, Michael Hudson wrote a tool to analyse the import structure of PyPy, culminating in a several megabyte HTML report which you can find at: http://starship.python.net/crew/mwh/importfunhtml/pypy/ For example, this is a list of all the modules that reference pypy.objspace.flow.model.Constant (one of the more referenced names in PyPy): http://starship.python.net/crew/mwh/importfunhtml/pypy/objspace/flow/model/Constant.html Of course, this work ended up duplicating some of the things done by tools such as pylint and pyflakes and has the potential to be useful for projects other than PyPy, so I hope to clean it up and maybe make it a pylint plugin soon-ish. A RPythonC tool? ================ A fairly common topic of discussion on #pypy starts with people who want to write RPython code and then use PyPy to translate it to efficient C. This was again the case on Monday evening (look from about 19:30 onwards): http://tismerysoft.de/pypy/irc-logs/pypy/%23pypy.log.20051031 While "officially speaking" supporting such things is not a goal of the PyPy project (RPython is essentially an implementation detail) the frequency of raising of the subject means that there probably is some interest in a "rpythonc" type tool that would compile an RPython program. A fairly serious problem, though, is that when the target of compilation turns out not to be RPython, working out *why* can be arbitrarily difficult, even for an experienced PyPyer. For these reasons, it seems unlikely that such a tool will be written all that soon (at least, I'm not going to do it :). PyPy-sync ========= The main discussion at the weekly pypy-sync meeting was planning for the G?teborg sprint in December: http://codespeak.net/pypy/extradoc/minute/pypy-sync-11-03-2005.txt -- if python is an orchestra, overloaded operators are "miscellaneous percussion" -- from Twisted.Quotes From arigo at tunes.org Sat Nov 5 10:06:13 2005 From: arigo at tunes.org (Armin Rigo) Date: Sat, 5 Nov 2005 10:06:13 +0100 Subject: [pypy-dev] Document drafts Message-ID: <20051105090613.GA20442@code1.codespeak.net> Hi all, People following only this mailing list may have missed some draft documents that we have been working on, as they are not linked to yet: http://codespeak.net/pypy/dist/pypy/doc/draft-dynamic-language-translation.html http://codespeak.net/pypy/dist/pypy/doc/draft-low-level-encapsulation.html A bientot, Armin From arigo at tunes.org Sat Nov 5 10:16:54 2005 From: arigo at tunes.org (Armin Rigo) Date: Sat, 5 Nov 2005 10:16:54 +0100 Subject: [pypy-dev] Feature-comparatives benchmarks Message-ID: <20051105091654.GB20442@code1.codespeak.net> Hi all, Even though it is short, I think that the draft-low-level-encapsulation would look complete enough if it had, for each described aspect: * a link to the doc (I'll add them); * some concrete benchmarks, in an "Experimental results" section, to see what would be the performance/memory impact of enabling each feature or leaving it out of the compiled PyPy. As far as I know our benchmark results are not nicely regrouped at some place, so I suggest we collect them on this mailing list. We need: * Stacklessness: what are the most up-to-date results? * Multiple Interpreters: I guess no one tried so far to compile in a mode where the 'space' variables don't go away. Let's. * Concurrency: not much data here apart from the massive unexplained overhead of enabling threads. * Memory Management: refcounting is veeery slow, which only shows that we could do much better there given sufficient efforts... * Evaluation Strategy: the thunk object space. Overhead? A bientot, Armin. From nicolas.chauvat at logilab.fr Sun Nov 6 16:53:14 2005 From: nicolas.chauvat at logilab.fr (Nicolas Chauvat) Date: Sun, 6 Nov 2005 16:53:14 +0100 Subject: [pypy-dev] Re: even more import analysis In-Reply-To: <2m3bml4tnd.fsf@starship.python.net> References: <2moe5a4q33.fsf@starship.python.net> <200510281048.26633.jacob@strakt.com> <2m7jby3th8.fsf@starship.python.net> <20051028133421.GU25315@logilab.fr> <2m3bml4tnd.fsf@starship.python.net> Message-ID: <20051106155314.GA18838@logilab.fr> On Fri, Oct 28, 2005 at 03:12:54PM +0100, Michael Hudson wrote: > reporting/documenting and maybe, maybe automated refactoring rather > than warning though -- in which light, have you used Bicycle Repair > Man much? It does work but for simple things only. Pylint has been trying to detect code smells for a couple releases btw :) Refactoring/optimising at AST level is something I would spend time playing with based on pypy... if only I could find time. -- Nicolas Chauvat logilab.fr - services en informatique avanc?e et gestion de connaissances From pedronis at strakt.com Wed Nov 9 20:43:08 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Wed, 09 Nov 2005 20:43:08 +0100 Subject: [pypy-dev] will not be present at tomorrow pypy-sync meeting Message-ID: <4372514C.6040809@strakt.com> I'm going to be on vacation, until wenesday/thursday of next week. I should be at the meeting then. Last I worked on reports (in particular 4.4) and helped with the PBC refactoring branch. Samuele. From cfbolz at gmx.de Thu Nov 10 11:24:55 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Thu, 10 Nov 2005 11:24:55 +0100 Subject: [pypy-dev] pypy sync Message-ID: <43731FF7.4090805@gmx.de> Hi pypy-devers! although the announcement is late, there will be a pypy-sync meeting today: Time & location: 1.00 - 1.30 pm (GMT+1) at #pypy-sync Regular Topics ==================== - activity reports (3 prepared lines of info, LAST/NEXT/BLOCKERS). - resolve conflicts/blockers Annotated Topics of the week ================================= New snake server ---------------- this is an informational topic: armin wants to tell us what is going on with the snake server. There are no further official topics today, you are free to come up with anything on short notice. Cheers, Carl Friedrich From mwh at python.net Fri Nov 11 16:39:17 2005 From: mwh at python.net (Michael Hudson) Date: Fri, 11 Nov 2005 15:39:17 +0000 Subject: [pypy-dev] This Week in PyPy 2 Message-ID: <2mek5nyz16.fsf@starship.python.net> Introduction ============ This is the second of what will hopefully be many summaries of what's been going on in the world of PyPy in the last week. I'd still like to remind people that when something worth summarizing happens to recommend if for "This Week in PyPy" as mentioned on: http://codespeak.net/pypy/dist/pypy/doc/weekly/ where you can also find old summaries. There were about 100 commits to the pypy section of codespeak's repository this week. pypy-c py.py ============ Over the weekend (while I was being blown around Wales by the remnants of hurricane Wilma) Armin and a few others worked on trying to get a translated pypy-c to run the interpreted py.py. This resulted in a fixing a welter of small differences between CPython and pypy-c, though at the end of it all "we are still left in the dark of incomprehensible geninterplevel crashes caused by subtle differences between the most internal types of CPython and pypy-c." Multiple Spaces =============== In one of the reports we're currently writing for the end of phase 1 EU review: http://codespeak.net/pypy/dist/pypy/doc/draft-low-level-encapsulation.html we made this claim: The situation of multiple interpreters is thus handled automatically: if there is only one space instance, it is regarded as a pre-constructed constant and the space object pointer (though not its non-constant contents) disappears from the produced source, i.e. both from function arguments and local variables and from instance fields. If there are two or more such instances, a 'space' attribute will be automatically added to all application objects (or more precisely, it will not be removed by the translation process), the best of both worlds. And then we tried to do it, and had to tune the claim down because it doesn't work. This is because the StdObjSpace class has a 'specialized method' -- a different version of the wrap() method is generated for each type it is seen to be called with. This causes problems when there are genuine StdObjSpace instances in the translated pypy because of limitations in our tools. We looked at these limitations and decided that it was time to rewrite the world again, leading in to the next section... SomePBC-refactoring =================== One of the more unusual annotations produced by PyPy's annotator is that of 'SomePBC', short for 'SomePrebuiltConstant'. This annotation means that a variable contains a reference to some object that existed before the annotation process began (key example: functions). Up until now, the annotation has actually explicitly included which prebuiltconstants a variable might refer to, which seems like the obvious thing to do. Unfortunately, not all things that we'd like to annotate as a prebuiltconstant actually exist as unique CPython objects -- in particular the point of specializing a function is that it becomes many functions in the translated result. Also for 'external', i.e. not written in RPython, functions we want to be able to supply annotations for the input and exit args even if there is no corresponding CPython function at all. The chosen solution is to have the SomePBC annotation refer not to a CPython object but to a more abstracted 'Description' of this object. In some sense, this isn't a very large change but it affects most files in the annotation directory and a fair fraction of those under rpython/ and translator/. We're also cleaning up some other mess while we're there and breaking everything anyway. Draft-Dynamic-... ================= It's not linked from anywhere on the website (yet...) but the report that will become "Deliverable 05.1": http://codespeak.net/pypy/dist/pypy/doc/draft-dynamic-language-translation.html has been reviewed and re-reviewed in the last couple of weeks and is definitely required reading for anyone who has an interest in the more theoretical side of PyPy. Gtbg Sprint in December ======================= Hopefully very soon, we'll announce the next PyPy sprint... stay tuned! Cheers, mwh -- > I'm a little confused. That's because you're Australian! So all the blood flows to your head, away from the organ most normal guys think with. -- Mark Hammond & Tim Peters, comp.lang.python From noamraph at gmail.com Sun Nov 13 00:44:32 2005 From: noamraph at gmail.com (Noam Raphael) Date: Sun, 13 Nov 2005 01:44:32 +0200 Subject: [pypy-dev] PyPy newbie question: How to play with types Message-ID: Hello, I want to use PyPy as a way of trying a change I will propose to Python. It includes a bit of messing with types. For example, I want to make a new type called frozendict, and another new type, basedict. frozendict and dict will be subclasses of basedict. basedict will not be instantiable, but will implement all the dict methods that do not change the dict. frozendict will add a single operation to basedict - it will be hashable. dict will be the same as the dict today, but since many operations will be inherited from basedict, it will be shorter. I also want to add a new built-in, frozen(x), that will simply call x.__frozen__(). I have looked into the directories. I have found pypy/objspace/dict{object,type}.py. My questions are: 1. How do I make new built-in types, play with their inheritence, make them uninstantiable? Should I register it somewhere? 2. Where do I add a new built-in like frozen()? How should I make it callable from interpreter-level code? Thanks a lot, Noam From arigo at tunes.org Sun Nov 13 18:12:05 2005 From: arigo at tunes.org (Armin Rigo) Date: Sun, 13 Nov 2005 18:12:05 +0100 Subject: [pypy-dev] PyPy newbie question: How to play with types In-Reply-To: References: Message-ID: <20051113171205.GA10173@code1.codespeak.net> Hi Noam, On Sun, Nov 13, 2005 at 01:44:32AM +0200, Noam Raphael wrote: > I want to use PyPy as a way of trying a change I will propose to > Python. I suppose that's what we are supposed to make easier :-) Understanding all the details of PyPy's built-in types is not exactly straightforward, but I suppose that with good documentation it could be made accessible. Let me give you a quick start... > I have looked into the directories. I have found > pypy/objspace/dict{object,type}.py. My questions are: > > 1. How do I make new built-in types, play with their inheritence, make > them uninstantiable? Should I register it somewhere? Built-in types go in files xxxtype.py. The StdTypeDef declared in xxxtype.py declares how the type behaves. For an example see e.g. stringtype.py and basestringtype.py. Inheritance is declared in the StdTypeDef. If you want the type name to appear in the built-ins automatically, register it in model.py. Then you can declare one (or zero or several) implementation of a type, traditionally in xxxobject.py as a W_XxxObject. It must be registered by being added to the dictionary 'self.typeorder' in model.py. Note that you can also register automatic conversions there, like str->unicode, but I think it's not necessary in your case. There is no inheritance of the W_XxxObject classes -- typically, you don't need a W_BaseDictObject at all because it's not instantiatable, just like there is no W_BaseStringObject (and no basestringobject.py). > 2. Where do I add a new built-in like frozen()? How should I make it > callable from interpreter-level code? A new __freeze__ protocol means a new multimethod. Add it to the ObjSpace.MethodTable in interpreter/baseobjspace.py. E.g. follow the example of 'len' and how various xxxobject.py files define len__Xxx(). (There are name-based hacks going on here. You don't need to register 'freeze' anywhere else than in ObjSpace.MethodTable, it will pick up the freeze__Xxx implementations and be available as 'space.freeze()'). Then follow the example of len() again to make it available as a built-in: you need to modify module/__builtin__/operation.py and __init__.py (that's just 4 lines of code to add :-) A bientot, Armin. From faassen at infrae.com Tue Nov 15 17:29:06 2005 From: faassen at infrae.com (Martijn Faassen) Date: Tue, 15 Nov 2005 17:29:06 +0100 Subject: [pypy-dev] This Week in PyPy 1 In-Reply-To: <2m4q6s3acc.fsf@starship.python.net> References: <2m4q6s3acc.fsf@starship.python.net> Message-ID: <437A0CD2.3080508@infrae.com> Michael Hudson wrote: [snip] > Import Analysis > =============== > > In an effort to understand what code is used where in PyPy, Michael > Hudson wrote a tool to analyse the import structure of PyPy, > culminating in a several megabyte HTML report which you can find at: > > http://starship.python.net/crew/mwh/importfunhtml/pypy/ > > For example, this is a list of all the modules that reference > pypy.objspace.flow.model.Constant (one of the more referenced > names in PyPy): > > http://starship.python.net/crew/mwh/importfunhtml/pypy/objspace/flow/model/Constant.html > > Of course, this work ended up duplicating some of the things done by > tools such as pylint and pyflakes and has the potential to be useful > for projects other than PyPy, so I hope to clean it up and maybe make > it a pylint plugin soon-ish. Something possibly relevant but very special purpose is a tool I wrote called 'importchecker'. Its only purpose is to report on unused imports so that they can be removed from the codebase. http://cvs.infrae.com/tools/importchecker/ The files haven't been updated in a while, but it still works with Python 2.4 and I'm using it regularly. Of course if PyPy does too much importing magic it might not work... Regards, Martijn From cfbolz at gmx.de Tue Nov 15 18:27:42 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 15 Nov 2005 18:27:42 +0100 Subject: [pypy-dev] PyPy sprint announcement: Gothenburg 7th - 11th December 2005 Message-ID: <437A1A8E.3060605@gmx.de> Gothenburg PyPy Sprint II: 7th - 11th December 2005 ====================================================== (NOTE: internal EU-only sprint starts on the 5th!) The next PyPy sprint is scheduled to be in December 2005 in Gothenborg, Sweden. Its main focus is heading towards phase 2, which means JIT work, alternate threading models and logic programming (but there are also other possible topics). We'll give newcomer-friendly introductions. To learn more about the new PyPy Python-in-Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint ------------------------------ We have released pypy-0.8.0_, which is officially a "research base" for future work. The goal of the Gothenburg sprint is to start exploring new directions and continue in the directions started at the Paris sprint. The currently scheduled main topics are: - The L3 interpreter, a small fast interpreter for "assembler-level" flow graphs. This is heading towards JIT work. - Stackless: write an app-level interface, which might be either Tasklets, as in "Stackless CPython", or the more limited Greenlets. - Porting C modules from CPython. (_socket is not finished) - Optimization/debugging work in general. In particular our thread support is far from stable at the moment and unaccountably slow. - Experimentation: logic programming in Python. A first step might be to try to add logic variables to PyPy. .. _`pypy-0.8.0`: http://codespeak.net/pypy/dist/pypy/doc/release-0.8.0.html Location & Accomodation ------------------------ The sprint will be held in the apartment of Laura Creighton and Jacob Halen which is in Gotabergsgatan 22. The location is central in Gothenburg. It is between the tram_ stops of Vasaplatsen and Valand, where many lines call. .. _tram: http://www.vasttrafik.se Probably cheapest and not too far away is to book accomodation at `SGS Veckobostader`_. (You can have a 10% discount there; ask in the pypy-sprint mailing list for details. We also have some possibilites of free accomodation.) .. _`SGS Veckobostader`: http://www.sgsveckobostader.com Exact times ----------- The public PyPy sprint is held Wednesday 7th - Sunday 11th December 2005. There is a sprint for people involved with the EU part of the project on the two days before the "official" sprint. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. In the middle of the sprint there usually is a break day and it's usually ok to take half-days off if you feel like it. Network, Food, currency ------------------------ Sweden is not part of the Euro zone. One SEK (krona in singular, kronor in plural) is roughly 1/10th of a Euro (9.15 SEK to 1 Euro). The venue is central in Gothenburg. There is a large selection of places to get food around, from edible-and-cheap to outstanding. You normally need a wireless network card to access the network, but we can provide a wireless/ethernet bridge. Sweden uses the same kind of plugs as Germany. 230V AC. Registration etc.pp. -------------------- Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Gothenburg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/gothenburg-2005/people.txt .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`Gothenburg people`: http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2005/people.html From arigo at tunes.org Wed Nov 16 12:53:12 2005 From: arigo at tunes.org (Armin Rigo) Date: Wed, 16 Nov 2005 12:53:12 +0100 Subject: [pypy-dev] Re: [pypy-svn] r19917 - in pypy/dist/pypy: annotation objspace/flow translator translator/c In-Reply-To: <20051116050823.1275327B69@code1.codespeak.net> References: <20051116050823.1275327B69@code1.codespeak.net> Message-ID: <20051116115312.GA14703@code1.codespeak.net> Hi Christian, On Wed, Nov 16, 2005 at 06:08:23AM +0100, tismer at codespeak.net wrote: > Modified: > pypy/dist/pypy/annotation/bookkeeper.py > pypy/dist/pypy/objspace/flow/objspace.py > pypy/dist/pypy/translator/c/pyobj.py > pypy/dist/pypy/translator/translator.py That's fine so far, but you should know that we have a branch in progress about the annotator, so if you plan to make larger changes to any of the translation parts, please discuss them first :-) Also, the subject of how to write C extension modules in RPython could do with being discussed on pypy-dev first anyway. Currently it mostly kind-of-works already, as a by-product of the way the whole thing was developed, because it allowed continuous testing. But we need to stop and design and think a bit more precisely about what we want, if indeed we want that now. A bientot, Armin. From tismer at stackless.com Wed Nov 16 22:45:13 2005 From: tismer at stackless.com (Christian Tismer) Date: Wed, 16 Nov 2005 13:45:13 -0800 Subject: [pypy-dev] Re: [pypy-svn] r19917 - in pypy/dist/pypy: annotation objspace/flow translator translator/c In-Reply-To: <20051116115312.GA14703@code1.codespeak.net> References: <20051116050823.1275327B69@code1.codespeak.net> <20051116115312.GA14703@code1.codespeak.net> Message-ID: <437BA869.5060401@stackless.com> Armin Rigo wrote: > Hi Christian, > > On Wed, Nov 16, 2005 at 06:08:23AM +0100, tismer at codespeak.net wrote: > >>Modified: >> pypy/dist/pypy/annotation/bookkeeper.py >> pypy/dist/pypy/objspace/flow/objspace.py >> pypy/dist/pypy/translator/c/pyobj.py >> pypy/dist/pypy/translator/translator.py > > > That's fine so far, but you should know that we have a branch in > progress about the annotator, so if you plan to make larger changes to > any of the translation parts, please discuss them first :-) Not at all. I just added what I needed, trying not to break anything. I'm keeping this to the minimum, since discussion is also a bit uneasy from here. > Also, the subject of how to write C extension modules in RPython could > do with being discussed on pypy-dev first anyway. Currently it mostly > kind-of-works already, as a by-product of the way the whole thing was > developed, because it allowed continuous testing. But we need to stop > and design and think a bit more precisely about what we want, if indeed > we want that now. Fine with me! ciao - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From mwh at python.net Thu Nov 17 10:47:29 2005 From: mwh at python.net (Michael Hudson) Date: Thu, 17 Nov 2005 09:47:29 +0000 Subject: [pypy-dev] pypy-sync vs trains Message-ID: <2macg3txla.fsf@starship.python.net> Assuming there's going to be a pypy-sync today (?), I'm not going to be at it as I'll be on a train. My activity report goes something like: LAST: somepbc-refactoring, admin NEXT: somepbc-refactoring BLOCKERS: failing to understand our current code :) I think we really need to get a move on with somepbc-refactoring or merging will become increasingly difficult. Cheers, mwh -- I sense much distrust in you. Distrust leads to cynicism, cynicism leads to bitterness, bitterness leads to the Awareness Of True Reality which is referred to by those-who-lack-enlightenment as "paranoia". I approve. -- David P. Murphy, alt.sysadmin.recovery From mwh at python.net Thu Nov 17 22:43:50 2005 From: mwh at python.net (Michael Hudson) Date: Thu, 17 Nov 2005 21:43:50 +0000 Subject: [pypy-dev] Re: [pypy-svn] r19981 - in pypy/branch/somepbc-refactoring/pypy: rpython rpython/test translator In-Reply-To: <20051117153511.CA03C27B60@code1.codespeak.net> (pedronis@codespeak.net's message of "Thu, 17 Nov 2005 16:35:11 +0100 (CET)") References: <20051117153511.CA03C27B60@code1.codespeak.net> Message-ID: <2mzmo3rlux.fsf@starship.python.net> pedronis at codespeak.net writes: > Author: pedronis > Date: Thu Nov 17 16:35:10 2005 > New Revision: 19981 > > Modified: > pypy/branch/somepbc-refactoring/pypy/rpython/annlowlevel.py > pypy/branch/somepbc-refactoring/pypy/rpython/test/test_llann.py > pypy/branch/somepbc-refactoring/pypy/translator/annrpython.py > Log: > (arigo, pedronis) > > fixed annlowlevel.py and its basic tests in test_llann.py > > now annotator.build_types delegate to the function desc to possibly > apply a required specialisation Hey, that's what I did on the train :) Oh well, now I know that bit of the code much better :) Cheers, mwh -- Hmmm... its Sunday afternoon: I could do my work, or I could do a Fourier analysis of my computer's fan noise. -- Amit Muthu, ucam.chat (from Owen Dunn's summary of the year) From mwh at python.net Fri Nov 18 12:40:08 2005 From: mwh at python.net (Michael Hudson) Date: Fri, 18 Nov 2005 11:40:08 +0000 Subject: [pypy-dev] testing testing Message-ID: <2D9D0FF3-1C9B-4BE1-A5F4-0729FB38EBA1@python.net> From noamraph at gmail.com Fri Nov 18 13:32:28 2005 From: noamraph at gmail.com (Noam Raphael) Date: Fri, 18 Nov 2005 14:32:28 +0200 Subject: [pypy-dev] PyPy newbie question: How to play with types In-Reply-To: <20051113171205.GA10173@code1.codespeak.net> References: <20051113171205.GA10173@code1.codespeak.net> Message-ID: Ok, I just tried to add the "frozen" multimethod. I managed to make it work as a one-argument function. I had to add a line to the flow/operation.py, to make it work: ('frozen', None), I then tried to make it a function which gets two arguments, the second one is optional (so you can call frozen(x), which means x.__frozen__(), and also frozen(x, y), which means x.__frozen__(y).) I replaced the "1" with "2" in the line in baseobjspace.py, and it didn't work - it said: Traceback (most recent call last): File "pypy/bin/py.py", line 205, in ? sys.exit(main_(sys.argv)) File "pypy/bin/py.py", line 81, in main_ space = make_objspace(Options) File "pypy/bin/py.py", line 58, in make_objspace from pypy.objspace.std import Space File "/home/noam/sand/pypy/pypy/objspace/std/__init__.py", line 1, in ? from objspace import StdObjSpace File "/home/noam/sand/pypy/pypy/objspace/std/objspace.py", line 11, in ? from pypy.objspace.descroperation import DescrOperation File "/home/noam/sand/pypy/pypy/objspace/descroperation.py", line 573, in ? raise Exception, "missing def for operation%s" % _name Exception: missing def for operationfrozen Another thing that I had to find out: I had to copy the "py" directory from the bz2 distribution in order to make pypy work (I checked out from subversion). I didn't see it mentioned in the subversion instructions. I will probably have more questions in the future, but that's it for now... Thanks again, Noam From cfbolz at gmx.de Sat Nov 19 14:20:10 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sat, 19 Nov 2005 14:20:10 +0100 Subject: [pypy-dev] Re: [pypy-svn] r20071 - pypy/dist/pypy/doc In-Reply-To: <20051119092139.9EF8327B90@code1.codespeak.net> References: <20051119092139.9EF8327B90@code1.codespeak.net> Message-ID: <437F268A.1080200@gmx.de> lac at codespeak.net wrote: > Author: lac > Date: Sat Nov 19 10:21:38 2005 > New Revision: 20071 > > Modified: > pypy/dist/pypy/doc/news.txt > Log: > I now know the perfect test for Germans. You ask them to > spell 'G?teborg'. Depending on how they misspell it, you can > determine exactly which part of Germany they call home. :-) > TODO: test on Nik, see if it is language or a country problem. :-) > > > Modified: pypy/dist/pypy/doc/news.txt > ============================================================================== > --- pypy/dist/pypy/doc/news.txt (original) > +++ pypy/dist/pypy/doc/news.txt Sat Nov 19 10:21:38 2005 > @@ -12,7 +12,7 @@ > PyPy Sprint in G?teborg 7th - 11th December 2005 > ================================================= > > -The next PyPy sprint is scheduled to be in December 2005 in G?theborg. > +The next PyPy sprint is scheduled to be in December 2005 in G?teborg. > Its main focus is heading towards phase 2, which means JIT work, > alternate threading models and logic programming (but there are also > other possible topics). We'll give newcomer-friendly introductions. well, I think in this case the part of Germany the author called home is "Bristol" :-) Cheers, Carl Friedrich From lac at strakt.com Sat Nov 19 14:44:02 2005 From: lac at strakt.com (Laura Creighton) Date: Sat, 19 Nov 2005 14:44:02 +0100 Subject: [pypy-dev] Re: [pypy-svn] r20071 - pypy/dist/pypy/doc In-Reply-To: Message from Carl Friedrich Bolz of "Sat, 19 Nov 2005 14:20:10 +0100." <437F268A.1080200@gmx.de> References: <20051119092139.9EF8327B90@code1.codespeak.net> <437F268A.1080200@gmx.de> Message-ID: <200511191344.jAJDi3Yw010633@theraft.strakt.com> In a message of Sat, 19 Nov 2005 14:20:10 +0100, Carl Friedrich Bolz writes: > > >lac at codespeak.net wrote: >> Author: lac >> Date: Sat Nov 19 10:21:38 2005 >> New Revision: 20071 >> >> Modified: >> pypy/dist/pypy/doc/news.txt >> Log: >> I now know the perfect test for Germans. You ask them to >> spell 'G??teborg'. Depending on how they misspell it, you can >> determine exactly which part of Germany they call home. :-) >> TODO: test on Nik, see if it is language or a country problem. :-) >> >> >> Modified: pypy/dist/pypy/doc/news.txt >> ======================================================================= >======= >> --- pypy/dist/pypy/doc/news.txt (original) >> +++ pypy/dist/pypy/doc/news.txt Sat Nov 19 10:21:38 2005 >> @@ -12,7 +12,7 @@ >> PyPy Sprint in G??teborg 7th - 11th December 2005 >> ================================================= >> >> -The next PyPy sprint is scheduled to be in December 2005 in G??theborg. >> +The next PyPy sprint is scheduled to be in December 2005 in G??teborg. >> Its main focus is heading towards phase 2, which means JIT work, >> alternate threading models and logic programming (but there are also >> other possible topics). We'll give newcomer-friendly introductions. > >well, I think in this case the part of Germany the author called home is > "Bristol" :-) But it happened WHILE HE WAS IN DUSSELDORF! I smell a paper for the JIR! http://www.jir.com/ Laura >Cheers, > >Carl Friedrich >_______________________________________________ >pypy-dev at codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev From arigo at tunes.org Sat Nov 19 19:59:29 2005 From: arigo at tunes.org (Armin Rigo) Date: Sat, 19 Nov 2005 19:59:29 +0100 Subject: [pypy-dev] PyPy newbie question: How to play with types In-Reply-To: References: <20051113171205.GA10173@code1.codespeak.net> Message-ID: <20051119185929.GA27035@code1.codespeak.net> Hi Noam, On Fri, Nov 18, 2005 at 02:32:28PM +0200, Noam Raphael wrote: > File "/home/noam/sand/pypy/pypy/objspace/descroperation.py", line 573, in ? > raise Exception, "missing def for operation%s" % _name > Exception: missing def for operationfrozen Indeed, to allow the user to define custom '__freeze__' method there is a step to take in descroperation.py that I forgot. See for example 'def setitem'. It would go something like: def freeze(space, w_obj): w_descr = space.lookup(w_obj, '__freeze__') if w_descr is None: # no __freeze__, complain or perform some default behavior else: return space.get_and_call_function(w_descr, w_obj) Adding another optional argument needs to be done with some care, because most of the places will internally need a non-optional argument. It's possible in theory to have default arguments on multimethods, but I suppose that you should just make the user-visible 'freeze()' in the __builtin__ module accept less arguments and add a default if necessary. About the py lib: the "Svn-check out" instructions at http://codespeak.net/pypy/dist/pypy/doc/getting-started.html should have checked out the 'py' subdirectory as well. A bientot, Armin From noamraph at gmail.com Sat Nov 19 22:47:27 2005 From: noamraph at gmail.com (Noam Raphael) Date: Sat, 19 Nov 2005 23:47:27 +0200 Subject: [pypy-dev] PyPy newbie question: How to play with types In-Reply-To: <20051119185929.GA27035@code1.codespeak.net> References: <20051113171205.GA10173@code1.codespeak.net> <20051119185929.GA27035@code1.codespeak.net> Message-ID: Thanks for your instructions, it now works. About py: On 11/19/05, Armin Rigo wrote: > > About the py lib: the "Svn-check out" instructions at > http://codespeak.net/pypy/dist/pypy/doc/getting-started.html > should have checked out the 'py' subdirectory as well. > I've now checked - it does. The problem was that I used svk, which presumably doesn't support the svn:externals property. Perhaps it should be mentioned in the instructions that the py directory should be downloaded automatically, but if it doesn't you can get it from ... Have a good week, Noam From lac at strakt.com Sun Nov 20 18:27:15 2005 From: lac at strakt.com (Laura Creighton) Date: Sun, 20 Nov 2005 18:27:15 +0100 Subject: [pypy-dev] Why does python's range function only take numbers? Message-ID: <200511201727.jAKHRFpw008156@theraft.strakt.com> I just wrote: def chrange(start, end): return [chr(i) for i in range(ord(start), ord(end)+1)] for about the thousandth time in my life. Which got me thinking. Due to the miracle of signature based polymorphism, we could make our range function take chars as well. Anybody know why CPython doesn't do this? Laura, now musing about a range function that takes an arbitrary sequence ... From jdahlin at async.com.br Tue Nov 15 20:09:33 2005 From: jdahlin at async.com.br (Johan Dahlin) Date: Tue, 15 Nov 2005 17:09:33 -0200 Subject: [pypy-dev] Re: This Week in PyPy 1 In-Reply-To: <437A0CD2.3080508@infrae.com> References: <2m4q6s3acc.fsf@starship.python.net> <437A0CD2.3080508@infrae.com> Message-ID: <437A326D.903@async.com.br> >> Of course, this work ended up duplicating some of the things done by >> tools such as pylint and pyflakes and has the potential to be useful >> for projects other than PyPy, so I hope to clean it up and maybe make >> it a pylint plugin soon-ish. > > Something possibly relevant but very special purpose is a tool I wrote > called 'importchecker'. Its only purpose is to report on unused imports > so that they can be removed from the codebase. > > http://cvs.infrae.com/tools/importchecker/ Seems very similar to pyflakes (which does the same and a few more things), which can be found at: http://divmod.org/projects/pyflakes Johan From jdahlin at async.com.br Tue Nov 15 20:09:33 2005 From: jdahlin at async.com.br (Johan Dahlin) Date: Tue, 15 Nov 2005 17:09:33 -0200 Subject: [pypy-dev] Re: This Week in PyPy 1 In-Reply-To: <437A0CD2.3080508@infrae.com> References: <2m4q6s3acc.fsf@starship.python.net> <437A0CD2.3080508@infrae.com> Message-ID: <437A326D.903@async.com.br> >> Of course, this work ended up duplicating some of the things done by >> tools such as pylint and pyflakes and has the potential to be useful >> for projects other than PyPy, so I hope to clean it up and maybe make >> it a pylint plugin soon-ish. > > Something possibly relevant but very special purpose is a tool I wrote > called 'importchecker'. Its only purpose is to report on unused imports > so that they can be removed from the codebase. > > http://cvs.infrae.com/tools/importchecker/ Seems very similar to pyflakes (which does the same and a few more things), which can be found at: http://divmod.org/projects/pyflakes Johan From tismer at stackless.com Mon Nov 21 10:31:06 2005 From: tismer at stackless.com (Christian Tismer) Date: Mon, 21 Nov 2005 01:31:06 -0800 Subject: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython In-Reply-To: <20051119194213.0862F27B9E@code1.codespeak.net> References: <20051119194213.0862F27B9E@code1.codespeak.net> Message-ID: <438193DA.6030908@stackless.com> arigo at codespeak.net wrote: > Author: arigo > Date: Sat Nov 19 20:42:12 2005 > New Revision: 20092 > > Modified: > pypy/dist/pypy/rpython/robject.py > Log: > Bug fix (for Christian :-) to compile code like > > d = {} > d[x] = y > > where x and y are SomeObjects. The reason is that operations manipulating > PyObjects must not have a 'void' return value, even operations like 'setitem', > but a PyObject one. Thank you very much! I worked around that, but in the end, it is a bug. And btw. I discovereed a bulk of more bugs or inconsistencies, which might be tackled after I'm back from my "mission". ATM, I need to make a small addition to allow float values as dict keys. There is a lot more considerable, but I can work around all other stuff and don't want to spoil our project without discussion. The need for float comes from the lack of a primitive long type. Alternatively, I'm thinking to map the long type to some internal 64 bit type. This would make some sense, also because we also have file related code that would need this type. I will start discusions when I'm back. Adding a bit of completeness (hash on float) will probably not hurt anybody. Btw., I have meanwhile turned all their application into RPython. Although this took many new little classes, and the lack of properties was as painful as the inability to define any __xx__ methods, the result is still rather pythonic and runs at blinding speed- I'm now only 30% slower than their highly optimized Java implementation, and I guess I could get the rest for free by finishing the needed optimizations of refcounting and some other tiny things. all the best - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From lac at strakt.com Mon Nov 21 10:51:29 2005 From: lac at strakt.com (Laura Creighton) Date: Mon, 21 Nov 2005 10:51:29 +0100 Subject: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython In-Reply-To: Message from Christian Tismer of "Mon, 21 Nov 2005 01:31:06 PST." <438193DA.6030908@stackless.com> References: <20051119194213.0862F27B9E@code1.codespeak.net> <438193DA.6030908@stackless.com> Message-ID: <200511210951.jAL9pTWU013620@theraft.strakt.com> In a message of Mon, 21 Nov 2005 01:31:06 PST, Christian Tismer writes: >arigo at codespeak.net wrote: > >> Author: arigo >> Date: Sat Nov 19 20:42:12 2005 >> New Revision: 20092 >> >> Modified: >> pypy/dist/pypy/rpython/robject.py >> Log: >> Bug fix (for Christian :-) to compile code like >> >> d = {} >> d[x] = y >> >> where x and y are SomeObjects. The reason is that operations manipulat >ing >> PyObjects must not have a 'void' return value, even operations like 'se >titem', >> but a PyObject one. > >Thank you very much! >I worked around that, but in the end, it is a bug. >And btw. I discovereed a bulk of more bugs or inconsistencies, >which might be tackled after I'm back from my "mission". > >ATM, I need to make a small addition to allow float values as dict >keys. There is a lot more considerable, but I can work around all >other stuff and don't want to spoil our project without discussion. >The need for float comes from the lack of a primitive long type. >Alternatively, I'm thinking to map the long type to some internal >64 bit type. This would make some sense, also because we also have >file related code that would need this type. > >I will start discusions when I'm back. Adding a bit of completeness >(hash on float) will probably not hurt anybody. > >Btw., I have meanwhile turned all their application into RPython. >Although this took many new little classes, and the lack of >properties was as painful as the inability to define any __xx__ >methods, the result is still rather pythonic and runs at blinding speed- >I'm now only 30% slower than their highly optimized Java >implementation, and I guess I could get the rest for free by finishing >the needed optimizations of refcounting and some other tiny things. > >all the best - chris > >-- >Christian Tismer :^) >tismerysoft GmbH : Have a break! Take a ride on Python's >Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ >14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ >work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 >PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ >_______________________________________________ >pypy-dev at codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev Correct me if I am wrong, but if we allow float keys, then we make code that is not portable between machines that have different float representations? Also, given that your new American friends are dealing with money, what is wrong with using the decimal type as keys for them, or possibly better still Facundo's money module? Laura From tismer at stackless.com Mon Nov 21 11:04:01 2005 From: tismer at stackless.com (Christian Tismer) Date: Mon, 21 Nov 2005 02:04:01 -0800 Subject: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython In-Reply-To: <200511210951.jAL9pTWU013620@theraft.strakt.com> References: <20051119194213.0862F27B9E@code1.codespeak.net> <438193DA.6030908@stackless.com> <200511210951.jAL9pTWU013620@theraft.strakt.com> Message-ID: <43819B91.9070401@stackless.com> Laura Creighton wrote: > Correct me if I am wrong, but if we allow float keys, then we make > code that is not portable between machines that have different > float representations? CPython does allow float keys and doesn't have portability problems. The only concern here is compatability with equally values integer keys. But that does not apply to RPython, since we there dfon't allow mixing types at all. > Also, given that your new American friends are dealing with money, > what is wrong with using the decimal type as keys for them, or > possibly better still Facundo's money module? I needed something that is supported by RPython and that is very fast. I'm not aware of a C implementation of the money type, yet, but maybe I'm missing something. 64 bit long would be perfect, because they use it at a fixed decimal scale and convert into float only for display purposes. So float is ATM a surrogate which is ok, because 53 bits fill the needed range, too. And my primary goal is to show them what PyPy can do, and to convince them that it makes sense to invest into this. Btw. it is not the Salomon Bros/group but an individual, with his roots in Hungary. all the best - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From arigo at tunes.org Mon Nov 21 12:47:21 2005 From: arigo at tunes.org (Armin Rigo) Date: Mon, 21 Nov 2005 12:47:21 +0100 Subject: [pypy-dev] Why does python's range function only take numbers? In-Reply-To: <200511201727.jAKHRFpw008156@theraft.strakt.com> References: <200511201727.jAKHRFpw008156@theraft.strakt.com> Message-ID: <20051121114721.GA4921@code1.codespeak.net> Hi Laura, On Sun, Nov 20, 2005 at 06:27:15PM +0100, Laura Creighton wrote: > Why does python's range function only take numbers? That's a comp.lang.python topic :-) Armin From arigo at tunes.org Mon Nov 21 12:55:56 2005 From: arigo at tunes.org (Armin Rigo) Date: Mon, 21 Nov 2005 12:55:56 +0100 Subject: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython In-Reply-To: <43819B91.9070401@stackless.com> References: <20051119194213.0862F27B9E@code1.codespeak.net> <438193DA.6030908@stackless.com> <200511210951.jAL9pTWU013620@theraft.strakt.com> <43819B91.9070401@stackless.com> Message-ID: <20051121115556.GB4921@code1.codespeak.net> Hi Christian, On Mon, Nov 21, 2005 at 02:04:01AM -0800, Christian Tismer wrote: > CPython does allow float keys and doesn't have portability > problems. The only concern here is compatability with equally > values integer keys. But that does not apply to RPython, since > we there dfon't allow mixing types at all. Good point. RPython can probably live with a simple hash function for floats, and our W_FloatObject's hash can be more complicated (possibly using the integer as hash when the float has no fractional part, like now, or falling back to the RPython hash if there is a fractional part). > 64 bit long would be perfect That's a possibility. For PyPy we should be more explicit, though, and use a "class r_longlong" or "class r_int64". It should be part of a general design that would allow integers of various precisions. The design decision is to choose if we want classes with explicit sizes (r_int64) or C-like names (longlong)... A bientot, Armin. From tismer at stackless.com Mon Nov 21 19:54:10 2005 From: tismer at stackless.com (Christian Tismer) Date: Mon, 21 Nov 2005 10:54:10 -0800 Subject: [pypy-dev] Nice floats Message-ID: <438217D2.704@stackless.com> Hi pypy-dev, I just stumbled oversome code from Gustavo. I think we were considering doing exact float formatting. I wrote something that works. But if we like to have it, this implementation gives the shortest possible representation. At some cost, of course... http://labix.org/python-nicefloat -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From mwh at python.net Tue Nov 22 10:33:11 2005 From: mwh at python.net (Michael Hudson) Date: Tue, 22 Nov 2005 09:33:11 +0000 Subject: [pypy-dev] Re: Nice floats References: <438217D2.704@stackless.com> Message-ID: <2m7jb1gh7s.fsf@starship.python.net> Christian Tismer writes: > Hi pypy-dev, > > I just stumbled oversome code from Gustavo. I think we were > considering doing exact float formatting. I wrote something > that works. But if we like to have it, this implementation > gives the shortest possible representation. > > At some cost, of course... > > http://labix.org/python-nicefloat This is the same algorithm I implemented in lib/_float_formatting.py ages and ages ago... It's not RPython as it uses long arithmetic, but only boundedly so (I don't think it will use a number larger than 2**53) so you could probably fake it by using a pair of ints. The problem with _float_formatting is that I never got around to implementing the fixed formatting routines from the same paper (and Gustavo hasn't either, AFAIK). Cheers, mwh -- > I wouldn't want to live without readline, but some of the > things it does call for the application of thumbscrews. -- me on python-dev From mwh at python.net Tue Nov 22 17:18:40 2005 From: mwh at python.net (Michael Hudson) Date: Tue, 22 Nov 2005 16:18:40 +0000 Subject: [pypy-dev] This week in PyPy 3 Message-ID: <2msltofyfz.fsf@starship.python.net> Better late than never... ======================= This Week in PyPy 3 ======================= Introduction ============ This is the third of what will hopefully be many summaries of what's been going on in the world of PyPy in the last week. I'd still like to remind people that when something worth summarizing happens to recommend if for "This Week in PyPy" as mentioned on: http://codespeak.net/pypy/dist/pypy/doc/weekly/ where you can also find old summaries. There were about 60 commits to the pypy section of codespeak's repository this week. SomePBC-refactoring =================== Work on the branch continued, to the point that the annotator now works but the scary mess of the RTyper still remains. We're still pleased with the ideas behind the branch -- the new annotator code has a good deal fewer hacks than the old (though it still has quite a few, of course). Backend progress ================ There was a fair bit of light refactoring on the LLVM backend this week, including a recommendation to upgrade to the newly released LLVM 1.6. This gives slightly better performance, meaning that a new pypy-llvm is the closest to CPython performance we've gotten yet (still about 8 times slower, mind). The main change is that the list of operations that can raise exceptions is now shared with the genc backend, reducing duplication and maintence overhead. Basically this means that the LLVM backend is and should remain compatible with the default pypy-c build (no threads, only the Boehm GC and no stackless features). There was also progress on the JavaScript backend, mainly focussed on adding some of the stackless features currently sported by the C backend. Cheers, mwh -- > It might get my attention if you'd spin around in your chair, > spoke in tongues, and puked jets of green goblin goo. I can arrange for this. ;-) -- Barry Warsaw & Fred Drake From adimasci at gmail.com Thu Nov 24 08:28:58 2005 From: adimasci at gmail.com (Adrien Di Mascio) Date: Thu, 24 Nov 2005 08:28:58 +0100 Subject: [pypy-dev] pypy-sync Message-ID: <437de8500511232328t2b5ee968x3a6f5d8fe9065b81@mail.gmail.com> Hi there, I won't be able to attend the pypy-sync meeting today. I did nothing the last week for PyPy, except preparing our trip to Gothenburg. Next week, I will probably have a look at some Logic-related stuff. Cheers, Adrien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhamph at gmail.com Fri Nov 25 18:13:25 2005 From: rhamph at gmail.com (Adam Olsen) Date: Fri, 25 Nov 2005 10:13:25 -0700 Subject: [pypy-dev] Full Python Annotation Message-ID: I'm a bit disorganized here, but I don't think delaying will help much as my brain is turning to mush. Nothing ventured... Notes for description of value annotator Iterative. Allows examination of individual steps Stable. Produces result in finite amount of time Order Insensitive. Always produces the same result, no matter what order in which it processes the sourcecode Specialization of builtins. All functions are given a "space depth". Multiple calls (at different lines of code) to the same function will, if it has a deeper depth, create separate copies of the function in their own "space". If those functions then call a function of a shallower depth they will use a shared function (rather than continuing to specialize it). The result is that separate calls to builtin functions (such as the plus operator) will get separate annotations, but without risk of an infinite loop in the annotation process. Values. A Value is a set (in the mathematical sense) of possible values, be they integer, float, string, or whatever. In practice it must store an approximation so that a set of 0..2**64-1 can be represented. It is acceptable for the set to be expanded to include values that are not really possible (as the program will still behave correctly), but not acceptable to be smaller. Note however that as an iterative process is used to determine values, it will initially be to small, and later replaced with new Values that cover the full range. Hypothetical value expansions. A mechanism is needed to expand values to their full range quickly, rather than iterate it one step at a time. To do this an integer_add will notice on the second pass (not the first!) that it had a previous possible output, and that the new output appears to create a sequence from it. A new value set is created as normal (increased by only a single step), except a "hypothetical" part is added to it. The hypothetical contains a Value set with the predicted sequence of values (not including any already known), as well as a reference to the node/space that created it. The value is then set as the new output for the integer_add node and is propagated through the rest of the code. Other nodes will modify the hypothetical as if it was a normal value set, including putting a cap on the the highest value in the case of an if branch, but they will not explore new code as a result of it. If the hypothetical reaches the node/space that created it then this indicates there is a loop which allows the value to expand over the whole range, and the node will convert it into a normal value (including any caps that were discovered). Branches and bool replacement Values. To effect a cap on the range of a value the bool value produced by lessthan and similar operations will contain a pair reduced Value associated with the input variables. If the bool is used for a branch then either the "True" or "False" version of the reduced Value associated with the bool's original input variable will be used to replace the variable thereafter. Note that a form of Single Static Assignment is used to allow a variable to have different values at different points in a function. Comment on SSA and aliases. As the branch that reduces a variable's range may happen outside the function itself, it is necessary to make the SSA alias lists globally available and allow modification at any point. This means they must be copied to every node, with the resulting cost being quadratic (O(n**2)). However, as most of the copies would have identical contents I believe it would be possible to optimize this and get performance that is closer to linear (O(n)). Finally, a note on what sorts of code this is aimed at. Anything where all the code can be determined at compiletime, ie no eval/exec/__import__/reload. Some analysis of code that does use those features would still be possible however. Spaces diagram: http://members.shaw.ca/rhamph/python-annvalue/spaces.pdf Values diagram: http://members.shaw.ca/rhamph/python-annvalue/values.pdf Partially annotated test "program": http://members.shaw.ca/rhamph/python-annvalue/annotation.pdf My sourcecode (requires autopath.py): http://members.shaw.ca/rhamph/python-annvalue/basicblock.py -- Adam Olsen, aka Rhamphoryncus From arigo at tunes.org Fri Nov 25 18:30:24 2005 From: arigo at tunes.org (Armin Rigo) Date: Fri, 25 Nov 2005 18:30:24 +0100 Subject: [pypy-dev] [lalo.martins@gmail.com: Re: Document drafts] Message-ID: <20051125173023.GA23875@code1.codespeak.net> Hi, Forwarded for Lalo, who cannot seem to post to pypy-dev, answering the following: > Hi all, > > People following only this mailing list may have missed some draft > documents that we have been working on, as they are not linked to yet: > > http://codespeak.net/pypy/dist/pypy/doc/draft-dynamic-language-translation.html > http://codespeak.net/pypy/dist/pypy/doc/draft-low-level-encapsulation.html ----- Forwarded message from Lalo Martins ----- I'm quite impressed with them, technically. The only suggestions I have about them are non-technical. I find that many sentences are too long, without break. It's a vice I have myself, as a non-native writer. Native readers often tell me, this makes my text too heavy, too hard to parse. Of course, the primary target audience (in academia) will have higher tolerance to that, but it's still somewhat bad style. I'd sprinkle commas generously, at least. Try reading them out loud :-) (the sentences, not the commas) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.laranja.org/ mailto:lalo.martins at gmail.com GNU: never give up freedom http://www.gnu.org/ ----- End forwarded message ----- From mwh at python.net Sat Nov 26 12:24:40 2005 From: mwh at python.net (Michael Hudson) Date: Sat, 26 Nov 2005 11:24:40 +0000 Subject: [pypy-dev] This Week in PyPy 4 Message-ID: <2mbr07fy87.fsf@starship.python.net> Introduction ============ This is the fourth of what will hopefully be many summaries of what's been going on in the world of PyPy in the last week. I'd still like to remind people that when something worth summarizing happens to recommend if for "This Week in PyPy" as mentioned on: http://codespeak.net/pypy/dist/pypy/doc/weekly/ where you can also find old summaries. There were about 50 commits to the pypy section of codespeak's repository since the last summary (not quite a week). SomePBC-refactoring =================== We attacked the RTyper quite a lot, which meant staring at some of the most obscure code in the codebase, and made substantial but incomplete progress (currently about 60% of the rtyper tests pass). We're optimistic that the majority of work is done on the branch, but there may be many strange details to cope with before translate_pypy runs again. Sprint Preparation ================== The next sprint is less than two weeks away -- it's definitely time to be buying flights and booking accomodation if you're going to be there :) LLVM progress ============= Richard implemented threading in the LLVM backend, bringing another feature that was previously pypy-c only in. Stacklessness next? PyPy spreads ============ Christian returned from America where he'd been consulting for a company implementing some systems in RPython which had been implemented in Java, and after some effort beating the Java versions for performance. This company had found out about PyPy and RPython from reading our mailing lists -- a nice example of how open development processes can work (and even make you money!). Resource consumption ==================== As part of being EU-funded, we have to keep track of the resources we use and have a slightly unusual problem: we haven't spent enough time or money in the first half of the project, and have to find something to do about this... PyPy at conferences =================== All three talks on PyPy that we submitted to PyCon were accepted, so there will be talks from - Michael and Christian on the current state of PyPy (whatever that may be at the time :), - Holger and Armin on the architecture and future of PyPy, and - Bea and Holger on the methodology of PyPy and the issues around being EU funded. Further to that, two papers were accepted for the Chaos Communication Congress in Berlin over the new year were accepted: http://events.ccc.de/congress/2005/fahrplan/events/585.en.html http://events.ccc.de/congress/2005/fahrplan/events/586.en.html Again, one talk is on the technology of PyPy and the other on methodology/business issues. So if you're going to a Python or hacker conference any time soon, you're likely to hear about PyPy :) -- Any form of evilness that can be detected without *too* much effort is worth it... I have no idea what kind of evil we're looking for here or how to detect is, so I can't answer yes or no. -- Guido Van Rossum, python-dev From tismer at stackless.com Sun Nov 27 13:37:59 2005 From: tismer at stackless.com (Christian Tismer) Date: Sun, 27 Nov 2005 13:37:59 +0100 Subject: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython In-Reply-To: <5.0.2.1.1.20051126174206.01ba5670@mail.oz.net> References: <43819B91.9070401@stackless.com> <20051119194213.0862F27B9E@code1.codespeak.net> <438193DA.6030908@stackless.com> <200511210951.jAL9pTWU013620@theraft.strakt.com> <43819B91.9070401@stackless.com> <5.0.2.1.1.20051126174206.01ba5670@mail.oz.net> Message-ID: <4389A8A7.6000708@stackless.com> Bengt Richter wrote: > At 12:55 2005-11-21 +0100, Armin Rigo wrote: ... >>That's a possibility. For PyPy we should be more explicit, though, and >>use a "class r_longlong" or "class r_int64". It should be part of a >>general design that would allow integers of various precisions. The >>design decision is to choose if we want classes with explicit sizes >>(r_int64) or C-like names (longlong)... > > > Please pardon my jumping in, but IMO a collection of _unambigous_ names like r_int32 > is in one sense just a small notch better than a collection of _ambiguous_ names > for various integer implementations (like int, long, etc.). Yes, I think at a certain primitive level I'd prefer to have an explicit way to spell the size of my numbers. I don't know yet if this should be done via names, or if there are better ways. For my application during the US trip for instance, I made a little data description language, a very tiny set of Python classes which allow to build record descriptions for data. I didn't use type names at all, but used notations like Char = StrDataDef("X", 1) Str16 = StrDataDef("some stuff", 16) Numeric = StrDataDef(123, 9) Price = StrDataDef(99999999999999, 14) Num1 = StrDataDef(9, 1) StrVar = StrDataDef("varying", 1, 255) The idea is to give an example value instead of a data type. See for instance the Price field. The maximum possible value is intentionally not written as a long. It just says how many digits I need. This will be a long in most cases, but on a 64 bit machine, it would be a simple integer, and my application would produce faster code. > If you want a "general design that would allow integers of various precisions," > perhaps one could think about some way of parameterizing the precision info (e.g., > exact or min bit widths) rather than just cleaning up the ambiguity in C's way > of defining an evolving series of increasingly ridiculous (what next, extralonglong?) > platform-dependent names. I.e., when would it be time to introduce r_int128 ? I would like to have two things: - a way to express what precision I need for something - a way to ask which precisions are native data types This is because depending on whether there is a native type or if it must be emulated, I might want to choose different implementations. From my work on the long integer implementation, I know that explicit types are quite error-prone and make the code less readable. The nicest thing I could imagine was a way to track the necessary bit sizes automatically in the annotator. But that's a difficult thing, because our current assumption is that overflows are ignored. In order to do explicit bit tracking, we would probably need an extra r_someint, which is handled specially to track the needed preceision? > If various integer subtypes are being generated, perhaps one could specify > minimum or exact bitwidths etc as parameters seen by a metaclass, like __SLOTS__ > only relevant to integer representation, or have an integer class factory function > that takes specs as parameters and raises an exception if the required class > can't be generated implementing the specs a particular platform. > > Just a thought. Interesting, too! We also could go further and produce an implementation for every small fixed bit size that is needed, even if it is not that efficient. This would be done in situations where there is no choice, like the 64 bit long file pointers. For things like the general long implementation, I would ask the systtem for the most efficient native types and build upon them. cheers - chris -- Christian Tismer :^) tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Sun Nov 27 14:41:08 2005 From: tismer at stackless.com (Christian Tismer) Date: Sun, 27 Nov 2005 14:41:08 +0100 Subject: [Fwd: Re: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython] Message-ID: <4389B774.2060302@stackless.com> [this message^did not appear on pypy-dev] -------------- next part -------------- An embedded message was scrubbed... From: Bengt Richter Subject: Re: [pypy-dev] Re: [pypy-svn] r20092 - pypy/dist/pypy/rpython Date: Sat, 26 Nov 2005 17:48:14 -0800 Size: 3312 URL: From cfbolz at gmx.de Mon Nov 28 01:44:09 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 28 Nov 2005 01:44:09 +0100 Subject: [pypy-dev] automatic generation of report pdfs Message-ID: <438A52D9.9090202@gmx.de> Hi pypy-dev! I set up a script that automatically generates all the report-pdfs (in eu-tracking/deliverable) every ten minutes and puts them into my home directory: http://codespeak.net/~cfbolz/deliverable_pdf The way I do it is quite hackish at the moment and might change soon. I hope that I can at least put error files in the directory if the rest is not valid. Cheers, Carl Friedrich From pedronis at strakt.com Mon Nov 28 23:09:39 2005 From: pedronis at strakt.com (Samuele Pedroni) Date: Mon, 28 Nov 2005 23:09:39 +0100 Subject: [pypy-dev] Re: [pypy-svn] r20364 - in pypy/branch/somepbc-refactoring/pypy/translator/c: . test In-Reply-To: <20051128172741.6F06127B7A@code1.codespeak.net> References: <20051128172741.6F06127B7A@code1.codespeak.net> Message-ID: <438B8023.8090200@strakt.com> mwh at codespeak.net wrote: > Author: mwh > Date: Mon Nov 28 18:27:39 2005 > New Revision: 20364 > > Modified: > pypy/branch/somepbc-refactoring/pypy/translator/c/extfunc.py > pypy/branch/somepbc-refactoring/pypy/translator/c/genc.py > pypy/branch/somepbc-refactoring/pypy/translator/c/pyobj.py > pypy/branch/somepbc-refactoring/pypy/translator/c/test/test_annotated.py > pypy/branch/somepbc-refactoring/pypy/translator/c/wrapper.py > Log: > test_annotated passes again, though this is pretty much a 'hack-until-it- > passes' approach. > > I see, > Modified: pypy/branch/somepbc-refactoring/pypy/translator/c/test/test_annotated.py > ============================================================================== > --- pypy/branch/somepbc-refactoring/pypy/translator/c/test/test_annotated.py (original) > +++ pypy/branch/somepbc-refactoring/pypy/translator/c/test/test_annotated.py Mon Nov 28 18:27:39 2005 > @@ -1,7 +1,7 @@ > import autopath > import py, sys > from pypy.translator.tool.cbuild import skip_missing_compiler > -from pypy.translator.translator import Translator > +from pypy.translator.translator import TranslationContext > > from pypy.translator.test import snippet > > @@ -12,7 +12,7 @@ > class TestAnnotatedTestCase: > > def getcompiled(self, func): > - t = Translator(func, simplifying=True) > + t = TranslationContext(simplifying=True) > # builds starting-types from func_defs > argstypelist = [] > if func.func_defaults: > @@ -20,9 +20,15 @@ > if isinstance(spec, tuple): > spec = spec[0] # use the first type only for the tests > argstypelist.append(spec) > - a = t.annotate(argstypelist) > + a = t.buildannotator() > + a.build_types(func, argstypelist) > a.simplify() > - return skip_missing_compiler(t.ccompile) > + from pypy.translator.c import genc > + builder = genc.CExtModuleBuilder(t, func) > + builder.generate_source() > + skip_missing_compiler(builder.compile) > + builder.import_module() > + return builder.get_entry_point() > > def test_set_attr(self): > set_attr = self.getcompiled(snippet.set_attr) > I missed this subtle point, indeed before going on writing more code like this, we need to think where and how much of translator.Translator to keep working and where instead to switch using TranslationContext From mwh at python.net Tue Nov 29 10:36:31 2005 From: mwh at python.net (Michael Hudson) Date: Tue, 29 Nov 2005 09:36:31 +0000 Subject: [pypy-dev] Re: [pypy-svn] r20364 - in pypy/branch/somepbc-refactoring/pypy/translator/c: . test References: <20051128172741.6F06127B7A@code1.codespeak.net> <438B8023.8090200@strakt.com> Message-ID: <2mhd9vdcdc.fsf@starship.python.net> Samuele Pedroni writes: >> if isinstance(spec, tuple): >> spec = spec[0] # use the first type only for the tests >> argstypelist.append(spec) >> - a = t.annotate(argstypelist) >> + a = t.buildannotator() >> + a.build_types(func, argstypelist) >> a.simplify() >> - return skip_missing_compiler(t.ccompile) >> + from pypy.translator.c import genc >> + builder = genc.CExtModuleBuilder(t, func) >> + builder.generate_source() >> + skip_missing_compiler(builder.compile) >> + builder.import_module() >> + return builder.get_entry_point() >> def test_set_attr(self): >> set_attr = self.getcompiled(snippet.set_attr) >> > > I missed this subtle point, indeed before going on writing more code > like this, we need to think where and how much of > translator.Translator to keep working and where instead to switch > using TranslationContext Definitely. I wrote that stuff largely to see how hard it would be and the answer is "not very, but it's a bit long winded". It's definitely too much to write in each test file. OTOH, it's hard to share this code between test files, because e.g. test_typed wants to do almost exactly the same but do rtyping in the middle. I'm a bit at a loss as to a clean design callable = self.compile(f, "annotate") callable = self.compile(f, "annotate", "rtype") callable = self.compile(f, "annotate", "rtype", "backendopt") ? Cheers, mwh -- I wouldn't trust the Anglo-Saxons for much anything else. Given they way English is spelled, who could trust them on _anything_ that had to do with writing things down, anyway? -- Erik Naggum, comp.lang.lisp From sanxiyn at gmail.com Wed Nov 30 19:40:58 2005 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 1 Dec 2005 03:40:58 +0900 Subject: [pypy-dev] Pascal backend Message-ID: <5b0248170511301040p4762a79bq@mail.gmail.com> I started Pascal backend for a while now. Have a look at: http://sparcs.kaist.ac.kr/~tinuviel/pypy/ Resulting Pascal source can be compiled with FPC(Free Pascal Compiler), available from http://www.freepascal.org/ What do you think? Also, if I understood correctly, translation part is undergoing much change in the branch. What do I need to change? Seo Sanghyeon