| 2026-03-07 00:02:04 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
| 2026-03-07 00:03:15 +0100 | tromp | (~textual@2001:1c00:3487:1b00:d97f:6c22:5298:b927) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-03-07 00:04:24 +0100 | juri_ | (~juri@217-114-215-140.pool.ovpn.com) (Ping timeout: 246 seconds) |
| 2026-03-07 00:06:17 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 00:08:59 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Ping timeout: 244 seconds) |
| 2026-03-07 00:10:32 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 00:11:13 +0100 | juri_ | (~juri@79.140.122.233) juri_ |
| 2026-03-07 00:12:06 +0100 | machinedgod | (~machinedg@172.219.48.230) machinedgod |
| 2026-03-07 00:12:59 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 00:22:26 +0100 | juri_ | (~juri@79.140.122.233) (Ping timeout: 248 seconds) |
| 2026-03-07 00:24:08 +0100 | juri_ | (~juri@217-114-215-140.pool.ovpn.com) juri_ |
| 2026-03-07 00:24:54 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
| 2026-03-07 00:26:23 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2026-03-07 00:29:21 +0100 | mange | (~mange@user/mange) (Remote host closed the connection) |
| 2026-03-07 00:37:51 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 00:40:13 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2026-03-07 00:40:26 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2026-03-07 00:44:48 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 264 seconds) |
| 2026-03-07 00:52:23 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 00:54:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 00:55:22 +0100 | athan | (~athan@98.150.233.226) athan |
| 2026-03-07 00:57:02 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-07 00:59:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-07 01:00:08 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 244 seconds) |
| 2026-03-07 01:01:13 +0100 | wickedjargon | (~user@207.194.38.18) (Remote host closed the connection) |
| 2026-03-07 01:05:59 +0100 | athan | (~athan@98.150.233.226) (Quit: Konversation terminated!) |
| 2026-03-07 01:09:02 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 01:10:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 01:14:05 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-07 01:15:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 01:22:52 +0100 | machinedgod | (~machinedg@172.219.48.230) (Ping timeout: 244 seconds) |
| 2026-03-07 01:25:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 01:31:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 01:38:43 +0100 | hiecaq | (~hiecaq@user/hiecaq) hiecaq |
| 2026-03-07 01:41:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 01:43:27 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) |
| 2026-03-07 01:43:27 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) (Changing host) |
| 2026-03-07 01:43:27 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 01:46:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-07 01:52:46 +0100 | Square3 | (~Square@user/square) (Ping timeout: 268 seconds) |
| 2026-03-07 01:57:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 01:59:45 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-07 02:01:03 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 02:02:12 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 02:06:09 +0100 | Tuplanolla | (~Tuplanoll@88.114.89.88) (Quit: Leaving.) |
| 2026-03-07 02:08:42 +0100 | <tusko> | When I write Haskell I sometimes ask myself why I ever wrote in another language |
| 2026-03-07 02:13:10 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 02:18:52 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-07 02:19:42 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 02:30:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 02:31:56 +0100 | omnifunctor | (~omnifunct@user/semifunctor) (Remote host closed the connection) |
| 2026-03-07 02:33:25 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-07 02:34:01 +0100 | omnifunctor | (~omnifunct@user/semifunctor) omnifunctor |
| 2026-03-07 02:34:54 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 02:36:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 02:36:27 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Remote host closed the connection) |
| 2026-03-07 02:37:17 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 02:40:10 +0100 | collide2954 | (~collide29@user/collide2954) (Quit: The Lounge - https://thelounge.chat) |
| 2026-03-07 02:44:49 +0100 | durstloescher | (~textual@2a02:8109:1b01:2500:a050:c84e:2137:b3ac) |
| 2026-03-07 02:46:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 02:47:42 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
| 2026-03-07 02:51:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 02:57:53 +0100 | skum | (~skum@user/skum) (Quit: WeeChat 4.8.1) |
| 2026-03-07 03:00:57 +0100 | skum | (~skum@user/skum) skum |
| 2026-03-07 03:01:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 03:02:34 +0100 | skum | (~skum@user/skum) (Client Quit) |
| 2026-03-07 03:03:01 +0100 | skum | (~skum@user/skum) skum |
| 2026-03-07 03:04:30 +0100 | skum | (~skum@user/skum) (Client Quit) |
| 2026-03-07 03:06:40 +0100 | skum | (~skum@user/skum) skum |
| 2026-03-07 03:07:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 03:16:06 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-07 03:17:23 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 03:17:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 03:20:22 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Remote host closed the connection) |
| 2026-03-07 03:22:00 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 03:23:12 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 03:24:26 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 03:29:06 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 03:30:19 +0100 | Ranhir | (~Ranhir@157.97.53.139) (Ping timeout: 245 seconds) |
| 2026-03-07 03:40:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 03:44:27 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-03-07 03:44:28 +0100 | Ranhir | (~Ranhir@157.97.53.139) Ranhir |
| 2026-03-07 03:45:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-07 03:47:20 +0100 | durstloescher | (~textual@2a02:8109:1b01:2500:a050:c84e:2137:b3ac) (Quit: Textual IRC Client: www.textualapp.com) |
| 2026-03-07 03:55:56 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 04:02:48 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 04:13:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 04:14:20 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 245 seconds) |
| 2026-03-07 04:16:14 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
| 2026-03-07 04:18:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 04:21:38 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-03-07 04:21:55 +0100 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-03-07 04:24:10 +0100 | DetourNe- | DetourNetworkUK |
| 2026-03-07 04:39:02 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) |
| 2026-03-07 04:39:02 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) (Changing host) |
| 2026-03-07 04:39:02 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 04:43:21 +0100 | mange | (~mange@user/mange) mange |
| 2026-03-07 04:44:18 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 248 seconds) |
| 2026-03-07 04:50:59 +0100 | xff0x | (~xff0x@2405:6580:b080:900:acbe:a784:57c1:5e52) (Ping timeout: 252 seconds) |
| 2026-03-07 04:52:22 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-07 04:54:05 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 04:57:36 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 04:59:52 +0100 | CloneOfNone_ | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-03-07 05:00:02 +0100 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) (Read error: Connection reset by peer) |
| 2026-03-07 05:00:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 05:01:56 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-07 05:04:12 +0100 | xff0x | (~xff0x@2405:6580:b080:900:acbe:a784:57c1:5e52) |
| 2026-03-07 05:05:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-07 05:16:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 05:16:37 +0100 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-03-07 05:17:55 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-03-07 05:18:56 +0100 | DetourNe- | DetourNetworkUK |
| 2026-03-07 05:21:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 05:31:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 05:32:38 +0100 | <glguy> | tusko: what was the answer? |
| 2026-03-07 05:38:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-07 05:39:53 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 05:44:18 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-07 05:46:04 +0100 | stackdroid18 | (~stackdroi@user/stackdroid) () |
| 2026-03-07 05:49:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 05:50:32 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2026-03-07 05:50:48 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-03-07 05:51:17 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-03-07 05:54:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 05:54:55 +0100 | humasect | (~humasect@192.249.132.90) humasect |
| 2026-03-07 05:54:57 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-03-07 06:05:12 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 06:06:19 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2026-03-07 06:06:55 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2026-03-07 06:07:02 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2026-03-07 06:10:04 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 06:10:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-07 06:11:57 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 06:14:41 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 06:24:03 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) |
| 2026-03-07 06:24:03 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) (Changing host) |
| 2026-03-07 06:24:03 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 06:27:16 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 06:27:24 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 06:27:47 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 06:29:12 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2026-03-07 06:30:19 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.7.2) |
| 2026-03-07 06:30:38 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
| 2026-03-07 06:31:13 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-03-07 06:32:40 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-03-07 06:32:52 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 06:35:09 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-03-07 06:36:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 06:39:29 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 06:39:42 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 06:41:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 06:42:09 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-03-07 06:42:30 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-03-07 06:44:18 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 06:44:42 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 06:48:15 +0100 | takuan | (~takuan@141.134.185.233) |
| 2026-03-07 06:53:05 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 06:54:42 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 268 seconds) |
| 2026-03-07 06:57:40 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 07:00:46 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 244 seconds) |
| 2026-03-07 07:01:57 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) |
| 2026-03-07 07:01:57 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) (Changing host) |
| 2026-03-07 07:01:57 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 07:07:23 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 252 seconds) |
| 2026-03-07 07:08:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 07:11:22 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-07 07:15:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 07:17:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 07:22:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-03-07 07:25:01 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 07:29:11 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-07 07:32:07 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2026-03-07 07:33:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 07:38:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 07:41:51 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) |
| 2026-03-07 07:41:51 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:9c04:77be:7a54:3a7d) (Changing host) |
| 2026-03-07 07:41:51 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 07:47:13 +0100 | mange | (~mange@user/mange) (Remote host closed the connection) |
| 2026-03-07 07:48:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 07:52:02 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 248 seconds) |
| 2026-03-07 07:53:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 07:56:35 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2026-03-07 07:57:33 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 07:57:39 +0100 | philopso11 | (~caecilius@107.175.39.130) |
| 2026-03-07 08:04:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 08:07:29 +0100 | philopso11 | (~caecilius@107.175.39.130) (Remote host closed the connection) |
| 2026-03-07 08:07:39 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 08:09:12 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 08:09:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-07 08:12:39 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 08:13:48 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-07 08:14:33 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-07 08:14:59 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-07 08:15:44 +0100 | <ski> | EvanR : if you want to, you can view the semantic value of a syntactic category / nonterminal to be the value of a particular (synthesized, passed up, output) attribute of that syntactical category, regarding the whole grammar as an attribute grammars. (but attribute grammars are more general, can have multiple attributes on each syntactic category, some of which may be inherited (passed down, input)) |
| 2026-03-07 08:18:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 08:18:41 +0100 | philopsos1 | (~caecilius@user/philopsos) (Remote host closed the connection) |
| 2026-03-07 08:18:46 +0100 | <ski> | @hackage uuagc |
| 2026-03-07 08:18:46 +0100 | <lambdabot> | https://hackage.haskell.org/package/uuagc |
| 2026-03-07 08:19:17 +0100 | philopsos1 | (~caecilius@user/philopsos) philopsos |
| 2026-03-07 08:23:17 +0100 | ski | . o O ( "Utrecht University Attribute Grammar Compiler" <https://web.archive.org/web/20160625015520/http://foswiki.cs.uu.nl/foswiki/bin/view/HUT/AttributeG…>,<https://github.com/UU-ComputerScience/uuagc> ) |
| 2026-03-07 08:23:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-07 08:24:47 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 08:30:11 +0100 | rainbyte | (~rainbyte@181.47.219.106) (Remote host closed the connection) |
| 2026-03-07 08:31:02 +0100 | philopsos1 | (~caecilius@user/philopsos) (Quit: leaving) |
| 2026-03-07 08:31:26 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-07 08:34:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 08:36:34 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-07 08:38:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 08:41:01 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-07 08:46:41 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-07 08:49:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 08:53:52 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2026-03-07 08:54:03 +0100 | califax | (~califax@user/califx) califx |
| 2026-03-07 08:56:20 +0100 | Vizious | (~bes@user/Vizious) (Quit: WeeChat 4.6.3) |
| 2026-03-07 08:56:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-07 09:00:21 +0100 | tromp | (~textual@2001:1c00:3487:1b00:e975:d7be:a717:768f) |
| 2026-03-07 09:01:02 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-03-07 09:02:39 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-03-07 09:07:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 09:12:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 09:12:45 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2026-03-07 09:15:06 +0100 | xff0x | (~xff0x@2405:6580:b080:900:acbe:a784:57c1:5e52) (Ping timeout: 244 seconds) |
| 2026-03-07 09:18:45 +0100 | Vizious | (~bes@user/Vizious) Vizious |
| 2026-03-07 09:19:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 09:22:34 +0100 | xff0x | (~xff0x@2405:6580:b080:900:acbe:a784:57c1:5e52) |
| 2026-03-07 09:24:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 09:29:46 +0100 | madresch | (~Thunderbi@user/madresch) (Quit: madresch) |
| 2026-03-07 09:30:06 +0100 | madresch | (~Thunderbi@user/madresch) madresch |
| 2026-03-07 09:37:58 +0100 | xff0x | (~xff0x@2405:6580:b080:900:acbe:a784:57c1:5e52) (Ping timeout: 256 seconds) |
| 2026-03-07 09:38:46 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4ba2:34a0:8fe0:b7c2) |
| 2026-03-07 09:39:54 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 244 seconds) |
| 2026-03-07 09:51:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 09:52:31 +0100 | bgamari_ | (~bgamari@64.223.168.27) |
| 2026-03-07 09:53:14 +0100 | bgamari | (~bgamari@64.223.173.201) (Ping timeout: 245 seconds) |
| 2026-03-07 09:53:33 +0100 | tzh | (~tzh@76.115.131.146) (Quit: zzz) |
| 2026-03-07 09:56:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 10:01:10 +0100 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 265 seconds) |
| 2026-03-07 10:04:15 +0100 | tomboy64 | (~tomboy64@user/tomboy64) tomboy64 |
| 2026-03-07 10:07:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 10:12:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-07 10:15:07 +0100 | Vizious | (~bes@user/Vizious) (Quit: WeeChat 4.6.3) |
| 2026-03-07 10:18:47 +0100 | humasect | (~humasect@192.249.132.90) (Quit: Leaving...) |
| 2026-03-07 10:20:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 10:23:39 +0100 | Vizious | (~bes@user/Vizious) Vizious |
| 2026-03-07 10:24:50 +0100 | Goodbye_Vincent1 | (cyvahl@freakshells.net) (Quit: ) |
| 2026-03-07 10:25:51 +0100 | Goodbye_Vincent1 | (cyvahl@freakshells.net) Goodbye_Vincent |
| 2026-03-07 10:27:16 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-07 10:27:20 +0100 | czan | (~czan@user/mange) czan |
| 2026-03-07 10:35:12 +0100 | aka_dude | (~aka_dude@192.71.166.120) (Quit: Gateway shutdown) |
| 2026-03-07 10:36:08 +0100 | aka_dude | (~aka_dude@2a03:f80:30:f490::1) |
| 2026-03-07 10:38:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 10:41:35 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 10:43:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 10:54:06 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 10:59:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-07 11:00:00 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-03-07 11:04:23 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-03-07 11:07:29 +0100 | Ranhir | (~Ranhir@157.97.53.139) (Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/) |
| 2026-03-07 11:10:00 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 11:14:27 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 11:14:56 +0100 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:6149:6cda:888:c7a0) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
| 2026-03-07 11:15:15 +0100 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) youngfrog |
| 2026-03-07 11:19:03 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-07 11:21:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 11:22:44 +0100 | img | (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-07 11:23:59 +0100 | img | (~img@user/img) img |
| 2026-03-07 11:25:05 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-07 11:26:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-03-07 11:26:34 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-07 11:29:48 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 264 seconds) |
| 2026-03-07 11:36:19 +0100 | Guest89 | (~Guest89@185.45.21.144) |
| 2026-03-07 11:37:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 11:39:06 +0100 | Beowulf | (florian@sleipnir.bandrate.org) (Quit: = "") |
| 2026-03-07 11:39:40 +0100 | <Guest89> | hello; I'm trying to profile an application that is rather performance sensitive and I'm hoping to reduce allocations as much as possible (this is for the purposes of a master's thesis I'm working on), but I'm having a little trouble isolating the hotspots in my code and understanding whether or not my code itself is overallocating as it is |
| 2026-03-07 11:39:41 +0100 | <Guest89> | written. would anyone be willing to help me figure things out? |
| 2026-03-07 11:40:11 +0100 | <Guest89> | garbage collection takes 3 times as long as the code itself for example, which I think seems very excessive. I've been trying to play around with things like ghc-compact but it didn't seem to help things any |
| 2026-03-07 11:41:21 +0100 | <haskellbridge> | <sm> hi Guest89 . It's not the easiest process, but it will be useful to generate a simple time and space profile - the profiling chapter in the GHC Users's Guide should tell how |
| 2026-03-07 11:41:50 +0100 | <haskellbridge> | <sm> you must make a profiling build of your app, then run it with special flags |
| 2026-03-07 11:42:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-07 11:44:12 +0100 | <haskellbridge> | <sm> it will be hard to understand completely, but full of useful information. You can also process it with https://hackage.haskell.org/package/profiterole which makes it more readable. |
| 2026-03-07 11:45:29 +0100 | <haskellbridge> | <sm> and you're right, it's overallocating (garbage collection should be a small percentage of your run time) |
| 2026-03-07 11:45:32 +0100 | <Guest89> | I'll be honest, I haven't figured out how to interact with packages like that yet; I've used stuff like eventlog2html but compiled as a separate executable |
| 2026-03-07 11:45:59 +0100 | <Guest89> | I've mostly relied on the metrics provided by different RTS options so far |
| 2026-03-07 11:46:16 +0100 | <Guest89> | it's verbose but I can navigate it at least? |
| 2026-03-07 11:46:33 +0100 | <haskellbridge> | <sm> yes, +RTS -s is useful |
| 2026-03-07 11:47:46 +0100 | <haskellbridge> | <loonycyborg> https://github.com/ezyang/compact <- this might help with excessive gc times |
| 2026-03-07 11:47:48 +0100 | <Guest89> | I have some data that suggests that the data itself isn't fragmented but the program allocates about twice as much as it uses, which also seems excessive |
| 2026-03-07 11:48:10 +0100 | <Guest89> | I've already been trying to use GHC.Compact but it doesn't seem to have affected runtimes at all |
| 2026-03-07 11:48:33 +0100 | <Guest89> | I assume there is some structure in my code that exacerbates the problem but I can't really see where |
| 2026-03-07 11:49:28 +0100 | <Guest89> | it's supposed to be an implementation of I/O efficient BDD (binary decision diagram) algorithms which necessarily generates a lot of data so I need some way to minimize overhead where it's reasonable |
| 2026-03-07 11:49:57 +0100 | Ranhir | (~Ranhir@157.97.53.139) Ranhir |
| 2026-03-07 11:50:08 +0100 | <haskellbridge> | <sm> it may be normal that the program uses 2 or even 3 times what you think, depending how you measure it, because of how GC works (making copies) |
| 2026-03-07 11:50:38 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 11:50:51 +0100 | <haskellbridge> | <sm> the time and space profile will show you the top users of time and space, and will show you any crazy large call counts indicating things called too often |
| 2026-03-07 11:50:56 +0100 | <Guest89> | I understand, but the issue is that my implementation uses something like 100 times as much memory as a reference implementation in C++ |
| 2026-03-07 11:51:26 +0100 | <Guest89> | obviously you can't get the performance *that* close, at least not in terms of memory, but as things are it's both an absurd difference and not feasible |
| 2026-03-07 11:51:37 +0100 | <haskellbridge> | <loonycyborg> Maybe it's thunk explosion somewhere, like from foldl |
| 2026-03-07 11:51:53 +0100 | <haskellbridge> | <sm> it requires investigation, there's no way round it |
| 2026-03-07 11:52:17 +0100 | <Guest89> | I've tried both strict and non-strict versions of foldl, and I didn't seem to see any issues |
| 2026-03-07 11:52:40 +0100 | <Guest89> | most of the actual allocation happens within the core algorithms, but I've also tried varying levels of strictness there |
| 2026-03-07 11:52:49 +0100 | <haskellbridge> | <loonycyborg> ye it's just an example |
| 2026-03-07 11:53:30 +0100 | <Guest89> | I just don't see how garbage collection can dominate the runtime so much |
| 2026-03-07 11:55:14 +0100 | <haskellbridge> | <sm> well, how much memory does +RTS -s say is being allocated ? |
| 2026-03-07 11:55:26 +0100 | <Guest89> | is it possible to paste pictures over IRC? |
| 2026-03-07 11:55:31 +0100 | <Guest89> | or should I just put it in writing |
| 2026-03-07 11:55:46 +0100 | <haskellbridge> | <sm> it's a lot easier if you use the matrix room |
| 2026-03-07 11:55:46 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 248 seconds) |
| 2026-03-07 11:55:58 +0100 | <Guest89> | not familiar |
| 2026-03-07 11:56:37 +0100 | <Guest89> | I guess I'll just write it down: |
| 2026-03-07 11:56:45 +0100 | <Leary> | Guest89: The problem is less likely to be allocations than unnecessary retention or unwanted thunks bloating your representation. Allocating is almost free, holding onto it is what costs you. In any case, I would start by heap profiling by type, which doesn't actually require a profiling build. |
| 2026-03-07 11:57:14 +0100 | <Leary> | @where paste |
| 2026-03-07 11:57:14 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2026-03-07 11:57:29 +0100 | Beowulf | (florian@sleipnir.bandrate.org) |
| 2026-03-07 11:57:34 +0100 | <Guest89> | https://paste.tomsmeding.com/xZZPhSCR |
| 2026-03-07 11:58:11 +0100 | <Guest89> | the only thing I haven't tried has to force computations in different places |
| 2026-03-07 11:58:49 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-07 11:58:57 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-07 11:59:04 +0100 | <Guest89> | my reference implementation generates only a few megabytes of data by comparison but again it's not comparable 1:1 |
| 2026-03-07 11:59:22 +0100 | hiecaq | (~hiecaq@user/hiecaq) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.2)) |
| 2026-03-07 11:59:28 +0100 | <haskellbridge> | <sm> how do you do that Leary ? |
| 2026-03-07 11:59:50 +0100 | <Guest89> | it's one of the -l(x) RTS settings |
| 2026-03-07 12:00:49 +0100 | <Leary> | -hT: https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-options-heap-prof |
| 2026-03-07 12:00:51 +0100 | <Guest89> | sorry, -h |
| 2026-03-07 12:01:03 +0100 | <Guest89> | i'll give it a whirl |
| 2026-03-07 12:01:49 +0100 | <Guest89> | I have some plots from using -hc that tells me which functions allocate the most but to be honest they're not particularly surprising in that department |
| 2026-03-07 12:02:32 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-07 12:02:52 +0100 | <Guest89> | also I've been relying on using eventlog2html but it seems to break fairly easily. are there any other options for visualizing the profiles? |
| 2026-03-07 12:08:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 12:11:08 +0100 | <Guest89> | seems the biggest allocations come from primitive types, tuples etc |
| 2026-03-07 12:15:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-07 12:16:09 +0100 | <probie> | Beyond the special syntax, tuples aren't really much different from `data T2 a b = T2 a b`, `data T3 a b c = T3 a b c`, `data T4 a b c d = T4 a b c d` etc. |
| 2026-03-07 12:17:07 +0100 | <Guest89> | I thought ghc treated them differently? |
| 2026-03-07 12:17:16 +0100 | <probie> | Why? |
| 2026-03-07 12:17:43 +0100 | <Guest89> | I just understood ghc optimized for tuples in particular over ordinary data constructors |
| 2026-03-07 12:21:47 +0100 | <Leary> | Guest89: It might here and there, but that doesn't mean you're better off using them. In particular, they're lazy, so they can easily accumulate big thunks. I suggest replacing such parts of your representation with suitably strict bespoke data declarations. |
| 2026-03-07 12:22:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 12:22:46 +0100 | <probie> | GHC is capable of doing something like `f x = (x, x+1)`, `g x = let (a, b) = f x in a + b` without actually allocating a tuple (assuming it can inline `f`), but that's the same for any user defined type as well |
| 2026-03-07 12:23:55 +0100 | <probie> | If you need multiple return values and can't afford an allocation, look at unboxed tuples (although this is likely overkill) |
| 2026-03-07 12:26:10 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2026-03-07 12:27:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-03-07 12:29:16 +0100 | <Guest89> | I tried playing around with unboxed tuples and different pragmas like unpacking but they seemed to have varying/counterintuitive results |
| 2026-03-07 12:29:47 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-03-07 12:29:55 +0100 | <Guest89> | I should probably experiment with it more but it seemed like allocations went down only a little (or at least less than I expected) while somehow runtimes increased slightly |
| 2026-03-07 12:30:20 +0100 | <Guest89> | but it kind of feels like I am at the kitchen sink stage in general if I'm being honest |
| 2026-03-07 12:31:40 +0100 | <Guest89> | actually, one thing I have been doing in general is guard patterns for unpacking. are they lazy as well or strict the same way pattern matching is? |
| 2026-03-07 12:33:56 +0100 | <haskellbridge> | <sm> Guest89 you won't be able to fix it by kitchen sink experimenting, you'll need to dig in and understand. There's likely many causes of space leak |
| 2026-03-07 12:34:24 +0100 | <haskellbridge> | <sm> reducing to a simple program you can share, may help |
| 2026-03-07 12:35:18 +0100 | <haskellbridge> | <sm> or, commenting out large chunks of your program to see what makes a difference |
| 2026-03-07 12:35:51 +0100 | <haskellbridge> | <sm> if you make a profile, people here will help you read it |
| 2026-03-07 12:38:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 12:38:34 +0100 | <Guest89> | when you say *make* a profile, what do you mean exactly? |
| 2026-03-07 12:38:54 +0100 | <haskellbridge> | <sm> I looked it up: stack install --profile PROG; PROG +RTS -P -RTS ... this will save PROG.prof |
| 2026-03-07 12:38:58 +0100 | <Guest89> | I've got the files from profiling and some html pages rendered from them if that's what you mean |
| 2026-03-07 12:39:54 +0100 | <Guest89> | do you just want a file dump? |
| 2026-03-07 12:40:02 +0100 | <haskellbridge> | <sm> do you have a .prof file ? |
| 2026-03-07 12:40:07 +0100 | <Guest89> | yes |
| 2026-03-07 12:40:18 +0100 | <haskellbridge> | <sm> by all means show it :) |
| 2026-03-07 12:40:51 +0100 | <Guest89> | https://paste.tomsmeding.com/AUb2v7Sh |
| 2026-03-07 12:41:02 +0100 | Square3 | (~Square@user/square) Square |
| 2026-03-07 12:41:39 +0100 | <haskellbridge> | <sm> lovely. And it might be interesting to run profiterole on that too. |
| 2026-03-07 12:42:17 +0100 | <Guest89> | will try |
| 2026-03-07 12:43:01 +0100 | <haskellbridge> | <sm> see the entries column.. you have something being called 26 million times, eg. Is that what you'd expect ? Is the data that large ? |
| 2026-03-07 12:43:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-07 12:43:12 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 12:43:34 +0100 | <Guest89> | so currently on a benchmark that I have (encoding `n-queens`) the number of nodes in my data structure is expected to quadruple for each n but currently space and time seems to increase 10-fold instead |
| 2026-03-07 12:43:46 +0100 | <Guest89> | but on that particular run; no, that is excessive |
| 2026-03-07 12:44:02 +0100 | <haskellbridge> | <sm> it sounds like something is doing too much work |
| 2026-03-07 12:44:30 +0100 | <haskellbridge> | <sm> $wbddApply'' is called half a million times |
| 2026-03-07 12:44:50 +0100 | <Guest89> | let me try something for a quick sanity check |
| 2026-03-07 12:44:57 +0100 | <haskellbridge> | <sm> $sinsert_$sgo4 14 million. maybe one of those... |
| 2026-03-07 12:45:47 +0100 | <haskellbridge> | <sm> (I don't know why these names are obfuscated) |
| 2026-03-07 12:46:07 +0100 | <Guest89> | I don't know what they are either |
| 2026-03-07 12:46:16 +0100 | <Guest89> | I've only seem them now that I'm running with -P instead of -p |
| 2026-03-07 12:47:02 +0100 | <Guest89> | well insert is probably from the data structure I use to maintain a priority queue |
| 2026-03-07 12:48:17 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-07 12:50:02 +0100 | <Guest89> | so in this particular example the data is generated from a fold that iteratively uses bddApply on new BDDs, but only 7 times total. the largest BDDs being applied have a few thousand nodes each, which means that the upper bound for bddApply will necessarily be in the millions |
| 2026-03-07 12:50:19 +0100 | <Guest89> | but most likely it should be less than that because of short circuiting on a lot of the node combinations |
| 2026-03-07 12:50:44 +0100 | <Guest89> | it seems like a lot but I can't dismiss it as unexpected |
| 2026-03-07 12:52:51 +0100 | <haskellbridge> | <sm> it looks like there's a lot comparing needed to do an insert. Is it your own custom priority queue ? |
| 2026-03-07 12:54:13 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-03-07 12:54:15 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 12:56:58 +0100 | Guest89 | (~Guest89@185.45.21.144) (Ping timeout: 240 seconds) |
| 2026-03-07 12:58:49 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 12:58:53 +0100 | <haskellbridge> | <sm> got to go.. good luck |
| 2026-03-07 12:59:28 +0100 | bggd__ | (~bgg@2a01:e0a:fd5:f510:537e:c033:7f9f:3728) |
| 2026-03-07 13:03:00 +0100 | fun-safe-math | (~fun-safe-@97.115.234.213) () |
| 2026-03-07 13:05:04 +0100 | fun-safe-math | (~fun-safe-@97.115.234.213) fun-safe-math |
| 2026-03-07 13:06:12 +0100 | Square3 | (~Square@user/square) (Remote host closed the connection) |
| 2026-03-07 13:06:30 +0100 | Square | (~Square@user/square) Square |
| 2026-03-07 13:09:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 13:11:01 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2026-03-07 13:13:14 +0100 | czan | (~czan@user/mange) (Ping timeout: 245 seconds) |
| 2026-03-07 13:14:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 13:19:46 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-03-07 13:23:39 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 13:26:35 +0100 | Guest89 | (~Guest89@185.45.21.144) |
| 2026-03-07 13:27:09 +0100 | <Guest89> | sorry I think I lost connection; I posted some replies to you sm but I'm not sure if they got through? |
| 2026-03-07 13:28:10 +0100 | <int-e> | no, but also: <+haskellbridge> <sm> got to go.. good luck |
| 2026-03-07 13:28:16 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 13:28:20 +0100 | <Guest89> | darn |
| 2026-03-07 13:29:55 +0100 | <Guest89> | if anyone else has any suggestions in the meantime, this is how my comparators are defined for the busiest functions https://paste.tomsmeding.com/jSnEEitE |
| 2026-03-07 13:36:52 +0100 | Tuplanolla | (~Tuplanoll@88-114-89-88.elisa-laajakaista.fi) Tuplanolla |
| 2026-03-07 13:39:11 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 13:43:53 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-03-07 13:45:36 +0100 | <Leary> | Guest89: All of your data is lazy, even `Uid`; `data Uid = Uid {-# UNPACK #-} !(Int, Int)` is essentially equivalent to `data Uid = Uid Int Int`. If you're not utilising that laziness, kill it with strictness annotations. |
| 2026-03-07 13:46:08 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 252 seconds) |
| 2026-03-07 13:48:05 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-07 13:51:29 +0100 | <Guest89> | I presume you mean at a function level? |
| 2026-03-07 13:51:34 +0100 | <Guest89> | I assumed the unpack itself made it strict |
| 2026-03-07 13:53:19 +0100 | <Leary> | No, the data constructors. `data Uid = Uid !Int !Int`; `data Ptr = PtrLeaf !Bool | PtrNode !Uid`; etc. |
| 2026-03-07 13:53:38 +0100 | <Guest89> | so what does unpack do in this case? |
| 2026-03-07 13:54:07 +0100 | <Guest89> | does it just transform the constructor into another one with the same arity as the tuples? |
| 2026-03-07 13:54:20 +0100 | <int-e> | yes |
| 2026-03-07 13:54:24 +0100 | <Leary> | `UNPACK` is only a hint for the compiler; it can't fundamentally change the semantics, which include the fields of `(,)` being lazy---that blocks any further unpacking. |
| 2026-03-07 13:55:10 +0100 | <Guest89> | right, but bangs force a semantics change? |
| 2026-03-07 13:55:36 +0100 | <Leary> | Yes. |
| 2026-03-07 13:56:06 +0100 | <Guest89> | I will play around and see what changes |
| 2026-03-07 13:56:38 +0100 | <int-e> | if you have data X = X (Int,Int) and data Y = Y !(Int,Int) then the difference is that you can have an `X bottom` value that's distinct from bottom, but `Y bottom` is just bottom. |
| 2026-03-07 13:56:55 +0100 | <int-e> | But you can still have Y (bottom, bottom) |
| 2026-03-07 13:57:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 13:57:27 +0100 | <Guest89> | I haven't really figured how you can even get bottom in practice |
| 2026-03-07 13:57:54 +0100 | <int-e> | And for a lazy language, you can also have thunks whereever bottoms can go, so you can't unpack anything in those places. |
| 2026-03-07 13:58:02 +0100 | <int-e> | > undefined |
| 2026-03-07 13:58:03 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2026-03-07 13:58:03 +0100 | <lambdabot> | CallStack (from HasCallStack): |
| 2026-03-07 13:58:03 +0100 | <lambdabot> | undefined, called at <interactive>:3:1 in interactive:Ghci1 |
| 2026-03-07 13:58:05 +0100 | <int-e> | > fix id |
| 2026-03-07 13:58:12 +0100 | <lambdabot> | *Exception: <<timeout>> |
| 2026-03-07 13:58:29 +0100 | <Guest89> | fair point |
| 2026-03-07 13:58:31 +0100 | <int-e> | (Those are the usual manifestations in Haskell: an explicit error value, or nontermination) |
| 2026-03-07 13:58:56 +0100 | <Guest89> | guess I assumed it to be semantically different from an exception but I think I get what you mean |
| 2026-03-07 13:59:45 +0100 | <Guest89> | I guess the point is that you prefer strict data when it contains primitives? |
| 2026-03-07 14:00:03 +0100 | <int-e> | yes, usually |
| 2026-03-07 14:00:13 +0100 | <Guest89> | makes sense I suppose |
| 2026-03-07 14:00:24 +0100 | <haskellbridge> | <loonycyborg> > length [undefined, undefined, undefined] |
| 2026-03-07 14:00:31 +0100 | <haskellbridge> | <loonycyborg> hmm |
| 2026-03-07 14:00:43 +0100 | <haskellbridge> | <loonycyborg> it ate '>' |
| 2026-03-07 14:00:59 +0100 | <Guest89> | and I guess the same if you have strict data in another type? |
| 2026-03-07 14:01:22 +0100 | <int-e> | (Unpacking isn't completely free: If you unpack and later repack a value, that means a new heap object has to be created for it. This is why for data, GHC only does it when you give it a hint to do so.) |
| 2026-03-07 14:01:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 14:01:45 +0100 | <__monty__> | loonycyborg: No, the Matrix bridge is a single bot IRC-side. So your messages are prefixed with your nick. |
| 2026-03-07 14:02:24 +0100 | <haskellbridge> | <loonycyborg> is there a way to interact with lambabot from matrix? |
| 2026-03-07 14:05:16 +0100 | <Leary> | I gather you just need to put the command in a second line. |
| 2026-03-07 14:05:57 +0100 | tremon | (~tremon@83.80.159.219) tremon |
| 2026-03-07 14:06:27 +0100 | <__monty__> | Isn't each line prefixed? |
| 2026-03-07 14:09:23 +0100 | <[exa]> | tusko: do write in other languages to learn and appreciate the difference. :] |
| 2026-03-07 14:11:33 +0100 | <Leary> | __monty__: See this snippet I grepped from my logs: https://paste.tomsmeding.com/dXOuNbFn |
| 2026-03-07 14:13:10 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-07 14:15:07 +0100 | <__monty__> | Ah, great, that should work for loonycyborg then. |
| 2026-03-07 14:17:21 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 244 seconds) |
| 2026-03-07 14:22:25 +0100 | <haskellbridge> | <loonycyborg> > length [undefined, undefined, undefined] |
| 2026-03-07 14:22:36 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 264 seconds) |
| 2026-03-07 14:22:55 +0100 | <__monty__> | loonycyborg: Was that with a blank line? Maybe it can't be blank. |
| 2026-03-07 14:24:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 14:24:54 +0100 | <haskellbridge> | <loonycyborg> test |
| 2026-03-07 14:24:54 +0100 | <haskellbridge> | test |
| 2026-03-07 14:25:16 +0100 | <haskellbridge> | <loonycyborg> is one of those tests without prefix? |
| 2026-03-07 14:25:26 +0100 | <__monty__> | Yep, the latter. |
| 2026-03-07 14:26:11 +0100 | <int-e> | well, it had a leading space |
| 2026-03-07 14:26:14 +0100 | <haskellbridge> | <loonycyborg> test |
| 2026-03-07 14:26:14 +0100 | <haskellbridge> | length [undefined, undefined, undefined] |
| 2026-03-07 14:26:30 +0100 | <haskellbridge> | <loonycyborg> test |
| 2026-03-07 14:26:30 +0100 | <haskellbridge> | > length [undefined, undefined, undefined] |
| 2026-03-07 14:26:31 +0100 | <lambdabot> | 3 |
| 2026-03-07 14:26:50 +0100 | <haskellbridge> | <loonycyborg> hmm nice |
| 2026-03-07 14:26:55 +0100 | <[exa]> | Guest89: based on my experience on a similar project that allocated a lot, you really want to make the tuples strict. |
| 2026-03-07 14:27:17 +0100 | <haskellbridge> | <loonycyborg> > length [undefined, undefined, undefined] |
| 2026-03-07 14:28:19 +0100 | <[exa]> | ( "similar" based solely on fact I had complex IDs and a structure of them :D ) |
| 2026-03-07 14:28:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-07 14:29:34 +0100 | <Guest89> | yeah I'm working on it exa; I'm not seeing as big a reduction in memory as I expected. seems more thunks are being allocated now instead |
| 2026-03-07 14:30:27 +0100 | <[exa]> | Guest89: do you have some compiler options that force it to specialize stuff? |
| 2026-03-07 14:30:35 +0100 | <Guest89> | not anything that specializes |
| 2026-03-07 14:30:38 +0100 | <[exa]> | Guest89: ( ghc-options: -O2 -fspecialise-aggressively -fexpose-all-unfoldings ) |
| 2026-03-07 14:30:57 +0100 | <Guest89> | I've got -O1 enabled atm but I didn't observe much when I tried -O2 |
| 2026-03-07 14:31:03 +0100 | <Guest89> | I can try some of the other settings later though |
| 2026-03-07 14:31:19 +0100 | <Guest89> | mostly I've tried to use pragmas to force things like inlining, but I haven't done anything to specialize |
| 2026-03-07 14:31:45 +0100 | <Guest89> | what are the benefits of specializing, exactly? |
| 2026-03-07 14:31:53 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-07 14:31:57 +0100 | <[exa]> | in short ghc seemed quite lazy to inline stuff across modules unless I asked for it explicitly |
| 2026-03-07 14:32:17 +0100 | <[exa]> | if you specialize code you don't need to send the typeclass pointer around |
| 2026-03-07 14:32:31 +0100 | <[exa]> | and the specialized code is much more likely to realize that it can do stuff strictly |
| 2026-03-07 14:32:34 +0100 | <Guest89> | because it has a separate definition already? |
| 2026-03-07 14:32:38 +0100 | <Guest89> | from the specialization |
| 2026-03-07 14:32:43 +0100 | <[exa]> | yeah |
| 2026-03-07 14:32:43 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-03-07 14:32:45 +0100 | <Guest89> | hmm |
| 2026-03-07 14:33:00 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-03-07 14:33:06 +0100 | <Guest89> | you have to do twice the work though in terms of source code though, right? |
| 2026-03-07 14:33:38 +0100 | <[exa]> | like, the part with typeclass dictionaries getting passed around is not a huge deal, but in the end you may have 1 less allocation, and the possibility to specialize is open |
| 2026-03-07 14:33:54 +0100 | <[exa]> | yeah it may cost an extra copy of the code |
| 2026-03-07 14:34:20 +0100 | <[exa]> | (tbh my binary changed from like 9M to 9.5M when I was trying it, so I decided I don't care) |
| 2026-03-07 14:35:36 +0100 | <Guest89> | I'm doing this for my master's thesis, but I'll probably end up presenting a "clean" version that's semantically correct in the thesis itself and then using an optimized version for the actual benchmarks |
| 2026-03-07 14:35:53 +0100 | <Guest89> | my tl;dr is that the extra LOC should be whatever |
| 2026-03-07 14:36:39 +0100 | <[exa]> | Guest89: by "semantically correct" you mean "readable" :D |
| 2026-03-07 14:37:12 +0100 | CallipygousPepe | (~reuben@user/CallipygousPepe) CallipygousPepe |
| 2026-03-07 14:37:45 +0100 | <Guest89> | well it's supposed to be an implementation that can be used as a jumping-off point if someone more nerdy about proofs would want to make a provably correct version |
| 2026-03-07 14:38:16 +0100 | <Guest89> | so compiler- or language-specific optimizations are kind of not the point there |
| 2026-03-07 14:38:23 +0100 | <[exa]> | anyway lots of the allocations in your profile actually seem to point to typeclass methods so I guess that a bit of specialization could help there |
| 2026-03-07 14:38:30 +0100 | <Guest89> | I will look into it |
| 2026-03-07 14:38:52 +0100 | madresch | (~Thunderbi@user/madresch) (Ping timeout: 256 seconds) |
| 2026-03-07 14:38:53 +0100 | <Guest89> | inlining seemed to take the worst of the initial overhead (like 20% or something) but yeah, thunsk everywhere |
| 2026-03-07 14:39:25 +0100 | <[exa]> | also do add bangs to all your datatype definitions (Pair !Ptr !Ptr, etc) |
| 2026-03-07 14:39:48 +0100 | <[exa]> | (except the ones where you know that laziness is required) |
| 2026-03-07 14:40:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 14:41:02 +0100 | <Guest89> | I mean the primary data structure is itself one big list, but I'm still not sure whether laziness or not is the way to go |
| 2026-03-07 14:42:41 +0100 | <[exa]> | well lmk if these 2 things change anything, if not I'd say we profile again and see |
| 2026-03-07 14:43:01 +0100 | <Guest89> | I've cut off about 30% of the allocations so far with it |
| 2026-03-07 14:43:03 +0100 | <Guest89> | do you want a new profile? |
| 2026-03-07 14:43:23 +0100 | <[exa]> | oh cool |
| 2026-03-07 14:43:42 +0100 | <Guest89> | we could move to a separate chat if you want |
| 2026-03-07 14:44:17 +0100 | <[exa]> | btw you can write that case-y comparison as: `compare s1 s2 <> compare r1 r2 <> compare ishigh1 ishigh2` |
| 2026-03-07 14:44:24 +0100 | <Guest89> | ooo |
| 2026-03-07 14:44:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-07 14:45:39 +0100 | <[exa]> | btw do you store these things in some kindof priority queue or ordered container or so? |
| 2026-03-07 14:45:51 +0100 | <Guest89> | yes |
| 2026-03-07 14:45:57 +0100 | <[exa]> | so a priority list? |
| 2026-03-07 14:46:02 +0100 | <Guest89> | it's not as much of a hot spot as I expected |
| 2026-03-07 14:46:20 +0100 | <[exa]> | just in case lemme find my quickhacked heapqueue implementation |
| 2026-03-07 14:46:27 +0100 | <Guest89> | right now it's just a red-black tree so it's not an optimal priority queue |
| 2026-03-07 14:46:42 +0100 | <Guest89> | I was conisdering using I think it's called PQueue? |
| 2026-03-07 14:46:51 +0100 | <Guest89> | the only asymptotic difference is constant or log time lookup though |
| 2026-03-07 14:47:43 +0100 | <Guest89> | otherwise I have some toy implementations from chris okasaki's book but it's, uhh, not working as intended right now |
| 2026-03-07 14:48:09 +0100 | <[exa]> | PQueues are great IF you need to also pick the elements by some index |
| 2026-03-07 14:48:21 +0100 | <[exa]> | if not they are strictly slower than a manual arrayheap |
| 2026-03-07 14:48:28 +0100 | <Guest89> | I only ever need the smallest element |
| 2026-03-07 14:48:41 +0100 | <Guest89> | part of my thesis involves *not* using arrays though |
| 2026-03-07 14:49:27 +0100 | <[exa]> | tuple is also an array |
| 2026-03-07 14:49:30 +0100 | [exa] | hides |
| 2026-03-07 14:49:47 +0100 | <haskellbridge> | <loonycyborg> if you ever need smallest element you can use set |
| 2026-03-07 14:50:01 +0100 | <[exa]> | +1 for set, not too slow at all |
| 2026-03-07 14:50:36 +0100 | <[exa]> | anyway I ended up replacing pqueue with this (the code is essentially a multi-stream merge): https://paste.tomsmeding.com/UskOMkBm, was like 3x faster |
| 2026-03-07 14:51:41 +0100 | <[exa]> | (apologies for the streaming mess around) |
| 2026-03-07 14:52:32 +0100 | <[exa]> | (missing def.: ofKey (a :> _) = a ) |
| 2026-03-07 14:55:52 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |