| 29 Jan 2025 |
 sterni (he/him) | except for when we need them | 20:44:54 |
 maralorn | Still sounds less predictable than just using them. | 20:45:27 |
| sterni (he/him) | I mean we could try and see what happens if we reinstall the reinstallable packages | 20:45:55 |
| maralorn | I’d say we should do that if we can get away with it. But of course that’s work and I don’t know if it would work. | 20:46:04 |
| sterni (he/him) | but I suspect it's a real nightmare with anything that links against GHC | 20:46:08 |
| maralorn | That’s a good point. | 20:46:26 |
| maralorn | How does that even?^^ | 20:46:42 |
| maralorn | Like with which stage are boot packages compiled? | 20:46:56 |
| maralorn | I mean ghc the lib cannot be compiled by itself of the same stage, right?^^ | 20:47:22 |
 hellwolf | In reply to @maralorn:maralorn.de
As always I have to ask: Why built hlint with ghc910? hlint will work perfectly fine when compiled with older ghcs. If you need support for new syntax the relevant version is that of ghc-lib-parser. some extensions are 9.10+, hlint wouldn't support it. | 20:48:01 |
| hellwolf | * some extensions are 9.10+, hlint built for other version of ghc wouldn't support it. | 20:48:19 |
| hellwolf | that's my understanding | 20:48:23 |
| hellwolf | * some extensions are 9.10+, hlint built for other version of ghc libs wouldn't support it. | 20:48:31 |
| maralorn | Yeah, true. | 20:48:59 |
| hellwolf | And I'm not shy away from using the latest the greatest... so | 20:51:40 |
| hellwolf | but I circumvented and avoided TypeaAbstractions in functions (a ghc9.10 addition) for now | 20:52:42 |
| maralorn | Or is that some kind of fix point where we link a lib compiled with ghc stage-n directly against the lib ghc stage-n? | 20:53:18 |
| maralorn | Oh, boy, why do I know so little about this. 😄 | 20:53:31 |
| maralorn | Really looking forward to using that one. | 20:53:50 |
 Teo (he/him) | In reply to @maralorn:maralorn.de
Or is that some kind of fix point where we link a lib compiled with ghc stage-n directly against the lib ghc stage-n? Iirc stage-2 GHC links against libraries built by stage1 GHC, but that's OK because they are practically the same anyway | 21:58:11 |
| Teo (he/him) | There's this explanation in the Hadrian docs but even with that it's still quite confusing https://gitlab.haskell.org/ghc/ghc/-/tree/master/hadrian#staged-compilation | 22:01:25 |
| maralorn | Ah, thanks that actually helps me. | 22:16:28 |
| maralorn | So even "reinstallable" dependencies of ghc cannot actually be reinstalled when used together with ghc? Because ghc stage 2 is linked with mtl stage 1 and thus will collide with mtl stage 2? | 22:19:49 |
| sterni (he/him) | Not sure you'll have to look at the package db entries i guess | 22:34:37 |
| sterni (he/him) | every package that is part of stage1 will also be built in stage2 | 22:34:54 |
| Teo (he/him) | I don't understand it fully but "reinstallability" is mostly a constraint imposed by cabal rather than GHC see mpickering's comments here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13297 | 23:30:51 |
| 30 Jan 2025 |
|  laurynasp joined the room. | 08:59:05 |
|  sem joined the room. | 21:56:33 |
| sterni (he/him) | same difference, really | 22:14:04 |
| sterni (he/him) | it doesn't really matter when practically all software is built using cabal | 22:14:22 |
