A response of sorts to commit robbery.

I’ve been on both sides of commit misattribution. Sometimes my commit gets sniped. Sometimes I’m the one doing the sniping. It’s very rarely intentional.

In a project like OpenBSD, we’d have three Todds and four Jasons, which led to frequent confusion. Forgetting exactly who contributed what would happen occasionally. Emails get forwarded around. And I think every new OpenBSD developer goes through the experience of having half their commits sniped for the first month because other developers think you’re submitting a patch, not requesting review.

I’d guess 1% of commits are misattributed in some way. There’s an acknowledgement, but it’s incomplete. Or it’s omitted. Or it credits somebody else entirely. I think that’s not bad overall, though it does mean 1% of first time contributors have a suboptimal experience. It sucks to be the statistic.

Could the 1% be improved? Sure, just require a few more TPS reports before commits are permitted. If the solution is that we simply need to ask the maintainers to care more, are we sure they don’t care? There’s already enough people burning out and dropping out of open source work.

I think Ariel’s story could have been framed better, with a rather less villainous counterparty. I almost didn’t read it, because I don’t care about commit drama, but the story of the debugging was really interesting. I’m glad I read that! But hey, your blog, your story. That said, I don’t think it’s possible to generalize from one event to sweeping conclusions like this is why people don’t contribute to open source. This is, maybe, why 1% of people don’t contribute to open source.

Can you use go run for scripting? I wrote a small program to find out.

package main

import (
    "fmt"
    "os"
    "os/exec"
    "time"
)

func main() {
    start := time.Now()
    gogo := fmt.Sprintf(`package main
    import "fmt"
    func main() {
        fmt.Printf("the time was %s\n")
    }`, start)
    os.WriteFile("gogo.go", []byte(gogo), 0666)
    cmd := exec.Command("go", "run", "gogo.go")
    cmd.Stdout = os.Stdout
    cmd.Run()
    end := time.Now()
    fmt.Printf("that took %s\n", end.Sub(start))
}

$ go run gorun.go
the time was 2024-01-05 12:04:01.042488 -0500 EST m=+0.000077959
that took 329.81325ms

On my somewhat older m3 running openbsd, it takes about 330ms. On a less old chromebook, it takes about 100ms. Not bad. On an M1 macbook, it varies wildly between 150ms and 300ms.

So I think not fast enough for interactive use. Probably fast enough for a continuously changing cronjob, though I wonder why you wouldn’t change the inputs. But I guess if you’re a big believer in configuration through compilation, and also have constantly changing requirements, it’s fast enough to get by.

For comparison, yaegi is still 10x or more quicker at putting something on the screen.

go build

I almost exclusively run go build. Actually, I run make and that runs go build, because that’s how my fingers work. So it wasn’t until recently that I noticed that go run is as fast as it is. I was used to a very observable one second per build.

Turns out go build will run hg stat for every build, which go run skips, and that was the slowest part of the process. Easily remedied by switching to chg.

I didn’t realize I needed this until I implemented it, and now, oh wow, can’t imagine life without it.

more...

Another month of poking around trying to make an almost useful terminal emulator.

more...

I wrote my own terminal and you won’t believe what happened next. I called it vertigo.

more...

The monaspace fonts introduced the idea of texture healing. I think of it as a sort of kerning for monospace fonts, though there’s probably some reason that’s technically incorrect. The basic idea is that some letters want more space, while others want less space, but this is hard to achieve in a monospace grid. And so they made a special font that includes alternative glyphs for letter pairs, so that i can donate some space to m.

more...

What’s next after you write your own text editor and mail client? How about a terminal? In fact, as a practice exercise or to learn some new skills, I’d say a terminal emulator makes for a much better target. It’s composed of many parts, but at an approachable level, making it easy to make tangible progress. In this way, I think it makes for a good introductory project. At the same time, there’s a very long tail of features that can be added to keep things interesting.

more...

There’s a feature called bracketed paste supported by some “modern” terminals and editors, etc. When text is pasted from the clipboard, the terminal brackets it in special markers so that the receiving program knows it came from the clipboard and not the keyboard, and thus might turn off autoindent, etc.

It’s also supported by some shells, and I’ve lost count of how many times I’ve seen people claim that this is a security measure. Yeah, sure, it’s totally safe to paste commands from a website into the shell, because bracketed paste will let you review them before executing.

Does it work? The brackets delimiting the pasted text are just bytes as well, in band. A website can put the end paste sequence into the clipboard as easily as any other text.

Here are two buttons for testing. One runs ls. The second tries a little harder.

ls bonus

In testing, xterm turns the escape into a space, and nothing happens but a little gibberish spray. Other terminals appear to be not so lucky.

Go 1.21 added experimental support for fixing the loop capture bug. For reasons it’s never really bothered me, but the other loop bug does bite me some times. This is the one where the loop values are values.

I want references but go doesn’t have references.

values

The problem is easy to see when you’re looking for it, and hard to see when you’re glossing over the code.

func resetScores(players []Player) {
    for _, player := range players {
        player.score = 0
    }
}

Before and after “the” loop fix, this will dutifully set the player’s score to zero. But which player? An anonymous player that only exists in the loop. The array will remain unchanged. Ugh.

hand fix

Fixing this requires slightly rewriting the loop.

func resetScores(players []Player) {
    for i := range players {
        players[i].score = 0
    }
}

This looks kinda weird I think, and it’s not my first instinct to write it this way. I really just want a way to say hi, I’m iterating over the elements of this array, give me a reference to them.

mechanical fix

So let’s add references to go.

func resetScores(players []Player) {
    for _, &player := range players {
        player.score = 0
    }
}

This can be translated by powerful state of the art tools into the go you’d have to write otherwise.

func resetScores(players []Player) {
    for  _i, _ := range players {
        player := &players[_i]
        player.score = 0
    }
}

oh well

What’s annoying is the above broken form works if the array contains pointers. A lot of my code uses pointers, so I get used to writing the first form, and then it breaks when I do something different. Or I decide to optimize the code and reduce allocations by switching from []*Player to []Player without a careful audit of the impacted loops. Alas, I probably wouldn’t think to use the reference form even if available until it’s too late.

The common mistakes wiki lists the capture bug twice, but doesn’t mention this bug.

There’s an amazing and famous scene of two hackers sharing a keyboard on NCIS, but it gets a lot of derision on the internet. What people don’t realize is that their mockery only reveals their own lack of skill. As everyone knows, a true hacker has mastered the art of dual wielding, and a keyboard that can be dual wielded by one might also be used by two hackers in tandem.

more...