Yeah, user error on my end, never mind. The persisted settings.yaml overrides the command line arguments. That’s surprising to me. I expected the command line options to overrule the config file. Oh well.

@abucci@anthony.buc.ci You can also use -R=false on the command line or leave it out entirely. When explicitly stating -R=false, there has to be an equal sign. With a space (-R false) it’s somehow parsed as -R which is equivalent to -R=true. O_o Very weird. I’d really like to see an error instead.

I still have to figure out the precedence of the settings.yaml or command line arguments. I’m probably holding it wrong, but it seems to give me different results…

@quark@ferengi.one @movq@www.uninformativ.de A general workaround in these cases is to wrap the command in a shell script and reference said script instead.

@mckinley@twtxt.net Wow, I was not aware, that there are different kinds of blackberries. But of course there are. Everything has all sorts of different species, why would it be different with these tasty guys? :-)

I just read up on them and – surprise, surprise – it turns out, the Himalayans are not native to most of Europe either. Doh! It gets even more interesting, their origin is unclear. Maybe Armenia and the Caucasus region. Fascinating!

@abucci@anthony.buc.ci Thank you for using Lyse’s Unofficial Yarnd Help Desk: https://lyse.isobeef.org/tmp/yarnd-disable-registrations.png

Today, I learned about vim "+normal $", how cool! :-) Thanks @quark@ferengi.one!

So, by “evolve” you actually mean “remove”, @prologic@twtxt.net? :-?

Correct, @bender@twtxt.net. Since the very beginning, my twtxt flow is very flawed. But it turns out to be an advantage for this sort of problem. :-) I still use the official (but patched) twtxt client by buckket to actually fetch and fill the cache. I think one of of the patches played around with the error reporting. This way, any problems with fetching or parsing feeds show up immediately. Once I think, I’ve seen enough errors, I unsubscribe.

tt is just a viewer into the cache. The read statuses are stored in a separate database file.

It also happened a few times, that I thought some feed was permanently dead and removed it from my list. But then, others mentioned it, so I resubscribed.

@falsifian@www.falsifian.org @bender@twtxt.net I’d certainly hate my client for automatic feed unsubscription, too.

@prologic@twtxt.net Yeah, I’ve noticed that as well when I hacked around. That’s a very good addition, ta! :-)

Getting to this view felt suprisingly difficult, though. I always expected my feeds I follow in the “Feeds” tab. You won’t believe how many times I clicked on “Feeds” yesterday evening. :-D Adding at least a link to my following list on the “Feeds” page would help my learning resistence. But that’s something different.

Also, turns out that “My Feeds” is the list of feeds that I author myself, not the ones I have subscribed to. The naming is alright, I can see that it makes sense. It just was an initial surprise that came up.

I’m wrong! Both 404 and 410, among others, are considered dead feeds: https://git.mills.io/yarnsocial/yarn/src/branch/main/internal/cache.go#L1343 Whatever that actually means.

@bender@twtxt.net 404 could be indeed a temporary error if the file resides on a mounted remote filesystem and then the mount point fails for some reason. With a symlink from the web root to the file on the mount, the web server probably will not recognize the mount point failure as such. Thus, it might not reply with a 503 Service Unavailable (or something like that), but 404 Not Found instead. (I could be wrong on that, though.)

The right™ way is to signal 410 Gone if the feed does not exist anymore and will not come back to life again. But that’s hard to come by in the wild. Somebody has to manually configure that in almost all situations.

But yes, as @falsifian@www.falsifian.org points out, exponential backoff looks like a good strategy. Probably even report a failure to users somehow, so they can check and potentially unsubscribe.

Transformed four kilograms of blackberries into a bit over three kilograms of blackberry jelly. https://lyse.isobeef.org/brombeergelee-2024-08-19/ The leftover jelly did not fit in prepared canning jars, so I dumped it in a regular drinking glass (which was a mustard glass in its former life):

Image

Let me suggest to use a more secure password, @bender@twtxt.net. One, that does not contain “password”. Like hunter2!!

Oh, the lovely smell of rain. Wonderful! 33°C today, yikes! And I can already hear the thunder rolling in.

By the way, @xuu@txt.sour.is, it looks like you’re running an old, buggy version of yarnd, that duplicates twts in the feed on edit.

The 26°C humidity was through the roof and we just barely escaped the thunderstorm on our stroll. Only the adjacent rain hit us hard. Black clouds caught up on us and we decided to take cover at a barn. Not even a minute later it started to rain cats and dogs for ten minutes straight. Holy crap, that was cool to watch. :-) Also, the smell of rain was just beautiful.

We then decided to continue our return in the light drizzle. But it then got much heavier again and we got completely soaked. With the wet t-shirt and the wind it actually felt rather cold. I anticipated to get rained on, so I left my camera at home. Plenty of paths turned into brook landscapes, several centimeter deep creeks ran down the hilly trails. Quite fascinating. :-)

The sunset a few minutes ago wasn’t too bad:

Image

I’ve been out a few hours again. I came across a dozen or so forest mice. I heard tons of squeaking and saw a lighting fast moving seething mass under leaves and groves. It was impossible to capture anything but I could watch it for two, three minutes. They even seemed to come as close as 20 centimeters judging by the rustle and moving plant leaves. Pretty cool.

But heaps of people had to fire up their noise machines today. That clouded my overall joy in nature. Once a commercial airliner was about to fade away in the distance, the next one already adumbrated itself. Lots of prop planes and even a helicopter. Obnoxious loud super cars and motorcycles with broken off mufflers or I don’t know what. My felt hat amplifies the sound I noted.

Luckily, the sun hid behind the clouds most of the time, so I survived the 25°C. Even hotter tomorrow, yikes!

https://lyse.isobeef.org/waldspaziergang-2024-04-07/

Image

Yeah, the lack of comments makes regular JSON not a good configuration format in my view. Also, putting all keys in quotes and the use of commas is annoying. The big upside is that’s in lots of standard libraries.

I think the appeal with YAML is that is has comments, is kind of easy to write and read and also provides unlimited nesting levels. But it has all its drawbacks, no question. Forbidding tabs, thousands of different string flavors, having so many boolean options (poor Norwegians) etc. I use it, but I don’t particularly enjoy it.

Among simple key value pairs, I like INI files, but with # for comments, not ;. I never used TOML, read up on it yesteray before writing this question, but it looks a bit weird and has some strange rules. I guess I have to give it a try one day.

And yes, as mentioned by several of you, it always depends on the complexity of the configuration at hand.

I’m developing something for the scouts at the moment with rather simple requirements on the config. Currently, there are just four settings. Even INI would be overkill with its section. I selected JSON for now, because that’s readily available with Go’s std lib. But I do not like it.

Btw. what’s your own config format, @xuu@txt.sour.is?

Question of the day: What configuration file formats do you all like and use?

@xuu@txt.sour.is These are indeed iterators. Very weird syntax, though.

@xuu@txt.sour.is Despite that these AoC math text problems are rather silly in my opinion (reminds me of an exercise in our math book where somebody wanted to carry a railroad rail around an L-shaped corner in the house and the question was how long that rail could be so that it still fits — sure, we’ve all carried several meter long railroad rails in our houses by ourselves numerous times…), these algorithms are really neat!

Holy moly, this is a fantastic 37C3 talk about security researchers getting attacked and they reverse-engineer and fully disclose the entire – very advanced – attack. Operation Triangulation: What You Get When Attack iPhones of Researchers Very impressive!

Question to all you Gophers out there: How do you deal with custom errors that include more information and different kinds of matching them?

I started with a simple var ErrPermissionNotAllowed = errors.New("permission not allowed"). In my function I then wrap that using fmt.Errorf("%w: %v", ErrPermissionNotAllowed, failedPermissions). I can match this error using errors.Is(err, ErrPermissionNotAllowed). So far so good.

Now for display purposes I’d also like to access the individual permissions that could not be assigned. Parsing the error message is obviously not an option. So I thought, I create a custom error type, e.g. type PermissionNotAllowedError []Permission and give it some func (e PermissionNotAllowedError) Error() string { return fmt.Sprintf("permission not allowed: %v", e) }. My function would then return this error instead: PermissionNotAllowedError{failedPermissions}

At some layers I don’t care about the exact permissions that failed, but at others I do, at least when accessing them. A custom func (e PermissionNotAllowedError) Is(target err) bool could match both the general ErrPermissionNotAllowed as well as the PermissionNotAllowedError. Same with As(…). For testing purposes the PermissionNotAllowedError would then also try to match the included permissions, so assertions in tests would work nicely. But having two different errors for different matching seems not very elegant at all.

Did you ever encounter this scenario before? How did you address this? Is my thinking flawed?

I played around with parsers. This time I experimented with parser combinators for twt message text tokenization. Basically, extract mentions, subjects, URLs, media and regular text. It’s kinda nice, although my solution is not completely elegant, I have to say. Especially my communication protocol between different steps for intermediate results is really ugly. Not sure about performance, I reckon a hand-written state machine parser would be quite a bit faster. I need to write a second parser and then benchmark them.

lexer.go and newparser.go resemble the parser combinators: https://git.isobeef.org/lyse/tt2/-/commit/4d481acad0213771fe5804917576388f51c340c0 It’s far from finished yet.

The first attempt in parser.go doesn’t work as my backtracking is not accounted for, I noticed only later, that I have to do that. With twt message texts there is no real error in parsing. Just regular text as a “fallback”. So it works a bit differently than parsing a real language. No error reporting required, except maybe for debugging. My goal was to port my Python code as closely as possible. But then the runes in the string gave me a bit of a headache, so I thought I just build myself a nice reader abstraction. When I noticed the missing backtracking, I then decided to give parser combinators a try instead of improving on my look ahead reader. It only later occurred to me, that I could have just used a rune slice instead of a string. With that, porting the Python code should have been straightforward.

Yeah, all this doesn’t probably make sense, unless you look at the code. And even then, you have to learn the ropes a bit. Sorry for the noise. :-)

Any good ideas on how to maintain ~/go/pkg/mod and to remove old garbage?

I started reading the proposal to introduce operator overloading in Go version 2 that I like to see: https://github.com/golang/go/issues/27605 Now a few hours later I ended up at this gem. Write a program that makes 2+2=5: https://codegolf.stackexchange.com/questions/28786/write-a-program-that-makes-2-2-5 There are some awesone solutions. :-)

@xuu@txt.sour.is Really sweet! Why did you pick MD5 as the example?

@prologic@twtxt.net Alright, there’s some erroneous markdown parsing going on, I reckon. In my original twt I have a code block surrounded by three backticks. The code block itself contains a single backtick. However, at least for rendering, yarnd shows three backticks instead (not sure if my markdown is invalid, though):

Image

Great, last system update broke something, building from current master I get:

/usr/bin/ld: /lib/x86_64-linux-gnu/libm.so.6: unknown type [0x13] section `.relr.dyn'

What the heck!?

And it also appears that I’m not really able to reproduce this unread bug. It only kind of works a single time. And it has something to do with my config. Not sure what it is yet. I also noticed that the <updated> timestamps in the entries somehow shifted between the old and new feed. Da fuq!?

Hmmm, after fixing my feeds to move the <author> from <entry>s to <feed>, Newsboat marked all old affected articles as unread. IDs were untouched, of course. Need to investigate that. Had something similar happen with another feed change I did some time ago. Can’t remember what that was, though.

@mckinley@twtxt.net Thank you! I didn’t even know about signing and encrypting XML documents. Right, RSS is a little bit messy.

Unfortunately, the autodiscovery document in one of your linked resources does not exist anymore. What annoys me in Atom is the distinction between <id> and <link>. I always want my URL also to be my ID, so I have to duplicate that – unnecessarily in my opinion.

Also, never found a good explanation why I should add <link rel="self" … /> to my feeds. I just do, but I don’t understand why. The W3C Feed Validation Service says:

[…] This value is important in a number of subscription scenarios where often times the feed aggregator only has access to the content of the feed and not the location from which the feed was fetched.

This just sounds like a very questionable bandaid to bad software architecture. Why would the feed parser need access to the feed URL at this stage? And if so, why not just pass down the input source? Just doesn’t make sense to me.

Also, I just noticed that I reference the http://purl.org/rss/1.0/modules/syndication/ namespace, but don’t use it in most of my feeds. Gotta fix that. Must have copied that from my yfav feed without paying attention what I’m doing.

Your article made me reread the Atom spec and I found out, that I can omit the <author> in the <entry> when I specify a global <author> at <feed> level. Awesome! Will do that as well and thus reduce the feed size.

We had a nice sunset a few minutes ago:

Image

Welcome back, @quark@ferengi.one! Your web server doesn’t send back a Last-Modified header for your feed, so the official twtxt client complains not to cache it. I just fixed that, so that tt shows your feed (of course no progress has been made in the meantime). And the Date header of your server seems to be quite funny, too. ;-)

@mckinley@twtxt.net Haha, while composing I was wondering two or three times whether I should throw my thoughts in an HTML page instead. But out of utter laziness I discarded that idea. ¯_(ツ)_/¯

@prologic@twtxt.net Error handling especially in Go is very tricky I think. Even though the idea is simple, it’s fairly hard to actually implement and use in a meaningful way in my opinion. All this error wrapping or the lack of it and checking whether some specific error occurred is a mess. errors.As(…) just doesn’t feel natural. errors.Is(…) only just. I mainly avoided it. Yesterday evening I actually researched a bit about that and found this article on errors with Go 1.13. It shed a little bit of light, but I still have a long way to go, I reckon.

We tried several things but haven’t found the holy grail. Currently, we have a mix of different styles, but nothing feels really right. And having plenty of different approaches also doesn’t help, that’s right. I agree, error messages often end up getting wrapped way too much with useless information. We haven’t found a solution yet. We just noticed that it kind of depends on the exact circumstances, sometimes the caller should add more information, sometimes it’s better if the callee already includes what it was supposed to do.

To experiment and get a feel for yesterday’s research results I tried myself on the combined log parser and how to signal three different errors. I’m not happy with it. Any feedback is highly appreciated. The idea is to let the caller check (not implemented yet) whether a specific error occurred. That means I have to define some dedicated errors upfront (ErrInvalidFormat, ErrInvalidStatusCode, ErrInvalidSentBytes) that can be used in the err == ErrInvalidFormat or probably more correct errors.Is(err, ErrInvalidFormat) check at the caller.

All three errors define separate error categories and are created using errors.New(…). But for the invalid status code and invalid sent bytes cases I want to include more detail, the actual invalid number that is. Since these errors are already predefined, I cannot add this dynamic information to them. So I would need to wrap them à la fmt.Errorf("invalid sent bytes '%s': %w", sentBytes, ErrInvalidSentBytes"). Yet, the ErrInvalidSentBytes is wrapped and can be asserted later on using errors.Is(err, ErrInvalidSentBytes), but the big problem is that the message is repeated. I don’t want that!

Having a Python and Java background, exception hierarchies are a well understood concept I’m trying to use here. While typing this long message it occurs to me that this is probably the issue here. Anyways, I thought, I just create a ParseError type, that can hold a custom message and some causing error (one of the three ErrInvalid* above). The custom message is then returned at Error() and the wrapped cause will be matched in Is(…). I then just return a ParseError{fmt.Sprintf("invalid sent bytes '%s'", sentBytes), ErrInvalidSentBytes}, but that looks super weird.

I probably need to scrap the “parent error” ParseError and make all three “suberrors” three dedicated error types implementing Error() string methods where I create a useful error messages. Then the caller probably could just errors.Is(err, InvalidSentBytesError{}). But creating an instance of the InvalidSentBytesError type only to check for such an error category just does feel wrong to me. However, it might be the way to do this. I don’t know. To be tried. Opinions, anyone? Implementing a whole new type is some effort, that I want to avoid.

Alternatively just one ParseError containing an error kind enumeration for InvalidFormat and friends could be used. Also seen that pattern before. But that would then require the much more verbose var parseError ParseError; if errors.As(err, &parseError) && parseError.Kind == InvalidSentBytes { … } or something like that. Far from elegant in my eyes.

I’m trying to switch from Konversation to irssi. Let’s see how that goes. Any irssiers out there who can recommend specific settings or scripts? I already got myself trackbar.pl and nickcolor.pl as super-essentials. Also trying window_switcher.pl. Somehow my custom binds for Ctrl+1/2/3/etc. to switch to window 1/2/3/etc. doesn’t do anything: { key = "^1"; id = "change_window"; data = "1"; } (I cannot use the default with Alt as this is handled by my window manager). Currently, I’m just cycling with Ctrl+N/P. Other things to solve in the near future:

• better, more colorful and compact theme (just removed clock from statusbar so far)
  
• getting bell/urgency hints working on arriving messages
  
• nicer tabs in status bar, maybe even just channel names and no indexes
  
• decluster status bar with user and channel modes (I never cared about those in the last decade)

@movq@www.uninformativ.de I usually only use eggs for baking or fry them for potatoes and spinach. @prologic@twtxt.net Why don’t you have them anymore? Did the fox get them all when the door didn’t close in time? ]:->

Alright, check this out. I just kinda completed today’s project of converting a jeans into a saw bag. It’s not fully done, the side seams on the flap need some more hand sewing, that’s for sure. No, I don’t have a sewing machine. Yet?

Image

At first I wanted to put in the saw on the short side, but that would have made for more sewing work and increased material consumption. As a Swabian my genes force me to be very thrifty. Slipping in on the long side had the benefit of using the bottom trouser leg without any modification at all. The leg tapers slightly and gets wider and wider the more up you go. At the bottom it’s not as extreme as at the top.

The bag is made of two layers of cloth for extra durability. The double layers help to hide the inner two metal snap fastener counter parts, so the saw blade doesn’t get scratched. Not a big concern, but why not doing it, literally no added efforts were needed. Also I reckon it cuts off the metal on metal clinking sounds.

The only downside I noticed right after I pressed in the receiving ends of the snap fasteners is that the flap overhangs the bag by quite a lot. I fear that’s not really user-friendly. Oh well. Maybe I will fold it shorter and sew it on. Let’s see. The main purpose is to keep the folding saw closed, it only locks in two open positions.

Two buttons would have done the trick, with three I went a bit overkill. In fact the one in the middle is nearly sufficient. Not quite, but very close. But overkill is a bit my motto. The sides making up the bag are sewed together with like five stitch rows. As said in the introduction, the flap on the hand needs some more love.

Oh, and if I had made it in a vertical orientation I would have had the bonus of adding a belt loop and carrying it right along me. In the horizontal layout that’s not possible at all. The jeans cloth is too flimsy, the saw will immediately fall out if I open the middle button. It’s not ridgid enough. Anyways, I call it a success in my books so far. Definitely had some fun.

My first attempt of guessing a German word was a close failure:

Image