Differences between revisions 1 and 23 (spanning 22 versions)
Revision 1 as of 2007-03-05 20:18:38
Size: 23
Editor: nat-pool-rdu
Comment:
Revision 23 as of 2007-04-17 05:03:50
Size: 2250
Editor: c-71-204-163-42
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Google Summer of Code = Google Summer of Code =

Some project ideas that might work for Google's summer of code. The Python folks have [http://wiki.python.org/moin/SummerOfCode very good advice] for submitting proposals.

== Potential Mentors ==
 * FrankWierzbicki
 * JimBaker
 * CharlieGroves
 * MikeTaylor

== AcceptedProjects ==

HelpSystem

== Python 2.5 Language Support in the JythonCompiler ==

JimBaker and MikeTaylor are currently working on adding 2.5+ '''language''' functionality to Jython. We are trying to limit the scope of this work, just as was done with the AST implementation in CPython 2.5:

 * Write a generational grammar to build the desired AST in ANTLR 3. We may explore using a tree grammar to support enhanced visting. We think we might be able to just generate a comparable set of AST nodes as CPython, for enhanced compatibility. This is the easy part.

 * Generate code using ASM; this would replace the current !CodeCompiler.java. This would be the bulk of the work. There's some interaction with the rest of Jython, but not too much (we think). More importantly, we need to identify some best practices on mapping Python constructs to JVM byte code, basically updating what JimHugunin worked out 10 years ago.

We're also looking at two additional enhancements:

 * Move to using nested classes to represent methods. This just seems to be the right way to do it. Issues of PermGen seem to be just a red herring. We may be wrong, but it's the approach being taken by JRuby.

 * Favor "classworking" instead of reflection. ASM provides support here; JRuby is also looking at caching the necessary stubs.

We would expect that there would be suitable subprojects in this that are suitable for the GSoC students. Some that come to mind:

 * Facilitate Java calling Jython, via class/method decorators and possibly annotations.
 * Construct translation, especially performance/correctness issues. (Subtle closure bugs still seem to be out there in CPython for example.)
 * Stub cache
 * Rolling up as part of the replacement to jythonc, using compileall, going to setuptools.

All of these have the advantage that they can be completed to a certain implementation, and still be useful.

/PotentialProjects

Google Summer of Code

Some project ideas that might work for Google's summer of code. The Python folks have [http://wiki.python.org/moin/SummerOfCode very good advice] for submitting proposals.

Potential Mentors

AcceptedProjects

HelpSystem

Python 2.5 Language Support in the JythonCompiler

JimBaker and MikeTaylor are currently working on adding 2.5+ language functionality to Jython. We are trying to limit the scope of this work, just as was done with the AST implementation in CPython 2.5:

  • Write a generational grammar to build the desired AST in ANTLR 3. We may explore using a tree grammar to support enhanced visting. We think we might be able to just generate a comparable set of AST nodes as CPython, for enhanced compatibility. This is the easy part.
  • Generate code using ASM; this would replace the current CodeCompiler.java. This would be the bulk of the work. There's some interaction with the rest of Jython, but not too much (we think). More importantly, we need to identify some best practices on mapping Python constructs to JVM byte code, basically updating what JimHugunin worked out 10 years ago.

We're also looking at two additional enhancements:

  • Move to using nested classes to represent methods. This just seems to be the right way to do it. Issues of PermGen seem to be just a red herring. We may be wrong, but it's the approach being taken by JRuby.

  • Favor "classworking" instead of reflection. ASM provides support here; JRuby is also looking at caching the necessary stubs.

We would expect that there would be suitable subprojects in this that are suitable for the GSoC students. Some that come to mind:

  • Facilitate Java calling Jython, via class/method decorators and possibly annotations.
  • Construct translation, especially performance/correctness issues. (Subtle closure bugs still seem to be out there in CPython for example.)
  • Stub cache
  • Rolling up as part of the replacement to jythonc, using compileall, going to setuptools.

All of these have the advantage that they can be completed to a certain implementation, and still be useful.

/PotentialProjects

SummerOfCode (last edited 2012-01-21 02:13:50 by SkipMontanaro)