| 19 Feb 2025 |
 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 |
| John Ericson | and then that is kind of a tie breaker event | 01:58:58 |
| John Ericson | that makes it better than the external interpreter | 01:59:08 |
| angerman | Template Haskell is an absolute train wreck. The qemu approach is the one that is the most conservative. Cross splicing under TH conditions is potentially dangerous across architectures. It also assumes you have a build native equivalent for all host libraries. | 02:03:24 |
| angerman | Cross splicing will work most of the time though. | 02:03:48 |
| angerman | It is bound to fail if you build system is 64 bit and target is 32bit and you end up embedding Word sizes and similar. For the JS backend though, I don’t think we use qemu at all. It’s basically still the th runner approach with node. | 02:05:33 |
| angerman | I will note that for android, we have a fairly big PR, that tries to fix a lot of issues. | 02:08:16 |
