A self-testing application?

It’s only more complicated because nobody coded that yet. But indeed it would merge some aspects of CI into the server itself. That’s probably not a very good idea except for a fun project (for some definition of fun).

Isn’t this just a more complicated way to do CI?

Safe healing, I think it could if you meant to automatically get back in time instead of trying to invent a new patch to fix itself. Like, if a test fails or that some of the web pages display errors, you could code something using git bissect that would find the culprit and go back in time enough to work again, until YOU fix the problem and push the fixed version.

If you code for the “happy” path—and make your pattern matches really strict—you will see it in your error logs every time your application encounter something unexpected. You can then decide on what to do in these discovered cases.

Besides the stuff that is build in to OTP (i.e. Supervision), patterns such as safety-valves and fuses can help you detecting and handling errors in regards to third-party systems—this way you can detect if something is wrong in your circuits and act accordingly

You should probably view this in context. Any “true” AI – like a sentient, intelligent being – that is much better and more durable than us, will likely have a stream of consciousness. Part of that includes continuously pulling diagnostic information and evaluating it; sort of like you will know if you suddenly got a leg cramp in the next milliseconds of it happening.

Truth is, having an artificially sentient entity will mean a lot of not-so-energy-efficient activities happening all the time; it cannot just react to things, it has to take the initiative and continuously process sensory information… sort of like us.

To create a software that fixes itself you’ll need a ton of specifications, goal-oriented programming, and you also must have a feedback mechanism (which answers the question “is the result of this function correct”?). I am not saying it’s impossible; it definitely is possible. And you’ll also probably need some logic programming as well (Prolog).

Thanks! I’ve wanted an Elixir equivalent of Haskell’s stack test --file-watch

Have you looked at mix test.watch?

A far cry from HAL but it allows you to have your tests re-ran as you are modifying your code.

Actually, it’s a piece of an ETL pipeline that will run daily. And so I’d it to refuse to run if the input format has changed too much. It’s Haskell that I’m going to try implementing in Elixir: GitHub - public-law/nevada-revised-statutes-parser: Parses the Nevada NRS into well formed JSON · GitHub

My tests mostly run on fixtures which are full files: nevada-revised-statutes-parser/test/fixtures at master · public-law/nevada-revised-statutes-parser · GitHub

I know some embedded engineers write code that checks memory content at runtime to ensure the code being executed is actually what is supposed to be executed. Something to do unstable hardware. And of course fixing that after detecting mismatch.

Correct me if I’m interpreting this incorrectly, but isn’t what you’re describing like a CI pipeline that runs when certain conditions are met rather than on code commit?

I’m interested since I working on an app that tests test quality and this might be in the same wheelhouse.