Often this is because some part of either the IDE or the build chain failed to clear some part that needed to be cleared. Especially for large projects and on older machines, compiling takes a while. Usually only small changes are made during programming, so to optimize the work flow it tries to only re-compile what absolutely needs to be recompiled. This speeds up the process, allowing for iterative development without waiting a long time.
I remember working with Java on my old Pentium 1 system and it taking easily 45 mins to compile something. That’s where the xkcd 303 got its origins. https://xkcd.com/303/
But sometimes this fails in some way, which can lead to very bizarre results. Often causing headscratches figuring out what went wrong, assuming the fault to be in what the developer did. A quick way to check is to simply delete the intermediate compiler result (often the obj or bin dir, or both) and do a whole fresh compile. Sometimes it’s enough to simply compile again, often when the error was caused by some race condition in the build process. For example something being flagged as needing cleanup, but the build being done before the cleanup was done. A recompile at that point will probably work as the cleanup has most likely happened.
Sometimes shit’s just cursed and there is no explanation, probably angered some coding god somewhere. Perform the proper ritual and you’re good to go.
Oh yeah, I was mostly just kidding with the LLM compiler bit. I’ve run into issues with incremental compiles working on the JVM ecosystem myself (mainly Kotlin though, as my work in the ecosystem took place early this decade). Still didn’t want to clean build every time though, because on an M1 Pro it was about 5 minutes to build some of our backend services from scratch and I tend to like a really rapid feedback loop for testing, changing code, recompiling, re-testing.
These days my docker container reloads the entire project when I edit any file, but it takes 10 seconds since there’s no need to compile anything since it’s Python. Pure bliss in comparison (the development pace that is; I actually liked Kotlin more as a language even though Python is fine)
Android had a quick deploy feature where you could push minor changes like text or layout updates to the phone while testing without having to actually rebuild it. Like press button and a couple seconds later it updates.
It without fail over years and years of trying to use it, always failed frequently, and you’d end up with unexpected behavior or crashes. For a time anyway, they tried to default it to on.
Im not sure what the current state of it is today, I just stopped bothering to test it out.
Yep, a clean build often got rid of the weirdest bugs I had, because some shared memory was misaligned, because, as you said, because of compile optimization, some parts didn’t know about the changes
Often this is because some part of either the IDE or the build chain failed to clear some part that needed to be cleared. Especially for large projects and on older machines, compiling takes a while. Usually only small changes are made during programming, so to optimize the work flow it tries to only re-compile what absolutely needs to be recompiled. This speeds up the process, allowing for iterative development without waiting a long time.
I remember working with Java on my old Pentium 1 system and it taking easily 45 mins to compile something. That’s where the xkcd 303 got its origins. https://xkcd.com/303/
But sometimes this fails in some way, which can lead to very bizarre results. Often causing headscratches figuring out what went wrong, assuming the fault to be in what the developer did. A quick way to check is to simply delete the intermediate compiler result (often the obj or bin dir, or both) and do a whole fresh compile. Sometimes it’s enough to simply compile again, often when the error was caused by some race condition in the build process. For example something being flagged as needing cleanup, but the build being done before the cleanup was done. A recompile at that point will probably work as the cleanup has most likely happened.
Sometimes shit’s just cursed and there is no explanation, probably angered some coding god somewhere. Perform the proper ritual and you’re good to go.
Oh yeah, I was mostly just kidding with the LLM compiler bit. I’ve run into issues with incremental compiles working on the JVM ecosystem myself (mainly Kotlin though, as my work in the ecosystem took place early this decade). Still didn’t want to clean build every time though, because on an M1 Pro it was about 5 minutes to build some of our backend services from scratch and I tend to like a really rapid feedback loop for testing, changing code, recompiling, re-testing.
These days my docker container reloads the entire project when I edit any file, but it takes 10 seconds since there’s no need to compile anything since it’s Python. Pure bliss in comparison (the development pace that is; I actually liked Kotlin more as a language even though Python is fine)
Android had a quick deploy feature where you could push minor changes like text or layout updates to the phone while testing without having to actually rebuild it. Like press button and a couple seconds later it updates.
It without fail over years and years of trying to use it, always failed frequently, and you’d end up with unexpected behavior or crashes. For a time anyway, they tried to default it to on.
Im not sure what the current state of it is today, I just stopped bothering to test it out.
Yep, a clean build often got rid of the weirdest bugs I had, because some shared memory was misaligned, because, as you said, because of compile optimization, some parts didn’t know about the changes
Ive had some build bugs where a clean build didnt fix it, restarting the IDE didn’t fix it, but rebooting the computer did.
I imagine some long running process even after the IDE is closed had been corrupted or something.