Newest at the top
| 2025-01-08 19:16:19 +0100 | plitter | (~plitter@user/plitter) (Ping timeout: 264 seconds) |
| 2025-01-08 19:14:08 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-01-08 19:05:30 +0100 | sprotte24 | (~sprotte24@p200300d16f1e660091235e642331973a.dip0.t-ipconnect.de) |
| 2025-01-08 19:03:47 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) |
| 2025-01-08 18:58:43 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-01-08 18:49:54 +0100 | <int-e> | But also because the ghc-pkg wrapper script sets a bunch of paths that are hard to figure out otherwise. |
| 2025-01-08 18:49:07 +0100 | <int-e> | geekosaur: I guess partly because the Cabal versions used may be different. |
| 2025-01-08 18:48:19 +0100 | <int-e> | geekosaur: I don't think that's correct. Yes, ghc-pkg uses (parts of) the Cabal library. But it's still invoked by Cabal or at least cabal-install anyway. |
| 2025-01-08 18:47:48 +0100 | <int-e> | There's also some baked-in paths here: ghc --print-global-package-db |
| 2025-01-08 18:45:41 +0100 | <hseg> | OK, I don't quite follow, but that's as deep as I can afford to go down this rabbit hole right now |
| 2025-01-08 18:43:22 +0100 | <geekosaur> | that si, ghc-pkg is a wrapper around the Cabal library's package db management |
| 2025-01-08 18:43:00 +0100 | <geekosaur> | that said, it does not use ghc-pkg because it *is* ghc-pkg |
| 2025-01-08 18:42:54 +0100 | <int-e> | well using System.Process |
| 2025-01-08 18:42:47 +0100 | <geekosaur> | it runs a lot of external programs, actually |
| 2025-01-08 18:42:06 +0100 | <hseg> | what, with system("ghc-pkg ...")? I doubt that |
| 2025-01-08 18:41:32 +0100 | <int-e> | I'm pretty sure the Cabal library interrogates ghc-pkg too. |
| 2025-01-08 18:40:56 +0100 | <hseg> | cabal-plan needs to be able to find the Cabal store |
| 2025-01-08 18:40:43 +0100 | <hseg> | no, I meant from within haskell source |
| 2025-01-08 18:40:43 +0100 | <geekosaur> | if you want the file, ghc --print-global-package-db |
| 2025-01-08 18:40:16 +0100 | <int-e> | run ghc-pkg and parse the output programmatically. --simple-output helps with that |
| 2025-01-08 18:39:53 +0100 | homo_ | homo |
| 2025-01-08 18:38:24 +0100 | <hseg> | ? |
| 2025-01-08 18:38:22 +0100 | <hseg> | any way of getting that location programmatically |
| 2025-01-08 18:38:05 +0100 | <hseg> | answer: ghc-pkg list ghc |
| 2025-01-08 18:37:00 +0100 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 252 seconds) |
| 2025-01-08 18:36:35 +0100 | <hseg> | which is where? |
| 2025-01-08 18:36:06 +0100 | <geekosaur> | you will find it in the package.conf for the "ghc" package, since that's the closest we currentlhy get to an ABI for a full GHC install |
| 2025-01-08 18:36:03 +0100 | <hseg> | how is one supposed to find that store, then? |
| 2025-01-08 18:35:46 +0100 | <hseg> | ah. OK, making a symlink there works, but I've reported this upstream to cabal-plan |
| 2025-01-08 18:35:18 +0100 | <geekosaur> | yes |
| 2025-01-08 18:32:28 +0100 | <hseg> | Oh? Wait, is that c895 a truncated hash? |
| 2025-01-08 18:30:21 +0100 | <geekosaur> | the store is very sensitive to ghc abi |
| 2025-01-08 18:30:12 +0100 | <geekosaur> | because that's the correct thing to do but wasn't possible in earlier versions |
| 2025-01-08 18:29:20 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-01-08 18:28:53 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2025-01-08 18:27:00 +0100 | jokoon | (~jokoon@2a01:cb1d:8f84:4f00:60a2:6701:a66e:bb95) (Quit: Leaving) |
| 2025-01-08 18:26:21 +0100 | <hseg> | For some reason, ghcup's ghc 9.8.4 compiles to store the Cabal store under ghc-9.8.4-c895 Any idea why? |
| 2025-01-08 18:17:42 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-01-08 18:13:35 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2025-01-08 18:11:31 +0100 | homo_ | (~homo@user/homo) homo |
| 2025-01-08 18:07:17 +0100 | homo | (~homo@user/homo) (Ping timeout: 252 seconds) |
| 2025-01-08 18:02:17 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:13a7:b05b:d8a6:72f8) (Quit: ubert) |
| 2025-01-08 17:57:16 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 17:57:01 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-08 17:55:07 +0100 | homo | (~homo@user/homo) homo |
| 2025-01-08 17:53:32 +0100 | <int-e> | does it involve giving |
| 2025-01-08 17:53:18 +0100 | <mauke> | <insert nsfw joke here> |
| 2025-01-08 17:53:07 +0100 | <int-e> | . o O ( or a good approximation thereof ) |
| 2025-01-08 17:51:46 +0100 | <tomsmeding> | much as I am usually condescending about the abilities of LLMs, I'm quite sure it can generate the source for `head`. :) |
| 2025-01-08 17:51:41 +0100 | saulosilva | (~saulosilv@181.216.220.21) saulosilva |