MawKKe

Would be nice to have some example code how the class is intended to be used

Well, that's the danger of using software without version pinning.

Also, usually tools like Ruff can be configured to enable/disable project-specific formatting rules (via a config file), allowing you to suppress the defaults you disagree with, or whose consequence you don't want to deal with _right now_. Some tools might even support suppressing specific rules per-file, so you can migrate codebase over time instead of in one go.

Having a config that explicitly defines the rules enforced in the project is really useful, and perhaps even crucial the bigger the project grows.

Sounds like the issue is not the tools themselves, but that the project management / stewardship allows someone to replace tools willy-nilly leaving others to pay the cost of migration?

At $WORK we have "code guardians" whose responsibility is do to this kind of migrations strategically in the background. The intent is that most other developers should not need to do any (or very little) extra work beyond the task they are actively working on.

This might be nvidia driver thing, I've had similar soft-bricking happen on ubuntu as well

FYI you can add description text to a photo in the (default) Photos app. Just swipe up and there should be a text box. You can (usually) find a photos based on what you've written

Similar thing happened (to me) with Hackaday around 2010-2011. I used to check it almost daily, and then never again after the major re-design.

There's also `std.fmt.allocPrint()` which functions similarly to `format!()`. Although I'd argue its rather poorly named, like many of the functions in the stdlib...

For wanting to avoid fiddling with multiple repeated alloc/defer-free, it's often convenient to use the arena allocators that allow you to release everything with a single `defer arena.deinit()`

Was the need for optimization work something that was on your mind the whole time? Like a nagging feeling in the back of the head that the code is not working as well as it _should_ be working? i.e. stress.

And when you finally "fixed" the issue through optimization, your mind allowed itself to let go of these open loops (borrowing the GTD terminology), leading to relaxation?

Isn't the new one also horribly type-unsafe? Since you can put (parent) objects of any kind into the list without any mechanism to detect which is which?

Zig builds a statically linked library called "cgo_static_linking" from Zig sources. Zig places the artifact into "./zig-out/lib/cgo_static_linking.a" (or maybe some other extension). The library is exported with C ABI, which Go (cgo) compiler supports.

The #cgo line tells the Go compiler to add custom compilation flags: -l flag tells the compiler that you wish to link to a library called "cgo_static_linking" in to the binary. However, the cgo compiler can't find it since it is not in the default search paths for libraries. The -L option extends the library search path to "./zig-out/lib/", allowing "cgo_static_linking" to be found.

The "#include" line inserts the header file contents as-is into the source file (main.go), bringing the definition of the function available to the compiler. The compiler is then able to compile the Go source, and later link it with the other build artifacts to produce the final executable.

The key here is the "C ABI" which acts as common ground for both languages. The rest is just scaffolding to let the compilers find and connect appropriate files together.

numpy as well. and tensorflow

Quick glance of zstd github repo shows they do provide CMake build scripts?

I mean, it's possible that at some point evolution produced such nuclear reactored individual, but who got "naturally selected" rather quickly for obvious reasons

VScode devcontainer can build from existing Dockerfile. You can develop the project image as usual, and then reference the Dockerfile from devcontainer.json. This means you can build and run from the command line via `docker` command if needed. The VScode extension just makes this slightly easier.

Not sure how GP's company does it, but that is how I would configure it.

Caveat: the default devcontainer initialization workflow does _not_ create the Dockerfile, only the .json.

At $work we don't use devcontainer.json, but we can launch the development environment image such that you can SSH into it as if it was a regular VM.