3 ms·

I've been dreaming of a tool which resembles this, at least in spirit. I want to figure out how to structure a codebase such that a failing test can spit out a

I've been dreaming of a tool which resembles this, at least in spirit. I want to figure out how to structure a codebase such that a failing test can spit out a CID for that failure such that it can be remotely recreated (you'd have to be running ipfs so that the remote party can pull the content from you, or maybe you push it to some kind of hub before you share it). It would be the files relevant to that failure--both code files and data files, stdin, env vars... a reproducible build of a test result. It would be handy for reporting bugs or getting LLM help. The remote party could respond with a similar "try this" hash which the tooling would then understand how to apply (fetching the necessary bits from their machine, or the hub). Sort of like how Unison resolves functions by cryptographic hash, except this is a link to a function call, so it's got inputs and outputs too. Of course that's a long way from vomiting everything into a text file, I need to establish functional dependency at as small a granularity as possible, but this feels like the first step on a path that eventually gets us there.

ffsm8 2y ago
Hmm, you could probably make a proof of concept on a weekend specifically in the typescript/JavaScript ecosystem, as it's already heavily reliant on bundlers. The process could be 1. defining a new/temporary bundler entry point 2. copying the failing code into the file 3. Bundle without minification It'd probably be best to reduce scope by limiting it to a specific testing framework and make it via an extension, i.e. jest
- __MatrixMan__ 2y ago
  You're talking sense, but I'm kinda wanting to do it at the subprocess level so that caller and callee need not use the same language (I was talking in terms of tests but tests are just a special kind of function). Whether to use nodejs or python or rust (and which version thereof) will be as much a part of the bundled function as its code. I figure I'll wrap nix so it can replicate the environments, then I'll just have to do the runtime stuff.

ffsm8 2y ago

Hmm, you could probably make a proof of concept on a weekend specifically in the typescript/JavaScript ecosystem, as it's already heavily reliant on bundlers. The process could be 1. defining a new/temporary bundler entry point 2. copying the failing code into the file 3. Bundle without minification It'd probably be best to reduce scope by limiting it to a specific testing framework and make it via an extension, i.e. jest

__MatrixMan__ 2y ago
You're talking sense, but I'm kinda wanting to do it at the subprocess level so that caller and callee need not use the same language (I was talking in terms of tests but tests are just a special kind of function). Whether to use nodejs or python or rust (and which version thereof) will be as much a part of the bundled function as its code. I figure I'll wrap nix so it can replicate the environments, then I'll just have to do the runtime stuff.