On Feb 1, 2008 2:39 PM, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com> wrote:
On Feb 1, 2008 3:37 PM, Tobias Ivarsson <thobes@gmail.com> wrote:
>
>
>
>
> 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.
>

Well, there is still one aspect that should be probably kept in mind:
how does this approach impact the overall performance.
If this approach is gonna have a big impact of the performance then I
would say that it should be provided as an alternative and to be
configurable using some specific settings.

Of course, and we will have to design it in a way that keeps the performance impact at a minimum, and measure these aspects as we progress.


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

>
> >
> >
> >
> > ./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
> > > >
> > > >
> > >
> > >
> >
>
>