Mailman 3 February 2003 - pypy-dev

Re: [pypy-dev] Release something?
by Laura Creighton 27 Feb '03

27 Feb '03

In a message of Thu, 27 Feb 2003 15:35:23 +0100, Armin Rigo writes: >Hello everybody, > >One more e-mail to remind you that one of the goal of the sprint was to >release something at the end of the week. > >Did you realize that the interpreter (with the trivial object space) already >works nicely enough to run the following: > ># python interactive.py >Python 2.2.2 (#2, Nov 14 2002, 17:24:26) >[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.68mdk)] in pypy >PyPyConsole / TrivialObjSpace >>>> import dis >>>> dis.dis(dis.dis) > >I particularly enjoy the slooooooowness of the resulting disassembly dump > :-) > >Do you think, just for the fun, that this would be worth a "release"? It >would show the "outside world" that we actually got something "serious" >done. Of course "serious" needs quote, given the speed of the result, >but at this point everybody should know that it was planned, and that >we are dreaming about top speeds involving some rather obscure translations >(probably invoking strange beasts from the theory of Computer Science). > > >A bientôt, > >Armin. >_______________________________________________ >pypy-dev(a)codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev I think that this is a great plan. Plus we didn't promise to be fast, only elegant -(well, simple and flexible). If we can get the idea of object spaces and the idea of multiple dispatches across, then that should be good enough for, say, the article(s) that Cameron Laird wants to write about us. It will make a nice talk for Python conferences as well. Laura

1 0

[issue14] issues go to pypy-dev
by holger krekel 27 Feb '03

27 Feb '03

New submission from holger krekel <hpk(a)trillke.net>: As requested on the sprint pypy-dev now gets notification of "new issues". With some new "detector" code for roundup i configured the pypy-issue tracker so that new issues will get sent to the pypy-dev list. The list itself is not "nosy" and everyone has to decide to "nosy in" on specific issues. Don't reply to the new post but follow the web-link in the posting. NEVER send mail to both the issue-tracker and the mailing list. This might currently lead to the implosion of the universe, who knows :-) I'll try to improve the way that mailing lists and issue-trackers interact and will communicate with the roundup developers about this. ---------- messages: 25 nosy: hpk priority: feature status: testing title: issues go to pypy-dev __________________________________________________ PyPython issue tracker <pypy-issues(a)codespeak.net> http://codespeak.net/issues/pypy/issue14 __________________________________________________

1 0

[issue13] RecentChanges is broken in the wiki
by holger krekel 27 Feb '03

27 Feb '03

New submission from holger krekel <hpk(a)trillke.net>: Rocco reported that the RecentChanges page is currently broken. it only shows the history of the past few days. ---------- assignedto: hpk messages: 24 nosy: hpk, rocco priority: bug status: unread title: RecentChanges is broken in the wiki topic: wiki __________________________________________________ PyPython issue tracker <pypy-issues(a)codespeak.net> http://codespeak.net/issues/pypy/issue13 __________________________________________________

1 0

Wiki Change Tracking
by roccomoretti＠netscape.net 27 Feb '03

27 Feb '03

I think there might be an issue with keeping track of Wiki page changes via RecentChanges (http://codespeak.net/moin/pypy/moin.cgi/RecentChanges). When I have gone in there recently, I've only seen the changes for the current day. There is no history past that. I suspect it may be an error, as in the past RecentChanges has given me a few weeks worth of changes. Is there some cron job or interaction with the subversion server which is causing changes older than 24 hours to be dropped? -Rocco __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

2 1

Re: Base Object library (was: stdobjspace status)
by Christian Tismer 26 Feb '03

26 Feb '03

Stephan Diehl wrote: ... > That's actually the place, where I'd really do it different to the CPython > implementation. I'd factor out the r_longs to a library (as discussed several > times in this thread) and would indeed write: > ----------------------------------------------------------------------------------------- > import basiclong # <== or something similar > def long_long_sub(space, w_long1, w_long2): > x = w_long1.longval > y = w_long2.longval > try: > z = basiclong.sub(x , y) # > except Error,e: > raise OperationError(Error, e) > return W_LongObject(z) > --------------------------------------------------------------------------------------- I don't remember that this was discussed, or I misunderstood all the time. What library should it be which provides the longs? Maybe this works for longs, but what is then up with say, dictionaries? > As far as I'm concerned, the implementation of the basic/restricted types and > the implementation of the W_XXXObjects should be clearly separated. What do you mean? I can't see where I mixed them up. The ones are the building blocks of the others. ... > Anyway, we are probably not too far apart > in our opinion about this topic :-) Well, just this one: I don't understand the library idea. How do we get to a minimal, self-contained Python if we don't implement everything ourselves? ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 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

codespeak downtime thursday 1pm-3pm (gmt+1)
by holger krekel 26 Feb '03

26 Feb '03

hello, please expect a downtime from 1pm to 3pm (gmt+1) tommorow. the server hosting the pypy project will move to a faster network location thanks to the nice people from Helios Software GmbH in Hannover. We will try to change the DNS addresses before moving the computer so that all the caches have time to adapt. Note, though, that Mozilla apparently *never* times out DNS-address resolutions. holger

