In-reply-to » @lyse Yeah I remember you said some days back that your interest in compilers was rekindled by my work on mu (µ) šŸ˜…

@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 šŸ˜‚

⤋ Read More
In-reply-to » @lyse Yeah I remember you said some days back that your interest in compilers was rekindled by my work on mu (µ) šŸ˜…

@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! :-)

⤋ Read More
In-reply-to » 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 Yeah I remember you said some days back that your interest in compilers was rekindled by my work on mu (µ) šŸ˜…

⤋ Read More
In-reply-to » 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 šŸ¤¦ā€ā™‚ļø

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

⤋ Read More
In-reply-to » Trying to come up with a name for a new project and every name is already taken. 🤣 The internet is full!

@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.

⤋ Read More

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.

⤋ Read More

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 šŸ¤¦ā€ā™‚ļø

⤋ Read More
In-reply-to » (#o3hv4aq) @zvava 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.

@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

⤋ Read More

@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.

⤋ Read More

@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.

⤋ Read More
In-reply-to » 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 šŸ¤”

@prologic@twtxt.net This is a really cool project, that’s for sure. šŸ‘Œ

⤋ Read More
⤋ Read More
In-reply-to » 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 šŸ¤”

@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.

⤋ Read More
In-reply-to » 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 šŸ¤”

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.

⤋ Read More
In-reply-to » 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’ve managed to bring a simple ā€œHello World!ā€ in mu (µ) (at least on macOS / Darwin / ARM64) down to ~86KB (previously ~146KB) 🄳

⤋ Read More

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 šŸ¤”

⤋ Read More
In-reply-to » My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

@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)

⤋ Read More
In-reply-to » My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

@prologic@twtxt.net Oh! šŸ¤”

⤋ Read More
In-reply-to » My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

@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 šŸ˜‚

⤋ Read More
In-reply-to » My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

@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. 😃

⤋ Read More
In-reply-to » My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

@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 šŸ¤”

⤋ Read More
In-reply-to » My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

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

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

⤋ Read More

My little toy operating system from last year runs in 16-bit Real Mode (like DOS). Since I’ve recently figured out how to switch to 64-bit Long Mode right after BIOS boot, I now have a little program that performs this switch on my toy OS. It will load and run any x86-64 program, assuming it’s freestanding, a flat binary, and small enough (< 128 KiB code, only uses the first 2 MiB of memory).

Here I’m running a little C program (compiled using normal GCC, no Watcom trickery):

https://movq.de/v/b27ced6dcb/los86%2D64.mp4

https://movq.de/v/b27ced6dcb/c.png

Next steps could include:

  • Use Rust instead of C for that 64-bit program?
  • Provide interrupt service routines. (At the moment, it just keeps interrupts disabled.)

⤋ Read More
In-reply-to » This one is a slightly more 3D looking, as well as the first one, with the tail swirled. Media

@prologic@twtxt.net Not even entirely sure how I did it myself, but likely a lucky combination of the new tail swirl, the legs closer to the screen being bigger and the head looking slightly to the side (eye & ear position), with bottom part of the hair, going behind the snout. The white is just an outline, around most of my works, so I don’t think that plays a part.

⤋ Read More

@zvava@twtxt.net I might misunderstand what you wrote, but only hashing the message once and storing the hash together with the message in the database seems a way better approch to me. It’s fixed and doesn’t change, so there’s no need to recompute it during runtime over and over and over again. You just have it. And can easily look up other messages by hash.

⤋ Read More
In-reply-to » Mastodon has a ā€œWrapstodon 2025ā€ now, showing you a ā€œwrap upā€ of the year. Of course, a pointless funny shitpost was my most ā€œsuccessfulā€ post in 2025. šŸ˜‚

@movq@www.uninformativ.de Maybe there’s another meaning I’m not aware of, but this doesn’t look like a shitpost to me. Congrats, I guess. ;-)

⤋ Read More

2025 end the year rewind:

Compared to only 3 new artworks in 2024 and next to no work, on other projects, this year I not only met the self-imposed goal of monthly pixelart, but exceeded it by 50%, with 18 additions in total.

Relicensed the majority of canine faction owned art and projects, under two less restrictive Creative Commons licensees*. This also applies retroactively, to everyone who used/archived our art and projects, back when the old license didn’t allow it.

Disappointed by the current state of the Internet and continued lack of competition among browsers, completely reworked the main website* and made Smol Drive** (a new image gallery project), both made to be compatible with as many web and Gemini browsers, as possible.

*see https://thecanine.smol.pub
**see https://thecanine.smol.pub/smolbox

⤋ Read More

Oh great, I received an e-mail that my SMTP credentials have been exposed. Once again, just another shitty scanner that generates garbage reports from tests it doesn’t understand. Thank you for nothing!

