| 30 Jan 2025 |
 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 |
| Alex | ("RTS ways","debug thr thr_debug thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p debug_p")
| 22:42:08 |
| sterni (he/him) | the problem is that the settings in common-hadrian.nix and generic-builder.nix are out of sync | 22:42:17 |
| sterni (he/him) | we should probably expose this information from GHC somehow and reuse in mkDerivation | 22:42:36 |
| Alex | Oh, so I should disable all profiling builds? Let me try that (bonus: near 2x speedup for builds). | 22:42:47 |
| 3 Feb 2025 |
| Alex | Yep, that worked. Thanks for the help. | 01:17:05 |
 MangoIV | PSA:
The registrations for ZuriHac 2025 are open.
https://zurihac.info | 06:32:52 |
|  vhash joined the room. | 08:48:30 |
 alexfmpe | maralorn: sterni about the whole warn-about-override-when-we-catch-up vs flood-logs-with-warnings dilemma: I wouldn't worry about the magnitude of it much either way
for the specific reflex-dom PR, I have strong local incentives to keep that stuff building out of up-to-date nixpkgs (e.g. using nixos.org binary cache and also getting vuln scans green)
for the general case, I've actually been tinkering with a way to automatically detect unused overrides, but waiting till we get back to minor LTS bump cycle to start actually using it
this ought to be O ( 1 ) human time, even if high latency (run it overnight variety) | 11:58:43 |
| alexfmpe | taking dontCheck as an example:
I have a .nix file that filters haskellPackages and filters for all derivations with doCheck = false, then doCheck = true for all of them | 12:00:05 |
