(#hivf4vq) @movq@www.uninformativ.de Because theyāre just boxes. :-D
#ih7lubq
(#hivf4vq) @movq@www.uninformativ.de Because theyāre just boxes. :-D
Why have these Unicode smilies never caught on, I wonder? š¤Ŗ
š²¦š²© š²Øš²© š²¦š²§
š²Ŗš²« š²®š²Æ š²°š²±
(#2p27wba) @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:
(#2p27wba) @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
(#2p27wba) 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
(#2p27wba) @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.
(#yiihgta) @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?
(#yiihgta) @prologic@twtxt.net No, thatās Python/curses on Linux. š
(#yiihgta) @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.
(#yh6mauq) 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.
(#ys4znqq) @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.
(#555iyvq) @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. :-)
(#iudi6qq) @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.
(#3hge2sq) Ok, the standard library implementation is wonky at best, at least in regards to XDG, because it really doesnāt implement it properly. https://github.com/golang/go/issues/62382 I stick to my own code then. It doesnāt properly support anything else than Linux or Unixes that use XDG, but personally, I donāt care about them anyway. And the cross-platform situation is a giant mess. Unsurprisingly.
(#iudi6qq) Hmm, mine also resolves a leading tilde in these variables. And if $HOME is not specified it tries to resolve the userās home directory by user.Current().HomeDir. Maybe thatās overkill, I have to check the XDG spec.
But Iām definitely missing os.UserDataDir(). Thatās a bummer.
(#dkvkbra) @shinyoukai@neko.laidback.moe Cool, I didnāt know about os.UserConfigDir() up until a few seconds ago! I always implemented that myself.
(#f2cdpva) @movq@www.uninformativ.de Thanks! Iāll have a look at SnipMate. Currently, Iām (mis)using the abbreviation mechanism to expand a code snippet inplace, e.g.
autocmd FileType go inoreab <buffer> testfunc func Test(t *testing.T) {<CR>}<ESC>k0wwi
or this monstrosity:
autocmd FileType go inoreab <buffer> tabletest for _, tt := range []struct {<CR> name string<CR><CR><BS>}{<CR> {<CR> name: "",<CR><BS>},<CR><BS>} {<CR> t.Run(tt.name, func(t *testing.T) {<CR><CR>})<CR><BS>}<ESC>9ki<TAB>
But this of course has the disadvantage that I still have to remove the last space or tab to trigger the expansion by hand again. Itās a bit annoying, but better than typing it out by hand.
Oh, suddenly Mother Hulda dumped a centimeter of snow tonight! https://lyse.isobeef.org/schnee-2025-12-30/01.jpg
Magpie from the day before yesterday: https://lyse.isobeef.org/elster-2025-12-28/
(#xwn45gq) @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
(#tackqqq) @prologic@twtxt.net Debugging this stuff on bare metal hardware (without an underlying OS) is a nightmare. š¤£
(#nr6p4la) @movq@www.uninformativ.de Yeah. I had that in my Python implementation and was really missing that.
(#fazzzcq) @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. ;-)
(#tackqqq) @prologic@twtxt.net Oh yeah, I bet it is horrible to troubleshoot.
(#sd722yq) @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)
(#j5s5khq) @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. š«¤
(#7tsxwnq) @lyse@lyse.isobeef.org Bwahaha. š¤£
(#dhngcaq) @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 š
(#dhngcaq) @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! :-)
(#xupmaxa) @lyse@lyse.isobeef.org Yeah I remember you said some days back that your interest in compilers was rekindled by my work on mu (µ) š
(#7tsxwnq) Dang it, thereās a Swede by the username of Quongsi: https://www.flashback.org/u1404408 :-D
(#xupmaxa) @prologic@twtxt.net Tada, congratulations! I find that rather interesting, thanks for telling us. :-)
(#j5s5khq) @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:
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 š¤¦āāļø
(#pact6sq) @lyse@lyse.isobeef.org True !
(#pact6sq) @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!
(#73l4niq) @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.
(#o3hv4aq) @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.
(#zvnyhga) @shinyoukai@neko.laidback.moe The CSS 404ing highlights the improvability of the content to noise ratio. :-)
(#e76wxtq) @movq@www.uninformativ.de The asshats are everywhere. Luckily, it has been rather quiet so far. But of course, I now jinxed it.
Building native compilers is hard 𤣠Building bytecode VM / interpreters is way easier š¤£