On 09/08/07, Tobias Ivarsson <thobes@...> wrote:
> Thanks for pointing this out Samuele. I realize that I perhaps have been
> working a little too quiet with regard to the Jython community at large, my
> design/idea discussions have been limited to including only Jim (Baker) and
> Anyway, here is my idea and motivation for the work I am doing at the
> The final goal is to generate java bytecode for Python2.5 source.
> Since Damien Lejeune is working on the parser I didn't want to duplicate
> that effort, but while I couldn't wait for that sub-project I started
> looking for annother, existing, parser. What I found was CPython.
> The code I have uploaded reads the output from CPython in the form of python
> bytecode. It then uses this to drive the java bytecode generation framework
> I am working on.
> The interfaces are uploaded in the newcompiler-branch and the implementation
> (written in jython code for now) is over at my personal repository (
> while I work on debugging it.
> This is not ment as a final solution, I use this only to get an Idea of what
> the generated java bytecode needs to look like. When this is working I will
> move on to the next iteration/generation of the framework that will be
> driven by an AST outputed from Damiens parser. The interfaces will then
> change slightly, and I will probably be able to generate more optimized java
> bytecode as well.
> I actually started working on porting the current bytecode generation
> framework to useing ASM (that code is also available in my personal
> repository), but I found that this approach would give me a better image of
> what bytecode we would want to generate.
> The current state is that the generated bytecode has some errors and I am
> trying to fix those. I have spent the last few days trying to attach a
> better bytecode verifyer to my toolchain that hopefully can give me better
> error messages than the bytecode verifyer in the java classloader. This
> simple verifyer only gives error messages in the form of what kind of error
> it encountered and in what method it occured. The new verifier that I have
> managed to add also tells me what instruction the error occurs at and
> displays the instructions of the method. So hopefully I will have working
> bytecode for larger examples soon.
That sounds interesting. I just had a quick look at your repository.
Following my normal practice of looking at the tests first to
understand the public API, can you help me understand why the tests
are how they are and why it doesn't use unittest? I had a look around,
but didn't see anything documenting implementation choices / tradeoffs
(I appreciate that it may have been like that when you lifted it from