![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ailbhekaberett
About twenty metres up the road is a front garden that is, at this time of year, full of ridiculous daffodils. It is an Annual Delight. I took this photo yesterday, and then I dragged A out to visit it at lunchtime today, in glorious weather. It has been a good day.
![[syndicated profile]](https://www.dreamwidth.org/img/silk/identity/feed.png){kind=small}
cks_techblog_feedI have a Python program that calculates and prints various pieces of Linux memory information on a per-cgroup basis. In the beginning, its life was simple; cgroups had a total memory use that was split between 'user' and '(filesystem) cache', so the program only needed to display either one field or a primary field plus a secondary field. Then I discovered that there was additional important (ie, large) kernel memory use in cgroups and added the ability to report it as an additional option for the secondary field. However, this wasn't really ideal, because now I had a three-way split and I might want to see all three things at once.
A while back I wrote up my realization about flexible string formatting with named arguments. This sparked all sorts of thoughts about writing a general solution for my program that could show any number of fields. Recently I took a stab at implementing this and rapidly ran into problems figuring out how I wanted to do it. I had multiple things that could be calculated and presented, I had to print not just the values but also a header with the right field names, I'd need to think about how I structured argparse argument groups in light of argparse not supporting nested groups, and so on. At a minimum this wasn't going to be a quick change; I was looking at significantly rewriting how the program printed its output.
The other day, I had an obvious realization: while it would be nice to have a fully general solution that could print any number of additional fields, which would meet my needs now and in the future, all that I needed right now was an additional three-field version with the extra fields hard-coded and the whole thing selected through a new command line argument. And this command line argument could drop right into the existing argparse exclusive group for choosing the second field, even though this feels inelegant.
(The fields I want to show are added with '-c' and '-k' respectively in the two field display, so the morally correct way to select both at once would be '-ck', but currently they're exclusive options, which is enforced by argparse. So I added a third option, literally '-b' for 'both'.)
Actually implementing this hard-coded version was a bit annoying for structural reasons, but I put the whole thing together in not very long; certainly it was much faster than a careful redesign and rewrite (in an output pattern I haven't used before, no less). It's not necessarily the right answer for the long term, but it's definitely the right answer for now (and I'm glad I talked myself into doing it).
(I'm definitely tempted to go back and restructure the whole output reporting to be general. But now there's no rush to it; it's not blocking a feature I want, it's a cleanup.)
cks_techblog_feedOne of my long standing gripes with Debian and Ubuntu is, well, I'll quote myself on the Fediverse:
I understand that Debian wants me to use 'apt' instead of apt-get, but the big reason I don't want to is because you can't turn off that progress bar at the bottom of your screen (or at least if you can it's not documented). That curses progress bar is something that I absolutely don't want (and it would make some of our tooling explode, yes we have tooling around apt-get).
Over time, I've developed opinions on what I want to see tools do for progress reports and other text output, and what I feel is increasingly too clever in tools that makes them more and more inconvenient for me. Today I'm going to try to run down that taxonomy, from best to worst.
less have some
ability to handle backspaces, but this will give you heartburn in
your own programs.
less and anything that already deals with
backspacing over things will generally be able to handle this.
I believe apt-get does this.
script and then
look over them later with pagers like less, although
less can process a limited amount of terminal codes, including
colours.
less to
display, search, or analyze and process. However, your terminal
program of choice is probably still going to see this as line by
line output and preserve various aspects of scrollback and so on.
top. In some environments this may damage or destroy
terminal scrollback.
An additional reason I dislike this style is that it causes output
to not appear at the current line. When I run your command line
program, I want your program to print its output right below where
I started it, in order, because that's what everything else does.
I don't want the output jumping around the screen to random other
locations. The only programs I accept that from are genuine full
screen programs like top. Programs that insist on displaying
things at random places on the screen are not really command line
programs, they are TUIs cosplaying being CLIs.
My strong system administrator's opinion is that if you're tempted
to do any of these other than the first, you should provide a command
line switch to turn these off. Also, you should detect unusual
settings of the $TERM environment variable, like 'dumb' or perhaps
'vt100', and automatically disable your smart output. And you should
definitely disable your smart output if $TERM isn't set or you're
not outputting to a (pseudo-)terminal.
(Programs that insist on fancy output no matter what make me very unhappy.)
cks_techblog_feedI recently read Evan Hahn's The two kinds of error (via), which talks very briefly in passing about logging, and it sparked a thought. I've previously written my system administrator's view of what an error log level should mean, but that entry leaves out something fundamental about log messages, which is that under most circumstances, log messages are for the people operating your software (I've sort of said this before in a different context). When you're about to add a non-debug log message, one of the questions you should ask is what does someone running your program get out of seeing the message.
Speaking from my own experience, it's very easy to write log messages (and other messages) that are aimed at you, the person developing the program, script, or what have you. They're useful for debugging and for keeping track of the state of the program, and it's natural to write them that way since you're immersed in the program and have all of the context (this is especially a problem for infrequent error messages, which I've learned to make as verbose as possible, and a similar thing applies for infrequently logged messages). But if your software is successful (especially if it gets distributed to other people), most of the people running it won't be the developers, they'll only be operating it.
(This can include a future version of you when you haven't touched this piece of software for months.)
If you want your log messages to be useful for anything other than being mailed to you as part of a 'can you diagnose this' message, they need to be useful for the people operating the software. This doesn't mean 'only report errors that they can fix and need to', although that's part of it. It also means making the information you provide through logs be things that are useful and meaningful to people operating your software, and that they can understand without a magic decoder ring.
If people operating your software won't get anything out of seeing a log message, you probably shouldn't log it by default in the first place (or you need to reword it so that people will get something from it). In Evan Hahn's terminology, this apply to the log messages for both expected errors and unexpected errors, although if the program aborts, it should definitely tell system administrators why it did.
For a system administrator, log messages about expected errors let us diagnose what went wrong to cause something to fail, and how interested we are in them depends partly on how common they are. However, how common they are isn't the only thing. MTAs often have what would be considered relatively verbose logs of message processing and will log every expected error like 'couldn't do a DNS lookup' or 'couldn't connect to a remote machine', even though they can happen a lot. This is very useful because one thing we sometimes care a lot about is what happened to and with a specific email message.
cks_techblog_feedI've said before in various contexts (eg)
that I'm very attached to the venerable xterm as my terminal
(emulator) program, and I'm not looking forward to the day that I
may have to migrate away from it due to Wayland (although I probably
can keep running it under XWayland, now that I think about it). But
I've never tried to write down a list of the things that make me
so attached to it over other alternatives like urxvt, much less
more standard ones like gnome-terminal. Today I'm going to try to
do that, although my list is probably going to be incomplete.
Yes, I can set my shell environment and many programs to not use colours, but I can't set all of them; some modern programs simply always use colours on terminals. Xterm can be set to completely ignore them.
(For instance, I'm extremely attached to double-click selecting only individual directories in full paths, rather than the entire thing. I can always swipe to select an entire path, but if I can't pick out individual path elements with a double click my only choice is character by character selection, which is a giant pain.)
Based on a quick experiment, I think I can make KDE's konsole behave more or less the way I want by clearing out its entire set of "Word characters" in profiles. I think this isn't quite how xterm behaves but it's probably close enough for my reflexes.
Of these, the hardest two to duplicate are probably xterm's double click selection behavior of what is a word and xterm's large selection behavior. The latter is hard because it requires the terminal program to not use mouse button 3 for a popup menu.
I use some other xterm features, like key binding, including duplicating windows, but I could live without them, especially if the alternate terminal program directly supports modern cut and paste in addition to xterm's traditional style. And I'm accustomed to a few of xterm's special control characters, especially Ctrl-space, but I think this may be pretty universally supported by now (Ctrl-space is in gnome-terminal).
There are probably things that other terminal programs like konsole, gnome-terminal and so on do that I don't want them to (and that xterm doesn't). But since I don't use anything other than xterm (and a bit of gnome-terminal and once in a while a bit of urxvt), I don't know what those undesired features are. Experimenting with konsole for this entry taught me some things I definitely don't want, such as it automatically placing itself where it was before (including placing a new konsole window on top of one of the existing ones, if you have multiple ones).
(This elaborates on a comment I made elsewhere.)
cosmolinguistAfter two days of utter misery at work, I was amazed that I actually got to finish on time -- I had not been expecting to!
The unstoppable force of my executive dysfunction met the immovable object of a deadline to respond to the Government's call for evidence on Developing the automated vehicles regulatory framework.
Ugh. I am so disgusted by the whole concept of self-driving cars that it was...well, not the only reason it's difficult to write about, but it was definitely one of them.
In other car-related news, I'm always delighted to read that other people are noticing the same things I am: not only are car headlights too damn bright, but cars are too damn big.
...while bigger cars may be safer for their occupants, critics insist they are considerably less safe for other road users. "Whether you're in another car [or] a pedestrian, you're more likely to be seriously injured if there's a collision with one of these vehicles," argues Tim Dexter, vehicles policy manager at T&E. He is also concerned about the implications for cyclists.
Research carried out in 2023 by Belgium's Vias Institute, which aims to improve road safety, suggested that a 10cm (3.9in) increase in the height of a car bonnet could increase the risk of vulnerable road users being killed in a collision by 27%. T&E also highlights concerns that high bonnets can create blind spots.
This is also something I've read about in the U.S., thanks to Victoria Scott:
If, in the span of one year, 18 fully-loaded Boeing 747s crashed with no survivors, we’d reappraise airspace. We’d question how we build airplanes and how we train pilots. We would recognize this as a failure of the system, not as individual mistakes of 18 pilots. Our roads should be no different.
The good news is that we have sensible solutions in plain sight: lower speed limits, redesign intersections, build roads that prioritize pedestrians and cars equally, and most importantly, reward automakers for building smaller vehicles with better visibility. The bad news is these require some sacrifice from drivers. Safer roads have lower speed limits—likely enforced by ticketing in one form or another. These roads also require more concentration to drive on. SUVs and pickups would need to revert back to 90s sizing, and all of our cars would need to shrink. These are all a hard sell in America, admittedly, but until they happen, we keep losing lives needlessly.
I genuinely love cars, and I’ve owned some big trucks. I understand the appeal of high speeds and lifted rigs, and I’m loath to give them up. But even I can’t accept a future wherein 7,500 are killed each year, especially when the solutions are so tangible and the rewards so massive. I’d accept small sacrifices if thousands more could live decades longer. I hope the rest of America agrees.
anais_pf posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
thefridayfivedray.oursinSo, I may have mentioned I would be giving a paper in one of the Fellows' Symposia of the Institution with which I am now affiliated, coming up over the horizon very soon. And I had originally intended to revisit some research I did Before Events Intervened and Do Something with that, but it has not been coming together as I should like, needs more percolating I think. So I am instead returning to a project I put aside when other things supervened and demanded my attention, for which I did a preliminary paper or two, and can spruce up and get, I hope, some feedback on, and maybe kickstart this back into action.
Meanwhile....
I think I mentioned being solicited to give an entertaining and instructive talk on the history of johnnies/baudruches some months hence, which I have a fair amount of material already on hand for. However, what the organisers would like is An Image for publicity purposes, fairly soonish, and REALLY. One is tempted to go with the Dudley Hoard which require a good deal of imagination to reconstruct for their original purpose.
Younger scholar whom I have been somewhat informally mentoring has now submitted their PhD thesis and would like me to read it, and think of what might come up in viva.
The project which I was involved in for some considerable while which went very weird last year, with me being somewhat accidental being left out of the loop for some months due to error in email address, so I never really got the full story, is being revived in a smaller and more defined way as a journal special issue edited by Old Friend and Me.
Meanwhile I am in the process of getting the latest volume of the Interminable Saga prepped for publication.
markdominus_feedSomething interesting happened at work this week. Our company is going to a convention later this month, and they will have a booth with big TV screens showing statistics that update in real time. My job is to write the backend server that delivers the statistics.
I read over the documents that the product people had written up about what was wanted, asked questions, got answers, and then turned the original two-line ticket into a three-page ticket that said what should be done and how. I intended to do the ticket myself, but it's good practice to write all this stuff down, for many reasons:
Writing things down forces me to think them through carefully and realize what doesn't make sense or what I still don't understand.
I forget things easily and this will keep the plan where I can find it.
I might get sick, and if someone else has to pick up the project this might help them understand what I was doing.
If my boss gets worried that all I do is post on 4chan all day, this is tangible work product that proves I did something else that might have enhanced shareholder value.
If I'm tempted to spend the day posting on 4chan, and then to later claim I spent the time planning the project, I might fool my boss. But without that tangible work product, I won't be able to fool myself, and that's more important.
Conversely if I later think back and ask “What was I doing the week of March 2?” I might be tempted to imagine that all I did was post on 4chan. But the three pages of ticket description will prove to me that I am not just a lazy slacker. This is a real problem for me.
In principle, a future person going back to extend the work might find this helpful documentation of what was done and why. Does this ever really happen? I don't know, but it might.
I like writing because writing is fun.
A few days after I wrote the ticket, something unexpected happened. It transpired that person who was to build the front-end consumer of my statistics would not be a professional programmer. It would be the company's Head of Product, a very smart woman named Amanda. The actual code would be written by Claude, under her supervision.
I have never done anything like this before, and I would not have wanted to try it on a short deadline, but there is some slack in the schedule and it seemed a worthwhile and exciting experiment.
Amanda shared some screencaps of her chats with Claude about the project, and I suggested:
When you get a chance, please ask Claude to write out a Markdown file memorializing all this. Tell it that you're going to give it to the backend programmer for discussion, so more detail is better. When it's ready, send it over.
Claude immediately produced a nine-page, 14-part memo and a half-page overview. I spent a couple of hours reviewing it and marking it up.
It became immediately clear that Claude and I had very similar ideas about how the project should go and how the front and back ends would hook up. So similar that I asked Angela:
It looks like maybe you started it off by feeding it my ticket description. Is that right?
She said yes, she had. She had also fed it the original product documents I had read.
I was delighted. I had had many reasons for writing detailed ticket descriptions before, but the most plausible ones were aimed back at myself.
The external consumers of the documentation all seemed somewhat unlikely. The person who would extend the project in the future probably didn't exist, and if they did they probably wouldn't have thought to look at my notes. Same for the hypothetical person who would take over when I got sick. My boss probably isn't checking up on me by looking at my ticketing history. Still, I like to document these things for my own benefit, and also just in case.
But now, because I had written the project plan, it was available for consumption when an unexpected consumer turned up! Claude and I were able to rapidly converge on the design of the system, because Amanda had found my notes and cleverly handed them to Claude. Suddenly one of those unlikely-seeming external reasons materialized!
On Mastodon I keep seeing programmers say how angry it makes
them that people are willing to write detailed CLAUDE.md and
PROJECT.md files for Claude to use, but they weren't willing to
write them for their coworkers. (They complain about this as if this
is somehow the fault of the AI, rather than of the people who failed
in the past to write documentation for their coworkers.)
The obvious answer to the question of why people are willing to write documentation for Claude but not for their coworkers is that the author can count on Claude to read the documentation, whereas it's a rare coworker who will look at it attentively.
Rik Signes points out there's a less obvious but more likely answer: your coworkers will remember things if you just tell them, but Claude forgets everything every time. If you want Claude to remember something, you have to write it down. So people using Claude do write things down, because otherwise they have to say them over and over.
And there's a happy converse to the complaint that most programmers don't bother to write documentation. It means that people like me, professionals who have always written meticulous documentation, are now reaping new benefits from that always valuable practice.
Not everything is going to get worse. Some things will get better.
scalziwhatever_feed
We have an outline! Major characters, plot lines, and various important story beats all laid out. Now to start writing it all up. Very exciting stuff.
This is worth noting because this is the first time Athena and I are doing this, but it won’t be the last, since we’ll be using this process to develop other projects soon. This is what our little family business does, after all: Think of cool stuff that we can then develop into actual projects that will hopefully become things you can see and buy. This is, hopefully, the first of many.
— JS
tamaranth
Mercutio has never been in love. Not unless you count a boy whose face he can barely remember. Not unless you count the world. [loc. 2328]
Mercutio Guertio (yes, that Mercutio) meets Dante Alighieri at the Battle of Campaldino in 1289: they are caught in a freak storm -- where they glimpse spectral armies, and becomes certain that there is a third man with them -- but stumble back to the carnage of the battlefield, and subsequently become friends. Mercurio, though, has been changed: he sees people who are not there, and does not recognise the stars in the night sky. Then Dante, grieving the death of 'his' Beatrice, is pulled into Faerie, where he wanders in a dark wood...
( Read more... )
nanila posting in awesomeersrmc28The university hockey season is nearly over. Huskies have played our last league game (I say 'our' but I was actually playing with Warbirds in a different city at the time), Varsity is coming up Saturday week, and then there's Nationals in April before we move into summer ice training. We had our Varsity dinner on Tuesday in Clare College and I became sharply aware during that evening that all things come to an end and some people will graduate this summer and leave. This is a university, people are always arriving and leaving, but it's nearly thirty years since I first arrived in Cambridge and I'm still not used to friends leaving.
I love everyone in this photograph (and a couple more teammates who didn't make it to the dinner).
Varsity: Saturday 14 March, tickets go on general sale at noon today, I didn't make the Huskies ("mixed 2nds") Varsity squad but I'm playing in the alumni game and helping out with (at least) Huskies and Women's Blues.
fred_mouseI have not been reading all that much* lately. Since the last post I have finished three books, all of which are from the old murder mystery list -- mostly because I have them on my phone, and I've been reading them in waiting rooms. In decreasing order of how much I liked them:
* not counting a bit of short fiction, a lot of Heated Rivalry fic, and chapters out of a lot of books that I haven't actually made it to the end of because it requires focus I haven't had.
fred_mouseuni: sent the ethics application to supervisors on ... Tuesday. Have started setting the foundations for the next sub-project, but haven't gathered together all the notes yet. This will be hunting for kids books. I am being optimistic and also grandiose about how much I'm hoping to achieve.
annual not-goals: reading (1) and music (4) are on track; the others either I've not really done anything on or they aren't currently achievable.
medical: 7/15 treatments down; I look mildly sunburned. I'm getting the expected kinds of side effects, albeit at levels that seem higher than is warranted for such a small area of body (today I am so crashed and food is a struggle, and language is a bit wonky; I told the nurse my head was full of glue). I have found some details that help with the overstimulation: I wear non-slip socks (no shoes on the bed, no bare feet to stress the staff, no taking shoes off), I keep my eyes closed and focus on breathing except when watching the 'how much to breath' lights, I take my belt off even though I don't need to so it doesn't dig in.
craft: I have been making progress on one of the two knitting projects that I'm counting as 'active' which means that some time this year I might get to the pattern that buttonsbeadslace shared with me (which needs to be done for ... September, because b'day gift. and then a second for october, and a third for December, because I think I'm funny). No other craft has had a look in. I did do weekly drawing for a bit but didn't find the spot in the routine it fits and keep forgetting.
music: I have played some of the Hanon's exercises roughly once a week. Monday group (viola) is going well; Wednesday (violin) I've made it to more than I've missed and alternating Sundays (recorder) are also good although there is less music happening there than would be my preference (P's house guest is in the final throes of writing a PhD thesis in mathematics; P does not do math; ariaflame and I have tangentially relevant knowledge, house guest take the opportunity to talk about their maths)
ailbhe - Use Lion With Eggkaberett - have a daffodil(s)cks_techblog_feed - Sometimes, non-general solutions are the right answercks_techblog_feed - A taxonomy of text output (from tools that want to be too clever)cks_techblog_feed - Log messages are mostly for the people operating your softwarecks_techblog_feed - The things that make me so attached to xterm as my terminal programcosmolinguist - Car shitanais_pf in thefridayfive - The Friday Five for 6 March 2026james_davis_nicoll - Happy Threads Dayoursin - Like buses in a bunchmarkdominus_feed - Documentation is a message in a bottlescalziwhatever_feed - Update, re: Secret Project at the Scalzi Compoundjames_davis_nicoll - The Paradox Men by Charles L. Harnessandrewducker - Interesting Links for 05-03-2026oursin - (no subject)tamaranth - 2026/033: Mercutio — Kate Heartfieldnanila in awesomeers - Just One Thing (05 March 2026)rmc28 - Endings in sightfred_mouse - Reading notesfred_mouse - Small updatesbaggyeyes
