Since using lots of Vim sessions in a terminal I had a brief dalliance with Nova (I did/do like it, but it’s not cross-platform) and then ended up with Helix. At work I tend to use Helix in the same way I was using Vim but instead of Terminal.app it’s Alacritty with one huuuuge Tmux session with multiple windows (“tabs”) per each Git repository I’m working on. I haven’t bothered figuring out renaming the tmux windows automatically and just rename them manually - it tends to be a very long running Tmux session that I also save and restore so renaming manually is a one-time thing. It is easy to find whichever repo I want (across 70+ windows) by using CTRL, b, w to bring up Tmux’s window search and then using / to search for the name I want.

Since starting to play about with AI clis, I’ll split the Tmux window so I have a pane for running the cli in and a pane for Helix. But I won’t be running an AI cli in all of these windows which has lead me to wonder, “How do I find where I’m running AI clis?”.

What I’ve done is add a simple wrapper to the AI cli command to set and unset Tmux window titles on launch and quit of the AI cli:

function ai {
	# Let me know where I'm running an AI cli session
	
	# Find tmux window this command was called from
	# This way can target window. 
	# And avoid racey style stuff where wrong "current window" gets renamed
	twin=$(tmux list-panes -a | grep "$TMUX_PANE " | cut -d : -f 2 | cut -d . -f 1)
	twse=$(tmux list-panes -a | grep "$TMUX_PANE " | cut -d : -f 1)
	# I don't think I'd ever use an asterisk as a window name, but this would fallover if I did
	twnm=$(tmux list-windows -a | grep "$twse:$twin:" | cut -d : -f 3 | cut -d ' ' -f 2 | cut -d '*' -f 1)
	tmux rename-window -t $twin "$twnm + ai"
	/path/to/ai/cli
	tmux rename-window -t $twin $twnm
}

And now I can easily search through my Tmux windows.

• Tags:
  • program

NetBSD themselves have a no AI policy (fair; at some point lawyers are going to make a mint), but I just wanted to have a play about and since I run NetBSD, perhaps for too long, I just assumed I was out of luck with most AI tooling (most things do just target macOS, Windows and Linux). But it turns out things are mostly ok thanks to all the CLI tooling being node/npm:

• Gemini just works* (and requires nothing more than a Google account; Which I have again since switching to Android)
• Codex throws an unsupported platform (I wonder if this could be worked around?)
• Claude runs (but there is no free tier)
• Qwen code works (requires a free account; Looks like a Gemini clone)

(Don’t use global installs)

I started with Gemini - I thought I’d jump in the deep end and ask it to do something useful and something fairly complex so I asked it to build me a Chrome Cast receiver in python - I’d love to be able to cast from my Pixel to my NetBSD laptop. It “worked” in that it built something that looked sensible and did run although didn’t actually work when it came to being a Chrome Cast receiver. So then I thought I’d step back a bit and ask it to migrate simplenote.py (long neglected by me) from Travis to Github Actions; Because this is the kind of thing I’ve been meaning to do for a few years and just haven’t found the time for; I.e. this seems like the kind of “chore” task we should be using AI for instead of all the terrible things we are using AI for.

Comparing Gemini with Qwen

For both I gave a prompt like this (apart from the branch name being different):

Create a branch of this repository called gemini-github-actions and migrate the Travis CI setup to Github Actions

And then also gave both permissions for whatever it asked for for the session.

Both gave me additional instructions. Gemini:

To verify the migration, you should push this branch and ensure the GitHub Actions runner can successfully execute the tests and build the package. If you want to proceed with a commit, please let me know.

Qwen:

Next steps:

1. Add PyPI credentials to GitHub repository secrets (PYPI_USERNAME and PYPI_PASSWORD)
2. The deploy job triggers on release publication (modern approach vs. Travis’s tag-based deployment)

Personally I find it dumb that neither of them committed automatically (why would I be telling you to create a branch?) so I told both:

Please commit your changes including the summary of the changes you’ve just provided in the commit message.

Qwen had just created the .github/workflows/ci.yml file whereas Gemini also removed the .travis.yml and updated the README badges (nice); However, I LOVE that Qwen co-authored the commit by default.

I told Qwen:

Please also delete the .travis.yml and update the README badges to suit Github Actions ​

to get it in the same state.

(Interesting aside… I had to update my PAT to allow creation and updates of workflows before I could push)

Here’s the final results (final at the time of publishing is one commit on the gemini branch and two on the qwen one):

1. Gemini
2. Qwen

There are some subtle differences. Gemini includes many more python versions, Qwen just two, matching exactly what I had for Travis.

Of these two, only the Gemini branch automatically triggered a Github Actions run because it sensibly included its own branch - it failed though on every single job. Don’t actually know why. Github just tells me all the jobs exceeded the maximum execution times whilst waiting for runners.

In an effort to actually publish this post this year I am going to leave the AI efforts there for now - I might continue with both branches and get Gemini and Qwen to make further tweaks or I might continue by hand, but that could take me days, or weeks. Or months. So this will do for now. There’s no conclusions to this post, just observations - literally just me documenting my playing about.

This post has taken me months to write. I’m just too busy. I’ve been wanting to play with AI CLI tooling because up until just the last day or so I’ve not been allowed to use any such tooling at work (believe it or not). At least my tinkering on NetBSD did give me a little bit of a headstart and familiarisation.

* - Worked until this change since that it now gives env: unknown option -- S on NetBSD. Reverting that makes it work again. For me that was these files:

