develooper Front page | perl.perl5.porters | Postings from May 2013

[perl #118185] perl debugger doesn't evaluate user input when it should

Thread Previous | Thread Next
From:
Linda Walsh via RT
Date:
May 27, 2013 14:59
Subject:
[perl #118185] perl debugger doesn't evaluate user input when it should
Message ID:
rt-3.6.HEAD-2650-1369666772-391.118185-15-0@perl.org
On Sun May 26 23:40:41 2013, smylers@stripey.com wrote:
> > For simple structures, I find P to be more clear.
> 
> Except that what I suggested wasn't x %a, but x \%a.
Sorry, I understand why and brainblanked it.

Still:
DB<52> $a={1=>2, 3=>4, 5=>6}
  DB<53> x $a                 ## $a already contains a reference
0  HASH(0x1713368)
   1 => 2
   3 => 4
   5 => 6
Vs.
 DB<55> P("%s", $a);0
{1=>2, 3=>4, 5=>6}


> 
> The documentation of x in perldebug also recommends the backslash, and
> it mentions configuration options available for controlling the
> formatting -- so you can have output all on one line.
----
That the only thing I can think of.  Mine was designed for debug and
devel in mind, so the defaults are more compact than anything
Data::Dumper can come up with -- they are not 'beautiful', just as
compact as can be -- though I did add spaces after the commas in a list.

Given the application, having to configure specific options to get
minimal output is something that might be rethought?  

I must note, it wouldn't exactly be a "drop in place" -- as it wasn't
designed for this purpose -- like it wasn't designed to expand it's
first argument (expecting it to be a format statement), but I think I
might change that in the name of having more intelligent defaults.

Since P operates much like printf (or sprintf, or say), you could format
the information and send it to a file descriptor,   or you could print
directly from the file descriptor (obviously a debug thing, as it would
likely mess up the real program reading its input! ;-))...

It isn't even close to trying to be a Pretty Data Dumper routine.

I think it's something that would be used in place of 'p', since 'x' is
a data dump format, not so much a printf like output.  It does have the
ability to vary the recursion, but since the command is usually used as
a function not an object, it feels a bit unnatural to call it as an
object (which is when you can vary the recursion level)...

I think I would use it in place of 'p' if it was better adapted to the
debugger (having to type a format statement, and make sure it's eval'ed
in void context is a bit strained for a good UI design.  But the null
context is useful in program writing... it acts like sprintf if it
detects 'wantarray' as defined, so it can be used as a formatting drop
in for other commands -- I often use it on 'die' lines when I need
formatting that won't die (sprintf chokes on undefs)..

Also, noticed a different problem...

Have an array in one program call USER::Constants with the
values:
 DB<73> P("%s", \@USER::Constants);0
["Phi", 'Φ', "phi", 'ɸ', "pi", 'π', 'e', 'c', 'g']

Trying to print that with p:
  DB<74> p \@USER::Constants
ARRAY(0x18e3378)
  DB<75> p @USER::Constants 
Wide character in print at (eval
407)[/usr/lib/perl5/5.16.2/perl5db.pl:646] line 2, <$histfile_h> line 596.
        eval '($@, $!, $^E, $,, $/, $\\, $^W) = @saved;package main; $^D
= $^D | $DB::db_stop;
print {$DB::OUT}  @USER::Constants;

;' called at /usr/lib/perl5/5.16.2/perl5db.pl line 646
        DB::eval called at /usr/lib/perl5/5.16.2/perl5db.pl line 3248
        DB::DB called at /usr/bin/pcalc line 498
Wide character in print at (eval
407)[/usr/lib/perl5/5.16.2/perl5db.pl:646] line 2, <$histfile_h> line 596.
        eval '($@, $!, $^E, $,, $/, $\\, $^W) = @saved;package main; $^D
= $^D | $DB::db_stop;
print {$DB::OUT}  @USER::Constants;

;' called at /usr/lib/perl5/5.16.2/perl5db.pl line 646
        DB::eval called at /usr/lib/perl5/5.16.2/perl5db.pl line 3248
        DB::DB called at /usr/bin/pcalc line 498
Wide character in print at (eval
407)[/usr/lib/perl5/5.16.2/perl5db.pl:646] line 2, <$histfile_h> line 596.
        eval '($@, $!, $^E, $,, $/, $\\, $^W) = @saved;package main; $^D
= $^D | $DB::db_stop;
print {$DB::OUT}  @USER::Constants;

;' called at /usr/lib/perl5/5.16.2/perl5db.pl line 646
        DB::eval called at /usr/lib/perl5/5.16.2/perl5db.pl line 3248
        DB::DB called at /usr/bin/pcalc line 498
PhiΦphiɸpiπecg
---
with x:
  DB<76> x @USER::Constants
0  'Phi'
1  '\x{03A6}'
2  'phi'
3  '\x{0278}'
4  'pi'
5  '\x{03C0}'
6  'e'
7  'c'
8  'g'


> What is it that your proposed P command does that the debugger doesn't
> already provide?
----
I was comparing it to the 'p' command which doesn't check for
undef's and apparently doesn't deal with Unicode very well, as it's
a print operator.  I wouldn't often use a dump operator in an
interactive debug session (usually too much output -- have to send it to
a file and filter it or something)...

It was more an off the cuff remark -- since when 'p' gets output it
doesn't like, it really tells you about it... ;-)

If I used the debugger more, I think adding auto-completion for symbols
would be neat.  But given howmuch I use it...

At this point the main issues are it eating up the 'P' command and
generating a fatal error that kills a debug session -- and there seem to
be problems with unicode(use utf8 is in the source of the program, so
shouldn't be a surprise to the debugger.

Also fixing the stdout of the debugger when it is in 'non-stop-mode'
helps in seeing what is being done, though there are so many library
calls that expand in to many lines, that tracing output is of limited
usefulness.

Something I did with a tracing option in one of my debug modules -- 
by default, I don't show and skip through any modules located under
/usr.  Rational being that I wouldn't usually develop there -- and those
are mostly the 'system libraries'...   Only if I needed to debug a
module there -- in place, would I need to change the defaults.

Would something like that be appropriate for the autotrace?






---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=118185

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About