The only good thing about this absolute craziness is that I can restock my rocket sticks. I picked up twelve along the way. Unfortunately, it looks like 99.999% of ammunition is bombs instead of rockets. Some sections of my street look exactly like an arbitrary Pakistanian town that I’ve seen online.

There was surprisingly much snow in the woods. Also, all ponds have frozen over. I didn’t expect that. Not at all. There were even illegal ice skating tracks in the natural reserve. We came across a large puddle and it was at least 10cm solid ice to the ground. Crazy!

https://lyse.isobeef.org/waldspaziergang-2026-01-01/

@lyse@lyse.isobeef.org It’s actually not nearly as half bad as I really thought it would be. Just having to eventually deal with the “lowering down” to machine code / ARM64 assembly in the end once you’ve verified the semantics in the VM.

@prologic@twtxt.net Not bad for a start, ey! Looking forward to see you going down these rabbit holes and opening one can of worms after the other. :‘-D Very, very impressive, hats off to you. :-)

@lyse@lyse.isobeef.org A “Hello World” binary is ~372KB in size. I currently have peephole optimization and deac code optimizations in play, and a few other performance related ones, but nothing too fancy. I have a test case that ensures fib(35) doesn’t regress too badly as I continue to evolve the language.

@prologic@twtxt.net Can you just make them optional? :-) But that of course complicates things.

@prologic@twtxt.net That’s impressive. How large are the resulting binaries? You don’t have any optimizations in place yet, do you?

@movq@www.uninformativ.de I hid in the workshop with earmuffs for the absolute worst part.

@javivf@adn.org.es Heck yeah, let’s do this! :-) Welcome to 2026.

Opinion / Question time…

Do you think Mu (µ)’s native compiler and therefore emitted machine code “runtime” (which obviously adds a bit of weight to the resulting binary, and runtime overheads) needs to support “runtime stack traces”, or would it be enough to only support that in the bytecode VM interpreter for debuggability / quick feedback loops and instead just rely on flat (no stacktraces) errors in natively built compiled executables?

So in effect:

Stack Traces:

• Bytecode VM Interpreter: ✅
  
• Native Code Executables: ❌

@prologic@twtxt.net Not bad. 😃

@prologic@twtxt.net Anything by Charlotte de Witte. 😅 For example:

https://www.youtube.com/watch?v=QfkgSlmoe1I

Nice! 😊 Here are the startup latencies for the simplest Mu (µ) program. println("Hello World"):

• Interpreter: ~5ms
  
• Native Code: ~1.5ms

Hmmm 🤔

Excluding merges, 1 author has pushed 171 commits to main and 175 commits to all branches. On main, 294 files have changed and there have been 52880 additions and 18269 deletions.

From the Mu (µ) Gitea Activity Tab

Happy new year! Waiting for ours watching the celebrations around the world. 🥳🥳🥳

@shinyoukai@neko.laidback.moe Happy New Year to you too! 🥳

Happy New Year, nyoro- !!!!

@movq@www.uninformativ.de This is fuck’n great shit™ Where did you find this? 🤔 Got any more shit™ like this? 🙏

@dce@hashnix.club Happy New Year to you too! 🥳

happy new year from the uk

@ionores@twtxt.net Very nice! 😊 Happy New Year to you too!

Happy New Year!! The Year of the Linux Desktop!!

Image

@lyse@lyse.isobeef.org Ooh, lovely! 🌇

I’m drowning the noise with this: https://www.youtube.com/watch?v=tgivYC2s6hs 😅

@shinyoukai@neko.laidback.moe We finally abandoned our GitLab. I publicly mirrored my code in the Mills Data Center a few days ago: https://git.mills.io/lyse/tt2

@movq@www.uninformativ.de Well, just a very limited subset thereof:

1. inline and multiline code blocks using single/double/triple backticks (but no code blocks with just indentation)
   
2. markdown links using using [text](url)
   
3. markdown media links using ![alt](url)
   

And that’s it. No bold, italics, lists, quotes, headlines, etc.

Just like mentions, plain URLs, markdown links and markdown media URLs are highlighted and available in the URLs View. They’re also colored differently, similarly to code segments.

I definitely should write some documentation and provide screenshots.

@lyse@lyse.isobeef.org You actually have a Markdown parser/renderer in there? Oh dear. I would have been (well, I am) way too lazy for that. 😅

@prologic@twtxt.net Happy New Year 🥳🎆

It totally sounds like an active warzone around here. So, I just went on a very, very, very quick stroll to check out our sunset from ontop our hill (were all the bangs are way more horrible): https://lyse.isobeef.org/abendhimmel-2025-12-31/

@lyse@lyse.isobeef.org Do you have your client’s code hosted anywhere?

Happy New Year (2026) 🥳

Hurray, I finally fixed another rendering bug in tt that was bugging me for a long time. Previously, when there were empty lines in a markdown multiline code block, the background color of the code block had not been used for the empty lines. So, this then looked as if there were actually several code blocks instead of a single one.

