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:
Shlomi Fish
Date:
November 27, 2011 05:50
Subject:
Re: [RFC] Can we convert lib/perl5db.pl (= the default perldebugger) to strict and warnings?
Message ID:
20111127154948.59a5f2ef@lap.shlomifish.org
Hi Vadim,
On Sun, 27 Nov 2011 14:12:37 +0100
"Konovalov, Vadim (Vadim)** CTR **" <vadim.konovalov@alcatel-lucent.com> wrote:
> > 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.
>
OK, people, relax. In the github branch in which I've worked on the patch, I
did the conversion in several steps by: 1. Adding "use strict;" at the top. 2.
Getting rid of several of the reported errors. 3. Commenting-out use strict;.
4. Making sure the tests still pass. 5. Repeat.
If you're interested in the individual patches you can find them at:
https://github.com/shlomif/perl/tree/perl-minus-d-strict-and-warnings
I've posted the final result of this effort which allows one to add "use
strict;".
> 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.
1. Are you sure they will pollute the call stack? Seems strange to me.
2. Why do you care so much about speed in "perl -d"? It's an interactive
debugger, which isn't supposed to be speed critical, and I never heard
complaints on it being slow (hell I used it with early versions of perl on a
Pentium 133 MHz, and it was fast enough). Furthermore, getting rid of some "no
strict 'refs'" is a micro-optimisation at best.
>
> 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?
Do you want extra tests for the sake of adding "use strict;"? The way I see
it, "use strict;" is also a kind of test and asserts that all variables have
been declared, etc. Sure, adding "use strict;" to one's code might break it,
but the code is likely to get more broken without it.
> > 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.
Should be doable in a future patch.
Regards,
Shlomi Fish
--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
The Case for File Swapping - http://shlom.in/file-swap
Larry Wall is lazy, impatient and full of hubris.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Thread Previous
|
Thread Next