Re: What is the history behind the DB module?
Indeed. You have to remember that just because some of us *like* using the debugger, many people do not. And there is a special kind of snobbery involved, something along the lines of: Oh, so you NEED to use the debugger, do you? Should be read aloud with raised eyebrows ;-) -- Ciao Richard Foley http://www.rfi.net/books.html On Fri, Sep 14, 2012 at 10:47:16AM +0300, Shlomi Fish wrote: Hi Rocky, On Thu, 13 Sep 2012 19:40:53 -0400 Rocky Bernstein rocky.bernst...@gmail.com wrote: http://perldoc.perl.org/DB.html mentions a programmatic interface to the Perl debugging API. As far as I can tell it hasn't really changed at all since Perl 5.8 and not much between that and 5.6 except bug fixes. Why was this not more widely adopted? I guess not too many people need to write custom debuggers. Furthermore, it seems that many Perl developers avoid using the debugger in favour of print statements and other stuff like that. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ What Makes Software Apps High Quality - http://shlom.in/sw-quality Quark: “Too much of a good thing is a bad thing. But only for your customers”. Rule of acquisition No. 172. — Star Trek, “We, the Living Dead” by Shlomi Fish Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: accelerated stepping
On Friday 29 August 2008 19:28:08 Heiko Ei�feldt wrote: To Richard: Afterwards I realized, $DB::single is to be used as a bitmask. So it would be 8 instead of 3, since 4 is already taken. Details, details ;-) The only difference should be the execution of grep/map/sort/... I either use 's' to do small steps or use 'n' with the intention to do bigger steps. But currently I cannot get this behaviour. It is not exactly what is documented, but this is what my expectation is (silly me). heretic mode off If you mean: 1. n - next step over everything (including grep/map/sort). 2. s - step into everything (including grep/map/sort). 3. forget nn and N. Then I would think this would be (mostly very) intuitive change, and the behaviour (most) people would expect from the debugger, most of the time. You'd have to check for unwarranted side effects of course, such that blocks other than single-line grep, map and sort, remain unaffected, but otherwise it seems to me to be a good idea. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: Unreliable breakpoint path specification
On Wednesday 06 June 2007 19:59, Jan Ploski wrote: What would be the best way to suggest an API extension to perl5db.pl maintainer(s)? The best thing is probably to send a patch to P5P and let them take a look at it. Ok, in that case I'd have to generalize my on load hook first to make it independent from EPIC. I'm not familiar with EPIC, but there are a number of cases where the debugger has been quite literally hacked to work with various OS's, terminals, certain libraries and so on. In these cases a sensible solution has often been to seperate the specific stuff via an environment variable. This only applies, of course, if it has no value for other users. Something like PERL5DB_EPIC=1 might do the trick, although you might very well have a more suitable suggestion. Then send a patch to p5p for Rafael to consider applying it to bleed. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: Debugger Doesn't Show Program Lines
On Friday 04 May 2007 16:17, Nelson R Pardee wrote: I found that the combination of -w -d didn't work. But if I did use warnings with -d, the problem went away. I don't think that's what's supposed to happen, but it's a usable workaround. And 5.8.x had the same problem, I believe. Spooky. Have you filed a bug report yet? -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/ ps. Please resend any bounced or unanswered emails.
Re; debug a script for Sendmail::Milter
Dirk, It looks like the Milter module was relocated from another Perl installation, hence the message. Possibly the SuSe installation or the Sendmail installation, or you, are using differing Perl versions? Ciao Richard Foley --- Ciao - Shorter than Aufwiedersehen http://www.oreilly.com/catalog/perldebugpr/index.html From: Dirk Tamme Subject: debug a script for Sendmail::Milter Date: Tue, 20 Apr 2004 00:06:03 -0700 Hello, I have a problem with the Perl-Modul Sendmail::Milter. I have ( using SuSE Linux 8.1 ) sendmail 8.12.11, which includes the Milter interface. What I have done to install Sendmail::Milter is cd /usr/local/src/Sendmail-Milter-0.18 perl Makefile.PL /usr/local/src/sendmail-8.12.11/obj.Linux.2.4.19-4GB.i686/ make make install Now I tested a script given in www.tpj.com/documents/s=7178/sam0206l/ http://www.tpj.com/documents/s=7178/ sam0206l/ Because there occurs an error, I used the debug option #! /usr/bin/perl -d What I found out is that the line if (not Sendmail::Milter::auto_setconn($ARGV[0], $ARGV[1])) gives me the error mesage /usr/bin/perl: relocation error: /usr/lib/perl5/site_perl/5.8.0/ i586-linux-thread-multi/auto/Sendmail/Milter/Milter.so: undefined symbol: smfi_setconn The Perl-script starts with use Sendmail::Milter; so the Package should be included. If anybody has an idea, please help. Yours Dirk Tamme debug a script for Sendmail::Milter, Dirk Tamme
