| 31 Jan 2025 |
 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 |
| alexfmpe | this gives an attrset that will attempt to build with tests all packages for which we don't build the tests | 12:00:33 |
| alexfmpe | the output of nix-build --keep-going will spit out all the ones who need the tests to stay disabled | 12:01:05 |
| alexfmpe | a bit of sed and grep gives us the complement of that with respect to the original attrset: the ones whose tests can now be enabled | 12:01:57 |
| alexfmpe | removal itself is still O ( n ), but n here is the number of cleanups, not total packages | 12:02:37 |
| alexfmpe | the same mechanism can be used for jailbreak = false, doHaddock = false | 12:03:19 |
| alexfmpe | and, what I realized today, is that we can also use as predicate the comparison with super.${pkg.pname}.version | 12:04:19 |
| alexfmpe | so we should soon (TM) have a mechanism to sweep over and detect obsolete trivial overrides | 12:05:18 |
