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

Regular Expression in PyPy
by Seo Sanghyeon Jan. 31, 2005

Jan. 31, 2005

In the checkin message of r8719, hpk wrote: > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > slight changes and were borrowing _sre from CPython anyway. > So let's back out our changes in pypy/lib and see how far we > get (if nobody minds, Seo?) But I mind! Let me explain this... Just before the checkin (r8718), there were following files in pypy/lib related to regular expression: re.py, dumbre.py, plexre.py, sre_adapt.py, sre_parse.py. You deleted re.py, sre_adapt.py, sre_parse.py. re.py contained (intended to contain) backend-neutral interface and utilities, like this: def match(pattern, string, flags=0): return compile(pattern, flags).match(string) And compile() does memoizing, just as CPython, etc. And re.escape() copied from CPython. These are backend-neutral. re.py imported Pattern class from the backend. Pattern's initializer has signature __init__(self, pattern, flags), and has methods of C type _sre.SRE_Pattern, like match, search, etc. And there were three backends (draft of backends) providing this Pattern class: dumbre.py, plexre.py, sre_adapt.py. Only sre_adapt.py imports CPython's _sre, others don't! You can read dumbre.py and plexre.py now, since you didn't delete them by mistake. :-) See, "dumbre.py" is exactly what you're referring as "see how far we get". It exits as soon as regular expression is used, and reports what was used. And this was the default re.py imported. (see below) "plexre.py" is more interesting, and it uses Plex to implement (for now) match(), but returns bool rather than full Match object. This is sufficient for all "if re.match(pattern, string):" tests, and this let pickle import and run, unmodified. (As I wrote in the log of r8636...) pickle uses regular expression only once, as following: __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$",x)]) This also means PyPy interprets all of Plex just fine. Since Plex does regular expression parsing, NFA->DFA transformation, state machine all in pure Python, this is actually quite cool. "sre_adapt.py" is, as you see, cheating. It contains a single line: Pattern = sre_compile.compile And this does not work. Currently C types are not succesfully faked, so _sre.SRE_Pattern instances are created (well, see below) but all method calls will result in long traceback. I asked why is this on IRC long time ago, and I heard that it's because this C type lacks __dict__. Same applies for _random.Random, I think. That's why we have pure Python random.py from 2.2.3 in lib directory now. And why is sre_parse.py patched? Because, without those, no _sre.SRE_Pattern instances will be created, because PyPy fails to interpret some part of sre_parse.py. How to reproduce this problem: (with current PyPy) >>>> re.compile('a*') Traceback (application level): (snip) AttributeError: getwidth Why is this? I wrote my reasoning on the log of this file... r3332 and r3456. To show what's going on, I will give an example: class A: def getwidth(self): print 'hahaha' class B: def getwidth(self): print 'lalala' class C: def __getitem__(self, index): return A() def __getslice__(self, start, stop): return B() c = C() c[0].getwidth() c[0:1].getwidth() CPython prints hahaha and lalala. PyPy prints both hahaha. And sre_parse uses __getslice__... And this is the only place getslice is used, in entire Python standard library! (except those in UserList and UserString) And getslice is deprecated since release 2.0, as officially announced in Language Reference 3.3.6. Okay, can I back your deletion now? :-) Seo Sanghyeon

2 1

Regular Expression in PyPy
by Seo Sanghyeon Jan. 31, 2005

Jan. 31, 2005

In the checkin message of r8719, hpk wrote: > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > slight changes and were borrowing _sre from CPython anyway. > So let's back out our changes in pypy/lib and see how far we > get (if nobody minds, Seo?) But I mind! Let me explain this... Just before the checkin (r8718), there were following files in pypy/lib related to regular expression: re.py, dumbre.py, plexre.py, sre_adapt.py, sre_parse.py. You deleted re.py, sre_adapt.py, sre_parse.py. re.py contained (intended to contain) backend-neutral interface and utilities, like this: def match(pattern, string, flags=0): return compile(pattern, flags).match(string) And compile() does memoizing, just as CPython, etc. And re.escape() copied from CPython. These are backend-neutral. re.py imported Pattern class from the backend. Pattern's initializer has signature __init__(self, pattern, flags), and has methods of C type _sre.SRE_Pattern, like match, search, etc. And there were three backends (draft of backends) providing this Pattern class: dumbre.py, plexre.py, sre_adapt.py. Only sre_adapt.py imports CPython's _sre, others don't! You can read dumbre.py and plexre.py now, since you didn't delete them by mistake. :-) See, "dumbre.py" is exactly what you're referring as "see how far we get". It exits as soon as regular expression is used, and reports what was used. And this was the default re.py imported. (see below) "plexre.py" is more interesting, and it uses Plex to implement (for now) match(), but returns bool rather than full Match object. This is sufficient for all "if re.match(pattern, string):" tests, and this let pickle import and run, unmodified. (As I wrote in the log of r8636...) pickle uses regular expression only once, as following: __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$",x)]) This also means PyPy interprets all of Plex just fine. Since Plex does regular expression parsing, NFA->DFA transformation, state machine all in pure Python, this is actually quite cool. "sre_adapt.py" is, as you see, cheating. It contains a single line: Pattern = sre_compile.compile And this does not work. Currently C types are not succesfully faked, so _sre.SRE_Pattern instances are created (well, see below) but all method calls will result in long traceback. I asked why is this on IRC long time ago, and I heard that it's because this C type lacks __dict__. Same applies for _random.Random, I think. That's why we have pure Python random.py from 2.2.3 in lib directory now. And why is sre_parse.py patched? Because, without those, no _sre.SRE_Pattern instances will be created, because PyPy fails to interpret some part of sre_parse.py. How to reproduce this problem: (with current PyPy) >>>> re.compile('a*') Traceback (application level): (snip) AttributeError: getwidth Why is this? I wrote my reasoning on the log of this file... r3332 and r3456. To show what's going on, I will give an example: class A: def getwidth(self): print 'hahaha' class B: def getwidth(self): print 'lalala' class C: def __getitem__(self, index): return A() def __getslice__(self, start, stop): return B() c = C() c[0].getwidth() c[0:1].getwidth() CPython prints hahaha and lalala. PyPy prints both hahaha. And sre_parse uses __getslice__... And this is the only place getslice is used, in entire Python standard library! (except those in UserList and UserString) And getslice is deprecated since release 2.0, as officially announced in Language Reference 3.3.6. Okay, can I back your deletion now? :-) Seo Sanghyeon

1 0

Re: [pypy-svn] r8642 - pypy/dist/pypy/objspace/std
by Christian Tismer Jan. 28, 2005

Jan. 28, 2005

