Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

Post reply on HN
Print view View original

51–60 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#51

Post by knodi123 »

johnnyo wrote: 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.

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 the intern was not.

But the bug didn't crop up until his code had been in production for a couple of weeks, so it was a real pain in the neck to track down.

Re: Perl code that is syntactically correct only on Fridays

#52

Post by space_ghost »

metalliqaz wrote: post #50
G3rn0ti wrote: post #40

This 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…

Thank you for this. I hate trying to read Perl so much. What is the "#/+" for?

Flavor? "#" starts a comment, so the "/+" characters are ignored by the interpreter.

Re: Perl code that is syntactically correct only on Fridays

#53

Post by [deleted] »

metalliqaz wrote: post #50
G3rn0ti wrote: post #40

This 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…

Thank you for this. I hate trying to read Perl so much. What is the "#/+" for?

[deleted]

Re: Perl code that is syntactically correct only on Fridays

#54

Post by dhosek »

manojlds wrote: post #27
johnnyo wrote: 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.

That's standard runtime issue right? This is syntax error at compile time.

Kind of sort of. The catch here is that because runtime is compile time with Perl, it's not exactly the same. Looking at the code, it's kind of like having something like

    #if (some C preprocessor expression that's true on Fridays
       printf("Hello world!);
    #else
       printf;
    #fi
(although it's been long enough since I've written C that I don't know if (a) there exists a C-preprocessor instruction as per the above, (2) if the compiler will notice errors in the unexecuted branch of an #if and (iii) if printf; would give a syntax error).

Another equivalent piece of code could be something along the lines of the JS

    if (today_is_friday()) {
      eval("2+2")
    }
    else {
      eval("--2abc")
    }

Re: Perl code that is syntactically correct only on Fridays

#55

Post by profmonocle »

raxxorrax wrote: post #2

I have written code that only works in winter because of daylight saving times and some unfortunate date conversions, but having a temporary correct syntax is really a new high.

The first iPhone app I wrote back in college would crash if you used it in a time zone with a positive UTC offset. I can't even remember why.

Re: Perl code that is syntactically correct only on Fridays

#56

Post by vidarh »

alisonatwork wrote: post #26
johnnyo wrote: 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.

Fantastic. We had a similar problem with test code that always worked on a remote team's computers during their work day but failed when we got into the office and tried to run it in a different timezone.

I've had to fix any number of test suite bugs as well as regressions that happened because the people who wrote the tests had ensured the test suite didn't (most of the time) test what they thought it would by relying on date arithmetic from current date and time...

Re: Perl code that is syntactically correct only on Fridays

#57

Post by G3rn0ti »

metalliqaz wrote: post #50
G3rn0ti wrote: post #40

This 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…

Thank you for this. I hate trying to read Perl so much. What is the "#/+" for?

> What is the "#/+" for?

I am sure this is not necessary for the behavior described. It's just a comment.

BTW: I am working for a company still maintaining a large Perl code base and I think this is rather obscure stuff. You rarely need to run something at compile time, hack the symbol table and you almost never need "sub() {}" to define subroutines with an empty "prototype". If I saw this in a code review I would most definitely had a closer look and would decline a PR if that was unnecessary. Meta programming should not be done lightheartedly and better serves a serious purpose.

Re: Perl code that is syntactically correct only on Fridays

#58

Post by vidarh »

praptak wrote: post #36

In similar vein: parsing C++ is literally undecidable: https://blog.reverberate.org/2013/08/parsing-c-is-literally-... You can't even decide if a particular "*" is multiplication or a pointer dereference until you resolve templates, which is Turing-complete.

Unless something has changed a lot, C++ templates at least only used to be Turing complete if you assume you're allowed unlimited recursive template applications, and compilers were free to restrict that (and did). Has that changed?

In theory I agree with you that this is horribly ugly - I very much prefer simple grammars (the irony being my favourite language to use is Ruby, which has an atrocious grammar). In practice these parses are rarely that hard to resolve.

Re: Perl code that is syntactically correct only on Fridays

#59

Post by markstos »

Just reading the headline gave me traumatic flashback to a customer project for a winter sports brand that broke on April 1st after not being modified for months prior to this.

You guessed it: There was a sleeper bug detonated by the date change. Pain the butt to track down in Perl code that was generating an Excel spreadsheet cell-by-cell.

Re: Perl code that is syntactically correct only on Fridays

#60

Post by lmm »

samatman wrote: post #45
lmm wrote: post #35

Earlier quoted context omitted.

> Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context. If you're going to be pedantic, it's important to be correct; there's no such thing as dynamic parsing. > If it could not be parsed it could never work! What's the logic here? An interpreter doesn't have to operate on an AST, a language doesn't have to have a nontrivial grammar (consider Brainfuck). Perl…

> there's no such thing as dynamic parsing As long as we're indulging in pedantry, this is incorrect presuming dynamic means what it usually means. Any regular expression constructed at runtime contradicts you. Modifying your core parser at runtime though, who would do such a thing? Other than reader macros in Common Lisp I mean. Are we going to argue this means Common Lisp doesn't parse if we add reader macros at ru…

> Are we going to argue this means Common Lisp doesn't parse if we add reader macros at runtime? A peculiar argument.

Peculiar how? Isn't that just common sense?

Post reply on HN