Dysfunctional Programming

I’m one of two developers on an open source project.  I’m going to try to be as vague as possible about the project, because the stimulus of this post is some developer politics that aren’t particularly important.  However, some background is required for some issues that I wish to bring up.  I’ve been a part of this project for about two months now, and have gradually been introducing bigger and more intrusive changes.  Recently, the other developer has begun to disagree with some of my commits, and as of today has informed me (in no uncertain terms) that I should stick to certain key areas of the source code, and avoid touching anything else.  If I have changes I want to make outside of my designated area, I should send a patch, which he will modify to his satisfaction and check it in.

Personally, I find this grating.  I’ve poured my soul into this project for the past two months, and I feel like I’ve got a really good handle on the code base.  I’m happy to discuss changes I want to make or have made, but this feels like I’m on probation because my attempts to improve the project conflicted with the lead developer’s vision.

Let’s ignore whether either of us in the right here, and concentrate on what possible courses of action I have available to me.  I can:

1. suck it up and keep working for the project’s benefit
2. pout and refuse to contribute under these conditions
3. fork the project, and take control of my own destiny

Option 3 is often touted as a fundamental right of any Free Software developer.  Since the code is completely open, anyone can take a snapshot of a project and make it their own.  This is a drastic measure, but sometimes a necessary one in cases where a hostile developer is actively stifling further work.  Leaving aside the question of the right choice in this situation, I realized today the problem with forking that is not considered by most people who evangelize Free Software’s benefits: the brand.

The project of which I am a part has a brand.  We receive 20-30 downloads per day, there is a Sourceforge page, a bug tracker, user forums, and more.  The lead developer is in control of all of this, meaning that a fork will lose it all.  This severely limits the efficacy of a fork - why bother working on something if nobody’s going to use it?  Any user will almost certainly find the original project before coming across my fork, so there’s precious little motivation for me besides “I want to be my own boss.”

While this is an isolated incident, and I haven’t spoken to anybody else about it, I would be interested to find out whether this is a legitimate concern for other projects.  The right to fork is great, but it’s wasted if there’s too much tying you down.

After some more fiddling, basic robot watching is pretty rock solid.  I fixed some memory leaks and crashes, and I’ve moved on to breakpoints.  And herein lies the conumdrum, as I’m trying to figure out the use cases here and how everything should work together.  As it stands, breakpoints are not very useful, because you can only place them when debugging, and then the only option is to place a breakpoint at the currently executing line.  The robot editor that shows up when debugging currently has no mechanism for scrolling around the robot’s code, so you’re limited to the view of about 10 lines of code that surround the current line.  For breakpoints to be useful to a developer, I feel like either you should be able to place them either in editing mode (when you’re actually modifying the robot), which will lead to all kinds of terrible headaches trying to keep that information in sync with the robot’s contents, or else the debugging interface needs to have more interactivity.  I’m leaning towards the latter option, but still open for discussion.

The other major consideration right now is what kind of lifetime breakpoints should have.  Should they persist between debugging/testing sessions?  Across boards?  What should happen to the interface when the player switches boards and the debugged robot no longer exists?  These are questions for which I don’t have good answers at the moment.

What with midterms and end of term, it’s been several weeks since I last touched my robotic debugger, but that changed tonight.  There’s now a usable bleeding-edge debugger for your perusal in the bzr repository.  You have your choice of robots to watch on activation (ctr+f6 in testing mode), f8 will bring up the watch dialog, f9 will step a single instruction (which updates in the editor accordingly, so you can follow the action), and f10 will continue normal execution with the debugger still activated, so pressing f9 will start stepping once more.  Of course I’ve somehow induced megazeux to start segfaulting on exit, so there are obviously some problems that need fixing, but everything starts somewhere!

I’m just finishing up the CS 136 class here at the University of Waterloo, which also goes by the name of “Elementary Algorithm Design and Data Abstraction.” In other words, we make the transition from introductory Scheme to introductory C while learning about topics such as braun trees, hash tables, and more. We’re also expected to use test driven design, or at least write tests and run them frequently, to ensure that our assignment programs are working correctly. While most of the programs are rather elementary, the procedure to test data structures such as linked lists is rather annoying, because it ends up looking something like this:

