2022/10/04

2022-10-04 00:03:18 +0200mvk(~mvk@2607:fea8:5ce3:8500::778c)
2022-10-04 00:11:40 +0200hgolden(~hgolden@cpe-172-251-233-141.socal.res.rr.com)
2022-10-04 00:15:51 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2022-10-04 00:16:08 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 00:16:20 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds)
2022-10-04 00:17:07 +0200Lord_of_Life_Lord_of_Life
2022-10-04 00:20:35 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds)
2022-10-04 00:20:59 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-10-04 00:22:48 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-10-04 00:24:55 +0200coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-10-04 00:31:14 +0200mikoto-chan(~mikoto-ch@164.5.249.78)
2022-10-04 00:42:33 +0200lys(lys@id-194105.uxbridge.irccloud.com) (Quit: At the still point of the turning world, there the dance is)
2022-10-04 00:43:20 +0200michalz(~michalz@185.246.207.197) (Remote host closed the connection)
2022-10-04 00:44:15 +0200stackdroid18(~stackdroi@user/stackdroid) (Quit: Lost terminal)
2022-10-04 00:48:03 +0200nate4(~nate@98.45.169.16)
2022-10-04 00:49:37 +0200Topsi(~Topsi@dyndsl-095-033-018-041.ewe-ip-backbone.de) (Quit: Leaving.)
2022-10-04 00:49:56 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection)
2022-10-04 00:53:33 +0200nate4(~nate@98.45.169.16) (Ping timeout: 265 seconds)
2022-10-04 00:55:33 +0200son0p(~ff@181.136.122.143)
2022-10-04 00:58:58 +0200vorpuni(~pvorp@2001:861:3881:c690:a94c:fa1b:4d2b:c74b) (Remote host closed the connection)
2022-10-04 00:59:27 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-10-04 01:01:23 +0200wonko(~wjc@2a0e:1c80:11::50) (Ping timeout: 248 seconds)
2022-10-04 01:02:18 +0200ellensol(~ellen@178-78-210-152.customers.ownit.se)
2022-10-04 01:07:05 +0200ellensol(~ellen@178-78-210-152.customers.ownit.se) (Ping timeout: 265 seconds)
2022-10-04 01:15:45 +0200Tuplanolla(~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) (Quit: Leaving.)
2022-10-04 01:21:36 +0200ncfaaaaaaaaaaaaaaaa
2022-10-04 01:21:46 +0200aaaaaaaaaaaaaaaancf
2022-10-04 01:25:56 +0200caryhartline(~caryhartl@wireless-mustang28.nat.smu.edu)
2022-10-04 01:27:38 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 01:28:16 +0200mvk(~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 260 seconds)
2022-10-04 01:31:09 +0200mmhat(~mmh@p200300f1c7062353ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
2022-10-04 01:35:29 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds)
2022-10-04 01:37:34 +0200 <alexfmpe[m]> there a way to spit out the core for a function inside ghci?
2022-10-04 01:38:01 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Ping timeout: 265 seconds)
2022-10-04 01:39:01 +0200 <geekosaur> you could :set -ddump-ds and then :r
2022-10-04 01:39:15 +0200 <geekosaur> once it's compiled, though, it's too late to ask for core
2022-10-04 01:39:24 +0200 <geekosaur> it's either bytecode or object code
2022-10-04 01:39:54 +0200 <geekosaur> (or if you're defining at the prompt, :set -ddump-ds and then define it again at the prompt)
2022-10-04 01:41:24 +0200 <alexfmpe[m]> ah thanks that worked
2022-10-04 01:46:10 +0200mmhat(~mmh@p57998e06.dip0.t-ipconnect.de)
2022-10-04 01:50:54 +0200EvanR(~EvanR@user/evanr) (Remote host closed the connection)
2022-10-04 01:51:13 +0200EvanR(~EvanR@user/evanr)
2022-10-04 01:59:31 +0200caryhartline(~caryhartl@wireless-mustang28.nat.smu.edu) (Quit: caryhartline)
2022-10-04 02:01:54 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 02:04:04 +0200moonsheep(~moonsheep@user/moonsheep)
2022-10-04 02:14:38 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-04 02:15:25 +0200ellensol(~ellen@178-78-210-152.customers.ownit.se)
2022-10-04 02:15:59 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net)
2022-10-04 02:18:08 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Ping timeout: 265 seconds)
2022-10-04 02:18:27 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-10-04 02:19:45 +0200ellensol(~ellen@178-78-210-152.customers.ownit.se) (Ping timeout: 252 seconds)
2022-10-04 02:24:11 +0200jargon(~jargon@174-22-199-121.phnx.qwest.net)
2022-10-04 02:24:15 +0200moonsheep(~moonsheep@user/moonsheep) (Quit: nyaa~)
2022-10-04 02:24:18 +0200 <_73> I am making a regex engine that must take a regex and produce a finite automaton. I am having trouble figuring out how I should represent a state at the type level. Here is my type for a FA that will be complete once I know what a "State" should be: http://dpaste.com/293QLNFEC
2022-10-04 02:28:02 +0200meinside(uid24933@id-24933.helmsley.irccloud.com)
2022-10-04 02:28:08 +0200 <EvanR> make State an abstract type 😎
2022-10-04 02:29:51 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 02:29:51 +0200 <_73> Could you expand on that?
2022-10-04 02:30:30 +0200doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com)
2022-10-04 02:31:02 +0200edrx(~Eduardo@2804:56c:d2d3:4800:cf7d:b421:4c3a:392e)
2022-10-04 02:31:09 +0200 <_73> I believe this is what you mean - http://dpaste.com/FQEWXLSP2
2022-10-04 02:31:26 +0200 <EvanR> just that whatever the state ends up being, do I have to know?
2022-10-04 02:31:59 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal)
2022-10-04 02:32:38 +0200 <_73> Ok, but what will the state likely end up being?
2022-10-04 02:33:36 +0200econo(uid147250@user/econo)
2022-10-04 02:33:42 +0200 <EvanR> do you already know what the state is but you are trying to implement it concretely?
2022-10-04 02:34:57 +0200 <EvanR> like, as an Int?
2022-10-04 02:35:49 +0200 <_73> I am trying to translate from my book about FA's where a State is just a numbered dot in an FA diagram. I do not know, concretely, what the State type will be in my Regex implementation.
2022-10-04 02:36:30 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net)
2022-10-04 02:38:28 +0200 <EvanR> it could be a number that maps into a set of whatever relevant data is associated with each state in the book
2022-10-04 02:39:00 +0200beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 268 seconds)
2022-10-04 02:39:16 +0200 <_73> So maybe an integer that is an index in the input string? Does that make sense?
2022-10-04 02:39:28 +0200 <EvanR> no...
2022-10-04 02:39:48 +0200 <EvanR> the position of input is something else
2022-10-04 02:40:15 +0200 <EvanR> it should be independent of your machine state
2022-10-04 02:42:47 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Ping timeout: 265 seconds)
2022-10-04 02:43:41 +0200 <_73> Ohhh ok. So say I have the regex "ab|cd" and I have already seen an "a" in the input string. My state must represent where in the machine I am that will accept either a "b" or a "cd".
2022-10-04 02:43:43 +0200 <EvanR> if the book has some kind notation to determine what is supposed to happen in a state, maybe you could model it as that notation.
2022-10-04 02:44:42 +0200 <_73> Yes it does have such a notation.
2022-10-04 02:44:55 +0200 <_73> I am much closer to understanding now
2022-10-04 02:46:41 +0200 <edrx> hi all!
2022-10-04 02:46:59 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2022-10-04 02:47:24 +0200 <edrx> does the bot have entries with instructions for compiling a recent ghc from source? what are the key words?
2022-10-04 02:47:35 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds)
2022-10-04 02:47:40 +0200justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 268 seconds)
2022-10-04 02:47:43 +0200 <jackdk> I'd go to the GHC user guide or a source tarball for that
2022-10-04 02:47:58 +0200dsrt^(~dsrt@c-76-17-6-165.hsd1.ga.comcast.net)
2022-10-04 02:48:16 +0200Lord_of_Life_Lord_of_Life
2022-10-04 02:50:38 +0200 <geekosaur> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian fwiw
2022-10-04 02:50:45 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 02:51:29 +0200 <geekosaur> make works through 9.2 but is being removed from the tree because it can't cope with newer versions, so becoming familiar with Hadrian is strongly recommended
2022-10-04 02:51:31 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net) (Quit: xff0x)
2022-10-04 02:51:56 +0200xff0x(~xff0x@2405:6580:b080:900:9917:904:91b1:8303)
2022-10-04 02:52:01 +0200 <geekosaur> @where hadrian
2022-10-04 02:52:02 +0200 <lambdabot> I know nothing about hadrian.
2022-10-04 02:52:08 +0200 <geekosaur> @where+ hadrian https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian
2022-10-04 02:52:09 +0200 <lambdabot> It is stored.
2022-10-04 02:57:43 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com)
2022-10-04 02:57:43 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host)
2022-10-04 02:57:43 +0200wroathe(~wroathe@user/wroathe)
2022-10-04 02:58:27 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-10-04 03:01:11 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-10-04 03:07:32 +0200nate4(~nate@98.45.169.16)
2022-10-04 03:11:46 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Ping timeout: 246 seconds)
2022-10-04 03:12:11 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-10-04 03:13:58 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-04 03:14:05 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 03:17:23 +0200xff0x(~xff0x@2405:6580:b080:900:9917:904:91b1:8303) (Ping timeout: 248 seconds)
2022-10-04 03:19:14 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-10-04 03:19:28 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 246 seconds)
2022-10-04 03:19:31 +0200ddellacosta(~ddellacos@143.244.47.73) (Ping timeout: 265 seconds)
2022-10-04 03:19:35 +0200nate4(~nate@98.45.169.16)
2022-10-04 03:20:08 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-04 03:29:26 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-10-04 03:30:50 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-04 03:34:50 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds)
2022-10-04 03:35:07 +0200doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 268 seconds)
2022-10-04 03:35:08 +0200mmhat(~mmh@p57998e06.dip0.t-ipconnect.de) (Quit: WeeChat 3.6)
2022-10-04 03:36:08 +0200mikoto-chan(~mikoto-ch@164.5.249.78) (Read error: Connection reset by peer)
2022-10-04 03:36:21 +0200caryhartline(~caryhartl@2600:1700:2d0:8d30:f196:e70f:bc3c:9f5f)
2022-10-04 03:36:45 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-04 03:44:44 +0200caryhartline(~caryhartl@2600:1700:2d0:8d30:f196:e70f:bc3c:9f5f) (Quit: caryhartline)
2022-10-04 03:53:00 +0200 <Axman6> _73: https://wiki.haskell.org/Regular_expressions_for_XML_Schema
2022-10-04 03:53:29 +0200 <Axman6> I recently used this to implement regexes in our app, and it worked really well - it's such a beautiful implementation IMO
2022-10-04 03:55:11 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2022-10-04 03:56:44 +0200biberu\(~biberu@user/biberu)
2022-10-04 04:00:14 +0200alphabeta(~kilolympu@213.144.144.24)
2022-10-04 04:00:36 +0200biberu(~biberu@user/biberu) (Ping timeout: 265 seconds)
2022-10-04 04:00:36 +0200kilolympus(~kilolympu@213.144.144.24) (Ping timeout: 265 seconds)
2022-10-04 04:00:36 +0200biberu\biberu
2022-10-04 04:02:15 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 268 seconds)
2022-10-04 04:02:32 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2022-10-04 04:08:39 +0200td_(~td@94.134.91.118) (Ping timeout: 252 seconds)
2022-10-04 04:10:35 +0200td_(~td@muedsl-82-207-238-106.citykom.de)
2022-10-04 04:12:48 +0200dumptruckman(~dumptruck@172-105-129-222.ip.linodeusercontent.com) (Remote host closed the connection)
2022-10-04 04:13:52 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2022-10-04 04:16:27 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2022-10-04 04:16:27 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2022-10-04 04:16:27 +0200finn_elijaFinnElija
2022-10-04 04:17:25 +0200dumptruckman(~dumptruck@45-33-69-234.ip.linodeusercontent.com)
2022-10-04 04:17:34 +0200 <jackdk> https://www.youtube.com/watch?v=QVdBPvOOjBA is also a pretty neat talk about derivatives of regexes
2022-10-04 04:19:40 +0200 <jackdk> https://blog.jle.im/entry/free-alternative-regexp.html is also a really clever take on a regex engine using free structure
2022-10-04 04:20:54 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 265 seconds)
2022-10-04 04:21:14 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-10-04 04:21:27 +0200_xor(~xor@74.215.182.83)
2022-10-04 04:22:03 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 04:22:33 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Client Quit)
2022-10-04 04:23:29 +0200edrx(~Eduardo@2804:56c:d2d3:4800:cf7d:b421:4c3a:392e) (Killed buffer)
2022-10-04 04:34:46 +0200nate4(~nate@98.45.169.16) (Read error: Connection reset by peer)
2022-10-04 04:34:48 +0200nate1(~nate@98.45.169.16)
2022-10-04 04:34:56 +0200azimut_(~azimut@gateway/tor-sasl/azimut)
2022-10-04 04:35:24 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds)
2022-10-04 04:41:59 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-10-04 04:45:20 +0200jargon(~jargon@174-22-199-121.phnx.qwest.net) (Read error: Connection reset by peer)
2022-10-04 04:46:33 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 04:47:46 +0200jargon(~jargon@174-22-201-96.phnx.qwest.net)
2022-10-04 04:47:50 +0200dr_merijn(~dr_merijn@86.86.29.250)
2022-10-04 04:48:17 +0200lottaquestions(~nick@2607:fa49:503e:7100:79b4:8afd:9b25:f433) (Quit: Konversation terminated!)
2022-10-04 04:49:07 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 248 seconds)
2022-10-04 04:54:44 +0200nate1(~nate@98.45.169.16) (Ping timeout: 265 seconds)
2022-10-04 04:55:15 +0200jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection)
2022-10-04 04:57:59 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com)
2022-10-04 04:58:00 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host)
2022-10-04 04:58:00 +0200wroathe(~wroathe@user/wroathe)
2022-10-04 04:58:24 +0200img(~img@user/img)
2022-10-04 05:02:43 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com)
2022-10-04 05:03:14 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds)
2022-10-04 05:03:22 +0200lys(lys@id-194105.uxbridge.irccloud.com)
2022-10-04 05:04:24 +0200azimut_(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-10-04 05:04:39 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-04 05:08:45 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds)
2022-10-04 05:09:50 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2022-10-04 05:10:17 +0200LukeHoersten(~LukeHoers@user/lukehoersten)
2022-10-04 05:10:57 +0200LukeHoersten(~LukeHoers@user/lukehoersten) (Client Quit)
2022-10-04 05:11:58 +0200nate1(~nate@98.45.169.16)
2022-10-04 05:11:58 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-04 05:20:00 +0200lys(lys@id-194105.uxbridge.irccloud.com) (Quit: bbl)
2022-10-04 05:20:49 +0200zebrag(~chris@user/zebrag) (Quit: Konversation terminated!)
2022-10-04 05:24:05 +0200twb(~twb@2403:5804:c6::add)
2022-10-04 05:24:32 +0200 <twb> Is there a better place to ask about gitit issues?
2022-10-04 05:25:43 +0200 <twb> I keep getting bursts of "withFd: resource vanished (Broken pipe)" for the static css/js files gitit is serving out, and they're not obviously connected to the actual files ACTUALLY disappearing
2022-10-04 05:26:04 +0200 <twb> And also a few "Network.Socket.sendBuf: resource vanished (Broken pipe)"
2022-10-04 05:26:49 +0200lys(lys@id-194105.uxbridge.irccloud.com)
2022-10-04 05:27:16 +0200 <twb> I'm not sure where to start debugging this. It might be due to systemd-level hardening I've added, if e.g. happstack is doing something weird internally (but e.g. AF_NETLINK is still allowed)
2022-10-04 05:28:13 +0200nate1(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-10-04 05:29:49 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-10-04 05:32:16 +0200justsomeguy(~justsomeg@47.201.160.8)
2022-10-04 05:32:20 +0200justsomeguy(~justsomeg@47.201.160.8) (Client Quit)
2022-10-04 05:32:34 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-10-04 05:32:45 +0200img(~img@user/img)
2022-10-04 05:33:46 +0200 <twb> https://paste.debian.net/1255894/ errors https://paste.debian.net/1255892/ gitit.conf https://paste.debian.net/1255893/ gitit.service http://ix.io/4ceF systemd-analyze security gitit
2022-10-04 05:34:55 +0200waleee(~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 246 seconds)
2022-10-04 05:37:16 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 265 seconds)
2022-10-04 05:38:47 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2022-10-04 05:38:59 +0200caryhartline(~caryhartl@2600:1700:2d0:8d30:c9ff:16c0:a456:ab01)
2022-10-04 05:46:25 +0200Vajb(~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) (Read error: Connection reset by peer)
2022-10-04 05:47:33 +0200Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi)
2022-10-04 05:51:58 +0200jargon(~jargon@174-22-201-96.phnx.qwest.net) (Remote host closed the connection)
2022-10-04 05:52:27 +0200 <Axman6> twb: I would've thought those were networking errors, not file errors
2022-10-04 05:56:22 +0200 <Axman6> hmm, maybe not
2022-10-04 05:56:58 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 246 seconds)
2022-10-04 05:57:16 +0200 <twb> FWIW the static files are on the same host as gitit, although they might have to transit a linux kernel bind mount
2022-10-04 05:57:37 +0200 <twb> i.e. I don't *think* there's anything like transient NFS outages involves
2022-10-04 05:57:40 +0200 <twb> *involved
2022-10-04 06:02:10 +0200jargon(~jargon@174-22-201-96.phnx.qwest.net)
2022-10-04 06:11:57 +0200nate1(~nate@98.45.169.16)
2022-10-04 06:17:09 +0200nate1(~nate@98.45.169.16) (Ping timeout: 250 seconds)
2022-10-04 06:21:06 +0200justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds)
2022-10-04 06:24:38 +0200zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2022-10-04 06:25:39 +0200zaquest(~notzaques@5.130.79.72)
2022-10-04 06:29:49 +0200jespada(~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Ping timeout: 252 seconds)
2022-10-04 06:31:42 +0200jespada(~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net)
2022-10-04 06:32:32 +0200jargon(~jargon@174-22-201-96.phnx.qwest.net) (Remote host closed the connection)
2022-10-04 06:33:32 +0200Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer)
2022-10-04 06:33:51 +0200Null_A(~null_a@c-73-93-244-42.hsd1.ca.comcast.net)
2022-10-04 06:34:12 +0200Vajb(~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57)
2022-10-04 06:37:45 +0200relrod(~relrod@redhat/ansible.staff.relrod) (Quit: .)
2022-10-04 06:39:40 +0200vglfr(~vglfr@145.224.100.164) (Ping timeout: 246 seconds)
2022-10-04 06:39:41 +0200Null_A(~null_a@c-73-93-244-42.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
2022-10-04 06:40:10 +0200Null_A(~null_a@c-73-93-244-42.hsd1.ca.comcast.net)
2022-10-04 06:40:25 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 06:44:40 +0200causal(~user@50.35.83.177) (Quit: WeeChat 3.6)
2022-10-04 06:49:15 +0200razetime(~quassel@117.254.35.18)
2022-10-04 07:03:25 +0200 <Axman6> maybe strace can tell you something useful?
2022-10-04 07:03:39 +0200 <twb> Good thinking
2022-10-04 07:04:14 +0200 <twb> I straced it while it was idle (for a different reason) and there nothing except a single "waiting for next query"
2022-10-04 07:07:10 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 07:11:58 +0200chomwitt(~chomwitt@2a02:587:dc14:f500:e5cf:fac1:d8f4:9053)
2022-10-04 07:13:40 +0200nate1(~nate@98.45.169.16)
2022-10-04 07:15:24 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 07:16:29 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 07:19:28 +0200lys(lys@id-194105.uxbridge.irccloud.com) (Quit: To the moon and back)
2022-10-04 07:20:13 +0200nate1(~nate@98.45.169.16) (Ping timeout: 265 seconds)
2022-10-04 07:21:51 +0200rekahsoft(~rekahsoft@142.189.68.220)
2022-10-04 07:21:53 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds)
2022-10-04 07:22:28 +0200danso(~danso@danso.ca) (Quit: ZNC - https://znc.in)
2022-10-04 07:25:07 +0200danso(~danso@danso.ca)
2022-10-04 07:27:36 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2022-10-04 07:29:39 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2022-10-04 07:44:12 +0200lys(lys@id-194105.uxbridge.irccloud.com)
2022-10-04 07:46:40 +0200nate1(~nate@98.45.169.16)
2022-10-04 07:48:35 +0200coot(~coot@213.134.171.3)
2022-10-04 07:50:33 +0200 <sm> anything in their issue tracker ? if not might be worth reporting
2022-10-04 07:50:46 +0200 <twb> Not that I could see
2022-10-04 07:51:19 +0200 <twb> I was hoping to solve it myself before reporting :-)
2022-10-04 07:51:38 +0200nate1(~nate@98.45.169.16) (Ping timeout: 265 seconds)
2022-10-04 07:52:07 +0200rekahsoft(~rekahsoft@142.189.68.220) (Remote host closed the connection)
2022-10-04 07:54:18 +0200rekahsoft(~rekahsoft@142.189.68.220)
2022-10-04 07:59:32 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2022-10-04 07:59:58 +0200rekahsoft(~rekahsoft@142.189.68.220) (Remote host closed the connection)
2022-10-04 08:00:31 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-10-04 08:01:01 +0200acidjnk_new(~acidjnk@p200300d6e7137a36edbbd7fd5b13d5e1.dip0.t-ipconnect.de)
2022-10-04 08:02:09 +0200rekahsoft(~rekahsoft@142.189.68.220)
2022-10-04 08:02:19 +0200k8yun_(~k8yun@user/k8yun) (Quit: Leaving)
2022-10-04 08:06:39 +0200kenran(~user@user/kenran)
2022-10-04 08:10:11 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-10-04 08:13:51 +0200rekahsoft(~rekahsoft@142.189.68.220) (Ping timeout: 268 seconds)
2022-10-04 08:14:16 +0200acidjnk_new(~acidjnk@p200300d6e7137a36edbbd7fd5b13d5e1.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-10-04 08:15:44 +0200chomwitt(~chomwitt@2a02:587:dc14:f500:e5cf:fac1:d8f4:9053) (Ping timeout: 268 seconds)
2022-10-04 08:21:37 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2022-10-04 08:24:01 +0200razetime(~quassel@117.254.35.18) (Ping timeout: 265 seconds)
2022-10-04 08:24:30 +0200razetime(~quassel@2401:4900:6298:84d:81f1:d694:dea5:362c)
2022-10-04 08:27:07 +0200dr_merijn(~dr_merijn@86.86.29.250) (Ping timeout: 246 seconds)
2022-10-04 08:28:20 +0200lys(lys@id-194105.uxbridge.irccloud.com) (Quit: ZzzZzz)
2022-10-04 08:28:21 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-04 08:30:18 +0200shriekingnoise(~shrieking@186.137.167.202) (Quit: Quit)
2022-10-04 08:32:21 +0200razetime(~quassel@2401:4900:6298:84d:81f1:d694:dea5:362c) (Ping timeout: 260 seconds)
2022-10-04 08:34:00 +0200darkstardevx(~darkstard@192.183.207.94) (Ping timeout: 264 seconds)
2022-10-04 08:38:17 +0200Null_A(~null_a@c-73-93-244-42.hsd1.ca.comcast.net) ()
2022-10-04 08:40:56 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-10-04 08:46:06 +0200ellensol(~ellen@ua-84-216-129-63.bbcust.telenor.se)
2022-10-04 08:49:07 +0200ellensol(~ellen@ua-84-216-129-63.bbcust.telenor.se) (Read error: Connection reset by peer)
2022-10-04 08:49:25 +0200michalz(~michalz@185.246.207.197)
2022-10-04 08:50:33 +0200BB[m](~cashmagem@2001:470:69fc:105::f6dc)
2022-10-04 08:53:50 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net)
2022-10-04 08:55:06 +0200MajorBiscuit(~MajorBisc@c-001-001-038.client.tudelft.eduvpn.nl)
2022-10-04 08:56:11 +0200chomwitt(~chomwitt@2a02:587:dc14:f500:4d9:c26a:402f:bdab)
2022-10-04 08:56:26 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:cbb9:efc2:3629:a341)
2022-10-04 08:58:18 +0200codaraxis___(~codaraxis@user/codaraxis)
2022-10-04 09:03:11 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 268 seconds)
2022-10-04 09:17:50 +0200mbuf(~Shakthi@49.204.133.164)
2022-10-04 09:17:56 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 09:19:49 +0200kenran(~user@user/kenran) (Remote host closed the connection)
2022-10-04 09:21:39 +0200kenran(~user@user/kenran)
2022-10-04 09:27:01 +0200troydm(~troydm@176.37.124.197) (Ping timeout: 244 seconds)
2022-10-04 09:27:45 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com)
2022-10-04 09:28:42 +0200nschoe(~quassel@2a01:e0a:8e:a190:824d:1eb5:b8c7:3d88)
2022-10-04 09:32:26 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds)
2022-10-04 09:40:03 +0200troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-10-04 09:43:45 +0200acidjnk_new(~acidjnk@p200300d6e7137a36b404354f0b8552f0.dip0.t-ipconnect.de)
2022-10-04 09:46:25 +0200romes[m]uploaded an image: (293KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/LeJhtBnxPwUVcicxsKtmUooK/image.png >
2022-10-04 09:46:32 +0200 <romes[m]> my girlfriend made me this meme :)
2022-10-04 09:47:54 +0200mmhat(~mmh@p200300f1c700bd12ee086bfffe095315.dip0.t-ipconnect.de)
2022-10-04 09:48:37 +0200RobertKrook(~robert@ext-1-087.eduroam.chalmers.se)
2022-10-04 09:48:51 +0200mmhat(~mmh@p200300f1c700bd12ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2022-10-04 09:48:57 +0200 <dminuoso> romes[m]: I think that meme could be improved by replacing that remark with "Did you know a Monad is just a Monoid in the category of endofunctors"
2022-10-04 09:50:00 +0200 <romes[m]> ahaha although I don't try to explain that to her, I have done the monoid talk quite often with my friends ahaha :)
2022-10-04 09:50:38 +0200 <romes[m]> but feel free to do that!
2022-10-04 09:51:01 +0200m5zs7k(aquares@web10.mydevil.net) (Ping timeout: 265 seconds)
2022-10-04 09:51:49 +0200_xor(~xor@74.215.182.83) (Quit: brb)
2022-10-04 09:52:17 +0200fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7)
2022-10-04 09:53:41 +0200m5zs7k(aquares@web10.mydevil.net)
2022-10-04 09:56:24 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-10-04 09:58:43 +0200 <twb> "Honey, I think we have to have... The Talk with the kids"
2022-10-04 10:00:08 +0200razetime(~quassel@117.254.35.128)
2022-10-04 10:00:43 +0200 <ski> @quote sarah.peyton
2022-10-04 10:00:44 +0200 <lambdabot> sarah says: "But I don't _want_ functional programming!" -- Sarah Peyton Jones, age 11, upon hearing the rules of Go
2022-10-04 10:01:14 +0200 <ski> @quote please.talk
2022-10-04 10:01:14 +0200 <lambdabot> Dave_Benjamin says: please talk to your son or daughter about parametric polymorphism
2022-10-04 10:02:40 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 246 seconds)
2022-10-04 10:02:46 +0200 <twb> ski: "Google Security Team recommends parents name their child's first pet using at least one codepoint outside the Basic Multilingual Plane"
2022-10-04 10:02:47 +0200rnat(uid73555@id-73555.lymington.irccloud.com)
2022-10-04 10:02:48 +0200dwt_(~dwt_@c-98-198-103-176.hsd1.tx.comcast.net) (Ping timeout: 264 seconds)
2022-10-04 10:02:58 +0200mncheck(~mncheck@193.224.205.254)
2022-10-04 10:03:50 +0200 <ski> hehe :)
2022-10-04 10:05:10 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 10:06:29 +0200rnat(uid73555@id-73555.lymington.irccloud.com) ()
2022-10-04 10:06:44 +0200rnat(uid73555@id-73555.lymington.irccloud.com)
2022-10-04 10:10:07 +0200__monty__(~toonn@user/toonn)
2022-10-04 10:11:05 +0200lys(lys@id-194105.uxbridge.irccloud.com)
2022-10-04 10:13:23 +0200cheater(~Username@user/cheater) (Ping timeout: 248 seconds)
2022-10-04 10:14:20 +0200rnat(uid73555@id-73555.lymington.irccloud.com) ()
2022-10-04 10:14:40 +0200rnat(uid73555@id-73555.lymington.irccloud.com)
2022-10-04 10:15:42 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 10:15:55 +0200RobertKrook(~robert@ext-1-087.eduroam.chalmers.se) (Quit: Lost terminal)
2022-10-04 10:16:21 +0200 <romes[m]> Ahahahahah
2022-10-04 10:22:54 +0200cheater(~Username@user/cheater)
2022-10-04 10:23:32 +0200cfricke(~cfricke@user/cfricke)
2022-10-04 10:24:57 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2022-10-04 10:26:48 +0200wonko(~wjc@2a0e:1c80:11::50)
2022-10-04 10:33:15 +0200ellensol(~ellen@emp-85-192.eduroam.uu.se)
2022-10-04 10:33:16 +0200 <phma> I have this code: seq (par (n `divMod` 2) (n `divMod` 3)) $ (long calculation that uses (n `divMod` 2) or (n `divMod` 3) but not both).
2022-10-04 10:33:55 +0200 <phma> Will it always compute both (n `divMod` 2) and (n `divMod` 3), or do I have to use seq instead of par?
2022-10-04 10:36:23 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65)
2022-10-04 10:37:25 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 10:37:35 +0200ellensol(~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 250 seconds)
2022-10-04 10:38:27 +0200lysrosalind
2022-10-04 10:39:26 +0200vegetabelfodos(~vegetabel@user/vegetabelfodos)
2022-10-04 10:39:45 +0200 <c_wraith> phma: I can't imagine divMod being slow enough that doing two of them in parallel is worth the overhead, unless you're in cryptographically-sized Integers
2022-10-04 10:41:02 +0200 <c_wraith> phma: but also, that code is kind of... not using par correctly. or seq.
2022-10-04 10:41:19 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 10:42:53 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-10-04 10:42:55 +0200 <phma> They are cryptographically sized integers, and the reason I need to compute both is to prevent Eve from finding which one I'm using.
2022-10-04 10:42:57 +0200razetime(~quassel@117.254.35.128) (Remote host closed the connection)
2022-10-04 10:43:13 +0200 <c_wraith> phma: first off, when using par, you really should be using pseq instead of seq. pseq enforces ordering, seq does not
2022-10-04 10:44:03 +0200 <phma> ordering of what?
2022-10-04 10:44:07 +0200 <twb> Is this for pedagogy, or production? For production I *strongly* recommend using a standard crypto library rather than DIY
2022-10-04 10:44:36 +0200 <c_wraith> pseq a b implies a will be evaluated, then b. seq a b implies a and b will both be evaluated.
2022-10-04 10:44:56 +0200 <dminuoso> Though for what its worth, even GHC internally uses `seq` in plenty of places where they should use `pseq` instead.
2022-10-04 10:45:33 +0200 <dminuoso> Probably to the point that `seq` could never do parallel evaluation, given that this would just create a lot of breakage
2022-10-04 10:45:50 +0200 <c_wraith> next up, you shouldn't be hoping for CSE to make par/pseq work correctly. Explicitly share values you want to be shared.
2022-10-04 10:46:04 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 246 seconds)
2022-10-04 10:46:15 +0200 <c_wraith> dminuoso: it's less about parallel and more that seq a b can decide to evaluate b first.
2022-10-04 10:46:21 +0200 <phma> CSE?
2022-10-04 10:46:28 +0200 <c_wraith> common subexpression elimination
2022-10-04 10:46:33 +0200 <phma> ah
2022-10-04 10:46:35 +0200nate1(~nate@98.45.169.16)
2022-10-04 10:46:38 +0200 <dminuoso> Also, if you want guaranteed sharing, use {-# NOINLINE foo #-}
2022-10-04 10:46:45 +0200 <dminuoso> Otherwise you are at the mercy of the simplifier
2022-10-04 10:46:47 +0200 <twb> In case people are missing context: c_wraith wants to guarantee some needless computation is performed, to mitigate power/timing analysis attacks
2022-10-04 10:46:59 +0200 <c_wraith> I don't. phma does. :P
2022-10-04 10:47:07 +0200 <twb> Oh sorry.
2022-10-04 10:47:18 +0200 <twb> https://en.wikipedia.org/wiki/Side-channel_attack
2022-10-04 10:47:43 +0200 <dminuoso> twb: phma has been discussion cryptography on and off for a while and they appear to be a student.
2022-10-04 10:47:59 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection)
2022-10-04 10:48:12 +0200 <twb> Righto
2022-10-04 10:48:16 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-10-04 10:49:09 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 10:50:25 +0200kuribas(~user@ptr-17d51emyfmo4vkmz9ge.18120a2.ip6.access.telenet.be)
2022-10-04 10:50:36 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 260 seconds)
2022-10-04 10:51:15 +0200nate1(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-10-04 10:52:16 +0200 <phma> twb: this isn't for production, this is for figuring out if it's possible to defeat a side-channel attack in Haskell, despite the simplifier
2022-10-04 10:52:41 +0200ellensol(~ellen@emp-85-192.eduroam.uu.se)
2022-10-04 10:53:25 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 246 seconds)
2022-10-04 10:54:51 +0200 <twb> Could you simply have another green thread that generates and throws away computation at random?
2022-10-04 10:55:03 +0200 <twb> I guess that would help with power but not timing
2022-10-04 10:57:32 +0200 <phma> This is in the code that makes the ladder; from an answer I got on Stack Exchange, I realized that Eve could easily see what the ladder is, which defeats the purpose.
2022-10-04 10:58:00 +0200 <phma> The code that climbs the ladder should take a lot longer than the code that makes the ladder.
2022-10-04 10:58:47 +0200 <phma> When it's actually encrypting something, that is. In the unit test, the operation is integer addition.
2022-10-04 11:04:24 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-10-04 11:05:48 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 11:05:50 +0200Hidlegunst(~Hidleguns@fw-pmc.sorbonne-universite.fr)
2022-10-04 11:07:15 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-04 11:08:29 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65)
2022-10-04 11:09:15 +0200 <dminuoso> phma: before defeating a side channel, you should perhaps start by demonstrating a side channel to begin with.
2022-10-04 11:09:29 +0200burnsidesLlama(~burnsides@client-8-89.eduroam.oxuni.org.uk)
2022-10-04 11:09:55 +0200 <dminuoso> If you recall my previous remarks, that's precisely the problem. It has not even been demonstrated either way.
2022-10-04 11:10:36 +0200 <dminuoso> If you can find side channel attacks that, perhaps, relate to either the semantics of the language or the artifacts of the simplifier, you would perhaps identify the exact causes - its only then when you can start looking into mitigation techniques
2022-10-04 11:10:50 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 268 seconds)
2022-10-04 11:11:13 +0200 <dminuoso> If you want to improve your impact factor, you can even aim for publishable research.
2022-10-04 11:11:16 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 11:12:59 +0200rosalindlys
2022-10-04 11:13:20 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds)
2022-10-04 11:13:41 +0200lys(lys@id-194105.uxbridge.irccloud.com) ()
2022-10-04 11:15:46 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de)
2022-10-04 11:16:03 +0200vglfr(~vglfr@145.224.100.164) (Read error: Connection reset by peer)
2022-10-04 11:16:15 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 11:20:35 +0200ellensol(~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 252 seconds)
2022-10-04 11:30:07 +0200 <phma> I'm planning to demonstrate a side channel; I'll have to implement point addition in pure Haskell (unless someone's done it already), pass it to my code, and instrument it somehow.
2022-10-04 11:30:38 +0200ellensol_(~ellen@emp-85-192.eduroam.uu.se)
2022-10-04 11:30:44 +0200ft(~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: leaving)
2022-10-04 11:33:37 +0200gmg(~user@user/gehmehgeh)
2022-10-04 11:38:00 +0200DavidBinder(~DavidBind@134.2.10.18)
2022-10-04 11:38:39 +0200ellensol_(~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 268 seconds)
2022-10-04 11:38:55 +0200vglfr(~vglfr@145.224.100.164) (Ping timeout: 246 seconds)
2022-10-04 11:39:57 +0200CiaoSen(~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-10-04 11:41:08 +0200ellensol(~ellen@emp-85-192.eduroam.uu.se)
2022-10-04 11:41:39 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 11:43:23 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042)
2022-10-04 11:46:11 +0200vglfr(~vglfr@145.224.100.164) (Read error: Connection reset by peer)
2022-10-04 11:46:30 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 11:48:23 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 268 seconds)
2022-10-04 11:54:35 +0200vglfr(~vglfr@145.224.100.164) (Read error: Connection reset by peer)
2022-10-04 11:55:43 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:cbb9:efc2:3629:a341) (Ping timeout: 246 seconds)
2022-10-04 11:55:58 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 11:59:08 +0200ellensol(~ellen@emp-85-192.eduroam.uu.se) (Quit: leaving)
2022-10-04 12:00:15 +0200vglfr(~vglfr@145.224.100.164) (Read error: Connection reset by peer)
2022-10-04 12:00:26 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 12:01:02 +0200dr_merijn(~dr_merijn@86.86.29.250)
2022-10-04 12:04:28 +0200vglfr(~vglfr@145.224.100.164) (Ping timeout: 246 seconds)
2022-10-04 12:05:40 +0200Hidlegunst(~Hidleguns@fw-pmc.sorbonne-universite.fr) (Quit: nyaa~)
2022-10-04 12:11:28 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 246 seconds)
2022-10-04 12:12:43 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 12:14:01 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds)
2022-10-04 12:15:10 +0200 <probie> Is there a way to silence a single "redundant constraint" warning, when the constraint isn't really redundant?
2022-10-04 12:16:03 +0200vglfr(~vglfr@145.224.100.164) (Read error: Connection reset by peer)
2022-10-04 12:16:04 +0200 <geekosaur> not presently
2022-10-04 12:16:39 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 12:16:48 +0200 <probie> I've got something like `(F xs ~ Just '(ls, x, rs), xs ~ (ls ++ (x ': rs)))` and it thinks `F xs ~ Just '(ls, x ,rs)` is redundant, but it's genuinely needed
2022-10-04 12:17:28 +0200 <probie> (where `F :: [Type] -> Maybe ([Type], Type, [Type])`)
2022-10-04 12:19:33 +0200DavidBinder(~DavidBind@134.2.10.18) (Remote host closed the connection)
2022-10-04 12:20:22 +0200kdaishi(~Thunderbi@dyn3137-209.wlan.ic.ac.uk)
2022-10-04 12:21:20 +0200vglfr(~vglfr@145.224.100.164) (Ping timeout: 265 seconds)
2022-10-04 12:24:46 +0200kdaishi(~Thunderbi@dyn3137-209.wlan.ic.ac.uk) (Ping timeout: 268 seconds)
2022-10-04 12:26:18 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 12:31:00 +0200twb(~twb@2403:5804:c6::add) (Ping timeout: 264 seconds)
2022-10-04 12:31:22 +0200ubert(~Thunderbi@91.141.46.118.wireless.dyn.drei.com)
2022-10-04 12:31:58 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 12:32:06 +0200cfricke(~cfricke@user/cfricke) (Ping timeout: 260 seconds)
2022-10-04 12:33:01 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-10-04 12:33:16 +0200 <dminuoso> probie: Localized control over diagnostics has been a topic for over 10 years. Instead of the pragmatic "lets address 99% of the problems" some voices wanted a wholesome solution to cover the rest 1% to avoid backwards compatibilty breaking changes down the way
2022-10-04 12:33:23 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2022-10-04 12:33:33 +0200 <dminuoso> And the mission was successful. No feature was implemented that, in the future, is going to be broken.
2022-10-04 12:34:02 +0200 <dminuoso> (But honestly I think that issue is just forgotten now)
2022-10-04 12:34:07 +0200ubert(~Thunderbi@91.141.46.118.wireless.dyn.drei.com) (Remote host closed the connection)
2022-10-04 12:34:44 +0200 <geekosaur> I'm under the impression it's still there but subsumed by a more complete error/warning overhaul that has in fact begun
2022-10-04 12:35:04 +0200 <dminuoso> Oh it was 18 years old.
2022-10-04 12:35:16 +0200 <probie> I'd also settle for making the constraint not redundant. Maybe I can do something silly like sneak it into a where
2022-10-04 12:35:21 +0200 <dminuoso> https://gitlab.haskell.org/ghc/ghc/-/issues/602
2022-10-04 12:35:30 +0200 <geekosaur> (option for JSON output instead of text, message numbers to facilitate documentation, etc.)
2022-10-04 12:35:31 +0200 <dminuoso> (There's a whole bunch of related issues, but this is the original core issue)
2022-10-04 12:37:16 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-04 12:37:19 +0200twb(~twb@2403:5804:c6::add)
2022-10-04 12:39:01 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 12:40:51 +0200CiaoSen(~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-10-04 12:43:02 +0200CiaoSen(~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-10-04 12:43:34 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 12:45:48 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65)
2022-10-04 12:54:07 +0200beteigeuze(~Thunderbi@89.187.168.45)
2022-10-04 12:55:32 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 13:01:00 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 264 seconds)
2022-10-04 13:03:14 +0200burnsidesLlama(~burnsides@client-8-89.eduroam.oxuni.org.uk) (Remote host closed the connection)
2022-10-04 13:04:31 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net)
2022-10-04 13:04:37 +0200vglfr(~vglfr@145.224.100.164)
2022-10-04 13:08:35 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de) (Quit: Leaving.)
2022-10-04 13:09:02 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 13:10:34 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2022-10-04 13:14:09 +0200__monty__(~toonn@user/toonn)
2022-10-04 13:14:27 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 250 seconds)
2022-10-04 13:17:27 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.)
2022-10-04 13:19:34 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-10-04 13:19:40 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-10-04 13:24:16 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 13:26:26 +0200vglfr(~vglfr@145.224.100.164) (Ping timeout: 268 seconds)
2022-10-04 13:27:53 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 13:28:35 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 248 seconds)
2022-10-04 13:32:04 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2022-10-04 13:32:26 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2022-10-04 13:36:09 +0200img(~img@user/img)
2022-10-04 13:38:06 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com)
2022-10-04 13:38:56 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:6f76:5354:52c9:73a2)
2022-10-04 13:39:36 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds)
2022-10-04 13:41:52 +0200 <dminuoso> Is there a variant of binary/cereal with more error control? In particular I want to parse really small chunks (somewhere around 6-20 bytes mostly), but I dont want an individual parse failures to fail the entire parser.
2022-10-04 13:42:15 +0200 <dminuoso> And running `runGet` for each small chunk seems like overkill
2022-10-04 13:43:14 +0200 <Hecate> dminuoso: and then what? why don't you also ask for meaningful error messages while you're at it? :P
2022-10-04 13:43:42 +0200 <dminuoso> Error messages are under my full control already anyway
2022-10-04 13:44:09 +0200 <dminuoso> All the useful diagnostics are not on the protocol decoding level, but higher (like "Attribute XYZ not known")
2022-10-04 13:44:35 +0200 <Hecate> dminuoso: who Attoparsec be more appropriate in your usecase?
2022-10-04 13:45:26 +0200vglfr(~vglfr@145.224.100.190)
2022-10-04 13:45:30 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042)
2022-10-04 13:46:04 +0200 <dminuoso> I thought about it, but it its a poor match. This is a low level binary protocol.
2022-10-04 13:46:13 +0200 <dminuoso> The only advantage attoparsec has for me, is being able to use `optional` with it
2022-10-04 13:46:25 +0200 <dminuoso> Oh huh wow hold on.
2022-10-04 13:46:31 +0200 <dminuoso> Get has Alternative/MonadPlus too
2022-10-04 13:46:40 +0200 <Hecate> ;-D
2022-10-04 13:46:43 +0200 <dminuoso> Then attoparsec has no advantage.
2022-10-04 13:46:47 +0200 <Hecate> ok
2022-10-04 13:48:44 +0200 <dminuoso> Maybe Ill just put `ExceptT DecodeError` ontop of Get, and carefully avoid using primitives that may `fail` the parser.
2022-10-04 13:48:51 +0200 <dminuoso> mmm
2022-10-04 13:49:59 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 250 seconds)
2022-10-04 13:52:05 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2022-10-04 13:54:37 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 13:56:22 +0200lyle(~lyle@104.246.145.85)
2022-10-04 13:56:36 +0200pavonia(~user@user/siracusa)
2022-10-04 13:56:57 +0200 <raehik> dminuoso: It's a stretch but my pkg binrep is built on flatparse so is nice and fast?
2022-10-04 13:57:24 +0200wonko(~wjc@2a0e:1c80:11::50) (Ping timeout: 264 seconds)
2022-10-04 13:57:26 +0200 <raehik> Problem being, there is very little error handling, and flatparse makes you do it yourself
2022-10-04 13:58:05 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 14:02:22 +0200 <raehik> Actually reading your msgs, I think you would appreciate flatparse's error model. Parse failures are split into recoverable and non-recoverable
2022-10-04 14:02:50 +0200 <Hecate> https://flora.pm/packages/@hackage/binrep nice indeed!
2022-10-04 14:03:33 +0200 <dminuoso> raehik: Okay so thats interesting. It doesnt address the problem I have right now really, but it does solve issues I have with binary/cereal.
2022-10-04 14:03:56 +0200 <dminuoso> I *was* looking for a strict bytestring alternative without that internal streamingmechanism
2022-10-04 14:04:17 +0200 <dminuoso> newtype Parser e a = Parser {runParser# :: ForeignPtrContents -> Addr# -> Addr# -> Res# e a}
2022-10-04 14:04:19 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-10-04 14:04:23 +0200 <dminuoso> I was on the brink of constructing this myself.
2022-10-04 14:04:36 +0200 <dminuoso> Yes this is lovely. :)\
2022-10-04 14:04:36 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 264 seconds)
2022-10-04 14:05:06 +0200 <raehik> it's a wonderful pkg from András Kovács and I wish it was used more!
2022-10-04 14:05:16 +0200 <dminuoso> raehik: No actually, *this* solves my problems
2022-10-04 14:05:30 +0200 <dminuoso> This parser is so evidently absurdly cheap, that I can just takeBs and re-run a nested Parser
2022-10-04 14:05:36 +0200yaroot(~yaroot@p2790051-ipngn7801souka.saitama.ocn.ne.jp) (Remote host closed the connection)
2022-10-04 14:05:40 +0200 <dminuoso> There wont even be a copy of the bytestring.
2022-10-04 14:06:05 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 14:06:09 +0200yaroot(~yaroot@p2790051-ipngn7801souka.saitama.ocn.ne.jp)
2022-10-04 14:06:25 +0200 <raehik> yeah :D
2022-10-04 14:07:17 +0200 <dminuoso> Well even with binary there likely wont be, but there's a bunch of additional internal checks because of that streaming mechanism
2022-10-04 14:07:23 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de)
2022-10-04 14:07:48 +0200 <dminuoso> Recoverable failure, non-recovereable failure. It has all.
2022-10-04 14:07:51 +0200 <dminuoso> Thank you raehik!
2022-10-04 14:08:23 +0200 <dminuoso> Now I just neet a flatpack put equivalent. :p
2022-10-04 14:08:25 +0200 <raehik> I'm very glad to help!!
2022-10-04 14:08:50 +0200 <dminuoso> Or do you happen to know a Put equivalent of flatparse?
2022-10-04 14:08:52 +0200 <raehik> dminuoso: you mean a serializer? haha https://hackage.haskell.org/package/mason
2022-10-04 14:09:15 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds)
2022-10-04 14:09:27 +0200 <dminuoso> Not quite, like flatparse I know ahead of time the size of the chunk (or at least I have good upper bounds)
2022-10-04 14:09:30 +0200 <raehik> I investigated this stuff a year or so back -- mason seems to win or tie at serialization performance with the other libs
2022-10-04 14:10:38 +0200 <dminuoso> Though mmm. mason *does* have a constant buffer mechanism
2022-10-04 14:12:11 +0200 <raehik> I'm not too sure what you're looking for, but mason lets you throw the bytestring lib primitives at it
2022-10-04 14:13:06 +0200 <raehik> If you know how long something is you can do something like this https://github.com/raehik/binrep/blob/d7b7b0c7c3e0bebbba49701db530b98ac0b154c5/src/Binrep/Type/Byt…
2022-10-04 14:13:46 +0200 <raehik> similarly, there is Mason.Builder.primBounded for BoundedPrim
2022-10-04 14:14:45 +0200 <dminuoso> Yeah I think this might fit the bill.
2022-10-04 14:15:49 +0200 <dminuoso> utting :: Parser e a -> e -> (e -> e -> e) -> Parser e a
2022-10-04 14:15:58 +0200 <dminuoso> Oh yeah, flatparse is definitely exactly what I want.
2022-10-04 14:17:24 +0200 <raehik> It would be nice to have a replacement to binary/cereal that uses these libs instead. my binrep is a start, but doesn't want to define serializations for Haskell types
2022-10-04 14:18:01 +0200 <raehik> "nice" as in lots of speed and a simplified lib I suppose
2022-10-04 14:22:43 +0200dr_merijn(~dr_merijn@86.86.29.250) (Ping timeout: 246 seconds)
2022-10-04 14:24:35 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 14:26:15 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2022-10-04 14:26:43 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 14:26:43 +0200 <dminuoso> But for putting, I think I will eventually just write my own version of Put
2022-10-04 14:26:52 +0200 <dminuoso> While mason is certainly nice, it has too much baggage I really dont care for
2022-10-04 14:28:20 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65)
2022-10-04 14:31:29 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 258 seconds)
2022-10-04 14:35:27 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2022-10-04 14:36:32 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 14:39:05 +0200enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7)
2022-10-04 14:39:20 +0200kdaishi(~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds)
2022-10-04 14:41:14 +0200rnat(uid73555@id-73555.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-04 14:41:30 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 14:46:26 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds)
2022-10-04 14:48:06 +0200nate1(~nate@98.45.169.16)
2022-10-04 14:48:40 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-04 14:52:57 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 14:53:06 +0200nate1(~nate@98.45.169.16) (Ping timeout: 265 seconds)
2022-10-04 15:04:00 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net)
2022-10-04 15:05:51 +0200zebrag(~chris@user/zebrag)
2022-10-04 15:08:26 +0200_73(~user@2600:4040:5aa2:2000:ccdd:de39:6c57:78f9) (Remote host closed the connection)
2022-10-04 15:08:35 +0200_73(~user@pool-173-76-236-42.bstnma.fios.verizon.net)
2022-10-04 15:10:32 +0200frost(~frost@user/frost) (Ping timeout: 252 seconds)
2022-10-04 15:10:43 +0200doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com)
2022-10-04 15:11:48 +0200vegetabelfodosbillcosby
2022-10-04 15:14:34 +0200stackdroid18(~stackdroi@user/stackdroid)
2022-10-04 15:15:29 +0200billcosby(~vegetabel@user/vegetabelfodos) (Quit: quit)
2022-10-04 15:17:42 +0200stiell_(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2022-10-04 15:18:22 +0200cyphase(~cyphase@user/cyphase) (Ping timeout: 246 seconds)
2022-10-04 15:18:40 +0200stiell_(~stiell@gateway/tor-sasl/stiell)
2022-10-04 15:19:18 +0200acidjnk_new(~acidjnk@p200300d6e7137a36b404354f0b8552f0.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2022-10-04 15:20:01 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2022-10-04 15:20:41 +0200dontdieych(~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-04 15:21:14 +0200dontdieych(~quassel@146.56.130.54)
2022-10-04 15:23:11 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-10-04 15:23:33 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 15:26:50 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-10-04 15:30:03 +0200kenran(~user@user/kenran) (Remote host closed the connection)
2022-10-04 15:34:40 +0200rekahsoft(~rekahsoft@142.189.68.220)
2022-10-04 15:35:30 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-10-04 15:35:41 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 15:38:25 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds)
2022-10-04 15:39:24 +0200troydm(~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 264 seconds)
2022-10-04 15:39:30 +0200dsrt^(~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) (Remote host closed the connection)
2022-10-04 15:40:11 +0200son0p(~ff@181.136.122.143) (Ping timeout: 252 seconds)
2022-10-04 15:49:50 +0200Maeda(~Maeda@91-161-10-149.subs.proxad.net) (Quit: leaving)
2022-10-04 15:50:29 +0200Maeda(~Maeda@91-161-10-149.subs.proxad.net)
2022-10-04 15:57:16 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-04 15:58:13 +0200Sgeo(~Sgeo@user/sgeo)
2022-10-04 15:58:45 +0200Joao003(~Joao003@187.85.87.16)
2022-10-04 16:01:26 +0200doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 268 seconds)
2022-10-04 16:05:41 +0200dontdieych(~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-04 16:06:14 +0200dontdieych(~quassel@146.56.130.54)
2022-10-04 16:09:08 +0200kdaishi(~Thunderbi@94.191.136.234.mobile.tre.se)
2022-10-04 16:11:32 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com)
2022-10-04 16:11:32 +0200wroathe(~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host)
2022-10-04 16:11:32 +0200wroathe(~wroathe@user/wroathe)
2022-10-04 16:13:47 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:6f76:5354:52c9:73a2) (Quit: WeeChat 2.8)
2022-10-04 16:14:11 +0200kenran(~user@user/kenran)
2022-10-04 16:17:25 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-10-04 16:18:26 +0200dontdieych(~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-04 16:19:08 +0200enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq)
2022-10-04 16:21:23 +0200echoone(~echoone@2a02:8109:a1c0:5d05:e839:fba:d2ce:cf82)
2022-10-04 16:21:24 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 264 seconds)
2022-10-04 16:21:25 +0200biberu\(~biberu@user/biberu)
2022-10-04 16:22:06 +0200troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-10-04 16:24:33 +0200biberu(~biberu@user/biberu) (Ping timeout: 252 seconds)
2022-10-04 16:24:33 +0200biberu\biberu
2022-10-04 16:24:44 +0200dontdieych(~quassel@146.56.130.54)
2022-10-04 16:26:09 +0200Joao003(~Joao003@187.85.87.16) (Quit: Client closed)
2022-10-04 16:30:31 +0200cfricke(~cfricke@user/cfricke)
2022-10-04 16:37:36 +0200dcoutts_(~duncan@host86-177-125-45.range86-177.btcentralplus.com) (Remote host closed the connection)
2022-10-04 16:37:46 +0200Joao003(~Joao003@187.85.87.16)
2022-10-04 16:37:53 +0200dcoutts_(~duncan@host86-177-125-45.range86-177.btcentralplus.com)
2022-10-04 16:37:57 +0200Joao003(~Joao003@187.85.87.16) (Client Quit)
2022-10-04 16:38:18 +0200inversed(~inversed@90.209.137.56) (Read error: Connection reset by peer)
2022-10-04 16:39:04 +0200inversed(~inversed@90.209.137.56)
2022-10-04 16:40:08 +0200infinity0(~infinity0@185.112.146.113) (Ping timeout: 268 seconds)
2022-10-04 16:41:09 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 250 seconds)
2022-10-04 16:41:40 +0200davean(~davean@davean.sciesnet.net) (Ping timeout: 246 seconds)
2022-10-04 16:41:58 +0200davean(~davean@davean.sciesnet.net)
2022-10-04 16:42:09 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 252 seconds)
2022-10-04 16:44:36 +0200dontdieych(~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-04 16:45:43 +0200shriekingnoise(~shrieking@186.137.167.202)
2022-10-04 16:45:50 +0200infinity0(~infinity0@185.112.146.113)
2022-10-04 16:45:51 +0200MajorBiscuit(~MajorBisc@c-001-001-038.client.tudelft.eduvpn.nl) (Ping timeout: 260 seconds)
2022-10-04 16:47:25 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 16:48:21 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2022-10-04 16:51:49 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 246 seconds)
2022-10-04 16:55:39 +0200TonyStone(~TonyStone@cpe-74-76-51-197.nycap.res.rr.com)
2022-10-04 17:02:23 +0200dontdieych(~quassel@132.226.169.184)
2022-10-04 17:09:34 +0200dontdieych(~quassel@132.226.169.184) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-04 17:10:09 +0200dontdieych(~quassel@132.226.169.184)
2022-10-04 17:10:12 +0200dontdieych(~quassel@132.226.169.184) (Client Quit)
2022-10-04 17:10:45 +0200dontdieych(~quassel@132.226.169.184)
2022-10-04 17:15:19 +0200dontdieych(~quassel@132.226.169.184) (Client Quit)
2022-10-04 17:16:41 +0200KaipeiKaiepi
2022-10-04 17:18:19 +0200stackdroid18(~stackdroi@user/stackdroid) (Quit: hasta la vista... tchau!)
2022-10-04 17:23:22 +0200jmtdJon
2022-10-04 17:24:17 +0200crns(~netcrns@user/crns) (Quit: gone)
2022-10-04 17:24:36 +0200crns(~netcrns@p4ff5e871.dip0.t-ipconnect.de)
2022-10-04 17:24:36 +0200crns(~netcrns@p4ff5e871.dip0.t-ipconnect.de) (Changing host)
2022-10-04 17:24:36 +0200crns(~netcrns@user/crns)
2022-10-04 17:25:52 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2022-10-04 17:28:37 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Quit: WeeChat 3.6)
2022-10-04 17:35:33 +0200mmhat(~mmh@p200300f1c71ac65eee086bfffe095315.dip0.t-ipconnect.de)
2022-10-04 17:36:16 +0200acidjnk_new(~acidjnk@p54ad5adb.dip0.t-ipconnect.de)
2022-10-04 17:37:03 +0200shapr(~user@68.54.166.125) (Ping timeout: 250 seconds)
2022-10-04 17:40:20 +0200vglfr(~vglfr@145.224.100.190) (Ping timeout: 265 seconds)
2022-10-04 17:41:25 +0200vglfr(~vglfr@145.224.100.190)
2022-10-04 17:41:28 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection)
2022-10-04 17:42:46 +0200son0p(~ff@181.136.122.143)
2022-10-04 17:43:21 +0200tobiasBora(~tobiasBor@2001:861:3381:7880:b41b:ebe4:a7ea:5772)
2022-10-04 17:44:16 +0200 <tobiasBora> Hello, I learnt about the --nix option of slack that is apparently required to make it work on nixos… However I tried it and it works without any trouble on my system. Is this option enabled by default now? If not any idea why it works on my system? Is --nix supposed to bring any other benefit rather than making it work on nixos?
2022-10-04 17:45:16 +0200 <geekosaur> --nix just means to use a nix-shell
2022-10-04 17:45:36 +0200 <geekosaur> if you don't need one to access dependencies, you don't need --nix
2022-10-04 17:45:58 +0200ellensol(~ln@pc-ellar188.it.uu.se)
2022-10-04 17:48:56 +0200son0p(~ff@181.136.122.143) (Remote host closed the connection)
2022-10-04 17:57:10 +0200Lycurgus(~juan@user/Lycurgus)
2022-10-04 17:57:28 +0200doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com)
2022-10-04 18:01:23 +0200levitating(~irc@user/levitating) ()
2022-10-04 18:01:42 +0200 <tobiasBora> geekosaur hum… so how can I know if I need a nix-shell to access the dependencies? Is it only the non-haskell dependencies here, or does it also include stuff like ghc…?
2022-10-04 18:02:36 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 18:02:57 +0200 <geekosaur> usually it means non-Haskell dependencies
2022-10-04 18:03:11 +0200 <geekosaur> stack wants to control ghc and Haskell dependencies itself
2022-10-04 18:04:12 +0200echoone(~echoone@2a02:8109:a1c0:5d05:e839:fba:d2ce:cf82) (Quit: Client closed)
2022-10-04 18:05:37 +0200 <geekosaur> a quick and not quite 100% reliable determinant is that if you have a shell.nix file then you need to build via nix-shell and therefore use --nix
2022-10-04 18:06:49 +0200 <geekosaur> that said, I don't know stack that well and it's possible that if you use --nix it writes a shell.nix specifying the non-haskell deps it wants
2022-10-04 18:06:57 +0200 <tobiasBora> And stack does not need --nix to get ghc on nixos? I got confused by https://typeclasses.com/stack-and-nix that says that stack cannot start without --nix on nixos
2022-10-04 18:07:00 +0200 <geekosaur> since it can rely on nix to provide them
2022-10-04 18:07:52 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-10-04 18:07:55 +0200 <tobiasBora> But if I have a shell.nix, I guess I would anyway start this shell manually even before stack to get the stack binary no?
2022-10-04 18:08:02 +0200 <geekosaur> that sounds wrong to me. perhaps at one point stack didn't know which of its canned ghcs to install on nixos
2022-10-04 18:08:21 +0200 <tobiasBora> ok thanks
2022-10-04 18:08:45 +0200 <geekosaur> anywayloo0ks like that's from 2019
2022-10-04 18:09:06 +0200 <geekosaur> in 2022 stack has figured out which of its ghcs to use on nixos
2022-10-04 18:09:57 +0200 <tobiasBora> ok good. So in 2022 --nix is not needed unless I have some non-haskell deps I want to use.
2022-10-04 18:10:53 +0200 <tobiasBora> Btw if you have a reference (commit…) for this statement "in 2022…" I'd love to have it :-)
2022-10-04 18:11:33 +0200 <geekosaur> you said it worked, that's all the proof I need 🙂
2022-10-04 18:11:47 +0200 <geekosaur> (I'm not a stack user and don't follow it that closely)
2022-10-04 18:13:07 +0200 <tobiasBora> Ahah I see, thanks. I was worried that in my case it could work because I had nix_ld setup at some points, and I don't want to write wrong statements if the nixos wiki ^^
2022-10-04 18:13:38 +0200elkcl_(~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru)
2022-10-04 18:14:54 +0200 <geekosaur> that would not tell stack which ghc bindist to install on nixos
2022-10-04 18:15:14 +0200cyphase(~cyphase@user/cyphase)
2022-10-04 18:15:17 +0200 <geekosaur> I believe that's a stack data file that it downloads from a central repository
2022-10-04 18:15:19 +0200massimo_zaniboni(~quassel@mail.asterisell.com)
2022-10-04 18:15:43 +0200shane(~shane@ana.rch.ist) (Ping timeout: 268 seconds)
2022-10-04 18:16:13 +0200shane(~shane@ana.rch.ist)
2022-10-04 18:16:22 +0200nschoe(~quassel@2a01:e0a:8e:a190:824d:1eb5:b8c7:3d88) (Ping timeout: 268 seconds)
2022-10-04 18:17:56 +0200 <geekosaur> also that was not the nixos wiki that claimed stack couldn't start without --nix, that was a third party site not associated with either stack or nixos
2022-10-04 18:18:23 +0200raehik1(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-10-04 18:20:23 +0200son0p(~ff@181.136.122.143)
2022-10-04 18:21:12 +0200davean(~davean@davean.sciesnet.net) (*.net *.split)
2022-10-04 18:21:12 +0200inversed(~inversed@90.209.137.56) (*.net *.split)
2022-10-04 18:21:12 +0200zxx7529(~Thunderbi@user/zxx7529) (*.net *.split)
2022-10-04 18:21:12 +0200kdaishi(~Thunderbi@94.191.136.234.mobile.tre.se) (*.net *.split)
2022-10-04 18:21:12 +0200Sgeo(~Sgeo@user/sgeo) (*.net *.split)
2022-10-04 18:21:12 +0200lyle(~lyle@104.246.145.85) (*.net *.split)
2022-10-04 18:21:12 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (*.net *.split)
2022-10-04 18:21:12 +0200mncheck(~mncheck@193.224.205.254) (*.net *.split)
2022-10-04 18:21:12 +0200coot(~coot@213.134.171.3) (*.net *.split)
2022-10-04 18:21:12 +0200alphabeta(~kilolympu@213.144.144.24) (*.net *.split)
2022-10-04 18:21:12 +0200hgolden(~hgolden@cpe-172-251-233-141.socal.res.rr.com) (*.net *.split)
2022-10-04 18:21:12 +0200ystael(~ystael@user/ystael) (*.net *.split)
2022-10-04 18:21:12 +0200[Leary](~Leary]@user/Leary/x-0910699) (*.net *.split)
2022-10-04 18:21:12 +0200cods(~fred@82-65-232-44.subs.proxad.net) (*.net *.split)
2022-10-04 18:21:12 +0200Guest1698(~Guest1698@20.83.116.49) (*.net *.split)
2022-10-04 18:21:12 +0200Ranhir(~Ranhir@157.97.53.139) (*.net *.split)
2022-10-04 18:21:12 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net) (*.net *.split)
2022-10-04 18:21:13 +0200Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (*.net *.split)
2022-10-04 18:21:13 +0200zero(~z@user/zero) (*.net *.split)
2022-10-04 18:21:13 +0200JimL(~quassel@89-162-2-132.fiber.signal.no) (*.net *.split)
2022-10-04 18:21:13 +0200glguy(~glguy@libera/staff-emeritus/glguy) (*.net *.split)
2022-10-04 18:21:13 +0200joeyh(~joeyh@kitenet.net) (*.net *.split)
2022-10-04 18:21:13 +0200sympt(~sympt@user/sympt) (*.net *.split)
2022-10-04 18:21:13 +0200mesaoptimizer(apotheosis@user/PapuaHardyNet) (*.net *.split)
2022-10-04 18:21:13 +0200eL_Bart0(eL_Bart0@dietunichtguten.org) (*.net *.split)
2022-10-04 18:21:13 +0200WarzoneCommand(~Frank@77-162-168-71.fixed.kpn.net) (*.net *.split)
2022-10-04 18:21:13 +0200Logio(em@kapsi.fi) (*.net *.split)
2022-10-04 18:21:13 +0200pgray__(~pgray@c-24-143-114-36.customer.broadstripe.net) (*.net *.split)
2022-10-04 18:21:13 +0200auri(~auri@fsf/member/auri) (*.net *.split)
2022-10-04 18:21:13 +0200tomboy64(~tomboy64@user/tomboy64) (*.net *.split)
2022-10-04 18:21:13 +0200asm(~alexander@user/asm) (*.net *.split)
2022-10-04 18:21:13 +0200res0nat0r084490(~Fletch@dia.whatbox.ca) (*.net *.split)
2022-10-04 18:21:13 +0200Maja(~quassel@178-37-215-128.adsl.inetia.pl) (*.net *.split)
2022-10-04 18:21:13 +0200haskl(~haskl@user/haskl) (*.net *.split)
2022-10-04 18:21:13 +0200GoldsteinQ(~goldstein@goldstein.rs) (*.net *.split)
2022-10-04 18:21:13 +0200zachel(~zachel@user/zachel) (*.net *.split)
2022-10-04 18:21:13 +0200aweinstock(~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (*.net *.split)
2022-10-04 18:21:13 +0200wagle(~wagle@quassel.wagle.io) (*.net *.split)
2022-10-04 18:21:13 +0200abrar(~abrar@static-108-2-152-54.phlapa.fios.verizon.net) (*.net *.split)
2022-10-04 18:21:13 +0200lambdabot(~lambdabot@haskell/bot/lambdabot) (*.net *.split)
2022-10-04 18:21:13 +0200int-e(~noone@int-e.eu) (*.net *.split)
2022-10-04 18:21:13 +0200foul_owl(~kerry@174-21-75-230.tukw.qwest.net) (*.net *.split)
2022-10-04 18:21:13 +0200taeaad(~taeaad@user/taeaad) (*.net *.split)
2022-10-04 18:21:13 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (*.net *.split)
2022-10-04 18:21:13 +0200Zemyla(~ec2-user@ec2-54-80-174-150.compute-1.amazonaws.com) (*.net *.split)
2022-10-04 18:21:13 +0200adium(adium@user/adium) (*.net *.split)
2022-10-04 18:21:13 +0200superbil(~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split)
2022-10-04 18:21:13 +0200hexology(~hexology@user/hexology) (*.net *.split)
2022-10-04 18:21:13 +0200anderson(~ande@user/anderson) (*.net *.split)
2022-10-04 18:21:13 +0200Square(~a@user/square) (*.net *.split)
2022-10-04 18:21:13 +0200Aleksejs(~Aleksejs@107.170.21.106) (*.net *.split)
2022-10-04 18:21:13 +0200mht-wtf(~mht@2a03:b0c0:3:e0::1e2:c001) (*.net *.split)
2022-10-04 18:21:13 +0200robertm(robertm@lattice.rojoma.com) (*.net *.split)
2022-10-04 18:21:13 +0200bwe_(~bwe@2a01:4f8:1c1c:4878::2) (*.net *.split)
2022-10-04 18:21:13 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (*.net *.split)
2022-10-04 18:21:13 +0200laman1(~laman@rego.ai) (*.net *.split)
2022-10-04 18:21:13 +0200vjoki(~vjoki@2a00:d880:3:1::fea1:9ae) (*.net *.split)
2022-10-04 18:21:13 +0200gmc(sid58314@id-58314.ilkley.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200hendi(sid489601@id-489601.lymington.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200glowcoil(sid3405@id-3405.tinside.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200bbhoss(sid18216@id-18216.tinside.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200sajith(~sajith@user/sajith) (*.net *.split)
2022-10-04 18:21:13 +0200Jon(jon@dow.land) (*.net *.split)
2022-10-04 18:21:13 +0200acertain(sid470584@id-470584.hampstead.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200lally(sid388228@id-388228.uxbridge.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200flukiluke(~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) (*.net *.split)
2022-10-04 18:21:13 +0200jocke-l(jocke-l@a.x0.is) (*.net *.split)
2022-10-04 18:21:13 +0200dexter1(dexter@2a01:7e00::f03c:91ff:fe86:59ec) (*.net *.split)
2022-10-04 18:21:13 +0200Franciman(~Franciman@mx1.fracta.dev) (*.net *.split)
2022-10-04 18:21:13 +0200beaky(~beaky@2a03:b0c0:0:1010::1e:a001) (*.net *.split)
2022-10-04 18:21:13 +0200gregberns__(sid315709@id-315709.helmsley.irccloud.com) (*.net *.split)
2022-10-04 18:21:13 +0200dy(sid3438@user/dy) (*.net *.split)
2022-10-04 18:21:13 +0200lexi-lambda(sid92601@id-92601.hampstead.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200dyniec(~dyniec@mail.dybiec.info) (*.net *.split)
2022-10-04 18:21:14 +0200liskin(~liskin@xmonad/liskin) (*.net *.split)
2022-10-04 18:21:14 +0200reda_(~reda@user/reda) (*.net *.split)
2022-10-04 18:21:14 +0200incertia(~incertia@d47-69-133-171.try.wideopenwest.com) (*.net *.split)
2022-10-04 18:21:14 +0200h2t_(~h2t@user/h2t) (*.net *.split)
2022-10-04 18:21:14 +0200SoF(~skius@user/skius) (*.net *.split)
2022-10-04 18:21:14 +0200PHO`(~pho@akari.cielonegro.org) (*.net *.split)
2022-10-04 18:21:14 +0200Firedancer(sid336191@id-336191.hampstead.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200joel135(sid136450@id-136450.hampstead.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200bjs(sid190364@user/bjs) (*.net *.split)
2022-10-04 18:21:14 +0200carter(sid14827@id-14827.helmsley.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200dpratt(sid193493@id-193493.helmsley.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200aristid(sid1599@id-1599.uxbridge.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200NemesisD(sid24071@id-24071.lymington.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200teehemkay_(sid14792@id-14792.lymington.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200lightandlight(sid135476@id-135476.helmsley.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200kevinsjoberg(sid499516@id-499516.lymington.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200sphynx(~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) (*.net *.split)
2022-10-04 18:21:14 +0200hongminhee(sid295@id-295.tinside.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200sa1(sid7690@id-7690.ilkley.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200caasih(sid13241@id-13241.ilkley.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200b20n(sid115913@id-115913.uxbridge.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200bradparker(sid262931@id-262931.uxbridge.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200dsal(sid13060@id-13060.lymington.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200davetapley_(sid666@id-666.uxbridge.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200whez(sid470288@id-470288.lymington.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200bookshelfdave(sid28102@id-28102.ilkley.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (*.net *.split)
2022-10-04 18:21:14 +0200ario_(~ario@159.65.220.102) (*.net *.split)
2022-10-04 18:21:14 +0200onosendi(sid552923@user/onosendi) (*.net *.split)
2022-10-04 18:21:14 +0200Ekho(~Ekho@user/ekho) (*.net *.split)
2022-10-04 18:21:14 +0200tomjaguarpaw(~tom@li367-225.members.linode.com) (*.net *.split)
2022-10-04 18:21:14 +0200Xe(~cadey@tailscale/xe) (*.net *.split)
2022-10-04 18:21:14 +0200kaskal(~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0) (*.net *.split)
2022-10-04 18:21:14 +0200DigitalKiwi(~kiwi@137.184.156.191) (*.net *.split)
2022-10-04 18:21:14 +0200asivitz(uid178348@id-178348.tinside.irccloud.com) (*.net *.split)
2022-10-04 18:21:14 +0200elkcl(~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (*.net *.split)
2022-10-04 18:21:14 +0200lagash_(lagash@lagash.shelltalk.net) (*.net *.split)
2022-10-04 18:21:14 +0200megaTherion(~therion@unix.io) (*.net *.split)
2022-10-04 18:21:14 +0200gff_(~gff@user/gff) (*.net *.split)
2022-10-04 18:21:14 +0200FragByte(~christian@user/fragbyte) (*.net *.split)
2022-10-04 18:21:14 +0200piele(~piele@tbonesteak.creativeserver.net) (*.net *.split)
2022-10-04 18:21:14 +0200Sciencentistguy(~sciencent@hacksoc/ordinary-member) (*.net *.split)
2022-10-04 18:21:14 +0200mzan(~quassel@mail.asterisell.com) (*.net *.split)
2022-10-04 18:21:14 +0200ddb(~ddb@tilde.club) (*.net *.split)
2022-10-04 18:21:14 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (*.net *.split)
2022-10-04 18:21:14 +0200mtjm(~mutantmel@2604:a880:2:d0::208b:d001) (*.net *.split)
2022-10-04 18:21:14 +0200Hafydd(jc@user/hafydd) (*.net *.split)
2022-10-04 18:21:14 +0200m1dnight(~christoph@78-22-0-121.access.telenet.be) (*.net *.split)
2022-10-04 18:21:14 +0200ajb(~ajb@mimas.whatbox.ca) (*.net *.split)
2022-10-04 18:21:14 +0200Ankhers(e99e97ef8e@2604:bf00:561:2000::2a2) (*.net *.split)
2022-10-04 18:21:14 +0200haasn(~nand@haasn.dev) (*.net *.split)
2022-10-04 18:21:14 +0200bjobjo(~bjobjo@user/bjobjo) (*.net *.split)
2022-10-04 18:21:14 +0200Vq(~vq@90-227-195-41-no77.tbcn.telia.com) (*.net *.split)
2022-10-04 18:21:14 +0200wrengr(~wrengr@201.59.83.34.bc.googleusercontent.com) (*.net *.split)
2022-10-04 18:21:14 +0200cpli(77fc530071@2604:bf00:561:2000::252) (*.net *.split)
2022-10-04 18:21:14 +0200fvr(ef3e56ca8b@2604:bf00:561:2000::3c4) (*.net *.split)
2022-10-04 18:21:14 +0200sm2n(ae95cb1267@user/sm2n) (*.net *.split)
2022-10-04 18:21:14 +0200samhh(7569f027cf@2604:bf00:561:2000::e4) (*.net *.split)
2022-10-04 18:21:14 +0200natto(~natto@140.238.225.67) (*.net *.split)
2022-10-04 18:21:14 +0200wolfshappen(~waff@irc.furworks.de) (*.net *.split)
2022-10-04 18:21:14 +0200ell(~ellie@user/ellie) (*.net *.split)
2022-10-04 18:21:14 +0200Inoperable(~PLAYER_1@fancydata.science) (*.net *.split)
2022-10-04 18:21:14 +0200tv(~tv@user/tv) (*.net *.split)
2022-10-04 18:21:14 +0200Igloo(~ian@matrix.chaos.earth.li) (*.net *.split)
2022-10-04 18:21:14 +0200cross(~cross@spitfire.i.gajendra.net) (*.net *.split)
2022-10-04 18:21:15 +0200elkcl_elkcl
2022-10-04 18:21:24 +0200CiaoSen(~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
2022-10-04 18:22:52 +0200davean(~davean@davean.sciesnet.net)
2022-10-04 18:22:52 +0200inversed(~inversed@90.209.137.56)
2022-10-04 18:22:52 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-10-04 18:22:52 +0200kdaishi(~Thunderbi@94.191.136.234.mobile.tre.se)
2022-10-04 18:22:52 +0200Sgeo(~Sgeo@user/sgeo)
2022-10-04 18:22:52 +0200lyle(~lyle@104.246.145.85)
2022-10-04 18:22:52 +0200mncheck(~mncheck@193.224.205.254)
2022-10-04 18:22:52 +0200coot(~coot@213.134.171.3)
2022-10-04 18:22:52 +0200alphabeta(~kilolympu@213.144.144.24)
2022-10-04 18:22:52 +0200hgolden(~hgolden@cpe-172-251-233-141.socal.res.rr.com)
2022-10-04 18:22:52 +0200ystael(~ystael@user/ystael)
2022-10-04 18:22:52 +0200[Leary](~Leary]@user/Leary/x-0910699)
2022-10-04 18:22:52 +0200cods(~fred@82-65-232-44.subs.proxad.net)
2022-10-04 18:22:52 +0200Guest1698(~Guest1698@20.83.116.49)
2022-10-04 18:22:52 +0200Ranhir(~Ranhir@157.97.53.139)
2022-10-04 18:22:52 +0200kaskal(~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0)
2022-10-04 18:22:52 +0200DigitalKiwi(~kiwi@137.184.156.191)
2022-10-04 18:22:52 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net)
2022-10-04 18:22:52 +0200asivitz(uid178348@id-178348.tinside.irccloud.com)
2022-10-04 18:22:52 +0200lagash_(lagash@lagash.shelltalk.net)
2022-10-04 18:22:52 +0200Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net)
2022-10-04 18:22:52 +0200megaTherion(~therion@unix.io)
2022-10-04 18:22:52 +0200gff_(~gff@user/gff)
2022-10-04 18:22:52 +0200zero(~z@user/zero)
2022-10-04 18:22:52 +0200JimL(~quassel@89-162-2-132.fiber.signal.no)
2022-10-04 18:22:52 +0200FragByte(~christian@user/fragbyte)
2022-10-04 18:22:52 +0200joeyh(~joeyh@kitenet.net)
2022-10-04 18:22:52 +0200glguy(~glguy@libera/staff-emeritus/glguy)
2022-10-04 18:22:52 +0200sympt(~sympt@user/sympt)
2022-10-04 18:22:52 +0200piele(~piele@tbonesteak.creativeserver.net)
2022-10-04 18:22:52 +0200Sciencentistguy(~sciencent@hacksoc/ordinary-member)
2022-10-04 18:22:52 +0200ddb(~ddb@tilde.club)
2022-10-04 18:22:52 +0200mesaoptimizer(apotheosis@user/PapuaHardyNet)
2022-10-04 18:22:52 +0200eL_Bart0(eL_Bart0@dietunichtguten.org)
2022-10-04 18:22:52 +0200WarzoneCommand(~Frank@77-162-168-71.fixed.kpn.net)
2022-10-04 18:22:52 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-10-04 18:22:52 +0200Logio(em@kapsi.fi)
2022-10-04 18:22:52 +0200mtjm(~mutantmel@2604:a880:2:d0::208b:d001)
2022-10-04 18:22:52 +0200pgray__(~pgray@c-24-143-114-36.customer.broadstripe.net)
2022-10-04 18:22:52 +0200auri(~auri@fsf/member/auri)
2022-10-04 18:22:52 +0200Hafydd(jc@user/hafydd)
2022-10-04 18:22:52 +0200m1dnight(~christoph@78-22-0-121.access.telenet.be)
2022-10-04 18:22:52 +0200ajb(~ajb@mimas.whatbox.ca)
2022-10-04 18:22:52 +0200Ankhers(e99e97ef8e@2604:bf00:561:2000::2a2)
2022-10-04 18:22:52 +0200haasn(~nand@haasn.dev)
2022-10-04 18:22:52 +0200bjobjo(~bjobjo@user/bjobjo)
2022-10-04 18:22:52 +0200tomboy64(~tomboy64@user/tomboy64)
2022-10-04 18:22:52 +0200Vq(~vq@90-227-195-41-no77.tbcn.telia.com)
2022-10-04 18:22:52 +0200wrengr(~wrengr@201.59.83.34.bc.googleusercontent.com)
2022-10-04 18:22:52 +0200cpli(77fc530071@2604:bf00:561:2000::252)
2022-10-04 18:22:52 +0200adium(adium@user/adium)
2022-10-04 18:22:52 +0200Zemyla(~ec2-user@ec2-54-80-174-150.compute-1.amazonaws.com)
2022-10-04 18:22:52 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2022-10-04 18:22:52 +0200taeaad(~taeaad@user/taeaad)
2022-10-04 18:22:52 +0200foul_owl(~kerry@174-21-75-230.tukw.qwest.net)
2022-10-04 18:22:52 +0200int-e(~noone@int-e.eu)
2022-10-04 18:22:52 +0200lambdabot(~lambdabot@haskell/bot/lambdabot)
2022-10-04 18:22:52 +0200abrar(~abrar@static-108-2-152-54.phlapa.fios.verizon.net)
2022-10-04 18:22:52 +0200wagle(~wagle@quassel.wagle.io)
2022-10-04 18:22:52 +0200aweinstock(~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com)
2022-10-04 18:22:52 +0200zachel(~zachel@user/zachel)
2022-10-04 18:22:52 +0200GoldsteinQ(~goldstein@goldstein.rs)
2022-10-04 18:22:52 +0200haskl(~haskl@user/haskl)
2022-10-04 18:22:52 +0200Maja(~quassel@178-37-215-128.adsl.inetia.pl)
2022-10-04 18:22:52 +0200res0nat0r084490(~Fletch@dia.whatbox.ca)
2022-10-04 18:22:52 +0200asm(~alexander@user/asm)
2022-10-04 18:22:52 +0200fvr(ef3e56ca8b@2604:bf00:561:2000::3c4)
2022-10-04 18:22:52 +0200sm2n(ae95cb1267@user/sm2n)
2022-10-04 18:22:52 +0200superbil(~superbil@1-34-176-171.hinet-ip.hinet.net)
2022-10-04 18:22:52 +0200samhh(7569f027cf@2604:bf00:561:2000::e4)
2022-10-04 18:22:52 +0200natto(~natto@140.238.225.67)
2022-10-04 18:22:52 +0200wolfshappen(~waff@irc.furworks.de)
2022-10-04 18:22:52 +0200ell(~ellie@user/ellie)
2022-10-04 18:22:52 +0200Inoperable(~PLAYER_1@fancydata.science)
2022-10-04 18:22:52 +0200tv(~tv@user/tv)
2022-10-04 18:22:52 +0200Igloo(~ian@matrix.chaos.earth.li)
2022-10-04 18:22:52 +0200cross(~cross@spitfire.i.gajendra.net)
2022-10-04 18:22:52 +0200hays(~rootveget@fsf/member/hays)
2022-10-04 18:22:52 +0200Xe(~cadey@tailscale/xe)
2022-10-04 18:22:52 +0200tomjaguarpaw(~tom@li367-225.members.linode.com)
2022-10-04 18:22:52 +0200Ekho(~Ekho@user/ekho)
2022-10-04 18:22:52 +0200ario_(~ario@159.65.220.102)
2022-10-04 18:22:52 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1)
2022-10-04 18:22:52 +0200bookshelfdave(sid28102@id-28102.ilkley.irccloud.com)
2022-10-04 18:22:52 +0200whez(sid470288@id-470288.lymington.irccloud.com)
2022-10-04 18:22:52 +0200davetapley_(sid666@id-666.uxbridge.irccloud.com)
2022-10-04 18:22:52 +0200dsal(sid13060@id-13060.lymington.irccloud.com)
2022-10-04 18:22:52 +0200bradparker(sid262931@id-262931.uxbridge.irccloud.com)
2022-10-04 18:22:52 +0200b20n(sid115913@id-115913.uxbridge.irccloud.com)
2022-10-04 18:22:52 +0200caasih(sid13241@id-13241.ilkley.irccloud.com)
2022-10-04 18:22:52 +0200onosendi(sid552923@user/onosendi)
2022-10-04 18:22:52 +0200sa1(sid7690@id-7690.ilkley.irccloud.com)
2022-10-04 18:22:52 +0200hongminhee(sid295@id-295.tinside.irccloud.com)
2022-10-04 18:22:52 +0200sphynx(~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288)
2022-10-04 18:22:52 +0200kevinsjoberg(sid499516@id-499516.lymington.irccloud.com)
2022-10-04 18:22:52 +0200teehemkay_(sid14792@id-14792.lymington.irccloud.com)
2022-10-04 18:22:52 +0200aristid(sid1599@id-1599.uxbridge.irccloud.com)
2022-10-04 18:22:52 +0200lightandlight(sid135476@id-135476.helmsley.irccloud.com)
2022-10-04 18:22:52 +0200NemesisD(sid24071@id-24071.lymington.irccloud.com)
2022-10-04 18:22:52 +0200dpratt(sid193493@id-193493.helmsley.irccloud.com)
2022-10-04 18:22:52 +0200carter(sid14827@id-14827.helmsley.irccloud.com)
2022-10-04 18:22:52 +0200bjs(sid190364@user/bjs)
2022-10-04 18:22:52 +0200joel135(sid136450@id-136450.hampstead.irccloud.com)
2022-10-04 18:22:52 +0200Firedancer(sid336191@id-336191.hampstead.irccloud.com)
2022-10-04 18:22:52 +0200PHO`(~pho@akari.cielonegro.org)
2022-10-04 18:22:52 +0200SoF(~skius@user/skius)
2022-10-04 18:22:52 +0200h2t_(~h2t@user/h2t)
2022-10-04 18:22:52 +0200incertia(~incertia@d47-69-133-171.try.wideopenwest.com)
2022-10-04 18:22:52 +0200reda_(~reda@user/reda)
2022-10-04 18:22:52 +0200liskin(~liskin@xmonad/liskin)
2022-10-04 18:22:52 +0200dyniec(~dyniec@mail.dybiec.info)
2022-10-04 18:22:52 +0200dy(sid3438@user/dy)
2022-10-04 18:22:52 +0200lexi-lambda(sid92601@id-92601.hampstead.irccloud.com)
2022-10-04 18:22:52 +0200gregberns__(sid315709@id-315709.helmsley.irccloud.com)
2022-10-04 18:22:52 +0200beaky(~beaky@2a03:b0c0:0:1010::1e:a001)
2022-10-04 18:22:52 +0200Franciman(~Franciman@mx1.fracta.dev)
2022-10-04 18:22:52 +0200dexter1(dexter@2a01:7e00::f03c:91ff:fe86:59ec)
2022-10-04 18:22:52 +0200jocke-l(jocke-l@a.x0.is)
2022-10-04 18:22:52 +0200flukiluke(~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962)
2022-10-04 18:22:52 +0200lally(sid388228@id-388228.uxbridge.irccloud.com)
2022-10-04 18:22:52 +0200glowcoil(sid3405@id-3405.tinside.irccloud.com)
2022-10-04 18:22:52 +0200acertain(sid470584@id-470584.hampstead.irccloud.com)
2022-10-04 18:22:52 +0200Jon(jon@dow.land)
2022-10-04 18:22:52 +0200bbhoss(sid18216@id-18216.tinside.irccloud.com)
2022-10-04 18:22:52 +0200hendi(sid489601@id-489601.lymington.irccloud.com)
2022-10-04 18:22:52 +0200sajith(~sajith@user/sajith)
2022-10-04 18:22:52 +0200gmc(sid58314@id-58314.ilkley.irccloud.com)
2022-10-04 18:22:52 +0200laman1(~laman@rego.ai)
2022-10-04 18:22:52 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34)
2022-10-04 18:22:52 +0200vjoki(~vjoki@2a00:d880:3:1::fea1:9ae)
2022-10-04 18:22:52 +0200bwe_(~bwe@2a01:4f8:1c1c:4878::2)
2022-10-04 18:22:52 +0200robertm(robertm@lattice.rojoma.com)
2022-10-04 18:22:52 +0200mht-wtf(~mht@2a03:b0c0:3:e0::1e2:c001)
2022-10-04 18:22:52 +0200Aleksejs(~Aleksejs@107.170.21.106)
2022-10-04 18:22:52 +0200Square(~a@user/square)
2022-10-04 18:22:52 +0200hexology(~hexology@user/hexology)
2022-10-04 18:22:52 +0200anderson(~ande@user/anderson)
2022-10-04 18:22:52 +0200lieven(~mal@ns2.wyrd.be)
2022-10-04 18:22:52 +0200yahb2(~yahb2@2a01:4f8:c0c:5c7b::2)
2022-10-04 18:22:52 +0200Guest585(~mike@user/feetwind)
2022-10-04 18:22:52 +0200leah2(~leah@vuxu.org)
2022-10-04 18:22:52 +0200lyxia(~lyxia@poisson.chat)
2022-10-04 18:22:52 +0200jimki(~jmaki@gazorpazorp.fixme.fi)
2022-10-04 18:22:52 +0200kronicmage(user88019@neotame.csclub.uwaterloo.ca)
2022-10-04 18:22:52 +0200iphy(sid67735@id-67735.lymington.irccloud.com)
2022-10-04 18:22:52 +0200CAT_S(apic@brezn3.muc.ccc.de)
2022-10-04 18:22:52 +0200farn(~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505)
2022-10-04 18:22:52 +0200nurupo(~nurupo.ga@user/nurupo)
2022-10-04 18:23:00 +0200SoF(~skius@user/skius) (Max SendQ exceeded)
2022-10-04 18:23:01 +0200CAT_S(apic@brezn3.muc.ccc.de) (Max SendQ exceeded)
2022-10-04 18:23:01 +0200sm2n(ae95cb1267@user/sm2n) (Max SendQ exceeded)
2022-10-04 18:23:01 +0200hays(~rootveget@fsf/member/hays) (Max SendQ exceeded)
2022-10-04 18:23:01 +0200wolfshappen(~waff@irc.furworks.de) (Max SendQ exceeded)
2022-10-04 18:23:13 +0200sm2n(ae95cb1267@user/sm2n)
2022-10-04 18:23:14 +0200CAT_S(apic@brezn3.muc.ccc.de)
2022-10-04 18:23:18 +0200SoF1(~skius@user/skius)
2022-10-04 18:23:18 +0200wolfshappen(~waff@irc.furworks.de)
2022-10-04 18:24:00 +0200 <tobiasBora> geekosaur oh sure, but I am the one writting the nixos wiki (as I find the documentation really sparse)
2022-10-04 18:24:10 +0200inversed(~inversed@90.209.137.56) (Max SendQ exceeded)
2022-10-04 18:24:36 +0200 <tobiasBora> so that's why I don't want to write "stack needs --nix on nixos" if it is not the case
2022-10-04 18:29:08 +0200econo(uid147250@user/econo)
2022-10-04 18:30:54 +0200jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-10-04 18:32:15 +0200bontaq(~user@ool-45779fe5.dyn.optonline.net)
2022-10-04 18:32:42 +0200 <geekosaur> I would expect it not to be the case, tbh. but if you want the truth, best is to ask at https://github.com/commercialhaskell/stack/issues
2022-10-04 18:33:38 +0200inversed(~inversed@90.209.137.56)
2022-10-04 18:34:25 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.)
2022-10-04 18:35:18 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042)
2022-10-04 18:36:12 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-10-04 18:37:33 +0200dontdieych_(~quassel@132.226.169.184)
2022-10-04 18:40:01 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-10-04 18:40:51 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection)
2022-10-04 18:41:46 +0200 <tobiasBora> ok thanks a lot!
2022-10-04 18:41:54 +0200dontdieych_(~quassel@132.226.169.184) (Client Quit)
2022-10-04 18:42:07 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de)
2022-10-04 18:44:55 +0200MajorBiscuit(~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net)
2022-10-04 18:45:17 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-10-04 18:46:12 +0200dontdieych_(~quassel@132.226.169.184)
2022-10-04 18:46:53 +0200dontdieych_(~quassel@132.226.169.184) (Client Quit)
2022-10-04 18:48:00 +0200zxx7529(~Thunderbi@user/zxx7529) (Ping timeout: 265 seconds)
2022-10-04 18:49:37 +0200nate1(~nate@98.45.169.16)
2022-10-04 18:50:41 +0200fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Ping timeout: 260 seconds)
2022-10-04 18:52:54 +0200kenran(~user@user/kenran) (Remote host closed the connection)
2022-10-04 18:54:46 +0200nate1(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2022-10-04 18:55:23 +0200Alex_test(~al_test@94.233.240.222) (Quit: ;-)
2022-10-04 18:55:32 +0200AlexZenon(~alzenon@94.233.240.222) (Quit: ;-)
2022-10-04 18:56:11 +0200AlexNoo(~AlexNoo@94.233.240.222) (Quit: Leaving)
2022-10-04 18:56:32 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 18:59:40 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection)
2022-10-04 19:01:05 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2022-10-04 19:05:23 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-10-04 19:05:23 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2022-10-04 19:06:25 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-10-04 19:08:03 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-04 19:08:36 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-10-04 19:12:34 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-10-04 19:12:57 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-10-04 19:16:09 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-10-04 19:16:31 +0200AlexZenon(~alzenon@94.233.240.222)
2022-10-04 19:16:38 +0200AlexNoo(~AlexNoo@94.233.240.222)
2022-10-04 19:22:35 +0200Alex_test(~al_test@94.233.240.222)
2022-10-04 19:30:22 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-10-04 19:30:57 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-10-04 19:31:25 +0200massimo_zanibonimzan
2022-10-04 19:32:33 +0200tobiasBora(~tobiasBor@2001:861:3381:7880:b41b:ebe4:a7ea:5772) (Quit: Client closed)
2022-10-04 19:32:50 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042)
2022-10-04 19:33:21 +0200 <dminuoso> Is there a compact and efficient way to get a hexadecimal ASCII representation (Text or String) for a Word8?
2022-10-04 19:33:55 +0200 <dminuoso> (0-padded if possible)
2022-10-04 19:34:45 +0200 <dminuoso> The most ideal way I can think of, is to set up a ByteArray# containing the UTF8 or UTF16 (depending on text version) sequences, and just unsafely creating texts using different offsets into that.
2022-10-04 19:34:51 +0200 <dminuoso> But that's.. effort. :(
2022-10-04 19:38:53 +0200 <davean> dminuoso: I spent some time optimizing that ages ago.
2022-10-04 19:38:58 +0200 <davean> But compact?
2022-10-04 19:39:08 +0200 <davean> miss has a fairly fast implimentation
2022-10-04 19:39:51 +0200dontdieych(~quassel@132.226.169.184)
2022-10-04 19:40:18 +0200 <dminuoso> `miss` as in?
2022-10-04 19:41:08 +0200 <davean> yes the package
2022-10-04 19:41:14 +0200shapr(~user@68.54.166.125)
2022-10-04 19:41:25 +0200 <davean> I focused mroe on parsing it though
2022-10-04 19:41:39 +0200 <davean> Sadly I never worked on breaking that stuff out
2022-10-04 19:41:46 +0200 <davean> mlep should have a package
2022-10-04 19:41:53 +0200dr_merijn(~dr_merijn@86-86-29-250.fixed.kpn.net)
2022-10-04 19:42:45 +0200 <EvanR> a table of 256 things?
2022-10-04 19:43:10 +0200jakalx(~jakalx@base.jakalx.net)
2022-10-04 19:43:34 +0200 <davean> EvanR: yah that works if you're in a big loop of it, its not as good if you aren't and then you want to nibble it and calculate
2022-10-04 19:43:40 +0200beteigeuze(~Thunderbi@89.187.168.45) (Ping timeout: 246 seconds)
2022-10-04 19:43:45 +0200 <davean> it VERY much depends on the surrounding code
2022-10-04 19:43:50 +0200 <EvanR> Vector String, Vector Text
2022-10-04 19:43:55 +0200 <EvanR> it's a constant table right
2022-10-04 19:44:14 +0200 <davean> EvanR: Yes but that takes a lot of cache space. Which is fine if you have a big loop but bad if its a small occasional piece of a bigger piece of code
2022-10-04 19:44:19 +0200 <dminuoso> Oh Im just code golfing with absolutely no need for performance. It's just because I enjoy exploring making things go fast.
2022-10-04 19:44:21 +0200 <dminuoso> Mmm
2022-10-04 19:44:44 +0200 <EvanR> so it's too large...
2022-10-04 19:44:46 +0200 <dminuoso> EvanR: Those suffer from indirection
2022-10-04 19:44:47 +0200 <davean> EvanR: The nibble calculation part is like 10 assembly instructions, so it has a major size advantage.
2022-10-04 19:45:08 +0200 <davean> it is slower than the lookup table though on desktop CPUs if you have a large loop
2022-10-04 19:45:18 +0200 <dminuoso> I absolutely new how to do this in assembly
2022-10-04 19:45:19 +0200 <EvanR> you said you wanted a String or Text so I'm not clear what is going on xD
2022-10-04 19:45:29 +0200 <dminuoso> I want to pretty print mac addresses!
2022-10-04 19:45:35 +0200 <dminuoso> :>
2022-10-04 19:45:43 +0200 <davean> EvanR: Do you understand my explanation?
2022-10-04 19:46:12 +0200 <EvanR> I understand this problem in the context of you are in a desert with nothing but 8 registers or something
2022-10-04 19:46:32 +0200 <davean> Hum, thats not what I'm getting at
2022-10-04 19:46:33 +0200 <EvanR> but like, if the goal is to construct a Text object
2022-10-04 19:46:41 +0200 <EvanR> like, in the heap
2022-10-04 19:46:59 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection)
2022-10-04 19:47:11 +0200 <dminuoso> So when constructing a text (assume text-2.0 for the sake of discussion), you ideally want to poke the UTF8 buffer directly
2022-10-04 19:47:19 +0200 <dminuoso> Rather than builder nonsense
2022-10-04 19:47:26 +0200 <davean> EvanR: Pulling a 256 entry table into cache is VERY slow. You need a lot of itterations to amortize that cost, and even fi you do amortize it, it can kick out other important things from cache.
2022-10-04 19:47:53 +0200 <dminuoso> davean: It wouldnt necessarily pull everything into cache.
2022-10-04 19:47:56 +0200 <EvanR> yeah I think I'm on the W of this XY
2022-10-04 19:48:10 +0200 <davean> dminuoso: No, but has to pull the relivent parts, and memory latency cycles are intense
2022-10-04 19:48:28 +0200 <davean> EvanR: Writes are buffered so you don't suffer any latency on them
2022-10-04 19:48:49 +0200 <dminuoso> Fair enough, you have a point. I guess for mac addresses, where you only need 6 conversions, doing this in arithmatic + poking into a buffer is better.
2022-10-04 19:48:58 +0200 <davean> dminuoso: exactly
2022-10-04 19:49:28 +0200 <davean> even for a Sha1 you easily win on the calculation implimentation
2022-10-04 19:49:33 +0200dontdieych_(~quassel@132.226.169.184)
2022-10-04 19:49:40 +0200 <EvanR> like, something somewhere is reading a Text in order to print it, and this is not order of as bad in memory?
2022-10-04 19:49:43 +0200 <davean> The entire calculation fits inside a single memory latency
2022-10-04 19:50:05 +0200dontdieych(~quassel@132.226.169.184) (Ping timeout: 250 seconds)
2022-10-04 19:50:32 +0200 <EvanR> ok 256 words and 256 utf8 different
2022-10-04 19:50:38 +0200 <davean> dminuoso: and so if you want the table version you actualyl want to prefetch the entire table as a streaming read.
2022-10-04 19:52:02 +0200mbuf(~Shakthi@49.204.133.164) (Remote host closed the connection)
2022-10-04 19:54:57 +0200 <EvanR> how many words is a Text again, minimum xD
2022-10-04 19:55:11 +0200 <EvanR> like 3 or 4
2022-10-04 19:55:16 +0200 <davean> EvanR: Why does that matter?
2022-10-04 19:56:47 +0200 <davean> So its 2 words and a ByteArray# if you want to know
2022-10-04 19:57:00 +0200 <davean> And a ByteArray is 2 Words and its contents
2022-10-04 19:57:00 +0200 <EvanR> and while I still don't understand the goal, isn't everything in haskell doing indirections all the time
2022-10-04 19:57:04 +0200 <davean> so min 5
2022-10-04 19:57:11 +0200 <davean> EvanR: Absolutely not!
2022-10-04 19:57:17 +0200 <davean> where would you get that idea?
2022-10-04 19:57:35 +0200 <EvanR> because my first approximation is that each expression is a heap object
2022-10-04 19:57:51 +0200 <EvanR> accessed via a pointer
2022-10-04 19:58:02 +0200 <davean> Oh god no
2022-10-04 19:58:28 +0200 <davean> Thats what the big chunks are but no, not for anything hot unless you really screw up the optimizer
2022-10-04 19:59:02 +0200 <dminuoso> https://gist.github.com/dminuoso/a49bd924e96c26fbd1d2869336bc6fc9
2022-10-04 19:59:06 +0200 <davean> Like using an existential
2022-10-04 19:59:07 +0200 <dminuoso> I mean this was my first naive attempt
2022-10-04 19:59:28 +0200 <dminuoso> Not entirely terrible, intToDigit is implemented very well
2022-10-04 19:59:42 +0200 <dminuoso> Oh that final showHex is a typo of course.
2022-10-04 19:59:55 +0200 <davean> Why are you doing DList and not poking the byte buffer directly?
2022-10-04 20:00:35 +0200 <dminuoso> So this is an internal struggle right now with supporting both text pre 2.0 and post 2.0
2022-10-04 20:00:42 +0200 <davean> Also I think your better off doing a list directly in this case
2022-10-04 20:00:45 +0200 <dminuoso> Now I could CPP this of course
2022-10-04 20:00:56 +0200 <dminuoso> Yeah, I pondered about that too, Ill have to criterion this
2022-10-04 20:01:24 +0200 <dminuoso> Just means I need to inline the showHex upper and lower part into the main list
2022-10-04 20:01:30 +0200 <dminuoso> Then it would likely be better
2022-10-04 20:01:49 +0200 <davean> https://hackage.haskell.org/package/text-2.0.1/docs/Data-Text.html#v:unpackCString-35-
2022-10-04 20:02:13 +0200Lycurgus(~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org)
2022-10-04 20:02:17 +0200 <davean> er, you want the ascii version I think but you get the idea
2022-10-04 20:02:35 +0200 <davean> Kinda the same thing here
2022-10-04 20:02:36 +0200 <dminuoso> davean: As for the text poking, Ive had similar experiments with domain name pretty printing - and over there all my attempts at poking UTF8/UTF16 directly into a buffer were not much faster than just going through T.unpack + list
2022-10-04 20:03:16 +0200 <davean> Oh I've beaten it by like 2x with it.
2022-10-04 20:03:19 +0200 <dminuoso> davean: Nah, I would rather just use https://hackage.haskell.org/package/text-2.0.1/docs/Data-Text-Internal.html#v:text
2022-10-04 20:04:06 +0200 <davean> dminuoso: you wanted compatible though :)
2022-10-04 20:04:24 +0200 <dminuoso> Sure, the internal struggle is whether I want to use CPP or not
2022-10-04 20:04:49 +0200 <davean> Yah I was avoiding CPP and version risks
2022-10-04 20:05:48 +0200 <dminuoso> The version risks are not an issue
2022-10-04 20:06:09 +0200 <dminuoso> I know to manage tight bounds
2022-10-04 20:06:29 +0200 <davean> Why support pre 2.0 text at all?
2022-10-04 20:06:40 +0200 <dminuoso> Because so many things have text < 2.0 bounds
2022-10-04 20:06:46 +0200 <davean> like what?
2022-10-04 20:06:54 +0200 <dminuoso> Fair chunks of hackage
2022-10-04 20:06:59 +0200 <dminuoso> I dont quite recall
2022-10-04 20:07:19 +0200 <davean> Its almost a year old
2022-10-04 20:07:29 +0200 <EvanR> I'm pre 2.0 text. What changed?
2022-10-04 20:07:36 +0200 <dminuoso> UTF16 -> UTF8
2022-10-04 20:07:41 +0200 <geekosaur> utf8 instead of some utf16 variant
2022-10-04 20:07:41 +0200 <EvanR> oh nice
2022-10-04 20:07:42 +0200 <dminuoso> For the internal representation
2022-10-04 20:08:36 +0200 <geekosaur> I do have to wonder why so many things would have issues with text 2.0
2022-10-04 20:09:00 +0200 <davean> geekosaur: I didn't see much of any issues at all
2022-10-04 20:09:00 +0200 <dminuoso> davean: Mmm, so there's `ip` at least which we do in a few projects. But with what Im doing, I may be replacing it with something more lightweight.
2022-10-04 20:09:07 +0200MajorBiscuit(~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Ping timeout: 248 seconds)
2022-10-04 20:09:17 +0200 <geekosaur> the representation change was supposed to be invisible to users, so either everyone is poking at internals or everyone's scared for no reason
2022-10-04 20:09:26 +0200 <dminuoso> And that thing constructs text buffers directly
2022-10-04 20:09:38 +0200 <dminuoso> Or relies on its internal representation
2022-10-04 20:09:49 +0200 <geekosaur> that said, there's the whole bounds thing
2022-10-04 20:09:49 +0200 <davean> dminuoso: thats on Text 2.0 off hackage
2022-10-04 20:10:03 +0200 <dminuoso> https://hackage.haskell.org/package/ip
2022-10-04 20:10:10 +0200_73(~user@pool-173-76-236-42.bstnma.fios.verizon.net) (Remote host closed the connection)
2022-10-04 20:10:11 +0200 <dminuoso> Nope, still on <1.3
2022-10-04 20:10:33 +0200 <davean> *off hackage* https://github.com/andrewthad/haskell-ip/commit/4bf13a8be73ddc0378cb5ea7ffb4cebfa20a7f96
2022-10-04 20:10:34 +0200 <geekosaur> that is, that upper bounds are recommended for compatibility reasons. but you';d think people would test and request bounds changes
2022-10-04 20:10:46 +0200 <dminuoso> It's solveable, but there's a bunch of GHCJS things I dont understand since I have no clue how to build it+use it with GHCJS fro testing
2022-10-04 20:10:58 +0200 <dminuoso> davean: Ohh! That's new, nice.
2022-10-04 20:11:22 +0200 <geekosaur> "switched some argument orders" ok, there's a good reason for <2 dependency
2022-10-04 20:11:46 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042)
2022-10-04 20:11:59 +0200 <dminuoso> This is going to be nice. :)
2022-10-04 20:11:59 +0200 <davean> geekosaur: there is a compat package though
2022-10-04 20:12:16 +0200 <davean> geekosaur: So you can just change an import
2022-10-04 20:12:24 +0200 <dminuoso> With text-2.0 we will actually gain a *noticeable* speed up in our DNS automation.
2022-10-04 20:12:37 +0200 <davean> dminuoso: Yah! So go Text 2.0 only
2022-10-04 20:12:50 +0200 <dminuoso> I will wait for that change to hit hackage though. :)
2022-10-04 20:13:05 +0200 <davean> dminuoso: Slap Andrew Martin about it
2022-10-04 20:13:33 +0200 <dminuoso> Re dlist, you're right a list is way more sensible: https://gist.github.com/dminuoso/540361a14d721b430c4bd1f7b84b866a
2022-10-04 20:14:05 +0200 <dminuoso> Once our dependencies have migrated, I might think about just requiring text-2.0 on this package and poking into a buffer directly.
2022-10-04 20:14:25 +0200 <dminuoso> But `T.pack` is still _very_ fast for small lists
2022-10-04 20:15:49 +0200 <davean> Sure
2022-10-04 20:16:10 +0200 <davean> Also there are some pretty reliable optimizations for list building in GHC
2022-10-04 20:16:17 +0200 <davean> I dobut you had to hand inline that
2022-10-04 20:16:51 +0200 <dminuoso> Force of habit. When I see something Im absolutely convinced should be inlined, my happiness will not depend on the mood of the simplifier.
2022-10-04 20:17:10 +0200 <davean> reasonable
2022-10-04 20:17:26 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection)
2022-10-04 20:17:43 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection)
2022-10-04 20:18:49 +0200 <davean> dminuoso: Specificly I'd have done it via mconcat
2022-10-04 20:18:56 +0200 <davean> (for reliability)
2022-10-04 20:19:18 +0200 <dminuoso> Why would that be more reliable?
2022-10-04 20:19:59 +0200 <davean> mconcat xss = [x | xs <- xss, x <- xs]
2022-10-04 20:20:11 +0200 <davean> Thats a super inlinable construction that would ruin nofib if someone broke it
2022-10-04 20:20:33 +0200 <davean> You'd have to break the core of the simplifier for it to happen
2022-10-04 20:21:29 +0200 <davean> Your version is sorta the co of that
2022-10-04 20:21:39 +0200 <davean> in that your version can have the shared parts lifted out
2022-10-04 20:22:24 +0200 <davean> (See how that implimentation is directly a nested loop and just needs unrolling?)
2022-10-04 20:22:29 +0200 <dminuoso> Im trying to imagine how you would use mconcat to that end. Mind giving me a pointer?
2022-10-04 20:22:56 +0200 <EvanR> nofib?
2022-10-04 20:22:57 +0200beteigeuze(~Thunderbi@2001:8a0:61b5:6101:f0c:e4e3:bfdc:91df)
2022-10-04 20:23:03 +0200 <dminuoso> EvanR: https://gitlab.haskell.org/ghc/nofib
2022-10-04 20:23:26 +0200 <davean> EvanR: nofib is the benchmark suite GHC is optimized against
2022-10-04 20:23:34 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.6)
2022-10-04 20:23:41 +0200vglfr(~vglfr@145.224.100.190) (Read error: Connection reset by peer)
2022-10-04 20:24:09 +0200fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7)
2022-10-04 20:24:12 +0200 <davean> dminuoso: mconcat [showHex w1, ":", showHex w2, ":", ...]
2022-10-04 20:24:54 +0200 <dminuoso> Outside of ":" it couldnt lift anything else out though
2022-10-04 20:24:56 +0200 <davean> set showHex inlinable
2022-10-04 20:25:00 +0200vglfr(~vglfr@145.224.100.190)
2022-10-04 20:25:17 +0200 <davean> dminuoso: you mean your version? I thought you were asking for my version
2022-10-04 20:25:28 +0200 <dminuoso> No yours
2022-10-04 20:25:38 +0200 <dminuoso> Or well, yes mine too
2022-10-04 20:25:50 +0200 <davean> A compiler COULD do code deduplication on yours and regenerate showHex
2022-10-04 20:26:15 +0200 <davean> Since you have the repeat code blocks
2022-10-04 20:26:33 +0200 <dminuoso> Despite INLINE?
2022-10-04 20:26:41 +0200fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Client Quit)
2022-10-04 20:26:45 +0200 <davean> https://gist.github.com/dminuoso/540361a14d721b430c4bd1f7b84b866a <-- no inline here
2022-10-04 20:26:50 +0200 <dminuoso> Oh well I guess INLINE does *not* forbid subsequent passes to do CSE.
2022-10-04 20:27:04 +0200 <dminuoso> Ahh that you mean
2022-10-04 20:27:32 +0200 <davean> So the short fixed loop version is the lowest decode cost for the CPU and fully pipelinable given the fixed itteration
2022-10-04 20:28:13 +0200 <davean> So it can fill execution units very well potentially
2022-10-04 20:28:16 +0200moonsheep(~user@user/moonsheep)
2022-10-04 20:29:51 +0200 <dminuoso> Im still sadly missing a good mental model of how haskell code gets turned into assembly
2022-10-04 20:30:22 +0200 <dminuoso> Or *machine code if you will
2022-10-04 20:30:51 +0200 <davean> dminuoso: well uh yah, its complicated
2022-10-04 20:30:52 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 20:31:05 +0200dontdieych_(~quassel@132.226.169.184) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-10-04 20:31:45 +0200 <dminuoso> But I do know papers and STG simulators exist, so its not unlearnable. Just didnt have the time or need yet
2022-10-04 20:32:05 +0200 <moonsheep> oh boy, I've been there, and I ended up just giving up
2022-10-04 20:33:10 +0200 <davean> I just take what I know of how compilers work in general, think about it, think about the general execution model and what is known at compile time, make a good guess at a reasonable optimization version, and check the output. I'm right more than 9 times out of 10. I've never specificly bothered to learn GHC
2022-10-04 20:34:26 +0200 <dminuoso> I tend to just imagine my functional code is just imperative code, recursion is just explicit loops, and somewhere assume that the generated code is somewhere along similar lines to what GCC would do with the imperative code.
2022-10-04 20:34:43 +0200 <dminuoso> But Im really not sure how well that approximation is.
2022-10-04 20:35:02 +0200 <davean> Its ... not terrible, it depends on the complexity.
2022-10-04 20:35:07 +0200jespada(~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Ping timeout: 246 seconds)
2022-10-04 20:35:17 +0200jespada_(~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net)
2022-10-04 20:36:12 +0200 <davean> dminuoso: Theres more to it than that, but yah
2022-10-04 20:36:53 +0200dontdieych(~quassel@132.226.169.184)
2022-10-04 20:37:26 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2022-10-04 20:37:31 +0200 <davean> Don't let monochrom know we're having this discussion though. They'll come in and stomp on trying to understand anything.
2022-10-04 20:38:07 +0200geekosaurtries to understand, but mostly the upper levels. codegen is uninteresting
2022-10-04 20:38:20 +0200 <geekosaur> (usually)
2022-10-04 20:38:25 +0200 <dminuoso> Well yeah, I do know there's more to it, and locally I can reason about code after some thinking. But sometimes you do fast and loose reasoning about code.
2022-10-04 20:38:53 +0200Guest112009(~bc@c-73-139-125-125.hsd1.fl.comcast.net)
2022-10-04 20:39:22 +0200 <dminuoso> I might argue, acceptable fast and loose reasoning is better than detailed knowledge, since its not economical to be analyzing generated core for every line of code.
2022-10-04 20:39:26 +0200 <EvanR> is predicting cache effect on performance at all scientific, given the various kinds of CPU out there. Or is it run a benchmark and infer what happened
2022-10-04 20:39:39 +0200 <dminuoso> And its usually also not economical to just think about performance and profile *when* a problem arises.
2022-10-04 20:39:46 +0200 <dminuoso> EvanR: Absolutely.
2022-10-04 20:40:00 +0200 <davean> EvanR: Very much so
2022-10-04 20:40:04 +0200 <dminuoso> EvanR: I find that cache behavior is perhaps the single most predictable and tractable thing you can do!
2022-10-04 20:40:12 +0200 <davean> Caches are all the same with a TINY number of variables
2022-10-04 20:40:15 +0200 <EvanR> by what alien tech do you do that
2022-10-04 20:40:27 +0200 <davean> EvanR: Huh?>
2022-10-04 20:40:28 +0200 <dminuoso> Loading cache lines from memory is *absurdly* slow. Your CPU will stall for hundreds of cycles.. doing nothing.
2022-10-04 20:40:34 +0200dontdieych(~quassel@132.226.169.184) (Client Quit)
2022-10-04 20:40:44 +0200 <dminuoso> (Ignoring the fine and grittier details of superscalar execution)
2022-10-04 20:40:52 +0200 <EvanR> i know the principle, but you don't have like, "use cache here" instructions
2022-10-04 20:40:59 +0200 <dminuoso> EvanR: You have.
2022-10-04 20:41:00 +0200 <EvanR> that you can see or not see
2022-10-04 20:41:10 +0200 <davean> You DO have use cache here, but also cache is ALWAYS used
2022-10-04 20:41:12 +0200 <dminuoso> In Haskell you call these things unboxed/packed things.
2022-10-04 20:41:23 +0200 <EvanR> >_>
2022-10-04 20:41:24 +0200 <dminuoso> Using them directly influences caching behavior
2022-10-04 20:41:26 +0200 <davean> well no, you have prefetch and fetch hints
2022-10-04 20:41:33 +0200 <davean> but you can't not use cache on x86
2022-10-04 20:41:42 +0200 <dminuoso> well you can indirectly. :)
2022-10-04 20:41:44 +0200 <davean> thats the ONLY place the execution units read from
2022-10-04 20:41:46 +0200 <EvanR> yes it's an invisible benefactor
2022-10-04 20:42:08 +0200 <davean> and all you have to do is reason about probability it is cycled out yet at a use site
2022-10-04 20:42:24 +0200 <EvanR> where do you get the probability numbers? what do you compare them to?
2022-10-04 20:42:25 +0200 <davean> And that comes down to addresses loaded and associtivity
2022-10-04 20:42:31 +0200 <davean> This --^
2022-10-04 20:42:41 +0200zaquest(~notzaques@5.130.79.72) (Ping timeout: 252 seconds)
2022-10-04 20:42:52 +0200 <EvanR> does each computer come with a probability table
2022-10-04 20:43:06 +0200vglfr(~vglfr@145.224.100.190) (Ping timeout: 268 seconds)
2022-10-04 20:43:12 +0200 <[exa]> EvanR: cache-oblivious algorithms are a thing
2022-10-04 20:43:19 +0200 <davean> No, you don't need that, thats what associtivity and how many hyper threads or more precisely the execution contexts sharing a cache there are.
2022-10-04 20:43:28 +0200 <davean> [exa]: I love those, but those do it via this
2022-10-04 20:43:58 +0200 <EvanR> I can't remember if cache-oblivious is good or bad
2022-10-04 20:44:19 +0200 <davean> cache oblivious means that no matter the cache, you'll be with a constant factor of optimal cache usage
2022-10-04 20:44:23 +0200vglfr(~vglfr@145.224.100.190)
2022-10-04 20:44:26 +0200 <davean> to simplify it
2022-10-04 20:44:29 +0200 <[exa]> davean: afaik the probability view of the cache is convertible to the owned unknown-cache-size
2022-10-04 20:44:40 +0200 <davean> [exa]: well, and associtivity
2022-10-04 20:44:43 +0200pavonia(~user@user/siracusa)
2022-10-04 20:44:44 +0200 <dminuoso> At the end its nearly impossible to control cache evictions unless you a) pin a process to a CPU (but you often still have shared L3 caches), and b) write the machine code by hand, and c) have some good intimiate knowledge of secret microarchitecfture details.
2022-10-04 20:45:12 +0200 <[exa]> d] run without OS
2022-10-04 20:45:20 +0200 <dminuoso> d is the same as a here.
2022-10-04 20:45:26 +0200 <davean> dminuoso: or you're on a CPU like Cell SPEs
2022-10-04 20:45:28 +0200 <[exa]> ok :D
2022-10-04 20:45:50 +0200 <davean> or a lot of ARMs have a program managed cache
2022-10-04 20:46:02 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:5240:b54d:87d3:8846)
2022-10-04 20:46:20 +0200 <dminuoso> That's just a weird way of phrasing x86 is the Python of CPUs.
2022-10-04 20:46:22 +0200 <dminuoso> :p
2022-10-04 20:46:46 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds)
2022-10-04 20:46:49 +0200 <dminuoso> Not great performance, questionable design, but a lot of people seem to... use it?
2022-10-04 20:47:07 +0200 <davean> dminuoso: A lot of ARM cpus have both explicite and implicite cache sections
2022-10-04 20:48:21 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643)
2022-10-04 20:50:07 +0200 <EvanR> so you can look at the code and decide yes this is certified to stay within the cache or certified to run amok of the cache and be ridiculously slow
2022-10-04 20:51:04 +0200 <dminuoso> EvanR: there is profilers like cachegrind
2022-10-04 20:51:13 +0200 <davean> with high probability. You can't know what other addresses are being loaded with users of the cache in a sahred cache situation but you can know its extremely unlikely
2022-10-04 20:51:34 +0200 <davean> like if you load one byte that is aligned to the start of a cache line and then the next instruction laod the next byte?
2022-10-04 20:51:35 +0200 <monochrom> I was too busy learning modal logics and constructing Kripke examples / counterexamples, so you are all spared! >:)
2022-10-04 20:51:40 +0200 <davean> What would have to happen for that NOT to be in cache?
2022-10-04 20:51:56 +0200 <davean> 16 loads on a 16-way associative cache, by other threads, in between 2 instructions
2022-10-04 20:52:18 +0200 <EvanR> where's the start of a cache line
2022-10-04 20:53:28 +0200 <davean> That depends on the CPU but it starts at memory address 0 and is modulo the cache line size, so assume at least 32 bytes
2022-10-04 20:53:30 +0200 <int-e> davean: well, you could get preempted
2022-10-04 20:53:40 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 265 seconds)
2022-10-04 20:53:42 +0200 <davean> int-e: right, I was talking abotu that
2022-10-04 20:53:56 +0200 <davean> int-e: Thats explicitely covered by what I said
2022-10-04 20:53:57 +0200 <dminuoso> On virtually all modern x86 CPUs cache lines (all L1, L2 and L3) are 64 bytes
2022-10-04 20:54:08 +0200 <dminuoso> On mod 64 boundaries
2022-10-04 20:54:12 +0200 <davean> er, specificly 16 *aliased* loads
2022-10-04 20:54:29 +0200 <davean> dminuoso: common cache line sizes are 32, 64, or 128 bytes
2022-10-04 20:55:06 +0200 <EvanR> when you hear ghc's first generation fits in cache, is that L1 cache, or 1 cache line or
2022-10-04 20:55:17 +0200 <davean> the z15 uses a 256 byte cache like
2022-10-04 20:55:27 +0200 <davean> EvanR: L3 cache
2022-10-04 20:56:03 +0200 <dminuoso> davean: For all of AMD processors (Zen, Zen2, Zen3), Intel processors (Xeon, Core) they are all 64 bytes.
2022-10-04 20:56:27 +0200 <dminuoso> z15 is not x86/AMD64
2022-10-04 20:57:09 +0200 <davean> dminuoso: He asked where the start of a cache line is
2022-10-04 20:57:35 +0200 <davean> 32 bytes will work on ARM too
2022-10-04 20:57:42 +0200 <davean> which is a much more significant platform
2022-10-04 20:57:55 +0200 <davean> (Most ARM is 64 bytes but not all)
2022-10-04 20:59:51 +0200 <davean> here are ARMs with 32, 64, and 128 byte caches
2022-10-04 21:00:04 +0200 <dminuoso> Unrelated, what are the necessary preconditions for foldr fusion to kick in, for something like `unpack bs = build (unpackFoldr bs)`?
2022-10-04 21:00:14 +0200 <dminuoso> Is it sufficient that GHC inlines `unpack` into my code?
2022-10-04 21:00:39 +0200 <davean> Cortex-M7 for 32 byte, most standard ARMs are 64 byte, and a few like the Exynos M1 are 128 byte
2022-10-04 21:00:59 +0200 <davean> (A lot of the M and lower series are 32 byte)
2022-10-04 21:12:52 +0200 <davean> dminuoso: you do networking equipment - do you not run your stuff on ARM CPUs a lot?
2022-10-04 21:13:22 +0200 <davean> A lot of switches and such have those giant ARM CPU arrays
2022-10-04 21:13:45 +0200 <davean> Some have MIPs still?!
2022-10-04 21:13:50 +0200acidjnk_new(~acidjnk@p54ad5adb.dip0.t-ipconnect.de) (Remote host closed the connection)
2022-10-04 21:14:15 +0200acidjnk_new(~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de)
2022-10-04 21:15:44 +0200 <darkling> MIPS went handily from big workstations to embedded controllers quite nicely. :)
2022-10-04 21:16:40 +0200 <EvanR> still haven't figured out what a MIP is and why MIPS has so many of them
2022-10-04 21:16:51 +0200 <davean> EvanR: is that a joke?
2022-10-04 21:16:53 +0200 <EvanR> yes
2022-10-04 21:16:57 +0200rekahsoft(~rekahsoft@142.189.68.220) (Ping timeout: 268 seconds)
2022-10-04 21:17:20 +0200 <sm> they stockpiled them in secret
2022-10-04 21:18:14 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042)
2022-10-04 21:19:20 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-10-04 21:20:01 +0200codaraxis__(~codaraxis@user/codaraxis)
2022-10-04 21:22:21 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:5240:b54d:87d3:8846) (Ping timeout: 260 seconds)
2022-10-04 21:22:43 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 248 seconds)
2022-10-04 21:24:03 +0200coot(~coot@213.134.171.3) (Quit: coot)
2022-10-04 21:24:06 +0200codaraxis___(~codaraxis@user/codaraxis) (Ping timeout: 260 seconds)
2022-10-04 21:25:06 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 268 seconds)
2022-10-04 21:25:11 +0200ft(~ft@p3e9bc57b.dip0.t-ipconnect.de)
2022-10-04 21:27:13 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 21:28:34 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-10-04 21:29:27 +0200wonko(~wjc@2a0e:1c80:11::50)
2022-10-04 21:30:01 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:7209:4af1:2ab1:81b8)
2022-10-04 21:32:18 +0200 <phma> In a stack project, should the *.cabal and *.lock files be committed or gitignored?
2022-10-04 21:32:47 +0200motherfsck(~motherfsc@user/motherfsck) (Quit: quit)
2022-10-04 21:32:59 +0200 <geekosaur> *.cabal should be committed
2022-10-04 21:35:08 +0200 <phma> they're generated from package.yaml and stack.yaml
2022-10-04 21:35:28 +0200 <davean> yes, but they're required for the package to function.
2022-10-04 21:35:39 +0200 <davean> And what is generated is critical
2022-10-04 21:35:40 +0200 <geekosaur> package.yaml gets you only so far, and if you include the cabal file then cabal users can build it
2022-10-04 21:35:55 +0200ec(~ec@gateway/tor-sasl/ec)
2022-10-04 21:36:02 +0200 <davean> It is absolutely a problem to not include the .cabal file
2022-10-04 21:36:59 +0200 <geekosaur> Jan 04 16:41:58 <merijn> Hell, even snoyberg now argues in favour of "commit the generated cabal file to your repo", at which point the package.yaml becomes pretty much vestigial already anyway
2022-10-04 21:37:24 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 268 seconds)
2022-10-04 21:37:41 +0200 <phma> ok, so stack.yaml.lock and the .cabal file should be committed. I've been committing them, but then noticed that they're regenerated.
2022-10-04 21:38:13 +0200 <phma> if I change the cabal file, but not package.yaml, stack changes it back
2022-10-04 21:38:29 +0200hueso(~root@user/hueso)
2022-10-04 21:39:10 +0200 <davean> yes, it does
2022-10-04 21:43:05 +0200 <sm> stack.yaml.lock might be overkill unless you found otherwise. Very few projects commit that
2022-10-04 21:43:47 +0200 <sm> stack prioritized the cabal file if you change it directly. (And warns that the two are out of sync)
2022-10-04 21:43:54 +0200 <sm> s/prioritized/prioritizes/
2022-10-04 21:44:18 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2022-10-04 21:44:29 +0200son0p(~ff@181.136.122.143) (Ping timeout: 250 seconds)
2022-10-04 21:45:16 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-10-04 21:47:57 +0200doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 252 seconds)
2022-10-04 21:49:00 +0200rockymarine(~rocky@user/rockymarine)
2022-10-04 21:49:30 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2022-10-04 21:49:33 +0200lyle(~lyle@104.246.145.85) (Quit: WeeChat 3.6)
2022-10-04 21:50:18 +0200adanwan(~adanwan@gateway/tor-sasl/adanwan)
2022-10-04 21:51:46 +0200Tuplanolla(~Tuplanoll@91-159-69-34.elisa-laajakaista.fi)
2022-10-04 21:53:04 +0200kuribas(~user@ptr-17d51emyfmo4vkmz9ge.18120a2.ip6.access.telenet.be) (Remote host closed the connection)
2022-10-04 21:58:29 +0200 <dminuoso> davean: So our core fabric runs on Mellanox Switches, which have some cheap intel celeron CPU on them. Our routing core uses Juniper MX204 which use some Intel AMD64 8-core processor that I dont know much more about (the shell you get exposed to runs in a qemu virtualized freebsd, without details about the hypervisor cpu)
2022-10-04 21:58:32 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-10-04 21:58:39 +0200zeenk(~zeenk@2a02:2f04:a20a:3e00:5712:52b0:ca1d:bc63)
2022-10-04 21:59:34 +0200kenran(~user@user/kenran)
2022-10-04 21:59:44 +0200kenran(~user@user/kenran) (Remote host closed the connection)
2022-10-04 22:00:16 +0200kenran(~user@user/kenran)
2022-10-04 22:00:42 +0200kenran(~user@user/kenran) (Remote host closed the connection)
2022-10-04 22:01:14 +0200kenran(~user@user/kenran)
2022-10-04 22:02:11 +0200 <dminuoso> As for our few cisco routers, they use specialized RP3 processors, which I dont think anyone outside Cisco knows much about
2022-10-04 22:02:28 +0200 <dminuoso> So its really mostly AMD64 in our datacenter.
2022-10-04 22:05:46 +0200 <dminuoso> davean: Up until the past, much of the market was saturated by PowerPC really.
2022-10-04 22:06:07 +0200 <dminuoso> At least the vendors I have been exposed to do not use ARM much
2022-10-04 22:06:10 +0200 <dminuoso> Not in the past and not now
2022-10-04 22:06:49 +0200 <dminuoso> Arista too uses x86 processors nowadays
2022-10-04 22:07:04 +0200Midjak(~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
2022-10-04 22:07:12 +0200 <dminuoso> The only ARM-equipped hardware I know of is broadcom stuff
2022-10-04 22:09:32 +0200_xor(~xor@74.215.182.83)
2022-10-04 22:10:00 +0200mixphix(~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca)
2022-10-04 22:12:39 +0200 <mixphix> hi. does anyone know where i can find the recent proposal (?) that expendad LambdaCase with \cases syntax?
2022-10-04 22:12:49 +0200 <mixphix> my google fu is failing me
2022-10-04 22:13:18 +0200 <geekosaur> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst
2022-10-04 22:13:38 +0200 <mixphix> thanks!! <3
2022-10-04 22:18:17 +0200 <EvanR> we finally get LambdaCase by default and now this?
2022-10-04 22:18:34 +0200 <EvanR> can't wait until 2042 to get cases by default
2022-10-04 22:18:42 +0200Lycurgus(~juan@user/Lycurgus)
2022-10-04 22:18:47 +0200 <yushyin> \cases is a fun one
2022-10-04 22:21:25 +0200 <dminuoso> EvanR: Sadly GHC2042 isn't available yet. The only time-travel we have is TardisT.
2022-10-04 22:23:05 +0200kdaishi(~Thunderbi@94.191.136.234.mobile.tre.se) (Read error: Connection reset by peer)
2022-10-04 22:25:18 +0200 <Lycurgus> sadly, unfortunately, ima have to call dr_merijn to find out what's right for yous
2022-10-04 22:25:21 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds)
2022-10-04 22:29:13 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:7209:4af1:2ab1:81b8) (Ping timeout: 246 seconds)
2022-10-04 22:29:57 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-10-04 22:30:26 +0200nate1(~nate@98.45.169.16)
2022-10-04 22:33:56 +0200Guest112009(~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Quit: Leaving)
2022-10-04 22:47:40 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-10-04 22:53:23 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2022-10-04 22:57:58 +0200Lycurgus(~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org)
2022-10-04 23:02:48 +0200ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2022-10-04 23:02:59 +0200chomwitt(~chomwitt@2a02:587:dc14:f500:4d9:c26a:402f:bdab) (Ping timeout: 248 seconds)
2022-10-04 23:04:13 +0200 <EvanR> is there any special cache orientation gotchas when it comes to SIMD like SSE2 operations
2022-10-04 23:04:22 +0200 <EvanR> cache oriented
2022-10-04 23:05:11 +0200 <EvanR> does that even use the same cache
2022-10-04 23:07:52 +0200kenran(~user@user/kenran) (Remote host closed the connection)
2022-10-04 23:11:24 +0200nschoe(~quassel@2a01:e0a:8e:a190:b3be:cb6e:9642:a3bf)
2022-10-04 23:11:24 +0200nschoe(~quassel@2a01:e0a:8e:a190:b3be:cb6e:9642:a3bf) (Client Quit)
2022-10-04 23:12:01 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-10-04 23:15:29 +0200causal(~user@50.35.83.177)
2022-10-04 23:17:33 +0200hays(rootvegeta@fsf/member/hays)
2022-10-04 23:17:54 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection)
2022-10-04 23:19:00 +0200mmhat(~mmh@p200300f1c71ac65eee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
2022-10-04 23:20:23 +0200 <mixphix> yushyin: the `language-haskell` syntax highlighting doesn't support that yet, which is why i was asking!
2022-10-04 23:23:35 +0200codaraxis___(~codaraxis@user/codaraxis)
2022-10-04 23:23:44 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-10-04 23:27:11 +0200mvk(~mvk@2607:fea8:5ce3:8500::778c)
2022-10-04 23:27:47 +0200codaraxis__(~codaraxis@user/codaraxis) (Ping timeout: 268 seconds)
2022-10-04 23:28:04 +0200alphabeta(~kilolympu@213.144.144.24) (Quit: See you later! :))
2022-10-04 23:29:35 +0200mikoto-chan(~mikoto-ch@164.5.249.78)
2022-10-04 23:29:41 +0200michalz(~michalz@185.246.207.197) (Remote host closed the connection)
2022-10-04 23:32:07 +0200 <dminuoso> EvanR: cache is about memory not registers.
2022-10-04 23:32:16 +0200mmhat(~mmh@p200300f1c71ac6cfee086bfffe095315.dip0.t-ipconnect.de)
2022-10-04 23:32:50 +0200 <dminuoso> https://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Intel_Nehalem_arch.svg/1024px-Intel_Neha…
2022-10-04 23:33:13 +0200 <dminuoso> This is a very decent architectural diagram that hopefully displays why SIMD is not different
2022-10-04 23:33:26 +0200 <dminuoso> At least, again, on AMD64 processors like Intel Core or AMD Zen
2022-10-04 23:33:33 +0200nate1(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-10-04 23:33:51 +0200acidjnk_new(~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2022-10-04 23:34:48 +0200biberu(~biberu@user/biberu) (Read error: Connection reset by peer)
2022-10-04 23:35:35 +0200rockymarine(~rocky@user/rockymarine) (Ping timeout: 265 seconds)
2022-10-04 23:37:38 +0200biberu(~biberu@user/biberu)
2022-10-04 23:38:54 +0200 <dminuoso> EvanR: One important thing to note, is how even CISC systems are under the hood just RISC. If you have an instruction that references an address, it will be compiled into a separate load micro op, and then another micro op to deal with that. So even your SIMD instructions might compile into a separate load + semantic execution op, where the load op will execute in port 2.
2022-10-04 23:39:14 +0200 <dminuoso> (that compilation happens right in the cpu itself in the decoders)
2022-10-04 23:41:57 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2022-10-04 23:48:21 +0200mastarija(~mastarija@2a05:4f46:e03:6000:f63b:c026:eeb8:e131)
2022-10-04 23:49:43 +0200 <mastarija> Is there a more elegant way to apply a lens getter to the list of items? e.g. `fmap (^. myGetter) [item1, item2] = [val1, val2]`
2022-10-04 23:51:22 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk)
2022-10-04 23:54:23 +0200 <dminuoso> ls ^.. traverse . myGetter
2022-10-04 23:55:01 +0200 <dminuoso> > [Just 1, Just 2] ^.. traverse . _Just
2022-10-04 23:55:02 +0200 <dminuoso> > [Just 1, Just 2] ^.. traverse . _Just
2022-10-04 23:55:05 +0200 <lambdabot> [1,2]
2022-10-04 23:55:19 +0200titibandit(~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection)
2022-10-04 23:56:41 +0200son0p(~ff@181.136.122.143)
2022-10-04 23:57:24 +0200burnsidesLlama(~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 264 seconds)
2022-10-04 23:57:26 +0200 <c_wraith> note that it *is* a bit different if the per-element lookup can fail
2022-10-04 23:57:35 +0200ec(~ec@gateway/tor-sasl/ec)
2022-10-04 23:57:46 +0200 <c_wraith> but that's not relevant if you were using ^. before
2022-10-04 23:58:07 +0200 <c_wraith> (unless you were using it really unusually)
2022-10-04 23:58:29 +0200 <dminuoso> Mmm, can you build a Getter out of an AffineFold?
2022-10-04 23:58:50 +0200 <dminuoso> % :t failing
2022-10-04 23:58:51 +0200 <yahb2> <interactive>:1:1: error: ; • Variable not in scope: failing ; • Perhaps you meant ‘ceiling’ (imported from Prelude)
2022-10-04 23:58:53 +0200 <dminuoso> :t failing
2022-10-04 23:58:54 +0200 <lambdabot> (Conjoined p, Applicative f) => Traversing p f s t a b -> Over p f s t a b -> Over p f s t a b
2022-10-04 23:59:54 +0200 <mastarija> thanks