Mailman 3 June 2005 - pypy-dev

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

10 Oct '05

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

pirate list
by Michal Wallace 13 Jul '05

13 Jul '05

Hello, PyPy list :) I've just started a new list for pirate, a python compiler for the parrot virtual machine. Pirate is written in python and currently uses the standard compiler package. However, as parrot supports native types, I would like to refactor it so that it can also work with PyPy's type annotation system (and possibly integrate with pypy in other ways) The pirate website is here: http://pirate.tangentcode.com/ Quite a bit of work has been done on pirate since I last updated the website back in 2003, mostly by Sam Ruby of http://intertwingly.net/ Sam is giving a python-on-parrot presentation at OSCON on August 4, so I'd like to get a few things cleaned up before then - for example, updating the site, creating a development roadmap, an fixing the code to work with the latest version of parrot, etc. If you're interested in helping out with any of these things, or just want to talk about pirate, then feel free to hop on board. The signup page is here: http://cornerhost.com/mailman/listinfo/pirate Thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal(a)sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ -------------------------------------

2 3

worth reading: Steve Jobs
by Christian Tismer 01 Jul '05

01 Jul '05

hi friends, the following is a so-called "commencement" talk. For those of you who could just enjoy an A-levels talk. - this one is one done right! - for those of you who feel too old to read this: show it to your kids. http://news-service.stanford.edu/news/2005/june15/jobs-061505.html ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> 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/

2 1

Re: [pypy-svn] r14022 - pypy/extradoc/sprintinfo
by Michael Hudson 30 Jun '05

30 Jun '05

arigo(a)codespeak.net writes: > +* fix floats:: > + - translator/c/float_include.h should catch floating-point signals > + with a technique similar to CPython's. This is not 100% clear, by the way. I wouldn't claim that all of what follows is solid fact (but I think I know more about this sort of thing than most of the other PyPyers...). The floating point standards define a bunch of conditions: Overflow (eg huge number * huge number) Underflow (tiny number / huge number) DivisionByZero (finite value / zero) InvalidOperation (0 / 0) Inexact (for things like 1.0 / 10.0) Rounded (when rounding occurs, not entirely sure how this differs from Inexact, tbh) and maybe a few more. Each condition has an independent setting ('trap') as to whether it's occurence should halt computation. There is some standard (not sure which, IEEE 754, SUS, POSIX, ...) that says programs should start up with all traps disabled, so we shouldn't really need to catch SIGFPE. I'm also far from convinced that the SIGFPE code is ever used today in Python (does anyone pass --with-fpectl to configure?). I think that there are some platforms which don't start up with all traps disabled, but the correct approach for them is to find out the incantation to whack them into standards mode and use that. At the PyPy level we should probably decide on which traps are enabled by default (at least DivisionByZero is traditional) and try to be consistent about applying it (something CPython does less than well, as various groans about strutil.string_to_float indicate). We probably don't want to get into the business of doing this at the FPU level, or at least not yet. My opinion: PyPy should trap DivisionByZero and InvalidOperation. There's a case for trapping Overflow, but CPython doesn't do this (most of the time...). It would be insane IMHO to trap Underflow or Inexact or Rounded. Another question is whether we want to support user control of this stuff. All these issues affect Lib/decimal.py by the way, and reading the documentation of that module is probably a good way to get an idea of the area. A possible post-sprint task would be making the aforementioned strutil.string_to_float less horribly naive and finally fixing the rounding issues in _float_formatting.py (for the last, some guy a while ago sent me some dylan code that might help... let me upload it: http://starship.python.net/crew/mwh/format.dylan http://starship.python.net/crew/mwh/float.dylan ). I can provide references for both these tasks, if anyone looks interested. Cheers, mwh -- You sound surprised. We're talking about a government department here - they have procedures, not intelligence. -- Ben Hutchings, cam.misc

1 0

sprint day 3
by Michael Hudson 26 Jun '05

26 Jun '05

