biot

This is the LLM equivalent of a riddle, eg: “A farmer has 17 sheep. All but 9 die. How many are left?”

Depending on how you define 3D printing: braille.

The article says:

> The full menagerie of shapes is too diverse to get a handle on, so mathematicians tend to focus on convex polyhedra

The phrase "tend to focus on" suggests it's not an exclusive thing. However, you're right -- it appears that the Rupert property only applies to convex polyhedra, so the article title and text is at the very least incomplete given that a sphere is a shape.

Presumably a simple sphere would trivially qualify as being unable to pass through itself.

If you buffer starting with the ( character, then you'd still send the [text] part of the link, and worst case is that with no matching ) character to close the link, you end up buffering the remainder of the response. Even still, the last step is "flush any buffered text to the client", so the remainder of the response will be transmitted eventually in a single chunk.

There are some easy wins that could improve this further: line endings within links are generally not valid markdown, so if the code ever sees \n then just flush buffered text to the client and reset the state to TEXT.

There are a few things in our implementation that make a more general solution unnecessary. We only need the output to support a limited set of markdown which is typically text, bullet points, and links. So we don't need code blocks (yet).

However, the second thing (not mentioned in the post) is that we are not rendering the markdown to HTML on the server, so []() markdown is sent to the client as []() markdown, not converted into <a href=...>. So even if a []() type link exists in a code block, that text will still be sent to the client as []() text, only sent in a single chunk and perhaps with the link URL replaced. The client has its own library to render the markdown to HTML in React.

Also, the answers are typically short so even if OpenAI outputs some malformed markdown links, worst case is that we end up buffering more than we need to and the user experiences a pause after which the entire response is visible at once (the last step is to flush any buffered text to the client).

This has long been my favorite entry! Still on my todo list to go through and fully understand it.

Maybe as an eventually consistent life form using extremely slow message passing. Though gravity becomes a major factor that would limit the size unless it’s incredibly sparse.

One of my favorite episodes of Love, Death, & Robots is “Swarm”. Worth a watch.

While the search offered is handy, I watch logs on multi-pod workloads via:

    kubectl logs -f -l app=api --max-log-requests=50

This follows along all pods with the given label (app: api) for up to 50 pods or however many you want. Quite useful when I'm looking for specific output such as ERROR logs to just pipe it to grep like this:

    kubectl logs -f -l app=api --max-log-requests=50 | grep ERROR

and get realtime filtering of all log output without having to tail individual pods by name.

The revenue milestones appears to show annual revenue goals rather than monthly. For example, if you have only 1 plan at $1/month, the $1000/month target shows you need 84 subscribers.

Fun fact: it's a different device, but the principle is the same as the device used in the documentary Tim's Vermeer. It results in the images overlapping between your left and right eye and you simply paint until the difference goes away.