Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

111–120 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#111

Earlier quoted context omitted.

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)

Guess it's time to change the `0` in that cronjob to a `*/12`.

Re: Perl code that is syntactically correct only on Fridays

#112
post #72

Earlier quoted context omitted.

> # The following line executes the subroutine "f" and divides the result by 1 on fridays > # but on other days causes the interpreter to trigger a syntax error You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments. Removing all the "only on a Friday" stuff boils down to the difference between these two: # this compiles sub f…

> You have this the opposite way round to what's happening (and the description). It only compiles on a Friday, i.e. when the sub takes no arguments. Isn't that what the parent said, going by your quote? They said "the following line [...] on fridays but on other days causes the interpreter to trigger a syntax error".

Yes! You're right. Not sure what happened to my brain there. Too much staring at Perl, I suspect.

Re: Perl code that is syntactically correct only on Fridays

#113

Earlier quoted context omitted.

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)

Admin like that sound a lot worse than the intern. Unless maybe if it's an intern-admin...

Re: Perl code that is syntactically correct only on Fridays

#114

Earlier quoted context omitted.

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)

If you are to be paranoid about time, better be paranoid about stepping time. Time discontinuities can trigger bugs in the best of software.

Re: Perl code that is syntactically correct only on Fridays

#116
post #10

I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.

Fortunately we rarely use 12h clocks where I live. But that opens up other avenues: if you are not much of an early riser, a build script failing to deal with single digit hours can remain undetected for a very long time.

Re: Perl code that is syntactically correct only on Fridays

#117

I had a program once which failed every time it was 8 or 9 minutes past the hour and worked the rest of the time. It parsed a string containing the time and sscanf treats "08" and "09" as invalid octal numbers. Argh.

Been there, a TCL web script, IIRC. This led to religious processing of input with "regsub" (this predated TCL 8). Yuck.

Also once fixed an inherited awk script that malfunctioned at the end of year: a hardcoded month name array with November missing. To this day I always populate any such lookup with a loop and strftime() or appropriate.

Re: Perl code that is syntactically correct only on Fridays

#119

I don't get it! It is clearly written in the code, that the progam should behave this way. Is the proof, that perl is capable of this behaviour?! I don't get it - what is the point? I read all the comments and still don't get it. What am i missing?

What makes it "special" here is the fact that it will COMPILE only on a friday.

It's not a runtime error but a compile time error. Because yes otherwise I would agree that it's doable easily in every single language.

Re: Perl code that is syntactically correct only on Fridays

#120
post #69

Earlier quoted context omitted.

We had situation where if you worked late, the test suite would consistently fail. Since developers rarely worked late and would give up when hitting the "random" test suite failure and go home, the bug persisted for months before the true cause was understood. Our time zone was UTC-5, and the test suite contained a local-vs-UTC bug which only triggered between 7pm and midnight.

I feel like this is relatively common (unfortunately)

It is. I'm in London which means that our time is +/- 1 hour of UTC depending on daylight saving time.

There's been a couple projects where if I pushed a commit between 11pm and 1am some tests would break. I'm pretty sure the issue is inconsistent use of UTC vs local time which during that period will differ by one day.

Post reply on HN