@lyse@lyse.isobeef.org Well, I used SnipMate years ago (until 2012). IIRC, it’s more than just “insert a bit of text here”, it can also jump to the correct next location(s) and stuff like that. Don’t remember why I stopped using it.

Then I used nothing for a long time. Just before Christmas, I made my own plugin (… of course …), which does everything I need at the moment (and nothing more).

It can insert simple templates and then jump to the next location:

https://movq.de/v/67cdf7c827/sisni%2Dpython.mp4

And replace a string after insertion:

https://movq.de/v/67cdf7c827/sisni%2Dheader.mp4

(It’s not public (yet?) and it also uses vim9script, so I guess it wouldn’t work on your system.)

Question to my fellow Vimers: Which snippet insertion mechanism are you using or can you (not) recommend?

Pro tip: Don’t keep the christmas biscuits close to the bird fat balls. I nearly mixed up the bags. :-D

@prologic@twtxt.net Debugging this stuff on bare metal hardware (without an underlying OS) is a nightmare. 🤣

@movq@www.uninformativ.de Yeah. I had that in my Python implementation and was really missing that.

@movq@www.uninformativ.de I see. Yeah, all the Unicode stuff certainly doesn’t help here, that’s for sure.

Maybe “speedcurses” could be a name. Or just select any Palatinate curse. ;-)

@prologic@twtxt.net Oh yeah, I bet it is horrible to troubleshoot.

@lyse@lyse.isobeef.org That sounds useful. 🤔

This was the scariest movie I’ve seen in a long time, jesus. 🤣 https://en.wikipedia.org/wiki/Fall_(2022_film)

@lyse@lyse.isobeef.org I’m toying with the idea of making a widget/window system on top of Python’s ncurses. I’ve never really been happy with the existing ones (like urwid, textual, pytermgui, …). I mean, they’re not horrible, it’s mostly the performance that’s bugging me – I don’t want to wait an entire second for a terminal program to start up.

Not sure if I’ll actually see it through, though. Unicode makes this kind of thing extremely hard. 🫤

@lyse@lyse.isobeef.org Bwahaha. 🤣

@lyse@lyse.isobeef.org I can tell you this right now, writing assembly / machine code is fucking hard work™ 😓 I’m sure @movq@www.uninformativ.de can affirm 🤣 And when it all goes to shit™ (which it does often), man is debugging fucking hard as hell! Without debug symbols I can’t use the regular tools like lldb or gdb 😂

@prologic@twtxt.net Yeah, the parser part is what I typically enjoy. Haven’t really looked into code generation itself.

I’m currently looking at your µ commits from the last few days. Holy cow! :-)

@lyse@lyse.isobeef.org Yeah I remember you said some days back that your interest in compilers was rekindled by my work on mu (µ) 😅

Dang it, there’s a Swede by the username of Quongsi: https://www.flashback.org/u1404408 :-D

@prologic@twtxt.net Tada, congratulations! I find that rather interesting, thanks for telling us. :-)

@movq@www.uninformativ.de How about “Quongsi”? I generated the first five letters with pwgen --no-capitalize --no-numerals 5 and since that already showed up in DDG search results, I simply appended the last two, which yielded nothing on DDG and Google).

What kind of project is it? Maybe we can help you find a name or nudge you in the right direction.

The tt URLs View now automatically selects the first URL that I probably are going to open. In decreasing order, the URL types are:

1. markdown media URLs (images, videos, etc.)
   
2. markdown or plaintext URLs
   
3. subjects
   
4. mentions
   

I might differentiate between mentions of subscribed and unsubscribed feeds in the future. The odds of opening a new feed over an already existing one are higher.

Whoo! I fixed one of the hardest bugs in mu (µ) I think I’ve had to figure out. Took me several days in fact to figure it out. The basic problem was, println(1, 2) was bring printed as 1 2 in the bytecode VM and 1 nil when natively compiled to machine code on macOS. In the end it turned out the machine code being generated / emitted meant that the list pointers for the rest... of the variadic arguments was being slot into a register that was being clobbered by the mu_retain and mu_release calls and effectively getting freed up on first use by the RC (reference counting) garbage collector 🤦‍♂️

@lyse@lyse.isobeef.org True !

@prologic@twtxt.net In my opinion, the integrity isn’t lost. The same input data always result in the same output hash, no matter when you calculate the hashes. It’s true that a corrupt database contents yields to corrupt hashes, but then you have a whole bigger problem than just receiving different hashes. :-D

Trying to come up with a name for a new project and every name is already taken. 🤣 The internet is full!

@zvava@twtxt.net By hashing definition, if you edit your message, it simply becomes a new message. It’s just not the same message anymore. At least from a technical point of view. As a human, personally I disagree, but that’s what I’m stuck with. There’s no reliable way to detect and “correct” for that.

