2012/12/03 12:48:41 -0500 Rocky Bernstein <ro...@cpan.org> => To Peter
RB> On Mon, Dec 3, 2012 at 9:06 AM, Peter Vereshagin
RB> > Hello.
RB> > 2012/12/03 08:51:28 -0500 Rocky Bernstein <ro...@cpan.org> => To Richard
RB> > Foley :
RB> > RB> Something I think about when I read about things like this whether
RB> > there
RB> > RB> some sort of unifying principle that could be used in other debuggers
RB> > or
RB> > RB> for other similar sorts of programs. Is there some support that a
RB> > debugger
RB> > RB> should be providing to make things like this easier?
RB> > I think it's about a standard for the program interface that majority of
RB> > debuggers should follow.
RB> I'm not sure what you mean. Suggest something.
api reference as a kind of unified principle described.
RB> > Debug::Fork::Tmux can redefine some other function (and/or a global
RB> > variable)
RB> > from another debugger. In this case the feature to implement can be the
RB> > 'let
RB> > user to tweak a namespace other than DB to inject to'. Very obvious.
RB> Devel::Trepan has lots of non-DB spaces one can tweak to. But again, I am
RB> not exactly sure what you mean so it would help if you could be very
For Debug::Fork::Tmux there's a DB::get_fork_TTY() to define and $DB::fork_TTY
to assign to. (a tty name for the next debugger's process).
I have no idea if any other debugger use this in the same way.
RB> > RB> Too often, especially with the venerable Perl debugger, you read about
RB> > RB> patch someone has that made that does some interesting thing. Or s a
RB> > trick
RB> > RB> you can do in order to get something done that is commonly needed. It
RB> > feels
RB> > RB> less like the "art" but rather knowing about a number of isolated
RB> > tricks,
RB> > RB> or worse, workarounds that is relevant for one debugger on one
RB> > programming
RB> > RB> language.
RB> > I don't patch the debugger, sorry.
RB> > When needed, the critical mass of 'isolated tricks and workarounds' can be
RB> > collected into one distribution, and documented in details in one place,
RB> > can't
RB> > them?
RB> > RB> That said, of course, all of this is cool.
RB> > Great.
RB> > My main target with Debug::Fork::Tmux was to make a convinient build
RB> > environment, including docs, for better and faster releasing.
RB> > Otherwise the one can use a couple of lines to use Tmux for that same
RB> > purpose.
RB> > RB> > Here is an interesting module from Peter Vereshagin which might help
RB> > with
RB> > RB> > debugging forks under the perl debugger, if you use tmux version
RB> > RB> >
RB> > RB> > http://search.cpan.org/dist/Debug-Fork-Tmux
Peter Vereshagin <pe...@vereshagin.org> (http://vereshagin.org) pgp: A0E26627