4 ms·
Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Downvote me if you wan
by lixtra 6y ago
Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits.
Downvote me if you want to open a bug ticket with the vendor and wait a week for the fix.
Upvote me if you’d give it a try to restart with a switch to ignore assertions.
You may abstain if you never shipped a bug.
Edit: not to forget that this website runs on lisp which violates all three. Was it really a bad choice for the website?
- unionpivo 6y ago> Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Several points: 1. Most of such critical components have several different and independent implementations, with analog backup (if possible). 2. You are arguing one specific safety critical case, that 99.999% or even more programmers will never face, should somehow inform decision about general purpose programming language. 3. Even if you are working in such safety critical situation, you should not really on assertion bypass, but have separate emergency procedure, which bypasses all the checks and try's to force the issue. (ever saw a --force flag ?) Because what happens in reality, is developer encounters a bug (maybe while its still in development), notice you can bypass it by disabling assertions (or they are disabled by default), log it as a low priority bug, that never gets fixed. Then a decade later me or someone like me is cursing you because you enterprise app just shit the bed, and is generating tons of assertion warnings, even when it running normally, so I have to figure out, which of them are "just normal" program flow, and which one just caused an outage. I never experienced situation like you described, but I have experienced behavior like I wrote above, too many times. Botom line is: - don't assert if you don't mean it - if you need bypass for various runtime checks, code one in explicitly. Edit: Hacker News is written in ARC which is schema dialect. ARC doesn't have assertions as far as i can tell. ARC doesn't have its own runtime and is run on racket language, that has optional assertion, that exit the runtime if they fail https://docs.racket-lang.org/ts-reference/Utilities.html https://docs.racket-lang.org/ts-reference/Utilities.html
- jrockway 6y agoI agree with this. Nuclear reactors are a special case of systems where removing energy from the system makes it more unsafe, because it generates its own energy and without a control system it will generate so much energy that it destroys itself (and due to the nature of radiation, destroys the surrounding suburbs too). With most systems, the safest state is off. CNC machine making a weird noise? Smash that e-stop. Computer overheating? Unplug it. With this in mind, "assert" transitions the system from an undefined state to an inoperative state, which is safer. That isn't to say that that you want bugs in your code, and that energizing some system is free of consequences. Your emergency stop of your mill just scrapped a $10,000 part. Unplugging your server made your website go down and you lost a million dollars in revenue. But, it didn't kill someone or burn the building down, so that's nice.
- BlueTemplar 6y agoModern nuclear reactors are designed and built with the expectation that when they melt down, the results aren't catastrophic (at least for the outside world).
- WalterBright 6y agoSee my previous reply. Your reactor design is susceptible to a single point of failure, and, how do I say it strongly enough, is an utterly incompetent design. Bypassing assertions is not the answer.