2008Q4 Grant Proposal: Perl debugger integration in Padre

  • Name: Gabor Szabo
  • Project Title: Perl debugger integration in Padre, the Perl IDE
  • Synopsis: Integrating the perl built-in debugger into Padre, the Perl IDE using Debug::Client a stand alone client to the perl debugger.

Gabor Szabo

Project Title:
Perl debugger integration in Padre, the Perl IDE

Integrating the perl built-in debugger into Padre, the Perl IDE using Debug::Client a stand alone client to the perl debugger.

Benefits to the Perl Community:
Padre already has many features required for a text editor. Adding the debugging capabilities will allow any perl programmer to use the power of the built in debugger without the fear of the command line or the learning curve associated with it. This addition will move Padre one large step closer to be a real Perl IDE.

Providing a simple text editor that people can use to write perl scripts and run them through a graphical debugger is especially important for beginners and/or MS Windows users but will benefit any Perl programmer.

As Padre is written in Perl and distributed under the same license as perl itself it can be used freely anywhere.

The separation of Debug::Client as a stand alone module will allow any text editor to be easily integrated with the built in debugger opening the way to other IDEs as well. The integration with Padre will ensure that the client is indeed usable in a real world situation.

Debug::Client, a stand-alone client for the built in perl debugger should pass its full test suit on Linux/Unix/OSX/MS Windows on perl versions starting from 5.6. This will be verified to the extent the CPAN testers provide coverage. Test coverage of the module should be at least 90%.

Integration into Padre to be usable right from the editor.

The following features will be supported:

  • step-in
  • step-over
  • step-out
  • run to line/subroutine
  • set/remove conditional breakpoint
  • set/remove watch (location independent conditional breakpoint)
  • constantly display content of any variable (scalar, array or hash)
  • evaluate arbitrary expression in the process
  • stack trace

Project Details:
The built-in debugger of perl that is normally invoked using the -d command line option can also connect to a predefined socket to be controlled via that socket.

This communication channel has been used by some editors to provide debugging capabilities for Perl but none of theses abstracted out their client side. In most, if not all the cases they are written in other languages so such abstraction would be meaningless to us anyway.

Padre is a Perl IDE written in Perl using the wxWidgets GUI library. It has been tested on MS Windows, Linux and OSX. In its current state it is a text editor with some Perl specific features. Adding debugging capabilities to it will turn it into something that can already be called a real IDE. In order to add debugging capabilities we either need to implement a debugger or reuse the built-in perl debugger via its socket communication layer. The advantage of connecting to the built-in debugger is that we don't need to install anything to the perl used for the production code and it also enables us to run the debugger remotely.

Debug::Client is a stand-alone module that implements the clients side of that socket communication with the built-in debugger. It has been written separately from Padre in order to make it reusable by any other IDE or tool that might want to add perl debugging capabilities.

See also http://padre.perlide.org/

Project Schedule:

I plan to begin the project immediately and finish it within 2 months.

Gabor Szabo has been programming Perl since 1995 and teaching it since 2000. He has several modules on CPAN and has contributed to many other modules including ack. Gabor is the primary author of both Padre and Debug::Client.

See also http://szabgab.com/

Amount Requested
USD 1500


Disclaimer: I've applied for a grant of my own.

Here's the thing about any project that aims to write an editor for Language X ...

In my opinion, these projects are fun for the author, but not likely to be used. If you look at the dominant editors in Perl-land (vi, emacs, TextMate), you'll note that they're all useful for more than one language.

Perl folks do not seem to be IDE users, and I don't think they're looking for an editor that only does one language. And of course, modern IDEs also handle more than one language anyway.

I commonly edit Perl, HTML, Mason (mostly HTML), CSS, and JS files, and sometimes things like config files and all sorts of other junk. With emacs, I have tools for all of them.

These big editors also have tons of features that have nothing to do with editing a programming language, like editing on remote hosts, source control integration, spell checking, etc. Their breadth and extensibility make them powerful, and are what attracts a critical base of users.

I cannot imagine Padre or any other Perl-specific editor becoming as useful as these existing tools. Does Gabor plan to spend the next 5-10 years or so working on this editor, because that's what it'd take, I suspect.

Sure, I'd like an editor that was smarter about Perl, but I'm not going to trade away all those other features just for that (plus there are even cool things like PerlySense that add "Perl smarts" to emacs).

For all these reasons, I don't really think a Perl-specific editor has much value for the Perl community.

Two problems with your "I don't use IDEs and nobody I know uses IDEs" theory here. First I'm not sure your selection size is a fair representative set, there are many more Perl people than either of us associate with (especially since we are running in increasingly similar crowds ;) ). Second even if this is true now, it may not be true if a good Perl Only IDE emerges.

One of the things people like about SmallTalk, Java, and the VisualStudio languages are the high level of tools for developing with those products. They look at Perl and are completely lost as to how to build anything effectively without an editor that can do proper highlighting, contextual help, method lookup and some nominal refactoring ... as well as integrated debugging (which is exactly the feature this grant is requesting).

While I may agree with you that *I* currently don't find Padre interesting because TextMate has owned me, I have changed editors semi-regularly in the last five years until I found one that seemed to fit best. The fact is that Padre may interest me if it provides me at least the same features I wanted in TextMate *and* is cross-platform, at least as a backup editor, and if I could potentially see it useful then I'm sure others will certainly find it useful.

Just as there is no one Operating System to rule them all, and no one True Programming Language ... Editors are a highly individualized choice and Padre seems to be making some headway in a unique way. I say let him run with ideas, and perhaps we will all be happily surprised.

Yes and no... I mean, on one hand, there's nearly no chance I'd ever use a special-purpose editor for one language. It's just not economical.

On the other hand, a well-developed special-purpose editor is likely to produce useful spin-off modules. For example, Debug::Client, above, is not described as something just for Padre, but something made for Padre that could be useful for other things. That's a great benefit, and if some of the work to build it goes toward Padre itself, that's just a marginal cost.

Disclaimer: I have not looked at the Padre project at all except by reading Gabor's journal entries.

Much to my surprise after years as an Emacs enthusiast, I've become a fan of heavyweight IDEs like Eclipse. In any IDE, strong debugging tools are a ticket-to-play feature, not a killer feature. What makes Eclipse special, in my opinion, is the huge amount of effort expended in ergonomics. I have a hard time believing a startup editor, even one devoted to Perl, can compete with those UI refinements without a significant team of experts.

Instead, I would prefer to see better Perl support in an existing IDE project, like the EPIC plugin for Eclipse. But of course it's not for me to say what volunteers work on!

I would love to see Perl get a "real" (graphical) debugger. It would just make my day.

I'd like to see Debug::Client developed further because it will help.

I would really like to see debugger functionality integrated in Padre.

I am aware that there are other products capable of doing it (Komodo IDE and Eclipse, for example), but I don't see it like a valid reason not to have it in Padre. We sholdn't have PSPad and Notepad++, because we have UltraEdit on Windows.

It seems that experienced Perl developer have their array of well tested tools. They don't seem to find reason to get others. But from the perspective of a developer like me, that started his carrer with Visual Basic, the benefits of a robust IDE with GUI is evident.

I believe also that a valid IDE could be a visible hint of the value of Perl, that usually doesn't get the attention it deserves, because many of its accomplishments are not mainstream visible.

you guys miss the point - it's about a mindset change.

Perl developers have their own oddball tool setups precisely because there was no clear way ahead. What we are talking about here is bringing new folks into the fold - quickly and easily. you want to be seducing Perl young-blood in.

The price of entry is high for the Perl newby - too many decisions to make to write a hello.pl. Compare that to Microsoft's approach - Insert CD, and twenty minutes later you are in a wizzy GUI and you type - hit F5 and you have a compiled binary.

If there was such a tool, like Padre, and it was cross platform, and it 'just installed' - I think you might draw in lots of fresh new recruits, otherwise Perl, with it's many virtues, will hold out the potential talent, because it is just to hard to get going.

I was initially sceptical about Padre (and Kephra before it), but actually I'm pretty impressed.

wx and the padre codebase are nice to code with and extend (even if 90% of the docs are for C++ and python) - the ability to extend and IDE and have pretty good (or close enough to make transition painless) emacs keybindings means I that it won't be long before I can use padre as productively as emacs *and* be able to extend it using perl and cpan modules, instead of copying and pasting pages of unintelligable lisp.

Perl has such a huge variety of development tools, that not having and editor that is extensible in Perl really is holding back the possibilities of what you can do.

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Entry

This page contains a single entry by Alberto Simões published on November 2, 2008 10:01 PM.

2008Q4 Grant Proposal: Inline C++/CLI was the previous entry in this blog.

2008Q4 Grant Proposal: Integrating Padre with Parrot and Rakudo is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2