Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Vomitorium – all of your project in 1 text file

npmjs.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Show HN: Vomitorium – all of your project in 1 text file

#41

Post by __MatrixMan__ »

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.

Re: Show HN: Vomitorium – all of your project in 1 text file

#42

Post by scbrg »

Diti wrote: post #20
ghgr wrote: post #6

As an alternative to (npm -g)'ing here some potentially useful coreutils one-liners I've been using for a similar purpose: - Dump all .py files into out.txt (for copy/paste into a LLM) > find . -name "*.py" -exec cat {} + > out.txt - Sort all .py files by number of lines > find . -name '*.py' -exec wc -l {} + | sort -n

I was going to comment this. “What’s wrong with `cat`”, whose job is literally to concatenate files? Or even [uncompressed] `tar` archives, which are basically just a list of files with some headers?

Never underestimate the node community's willingness to ignore the existing tech stack and reinvent 50 year old tools. It's peak NIH.

Re: Show HN: Vomitorium – all of your project in 1 text file

#43

Post by aunderscored »

hobs wrote: post #39
SuchAnonMuchWow wrote: post #33

Earlier quoted context omitted.

To help with circular import, we switched a few years ago to lazily importing submodules on demand, and never switched back. Just add to your __init__.py files: import importlib def __getattr__(submodule_name): return importlib.import_module('.' + submodule_name, __package__) And then just import the root module and use it without ever needing to import individual submodules: import foo def bar(): return foo.subfoo.b…

Doesn't that mean your editor support is crap though?

It does, which is why this is more easily done by importing exact bits or using a single file

Re: Show HN: Vomitorium – all of your project in 1 text file

#44

Post by Cyberdog »

Charon77 wrote: post #17

Isn't this a tar file?

That's what I was thinking too. It looks like someone just reinvented tar, and given how it's a JavaScript thing I'm wondering if it's a zoomer who didn't know tar existed and the HN crowd would set them straight. But then I come into the comments here and people are posting about how absolutely brilliant it is, so surely I'm missing something… right?

Re: Show HN: Vomitorium – all of your project in 1 text file

#46

Post by ableal »

Cyberdog wrote: post #44
Charon77 wrote: post #17

Isn't this a tar file?

That's what I was thinking too. It looks like someone just reinvented tar, and given how it's a JavaScript thing I'm wondering if it's a zoomer who didn't know tar existed and the HN crowd would set them straight. But then I come into the comments here and people are posting about how absolutely brilliant it is, so surely I'm missing something… right?

> someone just reinvented tar

Or "shell archives", .shar files - https://en.wikipedia.org/wiki/Shar - they used to be kicked around in comp.sources.

Re: Show HN: Vomitorium – all of your project in 1 text file

#47

Post by SuchAnonMuchWow »

hobs wrote: post #39
SuchAnonMuchWow wrote: post #33

Earlier quoted context omitted.

To help with circular import, we switched a few years ago to lazily importing submodules on demand, and never switched back. Just add to your __init__.py files: import importlib def __getattr__(submodule_name): return importlib.import_module('.' + submodule_name, __package__) And then just import the root module and use it without ever needing to import individual submodules: import foo def bar(): return foo.subfoo.b…

Doesn't that mean your editor support is crap though?

Not at all. Sublime is perfectly fine with it.

I suspect that from the usage in the code, it knows that there is a module foo and a submodule subfoo with a function bar() in it, and it can look directly in the file for the definition of bar().

It would be another story if we used this opportunity to mangle the submodules names for example, but that the kind of hidden control flow that nobody want in his codebase.

Also, it is not some dark arts of import or something: it is pretty standard at this point since its one of the most sane way of breaking circular dependencies between your modules, and the feature of overloading a module __getattr__ was introduced specifically for this usecase. (I couldn't find the specific PEP that introduced it, sorry)

Re: Show HN: Vomitorium – all of your project in 1 text file

#48

Post by wasyl »

acoretchi wrote: post #10
wilsonzlin wrote: post #8

Similar project: https://github.com/yamadashy/repopack

Repopack with Claude projects has been a game changer for me on repository-wide refactors.

Seems like repopack only packs the repo. How do you apply the refactors back to the project? Is it something that Claude projects does automatically somehow?

Re: Show HN: Vomitorium – all of your project in 1 text file

#49

Post by rramadass »

leovailati wrote: post #45

We use a C compiler for embedded systems that doesn't support link time optimizations (unless you pay for the pro version, that is). I have been thinking about some tool like this that merges all C source files for compilation.

Unless i am understanding you wrong, you could easily do this by #including all your a.c, b.c etc. into one file input.c and feeding that to the compiler.

We did this for a home-grown SoC with a gcc port for which there was no linker.

Re: Show HN: Vomitorium – all of your project in 1 text file

#50

Post by ffsm8 »

__MatrixMan__ wrote: post #41

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--bo…

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

Post reply on HN