Re: perl -d: faster and less scary than you think

Myself I use "perl -d" debugging all the time, and while it's probably slower, it's fast enough to help me figure out what's going on pretty quickly.

I also frequenly run the perl debugger using the emacs gud front-end, though I've only briefly looked at sepia (another thing for the todo list). It's pretty much a matter of feeding the right perl command into the emacs "compile" command.

(I wrote an elisp package to help with that sort of thing: perlnow.el.)

Comment on Re: perl -d: faster and less scary than you think

Replies are listed 'Best First'.
Re^2: perl -d: faster and less scary than you think by educated_foo (Vicar) on Jun 04, 2007 at 03:04 UTC
Sepia has come a long ways since your review. Myself, I've always found the Perl debugger more painful than print statements, and didn't discover gud's perl debugger function until I had become used to using Sepia and print. Besides, what I am aiming for with Sepia is not an improved debugger, but a Lisp-style development model for Perl, where you experiment at the prompt, and errors give you a prompt to play with. Anyways, the point of my post was that you might as well always run with some debugging enabled, since it costs nothing and lets you diagnose problems without having to come up with test cases to reproduce them.	[reply]

Replies are listed 'Best First'.

Re^2: perl -d: faster and less scary than you think
by educated_foo (Vicar) on Jun 04, 2007 at 03:04 UTC

Anyways, the point of my post was that you might as well always run with some debugging enabled, since it costs nothing and lets you diagnose problems without having to come up with test cases to reproduce them.

[reply]