I just ask it for what I’m looking for (doing very simple “spare part” level at home 3d printing, nothing fancy or elaborate) and it gives me a starting point. Then I sometimes just edit the scad code by hand, and some times I ask the AI to revise, sometimes a mix (many iterations).
For very simple geometries it works great, but it very quickly becomes apparent that there’s a bit of a disconnect between “LLM views image” and “LLM emits scad that looks like that image” when it comes to anything non-trivial.
Still gives me a starting point I can mess with, which is great since I have zero CAD training or experience.
Tbh that sounds harder than just learning CAD, which is really not that difficult if you use a proper parametric editor - I would recommend SOLIDWORKS first. It's got the easiest UX so is ideal for learning. They actually have a vaguely reasonably priced subscription now, but IMO it's still way too much for occasional hobby use so I'd recommend just pirating it (which is easy).
Once you have learnt a bit then the only FOSS options that are worth a damn are a) SolveSpace which is quite good and light, has a slightly quirky UI (but not in a bad way) but unfortunately has some critical missing features at the moment - notably bevels/chamfers. Although I did see someone made a sloppy PR to add them so we'll see where that goes.
Or b) FreeCAD which is actually good now and fairly close to SOLIDWORKS (at least for the basic stuff you're likely to use) and has a reasonably good UX. Some rough edges still but overall it's very usable. Good enough that I reach for it instead of pirating SOLIDWORKS these days.
The basic workflow is pretty simple:
1. Make some planes, referenced from existing geometry.
2. Make sketches on the planes.
3. Extrude/revolve them (either adding or subtracting from the existing geometry).
4. Repeat until you have the right shape.
5. Add a load of chamfers to make it pretty.
So, steps 1-5 can be done by clicking (tools you recommend), or writing lines of script (OpenSCAD). Once you grok those steps by just doing it yourself, you quickly get to a point where an LLM is quicker at editing the text file that represents the steps to generate the model. Things like "Make the extruded face I labelled blahblah do xyz", and it's quite good. Even better: "Parameterize curve abc and generate this spread" or something. You get it.
For LLM-assisted bespoke model generation it's still fine if you specify a process to follow, and can "speak the language" (knowing 1-5).
This is no different than purevibe vs LLM-assistance, IMHO. What TFA refers to is a more end-to-end, no iterative process, with no single touchpoint script like OpenSCAD offers, so it's very much _not_ a collaboration and requires no knowledge of how CAD models are made.
But this thread is moreso about iterating on an OpenSCAD specification using LLMs.
From my experience people who heavily rely on LLMs are allergic to learning anything new (with the exception of learning new and improved ways to generate slop). They just 'want to get stuff done', even if it means staying in a local maximum forever.
I hope you leave it on the WAF. If they're only just deciding to respect robots.txt, which has been internet infrastructure forever, then it's probably still incredibly amateur software with 'Amazon-priorities' rather than 'responsible internet traffic' priorities.
Yep x402 is for any blockchain rather than just Stripe. I use it: it’s like being able to access a service without having to sign up and get an API key.
How do you use it? I explored building on this as a platform but ditched it because only crypto nerds seem to use it and fiat is used all around anyway.
> MPP provides a specification for agents and services to coordinate payments programmatically, enabling microtransactions, *recurring payments*, and more.
I believe the Shared Payment Token is interchangeable with a payment method id that you attach to a customer object, but that link has very sparse information about how things actually work end to end and what objects mean what.
Are there any nuclear alternatives that don't include strapping low grade bombs to the reactor core (PRW/BWR: water separation -> hydrogen + oxygen -> boom, like happened @ Fukushima) or using coolants that instantly start violently combusting when exposed to air or moisture (sodium)?
I love the promise of nuclear energy, and I understand that every single engineering decision has tradeoffs, but these tradeoffs just seem so bad? Are there really no better options?
There have been some sodium cooled designs that have used a closed cycle gas turbine using nitrogen as the working fluid for the secondary circuit, in order to avoid any issues with sodium-water reactions with a traditional steam Rankine secondary circuit.
There are also fast reactor designs using lead as the coolant rather than sodium. These are interesting, but less mature than sodium cooling. Sodium is better from a cooling and pumping perspective though.
A eutectic is an alloy that has a lower melting point than any of its components.
Lead-bismuth eutectic or LBE is a eutectic alloy of lead (44.5 at%) and bismuth (55.5 at%) used as a coolant in some nuclear reactors, and is a proposed coolant for the lead-cooled fast reactor, part of the Generation IV reactor initiative. It has a melting point of 123.5 °C/254.3 °F (pure lead melts at 327 °C/621 °F, pure bismuth at 271 °C/520 °F) and a boiling point of 1,670 °C/3,038 °F.
Yes, some lead cooled reactor designs have used LBE, others pure lead. Though AFAIU so far the only lead cooled reactors that have actually been built and operated in production have used LBE. There is a pure lead cooled reactor under construction that should be started up in a few years if the current schedule holds.
The improvement is more on the fuel cladding for classic pwr or pebble bed reactors... But even without all this, nuclear is one of the safest sources of power on the planet, because we made it so
Nuclear today isn't that much different from steam engine - the fundamentals make it a technology of the past clearly losing to the today's tech, in this case to the massive solar/wind accompanied by the battery storage.
Nuclear will work in space, as it is the only tech feasible beyond the Mars orbit.
May be, may be the fundamentals will be sufficiently, to make it feasible on Earth, different for thorium MSRs and hopefully for fusion (my favorite is fusion driven thorium reactor - no need for fusion breakeven and relatively safe as turning off the fusion, the source of neutrons, stops thorium fission)
Thorium is inefficient. And its related to steam in that steam converts to heat and power. Differentiates considerably on the front end.
Nuclear solar and wind are all natural complements. This stupid this or that argument only empowers old oil and gas tech looking to hold on to the future.
Steam usage is a wonderful invention. It's certainly not a technology of the past. Nuclear will work anywhere you don't want to have oversized transmission network and where weather conditions aren't stellar, unless ren are combined with another firm source like gas/coal/geothermal/hydro
The AGRs are advanced reactors that use an inert coolant, CO2. In fact they have been designed to cool down quicker than any credible loss of coolant. And have been in service since the 70s, with some slated to go on until 2030.
I mean the LWR fleet has proven to be incredibly safe by any objective measure with deaths per TWhr as good or better than wind/solar. The very incident you mentioned had a direct death count of 0 or 1 depending on who you ask. Industrial shit blows up all the time, you just don't hear about it because it's normal and accepted.
What needs to improve about nuclear is our ability to deliver it on time and on budget. Safety is already more than adequate.
That is never going to happen until we are building more of a consistent design. I think every LWR is use today is a custom bespoke piece of equipment.
Yes, standardizing on a handful of designs will help immensely, as well as building two or more reactors on one site to share the overhead costs between units.
For example, building out more AP-1000s is really a no brainer. The first-of-a-kind is always expensive and the AP-1000 was especially so due to many factors. We bore that cost and now we should reap the benefits of Nth of a kind builds.
The International Atomic Energy Agency (IAEA) maintains a database of advanced reactor designs, ARIS [1]. It lists 119 reactors. A lot of them are small modular reactors, and the IAEA has published a book with details about them [2]. Some of these reactors have applied for NRC approval, and you can find an enormous amount of details at the NRC website [3].
To answer your question: numerous reactor designs are very safe.
Let's start with the most techonogically mature: helium cooled gas reactors. Helium is a noble gas, chemically inert, transparent to neutrons (the only substance in the universe to have zero neutron absorption cross-section), and it has a hard-to-believe high heat capacity by mass. The downside is that helium is somewhat expensive and it can leak. China has been operating 2 such reactors for the last 4 years [4]. In the US, there is a reactor design, Xe-100, that is quite similar to the Chinese design. It is quite difficult to come up with a scenario where something bad can happen with such reactors. The only problem is that they are quite expensive to build and operate, compared to water reactors.
There is one design that is very similar to the design of helium-cooled gas reactors, the only difference is that the coolant is not helium, it is a molten salt. In the US, the company Kairos is pursuing NRC approval for their reactor Hermes. The molten salt has lower heat capacity than helium by mass, but much higher by volume. There is no need for pressurization. The salt used here is a mixture of lithium fluoride and beryllium fluoride (FLiBe). Fluorine is an extraordinarily corrosive substance, but exactly because it is so, the salts that it forms are extremely stable. Still, stable or not, they can't match the inertness of helium, so such molten salt reactors are a bit more challenging when it comes to the contact between the coolant and the reactor vessel. However, they are extremely far from being a "low grade bomb". These reactors are almost as safe as they can be, albeit a bit below the inherent safety of helium cooled reactors.
Hijacob, AxonML author here. Our autograd is ~3K lines of Rust. Here's the actual architecture:
Three core pieces:
1. The GradientFunction trait — every differentiable op implements this:
pub trait GradientFunction: Debug + Send + Sync {
// Given dL/d(output), compute dL/d(each input)
fn apply(&self, grad_output: &Tensor<f32>) -> Vec<Option<Tensor<f32>>>;
// Linked list of parent grad functions (the "tape" edges)
fn next_functions(&self) -> &[Option<GradFn>];
fn name(&self) -> &'static str;
}
GradFn is just an Arc<dyn GradientFunction> wrapper — cheap to clone, identity via Arc pointer address.
2. Forward pass builds the graph implicitly. Every op creates a backward node with saved tensors + links to its
inputs' grad functions:
// Multiplication: d/dx(x*y) = y, d/dy(x*y) = x
pub struct MulBackward {
next_fns: Vec<Option<GradFn>>, // parent grad functions
saved_lhs: Tensor<f32>, // saved for backward
saved_rhs: Tensor<f32>,
}
impl GradientFunction for MulBackward {
fn apply(&self, grad_output: &Tensor<f32>) -> Vec<Option<Tensor<f32>>> {
let grad_lhs = grad_output.mul(&self.saved_rhs).unwrap();
let grad_rhs = grad_output.mul(&self.saved_lhs).unwrap();
vec![Some(grad_lhs), Some(grad_rhs)]
}
fn next_functions(&self) -> &[Option<GradFn>] { &self.next_fns }
}
The Variable wrapper connects it:
pub fn mul_var(&self, other: &Variable) -> Variable {
let result = self.data() * other.data();
let grad_fn = GradFn::new(MulBackward::new(
self.grad_fn.clone(), // link to lhs's grad_fn
other.grad_fn.clone(), // link to rhs's grad_fn
self.data(), other.data(), // save for backward
));
Variable::from_operation(result, grad_fn, true)
}
3. Backward pass = DFS topological sort, then reverse walk. This is the whole engine:
pub fn backward(output: &Variable, grad_output: &Tensor<f32>) {
let grad_fn = output.grad_fn().unwrap();
// Topological sort via post-order DFS
let mut topo_order = Vec::new();
let mut visited = HashSet::new();
build_topo_order(&grad_fn, &mut topo_order, &mut visited);
// Walk in reverse, accumulate gradients
let mut grads: HashMap<GradFnId, Tensor<f32>> = HashMap::new();
grads.insert(grad_fn.id(), grad_output.clone());
for node in topo_order.iter().rev() {
let grad = grads.get(&node.id()).unwrap();
let input_grads = node.apply(&grad); // chain rule
for (i, next_fn) in node.next_functions().iter().enumerate() {
if let Some(next) = next_fn {
if let Some(ig) = &input_grads[i] {
grads.entry(next.id())
.and_modify(|g| *g = g.add(ig).unwrap()) // accumulate
.or_insert(ig.clone());
}
}
}
}
}
Leaf variables use AccumulateGrad — a special GradientFunction that writes the gradient into the Variable's shared
Arc<RwLock<Option<Tensor>>> instead of propagating further. That's how x.grad() works after backward.
Key Rust-specific decisions:
- Thread-local graph (thread_local! + HashMap<NodeId, GraphNode>) — no global lock contention, each thread gets its
own tape
- Arc<dyn GradientFunction> for the linked-list edges — trait objects give polymorphism, Arc gives cheap cloning and
stable identity (pointer address = node ID)
- parking_lot::RwLock over std::sync — faster uncontended reads for the gradient accumulators
- Graph cleared after backward (like PyTorch's retain_graph=False) — we learned this the hard way when GRU training
with 120 timesteps leaked ~53GB via accumulated graph nodes
The "tape" isn't really a flat tape — it's a DAG of GradFn nodes linked via next_functions(). The topological sort
flattens it into an execution order at backward time. This is the same design as PyTorch's C++ autograd engine, just
in Rust with ownership semantics doing a lot of the memory safety work for free.
Sure, but each request has its own context. Shared resources like DB connection pools will be longer lived but by definition they aren’t alllcated by the request thread. So why not simply exempt everything allocated by a request thread from GC, and simply destroy it on request completion?
Generational GC assumes that short lived objects tend to come in groups, which is probably the best you can do in an OO language with shared everything.
His question is still valid for latency. That parallel GC in Java still seems to pause threads from a quick search. https://inside.java/2022/08/01/sip062/
Don't the models typically train on their input too? I.e. submitting the question also carries a risk/chance of it getting picked up?
I guess they get such a large input of queries that they can only realistically check and therefore use a small fraction? Though maybe they've come up with some clever trick to make use of it anyway?
Yeah, probably asking on LMArena makes this an invalid benchmark going forward, especially since I think Google is particular active in testing models on LMArena (as evidenced by the fact that I got their preview for this question).
I'll need to find a new one, or actually put together a set of questions to use instead of just a single benchmark.
(That can of course change very quickly, yes)
reply