Newest at the top
| 2026-02-11 23:29:14 +0100 | <tomsmeding> | or rather, a call to a null pointer |
| 2026-02-11 23:29:06 +0100 | <tomsmeding> | I just realised that in your lldb backtrace, it showed that the crash is not simply a dereference of a null pointer, it's a _jump_ to a null pointer |
| 2026-02-11 23:28:37 +0100 | <perryprog> | I mean, it's all in my .ghcup so it's all stuff I've deleted before |
| 2026-02-11 23:28:26 +0100 | <EvanR> | egyptian filename style |
| 2026-02-11 23:28:00 +0100 | fgarcia | (~lei@user/fgarcia) fgarcia |
| 2026-02-11 23:27:28 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-02-11 23:27:09 +0100 | <perryprog> | ahh okay wasn't sure if that was the case; in that case yes |
| 2026-02-11 23:27:00 +0100 | <tomsmeding> | can you find that file on your machine somewhere? |
| 2026-02-11 23:26:37 +0100 | <tomsmeding> | it's "process" but without vowels; cabal/ghc/something removes vowels from filenames in some situations |
| 2026-02-11 23:25:37 +0100 | <perryprog> | and it's not linked to by ghc or libHSrts |
| 2026-02-11 23:24:33 +0100 | <perryprog> | weird, I can't actually fine what libHSprcss /is/. HLS has some dylib with that in the name but besides that I can't see it anywhere. |
| 2026-02-11 23:24:29 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-11 23:22:09 +0100 | oskarw | (~user@user/oskarw) oskarw |
| 2026-02-11 23:22:08 +0100 | oskarw` | (~user@user/oskarw) (Remote host closed the connection) |
| 2026-02-11 23:20:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-11 23:18:43 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2026-02-11 23:13:45 +0100 | Googulator | (~Googulato@84-236-65-138.pool.digikabel.hu) |
| 2026-02-11 23:13:21 +0100 | Googulator | (~Googulato@84-236-65-138.pool.digikabel.hu) (Quit: Client closed) |
| 2026-02-11 23:09:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-11 23:04:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-11 22:53:41 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-11 22:46:41 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-11 22:45:33 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-02-11 22:44:31 +0100 | oskarw | (~user@user/oskarw) (Ping timeout: 246 seconds) |
| 2026-02-11 22:43:33 +0100 | oskarw` | (~user@user/oskarw) oskarw |
| 2026-02-11 22:42:05 +0100 | <tomsmeding> | the concrete dependency tree including versions can be found in dist-newstyle/cache/plan.json |
| 2026-02-11 22:41:25 +0100 | <perryprog> | it's not two versions of the same project—I haven't been able to get the main project (oama) working at all, but the thing that doesn't work works fine in isolation. (Will try other suggestions soon™) |
| 2026-02-11 22:40:56 +0100 | brioche | (~username@user/brioche) () |
| 2026-02-11 22:40:46 +0100 | <brioche> | :q |
| 2026-02-11 22:40:37 +0100 | <tomsmeding> | perryprog: this is a stupid suggestion, but what about taking your copy of the project that _does_ work, and copying it over the one that doesn't work |
| 2026-02-11 22:40:05 +0100 | <tomsmeding> | s/built-tool/build-tool/ |
| 2026-02-11 22:39:56 +0100 | <tomsmeding> | from skimming the scrollback I feel like this is irrelevant |
| 2026-02-11 22:39:47 +0100 | <tomsmeding> | and cabal freeze does this |
| 2026-02-11 22:39:42 +0100 | <tomsmeding> | in a 'constraints:' clause in cabal.project you can put 'any.' before a package name to apply the constraint to all targets being built, including built-tool dependencies |
| 2026-02-11 22:36:43 +0100 | <EvanR> | I think tomsmeding brought this up recently |
| 2026-02-11 22:36:36 +0100 | <EvanR> | can't that be encoded in the freeze file? |
| 2026-02-11 22:36:05 +0100 | PorfirioAguilar | (~PorfirioA@user/PorfirioAguilar) (Quit: WeeChat 4.1.1) |
| 2026-02-11 22:35:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-11 22:35:31 +0100 | <haskellbridge> | <sm> they're not using the same .dylib |
| 2026-02-11 22:34:38 +0100 | <EvanR> | that there's a working test case elsewhere makes me think it's not the lib |
| 2026-02-11 22:33:18 +0100 | <haskellbridge> | <sm> oh the paste didn't show the path, but the filename might be this ? libHSprcss-1.6.26.1-e81c95d2-ghc9.12.2.dylib. I'm assuming it's not under the project dir |
| 2026-02-11 22:31:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-11 22:31:09 +0100 | <EvanR> | that it's not the project's actual fault |
| 2026-02-11 22:30:59 +0100 | <EvanR> | rebuilding the broken project in a new sandbox seems like it would test sm's theory |
| 2026-02-11 22:30:01 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 244 seconds) |
| 2026-02-11 22:29:19 +0100 | PorfirioAguilar | (~PorfirioA@user/PorfirioAguilar) PorfirioAguilar |
| 2026-02-11 22:27:26 +0100 | <haskellbridge> | <sm> but I think your paste showed the path of it, you could try just deleting those files ? |
| 2026-02-11 22:26:01 +0100 | tromp | (~textual@2001:1c00:3487:1b00:5913:697:5f95:d198) |
| 2026-02-11 22:25:28 +0100 | <haskellbridge> | <sm> I feel there's an out of date build of process somewhere getting used by that particular project (and the package version number may not tell the whole story) |
| 2026-02-11 22:25:11 +0100 | <perryprog> | sm, it just kills ~/.ghcup I think |