Newest at the top
| 2026-02-11 19:16:10 +0100 | <tomsmeding> | if that's the problem that still points to a bug in ghc/rts/`process`/whatever, but it's worth trying |
| 2026-02-11 19:15:44 +0100 | <perryprog> | me too sm |
| 2026-02-11 19:15:32 +0100 | <haskellbridge> | <sm> I suspect it was installed before a macos upgrade, maybe |
| 2026-02-11 19:15:30 +0100 | <tomsmeding> | (the ~/.cabal/store nuke can be more targeted by only removing the relevant directory inside) |
| 2026-02-11 19:15:08 +0100 | prdak1 | prdak |
| 2026-02-11 19:15:06 +0100 | <tomsmeding> | (because 'process' may well from from the bootlibs distributed with GHC) |
| 2026-02-11 19:14:51 +0100 | <tomsmeding> | at that point `rm -rf ~/.cabal/store`, and uninstall the relevant GHC, then reinstall the relevant GHC with ghcup and rebuild |
| 2026-02-11 19:14:11 +0100 | <haskellbridge> | <sm> claude says it's the process library's posix_spawn wrapper crashing when GHC tries to shell out to an external tool during compilation, and suggests to force a rebuild or upgrade of that package |
| 2026-02-11 19:13:54 +0100 | <perryprog> | eh fair |
| 2026-02-11 19:13:44 +0100 | <tomsmeding> | it would be rather stupid and unlike the GHC RTS developers to do something like that (if it's that simple), but who knows |
| 2026-02-11 19:13:20 +0100 | <tomsmeding> | well, it's a null pointer dereference; who knows, perhaps the GHC RTS assumes that some file will be present, opens it, receives NULL, then proceeds to read from that? |
| 2026-02-11 19:12:50 +0100 | prdak1 | (~Thunderbi@user/prdak) prdak |
| 2026-02-11 19:12:40 +0100 | <perryprog> | sm, nah, it's an address boundary error, so almost definitely not. And thank you for your help! |
| 2026-02-11 19:12:39 +0100 | prdak | (~Thunderbi@user/prdak) (Read error: Connection reset by peer) |
| 2026-02-11 19:12:22 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-02-11 19:12:02 +0100 | <haskellbridge> | <sm> could it be a mac permissions issue, like your terminal doesn't have full disk access or something ? |
| 2026-02-11 19:12:00 +0100 | <tomsmeding> | sm: SIGSEGV when running TH sounds like a GHC / platform toolchain problem, not a cabal problem, but I can't know for sure |
| 2026-02-11 19:11:55 +0100 | <haskellbridge> | <sm> ok. That's too much work :) |
| 2026-02-11 19:11:53 +0100 | <perryprog> | well I have to figure out the cause out of spite now, surely :) |
| 2026-02-11 19:11:35 +0100 | <tomsmeding> | but this may also give you enough to devise a workaround if you just want oama to work |
| 2026-02-11 19:11:31 +0100 | <haskellbridge> | <sm> it might be an issue known to cabal devs |
| 2026-02-11 19:11:11 +0100 | <tomsmeding> | if you want to debug this, then my first suggestion would be to see if _any_ TH at all works -- i.e. `cabal new`, add some TH, build it |
| 2026-02-11 19:10:49 +0100 | <perryprog> | this was my first time updating it in a while |
| 2026-02-11 19:10:43 +0100 | <perryprog> | that checks out |
| 2026-02-11 19:10:38 +0100 | <tomsmeding> | ok then there's definitely something off either with GHC or with your installation |
| 2026-02-11 19:10:27 +0100 | <perryprog> | removing that fixes it |
| 2026-02-11 19:10:21 +0100 | <perryprog> | hahaha tomsmeding you're correct |
| 2026-02-11 19:10:18 +0100 | <yahb2> | --version ; ExitSuccess |
| 2026-02-11 19:10:18 +0100 | <tomsmeding> | % System.Process.system "echo --version" |
| 2026-02-11 19:09:22 +0100 | <perryprog> | sm, xcode-select --version is a prank, that's just the installer's version. If you have xcode installed you can open it > preferences > components > then whatever's under platform support |
| 2026-02-11 19:09:06 +0100 | <tomsmeding> | definitely try removing the TH from that module |
| 2026-02-11 19:09:05 +0100 | tureba | (tureba@tureba.org) tureba |
| 2026-02-11 19:09:01 +0100 | <tomsmeding> | that runInteractiveProcess, in combination with the TH, makes me suspect external-interpreter somehow |
| 2026-02-11 19:08:48 +0100 | tureba | (tureba@tureba.org) (Server closed connection) |
| 2026-02-11 19:08:31 +0100 | <tomsmeding> | (oh actually, just one usage of TH) |
| 2026-02-11 19:08:22 +0100 | <perryprog> | got an lldb backtrace: https://paste.tomsmeding.com/eDJZhqvX |
| 2026-02-11 19:08:20 +0100 | <haskellbridge> | <sm> macos 26.2, xcode-select version 2416. |
| 2026-02-11 19:08:12 +0100 | <tomsmeding> | perryprog: regardless of whether you submit a bug report to GHC or not, it might be worth minimising a little; there's a bunch of TemplateHaskell in the failing file, what if you remove all of that? |
| 2026-02-11 19:05:18 +0100 | <perryprog> | and I still failed to build with 9.12.1 :( |
| 2026-02-11 19:04:34 +0100 | <perryprog> | hmmm. What version of xcode command line tools and what macOS version? |
| 2026-02-11 19:03:53 +0100 | <haskellbridge> | <sm> ok, not so bad the second time |
| 2026-02-11 19:03:14 +0100 | <haskellbridge> | <sm> that module 6 did take an unusually long time |
| 2026-02-11 19:02:52 +0100 | <haskellbridge> | <sm> it built normally for me with cabal 3.16.1.0 and ghc 9.12.2, on mac |
| 2026-02-11 18:59:21 +0100 | <haskellbridge> | <sm> stack version doesn't matter much, no |
| 2026-02-11 18:58:21 +0100 | <perryprog> | my stack version /shouldn't/ matter if it's just a cabal project, right?? |
| 2026-02-11 18:57:43 +0100 | <perryprog> | failed on cabal 3.14.2.0 |
| 2026-02-11 18:56:50 +0100 | haskellbridge | sm tries 9.12.2 on mac |
| 2026-02-11 18:56:30 +0100 | <geekosaur> | in case a GC bug crept into .2 |
| 2026-02-11 18:56:27 +0100 | sord937_ | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937_) |
| 2026-02-11 18:56:15 +0100 | <geekosaur> | might still be worth trying 9.12.1 |