<div dir="ltr">Hey everyone! I'm not a frequent contributor but I observed similar challenges<br>as Hécate. I notice couple points.<br><br>### HLS and other editor integrations<br><br>I've never tried HLS for GHC development but it absolutely chokes on Cabal<br>for me (a $2K laptop), so I'm not surprised it's having troubles with GHC.<br>I've never tried to dig into it, but I heard before that disabling plugins is a<br>good start.<br><br>Ghcid (after the introduction of ghc-in-ghci) was interesting but still on a slow side.<br><br>I once tried to generate ETAGS and use them from Emacs (with plain haskell-mode): this<br>was quite nice. As Moritz, I didn't use much above syntax coloring, but ETAGS<br>allowed jumping to definitions, which is important. Maintaining tags wasn't fun,<br>on the other hand.<br><br>In all fairness, I think that's an issue with HLS more than with GHC.<br><br>### Build Times<br><br>I have been using a dedicated server for this, but this still was painful at<br>times (even git clone takes non-negligible amount of time, and I never got used<br>to git worktree because of a hoop you have to jump over, which I already forgot<br><div>but I know it can be looked up in Andreas Herrmann's presentation on developing <br></div><div>GHC). I'm surprised no one seems to try to challenge the status quo.<br></div><br>Hadrian is a Shake application. How is Cloud Shake doing? In the era of Nix and<br>Bazel you start assuming niceties like remote caching. It'd be great to improve<br>on this front as it just feels very wrong rebuilding master again and again on every<br>contributor's computer. Especially after so much effort put into GHC modularity,<br>which, I believe, should make it easier to cache. <br><br>It's sad that GHC still needs ./boot && ./configure: this can preclude any<br>remote caching technology that I can imagine. At one point it seemed like<br>configure could go into Hadrian, but it didn't really happen. <br><br>In the bright future I see Hadrian doing the whole job and using remote cache<br><div>on GitLab CI. Not sure how big of a task that would be.</div><div><br></div><div>--</div><div>Cheers, Artem<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Jul 2022 at 15:11, Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hécate <<a href="mailto:hecate@glitchbra.in" target="_blank">hecate@glitchbra.in</a>> writes:<br>
<br>
> Hello ghc-devs,<br>
><br>
> I hadn't made significant contributions to the GHC code base in a while, <br>
> until a few days ago, where I discovered that my computer wasn't able to <br>
> sustain running the test suite, nor handle HLS well.<br>
><br>
> Whether it is my OS automatically killing the process due to oom-killer <br>
> or just the fact that I don't have a war machine, I find it too bad and <br>
> I'm frankly discouraged.<br>
<br>
Do you know which process was being killed? There is one testsuite tests<br>
that I know of which does have quite a considerable memory footprint<br>
(T16992) due to its nature; otherwise I would expect a reasonably recent<br>
machine to pass the testsuite without much trouble. It's particularly<br>
concerning if this is a new regression; is this the first time you have<br>
observed this particular failure?<br>
<br>
> This is not the first time such feedback emerges, as the documentation <br>
> task force for the base library was unable to properly onboard some <br>
> people from third-world countries who do not have access to hardware <br>
> we'd consider "standard" in western Europe or some parts of North <br>
> America. Or at least "standard" until even my standard stuff didn't cut <br>
> it anymore.<br>
><br>
> So yeah, I'll stay around but I'm afraid I'm going to have to focus on <br>
> projects for which the feedback loop is not on the scale of hours , as <br>
> this is a hobby project.<br>
><br>
> Hope this will open some eyes.<br>
><br>
Hi Hécate,<br>
<br>
I would reiterate that the more specific feedback you can offer, the<br>
better.<br>
<br>
To share my some of my own experience: I have access to a variety of hardware,<br>
some of which is quite powerful. However, I find that I end up doing<br>
much of my development on my laptop which, while certainly not a slouch<br>
(being a Ryzen 4750U), is also not a monster. In particular, while a<br>
fresh build takes nearly twice as long on my laptop than some of the<br>
other hardware I have, I nevertheless find ways to make it worthwhile<br>
(due to the ease of iteration compared to ssh). If you routinely have<br>
multi-hour iteration times then something isn't right.<br>
<br>
In particular, I think there are a few tricks which make life far<br>
easier:<br>
<br>
<br>
 * Be careful about doing things that would incur<br>
   significant amounts of rebuilding. This includes:<br>
<br>
    * After modifying, e.g., `compiler/<a href="http://ghc.cabal.in" rel="noreferrer" target="_blank">ghc.cabal.in</a>` (e.g. to add a new<br>
      module to GHC), modify `compiler/ghc.cabal` manually instead of<br>
      rerunning `configure`.<br>
<br>
    * Be careful about pulling/rebase. I generally pick a base commit to<br>
      build off of and rebase sparingly: Having to stop what I'm doing to<br>
      wait for full rebuild is an easy way to lose momentum.<br>
<br>
    * Avoid switching branches; I generally have a GHC tree per on-going<br>
      project.<br>
<br>
 * Take advantage of Hadrian's `--freeze1` flag<br>
<br>
 * Use `hadrian/ghci` to typecheck changes<br>
<br>
 * Use the stage1 compiler instead of stage2 to smoke-test changes when<br>
   possible. (specifically, using the script generated by Hadrian's<br>
   `_build/ghc-stage1` target)<br>
<br>
 * Use the right build flavour for the task at hand: If I don't need a<br>
   performant compiler and am confident that I can get by without<br>
   thorough testsuite validation, I use `quick`. Otherwise, plan ahead<br>
   for what you need (e.g. `default+assertions+debug_info` or<br>
   `validate`)<br>
<br>
 * Run the fraction of the testsuite that is relevant to your change.<br>
   Hadrian's `--test-way` and `--only` flags are your friends.<br>
<br>
 * Take advantage of CI. At the moment we have a fair amount of CI<br>
   capacity. If you think that your change is close to working, you can<br>
   open an MR and start a build locally. If it fails, iterate on just the<br>
   failing testcases locally.<br>
<br>
 * Task-level parallelism. Admittedly, this is harder when you are<br>
   working as a hobby, but I often have two or three projects on-going<br>
   at a time. While one tree is building I try to make progress on<br>
   another.<br>
<br>
I don't use HLS so I may be insulated from some of the pain in this<br>
regard. However, I do know that Matt is a regular user and he<br>
disables most plugins.<br>
<br>
I would also say that, sadly, GHC is comparable to other similarly-size<br>
compilers in its build time: A build of LLVM (not even clang) takes ~50<br>
minutes on my 8-core desktop; impressively, rustc takes ~7 minutes<br>
although it is a considerably smaller compiler (being just a front-end).<br>
By contrast, GHC takes around 20 minutes. I know that this doesn't<br>
make the cost any easier to bear and I would love to bring this number<br>
down, but ultimately there are only so many hours in the day.<br>
<br>
I think one underexplored approach to addressing the build-time problem<br>
is to look not at the full-build time but rather look for common tasks<br>
where we could *avoid* doing a full build (e.g. updating documentation,<br>
typechecking `base`, running a "good enough" subset of the testsuite)<br>
and find ways to make those workflows more efficient.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>