2012/12/03 08:51:28 -0500 Rocky Bernstein <ro...@cpan.org> => To Richard Foley :
RB> Something I think about when I read about things like this whether there
RB> some sort of unifying principle that could be used in other debuggers or
RB> for other similar sorts of  programs. Is there some support that a debugger
RB> should be providing to make things like this easier?

I think it's about a standard for the program interface that majority of
debuggers should follow.

Debug::Fork::Tmux can redefine some other function (and/or a global variable)
from another debugger. In this case the feature to implement can be the 'let
user to tweak a namespace other than DB to inject to'. Very obvious.

RB> Too often, especially with the venerable Perl debugger, you read about
RB> patch someone has that made that does some interesting thing. Or s a trick
RB> you can do in order to get something done that is commonly needed. It feels
RB> less like the "art" but rather knowing about a number of isolated tricks,
RB> or worse, workarounds that is relevant for one debugger on one programming
RB> language.

I don't patch the debugger, sorry.

When needed, the critical mass of 'isolated tricks and workarounds' can be
collected into one distribution, and documented in details in one place, can't

RB> That said, of course, all of this is cool.


My main target with Debug::Fork::Tmux was to make a convinient build
environment, including docs, for better and faster releasing.

Otherwise the one can use a couple of lines to use Tmux for that same purpose.

RB> > Here is an interesting module from Peter Vereshagin which might help with
RB> > debugging forks under the perl debugger, if you use tmux version 1.6+
RB> >
RB> >     http://search.cpan.org/dist/Debug-Fork-Tmux

Peter Vereshagin <pe...@vereshagin.org> (http://vereshagin.org) pgp: A0E26627 

Reply via email to