Front page | perl.perl5.porters |
Postings from November 2011
RE: [RFC] Can we convert lib/perl5db.pl (= the default perldebugger) to strict and warnings?
Thread Previous
|
Thread Next
From:
Konovalov, Vadim ** CTR **
Date:
November 27, 2011 05:12
Subject:
RE: [RFC] Can we convert lib/perl5db.pl (= the default perldebugger) to strict and warnings?
Message ID:
35BF8D9716175C43BB9D67CA60CC345E2E08232E@FRMRSSXCHMBSC2.dc-m.alcatel-lucent.com
> From: Craig A. Berry
> On Sat, Nov 26, 2011 at 10:19 AM, Ricardo Signes wrote:
> > * Shlomi Fish <shlomif@shlomifish.org> [2011-11-25T07:49:15]
> >> I'm issuing this "request-for-comments" to see if anyone
> can see a good
> >> reason why I (or someone else who volunteers to do that)
> should not convert
> >> "lib/perl5db.pl" (which implements "perl -d") to "use
> strict;" and "use
> >> warnings;"? If everyone is OK with that, then I'd like to
> try doing exactly
> >> that.
> >
> > I'm with Jesse: this sounds most welcome, but *please*
> endeavor to do the work
> > in hunks. (Obviously, the first hunk can't be adding "use
> strict") :)
>
> Sound advice ... which was completely ignored in the patch that ended
> up being submitted.
I very much agreed!
I was offline for several hours, carried these perl5db.pl thoughts with me,
and it became clear to me that this Jesse's idea is actually a real good
something in this particualr case.
Namely, it was suggested from the very start to do a small changes step
by step, which was rejected by Shlomi, he said this is not doable.
I am sure this is not only doable, but actually is the way to go.
Please introduce strict-clean logic step by step, declare variables
and so on, but do not place atual "use strict;" yet.
Also, another idea come to my mind, that these chunks:
- @ret = &$sub;
+ {
+ no strict 'refs';
+ @ret = &$sub;
+ }
are not as innocent as they seem to be.
Not only they trade speed in critical tight loops
(they introduce block and do some action inside and then restoring on leave)
but there is another problem.
They will pollute call stack (some use- stack that was seen by me on
"ptkdb" debugger, I am not an active user of perl5db.pl, so I can not say
much about its stacks, but I believe the situation is similar)
So IMO all these blocks should be introduced more carefully and not in
one go, the speed-critical one should be considered separatedly.
And, Shlomi, according to mentioned by you
http://szabgab.com/what-does--if-it-aint-broke-dont-fix-it--really-mean.html
better test coverage should be implemented so to be more brave in
implementing changes
Can you PLEASE, together with patching in smaller chunks, write proper
tests that covers your newly patched piece?
> Vadim got a bit carried away, but he had serious concerns that I
> don't really think have been addressed. Basically, changes to the
> debugger, even innocent-looking ones, are likely to break something.
> When Dave Mitchell was passing over all debugger changes in the final
> days leading up to 5.10.1, he said, "anything to do with the debugger
> is by definition scary."[1] Anything that scares Dave ought to
> absolutely terrify most everyone else.
also good point.
When I was digging "ptkdb" internals, it was not scary, it was rather
interesting, but I saw a whole bunch of undergoing work and agreements
on debugger protocol that is happening.
This is not too scary when you do things after reading "perldebguts.pod",
but I have strong opinion that things in debugger must be done carefully.
> Here's a real-world example that has cost me an hour or two today. It
> used to be possible to use the debugger in an environment where only
> miniperl has been built and extensions have not been built. That
> doesn't work anymore because a few years ago a dependency on
> Term::ReadLine was added. That probably was ok until sometime later
> when the build directories were moved around so that Term::ReadLine is
> built on the fly, so now the debugger dies on loading because it
> cannot find Term::ReadLine. Adding -Idist/Term-ReadLine/lib to the
> command line doesn't work because under miniperl you're only allowed
> one -I and it's already used for -Ilib. This can probably be fixed by
> adding Term::ReadLine to write_buildcustomize.pl so it'll be in
> miniperl's magical @INC, but it took me a while to see that, time that
> I would rather have spent on the problem at hand rather than debugging
> the debugger.
Good point.
IMO this should be fixed, to have a debugger working good with
Term::ReadLine but still working without it.
Best regards,
Vadim.
Thread Previous
|
Thread Next