2009Q1 Grant Proposal: Perl debugger integration in Padre, the Perl IDE

| 9 Comments
Name:

Gabor Szabo

Email:

[hidden email]

Amount Requested:

USD 1500

Synopsis

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.

Deliverables

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.

Bio

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/

9 Comments

Adding the debugger to Padre makes the IDE just that much more usable. And a community supported IDE with all the bells and whistles makes perl that much more attractive.
2 thumbs up from me.

Perl has problems attracting new blood, so I think an easy to use debugger would help with that. +1 from me.

Please get this done, even if no grant happens! I've been working on and off with Perl since 1998, and it would help greatly!

A good IDE is an enabling technology.
A good IDE needs a graphical debugger.

This proposal is very important if you like to attract new talent to Perl.

If you think the focus is too narrow (Padre - is it just another Perl Editor Project?) please note that the end result should be easily integrated with other IDEs or editors.

Gabor has a very clear idea of what the perl world needs today to stay relevant without being dependant on a far away christmas aka perl6.

With padre he has shown to have the technical and community skills needed to deliver what he promises.

An integrated debugger is one of the killer features of great IDEs that often do not support perl (e.g. the java Netbeans debugger is great). Adding modern tools to the toolbox of perl programmers is necessary and debugging is an essential part of modern developing.

EPIC with Eclipse have Perl interactive debugging years ago.

Padre is I believe the most serious effort so far to build a perl editing environment in perl. Besides helping beginners learn perl easier, Padre makes it possible for experienced developers to provide a visual interface for their development tools when the command line is not the best or the only option. With on-the-fly syntax checking, PPI integration, outlining and advanced syntax highlighting, Padre has almost all the fundamentals in place, a quality debugger being the notable exception.

Eclipse-based EPIC is a great IDE which I actually use for the majority of my perl coding (my other editor of choice being vim). EPIC, however, suffers from the limitations of its platform - I find Eclipse too confusing for beginner programmers, and too inflexible for developers coming from the vim/emacs world. Furthermore, since EPIC is essentially a Java project, it too difficult for a perl programmer to contribute to it, or to write a plugin for specific functionality he or she needs. Padre fills a major niche in the Perl ecosystem, and its importance is yet to grow.

I don't understand everything but based in the other proyect you have, I agree.

The only problem is the licence wxwidgets use a wxwidgets licence like a gpl.

This way companies that support us are not going to be able to sell all we do.

Is really problematic to know what parts the company can sell about the products they use from us.

I don't recommend it :(

Neither the other project from the same person :(


Leave a comment

About this Entry

This page contains a single entry by Alberto Simões published on February 5, 2009 10:28 PM.

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