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:/ +/, 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 +:// 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__ 2019-07-23 19:12:39 Repaster Repasted text from mje__: http +:// 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.