in reply to POD ERRORS Hey! The above document had some coding errors, which are explained below

It's not vandalism, it's best practices as far as I'm concerned. I wish all software told you when you were making mistakes and made you look like a jerk till you fixed them. We'd have a lot less bad software and fewer jerks to boot.

  • Comment on Re: POD ERRORS Hey! The above document had some coding errors, which are explained below

Replies are listed 'Best First'.
Re^2: POD ERRORS Hey! The above document had some coding errors, which are explained below
by JavaFan (Canon) on Aug 19, 2008 at 10:07 UTC
    It's one thing to tell the producer he makes a mistake, it's something else to mangle the product telling the consumer there's a mistake (of which many users will not have a clue how serious it is - specially not if it's done for programs, the user may have no clue what POD is, nor should he have to).

    Personally, I think it's not very useful to display the message at view time. And putting errors on STDOUT instead of STDERR is, IMNSHO, a big booboo. Errors belong on STDERR. That's why there is STDERR.

    IMO, the best times for displaying POD errors are at 1) "make test" time, and 2) "make dist" time.

      I know where you're coming from but I want broken products to look broken. Not pretend otherwise. A message about bad Pod is a fairly good indicator, however minor, that the software author doesn't care about writing good software or keeping it maintained once it's out in the wild. So it's ultimately beneficial, if confusing to new comers, behavior for users. STDERR is fine but I'm tired of hackers who fill the error logs with a hundred lines a second because no one ever sees them. They mainly seem to find the behavior defensible because it's invisible and users are not savvy enough to see where it manifests in lost data, broken redirects, missing includes, etc. (Sidebar: I'm coming off a bit heavy but I truly appreciate Perl's forgiveness and flexibility in this regard.)

        I understand your first couple of lines, although I do not agree with them.

        However, I don't get the second part of your rant. What do error logs have to do with it? And why it's it the "hackers" fault of noone looks at the error log? First of all, neither "make install", nor "perldoc" redirects STDERR to an error log. Furthermore, if you use software of mine, and said software is setup (either by itself, a redirect by the program calling it, a syslog config or something) to redirect its errors to a file, and you don't look at it, who is to blame? You or me?

Re^2: POD ERRORS Hey! The above document had some coding errors, which are explained below
by Anonymous Monk on Aug 19, 2008 at 03:46 UTC
    I wish all software told you when you were making mistakes and made you look like a jerk till you fixed them.

    But I am not making mistakes, I'm just reading someone elses. He use for example

    =head1 NAME Foo - bar bar bar bar =head1 DESCRIPTION Foo bar bar bar bar =begin foo bar bar bar something foo bar bar bar =end foo bar bar bar =cut
    and get
    NAME Foo - bar bar bar bar DESCRIPTION Foo bar bar bar bar POD ERRORS Hey! The above document had some coding errors, which are explaine +d below: Around line 14: '=end foo bar bar bar' is invalid. (Stack: =begin foo)
    What does pod2man, pod2text ... care about "foo bar bar bar" section. Another thing you can't turn it off (like it was before).

      You've already made the right choice by bringing it up: don't suffer in silence. Try what the other anonymonk said first, upgrade. If it still turns up errors, file a bug with the author of the offending Pod. Then you'll be a Perl hero. Mine anyway.

        Thanks mother, I'll try that :)
      upgrade to Pod-Simple-3.07 (and Pod-Perldoc-3.14_07), seems to quiet most of those (the valid ones)
      =begin foo bar bar this is valid =end foo =begin foo bar bar this is invalid =end foo bar bar