Mailman 3 April 2005 - pypy-dev

bug in http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
by Laura Creighton Oct. 10, 2005

Oct. 10, 2005

If you click on the 'documentation' link you get a traceback! ooops. I will look at this later unless somebody beats me to it. Laura

5 4

new unicode checkins / announcing branches
by hpk＠trillke.net May 2, 2005

May 2, 2005

Hi Anders (Chrigstrom), Hi Anders (Lehmann), i noticed that both of you are doing unicode related checkins. Could you make sure that you are not duplicating efforts? In general, i think it's a good idea to advertise new branches (like the nice "non-fake-unicode" one) on pypy-dev. Better redundant than sorry. It's also advisable to at least skim if not read the pypy-svn list to know what's going on ... Um, and does one of you have a nice nickname? :-) cheers, holger

2 1

latest test results!
by hpk＠trillke.net April 30, 2005

April 30, 2005

Hi py-dev, at http://codespeak.net/~hpk/pypy-testresult/ you'll find continously updated test results from running CPython's regression test suite against PyPy. Each time when someone checks in test results from a local test run (see Armins earlier mail on how to do that), the above web page will be updated. Feel free to participate. It would be nice if we would now categorize CPython's tests into e.g. 'language features', 'extension modules' and 'platform specific'. We are obviously more interested to get the language feature regression tests fully working. cheers, holger

1 0

restructuring lib-python-2.3.4 / testing
by hpk＠trillke.net April 29, 2005

April 29, 2005

Hi pypy-dev, for various reasons it seems like a good idea to move to a slightly modified directory structure regarding our "compat 2.3.4 library" and tests. The idea is to put the completely unmodified standard python library into: lib/python-2.3.4 and put test-wrapping configuration/hacks etc.pp. in lib/ instead of modifying an otherwise unmodified tree. The changed tests and library modules we have in pypy/lib could reside where they are now although it might be clearer to put them into lib/python-2.3.4-modified instead. This is probably a question of how version independent our modifications really are. Today we also changed the way compliance tests are run (by default, you get the old behaviour with '-E') because we want to move on with getting a complete overview of test failures. If you run py.test (or pypy/test_all.py) in the python-2.3.4 library then your test runs will get recorded into a new 'result' directory. With the above proposed location i would suggest to put this result directory into: lib/python-2.3.4-testresult/ If there are no objections (even better: agreement :-) i am doing that this night or tomorrow. cheers, holger

3 6

Fwd: michele.simionato@gmail.com: ACCU conference aftermath
by Armin Rigo April 29, 2005

April 29, 2005

Hi all, I took the liberty to forward here the following e-mail from Michele Simionato, as it contains interesting links. ----- Hi Armin! I much enjoyed your talks and I have posted my impressions about them on c.l.py. (http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/7244…) As I told you in the conference, I think you should check in the Lisp/Scheme world where there is an astonishingly amount of knowledge about JIT and in general about compiling to C code fast. Relevant projects I know of are: - SBCL, a JIT compiler for Common Lisp; - Bigloo, a high performance Scheme->C compiler; - Chicken, another easy Scheme->C compiler. All these projects are free software and they are actually working products, not just experimental stuff. SBCL is mostly developed in the US I think (it is the successor to the Carnegie Mellon Common Lisp), Bigloo is developed in France by Manuel Serrano whereas Chicken is developed in Germany by Felix Winkelman. I am an user of Chicken and I think Felix is a extremely nice and helpful guy. Here are a few links: http://sbcl.sourceforge.net/ http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www.call-with-current-continuation.org/ <cut end of mail>

6 10

Mini-sprint 15-19th May
by Armin Rigo April 26, 2005

April 26, 2005

Hi all, According to The Plan, the next official deadline is to come up before the end of May with a partial implementation of Python in Python that passes 90% of the "core language" CPython tests (that is, without counting the ones relying on C extension modules from the standard library). As the ACCU sprint was cancelled, we have come up with a possible replacement mini-sprint. The primary goal is to finish off some of the remaining test failures, and polish a bit the release. If we have enough time we want to work on near/midterm-future issues and EuroPython planning etc. The sprint targets only people already familiar with the PyPy code base and the coding style in general (this seems sensible because we have a release goal associated with the sprint). The sprint could possibly take place at Trillke-Gut Hildesheim or in Gothenborg, on the 15th-20th of May. Samuele and Bea will check out accomodation possibilities. Early next week (say the 4th of May) we decide if we actually do the sprint, based on a closer examination of the current test failures. A bientot, Armin.

