Entrance to a ski-jumping hill in a rather questionable state
Is there some Makefile shenanigans going on maybe?
$V and $C being swallowed by the Makefile. I fell in that trap again the other day.
I'm actually glad I don't have to deal with all this web shit and work with compilers that hit me in the face when I do something illegal. :-)
Timber framed houses
Bergfried
Stacked logs
Your explanation seems fitting. I just don't get why people don't use feed readers anymore. Anyway.
@bender You're spot on, it's important to not introduce classical bugs!
1. Why the hell are e-mail newsletters considered a valid option in the first place? Just offer an Atom feed and be done with it! Especially for a blog of this very type. This doesn't even involve a third party service. Although, in addition he also links to Feedburner, what the fuck!? No e-mail address or the like is needed and subject to being disclosed.
2. When these spam mailers want to prevent resubscribing, then for fuck's sake, why don't they use a hash of the e-mail address (I saw that in yarnd) for that purpose? Storing the e-mail address in clear text after unsubscribing is illegal in my book.
about:compat. Crazy!
My backing SQLite database with indices is 8.7 MiB in size right now.
The
twtxt cache is 7.6 MiB, it uses Python's pickle module. And next to it there is a 16.0 MiB second database with all the read statuses for the old tt. Wow, super inefficient, it shouldn't contain anything else, it's a giant, pickled {"$hash": {"read": True/False}, …}. What the heck, why is it so big?! O_o
tt reimplementation that I already followed with the old Python tt. Previously, I just had a few feeds for testing purposes in my new config. While transfering, I "dropped" heaps of feeds that appeared to be inactive.This might motivate me to actually "finish" the new client, so that it could become my daily driver. No need to use the old software stack any longer. Let's see how bad this goes.
* KMail – e-mail client
* Okular – PDF viewer
* Gwenview – image viewer
* Dolphin – file browser
* KWallet – password manager (I want to check out
pass one day. The most annoying thing is that when I copy a password, it says that the password has been modified and asks me whether I want to save the changes. I never do, because the password is still the same. I don't get it.)* KPatience – card game
* Kdenlive – video editor
* Kleopatra – certificate manager
Qt:
* VLC – video player
* Psi – Jabber client (I happily used Kopete in the past, but that is not supported anymore or so. I don't remember.)
* sqlitebrowser – SQLite browser
Gtk:
* Firefox – web browser
* Quod Libet – music player (I should look for a better alternative. Can't remember why I had to move away from Amarok, was it dead? There was a fork Clementine or so, but I had to drop that for some unknown reason, too.)
* Audacity – audio editor
* GIMP – image editor
These are the things that are open right now or that I could think of. Most other stuff I actually do in the terminal.
In the past™, I used the Python KDE4 bindings. That was really nice. I could pass most stuff directly in the constructor and didn't have to call gazillions of setters improving the experience significantly. If I ever wanted to do GUI programming again, I'd definitely go that route. There are also great Qt bindings for Python if one wanted to avoid the KDE stuff on top. The vast majority I do for myself, though, is either CLI or maybe TUI. A few web shit things, but no GUIs anymore. :-)
I just noted today that JetBrains improv^Wcompletely fucked up their new commit dialog. There's no diff anymore where I would also be able to select which changes to stage. I guess from now on I'm going to exclusively commit from only the shell. No bloody git integration anymore. >:-( This is so useless now, unbelievable.
A pointer is an indirection. At a lower level, when you have some chunk of memory, you can have some actual values sitting in there, ready for direct use. A pointer, on the other hand, points to some other location where to look for the values one's actually after. Following that pointer is also called dereferencing the pointer.
I can't come up with a good real-world example, so this poor comparison has to do. It's a bit like you have a book (the real value that is being pointed to) and an ISBN referencing that book (the pointer). So, instead of sending you all these many pages from that book, I could give you just a small tag containing the ISBN. With that small piece of information, you're able to locate the book. Probably a copy of that book and that's where this analogy falls apart.
In contrast to that flawed comparision, it's actually the other way around. Many different pointers can point to the same value. But there are many books (values) and just one ISBN (pointer).
The pointer's target might actually be another pointer. You typically then would follow both of them. There are no limits on how long your pointer chains can become.
One important property of pointers is that they can also point into nothingness, signalling a dead end. This is typically called a null pointer. Following such a null pointer calls for big trouble, it typically crashes your program. Hence, you must never follow any null pointer.
Pointers are important for example in linked lists, trees or graphs. Let's look at a doubly linked list. One entry could be a triple consisting of (actual value, pointer to next entry, pointer to previous entry).
_______________________
/ ________\_______________
↓ ↓ | \
+---+---+---+ +---+---+-|-+ +---+---+-|-+
| 7 | n | x | | 23| n | p | | 42| x | p |
+---+-|-+---+ +---+-|-+---+ +---+---+---+
| ↑ | ↑
\_______/ \_______/
The "x" indicates a null pointer. So, the first element of the doubly linked list with value 7 does not have any reference to a previous element. The same is true for the next element pointer in the last element with value 42.
In the middle element with value 23, both pointers to the next (labeled "n") and previous (labeled "p") elements are pointing to the respective elements.
You can also see that the middle element is pointed to by two pointers. By the "next" pointer in the first element and the "previous" pointer in the last element.
That's it for now. There are heaps ;-) more things to tell about pointers. But it might help you a tiny bit.
@prologic I see this with the scouts. Luckily, not at work. But at work, I'm surrounded by techies.
@movq Oh my goodness! I'm so glad that I don't have to deal with that in my family. But yeah, I guess you're onto something with your theory. This article is also quite horrific. O_o
This wasn't the case six, seven years ago, everybody had some "real" username. Even non-techies. It looks like some "common knowledge" is getting lost. Strange. Very weird. It trips me every time I see it.
Have you experienced something similar?
Yeah, I should revert that and try to figure out which programs misbehaved. But that's something for future Lyse. 8-) Right now, I just redefine
TERM in my Makefile when the USER happens to be me.
URxvt.keysym.Control-Up: \033[1;5A URxvt.keysym.Control-Down: \033[1;5B
URxvt.keysym.Control-Left: \033[1;5D URxvt.keysym.Control-Right: \033[1;5C
Probably to behave more like XTerm and fix a few other issues I had with other programs. But, it turns out, tcell expects the original sequence: https://github.com/gdamore/tcell/blob/main/terminfo/r/rxvt/term.go#L487
Hmm.
Ctrl+Left to jump a word left, I get 1;5D in my tt2 message text. My TERM is set to rxvt-unicode-256color. In tt, it works just fine. When I change to TERM=xterm-256color, it also works in tt2. I have to read up on that. Maybe even try to capture these sequences and rewrite them.
Reply form in tt2 shows the messages to which a reply is composed
I now notice that I should also show the original message(s) to which I reply. That was super useful in the original
tt. But one after the other. The mentions are now automatically filled in. \o/
It worked!I now also implemented basic replying by hitting
a as in answering. What's missing is automatically adding mentions in the message text template. That's gonna be a bit more tricky, though.
tt.) Well, it kinda worked. At least appending to the file. But my cache database got screwed up. I do not yet support replies, so the subject and and root hash columns have not been set at all, resulting in a message that is just not shown at all. I gotta do something about that next. The good thing is, though, after simply fixing the two columns the message appeared on screen.
tt.) Now, this is the second attempt in tt2.Let's see!
Composing a new message in tt2Somehow, my local feed cannot be opened to append to. I reckon, I have to resolve the tilde first:
Opening feed file failed: no such file or directory
yarnc. I neither used nor looked at it, though.
Proposal 3 (https://git.mills.io/yarnsocial/twtxt.dev/issues/18#issuecomment-19215) has the "advantage", that you do not have to "mention" the original author if the thread slightly diverges. It seems to be a thing here that conversations are typically very flat instead of trees. Hence, and despite being a tree hugger, I voted for 3 being my favorite one, then 2, 1 and finally 4.
All proposals still need more work to clarify the details and edge cases in my opinion before they can be implemented.
Heart shows up fine in tt
In the meantime, I tried to add English subtitles, so the international audience has a chance of enjoying some of them, too. There are a bunch of puns, so translations don't work at that great.
I went to an exhibition of my fine arts teacher who passed away last year. He was a pretty cool dude and good teacher. I reckon I had him in 7th and probably also 8th grade. His Schelme (imps) were very famous here in this county and presumably well beyond.
Unfortunately, picture frame glas doesn't mix all that great with a fairly dark light and my camera. So, sorry in adavance for the poor quality. Anyway, I photographed a few funny paintings. Watch out, it may contain saucy contents: https://lyse.isobeef.org/siegfried-wagner-farrenstall-2025-03-15/.
Bilderrahmenglas in Verbindung mit vergleichsweise dunkler Beleuchtung gibt leider keine gute Kombination mit meiner Kamera ab. Vorab entschuldige ich mich bereits für die zu wünschen übrig lassende Qualität. Nichtsdestotrotz habe ich ein paar witzige Bilder abfotografiert. Obacht, kann mitunter anzüglichen Inhalt enthalten: https://lyse.isobeef.org/siegfried-wagner-farrenstall-2025-03-15/
Drei Eichhörnchen und ein Kind im bunten Blätterwald
@eapl.me Interesting, I wasn't aware that other parts of the world consider them to be a German thing :-)
Ha, das Lied gefällt mir außerordentlich gut! \o/ Mit Abstand das beste Güllelied. Ich kenn noch ein paar schwäbische, aber die gehen lang nicht so ab wie dieses hier.
Desk calendar highlighting the current date with a red "today window"This particular one is 95mm wide and 185mm high. Fairly compact.
I can only use it figure out distances to other dates and to do some basic calendar math. I'm not able to actually schedule anything. But I grew up with a month calendar like you have there where all appointments of the entire family was recorded.
By far most of my paper use is drawing random stuff on scratch paper during meetings. :-D
Random stuff drawn in interesting meetings
It sits on my desk next to my rightmost monitor. I've set it up so that I can see the last, current and next months. Each morning, I advance the "today window" or whatever its proper name is. This gives me a sense of what date we have today and which I will have forgotten half a minute later already. At most. However, it's easily at hand by turning my head just a few degrees.
With the last month still showing, I had several occasions so far where a date in the past popped up in a meeting. I could easily tell when something happened, how long ago that was. Or how many days or weeks are left until we have to deliver something, etc.
In hindsight, this is absolutely no surprise at all. But I still find it fascinating. I'm now actually wondering why I never had something like that before. How could I live without that thing? Sure, I pulled up a calendar on my computer,
ncal -w3 or so. But I always hated the inverted ncal output, necessary for showing week numbers, though. Having a paper calander right next to my screen at all times is sooooo much more handy.So, do yourself a favor and think about whether such a desk calendar might be useful to you.
The only annoying thing is that the "today window" moves too easily. It slips down by its own. I reckon it wants me to regularly interact with it, so that I memorize the current date.
I only very rarely have to deal with CSV files or databases in my day to day life. Maybe, these classic Unix tools offer some tricks I'm not aware of. When I have some more complicated CSV input, I generally reach for Python.
Hmmm, Eberhardt. Ist das eine plattdeutsche Sache? Dass ich den flinken Nagern so lang zuschauen konnte, war ein seltener Glücksfall. Normalerweise sind die nach fünf oder spätestens zehn Minuten wieder aus dem Sichtfeld verschwunden.
Squirrel jumping from tree to treeWhich photos would you remove?
make dev on current master, I get a proper version. Same with make server. Assuming you cloned the repo, do you have any (uncommited) changes? What does git status tell you?
Also, you would need to host not your own hash files, but everybody else's as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don't process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.
Additionally, yarnd's URL schema would then also break, because
https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.Sorry, I don't like that idea.
I had some sore muscles after yesterday's waste paper collection with the scouts. So, I only went for a short trip to my closest backyard mountain. Watching two rock climbers was interesting. That's not something I see very often.
Rock climber going up the Spielburghttps://lyse.isobeef.org/waldspaziergang-2025-03-09/
* storage/ defines the interface
* sqlite/ implements the storage interface
* mock/ extends the SQLite implementation by some mocking capabilities and assertions
Here, however, there are no storage subpackages. It's just
storage, that's it. Everything is in there. The only implementation so far is an SQLite backend that resides in storage. My RAM storage is exactly that SQLite storage, but with :memory: instead a backing file on disk. I do not have a mock storage (yet).I have to think about it a bit more, but I probably have to do exactly that in my
tt rewrite, too. Sigh. I just have the feeling that in storage/sqlite/sqlite_test.go I cannot import storage/mock for the helper because storage/mock/mock.go imports and embeds the type from storage/sqlite. But I'm too tired right now to think clearly.
* storage/
* storage.go: defines a
Storage interface* sqlite.go: implements the
Storage interface* sqlite_test.go: originally had a function to set up a test storage to test the SQLite storage implementation itself:
newRAMStorage(testing.T, $initialData) *Storage* controller/
* feeds.go: uses a
Storage* feeds_test.go: here I wanted to reuse the
newRAMStorage(…) functionI then tried to relocate the
newRAMStorage(…) into a* teststorage/
* storage.go: moved here as
NewRAMStorage(…)so that I could just reuse it from both
* storage/
* sqlite_test.go: uses
testutils.NewRAMStorage(…)* controller/
* feeds_test.go: uses
testutils.NewRamStorage(…)But that results into an import cycle, because the
teststorage package imports storage for storage.Storage and the storage package imports testutils for testutils.NewRAMStorage(…) in its test. I'm just screwed. For now, I duplicated it as newRAMStorage(…) in controller/feeds_test.go.I could put
NewRAMStorage(…) in storage/testutils.go, which could be guarded with //go:build testutils. With go test -tags testutils …, in storage/sqlite_test.go could just use NewRAMStorage(…) directly and similarly in controller/feeds_test.go I could call storage.NewRamStorage(…). But I don't know if I would consider this really elegant.The more I think about it, the more appealing it sounds. Because I could then also use other test-related stuff across packages without introducing other dedicated test packages. Build some assertions, converters, types etc. directly into the same package, maybe even make them methods of types.
If I went that route, I might do the opposite with the build tag and make it something like
!prod instead of testing. Only when building the final binary, I would have to specify the tag to exclude all the non-prod stuff. Hmmm.