trying out the Carmack .plan file…

  prefix │ meaning
  ───────┼──────────────────────
  none   │ working on this today
  *      │ finished today
  +      │ finished later
  !      │ dropped
  ?      │ delegated
  &      │ to be continued later

the first token of each entry is the project name. other people are
abbreviated by a given initial or relevant letter followed by a colon;
expect huge conflicts on the letters A and J.

═ feb 13, 2026 ══════════════════════════════════════════════════════════

  ukoos context switching

R&R day in preparation for the weekend event. Somewhat annoyed about
extension detection for ukoOS; Sstateen solves the problem, but I don’t
get that on the Milk-V Duo S or Jupiter.

═ feb 12, 2026 ══════════════════════════════════════════════════════════

& sylvan OAG demo impl

Spent a week not updating this, oops. I think my life is kinda getting
organized around “before/after big upcoming event.” Hopefully progress
accelerates somewhat next week.

Z is also now getting bootstrapped differently; instead of writing the
bootstrapper in C and requiring a HOSTCC, we now bootstrap from Python
since we already require that the host has Python, and this saves us
from having a bootstrap garbage collector, etc.

I spent some time redoing that to more closely follow AMOP too, since it
makes more sense for syntax objects to be CLOS objects if we have a
“heavy” bootstrap anyway.

═ feb 3, 2026 ══════════════════════════════════════════════════════════

& sylvan write engine data structures
& sylvan OAG demo impl
! ukoos/zc hashtables
& sylvan write interpreter
+ self M: sched lunch

═ feb 2, 2026 ══════════════════════════════════════════════════════════

! ukoos/zc prez
& ukoos review #87
* self C: pasta a la norma

═ feb 1, 2026 ══════════════════════════════════════════════════════════

& ukoos/zc prez

═ jan 31, 2026 ═════════════════════════════════════════════════════════

* ukoos/zc GC

═ jan 30, 2026 ═════════════════════════════════════════════════════════

* self healthcare
* a1 variants table
* ukoos review #87

═ jan 29, 2026 ═════════════════════════════════════════════════════════

* self bread
* a1/rs writeup



This ended up being my veggie cheat day, so no real work got done
because I was cooking all day.



═ jan 28, 2026 ═════════════════════════════════════════════════════════

* uko slides!!



Ugh, I need to consistently get appropriate amounts of sleep. UKO
kickoff went well, and I think I’ve successfully pushed off
non-OS-related UKO responsibilities, though.



═ jan 27, 2026 ═════════════════════════════════════════════════════════

& sylvan add support for unsized objects to gc-arena



Hopefully, all that’s left to do on gc-arena is to add more tests and PR
it. MVP/RFC PR submitted, https://github.com/kyren/gc-arena/pull/136.



═ jan 26, 2026 ═════════════════════════════════════════════════════════

& sylvan add support for unsized objects to gc-arena



Still out of the house and lab a bunch today, but the GC PR is coming
together; I still need a benchmark though.



═ jan 25, 2026 ═════════════════════════════════════════════════════════

& machines/sb0 throw together basic rootfs



I might abandon sb0 for a bit; some of this stuff is really a pain to
put together.



═ jan 24, 2026 ═════════════════════════════════════════════════════════

& machines/sb0 throw together basic rootfs



Personal dayyyyyyyy



═ jan 23, 2026 ═════════════════════════════════════════════════════════

* self make a big pot of minestrone and some bread
* self set up new desk
& machines/sb0 throw together basic rootfs



Dangerously cold out and there’s a general strike on, so I suppose today
should be for making a gallon of soup and relaxing. New desk arrived
just now too, so I think I’ll set that up while the bread rises; once
everything’s done, I’ll probably play with sb0 a bit, and see if I can
get it into a bit better state.



═ jan 22, 2026 ═════════════════════════════════════════════════════════

& sylvan add support for unsized objects to gc-arena
* self better boots



Bleugh. Slow day. Maybe should’ve tried working from the lab, but it was
dangerously cold out… Restocked on nice coffee at home though; hopefully
that’ll lead to 



═ jan 21, 2026 ═════════════════════════════════════════════════════════

& sylvan add support for unsized objects to gc-arena
& self better boots



