Newest at the top
| 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 |
| 2026-02-11 22:23:53 +0100 | <haskellbridge> | <maerwald> No, it doesn't delete ghc or cabal dirs |
| 2026-02-11 22:23:27 +0100 | <int-e> | LOL, https://github.com/haskell/ghcup-hs/blob/master/lib-opt/GHCup/OptParse/Nuke.hs#L78 |
| 2026-02-11 22:23:17 +0100 | confusedalex | (~confuseda@user/confusedalex) confusedalex |
| 2026-02-11 22:21:57 +0100 | housemate | (~housemate@202.7.248.67) housemate |
| 2026-02-11 22:21:16 +0100 | <haskellbridge> | <sm> there's nuke and there's NUKE FROM ORBIT |
| 2026-02-11 22:20:41 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-11 22:19:19 +0100 | <haskellbridge> | <sm> I don't know what that does, did it remove your ~/.ghc, ~/.cabal, all haskell tools from PATH etc ? |
| 2026-02-11 22:17:47 +0100 | <perryprog> | I did ghcup nuke |
| 2026-02-11 22:17:36 +0100 | <haskellbridge> | <sm> perryprog what did you nuke ? |
| 2026-02-11 22:17:22 +0100 | housemate | (~housemate@202.7.248.67) (Quit: https://ineedsomeacidtocalmmedown.space/) |
| 2026-02-11 22:15:56 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-11 22:14:25 +0100 | confusedalex | (~confuseda@user/confusedalex) (Ping timeout: 264 seconds) |
| 2026-02-11 22:10:55 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-02-11 22:07:55 +0100 | tromp | (~textual@2001:1c00:3487:1b00:5913:697:5f95:d198) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-02-11 22:06:55 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-02-11 22:06:29 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2026-02-11 22:05:44 +0100 | califax | (~califax@user/califx) califx |
| 2026-02-11 22:05:28 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2026-02-11 22:04:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-02-11 22:01:54 +0100 | <brioche> | I could do this by disabling close_fds in CreateProcess, but I don't want the other FDs to stay open. I just want to keep a specific list of FDs open. |
| 2026-02-11 22:00:33 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-11 22:00:18 +0100 | <brioche> | Yeah, a pipe for example |
| 2026-02-11 21:58:41 +0100 | <EvanR> | the other FDs? |
| 2026-02-11 21:57:11 +0100 | Googulator54 | Googulator |
| 2026-02-11 21:55:56 +0100 | <brioche> | I know that createProcess allows to specify a stdin, stdout and stderr FDs, but what about the other FDs? |