[Israel.pm] Perl and Debugging question
Gaal Yahas
gaal at forum2.org
Tue May 15 10:10:53 EEST 2007
Sure, but that has intrusive semantic implications! For instance, the
member is read-only, and taking a reference to it can cause a memory
leak if you implement writes by replacing the closure. If you really
want to go this route you may want to check out Inside Out objects
(viz., Class::InsideOut). If this was just so that you get nicer
output in the debugger...
FWIW, I know about ebug and I think it's neat, but I don't think it
solves your problem completely, either. And in response to Shlomi, I
wasn't suggesting not doing anything until Perl 6 arrives; you can get
important aspects of it today in Perl 5 by using Moose. Perhaps
Moose+ebug=love; worth looking into.
On 5/15/07, Peter Gordon <peter at pg-consultants.com> wrote:
> An opaque value does the trick:
>
> Hide the value in a subroutine
> $self->{getValue} = sub { return $value } ;
>
> Get the value:
> $value = &{$self->{getValue}} ;
>
>
> And in the debugger, all you get is:
> 'getValue' => CODE(0x87c8388)
> -> &ABC::__ANON__[../ABC.pm:31] in ../ABC.pm:31-31
>
>
> And thanks for the pointer to ebug.
>
> Peter
>
> On Mon, 2007-05-14 at 15:59 +0300, Shlomi Fish wrote:
> > Hi Peter!
> >
> > On Monday 14 May 2007, Peter Gordon 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.
> >
> > Wait for Perl 6 which will be a whole new ball game just for a better
> > debugger? Get real. At the moment, as far as I know, Pugs and Parrot don't
> > have any debuggers at all.
> >
> > It is possible to write a better debugger for perl 5 see Devel::ebug for
> > instance:
> >
> > http://search.cpan.org/dist/Devel-ebug/
> >
> > And you can always refactor the existing debugger into shape if the need
> > arises.
> >
> > Regards,
> >
> > Shlomi Fish
> >
> > >
> > > 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
> >
> >
> >
> > --
> >
> > ---------------------------------------------------------------------
> > Shlomi Fish shlomif at iglu.org.il
> > Homepage: http://www.shlomifish.org/
> >
> > If it's not in my E-mail it doesn't happen. And if my E-mail is saying
> > one thing, and everything else says something else - E-mail will conquer.
> > -- An Israeli Linuxer
>
> _______________________________________________
> 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