conf := &Config{
    SMTPHost: "smtp.example.com",
    SMTPPort: 587,
    SMTPUser: "user",
    SMTPPass: "hunter2",
    SMTPFrom: "from@example.com",
}

⤋ Read More
In-reply-to » Hey EU friends šŸ‘‹ wtf happened to the EU Internet today for about 40 minutes or so?

@prologic@twtxt.net I’ve been awake at that time, didn’t notice anything. šŸ¤” Where was that BGP analyzer again … šŸ˜… There’s a tool that keeps track of these things, right? I forgot what it was.

⤋ Read More
In-reply-to » Hey EU friends šŸ‘‹ wtf happened to the EU Internet today for about 40 minutes or so?

@prologic@twtxt.net @movq@www.uninformativ.de A crocodile had bitten the big submarine internet cable that connects Australia to Europe. The investigations revealed that some construction work last week accidentally tore up the protective layer around it. That went unnoticed, unfortunately, so marine life had an easy job today. For just 40 minutes, they were quite fast in repairing the damage if you ask me! These communication cables are fricking large.

Just kidding, I completely made that up. :-D I didn’t notice any outage either. But I didn’t try to connect to Down Under at the time span in question.

⤋ Read More
In-reply-to » Hey EU friends šŸ‘‹ wtf happened to the EU Internet today for about 40 minutes or so?

@movq@www.uninformativ.de From 2:50 PM to 3:23 PM AEST (+10 UTC) there was an outage. Everything went ā€œupā€ on Down Detector, my EU region went offline, numerous sites were unavailable, and so on. Basically everything to/from the EU appeared to basically go kaput.

⤋ Read More
In-reply-to » This feels useful: Rust’s Block Pattern

@movq@www.uninformativ.de Very nice! I often wish other languages had something similar. Sometimes, I use lambdas, but that also looks ugly and feels a bit like a misuse. Other times, just the normal blocks are enough, but it’s not the same. Especially with the mutability aspects as the article explains. Typically, I just put it in a function or ignore it if it’s just a few lines.

⤋ Read More
In-reply-to » Wow, @movq, so many tables. No idea what I expected (I'm totally clueless on this low-level stuff), but that was quite an interesting surprise to me. https://www.uninformativ.de/blog/postings/2025-12-21/0/POSTING-en.html

@lyse@lyse.isobeef.org These tables get shuffled around every time your OS switches to another process. It’s crazy that so much is going on behind the scenes.

⤋ Read More
In-reply-to » Wow, @movq, so many tables. No idea what I expected (I'm totally clueless on this low-level stuff), but that was quite an interesting surprise to me. https://www.uninformativ.de/blog/postings/2025-12-21/0/POSTING-en.html

@lyse@lyse.isobeef.org I was surprised by that as well. šŸ˜… I thought these were features that you can use, but no, you must do all this.

By the way, I now fixed the issue that I mentioned at the end and it works on the netbook now. 🄳

https://www.uninformativ.de/blog/postings/2025-12-21/0/netbook.jpg

⤋ Read More

There is a #Processing survey going on at:

https://docs.google.com/forms/d/e/1FAIpQLSduTT2cWlXzr7QG_g4LJ-Op6LwVTI7dtXHCGVH_FdI0BK00qg/viewform

I’m happy it mentions #py5 at some point.

At the end there is this invitation for the Processing Discord server. I find it unfortunate that the Processing Foundation is moving the community towards a closed, opaque platform controlled by a corporation, when they have the open and searchable forum powered by Discourse. I wish I understood the reasoning. I know Discord can be ā€œconvenientā€ but IMHO the downsides are much bigger.

#CreativeCoding #Discourse

⤋ Read More

@movq@www.uninformativ.de @kiwu@twtxt.net it just so happens to be a happy coincidence that I’m extending mu’s capabilities to now include a native toolchain-free compiler (doesn’t rely on any external gcc/clang or linkers, etc) that lowers the mu source code into an intermediate representation / IR (what @movq@www.uninformativ.de refers to as ā€œthick layers of abstractionsā€ā€¦) and finally to SSA + ARM64 + Mach-O encoder to produce native binary executables (at least for me on my Mac, Linux may some later?) 🤣

⤋ Read More

@kiwu@twtxt.net Assembly is usually the most low-level programming language that you can get. Typical programming languages like Python or Go are a thick layer of abstraction over what the CPU actually does, but with Assembler you get to see it all and you get full control. (With lots of caveats and footnotes. šŸ˜…)

I’m interested in the boot process, i.e. what exactly happens when you turn on your computer. In that area, using Assembler is a must, because you really need that fine-grained control here.

⤋ Read More