Went to see what this does. I think it might tell me? But it's unveiling the info as though the docs are generated in real time, one token at a time. For all I know, they might be? Anyway, I bounced. Ain't nobody got that kinda attention oh look a squirrel
The animation also shoves the mobile site down one line at a time, so if you skipped ahead because you're trying to read complete sentences, you get an unpleasant experience.
Appreciate the honest feedback on the website - hearing this loud and clear from multiple people. The Product Hunt page definitely does a better job explaining it simply.
Re: AMD - I'd love to chat about this. We're running on Modal right now which uses NVIDIA, but supporting AMD would be valuable especially as we scale. What part of the stack do you have running? Would be interested in exploring a collaboration.
We've written a cuda to amdgpu compiler. It should be possible to persuade someone like Modal that this is wonderful. So far people largely decline to believe that it can be done at all :)
If you've written vaguely reasonable cuda, feed it to our nvcc binary and away you go. It's more annoying with dependencies, e.g. first one builds cutlass with our "nvcc" and so forth. Just occurred to me while writing this that we could start hosting builds of popular libraries ourselves.
Does it help agents set up development environments?
This is confusing as mostly the problem has been solved - suboptimally but "well enough" - by a patchwork of solutions every repo builds over time:
1. README.md - which agents can read and follow just fine. And they can debug the problems and if you ask, they can update the README so the next agent (or human) can follow the README with less trouble.
2. Dependency versions can be pinned in Dockerfile to avoid dependency hell.
3. Version pinning is supported by project.toml, Gemfile, package.json etc. as well. And all the major languages offer per-directory isolated dependency environments (uv/venv, nvm, rvm, chruby, etc.) So even non-containerized dev has no dependency hell.
4. Secrets for the "dev DB" etc. can be stored in a password vault or wiki. Which agents can access via a browser or curl, given your credentials - or else you can copy-paste them over.
Most crucially, development environments are only set up once when starting work on a new codebase. As rarely as once every few years.
It doesn't really explain where the environment runs, it's not clear if I have to configure something like GCP/AWS or if GitArsenal handles all this (and how much it costs if so)
Good question, it handles all the infrastructure. GitArsenal runs on Modal's serverless platform, and we automatically provision the right machines for each repo's requirements(working on this feature btw). You don't need to configure GCP/AWS or manage any cloud resources, just point us at a GitHub repo and we handle finding the appropriate compute, spinning up environments, and running the setup
The unsolved part: reliable, automated setup that works across the long tail of repos without human intervention. Docker helps but doesn't solve it (many repos don't have working Dockerfiles, and building those is itself a setup problem).
but dockerfile is not the complete setup you need to configure a lot of other things, and in a lot of cases dockerfile is not even getting generated correctly, try out gitpod they generate devcontainer.json which is a standard format across different platforms, but generating a devcontainer.json or Dockerfile has never been easy for agents specially when the repositories are complex.
Went to see what this does. I think it might tell me? But it's unveiling the info as though the docs are generated in real time, one token at a time. For all I know, they might be? Anyway, I bounced. Ain't nobody got that kinda attention oh look a squirrel
The animation also shoves the mobile site down one line at a time, so if you skipped ahead because you're trying to read complete sentences, you get an unpleasant experience.
yup great suggestion, will fix that.
TL;DR: GitArsenal automates the "clone, install, build, test" workflow for GitHub repos.
There's a coherent description of what the product is at https://www.producthunt.com/products/gitarsenal?comment=5026... - the linked website is too fancy for me to make sense of. Can't throw stones though, our one confuses me too.
Shame to see it's all Nvidia tech. If you want it on AMDGPU as well I've got that part of the stack running. Can probably do something collaborative.
Appreciate the honest feedback on the website - hearing this loud and clear from multiple people. The Product Hunt page definitely does a better job explaining it simply.
Re: AMD - I'd love to chat about this. We're running on Modal right now which uses NVIDIA, but supporting AMD would be valuable especially as we scale. What part of the stack do you have running? Would be interested in exploring a collaboration.
Feel free to reach out at: rohan@ataraxy-labs.com
We've written a cuda to amdgpu compiler. It should be possible to persuade someone like Modal that this is wonderful. So far people largely decline to believe that it can be done at all :)
If you've written vaguely reasonable cuda, feed it to our nvcc binary and away you go. It's more annoying with dependencies, e.g. first one builds cutlass with our "nvcc" and so forth. Just occurred to me while writing this that we could start hosting builds of popular libraries ourselves.
3am here so I'll leave you with our somewhat confusing https://spectralcompute.com/ and the more useful direct link to a tarball https://docs.scale-lang.com/stable/manual/how-to-install/#__...
I've only just started thinking about how to make it easier to use the stack. Thoughts / feedback very welcome on that!
Does it help agents set up development environments?
This is confusing as mostly the problem has been solved - suboptimally but "well enough" - by a patchwork of solutions every repo builds over time:
1. README.md - which agents can read and follow just fine. And they can debug the problems and if you ask, they can update the README so the next agent (or human) can follow the README with less trouble.
2. Dependency versions can be pinned in Dockerfile to avoid dependency hell.
3. Version pinning is supported by project.toml, Gemfile, package.json etc. as well. And all the major languages offer per-directory isolated dependency environments (uv/venv, nvm, rvm, chruby, etc.) So even non-containerized dev has no dependency hell.
4. Secrets for the "dev DB" etc. can be stored in a password vault or wiki. Which agents can access via a browser or curl, given your credentials - or else you can copy-paste them over.
Most crucially, development environments are only set up once when starting work on a new codebase. As rarely as once every few years.
Can you explain what's unsolved?
Yeah if you go through setupbench, envbench, and csrbench papers you will realize how badly the agents perform in environment bootstrapping.
Infact github started building their own agent called as DiscoveryAgent to just solve this one issue.
It doesn't really explain where the environment runs, it's not clear if I have to configure something like GCP/AWS or if GitArsenal handles all this (and how much it costs if so)
Good question, it handles all the infrastructure. GitArsenal runs on Modal's serverless platform, and we automatically provision the right machines for each repo's requirements(working on this feature btw). You don't need to configure GCP/AWS or manage any cloud resources, just point us at a GitHub repo and we handle finding the appropriate compute, spinning up environments, and running the setup
Or, Docker
The unsolved part: reliable, automated setup that works across the long tail of repos without human intervention. Docker helps but doesn't solve it (many repos don't have working Dockerfiles, and building those is itself a setup problem).
I dunno, I find it pretty easy to ask Claude or Cursor to make a portable dockerfile to run a python app locally or in a hosted environment.
but dockerfile is not the complete setup you need to configure a lot of other things, and in a lot of cases dockerfile is not even getting generated correctly, try out gitpod they generate devcontainer.json which is a standard format across different platforms, but generating a devcontainer.json or Dockerfile has never been easy for agents specially when the repositories are complex.