"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."
Uhm, the context menu on words was a thing on the ZMachine (v3) port for the Game Boy too.
I launched Tristam Island under a Chinese Game Boy Colour clone and some rewritable USB cartridge. The games where playable enough with patience.
On smartphones, FDroid for Android had the Anysoft keyboard with a swipe option, it works great, much better than typing. There's also some grafitti 'keyboard' input at FDroid, but I prefer the swiping one as it's far superior.
On the old T9 phones, OFC a Frotz port exists for J2ME, but I didn't try it.
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?
SuperCollider enthusiast here, I think you missed the "is no different than" part. Working with SuperCollider is very different from playing any instrument live, and I doubt that'll change.
Where playing an instrument means balancing the handling of tempo, rhythm and notes while mastering your human limitations, a tool like SuperCollider lets you just define these bits as reactive variables. The focus in SuperCollider is on audio synthesis and algorithmic composition, that's closer to dynamically stringing a guitar in unique rule-based ways - mastering that means bridging music- and signal-processing theories while balancing your processing resources. Random generators in audio synthesis are mostly used to bring in some human depth to it.
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.
I moved from Pandoc+Lua filters to Typst. Having the scripting language integrated is just nicer, though I sometimes miss the separation between data (from Pandoc markdown) and code.
I use it to generate PDF. The last release introduced experimental HTML output which is promising but still immature. Work on EPUB support hasn't started as far as I know but it's on the roadmap, and I guess it will be relatively easy once the ongoing work on HTML and accessibility is done.
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.
The problem is that "support" usually isn't quite the right word. In practice for obscure platforms it is often closer to "isn't known to be horribly broken". Rust at least states this explicitly with their Tier 1/2/3 system, but the same will apply to every project.
Platform support needs to be maintained. There is no way around that. Any change in the codebase has the possibility of introducing subtle platform-specific bugs. When platform support means that some teenager a decade ago got it to compile during the summer holiday and upstreamed her patches, that's not worth a lot. Proper platform support means having people actively contributing to the codebase, regularly running test suites, and making sure that the project stays functional on that platform.
On top of this, it's important to remember that platform support isn't free either. Those platform-specific patches and workarounds can and will hold back development for all the other platforms. And if a platform doesn't have a maintainer willing to contribute to keeping those up-to-date, it probably also doesn't have a developer who's doing the basic testing and bug fixing, so its support is broken anyways.
In the end, is it really such a big deal to scrap support for something which is already broken and unlikely to ever be fixed? At a certain point you're just lying to yourself about the platform being supported - isn't it better to accept reality and formally deprecate it?
In theory I agree with you, and code written in a platform-agnostic way is definitely something we should strive for, but in practice: can keeping broken code around really be called "good engineering culture"?
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.
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.
you won't even be able to use the closed phone remotely from your main one since the restrictions wont allow remote software to see or interact with the screen
I am starting to do that but I still find that will be annoying to keep up. The dumb device will need to be kept up-to-date because that's important for e.g banking apps so that automatically excludes "old" devices (usually 3+ years old) because most stop getting updates that fast. Even LineageOS isn't an option because it does not pass Google's integrity checks so I am afraid I will need to buy a new dumb phone every couple of years..
On my to-do list is to join a local credit union after checking whether all services are available in person. All this mess is not worth simply being able to do stuff from my phone.
The trick is to never, ever install the banking app on your phone. If you only use their web app from the beginning (account creation) and say you don't have a duopoly phone, the app will not be required.
Yeah, you second phone sounds like a laptop. I have a boring phone that I don't care about with basically factory settings and perhaps 3 apps. MyGov, Dropbox and something else I can't even remember right now.
And I also carry a super cool small laptop that can tether to the phone and actually do stuff with.
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.
I was going to say that. I carry a laptop and an iphone 13 mini. The iphone is nice in a locked down way and the laptop you can code on etc. I'm not sure I see the attraction of the non locked down phone compared to the laptop for most use cases. I guess I could location spoof pokemon go so there'd be that.
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 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...