Howdy Kevin, Welcome to the Parrot Community!
We really need a new debugger, and I think the project can very easily spiral into something much larger than 3.5 months of work. I think it is a good idea to base a new debugger on Parrot-Instrument, which was a previous GSoC project. A lot of work has already been done for you, it would be best to build on it. Definitely read through the source of Parrot-Instrument and ask questions on parrot-dev about things that don't make sense to you. I think a reasonable "big goal" would be to get all the current parrot debugger tests to pass on a new implementation of a parrot_debugger. These live in t/tools/parrot_debugger.t . Of course, you may have to change the tests a bit, but the new parrot debugger should be able to do at least what the old one could, with a much better internal design. I think it would be good to collect a list of what the top 3 killer features that a new parrot_debugger would have, from people on this mailing list, and then concentrate on the most requested feature or two. Take note, that it could take the entire summer just to reimplement the debugger in a better way and get it to pass the tests we already have. The more questions you ask now, the better and more detailed your plan will be, which always coincides with a higher likelihood of a successful project. We need to see a very specific project schedule, down to which features you will work on every week of GSoC. Of course, this may change, but having a good plan up front makes changing the plan a lot easier :) Good luck! Duke On Thu, Mar 24, 2011 at 3:45 PM, Kevin Polulak <[email protected]> wrote: > 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 > > 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) > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > > -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
