GSoC 2011 proposal: GObject interoperability for Parrot

Christoph Gärtner cggaertner at
Fri Apr 8 19:29:19 UTC 2011

Hi parrot-dev.

First of all, sorry for basically dropping off the face of the world for 
the last week.

I had the opportunity to take part in a summer school event of my 
university, which would have fallen right in the middle of the coding 
period, so I was mostly resigned to drop my application to summer of code.

However, the summer school did not work out, and I just sent my 
application to GSoC, literally at the last minute - I quickly threw 
together some kind of biography (which was missing from my draft) and 
submitted what I had without proof-reading - when I was finished reading 
through the proposal again, the time was up ;)

Anyway, here's the proposal for general consumption with slight changes 
from the 'official' version:

== Personal Information ==

'''Christoph Gätner'''

'''cggaertner at'''

'''Other contact info''':
Look for cgaertner on

=== GObject interoperability for Parrot ===

=== Abstract ===

The basic goal of this project is to get Parrot and GObject-based 
libraries to talk to each other. On the GObject side of things, this 
means creating a wrapper over libparrot, which should also get us Vala 
bindings with minimal effort. On the Parrot side, the final goal would 
be automagically generating wrappers for GObject types and functions at 
runtime via introspection.

=== Benefits to the Parrot VM and Open Source Community ===

A GObject-based wrapper over libparrot and subsequent Vala bindings 
allows easier integration into GObject-based applications and could make 
the Parrot VM a more attractive target for application scripting. The 
scope of the project, however, goes beyond embedding: By making VM 
interals accessible through GObject, it becomes possible to extend 
Parrot using Vala.

GObject introspection aims to be the main scripting interface of GNOME 
libraries as it frees language implementors from maintaining seperate 
library bindings. There is ongoing work on integrating GObject 
introspection into several runtimes, including PHP. One of the most 
important benefits for the Parrot community would probably be access to 
GTK+, making it possible to create desktop applications with Parrot 

=== Deliverables ===

A basic GObject wrapper for libparrot should be considered the 'safe' 
deliverable, as no major problems are expected. Using the 
code-generation facilities already present within Parrot's build system, 
it should be possible to generate wrapper methods for PMC vtables and 
install attributes of object-like PMCs (ie PMCs where 
PObj_is_object_FLAG is set) as GObject properties. Finally, code 
annotaion should make it possible to autogenerate Vala language 
bindings, and the GObject port of Parrot's embedding and extension API 
will live on top of that.

Runtime introspection is the more ambitious and fragile part of the 
project. As introspection itself needs access to GObject-based libraries 
- in particular libgirepository - it seems to be an obvious choice to 
leverage the first part of this project and create an introspection 
extension to Parrot using Vala. The end result would be a dynop which 
can potentially load arbitrary GObject-based libraries. However, this 
would mean that arbitrary GType types have to be integrated into Parrot, 
which might not be feasible in general. Therefore, a specific library - 
GTK+ - is targetted for introspection.

=== Project Details ===

All further steps depend on access to libparrot through a GObject-based 
wrapper API. However, registering Parrot's types with GType - the 
dynamic type system on which GObject is based - is not enough: While 
numeric types can be mapped directly and others can probably be treated 
as opaque (eg opcode pointers), more complex types - PMCs and Strings - 
need more elaborate wrappers, which, among other things, need to handle 
object destruction and interaction with the garbage collector in general.

Using the already present code-generation facilities, it should be 
possible to auto-generate GObject methods for all vtabe functions - in 
fact, this has already been done in a first prototype, which can be 
found at <>. However, not all 
functionality is accessible through vtables. In addition to low-level 
(ie untyped) access to the attribute structure, the code generator can 
be used to register high-level language-accessible attributes of core 
PMCs as GObject properties. This can't be done in the general case as 
ordinary attributes can have any C type - including those not 
registestered with GObject - while object-like PMC attributes only use 
Parrot-based types.

The expected steps for this in arbitrary order:

     - register low-level types
     - create PMC class with auto-generated methods for vtable functions
     - create root class for object-like PMCs
     - register attributes of object-like core PMCs as properties
     - create Subroutine class
     - create Interpreter class
     - create String class

Once the type system is in place, proper code annotation will allow 
generating Vala bindings. Recreating the embedding API on top of the 
hand-crafted and generated Gobject code in Vala can be seen as a first 
test of the viability of Vala as an extension language. This completes 
the first part of the project.

The second part of this proposal is far less clear cut and requires 
further research. Wrapper-PMCs for classed and non-classed GObject types 
have to be created, probably as dynpmcs, and stand-alone functions have 
to be made available as Parrot subroutines. A closer look at current 
high-level languages (HLLs) is necessary to determine the best apporach 
to the problem. Points of interest are again memory management as well 
as GObject's event-driven interface using signals and callbacks. Being 
able to register Parrot subroutines as GObject callbacks is a must-have 
for development of desktop applications.