ludal(a)codespeak.net wrote: > Author: ludal > Date: Thu Jan 27 18:06:26 2005 > New Revision: 8642 > > Modified: > pypy/dist/pypy/objspace/std/stringobject.py > Log: > keep a cache of the hash value of strings like CPython does Hi! I think it is a fine idea to do the hash cache. Just a comment...: > Modified: pypy/dist/pypy/objspace/std/stringobject.py ... > def hash__String(space, w_str): > - return W_IntObject(space, hash(w_str._value)) > + w_hash = w_str.w_hash > + if w_hash is None: > + w_hash = W_IntObject(space, hash(w_str._value)) > + w_str.w_hash = w_hash > + return w_hash I don't see the point why the hash should be stored as a wrapped value. IMHO, the main use of the hash is inside of dict objects. Wouldn't it make more sense to cache the unwrapped value, since we (as I think) do the hashing in a dict with an unwrapped integer, anyway? It is also more conformant with CPython, where the hash is an internal implementation detail. Maybe I just missed something, so anyway - good night! (Ludovic, I don't have your email contact) cheers - 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

codespeak.net/pypy problem
by Jacek Generowicz Jan. 26, 2005

Jan. 26, 2005

There seems to be a problem with the PyPy pages. This is what I get when I try to access any of them: A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /www/codespeak.net/htdocs/pypy/index.cgi 7 basedir = os.path.dirname(os.path.dirname(real)) 8 sys.path.insert(0, basedir) 9 10 from pypywww import cgi 11 cgi.main(basedir) pypywww undefined, cgi undefined SyntaxError: invalid syntax (cgi.py, line 29) args = ('invalid syntax', ('/projects/pypy/www/pypywww/cgi.py', 29, 9, ' <doc>: \n')) filename = '/projects/pypy/www/pypywww/cgi.py' lineno = 29 msg = 'invalid syntax' offset = 9 print_file_and_line = None text = ' <doc>: \n'

2 2

Re: [pypy-dev] module writing
by Florian Bauer Jan. 25, 2005

Jan. 25, 2005

Hey Doug, I don't know exactly. Isn't there a pure python implementation for quoted printable in the python sources (I think in quopri.py or something). I would just use this code. Another thing: I don't have much time at the moment to finish my binascii code. Perhaps it's best if I pass my code to you, so you can have a look at it and perhaps merge it with yours and check it in? What do you think? Cheers Flo

2 1

[patch] fix for dot bad string generation
by Olivier Dormond Jan. 25, 2005

Jan. 25, 2005

Here is a patch to fix dot producing label surounded by <> instead of ""

3 4

VEE conference
by Armin Rigo Jan. 24, 2005

Jan. 24, 2005

Hi, A quick note: we should consider if we should propose a talk on PyPy at the new "Future of Virtual Execution Environmnents" conference, a conference-style follow-up of a closed workshop held last September in New York where I met a lot of interesting people. The focus is on anything about virtual machines. The first more specific area listed on the Call for Papers is "Dynamic and high-level languages". http://www.veeconference.org Armin

1 0

Re: [pypy-svn] r8426 - in pypy/branch/src-typedunwrap/pypy: interpreter/test objspace
by hpk＠trillke.net Jan. 21, 2005

Jan. 21, 2005

Hi Samuele, i think in the tests you checked in there are "assert"s missing ... for example, On Wed, Jan 19, 2005 at 20:34 +0100, pedronis(a)codespeak.net wrote: > Author: pedronis > Date: Wed Jan 19 20:34:37 2005 > New Revision: 8426 > > Modified: > pypy/branch/src-typedunwrap/pypy/interpreter/test/test_gateway.py > pypy/branch/src-typedunwrap/pypy/objspace/trivial.py > + def g3(space, w_a, w_b): > + return space.add(w_a, w_b) > + app_g3 = gateway.interp2app_temp(g3, > + unwrap_spec=[gateway.ObjSpace, > + gateway.W_Root, > + gateway.W_Root]) > + w_app_g3 = space.wrap(app_g3) > + self.space.eq_w( > + space.call(w_app_g3, > + space.newtuple([w('foo'), w('bar')]), > + space.newdict([])), > + w('foobar')) this does not test equality (but it at least checks that it doesn't raise an unexpected exception :-) cheers, holger

1 0

[pycon@python.org: [Python-Dev] PyCon Preliminary Program Announced!]
by Armin Rigo Jan. 21, 2005

Jan. 21, 2005

Hi all, PyCon is ready for registration, and the early bird rates end in one week. We've got a PyPy talk, "PyPy and Type Inference". Armin ----- Forwarded message from Steve Holden <pycon(a)python.org> ----- Date: Fri, 21 Jan 2005 01:06:05 +0100 (CET) From: Steve Holden <pycon(a)python.org> To: python-dev(a)python.org Subject: [Python-Dev] PyCon Preliminary Program Announced! Message-Id: <20050121000605.AAC3C1E400F(a)bag.python.org> Reply-To: PyCON(a)python.org List-Id: Python core developers <python-dev.python.org> List-Unsubscribe: <http://mail.python.org/mailman/listinfo/python-dev>, <mailto:python-dev-request@python.org?subject=unsubscribe> List-Archive: <http://mail.python.org/pipermail/python-dev> List-Post: <mailto:python-dev@python.org> List-Help: <mailto:python-dev-request@python.org?subject=help> List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>, <mailto:python-dev-request@python.org?subject=subscribe> Sender: python-dev-bounces+arigo=tunes.org(a)python.org Errors-To: python-dev-bounces+arigo=tunes.org(a)python.org Dear Python Colleague: You will be happy to know that the PyCon Program Committee, after lengthy deliberations, has now finalized the program for PyCon DC 2005. I can tell you that the decision-making was very difficult, as the standard of submissions was even higher than last year. You can see the preliminary program at http://www.python.org/pycon/2005/schedule.html and it's obvious that this year's PyCon is going to be even fuller than the last. On innovation is that there will be activities of a more social nature on the Wednesday (and perhaps the Thursday) evening, as well as keynote speeches from Guido and two other luminaries. Remember that the early bird registration rates end in just over a week, so hurry on down to http://www.python.org/pycon/2005/register.html to be sure of your place in what will surely be the premier Python event of the year. As always, I would appreciate your help in getting the word out. Please forward this message to your favorite mailing lists and newsgroups to make sure that everyone has a chance to join in the fun! regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications _______________________________________________ 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

is codespeak svn down?
by Samuele Pedroni Jan. 20, 2005

Jan. 20, 2005

I get this <D:error> <C:error/> <m:human-readable errcode="160029"> Could not open the requested SVN filesystem </m:human-readable> </D:error> trying to access trhough the web, same kind of error trying svn client. Samuele

2 1

new repolayout in place
by hpk＠trillke.net Jan. 18, 2005

Jan. 18, 2005

Hi pypy-dev, it seems the basic move to the new repo layout is complete. There are likely some broken web links here and there but i tried to take care that most of the existing links out in the wild still work. If you have a "pypy/trunk/src" checkout then you should go to that directory and issue svn switch http://codespeak.net/svn/pypy/dist The next step probably is to consolidate developer documentation into fewer files with sections and subsections and generally complete the steps mentioned in http://codespeak.net/pypy/index.cgi?doc/newrepolayout.html take care, holger

1 0

new repolayout proposal
by hpk＠trillke.net Jan. 17, 2005

Jan. 17, 2005

Hello, please find a draft of an envisioned new PyPy repository layout here: http://codespeak.net/pypy/index.cgi?doc/newrepolayout.html i plan to implement this new scheme early next week when we discussed and possibly modified it some. It does not try to prescribe the complete structure of all directories yet. Note that probably any new layout will very likely be incompatible with the old one so everyone will have to adjust checkouts accordingly. If you'd like to come up with completely other ideas then please add your proposal to the doc/newrepolayout.txt file by appending e.g. a section "new repo layout proposal No. 2". If you have slight modifications then just edit the current proposal accordingly or post them here. Of course, we can discuss general questions/considerations here on pypy-dev but let's try to keep the discussion as concrete as possible :-) cheers, holger On Sat, Jan 15, 2005 at 12:55 +0100, hpk(a)codespeak.net wrote: > Author: hpk > Date: Sat Jan 15 12:55:23 2005 > New Revision: 8293 > > Added: > pypy/trunk/doc/newrepolayout.txt > Log: > a repo layout proposal > > Added: pypy/trunk/doc/newrepolayout.txt > ============================================================================== > --- (empty file) > +++ pypy/trunk/doc/newrepolayout.txt Sat Jan 15 12:55:23 2005 > @@ -0,0 +1,75 @@ > +=========================================== > +Proposition: new svn repository layout > +=========================================== > + > +Motivation > +---------- > + > +The `PyPy repository layout`_ has evolved for two > +years into something that needs some refactoring > +to become more practical. > + > +For example, the `trunk/doc`_ directory was originally intended > +to hold developer documentation but nowadays it contains > +funding, negotiations, mails and misc-other-stuff documents. It is > +not easy and obvious anymore to know which files are relevant. > +Moreover, `trunk/doc`_ is too far away from the source code: > +developers currently checkout the 'trunk/src' directory and > +don't even get the documentation. This also makes it more > +difficult to keep the documentation up-to-date. > + > +.. _`trunk/doc`: http://codespeak.net/svn/pypy/trunk/doc > +.. _`PyPy repository layout`: http://codespeak.net/svn/pypy/ > + > +New repo layout proposal Nr. 1 > +------------------------------ > + > +Based on experiences in various repositories here is a > +new proposition describing a possible new structure > +(starting at /svn/pypy):: > + > + branch # holds branches > + tag # holds tagged dist-versions > + > + dist # holds current development > + pypy # current trunk/src/pypy > + documentation # developer documentation (inside pypy!) > + py # and other 'externals' > + setup.py # should be there at some point > + README.txt # tell how to run PyPy, the translator, tests > + LICENSE.txt # copyright notices for tree parts including pypy > + > + doc # non-dist documentations (papers etc.pp.) > + talk # various pypy-talks > + paper # various pypy-related papers (including our own) > + sprint # sprint related information (reports etc.pp.) > + irclog # IRC logs (snipped appropriately) > + > + www # website-related stuff (needs its own reconsideration) > + > + funding # funding related documents > + eu-info # official information from the EU > + contract # contract material (EU-contract, amendments) > + eu-report # eu reports (time/cost/budget) > + ... # probably more, we'll see later > + > +The idea is that developers can use a simple url:: > + > + svn co https://codespeak.net/svn/pypy/dist dist-pypy > + > +in order to get everything neccessary for sourcecode, documentation > +and test development. Obviously, if you care about the funding > +or web site application/contents you can do an appropriate checkout > +as well. > + > +Note, that having documentation inside the source tree will help > +with keeping a closer eye on documentation - especially when we > +have special ref-integrity tests for the documentation (which itself > +should reference real source-code/functions at some point). For > +example, the refactoring of unitest.py-style tests to `py.test`_ based ones > +"forgot" to modify our test-documentation in the too-far-away doc-folder. > +We should move to a scheme where such an omission will raise real > +test errors. > + > +.. _`py.test`: http://codespeak.net/py/current/doc/test.html > + > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

3 3

Re: [pypy-svn] r8324 - pypy/trunk/src/pypy/translator/test
by Armin Rigo Jan. 17, 2005

Jan. 17, 2005

Hi Holger, On Mon, Jan 17, 2005 at 12:08:01AM +0100, hpk(a)codespeak.net wrote: > Log: > skip tests if underlying system features (c-compiler mostly) > are not present. > - return t.ccompile() > + return py.test.skip_on_error(t.ccompile) Ahem! This looks like it is saying "run the difficult part that we are testing, but if anything goes wrong, just skip the test". The test *is* that t.ccompile() works correctly, and only additionally that calling the compiled function works. In practice it's more common that there is an exception-raising bug in genc.py, which is called by t.ccompile(). Armin

2 1

test_file fails, hard-coded tmp dir to blame?
by A.B., Khalid Jan. 17, 2005

Jan. 17, 2005

Hello, test_file fails at this end. It seems that it tries to create a '/tmp/tt' file, but it fails. This is so because my temp directory is at '/windows/temp' not '/tmp'. If I correctly understand this problem, then find attached a fix that got the test to pass. Hope that helps. Regards, Khalid PS. In case the developers here are interested to know, all the tests pass now on this box, including the JAVA and LISP ones which are made to use Jikes (version 1.20) and GNU CLISP (version 2.33) on Win98, MinGW built Python 2.3.5.0 (from CVS), and GCC 3.4.2 (MinGW special). Index: pypy/appspace/test/test_file.py =================================================================== --- pypy/appspace/test/test_file.py (revision 8317) +++ pypy/appspace/test/test_file.py (working copy) @@ -16,8 +16,10 @@ assert self.fd.tell() == 0 def test_case_readonly(self): - f=_file.file_('/tmp/tt', 'w') - assert f.name == '/tmp/tt' + from tempfile import mktemp + fn = mktemp() + f=_file.file_(fn, 'w') + assert f.name == fn assert f.mode == 'w' assert f.closed == False assert f.encoding == None # Fix when we find out what this is _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: [pypy-dev] test_file fails, hard-coded tmp dir to blame?
by Laura Creighton Jan. 17, 2005

Jan. 17, 2005

In a message of Mon, 17 Jan 2005 02:29:27 GMT, "A.B., Khalid" writes: >Hello, > > >test_file fails at this end. It seems that it tries to create a '/tmp/tt' > >file, but it fails. This is so because my temp directory is at >'/windows/temp' not '/tmp'. > >If I correctly understand this problem, then find attached a fix that got > >the test to pass. Hope that helps. > >Regards, >Khalid Thank you very much for the patch, which is in now. >PS. In case the developers here are interested to know, all the tests pass >now on this box, including the JAVA and LISP ones which are made to use >Jikes (version 1.20) and GNU CLISP (version 2.33) on Win98, MinGW built >Python 2.3.5.0 (from CVS), and GCC 3.4.2 (MinGW special). _Great_ to hear, thank you very much! Laura

1 0

Re: [pypy-dev] new branch src-typedunwrap
by holger krekel Jan. 15, 2005

Jan. 15, 2005

On Fri, Jan 14, 2005 at 20:45 +0100, Christian Tismer wrote: > Samuele Pedroni wrote: > >After discussing with Armin and Holger, I have created a new branch to > >explore typed unwrapping. > > Oh, did I miss an IRC discussion? i guess so. We are actually discussing things on #pypy quite a bit these days. It would be great if you keep an eye on it :-) > Does somebody happen to have a log file of the session? > I'm just curious to follow the reasoning, and to see > if I can help something. Sure, below you'll find the chat session. I just cut the log at the start and the end but not in between. Also there was an earlier (shorter) discussion which i didn't recover. But almost all of the arguments are recapped in the discussion below ... cheers, holger Jan 14 11:05:32 <pedronis> should we also really rename is_true to true_w Jan 14 11:05:43 <hpk> IMO: yes Jan 14 11:05:55 <hpk> we may do that in a branch as well Jan 14 11:06:05 <hpk> and warn on pypy-dev Jan 14 11:06:10 <arigo> good points Jan 14 11:06:12 <pedronis> I can create a branch Jan 14 11:06:18 <hpk> i don't know e.g. if Christian's translator breaks etc.pp. Jan 14 11:06:29 <hpk> although global replace works fairly well i guess Jan 14 11:06:52 <hpk> (but christian's translator is special because it targets interp-level python) Jan 14 11:07:14 <pedronis> well, it also depends what we do with the generic unwrap Jan 14 11:07:24 <pedronis> if we remove it, rename it Jan 14 11:07:54 <pedronis> I think some other translator stuff may break and need changes Jan 14 11:08:02 * hpk is off for an hour to do tax declaration work (argl!) Jan 14 11:08:48 <arigo> pedronis: I rediscovered unwrap_builtin() Jan 14 11:08:56 <pedronis> I saw that too Jan 14 11:09:14 <arigo> I'd believe that we only need that and the int_w&co Jan 14 11:09:32 <pedronis> probably yes Jan 14 11:09:50 <pedronis> I don't think we want to keep lists and tuple unwrappable Jan 14 11:09:59 <arigo> no it doesn't really make sense Jan 14 11:09:59 <pedronis> I mean directly unwrappable Jan 14 11:10:17 <pedronis> because of the mixed type cases Jan 14 11:10:19 <arigo> it's only used in some tests Jan 14 11:10:36 <pedronis> I think code objects use them Jan 14 11:10:43 <pedronis> to unwrap tuples of strings Jan 14 11:10:50 <pedronis> but it can be done differently Jan 14 11:10:55 <arigo> yes Jan 14 11:11:30 <pedronis> should str_w, int_w be multimethods in the std objspace Jan 14 11:11:39 <pedronis> if we consider multiple impl of types Jan 14 11:11:44 <pedronis> maybe yes Jan 14 11:13:07 <arigo> is_true() is no longer a MM Jan 14 11:13:45 <pedronis> yes, it's a bit of special case Jan 14 11:13:56 <arigo> right Jan 14 11:14:03 <pedronis> because it corresponds also to __nonzero__ Jan 14 11:14:11 <arigo> well we have __int__, __str__ etc Jan 14 11:14:12 <pedronis> so it goes through descrops Jan 14 11:14:30 <pedronis> yes but I don't think we want int_w to correspond to __int__ Jan 14 11:14:38 <pedronis> or maybe yes Jan 14 11:14:41 <arigo> I thought so Jan 14 11:15:21 --> lypanov (~alex(a)a80-126-190-213.adsl.xs4all.nl) has joined #pypy Jan 14 11:15:47 <pedronis> well but for str_w in often does not make sense, some function takes a string not everything that defines __str__ Jan 14 11:16:00 <pedronis> s/takes/takes just Jan 14 11:16:13 <arigo> hum, right Jan 14 11:16:35 <pedronis> we already have space.int Jan 14 11:16:37 <arigo> should it be readbuf_w()? (argh) Jan 14 11:16:37 <pedronis> btw Jan 14 11:17:12 <pedronis> that means that in parse_w we could have specifier both behaviors Jan 14 11:17:25 <pedronis> that menas something that implements the buffer intf Jan 14 11:17:32 <pedronis> s/menas/means Jan 14 11:18:16 <arigo> raah, trying to figure out what CPython really does is messy Jan 14 11:18:29 <arigo> suppose x.__class__ has an __int__ Jan 14 11:18:36 <arigo> then you can do range(x) but not float(x) Jan 14 11:18:55 <pedronis> I think it is easier to have both kind of primitive op Jan 14 11:18:58 <pedronis> ops Jan 14 11:19:17 <pedronis> both unwrap only if of the "right" type or invoke the __xxx__ method Jan 14 11:19:28 <pedronis> and then be clever at parse_w level Jan 14 11:19:31 <arigo> (you can't do 1+x either, btw) Jan 14 11:20:05 <pedronis> yup Jan 14 11:20:18 <arigo> ouack Jan 14 11:20:21 <pedronis> so we need int_w which is different from int Jan 14 11:20:29 <arigo> "abcdef"[1:x] -> TypeError Jan 14 11:20:33 <arigo> "abcdef".__getslice__(1,x) Jan 14 11:20:34 <arigo> 'bcdef' Jan 14 11:21:17 <pedronis> I think right now it is more worth to concetrate Jan 14 11:21:31 <pedronis> moving away from the generic unwrap to typed versions thereof Jan 14 11:21:55 <pedronis> sorting the mess what CPython accepts here and there Jan 14 11:22:03 <pedronis> is a slightly different issue Jan 14 11:22:14 <arigo> so we define int_w and str_w as only accepting the real type? Jan 14 11:22:23 <pedronis> yes Jan 14 11:22:37 <pedronis> you have space.int and space.str Jan 14 11:22:43 <pedronis> for the other behavior Jan 14 11:23:18 <pedronis> that's why I'm not sure that space.is_true should become true_w Jan 14 11:23:24 <arigo> I see Jan 14 11:23:26 <pedronis> true_w would just work with boolean Jan 14 11:23:53 <pedronis> although I think there's not much in CPython that behaves that way Jan 14 11:24:04 <pedronis> with bool args Jan 14 11:24:53 <arigo> it starts to look messy again, with a lot of xxx_w() MMs for each way we'd like to unwrap objects Jan 14 11:25:04 <arigo> readbuf_w(), writebuf_w(), ...? Jan 14 11:25:36 <pedronis> well, the othe option is to pass a 2nd type arg to unwrap Jan 14 11:26:41 <pedronis> but it gets tricky to express that as true RPython Jan 14 11:26:53 --> Eventh (evenwiik(a)v201a.studby.ntnu.no) has joined #pypy Jan 14 11:27:05 <arigo> float_w should accept an int, I guess Jan 14 11:28:04 <pedronis> well, if they are multimethods at least in the std objspace Jan 14 11:28:10 <pedronis> it easy to tweak that Jan 14 11:28:49 <arigo> I'm more trying to understand what we really want... Jan 14 11:30:06 <pedronis> right now a big parts of our unwraps Jan 14 11:30:12 <pedronis> are about ints and strings Jan 14 11:31:01 <pedronis> so at least int_w and str_w seem to make sense Jan 14 11:31:35 <arigo> ok Jan 14 11:31:54 <pedronis> parse_w will also make sense Jan 14 11:32:10 <pedronis> so I think creating a branch Jan 14 11:32:26 <pedronis> and introducing int_w and str_w as first step Jan 14 11:32:46 <arigo> looks good Jan 14 11:32:58 <pedronis> then I think it is easier to see what we need beyond that Jan 14 11:33:04 <pedronis> from parse_w point of view Jan 14 11:33:12 <arigo> ok. Jan 14 11:36:38 <pedronis> I will create a src-typedunwrap branch Jan 14 11:36:43 <pedronis> and mail pypy-dev Jan 14 11:36:57 <pedronis> now I'm going to have lunch Jan 14 11:37:03 --- pedronis is now known as pedronis_lunch Jan 14 11:55:42 <-- arigo has quit ("Leaving") Jan 14 12:15:09 <-- thingie24 has quit (leguin.freenode.net irc.freenode.net) Jan 14 12:15:09 <-- dlk has quit (leguin.freenode.net irc.freenode.net) Jan 14 12:15:09 <-- etrepum has quit (leguin.freenode.net irc.freenode.net) Jan 14 12:20:20 --> thingie24 (~rmt38(a)valhalla.ccp.cc) has joined #pypy Jan 14 12:20:20 --> dlk (~dlk(a)walter.ita.chalmers.se) has joined #pypy Jan 14 12:20:20 --> etrepum (bob(a)ayunami.redivi.com) has joined #pypy Jan 14 12:22:56 --> arigo (~arigo(a)d83-176-50-66.cust.tele2.ch) has joined #pypy Jan 14 12:26:30 --- pedronis_lunch is now known as pedronis Jan 14 12:47:44 <-- adim (~adim(a)logilab.net2.nerim.net) has left #pypy Jan 14 12:57:18 <mwh> afternoon Jan 14 12:59:42 <pedronis> hi Jan 14 12:59:57 <arigo> afternoon Jan 14 13:08:07 <hpk> afternoon Jan 14 13:22:27 <lac-sleeps> afternoon Jan 14 13:22:32 --- lac-sleeps is now known as lac Jan 14 13:27:54 <mwh> nothing else to say, i'm afraid :) Jan 14 13:31:46 <lac> :-) Jan 14 14:05:57 <mwh> arigo: i hope people read and take notice of your python-dev interface post Jan 14 14:07:54 <arigo> i hesitated Jan 14 14:08:08 <arigo> it's a bit lost in the thread but i don't want to insist more, specially to avoid flooding python-dev again Jan 14 14:10:38 <mwh> well, i think the idea that strings represent >1 concept is illuminating Jan 14 14:14:32 --> adim (~adim(a)logilab.net2.nerim.net) has joined #pypy Jan 14 14:59:59 <lac> I am going to work now. With a bottle of champaigne. Jan 14 15:00:04 <mwh> hehe Jan 14 15:00:05 --- lac is now known as lac-work Jan 14 15:12:19 <hpk> arigo, mwh: indeed i find "global adapter registries" scary Jan 14 15:14:35 <hpk> another serious concern which i haven't seen mentioned is debugging, btw Jan 14 15:15:16 <hpk> for example, how will a traceback involving adapations on arguments look like? Jan 14 15:21:29 <arigo> if there is an exception while adapting? Jan 14 15:22:17 <arigo> you'll probably see the "def f(x: y)" line in the traceback, which is a good hint that it's during adaptation Jan 14 15:34:57 <-- idnar has quit ("kbye") Jan 14 16:07:41 <hpk> i am pretty sure that it will make things harder to debug, anyway Jan 14 16:15:37 <-- dlk has quit (Read error: 104 (Connection reset by peer)) Jan 14 16:23:31 <arigo> the global registry is dangerous Jan 14 16:23:49 <arigo> __conform__() and __adapt__() should be reasonable, though Jan 14 16:24:21 <hpk> as methods on objects? (i didn't follow python-dev closely on all this) Jan 14 16:24:55 <arigo> I think the idea is that the built-in adapt() function just calls __conform__() and __adapt__() Jan 14 16:25:13 <arigo> a bit like "a+b" calls __add__() and __radd__(), btw Jan 14 16:25:57 <pedronis> arigo: unrelated, I'm thinking what to do about co_consts Jan 14 16:26:33 <pedronis> I rediscovered the fact that our code objects are supposed to be space indipendent Jan 14 16:26:48 <pedronis> but that means they must store co_consts unwrapped Jan 14 16:27:00 <arigo> yes Jan 14 16:27:31 <pedronis> but that exactly a mixed type tuple Jan 14 16:27:49 <arigo> oups Jan 14 16:28:11 <pedronis> so we would like co_consts_w Jan 14 16:28:34 <pedronis> but the the code objects are really designed to be space indipendent Jan 14 16:29:15 <hpk> although i am not sure this design decision is neccessary Jan 14 16:30:15 <hpk> what does it buy us? Jan 14 16:30:16 <pedronis> probably not, but is is quite pervasive Jan 14 16:30:28 <hpk> yes, and Armin had good arguments Jan 14 16:31:24 <pedronis> because the gateways are also space independent Jan 14 16:31:47 <arigo> it's all a bit messy Jan 14 16:32:26 <pedronis> I have converted most of interpreter/* to use just int_w,str_w and unwrap_builtin Jan 14 16:32:54 <arigo> there are really two approaches that exist in practice: Jan 14 16:32:59 <pedronis> althoug unwrap_builtin could probably have a better name Jan 14 16:33:05 <arigo> in CPython we have real objects in co_consts Jan 14 16:33:30 <arigo> in many other VMs the literals are stored in some bytecodeish compact format Jan 14 16:33:46 <arigo> and expanded into real objects by the equivalent of LOAD_CONST Jan 14 16:34:05 <arigo> e.g. LOAD_STRING n, where n somehow points to raw string data Jan 14 16:34:32 <arigo> so far PyPy does the latter, with LOAD_CONST n meaning wrap the "raw" co_consts[n] Jan 14 16:35:22 <arigo> a the nice property is that we don't have to preprocess code objects: the interpreter could theoretically just run off mmaped .pyc files Jan 14 16:36:20 <pedronis> ah but then our co_const would be in marshal format Jan 14 16:37:11 <arigo> yes, note that the marhsal format is similar to whatever format we'd have to invent to represent a mixed type tuple anyway Jan 14 16:38:09 <pedronis> well, for now I keep the unwrap and unwrap Jan 14 16:38:33 <arigo> in theory, we could tell the translator that the Code class and its attributes are implemented as a "view" over read-only packed data in marshal format Jan 14 16:38:45 <pedronis> and *if* we remove direct tuple list wrapping/unwrapping Jan 14 16:38:52 <arigo> and get a version of the interpreter that really handles only marshal data, never "real" Code instances Jan 14 16:39:18 <pedronis> yes Jan 14 16:39:58 <hpk> probably Jan 14 16:40:12 <arigo> well it's messy anyway, because of long or complex literals that are maybe not R-Python types Jan 14 16:40:38 <arigo> I mean, literals of type long or complex Jan 14 16:41:33 <pedronis> also true Jan 14 16:41:50 <pedronis> well with marshal approach Jan 14 16:42:20 <pedronis> that's not an issue Jan 14 16:42:37 <pedronis> but those wrap and unwrap need to be spelled in a special way Jan 14 16:43:13 <arigo> hum, it looks like a marshaled object is an object is the MarshalObjSpace :-) Jan 14 16:43:35 <pedronis> well that's still a special way Jan 14 16:43:40 <arigo> then those wrap and unwrap become sending objects across spaces Jan 14 16:43:42 <pedronis> because it's a different space Jan 14 16:43:49 <arigo> precisely. Jan 14 16:43:55 <mwh> arigo: i suspect you might be getting ahead of yourself here? Jan 14 16:44:02 <pedronis> :) Jan 14 16:44:13 <hpk> oh, he is probably thinking of making use of adapt() :-) Jan 14 16:44:26 <hpk> (not really) Jan 14 16:44:33 <pedronis> for now I will leave the wrap and unwrap Jan 14 16:44:36 <arigo> hpk: not that I am fully aware of :-) Jan 14 16:44:39 <mwh> adapt(1, ApplicationLevel) ? Jan 14 16:44:40 <pedronis> anyway I have not disabled Jan 14 16:44:52 <mwh> adapt(1, IApplicationLevelThingie), rather Jan 14 16:44:56 <pedronis> the wrap/unwrap functionality for tuples or lists Jan 14 16:45:00 <pedronis> if I do that Jan 14 16:45:01 <mwh> let's use a decorator too! Jan 14 16:45:08 <arigo> pedronis: ok Jan 14 16:45:15 <pedronis> I will use some special names for those cases Jan 14 16:45:18 <arigo> mwh: :-) Jan 14 16:47:08 <arigo> well it's all fuzzy, e.g. what should a built-in compiler produce? Code objects with what in the co_consts? It looks like it shouldn't depend on a space... Jan 14 16:48:01 <mwh> well, indeed Jan 14 16:49:28 <pedronis> yes, but I don't see a problem in finding a suitable space independent format for co_consts Jan 14 16:49:51 <hpk> the fact that we want to have a space-independent repr of a code object does not imply that PyPy's internal code objects could not be space-dependent Jan 14 16:50:15 <hpk> (sorry for the negation-complexity here :^) Jan 14 16:52:54 <arigo> ok Jan 14 16:53:25 <arigo> that's quite possible after all... Jan 14 16:54:15 <hpk> also it seems that apart from LOAD_CONST we hardly have "generic" wraps in interpreter/ Jan 14 16:54:43 <pedronis> yup Jan 14 16:54:44 <mwh> most of them are wraps of obvious strings or integers, i think Jan 14 16:55:01 <hpk> yes, mostly wraps of messages, filenames, varnames Jan 14 16:55:35 <pedronis> as I said the generic unwrap is also the one of co_consts Jan 14 16:55:42 <pedronis> s/the/the only Jan 14 16:56:43 <arigo> there must be a generic wrap for default args of gateways Jan 14 16:57:53 <pedronis> yes, I said unwrap Jan 14 16:58:22 <hpk> app2interp.getdefaults() does the generic wrap, right Jan 14 16:58:28 <pedronis> it's also marked as NOT_RPYTHON Jan 14 16:58:33 <hpk> yes :-) Jan 14 16:58:36 <pedronis> and happens at bootstrap Jan 14 16:58:47 <arigo> ok ok :-) Jan 14 17:00:56 <arigo> if we want to allow things like new.code(...., co_consts=(AnyThing(),), ...) Jan 14 17:01:03 <arigo> to be done by the user Jan 14 17:01:13 <arigo> then we have no choice but keep the object wrapped Jan 14 17:01:37 <pedronis> true Jan 14 17:03:16 <hpk> the same regarding func_defaults Jan 14 17:03:25 <hpk> it works in CPython (to override func_defaults) Jan 14 17:03:28 <hpk> but doesn't in PyPy apparently Jan 14 17:04:15 <arigo> no? Jan 14 17:04:39 <arigo> you can say def f(x=AnyThing()) Jan 14 17:04:48 <arigo> so you can create func_defaults with anything at all Jan 14 17:05:01 <hpk> yes, maybe the current limitation is just shallow Jan 14 17:05:02 <arigo> (even though we might not support assigning to .func_defaults) Jan 14 17:05:19 <pedronis> Functions are space depedent Jan 14 17:05:21 <arigo> that's quite different, func_defaults are not a syntactic property Jan 14 17:05:31 <pedronis> in fact they store defaults as defs_w Jan 14 17:06:07 <pedronis> it's code objects and gateways that are space independent Jan 14 17:10:54 <pedronis> looking further maybe it's not too hard to make code objects space depedent if we want to Jan 14 17:11:42 <pedronis> it seems gateways just need to become even more lazy Jan 14 17:12:26 <arigo> could BuiltinCode remain space-independent, and PyCode be space-dependent? Jan 14 17:13:53 <pedronis> I think so Jan 14 17:14:08 <hpk> it should be possible Jan 14 17:15:00 <pedronis> BuiltinCode is constructing a PyCode just to be able to use .signature Jan 14 17:15:15 <pedronis> but can be done in some other way Jan 14 17:15:35 <hpk> i guess we should untangle the cases more Jan 14 17:15:55 <hpk> maybe we tried too hard to reuse code for BuiltinCode/PyCode cases Jan 14 17:17:37 <pedronis> the question is, do we want PyCode to be space depedent, it probably has to because of what we found Jan 14 17:18:19 <arigo> I guess so Jan 14 17:18:43 <pedronis> I can do the change Jan 14 17:19:16 <pedronis> on the branch? Jan 14 17:19:31 <hpk> makes sense i think Jan 14 17:20:27 <pedronis> I'm going first to check in what I did so far Jan 14 17:23:48 <arigo> ok :-)

2 1

Re: [pypy-dev] new repolayout proposal
by Laura Creighton Jan. 15, 2005

Jan. 15, 2005

In a message of Sat, 15 Jan 2005 16:09:11 +0100, holger krekel writes: <snip> >> I think dist/pypy/documentation should be dist/pypy/doc also, for brevi >ty. > >maybe. Btw, this is not intended to be checked out directly >anyway (see the proposal for details) although you can do it >if you like it. I was more worried about really-long-filenames. Perhaps this doesn't matter as much. Laura > >cheers, > > holger >_______________________________________________ >pypy-dev(a)codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev

1 0

new branch src-typedunwrap
by Samuele Pedroni Jan. 14, 2005

Jan. 14, 2005

After discussing with Armin and Holger, I have created a new branch to explore typed unwrapping. This was touched and discussed also in the past, we would like to move away from the current generic unwrap to typed versions thereof, also because is a reasonable way to express type information about parameters that enters functions (for example builtin function implementations) as just generic object and then get unwrapped. As first step we will introduce str_w and int_w space operations, that are type specific unwraps for string and integers. Removing generic unwrapping of lists and tuples (probably up to their usage in tests) makes also sense, because in mixed type cases they are problematic as RPython operations. After this we discussed about supplying the gateways with specifier so that can also carry out unwrapping and argument type checking int the spirit of CPython ParseTuple* operations. For that we will likely need typed unwrapping for more types and to think about the issues of unwrapping vs. going first through the various __int__, __str__ conversion special methods. Samuele.

1 0

genrpy is ready so far.
by Christian Tismer Jan. 11, 2005

Jan. 11, 2005

Hi Armin, all, I've put quite some work into genrpy.py in the last few weeks. It seems to produce usefulcode, although it could of course be nicer with some more effort. The speed effect appears to be somewhere around 40% over interpreted appspace code, not really disappointing, but also not really overwhelming. The real effect of such translation lies probably in opening things to further optimization in a later code generation step. The code works fine with _formatting.py, md5.py and strutil.py. These all appear to obey RPython restrictions, as probably many others. There are some enhancements possible: Right now, I'm using the flow space as it is, but I do not try to create specialized functions for constant arguments. Flow space provides some way to do this, but translator doesn't allow it. I'm thinking to play with this. It would make much sense in the md5 module, where many small functions with constant arguments could be curryfied. In effect, with some more support, the flowspace could identify more constants than it does now. The way I'm creating the function interfaces is working, but less than optimum. I stupidly followed the pattern that Armin used for C code generation. Later on I figured out that I could create functions with names and default arguments directly. Armin, I'm referring to the distinction of f_<funcname> and fastf_<funcname>. Instead of using the pattern def f_<funcname>(space, *args_w) and later plumbing the defaults in, I could have done it in the function header, directly. I will enhance this later, provided that we want to use this module at all. How do we want to integrate this stuff? First I think it needs a different name. Then, there is the question whether there should be one huge module generated from the union of all app-space implementations, or if there should be onefile for every app-spacemodule part? I thought of acontainerlike pypy.appspace.generated where all stuff could be accumulated. Do we want togenerate stuff on demand, based upon modification time of modules, or better do it by hand? Another questio is if it is so good to loose all the local names early,or if I should try to regenerate local names wherever possible? Another thing I was considering is not to create all these goto blocks, but to turn them into simple functions. This would give us massive recursion, but if we add a tail recursion feature to pypy, this would show up quite nicely. It would make the source shorter and would really allow to use given local names, because each code block has its own closure, then. I have done a lot of local tests. The test code is still sitting in the module and should go elsewhere. I did not yet tryto integrate it into the app space calls of stdobjspace. This is easy to do,but I need consensus how wewant this to happen. Please review. You can select a few test functions by changing line 1084. For the current main function, you need to create an importable appspace/generated folder. You also will needto change the temp output file for your needs, at the moment this is "d:/tmp/look.py" :-) I will supply a real entrypoint and a cleaner interface when I have some feedback. all the best -- 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/

4 5

Re: [pypy-dev] Running Python in reverse
by Alexander Schliep Jan. 11, 2005

Jan. 11, 2005

On Fri, 7 Jan 2005 hpk(a)trillke.net (holger krekel) wrote: > ... > Yes, i see the problem. At EuroPython 2004 there also was Michael Salib > who also presented his wish to have a "time warp" debugger that allows > to arbitrarily move within execution time of your program and see all > the state. And IIRC, we have been discussing this between PyPy developers This sounds like the same general idea. > ... > Rightfully so. I wouldn't call it "run backwards" though but to jump > arbitrarily in execution and object states. The visualization would look like running backwards; technically you are correct. > Yes, although for debugging in general there is the problem of > "side effects" like dealing with files & sockets, databases etc.pp. Fortunately, this is not a problem for me. > Well, the question is if we could tackle the "History Space" (working > title) at some sprint and you would attend and we would together incorporate It will be really difficult for me to attend sprints, I already travel way too much. I'd be glad though to start to code towards extending Gato. Does it make it a lot of sense to run the whole tkinter app in pypy, or would we just have an embedded pypy-interpreter for the algorithm? Do you have suggestions how to setup the whole thing? Right now I just execfile the algorithm under debugger control. The algorihms calls the visualisation commands as side effects when doing interesting stuff (put a vertex on a queue). The debugger calls the idle_task etc. to keep the GUI alive, whenever something happens. > the functionality into your application for the fun of it. I imagine > a "time slider" that you can arbitrarily move forward and backward > ... Basically like VCR controls. I'd add "run backwards" or so. Best, Alexander

2 1

Common Lisp translation broken
by Adrien Di Mascio Jan. 11, 2005

Jan. 11, 2005

Hi all, I'm just beginning to play around with PyPy, and I got a traceback when trying to translate Python code to CL code. Here's the traceback : ######### >>> t = Translator(test.if_then_else) >>> t.cl() Traceback (most recent call last): File "<stdin>", line 1, in ? File "translator.py", line 165, in cl return self.generatecode(GenCL, input_arg_types, func) File "translator.py", line 184, in generatecode self.entrypoint, ann)] File "translator.py", line 205, in generatecode1 return g.emitcode(public) TypeError: emitcode() takes exactly 1 argument (2 given) >>> ######### A quick and dirty (partial) fix could be to add a "public=True" argument to the GenCL.emitcode() method, but I'm just a PyPy newbie for now, I don't really know how everything works and I'm not a Lisp Expert, so ... I just raise up the error here :-) Cheers, Adrien.

2 1

Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace
by Christian Tismer Jan. 11, 2005

Jan. 11, 2005

ale(a)codespeak.net wrote: > Author: ale > Date: Tue Jan 11 08:58:40 2005 > New Revision: 8201 > > Added: > pypy/trunk/src/pypy/appspace/struct.py > Log: > Added the start of a struct module. It is not quite finished yet. > > The structure of the code is basically as in structmodule.c. > But some python goodies has been used - if that makes the > module less RPython I don't know. No, I think this is absolutely fine. I could translate it to RPython, and it works. See attached module. (The implementation will improve, but this is at least a proof that you wrote RPython) 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 3

Re: [pypy-svn] r8201 - pypy/trunk/src/pypy/appspace
by Christian Tismer Jan. 11, 2005

Jan. 11, 2005

ale(a)codespeak.net wrote: > Author: ale > Date: Tue Jan 11 08:58:40 2005 > New Revision: 8201 > > Added: > pypy/trunk/src/pypy/appspace/struct.py > Log: > Added the start of a struct module. It is not quite finished yet. > > The structure of the code is basically as in structmodule.c. > But some python goodies has been used - if that makes the > module less RPython I don't know. No, I think this is absolutely fine. I could translate it to RPython, and it works. See attached module. (The implementation will improve, but this is at least a proof that you wrote RPython) 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/

1 0

flow space and UnboundLocalError! Eek!
by Christian Tismer Jan. 10, 2005

Jan. 10, 2005

Hi friends, I was playing with generated RPy functions, and just for fun, I ran my generator over its output. That should give an RPython interpreter for the whole pypy implementation. Not too useful, but nice to look at, better than disassembly :-) Here *the problem*: When I run flow space over my attached generated function, it crashes with an UnboundLocalError: w_26. This *is not* an error, because all the paths can only be walked in the order enforced by the big goto loop. But the flow space seems to step into a problem here. Well, flow space tries every branch, and most probably without looking at the data. Question: Is it possible to change the flow space to just ignore unbound variables? Or is this kind of code to be defined as NOT_RPYTHON ? The latter would be very bad, since I'm trying to create RPython, so it should be. An ugly solution would be to initialize all variables to some default. Please let me know ASAP -- 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/ #!/bin/env python # -*- coding: LATIN-1 -*- ##SECTION## ## filename 'genrpy.py' ## function 'ff' ## firstlineno 1062 ##SECTION## # global declarations # global object gcls_SystemError # global object gi_42 def f_ff(space, *args_w): kwlist = ["a", "b", "c"] w_1 = space.newtuple(list(args_w[3:])) _args_w = args_w[:3] defaults_w = (gi_3,) # XXX should parse args here, but no keyword support in gateway funcname = "ff" w_2, w_4, w_6 = PyArg_ParseMini(space, funcname, 2, 3, _args_w, defaults_w) return fastf_ff(space, w_2, w_4, w_6, w_1) def fastf_ff(space, w_2, w_4, w_6, w_1): goto = 1 # startblock while True: if goto == 1: v0 = space.is_true(w_1) if v0 == True: w_3, w_5, w_7, w_8 = w_2, w_4, w_6, w_1 goto = 3 else: assert v0 == False w_9, w_10, w_11, w_12 = w_2, w_4, w_6, w_1 goto = 2 if goto == 2: w_13 = space.add(w_9, w_10) v14 = space.is_true(w_12) if v14 == True: (w_15, w_16, w_17, w_18, w_19, w_20) = (w_9, w_10, w_11, w_12, w_13, v14) goto = 5 else: assert v14 == False w_21 = w_13 goto = 6 if goto == 3: v22 = space.is_true(w_8) if v22 == True: w_23, w_24, w_25, w_26, w_27 = w_3, w_5, w_7, w_8, v22 goto = 4 else: assert v22 == False w_28, w_29 = gcls_SystemError, gi_42 goto = 7 if goto == 4: w_30 = space.len(w_26) w_31 = space.newtuple([w_30, w_25]) w_21 = w_31 goto = 6 if goto == 5: w_32 = space.len(w_18) w_33 = space.newtuple([w_32, w_17]) w_21 = w_33 goto = 6 if goto == 6: return w_21 if goto == 7: raise OperationError(w_28, w_29) ##SECTION## ## filename 'genrpy.py' ## function '<lambda>' ## firstlineno 1142 ##SECTION## # global declarations # global object gfunc__lambda_ # global object gfunc_ff # global object gi_2 # global object gi_3 # global object gi_5 def f__lambda_(space, *args_w): kwlist = [] _args_w = args_w defaults_w = () # XXX should parse args here, but no keyword support in gateway funcname = "<lambda>" PyArg_ParseMini(space, funcname, 0, 0, _args_w, defaults_w) return fastf__lambda_(space, ) def fastf__lambda_(space, ): goto = 1 # startblock while True: if goto == 1: _tup = space.newtuple([gi_2, gi_3, gi_5]) w_0 = space.call(gfunc_ff, _tup) w_1 = w_0 goto = 2 if goto == 2: return w_1 ##SECTION## #************************************************************* def init_lambda__1(space): """NOT_RPYTHON""" class m: pass # fake module m.__dict__ = globals() from pypy.interpreter.gateway import interp2app m.gfunc__lambda_ = space.wrap(interp2app(f__lambda_)) m.gfunc_ff = space.wrap(interp2app(f_ff)) m.gi_2 = space.newint(2) m.gi_3 = space.newint(3) m.gi_5 = space.newint(5) from pypy.translator.genrpy import PyArg_ParseMini m.PyArg_ParseMini = PyArg_ParseMini from pypy.interpreter.error import OperationError m.OperationError = OperationError m.gcls_SystemError = space.wrap(SystemError) m.gi_42 = space.newint(42) # entry point: _lambda_, gfunc__lambda_) if __name__ == "__main__": from pypy.objspace.std import StdObjSpace space = StdObjSpace() init_lambda__1(space) print space.unwrap(space.call( gfunc__lambda_, space.newtuple([])))

1 0