On Feb 1, 2008 2:31 PM, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
On Feb 1, 2008 6:00 AM, Tobias Ivarsson <thobes@gmail.com> wrote:
>
> On Feb 1, 2008 4:00 AM, Jim Baker <jbaker@zyasoft.com> wrote:
> > Alex,
> > On Jan 31, 2008 6:50 PM, Alexandru Popescu ☀
> <the.mindstorm.mailinglist@gmail.com> wrote:
> > >
> > > On Feb 1, 2008 3:33 AM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
> > > > On Jan 31, 2008 6:56 PM, Alexandru Popescu
> > >
> > > > > 2/ there is a python bytecode to java bytecode converter (which
> > > > > according to people handles correctly "all" conversions).
> > > > > Currently pyasm is written in python and work on python bytecode
> directly.
> > > > > This lives in another sandbox project: sandbox/pyasm.
> > > > Right -- that is the work of Jim Baker and Tobias Ivarsson.
> > > >
> > > > > However, moving forward doesn't only mean to integrate these 2
> > > > > subprojects into the trunk. There is still a missing step in the
> > > > > middle of processing:
> > > >
> > > > > a) adapt pyasm to work on the parser generated AST
> > > > > b) add a post parser step that takes as input the AST and generates
> > > > > python bytecode. After this step pyasm can probably be applied as is
> > > > > (or with very small changes).
> > > > Well not python bytecode but JVM bytecode -- but maybe that is what
> > > > you meant?  Also we need to translate pyasm to pure Java since we are
> > > > not pypy (though who knows about the future...)
> > > >
> > >
> > > No, I actually meant what I have written down :-). Note, I'm speaking
> > > about 2 possible approaches:
> > >
> > > a/ (that is the most natural) move pyasm to java and apply it to the
> > > AST instead of python bytecode => java bytecode
> > >
> > > b/ (would be a twisted approach, but would probably offer a guarantee
> > > that the AST is the most correct one)
> > >
> >
> >
> > >
> > > AST => python bytecode (through a transformer) => java bytecode (through
> pyasm)
> > >
> >
> >
> > We are planning on supporting option a for now. But as Tobias observed to
> me, option b is actually quite useful seen through a different perspective,
> if you modify that final transformation by pyasm. So the idea would be to
> have Python bytecode VM that is available in Jython. PBC is quite high
> level, and we already know how to compile it to Java bytecode that works
> with the Jython internals using pyasm. So interpreting it should be really
> easy. The advantage of doing so: we could provide the missing level of
> dynamic functionality that would otherwise require runtime bytecode gen. So
> it could run on Dalvik or in an applet.
>
> One view I've had in my mind is to use python bytecode to model an API, and
> pyasm is really a first shot at that. At the moment I am working on using
> the AST to drive such an API and then have the implementation of that ( this
> is sandbox/pyasm today ) generate Java Bytecode. The benefit of this is that
> we have a code generation API that is targeted at Python that we can put
> different implementations behind to generate different kinds of output, eg.
> the Java bytecode that we generate today, python bytecode for when running
> in restricted environments, as Jim mentioned, or Java bytecode with another
> class structure. Why not bytecode for the DaVinci Machine
> (http://openjdk.java.net/projects/mlvm/). I see this as a nice cutting point
> for decoupling the logic of what we generate from the actual representation.
>
> - Tobias

It is so cool to see how an initial idea that sounded quite weird has
evolved so far :-).

I know, I had a personal argument with myself for almost two weeks from when I got the idea to when I started working on it. For that exact reason, it sounded quite weird. But I managed to convince myself that this road was a good enough idea.


./alex
--
.w( the_mindstorm )p.

> >
> >
> >
> >
> >
> > JRuby incidentally supports both interpreted and compiled mode, although I
> don't know if they have a similar VM approach.
> >
> >
> >
> > >
> > > I do believe that a/ is the right approach, but you never know :-).
> > >
> > >
> > > > > Am I seeing things correctly?
> > > > Yes I think so otherwise.
> > > >
> > > > > There are other 2 important aspects (cpython c modules and java
> > > > > integration), but that will come a bit later.
> > > > CPython c modules are tough -- for now we translate them into Java.
> > > > Someday we may look to calling C extensions through JNA as Charles
> > > > Nutter of JRuby has considered doing in the Ruby realm, but that is
> > > > perhaps pie in the sky talk.
> > > >
> > >
> > > Well, if there are important modules that people may miss right away
> > > then you/we should definitely consider
> > > porting them to Java. Is there such a list available? The only
> > > reference I could find is around 2 years old already.
> > >
> > >
> >
> >
> > We should formalize a list, but we're working slightly differently now.
> JRuby inspired us to tackle whole applications; I credit Eric Dobbs for
> bringing this approach to my attention. So that's why we're interested in
> Django or ipython or TurboGears 2; not only are these useful apps to run on
> Jython, they help prioritize this translation process and expose gaps that
> simple porting would not have.
> >
> > From a methodology perspective, such apps function like a customer in an
> agile setting.
> >
> > Of course we can do better and more, but I think recent work has
> demonstrated that we are making really good progress.
> >
> > - Jim
> >
> > --
> > Jim Baker
> > jbaker@zyasoft.com
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Jython-dev mailing list
> > Jython-dev@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
> >
>
>