Urkh, gc-arena patches ended up being a lot of work. Turns out I also
lost a couple commits to the repo ttt was in during all the swapping
disks around in the reinstalls; the only big changes are already in my
head, but I’ve gotta retype it.



═ jan 20, 2026 ═════════════════════════════════════════════════════════

* sylvan make “flat ir”
* sylvan dump bytecode
* blog/projects reverse ss13 game



Eugh, woke up with a splitting headache… probably not a great sign. I
think I’ll try working from the lab today, some time spent walking
outside would probably be good at this point.

Yep, that was a good idea; got a bunch done and caught up with folks.
Enough of the IR is done now for it to make sense to get started on the
Rust side, though the “you should make a game” brainworm is back…

I’m back to fighting gc-arena again, too — since we have static
type-safety, it’d be nice to just have untagged fat pointers to unsized
types everywhere, since we don’t need to dispatch on the tags, and know
we won’t write out of bounds.

However, gc-arena doesn’t really love it when you do that, since they
want the Collect vtable to be statically around.



═ jan 19, 2026 ═════════════════════════════════════════════════════════

* blog section for projects i’d like to do
& blog/projects federated irc
* blog/projects rv2js + rvy + tooling
* self A: sched dinner
& sylvan make “flat ir”
* machines/sb2 move router out of VM
* machines/sb2 router+slaac in pre-fde envt



Even with the pre-computed closure layouts, it’s a bit annoying to try
to generate encoded bytecode in a single pass over the Expr.t trees, so
I’m introducing another IR.

This one is after closure conversion, doesn’t support repr polymorphism,
doesn’t have type information, and can be dumped without depending on
the hashtables the type-checker exports.

Turns out systemd just has everything I need to make sb2 into a router,
so it was _mostly_ easy to do; the annoying part was figuring out what
kernel modules I needed in the initrd, and remembering that
net.ipv4.conf.all.forwarding behaves differently from
net.ipv6.conf.all.forwarding…



═ jan 18, 2026 ═════════════════════════════════════════════════════════

* ukoos write up containers and guards
* self order new coffee



Spent most of the day recovering instead of working, but got a good
chunk of macrology and documentation done for containers and guards.

I’m pretty happy with the guard macros; they seem like a clear and
immediate win for locks, but I need to figure out what I want to do for
refcounts. This’d be so much nicer if I could tie methods to types (to
support a single “free” to be expanded from the macros) but… ah well.

Really, guards are probably the wrong paradigm; I imagine the most
common pattern to need to incref is probably going to be, “acquire a
lock on a data structure, find a resource in it, incref it, then drop
the lock.” 

In this case, we can’t use a guard for the refcount, since that’d force
it to get decreffed before the lock gets released.



═ jan 17, 2026 ═════════════════════════════════════════════════════════

* machines/f12 move to lab
* machines/silo update login
& sylvan dump bytecode
& blog section for projects i’d like to do
& self J: ask about switching brands



Slow day for work… Had to fix a layout bug (lexical variables in
closures wouldn’t get added to their parent function’s closure env too),
but now everything _should_ be good there.



═ jan 16, 2026 ═════════════════════════════════════════════════════════

* machines/f12 reinstall
* flake unify f12
* flake/neovim add C-space prefix for macOS-like unicode keybinds
* sylvan compute variant layouts
* blog redoful ssg



Bleugh, snowing so not going to the lab. And kinda tired before dinner,
so I might work on setting up the blog a bit to handle building content.

Using something like redo (where it’s easy to use completely different
build rules for different files) should make the build system flexible
enough that it won’t be necessary to get rid of it later.

I’m also going to focus on building and preprocessing simple snippets,
then composing them at the end; this also hopefully makes it nicer to
have fine-grained behaviors.



═ jan 15, 2026 ═════════════════════════════════════════════════════════

* flake update shell config
* sylvan compute stack frame layouts
* sylvan compute record/typeclass layouts



I’m splitting up layout calculation from bytecode generation, actually.
I want to cache layouts for types anyway, so it doesn’t feel like a
“waste” of a module, since it looks like another pass. (I suppose it’s
good to identify all these passes too, since they’re good candidates for
nanopasses in the self-hosting compiler.)

Unfortunately, this uncovered that we do technically have some repr
polymorphism going on that the type-checker doesn’t eliminate — record
field access is doing that at the moment.

I think I’ll probably just hard-code that to reduce at codegen-time?
Famous last words, but we don’t allow user-written impls for FieldRepr,
so maybe it’s fine?



═ jan 14, 2026 ═════════════════════════════════════════════════════════

* flake/neovim grab updated configs from sb0
* sylvan attach nodes to IR dicts
& sylvan compute stack frame layouts
& sylvan dump bytecode



Okay, feeling much better-rested today! Turns out that despite dropping
reprs from IR dicts (see 2026-01-11), we still need to attach nodes to
them to be able to store them in NodeHTs during stack frame layout.

I apparently also totally forgot that typeclass dictionaries can have
unboxed fields, so I need to keep around more information to figure out
the offset of each field. I’m considering just storing this information
on the DictProj constructor, to avoid having to touch the Tyck_common
module…

A lot of progress got made on the Sylvan stuff today, but in a
“horizontal” slice instead of a “vertical” one; bytecode dumping is
completely done for a few expressions, and stack frame layout is done
for most of them, but I have to make progress across a few parts
concurrently.



═ jan 13, 2026 ═════════════════════════════════════════════════════════

* flake M: nag about garbage
* flake switch password manager
& flake/neovim grab updated configs from sb0
* self start dough
* self sleep early



Wow, not getting sleep and having construction above me is _really_ bad
for productivity… Got most of the machine setup on sb1 done at least,
but, not much else.



═ jan 12, 2026 ═════════════════════════════════════════════════════════

* machines/sb1 reinstall
* ukoos get remexre/mm merged
* ukoos review rtl8139 draft driver
& ukoos add cleanup-able refcount guards
& ukoos context switching
? ukoos clang(d) support
& ukoos A,A,J,J,K,S?: sched meeting(s?)



Today was the second and last winter-break ukoOS hackathon, so I’ll be
returning to the normal schedule tomorrow. I think I might take the
opportunity to use ukoOS to proof out a longer-term projects’ ideas for
concurrency primitives.

Instead of typical threads, I think I’ll plan to implement:

- Kernel tasks with Erlang-inspired links (task to task) and monitors
  (task to channel).

- “Register to be woken up once an event occurs” and “go to sleep” are
  the primitives for blocking; I don’t know what associated data I want
  to have with each registration; an arbitrary pointer?

- (MPSC) channels for most inter-task communication, including
  communication with drivers; each device (instance of a driver) spawns
  a task, other parts of the kernel communicate with it over channels.
  The receiving end of channel going from empty to non-empty is a
  registerable event.

  There’ll be nice helpers for making “synchronous” calls, of course.

- Because tasks can be killed by a link, we need unwinding-like cleanup;
  I think I’m going to have macros that work like the CAMLlocal() macro.

  Each task has an intrusive linked list on the stack containing
  closures (pairs of function ptr and void ptr) that accept a flag for
  whether they’re getting popped as part of a normal return or not.

  [[gnu::cleanup]] runs cleanups and pops them on normal return, but
  when a task dies, we can traverse the cleanup stack and call every
  non-null closure.

  This should be able to be applied to refcounts (just decref them),
  as well as sleeplocks and spinlocks (which can be poisoned).



The sb1 reinstall went through; as part of the plan to have somewhat
more normal technology, I’m now a GNOMEcel… Adwaita Mono does look
nicer than I expected, though.

The new install is in a new flake for now; it’ll probably become the new
trunk branch of ~remexre/flake, though for latent-CUI-worries reasons
that might move to non-public hosting too…

Once everything’s fairly stable, I think I might try out PaperWM; it
seems like it’d nicely fit my typical workflow. I might have to change
the keybinds to make some things easier to reach, but ah well.



═ jan 11, 2026 ═════════════════════════════════════════════════════════

* sylvan attach reprs to IR binders
* sylvan attach reprs to IR exprs
! sylvan attach reprs to IR dicts
* self clean up desk
& machines/sb1 reinstall
* self piano setup



I was going to attach reprs to dicts for symmetry with expressions,
since dict terms are essentially expressions, except with only two
reprs, boxed and erased. However, this would break zero-cost coercions,
because both reprs would have the same kind (constraint) and that’d
prevent coercing along a

    (fn() -> () where c) = (fn() -> () where Erasable)

