| 2022-10-04 00:03:18 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) |
| 2022-10-04 00:11:40 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-10-04 00:15:51 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-10-04 00:16:08 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 00:16:20 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2022-10-04 00:17:07 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-10-04 00:20:35 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds) |
| 2022-10-04 00:20:59 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-10-04 00:22:48 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 00:24:55 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-10-04 00:31:14 +0200 | mikoto-chan | (~mikoto-ch@164.5.249.78) |
| 2022-10-04 00:42:33 +0200 | lys | (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 +0200 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2022-10-04 00:44:15 +0200 | stackdroid18 | (~stackdroi@user/stackdroid) (Quit: Lost terminal) |
| 2022-10-04 00:48:03 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-10-04 00:49:37 +0200 | Topsi | (~Topsi@dyndsl-095-033-018-041.ewe-ip-backbone.de) (Quit: Leaving.) |
| 2022-10-04 00:49:56 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection) |
| 2022-10-04 00:53:33 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 00:55:33 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 00:58:58 +0200 | vorpuni | (~pvorp@2001:861:3881:c690:a94c:fa1b:4d2b:c74b) (Remote host closed the connection) |
| 2022-10-04 00:59:27 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-10-04 01:01:23 +0200 | wonko | (~wjc@2a0e:1c80:11::50) (Ping timeout: 248 seconds) |
| 2022-10-04 01:02:18 +0200 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) |
| 2022-10-04 01:07:05 +0200 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) (Ping timeout: 265 seconds) |
| 2022-10-04 01:15:45 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-10-04 01:21:36 +0200 | ncf | aaaaaaaaaaaaaaaa |
| 2022-10-04 01:21:46 +0200 | aaaaaaaaaaaaaaaa | ncf |
| 2022-10-04 01:25:56 +0200 | caryhartline | (~caryhartl@wireless-mustang28.nat.smu.edu) |
| 2022-10-04 01:27:38 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 01:28:16 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 260 seconds) |
| 2022-10-04 01:31:09 +0200 | mmhat | (~mmh@p200300f1c7062353ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
| 2022-10-04 01:35:29 +0200 | jao | (~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 +0200 | LukeHoersten | (~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 +0200 | mmhat | (~mmh@p57998e06.dip0.t-ipconnect.de) |
| 2022-10-04 01:50:54 +0200 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2022-10-04 01:51:13 +0200 | EvanR | (~EvanR@user/evanr) |
| 2022-10-04 01:59:31 +0200 | caryhartline | (~caryhartl@wireless-mustang28.nat.smu.edu) (Quit: caryhartline) |
| 2022-10-04 02:01:54 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 02:04:04 +0200 | moonsheep | (~moonsheep@user/moonsheep) |
| 2022-10-04 02:14:38 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 02:15:25 +0200 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) |
| 2022-10-04 02:15:59 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 02:18:08 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Ping timeout: 265 seconds) |
| 2022-10-04 02:18:27 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 02:19:45 +0200 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) (Ping timeout: 252 seconds) |
| 2022-10-04 02:24:11 +0200 | jargon | (~jargon@174-22-199-121.phnx.qwest.net) |
| 2022-10-04 02:24:15 +0200 | moonsheep | (~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 +0200 | meinside | (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 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 02:29:51 +0200 | <_73> | Could you expand on that? |
| 2022-10-04 02:30:30 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-04 02:31:02 +0200 | edrx | (~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 +0200 | machinedgod | (~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 +0200 | econo | (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 +0200 | xff0x | (~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 +0200 | beteigeuze | (~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 +0200 | LukeHoersten | (~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 +0200 | Lord_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 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 2022-10-04 02:47:40 +0200 | justsomeguy | (~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 +0200 | dsrt^ | (~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) |
| 2022-10-04 02:48:16 +0200 | Lord_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 +0200 | LukeHoersten | (~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 +0200 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Quit: xff0x) |
| 2022-10-04 02:51:56 +0200 | xff0x | (~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 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-04 02:57:43 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-04 02:57:43 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-04 02:58:27 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-10-04 03:01:11 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-10-04 03:07:32 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-10-04 03:11:46 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Ping timeout: 246 seconds) |
| 2022-10-04 03:12:11 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 03:13:58 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 03:14:05 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 03:17:23 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9917:904:91b1:8303) (Ping timeout: 248 seconds) |
| 2022-10-04 03:19:14 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 03:19:28 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 246 seconds) |
| 2022-10-04 03:19:31 +0200 | ddellacosta | (~ddellacos@143.244.47.73) (Ping timeout: 265 seconds) |
| 2022-10-04 03:19:35 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-10-04 03:20:08 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 03:29:26 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 03:30:50 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 03:34:50 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds) |
| 2022-10-04 03:35:07 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 268 seconds) |
| 2022-10-04 03:35:08 +0200 | mmhat | (~mmh@p57998e06.dip0.t-ipconnect.de) (Quit: WeeChat 3.6) |
| 2022-10-04 03:36:08 +0200 | mikoto-chan | (~mikoto-ch@164.5.249.78) (Read error: Connection reset by peer) |
| 2022-10-04 03:36:21 +0200 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:f196:e70f:bc3c:9f5f) |
| 2022-10-04 03:36:45 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 03:44:44 +0200 | caryhartline | (~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 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-10-04 03:56:44 +0200 | biberu\ | (~biberu@user/biberu) |
| 2022-10-04 04:00:14 +0200 | alphabeta | (~kilolympu@213.144.144.24) |
| 2022-10-04 04:00:36 +0200 | biberu | (~biberu@user/biberu) (Ping timeout: 265 seconds) |
| 2022-10-04 04:00:36 +0200 | kilolympus | (~kilolympu@213.144.144.24) (Ping timeout: 265 seconds) |
| 2022-10-04 04:00:36 +0200 | biberu\ | biberu |
| 2022-10-04 04:02:15 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-10-04 04:02:32 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-10-04 04:08:39 +0200 | td_ | (~td@94.134.91.118) (Ping timeout: 252 seconds) |
| 2022-10-04 04:10:35 +0200 | td_ | (~td@muedsl-82-207-238-106.citykom.de) |
| 2022-10-04 04:12:48 +0200 | dumptruckman | (~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 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-10-04 04:16:27 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 04:16:27 +0200 | finn_elija | FinnElija |
| 2022-10-04 04:17:25 +0200 | dumptruckman | (~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 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 265 seconds) |
| 2022-10-04 04:21:14 +0200 | gurkenglas | (~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 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 04:22:33 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2022-10-04 04:23:29 +0200 | edrx | (~Eduardo@2804:56c:d2d3:4800:cf7d:b421:4c3a:392e) (Killed buffer) |
| 2022-10-04 04:34:46 +0200 | nate4 | (~nate@98.45.169.16) (Read error: Connection reset by peer) |
| 2022-10-04 04:34:48 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 04:34:56 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 04:35:24 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-04 04:41:59 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 04:45:20 +0200 | jargon | (~jargon@174-22-199-121.phnx.qwest.net) (Read error: Connection reset by peer) |
| 2022-10-04 04:46:33 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 04:47:46 +0200 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) |
| 2022-10-04 04:47:50 +0200 | dr_merijn | (~dr_merijn@86.86.29.250) |
| 2022-10-04 04:48:17 +0200 | lottaquestions | (~nick@2607:fa49:503e:7100:79b4:8afd:9b25:f433) (Quit: Konversation terminated!) |
| 2022-10-04 04:49:07 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 248 seconds) |
| 2022-10-04 04:54:44 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 04:55:15 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 2022-10-04 04:57:59 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-04 04:58:00 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-04 04:58:00 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-04 04:58:24 +0200 | img | (~img@user/img) |
| 2022-10-04 05:02:43 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-04 05:03:14 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-10-04 05:03:22 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 05:04:24 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 05:04:39 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 05:08:45 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds) |
| 2022-10-04 05:09:50 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-10-04 05:10:17 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 05:10:57 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2022-10-04 05:11:58 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 05:11:58 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 05:20:00 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) (Quit: bbl) |
| 2022-10-04 05:20:49 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-10-04 05:24:05 +0200 | twb | (~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 +0200 | lys | (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 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 05:29:49 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 05:32:16 +0200 | justsomeguy | (~justsomeg@47.201.160.8) |
| 2022-10-04 05:32:20 +0200 | justsomeguy | (~justsomeg@47.201.160.8) (Client Quit) |
| 2022-10-04 05:32:34 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-04 05:32:45 +0200 | img | (~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 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 246 seconds) |
| 2022-10-04 05:37:16 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 265 seconds) |
| 2022-10-04 05:38:47 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-10-04 05:38:59 +0200 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:c9ff:16c0:a456:ab01) |
| 2022-10-04 05:46:25 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) (Read error: Connection reset by peer) |
| 2022-10-04 05:47:33 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-10-04 05:51:58 +0200 | jargon | (~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 +0200 | wroathe | (~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 +0200 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) |
| 2022-10-04 06:11:57 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 06:17:09 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 250 seconds) |
| 2022-10-04 06:21:06 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 2022-10-04 06:24:38 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-10-04 06:25:39 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-10-04 06:29:49 +0200 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-10-04 06:31:42 +0200 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) |
| 2022-10-04 06:32:32 +0200 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) (Remote host closed the connection) |
| 2022-10-04 06:33:32 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-10-04 06:33:51 +0200 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) |
| 2022-10-04 06:34:12 +0200 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) |
| 2022-10-04 06:37:45 +0200 | relrod | (~relrod@redhat/ansible.staff.relrod) (Quit: .) |
| 2022-10-04 06:39:40 +0200 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 246 seconds) |
| 2022-10-04 06:39:41 +0200 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 2022-10-04 06:40:10 +0200 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) |
| 2022-10-04 06:40:25 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 06:44:40 +0200 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.6) |
| 2022-10-04 06:49:15 +0200 | razetime | (~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 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 07:11:58 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:e5cf:fac1:d8f4:9053) |
| 2022-10-04 07:13:40 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 07:15:24 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 07:16:29 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 07:19:28 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) (Quit: To the moon and back) |
| 2022-10-04 07:20:13 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 07:21:51 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 07:21:53 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds) |
| 2022-10-04 07:22:28 +0200 | danso | (~danso@danso.ca) (Quit: ZNC - https://znc.in) |
| 2022-10-04 07:25:07 +0200 | danso | (~danso@danso.ca) |
| 2022-10-04 07:27:36 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-10-04 07:29:39 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-10-04 07:44:12 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 07:46:40 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 07:48:35 +0200 | coot | (~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 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 07:52:07 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) (Remote host closed the connection) |
| 2022-10-04 07:54:18 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 07:59:32 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-10-04 07:59:58 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) (Remote host closed the connection) |
| 2022-10-04 08:00:31 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 08:01:01 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a36edbbd7fd5b13d5e1.dip0.t-ipconnect.de) |
| 2022-10-04 08:02:09 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 08:02:19 +0200 | k8yun_ | (~k8yun@user/k8yun) (Quit: Leaving) |
| 2022-10-04 08:06:39 +0200 | kenran | (~user@user/kenran) |
| 2022-10-04 08:10:11 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-04 08:13:51 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) (Ping timeout: 268 seconds) |
| 2022-10-04 08:14:16 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a36edbbd7fd5b13d5e1.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-04 08:15:44 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:e5cf:fac1:d8f4:9053) (Ping timeout: 268 seconds) |
| 2022-10-04 08:21:37 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-10-04 08:24:01 +0200 | razetime | (~quassel@117.254.35.18) (Ping timeout: 265 seconds) |
| 2022-10-04 08:24:30 +0200 | razetime | (~quassel@2401:4900:6298:84d:81f1:d694:dea5:362c) |
| 2022-10-04 08:27:07 +0200 | dr_merijn | (~dr_merijn@86.86.29.250) (Ping timeout: 246 seconds) |
| 2022-10-04 08:28:20 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) (Quit: ZzzZzz) |
| 2022-10-04 08:28:21 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 08:30:18 +0200 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-10-04 08:32:21 +0200 | razetime | (~quassel@2401:4900:6298:84d:81f1:d694:dea5:362c) (Ping timeout: 260 seconds) |
| 2022-10-04 08:34:00 +0200 | darkstardevx | (~darkstard@192.183.207.94) (Ping timeout: 264 seconds) |
| 2022-10-04 08:38:17 +0200 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) () |
| 2022-10-04 08:40:56 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-10-04 08:46:06 +0200 | ellensol | (~ellen@ua-84-216-129-63.bbcust.telenor.se) |
| 2022-10-04 08:49:07 +0200 | ellensol | (~ellen@ua-84-216-129-63.bbcust.telenor.se) (Read error: Connection reset by peer) |
| 2022-10-04 08:49:25 +0200 | michalz | (~michalz@185.246.207.197) |
| 2022-10-04 08:50:33 +0200 | BB[m] | (~cashmagem@2001:470:69fc:105::f6dc) |
| 2022-10-04 08:53:50 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 08:55:06 +0200 | MajorBiscuit | (~MajorBisc@c-001-001-038.client.tudelft.eduvpn.nl) |
| 2022-10-04 08:56:11 +0200 | chomwitt | (~chomwitt@2a02:587:dc14:f500:4d9:c26a:402f:bdab) |
| 2022-10-04 08:56:26 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:cbb9:efc2:3629:a341) |
| 2022-10-04 08:58:18 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2022-10-04 09:03:11 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 09:17:50 +0200 | mbuf | (~Shakthi@49.204.133.164) |
| 2022-10-04 09:17:56 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 09:19:49 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 09:21:39 +0200 | kenran | (~user@user/kenran) |
| 2022-10-04 09:27:01 +0200 | troydm | (~troydm@176.37.124.197) (Ping timeout: 244 seconds) |
| 2022-10-04 09:27:45 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-10-04 09:28:42 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:824d:1eb5:b8c7:3d88) |
| 2022-10-04 09:32:26 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds) |
| 2022-10-04 09:40:03 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-10-04 09:43:45 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a36b404354f0b8552f0.dip0.t-ipconnect.de) |
| 2022-10-04 09:46:25 +0200 | romes[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 +0200 | mmhat | (~mmh@p200300f1c700bd12ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-10-04 09:48:37 +0200 | RobertKrook | (~robert@ext-1-087.eduroam.chalmers.se) |
| 2022-10-04 09:48:51 +0200 | mmhat | (~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 +0200 | m5zs7k | (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 +0200 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-10-04 09:53:41 +0200 | m5zs7k | (aquares@web10.mydevil.net) |
| 2022-10-04 09:56:24 +0200 | machinedgod | (~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 +0200 | razetime | (~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 +0200 | rockymarine | (~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 +0200 | rnat | (uid73555@id-73555.lymington.irccloud.com) |
| 2022-10-04 10:02:48 +0200 | dwt_ | (~dwt_@c-98-198-103-176.hsd1.tx.comcast.net) (Ping timeout: 264 seconds) |
| 2022-10-04 10:02:58 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2022-10-04 10:03:50 +0200 | <ski> | hehe :) |
| 2022-10-04 10:05:10 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 10:06:29 +0200 | rnat | (uid73555@id-73555.lymington.irccloud.com) () |
| 2022-10-04 10:06:44 +0200 | rnat | (uid73555@id-73555.lymington.irccloud.com) |
| 2022-10-04 10:10:07 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-10-04 10:11:05 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 10:13:23 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2022-10-04 10:14:20 +0200 | rnat | (uid73555@id-73555.lymington.irccloud.com) () |
| 2022-10-04 10:14:40 +0200 | rnat | (uid73555@id-73555.lymington.irccloud.com) |
| 2022-10-04 10:15:42 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 10:15:55 +0200 | RobertKrook | (~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 +0200 | cheater | (~Username@user/cheater) |
| 2022-10-04 10:23:32 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-10-04 10:24:57 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-10-04 10:26:48 +0200 | wonko | (~wjc@2a0e:1c80:11::50) |
| 2022-10-04 10:33:15 +0200 | ellensol | (~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 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 10:37:25 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 10:37:35 +0200 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 250 seconds) |
| 2022-10-04 10:38:27 +0200 | lys | rosalind |
| 2022-10-04 10:39:26 +0200 | vegetabelfodos | (~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 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 10:42:53 +0200 | eggplantade | (~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 +0200 | razetime | (~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 +0200 | rockymarine | (~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 +0200 | nate1 | (~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 +0200 | burnsidesLlama | (~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 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-10-04 10:49:09 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 10:50:25 +0200 | kuribas | (~user@ptr-17d51emyfmo4vkmz9ge.18120a2.ip6.access.telenet.be) |
| 2022-10-04 10:50:36 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 260 seconds) |
| 2022-10-04 10:51:15 +0200 | nate1 | (~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 +0200 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 10:53:25 +0200 | burnsidesLlama | (~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 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-04 11:05:48 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 11:05:50 +0200 | Hidlegunst | (~Hidleguns@fw-pmc.sorbonne-universite.fr) |
| 2022-10-04 11:07:15 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 11:08:29 +0200 | kdaishi | (~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 +0200 | burnsidesLlama | (~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 +0200 | rockymarine | (~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 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 11:12:59 +0200 | rosalind | lys |
| 2022-10-04 11:13:20 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds) |
| 2022-10-04 11:13:41 +0200 | lys | (lys@id-194105.uxbridge.irccloud.com) () |
| 2022-10-04 11:15:46 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-04 11:16:03 +0200 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 11:16:15 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 11:20:35 +0200 | ellensol | (~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 +0200 | ellensol_ | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 11:30:44 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-10-04 11:33:37 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-10-04 11:38:00 +0200 | DavidBinder | (~DavidBind@134.2.10.18) |
| 2022-10-04 11:38:39 +0200 | ellensol_ | (~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 268 seconds) |
| 2022-10-04 11:38:55 +0200 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 246 seconds) |
| 2022-10-04 11:39:57 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-04 11:41:08 +0200 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 11:41:39 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 11:43:23 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 11:46:11 +0200 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 11:46:30 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 11:48:23 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 268 seconds) |
| 2022-10-04 11:54:35 +0200 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 11:55:43 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:cbb9:efc2:3629:a341) (Ping timeout: 246 seconds) |
| 2022-10-04 11:55:58 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 11:59:08 +0200 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) (Quit: leaving) |
| 2022-10-04 12:00:15 +0200 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 12:00:26 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 12:01:02 +0200 | dr_merijn | (~dr_merijn@86.86.29.250) |
| 2022-10-04 12:04:28 +0200 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 246 seconds) |
| 2022-10-04 12:05:40 +0200 | Hidlegunst | (~Hidleguns@fw-pmc.sorbonne-universite.fr) (Quit: nyaa~) |
| 2022-10-04 12:11:28 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-04 12:12:43 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 12:14:01 +0200 | xff0x | (~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 +0200 | vglfr | (~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 +0200 | vglfr | (~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 +0200 | DavidBinder | (~DavidBind@134.2.10.18) (Remote host closed the connection) |
| 2022-10-04 12:20:22 +0200 | kdaishi | (~Thunderbi@dyn3137-209.wlan.ic.ac.uk) |
| 2022-10-04 12:21:20 +0200 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 265 seconds) |
| 2022-10-04 12:24:46 +0200 | kdaishi | (~Thunderbi@dyn3137-209.wlan.ic.ac.uk) (Ping timeout: 268 seconds) |
| 2022-10-04 12:26:18 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 12:31:00 +0200 | twb | (~twb@2403:5804:c6::add) (Ping timeout: 264 seconds) |
| 2022-10-04 12:31:22 +0200 | ubert | (~Thunderbi@91.141.46.118.wireless.dyn.drei.com) |
| 2022-10-04 12:31:58 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 12:32:06 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2022-10-04 12:33:01 +0200 | raehik | (~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 +0200 | econo | (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 +0200 | ubert | (~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 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 12:37:19 +0200 | twb | (~twb@2403:5804:c6::add) |
| 2022-10-04 12:39:01 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 12:40:51 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-04 12:43:02 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-04 12:43:34 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 12:45:48 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 12:54:07 +0200 | beteigeuze | (~Thunderbi@89.187.168.45) |
| 2022-10-04 12:55:32 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 13:01:00 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 264 seconds) |
| 2022-10-04 13:03:14 +0200 | burnsidesLlama | (~burnsides@client-8-89.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 13:04:31 +0200 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-10-04 13:04:37 +0200 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 13:08:35 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Quit: Leaving.) |
| 2022-10-04 13:09:02 +0200 | rockymarine | (~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 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 250 seconds) |
| 2022-10-04 13:17:27 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-04 13:19:34 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 13:19:40 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds) |
| 2022-10-04 13:24:16 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 13:26:26 +0200 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 268 seconds) |
| 2022-10-04 13:27:53 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 13:28:35 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 248 seconds) |
| 2022-10-04 13:32:04 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-10-04 13:32:26 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 13:36:09 +0200 | img | (~img@user/img) |
| 2022-10-04 13:38:06 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-10-04 13:38:56 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6f76:5354:52c9:73a2) |
| 2022-10-04 13:39:36 +0200 | kdaishi | (~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 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-04 13:45:30 +0200 | eggplantade | (~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 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 250 seconds) |
| 2022-10-04 13:52:05 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-10-04 13:54:37 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 13:56:22 +0200 | lyle | (~lyle@104.246.145.85) |
| 2022-10-04 13:56:36 +0200 | pavonia | (~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 +0200 | wonko | (~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 +0200 | burnsidesLlama | (~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 +0200 | jao | (~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 +0200 | burnsidesLlama | (~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 +0200 | yaroot | (~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 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 14:06:09 +0200 | yaroot | (~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 +0200 | titibandit | (~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 +0200 | azimut | (~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 +0200 | dr_merijn | (~dr_merijn@86.86.29.250) (Ping timeout: 246 seconds) |
| 2022-10-04 14:24:35 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 14:26:15 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-10-04 14:26:43 +0200 | burnsidesLlama | (~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 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 14:31:29 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 258 seconds) |
| 2022-10-04 14:35:27 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-04 14:36:32 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 14:39:05 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2022-10-04 14:39:20 +0200 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds) |
| 2022-10-04 14:41:14 +0200 | rnat | (uid73555@id-73555.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 14:41:30 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 14:46:26 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds) |
| 2022-10-04 14:48:06 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 14:48:40 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 14:52:57 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 14:53:06 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 15:04:00 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 15:05:51 +0200 | zebrag | (~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 +0200 | frost | (~frost@user/frost) (Ping timeout: 252 seconds) |
| 2022-10-04 15:10:43 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-04 15:11:48 +0200 | vegetabelfodos | billcosby |
| 2022-10-04 15:14:34 +0200 | stackdroid18 | (~stackdroi@user/stackdroid) |
| 2022-10-04 15:15:29 +0200 | billcosby | (~vegetabel@user/vegetabelfodos) (Quit: quit) |
| 2022-10-04 15:17:42 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-10-04 15:18:22 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 246 seconds) |
| 2022-10-04 15:18:40 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-04 15:19:18 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a36b404354f0b8552f0.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-10-04 15:20:01 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2022-10-04 15:20:41 +0200 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 15:21:14 +0200 | dontdieych | (~quassel@146.56.130.54) |
| 2022-10-04 15:23:11 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 15:23:33 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 15:26:50 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 15:30:03 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 15:34:40 +0200 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 15:35:30 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-04 15:35:41 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 15:38:25 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-10-04 15:39:24 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 264 seconds) |
| 2022-10-04 15:39:30 +0200 | dsrt^ | (~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2022-10-04 15:40:11 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 252 seconds) |
| 2022-10-04 15:49:50 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: leaving) |
| 2022-10-04 15:50:29 +0200 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
| 2022-10-04 15:57:16 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 15:58:13 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-10-04 15:58:45 +0200 | Joao003 | (~Joao003@187.85.87.16) |
| 2022-10-04 16:01:26 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 268 seconds) |
| 2022-10-04 16:05:41 +0200 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 16:06:14 +0200 | dontdieych | (~quassel@146.56.130.54) |
| 2022-10-04 16:09:08 +0200 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) |
| 2022-10-04 16:11:32 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-04 16:11:32 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-04 16:11:32 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-04 16:13:47 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6f76:5354:52c9:73a2) (Quit: WeeChat 2.8) |
| 2022-10-04 16:14:11 +0200 | kenran | (~user@user/kenran) |
| 2022-10-04 16:17:25 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-10-04 16:18:26 +0200 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 16:19:08 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2022-10-04 16:21:23 +0200 | echoone | (~echoone@2a02:8109:a1c0:5d05:e839:fba:d2ce:cf82) |
| 2022-10-04 16:21:24 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2022-10-04 16:21:25 +0200 | biberu\ | (~biberu@user/biberu) |
| 2022-10-04 16:22:06 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-10-04 16:24:33 +0200 | biberu | (~biberu@user/biberu) (Ping timeout: 252 seconds) |
| 2022-10-04 16:24:33 +0200 | biberu\ | biberu |
| 2022-10-04 16:24:44 +0200 | dontdieych | (~quassel@146.56.130.54) |
| 2022-10-04 16:26:09 +0200 | Joao003 | (~Joao003@187.85.87.16) (Quit: Client closed) |
| 2022-10-04 16:30:31 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-10-04 16:37:36 +0200 | dcoutts_ | (~duncan@host86-177-125-45.range86-177.btcentralplus.com) (Remote host closed the connection) |
| 2022-10-04 16:37:46 +0200 | Joao003 | (~Joao003@187.85.87.16) |
| 2022-10-04 16:37:53 +0200 | dcoutts_ | (~duncan@host86-177-125-45.range86-177.btcentralplus.com) |
| 2022-10-04 16:37:57 +0200 | Joao003 | (~Joao003@187.85.87.16) (Client Quit) |
| 2022-10-04 16:38:18 +0200 | inversed | (~inversed@90.209.137.56) (Read error: Connection reset by peer) |
| 2022-10-04 16:39:04 +0200 | inversed | (~inversed@90.209.137.56) |
| 2022-10-04 16:40:08 +0200 | infinity0 | (~infinity0@185.112.146.113) (Ping timeout: 268 seconds) |
| 2022-10-04 16:41:09 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 250 seconds) |
| 2022-10-04 16:41:40 +0200 | davean | (~davean@davean.sciesnet.net) (Ping timeout: 246 seconds) |
| 2022-10-04 16:41:58 +0200 | davean | (~davean@davean.sciesnet.net) |
| 2022-10-04 16:42:09 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 252 seconds) |
| 2022-10-04 16:44:36 +0200 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 16:45:43 +0200 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-10-04 16:45:50 +0200 | infinity0 | (~infinity0@185.112.146.113) |
| 2022-10-04 16:45:51 +0200 | MajorBiscuit | (~MajorBisc@c-001-001-038.client.tudelft.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2022-10-04 16:47:25 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 16:48:21 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-10-04 16:51:49 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-04 16:55:39 +0200 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-04 17:02:23 +0200 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 17:09:34 +0200 | dontdieych | (~quassel@132.226.169.184) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 17:10:09 +0200 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 17:10:12 +0200 | dontdieych | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 17:10:45 +0200 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 17:15:19 +0200 | dontdieych | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 17:16:41 +0200 | Kaipei | Kaiepi |
| 2022-10-04 17:18:19 +0200 | stackdroid18 | (~stackdroi@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-10-04 17:23:22 +0200 | jmtd | Jon |
| 2022-10-04 17:24:17 +0200 | crns | (~netcrns@user/crns) (Quit: gone) |
| 2022-10-04 17:24:36 +0200 | crns | (~netcrns@p4ff5e871.dip0.t-ipconnect.de) |
| 2022-10-04 17:24:36 +0200 | crns | (~netcrns@p4ff5e871.dip0.t-ipconnect.de) (Changing host) |
| 2022-10-04 17:24:36 +0200 | crns | (~netcrns@user/crns) |
| 2022-10-04 17:25:52 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-10-04 17:28:37 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Quit: WeeChat 3.6) |
| 2022-10-04 17:35:33 +0200 | mmhat | (~mmh@p200300f1c71ac65eee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-10-04 17:36:16 +0200 | acidjnk_new | (~acidjnk@p54ad5adb.dip0.t-ipconnect.de) |
| 2022-10-04 17:37:03 +0200 | shapr | (~user@68.54.166.125) (Ping timeout: 250 seconds) |
| 2022-10-04 17:40:20 +0200 | vglfr | (~vglfr@145.224.100.190) (Ping timeout: 265 seconds) |
| 2022-10-04 17:41:25 +0200 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-04 17:41:28 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 17:42:46 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 17:43:21 +0200 | tobiasBora | (~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 +0200 | ellensol | (~ln@pc-ellar188.it.uu.se) |
| 2022-10-04 17:48:56 +0200 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2022-10-04 17:57:10 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-10-04 17:57:28 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-04 18:01:23 +0200 | levitating | (~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 +0200 | burnsidesLlama | (~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 +0200 | echoone | (~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 +0200 | eggplantade | (~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 +0200 | elkcl_ | (~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 +0200 | cyphase | (~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 +0200 | massimo_zaniboni | (~quassel@mail.asterisell.com) |
| 2022-10-04 18:15:43 +0200 | shane | (~shane@ana.rch.ist) (Ping timeout: 268 seconds) |
| 2022-10-04 18:16:13 +0200 | shane | (~shane@ana.rch.ist) |
| 2022-10-04 18:16:22 +0200 | nschoe | (~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 +0200 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-04 18:20:23 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 18:21:12 +0200 | davean | (~davean@davean.sciesnet.net) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | inversed | (~inversed@90.209.137.56) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | Sgeo | (~Sgeo@user/sgeo) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | lyle | (~lyle@104.246.145.85) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | mncheck | (~mncheck@193.224.205.254) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | coot | (~coot@213.134.171.3) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | alphabeta | (~kilolympu@213.144.144.24) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | ystael | (~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 +0200 | cods | (~fred@82-65-232-44.subs.proxad.net) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | Guest1698 | (~Guest1698@20.83.116.49) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | Ranhir | (~Ranhir@157.97.53.139) (*.net *.split) |
| 2022-10-04 18:21:12 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | zero | (~z@user/zero) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | JimL | (~quassel@89-162-2-132.fiber.signal.no) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | glguy | (~glguy@libera/staff-emeritus/glguy) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | joeyh | (~joeyh@kitenet.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | sympt | (~sympt@user/sympt) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | mesaoptimizer | (apotheosis@user/PapuaHardyNet) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | WarzoneCommand | (~Frank@77-162-168-71.fixed.kpn.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Logio | (em@kapsi.fi) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | pgray__ | (~pgray@c-24-143-114-36.customer.broadstripe.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | auri | (~auri@fsf/member/auri) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | asm | (~alexander@user/asm) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | res0nat0r084490 | (~Fletch@dia.whatbox.ca) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Maja | (~quassel@178-37-215-128.adsl.inetia.pl) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | haskl | (~haskl@user/haskl) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | zachel | (~zachel@user/zachel) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | wagle | (~wagle@quassel.wagle.io) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | int-e | (~noone@int-e.eu) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | foul_owl | (~kerry@174-21-75-230.tukw.qwest.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | taeaad | (~taeaad@user/taeaad) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Zemyla | (~ec2-user@ec2-54-80-174-150.compute-1.amazonaws.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | adium | (adium@user/adium) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | hexology | (~hexology@user/hexology) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | anderson | (~ande@user/anderson) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Square | (~a@user/square) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Aleksejs | (~Aleksejs@107.170.21.106) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | mht-wtf | (~mht@2a03:b0c0:3:e0::1e2:c001) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | robertm | (robertm@lattice.rojoma.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | bwe_ | (~bwe@2a01:4f8:1c1c:4878::2) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | laman1 | (~laman@rego.ai) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | vjoki | (~vjoki@2a00:d880:3:1::fea1:9ae) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | gmc | (sid58314@id-58314.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | hendi | (sid489601@id-489601.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | glowcoil | (sid3405@id-3405.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | bbhoss | (sid18216@id-18216.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | sajith | (~sajith@user/sajith) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Jon | (jon@dow.land) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | acertain | (sid470584@id-470584.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | lally | (sid388228@id-388228.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | flukiluke | (~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | jocke-l | (jocke-l@a.x0.is) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | dexter1 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | Franciman | (~Franciman@mx1.fracta.dev) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | beaky | (~beaky@2a03:b0c0:0:1010::1e:a001) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | gregberns__ | (sid315709@id-315709.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | dy | (sid3438@user/dy) (*.net *.split) |
| 2022-10-04 18:21:13 +0200 | lexi-lambda | (sid92601@id-92601.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | dyniec | (~dyniec@mail.dybiec.info) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | reda_ | (~reda@user/reda) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | incertia | (~incertia@d47-69-133-171.try.wideopenwest.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | h2t_ | (~h2t@user/h2t) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | SoF | (~skius@user/skius) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | PHO` | (~pho@akari.cielonegro.org) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Firedancer | (sid336191@id-336191.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | bjs | (sid190364@user/bjs) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | carter | (sid14827@id-14827.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | dpratt | (sid193493@id-193493.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | teehemkay_ | (sid14792@id-14792.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | hongminhee | (sid295@id-295.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | caasih | (sid13241@id-13241.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | bradparker | (sid262931@id-262931.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | dsal | (sid13060@id-13060.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | davetapley_ | (sid666@id-666.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | whez | (sid470288@id-470288.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | bookshelfdave | (sid28102@id-28102.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | ario_ | (~ario@159.65.220.102) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | onosendi | (sid552923@user/onosendi) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Ekho | (~Ekho@user/ekho) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | tomjaguarpaw | (~tom@li367-225.members.linode.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Xe | (~cadey@tailscale/xe) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | kaskal | (~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | DigitalKiwi | (~kiwi@137.184.156.191) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | asivitz | (uid178348@id-178348.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | lagash_ | (lagash@lagash.shelltalk.net) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | megaTherion | (~therion@unix.io) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | gff_ | (~gff@user/gff) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | FragByte | (~christian@user/fragbyte) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | piele | (~piele@tbonesteak.creativeserver.net) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | mzan | (~quassel@mail.asterisell.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | ddb | (~ddb@tilde.club) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Hafydd | (jc@user/hafydd) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | ajb | (~ajb@mimas.whatbox.ca) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | haasn | (~nand@haasn.dev) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | bjobjo | (~bjobjo@user/bjobjo) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Vq | (~vq@90-227-195-41-no77.tbcn.telia.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | cpli | (77fc530071@2604:bf00:561:2000::252) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | fvr | (ef3e56ca8b@2604:bf00:561:2000::3c4) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | sm2n | (ae95cb1267@user/sm2n) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | samhh | (7569f027cf@2604:bf00:561:2000::e4) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | natto | (~natto@140.238.225.67) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | wolfshappen | (~waff@irc.furworks.de) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | ell | (~ellie@user/ellie) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Inoperable | (~PLAYER_1@fancydata.science) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | tv | (~tv@user/tv) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | Igloo | (~ian@matrix.chaos.earth.li) (*.net *.split) |
| 2022-10-04 18:21:14 +0200 | cross | (~cross@spitfire.i.gajendra.net) (*.net *.split) |
| 2022-10-04 18:21:15 +0200 | elkcl_ | elkcl |
| 2022-10-04 18:21:24 +0200 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-10-04 18:22:52 +0200 | davean | (~davean@davean.sciesnet.net) |
| 2022-10-04 18:22:52 +0200 | inversed | (~inversed@90.209.137.56) |
| 2022-10-04 18:22:52 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-10-04 18:22:52 +0200 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) |
| 2022-10-04 18:22:52 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-10-04 18:22:52 +0200 | lyle | (~lyle@104.246.145.85) |
| 2022-10-04 18:22:52 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2022-10-04 18:22:52 +0200 | coot | (~coot@213.134.171.3) |
| 2022-10-04 18:22:52 +0200 | alphabeta | (~kilolympu@213.144.144.24) |
| 2022-10-04 18:22:52 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-10-04 18:22:52 +0200 | ystael | (~ystael@user/ystael) |
| 2022-10-04 18:22:52 +0200 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2022-10-04 18:22:52 +0200 | cods | (~fred@82-65-232-44.subs.proxad.net) |
| 2022-10-04 18:22:52 +0200 | Guest1698 | (~Guest1698@20.83.116.49) |
| 2022-10-04 18:22:52 +0200 | Ranhir | (~Ranhir@157.97.53.139) |
| 2022-10-04 18:22:52 +0200 | kaskal | (~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0) |
| 2022-10-04 18:22:52 +0200 | DigitalKiwi | (~kiwi@137.184.156.191) |
| 2022-10-04 18:22:52 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-10-04 18:22:52 +0200 | asivitz | (uid178348@id-178348.tinside.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | lagash_ | (lagash@lagash.shelltalk.net) |
| 2022-10-04 18:22:52 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2022-10-04 18:22:52 +0200 | megaTherion | (~therion@unix.io) |
| 2022-10-04 18:22:52 +0200 | gff_ | (~gff@user/gff) |
| 2022-10-04 18:22:52 +0200 | zero | (~z@user/zero) |
| 2022-10-04 18:22:52 +0200 | JimL | (~quassel@89-162-2-132.fiber.signal.no) |
| 2022-10-04 18:22:52 +0200 | FragByte | (~christian@user/fragbyte) |
| 2022-10-04 18:22:52 +0200 | joeyh | (~joeyh@kitenet.net) |
| 2022-10-04 18:22:52 +0200 | glguy | (~glguy@libera/staff-emeritus/glguy) |
| 2022-10-04 18:22:52 +0200 | sympt | (~sympt@user/sympt) |
| 2022-10-04 18:22:52 +0200 | piele | (~piele@tbonesteak.creativeserver.net) |
| 2022-10-04 18:22:52 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) |
| 2022-10-04 18:22:52 +0200 | ddb | (~ddb@tilde.club) |
| 2022-10-04 18:22:52 +0200 | mesaoptimizer | (apotheosis@user/PapuaHardyNet) |
| 2022-10-04 18:22:52 +0200 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2022-10-04 18:22:52 +0200 | WarzoneCommand | (~Frank@77-162-168-71.fixed.kpn.net) |
| 2022-10-04 18:22:52 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-10-04 18:22:52 +0200 | Logio | (em@kapsi.fi) |
| 2022-10-04 18:22:52 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2022-10-04 18:22:52 +0200 | pgray__ | (~pgray@c-24-143-114-36.customer.broadstripe.net) |
| 2022-10-04 18:22:52 +0200 | auri | (~auri@fsf/member/auri) |
| 2022-10-04 18:22:52 +0200 | Hafydd | (jc@user/hafydd) |
| 2022-10-04 18:22:52 +0200 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2022-10-04 18:22:52 +0200 | ajb | (~ajb@mimas.whatbox.ca) |
| 2022-10-04 18:22:52 +0200 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) |
| 2022-10-04 18:22:52 +0200 | haasn | (~nand@haasn.dev) |
| 2022-10-04 18:22:52 +0200 | bjobjo | (~bjobjo@user/bjobjo) |
| 2022-10-04 18:22:52 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2022-10-04 18:22:52 +0200 | Vq | (~vq@90-227-195-41-no77.tbcn.telia.com) |
| 2022-10-04 18:22:52 +0200 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) |
| 2022-10-04 18:22:52 +0200 | cpli | (77fc530071@2604:bf00:561:2000::252) |
| 2022-10-04 18:22:52 +0200 | adium | (adium@user/adium) |
| 2022-10-04 18:22:52 +0200 | Zemyla | (~ec2-user@ec2-54-80-174-150.compute-1.amazonaws.com) |
| 2022-10-04 18:22:52 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2022-10-04 18:22:52 +0200 | taeaad | (~taeaad@user/taeaad) |
| 2022-10-04 18:22:52 +0200 | foul_owl | (~kerry@174-21-75-230.tukw.qwest.net) |
| 2022-10-04 18:22:52 +0200 | int-e | (~noone@int-e.eu) |
| 2022-10-04 18:22:52 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) |
| 2022-10-04 18:22:52 +0200 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) |
| 2022-10-04 18:22:52 +0200 | wagle | (~wagle@quassel.wagle.io) |
| 2022-10-04 18:22:52 +0200 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) |
| 2022-10-04 18:22:52 +0200 | zachel | (~zachel@user/zachel) |
| 2022-10-04 18:22:52 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2022-10-04 18:22:52 +0200 | haskl | (~haskl@user/haskl) |
| 2022-10-04 18:22:52 +0200 | Maja | (~quassel@178-37-215-128.adsl.inetia.pl) |
| 2022-10-04 18:22:52 +0200 | res0nat0r084490 | (~Fletch@dia.whatbox.ca) |
| 2022-10-04 18:22:52 +0200 | asm | (~alexander@user/asm) |
| 2022-10-04 18:22:52 +0200 | fvr | (ef3e56ca8b@2604:bf00:561:2000::3c4) |
| 2022-10-04 18:22:52 +0200 | sm2n | (ae95cb1267@user/sm2n) |
| 2022-10-04 18:22:52 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-10-04 18:22:52 +0200 | samhh | (7569f027cf@2604:bf00:561:2000::e4) |
| 2022-10-04 18:22:52 +0200 | natto | (~natto@140.238.225.67) |
| 2022-10-04 18:22:52 +0200 | wolfshappen | (~waff@irc.furworks.de) |
| 2022-10-04 18:22:52 +0200 | ell | (~ellie@user/ellie) |
| 2022-10-04 18:22:52 +0200 | Inoperable | (~PLAYER_1@fancydata.science) |
| 2022-10-04 18:22:52 +0200 | tv | (~tv@user/tv) |
| 2022-10-04 18:22:52 +0200 | Igloo | (~ian@matrix.chaos.earth.li) |
| 2022-10-04 18:22:52 +0200 | cross | (~cross@spitfire.i.gajendra.net) |
| 2022-10-04 18:22:52 +0200 | hays | (~rootveget@fsf/member/hays) |
| 2022-10-04 18:22:52 +0200 | Xe | (~cadey@tailscale/xe) |
| 2022-10-04 18:22:52 +0200 | tomjaguarpaw | (~tom@li367-225.members.linode.com) |
| 2022-10-04 18:22:52 +0200 | Ekho | (~Ekho@user/ekho) |
| 2022-10-04 18:22:52 +0200 | ario_ | (~ario@159.65.220.102) |
| 2022-10-04 18:22:52 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) |
| 2022-10-04 18:22:52 +0200 | bookshelfdave | (sid28102@id-28102.ilkley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | whez | (sid470288@id-470288.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | davetapley_ | (sid666@id-666.uxbridge.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | dsal | (sid13060@id-13060.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | bradparker | (sid262931@id-262931.uxbridge.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | caasih | (sid13241@id-13241.ilkley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | onosendi | (sid552923@user/onosendi) |
| 2022-10-04 18:22:52 +0200 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | hongminhee | (sid295@id-295.tinside.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) |
| 2022-10-04 18:22:52 +0200 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | teehemkay_ | (sid14792@id-14792.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | dpratt | (sid193493@id-193493.helmsley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | carter | (sid14827@id-14827.helmsley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | bjs | (sid190364@user/bjs) |
| 2022-10-04 18:22:52 +0200 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | Firedancer | (sid336191@id-336191.hampstead.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | PHO` | (~pho@akari.cielonegro.org) |
| 2022-10-04 18:22:52 +0200 | SoF | (~skius@user/skius) |
| 2022-10-04 18:22:52 +0200 | h2t_ | (~h2t@user/h2t) |
| 2022-10-04 18:22:52 +0200 | incertia | (~incertia@d47-69-133-171.try.wideopenwest.com) |
| 2022-10-04 18:22:52 +0200 | reda_ | (~reda@user/reda) |
| 2022-10-04 18:22:52 +0200 | liskin | (~liskin@xmonad/liskin) |
| 2022-10-04 18:22:52 +0200 | dyniec | (~dyniec@mail.dybiec.info) |
| 2022-10-04 18:22:52 +0200 | dy | (sid3438@user/dy) |
| 2022-10-04 18:22:52 +0200 | lexi-lambda | (sid92601@id-92601.hampstead.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | gregberns__ | (sid315709@id-315709.helmsley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | beaky | (~beaky@2a03:b0c0:0:1010::1e:a001) |
| 2022-10-04 18:22:52 +0200 | Franciman | (~Franciman@mx1.fracta.dev) |
| 2022-10-04 18:22:52 +0200 | dexter1 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) |
| 2022-10-04 18:22:52 +0200 | jocke-l | (jocke-l@a.x0.is) |
| 2022-10-04 18:22:52 +0200 | flukiluke | (~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) |
| 2022-10-04 18:22:52 +0200 | lally | (sid388228@id-388228.uxbridge.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | glowcoil | (sid3405@id-3405.tinside.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | acertain | (sid470584@id-470584.hampstead.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | Jon | (jon@dow.land) |
| 2022-10-04 18:22:52 +0200 | bbhoss | (sid18216@id-18216.tinside.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | hendi | (sid489601@id-489601.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | sajith | (~sajith@user/sajith) |
| 2022-10-04 18:22:52 +0200 | gmc | (sid58314@id-58314.ilkley.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | laman1 | (~laman@rego.ai) |
| 2022-10-04 18:22:52 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 2022-10-04 18:22:52 +0200 | vjoki | (~vjoki@2a00:d880:3:1::fea1:9ae) |
| 2022-10-04 18:22:52 +0200 | bwe_ | (~bwe@2a01:4f8:1c1c:4878::2) |
| 2022-10-04 18:22:52 +0200 | robertm | (robertm@lattice.rojoma.com) |
| 2022-10-04 18:22:52 +0200 | mht-wtf | (~mht@2a03:b0c0:3:e0::1e2:c001) |
| 2022-10-04 18:22:52 +0200 | Aleksejs | (~Aleksejs@107.170.21.106) |
| 2022-10-04 18:22:52 +0200 | Square | (~a@user/square) |
| 2022-10-04 18:22:52 +0200 | hexology | (~hexology@user/hexology) |
| 2022-10-04 18:22:52 +0200 | anderson | (~ande@user/anderson) |
| 2022-10-04 18:22:52 +0200 | lieven | (~mal@ns2.wyrd.be) |
| 2022-10-04 18:22:52 +0200 | yahb2 | (~yahb2@2a01:4f8:c0c:5c7b::2) |
| 2022-10-04 18:22:52 +0200 | Guest585 | (~mike@user/feetwind) |
| 2022-10-04 18:22:52 +0200 | leah2 | (~leah@vuxu.org) |
| 2022-10-04 18:22:52 +0200 | lyxia | (~lyxia@poisson.chat) |
| 2022-10-04 18:22:52 +0200 | jimki | (~jmaki@gazorpazorp.fixme.fi) |
| 2022-10-04 18:22:52 +0200 | kronicmage | (user88019@neotame.csclub.uwaterloo.ca) |
| 2022-10-04 18:22:52 +0200 | iphy | (sid67735@id-67735.lymington.irccloud.com) |
| 2022-10-04 18:22:52 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-10-04 18:22:52 +0200 | farn | (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) |
| 2022-10-04 18:22:52 +0200 | nurupo | (~nurupo.ga@user/nurupo) |
| 2022-10-04 18:23:00 +0200 | SoF | (~skius@user/skius) (Max SendQ exceeded) |
| 2022-10-04 18:23:01 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (Max SendQ exceeded) |
| 2022-10-04 18:23:01 +0200 | sm2n | (ae95cb1267@user/sm2n) (Max SendQ exceeded) |
| 2022-10-04 18:23:01 +0200 | hays | (~rootveget@fsf/member/hays) (Max SendQ exceeded) |
| 2022-10-04 18:23:01 +0200 | wolfshappen | (~waff@irc.furworks.de) (Max SendQ exceeded) |
| 2022-10-04 18:23:13 +0200 | sm2n | (ae95cb1267@user/sm2n) |
| 2022-10-04 18:23:14 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-10-04 18:23:18 +0200 | SoF1 | (~skius@user/skius) |
| 2022-10-04 18:23:18 +0200 | wolfshappen | (~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 +0200 | inversed | (~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 +0200 | econo | (uid147250@user/econo) |
| 2022-10-04 18:30:54 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-10-04 18:32:15 +0200 | bontaq | (~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 +0200 | inversed | (~inversed@90.209.137.56) |
| 2022-10-04 18:34:25 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-04 18:35:18 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 18:36:12 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 18:37:33 +0200 | dontdieych_ | (~quassel@132.226.169.184) |
| 2022-10-04 18:40:01 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 18:40:51 +0200 | titibandit | (~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 +0200 | dontdieych_ | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 18:42:07 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-04 18:44:55 +0200 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) |
| 2022-10-04 18:45:17 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 18:46:12 +0200 | dontdieych_ | (~quassel@132.226.169.184) |
| 2022-10-04 18:46:53 +0200 | dontdieych_ | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 18:48:00 +0200 | zxx7529 | (~Thunderbi@user/zxx7529) (Ping timeout: 265 seconds) |
| 2022-10-04 18:49:37 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 18:50:41 +0200 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Ping timeout: 260 seconds) |
| 2022-10-04 18:52:54 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 18:54:46 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-10-04 18:55:23 +0200 | Alex_test | (~al_test@94.233.240.222) (Quit: ;-) |
| 2022-10-04 18:55:32 +0200 | AlexZenon | (~alzenon@94.233.240.222) (Quit: ;-) |
| 2022-10-04 18:56:11 +0200 | AlexNoo | (~AlexNoo@94.233.240.222) (Quit: Leaving) |
| 2022-10-04 18:56:32 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 18:59:40 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection) |
| 2022-10-04 19:01:05 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-10-04 19:05:23 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 19:05:23 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-10-04 19:06:25 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 19:08:03 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 19:08:36 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 19:12:34 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 19:12:57 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 19:16:09 +0200 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-10-04 19:16:31 +0200 | AlexZenon | (~alzenon@94.233.240.222) |
| 2022-10-04 19:16:38 +0200 | AlexNoo | (~AlexNoo@94.233.240.222) |
| 2022-10-04 19:22:35 +0200 | Alex_test | (~al_test@94.233.240.222) |
| 2022-10-04 19:30:22 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 19:30:57 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 19:31:25 +0200 | massimo_zaniboni | mzan |
| 2022-10-04 19:32:33 +0200 | tobiasBora | (~tobiasBor@2001:861:3381:7880:b41b:ebe4:a7ea:5772) (Quit: Client closed) |
| 2022-10-04 19:32:50 +0200 | eggplantade | (~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 +0200 | dontdieych | (~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 +0200 | shapr | (~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 +0200 | dr_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 +0200 | jakalx | (~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 +0200 | beteigeuze | (~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 +0200 | eggplantade | (~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 +0200 | dontdieych_ | (~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 +0200 | dontdieych | (~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 +0200 | mbuf | (~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 +0200 | Lycurgus | (~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 +0200 | MajorBiscuit | (~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 +0200 | eggplantade | (~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 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 20:17:43 +0200 | eggplantade | (~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 +0200 | beteigeuze | (~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 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.6) |
| 2022-10-04 20:23:41 +0200 | vglfr | (~vglfr@145.224.100.190) (Read error: Connection reset by peer) |
| 2022-10-04 20:24:09 +0200 | fserucas | (~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 +0200 | vglfr | (~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 +0200 | fserucas | (~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 +0200 | moonsheep | (~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 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 20:31:05 +0200 | dontdieych_ | (~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 +0200 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-10-04 20:35:17 +0200 | jespada_ | (~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 +0200 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 20:37:26 +0200 | gmg | (~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 +0200 | geekosaur | tries 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 +0200 | Guest112009 | (~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 +0200 | dontdieych | (~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 +0200 | zaquest | (~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 +0200 | vglfr | (~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 +0200 | vglfr | (~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 +0200 | pavonia | (~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 +0200 | lortabac | (~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 +0200 | FinnElija | (~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 +0200 | FinnElija | (~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 +0200 | gurkenglas | (~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 +0200 | acidjnk_new | (~acidjnk@p54ad5adb.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-10-04 21:14:15 +0200 | acidjnk_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 +0200 | rekahsoft | (~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 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 21:19:20 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 21:20:01 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) |
| 2022-10-04 21:22:21 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:5240:b54d:87d3:8846) (Ping timeout: 260 seconds) |
| 2022-10-04 21:22:43 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 248 seconds) |
| 2022-10-04 21:24:03 +0200 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-10-04 21:24:06 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2022-10-04 21:25:06 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 21:25:11 +0200 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) |
| 2022-10-04 21:27:13 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 21:28:34 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-04 21:29:27 +0200 | wonko | (~wjc@2a0e:1c80:11::50) |
| 2022-10-04 21:30:01 +0200 | lortabac | (~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 +0200 | motherfsck | (~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 +0200 | ec | (~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 +0200 | rockymarine | (~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 +0200 | hueso | (~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 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-04 21:44:29 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 250 seconds) |
| 2022-10-04 21:45:16 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-04 21:47:57 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 252 seconds) |
| 2022-10-04 21:49:00 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 21:49:30 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-04 21:49:33 +0200 | lyle | (~lyle@104.246.145.85) (Quit: WeeChat 3.6) |
| 2022-10-04 21:50:18 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-04 21:51:46 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) |
| 2022-10-04 21:53:04 +0200 | kuribas | (~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 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-10-04 21:58:39 +0200 | zeenk | (~zeenk@2a02:2f04:a20a:3e00:5712:52b0:ca1d:bc63) |
| 2022-10-04 21:59:34 +0200 | kenran | (~user@user/kenran) |
| 2022-10-04 21:59:44 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 22:00:16 +0200 | kenran | (~user@user/kenran) |
| 2022-10-04 22:00:42 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 22:01:14 +0200 | kenran | (~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 +0200 | Midjak | (~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 +0200 | mixphix | (~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 +0200 | Lycurgus | (~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 +0200 | kdaishi | (~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 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-10-04 22:29:13 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:7209:4af1:2ab1:81b8) (Ping timeout: 246 seconds) |
| 2022-10-04 22:29:57 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 22:30:26 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 22:33:56 +0200 | Guest112009 | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Quit: Leaving) |
| 2022-10-04 22:47:40 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 22:53:23 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-10-04 22:57:58 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-10-04 23:02:48 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-04 23:02:59 +0200 | chomwitt | (~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 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 23:11:24 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:b3be:cb6e:9642:a3bf) |
| 2022-10-04 23:11:24 +0200 | nschoe | (~quassel@2a01:e0a:8e:a190:b3be:cb6e:9642:a3bf) (Client Quit) |
| 2022-10-04 23:12:01 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-04 23:15:29 +0200 | causal | (~user@50.35.83.177) |
| 2022-10-04 23:17:33 +0200 | hays | (rootvegeta@fsf/member/hays) |
| 2022-10-04 23:17:54 +0200 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 23:19:00 +0200 | mmhat | (~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 +0200 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2022-10-04 23:23:44 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 23:27:11 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) |
| 2022-10-04 23:27:47 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 268 seconds) |
| 2022-10-04 23:28:04 +0200 | alphabeta | (~kilolympu@213.144.144.24) (Quit: See you later! :)) |
| 2022-10-04 23:29:35 +0200 | mikoto-chan | (~mikoto-ch@164.5.249.78) |
| 2022-10-04 23:29:41 +0200 | michalz | (~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 +0200 | mmhat | (~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 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 23:33:51 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-10-04 23:34:48 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2022-10-04 23:35:35 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 23:37:38 +0200 | biberu | (~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 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-10-04 23:48:21 +0200 | mastarija | (~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 +0200 | burnsidesLlama | (~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 +0200 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection) |
| 2022-10-04 23:56:41 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 23:57:24 +0200 | burnsidesLlama | (~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 +0200 | ec | (~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 |
