"I have fond memories of some z-machine interpreter on the Palm that I found easier to play with than anything on my desktop computer. There were lots of shortcut buttons and thanks to the stylus it was still easy to use those (vs a touchscreen using ony fingers where you need huge buttons to hit). You could also tap any word in the output to bring up a context menu of actions (e.g. to examine or pick up objects mentioned in room descriptions) and that list of actions was a combination of a configurable global list and a game-specific list you could add actions to. Could play through entire games and barely ever have to type anything. Had a folding keyboard, but no memory of using that for interactive fiction."
There is a chapter in the Blue Book about how the GW-BASIC byte code is structured, and from what I understand it used pointers to lines, not just offsets? But I did not look too carefully (guess the answer is in the source code: https://gitlab.com/tkchia/GW-BASIC).
Before reading that I never considered how primitive early BASICs were. There is a lot of linear-searching for things (variables, line-numbers) that has to be considered when optimizing.
I have fond memories of some z-machine interpreter on the Palm that I found easier to play with than anything on my desktop computer. There were lots of shortcut buttons and thanks to the stylus it was still easy to use those (vs a touchscreen using ony fingers where you need huge buttons to hit). You could also tap any word in the output to bring up a context menu of actions (e.g. to examine or pick up objects mentioned in room descriptions) and that list of actions was a combination of a configurable global list and a game-specific list you could add actions to. Could play through entire games and barely ever have to type anything. Had a folding keyboard, but no memory of using that for interactive fiction.
Live programming music using tools like SuperCollider is/was a (very niche) thing. Someone is on stage with a laptop and, starting from a blank screen that is typically projected for everyone to see, types in code that makes sounds (and sometimes visual effects). A lot of it involves procedurally generated sounds using simple random generators. Live prompting as part of such shows would not seem entirely out of place and someone might figure out how to make that work as a performance?
I guess if Pandoc adds Typst output support I will consider using that, but "LaTeX replacement" sounds like something that is too low level to consider for most usecases? It was many years since I used LaTeX for anything other than at most short snippets embedded in other documents (e.g. md or org). Or would Typst replace something like Pandoc Markdown (with a long list of supported output formats and a convenient Lua filter API)?
* Submitted too fast. A quick search tells me Pandoc already added Typst input and output support (e.g. https://pandoc.org/typst-property-output.html), so guess I need to look into if I should switch to use that for generating PDFs.
Teams refused to let me copy text from the real-time captions, even showing a popup to say it wasn't allowed. But after the meeting in the posted transcript I could copy the same text anyway so not sure why it was so important to prevent me from copying immediately. Very annoying since I wanted that text right then and not later.
What I like about seeing a project support a long list of totally irrelevant old obscure platforms (like Free Pascal does, and probably GCC) is that it gives some hope that they will support some future obscure platform that I may care about. It shows a sign of good engineering culture. If a project supports only 64-bit arm+x86 on the three currently most popular operating systems that is a red flag for future compatibility risks.
I vaguely remember GEM in MS-DOS because it was the only software I knew of (iirc) that supported the mouse we had. One of those early optical mice with a metal mousepad with a grid of tiny reflective dots. No one else I knew that had a PC had a mouse back then.
It also had graphics programs. One for bitmaps and one for vectors, iirc. Me and my friend used to play with those. I don't even remember what else GEM was for. To me it was just a way to launch those editors to draw things and I did not have access to any other graphics applications in DOS until years later.
Official Android with Google Play and all the things some apps require will almost certainly refuse to run if a hypervisor is detected. Maybe someone could get it to work, but it would be a struggle to stay ahead of whatever new security checks are added to the OS and apps. The point of having one perfectly normal phone would be to not have to worry about any of that.
I sometimes bring a bt keyboard to use my phone as a tiny almost-laptop, but mostly happy with something just the size and weight of a phone.
Used to have two phones ~10 years ago. A Jolla Phone was my primary phone with a sim card and ran most non-Google apps. Then I carried around a cheap Motorola Android phone that had no sim card but could run Google Play apps and when it needed wifi I shared that from the Jolla and otherwise it was fully offline and most of the time turned off.
So the phone that was closer to a small laptop was the one I actually used as a phone. Not sure if that is the setup I would go for again or if I would do it the other way around with the Google phone being the phone. If I do the latter I guess something like a very small Linux netbook would work as a second device, it such a thing exists.
SailfishOS also came (at least back in the day of the first Jolla Phone and Tablet) with an excellent terminal app and built-in sshd that made it work great with pretty much every Linux command-line and TUI application (only exception was of course those with hardcoded minimum screen size support). Termux for Android is maybe half that good, not as well integrated, but still good enough that I use it every day, much more than I use other apps other than the browser.
My next phone will almost certainly be two phones. One cheap and super standard Android phone to just run banking apps and similar that insists on Google Play etc. Locked down and boring, turned off most of the time. Then a second phone for everything else (terminal with sshd, emacs, emulators, media players ... the stuff that allows a phone to be the general purpose computer it should be).
Looks increasingly unlikely that there will be convenient ways to have the best of both those worlds in a single device. For now it is somewhat possible with Android, but the experience keeps getting worse.
About mobile app, I never used pass until today, but it seems great, and so far I only tested it by installing it on my phone in Termux. Can't think of a reason for me to use a special app when running it in Termux works so well. Was happily surprised that even pass show -g worked out of the box, copying output to Android clipboard.
That is also nice since I have ssh already set up so syncing to my computer from the phone will be easy.
It was running on Hetzner, but I did not like the idea of having to rely on some script to try to avoid a disaster as opposed to just be able to set a limit (that they do not support?).
* Even if the risk is obviously very low, the value of running my gemlog isn't great. Not really worth any non-zero risk of significant costs.
I shut down my server the other day after people on HN were sharing horror stories about runaway bandwidth bills. I could not find a good (easy) way to ensure that my gemini server shuts down if hit by DDOS. I want to set it up again, but need to find some place to host it that has a guaranteed maximum bandwidth cost.
Some clients have a setting to inline images, or/and a shortcut to do so on the current page. Most clients can display images when the user follows a link to one. So images are quite useless as decorations (as most will probably not see them) but if an article contains useful images most users will be able to see those.
I have an old MeeBlip synth. It is basically a box with some knobs and switches and a cheap 8-bit Atmel AVR inside, similar to the processor in some old Arduinos. Source code is available (I think this repo: https://github.com/MeeBlip/meeblip-synth) and they expose some pins to flash new code to it, but I never tried.
Any Raspberry Pi, even the Pico, must be orders of magnitude more powerful than that old AVR and easier to program too. A lofi groovebox made from a Pico with a few knobs and buttons attached sounds like a fun project someone probably already made.
Also some XML parsers I used choked on UTF-8 BOMs. Not sure if valid XML is allowed to have anything other than clean ASCII in the first few characters before declaring what the encoding is?
"I have fond memories of some z-machine interpreter on the Palm that I found easier to play with than anything on my desktop computer. There were lots of shortcut buttons and thanks to the stylus it was still easy to use those (vs a touchscreen using ony fingers where you need huge buttons to hit). You could also tap any word in the output to bring up a context menu of actions (e.g. to examine or pick up objects mentioned in room descriptions) and that list of actions was a combination of a configurable global list and a game-specific list you could add actions to. Could play through entire games and barely ever have to type anything. Had a folding keyboard, but no memory of using that for interactive fiction."
From looking at my old hoarded palm files I think that the interpreter was PalmPilotFrotz, still available on the if-archive: https://ifarchive.org/indexes/if-archive/infocom/interpreter...