Tmux helps to debug perl fork()s

[Richard Foley]

Here is an interesting module from Peter Vereshagin which might help with
debugging forks under the perl debugger, if you use tmux version 1.6+

http://search.cpan.org/dist/Debug-Fork-Tmux

--
Ciao

Richard Foley

http://www.rfi.net/books.html

[Rocky Bernstein]

Something I think about when I read about things like this whether there
some sort of unifying principle that could be used in other debuggers or
for other similar sorts of programs. Is there some support that a debugger
should be providing to make things like this easier?

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

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

[Rocky Bernstein]

On Mon, Dec 3, 2012 at 9:06 AM, Peter Vereshagin <pe...@vereshagin.org>wrote:

> Hello.
>
> 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.
>

I'm not sure what you mean. Suggest something.

>
> 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.
>

Devel::Trepan has lots of non-DB spaces one can tweak to. But again, I am
not exactly sure what you mean so it would help if you could be very
specific.



>
> 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
> them?
>
> RB> That said, of course, all of this is cool.
>
> Great.
>
> 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
>

[Richard Foley]

You're welcome, Peter, it's a quiet list, but there are some debugger relevant
people on it ;-)

--
Ciao

Richard Foley

http://www.rfi.net/books.html

On Mon, Dec 03, 2012 at 03:11:34PM +0400, Peter Vereshagin wrote:
> Hello.
>
> 2012/12/03 10:34:27 +0100 Richard Foley <richar...@rfi.net> => To debu...@perl.org :
> RF> Here is an interesting module from Peter Vereshagin which might help with
> RF> debugging forks under the perl debugger, if you use tmux version 1.6+
> RF>
> RF> http://search.cpan.org/dist/Debug-Fork-Tmux
>
> Thank you very much Richard for your announce!
>
> The latest development (v1.000010 currently) is at:
>
> http://gitweb.vereshagin.org/Debug-Fork-Tmux/README.html
>
> The latest Changes are:
>
> Searching for tmux binary (in PATH) and perl-5.8.9 minimum (in POD)
>
> Keeping at sight the things to improve (have them recorded).
>
> There is a GitHub page, too:
>
> https://github.com/petr999/Debug-Fork-Tmux
>
> v1.000010 isn't yet on CPAN cause I always think twice before. This was just
> the case and I'd like to redo the feature a bit.
>
> If anyone is about to v1.00010 or any other version from Git then I should let
> know here that still on the list 'the missing test files from MANIFEST' bug:
> find them all in CPAN archive as they are all the same each time.
>
> RF> http://www.rfi.net/books.html

[Peter Vereshagin]

[Peter Vereshagin]

Hello.

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
them?

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

Great.

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]

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+