They had stopped for a while because they were transitioning away from using Paypal as a processor. A few weeks, maybe a month or so tops? I had to switch to JLC PCB for an order back in January, because they didn't support any viable payment method for me in Canada (tried to make a payoneer account, they don't do business in Canada).

But I just checked and it seems that they now accept CCs again.

In case anyone is interested, I enjoyed the book "Turn the Ship Around!" by L. David Marquet, about management lessons applied by the author who was a US Navy submarine captain. It does very much emphasize giving trust, responsibility and accountability to workers (or enlisted personnel, in this case).

One of my favourite techniques from that book is to remove the centralised backlog. People's ideas for improvement shouldn't be everyone's administrative burden. There are too many ideas for that.

Instead, keep a central record of the things that need to be done right now, and if something is important to do later, then someone will probably keep track of it personally and bring it up later when it is more relevant.

Agreed. Tex/Latex is very old tech. Error recovery and messages is very bad. Developing new macros in Tex is about as fun as you expect developing in a 70s-era language to be (ie probably similar to cobol and old fortran).

I haven't tried it yet but Typst seems like a promising replacement: https://typst.app/

uv has mostly solved the python issue. IME it's dependency resolution is fast and just works. Packages are hard linked from a global cache, which also greatly reduces storage requirements when you work with multiple projects.

uv is great for resolution, but it seems like it doesn't really address the build complexity for heavy native dependencies. If you are doing any serious work with torch or local LLMs, you still run into issues where wheels aren't available for your specific cuda/arch combination. That is usually where I lose time, not waiting for the resolver.

uv does nothing to help when you have old, crappy, barely maintained Python packages that don’t work reliably.

You still need to compile when those libraries are not pre compiled.

I mean, he absolutely knew it was going to burn up. But I have no trouble believing that such a circuit was designed by AI.

It's because aluminium has a higher coefficient of thermal expansion. It expands and shrinks more as it heats, and as those cycles add up it tends to loosen electrical connections. Loose connections have higher resistance, heat up and can cause fires.

That said, there is no reason we can't design better connectors that can withstand the expansion and shrinkage cycles, like spring loaded or spring cage connectors.

Wiring devices have almost all been universally rated for Al/Cu conductors for the last 50 years, what you’re talking about only lasted a handful of years in the early 1970s.

Go look at the terminals on any light switch or receptacle at Home Depot, they’re all Al/Cu rated.

Just an idea but Nim seems to have the features you mentioned. Nim "transpiles" to C, and can even be compiled via `zig cc` (which is an interace to clang). If you really want to, maybe you could make a zig backend for Nim?

no one even use nim plus nim dont give inline zig

Popularity is one thing { and probably more people use it than a non-existing new PLang you are only at the design phase of :-) }, but I think you misunderstood the backend idea. Nim has a javascript backend via `nim js` and on that backend you can use `emit` to do inline javascript, just as on the C/C++ backends you can use emit to put out C/C++. So, if you did do a zig backend, being able to emit inline zig would be part of that. It may still not be what you want, of course.

I already have using zig keyword user will be able to use whole zig inline like:

Zig {

Zig code here

}

As long as you keep the module and pressure angle the same, the gears should be compatible.

Only works in a one-way system, which might be okay, but if bidirectional is a requirement then the other gear would be necessary. I suppose then just create a symmetrical gear. Sorry I'm not a gear-head.

This is great! Any chance you could add STEP export also? It would facilitate importing into CAD software to customize the gear, eg to add a custom hub.

Or even just the ability to export a 2d dxf which is probably simpler to implement.

STL and 3MF are not very compatible with most CAD software.

uv uses a global cache but hardlinks the dependencies for your script into a temp venv that is only for your script, so its still pretty fast.