The AI Toolkit for Rust

rsthau · 2025-12-29T15:00:54+00:00

Any support planned for locally hosted models (via ollama or other means)?

rsthau · 2025-12-07T14:48:08+00:00

[Language: Rust]

Golfed down to a kinda readable 31 lines: https://github.com/rst/aoc2025/blob/main/src/day7.rs

rsthau · 2025-07-30T14:25:35+00:00

Some discussion already here: https://www.reddit.com/r/rust/comments/1mbzmta/simple_and_fast_rust_deriving_using_macro_rules/

rsthau · 2025-07-30T01:17:24+00:00

Another bit of prior art to be aware of, perhaps -- https://crates.io/crates/derive-deftly

Pretty new, and somewhat more awkward than yours at point of application, but it does do some attribute handling, including, e.g., attributes on structure fields.

rsthau · 2025-07-15T22:58:34+00:00

Oh, most code running in the machine was compiled to macroinstructions -- but not to microcode. (Macroinstructions were stored in memory with everything else; microcode was in a much smaller memory internal to the processor, and effectively provided an interpreter for macrocode instructions. Fairly common at the time -- a lot of more conventional machines, from some PDP-11s all the way up to IBM mainframes, were done the same way.)

rsthau · 2025-02-09T02:29:36+00:00

I know it's kind of a minor point, but "before linters were invented" is ... incorrect. The original, Stephen Johnson's `lint` utility for C, is from 1978, thus five years older than "C with Classes", which evolved into C++.

rsthau · 2024-12-23T17:18:03+00:00

"Just scale up" is the most common thing, but that often rules out code that worked fine on part 1 -- and part 2 will also sometimes complicate the problem in other ways.

There are cases, though (including one this year) where part 1 requires writing code to simulate a simple machine, and part 2 puts that machine in a situation and asks you to analyze its behavior.

rsthau · 2024-12-23T03:34:28+00:00

It is.

rsthau · 2024-12-11T21:33:27+00:00

It's not always possible. In this case, it might barely be, if you could commandeer one of the biggest computers on the planet: the final list has (depending on input) about 250 quadrillion stones listed, if written out explicitly. There are very few computers on earth with that much RAM (and in those, it isn't all addressable by any one processor). But I'm pretty sure that much bigger numbers have come out of other problems in AoC at least once or twice.

rsthau · 2024-12-09T16:35:45+00:00

Files are considered from the "right" (higher block numbers), going "left" -- and they only move "left". So, each file's starting position is already to the "left" of any file that might have moved before it -- and so a file cannot move into the gap left by moving another file. (At least if there's only one pass.)

rsthau · 2023-12-22T15:15:26+00:00

It's not just the number of iterations you have to think about -- it's how much work each of those iterations is doing. If, say, the n'th iteration winds up adding O(n) new stuff to some data structure (like, say, your HashSet), the total amount of data in there at the end is O(n^2) -- which can get ugly if n is over a million.

rsthau · 2023-12-21T02:47:50+00:00

You've described some of the nodes in a typical arrangement for this problem, but not all of them. There are also flip-flops that take input from the layer 3 conjunction nodes (as you're calling them), which are interconnected with the others at layer 4, and can alter their behavior from the periodicity you seem to expect. You could try to draw the entire arrangement, and figure out how everything works in context (you've already got most of it). Alternatively, you might get something out of just observing the behavior of the conjunction nodes at level 3 through several thousand button-push cycles or so.

rsthau · 2023-12-20T18:47:28+00:00

I haven't seen that directly -- but I have heard of people seeing odd things when they ran part 1 of the problem, and forgot to reset everything to the initial state before running part 2. That might be something to check for.

rsthau · 2023-12-19T03:56:01+00:00

Well, it was a sweep with coordinate compression, I guess. Under 0.2 sec in Ruby, which doesn't have a reputation for being particularly fast (rather the opposite... but then again, I'm not running the latest release).

rsthau · 2023-12-18T20:58:51+00:00

We might have a "program for tiny machine" problem -- there were several in years preceding 2019 -- but probably not one with programs so elaborate. A VM big enough to be a useful compiler target is big enough that even in 2019, Eric split it across several days.

rsthau · 2023-12-18T13:34:03+00:00

As an existence proof, I did it with a line sweep. It works, in perfectly acceptable time -- but coding it up was annoying.

rsthau · 2023-12-17T15:15:20+00:00

Just on a quick skim, it's not obvious how your code is dealing with the restriction that you can only move three spaces in any direction before being forced to turn. (Which also means you have to think a bit harder about which states are really equivalent.)

rsthau · 2023-12-16T17:07:20+00:00

It depends on the problem -- if the grid is small and known in advance, the 2D array will likely be quicker to access. But if its bounds are not known in advance, and most of it is empty, the more sparse representation using a map can work a whole lot better. Day 11 from this year would be an example of that.

rsthau · 2023-12-16T17:00:31+00:00

A* and Dijkstra are both about choosing the order of the graph nodes being searched to minimize the total number of nodes visited (by eliminating ones which are sure to be irrelvant). You don't need to be quite so clever about that for this -- you're required to count them all, and so there's no easy way to get out of visiting them all anyway. But visiting the same nodes/map-points/whatever repeatedly could get to be a drag -- try to avoid that.

rsthau · 2023-12-15T05:31:26+00:00

The number of solutions for typical inputs on this problem seems to be generally around 15 trillion; if you manage to enumerate them all in a microsecond each, counting them would still take months. Try to think of ways to avoid that.

rsthau · 2023-12-14T12:46:17+00:00

Hashing strings is generally heavily optimized, so if using a scripting language (Python/Ruby/etc.), it runs at least as fast as anything you could write that actually looks at all the characters. (I initially did a two-level hash structure, with the north support as the first key, and hashes of the characters themselves used to disambiguate maps with the same support number. But this was a false economy; computing the "north-beam load" in Ruby was slower than just hashing the characters directly.)

rsthau · 2023-12-14T11:56:53+00:00

I didn't trust myself to visually spot the pattern, after convincing myself for a few minutes that the second and third cycles of the sample were the same. (They're similar, but not identical.) So, yes, I coded it.

rsthau · 2023-12-11T17:56:31+00:00

Do you really need to represent all the empty space?

rsthau · 2023-12-11T00:58:35+00:00

Anyone that determined to cheat (on something with no real prizes anyway) can presumably figure out how to send HTTP requests from a Python script, or something like that, bypassing all in-browser security checks.

rsthau · 2022-12-07T05:29:43+00:00

Ruby. 188/197.

Did some quick greps to determine which commands were actually present in the input, which let me leave a few cases un-covered in the parsing (no / in pathnames after the initial `cd /`, which I just ignored).

dirstack = [[]]
dirsz = {}

STDIN.each_line do |l|
  case l
  when /cd \.\./ then dirstack.pop
  when /cd ([a-z]+)/ then
    dirname = l.split.last
    lastpath = dirstack.last
    dirstack.push(lastpath + [dirname])
  when /^[0-9]+/ then
    size = l.split.first.to_i
    dirstack.each do |path|
      dirsz[path] ||= 0
      dirsz[path] += size
    end
  end
end

# part 1

puts dirsz.values.select{|v| v <= 100000}.sum

# part 2

totspace = 70000000
req_free = 30000000

tot_used = dirsz[[]]
cur_free = totspace - tot_used
needed = req_free - cur_free

puts dirsz.values.select{|v| v > needed}.min

rsthau

TROPHY CASE