1 0

Re: Base Object library (was: stdobjspace status)
by Christian Tismer 26 Feb '03

26 Feb '03

Stephan Diehl wrote: ... > At the moment, the constructor of W_IntObject looks like: > > def __init__(w_self, intval): > w_self.intval = r_int(intval) > > At the end, this should look like: > > def __init__(w_self, rintval): > w_self.intval = rintval > > where rintval is already the restricted intval. > Am I right here? May be, not sure, I only want to make sure that self.intval is an r_int. >>So the meaning of the primitive types is always >>to provide a way down to the really implementable >>layers, regardless in which level of world you >>just happen to be. It even makes sense if you run >>PyPy on PyPy which is run on CPython, etc. > > > I take it then that in the end, we get something like the following: > > ######################## > # PyPy Interpreter # > ######################## > # StdObjSpace # > ######################## > # basic/primitive Types # > ######################## > > These basic types have nothing to do at all with the StdObjSpace and are > implemented at first in Python (for convinience) and later probably in C or > Assembler. Yes, but don't get me wrong: I will not rewrite them in C, but a code generator will do that. SO, actually, most of the work is done after writing it in Python. > The ObjSpace just has an interface to these basic types. > So, in the floatobject module for example, I'd rather define the > float_float_add function like this (I left out the errorchecking): > > ------------------------------------------------------------------------- > import basicfloat > > def float_float_add(space, w_float1, w_float2): > x = w_float1.floatval > y = w_float2.floatval > z = basicfloat.add(x,y) > > return W_FloatObject(z) > ------------------------------------------------------------------------- > > instead of > ------------------------------------------------------------------------- > def float_float_add(space, w_float1, w_float2): > x = w_float1.floatval > y = w_float2.floatval > z = x + y > > return W_FloatObject(z) > -------------------------------------------------------------------------- Why that? You can do that, but I don't see the point. This is why I defined r_int as derived from true ints: I want to keep the simple notation of "+". Why should I use a special method? If there is a special method, then it can be found in the class definition of r_int. > The most important thing seems to me to define content and interface of the > basic types. > I'd suggest one module "basictypes" that defines the number and string > definitions and operations. Apart from that (or together?) we'll need a > general bitfield (bytefield?) and then, on top of that, the list and > dictionary types. Yes. That is what I hope to do very soon. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 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: Base Object library (was: stdobjspace status)
by Christian Tismer 26 Feb '03

26 Feb '03

Stephan Diehl wrote: ... > This boils down to: > 1. define the most basic building blocks like bit fields + corresponding > memory management. > 2. define numbers, lists, strings, dicts, etc. on top of 1. This is actually my plan. It just takes more time. > Please note that these objects have nothing to do with the objspace we are > defining, but are used as the building blocks and are never exposed outside > the objspace. > > Does this make sense? Yes, makes sense. For the time being, my r_int objects for instance are derived from true integers, but they are *meant* to denote simple, internal integers. Their behavior is modelled this way, and a compiler is supposed to recognize r_int and generate the primitive code instead of object calls. In that sense, I'm already using primitive types. Well, the nice thing is, that these primitive types can be used both in objectspace and outside of it. Sure, they have to be not intermixed, and the meaning of r_int in objectspace is clearly that we want these objects to be replaced by primitives. Nevertheless, r_int can be imported from application space, becoming an application object, now. This is another level, "other world", but still the r_int objects make sense, since a compiler on application space (like Psyco) can now drive concluions of the usage of r_int, too. So the meaning of the primitive types is always to provide a way down to the really implementable layers, regardless in which level of world you just happen to be. It even makes sense if you run PyPy on PyPy which is run on CPython, etc. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 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-dev] svn and issue tracking doesn't work
by holger krekel 26 Feb '03

26 Feb '03

[Stephan Diehl Wed, Feb 26, 2003 at 12:34:22PM +0100] > On Wednesday 26 February 2003 12:09, you wrote: > > [Stephan Diehl Wed, Feb 26, 2003 at 11:28:30AM +0100] > > > > > codespeak.net doesn't work as expected. > > > codespeak.net:8080/svn doesn't respond at all. > > > With the issue tracking, I can log in but not create a new issue (or have > > > a look at the existing ones). > > > > Well, issue tracking works for me. what exactly > > doesn't work for you? Are you using exactly > > > > http://codespeak.net/issues/pypy/ > > > > ? I am using Konqueror and Mozilla which both work. > > I just realized that Mozilla works, but not Opera 6.11 (on Linux) > > With Opera (just in case you want to chase this), if I go for example to > http://codespeak.net/issues/issue8 this url is wrong. when i click there i get http://codespeak.net/issues/pypy/issue4 which works. > Very strange. indeed :-) holger

4 6

svn and issue tracking doesn't work
by Stephan Diehl 26 Feb '03

26 Feb '03

codespeak.net doesn't work as expected. codespeak.net:8080/svn doesn't respond at all. With the issue tracking, I can log in but not create a new issue (or have a look at the existing ones). Cheers Stephan

3 3