At this point, one or more GObject-based libraries have to be chosen for 
testing purposes. The most obvious target is GTK+, or at least a subset 
thereof. The PMC definitions aside, supporting code will be written 
mostly in Vala, using, and - if necessary - extending the already 
present bindings. Apart form libparrot, we also need access to 
libgirepository, GObject's runtime introspection library. Exposing the 
resulting functionality to HLLs can be made as easy as a single dynop.

Expected problem areas are memory management - for example avoiding 
cycles during the interaction of Parrot's garbage collector and 
GObject's reference counting system - and object system interaction, 
especially cross-system subclassing. The former is a necessity for 
production use, whereas the latter might not be strictly necessary and 
should be considered a secondary goal.

Especially the second part of this proposal involves a lot of 
uncertainties. However, there is prior art for other runtimes (see 
<> for the CPython implementation), so 
the project should at least theoretically be feasible.

If all goals can be met in the given timeframe remains to be seen.

If it turns out that there are unsurmountable problems with the second 
part, the first part can stand on its own and might be extended in a 
different direction: For example, creating Vala bindings for Rakudo - 
the Perl 6 implementation on Parrot - would be such a possible 
extension, another would be embedding Parrot into an actual application.

=== Project Schedule ===

Coding officially starts on May 24th and encompasses 13 weeks, where the 
last week is supposed to be reserved for code and documentation cleanup 
and general polishing and bug fixing. The time before the 24th will be 
used for setting up the development environment - including a testing 
framework - and getting more familiar with Parrot's internals as well as 
discussing basic design decisions with Parrot core developers.

Following is my provisional schedule for the actual coding period. I 
fully expect it to change once coding starts - however, any additional 
time can always be used to improve testing and documentation, and a 
backup plan in case of unforeseen major setbacks has alraedy been discussed.

Week 1:     Map Parrot's type system to GObject
             Write basic tests in C

Week 2:     Create Vala bindings through code annotation
             Write additional tests in Vala
             Evaluate design decisions, refactor if necessary

Week 3:     Create embedding API in Vala
             Add functionality as needed

Week 4:     Write additional unit tests for the new API, convert existing
                 tests to integrate with Parrot's test suite
             Document and  present results to Parrot community

Week 5:     Research and design: Play around with dynpmcs and dynops,
                 libgirepository, look into HLLs
             Decide on approach for integrating GObject with Parrot

Week 6:     Map GObject's type system to Parrot, concentrate on the 
classed types
             Use a testing framework from the start, possibly Rosella

Week 7:     Add more features, including mappings for additional 
                 types like errors and boxed types, possibly signalling and

Week 8-9:   Get support for GObject introspection into Parrot, use GTK+ for
                 testing purposes
             Try to get access to as much of GTK+ as possible, including
                 signalling and callbacks
             Reevaluate project feasibility

Week 10-11: Continue adding GTK+ support
             Use additional GObject-based libraries for testing
             If project goals are unreachable, decide on alternative 
                 or try to continue anyway if partial results are possible

Week 12:    Properly integrate the project with Parrot's build system
             Document and present the state of the project

=== References and Likely Mentors ===

Project details have been posted to parrot-dev and #parrot and generated 
some interest. So far, I had the most interaction with Andrew Whitworth 
(whiteknight) and got some assurance of help from the Parrot 
organisation's admin Jonathan "Duke" Leto.

=== License ===

All Parrot projects should use the Artistic 2.0 license.

=== Bio ===

My name is Christoph Gärtner and I'm attending Goethe-University 
Frankfurt/Main to obtain a diploma in both mathematics and physics. My 
studies focus on differential geometry and do not involve any 
computational work. I have no formal background in computer science and 
programming is purely a hobby - something I do for fun, and only 
occasionally for work.

I started out programming in school using web scripting languages 
(Javascript, PHP, Perl) and used to earn money through web-design. 
However, I did most of my programming in my spare time, using Java for 
application development and C for system-level code. I spent some time 
on creating my own operating system, but lost interest after getting a 
bootloader to work.

What I'm most interested in is virtual machines for dynamic languages, 
and during the last few years, I implemented various parts of a language 
runtime, including a basic grammar engine, a garbage collector and an 
interpreter for a custom instruction set, but never got around to 
fitting all the disconnected parts to a comprehensive whole.

Even though only working on this in my free time might be fun, it does 
not benefit the open source community at large. I have thought about 
contributing to Parrot in the past, but never made the jump, mostly due 
to time constraints: Parrot's codebase seemed too intimidating to work 
on only occasionally.

I see Google Summer of Code as an ooportunity to finally use the skills 
I taught myself for something worthwhile, which could not be easily done 
in a purely hobbyist environment due to interferance of both work and 


I'm over 18 years old and enrolled as a full-time student.


More information about the parrot-dev mailing list