September 2012 Archives

A plan for revamping and replacing the Perl debugger.

There is a little bit of overlap here with the first blog on Devel::Trepan. I apologize for that, but I don’t see how this can be avoided. The focus here though is more on the existing Perl debugger rather than Devel::Trepan which is given as one concrete example from which to draw lessons from.

A number of people, myself included, have talked about modernizing or replacing the venerable Perl debugger, Here I’d like to suggest a plan of action.

First the situation. It is in many ways similar to the challenges faced say in going from Perl5 to Perl6 — and in other languages Ruby 1.8 to 1.9 or Python 2.7 to Python 3K. What is there is:

  • well known
  • battle tested
  • has lots of features, and is therefore…
  • useful …
  • used by a large number of people …
  • and comes with Perl

That’s the good side. On the bad side, what is there is doesn’t represent current modern programming practice. In particular it is one large 10K file. It isn’t modular in two aspects. First, it doesn’t use Perl Modules or namespaces very effectively. Second, it doesn’t have an API that facilitates extension of its debugger commands or provide an API that allows front-ends to easily hook into it. This is not to say that, people haven’t extended tor written front ends for it. But these all feel like uncoordinated, custom, and heroic efforts.

Related to perl5db being large and not modular, there aren’t many tests for it, especially not the smaller “glass-box” unit tests. Even with the recent activity of adding tests to, those tests and coverage pale in comparison to those that comes with Devel::Trepan. And to be honest, the coverage in Devel::Trepan leaves something to be desired. But comparing the number of tests does give a feel for how much is probably missing in terms of testing for

Finally, perl5db feels to me one-off in its command set. There is no other debugger that I know of that is similar to it to any great extent. Sure, all debuggers allow some sort of stopping, stepping and evaluation of expressions, but that is about where the similarity ends.

There have been some inquiry about using Devel::Trepan or something else as a replacement for It appears to me that in the past there have been efforts, and understanding why those have not succeeded might be instructive.

The challenges in replacing are suggested by looking at’s advantages. One of the harder challenges that I see is, again, similar to revamping Perl itself. How does one migrate programmers from perl5db given that there are already a number of people using, either directly or via a front-end and are happy with it and the features it provides no matter how arcane or fragile they may be?

The overall approach I suggest is really two fold and again not unlike what I see for example in Perl5 versus Perl6. One approach is to work on a replacement such as Perl6 or Devel::Trepan. The replacement debugger aspect is what I have been doing. The other is approach to rework the existing debugger to modernize it. (For Perl5 there is perl5-porters which is trying to modernize Perl5). One hopes that the two disparate efforts meet in the middle, hopefully more towards Devel::Trepan or Perl6 side since both ends of the efforts are moving presumably forward.

But how does that specifically apply here to Perl debugger(s)? I’ve offered some specific suggestions on writing tests on the project proposal.

At some point I should probably write more about how I test Devel::Trepan. I find it relatively easy, although it really needs more explanation as it might not be as self-evident until after the fact.

The other area I think very important is defining more of a debugger API as opposed to a command-line interface. The DB API effort was from a while ago, but it looks like that was also abandoned long ago.

In Devel::Trepan I am pretty convinced I have laid the ground work for using parts of the DB API but equally important isolating and breaking out other modules. There is something called an “interface” that glues together I/O layers so output could very easily be XML (or XML over a socket) rather than less-structured text. And there is a “Command Processor” which has command-oriented part but there are more API-ish things available separated from the specific command-line commands.

An interesting exercise is that someone should be able to replace Devel::Trepan::CmdProcessor so that it handles exactly the commands using the other parts of Devel::Trepan — the Interface part with its separate I/O routines and the lower-level DB part which sort of subsumes the DB API. To date though, all of the people I’ve mentioned this to have felt that the is ugly and are therefore are not interested in. However, I suspect there are people out there who don’t want to switch from

Right now in Devel::Trepan there is a DB layer that ultimately should be pulled out of Devel::Trepan and turned into a separate package that Devel::Trepan uses. This similar to what perl5db and the DB API both use. This is another area where I feel there should be a “meeting in the middle”. The two reasons I have not separated this out right now is that the DB namespace is special in its powers and that namespace is taken. So I can’t register that. Secondly, right now Devel::Trepan is the only user of this. So breaking this out adds gratuitous complexity for Devel::Trepan users. For example, if I change that lower-level API in an incompatible way, Devel::Trepan will also have to change. And users of Devel::Trepan will have to update two packages where they would have had to update only one when they are bundled together.

Still, if Devel::Trepan becomes more popular or there is a desire in other packages to use some of the lower level routines, this can be changed. For example, DB::LineCache caches Perl source code lines. When there is another package that wants to use that, I’ll make the split.

Let me close this off by listing things that a new debugger should have, some of which has been alluded to above:

  1. It needs to be modular and represent current programming practice. However it probably needs to handle lots of older Perls as well.
  2. It needs to work in minimal and hostile environments. And that’s why in Devel::Trepan I don’t use Moose.
  3. On the other hand it should be extensible so that environments it can use things that many environments might have. For example terminal coloring, nice data structure formatters, disassemblers, interactive shells like Devel::REPL.
  4. It should facilitate hooking into front-ends like Padre or Eclipse and so on, and out-of-process or out-of-host remote debugging (which for example is useful in debugging web server modules).
  5. It should facilitate different styles of debugging and debugger entry: non-interactive tracing, or pulling in the debugger in via a signal handler or Josh Ben-Jore’s Enbugger.

About rockyb

user-pic I blog about Perl.