a better workflow?

Richard Eisenberg rae at richarde.dev
Tue Jul 23 02:56:19 UTC 2019


Hi devs,

Having gotten back to spending more time on GHC, I've found myself frequently hitting capacity limits on my machine. At one point, I could use a server at work that was a workhorse, but that's not possible any more (for boring reasons). It was great, and I miss it. So I started wondering about renting an AWS instance to help, but I quickly got overwhelmed by choice in setting that up. It's now pretty clear that their free services won't serve me, even as a trial prototype. So before diving deeper, I thought I'd ask: has anyone tried this? Or does anyone have a workflow that they like?

Problems I have in want of a solution:
 - Someone submits an MR and I'm reviewing it. I want to interact with it. This invariably means building from scratch and waiting 45 minutes.
 - I work on a patch for a few weeks, on and off. It's ready, but I want to rebase. So I build from scratch and wait 45 minutes.
 - I make a controversial change and want to smoke out any programs that fail. So I run the testsuite and wait over an hour.

This gets tiresome quickly. Most days of GHC hacking require at least one forced task-switch due to these wait times. If I had a snappy server, perhaps these times would be lessened.

By the way, I'm aware of ghc-artefact-nix, but I don't know how to use it. I tried it twice. The first time, I think it worked. But by the second time, it had been revamped (ghc-head-from), and I think I needed to go into two subshells to get it working... and then the ghc I had didn't include the MR code. I think. It's hard to be sure when you're not sure whether or not the patch itself is working. Part of the problem is that I don't use Nix and mostly don't know what I'm doing when I follow the ghc-artefact-nix instructions, which seem to target Nix users.

Thanks!
Richard


More information about the ghc-devs mailing list