Chris Dell

Changing the function reference from: `esp_a2d_register_data_callback` to: `esp_a2d_sink_register_data_callback` seemed to fix it for me.

This is what I've gone with for now: ```javascript /** Is this code executing in a Bull process? */ export const isBullProcess = process.argv.some(a => a.includes('bull')) ```

I encountered this issue when beginning to use the `satisfies` keyword for the first time in a WebPack project. I've narrowed it down to the smallest example of the bug...

Thanks @johnnyreilly. I actually have since narrowed it down further and I'm invoking the TS compile just as `ts-loader` does and it behaves the same way. Looks like a legitimate...

Link to the TypeScript issue for anyone following this: https://github.com/microsoft/TypeScript/issues/51642

Looks like this will be fixed very shortly... :-) https://github.com/microsoft/TypeScript/pull/51704

I have a solution for this: https://github.com/cjdell/mcpi/commit/5ba6bd693a836b30cb94f013ec9490225060c37b In short: ```python mc.setBlock(1, 2, 3, mcpi.block.TNT.id) ``` needs to be: ```python mc.setBlock(1, 2, 3, 'tnt') ``` This is because the newer protocol...

I'm getting the same problem with the compiler hanging, though I have narrowed it down to these lines which when I replace with `any` the compiler will work again: ```...

Noticing this too. With 1 CPU it is fine. You can easily see the problem when pinging the NAT gateway (in my case this is 192.168.64.1). With a single CPU...

Needs resolving. We have 3 instances of this thing using up 0.75 cores and we are now at the limit of resources for our cluster. There is barely any CPU...