| 2024-11-18 00:00:24 +0100 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) werneta |
| 2024-11-18 00:00:30 +0100 | Jeanne-Kamikaze | (~Jeanne-Ka@142.147.89.209) (Quit: Leaving) |
| 2024-11-18 00:03:55 +0100 | vgtw | (~vgtw@user/vgtw) (Quit: ZNC - https://znc.in) |
| 2024-11-18 00:04:10 +0100 | werneta_ | (~werneta@syn-071-083-160-242.res.spectrum.com) werneta |
| 2024-11-18 00:04:38 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-11-18 00:05:21 +0100 | ftzm | (~ftzm@085080230038.dynamic.telenor.dk) (Ping timeout: 276 seconds) |
| 2024-11-18 00:08:09 +0100 | vgtw | (~vgtw@user/vgtw) vgtw |
| 2024-11-18 00:08:21 +0100 | Alleria | (~Alleria@user/alleria) (Remote host closed the connection) |
| 2024-11-18 00:09:09 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 00:10:08 +0100 | xff0x | (~xff0x@2405:6580:b080:900:ba13:33aa:3901:2450) |
| 2024-11-18 00:18:40 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 00:19:46 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-18 00:20:02 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 00:21:56 +0100 | mari-estel | (~mari-este@user/mari-estel) (Client Quit) |
| 2024-11-18 00:22:37 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 00:25:10 +0100 | zlqrvx | (~zlqrvx@user/zlqrvx) (Quit: %quit%) |
| 2024-11-18 00:25:36 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f99b0ad6825ae812995.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-11-18 00:53:53 +0100 | divya | (~user@139.5.11.231) divya |
| 2024-11-18 00:55:56 +0100 | <SrPx> | so now that im using haskell for a larger project, monad transformers are unavoidable. but it is somewhat annoying to have chains of lifts. wouldn't it make more sense to have a list of the involved monads, and then a 'pick' that selects the one you want? like, `x <- pick M_IO $ something` instead of `x <- lift $ lift $ something` |
| 2024-11-18 00:57:17 +0100 | <Axman6> | that's basically what MTL is |
| 2024-11-18 00:57:48 +0100 | <SrPx> | oh, just learned about it. cool |
| 2024-11-18 00:57:52 +0100 | <glguy> | monad transformers are not an inevitability of large projects |
| 2024-11-18 00:59:09 +0100 | <glguy> | at most they can be an implementation detail of your more-specific monads that you are defining |
| 2024-11-18 01:00:26 +0100 | xal | (~xal@mx1.xal.systems) xal |
| 2024-11-18 01:00:26 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 272 seconds) |
| 2024-11-18 01:01:25 +0100 | <Axman6> | yeah the RIO approach (or similar ReaderT Env IO ideas) get you a very long way. it's pretty easy to do things like `inDB :: DB a -> ReaderT Env IO a` which runs a transaction inside your reader |
| 2024-11-18 01:02:48 +0100 | sprotte24 | (~sprotte24@p200300d16f2c3600a1fb2e60ac56d901.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2024-11-18 01:10:06 +0100 | Everything | (~Everythin@178-133-36-30.mobile.vf-ua.net) (Ping timeout: 246 seconds) |
| 2024-11-18 01:12:25 +0100 | hiredman | (~hiredman@frontier1.downey.family) hiredman |
| 2024-11-18 01:12:33 +0100 | hiredman | (~hiredman@frontier1.downey.family) (Client Quit) |
| 2024-11-18 01:12:51 +0100 | hiredman | (~hiredman@frontier1.downey.family) hiredman |
| 2024-11-18 01:16:22 +0100 | athan | (~athan@syn-173-042-095-241.biz.spectrum.com) athan |
| 2024-11-18 01:19:23 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2024-11-18 01:19:49 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2024-11-18 01:20:44 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2024-11-18 01:28:41 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-18 01:29:23 +0100 | tomboy64 | (~tomboy64@user/tomboy64) (Read error: Connection reset by peer) |
| 2024-11-18 01:29:29 +0100 | tomboy65 | (~tomboy64@user/tomboy64) tomboy64 |
| 2024-11-18 01:35:24 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2024-11-18 01:36:10 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-11-18 01:37:23 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-18 01:39:24 +0100 | <Leary> | SrPx: Note that if you use 'mtl' monad-polymorphically then performance will become unreliable for cross-module inlining reasons. Consider using a modern effect system like 'effectful' or 'bluefin' instead. |
| 2024-11-18 01:40:39 +0100 | athan | (~athan@syn-173-042-095-241.biz.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-11-18 01:41:30 +0100 | rvalue- | rvalue |
| 2024-11-18 01:53:45 +0100 | oxide | (~lambda@user/oxide) (Ping timeout: 252 seconds) |
| 2024-11-18 01:54:53 +0100 | j1n37 | (j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2024-11-18 01:59:15 +0100 | j1n37 | (j1n37@user/j1n37) j1n37 |
| 2024-11-18 02:05:57 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 248 seconds) |
| 2024-11-18 02:09:33 +0100 | son0p | (~ff@2800:e2:f80:ee7::4) son0p |
| 2024-11-18 02:18:24 +0100 | son0p | (~ff@2800:e2:f80:ee7::4) (Remote host closed the connection) |
| 2024-11-18 02:19:23 +0100 | son0p | (~ff@2800:e2:f80:ee7::4) son0p |
| 2024-11-18 02:23:06 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-18 02:35:56 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2024-11-18 02:41:41 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Ping timeout: 248 seconds) |
| 2024-11-18 02:43:12 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 02:43:43 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 02:53:23 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 02:53:53 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:03:34 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 03:04:04 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:13:44 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 03:14:15 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:17:36 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) () |
| 2024-11-18 03:20:04 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) ZLima12 |
| 2024-11-18 03:23:56 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 03:24:27 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:28:33 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds) |
| 2024-11-18 03:34:07 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 03:34:37 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:35:41 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in) |
| 2024-11-18 03:35:59 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) todi |
| 2024-11-18 03:44:18 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 03:44:48 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:54:29 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 03:54:59 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 03:56:21 +0100 | Inst | (~Inst@user/Inst) (Ping timeout: 246 seconds) |
| 2024-11-18 04:03:59 +0100 | rvalue- | (~rvalue@user/rvalue) rvalue |
| 2024-11-18 04:04:40 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 04:04:40 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-11-18 04:05:11 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 04:08:14 +0100 | rvalue- | rvalue |
| 2024-11-18 04:14:51 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 04:15:21 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 04:24:44 +0100 | xff0x | (~xff0x@2405:6580:b080:900:ba13:33aa:3901:2450) (Ping timeout: 260 seconds) |
| 2024-11-18 04:25:34 +0100 | td_ | (~td@i5387090C.versanet.de) (Ping timeout: 252 seconds) |
| 2024-11-18 04:27:45 +0100 | willscripted | (~willscrip@user/willscripted) (Ping timeout: 248 seconds) |
| 2024-11-18 04:32:41 +0100 | turlando | (~turlando@user/turlando) () |
| 2024-11-18 04:32:51 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 04:33:21 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 04:37:58 +0100 | turlando | (~turlando@user/turlando) turlando |
| 2024-11-18 04:42:48 +0100 | shapr | (~user@2600:4040:5c49:5600:cd62:8744:52b3:406b) (Quit: sleeyp) |
| 2024-11-18 04:43:02 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 04:43:33 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 04:51:33 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-18 05:02:31 +0100 | notzmv | (~daniel@user/notzmv) (Ping timeout: 264 seconds) |
| 2024-11-18 05:21:54 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-11-18 05:32:03 +0100 | troydm | (~troydm@user/troydm) (Ping timeout: 245 seconds) |
| 2024-11-18 05:35:08 +0100 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) (Quit: Lost terminal) |
| 2024-11-18 05:36:52 +0100 | Leary | (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2024-11-18 05:38:53 +0100 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-06-76-69-85-220.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2024-11-18 05:45:14 +0100 | Leary | (~Leary@user/Leary/x-0910699) Leary |
| 2024-11-18 05:48:57 +0100 | xff0x | (~xff0x@106.178.114.108) |
| 2024-11-18 05:57:33 +0100 | michalz | (~michalz@185.246.207.197) |
| 2024-11-18 06:53:50 +0100 | werneta_ | (~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 272 seconds) |
| 2024-11-18 07:13:32 +0100 | notzmv | (~daniel@user/notzmv) notzmv |
| 2024-11-18 07:14:21 +0100 | vanishing | (~vanishing@user/vanishingideal) (Ping timeout: 276 seconds) |
| 2024-11-18 07:24:00 +0100 | briandaed | (~root@user/briandaed) briandaed |
| 2024-11-18 07:27:51 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-11-18 07:30:04 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-11-18 07:37:04 +0100 | euleritian | (~euleritia@77.22.252.159) (Ping timeout: 260 seconds) |
| 2024-11-18 07:38:42 +0100 | euleritian | (~euleritia@dynamic-176-004-231-188.176.4.pool.telefonica.de) |
| 2024-11-18 07:44:04 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2024-11-18 07:53:59 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f6925a61425bb02ca09.dip0.t-ipconnect.de) acidjnk |
| 2024-11-18 08:01:06 +0100 | xff0x | (~xff0x@106.178.114.108) (Ping timeout: 248 seconds) |
| 2024-11-18 08:15:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 08:25:18 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-11-18 08:39:29 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f6925a61425bb02ca09.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-11-18 08:39:53 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2024-11-18 08:44:49 +0100 | Square2 | (~Square4@user/square) Square |
| 2024-11-18 08:45:13 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2024-11-18 08:45:46 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-18 08:51:02 +0100 | ft | (~ft@p4fc2a26f.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-11-18 08:53:52 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f69701fb6560bc0f0be.dip0.t-ipconnect.de) acidjnk |
| 2024-11-18 08:59:58 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-11-18 09:00:03 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-18 09:00:29 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-11-18 09:00:42 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-18 09:06:47 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2024-11-18 09:08:40 +0100 | fr33domlover | (~fr33domlo@towards.vision) (Quit: The Lounge - https://thelounge.chat) |
| 2024-11-18 09:14:02 +0100 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) misterfish |
| 2024-11-18 09:35:03 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2024-11-18 09:35:09 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-18 09:36:37 +0100 | euleritian | (~euleritia@dynamic-176-004-231-188.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-18 09:36:54 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 09:48:10 +0100 | chele | (~chele@user/chele) chele |
| 2024-11-18 09:54:17 +0100 | xff0x | (~xff0x@2405:6580:b080:900:e7b6:fba6:14b7:d70c) |
| 2024-11-18 09:57:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 10:02:49 +0100 | lockywolf | (~lockywolf@coconut.lockywolf.net) (Read error: Connection reset by peer) |
| 2024-11-18 10:05:45 +0100 | alphazone | unalmasIRC |
| 2024-11-18 10:06:48 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 10:08:56 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2024-11-18 10:09:04 +0100 | Digit | (~user@user/digit) (Ping timeout: 244 seconds) |
| 2024-11-18 10:11:15 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-11-18 10:11:22 +0100 | euleritian | (~euleritia@dynamic-176-004-231-188.176.4.pool.telefonica.de) |
| 2024-11-18 10:14:46 +0100 | kuribas | (~user@ptr-17d51eowbvu84pzojhe.18120a2.ip6.access.telenet.be) |
| 2024-11-18 10:19:26 +0100 | CrunchyFlakes | (~CrunchyFl@31.19.233.78) |
| 2024-11-18 10:19:59 +0100 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) (Ping timeout: 260 seconds) |
| 2024-11-18 10:32:19 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 244 seconds) |
| 2024-11-18 10:34:48 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2024-11-18 10:36:07 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 10:45:28 +0100 | euleritian | (~euleritia@dynamic-176-004-231-188.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-18 10:45:45 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 10:45:54 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-18 10:47:58 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-11-18 10:52:39 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-11-18 10:52:55 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 10:55:41 +0100 | Vajb | (~Vajb@n7m8bu6eaitlx0eukg2-1.v6.elisa-mobile.fi) (Ping timeout: 252 seconds) |
| 2024-11-18 10:56:55 +0100 | Vajb | (~Vajb@n84e9ei03jkqt6rm3ev-1.v6.elisa-mobile.fi) |
| 2024-11-18 10:59:34 +0100 | mari15224 | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 11:02:59 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 260 seconds) |
| 2024-11-18 11:03:24 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-11-18 11:06:13 +0100 | euleritian | (~euleritia@dynamic-176-004-231-188.176.4.pool.telefonica.de) |
| 2024-11-18 11:24:49 +0100 | son0p | (~ff@2800:e2:f80:ee7::4) (Ping timeout: 248 seconds) |
| 2024-11-18 11:24:57 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-11-18 11:27:33 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 248 seconds) |
| 2024-11-18 11:33:25 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2024-11-18 11:43:34 +0100 | zlqrvx | (~zlqrvx@user/zlqrvx) zlqrvx |
| 2024-11-18 11:47:04 +0100 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 272 seconds) |
| 2024-11-18 11:49:34 +0100 | jinsun | (~jinsun@user/jinsun) jinsun |
| 2024-11-18 12:04:50 +0100 | Digitteknohippie | Digit |
| 2024-11-18 12:07:23 +0100 | Digit | (~user@user/digit) (Remote host closed the connection) |
| 2024-11-18 12:09:10 +0100 | Digit | (~user@user/digit) Digit |
| 2024-11-18 12:10:03 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2024-11-18 12:15:52 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-11-18 12:18:34 +0100 | euleritian | (~euleritia@dynamic-176-004-231-188.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-18 12:18:52 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 12:38:12 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) SlackCoder |
| 2024-11-18 12:44:08 +0100 | Guest59 | (~Guest25@2402:3a80:413e:e883:2944:58c2:e568:454c) |
| 2024-11-18 12:44:56 +0100 | mari15224 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-18 12:45:41 +0100 | Guest59 | (~Guest25@2402:3a80:413e:e883:2944:58c2:e568:454c) () |
| 2024-11-18 12:55:25 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 12:59:04 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 13:02:09 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-11-18 13:02:59 +0100 | jinsun_ | (~jinsun@user/jinsun) jinsun |
| 2024-11-18 13:02:59 +0100 | jinsun | (~jinsun@user/jinsun) (Killed (tantalum.libera.chat (Nickname regained by services))) |
| 2024-11-18 13:02:59 +0100 | jinsun_ | jinsun |
| 2024-11-18 13:05:47 +0100 | notzmv | (~daniel@user/notzmv) (Remote host closed the connection) |
| 2024-11-18 13:11:10 +0100 | jinsun | Guest2809 |
| 2024-11-18 13:11:10 +0100 | jinsun_ | (~jinsun@user/jinsun) jinsun |
| 2024-11-18 13:11:10 +0100 | Guest2809 | (~jinsun@user/jinsun) (Killed (zinc.libera.chat (Nickname regained by services))) |
| 2024-11-18 13:11:10 +0100 | jinsun_ | jinsun |
| 2024-11-18 13:24:03 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) szkl |
| 2024-11-18 13:27:24 +0100 | SlackCoder | (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Remote host closed the connection) |
| 2024-11-18 13:41:31 +0100 | shapr | (~user@2600:4040:5c49:5600:7905:5c67:d410:b5e3) shapr |
| 2024-11-18 13:44:20 +0100 | user363627 | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-18 13:50:52 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) kupi |
| 2024-11-18 13:52:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 13:55:48 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f69701fb6560bc0f0be.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2024-11-18 13:58:39 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f69701fb6560bc0f0be.dip0.t-ipconnect.de) |
| 2024-11-18 14:04:16 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
| 2024-11-18 14:15:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 14:22:52 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-11-18 14:23:30 +0100 | euleritian | (~euleritia@dynamic-176-006-145-171.176.6.pool.telefonica.de) |
| 2024-11-18 14:27:53 +0100 | zlqrvx_ | (~zlqrvx@2001:8003:8c8b:e00:58ff:a30c:881f:1fe4) |
| 2024-11-18 14:28:06 +0100 | euleritian | (~euleritia@dynamic-176-006-145-171.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-11-18 14:28:27 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 14:31:55 +0100 | zlqrvx | (~zlqrvx@user/zlqrvx) (Ping timeout: 264 seconds) |
| 2024-11-18 14:33:00 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds) |
| 2024-11-18 14:39:58 +0100 | euleritian | (~euleritia@dynamic-176-007-160-241.176.7.pool.telefonica.de) |
| 2024-11-18 14:40:59 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2024-11-18 14:41:25 +0100 | euleritian | (~euleritia@dynamic-176-007-160-241.176.7.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-18 14:41:44 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 14:42:43 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
| 2024-11-18 14:48:20 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Remote host closed the connection) |
| 2024-11-18 14:48:45 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) manwithluck |
| 2024-11-18 14:52:43 +0100 | astroanax | (~astroanax@2001:19f0:7402:f82:5400:1ff:fec4:f7d7) (Ping timeout: 244 seconds) |
| 2024-11-18 14:53:35 +0100 | astroanax | (~astroanax@2001:19f0:7402:f82:5400:1ff:fec4:f7d7) astroanax |
| 2024-11-18 14:57:52 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 14:59:46 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-11-18 15:01:05 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 265 seconds) |
| 2024-11-18 15:01:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-11-18 15:05:08 +0100 | euleritian | (~euleritia@77.22.252.159) (Read error: Connection reset by peer) |
| 2024-11-18 15:05:59 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 15:07:31 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 15:07:35 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-11-18 15:07:56 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 15:11:21 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2024-11-18 15:22:12 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3113-e8b3-4dc5-4d20-737c-18a7.rev.sfr.net) alexherbo2 |
| 2024-11-18 15:37:24 +0100 | k` | (~k`@152.7.255.193) |
| 2024-11-18 15:38:18 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 15:39:49 +0100 | willscripted | (~willscrip@user/willscripted) willscripted |
| 2024-11-18 15:41:56 +0100 | <k`> | Is it possible to include GADT constraints in a pattern synonym? I'm trying to do something like `pattern ()=> (a ~ Int)=> Bool -> Foo a ; pattern Foo b <- (unpack -> b) where Foo x = Foo__ (pack x)`, and I get type error "Couldn't match type 'a' with 'Bool'". |
| 2024-11-18 15:43:32 +0100 | euleritian | (~euleritia@77.22.252.159) (Ping timeout: 252 seconds) |
| 2024-11-18 15:43:58 +0100 | euleritian | (~euleritia@176.2.4.196) |
| 2024-11-18 15:44:15 +0100 | <k`> | The GHC docs seem to imply that that's how the second set of constraints works, but I can't get the type to check. |
| 2024-11-18 15:49:41 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-18 15:50:11 +0100 | <dolio> | What is the type of unpack? |
| 2024-11-18 15:50:16 +0100 | k` | Wygulmage |
| 2024-11-18 15:52:41 +0100 | Wygulmage | (~k`@152.7.255.193) (Changing host) |
| 2024-11-18 15:52:41 +0100 | Wygulmage | (~k`@user/Wygulmage) Wygulmage |
| 2024-11-18 15:52:43 +0100 | <dolio> | Presumably the problem is that it just returns a boolean, which means that it doesn't actually get you the a ~ Int evidence that you say it has. |
| 2024-11-18 15:53:14 +0100 | <dolio> | You need it to produce a type that is a Boolean with evidence that you're going to match on. |
| 2024-11-18 15:54:12 +0100 | <dolio> | Like `data Witness c a where Wit :: c => a -> Witness c a` |
| 2024-11-18 15:55:18 +0100 | lol_ | jcarpenter2 |
| 2024-11-18 15:55:21 +0100 | <Wygulmage> | Sorry, so the GADT is `data Foo a where Foo__ :: Int -> Foo Bool |
| 2024-11-18 15:55:38 +0100 | <Wygulmage> | type of unpack is Int -> Bool |
| 2024-11-18 15:55:56 +0100 | <dolio> | Right, but what type is `unpack`? |
| 2024-11-18 15:56:39 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 252 seconds) |
| 2024-11-18 15:57:10 +0100 | <dolio> | Oh I see. Anyway, it doesn't matter. It just swaps around the problem. |
| 2024-11-18 15:57:12 +0100 | <Wygulmage> | (actually `Int# -> Bool`, if that matters.) |
| 2024-11-18 15:57:51 +0100 | <Wygulmage> | I assumed that strictly matching the GADT constructor Foo__ in the view pattern would bring the constraint into scope. |
| 2024-11-18 15:58:49 +0100 | <dolio> | It does in unpack. But what is the type of unpack ? |
| 2024-11-18 15:59:09 +0100 | <Wygulmage> | `unpack :: Int# -> Bool` |
| 2024-11-18 15:59:24 +0100 | <dolio> | Okay, so, it only returns a Bool, not evidence that `a ~ Int`. |
| 2024-11-18 15:59:58 +0100 | <Wygulmage> | Right. Can I give it a type like `Int# -> (a ~ Bool)=> a` ? |
| 2024-11-18 16:00:14 +0100 | <dolio> | You could, but that's not the right type. |
| 2024-11-18 16:01:45 +0100 | <dolio> | The right type is something like `Foo a -> Witness (a ~ Bool) ...` |
| 2024-11-18 16:03:33 +0100 | <Wygulmage> | Sorry, sorry, I had messed this up at the beginning. In desperation I had changed the pattern to `Foo b <- (\ (Foo_ i) -> unpack i -> b` |
| 2024-11-18 16:04:56 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:05:22 +0100 | <Wygulmage> | Does a view pattern like that not bring `Foo__` 's constraints into scope? Do I need to return something like `(# b, Refl #)` ? |
| 2024-11-18 16:05:28 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:05:41 +0100 | <dolio> | Maybe you want `Foo u <- Foo_ (unpack -> u)` |
| 2024-11-18 16:06:59 +0100 | <Wygulmage> | dolio: Thank you! I did not know that was legal syntax! |
| 2024-11-18 16:07:17 +0100 | <dolio> | It's just using a view pattern nested under a normal pattern. |
| 2024-11-18 16:07:35 +0100 | <dolio> | That way the Foo__ match gets you the evidence. |
| 2024-11-18 16:08:00 +0100 | <dolio> | If you put it all in a function, then the function won't be returning the evidence unless you give it a more complicated return type. |
| 2024-11-18 16:08:01 +0100 | <Wygulmage> | I'm pretty ignorant of view pattern syntax. I only use them when I need smart constructors in pattern synonyms. |
| 2024-11-18 16:08:23 +0100 | <Wygulmage> | Anyway, that works perfectly. |
| 2024-11-18 16:11:25 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-18 16:15:08 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:15:38 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:20:37 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 16:20:51 +0100 | <Wygulmage> | So here's a semirelated question: Do UNPACK pragmas do anything to UnliftedTypes? For example, my understanding is that `ByteArray#` is a reference to a GC-managed reference to a memory region of metadata and bytes. If you try to UNPACK the `ByteArray` into a lifted constructor `Bar Int# !ByteArray#` , is the result a reference to an `Int#` and a |
| 2024-11-18 16:20:52 +0100 | <Wygulmage> | GC-managed reference to a memory region of metadata and bytes? Or is it a reference to ( an `Int#` and a reference to a GC managed...)? |
| 2024-11-18 16:24:24 +0100 | <Wygulmage> | Is there a way to check by looking at the dumped .simpl file for the module? |
| 2024-11-18 16:24:27 +0100 | <dolio> | I'm not sure what you're asking. You can't unpack the ByteArray# stuff directly into the constructor of another type (to my knowledge) if that's what you mean. |
| 2024-11-18 16:24:50 +0100 | <dolio> | So the ByteArray# will still be an indirection. |
| 2024-11-18 16:25:19 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:25:19 +0100 | <dolio> | In a manner of speaking. |
| 2024-11-18 16:25:49 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:28:22 +0100 | <Wygulmage> | For what it's worth, GHC does not complain about an UNPACK pragma on a ByteArray#. And I assume that if I define my own unlifted types, I can unpack them (because they are still boxed). |
| 2024-11-18 16:28:40 +0100 | <dolio> | Basically, Bar contains two words (I think), one of which is the Int# and one which is the pointer to the byte array structure. |
| 2024-11-18 16:30:34 +0100 | <Wygulmage> | The byte array structure as in the actual memory region, or another pointer (to GC-managed memory if unpinned and pinned memory if pinned) to the actual allocated memory? |
| 2024-11-18 16:32:08 +0100 | <dolio> | It's not just a pointer to the beginning of the bytes, because byte arrays e.g. know their length. |
| 2024-11-18 16:32:26 +0100 | <dolio> | It's a structure. |
| 2024-11-18 16:33:38 +0100 | <dolio> | I don't know exactly how it's represented, though. I guess the structure could be all packed together instead of involving another pointer. |
| 2024-11-18 16:34:56 +0100 | <Wygulmage> | Right. I think we're talking past each other. My understanding is that a ByteArray# is a pointer to another pointer to flat memory that consists of length in bytes and then the bytes. I'm wondering whether unpacking the ByteArray# lifts gets rid of that first pointer, |
| 2024-11-18 16:35:29 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:35:31 +0100 | <Wygulmage> | (because GC can rewrite the pointer to actual memory inside the lifted structure that it's been unpacked into) |
| 2024-11-18 16:35:59 +0100 | <dolio> | You can only unpack data types. |
| 2024-11-18 16:36:01 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:37:35 +0100 | <Wygulmage> | Right. So UnliftedTypes are inside strict boxes (pointers) that allow the garbage collector to manage them. Does unpacking an unlifted type get rid of that box? |
| 2024-11-18 16:38:24 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-18 16:39:24 +0100 | <dolio> | Are you asking about ByteArray#? Then the answer is no, because it's not defined with data. It's a built-in. |
| 2024-11-18 16:40:09 +0100 | <dolio> | If you're asking about a data definition with a specified kind of UnliftedType, then I'm less certain. I think the answer might still be no. |
| 2024-11-18 16:40:16 +0100 | Alleria_ | (~Alleria@user/alleria) Alleria |
| 2024-11-18 16:40:35 +0100 | <Wygulmage> | OK, thanks. |
| 2024-11-18 16:40:44 +0100 | <Wygulmage> | That's exactly what I wanted to know. |
| 2024-11-18 16:43:17 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 248 seconds) |
| 2024-11-18 16:43:52 +0100 | <Wygulmage> | So a polymorphic `data Baz ( a :: UnliftedType ) = MkBaz Int# a` will have an equivalent in-memory representation to `data BazBytes = MkMazBytes Int# ByteArray#` when `a` is instantiated to `ByteArray#` |
| 2024-11-18 16:44:40 +0100 | <Wygulmage> | I was wondering whether the polymorphism would introduce an extra layer of indirection. |
| 2024-11-18 16:45:41 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:46:11 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:46:28 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 16:47:00 +0100 | Alleria_ | (~Alleria@user/alleria) (Ping timeout: 276 seconds) |
| 2024-11-18 16:47:27 +0100 | <Wygulmage> | It's nice to be able to have the `Baz` wrapper for `Array#`, `ByteArray#`, `MutableByteArray#`, etc., but at this low level, not if it creates an extra indirection. |
| 2024-11-18 16:49:03 +0100 | <dolio> | It appears that if `type F :: UnliftedType` is declared, then `data G = G {-# unpack #-} !F` does not actually unpack F. |
| 2024-11-18 16:49:49 +0100 | <dolio> | You can see this by messing around with -ddump-simpl. |
| 2024-11-18 16:50:12 +0100 | euleritian | (~euleritia@176.2.4.196) (Read error: Connection reset by peer) |
| 2024-11-18 16:50:13 +0100 | <Wygulmage> | That is very good to know. |
| 2024-11-18 16:50:30 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 16:50:51 +0100 | <dolio> | When F is not UnliftedType, a G value ends up looking like: `floobnar = Up.G 5# 6#` |
| 2024-11-18 16:51:29 +0100 | <dolio> | But the UnliftedType version is: `floobnar = Up.G (Up.F 5# 6#)` |
| 2024-11-18 16:51:33 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 276 seconds) |
| 2024-11-18 16:52:07 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-18 16:53:12 +0100 | <Wygulmage> | Huh. I wonder whether that's a bug or a feature. |
| 2024-11-18 16:53:47 +0100 | <dolio> | I don't know. I guess they figured you wouldn't be unpacking unlifted data types into other types. |
| 2024-11-18 16:54:08 +0100 | <dolio> | Certainly there's no reason you couldn't. |
| 2024-11-18 16:54:52 +0100 | <Wygulmage> | I assumed that GHC would unpack anything of `BoxedRep r`, regardless of whether `r` was lifted or unlifted. |
| 2024-11-18 16:55:04 +0100 | <Wygulmage> | I guess it operates at a less general level. |
| 2024-11-18 16:55:52 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 16:56:23 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 16:57:35 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 17:04:46 +0100 | Alleria | (~Alleria@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-11-18 17:05:59 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 17:06:03 +0100 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-11-18 17:06:33 +0100 | gorignak | (~gorignak@user/gorignak) gorignak |
| 2024-11-18 17:16:19 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-11-18 17:16:53 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 17:17:32 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Quit: Nothing to see here. I wasn't there.) |
| 2024-11-18 17:18:38 +0100 | <dolio> | You should probably check if UnliftedType omits other optimizations. E.G. does GHC still do constructed product returns for them? |
| 2024-11-18 17:18:42 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 17:20:07 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.4.2) |
| 2024-11-18 17:21:31 +0100 | son0p | (~ff@2800:e6:4001:6cc3:2748:5c2a:65d9:57ac) son0p |
| 2024-11-18 17:21:43 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Client Quit) |
| 2024-11-18 17:22:52 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 17:25:30 +0100 | Alleria | (~Alleria@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-11-18 17:26:54 +0100 | Leonard26 | (~Leonard26@49.236.26.53) |
| 2024-11-18 17:27:16 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2024-11-18 17:27:33 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 17:29:16 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Ping timeout: 244 seconds) |
| 2024-11-18 17:29:17 +0100 | mari-estel | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2024-11-18 17:32:13 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 17:33:15 +0100 | berberman | (~berberman@user/berberman) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-11-18 17:34:21 +0100 | killerstorm | (~killersto@224.225.60.94.rev.vodafone.pt) |
| 2024-11-18 17:35:20 +0100 | berberman | (~berberman@user/berberman) berberman |
| 2024-11-18 17:35:28 +0100 | <Leonard26> | Hello! =D How are you? |
| 2024-11-18 17:35:28 +0100 | <Leonard26> | I am trying to follow the tutorial/blog on ReaderT https://tech.fpcomplete.com/blog/2017/06/readert-design-pattern/ |
| 2024-11-18 17:35:29 +0100 | <Leonard26> | I was asking myself if given the following line `var <- newTVarIO (1 :: Int)` one could then use it in a different function outside of main? |
| 2024-11-18 17:35:29 +0100 | <Leonard26> | Like so https://paste.tomsmeding.com/IyjbMmtV |
| 2024-11-18 17:37:35 +0100 | alp | (~alp@2001:861:e3d6:8f80:568b:9761:243e:95b5) |
| 2024-11-18 17:37:36 +0100 | <ncf> | pass var as an argument |
| 2024-11-18 17:39:47 +0100 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Read error: Connection reset by peer) |
| 2024-11-18 17:40:33 +0100 | <Leonard26> | You mean like so? https://paste.tomsmeding.com/5unyMRGn |
| 2024-11-18 17:41:51 +0100 | jespada_ | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) jespada |
| 2024-11-18 17:43:23 +0100 | jespada_ | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Read error: Connection reset by peer) |
| 2024-11-18 17:44:05 +0100 | <ncf> | well obviously you need to call newFunc from main |
| 2024-11-18 17:44:46 +0100 | <Leonard26> | yes, right, sorry I forgot '=D |
| 2024-11-18 17:46:42 +0100 | jespada | (~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) jespada |
| 2024-11-18 17:48:48 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 17:49:54 +0100 | Alleria | (~Alleria@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-11-18 17:50:52 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-11-18 17:52:31 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection) |
| 2024-11-18 17:52:49 +0100 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) rachelambda |
| 2024-11-18 17:54:14 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 18:06:04 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 18:10:11 +0100 | <zzz> | is there any potencial performance difference between using the State monad and threading manually like this?: https://paste.jrvieira.com/1731949754002 |
| 2024-11-18 18:10:33 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f69701fb6560bc0f0be.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-11-18 18:11:16 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2024-11-18 18:14:14 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 18:14:15 +0100 | euleritian | (~euleritia@77.22.252.159) (Read error: Connection reset by peer) |
| 2024-11-18 18:18:49 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-18 18:22:30 +0100 | <zzz> | i guess i could create a new IntMap and update it each step instead of appending to a linked list and then using IntMap.fromList but other than that |
| 2024-11-18 18:22:33 +0100 | Alleria | (~Alleria@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-11-18 18:24:04 +0100 | <geekosaur> | if ghc's doing its thing correctly, the state monad should get optimized down to the manual version |
| 2024-11-18 18:24:09 +0100 | <zzz> | and then again maybe not. i guess IntMap.fromList can be more performant than IntMap.insert every step |
| 2024-11-18 18:24:40 +0100 | <geekosaur> | (but you'd need to inspect Core to find out) |
| 2024-11-18 18:24:43 +0100 | Leonard26 | (~Leonard26@49.236.26.53) (Quit: Client closed) |
| 2024-11-18 18:24:59 +0100 | <geekosaur> | and yes, especially if it's going to be a large tree I'd `fromList` at the end |
| 2024-11-18 18:25:25 +0100 | <zzz> | i actually prefer not using State in this particular instance |
| 2024-11-18 18:25:27 +0100 | <zzz> | thanks |
| 2024-11-18 18:26:09 +0100 | shapr | (~user@2600:4040:5c49:5600:7905:5c67:d410:b5e3) (Ping timeout: 248 seconds) |
| 2024-11-18 18:28:13 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-18 18:32:07 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3113-e8b3-4dc5-4d20-737c-18a7.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-18 18:33:55 +0100 | hellwolf | (~user@04ed-dbc2-42ba-2a72-0f00-4d40-07d0-2001.sta.estpak.ee) (Remote host closed the connection) |
| 2024-11-18 18:34:15 +0100 | hellwolf | (~user@ce28-37de-4848-1507-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
| 2024-11-18 18:47:07 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f69701fb6560bc0f0be.dip0.t-ipconnect.de) acidjnk |
| 2024-11-18 18:48:07 +0100 | Alleria_ | (~Alleria@user/alleria) Alleria |
| 2024-11-18 18:49:25 +0100 | iteratee | (~kyle@162.218.222.207) |
| 2024-11-18 18:52:47 +0100 | killerstorm | (~killersto@224.225.60.94.rev.vodafone.pt) (Quit: Client closed) |
| 2024-11-18 18:52:58 +0100 | <iteratee> | Chased down an interesting bug recently. I was trying to set up direct QUIC access to a server I have running. |
| 2024-11-18 18:53:26 +0100 | <iteratee> | My load balancer will answer requests via QUIC, but will only connect downstream via TCP. |
| 2024-11-18 18:53:56 +0100 | Alleria_ | (~Alleria@user/alleria) (Max SendQ exceeded) |
| 2024-11-18 18:53:57 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-11-18 18:54:22 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 18:54:58 +0100 | <iteratee> | so I created a UDP load balancer that went directly to my webserver. This means that the webserver needs the correct certificates to answer with quic. |
| 2024-11-18 18:55:50 +0100 | <iteratee> | I was getting certificate issues with the direct connection that I wasn't getting with the same certificate served by my reverse proxy. |
| 2024-11-18 18:56:29 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 18:57:50 +0100 | ft | (~ft@p4fc2a26f.dip0.t-ipconnect.de) ft |
| 2024-11-18 18:58:18 +0100 | <iteratee> | it turned out that `credentialLoadX509` and `credentialLoadX509FromMemory` were returning the certificates in differing orders. |
| 2024-11-18 18:59:03 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-18 18:59:24 +0100 | <iteratee> | with the root cause buried in the crypton-x509-store library. |
| 2024-11-18 19:00:34 +0100 | Alleria | (~Alleria@user/alleria) (Max SendQ exceeded) |
| 2024-11-18 19:01:27 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-18 19:01:33 +0100 | euleritian | (~euleritia@77.22.252.159) (Ping timeout: 276 seconds) |
| 2024-11-18 19:02:25 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 19:02:41 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 19:03:04 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2024-11-18 19:03:05 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Quit: Nothing to see here. I wasn't there.) |
| 2024-11-18 19:04:52 +0100 | Alleria | (~Alleria@user/alleria) (Client Quit) |
| 2024-11-18 19:05:59 +0100 | dpk | (~dpk@jains.nonceword.org) (Ping timeout: 260 seconds) |
| 2024-11-18 19:07:05 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 19:08:16 +0100 | kuribas | (~user@ptr-17d51eowbvu84pzojhe.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2024-11-18 19:15:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 19:15:09 +0100 | Wygulmage | (~k`@user/Wygulmage) (Quit: Client closed) |
| 2024-11-18 19:17:32 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-18 19:17:49 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2024-11-18 19:20:41 +0100 | ystael | (~ystael@user/ystael) (Read error: Connection reset by peer) |
| 2024-11-18 19:31:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 19:31:12 +0100 | son0p | (~ff@2800:e6:4001:6cc3:2748:5c2a:65d9:57ac) (Ping timeout: 244 seconds) |
| 2024-11-18 19:31:17 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-11-18 19:31:54 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-18 19:32:50 +0100 | talismanick | (~user@2601:644:937c:ed10::ae5) (Ping timeout: 248 seconds) |
| 2024-11-18 19:33:38 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-11-18 19:35:59 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-11-18 19:36:23 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-11-18 19:36:29 +0100 | <briandaed> | iteratee: was it somehow related to https://github.com/haskell-tls/hs-certificate/issues/31 |
| 2024-11-18 19:36:32 +0100 | <briandaed> | ? |
| 2024-11-18 19:37:55 +0100 | euleritian | (~euleritia@77.22.252.159) (Ping timeout: 264 seconds) |
| 2024-11-18 19:38:49 +0100 | euleritian | (~euleritia@dynamic-176-002-004-196.176.2.pool.telefonica.de) |
| 2024-11-18 19:56:01 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-11-18 20:06:01 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 20:07:09 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-18 20:08:53 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) stiell |
| 2024-11-18 20:13:45 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-18 20:19:55 +0100 | flounders | (~flounders@173.246.200.74) (Quit: WeeChat 4.4.2) |
| 2024-11-18 20:21:27 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-11-18 20:28:31 +0100 | k` | (~k`@152.7.255.193) |
| 2024-11-18 20:28:31 +0100 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) (Read error: Connection reset by peer) |
| 2024-11-18 20:30:50 +0100 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) rachelambda |
| 2024-11-18 20:31:50 +0100 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) (Read error: Connection reset by peer) |
| 2024-11-18 20:32:36 +0100 | euleritian | (~euleritia@dynamic-176-002-004-196.176.2.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-11-18 20:32:54 +0100 | euleritian | (~euleritia@ip5f5ad3bc.dynamic.kabel-deutschland.de) |
| 2024-11-18 20:34:15 +0100 | rachelambda | (~rachelamb@cust-95-80-25-71.csbnet.se) rachelambda |
| 2024-11-18 20:39:29 +0100 | euleritian | (~euleritia@ip5f5ad3bc.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
| 2024-11-18 20:40:20 +0100 | euleritian | (~euleritia@dynamic-176-002-004-196.176.2.pool.telefonica.de) |
| 2024-11-18 20:41:51 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-18 20:43:46 +0100 | Alleria_ | (~Alleria@user/alleria) Alleria |
| 2024-11-18 20:46:19 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 260 seconds) |
| 2024-11-18 20:47:54 +0100 | <SrPx> | quick question about how IO and laziness mix. consider the following Haskell program: |
| 2024-11-18 20:47:58 +0100 | <SrPx> | gen = do print "A"; return 1 |
| 2024-11-18 20:48:03 +0100 | <SrPx> | make = do x <- gen; y <- gen; z <- gen; return (x, y, z) |
| 2024-11-18 20:48:06 +0100 | <SrPx> | main = do (x, y, z) <- make; print x |
| 2024-11-18 20:48:20 +0100 | <SrPx> | obviously, it will print "A" 3 times, because we run all the lines of the "make" function |
| 2024-11-18 20:48:46 +0100 | <SrPx> | yet, we only ever observe "x". as such, in a full lazy sense, it should only print "A" once |
| 2024-11-18 20:48:56 +0100 | kaskal | (~kaskal@2001:4bb8:2c3:1470:8b1d:2068:6ef2:d351) (Quit: ZNC - https://znc.in) |
| 2024-11-18 20:48:57 +0100 | <SrPx> | I know that's not how IO works - |
| 2024-11-18 20:49:40 +0100 | <SrPx> | that said, on my application, I do need the ability to do IO inside "pure" functions (because I'm using C FFI for performance), but I'd also like these IO's to only be executed when necessary, i.e., lazily |
| 2024-11-18 20:50:15 +0100 | <SrPx> | is there any idiomatic way to modify the 'make' function so that "A" will be printed once if 'main' prints 'x', yet "A" will be printed 3 times if 'main' prints '(x,y,z)? |
| 2024-11-18 20:50:18 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2024-11-18 20:52:06 +0100 | <haskellbridge> | <sm> unsafePerformIO, I think |
| 2024-11-18 20:52:20 +0100 | <davean> | SrPx: what does C FFI have to do with pure functions? |
| 2024-11-18 20:52:21 +0100 | <haskellbridge> | <sm> not idiomatic, but I think that'd be the simple way |
| 2024-11-18 20:52:38 +0100 | kaskal | (~kaskal@213-147-165-220.nat.highway.webapn.at) kaskal |
| 2024-11-18 20:52:50 +0100 | <davean> | I'm lost as to the connection you're making |
| 2024-11-18 20:53:29 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-11-18 20:53:43 +0100 | <geekosaur> | you can do pure FFI, if you know the C function you are calling has no side effects and in particular doesn't allocate |
| 2024-11-18 20:53:44 +0100 | <SrPx> | davean: to be more specific, this is for an evaluator. the runtime is in C, including the "whnf-reduce" function. that function does, internally, effectiful things such as allocating memory and writing to the global heap. as such, whnf-reduce must be wrapped in IO - it isn't a pure function |
| 2024-11-18 20:53:59 +0100 | <geekosaur> | ah |
| 2024-11-18 20:54:00 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-11-18 20:54:19 +0100 | <davean> | geekosaur: right, but see what he said "I do need the ability to do IO inside "pure" functions (because I'm using C FFI for performance)" |
| 2024-11-18 20:54:43 +0100 | <SrPx> | the problem is that, now, the 'normal' function (which calls whnf-reduce layer by layer) is extremely eager. if I normalize a term and drop it, it will still fully normalize the term because the whole thing has to be wrapped in IO |
| 2024-11-18 20:54:44 +0100 | <geekosaur> | right, but at that point I think I say "just do it in IO, you will be sad otherwise" |
| 2024-11-18 20:55:07 +0100 | <davean> | I mean you can pass laziness through IO |
| 2024-11-18 20:55:13 +0100 | troydm | (~troydm@user/troydm) troydm |
| 2024-11-18 20:55:17 +0100 | <davean> | IO doesn't remove laziness |
| 2024-11-18 20:55:30 +0100 | <SrPx> | so I can't interleave IO calls to happen only when Haskell's lazy evaluator reaches an expression? ): |
| 2024-11-18 20:55:33 +0100 | <SrPx> | what will happen exactly? |
| 2024-11-18 20:55:45 +0100 | <davean> | I mean that is what IO already does. |
| 2024-11-18 20:56:15 +0100 | Angelz | (Angelz@Angelz.oddprotocol.org) (Ping timeout: 246 seconds) |
| 2024-11-18 20:56:31 +0100 | <mauke> | unsafeInterleaveIO exists |
| 2024-11-18 20:56:48 +0100 | <SrPx> | no. it is true that you can pass IO around lazily. yet, within the context of the execution of IO monad, calls will not be evaluated lazily - Haskell will run the whole IO, even if some parts aren't visible (see my example) |
| 2024-11-18 20:57:05 +0100 | <SrPx> | mauke: I've just learned about it, seems like what I need. although documentation isn't clear on how it could break things |
| 2024-11-18 20:57:27 +0100 | <mauke> | are you familiar with getContents? |
| 2024-11-18 20:57:47 +0100 | <SrPx> | interestingly, seems like there is a SO thread about exactly that: https://stackoverflow.com/questions/13263692/when-is-unsafeinterleaveio-unsafe |
| 2024-11-18 20:57:50 +0100 | <SrPx> | mauke: no, what is that? |
| 2024-11-18 20:59:29 +0100 | <mauke> | gives you stdin as a lazy string |
| 2024-11-18 20:59:30 +0100 | <davean> | SrPx: It will run the whole IO, but IO can pass and produce lazy values just fine |
| 2024-11-18 20:59:34 +0100 | <SrPx> | "In general, it is up to you to prove that your use of unsafeInterleaveIO is safe. If you call unsafeInterleaveIO x, then you have to prove that x can be called at any time and still produce the same output." |
| 2024-11-18 20:59:59 +0100 | <SrPx> | ah, based on this I'm good to use it. reduce() will always return the same result, even though it mutates memory internally. ty guys |
| 2024-11-18 21:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-18 21:00:40 +0100 | <davean> | SrPx: Then it might be pure and not involve IO at all? |
| 2024-11-18 21:00:41 +0100 | <SrPx> | and it works! |
| 2024-11-18 21:00:42 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-18 21:00:53 +0100 | <mauke> | is reduce a C function? |
| 2024-11-18 21:01:08 +0100 | <SrPx> | davean: you mean in the sense I could wrap unsafePerformIO into the reduce() function I get from C? |
| 2024-11-18 21:01:18 +0100 | <SrPx> | davean: that might be a better idea actually... |
| 2024-11-18 21:01:29 +0100 | <mauke> | if so, you can just import it at a pure type |
| 2024-11-18 21:01:56 +0100 | <SrPx> | mauke: makes sense |
| 2024-11-18 21:02:06 +0100 | <mauke> | (of course, that won't work if it takes/returns pointers) |
| 2024-11-18 21:02:25 +0100 | <SrPx> | so, as long as I guarantee reduce acts purely, it is ok to import it as a pure function, even thought it isn't |
| 2024-11-18 21:02:38 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 21:02:41 +0100 | <davean> | C FFI doesn't mean you have to have IO |
| 2024-11-18 21:02:52 +0100 | <mauke> | runST exists |
| 2024-11-18 21:03:05 +0100 | <mauke> | so I figure if it is morally "like ST", then it should be OK |
| 2024-11-18 21:04:46 +0100 | <davean> | Yah this sounds more ST than IO |
| 2024-11-18 21:09:54 +0100 | Square | (~Square@user/square) Square |
| 2024-11-18 21:10:30 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-18 21:12:11 +0100 | <SrPx> | it works flawlessly guys. the interaction count decreases based on the terms I actually observe in Haskell. so basically Haskell-side laziness propagates to HVM in the sense if you discard an HVM term Haskell-side, you won't pay for it |
| 2024-11-18 21:12:15 +0100 | <SrPx> | and that's extremely cool |
| 2024-11-18 21:12:17 +0100 | <SrPx> | ty |
| 2024-11-18 21:12:46 +0100 | <SrPx> | like mindblowingly cool |
| 2024-11-18 21:13:41 +0100 | kaskal- | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) |