refi64

I seem to get the same results, the `compile_commands.json` looks like: ``` { "directory": "/home/ryan/playground/clang-modules", "arguments": ["/home/ryan/code/llvm-project/install/usr/local/bin/clang", "-c", "-Qunused-arguments", "-O3", "-std=c++23", "-stdlib=libc++", "-fexperimental-modules-reduced-bmi", "-DNDEBUG", "-x", "c++-module", "-fmodule-output=build/.gens/mod/linux/arm64-v8a/release/rules/bmi/cache/modules/81262397/SomeModule.pcm", "-o", "build/.objs/mod/linux/arm64-v8a/release/mod.cc.o", "mod.cc"],...

I'd imagine a subset would work, since *most* usage of systemd user units is pretty basic...though it might be tricky to parse the unit files (the syntax is an *extension*...

This is actually "fixed" by defining another async test that runs afterwards, e.g.: ```javascript test('b', async () => { console.log('test b') await Bun.sleep(1) }) ``` will cause it to no...

So https://github.com/oven-sh/bun/pull/13463 fixed hangs for the `done` callback, with [this code in `jest.zig`'s `TestRunnerTask.run`](https://github.com/oven-sh/bun/blob/850cdb0587eaf333beeb098dca285d4f8c54a46a/src/bun.js/test/jest.zig#L1431-L1435) from https://github.com/oven-sh/bun/commit/886c31f0c5971607cb1777148d805688be6d1b98: ```zig if (this.reported and this.promise_state != .pending) { // An unhandled error was reported....

Does using the instance ID instead of the PID work instead?

For the purposes of testing, can you try the instance ID (the longer one)? They should both work.

I can definitely reproduce this. Bizarrely enough, the PID recorded in `$XDG_RUNTIME_DIR/.flatpak/instance/pid` is *dead*, and the child PID recorded in `$XDG_RUNTIME_DIR/.flatpak/instance/bwrapinfo.json` is the bwrap process. Atom seems to go through...

So I've spent a bit of time looking into this (1password user here!), and unfortunately I think the verdict is that, at the moment, there isn't really a practical way...

@complexspaces would it be possible to just have a small section of `mlock`/`MADV_DONTDUMP` memory (which is how passwords are *ideally* stored anyway), and have your APIs essentially treat it as...

Hmm that could definitely work, the primary way you run commands inside of a systemd-nspawn container is similar (it connects to the container's D-Bus instance and uses that to tell...