Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Forking the Perl debugger - which version?

by LanX (Bishop)
on Jun 11, 2013 at 17:11 UTC ( #1038290=perlquestion: print w/replies, xml ) Need Help??
LanX has asked for the wisdom of the Perl Monks concerning the following question:


I wanna fork the perldebugger for my IPL project, but I'm not sure which current version / distribution to build on.

The current version takes the 5.10 debugger which should be to old.

I've been told that there were some efforts taken to make the code more strict which broke compatibility.

What would be a good compromise between new and stable?

Cheers Rolf

( addicted to the Perl Programming Language)

PS: No I don't think that directly patching is a good idea, I don't wanna bother about compatibility issues of a small minority and leave it to the user which version to use... (at least in a transition phase)

  • Comment on Forking the Perl debugger - which version?

Replies are listed 'Best First'.
Re: Forking the Perl debugger - which version?
by rockyb (Scribe) on Jun 12, 2013 at 03:13 UTC

    I have a couple of misgivings about this that go off in a couple of diverging directions.

    If what you want to do is just give some sort of entertaining talk, sure. I wonder though if it might also be interesting to discuss and build on some of the existing non-dead-end avenues and might have a more lasting impact outside of a talk.

    There are two existing REPL's that I know of: Devel::REPL which is more like Ruby's irb, and psh which is more for like a Perl replacment for a POSIX shell.

    Installing Devel::REPL from CPAN pulls in lots of stuff including Moose which may be off-putting to some. But on the other hand, it may very well not be a problem for those who are writing Perl using modern OO Perl style. Those people may either already have it installed or want it installed. Some may simply decide to get Moose via their OS distribution mechanism.

    But while Devel::REPL pulls in lots of other modules, psh does not.

    So the first question: have you have considered contributing to one of these projects instead of going off in yet another direction?

    And this leads me to the other aspect of this endeavor I think saddening: yet another (largely dead-end) extension of perl5db. perl5db is what I'd use as a negative advertisement for the Perl language.

    Have you considered extending Devel::Trepan for a command-line debugger (which seems to be what you want here) or Devel::hdb for an HTML REST service debugger? Both of these are much more modular and come with tests.

    And for having expressions evaluated, have you seen my wiki entry on how expressions are handled in Devel::Trepan?

    Good luck with your talk.

      My project is about building a REPL and maybe a shell on top of the debugger w/o breaking compatibility (well preferably not too much). It's not about debugging.

      And my talk was already in 2012.

      You should know, we already discussed: Re^3: How to do perl -c inside perl?

      Good luck with your project! =)

      Cheers Rolf

      ( addicted to the Perl Programming Language)

      ) I recognized your discussion style!

        I confess, I'm absent minded and make lots of mistakes. That's one reason I work on debuggers!

        I clicked on the IPL link and saw the talk and didn't look at the date carefully. Sorry.

        But I still come back the key nagging question, why keep pursuing this rather than incorporate it into one of the existing REPLs or more modern debuggers which can function as a REPL?

        Lastly, although the sub ... trick is a clever hack, it is still a hack. Better would be to do something to more directly attack parsing which — yes I know — is hard.

        But for the use you describe, it doesn't have to be perfect, and basing off of some sort of more sound framework (such as via some sort of parsing technology) it could incrementally get better in a non-hacky way for the kind of thing you want to do. And could be used for other things too.

        Or instead of using some new different parsing technology, you could really start with Perl's parser (and related system) and strip it down. Sort of like what's going on with the sub hack but you have more control over everything.

Re: Forking the Perl debugger - which version?
by Anonymous Monk on Jun 12, 2013 at 03:15 UTC
Re: Forking the Perl debugger - which version?
by Anonymous Monk on Jun 12, 2013 at 05:21 UTC
    I am in favor of tkdb,
    it is pure-perl single file debugger that depends on Tcl::Tk and is an improvement of ptkdb

      I am in favor of tkdb, it is pure-perl single file debugger that depends on Tcl::Tk and is an improvement of ptkdb

      In what way is it an improvement, what's better?

Re: Forking the Perl debugger - which version?
by pemungkah (Priest) on Jun 13, 2013 at 03:44 UTC

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1038290]
Approved by marto
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2018-06-23 23:58 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.