IRCBrowse

2022/08/11

2022-08-11 00:00:02 +0200acidjnk_new(~acidjnk@p200300d6e7058614083d03ca0d10755f.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
2022-08-11 00:01:52 +0200Tuplanolla(~Tuplanoll@91-159-69-12.elisa-laajakaista.fi)
2022-08-11 00:02:14 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-11 00:02:45 +0200dcoutts_(~duncan@host86-167-206-78.range86-167.btcentralplus.com) (Remote host closed the connection)
2022-08-11 00:03:07 +0200dcoutts_(~duncan@host86-167-206-78.range86-167.btcentralplus.com)
2022-08-11 00:03:46 +0200Unode(~Unode@194.94.44.220) (Remote host closed the connection)
2022-08-11 00:04:57 +0200Unode(~Unode@194.94.44.220)
2022-08-11 00:08:09 +0200ph88(~ph88@ltea-178-013-121-150.pools.arcor-ip.net) (Remote host closed the connection)
2022-08-11 00:08:30 +0200ph88(~ph88@ltea-178-013-121-150.pools.arcor-ip.net)
2022-08-11 00:11:20 +0200malte(~malte@mal.tc)
2022-08-11 00:13:41 +0200ph88(~ph88@ltea-178-013-121-150.pools.arcor-ip.net) (Ping timeout: 268 seconds)
2022-08-11 00:13:49 +0200heartbur1(~gass@2a00:d880:3:1::b1e4:b241) (Quit: leaving)
2022-08-11 00:15:18 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 00:17:20 +0200heartburn(~gass@2a00:d880:3:1::b1e4:b241)
2022-08-11 00:18:05 +0200darchitect1(~darchitec@2a00:23c6:3584:df01:b208:b196:e5ae:769e)
2022-08-11 00:18:38 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 00:25:44 +0200califax(~califax@user/califx) (Read error: Connection reset by peer)
2022-08-11 00:25:44 +0200jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2022-08-11 00:25:44 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Write error: Broken pipe)
2022-08-11 00:25:44 +0200ec(~ec@gateway/tor-sasl/ec) (Write error: Connection reset by peer)
2022-08-11 00:25:44 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Write error: Connection reset by peer)
2022-08-11 00:25:44 +0200noteness(~noteness@user/noteness) (Write error: Connection reset by peer)
2022-08-11 00:25:44 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Write error: Broken pipe)
2022-08-11 00:25:44 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Write error: Broken pipe)
2022-08-11 00:25:44 +0200stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2022-08-11 00:26:09 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 00:26:12 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 00:26:21 +0200jpds(~jpds@gateway/tor-sasl/jpds)
2022-08-11 00:26:38 +0200califax(~califax@user/califx)
2022-08-11 00:26:41 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-11 00:26:54 +0200stiell(~stiell@gateway/tor-sasl/stiell)
2022-08-11 00:26:55 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 00:27:07 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-11 00:28:32 +0200noteness(~noteness@user/noteness)
2022-08-11 00:31:37 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 268 seconds)
2022-08-11 00:31:40 +0200 <glguy> dminuoso: I pushed out a version of config-schema that supports matching against arbitrary values instead of just atoms. I don't know if that's still useful to you, but it's on the response to your PR I made a while back
2022-08-11 00:32:43 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-11 00:37:40 +0200chele(~chele@user/chele) (Remote host closed the connection)
2022-08-11 00:41:52 +0200mmhat(~mmh@p200300f1c706f7beee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.6)
2022-08-11 00:42:02 +0200lsrts^(~lsrts@206.85.120.17) (Ping timeout: 268 seconds)
2022-08-11 00:44:35 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Quit: Leaving)
2022-08-11 00:49:25 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 00:51:36 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-11 00:51:56 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-11 00:54:38 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-11 00:55:13 +0200Sgeo(~Sgeo@user/sgeo)
2022-08-11 00:58:43 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 244 seconds)
2022-08-11 00:59:30 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Client Quit)
2022-08-11 01:00:12 +0200nate4(~nate@98.45.169.16)
2022-08-11 01:00:26 +0200luffy(~chenqisu1@183.217.201.23)
2022-08-11 01:05:27 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 01:18:30 +0200lsrts^(~lsrts@206.85.120.17)
2022-08-11 01:29:30 +0200moonsheep(~user@user/moonsheep) (Read error: Connection reset by peer)
2022-08-11 01:29:46 +0200moonsheep(~user@user/moonsheep)
2022-08-11 01:36:26 +0200darchitect1(~darchitec@2a00:23c6:3584:df01:b208:b196:e5ae:769e) (Ping timeout: 244 seconds)
2022-08-11 01:36:59 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec)
2022-08-11 01:38:01 +0200raym(~raym@user/raym) (Remote host closed the connection)
2022-08-11 01:41:17 +0200slack1256(~slack1256@wsip-184-177-0-226.no.no.cox.net) (Ping timeout: 255 seconds)
2022-08-11 01:41:43 +0200Tuplanolla(~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) (Quit: Leaving.)
2022-08-11 01:42:04 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 01:42:22 +0200raym(~raym@user/raym)
2022-08-11 01:42:30 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 01:42:48 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 01:44:21 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 01:56:39 +0200jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2022-08-11 01:57:09 +0200jpds(~jpds@gateway/tor-sasl/jpds)
2022-08-11 02:03:26 +0200lsrts^(~lsrts@206.85.120.17) (Ping timeout: 268 seconds)
2022-08-11 02:04:44 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 268 seconds)
2022-08-11 02:05:09 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-11 02:06:27 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 02:09:02 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 02:09:23 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 02:14:35 +0200vglfr(~vglfr@88.155.13.82) (Ping timeout: 255 seconds)
2022-08-11 02:15:24 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 02:15:30 +0200Chai-T-Rex(~ChaiTRex@user/chaitrex)
2022-08-11 02:15:54 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:d0f9:9fe4:8717:f94d) (Ping timeout: 268 seconds)
2022-08-11 02:15:56 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 02:16:33 +0200 <Axman6> d34df00d: I'm glad to see the Elm gateway drug worked :p
2022-08-11 02:17:54 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!)
2022-08-11 02:20:19 +0200allbery_b(~geekosaur@xmonad/geekosaur)
2022-08-11 02:20:19 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2022-08-11 02:20:23 +0200allbery_bgeekosaur
2022-08-11 02:21:07 +0200brettgilio(~brettgili@c9yh.net) (Remote host closed the connection)
2022-08-11 02:25:51 +0200moonsheep(~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1))
2022-08-11 02:29:17 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com)
2022-08-11 02:29:18 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host)
2022-08-11 02:29:18 +0200wroathe(~wroathe@user/wroathe)
2022-08-11 02:31:09 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-08-11 02:33:53 +0200mima(mmh@gateway/vpn/airvpn/mima)
2022-08-11 02:33:59 +0200mima(mmh@gateway/vpn/airvpn/mima) (Client Quit)
2022-08-11 02:34:19 +0200mima(mmh@gateway/vpn/airvpn/mima)
2022-08-11 02:34:52 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2022-08-11 02:34:52 +0200allbery_b(~geekosaur@xmonad/geekosaur)
2022-08-11 02:34:56 +0200allbery_bgeekosaur
2022-08-11 02:36:11 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 02:37:18 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-08-11 02:39:45 +0200vysn(~vysn@user/vysn)
2022-08-11 02:42:22 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 02:45:00 +0200nilradical(~nilradica@user/naso)
2022-08-11 02:49:42 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-11 02:49:42 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 02:53:02 +0200nilradical(~nilradica@user/naso)
2022-08-11 02:53:18 +0200Kaiepi(~Kaiepi@142.68.249.28) (Quit: Leaving)
2022-08-11 02:56:35 +0200brettgilio(~brettgili@c9yh.net)
2022-08-11 02:57:13 +0200 <c_wraith> zzz: it still reserves the namespace for that behavior if the internal representation changes in the future
2022-08-11 03:03:51 +0200 <albet70> there's a term called f-expr in newlisp, it's more powerful than macro, could haskell implement it?
2022-08-11 03:04:30 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2022-08-11 03:05:29 +0200 <Axman6> what is it?
2022-08-11 03:06:56 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Ping timeout: 268 seconds)
2022-08-11 03:08:31 +0200 <c_wraith> from what I'm seeing, most lisps had dropped support for them sometime in the 90s because they broke static compilation
2022-08-11 03:08:40 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 03:09:44 +0200 <albet70> https://en.wikipedia.org/wiki/Fexpr
2022-08-11 03:13:10 +0200 <zzz> not ecaluating operands? isn't that just lazyness?
2022-08-11 03:13:19 +0200 <zzz> *eval
2022-08-11 03:13:42 +0200 <Axman6> yeah it feels like laziness to me, but I assume you can also inspect those values' AST
2022-08-11 03:14:28 +0200 <Axman6> so you could do the equivalent of f x = case x of a + b -> ...; a * b -> ...; -a -> ...
2022-08-11 03:16:37 +0200 <c_wraith> ultimately the question is wrong.
2022-08-11 03:16:57 +0200 <c_wraith> albet70: don't ask how to do other-language-feature. Ask how to achieve a particular result.
2022-08-11 03:17:38 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-08-11 03:17:42 +0200hsw(~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Remote host closed the connection)
2022-08-11 03:18:15 +0200 <c_wraith> do you want to pass a code block into template haskell? cool, write a TH function that accepts an Q Exp.
2022-08-11 03:20:13 +0200 <c_wraith> the whole distinction between FExpr and macro doesn't make sense in Haskell, because Haskell doesn't pretend list of tokens and code are the same thing
2022-08-11 03:20:47 +0200 <c_wraith> So you don't need special forms to treat the same input two different ways. You just have two different types of input.
2022-08-11 03:20:50 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-11 03:21:02 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2022-08-11 03:21:48 +0200[_](~itchyjunk@user/itchyjunk/x-7353470)
2022-08-11 03:22:40 +0200 <jackdk> "a fexpr is a function whose operands are passed to it without being evaluated" sure sounds like a lazy function to me
2022-08-11 03:23:08 +0200 <c_wraith> well. it's more like a macro whose operands are passed without being evaluated.
2022-08-11 03:24:00 +0200 <c_wraith> in sufficiently old versions of lisp, they were used to implement control flow structures
2022-08-11 03:24:02 +0200 <Axman6> I think the main benefit is that the AST is accessible, so a function can modify its inputs
2022-08-11 03:24:11 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 252 seconds)
2022-08-11 03:24:22 +0200 <c_wraith> which in lisp requires turning the arguments into the bodies of functions
2022-08-11 03:26:55 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 03:29:18 +0200 <Axman6> a bit of a long shot, but does anyone know of a tool for visualising bitwise operations? the closest I've found is https://github.com/mellowcandle/bitwise which isn't really close at all to what I'm after
2022-08-11 03:30:01 +0200nate4(~nate@98.45.169.16)
2022-08-11 03:31:48 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-11 03:33:02 +0200 <Axman6> I want something symbolic that lets me do things like abcd_2 * 0x0201 and it'll give me back abcd0abcd_b (not super clear in text only, hence why I want something better)
2022-08-11 03:33:03 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Quit: Leaving)
2022-08-11 03:33:09 +0200 <Axman6> maybe I should make something
2022-08-11 03:35:15 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-11 03:35:32 +0200 <dibblego> and thus, the yak was again hairless
2022-08-11 03:35:38 +0200 <dibblego> I use pen/paper tbh
2022-08-11 03:35:57 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 03:37:56 +0200 <Axman6> the problem is when you want to represent things like y = x * 0x0101010101010101 and show that the top byte is the sum of the values in each of the bytes in x (if each byte is zero or one)
2022-08-11 03:38:58 +0200 <Axman6> I've written a bunch of implementations of popcount in C and was thinking about writing a blog post about them, and being able to visualise how they work ould be pretty useful
2022-08-11 03:40:45 +0200mcglk(~mcglk@131.191.49.120)
2022-08-11 03:45:34 +0200 <Axman6> ((((x * 0x8040201008040201) >> 7) & 0x0101010101010101) * 0x0101010101010101) >> 56 for example will do an 8 bit popcount but it's not at all clear why the multiplication works
2022-08-11 03:45:36 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 03:47:31 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-08-11 03:48:23 +0200lemonsnicks(~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) (Ping timeout: 252 seconds)
2022-08-11 03:48:30 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-08-11 03:50:48 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 268 seconds)
2022-08-11 03:55:40 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2022-08-11 03:55:54 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 03:56:18 +0200alp_(~alp@user/alp) (Ping timeout: 268 seconds)
2022-08-11 03:57:41 +0200zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2022-08-11 03:58:50 +0200zaquest(~notzaques@5.130.79.72)
2022-08-11 04:00:29 +0200 <jackdk> I look forward to your blogpost about bitwise visualisation axman6
2022-08-11 04:00:33 +0200 <jackdk> :>
2022-08-11 04:02:21 +0200nate4(~nate@98.45.169.16)
2022-08-11 04:07:23 +0200zebrag(~chris@user/zebrag) (Quit: Konversation terminated!)
2022-08-11 04:12:58 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 04:13:35 +0200noteness(~noteness@user/noteness) (Remote host closed the connection)
2022-08-11 04:13:58 +0200noteness(~noteness@user/noteness)
2022-08-11 04:16:12 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2022-08-11 04:16:12 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2022-08-11 04:16:12 +0200finn_elijaFinnElija
2022-08-11 04:16:12 +0200[_][itchyjunk]
2022-08-11 04:17:26 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 04:24:39 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 04:29:36 +0200hpc(~juzz@ip98-169-32-242.dc.dc.cox.net) (Ping timeout: 268 seconds)
2022-08-11 04:32:03 +0200td_(~td@muedsl-82-207-238-185.citykom.de) (Ping timeout: 268 seconds)
2022-08-11 04:32:08 +0200codaraxis__(~codaraxis@user/codaraxis)
2022-08-11 04:33:23 +0200td_(~td@94.134.91.58)
2022-08-11 04:33:51 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 04:36:06 +0200codaraxis(~codaraxis@user/codaraxis) (Ping timeout: 264 seconds)
2022-08-11 04:40:56 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2022-08-11 04:42:39 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-11 04:57:49 +0200ddellacosta(~ddellacos@89.45.224.209)
2022-08-11 04:58:05 +0200nilradical(~nilradica@user/naso)
2022-08-11 05:01:41 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 05:02:15 +0200machinedgod(~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 268 seconds)
2022-08-11 05:04:39 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-11 05:06:07 +0200ddellacosta(~ddellacos@89.45.224.209) (Ping timeout: 252 seconds)
2022-08-11 05:07:36 +0200luffy(~chenqisu1@183.217.201.23) (Quit: Leaving)
2022-08-11 05:07:55 +0200nilradical(~nilradica@user/naso) ()
2022-08-11 05:07:59 +0200luffy(~chenqisu1@183.217.201.23)
2022-08-11 05:08:10 +0200ddellacosta(~ddellacos@143.244.47.100)
2022-08-11 05:08:53 +0200nate4(~nate@98.45.169.16)
2022-08-11 05:11:30 +0200causal(~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0e)
2022-08-11 05:14:00 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 05:17:07 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds)
2022-08-11 05:18:12 +0200 <dibblego> thx Axman6
2022-08-11 05:20:12 +0200kadoban1(~kadoban@user/kadoban)
2022-08-11 05:20:25 +0200mima(mmh@gateway/vpn/airvpn/mima) (Ping timeout: 252 seconds)
2022-08-11 05:24:29 +0200stef204(~stef204@user/stef204) (Quit: WeeChat 3.6)
2022-08-11 05:31:18 +0200Vajb(~Vajb@2001:999:70c:2b99:3e15:6929:5bc6:c014) (Read error: Connection reset by peer)
2022-08-11 05:31:30 +0200Vajb(~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi)
2022-08-11 05:32:09 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 252 seconds)
2022-08-11 05:32:18 +0200vglfr(~vglfr@88.155.19.3)
2022-08-11 05:32:57 +0200jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection)
2022-08-11 05:36:10 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 05:36:47 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 05:40:48 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 05:41:51 +0200kazaf(~kazaf@94.180.63.53)
2022-08-11 05:46:08 +0200kazaf(~kazaf@94.180.63.53) (Ping timeout: 252 seconds)
2022-08-11 05:56:39 +0200nate4(~nate@98.45.169.16)
2022-08-11 05:58:40 +0200Vajb(~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) (Read error: Connection reset by peer)
2022-08-11 05:59:27 +0200Vajb(~Vajb@2001:999:70c:2b99:3e15:6929:5bc6:c014)
2022-08-11 06:00:19 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 06:00:45 +0200vglfr(~vglfr@88.155.19.3) (Ping timeout: 252 seconds)
2022-08-11 06:00:48 +0200hpc(~juzz@ip98-169-32-242.dc.dc.cox.net)
2022-08-11 06:01:13 +0200mbuf(~Shakthi@122.165.55.71)
2022-08-11 06:01:29 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-11 06:05:09 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 268 seconds)
2022-08-11 06:05:16 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2022-08-11 06:05:50 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-08-11 06:05:50 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-11 06:07:54 +0200Guest|3(~Guest|3@a81-14-214-243.net-htp.de)
2022-08-11 06:07:55 +0200lemonsnicks(~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net)
2022-08-11 06:08:16 +0200 <Guest|3> does haskell run on armv7?
2022-08-11 06:11:15 +0200 <c_wraith> like on phones? You can compile to mobile, yes, though it's a pain to get set up initially.
2022-08-11 06:17:36 +0200 <jackdk> arm is becoming an increasingly important compile target because of m1
2022-08-11 06:17:44 +0200 <Guest|3> https://github.com/simplex-chat/simplex-chat/issues/538#issuecomment-1100840391
2022-08-11 06:18:23 +0200 <Guest|3> simplex devs says it runs on aarch64 but not armv7
2022-08-11 06:19:09 +0200 <c_wraith> There are certainly people running haskell on mobile
2022-08-11 06:19:48 +0200 <Guest|3> yea but mobile phone cpus differ
2022-08-11 06:20:14 +0200 <Guest|3> my question is does armv7 work too?
2022-08-11 06:20:48 +0200 <Guest|3> not only aarch64 (which is also arm)
2022-08-11 06:21:48 +0200 <jackdk> https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms seems to be the canonical resource
2022-08-11 06:24:08 +0200biberu\(~biberu@user/biberu)
2022-08-11 06:27:58 +0200biberu(~biberu@user/biberu) (Ping timeout: 268 seconds)
2022-08-11 06:27:59 +0200biberu\biberu
2022-08-11 06:31:49 +0200nate4(~nate@98.45.169.16)
2022-08-11 06:34:08 +0200Guest|3(~Guest|3@a81-14-214-243.net-htp.de) (Ping timeout: 268 seconds)
2022-08-11 06:34:30 +0200lemonsnicks(~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 06:34:52 +0200lemonsnicks(~lemonsnic@cpc159519-perr18-2-0-cust114.19-1.cable.virginm.net)
2022-08-11 06:37:12 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 06:37:15 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 06:37:23 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2022-08-11 06:42:09 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 268 seconds)
2022-08-11 06:44:08 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 06:46:56 +0200 <Inst> yikes
2022-08-11 06:49:53 +0200macabre(~m@161.35.15.236) (Ping timeout: 252 seconds)
2022-08-11 06:51:06 +0200vysn(~vysn@user/vysn) (Ping timeout: 244 seconds)
2022-08-11 06:53:03 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 06:57:35 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds)
2022-08-11 07:01:25 +0200kitty4(~kitty@096-039-147-043.res.spectrum.com) (Ping timeout: 268 seconds)
2022-08-11 07:01:55 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 07:02:23 +0200kitty4(~kitty@096-039-147-043.res.spectrum.com)
2022-08-11 07:04:49 +0200img(~img@user/img)
2022-08-11 07:05:22 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec) (Quit: Going elsewhere)
2022-08-11 07:06:39 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec)
2022-08-11 07:11:47 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 07:12:11 +0200img(~img@user/img)
2022-08-11 07:14:02 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 07:18:28 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 07:20:01 +0200macabre(~m@161.35.15.236)
2022-08-11 07:23:28 +0200luffy(~chenqisu1@183.217.201.23) (Ping timeout: 268 seconds)
2022-08-11 07:23:37 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 252 seconds)
2022-08-11 07:30:56 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 07:32:31 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 07:33:22 +0200nate4(~nate@98.45.169.16)
2022-08-11 07:38:17 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-11 07:40:46 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 07:47:33 +0200 <dsal> I used to have a few things deployed on 32-bit ARM machines running armbian. It's been a while, though.
2022-08-11 07:51:35 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 08:04:44 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-08-11 08:05:47 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-08-11 08:06:06 +0200tv(~tv@user/tv) (Ping timeout: 264 seconds)
2022-08-11 08:07:17 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 08:09:15 +0200 <sm> Guest|3: yes it does
2022-08-11 08:17:55 +0200frost(~frost@user/frost)
2022-08-11 08:18:17 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 08:24:36 +0200coot(~coot@213.134.176.158)
2022-08-11 08:28:24 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 08:31:36 +0200 <Axman6> jackdk: well, I was thinking this might be a good excuse to look at reanimate... these examples are amazing: https://reanimate.readthedocs.io/en/latest/voice/
2022-08-11 08:32:04 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:4859:a137:2c1f:9457)
2022-08-11 08:32:42 +0200 <c_wraith> isn't that the one where the author refuses to stop using unsafePerformIO for file output?
2022-08-11 08:33:02 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 255 seconds)
2022-08-11 08:34:58 +0200ddellacosta(~ddellacos@143.244.47.100) (Quit: WeeChat 3.5)
2022-08-11 08:35:31 +0200ddellacosta(~ddellacos@143.244.47.100)
2022-08-11 08:36:50 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2022-08-11 08:37:09 +0200 <jackdk> X_X
2022-08-11 08:37:10 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 08:43:10 +0200 <Axman6> eh, it's really an app, I'm not too worried about that
2022-08-11 08:43:57 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:8014:4f1d:3973:a5c3)
2022-08-11 08:44:12 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 08:44:30 +0200 <Axman6> it would be better to use template haskell to embed them, but I can understand why they'd do it that way
2022-08-11 08:47:46 +0200 <tomsmeding> Axman6: c_wraith said "file output"
2022-08-11 08:48:41 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds)
2022-08-11 08:49:37 +0200mc47(~mc47@xmonad/TheMC47)
2022-08-11 08:54:40 +0200Kaiepi(~Kaiepi@142.68.249.28)
2022-08-11 08:57:37 +0200Cajun(~Cajun@user/cajun)
2022-08-11 09:04:12 +0200shriekingnoise(~shrieking@186.137.167.202) (Quit: Quit)
2022-08-11 09:07:42 +0200joo-_(~joo-_@80-62-116-198-mobile.dk.customer.tdc.net)
2022-08-11 09:07:42 +0200joo-_(~joo-_@80-62-116-198-mobile.dk.customer.tdc.net) (Changing host)
2022-08-11 09:07:42 +0200joo-_(~joo-_@fsf/member/joo--)
2022-08-11 09:07:56 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f)
2022-08-11 09:09:59 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Remote host closed the connection)
2022-08-11 09:10:19 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-11 09:12:06 +0200 <Axman6> oh I missed that - yeah that's less ok
2022-08-11 09:12:36 +0200 <Axman6> but whatevs, it's supposed to be a DSL for making pretty pictures, I can't see a lot of harm in doing that
2022-08-11 09:12:41 +0200Moyst_(~moyst@user/moyst) (Ping timeout: 268 seconds)
2022-08-11 09:13:15 +0200gff(~gff@user/gff) (Ping timeout: 268 seconds)
2022-08-11 09:13:47 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Remote host closed the connection)
2022-08-11 09:15:05 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2022-08-11 09:16:05 +0200Moyst_(~moyst@user/moyst)
2022-08-11 09:18:01 +0200 <siers> 1195532
2022-08-11 09:18:21 +0200 <siers> oh, that's just an expired 2fa code, sorry
2022-08-11 09:18:25 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 09:19:37 +0200gff(~gff@user/gff)
2022-08-11 09:20:01 +0200c_wraith(~c_wraith@adjoint.us) (Ping timeout: 268 seconds)
2022-08-11 09:20:34 +0200ystael(~ystael@user/ystael) (Remote host closed the connection)
2022-08-11 09:20:49 +0200ystael(~ystael@user/ystael)
2022-08-11 09:22:31 +0200 <tomsmeding> interesting length
2022-08-11 09:23:09 +0200 <siers> I was thinking someone might say that and that's because I have a short repeat delay and the initial one repeated
2022-08-11 09:23:19 +0200 <tomsmeding> :')
2022-08-11 09:24:48 +0200c_wraith(~c_wraith@adjoint.us)
2022-08-11 09:31:48 +0200 <[exa]> siers: I know a root password when I see it! :D
2022-08-11 09:31:50 +0200nate4(~nate@98.45.169.16)
2022-08-11 09:31:56 +0200 <siers> (':
2022-08-11 09:32:42 +0200 <tdammers> wait, what, you guys use multi-character root passwords?
2022-08-11 09:34:23 +0200 <siers> tdammers, your single-character password must have external entropy to achieve security — the password means so many things to you, that it has more information!
2022-08-11 09:34:34 +0200Cajun(~Cajun@user/cajun) (Ping timeout: 252 seconds)
2022-08-11 09:35:00 +0200ccntrq(~Thunderbi@172.209.94.92.rev.sfr.net)
2022-08-11 09:35:08 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 09:36:08 +0200mikoto-chan(~mikoto-ch@85-76-5-204-nat.elisa-mobile.fi)
2022-08-11 09:36:14 +0200 <Axman6> my root password is ********
2022-08-11 09:36:22 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 09:36:25 +0200nate4(~nate@98.45.169.16) (Ping timeout: 244 seconds)
2022-08-11 09:37:47 +0200 <[exa]> (almost 20 bits of entropy in a single random unicode char may be better than most people's passwords.)
2022-08-11 09:38:21 +0200michalz(~michalz@185.246.204.69)
2022-08-11 09:39:25 +0200tomsmeding. o O ( $ wc -l /usr/share/dict/words # -> 123115 )
2022-08-11 09:39:30 +0200yvan-sraka(~yvan-srak@105.67.135.250)
2022-08-11 09:41:51 +0200ubert(~Thunderbi@178.165.202.57.wireless.dyn.drei.com)
2022-08-11 09:43:19 +0200vysn(~vysn@user/vysn)
2022-08-11 09:44:48 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Write error: Connection reset by peer)
2022-08-11 09:44:48 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-11 09:45:07 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-11 09:45:35 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-08-11 09:49:20 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 09:50:50 +0200 <Axman6> > 123115^4
2022-08-11 09:50:52 +0200 <lambdabot> 229743841054595400625
2022-08-11 09:51:04 +0200 <Axman6> > logBase 10 229743841054595400625
2022-08-11 09:51:05 +0200 <lambdabot> 20.36124387769969
2022-08-11 09:51:14 +0200 <Axman6> > logBase 2 229743841054595400625
2022-08-11 09:51:16 +0200 <lambdabot> 67.63858808418391
2022-08-11 09:51:26 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 09:51:37 +0200mikoto-chan(~mikoto-ch@85-76-5-204-nat.elisa-mobile.fi) (Ping timeout: 268 seconds)
2022-08-11 09:52:27 +0200machinedgod(~machinedg@d172-219-86-154.abhsia.telus.net)
2022-08-11 09:54:15 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-11 09:55:33 +0200acidjnk_new(~acidjnk@p5dd87aad.dip0.t-ipconnect.de)
2022-08-11 09:56:02 +0200mikoto-chan(~mikoto-ch@85-76-5-204-nat.elisa-mobile.fi)
2022-08-11 09:56:11 +0200fserucas(~fserucas@83.223.227.123)
2022-08-11 09:56:14 +0200fserucas(~fserucas@83.223.227.123) (Client Quit)
2022-08-11 09:56:28 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 268 seconds)
2022-08-11 09:56:33 +0200fserucas(~fserucas@83.223.227.123)
2022-08-11 09:59:24 +0200 <tomsmeding> Axman6: why ^4?
2022-08-11 09:59:30 +0200 <tomsmeding> oh four words, duh
2022-08-11 10:00:14 +0200 <tomsmeding> manhole spacey stretchering nonmetal's
2022-08-11 10:00:29 +0200 <tomsmeding> somewhat less enticing than the classic
2022-08-11 10:02:35 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-08-11 10:03:02 +0200Sgeo(~Sgeo@user/sgeo)
2022-08-11 10:04:19 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-08-11 10:05:22 +0200tv(~tv@user/tv)
2022-08-11 10:07:48 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 10:10:49 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de)
2022-08-11 10:11:38 +0200 <chreekat> The spacey manhole is for stretchering nonmetals
2022-08-11 10:12:04 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 244 seconds)
2022-08-11 10:19:33 +0200jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2022-08-11 10:19:35 +0200kuribas(~user@silversquare.silversquare.eu)
2022-08-11 10:20:37 +0200jgeerds(~jgeerds@55d46bad.access.ecotel.net)
2022-08-11 10:21:07 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2022-08-11 10:22:57 +0200jinsun(~jinsun@user/jinsun)
2022-08-11 10:24:49 +0200alternateved(~user@staticline-31-183-149-36.toya.net.pl)
2022-08-11 10:26:39 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:8014:4f1d:3973:a5c3) (Ping timeout: 268 seconds)
2022-08-11 10:27:04 +0200chele(~chele@user/chele)
2022-08-11 10:30:20 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de) (Remote host closed the connection)
2022-08-11 10:30:58 +0200zxx7529(~Thunderbi@user/zxx7529) (Ping timeout: 268 seconds)
2022-08-11 10:33:14 +0200Inst(~Inst@2601:6c4:4080:3f80:9130:6712:37bc:57ff) (Ping timeout: 255 seconds)
2022-08-11 10:36:59 +0200ubert1(~Thunderbi@178.165.178.67.wireless.dyn.drei.com)
2022-08-11 10:37:10 +0200ubert(~Thunderbi@178.165.202.57.wireless.dyn.drei.com) (Ping timeout: 268 seconds)
2022-08-11 10:37:10 +0200ubert1ubert
2022-08-11 10:39:30 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-11 10:41:34 +0200mc47(~mc47@xmonad/TheMC47)
2022-08-11 10:41:48 +0200 <Athas> I'm reading an older paper on the GHC profiler and the sample profiling report for GHC itself shows a peak memory usage of 3MiB.
2022-08-11 10:41:52 +0200 <Athas> Where did we go wrong...
2022-08-11 10:43:53 +0200machinedgod(~machinedg@d172-219-86-154.abhsia.telus.net) (Ping timeout: 268 seconds)
2022-08-11 10:44:18 +0200 <merijn> Athas: tbh, peak memory varies a lot, a lot of my executables are actually showing surprisingly small peak memory usage compared to the amount of data I make them dig through
2022-08-11 10:45:12 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-08-11 10:47:26 +0200 <merijn> Athas: tbh, I think one of the big issues (not just in Haskell, but programming overall) with poor performance has come from people misunderstanding/abusing Knuth's "premature optimisation" quote to not think about performance and optimisation at all
2022-08-11 10:47:29 +0200jgeerds(~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 252 seconds)
2022-08-11 10:47:42 +0200 <merijn> Since optimising bad code is a rather huge task
2022-08-11 10:48:31 +0200 <kuribas> merijn: yeah, Knuth is an optimization freak.
2022-08-11 10:48:32 +0200luffy(~chenqisu1@183.217.201.23)
2022-08-11 10:48:54 +0200 <kuribas> merijn: what he meant is that some optimizations simply don't improve anything, not that you should not optimize.
2022-08-11 10:49:20 +0200 <kuribas> Now it has started to mean "don't optimize, because computers are fast enough".
2022-08-11 10:50:31 +0200 <merijn> kuribas: No, what he meant was that most people's idea of "optimising" was micro-stuff (like rewriting divisions to shifts, etc.) where you don't know if they are either 1) a bottleneck at all or 2) if it's even an optimisation at all
2022-08-11 10:50:55 +0200 <kuribas> that's what I meant
2022-08-11 10:51:17 +0200 <merijn> Some of the beginner programmers in #programming discussing their C code "optimisation" stuff has me facepalm hard. Spending hours on stuff that's basically irrelevant >.>
2022-08-11 10:51:21 +0200 <kuribas> and it's even more true now that you cannot just count instructions.
2022-08-11 10:51:37 +0200 <merijn> Also, benchmarking is *hard*
2022-08-11 10:51:40 +0200dschrempf(~dominik@070-207.dynamic.dsl.fonira.net)
2022-08-11 10:51:45 +0200 <merijn> People consistently underestimate that
2022-08-11 10:51:59 +0200 <tomsmeding> especially if the hotspot is a small loop
2022-08-11 10:52:22 +0200 <merijn> tomsmeding: That's when you get your boss to pay for vtune :p
2022-08-11 10:52:23 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:312b:b0d2:43e8:3622)
2022-08-11 10:53:07 +0200 <tomsmeding> I've had some grief from adding a printf in some unrelated place, which adjusted the offset of the address of said loop, which significantly changed performance
2022-08-11 10:53:34 +0200 <kuribas> ironically, LaTeX is encredibly slow because of all the stupid kpathsearch stuff.
2022-08-11 10:53:50 +0200 <merijn> kuribas: LaTeX is slow because lots of reasons :p
2022-08-11 10:53:53 +0200 <tomsmeding> well also if you start tikzing
2022-08-11 10:53:59 +0200 <merijn> I wonder if LaTeX3 will ever take off
2022-08-11 10:54:00 +0200 <kuribas> merijn: but not because of TeX
2022-08-11 10:54:43 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 10:56:03 +0200 <dminuoso> The main mistake with Knuth is not quoting properly I guess?
2022-08-11 10:56:13 +0200 <dminuoso> The original version goes "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
2022-08-11 10:56:53 +0200avpx(~nick@ec2-54-214-223-1.us-west-2.compute.amazonaws.com) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 10:56:53 +0200hexeme(~hexeme@user/hexeme) (Quit: co'o ro do)
2022-08-11 10:57:22 +0200 <dminuoso> Or I guess this was Sir Tony Hoare actually?
2022-08-11 10:57:32 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 10:57:54 +0200titibandit(~titibandi@2a00:8a60:c000:1:8a13:bf74:b2:8d47)
2022-08-11 10:57:56 +0200 <kuribas> for sure it didn't mean "don't think about which are the optimal datastructures for our problem."
2022-08-11 10:58:14 +0200hexeme(~hexeme@user/hexeme)
2022-08-11 10:58:15 +0200avpx(~nick@ec2-54-214-223-1.us-west-2.compute.amazonaws.com)
2022-08-11 10:59:05 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 244 seconds)
2022-08-11 10:59:45 +0200mmhat(~mmh@p200300f1c706f76bee086bfffe095315.dip0.t-ipconnect.de)
2022-08-11 10:59:57 +0200 <merijn> The real issue is: you can only tackle performance holistically
2022-08-11 11:00:20 +0200 <merijn> You can optimise the shit out of your inner loop, but that won't help you if you can't feed it data fast enough
2022-08-11 11:00:42 +0200wildsebastian(~wildsebas@2001:470:69fc:105::1:14b1) (Quit: You have been kicked for being idle)
2022-08-11 11:03:04 +0200 <Athas> This is why I prefer to only focus on application-level performance! It's easy to measure and you definitely only end up worrying about big changes.
2022-08-11 11:03:18 +0200wildsebastian(~wildsebas@2001:470:69fc:105::1:14b1)
2022-08-11 11:03:33 +0200 <merijn> Athas: I disagree about the easy to measure part :p
2022-08-11 11:03:48 +0200 <dminuoso> My perspective differs slightly. The act of religiously ignoring optimized code can easily lead to an accumulation of performance problems. Premature optimizing as rewriting without profiling is generally bad, but using efficient data structures or algorithms when it doesn't incur too much overhead is a great practice.
2022-08-11 11:04:17 +0200 <zzz> shouldn't it be immature? premature implies maturation
2022-08-11 11:04:30 +0200 <dminuoso> Even if the code in question is outside hot code. For one it reduces the chance of introducing performance regressions, and the more practice you have writing performant code, the better you get at it?
2022-08-11 11:04:57 +0200 <kuribas> dminuoso: I am sure Knuth was talking about small linear optimizations, not choosing correct algorithms/data structures.
2022-08-11 11:05:27 +0200 <dminuoso> So perhaps we should differentiate between "writing optimized code during rewriting" and "rewriting existing code after the fact"
2022-08-11 11:05:35 +0200 <dminuoso> Uhh hold on, that went wrong.
2022-08-11 11:05:50 +0200 <dminuoso> I meant "writing optimized code during rewriting" and "writing initially optimized code"
2022-08-11 11:06:18 +0200 <Athas> My experience is that it's very easy to use asymptotically efficient (or even optimal) data structures. Most of the performance problems I encounter are not asymptotic.
2022-08-11 11:06:28 +0200 <kuribas> dminuoso: for example, you could rewrite some code using SSE, but that will only bring a benifit if the code is a hotspot.
2022-08-11 11:06:43 +0200 <dminuoso> kuribas: I dont think that differentiation is meaningful at all.
2022-08-11 11:06:58 +0200 <Athas> Use Data.Map and you're in pretty good company asymptotically, but you can still end up with sluggish allocation-heavy code with bad locality.
2022-08-11 11:08:07 +0200 <merijn> Athas: My experience is that "arrays beat optimal data structures 90% of the time"
2022-08-11 11:08:20 +0200 <Athas> Yes, that is also my experience.
2022-08-11 11:08:25 +0200 <Athas> Brawns scale better than brains.
2022-08-11 11:08:48 +0200 <dminuoso> merijn: That goes into "things in cache are unbelivably fast"
2022-08-11 11:08:50 +0200 <Athas> It is unfortunate that Haskell is not great at arrays.
2022-08-11 11:08:55 +0200 <merijn> dminuoso: Sure
2022-08-11 11:08:59 +0200 <tdammers> the thing with asymptotic performance is that in a lot of cases, n is never anywhere near big enough for it to matter
2022-08-11 11:09:03 +0200 <merijn> Athas: I dunno, vector's pretty decent
2022-08-11 11:09:10 +0200 <kuribas> Athas: Vector work good enough?
2022-08-11 11:09:24 +0200 <merijn> tdammers: The thing is, when N *is* big, cache locality becomes *more* important
2022-08-11 11:09:33 +0200 <tdammers> merijn: haha, yeah, that too
2022-08-11 11:09:37 +0200 <Athas> Vector is indeed good! It is my favourite array library. But it's not great when you want something as exotic as a 2D array.
2022-08-11 11:09:43 +0200wildsebastian(~wildsebas@2001:470:69fc:105::1:14b1) ()
2022-08-11 11:09:52 +0200 <merijn> tdammers: I had a super intricate O(n log n) solution for a problem with big N (double digit billions)
2022-08-11 11:09:57 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2022-08-11 11:10:08 +0200 <Athas> And it's still a bit more clumsy than in many other languages (mostly because of the type zoo you have to traverse to get the Good Vector, i.e. unboxed or storable).
2022-08-11 11:10:43 +0200 <merijn> I rewrote it from heaps to arrays and doing multi-pass, so O(n) + a bit, and it was orders of magnitude faster
2022-08-11 11:10:44 +0200 <Athas> merijn: sounds like something that can easily end up just being O(n) cache misses.
2022-08-11 11:10:53 +0200 <merijn> Turns out, sequential scans of multi-GB are pretty fast
2022-08-11 11:10:58 +0200 <dminuoso> merijn, tdammers: With large things, there's not just cache locality but also cache friendly access. If you can trigger cache CPU prefetching early enough for future data to be in the cache line earlier.
2022-08-11 11:11:31 +0200 <merijn> Athas: Yeah, in the end I did a full pass over the data, counting elements per bucket, then radix sortig the whole thing, so two O(n) passes. Much faster
2022-08-11 11:11:35 +0200 <tdammers> merijn: cache misses kind of throw the big O off, yeah
2022-08-11 11:11:41 +0200 <dminuoso> So regarding multi-GB, its only fast if prefetched well enough, and you dont suffer from cache thrashing too much
2022-08-11 11:11:44 +0200 <merijn> Big O is all lies I tell you
2022-08-11 11:11:48 +0200 <kuribas> merijn: wouldn't chuncked lists or maps be better?
2022-08-11 11:11:50 +0200 <siers> caches and the low-level architecture is how I'm certain I know nothing about optimization
2022-08-11 11:12:13 +0200 <kuribas> siers: I can recommend anything by Agner Fog
2022-08-11 11:12:14 +0200 <dminuoso> tdammers: Ah, regarding that. https://www.ilikebigbits.com/2014_04_21_myth_of_ram_1.html and following parts! :)
2022-08-11 11:12:50 +0200 <dminuoso> Perhaps part of big-O is the physically incorrect assumption of random memory access being constant
2022-08-11 11:13:18 +0200 <merijn> big O is off by arbitrary amounts, depending on the access patterns, yes
2022-08-11 11:13:29 +0200 <merijn> dminuoso: Did you ever see PHK's article on the same thing?
2022-08-11 11:13:36 +0200 <Athas> Do modern CPUs perform much automatic prefetching?
2022-08-11 11:13:39 +0200 <dminuoso> merijn: No, do you have a link ready?
2022-08-11 11:13:42 +0200 <dminuoso> Athas: yes
2022-08-11 11:13:44 +0200 <merijn> https://queue.acm.org/detail.cfm?id=1814327
2022-08-11 11:13:47 +0200 <Athas> dminuoso: this is not about big-O; this is about the RAM cost model.
2022-08-11 11:14:08 +0200haskl(~haskl@user/haskl) (Remote host closed the connection)
2022-08-11 11:14:10 +0200 <merijn> Athas: You need a memory model for Big-O analysis to make sense
2022-08-11 11:14:21 +0200 <merijn> And most people use "O(1) memory access" as their memory model
2022-08-11 11:14:23 +0200 <merijn> Which is bogus
2022-08-11 11:14:24 +0200haskl(~haskl@user/haskl)
2022-08-11 11:14:27 +0200MajorBiscuit(~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl)
2022-08-11 11:14:28 +0200 <Athas> merijn: sure, but it doesn't have to be the RAM model. It's not the idea of doing asymptotic analysis that's the problem.
2022-08-11 11:14:31 +0200 <merijn> But doing it right is nearly infinitely hard
2022-08-11 11:14:42 +0200 <kuribas> merijn: For example, I was thinking about storing time series data using lmdb, with chunks of contiguous series data.
2022-08-11 11:14:52 +0200haskl(~haskl@user/haskl) (Remote host closed the connection)
2022-08-11 11:14:55 +0200 <merijn> Athas: The problem is that the results of asymptotic analysis can be off by an arbitrary factor from reality
2022-08-11 11:15:05 +0200 <kuribas> merijn: wouldn't that be obviously better than a single big array?
2022-08-11 11:15:08 +0200haskl(~haskl@user/haskl)
2022-08-11 11:15:16 +0200 <dminuoso> Athas: Intel has two separate prefetchers. One is the data cache unit prefetcher that triggers on desc/ascending access of memory (it sort of assumes if you load addr, and then addr+n, you will also want addr+(2*n) where n is the cache line size
2022-08-11 11:15:22 +0200 <Athas> merijn: isn't the factor something like 'sqrt(n)' where 'n' is peak data requirement?
2022-08-11 11:15:26 +0200 <merijn> Athas: i.e. it's very possible (even easy) to construct problems where the "asymptotically worse" wins by near arbitrary margins over the asymptotically better one
2022-08-11 11:15:32 +0200 <dminuoso> The other is the instruction pointer stride prefetcher that monitors loads
2022-08-11 11:15:45 +0200 <merijn> Athas: No, because the impact is non-linear
2022-08-11 11:16:08 +0200mikoto-chan(~mikoto-ch@85-76-5-204-nat.elisa-mobile.fi) (Ping timeout: 244 seconds)
2022-08-11 11:16:09 +0200 <Athas> The sqrt(n) factor is non-linear. It assumes that every single operation requires the equivalent of a cache miss.
2022-08-11 11:16:10 +0200 <merijn> So you can get arbitrarily big blow ups depending on your access pattern
2022-08-11 11:16:26 +0200 <siers> merijn, what do you do at work that you have to solve such problems?
2022-08-11 11:16:28 +0200 <Athas> It's a *factor*; not an additional term.
2022-08-11 11:17:23 +0200 <merijn> siers: It's been awhile since I did this stuff, but I did a bunch of it when I was interning at Oracle working on distributed graph processing
2022-08-11 11:18:02 +0200 <merijn> siers: I always find it hard to explain this stuff, since I mostly learned it through osmosis :p
2022-08-11 11:18:25 +0200 <siers> :) that sounds like quite the experience
2022-08-11 11:18:35 +0200 <merijn> siers: But we've reached a point where consumer hardware is starting to have a lot of them same issues that HPC systems used to have
2022-08-11 11:18:52 +0200 <kuribas> merijn: cache sized chunks makes sense, but does it make sense to store large arrays?
2022-08-11 11:19:08 +0200 <merijn> i.e. nearly every consumer machine is multi-core now, although I guess we don't really have NUMA consumers systems yet? (or do we?)
2022-08-11 11:19:32 +0200 <merijn> kuribas: I mean, once you go big chunks, what even is the point of having lists of chunks over a giant array?)
2022-08-11 11:19:40 +0200 <merijn> The giant array is much easier to write code for
2022-08-11 11:19:54 +0200 <kuribas> merijn: fast insertion?
2022-08-11 11:20:20 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-08-11 11:20:32 +0200 <merijn> kuribas: If you insert you're doing it wrong anyway. You wanna precompute and preallocate the entire array
2022-08-11 11:20:49 +0200 <kuribas> merijn: well, in a database I want to insert...
2022-08-11 11:21:24 +0200etoast(~exaltedto@user/exaltedtoast) (Quit: TschĂĽss)
2022-08-11 11:21:38 +0200 <kuribas> merijn: also, allocation is slow.
2022-08-11 11:21:46 +0200 <merijn> kuribas: Which is why you precompute and do it once
2022-08-11 11:21:52 +0200etoast(~exaltedto@user/exaltedtoast)
2022-08-11 11:21:54 +0200 <kuribas> merijn: wouldn't it be faster to have preallocated chunks?
2022-08-11 11:22:16 +0200 <merijn> The database example seems a bit disingenious, since arrays are not an alternative to databases, those are very different usecases
2022-08-11 11:22:45 +0200 <merijn> kuribas: allocating 10GB or allocating 20 bytes takes roughly the same time, so I don't see how preallocating chunks helps you much?
2022-08-11 11:23:11 +0200 <kuribas> merijn: if they are preallocated, no allocation is necessary?
2022-08-11 11:23:33 +0200 <kuribas> well, I choose that example because it is relevant to our domain.
2022-08-11 11:23:37 +0200 <merijn> kuribas: Well, you have to do the preallocation?
2022-08-11 11:23:52 +0200 <kuribas> sure, but only once in a while.
2022-08-11 11:24:05 +0200 <kuribas> I can keep the blocks around.
2022-08-11 11:24:06 +0200 <merijn> kuribas: How is that different from preallocating a giant array?
2022-08-11 11:24:23 +0200 <Athas> I don't think there is any doubt that trees-of-chunks (e.g. B-trees) are superior to arrays for some problems.
2022-08-11 11:24:36 +0200 <kuribas> right
2022-08-11 11:25:29 +0200 <kuribas> I've been trying to push for this idea (we now store blocks in a RDBMs and load it into linked lists of data), but not much succesfully.
2022-08-11 11:25:58 +0200 <merijn> Anyway, I need to go back through scrolling through fonts to decide on the perfect title font :p
2022-08-11 11:26:20 +0200 <Athas> merijn: it's about performance right? That means italic Impact.
2022-08-11 11:26:24 +0200 <Athas> It is the fastest font.
2022-08-11 11:26:35 +0200 <merijn> Athas: Doesn't quite fit the cover design :p
2022-08-11 11:26:43 +0200 <merijn> Athas: I was thinking impact for the spine, though
2022-08-11 11:27:08 +0200 <kuribas> people have forgotten that title fonts are different from text fonts.
2022-08-11 11:27:13 +0200 <merijn> Because the big glyphs make it easier to keep legible over the background
2022-08-11 11:27:26 +0200 <kuribas> Using time new roman for fonts is heresy.
2022-08-11 11:27:27 +0200 <merijn> kuribas: I haven't, you should see my CV ;)
2022-08-11 11:27:34 +0200 <kuribas> good :)
2022-08-11 11:27:36 +0200cawfee_cawfee
2022-08-11 11:27:51 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 11:27:58 +0200 <kuribas> fonts used to be subtly different for different sizes.
2022-08-11 11:28:12 +0200 <kuribas> But since digital fonts the same is used for everything.
2022-08-11 11:28:24 +0200 <kuribas> I am not sure if variable fonts are taking off.
2022-08-11 11:29:18 +0200 <Athas> Wait, have you actually seen how normal people use fonts? E.g. flyers about a summer party or whatever posted by a home owner's association? I promise you they do not use the same font for everything.
2022-08-11 11:29:52 +0200 <Athas> Titles are big wavy polychromatic things, preferably with drop shadows and gradients.
2022-08-11 11:30:22 +0200 <Athas> The body text will be a more modest Comic Sans, clearly inspired by SPJ's slides.
2022-08-11 11:30:50 +0200 <merijn> Athas: No, don't use Comic Sans
2022-08-11 11:30:58 +0200 <merijn> Athas: Comic Neue :D
2022-08-11 11:31:10 +0200 <merijn> Athas: http://comicneue.com/
2022-08-11 11:31:41 +0200merijnmoves to -offtopic
2022-08-11 11:31:54 +0200 <Athas> Yes, no. That has no heritage to it. Don't watch movie remakes, and only use the version of Comic Sans you can extract from a 1993 trial CD of Microsoft BOB.
2022-08-11 11:36:08 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2022-08-11 11:36:27 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:4859:a137:2c1f:9457) (Ping timeout: 268 seconds)
2022-08-11 11:40:19 +0200yvan-sraka(~yvan-srak@105.67.135.250) (Remote host closed the connection)
2022-08-11 11:40:28 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:7101:c713:9f12:569c)
2022-08-11 11:46:03 +0200gawen_(~gawen@user/gawen) (Quit: cya)
2022-08-11 11:52:13 +0200gawen(~gawen@user/gawen)
2022-08-11 11:56:39 +0200gff(~gff@user/gff) (Ping timeout: 268 seconds)
2022-08-11 12:01:36 +0200yvan-sraka(~yvan-srak@105.67.135.250)
2022-08-11 12:02:48 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-11 12:03:27 +0200nate4(~nate@98.45.169.16)
2022-08-11 12:04:39 +0200pmarg(~pmarg@2a01:799:159f:9b00:3e59:ad16:5739:cb9b)
2022-08-11 12:05:38 +0200Ram-Z_(~Ram-Z@li1814-254.members.linode.com) (Ping timeout: 240 seconds)
2022-08-11 12:08:09 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-11 12:12:55 +0200pgib(~textual@173.38.117.83) (Ping timeout: 252 seconds)
2022-08-11 12:13:28 +0200benin0(~benin@183.82.31.108)
2022-08-11 12:19:18 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:7101:c713:9f12:569c) (Ping timeout: 264 seconds)
2022-08-11 12:22:35 +0200cheater(~Username@user/cheater) (Ping timeout: 268 seconds)
2022-08-11 12:24:40 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 12:24:40 +0200pavonia_(~user@user/siracusa)
2022-08-11 12:27:03 +0200pavonia(~user@user/siracusa) (Read error: Connection reset by peer)
2022-08-11 12:27:05 +0200pavonia_pavonia
2022-08-11 12:28:15 +0200img(~img@user/img)
2022-08-11 12:33:00 +0200 <apache2> "written on my copy of Microsoft ComicChat"
2022-08-11 12:33:41 +0200 <apache2> kuribas: vector fonts also generate different fonts for different sizes, accentuating different aspects to enhance readability.
2022-08-11 12:33:54 +0200 <apache2> or at least the virtual machine supports it
2022-08-11 12:34:17 +0200 <APic> # Appears as Boten Anna
2022-08-11 12:34:54 +0200coot(~coot@213.134.176.158)
2022-08-11 12:39:36 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:8722:865e:dc02:97b0)
2022-08-11 12:43:15 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-08-11 12:47:04 +0200 <kuribas> apache2: not in general
2022-08-11 12:48:39 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-11 12:56:31 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 12:58:46 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-11 13:00:46 +0200 <Maxdamantus> afaict, the people that make font renderers have basically decided not to enhance legibility and instead maintain sub-pixel positions in all cases.
2022-08-11 13:00:54 +0200 <Maxdamantus> at least horizontally.
2022-08-11 13:00:57 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds)
2022-08-11 13:01:41 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds)
2022-08-11 13:01:45 +0200nate4(~nate@98.45.169.16)
2022-08-11 13:01:55 +0200 <Maxdamantus> you can see it in Freetype. If you use a TTF font, it becomes blurry by default from Freetype 2.7, unless you set FREETYPE_PROPERTIES=truetype:interpreter-version=35
2022-08-11 13:02:38 +0200 <Maxdamantus> the same thing happened at some point with OTF as well, as they switched to the Adobe OTF hinter.
2022-08-11 13:03:31 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-08-11 13:03:40 +0200 <Maxdamantus> in both cases, horizontal hints are now ignored, so vertical stems are usually blurred.
2022-08-11 13:06:34 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!)
2022-08-11 13:06:38 +0200Ram-Z(~Ram-Z@li1814-254.members.linode.com)
2022-08-11 13:06:57 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 13:07:04 +0200 <Maxdamantus> I was actually working on making some browser-based demo of how I prefer font rendering to be done, but haven't got around to finishing it: https://maxdamantus.eu.org/ftv35-220719/site/
2022-08-11 13:07:36 +0200zxx7529(~Thunderbi@user/zxx7529) (Ping timeout: 255 seconds)
2022-08-11 13:08:49 +0200 <Maxdamantus> that just uses Freetype compiled to WebAssembly, but most of the text should render in a way that I consider legible (assuming you're not using a fractionally scaled display, eg, on Wayland or macOS)
2022-08-11 13:13:58 +0200jgeerds(~jgeerds@55d46bad.access.ecotel.net)
2022-08-11 13:15:31 +0200dibblego(~dibblego@haskell/developer/dibblego) (Read error: Connection reset by peer)
2022-08-11 13:15:47 +0200dibblego(~dibblego@122-199-1-30.ip4.superloop.com)
2022-08-11 13:15:47 +0200dibblego(~dibblego@122-199-1-30.ip4.superloop.com) (Changing host)
2022-08-11 13:15:47 +0200dibblego(~dibblego@haskell/developer/dibblego)
2022-08-11 13:18:03 +0200Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 268 seconds)
2022-08-11 13:18:18 +0200Maxdamantus(~Maxdamant@user/maxdamantus)
2022-08-11 13:24:39 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-11 13:24:40 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2022-08-11 13:25:29 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:312b:b0d2:43e8:3622) (Ping timeout: 268 seconds)
2022-08-11 13:26:34 +0200kuribas(~user@silversquare.silversquare.eu) (Remote host closed the connection)
2022-08-11 13:26:55 +0200kuribas(~user@silversquare.silversquare.eu)
2022-08-11 13:28:04 +0200xal(~quassel@S01063c7c3f334fd0.vw.shawcable.net) (Ping timeout: 268 seconds)
2022-08-11 13:29:09 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 268 seconds)
2022-08-11 13:31:46 +0200mastarija(~mastarija@2a05:4f46:e03:6000:61a4:b62e:43b7:9ad3)
2022-08-11 13:34:33 +0200cfricke(~cfricke@user/cfricke)
2022-08-11 13:36:20 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 13:40:33 +0200gff(~gff@user/gff)
2022-08-11 13:43:56 +0200Batzy_(~quassel@user/batzy)
2022-08-11 13:43:57 +0200Batzy(~quassel@user/batzy) (Ping timeout: 268 seconds)
2022-08-11 13:46:04 +0200 <albet70> > let intersect = foldl1 (\xs ys -> [ x |x <- xs, elem x ys]) in intersect [[1,2,3],[4,3,5], [3,7,8,9,12]]
2022-08-11 13:46:07 +0200 <lambdabot> [3]
2022-08-11 13:46:25 +0200 <albet70> how to speed this up?
2022-08-11 13:48:09 +0200 <zzz> what are some possible arguments against StricData?
2022-08-11 13:49:52 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 13:51:36 +0200jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2022-08-11 13:53:51 +0200mastarija(~mastarija@2a05:4f46:e03:6000:61a4:b62e:43b7:9ad3) (Ping timeout: 268 seconds)
2022-08-11 13:54:22 +0200 <merijn> zzz: It is nearly equally likely to make performance worse as it is to make performance better
2022-08-11 13:54:42 +0200 <merijn> zzz: You cannot absolve yourself from thinking about strictness. StrictData merely changes the default behaviour
2022-08-11 13:55:25 +0200jinsun(~jinsun@user/jinsun)
2022-08-11 13:56:08 +0200 <arahael> I naively wrote something in purescript the same way I would in haskell.
2022-08-11 13:56:15 +0200 <arahael> Result: Took ages, then crashed.
2022-08-11 13:59:55 +0200 <dminuoso> albet70: With Data.Set
2022-08-11 14:01:35 +0200yvan-sraka(~yvan-srak@105.67.135.250) (Remote host closed the connection)
2022-08-11 14:01:39 +0200 <zzz> merijn: that's what i figured
2022-08-11 14:03:04 +0200 <albet70> dminuoso , for example?
2022-08-11 14:04:03 +0200 <dminuoso> albet70: https://hackage.haskell.org/package/containers-0.6.6/docs/Data-Set.html#v:intersection
2022-08-11 14:04:12 +0200 <dminuoso> Whether this is truly faster depends on the real size of your lists.
2022-08-11 14:14:21 +0200ec(~ec@gateway/tor-sasl/ec) (Quit: ec)
2022-08-11 14:18:42 +0200alternateved(~user@staticline-31-183-149-36.toya.net.pl) (Remote host closed the connection)
2022-08-11 14:19:43 +0200joo-_(~joo-_@fsf/member/joo--) (Ping timeout: 268 seconds)
2022-08-11 14:19:49 +0200sabry(~sabry@41.44.89.119)
2022-08-11 14:19:57 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2022-08-11 14:22:12 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-11 14:25:53 +0200luffy(~chenqisu1@183.217.201.23) (Ping timeout: 268 seconds)
2022-08-11 14:27:24 +0200natechan(~nate@98.45.169.16)
2022-08-11 14:27:45 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Ping timeout: 268 seconds)
2022-08-11 14:28:02 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2022-08-11 14:28:21 +0200nahcetan(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 14:40:48 +0200oo_miguel(~pi@77.252.47.226)
2022-08-11 14:53:08 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 14:55:56 +0200ph88(~ph88@sonicwall.snp-ag.com)
2022-08-11 14:57:16 +0200 <tomsmeding> if you don't need to treat the lists as sets in different places too, you might get a better constant factor by sorting the lists first and then merge pairwise Ă  la mergesort
2022-08-11 14:57:28 +0200 <tomsmeding> (but profile first)
2022-08-11 14:58:55 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 15:02:29 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 15:03:30 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds)
2022-08-11 15:04:29 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 15:06:30 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com)
2022-08-11 15:09:35 +0200img(~img@user/img)
2022-08-11 15:10:24 +0200mc47(~mc47@xmonad/TheMC47)
2022-08-11 15:15:07 +0200Hash(~Hash@tunnel686959-pt.tunnel.tserv15.lax1.ipv6.he.net) (Quit: ZNC - https://znc.in)
2022-08-11 15:15:36 +0200yvan-sraka(~yvan-srak@105.67.135.250)
2022-08-11 15:19:21 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 15:25:05 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2022-08-11 15:25:33 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 15:27:45 +0200fr33domlover[m](~fr33domlo@2001:470:69fc:105::1:3bb6)
2022-08-11 15:31:20 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 15:31:33 +0200dschrempf(~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.6)
2022-08-11 15:32:47 +0200nate4(~nate@98.45.169.16)
2022-08-11 15:38:11 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-11 15:40:56 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2022-08-11 15:41:45 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 15:48:49 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:bc9f:ef3a:bfe5:3be8)
2022-08-11 15:50:48 +0200benin0(~benin@183.82.31.108) (Quit: The Lounge - https://thelounge.chat)
2022-08-11 15:51:08 +0200zer0bitz(~zer0bitz@2001:2003:f748:2000:4941:f6bb:794b:548e)
2022-08-11 15:52:36 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-08-11 15:53:12 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-11 15:54:08 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:bc9f:ef3a:bfe5:3be8) (Ping timeout: 268 seconds)
2022-08-11 15:55:17 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:b1ae:6546:179b:240)
2022-08-11 15:56:22 +0200zxx7529(~Thunderbi@user/zxx7529) (Remote host closed the connection)
2022-08-11 15:56:35 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-11 16:00:46 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:b1ae:6546:179b:240) (Remote host closed the connection)
2022-08-11 16:01:05 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:1638:9f00:c92a:288b)
2022-08-11 16:01:32 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-11 16:03:20 +0200giedreich(~giedreich@host-92-26-16-130.as13285.net)
2022-08-11 16:05:52 +0200stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 268 seconds)
2022-08-11 16:06:40 +0200zxx7529(~Thunderbi@user/zxx7529) (Remote host closed the connection)
2022-08-11 16:06:52 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-11 16:07:57 +0200 <bairyn> Have the online GHC docs gone missing from haskell.org?
2022-08-11 16:08:24 +0200 <merijn> no?
2022-08-11 16:08:44 +0200frost(~frost@user/frost) (Ping timeout: 252 seconds)
2022-08-11 16:08:46 +0200 <merijn> actually...maybe? xD
2022-08-11 16:08:50 +0200 <merijn> @where usersguide
2022-08-11 16:08:50 +0200 <lambdabot> I know nothing about usersguide.
2022-08-11 16:08:54 +0200 <merijn> @where users-guide
2022-08-11 16:08:54 +0200 <lambdabot> see @where ghc-guide or @where cabal-guide
2022-08-11 16:08:55 +0200yvan-sraka(~yvan-srak@105.67.135.250) (Remote host closed the connection)
2022-08-11 16:08:57 +0200 <tomsmeding> the /html is gone from the url
2022-08-11 16:08:59 +0200 <merijn> @where ghc-guide
2022-08-11 16:08:59 +0200 <lambdabot> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide
2022-08-11 16:08:59 +0200 <tomsmeding> https://downloads.haskell.org/~ghc/latest/docs/users_guide/index.html
2022-08-11 16:09:05 +0200 <geekosaur> 9.4.1 is as usually not up yet
2022-08-11 16:09:08 +0200 <geekosaur> they take a few days
2022-08-11 16:09:29 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-08-11 16:09:32 +0200 <geekosaur> actually, iirc hadrian built them wrong and it'll be fixed in 9.4.2, hich is a priority to get released
2022-08-11 16:09:39 +0200 <geekosaur> *which
2022-08-11 16:09:42 +0200 <dolio> If you replace 'latest' with an earlier version they're still there.
2022-08-11 16:09:50 +0200 <tomsmeding> dolio: latest is also there, but without /html in the url
2022-08-11 16:10:05 +0200 <merijn> tomsmeding: Right, succesfully breaking google and links everywhere :p
2022-08-11 16:10:07 +0200 <geekosaur> right, that's the hadrian bug
2022-08-11 16:10:10 +0200 <tomsmeding> ah
2022-08-11 16:10:11 +0200 <merijn> Which is, kinda bad :p
2022-08-11 16:10:21 +0200 <merijn> the top google hit leads to a 404 now
2022-08-11 16:10:43 +0200 <dolio> Oh huh.
2022-08-11 16:12:22 +0200stiell(~stiell@gateway/tor-sasl/stiell)
2022-08-11 16:13:51 +0200Hash(~Hash@tunnel686959-pt.tunnel.tserv15.lax1.ipv6.he.net)
2022-08-11 16:14:03 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-11 16:14:05 +0200zxx7529(~Thunderbi@user/zxx7529) (Remote host closed the connection)
2022-08-11 16:14:18 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-11 16:15:01 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-11 16:16:56 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2022-08-11 16:17:49 +0200zebrag(~chris@user/zebrag)
2022-08-11 16:21:56 +0200yvan-sraka(~yvan-srak@105.67.135.250)
2022-08-11 16:22:08 +0200valhardt(~parsival@209.141.195.79)
2022-08-11 16:22:59 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-08-11 16:24:35 +0200zxx7529(~Thunderbi@user/zxx7529) (Ping timeout: 244 seconds)
2022-08-11 16:26:10 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:1638:9f00:c92a:288b) (Ping timeout: 268 seconds)
2022-08-11 16:29:26 +0200giedreich(~giedreich@host-92-26-16-130.as13285.net) (Quit: Connection closed)
2022-08-11 16:29:55 +0200ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 268 seconds)
2022-08-11 16:29:57 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-08-11 16:30:46 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 16:37:40 +0200kuribas(~user@silversquare.silversquare.eu) (Remote host closed the connection)
2022-08-11 16:38:30 +0200valhardtvalzant
2022-08-11 16:41:14 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-08-11 16:45:29 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 16:45:54 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 16:47:22 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-08-11 16:47:22 +0200 <albet70> dminuoso , for example?
2022-08-11 16:52:55 +0200shriekingnoise(~shrieking@186.137.167.202)
2022-08-11 16:55:36 +0200razetime(~quassel@117.193.4.185)
2022-08-11 17:00:07 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 17:00:43 +0200 <zzz> any impediment for the compiler to simplify arithmetic expressions as an optimization?
2022-08-11 17:01:41 +0200 <merijn> zzz: You mean technically or conceptually? :p
2022-08-11 17:02:30 +0200 <merijn> I guess it also means what you mean exactly by simplifying? i.e. just constant folding or something more complex?
2022-08-11 17:02:49 +0200acidjnk_new(~acidjnk@p5dd87aad.dip0.t-ipconnect.de) (Ping timeout: 244 seconds)
2022-08-11 17:04:53 +0200Hashstoned
2022-08-11 17:05:05 +0200slack1256(~slack1256@wsip-184-177-0-226.no.no.cox.net)
2022-08-11 17:05:38 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 17:12:41 +0200 <tomsmeding> why does GadtC in template-haskell have a _list_ of names? https://hackage.haskell.org/package/template-haskell-2.18.0.0/docs/Language-Haskell-TH.html#t:Con
2022-08-11 17:13:39 +0200pmarg(~pmarg@2a01:799:159f:9b00:3e59:ad16:5739:cb9b) (Ping timeout: 268 seconds)
2022-08-11 17:14:30 +0200 <tomsmeding> I can't seem to write a gadt that produces anything else than a list of length 1 there
2022-08-11 17:14:42 +0200yvan-sraka(~yvan-srak@105.67.135.250) (Remote host closed the connection)
2022-08-11 17:19:30 +0200CiaoSen(~Jura@p200300c95738a5002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-08-11 17:19:51 +0200 <Lears> tomsmeding: Maybe it's because GADTSyntax allows `C1, C2 :: ...`?
2022-08-11 17:20:36 +0200 <tomsmeding> O.o
2022-08-11 17:20:45 +0200 <tomsmeding> wow TIL
2022-08-11 17:20:59 +0200 <tomsmeding> Lears++
2022-08-11 17:21:39 +0200 <tomsmeding> oh
2022-08-11 17:21:57 +0200 <tomsmeding> Lears: even if I use C1, C2 :: ... syntax, I still get separate GadtC values for every constructor
2022-08-11 17:22:11 +0200 <tomsmeding> so perhaps that was the intention (can't really be anything else), but it wasn't implemented
2022-08-11 17:22:48 +0200 <tomsmeding> furthermore, RecGadtC also has the list-of-names parameter, but declaring multiple constructors with the same record field names is clearly nonsense!
2022-08-11 17:22:56 +0200 <tomsmeding> oh wait it isn't, heh
2022-08-11 17:23:00 +0200 <tomsmeding> disregard that
2022-08-11 17:23:57 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:8722:865e:dc02:97b0) (Quit: WeeChat 2.8)
2022-08-11 17:25:16 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-11 17:25:56 +0200pmarg(~pmarg@224.80-203-5.customer.lyse.net)
2022-08-11 17:30:08 +0200pmarg(~pmarg@224.80-203-5.customer.lyse.net) (Read error: Connection reset by peer)
2022-08-11 17:34:00 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.6)
2022-08-11 17:35:20 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-11 17:37:02 +0200Guest56(~Guest56@152.red-88-14-101.dynamicip.rima-tde.net)
2022-08-11 17:37:03 +0200razetime(~quassel@117.193.4.185) (Ping timeout: 252 seconds)
2022-08-11 17:38:05 +0200Guest56(~Guest56@152.red-88-14-101.dynamicip.rima-tde.net) (Client Quit)
2022-08-11 17:38:06 +0200vglfr(~vglfr@37.73.137.225)
2022-08-11 17:39:15 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 17:39:30 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 244 seconds)
2022-08-11 17:43:41 +0200nate4(~nate@98.45.169.16)
2022-08-11 17:47:34 +0200vglfr(~vglfr@37.73.137.225) (Ping timeout: 268 seconds)
2022-08-11 17:49:18 +0200razetime(~quassel@117.254.34.226)
2022-08-11 17:49:53 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-11 17:52:41 +0200mikoto-chan(~mikoto-ch@85-76-75-89-nat.elisa-mobile.fi)
2022-08-11 17:53:55 +0200 <Athas> Dinging on GHC for being slow is very enjoyable, but it can compile my main project from scratch in 4m27s on my laptop. That's enough for me.
2022-08-11 17:54:07 +0200 <Athas> I do vaguely recall it wasn't always this fast.
2022-08-11 17:54:42 +0200 <merijn> Athas: The 9.x series has gotten quite some performance work
2022-08-11 17:55:02 +0200sabry(~sabry@41.44.89.119) (Quit: Client closed)
2022-08-11 17:55:05 +0200 <Athas> Yes, I'm using 9.2.4.
2022-08-11 17:55:37 +0200 <Athas> I also made an effort to split the module dependency tree of my program to be wider. GHC is pretty decent at intra-package parallelisation nowadays.
2022-08-11 17:55:43 +0200titibandit(~titibandi@2a00:8a60:c000:1:8a13:bf74:b2:8d47) (Remote host closed the connection)
2022-08-11 17:56:21 +0200coot(~coot@213.134.176.158)
2022-08-11 17:57:35 +0200 <tomsmeding> Athas: are you compiling with -j in GHC's flags?
2022-08-11 17:58:27 +0200 <Athas> Yes.
2022-08-11 17:58:27 +0200 <merijn> I was gonna port my code to GHC 9.x, but too much dependency churn to be worth it :p
2022-08-11 17:58:52 +0200 <Athas> Version migration has been pretty easy for me for the past few years. Maybe I'm just getting lucky.
2022-08-11 17:59:34 +0200 <merijn> Athas: Yeah, but this is stuff that's been pinned and unupdated since late 2018 :p
2022-08-11 18:00:25 +0200 <merijn> So with 1 or 2 (barely) maintained packages it quickly because quite a hassle to get everything working again. So I decided to "not fuck with it" until I finished archiving on Zenodo :p
2022-08-11 18:00:35 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 18:01:54 +0200MajorBiscuit(~MajorBisc@wlan-145-94-167-213.wlan.tudelft.nl) (Ping timeout: 264 seconds)
2022-08-11 18:01:55 +0200acidjnk_new(~acidjnk@p200300d6e70586293de428a35ddddd41.dip0.t-ipconnect.de)
2022-08-11 18:07:18 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 18:07:50 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 18:12:11 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 18:13:01 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 18:15:12 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de)
2022-08-11 18:22:43 +0200nate4(~nate@98.45.169.16)
2022-08-11 18:24:45 +0200mbuf(~Shakthi@122.165.55.71) (Quit: Leaving)
2022-08-11 18:26:55 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-11 18:28:53 +0200 <zzz> merijn: well i guess i mean something like, for example, if you have `f x = div x y * mod x y` it knows that `f = id`
2022-08-11 18:29:15 +0200 <zzz> i mean
2022-08-11 18:29:40 +0200 <zzz> f x = div x y * y + mod x y
2022-08-11 18:30:09 +0200 <zzz> stuff like this
2022-08-11 18:30:41 +0200 <geekosaur> that depends on laziness, though
2022-08-11 18:31:06 +0200 <geekosaur> and I'm not sure ghc knows that the wired in Int and Integer types are strict
2022-08-11 18:31:35 +0200 <geekosaur> such that that equivalence only holds for *lazy* types, since with strict types it could bottom when `id` wouldn't
2022-08-11 18:32:06 +0200 <geekosaur> laziness concerns complicate optimization considerably, sadly
2022-08-11 18:33:45 +0200valzant(~parsival@209.141.195.79) (Ping timeout: 244 seconds)
2022-08-11 18:38:15 +0200 <merijn> zzz: I'm not even immediately convinced that's true :p
2022-08-11 18:38:27 +0200 <merijn> mod vs rem is confusing and complicated :p
2022-08-11 18:39:25 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 268 seconds)
2022-08-11 18:41:02 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-08-11 18:41:23 +0200chele(~chele@user/chele) (Remote host closed the connection)
2022-08-11 18:44:36 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 18:45:18 +0200Chai-T-Rex(~ChaiTRex@user/chaitrex) (Quit: Chai-T-Rex)
2022-08-11 18:46:15 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-08-11 18:46:44 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 18:46:56 +0200 <zzz> well, div leaves out the remainder and mod is just rem but it behaves better with negative numbers in this case
2022-08-11 18:47:49 +0200 <zzz> so `div x y * y` is just `x - (mod x y)`
2022-08-11 18:48:11 +0200mikoto-chan(~mikoto-ch@85-76-75-89-nat.elisa-mobile.fi) (Ping timeout: 255 seconds)
2022-08-11 18:48:17 +0200 <Lears> We have divMod and quotRem so you can remember which to use with which. Just pretend div/mod/quot/rem don't even exist.
2022-08-11 18:48:50 +0200 <zzz> this was just a quick example of something "simplifiable" i came up with on the spot
2022-08-11 18:50:08 +0200 <zzz> Lears: and eeew partial funcions :p
2022-08-11 18:50:28 +0200 <dolio> The thing is, if you implement that simplification, will it ever actually matter?
2022-08-11 18:51:44 +0200 <zzz> dolio: not this specifically, but some general rules for simplification. i guess the compiler would have to know which functions are inverses of eachother, which are commutative, wich are associative, etc
2022-08-11 18:52:15 +0200 <zzz> wolfram alfa doesnt do too bad simplifying expressions
2022-08-11 18:52:23 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-08-11 18:52:23 +0200 <albet70> dminuoso , for example?
2022-08-11 18:53:29 +0200 <Lears> We kinda have this already, e.g. `fmap f . fmap g` is replaced with `fmap (f . g)`. But it's a bit fragile, so it might be hard to have it handle arithmetic simplifications flexibly or thoroughly.
2022-08-11 18:54:08 +0200 <Lears> (the mechanism is called RULES)
2022-08-11 18:55:00 +0200CiaoSen(~Jura@p200300c95738a5002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
2022-08-11 18:55:05 +0200 <zzz> aren't those just ad hoc simplifications?
2022-08-11 18:55:43 +0200 <zzz> but i guess i know what you mean
2022-08-11 18:55:51 +0200 <zzz> where do you draw the line
2022-08-11 18:56:24 +0200 <Lears> Is what wolfram does any different? It's probably just more careful about how it collects, composes and applies its ad hoc rules.
2022-08-11 18:57:03 +0200 <zzz> i have no idea but i imagine it's something a but more sophisticated
2022-08-11 18:57:17 +0200 <zzz> *bit
2022-08-11 18:59:04 +0200mikoto-chan(~mikoto-ch@85-76-75-89-nat.elisa-mobile.fi)
2022-08-11 18:59:31 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
2022-08-11 19:00:59 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 19:03:55 +0200adanwan_(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 19:04:42 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 268 seconds)
2022-08-11 19:05:04 +0200razetime(~quassel@117.254.34.226) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-08-11 19:05:45 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:589f:ba83:fe7:256a)
2022-08-11 19:07:43 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 19:07:48 +0200 <carbolymer> how do I compose lenses? https://bpa.st/URDA
2022-08-11 19:08:28 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 19:08:43 +0200Kaipei(~Kaiepi@142.68.249.28)
2022-08-11 19:08:58 +0200moonsheep(~user@user/moonsheep)
2022-08-11 19:11:11 +0200Kaiepi(~Kaiepi@142.68.249.28) (Ping timeout: 255 seconds)
2022-08-11 19:11:28 +0200 <geekosaur> you're composing them correctly but how those lenses compose makes no sense
2022-08-11 19:12:10 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:589f:ba83:fe7:256a) (Ping timeout: 268 seconds)
2022-08-11 19:12:11 +0200 <[exa]> carbolymer: I guess it's just the other way? (lenses compose left to right)
2022-08-11 19:12:49 +0200 <[exa]> as in, I see no reason why `db . query` wouldn't work
2022-08-11 19:13:01 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 19:13:55 +0200 <moonsheep> Is there any way to have multiple readers in an MTL stack? This article (https://ro-che.info/articles/2014-06-11-problem-with-mtl) suggests merging both readers with one record, but that isn't really possible in my case, since my actual monad stacks each individually have a reader, and one is part of the other
2022-08-11 19:14:22 +0200 <moonsheep> I understand the problem, but I was wondering what is the best workaround
2022-08-11 19:14:23 +0200 <carbolymer> [exa]: you're right, thanks
2022-08-11 19:14:32 +0200 <moonsheep> Preferably one that doesn't require writing tons of boilerplate.
2022-08-11 19:15:02 +0200 <geekosaur> we just have a custom liftX that lifts past the outer Reader so you can reach the inner one
2022-08-11 19:15:23 +0200 <moonsheep> But I can't have a function with multiple MonadReaders in its context because of functional dependencies
2022-08-11 19:16:04 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 19:16:25 +0200 <dolio> It isn't multiple MonadReaders for the same monad.
2022-08-11 19:16:31 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 19:16:51 +0200k`(~user@2605:a601:a60d:5400:55e6:a9b6:adcd:beaa)
2022-08-11 19:17:29 +0200 <[exa]> moonsheep: you might wrap Reader (possibly automatically with DerivingVia and everything) to make a lot of reader types with lots of different MonadReader class types, or have an indexed MonadReader class (such as `MonadReader Env1 Int a`), but honestly just don't
2022-08-11 19:17:49 +0200 <[exa]> moonsheep: what's the usecase?
2022-08-11 19:17:58 +0200 <k`> What is `Data.Default.def` for `Int`? 1 or 0 or something else? (It's not documented and the source is hidden from Hoogle.)
2022-08-11 19:17:59 +0200 <Lears> moonsheep: I have some code with three monad stacks, each a reader over the last. Two custom lifts and, best of all, two withRunIn*s, and all your problems are solved.
2022-08-11 19:19:13 +0200 <[exa]> k`: here: https://hackage.haskell.org/package/data-default-class-0.1.2.0/docs/src/Data-Default-Class.html#li…
2022-08-11 19:19:25 +0200 <[exa]> (it's in another package)
2022-08-11 19:20:48 +0200neceve(~quassel@2.26.93.14)
2022-08-11 19:20:54 +0200cheater(~Username@user/cheater)
2022-08-11 19:21:49 +0200 <geekosaur> 0, as I learned all too well close to a year ago…
2022-08-11 19:22:36 +0200 <monochrom> This is why Default makes less sense than Monoid.
2022-08-11 19:25:21 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 19:26:30 +0200jgeerds(~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 264 seconds)
2022-08-11 19:27:27 +0200 <geekosaur> https://github.com/xmonad/xmonad/commit/383ffb772e4a is why Default makes less sense than Monoid
2022-08-11 19:28:08 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-11 19:29:03 +0200ph88(~ph88@sonicwall.snp-ag.com) (Read error: Connection reset by peer)
2022-08-11 19:30:43 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-08-11 19:30:46 +0200 <carbolymer> is there a way to change functions this way `f(a -> b ->c) -> a -> b -> f c` for any number of arguments?
2022-08-11 19:31:47 +0200 <carbolymer> Applicative f
2022-08-11 19:32:27 +0200 <monochrom> If you don't mind "upgrading" to f(a -> b ->c) -> f a -> f b -> f c, it becomes liftA3.
2022-08-11 19:32:31 +0200Kaiepi(~Kaiepi@142.68.249.28)
2022-08-11 19:32:59 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2022-08-11 19:33:02 +0200 <monochrom> I might right "f <*> pure a <*> pure b <*> ... <*> pure z" in general.
2022-08-11 19:33:08 +0200 <monochrom> s/right/write/
2022-08-11 19:33:18 +0200 <monochrom> "Mr. Wright is right" :)
2022-08-11 19:33:26 +0200 <carbolymer> monochrom: actually I mind ;)
2022-08-11 19:33:39 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de) (Quit: Leaving.)
2022-08-11 19:33:40 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 19:34:17 +0200vysn(~vysn@user/vysn) (Ping timeout: 268 seconds)
2022-08-11 19:35:23 +0200 <Lears> :t let ff &> x = ff <&> ($ x); infixl 4 &> in \ff x y z -> ff &> x &> y &> z
2022-08-11 19:35:24 +0200 <lambdabot> Functor f => f (a1 -> a2 -> a3 -> b) -> a1 -> a2 -> a3 -> f b
2022-08-11 19:35:29 +0200Kaipei(~Kaiepi@142.68.249.28) (Ping timeout: 252 seconds)
2022-08-11 19:35:39 +0200 <Lears> You can do something like that, though I'm not sure about the name.
2022-08-11 19:35:47 +0200 <Lears> Or if it exists somewhere.
2022-08-11 19:36:13 +0200 <carbolymer> @_@
2022-08-11 19:36:28 +0200 <monochrom> Yeah I was about to suggest that too.
2022-08-11 19:36:54 +0200 <ddellacosta> where can I find more on how the choices for the extensions in GHC2021 were made? I'm just curious
2022-08-11 19:37:22 +0200 <monochrom> &> is like <*> except that it just needs Functor because it's "downgraded" to f (x -> y) -> x -> f y
2022-08-11 19:37:50 +0200 <carbolymer> ddellacosta: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst
2022-08-11 19:37:59 +0200 <ddellacosta> carbolymer: thank you!
2022-08-11 19:38:04 +0200 <carbolymer> ddellacosta: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html
2022-08-11 19:38:21 +0200phma(~phma@host-67-44-208-154.hnremote.net) (Read error: Connection reset by peer)
2022-08-11 19:38:32 +0200 <moonsheep> [exa]: so there really isn't anything I can do other than wrapping everything in newtypes and making classes?
2022-08-11 19:39:14 +0200phma(~phma@host-67-44-208-161.hnremote.net)
2022-08-11 19:39:23 +0200 <carbolymer> monochrom: makes sense
2022-08-11 19:39:32 +0200 <carbolymer> Lears: thans, I'l try that
2022-08-11 19:40:42 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 19:40:54 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 19:43:14 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 19:46:19 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 19:51:46 +0200gmg(~user@user/gehmehgeh)
2022-08-11 19:52:11 +0200adanwan_(~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 268 seconds)
2022-08-11 19:52:32 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 19:52:38 +0200econo(uid147250@user/econo)
2022-08-11 19:52:49 +0200slac79690(~slack1256@2607:fb90:c6b:3cba:71e3:d44c:d4aa:8a0b)
2022-08-11 19:53:25 +0200valzant(~parsival@209.141.195.79)
2022-08-11 19:55:11 +0200slack1256(~slack1256@wsip-184-177-0-226.no.no.cox.net) (Ping timeout: 268 seconds)
2022-08-11 19:57:37 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 20:05:09 +0200geranim0(~geranim0@modemcable062.79-202-24.mc.videotron.ca) (Remote host closed the connection)
2022-08-11 20:05:26 +0200 <monochrom> Haha I suck at this game: http://www.doscienceto.it/whos-that-monoid/
2022-08-11 20:05:55 +0200geranim0(~geranim0@modemcable062.79-202-24.mc.videotron.ca)
2022-08-11 20:06:06 +0200aeka(~aeka@2606:6080:1001:17:9ea4:71f9:d294:d7b7) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-11 20:06:25 +0200slack1256(~slack1256@69.85.193.146)
2022-08-11 20:06:30 +0200aeka(~aeka@user/hiruji)
2022-08-11 20:06:54 +0200mikoto-chan(~mikoto-ch@85-76-75-89-nat.elisa-mobile.fi) (Ping timeout: 268 seconds)
2022-08-11 20:08:00 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2022-08-11 20:08:08 +0200valzant(~parsival@209.141.195.79) (Ping timeout: 268 seconds)
2022-08-11 20:08:23 +0200mikoto-chan(~mikoto-ch@164.5.249.78)
2022-08-11 20:08:46 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 20:08:49 +0200slac79690(~slack1256@2607:fb90:c6b:3cba:71e3:d44c:d4aa:8a0b) (Ping timeout: 244 seconds)
2022-08-11 20:09:13 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds)
2022-08-11 20:09:27 +0200moonsheep(~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1))
2022-08-11 20:10:05 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2022-08-11 20:10:06 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 20:10:13 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec)
2022-08-11 20:10:52 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 20:11:26 +0200slack1256(~slack1256@69.85.193.146) (Ping timeout: 255 seconds)
2022-08-11 20:13:08 +0200euandreh_euandreh
2022-08-11 20:14:45 +0200kenran(~kenran@200116b82be1610022a2541211968a00.dip.versatel-1u1.de)
2022-08-11 20:14:52 +0200kenran(~kenran@200116b82be1610022a2541211968a00.dip.versatel-1u1.de) (Client Quit)
2022-08-11 20:14:58 +0200 <monochrom> cabal-install 3.8 looks nice.
2022-08-11 20:15:05 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-08-11 20:16:06 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-11 20:17:10 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2022-08-11 20:19:36 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Read error: Connection reset by peer)
2022-08-11 20:19:36 +0200ec(~ec@gateway/tor-sasl/ec) (Write error: Connection reset by peer)
2022-08-11 20:19:36 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Write error: Connection reset by peer)
2022-08-11 20:20:01 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 20:20:04 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-08-11 20:20:06 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 20:20:07 +0200troydm(~troydm@host-176-37-124-197.b025.la.net.ua) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset)
2022-08-11 20:20:13 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-11 20:20:46 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 20:21:17 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 20:22:43 +0200troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-08-11 20:23:04 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 20:23:13 +0200mastarija(~mastarija@2a05:4f46:e03:6000:a177:7533:ec47:fb52)
2022-08-11 20:23:22 +0200valzant(~parsival@209.141.195.79)
2022-08-11 20:23:24 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 20:23:29 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 20:23:51 +0200mastarija(~mastarija@2a05:4f46:e03:6000:a177:7533:ec47:fb52) (Client Quit)
2022-08-11 20:28:15 +0200neceve(~quassel@2.26.93.14) (Remote host closed the connection)
2022-08-11 20:31:23 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 20:31:36 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 20:32:36 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de)
2022-08-11 20:32:58 +0200 <zzz> from the gloss docs, the the 7th argument to the function `play`, of type `(Float -> world -> world)` is described as "A function to step the world one interation. It is passed the period of time (in seconds) needing to be advanced.". I don't understand what this means.
2022-08-11 20:33:08 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de) (Client Quit)
2022-08-11 20:33:09 +0200ianliu(~Ian_Liu_R@2804:431:cfcf:8a26:265:a252:7b71:aacb)
2022-08-11 20:33:17 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 20:33:36 +0200 <zzz> What is "the period of time needing to be advanced" ?
2022-08-11 20:34:01 +0200 <geekosaur> the amount of time that has passed in the "world"
2022-08-11 20:35:05 +0200 <monochrom> Suppose you intend a frame rate of 10 frames per second. Then the next frame is 0.1 seconds after the previous frame. Now s/frame/world/ because what's a frame other than a projection of the world.
2022-08-11 20:35:33 +0200 <zzz> i see
2022-08-11 20:36:02 +0200pagnol(~me@213-205-209-87.ftth.glasoperator.nl)
2022-08-11 20:36:56 +0200 <ianliu> on https://wiki.haskell.org/Foreign_Function_Interface there is a warning on the top saying not to use ccall and use capi, but I couldn't find any working "hello world" for capi. Is there any "tutorial" on capi out there?
2022-08-11 20:37:02 +0200 <zzz> so the world gets updated at x time and rendered at x+1/fps, at which point the world gets updated again?
2022-08-11 20:37:41 +0200jgeerds(~jgeerds@55d46bad.access.ecotel.net)
2022-08-11 20:37:45 +0200 <monochrom> The GHC User's Guide has capi examples.
2022-08-11 20:38:32 +0200 <monochrom> But anything that ccall works for, you can just s/ccall/capi/ and it still works, just via a different path.
2022-08-11 20:39:30 +0200 <pagnol> are there any packages which provide a Tree class with implementations of all sorts of algorithms on trees?
2022-08-11 20:39:41 +0200 <monochrom> And then capi also works for, for example, C macros.
2022-08-11 20:40:12 +0200 <monochrom> (Just pretend the macro is a function/global-variable of the appropriate type.)
2022-08-11 20:41:00 +0200 <monochrom> The GHC User's Guide also explains how it manages to get macros to work.
2022-08-11 20:41:05 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
2022-08-11 20:41:25 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 20:41:49 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 20:41:51 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 20:41:55 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 20:42:37 +0200Guest|1(~Guest|1@172.58.171.168)
2022-08-11 20:43:19 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 20:43:35 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 20:45:42 +0200Tuplanolla(~Tuplanoll@91-159-69-12.elisa-laajakaista.fi)
2022-08-11 20:48:26 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-11 20:48:59 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 20:53:46 +0200Guest|1(~Guest|1@172.58.171.168) (Ping timeout: 268 seconds)
2022-08-11 20:55:52 +0200 <ianliu> monochrom: hmm, changing ccall to capi gives me a parse error
2022-08-11 20:56:15 +0200 <geekosaur> did you do {-# LANGUAGE CApiFFI #-} ?
2022-08-11 20:56:35 +0200stonedHash
2022-08-11 20:56:38 +0200 <ianliu> ah
2022-08-11 20:56:41 +0200 <ianliu> now it works :P
2022-08-11 20:56:42 +0200 <ianliu> thanks
2022-08-11 20:57:02 +0200 <monochrom> Did the wiki remind you?
2022-08-11 20:57:55 +0200 <monochrom> No. This is why I don't read the wiki.
2022-08-11 20:58:04 +0200 <ianliu> https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/ffi.html?highlight=capiffi#exte… This page here doesn't show a working example, but now that geekosaur replied, I see that the user guide says "The CApiFFI *extension*"
2022-08-11 20:58:05 +0200geekosaurjust has it memorized
2022-08-11 20:58:46 +0200 <ianliu> I don't program in haskell very much, so I'm not used to it
2022-08-11 20:59:03 +0200 <monochrom> No worries, I'm roasting low quality haskell wiki
2022-08-11 20:59:40 +0200 <monochrom> Right? An off-the-hand remark "use capi instead of ccall" and no support.
2022-08-11 21:01:16 +0200 <monochrom> The fact is that ccall is still in use and is still suitable for a lot of things.
2022-08-11 21:01:32 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 21:01:43 +0200chomwitt(~chomwitt@2a02:587:dc15:5e00:671f:736d:4d41:28c3)
2022-08-11 21:01:52 +0200 <geekosaur> ghc hq is strongly pushing capi and hinting that ccall may go away in the future
2022-08-11 21:02:04 +0200 <geekosaur> it causes too many weird support issues
2022-08-11 21:02:06 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 21:02:18 +0200 <monochrom> The useful thing to know is under what condition ccall fails and why doesn't capi suffer the same issue.
2022-08-11 21:02:37 +0200 <geekosaur> the problem is, knowing that requires internals knowledge of the thing you're calling
2022-08-11 21:02:53 +0200Boone(~Boone@172.58.171.168)
2022-08-11 21:03:00 +0200 <geekosaur> like, you have to know that glibc hides under several layers of macros the fact that there are four variants of the stat() syscall
2022-08-11 21:03:09 +0200McCabe(~McCabe@63.sub-174-231-82.myvzw.com)
2022-08-11 21:03:14 +0200 <monochrom> Sure, but I don't mean that.
2022-08-11 21:03:18 +0200 <geekosaur> and the only way you'll get that right is to call it with capi
2022-08-11 21:03:34 +0200 <monochrom> I just mean that, e.g., ccall fails if the "function" is a macro.
2022-08-11 21:03:40 +0200 <monochrom> That is not rocket science.
2022-08-11 21:03:46 +0200 <geekosaur> right, but when do you know that?
2022-08-11 21:04:16 +0200 <geekosaur> "not rocket science" to those of us who know C and know how to trace through possibly multiple layers of include files
2022-08-11 21:04:23 +0200Boone(~Boone@172.58.171.168) (Client Quit)
2022-08-11 21:04:50 +0200 <monochrom> No, just who know C.
2022-08-11 21:04:50 +0200 <geekosaur> and looking in a symbol table won't necessarily work because it may have one that's not guaranteed to work without all those macros
2022-08-11 21:05:14 +0200 <monochrom> Again, I do not mean that one has to find out whether execvp is a macro.
2022-08-11 21:06:47 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-08-11 21:08:52 +0200McCabe(~McCabe@63.sub-174-231-82.myvzw.com) (Quit: Connection closed)
2022-08-11 21:10:01 +0200 <geekosaur> in any case, you're arguing with the wrong person. as I said, ghc hq is deprecating ccall in favor of capi
2022-08-11 21:10:19 +0200 <geekosaur> argue it with them or make your peace with it
2022-08-11 21:11:20 +0200 <monochrom> I make peace with that. I just want more people to know why.
2022-08-11 21:12:12 +0200 <geekosaur> that's fine as long as it you and not ghc hq that has to do so, I suspect 🙂
2022-08-11 21:12:17 +0200Kaiepi(~Kaiepi@142.68.249.28) (Ping timeout: 252 seconds)
2022-08-11 21:12:21 +0200 <geekosaur> *it's
2022-08-11 21:13:35 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 21:13:41 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 21:14:06 +0200 <monochrom> And someone who cares about the wiki could have just done a s/ccall/capi/g instead of "oh let's be too afraid to change existing content, let's just add one mysterious line at the top".
2022-08-11 21:14:14 +0200 <monochrom> (I no longer care about the wiki.)
2022-08-11 21:20:39 +0200McCabe(~McCabe@63.sub-174-231-82.myvzw.com)
2022-08-11 21:21:15 +0200McCabe(~McCabe@63.sub-174-231-82.myvzw.com) (Client Quit)
2022-08-11 21:21:42 +0200McCabe(~McCabe@63.sub-174-231-82.myvzw.com)
2022-08-11 21:23:25 +0200McCabe(~McCabe@63.sub-174-231-82.myvzw.com) (Client Quit)
2022-08-11 21:24:03 +0200 <k`> Wikis can be high value, but for whatever reason Haskell seems to rely much more on blogs.
2022-08-11 21:24:36 +0200 <monochrom> Yeah I just mean the haskell wiki.
2022-08-11 21:24:53 +0200 <monochrom> But no, the blogs are not of better quality either.
2022-08-11 21:25:28 +0200 <monochrom> An article is of value [to readers] iff it is written for readers.
2022-08-11 21:25:29 +0200valzant(~parsival@209.141.195.79) (Ping timeout: 252 seconds)
2022-08-11 21:25:49 +0200 <k`> What would you do if there wasn't someone to rant at you that 'Monads are burritos'?
2022-08-11 21:26:08 +0200 <geekosaur> be happier?
2022-08-11 21:26:13 +0200 <monochrom> Writers of the Haskell wiki and many Haskell blogs have "I'm so excited I must share this in mind". This usually does not align with the readers.
2022-08-11 21:27:12 +0200 <k`> Unfortunately, Haskell changes quickly enough in backwards-incompatible ways that a Haskell book is likely out-of-date before it is published.
2022-08-11 21:27:45 +0200 <monochrom> Oh, I said that on haskell-cafe when someone talked about writing a Haskell database book.
2022-08-11 21:28:16 +0200 <monochrom> That someone was not very happy to hear such a cold hard truth. :)
2022-08-11 21:28:42 +0200 <monochrom> Hell, even databases change quickly too.
2022-08-11 21:32:00 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 21:33:30 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 21:35:17 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 21:36:38 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 21:38:40 +0200acidjnk_new(~acidjnk@p200300d6e70586293de428a35ddddd41.dip0.t-ipconnect.de) (Remote host closed the connection)
2022-08-11 21:39:03 +0200acidjnk_new(~acidjnk@p200300d6e70586293de428a35ddddd41.dip0.t-ipconnect.de)
2022-08-11 21:39:23 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 21:41:19 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 21:45:24 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 21:45:31 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 21:46:34 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 21:49:01 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-11 21:49:52 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 21:53:35 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds)
2022-08-11 21:55:54 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-11 21:56:38 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 21:57:17 +0200cheater(~Username@user/cheater) (Ping timeout: 268 seconds)
2022-08-11 21:57:32 +0200Kaiepi(~Kaiepi@142.68.249.28)
2022-08-11 21:59:28 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 21:59:38 +0200cheater(~Username@user/cheater)
2022-08-11 22:00:23 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-11 22:00:32 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-08-11 22:00:40 +0200jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff)
2022-08-11 22:00:56 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-11 22:01:22 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-08-11 22:02:44 +0200titibandit(~titibandi@xdsl-212-8-147-38.nc.de)
2022-08-11 22:03:28 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Client Quit)
2022-08-11 22:03:46 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 22:04:08 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 22:04:12 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 22:05:34 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 22:05:35 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 244 seconds)
2022-08-11 22:06:31 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 22:06:53 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 22:10:19 +0200acidjnk_new(~acidjnk@p200300d6e70586293de428a35ddddd41.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2022-08-11 22:12:27 +0200jargon(~jargon@184.101.168.117) (Remote host closed the connection)
2022-08-11 22:13:58 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 22:14:01 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
2022-08-11 22:15:26 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 22:16:08 +0200slack1256(~slack1256@wsip-184-177-0-226.no.no.cox.net)
2022-08-11 22:17:38 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 22:23:50 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-08-11 22:26:44 +0200acidjnk(~acidjnk@p200300d6e70586290c6dd2639c811ffe.dip0.t-ipconnect.de)
2022-08-11 22:27:18 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 22:27:42 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 22:30:28 +0200 <ddellacosta> It seems like people with a deeper understanding of Haskell/PLT/etc. use the expression "term-level" to talk about values (vs. "type-level")--but why is it not "value-level?" I thought "term" was a very general word for syntactic constructs--what is the history of this usage, where does it come from?
2022-08-11 22:30:28 +0200vysn(~vysn@user/vysn)
2022-08-11 22:31:33 +0200 <tomsmeding> people use "value-level" as well
2022-08-11 22:31:52 +0200 <tomsmeding> a "term" is, in general, usually a piece of syntax
2022-08-11 22:32:45 +0200 <tomsmeding> but the thing is, for types, the word "type" can both refer to the abstract concept of some type, say the type of the integers, as well as to the syntax that describes it, e.g. `Integer`
2022-08-11 22:33:00 +0200 <tomsmeding> though I believe I've seen people use "type-term" for the latter -- but not sure
2022-08-11 22:33:20 +0200 <tomsmeding> for value-level things, "value" doesn't refer to both -- a "value" is simply the abstract meaning of a program
2022-08-11 22:33:38 +0200 <tomsmeding> the syntax that describes it is itself not a value (barring lisps)
2022-08-11 22:34:14 +0200yvan-sraka(~yvan-srak@105.67.135.250)
2022-08-11 22:34:20 +0200 <tomsmeding> so people use "term" for that when constrasting with types -- and it's probably also a factor that the words "type" and "term" are both similar in structure :)
2022-08-11 22:34:48 +0200 <qrpnxz> ghc just hit me with a <<loop>> 🥹 debug time
2022-08-11 22:35:32 +0200 <ddellacosta> tomsmeding: okay, I have to think about that a bit--thank you
2022-08-11 22:40:11 +0200pmarg(~pmarg@2a01:799:159f:9b00:9386:acc:da1e:eccd)
2022-08-11 22:41:45 +0200son0p(~ff@181.136.122.143) (Ping timeout: 252 seconds)
2022-08-11 22:42:11 +0200ddellacosta(~ddellacos@143.244.47.100) (Ping timeout: 255 seconds)
2022-08-11 22:42:55 +0200Furor(~colere@about/linux/staff/sauvin)
2022-08-11 22:45:05 +0200pmarg(~pmarg@2a01:799:159f:9b00:9386:acc:da1e:eccd) (Remote host closed the connection)
2022-08-11 22:47:16 +0200Colere(~colere@about/linux/staff/sauvin) (Ping timeout: 268 seconds)
2022-08-11 22:50:31 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2022-08-11 22:54:23 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec)
2022-08-11 22:54:41 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 22:54:41 +0200califax(~califax@user/califx) (Read error: Connection reset by peer)
2022-08-11 22:54:41 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-11 22:54:42 +0200ec(~ec@gateway/tor-sasl/ec) (Write error: Connection reset by peer)
2022-08-11 22:54:42 +0200jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2022-08-11 22:55:04 +0200jpds(~jpds@gateway/tor-sasl/jpds)
2022-08-11 22:55:04 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 22:55:12 +0200califax(~califax@user/califx)
2022-08-11 22:55:17 +0200ec(~ec@gateway/tor-sasl/ec)
2022-08-11 22:55:28 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-11 22:57:05 +0200califax(~califax@user/califx) (Remote host closed the connection)
2022-08-11 22:57:22 +0200califax(~califax@user/califx)
2022-08-11 22:59:38 +0200Inst(~Inst@2601:6c4:4080:3f80:60a2:552d:5c38:7396)
2022-08-11 23:01:32 +0200toby(~toby@137.220.84.171)
2022-08-11 23:03:20 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2022-08-11 23:03:20 +0200allbery_b(~geekosaur@xmonad/geekosaur)
2022-08-11 23:03:23 +0200allbery_bgeekosaur
2022-08-11 23:09:45 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-08-11 23:10:15 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Quit: Leaving)
2022-08-11 23:11:04 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 23:11:19 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds)
2022-08-11 23:13:05 +0200FurorColere
2022-08-11 23:16:07 +0200 <monochrom> Oh darn missed that conversation.
2022-08-11 23:17:34 +0200kadoban1(~kadoban@user/kadoban) ()
2022-08-11 23:17:36 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 23:17:49 +0200kadoban1(~kadoban@user/kadoban)
2022-08-11 23:19:21 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-11 23:19:32 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-11 23:22:15 +0200 <toby> Recently started with haskell. I've been running into a segfault/assertion failiure at in the nonmoving-gc (rts/sm/NonMovingMark.c:1815 on a few ghc versions, including ghc-9.2.4. I have some sort of reproducer for this but im not sure if this is something dodgy in a library or an actual RTS bug. Any pointers on how to go about pinning this down further?
2022-08-11 23:22:44 +0200ubert(~Thunderbi@178.165.178.67.wireless.dyn.drei.com) (Ping timeout: 255 seconds)
2022-08-11 23:28:22 +0200zer0bitz(~zer0bitz@2001:2003:f748:2000:4941:f6bb:794b:548e) (Read error: Connection reset by peer)
2022-08-11 23:30:12 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-11 23:31:05 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-11 23:35:24 +0200 <merijn> toby: Check with #ghc ?
2022-08-11 23:35:30 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-11 23:35:35 +0200dcoutts(~duncan@host86-167-206-78.range86-167.btcentralplus.com)
2022-08-11 23:35:37 +0200ianliu(~Ian_Liu_R@2804:431:cfcf:8a26:265:a252:7b71:aacb) (Quit: WeeChat 3.6)
2022-08-11 23:36:01 +0200dcoutts_(~duncan@host86-167-206-78.range86-167.btcentralplus.com) (Ping timeout: 252 seconds)
2022-08-11 23:38:45 +0200 <geekosaur> they just fixed such a bug but it should have been fixed already in 9.2.4
2022-08-11 23:43:23 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 23:44:53 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-11 23:44:53 +0200jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2022-08-11 23:44:53 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 23:45:25 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 23:45:26 +0200jpds(~jpds@gateway/tor-sasl/jpds)
2022-08-11 23:45:30 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Client Quit)
2022-08-11 23:45:36 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-11 23:45:51 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 23:48:05 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-11 23:48:26 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-11 23:48:47 +0200jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2022-08-11 23:49:08 +0200jpds(~jpds@gateway/tor-sasl/jpds)
2022-08-11 23:50:55 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-11 23:54:36 +0200ccntrq(~Thunderbi@172.209.94.92.rev.sfr.net) (Remote host closed the connection)
2022-08-11 23:55:32 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-11 23:56:22 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2022-08-11 23:59:15 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-11 23:59:28 +0200dcoutts_(~duncan@host86-153-135-126.range86-153.btcentralplus.com)