IRCBrowse

2021/01/15

2021-01-15 00:00:07 +0100 <merijn> Where are you? How much are you paying? How skilled do your require them to be? Are you willing to invest anything in training? the list goes on and on
2021-01-15 00:00:30 +0100poljar(~poljar@93-139-122-127.adsl.net.t-com.hr) (Ping timeout: 272 seconds)
2021-01-15 00:01:31 +0100 <dibblego> all great questions, and the point is that any claim that "it is hard to hire haskell devs" must also be accompanied by "also python devs" and "also java devs", otherwise, it's just a lie thought up in the shower imo
2021-01-15 00:01:46 +0100 <merijn> Hiring is hard period
2021-01-15 00:02:16 +0100 <dibblego> right, so let's just use the appropriate tool to solve the problem, instead of relying on management doing a survey in the shower
2021-01-15 00:02:44 +0100 <Uniaika> the trick is to pick people who are ready to learn
2021-01-15 00:03:01 +0100 <merijn> Uniaika: That requires investing in people, and that's so 20th century ;)
2021-01-15 00:03:02 +0100 <Uniaika> and have a local guru that produces good enough tooling tailored to what you do
2021-01-15 00:03:15 +0100 <Uniaika> merijn: lol, McKinsey recommends firing people instead
2021-01-15 00:03:26 +0100 <merijn> Uniaika: I recommend we all unionise >.>
2021-01-15 00:03:45 +0100gehmehgeh(~ircuser1@gateway/tor-sasl/gehmehgeh) (Quit: Leaving)
2021-01-15 00:04:18 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 00:05:18 +0100 <Uniaika> merijn: I'm already in a union, what about you? :P
2021-01-15 00:05:27 +0100 <Uniaika> oh dear, it's already late
2021-01-15 00:05:31 +0100 <Uniaika> see you tomorrow!
2021-01-15 00:07:15 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 00:09:38 +0100bw2(~bw1@046125250116.public.t-mobile.at) (Quit: leaving)
2021-01-15 00:12:23 +0100vgtw(~vgtw@gateway/tor-sasl/vgtw) (Remote host closed the connection)
2021-01-15 00:12:41 +0100Cale(~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com)
2021-01-15 00:13:29 +0100vst(~vst@2406:3003:2004:2e8a:bd6b:578b:4351:fd57)
2021-01-15 00:13:39 +0100vgtw(~vgtw@gateway/tor-sasl/vgtw)
2021-01-15 00:14:47 +0100knupfer(~Thunderbi@200116b82c627000444868d876d9f74a.dip.versatel-1u1.de) (Ping timeout: 260 seconds)
2021-01-15 00:20:03 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net)
2021-01-15 00:20:20 +0100pavonia(~user@unaffiliated/siracusa)
2021-01-15 00:20:36 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-01-15 00:20:59 +0100ddere(uid110888@gateway/web/irccloud.com/x-nzqxoujubybhmaoy)
2021-01-15 00:22:10 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas)
2021-01-15 00:22:15 +0100Synthetica(uid199651@gateway/web/irccloud.com/x-lowrcjycbkmtdayh) (Quit: Connection closed for inactivity)
2021-01-15 00:23:11 +0100Franciman(~francesco@host-82-48-174-127.retail.telecomitalia.it) (Quit: Leaving)
2021-01-15 00:24:28 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net) (Ping timeout: 256 seconds)
2021-01-15 00:26:02 +0100conal(~conal@212.102.44.134) (Quit: Computer has gone to sleep.)
2021-01-15 00:28:32 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds)
2021-01-15 00:29:08 +0100son0p(~son0p@181.136.122.143) (Quit: Lost terminal)
2021-01-15 00:29:31 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 00:32:23 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 00:32:27 +0100Alleria(~textual@2603-7000-3040-0000-91cc-b7a0-b6bf-1a42.res6.spectrum.com)
2021-01-15 00:32:51 +0100AlleriaGuest67673
2021-01-15 00:33:13 +0100ADG1089(~adg1089@122.163.165.143) (Ping timeout: 264 seconds)
2021-01-15 00:37:18 +0100 <L29Ah> is it me or cabal-install ignores --package-db=clear? https://dpaste.com/2YYAQ8FBF
2021-01-15 00:37:49 +0100knupfer(~Thunderbi@200116b82c627000cc3741fffeae9b6a.dip.versatel-1u1.de)
2021-01-15 00:37:52 +0100knupfer(~Thunderbi@200116b82c627000cc3741fffeae9b6a.dip.versatel-1u1.de) (Client Quit)
2021-01-15 00:38:02 +0100knupfer(~Thunderbi@i5E86B4A3.versanet.de)
2021-01-15 00:39:17 +0100wonko7(~wonko7@2a01:e35:2ffb:7040:9f6f:4e99:c28:c69a) (Ping timeout: 260 seconds)
2021-01-15 00:44:05 +0100Vulfe_(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Remote host closed the connection)
2021-01-15 00:46:37 +0100Tuplanolla(~Tuplanoll@91-159-68-239.elisa-laajakaista.fi) (Quit: Leaving.)
2021-01-15 00:46:44 +0100conal(~conal@89.187.164.95)
2021-01-15 00:49:27 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 00:50:24 +0100Deide(~Deide@217.155.19.23) (Quit: Seeee yaaaa)
2021-01-15 00:51:07 +0100HiRE(~HiRE@104.128.237.40)
2021-01-15 00:51:15 +0100conal(~conal@89.187.164.95) (Client Quit)
2021-01-15 00:51:49 +0100vst(~vst@2406:3003:2004:2e8a:bd6b:578b:4351:fd57) (Remote host closed the connection)
2021-01-15 00:52:15 +0100vst(~vst@2406:3003:2004:2e8a:bd6b:578b:4351:fd57)
2021-01-15 00:53:21 +0100conal(~conal@89.187.164.95)
2021-01-15 00:53:21 +0100conal(~conal@89.187.164.95) (Client Quit)
2021-01-15 00:53:31 +0100LKoen(~LKoen@100.170.9.109.rev.sfr.net)
2021-01-15 00:53:52 +0100conal(~conal@89.187.164.95)
2021-01-15 00:54:03 +0100conal(~conal@89.187.164.95) (Client Quit)
2021-01-15 00:54:13 +0100HiRE_(~HiRE@2602:ffc5:20::1:512e) (Ping timeout: 272 seconds)
2021-01-15 00:59:22 +0100kupi(uid212005@gateway/web/irccloud.com/x-sxbetnzyfydbbjvs) (Quit: Connection closed for inactivity)
2021-01-15 01:00:00 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 01:00:20 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 01:03:11 +0100royal_screwup21(52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed)
2021-01-15 01:03:27 +0100Wuzzy(~Wuzzy@p5790eb14.dip0.t-ipconnect.de) (*.net *.split)
2021-01-15 01:03:27 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (*.net *.split)
2021-01-15 01:03:27 +0100ericholscher(~ericholsc@185.163.110.126) (*.net *.split)
2021-01-15 01:03:27 +0100phasespace(~sar@89-162-33-21.fiber.signal.no) (*.net *.split)
2021-01-15 01:03:27 +0100sm2n_(~sm2n@bras-base-hmtnon1497w-grc-43-64-231-95-247.dsl.bell.ca) (*.net *.split)
2021-01-15 01:03:27 +0100jmchael(~jmchael@87.112.235.234) (*.net *.split)
2021-01-15 01:03:27 +0100cheater(~user@unaffiliated/cheater) (*.net *.split)
2021-01-15 01:03:27 +0100jle`(~mstksg@unaffiliated/mstksg) (*.net *.split)
2021-01-15 01:03:27 +0100proteusguy(~proteusgu@cm-58-10-154-202.revip7.asianet.co.th) (*.net *.split)
2021-01-15 01:03:27 +0100fresheyeball(~isaac@c-71-237-105-37.hsd1.co.comcast.net) (*.net *.split)
2021-01-15 01:03:27 +0100pfurla(~pfurla@ool-182ed2e2.dyn.optonline.net) (*.net *.split)
2021-01-15 01:03:27 +0100p8m(p8m@gateway/vpn/protonvpn/p8m) (*.net *.split)
2021-01-15 01:03:27 +0100plateau(~plateau@51.194.80.91) (*.net *.split)
2021-01-15 01:03:27 +0100juri_(~juri@178.63.35.222) (*.net *.split)
2021-01-15 01:03:27 +0100tv(~tv@unaffiliated/tv) (*.net *.split)
2021-01-15 01:03:27 +0100is_null(~jpic@pdpc/supporter/professional/is-null) (*.net *.split)
2021-01-15 01:03:27 +0100lep-delete(~lep@94.31.81.93) (*.net *.split)
2021-01-15 01:03:27 +0100daGrevis(~daGrevis@unaffiliated/dagrevis) (*.net *.split)
2021-01-15 01:03:27 +0100guest111`(~user@49.5.6.87) (*.net *.split)
2021-01-15 01:03:27 +0100SupaYoshi(~supayoshi@213-10-140-13.fixed.kpn.net) (*.net *.split)
2021-01-15 01:03:27 +0100gentauro(~gentauro@unaffiliated/gentauro) (*.net *.split)
2021-01-15 01:03:27 +0100Ishutin(~Ishutin@92-249-179-46.pool.digikabel.hu) (*.net *.split)
2021-01-15 01:03:27 +0100troydm(~troydm@unaffiliated/troydm) (*.net *.split)
2021-01-15 01:03:27 +0100datajerk(~datajerk@sense.net) (*.net *.split)
2021-01-15 01:03:27 +0100aldum(~vishera@aldum.pw) (*.net *.split)
2021-01-15 01:03:27 +0100sajith(~sajith@fsf/member/nonzen) (*.net *.split)
2021-01-15 01:03:27 +0100quintasan(~quassel@ubuntu/member/quintasan) (*.net *.split)
2021-01-15 01:03:27 +0100RusAlex(~Chel@unaffiliated/rusalex) (*.net *.split)
2021-01-15 01:03:27 +0100dave_uy(~david@108.61.193.26) (*.net *.split)
2021-01-15 01:03:27 +0100thecoffemaker(~thecoffem@unaffiliated/thecoffemaker) (*.net *.split)
2021-01-15 01:03:27 +0100lordyod(~lordyod@c-67-169-144-132.hsd1.ca.comcast.net) (*.net *.split)
2021-01-15 01:03:27 +0100zfnmxt(~zfnmxt@unaffiliated/zfnmxt) (*.net *.split)
2021-01-15 01:03:27 +0100drewolson(~drewolson@64.227.24.16) (*.net *.split)
2021-01-15 01:03:27 +0100so(~so@unaffiliated/so) (*.net *.split)
2021-01-15 01:03:27 +0100orhan89(~orhan89@151.91.188.35.bc.googleusercontent.com) (*.net *.split)
2021-01-15 01:03:27 +0100tureba(~tureba@tureba.org) (*.net *.split)
2021-01-15 01:03:27 +0100nshepperd2(~nshepperd@li364-218.members.linode.com) (*.net *.split)
2021-01-15 01:03:27 +0100duckonomy(~duckonomy@177.ip-144-217-84.net) (*.net *.split)
2021-01-15 01:03:27 +0100todda7(~torstein@ppp-2-84-17-53.home.otenet.gr) (*.net *.split)
2021-01-15 01:03:27 +0100Profpatsch(~Profpatsc@static.88-198-193-255.clients.your-server.de) (*.net *.split)
2021-01-15 01:03:27 +0100sdressel(~sdressel@pwning.de) (*.net *.split)
2021-01-15 01:03:27 +0100fissureman(~quassel@c-73-163-84-25.hsd1.dc.comcast.net) (*.net *.split)
2021-01-15 01:03:27 +0100dan64(~dan64@dannyadam.com) (*.net *.split)
2021-01-15 01:03:27 +0100alx741(~alx741@186.178.110.154) (*.net *.split)
2021-01-15 01:03:27 +0100aidecoe(~aidecoe@unaffiliated/aidecoe) (*.net *.split)
2021-01-15 01:03:27 +0100MidAutumnHotaru(~MidAutumn@unaffiliated/midautumnhotaru) (*.net *.split)
2021-01-15 01:03:27 +0100ep1ctetus(~epictetus@ip184-187-162-163.sb.sd.cox.net) (*.net *.split)
2021-01-15 01:03:27 +0100Rudd0(~Rudd0@185.189.115.103) (*.net *.split)
2021-01-15 01:03:27 +0100carlomagno1(~cararell@148.87.23.10) (*.net *.split)
2021-01-15 01:03:27 +0100hololeap(~hololeap@unaffiliated/hololeap) (*.net *.split)
2021-01-15 01:03:27 +0100Foritus(~buggery@cpc91316-watf11-2-0-cust68.15-2.cable.virginm.net) (*.net *.split)
2021-01-15 01:03:27 +0100rotaerk(~rotaerk@ender.afternet.org) (*.net *.split)
2021-01-15 01:03:27 +0100xerox_(~xerox@unaffiliated/xerox) (*.net *.split)
2021-01-15 01:03:27 +0100jmsx_(~jordan@li1158-85.members.linode.com) (*.net *.split)
2021-01-15 01:03:27 +0100Athas(athas@sigkill.dk) (*.net *.split)
2021-01-15 01:03:27 +0100MrMobius(~MrMobius@208.58.206.154) (*.net *.split)
2021-01-15 01:03:27 +0100tomku(~tomku@unaffiliated/tomku) (*.net *.split)
2021-01-15 01:03:27 +0100phaul(~phaul@ruby/staff/phaul) (*.net *.split)
2021-01-15 01:03:27 +0100pounce(~pounce@ns379743.ip-5-196-70.eu) (*.net *.split)
2021-01-15 01:03:27 +0100andrew_znc(~andrew@andrewyu.org) (*.net *.split)
2021-01-15 01:03:27 +0100RecursiveG(~recursive@li810-210.members.linode.com) (*.net *.split)
2021-01-15 01:03:27 +0100Kaiepi(~Kaiepi@47.54.252.148) (*.net *.split)
2021-01-15 01:03:27 +0100cyphase(~cyphase@unaffiliated/cyphase) (*.net *.split)
2021-01-15 01:03:27 +0100nitrix(~nitrix@haskell/developer/nitrix) (*.net *.split)
2021-01-15 01:03:27 +0100haritz(~hrtz@unaffiliated/haritz) (*.net *.split)
2021-01-15 01:03:27 +0100Mzg(Mzg@s1.ct8.pl) (*.net *.split)
2021-01-15 01:03:27 +0100xwvvvvwx(xwvvvvwx@gateway/vpn/mullvad/xwvvvvwx) (*.net *.split)
2021-01-15 01:03:27 +0100hive-mind(~hivemind@rrcs-67-53-148-69.west.biz.rr.com) (*.net *.split)
2021-01-15 01:03:27 +0100Chobbes(~Chobbes@unaffiliated/chobbes) (*.net *.split)
2021-01-15 01:03:27 +0100amiri(~amiri@cpe-76-91-154-9.socal.res.rr.com) (*.net *.split)
2021-01-15 01:03:27 +0100petersen(~petersen@redhat/juhp) (*.net *.split)
2021-01-15 01:03:27 +0100BIG_JIMMY_D(~jim@108.61.185.76) (*.net *.split)
2021-01-15 01:03:27 +0100cohn(~noone@unaffiliated/cohn) (*.net *.split)
2021-01-15 01:03:27 +0100dlam(~dlam@dlam.me) (*.net *.split)
2021-01-15 01:03:27 +0100seanparsons(~sean@cpc145088-gill21-2-0-cust281.20-1.cable.virginm.net) (*.net *.split)
2021-01-15 01:03:27 +0100incertia(~incertia@d4-50-26-103.nap.wideopenwest.com) (*.net *.split)
2021-01-15 01:03:27 +0100gawen(~gawen@movzbl.root.sx) (*.net *.split)
2021-01-15 01:03:27 +0100rembo10(~rembo10@wally.codeshy.com) (*.net *.split)
2021-01-15 01:03:27 +0100centril(~centril@213-66-146-92-no250.tbcn.telia.com) (*.net *.split)
2021-01-15 01:03:27 +0100texasmynsted(~texasmyns@99.96.221.112) (*.net *.split)
2021-01-15 01:03:27 +0100ps-auxw(~arneb@p548c6e54.dip0.t-ipconnect.de) (*.net *.split)
2021-01-15 01:03:27 +0100nrdmn9(~nrdmn@95.129.53.118) (*.net *.split)
2021-01-15 01:03:27 +0100tasuki(~tasuki@198.211.120.27) (*.net *.split)
2021-01-15 01:03:27 +0100bcmiller(~bm3719@66.42.95.185) (*.net *.split)
2021-01-15 01:03:27 +0100afx237_(~afx237@107.170.10.178) (*.net *.split)
2021-01-15 01:03:27 +0100zyeri(zyeri@tilde.team/users/zyeri) (*.net *.split)
2021-01-15 01:03:27 +0100nek0(~nek0@mail.nek0.eu) (*.net *.split)
2021-01-15 01:03:27 +0100lnx(~irssi@167.71.7.27) (*.net *.split)
2021-01-15 01:03:27 +0100joel135(sid136450@gateway/web/irccloud.com/x-vyyhxnmonposoqmu) (*.net *.split)
2021-01-15 01:03:27 +0100xff0x(~xff0x@2001:1a81:528c:9f00:3c4e:11e3:52e1:1997) (*.net *.split)
2021-01-15 01:03:27 +0100berberman(~berberman@unaffiliated/berberman) (*.net *.split)
2021-01-15 01:03:27 +0100howdoi(uid224@gateway/web/irccloud.com/x-ikuobcyybrkdaaee) (*.net *.split)
2021-01-15 01:03:27 +0100aplainzetakind(~johndoe@captainludd.powered.by.lunarbnc.net) (*.net *.split)
2021-01-15 01:03:27 +0100Alleria_(~AllahuAkb@2603-7000-3040-0000-21c5-c900-9e1d-bf71.res6.spectrum.com) (*.net *.split)
2021-01-15 01:03:27 +0100fiQ2(~fiQ@mirkk.ninja) (*.net *.split)
2021-01-15 01:03:27 +0100yorick(~yorick@oftn/oswg-member/yorick) (*.net *.split)
2021-01-15 01:03:27 +0100echoreply(~echoreply@unaffiliated/echoreply) (*.net *.split)
2021-01-15 01:03:27 +0100kini(~kini@unaffiliated/kini) (*.net *.split)
2021-01-15 01:03:27 +0100tabemann(~travisb@2600:1700:7990:24e0:46fa:9bf1:e3c9:a6a) (*.net *.split)
2021-01-15 01:03:27 +0100whataday(~xxx@2400:8902::f03c:92ff:fe60:98d8) (*.net *.split)
2021-01-15 01:03:27 +0100Orbstheorem(~roosember@hellendaal.orbstheorem.ch) (*.net *.split)
2021-01-15 01:03:27 +0100sphalerite(~sphalerit@NixOS/user/lheckemann) (*.net *.split)
2021-01-15 01:03:27 +0100hsiktas[m](hsiktasmat@gateway/shell/matrix.org/x-ghuclucmencaeidc) (*.net *.split)
2021-01-15 01:03:28 +0100dh(dh@bsd.ee) (*.net *.split)
2021-01-15 01:03:28 +0100recon_-_(~quassel@2602:febc:0:b6::6ca2) (*.net *.split)
2021-01-15 01:03:28 +0100elvishjerricco(sid237756@NixOS/user/ElvishJerricco) (*.net *.split)
2021-01-15 01:03:28 +0100orcus-(~orcus@unaffiliated/orcus) (*.net *.split)
2021-01-15 01:03:28 +0100pierrot(~pi@unaffiliated/pierrot) (*.net *.split)
2021-01-15 01:03:28 +0100dequbed(~dequbed@2001:bc8:3f24:100::1) (*.net *.split)
2021-01-15 01:03:28 +0100gOOgler(uid125351@gateway/web/irccloud.com/x-jdvndeteehxffire) (*.net *.split)
2021-01-15 01:03:28 +0100dwt(~dwt@c-98-200-58-177.hsd1.tx.comcast.net) (*.net *.split)
2021-01-15 01:03:28 +0100noCheese(~nocheese@unaffiliated/nocheese) (*.net *.split)
2021-01-15 01:03:28 +0100bandali(bandali@fsf/emeritus/bandali) (*.net *.split)
2021-01-15 01:03:28 +0100dani-(sid341953@gateway/web/irccloud.com/x-ntpllqrkvsgxojfo) (*.net *.split)
2021-01-15 01:03:28 +0100Kamuela(sid111576@gateway/web/irccloud.com/x-sygmzwyrzcdkakla) (*.net *.split)
2021-01-15 01:03:28 +0100parseval(sid239098@gateway/web/irccloud.com/x-xrspdpklffjsbdan) (*.net *.split)
2021-01-15 01:03:28 +0100liszt(sid336875@gateway/web/irccloud.com/x-vjevhjtgitwwbjkb) (*.net *.split)
2021-01-15 01:03:28 +0100stass(~stas@2a00:13c0:63:7195::beef) (*.net *.split)
2021-01-15 01:03:28 +0100ibloom(sid350277@gateway/web/irccloud.com/x-qvdyimokdwsnoffs) (*.net *.split)
2021-01-15 01:03:28 +0100noan(~noan@2604:a880:400:d0::12fc:5001) (*.net *.split)
2021-01-15 01:03:28 +0100Klumben(Nsaiswatch@gateway/shell/panicbnc/x-fomxhgfovyvqanep) (*.net *.split)
2021-01-15 01:03:28 +0100xacktm(xacktm@gateway/shell/panicbnc/x-jvtlirfmskjbwohd) (*.net *.split)
2021-01-15 01:03:28 +0100JSharp(sid4580@wikia/JSharp) (*.net *.split)
2021-01-15 01:03:28 +0100mankyKitty(sid31287@gateway/web/irccloud.com/x-sisdzlgwpycrovxr) (*.net *.split)
2021-01-15 01:03:28 +0100whez(sid470288@gateway/web/irccloud.com/x-bovdnbstucgyrclj) (*.net *.split)
2021-01-15 01:03:28 +0100adamse(sid72084@gateway/web/irccloud.com/x-ntgmpqkvdscewbqi) (*.net *.split)
2021-01-15 01:03:28 +0100twk-(~thewormki@unaffiliated/twk-) (*.net *.split)
2021-01-15 01:03:28 +0100enemeth79(sid309041@gateway/web/irccloud.com/x-lvirpivflnhgtbsh) (*.net *.split)
2021-01-15 01:03:28 +0100ajmcmiddlin(sid284402@gateway/web/irccloud.com/x-cjcxesxeodrcvgsk) (*.net *.split)
2021-01-15 01:03:28 +0100chessai(sid225296@gateway/web/irccloud.com/x-yhjyupxhhvdvkdtd) (*.net *.split)
2021-01-15 01:03:28 +0100phaazon(~phaazon@2001:41d0:a:fe76::1) (*.net *.split)
2021-01-15 01:03:28 +0100stylewarning(stylewarni@gateway/web/irccloud.com/x-qyrbdxfrgqvtmbve) (*.net *.split)
2021-01-15 01:03:28 +0100pja(~phil@2a02:8010:6098:0:f2de:f1ff:fe2c:3d9) (*.net *.split)
2021-01-15 01:03:28 +0100ephemient(uid407513@gateway/web/irccloud.com/x-niqthzebbrwzruhe) (*.net *.split)
2021-01-15 01:03:28 +0100iphy(sid67735@gateway/web/irccloud.com/x-mauksswncovsmglx) (*.net *.split)
2021-01-15 01:03:28 +0100copypasteque(~copypaste@2001:41d0:8:b325::1) (*.net *.split)
2021-01-15 01:03:28 +0100ProofTechnique(sid79547@gateway/web/irccloud.com/x-svkesokyijyfonih) (*.net *.split)
2021-01-15 01:03:28 +0100runeks(sid21167@gateway/web/irccloud.com/x-ryjozvleeapnxzus) (*.net *.split)
2021-01-15 01:03:28 +0100alexknvl(sid259568@gateway/web/irccloud.com/x-jnvjyffojwxkuwuh) (*.net *.split)
2021-01-15 01:03:28 +0100trevorriles(sid469656@gateway/web/irccloud.com/x-cfgejkqvovtgjbpt) (*.net *.split)
2021-01-15 01:03:28 +0100sveit(~sveit@2001:19f0:ac01:247:5400:ff:fe5c:689f) (*.net *.split)
2021-01-15 01:03:28 +0100newhoggy(sid198874@gateway/web/irccloud.com/x-qhmnnfjnjtcmfiay) (*.net *.split)
2021-01-15 01:03:28 +0100idnar(sid12240@gateway/web/irccloud.com/x-nahgmbtmyvioqrjv) (*.net *.split)
2021-01-15 01:03:28 +0100scav(sid309693@gateway/web/irccloud.com/x-jqpiftkzlvsswiha) (*.net *.split)
2021-01-15 01:03:28 +0100absence(IfjEGObaTi@hildring.pvv.ntnu.no) (*.net *.split)
2021-01-15 01:03:28 +0100entel(uid256215@botters/entel) (*.net *.split)
2021-01-15 01:03:28 +0100angerman(sid209936@gateway/web/irccloud.com/x-mlhkemfvngmbvuol) (*.net *.split)
2021-01-15 01:03:28 +0100alunduil(alunduil@gateway/web/irccloud.com/x-uvppjsitsccsdxlk) (*.net *.split)
2021-01-15 01:03:28 +0100drbrule(sid395654@gateway/web/irccloud.com/x-vjqqnrysmaxqrzkw) (*.net *.split)
2021-01-15 01:03:28 +0100carter(sid14827@gateway/web/irccloud.com/x-ibvrelberchglxhy) (*.net *.split)
2021-01-15 01:03:28 +0100koankeeper(sid216950@gateway/web/irccloud.com/x-hjizfwywoqrskybo) (*.net *.split)
2021-01-15 01:03:28 +0100wildsebastian(sid324688@gateway/web/irccloud.com/x-ectvsfeiiygtpxsd) (*.net *.split)
2021-01-15 01:03:28 +0100edmundnoble(sid229620@gateway/web/irccloud.com/x-ehmqsocqyidpgjbk) (*.net *.split)
2021-01-15 01:03:28 +0100nlofaro(sid258233@gateway/web/irccloud.com/x-euteclalytxdvjpl) (*.net *.split)
2021-01-15 01:03:28 +0100^[(sid43445@ircpuzzles/2015/april-fools/sixth/zgrep) (*.net *.split)
2021-01-15 01:03:28 +0100FMJz____(sid279245@gateway/web/irccloud.com/x-obdwznzoluazipat) (*.net *.split)
2021-01-15 01:03:28 +0100sclv(sid39734@haskell/developer/sclv) (*.net *.split)
2021-01-15 01:03:28 +0100NemesisD(sid24071@gateway/web/irccloud.com/x-djyvkklsuqfzcevy) (*.net *.split)
2021-01-15 01:03:28 +0100rizary(sid220347@gateway/web/irccloud.com/x-kpnwyrewkhnqnyhk) (*.net *.split)
2021-01-15 01:03:28 +0100jetpack_joe(sid146137@gateway/web/irccloud.com/x-vmgmkyseyzxdizaw) (*.net *.split)
2021-01-15 01:03:28 +0100pasukon(sid49097@gateway/web/irccloud.com/x-naqadmmjejtzyxsk) (*.net *.split)
2021-01-15 01:03:28 +0100dexterfoo(dexter@2a01:7e00::f03c:91ff:fe86:59ec) (*.net *.split)
2021-01-15 01:03:28 +0100tomferon[m](tomferonmo@gateway/shell/matrix.org/x-noglbyofnphhclbb) (*.net *.split)
2021-01-15 01:03:28 +0100jamesfielder[m](jamesfield@gateway/shell/matrix.org/x-hodgerwioachkctf) (*.net *.split)
2021-01-15 01:03:28 +0100ViCi(daniel@10PLM.ro) (*.net *.split)
2021-01-15 01:03:28 +0100srid(sridmatrix@gateway/shell/matrix.org/x-kurgtyubfeavcpuk) (*.net *.split)
2021-01-15 01:03:28 +0100siraben(sirabenmat@gateway/shell/matrix.org/x-ompxpchgmuwlofwe) (*.net *.split)
2021-01-15 01:03:28 +0100rab24ack[m](rab24ackma@gateway/shell/matrix.org/x-iypkxumuyyhmektk) (*.net *.split)
2021-01-15 01:03:28 +0100rednaZ[m](r3dnazmatr@gateway/shell/matrix.org/x-psbwjgmwhnbfxpvd) (*.net *.split)
2021-01-15 01:03:28 +0100ThaEwat(thaewraptm@gateway/shell/matrix.org/x-zzghdaahzrfpgpjd) (*.net *.split)
2021-01-15 01:03:28 +0100polux200137(~polux@51.15.169.172) (*.net *.split)
2021-01-15 01:03:28 +0100operand(~operand@is.altijd.moe) (*.net *.split)
2021-01-15 01:03:28 +0100jbetz(sid283648@gateway/web/irccloud.com/x-mtknylhkbpwnovev) (*.net *.split)
2021-01-15 01:03:28 +0100metadave(sid28102@gateway/web/irccloud.com/x-ifeexfgbnrtdfxvo) (*.net *.split)
2021-01-15 01:03:28 +0100bulters(uid408399@gateway/web/irccloud.com/x-wpbfictwjpuyhkie) (*.net *.split)
2021-01-15 01:03:28 +0100bsima(~bsima@simatime.com) (*.net *.split)
2021-01-15 01:03:28 +0100isacl___(uid13263@gateway/web/irccloud.com/x-zatkgdiubqivrbyl) (*.net *.split)
2021-01-15 01:03:28 +0100yushyin(bSs9syBAug@karif.server-speed.net) (*.net *.split)
2021-01-15 01:03:28 +0100fl0_id(~fl0_id@2a01:4f8:171:4de::40:2) (*.net *.split)
2021-01-15 01:03:36 +0100conal(~conal@89.187.164.95)
2021-01-15 01:03:49 +0100tessier(~treed@kernel-panic/copilotco) (Ping timeout: 260 seconds)
2021-01-15 01:04:21 +0100Codaraxis(~Codaraxis@91.193.4.10) (Remote host closed the connection)
2021-01-15 01:04:28 +0100systemfault(sid267009@gateway/web/irccloud.com/x-doohdrkwzcmqbspf) (Ping timeout: 272 seconds)
2021-01-15 01:04:32 +0100Codaraxis(~Codaraxis@91.193.4.10)
2021-01-15 01:04:50 +0100tabemann(~travisb@2600:1700:7990:24e0:9229:ae6e:bc97:9587)
2021-01-15 01:04:59 +0100pounce(~pounce@ns379743.ip-5-196-70.eu)
2021-01-15 01:05:06 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 01:05:21 +0100tessier(~treed@98.171.210.130)
2021-01-15 01:05:21 +0100tessier(~treed@98.171.210.130) (Changing host)
2021-01-15 01:05:21 +0100tessier(~treed@kernel-panic/copilotco)
2021-01-15 01:05:23 +0100RusAlex(~Chel@unaffiliated/rusalex)
2021-01-15 01:05:48 +0100joel135(sid136450@gateway/web/irccloud.com/x-vyyhxnmonposoqmu)
2021-01-15 01:05:48 +0100xff0x(~xff0x@2001:1a81:528c:9f00:3c4e:11e3:52e1:1997)
2021-01-15 01:05:48 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 01:05:48 +0100howdoi(uid224@gateway/web/irccloud.com/x-ikuobcyybrkdaaee)
2021-01-15 01:05:48 +0100aplainzetakind(~johndoe@captainludd.powered.by.lunarbnc.net)
2021-01-15 01:05:48 +0100Alleria_(~AllahuAkb@2603-7000-3040-0000-21c5-c900-9e1d-bf71.res6.spectrum.com)
2021-01-15 01:05:48 +0100fiQ2(~fiQ@mirkk.ninja)
2021-01-15 01:05:48 +0100yorick(~yorick@oftn/oswg-member/yorick)
2021-01-15 01:05:48 +0100echoreply(~echoreply@unaffiliated/echoreply)
2021-01-15 01:05:48 +0100kini(~kini@unaffiliated/kini)
2021-01-15 01:05:48 +0100whataday(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2021-01-15 01:05:48 +0100Orbstheorem(~roosember@hellendaal.orbstheorem.ch)
2021-01-15 01:05:48 +0100sphalerite(~sphalerit@NixOS/user/lheckemann)
2021-01-15 01:05:48 +0100dh(dh@bsd.ee)
2021-01-15 01:05:48 +0100recon_-_(~quassel@2602:febc:0:b6::6ca2)
2021-01-15 01:05:48 +0100elvishjerricco(sid237756@NixOS/user/ElvishJerricco)
2021-01-15 01:05:48 +0100orcus-(~orcus@unaffiliated/orcus)
2021-01-15 01:05:48 +0100pierrot(~pi@unaffiliated/pierrot)
2021-01-15 01:05:48 +0100dequbed(~dequbed@2001:bc8:3f24:100::1)
2021-01-15 01:05:48 +0100gOOgler(uid125351@gateway/web/irccloud.com/x-jdvndeteehxffire)
2021-01-15 01:05:48 +0100dwt(~dwt@c-98-200-58-177.hsd1.tx.comcast.net)
2021-01-15 01:05:48 +0100noCheese(~nocheese@unaffiliated/nocheese)
2021-01-15 01:05:48 +0100bandali(bandali@fsf/emeritus/bandali)
2021-01-15 01:05:48 +0100dani-(sid341953@gateway/web/irccloud.com/x-ntpllqrkvsgxojfo)
2021-01-15 01:05:48 +0100Kamuela(sid111576@gateway/web/irccloud.com/x-sygmzwyrzcdkakla)
2021-01-15 01:05:48 +0100parseval(sid239098@gateway/web/irccloud.com/x-xrspdpklffjsbdan)
2021-01-15 01:05:48 +0100liszt(sid336875@gateway/web/irccloud.com/x-vjevhjtgitwwbjkb)
2021-01-15 01:05:48 +0100stass(~stas@2a00:13c0:63:7195::beef)
2021-01-15 01:05:48 +0100ibloom(sid350277@gateway/web/irccloud.com/x-qvdyimokdwsnoffs)
2021-01-15 01:05:48 +0100noan(~noan@2604:a880:400:d0::12fc:5001)
2021-01-15 01:05:48 +0100Klumben(Nsaiswatch@gateway/shell/panicbnc/x-fomxhgfovyvqanep)
2021-01-15 01:05:48 +0100xacktm(xacktm@gateway/shell/panicbnc/x-jvtlirfmskjbwohd)
2021-01-15 01:05:48 +0100JSharp(sid4580@wikia/JSharp)
2021-01-15 01:05:48 +0100mankyKitty(sid31287@gateway/web/irccloud.com/x-sisdzlgwpycrovxr)
2021-01-15 01:05:48 +0100whez(sid470288@gateway/web/irccloud.com/x-bovdnbstucgyrclj)
2021-01-15 01:05:48 +0100adamse(sid72084@gateway/web/irccloud.com/x-ntgmpqkvdscewbqi)
2021-01-15 01:05:48 +0100twk-(~thewormki@unaffiliated/twk-)
2021-01-15 01:05:48 +0100enemeth79(sid309041@gateway/web/irccloud.com/x-lvirpivflnhgtbsh)
2021-01-15 01:05:48 +0100ajmcmiddlin(sid284402@gateway/web/irccloud.com/x-cjcxesxeodrcvgsk)
2021-01-15 01:05:48 +0100chessai(sid225296@gateway/web/irccloud.com/x-yhjyupxhhvdvkdtd)
2021-01-15 01:05:48 +0100phaazon(~phaazon@2001:41d0:a:fe76::1)
2021-01-15 01:05:48 +0100stylewarning(stylewarni@gateway/web/irccloud.com/x-qyrbdxfrgqvtmbve)
2021-01-15 01:05:48 +0100pja(~phil@2a02:8010:6098:0:f2de:f1ff:fe2c:3d9)
2021-01-15 01:05:48 +0100ephemient(uid407513@gateway/web/irccloud.com/x-niqthzebbrwzruhe)
2021-01-15 01:05:48 +0100iphy(sid67735@gateway/web/irccloud.com/x-mauksswncovsmglx)
2021-01-15 01:05:48 +0100copypasteque(~copypaste@2001:41d0:8:b325::1)
2021-01-15 01:05:48 +0100ProofTechnique(sid79547@gateway/web/irccloud.com/x-svkesokyijyfonih)
2021-01-15 01:05:48 +0100runeks(sid21167@gateway/web/irccloud.com/x-ryjozvleeapnxzus)
2021-01-15 01:05:48 +0100alexknvl(sid259568@gateway/web/irccloud.com/x-jnvjyffojwxkuwuh)
2021-01-15 01:05:48 +0100trevorriles(sid469656@gateway/web/irccloud.com/x-cfgejkqvovtgjbpt)
2021-01-15 01:05:48 +0100sveit(~sveit@2001:19f0:ac01:247:5400:ff:fe5c:689f)
2021-01-15 01:05:48 +0100newhoggy(sid198874@gateway/web/irccloud.com/x-qhmnnfjnjtcmfiay)
2021-01-15 01:05:48 +0100idnar(sid12240@gateway/web/irccloud.com/x-nahgmbtmyvioqrjv)
2021-01-15 01:05:48 +0100scav(sid309693@gateway/web/irccloud.com/x-jqpiftkzlvsswiha)
2021-01-15 01:05:48 +0100absence(IfjEGObaTi@hildring.pvv.ntnu.no)
2021-01-15 01:05:48 +0100entel(uid256215@botters/entel)
2021-01-15 01:05:48 +0100angerman(sid209936@gateway/web/irccloud.com/x-mlhkemfvngmbvuol)
2021-01-15 01:05:48 +0100alunduil(alunduil@gateway/web/irccloud.com/x-uvppjsitsccsdxlk)
2021-01-15 01:05:48 +0100drbrule(sid395654@gateway/web/irccloud.com/x-vjqqnrysmaxqrzkw)
2021-01-15 01:05:48 +0100carter(sid14827@gateway/web/irccloud.com/x-ibvrelberchglxhy)
2021-01-15 01:05:48 +0100koankeeper(sid216950@gateway/web/irccloud.com/x-hjizfwywoqrskybo)
2021-01-15 01:05:48 +0100^[(sid43445@ircpuzzles/2015/april-fools/sixth/zgrep)
2021-01-15 01:05:48 +0100wildsebastian(sid324688@gateway/web/irccloud.com/x-ectvsfeiiygtpxsd)
2021-01-15 01:05:48 +0100nlofaro(sid258233@gateway/web/irccloud.com/x-euteclalytxdvjpl)
2021-01-15 01:05:48 +0100edmundnoble(sid229620@gateway/web/irccloud.com/x-ehmqsocqyidpgjbk)
2021-01-15 01:05:48 +0100sclv(sid39734@haskell/developer/sclv)
2021-01-15 01:05:48 +0100FMJz____(sid279245@gateway/web/irccloud.com/x-obdwznzoluazipat)
2021-01-15 01:05:48 +0100rizary(sid220347@gateway/web/irccloud.com/x-kpnwyrewkhnqnyhk)
2021-01-15 01:05:48 +0100jetpack_joe(sid146137@gateway/web/irccloud.com/x-vmgmkyseyzxdizaw)
2021-01-15 01:05:48 +0100NemesisD(sid24071@gateway/web/irccloud.com/x-djyvkklsuqfzcevy)
2021-01-15 01:05:48 +0100pasukon(sid49097@gateway/web/irccloud.com/x-naqadmmjejtzyxsk)
2021-01-15 01:05:48 +0100dexterfoo(dexter@2a01:7e00::f03c:91ff:fe86:59ec)
2021-01-15 01:05:50 +0100tomferon[m](tomferonmo@gateway/shell/matrix.org/x-noglbyofnphhclbb)
2021-01-15 01:05:50 +0100jamesfielder[m](jamesfield@gateway/shell/matrix.org/x-hodgerwioachkctf)
2021-01-15 01:05:50 +0100ViCi(daniel@10PLM.ro)
2021-01-15 01:05:50 +0100rab24ack[m](rab24ackma@gateway/shell/matrix.org/x-iypkxumuyyhmektk)
2021-01-15 01:05:50 +0100srid(sridmatrix@gateway/shell/matrix.org/x-kurgtyubfeavcpuk)
2021-01-15 01:05:50 +0100siraben(sirabenmat@gateway/shell/matrix.org/x-ompxpchgmuwlofwe)
2021-01-15 01:05:50 +0100rednaZ[m](r3dnazmatr@gateway/shell/matrix.org/x-psbwjgmwhnbfxpvd)
2021-01-15 01:05:50 +0100polux200137(~polux@51.15.169.172)
2021-01-15 01:05:50 +0100operand(~operand@is.altijd.moe)
2021-01-15 01:05:50 +0100jbetz(sid283648@gateway/web/irccloud.com/x-mtknylhkbpwnovev)
2021-01-15 01:05:50 +0100metadave(sid28102@gateway/web/irccloud.com/x-ifeexfgbnrtdfxvo)
2021-01-15 01:05:50 +0100bulters(uid408399@gateway/web/irccloud.com/x-wpbfictwjpuyhkie)
2021-01-15 01:05:50 +0100bsima(~bsima@simatime.com)
2021-01-15 01:05:50 +0100isacl___(uid13263@gateway/web/irccloud.com/x-zatkgdiubqivrbyl)
2021-01-15 01:05:50 +0100yushyin(bSs9syBAug@karif.server-speed.net)
2021-01-15 01:05:50 +0100fl0_id(~fl0_id@2a01:4f8:171:4de::40:2)
2021-01-15 01:06:00 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-01-15 01:06:02 +0100cr3(~cr3@192-222-143-195.qc.cable.ebox.net) (Quit: leaving)
2021-01-15 01:06:40 +0100Wuzzy(~Wuzzy@p5790eb14.dip0.t-ipconnect.de)
2021-01-15 01:06:40 +0100ericholscher(~ericholsc@185.163.110.126)
2021-01-15 01:06:40 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-01-15 01:06:40 +0100alx741(~alx741@186.178.110.154)
2021-01-15 01:06:40 +0100aidecoe(~aidecoe@unaffiliated/aidecoe)
2021-01-15 01:06:40 +0100MidAutumnHotaru(~MidAutumn@unaffiliated/midautumnhotaru)
2021-01-15 01:06:40 +0100ep1ctetus(~epictetus@ip184-187-162-163.sb.sd.cox.net)
2021-01-15 01:06:40 +0100phasespace(~sar@89-162-33-21.fiber.signal.no)
2021-01-15 01:06:40 +0100sm2n_(~sm2n@bras-base-hmtnon1497w-grc-43-64-231-95-247.dsl.bell.ca)
2021-01-15 01:06:40 +0100Rudd0(~Rudd0@185.189.115.103)
2021-01-15 01:06:40 +0100carlomagno1(~cararell@148.87.23.10)
2021-01-15 01:06:40 +0100jmchael(~jmchael@87.112.235.234)
2021-01-15 01:06:40 +0100cheater(~user@unaffiliated/cheater)
2021-01-15 01:06:40 +0100hololeap(~hololeap@unaffiliated/hololeap)
2021-01-15 01:06:40 +0100Foritus(~buggery@cpc91316-watf11-2-0-cust68.15-2.cable.virginm.net)
2021-01-15 01:06:40 +0100jle`(~mstksg@unaffiliated/mstksg)
2021-01-15 01:06:40 +0100rotaerk(~rotaerk@ender.afternet.org)
2021-01-15 01:06:40 +0100proteusguy(~proteusgu@cm-58-10-154-202.revip7.asianet.co.th)
2021-01-15 01:06:40 +0100fresheyeball(~isaac@c-71-237-105-37.hsd1.co.comcast.net)
2021-01-15 01:06:40 +0100pfurla(~pfurla@ool-182ed2e2.dyn.optonline.net)
2021-01-15 01:06:40 +0100xerox_(~xerox@unaffiliated/xerox)
2021-01-15 01:06:40 +0100jmsx_(~jordan@li1158-85.members.linode.com)
2021-01-15 01:06:40 +0100Athas(athas@sigkill.dk)
2021-01-15 01:06:40 +0100MrMobius(~MrMobius@208.58.206.154)
2021-01-15 01:06:40 +0100tomku(~tomku@unaffiliated/tomku)
2021-01-15 01:06:40 +0100phaul(~phaul@ruby/staff/phaul)
2021-01-15 01:06:40 +0100andrew_znc(~andrew@andrewyu.org)
2021-01-15 01:06:40 +0100p8m(p8m@gateway/vpn/protonvpn/p8m)
2021-01-15 01:06:40 +0100plateau(~plateau@51.194.80.91)
2021-01-15 01:06:40 +0100RecursiveG(~recursive@li810-210.members.linode.com)
2021-01-15 01:06:40 +0100Kaiepi(~Kaiepi@47.54.252.148)
2021-01-15 01:06:40 +0100cyphase(~cyphase@unaffiliated/cyphase)
2021-01-15 01:06:40 +0100juri_(~juri@178.63.35.222)
2021-01-15 01:06:40 +0100tv(~tv@unaffiliated/tv)
2021-01-15 01:06:40 +0100is_null(~jpic@pdpc/supporter/professional/is-null)
2021-01-15 01:06:40 +0100nitrix(~nitrix@haskell/developer/nitrix)
2021-01-15 01:06:40 +0100lep-delete(~lep@94.31.81.93)
2021-01-15 01:06:40 +0100daGrevis(~daGrevis@unaffiliated/dagrevis)
2021-01-15 01:06:40 +0100guest111`(~user@49.5.6.87)
2021-01-15 01:06:40 +0100haritz(~hrtz@unaffiliated/haritz)
2021-01-15 01:06:40 +0100SupaYoshi(~supayoshi@213-10-140-13.fixed.kpn.net)
2021-01-15 01:06:40 +0100Mzg(Mzg@s1.ct8.pl)
2021-01-15 01:06:40 +0100xwvvvvwx(xwvvvvwx@gateway/vpn/mullvad/xwvvvvwx)
2021-01-15 01:06:40 +0100hive-mind(~hivemind@rrcs-67-53-148-69.west.biz.rr.com)
2021-01-15 01:06:40 +0100gentauro(~gentauro@unaffiliated/gentauro)
2021-01-15 01:06:40 +0100Chobbes(~Chobbes@unaffiliated/chobbes)
2021-01-15 01:06:40 +0100Profpatsch(~Profpatsc@static.88-198-193-255.clients.your-server.de)
2021-01-15 01:06:40 +0100Ishutin(~Ishutin@92-249-179-46.pool.digikabel.hu)
2021-01-15 01:06:40 +0100amiri(~amiri@cpe-76-91-154-9.socal.res.rr.com)
2021-01-15 01:06:40 +0100dlam(~dlam@dlam.me)
2021-01-15 01:06:40 +0100petersen(~petersen@redhat/juhp)
2021-01-15 01:06:40 +0100BIG_JIMMY_D(~jim@108.61.185.76)
2021-01-15 01:06:40 +0100cohn(~noone@unaffiliated/cohn)
2021-01-15 01:06:40 +0100troydm(~troydm@unaffiliated/troydm)
2021-01-15 01:06:40 +0100seanparsons(~sean@cpc145088-gill21-2-0-cust281.20-1.cable.virginm.net)
2021-01-15 01:06:40 +0100datajerk(~datajerk@sense.net)
2021-01-15 01:06:40 +0100aldum(~vishera@aldum.pw)
2021-01-15 01:06:40 +0100incertia(~incertia@d4-50-26-103.nap.wideopenwest.com)
2021-01-15 01:06:40 +0100gawen(~gawen@movzbl.root.sx)
2021-01-15 01:06:40 +0100sajith(~sajith@fsf/member/nonzen)
2021-01-15 01:06:40 +0100quintasan(~quassel@ubuntu/member/quintasan)
2021-01-15 01:06:40 +0100rembo10(~rembo10@wally.codeshy.com)
2021-01-15 01:06:40 +0100centril(~centril@213-66-146-92-no250.tbcn.telia.com)
2021-01-15 01:06:40 +0100afx237_(~afx237@107.170.10.178)
2021-01-15 01:06:40 +0100dave_uy(~david@108.61.193.26)
2021-01-15 01:06:40 +0100texasmynsted(~texasmyns@99.96.221.112)
2021-01-15 01:06:40 +0100thecoffemaker(~thecoffem@unaffiliated/thecoffemaker)
2021-01-15 01:06:40 +0100lordyod(~lordyod@c-67-169-144-132.hsd1.ca.comcast.net)
2021-01-15 01:06:40 +0100ps-auxw(~arneb@p548c6e54.dip0.t-ipconnect.de)
2021-01-15 01:06:40 +0100zfnmxt(~zfnmxt@unaffiliated/zfnmxt)
2021-01-15 01:06:40 +0100nrdmn9(~nrdmn@95.129.53.118)
2021-01-15 01:06:40 +0100drewolson(~drewolson@64.227.24.16)
2021-01-15 01:06:40 +0100tasuki(~tasuki@198.211.120.27)
2021-01-15 01:06:40 +0100so(~so@unaffiliated/so)
2021-01-15 01:06:40 +0100bcmiller(~bm3719@66.42.95.185)
2021-01-15 01:06:40 +0100orhan89(~orhan89@151.91.188.35.bc.googleusercontent.com)
2021-01-15 01:06:40 +0100tureba(~tureba@tureba.org)
2021-01-15 01:06:40 +0100nshepperd2(~nshepperd@li364-218.members.linode.com)
2021-01-15 01:06:40 +0100duckonomy(~duckonomy@177.ip-144-217-84.net)
2021-01-15 01:06:40 +0100todda7(~torstein@ppp-2-84-17-53.home.otenet.gr)
2021-01-15 01:06:40 +0100zyeri(zyeri@tilde.team/users/zyeri)
2021-01-15 01:06:40 +0100sdressel(~sdressel@pwning.de)
2021-01-15 01:06:40 +0100nek0(~nek0@mail.nek0.eu)
2021-01-15 01:06:40 +0100fissureman(~quassel@c-73-163-84-25.hsd1.dc.comcast.net)
2021-01-15 01:06:40 +0100dan64(~dan64@dannyadam.com)
2021-01-15 01:06:40 +0100lnx(~irssi@167.71.7.27)
2021-01-15 01:06:48 +0100pedrorubster[m](pedrorubst@gateway/shell/matrix.org/x-vlkedizifqmvzfxx) (Ping timeout: 246 seconds)
2021-01-15 01:06:48 +0100VarikValefor[m](varikvalef@gateway/shell/matrix.org/x-vnnpwgfssdqwbqfu) (Ping timeout: 246 seconds)
2021-01-15 01:06:48 +0100sajith[m](sajithmatr@gateway/shell/matrix.org/x-xzxvlmzgkorbwysi) (Ping timeout: 246 seconds)
2021-01-15 01:06:48 +0100shutendoji[m](shutendoji@gateway/shell/matrix.org/x-xkkwzcxdpnysvaec) (Ping timeout: 244 seconds)
2021-01-15 01:06:49 +0100majjoha(majjohamat@gateway/shell/matrix.org/x-jifgtzsbvkjppkpw) (Ping timeout: 244 seconds)
2021-01-15 01:06:49 +0100PotatoHatsue(berbermanp@gateway/shell/matrix.org/x-qvbwsusysmmnlxwa) (Ping timeout: 244 seconds)
2021-01-15 01:06:49 +0100unclechu(unclechuma@gateway/shell/matrix.org/x-hiknotexkoisqxxl) (Ping timeout: 244 seconds)
2021-01-15 01:07:05 +0100jamesfielder[m](jamesfield@gateway/shell/matrix.org/x-hodgerwioachkctf) (Ping timeout: 240 seconds)
2021-01-15 01:07:09 +0100Lurkki[m]1(lurkkipriv@gateway/shell/matrix.org/x-nywvecrjcupkppty) (Ping timeout: 246 seconds)
2021-01-15 01:07:09 +0100doct0rhu[m](doct0rhumo@gateway/shell/matrix.org/x-xqcgpfxdrrdasugy) (Ping timeout: 246 seconds)
2021-01-15 01:07:10 +0100Hatsue[m](berbermanm@gateway/shell/matrix.org/x-uluzliuxxqhqsyle) (Ping timeout: 246 seconds)
2021-01-15 01:07:10 +0100metamod[m](metamodmat@gateway/shell/matrix.org/x-qkyweymrjkgyfpfo) (Ping timeout: 246 seconds)
2021-01-15 01:07:10 +0100psydruid(psydruidma@gateway/shell/matrix.org/x-sjzobmayhhdrnyrp) (Ping timeout: 246 seconds)
2021-01-15 01:07:13 +0100aplainze1akind(~johndoe@captainludd.powered.by.lunarbnc.net)
2021-01-15 01:07:15 +0100falling-edge[m](falling-ed@gateway/shell/matrix.org/x-pckulybifhkfiaod) (Ping timeout: 258 seconds)
2021-01-15 01:07:15 +0100jeffcasavant[m](jeffcasava@gateway/shell/matrix.org/x-jkwgveuwpobvzxsf) (Ping timeout: 258 seconds)
2021-01-15 01:07:19 +0100alvinsj[m](alvinsjmat@gateway/shell/matrix.org/x-aiymaqlzfwokexyh) (Ping timeout: 244 seconds)
2021-01-15 01:07:19 +0100freeman42x[m](freeman42x@gateway/shell/matrix.org/x-tgneiyxcgqrblnuy) (Ping timeout: 244 seconds)
2021-01-15 01:07:20 +0100sm[m](simonmicma@gateway/shell/matrix.org/x-erpehckoekyivhyz) (Ping timeout: 244 seconds)
2021-01-15 01:07:20 +0100lnxw37d4(lnxw37d4ma@gateway/shell/matrix.org/x-zcpsgkhlxjrtufan) (Ping timeout: 244 seconds)
2021-01-15 01:07:20 +0100Ericson2314(ericson231@gateway/shell/matrix.org/x-eycjxzyzybmehehh) (Ping timeout: 244 seconds)
2021-01-15 01:07:21 +0100aplainzetakind(~johndoe@captainludd.powered.by.lunarbnc.net) (Remote host closed the connection)
2021-01-15 01:07:21 +0100howdoi(uid224@gateway/web/irccloud.com/x-ikuobcyybrkdaaee) (Ping timeout: 272 seconds)
2021-01-15 01:07:21 +0100elvishjerricco(sid237756@NixOS/user/ElvishJerricco) (Ping timeout: 272 seconds)
2021-01-15 01:07:21 +0100entel(uid256215@botters/entel) (Ping timeout: 272 seconds)
2021-01-15 01:07:21 +0100rizary(sid220347@gateway/web/irccloud.com/x-kpnwyrewkhnqnyhk) (Ping timeout: 272 seconds)
2021-01-15 01:07:21 +0100jetpack_joe(sid146137@gateway/web/irccloud.com/x-vmgmkyseyzxdizaw) (Ping timeout: 272 seconds)
2021-01-15 01:07:21 +0100aplainze1akindaplainzetakind
2021-01-15 01:07:22 +0100jmsx(~jordan@li1158-85.members.linode.com)
2021-01-15 01:07:25 +0100srid(sridmatrix@gateway/shell/matrix.org/x-kurgtyubfeavcpuk) (Ping timeout: 240 seconds)
2021-01-15 01:07:26 +0100siraben(sirabenmat@gateway/shell/matrix.org/x-ompxpchgmuwlofwe) (Ping timeout: 240 seconds)
2021-01-15 01:07:26 +0100rab24ack[m](rab24ackma@gateway/shell/matrix.org/x-iypkxumuyyhmektk) (Ping timeout: 240 seconds)
2021-01-15 01:07:26 +0100rednaZ[m](r3dnazmatr@gateway/shell/matrix.org/x-psbwjgmwhnbfxpvd) (Ping timeout: 240 seconds)
2021-01-15 01:07:30 +0100maralorn(maralornma@gateway/shell/matrix.org/x-kxmvzacxixldobru) (Ping timeout: 246 seconds)
2021-01-15 01:07:30 +0100MrMuffles[m](mrmufflesm@gateway/shell/matrix.org/x-ocqxcgfxuorbepel) (Ping timeout: 246 seconds)
2021-01-15 01:07:30 +0100dyniec[m](dyniecmatr@gateway/shell/matrix.org/x-dntagevwjtsssopc) (Ping timeout: 246 seconds)
2021-01-15 01:07:30 +0100michaelpj(michaelpjm@gateway/shell/matrix.org/x-ppnwgolzqhsbjxqk) (Ping timeout: 246 seconds)
2021-01-15 01:07:30 +0100Wraul[m](wraulmatri@gateway/shell/matrix.org/x-ocrsiypemiiqameo) (Ping timeout: 246 seconds)
2021-01-15 01:07:30 +0100Lurkki[m](lurkkifene@gateway/shell/matrix.org/x-tqwpdpxocqfxaqic) (Ping timeout: 246 seconds)
2021-01-15 01:07:30 +0100jtojnar(jtojnarmat@gateway/shell/matrix.org/x-bqcuakapvvkhqvyh) (Ping timeout: 246 seconds)
2021-01-15 01:07:31 +0100AmitLevy[m](amitmostly@gateway/shell/matrix.org/x-baxosktqaxjrlryv) (Ping timeout: 272 seconds)
2021-01-15 01:07:35 +0100jmsx_(~jordan@li1158-85.members.linode.com) (Ping timeout: 246 seconds)
2021-01-15 01:07:35 +0100lordyod(~lordyod@c-67-169-144-132.hsd1.ca.comcast.net) (Max SendQ exceeded)
2021-01-15 01:07:37 +0100svc0[m](svc0matrix@gateway/shell/matrix.org/x-cgayodjircveqtkr) (Ping timeout: 268 seconds)
2021-01-15 01:07:37 +0100pythag76[m](pythag76ma@gateway/shell/matrix.org/x-uokvpcmzafuiszqm) (Ping timeout: 260 seconds)
2021-01-15 01:07:37 +0100peterstorm[m](peterstorm@gateway/shell/matrix.org/x-hslfrrbtahiybhio) (Ping timeout: 260 seconds)
2021-01-15 01:07:37 +0100bitonic(bitonicmat@gateway/shell/matrix.org/x-dbuvsguzqiivdtvd) (Ping timeout: 258 seconds)
2021-01-15 01:07:37 +0100cnmne[m](cnmnematri@gateway/shell/matrix.org/x-sjfvuxbdraxbtjzp) (Ping timeout: 268 seconds)
2021-01-15 01:07:37 +0100floatingpoint[m](floating5@gateway/shell/matrix.org/x-cjdgttiluqrdsali) (Ping timeout: 260 seconds)
2021-01-15 01:07:37 +0100jkaye[m](jkayematri@gateway/shell/matrix.org/x-ygixxwauoonufenh) (Ping timeout: 258 seconds)
2021-01-15 01:07:37 +0100Poscat[m](poscatmatr@gateway/shell/matrix.org/x-vcoicgxvllexrrii) (Ping timeout: 268 seconds)
2021-01-15 01:07:37 +0100bsima[m](bensimatim@gateway/shell/matrix.org/x-ktajiadhtjvptkuy) (Ping timeout: 268 seconds)
2021-01-15 01:07:37 +0100fgaz(fgazmatrix@gateway/shell/matrix.org/x-ilhbhnqcmreoygeu) (Ping timeout: 268 seconds)
2021-01-15 01:07:37 +0100boistordu(boistordum@gateway/shell/matrix.org/x-uxzyryrlcsuoeixd) (Ping timeout: 258 seconds)
2021-01-15 01:07:38 +0100psamim(samimpmatr@gateway/shell/matrix.org/x-zcokmttvseaiorus) (Ping timeout: 260 seconds)
2021-01-15 01:07:38 +0100domenkozar[m](domenkozar@NixOS/user/domenkozar) (Ping timeout: 260 seconds)
2021-01-15 01:07:50 +0100Noughtmare[m](naughtmare@gateway/shell/matrix.org/x-elhpevndlmaavbwt) (Ping timeout: 244 seconds)
2021-01-15 01:07:51 +0100berberman[T](berberma4@gateway/shell/matrix.org/x-ydntbnxvrquqngkp) (Ping timeout: 244 seconds)
2021-01-15 01:07:51 +0100lambdaclan(lambdaclan@gateway/shell/matrix.org/x-qnuenoqqycybdvsq) (Ping timeout: 244 seconds)
2021-01-15 01:07:53 +0100sawmon-and-natal(sawmon-and@gateway/shell/matrix.org/x-xtzpbggeyumafmmb) (Ping timeout: 260 seconds)
2021-01-15 01:07:53 +0100joshualit140[m](joshualit1@gateway/shell/matrix.org/x-whhblwmaoulboefx) (Ping timeout: 260 seconds)
2021-01-15 01:07:59 +0100lordyod(~lordyod@c-67-169-144-132.hsd1.ca.comcast.net)
2021-01-15 01:08:00 +0100agentofuser(agentofuse@gateway/shell/matrix.org/x-haotbgmijlnmxwen) (Ping timeout: 258 seconds)
2021-01-15 01:08:00 +0100noIOBeforeBedtim(dissatisfi@gateway/shell/matrix.org/x-pljvxnigkfwhdutt) (Ping timeout: 258 seconds)
2021-01-15 01:08:01 +0100Wuzzy(~Wuzzy@p5790eb14.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
2021-01-15 01:08:09 +0100sigmacool[m](sigmacoolm@gateway/shell/matrix.org/x-fywwkproowrcadql) (Ping timeout: 272 seconds)
2021-01-15 01:08:14 +0100immae(immaematri@gateway/shell/matrix.org/x-sofszfynxwfdycbe) (Ping timeout: 268 seconds)
2021-01-15 01:08:14 +0100jesser[m](jessermatr@gateway/shell/matrix.org/x-ztgnpizlmfjqozxc) (Ping timeout: 268 seconds)
2021-01-15 01:08:14 +0100pqwy[m](pqwymatrix@gateway/shell/matrix.org/x-yrqbzcfvvgvhihqp) (Ping timeout: 268 seconds)
2021-01-15 01:08:14 +0100johnnyboy[m](gifumatrix@gateway/shell/matrix.org/x-ddtyjxliegbymllk) (Ping timeout: 268 seconds)
2021-01-15 01:08:24 +0100tomferon[m](tomferonmo@gateway/shell/matrix.org/x-noglbyofnphhclbb) (Ping timeout: 249 seconds)
2021-01-15 01:08:25 +0100isacl___(uid13263@gateway/web/irccloud.com/x-zatkgdiubqivrbyl) (Ping timeout: 249 seconds)
2021-01-15 01:08:29 +0100ulidtko(~ulidtko@193.111.48.79) (Ping timeout: 260 seconds)
2021-01-15 01:08:51 +0100PotatoGim(sid99505@gateway/web/irccloud.com/x-rzrxvalmasmuxemd) (Ping timeout: 268 seconds)
2021-01-15 01:09:14 +0100Kaeipi(~Kaiepi@47.54.252.148)
2021-01-15 01:09:14 +0100SlackIntegration(slackbotma@gateway/shell/matrix.org/x-fhaqgxbsmcjmdpgv) (Ping timeout: 246 seconds)
2021-01-15 01:09:15 +0100itai33[m](itai33matr@gateway/shell/matrix.org/x-erpojaoftljshoya) (Ping timeout: 246 seconds)
2021-01-15 01:09:15 +0100alexfmpe(alexfmpema@gateway/shell/matrix.org/x-byegcjtdnwjrjstz) (Ping timeout: 246 seconds)
2021-01-15 01:09:15 +0100albethere(sid457088@gateway/web/irccloud.com/x-mnpwzrwlirbhrtwo) (Ping timeout: 246 seconds)
2021-01-15 01:09:16 +0100isacl___(sid13263@gateway/web/irccloud.com/x-bkkmkmnuzgolneku)
2021-01-15 01:09:17 +0100epicte7us(~epictetus@ip184-187-162-163.sb.sd.cox.net)
2021-01-15 01:09:23 +0100kadoban(kadobanmat@gateway/shell/matrix.org/x-tvbkdchltyihqohm) (Ping timeout: 244 seconds)
2021-01-15 01:09:29 +0100kibe(52214e53@cpc104892-live32-2-0-cust594.17-2.cable.virginm.net)
2021-01-15 01:09:36 +0100Hanma[m](hanmamatri@gateway/shell/matrix.org/x-hqagbkflkardbeyb) (Ping timeout: 246 seconds)
2021-01-15 01:09:38 +0100parseval(sid239098@gateway/web/irccloud.com/x-xrspdpklffjsbdan) (Ping timeout: 274 seconds)
2021-01-15 01:09:38 +0100mankyKitty(sid31287@gateway/web/irccloud.com/x-sisdzlgwpycrovxr) (Ping timeout: 274 seconds)
2021-01-15 01:09:38 +0100adamse(sid72084@gateway/web/irccloud.com/x-ntgmpqkvdscewbqi) (Ping timeout: 274 seconds)
2021-01-15 01:09:38 +0100ajmcmiddlin(sid284402@gateway/web/irccloud.com/x-cjcxesxeodrcvgsk) (Ping timeout: 274 seconds)
2021-01-15 01:09:38 +0100chessai(sid225296@gateway/web/irccloud.com/x-yhjyupxhhvdvkdtd) (Ping timeout: 274 seconds)
2021-01-15 01:09:39 +0100ProofTechnique(sid79547@gateway/web/irccloud.com/x-svkesokyijyfonih) (Ping timeout: 274 seconds)
2021-01-15 01:09:39 +0100alexknvl(sid259568@gateway/web/irccloud.com/x-jnvjyffojwxkuwuh) (Ping timeout: 274 seconds)
2021-01-15 01:09:39 +0100newhoggy(sid198874@gateway/web/irccloud.com/x-qhmnnfjnjtcmfiay) (Ping timeout: 274 seconds)
2021-01-15 01:09:39 +0100scav(sid309693@gateway/web/irccloud.com/x-jqpiftkzlvsswiha) (Ping timeout: 274 seconds)
2021-01-15 01:09:39 +0100angerman(sid209936@gateway/web/irccloud.com/x-mlhkemfvngmbvuol) (Ping timeout: 274 seconds)
2021-01-15 01:09:39 +0100FMJz____(sid279245@gateway/web/irccloud.com/x-obdwznzoluazipat) (Ping timeout: 274 seconds)
2021-01-15 01:09:44 +0100bulters(uid408399@gateway/web/irccloud.com/x-wpbfictwjpuyhkie) (Ping timeout: 240 seconds)
2021-01-15 01:09:49 +0100plateau(~plateau@51.194.80.91) (Ping timeout: 254 seconds)
2021-01-15 01:09:49 +0100SupaYoshi(~supayoshi@213-10-140-13.fixed.kpn.net) (Ping timeout: 254 seconds)
2021-01-15 01:09:56 +0100Wuzzy(~Wuzzy@p5790eb14.dip0.t-ipconnect.de)
2021-01-15 01:09:58 +0100alexknvl(sid259568@gateway/web/irccloud.com/x-bsooitzjcuntpber)
2021-01-15 01:10:03 +0100scav(sid309693@gateway/web/irccloud.com/x-jxtbysqgjpxwlabe)
2021-01-15 01:10:04 +0100Kaiepi(~Kaiepi@47.54.252.148) (Write error: Broken pipe)
2021-01-15 01:10:05 +0100plumenator[m](plumenator@gateway/shell/matrix.org/x-lvykfzzrvmqptvzq) (Ping timeout: 268 seconds)
2021-01-15 01:10:05 +0100ep1ctetus(~epictetus@ip184-187-162-163.sb.sd.cox.net) (Remote host closed the connection)
2021-01-15 01:10:05 +0100petersen(~petersen@redhat/juhp) (Remote host closed the connection)
2021-01-15 01:10:10 +0100mankyKitty(sid31287@gateway/web/irccloud.com/x-trleelmrumtoacfc)
2021-01-15 01:10:12 +0100ProofTechnique(sid79547@gateway/web/irccloud.com/x-xkwpvqwpcxzbqliv)
2021-01-15 01:10:14 +0100stylewarning(stylewarni@gateway/web/irccloud.com/x-qyrbdxfrgqvtmbve) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100alunduil(alunduil@gateway/web/irccloud.com/x-uvppjsitsccsdxlk) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100carter(sid14827@gateway/web/irccloud.com/x-ibvrelberchglxhy) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100wildsebastian(sid324688@gateway/web/irccloud.com/x-ectvsfeiiygtpxsd) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100nlofaro(sid258233@gateway/web/irccloud.com/x-euteclalytxdvjpl) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100^[(sid43445@ircpuzzles/2015/april-fools/sixth/zgrep) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100sclv(sid39734@haskell/developer/sclv) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100NemesisD(sid24071@gateway/web/irccloud.com/x-djyvkklsuqfzcevy) (Ping timeout: 264 seconds)
2021-01-15 01:10:14 +0100pasukon(sid49097@gateway/web/irccloud.com/x-naqadmmjejtzyxsk) (Ping timeout: 264 seconds)
2021-01-15 01:10:15 +0100bulters(sid408399@gateway/web/irccloud.com/x-sdqeovzhlllgyfxc)
2021-01-15 01:10:16 +0100parseval(sid239098@gateway/web/irccloud.com/x-dptvijkmopmshrsp)
2021-01-15 01:10:30 +0100ajmcmiddlin(sid284402@gateway/web/irccloud.com/x-szkbydrrgjdkqwdg)
2021-01-15 01:10:32 +0100FMJz____(sid279245@gateway/web/irccloud.com/x-praqwrhcblptjscb)
2021-01-15 01:10:35 +0100SupaYoshi(~supayoshi@213-10-140-13.fixed.kpn.net)
2021-01-15 01:10:36 +0100angerman(sid209936@gateway/web/irccloud.com/x-xtkvrytwrycxizka)
2021-01-15 01:10:41 +0100chessai(sid225296@gateway/web/irccloud.com/x-eojxzrwdmpbxajck)
2021-01-15 01:10:41 +0100newhoggy(sid198874@gateway/web/irccloud.com/x-jdnuyfbxfnsiohki)
2021-01-15 01:10:42 +0100materialfuture[m(materialfu@gateway/shell/matrix.org/x-himioyqaldoiauxa) (Ping timeout: 268 seconds)
2021-01-15 01:10:45 +0100wildsebastian(sid324688@gateway/web/irccloud.com/x-nvmlmfurbdxhppbr)
2021-01-15 01:10:46 +0100PotatoGim(sid99505@gateway/web/irccloud.com/x-nkelvwmwfteegkul)
2021-01-15 01:10:50 +0100liszt(sid336875@gateway/web/irccloud.com/x-vjevhjtgitwwbjkb) (Ping timeout: 264 seconds)
2021-01-15 01:10:50 +0100drbrule(sid395654@gateway/web/irccloud.com/x-vjqqnrysmaxqrzkw) (Ping timeout: 264 seconds)
2021-01-15 01:11:03 +0100sclv(sid39734@haskell/developer/sclv)
2021-01-15 01:11:04 +0100adamse(sid72084@gateway/web/irccloud.com/x-ddpddrljstsxhjtp)
2021-01-15 01:11:09 +0100nlofaro(sid258233@gateway/web/irccloud.com/x-zedxjapmpevpowdw)
2021-01-15 01:11:11 +0100PotatoGim(sid99505@gateway/web/irccloud.com/x-nkelvwmwfteegkul) (Excess Flood)
2021-01-15 01:11:13 +0100alunduil(alunduil@gateway/web/irccloud.com/x-raqtcjrhwuisweda)
2021-01-15 01:11:14 +0100entel(uid256215@botters/entel)
2021-01-15 01:11:20 +0100NemesisD(sid24071@gateway/web/irccloud.com/x-ideplfgvbdrmtjvk)
2021-01-15 01:11:21 +0100Vanilla[m](danielm14@gateway/shell/matrix.org/x-hwrkmoboegngyxlc) (Ping timeout: 246 seconds)
2021-01-15 01:11:24 +0100pasukon(sid49097@gateway/web/irccloud.com/x-rfyegaueofgzvrku)
2021-01-15 01:11:33 +0100carter(sid14827@gateway/web/irccloud.com/x-acshkzobizuejnrw)
2021-01-15 01:11:34 +0100PotatoGim(sid99505@gateway/web/irccloud.com/x-yiylpgitlafelbpb)
2021-01-15 01:11:37 +0100liszt(sid336875@gateway/web/irccloud.com/x-wowcorjcypctgmpg)
2021-01-15 01:11:42 +0100albethere(sid457088@gateway/web/irccloud.com/x-mlojfqddwapqjmhc)
2021-01-15 01:11:49 +0100^[(sid43445@ircpuzzles/2015/april-fools/sixth/zgrep)
2021-01-15 01:11:52 +0100drbrule(sid395654@gateway/web/irccloud.com/x-nywfvliqiepvgwkr)
2021-01-15 01:11:58 +0100jetpack_joe(sid146137@gateway/web/irccloud.com/x-nrokewanbpijouah)
2021-01-15 01:12:41 +0100rizary(sid220347@gateway/web/irccloud.com/x-ebqpgocdyubyodty)
2021-01-15 01:12:42 +0100stylewarning(stylewarni@gateway/web/irccloud.com/x-smhyaldbfgzvkuwe)
2021-01-15 01:12:55 +0100howdoi(uid224@gateway/web/irccloud.com/x-ctamwhdrfdasswkk)
2021-01-15 01:13:45 +0100hiroaki_(~hiroaki@ip4d166c42.dynamic.kabel-deutschland.de)
2021-01-15 01:14:12 +0100elvishjerricco(sid237756@NixOS/user/ElvishJerricco)
2021-01-15 01:14:13 +0100lnx(~irssi@167.71.7.27) (Ping timeout: 246 seconds)
2021-01-15 01:14:21 +0100plateau(~plateau@51.194.80.91)
2021-01-15 01:14:30 +0100dandels(~dandels@unaffiliated/dandels)
2021-01-15 01:15:12 +0100Sonderblade(~helloman@94.191.152.250)
2021-01-15 01:15:14 +0100tessier(~treed@kernel-panic/copilotco) (Ping timeout: 272 seconds)
2021-01-15 01:15:21 +0100systemfault(sid267009@gateway/web/irccloud.com/x-tudigexavdjrhlgn)
2021-01-15 01:17:06 +0100hiroaki(~hiroaki@ip4d16b6b9.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2021-01-15 01:17:35 +0100jameekim1(~jameekim@mx.nodaplife.me) (Ping timeout: 260 seconds)
2021-01-15 01:19:01 +0100Kaeipi(~Kaiepi@47.54.252.148) (Read error: Connection timed out)
2021-01-15 01:19:26 +0100Kaeipi(~Kaiepi@47.54.252.148)
2021-01-15 01:25:42 +0100conal(~conal@89.187.164.95) (Quit: Computer has gone to sleep.)
2021-01-15 01:26:26 +0100conal(~conal@89.187.164.95)
2021-01-15 01:27:02 +0100xff0x(~xff0x@2001:1a81:528c:9f00:3c4e:11e3:52e1:1997) (Ping timeout: 264 seconds)
2021-01-15 01:27:35 +0100xff0x(~xff0x@2001:1a81:528c:9f00:a5d9:337c:1e59:6b2b)
2021-01-15 01:28:02 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds)
2021-01-15 01:28:31 +0100conal(~conal@89.187.164.95) (Client Quit)
2021-01-15 01:28:32 +0100acarrico(~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) (Ping timeout: 272 seconds)
2021-01-15 01:30:16 +0100conal(~conal@89.187.164.95)
2021-01-15 01:30:40 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 01:31:06 +0100jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2021-01-15 01:31:16 +0100banner(~banner@116-255-17-44.ip4.superloop.com)
2021-01-15 01:31:42 +0100dmytrish(~mitra@2a02:8084:a82:d900:f0a2:b911:b958:c991)
2021-01-15 01:32:18 +0100conal(~conal@89.187.164.95) (Remote host closed the connection)
2021-01-15 01:32:26 +0100majjoha(majjohamat@gateway/shell/matrix.org/x-ubqqebrcaaxwnaxx)
2021-01-15 01:32:32 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 01:32:33 +0100 <koz_> Am I missing something here, but I don't see why left distribution is mutually incompatible with left catch: https://hackage.haskell.org/package/semigroupoids-5.3.5/docs/Data-Functor-Alt.html#t:Alt
2021-01-15 01:32:55 +0100borne(~fritjof@200116b86496e00002b34828c30df1e8.dip.versatel-1u1.de) (Ping timeout: 258 seconds)
2021-01-15 01:33:03 +0100 <koz_> And I assume that 'ReaderT r Maybe' behaves the same way as 'Maybe' vis-a-vis Alt?
2021-01-15 01:33:04 +0100doct0rhu[m](doct0rhumo@gateway/shell/matrix.org/x-odftfjmtqtwyxokt)
2021-01-15 01:33:07 +0100jpds(~jpds@gateway/tor-sasl/jpds)
2021-01-15 01:33:16 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas) (Ping timeout: 240 seconds)
2021-01-15 01:33:19 +0100 <koz_> (in terms of satisfying laws)
2021-01-15 01:33:41 +0100conal(~conal@89.187.164.95)
2021-01-15 01:34:27 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 01:35:41 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Remote host closed the connection)
2021-01-15 01:35:55 +0100knupfer(~Thunderbi@i5E86B4A3.versanet.de) (Ping timeout: 240 seconds)
2021-01-15 01:35:58 +0100 <koz_> (OK, having checked, question 2's answer is indeed 'yes')
2021-01-15 01:37:39 +0100hiroaki_(~hiroaki@ip4d166c42.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2021-01-15 01:37:55 +0100ph88(~ph88@2a02:8109:9e00:7e5c:31dc:e698:c1fb:a61d) (Ping timeout: 272 seconds)
2021-01-15 01:38:00 +0100dmytrish(~mitra@2a02:8084:a82:d900:f0a2:b911:b958:c991) (Remote host closed the connection)
2021-01-15 01:38:37 +0100tessier(~treed@kernel-panic/copilotco)
2021-01-15 01:38:37 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 01:39:50 +0100VarikValefor[m](varikvalef@gateway/shell/matrix.org/x-eylmreqwdhhozxey)
2021-01-15 01:39:51 +0100pedrorubster[m](pedrorubst@gateway/shell/matrix.org/x-xmousjrxjbsyclop)
2021-01-15 01:39:53 +0100sajith[m](sajithmatr@gateway/shell/matrix.org/x-eqzgxqmphsvloqjo)
2021-01-15 01:39:53 +0100shutendoji[m](shutendoji@gateway/shell/matrix.org/x-zoldmulhczmedykw)
2021-01-15 01:39:55 +0100Hatsue[m](berbermanm@gateway/shell/matrix.org/x-mlzdnsgtcngfpuwt)
2021-01-15 01:40:24 +0100unclechu(unclechuma@gateway/shell/matrix.org/x-qcqpphiakkjzwsak)
2021-01-15 01:40:35 +0100LKoen(~LKoen@100.170.9.109.rev.sfr.net) (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”)
2021-01-15 01:40:39 +0100PotatoHatsue(berbermanp@gateway/shell/matrix.org/x-cyzehinlocfsvrli)
2021-01-15 01:41:03 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net)
2021-01-15 01:41:31 +0100 <dolio> The only way you can satisfy both is if `(a <$> c) <!> (b <.> c) = a <$> c`, essentially.
2021-01-15 01:42:50 +0100dcoutts_(~duncan@33.14.75.194.dyn.plus.net) (Ping timeout: 256 seconds)
2021-01-15 01:43:05 +0100jamesfielder[m](jamesfield@gateway/shell/matrix.org/x-aggwlzqjynbvqpuj)
2021-01-15 01:43:13 +0100immae(immaematri@gateway/shell/matrix.org/x-xtsuhftrskviqduc)
2021-01-15 01:43:41 +0100noIOBeforeBedtim(dissatisfi@gateway/shell/matrix.org/x-wxmtqlszaquuclla)
2021-01-15 01:43:51 +0100metamod[m](metamodmat@gateway/shell/matrix.org/x-eeteqiiuwhgqhhan)
2021-01-15 01:43:51 +0100fgaz(fgazmatrix@gateway/shell/matrix.org/x-fkqvrdzzwmylyzim)
2021-01-15 01:43:53 +0100Lurkki[m]1(lurkkipriv@gateway/shell/matrix.org/x-bgjxblelcopynrls)
2021-01-15 01:44:58 +0100psydruid(psydruidma@gateway/shell/matrix.org/x-lsgbiiyqrdcofzca)
2021-01-15 01:45:21 +0100bitonic(bitonicmat@gateway/shell/matrix.org/x-mvvtiwcsgwujegzo)
2021-01-15 01:45:21 +0100jeffcasavant[m](jeffcasava@gateway/shell/matrix.org/x-ezaslszscjsugiki)
2021-01-15 01:45:33 +0100jkaye[m](jkayematri@gateway/shell/matrix.org/x-yzgfllsjqvkerepq)
2021-01-15 01:45:37 +0100jameekim1(~jameekim@mx.nodaplife.me)
2021-01-15 01:45:40 +0100joshualit140[m](joshualit1@gateway/shell/matrix.org/x-yxzwvqpdotpectlc)
2021-01-15 01:45:45 +0100sawmon-and-natal(sawmon-and@gateway/shell/matrix.org/x-nyvbfbbnahcoivhx)
2021-01-15 01:45:52 +0100freeman42x[m](freeman42x@gateway/shell/matrix.org/x-qbgiejvcqhrrqkmt)
2021-01-15 01:46:09 +0100dyniec[m](dyniecmatr@gateway/shell/matrix.org/x-kekhkdqeipbmemdk)
2021-01-15 01:46:31 +0100AmitLevy[m](amitmostly@gateway/shell/matrix.org/x-nqntfdhgjhucnvvb)
2021-01-15 01:46:33 +0100sigmacool[m](sigmacoolm@gateway/shell/matrix.org/x-seyfmdqkjjunrcnm)
2021-01-15 01:47:26 +0100falling-edge[m](falling-ed@gateway/shell/matrix.org/x-ofbrzhcmlwbldycc)
2021-01-15 01:47:57 +0100domenkozar[m](domenkozar@NixOS/user/domenkozar)
2021-01-15 01:48:00 +0100rajivr(uid269651@gateway/web/irccloud.com/x-gknvnupcsrvhzqnh)
2021-01-15 01:48:00 +0100pythag76[m](pythag76ma@gateway/shell/matrix.org/x-xavdsfqcujgvcvww)
2021-01-15 01:48:11 +0100floatingpoint[m](floating5@gateway/shell/matrix.org/x-ibjdxwlefaqmbsbe)
2021-01-15 01:49:01 +0100thc202(~thc202@unaffiliated/thc202) (Quit: thc202)
2021-01-15 01:49:48 +0100 <ezzieyguywuf> hm, how do I deal with ambiguous module names? Control.Monad.Extra, https://hoogle.haskell.org/?hoogle=Control.Monad.Extra&scope=set%3Astackage
2021-01-15 01:50:00 +0100 <ezzieyguywuf> it was found in multiple packages: extra-1.7.8 monad-extras-0.6.0
2021-01-15 01:50:21 +0100 <L29Ah> you can hide a package
2021-01-15 01:51:10 +0100xirhtogal(~lagothrix@unaffiliated/lagothrix)
2021-01-15 01:51:10 +0100lagothrix(~lagothrix@unaffiliated/lagothrix) (Killed (wolfe.freenode.net (Nickname regained by services)))
2021-01-15 01:51:10 +0100xirhtogallagothrix
2021-01-15 01:51:24 +0100jeffcasavant[m](jeffcasava@gateway/shell/matrix.org/x-ezaslszscjsugiki) (Ping timeout: 240 seconds)
2021-01-15 01:51:26 +0100bitonic(bitonicmat@gateway/shell/matrix.org/x-mvvtiwcsgwujegzo) (Ping timeout: 240 seconds)
2021-01-15 01:51:26 +0100psydruid(psydruidma@gateway/shell/matrix.org/x-lsgbiiyqrdcofzca) (Ping timeout: 240 seconds)
2021-01-15 01:51:44 +0100jkaye[m](jkayematri@gateway/shell/matrix.org/x-yzgfllsjqvkerepq) (Ping timeout: 240 seconds)
2021-01-15 01:51:45 +0100unclechu(unclechuma@gateway/shell/matrix.org/x-qcqpphiakkjzwsak) (Ping timeout: 240 seconds)
2021-01-15 01:51:45 +0100majjoha(majjohamat@gateway/shell/matrix.org/x-ubqqebrcaaxwnaxx) (Ping timeout: 240 seconds)
2021-01-15 01:51:45 +0100AmitLevy[m](amitmostly@gateway/shell/matrix.org/x-nqntfdhgjhucnvvb) (Ping timeout: 244 seconds)
2021-01-15 01:51:45 +0100immae(immaematri@gateway/shell/matrix.org/x-xtsuhftrskviqduc) (Ping timeout: 244 seconds)
2021-01-15 01:51:53 +0100 <ezzieyguywuf> how?
2021-01-15 01:51:55 +0100falling-edge[m](falling-ed@gateway/shell/matrix.org/x-ofbrzhcmlwbldycc) (Ping timeout: 240 seconds)
2021-01-15 01:51:56 +0100sigmacool[m](sigmacoolm@gateway/shell/matrix.org/x-seyfmdqkjjunrcnm) (Ping timeout: 240 seconds)
2021-01-15 01:51:56 +0100freeman42x[m](freeman42x@gateway/shell/matrix.org/x-qbgiejvcqhrrqkmt) (Ping timeout: 240 seconds)
2021-01-15 01:51:56 +0100pedrorubster[m](pedrorubst@gateway/shell/matrix.org/x-xmousjrxjbsyclop) (Ping timeout: 240 seconds)
2021-01-15 01:51:57 +0100PotatoHatsue(berbermanp@gateway/shell/matrix.org/x-cyzehinlocfsvrli) (Ping timeout: 246 seconds)
2021-01-15 01:52:04 +0100metamod[m](metamodmat@gateway/shell/matrix.org/x-eeteqiiuwhgqhhan) (Ping timeout: 240 seconds)
2021-01-15 01:52:05 +0100sajith[m](sajithmatr@gateway/shell/matrix.org/x-eqzgxqmphsvloqjo) (Ping timeout: 240 seconds)
2021-01-15 01:52:05 +0100sawmon-and-natal(sawmon-and@gateway/shell/matrix.org/x-nyvbfbbnahcoivhx) (Ping timeout: 258 seconds)
2021-01-15 01:52:05 +0100joshualit140[m](joshualit1@gateway/shell/matrix.org/x-yxzwvqpdotpectlc) (Ping timeout: 258 seconds)
2021-01-15 01:52:11 +0100mmmattyx(uid17782@gateway/web/irccloud.com/x-jnccgurzyfdhopjk) (Quit: Connection closed for inactivity)
2021-01-15 01:52:13 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-01-15 01:52:16 +0100Lurkki[m]1(lurkkipriv@gateway/shell/matrix.org/x-bgjxblelcopynrls) (Ping timeout: 244 seconds)
2021-01-15 01:52:16 +0100noIOBeforeBedtim(dissatisfi@gateway/shell/matrix.org/x-wxmtqlszaquuclla) (Ping timeout: 244 seconds)
2021-01-15 01:52:16 +0100shutendoji[m](shutendoji@gateway/shell/matrix.org/x-zoldmulhczmedykw) (Ping timeout: 244 seconds)
2021-01-15 01:52:24 +0100floatingpoint[m](floating5@gateway/shell/matrix.org/x-ibjdxwlefaqmbsbe) (Ping timeout: 240 seconds)
2021-01-15 01:52:25 +0100pythag76[m](pythag76ma@gateway/shell/matrix.org/x-xavdsfqcujgvcvww) (Ping timeout: 240 seconds)
2021-01-15 01:52:26 +0100domenkozar[m](domenkozar@NixOS/user/domenkozar) (Ping timeout: 240 seconds)
2021-01-15 01:52:26 +0100fgaz(fgazmatrix@gateway/shell/matrix.org/x-fkqvrdzzwmylyzim) (Ping timeout: 240 seconds)
2021-01-15 01:52:26 +0100jamesfielder[m](jamesfield@gateway/shell/matrix.org/x-aggwlzqjynbvqpuj) (Ping timeout: 240 seconds)
2021-01-15 01:52:28 +0100dyniec[m](dyniecmatr@gateway/shell/matrix.org/x-kekhkdqeipbmemdk) (Ping timeout: 258 seconds)
2021-01-15 01:52:30 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-01-15 01:52:32 +0100Hatsue[m](berbermanm@gateway/shell/matrix.org/x-mlzdnsgtcngfpuwt) (Ping timeout: 260 seconds)
2021-01-15 01:52:36 +0100 <monochrom> Perhaps you don't need both packages.
2021-01-15 01:52:38 +0100VarikValefor[m](varikvalef@gateway/shell/matrix.org/x-eylmreqwdhhozxey) (Ping timeout: 268 seconds)
2021-01-15 01:52:38 +0100doct0rhu[m](doct0rhumo@gateway/shell/matrix.org/x-odftfjmtqtwyxokt) (Ping timeout: 268 seconds)
2021-01-15 01:53:18 +0100 <ezzieyguywuf> monochrom: you think maybe the two are mutually exclusive?
2021-01-15 01:53:31 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net)
2021-01-15 01:54:33 +0100epicte7us(~epictetus@ip184-187-162-163.sb.sd.cox.net) (Quit: Leaving)
2021-01-15 01:54:42 +0100justsomeguy(~justsomeg@unaffiliated/--/x-3805311) ("WeeChat 2.9")
2021-01-15 01:55:07 +0100jmchael(~jmchael@87.112.235.234) (Remote host closed the connection)
2021-01-15 01:55:08 +0100 <monochrom> No, I think these "extra utilities" libraries are just a lot of one-liners you could have handcoded yourself and you only need maybe 3 out of 100 such one-liners.
2021-01-15 01:57:18 +0100 <ezzieyguywuf> monochrom: makes sense. what about in other cases though? specifically I'm running in to this packaging haskell stuff in gentoo - if two packages depend on different libraries with ambiguous module names...how do you deal with it?
2021-01-15 01:58:00 +0100 <yushyin> ezzieyguywuf: so hardcode the function you need, hide/rename package with mixins: cabal-feature or use ghc's package-qualified imports extension
2021-01-15 01:58:29 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3656:8d15:34a2:c515:f802)
2021-01-15 01:59:03 +0100 <ezzieyguywuf> yushyin: this sounds right, but you threw a lot at me that's new that I don't understand :-P
2021-01-15 01:59:18 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net) (Remote host closed the connection)
2021-01-15 01:59:22 +0100 <ezzieyguywuf> i.e. "mixins", "cabal-feature", and "package-qualified imports extension"
2021-01-15 01:59:33 +0100 <ezzieyguywuf> can you point me to a man-page or some documentation?
2021-01-15 01:59:45 +0100 <yushyin> sure
2021-01-15 01:59:51 +0100 <yushyin> https://cabal.readthedocs.io/en/3.4/cabal-package.html?highlight=mixins#pkg-field-mixins
2021-01-15 01:59:54 +0100nineonine(~nineonine@50.216.62.2)
2021-01-15 01:59:58 +0100 <yushyin> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#package-qualifie…
2021-01-15 02:01:25 +0100dandels(~dandels@unaffiliated/dandels) (Ping timeout: 240 seconds)
2021-01-15 02:02:34 +0100sigmacool[m](sigmacoolm@gateway/shell/matrix.org/x-mdwbqjiwxrqtfkyd)
2021-01-15 02:02:37 +0100 <ezzieyguywuf> yushyin: thanks!
2021-01-15 02:03:22 +0100ph88(~ph88@2a02:8109:9e00:7e5c:31dc:e698:c1fb:a61d)
2021-01-15 02:04:42 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl) (Ping timeout: 256 seconds)
2021-01-15 02:04:59 +0100tromp(~tromp@dhcp-077-249-230-040.chello.nl)
2021-01-15 02:08:26 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-01-15 02:09:04 +0100 <ezzieyguywuf> hm, ok now I can see how either mixins or package-qualified imports would resolve this (or hard-coding the function)
2021-01-15 02:09:55 +0100 <ezzieyguywuf> is this issue that I'm running into gentoo-specific, though, or is it truly something that I should expect 'upstream' i.e. the haskell package to resolve?
2021-01-15 02:10:56 +0100lnx(~irssi@167.71.7.27)
2021-01-15 02:12:49 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-01-15 02:13:23 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-01-15 02:14:58 +0100 <ezzieyguywuf> but really, i guess I'm still not understanding how this conflict occurs - [this](https://github.com/simonmichael/hledger/blob/master/hledger-lib/hledger-lib.cabal#L117) is the line giving me "trouble", but really, everything should be hidden unless it's listed in this cabal file, right? and so since monad-extras isnt't listed, it doesn't seem like there should be a problem
2021-01-15 02:16:02 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) (Ping timeout: 244 seconds)
2021-01-15 02:16:16 +0100sm[m](simonmicma@gateway/shell/matrix.org/x-jwbioiwchujqjxlm)
2021-01-15 02:16:16 +0100 <sm[m]> what conflict, ezzieyguywuf ?
2021-01-15 02:17:58 +0100 <ezzieyguywuf> sm[m]: well, I'm not sure how to duplicate the issue outside of gentoo :-P here's some info https://github.com/gentoo-haskell/gentoo-haskell/commit/ef6a2b2d63b1931f3404e02cd351a1af0cc48969#r…
2021-01-15 02:18:58 +0100 <ezzieyguywuf> sm[m]: but in short - since the `extra` package *and* the `monad-extras` packages each have a `Control.Monad.Extra` module, an "Ambiguous module" error pops up if both are "installed"
2021-01-15 02:19:21 +0100 <ezzieyguywuf> sm[m]: I think we're going to deal with it by removing `monad-extras`, since that looks old and unmaintained and doesn't seem to have any reverse dependencies
2021-01-15 02:19:53 +0100 <ezzieyguywuf> but then I'm left wondering two things: (1) how to deal with it in the future (I think yushyin set me straight on this), but also (2) why the heck is it even an issue if `monad-extras` should be hidden
2021-01-15 02:21:48 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 02:22:44 +0100majjoha(majjohamat@gateway/shell/matrix.org/x-vizrtqswjwjmnnvt)
2021-01-15 02:22:45 +0100plumenator[m](plumenator@gateway/shell/matrix.org/x-xteumsediorkkida)
2021-01-15 02:22:45 +0100shutendoji[m](shutendoji@gateway/shell/matrix.org/x-pcdiwvbldmijnjsr)
2021-01-15 02:22:45 +0100alexfmpe(alexfmpema@gateway/shell/matrix.org/x-nxewwfiqygjuitsm)
2021-01-15 02:22:45 +0100dyniec[m](dyniecmatr@gateway/shell/matrix.org/x-fljvprayxammalyd)
2021-01-15 02:22:45 +0100Ericson2314(ericson231@gateway/shell/matrix.org/x-vjbzspbyybhkijcr)
2021-01-15 02:22:45 +0100alvinsj[m](alvinsjmat@gateway/shell/matrix.org/x-knlqpcazouaxyrms)
2021-01-15 02:22:45 +0100freeman42x[m](freeman42x@gateway/shell/matrix.org/x-tmohfkxwvposgmkk)
2021-01-15 02:22:45 +0100hsiktas[m](hsiktasmat@gateway/shell/matrix.org/x-mpdjbrfpxquezqnj)
2021-01-15 02:22:45 +0100jesser[m](jessermatr@gateway/shell/matrix.org/x-lhghtamdmfcigeuj)
2021-01-15 02:22:45 +0100pythag76[m](pythag76ma@gateway/shell/matrix.org/x-fqwwvbqdmrpyfpme)
2021-01-15 02:22:45 +0100Hatsue[m](berbermanm@gateway/shell/matrix.org/x-jfqtcejyrmidtigo)
2021-01-15 02:22:45 +0100rednaZ[m](r3dnazmatr@gateway/shell/matrix.org/x-kklwlhhtroaldxii)
2021-01-15 02:22:46 +0100johnnyboy[m](gifumatrix@gateway/shell/matrix.org/x-mdpxrkceozqnbnvt)
2021-01-15 02:22:46 +0100jtojnar(jtojnarmat@gateway/shell/matrix.org/x-csnjpailzaiaxbid)
2021-01-15 02:22:46 +0100psamim(samimpmatr@gateway/shell/matrix.org/x-cuwklhplbamkxghk)
2021-01-15 02:22:46 +0100noIOBeforeBedtim(dissatisfi@gateway/shell/matrix.org/x-dpzgelpmgtzaopdc)
2021-01-15 02:22:46 +0100pqwy[m](pqwymatrix@gateway/shell/matrix.org/x-rvesdbtaijactapq)
2021-01-15 02:22:46 +0100immae(immaematri@gateway/shell/matrix.org/x-btvogldsfndylfum)
2021-01-15 02:22:46 +0100cnmne[m](cnmnematri@gateway/shell/matrix.org/x-nzmrelpxjrvshdco)
2021-01-15 02:22:46 +0100unclechu(unclechuma@gateway/shell/matrix.org/x-ihwqdoosusxrclkm)
2021-01-15 02:22:46 +0100bitonic(bitonicmat@gateway/shell/matrix.org/x-metwivhpxaujumkh)
2021-01-15 02:22:47 +0100rab24ack[m](rab24ackma@gateway/shell/matrix.org/x-psfptiosqomyptjf)
2021-01-15 02:22:47 +0100berberman[T](berberma4@gateway/shell/matrix.org/x-ejbwxnmnivsaykpy)
2021-01-15 02:22:47 +0100falling-edge[m](falling-ed@gateway/shell/matrix.org/x-mdagccdrqkzhxoyn)
2021-01-15 02:22:47 +0100lambdaclan(lambdaclan@gateway/shell/matrix.org/x-dfumjpmhgjjrokyl)
2021-01-15 02:22:47 +0100kadoban(kadobanmat@gateway/shell/matrix.org/x-wpraxjggsxhnloks)
2021-01-15 02:22:47 +0100maralorn(maralornma@gateway/shell/matrix.org/x-gbyceipyfdkumcfo)
2021-01-15 02:22:47 +0100siraben(sirabenmat@gateway/shell/matrix.org/x-jucvqrunhvhrwair)
2021-01-15 02:22:47 +0100jkaye[m](jkayematri@gateway/shell/matrix.org/x-cwxloaoopccwhafn)
2021-01-15 02:22:47 +0100Noughtmare[m](naughtmare@gateway/shell/matrix.org/x-lzdlfmtcvofdybcb)
2021-01-15 02:22:47 +0100fgaz(fgazmatrix@gateway/shell/matrix.org/x-hgnuaxnlyjfrynyg)
2021-01-15 02:22:47 +0100lnxw37d4(lnxw37d4ma@gateway/shell/matrix.org/x-pmsnpgdqdgdrtjbn)
2021-01-15 02:22:47 +0100SlackIntegration(slackbotma@gateway/shell/matrix.org/x-xfprwmnaewtujqaw)
2021-01-15 02:22:47 +0100domenkozar[m](domenkozar@NixOS/user/domenkozar)
2021-01-15 02:22:48 +0100PotatoHatsue(berbermanp@gateway/shell/matrix.org/x-rlkpwzqyjculsyrl)
2021-01-15 02:22:48 +0100metamod[m](metamodmat@gateway/shell/matrix.org/x-xfwtkfxwyystdnpb)
2021-01-15 02:22:48 +0100bsima[m](bensimatim@gateway/shell/matrix.org/x-zafytodychrvjxwz)
2021-01-15 02:22:48 +0100ThaEwat(thaewraptm@gateway/shell/matrix.org/x-gqxuozjrrepvlmfp)
2021-01-15 02:22:48 +0100VarikValefor[m](varikvalef@gateway/shell/matrix.org/x-dwnvehwebfmuqknj)
2021-01-15 02:22:48 +0100srid(sridmatrix@gateway/shell/matrix.org/x-ohbftpyekflqutne)
2021-01-15 02:22:48 +0100tomferon[m](tomferonmo@gateway/shell/matrix.org/x-dodjzsgkkcctfhjs)
2021-01-15 02:22:48 +0100sajith[m](sajithmatr@gateway/shell/matrix.org/x-smrjdwfdywihjlbm)
2021-01-15 02:22:48 +0100Poscat[m](poscatmatr@gateway/shell/matrix.org/x-ebjpmkbyptcfrkby)
2021-01-15 02:22:48 +0100Hanma[m](hanmamatri@gateway/shell/matrix.org/x-xibwtazmlorhvlak)
2021-01-15 02:22:48 +0100doct0rhu[m](doct0rhumo@gateway/shell/matrix.org/x-sofiodtjhgbkukgv)
2021-01-15 02:22:48 +0100jeffcasavant[m](jeffcasava@gateway/shell/matrix.org/x-pqdubrrqsciedjkz)
2021-01-15 02:22:48 +0100svc0[m](svc0matrix@gateway/shell/matrix.org/x-fzpzyolkdsgkuasb)
2021-01-15 02:22:48 +0100michaelpj(michaelpjm@gateway/shell/matrix.org/x-cufdgsqqlgsifkfo)
2021-01-15 02:22:48 +0100boistordu(boistordum@gateway/shell/matrix.org/x-suypkumwavpowhpu)
2021-01-15 02:22:49 +0100psydruid(psydruidma@gateway/shell/matrix.org/x-mhamjlslfwlsceyz)
2021-01-15 02:22:50 +0100joshualit140[m](joshualit1@gateway/shell/matrix.org/x-vnlszjxsiqmfmjyh)
2021-01-15 02:22:51 +0100itai33[m](itai33matr@gateway/shell/matrix.org/x-tutmwxwkzcqqbmgy)
2021-01-15 02:22:52 +0100Wraul[m](wraulmatri@gateway/shell/matrix.org/x-oaykxwwyyooccwad)
2021-01-15 02:22:52 +0100Vanilla[m](danielm14@gateway/shell/matrix.org/x-uldilkivfzntlfty)
2021-01-15 02:22:52 +0100floatingpoint[m](floating5@gateway/shell/matrix.org/x-nlbpryfzkzgxjafn)
2021-01-15 02:22:52 +0100AmitLevy[m](amitmostly@gateway/shell/matrix.org/x-csdqoyezivpsmkra)
2021-01-15 02:22:52 +0100Lurkki[m](lurkkipriv@gateway/shell/matrix.org/x-wryvoutmljopirtz)
2021-01-15 02:22:52 +0100pedrorubster[m](pedrorubst@gateway/shell/matrix.org/x-ptgumbiukerdwwrm)
2021-01-15 02:22:53 +0100jamesfielder[m](jamesfield@gateway/shell/matrix.org/x-mbtycevoimthkkti)
2021-01-15 02:22:53 +0100Lurkki[m]1(lurkkifene@gateway/shell/matrix.org/x-yyxkihhpivitadru)
2021-01-15 02:22:54 +0100MrMuffles[m](mrmufflesm@gateway/shell/matrix.org/x-vcwutvcdeerrzxfc)
2021-01-15 02:22:54 +0100sawmon-and-natal(sawmon-and@gateway/shell/matrix.org/x-bllgaqfjammxmfum)
2021-01-15 02:22:54 +0100materialfuture[m(materialfu@gateway/shell/matrix.org/x-aqhixpzgkhbmmtgo)
2021-01-15 02:22:55 +0100peterstorm[m](peterstorm@gateway/shell/matrix.org/x-agdwdndygjfbxasv)
2021-01-15 02:22:55 +0100agentofuser(agentofuse@gateway/shell/matrix.org/x-xdrgvktasdrdhynq)
2021-01-15 02:23:04 +0100columbarius1(~columbari@i5E86B385.versanet.de) (Ping timeout: 256 seconds)
2021-01-15 02:24:17 +0100nineonine(~nineonine@50.216.62.2) (Ping timeout: 258 seconds)
2021-01-15 02:24:19 +0100 <sm[m]> ezzieyguywuf: that sounds easiest indeed.
2021-01-15 02:24:47 +0100 <sm[m]> I'm not sure if not listing a dep in the cabal file actually hides it, if it's installed. ghc-pkg has hide and expose commands for some reason. I did successfully build hledger-lib just now after also installing monad-extras, but that's with stack
2021-01-15 02:24:53 +0100columbarius1(~columbari@i5E86B3FB.versanet.de)
2021-01-15 02:25:38 +0100 <sm[m]> packaging is quite a rabbit hole isn't it
2021-01-15 02:25:47 +0100 <ezzieyguywuf> I tried duplicating the issue with just cabal-install, but `cabal-install monad-extras` doesn't seem to do anything.
2021-01-15 02:25:55 +0100 <ezzieyguywuf> sm[m]: also, the issue pops up when compiling the tests.
2021-01-15 02:26:07 +0100 <ezzieyguywuf> sm[m]: hah, yea quite the rabit hole indeed. but fun :)
2021-01-15 02:27:02 +0100 <ephemient> first time digging into Gentoo's Haskell packaging, but https://github.com/gentoo-haskell/gentoo-haskell/blob/master/eclass/haskell-cabal.eclass looks like it uses `./setup build`, not `cabal build`
2021-01-15 02:27:36 +0100 <sm[m]> ah well cabal is complicated. Also it's not cabal-install :)
2021-01-15 02:28:22 +0100 <sm[m]> gentoo sounds like it's somewhere between homebrew and nix
2021-01-15 02:28:30 +0100 <ezzieyguywuf> ephemient: yes we use ./setup build
2021-01-15 02:28:49 +0100 <ezzieyguywuf> sm[m]: hah, I meant `cabal install...`
2021-01-15 02:29:14 +0100 <ezzieyguywuf> I've tried to get into the habit of specifying cabal-install when I'm talking about the *executable* versus the library, mostly for my own sanity
2021-01-15 02:29:43 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 02:29:50 +0100 <sm[m]> I've given up on that. And it's fine
2021-01-15 02:30:04 +0100 <ephemient> is the package isolation stuff in cabal-install or cabal-lib?
2021-01-15 02:34:28 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 02:36:53 +0100loli(~loli@024-171-017-003.res.spectrum.com) (Quit: WeeChat 3.0)
2021-01-15 02:37:38 +0100 <ephemient> yeah I don't understand Cabal very well but I don't think https://github.com/haskell/cabal/blob/master/Cabal/src/Distribution/Simple/Build.hs has any sandboxing, only https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/CmdBuild.hs
2021-01-15 02:37:54 +0100mouseghost(~draco@wikipedia/desperek) (Quit: mew wew)
2021-01-15 02:38:22 +0100 <ephemient> why doesn't gentoo use cabal-install?
2021-01-15 02:38:29 +0100 <ezzieyguywuf> ephemient: I dunno about sandboxing, but doesn't ghc-pkg by default hide anything that isn't explictly listed in the cabal file?
2021-01-15 02:38:43 +0100 <ezzieyguywuf> well, now I'm showing my ignorance, I dunno who does what in this scenareo...
2021-01-15 02:38:44 +0100loli(~loli@024-171-017-003.res.spectrum.com)
2021-01-15 02:39:26 +0100 <ezzieyguywuf> ephemient: I asked, and received what appeared to be a reasonable response. I forget all the specifics, but part of it had to do with the larger dependency footprint of cabal-install versus just cabal-lib
2021-01-15 02:39:47 +0100 <ezzieyguywuf> i could try to dig up the answer in my irc logs...
2021-01-15 02:42:40 +0100Jd007(~Jd007@162.156.11.151) (Quit: Jd007)
2021-01-15 02:44:22 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 02:46:50 +0100 <ephemient> it's not ghc-pkg that does it, it's how cabal invokes ghc that has that effect
2021-01-15 02:47:08 +0100banner(~banner@116-255-17-44.ip4.superloop.com) (Quit: Leaving)
2021-01-15 02:49:04 +0100haritz(~hrtz@unaffiliated/haritz) (Ping timeout: 246 seconds)
2021-01-15 02:49:15 +0100 <ezzieyguywuf> hrm, I think we do invoke ghc with the appropriate flag. let me check.
2021-01-15 02:49:16 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-01-15 02:50:00 +0100kibe(52214e53@cpc104892-live32-2-0-cust594.17-2.cable.virginm.net) (Quit: Connection closed)
2021-01-15 02:50:20 +0100kibe(52214e53@cpc104892-live32-2-0-cust594.17-2.cable.virginm.net)
2021-01-15 02:51:22 +0100 <ezzieyguywuf> hrm, maybe we don't...
2021-01-15 02:51:36 +0100 <ezzieyguywuf> I guess --hide-all-packages is the appropriate ghc option?
2021-01-15 02:53:22 +0100 <ephemient> running `build --verbose=3` here, I see it invoke `/usr/bin/ghc --make -fbuilding-cabal-package ... -hide-all-packages ... -no-user-package-db -package-db dist/package.conf.inplace -package-id base-4.14.1.0 ...`
2021-01-15 02:53:45 +0100 <ephemient> so at least one of those options, probably
2021-01-15 02:54:31 +0100haritz(~hrtz@62.3.70.206)
2021-01-15 02:54:31 +0100haritz(~hrtz@62.3.70.206) (Changing host)
2021-01-15 02:54:31 +0100haritz(~hrtz@unaffiliated/haritz)
2021-01-15 02:54:44 +0100Guest67673(~textual@2603-7000-3040-0000-91cc-b7a0-b6bf-1a42.res6.spectrum.com) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 02:55:56 +0100Wuzzy(~Wuzzy@p5790eb14.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2021-01-15 02:56:21 +0100kibe(52214e53@cpc104892-live32-2-0-cust594.17-2.cable.virginm.net) (Quit: Connection closed)
2021-01-15 02:58:43 +0100acidjnk_new(~acidjnk@p200300d0c704e7817426bb844d6a6b27.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2021-01-15 02:59:49 +0100 <ezzieyguywuf> ephemient: thanks for your help, this gives me enough info to have some conversations with the gentoo folks
2021-01-15 03:00:30 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 03:00:40 +0100conal(~conal@89.187.164.95) (Quit: Computer has gone to sleep.)
2021-01-15 03:01:22 +0100brisbin(~patrick@pool-173-49-158-4.phlapa.fios.verizon.net) (Ping timeout: 256 seconds)
2021-01-15 03:02:18 +0100conal(~conal@89.187.164.95)
2021-01-15 03:02:31 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 03:05:03 +0100Wuzzy(~Wuzzy@p549c9d1f.dip0.t-ipconnect.de)
2021-01-15 03:07:44 +0100bitmapper(uid464869@gateway/web/irccloud.com/x-vuttdldiuuoxfimh)
2021-01-15 03:07:45 +0100tropico(~tropico@unaffiliated/tropico)
2021-01-15 03:09:28 +0100vappend(~ezrakilty@75-172-99-84.tukw.qwest.net)
2021-01-15 03:13:07 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3656:8d15:34a2:c515:f802) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 03:16:08 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3656:64d3:d9bb:432e:acbc)
2021-01-15 03:17:33 +0100nineonine(~nineonine@50.216.62.2)
2021-01-15 03:20:10 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Remote host closed the connection)
2021-01-15 03:20:14 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 03:25:04 +0100acidjnk_new(~acidjnk@p200300d0c704e79940e641953fd44719.dip0.t-ipconnect.de)
2021-01-15 03:25:39 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 03:26:18 +0100darjeeling_(~darjeelin@122.245.120.137) (Ping timeout: 256 seconds)
2021-01-15 03:31:55 +0100xff0x(~xff0x@2001:1a81:528c:9f00:a5d9:337c:1e59:6b2b) (Ping timeout: 240 seconds)
2021-01-15 03:33:35 +0100acidjnk_new(~acidjnk@p200300d0c704e79940e641953fd44719.dip0.t-ipconnect.de) (Remote host closed the connection)
2021-01-15 03:33:51 +0100xff0x(~xff0x@2001:1a81:52c6:7f00:29e8:57ce:ba2b:1f46)
2021-01-15 03:34:02 +0100acidjnk_new(~acidjnk@p200300d0c704e79940e641953fd44719.dip0.t-ipconnect.de)
2021-01-15 03:35:21 +0100conal(~conal@89.187.164.95) (Quit: Computer has gone to sleep.)
2021-01-15 03:40:07 +0100ericsagnes(~ericsagne@2405:6580:0:5100:a508:836d:e92e:17f2) (Ping timeout: 260 seconds)
2021-01-15 03:44:40 +0100ADG1089(~adg1089@122.163.165.143)
2021-01-15 03:44:59 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net)
2021-01-15 03:46:24 +0100darjeeling_(~darjeelin@122.245.120.137)
2021-01-15 03:46:25 +0100ADG1089(~adg1089@122.163.165.143) (Read error: Connection reset by peer)
2021-01-15 03:48:14 +0100fresheyeball(~isaac@c-71-237-105-37.hsd1.co.comcast.net) (Quit: WeeChat 2.9)
2021-01-15 03:51:56 +0100Wuzzy(~Wuzzy@p549c9d1f.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2021-01-15 03:52:21 +0100vappend(~ezrakilty@75-172-99-84.tukw.qwest.net) (Remote host closed the connection)
2021-01-15 03:52:40 +0100ericsagnes(~ericsagne@2405:6580:0:5100:6bc2:e498:a980:d2bd)
2021-01-15 03:54:16 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2021-01-15 03:59:30 +0100ADG1089(~adg1089@122.163.165.143)
2021-01-15 03:59:46 +0100maerwald(~maerwald@mail.hasufell.de)
2021-01-15 04:05:55 +0100conal(~conal@89.187.164.95)
2021-01-15 04:10:24 +0100drbean(~drbean@TC210-63-209-154.static.apol.com.tw)
2021-01-15 04:11:22 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 04:14:06 +0100acidjnk_new(~acidjnk@p200300d0c704e79940e641953fd44719.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2021-01-15 04:15:54 +0100Jd007(~Jd007@162.156.11.151)
2021-01-15 04:16:18 +0100threestrikes(~threestri@cpe-24-243-229-2.hot.res.rr.com)
2021-01-15 04:16:25 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net) (Ping timeout: 264 seconds)
2021-01-15 04:18:17 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net) (Remote host closed the connection)
2021-01-15 04:22:25 +0100nineonine(~nineonine@50.216.62.2) (Ping timeout: 264 seconds)
2021-01-15 04:22:34 +0100livvy(~livvy@gateway/tor-sasl/livvy) (Remote host closed the connection)
2021-01-15 04:23:54 +0100livvy(~livvy@gateway/tor-sasl/livvy)
2021-01-15 04:24:43 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 04:26:33 +0100_xor(~xor@74.215.46.133) (Quit: brb)
2021-01-15 04:28:16 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-01-15 04:30:11 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds)
2021-01-15 04:30:23 +0100urodna(~urodna@unaffiliated/urodna) (Quit: urodna)
2021-01-15 04:33:11 +0100conal(~conal@89.187.164.95) (Quit: Computer has gone to sleep.)
2021-01-15 04:36:05 +0100plutoniix(~q@184.82.197.202)
2021-01-15 04:37:16 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr)
2021-01-15 04:39:10 +0100ADG1089_(~adg1089@171.76.134.49)
2021-01-15 04:41:36 +0100ADG1089(~adg1089@122.163.165.143) (Ping timeout: 240 seconds)
2021-01-15 04:41:37 +0100ADG1089_(~adg1089@171.76.134.49) (Read error: Connection reset by peer)
2021-01-15 04:41:44 +0100ADG1089_(~adg1089@183.83.47.213)
2021-01-15 04:42:16 +0100theDon(~td@muedsl-82-207-238-218.citykom.de) (Ping timeout: 265 seconds)
2021-01-15 04:44:03 +0100theDon(~td@muedsl-82-207-238-172.citykom.de)
2021-01-15 04:47:46 +0100ADG1089_(~adg1089@183.83.47.213) (Read error: Connection reset by peer)
2021-01-15 04:54:45 +0100threestrikes(~threestri@cpe-24-243-229-2.hot.res.rr.com) (Ping timeout: 240 seconds)
2021-01-15 04:55:42 +0100xirhtogal(~lagothrix@unaffiliated/lagothrix)
2021-01-15 04:55:42 +0100lagothrix(~lagothrix@unaffiliated/lagothrix) (Killed (verne.freenode.net (Nickname regained by services)))
2021-01-15 04:55:42 +0100xirhtogallagothrix
2021-01-15 04:55:50 +0100ericholscher(~ericholsc@185.163.110.126) (Remote host closed the connection)
2021-01-15 05:00:04 +0100Alleria(~textual@2603-7000-3040-0000-91cc-b7a0-b6bf-1a42.res6.spectrum.com)
2021-01-15 05:00:14 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 05:00:28 +0100AlleriaGuest11631
2021-01-15 05:00:58 +0100ADG1089_(~adg1089@171.76.134.49)
2021-01-15 05:05:35 +0100tabemann(~travisb@2600:1700:7990:24e0:9229:ae6e:bc97:9587) (Remote host closed the connection)
2021-01-15 05:05:49 +0100tabemann(~travisb@2600:1700:7990:24e0:9229:ae6e:bc97:9587)
2021-01-15 05:06:25 +0100plateau(~plateau@51.194.80.91) (Ping timeout: 240 seconds)
2021-01-15 05:07:43 +0100forell(~forell@unaffiliated/forell) (Quit: ZNC - https://znc.in)
2021-01-15 05:08:13 +0100Stanley00(~stanley00@unaffiliated/stanley00)
2021-01-15 05:08:32 +0100forell(~forell@unaffiliated/forell)
2021-01-15 05:16:27 +0100_xor(~xor@74.215.46.133)
2021-01-15 05:16:41 +0100 <hololeap> ugh, why does cabal place upper-bounds on dependency versions by default?
2021-01-15 05:17:04 +0100 <hololeap> i understand why in theory, but 99% of the time nothing bad happens if you remove them
2021-01-15 05:20:29 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-01-15 05:21:19 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net)
2021-01-15 05:23:41 +0100plutoniix(~q@184.82.197.202) (Ping timeout: 256 seconds)
2021-01-15 05:25:07 +0100 <hololeap> i'm also making packages for gentoo, and i don't know how many times i've had to remove those upper bounds because a dependency got bumped and whatever is depending on it hasn't updated their cabal file
2021-01-15 05:26:12 +0100superstar64(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net)
2021-01-15 05:27:35 +0100Tario(~Tario@201.192.165.173)
2021-01-15 05:27:40 +0100 <superstar64> are there any non bottom values for this type? `data Not a = Not ( a => Void )`
2021-01-15 05:29:27 +0100 <hololeap> i don't see how there could be. are there any non bottom values for Void?
2021-01-15 05:29:30 +0100 <ephemient> is `a => Void` any different from `Void`?
2021-01-15 05:30:02 +0100 <ephemient> also `Not ⟂` is not quite the same as `⟂`
2021-01-15 05:30:11 +0100 <superstar64> well for if `data Not a = Not (a -> Void)`, `Not id` is valid
2021-01-15 05:30:26 +0100 <superstar64> i'm just wondering if there's a typeclass equivalent
2021-01-15 05:30:50 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 05:33:03 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 05:34:05 +0100 <superstar64> actually, maybe there aren't it would allow you to call this function:
2021-01-15 05:34:05 +0100 <superstar64> `f :: a => Not a -> Void`
2021-01-15 05:34:06 +0100 <superstar64> `f (Not x) = x`
2021-01-15 05:34:16 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds)
2021-01-15 05:35:46 +0100Distance_(~Distance@51.194.80.91)
2021-01-15 05:36:33 +0100plutoniix(~q@ppp-223-24-191-164.revip6.asianet.co.th)
2021-01-15 05:36:50 +0100 <hololeap> superstar64: are you trying to make a constraint that's the inversion of the constraint a?
2021-01-15 05:37:10 +0100 <superstar64> i'm not really trying to do anything
2021-01-15 05:37:42 +0100 <hololeap> fair enough, i was just checking
2021-01-15 05:37:58 +0100 <superstar64> oh also, are zero parameter typeclasses useful in anyway?
2021-01-15 05:39:35 +0100mtae(uid179115@gateway/web/irccloud.com/x-zvlrypoijsiqdave) (Quit: Connection closed for inactivity)
2021-01-15 05:39:57 +0100Saukk(~Saukk@83-148-239-3.dynamic.lounea.fi)
2021-01-15 05:40:24 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Remote host closed the connection)
2021-01-15 05:40:55 +0100pcmanus1(~pcmanus@184.75.223.203)
2021-01-15 05:40:56 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net) (Ping timeout: 240 seconds)
2021-01-15 05:43:55 +0100 <superstar64> they kinda remind me of C's forward declarations https://pastebin.com/raw/3V06qF24
2021-01-15 05:48:17 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr)
2021-01-15 05:49:28 +0100Wuzzy(~Wuzzy@p5b0df7fc.dip0.t-ipconnect.de)
2021-01-15 05:50:15 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 05:53:10 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 246 seconds)
2021-01-15 05:54:22 +0100mirrorbird_(~psutcliff@2a00:801:446:b70b:607:9995:9930:4d27) (Quit: Leaving)
2021-01-15 05:55:14 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 05:59:15 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-01-15 06:01:00 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 06:03:23 +0100 <superstar64> i can't find any resources on zero parameter typeclasses. are they actually useless or just unexplored?
2021-01-15 06:04:06 +0100 <superstar64> in theory, you don't need global bindings if you have zero parameter typeclasses right?
2021-01-15 06:05:12 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar) (Remote host closed the connection)
2021-01-15 06:05:23 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 260 seconds)
2021-01-15 06:05:39 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 06:07:20 +0100iridescent(2fe3e53b@047-227-229-059.res.spectrum.com)
2021-01-15 06:07:58 +0100 <Axman6> :kind HasCallStack
2021-01-15 06:08:20 +0100 <Axman6> % :kind HasCallStack
2021-01-15 06:08:20 +0100 <yahb> Axman6: ; <interactive>:1:1: error: Not in scope: type constructor or class `HasCallStack'
2021-01-15 06:08:28 +0100 <Axman6> % :kind HasCallstack
2021-01-15 06:08:28 +0100 <yahb> Axman6: ; <interactive>:1:1: error: Not in scope: type constructor or class `HasCallstack'
2021-01-15 06:08:31 +0100 <Axman6> :(
2021-01-15 06:09:10 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar)
2021-01-15 06:09:47 +0100justsomeguy(~justsomeg@unaffiliated/--/x-3805311)
2021-01-15 06:10:09 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-01-15 06:10:26 +0100Tario(~Tario@201.192.165.173)
2021-01-15 06:10:42 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-01-15 06:10:46 +0100 <superstar64> i'm surprised this works https://pastebin.com/raw/d2nAyNdy
2021-01-15 06:10:49 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 06:11:01 +0100texasmynsted(~texasmyns@99.96.221.112) (Ping timeout: 246 seconds)
2021-01-15 06:13:04 +0100 <superstar64> you get this if you leave out the instance: `    • No instance for Main arising from a use of ‘main’`
2021-01-15 06:13:54 +0100 <glguy> I don't think nullary type classes are generally that useful, but they make sense to exist so they are allowed too
2021-01-15 06:14:35 +0100howdoi(uid224@gateway/web/irccloud.com/x-ctamwhdrfdasswkk) (Quit: Connection closed for inactivity)
2021-01-15 06:15:14 +0100Tario(~Tario@201.192.165.173) (Ping timeout: 256 seconds)
2021-01-15 06:15:38 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 06:16:02 +0100 <superstar64> oh that's what they're called, thanks
2021-01-15 06:22:43 +0100Wuzzy(~Wuzzy@p5b0df7fc.dip0.t-ipconnect.de) (Remote host closed the connection)
2021-01-15 06:24:36 +0100plutoniix(~q@ppp-223-24-191-164.revip6.asianet.co.th) (Ping timeout: 240 seconds)
2021-01-15 06:25:16 +0100pcmanus1(~pcmanus@184.75.223.203) (Ping timeout: 240 seconds)
2021-01-15 06:29:21 +0100m0rphism(~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de) (Ping timeout: 256 seconds)
2021-01-15 06:31:19 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 06:31:20 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 06:31:26 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2021-01-15 06:33:06 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 06:34:15 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Read error: Connection reset by peer)
2021-01-15 06:34:44 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 06:35:30 +0100ADG1089__(~aditya@122.163.165.143)
2021-01-15 06:36:17 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 260 seconds)
2021-01-15 06:37:29 +0100plutoniix(~q@184.82.197.202)
2021-01-15 06:38:15 +0100grawity1(~grawity@84.39.117.57)
2021-01-15 06:41:44 +0100b4er(~b4er@193.27.14.141) (Quit: leaving)
2021-01-15 06:41:46 +0100ADG1089_(~adg1089@171.76.134.49) (Read error: Connection reset by peer)
2021-01-15 06:42:02 +0100iridescent(2fe3e53b@047-227-229-059.res.spectrum.com) (Quit: Connection closed)
2021-01-15 06:42:09 +0100ADG1089_(~adg1089@122.163.165.143)
2021-01-15 06:42:41 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 06:44:44 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 240 seconds)
2021-01-15 06:46:34 +0100texasmynsted(~texasmyns@99.96.221.112)
2021-01-15 06:46:58 +0100revprez_anzio(~revprez_a@pool-108-49-213-40.bstnma.fios.verizon.net) (Ping timeout: 265 seconds)
2021-01-15 06:47:09 +0100Profpatsch(~Profpatsc@static.88-198-193-255.clients.your-server.de) (Quit: WeeChat 2.9)
2021-01-15 06:47:26 +0100justsomeguy(~justsomeg@unaffiliated/--/x-3805311) (Quit: WeeChat 2.9)
2021-01-15 06:49:12 +0100revprez_anzio(~revprez_a@pool-108-49-213-40.bstnma.fios.verizon.net)
2021-01-15 06:56:08 +0100b4er(~b4er@193.27.14.77)
2021-01-15 07:02:18 +0100danvet(~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa)
2021-01-15 07:03:29 +0100vicfred(~vicfred@unaffiliated/vicfred) (Quit: Leaving)
2021-01-15 07:04:32 +0100grawity1(~grawity@84.39.117.57) (Remote host closed the connection)
2021-01-15 07:05:01 +0100pfurla(~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 264 seconds)
2021-01-15 07:09:16 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net)
2021-01-15 07:10:23 +0100noecho(~noecho@2a01:4f8:1c0c:80ee::4223) (Quit: ZNC - http://znc.in)
2021-01-15 07:10:55 +0100noecho(~noecho@2a01:4f8:1c0c:80ee::4223)
2021-01-15 07:12:11 +0100mirrorbird(~psutcliff@2a00:801:446:b70b:607:9995:9930:4d27)
2021-01-15 07:14:01 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Read error: Connection reset by peer)
2021-01-15 07:14:19 +0100 <superstar64> is there a typeclass where you can implement this? `lambda :: (a -> m c) -> m (a -> c)`
2021-01-15 07:15:10 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 07:16:15 +0100pfurla(~pfurla@2607:fb90:7ae4:d59c:fd3d:6aba:85b7:1892)
2021-01-15 07:16:49 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds)
2021-01-15 07:17:59 +0100ukari(~ukari@unaffiliated/ukari)
2021-01-15 07:18:29 +0100zx(637ce278@99-124-226-120.lightspeed.rcsntx.sbcglobal.net)
2021-01-15 07:19:04 +0100echoreply(~echoreply@unaffiliated/echoreply) (Quit: WeeChat 1.9.1)
2021-01-15 07:19:32 +0100echoreply(~echoreply@unaffiliated/echoreply)
2021-01-15 07:21:20 +0100 <jle`> superstar64: hm, Alternative?
2021-01-15 07:21:27 +0100 <jle`> lambda _ = empty
2021-01-15 07:22:10 +0100 <superstar64> well, something meaning full, like flip, where `m` is the reader monad
2021-01-15 07:22:34 +0100 <c_wraith> In general, that type only works for things that are the reader monad
2021-01-15 07:22:35 +0100Saukk(~Saukk@83-148-239-3.dynamic.lounea.fi) (Remote host closed the connection)
2021-01-15 07:22:46 +0100 <jle`> so, you're looking for maybe a generalized version of flip?
2021-01-15 07:23:16 +0100 <jle`> are you looking to find an abstraction, or are you asking about a specific 'm' you are thinking of?
2021-01-15 07:23:22 +0100 <superstar64> give me a second, i'll show you how i derived this
2021-01-15 07:24:37 +0100 <superstar64> https://imgur.com/a/FSf14pq
2021-01-15 07:24:40 +0100Stanley00(~stanley00@unaffiliated/stanley00) (Remote host closed the connection)
2021-01-15 07:24:59 +0100 <superstar64> and the matching haskell https://pastebin.com/raw/rueeReGy
2021-01-15 07:26:24 +0100 <superstar64> is there anything other then the reader monad that can inhabit `Marshallable`?
2021-01-15 07:26:36 +0100 <jle`> do you have any laws?
2021-01-15 07:26:46 +0100 <jle`> lambda _ = Nothing, for Maybe
2021-01-15 07:26:48 +0100 <superstar64> i haven't though of any
2021-01-15 07:27:28 +0100 <jle`> NonEmpty list, lambda f = (NE.head . f) :| []
2021-01-15 07:27:40 +0100 <jle`> but yeah without knowing what sort of behavior or laws you are thinking of, it's hard to answer in a meaningful way
2021-01-15 07:28:12 +0100 <superstar64> i'm trying to generalize typeclasses
2021-01-15 07:28:22 +0100 <superstar64> if that's even possible
2021-01-15 07:28:59 +0100pfurla_(~pfurla@2607:fb90:7ae4:d59c:e58e:b09b:b088:aa2b)
2021-01-15 07:29:05 +0100 <jle`> first think about what sort of properties you'd expect to hold
2021-01-15 07:29:09 +0100 <jle`> aka laws
2021-01-15 07:29:21 +0100 <jle`> what properties about the Reader version are important to you
2021-01-15 07:29:26 +0100pfurla(~pfurla@2607:fb90:7ae4:d59c:fd3d:6aba:85b7:1892) (Ping timeout: 264 seconds)
2021-01-15 07:29:36 +0100b4er(~b4er@193.27.14.77) (Quit: Lost terminal)
2021-01-15 07:30:06 +0100 <superstar64> well, i guess `(\x -> e1)(e2)` = `e1[x := e2]` is a pretty important one
2021-01-15 07:30:57 +0100 <superstar64> what other laws does the lambda calculus have?
2021-01-15 07:32:18 +0100riatre(~quassel@2001:310:6000:f::5198:1) (Ping timeout: 260 seconds)
2021-01-15 07:34:27 +0100b4er(~b4er@193.27.14.109)
2021-01-15 07:34:29 +0100mirrorbird(~psutcliff@2a00:801:446:b70b:607:9995:9930:4d27) (Ping timeout: 272 seconds)
2021-01-15 07:34:51 +0100pfurla(~pfurla@ool-182ed2e2.dyn.optonline.net)
2021-01-15 07:35:32 +0100vst(~vst@2406:3003:2004:2e8a:bd6b:578b:4351:fd57) (Ping timeout: 260 seconds)
2021-01-15 07:36:01 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2021-01-15 07:37:14 +0100pfurla_(~pfurla@2607:fb90:7ae4:d59c:e58e:b09b:b088:aa2b) (Ping timeout: 264 seconds)
2021-01-15 07:38:18 +0100rmk236(~lcampos@2a02:908:3616:b100:1800:1cb7:353d:300d)
2021-01-15 07:40:25 +0100phasespace(~sar@89-162-33-21.fiber.signal.no) (Ping timeout: 264 seconds)
2021-01-15 07:44:40 +0100superstar6447(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net)
2021-01-15 07:44:58 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net) (Remote host closed the connection)
2021-01-15 07:45:19 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net)
2021-01-15 07:45:25 +0100ADG1089_(~adg1089@122.163.165.143) (Ping timeout: 240 seconds)
2021-01-15 07:45:32 +0100superstar6447(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net) (Client Quit)
2021-01-15 07:46:12 +0100superstar6455(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net)
2021-01-15 07:46:34 +0100superstar6455(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net) ()
2021-01-15 07:47:48 +0100superstar6455(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net)
2021-01-15 07:48:01 +0100superstar64(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net) (Ping timeout: 248 seconds)
2021-01-15 07:48:08 +0100 <superstar6455> kiwi is being buggy today, anyway is marshallable a good name for that typeclass?
2021-01-15 07:49:52 +0100 <superstar6455> on the laws, i'm not sure if this cuts it `lam' e <*> (pure e') = e e'`
2021-01-15 07:52:25 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net) (Ping timeout: 264 seconds)
2021-01-15 07:52:45 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 07:53:03 +0100roconnor(~roconnor@host-104-157-225-60.dyn.295.ca) (Quit: Konversation terminated!)
2021-01-15 07:55:00 +0100 <superstar6455> ok it's on reddit now too https://old.reddit.com/r/haskell/comments/kxp65a/applicatives_where_a_m_c_m_a_c_is_sensible/?
2021-01-15 07:57:37 +0100Jd007(~Jd007@162.156.11.151) (Quit: Jd007)
2021-01-15 07:58:02 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds)
2021-01-15 08:01:40 +0100phasespace(~sar@80-89-47-117.inet.signal.no)
2021-01-15 08:05:50 +0100mirrorbird(~psutcliff@2a00:801:446:b70b:607:9995:9930:4d27)
2021-01-15 08:10:25 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net)
2021-01-15 08:12:32 +0100zx(637ce278@99-124-226-120.lightspeed.rcsntx.sbcglobal.net) (Quit: Connection closed)
2021-01-15 08:15:48 +0100_ht(~quassel@82-169-194-8.biz.kpn.net)
2021-01-15 08:21:08 +0100 <b4er> Is this not co-applicative?
2021-01-15 08:21:49 +0100 <b4er> Identity can also be an instance btw, but it's not really interesting ;P
2021-01-15 08:22:05 +0100jespada(~jespada@90.254.245.49) (Ping timeout: 240 seconds)
2021-01-15 08:22:07 +0100 <b4er> Ah no, you also need pure too
2021-01-15 08:22:44 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 272 seconds)
2021-01-15 08:23:26 +0100chele(~chele@ip5b40237d.dynamic.kabel-deutschland.de)
2021-01-15 08:23:27 +0100knupfer(~Thunderbi@200116b82c666e00a07dcffffebc6b68.dip.versatel-1u1.de)
2021-01-15 08:23:43 +0100jpds(~jpds@gateway/tor-sasl/jpds) (Ping timeout: 240 seconds)
2021-01-15 08:24:07 +0100knupfer(~Thunderbi@200116b82c666e00a07dcffffebc6b68.dip.versatel-1u1.de) (Remote host closed the connection)
2021-01-15 08:24:15 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 08:24:20 +0100knupfer(~Thunderbi@200116b82c666e00f1263aa23e408b12.dip.versatel-1u1.de)
2021-01-15 08:25:13 +0100jespada(~jespada@90.254.245.49)
2021-01-15 08:25:58 +0100 <mniip> b4er, the "f (a -> b) -> f a -> f b" formulation of applicative is merely a convenient description in haskell. From the category theory PoV, this description is only available in a cartesian closed category. The more general description involves arbitrary monoidal categories and so is not really up for dualization
2021-01-15 08:26:27 +0100dhouthoo(~dhouthoo@ptr-eitgbj2w0uu6delkbrh.18120a2.ip6.access.telenet.be)
2021-01-15 08:26:51 +0100 <idnar> @hoogle .#
2021-01-15 08:26:51 +0100 <lambdabot> Network.AWS.Data.Headers (.#) :: FromText a => ResponseHeaders -> HeaderName -> Either String a
2021-01-15 08:26:52 +0100 <lambdabot> Network.AWS.Prelude (.#) :: FromText a => ResponseHeaders -> HeaderName -> Either String a
2021-01-15 08:26:52 +0100 <lambdabot> Data.Profunctor.Unsafe (.#) :: forall a b c q . (Profunctor p, Coercible b a) => p b c -> q a b -> p a c
2021-01-15 08:27:29 +0100 <idnar> huh why is that unsafe?
2021-01-15 08:27:43 +0100 <mniip> because it ignores q
2021-01-15 08:28:04 +0100 <mniip> it assumes the second argument to be the identity
2021-01-15 08:29:43 +0100tzh(~xax@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2021-01-15 08:30:12 +0100 <idnar> oh I see, it's a class method (and also not quite what I wanted)
2021-01-15 08:32:18 +0100Sgeo(~Sgeo@ool-18b98aa4.dyn.optonline.net) (Read error: Connection reset by peer)
2021-01-15 08:34:35 +0100 <idnar> @hoogle #.
2021-01-15 08:34:35 +0100 <lambdabot> Data.Profunctor.Unsafe ( #. ) :: forall a b c q . (Profunctor p, Coercible c b) => q b c -> p a b -> p a c
2021-01-15 08:34:35 +0100 <lambdabot> Lens.Micro.Internal ( #. ) :: Coercible c b => (b -> c) -> (a -> b) -> a -> c
2021-01-15 08:34:35 +0100 <lambdabot> Linear.Affine ( #. ) :: Coercible c b => (b -> c) -> (a -> b) -> a -> c
2021-01-15 08:38:43 +0100 <b4er> mniip, I did not know about that. if there's Comonad there must be Coapplicative but guess not.
2021-01-15 08:39:16 +0100 <b4er> What is the reason we got Applicative then?
2021-01-15 08:39:38 +0100 <b4er> I agree, it's convenient but that's probably not the reason
2021-01-15 08:40:05 +0100 <mniip> monads are a monoid object in the category of endofunctors
2021-01-15 08:40:12 +0100 <mniip> it's very easy to switch in "comonoid object"
2021-01-15 08:40:14 +0100 <mniip> and get comonads
2021-01-15 08:40:21 +0100 <mniip> applicatives not so much
2021-01-15 08:40:54 +0100 <mniip> applicatives can be seen as lax monoidal functors from the cartesian structure on hask to itself
2021-01-15 08:41:03 +0100 <mniip> it's not immediately clear what we want to dualize here
2021-01-15 08:41:31 +0100 <mniip> cocartesian structure? all functors are lax monoidal with respect to it
2021-01-15 08:41:56 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 08:42:00 +0100 <mniip> (the comonad class has a note about it)
2021-01-15 08:42:06 +0100 <idnar> @hoogle (a -> b) -> (a -> c) -> a -> (b, c)
2021-01-15 08:42:08 +0100 <lambdabot> Data.Tuple.Extra (&&&) :: (a -> b) -> (a -> c) -> a -> (b, c)
2021-01-15 08:42:08 +0100 <lambdabot> Extra (&&&) :: (a -> b) -> (a -> c) -> a -> (b, c)
2021-01-15 08:42:08 +0100 <lambdabot> Control.Wire.Core (&&&!) :: (a -> b) -> (a -> c) -> (a -> (b, c))
2021-01-15 08:42:39 +0100 <b4er> I should look at laxity (or whatever the real name is), I don't think I ever read something proper about it=
2021-01-15 08:43:09 +0100 <mniip> there's the notion of a monoidal functor
2021-01-15 08:43:14 +0100 <mniip> a functor that preserves monoidal structure
2021-01-15 08:43:29 +0100 <b4er> I know a bit about these, yeah but not what the lax part means
2021-01-15 08:43:31 +0100matryoshka`(~matryoshk@2606:6080:1002:8:3285:30e:de43:8809) (Quit: ZNC 1.8.2 - https://znc.in)
2021-01-15 08:43:32 +0100 <mniip> "lax monoidal functor" is a weaker notion
2021-01-15 08:43:48 +0100matryoshka(~matryoshk@2606:6080:1002:8:3285:30e:de43:8809)
2021-01-15 08:44:31 +0100 <mniip> instead of a natural isomorphism F A x F B = F (A x B) you look at a mere natural transformation in the forward direction
2021-01-15 08:45:29 +0100cfricke(~cfricke@unaffiliated/cfricke)
2021-01-15 08:46:13 +0100 <mniip> there's also something called day convolution
2021-01-15 08:46:43 +0100 <mniip> it creates a monoidal structure
2021-01-15 08:46:43 +0100ulidtko(~ulidtko@193.111.48.79)
2021-01-15 08:46:50 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 08:46:55 +0100 <mniip> and a monoid object in this structure is precisely a lax monoidal functor
2021-01-15 08:47:30 +0100 <mniip> there's a somewhat dual notion of day convolution of contravariant functors
2021-01-15 08:47:32 +0100 <b4er> Pierce (the book I'm currently working through) never mentions "laxity" or "day convolutions" it seems but maybe he'll just use different nomenclature
2021-01-15 08:48:19 +0100 <mniip> which book
2021-01-15 08:48:47 +0100 <b4er> Pierce's "Basic Category Theory for Computer Scientists"
2021-01-15 08:48:57 +0100ulidtko|k(~ulidtko@194.54.80.38)
2021-01-15 08:49:02 +0100 <mniip> :S
2021-01-15 08:49:25 +0100 <b4er> What?
2021-01-15 08:49:38 +0100 <mniip> not a fan of that type of literature
2021-01-15 08:50:44 +0100 <b4er> Makes sense it's got Computer Scientist in its title
2021-01-15 08:50:49 +0100 <mniip> looking at the contents, this may be a bit above that book's pay grade
2021-01-15 08:51:25 +0100ulidtko(~ulidtko@193.111.48.79) (Ping timeout: 240 seconds)
2021-01-15 08:52:03 +0100 <mniip> (my general sentiment is that in attempting to "dumb down" category theory you lose crucial details, at least, I haven't seen a source that doesn't)
2021-01-15 08:53:59 +0100 <b4er> It's the feeling I got with all the material from Bartosz who seems fairly popular in Haskell world. But I do like this book
2021-01-15 08:54:05 +0100dandels(~dandels@unaffiliated/dandels)
2021-01-15 08:54:20 +0100superstar6455(6ccefa7c@108-206-250-124.lightspeed.miamfl.sbcglobal.net) (Quit: Connection closed)
2021-01-15 08:54:32 +0100 <mniip> some of bartosz's material is hacked together without any rigor :(
2021-01-15 08:54:55 +0100ericsagnes(~ericsagne@2405:6580:0:5100:6bc2:e498:a980:d2bd) (Ping timeout: 272 seconds)
2021-01-15 08:55:16 +0100 <b4er> It is meant as a light introduction though and I am aware that it is not a proper introduction to category theory. I think it's a good book especially coupled with the exercises
2021-01-15 08:55:55 +0100 <mniip> have you come across examples of non-concrete non-thin categories
2021-01-15 08:56:25 +0100tsrt^(~hph@ip98-184-89-2.mc.at.cox.net) (Ping timeout: 240 seconds)
2021-01-15 08:57:02 +0100tsrt^(~hph@ip98-184-89-2.mc.at.cox.net)
2021-01-15 08:57:51 +0100 <b4er> If you got a good (book) suggestion I am all ears
2021-01-15 08:58:12 +0100 <b4er> mniip: I don't think I did
2021-01-15 08:58:25 +0100 <mniip> unfortunately I don't
2021-01-15 08:58:36 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-01-15 08:59:00 +0100 <mniip> I read mac lane's book, and it is very pure math heavy, which caused me to learn a ton of pure math (which I found I liked)
2021-01-15 08:59:06 +0100 <b4er> I had a meeting last week where I got two suggestions, but I forgot the second
2021-01-15 08:59:08 +0100 <mniip> but I anticipate many won't
2021-01-15 08:59:31 +0100 <b4er> It's everytime I use Zoom and someone puts it into chat, "yay meeting's over" - logout and stuff's gone ^^
2021-01-15 08:59:41 +0100 <mniip> there's emily riehl's more recent book which is still pure maths but less "heavey"
2021-01-15 09:00:11 +0100 <b4er> I'll ask next time I get a chance for a meeting but that'll be a while I think
2021-01-15 09:01:20 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Remote host closed the connection)
2021-01-15 09:01:53 +0100bitmagie(~Thunderbi@200116b8066e11002810c42dd768e9a0.dip.versatel-1u1.de)
2021-01-15 09:01:58 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 09:02:20 +0100Vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2021-01-15 09:02:30 +0100 <mniip> in pure math, category theory is orinally used to formalize some notions of algebraic topology
2021-01-15 09:02:52 +0100 <mniip> which is why a lot of introductions assume knowledge of topology and algebra
2021-01-15 09:03:33 +0100 <mniip> on the other hand, category theory is the study of structure, abstraction and generalization. And you can't appreciate an abstraction if you don't have a variety of examples fitting that abstraction
2021-01-15 09:03:41 +0100 <mniip> which there's plenty in pure math, not so much in cs
2021-01-15 09:04:11 +0100 <mniip> this is why it's impossible to explain what a monad is
2021-01-15 09:04:16 +0100 <mniip> you have to toy around with examples
2021-01-15 09:05:41 +0100 <b4er> It's always Set, arrows over Set and so on (okay, not always but mostly) yah
2021-01-15 09:06:57 +0100ericsagnes(~ericsagne@2405:6580:0:5100:ac2c:af5:4276:675d)
2021-01-15 09:07:06 +0100Vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Ping timeout: 256 seconds)
2021-01-15 09:10:34 +0100Rudd0(~Rudd0@185.189.115.103) (Ping timeout: 246 seconds)
2021-01-15 09:12:57 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 09:13:33 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se)
2021-01-15 09:15:22 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-01-15 09:16:03 +0100jb55(~jb55@gateway/tor-sasl/jb55) (Ping timeout: 240 seconds)
2021-01-15 09:17:26 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 09:17:26 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3656:64d3:d9bb:432e:acbc) (Ping timeout: 264 seconds)
2021-01-15 09:19:24 +0100ADG1089_(~adg1089@122.163.165.143)
2021-01-15 09:20:33 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds)
2021-01-15 09:22:48 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 09:24:48 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3a8e:d956:f43e:d9a3:9155)
2021-01-15 09:24:54 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
2021-01-15 09:27:48 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 260 seconds)
2021-01-15 09:28:08 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 09:28:13 +0100niko(~niko@freenode/staff/ubuntu.member.niko)
2021-01-15 09:28:57 +0100knupfer(~Thunderbi@200116b82c666e00f1263aa23e408b12.dip.versatel-1u1.de) (Ping timeout: 260 seconds)
2021-01-15 09:30:13 +0100proteusguy(~proteusgu@cm-58-10-154-202.revip7.asianet.co.th) (Ping timeout: 264 seconds)
2021-01-15 09:30:44 +0100kritzefitz(~kritzefit@fw-front.credativ.com)
2021-01-15 09:32:01 +0100 <ukari> why there is some code that can run correctly in ghci but occurs "Overlapping instances" error when compile from file? https://gist.github.com/ukari/edddcd04ca0da3068460a34bb050d736
2021-01-15 09:32:35 +0100LKoen(~LKoen@119.169.9.109.rev.sfr.net)
2021-01-15 09:32:57 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 09:33:16 +0100yoneda(~mike@193.206.102.122)
2021-01-15 09:34:16 +0100 <ukari> And I fix the compile error by change OVERLAPPABLE to INCOHERENT, but get another weird behaviour that type signature of `testRaw` in ghci is different from signature in file
2021-01-15 09:34:33 +0100danso(~dan@23-233-104-25.cpe.pppoe.ca) (Quit: WeeChat 3.0)
2021-01-15 09:36:12 +0100 <int-e> ukari: as a guess, ghci's extended defaulting kicks in, so it picks `Integer` as the type for that 0
2021-01-15 09:36:24 +0100 <int-e> And indeed testNumber = foo (0 :: Integer) works
2021-01-15 09:37:48 +0100 <ukari> maybe
2021-01-15 09:37:50 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 09:40:54 +0100nineonine(~nineonine@50.216.62.2)
2021-01-15 09:41:04 +0100 <int-e> But that seems to need ExtendedDefaultRules. I thought ghci enabled that, but :show language doesn't report it. Anyway, the module compiles if you add {-# LANGUAGE ExtendedDefaultRules #-}
2021-01-15 09:41:51 +0100 <ukari> :show language returns NoDatatypeContexts, NondecreasingIndentation
2021-01-15 09:42:04 +0100 <int-e> I can't fully explain why that makes a difference.
2021-01-15 09:42:32 +0100proteusguy(~proteusgu@cm-58-10-154-202.revip7.asianet.co.th)
2021-01-15 09:43:12 +0100 <int-e> ukari: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ghci.html#type-defaulting-in-ghci "At the GHCi prompt, or with GHC if the ExtendedDefaultRules flag is given, [...]"
2021-01-15 09:43:27 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:6ccc:7c34:64f9:a54f) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 09:43:49 +0100bitmagie(~Thunderbi@200116b8066e11002810c42dd768e9a0.dip.versatel-1u1.de) (Quit: bitmagie)
2021-01-15 09:44:05 +0100 <ukari> int-e, thank you, I compile with {-# LANGUAGE ExtendedDefaultRules #-} and it works as same as ghci
2021-01-15 09:44:14 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:d8c5:1dbb:568:768a)
2021-01-15 09:46:21 +0100knupfer(~Thunderbi@200116b82c666e00c4a266fffebc8aba.dip.versatel-1u1.de)
2021-01-15 09:46:47 +0100knupfer(~Thunderbi@200116b82c666e00c4a266fffebc8aba.dip.versatel-1u1.de) (Remote host closed the connection)
2021-01-15 09:47:01 +0100knupfer(~Thunderbi@200116b82c666e00540ca7b495fcd41e.dip.versatel-1u1.de)
2021-01-15 09:47:12 +0100pera(pera@gateway/vpn/mullvad/pera)
2021-01-15 09:48:38 +0100Varis(~Tadas@unaffiliated/varis)
2021-01-15 09:49:46 +0100kritzefitz(~kritzefit@fw-front.credativ.com) (Ping timeout: 246 seconds)
2021-01-15 09:51:26 +0100knupfer(~Thunderbi@200116b82c666e00540ca7b495fcd41e.dip.versatel-1u1.de) (Ping timeout: 240 seconds)
2021-01-15 09:52:05 +0100nineonine(~nineonine@50.216.62.2) (Ping timeout: 240 seconds)
2021-01-15 09:52:24 +0100 <dminuoso> Can GHCi tell me which rules exist for a binding?
2021-01-15 09:54:41 +0100michalz(~user@185.246.204.80)
2021-01-15 09:54:47 +0100nineonine(~nineonine@50.216.62.2)
2021-01-15 09:57:00 +0100kritzefitz(~kritzefit@fw-front.credativ.com)
2021-01-15 09:57:08 +0100borne(~fritjof@200116b864d9bb00b67b1043029333d3.dip.versatel-1u1.de)
2021-01-15 09:57:52 +0100wonko7(~wonko7@91.151.74.79)
2021-01-15 09:59:19 +0100nineonine(~nineonine@50.216.62.2) (Ping timeout: 260 seconds)
2021-01-15 10:01:34 +0100 <int-e> dminuoso: oh that would be useful (but I don't think ghci displays rules at all)
2021-01-15 10:05:41 +0100jb55(~jb55@gateway/tor-sasl/jb55)
2021-01-15 10:05:48 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2021-01-15 10:08:08 +0100jpds(~jpds@gateway/tor-sasl/jpds)
2021-01-15 10:10:20 +0100dandels(~dandels@unaffiliated/dandels) (Ping timeout: 256 seconds)
2021-01-15 10:10:25 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Remote host closed the connection)
2021-01-15 10:10:42 +0100poljar(~poljar@93-139-54-120.adsl.net.t-com.hr)
2021-01-15 10:10:56 +0100drbean(~drbean@TC210-63-209-154.static.apol.com.tw) (Ping timeout: 240 seconds)
2021-01-15 10:11:22 +0100hnOsmium0001(uid453710@gateway/web/irccloud.com/x-womepahugemfqphs) (Quit: Connection closed for inactivity)
2021-01-15 10:13:25 +0100poljar1(~poljar@93-143-187-222.adsl.net.t-com.hr) (Ping timeout: 240 seconds)
2021-01-15 10:17:07 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas)
2021-01-15 10:17:36 +0100mastarija(~mastarija@93-136-6-188.adsl.net.t-com.hr)
2021-01-15 10:18:49 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56)
2021-01-15 10:22:02 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) (Client Quit)
2021-01-15 10:22:23 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56)
2021-01-15 10:24:31 +0100niko(~niko@freenode/staff/ubuntu.member.niko) (Ping timeout: 606 seconds)
2021-01-15 10:26:43 +0100xff0x(~xff0x@2001:1a81:52c6:7f00:29e8:57ce:ba2b:1f46) (Ping timeout: 260 seconds)
2021-01-15 10:27:12 +0100xff0x(~xff0x@2001:1a81:52c6:7f00:782f:7bae:5710:c758)
2021-01-15 10:27:21 +0100kuribas(~user@ptr-25vy0iacr2x8efujlkt.18120a2.ip6.access.telenet.be)
2021-01-15 10:28:03 +0100 <kuribas> is creating closures expensive in ghc? For example, I want to parse a query into an applicative action, but it has to first parse and validate the whole query before it can apply the action.
2021-01-15 10:28:30 +0100 <kuribas> So I wonder if the overhead of creating the applicative closure is negligible or not.
2021-01-15 10:28:58 +0100 <opqdonut> it's cheap
2021-01-15 10:29:19 +0100 <kuribas> right :)
2021-01-15 10:29:20 +0100 <opqdonut> the haskell runtime isn't "creating closures" in the same way as an imperative runtime would
2021-01-15 10:29:33 +0100christo(~chris@81.96.113.213)
2021-01-15 10:30:03 +0100 <opqdonut> it's graph reduction so closing over some variables is pretty much automatic
2021-01-15 10:30:24 +0100nineonine(~nineonine@50.216.62.2)
2021-01-15 10:30:51 +0100 <kuribas> The nice thing with this method is that there is no need for a separate validation step.
2021-01-15 10:31:07 +0100 <opqdonut> but of course if you have two different options you can measure the performance (perhaps with criterion)
2021-01-15 10:31:33 +0100 <kuribas> I suppose I'd need to benchmark it first.
2021-01-15 10:31:38 +0100 <kuribas> I mean profile
2021-01-15 10:31:54 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3a8e:d956:f43e:d9a3:9155) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 10:34:44 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-01-15 10:35:11 +0100 <kuribas> I would think the IO and database access would dominate the runtime. However in this article, they claim that parsing the JSON would be a bottleck: https://hasura.io/blog/architecture-of-a-high-performance-graphql-to-sql-server-58d9944b8a87/
2021-01-15 10:35:14 +0100 <dminuoso> Is there a name for binary trees in which the second-to-outermost nodes cannot be binary?
2021-01-15 10:35:25 +0100 <dminuoso> (i.e. the parent of each leaf may not be binary)
2021-01-15 10:35:52 +0100 <dminuoso> Im thinking of a particular take of a PATRICIA trie
2021-01-15 10:36:04 +0100nineonine(~nineonine@50.216.62.2) (Ping timeout: 265 seconds)
2021-01-15 10:36:38 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds)
2021-01-15 10:37:28 +0100 <kuribas> I find it strange that generating JSON using Aeson would be slower than reading stuff from a database.
2021-01-15 10:37:49 +0100 <kuribas> perhaps there where using toJson, instead of toEncoding?
2021-01-15 10:38:07 +0100 <dminuoso> It's possible
2021-01-15 10:38:20 +0100 <dminuoso> But also, aeson isn't exactly high performance
2021-01-15 10:38:28 +0100 <dminuoso> Despite of what it claims
2021-01-15 10:39:13 +0100 <kuribas> is there a faster alternative?
2021-01-15 10:39:20 +0100 <dminuoso> Yes.
2021-01-15 10:39:46 +0100 <kuribas> toEncoding goes straight to a bytestring builder, so how can you improve that?
2021-01-15 10:39:54 +0100 <kuribas> dminuoso: which is?
2021-01-15 10:41:01 +0100 <dminuoso> Ah well, both directions or just encoding?
2021-01-15 10:42:13 +0100troydm(~troydm@unaffiliated/troydm) (Ping timeout: 264 seconds)
2021-01-15 10:43:00 +0100 <kuribas> just encoding
2021-01-15 10:43:10 +0100 <dminuoso> Even then, aeson uses Text for string data.
2021-01-15 10:43:13 +0100 <mniip> kuribas, there's very little difference between code and data in the RTS
2021-01-15 10:43:26 +0100 <dminuoso> That requires conversion from UTF16 to UTF6
2021-01-15 10:43:52 +0100 <mniip> the only performance difference between (x, y) and (\p -> p x y) is the fact that the former memoizes (sometimes)
2021-01-15 10:44:16 +0100darjeeling_(~darjeelin@122.245.120.137) (Ping timeout: 240 seconds)
2021-01-15 10:44:22 +0100niko(~niko@freenode/staff/ubuntu.member.niko)
2021-01-15 10:45:06 +0100 <mniip> oh I guess and the fact that projections out of (,) (selectors) are slightly more optimized
2021-01-15 10:45:15 +0100troydm(~troydm@unaffiliated/troydm)
2021-01-15 10:48:44 +0100 <kuribas> dminuoso: I get that it's slower than say directly writing to a buffer in C++, but I just find it hard to believe it's slower than reading from disk.
2021-01-15 10:50:16 +0100 <kuribas> from the article: "From our benchmarks this approach is roughly 3–6x faster than the transformation function in Haskell"
2021-01-15 10:50:29 +0100 <kuribas> that includes parsing the query result also...
2021-01-15 10:51:26 +0100 <kuribas> dminuoso: still curious for the fast Aeson alternative ...
2021-01-15 10:51:38 +0100gaussian(8cb4f058@gateway/web/cgi-irc/kiwiirc.com/ip.140.180.240.88)
2021-01-15 10:52:38 +0100 <dminuoso> kuribas: Mmm, I guess for just going into encoding there's just the UTF16 of Text in the way
2021-01-15 10:53:01 +0100 <dminuoso> Either way, the problem is JSON. :p
2021-01-15 10:53:55 +0100 <kuribas> dminuoso: not using Text means that my library would need to take ByteString for text fields, which is rather ugly...
2021-01-15 10:54:23 +0100 <kuribas> but then, how hard can it be to generate JSON?
2021-01-15 10:54:25 +0100 <dminuoso> You could use text-utf8 I guess?
2021-01-15 10:54:52 +0100zaquest(~notzaques@5.128.210.178) (Quit: Leaving)
2021-01-15 10:54:57 +0100mastarija(~mastarija@93-136-6-188.adsl.net.t-com.hr) (Quit: Leaving)
2021-01-15 10:55:24 +0100 <kuribas> ah, I didn't about that package.
2021-01-15 10:55:36 +0100zar(~zar@fw1.ciirc.cvut.cz)
2021-01-15 10:55:44 +0100 <kuribas> Why not merge it with Text?
2021-01-15 10:56:06 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 10:56:13 +0100gaussian(8cb4f058@gateway/web/cgi-irc/kiwiirc.com/ip.140.180.240.88) (Client Quit)
2021-01-15 10:56:50 +0100 <kritzefitz> I think UTF16 performs better than UTF8 in cases, when you don't need UTF8 for external reasons. For example, indexing on UTF16 is O(1), while on UTF8 it is O(n).
2021-01-15 10:56:52 +0100 <kuribas> then again, mysql-haskell uses normal Text, and most other packages do.
2021-01-15 10:57:14 +0100 <kuribas> So converting to Utf-8 will not improve things...
2021-01-15 10:57:23 +0100mirrorbird(~psutcliff@2a00:801:446:b70b:607:9995:9930:4d27) (Quit: Leaving)
2021-01-15 10:57:26 +0100 <kuribas> kritzefitz: indeixing on UTF16 is not O(1)
2021-01-15 10:57:31 +0100 <mniip> >indexing on UTF16 is O(1)
2021-01-15 10:57:34 +0100 <mniip> that's a bad, bad lie
2021-01-15 10:57:35 +0100 <merijn> Text is UTF16 because ICU uses UTF-16 and anyone who needs *serious* unicode processing needs ICU
2021-01-15 10:57:45 +0100 <kritzefitz> It is not?
2021-01-15 10:57:48 +0100 <merijn> kritzefitz: No
2021-01-15 10:57:54 +0100 <merijn> UTF-16 is a variable length encoding
2021-01-15 10:57:58 +0100 <kritzefitz> Then I stand corrected.
2021-01-15 10:58:06 +0100 <merijn> Because there are more than 2^16 unicode codepoints
2021-01-15 10:58:23 +0100 <merijn> kritzefitz: And even if you use UTF-32 you don't get *sensible* O(1) indexing
2021-01-15 10:58:23 +0100hekkaidekapus{(~tchouri@gateway/tor-sasl/hekkaidekapus) (Ping timeout: 240 seconds)
2021-01-15 10:58:34 +0100 <merijn> Because there is no such thing as *sensible* indexing of unicode
2021-01-15 10:58:36 +0100 <mniip> I mean you can index "codepoints" in O(1)
2021-01-15 10:58:38 +0100 <merijn> It's literally impossible
2021-01-15 10:58:48 +0100 <mniip> however "codepoints" are not "characters"
2021-01-15 10:58:50 +0100 <dminuoso> kuribas: The same thing as usual: We dont have any company who hires 2 experiences Haskellers full time to take care of text-utf8.
2021-01-15 10:58:54 +0100 <merijn> mniip: Which is why I said *sensible*
2021-01-15 10:58:56 +0100 <dminuoso> Which would probably be necessary
2021-01-15 10:59:04 +0100 <merijn> dminuoso: But also, who really cares?
2021-01-15 10:59:06 +0100MorrowM(~Moshe@bzq-110-168-31-106.red.bezeqint.net)
2021-01-15 10:59:26 +0100 <merijn> for something like 95% of applications the internals of Text are irrelevant
2021-01-15 10:59:44 +0100 <mniip> I had a fun time working around wchar_t in C++ the other day
2021-01-15 10:59:52 +0100 <kuribas> merijn: for performance?
2021-01-15 11:00:05 +0100 <mniip> now super salty whenever someone goes "look we have 16-bit chars we did it we solved unicode"
2021-01-15 11:00:10 +0100 <merijn> kuribas: What performance, *exactly*?
2021-01-15 11:00:18 +0100darjeeling_(~darjeelin@122.245.120.137)
2021-01-15 11:00:26 +0100 <merijn> mniip: The width of wchar_t isn't specified to be 16-bit
2021-01-15 11:00:28 +0100 <kuribas> merijn: writing Text to bytestrings
2021-01-15 11:00:31 +0100LKoen(~LKoen@119.169.9.109.rev.sfr.net) (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”)
2021-01-15 11:00:32 +0100 <mniip> it happens to be that though
2021-01-15 11:00:46 +0100 <merijn> kuribas: How do you think that will be faster?
2021-01-15 11:00:53 +0100 <mniip> I ended up writing a bunch of code that processes std::basic_string<char32_t>
2021-01-15 11:01:05 +0100 <mniip> and you'd be surprised by how bad the stdlib support for that is
2021-01-15 11:01:07 +0100 <merijn> You need to copy anyway, since Text isn't pinned and ByteString is, so you don't get to skip the copy
2021-01-15 11:01:17 +0100 <kuribas> merijn: because you need to process less data?
2021-01-15 11:01:22 +0100 <kuribas> merijn: more cache locality?
2021-01-15 11:01:26 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) (Ping timeout: 240 seconds)
2021-01-15 11:01:30 +0100 <merijn> And I find it hard to believe that recoding UTF-16 to UTF-8 is that computationally intensive
2021-01-15 11:02:08 +0100 <merijn> kuribas: I stand by my claim that for 95% of applications (conservative estimate) this doesn't matter shit
2021-01-15 11:02:26 +0100 <kritzefitz> So what exactly is the reason for using UTF16? I guess (or at least hope) there is some reason why ICU works on UTF16 instead of the more ubiquitous UTF8?
2021-01-15 11:02:28 +0100 <merijn> kuribas: both your network connections *and* your hard disk are going to be slower than your encoding will be
2021-01-15 11:02:46 +0100 <kuribas> merijn: perhaps... I am still confused about their claim that Aeson was the bottleneck...
2021-01-15 11:02:46 +0100 <merijn> kritzefitz: Because ICU predates utf-8 being near universal
2021-01-15 11:03:16 +0100 <merijn> kuribas: I call BS on that claim without hard and well defined benchmarks
2021-01-15 11:03:23 +0100 <mniip> kritzefitz, I might be wrong here but it might come from microsoft's sloppy implementation of unicode?
2021-01-15 11:03:25 +0100 <dminuoso> kritzefitz: Actually UTF-16 is very prevalent.
2021-01-15 11:03:39 +0100 <merijn> kritzefitz: Same reason Java uses UTF-16 as do the old macOS filesystem and MicroSoft's NTFS
2021-01-15 11:04:13 +0100 <merijn> mniip: UTF-8 was invented later and not by the unicode consortium
2021-01-15 11:04:18 +0100 <dminuoso> Java for example internally encodes strings as UTF-16 too.
2021-01-15 11:04:35 +0100Rudd0(~Rudd0@185.189.115.103)
2021-01-15 11:04:36 +0100 <mniip> ah
2021-01-15 11:04:45 +0100 <kuribas> merijn: indeed, and I am conjecturing that they did something inefficient, like using toJson instead of toEncoding.
2021-01-15 11:05:03 +0100 <kuribas> merijn: and perhaps an expensive query postprocessing step
2021-01-15 11:05:08 +0100 <aldum> I remember when I heard about that in Java
2021-01-15 11:05:25 +0100 <mniip> we had a problem with aeson performance once
2021-01-15 11:05:33 +0100 <mniip> but that's when we were running aeson on ghcjs
2021-01-15 11:05:36 +0100 <aldum> I was like "wait, a minute, I can name variables with kanji?" turns out I can
2021-01-15 11:05:38 +0100 <mniip> so like, understandable have a nice day
2021-01-15 11:06:08 +0100 <merijn> aldum: Haskell is clearly superior!
2021-01-15 11:06:08 +0100 <dminuoso> merijn: Anyway, if you deal with large strings in Haskell, then you waste quite a bif of memory.
2021-01-15 11:06:20 +0100 <opqdonut> json is surprisingly inefficient
2021-01-15 11:06:23 +0100 <merijn> > let x ☃ y = x*x + y*y in 2 ☃ 3
2021-01-15 11:06:24 +0100 <lambdabot> 13
2021-01-15 11:06:31 +0100 <merijn> opqdonut++
2021-01-15 11:06:40 +0100 <opqdonut> we made a service (in clojure though) that was processing large json requests and responses, and the serde time dominated everything
2021-01-15 11:06:42 +0100 <merijn> Anyone who gives a shit about encoding performance shouldn't be using JSON anyway
2021-01-15 11:06:51 +0100 <opqdonut> even though we did db access and computation
2021-01-15 11:07:09 +0100 <mniip> > let (😼) = (<>) in "hello" 😼 "world"
2021-01-15 11:07:11 +0100 <lambdabot> "helloworld"
2021-01-15 11:07:14 +0100 <kuribas> mniip: I wouldn't use ghcjs if I needed even a small bit of performance.
2021-01-15 11:07:24 +0100 <ph88> hey guys, do you know a few examples when making things strict hurts the code? when is it better to leave things lazy ?
2021-01-15 11:07:29 +0100 <dminuoso> UTF-8 is space efficient, and if you do string operations you get better locality of reference
2021-01-15 11:07:37 +0100 <mniip> kuribas, yea but when your ghcjs webapp needs to query some data from the backend, and the data happens to be 100KB of json
2021-01-15 11:07:39 +0100 <kuribas> ph88: right folds
2021-01-15 11:07:44 +0100 <merijn> dminuoso: Also, robust to dumbass C code!
2021-01-15 11:07:57 +0100 <ph88> kuribas, what is it with right folds ?
2021-01-15 11:08:19 +0100 <merijn> ph88: There are lots of cases where making things strict hurts code
2021-01-15 11:08:24 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 11:08:35 +0100Guest11631(~textual@2603-7000-3040-0000-91cc-b7a0-b6bf-1a42.res6.spectrum.com) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 11:08:50 +0100 <merijn> ph88: A strict program will *at best* do the same number of operations as a lazy one, but on average it will do much, much more.
2021-01-15 11:08:52 +0100 <dminuoso> ph88: "hurts the code" is so generic. Is this just a question "why is lazyness useful"?
2021-01-15 11:09:01 +0100Franciman(~francesco@host-82-48-174-127.retail.telecomitalia.it)
2021-01-15 11:09:06 +0100christo(~chris@81.96.113.213)
2021-01-15 11:09:17 +0100 <kritzefitz> Yes, I was aware that many things use UTF16. But most of the cases I know are only “local” to some component and once you interchange data between different components it is usually done in UTF8. Apparently I assumed there was some non-historic reason for that, but maybe that was wrong.
2021-01-15 11:09:31 +0100 <dminuoso> kritzefitz: http://utf8everywhere.org/
2021-01-15 11:09:35 +0100 <dminuoso> You might find this website enlightening.
2021-01-15 11:09:36 +0100 <mniip> merijn, asymptotically
2021-01-15 11:09:47 +0100 <ph88> dminuoso, ye but i would like to have it phrased the other way around -- how can strictness be bad and have some good examples
2021-01-15 11:09:48 +0100 <mniip> in practice the constant might bite
2021-01-15 11:09:53 +0100 <merijn> ph88: Now there are some space leak scenarios where the laziness costs you more than you save due GHC's implementation, but those aren't nearly as common as some people make it out to be
2021-01-15 11:09:53 +0100 <kuribas> ph88: right folds are quite efficient, and don't require an accumulator to be efficient, unlike in scheme.
2021-01-15 11:10:22 +0100 <merijn> kritzefitz: Well, you can't interchange Text, so ;)
2021-01-15 11:10:23 +0100ddere(uid110888@gateway/web/irccloud.com/x-nzqxoujubybhmaoy) (Quit: Connection closed for inactivity)
2021-01-15 11:10:47 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 11:11:00 +0100 <merijn> kritzefitz: That was my earlier point, the internals of Text (like it being UTF-16) are irrelevant to users
2021-01-15 11:11:27 +0100 <merijn> Unless you're a MagicHash and unsafeX adept
2021-01-15 11:11:50 +0100 <kuribas> ph88: that is, if the thing you fold is also lazy, like a list
2021-01-15 11:12:03 +0100 <kuribas> ph88: like map, filter, etc...
2021-01-15 11:12:11 +0100 <ph88> merijn, i get the idea conceptually i have some problems coming up with good examples to show this point
2021-01-15 11:12:12 +0100 <dminuoso> Or if the memory efficiency impacts you negatively
2021-01-15 11:12:37 +0100 <dminuoso> ph88: One example where strictness hurts is lists.
2021-01-15 11:12:42 +0100 <opqdonut> a strict pipeline of map-filter-map-filter will keep all of your data in memory
2021-01-15 11:12:47 +0100 <opqdonut> a lazy one is O(1)
2021-01-15 11:12:51 +0100 <kritzefitz> Sure, from an interface perspective its mostly irrelevant. But the people who implemented those systems that use UTF16 (e.g. the authors of ICU) had to have some reason to use UTF16 instead of UTF8. I just assumed that the reason was, that UTF16 is better suited for the task than UTF8, but apparently that was wrong.
2021-01-15 11:12:56 +0100 <kritzefitz> merijn, ^
2021-01-15 11:13:08 +0100 <opqdonut> in a strict world you need something like iteratees to get nice streaming behaviour
2021-01-15 11:13:11 +0100 <ph88> opqdonut, ah thanks ! that's a good example
2021-01-15 11:13:16 +0100 <kuribas> ph88: however, lazyness is mostly a design feature, not a performance feature.
2021-01-15 11:13:20 +0100 <mniip> in the modern world, a truly modern solution would be UTF32
2021-01-15 11:13:21 +0100 <dminuoso> ph88: In Haskell, we often tend to think of lists as encoding control flow (rather than data). So it being lazy makes it more modular
2021-01-15 11:13:22 +0100 <opqdonut> I guess even in haskell if you want reliable/provable streaming, you need conduits/pipes
2021-01-15 11:13:29 +0100 <mniip> "just buy more memory"
2021-01-15 11:13:32 +0100 <merijn> mniip: >:(
2021-01-15 11:13:35 +0100 <ph88> thanks dminuoso
2021-01-15 11:13:40 +0100 <dminuoso> merijn: And buy larger cache lines too? :)
2021-01-15 11:13:45 +0100 <dminuoso> Err mniip ^-
2021-01-15 11:13:49 +0100 <mniip> sure
2021-01-15 11:13:54 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56)
2021-01-15 11:14:01 +0100christo(~chris@81.96.113.213) (Ping timeout: 264 seconds)
2021-01-15 11:14:04 +0100 <merijn> kritzefitz: Well, "better suited for the task at the time the task was implemented" ;)
2021-01-15 11:14:48 +0100 <kuribas> ph88: the goal of lazyness is to make elegant code, without having to sacrifice to much efficiency. However if you want supreme performance, than you better write ugly ass low level C code.
2021-01-15 11:15:25 +0100 <dminuoso> ph88: Another example where lazyness is beneficial, is bindings that are possibly not used.
2021-01-15 11:15:38 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 11:16:33 +0100 <MorrowM> head . sort comes to mind
2021-01-15 11:17:18 +0100 <mniip> my CPU cache fits my entire kernel and loaded modules
2021-01-15 11:17:37 +0100 <ph88> MorrowM, cool example =)
2021-01-15 11:17:41 +0100 <mniip> (their text)
2021-01-15 11:18:05 +0100 <kuribas> ph88: the tradeoff that haskell and lazyness gives you is high level code with fairly good performance. Other languages give you the choice between very good performance and low level code, or very bad performance and high level code.
2021-01-15 11:18:29 +0100 <dminuoso> I mean the cache line bit is quite interesting actually. In a worst case, where we assume UTF-16 to waste *half* the memory, you waste half your cache too, and it doubles memory accesses..
2021-01-15 11:18:46 +0100 <mniip> easy
2021-01-15 11:18:49 +0100 <mniip> just transpose your string
2021-01-15 11:18:52 +0100 <dminuoso> haha
2021-01-15 11:19:18 +0100 <ph88> kuribas, how is that done in other languages that you can't have high level code with fairly good performancce? I thought other languages also have good solutions
2021-01-15 11:19:28 +0100christo(~chris@81.96.113.213)
2021-01-15 11:19:35 +0100 <kuribas> ph88: I see this in common lisp, our code is supposed to be high level, but it is littered with small hacks for "performance", which make the code a lot less readable.
2021-01-15 11:19:55 +0100 <dminuoso> ph88: You'd implement the lazyness ad-hoc manually by means of conditional code execution
2021-01-15 11:20:02 +0100 <dminuoso> Or maybe not at all
2021-01-15 11:20:25 +0100 <mniip> makes me wonder if writing a byte to a cacheline that is already there marks the cacheline as modified
2021-01-15 11:20:31 +0100 <kuribas> ph88: what a java programmer considers "good" and "high level" is different from what a haskell programmer does.
2021-01-15 11:20:46 +0100 <dminuoso> Consider writing something like `f x s t = if x > 10 then s else t` where the second argument to `f` is a very expensive computation
2021-01-15 11:21:03 +0100 <dminuoso> In Haskell you dont even have to think about it, and you pay for the price of the second argument only when you need it
2021-01-15 11:21:13 +0100 <dminuoso> In strict world, this needs to be done explicitly
2021-01-15 11:21:16 +0100 <opqdonut> yeah, laziness obviates macros
2021-01-15 11:21:23 +0100 <opqdonut> for implementing basic flow-control
2021-01-15 11:21:38 +0100zangi(~azure@103.154.230.250)
2021-01-15 11:21:44 +0100LKoen(~LKoen@119.169.9.109.rev.sfr.net)
2021-01-15 11:21:53 +0100 <kuribas> opqdonut: good point, I find that most macros in lisp can be just done using the language in haskell.
2021-01-15 11:22:10 +0100 <kuribas> and are also way more readable
2021-01-15 11:22:13 +0100 <kuribas> and easier to debug
2021-01-15 11:22:32 +0100 <opqdonut> yes
2021-01-15 11:22:37 +0100 <opqdonut> cheap HOFs and laziness
2021-01-15 11:23:26 +0100 <zangi> can anyone explain why f keeps going on forever `f = [1..9] <|> f`, while g stops at first sequence `g = (pure [1..9]) <|> g`?
2021-01-15 11:23:29 +0100 <kuribas> the lisp way of making DSLs is using macros and lists with symbols.
2021-01-15 11:23:30 +0100 <dminuoso> mniip: Mmm, that would introduce latency to all writes, wouldn't it?
2021-01-15 11:23:48 +0100 <dminuoso> Unless there was specialized circuitry that would detect a copy-write
2021-01-15 11:23:51 +0100 <merijn> zangi: Those use different Alternative instances
2021-01-15 11:23:55 +0100christo(~chris@81.96.113.213) (Ping timeout: 246 seconds)
2021-01-15 11:24:06 +0100 <kuribas> :t let g = pure [1..9] <|> g in g
2021-01-15 11:24:08 +0100 <lambdabot> (Alternative f, Num a, Enum a) => f [a]
2021-01-15 11:24:17 +0100christo(~chris@81.96.113.213)
2021-01-15 11:24:23 +0100 <merijn> zangi: in ghci?
2021-01-15 11:24:24 +0100xsperry(~as@unaffiliated/xsperry) ()
2021-01-15 11:24:37 +0100merijnputs $10 on "uses the Alternative of IO"
2021-01-15 11:24:47 +0100 <zangi> merijn: yeah
2021-01-15 11:25:19 +0100 <kuribas> opqdonut: but then, unlike haskell, lisp doesn't provide any way to describe how these macros or symbol lists need to be formed.
2021-01-15 11:25:38 +0100 <opqdonut> indeed
2021-01-15 11:25:38 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Read error: Connection reset by peer)
2021-01-15 11:26:15 +0100 <merijn> zangi: The 'g' example is using pure to "put" a list into *an* Alternative and ghci just happens to pick IO (which succeeds and ends)
2021-01-15 11:26:15 +0100 <zangi> merijn: how do I make `g` last forever?
2021-01-15 11:26:34 +0100 <kuribas> opqdonut: in the end, you mess around on the repl, and dig in the source code, but IMO that's not "high level programming".
2021-01-15 11:26:36 +0100 <merijn> zangi: The first version uses the Alternative instance of "[]" which is just concat
2021-01-15 11:26:48 +0100 <merijn> So 'f' is just 'f = [1..9] ++ f'
2021-01-15 11:27:26 +0100 <zangi> merijn: is there (++) for `IO [Int]`?
2021-01-15 11:27:39 +0100 <dibblego> @liftA2 (++)
2021-01-15 11:27:40 +0100 <lambdabot> Unknown command, try @list
2021-01-15 11:27:43 +0100 <dibblego> @type liftA2 (++)
2021-01-15 11:27:44 +0100 <lambdabot> Applicative f => f [a] -> f [a] -> f [a]
2021-01-15 11:27:46 +0100 <merijn> What are you trying to *actually* do
2021-01-15 11:27:49 +0100 <kuribas> opqdonut: or in other words, people have different opinions on what "high level code" means.
2021-01-15 11:28:08 +0100 <merijn> What does "making 'g' go forever" even mean?
2021-01-15 11:28:13 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-exqmmrztjppnvoxd) (Quit: Connection closed for inactivity)
2021-01-15 11:28:42 +0100 <kuribas> maybe he wants liftA2 (<|>) ?
2021-01-15 11:28:53 +0100 <merijn> Maybe
2021-01-15 11:28:58 +0100 <merijn> Maybe he wants a pony
2021-01-15 11:29:06 +0100 <merijn> I'm not psychic
2021-01-15 11:29:12 +0100 <zangi> merijn: I want to generate random numbers which consists of [1..9]s
2021-01-15 11:29:19 +0100 <kuribas> :t let g = liftA2 (<|>) (pure [1..9]) g in g
2021-01-15 11:29:20 +0100 <lambdabot> (Applicative f, Num a, Enum a) => f [a]
2021-01-15 11:29:25 +0100 <merijn> I can come up within infinitely many expressions that match his type
2021-01-15 11:29:46 +0100 <mniip> merijn, how many non-extensionally-equivalent :P
2021-01-15 11:29:46 +0100 <merijn> > randomRs (1,9) (mkStdgen 42)
2021-01-15 11:29:48 +0100 <lambdabot> error:
2021-01-15 11:29:48 +0100 <lambdabot> • Variable not in scope: mkStdgen :: t0 -> g0
2021-01-15 11:29:48 +0100 <lambdabot> • Perhaps you meant ‘mkStdGen’ (imported from System.Random)
2021-01-15 11:29:52 +0100 <merijn> bah
2021-01-15 11:29:57 +0100 <kritzefitz> merijn, yes I don't want to say it was a bad choice. But when looking at design a choice that was good at the time, it makes a difference if the choice would still be good today or if you would make a different choice today. As I understand it now, UTF16 for ICu seems to fall in the second category.
2021-01-15 11:30:00 +0100 <merijn> > randomRs (1,9) (System.Random.mkStdgen 42)
2021-01-15 11:30:05 +0100 <lambdabot> error:
2021-01-15 11:30:05 +0100 <lambdabot> Not in scope: ‘System.Random.mkStdgen’
2021-01-15 11:30:05 +0100 <lambdabot> Perhaps you meant one of these:
2021-01-15 11:30:09 +0100 <mniip> capital G
2021-01-15 11:30:11 +0100 <mniip> it even tells you
2021-01-15 11:30:14 +0100 <merijn> oh, doh
2021-01-15 11:30:18 +0100 <merijn> > randomRs (1,9) (System.Random.mkStdGen 42)
2021-01-15 11:30:20 +0100 <lambdabot> [1,8,1,3,2,8,5,3,6,9,3,9,2,1,3,3,9,3,3,9,1,7,9,8,6,7,4,2,7,1,3,2,7,4,8,5,3,8...
2021-01-15 11:30:26 +0100 <merijn> mniip: Pfft, who reads errors?
2021-01-15 11:30:32 +0100 <mniip> I do :<
2021-01-15 11:30:34 +0100 <kuribas> let g = liftA2 (<|>) (pure [1..9]) g in g :: Const "pony"
2021-01-15 11:30:39 +0100 <kuribas> > let g = liftA2 (<|>) (pure [1..9]) g in g :: Const "pony"
2021-01-15 11:30:41 +0100 <lambdabot> error:
2021-01-15 11:30:41 +0100 <lambdabot> • Expecting one more argument to ‘Const "pony"’
2021-01-15 11:30:41 +0100 <lambdabot> Expected a type, but ‘Const "pony"’ has kind ‘k0 -> *’
2021-01-15 11:30:55 +0100 <kuribas> > let g = liftA2 (<|>) (pure [1..9]) g in g :: Const "pony" [Int]
2021-01-15 11:30:57 +0100 <lambdabot> error:
2021-01-15 11:30:58 +0100 <lambdabot> • Expected a type, but ‘"pony"’ has kind ‘GHC.Types.Symbol’
2021-01-15 11:30:58 +0100 <lambdabot> • In the first argument of ‘Const’, namely ‘"pony"’
2021-01-15 11:30:58 +0100 <merijn> zangi: If you want random numbers you want randomRs
2021-01-15 11:31:04 +0100 <merijn> :t randomRs
2021-01-15 11:31:05 +0100 <lambdabot> (Random a, RandomGen g) => (a, a) -> g -> [a]
2021-01-15 11:31:27 +0100 <mniip> I think they mean generating the sequence of all finite sequences of [1..9]
2021-01-15 11:31:50 +0100 <ph88> what are the tradeoffs between Map and HashMap ?
2021-01-15 11:32:10 +0100 <zangi> each [1..9] has to be unique, i.e [6,9,2,4,3,8,1,7,5] and not [8,9,8,4,8,8,1,8,5]
2021-01-15 11:32:37 +0100 <merijn> ph88: The trade-offs are "just use Map, because unless you know why you should there's no real reason to use HashMap"
2021-01-15 11:33:04 +0100 <ph88> please tell me why i should
2021-01-15 11:33:13 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 264 seconds)
2021-01-15 11:33:29 +0100fendor(~fendor@178.115.129.78.wireless.dyn.drei.com)
2021-01-15 11:33:43 +0100 <merijn> "Your key doesn't have an Ord instance" and possibly "you have a hash function that's cheaper than compare"
2021-01-15 11:34:02 +0100guest111`(~user@49.5.6.87) (Remote host closed the connection)
2021-01-15 11:34:32 +0100 <ph88> thanks
2021-01-15 11:35:57 +0100 <merijn> The worst case complexity of HashMaps is worse, their space usage is worse, seems like they'd be tricky to implement immutably too (but that's a problem for the implementers)
2021-01-15 11:36:18 +0100 <merijn> And in general "balanced search trees" are just "pretty damn good and everone should stop hating on them"
2021-01-15 11:36:47 +0100 <opqdonut> for slightly better performance it's best to have k-ary trees with a nice k
2021-01-15 11:36:54 +0100 <opqdonut> e.g. IntMap does this
2021-01-15 11:36:55 +0100 <mniip> a lot of the time I even use Map instead of Array
2021-01-15 11:37:06 +0100 <opqdonut> yeah, same here
2021-01-15 11:37:06 +0100 <kuribas> merijn: hashmap is also a balanced search tree
2021-01-15 11:37:13 +0100 <kuribas> merijn: it just hashes first
2021-01-15 11:37:26 +0100 <mniip> hashmap is more like IntMap than like Map
2021-01-15 11:37:43 +0100 <int-e> zangi: to produce a random permutation of a list, select one of its elements at random as the first element, then append a random permutation of the remaining elements. Or use a ready-made implementation like https://hackage.haskell.org/package/random-shuffle-0.0.4/docs/System-Random-Shuffle.html
2021-01-15 11:37:55 +0100 <mniip> which, I forget, is there an Integer-keyed radix tree somewhere on hackage?
2021-01-15 11:38:21 +0100 <merijn> mniip: lol, so it doesn't even have the (oversold, underdelivering) O(1) best case complexity?
2021-01-15 11:38:28 +0100 <int-e> https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle is relevant as well, but not too friendly towards a language with immutable data like Haskell.
2021-01-15 11:38:41 +0100 <merijn> Fisher-Yates!
2021-01-15 11:38:51 +0100mastarija(~mastarija@93-136-6-188.adsl.net.t-com.hr)
2021-01-15 11:38:51 +0100 <merijn> One of the most useful and easy algorithms I've learned
2021-01-15 11:38:59 +0100thc202(~thc202@unaffiliated/thc202)
2021-01-15 11:39:05 +0100 <int-e> merijn: of course it does, since the word size and hence the depth of the trie is bounded by a constant
2021-01-15 11:39:17 +0100 <mniip> "Many operations have a average-case complexity of O(log n). The implementation uses a large base (i.e. 16) so in practice these operations are constant time."
2021-01-15 11:39:20 +0100int-ehas a terrible feeling of deja vu
2021-01-15 11:39:39 +0100 <merijn> int-e: By that logic any operation is O(1)
2021-01-15 11:39:44 +0100 <opqdonut> merijn: I was surprised that it has a fancy name, feels like the obvious way
2021-01-15 11:39:47 +0100 <int-e> . o O ( On a real computer, everything either fails to terminate or is O(1). )
2021-01-15 11:39:48 +0100 <merijn> int-e: All data structures are bounded by memory!
2021-01-15 11:39:50 +0100 <mniip> hashmaps with "O"("1") access are inherently not persistent
2021-01-15 11:39:58 +0100 <int-e> merijn: I was getting there.
2021-01-15 11:40:03 +0100 <opqdonut> merijn: or rather, I remember being surprised - -
2021-01-15 11:40:06 +0100 <mniip> and thus can only exist in State#
2021-01-15 11:40:27 +0100 <int-e> mniip: DiffArray ... *runs*
2021-01-15 11:41:26 +0100 <int-e> (Those are no longer popular, fortunately. They're such a terrible, and amazingly expensive, hack.)
2021-01-15 11:41:52 +0100 <merijn> Fisher-Yates + STVector works well, though
2021-01-15 11:42:30 +0100 <int-e> opqdonut: what's interesting about hashmap is that it has its own implementation of a Word-indexed map instead of using Data.IntMap, presumably for performance reason.
2021-01-15 11:42:33 +0100 <int-e> *s
2021-01-15 11:43:30 +0100 <mniip> I wonder, is union-find inherently non-persistent as well
2021-01-15 11:43:32 +0100 <kuribas> merijn: any O(log(n)) where n is a physical quantity is O(1).
2021-01-15 11:43:46 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 11:44:09 +0100 <kuribas> merijn: because physical quantities are limited, and the logarithm is a small upper bound.
2021-01-15 11:44:09 +0100 <mniip> kuribas, all algorithms are Omega(sqrt(n)) where n is input size
2021-01-15 11:44:24 +0100pevby(5fa87469@95.168.116.105)
2021-01-15 11:45:11 +0100pevby(5fa87469@95.168.116.105) (Client Quit)
2021-01-15 11:45:39 +0100Alleria(~textual@zrcout.mskcc.org)
2021-01-15 11:45:41 +0100 <mniip> combining the Bekenshtein bound with the Swarzchild bound with the speed of light bound, if you have n bits of memory it takes at least sqrt(n) time to access them
2021-01-15 11:45:47 +0100ubert(~Thunderbi@p200300ecdf1ee06ce6b318fffe838f33.dip0.t-ipconnect.de)
2021-01-15 11:45:56 +0100 <kuribas> mniip: how is sum x O(sqrt(n)) ?
2021-01-15 11:46:03 +0100AlleriaGuest57013
2021-01-15 11:46:06 +0100 <mniip> otherwise your computer collapses into a black hole
2021-01-15 11:46:11 +0100 <kuribas> mniip: wouldn't that be at least O(n) ?
2021-01-15 11:46:17 +0100 <int-e> merijn: On a real computer the idea that hashtables have O(1) access is silly given the profound effect that an increased working set size has on caches, and hence memory access time. A trie will be somewhat worse, but you can expect the top levels to be cached, so it's not *much* worse.
2021-01-15 11:46:46 +0100 <merijn> On a *real* computer big O is all a bunch of hokum and lies
2021-01-15 11:46:49 +0100 <dminuoso> mniip: Mmm, we had this discussions a few times in here now. I heard some convincing arguments, that the blackhole idea is misleading in the wrong way.
2021-01-15 11:47:09 +0100 <merijn> "Oh, my entire model is predicated on assumptions that fundamentally untrue and have been over 3 decades!"
2021-01-15 11:47:48 +0100 <dminuoso> The blog articles (which Im sure you're referring to) make some arguments that this notion of memmory access is sqrt(n) has merits, because it matches real world data.
2021-01-15 11:48:03 +0100 <merijn> Big O is all lies! It's a conspiracy for math nerds to ask you tricky math questions instead of real world...
2021-01-15 11:48:16 +0100merijnis dragged of my the men in white suits and non-descript vans
2021-01-15 11:48:25 +0100 <mniip> dminuoso, not really
2021-01-15 11:48:26 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 240 seconds)
2021-01-15 11:48:34 +0100 <int-e> merijn: The actual argument should be that hashtables are expected to be faster because they usually get an access done in a single memory access where traversing a trie needs several.
2021-01-15 11:48:35 +0100 <mniip> I'm just referring to three formulas from physics
2021-01-15 11:48:42 +0100 <int-e> No O(), just plain numbers.
2021-01-15 11:48:43 +0100 <merijn> Big O is fake news (fake theorems?)
2021-01-15 11:49:12 +0100 <int-e> (ignoring the computation of the hash, which both hash tables and hashmap will have to do anyway)
2021-01-15 11:49:37 +0100 <int-e> (and a couple of other things, like checking the key, which again, both approaches have to do)
2021-01-15 11:51:43 +0100DavidEichmann(~david@234.109.45.217.dyn.plus.net)
2021-01-15 11:52:00 +0100 <mniip> bekenshtein bound gives R > k1 I / M, swarzchild bound gives M < k2 R; together R > k1 I / k2 R, i.e. R^2 > k1 I / k2. Light speed bound gives t > c R, giving t > c sqrt(k1 I / k2)
2021-01-15 11:52:08 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3a8e:d956:f43e:d9a3:9155)
2021-01-15 11:52:53 +0100 <mniip> where k1 = hbar ln2 / 2 pi c, k2 = c^2 / 2G
2021-01-15 11:53:42 +0100 <dminuoso> mniip: So the entire argument revolves around the idea, that we should use the physical laws as a model, because that's where be build computers in. So complexity analysis should take them into account, because they tell us about bounds of algorithms, executed on computers built in this reality. Right?
2021-01-15 11:53:51 +0100 <mniip> not really
2021-01-15 11:53:59 +0100 <mniip> I'm not being 100% serious here
2021-01-15 11:54:08 +0100 <dminuoso> Oh.
2021-01-15 11:54:27 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 11:54:49 +0100 <mniip> the unironical issue here is that asymptotic analysis gives behavior "at infinity" and some functions behave differently at different scales before settling down to some behavior at infinity, and we don't really have the tools to talk about intermediate behaviors
2021-01-15 11:54:55 +0100 <mniip> at least not commonly known tools
2021-01-15 11:56:38 +0100 <merijn> mniip: I think my issue is even more crucial :p
2021-01-15 11:57:00 +0100 <merijn> Which is that *asymptotic behaviour of big O is absolute bogus on any computer anyone actually uses*
2021-01-15 11:57:11 +0100 <mniip> that's kinda what I said?
2021-01-15 11:57:29 +0100 <mniip> you wanna know how your function behaves in the 1-1e12 range or so
2021-01-15 11:57:46 +0100 <merijn> mniip: Well, your comment is "we don't have the tools to talk at range smaller then the asymptotic"
2021-01-15 11:58:10 +0100 <merijn> My comment is "the asymptotic is a lie, so we don't even have ways to talk about stuff 'at infinity' *either*"
2021-01-15 11:58:21 +0100 <mniip> we don't?
2021-01-15 11:58:31 +0100 <nshepperd> in practical engineering big O is just an excuse to do what we normally do, which is dropping terms which look like they'd be small enough to not matter at the values of n we care about
2021-01-15 11:58:43 +0100 <merijn> mniip: Well no, because Big O asymptotics assume uniform random access, which we don't have
2021-01-15 11:58:43 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 11:58:53 +0100 <mniip> ah
2021-01-15 11:58:54 +0100 <mniip> that
2021-01-15 11:58:55 +0100 <merijn> mniip: And you can't approximate it by averaging either
2021-01-15 11:59:17 +0100 <mniip> yea I wasn't including a computation model as part of the problem
2021-01-15 11:59:18 +0100 <merijn> Because you (can) get non-linear affects based on your access pattern
2021-01-15 11:59:26 +0100 <mniip> I was thinking about just functions N -> N
2021-01-15 11:59:26 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 11:59:46 +0100 <merijn> In which case it all just crumbles to pieces leaving almost nothing useful :p
2021-01-15 11:59:55 +0100 <kuribas> merijn: but O notation doesn't measure time, does it?
2021-01-15 12:00:03 +0100 <kuribas> merijn: it measures number of operations
2021-01-15 12:00:12 +0100jb55(~jb55@gateway/tor-sasl/jb55) (Read error: Connection reset by peer)
2021-01-15 12:00:12 +0100andreas303(~andreas@gateway/tor-sasl/andreas303) (Remote host closed the connection)
2021-01-15 12:00:12 +0100hexo(~hexo@gateway/tor-sasl/hexo) (Remote host closed the connection)
2021-01-15 12:00:12 +0100cantstanya(~chatting@gateway/tor-sasl/cantstanya) (Remote host closed the connection)
2021-01-15 12:00:12 +0100jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2021-01-15 12:00:12 +0100srk(~sorki@gateway/tor-sasl/sorki) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100gxt(~gxt@gateway/tor-sasl/gxt) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100denisse(~spaceCat@gateway/tor-sasl/alephzer0) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100vgtw(~vgtw@gateway/tor-sasl/vgtw) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100livvy(~livvy@gateway/tor-sasl/livvy) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Write error: Broken pipe)
2021-01-15 12:00:12 +0100ChaiTRex(~ChaiTRex@gateway/tor-sasl/chaitrex) (Remote host closed the connection)
2021-01-15 12:00:13 +0100tomboy64(~tomboy64@gateway/tor-sasl/tomboy64) (Write error: Broken pipe)
2021-01-15 12:00:15 +0100 <mniip> that depends on your computation model
2021-01-15 12:00:17 +0100 <merijn> kuribas: Yes, but it assume operations take the same time
2021-01-15 12:00:18 +0100 <kuribas> or space
2021-01-15 12:00:26 +0100 <merijn> kuribas: and generally the operation is "memory access"
2021-01-15 12:00:33 +0100 <kuribas> merijn: I don't think it does, because it's a mathematial model
2021-01-15 12:00:39 +0100 <merijn> kuribas: But neither our operations *nor* our memory access are uniform
2021-01-15 12:00:58 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-01-15 12:01:00 +0100 <mniip> we assume that memory access and operations are bounded by a constant
2021-01-15 12:01:10 +0100 <mniip> which is problematic for large enough n
2021-01-15 12:01:10 +0100 <merijn> kuribas: If you don't assume operations correspond to some time (or other cost) what does "f(x) > g(x)" tell you?
2021-01-15 12:01:44 +0100 <kuribas> merijn: that f(x) is bigger than g(x)?
2021-01-15 12:01:46 +0100 <merijn> kuribas: If f(x) does less operations, but they all take 10x the time as the operations of g(x), the entire comparison is useless
2021-01-15 12:01:57 +0100 <merijn> kuribas: Right, but that assumes the numbers are comparable
2021-01-15 12:02:08 +0100 <kuribas> merijn: what is f(x) here?
2021-01-15 12:02:13 +0100 <merijn> Which is only the case if there is a constant or uniform cost
2021-01-15 12:02:29 +0100 <kuribas> merijn: that formula tells me nothing
2021-01-15 12:02:42 +0100 <kuribas> because I don't know what f does, what the type of f or x is...
2021-01-15 12:02:42 +0100livvy(~livvy@gateway/tor-sasl/livvy)
2021-01-15 12:02:48 +0100srk(~sorki@gateway/tor-sasl/sorki)
2021-01-15 12:02:48 +0100hexo(~hexo@gateway/tor-sasl/hexo)
2021-01-15 12:02:59 +0100 <merijn> kuribas: We have algorithm 'f' which has some asymptotic and algorithm 'g' which has a "worse" asymptotic (i.e. does more operations)
2021-01-15 12:03:05 +0100ChaiTRex(~ChaiTRex@gateway/tor-sasl/chaitrex)
2021-01-15 12:03:06 +0100denisse(~spaceCat@gateway/tor-sasl/alephzer0)
2021-01-15 12:03:10 +0100 <nshepperd> big O notation can measure whatever you want
2021-01-15 12:03:12 +0100fradet(~glenda@216.252.75.247)
2021-01-15 12:03:13 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2021-01-15 12:03:25 +0100 <opqdonut> like with all theory, you have to squint a bit to make the analogies with the real world work
2021-01-15 12:03:25 +0100gxt(~gxt@gateway/tor-sasl/gxt)
2021-01-15 12:03:26 +0100jb55(~jb55@gateway/tor-sasl/jb55)
2021-01-15 12:03:27 +0100 <merijn> kuribas: How can you compare these asymptotic results if you don't assume the cost of operations is constant for 'f' and 'g'?
2021-01-15 12:03:34 +0100xelxebar(~xelxebar@gateway/tor-sasl/xelxebar)
2021-01-15 12:03:39 +0100jpds(~jpds@gateway/tor-sasl/jpds)
2021-01-15 12:03:51 +0100 <mniip> you can compare them if you know that the cost of operations is bounded
2021-01-15 12:03:53 +0100 <merijn> kuribas: If you *don't* assume constant cost (as you said) you can't compare these and the asymptotic is useless
2021-01-15 12:03:58 +0100 <opqdonut> something like O(n) is just short hand for thinking about how much work something does
2021-01-15 12:03:59 +0100 <kuribas> merijn: you cannot, without benchmarking it.
2021-01-15 12:04:01 +0100 <merijn> mniip: Right, but you don't know that either!
2021-01-15 12:04:03 +0100 <opqdonut> if you're a programmer, that is
2021-01-15 12:04:17 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 12:04:27 +0100 <opqdonut> staring too finely at the asymptotics of fancy datastructures will probably go wrong, but everybody kinda knows that, right?
2021-01-15 12:04:27 +0100 <merijn> opqdonut: That's the only semi-useful thing about big O, sloppy programmer shorthand :p
2021-01-15 12:04:33 +0100 <kuribas> merijn: however, it does make sense to try convert O(n) to O(log n), and then check that the second is faster.
2021-01-15 12:04:37 +0100 <merijn> opqdonut: Lol, optimist
2021-01-15 12:04:43 +0100 <opqdonut> at least everybody I talk to
2021-01-15 12:04:46 +0100 <merijn> opqdonut: There's tons of people these things are true
2021-01-15 12:04:52 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 246 seconds)
2021-01-15 12:04:59 +0100 <merijn> opqdonut: You must be talking to the upper quantile of programmers ;)
2021-01-15 12:05:03 +0100 <merijn> anyway, lunch
2021-01-15 12:05:09 +0100 <kuribas> merijn: I mean, O notation isn't the whole story, but it's still part of the story...
2021-01-15 12:05:10 +0100 <mniip> sorting a list of 200 elements is very hard
2021-01-15 12:05:26 +0100 <kuribas> merijn: and still something programmers should know
2021-01-15 12:05:37 +0100 <int-e> kuribas: in the end you benchmark and pick the code that is fastest, hoping that the benchmarks were a good model of the real life applications you'll encounter.
2021-01-15 12:05:57 +0100 <opqdonut> indeed
2021-01-15 12:06:32 +0100 <kuribas> int-e: and you also want to take malicious attacks into account.
2021-01-15 12:06:37 +0100 <int-e> You may use big O for extrapolation, while keeping an eye on the memory hierarchy.
2021-01-15 12:06:40 +0100 <mniip> how did we go from hashtables to philosophy of mathematical modeling
2021-01-15 12:06:54 +0100 <int-e> kuribas: I don't *want* to! ;-)
2021-01-15 12:07:14 +0100 <kuribas> int-e: you can say, it's O(n^2), but the input is small. But what if someone deliberately sends you a large input set to bring down the service?
2021-01-15 12:07:27 +0100 <int-e> kuribas: use UDP ;-)
2021-01-15 12:07:29 +0100 <kuribas> int-e: right, you may need to then...
2021-01-15 12:07:41 +0100ubert(~Thunderbi@p200300ecdf1ee06ce6b318fffe838f33.dip0.t-ipconnect.de) (Quit: ubert)
2021-01-15 12:07:48 +0100 <kuribas> int-e: how does that solve it?
2021-01-15 12:07:56 +0100 <int-e> kuribas: limited package size ;)
2021-01-15 12:08:02 +0100ubert(~Thunderbi@p200300ecdf1ee06ce02324fb94e406b3.dip0.t-ipconnect.de)
2021-01-15 12:08:03 +0100 <int-e> packet, I mean
2021-01-15 12:08:03 +0100hekkaidekapus{(~tchouri@gateway/tor-sasl/hekkaidekapus)
2021-01-15 12:08:11 +0100 <kuribas> ok, you could truncate the input if it gets to big...
2021-01-15 12:08:16 +0100 <mniip> imagine offering turing incomplete services
2021-01-15 12:08:32 +0100 <int-e> mniip: ...you mean like in real life?
2021-01-15 12:09:02 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 12:09:13 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se) (Ping timeout: 264 seconds)
2021-01-15 12:11:13 +0100 <int-e> . o O ( "sorting a list of 200 elements is very hard" -- you could start practicing with a deck of 52 cards and then work your way up to 200 )
2021-01-15 12:12:13 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 12:12:16 +0100pera(pera@gateway/vpn/mullvad/pera) (Quit: leaving)
2021-01-15 12:12:30 +0100 <mniip> I mean like, doing it efficiently
2021-01-15 12:12:54 +0100daGrevis(~daGrevis@unaffiliated/dagrevis) (Remote host closed the connection)
2021-01-15 12:13:00 +0100 <mniip> it's in that weird area between precomputed sort nets and when logarithmic asymptotic of quicksort kicks in
2021-01-15 12:13:22 +0100 <int-e> kuribas: well, thanks to you I'm now reminiscing about a pattern matching incident where I asked for matches of foo********bar... which turned out to be handled by a backtracking regexp implementation.
2021-01-15 12:13:52 +0100 <int-e> It wasn't even deliberate.
2021-01-15 12:13:57 +0100 <ph88> merijn, here it says that HashMap has more efficient space and time performance http://dev.stephendiehl.com/hask/#unordered-containers
2021-01-15 12:14:02 +0100 <kuribas> int-e: what was that supposed to do?
2021-01-15 12:14:23 +0100 <int-e> kuribas: the same as foo*bar, of course
2021-01-15 12:14:35 +0100 <kuribas> int-e: did you cat run over the keyboard?
2021-01-15 12:14:53 +0100 <int-e> kuribas: emacs was involved, I hit M-8 instead of S-8 so the * came out 8 times in a row
2021-01-15 12:15:07 +0100 <mniip> a `concat <$> many (many p)` will generally perform worse than `many p`
2021-01-15 12:15:08 +0100 <int-e> I glanced at it, decided it should be equivalent.
2021-01-15 12:15:11 +0100 <mniip> even though the two are equivalent
2021-01-15 12:15:27 +0100 <int-e> And waited. And waited. And then realization dawned :)
2021-01-15 12:16:09 +0100gehmehgeh(~ircuser1@gateway/tor-sasl/gehmehgeh)
2021-01-15 12:16:13 +0100vgtw(~vgtw@gateway/tor-sasl/vgtw)
2021-01-15 12:16:50 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 12:21:53 +0100andrew_znc(~andrew@andrewyu.org) (Changing host)
2021-01-15 12:21:53 +0100andrew_znc(~andrew@unaffiliated/andrew-znc)
2021-01-15 12:24:41 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 12:24:46 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 12:25:05 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds)
2021-01-15 12:25:19 +0100andreas303(~andreas@gateway/tor-sasl/andreas303)
2021-01-15 12:25:50 +0100son0p(~son0p@181.58.39.182)
2021-01-15 12:25:59 +0100tomboy64(~tomboy64@gateway/tor-sasl/tomboy64)
2021-01-15 12:27:00 +0100cantstanya(~chatting@gateway/tor-sasl/cantstanya)
2021-01-15 12:27:17 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-01-15 12:29:48 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 260 seconds)
2021-01-15 12:30:23 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 256 seconds)
2021-01-15 12:31:03 +0100gxt(~gxt@gateway/tor-sasl/gxt) (Ping timeout: 240 seconds)
2021-01-15 12:32:10 +0100andrew_znc(~andrew@unaffiliated/andrew-znc) ("WeeChat 2.3")
2021-01-15 12:32:12 +0100gxt(~gxt@gateway/tor-sasl/gxt)
2021-01-15 12:32:50 +0100petersen(~petersen@redhat/juhp)
2021-01-15 12:33:16 +0100jespada(~jespada@90.254.245.49) (Ping timeout: 240 seconds)
2021-01-15 12:33:31 +0100nullifidian(~nullifidi@unaffiliated/nullifidian)
2021-01-15 12:34:14 +0100cfricke(~cfricke@unaffiliated/cfricke) (Ping timeout: 264 seconds)
2021-01-15 12:34:29 +0100jespada(~jespada@90.254.245.49)
2021-01-15 12:37:44 +0100jmchael(~jmchael@87.112.235.234)
2021-01-15 12:38:40 +0100 <L29Ah> is it me or cabal-install ignores --package-db=clear? https://dpaste.com/2YYAQ8FBF
2021-01-15 12:42:02 +0100kini(~kini@unaffiliated/kini) (Ping timeout: 264 seconds)
2021-01-15 12:42:22 +0100kini(~kini@unaffiliated/kini)
2021-01-15 12:44:43 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 12:45:02 +0100m0rphism(~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de)
2021-01-15 12:47:55 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net) (Ping timeout: 246 seconds)
2021-01-15 12:49:36 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser) (Ping timeout: 246 seconds)
2021-01-15 12:49:50 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Ping timeout: 264 seconds)
2021-01-15 12:50:11 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net)
2021-01-15 12:50:23 +0100o1lo01ol1o(~o1lo01ol1@bl11-140-216.dsl.telepac.pt)
2021-01-15 12:53:40 +0100plutoniix(~q@184.82.197.202) (Quit: Leaving)
2021-01-15 12:54:20 +0100borne(~fritjof@200116b864d9bb00b67b1043029333d3.dip.versatel-1u1.de) (Quit: WeeChat 3.0)
2021-01-15 12:56:32 +0100borne(~fritjof@200116b864d9bb00a1d8c9ac4a9e7a6d.dip.versatel-1u1.de)
2021-01-15 12:56:34 +0100berberman_(~berberman@unaffiliated/berberman)
2021-01-15 12:57:02 +0100berberman(~berberman@unaffiliated/berberman) (Ping timeout: 264 seconds)
2021-01-15 12:59:24 +0100borne(~fritjof@200116b864d9bb00a1d8c9ac4a9e7a6d.dip.versatel-1u1.de) (Client Quit)
2021-01-15 12:59:41 +0100whyworxbutok(a7072803@167.7.40.3)
2021-01-15 13:01:50 +0100ericsagnes(~ericsagne@2405:6580:0:5100:ac2c:af5:4276:675d) (Ping timeout: 264 seconds)
2021-01-15 13:06:52 +0100__monty__(~toonn@unaffiliated/toonn)
2021-01-15 13:09:49 +0100maxsu(~maxsu@ip-64-72-99-232.lasvegas.net) (Ping timeout: 264 seconds)
2021-01-15 13:12:47 +0100drbean(~drbean@TC210-63-209-49.static.apol.com.tw)
2021-01-15 13:13:02 +0100MorrowM(~Moshe@bzq-110-168-31-106.red.bezeqint.net) (Quit: Leaving)
2021-01-15 13:14:20 +0100MorrowM(~Moshe@bzq-110-168-31-106.red.bezeqint.net)
2021-01-15 13:14:27 +0100ericsagnes(~ericsagne@2405:6580:0:5100:7035:540:bf28:536c)
2021-01-15 13:15:17 +0100ubert(~Thunderbi@p200300ecdf1ee06ce02324fb94e406b3.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2021-01-15 13:18:28 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-01-15 13:18:44 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-01-15 13:23:20 +0100 <zangi> is there a way to do `f (IO []) = IO []` like `f [] = []`?
2021-01-15 13:23:54 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr)
2021-01-15 13:24:08 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se)
2021-01-15 13:24:24 +0100Stanley00(~stanley00@unaffiliated/stanley00)
2021-01-15 13:25:30 +0100 <c_wraith> zangi: are you look for a function of type [IO a] -> IO [a] ?
2021-01-15 13:26:07 +0100 <c_wraith> zangi: IO isn't a constructor, so I'm not really sure what you're asking for.
2021-01-15 13:28:56 +0100 <kritzefitz> zangi, sounds to me like you want `f` to be polymorphic so it can be both `IO [a] -> IO [b]` or `[a] -> [b]`, depending on the type of its argument, correct?
2021-01-15 13:29:06 +0100Stanley00(~stanley00@unaffiliated/stanley00) (Ping timeout: 265 seconds)
2021-01-15 13:29:52 +0100 <zangi> something like this https://0x0.st/-z0F.txt
2021-01-15 13:30:02 +0100tsaka__(~torstein@athedsl-316921.home.otenet.gr)
2021-01-15 13:30:47 +0100ADG1089__(~aditya@122.163.165.143) (Remote host closed the connection)
2021-01-15 13:30:49 +0100todda7(~torstein@ppp-2-84-17-53.home.otenet.gr) (Ping timeout: 264 seconds)
2021-01-15 13:31:01 +0100zaquest(~notzaques@5.128.210.178)
2021-01-15 13:31:24 +0100 <kritzefitz> zangi, if you're trying to apply `f` to a value of type `getXs :: IO [a]`, you probably want `fmap f getXs`.
2021-01-15 13:33:02 +0100ADG1089__(~aditya@122.163.165.143)
2021-01-15 13:33:06 +0100 <zangi> I mean inside the f definition contains IO code
2021-01-15 13:34:31 +0100 <zangi> `f (x:xs) = x : f (turnsToIO xs)`
2021-01-15 13:39:37 +0100 <MorrowM> perhaps you want mapM/traverse
2021-01-15 13:39:56 +0100 <MorrowM> @type traverse
2021-01-15 13:39:58 +0100 <lambdabot> (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)
2021-01-15 13:40:06 +0100geekosaur(ac3a3b75@172.58.59.117)
2021-01-15 13:43:21 +0100cfricke(~cfricke@unaffiliated/cfricke)
2021-01-15 13:44:32 +0100xsperry(~as@unaffiliated/xsperry)
2021-01-15 13:45:42 +0100cfricke(~cfricke@unaffiliated/cfricke) (Client Quit)
2021-01-15 13:45:51 +0100cfricke(~cfricke@unaffiliated/cfricke)
2021-01-15 13:48:15 +0100 <kritzefitz> zangi, to me it also sounds like you want to use `traverse` or at least something similar. But your example doesn't really give me an idea of what your actual real-world problem is. So I can't make a more specific recommendation.
2021-01-15 13:52:04 +0100mastarija(~mastarija@93-136-6-188.adsl.net.t-com.hr) (Ping timeout: 260 seconds)
2021-01-15 13:53:06 +0100rayyyy(~nanoz@gateway/tor-sasl/nanoz)
2021-01-15 13:54:12 +0100 <zangi> kritzefitz: something like this https://0x0.st/-zGT.txt
2021-01-15 13:54:56 +0100_Alleria(~AllahuAkb@2603-7000-3040-0000-70d9-022a-866f-2250.res6.spectrum.com)
2021-01-15 13:55:03 +0100mouseghost(~draco@wikipedia/desperek)
2021-01-15 13:56:44 +0100ADG1089__(~aditya@122.163.165.143) (Remote host closed the connection)
2021-01-15 13:57:38 +0100Alleria_(~AllahuAkb@2603-7000-3040-0000-21c5-c900-9e1d-bf71.res6.spectrum.com) (Ping timeout: 264 seconds)
2021-01-15 13:58:00 +0100ADG1089__(~aditya@122.163.165.143)
2021-01-15 13:58:13 +0100rdivyanshu(uid322626@gateway/web/irccloud.com/x-fieuoudgdzkiaysv)
2021-01-15 14:01:34 +0100xsperry(~as@unaffiliated/xsperry) ()
2021-01-15 14:01:54 +0100ADG1089__(~aditya@122.163.165.143) (Remote host closed the connection)
2021-01-15 14:02:04 +0100ArConan(9de62a69@157.230.42.105)
2021-01-15 14:03:01 +0100ADG1089__(~aditya@122.163.165.143)
2021-01-15 14:03:03 +0100urodna(~urodna@unaffiliated/urodna)
2021-01-15 14:03:06 +0100cfricke(~cfricke@unaffiliated/cfricke) (Quit: WeeChat 3.0)
2021-01-15 14:05:56 +0100ADG1089__(~aditya@122.163.165.143) (Remote host closed the connection)
2021-01-15 14:06:26 +0100son0p(~son0p@181.58.39.182) (Quit: Lost terminal)
2021-01-15 14:07:01 +0100ADG1089__(~aditya@122.163.165.143)
2021-01-15 14:08:01 +0100zangi(~azure@103.154.230.250) (Ping timeout: 264 seconds)
2021-01-15 14:08:23 +0100zangi(~azure@103.154.230.250)
2021-01-15 14:11:03 +0100 <kritzefitz> zangi, from a type perspective https://gitlab.com/-/snippets/2061706 should work. However, I don't really understand what the function is supposed to do and when I try to run it, it either fails on the `!!` or doesn't terminate at all.
2021-01-15 14:11:38 +0100 <MorrowM> Are you trying to move a random element to the front of the list?
2021-01-15 14:11:59 +0100pera(~pera@unaffiliated/pera)
2021-01-15 14:12:37 +0100cfricke(~cfricke@unaffiliated/cfricke)
2021-01-15 14:13:22 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 14:13:43 +0100 <MorrowM> Consider separating your pure logic into a function, something like `baz :: Eq a => Int -> [a] -> [a]` and then use bind `(>>=)` to pass in a random number
2021-01-15 14:14:31 +0100ubert(~Thunderbi@p200300ecdf1ee06ce02324fb94e406b3.dip0.t-ipconnect.de)
2021-01-15 14:16:02 +0100 <ukari> I found there is a hack way to overlapping instance with constraint for only two types, which could write `foo 0`,`foo "abc"` instead of `foo (0::Int)` `foo ("abc"::String)` . but is this a bad smell?
2021-01-15 14:16:13 +0100 <ukari> https://gist.github.com/ukari/a0715787899455e593edc4e7f790ef52
2021-01-15 14:16:41 +0100da39a3ee5e6b4b0d(~da39a3ee5@2403:6200:8876:3a8e:d956:f43e:d9a3:9155) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 14:17:15 +0100Sheilong(uid293653@gateway/web/irccloud.com/x-yybsiwkkxmipzuww)
2021-01-15 14:18:10 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Remote host closed the connection)
2021-01-15 14:18:38 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 14:18:45 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 14:26:25 +0100brisbin(~patrick@pool-173-49-158-4.phlapa.fios.verizon.net)
2021-01-15 14:27:16 +0100Tario(~Tario@201.192.165.173)
2021-01-15 14:28:43 +0100Mzg(Mzg@s1.ct8.pl) (Ping timeout: 246 seconds)
2021-01-15 14:29:54 +0100threestrikes(~threestri@cpe-24-243-229-2.hot.res.rr.com)
2021-01-15 14:30:39 +0100jfe(~user@pool-71-184-149-134.bstnma.fios.verizon.net)
2021-01-15 14:31:57 +0100 <merijn> ph88: Citation needed
2021-01-15 14:33:08 +0100 <ph88> merijn, haha :D
2021-01-15 14:34:43 +0100 <idnar> merijn: https://docs.google.com/spreadsheet/oimg?key=0AiZ8xw4sxde1dDJhSGxGXzdhYzlVS2lZNjNZZEpSZ3c&oid=18&z… ;)
2021-01-15 14:34:50 +0100rayyyy(~nanoz@gateway/tor-sasl/nanoz) (Remote host closed the connection)
2021-01-15 14:35:13 +0100 <merijn> idnar: That is for String types, mostly due to hashing ones then doing lookups being faster than compare every time
2021-01-15 14:35:16 +0100rayyyy(~nanoz@gateway/tor-sasl/nanoz)
2021-01-15 14:35:43 +0100 <merijn> idnar: Generalising that to every key is dangerous
2021-01-15 14:36:01 +0100 <merijn> Also, still not relevant for most applications
2021-01-15 14:36:06 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 256 seconds)
2021-01-15 14:36:22 +0100 <zangi> MorrowM: I'm trying to randomly shuffle a list, e.g. [1,2,3] -> [2,3,1], [3,1,2], [1,3,2], etc
2021-01-15 14:36:49 +0100 <zangi> kritzefitz: wow, never thought about using do notation
2021-01-15 14:36:54 +0100 <lortabac> ukari: what is the purpose of this "hack"? avoiding ambiguous types?
2021-01-15 14:38:53 +0100 <lortabac> ukari: can't you just do 'instance Foo Int where foo = Number' ?
2021-01-15 14:40:45 +0100 <lortabac> I don't think Foo would be ambiguous, because the type of 'a' can be determined from the argument of 'foo'
2021-01-15 14:40:58 +0100Spiff(~quassel@102.160.161.107)
2021-01-15 14:42:55 +0100 <merijn> lortabac: It's ambiguous if you do "foo 1" :p
2021-01-15 14:43:05 +0100 <merijn> Because 1 *could* be String
2021-01-15 14:43:32 +0100 <lortabac> I don't understand
2021-01-15 14:44:18 +0100 <geekosaur> nothig stops you from defining a Num instance for String, and numeric literals get fromIntegral applied to them
2021-01-15 14:44:40 +0100 <lortabac> oh ok, but this is a different problem
2021-01-15 14:44:43 +0100 <merijn> lortabac: Yes
2021-01-15 14:44:46 +0100 <geekosaur> (whether it makes sense is another question, but the compiler doesn't do "makes sense")
2021-01-15 14:44:50 +0100 <merijn> It's unrelated to overlapping
2021-01-15 14:45:15 +0100drbean(~drbean@TC210-63-209-49.static.apol.com.tw) (Ping timeout: 256 seconds)
2021-01-15 14:45:15 +0100 <lortabac> it's about how to specialize literal integers to 'Int'
2021-01-15 14:45:47 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 14:45:57 +0100 <geekosaur> sorry, fromInteger
2021-01-15 14:46:39 +0100 <lortabac> I am not sure avoiding 6 extra chars is worth an incoherent instance
2021-01-15 14:47:37 +0100ADG1089_(~adg1089@122.163.165.143) (Ping timeout: 264 seconds)
2021-01-15 14:47:38 +0100 <lortabac> especially if the type of the argument can be inferred to be an Int somewhere else in the code
2021-01-15 14:49:13 +0100rmk236(~lcampos@2a02:908:3616:b100:1800:1cb7:353d:300d) (Quit: Leaving.)
2021-01-15 14:49:45 +0100 <ArConan> @where paste
2021-01-15 14:49:45 +0100 <lambdabot> Help us help you: please paste full code, input and/or output at eg https://paste.tomsmeding.com
2021-01-15 14:51:38 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Remote host closed the connection)
2021-01-15 14:51:44 +0100Vulfe_(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 14:52:24 +0100 <ArConan> https://paste.tomsmeding.com/NTX1IjGD
2021-01-15 14:53:06 +0100 <ArConan> why we use `fmap f` in haskell?
2021-01-15 14:53:25 +0100 <ArConan> why not use `fmap Tree`?
2021-01-15 14:53:45 +0100 <__monty__> ArConan: Do you mean the order of arguments?
2021-01-15 14:53:53 +0100Mzg(Mzg@s1.ct8.pl)
2021-01-15 14:54:20 +0100 <geekosaur> because you are mapping a function over a Tree, not mapping a Tree over a function
2021-01-15 14:54:38 +0100berberman_(~berberman@unaffiliated/berberman) (Quit: ZNC 1.7.5 - https://znc.in)
2021-01-15 14:54:48 +0100 <geekosaur> (I assume you meant Functor instead of Function in that paste)
2021-01-15 14:55:02 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 14:55:46 +0100 <ArConan> geekosaur: ah ,yes
2021-01-15 14:56:13 +0100 <ArConan> problem sovled
2021-01-15 14:56:20 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 14:56:59 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 14:57:24 +0100vicfred(~vicfred@unaffiliated/vicfred)
2021-01-15 15:02:02 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 15:03:04 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:04:28 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 15:04:41 +0100da39a3ee5e6b4b0d(~da39a3ee5@67.23.55.162)
2021-01-15 15:05:08 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:05:40 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 15:06:36 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 240 seconds)
2021-01-15 15:06:59 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 15:07:34 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:07:45 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Remote host closed the connection)
2021-01-15 15:07:46 +0100cfricke(~cfricke@unaffiliated/cfricke) (Quit: WeeChat 3.0)
2021-01-15 15:08:18 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 15:09:06 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 15:10:38 +0100 <itai33[m]> is there a program that automatically weakens your dependencies to the largest thing that will compile in haskell/cabal?
2021-01-15 15:10:58 +0100 <ij> when backtracking and trying to do fairness, does that count as heuristic? is there any similarity between that and A*?
2021-01-15 15:11:35 +0100jumper149(~jumper149@ip185225.wh.uni-hannover.de)
2021-01-15 15:12:28 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 246 seconds)
2021-01-15 15:12:32 +0100 <__monty__> itai33[m]: Hackage does have a build matrix which is generated by CI supposedly so the mechanism exists afaict. You'd have to run a ton of builds though.
2021-01-15 15:13:40 +0100 <__monty__> If you just want a policy to adhere to "package ^>= current-version" and then relaxing it when users report your bounds are too strict is a common way of going about it.
2021-01-15 15:14:08 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 15:15:20 +0100ep1ctetus(~epictetus@ip184-187-162-163.sb.sd.cox.net)
2021-01-15 15:15:37 +0100 <itai33[m]> __monty__: this kind of assumes that my package actually has users though
2021-01-15 15:15:46 +0100 <itai33[m]> however if it doesn't really i guess this matters a lot less
2021-01-15 15:16:12 +0100 <__monty__> Yeah, if you're the only consumer you'll just be the one reporting to yourself your bounds are too strict : )
2021-01-15 15:16:29 +0100 <__monty__> It's also less important for executables than libraries.
2021-01-15 15:16:51 +0100 <itai33[m]> true true
2021-01-15 15:17:12 +0100 <itai33[m]> however it seems that getting on the CI is nontrivial
2021-01-15 15:17:26 +0100 <itai33[m]> idiii asked like 2 months ago and isn't on
2021-01-15 15:18:00 +0100 <__monty__> What do you mean? Get your package built by hackage CI without publishing to hackage?
2021-01-15 15:18:09 +0100tropico(~tropico@unaffiliated/tropico) (Quit: WeeChat 3.0)
2021-01-15 15:18:29 +0100 <itai33[m]> __monty__: no you have to ask explicitly even if is on hackage already
2021-01-15 15:18:46 +0100 <__monty__> Ah. Understandable, like I said it's a *lot* of builds.
2021-01-15 15:18:46 +0100carlomagno1(~cararell@148.87.23.10) (Remote host closed the connection)
2021-01-15 15:18:58 +0100 <__monty__> I imagine only somewhat popular libraries get added.
2021-01-15 15:18:59 +0100 <itai33[m]> true, maybe they only do it for popular packages
2021-01-15 15:19:14 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 15:19:19 +0100Vulfe_(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Remote host closed the connection)
2021-01-15 15:19:39 +0100 <__monty__> I didn't mean use hackage CI btw. I meant hackage CI does it somehow so presumably there's code somewhere which you'd then need to adapt to run conveniently.
2021-01-15 15:20:18 +0100 <itai33[m]> hmm yeah i'll look into it
2021-01-15 15:20:27 +0100 <kritzefitz> I think I recently read somewhere that matrix CI should automatically build new packages on Hackage, but in reality it doesn't seem to happen. Unfortunately I couldn't find a reliable information on what is the intended behavior.
2021-01-15 15:21:04 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8)
2021-01-15 15:21:52 +0100Stanley00(~stanley00@unaffiliated/stanley00)
2021-01-15 15:23:03 +0100 <texasmynsted> I looked on reddit, so, haskell.org, the haskell wiki, etc... What is a good option for hosting prototype haskell web apps? Right now the only thing that I can think of is Amazon EC2.
2021-01-15 15:25:12 +0100jchia__(~jchia@58.32.32.252) (Read error: Connection reset by peer)
2021-01-15 15:25:17 +0100berberman(~berberman@unaffiliated/berberman) (Quit: ZNC 1.7.5 - https://znc.in)
2021-01-15 15:25:30 +0100jchia__(~jchia@58.32.32.252)
2021-01-15 15:25:45 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:27:17 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 15:27:24 +0100MaxRos(~MaxRos@bzq-110-168-31-106.red.bezeqint.net)
2021-01-15 15:27:31 +0100MaxRos(~MaxRos@bzq-110-168-31-106.red.bezeqint.net) (Client Quit)
2021-01-15 15:27:55 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:27:56 +0100MaxRos(~MorrowM@bzq-110-168-31-106.red.bezeqint.net)
2021-01-15 15:28:07 +0100gaussian(~gaussian@nat-wireless-140-180-240-88.princeton.edu)
2021-01-15 15:28:18 +0100Stanley00(~stanley00@unaffiliated/stanley00) (Ping timeout: 260 seconds)
2021-01-15 15:29:10 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 15:29:26 +0100carlomagno(~cararell@148.87.23.5)
2021-01-15 15:29:37 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:30:54 +0100berberman(~berberman@unaffiliated/berberman) (Max SendQ exceeded)
2021-01-15 15:31:28 +0100berberman(~berberman@unaffiliated/berberman)
2021-01-15 15:31:41 +0100 <ij> maybe heroku with custom build packs? just a guess, I haven't tried it
2021-01-15 15:32:24 +0100gaussian95(8cb4f058@gateway/web/cgi-irc/kiwiirc.com/ip.140.180.240.88)
2021-01-15 15:32:34 +0100 <texasmynsted> Good idea. I have not tried heroku in years.
2021-01-15 15:32:46 +0100gaussian95(8cb4f058@gateway/web/cgi-irc/kiwiirc.com/ip.140.180.240.88) (Client Quit)
2021-01-15 15:33:13 +0100cheater(~user@unaffiliated/cheater) (Ping timeout: 264 seconds)
2021-01-15 15:33:22 +0100machinedgod(~machinedg@135-23-192-217.cpe.pppoe.ca)
2021-01-15 15:35:18 +0100da39a3ee5e6b4b0d(~da39a3ee5@67.23.55.162) (Ping timeout: 272 seconds)
2021-01-15 15:37:18 +0100pavonia(~user@unaffiliated/siracusa) (Quit: Bye!)
2021-01-15 15:38:06 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com) (Remote host closed the connection)
2021-01-15 15:38:35 +0100gaussian(~gaussian@nat-wireless-140-180-240-88.princeton.edu) (Quit: Leaving)
2021-01-15 15:38:38 +0100shatriff(~vitaliish@176-52-216-242.irishtelecom.com)
2021-01-15 15:38:53 +0100gaussian(~gaussian@nat-wireless-140-180-240-72.princeton.edu)
2021-01-15 15:38:58 +0100gaussian_(~gaussian@nat-wireless-140-180-240-88.princeton.edu)
2021-01-15 15:38:59 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 15:39:17 +0100gaussian_(~gaussian@nat-wireless-140-180-240-88.princeton.edu) (Remote host closed the connection)
2021-01-15 15:40:58 +0100cr3(~cr3@192-222-143-195.qc.cable.ebox.net)
2021-01-15 15:43:36 +0100cheater(~user@unaffiliated/cheater)
2021-01-15 15:43:50 +0100 <travv0> I use heroku for that, works well
2021-01-15 15:48:43 +0100geekosaur(ac3a3b75@172.58.59.117) (Quit: Connection closed)
2021-01-15 15:49:43 +0100 <itai33[m]> does adding more summed options to a sum type count as a breaking change?
2021-01-15 15:50:20 +0100 <merijn> itai33[m]: Luckily for you, there is a helpful flowchart!
2021-01-15 15:50:27 +0100 <merijn> itai33[m]: https://pvp.haskell.org/
2021-01-15 15:50:30 +0100 <itai33[m]> neat!
2021-01-15 15:51:32 +0100 <itai33[m]> cool so it does count if the constructors are visible
2021-01-15 15:52:04 +0100 <itai33[m]> merijn: thanks for the link, is the flowchart new? i feel like i haven't seen it before
2021-01-15 15:52:16 +0100 <merijn> itai33[m]: Well, depends how you define new :p
2021-01-15 15:52:27 +0100 <merijn> It's certainly *at least* 2 years old by now
2021-01-15 15:52:32 +0100 <itai33[m]> i may have only read the pvp faq and not the spec itself
2021-01-15 15:52:48 +0100 <itai33[m]> yeah okay i just missed the fact that the spec is also there
2021-01-15 15:56:13 +0100matryoshka(~matryoshk@2606:6080:1002:8:3285:30e:de43:8809) (Read error: Connection reset by peer)
2021-01-15 15:56:36 +0100matryoshka(~matryoshk@184.75.223.227)
2021-01-15 15:59:20 +0100Sgeo(~Sgeo@ool-18b98aa4.dyn.optonline.net)
2021-01-15 16:01:51 +0100alexelcu(~alexelcu@142.93.180.198) (Quit: ZNC 1.8.2 - https://znc.in)
2021-01-15 16:02:29 +0100alexelcu(~alexelcu@142.93.180.198)
2021-01-15 16:04:59 +0100alexelcu(~alexelcu@142.93.180.198) (Client Quit)
2021-01-15 16:05:29 +0100alexelcu(~alexelcu@142.93.180.198)
2021-01-15 16:05:39 +0100pera(~pera@unaffiliated/pera) (Ping timeout: 260 seconds)
2021-01-15 16:06:15 +0100xsperry(~as@unaffiliated/xsperry)
2021-01-15 16:06:23 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Ping timeout: 240 seconds)
2021-01-15 16:07:35 +0100 <maralorn> People always complain about the quadratic instances problem of monad stacks. But isn‘t that essentially solved by the MonadTrans class?
2021-01-15 16:07:58 +0100 <merijn> maralorn: No
2021-01-15 16:08:09 +0100 <merijn> maralorn: How would that solve it?
2021-01-15 16:08:54 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2021-01-15 16:09:06 +0100 <merijn> maralorn: Sure, you can manually write 'lift' 5 times for each operation, but that's hard "solved"
2021-01-15 16:10:59 +0100 <maralorn> In this article I got the impression that one instance of the form (MyClass m a, MonadTrans t, Monad m) => MyClass (t m) a, solves it. https://lukasz-golebiewski.github.io/haskell/effects/2021/01/06/overlappable-instances.html
2021-01-15 16:11:26 +0100 <maralorn> Is that a crazy new idea? Does everyone already do that?
2021-01-15 16:11:27 +0100 <maralorn> What are the downsides?
2021-01-15 16:11:51 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr)
2021-01-15 16:13:06 +0100 <merijn> maralorn: It overlaps every possible transformer? :)
2021-01-15 16:13:38 +0100 <merijn> maralorn: So you can't instantiate the instance for ReaderT, because if overlaps with that one
2021-01-15 16:14:10 +0100 <maralorn> It does?
2021-01-15 16:14:16 +0100 <merijn> Well yes
2021-01-15 16:14:22 +0100lawid(~quassel@dslb-090-186-127-244.090.186.pools.vodafone-ip.de) (Ping timeout: 256 seconds)
2021-01-15 16:14:24 +0100mouseghost(~draco@wikipedia/desperek) (Quit: mew wew)
2021-01-15 16:14:26 +0100 <maralorn> You mean I can‘t write this instance for ReaderT?
2021-01-15 16:14:30 +0100 <merijn> Unless you wanna not define a MonadTrans instance for ReaderT?
2021-01-15 16:14:44 +0100 <maralorn> Or you I can‘t use that instance with t = ReaderT?
2021-01-15 16:15:12 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 16:15:27 +0100 <maralorn> Why would there be another instance for MyClass (ReaderT m) a?
2021-01-15 16:15:43 +0100 <merijn> maralorn: "instance Monad m => MonadReader r (ReaderT r m) where..." overlaps with instance "instance (MonadReader r m, MonadTrans t, Monad m) => MonadReader r (t m)"
2021-01-15 16:15:46 +0100 <maralorn> And would it be a problem? I mean it would overlap our instance, right?
2021-01-15 16:16:11 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr)
2021-01-15 16:16:12 +0100 <merijn> maralorn: Why would there be another instance? Because you just defined another instance...
2021-01-15 16:16:58 +0100rdivyanshu(uid322626@gateway/web/irccloud.com/x-fieuoudgdzkiaysv) (Quit: Connection closed for inactivity)
2021-01-15 16:16:59 +0100lawid(~quassel@dslb-178-005-066-239.178.005.pools.vodafone-ip.de)
2021-01-15 16:18:40 +0100 <maralorn> Well the blog post says those instances overlap. That‘s why they use OVERLAPPABLE.
2021-01-15 16:19:43 +0100 <merijn> maralorn: That doesn't solve your problem, because you can get in positions where it's hard to predict what goes on
2021-01-15 16:19:59 +0100 <merijn> "ReaderT Int (ReaderT Bool m)" How is this resolved
2021-01-15 16:20:06 +0100kupi(uid212005@gateway/web/irccloud.com/x-ljwqugooccinbszd)
2021-01-15 16:20:06 +0100dcoutts_(~duncan@33.14.75.194.dyn.plus.net)
2021-01-15 16:20:26 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 16:20:49 +0100 <maralorn> I don‘t know. Does it get resolved at all?
2021-01-15 16:20:50 +0100 <merijn> maralorn: Oh, also
2021-01-15 16:20:55 +0100 <dolio> The `ReaderT Int m` instance is used.
2021-01-15 16:21:00 +0100 <kupi> is there any way to inline f in the expression a `f` b while still being infix?
2021-01-15 16:21:00 +0100 <merijn> maralorn: That class still requires multiple lifts
2021-01-15 16:21:14 +0100 <merijn> Maybe?
2021-01-15 16:21:15 +0100 <merijn> Anyway
2021-01-15 16:21:27 +0100 <merijn> Hot take: The mtl classes are bad and you should not use them anyway!
2021-01-15 16:21:47 +0100 <merijn> kupi: Put an INLINE pragma on 'f'? :p
2021-01-15 16:22:07 +0100 <merijn> kupi: You can't make composite expressions infix with ``, no
2021-01-15 16:22:26 +0100 <merijn> kupi: Although I'm curious why it'd matter?
2021-01-15 16:23:44 +0100 <kupi> because i think "t (div `on` floor) nominalDay" looks better than "(div `on` floor) t nominalDay"
2021-01-15 16:23:57 +0100 <maralorn> merijn: So how do you stack effects?
2021-01-15 16:24:24 +0100Jd007(~Jd007@162.156.11.151)
2021-01-15 16:24:31 +0100 <merijn> maralorn: The classes are too general to count as useful effects
2021-01-15 16:24:33 +0100phasespace(~sar@80-89-47-117.inet.signal.no) (Ping timeout: 265 seconds)
2021-01-15 16:25:18 +0100 <merijn> The class style polymorphism is great for higher level, DSL-like operations that are unique (like logging, database access, etc.)
2021-01-15 16:25:18 +0100 <kupi> hmm i can "(t & (div `on` floor)) nominalDay"
2021-01-15 16:25:23 +0100 <maralorn> Ah, I remember that point. You prefer a (ReadMyAppState m) Constraint?
2021-01-15 16:25:25 +0100knupfer(~Thunderbi@87.123.206.193)
2021-01-15 16:26:19 +0100 <merijn> maralorn: MonadReader isn't close to unique, lots of different things use that and libraries that expose MonadReader as part of their API are automatically incompatible on account of having conflicting requirements on MonadReader
2021-01-15 16:26:35 +0100Vulfe(~vulfe@2600:1702:31b0:34e0:14ba:8187:11f3:2cd8) (Remote host closed the connection)
2021-01-15 16:27:24 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 256 seconds)
2021-01-15 16:27:35 +0100pera(pera@gateway/vpn/mullvad/pera)
2021-01-15 16:27:37 +0100gaussian_(uid482612@gateway/web/irccloud.com/x-wvvzwlxqofinemam)
2021-01-15 16:27:46 +0100gaussian(~gaussian@nat-wireless-140-180-240-72.princeton.edu) (Quit: Leaving)
2021-01-15 16:27:47 +0100mmmattyx(uid17782@gateway/web/irccloud.com/x-vpawruibcbfaslfq)
2021-01-15 16:27:47 +0100gaussian_gaussian
2021-01-15 16:27:58 +0100 <merijn> maralorn: In my own code I have stuff like MonadX classes, but specific for my application
2021-01-15 16:28:14 +0100idups(~pandora@business-90-187-28-109.pool2.vodafone-ip.de)
2021-01-15 16:28:29 +0100 <merijn> maralorn: And where possible you should not be exposing "monad stacks" as part of your API, they should just be an opaque newtype
2021-01-15 16:28:48 +0100 <maralorn> Yeah.
2021-01-15 16:30:59 +0100azure1(~azure@103.154.230.250)
2021-01-15 16:31:05 +0100Deide(~Deide@217.155.19.23)
2021-01-15 16:32:24 +0100 <maralorn> One of the annoyances of MonadReader is that you cannot use mapReaderT on (MonadReader r m => m)
2021-01-15 16:33:02 +0100idups(~pandora@business-90-187-28-109.pool2.vodafone-ip.de) ()
2021-01-15 16:33:06 +0100Vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net)
2021-01-15 16:34:12 +0100zangi(~azure@103.154.230.250) (Ping timeout: 256 seconds)
2021-01-15 16:34:15 +0100 <dolio> It doesn't necessarily make any sense.
2021-01-15 16:34:37 +0100 <dolio> You can have instances that only work for a fixed `r`.
2021-01-15 16:38:55 +0100azure1(~azure@103.154.230.250) (Ping timeout: 246 seconds)
2021-01-15 16:39:10 +0100danso(~dan@23-233-104-25.cpe.pppoe.ca)
2021-01-15 16:39:18 +0100azure1(~azure@103.154.230.250)
2021-01-15 16:40:27 +0100jamm(~jamm@unaffiliated/jamm)
2021-01-15 16:41:41 +0100xff0x(~xff0x@2001:1a81:52c6:7f00:782f:7bae:5710:c758) (Ping timeout: 272 seconds)
2021-01-15 16:41:42 +0100phasespace(~sar@89-162-33-21.fiber.signal.no)
2021-01-15 16:42:27 +0100xff0x(~xff0x@2001:1a81:52c6:7f00:785f:53ed:cde5:7b1a)
2021-01-15 16:45:47 +0100 <maralorn> Fair enough
2021-01-15 16:46:41 +0100 <maralorn> Well than maybe I am looking for a class which is more restrictive in that sense …
2021-01-15 16:47:00 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se) (Ping timeout: 256 seconds)
2021-01-15 16:48:38 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se)
2021-01-15 16:52:25 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr)
2021-01-15 16:53:23 +0100jonathanx_(~jonathan@h-176-109.A357.priv.bahnhof.se)
2021-01-15 16:53:30 +0100jonathanx(~jonathan@h-176-109.A357.priv.bahnhof.se) (Read error: No route to host)
2021-01-15 16:55:22 +0100Vulfe(~vulfe@75-28-176-196.lightspeed.evtnil.sbcglobal.net) (Remote host closed the connection)
2021-01-15 16:58:21 +0100jonathanx_(~jonathan@h-176-109.A357.priv.bahnhof.se) (Ping timeout: 256 seconds)
2021-01-15 17:00:35 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-01-15 17:01:14 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 256 seconds)
2021-01-15 17:01:21 +0100Tuplanolla(~Tuplanoll@91-159-68-239.elisa-laajakaista.fi)
2021-01-15 17:01:35 +0100 <texasmynsted> thank you travv0 and ij.
2021-01-15 17:02:12 +0100ericsagnes(~ericsagne@2405:6580:0:5100:7035:540:bf28:536c) (Ping timeout: 260 seconds)
2021-01-15 17:03:57 +0100atraii(~atraii@c-98-32-64-84.hsd1.ut.comcast.net) (Quit: ZNC 1.7.5 - https://znc.in)
2021-01-15 17:04:21 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr)
2021-01-15 17:05:43 +0100elfets(~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de)
2021-01-15 17:05:46 +0100atraii(~atraii@c-98-32-64-84.hsd1.ut.comcast.net)
2021-01-15 17:08:57 +0100ArConan(9de62a69@157.230.42.105) (Quit: Connection closed)
2021-01-15 17:10:28 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 256 seconds)
2021-01-15 17:11:36 +0100niekvand_(~niekvande@89.205.135.50)
2021-01-15 17:11:56 +0100Spiff(~quassel@102.160.161.107) (Ping timeout: 240 seconds)
2021-01-15 17:13:39 +0100acarrico(~acarrico@dhcp-68-142-39-249.greenmountainaccess.net)
2021-01-15 17:13:51 +0100mastarija(~mastarija@188.252.196.94)
2021-01-15 17:14:37 +0100ericsagnes(~ericsagne@2405:6580:0:5100:5879:2dc6:16a6:5fa5)
2021-01-15 17:15:00 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 256 seconds)
2021-01-15 17:16:10 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 17:18:10 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 17:20:18 +0100ubert(~Thunderbi@p200300ecdf1ee06ce02324fb94e406b3.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2021-01-15 17:20:30 +0100niekvand_(~niekvande@89.205.135.50) (Read error: Connection reset by peer)
2021-01-15 17:20:50 +0100jamm(~jamm@unaffiliated/jamm) (Remote host closed the connection)
2021-01-15 17:20:51 +0100ubert(~Thunderbi@p200300ecdf1ee03ee02324fb94e406b3.dip0.t-ipconnect.de)
2021-01-15 17:21:02 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 17:21:57 +0100Spiff(~quassel@102.160.161.107)
2021-01-15 17:23:12 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net)
2021-01-15 17:23:58 +0100michalz(~user@185.246.204.80) (Remote host closed the connection)
2021-01-15 17:24:08 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Remote host closed the connection)
2021-01-15 17:28:40 +0100threestrikes(~threestri@cpe-24-243-229-2.hot.res.rr.com) (Ping timeout: 272 seconds)
2021-01-15 17:29:10 +0100atraii(~atraii@c-98-32-64-84.hsd1.ut.comcast.net) (Ping timeout: 256 seconds)
2021-01-15 17:29:12 +0100hiroaki_(~hiroaki@ip4d166c42.dynamic.kabel-deutschland.de)
2021-01-15 17:29:23 +0100alexcleac(~alexcleac@213.111.86.105)
2021-01-15 17:31:43 +0100rayyyy(~nanoz@gateway/tor-sasl/nanoz) (Ping timeout: 240 seconds)
2021-01-15 17:32:46 +0100ciderpunx[m](ciderpunxm@gateway/shell/matrix.org/x-wtxjlxxcorbdpyii)
2021-01-15 17:38:49 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 17:41:27 +0100threestrikes(~threestri@cpe-24-243-229-2.hot.res.rr.com)
2021-01-15 17:43:53 +0100roconnor(~roconnor@host-104-157-225-60.dyn.295.ca)
2021-01-15 17:45:23 +0100Saukk(~Saukk@83-148-239-3.dynamic.lounea.fi)
2021-01-15 17:46:25 +0100kritzefitz(~kritzefit@fw-front.credativ.com) (Remote host closed the connection)
2021-01-15 17:46:26 +0100 <ezzieyguywuf> hah, ok back to my "ambiguous module" thing from yesterday - I think it may actually be related to doctests? `cabal unpack pcre-heavy; cd pcre-heavy-1.0.0.2; cabal test` will result in "Ambiguous module" error if both "base-compat" and "base-compat-batteries" are listed in `ghc-pkg list`
2021-01-15 17:46:48 +0100 <ezzieyguywuf> so I'm using cabal-install now, which I think _should_ use `-hide-all-packages`
2021-01-15 17:46:53 +0100 <ezzieyguywuf> so something wonky is happening!
2021-01-15 17:48:03 +0100Lord_of_Life_(~Lord@unaffiliated/lord-of-life/x-0885362)
2021-01-15 17:48:16 +0100roconnor(~roconnor@host-104-157-225-60.dyn.295.ca) (Ping timeout: 240 seconds)
2021-01-15 17:48:22 +0100roconnor_(~roconnor@host-104-157-225-60.dyn.295.ca)
2021-01-15 17:49:01 +0100philopsos(~caecilius@gateway/tor-sasl/caecilius)
2021-01-15 17:49:44 +0100tzh(~xax@c-24-21-73-154.hsd1.wa.comcast.net)
2021-01-15 17:50:16 +0100Lord_of_Life(~Lord@unaffiliated/lord-of-life/x-0885362) (Ping timeout: 240 seconds)
2021-01-15 17:50:56 +0100Lord_of_Life_Lord_of_Life
2021-01-15 17:56:15 +0100geekosaur(42d52137@66.213.33.55)
2021-01-15 18:00:47 +0100_noblegas(uid91066@gateway/web/irccloud.com/x-nggbacvcifzzsyid)
2021-01-15 18:02:13 +0100Spiff(~quassel@102.160.161.107) (Ping timeout: 246 seconds)
2021-01-15 18:04:36 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 265 seconds)
2021-01-15 18:06:49 +0100jamm(~jamm@unaffiliated/jamm)
2021-01-15 18:07:00 +0100threestrikes(~threestri@cpe-24-243-229-2.hot.res.rr.com) (Remote host closed the connection)
2021-01-15 18:07:17 +0100 <ezzieyguywuf> `ghc-pkg hide base-compat-batteries` fixes things, but I don't really understand why this is needed, and seems fragile
2021-01-15 18:07:34 +0100 <ezzieyguywuf> I'd love to file a bug report if that's appropriate, but I could use some help first understanding what's going on.
2021-01-15 18:08:20 +0100plutoniix(~q@node-uib.pool-125-24.dynamic.totinternet.net)
2021-01-15 18:09:22 +0100 <merijn> ezzieyguywuf: Which version of cabal-install?
2021-01-15 18:09:53 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 18:10:17 +0100 <ezzieyguywuf> merijn: 3.2.0.0
2021-01-15 18:10:22 +0100 <ezzieyguywuf> I believe that's the latest...
2021-01-15 18:10:32 +0100 <ezzieyguywuf> cabal v3.2.1.0
2021-01-15 18:11:12 +0100 <merijn> And you didn't have to specify a database location for ghc-pkg? Because that sounds like you somehow got something in your global package db (which, iirc, causes cabal-install to pin that version)
2021-01-15 18:11:26 +0100jamm(~jamm@unaffiliated/jamm) (Ping timeout: 264 seconds)
2021-01-15 18:12:07 +0100Ariakenom(~Ariakenom@2001:9b1:efb:fc00:8cf9:a684:8b01:4d31)
2021-01-15 18:12:09 +0100azure1(~azure@103.154.230.250) (Quit: WeeChat 2.9)
2021-01-15 18:12:13 +0100 <ezzieyguywuf> merijn: I have ghc installed using my package manager, as well as all the dependencies of prce-heavy
2021-01-15 18:12:34 +0100 <ezzieyguywuf> so `cabal test --dry-run` says it only needs to build pcre-heavy, everything else comes from the system-wide package db
2021-01-15 18:13:14 +0100 <merijn> hmm, I'm not sure why that'd happen and it's dinner time now, so someone else will have to guess
2021-01-15 18:13:48 +0100 <ezzieyguywuf> merijn: thanks for trying!
2021-01-15 18:14:00 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:d8c5:1dbb:568:768a) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 18:14:07 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 246 seconds)
2021-01-15 18:14:30 +0100pera(pera@gateway/vpn/mullvad/pera) (Ping timeout: 256 seconds)
2021-01-15 18:15:05 +0100CindyLinz(~cindy_utf@112.121.78.20) (Ping timeout: 240 seconds)
2021-01-15 18:15:57 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:989c:f9b9:87c4:db9d)
2021-01-15 18:19:42 +0100veverak(~squirrel@ip-89-102-98-161.net.upcbroadband.cz) (Quit: WeeChat 2.3)
2021-01-15 18:20:23 +0100conal(~conal@64.71.133.70)
2021-01-15 18:20:54 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 18:22:48 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-01-15 18:22:53 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr)
2021-01-15 18:23:10 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr)
2021-01-15 18:23:51 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net)
2021-01-15 18:24:40 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net) (Remote host closed the connection)
2021-01-15 18:25:25 +0100mastarija(~mastarija@188.252.196.94) (Quit: Leaving)
2021-01-15 18:25:38 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net)
2021-01-15 18:26:52 +0100rayyyy(~nanoz@gateway/tor-sasl/nanoz)
2021-01-15 18:29:05 +0100geekosaur(42d52137@66.213.33.55) (Ping timeout: 248 seconds)
2021-01-15 18:29:13 +0100Tops2(~Tobias@dyndsl-095-033-020-049.ewe-ip-backbone.de)
2021-01-15 18:29:55 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net)
2021-01-15 18:30:09 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net) (Ping timeout: 256 seconds)
2021-01-15 18:31:43 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net)
2021-01-15 18:32:04 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-01-15 18:32:43 +0100nineonine(~nineonine@S01061cabc0b095f3.vf.shawcable.net) (Remote host closed the connection)
2021-01-15 18:33:18 +0100nineonine(~nineonine@50.216.62.2)
2021-01-15 18:37:17 +0100conal(~conal@64.71.133.70)
2021-01-15 18:39:04 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-01-15 18:39:12 +0100Saukk(~Saukk@83-148-239-3.dynamic.lounea.fi) (Remote host closed the connection)
2021-01-15 18:39:59 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Remote host closed the connection)
2021-01-15 18:40:59 +0100ashepelev(~ashepelev@217.146.82.202)
2021-01-15 18:42:33 +0100geekosaur(42d52137@66.213.33.55)
2021-01-15 18:43:10 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 19:00:23 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 19:01:40 +0100Noldorin(~noldorin@unaffiliated/noldorin)
2021-01-15 19:07:04 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net) (Ping timeout: 260 seconds)
2021-01-15 19:11:36 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas) (Ping timeout: 240 seconds)
2021-01-15 19:12:40 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 19:14:28 +0100jonatan(~nate@h77-53-70-163.cust.a3fiber.se) (Quit: leaving)
2021-01-15 19:15:29 +0100jonatan(~nate@h77-53-70-163.cust.a3fiber.se)
2021-01-15 19:16:41 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser)
2021-01-15 19:17:10 +0100carthia(~carthia@gateway/tor-sasl/carthia)
2021-01-15 19:17:22 +0100rajivr(uid269651@gateway/web/irccloud.com/x-gknvnupcsrvhzqnh) (Quit: Connection closed for inactivity)
2021-01-15 19:18:50 +0100 <ezzieyguywuf> hm, this seems like a clue...https://github.com/ekmett/lens/commit/d2459a012b5d9c2ae011814143ffcba4e9324ea9
2021-01-15 19:19:30 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 272 seconds)
2021-01-15 19:19:48 +0100christo(~chris@81.96.113.213)
2021-01-15 19:22:44 +0100knupfer(~Thunderbi@87.123.206.193) (Quit: knupfer)
2021-01-15 19:22:48 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr) (Quit: Konversation terminated!)
2021-01-15 19:22:49 +0100knupfer1(~Thunderbi@200116b82c666e004c059dad5af23240.dip.versatel-1u1.de)
2021-01-15 19:23:10 +0100zebrag(~inkbottle@aaubervilliers-654-1-109-134.w86-212.abo.wanadoo.fr)
2021-01-15 19:23:37 +0100wonko7(~wonko7@91.151.74.79) (Ping timeout: 264 seconds)
2021-01-15 19:24:57 +0100knupfer1(~Thunderbi@200116b82c666e004c059dad5af23240.dip.versatel-1u1.de) (Read error: Connection reset by peer)
2021-01-15 19:25:07 +0100knupfer(~Thunderbi@200116b82c666e001d22309f07016899.dip.versatel-1u1.de)
2021-01-15 19:26:23 +0100knupfer(~Thunderbi@200116b82c666e001d22309f07016899.dip.versatel-1u1.de) (Client Quit)
2021-01-15 19:26:27 +0100knupfer1(~Thunderbi@200116b82c666e0049063d7826f1d858.dip.versatel-1u1.de)
2021-01-15 19:26:41 +0100knupfer1(~Thunderbi@200116b82c666e0049063d7826f1d858.dip.versatel-1u1.de) (Client Quit)
2021-01-15 19:26:58 +0100knupfer(~Thunderbi@200116b82c666e00c43fa4a0f4acdbbe.dip.versatel-1u1.de)
2021-01-15 19:27:24 +0100knupfer1(~Thunderbi@87.123.206.193)
2021-01-15 19:27:28 +0100knupfer(~Thunderbi@200116b82c666e00c43fa4a0f4acdbbe.dip.versatel-1u1.de) (Read error: Connection reset by peer)
2021-01-15 19:27:33 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2021-01-15 19:27:34 +0100knupfer1(~Thunderbi@87.123.206.193) (Read error: Connection reset by peer)
2021-01-15 19:27:38 +0100knupfer(~Thunderbi@200116b82c666e004ddb2b2b9fc7da22.dip.versatel-1u1.de)
2021-01-15 19:28:15 +0100Spiff(~quassel@102.160.161.107)
2021-01-15 19:29:12 +0100vicfred(~vicfred@unaffiliated/vicfred) (Quit: Leaving)
2021-01-15 19:29:44 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 19:30:10 +0100coot(~coot@37.30.55.132.nat.umts.dynamic.t-mobile.pl)
2021-01-15 19:30:12 +0100vicfred(~vicfred@unaffiliated/vicfred)
2021-01-15 19:30:27 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr)
2021-01-15 19:31:25 +0100 <ezzieyguywuf> hm, I think I'm starting to understand, my issue is not at compile-time it is at run-time
2021-01-15 19:34:00 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net)
2021-01-15 19:36:40 +0100whyworxbutok(a7072803@167.7.40.3) (Quit: Connection closed)
2021-01-15 19:37:03 +0100christo(~chris@81.96.113.213)
2021-01-15 19:38:12 +0100 <ezzieyguywuf> I believe this is the issue I'm seeing!!! https://github.com/sol/doctest/issues/119
2021-01-15 19:38:50 +0100 <glguy> that does look like a pretty tight fit to what you've described
2021-01-15 19:38:57 +0100geekosaur(42d52137@66.213.33.55) (Ping timeout: 248 seconds)
2021-01-15 19:39:41 +0100ClaudiusMaximus(~claude@unaffiliated/claudiusmaximus) (Quit: ->)
2021-01-15 19:40:18 +0100 <ezzieyguywuf> yea, especially this comment describes it exactly https://github.com/sol/doctest/issues/119#issuecomment-415820972
2021-01-15 19:40:54 +0100Spiff(~quassel@102.160.161.107) (Ping timeout: 260 seconds)
2021-01-15 19:44:15 +0100tsaka__(~torstein@athedsl-316921.home.otenet.gr) (Read error: Connection reset by peer)
2021-01-15 19:44:46 +0100 <ezzieyguywuf> nice: so `cabal v1-configure; cabal v1-build; cabal v1-doctest` resolves the problem
2021-01-15 19:45:05 +0100 <ezzieyguywuf> I'm still left wondering why it hasn't (yet?) been ported to v2, but it def seems I'm on the right path
2021-01-15 19:45:28 +0100tsaka__(~torstein@athedsl-316921.home.otenet.gr)
2021-01-15 19:45:30 +0100 <merijn> doctest is *hard*
2021-01-15 19:46:29 +0100 <ezzieyguywuf> lol
2021-01-15 19:46:49 +0100 <ezzieyguywuf> it seems to be more hard than it's worth honestly, I wonder what the payoff is
2021-01-15 19:47:01 +0100 <merijn> I think it works in v1 because, essentially, v1 is pretty unprincipled and ad hoc
2021-01-15 19:50:08 +0100hnOsmium0001(uid453710@gateway/web/irccloud.com/x-mbazhcqiqbqsbhaw)
2021-01-15 19:54:28 +0100geekosaur(42d52137@66.213.33.55)
2021-01-15 19:55:30 +0100mouseghost(~draco@87-206-9-185.dynamic.chello.pl)
2021-01-15 19:55:30 +0100mouseghost(~draco@87-206-9-185.dynamic.chello.pl) (Changing host)
2021-01-15 19:55:30 +0100mouseghost(~draco@wikipedia/desperek)
2021-01-15 19:56:01 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 264 seconds)
2021-01-15 19:56:35 +0100gzj(~gzj@unaffiliated/gzj)
2021-01-15 19:58:40 +0100carthia(~carthia@gateway/tor-sasl/carthia) (Quit: carthia)
2021-01-15 20:00:57 +0100ChanServ+o monochrom
2021-01-15 20:01:25 +0100monochrom-b Smerdyakov!*@*
2021-01-15 20:01:26 +0100smerdyakov(~dan@5.146.195.145)
2021-01-15 20:01:26 +0100ChanServ+b Smerdyakov!*@*
2021-01-15 20:01:26 +0100smerdyakovChanServBanned: don't*pick*on*newbies
2021-01-15 20:01:34 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-01-15 20:01:46 +0100ChanServ-b Smerdyakov!*@*
2021-01-15 20:02:44 +0100niekvand_(~niekvande@89.205.135.50)
2021-01-15 20:02:44 +0100smerdyakov(~dan@5.146.195.145)
2021-01-15 20:03:35 +0100berberman_(~berberman@unaffiliated/berberman)
2021-01-15 20:04:13 +0100berberman(~berberman@unaffiliated/berberman) (Ping timeout: 260 seconds)
2021-01-15 20:04:36 +0100recon_-_(~quassel@2602:febc:0:b6::6ca2) (Quit: No Ping reply in 180 seconds.)
2021-01-15 20:05:20 +0100conal(~conal@64.71.133.70)
2021-01-15 20:05:33 +0100conal(~conal@64.71.133.70) (Client Quit)
2021-01-15 20:05:54 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 256 seconds)
2021-01-15 20:05:55 +0100recon_-(~quassel@2602:febc:0:b6::6ca2)
2021-01-15 20:06:44 +0100elfets(~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) (Quit: Leaving)
2021-01-15 20:07:00 +0100jamm(~jamm@unaffiliated/jamm)
2021-01-15 20:07:25 +0100mmmattyx(uid17782@gateway/web/irccloud.com/x-vpawruibcbfaslfq) (Quit: Connection closed for inactivity)
2021-01-15 20:07:39 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 20:07:58 +0100christo(~chris@81.96.113.213)
2021-01-15 20:09:01 +0100mirrorbird(~psutcliff@2a00:801:446:b70b:607:9995:9930:4d27)
2021-01-15 20:09:34 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 20:10:02 +0100rwdrich(560395a9@cpc159427-cmbg20-2-0-cust424.5-4.cable.virginm.net)
2021-01-15 20:10:32 +0100hyperisco(~hyperisco@d24-57-249-233.home.cgocable.net)
2021-01-15 20:10:48 +0100conal(~conal@64.71.133.70)
2021-01-15 20:11:01 +0100Rudd0(~Rudd0@185.189.115.103) (Ping timeout: 264 seconds)
2021-01-15 20:11:22 +0100jamm(~jamm@unaffiliated/jamm) (Ping timeout: 246 seconds)
2021-01-15 20:12:12 +0100 <hyperisco> I have a list xs , and I have takeWhile p xs and dropWhile p xs … if takeWhile p xs evaluates first, I already know where dropWhile p xs starts. How can I share this knowledge?
2021-01-15 20:12:12 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-01-15 20:12:44 +0100christo(~chris@81.96.113.213)
2021-01-15 20:13:01 +0100 <merijn> eh, there was one in Data.List
2021-01-15 20:13:25 +0100Tario(~Tario@201.192.165.173)
2021-01-15 20:13:27 +0100 <merijn> Ah
2021-01-15 20:13:29 +0100 <merijn> :t span
2021-01-15 20:13:30 +0100 <lambdabot> (a -> Bool) -> [a] -> ([a], [a])
2021-01-15 20:13:36 +0100 <hyperisco> operationally, reaching the end of takeWhile p xs should assign the tail to a variable, and dropWhile p xs should read that variable or force takeWhile p xs if it is not assigned
2021-01-15 20:13:57 +0100 <merijn> hyperisco: It even mentions takeWhile + dropWhile in the docs :p
2021-01-15 20:15:02 +0100 <c_wraith> and the implementation is careful to be lazy enough to meet that operational guideline
2021-01-15 20:15:18 +0100 <xerox_> @src span
2021-01-15 20:15:18 +0100 <lambdabot> span _ xs@[] = (xs, xs)
2021-01-15 20:15:18 +0100 <lambdabot> span p xs@(x:xs') | p x = let (ys,zs) = span p xs' in (x:ys,zs)
2021-01-15 20:15:18 +0100 <lambdabot> | otherwise = ([],xs)
2021-01-15 20:15:38 +0100 <c_wraith> that's actually the implementation in base, which is uncommon. :P
2021-01-15 20:15:46 +0100dcoutts_(~duncan@33.14.75.194.dyn.plus.net) (Ping timeout: 256 seconds)
2021-01-15 20:15:54 +0100 <c_wraith> The @src command doesn't usually give back the real implementation
2021-01-15 20:16:15 +0100ukari(~ukari@unaffiliated/ukari) (Remote host closed the connection)
2021-01-15 20:16:16 +0100cyphase(~cyphase@unaffiliated/cyphase) (Ping timeout: 246 seconds)
2021-01-15 20:16:19 +0100 <hyperisco> is that stack safe?
2021-01-15 20:16:25 +0100christo(~chris@81.96.113.213) (Remote host closed the connection)
2021-01-15 20:16:50 +0100ukari(~ukari@unaffiliated/ukari)
2021-01-15 20:17:01 +0100christo(~chris@81.96.113.213)
2021-01-15 20:17:06 +0100cyphase(~cyphase@unaffiliated/cyphase)
2021-01-15 20:17:28 +0100 <hyperisco> I guess the recursion is guarded as long as the tuple pattern match is lazy, but I don't think it is
2021-01-15 20:18:06 +0100 <c_wraith> I don't see a case on the tuple
2021-01-15 20:18:27 +0100 <hyperisco> do you know how let patterns are desugared?
2021-01-15 20:18:31 +0100 <c_wraith> yes
2021-01-15 20:18:39 +0100 <c_wraith> they're irrefutable matches
2021-01-15 20:18:47 +0100 <hyperisco> oh, okay
2021-01-15 20:19:06 +0100kupi(uid212005@gateway/web/irccloud.com/x-ljwqugooccinbszd) (Quit: Connection closed for inactivity)
2021-01-15 20:20:56 +0100 <jfe> hi all. has anyone thought of building a "big data" frontend for haskell? seems like lazy evaluation would be a good fit for that space.
2021-01-15 20:21:19 +0100 <merijn> Define "big data"
2021-01-15 20:21:30 +0100 <merijn> In my experience basically no one has big data to begin with >.>
2021-01-15 20:21:30 +0100 <jfe> no.
2021-01-15 20:21:34 +0100 <jfe> :)
2021-01-15 20:21:47 +0100christo(~chris@81.96.113.213) (Ping timeout: 256 seconds)
2021-01-15 20:21:50 +0100 <merijn> Oh well, then it's easy
2021-01-15 20:21:57 +0100 <merijn> "Yes, no, maybe, it depends"
2021-01-15 20:22:19 +0100 <jfe> i agree with you, hardly anyone has the scale of data necessary to justify the tools.
2021-01-15 20:22:50 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 265 seconds)
2021-01-15 20:22:51 +0100 <jfe> that's a separate topic though. i'm saying, for those who do...
2021-01-15 20:22:59 +0100 <jfe> s/saying/asking/
2021-01-15 20:23:16 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-01-15 20:23:38 +0100 <merijn> tbh, laziness isn't really that desirable for that anyway. You'd sooner want something like the streaming libraries instead
2021-01-15 20:23:46 +0100sakirious(~sakirious@c-71-197-191-137.hsd1.wa.comcast.net) (Quit: The Lounge - https://thelounge.chat)
2021-01-15 20:25:03 +0100sakirious(~sakirious@c-71-197-191-137.hsd1.wa.comcast.net)
2021-01-15 20:25:03 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Remote host closed the connection)
2021-01-15 20:25:06 +0100sakirious(~sakirious@c-71-197-191-137.hsd1.wa.comcast.net) (Client Quit)
2021-01-15 20:25:30 +0100dcoutts_(~duncan@33.14.75.194.dyn.plus.net)
2021-01-15 20:25:36 +0100fradet(~glenda@216.252.75.247) (Ping timeout: 240 seconds)
2021-01-15 20:25:47 +0100 <dminuoso> Re "big data". It kind of reminds me how often I hear people talking about "we have this big database", just to realize they have talkes with a few hundred thousand rows...
2021-01-15 20:26:12 +0100 <dminuoso> *tables
2021-01-15 20:26:36 +0100 <merijn> dminuoso: Oh, my SQLite database is big data, then \o/
2021-01-15 20:27:43 +0100 <dminuoso> merijn: Well the term "big data" is just a buzzword people throw around with their circlejerk buddies. It has no coherent meaning, but managers do like it because they confuse correlation and causality, hoping that if they too accumulate data like Google, they will become a tech giant..
2021-01-15 20:28:03 +0100o1lo01ol1o(~o1lo01ol1@bl11-140-216.dsl.telepac.pt) (Remote host closed the connection)
2021-01-15 20:28:07 +0100 <dminuoso> And you can just use it everywhere and impress the other folks who are just as clueless are you.
2021-01-15 20:28:12 +0100iteratee(~kyle@162.211.154.4) (Read error: Connection reset by peer)
2021-01-15 20:28:39 +0100o1lo01ol1o(~o1lo01ol1@bl11-140-216.dsl.telepac.pt)
2021-01-15 20:29:12 +0100 <dminuoso> On a technical level, it frequently is about people having terribly inefficient programs and datahousing, and lack of algorithmic skills...
2021-01-15 20:29:12 +0100 <c_wraith> It's fun that even people who are tech-savvy in general seem to not understand just how fast computers are. A million records? That's nothing for a linear scan!
2021-01-15 20:29:28 +0100 <dminuoso> But hey, if you can just throw machine learning on it, you have two cyber technologies now.
2021-01-15 20:29:28 +0100 <__monty__> Can we at least posit a lower bound, something like "If it fits on a single machine, it's not big data."
2021-01-15 20:30:27 +0100 <monochrom> Yes, I usually do that.
2021-01-15 20:31:03 +0100 <monochrom> Note that it is time varying (every year, even new PCs get a larger disk). But it's OK.
2021-01-15 20:31:19 +0100iteratee(~kyle@162.211.154.4)
2021-01-15 20:31:30 +0100 <c_wraith> reminds me of an older book on managing large datasets. It's actually a pretty good book. But it's old enough that the title is "Managing Gigabytes". These days, you do that by "loading it into RAM".
2021-01-15 20:31:50 +0100 <dminuoso> My main problem with "big data" is how relative it is. Say you have two datasets of a billion rows, and you want to find some common dataset between them, you could either be smart and perhaps sort them in some manner or put them into a datastructure and operate on them..
2021-01-15 20:32:13 +0100 <dminuoso> Or you just give up, do the naive brute force attempt, and fail because its computationally too expensive, label it as "big data", and have your reason to buy expensive "big data analyst tool"
2021-01-15 20:32:50 +0100 <MrMobius> I dont think thats what they mean by big data
2021-01-15 20:33:00 +0100 <monochrom> I also want to point out that serious, professional, niche big data exists. It is just that average people want to look impressive by hijacking the name for their puny problem domains, spoiling the whole thing.
2021-01-15 20:33:18 +0100kritzefitz(~kritzefit@212.86.56.80)
2021-01-15 20:33:32 +0100 <dminuoso> Right.
2021-01-15 20:33:33 +0100 <monochrom> At the scale of Google, Microsoft, and NSA, they do have big data.
2021-01-15 20:33:49 +0100o1lo01ol1o(~o1lo01ol1@bl11-140-216.dsl.telepac.pt) (Ping timeout: 264 seconds)
2021-01-15 20:34:04 +0100 <monochrom> But every one-person company is also going to claim "I have big data" and "I want to motivate my employees like Google does".
2021-01-15 20:34:21 +0100wonko7(~wonko7@2a01:e35:2ffb:7040:55a5:81b6:6cbc:13ed)
2021-01-15 20:34:32 +0100 <merijn> monochrom: By crushing any rumours of unionization? >.>
2021-01-15 20:34:32 +0100 <monochrom> Fact: If you don't spend big money, you don't have big data and you have nothing to motivate your employees.
2021-01-15 20:34:59 +0100 <monochrom> Heh, but they also free gourmet food and free game rooms.
2021-01-15 20:35:10 +0100 <monochrom> s/also/offer/
2021-01-15 20:35:54 +0100 <monochrom> probably better wording: "I want my employees to be as motivated as Google employees"
2021-01-15 20:36:19 +0100 <dminuoso> monochrom: Id phrase it differently: big data is when you have highly skilled teams that just can't engineer solutions for the amount of data your business already needs (!) anymore.
2021-01-15 20:36:36 +0100 <dminuoso> Most companies meddling with "big data" have neither skilled teams, nor do they rely on the data to begin with
2021-01-15 20:37:17 +0100 <merijn> I think we have drifted offtopic :p
2021-01-15 20:37:19 +0100 <dminuoso> (that was incomplete, "engineer solutions using regular algorithms and computers")
2021-01-15 20:37:20 +0100 <monochrom> nor do they provide gourmet food or game rooms
2021-01-15 20:39:01 +0100cheater(~user@unaffiliated/cheater) (Ping timeout: 246 seconds)
2021-01-15 20:39:22 +0100xsperry(~as@unaffiliated/xsperry) (Ping timeout: 246 seconds)
2021-01-15 20:39:35 +0100 <monochrom> nor "20% of your time can be on personal projects such as learning Haskell" to bring us back :)
2021-01-15 20:40:31 +0100 <hyperisco> not sure why I was having such a difficult time conceiving of how span works… thanks
2021-01-15 20:44:24 +0100cheater(~user@unaffiliated/cheater)
2021-01-15 20:45:02 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser) (Ping timeout: 264 seconds)
2021-01-15 20:45:50 +0100petrus_(~petrus@unaffiliated/petrus)
2021-01-15 20:47:59 +0100jespada(~jespada@90.254.245.49) (Quit: Leaving)
2021-01-15 20:51:29 +0100geekosaur(42d52137@66.213.33.55) (Ping timeout: 248 seconds)
2021-01-15 20:51:45 +0100o1lo01ol1o(~o1lo01ol1@bl11-140-216.dsl.telepac.pt)
2021-01-15 20:53:00 +0100 <ski> hyperisco : that tuple pattern match is not strict
2021-01-15 20:55:06 +0100dcoutts_(~duncan@33.14.75.194.dyn.plus.net) (Remote host closed the connection)
2021-01-15 20:55:29 +0100dcoutts_(~duncan@33.14.75.194.dyn.plus.net)
2021-01-15 20:57:21 +0100stef204(~stef204@unaffiliated/stef-204/x-384198)
2021-01-15 20:59:06 +0100maerwald(~maerwald@mail.hasufell.de) (Quit: gone)
2021-01-15 20:59:25 +0100maerwald(~maerwald@mail.hasufell.de)
2021-01-15 20:59:58 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691)
2021-01-15 21:00:32 +0100tomsen(~tomsen@2a02:908:1862:49e0::3)
2021-01-15 21:01:25 +0100tomsen_(~tomsen@ip-95-222-214-213.hsi15.unitymediagroup.de) (Read error: Connection reset by peer)
2021-01-15 21:02:26 +0100geekosaur(42d52137@66.213.33.55)
2021-01-15 21:03:39 +0100fresheyeball(~isaac@c-71-237-105-37.hsd1.co.comcast.net)
2021-01-15 21:04:46 +0100 <MrMuffles[m]> <monochrom "Heh, but they also free gourmet "> Gourmet food != motivation
2021-01-15 21:05:42 +0100justanotheruser(~justanoth@unaffiliated/justanotheruser)
2021-01-15 21:06:13 +0100tomsen_(~tomsen@2a02:908:1862:49e0::3)
2021-01-15 21:08:57 +0100tomsen(~tomsen@2a02:908:1862:49e0::3) (Ping timeout: 272 seconds)
2021-01-15 21:09:53 +0100 <Kronic> Does anyone know why I might be facing this issue? https://dpaste.org/yqv1 I setup a new IHP project after following the install instructions and generating a default hie.yaml using gen-hie, however it just explodes everytime I try to run the language server resulting in redlines everywhere in neovim
2021-01-15 21:10:16 +0100 <adamCS> I'm trying to serialize a set of things (in this case vinyl records) to a ByteString. I'm discovering that it is...difficult to do this in a way that doesn't leak memory. I'm using a streamly stream which reads lines from csv, parses the fields and constructs a vinyl Record. Each Record is serialized using cereal (toBS !x = runPut x $! put x). Given that, I've tried various things:
2021-01-15 21:10:39 +0100 <adamCS> 1. Convert each directly to strict ByteString and concatenate those directly. Slow but doesn't leak.
2021-01-15 21:11:09 +0100rwdrich(560395a9@cpc159427-cmbg20-2-0-cust424.5-4.cable.virginm.net) (Quit: Connection closed)
2021-01-15 21:11:11 +0100 <adamCS> 2. Convert each, then use fast-builder. That does leak.
2021-01-15 21:11:48 +0100 <adamCS> 3. Use the builder in the bytestring package. That leaks more! Thought I might be doing something very silly with strict vs. lazy bytestrings there.
2021-01-15 21:13:05 +0100cole-h(~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2021-01-15 21:13:07 +0100 <adamCS> I've even tried to use "deepseq" to force the vinyl Record to be converted somehow more strictly but that doesn't change anything, clarifying that I don't really understand what's happening.
2021-01-15 21:14:51 +0100 <adamCS> So my question, I guess, is if there is some way to get the memory footprint/no leak of the direct concatenation but the speed of something like the builder? Because my actual data is large enough that the leaky versions are bad.
2021-01-15 21:15:18 +0100 <adamCS> But also, I would just like to understand what is happening...
2021-01-15 21:15:44 +0100Tops2(~Tobias@dyndsl-095-033-020-049.ewe-ip-backbone.de) (Read error: Connection reset by peer)
2021-01-15 21:16:25 +0100alx741(~alx741@186.178.110.154) (Quit: alx741)
2021-01-15 21:16:39 +0100Noldorin(~noldorin@unaffiliated/noldorin) (Read error: Connection reset by peer)
2021-01-15 21:17:05 +0100gzj(~gzj@unaffiliated/gzj) (Ping timeout: 240 seconds)
2021-01-15 21:17:56 +0100alx741(~alx741@186.178.110.154)
2021-01-15 21:21:30 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 256 seconds)
2021-01-15 21:21:59 +0100howdoi(uid224@gateway/web/irccloud.com/x-vqsmakxboqrscwtf)
2021-01-15 21:25:39 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 21:25:51 +0100knupfer(~Thunderbi@200116b82c666e004ddb2b2b9fc7da22.dip.versatel-1u1.de) (Quit: knupfer)
2021-01-15 21:26:00 +0100knupfer(~Thunderbi@200116b82c666e002d3d942c4792ec8d.dip.versatel-1u1.de)
2021-01-15 21:26:13 +0100mmmattyx(uid17782@gateway/web/irccloud.com/x-apbaqdtxhenyxhsr)
2021-01-15 21:27:55 +0100knupfer(~Thunderbi@200116b82c666e002d3d942c4792ec8d.dip.versatel-1u1.de) (Client Quit)
2021-01-15 21:28:03 +0100knupfer(~Thunderbi@200116b82c666e00b88474aa382ddc75.dip.versatel-1u1.de)
2021-01-15 21:28:29 +0100phittacus(bklmatrixo@gateway/shell/matrix.org/x-gtuyyovhujfsszlo)
2021-01-15 21:29:07 +0100knupfer(~Thunderbi@200116b82c666e00b88474aa382ddc75.dip.versatel-1u1.de) (Client Quit)
2021-01-15 21:29:28 +0100knupfer(~Thunderbi@200116b82c666e00cdfc3c5562c54d9e.dip.versatel-1u1.de)
2021-01-15 21:29:40 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr)
2021-01-15 21:30:38 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2) (Ping timeout: 264 seconds)
2021-01-15 21:31:30 +0100 <nshepperd> isn't the Put type already a builder-like thing
2021-01-15 21:31:39 +0100Nahra(~Nahra@unaffiliated/nahra)
2021-01-15 21:31:48 +0100 <merijn> yes
2021-01-15 21:32:20 +0100 <merijn> Also
2021-01-15 21:32:27 +0100 <merijn> Consider using binary?
2021-01-15 21:32:28 +0100 <nshepperd> so why not directly traverse over the list with put
2021-01-15 21:33:28 +0100 <adamCS> nshepperd: I'll try directly with put. I've been on quite a wander so I might've missed that option.
2021-01-15 21:33:43 +0100rayyyy(~nanoz@gateway/tor-sasl/nanoz) (Ping timeout: 240 seconds)
2021-01-15 21:33:58 +0100 <adamCS> merijn: Why try binary for this?
2021-01-15 21:34:02 +0100 <nshepperd> what's the difference between binary and cereal
2021-01-15 21:34:22 +0100 <nshepperd> I've used both before and they seemed basically identical
2021-01-15 21:34:34 +0100 <glguy> cereal is more or less unmaintained and existed because binary didn't have the features it has now
2021-01-15 21:35:30 +0100Varis(~Tadas@unaffiliated/varis) (Remote host closed the connection)
2021-01-15 21:35:39 +0100 <merijn> cereal serialised to lazy ByteString
2021-01-15 21:35:49 +0100 <merijn> or was it strict?
2021-01-15 21:35:52 +0100 <merijn> I forget
2021-01-15 21:35:54 +0100 <glguy> cereal had a copy of binary's Put
2021-01-15 21:36:00 +0100 <merijn> either way, one was strict, the other was lazy
2021-01-15 21:36:05 +0100 <merijn> Now binary does both
2021-01-15 21:36:17 +0100 <merijn> And cereal is, indeed, mostly unmaintained afaik
2021-01-15 21:36:23 +0100 <glguy> cereal was for strict bytestrings and had support for isolating subregions with better error reporting
2021-01-15 21:36:48 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds)
2021-01-15 21:36:50 +0100 <glguy> and then binary stopped being as lazy and exposed a chunk-based interface
2021-01-15 21:37:17 +0100 <glguy> It came out of an IPsec implementation we did
2021-01-15 21:42:28 +0100 <adamCS> nsheppard: Using put directly is much leakier!
2021-01-15 21:42:40 +0100 <adamCS> I thnshepperd: ^
2021-01-15 21:42:48 +0100 <adamCS> nshepperd ^^
2021-01-15 21:43:05 +0100justsomeguy(~justsomeg@unaffiliated/--/x-3805311)
2021-01-15 21:44:38 +0100 <adamCS> using fast-builder, I think it's just the builder stuff itself that is accumulating? I don't see types from the Records themselves. Using put directly, I see acumulating bits os he records. The data, once a single bytestring, is about 10MB. The leaky version using fast builder grows to about 20MB. The put version grows to 115MB.
2021-01-15 21:45:00 +0100 <merijn> measured how?
2021-01-15 21:45:11 +0100 <glguy> Is the code online somewhere?
2021-01-15 21:45:13 +0100 <adamCS> Using heap profiling.
2021-01-15 21:45:21 +0100 <merijn> Also
2021-01-15 21:45:24 +0100 <merijn> Define leak :p
2021-01-15 21:45:29 +0100 <adamCS> It is but it is so very messy.
2021-01-15 21:45:50 +0100geekosaur(42d52137@66.213.33.55) (Quit: Connection closed)
2021-01-15 21:46:04 +0100 <adamCS> Right. Maybe that is just the cost I need to pay for the speed of the builder?
2021-01-15 21:46:14 +0100 <merijn> maybe?
2021-01-15 21:47:31 +0100 <adamCS> Though the put thing seems like a leak in the sense that my 100,000 records, which make a 10MB bytestring, generate 40MB of "&:" (a Record constructor) while the bytestring is being built.
2021-01-15 21:47:32 +0100dedede(~david@81.61.242.182.dyn.user.ono.com)
2021-01-15 21:47:32 +0100 <nshepperd> maybe you have too many !s
2021-01-15 21:48:11 +0100 <adamCS> And I'm pretty sure that I've done the biographical thing and a lot of those are "void" which, I think, means never used.
2021-01-15 21:48:18 +0100 <adamCS> But to be fair, that was a while back.
2021-01-15 21:48:38 +0100 <adamCS> nshepperd: ?
2021-01-15 21:49:53 +0100conal(~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2021-01-15 21:49:54 +0100geekosaur(42d52137@66.213.33.55)
2021-01-15 21:49:55 +0100tomsen_(~tomsen@2a02:908:1862:49e0::3) (Remote host closed the connection)
2021-01-15 21:50:14 +0100kw(d4662d5d@212.102.45.93)
2021-01-15 21:50:14 +0100heatsink(~heatsink@2600:1700:bef1:5e10:d4d8:4447:1149:eaf2)
2021-01-15 21:50:16 +0100tomsen_(~tomsen@2a02:908:1862:49e0::2)
2021-01-15 21:50:18 +0100thc202(~thc202@unaffiliated/thc202) (Quit: thc202)
2021-01-15 21:51:05 +0100 <nshepperd> using bang patterns to make things strict sometimes makes memory usage worse
2021-01-15 21:52:00 +0100 <adamCS> More generally, I have assorted situations where I have a stream of Records. Some folds of those streams do not "leak" (fair point that I am not defining that precisely), like a fold which uses mutable vectors to build a "Frame". But this fold to bytestring does, unless I concatenate each bytestring directly. And another which tries to put them in something like and Boxed vector (a streamly array type).
2021-01-15 21:53:09 +0100 <adamCS> nshepperd: so far, adding the "!" has resulted in the leaks being smaller, in the sense of peak memory reached to do the same task is overshooting the "no-leak" case by less.
2021-01-15 21:53:22 +0100 <adamCS> But I haven't tried all possible combinations.
2021-01-15 21:53:25 +0100 <adamCS> :)
2021-01-15 21:53:35 +0100dedede(~david@81.61.242.182.dyn.user.ono.com) (Quit: Leaving)
2021-01-15 21:53:46 +0100conal(~conal@64.71.133.70)
2021-01-15 21:53:46 +0100conal(~conal@64.71.133.70) (Client Quit)
2021-01-15 21:53:49 +0100 <kw> Does the Functor law `forall f g. fmap g . fmap f  =  fmap (g . f)` conventionally include the case of `g _ = ()` and `f = undefined`? Or are strict tuple Functor instances given a pass?
2021-01-15 21:54:08 +0100conal(~conal@64.71.133.70)
2021-01-15 21:54:08 +0100conal(~conal@64.71.133.70) (Client Quit)
2021-01-15 21:54:59 +0100conal(~conal@64.71.133.70)
2021-01-15 21:55:05 +0100 <nshepperd> maybe the problem is that streamly isn't lazy enough
2021-01-15 21:55:11 +0100conal(~conal@64.71.133.70) (Client Quit)
2021-01-15 21:55:19 +0100geowiesnot(~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 246 seconds)
2021-01-15 21:55:23 +0100philopsos(~caecilius@gateway/tor-sasl/caecilius) (Ping timeout: 240 seconds)
2021-01-15 21:55:31 +0100notzmv(~user@unaffiliated/zmv)
2021-01-15 21:56:03 +0100 <merijn> kw: Laws are generally specified as being in a total language
2021-01-15 21:56:14 +0100 <adamCS> nshepperd: I think I can test that...I can fold the stream to a lazy list and then mconcat that?
2021-01-15 21:56:15 +0100 <merijn> kw: See also "Fast and Loose Reasoning is Morally Correct"
2021-01-15 21:57:10 +0100 <kw> Thanks, merijn.
2021-01-15 21:57:26 +0100 <nshepperd> that probably won't help
2021-01-15 21:57:49 +0100 <monochrom> `g _ = ()` and `f = undefined` still satisfies the functor law for [] and Maybe.
2021-01-15 21:57:51 +0100 <merijn> kw: So no one (except a tiny handful of people) cares about strictness of laws, since (at worst) some code that shouldn't work, works anyway
2021-01-15 21:58:12 +0100 <monochrom> strict tuple can be the oddball here, depending on which category you have in mind.
2021-01-15 21:58:51 +0100conal(~conal@64.71.133.70)
2021-01-15 21:59:14 +0100 <monochrom> In most categories that fit well with Haskell's non-strictness, strict tuple is the ignored one because it doesn't stand for product. (vanilla tuple does.)
2021-01-15 21:59:52 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net) (Ping timeout: 246 seconds)
2021-01-15 22:01:11 +0100 <nshepperd> adamCS: try folding over your stream with foldr to create the Put action
2021-01-15 22:01:20 +0100 <kw> @monochrom: Aside from being able to use `seq` to test whether `x :: Vanilla (a, b)` is `undefined` or `Vanilla (undefined, undefined)`.
2021-01-15 22:01:20 +0100 <lambdabot> Unknown command, try @list
2021-01-15 22:01:29 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 260 seconds)
2021-01-15 22:01:40 +0100 <merijn> adamCS: Anyway, if you're serialising 100k records you probably wanna use some streaming solution anyway
2021-01-15 22:01:49 +0100 <adamCS> nshepperd: Okay..couple minutes...
2021-01-15 22:03:05 +0100 <nshepperd> actually no, you need to produce the bytestring within that fold too somehow i think
2021-01-15 22:03:20 +0100 <merijn> binary-conduit or something like that
2021-01-15 22:03:22 +0100 <adamCS> merijn: Yes. Although loading to Frame works and I often have the much larger (25 Million records) data set in that form. It's these other conversions that cause issues.
2021-01-15 22:03:47 +0100Noldorin(~noldorin@unaffiliated/noldorin)
2021-01-15 22:03:49 +0100conal(~conal@64.71.133.70) (Ping timeout: 264 seconds)
2021-01-15 22:04:01 +0100petrus_(~petrus@unaffiliated/petrus) (Quit: WeeChat 3.0)
2021-01-15 22:04:10 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr)
2021-01-15 22:04:52 +0100 <adamCS> merijn: Not everything that I do with the data can happen in streaming form.
2021-01-15 22:05:51 +0100Vulfe(~vulfe@rrcs-23-246-119-132.nys.biz.rr.com)
2021-01-15 22:06:36 +0100 <adamCS> And once I get the data as a frame, it's fine. But I'm also trying to cache it, on disk and in memory, and that requires rare-but-not-unique loading from csv to records to bytestring, etc.
2021-01-15 22:07:20 +0100elliott_(~elliott_@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 22:08:36 +0100geowiesnot(~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 240 seconds)
2021-01-15 22:08:47 +0100 <nshepperd> foldr (\x xs -> let b = runPut (put x) in seq b (ByteString.fromStrict b <> xs)) or something
2021-01-15 22:09:17 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-01-15 22:10:10 +0100 <nshepperd> nah, that won't work either
2021-01-15 22:10:12 +0100 <adamCS> nshepperd: I'll try that. Lazy list was very bad!
2021-01-15 22:10:19 +0100 <adamCS> nshepperd: Okay!
2021-01-15 22:10:22 +0100 <nshepperd> streaming libraries are the worst
2021-01-15 22:11:02 +0100 <adamCS> nshepperd: why?
2021-01-15 22:12:01 +0100 <nshepperd> because they're not lazy lists lol
2021-01-15 22:12:45 +0100 <adamCS> nshepperd: you were thinking foldr because it's like composing functions rather than accumulating results?
2021-01-15 22:13:02 +0100 <adamCS> which is what the Builders are doing also, somehow?
2021-01-15 22:13:17 +0100mnrmnaugh(~mnrmnaugh@unaffiliated/mnrmnaugh)
2021-01-15 22:13:22 +0100son0p(~son0p@181.136.122.143)
2021-01-15 22:13:58 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 256 seconds)
2021-01-15 22:14:08 +0100 <kw> Could be wrong about this but I think Builders just perform unsafe IO on a large mutable buffer.
2021-01-15 22:15:10 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 256 seconds)
2021-01-15 22:15:47 +0100awk(~mnrmnaugh@unaffiliated/mnrmnaugh)
2021-01-15 22:15:54 +0100 <kw> :)
2021-01-15 22:16:07 +0100 <adamCS> kw: Then the "leak" is more confusing. Then I'd think the heap profile would step up as that buffer is grown and then stop. But it goes up linearly.
2021-01-15 22:17:02 +0100ADG1089__(~aditya@122.163.165.143) (Remote host closed the connection)
2021-01-15 22:17:28 +0100 <adamCS> When I concatenate the strict bytestrings I get the stepping, which makes sense to me. But the linear thing is something allocating as each record is processed.
2021-01-15 22:17:46 +0100 <Kronic> Anyone catch my question from earlier?
2021-01-15 22:17:53 +0100ADG1089_(~adg1089@27.63.60.143)
2021-01-15 22:18:52 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56) (Quit: p-core)
2021-01-15 22:18:53 +0100ADG1089_(~adg1089@27.63.60.143) (Read error: Connection reset by peer)
2021-01-15 22:18:55 +0100 <nshepperd> your stream is like a reified loop in IO
2021-01-15 22:19:25 +0100p-core(~Thunderbi@2001:718:1e03:5128:3697:eeda:19aa:8e56)
2021-01-15 22:19:29 +0100 <nshepperd> you need to somehow interleave writing the output bytestring with the io that reads the input
2021-01-15 22:20:19 +0100niekvand_(~niekvande@89.205.135.50) (Remote host closed the connection)
2021-01-15 22:21:37 +0100_noblegas(uid91066@gateway/web/irccloud.com/x-nggbacvcifzzsyid) (Quit: Connection closed for inactivity)
2021-01-15 22:22:06 +0100mctpyt(~mctpyt@unaffiliated/mctpyt)
2021-01-15 22:22:08 +0100niekvand_(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 22:22:14 +0100 <adamCS> nshepperd: That almost makes sense to me! But why?
2021-01-15 22:22:41 +0100kw(d4662d5d@212.102.45.93) (Ping timeout: 248 seconds)
2021-01-15 22:25:08 +0100 <adamCS> nshepperd: I mean, that's kind of what happens in the direct concat case, right? I'm just building it one record worth of ByteString at a time.
2021-01-15 22:26:28 +0100niekvand_(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 246 seconds)
2021-01-15 22:28:22 +0100 <nshepperd> in theory yes, but i dunno if that will automatically evaluate things in the right order
2021-01-15 22:30:57 +0100Noldorin(~noldorin@unaffiliated/noldorin) (Quit: Textual IRC Client: www.textualapp.com)
2021-01-15 22:31:05 +0100 <nshepperd> foldl' (\acc x -> let b = runPut (put x) in seq b (acc <> toBuilder b)) mempty
2021-01-15 22:32:13 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691) (Quit: brodie)
2021-01-15 22:32:23 +0100fnurglewitz(uid263868@gateway/web/irccloud.com/x-yezkpczvtftthifl)
2021-01-15 22:33:39 +0100 <nshepperd> this one should result in all the bytestrings existing in memory at once, but not the records
2021-01-15 22:33:50 +0100 <nshepperd> (use strict bytestring)
2021-01-15 22:34:02 +0100 <itai33[m]> is a @since haddock appropriate when you just change the type of a function?
2021-01-15 22:34:04 +0100 <adamCS> nshepperd: I'm going to try it!
2021-01-15 22:38:37 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691)
2021-01-15 22:42:03 +0100_ht(~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection)
2021-01-15 22:43:29 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 22:45:01 +0100jneira(501ca940@gateway/web/cgi-irc/kiwiirc.com/ip.80.28.169.64)
2021-01-15 22:45:21 +0100 <adamCS> nshepperd: fascinating. It does the right thing until, I think, I call the function to get the bytes from the builder. Then it spikes up to even higher than the version I had before. Slow direct concatenation steps up to about 10MB. My previous builder folds go linearly up to about 20MB. This one steps up to about 9MB, then goes fast linear to almost 30MB.
2021-01-15 22:45:59 +0100 <adamCS> nshepperd: But maybe that's an artifact of something else. Lemme try it all in IO...
2021-01-15 22:46:45 +0100 <fnurglewitz> hi, I'm trying to use servant's hoistServer to pass (with a reader) a context which could have more than 1 database implementations (eg. a TVar with a Map or a connection pool of a sql database), I defined a typeclass that defines the operations that this "DB" admits but I'm unsure on how I could put them inside the context type, can anyone point me to some code that does this pls?
2021-01-15 22:46:50 +0100ericsagnes(~ericsagne@2405:6580:0:5100:5879:2dc6:16a6:5fa5) (Ping timeout: 264 seconds)
2021-01-15 22:48:14 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691) (Quit: brodie)
2021-01-15 22:48:21 +0100fangyrn(uid481529@gateway/web/irccloud.com/x-qtoesenwjedcxvhm) (Quit: Connection closed for inactivity)
2021-01-15 22:49:08 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 272 seconds)
2021-01-15 22:49:10 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691)
2021-01-15 22:49:12 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691) (Client Quit)
2021-01-15 22:50:29 +0100son0p(~son0p@181.136.122.143) (Ping timeout: 260 seconds)
2021-01-15 22:50:30 +0100 <nshepperd> how mysterious
2021-01-15 22:51:18 +0100geekosaur(42d52137@66.213.33.55) (Quit: Connection closed)
2021-01-15 22:52:10 +0100elliott__(~elliott@pool-108-51-101-42.washdc.fios.verizon.net)
2021-01-15 22:53:10 +0100usr25(~usr25@unaffiliated/usr25)
2021-01-15 22:55:19 +0100elfets(~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de)
2021-01-15 22:56:07 +0100usr25(~usr25@unaffiliated/usr25) ()
2021-01-15 22:56:51 +0100 <mctpyt> hello! a question regarding internationalization, I've been trying to use hgettext but its dependencies seems to be broken, and I also found haskell-gettext and Shakespeare; are there any recommendations on which to use?, I'm not using Yesod and I'd prefer to have gettext, but I wonder which is the most popular approach on Haskell (I only found that Pandoc uses Shakespeare a little bit)
2021-01-15 22:58:18 +0100 <adamCS> nshepperd: Even weirder. In IO, that version looks like the others, linear growth to about 20MB. Previous version was in a Polysemy stack. Hadn't imagined that would matter but I may as well stay directly in IO for simplicity.
2021-01-15 22:58:40 +0100ericsagnes(~ericsagne@2405:6580:0:5100:3abe:a88c:1b2d:b08c)
2021-01-15 22:59:38 +0100Inoperable(~PLAYER_1@fancydata.science) (Excess Flood)
2021-01-15 23:00:43 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl)
2021-01-15 23:01:07 +0100awk(~mnrmnaugh@unaffiliated/mnrmnaugh) (Ping timeout: 246 seconds)
2021-01-15 23:02:03 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691)
2021-01-15 23:03:23 +0100Inoperable(~PLAYER_1@fancydata.science)
2021-01-15 23:04:35 +0100Rudd0(~Rudd0@185.189.115.108)
2021-01-15 23:07:25 +0100ubert(~Thunderbi@p200300ecdf1ee03ee02324fb94e406b3.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2021-01-15 23:07:49 +0100polyrain(~polyrain@2001:8003:e501:6901:1dd9:2fe6:ccd8:6fc9)
2021-01-15 23:13:02 +0100DataComputist(~lumeng@50.43.26.251)
2021-01-15 23:13:56 +0100stef204(~stef204@unaffiliated/stef-204/x-384198) (Ping timeout: 240 seconds)
2021-01-15 23:14:12 +0100 <ij> can I add {-# UNPACK #-}s in named records?
2021-01-15 23:15:02 +0100alx741(~alx741@186.178.110.154) (Quit: alx741)
2021-01-15 23:15:18 +0100 <dolio> Yes.
2021-01-15 23:16:02 +0100vst(~vst@2406:3003:2004:2e8a:eca7:1543:921c:b50a)
2021-01-15 23:16:04 +0100 <monochrom> Pretty sure the GHC user's guide has examples of exactly how to do it.
2021-01-15 23:16:09 +0100 <ij> ah, the unpacks and bangs go before types no matter how
2021-01-15 23:16:11 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-01-15 23:16:17 +0100stef204(~stef204@unaffiliated/stef-204/x-384198)
2021-01-15 23:16:26 +0100 <ij> monochrom, yeah, but only on unnamed records – couldn't connect the dots
2021-01-15 23:16:51 +0100 <adamCS> nshepperd: That version was using fast-builder and strict bytestrings. Switched out for the builder in the bytestring package--thus building with lazy bytestrings--that one is much worse, as I think you knew it would be. Thanks for all the help! I'm just going to have to try more things or put up with the slowness of direct concatenation...
2021-01-15 23:18:00 +0100 <monochrom> Yikes, it doesn't.
2021-01-15 23:19:16 +0100notzmv(~user@unaffiliated/zmv) (Ping timeout: 240 seconds)
2021-01-15 23:20:55 +0100alx741(~alx741@181.196.68.16)
2021-01-15 23:21:55 +0100son0p(~son0p@181.136.122.143)
2021-01-15 23:22:03 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds)
2021-01-15 23:22:36 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-01-15 23:23:44 +0100coot(~coot@37.30.55.132.nat.umts.dynamic.t-mobile.pl) (Ping timeout: 260 seconds)
2021-01-15 23:23:52 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl)
2021-01-15 23:24:11 +0100kuribas(~user@ptr-25vy0iacr2x8efujlkt.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3))
2021-01-15 23:26:29 +0100Tario(~Tario@201.192.165.173)
2021-01-15 23:26:59 +0100Tario(~Tario@201.192.165.173) (Read error: Connection reset by peer)
2021-01-15 23:29:00 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 256 seconds)
2021-01-15 23:31:30 +0100knupfer(~Thunderbi@200116b82c666e00cdfc3c5562c54d9e.dip.versatel-1u1.de) (Remote host closed the connection)
2021-01-15 23:31:39 +0100knupfer(~Thunderbi@200116b82c666e0028b6767136b5847d.dip.versatel-1u1.de)
2021-01-15 23:32:13 +0100 <ij> does haskell language server support sorting imports?
2021-01-15 23:32:45 +0100polyrain(~polyrain@2001:8003:e501:6901:1dd9:2fe6:ccd8:6fc9) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 23:34:01 +0100niekvandepas(~niekvande@dhcp-077-249-088-250.chello.nl) (Ping timeout: 246 seconds)
2021-01-15 23:34:30 +0100 <ij> formatOnImportOn is probably not related
2021-01-15 23:35:47 +0100mmmattyx(uid17782@gateway/web/irccloud.com/x-apbaqdtxhenyxhsr) (Quit: Connection closed for inactivity)
2021-01-15 23:36:31 +0100Spiff(~quassel@102.160.161.107)
2021-01-15 23:37:42 +0100 <ep1ctetus> can anyone recommend a library to print record types nicely?
2021-01-15 23:38:09 +0100conjunctive(sid433686@gateway/web/irccloud.com/x-mvhsqhdjquopssnl) (Ping timeout: 246 seconds)
2021-01-15 23:38:09 +0100kip(sid71464@gateway/web/irccloud.com/x-pvovbezbvedanksd) (Ping timeout: 246 seconds)
2021-01-15 23:38:30 +0100affinespaces(sid327561@gateway/web/irccloud.com/x-topqtuxrgvpqgael) (Ping timeout: 246 seconds)
2021-01-15 23:38:48 +0100mudri(sid317655@gateway/web/irccloud.com/x-yceixeaikwokfiut) (Read error: Connection reset by peer)
2021-01-15 23:38:49 +0100dsal(sid13060@gateway/web/irccloud.com/x-uhinxzkjykjyzztk) (Read error: Connection reset by peer)
2021-01-15 23:38:49 +0100Boarders(sid425905@gateway/web/irccloud.com/x-smstehzqejvxsgsx) (Read error: Connection reset by peer)
2021-01-15 23:38:49 +0100dsturnbull(sid347899@gateway/web/irccloud.com/x-lybuwhzmiqnxosyj) (Read error: Connection reset by peer)
2021-01-15 23:38:58 +0100kip(sid71464@gateway/web/irccloud.com/x-iqwkdxaxsukyalqa)
2021-01-15 23:38:58 +0100dsturnbull(sid347899@gateway/web/irccloud.com/x-uwydaeimpczksxke)
2021-01-15 23:39:01 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:989c:f9b9:87c4:db9d) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 23:39:05 +0100Boarders(sid425905@gateway/web/irccloud.com/x-vslsedkkixwoisme)
2021-01-15 23:39:05 +0100conjunctive(sid433686@gateway/web/irccloud.com/x-mcpxbchitcsdjuun)
2021-01-15 23:39:05 +0100dsal(sid13060@gateway/web/irccloud.com/x-xcmmksyfygnrhaeu)
2021-01-15 23:39:11 +0100affinespaces(sid327561@gateway/web/irccloud.com/x-kwfevmsqfemkgjuy)
2021-01-15 23:39:41 +0100mudri(sid317655@gateway/web/irccloud.com/x-tykowpwgevxgkhqt)
2021-01-15 23:40:15 +0100bitonic(bitonicmat@gateway/shell/matrix.org/x-metwivhpxaujumkh) (Ping timeout: 246 seconds)
2021-01-15 23:40:36 +0100siraben(sirabenmat@gateway/shell/matrix.org/x-jucvqrunhvhrwair) (Ping timeout: 246 seconds)
2021-01-15 23:40:37 +0100sajith[m](sajithmatr@gateway/shell/matrix.org/x-smrjdwfdywihjlbm) (Ping timeout: 246 seconds)
2021-01-15 23:40:37 +0100johnnyboy[m](gifumatrix@gateway/shell/matrix.org/x-mdpxrkceozqnbnvt) (Ping timeout: 246 seconds)
2021-01-15 23:40:37 +0100noIOBeforeBedtim(dissatisfi@gateway/shell/matrix.org/x-dpzgelpmgtzaopdc) (Ping timeout: 246 seconds)
2021-01-15 23:40:52 +0100 <ij> so if I do stuff in IO and I want a MVector, then it's going to be MVector RealWorld a, because PrimState IO is RealWorld?
2021-01-15 23:40:57 +0100jeffcasavant[m](jeffcasava@gateway/shell/matrix.org/x-pqdubrrqsciedjkz) (Ping timeout: 246 seconds)
2021-01-15 23:40:57 +0100Poscat[m](poscatmatr@gateway/shell/matrix.org/x-ebjpmkbyptcfrkby) (Ping timeout: 246 seconds)
2021-01-15 23:40:57 +0100sigmacool[m](sigmacoolm@gateway/shell/matrix.org/x-mdwbqjiwxrqtfkyd) (Ping timeout: 246 seconds)
2021-01-15 23:41:18 +0100Spiff(~quassel@102.160.161.107) (Ping timeout: 256 seconds)
2021-01-15 23:42:00 +0100drupol(sid117588@gateway/web/irccloud.com/x-eyueysrhujknypzd) (Ping timeout: 246 seconds)
2021-01-15 23:42:43 +0100 <sm[m]> ep1ctetus: pretty-simple
2021-01-15 23:44:19 +0100slack1256(~slack1256@dvc-186-186-101-190.movil.vtr.net)
2021-01-15 23:44:48 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:989c:f9b9:87c4:db9d)
2021-01-15 23:45:14 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas)
2021-01-15 23:45:23 +0100danvet(~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa) (Ping timeout: 272 seconds)
2021-01-15 23:45:38 +0100brodie(~brodie@2607:f598:b992:f800:bd82:b9a4:7938:2691) (Quit: brodie)
2021-01-15 23:46:22 +0100jess(jess@freenode/staff/jess) (Quit: Leaving)
2021-01-15 23:46:27 +0100 <ij> why does the MVector need (PrimState m) as a type argument?
2021-01-15 23:47:17 +0100 <ij> (type parameters is the accepted terminology, I guess)
2021-01-15 23:48:08 +0100 <ep1ctetus> sm[m], thank you
2021-01-15 23:49:24 +0100 <ep1ctetus> this is excellent
2021-01-15 23:53:44 +0100nbloomf(~nbloomf@2600:1700:ad14:3020:989c:f9b9:87c4:db9d) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-01-15 23:53:48 +0100bitonic(bitonicmat@gateway/shell/matrix.org/x-zzyfhzjahtjmslqn)
2021-01-15 23:53:50 +0100noIOBeforeBedtim(dissatisfi@gateway/shell/matrix.org/x-miyoqdfcixkdjcae)
2021-01-15 23:54:17 +0100Franciman(~francesco@host-82-48-174-127.retail.telecomitalia.it) (Quit: Leaving)
2021-01-15 23:55:03 +0100sajith[m](sajithmatr@gateway/shell/matrix.org/x-btcvxzbdjqkrkiwi)
2021-01-15 23:55:06 +0100drupol(sid117588@gateway/web/irccloud.com/x-lkgibdqlgsuwbeph)
2021-01-15 23:55:14 +0100johnnyboy[m](gifumatrix@gateway/shell/matrix.org/x-bjzclgwfdthdnzpg)
2021-01-15 23:55:55 +0100Codaraxis_(~Codaraxis@ip68-5-90-227.oc.oc.cox.net)
2021-01-15 23:56:43 +0100siraben(sirabenmat@gateway/shell/matrix.org/x-pjokmvoqmjklmznu)
2021-01-15 23:56:44 +0100Codaraxis(~Codaraxis@91.193.4.10) (Read error: Connection reset by peer)
2021-01-15 23:56:48 +0100qz(~quetzal@li272-85.members.linode.com) (Quit: WeeChat 2.9)
2021-01-15 23:57:09 +0100Gurkenglas(~Gurkengla@unaffiliated/gurkenglas) (Read error: Connection reset by peer)
2021-01-15 23:57:25 +0100sigmacool[m](sigmacoolm@gateway/shell/matrix.org/x-wncuswjxghpgivhm)
2021-01-15 23:57:49 +0100merijn(~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 246 seconds)
2021-01-15 23:57:51 +0100rawles(~r@unaffiliated/rawles) (Ping timeout: 268 seconds)
2021-01-15 23:57:51 +0100gluegadget(sid22336@gateway/web/irccloud.com/x-msgsyimkpfzfdplm) (Ping timeout: 268 seconds)
2021-01-15 23:57:51 +0100srhb(sid400352@NixOS/user/srhb) (Ping timeout: 268 seconds)
2021-01-15 23:57:51 +0100kristjansson(sid126207@gateway/web/irccloud.com/x-kjqkrwfhxeyivisw) (Ping timeout: 268 seconds)
2021-01-15 23:57:51 +0100jonrh(sid5185@gateway/web/irccloud.com/x-hntqrgohvgwoczvy) (Ping timeout: 268 seconds)
2021-01-15 23:57:51 +0100zzz(~zzz@2a03:b0c0:3:d0::3095:3001) (Ping timeout: 268 seconds)
2021-01-15 23:58:16 +0100kyagrd__(sid102627@gateway/web/irccloud.com/x-ypgrgcqphmltykqe) (Read error: Connection reset by peer)
2021-01-15 23:58:16 +0100milessabin(sid86799@gateway/web/irccloud.com/x-tvcbhvvpnfvrhwif) (Read error: Connection reset by peer)
2021-01-15 23:58:16 +0100taktoa[c](sid282096@gateway/web/irccloud.com/x-qzdgtblpiialqhic) (Read error: Connection reset by peer)
2021-01-15 23:58:16 +0100natim87(sid286962@gateway/web/irccloud.com/x-nksbbmqvaevagztw) (Read error: Connection reset by peer)
2021-01-15 23:58:16 +0100wpcarro_(sid397589@gateway/web/irccloud.com/x-cihesreymldlqpdf) (Read error: Connection reset by peer)
2021-01-15 23:58:16 +0100ebutleriv(sid217783@gateway/web/irccloud.com/x-snsrtsqpsqwwbfgf) (Write error: Connection reset by peer)
2021-01-15 23:58:16 +0100AndreasK(uid320732@gateway/web/irccloud.com/x-vdseamlbfcbchsil) (Write error: Connection reset by peer)
2021-01-15 23:58:16 +0100joshmeredith(sid387798@gateway/web/irccloud.com/x-fznswsrrgymxksrk) (Read error: Network is unreachable)
2021-01-15 23:58:16 +0100edwinb(sid69486@gateway/web/irccloud.com/x-vtbwkodqpgkvptre) (Read error: Connection reset by peer)
2021-01-15 23:58:17 +0100brown121407(~brown1214@fsf/member/brown121407) (Remote host closed the connection)
2021-01-15 23:58:18 +0100cemerick(sid54985@gateway/web/irccloud.com/x-hvytxjnfgkcybten) (Read error: Connection reset by peer)
2021-01-15 23:58:19 +0100Kronic(sid480486@gateway/web/irccloud.com/x-yefsgwxmddskyzbm) (Read error: Connection reset by peer)
2021-01-15 23:58:19 +0100alanz(sid110616@gateway/web/irccloud.com/x-prwdeyzwdytgtxkp) (Read error: Connection reset by peer)
2021-01-15 23:58:19 +0100d0liver(sid363046@gateway/web/irccloud.com/x-tttmhfenawofeixc) (Read error: Connection reset by peer)
2021-01-15 23:58:20 +0100typetetris(sid275937@gateway/web/irccloud.com/x-wukxokdildxlsinc) (Read error: Connection reset by peer)
2021-01-15 23:58:21 +0100ocharles(sid30093@musicbrainz/user/ocharles) (Read error: Connection reset by peer)
2021-01-15 23:58:21 +0100hazard-pointer(sid331723@gateway/web/irccloud.com/x-nmwklpcxqbimwbcx) (Read error: Connection reset by peer)
2021-01-15 23:58:21 +0100kozowu(uid44796@gateway/web/irccloud.com/x-lmrzkgcwuiqfijer) (Read error: Connection reset by peer)
2021-01-15 23:58:22 +0100johs(sid246410@gateway/web/irccloud.com/x-tafdqtulgzplanux) (Write error: Connection reset by peer)
2021-01-15 23:58:22 +0100PyroLagus(PyroLagus@i.have.ipv6.on.coding4coffee.org) (Quit: ZNC / WeeChat)
2021-01-15 23:58:24 +0100betawaffle(sid2730@gateway/web/irccloud.com/x-iqipatfmsyxtpnsb) (Read error: Connection reset by peer)
2021-01-15 23:58:24 +0100graingert(sid128301@gateway/web/irccloud.com/x-pvrbspgvxauvbmrf) (Read error: Connection reset by peer)
2021-01-15 23:58:24 +0100agander_m(sid407952@gateway/web/irccloud.com/x-godagyxukcquqjck) (Read error: Connection reset by peer)
2021-01-15 23:58:27 +0100milessabin(sid86799@gateway/web/irccloud.com/x-tsfirmfaeyltehov)
2021-01-15 23:58:27 +0100taktoa[c](sid282096@gateway/web/irccloud.com/x-pvznddqjvryzvklu)
2021-01-15 23:58:27 +0100srhb(sid400352@NixOS/user/srhb)
2021-01-15 23:58:29 +0100jonrh(sid5185@gateway/web/irccloud.com/x-xhkeplnurjzdkwie)
2021-01-15 23:58:30 +0100cemerick(sid54985@gateway/web/irccloud.com/x-uyhbshivnlrcdkep)
2021-01-15 23:58:30 +0100alanz(sid110616@gateway/web/irccloud.com/x-dtfqgsafddbupptz)
2021-01-15 23:58:31 +0100wpcarro_(sid397589@gateway/web/irccloud.com/x-muqwknpzlwpmqqkn)
2021-01-15 23:58:31 +0100joshmeredith(sid387798@gateway/web/irccloud.com/x-ywduelldbxnktgum)
2021-01-15 23:58:31 +0100ocharles(sid30093@musicbrainz/user/ocharles)
2021-01-15 23:58:32 +0100d0liver(sid363046@gateway/web/irccloud.com/x-yxldiyijvvvoeqdg)
2021-01-15 23:58:35 +0100typetetris(sid275937@gateway/web/irccloud.com/x-mbcxqikjwssppdzb)
2021-01-15 23:58:36 +0100agander_m(sid407952@gateway/web/irccloud.com/x-cybrydutbcgtnfpa)
2021-01-15 23:58:36 +0100brown121407(~brown1214@2001:19f0:6c01:2b9c:3c66:4201:22f3:3ebc)
2021-01-15 23:58:36 +0100brown121407(~brown1214@2001:19f0:6c01:2b9c:3c66:4201:22f3:3ebc) (Changing host)
2021-01-15 23:58:36 +0100brown121407(~brown1214@fsf/member/brown121407)
2021-01-15 23:58:43 +0100Bigcheese_(~quassel@unaffiliated/bigcheese) (Remote host closed the connection)
2021-01-15 23:58:54 +0100kristjansson(sid126207@gateway/web/irccloud.com/x-yoqynwwbabnncebd)
2021-01-15 23:59:02 +0100kristjansson(sid126207@gateway/web/irccloud.com/x-yoqynwwbabnncebd) (Excess Flood)
2021-01-15 23:59:04 +0100edwinb(sid69486@gateway/web/irccloud.com/x-yclnpdvebbvtgqcs)
2021-01-15 23:59:08 +0100AndreasK(uid320732@gateway/web/irccloud.com/x-bidajccraqzbxuat)
2021-01-15 23:59:10 +0100natim87(sid286962@gateway/web/irccloud.com/x-icmknatlznhqfdmc)
2021-01-15 23:59:11 +0100hazard-pointer(sid331723@gateway/web/irccloud.com/x-yjgnwgppjbnutxrc)
2021-01-15 23:59:12 +0100Kronic(sid480486@gateway/web/irccloud.com/x-mmcorpzvbrtyqkwx)
2021-01-15 23:59:13 +0100johs(sid246410@gateway/web/irccloud.com/x-anopdybklwkzjevp)
2021-01-15 23:59:14 +0100kozowu(uid44796@gateway/web/irccloud.com/x-fbpunzzcmbyaebte)
2021-01-15 23:59:14 +0100kyagrd__(sid102627@gateway/web/irccloud.com/x-zawyiultvziwhzkq)
2021-01-15 23:59:19 +0100Poscat[m](poscatmatr@gateway/shell/matrix.org/x-fdhyfndynnizckdt)
2021-01-15 23:59:30 +0100wroathe(~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2021-01-15 23:59:31 +0100Tario(~Tario@201.192.165.173)
2021-01-15 23:59:34 +0100betawaffle(sid2730@gateway/web/irccloud.com/x-utpaisavhixlsaex)
2021-01-15 23:59:36 +0100graingert(sid128301@gateway/web/irccloud.com/x-zrbkfaqykndgofin)
2021-01-15 23:59:45 +0100kristjansson(sid126207@gateway/web/irccloud.com/x-lhbgfhvnarwdylff)
2021-01-15 23:59:46 +0100jeffcasavant[m](jeffcasava@gateway/shell/matrix.org/x-qbszcvejqtcqwzfd)
2021-01-15 23:59:48 +0100ebutleriv(sid217783@gateway/web/irccloud.com/x-verpyznohhsayxxo)
2021-01-15 23:59:49 +0100kristjansson(sid126207@gateway/web/irccloud.com/x-lhbgfhvnarwdylff) (Excess Flood)
2021-01-15 23:59:49 +0100gluegadget(sid22336@gateway/web/irccloud.com/x-gpdwingfejgfufvv)
2021-01-15 23:59:50 +0100beaky(~beaky@2a03:b0c0:0:1010::17cf:7003) (Read error: Connection reset by peer)
2021-01-15 23:59:51 +0100Bigcheese(~quassel@unaffiliated/bigcheese)
2021-01-15 23:59:52 +0100PyroLagus(PyroLagus@i.have.ipv6.on.coding4coffee.org)