(re-sending with replay-all this time)
Hi Simon, thank you for your concern.
Regarding the compiler compilation:
I often have to re-run ./configure and ./boot between development
phases (usually spaced by one or two weeks), which prevents me
from benefiting from `--freeze1` from the get-go.
The flavour I use is `Quick`, as it is advertised on https://ghc.dev.
The technique I use now is to restrict the `-j` parameter to 1 or
2. I can go above for night builds, but if I want to keep my
system usable, this is how it goes.
This takes 47m07s according to Hadrian.
Moreover, modern computers have a BIOS setting that shuts down the
computer when the temperature is too high (between 70°C and 100°C
I believe). I ended up upping this limit in my BIOS some time ago,
but I wish I didn't need to.
(and yes I do frequently remove the dust ;)
Regarding documentation contribution,
The time it takes to run `hadrian/build -j
--flavour=Quick` *plus* `hadrian/build
-j2 --freeze1 --flavour=Quick docs --docs=no-sphinx-pdfs
` in order to render the haddocks is way too high for occasional
contributors.
I started a process while writing this email, in order to get
fresh and accurate numbers, and here is what I got in return:
juil. 19 19:37:21 elatha systemd[1759]:
app-kitty-dedaa3d5a1ee43dd8b2552b7afd53cd5.scope: systemd-oomd
killed 36 process(es) in this unit.
juil. 19 19:37:21 elatha systemd-oomd[682429]: Killed
/user.slice/user-1000.slice/user@1000.service/app.slice/app-kitty-dedaa3d5a1ee43dd8b2552b7afd53cd5.scope
due to memory used (16192806912) / total (16358338560) and swap
used (8102125568) / total (8589930496) being more than 90.00%
Now regarding HLS, I remember that a point of marketing for it is
that it supports GHC. Considering the very skilled people who hold
the wheel of HLS development, my first (nor second) reflex isn't
to doubt them. So yes I believe I must disable HLS when working on
GHC, but then how do we spread this kind of information /
work-around while at the same time saying "but HLS is still
reliable, pinky swear, it's just that it doesn't scale".
That's bad Hecate. We need GHC to be fun to work with, not a pain.
Can you be (much) more specific? The more concrete the problem, the more likely we can address it.
e.g. What if you don't use HLS? Or maybe Hadrian is building much more than you need? It would be super helpful to have more information. There may be things we can't reasonably address (e.g. make a small, light, non-optimising compiler instead, throwing away most of the code base) but I bet that sheer size isn't the only factor.
Thanks!
Simon
On Tue, 19 Jul 2022 at 17:21, Hécate <hecate@glitchbra.in> wrote:
Hello ghc-devs,
I hadn't made significant contributions to the GHC code base in a while,
until a few days ago, where I discovered that my computer wasn't able to
sustain running the test suite, nor handle HLS well.
Whether it is my OS automatically killing the process due to oom-killer
or just the fact that I don't have a war machine, I find it too bad and
I'm frankly discouraged.
This is not the first time such feedback emerges, as the documentation
task force for the base library was unable to properly onboard some
people from third-world countries who do not have access to hardware
we'd consider "standard" in western Europe or some parts of North
America. Or at least "standard" until even my standard stuff didn't cut
it anymore.
So yeah, I'll stay around but I'm afraid I'm going to have to focus on
projects for which the feedback loop is not on the scale of hours , as
this is a hobby project.
Hope this will open some eyes.
Cheers,
Hécate
--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD