Open Source rocks! Learning from code by debugging

Posted May 12th, 2009 by kaikokan

In my previous article I described installing the EPIC plugin in Eclipse. I think this is a great editor and I definitely appreciate it a lot. I do have some problems with it, it seems to me it's a bit buggy, if you just want to use it for writing code you won't have this problem, but I want to use it for debugging and there it gives me some problems (crashing, unexpected results). It works OK for some programs but I want to use it for debugging GUI programs and I'm afraid it just isn't perfect for the job(yet).

Other IDE's

I tried a few other IDE's in the past few days and I must say much to my dislike the only one which really worked well on debugging the code I was trying this on was the komodo IDE. The reason I'm not happy about this is that it's the only one which is not free. I do have to say I do really think it's worth it's money and I'm actually thinking of convincing someone to buy it for me.

Learning from other people's code

The reason I want this debugging feature so hard is that I like to learn from other people's code. The thing I like so much about running an open source OS, is that I can just read the sources for programs on my system and try to figure out what they do and how they do it .

podviewer

I found a program called podviewer on my system which is a GUI tool to view perl documentation, this program uses gtk2 which is the main reason why it drew my attention. (I found the tool as I was grepping for perl and gtk trough my /usr/bin directory.) Anyone who has read my previous articles knows that I'm looking for a way to learn perl GUI programming and I'm starting by trying to learn to use Gtk. I won't say I will stick with Gtk forever as readers already pointed out there are valuable alternatives available. But back to the podviewer. The podviewer is a reasonably "simple" application when started it looks like this:

As I said pretty basic, it has a few options you can enter a perl module name in the left box and then you can load the perl documenting which is in this module which is then formatted and shown. You have a search box which gives you the option of searching trough the displayed text, it shows an index to the loaded documentation at the left and I believe it can also use a browser if you have some environment variable set.

Improvement

It's a nice tool as it does it's job, but I like to see if I can make a small change to it to improve it a bit. I do have one problem with it: I can only load the documentation which I know exists, if I try to load a module by just typing some arbitrary text the program searches my system for that specific module and when it fails to find anything it just displays a alert screen saying it's not there.

What I would like it to do is show me the available POD documents upfront so I can just choose one from a list or something. As the program is already capable of searching for this stuff I'm pretty sure it must not be to difficult to adapt it to make it search upfront and make a list or something.
I really don't have a clue how I could make something like this work but I think it would be a good start trying to understand how the program finds the documents it displays.

Debugger

Enter the debugger, in my experience when you learn programming the debugger is not something that comes up first as it is considered a advanced tool. Too bad in my personal opinion as I think the debugger is a unmatched learning tool. While I do understand you need to learn the theory behind the code first it's just so much easier to understand when it's actually shown to you (this is my personal opinion, I don't know how other people perceive this). The debugger can actually show you what is going on in the program while it's running.
Not only can it show the execution path line by line it also shows all variable values and changes in the values while code is executed. I must say it is a little tricky to debug a GUI application as it responds to everything that gives a signal to the program. For example when you run the debugger and step trough the program until you are at a certain point, you then activate the window and when the mouse is on something which activates a tooltip the program executes the tooltip so you step to another place in the program.

Playing around

I've been playing around with a trial version of komodo debugging podviewer (which I copied to my home directory and renamed podviewer.pl so it shows as a perl file in my editors)

When started by clicking debug the execution is stopped on the first executable line:

The rest of the story on page 2

This is the third article in a ongoing series about learning perl GUI programming. You may be interested in the other articles too. You can find the other articles here:
1. starting perl GUI programming
2. Installing Eclipse, the Epic Perl plugin and my first Perl GUI program
3. Open Source rocks! Learning from code by debugging
4. Quick and dirty linux GUI programming
5. resources for learning Perl Graphical Programming
6. Drawing and animating directly to the Desktop with Perl
7. Dynamically-creating-gui-objects-on-demand-in-Perl

Here's a reason for installing Perl/Tk.

Anonymous 1 year 16 weeks 17 hours 35 min ago

The Perl/Tk debugger is a Perl GUI app; find it on CPAN at http://search.cpan.org/~aepage/Devel-ptkdb-1.1091/ -- Once you've pulled in and installed the CPAN Tk module, installing ptkdb is quick and using it isn't hard. Other than when I need to debug Perl/Tk code (which is like having the debugger run while standing on its own shoelaces), about the biggest annoyances I've had with it are based on my own prior experience with other emulators and debuggers, and thus my expectations. You're starting fresh, so you should form good habits instead.

Is it perfect? No. It's Perl, though, and it's free (as in beer/speech/country), which soundly beats an expired-time-limit-trial app.

There's also commandline debugging in Perl itself; Conway's "Perl Best Practices" (one of the O'Reilly books) points to the perldebug ("man perldebug") and perldebtut files for how-tos on using it. Commandline debugging can get old fast, though, and, because your patience gets lost in the noise, it's less effective for zeroing in on bugs.

And you're right: sometimes, just watching the computer flawlessly execute my/your dumb programming errors and faithfully fulfill my/your code based on mistaken assumptions is the quickest way to enlightenment. I have a laugh whenever I zero in on a bug that I had to drag into the debugger to find; partly at myself for my overweening presumptions of expertise, and partly in relief, because, if the bug is in code I wrote (rather than in the Perl executable, the operating system or the hardware), I can fix it myself.

I often break out and test out small sections of code, where either I'm not sure of how Perl will behave, or I'm not sure of my algorithm, in little test programs (which typically means that I litter my project subdirectories with ".testperl" files). That way I can step through suspect code in the ptkdb debugger, even when that code will end up in a Perl/Tk app.

That's also a good way to compare the speed of execution of two or more approaches to doing something, using Time::Stopwatch (that's another CPAN module) to get comparison runtimes. (Just remember: first make it work, then make it reliable, then make it fast.)