mje says he was ridiculed and alludes to intolerance (in the heading):
GIven my new enthusiasm for the Perl community I dare to post an issue I was having to IRC on #perl-help and it all fell down. […] anyone posting in #perl-help, needs help and I'd forgotten that certain people view this channel as a shooting ground where you pour ridicule on posters "who don't understand their problem" - of course they don't or why would they post on #perl-help. I got some helpful comments but I also got the ridicule.
That sounds untypical for #perl-help, in which I occasionally participate on both the Q and A sides. (There's my disclosure of bias.) mje did not substantiate, so I went and looked what happened. I did not find ridicule, not even a heated discussion. I notice I am confused.
I decided to post the log because the Perl community as a whole was blamed, not individuals, and in order to provide accurate first-hand information so that anyone can form their own opinion.
2019-07-23 18:47:42 mje__ I have a strange warning that I cannot
+ provide a runnable example for. The code "if (defined($match->{in_co
+ntrol}) && ($match->{in_control} == 1))" ends up issuing a warning sa
+ying "Use of uninitialized value in numeric eq (==)" but I cannor und
+erstand how this can happen. $match is defined and even if it wasn't
+I'd expect a warning saying trying to deref and undef. I don't think
+it is autovivification as my tests show
2019-07-23 18:47:42 mje__ defined doesn't do this. Any ideas?
2019-07-23 18:48:44 mje__ Perl 5.24.4
2019-07-23 18:56:48 alh in_control could have operator overloa
+ding
2019-07-23 18:57:00 alh Alternatively, the warning isn't happe
+ning where you think it is which seems more likely
2019-07-23 18:57:21 alh Line numbers can be wrong if it's part
+ of a giant if () { } elsif () { } else {} block
2019-07-23 18:57:35 alh So it could be a different conditional
+ triggering it
2019-07-23 18:58:54 mje__ Simple hash ref, so no overloading. Th
+e warning seems pretty good since the line mentioned contains an ==
2019-07-23 18:59:58 alh Is it part of a multi-line conditional
+?
2019-07-23 19:00:02 alh Can you show us more of the code
2019-07-23 19:00:08 mst the warning is happening somewhere els
+e
2019-07-23 19:00:10 mst 99% chance
2019-07-23 19:02:28 mje__ Here is what it looks like now https:/
+/pastebin.com/fsTnLRaS, the only thing changed from when the warning
+was output was defined changed to exists
2019-07-23 19:02:29 Repaster Repasted text from mje__: http
+://perl.bot/p/mmydbc
2019-07-23 19:03:03 alh That's using exists
2019-07-23 19:03:04 alh not defined
2019-07-23 19:03:07 alh So it can exist and e undef
2019-07-23 19:03:13 alh Which is your problem
2019-07-23 19:03:46 mje__ I said, the original was defined when
+the warning was issued and what I pasted was afterwards when it was c
+hanged to exists
2019-07-23 19:04:48 mje__ the change from defined to exists is l
+ikely wrong but the warning came from the defined case
2019-07-23 19:06:29 alh Can you show more context?
2019-07-23 19:12:38 mje__ https://pastebin.com/sYC3XR31
2019-07-23 19:12:39 Repaster Repasted text from mje__: http
+://perl.bot/p/t8p5x4
2019-07-23 19:16:48 alh before line 18 warn the value of $exis
+ting_match->{in_control}
2019-07-23 19:17:01 alh Beore line 14 do the same for $events{
+$event_id}->{event_status_id}
2019-07-23 19:17:05 alh That may be where the real warning is
+coming from
2019-07-23 19:22:02 mje__ ok, so the crux of the opinion is the
+line number is possibly wrong and so other == tests could be at fault
+?
2019-07-23 19:24:47 mst the crux of the opinion is "you're con
+fused about *something*
2019-07-23 19:24:51 alh Yes. And you can figure out by adding
+debug everywhere
2019-07-23 19:24:57 mst I'd probably apply warn + Data::Dumper
2019-07-23 19:25:12 alh If you think $x->{foo} == 1 is warning
+, warn reight before that conditional, warn inside that conditional,
+warn after that conditional
2019-07-23 19:25:31 alh Where the unintialized value warning a
+ppears in regards to what you've added should help you track it down
2019-07-23 19:28:21 Grinnz source filters are also known to screw
+ up line numbers
2019-07-23 19:29:32 mst oh. yes. if you have 'use Switch;' in
+that code, you can assume all line numbers are wrong
2019-07-23 19:30:00 Grinnz (and in that case, that it also caused
+ the error)
2019-07-23 19:31:00 mje__ Unfortunately this is code working on
+live data and although it is possible to play it back the playback is
+n't EXACTLY as it was live. We don't use Switch. I hadn't considered
+the warning line number was wrong so I've got something to work on. T
+hanks
2019-07-23 19:31:43 Grinnz there are still some core bugs that ma
+ke wrong line numbers too
2019-07-23 19:34:35 alh Also if a comment like this is anywher
+e in the file:
2019-07-23 19:34:38 alh # line 5 10
2019-07-23 19:35:07 alh Or even:
2019-07-23 19:35:09 alh # line 10
2019-07-23 19:35:12 mst honestly I still thing you're just con
+fused about the data
Timestamps are in Europe/Vienna timezone. The log is complete and unmodified. I'd appreciate replies of confirmation that it is so.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