Yesterday was another good day at the pre-EP sprint. We mostly started by polishing stuff from the day before -- unicode characters, pre-built caches. Holger and Michael removed by writing boring code a use of specialize:memo we weren't feeling intelligent enought to support in the rtyper. Armin and Anders made yet another pass through the list of partially supported 'builtins'[1] and made some decisions about whether support should be removed, finished or ignored for now. The we had bit of a planning session and decided that (Christian and Arre) and (Anders and Armin) would pair on supporting builtins and Holger, Samuele and Michael would work on translator issues. Holger and Michael implemented for the C translator the few remaining unsupported float operations the rtyper could emit. Arre and Christian implemented a few more operations on rdicts. Armin and Anders worked on the list of builtins in the usual fashion: sometimes removing code now deemed to be not rpython, sometimes by removing special-casing code that was no longer necessary and sometimes by adding code to the rtyper. Holger, Michael and Samuele attempted to translate demo/bpnn.py and fixed the problems they ran into; this included obscure behaviour when the rtyper hit code calling a statically known bound method of a Constant, the same when the Constant was of a class that was only seen by the RTyper as a class of such a Constant and not elsewhere. Holger and Armin refactored some of the rtyper code in the area of equality. Michael and Samuele fixed some broken code in the c translator in the area of calling C functions not implemented by us. Anders with help from Armin implemented is_true for PBC and fixed some bugs. Holger and Armin implemented yet another sort of dictionary: 'constant' dicts that are built at initialization time and only queried thereafter. Then we called it a day and went for dinner. Today, we plan to carry on the above and do a little planning for the post-EP sprint (which I won't be at, as I'll be involved in the much-more-entertaining task of moving house) and maybe, maybe, writing a talk for that conference we hear is happening quite soon. Cheers, mwh -- The Oxford Bottled Beer Database heartily disapproves of the excessive consumption of alcohol. No, really. -- http://www.bottledbeer.co.uk/beergames.html (now sadly gone to the big 404 in the sky)

1 0

sprint day 2
by Michael Hudson 25 Jun '05

25 Jun '05

