Google Summer of Code 2011 - Parrot Debugger

[Kevin Polulak]

Hey guys,

I am a student interested in working on Parrot's debugger for Google Summer
of Code 2011. Some of you may already know me as soh_cah_toa #parrot. If you
do, then you know that I've spent the last week gathering ideas and studying
Parrot code (very fun, by the way). However, I'd like to ask a few questions
here on the mailing list in order to get some feedback from some of those
who maybe don't frequent #parrot quite as much.

The Parrot GSoC 2011 wiki reads:
New Parrot Debugger
 <http://trac.parrot.org/parrot/wiki/GSoc2011#NewParrotDebugger>

   - *Difficulty*: 4/5
   - *Links of Interest*: <NONE, please add some>
   - *Possible Mentors*: Whiteknight, cotto
   - *Details*: Parrot needs a new debugger. There exists a toolset called
   "parrot-instrument" which can be used to insert introspection, analysis, and
   manipulation functions into Parrot internals. You may optionally
   (preferrably) use Parrot-Instrument as the basis for your new debugger or
   create a new one from scratch. A successful debugger will have the ability
   to set break-points on subroutines at the PIR and HLL level, set watchpoints
   on registers or individual PMCs, and introspect state information from a
   running program. The debugger should read information from annotations so
   that it can be used to work with various HLLs. Performance of code executing
   under the debugger is not a primary concern for the initial deliverable.
   - *Expected Deliverables*: A working debugger with the capabilities
   listed above. In addition, the successfull student should provide adequate
   unit tests, code examples, and documentation.

What I would like to know is: what new features would you like to see in the
new debugger? Yesterday, plobsing mentioned something about a REPL and I
think this would be a nice addition as well. However, I don't have any
experience them. In spite of this fact, I don't think it's entirely out of
my league as I do have time before the summer to get my hands dirty. Though
I think it's important to consider this: is two months enough time for me to
become more familiar with REPL's and is three months enough time to
implement it into the Parrot debugger while leaving enough time for other
features?

Allow me to tell you a bit about myself so that you can gauge the difficulty
of your suggestions: This is my first GSoC as well as my first open source
project. The languages I have the most experience with are C and Perl. There
are a few others - Java, for instance - but being a Linux hacker, C and Perl
are my two comfort zones. I don't have any experience writing
compilers/parsers or debuggers but I do (obviously) use both of these on a
regular basis. However, that is the direction I would like to go with my
career which is why I am very interested in Parrot. To be specific, I
consider *gdb* and *perl -d* to be one the most frequently used tools in my
little programmer's pocketknife.

Please try to keep in mind that while I am certainly not a n00b, I am also
not a professional with 10 years experience as a senior developer.

I'm very eager to hear what you guys have to say. Even though, as I
mentioned earlier, I don't have much experience in writing debuggers, I
think this project would be the perfect challenge for me. It is right at the
level that would force me to "stretch" my abilities quite far but not too
much that it would be just out of my reach.

Even after a week of spending time on #parrot, I already feel quite
comfortable with Parrot and some of the developers. You have been very open
to my questions and input. Should I have the chance to work on Parrot this
summer, I think it would be quite fun to collaborate with you guys.


Regards,

Kevin P.
(IRC: soh_cah_toa)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20110324/b9bd724b/attachment.html>