mawildoer

It's interesting how it ignores things like headers and footers. LLMs have an edge there in "deciding" whether to include something in the output or not.

It'd be great if your hosted version would also accept a URL to a PDF and give a permalink to the result as well (if you're looking for upgrades)

We have some plans and atopile already supports some configuration regarding those deviations. There's a component selector which can choose resistors, caps, inductors etc... from a database of known components. Currently it's a free-for-all, but naturally we expect to be able to constrain this to a subset of components like "thing we already use at this company". That database means (once equations are also in) we'll be able to capture those requirements and change those output components depending on the scenario.

Lot of good stuff! We're working on some updates to the package manager now that should make a lot of that super tenable to build out.

Not at all! Thanks so much for engaging with us on this level. It's greatly appreciated!

You're not the first person to ask for alternative syntax highlighting! Might be something we need to address soon.

I think an LSP server is what we're really excited about, since it also means we can provide far richer autocomplete and inline docs as we go too.

If we can build the equation solver our hearts are set on, you should be able to account for as many factors as your design requires - albeit with some performance limitations at some point. That is, assuming temperature can be factored into equations in the same manner as any other parameter or attribute

For sure! You've made two super important points; how can I trust it shuffling things under me and how can I justify trusting this thing if it's going in long-lead or production hardware (stuff that's hard to fix)

The first one is super interesting technically because there's a few routes by which engineers can gain trust in something, and in my experience code-generation often isn't the strongest of them. It's often the case that checking an answer is vastly easier than solving the problem in the first place. Our mid-term roadmap includes scripting tests (~pytest + SPICE in CI) and for a complex chip like that, I first expect that those params will tweak those tests, those tests will fail out of spec and the engineer needs to reconfigure it in that application while understanding the datasheet.

The next level is extremely similar, except the solver is selecting configuration component params based on cost-functions and rules, and this same test suite is validating the solution and providing the confidence needed to manufacture a prototype.

The final and important mechanism though is that you have a lockfile that lockdown the configuration of these discretes unless an engineer opens it up - yielding review as we'd have today.

The other half of this though - how can we confidently deploy this to production, is eased with the rigorous workflows software version control tools (github, gitlab) can enforce. If an engineer tweaks these params, you can use the tool to rigorously enforce review from the domain-specific-experts on the team. Currently, it's vastly too easy to slip something through (mostly unwittingly) in design review meetings, and these version control tools go a long way towards fixing that.

Thanks mate!