hi, gsoc is on again... for your information the python mailing list for it is here: http://mail.python.org/mailman/listinfo/soc2010-mentors It would be good to have a wiki page(or blog post? ... err a text file available via http) of project ideas for pypy... if there are any pypy people mentoring that is. With the pygame project last year, we found having a project page for suggestions of acceptable projects helped students pick things they were interested in, and things the project would be happy with. cu
hello again. To start the gsoc ideas list off... - port jit to 64 bit (maybe too short for 3 month project, if so start on ARM after amd64?). - speed up ctypes wrapper. - GIL removal work. - python2.6/2.7/py3k features. - ctypes bindings for database adaptors (would be good for ironpython, jython, and even cpython too). - faster ctypes module. (by using jit?) - cpython bridge module. Either load pypy as cpython extension or the otherway around. To allow gradual porting. - ironclad port to pypy. To allow loading cpython C extensions. eg, ironpython can run numpy with this. - revive javascript/flex backend. - improvements to java/.net backend. - AOT compilation research - to allow compiling to iphone for example. I guess this list could also be put on a page looking for sponsors? To give sponsors something concrete they can pay a contract for. eg, 'approximately 2-3 months work(24,000 euros) to get X benefit, as well as a logo+link on our sponsors page... etc.' Anyway... those are some of the areas I can think of from past discussions. I'm sure pypy project members have a better idea of what would be good for gsoc students to work on? cu, On Tue, Mar 2, 2010 at 3:51 PM, René Dudfield <renesd@gmail.com> wrote:
hi,
gsoc is on again... for your information the python mailing list for it is here: http://mail.python.org/mailman/listinfo/soc2010-mentors
It would be good to have a wiki page(or blog post? ... err a text file available via http) of project ideas for pypy... if there are any pypy people mentoring that is. With the pygame project last year, we found having a project page for suggestions of acceptable projects helped students pick things they were interested in, and things the project would be happy with.
cu
Hey. Thanks for posting that! I think it makes sense to discuss a bit whether stuff makes or does not make sense. On Tue, Mar 2, 2010 at 11:06 AM, René Dudfield <renesd@gmail.com> wrote:
hello again.
To start the gsoc ideas list off...
- port jit to 64 bit (maybe too short for 3 month project, if so start on ARM after amd64?).
Not sure if it's too short. It's too short for core dev 3 month project, but for student it's ideal.
- speed up ctypes wrapper.
A bit hard, but also JIT-cooperation.
- GIL removal work.
Hard/researchy
- python2.6/2.7/py3k features. - ctypes bindings for database adaptors (would be good for ironpython, jython, and even cpython too).
that's not strictly pypy-related. I would like such projects to be under PSF umbrella. Also there is a question of maintainability.
- cpython bridge module. Either load pypy as cpython extension or the otherway around. To allow gradual porting. - ironclad port to pypy. To allow loading cpython C extensions. eg, ironpython can run numpy with this.
This is probably interesting, might also be a bit hard.
- revive javascript/flex backend.
please no :)
- improvements to java/.net backend.
Honestly, we had problems with maintability of new backends. Also .net is sort of done (except .net bindings).
- AOT compilation research - to allow compiling to iphone for example.
that's research, possibly interesting though.
I guess this list could also be put on a page looking for sponsors? To give sponsors something concrete they can pay a contract for. eg, 'approximately 2-3 months work(24,000 euros) to get X benefit, as well as a logo+link on our sponsors page... etc.'
Sure. Although note that so far we did not get any feedback on sponsoring blog post.
Anyway... those are some of the areas I can think of from past discussions. I'm sure pypy project members have a better idea of what would be good for gsoc students to work on?
How about investigating (again) llvm jit backend? Thanks for starting the discussion! Cheers, fijal
On Tue, Mar 2, 2010 at 7:38 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
Hey.
Anyway... those are some of the areas I can think of from past discussions. I'm sure pypy project members have a better idea of what would be good for gsoc students to work on?
How about investigating (again) llvm jit backend?
Is there a summary of what the problems were? I guess the lack of maturity of the JIT engine was one (as experienced by unladed-swallow). cheers, Benoit
On Tue, Mar 2, 2010 at 11:56 AM, Benoit Boissinot <bboissin+pypy@gmail.com> wrote:
On Tue, Mar 2, 2010 at 7:38 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
Hey.
Anyway... those are some of the areas I can think of from past discussions. I'm sure pypy project members have a better idea of what would be good for gsoc students to work on?
How about investigating (again) llvm jit backend?
Is there a summary of what the problems were? I guess the lack of maturity of the JIT engine was one (as experienced by unladed-swallow).
cheers,
Benoit
Not written. Bugs and immaturity, yes. The precise issue we run into was tail calls not working, but this one is supposed to be fixed by now. Having US team on LLVM JIT team is certainly a big advantage. I suppose next step is to try to push it and see what's next. Cheers, fijal
Hi, On Tue, Mar 02, 2010 at 12:01:23PM -0700, Maciej Fijalkowski wrote:
How about investigating (again) llvm jit backend? (...) I suppose next step is to try to push it and see what's next.
Yes, but I bet from experience that we're going to run after a few days' work into the next issue. We've already done that 3 or 4 times with llvm, so now I'm honestly a bit fed up. For comparison, gcc gives code that is a bit slower but at least it is really a solid bug-free project. A bientot, Armin.
Re-hi, On Tue, Mar 02, 2010 at 08:22:51PM +0100, Armin Rigo wrote:
Yes, but I bet from experience that we're going to run after a few days' work into the next issue. We've already done that 3 or 4 times with llvm, so now I'm honestly a bit fed up. For comparison, gcc gives code that is a bit slower but at least it is really a solid bug-free project.
Let me make this statement more precise: I mean for the non-JIT backends of PyPy, using the llvm backend of PyPy gaves results that were typically a little bit faster than using the C backend, when compiling with llvm-gcc. However, with the various generations of our JIT, using a JIT llvm backend always ran into llvm bugs. A bientot, Armin.
On Tue, Mar 2, 2010 at 8:35 PM, Armin Rigo <arigo@tunes.org> wrote:
Re-hi,
On Tue, Mar 02, 2010 at 08:22:51PM +0100, Armin Rigo wrote:
Yes, but I bet from experience that we're going to run after a few days' work into the next issue. We've already done that 3 or 4 times with llvm, so now I'm honestly a bit fed up. For comparison, gcc gives code that is a bit slower but at least it is really a solid bug-free project.
Let me make this statement more precise: I mean for the non-JIT backends of PyPy, using the llvm backend of PyPy gaves results that were typically a little bit faster than using the C backend, when compiling with llvm-gcc. However, with the various generations of our JIT, using a JIT llvm backend always ran into llvm bugs.
On the other hand, it looks like the US guys made it production quality, isn't it? (At least it seems they generate correct code) Benoit
Hi, On Tue, Mar 02, 2010 at 08:40:49PM +0100, Benoit Boissinot wrote:
On the other hand, it looks like the US guys made it production quality, isn't it? (At least it seems they generate correct code)
Yes. Well, I suppose it should be ok if a student wants to work on it, though I remain a bit skeptical (maybe wrongly). A bientot, Armin.
participants (4)
-
Armin Rigo -
Benoit Boissinot -
Maciej Fijalkowski -
René Dudfield