| 30 Jan 2025 |
 maralorn | What surprises me slightly from this picture is that I always hammer in the point that HLS needs to be compiled with the same GHC which is used to build the project. But now it seems to me like we are not doing that because HLS is linked againts GHC stage 3, while the project is being compiled by ghc stage 2? | 22:24:31 |
| maralorn | I am not actually saying that this is a reductio ad absurdum I just want to spell it out, that I was missing the full picture before and trying to get my understanding precise. | 22:25:41 |
 Teo (he/him) | In reply to @maralorn:maralorn.de
Only solution would be if we could build ghc the library as a normal Cabal package at least in stage 3? Afaik this is possible and there's a job in the GHC CI that ensures this using this code: https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/src/Rules/CabalReinstall.hs | 22:26:36 |
| maralorn | sterni: Does what I am writing match your understanding? (or at least not contradict it?) | 22:45:49 |
 sterni (he/him) | I'd need to think through it myself honestly | 22:46:48 |
| sterni (he/him) | in any case see also https://gitlab.haskell.org/ghc/ghc/-/tree/master/hadrian?ref_type=heads#staged-compilation | 22:47:00 |
| sterni (he/him) | no I think the packages in a stage are linked against its siblings so the ghc executable and library are just stage2 (i.e. built using stage1) | 22:57:30 |
| sterni (he/him) | default setting of hadrian is to stop after stage2 has been built (i.e. all stage2Packages have been built using stage1). | 22:57:55 |
| maralorn | Okay. So we compile everything with ghc stage 2 but link it against boot packages built in stage 1? And especially we build with ghc stage 2 and link against ghc stage 2. | 22:59:13 |
| sterni (he/him) | hmm though what I'm saying doesn't quite match the picture they have in the readme | 22:59:53 |
| sterni (he/him) | I honestly don't know I'd probably need to take a few days to read the code or idk find a way to dump the build graph from shake | 23:00:17 |
| sterni (he/him) | unfortunately hadrian is magic to a degree because it can sort of load cabal packages so the dependency plumbing is not very explicit | 23:00:57 |
| sterni (he/him) | you can probably make a rube goldberg machine where you have a derivation for just ghc, one for haddock etc., but this stuff really hasn't been designed for that, so who knows how many problems you run into | 23:02:40 |
| sterni (he/him) | I suspect you can get hadrian to do it, but configure won't like all the missing dependencies (for targets you don't want to build) | 23:03:38 |
| maralorn | I really like the metaphor of nix builds as rube goldberg machines. My I can design an alternative visualisation for nom from that. š | 23:09:19 |
| 31 Jan 2025 |
 Alex | In reply to @sternenseemann:systemli.org
default setting of hadrian is to stop after stage2 has been built (i.e. all stage2Packages have been built using stage1). This makes sense, as there's no real benefit to using stage2 over stage1 to build packages outside of build time, which already needs to be spent to build stage2 dependencies.
(If we use version A to boot a version B build, stage1 is built by A and outputs programs built by B, so packages built by it have all of B's performance improvements.) | 08:08:19 |
| maralorn | * I really like the metaphor of nix builds as rube goldberg machines. Maybe I can design an alternative visualisation for nom from that. š | 08:59:47 |
| maralorn | Alex: You mean the results of the stage 1 and the stage 2 compiler are basically identical, stage 2 just compiles faster? | 09:02:30 |
| Alex | Yes | 09:18:54 |
| maralorn | Well, I guess this means whenever you link against ghc everything in the dependency closure of ghc is locked. | 09:23:26 |
 Profpatsch | maralorn: Iād say nix builds are the opposite of RG machines | 10:47:18 |
| Profpatsch | RG machinesā primary idea is that every transition is kinda wonky and actually running it to completion will require many tries with temporary adjustments in between steps | 10:48:01 |
| Profpatsch | i.e. āI canāt believe it actually worked this time, probabyl the only time thoughā vs āI canāt believe it works now, but at least itās gonna stay workingā | 10:48:38 |
| Profpatsch | okay enough philosophical ramble lol | 10:49:04 |
| Profpatsch | In a way, the final product of a RG machine is the video of it running through once :P | 10:49:33 |
| 1 Feb 2025 |
|  myhlamaeus joined the room. | 18:17:44 |
| 2 Feb 2025 |
 hellwolf | https://x.com/ndm_haskell/status/1886165769152512146 | 22:02:22 |
| hellwolf | well, hlint problem will go away, soon. | 22:02:47 |
| Alex | [12 of 16] Compiling Language.Haskell.HsColour.Output ( Language/Haskell/HsColour/Output.hs, dist/build/Language/Haskell/HsColour/Output.p_o )
Language/Haskell/HsColour/Output.hs:1:8: error:
Could not find module āPreludeā
Perhaps you haven't installed the profiling libraries for package ābase-4.18.2.1ā?
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
1 | module Language.Haskell.HsColour.Output(TerminalType(..),Output(..)) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, this error is extremely weird considering that other packages and modules compile just fine.
Has anyone seen this before? Does anyone understand why it could be happening?
(Building on RISC-V.) | 22:35:33 |
| sterni (he/him) | Alex: libaries built with profiling, ghc without (due to size constraints on riscv64) | 22:41:55 |