• /home/me/node_modules/.bin/gemini
• /home/me/node_modules/@google/gemini-cli/dist/index.d.ts

• Tags:
  • program

It took me a bit to get up and running after getting the laptop, but did want to point out that I am actually making use of it now:

• I make use of the excellent pdh on my NetBSD server so it means I can somewhat have an unofficial PagerDuty client on my phone (for “reasons” I can’t use the official one). But it bugged me that plain output was broken and that I couldn’t snooze alerts. So I fixed them both; Technically I didn’t need local NetBSD hardware for this since I only run pdh on my server, but just having a portable computer which is mine doesn’t half make it easier to do this.
  • I spent quite a bit of time looking at pre-commit and ruff-pre-commit as part of this. In the end I’ve not pushed anything, but I patched pre-commit locally so it works after I install pysqlite3, but then still ran into issues building ruff-pre-commit on NetBSD and I couldn’t find a work-around even though I could install ruff itself fine.

    diff --git a/pre_commit/store.py b/pre_commit/store.py
    index 1235942..ba2469a 100644
    --- a/pre_commit/store.py
    +++ b/pre_commit/store.py
    @@ -3,7 +3,11 @@ from __future__ import annotations
     import contextlib
     import logging
     import os.path
    -import sqlite3
    +try:
    +    # Primarily for BSDs that don't have built-in
    +    import pysqlite3
    +except ImportError:
    +    import sqlite3
     import tempfile
     from collections.abc import Generator
     from collections.abc import Sequence
  

• One of the first things I did on this machine was build helix. It built fine outside of Pkgsrc, but I wanted to update the Pkgsrc package and having local NetBSD hardware meant I could finally do it. Now I just need someone to merge it.
• Similarly with spotifyd, especially since I’m the supposed maintainer of the Pkgsrc package. That really can only be tested on local hardware.
• And libvips too.
• I had some thoughts about trying to setup my own taskwarrior sync server and put together a Pkgsrc WIP package for taskchampion-sync-server, but I don’t think I’m going to pursue this as using the mobile app requires running CCsync as well which just seems silly. Maybe I’ll re-visit this at some point. Maybe I’ll go back to TeuxDeux.

• Tags:
  • program

If I have time (“ha ha ha ha”; I’m also doing this all via ssh from my phone) I’d like to see about making a Pkgsrc WIP package for this (since it’s quite a change from v2 it makes more sense to stick it in WIP rather than just upgrade the existing Pkgsrc package). On that note, I wonder if it’ll have to be split out into taskchampion and taskwarrior for Pkgsrc? I.e. so the new Rust taskchampion bit is built first and then the C++ taskwarrior bit includes that?

In the meantime I just built outside of Pkgsrc:

1. Needed a small patch to build:

    diff --git a/CMakeLists.txt b/CMakeLists.txt
    index 25ed4d9eb..a644268ac 100644
    --- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -65,7 +65,11 @@ SET (TASK_RCDIR "${TASK_DOCDIR}/rc" CACHE STRING "Installation directory for con
     SET (TASK_BINDIR  bin            CACHE STRING "Installation directory for the binary")
        
     # rust libs require these
    -set (TASK_LIBRARIES dl pthread)
    +if (NETBSD)
    +  set (TASK_LIBRARIES pthread)
    +else ()
    +  set (TASK_LIBRARIES dl pthread)
    +endif ()
        
     check_function_exists (timegm  HAVE_TIMEGM)
     check_function_exists (get_current_dir_name HAVE_GET_CURRENT_DIR_NAME)
   

2. Needed this exporting: CARGO_HTTP_CAINFO=/usr/pkg/share/mozilla-rootcerts/cacert.pem
3. And then a cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON . to keep libuuid linked for the install; I am wondering if libuuid is even needed on NetBSD, probably not, but that can be an exercise for another day.
4. The rest of it is per the INSTALL instructions.

I also updated my patch from ten years ago to fix recurring tasks for DST for v3:

diff --git a/src/recur.cpp b/src/recur.cpp
index d6bb47454..b11480245 100644
--- a/src/recur.cpp
+++ b/src/recur.cpp
@@ -53,6 +53,8 @@
 
 // Add a `time_t` delta to a Datetime, checking for and returning nullopt on integer overflow.
 std::optional<Datetime> checked_add_datetime(Datetime& base, time_t delta) {
+  Datetime recurrence_date;
+
   // Datetime::operator+ takes an integer delta, so check that range
   if (static_cast<time_t>(std::numeric_limits<int>::max()) < delta) {
     return std::nullopt;
@@ -62,6 +64,14 @@ std::optional<Datetime> checked_add_datetime(Datetime& base, time_t delta) {
   if (std::numeric_limits<time_t>::max() - base.toEpoch() < delta) {
     return std::nullopt;
   }
+  // Shift current to midday, to be safe of any DST changes, before calculating future date
+  // Then set back to correct hour
+  // Only do this if delta is a whole number of days
+  if (delta % 86400 == 0) {
+    recurrence_date = (Datetime (base.year(), base.month(), base.day()) + 43200) + delta;
+    return Datetime (recurrence_date.year(), recurrence_date.month(), recurrence_date.day()) + 3600 * base.hour() + 60 * base.minute() + base.second();
+  }
   return base + delta;
 }

It seems there maybe future plans to use timezones in tasks which would finally solve this properly so I guess since my approach is still a little hacky it’s not worth PR’ing (the idea didn’t get any traction in the last ten years anyway).

• Tags:
  • program