@nprofile1q... why don't they contact Microsoft support to help them figure out which application installed that file and how to update it, or to improve their OS so it can automatically track this information?
I don't have access to a Windows machine anymore, but I would've right clicked on the file to find its version and digital signature, and hopefully that would've told them who built the file.
There are also various scripts to try to find the (un)installer that'd be responsible for a particular file https://github.com/Zero3/windows-installer-file-search, and the uninstallers might also be cached somewhere.
Although there are multiple installer formats, multiple package managers, etc. so it may not work.
(Although maybe standardising on .MSI and Winget could help)

Taking a step back though, if an organisation can't find out why one of their machines has an executable file/DLL and how it got there, then they have a bigger security problem than an unaddressed CVE in libcurl.dll, and they should work on fixing *that* first.

@nprofile1q... nice speedups!

It feels like there are some things missing from the standard library, and it'd be nice if the stdlib was improved so that in future versions you wouldn't have to rely on runtime internals like `caml_ba_update_proxy`.

What do you think could be added to Bytes and Bigarray to make your implementation simpler?

@nprofile1q... nice. One caveat with running benchmarks on the local dev machine: ensure that CPU turbo/boosting is off, and governor is performance. Otherwise you could get one benchmark influencing the next one, or an inefficient implementation (that raises CPU frequency on a core) appearing faster than an efficient one (which doesn't run long enough to raise the frequency).
I got this wrong enough times that I have a script to do it and undo it (unfortunately the API to turn it off is different between Intel and modern AMD CPUs).

@nprofile1q... good point, OCaml is similar, but it doesn't have a similar packaging policy (it creates statically linked binaries, unless you go out of your way to create dynamically loadable plugins).
Maybe now that Rust and Go have vendoring support (at least in Fedora), it could be used to allow something similar for OCaml.

@nprofile1q... nice! Looks like Rust, Go and Haskell have good support for dealing with dependencies: https://docs.freebsd.org/en/books/porters-handbook/special/#using-cargo

Interestingly Fedora says that Go programs *must* vendor their dependencies (which contradicts the usual no vendoring for system packages...) https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_vendored_dependencies

Although it seems like a better way forward would be to add better support for emitting distro packages into the upstream language-specific tooling. That'd be a one-off effort / language ecosystem, rather than having each library/application having to figure out how to do this on its own.
It'd probably require augmenting the upstream language-specific packages with more metadata, although it feels like a https://xkcd.com/927/ problem.

@nprofile1q... @nprofile1q... I'm surprised that `g` would use `long`, instead of a fixed width integer type. If this is part of a compiler pass it would've had to assign known sizes to the types by this point. I don't think the transformation would be valid on an ILP32 or ILP64 system. Or maybe because the compiler only supports one model, it is valid under that one?

@nprofile1q... what you are describing sounds similar to handshaking, I think you also need an arbiter to decide which "caller" to run (remember that in an FPGA everything happens in parallel).
This article describes compostable building blocks for achieving that: https://www.cs.toronto.edu/~hehner/HLCD.pdf
However getting from theory to practical implementation also means you have to add either timing constraints, or local handshaking.

@nprofile1q... look for ESP32-P4, such as the M5Tab5

@nprofile1q... this has a plausible explanation: https://docs.oracle.com/cd/E19455-01/806-5257/sync-94/index.html
> To avoid priority inversion, prioceiling will be set to a priority higher than or equal to the highest priority of all the threads that might lock the particular mutex.

I assume you'd determine the 'highest priority thread that might lock the mutex' through static analysis, or guarantee it another way in an application's design, and then you set the prio ceiling to tell the kernel about it.

@nprofile1q... @nprofile1q... @nprofile1q... a variation of this is when you fix a bug in a 3rdparty library, and you want to test the change before submitting it upstream. Except due to complexities in the build system you end up testing the old code and not the new one. Especially if the build requires applying a patch queue, where you've carefully added all the patches, but forgot to actually update the series file/.spec file/etc.
(The code was all fine and tested with unit tests in a proper git repo, but that is not always what the build system consumes).

A good way to ensure you are running the right code is to define a new function temporarily, and explicitly call that from the main application. Then you get a build error if you have the wrong dependency.
Also include a unique string in that function (not necessarily as a log statement, maybe the library isn't allowed to log), and check for the string in the built binary with `strings -a`.

@nprofile1q... Run `conpinstall`, it'll ask a series of questions to customize how completion works. You probably want the `original=true` setting from https://github.com/zsh-users/zsh/blob/2564174dd6f9289b4e4da2a8122b0f8edd8a62b4/Completion/compinstall#L1330

FWIW here is my zsh configuration: https://codeberg.org/edwintorok/dotfiles/src/commit/f81b592031ef8bd256897b90b2a0c96e118f3780/zsh/.zshrc
I use the https://github.com/agkozak/agkozak-zsh-prompt prompt because it is asynchronous (so you don't get huge delays in large git repos).

@nprofile1q... the official rationale is here: https://pubs.opengroup.org/onlinepubs/9799919799/xrat/V4_xsh_chap01.html#tag_22_02_08. It makes sense why they picked a signed type (handling differences). And they also explain why they wanted a 32-bit type.
`long` seems to be the only type guaranteed to be at least 32-bits. But fixed width integer types are also required by POSIX, so it doesn't explain why not those.
Although it looks like this changed in C23, where the type becomes an implementation defined signed integer capable of holding that range (which would allow you to choose th best one for your implementation) https://en.cppreference.com/c/chrono/timespec
I assume that the next POSIX spec update will catch up to the C standard?

Although in practice I don't think it'll matter, time_t is 64-bit already, so with a 32-bit tv_nsec, you'll likely get padding to 64-bit anyway...