GHC 9.10.1-alpha3 is now available

Announcements
#41

I guess I would like to get to point where basically current ghc9 would correspond to Stackage LTS and ghc10 to Nightly.

Well I guess forward-looking I really mean: ghc10 would be stable (ie the same Stackage LTS major version could use GHC 10.1, 10.2, 10.3, 10.4,… minor versions). Whereas GHC nightly might live in Stackage “experimental” (nightly) say.

This would require a complete change of versioning and releases of course. New features could be gradually backported as needed/desired to stable releases if they don’t break stable GHC.

In the ideal stable world, ghc10 would then be the last final stable major version of GHC (à la rust 1) ever.

#42

Nightlies as they they were promised to exist have been consistently available for the last 6 months. (see here).

I don’t think it’s very helpful language to label them as a “failure”. It’s more of a difference in opinion between @hasufell and GHC developers about the level of resources to invest in their production. There doesn’t seem to have been very much uptake in using nightlies so it is difficult to justify further investment in improving the infrastructure around them.

#43

Promised where/by whom?

This design document from the HF talks about indefinite bindist retention and predictable URLs in the requirements section. Neither of that is the case at the moment.

Also, looking at the availabilty stats of nightlies: https://grafana.gitlab.haskell.org/d/ab109e66-a8a1-4ae9-b976-40e2dfe281ab/availability-of-ghc-nightlies-via-ghcup?orgId=2&refresh=1d

Half of the time, nightlies are stale (not produced for a given day). Mainly because of architectural issues with CI (divergence of validate and nightly pipelines), which is still not fixed: #23601: ghcup-metadata: In nightly pipelines, still generate the metadata even if some of the jobs fail · Issues · Glasgow Haskell Compiler / GHC · GitLab

#44

As I repeatedly explained to you privately Julian, the nightlies were only ever promised to be provided on a best-effort basis by exposing what already existed as part of nightly pipelines to users. The document you link clearly says at the top that it’s not the final plan. The expectations about availability are documented on the GHC Wiki.

In retrospect it seems that it would have been much better to not engage with this project at all.

#45

Maybe we should move away from the subject of the nightlies since it is clearly touching some raw nerves.

2 Likes
#46

Thank you for this build, I suppose it should be used with cabal-install-3.12 prerelease which supports js-sources. It seems like I can find a build plan for miso using the following command line for the sample-app (from inside the miso repo).

It does seem like “latest” is not correct, since the GHC build is for a specific version of Emscripten, and not the latest.

cabal build --with-ghc=javascript-unknown-ghcjs-ghc \
--with-ghc-pkg=javascript-unknown-ghcjs-ghc-pkg \
--allow-newer=servant:base,vault:base,singleton-bool:base \
--allow-newer=jsaddle:lens \
--allow-newer=lucid:base \
--allow-newer=http-api-data:base \
-c 'singleton-bool>=0.1.7' -c 'servant>=0.20.1' -c 'miso>=1.8.4' \
-c 'aeson>=2.2.2.0' -c 'dec>=0.0.6' -c 'boring>=0.2.2'

The reference to aeson-2.2.3.0 is from Support GHC-8.6.5..9.10.1 by phadej · Pull Request #1097 · haskell/aeson · GitHub

#47

Yes, that should be printed before installation:

So for javascript-unknown-ghcjs-9.10.0.20240413 you need emscripten 3.1.57.

1 Like