Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

I don't want to be forced into your damned warning policy 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I don't think you've taken a controversial position at all there, you've hit the nail on the head.

    Modules should stay the hell out of your namespace and application except to do the things you've actually asked them to do.

    Warnings and logfiles: abso-bloody-lutely.

    If you break something, you need to be told about it once, not 5 million times.

    If someone else breaks something and doesn't pay attention that they're being told 5 million times, you don't want to find the 5 billion other messages first thing monda

  • Something like this: my %warnings; $SIG{WARN} = sub { print STDERR $_[0] if not $warnings{$_[0]}; $warnings{$_[0]} = 1}; Gabor
    --

    • Only works per-process.

      Most webservers are multiple processes with a limited lifetime (they often get killed after a fixed number of requests).

      Then there's the issue that most large sites have a server farm too...

      • Yes, it only works per-process and per-server, but in my experience (with 80+ servers running many mod_perl processes) it is a very simple and effective way to eliminating the kinds of web-service log-storms you described. It changes an unmanageable flood into a very manageable stream. Highly recommended.

        • Sorry, didn't mean to imply that it doesn't mitigate the problem, it does but it can only mitigate it.

          Whether that turns the situation into a manageable one or not would depend on circumstance. :)

    • Does this work? I get an error:

        $ perl -Mwarnings -e'$SIG{WARN}=sub{}; my $a; my $b=$a+1;'
        No such signal: SIGWARN at -e line 1.
        Use of uninitialized value $a in addition (+) at -e line 1.
  • Sorry, if the following text sounds a bit rude ;-) I don't really know what the big problem is. At the beginning you wrote you test it in a way beginners would do, meaning you don't want the modules to cause problems to beginners. Enabling use strict and use warnings is definatly the way to go in more than 99% of cases. Even Perl6 enables it per default. Nearly every module forces you to something and these two things shouldn't really be a problen in most cases. Even low level programming languages (meanin

    • There's several problems:

      One, the module is doing something that isn't its advertised function and _really_ isn't neccessary to implement its core function.

      Two, it's changing behaviour of the parent program, this is a bad thing to do even when it _is_ neccessary.

      Three, it isn't clear in situations like the Moose one, just when to turn it off or on, consider the following sequence within a single scope:

      You enable warnings/strict. You do some code. You turn off warnings/strict. You do some code. You use M

  • I fully agree. Warnings in production are a no-go. Except very specific and monitored cases maybe.

    That's where "perl -X" is useful. Can one enable mod_perl running under -X yet ?

  • How do you think about:

    use warnings FATAL => 'all';

    No one has commented on the necessity of empty import lists yet. How about a Critic policy that always requires an explicit import list (with configurable exceptions because the world's not perfect)? I certainly would like that.

    • It would be nice, but a little tricky, since you need to exclude pragmas which use the import function to achieve their pragma effects.

      It's doable though, and I'd happily enable that rule for Padre if someone wrote it.

  • I have to say I was greatly impressed that the Dancer guys have offered to implement some kind of configuration option so I can explicitly turn disable their Dancer-imposed warnings in production...

    This quote makes me very suspicious about the whole contest, since the Mojolicious folks never even heard a single word about this before.

    • I reckon this post was instigated mainly by me. When Adam turned up on the IRC channel after he read from our posts that strict and warnings are on by default, I tried to explain it's on purpose and asked what the problem with it was.

      This started a whole discussion when Adam said there's no need for it in production and I countered it saying I do want it in production.

      Then the discussion flowed between the rest of the programmers on letting the user be able to change the default warnings on.

      This is also som

    • Good ol’ Sebastian… :-)

  • Just like that one text editor...

    I often use an idiom that I try to fetch an item, and if successful I want to do something with it; if not successful, the code returns undef (false). Typically, the code goes something like this:

    if(my $item = get_item(@params)) {
        # do something with $item
        print $item->{text};
    }

    but this text editor complains about it, stating, in a dialog box:

    a single = in a conditional is usually a typo, use == or eq to compare.
    Do you want to continue?

    every.

    • You'd think that the "my" would be a clue that you intended to do it that way. And a my $foo == ... in an if statement would be a red flag.
    • It is a bug. You could report it (or at least ask on the Padre channels if this is a bug or a feature).

      We could tell you where to turn off the message until we fix the bug. By the way the the feature that is causing that error message is specifically designed to catch mistakes of beginners.

      The idea is to catch bugs that can be caused by code like this:

      if ($x = /boo/) {
      }

      which is valid perl but it is unlikely a beginner would know what it actually does. The example you gave probably should not trigger

      --
      • Oh and just to make a useful post as well, - after having dinner and being less grumpy - you can turn on/off the Perl beginner mode in "Edit/Preferences/Behaviour/Perl beginner mode" or "Tools/Preferences/Behaviour/Perl beginner mode" in newer versions of Padre.

        Also I think I have partially fixed that specific bug in 0.59 as it was also causing test failures in Padre where we also use similar constructs here and there.

        I think it is still buggy and eventually it should be implemented as a plugin for Perl

        --

  • ... and this is why strictures will be the default in Perl. Modules have no business mucking with your namespace, as you say. Perl does.

    Note that warnings won't be the default for various reasons.

  • Moose started this whole thing, not any $Adjective::Perl modules. Moose 0.10 (released 05 Jul 2006) turns on strict and warnings for you. Modern::Perl is circa 2009.

    I think it was mst who came up with the trick.

  • (but -1 for the apostrophes)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.