| 2025-01-13 00:07:06 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 00:11:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-13 00:21:28 +0100 | elnegro | (elnegro@r186-52-121-168.dialup.adsl.anteldata.net.uy) (Remote host closed the connection) |
| 2025-01-13 00:22:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 00:26:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 00:28:30 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-13 00:33:40 +0100 | dysthesis | (~dysthesis@user/dysthesis) dysthesis |
| 2025-01-13 00:37:50 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 00:41:48 +0100 | raym | (~ray@user/raym) (Ping timeout: 252 seconds) |
| 2025-01-13 00:43:46 +0100 | raym | (~ray@user/raym) raym |
| 2025-01-13 00:44:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-13 00:55:17 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 00:59:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 01:10:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 01:12:03 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.37) Jeanne-Kamikaze |
| 2025-01-13 01:13:42 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-01-13 01:14:55 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 01:17:36 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-01-13 01:20:44 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-13 01:22:32 +0100 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2025-01-13 01:26:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 01:29:07 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-13 01:30:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 01:35:49 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds) |
| 2025-01-13 01:36:30 +0100 | sprotte24_ | (~sprotte24@p200300d16f1ab700b95fa6f61d41c09f.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-01-13 01:38:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-01-13 01:39:03 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-13 01:40:46 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f06081469c6fc5c461d.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-01-13 01:41:24 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 01:42:28 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-13 01:43:20 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) (Ping timeout: 244 seconds) |
| 2025-01-13 01:45:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 01:52:14 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-13 01:56:47 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 01:58:19 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
| 2025-01-13 02:01:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 02:05:11 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2025-01-13 02:06:02 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2025-01-13 02:12:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 02:18:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 02:30:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 02:31:24 +0100 | OftenFaded | (~OftenFade@user/tisktisk) (Quit: OftenFaded) |
| 2025-01-13 02:34:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 02:36:04 +0100 | otto_s | (~user@p4ff27ed7.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-01-13 02:37:22 +0100 | otto_s | (~user@p5de2fe2f.dip0.t-ipconnect.de) |
| 2025-01-13 02:39:36 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@79.127.217.37) (Ping timeout: 252 seconds) |
| 2025-01-13 02:40:43 +0100 | dysthesis | (~dysthesis@user/dysthesis) (Remote host closed the connection) |
| 2025-01-13 02:45:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 02:50:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-13 02:56:43 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-13 03:00:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 03:05:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-13 03:16:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 03:21:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 03:22:45 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2025-01-13 03:31:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 03:36:20 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 03:38:11 +0100 | dontdieych2 | (~quassel@user/dontdieych2) dontdieych2 |
| 2025-01-13 03:42:06 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2025-01-13 03:47:05 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 03:52:16 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) (Quit: connecting on another system) |
| 2025-01-13 03:52:28 +0100 | hueso | (~root@user/hueso) (Quit: hueso) |
| 2025-01-13 03:52:50 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) rekahsoft |
| 2025-01-13 03:54:27 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-13 03:56:53 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2025-01-13 04:02:53 +0100 | hueso | (~root@user/hueso) hueso |
| 2025-01-13 04:05:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 04:05:51 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-13 04:09:42 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 04:13:00 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-13 04:23:00 +0100 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Read error: Connection reset by peer) |
| 2025-01-13 04:25:14 +0100 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) sciencentistguy |
| 2025-01-13 04:26:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 04:30:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 04:31:59 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-13 04:41:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 04:46:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 04:48:09 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2025-01-13 04:55:59 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-13 04:59:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 05:04:39 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-13 05:05:24 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) (Ping timeout: 245 seconds) |
| 2025-01-13 05:05:35 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2025-01-13 05:05:57 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2025-01-13 05:08:29 +0100 | homo | (~homo@user/homo) (Read error: Connection reset by peer) |
| 2025-01-13 05:09:40 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:198e:8888:ba04:6650) (Ping timeout: 260 seconds) |
| 2025-01-13 05:10:39 +0100 | mari11300 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-13 05:12:33 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 248 seconds) |
| 2025-01-13 05:15:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 05:18:51 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:903c:1567:85ba:7c1c) dtman34 |
| 2025-01-13 05:22:24 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 05:23:40 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:903c:1567:85ba:7c1c) (Ping timeout: 260 seconds) |
| 2025-01-13 05:33:38 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 05:38:18 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-13 05:38:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 05:45:15 +0100 | Xe | (~Xe@perl/impostor/xe) (Ping timeout: 260 seconds) |
| 2025-01-13 05:49:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 05:51:12 +0100 | Xe | (~Xe@perl/impostor/xe) Xe |
| 2025-01-13 05:53:39 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:903c:1567:85ba:7c1c) dtman34 |
| 2025-01-13 05:55:40 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 06:07:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 06:08:54 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-13 06:11:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 06:13:24 +0100 | OftenFaded | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-13 06:18:25 +0100 | michalz | (~michalz@185.246.207.217) |
| 2025-01-13 06:22:25 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 06:27:09 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 06:37:48 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 06:42:15 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-13 06:53:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 06:57:04 +0100 | dnerchm^ | (dnerchm@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 245 seconds) |
| 2025-01-13 06:57:04 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 245 seconds) |
| 2025-01-13 06:57:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-13 07:00:53 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 07:02:01 +0100 | ft | (~ft@p4fc2a354.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-01-13 07:05:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-13 07:10:44 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-01-13 07:13:31 +0100 | Square | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2025-01-13 07:16:47 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2025-01-13 07:17:18 +0100 | Square | (~Square@user/square) Square |
| 2025-01-13 07:23:07 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-13 07:23:49 +0100 | Square | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2025-01-13 07:24:15 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 246 seconds) |
| 2025-01-13 07:24:15 +0100 | tnt2 | tnt1 |
| 2025-01-13 07:31:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 07:38:13 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-13 07:49:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 07:52:00 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f35081469c6fc5c461d.dip0.t-ipconnect.de) |
| 2025-01-13 07:52:05 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2025-01-13 07:53:59 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-01-13 07:54:35 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-13 07:54:40 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-13 07:54:41 +0100 | dnerchm^ | (~dnerchm@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-13 07:57:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2025-01-13 07:59:09 +0100 | CiaoSen | (~Jura@2a05:5800:208:a200:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-13 08:00:29 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-13 08:01:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 08:06:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 08:16:23 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-01-13 08:17:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 08:19:53 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-13 08:20:49 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 245 seconds) |
| 2025-01-13 08:20:49 +0100 | tnt2 | tnt1 |
| 2025-01-13 08:21:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 08:21:49 +0100 | hsw_ | (~hsw@112-104-8-145.adsl.dynamic.seed.net.tw) (Read error: Connection reset by peer) |
| 2025-01-13 08:22:07 +0100 | hsw_ | (~hsw@112-104-8-145.adsl.dynamic.seed.net.tw) hsw |
| 2025-01-13 08:24:25 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-13 08:25:15 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-13 08:25:15 +0100 | tnt2 | tnt1 |
| 2025-01-13 08:32:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 08:37:04 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2025-01-13 08:37:55 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2025-01-13 08:41:18 +0100 | mud | (~mud@user/kadoban) kadoban |
| 2025-01-13 08:42:06 +0100 | kadobanana | (~mud@user/kadoban) (Read error: Connection reset by peer) |
| 2025-01-13 08:42:45 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-13 08:47:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 08:52:54 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-13 08:55:39 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-13 08:58:18 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-13 09:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-13 09:00:42 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-13 09:01:25 +0100 | danz63877 | (~danza@user/danza) danza |
| 2025-01-13 09:02:22 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-13 09:02:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 09:04:20 +0100 | danza | (~danza@user/danza) (Ping timeout: 264 seconds) |
| 2025-01-13 09:04:43 +0100 | mari11300 | (~mari-este@user/mari-estel) (Ping timeout: 265 seconds) |
| 2025-01-13 09:07:42 +0100 | alecs | (~alecs@nat16.software.imdea.org) alecs |
| 2025-01-13 09:07:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-13 09:18:34 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-13 09:32:53 +0100 | chele | (~chele@user/chele) chele |
| 2025-01-13 09:35:11 +0100 | dontdieych2 | (~quassel@user/dontdieych2) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2025-01-13 09:46:21 +0100 | kuribas | (~user@ptr-17d51epu50i07rg06yn.18120a2.ip6.access.telenet.be) kuribas |
| 2025-01-13 09:48:27 +0100 | internatetional | (~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) internatetional |
| 2025-01-13 09:53:43 +0100 | internatetional | (~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) (Quit: WeeChat 4.5.1) |
| 2025-01-13 09:59:05 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-13 10:00:33 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-13 10:00:35 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-01-13 10:00:35 +0100 | tnt2 | tnt1 |
| 2025-01-13 10:01:45 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-13 10:02:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 10:12:17 +0100 | danz63877 | (~danza@user/danza) (Remote host closed the connection) |
| 2025-01-13 10:12:33 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-13 10:14:42 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-01-13 10:18:51 +0100 | califax | (~califax@user/califx) califx |
| 2025-01-13 10:27:00 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-01-13 10:27:12 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-01-13 10:27:18 +0100 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-13 10:34:04 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-13 10:34:37 +0100 | Typedfern | (~Typedfern@106.red-83-37-34.dynamicip.rima-tde.net) (Ping timeout: 265 seconds) |
| 2025-01-13 10:35:43 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 10:40:02 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-13 10:40:53 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) |
| 2025-01-13 10:45:28 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-01-13 10:47:33 +0100 | Typedfern | (~Typedfern@106.red-83-37-34.dynamicip.rima-tde.net) |
| 2025-01-13 10:48:57 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-01-13 10:53:02 +0100 | mari15751 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-13 10:53:12 +0100 | danz79448 | (~danza@user/danza) danza |
| 2025-01-13 10:55:34 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 272 seconds) |
| 2025-01-13 10:55:35 +0100 | danza | (~danza@user/danza) (Ping timeout: 260 seconds) |
| 2025-01-13 11:07:57 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-01-13 11:09:25 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-01-13 11:10:00 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-01-13 11:22:18 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 11:28:01 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-01-13 11:37:35 +0100 | alexherbo2 | (~alexherbo@2a02-8440-e502-b62f-45c1-19be-c4a2-0325.rev.sfr.net) alexherbo2 |
| 2025-01-13 11:38:24 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 11:40:50 +0100 | CiaoSen | (~Jura@2a05:5800:208:a200:ca4b:d6ff:fec1:99da) (Ping timeout: 265 seconds) |
| 2025-01-13 11:45:13 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 252 seconds) |
| 2025-01-13 11:58:32 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2025-01-13 12:05:28 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-01-13 12:17:30 +0100 | califax_ | (~califax@user/califx) califx |
| 2025-01-13 12:17:36 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-01-13 12:18:12 +0100 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-01-13 12:18:44 +0100 | califax_ | califax |
| 2025-01-13 12:18:48 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 264 seconds) |
| 2025-01-13 12:18:55 +0100 | chexum_ | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-01-13 12:19:58 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-01-13 12:25:54 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2025-01-13 12:28:39 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-01-13 12:38:36 +0100 | CiaoSen | (~Jura@2a05:5800:208:a200:ca4b:d6ff:fec1:99da) CiaoSen |
| 2025-01-13 12:40:40 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-01-13 12:43:12 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-01-13 12:49:52 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 12:59:04 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
| 2025-01-13 13:00:59 +0100 | lbseale | (~quassel@user/ep1ctetus) (Ping timeout: 252 seconds) |
| 2025-01-13 13:04:29 +0100 | lortabac | (~lortabac@88-125-6-227.subs.proxad.net) lortabac |
| 2025-01-13 13:07:20 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-13 13:12:34 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 13:15:34 +0100 | orangeFlu | (~orangeFlu@240-100-179-143.ftth.glasoperator.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 13:21:36 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 246 seconds) |
| 2025-01-13 13:23:45 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-13 13:25:43 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-01-13 13:27:37 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 13:29:10 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 13:37:32 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) |
| 2025-01-13 13:42:43 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-13 13:42:47 +0100 | akegalj | (~akegalj@142-231.dsl.iskon.hr) akegalj |
| 2025-01-13 13:45:51 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-13 13:48:05 +0100 | dontdieych2 | (~quassel@user/dontdieych2) dontdieych2 |
| 2025-01-13 13:49:06 +0100 | mari15751 | (~mari-este@user/mari-estel) (Quit: overwhelm) |
| 2025-01-13 14:00:48 +0100 | chenggong7788 | (~chenggong@162.248.73.62) chenggong7788 |
| 2025-01-13 14:01:56 +0100 | chenggong7788 | nil78 |
| 2025-01-13 14:02:54 +0100 | danz79448 | (~danza@user/danza) (Ping timeout: 246 seconds) |
| 2025-01-13 14:04:00 +0100 | akegalj | (~akegalj@142-231.dsl.iskon.hr) (Quit: leaving) |
| 2025-01-13 14:05:05 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Read error: Connection reset by peer) |
| 2025-01-13 14:05:20 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-13 14:05:34 +0100 | jespada | (~jespada@2800:a4:1fd:ad00:50c2:f579:e377:bf59) jespada |
| 2025-01-13 14:06:59 +0100 | chexum_ | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2025-01-13 14:07:09 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2025-01-13 14:09:49 +0100 | nil78 | (~chenggong@162.248.73.62) (Quit: Client closed) |
| 2025-01-13 14:13:54 +0100 | housemate | (~housemate@146.70.66.228) (Ping timeout: 276 seconds) |
| 2025-01-13 14:19:07 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 14:22:11 +0100 | merijn | (~merijn@77.242.116.146) (Remote host closed the connection) |
| 2025-01-13 14:22:28 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-13 14:23:22 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-13 14:31:36 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 246 seconds) |
| 2025-01-13 14:32:18 +0100 | mreh | (~matthew@host86-146-25-121.range86-146.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2025-01-13 14:32:35 +0100 | housemate | (~housemate@146.70.66.228) (Ping timeout: 260 seconds) |
| 2025-01-13 14:33:29 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-13 14:33:38 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-13 14:35:53 +0100 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2025-01-13 14:36:17 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-13 14:41:46 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-01-13 14:45:57 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 248 seconds) |
| 2025-01-13 14:52:56 +0100 | danza | (~danza@user/danza) (Read error: Connection reset by peer) |
| 2025-01-13 14:54:03 +0100 | danza | (~danza@user/danza) danza |
| 2025-01-13 14:58:56 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-13 15:10:10 +0100 | CiaoSen | (~Jura@2a05:5800:208:a200:ca4b:d6ff:fec1:99da) (Ping timeout: 272 seconds) |
| 2025-01-13 15:12:53 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2025-01-13 15:15:55 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-01-13 15:20:16 +0100 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2025-01-13 15:27:58 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-13 15:31:12 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2025-01-13 15:36:54 +0100 | gentauro | (~gentauro@user/gentauro) gentauro |
| 2025-01-13 15:37:37 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 2025-01-13 15:39:27 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-13 15:41:35 +0100 | ChanServ | +o tomsmeding |
| 2025-01-13 15:44:57 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-13 15:45:29 +0100 | alexherbo2 | (~alexherbo@2a02-8440-e502-b62f-45c1-19be-c4a2-0325.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-13 15:45:29 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-13 15:46:36 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2025-01-13 15:46:59 +0100 | alexherbo2 | (~alexherbo@2a02-8440-e502-b62f-1cd7-f123-37f9-6156.rev.sfr.net) alexherbo2 |
| 2025-01-13 15:50:05 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 272 seconds) |
| 2025-01-13 15:50:15 +0100 | alexherbo2 | (~alexherbo@2a02-8440-e502-b62f-1cd7-f123-37f9-6156.rev.sfr.net) (Remote host closed the connection) |
| 2025-01-13 15:51:24 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 276 seconds) |
| 2025-01-13 15:51:24 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-13 15:52:17 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-13 16:00:08 +0100 | mchav | (~mchav@c-98-59-172-239.hsd1.wa.comcast.net) |
| 2025-01-13 16:00:21 +0100 | mchav | (~mchav@c-98-59-172-239.hsd1.wa.comcast.net) (Client Quit) |
| 2025-01-13 16:16:32 +0100 | sixfourtwelve | (~ethanmorg@82.18.82.103) sixfourtwelve |
| 2025-01-13 16:22:03 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-01-13 16:32:36 +0100 | sixfourtwelve | (~ethanmorg@82.18.82.103) () |
| 2025-01-13 16:57:23 +0100 | forell | (~forell@user/forell) (Quit: ZNC - https://znc.in) |
| 2025-01-13 16:57:38 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-13 16:59:44 +0100 | dontdieych2 | (~quassel@user/dontdieych2) (Ping timeout: 272 seconds) |
| 2025-01-13 17:01:22 +0100 | forell | (~forell@user/forell) forell |
| 2025-01-13 17:03:33 +0100 | alecs | (~alecs@nat16.software.imdea.org) (Ping timeout: 276 seconds) |
| 2025-01-13 17:17:57 +0100 | lortabac | (~lortabac@88-125-6-227.subs.proxad.net) (Ping timeout: 248 seconds) |
| 2025-01-13 17:22:38 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 244 seconds) |
| 2025-01-13 17:24:39 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-01-13 17:34:34 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2025-01-13 17:35:09 +0100 | <r-sta> | hi i have <<loop>> im trying to do some profiling but; |
| 2025-01-13 17:35:10 +0100 | <r-sta> | cabal v2-run launch-starship -O2 -fbreak-on-exception |
| 2025-01-13 17:35:22 +0100 | <r-sta> | just gives <<loop>> still |
| 2025-01-13 17:35:38 +0100 | <r-sta> | and does not allow to step through stages like a break would |
| 2025-01-13 17:36:15 +0100 | <r-sta> | it appears infact, not, to break upon exception... |
| 2025-01-13 17:36:21 +0100 | <r-sta> | any idea what the problem is? |
| 2025-01-13 17:38:00 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Client Quit) |
| 2025-01-13 17:41:28 +0100 | <geekosaur> | `-fbreak-on-exception` only works in ghci, I think? but `v2-run` compiles |
| 2025-01-13 17:42:19 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2025-01-13 17:42:26 +0100 | <geekosaur> | yes, ghci only |
| 2025-01-13 17:42:40 +0100 | <r-sta> | ok, i understand this i think |
| 2025-01-13 17:42:58 +0100 | <geekosaur> | there's nothing to beak to in a compiled program |
| 2025-01-13 17:45:27 +0100 | <r-sta> | hmm |
| 2025-01-13 17:45:30 +0100 | <r-sta> | now it gives |
| 2025-01-13 17:45:31 +0100 | <r-sta> | Access violation in generated code when executing data at 0x7ff687e1c1a0 |
| 2025-01-13 17:45:32 +0100 | <r-sta> | Attempting to reconstruct a stack trace... |
| 2025-01-13 17:45:45 +0100 | <r-sta> | so i think its *trying* to break on exception |
| 2025-01-13 17:46:05 +0100 | <r-sta> | thats changing `cabal v2-run' to `cabal v2-repl' |
| 2025-01-13 17:47:12 +0100 | <r-sta> | but if i try to write :break 2 at the ghci prompt, it says; |
| 2025-01-13 17:47:25 +0100 | <r-sta> | No modules are loaded with debugging support. |
| 2025-01-13 17:47:37 +0100 | <r-sta> | i guess im missing a cabal flag |
| 2025-01-13 17:48:51 +0100 | <geekosaur> | if it finds a compiled module it uses it, unless you prefix with an asterisk |
| 2025-01-13 17:49:00 +0100 | <geekosaur> | but the compiled one can't be debugged |
| 2025-01-13 17:49:29 +0100 | <r-sta> | how is there one which is not compiled!? |
| 2025-01-13 17:50:28 +0100 | <geekosaur> | that's the point, you used v2-run which compiled it, now ghci is insisting on using the compiled one |
| 2025-01-13 17:50:41 +0100 | <geekosaur> | you need to force it to load the source files instead |
| 2025-01-13 17:50:50 +0100 | <r-sta> | ok so i just delete dist-newstyle |
| 2025-01-13 17:51:42 +0100 | <r-sta> | im having to deal with like 10 min compilation times, its a pain |
| 2025-01-13 17:52:04 +0100 | <geekosaur> | well, `cabal repl` may just compile everything again. ghci's the one being annoying here with its preference for compiled stuff |
| 2025-01-13 17:52:28 +0100 | <r-sta> | it is doing that |
| 2025-01-13 17:52:30 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f35081469c6fc5c461d.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-01-13 17:52:41 +0100 | <r-sta> | but maybe it will stop short of main.exe |
| 2025-01-13 17:53:08 +0100 | <r-sta> | i mean, repl should do that anyway right? but the run call would have maybe left *something* extra... |
| 2025-01-13 17:53:12 +0100 | <r-sta> | ill see if it works |
| 2025-01-13 17:53:41 +0100 | <r-sta> | its the bigest project ever! |
| 2025-01-13 17:53:47 +0100 | <r-sta> | its got code i wrote like 5 years ago |
| 2025-01-13 17:53:58 +0100 | <r-sta> | 7* |
| 2025-01-13 17:54:23 +0100 | <haskellbridge> | <magic_rb> Ive taking a course on compiler construction, unfortunately in python so im thinking if i can rewrite it haskell. Do we have a package which would allow me to spit out textual llvm IR easily? |
| 2025-01-13 17:54:53 +0100 | <r-sta> | sounds like a parsecy sort of thing maybe? |
| 2025-01-13 17:54:58 +0100 | <geekosaur> | I thought you weren't supposed to do that |
| 2025-01-13 17:55:14 +0100 | <haskellbridge> | <magic_rb> Youre not :) |
| 2025-01-13 17:55:24 +0100 | <geekosaur> | (LLVM doesn't want people using IR directly. never mind that ghc does, they pay the price for it) |
| 2025-01-13 17:55:37 +0100 | <haskellbridge> | <magic_rb> Was just about to say GHC does that |
| 2025-01-13 17:55:50 +0100 | <haskellbridge> | <magic_rb> My other option is fixing llvm-hs |
| 2025-01-13 17:56:28 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2025-01-13 17:56:33 +0100 | <r-sta> | i can find this; |
| 2025-01-13 17:56:34 +0100 | <r-sta> | https://stackoverflow.com/questions/52040651/compile-haskell-programs-to-llvm-ir |
| 2025-01-13 17:57:17 +0100 | <r-sta> | ghc -keep-llvm-files main.hs |
| 2025-01-13 17:57:18 +0100 | <r-sta> | and a file called main.ll is created. |
| 2025-01-13 17:57:24 +0100 | <r-sta> | nothing about llvm IR tho |
| 2025-01-13 17:57:42 +0100 | <haskellbridge> | <magic_rb> No i meant writing my own codegen in haskell for my own shitty little language |
| 2025-01-13 17:58:14 +0100 | <r-sta> | fair |
| 2025-01-13 17:59:31 +0100 | <haskellbridge> | <magic_rb> I can always do a healthy amount of Text concatenations |
| 2025-01-13 18:00:10 +0100 | <r-sta> | https://www.hcesperer.org/posts/2017-07-28-writing-a-small-llvm-compiler-frontend-in-haskell.html |
| 2025-01-13 18:00:31 +0100 | <geekosaur> | that's the IR. you can carry it to another system with no ghc but has LLVM and run opt and llc there |
| 2025-01-13 18:00:47 +0100 | <haskellbridge> | <magic_rb> r-sta Thats llvm-hs i think which is not really functional anymore :( |
| 2025-01-13 18:01:12 +0100 | <haskellbridge> | <magic_rb> Ill end up doing the Text magic probably. Not a big project so its fine |
| 2025-01-13 18:02:15 +0100 | <r-sta> | this seems on point |
| 2025-01-13 18:02:15 +0100 | <r-sta> | https://www.reddit.com/r/haskell/comments/13yhc5l/comment/jmmui4b/?utm_source=share&utm_medium=web… |
| 2025-01-13 18:02:54 +0100 | <r-sta> | you have to expand the comment on a deleted comment! |
| 2025-01-13 18:02:55 +0100 | <haskellbridge> | <magic_rb> Yeah exactly |
| 2025-01-13 18:03:16 +0100 | <haskellbridge> | <magic_rb> I dont use normal reddit so i dont :) but yes |
| 2025-01-13 18:03:25 +0100 | <r-sta> | it mentions "the need to update LLVM-hs" |
| 2025-01-13 18:03:31 +0100 | <haskellbridge> | <magic_rb> Okay i was wondering if im missing a lib we have, but looks like im not |
| 2025-01-13 18:03:35 +0100 | <r-sta> | this seems like project creep |
| 2025-01-13 18:03:44 +0100 | <haskellbridge> | <magic_rb> So ill just spit out LLVM IR directly |
| 2025-01-13 18:04:06 +0100 | <r-sta> | i guess the option to do so might be reason to suspect the support for an alternative might not exist |
| 2025-01-13 18:04:44 +0100 | <haskellbridge> | <magic_rb> Nah its mainly the fact that LLVMs api is extremely unstable and just bad in general |
| 2025-01-13 18:04:47 +0100 | <r-sta> | still, seems like it would have the kind of semantics that a lib would support, im guessing thats what llvm-hs is, ill check |
| 2025-01-13 18:04:50 +0100 | <haskellbridge> | <magic_rb> And extremely poorly documented |
| 2025-01-13 18:05:29 +0100 | <r-sta> | yeah jesus christ thats horrendous |
| 2025-01-13 18:05:43 +0100 | <r-sta> | if it works at all, you would expect a better interface from an intermediate module |
| 2025-01-13 18:06:01 +0100 | <r-sta> | there must be some plugins to some grammer library |
| 2025-01-13 18:06:53 +0100 | <r-sta> | btw, google search says; |
| 2025-01-13 18:06:54 +0100 | <r-sta> | llvm-hs is a set of Haskell bindings for LLVM http://llvm.org/. Unlike other current Haskell bindings, it uses an ADT to represent LLVM IR. |
| 2025-01-13 18:07:05 +0100 | <r-sta> | so its in there... |
| 2025-01-13 18:07:17 +0100 | <r-sta> | so its not going to be anywhere else! |
| 2025-01-13 18:07:29 +0100 | <r-sta> | you want a better access point |
| 2025-01-13 18:08:44 +0100 | <r-sta> | dont know if you seen this too https://hackage.haskell.org/package/llvm-hs-pure |
| 2025-01-13 18:09:10 +0100 | <r-sta> | that might be much easier to work with if you need the AST without the FFI |
| 2025-01-13 18:10:14 +0100 | <r-sta> | https://stackoverflow.com/questions/27696261/good-type-design-in-haskell-for-the-ast-of-a-simple-l… |
| 2025-01-13 18:10:31 +0100 | <r-sta> | Stephen Diehl looks like your man |
| 2025-01-13 18:11:40 +0100 | <r-sta> | here |
| 2025-01-13 18:11:41 +0100 | <r-sta> | https://github.com/sdiehl/kaleidoscope/tree/master |
| 2025-01-13 18:12:48 +0100 | <r-sta> | described as "A minimal LLVM builder" |
| 2025-01-13 18:12:55 +0100 | <r-sta> | https://github.com/llvm-hs/llvm-hs-kaleidoscope |
| 2025-01-13 18:13:06 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 276 seconds) |
| 2025-01-13 18:13:40 +0100 | <r-sta> | {btw whats happening here is a combo of utfse and why is your search engine better than mine} |
| 2025-01-13 18:14:05 +0100 | ft | (~ft@p4fc2a354.dip0.t-ipconnect.de) ft |
| 2025-01-13 18:14:50 +0100 | <r-sta> | one of the most complicated pieces of code iv ever seen! |
| 2025-01-13 18:16:20 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-01-13 18:16:22 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-01-13 18:17:10 +0100 | <haskellbridge> | <magic_rb> Okay ill keep llvm-hs-pure in mind |
| 2025-01-13 18:17:11 +0100 | <haskellbridge> | <magic_rb> Looks good |
| 2025-01-13 18:17:21 +0100 | <haskellbridge> | <magic_rb> Ill add this to my ever growing list of side projects |
| 2025-01-13 18:17:50 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-13 18:17:51 +0100 | <r-sta> | yeah, idk if your going to be able to get the output you were looking for in a super easy way |
| 2025-01-13 18:21:15 +0100 | <r-sta> | btw geekosaur: the use of repl vs run does indeed not result in a pesky compiled version |
| 2025-01-13 18:21:27 +0100 | <r-sta> | i can insert breaks |
| 2025-01-13 18:22:03 +0100 | <r-sta> | but it just stops! |
| 2025-01-13 18:22:18 +0100 | <r-sta> | not forwards or backwards stepping to examine variables (i have never done this) |
| 2025-01-13 18:23:15 +0100 | <geekosaur> | https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#the-ghci-debugger might be helpful |
| 2025-01-13 18:23:44 +0100 | <r-sta> | based on what iv read i should be able to break and then step through line by line basically |
| 2025-01-13 18:24:53 +0100 | <r-sta> | hmm, :list might be able to help me find ther <<loop>> without needing to step |
| 2025-01-13 18:26:30 +0100 | <r-sta> | ghci> :set -fbreak-on-exception |
| 2025-01-13 18:26:30 +0100 | <r-sta> | ghci> main |
| 2025-01-13 18:26:31 +0100 | <r-sta> | "trades loaded; Stopped in <exception thrown>, <unknown> |
| 2025-01-13 18:26:32 +0100 | <r-sta> | _exception :: e = _ |
| 2025-01-13 18:26:32 +0100 | <r-sta> | [<unknown>] ghci> :list |
| 2025-01-13 18:26:33 +0100 | <r-sta> | Unable to list source for <unknown> |
| 2025-01-13 18:26:33 +0100 | <r-sta> | Try rerunning with :trace, :back then :list |
| 2025-01-13 18:26:33 +0100 | <geekosaur> | I should mention that <<loop>> is a special exception that doesn't behave like normal ones; it's kinda manufactured by STG |
| 2025-01-13 18:26:47 +0100 | <r-sta> | yeah it even has this special error |
| 2025-01-13 18:26:55 +0100 | <geekosaur> | it means you have something that evaluates itself |
| 2025-01-13 18:27:06 +0100 | <r-sta> | it says, here, your ussposed to use :trace for a start, and then, this error it doesnt like so youl have to go backl |
| 2025-01-13 18:27:17 +0100 | <geekosaur> | keep in mind that `let x = x + 1` doesn't do what you think from other languages |
| 2025-01-13 18:27:42 +0100 | <r-sta> | thats ok i never used another language! |
| 2025-01-13 18:28:42 +0100 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-13 18:29:14 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-01-13 18:29:33 +0100 | <r-sta> | hmm, ok the back thing works, but it takes it to part of the code where there is no loop! |
| 2025-01-13 18:30:50 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 244 seconds) |
| 2025-01-13 18:32:45 +0100 | <r-sta> | how can i tell where the loop is!? |
| 2025-01-13 18:35:18 +0100 | <r-sta> | at least initially because its in IO the main routine is sequential so you can do printouts after each line, but then it would be bredth first search through everything pure with trace debug which is way harder to keep track of |
| 2025-01-13 18:41:57 +0100 | <r-sta> | man, that is the most nondeterministic thing ever |
| 2025-01-13 18:42:11 +0100 | <r-sta> | so, just then my computer run out of memory, and the exception is not the loop!" |
| 2025-01-13 18:42:28 +0100 | <r-sta> | so it was breaking at some memory hanging exception somewhere away from the loop |
| 2025-01-13 18:42:33 +0100 | <r-sta> | damn real world! |
| 2025-01-13 18:46:02 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-01-13 18:47:57 +0100 | <r-sta> | rrg, now without breakpoints, ie without setting -fbreak-on-exception, it works, ie it gets through this "unknown" error |
| 2025-01-13 18:48:14 +0100 | <r-sta> | so it doesnt even crash at the same place with the breakpoints on!! |
| 2025-01-13 18:48:27 +0100 | <r-sta> | this SUCKS |
| 2025-01-13 18:48:33 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-13 18:48:34 +0100 | <r-sta> | ill never find this <<loop>> |
| 2025-01-13 18:48:44 +0100 | <r-sta> | this piece of code is huge! iv no idea what changed |
| 2025-01-13 18:50:48 +0100 | <EvanR> | run the test suite |
| 2025-01-13 18:50:53 +0100 | <EvanR> | that you have |
| 2025-01-13 18:51:30 +0100 | <EvanR> | I am grateful that <<loop>> exists, it could be much worse |
| 2025-01-13 18:56:12 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-01-13 18:59:20 +0100 | gehmehgeh | (~user@user/gehmehgeh) gehmehgeh |
| 2025-01-13 19:01:59 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-13 19:04:23 +0100 | <r-sta> | testsuite!? |
| 2025-01-13 19:04:25 +0100 | sprotte24 | (~sprotte24@p200300d16f245c002d65884199a66258.dip0.t-ipconnect.de) |
| 2025-01-13 19:04:44 +0100 | gehmehgeh | gmg |
| 2025-01-13 19:04:52 +0100 | <r-sta> | (and obviously even after deleting plenty, it still throws a non-deterministic error when trying to load in the data) |
| 2025-01-13 19:05:30 +0100 | <r-sta> | EvanR: any details on this test suite, idk what it is, but if it could be a path to finding the <<loop>> id be overjoyed |
| 2025-01-13 19:05:30 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-13 19:06:17 +0100 | <r-sta> | problem atm is its throwing some other unknown error for some unknown reason before it even hits the loop, simply by virtue of enabling -fbreak-on-exception, which i think is lame |
| 2025-01-13 19:06:26 +0100 | <EvanR> | it's where you have a set of tests which sanity check subsections of the code |
| 2025-01-13 19:06:39 +0100 | <EvanR> | that you can run |
| 2025-01-13 19:06:50 +0100 | <r-sta> | oh |
| 2025-01-13 19:07:03 +0100 | <r-sta> | no i mean, i didnt break most of it |
| 2025-01-13 19:07:16 +0100 | <r-sta> | so the last propper run checks almost all the components |
| 2025-01-13 19:07:23 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:07:55 +0100 | <r-sta> | still idk why it breaks now or what i changed, or why the thing that finds the bugs introduces new bugs or anything |
| 2025-01-13 19:08:28 +0100 | <EvanR> | to find out what you changed, look at the version control system |
| 2025-01-13 19:08:31 +0100 | <EvanR> | that you have |
| 2025-01-13 19:08:35 +0100 | <r-sta> | !!!! |
| 2025-01-13 19:08:48 +0100 | <r-sta> | the code version of free climbing el chapo |
| 2025-01-13 19:09:27 +0100 | <r-sta> | i just need to find this loop! |
| 2025-01-13 19:09:33 +0100 | <r-sta> | i want to step through line by line |
| 2025-01-13 19:13:09 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-01-13 19:13:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-13 19:14:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-13 19:19:38 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-01-13 19:20:19 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-13 19:23:38 +0100 | <r-sta> | now if i dont do any profiling, it even still gives a new different error! |
| 2025-01-13 19:23:49 +0100 | <r-sta> | Access violation in generated code when executing data at 0x7ff687e1a1a0 |
| 2025-01-13 19:23:50 +0100 | <r-sta> | Attempting to reconstruct a stack trace... |
| 2025-01-13 19:23:51 +0100 | <r-sta> | Frame Code address |
| 2025-01-13 19:23:51 +0100 | <r-sta> | * 0x8ec1afd9f0 0x7ff687e1a1a0 |
| 2025-01-13 19:24:03 +0100 | <r-sta> | it wasnt doing that before. im going back to cabal v2-run |
| 2025-01-13 19:24:10 +0100 | <r-sta> | the repl seems to be messing something up |
| 2025-01-13 19:24:13 +0100 | <r-sta> | it mentions hmatrix |
| 2025-01-13 19:24:24 +0100 | <r-sta> | there are some blas i hope it doesnt mess up in the ghci prompt |
| 2025-01-13 19:24:31 +0100 | housemate | (~housemate@146.70.66.228) (Ping timeout: 252 seconds) |
| 2025-01-13 19:24:34 +0100 | <r-sta> | i ant deal with nodeterministic errors! |
| 2025-01-13 19:24:37 +0100 | <r-sta> | can* |
| 2025-01-13 19:24:39 +0100 | <r-sta> | cant*! |
| 2025-01-13 19:25:33 +0100 | <r-sta> | ok, at least now it hits the <<loop>> and loads in all the data |
| 2025-01-13 19:27:54 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:29:39 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-01-13 19:30:20 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:30:45 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-13 19:31:19 +0100 | <r-sta> | i think i want it to loop! |
| 2025-01-13 19:31:31 +0100 | <r-sta> | is there any way i can have it not crash when it loops |
| 2025-01-13 19:31:37 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:31:50 +0100 | <r-sta> | im halting prints everywhere and it breaks actually *as* it loops |
| 2025-01-13 19:32:02 +0100 | <r-sta> | its just given a normal recursive call to itself |
| 2025-01-13 19:32:19 +0100 | <tomsmeding> | '<<loop>>' means something is defined in terms of itself directly, without any useful work in between |
| 2025-01-13 19:32:23 +0100 | <tomsmeding> | it's not the loop you're looking for |
| 2025-01-13 19:32:34 +0100 | nickiminjaj | (~nickiminj@user/laxhh) laxhh |
| 2025-01-13 19:33:38 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-01-13 19:34:17 +0100 | <r-sta> | hmmmm |
| 2025-01-13 19:34:19 +0100 | <r-sta> | yeah |
| 2025-01-13 19:34:24 +0100 | nickiminjaj | (~nickiminj@user/laxhh) (Client Quit) |
| 2025-01-13 19:34:49 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:35:29 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:36:55 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-01-13 19:37:38 +0100 | <tomsmeding> | r-sta: you could try compiling with `cabal --enable-profiling`, and then running with `+RTS -xc` at the end of your command line |
| 2025-01-13 19:37:50 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-01-13 19:37:53 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2025-01-13 19:37:53 +0100 | <tomsmeding> | that might print useful backtrace information |
| 2025-01-13 19:37:55 +0100 | <tomsmeding> | it might also not :) |
| 2025-01-13 19:37:59 +0100 | <tomsmeding> | but it's worth a try |
| 2025-01-13 19:38:00 +0100 | <r-sta> | ok ill try |
| 2025-01-13 19:38:19 +0100 | <r-sta> | as in cabal v2-build ? |
| 2025-01-13 19:38:27 +0100 | <tomsmeding> | yes |
| 2025-01-13 19:38:31 +0100 | <tomsmeding> | (the v2- is redundant) |
| 2025-01-13 19:38:37 +0100 | <tomsmeding> | (if you have a non-ancient cabal) |
| 2025-01-13 19:38:40 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:39:07 +0100 | <r-sta> | ok |
| 2025-01-13 19:39:12 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-01-13 19:39:17 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:39:17 +0100 | <r-sta> | so build with --enable-profiling |
| 2025-01-13 19:39:27 +0100 | <r-sta> | and then run with +RTS -xc |
| 2025-01-13 19:39:30 +0100 | <tomsmeding> | yes |
| 2025-01-13 19:39:30 +0100 | <r-sta> | what does this do? |
| 2025-01-13 19:39:34 +0100 | avidseeker | (av@user/avidseeker) avidseeker |
| 2025-01-13 19:39:59 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-01-13 19:40:13 +0100 | <tomsmeding> | the first 1. builds with the profiling RTS (runtime system), which allows stuff like -xc, and 2. instruments all (?) functions with a little wrapper that tells the RTS that this function is now being entered/left |
| 2025-01-13 19:40:25 +0100 | <tomsmeding> | the second tells the RTS to print a backtrace on every thrown exception |
| 2025-01-13 19:40:35 +0100 | <tomsmeding> | _every_ thrown exception, even if it's caught by something else, unfortunately |
| 2025-01-13 19:40:45 +0100 | <tomsmeding> | so you may well get false-positives |
| 2025-01-13 19:41:29 +0100 | <tomsmeding> | r-sta: typically, <<loop>> is caused by stupid typos like `let x = foo x` where it should have been `let x' = foo x` |
| 2025-01-13 19:41:31 +0100 | <r-sta> | ok, its a lengthy recompile but ill let you know how i get on |
| 2025-01-13 19:41:56 +0100 | <tomsmeding> | sometimes it's more complicated, but it's usually a typo |
| 2025-01-13 19:42:19 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:42:33 +0100 | <r-sta> | yeah ill celebrate when i find it |
| 2025-01-13 19:42:39 +0100 | <tomsmeding> | typically on new GHCs these days you shouldn't need -xc any more to get backtrace info on uncaught exceptions, but apparently the <<loop>> isn't quite a normal exception |
| 2025-01-13 19:43:07 +0100 | <r-sta> | it would be great to give the variable name at the loop exception |
| 2025-01-13 19:43:14 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2025-01-13 19:43:15 +0100 | <r-sta> | even the module! |
| 2025-01-13 19:43:26 +0100 | <tomsmeding> | well it need not be a single module, right |
| 2025-01-13 19:43:31 +0100 | <tomsmeding> | it could be a few calls deep across modules |
| 2025-01-13 19:43:35 +0100 | <tomsmeding> | I'm with you though |
| 2025-01-13 19:43:39 +0100 | <r-sta> | yeah |
| 2025-01-13 19:43:50 +0100 | <r-sta> | i mean, if the trace thing works with :list |
| 2025-01-13 19:43:54 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:43:55 +0100 | euleritian | (~euleritia@dynamic-176-006-133-150.176.6.pool.telefonica.de) |
| 2025-01-13 19:43:55 +0100 | nickiminjaj | (~nickiminj@188.146.46.126) |
| 2025-01-13 19:43:55 +0100 | nickiminjaj | (~nickiminj@188.146.46.126) (Changing host) |
| 2025-01-13 19:43:55 +0100 | nickiminjaj | (~nickiminj@user/laxhh) laxhh |
| 2025-01-13 19:44:09 +0100 | <r-sta> | but its being anoying and not even making it to the loop in -fbreak-on-exception mode |
| 2025-01-13 19:47:05 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:47:24 +0100 | nickiminjaj | ol0ck |
| 2025-01-13 19:48:22 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:48:38 +0100 | <r-sta> | yeah, that didnt work |
| 2025-01-13 19:48:43 +0100 | <r-sta> | it says it needs -prof |
| 2025-01-13 19:49:02 +0100 | <tomsmeding> | are you using `cabal run`? |
| 2025-01-13 19:49:08 +0100 | <tomsmeding> | then you need the `--enable-profiling` with `cabal run` too |
| 2025-01-13 19:49:16 +0100 | <tomsmeding> | like `cabal run --enable-profiling your-app -- +RTS -xc` |
| 2025-01-13 19:49:30 +0100 | <tomsmeding> | `cabal run` is essentially `cabal build` + `cabal exec` |
| 2025-01-13 19:51:18 +0100 | ol0ck_ | (~quassel@user/ol0ck) ol0ck |
| 2025-01-13 19:51:42 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:52:02 +0100 | <r-sta> | the flag -xc requires the program to be built with -prof |
| 2025-01-13 19:52:07 +0100 | ol0ck | (~nickiminj@user/laxhh) (Quit: Textual IRC Client: www.textualapp.com) |
| 2025-01-13 19:52:15 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2025-01-13 19:52:17 +0100 | ol0ck_ | ol0ck |
| 2025-01-13 19:52:22 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:52:27 +0100 | <tomsmeding> | your app will be built with -prof if you --enable-profiling to `cabal run` |
| 2025-01-13 19:52:29 +0100 | <tomsmeding> | how are you running your app? |
| 2025-01-13 19:52:53 +0100 | <r-sta> | im doing cabal v2-build then cabal v2-run |
| 2025-01-13 19:53:00 +0100 | <r-sta> | i guess i should uses v2-exec... |
| 2025-01-13 19:53:00 +0100 | <tomsmeding> | why v2- before everything? |
| 2025-01-13 19:53:06 +0100 | <r-sta> | force of habbit |
| 2025-01-13 19:53:17 +0100 | <tomsmeding> | you could do that, or `cabal --enable-profiling run your-executable-name -- +RTS -xc` |
| 2025-01-13 19:53:31 +0100 | <tomsmeding> | perhaps the 'run' needs to come before the '--enable-profiling' |
| 2025-01-13 19:54:13 +0100 | OftenFaded37 | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-13 19:54:46 +0100 | <r-sta> | idk it seems to be producing gibberish now so it must be working |
| 2025-01-13 19:55:16 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 19:56:22 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 19:56:37 +0100 | <r-sta> | it points to some locations but i cant see anything, i think iv become frustrated, time to take a break |
| 2025-01-13 19:56:38 +0100 | nickiminjaj | (~nickiminj@user/laxhh) laxhh |
| 2025-01-13 19:57:39 +0100 | nickiminjaj | (~nickiminj@user/laxhh) (Client Quit) |
| 2025-01-13 19:58:01 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2025-01-13 19:58:09 +0100 | ol0ck | (~quassel@user/ol0ck) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2025-01-13 19:58:19 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-01-13 19:59:11 +0100 | ol0ck | (~quassel@user/ol0ck) ol0ck |
| 2025-01-13 19:59:35 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:00:53 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:02:14 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-01-13 20:03:48 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:05:22 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:06:27 +0100 | Guest1364 | (~user@2601:644:937c:ed10::ae5) |
| 2025-01-13 20:08:38 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:09:11 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:10:20 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 20:10:59 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:11:46 +0100 | OftenFaded37 | OftenFaded1 |
| 2025-01-13 20:11:51 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 20:12:25 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:12:42 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 276 seconds) |
| 2025-01-13 20:14:35 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:15:06 +0100 | Guest21 | (~Guest21@net-2-44-139-71.cust.vodafonedsl.it) |
| 2025-01-13 20:16:01 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Quit: Client closed) |
| 2025-01-13 20:16:19 +0100 | Guest21 | (~Guest21@net-2-44-139-71.cust.vodafonedsl.it) (Client Quit) |
| 2025-01-13 20:16:38 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:18:57 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:20:24 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:21:21 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 20:21:58 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:24:18 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-01-13 20:24:19 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:25:06 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:27:15 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:28:21 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:28:36 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-01-13 20:30:35 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:31:13 +0100 | yahb2 | (~yahb2@user/tomsmeding/bot/yahb2) (Remote host closed the connection) |
| 2025-01-13 20:31:38 +0100 | yahb2 | (~yahb2@user/tomsmeding/bot/yahb2) yahb2 |
| 2025-01-13 20:31:38 +0100 | ChanServ | +v yahb2 |
| 2025-01-13 20:31:50 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:34:00 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:34:25 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:77c0:5b4e:4973:375e) |
| 2025-01-13 20:34:38 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:34:56 +0100 | jespada | (~jespada@2800:a4:1fd:ad00:50c2:f579:e377:bf59) (Ping timeout: 264 seconds) |
| 2025-01-13 20:36:42 +0100 | ircbrowse_tom | (~ircbrowse@user/tomsmeding/bot/ircbrowse-tom) ircbrowse_tom |
| 2025-01-13 20:36:44 +0100 | Server | +Cnt |
| 2025-01-13 20:36:53 +0100 | jespada | (~jespada@2800:a4:17:fd00:48e9:a913:6d6f:7a29) jespada |
| 2025-01-13 20:38:12 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:39:23 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:39:48 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:41:22 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-01-13 20:42:11 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:42:20 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) szkl |
| 2025-01-13 20:43:01 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f35081469c6fc5c461d.dip0.t-ipconnect.de) |
| 2025-01-13 20:44:10 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:44:50 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 20:45:47 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:47:31 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:48:07 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:50:33 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:50:53 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-01-13 20:51:26 +0100 | Guest21 | (~Guest21@net-2-44-139-71.cust.vodafonedsl.it) |
| 2025-01-13 20:52:08 +0100 | Guest21 | (~Guest21@net-2-44-139-71.cust.vodafonedsl.it) (Client Quit) |
| 2025-01-13 20:52:08 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:52:51 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-13 20:54:00 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:54:37 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:56:55 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 20:56:57 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 20:57:24 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 20:59:28 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:00:15 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-13 21:00:41 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-13 21:00:56 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:01:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-13 21:01:50 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 21:02:04 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) (Ping timeout: 252 seconds) |
| 2025-01-13 21:02:25 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:03:20 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 21:03:51 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:05:55 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:06:53 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:07:56 +0100 | kuribas | (~user@ptr-17d51epu50i07rg06yn.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2025-01-13 21:08:12 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) |
| 2025-01-13 21:09:09 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:09:49 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:11:57 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:12:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 21:12:54 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:12:55 +0100 | <bailsman> | So basically if one function returns a list and that is immediately consumed by another function that just loops over that list, GHC in all likelihood won't actually create the list? This is true even if both functions are in separate modules? |
| 2025-01-13 21:14:28 +0100 | <tomsmeding> | it will create the list nodes, but only on-demand |
| 2025-01-13 21:14:45 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:14:57 +0100 | <tomsmeding> | so if the consumer is a simple loop over the list, and doesn't consume the list twice, then you _will_ allocate all the list nodes, but only individually, not all at the same time |
| 2025-01-13 21:16:02 +0100 | <tomsmeding> | you will have a high GB/s allocation rate, but a very low peak: they will be deallocated again at roughly the same rate |
| 2025-01-13 21:16:02 +0100 | <tomsmeding> | (technically: they will be deallocated in bulk at every GC) |
| 2025-01-13 21:16:02 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:16:17 +0100 | <bailsman> | yeah it's generational gc so that should be super cheap, right? but I was sort of hoping it would just inline it somehow and directly loop over the source |
| 2025-01-13 21:16:26 +0100 | <tomsmeding> | yep |
| 2025-01-13 21:16:37 +0100 | <tomsmeding> | the second thing you're talking about is _fusion_ |
| 2025-01-13 21:16:59 +0100 | <tomsmeding> | GHC sometimes does this -- or rather, 'base' provides rewrite rules on some list functions that tell GHC to merge certain calls |
| 2025-01-13 21:17:07 +0100 | <tomsmeding> | this is foldr/build fusion |
| 2025-01-13 21:17:52 +0100 | <r-sta> | the most awesome thing ever |
| 2025-01-13 21:18:00 +0100 | <tomsmeding> | things like 'map' are rewritten at compile time to an invocation of 'build' (an internal function in base); foldr has a rewrite rule to fuse with 'build' and actually eliminate the list nodes |
| 2025-01-13 21:18:01 +0100 | <r-sta> | its like a rewrite |
| 2025-01-13 21:18:06 +0100 | <tomsmeding> | it _is_ a rewrite |
| 2025-01-13 21:18:15 +0100 | <r-sta> | yeah, super cheap to evaluate! |
| 2025-01-13 21:18:18 +0100 | <r-sta> | at compile time!! |
| 2025-01-13 21:18:19 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:18:21 +0100 | <tomsmeding> | if a 'build' remains after this fusion pass, then it's rewritten back to a normal call |
| 2025-01-13 21:18:36 +0100 | <tomsmeding> | but note that this fusion can only happen if GHC sees the calls right next to each other, possibly after inlining |
| 2025-01-13 21:19:01 +0100 | <tomsmeding> | now, GHC is quite keen on inlining stuff, so that may well come to be -- but it's not guaranteed |
| 2025-01-13 21:19:02 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2025-01-13 21:19:27 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:20:12 +0100 | <tomsmeding> | the RULES for 'map' are here https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Internal.Base.html#line-1935 |
| 2025-01-13 21:20:48 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 21:20:48 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-13 21:20:58 +0100 | <tomsmeding> | and the foldr + build = no list rule is here https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Internal.Base.html#line-1828 |
| 2025-01-13 21:20:59 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:21:09 +0100 | <tomsmeding> | bailsman: ^ |
| 2025-01-13 21:21:18 +0100 | <haskellbridge> | <Bowuigi> Yeah if you do an operation that consumes and builds a list and you don't want to do it using map and friends, using foldr and build gives you fusion if you inline that definition |
| 2025-01-13 21:21:25 +0100 | <r-sta> | many years after studying this i now only work with state encodings! |
| 2025-01-13 21:21:30 +0100 | <r-sta> | :t mapAccumL |
| 2025-01-13 21:21:31 +0100 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2025-01-13 21:21:43 +0100 | <bailsman> | interesting |
| 2025-01-13 21:21:45 +0100 | <r-sta> | there is an algebra on the state function here |
| 2025-01-13 21:21:47 +0100 | <tomsmeding> | Bowuigi: map is rewritten to build ;) |
| 2025-01-13 21:21:49 +0100 | <tomsmeding> | so map works fine |
| 2025-01-13 21:21:50 +0100 | housemate | (~housemate@146.70.66.228) (Remote host closed the connection) |
| 2025-01-13 21:21:56 +0100 | <tomsmeding> | if you manually recurse over the list, then that's _not_ fused |
| 2025-01-13 21:22:15 +0100 | <haskellbridge> | <Bowuigi> Yeah that's why I am making the exception |
| 2025-01-13 21:22:15 +0100 | <r-sta> | a scanner is the name i was using to refer to the mapAccumL process |
| 2025-01-13 21:22:22 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2025-01-13 21:22:22 +0100 | <r-sta> | the states "scan" over streams |
| 2025-01-13 21:22:30 +0100 | <haskellbridge> | <Bowuigi> foldr/build is like switching to Church encoding for a bit in order to get fusion |
| 2025-01-13 21:22:32 +0100 | <tomsmeding> | mapAccumL is a little generalisation over scanl |
| 2025-01-13 21:22:42 +0100 | <r-sta> | the fact you can again scan the output, is the origin of the composition algebra |
| 2025-01-13 21:22:46 +0100 | Everything | (~Everythin@195.138.86.118) Everything |
| 2025-01-13 21:22:48 +0100 | <r-sta> | scanners compose sequentially |
| 2025-01-13 21:22:53 +0100 | <tomsmeding> | Bowuigi: you said "you don't want to do it using map and friends" -- that's what I was referring to |
| 2025-01-13 21:22:55 +0100 | <r-sta> | you can make composite states |
| 2025-01-13 21:23:13 +0100 | <r-sta> | now, the cool thing here is that these do not need to be in sequential composition |
| 2025-01-13 21:23:59 +0100 | <r-sta> | when you bind the results of the state functions in a where clause, as long as they are non cycle inducing... |
| 2025-01-13 21:23:59 +0100 | <haskellbridge> | <Bowuigi> tomsmeding Oh, I meant that if you don't want to use them, you should use foldr and build for the fusion |
| 2025-01-13 21:23:59 +0100 | <tomsmeding> | ah right |
| 2025-01-13 21:23:59 +0100 | <r-sta> | its like the top level graphical language allows that the states can be composed together using the actual scope, which is ace |
| 2025-01-13 21:24:26 +0100 | housemate | (~housemate@146.70.66.228) (Max SendQ exceeded) |
| 2025-01-13 21:24:37 +0100 | <r-sta> | your build fold fusion rules are basically saying that you can almost sort of not remake the list |
| 2025-01-13 21:24:54 +0100 | <r-sta> | this is basically then one big sequence of scanners composed together to run along with the thing that unfolds the list |
| 2025-01-13 21:25:21 +0100 | <r-sta> | the build and fold are endpoints with scans inbetween |
| 2025-01-13 21:25:37 +0100 | <haskellbridge> | <Bowuigi> Also note that the foldr/build trick works for anything that allows a Church encoding. On an eager language, a Mendler-style variant would be more efficient while having the same benefits |
| 2025-01-13 21:25:41 +0100 | <r-sta> | rather than folding strait after unfolding and fusioning away the process |
| 2025-01-13 21:25:54 +0100 | <r-sta> | you can insert a sequence, or scope resolved collection of scanners inbetween |
| 2025-01-13 21:26:10 +0100 | <r-sta> | and in state representation, all the kind of fusion happens automatically anyway |
| 2025-01-13 21:27:11 +0100 | <r-sta> | your using some kind of algebra on the folding, unfolding, and scanning functions |
| 2025-01-13 21:27:12 +0100 | <r-sta> | all of which are stateful processes |
| 2025-01-13 21:27:18 +0100 | <r-sta> | it also indicates that last . scanner, is slightly different to fold |
| 2025-01-13 21:27:30 +0100 | <r-sta> | getting the output rather than the carry |
| 2025-01-13 21:27:46 +0100 | <r-sta> | slightly more expressive as it allows to map from the type of the carry |
| 2025-01-13 21:27:57 +0100 | <haskellbridge> | <Bowuigi> Also I wonder why unfoldr/unbuild (the dual trick) using skipping streams isn't the standard on base. GHC can optimize that properly as well and it reaches more function than the standard foldr/build |
| 2025-01-13 21:29:07 +0100 | <haskellbridge> | <Bowuigi> Can reach more functions* |
| 2025-01-13 21:29:37 +0100 | <r-sta> | skipping? |
| 2025-01-13 21:30:19 +0100 | <r-sta> | i was interested in the zip case as it adds more algebras! |
| 2025-01-13 21:30:37 +0100 | <r-sta> | the fusion rules for some zips based on seti + geti |
| 2025-01-13 21:30:39 +0100 | <r-sta> | whew |
| 2025-01-13 21:30:48 +0100 | <r-sta> | they never did make a superclass to traverse |
| 2025-01-13 21:31:57 +0100 | <r-sta> | seti :: SuperTraverse f i => i -> a -> f a -> f a, geti :: SuperTraverse f i => f a -> (i,a) |
| 2025-01-13 21:32:01 +0100 | <haskellbridge> | <Bowuigi> The skipping stream used for unfoldr/unbuild is a representation of unfoldr that can "skip" the processing of some elements, like when filter discards elements of the input list |
| 2025-01-13 21:32:33 +0100 | <r-sta> | hmm, sounds like a zygomorphism or something crazy |
| 2025-01-13 21:33:01 +0100 | <r-sta> | something to do with partial processing in pre or post positions |
| 2025-01-13 21:33:19 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-13 21:33:42 +0100 | <r-sta> | its weird if its non length preserving |
| 2025-01-13 21:34:02 +0100 | <r-sta> | its also weird if during a traversal not all elements are affected |
| 2025-01-13 21:34:08 +0100 | <r-sta> | basically visitation being non total |
| 2025-01-13 21:34:22 +0100 | <r-sta> | you cant use fmap like to change the element types, cos not all of them are visited |
| 2025-01-13 21:34:24 +0100 | <haskellbridge> | <Bowuigi> The whole system is a hylomorphism that can skip elements |
| 2025-01-13 21:34:33 +0100 | <r-sta> | so you get a monomorphic type constriction |
| 2025-01-13 21:35:00 +0100 | michalz | (~michalz@185.246.207.217) (Remote host closed the connection) |
| 2025-01-13 21:35:00 +0100 | <r-sta> | like, if you dont discard |
| 2025-01-13 21:35:03 +0100 | Midjak | (~MarciZ@82.66.147.146) Midjak |
| 2025-01-13 21:35:06 +0100 | <r-sta> | means you cant change the type of only some of them |
| 2025-01-13 21:35:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 21:35:26 +0100 | <r-sta> | so your partial traversal opperations dont quite look the same because there is less type changes |
| 2025-01-13 21:35:48 +0100 | <r-sta> | partial traversals basically being cursors |
| 2025-01-13 21:36:04 +0100 | <haskellbridge> | <Bowuigi> No no I don't mean "skip" as "not modify", I mean "not appear in the result" |
| 2025-01-13 21:36:04 +0100 | <r-sta> | almost the opposite of the fusion process, which tries to make the intermediate list not exist |
| 2025-01-13 21:36:40 +0100 | <r-sta> | where you can actually halt the progression |
| 2025-01-13 21:36:48 +0100 | <r-sta> | yeah, sure if you delete the elements then you can just basically use total opperations everwhere else that have the type changes in |
| 2025-01-13 21:37:01 +0100 | <r-sta> | like, fmaps would be around the place still, with some filters or something |
| 2025-01-13 21:37:06 +0100 | <r-sta> | but there is a paradigm in the middle |
| 2025-01-13 21:37:30 +0100 | euleritian | (~euleritia@dynamic-176-006-133-150.176.6.pool.telefonica.de) (Remote host closed the connection) |
| 2025-01-13 21:37:41 +0100 | <r-sta> | fmapOn :: (a -> Bool) -> (a -> b) -> f a -> f (Either a b) |
| 2025-01-13 21:38:08 +0100 | euleritian | (~euleritia@dynamic-176-006-133-150.176.6.pool.telefonica.de) |
| 2025-01-13 21:38:24 +0100 | <r-sta> | and then you have your fold fold up all the b's or something |
| 2025-01-13 21:38:43 +0100 | <r-sta> | you have an unfold, a map (like a scanner without a carry), and the consequent fold |
| 2025-01-13 21:38:54 +0100 | <r-sta> | the skipping is acieved at the fold though, not a folter! |
| 2025-01-13 21:38:56 +0100 | <r-sta> | filter* |
| 2025-01-13 21:39:12 +0100 | <r-sta> | idk about the effeciency fusion concerns |
| 2025-01-13 21:40:04 +0100 | <r-sta> | the advantage here is by allowing the types to be partially transformed, ie, only some elements altered |
| 2025-01-13 21:40:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-13 21:40:13 +0100 | <r-sta> | that then you get to continue this process |
| 2025-01-13 21:40:26 +0100 | <r-sta> | like, you could go halfway through a list showing the elements |
| 2025-01-13 21:40:37 +0100 | <r-sta> | pause, do something else, and then complete the rest |
| 2025-01-13 21:41:03 +0100 | <r-sta> | and the "fusion" in this paradigm is kind of spurious in a way if the state space formalism is just addopted wholesale |
| 2025-01-13 21:41:29 +0100 | <r-sta> | but yeah, it kind of looks like a hack to keep the number of elements the same |
| 2025-01-13 21:41:40 +0100 | <r-sta> | even though this is kind of the whole restrictiveness of complete traversals |
| 2025-01-13 21:42:08 +0100 | <r-sta> | like idk, theoretically if maybe like, the list being infinite and partially processed is a good visualisation |
| 2025-01-13 21:42:23 +0100 | <r-sta> | if your going to end up with something finite |
| 2025-01-13 21:42:38 +0100 | <r-sta> | ie that lazyness intrinsically forces us into an incomplete traversal situation |
| 2025-01-13 21:43:00 +0100 | <r-sta> | and the scanner algebra as associated via build fold fusion to lazy consumption is kinda cool |
| 2025-01-13 21:43:20 +0100 | <r-sta> | the incomplete traversal part rather |
| 2025-01-13 21:43:30 +0100 | <r-sta> | ie that lazyness seems to introduce the cursor |
| 2025-01-13 21:43:54 +0100 | <r-sta> | intuitively it is thought of as a cut off point |
| 2025-01-13 21:44:37 +0100 | <r-sta> | i guess that in a way its the traversal that got furthest along |
| 2025-01-13 21:44:39 +0100 | <r-sta> | and we always truncate, to avoid this |
| 2025-01-13 21:44:52 +0100 | <r-sta> | its notional, as its in state space encoding (church iiuc) |
| 2025-01-13 21:45:21 +0100 | <r-sta> | so you never actually produce this long truncated finite list as a subsection of the infinite list during lazy evaluation |
| 2025-01-13 21:45:43 +0100 | <r-sta> | and basically the whole time your in cursor land. thanks fusion! |
| 2025-01-13 21:46:18 +0100 | <r-sta> | fusion + lazyness = zippers? |
| 2025-01-13 21:47:28 +0100 | <r-sta> | i mean, its kinda complicated cos you can have a type hetroginous zipper, on a *list* that has the visited elements with updated type and as yet unvisited elements not type changed, like a halted scanner or map depending on if there is a carry |
| 2025-01-13 21:48:07 +0100 | <r-sta> | but in non list geti+seti instances, then use of the zippers linearization to handle partial type changing of entries... |
| 2025-01-13 21:48:15 +0100 | <r-sta> | yeesh ima give it a break. peace |
| 2025-01-13 21:48:25 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-13 21:49:28 +0100 | <r-sta> | (its like a horrible tree thats half put into a list and waiting to be reconstructed, / fold fusioned) |
| 2025-01-13 21:50:34 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 21:51:49 +0100 | <r-sta> | TreePartialZipper = TreePartialZipper [(\i a fa -> seti i (f a) fa) (i1,a1) , (\i a fa -> seti i (f a) fa) (i2,a2) ... ] [a] |
| 2025-01-13 21:52:46 +0100 | <r-sta> | TreePartialZipper f = TreePartialZipper [(\i a fa -> seti i (f a) fa) (i1,a1) , (\i a fa -> seti i (f a) fa) (i2,a2) ... ] (f a) |
| 2025-01-13 21:52:46 +0100 | <r-sta> | !? |
| 2025-01-13 21:52:46 +0100 | <r-sta> | sorrry |
| 2025-01-13 21:53:05 +0100 | <r-sta> | TreePartialZipper f = TreePartialZipper [(\i a fa -> seti i (f a) fa) (i1,a1) , (\i a fa -> seti i (f a) fa) (i2,a2) ... ] (xs :: f a) |
| 2025-01-13 21:53:40 +0100 | <r-sta> | call by use basically means all these suspended traversals get advanced along together |
| 2025-01-13 21:54:12 +0100 | <r-sta> | i just like the factorisation of the streaming inputs, so that the programs are in the algebra of composition of the scanners |
| 2025-01-13 21:54:31 +0100 | euleritian | (~euleritia@dynamic-176-006-133-150.176.6.pool.telefonica.de) (Remote host closed the connection) |
| 2025-01-13 21:54:32 +0100 | <r-sta> | and yeah, zips and the fusion rules assoiated, with everything done properly using geti+seti... |
| 2025-01-13 21:54:41 +0100 | <r-sta> | i almost got it all done |
| 2025-01-13 21:54:48 +0100 | euleritian | (~euleritia@dynamic-176-006-133-150.176.6.pool.telefonica.de) |
| 2025-01-13 21:57:00 +0100 | <r-sta> | https://gist.github.com/fen-hs |
| 2025-01-13 21:57:30 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 246 seconds) |
| 2025-01-13 21:57:30 +0100 | <r-sta> | https://gist.githubusercontent.com/fen-hs/a71ab735bf977d9b948a62416662fe57/raw/d5490878dded9298cc6… |
| 2025-01-13 21:57:41 +0100 | <r-sta> | if anyone wants to give me an award or anything... |
| 2025-01-13 21:58:00 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2025-01-13 21:59:07 +0100 | <r-sta> | sorry if gists arent your prefered method of disclosure |
| 2025-01-13 22:02:18 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2025-01-13 22:04:20 +0100 | dtman34 | (~dtman34@2601:447:d080:1a3c:903c:1567:85ba:7c1c) (Ping timeout: 265 seconds) |
| 2025-01-13 22:05:33 +0100 | <haskellbridge> | <hellwolf> o_o |
| 2025-01-13 22:07:34 +0100 | jespada | (~jespada@2800:a4:17:fd00:48e9:a913:6d6f:7a29) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-01-13 22:08:43 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 22:11:56 +0100 | OftenFaded1 | (~OftenFade@user/tisktisk) () |
| 2025-01-13 22:13:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2025-01-13 22:15:18 +0100 | <EvanR> | wall of text |
| 2025-01-13 22:16:16 +0100 | <r-sta> | sry |
| 2025-01-13 22:16:53 +0100 | <r-sta> | it was a huge body of work, some of the implications are really cool |
| 2025-01-13 22:17:00 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 264 seconds) |
| 2025-01-13 22:17:02 +0100 | <r-sta> | after youv transformed away all the streams and are just left with the scope bound state evaluations |
| 2025-01-13 22:17:12 +0100 | <r-sta> | cool result from fusion (tldr) |
| 2025-01-13 22:18:23 +0100 | <r-sta> | im really interested in the stateful sublanguage aspect |
| 2025-01-13 22:18:33 +0100 | <r-sta> | all my programs end up looking the same, just a where clause with a bunch of states getting bound |
| 2025-01-13 22:18:37 +0100 | dtman34 | (~dtman34@c-174-53-203-90.hsd1.mn.comcast.net) dtman34 |
| 2025-01-13 22:19:06 +0100 | <r-sta> | i think the semantics of such a language are quite rich and a close to those of a "stateless" functional language |
| 2025-01-13 22:19:31 +0100 | <EvanR> | stateful programming sounds groundbreaking indeed |
| 2025-01-13 22:19:42 +0100 | <EvanR> | it might have some relation to imperative programming |
| 2025-01-13 22:20:03 +0100 | <r-sta> | the main difference being the specific factorisation identifying and separately presenting, the data "in the function" |
| 2025-01-13 22:20:07 +0100 | <r-sta> | its just that graphs can be linearized |
| 2025-01-13 22:20:23 +0100 | <r-sta> | the variable binding dereferencing cannot create a cycle |
| 2025-01-13 22:20:27 +0100 | <r-sta> | thats basically the condition |
| 2025-01-13 22:20:49 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2025-01-13 22:20:58 +0100 | hgolden_ | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-01-13 22:21:00 +0100 | <r-sta> | but thinking of it "top down" has some relavence since you shouldnt be refering to things below you more or less |
| 2025-01-13 22:21:33 +0100 | <r-sta> | unless you are careful, but yeah, its definately not imperative, but thats kind of where the intuition comes from |
| 2025-01-13 22:23:43 +0100 | <r-sta> | stateful programming is just like how a function can only have 2 arguments |
| 2025-01-13 22:24:01 +0100 | <r-sta> | but that these can be other functions which output other functions of lower partial application cardinality and so on |
| 2025-01-13 22:24:06 +0100 | <r-sta> | i -> o |
| 2025-01-13 22:24:08 +0100 | <r-sta> | becomes |
| 2025-01-13 22:24:17 +0100 | <r-sta> | s -> i -> (s,o) |
| 2025-01-13 22:24:51 +0100 | <r-sta> | at the fundamental function type |
| 2025-01-13 22:24:51 +0100 | <r-sta> | and its actually |
| 2025-01-13 22:24:51 +0100 | <r-sta> | (s,s -> i -> (s,o)) |
| 2025-01-13 22:24:51 +0100 | <r-sta> | because you need the functions "stateful data" |
| 2025-01-13 22:25:03 +0100 | <r-sta> | all function calls also bind into scope the updated state information for the function |
| 2025-01-13 22:25:14 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-13 22:25:24 +0100 | <r-sta> | the state data associated to a stateful function is understood to have the pottential to change as it is called |
| 2025-01-13 22:25:44 +0100 | <r-sta> | and its all handled semantically by the binding of variables like (s,o) = fs s i |
| 2025-01-13 22:25:54 +0100 | <r-sta> | s' * |
| 2025-01-13 22:26:30 +0100 | <r-sta> | (s',o) = fs s i |
| 2025-01-13 22:26:31 +0100 | <r-sta> | and its actually quite annoying they dont compose in a better way |
| 2025-01-13 22:26:50 +0100 | <r-sta> | but the richness of variable dereferencing and binding into scope in where clauses is quite adiquate |
| 2025-01-13 22:27:10 +0100 | <r-sta> | as you try to start presenting the sequence any other way, you have to take over handling the scope |
| 2025-01-13 22:27:16 +0100 | <r-sta> | better to let the language do that |
| 2025-01-13 22:27:17 +0100 | dtman34 | (~dtman34@c-174-53-203-90.hsd1.mn.comcast.net) (Ping timeout: 248 seconds) |
| 2025-01-13 22:28:07 +0100 | <r-sta> | it gives a good overview of the "shape" of the programs that result |
| 2025-01-13 22:29:28 +0100 | <r-sta> | if you *do* opt to handle the connectivity of the function calls in another way by handling the scope, then it ends up equivalent to some way of expressing a graph such as edges, which i seem to remember having to be handled at type level however i was trying to do it, so it was abandoned! |
| 2025-01-13 22:30:19 +0100 | <r-sta> | the condition is that upon exponentiation, the graph of edges should not induce some kind of collision |
| 2025-01-13 22:31:13 +0100 | <r-sta> | like, to check it doesnt have a cycle you exponentiate the edge matrix and somehow it breaks when its cyclic |
| 2025-01-13 22:31:13 +0100 | <r-sta> | so you can check at compile time |
| 2025-01-13 22:31:13 +0100 | <r-sta> | basically this check does the "compilation" checking you connected all the edges correctly |
| 2025-01-13 22:31:16 +0100 | <r-sta> | total headache |
| 2025-01-13 22:31:46 +0100 | <r-sta> | the construction is like, knitting together this type level sequence of edge additions |
| 2025-01-13 22:31:55 +0100 | <r-sta> | constructor* |
| 2025-01-13 22:32:03 +0100 | <r-sta> | brutal! |
| 2025-01-13 22:32:14 +0100 | <r-sta> | its like another line in the where clause |
| 2025-01-13 22:32:28 +0100 | <r-sta> | but like, typechecked line by line |
| 2025-01-13 22:33:30 +0100 | <r-sta> | and you have to *manually* add those edges *correctly* it just breaks *horribly* if you do it wrong |
| 2025-01-13 22:33:30 +0100 | <r-sta> | it was like the least useful sublangauge ever, it was practically impossible to construct a program according to that |
| 2025-01-13 22:33:43 +0100 | <r-sta> | im quite impressed it actually even exists in sufficient enough a form as i can recount it |
| 2025-01-13 22:34:12 +0100 | <r-sta> | lex called it "cyrillic" and said it was the reason i crashed the car one time |
| 2025-01-13 22:36:23 +0100 | <r-sta> | OH and BTW, since im only here cos of some <<loop>> situation, i think these kind of checks are actually quite important! |
| 2025-01-13 22:36:46 +0100 | <r-sta> | cycle detected in your program! except in haskell that would mess up the recusive calls |
| 2025-01-13 22:38:35 +0100 | <r-sta> | think weirdly there is a one evaluation per function "style" aswell |
| 2025-01-13 22:38:53 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-01-13 22:39:20 +0100 | <r-sta> | as in all recusive extensions of the program graph are internal to this outer program graph of bound variables at state calls, this kind of sublanguage layer |
| 2025-01-13 22:39:27 +0100 | <r-sta> | now is a middle layer... |
| 2025-01-13 22:39:45 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 22:40:13 +0100 | <r-sta> | a non recusively extending bottleneck between streams and recusive functions |
| 2025-01-13 22:40:24 +0100 | <r-sta> | the scanning algebra! woot |
| 2025-01-13 22:41:29 +0100 | <r-sta> | the point from before is that, since it is non recursive by virtue of this one call per state "style", non recusive implying that *recursive calls can be flagged as errors* |
| 2025-01-13 22:42:04 +0100 | <r-sta> | reserving the recursive "sublanguage" for the layer below |
| 2025-01-13 22:42:44 +0100 | <r-sta> | language extension would be something like ExhaustiveWhere |
| 2025-01-13 22:43:00 +0100 | <r-sta> | saying that recursive function definitions are *not* allowed in where clauses |
| 2025-01-13 22:43:15 +0100 | <r-sta> | and that any repeated variable binding, is erronious |
| 2025-01-13 22:43:33 +0100 | <r-sta> | its a subscope situation where you dont allow variable reallocation |
| 2025-01-13 22:44:29 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 22:44:30 +0100 | <r-sta> | sorry, i mess up this part since its not clear how this pertains to cycles which are whats technically precluded |
| 2025-01-13 22:44:33 +0100 | <r-sta> | i might have made a mistake |
| 2025-01-13 22:44:57 +0100 | <r-sta> | anyway precludes recusrive function, but just not sure what exactly it means for the scope |
| 2025-01-13 22:44:58 +0100 | <EvanR> | you are hereby relegated to the blogosphere. Please state your theory in the form of a blog |
| 2025-01-13 22:45:08 +0100 | <r-sta> | lol ok chow |
| 2025-01-13 22:45:58 +0100 | <r-sta> | last chance to comment, re ExhaustiveWhere ? |
| 2025-01-13 22:46:45 +0100 | <r-sta> | "no cycles for <<loop>> safe where blocks" |
| 2025-01-13 22:48:12 +0100 | dtman34 | (~dtman34@c-174-53-203-90.hsd1.mn.comcast.net) dtman34 |
| 2025-01-13 22:49:12 +0100 | ftzm | (~ftzm@085081033150.dynamic.telenor.dk) ftzm |
| 2025-01-13 22:54:37 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-01-13 22:55:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 22:58:44 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2025-01-13 23:00:33 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2025-01-13 23:01:00 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-13 23:02:25 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-01-13 23:06:38 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-13 23:10:32 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 23:14:11 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-13 23:14:58 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-13 23:17:44 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-01-13 23:18:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-13 23:21:00 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-01-13 23:23:07 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) (Ping timeout: 265 seconds) |
| 2025-01-13 23:23:51 +0100 | r-sta | (~r-sta@sgyl-37-b2-v4wan-168528-cust2421.vm6.cable.virginm.net) (Quit: Client closed) |
| 2025-01-13 23:26:12 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 23:29:11 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 245 seconds) |
| 2025-01-13 23:29:28 +0100 | hawer | (~newyear@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-01-13 23:32:46 +0100 | dnerchm^ | (~dnerchm@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2025-01-13 23:33:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2025-01-13 23:33:03 +0100 | dsrt^ | (~dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 246 seconds) |
| 2025-01-13 23:33:04 +0100 | dnerchm^ | (~dnerchm@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-13 23:34:01 +0100 | dsrt^ | (ecaokoylad@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2025-01-13 23:36:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-13 23:36:43 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-13 23:36:56 +0100 | alecs | (~alecs@61.pool85-58-154.dynamic.orange.es) alecs |
| 2025-01-13 23:43:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-13 23:43:57 +0100 | dsrt^ | (ecaokoylad@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 276 seconds) |
| 2025-01-13 23:45:13 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f35081469c6fc5c461d.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-01-13 23:45:42 +0100 | dnerchm^ | (~dnerchm@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 272 seconds) |
| 2025-01-13 23:48:35 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2025-01-13 23:49:32 +0100 | simon1 | sim590 |
| 2025-01-13 23:50:00 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-01-13 23:51:56 +0100 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2025-01-13 23:52:37 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-01-13 23:59:19 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |