2026/05/25

2026-05-25 00:04:29 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 00:09:33 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 00:19:29 +0000weary-traveler(~user@user/user363627) user363627
2026-05-25 00:20:16 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 00:24:04 +0000Square(~Square@user/square) (Remote host closed the connection)
2026-05-25 00:24:57 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 00:30:24 +0000gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2026-05-25 00:31:05 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 00:32:29 +0000califax(~califax@user/califx) (Remote host closed the connection)
2026-05-25 00:33:29 +0000califax(~califax@user/califx) califx
2026-05-25 00:35:45 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 00:40:21 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 242 seconds)
2026-05-25 00:51:32 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 00:54:54 +0000koz_(~koz@121.99.240.58) (Ping timeout: 245 seconds)
2026-05-25 00:54:57 +0000koz(~koz@121.99.240.58)
2026-05-25 00:58:08 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 249 seconds)
2026-05-25 01:02:10 +0000xff0x(~xff0x@2405:6580:b080:900:dc8c:f72a:135a:db02) (Ping timeout: 248 seconds)
2026-05-25 01:03:37 +0000humasect(~humasect@192.249.132.90) (Quit: Leaving...)
2026-05-25 01:09:34 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 01:12:42 +0000cyclemaniac(~cyclemani@2a02:8071:881:2d20:c1c7:793e:b89b:1589) (Ping timeout: 245 seconds)
2026-05-25 01:14:18 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-05-25 01:22:59 +0000acidjnk_new3(~acidjnk@p200300d6e700e58123079e5c04a78535.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2026-05-25 01:23:35 +0000Guest54(~Guest54@2600:1700:4c00:68f0:3f3a:4952:67d7:919e)
2026-05-25 01:25:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 01:30:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 01:32:17 +0000chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2026-05-25 01:32:51 +0000chexum(~quassel@gateway/tor-sasl/chexum) chexum
2026-05-25 01:41:07 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 01:43:02 +0000tremon(~tremon@83.80.159.219) (Quit: getting boxed in)
2026-05-25 01:45:44 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 251 seconds)
2026-05-25 01:46:27 +0000humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2026-05-25 01:50:58 +0000Guest54(~Guest54@2600:1700:4c00:68f0:3f3a:4952:67d7:919e) (Quit: Client closed)
2026-05-25 01:56:29 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 01:56:50 +0000xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp)
2026-05-25 01:57:47 +0000nek0(~nek0@user/nek0) (Quit: The Lounge - https://thelounge.chat)
2026-05-25 02:00:03 +0000Flow(~none@gentoo/developer/flow) (Quit: WeeChat 4.7.2)
2026-05-25 02:01:12 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 02:01:53 +0000Flow(~none@gentoo/developer/flow) flow
2026-05-25 02:05:35 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 02:06:11 +0000nek0(~nek0@user/nek0) nek0
2026-05-25 02:10:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2026-05-25 02:11:26 +0000tusko(~uwu@user/tusko) (Remote host closed the connection)
2026-05-25 02:11:39 +0000tusko(~uwu@user/tusko) tusko
2026-05-25 02:18:15 +0000notzmv(~umar@user/notzmv) (Ping timeout: 252 seconds)
2026-05-25 02:20:11 +0000chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2026-05-25 02:20:11 +0000tusko(~uwu@user/tusko) (Remote host closed the connection)
2026-05-25 02:20:22 +0000chexum(~quassel@gateway/tor-sasl/chexum) chexum
2026-05-25 02:20:23 +0000tusko(~uwu@user/tusko) tusko
2026-05-25 02:21:10 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 256 seconds)
2026-05-25 02:21:16 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 02:26:15 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds)
2026-05-25 02:37:03 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 02:43:54 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 251 seconds)
2026-05-25 02:45:23 +0000sp1ff(~user@2601:1c2:4080:14c0:5df2:f2f4:8a07:70ec) (Remote host closed the connection)
2026-05-25 02:55:07 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 03:00:07 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-05-25 03:10:38 +0000sp1ff(~user@2601:1c2:4080:14c0:5df2:f2f4:8a07:70ec) sp1ff
2026-05-25 03:10:54 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 03:12:11 +0000Leary(~Leary@user/Leary/x-0910699) (Remote host closed the connection)
2026-05-25 03:14:08 +0000spew(~spew@user/spew) (Ping timeout: 275 seconds)
2026-05-25 03:15:53 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-05-25 03:18:35 +0000Leary(~Leary@user/Leary/x-0910699) Leary
2026-05-25 03:26:37 +0000spew(~spew@user/spew) spew
2026-05-25 03:26:41 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 03:31:46 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-05-25 03:37:31 +0000lisbeths(uid135845@id-135845.lymington.irccloud.com) lisbeths
2026-05-25 03:42:19 +0000robertm(robertm@lattice.rojoma.com) (Quit: ...)
2026-05-25 03:42:37 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 03:45:36 +0000robertm(robertm@lattice.rojoma.com) robertm
2026-05-25 03:47:43 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-05-25 03:58:15 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 04:02:38 +0000emilym(~Thunderbi@user/emilym) emilym
2026-05-25 04:02:38 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-25 04:07:17 +0000emilym(~Thunderbi@user/emilym) (Ping timeout: 252 seconds)
2026-05-25 04:07:39 +0000rekahsoft(~rekahsoft@70.51.99.119) rekahsoft
2026-05-25 04:13:11 +0000ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2026-05-25 04:13:11 +0000gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2026-05-25 04:13:11 +0000bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2026-05-25 04:13:12 +0000marinelli(~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection)
2026-05-25 04:13:35 +0000marinelli(~weechat@gateway/tor-sasl/marinelli) marinelli
2026-05-25 04:13:37 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 04:13:38 +0000bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2026-05-25 04:13:40 +0000ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2026-05-25 04:13:52 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 04:20:29 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 04:23:21 +0000ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2026-05-25 04:23:21 +0000ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2026-05-25 04:23:40 +0000ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2026-05-25 04:24:20 +0000ec(~ec@gateway/tor-sasl/ec) ec
2026-05-25 04:31:41 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 04:34:04 +0000humasect(~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection)
2026-05-25 04:36:25 +0000chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 252 seconds)
2026-05-25 04:36:32 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 249 seconds)
2026-05-25 04:36:38 +0000chexum(~quassel@gateway/tor-sasl/chexum) chexum
2026-05-25 04:47:27 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 04:52:31 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-05-25 04:55:31 +0000ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2026-05-25 04:55:51 +0000ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2026-05-25 04:58:34 +0000notzmv(~umar@user/notzmv) notzmv
2026-05-25 04:58:45 +0000tt1231607019780(~tt1231@2603:6010:8700:4a81:a4f6:acff:fe95:3803) (Ping timeout: 246 seconds)
2026-05-25 05:03:15 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 05:03:25 +0000michalz(~michalz@185.246.207.221)
2026-05-25 05:05:03 +0000peterbecich(~Thunderbi@71.84.33.135) peterbecich
2026-05-25 05:08:12 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 05:09:30 +0000tnt1(~Thunderbi@user/tnt1) tnt1
2026-05-25 05:19:01 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 05:23:07 +0000takuan(~takuan@141.134.185.233)
2026-05-25 05:23:36 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 05:27:04 +0000tnt1(~Thunderbi@user/tnt1) (Remote host closed the connection)
2026-05-25 05:32:34 +0000tnt1(~Thunderbi@user/tnt1) tnt1
2026-05-25 05:34:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 05:39:05 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 254 seconds)
2026-05-25 05:46:55 +0000lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2026-05-25 05:49:47 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 05:56:18 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-25 06:00:54 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 06:04:03 +0000Alex_delenda_est(~al_test@5.139.233.99) (Ping timeout: 244 seconds)
2026-05-25 06:04:15 +0000peterbecich(~Thunderbi@71.84.33.135) (Ping timeout: 266 seconds)
2026-05-25 06:04:34 +0000AlexZenon(~alzenon@5.139.233.99) (Ping timeout: 244 seconds)
2026-05-25 06:05:24 +0000AlexNoo(~AlexNoo@5.139.233.99) (Ping timeout: 252 seconds)
2026-05-25 06:05:40 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 259 seconds)
2026-05-25 06:13:59 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 06:18:58 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2026-05-25 06:27:59 +0000CiaoSen(~Jura@dynamic-046-114-251-077.46.114.pool.telefonica.de) CiaoSen
2026-05-25 06:29:31 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 06:29:47 +0000haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
2026-05-25 06:34:05 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2026-05-25 06:36:02 +0000gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2026-05-25 06:36:43 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 06:37:21 +0000bedbedbde(~bedbedbde@user/bedbedbde) (Quit: bedbedbde)
2026-05-25 06:44:57 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 06:45:28 +0000gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2026-05-25 06:45:29 +0000ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2026-05-25 06:45:54 +0000ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2026-05-25 06:46:09 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 06:49:32 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 06:52:54 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline
2026-05-25 07:00:32 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 07:03:18 +0000gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2026-05-25 07:03:59 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 07:05:21 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 07:16:17 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 07:16:41 +0000chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2026-05-25 07:17:24 +0000chexum(~quassel@gateway/tor-sasl/chexum) chexum
2026-05-25 07:20:41 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-05-25 07:31:21 +0000synchromesh(~john@2406:5a00:247e:1500:4cca:facc:b385:8d3e) (Read error: Connection reset by peer)
2026-05-25 07:31:41 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 07:32:58 +0000synchromesh(~john@2406:5a00:247e:1500:4cca:facc:b385:8d3e) synchromesh
2026-05-25 07:36:02 +0000fp1(~Thunderbi@130.233.70.102) fp
2026-05-25 07:38:28 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-05-25 07:39:51 +0000jreicher(~joelr@user/jreicher) (Quit: In transit)
2026-05-25 07:49:44 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 07:54:51 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 07:55:23 +0000jcarpenter2(~lol@2603:3016:1e01:b9c0:5528:6cdb:4792:b224)
2026-05-25 08:01:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 08:07:03 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2026-05-25 08:08:10 +0000emmanuelux(~em@user/emmanuelux) (Quit: bye)
2026-05-25 08:15:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 08:19:56 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-25 08:22:51 +0000__monty__(~toonn@user/toonn) toonn
2026-05-25 08:31:01 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 08:36:14 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 08:41:51 +0000acidjnk_new3(~acidjnk@p200300d6e700e5819d9a4d62040224c6.dip0.t-ipconnect.de)
2026-05-25 08:44:40 +0000divlamir(~divlamir@user/divlamir) (Read error: Connection reset by peer)
2026-05-25 08:44:56 +0000divlamir(~divlamir@user/divlamir) divlamir
2026-05-25 08:45:26 +0000fp1(~Thunderbi@130.233.70.102) (Ping timeout: 264 seconds)
2026-05-25 08:45:53 +0000tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2026-05-25 08:51:55 +0000jreicher(~joelr@user/jreicher) jreicher
2026-05-25 08:57:20 +0000acidjnk_new(~acidjnk@p200300d6e700e587d0d964644d901e6e.dip0.t-ipconnect.de)
2026-05-25 09:00:10 +0000acidjnk_new3(~acidjnk@p200300d6e700e5819d9a4d62040224c6.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
2026-05-25 09:02:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 09:09:25 +0000CiaoSen(~Jura@dynamic-046-114-251-077.46.114.pool.telefonica.de) (Ping timeout: 245 seconds)
2026-05-25 09:09:37 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-05-25 09:16:48 +0000notzmv(~umar@user/notzmv) (Ping timeout: 252 seconds)
2026-05-25 09:20:39 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 09:25:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-05-25 09:36:24 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 09:40:55 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 246 seconds)
2026-05-25 09:51:47 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 09:56:14 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 254 seconds)
2026-05-25 10:03:35 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 10:06:36 +0000CiaoSen(~Jura@dynamic-046-114-251-077.46.114.pool.telefonica.de) CiaoSen
2026-05-25 10:08:18 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-05-25 10:19:18 +0000Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2026-05-25 10:19:22 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 10:22:15 +0000xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds)
2026-05-25 10:24:32 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2026-05-25 10:28:25 +0000gmg(~user@user/gehmehgeh) (Quit: Leaving)
2026-05-25 10:28:31 +0000marinelli(~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli)
2026-05-25 10:35:10 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 10:39:32 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 247 seconds)
2026-05-25 10:43:30 +0000acidsys(~crameleon@openSUSE/member/crameleon) (Ping timeout: 248 seconds)
2026-05-25 10:46:23 +0000acidsys(~crameleon@openSUSE/member/crameleon) crameleon
2026-05-25 10:50:40 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 10:51:07 +0000dibblego(~dibblego@haskell/developer/dibblego) (Ping timeout: 265 seconds)
2026-05-25 10:53:03 +0000CiaoSen(~Jura@dynamic-046-114-251-077.46.114.pool.telefonica.de) (Ping timeout: 252 seconds)
2026-05-25 10:57:49 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2026-05-25 11:02:03 +0000fun-safe-math(~fun-safe-@97-120-35-225.ptld.qwest.net) ()
2026-05-25 11:04:18 +0000fun-safe-math(~fun-safe-@97.120.35.225) fun-safe-math
2026-05-25 11:04:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 11:08:15 +0000CiaoSen(~Jura@46.114.251.77) CiaoSen
2026-05-25 11:09:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-25 11:12:50 +0000tnt1(~Thunderbi@user/tnt1) (Remote host closed the connection)
2026-05-25 11:20:23 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 11:24:48 +0000weary-traveler(~user@user/user363627) (Remote host closed the connection)
2026-05-25 11:25:04 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 11:25:40 +0000notzmv(~umar@user/notzmv) notzmv
2026-05-25 11:26:06 +0000kaol(~kaol@94-237-45-144.nl-ams1.upcloud.host) (Read error: Connection reset by peer)
2026-05-25 11:28:23 +0000michalz(~michalz@185.246.207.221) (Quit: ZNC 1.9.1 - https://znc.in)
2026-05-25 11:28:42 +0000michalz(~michalz@185.246.207.205)
2026-05-25 11:36:09 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 11:40:50 +0000synchromesh(~john@2406:5a00:247e:1500:4cca:facc:b385:8d3e) (Read error: Connection reset by peer)
2026-05-25 11:41:17 +0000synchromesh(~john@2406:5a00:247e:1500:b0dc:77a1:3a5a:2f5) synchromesh
2026-05-25 11:41:45 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2026-05-25 11:45:52 +0000Square2(~Square4@user/square) Square
2026-05-25 11:49:03 +0000califax(~califax@user/califx) (Remote host closed the connection)
2026-05-25 11:51:01 +0000califax(~califax@user/califx) califx
2026-05-25 11:52:10 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 11:54:17 +0000califax_(~califax@user/califx) califx
2026-05-25 11:55:03 +0000califax(~califax@user/califx) (Remote host closed the connection)
2026-05-25 11:55:33 +0000califax_califax
2026-05-25 11:56:51 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 12:05:36 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 12:06:57 +0000xff0x(~xff0x@2405:6580:b080:900:5801:469a:d89d:a8ee)
2026-05-25 12:10:11 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 244 seconds)
2026-05-25 12:14:11 +0000akegalj(~akegalj@141.136.184.165) akegalj
2026-05-25 12:27:47 +0000CiaoSen(~Jura@46.114.251.77) (Ping timeout: 256 seconds)
2026-05-25 12:31:57 +0000tnt1(~Thunderbi@user/tnt1) tnt1
2026-05-25 12:39:26 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 12:44:04 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-05-25 12:50:57 +0000califax(~califax@user/califx) (Remote host closed the connection)
2026-05-25 12:51:59 +0000califax(~califax@user/califx) califx
2026-05-25 12:55:13 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 12:56:51 +0000haritz(~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8)
2026-05-25 12:56:52 +0000haritz(~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host)
2026-05-25 12:56:52 +0000haritz(~hrtz@user/haritz) haritz
2026-05-25 12:59:53 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-05-25 13:06:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 13:11:41 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2026-05-25 13:12:39 +0000AlexNoo(~AlexNoo@94.233.241.168)
2026-05-25 13:22:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 13:26:11 +0000 <segfaultfizzbuzz> tomsmeding: well, is your evaluator sequential or parallel?
2026-05-25 13:26:23 +0000 <segfaultfizzbuzz> if it is parallel, somehow work is coordinated, right?
2026-05-25 13:26:45 +0000 <segfaultfizzbuzz> so something says "eval1 is here, eval2 is there, etc..." across your 1024 cores or whatever
2026-05-25 13:26:59 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-05-25 13:27:52 +0000 <segfaultfizzbuzz> the idea of laziness is that you do only work which is necessary
2026-05-25 13:32:17 +0000 <segfaultfizzbuzz> i don't think you can guarantee that only necessary work is being done on all 1024 cores
2026-05-25 13:32:28 +0000 <segfaultfizzbuzz> so maybe you are 90% necessary 10% unnecessary or something
2026-05-25 13:32:35 +0000 <segfaultfizzbuzz> in which case that looks a lot like amdahl's law
2026-05-25 13:33:45 +0000collide29543(~collide29@user/collide2954) collide2954
2026-05-25 13:34:43 +0000Square2(~Square4@user/square) (Ping timeout: 243 seconds)
2026-05-25 13:35:43 +0000collide2954(~collide29@user/collide2954) (Ping timeout: 264 seconds)
2026-05-25 13:35:43 +0000collide29543collide2954
2026-05-25 13:37:46 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 13:42:33 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds)
2026-05-25 13:52:58 +0000spew(~spew@user/spew) (Ping timeout: 257 seconds)
2026-05-25 13:53:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 13:56:51 +0000 <tomsmeding> segfaultfizzbuzz: amdahl's law says something about the scaling behaviour over multiple cores after you have chosen a specific evaluation strategy, and that strategy conforms to the assumptions of amdahl
2026-05-25 13:57:20 +0000 <tomsmeding> re guaranteeing only necessary work: isn't that just a choice?
2026-05-25 13:57:40 +0000 <tomsmeding> sure, you may be able to speculatively spawn more parallel work if you're willing to overestimate the set of actually necessary work
2026-05-25 13:57:53 +0000 <tomsmeding> but that sounds more difficult than not speculating at all and only doing the work that has been shown to be necessary
2026-05-25 13:58:16 +0000 <tomsmeding> and the "somehow work is coordinated" is true, kind of, but also not precise enough to be useful in this context I think
2026-05-25 13:58:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 13:58:53 +0000 <tomsmeding> how is work being coordinated precisely? Is the parallelisation explicit in the program being evaluated (e.g. mapConcurrently style), or is it implicit in the evaluation strategy when it discovers two independent thunks?
2026-05-25 14:00:03 +0000 <tomsmeding> if you want to point at a connection here, you'll have to be more concrete/precise I think
2026-05-25 14:01:37 +0000AlexZenon(~alzenon@94.233.241.168)
2026-05-25 14:02:42 +0000 <tomsmeding> (i.e. I'm happy to consider an analogue to Amdahl that's not precisely the original statement, but then you have to say what analogue you mean :p)
2026-05-25 14:06:23 +0000AlexZenon(~alzenon@94.233.241.168) (Ping timeout: 254 seconds)
2026-05-25 14:07:35 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 14:11:04 +0000Alex_delenda_est(~al_test@94.233.241.168)
2026-05-25 14:12:31 +0000Alex_delenda_set(~al_test@94.233.241.168)
2026-05-25 14:13:18 +0000AlexZenon(~alzenon@94.233.241.168)
2026-05-25 14:14:29 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 14:14:53 +0000pavonia(~user@user/siracusa) (Quit: Bye!)
2026-05-25 14:15:19 +0000Alex_delenda_est(~al_test@94.233.241.168) (Ping timeout: 242 seconds)
2026-05-25 14:17:50 +0000Alex_delenda_setAlex_delenda_est
2026-05-25 14:25:44 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 14:31:13 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 241 seconds)
2026-05-25 14:32:07 +0000spew(~spew@user/spew) spew
2026-05-25 14:33:58 +0000Square2(~Square4@user/square) Square
2026-05-25 14:42:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 14:42:48 +0000 <segfaultfizzbuzz> if the evaluation wasn't needed, then that percentage of the parallelism is a waste
2026-05-25 14:45:30 +0000 <segfaultfizzbuzz> if you do single core eval then maybe you can be perfect at avoiding wasted work
2026-05-25 14:45:49 +0000 <segfaultfizzbuzz> i would guess that the percent of waste grows as you add cores
2026-05-25 14:45:55 +0000 <segfaultfizzbuzz> in many cases
2026-05-25 14:47:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2026-05-25 14:48:59 +0000karenw(~karenw@user/karenw) karenw
2026-05-25 14:58:05 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 15:02:45 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 15:06:35 +0000Digitteknohippie(~user@user/digit) Digit
2026-05-25 15:07:50 +0000Digit(~user@user/digit) (Ping timeout: 252 seconds)
2026-05-25 15:08:22 +0000bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds)
2026-05-25 15:08:39 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 15:09:18 +0000prdak(~Thunderbi@user/prdak) prdak
2026-05-25 15:13:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 249 seconds)
2026-05-25 15:24:27 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 15:26:35 +0000ft(~ft@p4fc2aedc.dip0.t-ipconnect.de) (Quit: Lost terminal)
2026-05-25 15:29:43 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-05-25 15:31:40 +0000 <[exa]> segfaultfizzbuzz: if the evaluation wasn't needed, then the parallelization strategy sucked in the first place and is not a subject to (extreme-case) situation described by Amdahl
2026-05-25 15:33:29 +0000 <[exa]> you might be referring to the situation with unnecessary synchronization and re-computation over shared sub-computations, which is indeed triggered by the laziness, but it is more of a scheduling problem
2026-05-25 15:34:50 +0000ft(~ft@p4fc2aedc.dip0.t-ipconnect.de) ft
2026-05-25 15:40:10 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 15:43:04 +0000 <tomsmeding> segfaultfizzbuzz: right, with "wasted work", are you referring to synchronisation overheads which are not actually work specified in the program but solely for getting that work to be performed?
2026-05-25 15:43:18 +0000 <tomsmeding> e.g. the RTS scheduler, mutex overhead, etc.
2026-05-25 15:44:07 +0000 <tomsmeding> because the prime assumption for Amdahl's law implies that there is no such work
2026-05-25 15:44:22 +0000 <tomsmeding> the assumption is in fact even stronger than that, but in particular it also means that there is no such overhead
2026-05-25 15:45:03 +0000 <tomsmeding> The assumption is in fact never valid in practice! But as a result the formula is simple. All models are wrong, some are useful.
2026-05-25 15:45:07 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-05-25 15:45:09 +0000 <int-e> with GHC's runtime, several threads entering the same closure at the same time can all start evaluating it because a full lock is too expensive and purity means it's just a waste of effort rather than a correctness issue
2026-05-25 15:45:27 +0000 <int-e> I would assume that "wasted work" refers to that
2026-05-25 15:45:45 +0000 <tomsmeding> oh, right, that's also a thing
2026-05-25 15:48:06 +0000 <tomsmeding> int-e: does a thread, when entering a closure, mark that closure as a black hole without locking it? (And if so, is a CAS also too expensive there?)
2026-05-25 15:49:03 +0000 <tomsmeding> (I guess it might be)
2026-05-25 15:49:03 +0000synchromesh(~john@2406:5a00:247e:1500:b0dc:77a1:3a5a:2f5) (Read error: Connection reset by peer)
2026-05-25 15:49:36 +0000synchromesh(~john@2406:5a00:247e:1500:b0dc:77a1:3a5a:2f5) synchromesh
2026-05-25 15:55:57 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 15:56:15 +0000euphores(~SASL_euph@user/euphores) (Quit: Leaving.)
2026-05-25 15:57:50 +0000DigitteknohippieDigit
2026-05-25 16:00:58 +0000 <int-e> tomsmeding: The code uses an atomic store with release ordering. https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/StgToCmm/Bind.hs#L733-736 ...I can't really answer your question though. There are complications on top of the cost of doing a CAS. What happens to the owning TSO field? As is it doesn't matter which of the writes to that field win. With CAS, would you need a 2-word CAS?...
2026-05-25 16:01:04 +0000 <int-e> ...Can that cross cache lines?
2026-05-25 16:01:18 +0000tv(~tv@user/tv) (Quit: derp)
2026-05-25 16:01:35 +0000tv(~tv@user/tv) tv
2026-05-25 16:02:08 +0000 <tomsmeding> cache-line-crossing 2-word CAS is likely not a thing
2026-05-25 16:02:42 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 16:02:59 +0000 <tomsmeding> int-e: not actually knowing anything about this code, it looks like the snippet you found is predicatd on eager_blackholing which (according to the comment above it) is false by default?
2026-05-25 16:03:23 +0000rekahsoft(~rekahsoft@70.51.99.119) (Ping timeout: 252 seconds)
2026-05-25 16:05:28 +0000akegalj(~akegalj@141.136.184.165) (Quit: leaving)
2026-05-25 16:05:37 +0000noscript(~noscript@user/earldouglas) earldouglas
2026-05-25 16:06:49 +0000 <tomsmeding> https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/include/stg/SMP.h#L170-172 does MUT_FIELD really mark an immutable field?
2026-05-25 16:09:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 16:10:26 +0000 <tomsmeding> https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/include/stg/SMP.h#L182-185 Is this causality argument really sound on all architectures? What if O' was written by processor P1, and O by P2, and we are P3. Do all architectures guarantee that if P2 can see O' then P3 also can?
2026-05-25 16:13:53 +0000califax(~califax@user/califx) (Quit: ZNC 1.10.1 - https://znc.in)
2026-05-25 16:14:44 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2026-05-25 16:15:21 +0000califax(~califax@user/califx) califx
2026-05-25 16:16:49 +0000 <tomsmeding> it seems the ARMv7 spec did in fact allow such non-causal behaviour, but the model was simplified (thus prohibiting such behaviour) in ARMv8
2026-05-25 16:17:14 +0000 <tomsmeding> does GHC support ARMv7? :D
2026-05-25 16:17:43 +0000 <geekosaur> on the way out iirc?
2026-05-25 16:22:30 +0000 <tomsmeding> and IBM POWER also still allows such "non-causal" behaviour (https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/pldi105-sarkar.pdf , search for "WRC:")
2026-05-25 16:22:44 +0000 <tomsmeding> though I don't think GHC supports ppc :)
2026-05-25 16:23:22 +0000 <geekosaur> it does
2026-05-25 16:24:14 +0000 <tomsmeding> geekosaur: the Note I linked, at least, is wrong on PPC, as far as I can determine. (SMP.h:182-185) I don't know if that also invalidates the implementation. Would anyone be interested in this?
2026-05-25 16:25:23 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 16:25:42 +0000 <geekosaur> dunno about native backend but there's definitely support code for ppc64 (looks like it uses llvm backend?)
2026-05-25 16:26:15 +0000 <tomsmeding> I'd guess that whether it's NCG or LLVM doesn't matter for this -- what matters is the barriers emitted by GHC, and LLVM isn't going to change those
2026-05-25 16:26:33 +0000 <geekosaur> yeh
2026-05-25 16:26:55 +0000 <tomsmeding> (or, well, I guess it might sometimes, but not anything you can rely on)
2026-05-25 16:28:15 +0000 <geekosaur> someone has recently been cleaning up the ppc code, which is why I know it's supported, but don't have details
2026-05-25 16:28:22 +0000 <tomsmeding> ah
2026-05-25 16:28:44 +0000 <tomsmeding> should I open an issue about this? I'm hesitant because I don't really have the time/energy to figure out if the implementation is actually wrong :p
2026-05-25 16:29:46 +0000 <geekosaur> still worth opening it to make whoever's working on the ppc stuff currently aware, I think
2026-05-25 16:30:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds)
2026-05-25 16:31:39 +0000emilym(~Thunderbi@user/emilym) emilym
2026-05-25 16:36:00 +0000emilym(~Thunderbi@user/emilym) (Ping timeout: 245 seconds)
2026-05-25 16:37:12 +0000 <int-e> tomsmeding: You're right that there is no eager blackholing by default, so I guess even that has a noticable performance impact. So the window for duplicate evaluation is larger than I thought. (It will be caught by walking up the stack when a GC is triggered or threads are stopped for other reasons.)
2026-05-25 16:37:50 +0000 <tomsmeding> right, so by default, parallel evaluation of the same thunk will just, well, do that?
2026-05-25 16:38:05 +0000 <tomsmeding> now that I write that, I think I recall reading precisely that somewhere before
2026-05-25 16:39:15 +0000 <geekosaur> yeh
2026-05-25 16:40:09 +0000 <geekosaur> until a decade or so back they locked the thunk to avoid duplicate evaluation, then they determined that the overhead was significantly higher than just letting it happen and got rid of it
2026-05-25 16:40:16 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Excess Flood)
2026-05-25 16:40:35 +0000 <tomsmeding> right
2026-05-25 16:41:11 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 16:44:30 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2026-05-25 16:45:23 +0000 <geekosaur> of course that means `unsafePerformIO` may do surprising things in that case… then again, if you have any such expectations to begin with you're probably in trouble anyway
2026-05-25 16:45:45 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-25 16:46:12 +0000 <tomsmeding> that is actually an interesting complication to the fairly typical usage of unsafePerformIO to initialise a global counter/mutex/something
2026-05-25 16:46:36 +0000 <tomsmeding> what if the first use of that counter is in parallel from multiple threads? I guess you may get multiple counters?
2026-05-25 16:47:20 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Excess Flood)
2026-05-25 16:47:51 +0000fgarcia(~lei@user/fgarcia) (Quit: Remote host closed the connection)
2026-05-25 16:48:08 +0000Square(~Square@user/square) Square
2026-05-25 16:49:37 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 16:49:53 +0000 <int-e> unsafePerformIO has duplicate avoidance (vs. unsafeDupablePerformIO that doesn't)
2026-05-25 16:50:10 +0000fgarcia(~lei@user/fgarcia) fgarcia
2026-05-25 16:50:34 +0000 <geekosaur> no, I think that's safe. "multiple counters" can only happen if you don't `NOINLINE` it, and "gets initialized multiple times" probably won't happen because this isn't likely to be the parallel-evaluated thunk (that'd be the thunk containing usage, not the thunk representing the global CAF)
2026-05-25 16:51:57 +0000 <int-e> The main surprise with `unsafePerformIO` evaluations that I know of is that they can just fizzle out, breaking resource management with `bracket`. Mostly (only?) in the context of STM.
2026-05-25 16:52:30 +0000 <tomsmeding> I opened an issue about the possible powerpc thing https://gitlab.haskell.org/ghc/ghc/-/issues/27298
2026-05-25 16:52:33 +0000 <geekosaur> I thought unsafePerformIO inside STM raised an RTS exception?
2026-05-25 16:53:06 +0000 <tomsmeding> int-e: oh right, it's not unsafeDupablePerformIO! Good.
2026-05-25 16:53:06 +0000 <int-e> geekosaur: Really? Hmm, how would it do that?
2026-05-25 16:54:01 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2026-05-25 16:54:32 +0000 <tomsmeding> the trivial case isn't caught, in any case https://play.haskell.org/saved/esxKgvjD
2026-05-25 16:54:42 +0000 <tomsmeding> (but maybe this is too trivial)
2026-05-25 16:54:44 +0000jreicher(~joelr@user/jreicher) (Read error: Connection reset by peer)
2026-05-25 16:55:28 +0000 <int-e> tomsmeding: I think it needs `return $!` but that still works
2026-05-25 16:55:34 +0000jreicher(~joelr@user/jreicher) jreicher
2026-05-25 16:56:14 +0000tzh(~tzh@76.115.131.146)
2026-05-25 16:59:17 +0000skum(~skum@user/skum) (Quit: WeeChat 4.9.0)
2026-05-25 16:59:42 +0000 <int-e> geekosaur: I assume you remember this: https://play.haskell.org/saved/Q1HM9Uyi
2026-05-25 17:00:09 +0000 <geekosaur> hm, I thought it just checked if there was a transaction open; maybe it only handles the other direction (STM inside of unsafePerformIO
2026-05-25 17:00:12 +0000 <int-e> (also note the -O0 )
2026-05-25 17:00:17 +0000Digitteknohippie(~user@user/digit) Digit
2026-05-25 17:00:35 +0000Digit(~user@user/digit) (Ping timeout: 244 seconds)
2026-05-25 17:00:52 +0000 <int-e> There is such a check, but it's not in `unsafePerformIO`; it's in `atomically`.
2026-05-25 17:00:55 +0000tnt1(~Thunderbi@user/tnt1) (Remote host closed the connection)
2026-05-25 17:01:07 +0000tnt1(~Thunderbi@user/tnt1) tnt1
2026-05-25 17:01:57 +0000 <geekosaur> ugh. that one I'm pretty sure is supposed to fail since (a second) atomically is inside unsafePerformIO. but maybe https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0077-deprecate-stm-invariants… broke it?
2026-05-25 17:04:33 +0000 <int-e> geekosaur: And it does fail.
2026-05-25 17:05:00 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 17:05:45 +0000 <int-e> I don't see what STM invariants have to do with this.
2026-05-25 17:08:22 +0000 <int-e> tomsmeding: can I register a thumbs down for the closing confirmation on the playground? (not that I use it heavily...)
2026-05-25 17:08:42 +0000skum(~skum@user/skum) skum
2026-05-25 17:09:00 +0000cyclemaniac(~cyclemani@2a02:8071:881:2d20:c1c7:793e:b89b:1589)
2026-05-25 17:09:56 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 17:10:39 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 17:12:38 +0000Square2(~Square4@user/square) (Ping timeout: 253 seconds)
2026-05-25 17:15:19 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-05-25 17:26:12 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 17:27:10 +0000tnt1(~Thunderbi@user/tnt1) (Ping timeout: 276 seconds)
2026-05-25 17:31:15 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 17:34:41 +0000DigitteknohippieDigit
2026-05-25 17:36:13 +0000 <tomsmeding> int-e: I guess. One of the problems with that is that ctrl-W closes the tab, even if the editor is focused, whereas a user may hit that by habit to do the readline delete-word thing
2026-05-25 17:36:18 +0000 <tomsmeding> and then the code is gone.
2026-05-25 17:36:54 +0000 <int-e> tomsmeding: FWIW, I think that non-causal memory issue is real; the release ordering imposed by updateWithIndirection in Updates.h isn't strong enough. So you can have something like https://paste.tomsmeding.com/bFipQCLC (trying to make your four bullet points more concrete)
2026-05-25 17:37:31 +0000 <int-e> tomsmeding: but all I did is change a compiler flag and add three characters. ;P
2026-05-25 17:37:48 +0000 <tomsmeding> sure :p
2026-05-25 17:38:04 +0000 <int-e> anyway. it's just a vote, and you're under no obligation to tally any
2026-05-25 17:38:14 +0000 <tomsmeding> I think you do see that trying to determine the cost of deleting changes is not something the playground should be doing :p
2026-05-25 17:38:23 +0000 <tomsmeding> yes thanks, noted (in my head)
2026-05-25 17:38:42 +0000 <int-e> tomsmeding: at the same time, good luck to anybody trying to actually manifest that memory ordering issue!
2026-05-25 17:38:52 +0000 <tomsmeding> oh for sure
2026-05-25 17:39:32 +0000bedbedbde(~bedbedbde@user/bedbedbde) bedbedbde
2026-05-25 17:39:54 +0000 <geekosaur> comment on that issue please
2026-05-25 17:40:04 +0000emilym(~Thunderbi@user/emilym) emilym
2026-05-25 17:40:16 +0000 <tomsmeding> int-e: is your thread 2 script accurate? Wouldn't it be "evaluate t2, as part of that evaluate t1 to r1"?
2026-05-25 17:41:12 +0000 <tomsmeding> int-e: and should the thread 3 script have "evaluate t1, see <IND r1>, get r1" as clarification?
2026-05-25 17:41:34 +0000 <int-e> tomsmeding: No, that's wrong indeed. Both in threads 2 and 3.
2026-05-25 17:41:42 +0000 <tomsmeding> I'm also not sure if t2 is necessary here at all
2026-05-25 17:41:54 +0000 <tomsmeding> the two values are t1 and r1 here
2026-05-25 17:42:15 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 17:42:29 +0000 <int-e> tomsmeding: https://paste.tomsmeding.com/b9M3Q3iB
2026-05-25 17:42:44 +0000 <int-e> tomsmeding: t2 is where thread 2 writes something that thread 3 reads
2026-05-25 17:43:01 +0000 <int-e> maybe I should've called those x and y
2026-05-25 17:43:10 +0000 <tomsmeding> nah
2026-05-25 17:44:14 +0000 <tomsmeding> int-e: still, the point here is that thread 3 does get the <IND r1>, right? If it doesn't, then it just evaluates t2 to r1 itself and that's that
2026-05-25 17:44:54 +0000 <int-e> yeah. but it gets it from t2, written by thread 2, and only causality links it to the local heap data of thread 1
2026-05-25 17:45:15 +0000 <int-e> while if it read it from t1 then release ordering from thread 1 would ensure that tht data is there
2026-05-25 17:45:16 +0000 <tomsmeding> (i.e. your analogue to "read y, yielding 1" is implicit, and I'd like it to be explicit)
2026-05-25 17:45:44 +0000 <tomsmeding> (if the read from y yielded 0, then x = 0 is perfectly fine and unsurprising)
2026-05-25 17:46:16 +0000 <int-e> the `1` value is `r1`; y is t2.
2026-05-25 17:46:23 +0000 <int-e> x is t1
2026-05-25 17:46:41 +0000 <tomsmeding> you're making a distinction between "evaluate t2 to r1" and "evaluate t2, get r1"?
2026-05-25 17:47:06 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 242 seconds)
2026-05-25 17:47:46 +0000 <int-e> aha! let me rephrase those...
2026-05-25 17:48:07 +0000 <tomsmeding> because those two formulations sound too close in meaning to me :p
2026-05-25 17:48:53 +0000 <int-e> tomsmeding: https://paste.tomsmeding.com/IjEujBEA
2026-05-25 17:49:53 +0000 <tomsmeding> ah! There we go
2026-05-25 17:50:06 +0000 <int-e> it was clearer in my head ;)
2026-05-25 17:50:18 +0000 <tomsmeding> this stuff is way too subtle
2026-05-25 17:50:37 +0000sm__(~sm@2601:644:8280:ec80:f80f:4c71:49ff:3397)
2026-05-25 17:50:40 +0000tomsmedingis afk for a while
2026-05-25 17:55:36 +0000ricardomaps(~ricardoma@179.154.171.223)
2026-05-25 17:55:43 +0000 <tomsmeding> (funny sidenote: ARMv7 allowed this behaviour; an early spec for ARMv8 also did, but it was considered too hard to reason about and actual silicon manufacturers didn't end up using the flexibility, so the ARMv8 spec was revised to require causality)
2026-05-25 17:55:56 +0000 <tomsmeding> (now actually afk)
2026-05-25 17:57:33 +0000sm__(~sm@2601:644:8280:ec80:f80f:4c71:49ff:3397) (Quit: sm__)
2026-05-25 17:58:02 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 17:59:04 +0000Eoco(~ian@128.101.131.218) Eoco
2026-05-25 18:02:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 18:08:58 +0000 <int-e> tomsmeding: It's a bit more complicated than the basic WRC example because in the GHC runtime reading old values is generally okay. So to actually cause trouble it has to read not-yet-propagated ("future") values instead.
2026-05-25 18:09:29 +0000emilym(~Thunderbi@user/emilym) (Ping timeout: 245 seconds)
2026-05-25 18:11:35 +0000sm__(~sm@2601:644:8280:ec80:c9b:ab8c:3e8e:da44)
2026-05-25 18:12:42 +0000sm__(~sm@2601:644:8280:ec80:c9b:ab8c:3e8e:da44) (Client Quit)
2026-05-25 18:13:34 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 18:18:16 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2026-05-25 18:19:58 +0000Raito_Bezarius(~Raito@libera/contributor/wireguard.tunneler.raito-bezarius) Raito_Bezarius
2026-05-25 18:20:09 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 18:20:50 +0000sm__(~sm@2601:644:8280:ec80:10de:e505:94cc:fb5a)
2026-05-25 18:24:24 +0000sm__(~sm@2601:644:8280:ec80:10de:e505:94cc:fb5a) (Client Quit)
2026-05-25 18:29:24 +0000merijn(~merijn@62.45.136.136) merijn
2026-05-25 18:30:38 +0000Pozyomka(~pyon@user/pyon) (Quit: brb)
2026-05-25 18:33:23 +0000Pozyomka(~pyon@user/pyon) pyon
2026-05-25 18:35:44 +0000Jacqueline__(uid751191@id-751191.helmsley.irccloud.com)
2026-05-25 18:36:09 +0000merijn(~merijn@62.45.136.136) (Ping timeout: 252 seconds)
2026-05-25 18:41:17 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2026-05-25 18:43:30 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Excess Flood)
2026-05-25 18:43:31 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 264 seconds)
2026-05-25 18:46:10 +0000gmg(~user@user/gehmehgeh) (Ping timeout: 252 seconds)
2026-05-25 18:47:24 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 18:48:19 +0000terrorjack(~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat)
2026-05-25 18:48:27 +0000gmg(~user@user/gehmehgeh) gehmehgeh
2026-05-25 18:50:42 +0000vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2026-05-25 18:51:53 +0000terrorjack(~terrorjac@2a01:4f8:271:2d98::2) terrorjack
2026-05-25 18:51:53 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2026-05-25 18:58:32 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline
2026-05-25 19:02:48 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 19:08:07 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2026-05-25 19:09:25 +0000finsternis(~X@23.226.237.192) finsternis
2026-05-25 19:17:39 +0000spew(~spew@user/spew) (Ping timeout: 244 seconds)
2026-05-25 19:18:24 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2026-05-25 19:18:36 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 19:20:01 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Excess Flood)
2026-05-25 19:23:24 +0000Sgeo(~Sgeo@user/sgeo) Sgeo
2026-05-25 19:23:25 +0000target_i(~target_i@user/target-i/x-6023099) target_i
2026-05-25 19:23:38 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2026-05-25 19:25:03 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2026-05-25 19:27:45 +0000prdak(~Thunderbi@user/prdak) (Ping timeout: 242 seconds)
2026-05-25 19:34:22 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn
2026-05-25 19:35:59 +0000Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Excess Flood)
2026-05-25 19:39:01 +0000merijn(~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2026-05-25 19:45:19 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 264 seconds)
2026-05-25 19:46:15 +0000Inline(~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline