I love the vibrant green of spring leaves, and the way they dapple the sunlight.

In Generative Agents: Interactive Simulacra of Human Behavior (April, 2023), the authors discuss the use of the ChatGPT LLM to generate the behaviour of 25 agents that live and work together in a simulated village called Smallville.

The agents wake up, have breakfast, open up their shops, get coffee, organise parties and gossip with each other. Their activities are surprisingly… human:

These generative agents produce believable individual and emergent social behaviors: for example, starting with only a single user-specified notion that one agent wants to throw a Valentine’s Day party, the agents autonomously spread invitations to the party over the next two days, make new acquaintances, ask each other out on dates to the party, and coordinate to show up for the party together at the right time.

What I found most horizon-expanding about this work was the demonstration of the results of using the LLM in a wider setting. Rather than the end result being the text the LLM outputs, instead the social interactions of the agents are the output. The LLM’s text output is instead being used for its encapsulation of behaviour in its language generation, and is fully hidden within the system’s runtime.

The LLM is put to use in a great variety of ways within the system. A fascinating example was the way the researchers structured each agent’s memories and used the LLM to decide which events an agent experiences would be more important to that agent. The LLM’s ratings of interestingness are fed to a wider system, which uses the ratings to decide which memories to use during another use of the LLM: asking it for the actions an agent should take. The system is full of ways prior LLM result texts influence future LLM result texts in ways designed to support this world simulation.

Overall, a very eye-opening exploration of the possibilities within the space.

Now spring has arrived, we’re starting the year’s harvest the from the cut flower bed. That makes it sound like we live in a stately home with a huge garden. We most certainly don’t. We have set aside a small raised bed, around 1m x 2m, for this, and it turns out that you can pack quite a lot into it, if you plan.

I say “we”, but this is 100% my partner’s planning, effort and results. I just get to enjoy her work.

While reading about setting up Neovim, I kept coming across guidance to install the nvim-lspconfig plugin. The gist of the advice was that installing this plugin was essential to using LSP in Neovim. It made it “easier” somehow.

As I wanted to avoid plugins where I could, and I only needed to configure three or four language servers (out of the dozens nvim-lspconfig supports), I wondered what the plugin actually did and whether it was worth pulling into my configuration.

In this post, we’ll look at getting a language server working with an open file without using any Neovim plugins at all. We’ll get to the point where we can open .go files in a Go module, and automatically be able to use LSP functionality like go-to-definition, auto-complete and rename.

Then we’ll look at nvim-lspconfig with fresh eyes, understanding what it’s doing and better able to judge whether it’s worthwhile for my, and your, configuration. Regardless of the conclusion we come to, for me it’s always super-valuable to understand what’s going on under the hood of my tools, and we’ll certainly come out of this article knowing a lot more about Neovim’s LSP API and capabilities than I did before I started writing it 🌟

This site is a static site, pre-built with Hugo and uploaded to GitHub Pages. Static sites do not appear to lend themselves to dynamic functionality, like scheduling posts for later, automatic publication. This is what I believed; I had to be there, at the keyboard, bashing out commands, to upload a new version.

But with a little creativity, it can be done.

A couple of weeks after I started to use GitHub Actions to publish this site, I had three or four posts half-drafted (a result of my goal to post smaller things, less often). I wanted to get them finished, but I thought it’d be good to publish them over time rather than all at once. Idly, I wondered whether Hugo could schedule posts, and thought, “no, of course not, I have to run Hugo”. It was then that it hit me that I’d just got “running Hugo” automated within an Actions workflow. And that Actions must have a way to schedule regular execution of a workflow. A plan for scheduled posts was born.

I’ve been using this setup for a couple of months now to schedule publication. It’s simple and reliable. This post shows how to set this up for any GitHub Pages site that uses Hugo. While this post talks specifics for this setup, I expect the general idea can be made to work with any CI/CD and static site builder.

The outline for this is:

1. Set up a GitHub Pages site to be built using Hugo and published nightly using GitHub Actions.
2. Show how to write a Hugo post for future publishing. It’ll be caught and published during the nightly scheduled build, but not before.

Let’s get started.