Finally got around to updating hex2txt. I've slapped on a deprecation notice and added a FAQ entry highlighting the amazing ecosystem/tooling updates that obviate it, including the ExDoc Markdown formatter + llms.txt generation, new HexDocs search engine, `mix hex. docs fetch`, usage_rules, Tidewave, etc. #ElixirLang
New project: hex2txt (hex package docs → llms.txt file)
Help AI coding assistants write better Elixir code by teaching them about the packages you're using.
#MyElixirStatus
@Stammy@mzu_maclean Have you tried Scoot? Supports element-based navigation (using accessibility APIs), alongside grid-based nav.
https://t.co/D9lcEDvYRC
I use Voom to run a custom image built from my NixOS system configuration, so each VM is a full development environment, with all my dotfiles, programs, etc. already configured. This image has nix-direnv pre-wired, and since every project I work on has a Nix devShell, I don't need to worry about setting up any toolchains or manually installing software once I'm inside the VM.
This approach fills a Vagrant-shaped hole, at least for my needs.
That being said, I'd love to know how @mitchellh would approach a modern take on Vagrant... I'd have to imagine it would involve Nix at some fundamental level.
https://t.co/e5KyM8LxMx
@jfroma Vagrant itself is in the IBM machine now but the idea of Vagrant adapted to contemporary patterns would absolutely explode right now. I've talked to a LOT of devs (and VCs lmao -- not interested on my side) about it.
Just released Voom, my take on a "magic-free CLI for running and managing virtual machines". Given how much time I've been spending developing inside of VMs lately (trending to 100%), I wanted something custom that perfectly fits my needs. Open sourcing in case anyone else finds it valuable:
https://t.co/rWDsd38DbY
There are, of course, a huge number of existing options and alternatives. Huge thanks to @lynaghk for documenting many of them: https://t.co/G4jHPBFfUQ
Vibe is optimized for fast-startup time and agent access. Voom instead makes some different tradeoffs, and is what I use for longer-running, "disposable-ish, pseudo-ephemeral VMs"; typically I'll have a handful of these going at any given time, and I don't just relegate them to agents: I'll SSH in, launch tmux and Emacs (from inside the VM), and get to work.
There is at least a certain elegance to distinguishing between interactive and non-interactive use, and billing them differently. This works if you think of a Claude subscription like a gym membership (an analogy Anthropic employees have used in the past).
However, if the technical mechanism you're using for classification labels tools like Conductor and Tidewave as non-interactive, and Gas Town as interactive... well, it's clearly pretty brain-dead.
The whole Anthropic kerfuffle would have gone much smoother if they had been upfront about it.
"Hey, we know this is unpopular, but we are moving programmatic access to API pricing. To easen the transition, we are giving API credits that match your subscription value. We also expect this change to increase capacity, so we are doubling the limits throughout Claude products for the next 2 months".
The reason they made it sound like an upgrade was because the announcement was not for developers. It was for investors and enterprise customers. Impacting devrel is just collateral damage, which is on par for a company which believes coding is going away any time now.
And this is extremely disapointing because they want to position themselves as a company that we should trust. But if they can't be honest about pricing changes, it is really hard to believe them on anything else.
Ah, so the actual setting is "Branch new workspaces from", which is correctly labeled as "origin/main". But, if you click to open the dropdown, the option then appears (incorrectly labeled) as "main".
The implication is that you can't actually choose "main" (which I would personally prefer for at least some repos).
There's a bunch of spots where Conductor refers to "main" but really means "origin/main". I'd bet this bug report is related. (iirc, if you have code on main that hasn't been pushed, and you make a new workspace, Conductor will update the remote origin/main and branch from that spot, not your local main branch.)
Scoot, your friendly neighbourhood keyboard-driven MacOS cursor actuator, (finally) works properly on systems running the Aerospace window manager with multiple connected displays.
Shout out to @bymarvindore a) for his first open source contribution, and b) for fixing this long-standing issue.
https://t.co/3eAJ8wvfSb
For Conductor specifically I think showing the main worktree (as a "root workspace" that you can directly chat with), with one click to move code between trees (automatically build a patch, use git to apply it, hand-off to agent to fix if apply fails) would be a good unlock. The latter has some overlap with spotlight testing but it's more flexible and unlocks some different usage patterns.
Just open sourced a project that automatically publishes WASM builds of mquickjs (Micro QuickJS). If you need to run untrusted code, a WASM-sandboxed JavaScript interpreter might be a very good fit.
This builds upon excellent exploratory work by @simonw, removes some hacks, and adds automation.
https://t.co/9aBizItviQ