| 17 Feb 2025 |
|  @adestice:matrix.org joined the room. | 18:04:23 |
| 18 Feb 2025 |
 lazyLambda | https://input-output-hk.github.io/haskell.nix/tutorials/getting-started#scaffolding
I see this works for cabal.project and stack.yaml, does haskell.nix also work for plain .cabal? | 23:31:41 |
| 19 Feb 2025 |
|  João Moreira changed their profile picture. | 03:29:48 |
 Alex | A message in #haskell:matrix.org has brought microhs to my attention. According to the README, it can be bootstrapped with Hugs so I'm going to try going all the way to building GHC from source. If successful, it could resolve some of our booting woes. | 09:54:08 |
 toonn | I'm pretty sure someone in #bootstrappable @ Libera.Chat said that way lies pain. | 10:06:53 |
| toonn | Don't let that stop you of course. Just expect to have to get your hands dirty to the tune of building multiple intermediate GHCs. | 10:07:44 |
| Alex | It's worth a try ¯\(ツ)/¯ | 10:13:34 |
| Alex | * It's worth a try ¯\_(ツ)_/¯ | 10:13:39 |
| Alex | hugs is marked broken on Darwin.
Apparently, this fork renders it buildable on modern macOS systems.
Maybe the fork's source or its patches could be used to fix the hugs package? | 10:21:03 |
| Alex | MacOS or not, Hugs has regressed on latest master and haskell-updates. It works fine on 24.11. | 11:26:11 |
 linj | Redacted or Malformed Event | 13:04:07 |
| linj | * microhs is itself bootstrappable so probably we do not need hugs in the bootstrap chain https://discourse.haskell.org/t/what-s-needed-to-bootstrap-ghc-with-hugs/6205/43 | 13:04:17 |
| toonn | It's bootstrappable *with* hugs. | 13:08:47 |
| toonn | Otherwise you're relying on GHC to compile Microhs to compile GHC... | 13:09:11 |
| Alex | $ /nix/store/pig9c96ln4z91ds4d37iybvj6jzsghq3-microhs-0.11.7.1/bin/mhs --version
MicroHs, version 0.11.7.1, combinator file version v7.0
$ /nix/store/pig9c96ln4z91ds4d37iybvj6jzsghq3-microhs-0.11.7.1/bin/mcabal --version
MicroCabal 0.5.0.0
Off to a good start.
I'll try building Hadrian next, but if it's too incompatible I'll try 9.4 or older with Make. | 16:30:54 |
| 20 Feb 2025 |
 angerman | In reply to @sternenseemann:systemli.org
yeah, I'm very interested in what hsyl20 is working on / John has been working towards upstream as well. I've been holding out for a long time for something like that to materialize or all the hadrian regressions being fixed. The latter was probably never going to happen. Now the time has come where we can no longer backpin everything to 9.4 where hadrian doesn't agree with us, so I'll have to bite the bullet and figure a way to do this stuff with hadrian for now. Currently trying to find a way to do this without tricking hadrian into using the native logic, though I may just give up and do something similar to installStage1 You seem to have given him the impression that getting rid of Hadrian is nothing anyone wants. | 23:20:16 |
 sterni (he/him) | then something got lost in communication :) | 23:24:23 |
 maralorn | In reply to @angerman:matrix.org
You seem to have given him the impression that getting rid of Hadrian is nothing anyone wants. Whoever got that impression must have caught weird glimpses of sterni. I can assure that sterni complains about hadrian a lot. | 23:24:41 |
| sterni (he/him) | angerman: I felt like this was the most valuable immediate feedback I could give at the time since I assumed this was probably something people that aren't packaging GHC wouldn't immediately think about. Though, on reflection, it was maybe worded too strongly: Even if cabal-install is annoying to bootstrap; if the new build system is simpler, easier to change and has less undercooked areas it'd be much better than hadrian. | 23:28:55 |
| sterni (he/him) | I still want to look at the actual implementation to figure out how bespoke the usage of cabal-install is | 23:30:43 |
| angerman | I'm being faced with "why are we doing this even? Hadrian is working perfectly fine, no one (link to issue) wants this". | 23:37:51 |
| angerman | 😅 | 23:38:00 |
| angerman | Untangling this mess of ghc and hadrian's symbiotic relationship should result in (a) better separation of conerns. (b) better cabal-install. I do not say we will not need to make cabal-install better, of course we do, but let's stop sinking time into hadrian, that could be used to improve cabal for everyone, not jsut some bespoke build system for GHC, which is also very atrocious. | 23:39:46 |
| 21 Feb 2025 |
 alexfmpe | angerman: sterni with https://github.com/NixOS/nixpkgs/pull/383528 possibly being the last step in the nixpkgs-js-backend track, I'm thinking about messing with mobile soon
I ran into the TH issue before on https://github.com/NixOS/nixpkgs/pull/355543 and am wondering how to address that | 01:50:37 |
| alexfmpe | IIUC haskell.nix does target TH via qemu | 01:50:49 |
| alexfmpe | whereas reflex-platform, even in its haskell.nix based rewrite, does host TH with some splices plugin or something | 01:51:38 |
| alexfmpe | I'd like to get at least one of them in nixpkgs, but don't know how they compare | 01:52:37 |
| alexfmpe | cc John Ericson | 01:53:51 |
 John Ericson | alexfmpe: IMO if the staging iports things lands | 01:58:35 |
| John Ericson | the non-jank version of obsidian's splicing patch becomes possible | 01:58:45 |
