| 2025-12-11 00:04:02 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-12-11 00:04:31 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-11 00:08:10 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-11 00:13:54 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-11 00:18:51 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-12-11 00:30:25 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-11 00:31:55 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-11 00:33:35 +0100 | tromp | (~textual@2001:1c00:3487:1b00:fc9c:738b:219c:bafe) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 00:33:37 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2025-12-11 00:42:35 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) (Ping timeout: 240 seconds) |
| 2025-12-11 00:44:15 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb!) |
| 2025-12-11 00:45:16 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Read error: Connection reset by peer) |
| 2025-12-11 00:45:18 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-11 00:46:06 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-11 00:47:02 +0100 | jmcantrell_ | jmcantrell |
| 2025-12-11 00:47:30 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-12-11 00:51:52 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2025-12-11 00:52:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 00:56:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 01:07:09 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Read error: Connection reset by peer) |
| 2025-12-11 01:08:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 01:12:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 01:15:08 +0100 | pabs3 | (~pabs3@user/pabs3) (Read error: Connection reset by peer) |
| 2025-12-11 01:16:00 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-12-11 01:23:04 +0100 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-12-11 01:23:11 +0100 | p3n_ | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) |
| 2025-12-11 01:23:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 01:28:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-11 01:33:09 +0100 | Sgeo__ | (~Sgeo@user/sgeo) Sgeo |
| 2025-12-11 01:34:31 +0100 | ycp | (~znc@user/dragestil) (Ping timeout: 244 seconds) |
| 2025-12-11 01:35:14 +0100 | ycp | (~znc@user/dragestil) dragestil |
| 2025-12-11 01:36:04 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Ping timeout: 244 seconds) |
| 2025-12-11 01:39:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 01:40:49 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 01:41:02 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 01:41:58 +0100 | larsivi | (~larsivi@user/larsivi) (Ping timeout: 246 seconds) |
| 2025-12-11 01:44:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 01:47:55 +0100 | Raito_Bezarius | (~Raito@libera/contributor/wireguard.tunneler.raito-bezarius) (Ping timeout: 246 seconds) |
| 2025-12-11 01:48:27 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 01:51:04 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 01:55:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 01:59:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-11 02:02:28 +0100 | Raito_Bezarius | (~Raito@libera/contributor/wireguard.tunneler.raito-bezarius) Raito_Bezarius |
| 2025-12-11 02:05:04 +0100 | jle` | (~jle`@2603:8001:3b00:11:ed74:b35d:c320:7e16) (Ping timeout: 246 seconds) |
| 2025-12-11 02:05:59 +0100 | jle` | (~jle`@2603:8001:3b00:11:a23f:f454:6842:2ec4) jle` |
| 2025-12-11 02:09:09 +0100 | hsw | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) (Quit: Leaving) |
| 2025-12-11 02:09:16 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9fc6:fc26:b514:683b) (Ping timeout: 246 seconds) |
| 2025-12-11 02:10:17 +0100 | Tuplanolla | (~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-12-11 02:10:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 02:15:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 02:19:20 +0100 | larsivi | (~larsivi@user/larsivi) larsivi |
| 2025-12-11 02:24:46 +0100 | divlamir_ | (~divlamir@user/divlamir) divlamir |
| 2025-12-11 02:24:50 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2025-12-11 02:25:38 +0100 | divlamir_ | divlamir |
| 2025-12-11 02:26:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 02:26:25 +0100 | acidjnk | (~acidjnk@p200300d6e717192391252480cf04477b.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-12-11 02:28:08 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:327d:b50f:5899:99de) |
| 2025-12-11 02:30:27 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 02:30:40 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 02:31:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-11 02:32:46 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-11 02:34:29 +0100 | omidmash5 | (~omidmash@user/omidmash) omidmash |
| 2025-12-11 02:36:31 +0100 | omidmash | (~omidmash@user/omidmash) (Ping timeout: 244 seconds) |
| 2025-12-11 02:36:31 +0100 | omidmash5 | omidmash |
| 2025-12-11 02:40:46 +0100 | trickard_ | trickard |
| 2025-12-11 02:42:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 02:43:38 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-11 02:45:22 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2025-12-11 02:45:38 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2025-12-11 02:46:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-11 02:49:31 +0100 | timide | (~timide@user/timide) (Ping timeout: 246 seconds) |
| 2025-12-11 02:49:53 +0100 | sp1ff` | (~user@2601:1c2:4c00:6820::c593) (Remote host closed the connection) |
| 2025-12-11 02:55:08 +0100 | ephemient | (uid407513@user/ephemient) (Quit: Connection closed for inactivity) |
| 2025-12-11 02:58:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 02:58:32 +0100 | timide | (~timide@user/timide) timide |
| 2025-12-11 03:01:21 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-12-11 03:02:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 03:05:00 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:327d:b50f:5899:99de) (Remote host closed the connection) |
| 2025-12-11 03:08:19 +0100 | <Pozyomka> | Why is does XMonad.keys have type “XConfig l -> XConfig Layout -> Data.Map.Internal.Map (ButtonMask, KeySym) (X ())”? The first XConfig, I can understand, it's the XConfig record we're projecting from. But why would we need a second record? |
| 2025-12-11 03:10:16 +0100 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2025-12-11 03:11:20 +0100 | <geekosaur> | because it's not a Map, it's a function that produces a Map. the function is passed the current configuration, mostly so it can extract the modMask |
| 2025-12-11 03:12:14 +0100 | <geekosaur> | https://github.com/xmonad/xmonad/blob/master/src/XMonad/Config.hs#L181-L243 |
| 2025-12-11 03:13:06 +0100 | <geekosaur> | also note like 194 which extracts the current layoutHook and hard sets it to reinitialize layouts |
| 2025-12-11 03:13:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 03:13:50 +0100 | <geekosaur> | and line 233 which extracts the workspaces |
| 2025-12-11 03:18:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 03:18:55 +0100 | myxos | (~myxos@wsip-70-166-126-146.ph.ph.cox.net) (Ping timeout: 264 seconds) |
| 2025-12-11 03:23:57 +0100 | <Pozyomka> | Ah, thanks... I guess I just find it hard to reason about non-positive types: “Part of the data of a configuration is a function that takes another configuration...” |
| 2025-12-11 03:27:19 +0100 | myxos | (~myxos@wsip-70-166-126-146.ph.ph.cox.net) myxokephale |
| 2025-12-11 03:29:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 03:35:01 +0100 | <geekosaur> | it takes the same configuration. there's just no way to relay the configuration it came from to it automatically, so xmonad has to do `keys conf conf` |
| 2025-12-11 03:35:35 +0100 | <geekosaur> | (hypothetically you could even call the function directly, but I can't think of a good reason to do so. xmonad users have surprised me in the past, though) |
| 2025-12-11 03:35:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 03:37:49 +0100 | karenw | (~karenw@user/karenw) (Ping timeout: 264 seconds) |
| 2025-12-11 03:44:07 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 264 seconds) |
| 2025-12-11 03:45:54 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-11 03:47:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 03:51:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 03:52:05 +0100 | trickard | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 03:52:18 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 03:57:35 +0100 | rekahsoft | (~rekahsoft@70.51.99.245) (Ping timeout: 240 seconds) |
| 2025-12-11 03:58:00 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-12-11 04:01:02 +0100 | hsw | (~hsw@112-104-86-252.adsl.dynamic.seed.net.tw) hsw |
| 2025-12-11 04:02:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 04:06:50 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) ryanbooker |
| 2025-12-11 04:07:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-11 04:09:26 +0100 | img | (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-12-11 04:10:39 +0100 | img | (~img@user/img) img |
| 2025-12-11 04:11:55 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 240 seconds) |
| 2025-12-11 04:14:04 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-12-11 04:17:22 +0100 | nschoe | (~nschoe@82-65-202-30.subs.proxad.net) (Ping timeout: 246 seconds) |
| 2025-12-11 04:18:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 04:23:15 +0100 | nschoe | (~nschoe@82-65-202-30.subs.proxad.net) nschoe |
| 2025-12-11 04:23:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 04:34:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 04:35:55 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-12-11 04:38:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 04:41:55 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 04:42:08 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 04:49:54 +0100 | omidmash | (~omidmash@user/omidmash) (Quit: The Lounge - https://thelounge.chat) |
| 2025-12-11 04:50:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 04:54:19 +0100 | omidmash | (~omidmash@user/omidmash) omidmash |
| 2025-12-11 04:54:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 05:05:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 05:10:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 05:21:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 05:25:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 05:33:17 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-12-11 05:37:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 05:41:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 05:47:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 05:52:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 05:52:55 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2025-12-11 05:56:53 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-11 06:00:42 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 244 seconds) |
| 2025-12-11 06:03:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 06:07:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 06:14:45 +0100 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2025-12-11 06:15:38 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-11 06:16:36 +0100 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-12-11 06:18:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 06:20:55 +0100 | trickard_ | trickard |
| 2025-12-11 06:24:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 06:26:47 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:fd44:bbca:9ef1:b046) |
| 2025-12-11 06:27:03 +0100 | <iqubic> | If I have a `Map k v` is there a function of type `Map k v -> k -> Bool` that tells me if said key is present in the Map? |
| 2025-12-11 06:27:41 +0100 | <iqubic> | It's member and notMemember that I want. |
| 2025-12-11 06:36:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 06:41:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 06:50:53 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 252 seconds) |
| 2025-12-11 06:51:30 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2025-12-11 06:52:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 06:52:49 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-12-11 06:54:35 +0100 | iqubic | (~sophia@2601:602:9203:1660:767a:e6b6:2f4b:e37e) (Remote host closed the connection) |
| 2025-12-11 06:54:43 +0100 | <Leary> | @tell Wygyulmage Looks like it's because it's defined in terms of `deleteBy`, but with the arguments flipped to be consistent with `\\`. I wouldn't call that a /deep/ reason though, and you could perhaps change it by complaining at the CLC. |
| 2025-12-11 06:54:43 +0100 | <lambdabot> | Consider it noted. |
| 2025-12-11 06:56:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-11 07:07:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 07:10:16 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 246 seconds) |
| 2025-12-11 07:12:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 07:14:14 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-11 07:19:14 +0100 | ephemient | (uid407513@user/ephemient) ephemient |
| 2025-12-11 07:19:41 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-11 07:23:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 07:28:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-11 07:32:46 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-11 07:34:27 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-11 07:34:29 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-12-11 07:39:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 07:41:20 +0100 | <int-e> | Leary: you had an extra 'y' |
| 2025-12-11 07:41:54 +0100 | <int-e> | (I noticed because I tried finding the question) |
| 2025-12-11 07:43:35 +0100 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-12-11 07:44:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 07:45:44 +0100 | <Leary> | Geh. That's what happens when no tab-complete. |
| 2025-12-11 07:47:11 +0100 | <Leary> | @clear-messages |
| 2025-12-11 07:47:11 +0100 | <lambdabot> | Messages cleared. |
| 2025-12-11 07:47:27 +0100 | <Leary> | @tell Wygulmage Looks like it's because it's defined in terms of `deleteBy`, but with the arguments flipped to be consistent with `\\`. I wouldn't call that a /deep/ reason though, and you could perhaps change it by complaining at the CLC. |
| 2025-12-11 07:47:27 +0100 | <lambdabot> | Consider it noted. |
| 2025-12-11 07:47:52 +0100 | acidjnk | (~acidjnk@p200300d6e717192391252480cf04477b.dip0.t-ipconnect.de) acidjnk |
| 2025-12-11 07:50:09 +0100 | <int-e> | It's been that way since at least Haskell 98 though. (On the flip side, I don't remember ever using that function.) |
| 2025-12-11 07:52:23 +0100 | <int-e> | Changing the orientation of the predicate would be one of the more insidious changes you could push onto users, since the code will still compile. |
| 2025-12-11 07:53:30 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-11 07:54:41 +0100 | <Leary> | Yeah, it probably won't happen. That said, it's probably not actually hard to warn/PR every single user on hackage. |
| 2025-12-11 07:59:12 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2025-12-11 08:02:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 08:07:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 08:20:02 +0100 | jrm2 | (~jrm@user/jrm) jrm |
| 2025-12-11 08:20:16 +0100 | jrm | (~jrm@user/jrm) (Ping timeout: 246 seconds) |
| 2025-12-11 08:21:38 +0100 | jrm2 | jrm |
| 2025-12-11 08:46:17 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-11 08:48:29 +0100 | lucabtz | (~lucabtz@user/lucabtz) lucabtz |
| 2025-12-11 08:49:12 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-12-11 08:53:07 +0100 | ft | (~ft@p508db844.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-12-11 08:56:50 +0100 | FirefoxDeHuk | (~FirefoxDe@user/FirefoxDeHuk) FirefoxDeHuk |
| 2025-12-11 08:58:02 +0100 | j1n37 | (~j1n37@user/j1n37) (Quit: Ich bin der Welt abhanden gekommen) |
| 2025-12-11 08:59:43 +0100 | tolt_ | (~weechat-h@li219-154.members.linode.com) (Ping timeout: 240 seconds) |
| 2025-12-11 08:59:45 +0100 | emmanuelux_ | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-12-11 08:59:55 +0100 | haskellbridge_ | (~hackager@96.28.224.214) hackager |
| 2025-12-11 08:59:55 +0100 | ChanServ | +v haskellbridge_ |
| 2025-12-11 09:00:12 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-12-11 09:00:50 +0100 | tolt | (~weechat-h@li219-154.members.linode.com) tolt |
| 2025-12-11 09:02:00 +0100 | jrm2 | (~jrm@user/jrm) jrm |
| 2025-12-11 09:02:40 +0100 | pabs3 | (~pabs3@user/pabs3) (Killed (platinum.libera.chat (Nickname regained by services))) |
| 2025-12-11 09:02:44 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-12-11 09:02:48 +0100 | takuan_dozo | (~takuan@d8D86B9E9.access.telenet.be) |
| 2025-12-11 09:04:15 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer) |
| 2025-12-11 09:04:15 +0100 | itaipu | (~itaipu@168.121.97.28) (Ping timeout: 240 seconds) |
| 2025-12-11 09:04:15 +0100 | haskellbridge | (~hackager@96.28.224.214) (Ping timeout: 240 seconds) |
| 2025-12-11 09:04:16 +0100 | jrm | (~jrm@user/jrm) (Ping timeout: 240 seconds) |
| 2025-12-11 09:04:16 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 240 seconds) |
| 2025-12-11 09:04:16 +0100 | jrm2 | jrm |
| 2025-12-11 09:04:31 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 240 seconds) |
| 2025-12-11 09:04:35 +0100 | FANTOM | (~fantom@90.244.161.115) (Ping timeout: 240 seconds) |
| 2025-12-11 09:04:47 +0100 | haskellbridge_ | haskellbridge |
| 2025-12-11 09:06:33 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-12-11 09:06:59 +0100 | FirefoxDeHuk | (~FirefoxDe@user/FirefoxDeHuk) (Quit: Client closed) |
| 2025-12-11 09:08:00 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-11 09:08:17 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 09:08:58 +0100 | SheRejoined | (haveident@libera/staff/she/her) She |
| 2025-12-11 09:10:16 +0100 | She | (haveident@libera/staff/she/her) (Read error: Connection reset by peer) |
| 2025-12-11 09:10:16 +0100 | SheRejoined | She |
| 2025-12-11 09:10:53 +0100 | FANTOM | (~fantom@90.244.161.115) |
| 2025-12-11 09:13:34 +0100 | itaipu | (~itaipu@168.121.97.28) itaipu |
| 2025-12-11 09:15:19 +0100 | arahael | (~wetfoot@user/arahael) (Ping timeout: 265 seconds) |
| 2025-12-11 09:18:53 +0100 | arahael | (~wetfoot@user/arahael) arahael |
| 2025-12-11 09:19:49 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 264 seconds) |
| 2025-12-11 09:20:01 +0100 | trickard | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 09:20:14 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 09:20:31 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2025-12-11 09:26:49 +0100 | chencheng57 | (~chencheng@user/chencheng) chencheng |
| 2025-12-11 09:28:18 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 260 seconds) |
| 2025-12-11 09:29:09 +0100 | chencheng57 | (~chencheng@user/chencheng) (Client Quit) |
| 2025-12-11 09:31:41 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-12-11 09:35:46 +0100 | chele | (~chele@user/chele) chele |
| 2025-12-11 09:43:38 +0100 | Sgeo__ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-12-11 09:55:20 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 10:09:48 +0100 | emmanuelux_ | (~emmanuelu@user/emmanuelux) (Remote host closed the connection) |
| 2025-12-11 10:13:55 +0100 | pabs3 | (~pabs3@user/pabs3) (Read error: Connection reset by peer) |
| 2025-12-11 10:14:52 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-12-11 10:18:37 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 10:18:51 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 10:20:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-11 10:21:52 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-12-11 10:24:44 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-12-11 10:27:00 +0100 | olivial | (~benjaminl@user/benjaminl) (Ping timeout: 245 seconds) |
| 2025-12-11 10:37:47 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-12-11 10:40:38 +0100 | arahael | (~wetfoot@user/arahael) (Ping timeout: 260 seconds) |
| 2025-12-11 10:41:14 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-12-11 10:49:03 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2025-12-11 10:53:11 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 11:00:02 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2025-12-11 11:00:02 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2025-12-11 11:00:02 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-12-11 11:01:31 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-11 11:02:04 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 11:02:48 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-12-11 11:03:15 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Ping timeout: 240 seconds) |
| 2025-12-11 11:03:31 +0100 | arahael | (~wetfoot@user/arahael) arahael |
| 2025-12-11 11:05:25 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 264 seconds) |
| 2025-12-11 11:06:08 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 11:08:51 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-11 11:09:15 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-11 11:09:15 +0100 | ljdarj1 | ljdarj |
| 2025-12-11 11:09:51 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 11:14:28 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 11:16:33 +0100 | yuuta | (~YuutaW@infornography.yta.moe) (Ping timeout: 252 seconds) |
| 2025-12-11 11:18:37 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-11 11:18:46 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2025-12-11 11:18:52 +0100 | Googulator | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 11:20:15 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-11 11:20:15 +0100 | ljdarj1 | ljdarj |
| 2025-12-11 11:30:37 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 11:34:55 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
| 2025-12-11 11:37:27 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 11:48:22 +0100 | YuutaW | (~YuutaW@2404:f4c0:f9c3:502::100:6eef) YuutaW |
| 2025-12-11 11:49:15 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 240 seconds) |
| 2025-12-11 11:55:41 +0100 | Googulator85 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 11:55:43 +0100 | Googulator | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 11:58:52 +0100 | xff0x | (~xff0x@2405:6580:b080:900:bfb6:36fd:6718:66b7) |
| 2025-12-11 12:06:04 +0100 | Square | (~Square4@user/square) Square |
| 2025-12-11 12:15:35 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 12:25:43 +0100 | Googulator85 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 12:25:50 +0100 | Googulator48 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 12:29:22 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 12:31:54 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-12-11 12:34:39 +0100 | jreicher | (~user@user/jreicher) (Quit: brb) |
| 2025-12-11 12:38:13 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-12-11 12:43:41 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-12-11 12:45:01 +0100 | jreicher | (~user@user/jreicher) jreicher |
| 2025-12-11 12:51:20 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-12-11 12:58:03 +0100 | yin | (~zero@user/zero) (Remote host closed the connection) |
| 2025-12-11 13:00:14 +0100 | Jackneill_ | (~Jackneill@178-164-177-109.pool.digikabel.hu) |
| 2025-12-11 13:02:42 +0100 | Jackneill | (~Jackneill@94-21-15-191.pool.digikabel.hu) (Ping timeout: 252 seconds) |
| 2025-12-11 13:06:12 +0100 | yin | (~zero@user/zero) zero |
| 2025-12-11 13:08:25 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-11 13:10:35 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 13:10:48 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 13:17:05 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 13:22:52 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 13:24:18 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-12-11 13:25:42 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 13:25:55 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 13:30:06 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-12-11 13:30:18 +0100 | karenw | (~karenw@user/karenw) (Remote host closed the connection) |
| 2025-12-11 13:31:20 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-12-11 13:35:14 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 13:36:44 +0100 | fp | (~Thunderbi@2001:708:20:1406::10c5) fp |
| 2025-12-11 13:38:04 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2025-12-11 13:39:16 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:fb9e:194f:f1d5:eb88) |
| 2025-12-11 13:45:41 +0100 | Googulator63 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 13:45:49 +0100 | Googulator48 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 13:47:14 +0100 | yin | (~zero@user/zero) (Remote host closed the connection) |
| 2025-12-11 13:49:01 +0100 | yin | (~zero@user/zero) zero |
| 2025-12-11 13:54:57 +0100 | yin | (~zero@user/zero) (Remote host closed the connection) |
| 2025-12-11 13:55:20 +0100 | yin | (~zero@user/zero) zero |
| 2025-12-11 14:05:29 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-11 14:07:30 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-11 14:12:17 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-11 14:12:37 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-11 14:12:48 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-11 14:13:57 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 14:15:54 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 14:16:11 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 14:16:25 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 14:17:43 +0100 | Googulator63 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 14:34:09 +0100 | cawfee | (root@2401:c080:3800:3460::babe) (Quit: WeeChat 4.7.1) |
| 2025-12-11 14:34:55 +0100 | cawfee | (root@2401:c080:3800:3460::babe) qjqqyy |
| 2025-12-11 14:35:58 +0100 | cawfee | (root@2401:c080:3800:3460::babe) (Client Quit) |
| 2025-12-11 14:36:46 +0100 | cawfee | (root@2401:c080:3800:3460::babe) |
| 2025-12-11 14:41:47 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Ping timeout: 272 seconds) |
| 2025-12-11 14:42:45 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-12-11 14:49:40 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 14:52:35 +0100 | Square | (~Square4@user/square) (Ping timeout: 240 seconds) |
| 2025-12-11 14:52:52 +0100 | fp | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 256 seconds) |
| 2025-12-11 15:00:39 +0100 | fp | (~Thunderbi@wireless-86-50-140-30.open.aalto.fi) fp |
| 2025-12-11 15:03:28 +0100 | fp | (~Thunderbi@wireless-86-50-140-30.open.aalto.fi) (Remote host closed the connection) |
| 2025-12-11 15:06:43 +0100 | Googulator87 | (~Googulato@185.199.28.81) |
| 2025-12-11 15:09:05 +0100 | rekahsoft | (~rekahsoft@70.51.99.245) rekahsoft |
| 2025-12-11 15:13:14 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.retail.telecomitalia.it) Enrico63 |
| 2025-12-11 15:13:15 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 15:16:20 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.retail.telecomitalia.it) (Client Quit) |
| 2025-12-11 15:17:50 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) fp |
| 2025-12-11 15:18:53 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-12-11 15:22:00 +0100 | <pounce> | does anybody know if there's a name for Functor f => (k -> f a) -> (k -> b) -> (k -> f b)? kind of like blah f g x = f x $> g x |
| 2025-12-11 15:22:48 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.retail.telecomitalia.it) Enrico63 |
| 2025-12-11 15:25:39 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 15:29:57 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 250 seconds) |
| 2025-12-11 15:30:30 +0100 | <Leary> | pounce: Only `liftA2 ($>)`. |
| 2025-12-11 15:31:11 +0100 | Googulator87 | (~Googulato@185.199.28.81) (Ping timeout: 272 seconds) |
| 2025-12-11 15:33:24 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) (Ping timeout: 252 seconds) |
| 2025-12-11 15:33:58 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 15:34:23 +0100 | tremon | (~tremon@83.80.159.219) tremon |
| 2025-12-11 15:39:12 +0100 | <kuribas> | pounce: give it your own name :) |
| 2025-12-11 15:39:44 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) fp |
| 2025-12-11 15:41:35 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 15:42:11 +0100 | <kuribas> | I hate this error: Ambiguous type variable ‘a0’ arising from a use of ‘subQuery’ prevents the constraint ‘(ToQueryBuilder a0)’ from being solved. |
| 2025-12-11 15:42:14 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) (Remote host closed the connection) |
| 2025-12-11 15:42:33 +0100 | <kuribas> | There is nothing that stops ghc from creating a hole for a0, no? |
| 2025-12-11 15:42:39 +0100 | <kuribas> | This shouldn't be an error at all. |
| 2025-12-11 15:43:25 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-12-11 15:43:53 +0100 | <kuribas> | Well, with -fdefer-typed-holes |
| 2025-12-11 15:44:57 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 15:45:59 +0100 | <kuribas> | I would expect ghc to infer constraints as much as possible with holes, but create another hole when it cannot resolve them. |
| 2025-12-11 15:46:09 +0100 | <kuribas> | This would make working with typed holes so much better. |
| 2025-12-11 15:46:38 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2025-12-11 15:49:43 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 15:53:57 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-12-11 15:56:52 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 16:03:33 +0100 | raym | (~ray@user/raym) raym |
| 2025-12-11 16:03:50 +0100 | fp | (~Thunderbi@130.233.70.102) fp |
| 2025-12-11 16:06:07 +0100 | fp | (~Thunderbi@130.233.70.102) (Client Quit) |
| 2025-12-11 16:06:21 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-12-11 16:06:27 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) fp |
| 2025-12-11 16:08:31 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 16:08:44 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 16:11:17 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-12-11 16:12:11 +0100 | qqe | (~qqq@185.54.20.98) (Quit: Lost terminal) |
| 2025-12-11 16:12:41 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-11 16:16:31 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds) |
| 2025-12-11 16:17:01 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 16:17:13 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 260 seconds) |
| 2025-12-11 16:19:36 +0100 | fp | (~Thunderbi@2001:708:20:1406::1370) (Ping timeout: 252 seconds) |
| 2025-12-11 16:21:00 +0100 | deptype_ | (~deptype@2406:b400:3a:9d2f:fd44:bbca:9ef1:b046) |
| 2025-12-11 16:23:42 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-12-11 16:24:28 +0100 | Square | (~Square4@user/square) Square |
| 2025-12-11 16:24:54 +0100 | Enrico63 | (~Enrico63@host-212-171-79-170.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-12-11 16:26:04 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 246 seconds) |
| 2025-12-11 16:42:12 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-11 16:42:54 +0100 | <tomsmeding> | kuribas: the context "I want to work with -fdefer-typed-holes" is very important there :p |
| 2025-12-11 16:43:12 +0100 | <kuribas> | right :) |
| 2025-12-11 16:46:02 +0100 | <merijn> | Of course you do |
| 2025-12-11 16:46:17 +0100 | <merijn> | -fdefer-typed-holes is the greatest flag ever and whoever implemented it was a visionary genius |
| 2025-12-11 16:46:29 +0100 | <tomsmeding> | well that turns this from "GHC's diagnostics are bad" into "-fdefer-typed-holes is not strong enough" |
| 2025-12-11 16:46:39 +0100 | <tomsmeding> | which is a completely different thing, namely a feature request instead of a bug report |
| 2025-12-11 16:46:55 +0100 | <merijn> | (I missed the context, btw) |
| 2025-12-11 16:47:32 +0100 | <kuribas> | tomsmeding: A feature request I have been missing for 10 years or so :) |
| 2025-12-11 16:47:39 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 16:49:00 +0100 | <kuribas> | merijn: it came from profo assistants, no? |
| 2025-12-11 16:49:02 +0100 | <kuribas> | proof |
| 2025-12-11 16:49:26 +0100 | <merijn> | kuribas: The ambiguous variable *is* an error and it cannot be solved |
| 2025-12-11 16:49:32 +0100 | <merijn> | holes don't help you there |
| 2025-12-11 16:50:22 +0100 | <kuribas> | If a0 is the type of a hole, I don't want an error. |
| 2025-12-11 16:50:43 +0100 | <merijn> | Can you pastebin an example? |
| 2025-12-11 16:50:59 +0100 | <kuribas> | I don't have an easy example right now. |
| 2025-12-11 16:51:19 +0100 | <merijn> | kuribas: It didn't come from proof assistants |
| 2025-12-11 16:51:23 +0100 | <merijn> | It was I, Dio! |
| 2025-12-11 16:51:37 +0100 | <kuribas> | ah right :) |
| 2025-12-11 16:51:46 +0100 | <kuribas> | Well, the hole thingy came from proof assistants, no? |
| 2025-12-11 16:52:10 +0100 | <kuribas> | "Typed holes are a powerful feature in GHC inspired by Agda. But what are typed holes, and how do they help us write code? " |
| 2025-12-11 16:52:10 +0100 | <merijn> | I saw -fdefer-type-errprs and I was like "man, that's useless. But also, it would be nice if I could run my code while it still had holes" |
| 2025-12-11 16:52:35 +0100 | <kuribas> | indeed! |
| 2025-12-11 16:53:08 +0100 | <kuribas> | And if you allow holes, why not allow missing constraints on those holes? |
| 2025-12-11 17:00:01 +0100 | deptype_ | (~deptype@2406:b400:3a:9d2f:fd44:bbca:9ef1:b046) (Quit: Leaving) |
| 2025-12-11 17:00:24 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:fd44:bbca:9ef1:b046) (Read error: Connection reset by peer) |
| 2025-12-11 17:02:49 +0100 | <merijn> | kuribas: You could try and fix it. I hacked that flag together when I barely knew haskell :p |
| 2025-12-11 17:03:37 +0100 | <haskellbridge> | <matti palli> Allowing missing constraints is a bit problematic, since constraints is how we generate code. Indeed, holes are just an “undefined variable” error with a fancy message |
| 2025-12-11 17:03:47 +0100 | Axman6 | (~Axman6@user/axman6) (Remote host closed the connection) |
| 2025-12-11 17:04:17 +0100 | <kuribas> | How are constraints "generating code"? |
| 2025-12-11 17:04:40 +0100 | <kuribas> | constraints are just implicits. |
| 2025-12-11 17:05:15 +0100 | yin | (~zero@user/zero) (Remote host closed the connection) |
| 2025-12-11 17:05:26 +0100 | <kuribas> | And the point is that the hole is not just "an error", but allows you to fill in the rest of the program, while leave out details. |
| 2025-12-11 17:05:30 +0100 | yin | (~zero@user/zero) zero |
| 2025-12-11 17:05:30 +0100 | <haskellbridge> | <matti palli> that’s how the typechecker works, you solve constraint by emitting a “proof” that the constraint holds, and that contains the dictionary which contains the code |
| 2025-12-11 17:06:05 +0100 | <kuribas> | You don't emit a "proof", the type inference does a proof search to find the right instance. |
| 2025-12-11 17:06:46 +0100 | <haskellbridge> | <matti palli> yeah, and the right instance is the proof |
| 2025-12-11 17:07:39 +0100 | <haskellbridge> | <matti palli> and it’s simultaneously the dictionary which contains the code, afaiu |
| 2025-12-11 17:08:30 +0100 | <kuribas> | haskell doesn't really have "proofs". |
| 2025-12-11 17:08:36 +0100 | <kuribas> | Due to bottom. |
| 2025-12-11 17:09:33 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-12-11 17:10:09 +0100 | <kuribas> | Even so, proof assistants like agda and idris allow you to have holes as proofs. |
| 2025-12-11 17:10:15 +0100 | <kuribas> | Then they are just "assumptions". |
| 2025-12-11 17:10:15 +0100 | <lucabtz> | i remember a video of tsoding on youtube referring to implementing instances like the functor instance as "proving" something is a functor |
| 2025-12-11 17:10:15 +0100 | <haskellbridge> | <matti palli> yeah sure, you can emit a “proof” that just contains error |
| 2025-12-11 17:10:58 +0100 | <haskellbridge> | <matti palli> what I mean is that you solve the constraint and emit a witness that is the dictionary |
| 2025-12-11 17:11:17 +0100 | <kuribas> | That's how large proofs are done, you treat some parts as "assumptions", and proof them later. Or they turn out to be false, and you have to abort the whole proof (or find another proof). |
| 2025-12-11 17:12:12 +0100 | <haskellbridge> | <matti palli> sure, you can do that with undefined or error as well. but then you have the issue of ambiguous type variables, as you’ve encountered |
| 2025-12-11 17:12:31 +0100 | <tomsmeding> | is the problem here that you want to be sure that the unsolvable constraint is _purely_ due to a typed hole? |
| 2025-12-11 17:12:43 +0100 | <kuribas> | yeah |
| 2025-12-11 17:12:56 +0100 | <tomsmeding> | because instantiating a typeclass dictionary argument with an error term is very much expressible in Core, at least |
| 2025-12-11 17:13:22 +0100 | <tomsmeding> | it's just hard to draw the line between an arbitrary unsolved constraint and one that is "intuitively" part of the hole |
| 2025-12-11 17:13:43 +0100 | <tomsmeding> | and replacing arbitrary unsolved constraints with errors (and thus not stopping compilation for them) is rather against the idea of -fdefer-typed-holes |
| 2025-12-11 17:13:54 +0100 | <kuribas> | tomsmeding: isn't that use a graph on the typeclass dependencies? |
| 2025-12-11 17:14:16 +0100 | <tomsmeding> | perhaps, but I expect you're going to have a lot of spurious dependencies |
| 2025-12-11 17:14:23 +0100 | <tomsmeding> | also, the graph needs to include type variables |
| 2025-12-11 17:16:03 +0100 | <tomsmeding> | one thing that's probably implementable (I say without having ever looked at the GHC typechecker) is instantiating any ambiguous unification variable with a special type such that unsolved constraints that mention that special type get magically solved with an error |
| 2025-12-11 17:16:13 +0100 | <tomsmeding> | but that would be -fdefer-type-errors behaviour, not -fdefer-typed-holes |
| 2025-12-11 17:16:59 +0100 | <kuribas> | tomsmeding: the hole gives rise to a type variable, which can be either unified with something, or remains "ambiguous". In the latter case you can trace which type classes depend on the ambiguous variable, no? |
| 2025-12-11 17:17:07 +0100 | <haskellbridge> | <matti palli> You could get there by just giving a more specific type to the hole "_ :: blah", resolving the ambiguity |
| 2025-12-11 17:17:12 +0100 | <tomsmeding> | "the hole gives rise to a type variable" is not a thing |
| 2025-12-11 17:17:30 +0100 | <tomsmeding> | every term gives rise to potentially multiple unification variables, and a lot of those are equal |
| 2025-12-11 17:17:44 +0100 | <tomsmeding> | you can track dependencies of everything, but that likely slows down type checking significantly |
| 2025-12-11 17:18:31 +0100 | <tomsmeding> | if the type of the hole itself is the ambiguous type variable, then sure, it clearly "gives rise" to it (though even then, there's not at all necessarily a causal relationship!) |
| 2025-12-11 17:19:04 +0100 | <tomsmeding> | what if you have `read undefined + _`; that has an ambiguous type, but is that type "given rise to" by the hole? |
| 2025-12-11 17:19:08 +0100 | <tomsmeding> | how would GHC decide? |
| 2025-12-11 17:19:10 +0100 | <haskellbridge> | <matti palli> tomsmeding: technically the type of the hole starts of as a type variable, but is then quickly unified with variables that exist in scope. |
| 2025-12-11 17:19:16 +0100 | <tomsmeding> | right |
| 2025-12-11 17:19:29 +0100 | <haskellbridge> | <matti palli> it never comes up with a completely new variable |
| 2025-12-11 17:20:01 +0100 | <tomsmeding> | well, if the type of the hole starts off as a type variable, that variable was completely new, wasn't it? ;) |
| 2025-12-11 17:20:34 +0100 | <haskellbridge> | <matti palli> well yes but it shouldn’t escape the scope (you’d get the skolem has escaped warning haha) |
| 2025-12-11 17:20:47 +0100 | <tomsmeding> | but kuribas what do you think about my little example? |
| 2025-12-11 17:21:30 +0100 | <haskellbridge> | <matti palli> but yeah you are completely right, the ambiguity isn’t introduced by the hole, it’s just that the hole isn’t resolving any ambiguity (nor should it!) |
| 2025-12-11 17:21:59 +0100 | <tomsmeding> | you can try to deduce that fixing the type of the whole would resolve the ambiguity, perhaps |
| 2025-12-11 17:22:16 +0100 | <tomsmeding> | but I'm not sure that characterises precisely what kuribas intends |
| 2025-12-11 17:22:28 +0100 | <tomsmeding> | and also that feels like fragile code, especially in GHC where you have zonking |
| 2025-12-11 17:22:37 +0100 | <kuribas> | tomsmeding: (read undefined :: Read a => a), after + it becomes (Read a, Num a), and (_ :: ?hole1), so after unifying with the hole, you have (Read ?hole, Num ?hole) => ?hole |
| 2025-12-11 17:22:57 +0100 | <tomsmeding> | kuribas: or you have (Read a, Num a) => a, with the hole also of type a |
| 2025-12-11 17:23:17 +0100 | <haskellbridge> | <matti palli> the type of the home becomes a, not the other way around |
| 2025-12-11 17:23:21 +0100 | <tomsmeding> | GHC makes some arbitrary rewriting choice when handling the equality `a ~ ?hole` introduced by the + |
| 2025-12-11 17:23:49 +0100 | <tomsmeding> | (it's not random, of course, but if it's the one I can probably flip it around by swapping the arguments to +) |
| 2025-12-11 17:24:14 +0100 | <tomsmeding> | the point is, GHC's behaviour ought not to depend on which choice is made here |
| 2025-12-11 17:24:28 +0100 | <kuribas> | tomsmeding: like you said, "read undefined" gives rise to a unification variable. |
| 2025-12-11 17:24:54 +0100 | <tomsmeding> | because if it does depend on internal typechecker choices like these, then behaviour in practice will be highly unpredictable, which GHC in general considers worse than just not supporting the thing at all |
| 2025-12-11 17:25:19 +0100 | <tomsmeding> | kuribas: if I write simply `read undefined` in a program without a hole, and I set -fdefer-typed-holes, should that result in an error? |
| 2025-12-11 17:25:32 +0100 | <tomsmeding> | if so, my `read undefined + _` makes it ambiguous whether it should throw an error or not |
| 2025-12-11 17:25:35 +0100 | <kuribas> | tomsmeding: in idris it doesn't :) |
| 2025-12-11 17:25:44 +0100 | <tomsmeding> | then it's -fdefer-type-errors, not -fdefer-typed-holes |
| 2025-12-11 17:25:49 +0100 | <kuribas> | tomsmeding: It'll happily generate an empty list of undefined type. |
| 2025-12-11 17:25:57 +0100 | <tomsmeding> | `read undefined` has no holes in haskell |
| 2025-12-11 17:26:26 +0100 | <kuribas> | tomsmeding: why should it? |
| 2025-12-11 17:26:50 +0100 | <tomsmeding> | because if it doesn't, then -fdefer-typed-HOLES should not have an impact on GHC's behaviour when compiling `read undefined` |
| 2025-12-11 17:27:21 +0100 | <tomsmeding> | (I guess the 'undefined' is a red herring in all of this, `read ""` works just as well) |
| 2025-12-11 17:27:22 +0100 | <kuribas> | tomsmeding: well it doesn't? |
| 2025-12-11 17:27:28 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) |
| 2025-12-11 17:27:38 +0100 | <tomsmeding> | right |
| 2025-12-11 17:27:49 +0100 | <kuribas> | tomsmeding: I tag ?hole as a unification variable belonging to a hole, and any constraints on it are deferred as well. |
| 2025-12-11 17:28:01 +0100 | <tomsmeding> | and should `read "" + _` and `_ + read ""` have the same behaviour under -fdefer-typed-holes? |
| 2025-12-11 17:28:29 +0100 | <kuribas> | yes |
| 2025-12-11 17:28:43 +0100 | <tomsmeding> | but the unification variable resulting from `read ""` and the one resulting from `_` are the same to GHC |
| 2025-12-11 17:28:54 +0100 | <tomsmeding> | so they're rewritten in some direction, and one of the two disappears |
| 2025-12-11 17:29:18 +0100 | <kuribas> | tomsmeding: they are now, but like I said, I would tag it as belonging to a hole. |
| 2025-12-11 17:29:30 +0100 | <tomsmeding> | what about `show (fromJust _)`? |
| 2025-12-11 17:29:45 +0100 | <tomsmeding> | does the `a` in the `Maybe a` that is the type of `_`, arise from the hole? |
| 2025-12-11 17:29:49 +0100 | <haskellbridge> | <matti palli> kuribas: but it doesn’t, it belongs to the undefined or the read |
| 2025-12-11 17:30:19 +0100 | <tomsmeding> | matti: kuribas is arguing that a type variable "arising from" a hole originally should have a little tag saying so, and when unifying two type variables, you take the union of the tags |
| 2025-12-11 17:30:21 +0100 | <tomsmeding> | I think |
| 2025-12-11 17:30:28 +0100 | <tomsmeding> | ok I have to go, sorry |
| 2025-12-11 17:30:29 +0100 | <kuribas> | tomsmeding: right |
| 2025-12-11 17:30:36 +0100 | <tomsmeding> | good luck :p |
| 2025-12-11 17:30:58 +0100 | lucabtz | (~lucabtz@user/lucabtz) (Remote host closed the connection) |
| 2025-12-11 17:31:46 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-12-11 17:32:06 +0100 | <haskellbridge> | <matti palli> tomsmeding: hmm yes interesting |
| 2025-12-11 17:32:06 +0100 | <haskellbridge> | SPJ bugged me about this, saying we should add provenance to type variables for improved errors. If you had that you could improve holes as well |
| 2025-12-11 17:32:30 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-11 17:32:47 +0100 | <kuribas> | Yes "fromJust :: Maybe a -> a", then "?hole ~ Maybe ?sub_hole", and "Show ?sub_hole" is deferred. |
| 2025-12-11 17:35:22 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:fb9e:194f:f1d5:eb88) (Remote host closed the connection) |
| 2025-12-11 17:40:12 +0100 | spew_ | (~spew@user/spew) spew |
| 2025-12-11 17:40:43 +0100 | spew | (~spew@user/spew) (Ping timeout: 255 seconds) |
| 2025-12-11 17:41:15 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 17:41:16 +0100 | spew_ | spew |
| 2025-12-11 17:41:35 +0100 | <haskellbridge> | <matti palli> Right. At the moment there is no distinction, and thinking about it might be that typechecking levels could be an issue, i.e. when do you unify with a hole type variable in the new schema |
| 2025-12-11 17:41:38 +0100 | <haskellbridge> | interesting problem for sure |
| 2025-12-11 17:42:20 +0100 | karenw | (~karenw@user/karenw) (Ping timeout: 244 seconds) |
| 2025-12-11 17:43:45 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-12-11 17:45:02 +0100 | <dolio> | Even if you know the provenance of type variables, I don't know that the further idea makes sense. |
| 2025-12-11 17:45:17 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 17:46:36 +0100 | yin | zero |
| 2025-12-11 17:46:40 +0100 | zero | yin |
| 2025-12-11 17:49:55 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 17:53:17 +0100 | Guest87 | (~Guest87@2405:201:d006:986f:5c73:3a20:69d:7d07) |
| 2025-12-11 18:02:14 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 18:08:13 +0100 | skum | (~skum@user/skum) (Quit: WeeChat 4.8.1) |
| 2025-12-11 18:08:27 +0100 | milan | (~milan@88.212.61.169) |
| 2025-12-11 18:08:35 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-12-11 18:09:49 +0100 | <milan> | Guyz Am I out of luck if I want to use Data.Text in application build with -XSafe? |
| 2025-12-11 18:10:47 +0100 | spew | (~spew@user/spew) (Read error: Connection reset by peer) |
| 2025-12-11 18:12:55 +0100 | Tuplanolla | (~Tuplanoll@91-152-225-194.elisa-laajakaista.fi) Tuplanolla |
| 2025-12-11 18:13:09 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-11 18:15:42 +0100 | Googulator87 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 18:15:45 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-11 18:15:58 +0100 | trickard_ | (~trickard@cpe-83-98-47-163.wireline.com.au) |
| 2025-12-11 18:17:13 +0100 | tv | (~tv@user/tv) tv |
| 2025-12-11 18:18:27 +0100 | Googulator87 | Googulator |
| 2025-12-11 18:20:30 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 18:21:59 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-12-11 18:25:13 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-11 18:33:31 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-12-11 18:36:23 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 18:36:36 +0100 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2025-12-11 18:37:14 +0100 | spew | (~spew@user/spew) spew |
| 2025-12-11 18:37:25 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 18:39:29 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-12-11 18:41:14 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Ping timeout: 244 seconds) |
| 2025-12-11 18:42:19 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-11 18:45:07 +0100 | tccq | (~user@user/tccq) tccq |
| 2025-12-11 18:46:33 +0100 | <gentauro> | I'm tryiing to build an old stack/cabal project, but I'm getting: `startProcess: posix_spawnp: does not exist`. Have anybody seen that before? |
| 2025-12-11 18:46:45 +0100 | <gentauro> | *note*: I have the newest stack installed |
| 2025-12-11 18:47:15 +0100 | <gentauro> | `Version 3.7.1, Git revision` |
| 2025-12-11 18:48:35 +0100 | Googulator | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 18:48:51 +0100 | Googulator | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 18:54:00 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 18:54:35 +0100 | skum | (~skum@user/skum) skum |
| 2025-12-11 18:54:40 +0100 | ephemient | (uid407513@user/ephemient) (Quit: Connection closed for inactivity) |
| 2025-12-11 18:55:21 +0100 | <sm> | gentauro: doesn't ring a bell, but have you tried searching for that error message ? |
| 2025-12-11 18:55:58 +0100 | int-e | would look for verbosity options or maybe use strace to figure out what program it's trying to execute |
| 2025-12-11 18:56:28 +0100 | <sm> | anything at https://github.com/haskell/process/issues/247 ? |
| 2025-12-11 18:56:38 +0100 | <geekosaur> | normally it says the program |
| 2025-12-11 18:57:37 +0100 | <gentauro> | sm: it seems that the cached `Cabal-simple-…` placed in `~/.stack/setup-exe-cache/x86_64-linux-nix` become wacko. I cleansed that folder and now it works. |
| 2025-12-11 18:57:51 +0100 | kuribas | (~user@2a02:1808:cd:df9d:1dcb:cff3:20e8:95d8) kuribas |
| 2025-12-11 18:58:08 +0100 | <gentauro> | geekosaur: yeah, it mentioned `Cabal-simple-…` |
| 2025-12-11 18:58:17 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-12-11 18:58:44 +0100 | <int-e> | (note that "not found" in an exec-like context doesn't necessarily mean that the executable itself is missing; it can also be a shared library that it depends on) |
| 2025-12-11 18:59:01 +0100 | <gentauro> | I guess it happens from time to time on NixOS when I change the main channel (recently moved from 25.05 -> 25.11) |
| 2025-12-11 18:59:32 +0100 | <int-e> | oh I suppose nix will change library paths all the time |
| 2025-12-11 19:00:06 +0100 | <int-e> | anyway, it sunds like the issue is solved :) |
| 2025-12-11 19:00:20 +0100 | <gentauro> | int-e: and sometimes remove support for old GHC. They do that cos the burden of maintaining all of it. So I do understand. |
| 2025-12-11 19:00:28 +0100 | <gentauro> | int-e: it sure is. Thx :) |
| 2025-12-11 19:00:46 +0100 | Googulator | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 19:00:49 +0100 | Googulator24 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 19:00:57 +0100 | <sm> | gentauro: great. I guess "nuke things and start over" is our equivalent of "have you tried turning it off and on again" |
| 2025-12-11 19:01:10 +0100 | <gentauro> | sm: xD |
| 2025-12-11 19:01:21 +0100 | <sm> | sometimes it's the quickest thing to try |
| 2025-12-11 19:01:40 +0100 | <gentauro> | sm: back in the good old days, I sed gentoo and compiled it all locally. I'm never going back to those days again xD |
| 2025-12-11 19:01:57 +0100 | <gentauro> | I would rather spend my time producing code ;) |
| 2025-12-11 19:02:47 +0100 | <haskellbridge> | <sm> sure, but sometimes it's quicker to move some dirs aside and let cabal/stack run in another window while you continue working on things that require thought |
| 2025-12-11 19:02:56 +0100 | <geekosaur> | if that binary was left over from then, it might do it. "does not exist" can refer not to the binary, but to its ELF "interpreter" whose path might vary on different systems (well, shouldn't these days, but if it was old enough it might) |
| 2025-12-11 19:03:27 +0100 | <geekosaur> | leading to confusing error messages because `exec` has no way to pass back precisely what wasn't found |
| 2025-12-11 19:03:37 +0100 | <haskellbridge> | <sm> (not something I would do often, but sometimes the dumb hands-free test is worth doing) |
| 2025-12-11 19:03:47 +0100 | <geekosaur> | in particular, it varies on NixOS |
| 2025-12-11 19:03:55 +0100 | <geekosaur> | see `patchelf` |
| 2025-12-11 19:04:09 +0100 | Guest87 | (~Guest87@2405:201:d006:986f:5c73:3a20:69d:7d07) (Quit: Client closed) |
| 2025-12-11 19:05:20 +0100 | <haskellbridge> | <sm> I guess my point is, as we work with computers and tools we are working with very complex state which will never be entirely bug free, sometimes it's more cost effective to try a state reset than to debug what's going wrong |
| 2025-12-11 19:06:33 +0100 | Googulator24 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 19:06:43 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-11 19:06:45 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 19:06:55 +0100 | Googulator24 | (~Googulato@87-97-86-146.pool.digikabel.hu) |
| 2025-12-11 19:07:18 +0100 | Googulator24 | Googulator |
| 2025-12-11 19:09:19 +0100 | Square | (~Square4@user/square) (Ping timeout: 240 seconds) |
| 2025-12-11 19:09:21 +0100 | <gentauro> | haskellbridge: that's actually the foundation of Erlang right? We know we are gonna fail at some point, lets add that to the equation. |
| 2025-12-11 19:10:23 +0100 | <EvanR> | well, transactional semantics are a good way to deal with that assumption |
| 2025-12-11 19:10:38 +0100 | <EvanR> | which is not what erlang is usually promoting |
| 2025-12-11 19:11:05 +0100 | <haskellbridge> | <sm> I know php is a good example, you get a fresh state every request |
| 2025-12-11 19:11:46 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 19:11:49 +0100 | <haskellbridge> | <sm> that's running software rather than dev in process, but you know what I mean |
| 2025-12-11 19:12:01 +0100 | <haskellbridge> | <sm> same principle |
| 2025-12-11 19:12:45 +0100 | <haskellbridge> | <sm> I haven't used erlang, but yes that sounds right, they like to throw something away if it fails |
| 2025-12-11 19:14:31 +0100 | <haskellbridge> | <Morj> I've been learning erlang recently, and haven't seen anything about transactional semantics. Sad |
| 2025-12-11 19:14:39 +0100 | <EvanR> | ;_; |
| 2025-12-11 19:14:44 +0100 | <haskellbridge> | <Morj> Sadder still is that I thought I finished learning |
| 2025-12-11 19:15:06 +0100 | <Rembane> | Finally max level! |
| 2025-12-11 19:15:27 +0100 | ft | (~ft@p508db844.dip0.t-ipconnect.de) ft |
| 2025-12-11 19:15:58 +0100 | <EvanR> | level 60, you're done |
| 2025-12-11 19:16:10 +0100 | <EvanR> | return to the world |
| 2025-12-11 19:18:46 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-12-11 19:28:50 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-12-11 19:30:24 +0100 | spew | (~spew@user/spew) (Quit: WeeChat 4.7.2) |
| 2025-12-11 19:31:10 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 245 seconds) |
| 2025-12-11 19:36:55 +0100 | raym | (~ray@user/raym) (Ping timeout: 240 seconds) |
| 2025-12-11 19:38:35 +0100 | raym | (~ray@user/raym) raym |
| 2025-12-11 19:42:04 +0100 | kuribas | (~user@2a02:1808:cd:df9d:1dcb:cff3:20e8:95d8) (Ping timeout: 246 seconds) |
| 2025-12-11 19:43:13 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2025-12-11 19:43:27 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Ping timeout: 252 seconds) |
| 2025-12-11 19:45:22 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-12-11 19:45:28 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-11 19:50:57 +0100 | __monty__ | (~toonn@user/toonn) (Ping timeout: 256 seconds) |
| 2025-12-11 19:57:06 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-11 19:57:28 +0100 | omidmash | (~omidmash@user/omidmash) (Quit: The Lounge - https://thelounge.chat) |
| 2025-12-11 19:58:38 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-11 20:01:02 +0100 | Googulator | (~Googulato@87-97-86-146.pool.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 20:01:09 +0100 | Googulator | (~Googulato@87-97-86-146.pool.digikabel.hu) |
| 2025-12-11 20:01:30 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-11 20:02:25 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-11 20:03:05 +0100 | omidmash | (~omidmash@user/omidmash) omidmash |
| 2025-12-11 20:03:48 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 20:05:36 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-12-11 20:06:47 +0100 | kuribas | (~user@2a02:1808:cd:df9d:3fd8:99c:a12:7c8) kuribas |
| 2025-12-11 20:14:21 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-12-11 20:15:43 +0100 | tabaqui1 | (~tabaqui@167.71.80.236) (Ping timeout: 240 seconds) |
| 2025-12-11 20:16:49 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2025-12-11 20:20:28 +0100 | yin | (~zero@user/zero) (Remote host closed the connection) |
| 2025-12-11 20:23:36 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 20:24:40 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-11 20:24:49 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-11 20:29:00 +0100 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2025-12-11 20:30:48 +0100 | Googulator58 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 20:30:51 +0100 | Googulator | (~Googulato@87-97-86-146.pool.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 20:31:28 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-11 20:31:46 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2025-12-11 20:32:48 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-12-11 20:35:59 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-11 20:42:30 +0100 | vetkat | (~vetkat@user/vetkat) (Read error: Connection reset by peer) |
| 2025-12-11 20:42:53 +0100 | vetkat | (~vetkat@user/vetkat) vetkat |
| 2025-12-11 20:46:27 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-11 20:47:07 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-12-11 20:50:31 +0100 | polykernel | (~polykerne@user/polykernel) (Remote host closed the connection) |
| 2025-12-11 20:50:59 +0100 | polykernel | (~polykerne@user/polykernel) polykernel |
| 2025-12-11 20:57:33 +0100 | <bwe> | Reader & ReaderT: I've now grasped the concept of hiding an (read only) input argument within Reader. Also it's straightforward to have a nested structure of functions that propagate this way the argument to the terminal function. What causes frustration right now is: `ReaderT ReadArg Parser Result` when is which bind operator (`<-`) working in which context (and what does it expect), i.e. ReaderT or Parser? -- Can you recommend a tutorial / paper that wal |
| 2025-12-11 20:57:33 +0100 | <bwe> | ks through some examples of this kind? |
| 2025-12-11 20:59:18 +0100 | <haskellbridge> | <Zemyla> It's operating in the Reader context, and if you want to run a Parser value, you need to lift it. |
| 2025-12-11 20:59:33 +0100 | <haskellbridge> | <Zemyla> Or else use a typeclass that lifts it automatically. |
| 2025-12-11 21:00:33 +0100 | <bwe> | Zemyla: Do I want in this case something like `liftIO` but for Reader context? |
| 2025-12-11 21:02:40 +0100 | <c_wraith> | :t lift |
| 2025-12-11 21:02:41 +0100 | <lambdabot> | (MonadTrans t, Monad m) => m a -> t m a |
| 2025-12-11 21:03:08 +0100 | <c_wraith> | that's... the *sole* operation specific to monad transformers |
| 2025-12-11 21:03:54 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-11 21:03:59 +0100 | <bwe> | lift ... then is adding another layer of Reader to Parser so it matches up to the expected type |
| 2025-12-11 21:04:52 +0100 | kuribas | (~user@2a02:1808:cd:df9d:3fd8:99c:a12:7c8) (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)) |
| 2025-12-11 21:04:59 +0100 | <c_wraith> | there are some rules it must follow.. lift a >>= \x -> lift (f x) must be equivalent to lift (a >>= \x -> f x) |
| 2025-12-11 21:05:12 +0100 | <c_wraith> | that's really the only rule you need, actually |
| 2025-12-11 21:08:26 +0100 | Square2 | (~Square@user/square) Square |
| 2025-12-11 21:09:03 +0100 | <bwe> | Ok, thanks, that instantly relieves me of some frustration if I use that in my code. -- Then, what's the confusion about transformer libraries? There's one I am warned about whereas I should use the other. What's true? |
| 2025-12-11 21:09:20 +0100 | <monochrom> | To a large extent, ReaderT makes more sense if you follow Typeclassopedia in reinventing ReaderT from scratch (or any of those transformers). |
| 2025-12-11 21:11:06 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-12-11 21:11:43 +0100 | <bwe> | Oh, I meant https://hackage.haskell.org/package/mtl vs. https://hackage.haskell.org/package/transformers |
| 2025-12-11 21:11:56 +0100 | <c_wraith> | the funny thing is there is no argument there. |
| 2025-12-11 21:12:01 +0100 | trickard_ | trickard |
| 2025-12-11 21:12:11 +0100 | <c_wraith> | the argument is between mtl and monads-tf. mtl won. |
| 2025-12-11 21:12:29 +0100 | <c_wraith> | transformers was created to share as much code as possible between mtl and monads-tf |
| 2025-12-11 21:12:51 +0100 | <c_wraith> | transformers has all the actual implementations |
| 2025-12-11 21:13:05 +0100 | <c_wraith> | mtl provides a slightly different API for them |
| 2025-12-11 21:13:14 +0100 | <monochrom> | Yeah you must have been reading very outdated material. There was a divide two decades ago. They were unified since then. |
| 2025-12-11 21:13:35 +0100 | <bwe> | That's interesting to learn. So my default is then any or just mtl? |
| 2025-12-11 21:13:56 +0100 | <c_wraith> | I'm still mildly in favor of using transformers without the mtl layer, but I'm unconcerned. I'll go either way for compatibility |
| 2025-12-11 21:14:00 +0100 | <monochrom> | Today, transformers defines ReaderT, and mtl defines the MonadReader class and puts ReaderT as an instance. That is all. |
| 2025-12-11 21:14:14 +0100 | <monochrom> | (and mtl re-exports transformers) |
| 2025-12-11 21:14:55 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 240 seconds) |
| 2025-12-11 21:15:48 +0100 | Googulator22 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 21:15:48 +0100 | Googulator58 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 21:16:43 +0100 | <dolio> | At some point mtl had everything directly in it, and then there were a couple of split up packages on top of transformers. But eventually mtl just got turned into essentially the same thing as the fundeps one. |
| 2025-12-11 21:17:09 +0100 | <dolio> | Because it was silly having 3 things like mtl. |
| 2025-12-11 21:17:41 +0100 | <bwe> | monochrom: that's complicated enough :) |
| 2025-12-11 21:18:22 +0100 | <monochrom> | I used to tell fake news about it in the form of "Vienna Peace Conference established the Concert of MTL" >:) |
| 2025-12-11 21:18:35 +0100 | <bwe> | https://play.haskell.org/saved/CIlt9hCq <- what's the right approach to mix Reader and non Reader parsers? I mean line 4. |
| 2025-12-11 21:19:23 +0100 | <monochrom> | I thought you knew about `lift`? |
| 2025-12-11 21:19:59 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-11 21:20:00 +0100 | <mauke> | why is there a runReaderT in there? |
| 2025-12-11 21:20:26 +0100 | <monochrom> | I believe it is to reinvent `lift`. :) |
| 2025-12-11 21:20:35 +0100 | <bwe> | mauke: because parserB and parser C are of type `Parser Result` |
| 2025-12-11 21:20:52 +0100 | <mauke> | parserA <|> lift parserB <|> lift parserC ? |
| 2025-12-11 21:21:20 +0100 | <monochrom> | Although, can you still use <|> at the ReaderT level? |
| 2025-12-11 21:21:28 +0100 | <bwe> | okay, the thing then is that my working context is already ReaderT |
| 2025-12-11 21:21:30 +0100 | <monochrom> | Ah probably yes. |
| 2025-12-11 21:22:15 +0100 | <EvanR> | ReaderT, (one of) haskell's (many) answers to dependency injection |
| 2025-12-11 21:24:20 +0100 | <c_wraith> | dependency injection is such a complicated name for "pass values around" |
| 2025-12-11 21:26:28 +0100 | <EvanR> | haha |
| 2025-12-11 21:26:50 +0100 | <monochrom> | I would say "higher-order functions" but OK! |
| 2025-12-11 21:27:13 +0100 | <EvanR> | the dependency may not be a function |
| 2025-12-11 21:27:34 +0100 | <monochrom> | <facetious> "callback" is a complicated way to say "continuation" </facectious> |
| 2025-12-11 21:28:04 +0100 | <dolio> | I don't know which of those deserves to be considered more complicated. |
| 2025-12-11 21:28:07 +0100 | <mauke> | lower-chrer |
| 2025-12-11 21:28:29 +0100 | <EvanR> | dependency itself is kind a can of worms |
| 2025-12-11 21:28:38 +0100 | <EvanR> | evokes a lot of infrastructure |
| 2025-12-11 21:29:06 +0100 | <EvanR> | but here it boils down to, this express has free variables. But we're calling it a dependency |
| 2025-12-11 21:29:11 +0100 | <EvanR> | expression |
| 2025-12-11 21:32:14 +0100 | <monochrom> | Oh! Then "lambda lifting" :) |
| 2025-12-11 21:32:25 +0100 | <bwe> | f xs = (_ . map returnsSomeReader $ xs) :: [Text] -> Reader Config [Result] -- how do I transform [Reader Config Result] to `Reader Config [Result]`? |
| 2025-12-11 21:32:58 +0100 | <monochrom> | Does `sequence` do what you want? |
| 2025-12-11 21:33:43 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-11 21:35:00 +0100 | <mauke> | :t sequence |
| 2025-12-11 21:35:01 +0100 | <lambdabot> | (Traversable t, Monad m) => t (m a) -> m (t a) |
| 2025-12-11 21:35:11 +0100 | <mauke> | :t traverse |
| 2025-12-11 21:35:12 +0100 | <lambdabot> | (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) |
| 2025-12-11 21:35:40 +0100 | <bwe> | My intuition led me to traverse :). |
| 2025-12-11 21:36:18 +0100 | <mauke> | :t \f -> sequence . map f |
| 2025-12-11 21:36:18 +0100 | <lambdabot> | Monad m => (a1 -> m a2) -> [a1] -> m [a2] |
| 2025-12-11 21:36:39 +0100 | <mauke> | :t \f -> sequenceA . map f |
| 2025-12-11 21:36:40 +0100 | <lambdabot> | Applicative f => (a1 -> f a2) -> [a1] -> f [a2] |
| 2025-12-11 21:38:10 +0100 | AlexNoo | (~AlexNoo@85.174.180.40) |
| 2025-12-11 21:40:10 +0100 | <Leary> | bwe: Re mixing levels, this <https://play.haskell.org/saved/vdNe7NSH> is one option, but you're probably better off reversing the order of `ReaderT` and `ParsecT`, since that way the only operation you need to `lift` is `ask`. |
| 2025-12-11 21:45:32 +0100 | <bwe> | Leary: …you do that with `k (`runReaderT` r)` right? |
| 2025-12-11 21:47:41 +0100 | Wygulmage | (~Wygulmage@user/Wygulmage) Wygulmage |
| 2025-12-11 21:49:28 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-11 21:51:04 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-12-11 21:55:25 +0100 | <Leary> | bwe: I'm not sure what you're asking. Regardless, the way I'd actually recommend goes like so: https://play.haskell.org/saved/8oJlQyYR |
| 2025-12-11 21:55:46 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 246 seconds) |
| 2025-12-11 21:56:42 +0100 | Square | (~Square4@user/square) Square |
| 2025-12-11 21:57:41 +0100 | Pixi__ | (~Pixi@user/pixi) (Quit: Leaving) |
| 2025-12-11 21:59:37 +0100 | Square2 | (~Square@user/square) (Ping timeout: 246 seconds) |
| 2025-12-11 22:02:13 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-11 22:02:53 +0100 | <bwe> | Leary: wow, that's actually beautiful. |
| 2025-12-11 22:06:32 +0100 | <monochrom> | You can furthermore omit the `lift` because ParsercT e s (Reader r) is an instance of MonadReader too. (Generally, ParsecT e s m, if m is an instance of MonadReader). |
| 2025-12-11 22:12:15 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-12-11 22:13:58 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-11 22:14:26 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-11 22:14:38 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-11 22:14:56 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-11 22:23:19 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 252 seconds) |
| 2025-12-11 22:25:38 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2025-12-11 22:29:33 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-12-11 22:36:17 +0100 | Pixi | (~Pixi@user/pixi) Pixi |
| 2025-12-11 22:43:09 +0100 | humasect | (~humasect@192.249.132.90) |
| 2025-12-11 22:45:35 +0100 | Googulator22 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 22:45:44 +0100 | Googulator22 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 22:47:59 +0100 | <bwe> | thanks, mauke, monochrom, Leary, c_wraith and Zemyla |
| 2025-12-11 22:48:37 +0100 | humasect | (~humasect@192.249.132.90) (Ping timeout: 264 seconds) |
| 2025-12-11 22:55:23 +0100 | milan | (~milan@88.212.61.169) (Quit: WeeChat 4.5.2) |
| 2025-12-11 22:56:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 22:57:07 +0100 | michalz | (~michalz@185.246.207.215) (Remote host closed the connection) |
| 2025-12-11 22:58:51 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:e9bb:9c42:9519:597d) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-12-11 22:59:03 +0100 | Athas | (athas@sigkill.dk) |
| 2025-12-11 23:01:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 23:08:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 23:13:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-11 23:15:51 +0100 | Googulator7 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) |
| 2025-12-11 23:15:51 +0100 | Googulator22 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 23:24:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 23:28:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-11 23:35:03 +0100 | Wygulmage | (~Wygulmage@user/Wygulmage) (Ping timeout: 272 seconds) |
| 2025-12-11 23:38:31 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-12-11 23:39:13 +0100 | Everything | (~Everythin@172-232-54-192.ip.linodeusercontent.com) Everything |
| 2025-12-11 23:40:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-11 23:40:49 +0100 | pavonia | (~user@user/siracusa) siracusa |