1 0

whitespace policies
by hpk＠trillke.net April 25, 2005

April 25, 2005

Hi all, apparently i am one of the people who happily add spaces at the end of lines (more or less unconciously but i think it also relates to my vim usage patterns, whatever). I remember Armin complained once about these extra spaces. The main problem with these extra spaces is that if a someone's editor automatically scraps those whitespaces (like apparently, Armin's emacs did) then that someone will produce large unmeaningful diffs. Now my question is, do we want to "enforce" or at least state in our coding-style document one policy or the other? I see two options: 1. you should NOT use editor settings that scrap trailing whitespace on source code or documentation. You will note "wrong" editor settings when you see 'svn diff's ala:: - some line content + some line content which indicate that you only changed whitespace. or 2. you should use editor settings that scrap trailing whitespace on source code and documentation Obviously, the second option should be accompanied by a monster-commit changing all those lines in one go. What do you think? cheers, holger

7 9

annotation status
by Samuele Pedroni April 24, 2005

April 24, 2005

I think people not following IRC/pyp-svn etc may still be interested in this piece of information about progress. As of end of last week the annotator is able to type-annotate all of the pypy codebase, at least as loaded by goal/buildcache2.py and goal/targetpypy.py, that means the interpreter plus the standard object space plus interp-level modules. We still get some expected warnings in areas touched by faking, and some of that code may be delicate to translate. Notice that the code-generators right now are not up to the task of using this result, gen-llvm is probably the most evoluted. Having them catch up with the annotator is the next important step. Trying to translate is also probably the only way in order to discover whether there are still problems with the annotator result. Annotation takes around 15 mins on a 1.5Ghz Powerbook 15" and grows up to around .5Gb of memory also because we keep a lot of debug info about how annotations evolved during the process to facilitate type-pollution tracking. .../goal$ python translate_pypy.py -no-t -no-c targetpypy Analysing target as defined by targetpypy faking <type 'unicode'> faking <type 'module'> faking <type 'file'> *builtin* *sys* *parser* *GetSetProperty* *Member* *Ellipsis* *method* *function* *generator* *staticmethod* *ControlFlowException* *NotImplemented* *traceback* *code* *cell* *internal-code* *internal-frame* *module* *frame* *list* *type* *tuple* *long* *str* *float* *int* *dict* *object* *unicode* *NoneType* *slice* *bool* *sequenceiterator* *basestring* *dictproxy* cache build finished getflowgraph (?:7) entry_point getflowgraph (pypy.objspace.std.intobject:15) __init__ getflowgraph (pypy.objspace.descroperation:460) binop_mul_impl getflowgraph (pypy.objspace.std.objspace:264) type getflowgraph (pypy.objspace.std.model:108) __init__ getflowgraph (pypy.interpreter.baseobjspace:28) getclass (pypy.objspace.std.model:108) __init__ -> SomePBC(const=None) getflowgraph (pypy.objspace.std.objspace:159) gettypeobject getflowgraph (pypy.interpreter.baseobjspace:102) loadfromcache getflowgraph (pypy.interpreter.baseobjspace:102) loadfromcache getflowgraph (pypy.tool.cache:21) getorbuild getflowgraph (pypy.tool.cache:21) getorbuild (pypy.objspace.std.intobject:15) __init__ -> SomePBC(const=None) (pypy.tool.cache:21) getorbuild -> SomeInstance(can_be_None=False, classdef=W_TypeObject) (pypy.interpreter.baseobjspace:102) loadfromcache -> SomeInstance(can_be_None=False, classdef=W_TypeObject) (pypy.objspace.std.objspace:159) gettypeobject -> SomeInstance(can_be_None=False, classdef=W_TypeObject) (pypy.interpreter.baseobjspace:28) getclass -> SomeInstance(can_be_None=False, classdef=W_TypeObject) (pypy.objspace.std.objspace:264) type -> SomeInstance(can_be_None=False, classdef=W_TypeObject) ... ... ... (pypy.objspace.std.listsort:119) gallop -> SomeInteger(nonneg=False, unsigned=False) (pypy.objspace.std.objspace:166) wrap__SomePBC__SI_ControlFlowException -> SomeInstance(can_be_None=False, classdef=BaseWrappable) (pypy.objspace.std.listsort:428) merge_at -> SomePBC(const=None) getflowgraph (pypy.objspace.std.listsort:216) merge_lo (pypy.objspace.std.objspace:166) wrap__SomePBC__SI_SApplicationException -> SomeInstance(can_be_None=False, classdef=BaseWrappable) (pypy.interpreter.pyframe:415) unroll -> SomeBool(const=True) getflowgraph (pypy.objspace.std.listsort:319) merge_hi (pypy.interpreter.pyframe:382) unroll -> SomeBool() getflowgraph (pypy.objspace.std.listsort:553) copyitems (pypy.objspace.std.listsort:553) copyitems -> SomeInstance(can_be_None=False, classdef=ListSlice) getflowgraph (pypy.objspace.std.listsort:567) popright getflowgraph (pypy.objspace.std.listsort:561) popleft (pypy.objspace.std.listsort:561) popleft -> SomeInstance(can_be_None=True, classdef=W_Root) (pypy.objspace.std.listsort:567) popright -> SomeInstance(can_be_None=True, classdef=W_Root) (pypy.objspace.std.listsort:216) merge_lo -> SomePBC(const=None) (pypy.objspace.std.listsort:319) merge_hi -> SomePBC(const=None) ====================================================================== Functions that have SomeObject in their signature ====================================================================== PyCode._from_code(SomeInstance, SomeObject, const SomeBool) -> SomeInstance pypy.interpreter.pycode:101 PyInterpFrame.MISSING_OPCODE(SomeInstance, SomeObject) -> ? pypy.interpreter.pyopcode:695 StdObjSpace.unwrap(const SomePBC, SomeInstance) -> SomeObject pypy.objspace.std.objspace:223 StdObjSpace.wrap__SomePBC__SomeObject(const SomePBC, SomeObject) -> SomeInstance pypy.objspace.std.objspace:166 W_FakeFile.__init__(SomeInstance, const SomePBC, SomeObject) -> const SomePBC pypy.objspace.std.fake:98 W_FakeFile.unwrap(SomeInstance) -> SomeObject pypy.objspace.std.fake:101 W_FakeModule.unwrap(SomeInstance) -> SomeObject pypy.objspace.std.fake:101 W_FakeUnicode.__init__(SomeInstance, const SomePBC, SomeObject) -> const SomePBC pypy.objspace.std.fake:98 W_FakeUnicode.unwrap(SomeInstance) -> SomeObject pypy.objspace.std.fake:101 W_LongObject.longval(SomeInstance) -> SomeObject pypy.objspace.std.longobject:32 W_LongObject.unwrap(SomeInstance) -> SomeObject pypy.objspace.std.longobject:39 W_TupleObject.unwrap(SomeInstance) -> SomeObject pypy.objspace.std.tupleobject:20 W_TypeObject.unwrap(SomeInstance) -> SomeObject pypy.objspace.std.typeobject:212 args_from_long(SomeObject) -> SomeTuple pypy.objspace.std.longobject:527 get_unique_interplevel_subclass(SomePBC, SomeObject, SomeBool) -> SomePBC pypy.interpreter.typedef:23 string_to_long(SomeString, SomeInteger) -> SomeObject pypy.objspace.std.strutil:77 ====================================================================== somobjectness: 0 percent (16 out of 2951 functions get or return SomeObjects ====================================================================== ------------------------------------------------------------ Not generating C code. ------------------------------------------------------------ Done.

2 1

Fwd: CFP: DLS05: ACM Dynamic Languages Symposium
by Armin Rigo April 24, 2005

April 24, 2005

Hi all, I think we should consider the following conference. It's part of OOPSLA, which is definitely a prestigious conference and I believe that "language symbiosis and multi-paradigm languages" is a nice way to describe what we are trying to do with PyPy's approach. ----- Forwarded message from Guido van Rossum <gvanrossum(a)gmail.com> ----- See you all at OOPSLA! ---------- Forwarded message ---------- From: Roel Wuyts <Roel.Wuyts(a)ulb.ac.be> Date: Apr 17, 2005 10:59 PM Subject: CFP: DLS05: ACM Dynamic Languages Symposium To: python-announce-list(a)python.org CALL FOR PAPERS FOR THE ACM Dynamic Languages Symposium 2005 October 18, 2005 San Diego, California (co-located with OOPSLA'05) URL: http://decomp.ulb.ac.be:8082/events/dls05/ ----------- Abstract ----------- In industry, static languages (such as Java, C++ and C#) are much more widely used than their dynamic counterparts (like CLOS, Python, Self, Perl, php or Smalltalk). So it appears as though dynamic language concepts were forgotten and lost the race. But this is not the case. Java and C#, the latest mainstream static languages, popularized to a certain extent dynamic language features such as garbage collection, portability and (limited forms of) reflection. In the near future, we expect this dynamicity to increase even further. E.g., it is getting clearer year after year that pervasive computing is becoming the rule and that concepts such as meta programming, reflection, mobility, dynamic reconfigurability and distribution are becoming increasingly popular. All of these features are the domain of dynamic languages, and hence it is only logical that more dynamic language concepts have to be taken up by static languages, or that dynamic languages can make a breakthrough. Currently, the dynamic language community is fragmented, split over a multitude of paradigms (from functional over logic to object-oriented), languages and syntaxes. This fragmentation severely hinders research as well as acceptance, and results in either language wars or, even worse, language ignorance. The goal of this symposium is to provide a highly visible, international forum for researchers working on dynamic features and languages. We explicitly invite submissions from all kinds of paradigms (object-oriented, functional, logic, ...), as can be seen from the structure of the program committee. Areas of interests include, but are not limited to: - closures - delegation - actors, active objects - constraint systems - mixins and traits - reflection and meta-programming - language symbiosis and multi-paradigm languages - experience reports on successful application of dynamic languages Accepted Papers will be published in the ACM Digital Library. ------------------------------- Submission Guidelines ------------------------------- Papers will need to be submitted using an online tracking system, of which the URL will be given later. All papers must be submitted electronically in PDF format (or PostScript, if you do not have access to PDF-producing programs, but this is not recommended). Submissions, as well as final versions, must be formatted to conform to ACM Proceedings requirements: Nine point font on ten point baseline, two columns per page, each column 3.33 inches wide by 9 inches tall, with a column gutter of 0.33 inches, etc. See the ACM Proceedings Guidelines. You can save preparation time by using one of the templates from that page. Note that MS Word documents must be converted to PDF before being submitted. ---------------------- Important Dates ---------------------- - Deadline for receipt of submissions: June 24th 2005 - Notification of acceptance or rejection: August 5th 2005 - Final version for the proceedings: To be announced later --------------------------- Program Committee --------------------------- - Gilad Bracha - Wolfgang De Meuter - Stephane Ducasse - Gopal Gupta - Robert Hirschfeld - Dan Ingalls - Yukihiro Matsumoto - Mark Miller - Eliot Miranda - Philippe Mougin - Oscar Nierstrasz - Dave Thomas - David Ungar - Guido Van Rossum - Peter Van Roy - Jon L White (G) - Roel Wuyts (Chair) -- Roel Wuyts DeComp roel.wuyts(a)ulb.ac.be Université Libre de Bruxelles http://homepages.ulb.ac.be/~rowuyts/ Belgique Vice-President of the European Smalltalk Users Group: www.esug.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/arigo%40tunes.org ----- End forwarded message -----

1 0

result of mini-sprint / documentation
by hpk＠trillke.net April 17, 2005

April 17, 2005

Hi folks, Armin and me have spent today on largely reworking and refactoring PyPy's documentation. On http://codespeak.net/pypy/index.cgi?doc you'll see a cleaned up entry page and navigation bar, and much cleaned up and cross-referenced content. Moreover, the integrity of the links in the ReST files are now checked within our testing process. If you issue:: python test_all.py documentation then ReST-checks as well as link checks are performed. If you provide the '-R' option then also all remote links are checked for existence. Running 'py.test' or 'python test_all.py' in the pypy directory will run the non-remote documentation checks by default. Our documentation rework should provide a good basis for continued updating and improvement of the documentation. Btw, there is a 'redirections' file which contains a mapping from old names to new names/locations which the web site uses to map old URLs to new places (via a Redirect). Try e.g.: http://codespeak.net/pypy/index.cgi?doc/howtopypy.html or any other old URL. Feedback (and helping with improving the documentation further) is very welcome! cheers, holger

1 0