https://lyse.isobeef.org/tmp/tt-bugfix-empty-lines-in-multiline-code-blocks.png

@movq@www.uninformativ.de Because they’re just boxes. :-D

Why have these Unicode smilies never caught on, I wonder? 🤪

𜲦𜲩 𜲨𜲩 𜲦𜲧
𜲪𜲫 𜲮𜲯 𜲰𜲱

@movq@www.uninformativ.de Yeah, I see. Just crudely checked on my computer, with around 0.013 seconds, Python 2.7 seems a tad faster than Python 3.14’s 0.023 seconds in this little program.

The lazy imports sound not too bad, but I just skimmed over them. There are surprisingly many exceptions, but yeah, no way around them. :-)

mu (µ) now has builtin code formatting and linting tools, making µ far more useful and useable as a general purpose programming language. Mu now includes:

• An interpreter for quick “scriptinog”
  
• A native code compiler for building native executables (Darwin / macOS only for now)
  
• A builtin set of developer tools, currently: fmt (-fmt), check (-check) and test (-test).

@movq@www.uninformativ.de Mu (µ)’s startup latency appears to be ~10ms on my machine:

$ time ./bin/mu ./foo.mu 

real    0m0.011s
user    0m0.004s
sys     0m0.006s

The baseline here is about 55 ms for nothing, btw. Python ain’t fast to start up.

$ time python -c 'exit(0)'

real    0m0.055s
user    0m0.046s
sys     0m0.007s

@lyse@lyse.isobeef.org

I assume you made the thing load quickly, didn’t you?

That’s the problem with Python. If you have a couple of files to import, it will take time.

I want this to be reasonably fast on my old Intel NUC from 2016 (Celeron N3050 @ 1.60GHz) and I already notice that the program startup takes about 95 ms (or 125 ms when there are no .pyc files yet). That’s still fine, but it shows that I’ll have to be careful and keep this thing very small …

Python 3.14 will bring lazy imports, maybe that can help in some cases.

@movq@www.uninformativ.de That’s cool! I also like the name of your library. :-) I assume you made the thing load quickly, didn’t you?

@prologic@twtxt.net No, that’s Python/curses on Linux. 😅

@movq@www.uninformativ.de Is this on yout little toy OS? 🤔

Well, you girls and guys are making cool things, and I have some progress to show as well. 😅

https://movq.de/v/c0408a80b1/movwin.mp4

Scrolling widgets appears to work now. This is (mostly) Unicode-aware: Note how emojis like “😅” are double-width “characters” and the widget system knows this. It doesn’t try to place a “😅” in a location where there’s only one cell available.

Same goes for that weird “ä” thingie, which is actually “a” followed by U+0308 (a combining diacritic). Python itself thinks of this as two “characters”, but they only occupy one cell on the screen. (Assuming your terminal supports this …)

This library does the heavy Unicode lifting: https://github.com/jquast/wcwidth (Take a look at its implementation to learn how horrible Unicode and human languages are.)

The program itself looks like this, it’s a proper widget hierarchy:

https://movq.de/v/1d155106e2/s.png

(There is no input handling yet, hence some things are hardwired for the moment.)

I just fixed another bug in tt where the language hint in multiline markdown code blocks had not been stripped before rendering. It just looked like it was part of the actual code, which was ugly. I now throw it away. Actually, it’s already extracted into the data model for possible future syntax highlighting.

Phew, it was just a one-time thing. Ta! :-)

Btw, @shinyoukai@neko.laidback.moe, that’s a super cool logo on your yarnd. I like it a lot!

It just doesn’t look aligned properly: https://lyse.isobeef.org/tmp/misalignment.png Could be a yarnd issue, though, it might not expect a logo this large. Just wildguessing, no idea.

@shinyoukai@neko.laidback.moe Because you might not want to commit all changed files in a single commit. I very often make use of this and create several commits. In fact, I like to git add --patch to interactively select which parts of a file go in the next commit. This happens most likely when refactoring during a feature implementation or bug fix. I couldn’t live without that anymore. :-)

If you have a much more organized way of working where this does not come up, you can just git commit --all to include all changed files in the next commit without git adding them first. But new files still have to be git added manually once.

@shinyoukai@neko.laidback.moe Do we now need ad filters in twtxt clients, too? O_o I hope not! Personally, I cannot stand the “Sent with my crappy $phone/$app” e-mail footers.

But congrats on your client. :-)

Why the hell do I have to git add everything!? Is it not enough for the file(s) to be already checked in from the get go?

Git = G(od damn)it

@shinyoukai@neko.laidback.moe Yeah, they don’t truly support XDG. In fact, I looked in the Go stdlib source code to notice all the differences and shortcomings.

@lyse@lyse.isobeef.org You could always take a peek at the Go source

Posted from mikuru/0.0.3 @ NetBSD amd64