I have a tool wrapper that captures the output of anything and allows the LLM to query it later, to save on tokens. It “smartly” truncates the output (basically like Node’s util.inspect) and allows the LLM to expand truncated content.
It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying.
This for me solves the danger of a tool returning tons of content.
My newest cat started as a stray. Cautious around humans, but not feral. He was hanging around a lot, so of course I started giving him food because I’m a sucker that way. He disappeared for a couple months, then showed up injured from a fight one day, so we took him to the hospital and ended up keeping him in the garage for a few days to recover. We also did the usual due diligence to locate an owner.
The rest, of course, is history. Now he’s a big 20lb goober of a cat who is positively enamored with my wife. The feeling is mutual.
There was a farm nearby where a mother cat died and all but two kittens died from hunger afterwards. We adopted one, my wife fed the kitten (which was way underage for adopting) with bottle.
Now she has been with us for years. She’s very loyal to me, dismissive to aggressive to anyone else. Not sure why me and not my wife, but hey :)
She basically sleeps next to me all the time, both when I work from home or at night. She’s 14 now, no medical issues.
Practically? Quite a few codebases from *nix systems rely on the case sensitivity. To do a successful git clone you need a file system that handles both Makefile and makefile, or whatever.
I ran into it more than once back in the day when I used Mac OS X as my primary OS.
More generally -- case sensitivity is a conceptual nightmare in the Unicode era. Should Cyrillic or Greek be case-insensitive as well? Etc. Do you really want the full complexity of Unicode string handling in your file system?
I would suggest treating file names like raw bytes. On modern Linux, anything but NUL is valid.
Sometimes you download stuff that relies on case sensitivity. Anyone who's dealt with this probably has a sensitive RW DMG lying around for this reason. But macOS FSes default to case-insensitive, so random issues come up if you make your root sensitive (famously in Adobe software). Damned if you do or don't.
Another weird thing in macOS:
$ mkdir Cased
$ cd cased
$ pwd
/Users/me/Downloads/cased
$ cd ../Cased && pwd
/Users/me/Downloads/Cased
So yeah I wish the FS defaulted to sensitive, even though I never rely on that. Not its job to normalize names.
-L Display the logical current working directory.
-P Display the physical current working directory (all symbolic links resolved).
If no options are specified, the -L option is assumed.
In Bash and many modern POSIX shells, `pwd` is a builtin, not to mention an environment variable ${PWD}, but the POSIX system should also provide an external command, such as `/bin/pwd` that would operate on the filesystem, rather than semantically tracking your shell activity.
It can be nice to checkout some Git repositories that have this. It can also be nice to catch miscapitalizations of filename imports when those would fail on Linux, etc. One of my past workplaces actually had that problem, they mis-cased imports and the product failed to build on Linux. Nobody caught it because they all used macOS or Windows, I was the first to try WSL (this was before I switched back to Mac)
You would be asking for a world of hurt to put your root filesystem in a case-sensitive volume though. All sorts of software and applications have silently relied on case-insensitivity for decades. You can sometimes fix it on a case-by-case basis, but sometimes you can't, and it's also annoying for it to happen in the first place. Better to have a separate case-sensitive volume just for the stuff you want to be case-sensitive.
Mostly consistency in knowing that Foo will become foo. This is a problem when it comes to (for example) supporting devs on Windows working on a codebase with prod on Linux. The database dbCustomer would be renamed dbcustomer on Windows.
There are workarounds, and containerization is a better idea, but you asked why you might want this.
I don't know if the splat is exactly the same, but the playcanvas engine has no false transparency on this one: https://superspl.at/scene/7e4e9bcb that splat is actually of fairly high quality, so unless this is a materially different splat (with some of the gaussians dropped out maybe?) I'm inclined to blame the engine.
If you turn off performance mode this is way higher quality than either of the other two versions of this model linked by bhouston in this thread, although with a much lower frame rate on my phone of course:
Worktrees or sandboxes. You can tell Claude to put its stuff in a worktree. I can easily develop any amount of features in the same codebase because they all run in their own worktree
It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying.
This for me solves the danger of a tool returning tons of content.
reply