mkeeter

> Can anyone explain where this blob of "assembly language" comes from?

Assembly language is definitely the right analogy: it's a low-level target generated by higher-level tools. In this case, the expression came from a Python script calling this text(...) function:

https://github.com/mkeeter/antimony/blob/f6a56dd7/py/fab/sha...

The font is hand-built from geometric primitives (rectangles, circles, etc) and CSG operations (union, intersection, difference)

> What is considered an acceptable preprocessing or transformation?

I'm looking for interesting ideas, and to mine the depths of PLs / compiler / interpreter / runtime research. Just returning a fixed image isn't particularly interesting, but (for example) I just updated the site with a compile-to-CUDA example that shows off the brute force power of a modern GPU.

Quoth the article: "Obviously, you could precompute the entire image, but that's against the spirit of the challenge"

> By default mlua uses pkg-config tool to find lua includes and libraries for the chosen Lua version. In most cases it works as desired, although sometimes could be more preferable to use a custom lua library.

The fact that Rhai builds with just 'cargo build' shouldn't be underestimated - a Rust project with all pure-Rust dependencies is much easier to maintain / support / distribute across a wide variety of hosts!

This wouldn't be an issue if I locked my computer in a safe, but the rest of the system is changing underneath me: I may have a new laptop, a new CMake version, a new Qt install location, etc. Having everything managed through Cargo does a great job of isolating me from those kind of changes.

You would probably find "A Unified Differentiable Boolean Operator with Fuzzy Logic" interesting!

https://arxiv.org/abs/2407.10954

They build up CSG trees with differentiable leafs (quadrics) combined with differentiable boolean-ish operations, so you can hill-climb over the entire shape.

Here's a quick list, off the top of my head:

"Ao" was an early codename for libfive, so those are the same thing (at different stages of development).

Fidget is written in Rust, versus C/C++ for libfive. This makes it easier to use as a dependency (in Rust projects) and cross-compile to WebAssembly. Also, I don't have to debug segfaults anymore, except when touching the raw assembly in the JIT.

They both implement a similar set of algorithms (meshing, 2D and 3D rasterization).

Fidget has the potential to be faster due to its JIT, and is faster for 2D / 3D rasterization. (I suspect that the non-JIT interpreter is also faster at rasterization, for architectural reasons)

libfive has more effort put into its meshing algorithms, so it does a better job of handling edge cases (heh). I've heard reports that libfive is faster than Fidget at meshing, but haven't done much investigation.

Fidget is not limited to 2D and 3D functions: it can be used wherever you want to quickly evaluation graphs of math, with arbitrary numbers of inputs and outputs. libfive, on the other hand, is specialized to functions of the form f(x, y, z, *vars) -> v.

Extremely in the weeds: if you know what libfive's "feature"-flavored evaluator is, Fidget doesn't have it.

Hi, this is my project :)

I particularly love this corner of CS because there's something for everyone – data structures and algorithms, low-level performance work, compilers, rendering / computer graphics, UI/UX for design tools, GPGPU programming, and more!

I'll be answering questions in the threads as I see them, but feel free to connect on social media (https://mattkeeter.com/links/) or follow my blog's RSS feed for further updates (https://mattkeeter.com/atom.xml)

Thanks Reza!

Hah, I actually wrote a similar constrain solver that uses Fidget's evaluation + differentiation! This blog post was getting too long, so I'm going to write it up separately, but in the meantime:

demo: https://mattkeeter.com/projects/fidget/constraints

source: https://github.com/mkeeter/fidget/blob/main/demos/constraint...

docs on the solver: https://docs.rs/fidget/latest/fidget/solver/

It does not support STEP export, unfortunately, because STEP files use a completely different underlying representation.

Most STEP files represent shapes as a set of surfaces (e.g. trimmed NURBS). These surfaces have to form a watertight manifold, which can be treated as a solid volume.

To make this actually work, you need a kernel for boundary representations (b-reps), rather than Fidget's functional representations (f-reps). Writing such a kernel is a much harder problem – as one example, the intersection of two NURBS surfaces doesn't always have a closed-form representation! In conversations with someone in the industry, they estimated it would take 6 engineers about a year to write a decent b-rep kernel, if they had done it before.

If you'd like to learn more, I've coincidentally also written a STEP file viewer, which includes a far-from-industrial-strength b-rep kernel: https://www.mattkeeter.com/projects/foxtrot/

You're correct, fixed!

Nope, but many of us (Oxide staff) are big fans of what Bluesky is doing!

One of the Bluesky team members posted about their requirements earlier this month, and why Oxide isn't a great fit for them at the moment:

https://bsky.app/profile/jaz.bsky.social/post/3laha2upw3k2z

For a very deep dive into the subject, this is a great writeup:

How to Optimize a CUDA Matmul Kernel for cuBLAS-like Performance (https://siboehm.com/articles/22/CUDA-MMM)

(It's CUDA-specific, so there may be aspects that can't yet be ported to WGPU)

The second-from-most-recent bug, "Leases cannot span MPU regions", did in fact cause immediate failures in our network switch image!

Cliff wrote this up in a blog post, which also had substantial discussion:

Who killed the network switch? A Hubris Bug Story (2024) - https://news.ycombinator.com/item?id=39813365 - March 2024 (128 comments)

Finding bugs in the Hubris kernel is rare enough that we have a running joke about resetting the “days since last kernel bug” timer.

I decided to make this joke into an actual docs page; because HN has enjoyed posts about Hubris in the past [1], I figured this might be of interest!

Many of the individual bugs are terrifying dives into corner cases of an embedded OS. This one is particularly good reading: https://github.com/oxidecomputer/hubris/issues/1134

[1] https://news.ycombinator.com/item?id=29390751

It’s moderately smart - there’s a PID loop with per-component target temperatures, so it’s trying not to do more work than necessary.

(source: I wrote it, and it’s all published at https://github.com/oxidecomputer/hubris/tree/master/task/the... )

We also worked with the fan vendor to get parts with a lower minimum RPM. The stock fans idle at about 5K RPM, and ours idle at 2K, which is already enough to keep the system cool under light loads.

The article title has since been changed to

"Cockroach Labs shakes up its licensing to force bigger companies to pay"

Very cool, thanks for digging into this!

It's doing the following cast:

    &mut DeviceHandle -> *mut DeviceHandle -> *mut c_void

(with the pointer types being solved for automatically by the compiler)

Thanks for the feedback; I tweaked the brightness and pushed the change.

This is an interesting idea, but gets tricky if someone writes self-modifying code!

There are Uxn instructions which write to RAM; normally, this is used for storing data, but nothing prevents programs from editing their own code as they're running.

Good catch, I've updated the link to select Rust 1.67 specifically!

You’ll be glad to learn that the debugger is named “humility”:

https://github.com/oxidecomputer/humility

thanks, edited!

https://jacobian.org is Jacob Kaplan-Moss's website

https://jacobin.com is a socialist magazine

This blog post is from the former!

Look for the "Nucleo" boards rather than full-fledged eval kits, e.g. https://www.st.com/en/evaluation-tools/nucleo-h743zi.html is $26.

The embedded side is here: https://github.com/oxidecomputer/hubris/blob/master/lib/ring...

And the debugger is here: https://github.com/oxidecomputer/humility/blob/master/cmd/ri...

I also gave a talk at this year's Open Source Firmware Conference that covers a bunch of debug strategies: https://www.osfc.io/2023/talks/unplugging-the-debugger-live-...

(conference videos aren't online yet, but should be posted early next week)

Here's a pretty good summary: "What Happened with HustleGPT?"

https://thehustle.co/04172023-what-happened-with-hustlegpt/

It's been done before!

See the excellent "Oxide at Home" blog post [1], and HN discussion [2]

[1] https://artemis.sh/2022/03/14/propolis-oxide-at-home-pt1.htm... [2] https://news.ycombinator.com/item?id=30671447

I have the same question; this article feels like it was written by ChatGPT, and it's surprising to see something like that on the front page!