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'''
'''[email protected]'''
'''Other contact info''':
Look for cgaertner on irc.perl.org
=== 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
languages.
=== 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 <https://github.com/cgaertner/gparrot>. 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
<http://live.gnome.org/PyGObject> 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
non-classed
types like errors and boxed types, possibly signalling and
callbacks
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
approach
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
studies.
'''Eligibility'''
I'm over 18 years old and enrolled as a full-time student.
Christoph
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
