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.
Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and t…
Perl code that is syntactically correct only on Fridays
161–170 of 233 posts
Re: Perl code that is syntactically correct only on Fridays
#162Earlier quoted context omitted.
Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and t…
> an intern who wrote code .... his code had been in production You get what you pay for, eh?
Re: Perl code that is syntactically correct only on Fridays
#163Earlier quoted context omitted.
> I have written code that only works in winter because of daylight saving times and some unfortunate date conversions Not sure where you are located, but this can be particularly bad in the UK where winter time happens to coincide with UTC.
Let's be pedantic about this, because this is one of the very few areas where pedantry matters: GMT ("British Winter Time") is NOT UTC, and it can differ from UTC up to 0.9 seconds. GMT is a time zone (corresponding to UT1). UTC is a time standard.
There may be some niche astronomical or legal(?) applications which have to keep track of the potential 0.9 seconds skew, but my impression is that any app which claims to support a "GMT" (or Europe/London) option is actually only supporting "GMT-ish".
Re: Perl code that is syntactically correct only on Fridays
#164This is how it works: BEGIN { # an execution block that runs when the module is compiled *f = # assigns to the symbol "f" inside the symbol table ... (localtime->wdayname eq 'Fri') # is it Friday? ? sub() {} # ... on friday an anonymous subroutine taking no arguments : sub {}; # ... on every other day a subrouting taking arguments } # closes the execution block # The following line executes the subroutine "f" and div…
: sub {};
Don't all perl subroutines allow any number of arguments (including 0) to be passed?Does the fact that the above is an anonymous subroutine affect the answer to my question?
Re: Perl code that is syntactically correct only on Fridays
#165I 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.
If you tried, you couldn't even come up with this.
Re: Perl code that is syntactically correct only on Fridays
#166Earlier quoted context omitted.
Right, the beauty of this is that it's a syntax error he's produced. Sure any language can write code to produce a runtime error under any condition at all. And a lot of languages have features that allow them to run code at compile time, and similarly produce errors then too. But those languages don't allow you to ruin the syntax of the language. I guess it's something that requires macros. Would it be safe to say t…
It is formally proven that Perl can't be parsed! https://www.perlmonks.org/index.pl?node_id=663393
Re: Perl code that is syntactically correct only on Fridays
#167Earlier quoted context omitted.
Most other languages would require `eval` and having incorrect code as syntactically correct string literal. But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.
Perl is not parsed as it is executed. It is compiled to opcodes then run. The BEGIN block, however, explicitly runs code at compile time. It is literally compiling different code on different days, then attempting to run it.
Re: Perl code that is syntactically correct only on Fridays
#168Earlier quoted context omitted.
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.
Re: Perl code that is syntactically correct only on Fridays
#169I worked with Randal L. Schwartz for several years in the Los Angeles area. I was already doing Perl but getting an opportunity to see his code and ask him questions was something that changed my career for the better. Thanks Merlyn!
Re: Perl code that is syntactically correct only on Fridays
#170This is how it works: BEGIN { # an execution block that runs when the module is compiled *f = # assigns to the symbol "f" inside the symbol table ... (localtime->wdayname eq 'Fri') # is it Friday? ? sub() {} # ... on friday an anonymous subroutine taking no arguments : sub {}; # ... on every other day a subrouting taking arguments } # closes the execution block # The following line executes the subroutine "f" and div…
Why does the following expect arguments: : sub {}; Don't all perl subroutines allow any number of arguments (including 0) to be passed? Does the fact that the above is an anonymous subroutine affect the answer to my question?