IRCBrowse

2023/07/07

2023-07-07 00:00:17 +0200migas(~migas@astra4961.startdedicated.net) (Remote host closed the connection)
2023-07-07 00:00:33 +0200migas(~migas@astra4961.startdedicated.net)
2023-07-07 00:02:37 +0200reio(~reio@86-90-81-176.fixed.kpn.net) (Remote host closed the connection)
2023-07-07 00:04:32 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-07-07 00:05:30 +0200acidjnk(~acidjnk@p200300d6e7072f0700a8e9aef9077b5f.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-07-07 00:06:24 +0200jargon(~jargon@184.101.73.95)
2023-07-07 00:07:21 +0200ai5lk(~ai5lk@209-188-121-236.taosnet.com) (Quit: WeeChat 3.8)
2023-07-07 00:09:36 +0200alternateved(~user@77-254-166-50.dynamic.inetia.pl) (Remote host closed the connection)
2023-07-07 00:13:23 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-07-07 00:13:33 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 246 seconds)
2023-07-07 00:13:46 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 245 seconds)
2023-07-07 00:16:16 +0200Guest5320(~finn@176-151-21-224.abo.bbox.fr) (Ping timeout: 245 seconds)
2023-07-07 00:17:41 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-07-07 00:19:08 +0200delYsid`(~user@84-115-138-74.cable.dynamic.surfer.at)
2023-07-07 00:19:11 +0200delYsid(~user@user/delYsid) (Ping timeout: 245 seconds)
2023-07-07 00:19:51 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-07-07 00:27:48 +0200mstksg(~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds)
2023-07-07 00:30:00 +0200mstksg(~jle`@cpe-23-240-75-236.socal.res.rr.com)
2023-07-07 00:30:01 +0200dibblego(~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds)
2023-07-07 00:30:51 +0200gurkenglas(~gurkengla@dynamic-046-114-179-175.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-07-07 00:31:16 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds)
2023-07-07 00:34:05 +0200dibblego(~dibblego@116-255-1-157.ip4.superloop.au)
2023-07-07 00:34:05 +0200dibblego(~dibblego@116-255-1-157.ip4.superloop.au) (Changing host)
2023-07-07 00:34:05 +0200dibblego(~dibblego@haskell/developer/dibblego)
2023-07-07 00:35:06 +0200phma(phma@2001:5b0:215a:8658:2ff0:2260:7332:7cdc) (Read error: Connection reset by peer)
2023-07-07 00:35:31 +0200phma(~phma@host-67-44-208-75.hnremote.net)
2023-07-07 00:39:59 +0200lainon(~textual@c-98-54-78-2.hsd1.al.comcast.net)
2023-07-07 00:41:04 +0200nick4(~nick@2600:8807:9084:7800:d846:c2ed:f029:599)
2023-07-07 00:45:30 +0200nick4(~nick@2600:8807:9084:7800:d846:c2ed:f029:599) (Ping timeout: 260 seconds)
2023-07-07 00:45:48 +0200sagax(~sagax_nb@user/sagax) (Ping timeout: 240 seconds)
2023-07-07 00:48:21 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 245 seconds)
2023-07-07 00:50:01 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 245 seconds)
2023-07-07 00:55:58 +0200phma(~phma@host-67-44-208-75.hnremote.net) (Read error: Connection reset by peer)
2023-07-07 01:02:24 +0200phma(~phma@2001:5b0:211c:c328:623:9873:19c7:83ce)
2023-07-07 01:02:48 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-07-07 01:02:49 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-07-07 01:02:49 +0200wroathe(~wroathe@user/wroathe)
2023-07-07 01:03:08 +0200xff0x_(~xff0x@ai086045.d.east.v6connect.net) (Ping timeout: 240 seconds)
2023-07-07 01:04:27 +0200phma(~phma@2001:5b0:211c:c328:623:9873:19c7:83ce) (Read error: Connection reset by peer)
2023-07-07 01:04:54 +0200inversed(~inversed@bcdcac82.skybroadband.com) (Read error: Connection reset by peer)
2023-07-07 01:05:16 +0200xff0x_(~xff0x@178.255.149.135)
2023-07-07 01:07:35 +0200Midjak(~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
2023-07-07 01:09:51 +0200phma(phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce)
2023-07-07 01:15:58 +0200 <EvanR> has anything changed since haskell98 regarding the lexical analysis step
2023-07-07 01:16:34 +0200xff0x_(~xff0x@178.255.149.135) (Ping timeout: 250 seconds)
2023-07-07 01:16:47 +0200Sgeo(~Sgeo@user/sgeo)
2023-07-07 01:18:31 +0200xff0x_(~xff0x@2405:6580:b080:900:50da:9b7c:4bac:847a)
2023-07-07 01:21:56 +0200oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Ping timeout: 246 seconds)
2023-07-07 01:29:33 +0200 <geekosaur> the layout rule, as described lexically, has changed slightly to eliminate an ambiguity iirc
2023-07-07 01:32:13 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2023-07-07 01:44:37 +0200thegeekinside(~thegeekin@189.217.90.138) (Read error: Connection reset by peer)
2023-07-07 01:47:37 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1)
2023-07-07 01:48:58 +0200 <monochrom> dminuoso_: Haskell's "[Int]" becomes MLs' "int list". Now suppose you define your own ADT. Nothing stops you from naming it "t". And it it's a polymorphic type, users will be writing like "int t" instead of Haskell's "T Int". Furthermore, the ML communities are fond of naming their modules nicely, and say "<module name>.t" all the time, and not bother changing "t" to a better name, because the module name there is already the perfect name.
2023-07-07 01:49:24 +0200billb(~billb@cpe-66-8-173-22.hawaii.res.rr.com) (Quit: Leaving)
2023-07-07 01:50:58 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-07-07 01:51:01 +0200 <geekosaur> oh, is that where henningskell comes from?
2023-07-07 01:51:23 +0200 <monochrom> YES :)
2023-07-07 01:52:11 +0200mauke_(~mauke@user/mauke)
2023-07-07 01:52:23 +0200monochromworked with SML in a previous life because of the theorem prover HOL4.
2023-07-07 01:53:24 +0200mei(~mei@user/mei)
2023-07-07 01:53:46 +0200mauke(~mauke@user/mauke) (Ping timeout: 245 seconds)
2023-07-07 01:53:46 +0200mauke_mauke
2023-07-07 01:54:25 +0200ski. o O ( s/polymorphic type/parametric type/ )
2023-07-07 01:54:51 +0200 <monochrom> Yeah parametric type is better.
2023-07-07 01:55:10 +0200 <ski> yea, it's a common convention in the MLs
2023-07-07 01:55:26 +0200 <ski> i guess module functors kinda encourage it, too ?
2023-07-07 01:59:00 +0200 <ski> (imagine writing a functor (a parameterized module) where the parameter module is expected to contain a type named `t', and a `compare' function operating on it)
2023-07-07 01:59:23 +0200 <monochrom> I kind of didn't want to believe that, I was hoping that humans would be above using that as an excuse, but upon 2nd thought, yeah totally. :)
2023-07-07 02:01:00 +0200 <ski> .. i'm not sure how common it is to anticipate that, by naming the type `t' (and then going on to pass that module directly to a functor), rather than construct a custom wrapper ("adapter") module when instantiating the functor
2023-07-07 02:01:13 +0200 <ski> anyway, the (above) thought just occured to me
2023-07-07 02:01:42 +0200xff0x_(~xff0x@2405:6580:b080:900:50da:9b7c:4bac:847a) (Ping timeout: 246 seconds)
2023-07-07 02:03:51 +0200xff0x_(~xff0x@ai086045.d.east.v6connect.net)
2023-07-07 02:04:28 +0200inversed(~inversed@bcdcac82.skybroadband.com)
2023-07-07 02:05:14 +0200califax(~califax@user/califx) (Remote host closed the connection)
2023-07-07 02:06:38 +0200bontaq(~user@ool-45779b84.dyn.optonline.net)
2023-07-07 02:06:43 +0200sagax(~sagax_nb@user/sagax)
2023-07-07 02:09:34 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-07-07 02:13:39 +0200califax(~califax@user/califx)
2023-07-07 02:14:34 +0200falafel(~falafel@2603-7000-a700-8710-eb2d-b2d5-726c-ab42.res6.spectrum.com)
2023-07-07 02:25:48 +0200ddellacosta(~ddellacos@146.70.166.152) (Ping timeout: 240 seconds)
2023-07-07 02:26:26 +0200connrs(~connrs@user/connrs) (Read error: Connection reset by peer)
2023-07-07 02:27:31 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-07-07 02:27:55 +0200ddellacosta(~ddellacos@146.70.168.100)
2023-07-07 02:29:05 +0200connrs(~connrs@user/connrs)
2023-07-07 02:31:48 +0200EvanR_(~EvanR@user/evanr)
2023-07-07 02:32:04 +0200notzmv(~zmv@user/notzmv)
2023-07-07 02:32:16 +0200EvanR(~EvanR@user/evanr) (Read error: Connection reset by peer)
2023-07-07 02:33:28 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds)
2023-07-07 02:35:02 +0200caryhartline(~caryhartl@168.182.58.169) (Quit: caryhartline)
2023-07-07 02:39:37 +0200EvanR_EvanR
2023-07-07 02:40:41 +0200lainon(~textual@c-98-54-78-2.hsd1.al.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
2023-07-07 02:40:52 +0200thegeekinside(~thegeekin@189.217.90.138)
2023-07-07 02:41:05 +0200dmgk(~dmgk@user/dmgk)
2023-07-07 02:42:33 +0200 <EvanR> the extension LexicalNegation seems to mess with the lexer
2023-07-07 02:42:51 +0200 <EvanR> everything I know is wrong now
2023-07-07 02:43:14 +0200 <Axman6> Welcome to the future
2023-07-07 02:44:12 +0200Inst_(~Inst@2601:6c4:4081:2fc0:1933:a56d:b98f:3d34)
2023-07-07 02:48:02 +0200Inst__(~Inst@2601:6c4:4081:2fc0:44fe:e619:5fe8:5723) (Ping timeout: 246 seconds)
2023-07-07 02:51:41 +0200thegeekinside(~thegeekin@189.217.90.138) (Ping timeout: 245 seconds)
2023-07-07 02:55:03 +0200 <jackdk> record dot syntax will also change the lexing of what would otherwise be an operator followed by an identifier
2023-07-07 02:57:41 +0200 <geekosaur> even ExplicitForAll changes the lexer
2023-07-07 02:59:57 +0200priesvitne_sklo(~priesvitn@109-230-60-22.dynamic.orange.sk)
2023-07-07 03:01:54 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds)
2023-07-07 03:02:31 +0200inversed(~inversed@bcdcac82.skybroadband.com) (Ping timeout: 245 seconds)
2023-07-07 03:03:10 +0200delYsid`(~user@84-115-138-74.cable.dynamic.surfer.at) (ERC 5.6-git (IRC client for GNU Emacs 30.0.50))
2023-07-07 03:08:21 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 245 seconds)
2023-07-07 03:08:28 +0200 <Axman6> What even is a token??? Nobody knows
2023-07-07 03:10:32 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-07-07 03:10:37 +0200 <Axman6> So WAI has Application = Request -> (Response -> IO ResponseReceived) -> IO ResponseReceived, there isn't much sodumentation about what you should do with the response function, but it feels to me like it really should be treated as a linear argument, it should only be called once. is that something that can be done with current linear types?
2023-07-07 03:11:41 +0200 <Axman6> Request -> (Response -> IO ResponseReceived) %1 -> IO ResponseReceived?
2023-07-07 03:14:27 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-07-07 03:16:40 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-07-07 03:18:11 +0200 <EvanR> are you sure, because there's more things in heaven and middleware than are dreamt of in your philosophy
2023-07-07 03:19:18 +0200 <Axman6> I think it should always be the case that the response handler is only called once, even when middleware is involved, as it can wrap the passed in handler in a new function which itself is only called once
2023-07-07 03:20:12 +0200 <jackdk> I think under this model you have `type Middleware = Application %1 -> Application`, so you consume the old respond function and provide a new one.
2023-07-07 03:20:47 +0200 <Axman6> yeah that feels right
2023-07-07 03:22:03 +0200bilegeek(~bilegeek@2600:1008:b092:dfba:4ead:a88d:cd60:d095)
2023-07-07 03:25:08 +0200 <EvanR> are you required to use the response function
2023-07-07 03:26:12 +0200 <EvanR> or is it more of a continuation
2023-07-07 03:26:24 +0200priesvitne_sklo(~priesvitn@109-230-60-22.dynamic.orange.sk) (Ping timeout: 246 seconds)
2023-07-07 03:33:24 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 246 seconds)
2023-07-07 03:35:43 +0200 <Axman6> it's the only way to create a ResponseReceived, so yes
2023-07-07 03:41:29 +0200 <jackdk> I believe it was done to avoid a rank-2 type, and the constructor is hard to find (not impossible, but you shouldn't go using it if you're writing an application)
2023-07-07 03:54:03 +0200xff0x_(~xff0x@ai086045.d.east.v6connect.net) (Ping timeout: 246 seconds)
2023-07-07 04:00:44 +0200phma(phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce) (Read error: Connection reset by peer)
2023-07-07 04:01:07 +0200phma(phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce)
2023-07-07 04:08:40 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-07-07 04:10:21 +0200jargon(~jargon@184.101.73.95) (Remote host closed the connection)
2023-07-07 04:12:57 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds)
2023-07-07 04:14:38 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-07-07 04:14:38 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-07-07 04:14:39 +0200finn_elijaFinnElija
2023-07-07 04:16:34 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-07-07 04:17:59 +0200td_(~td@i53870936.versanet.de) (Ping timeout: 246 seconds)
2023-07-07 04:19:34 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec)
2023-07-07 04:19:52 +0200td_(~td@i5387091B.versanet.de)
2023-07-07 04:28:35 +0200trev(~trev@user/trev)
2023-07-07 04:29:33 +0200phma(phma@2001:5b0:215a:da58:dcbf:27e8:323f:f6ce) (Read error: Connection reset by peer)
2023-07-07 04:30:05 +0200phma(~phma@host-67-44-208-87.hnremote.net)
2023-07-07 04:42:48 +0200xff0x_(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-07-07 04:42:57 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-07-07 04:46:22 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-07-07 04:52:01 +0200 <talismanick> How difficult is it to learn/use Shake if you use Cabal and not Stack?
2023-07-07 04:52:57 +0200 <talismanick> (I prefer Cabal because it's less restrictive wrt one-off libraries that don't fit neatly into Stackage releases)
2023-07-07 04:53:16 +0200justsomeguy(~justsomeg@user/justsomeguy)
2023-07-07 04:58:02 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-07-07 05:02:13 +0200 <jackdk> As easy as any other hackage package. I have a few internal work projects built upon shake.
2023-07-07 05:03:10 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-07-07 05:03:21 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds)
2023-07-07 05:05:36 +0200mei(~mei@user/mei)
2023-07-07 05:07:14 +0200fweht(uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-07-07 05:11:01 +0200 <EvanR> in the docs for Data.Scientific I find this warning
2023-07-07 05:11:18 +0200 <EvanR> WARNING: 'coefficient' and 'base10exponent' violate substantivity of 'Eq'.
2023-07-07 05:11:40 +0200 <EvanR> that was close, now what does substantivity mean
2023-07-07 05:12:55 +0200 <EvanR> oh, there's an example demonstrating the phenomenon
2023-07-07 05:16:29 +0200 <EvanR> they observe a difference in two scientifics that might report equal according to ==
2023-07-07 05:18:53 +0200nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
2023-07-07 05:24:38 +0200 <sm> talismanick: I think there's no real connection.. unless you are making your shake file a cabal or stack script ?
2023-07-07 05:25:31 +0200 <sm> and that doesn't affect Shake's learnability
2023-07-07 05:30:35 +0200 <Axman6> EvanR: is that because it doesn't make an effort to find the minimal mantissa?
2023-07-07 05:31:47 +0200 <EvanR> something about the internal representation will be normalized when pretty printed or by toDecimalDigits
2023-07-07 05:32:11 +0200 <EvanR> otherwise mantissa might have trailing zeros
2023-07-07 05:35:33 +0200 <Axman6> so 123*10^-3 === 12300*10^-5? (pretty sure those are bout 1.23?)
2023-07-07 05:35:37 +0200 <Axman6> both*
2023-07-07 05:36:05 +0200 <EvanR> they look equal to me
2023-07-07 05:36:30 +0200 <Axman6> but it doesn't normalise the latter into the former right?
2023-07-07 05:36:55 +0200 <EvanR> according to the docs if you're messing with the internal representation, no
2023-07-07 05:37:19 +0200 <EvanR> not after every operation like Rational
2023-07-07 05:48:48 +0200aniketd[m](~aniketdma@2001:470:69fc:105::dede) ()
2023-07-07 05:49:11 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 245 seconds)
2023-07-07 05:49:58 +0200aniketd[m](~aniketdma@2001:470:69fc:105::dede)
2023-07-07 05:50:04 +0200jargon(~jargon@184.101.73.95)
2023-07-07 05:53:41 +0200aforemny_(~aforemny@2001:9e8:6ce6:ca00:3bad:e307:8f54:4c53) (Ping timeout: 246 seconds)
2023-07-07 05:54:02 +0200aforemny(~aforemny@i59F516EE.versanet.de)
2023-07-07 06:05:53 +0200 <Axman6> man, python's coroutines make me feel very unconfortable, they feel so hacky
2023-07-07 06:12:32 +0200son0p(~ff@181.136.122.143) (Ping timeout: 250 seconds)
2023-07-07 06:12:51 +0200robertm(robertm@lattice.rojoma.com) (Quit: WeeChat 3.8)
2023-07-07 06:14:42 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-07-07 06:15:11 +0200robertm(robertm@lattice.rojoma.com)
2023-07-07 06:16:48 +0200oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl)
2023-07-07 06:32:17 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-07-07 06:34:28 +0200hololeap(~quassel@user/hololeap) (Quit: Bye)
2023-07-07 06:36:47 +0200hololeap(~quassel@user/hololeap)
2023-07-07 06:48:59 +0200jargon(~jargon@184.101.73.95) (Remote host closed the connection)
2023-07-07 06:53:33 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-07-07 06:59:37 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-07-07 07:07:44 +0200jargon(~jargon@184.101.73.95)
2023-07-07 07:07:54 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-07-07 07:08:21 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2023-07-07 07:09:00 +0200azimut_(~azimut@gateway/tor-sasl/azimut)
2023-07-07 07:09:20 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-07-07 07:09:28 +0200michalz(~michalz@185.246.207.203)
2023-07-07 07:10:39 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-07-07 07:14:06 +0200 <probie> Axman6: The "new" ones using await (e.g. asyncio), or the old ones sending values to generators (as described in PEP-342)?
2023-07-07 07:16:35 +0200 <maerwald[m]> https://discourse.haskell.org/t/rfc-bumping-recommended-ghc-to-9-4-5-in-ghcup/6866
2023-07-07 07:16:55 +0200Buggys(Buggys@shelltalk.net) (Ping timeout: 246 seconds)
2023-07-07 07:21:31 +0200stilgart(~Christoph@chezlefab.net) (Quit: leaving)
2023-07-07 07:21:42 +0200stilgart(~Christoph@chezlefab.net)
2023-07-07 07:26:04 +0200Buggys(Buggys@Buggy.shelltalk.net)
2023-07-07 07:27:03 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2023-07-07 07:29:46 +0200praknak(~praknak@bcdcac82.skybroadband.com)
2023-07-07 07:33:51 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds)
2023-07-07 07:40:14 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-07-07 07:43:02 +0200Guest5320(~finn@176-151-21-224.abo.bbox.fr)
2023-07-07 08:04:32 +0200bilegeek(~bilegeek@2600:1008:b092:dfba:4ead:a88d:cd60:d095) (Quit: Leaving)
2023-07-07 08:08:06 +0200genieliu(~jianshili@36.112.90.53)
2023-07-07 08:13:51 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-07-07 08:17:15 +0200Guest5320(~finn@176-151-21-224.abo.bbox.fr) (Ping timeout: 246 seconds)
2023-07-07 08:18:18 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 246 seconds)
2023-07-07 08:22:02 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-07-07 08:22:22 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 260 seconds)
2023-07-07 08:23:50 +0200hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 250 seconds)
2023-07-07 08:24:07 +0200son0p(~ff@181.136.122.143)
2023-07-07 08:29:59 +0200son0p(~ff@181.136.122.143) (Ping timeout: 246 seconds)
2023-07-07 08:30:11 +0200Guest5320(~finn@176-151-21-224.abo.bbox.fr)
2023-07-07 08:37:17 +0200fendor(~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0)
2023-07-07 08:45:48 +0200hugo(znc@verdigris.lysator.liu.se)
2023-07-07 08:47:54 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-07-07 08:57:15 +0200gurkenglas(~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de)
2023-07-07 08:59:02 +0200falafel(~falafel@2603-7000-a700-8710-eb2d-b2d5-726c-ab42.res6.spectrum.com) (Ping timeout: 246 seconds)
2023-07-07 09:00:18 +0200alternateved(~user@77-254-166-50.dynamic.inetia.pl)
2023-07-07 09:02:45 +0200fweht(uid404746@id-404746.lymington.irccloud.com)
2023-07-07 09:05:23 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-07-07 09:14:50 +0200genieliu(~jianshili@36.112.90.53) (Quit: Lost terminal)
2023-07-07 09:17:16 +0200gmg(~user@user/gehmehgeh)
2023-07-07 09:18:33 +0200mbuf(~Shakthi@49.207.178.186)
2023-07-07 09:21:47 +0200actioninja6(~actioninj@user/actioninja) (Ping timeout: 246 seconds)
2023-07-07 09:23:31 +0200titibandit(~titibandi@user/titibandit)
2023-07-07 09:24:55 +0200ft(~ft@p508db151.dip0.t-ipconnect.de) (Quit: leaving)
2023-07-07 09:25:26 +0200priesvitne_sklo(~priesvitn@109-230-60-22.dynamic.orange.sk)
2023-07-07 09:25:36 +0200actioninja6(~actioninj@user/actioninja)
2023-07-07 09:25:45 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-07-07 09:28:04 +0200 <Axman6> probie: I'm going to say both
2023-07-07 09:34:36 +0200shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 245 seconds)
2023-07-07 09:34:58 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-07-07 09:36:02 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-07-07 09:36:55 +0200gurkenglas(~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-07-07 09:38:59 +0200Pickchea(~private@user/pickchea)
2023-07-07 09:42:33 +0200hisa38779(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net)
2023-07-07 09:44:01 +0200acidjnk(~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de)
2023-07-07 09:44:03 +0200hisa3877(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 246 seconds)
2023-07-07 09:44:03 +0200hisa38779hisa3877
2023-07-07 09:45:50 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-07-07 09:48:43 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Remote host closed the connection)
2023-07-07 09:50:08 +0200misterfish(~misterfis@87.215.131.102)
2023-07-07 09:52:54 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-07-07 10:09:32 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-07-07 10:16:49 +0200alternateved(~user@77-254-166-50.dynamic.inetia.pl) (Remote host closed the connection)
2023-07-07 10:18:36 +0200ubert(~Thunderbi@2a02:8109:abc0:6434:2722:db0d:9dca:9984)
2023-07-07 10:20:00 +0200alternateved(~user@77-254-166-50.dynamic.inetia.pl)
2023-07-07 10:21:45 +0200Sgeo_(~Sgeo@user/sgeo)
2023-07-07 10:21:52 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-07-07 10:25:12 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-07-07 10:25:25 +0200danse-nr3_(~francesco@151.57.190.75)
2023-07-07 10:25:31 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-07-07 10:26:01 +0200gmg(~user@user/gehmehgeh)
2023-07-07 10:27:48 +0200 <dminuoso_> Axman6: I finally figured out whats wrong with python coroutines.
2023-07-07 10:28:08 +0200 <dminuoso_> Python coroutines are in truth just an implementation detail of green threads.
2023-07-07 10:30:07 +0200priesvitne_sklo(~priesvitn@109-230-60-22.dynamic.orange.sk) (Remote host closed the connection)
2023-07-07 10:30:21 +0200 <dminuoso_> There's so many red herrings around asyncio. The core theme is to facilitate efficient green thread scheduling on things that wait on external resources.
2023-07-07 10:31:10 +0200 <dminuoso_> I mean Haskell has all of python asyncio built-in to GHC RTS + STM
2023-07-07 10:32:15 +0200 <dminuoso_> Well, and some of `async` library for some of the thread coordination stuff.
2023-07-07 10:35:17 +0200mmhat(~mmh@p200300f1c716433cee086bfffe095315.dip0.t-ipconnect.de)
2023-07-07 10:39:21 +0200danse-nr3_(~francesco@151.57.190.75) (Ping timeout: 246 seconds)
2023-07-07 10:40:09 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2023-07-07 10:43:07 +0200bliminse(~bliminse@user/bliminse) (Quit: leaving)
2023-07-07 10:49:48 +0200son0p(~ff@181.136.122.143)
2023-07-07 10:52:40 +0200danse-nr3_(~francesco@151.57.190.75)
2023-07-07 10:53:00 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-07-07 11:00:07 +0200dminuoso_dminuoso
2023-07-07 11:00:28 +0200Sgeo_(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-07-07 11:02:49 +0200gurkenglas(~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de)
2023-07-07 11:09:35 +0200DustinStiles[m](~duwstiles@2001:470:69fc:105::3:699b) (Remote host closed the connection)
2023-07-07 11:11:10 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2023-07-07 11:12:02 +0200polykernel[m](~polykerne@user/polykernel) (Remote host closed the connection)
2023-07-07 11:12:54 +0200gtf(~gideon@2a02:8012:2259:0:299:560e:70f9:4290)
2023-07-07 11:14:56 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl)
2023-07-07 11:18:07 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Remote host closed the connection)
2023-07-07 11:26:56 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-07-07 11:27:56 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds)
2023-07-07 11:28:16 +0200Lord_of_Life_Lord_of_Life
2023-07-07 11:32:58 +0200azimut_(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-07-07 11:41:22 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-07-07 11:42:08 +0200fendor(~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0) (Remote host closed the connection)
2023-07-07 11:43:49 +0200fendor(~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0)
2023-07-07 11:45:50 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds)
2023-07-07 12:02:56 +0200xff0x_(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 245 seconds)
2023-07-07 12:04:39 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-07-07 12:06:08 +0200tcard_(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving)
2023-07-07 12:07:47 +0200tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
2023-07-07 12:09:26 +0200Pickchea(~private@user/pickchea)
2023-07-07 12:10:07 +0200danse-nr3_(~francesco@151.57.190.75) (Remote host closed the connection)
2023-07-07 12:13:38 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-07-07 12:15:27 +0200danse-nr3_(~francesco@151.57.190.75)
2023-07-07 12:15:57 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl)
2023-07-07 12:16:21 +0200dsrt^(~cd@24.125.210.85)
2023-07-07 12:18:38 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec)
2023-07-07 12:19:37 +0200driib(~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat)
2023-07-07 12:20:04 +0200driib(~driib@vmi931078.contaboserver.net)
2023-07-07 12:23:05 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Ping timeout: 246 seconds)
2023-07-07 12:25:35 +0200azr4e1(~azr4e1@host86-134-72-140.range86-134.btcentralplus.com)
2023-07-07 12:25:38 +0200azr4e1(~azr4e1@host86-134-72-140.range86-134.btcentralplus.com) (Remote host closed the connection)
2023-07-07 12:37:28 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-07-07 12:39:36 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 245 seconds)
2023-07-07 12:42:26 +0200Lewix(uid158496@id-158496.tinside.irccloud.com)
2023-07-07 12:42:32 +0200 <Lewix> hi all
2023-07-07 12:42:36 +0200 <Lewix> is free node still alive?
2023-07-07 12:43:29 +0200 <Lewix> I need to learn Haskell pretty fast, any advice that point me to the right direction would be appreciated. I'm a huge fan of functional programming but have not used it for years.
2023-07-07 12:44:56 +0200 <danse-nr3_> been writing haskell for years and still have not learned it
2023-07-07 12:46:02 +0200 <tomsmeding> Lewix: https://www.haskell.org/documentation/ is not very opinionated but perhaps a good start
2023-07-07 12:49:58 +0200 <Lewix> @danse-nr3_ that is very encouraging :)
2023-07-07 12:49:58 +0200 <lambdabot> Unknown command, try @list
2023-07-07 12:50:19 +0200 <Lewix> @tomsmeding thank you man
2023-07-07 12:50:19 +0200 <lambdabot> Unknown command, try @list
2023-07-07 12:50:33 +0200 <Lewix> danse-nr3_: that is very encouraging :)
2023-07-07 12:50:39 +0200 <Lewix> tomsmeding: thank you man!
2023-07-07 12:51:10 +0200fweht(uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-07-07 12:51:52 +0200 <danse-nr3_> apologies, was an indirect advice about setting expectations and the "need" requirement. The value-level language, focusing on pure code, is quite consistent and in my opinion one can get a long way by approaching it
2023-07-07 12:52:32 +0200 <Lewix> tomsmeding: any video lecture that you enjoyed or would recommend?
2023-07-07 12:52:38 +0200 <Lewix> danse-nr3_: noted. It's all good
2023-07-07 12:57:15 +0200 <juri_> Lewix: it depends how you learn. i learn by doing, so more doing works. :)
2023-07-07 12:57:27 +0200tomsmedingis same as juri_
2023-07-07 12:57:42 +0200 <tomsmeding> find something you like building, and try to do it well
2023-07-07 12:58:13 +0200 <tomsmeding> depending on your level, some of the slides here are nice https://uu-afp.github.io/schedule.html
2023-07-07 12:58:53 +0200 <Rembane> Lewix: Also, come back here and ask questions whenever you get stuck!
2023-07-07 12:59:50 +0200 <probie> If I write something which uses backpack, and upload it to hackage, will things for users break beyond the haddock docs?
2023-07-07 13:01:45 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-07-07 13:02:34 +0200gmg(~user@user/gehmehgeh)
2023-07-07 13:02:35 +0200merijn(~merijn@097-099-045-062.dynamic.caiway.nl)
2023-07-07 13:13:36 +0200bontaq(~user@ool-45779b84.dyn.optonline.net)
2023-07-07 13:14:32 +0200 <maerwald[m]> probie: stack users won't be able to use it
2023-07-07 13:15:08 +0200hpc(~juzz@ip98-169-35-163.dc.dc.cox.net) (Ping timeout: 240 seconds)
2023-07-07 13:17:19 +0200hpc(~juzz@ip98-169-35-163.dc.dc.cox.net)
2023-07-07 13:20:25 +0200 <dminuoso> And depending on how much backpack you use, it can greatly limit the people capable or willing to work on your library.
2023-07-07 13:23:12 +0200 <probie> dminuoso: That doesn't bother me. If they're not interested in it, they're not interested in it. Any library I write is non-proselytising
2023-07-07 13:26:20 +0200 <Lewix> Also any resources to prepare for interview with Haskell is more than welcome
2023-07-07 13:26:23 +0200smalltalkman(uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
2023-07-07 13:26:28 +0200 <Lewix> Rembane: thank you
2023-07-07 13:28:47 +0200 <probie> maerwald[m]: I thought stack uses cabal under the hood. Are there any issues if the libraries depended on are the implementation of backpack signatures?
2023-07-07 13:30:37 +0200slaydr(~slaydr@2601:1c2:980:4ea0::43b3)
2023-07-07 13:33:09 +0200hippoid(~hippoid@user/hippoid)
2023-07-07 13:33:47 +0200ryantrinkle(~ryantrink@89.247.249.243) (Ping timeout: 246 seconds)
2023-07-07 13:37:10 +0200 <merijn> probie: https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07
2023-07-07 13:37:50 +0200merijnincreases the value of his "time saved on explaining the different meanings of cabal"-counter
2023-07-07 13:39:36 +0200danse-nr3_(~francesco@151.57.190.75) (Ping timeout: 245 seconds)
2023-07-07 13:40:12 +0200hippoid(~hippoid@user/hippoid) (Quit: WeeChat 3.8)
2023-07-07 13:40:57 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-07-07 13:42:28 +0200pandeyan(~pandeyan@135-180-53-134.fiber.dynamic.sonic.net) (Quit: ZNC 1.8.2 - https://znc.in)
2023-07-07 13:45:25 +0200 <probie> That failed to answer my question, probably because I'm not particularly bright
2023-07-07 13:46:12 +0200 <probie> but my current guess is that if there exists package X that's a dependency, whether X uses backpack or not is irrelevant to whether or not stack can install it
2023-07-07 13:46:24 +0200anpad(~pandeyan@user/anpad)
2023-07-07 13:46:39 +0200 <Rembane> probie: I know way too little about Stack + backpack, but there's a very long thread about it here: https://github.com/commercialhaskell/stack/issues/2540
2023-07-07 13:47:06 +0200 <probie> in which case "stack users won't be able to use it" seems wrong. It seems like all they won't be able to do is instantiate backpack sigs
2023-07-07 13:50:19 +0200danse-nr3_(~francesco@151.57.190.75)
2023-07-07 13:53:01 +0200notzmv(~zmv@user/notzmv)
2023-07-07 13:54:22 +0200 <dminuoso> probie: Oh its not necessarily about proselytising, but rather about maintenance and ownership.
2023-07-07 13:54:42 +0200 <dminuoso> The more exotic the tools used to build the product, the less people will contribute or be able to pick it up later on.
2023-07-07 13:54:53 +0200 <dminuoso> I know, in this channel this is a heretic thing to say.
2023-07-07 13:55:41 +0200 <dminuoso> It's much more fun to compile to categories with dependent types, using highly undocumented cabal features..
2023-07-07 13:56:40 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-07-07 13:57:22 +0200 <tomsmeding> and use TH in the process
2023-07-07 14:09:05 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl)
2023-07-07 14:11:47 +0200xff0x_(~xff0x@ai086045.d.east.v6connect.net)
2023-07-07 14:13:27 +0200fweht(uid404746@id-404746.lymington.irccloud.com)
2023-07-07 14:16:14 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-07-07 14:25:56 +0200smalltalkman(uid545680@id-545680.hampstead.irccloud.com)
2023-07-07 14:26:38 +0200danse-nr3_(~francesco@151.57.190.75) (Read error: Connection reset by peer)
2023-07-07 14:26:51 +0200danse-nr3_(~francesco@151.57.136.214)
2023-07-07 14:40:04 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-07-07 14:46:17 +0200slaydr(~slaydr@2601:1c2:980:4ea0::43b3) (Read error: Connection reset by peer)
2023-07-07 14:46:47 +0200Guest5320(~finn@176-151-21-224.abo.bbox.fr) (Ping timeout: 264 seconds)
2023-07-07 14:48:22 +0200 <jackdk> hasn't backpack been out for yonks though?
2023-07-07 14:49:18 +0200 <merijn> jackdk: Yes
2023-07-07 14:49:24 +0200 <merijn> probably close to a decade or longer
2023-07-07 14:57:34 +0200ft(~ft@p508db151.dip0.t-ipconnect.de)
2023-07-07 14:59:39 +0200pyooque(~puke@user/puke)
2023-07-07 14:59:39 +0200pukeGuest8530
2023-07-07 14:59:39 +0200Guest8530(~puke@user/puke) (Killed (platinum.libera.chat (Nickname regained by services)))
2023-07-07 14:59:39 +0200pyooquepuke
2023-07-07 15:18:07 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1)
2023-07-07 15:24:08 +0200Zambyte(~user@c-73-114-31-74.hsd1.ma.comcast.net)
2023-07-07 15:24:36 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-07-07 15:24:36 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-07-07 15:24:36 +0200wroathe(~wroathe@user/wroathe)
2023-07-07 15:24:50 +0200 <Profpatsch> I want to replace a bunch of allocation bracket functions with a single ResourceT block
2023-07-07 15:26:03 +0200 <Profpatsch> is ResourceT.allocate forkIO killThread a viable way to wrap a thread that has a sub-task which does not need cleanup itself?
2023-07-07 15:36:55 +0200comerijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-07-07 15:38:28 +0200kimiamania6(~681cf57f@user/kimiamania) (Quit: PegeLinux)
2023-07-07 15:39:09 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 240 seconds)
2023-07-07 15:39:51 +0200kimiamania6(~681cf57f@user/kimiamania)
2023-07-07 15:39:56 +0200merijn(~merijn@097-099-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2023-07-07 15:40:15 +0200 <Profpatsch> Hm, seems to work
2023-07-07 15:40:28 +0200 <Profpatsch> (it’s just for a dumb heartbeat log output)
2023-07-07 15:47:58 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-07-07 15:55:16 +0200 <Inst_> bleh, going back to translating "Big Book of Small Python Projects" into Haskell
2023-07-07 15:56:12 +0200 <Inst_> i'm trying to do a vigniere cipher, but via HOF instead of manual recursion
2023-07-07 15:57:14 +0200 <Inst_> ehh, the probable solution is foldr
2023-07-07 15:58:51 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl)
2023-07-07 16:00:05 +0200 <int-e> zipWith and cycle?
2023-07-07 16:02:38 +0200lainon(~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39)
2023-07-07 16:03:37 +0200lainon(~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39) (Client Quit)
2023-07-07 16:08:00 +0200 <tomsmeding> ^
2023-07-07 16:14:49 +0200jinsl(~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) (Quit: ZNC - https://znc.in)
2023-07-07 16:17:06 +0200juri_(~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 245 seconds)
2023-07-07 16:18:01 +0200 <Profpatsch> Hm, is there any multiplication that can determine wraparound on Iont?
2023-07-07 16:18:03 +0200 <Profpatsch> *Int?
2023-07-07 16:18:13 +0200 <Profpatsch> Maybe a newtype that throws an exception?
2023-07-07 16:19:19 +0200jinsl(~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea)
2023-07-07 16:23:15 +0200Midjak(~Midjak@82.66.147.146)
2023-07-07 16:24:41 +0200 <c_wraith> I suppose you could do that, but detecting it in ways that aren't architecture-specific is an incredible slowdown.
2023-07-07 16:26:00 +0200 <Profpatsch> I just had to double and checked whether the result is smaller, which should be pretty easy
2023-07-07 16:26:05 +0200 <Profpatsch> It’s not a tight loop anyway
2023-07-07 16:26:37 +0200 <Profpatsch> Kind of a weird excercise anyway dunno why I’m spending time on this lol
2023-07-07 16:26:44 +0200 <Profpatsch> Mostly out of interest I guess
2023-07-07 16:28:15 +0200 <c_wraith> the most general way to detect it is look for the sign of the output being wrong.
2023-07-07 16:28:57 +0200 <c_wraith> add two positive numbers and get a negative? multiply a negative number by a positive number and get a positive?
2023-07-07 16:28:59 +0200juri_(~juri@84-19-175-187.pool.ovpn.com)
2023-07-07 16:29:03 +0200thegeekinside(~thegeekin@189.217.90.138)
2023-07-07 16:33:19 +0200Arima_Kun(~Arima_Kun@45.124.5.97)
2023-07-07 16:33:57 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 245 seconds)
2023-07-07 16:36:34 +0200misterfish(~misterfis@87.215.131.102) (Ping timeout: 260 seconds)
2023-07-07 16:36:44 +0200Arima_Kun(~Arima_Kun@45.124.5.97) (Client Quit)
2023-07-07 16:37:02 +0200ripspin(~chatzilla@1.145.156.103)
2023-07-07 16:41:52 +0200 <Inst_> int-e: i'm trying to skip non-alphanumerical characters
2023-07-07 16:47:33 +0200juri_(~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 246 seconds)
2023-07-07 16:52:09 +0200jinsl(~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) (Quit: ZNC - https://znc.in)
2023-07-07 16:54:01 +0200jinsl(~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea)
2023-07-07 16:57:57 +0200jinsl(~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea) (Client Quit)
2023-07-07 16:59:27 +0200juri_(~juri@84-19-175-187.pool.ovpn.com)
2023-07-07 17:00:25 +0200shriekingnoise(~shrieking@186.137.175.87)
2023-07-07 17:02:20 +0200 <EvanR> perform the operation on an intermediate Integer and check the "actual result" for overflow xD
2023-07-07 17:04:14 +0200 <EvanR> Inst_, span and break?
2023-07-07 17:09:01 +0200 <janus> anybody at munihac? i landed a bit late, not sure where people are now
2023-07-07 17:11:18 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-07-07 17:13:12 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl)
2023-07-07 17:17:12 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-07-07 17:21:29 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Remote host closed the connection)
2023-07-07 17:21:46 +0200 <Inst_> is there a better way to do it?
2023-07-07 17:22:11 +0200 <Inst_> i mean, i'm pretty satisfied with using foldr on the cycled key
2023-07-07 17:22:33 +0200 <EvanR> in a sense foldr can do anything
2023-07-07 17:22:37 +0200 <Inst_> and using right fold as left fold
2023-07-07 17:23:14 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec)
2023-07-07 17:23:15 +0200acidjnk(~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-07-07 17:23:20 +0200alternateved(~user@77-254-166-50.dynamic.inetia.pl) (Ping timeout: 250 seconds)
2023-07-07 17:23:50 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-07-07 17:23:55 +0200 <Inst_> so you have an outside accumulator that's the actual text, and the cycled key as what's being folded over, with the lambda being keyed to process the accumulator
2023-07-07 17:24:05 +0200 <Inst_> mildly annoyed that foldr1 doesn't work with this
2023-07-07 17:25:32 +0200 <EvanR> if you're talking about accumulators then you probably (a form of) foldl
2023-07-07 17:25:39 +0200 <EvanR> probably want*
2023-07-07 17:25:52 +0200 <Inst_> iirc you can't use an outside accumulator...
2023-07-07 17:26:03 +0200 <EvanR> what does that mean
2023-07-07 17:26:26 +0200 <Inst_> well, i think you can do it that way
2023-07-07 17:27:15 +0200 <Inst_> you know the foldr trick wherein you have (foldr fun (const foo) list1 list2), right?
2023-07-07 17:27:27 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Ping timeout: 246 seconds)
2023-07-07 17:27:50 +0200 <Inst_> well tbh maybe i can exploit laziness and the fact that seq won't force the evaluation beneath a tuple
2023-07-07 17:27:53 +0200 <EvanR> no but that's looks groovy before I've had coffee
2023-07-07 17:28:25 +0200nick4(~nick@2600:8807:9084:7800:6937:8c50:52d4:31ba)
2023-07-07 17:28:51 +0200 <Inst_> so i can still have an infinite list with seq, just it can't be on the top level, right?
2023-07-07 17:28:51 +0200 <EvanR> if you have 2 parallel accumulators that's just a foldl using a tuple
2023-07-07 17:29:35 +0200 <Inst_> iirc even if you seq a list, it won't trigger a bottom, right? You'd need force from deepseq to trigger a bottom from an infinite list?
2023-07-07 17:29:44 +0200 <geekosaur> yes
2023-07-07 17:29:51 +0200 <geekosaur> `seq` is only to WHNF
2023-07-07 17:30:14 +0200 <EvanR> > [undefined] `seq` '👍'
2023-07-07 17:30:16 +0200 <lambdabot> '\128077'
2023-07-07 17:32:34 +0200 <Inst_> but tbh foldr stil lworks better if i'm working with lists, no?
2023-07-07 17:33:01 +0200 <Inst_> since the foldr can lazily generate the list, whereas foldl' will have to complete the list before it can produce any output?
2023-07-07 17:33:03 +0200 <EvanR> foldr is pretty bad when adding up a list for example
2023-07-07 17:33:15 +0200 <EvanR> unless you're scanning for all intermediate sums
2023-07-07 17:33:22 +0200 <Inst_> i mean foldr (:) is performant, no?
2023-07-07 17:33:30 +0200 <Inst_> foldr (:) []
2023-07-07 17:33:36 +0200 <EvanR> that's lazy
2023-07-07 17:33:47 +0200 <EvanR> which is good
2023-07-07 17:34:49 +0200 <EvanR> foldl and foldl' don't work on infinite lists
2023-07-07 17:35:15 +0200 <Inst_> the problem is that i don't feel like map is powerful enough for it, i.e, there's an implicitly mutating accumulator here
2023-07-07 17:35:26 +0200 <EvanR> :t mapAccum
2023-07-07 17:35:26 +0200 <Inst_> was looking at map accum, but not familiar with it, was thinking scanr / scanl, but not used to it
2023-07-07 17:35:27 +0200 <lambdabot> error:
2023-07-07 17:35:27 +0200 <lambdabot> • Variable not in scope: mapAccum
2023-07-07 17:35:27 +0200 <lambdabot> • Perhaps you meant one of these:
2023-07-07 17:35:31 +0200 <EvanR> :t mapAccumR
2023-07-07 17:35:32 +0200 <lambdabot> Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c)
2023-07-07 17:35:50 +0200 <EvanR> :t mapAccumL
2023-07-07 17:35:51 +0200 <lambdabot> Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c)
2023-07-07 17:36:18 +0200 <EvanR> it's map with an accumulator
2023-07-07 17:36:47 +0200 <Inst_> maybe mapaccum is the best solution here
2023-07-07 17:37:27 +0200econo_(uid147250@id-147250.tinside.irccloud.com)
2023-07-07 17:38:58 +0200bontaq(~user@ool-45779b84.dyn.optonline.net)
2023-07-07 17:39:59 +0200mmhat(~mmh@p200300f1c716433cee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 4.0.1)
2023-07-07 17:40:20 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-07-07 17:41:27 +0200juri_(~juri@84-19-175-187.pool.ovpn.com) (Ping timeout: 246 seconds)
2023-07-07 17:42:28 +0200Sgeo(~Sgeo@user/sgeo)
2023-07-07 17:49:14 +0200JanusTroelsen[m](~janustmat@2001:470:69fc:105::3:7e89)
2023-07-07 17:53:18 +0200juri_(~juri@84-19-175-187.pool.ovpn.com)
2023-07-07 17:54:13 +0200danse-nr3_(~francesco@151.57.136.214) (Read error: Connection reset by peer)
2023-07-07 18:00:29 +0200nick4(~nick@2600:8807:9084:7800:6937:8c50:52d4:31ba) (Ping timeout: 246 seconds)
2023-07-07 18:00:51 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 245 seconds)
2023-07-07 18:00:56 +0200 <ski> Inst_ : why accumulator ?
2023-07-07 18:02:44 +0200jinsl(~jinsl@2408:8207:2550:b730:211:32ff:fec8:6aea)
2023-07-07 18:04:24 +0200Ross[m](~zhichuche@2001:470:69fc:105::3:584b) (Remote host closed the connection)
2023-07-07 18:07:23 +0200 <Inst_> let's say you're doing a vigenere cipher
2023-07-07 18:07:32 +0200 <Inst_> the way i'm doing it is that i'm encoding the key as a list of ints (offsets)
2023-07-07 18:08:38 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec)
2023-07-07 18:09:09 +0200 <Inst_> bleh, my brain is dead
2023-07-07 18:10:27 +0200 <ski> sounds reasonable, so far
2023-07-07 18:11:10 +0200 <Inst_> maybe there's an easier way to do it
2023-07-07 18:11:17 +0200 <Inst_> i need zip to be able to skip whitespace and symbols, etc
2023-07-07 18:11:44 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-07-07 18:11:50 +0200 <ski> hm, i see
2023-07-07 18:12:06 +0200 <ski> so you're keeping the key as the accumulator, yes ?
2023-07-07 18:12:54 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-07-07 18:13:02 +0200 <Inst_> yeah
2023-07-07 18:13:08 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2023-07-07 18:13:25 +0200 <Inst_> anyways, moved onto a different problem, which is figuring out how to get haskell win32 to replicate the clipboard copy function
2023-07-07 18:14:10 +0200mei(~mei@user/mei)
2023-07-07 18:14:38 +0200 <EvanR> are you using win32 bindings or something
2023-07-07 18:15:12 +0200 <Inst_> should I be using something else?
2023-07-07 18:15:22 +0200 <EvanR> no just wondering
2023-07-07 18:15:22 +0200 <Inst_> "type HANDLE = Ptr ()"
2023-07-07 18:19:38 +0200nick4(~nick@50.86.118.19)
2023-07-07 18:22:49 +0200 <Inst_> https://hackage.haskell.org/package/Clipboard
2023-07-07 18:22:51 +0200 <Inst_> this is just a better idea
2023-07-07 18:24:51 +0200 <Inst_> okay, does not support Wayland
2023-07-07 18:24:52 +0200 <Inst_> doip
2023-07-07 18:25:01 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 245 seconds)
2023-07-07 18:26:31 +0200 <Inst_> provisionally:
2023-07-07 18:26:32 +0200 <Inst_> https://paste.tomsmeding.com/RLzR9DHm
2023-07-07 18:26:46 +0200barcisz(~barcisz@79.191.32.38.ipv4.supernova.orange.pl) (Quit: Connection closed)
2023-07-07 18:28:55 +0200 <Inst_> okay, and it works, with some typos
2023-07-07 18:30:48 +0200dtman34(~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2023-07-07 18:30:53 +0200 <EvanR> \o/
2023-07-07 18:31:57 +0200 <Inst_> btw why is there only mapAccumL not mapAccumL'?
2023-07-07 18:32:06 +0200nick4(~nick@50.86.118.19) (Ping timeout: 245 seconds)
2023-07-07 18:32:16 +0200dtman34(~dtman34@c-76-156-89-180.hsd1.mn.comcast.net)
2023-07-07 18:37:39 +0200 <int-e> because the result of the accumulator function is forced? (the pair has to be deconstructed)
2023-07-07 18:38:09 +0200 <EvanR> I see a 10 year old mailing list thread on the topic and it seems to be an episode in the debate on why sum should be foldl and not foldl'
2023-07-07 18:38:18 +0200 <int-e> s/accumulator/step/
2023-07-07 18:38:40 +0200 <EvanR> deconstruct a pair doesn't force the accumulator though
2023-07-07 18:39:47 +0200 <int-e> But you have the power to do so inside the step function.
2023-07-07 18:40:05 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-07-07 18:40:08 +0200 <int-e> a `seq` c `seq` (a,c)
2023-07-07 18:41:01 +0200 <int-e> With foldl, you don't have that ability.
2023-07-07 18:41:10 +0200 <EvanR> I was about to say
2023-07-07 18:41:36 +0200 <int-e> So having `foldl'` is practically a necessity.
2023-07-07 18:43:04 +0200 <int-e> (Also, there are two elements in that pair so if you start offering strict versions of mapAccumL, do you force both or only one of them, or do you provide four variants? And how do you name them?)
2023-07-07 18:43:26 +0200 <EvanR> I see, foldl immediately recurses to the end of the list before doing anything else, mapAccumL sets up a chain of (non-lazy) tuples
2023-07-07 18:43:48 +0200 <EvanR> so your code is running at each step
2023-07-07 18:44:23 +0200 <EvanR> or...
2023-07-07 18:45:25 +0200 <Inst_> ffff
2023-07-07 18:45:54 +0200 <Inst_> jesus christ, someone talked me into using if then else for when you only have two alternatives, but even though it's more terse, i somehow feel that guards are still more readable overall
2023-07-07 18:45:56 +0200 <int-e> ffffine?
2023-07-07 18:46:20 +0200 <int-e> (too slow)
2023-07-07 18:46:55 +0200 <dolio> I usually prefer guards, I think.
2023-07-07 18:47:11 +0200 <dolio> Unless it's in the middle of some other expression.
2023-07-07 18:48:30 +0200 <int-e> yeah it's situational
2023-07-07 18:48:34 +0200 <EvanR> ok like scanl mapAccumL on list works as long as you carefully consume the result, and via magic of update frames, you don't hold on to old accumulators
2023-07-07 18:55:07 +0200 <Inst_> is it really smelly to immediately map into an IO action before binding it?
2023-07-07 18:55:26 +0200 <Inst_> say, transform <$> getLine
2023-07-07 18:55:39 +0200 <EvanR> miranda guards ftw https://paste.tomsmeding.com/LABOLtZy
2023-07-07 18:57:40 +0200 <tomsmeding> Inst_: that's a common pattern
2023-07-07 18:57:50 +0200fendor(~fendor@2a02:8388:1640:be00:821b:25b5:c8f3:73a0) (Remote host closed the connection)
2023-07-07 18:59:59 +0200 <EvanR> lines <$> getContents -- 😎
2023-07-07 19:01:51 +0200 <[exa]> Inst_: is it really "before" binding it?
2023-07-07 19:02:25 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-07-07 19:02:45 +0200 <EvanR> stuff <- getLine <&> transform -- there you go
2023-07-07 19:03:48 +0200 <Inst_> afaik IO is strict, no?
2023-07-07 19:04:02 +0200 <Inst_> it's only lazy when you unsafeInterleaveIO it, and some IO functions have built-ins, no?
2023-07-07 19:04:08 +0200 <[exa]> it is, with respect to other IO actions
2023-07-07 19:04:09 +0200 <Inst_> erm, built-in unsafeInterleaveIO?
2023-07-07 19:06:38 +0200 <[exa]> but binding doesn't technically "do" anything so it's pretty hard to say "when" (or even if) it happens
2023-07-07 19:07:07 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2023-07-07 19:08:36 +0200 <tomsmeding> Inst_: if X is a normal IO action, then f <$> X will first fully complete X, and then apply f to the result
2023-07-07 19:09:01 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-07-07 19:09:17 +0200 <tomsmeding> indeed for things that implement "lazy IO", like getContents, readFile, and perhaps also getLine, there is some unsafeInterleaveIO happening so that the IO is happening on-demand as consumers need its result
2023-07-07 19:09:50 +0200 <tomsmeding> but f doesn't demand X's result -- if f's result is unused, still nothing happens
2023-07-07 19:10:13 +0200 <tomsmeding> or, well, IO's (>>=) evaluates the result of the LHS to WHNF, so something might happen, but probably not much
2023-07-07 19:10:23 +0200ripspin(~chatzilla@1.145.156.103) (Remote host closed the connection)
2023-07-07 19:10:52 +0200 <tomsmeding> but there's little difference between 'do { tmp <- getLine ; let stuff = transform tmp ; ...}' and 'do { stuff <- transform <$> getLine ; ... }'
2023-07-07 19:11:11 +0200 <EvanR> getLine from System.IO at least blocks until it gets a whole line
2023-07-07 19:11:15 +0200 <tomsmeding> I think not even a WHNF laziness difference, if IO's fmap is consistent with its (>>=)
2023-07-07 19:11:18 +0200 <tomsmeding> ah
2023-07-07 19:12:44 +0200 <EvanR> in some languages there's a style convention to put I/O statements like getLine on their own line, resulting in an increase in variable names
2023-07-07 19:12:56 +0200 <EvanR> instead of doing a lot on one line
2023-07-07 19:14:10 +0200 <Inst_> Some or most?
2023-07-07 19:14:38 +0200perrierjouet(~perrierjo@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 4.0.0)
2023-07-07 19:14:43 +0200 <EvanR> no I'm going to chalk that one up to bizarre cult-like behavior
2023-07-07 19:15:35 +0200 <EvanR> chaining operations together reduces variable naming
2023-07-07 19:17:53 +0200 <Inst_> but isn't variable naming useful? Like, some programmers don't believe in anonymous lambdas
2023-07-07 19:18:15 +0200 <dolio> Sometimes. Sometimes not.
2023-07-07 19:18:36 +0200 <Inst_> Going into Python, I get chortles when I insist on keeping the Haskell idiom of named lambdas and actually assigning them before I use them.
2023-07-07 19:18:40 +0200 <dolio> Just like parentheses. Sometimes they make things clearer. Sometimes they make things less clear.
2023-07-07 19:19:11 +0200 <EvanR> yeah you can't go into python acting like it's haskell
2023-07-07 19:19:27 +0200mbuf(~Shakthi@49.207.178.186) (Quit: Leaving)
2023-07-07 19:19:41 +0200 <Inst_> I've read in places actually naming your lambdas somehow improves performance
2023-07-07 19:19:55 +0200 <EvanR> that's annoying
2023-07-07 19:20:05 +0200 <Inst_> Python is annoying, what else is new?
2023-07-07 19:20:40 +0200 <EvanR> they should introduce an internal name on your behalf then xD
2023-07-07 19:21:07 +0200 <EvanR> make it two for good measure
2023-07-07 19:21:25 +0200jinsun(~jinsun@user/jinsun)
2023-07-07 19:21:38 +0200ubert(~Thunderbi@2a02:8109:abc0:6434:2722:db0d:9dca:9984) (Read error: Connection reset by peer)
2023-07-07 19:22:52 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-07-07 19:25:24 +0200captnemo(~captnemo@193.32.127.239)
2023-07-07 19:31:17 +0200nick4(~nick@2600:8807:9084:7800:dc97:418d:c7fc:117f)
2023-07-07 19:36:52 +0200 <EvanR> int-e, https://mail.haskell.org/pipermail/libraries/2012-November/018766.html 🤔
2023-07-07 19:36:57 +0200ystael(~ystael@user/ystael) (Ping timeout: 246 seconds)
2023-07-07 19:39:29 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-07-07 19:41:52 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 245 seconds)
2023-07-07 19:43:49 +0200comerijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 240 seconds)
2023-07-07 19:46:29 +0200danse-nr3(~francesco@151.43.173.33)
2023-07-07 19:46:45 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 246 seconds)
2023-07-07 19:49:33 +0200dibblego(~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds)
2023-07-07 19:49:53 +0200dibblego(~dibblego@116-255-1-157.ip4.superloop.au)
2023-07-07 19:49:53 +0200dibblego(~dibblego@116-255-1-157.ip4.superloop.au) (Changing host)
2023-07-07 19:49:53 +0200dibblego(~dibblego@haskell/developer/dibblego)
2023-07-07 19:50:05 +0200 <int-e> EvanR: oh hmm. I guess the issue then is that let !(x,y) = mapAccumL (\a b -> let !x = a+b in (x, ())) 0 [1..1000000 :: Int] gives you a big unevaluated thunk for x.
2023-07-07 19:51:14 +0200 <int-e> But if you evaluate the resulting `y` to the end, that will also evaluate x.
2023-07-07 19:51:24 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-07-07 19:51:37 +0200 <EvanR> aiui it depends on what you do next, look at x first and you're screwed. Process all of y you're not
2023-07-07 19:51:41 +0200Lewix(uid158496@id-158496.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-07-07 19:52:16 +0200 <int-e> yeah as I was trying to say
2023-07-07 19:52:29 +0200 <EvanR> that bang(x,y) doesn't do anything right
2023-07-07 19:52:41 +0200 <dolio> Right.
2023-07-07 19:52:56 +0200 <dolio> Oh wait, no, it does.
2023-07-07 19:52:59 +0200 <int-e> EvanR: well, it does *something*; it overrides the default laziness of `let`.
2023-07-07 19:53:23 +0200 <EvanR> default laziness?
2023-07-07 19:53:25 +0200 <dolio> It only does something with respect to code that wasn't written, though.
2023-07-07 19:53:28 +0200 <int-e> EvanR: but it doesn't do much in this context because `mapAccumL` is using a lazy-in-state state monad.
2023-07-07 19:53:40 +0200 <int-e> > let (x,y) = undefined in ()
2023-07-07 19:53:41 +0200 <lambdabot> ()
2023-07-07 19:53:43 +0200 <int-e> > let !(x,y) = undefined in ()
2023-07-07 19:53:44 +0200 <lambdabot> *Exception: Prelude.undefined
2023-07-07 19:54:28 +0200 <int-e> So there's room for a mapAccumL variant that uses a strict-in-state state monad.
2023-07-07 19:55:12 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 245 seconds)
2023-07-07 19:56:23 +0200 <EvanR> would that hypothetically mean you don't have to be as careful with the results?
2023-07-07 19:58:42 +0200 <dolio> If mapAccumL gets inlined, does GHC just figure out the strictness?
2023-07-07 19:59:34 +0200 <dolio> Similar to sum on particular types.
2023-07-07 20:00:09 +0200nurupo(~nurupo.ga@user/nurupo) (Quit: nurupo.ga)
2023-07-07 20:00:20 +0200 <int-e> @where L.hs
2023-07-07 20:00:20 +0200 <lambdabot> what lambdabot has in scope is at https://silicon.int-e.eu/lambdabot/State/Pristine.hs
2023-07-07 20:00:24 +0200nurupo(~nurupo.ga@user/nurupo)
2023-07-07 20:01:05 +0200 <int-e> @let import Control.Monad.State.Strict as S'
2023-07-07 20:01:07 +0200 <lambdabot> Defined.
2023-07-07 20:01:56 +0200 <dolio> Strict State isn't strict in the state value. It just forces the tuple in (>>=) or something.
2023-07-07 20:02:08 +0200 <EvanR> let (x,y) = undefined in () ==> (), case undefined of (x,y) -> () ==> CRASH, case undefined of ~(x,y) -> () ==> (), .....
2023-07-07 20:02:25 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-07-07 20:02:37 +0200 <int-e> > fst $ S'.runState (traverse (\a -> S'.modify (+a) >> get) [1,2,undefined]) 0
2023-07-07 20:02:39 +0200 <lambdabot> [1,3,*Exception: Prelude.undefined
2023-07-07 20:02:54 +0200 <int-e> > fst $ S'.runState (traverse (\a -> S'.modify' (+a) >> get) [1,2,undefined]) 0
2023-07-07 20:02:55 +0200 <lambdabot> *Exception: Prelude.undefined
2023-07-07 20:03:15 +0200int-eis confused
2023-07-07 20:04:18 +0200 <int-e> Oh, wait, the lazy state monad is lazy in the (s,a) pairs produced by the intermediate actions.
2023-07-07 20:04:19 +0200 <EvanR> the last one is most strict
2023-07-07 20:04:42 +0200 <EvanR> yeah
2023-07-07 20:05:03 +0200 <EvanR> that's what I was originally looking at but didn't realize the "default laziness of let"
2023-07-07 20:05:06 +0200 <int-e> (It has been a while since I needed that information.)
2023-07-07 20:05:35 +0200 <dminuoso> jackdk: Yes, and largely undocumented. You have to refer to the original PhD thesis and Edwards repositories to know how to use backpack.
2023-07-07 20:05:36 +0200 <int-e> > runState (undefined >> put 2) 0
2023-07-07 20:05:37 +0200 <lambdabot> error:
2023-07-07 20:05:38 +0200 <lambdabot> Ambiguous occurrence ‘runState’
2023-07-07 20:05:38 +0200 <lambdabot> It could refer to
2023-07-07 20:05:46 +0200 <int-e> ah
2023-07-07 20:05:47 +0200 <int-e> @undef
2023-07-07 20:05:47 +0200 <lambdabot> Undefined.
2023-07-07 20:05:59 +0200 <int-e> @let import qualified Control.Monad.State.Strict as S'
2023-07-07 20:06:00 +0200 <lambdabot> Defined.
2023-07-07 20:06:05 +0200 <int-e> > runState (undefined >> put 2) 0
2023-07-07 20:06:07 +0200 <lambdabot> ((),2)
2023-07-07 20:06:14 +0200 <int-e> > S'.runState (undefined >> S'.put 2) 0
2023-07-07 20:06:15 +0200 <lambdabot> *Exception: Prelude.undefined
2023-07-07 20:06:44 +0200 <EvanR> I really need to upgrade my visual reasoning of evaluating chains of let (a,b) = ...
2023-07-07 20:07:38 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds)
2023-07-07 20:07:40 +0200 <int-e> are you aware of selector thunks?
2023-07-07 20:07:46 +0200 <EvanR> nope
2023-07-07 20:09:59 +0200 <int-e> (They're obscure. Basically, functions like `fst` and `snd` have a special heap representation. The point is, if you have lots of chained let (a,b) = f (...) where f is lazy (like in the state monad), then `a` becomes, effectively, `fst (f (...))` so you could easily end up with thunks of the shape `fst (fst (...),...)`
2023-07-07 20:11:00 +0200 <int-e> When proceeding with lazy evaluation. That's not good. So the garbage collector has code to recognize that case and evaluate those selectors when their argument is a value (not a thunk).
2023-07-07 20:11:04 +0200acarrico(~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) (Quit: Leaving.)
2023-07-07 20:11:27 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2023-07-07 20:11:39 +0200reio(~reio@86-90-81-176.fixed.kpn.net)
2023-07-07 20:11:51 +0200 <int-e> To do that, it has to know when a function is a selector, so selectors like `fst` have a special closure type in the RTS for that purpose.
2023-07-07 20:12:13 +0200justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2023-07-07 20:13:04 +0200 <int-e> And it's somewhat brittle... inlining and let-floating can turn what would be selectors into more complicate closures that are no longer selectors and then the garbage collector can no longer evaluate them on the spot and that can cause space leaks that are really hard to understand :)
2023-07-07 20:13:17 +0200 <int-e> (this is basically how I learned about selector thunks)
2023-07-07 20:15:34 +0200 <EvanR> so a = fst(some thunk) and b = snd(SAME thunk), but at some point the argument may become a value, and even though no one demanding a, it can be simplified
2023-07-07 20:15:47 +0200 <int-e> yep
2023-07-07 20:16:14 +0200 <int-e> and b too
2023-07-07 20:16:46 +0200 <EvanR> and if that is compounded by recursion like in scanl, the gc can repeatedly come in to stop a from building up
2023-07-07 20:17:11 +0200 <EvanR> then what's an update frame? xD
2023-07-07 20:17:30 +0200acarrico(~acarrico@dhcp-68-142-49-163.greenmountainaccess.net)
2023-07-07 20:17:52 +0200 <int-e> That's something on the stack, not on the heap, keeping track of where to put return values of closures.
2023-07-07 20:17:55 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec) (Remote host closed the connection)
2023-07-07 20:18:02 +0200 <int-e> I understand those less well than selector thunks.
2023-07-07 20:18:29 +0200 <hololeap> I'm looking for some in-depth info on how to profile a data structure for unwanted laziness
2023-07-07 20:19:25 +0200captnemo(~captnemo@193.32.127.239) (Quit: WeeChat 3.8)
2023-07-07 20:20:03 +0200 <int-e> But there is an optimization (during GC I think?) that collapses update frames on the stack if there are several for the same thunk (which are, IIRC, easy to detect because they'll always be consecutive update frames).
2023-07-07 20:20:26 +0200 <EvanR> wow the GC is doing a lot
2023-07-07 20:22:06 +0200 <EvanR> why would there be many update frames for the same thunk
2023-07-07 20:22:18 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:b9c2:276d:fb2c:5cec)
2023-07-07 20:23:18 +0200 <geekosaur> "accumulator" for a fold?
2023-07-07 20:24:20 +0200notzmv(~zmv@user/notzmv)
2023-07-07 20:25:15 +0200 <EvanR> well I think my main confusion was coming from the selector thunks anyway, thanks for that
2023-07-07 20:26:48 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-07-07 20:32:44 +0200 <EvanR> > let Just () = Nothing in ()
2023-07-07 20:32:46 +0200 <lambdabot> ()
2023-07-07 20:33:12 +0200 <EvanR> is there a selector thunk which checks the sum type's tag too
2023-07-07 20:33:25 +0200 <int-e> no
2023-07-07 20:33:46 +0200 <EvanR> let Just a = Nothing in something something a something something, now what would a be
2023-07-07 20:34:33 +0200biberu(~biberu@user/biberu) (Read error: Connection reset by peer)
2023-07-07 20:35:14 +0200 <EvanR> whatever it is, defensively evaluating it would be bad right
2023-07-07 20:35:19 +0200 <int-e> (It's not *overly* useful because it would basically only work when you know which constructor the return value will have... I mean we're talking about functions like `fromJust`. In which case, you can and arguably should refactor the code to not produce the constructor in the first place.)
2023-07-07 20:35:46 +0200 <EvanR> yeah but that code does something
2023-07-07 20:36:34 +0200 <int-e> While the chained selectors-on-tuples is actually common when writing loops-as-recursion
2023-07-07 20:36:48 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2023-07-07 20:37:35 +0200 <EvanR> > let Just a = Nothing in [1,2,a,4,5]
2023-07-07 20:37:37 +0200 <lambdabot> [1,2,*Exception: <interactive>:3:5-20: Non-exhaustive patterns in Just a
2023-07-07 20:37:50 +0200 <EvanR> > fromJust Nothing
2023-07-07 20:37:52 +0200 <lambdabot> *Exception: Maybe.fromJust: Nothing
2023-07-07 20:38:11 +0200 <int-e> it's just an ordinary thunk
2023-07-07 20:38:18 +0200biberu(~biberu@user/biberu)
2023-07-07 20:38:24 +0200 <EvanR> containing what, a case
2023-07-07 20:39:05 +0200 <int-e> It's more or less `let a = case Nothing of Just a => a in ...`
2023-07-07 20:39:28 +0200misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds)
2023-07-07 20:39:33 +0200 <EvanR> groovy
2023-07-07 20:40:13 +0200 <EvanR> so selectors are specifically for data types with 1 constructor
2023-07-07 20:40:20 +0200 <int-e> IIRC the Haskell report actually has desugarings for this stuff (pattern matches, including irrefutable ones).
2023-07-07 20:40:53 +0200 <int-e> "irrefutable" being the report's term for what we call "lazy matching"
2023-07-07 20:42:44 +0200 <geekosaur> EvanR, don't forget field selectors
2023-07-07 20:43:10 +0200 <int-e> EvanR: selector thunks, yes.
2023-07-07 20:43:24 +0200 <EvanR> explicit use of field selectors produces a selector thunk too?
2023-07-07 20:43:41 +0200 <int-e> not if there is more than one data constructor
2023-07-07 20:43:48 +0200 <EvanR> got it
2023-07-07 20:44:19 +0200 <int-e> obviously this is a deep implementation detail of ghc
2023-07-07 20:44:48 +0200 <int-e> (though hugs also did thise kind of thing... and probably everybody else too, at least for pairs)
2023-07-07 20:48:48 +0200k``(~user@152.7.255.193)
2023-07-07 20:49:26 +0200 <k``> Is there an easy way to do a reverse dependency search for packages?
2023-07-07 20:49:55 +0200 <ncf> https://packdeps.haskellers.com/reverse
2023-07-07 20:50:06 +0200 <k``> Thanks!
2023-07-07 20:50:11 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-07-07 20:50:45 +0200acidjnk(~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de)
2023-07-07 20:50:51 +0200danse-nr3(~francesco@151.43.173.33) (Ping timeout: 245 seconds)
2023-07-07 20:51:17 +0200 <k``> Now I just need to figure out how much of the API they depend on...
2023-07-07 20:54:47 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2023-07-07 20:55:13 +0200trev(~trev@user/trev) (Quit: trev)
2023-07-07 21:02:03 +0200__monty__(~toonn@user/toonn)
2023-07-07 21:05:48 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-07-07 21:06:38 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 240 seconds)
2023-07-07 21:08:53 +0200falafel(~falafel@2603-7000-a700-8710-770e-b4b3-5186-ab58.res6.spectrum.com)
2023-07-07 21:10:45 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2023-07-07 21:17:46 +0200 <EvanR> > if 4 > 9000; then "over 9000!"; else ""
2023-07-07 21:17:47 +0200 <lambdabot> ""
2023-07-07 21:17:51 +0200 <EvanR> > if 4 > 9000; then "over 9000!"; else "";
2023-07-07 21:17:52 +0200 <lambdabot> <hint>:1:40: error: parse error on input ‘;’
2023-07-07 21:19:48 +0200 <geekosaur> you don't actually need those, do you?
2023-07-07 21:20:02 +0200 <geekosaur> > if 4 > 9000 then "over 9000!" else ""
2023-07-07 21:20:04 +0200 <lambdabot> ""
2023-07-07 21:20:09 +0200 <geekosaur> that's what I thought
2023-07-07 21:20:26 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2023-07-07 21:20:37 +0200 <monochrom> But they are allowed because of DoIfThenElse which is now part of Haskell2010.
2023-07-07 21:20:38 +0200 <mauke> the semicola are optionally allowed in an if-then-else expression to make do-notation slightly less annoying
2023-07-07 21:20:56 +0200 <geekosaur> yeh
2023-07-07 21:21:25 +0200 <EvanR> DoIfThenElse?
2023-07-07 21:21:29 +0200 <mauke> did you know import lists allow trailing commata?
2023-07-07 21:21:55 +0200 <monochrom> In fact, DoIfThenElse is defined to just mean allowing ; so that it is a minimal change to the grammar. :)
2023-07-07 21:21:56 +0200 <geekosaur> EvanR, that alters indentation rules
2023-07-07 21:22:03 +0200 <geekosaur> iirc
2023-07-07 21:22:16 +0200 <monochrom> I have only tried export list trailing commas.
2023-07-07 21:22:36 +0200 <monochrom> Also I will raise the endiar war between "commata" and "commae" >:D
2023-07-07 21:22:36 +0200 <geekosaur> since it's an expression, `then` and `else` should be indented, but iirc `DoAndIfThenElse` relaxes that?
2023-07-07 21:22:48 +0200 <monochrom> raise? rage? wage?
2023-07-07 21:23:20 +0200 <geekosaur> "commoi"
2023-07-07 21:23:48 +0200geekosaurgreekosaur
2023-07-07 21:23:55 +0200 <monochrom> Yes, if you don't indent "then" and "else", then layout processing adds ";". Then DoAndIfThenElse just needs to say ";" is OK.
2023-07-07 21:24:17 +0200 <monochrom> It's an ingenious life hack.
2023-07-07 21:24:21 +0200greekosaurgeekosaur
2023-07-07 21:25:35 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2023-07-07 21:26:26 +0200gurkenglas(~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de) (Ping timeout: 250 seconds)
2023-07-07 21:26:36 +0200mei(~mei@user/mei) (Remote host closed the connection)
2023-07-07 21:28:35 +0200 <EvanR> wow that is sneaky as hell
2023-07-07 21:28:53 +0200 <monochrom> :)
2023-07-07 21:29:10 +0200 <monochrom> My thought when I first saw it.
2023-07-07 21:30:02 +0200 <EvanR> but no 3rd ; is needed?
2023-07-07 21:30:06 +0200 <monochrom> You don't even need to change the layout rules.
2023-07-07 21:30:07 +0200 <EvanR> (or allowed)
2023-07-07 21:30:23 +0200 <monochrom> You can have the 3rd ; in a do-block.
2023-07-07 21:30:54 +0200 <mauke> you don't want the statement after if-then-else to be swallowed by the else part
2023-07-07 21:31:00 +0200 <monochrom> > do if 4 > 9000; then "over 9000!"; else "";
2023-07-07 21:31:01 +0200 <lambdabot> ""
2023-07-07 21:31:20 +0200 <monochrom> Your life is complete. :)
2023-07-07 21:31:32 +0200 <EvanR> and this is a haskell2010 thing
2023-07-07 21:31:36 +0200 <monochrom> Yes.
2023-07-07 21:32:04 +0200dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 250 seconds)
2023-07-07 21:32:07 +0200 <mauke> > do if do 4 > do 9000; then do "over 9000!"; else do "";
2023-07-07 21:32:09 +0200 <lambdabot> ""
2023-07-07 21:32:25 +0200dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-07-07 21:32:39 +0200 <EvanR> > do do do do do "batman!"
2023-07-07 21:32:40 +0200 <monochrom> deep dodo
2023-07-07 21:32:40 +0200 <lambdabot> "batman!"
2023-07-07 21:32:52 +0200 <mauke> I don't know if you can fit any extra semicola in there now
2023-07-07 21:32:58 +0200 <monochrom> batmonad
2023-07-07 21:34:06 +0200 <monochrom> > do if do 4 > do 9000;;;;;; then do "over 9000!";;;;; else do "";;;;;
2023-07-07 21:34:07 +0200 <lambdabot> ""
2023-07-07 21:34:19 +0200 <monochrom> Beethoven Virus but semicolons.
2023-07-07 21:34:25 +0200mei(~mei@user/mei)
2023-07-07 21:35:31 +0200 <mauke> > do;; if do 4;; > do 9000;; then do "over 9000!";; else do;; do "";;
2023-07-07 21:35:32 +0200 <lambdabot> ""
2023-07-07 21:36:53 +0200 <hololeap> so, here you can see the flamegraph output of my command: https://eidetic.codes/hackport.html
2023-07-07 21:37:20 +0200 <hololeap> the actual command is: ./dist-newstyle/build/x86_64-linux/ghc-9.2.8/hackport-0.8.4.0/x/hackport/build/hackport/hackport --bash-completion-index 2 --bash-completion-word hackport --bash-completion-word merge --bash-completion-word Cabal +RTS -I0 -A128M -N -pj -hc -l
2023-07-07 21:38:46 +0200 <hololeap> the main block of relevant code is here: https://github.com/gentoo-haskell/hackport/blob/master/src/Hackport/Completion.hs#L82-L129
2023-07-07 21:39:29 +0200 <hololeap> it seems like that's an excessive amount of GC.GC and IDLE.IDLE, but I don't really know
2023-07-07 21:41:31 +0200 <hololeap> and when I've asked in here before I either get "I don't know" or crickets, but surely there must be some information out there on how to investigate why there is so much garbage being generated
2023-07-07 21:45:03 +0200 <hololeap> in this case, it is reading a Trie from a binary file and running Trie.lookup on it
2023-07-07 21:45:19 +0200 <hololeap> https://github.com/gentoo-haskell/hackport/blob/master/src/Data/Trie.hs
2023-07-07 21:53:17 +0200 <EvanR> a lot of garbage *generated* seems par for the course
2023-07-07 21:53:34 +0200perrierjouet(~perrierjo@modemcable048.127-56-74.mc.videotron.ca)
2023-07-07 21:53:36 +0200 <EvanR> if it's not being collected soon then it's potentially a problem
2023-07-07 21:55:36 +0200Pickchea(~private@user/pickchea)
2023-07-07 21:57:19 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2023-07-07 21:57:28 +0200 <hololeap> is the GC.GC and IDLE.IDLE at the beginning some sort of unavoidable startup for the runtime?
2023-07-07 21:59:13 +0200jrm(~jrm@user/jrm) (Quit: ciao)
2023-07-07 22:00:34 +0200jrm(~jrm@user/jrm)
2023-07-07 22:01:11 +0200 <int-e> hololeap: hmm the idling may be waiting for external commands?
2023-07-07 22:01:20 +0200lainon(~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39)
2023-07-07 22:01:39 +0200 <int-e> you could try +RTS -I0 -RTS to disable the idle GC and see if that reduces the proportion of GC time
2023-07-07 22:02:01 +0200 <int-e> ("-I<sec> Perform full GC after <sec> idle time (default: 0.3, 0 == off)")
2023-07-07 22:02:21 +0200 <hololeap> hm, well it already is running with +RTS -I0
2023-07-07 22:02:39 +0200 <int-e> ah, I missed that.
2023-07-07 22:03:02 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-07-07 22:04:40 +0200 <int-e> hmm, -N, how many cores will that end up using?
2023-07-07 22:06:31 +0200lainon(~textual@2601:7c0:cb00:c0a0:718c:10e2:ff4c:a39) (Quit: Textual IRC Client: www.textualapp.com)
2023-07-07 22:06:35 +0200 <hololeap> 4 in this case, is that going to be a problem? -N is actually set in ghc-options: ... -with-rtsopts=-N
2023-07-07 22:07:33 +0200 <int-e> Well it might explain the idle thing... expecially if the actuaal work load has only one thread
2023-07-07 22:07:54 +0200 <int-e> So trying with -N1 seems to be a worthwhile experiment at least?
2023-07-07 22:08:02 +0200 <hololeap> yeah, I'll try that
2023-07-07 22:08:19 +0200 <int-e> It shouldn't dramatically affect the GC time though which is your real question
2023-07-07 22:08:44 +0200 <int-e> (I think)
2023-07-07 22:08:47 +0200 <EvanR> whoa https://github.com/sdiehl/write-you-a-haskell (not necessarily in 24 hours)
2023-07-07 22:10:17 +0200 <int-e> Hmm, 2+ years, unfinished?
2023-07-07 22:10:29 +0200 <hololeap> so the whole point of this is to add bash completion to the `hackport merge` command, which takes a package/version that exists in the hackage database. the list of package/versions is cached in a trie which is serialized via binary to a file. on subsequent runs, it should deserialize the cache file and run a lookup on the trie.
2023-07-07 22:10:59 +0200 <hololeap> with bash completion, adding a second or two feels really sluggish, so I was trying to squeeze a bit more speed out of it
2023-07-07 22:11:31 +0200 <hololeap> (just some background)
2023-07-07 22:11:32 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 240 seconds)
2023-07-07 22:12:07 +0200 <int-e> hmm, a second or two... did you say how big the serialized data is?
2023-07-07 22:12:25 +0200 <hololeap> I think it's around 150,000 entries?
2023-07-07 22:13:01 +0200 <hololeap> but you can see from that flamegraph thing that quite a bit of time is spent at the beginning before it even enters main
2023-07-07 22:13:33 +0200 <int-e> I don't think you see that
2023-07-07 22:13:51 +0200 <int-e> I think you're seeing *total* times spent in various parts of the program
2023-07-07 22:14:02 +0200 <hololeap> oh, ok
2023-07-07 22:14:08 +0200alternateved(~user@77-254-166-50.dynamic.inetia.pl)
2023-07-07 22:14:09 +0200 <int-e> and GC.GC is first only because it's the biggest chunk
2023-07-07 22:14:53 +0200 <hololeap> I'm also interested in this because the understanding I gain will really help me in the future projects
2023-07-07 22:16:03 +0200 <hololeap> for instance, I was told adding `LANGUAGE Strict` to my Data.Trie is clumsy and may not do what I expect, but I wasn't told what the _proper_ solution there is either
2023-07-07 22:16:14 +0200 <int-e> I guess the generic recipe for reducing GC times without modifying the program is to increase heap size (both -A and -H may be relevant)
2023-07-07 22:17:18 +0200 <davean> hololeap: you can profile allocations. Also including what closures, etc allocates them - have you done such? Also I see comments above about -N, but have you tried disabling parallel GC?
2023-07-07 22:17:22 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: jdvkjb)
2023-07-07 22:17:54 +0200 <hololeap> davean: I'm not sure how to do any of this
2023-07-07 22:18:56 +0200 <hololeap> I see the -pa runtime argument in the chapter on profiling
2023-07-07 22:19:01 +0200acidjnk(~acidjnk@p200300d6e7072f0600a8e9aef9077b5f.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-07-07 22:19:03 +0200 <davean> add "+RTS -?" to your commend to get options (build with profiling enabled, and RTS options enabled)
2023-07-07 22:19:17 +0200 <int-e> why is the top user of runtime somewhere in hackage-security
2023-07-07 22:19:21 +0200 <davean> ps are about time, you want heap, which is h
2023-07-07 22:19:33 +0200 <int-e> (if the flame graph is to be trusted)
2023-07-07 22:20:23 +0200 <davean> int-e: I would expect that if not much was being done in the program at all.
2023-07-07 22:20:49 +0200 <hololeap> int-e: that's a good question and has to do with the way the program was originally structured
2023-07-07 22:21:22 +0200 <int-e> hololeap: the reason I'm asking is really that I'm wondering whether you're blaming the right thing for taking so much time
2023-07-07 22:21:54 +0200 <hololeap> int-e: I would love to know how to find out
2023-07-07 22:22:28 +0200acidjnk(~acidjnk@p200300d6e7072f06a5c472a3c7963a83.dip0.t-ipconnect.de)
2023-07-07 22:22:32 +0200 <hololeap> from the profiling data, rather than start chopping parts off until it goes fast
2023-07-07 22:22:41 +0200 <int-e> (and often, time correlates with allocations, and allocations trigger GCs, so it's all related to the high GC activity)
2023-07-07 22:22:51 +0200 <int-e> (well, potentially related)
2023-07-07 22:23:06 +0200 <davean> Is the GC activity high? Its a flame graph so i can't tell
2023-07-07 22:23:14 +0200 <davean> I'd kill for an actual graph
2023-07-07 22:23:24 +0200 <hololeap> davean: I can provide other files, what do you want
2023-07-07 22:23:25 +0200 <int-e> well the graph suggests 40%+ GC time
2023-07-07 22:23:28 +0200 <jade[m]> davean: pls don't
2023-07-07 22:23:55 +0200 <davean> hololeap: I mean the actual profile file would be great, but I'm not going to spend much time on this ATM
2023-07-07 22:24:28 +0200 <hololeap> davean: the .prof in json or what format?
2023-07-07 22:24:42 +0200 <davean> the .prof in standard format
2023-07-07 22:24:49 +0200 <int-e> tbh I'd like to see the percentages from `+RTS -s` just to support or refute the flame graph
2023-07-07 22:26:00 +0200reio(~reio@86-90-81-176.fixed.kpn.net) (Ping timeout: 246 seconds)
2023-07-07 22:27:59 +0200 <davean> actually I can generate all this myself unless its a quirk of your system - whats the repo, do you have a nix file for it, and what do you want profiled? I might do it between stuff tonight
2023-07-07 22:28:44 +0200 <hololeap> here's the output with +RTS -s: http://sprunge.us/VJ9cxA
2023-07-07 22:28:52 +0200 <hololeap> here's the .prof file: http://sprunge.us/3h8TNy
2023-07-07 22:29:29 +0200 <hololeap> davean, I don't have a nix file, but I'm using master from here: https://github.com/gentoo-haskell/hackport
2023-07-07 22:29:31 +0200 <int-e> so that confirms 40%-50% GC time
2023-07-07 22:29:42 +0200 <geekosaur> if this turns out to be in hackage-security then #hackage will want to hear about it
2023-07-07 22:30:07 +0200 <davean> Its only allocating like 357MiB, how long is this taking?
2023-07-07 22:31:12 +0200 <hololeap> well, +RTS -N1 -qg -RTS seemed to speed it up quite a bit: total time = 1.15 secs
2023-07-07 22:31:30 +0200 <int-e> "227MB copied during GC" is what makes GC expensive
2023-07-07 22:32:01 +0200 <davean> Yah but even that means this is a VERY slow system it is on - how big is the datafile? We can look at how it is parsed.
2023-07-07 22:32:13 +0200 <davean> You don't happen to be using lazy IO by any chance?
2023-07-07 22:32:47 +0200 <hololeap> I'm using encodeFile from Data.Binary
2023-07-07 22:33:00 +0200 <hololeap> encodeFile/decodeFile
2023-07-07 22:34:56 +0200 <hololeap> https://github.com/gentoo-haskell/hackport/blob/master/src/Hackport/Completion.hs#L115-L118
2023-07-07 22:35:45 +0200 <hololeap> I forgot I put this into a compact region as an experiment, which doesn't seem to affect anything
2023-07-07 22:37:01 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-07-07 22:37:06 +0200 <davean> hololeap: and what is the actual command you're running that should be profiled?
2023-07-07 22:37:19 +0200 <hololeap> it's in the .prof file I just pasted
2023-07-07 22:37:25 +0200 <davean> If it isn't too much of a pain to get build I probably can look at it in a few hours.
2023-07-07 22:37:51 +0200 <davean> Ok, are any of the RTS options important?
2023-07-07 22:38:02 +0200 <davean> You have both -N and -N1 for example
2023-07-07 22:38:25 +0200 <EvanR> haskell report section on the context-free grammar doesn't mention whitespace at all. Is the idea that whitespace is dropped in the process of doing the layout algorithm
2023-07-07 22:38:27 +0200 <hololeap> -N is added in the cabal file via --with-rtsopts
2023-07-07 22:38:41 +0200 <hololeap> it was suggested that I turn it off for this
2023-07-07 22:39:13 +0200 <hololeap> I think that optparse-applicative is adding the -I0 -A128M
2023-07-07 22:39:19 +0200 <geekosaur> EvanR, it's typically removed during lexing, as it's either layout or a way to separate tokens
2023-07-07 22:39:20 +0200 <mauke> whitespace is the lexer's problem
2023-07-07 22:39:34 +0200 <darkling> Depends on your lexer rules. :)
2023-07-07 22:39:39 +0200 <mauke> which is why most grammars are useless for finding polyglots
2023-07-07 22:39:45 +0200 <EvanR> ok but the layout algorithm requires knowing all about whitespace to do its thing
2023-07-07 22:39:55 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl)
2023-07-07 22:40:09 +0200 <mauke> I don't think layout cares about whitespace, really
2023-07-07 22:40:15 +0200 <mauke> just columns
2023-07-07 22:40:23 +0200 <geekosaur> right, but you'll note the layout algorithm is in terms of inserting special tokens, which means it happens during lexing for the most part
2023-07-07 22:40:28 +0200fgaz_(1ff9197ed6@2604:bf00:561:2000::11ea)
2023-07-07 22:40:51 +0200 <EvanR> alright
2023-07-07 22:40:52 +0200 <geekosaur> remember the {n} asnd <n> tokens?
2023-07-07 22:41:01 +0200 <int-e> hololeap: Hmm, "trieFile >>= decodeFile >>= compact" ... GHC.Compact.compact is not going to pay off for you I think.
2023-07-07 22:41:24 +0200 <hololeap> int-e: yeah I found that out, but apparently left it in the commit
2023-07-07 22:41:24 +0200 <EvanR> yeah, it says they exist. I guess whitespace turned into {n} and <n> tokens prior to layout
2023-07-07 22:41:32 +0200 <geekosaur> yep
2023-07-07 22:42:51 +0200 <EvanR> though you might want to attach line and column numbers to tokens for reasons?
2023-07-07 22:43:07 +0200 <dolio> EvanR: BTW, you might be interested in the references here: https://github.com/haskell/happy/issues/235
2023-07-07 22:43:10 +0200 <geekosaur> yes, and ghc for example does that
2023-07-07 22:43:27 +0200 <int-e> hololeap: I'm still confused though... shouldn't the whole cabal-install/hackage-security code path be skipped if the cache exists?
2023-07-07 22:44:58 +0200 <hololeap> int-e: yes it should, I haven't gotten to that yet. I was really just trying to understand the GC usage
2023-07-07 22:45:27 +0200 <int-e> hololeap: so, tentatively, I suspect `choice` may not be as lazy as you expect
2023-07-07 22:51:02 +0200 <int-e> > runWriter $ runMaybeT $ asum [lift (tell [1]) >> pure "Ok", lift (tell [2]) >> fail "Nope"]
2023-07-07 22:51:03 +0200 <lambdabot> (Just "Ok",[1])
2023-07-07 22:51:15 +0200 <int-e> This... suggests that it's lazy enough.
2023-07-07 22:51:39 +0200 <int-e> (`choice` is defined as `asum`)
2023-07-07 22:52:15 +0200nick4(~nick@2600:8807:9084:7800:dc97:418d:c7fc:117f) (Ping timeout: 246 seconds)
2023-07-07 22:52:40 +0200gry(quasselcor@botters/gry) (Ping timeout: 250 seconds)
2023-07-07 22:53:16 +0200 <EvanR> the final section of that chapter on syntax is about disambiguating infix expressions by using fixity and precedence. It is explained in terms of a "list of tokens" which are either infixexps from the grammar (which includes operators already), operators, and negative signs
2023-07-07 22:53:17 +0200 <dolio> > runWriter . runMaybeT $ fail "Nope"
2023-07-07 22:53:18 +0200 <lambdabot> (Nothing,())
2023-07-07 22:53:31 +0200 <int-e> hmmmm. what does `optional` do here
2023-07-07 22:53:41 +0200 <EvanR> is the idea to use first get a parse tree however you can, then flatten infixexps into a list, and rearrange them?
2023-07-07 22:54:42 +0200 <dolio> EvanR: I think so. As I recall, fixity is handled as a post-pass, not during parsing.
2023-07-07 22:55:02 +0200 <dolio> Because you have to parse to find fixity declarations.
2023-07-07 22:55:13 +0200 <EvanR> interesting
2023-07-07 22:56:32 +0200 <EvanR> that adds another level to the common expectation for recursive modules to "just work"
2023-07-07 22:57:00 +0200 <EvanR> operators defined in module A used in module B which uses operators defined in module A
2023-07-07 22:57:22 +0200 <int-e> hololeap: maybe `decodeFile` fails? You'd never seen an error from that because `optional` suppresses it
2023-07-07 22:57:40 +0200 <hololeap> that's intentional
2023-07-07 22:58:06 +0200 <int-e> But it would cause you to go down the slow path. 
2023-07-07 22:58:28 +0200 <hololeap> well, the slow path is like 20 seconds, so it's pretty noticable :3
2023-07-07 22:58:31 +0200 <int-e> So in the interest of debugging, a message would be helpful there.
2023-07-07 22:58:35 +0200 <hololeap> fair
2023-07-07 22:59:34 +0200 <hololeap> also, outputting to stderr on tab completion can be pretty annoying
2023-07-07 23:00:12 +0200 <hololeap> but in the interest of debugging, that's fine, or outputting somewhere in /tmp
2023-07-07 23:00:20 +0200 <int-e> that's fair...
2023-07-07 23:00:51 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-07-07 23:01:13 +0200kimiamania6(~681cf57f@user/kimiamania) (Quit: PegeLinux)
2023-07-07 23:01:17 +0200infinity0(~infinity0@pwned.gg) (Remote host closed the connection)
2023-07-07 23:01:24 +0200 <int-e> I just still don't understand why cabal-install/hackage-security show up in the flame graph here, if you're just reading that trie and then traversing it
2023-07-07 23:01:45 +0200kimiamania6(~681cf57f@user/kimiamania)
2023-07-07 23:02:58 +0200cyphase(~cyphase@user/cyphase) (Ping timeout: 260 seconds)
2023-07-07 23:03:11 +0200gurkenglas(~gurkengla@dynamic-046-114-176-237.46.114.pool.telefonica.de)
2023-07-07 23:03:24 +0200infinity0(~infinity0@pwned.gg)
2023-07-07 23:05:45 +0200 <hololeap> int-e, I refactored and there's no more hackage-security when it reads from the cache: https://eidetic.codes/hackport.html
2023-07-07 23:06:15 +0200 <int-e> No more IDLE.IDLE either?
2023-07-07 23:06:34 +0200 <hololeap> yeah I guess not...
2023-07-07 23:08:16 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-07-07 23:09:00 +0200 <int-e> Of course the fact that it attributes anything to mkCompleter is dubious (it's a plain newtype data constructor)
2023-07-07 23:09:03 +0200drdo6(~drdo@bl5-28-156.dsl.telepac.pt)
2023-07-07 23:11:23 +0200drdo(~drdo@bl8-153-185.dsl.telepac.pt) (Ping timeout: 264 seconds)
2023-07-07 23:11:23 +0200drdo6drdo
2023-07-07 23:11:44 +0200pavonia(~user@user/siracusa)
2023-07-07 23:11:51 +0200k``(~user@152.7.255.193) (Ping timeout: 246 seconds)
2023-07-07 23:13:46 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 245 seconds)
2023-07-07 23:14:18 +0200merijn(~merijn@088-129-128-083.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2023-07-07 23:16:35 +0200 <int-e> hololeap: That said I'm prepared to believe that the deserialization is just that slow. A standalone program that just replicates the Trie data type and does the trieFile >>= decodeFile part could confirm.
2023-07-07 23:18:44 +0200 <int-e> Ah, with some care to force the result.
2023-07-07 23:20:15 +0200 <int-e> which, I guess, `compact` would do for you
2023-07-07 23:22:14 +0200 <hololeap> yeah, that sounds like a good idea, and with it isolated I could probably ask a better question in the haskell discourse or reddit
2023-07-07 23:22:50 +0200 <hololeap> in any case, just the suggestions I've received today sped it up quite a bit, so thanks everyone
2023-07-07 23:23:04 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-07-07 23:24:31 +0200 <EvanR> haskell reddit?
2023-07-07 23:25:48 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-07-07 23:25:52 +0200 <EvanR> yep there it is
2023-07-07 23:26:10 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-07-07 23:26:11 +0200 <int-e> is there a haskell lemmy too?
2023-07-07 23:26:43 +0200 <EvanR> so the moderators quit
2023-07-07 23:32:58 +0200 <Hecate> int-e: kbin.social/m/haskell
2023-07-07 23:33:36 +0200 <EvanR> the minus sign, which means subtraction or negation (or comments) depending on who knows what, including whitespace. Seems like a lexical thing but random stackoverflow says it's more convenient to do in the parser, what a mess
2023-07-07 23:34:01 +0200 <int-e> Hecate: ah that looks a bit more lively than https://programming.dev/c/haskell (unavoidably there are several, hmm, let's call it seeds)
2023-07-07 23:35:05 +0200 <EvanR> it's cool that LexicalNegation did something... like make sections always work the way you think. But it's not in the haskell report here
2023-07-07 23:37:11 +0200 <monochrom> If you write "- 5" with spaces between - and 5, it is pretty difficult for lexers, easier for lexer to just output [Minus, Num 5] and let the CFG stage deal with it.
2023-07-07 23:43:01 +0200m21it(~m21it@2800:ac:8012:135a:9aa8:aa:24dc:5f7a)
2023-07-07 23:43:13 +0200 <EvanR> right, if I'm in the chinese room and see Minus then 5, then I could output negative 5. But if I see x then Minus then y, then x subtract y? Or x(negative y)
2023-07-07 23:43:46 +0200 <EvanR> how did haskell's ancestors do it
2023-07-07 23:44:48 +0200 <EvanR> who the heck came up with this notation
2023-07-07 23:45:21 +0200 <dolio> Distinguishing subtraction from negation isn't usually lexing.
2023-07-07 23:45:23 +0200cyphase(~cyphase@user/cyphase)
2023-07-07 23:45:36 +0200caryhartline(~caryhartl@168.182.58.169)
2023-07-07 23:46:09 +0200 <EvanR> it seems to depend on whitespace
2023-07-07 23:46:37 +0200 <m21it> Hello! Does anyone have an idea why 2 expressions here are giving the different results? I was sure they should be equivalent for the case where key is missing, and both should insert the value 321 with the key "WORLD" https://paste.tomsmeding.com/zVIswWjv
2023-07-07 23:49:17 +0200 <dolio> It is with LexicalNegation on, but I think it isn't in the report.
2023-07-07 23:49:18 +0200EvanR(~EvanR@user/evanr) (Remote host closed the connection)
2023-07-07 23:50:23 +0200EvanR(~EvanR@user/evanr)
2023-07-07 23:53:53 +0200michalz(~michalz@185.246.207.203) (Remote host closed the connection)
2023-07-07 23:53:58 +0200ryantrinkle(~ryantrink@89.247.249.243)
2023-07-07 23:57:13 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1)