HN user
John Koza has something like three or four books on Genetic Programming. It's all in Lisp and I enjoyed working with different examples from his books. If I ever have enough free time, I'd like to go back and work with it again for a while.
Thank you for taking the time to drop this link. I had exactly the question I think you anticipated: "Where can I get a really well-made washer and dryer?"
Here's my take. Asserts are a kind of error handling. They handle situations where the code can tell that it's off the rails. It might be off the rails due to a hardware error or a software implementation error, e.g., a 'can't happen' situation.
We didn't have debug-only asserts. Asserts were enable in the software we verified and shipped.
It took a while for developers to be able to determine when a situation called for an assert, and when it called for what might be called traditional error handling.
The strategy of shipping with asserts enabled kind of worried some folks. They were concerned that it might assert in front of a customer. I understand the concern, but in our domain, if you're doing an OB exam with the ultrasound system and you have a choice of asserting or showing a femur length measurement of -1039cm, which is better?
We didn't have many asserts in the field. We had a lab where we had about 25 - 30 ultrasound machines running embedded tests constantly. Each machine was connected to a JTAG debug board, so we could flash new code into the system and so we could set a breakpoint on the assert routine itself and save a "core dump" for subsequent debugging without having to try to reproduce the system state that led to the assert.
The whole lash-up evolved over a period of years. It worked well, so far as I know.
One mitigating factor was that our systems were class B devices. They were always supposed to be used by a medically trained professional that had the ability to take over if the system asserted, or power failed, etc.
Happy to try to answer any questions about this.
This has been exactly my strategy when writing software for medical devices, in my case, ultrasound systems.
You have to help other developers understand how and when to use asserts, and then you have to test the developed device very well, so that it won't assert in the field.
Yet if it does assert in the field, it's highly likely that it will get a lot of management attention.
Yeah, I was thinking of a different book. Here's the link to the other one:
https://www.amazon.com/Object-Oriented-Programming-COMMON-LI...
I have had this book for many years. I remember the toy expert system ("Otto") and enjoyed learning from the example. If I remember correctly the author makes good use of CLOS in the book.
Looks neat and I'd like to try it. I wonder how well it would work from within a GNU Emacs shell buffer (comint based, I think) running bash. Has anyone given this a shot?
Yep. My 2012 Tundra still runs well and looks good. The only issue is that over time the steering wheel has been polished smooth by all my driving over the years. I am at 160,000 miles and expect to get to at least 250,000.
At a large insurance company I worked for, management set a target of 80% test coverage across our entire codebase. So people started writing stupid unit tests for getters and setters in Java DTOs to reach the goal.
I attended many TOC conferences in the 90s and early 2000s. Eli Goldratt was famous for saying "Tell me how you'll measure me, and I'll tell you how I will behave."
I was somewhat reminded of Larry Wall's newsreader, 'rn', as I read the description of Orange Site Hit. I invested a lot of hours on Nutnews back in the day.
Eli Goldratt has entered the chat...
I hope the following from Wikipedia is helpful:
The computer had 2048 words of erasable magnetic-core memory and 36,864 words of read-only core rope memory. Both had cycle times of 11.72 microseconds. The memory word length was 16 bits: 15 bits of data and one odd-parity bit. The CPU-internal 16-bit word format was 14 bits of data, one overflow bit, and one sign bit (ones' complement representation). [1]
Can you say how your tool compares to Vector PC-Lint in terms of analyzing compliance w/r/t MISRA C and C++?
Wasn't familiar with RACI acronym:
RACI is an acronym derived from the four key responsibilities most typically used: responsible, accountable, consulted, and informed. It is used for clarifying and defining roles and responsibilities in cross-functional or departmental projects and processes.
I wish more people briefly defined acronyms at first usage in a document.
Same. I love the idea of ditching the Proton Mail bridge app on my Macs. It's been a frequent source of configuration and update headaches for me.
This has been my take as well. There is a lot of disruption in a company when a key part, like the FPGA that serves as a communications nexus in the product goes EOL and everyone scrambles for a year trying to engineer in a replacement.
Buy enough parts for expected product life, make good use of the time you didn't waste on scrambling, and when your product is EOL sell any left-over parts on the secondhand markets.
"If you drop your DVM and it still works, it's a Fluke."
Can you say a little bit about the possible risks from hot silicon being in contact with the water? I have not heard of this before.
Perfect. Appreciate the ref.
Please say more!
Will check it out! Ty!
This reminds me of an Alan Watt's talk on alternating levels of order and chaos in nature.
I asked ChatGPT 4.0 what LMR meant as applied to coaxial cable. It gave me an excellent response, including that LMR is a trademark of Times Microwave Systems.
I rarely use search engines anymore. I'll bet the same is true for many people.
If the Five Whys appeals to you, you might also like the "Thinking Process Tools" of Goldratt's Theory of Constraints.
That being said, you always have to avoid fooling yourself when building logic diagrams. It's easy to do.
Thank you so much for the link to the postmortem. I will be sharing it and discussing it with my colleagues. We are currently working on the embedded software for an AED.
You might enjoy this article on the Therac-25 [1]. It's kind of the standard example of how errors in software can wind up harming people. I have written medical device software for about 30 years. In my experience, delivering high quality software for Class B and Class C devices is both challenging and expensive.
Snap-On tools are great. They also cost an arm and a leg. Yet if you put a 3' pipe on your 1/2" ratchet and break the ratchet, the tool guy will fix it or replace it on his next visit.
Following up my own post, I also remember the hardware guys having occasional phone calls with some guy known only as "Larry" at Intel. I'm guessing he was a microcode guy or some such. Would be interesting to know more about him.
I worked at Applied Microsystems (now defunct). We made in-circuit emulators and did one for the 80960CA variant. I remember that processor had an undocumented (IIRC) feature called "Incremental Trace" that would allow the emulator to keep track of what the processor was doing. We used it to develop an execution trace disassembler for the processor.
I seem to remember HP/Boise was using a lot of the CA parts for use in printers. They had one of our emulators, and I remember that we once got a report of the emulator probe tip having caught fire (!) due a short or some such.
I enjoyed working with the CA part. I also worked with the 80960MX part. Now, that was an odd processor!
Might it be this article?