Skip Menu |
 

This queue is for tickets about the common-sense CPAN distribution.

Report information
The Basics
Id: 122608
Status: open
Priority: 0/
Queue: common-sense

People
Owner: Nobody in particular
Requestors: pali [...] cpan.org
Cc: rt.cpan.org [...] schmorp.de
schmorp [...] schmorp.de
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.0
Fixed in: (no value)



CC: "Marc Lehmann" <schmorp [...] schmorp.de>
Subject: common::sense enable fundamentaly broken fatal warnings and therefore is unusable
Download (untitled) / with headers
text/plain 576b
Perl fatal warnings are fundamentally broken and should not be used. There are serious bugs in fatal warnings including memory leaks, breaking $?, $!, fork/exec or hiding warning/errors. Therefore module which enable these fatal warnings is unusable and so common::sense (version 2.0 and upper which enabled fatal warnings) is in current form should not be used. Please fix module common::sense to not enable perl fatal warnings. See for more details: https://metacpan.org/pod/warnings#Fatal-Warnings http://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg225235.html
Download (untitled) / with headers
text/plain 533b
On Wed Jul 26 04:35:22 2017, PALI wrote: Show quoted text
> Perl fatal warnings are fundamentally broken and should not be used.
They *can* be used fine, the rant you linked to on p5p is only one side of the equation. Note that strictures v2+ is very careful about which warnings it fatalizes - we defatalize 'exec' specifically to avoid the fork/exec issues, for example. I would encourage common::sense to follow our lead in defanging the riskier warnings, and encourage all common::sense users to switch to strictures unless/until it's fixed.
Subject: Re: [rt.cpan.org #122608] common::sense enable fundamentaly broken fatal warnings and therefore is unusable
Date: Wed, 2 Aug 2017 12:02:03 +0200
To: Pali via RT <bug-common-sense [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
Hi! Please send your bug report to the official contact/author address for the module in question (or send it to rt.cpan.org@schmorp.de, that's fine as well). What follows is the rationale for this request, you don't have to read it if you don't care. Why is this necessary? rt.cpan.org has many deficiencies which makes it tedious and hard to use, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs). Still, for some people, rt.cpan.org is useful to have, and some people even like it and really want to use it. That is fine, too. Unfortunately, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author. Just like a spammer, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer, they don't care for the people they actively hurt. Just like a spammer, they don't don't care to fix these issues and make their "service" ethically acceptable. You cannot even configure it to redirect tickets to somewhere else. Unfortunately, ignoring rt.cpan.org is not an option either: for people reporting possible bugs there is no indication that their report will be ignored, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered, making a module look unmaintained when in fact the opposite might be true). I am sorry that this wasted a bit of your time, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody. Please redirect your bug report as stated in the beginning of this mail, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in, opt-out, or some redirect option. One last issue: many people mail me that this can be "fixed" by including the bugtracker element in my module meta file. This is not true: 1. This field only affects search.cpan.org and maybe similar services. (Many people confuse rt.cpan.org with search.cpan.org for some reason). 2. It doesn't even work (there are still links to rt.cpan.org displayed). 3. Even if search.cpan.org does no longer display the link, it doesn't actually affect rt.cpan.org (and tests have shown that people go to rt.cpan.org regardless) Even *iff* rt.cpan.org would start listening on the bugtracker field, however, it's still wrong. I have a lot of modules, and each time a service like rt.cpan.org comes out, I would have to make dummy releases for all my modules. This not only creates a lot of extra work for me (I take releases very seriously) but also users, who would wonder why there is a new release. Thanks a lot, Marc Lehmann <rt.cpan.org@schmorp.de> Last updated: 2012-04-22
Subject: Re: [rt.cpan.org #122608] common::sense enable fundamentaly broken fatal warnings and therefore is unusable
Date: Wed, 2 Aug 2017 12:28:41 +0200
To: Matt S Trout via RT <bug-common-sense [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
Hi! Please send your bug report to the official contact/author address for the module in question (or send it to rt.cpan.org@schmorp.de, that's fine as well). What follows is the rationale for this request, you don't have to read it if you don't care. Why is this necessary? rt.cpan.org has many deficiencies which makes it tedious and hard to use, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs). Still, for some people, rt.cpan.org is useful to have, and some people even like it and really want to use it. That is fine, too. Unfortunately, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author. Just like a spammer, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer, they don't care for the people they actively hurt. Just like a spammer, they don't don't care to fix these issues and make their "service" ethically acceptable. You cannot even configure it to redirect tickets to somewhere else. Unfortunately, ignoring rt.cpan.org is not an option either: for people reporting possible bugs there is no indication that their report will be ignored, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered, making a module look unmaintained when in fact the opposite might be true). I am sorry that this wasted a bit of your time, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody. Please redirect your bug report as stated in the beginning of this mail, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in, opt-out, or some redirect option. One last issue: many people mail me that this can be "fixed" by including the bugtracker element in my module meta file. This is not true: 1. This field only affects search.cpan.org and maybe similar services. (Many people confuse rt.cpan.org with search.cpan.org for some reason). 2. It doesn't even work (there are still links to rt.cpan.org displayed). 3. Even if search.cpan.org does no longer display the link, it doesn't actually affect rt.cpan.org (and tests have shown that people go to rt.cpan.org regardless) Even *iff* rt.cpan.org would start listening on the bugtracker field, however, it's still wrong. I have a lot of modules, and each time a service like rt.cpan.org comes out, I would have to make dummy releases for all my modules. This not only creates a lot of extra work for me (I take releases very seriously) but also users, who would wonder why there is a new release. Thanks a lot, Marc Lehmann <rt.cpan.org@schmorp.de> Last updated: 2012-04-22
Download (untitled) / with headers
text/plain 1.9k
On Wed Jul 26 13:22:31 2017, MSTROUT wrote: Show quoted text
> On Wed Jul 26 04:35:22 2017, PALI wrote:
> > Perl fatal warnings are fundamentally broken and should not be used.
> > They *can* be used fine,
Nope, they cannot. Even warnings documentation by perl5 porters does not recommend to enable fatal warnings. Also there is note "ENTIRELY AT THE USER'S RISK." specially when using XS modules which issue categorized warnings. Show quoted text
> the rant you linked to on p5p is only one > side of the equation. > > Note that strictures v2+ is very careful about which warnings it > fatalizes - we defatalize 'exec' specifically to avoid the fork/exec > issues, for example.
So take random one mentioned problem: $ touch /tmp/test $ perl5.10.1 -MData::Dumper -e 'stat "/tmp/test"; eval { -l TEST; 1 }; print Dumper([stat _])' 2>/dev/null $VAR1 = []; Then verify with non-fatal warnings: $ perl5.10.1 -MData::Dumper -e 'use warnings; stat "/tmp/test"; eval { -l TEST; 1 }; print Dumper([stat _])' 2>/dev/null $VAR1 = []; Output is same, great. And now with common::sense: $ touch /tmp/test $ perl5.10.1 -MData::Dumper -e 'use common::sense; stat "/tmp/test"; eval { -l TEST; 1 }; print Dumper([stat _])' 2>/dev/null $VAR1 = [ 25, 2977687, 33188, 1, 1000, 1000, 0, 0, 1501673359, 1501673359, 1501673359, 4096, 0 ]; And result is completely different, just because of fatal warnings. Nasty, common::sense is really great for heisenbugs and for debugging... So common::sense here is a problem. And this is just one example. Show quoted text
> I would encourage common::sense to follow our lead in defanging the > riskier warnings, and encourage all common::sense users to switch to > strictures unless/until it's fixed.
So please make warnings non-fatal by default and people who understand risk could optionally enable fatalization. Because now it is needed to call use warnings NONFATAL => "all"; after each usage of common::sense.
CC: pali [...] cpan.org
Subject: Re: [rt.cpan.org #122608] common::sense enable fundamentaly broken fatal warnings and therefore is unusable
Date: Thu, 3 Aug 2017 04:16:49 +0200
To: Matt S Trout via RT <bug-common-sense [...] rt.cpan.org>
From: mst [...] shadowcat.co.uk
Download (untitled) / with headers
text/plain 1.9k
On Wed, Jul 26, 2017 at 01:22:37PM -0400, Matt S Trout via RT <bug-common-sense@rt.cpan.org> wrote: Show quoted text
> Note that strictures v2+ is very careful about which warnings it fatalizes - we defatalize 'exec' specifically to avoid the fork/exec issues, for example. > > I would encourage common::sense to follow our lead in defanging the riskier warnings, and encourage all common::sense users to switch to strictures unless/until it's fixed.
Matt, doesn't the easily verifiable fact that common-sense already did this a whole year before strictures even existed worry you a bit? A tiny bit? You know, reality, that ... thing... that you... constantly... ignore? Of course, spreading FUD seems to be what you can do best, but you are really not adding to this discussion by making up some fantasy story about strictures taking a lead while trying to make people feel unsafe by insinuating that there is a problem here. But of course it's nice to hear that strictures has applied some common sense and also not made exec (and some other warnings) fatal - long after common-sense did so, but eventually, it did. But you were presumably copying from the best, as they say :) Seriously, copying stuff that works and learning from each other is a good thing, but honestly acknowledging sources and not badmouthing "the competition" are very important. (As a sidenote, no version of common-sense ever had exec a fatal warning - common-sense very carefully picks its warnings, and very carefully and explicitly documents what it enables or not, and why). But actually checking before making up some shit is too much for you, no). Well, I wish you personally well and hope thta some distant day, you become a better person.... -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
Download (untitled) / with headers
text/plain 488b
On Wed Jul 26 13:22:31 2017, MSTROUT wrote: Show quoted text
> Note that strictures v2+ is very careful about which warnings it > fatalizes - we defatalize 'exec' specifically to avoid the fork/exec > issues, for example.
And has exactly same problem as common::sense described in this ticket. I reported new bug https://rt.cpan.org/Ticket/Display.html?id=122699 for strictures as this ticket is for common::sense and for unknown reason it was marked as deleted without any comment and without fixing it.
On Wed Aug 02 22:17:01 2017, mst@shadowcat.co.uk wrote: Marc, I'd ask you to not reply with my email address in the 'From:' address, to avoid confusion for people reading this conversation later. Show quoted text
> On Wed, Jul 26, 2017 at 01:22:37PM -0400, Matt S Trout via RT <bug- > common-sense@rt.cpan.org> wrote: > Matt, doesn't the easily verifiable fact that common-sense already did > this a whole year before strictures even existed worry you a bit? A > tiny > bit? You know, reality, that ... thing... that you... constantly... > ignore?
We concluded that common::sense disabled too many things, and since it had minimal documented rationale for the selections started with "all warnings" and worked down from there. At this point, strictures 2 has a longer list of defatalisations than common::sense, which is what I was referring to. We document exactly why we defatalise each category that we do - specifically so that other users don't have to reverse engineer out decision process. Perhaps you might consider doing the same for common::sense.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.