GSoC 2011 project idea: GObject interoperability

[Andrew Whitworth]

Hello Christoph, welcome to Parrot!

On Fri, Mar 25, 2011 at 10:43 AM, Christoph Gärtner
<cggaertner at googlemail.com> wrote:
> Is there interest in a GSoC project focusing on Parrot <-> GObject/Vala
> interoperability? The scope of the project could be along these lines:

The answer is "yes". Vala on Parrot is something that we've talked
about in the past, and would be a welcome addition to the Parrot
infrastructure. This could be in the form of a new Vala compiler
written from the ground-up, a Vala wrapper for the embed API, or a new
backend for valac. I think all are all pretty interesting ideas.

GObject is another topic we've talked about in the past, and arguably
would be better than a Vala interface. If we had a good GObject
interface which was easy to use, that would make it much easier for us
to interface with various GNOME libraries: Everything from cairo, gimp
and pango all the way up to something much larger like full bindings
to Gtk+. Also, we can start talking about embedding Parrot into GNOME
utilities much more easily.

> * low-hanging fruit:
>  - create a Vala wrapper for Parrot's embedding API
>  - create a Parrot wrapper (PMCs/dynops) for GObject less painful
>   to use than NCI
>
> * advanced goals:
>  - implement GObject's object-model on top of 6model
>  - retarget valac to create PIR instead of C code
>
> * optional goals:
>  - create GNOME bindings for Rakudo

My personal preference (and other developers may have a different
opinion), would be to work on the GObject wrapper types first. From
there you can branch out to doing something related to Vala, or use
your new GObject wrapper types to start providing nice interfaces to
various bits of GNOME.

> * using TinyCC to create a JIT prototype: TinyCC should be fast enough
>  for that, and op definitions are already available as C; however, the
>  Lorito effort probably makes this worthless in the long term

I agree with your last statement, Lorito probably makes this
unnecessary. Also one of our developers, bacek, has been working on a
library for doing PBC JIT-like compilations down to native code using
LLVM. TinyCC is a nice idea, but we're probably past that at this
point.

> * using Parrot as a testbed for ECMAScript-Harmony; however, you'd have
>  to duplicate a lot of the effort of (or block on) Javascript-on-Parrot
>  (see http://wiki.ecmascript.org/doku.php?id=harmony:proposals and
>  http://wiki.ecmascript.org/doku.php?id=strawman:strawman for Harmony
>  features beyond current ECMAScript)

We definitely like JavaScript, but I don't think we can do anything
like this until we have a working JavaScript-on-Parrot compiler
running, which probably won't be till the end of the summer.
Unfortunately we can't have a situtation where students are depending
on each others work, or blocking on each other.

I would really like to hear more about your ideas for GObject and
Vala. Are you available to chat on IRC?

--Andrew Whitworth