query.live first thoughts","summary":"Initial thoughts on one of the new remote function APIs in Svelte Kit 3/Svelte 6","content_html":"With Svelte Kit 3 entering Release Candidate a couple of weeks ago, it seemed like a good time to finally start exploring the Remote Functions support that the Svelte team have been previewing since last year. I’ve got a hobby project in mind that I’d like to use it for, a dice roller for the Burning Wheel RPG, and query.live looks like a good place to start. Until now doing something like this with Svelte has been a bit of a pain in the ass as there was no first class support for WebSockets or Server-Sent Events.
A dice roller is really just a broadcast chat app that happens to do some random number stuff on the server, so a minimal in-memory chat program is a good place to start.
\nHere’s the core of this prototype lives in one file, chat.remote.ts:
import * as v from 'valibot';\n\nimport { query, command } from '$app/server';\nimport { PubSubHub } from '../lib/pubsubhub.ts';\n\nconst history:string[] = [];\nconst room = new PubSubHub<string[]>();\n\nexport const addChat = command(v.string(), (text: string) => { \n history.push(text);\n room.publish(history);\n});\n\nexport const getChats = query.live(room.subscribe.bind(room));Probably the most notable thing is the presence of PubSubHub (code below). I immediately ran into an issue where the new query.live consumes a Async Generator function. The example in the documentation, getTime, makes this appear very simple: the only source of events is setTimeout so it’s trivial to setup. Of course, in a real application you probably want the remote function to update in response to some external events, such as the user posting a chat message.
If you’ve ever looked at async generators before, you’ll know that this pretty quickly becomes a bunch of bookkeepping to manage a cavalcade of Promises. These Promise objects are subverted for use as signalling rather than as delayed values, resulting in the resolve functions being exfiltrated as one time event triggers. Because a Promise only delivers at most once, you need to keep creating new Promises after each yield.
To that end, I create this minimal publish subscribe object that returns an AsyncGenerator when you subscribe.
pubsubhub.ts:
interface SubscriberHandle<T> {\n handle: (msg:T) => void;\n}\n\n/**\n * A Publish Subscribe hub that is consumed via async generators.\n * \n * Subscribe uses an async generator because that’s what Svelte’s \n * `query.live` consumes.\n * \n * ```typescript\n * const hub = new PubSubHub<string>();\n * \n * for await (const message of hub.subscribe()) {\n * // Process message\n * } \n * \n * …\n * \n * function onSend(text:string) {\n * hub.publish(text);\n * }\n * ```\n */\nexport class PubSubHub<T> {\n private subscribers: Set<SubscriberHandle<T>> = new Set();\n\n publish(msg:T) {\n for (const sub of this.subscribers) {\n sub.handle(msg);\n }\n }\n\n async * subscribe(): AsyncGenerator<T> {\n // To set up the generator's body, we need an object (the subscriber)\n // to be registered with the `subscribers` set, that can hold the \n // resolve functions generated by the `signal` sentinel Promises.\n const subscriber:SubscriberHandle<T> = {handle:() => {}};\n this.subscribers.add(subscriber);\n\n try {\n // Callers can break out of the loop by calling `return()` on the\n // resulting generator, cleanly exiting.\n // https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Generator/return\n while (true) {\n const signal = new Promise<T>((resolve) => void (subscriber.handle = resolve));\n yield await signal;\n } \n }\n finally {\n // if the caller calls `return()` on the generator we need to \n // remove the subscriber so that they no longer receive messages.\n this.subscribers.delete(subscriber);\n }\n }\n}Note that you need to call bind on the subscribe method if you want to pass it as-is to query.live, otherwise it will become detached from the PubSubHub and not be able to find the list of subscribers.
In a real application you’ll probably want something else, connected to an external service such as a message bus, Postgres’s LISTEN / NOTIFY, etc. But the basic pattern of converting events in a generator stream remains.
query.command is trivial to use. I probably should have used a query.form, but for this toy example it was easier to just skip that for now. That interface seems solid, and query.form is an obvious expansion on the concept.
query.live consuming an async generator I’m less sure on. It works, but the busywork associated with setting it up feels more onerous than I would have liked. Not having an obviously documented example of it interacting with svelte’s observable values or stores seems like an oversight.
Likewise, the lack of an equivalent of PubSubHub, or other utilities for adapting external data to a generater, in the core library is puzzling. It’s still a release candidate so maybe that is still to come. The store API is very close but doesn’t, as best as I can tell, expose an async generator. Something that can consume any observable svelte object, or a store, and produce an async stream seems like an obvious addition.
From the consumer side, having the query.live function (getChats in my example) produce a single value that changes over time, and not a sequence is a little surprising. Not a deal breaker, but I dislike the asymmetry between producer and consumer; it means that – as in this example – the client or server has to do extra work to keep track of the history if that is required. I opted to do it on the server for convenience in the example, even though it’s wasteful. Again, some standard convenience functions in the library would resolve this.
Minor misgivings aside, this is new set of features is promising. Hopefully it will get a finalised release in the not too distant future.
\n","url":"https://brehaut.net/blog/2026/sveltekit_query_live","date_published":"2026-08-23T00:00:00Z"},{"id":"https://brehaut.net/blog/2026/jj_user_aliases","title":"User Aliases injj logs","summary":"jj config for using short aliases for users in log lines","content_html":"Here’s a quick bit of jj config that streamlines the log lines. I use this for my immediate team, and for dependabot, to make my logs more glancable, while leaving commits from irregular contributors louder:
[template-aliases]\n'user_alias(signature)' = '''config('user-aliases.\"' ++ signature.email() ++ '\"')'''\n'format_short_signature(signature)' = '''label(\n 'author', \n if (signature.email() == config('user.email').as_string(),\n config('user-aliases.me').as_string(),\n if (user_alias(signature), \n user_alias(signature).as_string(), \n signature\n )\n )\n)\n'''\n\n[user-aliases]\n\"me\" = \"⏺ Andrew\"\n'foo.bar@example.invalid' = 'Foo'\n'…dependabot[bot]@users.noreply.github.com' = '🤖 dependabot'This overrides format_short_signature which is used by the default log line template. Better factoring of the templates is left as an exercise for the reader.
The me alias is a special case that uses the already configured user.email config setting. This also means that we could commit a repo level config file with common aliases if we wanted to, and my own commits would still be annotated with the bullet.
I’m still dipping into logic programming intermittently. I’m still a tourist. Today I had reason to want to rotate a list – that is, take some number of items from the front, and append them to the back – and I couldn’t find a suitable predicate in the standard libray. My initial attempts to write the predicate myself were bad (leaning on functional and procedural definitions), and in googling I could only find other unsatisfying solutions.
\nlist_rotation_list(List, N, Rot) :-\n length(Front, N),\n append(Front, Back, List),\n append(Back, Front, Rot).Here, length is used to generate a “dynamic” pattern for pattern matching unification against the front of the list: it’s just a list of free variables of a specific length to pattern match the front of the input list. Then the relational behaviour of append unifies the actual values into Front and the remainder into Back, finally just running append again with the order flipped to generate Rot.
One of my friends described Prolog as a “puzzle box language”, and I think thats a great description; there’s something satisfacting in describing a predicate in a way that declaritively expresses the problem. Initially I didn’t think to use length, and wrote a bespoke – and terrible – predicate called free_list_ that did the job badly. This sort of turned-around way of thinking about problems is what I find makes Prolog so satisfying, and mind boggling, to learn and use.
As a tourist into the world of logic programming, I was interested in reading Hillel Wayne talk about Picat, a new (relatively speaking) logical programming language derived from Prolog, but with affordances for functional and imperative programming1. Of particular note, Picat predicates default to deterministic and you have to explicitly opt into nondetermnism, which is a big change from Prolog, which – as a Prolog beginner – is maybe the thing I find most difficult about writing real programs.
\nI’ve been looking for something to trial Picat with, and this week I gave it a crack on some Advent of Code puzzles (more about that in a separate post maybe). This experiment resulted in around 400 lines of Picat code (including whitespace and some comments), covering some basic IO processing, algorithms, and building my own little test runner over about 5 days. I have not yet experimented in any real way with the planner or constraint programming libraries.
\nPicat is clearly a research language. For one thing Github doesn’t have syntax highlighting for it (and there are many hundreds of syntaxes supported there). There is a basic VSCode mode that I suspect is a fork(?) of the Prolog mode: it exhibits the same extremely frustrating bug that occasionaly causes random lines of code from elsewhere in the file to be randomly inserted instead of what you typed when some syntax errors occur.
\nThere are very little in the way of developer ergonomics. Error messages report almost zero context, no line numbers, or stack traces. There’s a basic built in debugger but I leaned on println debugging more. There is a basic REPL, although it doesn’t have the readline style ergonomics you might be used to.
The documentation is comprehensive but terse, and I hope you area okay with Times New Roman for everything (everything even inline syntax). Good news, because the language is fundamentally ungoogleable2.
\nPicat encourages using a functional via it’s API design, and language features. It’s functional programming heavily flavoured by the Prolog origins, so powerful pattern matching and logical variables everywhere. This certainly got me productive quickly: I was writing productive code almost immediately. But it comes at a cost: Picat is not a great functional language, the syntax is, somewhat necessarily, clumsier than an ML or a lisp, or even a modern braces language like Javascript. And the inclusion of functions means that structures are just a little clumsier to work with in Picat than in Prolog: it’s not much but that friction adds up.
\nSimilarly, the imperative facilities are useful (it certainly simplified the IO code I needed to write for Advent of Code), but an expressive imperative language this is not. It reminds me of basic in the 90s. Speaking of which, the IO library exists but is very bare bones.
\nA consequence of these feature’s is that I found myself writing more functional code than logical code, which was a disappointment. I didn’t really feel like I was getting the advantage of using the language.
\nAs mentioned at the top, I ended up writing a minimal test case runner that would allow you to provide a predicate goal (predicates only, no functions), the name of the variable under test, and the expected value, and it would list successes, failures (predicates with no solutions), and incorrect results. Why did I do this? Because I couldn’t find a testing library in the standard library or elsewhere online.
\nThis was a fun challenge. Prolog, and Picat as a result, have an interesting approach to metaprogramming that feels a bit like lisp macros on rocket fuel. I ended up learning how to make a function that would walk a structure replacing occurances of the named variable under test with a fresh variable, and the executing that goal with the call predicate.
Of course the very first Advent of Code puzzle I tried this on ended up using bigints which immediately blew up the test running (I suspect somewhere deep in the structure rewriting code). Oh well.
\nI’m not ready to say that I’m finished experienting with this language. But in the 5 days I spent with it, I certainly experienced enough friction to need a break, and ultimately I think Prolog is still probably more interesting to me at this point.
\nMy next logic programming excursion is probably returning to Prolog. SWI Prolog recently released version 10, with improved support for their WASM runtime to let you run it in the browser. I believe Scryer Prolog also has a WASM build. Perhaps I’ll make a Svelte app that wraps up SWI Prolog; I’ve wanted to deploy logical programs for some RPG programs in the browser in the past (Manticore started life as a miniKanren program in Clojure that was rewritten into Typescript).
\nvite-node","summary":"Maybe the easiest way to run a TypeScript program with Node.js","content_html":"While building the Burning Wheel index on this site, I’ve written a small command line tool to manage the index database. This tool shares some code with the site proper. As anyone who has ever used Typescript directly will know, managing different tsconfig.json files, and the various targets, modules, output files, etc can quickly become an absolute quagmire. I wasn’t surprised to have trouble getting it to build.
It turns out that for projects using Vite (such as with Astro or Svelte) the vite-node package lets you trivially run any TypeScript file in your project as a script, using the existing configuration. Honestly, it’s a bit like magic.