RE: Existing books on debugging ?
The Perl Debugger Pocket Reference: http://www.oreilly.com/catalog/perldebugpr/index.html Ciao Richard Foley --- Ciao - Shorter than Aufwiedersehen
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
rel; script aborts when debugged
Works for me:
[EMAIL PROTECTED]:~/att> perl -d -Mencoding="iso-8859-2" -e 'print "hello
there($$)\n"; print "etc...\n";'
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): print "hello there($$)\n"; print "etc...\n";
DB<1> use encoding ("iso-8859-2");
DB<2> M
'/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/auto/Term/ReadLine/Gnu/XS/autosplit.ix'
=>
'/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/auto/Term/ReadLine/Gnu/XS/autosplit.ix'
'AutoLoader.pm' => '5.59 from /usr/lib/perl5/5.8.0/AutoLoader.pm'
'Carp.pm' => '1.01 from /usr/lib/perl5/5.8.0/Carp.pm'
'Config.pm' => '/usr/lib/perl5/5.8.0/i586-linux-thread-multi/Config.pm'
'DynaLoader.pm' => '1.04 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/DynaLoader.pm'
'Encode.pm' => '1.75 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/Encode.pm'
'Encode/Alias.pm' => '1.32 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/Encode/Alias.pm'
'Encode/Byte.pm' => '1.22 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/Encode/Byte.pm'
'Encode/Config.pm' => '1.06 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/Encode/Config.pm'
'Encode/Encoding.pm' => '1.30 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/Encode/Encoding.pm'
'Exporter.pm' => '5.566 from /usr/lib/perl5/5.8.0/Exporter.pm'
'PerlIO/encoding.pm' => '0.06 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/PerlIO/encoding.pm'
'Term/ReadLine.pm' => '1.00 from /usr/lib/perl5/5.8.0/Term/ReadLine.pm'
'Term/ReadLine/Gnu.pm' => '1.13 from
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/Term/ReadLine/Gnu.pm'
'Term/ReadLine/Gnu/XS.pm' =>
'/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi/Term/ReadLine/Gnu/XS.pm'
'XSLoader.pm' => '0.01 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/XSLoader.pm'
'base.pm' => '1.03 from /usr/lib/perl5/5.8.0/base.pm'
'encoding.pm' => '1.35 from
/usr/lib/perl5/5.8.0/i586-linux-thread-multi/encoding.pm'
'perl5db.pl' => '1.19 from /usr/lib/perl5/5.8.0/perl5db.pl'
'strict.pm' => '1.02 from /usr/lib/perl5/5.8.0/strict.pm'
'vars.pm' => '1.01 from /usr/lib/perl5/5.8.0/vars.pm'
'warnings.pm' => '1.00 from /usr/lib/perl5/5.8.0/warnings.pm'
'warnings/register.pm' => '1.00 from
/usr/lib/perl5/5.8.0/warnings/register.pm'
DB<2> c
hello there(3653)
etc...
Debugged program terminated. Use q to quit or R to restart,
use O inhibit_exit to avoid stopping after program termination,
h q, h R or h O to get additional info.
DB<2> q
[EMAIL PROTECTED]:~/att>
re; core dump
I think I would contact the webmin people to see if they can help, first. -- Richard Foley --- core dump whitevamp Sat, 27 Nov 2004 16:34:23 -0800 im not sure if this is the right place to list this .. im running webmin or trying to and when i goto start it IE: /usr/local/webmin-conf/config-files-logs/webmin/start i get the following error Starting Webmin server in /usr/local/webmin Segmentation fault (core dumped) and i have posted a thred at webmin.com and they said that it was not a issue with webmin but a issue with perl http://sourceforge.net/tracker/index.php?func=detail&aid=1073942&group_id=17457&atid=117457 ohh and my sys is as follows fbsd: 4.9 perl: This is perl, v5.8.5 built for i386-freebsd-64int if im not in tthe right place can u point in in the right direction.. and thx inadvance for any help --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.802 / Virus Database: 545 - Release Date: 11/26/2004
Re: re; core dump
perl5-porters@perl.org would be the next best place, I would think. Use the perlbug program to report what you think is a perl bug and go from there. You can see previous bugs, maybe yours is there a this URL: http://rt.perl.org/perlbug/ Richard. From: "whitevamp" <[EMAIL PROTECTED]> on 08-02-2005 09:14 PST To: "Richard Foley" <[EMAIL PROTECTED]> cc: Subject: Re: re; core dump thats where i first whent and they said that it was a perl issue please see http://sourceforge.net/tracker/index.php?func=detail&aid=1073942&group_id=17457&atid=117457 - Original Message - From: "Richard Foley" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Tuesday, February 08, 2005 2:34 AM Subject: re; core dump >I think I would contact the webmin people to see if they can help, first. > > -- > > Richard Foley > > --- > > core dump > whitevamp > Sat, 27 Nov 2004 16:34:23 -0800 > > im not sure if this is the right place to list this .. > im running webmin or trying to and when i goto start it > IE: /usr/local/webmin-conf/config-files-logs/webmin/start > > i get the following error > Starting Webmin server in /usr/local/webmin > Segmentation fault (core dumped) > and i have posted a thred at webmin.com and they said that it was not a > issue with webmin but a issue with perl > http://sourceforge.net/tracker/index.php?func=detail&aid=1073942&group_id=17457&atid=117457 > > ohh and my sys is as follows > fbsd: 4.9 > perl: This is perl, v5.8.5 built for i386-freebsd-64int > > if im not in tthe right place can u point in in the right direction.. > > and thx inadvance for any help > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.802 / Virus Database: 545 - Release Date: 11/26/2004 > > >
Re: Different output when run from the debugger vs. the command line
I don't see this at all using 5.8.5 on Linux. > cat db.pl #!/usr/bin/perl use Config qw(myconfig); print Config->myconfig; 1; > perl db.pl > ordinary.output > perl -d db.pl > debugger .output Loading DB routines from perl5db.pl version 1.27 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(db.pl:3): print Config->myconfig; DB<1> c Debugged program terminated. Use q to quit or R to restart, use O inhibit_exit to avoid stopping after program termination, h q, h R or h O to get additional info. DB<1> q > diff ordinary.output debugger > No difference at all. Richard Foley Different output when run from the debugger vs. the command line Shimon Bollinger Mon, 15 May 2006 04:40:02 -0700 When I run the following script from the command line, I get different output than when I run it with the debugger. #!/usr/bin/perl use Config qw(myconfig); print Config->myconfig; 1; Here is the relevant differences in the output: >From the debugger: uname='linux lxcert-i386.cern.ch 2.4.21-27.0.2.el.cernsmp #1 smp thu jan 20 01:37:09 cet 2005 i686 i686 i386 gnulinux ' >From the command line: uname='linux lxc' Why would this happen? Perl and OS Info: This is perl, v5.8.0 built for i386-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Linux localhost.localdomain 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux
Attaching a debugger to a file being eval'd?
Doug,
This should be no problem.
If 'hello.pl', the file which includes the code to be called, looks like this,
(note the $DB::single=2):
#!/usr/bin/perl
print "Hello";
$DB::single=2;
print "World";
print "\n";
And 'wrapper.pl', the file you are calling from, looks like this:
#!/usr/bin/perl
my $filename = "hello.pl";
eval "do '$filename'";
Now you call the debugger, and your first command is 'c' (continue):
$> perl -d wrapper.pl
Loading DB routines from perl5db.pl version 1.28
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(wrapper.pl:3): my $cmd = "do './hello.pl'";
DB<1> c
Hellomain::(./hello.pl:7): print "World";
DB<1> l
7==>print "World";
8
9: print "\n";
10
DB<1>
What's the problem, or have I missed something? I've just tried it with ptkdb
too, and that works fine, (stopping at the $DB::single line), also:
$> perl -d:ptkdb wrapper.pl
...
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
> Mon, 08 Jan 2007 14:07:34 -0800
> Hi all,
>
> I am running VMS perl 5.8.6. I am using persistent perl and am eval'ing a
file.
>
> The problem is, sometimes I want to eval the file to debug it. To make
matters
> worse, I need to use ptkdb to do the debugging.
>
> I've tried the obvious things like putting perl -d:ptkdb into the first line
of
> the file, and putting "use Devel::ptkdb" into PERL5LIB and PERLDBOPT all to
no
> avail.
>
> Is this even possible?
>
> Thanks in advance,
>
> -Doug
>
> Code snippet follows:
>
>
> ...{
> local *FH;
> open FH, $filename or die "open '$filename' $!";
> local($/) = undef;
> my $sub = ;
> close FH;
>
> #wrap the code into a subroutine inside our unique package
> my $eval = qq{package $package; sub handler { $sub; }};
> {
> # hide our variables within this block
> my($filename,$mtime,$package,$sub);
> eval $eval;
> }
> die $@ if $@;
>
> #cache it unless we're cleaning out each time
> $Cache{$package}{mtime} = $mtime unless $delete;
> }
>
> eval {$package->handler;};
> die $@ if $@;
>
Re; debugging threaded application
Khai, You could try using the debugger threads support (-dt): $> perl -dt threadedprogram.pl Hopefully this helps? > Tue, 23 Jan 2007 16:34:43 -0800 > I've written a threaded application using perl 5.8.5 with ithreads. The application runs as daemon, and sometimes it hangs. How should I go about debugging this? > > Thanks > Khai Doan -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/ ps. Please resend any bounced or unanswered emails.
re: Debugger Doesn't Show Program Lines
Perhaps it's a problem with 5.6.1, have you tried a more recent version of Perl, like 5.8.n? -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/ ps. Please resend any bounced or unanswered emails. > In-ReplyTo: [EMAIL PROTECTED] > > We're upgrading from an old 5.005_03 to v5.6.1. Now when I use -d on > via the first line of the program, it starts in debug mode but no lines of > the program are visible & they are unlistable. If I do an R, then they are > visible. <Perl -d pgmname> doesn't have this problem. > > We're also running into problems reading stdin, and nntp complains about > Can't call method "post" on an undefined value at eg.pl line 1607. The > script runs fine under the old version of perl. > > Thanks in advance for help. > > Nelson > > --Nelson R. Pardee, Support Analyst, Information Technology & Services-- > --Syracuse University, CST 4-191, Syracuse, NY 13244 -- > --(315) 443-1079 [EMAIL PROTECTED] --
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: Debugger Doesn't Show Program Lines
On Friday 04 May 2007 17:10, Nelson R Pardee wrote: > I don't even know how to file a bug report, and right now this problem > is "ages" ago in terms of projects:-) > Well, for the next one, just run perlbug :-) -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/ ps. Please resend any bounced or unanswered emails.
Re: Unreliable breakpoint path specification
On Monday 04 June 2007 16:45, Jay Rifkin wrote: > Hi Jan - > If you have write access to the "require"d file, you can try setting a > breakpoint in it, via setting: > $DB::single = 1 > Good idea. Without modifying the source code you could try setting a breakpoint on a subroutine: b foo::mysubname You could also use a watch variable, if you have a suitable variable available in the file you wish to debug, something like this perhaps: w $foo::myvarname > I am now considering throwing away perl5db.pl or rewriting significant > portions of it. > Before you try rewriting the debugger from scratch, you might like to look at the output of the help for breakpoints, which you can access from within the debugger like this: h b As you might expect, TMTOWTDI. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: Unreliable breakpoint path specification
On Tuesday 05 June 2007 19:25, Jan Ploski wrote: > > Thank you for your suggestions. > Did "b subname" not work? > In the end, I solved my problem by patching up perl5db.pl to call back > a user-defined routine on *every* loaded file from sub DB::postponed. > Are there any potential side-effects for other users? > The downsides are the possibly unreliable patching and > If it's unreliable, (your word), then you should keep the patch on your local system, please. If it's reliable, then it might be a useful fix. Is it possible to make a test case for it? > the fact that I now depend on perl5db.pl internals. > I don't know whether Devel::Command would have been useful to you? > 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. -- 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: accelerated stepping
Hi Heiko,
> I could imagine $DB::single can be set to 3 for this 'accelerated'
> stepping.
>
It's a good idea.
> May I reserve the capital N for that command?
>
Nearly :-)
I only mean you could use either 'nn' or 'N', equally. To be honest, the
former appeals a little more as an extention to the existing command, while
the latter seems to be a bit more distinct, although I don't actually have
another suggestion for the latter at the moment either. If you implement it
though, I suspect you can use any letter you choose, certainly at first...
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
On Wednesday 27 August 2008 21:33:25 Heiko EiÃfeldt wrote:
> Hi,
>
> often during single-stepping I am missing a command like 'n' to step
> over not only subroutine calls, but also complete map and grep-commands.
>
> Example:
>
> Instead of
>
> main::(perldb_demo.pl:4): my @a = (1..10);
> DB<1> n
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:7): print "found\n";
>
> I would like to use
>
> main::(perldb_demo.pl:4): my @a = (1..10);
> DB<1> N
> main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
> DB<1>
> main::(perldb_demo.pl:7): print "found\n";
>
> How could that be done?
>
> I could imagine $DB::single can be set to 3 for this 'accelerated'
> stepping.
>
> May I reserve the capital N for that command?
>
> Thanks,
> Heiko
> --
>
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). > > 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: accelerated stepping
On Saturday 30 August 2008 22:21:34 Heiko Ei�feldt wrote:
>
> > 1. n <- next step over everything (including grep/map/sort).
> >
> > 2. s <- step into everything (including grep/map/sort).
> >
>
> Ok, here is what I did, patch is against Perl 5.10.0.
> Please review, thanks. My simple tests worked so far.
>
From an initial look at it, it looks good to me, (and works nicely ;), too.
Just one thing, you might need to change the regex:
if ( $dbline[$line] =~ m{\bgrep\b}xms
|| $dbline[$line] =~ m{\bmap\b}xms
|| $dbline[$line] =~ m{\bsort\b}xms
) {
to handle join and reverse as well:
if ( $dbline[$line] =~ m{
\b(grep|join|map|reverse|sort)\b
}xms ) {
Maybe try a few single- and multi-line variations and, if it still looks good,
submit a proposed patch to p5p?
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
Re: accelerated stepping
On Monday 01 September 2008 22:50:53 Heiko wrote:
>
> > \b(grep|join|map|reverse|sort)\b
>
> So I think I will take your proposal and will leave out 'join' and
> 'reverse'.
>
Ok.
> I also checked
> s expr
> and
> n expr
>
Good to hear :-)
> BTW:
> with the definition
> sub x1 {
> my $arg = shift;
> return reverse unpack "(a)*", $arg; }
>
> if I single step through an expression
> like this
> s @x = x1('blabla')
> s
> s
> ...
> (up to the end of function x1)
> I never see the returned result. Neither in the debugger output,
> nor in the variable @x. That is, when I do afterwards
> x [EMAIL PROTECTED]
> the array is empty.?!?!?
> (ok, I just see, it is not empty, if @x has been used before,
> what a weird behaviour, what is going on??? :-)
>
Maybe it's a localisation issue?
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
Re: accelerated stepping
On Thursday 04 September 2008 21:33:41 Heiko Ei�feldt wrote:
> Hello Richard,
>
> I discussed this topic and patch on PerlMonks, and got a general
> agreement, that the patch would have great merit.
>
Hi Heiko,
Good to hear that - I found the thread and appended my half'pen'th.
> New Plan
>
> So I would like to make a patch now, that will have 'n' short cut for
> ANY code block, not only subroutines. And that should be done without a
> regexp.
>
Hmmm, yes but there's always exceptions... consider arriving at the following
pseudocode under the debugger:
{
code1;
code2;
code3;
}
code4;
Do you want to step over all the three code lines above with 'n'? Probably
not if it's just a way of controlling lexical variables, for example, you
would be expecting to step to the next statement (code1) rather than leap
over to code4. I'm not sure what the solution is, but as you can see from the
various comments, it's never quite as simple as it might seem at first.
Possibly because it's Perl, there's just SMWTDI (so many ways to do it), that
these kind of edge cases can become quite problematic.
> the special treatment of 'n' regarding subroutines only needs to be extended
> to general code blocks like those in grep/map/sort, ...
>
It's perl which provides the hook for the debugger, calling DB::sub on each
subroutine, just as DB::DB gets called for each line, so I'm not sure how
easy it's going to be to extend that handling for map{} and grep{} and sort{}
blocks, unless you modify Perl's source too. You may still have to emulate
it in the way you started to...
> Help is of course very much appreciated!!
>
If I can help, I'll be happy to do so.
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
Fwd: Debug Perl embedded in irssi
Perhaps p5p will have an opinion...? -- Forwarded Message -- Subject: Debug Perl embedded in irssi Date: Tuesday 20 January 2009 From: Wouter Coekaerts To: debugger@perl.org Hi, Irssi is an IRC client using Perl for scripting. I'm trying to attach a debugger to its embedded Perl. I'm using PERLDB_OPTS="RemotePort=127.0.0.1:5000" to let it connect to a socket. Running and debugging a perl script started in the "normal" way works fine: "perl -d -e 0" connects to the socket and I can control the debugger from there. Now I changed irssi so that the arguments it passes to perl_parse and PERL_SYS_INIT3 include "-d". Then when starting irssi, it connects to the socket, and prints its usual "Loading DB routines"... "Enter h"... But when I give any command (including "h") it doesn't respond. The irssi (and its Perl scripts) continue to run fine. Someone an idea of what could be going wrong? Thanks. Wouter. --- -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: website update: B::Debugger
Hi Reini, Good idea. I'm forwarding this to Gabor, so he can update the site directly. Cheers. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/ On Monday 18 January 2010 12:16:23 Reini Urban wrote: > Hi > > I have a website update suggestion regarding debugging B modules. > > http://debugger.perl.org/tools.html > > http://search.cpan.org/dist/B-Debugger/";>B::Debugger > Debug B modules and optrees. > > Thanks
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 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 .
Tmux helps to debug perl fork()s
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
Re: Tmux helps to debug perl fork()s
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 => To > debugger@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.10 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.10 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 (http://vereshagin.org) pgp: A0E26627
