Mailman 3 August 2007 - pypy-dev

Re: [pypy-dev] How's the JIT coming along?
by Gary Robinson Aug. 22, 2007

Aug. 22, 2007

> If i might ask - what are the use cases you are thinking about when > talking about the JIT > (and/or the JIT generator?). Numerical computing. I have a lot of floating point arithmetic. I was also going to mention the function calling overhead that I see was already discussed (yesterday) in this thread! -- Gary Robinson CTO Emergent Music, LLC grobinson(a)goombah.com 207-942-3463 Company: http://www.goombah.com Blog: http://www.garyrobinson.net

3 3

How's the JIT coming along?
by Gary Robinson Aug. 22, 2007

Aug. 22, 2007

The docs for PyPy 1.0 it say: > A foreword of warning about the JIT of PyPy as of March 2007: single > functions doing integer arithmetic get great speed-ups; about > anything else will be a bit slower with the JIT than without. We are > working on this - you can even expect quick progress, because it is > mostly a matter of adding a few careful hints in the source code of > the Python interpreter of PyPy. Given the mention of the possibility of "quick progress", I'm … [View More]

6 9

Javascript Frontend (and mybe some unrelated future plans)
by Leonardo Santagada Aug. 19, 2007

Aug. 19, 2007

I've been on a cave for some time, but I want to get back to work more on pypy but I don't know what to do with the javascript interpreter. While I was working with it it was getting better but almost all the architecture work i've done alone and I'm not happy with the results. The code looks kinda ugly and I don't really know how to get it into a good shape. Maybe I need someone to take a look at it. Also there is some stuff that I don't know what to do about like automatic … [View More]

1 0

Re: [pypy-dev] scheme interpreter [status report]
by Laura Creighton Aug. 18, 2007

Aug. 18, 2007

>> What's next? >> I will probably mysteriously disappear and became grave-digger or >> hermit. Never touch computer again and live happily ever after ;-). This sort of peace is good for 2 weeks, a month, even a year in severe burn-out cases. UNless you plan on being struck by lightning on your vacation in the hermitage or graveyard, I would expect the technical world to grab its claw around you once again. Know that you are welcome here whenever this happens. :-) Laura

1 0

Re: [pypy-dev] PyPy work plan
by Laura Creighton Aug. 18, 2007

Aug. 18, 2007

Hi Simon. I never like to quote somebody's email without informing them. I am about to use ICCARUS (why 2 Cs) as an example of what I am looking for. The rest is the middle of a discusison that you are not expected to understand. Thank you for ICCARUS. -- Laura In a message of Sat, 18 Aug 2007 13:26:55 +0200, Maciek Fijalkowski writes: > >As you probably have observed already, for the last few months pypy >is slowly approaching "being usable" state instead of "having more >… [View More]ultra-cool >features", as we've got enough of them to be willing to use them. >As we're moving towards maintaining pypy as an open source project I woul >d >suggest to look around parts of pypy and have list >of people who are willing to maintain certain parts. Maintain not in a se >nse >of developing those, but rather accepting/rejecting patches, keeping it u >p >to date with other parts, etc. I would also suggest >to move parts with no obvious maintainer somewhere else in svn >(branch? tag?) not to confuse people who checkout whole svn repository >with parts never used by anyone. This option would make it easier to: > >* have people entering project, since it would be obvious who to > contact for different parts. > >* maintain whole codebase, since some cleanup changes are pervasive > enough to break different parts. > >* this would also hopefully reduce whole code size. > >I've also checked in pypy parts (more or less) into >http://codespeak.net/svn/pypy/dist/pypy/doc/maintainers.txt >feel free to add yourself wherever you like and to modify this list as we >ll > >What do you think? > >Cheers, >fijal As mentioned just in irc, I am unhappy with the dividing up of pypy into pieces with maintainers. That way the people who envision the small can dominate those who envision the large, and one of the strengths of this project is the sheer visionary power of some of its members. on the other hand, some tidying would be nice. and we sure as hell could be friendlier for newbies. I am now looking at code visualisation tools, and time visualisation tools. I get the idea that if we could visualise things better, we could undersgtand who knows what about what, and what else, then we would need less in the way of 'task management'. for static things I am thinking of: http://simile.mit.edu/timeline/ or everything at the top level simile.mit.edu domain. But then yesterday I read this on the pygame mailing list. ..... From: "Simon Wittber" <simonwittber(a)gmail.com> To: pygame-users(a)seul.org Subject: [pygame] 3D Social Network Visualisation A few evening ago we demonstrated ICCARUS at a web party. It is a piece of software which provides a visualisation of social networks in three dimensions :-) It uses pygame and a Pyrexed OpenGL lib called GFX. You can see screencast here: http://scouta.com/faves/8raO17jT8Y3/ and a vid of the presentation here: http://blog.viddler.com/cdevroe/webjam-iccarus/ Thanks to python and pygame, this project was conceived and implemented over 3 days. ...... I thought this was way cool. Especially the 3 days part. I want our code base to work like this. Who knows what? stuff that everybody knows, stuff that carl freidrich and armin and maciek and samuele know, stuff that nobody knows but samuele, and even -- 'stuff that nobody knows' somebody did at one time but we all have forgotten by now. This is a half-baked proposal for code base management, normally I would not mention this at all, but some of us are getting grumpy, and I thought that other ideas, however weird might be welcome. Laura [View Less]

1 0

PyPy work plan
by Maciek Fijalkowski Aug. 18, 2007

Aug. 18, 2007

As you probably have observed already, for the last few months pypy is slowly approaching "being usable" state instead of "having more ultra-cool features", as we've got enough of them to be willing to use them. As we're moving towards maintaining pypy as an open source project I would suggest to look around parts of pypy and have list of people who are willing to maintain certain parts. Maintain not in a sense of developing those, but rather accepting/rejecting patches, keeping it up to date … [View More]

2 1

scheme interpreter [status report]
by Jakub Gustak Aug. 17, 2007

Aug. 17, 2007

Hello. Scheme interpreter is starting look like its going to do some serious stuff in the near future, or maybe I am just too enthusiastic about it. What we have now: - We can execute simple expressions like: (+ 1 2 1.3 -2) Nested ones also works. - (define <var> <value>) works with a given context, so: (define var 2) (+ var 40) => 42 - Conditional (if <cond> <then> <else>) seem to work fine, <else> is not arbitrary. pypy/lang/scheme/test/… [View More]

4 10

Re: [pypy-dev] [pypy-svn] r45656 - in pypy/branch/pypy-more-rtti-inprogress: . module/posix rlib rpython rpython/lltypesystem rpython/lltypesystem/module rpython/module rpython/module/test rpython/ootypesystem/module rpython/test translator translator/c translator/c/src translator/c/test translator/sandbox translator/sandbox/test
by Maciek Fijalkowski Aug. 14, 2007

Aug. 14, 2007

arigo(a)codespeak.net wrote: > For backup purposes, in-progress: convert more of the os module to rtti > and try to get rid of the rllib.ros module by making the native > interfaces RPythonic. This looks quite good in my opinion - seems that > we've finally learned a reasonable way to do external functions. > > Hooray! I would suggest to be consistent in names. Either rename it to rtti or keep using rffi (I know that fonts basically suck when it comes to this :) … [View More]

2 1

Paper about accurate GC in C
by Carl Friedrich Bolz Aug. 14, 2007

Aug. 14, 2007

Hi all, the following paper describes a variant of the root-finding approach we use for the framework GC: http://citeseer.ist.psu.edu/henderson02accurate.html They use a "shadow stack" as well, but keep all their GCed locals always in it: The tradeoffs are slightly different than ours. They reach performance quite similar to that of the Boehm GC with a simple semispace collector. Chris Lattner told me that this is how LLVM lowers GC operations currently (since no backend directly … [View More]

1 0

Lua Frontend
by Jason Davies Aug. 13, 2007

Aug. 13, 2007

Hello, A couple of years ago I wrote a JIT compiler for Lua [1] for my final-year dissertation. Looking through the project-ideas page [2] I noticed there might be interest in writing Lua interpreter using PyPy. I'd be interested in doing this as a personal project. How would I go about getting started? Jason [1] http://www.lua.org/ [2] http://codespeak.net/pypy/dist/pypy/doc/project-ideas.html#write-a-new-fron…

2 1