| 2025-02-07 00:07:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 00:12:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 00:22:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 00:27:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 00:29:30 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-07 00:30:50 +0100 | kilolympus | (~kilolympu@2a04:ee41:4:32b3:7e9f:f324:8323:112e) kilolympus |
| 2025-02-07 00:31:45 +0100 | <kilolympus> | Not exactly sure where I should ask this (so pardon me if this is the wrong place), but is there a list of available libraries on the Hackage build server? |
| 2025-02-07 00:32:16 +0100 | <kilolympus> | I want to check if libopus is available to link to while building, or whether I should be prepared for a build failure and need to upload docs manually |
| 2025-02-07 00:35:59 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-02-07 00:37:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 00:38:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-02-07 00:42:42 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 00:43:03 +0100 | <geekosaur> | #haskell-infrastructure would probably be the right place, but I'm pretty sure if it's not in a minimal Ubuntu install it won't be there and won't be installed on request |
| 2025-02-07 00:44:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 00:47:25 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-02-07 00:54:30 +0100 | Guest64 | (~Guest64@202.20.31.4) |
| 2025-02-07 00:55:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 00:56:36 +0100 | Googulator | (~Googulato@2a01-036d-0106-418c-6daf-e703-6cee-d20f.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-02-07 00:56:52 +0100 | Googulator | (~Googulato@2a01-036d-0106-418c-6daf-e703-6cee-d20f.pool6.digikabel.hu) |
| 2025-02-07 01:00:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-02-07 01:05:44 +0100 | Guest64 | HEGX64 |
| 2025-02-07 01:10:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 01:15:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 01:19:07 +0100 | otbergsten | (~otbergste@user/otbergsten) () |
| 2025-02-07 01:22:01 +0100 | capslair^ | (~capslair@108.192.66.114) |
| 2025-02-07 01:23:42 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-02-07 01:25:02 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4c17:71c9:4c89:f803) (Ping timeout: 268 seconds) |
| 2025-02-07 01:26:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 01:26:35 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 01:26:55 +0100 | <davean> | kilolympus: https://github.com/haskell-infra/hackage-doc-builder-config |
| 2025-02-07 01:27:13 +0100 | <davean> | kilolympus: you can ask for a modification of cours |
| 2025-02-07 01:27:48 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 01:29:05 +0100 | sprotte24 | (~sprotte24@p200300d16f04b500f0fec28a072486d6.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-02-07 01:30:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-02-07 01:31:27 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 01:35:53 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-07 01:41:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 01:44:00 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f31bc6d2d03cd52feea.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-02-07 01:44:32 +0100 | alphabeta | (~kilolympu@213.55.241.40) kilolympus |
| 2025-02-07 01:44:59 +0100 | kilolympus | (~kilolympu@2a04:ee41:4:32b3:7e9f:f324:8323:112e) (Ping timeout: 265 seconds) |
| 2025-02-07 01:46:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 01:46:37 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 268 seconds) |
| 2025-02-07 01:48:04 +0100 | catties | bunnies |
| 2025-02-07 01:48:26 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-07 01:53:27 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2025-02-07 01:53:51 +0100 | euleritian | (~euleritia@77.23.250.232) |
| 2025-02-07 01:54:23 +0100 | euleritian | (~euleritia@77.23.250.232) (Remote host closed the connection) |
| 2025-02-07 01:56:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 01:57:02 +0100 | euleritian | (~euleritia@77.23.250.232) |
| 2025-02-07 02:01:05 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2025-02-07 02:01:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-02-07 02:02:03 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-07 02:03:16 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 02:08:12 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 02:12:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 02:13:46 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-02-07 02:15:34 +0100 | alphabeta | (~kilolympu@213.55.241.40) (Quit: See you later! :)) |
| 2025-02-07 02:18:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-07 02:19:31 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 02:23:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 02:29:08 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds) |
| 2025-02-07 02:30:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 02:32:15 +0100 | euleritian | (~euleritia@77.23.250.232) (Remote host closed the connection) |
| 2025-02-07 02:32:36 +0100 | euleritian | (~euleritia@77.23.250.232) |
| 2025-02-07 02:34:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-02-07 02:36:53 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Quit: So long and thanks for all the fish) |
| 2025-02-07 02:37:29 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-02-07 02:45:10 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-02-07 02:50:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 02:52:11 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-02-07 02:57:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 03:07:55 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 03:08:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 03:12:20 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-02-07 03:13:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 03:19:10 +0100 | tavare | (~tavare@150.129.88.189) |
| 2025-02-07 03:19:10 +0100 | tavare | (~tavare@150.129.88.189) (Changing host) |
| 2025-02-07 03:19:10 +0100 | tavare | (~tavare@user/tavare) tavare |
| 2025-02-07 03:24:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 03:29:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 03:38:53 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 03:39:38 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 03:39:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 03:44:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 03:49:39 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 03:52:02 +0100 | dostoevsky | (~dostoevsk@user/dostoevsky) dostoevsky |
| 2025-02-07 03:52:41 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 03:54:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 03:55:59 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 04:00:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 276 seconds) |
| 2025-02-07 04:01:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-02-07 04:01:45 +0100 | Sgeo_ | (~Sgeo@user/sgeo) Sgeo |
| 2025-02-07 04:05:00 +0100 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 252 seconds) |
| 2025-02-07 04:05:22 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-02-07 04:08:22 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-02-07 04:11:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 04:15:30 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-02-07 04:15:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-07 04:20:08 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-02-07 04:20:21 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Quit: Lost terminal) |
| 2025-02-07 04:20:47 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-07 04:21:33 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) |
| 2025-02-07 04:25:30 +0100 | prasad | (~Thunderbi@c-73-75-25-251.hsd1.in.comcast.net) (Client Quit) |
| 2025-02-07 04:26:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 04:31:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-02-07 04:31:39 +0100 | hammond | (proscan@gateway04.insomnia247.nl) (Ping timeout: 246 seconds) |
| 2025-02-07 04:31:40 +0100 | agent314 | (~quassel@79.127.222.205) agent314 |
| 2025-02-07 04:33:26 +0100 | vulpine | (xfnw@user/meow/xfnw) (Read error: Connection reset by peer) |
| 2025-02-07 04:33:47 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:33:51 +0100 | vulpine | (xfnw@user/meow/xfnw) (Max SendQ exceeded) |
| 2025-02-07 04:34:11 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:34:13 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:37:58 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:38:00 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:39:06 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:39:08 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:42:08 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:42:10 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:42:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 04:44:22 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 04:44:59 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:45:03 +0100 | vulpine | (xfnw@user/meow/xfnw) (Max SendQ exceeded) |
| 2025-02-07 04:46:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 04:47:34 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:47:39 +0100 | vulpine | (xfnw@user/meow/xfnw) (Max SendQ exceeded) |
| 2025-02-07 04:49:09 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-02-07 04:50:39 +0100 | saimazoon | (~hrtz@user/haritz) (Ping timeout: 260 seconds) |
| 2025-02-07 04:51:00 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:51:02 +0100 | alp__ | (~alp@2001:861:8ca0:4940:c852:f016:ee1c:5cf) (Remote host closed the connection) |
| 2025-02-07 04:51:02 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:51:20 +0100 | alp__ | (~alp@2001:861:8ca0:4940:7350:41fe:ef34:5f0f) |
| 2025-02-07 04:52:43 +0100 | alp__ | (~alp@2001:861:8ca0:4940:7350:41fe:ef34:5f0f) (Remote host closed the connection) |
| 2025-02-07 04:53:01 +0100 | alp__ | (~alp@2001:861:8ca0:4940:eaf7:425c:a3f4:9d66) |
| 2025-02-07 04:53:43 +0100 | hammond | (proscan@gateway04.insomnia247.nl) |
| 2025-02-07 04:54:25 +0100 | alp__ | (~alp@2001:861:8ca0:4940:eaf7:425c:a3f4:9d66) (Remote host closed the connection) |
| 2025-02-07 04:54:43 +0100 | alp__ | (~alp@2001:861:8ca0:4940:569c:57b4:f240:3d2b) |
| 2025-02-07 04:55:04 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:55:06 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:56:06 +0100 | alp__ | (~alp@2001:861:8ca0:4940:569c:57b4:f240:3d2b) (Remote host closed the connection) |
| 2025-02-07 04:56:24 +0100 | alp__ | (~alp@2001:861:8ca0:4940:e670:d145:9f1b:674) |
| 2025-02-07 04:56:35 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) |
| 2025-02-07 04:56:38 +0100 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host) |
| 2025-02-07 04:56:38 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2025-02-07 04:57:39 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:57:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 04:57:48 +0100 | alp__ | (~alp@2001:861:8ca0:4940:e670:d145:9f1b:674) (Remote host closed the connection) |
| 2025-02-07 04:58:06 +0100 | alp__ | (~alp@2001:861:8ca0:4940:5024:ff7b:ce1f:1128) |
| 2025-02-07 04:58:18 +0100 | vulpine | (xfnw@user/meow/xfnw) (Excess Flood) |
| 2025-02-07 04:59:31 +0100 | alp__ | (~alp@2001:861:8ca0:4940:5024:ff7b:ce1f:1128) (Remote host closed the connection) |
| 2025-02-07 04:59:38 +0100 | vulpine | (xfnw@user/meow/xfnw) xfnw |
| 2025-02-07 04:59:49 +0100 | alp__ | (~alp@2001:861:8ca0:4940:e025:f618:6016:7d8a) |
| 2025-02-07 05:01:13 +0100 | alp__ | (~alp@2001:861:8ca0:4940:e025:f618:6016:7d8a) (Remote host closed the connection) |
| 2025-02-07 05:01:31 +0100 | alp__ | (~alp@2001:861:8ca0:4940:cb5b:ce0e:5074:ffb7) |
| 2025-02-07 05:02:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 05:03:00 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 05:03:13 +0100 | alp_ | (~alp@2001:861:8ca0:4940:c426:72e5:a4bc:f323) |
| 2025-02-07 05:04:38 +0100 | alp_ | (~alp@2001:861:8ca0:4940:c426:72e5:a4bc:f323) (Remote host closed the connection) |
| 2025-02-07 05:04:40 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 05:04:55 +0100 | alp_ | (~alp@2001:861:8ca0:4940:4256:492f:9aa8:cd35) |
| 2025-02-07 05:07:02 +0100 | alp__ | (~alp@2001:861:8ca0:4940:cb5b:ce0e:5074:ffb7) (Ping timeout: 268 seconds) |
| 2025-02-07 05:08:13 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-07 05:09:53 +0100 | alp_ | (~alp@2001:861:8ca0:4940:4256:492f:9aa8:cd35) (Ping timeout: 252 seconds) |
| 2025-02-07 05:10:45 +0100 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-10-142-112-184-232.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2025-02-07 05:13:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 05:13:33 +0100 | driib318 | (~driib@vmi931078.contaboserver.net) driib |
| 2025-02-07 05:17:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 05:20:23 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 05:26:32 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 05:28:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 05:32:06 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 05:32:06 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) (Remote host closed the connection) |
| 2025-02-07 05:32:16 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2025-02-07 05:34:12 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-07 05:35:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-02-07 05:35:53 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 05:36:18 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 05:36:18 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
| 2025-02-07 05:36:18 +0100 | tnt2 | tnt1 |
| 2025-02-07 05:36:57 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-02-07 05:38:03 +0100 | dsrt^ | (~dsrt@108.192.66.114) (Ping timeout: 252 seconds) |
| 2025-02-07 05:39:07 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) MyNetAz |
| 2025-02-07 05:39:39 +0100 | capslair^ | (~capslair@108.192.66.114) (Ping timeout: 260 seconds) |
| 2025-02-07 05:41:50 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-02-07 05:46:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 05:47:38 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 05:48:10 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-02-07 05:49:03 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 05:51:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 05:56:00 +0100 | dsrt^ | (~dsrt@108.192.66.114) |
| 2025-02-07 05:56:05 +0100 | dsrt^ | (~dsrt@108.192.66.114) (Remote host closed the connection) |
| 2025-02-07 05:58:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-02-07 06:02:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 06:02:08 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 06:03:21 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 06:07:03 +0100 | michalz | (~michalz@185.246.207.197) |
| 2025-02-07 06:07:59 +0100 | dsrt^ | (~dsrt@108.192.66.114) |
| 2025-02-07 06:09:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 06:13:44 +0100 | Square | (~Square@user/square) (Quit: Leaving) |
| 2025-02-07 06:14:07 +0100 | Square | (~Square@user/square) Square |
| 2025-02-07 06:19:41 +0100 | jle` | (~jle`@2603:8001:3b02:84d4:6618:6c83:b259:edfc) (Quit: WeeChat 4.5.1) |
| 2025-02-07 06:20:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 06:20:13 +0100 | jle` | (~jle`@2603:8001:3b02:84d4:6618:6c83:b259:edfc) jle` |
| 2025-02-07 06:20:50 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 06:24:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 06:24:59 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-02-07 06:25:13 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-07 06:26:53 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-02-07 06:29:00 +0100 | HEGX64 | (~Guest64@202.20.31.4) (Quit: Client closed) |
| 2025-02-07 06:29:48 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-02-07 06:30:04 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-02-07 06:30:32 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 06:31:52 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 06:35:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 06:40:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 06:41:19 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2025-02-07 06:48:21 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2025-02-07 06:48:54 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
| 2025-02-07 06:50:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 06:55:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 06:56:25 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 06:57:37 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 07:05:16 +0100 | echoreply | (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 2025-02-07 07:06:10 +0100 | echoreply | (~echoreply@45.32.163.16) echoreply |
| 2025-02-07 07:06:17 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 07:07:40 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 07:08:17 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 07:08:54 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 07:10:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-02-07 07:12:50 +0100 | euleritian | (~euleritia@77.23.250.232) (Ping timeout: 268 seconds) |
| 2025-02-07 07:13:04 +0100 | euleritian | (~euleritia@dynamic-176-006-138-232.176.6.pool.telefonica.de) |
| 2025-02-07 07:13:18 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-02-07 07:19:20 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 07:21:08 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 07:21:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 07:21:56 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-02-07 07:26:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 07:30:22 +0100 | euleritian | (~euleritia@dynamic-176-006-138-232.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-02-07 07:30:39 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-07 07:32:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 07:36:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 07:37:14 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-02-07 07:40:59 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2025-02-07 07:48:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 07:53:27 +0100 | CiaoSen | (~Jura@2a05:5800:220:3300:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-02-07 07:55:06 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f97bc6d2d03cd52feea.dip0.t-ipconnect.de) acidjnk |
| 2025-02-07 07:55:23 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2025-02-07 07:55:52 +0100 | euleritian | (~euleritia@dynamic-176-006-138-232.176.6.pool.telefonica.de) |
| 2025-02-07 07:56:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-07 07:57:20 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 07:59:08 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 07:59:12 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-02-07 08:00:23 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 08:01:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 08:03:34 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 08:03:42 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-02-07 08:03:42 +0100 | tnt2 | tnt1 |
| 2025-02-07 08:06:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 08:07:31 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 08:08:17 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
| 2025-02-07 08:08:17 +0100 | tnt2 | tnt1 |
| 2025-02-07 08:11:05 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-02-07 08:11:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 08:12:12 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 08:13:07 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
| 2025-02-07 08:14:56 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 08:16:58 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 08:17:09 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 08:17:56 +0100 | ft | (~ft@p3e9bcd97.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-02-07 08:18:40 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 08:20:03 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 08:20:06 +0100 | tnt2 | tnt1 |
| 2025-02-07 08:20:22 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 08:22:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 08:25:22 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 08:26:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-02-07 08:27:27 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 08:27:28 +0100 | tnt2 | tnt1 |
| 2025-02-07 08:29:59 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-07 08:33:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 08:34:23 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-02-07 08:36:36 +0100 | akegalj | (~akegalj@89-172-213-142.adsl.net.t-com.hr) akegalj |
| 2025-02-07 08:39:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 08:40:35 +0100 | tabaqui1 | (~root@87.200.129.102) tabaqui |
| 2025-02-07 08:45:04 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 08:49:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-02-07 08:50:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 08:54:47 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-02-07 08:55:40 +0100 | Googulator | (~Googulato@2a01-036d-0106-418c-6daf-e703-6cee-d20f.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
| 2025-02-07 08:56:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-02-07 08:58:34 +0100 | <kqr> | I understand on an intellectual level why `const Just :: a -> b -> Maybe b` whereas `const . Just :: a -> b -> Maybe a` but I'd like to have some intuition for why inserting a composition operator sort of swaps the arguments. It feels like there's something happening there that is more fundamental. |
| 2025-02-07 09:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-02-07 09:00:47 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-02-07 09:00:59 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-02-07 09:01:07 +0100 | <mauke> | if f :: a -> b, then const f :: x -> a -> b |
| 2025-02-07 09:01:18 +0100 | <mauke> | and const . f :: a -> x -> b |
| 2025-02-07 09:01:37 +0100 | <mauke> | I don't see it as swapping, really |
| 2025-02-07 09:01:44 +0100 | chele | (~chele@user/chele) chele |
| 2025-02-07 09:01:49 +0100 | <mauke> | it's just where the dummy argument gets inserted |
| 2025-02-07 09:08:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:10:29 +0100 | <kqr> | Aah, I might be starting to get it! |
| 2025-02-07 09:11:18 +0100 | euleritian | (~euleritia@dynamic-176-006-138-232.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-02-07 09:11:36 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-07 09:12:36 +0100 | <kqr> | Since const f is really something like const f _ = f it will swallow a dummy argument before starting to apply f, whereas const . f first applies f and then swallows a dummy argument. Yeah, thinking of it that way helps. |
| 2025-02-07 09:12:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 09:13:02 +0100 | <kqr> | This also helps explain why (const . const . const) f and (const . const . const . f) behaves the way they do! |
| 2025-02-07 09:13:14 +0100 | <kqr> | Thanks |
| 2025-02-07 09:14:55 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) misterfish |
| 2025-02-07 09:17:34 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 09:17:34 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-02-07 09:19:16 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 09:19:16 +0100 | tnt2 | tnt1 |
| 2025-02-07 09:19:52 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2025-02-07 09:20:36 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::9939) ensyde |
| 2025-02-07 09:23:15 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-02-07 09:23:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:28:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-02-07 09:32:13 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::9939) (Quit: WeeChat 4.5.1) |
| 2025-02-07 09:33:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 09:34:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:37:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 09:39:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 09:45:40 +0100 | dhil | (~dhil@2a0c:b381:5bf:3500:33f8:3d71:b2ae:2adc) dhil |
| 2025-02-07 09:48:45 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 246 seconds) |
| 2025-02-07 09:49:15 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 09:54:26 +0100 | <dminuoso> | tomsmeding: By the way, the error was because I was missing a Generic instance. |
| 2025-02-07 09:54:56 +0100 | <dminuoso> | I'm half-way convinced that this could be a GHC diagnostics bug. |
| 2025-02-07 09:55:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:56:00 +0100 | <dminuoso> | Ill try and condense this into an isolated reproducer without servant next week. |
| 2025-02-07 09:58:34 +0100 | <dminuoso> | At this point I've finally settled on an opinion: Servant while being a neat experiment is not worth the type trickery: TH is more suitable for the job. |
| 2025-02-07 09:59:09 +0100 | <dminuoso> | It's *much* faster and can yield much better errors. |
| 2025-02-07 10:01:44 +0100 | mcfrdy | (~mcfrdy@user/mcfrdy) mcfrdy |
| 2025-02-07 10:03:50 +0100 | sim590 | (~simon@24-122-69-233.resi.cgocable.ca) sim590 |
| 2025-02-07 10:09:29 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 10:09:33 +0100 | AlexNoo_ | (~AlexNoo@178.34.151.30) |
| 2025-02-07 10:12:17 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 10:13:00 +0100 | AlexZenon | (~alzenon@5.139.233.186) (Ping timeout: 276 seconds) |
| 2025-02-07 10:13:14 +0100 | AlexNoo | (~AlexNoo@5.139.233.186) (Ping timeout: 260 seconds) |
| 2025-02-07 10:14:45 +0100 | akegalj | (~akegalj@89-172-213-142.adsl.net.t-com.hr) (Ping timeout: 268 seconds) |
| 2025-02-07 10:16:32 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-02-07 10:17:22 +0100 | <tomsmeding> | dminuoso: you know, given the appearance of that GServant or what was it, I already had an inkling that it might be that |
| 2025-02-07 10:18:13 +0100 | AlexZenon | (~alzenon@178.34.151.30) |
| 2025-02-07 10:19:25 +0100 | <tomsmeding> | a lot of understanding how to read (and fix) type errors from GHC comes down to honing your mental model of in what situations these diagnostics arise, and that mental model is distressingly associative (as opposed to logical) |
| 2025-02-07 10:19:30 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-02-07 10:21:00 +0100 | <tomsmeding> | okay let me be more precise: I didn't intuit that _you_ were missing a Generic instance. Just that it was something with GServant not reducing due to (I didn't think this far) |
| 2025-02-07 10:21:11 +0100 | sa | (sid1055@id-1055.tinside.irccloud.com) (Ping timeout: 252 seconds) |
| 2025-02-07 10:21:14 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 10:21:15 +0100 | <hololeap> | I'm looking for any comments on ways this code can be improved: https://bpa.st/FTCA |
| 2025-02-07 10:21:31 +0100 | <tomsmeding> | probably because essentially any time I've seen G* stuff in type errors, it was because the generics stuff was wrong, not because something else was :p |
| 2025-02-07 10:22:22 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-02-07 10:22:29 +0100 | <dminuoso> | tomsmeding: If this was some missing instance of some obscure deeply hidden GServerantSomething class that would have been obvious. |
| 2025-02-07 10:22:42 +0100 | akegalj | (~akegalj@141-136-207-93.dsl.iskon.hr) |
| 2025-02-07 10:23:10 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 10:23:16 +0100 | <dminuoso> | Im thinking the reason this all happened was because these are associated types of typeclass instances, and if the lack of a specific instance meant another instance was matched, I guess that could lead to associated types resolving to some nonsense. |
| 2025-02-07 10:24:03 +0100 | <tomsmeding> | > let f = foldr (\c -> maybe (if c == '0' then Nothing else Just [c]) (Just . (c:))) Nothing in (f "12300", f "123", f "00", f "") |
| 2025-02-07 10:24:03 +0100 | sa | (sid1055@id-1055.tinside.irccloud.com) sa |
| 2025-02-07 10:24:04 +0100 | <lambdabot> | (Just "123",Just "123",Nothing,Nothing) |
| 2025-02-07 10:24:29 +0100 | <tomsmeding> | hololeap: ^ |
| 2025-02-07 10:24:51 +0100 | <tomsmeding> | dminuoso: but it didn't resolve to some nonsense here, right? It just didn't reduce. |
| 2025-02-07 10:24:59 +0100 | <tomsmeding> | (if I remember the error correctly) |
| 2025-02-07 10:25:23 +0100 | <dminuoso> | hololeap: reverse . dropWhile (== '0') . reverse ? |
| 2025-02-07 10:25:34 +0100 | <tomsmeding> | hence the stuck application of GServant just appeared in the error verbatim |
| 2025-02-07 10:25:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 10:25:40 +0100 | <hololeap> | > let f = foldr (\c -> maybe (if c == '0' then Nothing else Just [c]) (Just . (c:))) Nothing in f "120300" |
| 2025-02-07 10:25:41 +0100 | <lambdabot> | Just "1203" |
| 2025-02-07 10:25:43 +0100 | <dminuoso> | Just tossing it out there, since "improve" can go either way. |
| 2025-02-07 10:25:57 +0100 | <hololeap> | hm that does seem to work |
| 2025-02-07 10:26:12 +0100 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-02-07 10:26:12 +0100 | <tomsmeding> | it works because once it switches to Just, it never becomes Nothing any more |
| 2025-02-07 10:26:25 +0100 | <dminuoso> | tomsmeding: I was just holding :k! wrong yesterday, it did resolve to some nonsense. |
| 2025-02-07 10:26:26 +0100 | <tomsmeding> | but yes dminuoso's suggestion has a lot of readability merit :p |
| 2025-02-07 10:26:31 +0100 | <tomsmeding> | ah! |
| 2025-02-07 10:26:34 +0100 | <dminuoso> | tomsmeding: But GHC didnt even tell us about that. |
| 2025-02-07 10:26:42 +0100 | <dminuoso> | Just that these two type expressions did not match. |
| 2025-02-07 10:26:55 +0100 | <tomsmeding> | yes, I agree that this is rather useless |
| 2025-02-07 10:27:10 +0100 | Googulator | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-02-07 10:27:12 +0100 | <tomsmeding> | on the other hand, GHC has a tricky job in deciding whether, and how far, to reduce type families and synonyms in type errors |
| 2025-02-07 10:27:16 +0100 | <hololeap> | yeah dminuoso's was my first implementation, but I wanted to see if I could do it with a right fold |
| 2025-02-07 10:27:29 +0100 | <tomsmeding> | if there's a FilePath around, you probably want that to stay a FilePath -- and you don't want String to turn into [Char] |
| 2025-02-07 10:27:43 +0100 | <tomsmeding> | but you perhaps _do_ want to reduce GServant -- but perhaps also keep the original around, or something? |
| 2025-02-07 10:27:46 +0100 | <tomsmeding> | This is not trivial to solve |
| 2025-02-07 10:28:31 +0100 | <tomsmeding> | dminuoso: also it's funny that you say that TH is *much* faster. TH is not known for its speediness |
| 2025-02-07 10:28:39 +0100 | <dminuoso> | tomsmeding: See, as far as I'm concerned it can just tell me "Could not match <expr1> with <expr2>" and then below in the context tell me stuff about <expr1> and <expr2> |
| 2025-02-07 10:29:05 +0100 | <dminuoso> | tomsmeding: Compared to programming propagation into generics and type system? Uh. |
| 2025-02-07 10:29:12 +0100 | <dminuoso> | Not sure why TH should be slow to begin with. |
| 2025-02-07 10:29:47 +0100 | <dminuoso> | Now that we're actually talking about it, how is TH executed anyway? Is that via bytecode? |
| 2025-02-07 10:30:01 +0100 | <tomsmeding> | dminuoso: exactly, it's funny because TH is known to be not-fast, but then constraint propagation is just devastatingly slow |
| 2025-02-07 10:30:03 +0100 | <merijn> | dminuoso: TH is kinda slow compared to regular compilation |
| 2025-02-07 10:30:15 +0100 | <merijn> | but much faster than complex type level computing |
| 2025-02-07 10:30:21 +0100 | <merijn> | dminuoso: Don't ask |
| 2025-02-07 10:30:26 +0100 | <tomsmeding> | TH is run through bytecode in ghci-style, indeed |
| 2025-02-07 10:30:36 +0100 | <tomsmeding> | if you're cross-compiling or have external-interpreter, it's black magic |
| 2025-02-07 10:30:39 +0100 | <merijn> | It's a mess, which is why cross compilation and TH work so nightmarish |
| 2025-02-07 10:30:50 +0100 | <merijn> | No proper separation of host vs target in TH |
| 2025-02-07 10:30:59 +0100 | <haskellbridge> | <magic_rb> Ghc plugins are worse :) |
| 2025-02-07 10:31:02 +0100 | <tomsmeding> | GHC ensures that TH runs on the target architecture, not the host architecture, when cross compiling |
| 2025-02-07 10:31:06 +0100 | <dminuoso> | When I pondered about TH, I kept thinking that one of the problems of TH is that it's meddled into the linkage of the program too much. |
| 2025-02-07 10:31:06 +0100 | <tomsmeding> | this produces... difficulties |
| 2025-02-07 10:31:40 +0100 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 244 seconds) |
| 2025-02-07 10:31:42 +0100 | <haskellbridge> | <magic_rb> You can get TH working while cross compiling, its not even _that_ bad to get it working. But plugins are just unsupported period |
| 2025-02-07 10:32:02 +0100 | <tomsmeding> | also if your package depends on C libraries, these are already linked in when interpreting TH -- and it takes the dynamic libraries, even if you link the libraries statically in the package normally |
| 2025-02-07 10:32:04 +0100 | <tomsmeding> | iirc |
| 2025-02-07 10:32:33 +0100 | <dminuoso> | Yeah and that's slightly bizarre. |
| 2025-02-07 10:32:55 +0100 | <tomsmeding> | merijn: isn't that there _is_ proper separation, we just chose, by historical accident, to take the side that's awful to support for GHC? |
| 2025-02-07 10:33:19 +0100 | <tomsmeding> | (We could have specified that TH runs on the host, and GHC would have a much easier job when cross-compiling. But then hacks like $(sizeOf (undefined :: Int)) don't work) |
| 2025-02-07 10:33:27 +0100 | <Leary> | hololeap: `foldr cons' [] where { cons' '0' [] = []; cons' c cs = c:cs }` |
| 2025-02-07 10:33:31 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 10:33:32 +0100 | <dminuoso> | tomsmeding: Regarding speed, when we switched from generic FromJSON/ToJSON to TH (some 100 instances perhaps), we brought down compilation speed from 5 minutes to roughly 20s in our large project. |
| 2025-02-07 10:33:48 +0100 | <tomsmeding> | nice |
| 2025-02-07 10:34:42 +0100 | <hololeap> | > let f = foldr cons' [] where { cons' '0' [] = []; cons' c cs = c:cs } in f "120300" |
| 2025-02-07 10:34:44 +0100 | <lambdabot> | "1203" |
| 2025-02-07 10:34:53 +0100 | <tomsmeding> | much nicer than mine |
| 2025-02-07 10:34:57 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-07 10:35:30 +0100 | <dminuoso> | Nice. |
| 2025-02-07 10:35:40 +0100 | <haskellbridge> | <magic_rb> Maybe we ought to make a new language feature called "ProcMacros" and then copy the impl and idea verbatim from Rust |
| 2025-02-07 10:35:58 +0100 | <haskellbridge> | <magic_rb> And just deprecate TH (never removing it probably, but throw a big fat warning) |
| 2025-02-07 10:36:20 +0100 | <tomsmeding> | isn't rust proc macros essentially TH, whereas macro_rules! is the one that is "nicer"? |
| 2025-02-07 10:36:42 +0100 | tomsmeding | never used rust proc macros |
| 2025-02-07 10:36:45 +0100 | <haskellbridge> | <magic_rb> No they define it as running on the host not the target and also they compile them down to machine code |
| 2025-02-07 10:36:47 +0100 | m5zs7k | (aquares@web10.mydevil.net) m5zs7k |
| 2025-02-07 10:36:55 +0100 | <int-e> | at least TH gives you a syntax tree |
| 2025-02-07 10:36:57 +0100 | <tomsmeding> | ah |
| 2025-02-07 10:37:15 +0100 | <haskellbridge> | <magic_rb> So yes macro_rules! Is nicer than proc macros but their proc macros are much better than our template haskell |
| 2025-02-07 10:37:23 +0100 | <haskellbridge> | <magic_rb> int-e so do proc macros |
| 2025-02-07 10:37:29 +0100 | <tomsmeding> | much better just because they run on the host? |
| 2025-02-07 10:37:37 +0100 | <hololeap> | Leary: that's so simple it makes me think I've been overthinking this |
| 2025-02-07 10:37:40 +0100 | <haskellbridge> | <magic_rb> And being compiled |
| 2025-02-07 10:37:40 +0100 | <int-e> | then explain why rust has the horror that is `syn` |
| 2025-02-07 10:37:53 +0100 | <tomsmeding> | that sounds like it wouldn't be worth making a new language extension for. Just add {-# LANGUAGE TemplateHaskellRunsOnHost #-} or something. :P |
| 2025-02-07 10:38:17 +0100 | <haskellbridge> | <magic_rb> Yeah thats what i meant :) just called it ProcMacros |
| 2025-02-07 10:38:35 +0100 | <haskellbridge> | <magic_rb> int-e isnt that a built in crate? |
| 2025-02-07 10:38:39 +0100 | <tomsmeding> | well "copy the impl and idea" sounded a bit more expansive than this :p |
| 2025-02-07 10:38:45 +0100 | <int-e> | nope it's a third party crate |
| 2025-02-07 10:39:02 +0100 | <haskellbridge> | <magic_rb> Ah, havent written rust in a few years, good to knoe |
| 2025-02-07 10:39:03 +0100 | <dminuoso> | Sometimes I dont get why TH is this problematic. Like, why are we not forced to just specify separate dependencies for TH (C and Haskell), and then it becomes just a dumb Haskell program that is executed in the middle of parsing... |
| 2025-02-07 10:39:14 +0100 | <dminuoso> | That communicates with GHC via some protocol |
| 2025-02-07 10:39:53 +0100 | <tomsmeding> | would every slice indicate their own dependencies? Or would a packaeg indicate TH deps for all its slices? |
| 2025-02-07 10:40:02 +0100 | <dminuoso> | For all its slices. |
| 2025-02-07 10:40:05 +0100 | <haskellbridge> | <magic_rb> Because GHC really wants it to be "a integrated part of your program". Compare rustc and haskell. To you a proc macro it must be defined in a different crate. While TH has to be define in a different module |
| 2025-02-07 10:40:37 +0100 | <haskellbridge> | <magic_rb> *drop the "To you" dunno how that happenef |
| 2025-02-07 10:40:39 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 10:40:51 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 10:40:56 +0100 | <int-e> | which is not so different either; crates are rust's compilation units |
| 2025-02-07 10:41:23 +0100 | <haskellbridge> | <magic_rb> Its harder to spew out a module into .so than a crate |
| 2025-02-07 10:41:29 +0100 | <int-e> | While for Haskell that's a module. |
| 2025-02-07 10:41:40 +0100 | <haskellbridge> | <magic_rb> Which is what proc macros become, shared objects afaik |
| 2025-02-07 10:42:12 +0100 | <tomsmeding> | you can just _not_ compile whatever modules depend on the module that contains the TH function definition, and then compile that to a library |
| 2025-02-07 10:42:39 +0100 | <dminuoso> | The convenience of just packing TH next to program code and importing in both directions comes at the price of convenience when using TH... |
| 2025-02-07 10:42:43 +0100 | <haskellbridge> | <magic_rb> Ig so, dunno how hard ghc makes that "just" |
| 2025-02-07 10:42:54 +0100 | <int-e> | That said I'm *for* separating TH imports from runtime imports. But it feels like a thing that you could do without dramatically changing TH. |
| 2025-02-07 10:43:35 +0100 | <tomsmeding> | right, there's some engineering required to make this happen in practice, but in terms of compilation and linking etc., it's not more difficult -- the work is "just" in adding flags to ghc and some logic in the build process to allow building shared libraries also for subsets of the module tree |
| 2025-02-07 10:43:50 +0100 | <haskellbridge> | <magic_rb> I think we all agree that something needs to be done with TH and i also think all the somethings are quite close to each other. Someone just needs to write down a proposal |
| 2025-02-07 10:44:36 +0100 | <haskellbridge> | <magic_rb> Cross compilation is becoming ever more important and TH (and plugins to a much worse degree) are blocking progress |
| 2025-02-07 10:44:42 +0100 | <tomsmeding> | compiling TH slices to native code instead of bytecode is something that isn't visible from userland, so that doesn't need a proposal, just a motivated ghc hacker |
| 2025-02-07 10:44:55 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 10:45:03 +0100 | <tomsmeding> | tbh -XTemplateHaskellRunsOnHost is maybe just the thing that fixes most problems for least effort |
| 2025-02-07 10:46:07 +0100 | <haskellbridge> | <magic_rb> (i will also complain about our c binding generation story, which is worse than rusts -- and also not being able to pass "Storable a" on the stack to a function...) |
| 2025-02-07 10:46:09 +0100 | <dminuoso> | The proposal probably isn't even the biggest difficulty. Somebody needs to engineer this into GHC, and for adoption to occur it needs to land in cabal (all parts of it). And there's lengthy discussions about whether to keep two concurrent TH infrastructures or the amount of breakage across hackage if new boundaries between host and target (imports and linkage) were introduced. |
| 2025-02-07 10:46:49 +0100 | <tomsmeding> | oh, hah, -XTemplateHaskellRunsOnHost would be viral -- yes, that would be a problem |
| 2025-02-07 10:48:36 +0100 | <dminuoso> | tomsmeding: What does that fictional extension do? |
| 2025-02-07 10:48:55 +0100 | <tomsmeding> | dminuoso: make all splices in this module run on the host instead of the target. |
| 2025-02-07 10:49:11 +0100 | <tomsmeding> | which only makes a difference if you're cross-compiling |
| 2025-02-07 10:49:41 +0100 | <tomsmeding> | but this is rather tricky if you unknowingly make use of functions from other packages that we written with "execution on the target" in mind |
| 2025-02-07 10:49:48 +0100 | <tomsmeding> | because that was (is) the default |
| 2025-02-07 10:50:13 +0100 | <tomsmeding> | viral is indeed the wrong word, I was confused for a bit |
| 2025-02-07 10:50:52 +0100 | <tomsmeding> | technically, there would be no hackage split: each module could really decide for itself where to execute its splices. But practically, you do need to watch out |
| 2025-02-07 10:53:05 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 10:53:19 +0100 | <haskellbridge> | <magic_rb> There would be some fall out yet, but it does need to happen sooner or later in my opinion |
| 2025-02-07 10:53:19 +0100 | neiluj | (~julien@90.121.75.121) neiluj |
| 2025-02-07 10:53:45 +0100 | <neiluj> | hi! is there a way to index a map by a polymorphic and abstract type? |
| 2025-02-07 10:54:01 +0100 | <neiluj> | (hitting this limitation in OCaml) |
| 2025-02-07 10:54:17 +0100 | <tomsmeding> | % :t Data.Map.lookup |
| 2025-02-07 10:54:17 +0100 | <yahb2> | Data.Map.lookup ; :: Ord k => k -> Data.Map.Internal.Map k a -> Maybe a |
| 2025-02-07 10:54:23 +0100 | <tomsmeding> | k is rather polymorphic and abstract here |
| 2025-02-07 10:54:32 +0100 | <neiluj> | true |
| 2025-02-07 10:54:33 +0100 | <tomsmeding> | if that's not what you mean, then please elaborate :) |
| 2025-02-07 10:55:05 +0100 | <neiluj> | yes, that would totally work |
| 2025-02-07 10:55:10 +0100 | <neiluj> | thanks! |
| 2025-02-07 10:55:36 +0100 | <tomsmeding> | neiluj: for my curiosity, how is this not true in ocaml? |
| 2025-02-07 10:56:49 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2025-02-07 10:57:22 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-02-07 10:58:11 +0100 | <neiluj> | just to give more context, wrote bindings to the Pari/GP C library https://github.com/jtcoolen/ocaml-pari/blob/staging/src/pari.mli#L5. The main type is an abstract polymorphic type 'a t for which I'd like to set up a map with keys of type 'a t. You cannot do that in OCaml, as Map.Make expects a non polymorphic type t for the keys |
| 2025-02-07 10:58:53 +0100 | <neiluj> | but that would work nicely with Data.Map as it would only require to implement the typecall Ord for that type |
| 2025-02-07 10:59:13 +0100 | <neiluj> | kind of regretting I didn't go with Haskell for these bindings |
| 2025-02-07 11:00:04 +0100 | <neiluj> | *typeclass |
| 2025-02-07 11:06:20 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-02-07 11:06:31 +0100 | <tomsmeding> | neiluj: is this the proper Map type to look at? https://ocaml.org/docs/maps |
| 2025-02-07 11:06:41 +0100 | <tomsmeding> | (I seem to recall that ocaml has various standard libraries) |
| 2025-02-07 11:07:22 +0100 | <tomsmeding> | (That is to say, this one https://ocaml.org/manual/5.3/api/Map.Make.html ) |
| 2025-02-07 11:08:13 +0100 | alp | (~alp@2001:861:8ca0:4940:d5b5:2163:e0a9:7a7f) |
| 2025-02-07 11:08:16 +0100 | <tomsmeding> | funny, that OrderedType is scoped within Map; there is no general Ord-like thing? |
| 2025-02-07 11:08:52 +0100 | <merijn> | tomsmeding: What we really just need is proper phased TH that lets you specify whether something should run on host or target, because both are valid for different scenarios |
| 2025-02-07 11:09:15 +0100 | <merijn> | tomsmeding: That lets you have maps with different orderings for the same type |
| 2025-02-07 11:09:24 +0100 | <neiluj> | tomsmeding: yes, that's the one from the built-in standard library |
| 2025-02-07 11:09:38 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 11:09:57 +0100 | <tomsmeding> | neiluj: I'm not an ocaml programmer (as you can see), but within your library, isn't the t type known? That is to say, surely it's a monomorphic type _somewhere_, and then just create the Map there? |
| 2025-02-07 11:10:36 +0100 | <tomsmeding> | in Haskell, that Ord typeclass instance also needs to come from somewhere, and you can only define such an instance if you actually know what type you have in hand (of course) |
| 2025-02-07 11:11:01 +0100 | <tomsmeding> | (furthermore, the orphan rules dictate that such an instance ought to be defined in the same module as where the type itself is defined) |
| 2025-02-07 11:11:31 +0100 | CiaoSen | (~Jura@2a05:5800:220:3300:ca4b:d6ff:fec1:99da) (Quit: CiaoSen) |
| 2025-02-07 11:11:42 +0100 | <neiluj> | there's no general Ord-like thing, but you can see that all *.OrderedType (Set,Map) module signatures are alike |
| 2025-02-07 11:11:58 +0100 | <tomsmeding> | alternatively, in ocaml, wherever you define this abstract type t (as a non-abstract type, which you then later presumably export as abstract), also give a 'compare' function? |
| 2025-02-07 11:12:14 +0100 | <tomsmeding> | (or however you generally instantiate such OrderedType modules) |
| 2025-02-07 11:12:52 +0100 | <tomsmeding> | merijn: re maps with different orderings for the same type: sure, but I was just surprised that it was Map.OrderedType, not Stdlib.OrderedType or whatever |
| 2025-02-07 11:13:00 +0100 | <tomsmeding> | does Set have its own OrderedType? Are they compatible? |
| 2025-02-07 11:13:50 +0100 | <tomsmeding> | (does ocaml do duck-typing on module signatures, where if a module satisfies a signature's body, then it implements the signature?) |
| 2025-02-07 11:13:57 +0100 | <neiluj> | tomsmeding: yes, so the C library deals with one single recursive type (called GEN), so that all functions take and return GENs. The C library exports a comparison function which I think does structural equality |
| 2025-02-07 11:13:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 11:15:31 +0100 | <tomsmeding> | neiluj: then from a Haskell programmer's point of view, I would just define a data type in your bindings, export that as abstract (i.e. don't allow other code to look inside / construct or destruct it), and also provide your users with implementations of OrderedType, etc., to the extent that PARI defines those operations and that you consider it suitable for users to have them |
| 2025-02-07 11:15:39 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2025-02-07 11:15:57 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 11:16:28 +0100 | <tomsmeding> | it's the same in haskell; if I define an abstract data type in a haskell module, and I want other people to be able to compare values of those types (so that they can put them in a Map or Set, for example), it's me who has to write that Ord instance and make it available |
| 2025-02-07 11:17:02 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 268 seconds) |
| 2025-02-07 11:17:07 +0100 | <tomsmeding> | users can't do that, precisely because it's an abstract data type |
| 2025-02-07 11:17:08 +0100 | <neiluj> | tomsmeding: Set has its own OrderedType, and they are compatible with the one from Map because they share the same signature |
| 2025-02-07 11:17:30 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 11:18:07 +0100 | <tomsmeding> | neiluj: and "compatible" means that the type signatures are the same, and if you want to instantiate a signature with some concrete module you can always do that if it happens to match the types in that signature? |
| 2025-02-07 11:18:16 +0100 | <tomsmeding> | i.e. go-style, not C++/Java style? |
| 2025-02-07 11:18:57 +0100 | <tomsmeding> | an alternate design could be that when defining an ocaml module, you have to specify (by name) which signatures it implements, and then it doesn't implement any others. |
| 2025-02-07 11:19:09 +0100 | <tomsmeding> | (That would be classic object-oriented style, C++/Java style) |
| 2025-02-07 11:20:12 +0100 | <neiluj> | tomsmeding: precisely, and any module whose signature is a superset of some module signature S can be accepted as an instance of S whenever some function or functor expects an S |
| 2025-02-07 11:20:20 +0100 | <tomsmeding> | merijn: sorry for being tardy. Yes, we need both styles of TH, hence this being a switch you can also _not_ turn on. But it's probably even better to do this with slice granularity, not module granularity :) |
| 2025-02-07 11:20:31 +0100 | <tomsmeding> | neiluj: I see! Then it makes sense. :) |
| 2025-02-07 11:20:36 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 11:21:41 +0100 | <tomsmeding> | neiluj: Ideally you'd need to have a module that defines your wrapping of GEN, which (among other things) defines a compare function so that it satisfies Map.OrderedType. The module's internals are abstract. However, somehow the rest of your library would need to be able to access those internals nevertheless |
| 2025-02-07 11:21:54 +0100 | <tomsmeding> | or perhaps this means that the whole bindings package needs to live inside that module? |
| 2025-02-07 11:22:18 +0100 | notzmv | (~umar@user/notzmv) (Remote host closed the connection) |
| 2025-02-07 11:22:20 +0100 | <neiluj> | in a sense, you can emulate typeclasses in ocaml with functors, but you have to explicitly specify the module signature, while haskell does that for you with typeclasses |
| 2025-02-07 11:22:34 +0100 | <tomsmeding> | in other words, I don't see anything yet here that you fundamentally can't do in ocaml but you can do in haskell |
| 2025-02-07 11:22:57 +0100 | <neiluj> | for ex: val f : (type t) (module Ord with type t = t) -> t -> t |
| 2025-02-07 11:24:05 +0100 | <neiluj> | instead of f :: Ord t => t -> t (where the Ord is implicit in the function call) |
| 2025-02-07 11:24:48 +0100 | <neiluj> | well ocaml functors are more flexible as you can implement multiple instances of a module type for some type, while in haskell you'd need a newtype |
| 2025-02-07 11:25:28 +0100 | <neiluj> | given a type t, in ocaml, i can implement to instances of Ord with different comparison functions |
| 2025-02-07 11:25:34 +0100 | <neiluj> | for that type |
| 2025-02-07 11:25:35 +0100 | <tomsmeding> | right |
| 2025-02-07 11:25:54 +0100 | <tomsmeding> | you might need to visit some ocaml-specific forum to ask for more specific guidance. But I think you can get what you want in ocaml :) |
| 2025-02-07 11:25:56 +0100 | <neiluj> | plus it's more explicit, so easier to know which function gets called |
| 2025-02-07 11:26:16 +0100 | <tomsmeding> | wherever you export your t, also make sure that module exports a compare function |
| 2025-02-07 11:26:36 +0100 | <neiluj> | sure, thanks! just wanted to see if haskell could solve my problem more easily, and it seems so :) |
| 2025-02-07 11:26:44 +0100 | <tomsmeding> | I'm not sure it can! That's my point |
| 2025-02-07 11:27:01 +0100 | <tomsmeding> | the types look different, but as you say, ocaml is the one that's more flexible, not haskell |
| 2025-02-07 11:27:35 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2025-02-07 11:27:53 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 11:30:04 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 11:31:02 +0100 | alp | (~alp@2001:861:8ca0:4940:d5b5:2163:e0a9:7a7f) (Remote host closed the connection) |
| 2025-02-07 11:31:19 +0100 | alp | (~alp@2001:861:8ca0:4940:41b4:15ba:b9c5:e001) |
| 2025-02-07 11:31:24 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-02-07 11:31:46 +0100 | <tomsmeding> | in haskell, you can't satisfy that Ord constraint unless you know what the 'k' type is, monomorphically, or unless you have that 'k' as a parameter yourself and get the Ord instance from your caller |
| 2025-02-07 11:31:57 +0100 | <tomsmeding> | I think you can do the same in ocaml |
| 2025-02-07 11:32:05 +0100 | <tomsmeding> | somehow :) |
| 2025-02-07 11:32:20 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:3bd7:f04:27ee:5a69) ubert |
| 2025-02-07 11:32:20 +0100 | akegalj | (~akegalj@141-136-207-93.dsl.iskon.hr) (Ping timeout: 244 seconds) |
| 2025-02-07 11:32:44 +0100 | alp | (~alp@2001:861:8ca0:4940:41b4:15ba:b9c5:e001) (Remote host closed the connection) |
| 2025-02-07 11:33:00 +0100 | alp | (~alp@2001:861:8ca0:4940:d783:3ed4:b3b2:7c8f) |
| 2025-02-07 11:34:26 +0100 | alp | (~alp@2001:861:8ca0:4940:d783:3ed4:b3b2:7c8f) (Remote host closed the connection) |
| 2025-02-07 11:34:42 +0100 | alp | (~alp@2001:861:8ca0:4940:c543:753a:35f:61ff) |
| 2025-02-07 11:36:25 +0100 | alp_ | (~alp@2001:861:8ca0:4940:5fab:379e:f5b9:17db) |
| 2025-02-07 11:37:47 +0100 | JuanDaugherty | ColinRobinson |
| 2025-02-07 11:37:50 +0100 | alp_ | (~alp@2001:861:8ca0:4940:5fab:379e:f5b9:17db) (Remote host closed the connection) |
| 2025-02-07 11:38:07 +0100 | alp_ | (~alp@2001:861:8ca0:4940:c66f:9510:c543:5c5b) |
| 2025-02-07 11:39:26 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) tcard |
| 2025-02-07 11:39:32 +0100 | alp_ | (~alp@2001:861:8ca0:4940:c66f:9510:c543:5c5b) (Remote host closed the connection) |
| 2025-02-07 11:39:50 +0100 | alp_ | (~alp@2001:861:8ca0:4940:9b7d:225:6dca:3) |
| 2025-02-07 11:40:28 +0100 | alp | (~alp@2001:861:8ca0:4940:c543:753a:35f:61ff) (Ping timeout: 272 seconds) |
| 2025-02-07 11:41:14 +0100 | alp_ | (~alp@2001:861:8ca0:4940:9b7d:225:6dca:3) (Remote host closed the connection) |
| 2025-02-07 11:41:32 +0100 | alp_ | (~alp@2001:861:8ca0:4940:cbb9:a4bc:2367:1426) |
| 2025-02-07 11:42:56 +0100 | alp_ | (~alp@2001:861:8ca0:4940:cbb9:a4bc:2367:1426) (Remote host closed the connection) |
| 2025-02-07 11:43:13 +0100 | alp_ | (~alp@2001:861:8ca0:4940:ded:f36a:cce:f632) |
| 2025-02-07 11:44:16 +0100 | akegalj | (~akegalj@95.168.121.14) |
| 2025-02-07 11:44:38 +0100 | alp_ | (~alp@2001:861:8ca0:4940:ded:f36a:cce:f632) (Remote host closed the connection) |
| 2025-02-07 11:44:55 +0100 | alp_ | (~alp@2001:861:8ca0:4940:62ab:e74d:1ce5:46a6) |
| 2025-02-07 11:46:00 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 11:46:20 +0100 | alp_ | (~alp@2001:861:8ca0:4940:62ab:e74d:1ce5:46a6) (Remote host closed the connection) |
| 2025-02-07 11:46:38 +0100 | alp_ | (~alp@2001:861:8ca0:4940:71ab:5717:4fb2:efbd) |
| 2025-02-07 11:46:45 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 11:48:02 +0100 | alp_ | (~alp@2001:861:8ca0:4940:71ab:5717:4fb2:efbd) (Remote host closed the connection) |
| 2025-02-07 11:48:20 +0100 | alp_ | (~alp@2001:861:8ca0:4940:a997:e2f2:f7d1:e67e) |
| 2025-02-07 11:49:44 +0100 | alp_ | (~alp@2001:861:8ca0:4940:a997:e2f2:f7d1:e67e) (Remote host closed the connection) |
| 2025-02-07 11:50:01 +0100 | alp_ | (~alp@2001:861:8ca0:4940:eb15:e09d:d9d1:dd64) |
| 2025-02-07 11:51:26 +0100 | alp_ | (~alp@2001:861:8ca0:4940:eb15:e09d:d9d1:dd64) (Remote host closed the connection) |
| 2025-02-07 11:51:43 +0100 | alp_ | (~alp@2001:861:8ca0:4940:ae81:7c78:7938:da13) |
| 2025-02-07 11:53:08 +0100 | alp_ | (~alp@2001:861:8ca0:4940:ae81:7c78:7938:da13) (Remote host closed the connection) |
| 2025-02-07 11:53:26 +0100 | alp_ | (~alp@2001:861:8ca0:4940:3337:c2d5:219b:8ea3) |
| 2025-02-07 11:55:09 +0100 | alp__ | (~alp@2001:861:8ca0:4940:c29d:3ca2:b267:28b1) |
| 2025-02-07 11:56:32 +0100 | alp__ | (~alp@2001:861:8ca0:4940:c29d:3ca2:b267:28b1) (Remote host closed the connection) |
| 2025-02-07 11:56:50 +0100 | alp__ | (~alp@2001:861:8ca0:4940:79d9:d457:2:aee5) |
| 2025-02-07 11:57:23 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 11:58:15 +0100 | alp__ | (~alp@2001:861:8ca0:4940:79d9:d457:2:aee5) (Remote host closed the connection) |
| 2025-02-07 11:58:33 +0100 | alp__ | (~alp@2001:861:8ca0:4940:6519:dc9d:e9c:614a) |
| 2025-02-07 11:58:58 +0100 | alp_ | (~alp@2001:861:8ca0:4940:3337:c2d5:219b:8ea3) (Ping timeout: 268 seconds) |
| 2025-02-07 12:00:15 +0100 | alp_ | (~alp@2001:861:8ca0:4940:2f2f:adaf:22dd:2984) |
| 2025-02-07 12:01:39 +0100 | alp_ | (~alp@2001:861:8ca0:4940:2f2f:adaf:22dd:2984) (Remote host closed the connection) |
| 2025-02-07 12:01:40 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 12:01:56 +0100 | alp_ | (~alp@2001:861:8ca0:4940:f173:421e:50:abf5) |
| 2025-02-07 12:03:21 +0100 | alp_ | (~alp@2001:861:8ca0:4940:f173:421e:50:abf5) (Remote host closed the connection) |
| 2025-02-07 12:03:37 +0100 | alp_ | (~alp@2001:861:8ca0:4940:6404:3a5a:e9a:718c) |
| 2025-02-07 12:03:54 +0100 | alp__ | (~alp@2001:861:8ca0:4940:6519:dc9d:e9c:614a) (Ping timeout: 268 seconds) |
| 2025-02-07 12:05:03 +0100 | alp_ | (~alp@2001:861:8ca0:4940:6404:3a5a:e9a:718c) (Remote host closed the connection) |
| 2025-02-07 12:05:21 +0100 | alp_ | (~alp@2001:861:8ca0:4940:40e8:5a4c:5708:2ed2) |
| 2025-02-07 12:06:45 +0100 | alp_ | (~alp@2001:861:8ca0:4940:40e8:5a4c:5708:2ed2) (Remote host closed the connection) |
| 2025-02-07 12:07:03 +0100 | alp_ | (~alp@2001:861:8ca0:4940:7dad:d25a:6bb7:3230) |
| 2025-02-07 12:08:06 +0100 | agent314 | (~quassel@79.127.222.205) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2025-02-07 12:08:27 +0100 | alp_ | (~alp@2001:861:8ca0:4940:7dad:d25a:6bb7:3230) (Remote host closed the connection) |
| 2025-02-07 12:08:41 +0100 | agent314 | (~quassel@79.127.222.205) agent314 |
| 2025-02-07 12:08:45 +0100 | alp_ | (~alp@2001:861:8ca0:4940:137a:a43f:4411:7b2b) |
| 2025-02-07 12:09:54 +0100 | agent314 | (~quassel@79.127.222.205) (Client Quit) |
| 2025-02-07 12:10:09 +0100 | alp_ | (~alp@2001:861:8ca0:4940:137a:a43f:4411:7b2b) (Remote host closed the connection) |
| 2025-02-07 12:10:26 +0100 | alp_ | (~alp@2001:861:8ca0:4940:fcc4:ad40:bfe8:4272) |
| 2025-02-07 12:11:51 +0100 | alp_ | (~alp@2001:861:8ca0:4940:fcc4:ad40:bfe8:4272) (Remote host closed the connection) |
| 2025-02-07 12:12:09 +0100 | alp_ | (~alp@2001:861:8ca0:4940:8a35:a696:413b:c43a) |
| 2025-02-07 12:12:50 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 12:13:32 +0100 | alp_ | (~alp@2001:861:8ca0:4940:8a35:a696:413b:c43a) (Remote host closed the connection) |
| 2025-02-07 12:13:45 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a44a:d727:8d11:d274) |
| 2025-02-07 12:13:51 +0100 | alp_ | (~alp@2001:861:8ca0:4940:dda1:b533:697e:2ecc) |
| 2025-02-07 12:15:15 +0100 | alp_ | (~alp@2001:861:8ca0:4940:dda1:b533:697e:2ecc) (Remote host closed the connection) |
| 2025-02-07 12:15:32 +0100 | alp_ | (~alp@2001:861:8ca0:4940:7f1:741d:9be9:bad) |
| 2025-02-07 12:16:25 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 12:16:57 +0100 | alp_ | (~alp@2001:861:8ca0:4940:7f1:741d:9be9:bad) (Remote host closed the connection) |
| 2025-02-07 12:17:15 +0100 | alp_ | (~alp@2001:861:8ca0:4940:d1ce:16c7:4dae:178a) |
| 2025-02-07 12:17:40 +0100 | <dminuoso> | tomsmeding: "execution on the target" seems like a rather vague notion. |
| 2025-02-07 12:18:33 +0100 | <dminuoso> | Packages themselves has no notion of "target", code just runs. This is a configuration/build question of what the compiler should do. |
| 2025-02-07 12:18:39 +0100 | alp_ | (~alp@2001:861:8ca0:4940:d1ce:16c7:4dae:178a) (Remote host closed the connection) |
| 2025-02-07 12:18:56 +0100 | alp_ | (~alp@2001:861:8ca0:4940:14f3:ef88:5d72:946) |
| 2025-02-07 12:19:53 +0100 | <dminuoso> | If we pick say `text`, and link against its for TH purposes, just build a separate `text` to run on what the compiler perceives as target, link it to the TH code, and done. |
| 2025-02-07 12:20:08 +0100 | <dminuoso> | Of course this introduces some coherence questions, but that's really a cabal problem. |
| 2025-02-07 12:20:21 +0100 | alp_ | (~alp@2001:861:8ca0:4940:14f3:ef88:5d72:946) (Remote host closed the connection) |
| 2025-02-07 12:20:29 +0100 | <tomsmeding> | the target is decided at the point where you build a final executable |
| 2025-02-07 12:20:38 +0100 | alp_ | (~alp@2001:861:8ca0:4940:2887:5196:3f2d:f111) |
| 2025-02-07 12:20:45 +0100 | <tomsmeding> | all code that is compiled is compile for a particular target environment/architecture/etc. |
| 2025-02-07 12:20:53 +0100 | <tomsmeding> | so there is definitely a well-defined target at all times |
| 2025-02-07 12:21:11 +0100 | <tomsmeding> | you cannot compile any code if you don't yet know whether to do so for x64 or for riscv! |
| 2025-02-07 12:21:37 +0100 | <dminuoso> | Who cares what the target is? |
| 2025-02-07 12:21:53 +0100 | <tomsmeding> | ghc cares, when generating assembly code. |
| 2025-02-07 12:22:03 +0100 | alp_ | (~alp@2001:861:8ca0:4940:2887:5196:3f2d:f111) (Remote host closed the connection) |
| 2025-02-07 12:22:05 +0100 | <dminuoso> | We compile text twice, one for host and once for target. TH links against the host object files, final program against the target object files. |
| 2025-02-07 12:22:21 +0100 | alp_ | (~alp@2001:861:8ca0:4940:1362:b30:65a6:8bf) |
| 2025-02-07 12:22:48 +0100 | <dminuoso> | Problems only arise if you insist on compiling text only once to use for both TH and the final executable. |
| 2025-02-07 12:22:55 +0100 | <tomsmeding> | also, some people write TH code that explicitly assumes it's running on the target machine, so that it can use stuff like `sizeOf (undefined :: Int)` in TH and have that return appropriate values |
| 2025-02-07 12:23:09 +0100 | <tomsmeding> | and this is explicitly supported |
| 2025-02-07 12:23:14 +0100 | <tomsmeding> | (for better or for worse) |
| 2025-02-07 12:24:04 +0100 | alp__ | (~alp@2001:861:8ca0:4940:817d:397a:310b:59bd) |
| 2025-02-07 12:24:29 +0100 | <dminuoso> | This is an intriguing example. |
| 2025-02-07 12:25:25 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 12:26:11 +0100 | <tomsmeding> | dminuoso: "We compile text twice" -- is this a hypothetical, or do you actually compile TH this way at your workplace? |
| 2025-02-07 12:26:17 +0100 | <tomsmeding> | just double-checking |
| 2025-02-07 12:26:37 +0100 | <tomsmeding> | I hope it's the former |
| 2025-02-07 12:27:12 +0100 | <dminuoso> | Yeah just hypothetical. |
| 2025-02-07 12:27:12 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 12:27:51 +0100 | <dminuoso> | So after pondering some, I think that `sizeOf` in TH should not give you target information. |
| 2025-02-07 12:27:57 +0100 | alp_ | (~alp@2001:861:8ca0:4940:1362:b30:65a6:8bf) (Ping timeout: 268 seconds) |
| 2025-02-07 12:28:06 +0100 | <tomsmeding> | I agree. But it's not the status quo, so changing that would be breaking |
| 2025-02-07 12:28:22 +0100 | <dminuoso> | Something equivalent to a separate Foreign.Storable.Target module would make more sense. |
| 2025-02-07 12:28:35 +0100 | <dminuoso> | Or maybe not exist at all. |
| 2025-02-07 12:28:46 +0100 | <tomsmeding> | (There's more than just sizeOf that returns system information. There's everything in the System.Info module, for starters, and also anything in IO is system-dependent) |
| 2025-02-07 12:29:07 +0100 | <dminuoso> | For this discussion, a thorough analysis of hackage would be interesting. |
| 2025-02-07 12:29:11 +0100 | alp__ | (~alp@2001:861:8ca0:4940:817d:397a:310b:59bd) (Ping timeout: 268 seconds) |
| 2025-02-07 12:29:19 +0100 | <dminuoso> | Whether any breakage if we limited availability in TH is even worth discussing. |
| 2025-02-07 12:29:46 +0100 | <tomsmeding> | GHC is actively doing lots of work to ensure that TH can run on the target when cross-compiling, with the whole external-interpreter stuff |
| 2025-02-07 12:29:56 +0100 | <tomsmeding> | particularly around the wasm and js backends |
| 2025-02-07 12:30:05 +0100 | <tomsmeding> | so this choice has already been made :p |
| 2025-02-07 12:30:34 +0100 | <dminuoso> | Why would it need to run on the target? |
| 2025-02-07 12:30:44 +0100 | <dminuoso> | Dont quite see how this makes sense |
| 2025-02-07 12:30:45 +0100 | <tomsmeding> | the above-mentioned, I'd guess |
| 2025-02-07 12:30:53 +0100 | <tomsmeding> | though I'm not actively following that space |
| 2025-02-07 12:31:10 +0100 | <dminuoso> | TH runs during parse time on host. |
| 2025-02-07 12:31:21 +0100 | <int-e> | It's so that most user code doesn't have to worry about cross-compilation. |
| 2025-02-07 12:31:24 +0100 | <dminuoso> | Not sure what TH running on target in cross-compilation would even mean |
| 2025-02-07 12:31:39 +0100 | <dminuoso> | Given that parsing tends to not happen on target. |
| 2025-02-07 12:31:40 +0100 | <tomsmeding> | dminuoso: when compiling for JS, GHC literally spins up a nodejs executable to run your TH code |
| 2025-02-07 12:32:22 +0100 | <tomsmeding> | (if I remember correctly) |
| 2025-02-07 12:32:32 +0100 | <dminuoso> | Okay I see! Then all we need is qemu to run in GHC. :-) |
| 2025-02-07 12:33:05 +0100 | <tomsmeding> | I don't know what happens if you try to cross-compile for a different architecture that is not JS or wasm. :P |
| 2025-02-07 12:34:13 +0100 | <tomsmeding> | https://gitlab.haskell.org/ghc/ghc/-/wikis/template-haskell/cross-compilation |
| 2025-02-07 12:35:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 12:36:52 +0100 | neiluj | (~julien@90.121.75.121) (Quit: WeeChat 4.4.3) |
| 2025-02-07 12:38:55 +0100 | <dminuoso> | One thing I had wanted before, is to keep runtime dependencies smaller. I once had something akin to an openapi.json and needed to generate stub code - now I dont want aeson in my runtime dependency, large dependency closures lead to version bounds being overly restrictive especially if some of those transitive packages have tight bounds and are not updated regularly. |
| 2025-02-07 12:39:24 +0100 | <dminuoso> | Which is why I explored some solution similar to zeroth |
| 2025-02-07 12:42:23 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2025-02-07 12:46:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 12:46:26 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) (Remote host closed the connection) |
| 2025-02-07 12:47:34 +0100 | <tomsmeding> | there's build-tool-depends, not sure if that is flexible enough |
| 2025-02-07 12:47:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-07 12:48:18 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 268 seconds) |
| 2025-02-07 12:48:37 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) |
| 2025-02-07 12:49:57 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) (Client Quit) |
| 2025-02-07 12:50:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 12:50:51 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) |
| 2025-02-07 12:53:19 +0100 | sprotte24 | (~sprotte24@p200300d16f162e0095bcbd8ff54bb672.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-02-07 12:53:27 +0100 | MyNetAz | (~MyNetAz@user/MyNetAz) MyNetAz |
| 2025-02-07 12:56:17 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 12:56:59 +0100 | jespada | (~jespada@2800:a4:2309:e700:64a6:7448:7cfa:894d) jespada |
| 2025-02-07 12:57:27 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 12:57:43 +0100 | jespada | (~jespada@2800:a4:2309:e700:64a6:7448:7cfa:894d) (Client Quit) |
| 2025-02-07 12:58:56 +0100 | AlexNoo_ | AlexNoo |
| 2025-02-07 13:03:42 +0100 | jespada | (~jespada@2800:a4:2309:e700:64a6:7448:7cfa:894d) jespada |
| 2025-02-07 13:10:53 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 13:14:25 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 13:19:52 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 13:20:43 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 13:27:27 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 13:29:03 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 13:29:34 +0100 | otbergsten | (~otbergste@user/otbergsten) otbergsten |
| 2025-02-07 13:30:28 +0100 | bunnies | Catty |
| 2025-02-07 13:35:10 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 13:39:04 +0100 | ft | (~ft@p3e9bcd97.dip0.t-ipconnect.de) ft |
| 2025-02-07 13:40:06 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-02-07 13:42:32 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 13:49:29 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 13:50:25 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-02-07 13:52:37 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-02-07 13:53:29 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-07 13:59:42 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 14:00:52 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 14:01:44 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2025-02-07 14:01:59 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-07 14:07:32 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-02-07 14:08:00 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
| 2025-02-07 14:15:08 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 14:16:14 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 14:16:24 +0100 | akegalj | (~akegalj@95.168.121.14) (Read error: Connection reset by peer) |
| 2025-02-07 14:23:56 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 14:28:20 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 14:30:32 +0100 | Xe | (~Xe@perl/impostor/xe) (Remote host closed the connection) |
| 2025-02-07 14:31:55 +0100 | akegalj | (~akegalj@89-172-213-142.adsl.net.t-com.hr) |
| 2025-02-07 14:32:54 +0100 | Xe | (~Xe@perl/impostor/xe) Xe |
| 2025-02-07 14:43:22 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 252 seconds) |
| 2025-02-07 14:47:35 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-02-07 14:51:51 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 265 seconds) |
| 2025-02-07 14:52:11 +0100 | ash3en | (~Thunderbi@146.70.124.222) ash3en |
| 2025-02-07 14:56:55 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 14:58:51 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |