While I feel like I got a lot of work done today, this past week was unfortunately much like the last: frustrating. Implementing breakpoints has turned out to be a lot more...interesting...than I had expected. And to what do I owe this great frustration? Why IMCC of course! For those of you who are unfamiliar with this, IMCC stands for "I Make Coders Cry."

Here's why:

A very simple algorithm for creating a breakpoint would look like this:

1. User enters command breakpoint 12
2. Store line number 12 somehwere
3. Run code

Since joining the Parrot development team, I've been forced to forget just about everything I thought I ever knew about stack machines, computer architecture, and especially control flow. In fact, I think a more appropriate slogan for Parrot would be "the antithesis of tradition." This is not necessarily a bad thing though. If it weren't for Parrot, I probably would never have heard of things like continuation passing style or mark and sweep garbage collection systems.

No, I'm not that lazy. I'm talking about breakpoints. :)

Right now, I'm focusing on how to implement breakpoints. First I will talk about how breakpoints are implemented in traditional debuggers. Then I will consider what this means for Parrot.

Howdy.

My name is Kevin Polulak (a.k.a. soh_cah_toa) and I am one of the seven newest additions to the Parrot community. This is going to be my first Google Summer of Code. The goal of my project is to build a language-independent symbolic debugger for Parrot. My proposal can be read here.