under the evidence (c = Erasable), which the user can write with a GADT.

It’d probably be reasonable to do this as part of the worker/wrapper
transform:

- Add a kind and repr for erased constraints.
- Add a constructor/eliminator for a form of the _=_ constraint that
  has the erased kind/repr.
- Make the worker/wrapper transform use that in the interface with the
  worker.
- The constructor just discards its argument.
- The eliminator just translates to a nullptr or singleton.

This can wait until the self-hosting compiler (probably coming in 2027),
though.



Urkh, the sb1 reinstall turned into a headache. Turns out, that machine
won’t boot if certain DisplayPort ports are plugged in at power-on… Most
of the files it needs to pull (datasets and models) are also on sb2,
which… doesn’t have an address that cleanly routes to it, IPv4 or IPv6.

I’m away from that machine past tomorrow morning, so maybe I’ll try to
get enough of an install going that I can do the rest remotely.



═ jan 10, 2026 ═════════════════════════════════════════════════════════

* wpe plan out more, write todo comments
* machines update foundry www hostname
* ukoos K: ask about rtl8139 driver
* self N: ask about sensors
+ sylvan attach reprs to IR exprs



Today continues with the repr refactor; previously, the evaluator was
double-boxing everything; so, a scalar32 value would be 32 bits, but
stored behind a box. As a result, nothing actually had to worry about
reprs enough to notice that they couldn’t be reconstructed from what
_was_ being saved…



The hope with the sensors ask was to get enough biometric sensors to
start doing rough correlations with productivity, and start building
models. I’d like to be able to start getting answers to questions like:

- When should I drink caffeine and how much? On which days should I take
  or skip my meds? Ideally, this’d be backed by a higher-order model
  that takes tasking and tolerance into account.

- How much value would I get from a thermostat? Right now, I get
  occasional sleep disruptions from not having one, but building one
  would probably take 20 FTE hours in labor and parts.

- Should I move the humidifier or adjust the humidistat?

It sounds like the sensor setup N has wouldn’t be as easy to integrate
with my existing stats as I hoped, so I’m shelving the project as having
too high of an opportunity cost.



═ backlog (sorted by project, then toposorted by dependencies) ═════════

  a1/nv port
  blog find right point for syntax highlighting
  blog ssg rss
  blog ssgify .plan
  blog/projects cult game
  blog/projects rpg on grid w/ complex magic system, automation
  blog/projects redo with automatic dependency tracking thru sandboxing
  flake update mail
  flake unify fu1
  flake unify sb2
  flake unify silo
  flake/neovim kitty-like unicode picker
  flake/neovim .plan syntax+folding
  flake unified notifications
  flake grafana tailscale
  machines/fu1 reinstall
  machines move sb1 and f12 backups, fu1 to office
  machines/sb2 push dns
  machines/silo move ircd
  machines/foundry update login
  machines/foundry put old http reqs into loki
  ttt/dram move latest userspace driver to publishable repo
  ttt/dram put kernel into examples/
  ttt/dram write prose describing kernel
  ttt/dram go over host-side code
  ttt/dram publish
  ttt throw together assembler
  self belt
  self catch up on sunspot
  self new running shoes?
  self pasta
  self underware
  self A: figure out nails
  self C: sched dinner
  self J: sched dinner, get parts
  self R: sched lunch
  self Q: ask about tools for keyboard
  sylvan parse bytecode
  sylvan merge new evaluator
  sylvan perf support
  sylvan finalize nag syntax
  sylvan tyck nag
  sylvan ordering for nags
  sylvan ordering datalog exp
  sylvan tyck IR exprs as they’re constructed
  sylvan redo website
  uko review wireshark slides
  ukoos channels
  ukoos spinlocks
  ukoos kernel task links/monitors
  ukoos scheduler
  ukoos hartlocks
  ukoos sleeplocks
  ukoos traps
  ukoos timers
  ukoos concurrent selftests
  ukoos mock uart
  ukoos mock eth phy
  ukoos watch queue talk
  ukoos H: ask about compiler port
  wpe write down langck rules as tyck rules
  wpe describe ordering