Storing the hash in your database doesn’t prevent you from switching to another hashing implementation later on. As of now, message creation timestamps earlier than some magical point in time use twt hash v1, messages on or after that magical timestamp use twt hash v2. So, a message either has a v1 or a v2 hash, but not both. At least one of them is never meaningful.

Once you “upgrade” your database schema, you can check for stored messages from the future which should have been hashed using v2, but were actually v1-hashed and simply fix them.

If there will ever be another addressing scheme, you could reuse the existing hash column if it supersedes the v1/v2 hashes. Otherwise, a new column might be useful, or perhaps no column at all (looking at location-based addressing or how it was called). The old v1/v2 hashes are still needed for all past conversation trees.

In my opinion, always recalculating the hashes is a big waste of time and energy. But if it serves you well, then go for it.

@zvava@twtxt.net The problem you now then is you lose integrity of the message content if you compute the hashes at runtime rather than on the way in. So if your message content or database becomes corrupt in any way, so do your hashes.

@lyse@lyse.isobeef.org while caching those is a good idea the problem is baking data that can be calculated into the database instead of some cache, because post hashes are not fixed and change for every post edit. you can always easily look up other twts by hash with a cached lookup table, but now you’re not locked into them so supporting hashv2 or other hash variants or any other solution becomes far easier

@shinyoukai@neko.laidback.moe The CSS 404ing highlights the improvability of the content to noise ratio. :-)

@movq@www.uninformativ.de The asshats are everywhere. Luckily, it has been rather quiet so far. But of course, I now jinxed it.

well, accidentally I did make a simpler yarn theme, in hindsight

Building native compilers is hard 🤣 Building bytecode VM / interpreters is way easier 🤣

@shinyoukai@neko.laidback.moe Very cool! 😎

@shinyoukai@neko.laidback.moe Nice! 👍

https://gt.kalli.st/novaburst/pkgsrc/commit/a1cc81dd354e14b7c4ded65ec53a12eca9e35cf0

@prologic@twtxt.net

@movq@www.uninformativ.de Thanks! 🙏

@prologic@twtxt.net This is a really cool project, that’s for sure. 👌

@lyse@lyse.isobeef.org … I was about to write “it really is worse where you live”, then I heard the first bang out on the street. 🤣

It’s this time of the year again, where people burn money on the streets.

https://www.joanwestenberg.com/the-rime-of-the-ancient-maintainer/

@shinyoukai@neko.laidback.moe Nah it’s more like there’s a lot of repeated code, because when you go from source language to intermediate representation to machine code, well you just end up writing a lot of the same patterns over and over again. I need to dedupe this I think.

@kiwu@twtxt.net Ooof 😢 That’s rough!

I’ve been sick all week….

The compiler technique I’m using here is to not “emit” most of the runtime if it’s actually never used in your program, and also dropping dead code in the SSA pass.

@movq@www.uninformativ.de I’ve managed to bring a simple “Hello World!” in mu (µ) (at least on macOS / Darwin / ARM64) down to ~86KB (previously ~146KB) 🥳

Hmmm I need to figure out a way to reduce the no. of lines of code / complexity of the ARM64 native code emitter for mu (µ). It’s insane really, it’s a whopping ~6k SLOC, the next biggest source file is the compiler at only ~800 SLOC 🤔

@movq@www.uninformativ.de I think I can get binaries even smaller with a bit more work and effort 🤔 But yeah still working on the native code generation (at least for macOS targets)

@prologic@twtxt.net Oh! 🤔

@movq@www.uninformativ.de Oh that’s fine, Mu can compile to native code and so far binaries. at least on macOS are in the order of Kb in size 😂

@prologic@twtxt.net That might be a challenge, at least in 16-bit Real Mode: The OS follows the model of COM files on DOS, i.e. the size of the binary cannot exceed 64 KiB and heap+stack of the running program will have to fit into that same 64 KiB. 😅 (The memory layout is very rigid, each process gets such a 64 KiB slice.)

And in 64-bit Long Mode, there is no “kernel” yet. The thing in the video is literally just a small bare-metal program.

But some day, maybe. 😃

@movq@www.uninformativ.de It’d be cool if you could get µ (Mu) running in your little toyOS 🤣 You’d technically only have to swap out the syscall() builtin for whatever your toy OS supports 🤔

Almost all photos turned out to be blurred today. That made sorting a very quick process. Delete, delete, delete, … https://lyse.isobeef.org/waldspaziergang-2025-12-26/

Seeing this run on real hardware is so satisfying, even if it’s just a small example. 😅

https://movq.de/v/ec46b8cf99/netbook.mp4