Hello. 2012/12/03 12:48:41 -0500 Rocky Bernstein <ro...@cpan.org> => To Peter Vereshagin : RB> On Mon, Dec 3, 2012 at 9:06 AM, Peter Vereshagin <pe...@vereshagin.org>wrote: RB> RB> > Hello. RB> > 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> > RB> > I think it's about a standard for the program interface that majority of RB> > debuggers should follow. RB> > RB> 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> > RB> 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 RB> specific. 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> > RB> > I don't patch the debugger, sorry. RB> > 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> > RB> That said, of course, all of this is cool. RB> > RB> > Great. RB> > RB> > My main target with Debug::Fork::Tmux was to make a convinient build RB> > environment, including docs, for better and faster releasing. RB> > RB> > Otherwise the one can use a couple of lines to use Tmux for that same RB> > purpose. RB> > 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 1.6+ RB> > RB> > RB> > RB> > http://search.cpan.org/dist/Debug-Fork-Tmux -- Peter Vereshagin <pe...@vereshagin.org> (http://vereshagin.org) pgp: A0E26627
