IRCBrowse

2023/05/09

2023-05-09 00:00:51 +0200chomwitt(~chomwitt@2a02:587:7a14:af00:9080:176a:ae9d:81cc) (Remote host closed the connection)
2023-05-09 00:04:59 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 265 seconds)
2023-05-09 00:07:50 +0200 <Inst> axman6: I'm begging another professional Haskeller for tutorials on laziness (I know about thunks, I know about some standard lazy coding patterns, I've skimmed through parts of Parallel and Concurrent Programming in Haskell)
2023-05-09 00:08:24 +0200 <Inst> tbh, I think long-term, making Haskell's laziness desirable (i.e, FP is popping its head everywhere, laziness a la Haskell, not so much) and a selling feature would at least be interesting
2023-05-09 00:09:03 +0200oo_miguel(~Thunderbi@77.252.47.78) (Ping timeout: 256 seconds)
2023-05-09 00:13:01 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-09 00:13:47 +0200freeside(~mengwong@103.252.202.85)
2023-05-09 00:16:51 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-05-09 00:17:25 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds)
2023-05-09 00:18:26 +0200freeside(~mengwong@103.252.202.85) (Ping timeout: 268 seconds)
2023-05-09 00:18:35 +0200jargon(~jargon@184.101.78.160)
2023-05-09 00:26:53 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-05-09 00:30:42 +0200 <roboguy_> Inst: What sort of topics would you want it to cover?
2023-05-09 00:33:52 +0200 <Inst> it basically comes down to an understanding of GHC's unstable evaluation model beyond the stuff Bird covered (lazy is outside in, eager / strict is inside out), how sharing creates space leaks, how to exploit laziness for fun and profit
2023-05-09 00:34:21 +0200 <Inst> might actually be better to cover the topics in reverse, because everyone who needs to know the information needs to get all the way to "how not to space leak yourself to death"
2023-05-09 00:34:42 +0200 <Inst> I'm hoping HLS will eventually come with a space leak warning overlay, tbh
2023-05-09 00:35:23 +0200 <ncf> (i think i told a lie: elements of Reader r a commute with all other elements of Reader r a, not generally with State r a. it seems like Reader r is the "largest commutative submonad" of State r, but i don't think you get it from the centre construction, which is weird)
2023-05-09 00:36:21 +0200 <vulfe> I feel like that also has a name but I can't summon it to mind
2023-05-09 00:37:12 +0200 <c_wraith> Inst: the single most important topic is "why -XStrict is not the answer to the question you have"
2023-05-09 00:37:21 +0200 <c_wraith> Need to get people out of that cargo cult
2023-05-09 00:39:17 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-05-09 00:42:06 +0200 <geekosaur> sadly I think you'll have to convince SPJ first, since he's on record as considering lazy-by-default a mistake
2023-05-09 00:46:43 +0200 <Inst> c_wraith: the way I understand it, -XStrict is equivalent to admitting you suck
2023-05-09 00:47:04 +0200 <Inst> I suck, and I don't even use -XStrict
2023-05-09 00:47:37 +0200 <c_wraith> There are very specific cases where it's a great time-saver.
2023-05-09 00:47:49 +0200 <geekosaur> it's the bad parts of OCaml minus the good parts
2023-05-09 00:49:04 +0200jero98772(~jero98772@2800:484:1d84:9000::2) (Ping timeout: 248 seconds)
2023-05-09 00:49:36 +0200 <Inst> geekosaur: that's a subjective interpretation of his comments
2023-05-09 00:49:44 +0200 <Inst> Haskell is, I think, the only major lazy-by-default language?
2023-05-09 00:50:03 +0200 <Inst> it's more, "the market for laziness related research and production is tapped"
2023-05-09 01:02:14 +0200jero98772(~jero98772@2800:484:1d84:9000::2)
2023-05-09 01:03:27 +0200 <jackdk> ISTM that if you really want the code reuse and the purity, you have to have laziness. See https://www.reddit.com/r/haskell/comments/l98v73/can_you_share_a_realworld_anecdote_of_when/glgun65/ and https://www.reddit.com/r/haskell/comments/5xge0v/today_i_used_laziness_for/
2023-05-09 01:04:31 +0200taupiqueur1(~taupiqueu@2a02-842a-8180-4601-64af-550d-b7f1-261b.rev.sfr.net)
2023-05-09 01:05:09 +0200mmhat(~mmh@p200300f1c706687dee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2023-05-09 01:05:31 +0200mmhat(~mmh@p200300f1c706684eee086bfffe095315.dip0.t-ipconnect.de)
2023-05-09 01:06:08 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 248 seconds)
2023-05-09 01:06:25 +0200gurkenglas(~gurkengla@dynamic-046-114-179-106.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-05-09 01:06:28 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-18c4-e25f-ca07-3bb1.rev.sfr.net) (Ping timeout: 245 seconds)
2023-05-09 01:06:51 +0200taupiqueur(~taupiqueu@2a02-842a-8180-4601-18c4-e25f-ca07-3bb1.rev.sfr.net) (Ping timeout: 256 seconds)
2023-05-09 01:06:58 +0200emmanuelux_(~emmanuelu@user/emmanuelux)
2023-05-09 01:08:04 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer)
2023-05-09 01:08:17 +0200waleee(~waleee@h-176-10-137-138.NA.cust.bahnhof.se)
2023-05-09 01:08:44 +0200 <geekosaur> https://news.ycombinator.com/item?id=23454642 which claims among other things that purity is actually independent of laziness
2023-05-09 01:08:59 +0200 <geekosaur> although laziness is what revealed it
2023-05-09 01:12:32 +0200 <int-e> Didn't SPJ say "laziness kept us pure"?
2023-05-09 01:13:53 +0200 <geekosaur> that one implies the opposite direction, that laziness requires purity
2023-05-09 01:14:05 +0200Guest|20(~Guest|20@192.228.163.95)
2023-05-09 01:14:14 +0200 <int-e> In any case we've learned a lot from lazy by default.
2023-05-09 01:14:45 +0200 <int-e> geekosaur: It pretty much does, because reasoning about effects when evaluation order is unpredictable is very hard.
2023-05-09 01:15:17 +0200 <geekosaur> and in any case my point is there's a lot of people who believe what I said earlier, which is making laziness a hard sell
2023-05-09 01:15:23 +0200 <int-e> Sure, we still have unsafePerformIO and ST and the state# token trick
2023-05-09 01:17:18 +0200 <int-e> well, it's not independent if one of the 4 possible combinations (pure,strict), (impure, strict), (pure, lazy), (impure, lazy) is too wild for programming.
2023-05-09 01:17:46 +0200xff0x(~xff0x@2405:6580:b080:900:8bd4:f87d:a79b:d165) (Quit: xff0x)
2023-05-09 01:19:22 +0200 <int-e> (while the other three all make sense)
2023-05-09 01:20:51 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-05-09 01:20:51 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2023-05-09 01:21:01 +0200acidjnk(~acidjnk@p200300d6e7072f29d032399e5afc9b1f.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-05-09 01:21:05 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2023-05-09 01:21:21 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-05-09 01:22:17 +0200nate2(~nate@98.45.169.16)
2023-05-09 01:23:02 +0200xff0x(~xff0x@2405:6580:b080:900:7ba2:121c:2a4c:a692)
2023-05-09 01:27:15 +0200nate2(~nate@98.45.169.16) (Ping timeout: 256 seconds)
2023-05-09 01:29:15 +0200mauke_(~mauke@user/mauke)
2023-05-09 01:31:12 +0200mauke(~mauke@user/mauke) (Ping timeout: 268 seconds)
2023-05-09 01:31:12 +0200mauke_mauke
2023-05-09 01:31:33 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-05-09 01:40:27 +0200Guest|20(~Guest|20@192.228.163.95) (Ping timeout: 268 seconds)
2023-05-09 01:51:11 +0200phma(phma@2001:5b0:210b:ef98:fc16:fb7:1e9c:8673)
2023-05-09 01:57:50 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-05-09 01:57:50 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-05-09 01:57:50 +0200wroathe(~wroathe@user/wroathe)
2023-05-09 02:05:30 +0200freeside(~mengwong@103.252.202.85)
2023-05-09 02:10:03 +0200freeside(~mengwong@103.252.202.85) (Ping timeout: 268 seconds)
2023-05-09 02:10:47 +0200pyook(~puke@user/puke) (Read error: Connection reset by peer)
2023-05-09 02:10:48 +0200jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2023-05-09 02:12:13 +0200 <Inst> also, i'm trying to do FP in Python
2023-05-09 02:12:21 +0200 <Inst> my eyes are bleeding right now because all of a sudden, and this is a boon for laziness
2023-05-09 02:12:30 +0200zeenk(~zeenk@2a02:2f04:a105:f00::7fe) (Quit: Konversation terminated!)
2023-05-09 02:12:33 +0200 <Inst> I have to care about what order I'm doing my maps in
2023-05-09 02:17:56 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 250 seconds)
2023-05-09 02:20:07 +0200ava[m]1(~ava2607ma@2001:470:69fc:105::3:5307)
2023-05-09 02:21:02 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-05-09 02:30:03 +0200freeside(~mengwong@103.252.202.85)
2023-05-09 02:34:33 +0200erisco(~erisco@d24-141-66-165.home.cgocable.net)
2023-05-09 02:34:43 +0200freeside(~mengwong@103.252.202.85) (Ping timeout: 268 seconds)
2023-05-09 02:38:21 +0200_leo___(~emmanuelu@user/emmanuelux)
2023-05-09 02:40:29 +0200emmanuelux_(~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer)
2023-05-09 02:47:09 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 256 seconds)
2023-05-09 02:48:17 +0200pavonia(~user@user/siracusa)
2023-05-09 02:50:32 +0200mmhat(~mmh@p200300f1c706684eee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8)
2023-05-09 02:56:11 +0200freeside(~mengwong@103.252.202.85)
2023-05-09 03:00:45 +0200freeside(~mengwong@103.252.202.85) (Ping timeout: 256 seconds)
2023-05-09 03:01:31 +0200tanyastopguy(~username@2600:1700:4010:6d20:3aea:f984:552:57de) (Remote host closed the connection)
2023-05-09 03:04:40 +0200johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in)
2023-05-09 03:05:12 +0200johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net)
2023-05-09 03:05:50 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds)
2023-05-09 03:10:33 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-09 03:16:40 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-09 03:18:30 +0200_leo___(~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer)
2023-05-09 03:19:27 +0200_leo___(~emmanuelu@user/emmanuelux)
2023-05-09 03:20:25 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Ping timeout: 260 seconds)
2023-05-09 03:20:35 +0200xff0x(~xff0x@2405:6580:b080:900:7ba2:121c:2a4c:a692) (Ping timeout: 256 seconds)
2023-05-09 03:21:15 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1)
2023-05-09 03:28:02 +0200freeside(~mengwong@103.252.202.85)
2023-05-09 03:29:19 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-05-09 03:33:37 +0200freeside(~mengwong@103.252.202.85) (Ping timeout: 256 seconds)
2023-05-09 03:34:32 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9)
2023-05-09 03:37:19 +0200learner-monad(~ehanneken@user/learner-monad) (Ping timeout: 260 seconds)
2023-05-09 03:38:53 +0200pyook(~puke@user/puke)
2023-05-09 03:39:05 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9) (Ping timeout: 260 seconds)
2023-05-09 03:45:45 +0200waleee(~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 240 seconds)
2023-05-09 03:46:08 +0200freeside1(~mengwong@103.252.202.85) (Ping timeout: 240 seconds)
2023-05-09 03:56:05 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-05-09 03:58:54 +0200ec(~ec@gateway/tor-sasl/ec)
2023-05-09 03:59:49 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-05-09 04:01:37 +0200_leo___(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2023-05-09 04:03:56 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-05-09 04:03:56 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-05-09 04:03:56 +0200finn_elijaFinnElija
2023-05-09 04:12:20 +0200Albina_Pavlovna(~Albina_Pa@2603-7000-76f0-76e0-f453-5744-a112-fdd6.res6.spectrum.com)
2023-05-09 04:13:31 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-09 04:15:26 +0200nate2(~nate@98.45.169.16)
2023-05-09 04:18:23 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds)
2023-05-09 04:19:59 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 04:21:16 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-05-09 04:21:25 +0200tanyastopguy(~tanyastop@2600:1700:4010:6d20:3aea:f984:552:57de)
2023-05-09 04:21:52 +0200td_(~td@i53870906.versanet.de) (Ping timeout: 250 seconds)
2023-05-09 04:23:37 +0200td_(~td@i53870936.versanet.de)
2023-05-09 04:25:56 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 04:27:34 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 04:28:31 +0200Me-me(~me-me@2602:ff16:3:0:1:dc:beef:d00d) (Changing host)
2023-05-09 04:28:31 +0200Me-me(~me-me@user/me-me)
2023-05-09 04:29:36 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 04:33:45 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 04:34:58 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 04:35:32 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9)
2023-05-09 04:36:31 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Ping timeout: 256 seconds)
2023-05-09 04:38:07 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1)
2023-05-09 04:42:25 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-05-09 04:43:40 +0200Albina_Pavlovna(~Albina_Pa@2603-7000-76f0-76e0-f453-5744-a112-fdd6.res6.spectrum.com) (Quit: ZZZzzz…)
2023-05-09 04:43:57 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-05-09 04:48:25 +0200dsrt^(~dsrt@c-76-105-96-13.hsd1.ga.comcast.net) (Read error: Connection reset by peer)
2023-05-09 04:49:20 +0200dsrt^(~dsrt@c-76-105-96-13.hsd1.ga.comcast.net)
2023-05-09 05:01:36 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 05:02:00 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 05:02:22 +0200nick4(~nick@2600:8807:9103:b700:d8e6:a031:6c5c:b040)
2023-05-09 05:02:27 +0200slack1256(~slack1256@181.42.51.157)
2023-05-09 05:04:38 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 05:06:48 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 05:10:08 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-09 05:11:04 +0200goodtimeswithtom(~goodtimes@2600:1700:4010:6d20:3aea:f984:552:57de)
2023-05-09 05:14:22 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 05:14:41 +0200jero98772(~jero98772@2800:484:1d84:9000::2) (Remote host closed the connection)
2023-05-09 05:16:03 +0200Albina_Pavlovna(~Albina_Pa@047-230-050-118.res.spectrum.com)
2023-05-09 05:16:09 +0200Albina_Pavlovna(~Albina_Pa@047-230-050-118.res.spectrum.com) (Client Quit)
2023-05-09 05:16:48 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 240 seconds)
2023-05-09 05:17:41 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 05:19:22 +0200nate2(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2023-05-09 05:20:09 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 05:22:08 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 248 seconds)
2023-05-09 05:22:31 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 05:27:28 +0200goodtimeswithtom(~goodtimes@2600:1700:4010:6d20:3aea:f984:552:57de) (Quit: Client closed)
2023-05-09 05:28:01 +0200Guest4444(~Guest44@101.78.229.4)
2023-05-09 05:28:19 +0200Guest4444ycli
2023-05-09 05:30:13 +0200ycli(~Guest44@101.78.229.4) (Client Quit)
2023-05-09 05:30:18 +0200gabiruh(~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in)
2023-05-09 05:30:36 +0200gabiruh(~gabiruh@vps19177.publiccloud.com.br)
2023-05-09 05:31:20 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-05-09 05:34:20 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 05:35:32 +0200goodtimeswithtom(~goodtimes@2600:1700:4010:6d20:3aea:f984:552:57de)
2023-05-09 05:36:12 +0200shailangsa(~shailangs@host86-186-136-24.range86-186.btcentralplus.com)
2023-05-09 05:36:27 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 05:42:25 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-09 05:42:25 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 05:50:55 +0200rf(~rf@2605:59c8:179c:f610:3bd2:4ecb:9b16:aa4f) (Ping timeout: 260 seconds)
2023-05-09 05:54:41 +0200goodtimeswithtom(~goodtimes@2600:1700:4010:6d20:3aea:f984:552:57de) (Quit: Client closed)
2023-05-09 05:57:01 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 06:01:39 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 265 seconds)
2023-05-09 06:06:26 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 06:07:28 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-05-09 06:11:04 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 250 seconds)
2023-05-09 06:15:17 +0200notzmv(~zmv@user/notzmv)
2023-05-09 06:20:37 +0200mbuf(~Shakthi@49.207.178.186)
2023-05-09 06:27:28 +0200nick4(~nick@2600:8807:9103:b700:d8e6:a031:6c5c:b040) (Ping timeout: 240 seconds)
2023-05-09 06:28:49 +0200cheater(~Username@user/cheater) (Remote host closed the connection)
2023-05-09 06:30:45 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 06:34:38 +0200cheater(~Username@user/cheater)
2023-05-09 06:35:50 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 268 seconds)
2023-05-09 06:36:42 +0200cheater_(~Username@user/cheater)
2023-05-09 06:39:13 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-05-09 06:39:18 +0200cheater_cheater
2023-05-09 06:41:41 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 06:46:00 +0200zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2023-05-09 06:46:19 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 06:48:06 +0200zaquest(~notzaques@5.130.79.72)
2023-05-09 06:51:56 +0200califax_(~califax@user/califx)
2023-05-09 06:52:27 +0200gehmehgeh(~user@user/gehmehgeh)
2023-05-09 06:52:48 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-05-09 06:54:08 +0200califax(~califax@user/califx) (Ping timeout: 240 seconds)
2023-05-09 06:54:08 +0200califax_califax
2023-05-09 07:04:57 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 07:08:18 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-05-09 07:09:20 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 248 seconds)
2023-05-09 07:15:45 +0200michalz(~michalz@185.246.207.218)
2023-05-09 07:22:08 +0200slack1256(~slack1256@181.42.51.157) (Remote host closed the connection)
2023-05-09 07:22:48 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-05-09 07:29:07 +0200trev(~trev@user/trev)
2023-05-09 07:38:08 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-05-09 07:44:05 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 07:45:56 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 07:48:07 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2023-05-09 07:52:49 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 265 seconds)
2023-05-09 07:54:00 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 07:54:09 +0200chomwitt(~chomwitt@2a02:587:7a14:af00:9080:176a:ae9d:81cc)
2023-05-09 07:56:04 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 07:58:15 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 08:00:47 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 264 seconds)
2023-05-09 08:01:17 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 08:04:11 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 08:04:38 +0200monochrom(trebla@216.138.220.146) (Ping timeout: 268 seconds)
2023-05-09 08:07:23 +0200monochrom(trebla@216.138.220.146)
2023-05-09 08:08:54 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-05-09 08:08:57 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 08:08:59 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 08:10:09 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 08:26:02 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-05-09 08:36:37 +0200falafel(~falafel@2603-8000-d700-115c-6069-6909-c684-7d8e.res6.spectrum.com)
2023-05-09 08:38:25 +0200 <jade[m]1> haha
2023-05-09 08:39:13 +0200falafel(~falafel@2603-8000-d700-115c-6069-6909-c684-7d8e.res6.spectrum.com) (Remote host closed the connection)
2023-05-09 08:40:03 +0200iteratee(~kyle@162.218.222.207) (Read error: Connection reset by peer)
2023-05-09 08:40:09 +0200falafel(~falafel@2603-8000-d700-115c-6069-6909-c684-7d8e.res6.spectrum.com)
2023-05-09 08:40:50 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 08:43:30 +0200freeside(~mengwong@202.161.55.11)
2023-05-09 08:43:49 +0200iteratee(~kyle@162.218.222.207)
2023-05-09 08:45:17 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 08:46:41 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 08:47:44 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net)
2023-05-09 08:49:24 +0200acidjnk(~acidjnk@p200300d6e7072f24c1846b175da7e4e4.dip0.t-ipconnect.de)
2023-05-09 08:51:30 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 268 seconds)
2023-05-09 08:51:55 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net) (Ping timeout: 248 seconds)
2023-05-09 08:52:18 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 265 seconds)
2023-05-09 08:54:30 +0200oo_miguel(~Thunderbi@77.252.47.78)
2023-05-09 09:00:35 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 256 seconds)
2023-05-09 09:13:28 +0200 <chreekat> I think it's nice that I don't have to reason about evaluation order. I don't think that's just thanks to purity. The function that's nice to write is also the function that solves the business needs in most circumstances. But I do think learning to deal with space leaks needs to happen a lot sooner in Haskell education. If we raised the overall level of understanding (and tooling), it wouldn't be any worse than other practical, unavoidable
2023-05-09 09:13:28 +0200 <chreekat> problems in computer engineering
2023-05-09 09:16:13 +0200nate2(~nate@98.45.169.16)
2023-05-09 09:17:53 +0200 <Athas> Well sure, all tools have problems. I will say that space leaks have some subtleties that make them worse than the equivalent in your bog standard strict language.
2023-05-09 09:18:50 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 09:18:57 +0200 <maralorn> Yeah, I'd agree that laziness would be clearly superior if space leaks weren't a problem. I remember Edsko saying that 50% of welltypeds consulting work is fixing space leaks.
2023-05-09 09:20:14 +0200 <maralorn> So it definitely is a trade off.
2023-05-09 09:20:54 +0200 <Athas> I wonder how often an enterprise Java consultancy is hired to fix null pointer exceptions.
2023-05-09 09:21:07 +0200 <Athas> Or, uh, malformed XML? I really have no idea what the problems are in that space.
2023-05-09 09:21:15 +0200nate2(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2023-05-09 09:22:03 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-05-09 09:23:10 +0200 <maralorn> A good C programmer has to be a memory safety wizard a good Haskell programmer has to be a memory efficiency wizard...
2023-05-09 09:23:35 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 260 seconds)
2023-05-09 09:24:36 +0200 <jade[m]1> I feel like the problem with space leaks is that you won't notice unless you monitor it
2023-05-09 09:24:36 +0200 <maralorn> But yeah that's why we should really focus on teaching people stuff like nothunk, strict data types and memory profiling.
2023-05-09 09:24:41 +0200CiaoSen(~Jura@dynamic-046-114-219-059.46.114.pool.telefonica.de)
2023-05-09 09:25:31 +0200 <c_wraith> I still think it should be easy to design tooling to warn people when they're doing something foolish, because I can tell immediately when I look at code if it was written by someone who understood laziness or not.
2023-05-09 09:25:40 +0200 <jade[m]1> jade[m]1: so you have to know about it to even suspect there might be space leaks
2023-05-09 09:25:52 +0200 <c_wraith> But whenever I try to hammer out exactly what the rules are, it's hard.
2023-05-09 09:26:00 +0200 <jade[m]1> mhm
2023-05-09 09:26:04 +0200mncheck(~mncheck@193.224.205.254)
2023-05-09 09:26:37 +0200mc47(~mc47@xmonad/TheMC47)
2023-05-09 09:26:38 +0200 <c_wraith> but like... strict data? ugh. I get so sick of libraries fobbing their work off on me like that.
2023-05-09 09:27:20 +0200 <Athas> Memory safety is obviously a huge problem in C, but there are tools (Valgrind, ASAN) that can detect problems when they occur. In Haskell, a "space leak" cannot be rigorously defined, so tooling is difficult to construct.
2023-05-09 09:27:34 +0200ccapndave(~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch)
2023-05-09 09:27:37 +0200 <Athas> Detonating the program whenever a thunk is created is obviously not useful.
2023-05-09 09:28:51 +0200 <jade[m]1> what are some resources that one can read to get better in working with laziness and avoiding space leaks?
2023-05-09 09:28:51 +0200 <jade[m]1> Or is it more experience and intuition?
2023-05-09 09:29:43 +0200 <maralorn> c_wraith: What do you mean with fobbing work onto you?
2023-05-09 09:30:17 +0200ubert(~Thunderbi@p200300ecdf42c686843d6adf8e2b9083.dip0.t-ipconnect.de)
2023-05-09 09:30:33 +0200 <c_wraith> maralorn: I mean I'm tired of libraries adding too much strictness and breaking my correct use of their correct laziness. The developers could have just written correct code instead.
2023-05-09 09:30:51 +0200 <chreekat> jade: I think if you use heap profiling and eventlog2html a couple times you'll already be ahead of the curve
2023-05-09 09:31:05 +0200 <Athas> I too often wish that other people wrote correct code all the time.
2023-05-09 09:31:14 +0200zeenk(~zeenk@2a02:2f04:a105:f00::7fe)
2023-05-09 09:31:17 +0200 <sm> jade: there have been one or two good guides written .. possobly searching the haskell reddit will find them
2023-05-09 09:31:31 +0200 <c_wraith> jade[m]1: this is the most important one: https://apfelmus.nfshost.com/blog/2013/08/21-space-invariants.html
2023-05-09 09:31:39 +0200 <chreekat> The trouble is that I had to stop and try to remember the name of eventlog2html, and I don't entirely remember how to enable heap profiling, and I'm not sure if there aren't better tools. ghc-debug is getting more useful
2023-05-09 09:31:56 +0200 <chreekat> These are the seemingly-simple things we could do to actually make space leaks less daunting
2023-05-09 09:33:35 +0200merijn(~merijn@c-001-001-013.client.esciencecenter.eduvpn.nl)
2023-05-09 09:37:10 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-05-09 09:45:40 +0200ubert(~Thunderbi@p200300ecdf42c686843d6adf8e2b9083.dip0.t-ipconnect.de) (Quit: ubert)
2023-05-09 09:46:57 +0200 <jade[m]1> <c_wraith> "jade: this is the most important..." <- Thank you very much, that was an interesting read. I need to think about some of the stuff presented in more depth though.
2023-05-09 09:46:57 +0200 <jade[m]1> What gave me a very interesting insight is the reason that `seq` takes two values, in a sense that it's linking them and _not_ "evaluating" one of them
2023-05-09 09:47:47 +0200cfricke(~cfricke@user/cfricke)
2023-05-09 09:48:22 +0200 <c_wraith> yeah, that's incredibly important to understand.
2023-05-09 09:50:21 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:6722:77f:2791:a818)
2023-05-09 09:52:51 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 09:54:11 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-05-09 09:58:08 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 09:58:20 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-05-09 10:00:05 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 256 seconds)
2023-05-09 10:04:51 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli)
2023-05-09 10:05:18 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2023-05-09 10:07:28 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
2023-05-09 10:07:29 +0200 <maralorn> The article says any implementation of lookup of the form lookup key container = container `seq` ... fulfills the strictness property ∀ key. (lookup key container = ⊥ → container = ⊥)
2023-05-09 10:07:39 +0200 <maralorn> I don't see it.
2023-05-09 10:08:48 +0200 <maralorn> Which means I am not sure I understand the difference between space invariants and strictness.
2023-05-09 10:09:46 +0200MajorBiscuit(~MajorBisc@2001:1c00:2492:e200:561f:c4dd:78fa:8040)
2023-05-09 10:10:10 +0200 <maralorn> Isn't a is in WHNF implies b is in WHNF equivalent to b is bottom implies a is bottom?
2023-05-09 10:10:16 +0200dontdieych(~alarm@132.226.169.184)
2023-05-09 10:10:19 +0200falafel(~falafel@2603-8000-d700-115c-6069-6909-c684-7d8e.res6.spectrum.com) (Ping timeout: 248 seconds)
2023-05-09 10:11:04 +0200ccapndave(~ccapndave@xcpe-62-167-164-99.cgn.res.adslplus.ch) (Quit: Textual IRC Client: www.textualapp.com)
2023-05-09 10:11:25 +0200 <maralorn> Well, yeah I am not convinced either in the abstract. Still wonder if it is true enough under reasonable assumptions.
2023-05-09 10:14:12 +0200MajorBiscuit(~MajorBisc@2001:1c00:2492:e200:561f:c4dd:78fa:8040) (Client Quit)
2023-05-09 10:14:16 +0200 <[Leary]> maralorn: Maybe the bracketing is wrong? (forall key. lookup key container = _|_) ==> container = _|_
2023-05-09 10:15:33 +0200MajorBiscuit(~MajorBisc@2001:1c00:2492:e200:561f:c4dd:78fa:8040)
2023-05-09 10:15:46 +0200 <maralorn> [Leary]: That's a much less interesting property.
2023-05-09 10:17:58 +0200 <maralorn> c_wraith: It seems to me the article is saying that space invariants are a good solution. Making data types strict is introducing a space invariant. So why don't you like it when libraries do that?
2023-05-09 10:18:45 +0200hugo(znc@verdigris.lysator.liu.se)
2023-05-09 10:19:42 +0200MajorBiscuit(~MajorBisc@2001:1c00:2492:e200:561f:c4dd:78fa:8040) (Client Quit)
2023-05-09 10:20:17 +0200zeenk(~zeenk@2a02:2f04:a105:f00::7fe) (Remote host closed the connection)
2023-05-09 10:20:20 +0200MajorBiscuit(~MajorBisc@2001:1c00:2492:e200:561f:c4dd:78fa:8040)
2023-05-09 10:20:40 +0200zeenk(~zeenk@2a02:2f04:a105:f00::fba)
2023-05-09 10:22:41 +0200gehmehgeh(~user@user/gehmehgeh) (Remote host closed the connection)
2023-05-09 10:24:08 +0200pharonix71(~pharonix7@user/pharonix71) (Ping timeout: 240 seconds)
2023-05-09 10:24:14 +0200 <c_wraith> maralorn: because it's usually the wrong space invariant in libraries. A library shouldn't assume it knows better than its user about when the user is allowed to tie knots. So I'd prefer have the space invariants be on the functions, not the data structure itself. Let users use Haskell.
2023-05-09 10:24:40 +0200pharonix71(~pharonix7@user/pharonix71)
2023-05-09 10:24:40 +0200 <maralorn> I see.
2023-05-09 10:25:28 +0200 <c_wraith> About the only time I want the data structure itself to own the strictness is in cases where you want to take advantage of unpacking small fields.
2023-05-09 10:26:35 +0200 <maralorn> Does the same apply for application code? I decided to make my longrunning state leak safe by making the datatype completely strict. Do you think it would be better to carefully make all functions on the state strict?
2023-05-09 10:28:48 +0200 <c_wraith> better? absolutely. I think basically every definition have its space invariants documented. Now, in the real world... If you've already got a lot of code, I'd totally understand if retrofitting existing code is more work than it's worth
2023-05-09 10:29:08 +0200 <merijn> maralorn: I think it is best to make concious decisions about strict vs lazy
2023-05-09 10:29:12 +0200 <fbytez> What's the typical method to convert a ByteString to a String?
2023-05-09 10:29:36 +0200 <merijn> fbytez: Well, the typical method is to not, because you typically convert to Text
2023-05-09 10:29:51 +0200 <merijn> fbytez: Although going from Text to String is trivial if it's really required
2023-05-09 10:30:36 +0200 <tomsmeding> (there is a direct route via https://hackage.haskell.org/package/utf8-string , but composing Data.Text.unpack and Data.Text.Encoding.decode* is probably not worse)
2023-05-09 10:30:39 +0200mmhat(~mmh@p200300f1c706684eee086bfffe095315.dip0.t-ipconnect.de)
2023-05-09 10:30:39 +0200 <merijn> maralorn: if, for example, your state is relatively small then making everything strict to force it to be small is the way to go, yes
2023-05-09 10:31:17 +0200 <maralorn> c_wraith: The expected pay off would be a bit more performance?
2023-05-09 10:31:38 +0200 <maralorn> merijn: My state is sadly frightingly big.
2023-05-09 10:31:51 +0200 <maralorn> 10MB or so.
2023-05-09 10:32:37 +0200 <c_wraith> I wouldn't expect it to perform better to have explicit space invariants unless you're in a very weird case. I'd just expect the behavior to be more... explicit.
2023-05-09 10:34:34 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 10:35:04 +0200mmhat(~mmh@p200300f1c706684eee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2023-05-09 10:35:08 +0200pharonix71(~pharonix7@user/pharonix71) (Remote host closed the connection)
2023-05-09 10:37:28 +0200 <fbytez> tomsmeding, merijn, Thanks.
2023-05-09 10:37:31 +0200pharonix71(~pharonix7@user/pharonix71)
2023-05-09 10:38:23 +0200 <merijn> fbytez: Data.Text.Encoding from text has decoders for UTF-8/16/32
2023-05-09 10:39:11 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 10:40:31 +0200michalz(~michalz@185.246.207.218) (Remote host closed the connection)
2023-05-09 10:42:33 +0200MasseR46(thelounge@2001:bc8:62c:1e19::1)
2023-05-09 10:42:47 +0200chomwitt(~chomwitt@2a02:587:7a14:af00:9080:176a:ae9d:81cc) (Ping timeout: 264 seconds)
2023-05-09 10:44:33 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 10:46:16 +0200michalz(~michalz@185.246.207.205)
2023-05-09 10:48:49 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 250 seconds)
2023-05-09 10:56:49 +0200michalz(~michalz@185.246.207.205) (Remote host closed the connection)
2023-05-09 10:58:42 +0200ubert(~Thunderbi@2a02:8109:abc0:6434:81f:756b:c2fe:5d83)
2023-05-09 10:59:32 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:4165:ceb6:19a8:1e1e)
2023-05-09 11:01:26 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9) (Remote host closed the connection)
2023-05-09 11:05:48 +0200michalz(~michalz@185.246.207.197)
2023-05-09 11:07:23 +0200pharonix71(~pharonix7@user/pharonix71) (Remote host closed the connection)
2023-05-09 11:07:55 +0200pharonix71(~pharonix7@user/pharonix71)
2023-05-09 11:09:13 +0200shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 256 seconds)
2023-05-09 11:09:48 +0200notzmv(~zmv@user/notzmv)
2023-05-09 11:17:05 +0200mei(~mei@user/mei) (Ping timeout: 240 seconds)
2023-05-09 11:17:06 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2023-05-09 11:17:24 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2023-05-09 11:26:41 +0200__monty__(~toonn@user/toonn)
2023-05-09 11:28:33 +0200pharonix71(~pharonix7@user/pharonix71) (Remote host closed the connection)
2023-05-09 11:28:59 +0200pharonix71(~pharonix7@user/pharonix71)
2023-05-09 11:46:10 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2023-05-09 11:48:48 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 11:52:10 +0200 <maralorn> c_wraith: I wondered mainly whether it performs better than using strict datatypes.
2023-05-09 11:53:38 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 11:53:48 +0200 <maralorn> Which have the nice property of enforcing space invariants on the type level.
2023-05-09 11:54:02 +0200chomwitt(~chomwitt@ppp-94-67-206-188.home.otenet.gr)
2023-05-09 11:56:04 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 11:57:45 +0200 <maralorn> I am still quite confused about the performance implications of laziness because people say laziness is great for performance, which makes total sense if it avoids unnecessary computation or helps keeping the memory footprint low, but in situations where those two don't apply it is my impression that ghc does a lot of strictness analysis and thus can make code faster if it is stricter?
2023-05-09 11:57:48 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-09 12:00:28 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 12:01:32 +0200 <geekosaur> the "faster if stricter" aspect mostly comes from using unboxed values where possible, thereby avoiding a pointer indirection per access
2023-05-09 12:01:51 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-05-09 12:01:56 +0200 <geekosaur> laziness operates in the large, strictness in the small
2023-05-09 12:05:44 +0200zer0bitz_(~zer0bitz@2001:2003:f443:d600:cc73:5fe2:e3b9:4425)
2023-05-09 12:06:36 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds)
2023-05-09 12:07:01 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 256 seconds)
2023-05-09 12:07:35 +0200zer0bitz(~zer0bitz@2001:2003:f443:d600:14e6:e58c:1d60:2677) (Ping timeout: 256 seconds)
2023-05-09 12:09:17 +0200ddellacosta(~ddellacos@146.70.185.10) (Ping timeout: 256 seconds)
2023-05-09 12:09:18 +0200chele(~chele@user/chele)
2023-05-09 12:11:24 +0200ddellacosta(~ddellacos@146.70.166.177)
2023-05-09 12:16:07 +0200maroloccio(~marolocci@90.167.166.125)
2023-05-09 12:19:41 +0200 <maralorn> Makes sense.
2023-05-09 12:21:09 +0200 <maralorn> So the recommendation I’d expect is "it depends" what I often hear is "don’t sacrifice laziness"
2023-05-09 12:22:50 +0200 <[exa]> "it depends" mostly on what the compiler is able to assume as a safely&usefully strict operation
2023-05-09 12:23:06 +0200 <geekosaur> right. the recommendation I most hear is "examine the core"
2023-05-09 12:24:10 +0200 <geekosaur> of course that's not especially convenient
2023-05-09 12:24:17 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving)
2023-05-09 12:24:31 +0200 <geekosaur> since core is kinda its own language and requires some experience to understand
2023-05-09 12:25:50 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 260 seconds)
2023-05-09 12:26:44 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 12:26:52 +0200 <maralorn> I mean that’s why I love the "use strict datatypes" approach. You have all the guarantees you need on the type level.
2023-05-09 12:28:12 +0200 <maralorn> Inspecting the core seems tedious even if you are good at it. A large code base has a lot of core. "Read the assembler if you want to be sure your C code is good" seems quite annoying. There have to be shortcuts and heuristics to circumvent that in most situations.
2023-05-09 12:29:53 +0200 <[exa]> I wish we had something that just annotated the code with "this has generated 4321 thunks that have been evaluated 1234 times"
2023-05-09 12:31:12 +0200 <[exa]> anyway the strict datatypes by default often kinda defeat the purpose of laziness; you are often better off with just inserting a few deepseq's into the pipeline
2023-05-09 12:31:23 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 256 seconds)
2023-05-09 12:34:22 +0200 <maralorn> [exa]: That’s a nice heuristic. Although in the case of my program it was a grave mistake. As I said I have 10MB of state and I called deepseq on it 1 million times, (once after each state transition).
2023-05-09 12:34:59 +0200maroloccio(~marolocci@90.167.166.125) (Quit: WeeChat 3.7.1)
2023-05-09 12:35:24 +0200 <maralorn> Otoh batching state transitions and only deepseqing after lets say a few hundred sounds like a lot of small space leaks instead of one big one.
2023-05-09 12:36:17 +0200 <maralorn> Also if only a small part of the state changes with every transition, then deepseqing everything is probably duplicating work.
2023-05-09 12:40:46 +0200 <[exa]> yeah doing deepseq too much is probably not a good usecase
2023-05-09 12:48:00 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net)
2023-05-09 12:48:04 +0200Feuermagier(~Feuermagi@user/feuermagier)
2023-05-09 12:51:11 +0200CiaoSen(~Jura@dynamic-046-114-219-059.46.114.pool.telefonica.de) (Ping timeout: 246 seconds)
2023-05-09 12:52:16 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net) (Ping timeout: 248 seconds)
2023-05-09 12:55:55 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-05-09 13:00:28 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 13:05:04 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 248 seconds)
2023-05-09 13:05:41 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 13:05:59 +0200gurkenglas(~gurkengla@dynamic-089-204-139-070.89.204.139.pool.telefonica.de)
2023-05-09 13:08:04 +0200xff0x(~xff0x@2405:6580:b080:900:df5d:59c:37fd:3926)
2023-05-09 13:10:30 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 13:11:47 +0200 <Athas> Sweet, cabal-install 3.10 finally made it into Nixpkgs master.
2023-05-09 13:11:57 +0200 <Athas> Now I no longer need to use a locally installed one to get XDG support.
2023-05-09 13:13:55 +0200marinelli(~weechat@gateway/tor-sasl/marinelli)
2023-05-09 13:17:43 +0200nate2(~nate@98.45.169.16)
2023-05-09 13:19:13 +0200 <maralorn> Athas: Afaict cabal-install has been on nixpkgs master since March 30th, 2 weeks after it got released to hackage.
2023-05-09 13:20:10 +0200 <maralorn> *cabal-install 3.10
2023-05-09 13:21:41 +0200nschoe(~q@82-65-202-30.subs.proxad.net)
2023-05-09 13:22:56 +0200nate2(~nate@98.45.169.16) (Ping timeout: 265 seconds)
2023-05-09 13:26:35 +0200nschoe(~q@82-65-202-30.subs.proxad.net) (Ping timeout: 256 seconds)
2023-05-09 13:26:53 +0200nschoe(~q@2a01:e0a:8e:a190:73b5:77b:3a08:becb)
2023-05-09 13:29:03 +0200 <Athas> Right, but I'm on... uh, whatever the 'nixpkgs' channel is called.
2023-05-09 13:29:13 +0200__monty__(~toonn@user/toonn) (Ping timeout: 265 seconds)
2023-05-09 13:29:25 +0200 <Athas> Wait no, nixos-unstable.
2023-05-09 13:30:55 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 13:32:29 +0200gurkenglas(~gurkengla@dynamic-089-204-139-070.89.204.139.pool.telefonica.de) (Ping timeout: 246 seconds)
2023-05-09 13:35:39 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 13:39:34 +0200gurkenglas(~gurkengla@dynamic-089-204-139-070.89.204.139.pool.telefonica.de)
2023-05-09 13:39:44 +0200 <maralorn> Well that normally lags about 3 days behind master. I mean I am happy that you are happy. Just wanted to remark that the "finally" happened a bit earlier than you noticed.
2023-05-09 13:42:17 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 13:54:42 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 13:56:38 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 13:56:47 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 13:57:23 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 13:59:15 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-05-09 13:59:22 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 13:59:34 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 14:00:12 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 14:00:19 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 260 seconds)
2023-05-09 14:10:46 +0200vulfe(~vulfe@168.91.196.163)
2023-05-09 14:11:02 +0200vulfe(~vulfe@168.91.196.163) (Remote host closed the connection)
2023-05-09 14:11:15 +0200vulfe(~vulfe@168.91.196.163)
2023-05-09 14:14:12 +0200freeside(~mengwong@202.161.55.11) (Ping timeout: 265 seconds)
2023-05-09 14:18:22 +0200jargon(~jargon@184.101.78.160) (Remote host closed the connection)
2023-05-09 14:22:06 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-05-09 14:26:28 +0200pyook(~puke@user/puke) (Remote host closed the connection)
2023-05-09 14:26:45 +0200pyook(~puke@user/puke)
2023-05-09 14:27:06 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-05-09 14:32:31 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 14:36:48 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 248 seconds)
2023-05-09 14:37:20 +0200notzmv(~zmv@user/notzmv)
2023-05-09 14:52:58 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-05-09 14:54:49 +0200elain4(~textual@2601:5c1:4402:cd30:99ae:6dbf:fe1:e05a)
2023-05-09 14:56:18 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.8)
2023-05-09 14:58:50 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 14:58:56 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 15:04:57 +0200nschoe(~q@2a01:e0a:8e:a190:73b5:77b:3a08:becb) (Ping timeout: 256 seconds)
2023-05-09 15:07:05 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 15:11:11 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 15:13:51 +0200elain4(~textual@2601:5c1:4402:cd30:99ae:6dbf:fe1:e05a) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-05-09 15:16:33 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 265 seconds)
2023-05-09 15:20:43 +0200acidjnk(~acidjnk@p200300d6e7072f24c1846b175da7e4e4.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-05-09 15:20:49 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 15:21:14 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-05-09 15:24:01 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-05-09 15:24:10 +0200JScript2(~JScript@cpe-172-193-181-254.qld.foxtel.net.au)
2023-05-09 15:24:21 +0200 <JScript2> how do i update base
2023-05-09 15:25:08 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 15:26:05 +0200 <JScript2> cabal install base --lib base
2023-05-09 15:26:05 +0200 <JScript2> Resolving dependencies...
2023-05-09 15:26:05 +0200 <JScript2> Up to date
2023-05-09 15:26:45 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-e916-5c4e-9cb1-6957.rev.sfr.net)
2023-05-09 15:26:47 +0200 <merijn> JScript2: You don't
2023-05-09 15:26:52 +0200 <merijn> JScript2: base is tied into GHC
2023-05-09 15:27:10 +0200 <merijn> So you can only update it by switching to a newer compiler
2023-05-09 15:27:22 +0200elain4(~textual@2601:5c1:4402:cd30:99ae:6dbf:fe1:e05a)
2023-05-09 15:27:53 +0200taupiqueur2(~taupiqueu@2a02-842a-8180-4601-e916-5c4e-9cb1-6957.rev.sfr.net)
2023-05-09 15:28:50 +0200 <JScript2> The Glorious Glasgow Haskell Compilation System, version 9.2.7
2023-05-09 15:29:11 +0200taupiqueur2(~taupiqueu@2a02-842a-8180-4601-e916-5c4e-9cb1-6957.rev.sfr.net) (Client Quit)
2023-05-09 15:29:12 +0200 <JScript2> rejecting: base-4.16.4.0/installed-4.16.4.0 (conflict: darcs => base>=4.10 && <4.16)
2023-05-09 15:30:05 +0200taupiqueur1(~taupiqueu@2a02-842a-8180-4601-64af-550d-b7f1-261b.rev.sfr.net) (Ping timeout: 246 seconds)
2023-05-09 15:30:24 +0200 <merijn> darcs requires based older than 4.16, and 9.2 ships with 4.16, so you either downgrade to 8.10 or 9.0 or, alternatively, you could build darcs with "--allow-newer=base" and cross your fingers that works
2023-05-09 15:30:40 +0200 <JScript2> qwq
2023-05-09 15:31:34 +0200 <merijn> I mean, it probably will, I don't think there've been big changes to base recently
2023-05-09 15:37:09 +0200 <JScript2> ill try 9.0.2
2023-05-09 15:38:33 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 15:39:13 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-e916-5c4e-9cb1-6957.rev.sfr.net) (Remote host closed the connection)
2023-05-09 15:42:55 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 15:43:00 +0200 <JScript2> why tf is haskell so difficult to debug ;-;
2023-05-09 15:43:04 +0200dtman34(~dtman34@2601:447:d000:93c9:aba0:2b0:9983:9568) (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in)
2023-05-09 15:43:25 +0200dtman34(~dtman34@2601:447:d000:93c9:30e0:dc16:93:df06)
2023-05-09 15:46:17 +0200 <dminuoso> JScript2: I suppose the primary reason is lack of industry backing for improved tooling.
2023-05-09 15:46:58 +0200 <dminuoso> Debugging C is only bearable because many person years were invested into projects like gdb or lldb.
2023-05-09 15:48:47 +0200 <yushyin> at least this version mismatch is relatively obvious and straightforward
2023-05-09 15:51:23 +0200 <dminuoso> JScript2: Though to be fair, this specific problem isnt about debugging Haskell. Its about cabal-install.
2023-05-09 15:51:26 +0200merijn(~merijn@c-001-001-013.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds)
2023-05-09 15:51:33 +0200__monty__(~toonn@user/toonn)
2023-05-09 15:51:52 +0200 <dminuoso> Which generally has very poor consideration for a pleasant user experience when emitting diagnostics.
2023-05-09 15:52:38 +0200 <dminuoso> (However, I suppose a newcomer to the language might not care to make a distinction between Haskell, and externa tooling)
2023-05-09 15:53:49 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-09 15:53:49 +0200 <Helle> oh, right, I was putting off working on some stuff as cabal was giving me a fight
2023-05-09 15:53:52 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 15:54:35 +0200 <Helle> refusing to run the autogen for PackageInfo_foo stuff, for no clear reason
2023-05-09 15:54:49 +0200 <Helle> what tools do I have to introspect cabal's reading of it's files ?
2023-05-09 15:55:17 +0200 <merijn> Helle: What's PackageInfo? Do you mean the Paths_ stuff>
2023-05-09 15:55:17 +0200 <merijn> +?
2023-05-09 15:56:20 +0200 <Helle> merijn: ah, no, and that gives me a hint at what is going on
2023-05-09 15:56:58 +0200 <merijn> Helle: Then I don't even know what PackageInfo is supposed to be in the context of cabal?
2023-05-09 15:57:12 +0200 <Helle> https://cabal.readthedocs.io/en/3.10/cabal-package.html#accessing-package-related-informations
2023-05-09 15:57:34 +0200 <Helle> I think it may be newer then the version of cabal I have
2023-05-09 15:58:02 +0200 <Helle> yep, that is exactly it
2023-05-09 15:58:05 +0200 <merijn> ah, so it's new
2023-05-09 15:58:20 +0200 <Helle> but yes, you not knowing it gave me the clue I needed, heh
2023-05-09 15:58:23 +0200 <merijn> Helle: I dunno about PackageInfo, but Paths_ has to be in autogen-modules to be generated
2023-05-09 15:58:36 +0200 <Helle> merijn: yeah, I know, it works
2023-05-09 15:58:43 +0200 <Helle> hence I was utterly confused
2023-05-09 15:59:28 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 15:59:43 +0200 <Helle> but it also does not cleanly complain about an autogen-modules it doesn't know, it will just be "cabal: can't find source for PackageInfo_test", etc, so that had me like "is it misreading the autogen, or what"
2023-05-09 16:00:03 +0200vulfe(~vulfe@168.91.196.163) (Remote host closed the connection)
2023-05-09 16:00:47 +0200 <Helle> anyway, given that even Debian is behind on it, I can't really go use it, as that forces other users of this code into a lot of headache
2023-05-09 16:01:45 +0200 <Helle> (yes, I know ghcup is not too horrendous, but still)
2023-05-09 16:02:06 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 16:02:25 +0200 <merijn> Helle: What part of it do you need?
2023-05-09 16:05:06 +0200 <Helle> no absolute need for anything, was just getting some convenience stuff going to make sure that everything output consistent info
2023-05-09 16:05:28 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9)
2023-05-09 16:07:28 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 248 seconds)
2023-05-09 16:08:22 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 16:09:04 +0200 <Helle> and PackageInfo is only in on 3.10 good to know
2023-05-09 16:09:56 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9) (Ping timeout: 250 seconds)
2023-05-09 16:12:31 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 250 seconds)
2023-05-09 16:12:48 +0200byte(~byte@user/byte) (Quit: Quitting...)
2023-05-09 16:13:56 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 16:13:57 +0200mncheck(~mncheck@193.224.205.254) (Read error: Connection reset by peer)
2023-05-09 16:14:12 +0200nick4(~nick@50.86.118.19)
2023-05-09 16:16:55 +0200__monty__(~toonn@user/toonn) (Ping timeout: 256 seconds)
2023-05-09 16:17:04 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 16:17:04 +0200acidjnk(~acidjnk@p200300d6e7072f242d8d66ef0fd61958.dip0.t-ipconnect.de)
2023-05-09 16:18:35 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 260 seconds)
2023-05-09 16:19:22 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:6722:77f:2791:a818) (Quit: WeeChat 2.8)
2023-05-09 16:22:58 +0200byte(~byte@user/byte)
2023-05-09 16:23:30 +0200JScript2(~JScript@cpe-172-193-181-254.qld.foxtel.net.au) ()
2023-05-09 16:24:57 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 16:29:23 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 16:30:55 +0200marinelli(~weechat@gateway/tor-sasl/marinelli) ()
2023-05-09 16:31:18 +0200shriekingnoise(~shrieking@186.137.175.87)
2023-05-09 16:35:09 +0200zer0bitz_(~zer0bitz@2001:2003:f443:d600:cc73:5fe2:e3b9:4425) (Read error: Connection reset by peer)
2023-05-09 16:35:15 +0200__monty__(~toonn@user/toonn)
2023-05-09 16:35:34 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 16:38:58 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 250 seconds)
2023-05-09 16:40:08 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 265 seconds)
2023-05-09 16:42:30 +0200nick4(~nick@50.86.118.19) (Ping timeout: 260 seconds)
2023-05-09 16:45:27 +0200zer0bitz(~zer0bitz@2001:2003:f443:d600:cc73:5fe2:e3b9:4425)
2023-05-09 16:48:30 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net)
2023-05-09 16:51:23 +0200elain4(~textual@2601:5c1:4402:cd30:99ae:6dbf:fe1:e05a) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-05-09 16:52:25 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-05-09 16:54:54 +0200nick4(~nick@50.86.118.19)
2023-05-09 16:56:57 +0200zer0bitz(~zer0bitz@2001:2003:f443:d600:cc73:5fe2:e3b9:4425) (Changing host)
2023-05-09 16:56:57 +0200zer0bitz(~zer0bitz@user/zer0bitz)
2023-05-09 16:58:34 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-05-09 17:00:00 +0200mncheck(~mncheck@193.224.205.254)
2023-05-09 17:00:35 +0200elain4(~textual@2601:5c1:4402:cd30:99ae:6dbf:fe1:e05a)
2023-05-09 17:02:16 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 17:03:24 +0200jtza8(~user@165.255.35.64)
2023-05-09 17:04:13 +0200nick4(~nick@50.86.118.19) (Ping timeout: 268 seconds)
2023-05-09 17:09:07 +0200 <jtza8> I'm using Aeson to encode a sum type by hand, usually Aeson starts the encoded JSON object with the "tag" key/value pair, but with "toJSON = object [ ... ]" the "contents" pair seems to move to the first slot. Is that just life, or is there a way to correct this and get consistency?
2023-05-09 17:10:34 +0200Sgeo(~Sgeo@user/sgeo)
2023-05-09 17:11:00 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 17:12:00 +0200elain4(~textual@2601:5c1:4402:cd30:99ae:6dbf:fe1:e05a) (Ping timeout: 248 seconds)
2023-05-09 17:19:13 +0200nate2(~nate@98.45.169.16)
2023-05-09 17:20:48 +0200 <[exa]> jtza8: "first slot"? do you have an example json with this?
2023-05-09 17:21:43 +0200 <[exa]> ah you refer to the order of keyval pairs in the formatted JSON?
2023-05-09 17:22:39 +0200 <ncf> https://github.com/haskell/aeson/issues/368
2023-05-09 17:23:05 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 17:23:45 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-05-09 17:24:21 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection)
2023-05-09 17:28:33 +0200notzmv(~zmv@user/notzmv)
2023-05-09 17:28:50 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-05-09 17:30:47 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 264 seconds)
2023-05-09 17:30:52 +0200jero98772(~jero98772@2800:484:1d84:9000::2)
2023-05-09 17:32:51 +0200 <gentauro> hey, long time no ask in here :) Just a question. Being used to Haskell (and other ML-syntax langs) is it even possible to write `rust` code? xD
2023-05-09 17:33:29 +0200 <gentauro> lack of curried function parameters. No lambdas. No own defined ops …
2023-05-09 17:35:03 +0200 <gentauro> and the syntax … it awakes my C++ days :-\
2023-05-09 17:35:34 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-09 17:36:22 +0200 <gentauro> however, it seems that Snoyman is really keen to the lang so there might be hope :)
2023-05-09 17:36:57 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9)
2023-05-09 17:37:13 +0200 <vulfe> Rust is great
2023-05-09 17:38:40 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2023-05-09 17:39:37 +0200 <vulfe> I don't think functional programming makes learning other things impossible :P
2023-05-09 17:41:17 +0200 <yushyin> gentauro: well, c++ is what it tries to compete with
2023-05-09 17:41:19 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 17:41:19 +0200048AA07W5(~mengwong@103.252.202.151)
2023-05-09 17:41:22 +0200 <gentauro> vulfe: I tried to write a "simple" parser combinator in `rust`
2023-05-09 17:41:26 +0200 <tokie> C++ is what it's replacing
2023-05-09 17:41:26 +0200 <gentauro> I couldn't xD
2023-05-09 17:41:31 +0200 <tokie> not just competing :D
2023-05-09 17:41:41 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-09 17:41:45 +0200 <tokie> gentauro: i wrote a parser combinator similar to parsec in rust!
2023-05-09 17:41:49 +0200 <gentauro> tokie: I guess that cos of the `foo::bar::…`
2023-05-09 17:41:54 +0200 <gentauro> tokie: :o
2023-05-09 17:41:59 +0200 <vulfe> Rust and Haskell actually have a lot of things in common
2023-05-09 17:42:01 +0200 <tokie> https://github.com/strtok/parcom
2023-05-09 17:42:01 +0200 <gentauro> you have it on GH or GL?
2023-05-09 17:42:14 +0200 <tokie> it is very h ard to do it in rust because of the borrow checker
2023-05-09 17:43:00 +0200 <tokie> there's a lot of limitations on lifetimes and lambdas in rust right now. hopefully that's fixed with borrow checker improvements. it does make writing a -closure based- parser combinator difficult
2023-05-09 17:43:14 +0200 <tokie> but there are other approaches to writing parser combinators that work out much better
2023-05-09 17:43:29 +0200 <tokie> https://github.com/rust-bakery/nom
2023-05-09 17:43:44 +0200 <vulfe> a solution based on closures is probably the closest philisophically to FP parser-combinators
2023-05-09 17:43:45 +0200 <yushyin> tokie: maybe someday, but languages, especially an industry standard like c++, are hard to replace
2023-05-09 17:44:11 +0200 <tokie> yushyin: yes, but we are seeing serious momentum now - microsoft just announced they're rewriting core windows libraries in rust
2023-05-09 17:44:14 +0200 <vulfe> c++ might be widely used but it also mega sucks
2023-05-09 17:44:22 +0200 <tokie> linux kernel is moving forward with rust as the second language (C++ never got there!)
2023-05-09 17:44:25 +0200 <gentauro> tokie: did you implement `<|>` (alternate) for `backtracking`?
2023-05-09 17:44:25 +0200 <vulfe> and rust does not mega suck, so it has that going for it
2023-05-09 17:44:41 +0200 <tokie> gentauro: no
2023-05-09 17:44:55 +0200CiaoSen(~Jura@dynamic-046-114-217-185.46.114.pool.telefonica.de)
2023-05-09 17:44:56 +0200 <tokie> check nom for a more complete parser combinator framework
2023-05-09 17:45:15 +0200 <gentauro> btw, new C++, I recall writing some stuff and just putting `auto` in front of the var name and problems solved xD
2023-05-09 17:45:25 +0200 <yushyin> :)
2023-05-09 17:45:36 +0200048AA07W5(~mengwong@103.252.202.151) (Ping timeout: 248 seconds)
2023-05-09 17:45:49 +0200 <tokie> gentauro: to a degree. rust's type inference is a lot more powerful than C++
2023-05-09 17:45:52 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 265 seconds)
2023-05-09 17:45:55 +0200 <gentauro> then I had an error and the "verbose" output reminded me of the `C++ generic days` and I ran away from it xD
2023-05-09 17:46:42 +0200 <yushyin> gentauro: yes, c++ is evolving too, you can't compare c++20 with c++98
2023-05-09 17:46:43 +0200 <tokie> yeah, a lot of that is usually related to how c++'s generics work - rust's generics are way less powerful than C++, since type parameters have to be bound by a trait
2023-05-09 17:46:58 +0200 <tokie> traits are based off haskell's type classes
2023-05-09 17:47:22 +0200 <gentauro> tokie: just like `scala` traits right?
2023-05-09 17:47:44 +0200 <tokie> i don't know scala, but probably? the rust team cites haskell for inspiration for traits i think?
2023-05-09 17:47:51 +0200 <tokie> https://doc.rust-lang.org/reference/influences.html
2023-05-09 17:48:23 +0200 <vulfe> bounded parametric polymorphism ftw
2023-05-09 17:48:34 +0200 <tokie> vulfe: yeah, agreed
2023-05-09 17:48:42 +0200 <vulfe> it's a really good idea
2023-05-09 17:50:12 +0200 <gentauro> tokie: thx for link. Quite interesting the mixture
2023-05-09 17:51:18 +0200 <tokie> gentauro: this is my more interesting rust project: https://github.com/strtok/marwood/
2023-05-09 17:51:36 +0200 <tokie> demo at https://www.marwood.io/
2023-05-09 17:52:04 +0200mc47(~mc47@xmonad/TheMC47)
2023-05-09 17:52:35 +0200 <yushyin> c++ tries to get their template programming under control with 'concepts'.
2023-05-09 17:52:43 +0200nick4(~nick@98.186.196.174)
2023-05-09 17:54:44 +0200 <gentauro> tokie: nice
2023-05-09 17:55:56 +0200 <gentauro> tokie: repl needs copy/past capabilities :0
2023-05-09 17:55:57 +0200 <gentauro> :)
2023-05-09 17:56:35 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-09 17:59:18 +0200 <gentauro> tokie: stuff like this -> https://github.com/strtok/marwood/blob/master/marwood/src/lex.rs is exactly what I'm looking for (to get inspired) Thx !!!
2023-05-09 18:02:42 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-09 18:03:45 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 265 seconds)
2023-05-09 18:05:48 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 240 seconds)
2023-05-09 18:06:38 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 18:07:22 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-05-09 18:08:04 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-05-09 18:09:16 +0200 <jtza8> [exa]: Yeah, that was what I meant.
2023-05-09 18:09:59 +0200 <jtza8> ncf: Thanks.
2023-05-09 18:11:58 +0200CiaoSen(~Jura@dynamic-046-114-217-185.46.114.pool.telefonica.de) (Ping timeout: 265 seconds)
2023-05-09 18:12:05 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 18:13:40 +0200gmg(~user@user/gehmehgeh)
2023-05-09 18:14:39 +0200 <[exa]> jtza8: if it's for humans, you might like running the json through `jq -S`
2023-05-09 18:15:30 +0200 <bwe> which parser combinator library can you recommend from your personal experience because it's compact, ergonomic and powerful?
2023-05-09 18:17:49 +0200 <maerwald> just roll your own
2023-05-09 18:18:02 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 18:18:59 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 18:19:32 +0200hugo(znc@verdigris.lysator.liu.se)
2023-05-09 18:21:31 +0200ubert(~Thunderbi@2a02:8109:abc0:6434:81f:756b:c2fe:5d83) (Quit: ubert)
2023-05-09 18:22:08 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds)
2023-05-09 18:23:51 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-09 18:24:02 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 246 seconds)
2023-05-09 18:25:21 +0200chele(~chele@user/chele) (Remote host closed the connection)
2023-05-09 18:27:15 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Ping timeout: 260 seconds)
2023-05-09 18:27:40 +0200EsoAlgo8(~EsoAlgo@129.146.136.145)
2023-05-09 18:27:49 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 256 seconds)
2023-05-09 18:27:59 +0200Ekho(~Ekho@user/ekho) (Quit: CORE ERROR, SYSTEM HALTED.)
2023-05-09 18:29:50 +0200zeenk(~zeenk@2a02:2f04:a105:f00::fba) (Quit: Konversation terminated!)
2023-05-09 18:32:30 +0200 <jtza8> [exa]: It was mostly just for debugging and legibility. jq looks like a good solution though, thanks.
2023-05-09 18:38:34 +0200nick4(~nick@98.186.196.174) (Ping timeout: 268 seconds)
2023-05-09 18:38:39 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 18:40:06 +0200nick4(~nick@98.186.196.174)
2023-05-09 18:45:19 +0200stevenxl(uid133530@id-133530.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-05-09 18:45:52 +0200hugo(znc@verdigris.lysator.liu.se)
2023-05-09 18:46:52 +0200 <bwe> maerwald: any good tutorial for writing your own parser combinator you can recommend? I am after the dos and don'ts of writing a parser combinator.
2023-05-09 18:46:55 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 18:47:30 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 18:48:11 +0200mechap(~mechap@user/mechap)
2023-05-09 18:51:24 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-05-09 18:52:11 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 256 seconds)
2023-05-09 18:54:51 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net)
2023-05-09 18:58:07 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-05-09 18:59:46 +0200mbuf(~Shakthi@49.207.178.186) (Quit: Leaving)
2023-05-09 19:00:24 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 19:03:21 +0200evincar(~evincar@user/evincar)
2023-05-09 19:04:32 +0200freeside_(~mengwong@103.252.202.151)
2023-05-09 19:06:08 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 248 seconds)
2023-05-09 19:08:23 +0200mechap(~mechap@user/mechap) (Quit: WeeChat 3.8)
2023-05-09 19:08:30 +0200barcisz(~barcisz@79.191.229.20.ipv4.supernova.orange.pl)
2023-05-09 19:09:05 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 19:09:54 +0200mechap(~mechap@user/mechap)
2023-05-09 19:10:40 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-05-09 19:14:59 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 19:15:40 +0200 <fendor[m]> my ghc 9.2.7 is segfaulting... https://paste.tomsmeding.com/4tqnf1e1 is that a known issue or more likely my pc dying?
2023-05-09 19:16:45 +0200Ekho(~Ekho@user/ekho)
2023-05-09 19:17:33 +0200 <fendor[m]> but it segfaults only sometimes
2023-05-09 19:17:33 +0200 <Hecate> fendor[m]: https://twitter.com/TechnoEmpress/status/1620818425332518913
2023-05-09 19:17:56 +0200 <Hecate> and https://gitlab.haskell.org/ghc/ghc/-/issues/19421
2023-05-09 19:18:40 +0200Angelz(Angelz@angelz.oddprotocol.org) (Ping timeout: 265 seconds)
2023-05-09 19:19:36 +0200 <fendor[m]> thanks! Didn't see that, would have expected a discourse announcement or something
2023-05-09 19:19:43 +0200 <Hecate> creating one rn
2023-05-09 19:20:25 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-05-09 19:20:36 +0200 <Hecate> https://discourse.haskell.org/t/facing-mmap-4096-bytes-at-nil-cannot-allocate-memory-youre-not-alo… fendor[m]
2023-05-09 19:22:05 +0200 <fendor[m]> hehe, thankyou :)
2023-05-09 19:22:07 +0200 <fendor[m]> time to upgrade to a newer ghc version
2023-05-09 19:22:34 +0200nick4(~nick@98.186.196.174) (Ping timeout: 265 seconds)
2023-05-09 19:22:49 +0200nick4(~nick@ip68-1-49-124.pn.at.cox.net)
2023-05-09 19:24:54 +0200 <geekosaur> there;s two possible problems there, one is the ghc issue, the other is a linux kernel issue (https://bbs.archlinux.org/viewtopic.php?id=282429)
2023-05-09 19:25:32 +0200 <geekosaur> both are fixed by using 9.4 because 9.4 changed how it's doing `mmap` in a way that avoids the kernel issue
2023-05-09 19:25:39 +0200MajorBiscuit(~MajorBisc@2001:1c00:2492:e200:561f:c4dd:78fa:8040) (Quit: WeeChat 3.6)
2023-05-09 19:30:29 +0200 <fendor[m]> hm, at least on my machine, I have a linux kernel version that should have the fix 6.2.13-arch1-1
2023-05-09 19:31:53 +0200 <fendor[m]> ah, apparently it is not entirely fixed? ah whatever
2023-05-09 19:33:09 +0200 <geekosaur> it was fixed and then the patch was reverted in some 6.2 version and then re-added later
2023-05-09 19:33:19 +0200 <geekosaur> so you may be in the gap
2023-05-09 19:33:43 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 19:34:10 +0200 <fendor[m]> ah, thank you for the explanation!
2023-05-09 19:34:36 +0200ubert(~Thunderbi@p200300ecdf42c68668c9dcfdb6c1aa18.dip0.t-ipconnect.de)
2023-05-09 19:36:16 +0200Angelz(Angelz@Angelz.oddprotocol.org)
2023-05-09 19:37:46 +0200biberu(~biberu@user/biberu) (Ping timeout: 268 seconds)
2023-05-09 19:37:48 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-09 19:42:47 +0200biberu(~biberu@user/biberu)
2023-05-09 19:44:59 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 19:48:24 +0200 <geekosaur> yeh, I just did a logs search and you got unlucky: 6.2.13 is the first version that regressed
2023-05-09 19:49:08 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-09 19:49:30 +0200 <geekosaur> so you can either rebuild your kernel with the hotfix patch from that discussion, or you can upgrade to 9.4 and avoid it
2023-05-09 19:53:14 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-05-09 19:54:31 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 19:56:26 +0200 <tokie> gentauro: yeah! i think copy paste works on some browsers/operating systems :D
2023-05-09 19:57:20 +0200mechap(~mechap@user/mechap) (Ping timeout: 248 seconds)
2023-05-09 19:58:17 +0200 <sm> bwe: 👍🏻
2023-05-09 19:59:52 +0200mechap(~mechap@user/mechap)
2023-05-09 20:04:20 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 20:04:37 +0200mechap(~mechap@user/mechap) (Ping timeout: 265 seconds)
2023-05-09 20:06:16 +0200mechap(~mechap@user/mechap)
2023-05-09 20:06:45 +0200jtza8(~user@165.255.35.64) (Ping timeout: 268 seconds)
2023-05-09 20:08:59 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 260 seconds)
2023-05-09 20:09:39 +0200roboguy_(~roboguy_@cpe-69-76-235-109.kc.res.rr.com)
2023-05-09 20:11:29 +0200mechap(~mechap@user/mechap) (Ping timeout: 246 seconds)
2023-05-09 20:12:07 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2023-05-09 20:12:35 +0200mechap(~mechap@user/mechap)
2023-05-09 20:13:19 +0200roboguy_(~roboguy_@cpe-69-76-235-109.kc.res.rr.com) (Client Quit)
2023-05-09 20:14:11 +0200notzmv(~zmv@user/notzmv)
2023-05-09 20:17:05 +0200mechap(~mechap@user/mechap) (Ping timeout: 246 seconds)
2023-05-09 20:19:42 +0200ub(~Thunderbi@p548c9371.dip0.t-ipconnect.de)
2023-05-09 20:20:48 +0200ubert(~Thunderbi@p200300ecdf42c68668c9dcfdb6c1aa18.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-05-09 20:20:48 +0200ububert
2023-05-09 20:25:39 +0200mechap(~mechap@user/mechap)
2023-05-09 20:25:41 +0200econo(uid147250@user/econo)
2023-05-09 20:27:10 +0200barcisz89(~barcisz@79.191.229.20.ipv4.supernova.orange.pl)
2023-05-09 20:29:34 +0200barcisz(~barcisz@79.191.229.20.ipv4.supernova.orange.pl) (Ping timeout: 268 seconds)
2023-05-09 20:32:06 +0200mechap(~mechap@user/mechap) (Ping timeout: 250 seconds)
2023-05-09 20:32:56 +0200mechap(~mechap@user/mechap)
2023-05-09 20:37:56 +0200mechap(~mechap@user/mechap) (Ping timeout: 265 seconds)
2023-05-09 20:39:16 +0200mechap(~mechap@user/mechap)
2023-05-09 20:40:28 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
2023-05-09 20:44:57 +0200mechap(~mechap@user/mechap) (Ping timeout: 256 seconds)
2023-05-09 20:45:35 +0200mechap(~mechap@user/mechap)
2023-05-09 20:51:30 +0200hugo(znc@verdigris.lysator.liu.se)
2023-05-09 20:54:17 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-e916-5c4e-9cb1-6957.rev.sfr.net)
2023-05-09 20:54:35 +0200evincar(~evincar@user/evincar) (Ping timeout: 256 seconds)
2023-05-09 20:58:32 +0200 <bwe> sm: is there any better intro than https://markkarpov.com/tutorial/megaparsec.html you know of?
2023-05-09 20:58:34 +0200barcisz89(~barcisz@79.191.229.20.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-05-09 20:59:17 +0200 <sm> to parser combinators generally ?
2023-05-09 20:59:43 +0200 <jean-paul[m]> https://hackage.haskell.org/package/crypto-api-0.13.3/docs/Crypto-Types.html#t:IV says that a common way to get an IV is via its Serialize instance - but then in the instances list below, there is no Serialize instance listed. How should I interpret this?
2023-05-09 21:03:00 +0200 <sm> bwe I mainly just use them, but some of these might be useful: https://en.wikipedia.org/wiki/Parser_combinator https://serokell.io/blog/parser-combinators-in-haskell https://hasura.io/blog/parser-combinators-walkthrough/ https://parsica-php.github.io/docs/tutorial/01_introduction/ https://crypto.stanford.edu/~blynn/haskell/parse.html
2023-05-09 21:03:16 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-05-09 21:04:48 +0200 <sm> or perhaps these: https://www.cs.nott.ac.uk/~pszgmh/monparsing.pdf https://www.cmi.ac.in/~spsuresh/teaching/prgh15/papers/monadic-parsing.pdf
2023-05-09 21:06:41 +0200 <bwe> sm: got a start :) thanks a lot.
2023-05-09 21:10:05 +0200biberu(~biberu@user/biberu) (Read error: Connection reset by peer)
2023-05-09 21:11:23 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 21:12:09 +0200trev(~trev@user/trev) (Quit: trev)
2023-05-09 21:17:15 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 260 seconds)
2023-05-09 21:17:15 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-05-09 21:20:49 +0200nate2(~nate@98.45.169.16)
2023-05-09 21:24:16 +0200evincar(~evincar@user/evincar)
2023-05-09 21:25:17 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 21:25:59 +0200nate2(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2023-05-09 21:29:09 +0200ub(~Thunderbi@p200300ecdf42c68668c9dcfdb6c1aa18.dip0.t-ipconnect.de)
2023-05-09 21:29:12 +0200biberu(~biberu@user/biberu)
2023-05-09 21:29:23 +0200evincar(~evincar@user/evincar) (Ping timeout: 268 seconds)
2023-05-09 21:29:28 +0200ubert(~Thunderbi@p548c9371.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-05-09 21:29:28 +0200ububert
2023-05-09 21:30:27 +0200Topsi(~Topsi@host-82-135-42-158.customer.m-online.net)
2023-05-09 21:34:25 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 21:40:16 +0200Topsi(~Topsi@host-82-135-42-158.customer.m-online.net) (Quit: Leaving.)
2023-05-09 21:42:04 +0200ub(~Thunderbi@p548c9371.dip0.t-ipconnect.de)
2023-05-09 21:43:07 +0200ubert(~Thunderbi@p200300ecdf42c68668c9dcfdb6c1aa18.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-05-09 21:43:07 +0200ububert
2023-05-09 21:50:47 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-05-09 21:51:08 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:4165:ceb6:19a8:1e1e) (Quit: use-value)
2023-05-09 21:55:10 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 21:56:27 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 21:56:59 +0200evincar(~evincar@user/evincar)
2023-05-09 22:01:47 +0200evincar(~evincar@user/evincar) (Ping timeout: 248 seconds)
2023-05-09 22:06:26 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2023-05-09 22:07:02 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2023-05-09 22:11:10 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9) (Remote host closed the connection)
2023-05-09 22:13:46 +0200zeenk(~zeenk@2a02:2f04:a105:f00::fba)
2023-05-09 22:15:07 +0200ddellacosta(~ddellacos@146.70.166.177) (Ping timeout: 265 seconds)
2023-05-09 22:16:43 +0200ddellacosta(~ddellacos@143.244.47.88)
2023-05-09 22:18:24 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-05-09 22:21:17 +0200nick4(~nick@ip68-1-49-124.pn.at.cox.net) (Ping timeout: 256 seconds)
2023-05-09 22:21:32 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 22:25:45 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-09 22:29:02 +0200evincar(~evincar@user/evincar)
2023-05-09 22:32:03 +0200nick4(~nick@ip68-1-49-124.pn.at.cox.net)
2023-05-09 22:33:47 +0200evincar(~evincar@user/evincar) (Ping timeout: 264 seconds)
2023-05-09 22:34:28 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-05-09 22:35:23 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-05-09 22:38:19 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 22:44:05 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 22:46:35 +0200 <Inst> do you guys ever do codewars here?
2023-05-09 22:46:38 +0200 <Inst> https://www.codewars.com/kata/60ae5db1639df90055068d20/train/haskell
2023-05-09 22:47:38 +0200 <Inst> whoops, take off the train, or you'll be forced to train
2023-05-09 22:47:43 +0200 <Inst> and ruin stats, if you do do codewars
2023-05-09 22:49:43 +0200smdid https://www.codingame.com/multiplayer/clashofcode a bit.. fun
2023-05-09 22:50:39 +0200chomwitt(~chomwitt@ppp-94-67-206-188.home.otenet.gr) (Remote host closed the connection)
2023-05-09 22:53:20 +0200freeside(~mengwong@103.252.202.151)
2023-05-09 22:55:50 +0200caryhartline(~caryhartl@2600:1700:2d0:8d30:5d14:9417:a6bd:7661)
2023-05-09 22:56:00 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 22:58:11 +0200freeside(~mengwong@103.252.202.151) (Ping timeout: 268 seconds)
2023-05-09 22:58:43 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-05-09 22:58:46 +0200ubert(~Thunderbi@p548c9371.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-05-09 23:01:06 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Quit: Leaving)
2023-05-09 23:03:06 +0200evincar(~evincar@user/evincar)
2023-05-09 23:03:22 +0200titibandit(~titibandi@user/titibandit)
2023-05-09 23:03:47 +0200nick4(~nick@ip68-1-49-124.pn.at.cox.net) (Ping timeout: 264 seconds)
2023-05-09 23:07:28 +0200evincar(~evincar@user/evincar) (Ping timeout: 240 seconds)
2023-05-09 23:11:35 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9)
2023-05-09 23:12:10 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 23:12:48 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 23:13:00 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de)
2023-05-09 23:15:53 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:718d:894b:b41:1ab9) (Ping timeout: 250 seconds)
2023-05-09 23:17:11 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 250 seconds)
2023-05-09 23:19:31 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 23:21:02 +0200tubogram44(~tubogram@user/tubogram) (*.net *.split)
2023-05-09 23:21:24 +0200tubogram44(~tubogram@user/tubogram)
2023-05-09 23:23:14 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-09 23:28:57 +0200rf(~rf@2605:59c8:179c:f610:44a3:b0ec:665c:93d3)
2023-05-09 23:30:00 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2023-05-09 23:30:37 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 23:33:17 +0200tubogram44(~tubogram@user/tubogram) (*.net *.split)
2023-05-09 23:34:02 +0200tubogram44(~tubogram@user/tubogram)
2023-05-09 23:34:48 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-09 23:36:23 +0200evincar(~evincar@user/evincar)
2023-05-09 23:38:58 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-05-09 23:41:11 +0200evincar(~evincar@user/evincar) (Ping timeout: 256 seconds)
2023-05-09 23:42:14 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-e916-5c4e-9cb1-6957.rev.sfr.net) (Remote host closed the connection)
2023-05-09 23:44:25 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 240 seconds)
2023-05-09 23:47:18 +0200vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2023-05-09 23:51:41 +0200superbil(~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split)
2023-05-09 23:52:58 +0200elevenkb(~elevenkb@vc-gp-n-105-245-97-98.umts.vodacom.co.za)
2023-05-09 23:54:47 +0200myrix(~myrix@95-24-68-157.broadband.corbina.ru)
2023-05-09 23:55:01 +0200myrix(~myrix@95-24-68-157.broadband.corbina.ru) (Client Quit)
2023-05-09 23:55:17 +0200myrix(~myrix@95-24-68-157.broadband.corbina.ru)
2023-05-09 23:55:20 +0200myrix(~myrix@95-24-68-157.broadband.corbina.ru) (Client Quit)
2023-05-09 23:55:25 +0200superbil(~superbil@1-34-176-171.hinet-ip.hinet.net)