Have you seen Common Lisp’s condition system? It’s a step above exceptions, because one can signal a condition in low-level code, handle it in high-level code and then resume back at the lower level, or anywhere in between which has established a restart.
> It would need to be the case that code that doesn’t want to handle errors (like Max’s simple website) doesn’t have any error handling code, but it’s easy to add, and common patterns (e.g. “retry this inner operation N times, maybe with back off and jitter, and then fail this outer operation, either exiting the program or leaving unaffected parts running”) are easy to express
Lisp’s condition system can handle that! Here’s a dumb function which signals a continuable error when i ≤ 3:
(defun foo ()
(loop for i from 0
do (if (> i 3)
(return (format nil "good i: ~d" i))
(cerror "Keep going." "~d is too low" i))))
If one runs (foo) by hand then i starts at 0 and FOO signals an error; the debugger will include the option to continue, then i is 1 and FOO signals another error and one may choose to continue. That’s good for interactive use, but kind of a pain in a program. Fortunately, there are ways to retry, and to even ignore errors completely.
If one wishes to retry up to six times, one can bind a handler which invokes the CONTINUE restart:
(let ((j 0))
(handler-bind ((error #'(lambda (c)
(declare (ignore c))
;; only retry six times
(unless (> (incf j) 6)
(invoke-restart 'continue)))))
(foo)))
If one wants to ignore errors, then (ignore-errors (foo)) will run and handle the error by returning two values: NIL and the first error.
> The unattended workaround is to have the tmux daemon spawn at login via `start-server` + enable some tmux settings like `exit-empty` plus some I can't recall regarding environment handling, but nobody does that.
I just have my terminal emulator spin up tmux when it starts, and I start my terminal emulator from my desktop, so it always runs in a clean environment.
That conflicts with the standard Emacs binding to move to the beginning of the current line. Many years ago, I switched to C-z instead, on the theory that it is really easy to type C-z C-z when I really want to suspend whatever is currently running.
Pity that (AFAICT) terminals have no concept of Super and Hyper (USB doesn’t know about Hyper, either, but at least X11 does).
> But it solves a really important problem: How to exchange markdown documents that include attachments like images, video etc. in a standard way?
Oddly enough, I was recently thinking of using RFC 822 messages with CommonMark bodies and MIME attachments as a way to store blog entries on disk, so I was considering this exact problem earlier this week (small world!). RFC 2046 specifies multipart messages, RFC 2392 specifies URI schemes for linking from the body of the message to other parts; and RFC 7763 specifies the text/markdown MIME type. There’s already a ton of tooling out there which deals with MIME, so one needn’t reinvent the wheel.
The authors’ statement that ‘unlike hallucinations, confabulations are not perceived experiences but instead mistaken reconstructions of information which are influenced by existing knowledge, experiences, expectations, and context’ is pretty compelling.
I think that it is. The article does raise some good points to consider, but at this point in my experience with it I believe that a lot of the complexity of Kubernetes is not something it introduces but rather something it exposes: it was already there, just maybe not explicitly. Likewise with a lot of the operational costs and so forth.
OTOH, I do think that now that it has shown the way, there is room for both improvement and replacement.
A door. No Internet-connected camera. No doorbell. Not even a knocker. Just a door. No batteries. No hype cycle. No upgrades. No WiFi. Just a door. When someone is at the door, he knocks with his knuckles. It works. We’ll probably get a knocker at some point, but we don’t need one.
Mechanical watches. I came very close to getting into so-called ‘smart’ watches awhile back, but decided that would have been a pretty foolish waste of my money. Quartz would be more accurate, of course, but I like the sweeping hands and the clockwork.
The modern version would be https://www.omniglot.com/, which has tons of real and constructed writing systems. It’s a reminder of when the Web was a bunch of neat people sharing neat things.
No affiliation with it, just been happily reading and sharing it for years.
> I conjectured that it's Kubernetes. Just like XML, Kubernetes solves a problem, but it doesn't solve EVERY problem.
Like XML, Kubernetes does a lot of cool things which were not common before it came around (unlike XML, I think K8s actually manages to improve on the state of the art a bit, too). But just as XML was largely replaced by JSON, I am really excited to see what replaces Kubernetes.
Then the user is stuck with the macOS UI and macOS software.
I have a very custom desktop UI based on a tiling window manager (WM); I tend to run it with one or two windows per screen, so that I can focus. I have a suite of synchronised colour schemes between the WM, my editor, my browser (with custom styles for commonly-used sites), my terminal, my PDF reader and my screen locker, so I see one unified colour theme across everything I do on a computer (with separate themes for work and personal computers, so I instantly know what context I am in). I have as few distractions as possible from the work I am doing. I have a fairly consistent set of keybindings across my environment, with custom keybindings for custom work.
Since it’s written in Common Lisp, I can dynamically reprogram my WM as it runs. What I mean is that I can connect to it from my editor and open a REPL; I can define, replace and debug live code in the running instance. It’s not quite as powerful as a real Lisp machine would be, but it’s better than any other desktop environment I’m aware of.
My Compose key setup is much more powerful than macOS’s Option key. I have a pair of true Hyper keys dedicated specifically to my own cross-application tooling, unused by any specific program.
I believe that switching to macOS, Windows, GNOME, KDE or any other setup would be a step back, or at the very least require a significant investment of time and effort to begin to approach parity.
Then there is the issue of freedom. Just about every line of code I run is free software, which I may inspect, learn from, debug and change. It’s not there to make Apple more money.
Then there is the issue of privacy. Apple claim to care about privacy, but with free software I can actually examine code to see if it does anything I don’t want it to do, and I can hire someone to do that for me, or rely on others I trust who have done that. You can’t do that with proprietary software.
The developers of GNU/Linux and the other software are more aligned with my own interests, wants, needs and desires than the developers of macOS are. It’s not perfect alignment, of course (Mozilla is a good example where improvement really is needed, as are the systemd developers), but on the whole the free software community are reasonably well-aligned with me.
I care about privacy, freedom, customisation and productivity. When I use my system, it does what I want it to do and nothing (or at least very little …) else. It gets out of my way and enables me to be effective in my job and in my computer-based hobbies, and gets out of my way so that I have time for my non-computer-based hobbies and the rest of my life.
GNU/Linux and other free software afford me much more privacy, freedom, customisation and ultimately productivity than does macOS.
Pretty neat! I see that you’re using Hunchentoot — are you concerned that it interns HTTP header names in the KEYWORD package? It means that a malicious client can use up all your RAM by submitting requests with random header names.
> Good to see that the good old "laptop doesn't go to sleep on linux" problem has never truly gone away.
FWIW, I have a spare Windows laptop, just over a year old, whose WiFi does not recover upon waking from sleep about eleven times out of a dozen.
OTOH, I have had both Windows and Linux laptops which have gotten uncomfortably warm when ‘asleep.’ And right now I have a Linux laptop which very rarely hangs on sleep and turns into space heater, not even turning off the monitor but becoming completely unresponsive.
Sleep is apparently a lot trickier a feature than it looks.
That strikes me as an excellent idea: it’s a pretty small tool, but it is useful and has just enough complexity to test the language and its standard library. Note, however, that I have not done so myself!
This is a great example of why Emacs is so powerful: the activation energy to go from ‘gosh, that sounds neat’ to ‘cool, I implemented that’ is so incredibly low.
> Also knowing that the thing will last forever, take care of it and it will probably outlive you. Can't say that about an Apple Watch.
I don’t know how many mechanical watches really will last a lifetime, but they will easily last longer than a so-called ‘smart’ watch.
Six years ago I seriously considered purchasing a ‘smart’ watch. Eventually I realised that they were just another money sink and attention leash, and put the money into a couple of automatic watches instead. I still have them, and wear them regularly. Had I bought an Apple or Android watch, I would have replaced it multiple times by now.
That’s the plus side. The minus side is that I don’t wear one of those two every single day because … I gotten bitten by the watch bug, and now I have a pile of other watches, and I wear those too! I still think that I am ahead of the game, though.
BTW, I write ‘smart’ watch because I don’t think they are really that smart; if anything, they should be called unwise watches, because they are an unwise expenditure of resources, money and attention. Also they just don’t look good. I predict that in thirty years we’ll look back on them much as we do digital watches: as a fad.
https://gigamonkeys.com/book/beyond-exception-handling-condi... is a nice introduction; https://news.ycombinator.com/item?id=24867548 points to a great book about it. I believe that Smalltalk ended up using a similar system, too.
> It would need to be the case that code that doesn’t want to handle errors (like Max’s simple website) doesn’t have any error handling code, but it’s easy to add, and common patterns (e.g. “retry this inner operation N times, maybe with back off and jitter, and then fail this outer operation, either exiting the program or leaving unaffected parts running”) are easy to express
Lisp’s condition system can handle that! Here’s a dumb function which signals a continuable error when i ≤ 3:
If one runs (foo) by hand then i starts at 0 and FOO signals an error; the debugger will include the option to continue, then i is 1 and FOO signals another error and one may choose to continue. That’s good for interactive use, but kind of a pain in a program. Fortunately, there are ways to retry, and to even ignore errors completely.
If one wishes to retry up to six times, one can bind a handler which invokes the CONTINUE restart:
If one wants to ignore errors, then (ignore-errors (foo)) will run and handle the error by returning two values: NIL and the first error.