mawildoer

I wanted to setup a slackbot to manager Doordash orders for our company.

Starting with PyPi "Doordash Client": https://pypi.org/search/?q=doordash+client I was excited by 5 recently published packages. As I usually do, I checked them out via Github... buut, hit a deadlink

Quick inspection of the package clearly shows a random server handles all the requests made including your PII, address, credit card info -- 99% chance this is malware.

World's moving fast these days, and AI is making it easier for everyone - even the bad actors - to make what looks like polish OSS.

My typical workflow selecting packages is:

1. Check out their Github - social credit means a lot to me

2. Clone the repo, and ask `claude`, `cursor` or whichever agent I'm using at the time for a quick audit

3. If I'm putting my own credentials of a PAT in there, review it myself at the top level too

Stay safe folks!

I thought it was a big upgrade. Comparing Zerox w/ Unstructured on the first 5 pages of [this datasheet](https://www.ti.com/lit/ds/symlink/lm5117.pdf); zerox gave me what I wanted, and Unstructured gave me a bunch of extra junk that was harder to sort through at the top

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.

You're right about "code" not being the right solution for everything. In the case of the layout we have indeed already already implemented an MVP of the "snippets" approach you described: https://atopile.io/blog/2024/02/02/-layout-reuse-keeps-getti...

A big part of the code is that creating a wizard for each issue it a tall order to develop, but through expressive and composable language we should be able to articulate the parameters for the configuration just as as clearly and generically solve that class of problems.

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.

We hear you! We're most certainly planning on eating up the system's chain to describe, version control and validate up the system's chain.

As one example in an earlier (and likely future) permutation of atopile we could compile harnesses (using the fantastic https://github.com/wireviz/WireViz) by linking two interfaces on connectors.

Long future, if you can integrate mechanically too, you can at least check if not generate the harnesses lengths, bend radii, drip looks etc... for that same harness.

Somewhat like software, you can only tractably do that at scale if the units work and work reliably. Unit tests are the basis of software validation and we expect hardware validation as well. We're starting low-level we know, but with a concepts we know (from the insane scale of big software projects) can work on enormous projects too.

Thanks mate!

You're right. It definitely is currently.

This is a hole we're planning to fill between linters and a language server. Picture a red-underline under an instance which is insufficiently configured, for example

Thank you!! That's just about the workflow as where we lie today - albeit without the full suite of potency we're working towards.

I haven't actually used Onshape, so I'm not intimately familiar with their constraints system. Thank you for the recommendation, I'll have to check it out for some hints.

We're largely on board with the same problem's we're trying to tackle, and I most certainly understand why you're making these criticisms of these trivial examples and our current implementation. You're right to - these simple designs aren't where designing PCBAs with code will shine (we expect!).

Currently when you discuss configuring a regulator, it's beholden upon the designer to understand enough of the internals to configure it because, in our opinion, schematics aren't well suited to designing things that are configurable and plastic - either in topological terms, or in their parameters. Our hope isn't to abstract this complexity directly by using code, but rather because code allows the workflow itself to change, for a well tested and trusted configurable block to completely abstract the internals such that a designer can forget about it (like a tested piece of code). We want to bring configurability on this "trusted" scale in from the physical world of modules to the world of highly descriptive code. It's a tall order, I'll indeed admit!

It's also well worth nothing that while at the moment we're running lean on the visualisations, we do agree they're an extremely potent tool to convey the topology of a design at a glance. We expect we'll be adding a visualiser which should be used to gain familiarity with a circuit, diff it for review and understand it from a system level (by viewing topology by interface type etc...) - unlike current schematics that implicitly hold so much content via the positioning of components.

Thanks for the detailed comment!

Sorry, not quite sure what you’re asking. Mind rephrasing?

Super! So far that’s all we support for layout and we love that it’s also super-low-barrier to entry OSS.

You're absolutely right! We've been thinking very similar ways about "dipole" components and how to best do this; and I think you've nailed it. What about using dunder __in__ and __out__ attributes? Easy enough to implement for us and overload for folks in the future.

Definitely agree this isn't taking away EEs - anytime soon or ideally ever! The goal is to make EEs far more potent, rather than bring SWEs to hardware (although letting them easily tweak existing board's filter constants, vdivs etc... would be awesome too!)

We're honestly not sure how explicitly we want to describe a layout in code, or if it's a more declarative thing. Currently we're leaning more towards the declarative approach (eg. this trace carries 100mA of current) rather than the imperative (this trace is 0.150mm wide) since it should scale more intuitively with equations and layer better with DFM specs etc...

Have you got some ideas?

We share similar thoughts about the core of the auto-routing/placement/simulation issues being UX! We're a bit more bullish on code being able to fix that as well.

Noticing that these tools are infrequently even configured because it's simply too much of a pain to do so for every new design - we're hoping the expressive, reuse-focussed code-based-approach means people need to capture these things once and then everyone gets to reuse them.

This is all a while away, but after we're able to get design currently captured in schematics working smoothly we certainly plan to tackle auto-routing/layout as well

Great question! We hope we have a few good reasons.

This iteration of the project actually came after first working with and then modifying another awesome project called SKiDL (https://github.com/devbisme/skidl).

It's based on Python - but we found that since it's procedural, turing complete and has a rich eco-system - people use to that and there aren't standard composable ways of designing things. Instead of describing your board, you (practically) write a script that generates your board. It entangles your targets with your source-code and can make it difficult to understand the ultimate outcome of what you've written.

Additionally, since it's a potentially very long program, it was hard to write good language support around (a language server for VSCode, a schematic visualiser etc...) that were snappy, responsive and lent to examining modules as well as the whole program.

There's a few operators and first-class language features we wanted as well, like units and tolerances (3.3V +/- 100mV) that just aren't the same when embedded in a string, or class init method.

We're also super stoked about getting topology and equations together in the same file (and even code-base!)

The equation solver is soon on our roadmap: https://atopile.io/roadmap/#language-features

Not even quite synthesis yet! We're well aware there's quite a lot out there that's fairly analogous - but nothing that's quite translated to the space, despite a few efforts as pointed out above.

There's a few parts we think that are behind that, but one is similar to python's/Guido's "code is read more than it's written", so we're attempting to address that!

That's awesome! We're definitely thinking along the same lines in terms of a lot of those optimisations / cost-functions.

Here's some of the basics Tim was playing with earlier: https://github.com/atopile/atopile/blob/d25686952534e0f96582...

Interesting! Haven't come across it before but those linked `~>` operators do indeed quite familiar. If you're familiar with GraphDSL do you have some elements we should look into?

Absolutely love to hear that!

100% agreed about the ecosystem too. We've already created a perhaps-too-scrappy package manager, but it works! https://packages.atopile.io/ We're pretty convinced that the awesomeness of the software ecosystem is a function of its openness and open-source and atopile largely came from working out how we could seed a similar shift in the hardware world. I can't wait for the day I can `ato install` SMPS, filters, radios and servo-drives with the confidence they'll just work!

Great question! Current HDLs tend to primarily be focussed on digital circuit design, while at the PCBA level, there's a lot more focus on the "fuzziness" of the physical world (eg. tolerances).

We also noticed that most EEs we've worked with were a bit put off by the syntax and preferred something a bit more terse, but more intuitive and easier to read.

There perhaps an analog here in software - where we started with assembly (~ SPICE), moved up through things like C and now languages like Python and JavaScript are prolific and accessible.