Mailman 3 May 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

dev meeting 2nd June 3pm (CEST)
by hpk＠trillke.net 02 Jun '05

02 Jun '05

Hi pypy-dev, it makes sense to discuss a few issuses regarding future development work (apart from the very nice and successful translation meeting we had last week). I suggest to meet Thursday, 2nd June, 3pm (CEST == GMT+1) on #pypy at irc.freenode.net. Here are suggested topics: - sprint announcement/themes: although times and city are fixed already, the actual sprint topics for the post-europython sprint from 1st July - 7th July in Goetheborg (Sweden) are not yet decided and announced. However, almost all active developers will come and it's already safe to reserve the time and book your flights if you want to attend a newcomer-friendly sprint! - release planning: there is the idea to do a PyPy-0.6.2 around EuroPython or even as the finishing event of the public EuroPython sprint. Goals for this possible release need some discussion, though. Here is a suggestion: - move our lib-python base to 2.4.1 - make documentation more complete (e.g. interpreter/ docs are still missing) - integrate parser module (possibly making it RPython conformant) (- maybe offer a small tool to translate small RPython programs) - giving the translation efforts a stable base: One problem with ongoing development of PyPy is that the translation process is still somewhat fragile with respect to type inference (annotation) on our source tree. Therefore, it would be good if translation could for some time rely on a non-changing PyPy base. One simple idea is to fork off translation work in a branch, although i'd like to avoid that if possible. For starters, documentation changes in the branch would not be immediately seen on the website. Any other _simple_ ideas? - Advancing Issue Tracking: we probably want to decide how we proceed with issue tracking and especially classifications of issues. There is the simple idea of assigning an 'easy', 'medium' and 'hard' value to each issue to make it easier for newcomers and for ourselves. Moreover, if we go for a 0.6.2 release i think we should redesign the tracker schema to use 'release' instead of 'milestone'. - news/infos: there are news regarding a guy who is likely to enter the EU/PyPy project and who comes from the Squeak (Smalltalk mostly implemented in Smalltalk) world. Just so you know. - anything else i forgot (please post before instead of suggesting it at the meeting -> better planning) cheers & see you, holger

5 6

Re: [pypy-svn] r12876 - pypy/dist/lib-python/modified-2.3.4/encodings
by Armin Rigo 30 May '05

30 May '05

Hi Ale, On Mon, May 30, 2005 at 12:38:23AM +0200, ale(a)codespeak.net wrote: > - encode = codecs.escape_encode > - decode = codecs.escape_decode > + encode = staticmethod(codecs.escape_encode) > + decode = staticmethod(codecs.escape_decode) Sorry, I missed an older checkin (r11820) where you did something similar. There must be another way than modifying the encodings package (as you hint in the check-in message). Some time ago, for precisely this reason, we introduced a way to define functions that aren't bound in the normal Python way, but behave like CPython's builtin functions: def escape_encode( obj,errors='strict'): """None """ s = repr(obj) v = s[1:-1] return v,len(v) escape_encode = types.BuiltinFunctionType(escape_encode) I'm still unsure if it's a good solution to use it all over the place in _codecs.py because it's PyPy-specific. Another solution is to keep _codecs.py clean of this, but put the whole module in pypy/module/_codecs/app__codecs.py instead of pypy/lib/. This way, all functions exported by the _codecs module become "builtin functions" automatically. (It also allows you to hide parts you don't want to export, like the codec_search_path and codec_search_cache registry.) The advantage is that app__codecs.py by itself is still usable by non-PyPy projects. A bientot, Armin

1 0

Introduction
by Suman Karumuri 29 May '05

29 May '05

Hi all, I am suman from india. I have completed my B.E(bachelors degree) in Computer science and inf. technology. I am currently working as a software programmer for ADP. I am highly interested in programming language research and can code in most of the imperative OO/procedural languages. I have used python to write soem scripts for the company i work for and i use it on a day to day basis to generate repetitive SQL code. My skillset includes, c/c++/java/python. In near future i want to implement a useful and successful visual programming language and so want to get a hands my hands dirty with a programming language implementation and hence chose pypy. I do not mind working on any part of the code, but as i can contribute my weekends i cannot work on peices which are needed for immediete development. -Suman

1 0

Re: [pypy-svn] r12855 - pypy/dist/pypy/rpython
by Armin Rigo 28 May '05

28 May '05

Hi Eric, On Sat, May 28, 2005 at 12:25:07AM +0200, ericvrp(a)codespeak.net wrote: > - v_int1 = receive(Unsigned, arg=0) > - v_int2 = receive(Unsigned, arg=1) > + v_int1 = _receive_may_cast(s_int1, Unsigned, 0) > + v_int2 = _receive_may_cast(s_int2, Unsigned, 1) As you just added casts between signed and unsigned in convert_from_to(), the _receive_may_cast() helper you define and use in this check-in should not be necessary -- indeed, the purpose of the original receive() is precisely to detect a mismatch between the actual and the requested type of the argument and generate a conversion if necessary, by calling convert_from_to(). Armin

1 3

possible flowgraph simplification?
by Eric van Riet Paap 28 May '05

28 May '05

Hi, When this function gets annotated... *def h(n): return not n* An additional block is generated. Is this something that should/can be avoided by the annotator? If this is unavoidable I would like to dive a little in the annotator simplifier to try to merge the blocks. cheers Eric

2 1

_codecs.py test results
by Armin Rigo 28 May '05

28 May '05

Hi Anders, I ran the CPython tests with inprogress__codecs.py renamed to _codecs.py. As I should probably not check them in "the normal way", to avoid confusing the web reports, I checked them into http://codespeak.net/svn/user/arigo/hack/pypy-hack/testresult-codecs/ which you can check out and inspect (Holger, comments on a good way to dig into these 133 files locally?). There are 26 failures, which is 8 more than reported by http://codespeak.net/~hpk/pypy-testresult/ on the trunk -- not too bad, I suppose. Sorry, I didn't figure out so far which ones these 8 tests are... small Python scripts ahead :-) Also, we should move some unicode-specific tests from "non-core" to "core" now. If test_unicode takes ages to run we should try to reduce the longest-running loops. Armin

1 0

Re: [pypy-dev] Re: [pypy-svn] r12801 - pypy/dist/pypy/rpython
by Armin Rigo 27 May '05

27 May '05

Hi Eric, (CC'ing to pypy-dev, hope you don't mind...) On Thu, May 26, 2005 at 09:04:13PM +0200, Eric van Riet Paap wrote: > About making itless verbose: I wasn't sure > how much dynamic coding was allowed in this file. Should this keep to > the RPython "coding standard"? No, this file doesn't have to follow the RPython rules. (Also note that even if it did, you are allowed to use 'exec' and any strange things when the module is imported and the class defined.) > Do we want a rbool.py for consistancy (and a rfloat.py). Or do we want > the whole thing in one file and assume its size will shrink when refactored? I guess rbool.py and rfloat.py make sense. Armin

2 1

Diagram of translation process
by Carl Friedrich Bolz 26 May '05

26 May '05

Hi pypy-dev, I got a bit bored yesterday and threw together a diagram that shows the various stages of the PyPy translation process. Look there: http://codespeak.net/~cfbolz/translation.pdf Regards, Carl Friedrich

2 1

Re: [pypy-svn] r12801 - pypy/dist/pypy/rpython
by Armin Rigo 26 May '05

26 May '05

Hi Eric, On Thu, May 26, 2005 at 11:57:57AM +0200, ericvrp(a)codespeak.net wrote: > pypy/dist/pypy/rpython/rint.py > Log: > added more rint methods. Someone please check if this is basicly right! Yes, great work (if boringly repetitive :-) The policy about signed versus unsigned operations is not very clearly defined for the moment. Some operations give a different result when interpreting their arguments as signed or unsigned, while others don't. A few details about it: > + def rtype_lshift((s_int1, s_int2)): > + if s_int1.unsigned or s_int2.unsigned: According to annotation/binaryop.py, lshift and rshift are signed/unsigned depending on the first argument only, not on the shift count. > + def rtype_pow((s_int1, s_int2)): > + #XXX RPythonTyper gives this error: TypeError: rtype_pow() takes exactly 1 argument (2 given) 'pow' is the equivalent of the built-in pow(), which can take a third argument. Our pow operation always takes three arguments. But at this point rtype_pow should probably only generate a two-arguments int_pow or uint_pow, optionally followed by a second operation, int_mod or uint_mod, depending on if the 3rd arg is a SomeInteger or a None: def rtype_pow((s_int1, s_int2), s_int3): ... v_result = direct_op(...) if isinstance(s_int3, SomeInteger): v_int3 = receive(...) v_result = direct_op(..., [v_result, v_int3], ...) elif s_int3.is_constant() and s_int3.const is None: pass else: raise TyperError("pow() 3rd argument must be int or None") return v_result > + def rtype_eq((s_int1, s_int2)): Should probably use the same logic as rtype_l & friends, to avoid considering a signed negative number as possibly equal to a large unsigned number. > + #Unary arithmetic operations Same signed/unsigned distinctions needed... For abs of an unsigned number, and for pos: > + def rtype_pos(s_int): > + #XXX I think this is a nop and should really be removed from the graph you can just return the received v_int variable directly, without any direct_op(). A bientot, Armin

2 1