Searching yarn

Twts matching #http
Sort by: Newest, Oldest, Most Relevant
In-reply-to » @lyse Is it this one? https://github.com/rivo/tview It’s almost 10 years old but hasn’t seen a 1.0.0 release yet? šŸ¤”

@lyse@lyse.isobeef.org Interesting approach. šŸ¤”

The master branch should never be in a broken state (apart from bugs I don’t know about). Any intermediate state during the development of a larger feature will happen in a different branch.

I mean, yeah, but … I don’t know, I like having ā€œtraditional releasesā€ as a second safety net when I write programs. I like to let things mature for a while and then I cut a new release. So it’s, like, ā€œwe have a bunch of new features and fixes here, and to the best of my knowledge this works fine nowā€. But maybe I’m just paranoid. šŸ¤”

⤋ Read More
In-reply-to » @movq Yes. The author tries hard not to break existing code, but apparently he did this time. In his defense, it's not an official release, I just updated to master. Which is exactly what I always did in the past as there are no real versions (I even think that in one ticket he wrote years ago that master is always stable). That has finally changed a year ago, though: https://github.com/rivo/tview/releases/tag/v0.42.0

There: https://github.com/rivo/tview/issues/442#issuecomment-641898039

⤋ Read More
In-reply-to » @lyse Is it this one? https://github.com/rivo/tview It’s almost 10 years old but hasn’t seen a 1.0.0 release yet? šŸ¤”

@movq@www.uninformativ.de Yes. The author tries hard not to break existing code, but apparently he did this time. In his defense, it’s not an official release, I just updated to master. Which is exactly what I always did in the past as there are no real versions (I even think that in one ticket he wrote years ago that master is always stable). That has finally changed a year ago, though: https://github.com/rivo/tview/releases/tag/v0.42.0

⤋ Read More
In-reply-to » Updated draft: http://movq.de/blog/drafts/changelog/POSTING-en.html

@movq@www.uninformativ.de Brilliant! Oh, I’m super happy to get it all wrong together with you. :-)

[Release notes] are meant for human beings, it’s a human-to-human interaction.

This is one of the most important messages. Absolute key, but misunderstood so often.

⤋ Read More
In-reply-to » Every now and then, I think that I have carefully proof-read my message enough times and hit the "Add message" button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:

@lyse@lyse.isobeef.org Is it this one? https://github.com/rivo/tview It’s almost 10 years old but hasn’t seen a 1.0.0 release yet? šŸ¤”

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

Updated draft: http://movq.de/blog/drafts/changelog/POSTING-en.html

I’ll probably publish this later today. Or maybe not at all. It’s one of those topics that might cause outrage because I’m getting it all wrong. 🤪

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@lyse@lyse.isobeef.org Oh god, yeah. In other words: Devs need to think about who their target audience is. 😐

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@movq@www.uninformativ.de I just ran across another thing. At least I personally couldn’t care less about CI infrastructure changes. Whether they’re using github action a or b or c or version v or w, it is not of my interest. At all. (It might be useful to estimate the supply chain attack risk, though.) If the maintainers want to include them in the changelog – and there are probably people to whom this information is crucial – it’s probably best to document CI infrastructure changes in their own section.

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@movq@www.uninformativ.de You may want to include another antipattern to avoid in your article:

  • bump $same_dependency from 1.0.0 to 1.0.1
  • bump $same_dependency from 1.0.1 to 1.0.2
  • bump $same_dependency from 1.0.2 to 1.1.0
  • bump $same_dependency from 1.1.0 to 1.2.0

⤋ Read More
In-reply-to » Every now and then, I think that I have carefully proof-read my message enough times and hit the "Add message" button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:

@movq@www.uninformativ.de Thank you very much! So, the concept is very similar. The root widget gets the input and can pass it to whatever child has the focus and so on.

My two main issues are the API design, that the input handler sometimes get an additional callback to notify the application about which element is focused, but sometimes not. And that focus switching sometimes just does not work as expected. Anyway.

As for rendering the selected button, I was also thinking about indicating it with some kind of border around it, square brackets seem to be a wonderful choice. :-)

⤋ Read More
In-reply-to » Every now and then, I think that I have carefully proof-read my message enough times and hit the "Add message" button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:

@lyse@lyse.isobeef.org

With multicolored TUIs, I find it usually hard to immediately tell which button is selected if there are just two.

Indeed, I wouldn’t be able to tell in that example, either. movwin works around that by (mostly) assuming that there is no support for colors at all, so there should always be a way to tell which widget has focus, even without colors. That’s why it puts brackets around a button’s label when focused:

The fewer colors you use, the better, I guess. šŸ¤”

⤋ Read More
In-reply-to » Every now and then, I think that I have carefully proof-read my message enough times and hit the "Add message" button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt's cache. This is rather tidious:

@lyse@lyse.isobeef.org

Now I’m curious how movwin deals with that. ;-)

Focus handling? I hardly remember, lol. šŸ˜… Did that 6 months ago and haven’t touched it since. Let’s see.

The core main loop gets keyboard/mouse events from curses. At this level, the main loop only knows about exactly one widget, so it passes the event to that widget (whatever that is, doesn’t matter – they all inherit from the Widget base class, it could be a Window, a WindowManager, or an Edit box directly).

The outermost widget is usually a WindowManager. It implements a few hotkeys of its own, like switching to another window. If none of those hotkeys match, it passes the event to the currently focused window.

Same story here: Window implements some hotkeys (like opening the menu bar). If none of those match, then … the magic happens.

Each Window acts as a focus manager. It can descend into its child widget hierarchy and collect all child widgets in a depth-first search. They are collected into a flat list. Each Window then has an attribute _focus_position, which is an index into that list. Pressing Tab or Shift+Tab increases or decreases that index and that allows you to select the next/previous focusable widget in the current window.

Eventually, Window passes the input event to the currently focused widget.

Usually on initialization, the application can ask a Window object to focus a certain widget. The file selection dialog does that, for example, because the ā€œnaturalā€ focus order would be to focus the Edit box at the top of the window first – but that’s not what the user wants, the Table showing the list of files should be focused.

If no widget ever feels responsible for handling a certain input event, then there’s a global unhandled_input callback that the application can provide (same as in urwid).

I think that’s it.

Hm, that’s more complicated than I remembered, but apparently it works fine, because I completely forgot about this. šŸ˜… All I did in the last few months was make new classes that inherit from Widget, like the new Table class or Edit or HexEdit or whatever, and if they want to get input events, then they must implement the methods input_key() or input_mouse().

Does this answer your question? šŸ˜… (I admit that I didn’t exactly understand your scenario, so I just went ahead and rambled about my implementation. šŸ˜…)

⤋ Read More

Every now and then, I think that I have carefully proof-read my message enough times and hit the ā€œAdd messageā€ button in tt. But then, in the message tree, I spot another missed typo. My process is then to go to my twtxt.txt and fix it by hand. However, I still have to clean up tt’s cache. This is rather tidious:

  1. Recall the sqlitebrowser ~/.local/share/twtxt/tt2.sqlite from my shell history.
  2. Switch to the ā€œBrowse dataā€ tab.
  3. Go to the messages table and wait a second or two until it’s loaded.
  4. Sort by the created_at column twice, so that I get descending order.
  5. Select the first message, which is typically the one in question.
  6. Find the ā€œRemove currently selected rowā€ button in the tool bar.
  7. Commit the changes.
  8. Close sqlitebrowser.

So, I finally implemented the removal of messages from the cache in tt. I can now hit d and confirm the removal. Bam! Should have done that ages ago!

https://lyse.isobeef.org/tmp/tt-confirm-message-removal.png

Next up is the search, I think.

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@lyse@lyse.isobeef.org Thanks!

On the AI changelog part, though, I’d rather recommend to just not have a changelog at all.

I’m afraid that ship has sailed. You can rest assured that someone who uses AI/LLMs for their code (which is almost everybody at this point) will most certainly also use it for changelogs.

I actually considered not mentioning AI output at all, because this just opens a huge can of worms … šŸ˜ž

While going through these terrible GitHub release pages, I also found these ā€œNew Project Contributorsā€ sections

Yeah, they play on a nerd’s pride.

Now, it’s just the same auto shitshow with MR titles in a rolling date-versioned release scheme. It’s just our team who has to deal with that, though. I think I’m the only one who is not a fan of it.

I’ve found that this whole situation is much worse at work than it is in the Free Software world. At work, it’s literally work and hardly anybody actually cares. We still don’t have all people convinced that writing good commit messages or using good branch names is worth the time. It’s … oh god, no, I’m going to stop here, this is bad for my mental health. šŸ˜…

Suffice it to say, all release notes at work are now AI-generated. Nobody gives a fuck.

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@movq@www.uninformativ.de Hahaha, great timing! :-D I love your article and agree with almost all your points.

On the AI changelog part, though, I’d rather recommend to just not have a changelog at all.

Another important thing for me is the deprecation notice section. What do I need to look out for in the future? Should I start to migrate to another API soon? Even right now? Or does it have time?

While going through these terrible GitHub release pages, I also found these ā€œNew Project Contributorsā€ sections (yeah, for that, they found the time to make a section) annoying. Don’t get me wrong, sure, credit where credit is due. But come on. Soooooo much space for an inefficiently formatted (and also unsorted) list. At least it was easy enough to skip over it.

And then, there are also these changelogs or rather notice documents in general that are infested with multicolored emojis all over the place. My brain’s spam filter kicks in and shoves everything to /dev/null immediately. It’s especially a thing at work.

In my previous work project, we also used the Keep A Changelog Format. That was great. You wouldn’t believe how often I resorted back to that document. At least twice a week, often several times a day. I was very glad that we put in this effort. Of course, writing the changelog took its time, but it was worth every minute and more. Reading a many months old item, it was immediately clear. I was our best customer in that regard.

Now, it’s just the same auto shitshow with MR titles in a rolling date-versioned release scheme. It’s just our team who has to deal with that, though. I think I’m the only one who is not a fan of it.

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@lyse@lyse.isobeef.org This is the draft so far, let me know what you think: https://movq.de/blog/drafts/changelog/POSTING-en.html

⤋ Read More
In-reply-to » Oh boy, I absolutely hate this stupid trend of not writing changelogs anymore! Why the fuck would one seriously consider it to be a viable option to just let some shitty bot spew all merge requests on a goddamn GitHub release?! First of all, these merge request titles suck balls. The order of the changes in this "changelog" is completely random (well, probably merge time, which is as useless as the dick on the Pope). They are not grouped by anything at all. Additions, changes, removals, deprecations, etc. randomly mixed up in one giant list. And then "Add feature X", seventeen kilometers further down "Revert 'Add feature X'". Fuck you! Don't include this shit in the first place!

@lyse@lyse.isobeef.org … I am literally writing a blog post about changelogs at this very moment … šŸ˜‚ I am certainly adding the ā€œā€˜add X’ and then later ā€˜remove Xā€™ā€ to my list of DON’Ts. šŸ˜…

⤋ Read More
In-reply-to » @lyse FernwƤrme it is. %)

@movq@www.uninformativ.de Next town, they use FernwƤrme from the waste incineration plant to heat the hospital and probably also parts of the neighborhood. I don’t know how good it works, but in the cold months there’s always steam coming out of the manholes along the road through the woods. I very rarely am in this area, but whenever I am, the steam on the side of the road always amazes me.

⤋ Read More
In-reply-to » I went to check on the fireflies this season. But I didn't see any. Instead lots of moths. At first, I thought it might have been still too light, but it was already dark enough for me to miss and destroy a snail shell. Bummer. Maybe it was too wet tonight. Although, it's probably just another or two weeks until my glowing friends will finally show up.

@lyse@lyse.isobeef.org having seeing, and played with fireflies as a child I envy you. We have none around here. Children have no idea what a firefly is. I mean, they do, but vague, and based on videos and telly.

⤋ Read More
In-reply-to » No hot water today. Again. 🫩

@lyse@lyse.isobeef.org I don’t know what it is. It’s this damn central heating here (distributed over the entire village), where, if something breaks at their end, hundreds of households are affected. šŸ™„

(I don’t get why anyone would build a central heating system in the first place. Isn’t this super inefficient?)

⤋ Read More
In-reply-to » No hot water today. Again. 🫩

@movq@www.uninformativ.de What the heck! Construction work? Eventually, one has to resort to the good old bucket shower. Maybe raise the comfort level with a kettle.

It’s raining all day long over here. You could just stand outside for a while.

I hope it’s back sooner than later!

⤋ Read More