GObject interop proposal - looking for likely mentors

[Jonathan "Duke" Leto]

Howdy,

I think this sounds like a great idea, and you should indeed post a
formal proposal to this list for review. Soon!

As organization admin, I try to provide strategic mentoring to each
student when they need it most, as well as all my other duties. You
can always ask me questions.

Good proposals almost always find good mentors, so I wouldn't worry to
much about that now. Concentrate on the rest of the proposal,
especially the timeline.

I eagerly await reading your awesome proposal :)

Duke

On Sat, Apr 2, 2011 at 9:38 AM, Christoph Gärtner
<cggaertner at googlemail.com> wrote:
> Hello parrot-dev,
>
> the GSoC application deadline draws closer, so I really should get a formal
> proposal written. The template available on trac asks for likely mentors, so
> I'd like to know who is interested in overseeing the GObject
> interoperability project.
>
> The project idea has somewhat matured during the last few dates, thus I'll
> provide a revised outline:
>
> The basic goal is to get Parrot and GObject to talk to each other. For the
> GObject side of things, this means creating a wrapper API over libparrot,
> for the Parrot side, this means using GObject introspection to automagically
> get wrappers for GObject-based libraries installed into Parrot at runtime.
>
> The second part is probably a lot harder than the first, and having thought
> some more about it, I'm actually planning to leverage the first part to make
> things more approachable:
>
> libgirepository, the library providing access to GObject introspection
> information, is itself GObject-based, so getting access to that from within
> Parrot must either use C or a Parrot language and go through NCI, both of
> which is likely more painful than it needs to be: There's a natural language
> for GObject, called Vala, and if the first part of the proposal is extended
> to a proper extension API instead of just providing access to the embedding
> API, it should be possible to code the second part completely in Vala.
>
> I actually already got access to all vtable functions in a first prototype
> which can be found at <https://github.com/cgaertner/gparrot>, and I do not
> see any unsolvable problems with that approach.
>
> There are some performance concerns, as the GObject wrappers for PMCs and
> GObjects's dynamic type checking don't come for free, but I don't consider
> them a deal-breaker: The cost only has to be paid when loading libraries,
> the installed wrapper-PMCs won't have any unnecessary overhead.
>
> If you (ie the Parrot developers) think this approach doable and valuable to
> the Parrot project, please let me know if you are interested in mentoring
> me, and I'll post the actual proposal with a proper timeline tomorrow.
>
> Christoph
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net