[Israel.pm] Perl and Debugging question

Gaal Yahas gaal at forum2.org
Mon May 14 13:07:29 EEST 2007


Well then. My only appropriate response here could be "haha, pwned" :-)

What I'm advocating is to put "how to print me" responsibility in the object,
not the printer. You're obviously familiar with the debugger
internals, you know it's
possible but not very enjoyable to put it there; I think that even if
it were easier then the manipulation would have been cleaner had it
gone through an API that wasn't debugger-specific.

On 5/14/07, Peter Gordon <peter at pg-consultants.com> wrote:
> If you have a look it dumpvar.pl, you will find my name there. Once upon
> a time, during the birth pangs of Perl 5,  I did bang my head against
> it.
>
> I agree with you that the debugger is a Real Mess (tm) and hopefully in
> Perl 6 it will be a lot nicer.
>
> Another way would be make an opaque object so that the values don't get
> dumped down.
>
> Peter
>
>
> On Mon, 2007-05-14 at 09:30 +0300, Gaal Yahas wrote:
> > I disagree on both counts. :-)
> >
> > Simplicity isn't one of the best descriptions of the debugger code.
> > (By which I mean
> > the actual debugger, perl5db.pl.) I mean sure, you could tweak around lines:
> > 2434
> > 654
> > 5547
> >
> > But you'd still have to bang your head against dumpvar.pl.
> >
> > And how to make the interface for it? Just hardcode some arbitrary
> > limit? Yet another config option? What happens when your members are
> > actually tied scalars that when read do some expensive operation like
> > compute a value or read from the network? Maybe you want to skip those
> > fields too... How?
> >
> > If what guides you is a sense that debuggability features don't seem
> > clean to leave in production code, I hear you, but consider that they
> > would be implemented in a separate unit of modularity (a Role, in the
> > case of Perl 6) and have declarative, thus uncluttering,
> > configuration. Incidentally, in Perl 6 Roles can be composed at
> > runtime, so your production program has absolutely no trace of this
> > filterable dumpage, until you drop into the debugger and add it to a
> > particular instance. Then you also have a consistent interface to mess
> > around with its properties.
> >
> > On 5/14/07, Peter Gordon <peter at pg-consultants.com> wrote:
> > > It might be simpler and more consistent to add an option to the debugger
> > > itself.
> > >
> > > On Sun, 2007-05-13 at 21:50 +0300, Gaal Yahas wrote:
> > > > On 5/13/07, Peter Gordon <peter at pg-consultants.com> wrote:
> > > > > On this occasion, one of the elements is a string a few megabytes long,
> > > > > and I don't really want to dump the whole string.
> > > > >
> > > > > What would be the nicest way to suppress printing of this particular
> > > > > element.
> > > > >
> > > > > I could print each element in turn, but that is inelegant.
> > > >
> > > > I'm afraid I don't have an elegant solution to offer. (A related
> > > > problem that does
> > > > have debugger support is deeply recursive structures. Saying "x 3
> > > > $that" limits to
> > > > depth 3 print.)
> > > >
> > > > What you might do -- and I'm not saying this is significantly
> > > > different from printing each element in turn -- is add a to_debug
> > > > method to the object. This copies the object but only leaves a digest
> > > > version of the long string, say with the first 100 characters.
> > > >
> > > > Not that I've searched CPAN for prior art, but you might want to make
> > > > this into a reusable module. (With Moose.pm or Perl 6, it would more
> > > > properly be a Role.) Something like:
> > > >
> > > > package MyModuleWithLongMember;
> > > >
> > > > use Debug::Dump::Digest qw(long_memb1 huge_memb2);
> > > >
> > > > And then in the debugger:
> > > >
> > > > x $self->to_debug;
> > > >
> > >
> > > _______________________________________________
> > > Perl mailing list
> > > Perl at perl.org.il
> > > http://perl.org.il/mailman/listinfo/perl
> > >
> >
> >
>
> _______________________________________________
> Perl mailing list
> Perl at perl.org.il
> http://perl.org.il/mailman/listinfo/perl
>


-- 
Gaal Yahas <gaal at forum2.org>
http://gaal.livejournal.com/



More information about the Perl mailing list