diff --git a/docs/State-of-play.md b/docs/State-of-play.md index ea48db0..c7c9832 100644 --- a/docs/State-of-play.md +++ b/docs/State-of-play.md @@ -1,5 +1,31 @@ # State of Play +## 20260504 + +My monster, she builds! + +Admittedly, she doesn't yet do much, but... + +### Evaluating editors + +My favourite Clojure editor, [LightTable](http://lighttable.com/), went dark — or at least, ceased to be actively developed — about five years ago; and as it depends on libraries which are not available in Debian Trixie, the published executable will no longer run. At about the time it died I did have a look at whether it would be feasible for me to take over maintenance of it, and I came to the conclusion that it would be too much work. + +#### VS Codium + +So I switched to [VSCodium](https://vscodium.com/), which is a fork of Microsoft's supposedly open source VS Code editor with all the proprietary Microsoft shit taken out, some years ago. VS Codium, like VS Code, is built on [Electron](https://www.electronjs.org/), which means it's built, fundamentally, on a JavaScript library stack, with all the instability and insecurity that implies. I have been getting increasingly nervous about my use of VSCodium in the light of [increasingly frequent attacks](https://krebsonsecurity.com/2025/09/18-popular-code-packages-hacked-rigged-to-steal-crypto/) on the JavaScript ecosystem. + +This is not to say I dislike VSCodium; I don't. It's been, mainly, a pleasure to use. It's stable, it doesn't get in my way, it's highly configurable and extensible. I just don't have the bandwidth to monitor and audit the libraries it is using. + +#### Emacs + +In April had one of my periodic attempts to switch back to [Emacs](https://www.gnu.org/software/emacs/) — that ancient editor which is Generally Not Used Except by Middle Aged Computer Scientists. Back in the day I didn't use Emacs for editing Lisp, of course, because back in the day I was using real Lisps like Portable Standard Lisp and InterLisp which had built in structure editors. But I used to use Emacs for almost everything else, including reading my mail, browsing [Usenet](https://en.wikipedia.org/wiki/Usenet), and editing shell scripts and programs in the languages of [οἱ](https://en.wiktionary.org/wiki/οἱ#Ancient_Greek) [πολλοί](https://en.wiktionary.org/wiki/πολλοί#Ancient_Greek). And given that the substrate of Post Scarcity is (still) being written in C, just as KnacqTools was back in the day, why not Emacs? After all, it is extremely stable, and extraordinarily configurable and extensible. + +The answer, dear reader, is that Emacs is determined to get in my way in every possible way. It is obnoxious to use. Every key binding, every mouse action, which works in every other software package on a modern windowed user interface does something completely different in Emacs (and vice versa). Your muscle memory no longer works. Every keystroke, every command action, has to be carefully thought about. You have two choices: you can switch entirely to living only in Emacs and relearning the Emacs keybindings, or to live in a permanent hell of confusion, overthinking and self-doubt. And, in this day and age, there are many things which Emacs does not do nearly so well as more modern packages do. You **can** browse the web in Emacs — of course you can! — but, dear reader, you really wouldn't want to. + +#### Eclipse + +When I finally switched away from using Emacs for everything + ## 20260503 Right, so, it's a week since my last entry. The version of eval/apply copied from `0.0.6` still doesn't compile, let alone work. There are reasons. I've been ill — my brain really is fucked — and I've had outdoor work it's felt urgent to do. diff --git a/src/c/ops/dump.h b/src/c/ops/dump.h new file mode 100644 index 0000000..e69de29 diff --git a/src/c/ops/eval_apply.c b/src/c/ops/eval_apply.c index ad8f3e6..0473523 100644 --- a/src/c/ops/eval_apply.c +++ b/src/c/ops/eval_apply.c @@ -16,7 +16,6 @@ #include #include - #include "debug.h" #include "environment/privileged_keywords.h" diff --git a/src/c/payloads/float.h b/src/c/payloads/float.h new file mode 100644 index 0000000..9cfc018 --- /dev/null +++ b/src/c/payloads/float.h @@ -0,0 +1,22 @@ +/** + * payloads/float.h + * + * A floating point number. + * + * (c) 2026 Simon Brooke + * Licensed under GPL version 2.0, or, at your option, any later version. + */ + +#ifndef __psse_payloads_float_h +#define __psse_payloads_float_h + + +/** + * @brief a floating point number. At this stage it's only 64 bits wide, but + * we could/should use the full 128 bits. + */ +struct float_payload { + long double value; +}; + +#endif \ No newline at end of file