Yesterday was less obviously productive than day 1, possibly because you now have to go quite a lot higher up the tree to find the lowest fruit by now... Arre and Holger finished off string-keyed dictionary stuff. Anders and Samuele did the list builtin. Armin and Michael did isinstance. Michael and Armin wrote some grotty float parsing code and removed the only use of the float builtin on a string (if anyone has some nice and less numerically naive float parsing code or wants to write some, feel free -- it's a fairly self contained task). Christian worked on reducing the use of import * in rpython/ (though really we should have less 'from module import thing ... thing' and more 'import module ... module.thing', but this still an improvement). Holger and Armin removed some of the uses of dictionaries in the to-be-translated code. Michael and Samuele implemented a very limited str for instances. Arre and Anders implemented a 'unicode character' for the rtyper and c backend. Michael and Samuele investigated issues preventing the translation of demo/bpnn.py. Holger and Armin worked on functions like Cache.getorbuild which need to be treated specially by the annotator and rtyper (because the 'build' part is not allowed to happen at runtime). Then Michael, Samuele and the two Anders went to a midsomar party, and at 1pm the day after, Samuele hasn't been seen since... Cheers, mwh -- python py.py ~/Source/python/dist/src/Lib/test/pystone.py Pystone(1.1) time for 5000 passes = 19129.1 This machine benchmarks at 0.261381 pystones/second

1 0

sprint report, day 1
by Michael Hudson 25 Jun '05

25 Jun '05

Nothing official, but as I'm stting here waiting for the others to arrive, I thought I'd wirte a little bit about what we did yesterday (all my own opninions and recollections, corrections welcome :-). The people present and hacking were: Armin, Samuele, Christian, Holger, Michael, Anders (C) and Anders (L). We started by writing: http://codespeak.net/svn/pypy/extradoc/sprintinfo/pre-ep2005-planning.txt (which actually started as a mail Armin sent to pypy-dev a week or so ago, and was edited during the day to reflect progress). Then in a pretty informal way we paired or tripled up and got cracking. Generally speaking, it was encouraging how quickly everyone became productive, it says good things about the current design of codebase (and also indicates how much work there is left to do...). Almost all of the work happened at the rtyper level: http://codespeak.net/pypy/index.cgi?doc/translation.html#the-rpython-typer that sits between the annotator and the language backends. Samuele and Michael mostly worked on string operations in rpython, implementing conversions from ints to strings and limited string formatting operations, did a couple of easy builtins and worked out which were going to be hard. Anders (L) and Christian worked mostly on rpython lists and tuples, and also did string slicing. Anders (C), Holger and Armin mostly worked on rpython dictionaries (the ones that will hold keyword arguments during argument processing, among a few other things), and nearly finished it. Right, the others are hear now, so it's time to start hacking again... Cheers, mwh -- While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work. -- C Hacking -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

2 1

Re: [pypy-svn] r13639 - pypy/dist/pypy/translator/goal
by Ben.Young＠risk.sungard.com 21 Jun '05

21 Jun '05

You may be happy to know, on my machine, running cygwin, I get a factor of 2000 for the fast mode! Sounds like you are quite a long way towards your goal! .... (pypy.rpython.exceptiondata:109) ll_pyexcclass2exc__PyObjectPtr -> SomePtr(ll_ptrtype=<ptr(gc) to GcStruct object { typeptr: ptr() to S truct object_vtable { parenttypeptr: ptr() to Struct object_vtable { ... }, rtti: ptr() to RuntimeTypeInfo (opaque), name: ptr() to Arr ay of Char } }>) Back-end optimizations... ------------------------------------------------------------ Generating and compiling C code... Running! translated rpystone.pystones/fast time for 1000000000 passes = 2.16684 This machine benchmarks at 4.61501e+008 translated rpystone/fast pystones/second CPython: rpystone.pystones/fast time for 50000 passes = 0.215902 This machine benchmarks at 231587 rpystone/fast pystones/second ------------------------------------------------------------ Done. --Return-- > c:\documents and settings\youngb\dist\pypy\translator\goal\translate_pypy.py(474)debug()->None -> func(*args) (Pdb) 4.61e8/231587 1990.6125991528022 (Pdb) pypy-svn-bounces(a)codespeak.net wrote on 20/06/2005 23:14:26: > Author: tismer > Date: Tue Jun 21 00:14:25 2005 > New Revision: 13639 > > Modified: > pypy/dist/pypy/translator/goal/targetrpystone.py > pypy/dist/pypy/translator/goal/targetrpystone2.py > Log: > did some testing with the newly generated code. > At first glance, it looks great, if we can trust > the timing. > For "slow" mode, I get a factor of 43. > For "fast"mode, I get 250 or more, and I bumped > the iterations to 10**9. But real run-time > seems to be several seconds, so I think we can't trust > these results. Something must be wrong with the dry-running. > Will look abit deeper when on the train. > > Modified: pypy/dist/pypy/translator/goal/targetrpystone.py > ============================================================================== > --- pypy/dist/pypy/translator/goal/targetrpystone.py (original) > +++ pypy/dist/pypy/translator/goal/targetrpystone.py Tue Jun 21 > 00:14:25 2005 > @@ -1,6 +1,6 @@ > import targetrpystonex > > -LOOPS = 150000 > +LOOPS = 2000000 > > # targetrpystonex.rpystone.setslow(False) > > > Modified: pypy/dist/pypy/translator/goal/targetrpystone2.py > ============================================================================== > --- pypy/dist/pypy/translator/goal/targetrpystone2.py (original) > +++ pypy/dist/pypy/translator/goal/targetrpystone2.py Tue Jun 21 > 00:14:25 2005 > @@ -1,7 +1,7 @@ > import targetrpystonex > > > -LOOPS = 1000000 > +LOOPS = 1000000000 #10**9 > > targetrpystonex.rpystone.setslow(False) > > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

3 2

Re: [pypy-svn] r13653 - pypy/dist/pypy/rpython[POSSIBLE SPAM]
by Ben.Young＠risk.sungard.com 21 Jun '05

21 Jun '05

Hi Armin, Not sure if it was this changelist, but you are new generating c with nested comments, which doesn't seem to be allowed by all compilers. e.g. /* /* nothing */ = v106238->z_cls_my_method; */ Cheers, Ben pypy-svn-bounces(a)codespeak.net wrote on 21/06/2005 12:48:42: > Author: arigo > Date: Tue Jun 21 13:48:41 2005 > New Revision: 13653 > > Modified: > pypy/dist/pypy/rpython/rpbc.py > pypy/dist/pypy/rpython/rtyper.py > Log: > - Method calls sanitization, by falling back to function calls code. > - Nicer error message for hop.inputarg() argument count mismatch. > > > Modified: pypy/dist/pypy/rpython/rpbc.py > ============================================================================== > --- pypy/dist/pypy/rpython/rpbc.py (original) > +++ pypy/dist/pypy/rpython/rpbc.py Tue Jun 21 13:48:41 2005 > @@ -355,30 +355,26 @@ > "methods can be found: %r" % ( > s_pbc.prebuiltinstances,)) > # the low-level representation is just the bound 'self' argument. > - self.r_instance = rclass.getinstancerepr(rtyper, self.classdef) > - self.lowleveltype = self.r_instance.lowleveltype > + self.s_im_self = annmodel.SomeInstance(self.classdef) > + self.r_im_self = rclass.getinstancerepr(rtyper, self.classdef) > + self.lowleveltype = self.r_im_self.lowleveltype > > def rtype_simple_call(self, hop): > - # XXX the graph of functions used as methods may need to be hacked > - # XXX so that its 'self' argument accepts a pointer to an instance of > - # XXX the common base class. This is needed to make the direct_call > - # XXX below well-typed. > - r_class = self.r_instance.rclass > + r_class = self.r_im_self.rclass > mangled_name, r_func = r_class.clsfields[self.methodname] > assert isinstance(r_func, FunctionsPBCRepr) > - # > - # XXX try to unify with FunctionsPBCRepr.rtype_simple_call() > - f, rinputs, rresult = r_func.function_signatures.itervalues().next() > - vlist = hop.inputargs(self, *rinputs[1:]) # ignore the > self from r_func > - if r_func.lowleveltype == Void: > - assert len(r_func.function_signatures) == 1 > - vfunc = hop.inputconst(typeOf(f), f) > - else: > - vinst = vlist[0] > - vcls = self.r_instance.getfield(vinst, '__class__', hop.llops) > - vfunc = r_class.getclsfield(vcls, self.methodname, hop.llops) > - vlist.insert(0, vfunc) > - return hop.genop('direct_call', vlist, resulttype = rresult) > + s_func = r_func.s_pbc > + > + hop2 = hop.copy() > + hop2.args_s[0] = self.s_im_self # make the 1st arg stand > for 'im_self' > + hop2.args_r[0] = self.r_im_self # (same lowleveltype as 'self') > + > + v_im_self = hop.inputarg(self, arg=0) > + v_cls = self.r_im_self.getfield(v_im_self, '__class__', hop.llops) > + v_func = r_class.getclsfield(v_cls, self.methodname, hop.llops) > + hop2.v_s_insertfirstarg(v_func, s_func) # insert 'function' > + # now hop2 looks like simple_call(function, self, args...) > + return hop2.dispatch() > > > # ____________________________________________________________ > > Modified: pypy/dist/pypy/rpython/rtyper.py > ============================================================================== > --- pypy/dist/pypy/rpython/rtyper.py (original) > +++ pypy/dist/pypy/rpython/rtyper.py Tue Jun 21 13:48:41 2005 > @@ -417,9 +417,10 @@ > inputconst = staticmethod(inputconst) # export via the > HighLevelOp class > > def inputargs(self, *converted_to): > - assert len(converted_to) == self.nb_args, ( > - "operation argument count mismatch: '%s' has %d arguments" % ( > - self.spaceop.opname, self.nb_args)) > + if len(converted_to) != self.nb_args: > + raise TyperError("operation argument count mismatch:\n" > + "'%s' has %d arguments, rtyper wants %d" % ( > + self.spaceop.opname, self.nb_args, len(converted_to))) > vars = [] > for i in range(len(converted_to)): > vars.append(self.inputarg(converted_to[i], i)) > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

2 1

Summer of code mentors
by Armin Rigo 21 Jun '05

21 Jun '05

Hi all, For Google's Summer of Code, the Python Software Foundation could do with more mentors willing to supervise projects. We are in the process of choosing proposals, and aim roughly at 20-25 accepted ones. I know we are at least 3 mentors on this list, but I thought I'd ask anyway if someone else wants to jump in, it's not too late yet :-) Inofficially -- hint without guarantee -- we might accept two PyPy-related proposals. Would-be mentors will be about other Python-related stuff -- there is a wide range of subjects and ideas. Armin

1 0