A
Anno Siegel
Hendrik Maryns said:
It doesn't, what should it do? It's a syntactically perfect (perlfect?)
rose.
Anno
It doesn't, what should it do? It's a syntactically perfect (perlfect?)
rose.
Anno
H
Hendrik Maryns
Abigail schreef:
I get it, d'oh!
H.
I get it, d'oh!
H.
A
Arndt Jonasson
Abigail said:
They smell nicely, sometimes.
P
Peter Scott
Joachim Pense ([email protected]) wrote on MMMMCLXXVII
September MCMXCIII in <URL) I do not think a one-letter no-warnings option would really hurt.
Well, it seems that people think a one-letter warnings option does hurt.
So, by that token, a one-letter no-warning would hurt as well.
It's quite reasonable to suppose that -e would disable implicit
warnings.
A
Anno Siegel
Arndt Jonasson said:
You forgot to plug in your OMC (Olfactory Multimedia Component).
Anno
G
Guest
Thats actually one of the reasons I don't care for the -w switch. (*EXCEPT* in
debugging) I don't know if it's still the case or not, but this used to
generate a warning:
sub something {
my($i);
{
my($i)
.. use inner $i ...
}
... use outer $i ..
}
The way I see it, the above should be legal, and maybe even encouraged for
small index variables.
I see so much code with:
my($var) = '' # squelch warning about undefined variable
When your program knows very well it could be undefined but it doesn't care.
Extra junk to void out warnings can sometimes make it harder to follow.
I use a -w pretty much only when hunting down a bug. (Use it so seldom
that I sometimes forget it's available, I shouldn't do that because it
is sometimes useful.)
OTOH, I'm quite fond of 'use strict'. I like the way it catches
problems in advance and makes you think twice before using a global
variable. Once in awhile you have to do a
{
no strict 'refs';
...
}
But, overall, the advantages of strict are well worth it.
Just my opinion, of course.
Jamie
A
Anno Siegel
It doesn't warn (why didn't you test it?) and it never did. That is
no reason to avoid warnings.
Anno
A
Anno Siegel
It doesn't warn (why didn't you test it?) and it never did. That is
no reason not to use warnings.
Anno
X
xhoster
Why is the comment necessary? Do you put a comment after every
semicolon saying "# To prevent syntax errors"?
If I see a variable being initialized to '' or 0, that gives me valuable
information about how I expect the variable is going to be used. Not
distracting at all. (The unnecessary paranthesis, on the other hand, do
throw me off.)
Xho
T
Tassilo v. Parseval
Also sprach Anno Siegel:
There is a problem with warnings on a larger scale, namely in the
context of published code, most notably modules. It's most annoying and
fairly useless to read things such as
Use of uninitialized value in string eq at
/opt/perl5.8.6-db/lib/5.8.6/Foo/Bar/Baz.pm line 4242
Does it mean there's a bug in the module, or maybe in my program using
this module? Or maybe it's a potential bug that could occur under
certain rare circumstances. It could just as easily mean nothing of that
kind and only expose the module's author's sloppyness.
If warnings in module context really and rightly suggest there's a bug,
then the bug itself will sooner or later manifest in some other way,
wont it? Otherwise it wouldn't be one. The point being that warnings
rarely provide information useful to people not in charge of the code.
Tassilo
There is a problem with warnings on a larger scale, namely in the
context of published code, most notably modules. It's most annoying and
fairly useless to read things such as
Use of uninitialized value in string eq at
/opt/perl5.8.6-db/lib/5.8.6/Foo/Bar/Baz.pm line 4242
Does it mean there's a bug in the module, or maybe in my program using
this module? Or maybe it's a potential bug that could occur under
certain rare circumstances. It could just as easily mean nothing of that
kind and only expose the module's author's sloppyness.
If warnings in module context really and rightly suggest there's a bug,
then the bug itself will sooner or later manifest in some other way,
wont it? Otherwise it wouldn't be one. The point being that warnings
rarely provide information useful to people not in charge of the code.
Tassilo
A
Anno Siegel
Tassilo v. Parseval said:
Okay, but that happens only with global -w, not with lexical "use warnings".
Yes. See below.
If a module issues warnings the author didn't intend the user to see,
that's a bug. Most of the time it is trivially fixed.
If the module author has "use warnings" early in each file as a matter of
course, these problems are caught during development. Unfortunately, h2xs
issues a module template without warnings. That may be a reason why the
practice isn't more common.
What about silently delivering wrong results?
Really? I'd understand "(not) useful to the people running the program",
but as a developer I'm just as interested in warnings as I am in errors.
Anno
T
Tassilo v. Parseval
Also sprach Anno Siegel:
h2xs puts 'use warnings' into the created module skeleton. Those modules
will emit warnings even if -w or warnings are turned off in the program
using this module.
Ah, but there the warning itself becomes the bug. The trivial fix would
be getting rid of 'use warnings' within the module. No warning, hence no
bug. ;-)
There is obviously something very contorted in this logic just outlined.
But it is the direct implication of your assertion that a warning
produced by a module is a bug.
I just checked it (again). h2xs puts them in, unless a version older
than 5.6 is specified using -b or --skip-warnings is mentioned
explicitly.
Interestingly enough, I just noticed that I preach things differently
from how I do them in the modules I have released. Most of my modules
have warnings on in fact. I even go through painful procedures to
temporarily switch them off in XS code where necessary and turning them
on again afterwards. Hmmh.
It's not at all clear to me how wrong results correlate with the amount
of warnings emitted. I will admit that the likelihood of warnings is
probably higher when a wrong result is being computed (and vice versa).
However, there will still be many cases where those two things will be
entirely uncorrelated. If anything, warnings from a module will give me
doubts about the quality of the module in question.
I see myself as a plain user when it comes to external modules and
libraries. It is true that in some cases I might lay hands on their code
but in most cases I will start looking for less noisy alternatives. It's
not always practical (let alone easy) to dive into other people's code
and fix things.
Tassilo
h2xs puts 'use warnings' into the created module skeleton. Those modules
will emit warnings even if -w or warnings are turned off in the program
using this module.
Ah, but there the warning itself becomes the bug. The trivial fix would
be getting rid of 'use warnings' within the module. No warning, hence no
bug. ;-)
There is obviously something very contorted in this logic just outlined.
But it is the direct implication of your assertion that a warning
produced by a module is a bug.
I just checked it (again). h2xs puts them in, unless a version older
than 5.6 is specified using -b or --skip-warnings is mentioned
explicitly.
Interestingly enough, I just noticed that I preach things differently
from how I do them in the modules I have released. Most of my modules
have warnings on in fact. I even go through painful procedures to
temporarily switch them off in XS code where necessary and turning them
on again afterwards. Hmmh.
It's not at all clear to me how wrong results correlate with the amount
of warnings emitted. I will admit that the likelihood of warnings is
probably higher when a wrong result is being computed (and vice versa).
However, there will still be many cases where those two things will be
entirely uncorrelated. If anything, warnings from a module will give me
doubts about the quality of the module in question.
I see myself as a plain user when it comes to external modules and
libraries. It is true that in some cases I might lay hands on their code
but in most cases I will start looking for less noisy alternatives. It's
not always practical (let alone easy) to dive into other people's code
and fix things.
Tassilo
P
phaylon
Tassilo said:
I think the bug is "letting the warning happen."
btw: This kind of discussion is one reason why I like this group
A
Anno Siegel
Tassilo v. Parseval said:
[unplanned warnings from a module]
Taking out "use warnings" doesn't fix the bug -- the user can make it
reappear through -w. You need "no warnings ..." in the right scope.
That scope would rarely be the entire module, but rather the smallest
possible scope that does the job. Or you change the logic so that
the warning doesn't happen in the first place.
It's less contorted when the fix is as outlined above.
You are right. Apparently it has done so since at least 5.6.1. I don't
know what made me think otherwise.
[...]
The warning indicates a case the author hasn't thought of and hasn't
tested. If the results are correct in such cases that's coincidence.
Sorry. I consistently overlooked a "not" in your sentence. My objection
makes no sense.
Anno
G
Guest
This is where I think warnings belong, for the developers.
I do appreciate the ability to use them, to *me* it's kind of like
discussing whether or not '-g' should be on gcc by default.
-g is great for debugging but I wouldn't want it on by default.
Likewise, -w is a useful tool.
If I see existing code that generates lots of warnings with -w,
I don't consider it buggy. If it bombs with 'use strict'
I consider it 'potentially buggy.'
Where MY code generates warnings, I will sometimes look into it,
but usually it's a harmless warning.
I suppose one could argue the same about 'use strict', that
perhaps it should be off for finished modules. (I like it
on, but I appreciate 'use strict' being optional)
Creativity & freedom is what makes perl better than
the other languages. It's nice to have choices.
Anyone know of the performance differences with -w turned on/off?
(Same with strict?)
Jamie
T
Tassilo v. Parseval
Also sprach (e-mail address removed):
I always wanted to write a little Perl script that processes Makefiles
and removes any signs of '-g'. Lately I've come across so many programs
that forcibly put them in regardless of the presence of the
'--disable-debug' and '--enable-optimize' switches for Configure.
Strictures are, for me anyway, a different pair of shoes. They leave
almost no visible marks at runtime safe for croaking on symbolic
references. Therefore I never bothered to yank them out again before a
release.
As for 'use warnings', I don't have to remove that from my code either
because I rarely use it. Instead, I have -w switched on in my
testscripts (not the one in t/ but rather my private ones) which will
automatically propagate them into my module.
There are rumours that both would have a slight but still noticeable
effect on runtime performance. This is something I refuse to believe.
Strictures and warnings are merely flags that are either set or not. In
both cases however, the Perl interpreter has to check them. The
additional code executed when one of them is one is negligible (usually
just one statement).
This naturally only holds true for programs that don't emit warnings.
For those that do there is a slow-down caused by the simple fact that
warnings write to stderr.
Tassilo
I always wanted to write a little Perl script that processes Makefiles
and removes any signs of '-g'. Lately I've come across so many programs
that forcibly put them in regardless of the presence of the
'--disable-debug' and '--enable-optimize' switches for Configure.
Strictures are, for me anyway, a different pair of shoes. They leave
almost no visible marks at runtime safe for croaking on symbolic
references. Therefore I never bothered to yank them out again before a
release.
As for 'use warnings', I don't have to remove that from my code either
because I rarely use it. Instead, I have -w switched on in my
testscripts (not the one in t/ but rather my private ones) which will
automatically propagate them into my module.
There are rumours that both would have a slight but still noticeable
effect on runtime performance. This is something I refuse to believe.
Strictures and warnings are merely flags that are either set or not. In
both cases however, the Perl interpreter has to check them. The
additional code executed when one of them is one is negligible (usually
just one statement).
This naturally only holds true for programs that don't emit warnings.
For those that do there is a slow-down caused by the simple fact that
warnings write to stderr.
Tassilo