| 2026-06-08 00:04:29 +0000 | acidjnk | (~acidjnk@p200300d6e700e50741512d8f957d2df5.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-08 00:05:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:10:16 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 245 seconds) |
| 2026-06-08 00:10:17 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 00:21:20 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:26:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 00:27:39 +0000 | _\_ | (~o@user/offon) (Quit: ___) |
| 2026-06-08 00:28:06 +0000 | _\_ | (~o@user/offon) offon |
| 2026-06-08 00:37:08 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:37:58 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-06-08 00:41:51 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 00:52:53 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 00:57:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2026-06-08 01:10:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 01:15:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 253 seconds) |
| 2026-06-08 01:26:22 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 01:29:40 +0000 | fgarcia | (~lei@user/fgarcia) (Ping timeout: 252 seconds) |
| 2026-06-08 01:33:07 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 01:35:32 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-08 01:36:07 +0000 | rainbyte | (~rainbyte@181.47.219.31) (Read error: Connection reset by peer) |
| 2026-06-08 01:37:09 +0000 | rainbyte | (~rainbyte@181.47.219.31) rainbyte |
| 2026-06-08 01:40:02 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 248 seconds) |
| 2026-06-08 01:44:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 01:49:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 267 seconds) |
| 2026-06-08 01:50:10 +0000 | fgarcia | (~lei@user/fgarcia) fgarcia |
| 2026-06-08 01:59:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:04:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 02:09:30 +0000 | td_ | (~td@i5387090E.versanet.de) (Ping timeout: 241 seconds) |
| 2026-06-08 02:11:42 +0000 | td_ | (~td@i53870937.versanet.de) |
| 2026-06-08 02:15:47 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:16:44 +0000 | karenw | (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
| 2026-06-08 02:19:01 +0000 | rekahsoft | (~rekahsoft@70.51.99.119) rekahsoft |
| 2026-06-08 02:21:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 259 seconds) |
| 2026-06-08 02:31:35 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:35:48 +0000 | wickedjargon | (~user@2605:8d80:8100:486:a645:88dd:2cda:7f4) wickedjargon |
| 2026-06-08 02:36:39 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-08 02:47:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 02:52:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-08 02:52:46 +0000 | ricardomaps | (~ricardoma@2804:14d:a040:81ea:3035:8c54:ee2a:4632) (Quit: ricardomaps) |
| 2026-06-08 03:02:17 +0000 | rekahsoft | (~rekahsoft@70.51.99.119) (Remote host closed the connection) |
| 2026-06-08 03:03:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:10:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 03:10:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:15:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 03:23:30 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 248 seconds) |
| 2026-06-08 03:26:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:26:54 +0000 | Guest56 | (~Guest56@2601:645:8101:ead:1598:8824:ff53:79f0) |
| 2026-06-08 03:31:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 03:35:33 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 03:42:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 03:46:38 +0000 | wickedjargon | (~user@2605:8d80:8100:486:a645:88dd:2cda:7f4) (Remote host closed the connection) |
| 2026-06-08 03:47:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 03:58:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 04:03:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-06-08 04:08:50 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-08 04:09:05 +0000 | Guest56 | (~Guest56@2601:645:8101:ead:1598:8824:ff53:79f0) (Quit: Client closed) |
| 2026-06-08 04:14:37 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 04:19:19 +0000 | misterfish | (~misterfis@178.230.150.156) (Ping timeout: 272 seconds) |
| 2026-06-08 04:19:22 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 242 seconds) |
| 2026-06-08 04:26:39 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 252 seconds) |
| 2026-06-08 04:30:13 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-08 04:30:23 +0000 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 242 seconds) |
| 2026-06-08 04:34:54 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-08 04:37:32 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-06-08 04:45:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 04:52:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 04:54:17 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-06-08 04:58:13 +0000 | zalo-rocky | (~flyingzal@186.19.88.142) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-08 05:02:13 +0000 | michalz | (~michalz@185.246.207.221) |
| 2026-06-08 05:02:27 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-08 05:03:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:06:35 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 05:09:12 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-06-08 05:11:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:17:20 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-08 05:25:50 +0000 | fp1 | (~Thunderbi@wireless-86-50-141-161.open.aalto.fi) fp |
| 2026-06-08 05:27:39 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:31:33 +0000 | Axma32385 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 05:33:13 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-08 05:33:25 +0000 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 245 seconds) |
| 2026-06-08 05:34:05 +0000 | Axma32385 | Axman6 |
| 2026-06-08 05:37:53 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) Enrico63 |
| 2026-06-08 05:39:50 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 05:42:37 +0000 | djspacewhale | (~djspacewh@user/djspacewhale) djspacewhale |
| 2026-06-08 05:42:55 +0000 | djspacewhale | (~djspacewh@user/djspacewhale) (Remote host closed the connection) |
| 2026-06-08 05:43:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 05:46:06 +0000 | fp1 | (~Thunderbi@wireless-86-50-141-161.open.aalto.fi) (Ping timeout: 241 seconds) |
| 2026-06-08 05:48:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-08 05:49:42 +0000 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-06-08 05:55:50 +0000 | Square | (~Square4@user/square) Square |
| 2026-06-08 05:56:13 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2026-06-08 05:59:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:00:36 +0000 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-06-08 06:03:56 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 251 seconds) |
| 2026-06-08 06:12:49 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-08 06:12:52 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:16:15 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Client Quit) |
| 2026-06-08 06:17:30 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-08 06:21:40 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-08 06:26:34 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-06-08 06:28:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:35:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 259 seconds) |
| 2026-06-08 06:39:55 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) (Quit: Client closed) |
| 2026-06-08 06:40:31 +0000 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2026-06-08 06:40:49 +0000 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2026-06-08 06:46:53 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 06:51:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-08 07:02:35 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 07:04:14 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 256 seconds) |
| 2026-06-08 07:04:22 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-06-08 07:07:55 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
| 2026-06-08 07:07:58 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-08 07:09:53 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-08 07:13:05 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-08 07:13:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 07:15:10 +0000 | krei-se | (~krei-se@p5098b7b3.dip0.t-ipconnect.de) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2026-06-08 07:17:45 +0000 | krei-se | (~krei-se@photonen.krei.se) krei-se |
| 2026-06-08 07:18:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-08 07:18:47 +0000 | APic | (apic@chiptune.apic.name) (Ping timeout: 244 seconds) |
| 2026-06-08 07:18:54 +0000 | danza | (~danza@user/danza) danza |
| 2026-06-08 07:29:13 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-08 07:33:55 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-06-08 07:35:37 +0000 | APic | (apic@chiptune.apic.name) APic |
| 2026-06-08 07:35:38 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-08 07:40:06 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) (Ping timeout: 246 seconds) |
| 2026-06-08 07:40:37 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 276 seconds) |
| 2026-06-08 07:46:12 +0000 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-06-08 07:55:08 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 07:57:20 +0000 | p3n | (~p3n@217.198.124.246) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-06-08 07:58:07 +0000 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) p3n |
| 2026-06-08 08:00:43 +0000 | danza | (~danza@user/danza) (Ping timeout: 252 seconds) |
| 2026-06-08 08:04:34 +0000 | hc_ | (~hc@mail.hce.li) hc |
| 2026-06-08 08:06:39 +0000 | hc | (~hc@mail.hce.li) (Ping timeout: 252 seconds) |
| 2026-06-08 08:09:28 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-08 08:11:14 +0000 | bandola | (~bandola@c-5eea527c-74736162.cust.telenor.se) |
| 2026-06-08 08:14:57 +0000 | bandola | (~bandola@c-5eea527c-74736162.cust.telenor.se) (Changing host) |
| 2026-06-08 08:14:57 +0000 | bandola | (~bandola@user/bandola) bandola |
| 2026-06-08 08:15:48 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2026-06-08 08:15:48 +0000 | Freakie | (~Freakie@185.45.21.144) |
| 2026-06-08 08:17:19 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-08 08:21:41 +0000 | hc_ | hc |
| 2026-06-08 08:22:00 +0000 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 2026-06-08 08:27:40 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-06-08 08:28:23 +0000 | ft | (~ft@p508db0ab.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-06-08 08:37:16 +0000 | <Freakie> | does anyone know where I can find some resources on how major garbage collections are triggered? |
| 2026-06-08 08:45:46 +0000 | vivaldi` | (~ident@user/blackbox) (Quit: vivaldi`) |
| 2026-06-08 08:51:21 +0000 | Digit | (~user@user/digit) (Ping timeout: 248 seconds) |
| 2026-06-08 08:51:30 +0000 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-06-08 08:56:24 +0000 | <merijn> | Freakie: GHC wiki, this https://ezyang.com/jfp-ghc-rts-draft.pdf, and maybe the GHC manual? |
| 2026-06-08 08:57:23 +0000 | <Freakie> | I'll have a look but the places I looked only mentioned as a result of heap overflow, but that doesn't really align with how I understand my experiments to work |
| 2026-06-08 08:59:18 +0000 | <merijn> | Heap overflow? I thought heap as unbounded, sound like you're straight up running the entire system out of memory? |
| 2026-06-08 09:01:15 +0000 | Axma40140 | (~Axman6@user/axman6) Axman6 |
| 2026-06-08 09:04:00 +0000 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 277 seconds) |
| 2026-06-08 09:10:46 +0000 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-06-08 09:11:01 +0000 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2026-06-08 09:11:20 +0000 | Digitteknohippie | Digit |
| 2026-06-08 09:12:22 +0000 | <Freakie> | overflow in the sense that the program needs to allocate more |
| 2026-06-08 09:12:31 +0000 | <tomsmeding> | more than what? |
| 2026-06-08 09:13:11 +0000 | <tomsmeding> | (What is the underlying reason why you want to know about this?) |
| 2026-06-08 09:15:42 +0000 | bandola | (~bandola@user/bandola) (Ping timeout: 256 seconds) |
| 2026-06-08 09:16:07 +0000 | bandola | (~bandola@c-5eea53c4-74736162.cust.telenor.se) |
| 2026-06-08 09:18:38 +0000 | <tomsmeding> | ok the user guide also speaks of "heap overflow" https://downloads.haskell.org/ghc/latest/docs/users_guide/hints.html#understanding-how-os-memory-u… |
| 2026-06-08 09:19:46 +0000 | <Freakie> | the runtime still needs to request memory from the OS whenever it runs out of addressable space |
| 2026-06-08 09:19:59 +0000 | <Freakie> | that's what I mean by overflow |
| 2026-06-08 09:20:08 +0000 | <Freakie> | as far as I understand it was one of the things that triggered major GC |
| 2026-06-08 09:20:08 +0000 | <tomsmeding> | right |
| 2026-06-08 09:20:47 +0000 | <Freakie> | anyway I'm running an experiment on an implementation where I use 4 MiB for the nursery size, and 32 MiB |
| 2026-06-08 09:21:11 +0000 | <Freakie> | the expectation is (and holds) that higher nursery size gives better performance with what I'm doing but it turns out to only be because higher nursery size correlates with fewer major garbage collections |
| 2026-06-08 09:21:16 +0000 | <Freakie> | which is the part I'm trying to understand why |
| 2026-06-08 09:21:29 +0000 | <tomsmeding> | well, GC takes time |
| 2026-06-08 09:21:47 +0000 | <Freakie> | yes but that's not what's making the difference in my prgoram |
| 2026-06-08 09:22:44 +0000 | <tomsmeding> | GC is O(live data); if you consistently allocate stuff but have a constant-size live data set, then a GC pass will consist of "iterate over your live data and forget all else". Then doing GC fewer times will use more peak memory but spend less time. |
| 2026-06-08 09:23:12 +0000 | <tomsmeding> | the flip side is that spending more memory means less memory locality hence worse cache behaviour, potentially, though that depends very much on the sizes of everything involved |
| 2026-06-08 09:23:32 +0000 | <Freakie> | what I'm trying to say is that I don't know why having larger nurseries correlates to *performing* less major GC |
| 2026-06-08 09:23:45 +0000 | <Freakie> | because that shouldn't have any effect on the allocation throughput |
| 2026-06-08 09:24:01 +0000 | <tomsmeding> | GC runs when the nursery is exhausted |
| 2026-06-08 09:24:08 +0000 | <tomsmeding> | I'm not sure whether it's minor or major, but GC definitely runs |
| 2026-06-08 09:24:11 +0000 | <Freakie> | isn't that only minor gc? |
| 2026-06-08 09:24:19 +0000 | <Freakie> | it should only be minor |
| 2026-06-08 09:28:17 +0000 | <Freakie> | but my point is that the exact triggers for major GC seems quite opaque to me beyond doing it when the program needs to move the heap anyway (i.e. allocate more from the OS) |
| 2026-06-08 09:30:00 +0000 | <tomsmeding> | Freakie: the entry points to GC seem to mostly be in rts/Schedule.c, in calls to scheduleDoGC() |
| 2026-06-08 09:30:13 +0000 | <tomsmeding> | there's one when threads seem to be deadlocked, for example (scheduleDetectDeadlock()) |
| 2026-06-08 09:31:56 +0000 | <merijn> | nurseries only trigger minor GC (i.e. only on the nursery, I think?) |
| 2026-06-08 09:32:09 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 261 seconds) |
| 2026-06-08 09:32:31 +0000 | <merijn> | One obvious reasons for "bigger nursery == less major GC" is that bigger nurseries don't fill up as fast, so stuff isn't aging out of it so fast |
| 2026-06-08 09:32:49 +0000 | <merijn> | If data never leaves the nursery than a major GC won't ever be needed |
| 2026-06-08 09:33:38 +0000 | chele | (~chele@user/chele) chele |
| 2026-06-08 09:34:43 +0000 | <merijn> | Freakie: if the lifetime of your data was *slightly* longer than the time it stayed in the nursery. i.e. it dies very soon AFTER leaving the nursery that's, like, worst case scenario |
| 2026-06-08 09:34:49 +0000 | acidjnk | (~acidjnk@p200300d6e700e514a755b21df9febc31.dip0.t-ipconnect.de) acidjnk |
| 2026-06-08 09:35:25 +0000 | <merijn> | Because then it graduates out of the nursery and immediately dies, requiring a major GC to get rid off it |
| 2026-06-08 09:35:29 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 09:35:46 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 09:35:55 +0000 | <merijn> | If bigger nursery causes it to stay in the nursery longer and die there **before** leaving the nursery, then you never need a major GC to get rid of it |
| 2026-06-08 09:36:16 +0000 | <merijn> | So in that sense it seems very obvious that bigger nursery correlates with fewer major GC |
| 2026-06-08 09:36:18 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) (Ping timeout: 246 seconds) |
| 2026-06-08 09:36:33 +0000 | <merijn> | At least for some workflows |
| 2026-06-08 09:43:10 +0000 | <Freakie> | nurseries are only garbage collected once full, right? remove the dead data and push the rest to gen 0 |
| 2026-06-08 09:43:46 +0000 | <Freakie> | at any rate evicting the nursery shouldn't require a major GC because it gets pushed to gen 0, while major GC only works on the oldest generation (as far as I've been able to infer) |
| 2026-06-08 09:48:56 +0000 | <merijn> | major GC works on everything afaik? |
| 2026-06-08 09:49:04 +0000 | <merijn> | It makes no sense to only work on the oldest generation |
| 2026-06-08 09:49:33 +0000 | <merijn> | Freakie: Right, but if the entire nursery is dead by the time you GC, then nothing graduates to gen 0 |
| 2026-06-08 09:50:23 +0000 | <merijn> | Growing the nursery makes it last longer until it's full, which means there's more time for nursery data to die before graduating |
| 2026-06-08 09:50:59 +0000 | <Freakie> | oh you mean |
| 2026-06-08 09:53:17 +0000 | <Freakie> | just because more gets cleaned up by the time it's pushed to gen 0, the older generations will take up less space on the heap and therefore require fewer allocations from the OS? (which would trigger major gc) |
| 2026-06-08 09:53:30 +0000 | <Freakie> | less space on average* |
| 2026-06-08 09:58:53 +0000 | <Freakie> | at any rate I did finally find a paper describing the GC triggers in detail, so I guess there is that |
| 2026-06-08 10:05:05 +0000 | Axma40140 | (~Axman6@user/axman6) (Ping timeout: 245 seconds) |
| 2026-06-08 10:18:09 +0000 | <tomsmeding> | Freakie: right, assuming most data has a finite lifetime, larger nursery means less data gets promoted to gen 0 at each minor GC, so gen 0 grows more slowly, so gen 0 overflow triggers major GC less often |
| 2026-06-08 10:18:58 +0000 | <tomsmeding> | the extent to which this effect exists, depends on the distribution of lifetimes of your live data |
| 2026-06-08 10:21:27 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-08 10:21:59 +0000 | misterfish | (~misterfis@178.230.99.247) misterfish |
| 2026-06-08 10:23:27 +0000 | <Freakie> | only downside to this is that it's completely tangential to my hypothesis but oh well |
| 2026-06-08 10:23:55 +0000 | vivaldi` | (~ident@user/blackbox) blackbox |
| 2026-06-08 10:24:09 +0000 | <Freakie> | most of my live data is gated behind compacts which are treated as write-only data so that explains a lot honestly |
| 2026-06-08 10:24:37 +0000 | <vivaldi`> | hello haskellians! |
| 2026-06-08 10:25:01 +0000 | <vivaldi`> | I don't do haskell. should I try it? |
| 2026-06-08 10:26:10 +0000 | <Freakie> | depends on your needs/interests I think |
| 2026-06-08 10:27:29 +0000 | <vivaldi`> | could be fun to learn :) |
| 2026-06-08 10:28:13 +0000 | <Freakie> | if you already have programming experience it's never a bad idea to learn something new |
| 2026-06-08 10:28:14 +0000 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) (Ping timeout: 256 seconds) |
| 2026-06-08 10:31:11 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-08 10:38:49 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 10:39:09 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 10:40:08 +0000 | picnoir | (~picnoir@about/aquilenet/vodoo/NinjaTrappeur) NinjaTrappeur |
| 2026-06-08 10:41:29 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-08 10:41:30 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-08 10:41:30 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-08 10:50:40 +0000 | glguy | (glguy@libera/staff/glguy) (Read error: Connection reset by peer) |
| 2026-06-08 10:51:04 +0000 | glguy | (glguy@libera/staff/glguy) glguy |
| 2026-06-08 10:56:04 +0000 | xstill_ | (xstill@fimu/xstill) xstill |
| 2026-06-08 10:56:18 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2026-06-08 10:58:52 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Quit: KVIrc 5.2.8 Quasar http://www.kvirc.net/) |
| 2026-06-08 10:59:21 +0000 | misterfish | (~misterfis@178.230.99.247) (Ping timeout: 252 seconds) |
| 2026-06-08 11:01:43 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 11:06:30 +0000 | Square2 | (~Square@user/square) Square |
| 2026-06-08 11:07:29 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 11:07:46 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 11:09:38 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) Enrico63 |
| 2026-06-08 11:19:37 +0000 | cipherrot | (~jez@user/petrichor) (Ping timeout: 248 seconds) |
| 2026-06-08 11:20:24 +0000 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2026-06-08 11:20:31 +0000 | petrichor | (~jez@user/petrichor) petrichor |
| 2026-06-08 11:24:36 +0000 | comerijn | (~merijn@77.242.116.150) merijn |
| 2026-06-08 11:26:02 +0000 | Freakie | (~Freakie@185.45.21.144) (Ping timeout: 245 seconds) |
| 2026-06-08 11:27:24 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 253 seconds) |
| 2026-06-08 11:27:24 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 253 seconds) |
| 2026-06-08 11:28:32 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) (Ping timeout: 245 seconds) |
| 2026-06-08 11:28:38 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-08 11:36:36 +0000 | Square2 | (~Square@user/square) (Ping timeout: 244 seconds) |
| 2026-06-08 11:41:45 +0000 | caryhartline | (~caryhartl@159.26.119.68) (Read error: Connection reset by peer) |
| 2026-06-08 11:47:53 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-08 11:50:58 +0000 | comerijn | (~merijn@77.242.116.150) (Ping timeout: 256 seconds) |
| 2026-06-08 11:59:50 +0000 | xnyhps__ | (~xnyhps@s.xnyhps.nl) (Remote host closed the connection) |
| 2026-06-08 12:00:05 +0000 | xnyhps_ | (~xnyhps@s.xnyhps.nl) |
| 2026-06-08 12:05:13 +0000 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-06-08 12:07:40 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 252 seconds) |
| 2026-06-08 12:07:59 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
| 2026-06-08 12:08:55 +0000 | CiaoSen | (~Jura@2a02:3035:bec:2995:4e50:ddff:fe9b:8922) (Ping timeout: 245 seconds) |
| 2026-06-08 12:09:43 +0000 | xnyhps_ | (~xnyhps@s.xnyhps.nl) (Ping timeout: 276 seconds) |
| 2026-06-08 12:10:17 +0000 | xnyhps | (~xnyhps@s.xnyhps.nl) |
| 2026-06-08 12:11:40 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-08 12:11:41 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-08 12:11:41 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-08 12:22:15 +0000 | haritz | (~hrtz@140.228.70.141) |
| 2026-06-08 12:22:16 +0000 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2026-06-08 12:22:16 +0000 | haritz | (~hrtz@user/haritz) haritz |
| 2026-06-08 12:24:30 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-06-08 12:32:24 +0000 | ouilemur | (~jgmerritt@user/ouilemur) (Ping timeout: 245 seconds) |
| 2026-06-08 12:33:54 +0000 | user363627 | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2026-06-08 12:34:13 +0000 | user363627 | (~user@user/user363627) user363627 |
| 2026-06-08 12:37:46 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 245 seconds) |
| 2026-06-08 12:39:08 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) Enrico63 |
| 2026-06-08 12:45:57 +0000 | xff0x | (~xff0x@ai070051.d.east.v6connect.net) |
| 2026-06-08 12:47:00 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) (Quit: Client closed) |
| 2026-06-08 12:47:27 +0000 | Freakie | (~Freakie@185.45.21.144) |
| 2026-06-08 12:48:16 +0000 | <yin> | i think i finally surrendered to StrictData |
| 2026-06-08 12:53:52 +0000 | Googulator | (~Googulato@94-21-172-222.pool.digikabel.hu) |
| 2026-06-08 12:56:42 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-08 12:57:00 +0000 | user363627 | (~user@user/user363627) (Ping timeout: 268 seconds) |
| 2026-06-08 12:58:18 +0000 | <janus> | in the STGi, is evaluation always to normal form? |
| 2026-06-08 12:58:45 +0000 | <janus> | i am wondering why it starts out with 'Eval main' and then evaluates 'add 1# 2#' all the way to '3#' |
| 2026-06-08 13:01:13 +0000 | <janus> | i suppose i am just wondering why, in a pure lazy language, there needs to be a difference between Case and Eval |
| 2026-06-08 13:02:44 +0000 | <janus> | i've seen that that Case always only matches on the outer level, so if main is an Int#, i suppose it has to get evaluated to 3# because anything else wouldn't be a constructor of Int# |
| 2026-06-08 13:08:54 +0000 | <janus> | maybe 'main' is a bit different in STGi in that it can be evaluated to WHNF while in Haskell i don't even know if it makes sense to talk about WHNF of 'IO ()' |
| 2026-06-08 13:12:14 +0000 | <ski> | `return undefined' is different from `undefined' |
| 2026-06-08 13:12:35 +0000 | <ski> | (also, `main' has type `IO a', for any `a' you like) |
| 2026-06-08 13:15:22 +0000 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-06-08 13:15:40 +0000 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-06-08 13:17:35 +0000 | DetourNe- | DetourNetworkUK |
| 2026-06-08 13:21:49 +0000 | <janus> | hmm, so I suppose main with type `IO a` is evaluated until the last `pure`, but that `a` is not necessarily evaluated. Because I can do `pure undefined` without having it crash at runtime |
| 2026-06-08 13:22:50 +0000 | <janus> | This also shows the difference with simply `undefined` at the end since that _does_ crash |
| 2026-06-08 13:24:32 +0000 | <janus> | Right ok. So since STGi doesn't have any special monad handling, it has to teach main differently. And it just decides to evaluates main to WHNF even though that is not applicable to GHC's main |
| 2026-06-08 13:25:37 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-06-08 13:27:07 +0000 | <janus> | s/teach/handle/ |
| 2026-06-08 13:27:44 +0000 | rekahsoft | (~rekahsoft@2605:8d80:1520:40b8:7f13:d56c:3912:7b7a) rekahsoft |
| 2026-06-08 13:31:49 +0000 | __monty__ | (~toonn@user/toonn) (Ping timeout: 244 seconds) |
| 2026-06-08 13:34:01 +0000 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-06-08 13:38:43 +0000 | TwinAdam | (~TwinAdam@user/adamsaunders) (Ping timeout: 264 seconds) |
| 2026-06-08 13:39:59 +0000 | <janus> | oh, the readme does say "Note that the WHNF part makes case strict, and indeed it is the only construct that does evaluation." |
| 2026-06-08 13:39:59 +0000 | TwinAdam | (~TwinAdam@user/adamsaunders) adamsaunders |
| 2026-06-08 13:41:07 +0000 | <janus> | probably not entirely true because as written, main is also evaluted even though it has no case |
| 2026-06-08 13:45:21 +0000 | ouilemur | (~jgmerritt@user/ouilemur) ouilemur |
| 2026-06-08 13:47:06 +0000 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2026-06-08 13:52:15 +0000 | xff0x | (~xff0x@ai070051.d.east.v6connect.net) (Quit: xff0x) |
| 2026-06-08 13:52:43 +0000 | <comerijn> | janus: The evaluation of main is (conceptually) external to your code, though |
| 2026-06-08 13:52:57 +0000 | <comerijn> | i.e., that's the RTS' purview which is not constrained by the language definition |
| 2026-06-08 13:57:21 +0000 | <comerijn> | janus: At the STG level `IO a` is just a function `RealWorld# -> (a, RealWorld#)` (where `RealWorld#` is a builtin in the compiler) |
| 2026-06-08 13:57:46 +0000 | <comerijn> | janus: So at the STG level running IO/main is just a matter of "pass an argument, force the resulting tuple" |
| 2026-06-08 14:02:20 +0000 | <janus> | comerijn: ok, and 'pure' corresponds to the tuple constructor? because it crashes if the tuple is undefined, but it doesn't crash if the 'a' is undefined... |
| 2026-06-08 14:03:31 +0000 | <janus> | i suppose i could make an STGi program with a tuple construction, and then it shouldn't ever evaluated the 'a' thunk |
| 2026-06-08 14:07:05 +0000 | rekahsoft | (~rekahsoft@2605:8d80:1520:40b8:7f13:d56c:3912:7b7a) (Ping timeout: 248 seconds) |
| 2026-06-08 14:08:49 +0000 | ystael | (~ystael@user/ystael) ystael |
| 2026-06-08 14:10:40 +0000 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) epolanski |
| 2026-06-08 14:11:00 +0000 | <ski> | janus : "is evaluated until the last `pure`" -- not really. it would also stop at a `(>>=)' |
| 2026-06-08 14:12:15 +0000 | xff0x | (~xff0x@2405:6580:b080:900:7bda:8dd9:d259:e21b) |
| 2026-06-08 14:17:11 +0000 | gehmehgeh | (~user@user/gehmehgeh) gehmehgeh |
| 2026-06-08 14:19:01 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 245 seconds) |
| 2026-06-08 14:20:06 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-06-08 14:20:34 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-08 14:23:38 +0000 | gehmehgeh | gmg |
| 2026-06-08 14:24:29 +0000 | xff0x | (~xff0x@2405:6580:b080:900:7bda:8dd9:d259:e21b) (Ping timeout: 245 seconds) |
| 2026-06-08 14:25:36 +0000 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-06-08 14:25:49 +0000 | <janus> | ski: how would it ever get beyond the first line of the 'do' notation the 'main' definition if it stops at the first >>=? |
| 2026-06-08 14:26:00 +0000 | <janus> | if i do echo -e 'import Debug.Trace ; main = traceM "hi" >>= \() -> pure undefined' > /tmp/B.hs |
| 2026-06-08 14:26:13 +0000 | <janus> | and i run that program, i see "hi" but no exception |
| 2026-06-08 14:27:09 +0000 | <ski> | janus : after evaluation to WHNF, it executes the resulting `IO'-action, which may in turn trigger further execution (and dependent evaluation) |
| 2026-06-08 14:27:45 +0000 | <ski> | and yea, the monadic result value of `main' is ignored, so that `undefined' is never evaluated |
| 2026-06-08 14:29:56 +0000 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2026-06-08 14:29:58 +0000 | CloneOfNone | (~CloneOfNo@user/CloneOfNone) CloneOfNone |
| 2026-06-08 14:30:12 +0000 | weary-traveler | (~user@user/user363627) user363627 |
| 2026-06-08 14:30:52 +0000 | CloneOfNone_ | (~CloneOfNo@user/CloneOfNone) (Ping timeout: 265 seconds) |
| 2026-06-08 14:32:31 +0000 | <probie> | janus: Try `traceM "hi" >>= \() -> pure undefined >>= \() -> pure ()` |
| 2026-06-08 14:33:14 +0000 | <janus> | probie: it should crash because you're matching on the unit no? |
| 2026-06-08 14:34:19 +0000 | <probie> | Correct, but ignore me. I wrote my response before scrolling up to read the earlier conversation and it's therefore irrelevant |
| 2026-06-08 14:34:20 +0000 | <janus> | ah right, if i replace the second unit with _, there is no crash |
| 2026-06-08 14:37:28 +0000 | stephend | (~stephend@2a06:61c1:77fc:0:9b71:2db5:cdef:4eb2) |
| 2026-06-08 14:37:39 +0000 | <janus> | ski: i wonder if i am missing something, because for me, 'evaluating to the last pure' and 'evaluating to >>= and then repeating' seem equivalent. because there are no ways to contruct IO |
| 2026-06-08 14:37:39 +0000 | stephend | (~stephend@2a06:61c1:77fc:0:9b71:2db5:cdef:4eb2) () |
| 2026-06-08 14:37:41 +0000 | bandola | (~bandola@c-5eea53c4-74736162.cust.telenor.se) (Remote host closed the connection) |
| 2026-06-08 14:45:35 +0000 | <probie> | janus: You can construct IO (in GHC Haskell). https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-IO.html#t:IO |
| 2026-06-08 14:46:59 +0000 | <lortabac> | it depends what you mean by "you can" |
| 2026-06-08 14:47:16 +0000 | <lortabac> | technically yes, but that module is not meant to be used directly |
| 2026-06-08 14:57:55 +0000 | tv | (~tv@user/tv) (Ping timeout: 264 seconds) |
| 2026-06-08 14:58:24 +0000 | tv | (~tv@user/tv) tv |
| 2026-06-08 15:01:51 +0000 | <ski> | janus : "evaluating to the last pure" surely can't mean get to the `pure' in `getLine >>= \s -> pure (reverse s)', because you need to execute to get to that, not just evaluate |
| 2026-06-08 15:02:25 +0000 | <ski> | "there are no ways to contruct IO" -- `getLine',`pure',`(>>=)',.. |
| 2026-06-08 15:03:21 +0000 | <janus> | right ok |
| 2026-06-08 15:05:19 +0000 | tremon | (~tremon@83-80-159-219.cable.dynamic.v4.ziggo.nl) tremon |
| 2026-06-08 15:05:52 +0000 | <probie> | lortabac: You can use it to come up with a "better" IO type, `newtype IO a = IO (State# RealWorld ⊸ (# State# RealWorld, a #))` |
| 2026-06-08 15:06:35 +0000 | <probie> | Whatever happened to linear types in Haskell? I've heard pretty much nothing in that space for the past few years |
| 2026-06-08 15:06:50 +0000 | <ski> | janus : you could try doing `data MyIO a = Pure a | BindOpenFile FilePath IOMode (Handle -> MyIO a) | BindHGetChar Handle (Char -> MyIO a) | BindHPutChar Handle Char (MyIO a) | ...', and then make a `runMyIO :: MyIO a -> IO a' (and also `Monad' instance) |
| 2026-06-08 15:08:35 +0000 | <ski> | or, using `GADTs', `data MyIO :: * -> * where Pure :: a -> MyIO a; Bind :: MyIO a -> (a -> MyIO b) -> MyIO b; OpenFile :: FilePath -> IOMode -> MyIO Handle; HGetChar :: Handle -> MyIO Char; HPutChar :: Handle -> Char -> MyIO (); ...' if you prefer |
| 2026-06-08 15:09:41 +0000 | <ski> | it would also be possible to rename the former into `IOProgram', remove the `Pure' constructor, and then define `MyIO a' as `(a -> IOProgram) -> IOProgram' (aka `Cont IOProgram a)' |
| 2026-06-08 15:11:38 +0000 | <ski> | .. then there's also the old dialogue-style request&response I/O model, which you could define and translate to standard `IO' in a similar fashion, to get a feel for how it worked |
| 2026-06-08 15:12:15 +0000 | <ski> | (which was how I/O was done, in Haskell, before monads were introduced) |
| 2026-06-08 15:15:03 +0000 | <ski> | "execute" an `m'-action of type `m a', means roughly to "interact with your context" (whatever that means, depends on which `m' we have), in order to end up with the "monadic result" of type `a'. in some cases there may be no `a' value, or there may be several, and there may also be other effects happening (reading or modifying state, reading environment, aborting with an exception, &c.) |
| 2026-06-08 15:17:08 +0000 | <ski> | the RTS knows how to execute `IO'-actions, which is what we were talking about here. it also knows how to evaluate expressions to WHNF. these two processes are interleaved. we first evaluate `main' in order to see what subaction (I/O operation) we should first perform, which is then executed, then we evaluate the next part of the `(>>=)'. execution may trigger evaluation, but evaluation may not trigger |
| 2026-06-08 15:17:14 +0000 | <ski> | execution (with the exception of some low-level unsafe magic primitives) |
| 2026-06-08 15:24:32 +0000 | <comerijn> | janus: Keep in mind that we have two meta-levels: evaluation (this refers to Haskell expression being evaluated) and execution (i.e. running side-effectful IO) |
| 2026-06-08 15:25:18 +0000 | <comerijn> | Only the former is observable from within Haskell code, execution is not observable (well, not without extreme hacks) from within Haskell |
| 2026-06-08 15:26:28 +0000 | <comerijn> | execution is "running the side-effectful IO resulting from evaluation of a Haskell program" and is only done by the RTS, via "magic implementation details the compiler and RTS agree on" |
| 2026-06-08 15:27:58 +0000 | <comerijn> | janus: Once we start talking about STG (or the code generated by GHC) these two are interleaved with each other and there's really no clear boundary at all, but at that point we're really no longer talking about "Haskell" and more "talking about implementation details of a Haskell implementation" and the "Haskell rules" no longer apply |
| 2026-06-08 15:29:31 +0000 | <tomsmeding> | comerijn: what do you mean with "execution is not observable"? If I write to a file, I can observe that by... reading that file. |
| 2026-06-08 15:29:50 +0000 | <janus> | ok that sounds good. it sounds like you can just compile unsafePerformIO to the identity function with STG |
| 2026-06-08 15:30:11 +0000 | <tomsmeding> | (and if you say: that's not observing, that's just asking the RTS to tell you -- well then you can't observe IO by definition so the point is moot) |
| 2026-06-08 15:30:20 +0000 | <janus> | and other IO actions could also just be regular functions |
| 2026-06-08 15:30:27 +0000 | <comerijn> | tomsmeding: Not observable within Haskell |
| 2026-06-08 15:30:41 +0000 | <comerijn> | tomsmeding: Reading the file is IO not Haskell evaluation |
| 2026-06-08 15:30:41 +0000 | <tomsmeding> | would it be observable within C? |
| 2026-06-08 15:31:00 +0000 | <tomsmeding> | is write(2) observable within C evaluation? |
| 2026-06-08 15:31:07 +0000 | <comerijn> | tomsmeding: C doesn't specify the behaviour of kernel calls, so 'mu' |
| 2026-06-08 15:31:21 +0000 | <janus> | everything turns really complicated because there is an idealized haskell and then there is the one we actually have where the CPU turns to dust if you compute too much :P |
| 2026-06-08 15:31:30 +0000 | <tomsmeding> | I feel like your definition of observable here is not very useful if nothing can ever observe that :p |
| 2026-06-08 15:31:49 +0000 | <comerijn> | tomsmeding: You cannot observe "I wrote to a file in Haskell", you can "use Haskell to write an IO that can observe I wrote to a file" |
| 2026-06-08 15:31:55 +0000 | <tomsmeding> | janus: https://hackage-content.haskell.org/package/bytestring-0.12.2.0/docs/src/Data.ByteString.Internal.… |
| 2026-06-08 15:32:23 +0000 | <tomsmeding> | comerijn: right, but I think you can replace "Haskell" with "$programming_language" and have the same statement |
| 2026-06-08 15:32:28 +0000 | <comerijn> | janus: I disagree, there's a Haskell spec that specifies how haskell code behaves. And there is an implementation of said spec |
| 2026-06-08 15:33:09 +0000 | <comerijn> | janus: The internals of said implementation are not required (and do not) adhere to the rules of the spec, as long as the bits "observable within Haskell" do |
| 2026-06-08 15:33:11 +0000 | <tomsmeding> | janus: the CPU that turns to dust is yet another layer here, where you may observe impossible things if you didn't seat your RAM sticks correctly :p |
| 2026-06-08 15:33:56 +0000 | <comerijn> | tomsmeding: The fact that it's true for any language with a spec is irrelevant to the point I'm trying to make |
| 2026-06-08 15:34:16 +0000 | <comerijn> | tomsmeding: My point is: You need to keep very clearly which meta level you're making statements on/about |
| 2026-06-08 15:34:29 +0000 | <tomsmeding> | I agree with that |
| 2026-06-08 15:34:38 +0000 | <comerijn> | Confusing meta-levels of your statements is a good way to get very confused when talking about "spec vs implementation" |
| 2026-06-08 15:35:22 +0000 | <comerijn> | janus: Did you read the STG paper yet? |
| 2026-06-08 15:35:53 +0000 | <tomsmeding> | ok I guess fine, I get your point now, although I might have said it slightly differently :p |
| 2026-06-08 15:36:07 +0000 | <comerijn> | tomsmeding: I'm open to clearer wording |
| 2026-06-08 15:36:28 +0000 | synchromesh | (~john@2406:5a00:247e:1500:407:f239:9ec7:d065) (Read error: Connection reset by peer) |
| 2026-06-08 15:36:52 +0000 | <janus> | comerijn: i am reading it. but i am a bit worried about all the later changes in the STG |
| 2026-06-08 15:37:20 +0000 | <janus> | now i am trying to understand the {} \u {} -> ... notation |
| 2026-06-08 15:37:47 +0000 | <comerijn> | janus: Why worried? |
| 2026-06-08 15:38:02 +0000 | <comerijn> | Whether those changes are relevant to you at all depends on what you're trying to accomplish |
| 2026-06-08 15:38:02 +0000 | synchromesh | (~john@2406:5a00:247e:1500:54ac:d0d8:80b:9ccf) synchromesh |
| 2026-06-08 15:38:30 +0000 | <comerijn> | Is it just "getting an idea of how Haskell executes on an x64-ish CPU" or something else |
| 2026-06-08 15:38:57 +0000 | <comerijn> | Because I don't think any of the changes to STG have ever been relevant to me in terms of programming Haskell |
| 2026-06-08 15:39:42 +0000 | <janus> | it's just for fun yeah |
| 2026-06-08 15:40:13 +0000 | <janus> | we don't worry much about stg or core at work because we just have a billion db roundtrips that take more time |
| 2026-06-08 15:40:29 +0000 | <comerijn> | janus: Then I wouldn't worry about any changes. Most of the changes are such technical niche things they don't really affect how you code much |
| 2026-06-08 15:41:41 +0000 | <dolio> | STG has two sorts of variables for a lambda. The first {...} lists variables that would be mentioned from closing over the local scope where it was originally defined, and the second is actual function arguments. |
| 2026-06-08 15:42:37 +0000 | <dolio> | This is useful when floating the lambda terms around. They are pre-built to be floated, rather than requiring some kind of transformation. |
| 2026-06-08 15:44:12 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2026-06-08 15:45:25 +0000 | <tomsmeding> | comerijn: hm, perhaps: there are two layers to the meaning (semantics) of a haskell program: "pure haskell" and "IO". "Pure haskell" defines what evaluation means, and in particular sees IO as just a newtype over a function, albeit taking an argument (RealWorld#) with special non-duplication rules. Typical IO functions like readFile are just externally provided such pure functions. The "IO" layer |
| 2026-06-08 15:45:27 +0000 | <tomsmeding> | provides those IO functions with some magical implementation, and knows how to _execute_ an IO action: _evaluate_ it, and then apply it to a RealWorld# value. It ensures somehow that the side effects happen as specified. In the GHC implementation, that happens in the magical implementation of those provided IO functions. |
| 2026-06-08 15:46:44 +0000 | <tomsmeding> | "Pure haskell" provides no way to _construct_ a RealWorld# value. |
| 2026-06-08 15:47:08 +0000 | <tomsmeding> | I don't feel like it's helpful to refer to "observability" here because then it's very difficult to not get circular. |
| 2026-06-08 15:48:11 +0000 | <tomsmeding> | But I haven't thought thoroughly about this! This is just me thinking about it for a few minutes now :p |
| 2026-06-08 15:49:28 +0000 | <tomsmeding> | % :i GHC.Prim.realWorld# |
| 2026-06-08 15:49:28 +0000 | <yahb2> | GHC.Internal.Prim.realWorld# :: ; GHC.Internal.Prim.State# GHC.Internal.Prim.RealWorld ; -- Defined in ‘GHC.Internal.Prim’ |
| 2026-06-08 15:49:43 +0000 | <tomsmeding> | it's all lies |
| 2026-06-08 15:50:09 +0000 | <comerijn> | The entirery of GHC.Prim is "just trust me, bro" |
| 2026-06-08 15:50:33 +0000 | <tomsmeding> | yeah I think it's not so controversial to say that when you use something from GHC.Prim, you're coding GHC Haskell, not Haskell :p |
| 2026-06-08 15:50:36 +0000 | <comerijn> | Source: some guy told me :) |
| 2026-06-08 15:51:04 +0000 | <Freakie> | I mean it's in the module name |
| 2026-06-08 15:51:09 +0000 | <tomsmeding> | yes |
| 2026-06-08 15:51:28 +0000 | <Freakie> | I was slightly miffed that there weren't any haskell-level features that allowed you to redirect streams from stdout to somewhere else |
| 2026-06-08 15:51:38 +0000 | <Freakie> | but lo and behold, GHC had some internal support for it |
| 2026-06-08 15:51:55 +0000 | ninjacato | (~Thunderbi@user/ninjacato) ninjacato |
| 2026-06-08 15:52:55 +0000 | zalo-rocky | (~flyingzal@186.19.88.142) |
| 2026-06-08 15:53:01 +0000 | Square2 | (~Square@user/square) Square |
| 2026-06-08 15:53:17 +0000 | <ski> | s/side-effectful IO/effectful IO/ |
| 2026-06-08 15:53:31 +0000 | <comerijn> | Freakie: There's also the unix package (and presumably win32) |
| 2026-06-08 15:53:46 +0000 | <comerijn> | Freakie: Because that's not an OS portable feature |
| 2026-06-08 15:54:11 +0000 | <tomsmeding> | unless they mean rebinding what System.IO.stdout writes to |
| 2026-06-08 15:54:19 +0000 | Square | (~Square4@user/square) (Ping timeout: 264 seconds) |
| 2026-06-08 15:54:23 +0000 | <comerijn> | tomsmeding: You can do that via unix |
| 2026-06-08 15:54:31 +0000 | <comerijn> | dup2 let's you do that just fine |
| 2026-06-08 15:54:38 +0000 | <tomsmeding> | that's a lower level of abstraction :p |
| 2026-06-08 15:54:42 +0000 | <tomsmeding> | if we're talking about those anyway |
| 2026-06-08 15:54:44 +0000 | <Freakie> | those don't come with base though? |
| 2026-06-08 15:54:54 +0000 | <comerijn> | Freakie: Sure, but base comes with almost nothing |
| 2026-06-08 15:54:55 +0000 | <Freakie> | anyway point is that it wasn't in the standard |
| 2026-06-08 15:55:16 +0000 | <comerijn> | You don't need that to be in the standard or compiler, though |
| 2026-06-08 15:55:30 +0000 | <comerijn> | The unix package can add that without compiler support just fine |
| 2026-06-08 15:55:31 +0000 | <Freakie> | I will chalk it up to a design flaw in QuickCheck instead of the language/compiler though |
| 2026-06-08 15:55:37 +0000 | <tomsmeding> | ^ |
| 2026-06-08 15:55:59 +0000 | <tomsmeding> | hedgehog does allow you to do reporting yourself, though you do have to reimplement some of the output logic |
| 2026-06-08 15:56:23 +0000 | <Freakie> | it turned out that I didn't need the output that bad anyway, so I never ended up writing any of it to a file either way |
| 2026-06-08 15:56:25 +0000 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2026-06-08 15:56:35 +0000 | <Freakie> | it was just a thing I found strange in an otherwise feature-complete package |
| 2026-06-08 16:00:06 +0000 | <tomsmeding> | I needed it at some point when I wrote my own test runner (i.e. a replacement for tasty) and needed to do stuff with the output |
| 2026-06-08 16:00:11 +0000 | <tomsmeding> | switched to hedgehog :p |
| 2026-06-08 16:01:09 +0000 | <Freakie> | yeah I just didn't feel the need to use it for my thesis anyway |
| 2026-06-08 16:06:37 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-06-08 16:18:11 +0000 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2026-06-08 16:20:18 +0000 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-06-08 16:20:25 +0000 | euphores | (~SASL_euph@user/euphores) euphores |
| 2026-06-08 16:29:16 +0000 | tnt1 | (~Thunderbi@user/tnt1) (Remote host closed the connection) |
| 2026-06-08 16:29:29 +0000 | attlin | (~user@user/attlin) (Ping timeout: 248 seconds) |
| 2026-06-08 16:30:52 +0000 | attlin | (~user@user/attlin) attlin |
| 2026-06-08 16:31:56 +0000 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2026-06-08 16:35:38 +0000 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2026-06-08 16:37:48 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-08 16:46:04 +0000 | poscat0x04 | (~poscat@user/poscat) poscat |
| 2026-06-08 16:47:24 +0000 | poscat | (~poscat@user/poscat) (Ping timeout: 245 seconds) |
| 2026-06-08 16:51:34 +0000 | Enrico63 | (~Enrico63@host-95-247-196-30.retail.telecomitalia.it) (Quit: Client closed) |
| 2026-06-08 16:58:49 +0000 | biberao | (~m@user/biberao) biberao |
| 2026-06-08 17:00:05 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2026-06-08 17:00:27 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-08 17:01:36 +0000 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 264 seconds) |
| 2026-06-08 17:08:07 +0000 | Freakie | (~Freakie@185.45.21.144) (Ping timeout: 245 seconds) |
| 2026-06-08 17:08:51 +0000 | tabaqui | (~tabaqui@167.71.80.236) tabaqui |
| 2026-06-08 17:09:53 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 265 seconds) |
| 2026-06-08 17:13:25 +0000 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2026-06-08 17:23:41 +0000 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-06-08 17:24:12 +0000 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 255 seconds) |
| 2026-06-08 17:29:24 +0000 | bandola | (~bandola@c-5eea53c4-74736162.cust.telenor.se) |
| 2026-06-08 17:38:12 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-06-08 17:42:49 +0000 | attlin | (~user@user/attlin) (Remote host closed the connection) |
| 2026-06-08 17:42:55 +0000 | CipherLab | (~NSA@2.59.157.235) (Ping timeout: 244 seconds) |
| 2026-06-08 17:43:17 +0000 | CipherLab | (~NSA@171.33.191.92) CommanderBond007 |
| 2026-06-08 17:46:58 +0000 | ft | (~ft@p508db0ab.dip0.t-ipconnect.de) ft |
| 2026-06-08 17:49:58 +0000 | attlin | (~user@user/attlin) attlin |
| 2026-06-08 17:58:22 +0000 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2026-06-08 17:58:42 +0000 | EvanR | (~EvanR@user/evanr) EvanR |
| 2026-06-08 18:03:21 +0000 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2026-06-08 18:04:37 +0000 | vgtw_ | (~vgtw@user/vgtw) (Ping timeout: 276 seconds) |
| 2026-06-08 18:13:20 +0000 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2026-06-08 18:26:17 +0000 | bandola | (~bandola@c-5eea53c4-74736162.cust.telenor.se) (Ping timeout: 248 seconds) |
| 2026-06-08 18:26:36 +0000 | bandola | (~bandola@c-5eea4b92-74736162.cust.telenor.se) |
| 2026-06-08 18:34:29 +0000 | hsw | (~hsw@106.104.102.114) (Ping timeout: 245 seconds) |
| 2026-06-08 18:35:26 +0000 | hsw | (~hsw@112-104-29-204.adsl.dynamic.seed.net.tw) hsw |
| 2026-06-08 18:44:47 +0000 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-06-08 18:47:43 +0000 | bandola | (~bandola@c-5eea4b92-74736162.cust.telenor.se) (Ping timeout: 264 seconds) |
| 2026-06-08 18:48:00 +0000 | bandola | (~bandola@c-5eea4394-74736162.cust.telenor.se) |
| 2026-06-08 19:04:41 +0000 | Digit | (~user@user/digit) (Ping timeout: 248 seconds) |
| 2026-06-08 19:04:45 +0000 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-06-08 19:10:31 +0000 | CiaoSen | (~Jura@2a02:3030:ad5:eab1:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-08 19:22:33 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2026-06-08 19:42:51 +0000 | Digitteknohippie | Digit |
| 2026-06-08 19:44:08 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2026-06-08 19:45:16 +0000 | petrichor | (~jez@user/petrichor) (Ping timeout: 256 seconds) |
| 2026-06-08 19:45:17 +0000 | synchromesh | (~john@2406:5a00:247e:1500:54ac:d0d8:80b:9ccf) (Read error: Connection reset by peer) |
| 2026-06-08 19:46:44 +0000 | synchromesh | (~john@2406:5a00:247e:1500:54ac:d0d8:80b:9ccf) synchromesh |
| 2026-06-08 19:55:30 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-08 19:55:44 +0000 | ouilemur | (~jgmerritt@user/ouilemur) (Ping timeout: 252 seconds) |
| 2026-06-08 19:56:51 +0000 | ouilemur | (~jgmerritt@user/ouilemur) ouilemur |
| 2026-06-08 19:59:37 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 248 seconds) |
| 2026-06-08 20:03:49 +0000 | gehmehgeh | (~user@user/gehmehgeh) gehmehgeh |
| 2026-06-08 20:04:51 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 245 seconds) |
| 2026-06-08 20:06:49 +0000 | Pozyomka | (~pyon@user/pyon) (Ping timeout: 276 seconds) |
| 2026-06-08 20:15:42 +0000 | bandola | (~bandola@c-5eea4394-74736162.cust.telenor.se) (Remote host closed the connection) |
| 2026-06-08 20:16:04 +0000 | bandola | (~bandola@c-5eea4394-74736162.cust.telenor.se) |
| 2026-06-08 20:16:22 +0000 | bandola | (~bandola@c-5eea4394-74736162.cust.telenor.se) (Remote host closed the connection) |
| 2026-06-08 20:29:36 +0000 | michalz | (~michalz@185.246.207.221) (Remote host closed the connection) |
| 2026-06-08 20:33:19 +0000 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 264 seconds) |
| 2026-06-08 20:34:42 +0000 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-06-08 20:34:54 +0000 | Square2 | (~Square@user/square) (Ping timeout: 245 seconds) |
| 2026-06-08 20:35:45 +0000 | petrichor | (~jez@user/petrichor) petrichor |
| 2026-06-08 20:41:00 +0000 | ninjacato | (~Thunderbi@user/ninjacato) (Remote host closed the connection) |
| 2026-06-08 20:47:57 +0000 | ninjacato | (~Thunderbi@user/ninjacato) ninjacato |
| 2026-06-08 20:53:41 +0000 | leppard | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) Inline |
| 2026-06-08 20:54:33 +0000 | jreicher | (~joelr@user/jreicher) (Quit: In transit) |
| 2026-06-08 20:55:00 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 252 seconds) |
| 2026-06-08 21:00:20 +0000 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-06-08 21:03:04 +0000 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2026-06-08 21:07:12 +0000 | CipherLab | (~NSA@171.33.191.92) (Read error: Connection reset by peer) |
| 2026-06-08 21:08:02 +0000 | CipherLab | (~NSA@2.59.157.238) CommanderBond007 |
| 2026-06-08 21:08:36 +0000 | CiaoSen | (~Jura@2a02:3030:ad5:eab1:4e50:ddff:fe9b:8922) (Ping timeout: 246 seconds) |
| 2026-06-08 21:11:39 +0000 | CiaoSen | (~Jura@dynamic-046-114-170-105.46.114.pool.telefonica.de) CiaoSen |
| 2026-06-08 21:17:21 +0000 | itaipu | (~itaipu@168.121.98.199) (Ping timeout: 258 seconds) |