No imagine writing that over and over, especially if you have multiple fields that need testing. Being unsatisfied with this setup, I took it upon myself to write a linked list field asserter, which can be used like so:

As you can guess, it’s about as generic as you can get in straight C without the benefit of C++ templates. If you have a structure that is traversed via a pointer to the next structure, it can be asserted with this system. assertListFieldEqual takes

• a pointer to the head element
• offsetof(list type, field to compare)
• a pointer to a comparison function
• a pointer to a list of expected values
• the size of a value
• offsetof(list type, traversal field)

The function itself is not particularly difficult, but it does abuse pointers in very unethical ways:

I’m pretty sure all of my pointer abuse is fully sanctioned by the standard, so it should be portable to my knowledge. Therefore, go forth and multiply, and test your lists well! And if you’re in any doubt that this is not generic enough, behold, I give you string comparison!

I’m an occasional contributor to the MegaZeux source code, and I frequently compete in the bi-annual Day of Zeux competions.  Accordingly, I’m always interested in new ways to push MegaZeux forward and help people create games easier, which brings me to Kev Vance’s MegaZeux debugger.  It’s ten years old and based on the ancient 2.51 codebase, which means that the released code is not much good (2.7 was a near complete rewrite, if I recall correctly), but it’s got me thinking about how a debugger could integrate into the modern incarnation of mzx.  So much so that I’ve got a prototype in the works (and a corresponding bzr repository), and some thoughts to put down on paper.

I forsee a debugger in MegaZeux as being useful in the following ways:

• Tracing code execution in a single robot
• Placing breakpoints in robotic code
• Verifying expected values at different points in the program

The third is already possible with the F11 window that was added recently, which displays all known counters for easy perusal.  Combined with instruction stepping, a debugger will hopefully remove the need for debug variable output lines in order to determine when a counter’s value changes.

The vision of the robotic debugger I have is a shortened robotic editor that takes up half the screen.  This displays the watched robot’s program with the current line highlighted.  F9 will single step forwards in the current robot, F10 continues the normal execution until/unless a breakpoint is reached (in any robot).  Pressing CTR+F6 will bring up the debugger interface, and a window to select the robot to watch, at which point all execution will cease until the user presses either F9 or F10.

That’s the gist of it right now.  I currently have the shortened editor displaying the watched robot code, but only the global robot can be watched right now, and the code display doesn’t actually show which line is about to be executed.  If you bring up the debugger, all robot execution stops, and pressing F9 will trigger one line of code to be executed in the global robot, and F10 will make everything resume as normal.

Now, a brain dump of problems that I need to consider, in no particular order:

• Remove the ability for the player to move when single stepping?
• In fact, currently the rest of the board is updated as usual while the debugger is active, so bullets will continue to move normally even when the user is single stepping a robot, so something has to change there.

I’m positive there are going to be more concerns I’ll have to deal with, but I’m pleased with the progress I’ve made so far.  Next step: make the debugger show the actual line being executed.  Then it might start being useful!

This site is beginning to take some semblance of form, not that any of it’s really visible right now.  I’m working towards a basic root page with the required information and resume links, and I’ve also put together a public bzr repository of the projects I am currently working on.

That said, there’s really only one right now, and that’s Denkatsu.  There’ll be an information page about it going up sometime soon, but here’s the gist of it - there will eventually be an open-source video editing app (a suite makes it sound like a lot more work for me) with similarities to iMovie and Final Cut, but with timelines represented as transformations on raw footage.  The goal is to enable a sort of editing playground - the user should never have to save a backup before cutting up a bunch of clips, as none of the original footage will be affected.  Procedural video editing, anybody?

As I said, that’s the ideal I’m aiming for.  Currently, Denkatsu (meaning activity like lightning) displays an episode of Star Trek: Voyager in a window that you can drag around inside the app window.  This is accomplished with a hideous beautiful open-source cross-breed of SDL, guichan, and ffmpeg, with more hybrid code grafting to follow.  Maybe I can even fit python scripting in there somehow!

For those with a hankering for blunt-edged code (this can’t even be called bleeding yet), the public bzr repository is up and in business!  Ciao!