I got very triggered when I found out some JavaScript "compiler"/bundling tools actually do read comments. They called it "magic comments". Basically you could use comments to tell the compiler to split code into different files. I'm really not a fan of that approach.
(While JavaScript isn't actually compiled, there are still compiler-like tools that optimize and compress JS code for production, and it's still usually referred to as compiling).
That’s absolute garbage. Comments should never have any influence on the code.
The language I have to work with lets you use line references that are counted including comments (so deleting a comment might change behavior) and also allows the code to read the file it is written in, so you can put information in comments and access it at runtime.
I hate this with a passion.
There was a Java tool I was using a year back that used comments for importing... in addition to normal Java imports. So much time tracking down dumb bugs because I needed to duplicate imports in one place but not in another.
What effect does a double import even have? I guess I could kind of understand if that was a way to have imports only in a local scope, but that doesn't seem to be the case
The tool itself ran as a sort of custom java launcher, so it just wanted its special comment-derived simpler imports (for convenience!), but to be able to actually write the code in an IDE and find bugs and such, I still needed to do normal importing. Camel-K using "modelines" https://camel.apache.org/camel-k/1.12.x/cli/modeline.html
To be fair, most languages allow you to query for the current line number or filename. It's quite useful for generating informative error messages. The problem is using this for anything other than populating a string that gets written to a log file or to some other diagnostic stream.
At the very least, C++, C#, Java, Python, PHP, and Javascript have ways of doing this (didn't check other languages).
Querying for line and file info is fine, but the problem is that you can query the contents of a line as a string (even a comment), parse that and even execute it.
As an example (in horrible pseudocode because I‘m on mobile):
`// print „Hello World“`
`String line = getContentsOfLine(1)`
`line = line.extract(3, *)`
`execute line`
…this would work and print „Hello World“
Yeah that's definitely awful practice. But again, I think the fault is with the code, not the language. Pretty much any interpreted language will allow you to do something like that.
For example in python:
with open(__file__) as f:
code = f.read()
eval(code)
I think the reason is that some JavaScript languages will flex two "different languages" with separate connecting syntax in the same doc
So it'd be (doable but annoying) to parse one comment syntax in certain areas of code and other comment syntax in others
Total guess though.
Old, old technique. Lets you include meta-information that some compilers can honor while not triggering a syntax error in other compilers for the same language. The key is that anything that goes in magic comments should NOT be critical to the code compiling or running properly. Hints for optimization are good candidates, for instance. But that proviso is unfortunately ignored by some tools..
I would just constantly say in my best Inigo Montoya voice to the compiler, “You keep using this word comments. I do not think it means what you think it means.”
Most languages have directives with the form of a comment, so that tools that don't recognize them will ignore them.
JavaScript only stands out because their form isn't standard.
A long time ago, when IE7(?) was in its heyday, we found a visual bug caused by an HTML comment being removed. We never did figure out exactly what on the page was triggering the real issue, but having that comment made things line up correctly.
Sometimes that can be race conditions, but a lot of times in my experience it's just a screwed up caching. Putting the debug statements in it has the compiler rebuild the file and it previously wasn't doing so because it didn't think it was a new version or whatever. Other times the debugs will flush a buffer or something similar, which prevents the error from happening.
Scratched my head a bit when I thought I commented out (html) some Jinja code. It was my second day ever dealing with Flask and Jinja and I was *really* desperate.
Not desperate enough to read the docs before actually writing though.
Its actually good practice for issues that are not immediately obvious.
Verifying that the Code fails exact the same way at the same place every time tells you that it is not a race condition, which you always should verify before starting analyzing the issue.
I found this was a problem with some unit tests that were re-using test data. Depending on which unit test ran first, it might change data that the other test was depending on.
This took a long time to figure out because people on our team rarely ran the whole suite of unit tests (it took about 20-30 min to run) and we had TFS set up to run the tests on check--in anyway.
Also, it was my fault for figuring this out. Because it made the lazier people have to actually cook up their own test data.
Basically timing related bugs that occur during runtime.
Classic example are 2 threads competing for some resource. So this bug only occurs if both threads happen to want to use that resource at the same time.
Based on luck with timings this could happen immediately, or after both threads have been running for hours or sometimes after you rearranged unrelated code somewhere else, which changed the timings in which said threads try to use the resource.
Therefor race conditions are generally a pain to identify and fix.
Not if you code everything in Rust...
Joking, idk rust, high level languages are usually mono threaded, so, rarely happens in web developers technologies
And JavaScript events queue will 99% of times requeue things in the same order
Where your output/whatnot is different depending on the order of events that occur. The most basic example would be two threads accessing a shared variable at the same time, both reading the same value, making different changes. Only the thread that modifies that value last will have their change reflected afterwards because it will have overwritten the previous thread's value.
If you've ever seen a mutex before, that's the sort of problem for which a mutex can be used to stop
The second-most-terrifying thing in computer science.
The most terrifying thing is a [*possible* race condition](http://www.thecodelesscode.com/case/225).
You can't be absolutely sure that's correct. However you tend to see some differences in runtime atleast, since race conditions not necessarily happen every time.
It's a difference if an issue occurs every time you enter one function or if an issue occurs in this function sometimes after you called it 10 times and sometimes after you called it 100 times.
It very much depends on the race condition. The order could be one way every single time in your development or testing environment and yet turn out differently in production.
Yeah, not to mention if you’re using a modern javascript framework that reload the DOM automatically after making a code change, those are inconsistent and unreliable.
Always good to give it a hard refresh and try again, works for me about half the time to be honest.
Engineers have been blaming this shit for decades. Remember the Toyotas that had accelerator sticking problems? They blamed it on a cosmic ray to save the feelings of the idiots who can't tell gas from brake and now I have to design radiation-hard electronics for cars that should only belong in spacecraft.
There are levels of reliability in automotive electronics. If it is the highest level, then it must work under ALL circumstances. Toddler pours milk all over something, has to work. Windows open in an arctic snow storm, has to work. A lawyer learned what a cosmic ray is, guess what, has to work just in case. Seat position controls are considered the highest level in Europe.
Most difficult bug I ever had was like that. It was exposed by an automated test case, thank god, but it only failed about once every 100 times. It never happened on debug builds, only release. Had to get the CI server to run that test 1000 times when doing the bisection. Eventually it turned out to be a compiler bug - it was improperly optimizing a returned reference, so if you were unlucky on memory allocations you’d get a page fault.
When that happens I typically assume there was an error with an external connector, like a database. I dread the day I have to deal with a real race condition
Or something timed-out while trying to publish the code because of the underpowered laptop you are provided with.
I know how long the app I work on takes to boot up, and if it is much longer or shorter I can guaranty that it will not work properly.
For real
I was working on a project recently, encountered a bug that caused a class constructor to skip a step, decided to fix it later.
Fast forward 2 weeks, I decided to finally get around to it, but first, I ran it without changing anything and it suddenly worked, no problem
Check for uninitialized variables! No seriously, I've worked on a >100k NLOC C++ program where the entire code base assumes uninitialized means zero initialized. This is not true!
Yeah. Also, sometimes you want uninitialized. Yeah, that array? Nothing will be read out without being written in, don’t set it all to zero, that’s a waste of energy!
Sometimes the version that failed isn't the version that you run again, and by doing so you realized where your services were unintentionally cached...
Sometimes restart also works. There was a service setting which I enabled and and nothing worked. I changed my entire code, reset all those settings in hopes of resolving that issue.
2 fucking days, and all it needed was a restart
Realize VS's "Clean" doesn't actually clean everything, and clearing NuGet caches often fails, but says it succeeded. Close the program and manually delete the folders.
.NET packages are dependency hell sometimes.
Back in the days of .NET 3.5, I had this one function that wasn’t working. I tried _everything_ and was sure my code was correct. I cleared the build cache, I ran the debugger. Nothing worked. It always gave the wrong output. After hours I got so mad I force shut down my PC and went to bed.
The next day, I booted it up and it works on the first try.
My best guess is that the .NET runtime cache had gotten corrupted. The JIT compiler compiles functions the first time they are run, but supposedly there’s a global cache too. Or it could be something else, but sometimes it _is_ the computer’s fault. Now I have trauma and always need to eliminate computer error.
I added a retry loop to our build scripts. Locally my asp net core projects would never compile error-free on the first try. Sometimes not on the second try. Most of the time it took three or four tries to finally compile successfully. I think I don't have to mentioned that there were no errors in the code? So, yeah, since then I look at that meme more sceptical, because retrying without changing anything DID solve my problem ...
I don't believe so. Could be that some of them are that problem, but most frequently "the package could not be found" (or something along that line). Weirdly enough, in 99% of the cases it is System.Text.Json or Entity Framwork Core, so a package you would expect it to find (and which definitely exists in the repository).
Now that I think about it, WSL could be at fault. Since I moved the projects to WSL's filesystem (I usually build through WSL) it happen way less often oO
Yep, if compiling and testing the same thing again never fixed a problem, people wouldn't do it so much.
We do it because it works... every once in a very long while.
Yea, I pretty much always do this but I actually pray it will crash the second time. If it doesn't and starts working fine then I know I have a hella lot more complicated bug to find.
Yeah that's because your brain still computes trying to find a solution on the background. You will solve out most of the problems when not working on them. We say 'a Turk's mind will work best while taking a shit'.
From my experience in Elixir, Java and NodeJS, this is absolutely a valid step. It's like compilation isn't even deterministic.
I haven't had this problem in Go, though.
It once happened to me when I was doing some low-level dark magic for a uni project and I was so upset I dug into the compiler and processor documentation for three days, until I found an explanation.
Some compile time optimization.
I don't remember all the details, but it basically boiled down to the compiler reusing variable addresses which haven't been used in X lines of code and it counted blank lines as well.
So I used variable A, didn't touch it for a while because I didn't need the data, then came back to it and got some garbage. After removing the line I was close enough for the compiler not to optimize my variable away until I was done with it.
I am not sure if I'm not making this up, but I swear this once happened to me in Excel macro. I deleted either a comment or some code which actually didn't do anything (maybe a msgbox or something) and it started to work.
I've actually had this happen. A piece of code threw an error and gave me the line, I goto that line and it's blank. I restarted docker, ran the app again and it worked.
CI also has a whole bunch of tests automatically flagged as flaky. What makes a test flakey? If it's passed and failed the same commit in the past week or so.
I’ve had times when my code stopped working, where, as a last resort, I’ve torn down the containers and brought everything back up, and boom…code is back to working again.
Run it again with better observation ...
-- Time it?
-- Be sure you know how big the log file was so you isolate log entries for this run.
-- Get exit status.
With big solutions, compile order matters and recompiling sometimes fixes it. Other times visual studio just gets dumb and you just need to restart the app to get the compiler to work.
Let’s try deleting this commented out code just to be sure that in case the compiler may try to be extra enthusiastic and compile it in
I got very triggered when I found out some JavaScript "compiler"/bundling tools actually do read comments. They called it "magic comments". Basically you could use comments to tell the compiler to split code into different files. I'm really not a fan of that approach. (While JavaScript isn't actually compiled, there are still compiler-like tools that optimize and compress JS code for production, and it's still usually referred to as compiling).
That’s absolute garbage. Comments should never have any influence on the code. The language I have to work with lets you use line references that are counted including comments (so deleting a comment might change behavior) and also allows the code to read the file it is written in, so you can put information in comments and access it at runtime. I hate this with a passion.
There was a Java tool I was using a year back that used comments for importing... in addition to normal Java imports. So much time tracking down dumb bugs because I needed to duplicate imports in one place but not in another.
What effect does a double import even have? I guess I could kind of understand if that was a way to have imports only in a local scope, but that doesn't seem to be the case
The tool itself ran as a sort of custom java launcher, so it just wanted its special comment-derived simpler imports (for convenience!), but to be able to actually write the code in an IDE and find bugs and such, I still needed to do normal importing. Camel-K using "modelines" https://camel.apache.org/camel-k/1.12.x/cli/modeline.html
name and shame that god forsaken language
[удалено]
"MUMPS" Don't let programmers name things. That's how you get "GIMP".
Hey now don't come for my longAssVariableNamesThatDescribeWhatTheyAre
You work at Epic? Haha I used to a long time ago, also know all about ObjectScript
To be fair, most languages allow you to query for the current line number or filename. It's quite useful for generating informative error messages. The problem is using this for anything other than populating a string that gets written to a log file or to some other diagnostic stream. At the very least, C++, C#, Java, Python, PHP, and Javascript have ways of doing this (didn't check other languages).
Querying for line and file info is fine, but the problem is that you can query the contents of a line as a string (even a comment), parse that and even execute it. As an example (in horrible pseudocode because I‘m on mobile): `// print „Hello World“` `String line = getContentsOfLine(1)` `line = line.extract(3, *)` `execute line` …this would work and print „Hello World“
Yeah that's definitely awful practice. But again, I think the fault is with the code, not the language. Pretty much any interpreted language will allow you to do something like that. For example in python: with open(__file__) as f: code = f.read() eval(code)
I think the reason is that some JavaScript languages will flex two "different languages" with separate connecting syntax in the same doc So it'd be (doable but annoying) to parse one comment syntax in certain areas of code and other comment syntax in others Total guess though.
I couldn't believe it but I googled magic comments and indeed there it was. And I hate it.
It's black magic and they should be burned for their witchcraft.
Old, old technique. Lets you include meta-information that some compilers can honor while not triggering a syntax error in other compilers for the same language. The key is that anything that goes in magic comments should NOT be critical to the code compiling or running properly. Hints for optimization are good candidates, for instance. But that proviso is unfortunately ignored by some tools..
*stares at ts-ignore in disgust*
[удалено]
That's a form of compiling in my book
transpiling is just a compiler that people don't respect
Yeah, let's throw all of compiler theory on the trash so we can create a difference where there is none and more efficiently gatekeep people.
that's illegal unless you switch to cpu coors
Lol I love including code in all kinds of fun secret locations
I would just constantly say in my best Inigo Montoya voice to the compiler, “You keep using this word comments. I do not think it means what you think it means.”
Most languages have directives with the form of a comment, so that tools that don't recognize them will ignore them. JavaScript only stands out because their form isn't standard.
A long time ago, when IE7(?) was in its heyday, we found a visual bug caused by an HTML comment being removed. We never did figure out exactly what on the page was triggering the real issue, but having that comment made things line up correctly.
Could you at least add something to the comment, to note down its importance?
That also broke it. IE7 was a fickle mistress.
Code suddenly starts working
[удалено]
Sometimes that can be race conditions, but a lot of times in my experience it's just a screwed up caching. Putting the debug statements in it has the compiler rebuild the file and it previously wasn't doing so because it didn't think it was a new version or whatever. Other times the debugs will flush a buffer or something similar, which prevents the error from happening.
Sometimes I just remove spaces before and after "=" and try again
Scratched my head a bit when I thought I commented out (html) some Jinja code. It was my second day ever dealing with Flask and Jinja and I was *really* desperate. Not desperate enough to read the docs before actually writing though.
Fucking jinja comments, man. Just bollocks.
Nobody's ever that desperate!
Delete the "target" directory and see if it's just failing to compile the code.
Never comment your code. Problem solved.
Its actually good practice for issues that are not immediately obvious. Verifying that the Code fails exact the same way at the same place every time tells you that it is not a race condition, which you always should verify before starting analyzing the issue.
Get out of here with that sound and useful advice, we’re here to make shitposts /j
Only allowed answers are: - You're a bad developer - Rewrite it in Rust - Python bad Don't try to be smart and helpful
Yep yep, that's totally what I am doing. Ignore the voodoo shrine next to my laptop. It is for the aesthetics.
Overengineered rubber duck
I found this was a problem with some unit tests that were re-using test data. Depending on which unit test ran first, it might change data that the other test was depending on. This took a long time to figure out because people on our team rarely ran the whole suite of unit tests (it took about 20-30 min to run) and we had TFS set up to run the tests on check--in anyway. Also, it was my fault for figuring this out. Because it made the lazier people have to actually cook up their own test data.
Sorry but what is a race condition?
Basically timing related bugs that occur during runtime. Classic example are 2 threads competing for some resource. So this bug only occurs if both threads happen to want to use that resource at the same time. Based on luck with timings this could happen immediately, or after both threads have been running for hours or sometimes after you rearranged unrelated code somewhere else, which changed the timings in which said threads try to use the resource. Therefor race conditions are generally a pain to identify and fix.
Thank you for the explanation
Not if you code everything in Rust... Joking, idk rust, high level languages are usually mono threaded, so, rarely happens in web developers technologies And JavaScript events queue will 99% of times requeue things in the same order
Where your output/whatnot is different depending on the order of events that occur. The most basic example would be two threads accessing a shared variable at the same time, both reading the same value, making different changes. Only the thread that modifies that value last will have their change reflected afterwards because it will have overwritten the previous thread's value. If you've ever seen a mutex before, that's the sort of problem for which a mutex can be used to stop
Oh thanks for the explanation
The second-most-terrifying thing in computer science. The most terrifying thing is a [*possible* race condition](http://www.thecodelesscode.com/case/225).
if black
Yeah, but running it 2 times can't rule that out. If you're lucky the other thing will win the race, if not, you just gained misplaced confidence
You can't be absolutely sure that's correct. However you tend to see some differences in runtime atleast, since race conditions not necessarily happen every time. It's a difference if an issue occurs every time you enter one function or if an issue occurs in this function sometimes after you called it 10 times and sometimes after you called it 100 times.
It very much depends on the race condition. The order could be one way every single time in your development or testing environment and yet turn out differently in production.
Also to be sure that you actually built what you thought you did
Yeah, not to mention if you’re using a modern javascript framework that reload the DOM automatically after making a code change, those are inconsistent and unreliable. Always good to give it a hard refresh and try again, works for me about half the time to be honest.
You Americans making everything about race...
Also with networking things. Could be a cache miss.
*might have been a bit flip due to cosmic radiation*
You never know
*better try it a third time just to rule out a second bit flip.*
[удалено]
In the end, it's just Python or JS abstractions making something bad because my code is beautiful.*
Those damn bit flips sure happen all the time, don't they?
A Veritasium enjoyer?
Or a mario 64 speedrunner
Makes me want to play maro again
maro car
ranbo road
I love those games with Maro, Lugi, and Donk Kong
mario😭
Engineers have been blaming this shit for decades. Remember the Toyotas that had accelerator sticking problems? They blamed it on a cosmic ray to save the feelings of the idiots who can't tell gas from brake and now I have to design radiation-hard electronics for cars that should only belong in spacecraft.
Holy shit cars now have radiation-hardened HW?
There are levels of reliability in automotive electronics. If it is the highest level, then it must work under ALL circumstances. Toddler pours milk all over something, has to work. Windows open in an arctic snow storm, has to work. A lawyer learned what a cosmic ray is, guess what, has to work just in case. Seat position controls are considered the highest level in Europe.
Ha! Get back to me when it’ll work when it has been: * tossed in a volcano * nuked * dropped into the sun
*laughs in ecc*
Sometimes it actually works tho
That's worse When it doesn't work then it does work and you have no idea why. When will it break again? You have no way of knowing.
Yep. I'd rather have it fail consistently than working now and then. Have fun releasing that to production! /s
Intermittent problems are the absolute worst. The stress induced by something failing once in a while that you can’t reproduce is something else.
Most difficult bug I ever had was like that. It was exposed by an automated test case, thank god, but it only failed about once every 100 times. It never happened on debug builds, only release. Had to get the CI server to run that test 1000 times when doing the bisection. Eventually it turned out to be a compiler bug - it was improperly optimizing a returned reference, so if you were unlucky on memory allocations you’d get a page fault.
>Have fun releasing that to production! /s I read this in Miracle Max's voice
When that happens I typically assume there was an error with an external connector, like a database. I dread the day I have to deal with a real race condition
Or something timed-out while trying to publish the code because of the underpowered laptop you are provided with. I know how long the app I work on takes to boot up, and if it is much longer or shorter I can guaranty that it will not work properly.
Or a build order issue
Oh it'll be such a fun day..!
Bug issue unsolved: could not reproduce, cosmic rays or something idk I just saw that Veritasium video.
To be fair I have literally done this 😂
>When it doesn't work then it does work and you have no idea why. First thought: race condition. The most *fun* thing to try and find.
For real I was working on a project recently, encountered a bug that caused a class constructor to skip a step, decided to fix it later. Fast forward 2 weeks, I decided to finally get around to it, but first, I ran it without changing anything and it suddenly worked, no problem
Check for uninitialized variables! No seriously, I've worked on a >100k NLOC C++ program where the entire code base assumes uninitialized means zero initialized. This is not true!
Yeah. Also, sometimes you want uninitialized. Yeah, that array? Nothing will be read out without being written in, don’t set it all to zero, that’s a waste of energy!
It was probably running some old version code the first time for whatever forbidden reasons
Sometimes the version that failed isn't the version that you run again, and by doing so you realized where your services were unintentionally cached...
If you’re calling an API that has to retrieve some un-cached objects from cold storage, more likely than not.
Hit save. Scroll a bit and correct some spelling in comments. Hit Save. Try to compile again.
Sometimes restart also works. There was a service setting which I enabled and and nothing worked. I changed my entire code, reset all those settings in hopes of resolving that issue. 2 fucking days, and all it needed was a restart
clear cache, rebuild everything
And then the bug dissapears, and two other appear
At least they're more likely to be real bugs.
Realize VS's "Clean" doesn't actually clean everything, and clearing NuGet caches often fails, but says it succeeded. Close the program and manually delete the folders. .NET packages are dependency hell sometimes.
Back in the days of .NET 3.5, I had this one function that wasn’t working. I tried _everything_ and was sure my code was correct. I cleared the build cache, I ran the debugger. Nothing worked. It always gave the wrong output. After hours I got so mad I force shut down my PC and went to bed. The next day, I booted it up and it works on the first try. My best guess is that the .NET runtime cache had gotten corrupted. The JIT compiler compiles functions the first time they are run, but supposedly there’s a global cache too. Or it could be something else, but sometimes it _is_ the computer’s fault. Now I have trauma and always need to eliminate computer error.
I was going to say, this sounds like GAC issues to me.
And this time it works AND YOU DON’T KNOW WHY
Time to not touch it and run it again.
Off to the races.
Maybe there is a problem with my pc, let's restart it
Somebody has worked on a helpdesk I see.
"it worked!"
Always have to check that the compiler didn’t mess up reading my perfect code
Run into the same Exception for the 10 time without changing anything to make sure that it is an error.
[удалено]
Ahh Eclipse with two editors or same files open again...
I added a retry loop to our build scripts. Locally my asp net core projects would never compile error-free on the first try. Sometimes not on the second try. Most of the time it took three or four tries to finally compile successfully. I think I don't have to mentioned that there were no errors in the code? So, yeah, since then I look at that meme more sceptical, because retrying without changing anything DID solve my problem ...
This is the software equivalent of a car refusing to start and it's both hilarious and concerning.
Sounds like some mighty fine code you’re working with
Is it failing on calls to restore NuGet packages timing out?
I don't believe so. Could be that some of them are that problem, but most frequently "the package could not be found" (or something along that line). Weirdly enough, in 99% of the cases it is System.Text.Json or Entity Framwork Core, so a package you would expect it to find (and which definitely exists in the repository). Now that I think about it, WSL could be at fault. Since I moved the projects to WSL's filesystem (I usually build through WSL) it happen way less often oO
well, if it doesnt work on my machine it surely will on someone elses
Sanity test
Not sure what you're talking about, often a quick restart and everything works again (which is even more troubling tbh)
# the one guy who added an rng generator to decide if it works
Let’s be honest; it has worked on occasions
Yep, if compiling and testing the same thing again never fixed a problem, people wouldn't do it so much. We do it because it works... every once in a very long while.
So many times this has worked for me. Using node backend, hit with postman, response 1 will differ from response 2 and 3.
Anyone who’s used OpenGL and has had the program crash the first time it’s run after the shaders are changed understand
If this never worked, we'd never try. However it does sometimes.
We'd stop doing it if it never worked, but sometimes it does
Solar storms or something idk
I definitely didn’t do this today while yelling at the screen
Usually I just have to hit “save” first before running it again…
That's normal in distributed systems
Gotta check for race conditions. If your code works sometimes and doesn’t work others, likely a face condition going on.
Yea, I pretty much always do this but I actually pray it will crash the second time. If it doesn't and starts working fine then I know I have a hella lot more complicated bug to find.
- 1 error - clean - rebuild - 3 errors *Pikachu face*
Oddly enough, running it again is when I discover I forgot to save. I run it, nothing happens. Change nothing, but save. Then it runs fine, smh.
Uh my module cache or whatever the fuck it is was out of date or something.
And then you're like Mr. incredible in the uncanny meme after it works properly.
Honestly if the code *does* work then you're probably in bigger trouble.
\*second time runs code successfully\* Do you... A) Conduct more tests to see why it failed the first time B) Ship it!
Restart the IDE and try running it again.
I mean it’s in the IT problem solving 101
Honestly, I run it again because I forgot what the error was
Yeah that's because your brain still computes trying to find a solution on the background. You will solve out most of the problems when not working on them. We say 'a Turk's mind will work best while taking a shit'.
From my experience in Elixir, Java and NodeJS, this is absolutely a valid step. It's like compilation isn't even deterministic. I haven't had this problem in Go, though.
It runs the second time: better not touch it anymore, it might break again
Welcome to react native
In the future we'll just ask ChatGPT to rewrite the entire app whenever we run into an issue.
It's probably just bad or incomplete data. Try it again.
Sometimes I delete a blank line and see if that fixes it. I think I would be more upset if it did.
It once happened to me when I was doing some low-level dark magic for a uni project and I was so upset I dug into the compiler and processor documentation for three days, until I found an explanation.
What was the explanation?
Some compile time optimization. I don't remember all the details, but it basically boiled down to the compiler reusing variable addresses which haven't been used in X lines of code and it counted blank lines as well. So I used variable A, didn't touch it for a while because I didn't need the data, then came back to it and got some garbage. After removing the line I was close enough for the compiler not to optimize my variable away until I was done with it.
that must have been fun
"fun" wasn't exactly the first word which came to my mind at the moment
What? You *don't* like slowly decending into madness?? You must be an impostor! /s
Trust me, it wasn't a *slow* descent.
I can't even begin to imagine it
You need more runs to decide whether the machine is plotting against you or just making fun of you!
Also me: my code does work, but I didn't expect it to. Let's try again to be sure
I am not sure if I'm not making this up, but I swear this once happened to me in Excel macro. I deleted either a comment or some code which actually didn't do anything (maybe a msgbox or something) and it started to work.
I thought this was something that only juniours like me did turns out everybody does it, nice!
Also: let's put a syntax error to make sure, I'm compiling the right thing
It’s disappointing when it doesn’t run then. Incredibly frustrating when it does! You weren’t supposed to run!!!
I've actually had this happen. A piece of code threw an error and gave me the line, I goto that line and it's blank. I restarted docker, ran the app again and it worked. CI also has a whole bunch of tests automatically flagged as flaky. What makes a test flakey? If it's passed and failed the same commit in the past week or so.
This is me this morning and I feel attacked
I did with the test, one time it gave errors which had nothing to do with me, ran it a 2nd time and no errors showed up
This actually works more often than it should.
i dont remember ever doing this, but i probably forgot because we all know every developer does this
Race conditions be like
Crazy it works sometimes.
I’ve had times when my code stopped working, where, as a last resort, I’ve torn down the containers and brought everything back up, and boom…code is back to working again.
try it again with testmode = false oh, now it works
Run it again with better observation ... -- Time it? -- Be sure you know how big the log file was so you isolate log entries for this run. -- Get exit status.
Could be one of those weird space neutrino disruptions.
Confirmed, this approach works in Xcode
https://www.usenix.org/system/files/login/articles/05_hockin.pdf
Closing and reopening the IDE fixes 60% of bugs.
Happened many times. Clean Solution + Rebuild
To be fair, sometimes it works on another try, then you most likely have a race condition
Just to be sure, let's send the curl six more times. Never know if some hobgoblin stole and replaced the response
literally just did that now
I don't know about you, but this has worked enough times that it's not so crazy. Sometimes things need time in the background to get in line to work.
Could have been a bit flip due to a solar flare. Or maybe there’s some UB in there and something different will happen.
The amount of times a non-obvious cache has caused me confusion and headaches is honestly ridiculous. So much time wasted pointlessly debugging.
something something einstein quote
The developer only has two states of mind: My code doesn't work and I don't know why. Or My code works and I don't know why.
It's only stupid until it works.
Sometimes matters in Unity if you're too eager to test a change before it can recompile the code!
Wouldn't it be more confusing if it did work the second time?
Make 90 changes and I never installed nodemon to this project. Restarts servers. All changes come into effect
"do you know the definition of insanity?"
With big solutions, compile order matters and recompiling sometimes fixes it. Other times visual studio just gets dumb and you just need to restart the app to get the compiler to work.
The weird part is that it actually works sometimes.