| 2022-10-04 00:01:54 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 00:04:04 +0000 | moonsheep | (~moonsheep@user/moonsheep) |
| 2022-10-04 00:14:38 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 00:15:25 +0000 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) |
| 2022-10-04 00:15:59 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 00:18:08 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Ping timeout: 265 seconds) |
| 2022-10-04 00:18:27 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 00:19:45 +0000 | ellensol | (~ellen@178-78-210-152.customers.ownit.se) (Ping timeout: 252 seconds) |
| 2022-10-04 00:24:11 +0000 | jargon | (~jargon@174-22-199-121.phnx.qwest.net) |
| 2022-10-04 00:24:15 +0000 | moonsheep | (~moonsheep@user/moonsheep) (Quit: nyaa~) |
| 2022-10-04 00:24:18 +0000 | <_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 00:28:02 +0000 | meinside | (uid24933@id-24933.helmsley.irccloud.com) |
| 2022-10-04 00:28:08 +0000 | <EvanR> | make State an abstract type 😎 |
| 2022-10-04 00:29:51 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 00:29:51 +0000 | <_73> | Could you expand on that? |
| 2022-10-04 00:30:30 +0000 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-04 00:31:02 +0000 | edrx | (~Eduardo@2804:56c:d2d3:4800:cf7d:b421:4c3a:392e) |
| 2022-10-04 00:31:09 +0000 | <_73> | I believe this is what you mean - http://dpaste.com/FQEWXLSP2 |
| 2022-10-04 00:31:26 +0000 | <EvanR> | just that whatever the state ends up being, do I have to know? |
| 2022-10-04 00:31:59 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2022-10-04 00:32:38 +0000 | <_73> | Ok, but what will the state likely end up being? |
| 2022-10-04 00:33:36 +0000 | econo | (uid147250@user/econo) |
| 2022-10-04 00:33:42 +0000 | <EvanR> | do you already know what the state is but you are trying to implement it concretely? |
| 2022-10-04 00:34:57 +0000 | <EvanR> | like, as an Int? |
| 2022-10-04 00:35:49 +0000 | <_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 00:36:30 +0000 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-10-04 00:38:28 +0000 | <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 00:39:00 +0000 | beteigeuze | (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 268 seconds) |
| 2022-10-04 00:39:16 +0000 | <_73> | So maybe an integer that is an index in the input string? Does that make sense? |
| 2022-10-04 00:39:28 +0000 | <EvanR> | no... |
| 2022-10-04 00:39:48 +0000 | <EvanR> | the position of input is something else |
| 2022-10-04 00:40:15 +0000 | <EvanR> | it should be independent of your machine state |
| 2022-10-04 00:42:47 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Ping timeout: 265 seconds) |
| 2022-10-04 00:43:41 +0000 | <_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 00:43:43 +0000 | <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 00:44:42 +0000 | <_73> | Yes it does have such a notation. |
| 2022-10-04 00:44:55 +0000 | <_73> | I am much closer to understanding now |
| 2022-10-04 00:46:41 +0000 | <edrx> | hi all! |
| 2022-10-04 00:46:59 +0000 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-10-04 00:47:24 +0000 | <edrx> | does the bot have entries with instructions for compiling a recent ghc from source? what are the key words? |
| 2022-10-04 00:47:35 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 2022-10-04 00:47:40 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 268 seconds) |
| 2022-10-04 00:47:43 +0000 | <jackdk> | I'd go to the GHC user guide or a source tarball for that |
| 2022-10-04 00:47:58 +0000 | dsrt^ | (~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) |
| 2022-10-04 00:48:16 +0000 | Lord_of_Life_ | Lord_of_Life |
| 2022-10-04 00:50:38 +0000 | <geekosaur> | https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian fwiw |
| 2022-10-04 00:50:45 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 00:51:29 +0000 | <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 00:51:31 +0000 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Quit: xff0x) |
| 2022-10-04 00:51:56 +0000 | xff0x | (~xff0x@2405:6580:b080:900:9917:904:91b1:8303) |
| 2022-10-04 00:52:01 +0000 | <geekosaur> | @where hadrian |
| 2022-10-04 00:52:02 +0000 | <lambdabot> | I know nothing about hadrian. |
| 2022-10-04 00:52:08 +0000 | <geekosaur> | @where+ hadrian https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian |
| 2022-10-04 00:52:09 +0000 | <lambdabot> | It is stored. |
| 2022-10-04 00:57:43 +0000 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-04 00:57:43 +0000 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-04 00:57:43 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-04 00:58:27 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-10-04 01:01:11 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-10-04 01:07:32 +0000 | nate4 | (~nate@98.45.169.16) |
| 2022-10-04 01:11:46 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Ping timeout: 246 seconds) |
| 2022-10-04 01:12:11 +0000 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 01:13:58 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 01:14:05 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 01:17:23 +0000 | xff0x | (~xff0x@2405:6580:b080:900:9917:904:91b1:8303) (Ping timeout: 248 seconds) |
| 2022-10-04 01:19:14 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 01:19:28 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 246 seconds) |
| 2022-10-04 01:19:31 +0000 | ddellacosta | (~ddellacos@143.244.47.73) (Ping timeout: 265 seconds) |
| 2022-10-04 01:19:35 +0000 | nate4 | (~nate@98.45.169.16) |
| 2022-10-04 01:20:08 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 01:29:26 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 01:30:50 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 01:34:50 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds) |
| 2022-10-04 01:35:07 +0000 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 268 seconds) |
| 2022-10-04 01:35:08 +0000 | mmhat | (~mmh@p57998e06.dip0.t-ipconnect.de) (Quit: WeeChat 3.6) |
| 2022-10-04 01:36:08 +0000 | mikoto-chan | (~mikoto-ch@164.5.249.78) (Read error: Connection reset by peer) |
| 2022-10-04 01:36:21 +0000 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:f196:e70f:bc3c:9f5f) |
| 2022-10-04 01:36:45 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 01:44:44 +0000 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:f196:e70f:bc3c:9f5f) (Quit: caryhartline) |
| 2022-10-04 01:53:00 +0000 | <Axman6> | _73: https://wiki.haskell.org/Regular_expressions_for_XML_Schema |
| 2022-10-04 01:53:29 +0000 | <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 01:55:11 +0000 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-10-04 01:56:44 +0000 | biberu\ | (~biberu@user/biberu) |
| 2022-10-04 02:00:14 +0000 | alphabeta | (~kilolympu@213.144.144.24) |
| 2022-10-04 02:00:36 +0000 | biberu | (~biberu@user/biberu) (Ping timeout: 265 seconds) |
| 2022-10-04 02:00:36 +0000 | kilolympus | (~kilolympu@213.144.144.24) (Ping timeout: 265 seconds) |
| 2022-10-04 02:00:36 +0000 | biberu\ | biberu |
| 2022-10-04 02:02:15 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-10-04 02:02:32 +0000 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-10-04 02:08:39 +0000 | td_ | (~td@94.134.91.118) (Ping timeout: 252 seconds) |
| 2022-10-04 02:10:35 +0000 | td_ | (~td@muedsl-82-207-238-106.citykom.de) |
| 2022-10-04 02:12:48 +0000 | dumptruckman | (~dumptruck@172-105-129-222.ip.linodeusercontent.com) (Remote host closed the connection) |
| 2022-10-04 02:13:52 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-10-04 02:16:27 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-10-04 02:16:27 +0000 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 02:16:27 +0000 | finn_elija | FinnElija |
| 2022-10-04 02:17:25 +0000 | dumptruckman | (~dumptruck@45-33-69-234.ip.linodeusercontent.com) |
| 2022-10-04 02:17:34 +0000 | <jackdk> | https://www.youtube.com/watch?v=QVdBPvOOjBA is also a pretty neat talk about derivatives of regexes |
| 2022-10-04 02:19:40 +0000 | <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 02:20:54 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 265 seconds) |
| 2022-10-04 02:21:14 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 02:21:27 +0000 | _xor | (~xor@74.215.182.83) |
| 2022-10-04 02:22:03 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 02:22:33 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2022-10-04 02:23:29 +0000 | edrx | (~Eduardo@2804:56c:d2d3:4800:cf7d:b421:4c3a:392e) (Killed buffer) |
| 2022-10-04 02:34:46 +0000 | nate4 | (~nate@98.45.169.16) (Read error: Connection reset by peer) |
| 2022-10-04 02:34:48 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 02:34:56 +0000 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 02:35:24 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-04 02:41:59 +0000 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 02:45:20 +0000 | jargon | (~jargon@174-22-199-121.phnx.qwest.net) (Read error: Connection reset by peer) |
| 2022-10-04 02:46:33 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 02:47:46 +0000 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) |
| 2022-10-04 02:47:50 +0000 | dr_merijn | (~dr_merijn@86.86.29.250) |
| 2022-10-04 02:48:17 +0000 | lottaquestions | (~nick@2607:fa49:503e:7100:79b4:8afd:9b25:f433) (Quit: Konversation terminated!) |
| 2022-10-04 02:49:07 +0000 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 248 seconds) |
| 2022-10-04 02:54:44 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 02:55:15 +0000 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 2022-10-04 02:57:59 +0000 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-04 02:58:00 +0000 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-04 02:58:00 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-04 02:58:24 +0000 | img | (~img@user/img) |
| 2022-10-04 03:02:43 +0000 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-04 03:03:14 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-10-04 03:03:22 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 03:04:24 +0000 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 03:04:39 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 03:08:45 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds) |
| 2022-10-04 03:09:50 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-10-04 03:10:17 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-10-04 03:10:57 +0000 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Client Quit) |
| 2022-10-04 03:11:58 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 03:11:58 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 03:20:00 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) (Quit: bbl) |
| 2022-10-04 03:20:49 +0000 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-10-04 03:24:05 +0000 | twb | (~twb@2403:5804:c6::add) |
| 2022-10-04 03:24:32 +0000 | <twb> | Is there a better place to ask about gitit issues? |
| 2022-10-04 03:25:43 +0000 | <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 03:26:04 +0000 | <twb> | And also a few "Network.Socket.sendBuf: resource vanished (Broken pipe)" |
| 2022-10-04 03:26:49 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 03:27:16 +0000 | <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 03:28:13 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 03:29:49 +0000 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 03:32:16 +0000 | justsomeguy | (~justsomeg@47.201.160.8) |
| 2022-10-04 03:32:20 +0000 | justsomeguy | (~justsomeg@47.201.160.8) (Client Quit) |
| 2022-10-04 03:32:34 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-04 03:32:45 +0000 | img | (~img@user/img) |
| 2022-10-04 03:33:46 +0000 | <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 03:34:55 +0000 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 246 seconds) |
| 2022-10-04 03:37:16 +0000 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 265 seconds) |
| 2022-10-04 03:38:47 +0000 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-10-04 03:38:59 +0000 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:c9ff:16c0:a456:ab01) |
| 2022-10-04 03:46:25 +0000 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) (Read error: Connection reset by peer) |
| 2022-10-04 03:47:33 +0000 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-10-04 03:51:58 +0000 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) (Remote host closed the connection) |
| 2022-10-04 03:52:27 +0000 | <Axman6> | twb: I would've thought those were networking errors, not file errors |
| 2022-10-04 03:56:22 +0000 | <Axman6> | hmm, maybe not |
| 2022-10-04 03:56:58 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2022-10-04 03:57:16 +0000 | <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 03:57:37 +0000 | <twb> | i.e. I don't *think* there's anything like transient NFS outages involves |
| 2022-10-04 03:57:40 +0000 | <twb> | *involved |
| 2022-10-04 04:02:10 +0000 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) |
| 2022-10-04 04:11:57 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 04:17:09 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 250 seconds) |
| 2022-10-04 04:21:06 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 2022-10-04 04:24:38 +0000 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-10-04 04:25:39 +0000 | zaquest | (~notzaques@5.130.79.72) |
| 2022-10-04 04:29:49 +0000 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-10-04 04:31:42 +0000 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) |
| 2022-10-04 04:32:32 +0000 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) (Remote host closed the connection) |
| 2022-10-04 04:33:32 +0000 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-10-04 04:33:51 +0000 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) |
| 2022-10-04 04:34:12 +0000 | Vajb | (~Vajb@2001:999:504:1841:9e47:1ec7:a52e:1d57) |
| 2022-10-04 04:37:45 +0000 | relrod | (~relrod@redhat/ansible.staff.relrod) (Quit: .) |
| 2022-10-04 04:39:40 +0000 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 246 seconds) |
| 2022-10-04 04:39:41 +0000 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 2022-10-04 04:40:10 +0000 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) |
| 2022-10-04 04:40:25 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 04:44:40 +0000 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.6) |
| 2022-10-04 04:49:15 +0000 | razetime | (~quassel@117.254.35.18) |
| 2022-10-04 05:03:25 +0000 | <Axman6> | maybe strace can tell you something useful? |
| 2022-10-04 05:03:39 +0000 | <twb> | Good thinking |
| 2022-10-04 05:04:14 +0000 | <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 05:07:10 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 05:11:58 +0000 | chomwitt | (~chomwitt@2a02:587:dc14:f500:e5cf:fac1:d8f4:9053) |
| 2022-10-04 05:13:40 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 05:15:24 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 05:16:29 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 05:19:28 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) (Quit: To the moon and back) |
| 2022-10-04 05:20:13 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 05:21:51 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 05:21:53 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 252 seconds) |
| 2022-10-04 05:22:28 +0000 | danso | (~danso@danso.ca) (Quit: ZNC - https://znc.in) |
| 2022-10-04 05:25:07 +0000 | danso | (~danso@danso.ca) |
| 2022-10-04 05:27:36 +0000 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-10-04 05:29:39 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-10-04 05:44:12 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 05:46:40 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 05:48:35 +0000 | coot | (~coot@213.134.171.3) |
| 2022-10-04 05:50:33 +0000 | <sm> | anything in their issue tracker ? if not might be worth reporting |
| 2022-10-04 05:50:46 +0000 | <twb> | Not that I could see |
| 2022-10-04 05:51:19 +0000 | <twb> | I was hoping to solve it myself before reporting :-) |
| 2022-10-04 05:51:38 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 05:52:07 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) (Remote host closed the connection) |
| 2022-10-04 05:54:18 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 05:59:32 +0000 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 2022-10-04 05:59:58 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) (Remote host closed the connection) |
| 2022-10-04 06:00:31 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 06:01:01 +0000 | acidjnk_new | (~acidjnk@p200300d6e7137a36edbbd7fd5b13d5e1.dip0.t-ipconnect.de) |
| 2022-10-04 06:02:09 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 06:02:19 +0000 | k8yun_ | (~k8yun@user/k8yun) (Quit: Leaving) |
| 2022-10-04 06:06:39 +0000 | kenran | (~user@user/kenran) |
| 2022-10-04 06:10:11 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-04 06:13:51 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) (Ping timeout: 268 seconds) |
| 2022-10-04 06:14:16 +0000 | acidjnk_new | (~acidjnk@p200300d6e7137a36edbbd7fd5b13d5e1.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-04 06:15:44 +0000 | chomwitt | (~chomwitt@2a02:587:dc14:f500:e5cf:fac1:d8f4:9053) (Ping timeout: 268 seconds) |
| 2022-10-04 06:21:37 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-10-04 06:24:01 +0000 | razetime | (~quassel@117.254.35.18) (Ping timeout: 265 seconds) |
| 2022-10-04 06:24:30 +0000 | razetime | (~quassel@2401:4900:6298:84d:81f1:d694:dea5:362c) |
| 2022-10-04 06:27:07 +0000 | dr_merijn | (~dr_merijn@86.86.29.250) (Ping timeout: 246 seconds) |
| 2022-10-04 06:28:20 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) (Quit: ZzzZzz) |
| 2022-10-04 06:28:21 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 06:30:18 +0000 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-10-04 06:32:21 +0000 | razetime | (~quassel@2401:4900:6298:84d:81f1:d694:dea5:362c) (Ping timeout: 260 seconds) |
| 2022-10-04 06:34:00 +0000 | darkstardevx | (~darkstard@192.183.207.94) (Ping timeout: 264 seconds) |
| 2022-10-04 06:38:17 +0000 | Null_A | (~null_a@c-73-93-244-42.hsd1.ca.comcast.net) () |
| 2022-10-04 06:40:56 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-10-04 06:46:06 +0000 | ellensol | (~ellen@ua-84-216-129-63.bbcust.telenor.se) |
| 2022-10-04 06:49:07 +0000 | ellensol | (~ellen@ua-84-216-129-63.bbcust.telenor.se) (Read error: Connection reset by peer) |
| 2022-10-04 06:49:25 +0000 | michalz | (~michalz@185.246.207.197) |
| 2022-10-04 06:50:33 +0000 | BB[m] | (~cashmagem@2001:470:69fc:105::f6dc) |
| 2022-10-04 06:53:50 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 06:55:06 +0000 | MajorBiscuit | (~MajorBisc@c-001-001-038.client.tudelft.eduvpn.nl) |
| 2022-10-04 06:56:11 +0000 | chomwitt | (~chomwitt@2a02:587:dc14:f500:4d9:c26a:402f:bdab) |
| 2022-10-04 06:56:26 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:cbb9:efc2:3629:a341) |
| 2022-10-04 06:58:18 +0000 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2022-10-04 07:03:11 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 07:17:50 +0000 | mbuf | (~Shakthi@49.204.133.164) |
| 2022-10-04 07:17:56 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 07:19:49 +0000 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 07:21:39 +0000 | kenran | (~user@user/kenran) |
| 2022-10-04 07:27:01 +0000 | troydm | (~troydm@176.37.124.197) (Ping timeout: 244 seconds) |
| 2022-10-04 07:27:45 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-10-04 07:28:42 +0000 | nschoe | (~quassel@2a01:e0a:8e:a190:824d:1eb5:b8c7:3d88) |
| 2022-10-04 07:32:26 +0000 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds) |
| 2022-10-04 07:40:03 +0000 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-10-04 07:43:45 +0000 | acidjnk_new | (~acidjnk@p200300d6e7137a36b404354f0b8552f0.dip0.t-ipconnect.de) |
| 2022-10-04 07:46:25 +0000 | romes[m] | uploaded an image: (293KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/LeJhtBnxPwUVcicxsKtmUooK/image.png > |
| 2022-10-04 07:46:32 +0000 | <romes[m]> | my girlfriend made me this meme :) |
| 2022-10-04 07:47:54 +0000 | mmhat | (~mmh@p200300f1c700bd12ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-10-04 07:48:37 +0000 | RobertKrook | (~robert@ext-1-087.eduroam.chalmers.se) |
| 2022-10-04 07:48:51 +0000 | mmhat | (~mmh@p200300f1c700bd12ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit) |
| 2022-10-04 07:48:57 +0000 | <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 07:50:00 +0000 | <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 07:50:38 +0000 | <romes[m]> | but feel free to do that! |
| 2022-10-04 07:51:01 +0000 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 265 seconds) |
| 2022-10-04 07:51:49 +0000 | _xor | (~xor@74.215.182.83) (Quit: brb) |
| 2022-10-04 07:52:17 +0000 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-10-04 07:53:41 +0000 | m5zs7k | (aquares@web10.mydevil.net) |
| 2022-10-04 07:56:24 +0000 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-10-04 07:58:43 +0000 | <twb> | "Honey, I think we have to have... The Talk with the kids" |
| 2022-10-04 08:00:08 +0000 | razetime | (~quassel@117.254.35.128) |
| 2022-10-04 08:00:43 +0000 | <ski> | @quote sarah.peyton |
| 2022-10-04 08:00:44 +0000 | <lambdabot> | sarah says: "But I don't _want_ functional programming!" -- Sarah Peyton Jones, age 11, upon hearing the rules of Go |
| 2022-10-04 08:01:14 +0000 | <ski> | @quote please.talk |
| 2022-10-04 08:01:14 +0000 | <lambdabot> | Dave_Benjamin says: please talk to your son or daughter about parametric polymorphism |
| 2022-10-04 08:02:40 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-04 08:02:46 +0000 | <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 08:02:47 +0000 | rnat | (uid73555@id-73555.lymington.irccloud.com) |
| 2022-10-04 08:02:48 +0000 | dwt_ | (~dwt_@c-98-198-103-176.hsd1.tx.comcast.net) (Ping timeout: 264 seconds) |
| 2022-10-04 08:02:58 +0000 | mncheck | (~mncheck@193.224.205.254) |
| 2022-10-04 08:03:50 +0000 | <ski> | hehe :) |
| 2022-10-04 08:05:10 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 08:06:29 +0000 | rnat | (uid73555@id-73555.lymington.irccloud.com) () |
| 2022-10-04 08:06:44 +0000 | rnat | (uid73555@id-73555.lymington.irccloud.com) |
| 2022-10-04 08:10:07 +0000 | __monty__ | (~toonn@user/toonn) |
| 2022-10-04 08:11:05 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) |
| 2022-10-04 08:13:23 +0000 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2022-10-04 08:14:20 +0000 | rnat | (uid73555@id-73555.lymington.irccloud.com) () |
| 2022-10-04 08:14:40 +0000 | rnat | (uid73555@id-73555.lymington.irccloud.com) |
| 2022-10-04 08:15:42 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 08:15:55 +0000 | RobertKrook | (~robert@ext-1-087.eduroam.chalmers.se) (Quit: Lost terminal) |
| 2022-10-04 08:16:21 +0000 | <romes[m]> | Ahahahahah |
| 2022-10-04 08:22:54 +0000 | cheater | (~Username@user/cheater) |
| 2022-10-04 08:23:32 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2022-10-04 08:24:57 +0000 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-10-04 08:26:48 +0000 | wonko | (~wjc@2a0e:1c80:11::50) |
| 2022-10-04 08:33:15 +0000 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 08:33:16 +0000 | <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 08:33:55 +0000 | <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 08:36:23 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 08:37:25 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 08:37:35 +0000 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 250 seconds) |
| 2022-10-04 08:38:27 +0000 | lys | rosalind |
| 2022-10-04 08:39:26 +0000 | vegetabelfodos | (~vegetabel@user/vegetabelfodos) |
| 2022-10-04 08:39:45 +0000 | <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 08:41:02 +0000 | <c_wraith> | phma: but also, that code is kind of... not using par correctly. or seq. |
| 2022-10-04 08:41:19 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 08:42:53 +0000 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-10-04 08:42:55 +0000 | <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 08:42:57 +0000 | razetime | (~quassel@117.254.35.128) (Remote host closed the connection) |
| 2022-10-04 08:43:13 +0000 | <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 08:44:03 +0000 | <phma> | ordering of what? |
| 2022-10-04 08:44:07 +0000 | <twb> | Is this for pedagogy, or production? For production I *strongly* recommend using a standard crypto library rather than DIY |
| 2022-10-04 08:44:36 +0000 | <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 08:44:56 +0000 | <dminuoso> | Though for what its worth, even GHC internally uses `seq` in plenty of places where they should use `pseq` instead. |
| 2022-10-04 08:45:33 +0000 | <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 08:45:50 +0000 | <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 08:46:04 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-04 08:46:15 +0000 | <c_wraith> | dminuoso: it's less about parallel and more that seq a b can decide to evaluate b first. |
| 2022-10-04 08:46:21 +0000 | <phma> | CSE? |
| 2022-10-04 08:46:28 +0000 | <c_wraith> | common subexpression elimination |
| 2022-10-04 08:46:33 +0000 | <phma> | ah |
| 2022-10-04 08:46:35 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 08:46:38 +0000 | <dminuoso> | Also, if you want guaranteed sharing, use {-# NOINLINE foo #-} |
| 2022-10-04 08:46:45 +0000 | <dminuoso> | Otherwise you are at the mercy of the simplifier |
| 2022-10-04 08:46:47 +0000 | <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 08:46:59 +0000 | <c_wraith> | I don't. phma does. :P |
| 2022-10-04 08:47:07 +0000 | <twb> | Oh sorry. |
| 2022-10-04 08:47:18 +0000 | <twb> | https://en.wikipedia.org/wiki/Side-channel_attack |
| 2022-10-04 08:47:43 +0000 | <dminuoso> | twb: phma has been discussion cryptography on and off for a while and they appear to be a student. |
| 2022-10-04 08:47:59 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 08:48:12 +0000 | <twb> | Righto |
| 2022-10-04 08:48:16 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 2022-10-04 08:49:09 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 08:50:25 +0000 | kuribas | (~user@ptr-17d51emyfmo4vkmz9ge.18120a2.ip6.access.telenet.be) |
| 2022-10-04 08:50:36 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 260 seconds) |
| 2022-10-04 08:51:15 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 08:52:16 +0000 | <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 08:52:41 +0000 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 08:53:25 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 246 seconds) |
| 2022-10-04 08:54:51 +0000 | <twb> | Could you simply have another green thread that generates and throws away computation at random? |
| 2022-10-04 08:55:03 +0000 | <twb> | I guess that would help with power but not timing |
| 2022-10-04 08:57:32 +0000 | <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 08:58:00 +0000 | <phma> | The code that climbs the ladder should take a lot longer than the code that makes the ladder. |
| 2022-10-04 08:58:47 +0000 | <phma> | When it's actually encrypting something, that is. In the unit test, the operation is integer addition. |
| 2022-10-04 09:04:24 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-04 09:05:48 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 09:05:50 +0000 | Hidlegunst | (~Hidleguns@fw-pmc.sorbonne-universite.fr) |
| 2022-10-04 09:07:15 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 09:08:29 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 09:09:15 +0000 | <dminuoso> | phma: before defeating a side channel, you should perhaps start by demonstrating a side channel to begin with. |
| 2022-10-04 09:09:29 +0000 | burnsidesLlama | (~burnsides@client-8-89.eduroam.oxuni.org.uk) |
| 2022-10-04 09:09:55 +0000 | <dminuoso> | If you recall my previous remarks, that's precisely the problem. It has not even been demonstrated either way. |
| 2022-10-04 09:10:36 +0000 | <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 09:10:50 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 09:11:13 +0000 | <dminuoso> | If you want to improve your impact factor, you can even aim for publishable research. |
| 2022-10-04 09:11:16 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 09:12:59 +0000 | rosalind | lys |
| 2022-10-04 09:13:20 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds) |
| 2022-10-04 09:13:41 +0000 | lys | (lys@id-194105.uxbridge.irccloud.com) () |
| 2022-10-04 09:15:46 +0000 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-04 09:16:03 +0000 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 09:16:15 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 09:20:35 +0000 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 252 seconds) |
| 2022-10-04 09:30:07 +0000 | <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 09:30:38 +0000 | ellensol_ | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 09:30:44 +0000 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) (Quit: leaving) |
| 2022-10-04 09:33:37 +0000 | gmg | (~user@user/gehmehgeh) |
| 2022-10-04 09:38:00 +0000 | DavidBinder | (~DavidBind@134.2.10.18) |
| 2022-10-04 09:38:39 +0000 | ellensol_ | (~ellen@emp-85-192.eduroam.uu.se) (Ping timeout: 268 seconds) |
| 2022-10-04 09:38:55 +0000 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 246 seconds) |
| 2022-10-04 09:39:57 +0000 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-04 09:41:08 +0000 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) |
| 2022-10-04 09:41:39 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 09:43:23 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 09:46:11 +0000 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 09:46:30 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 09:48:23 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 268 seconds) |
| 2022-10-04 09:54:35 +0000 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 09:55:43 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:cbb9:efc2:3629:a341) (Ping timeout: 246 seconds) |
| 2022-10-04 09:55:58 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 09:59:08 +0000 | ellensol | (~ellen@emp-85-192.eduroam.uu.se) (Quit: leaving) |
| 2022-10-04 10:00:15 +0000 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 10:00:26 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 10:01:02 +0000 | dr_merijn | (~dr_merijn@86.86.29.250) |
| 2022-10-04 10:04:28 +0000 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 246 seconds) |
| 2022-10-04 10:05:40 +0000 | Hidlegunst | (~Hidleguns@fw-pmc.sorbonne-universite.fr) (Quit: nyaa~) |
| 2022-10-04 10:11:28 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-04 10:12:43 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 10:14:01 +0000 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 260 seconds) |
| 2022-10-04 10:15:10 +0000 | <probie> | Is there a way to silence a single "redundant constraint" warning, when the constraint isn't really redundant? |
| 2022-10-04 10:16:03 +0000 | vglfr | (~vglfr@145.224.100.164) (Read error: Connection reset by peer) |
| 2022-10-04 10:16:04 +0000 | <geekosaur> | not presently |
| 2022-10-04 10:16:39 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 10:16:48 +0000 | <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 10:17:28 +0000 | <probie> | (where `F :: [Type] -> Maybe ([Type], Type, [Type])`) |
| 2022-10-04 10:19:33 +0000 | DavidBinder | (~DavidBind@134.2.10.18) (Remote host closed the connection) |
| 2022-10-04 10:20:22 +0000 | kdaishi | (~Thunderbi@dyn3137-209.wlan.ic.ac.uk) |
| 2022-10-04 10:21:20 +0000 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 265 seconds) |
| 2022-10-04 10:24:46 +0000 | kdaishi | (~Thunderbi@dyn3137-209.wlan.ic.ac.uk) (Ping timeout: 268 seconds) |
| 2022-10-04 10:26:18 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 10:31:00 +0000 | twb | (~twb@2403:5804:c6::add) (Ping timeout: 264 seconds) |
| 2022-10-04 10:31:22 +0000 | ubert | (~Thunderbi@91.141.46.118.wireless.dyn.drei.com) |
| 2022-10-04 10:31:58 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 10:32:06 +0000 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2022-10-04 10:33:01 +0000 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-04 10:33:16 +0000 | <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 10:33:23 +0000 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-10-04 10:33:33 +0000 | <dminuoso> | And the mission was successful. No feature was implemented that, in the future, is going to be broken. |
| 2022-10-04 10:34:02 +0000 | <dminuoso> | (But honestly I think that issue is just forgotten now) |
| 2022-10-04 10:34:07 +0000 | ubert | (~Thunderbi@91.141.46.118.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-10-04 10:34:44 +0000 | <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 10:35:04 +0000 | <dminuoso> | Oh it was 18 years old. |
| 2022-10-04 10:35:16 +0000 | <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 10:35:21 +0000 | <dminuoso> | https://gitlab.haskell.org/ghc/ghc/-/issues/602 |
| 2022-10-04 10:35:30 +0000 | <geekosaur> | (option for JSON output instead of text, message numbers to facilitate documentation, etc.) |
| 2022-10-04 10:35:31 +0000 | <dminuoso> | (There's a whole bunch of related issues, but this is the original core issue) |
| 2022-10-04 10:37:16 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 10:37:19 +0000 | twb | (~twb@2403:5804:c6::add) |
| 2022-10-04 10:39:01 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 10:40:51 +0000 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-10-04 10:43:02 +0000 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-10-04 10:43:34 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 10:45:48 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 10:54:07 +0000 | beteigeuze | (~Thunderbi@89.187.168.45) |
| 2022-10-04 10:55:32 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 11:01:00 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 264 seconds) |
| 2022-10-04 11:03:14 +0000 | burnsidesLlama | (~burnsides@client-8-89.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 11:04:31 +0000 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-10-04 11:04:37 +0000 | vglfr | (~vglfr@145.224.100.164) |
| 2022-10-04 11:08:35 +0000 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Quit: Leaving.) |
| 2022-10-04 11:09:02 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 11:10:34 +0000 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-10-04 11:14:09 +0000 | __monty__ | (~toonn@user/toonn) |
| 2022-10-04 11:14:27 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 250 seconds) |
| 2022-10-04 11:17:27 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-04 11:19:34 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 11:19:40 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds) |
| 2022-10-04 11:24:16 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 11:26:26 +0000 | vglfr | (~vglfr@145.224.100.164) (Ping timeout: 268 seconds) |
| 2022-10-04 11:27:53 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 11:28:35 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 248 seconds) |
| 2022-10-04 11:32:04 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-10-04 11:32:26 +0000 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 11:36:09 +0000 | img | (~img@user/img) |
| 2022-10-04 11:38:06 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-10-04 11:38:56 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6f76:5354:52c9:73a2) |
| 2022-10-04 11:39:36 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds) |
| 2022-10-04 11:41:52 +0000 | <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 11:42:15 +0000 | <dminuoso> | And running `runGet` for each small chunk seems like overkill |
| 2022-10-04 11:43:14 +0000 | <Hecate> | dminuoso: and then what? why don't you also ask for meaningful error messages while you're at it? :P |
| 2022-10-04 11:43:42 +0000 | <dminuoso> | Error messages are under my full control already anyway |
| 2022-10-04 11:44:09 +0000 | <dminuoso> | All the useful diagnostics are not on the protocol decoding level, but higher (like "Attribute XYZ not known") |
| 2022-10-04 11:44:35 +0000 | <Hecate> | dminuoso: who Attoparsec be more appropriate in your usecase? |
| 2022-10-04 11:45:26 +0000 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-04 11:45:30 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 11:46:04 +0000 | <dminuoso> | I thought about it, but it its a poor match. This is a low level binary protocol. |
| 2022-10-04 11:46:13 +0000 | <dminuoso> | The only advantage attoparsec has for me, is being able to use `optional` with it |
| 2022-10-04 11:46:25 +0000 | <dminuoso> | Oh huh wow hold on. |
| 2022-10-04 11:46:31 +0000 | <dminuoso> | Get has Alternative/MonadPlus too |
| 2022-10-04 11:46:40 +0000 | <Hecate> | ;-D |
| 2022-10-04 11:46:43 +0000 | <dminuoso> | Then attoparsec has no advantage. |
| 2022-10-04 11:46:47 +0000 | <Hecate> | ok |
| 2022-10-04 11:48:44 +0000 | <dminuoso> | Maybe Ill just put `ExceptT DecodeError` ontop of Get, and carefully avoid using primitives that may `fail` the parser. |
| 2022-10-04 11:48:51 +0000 | <dminuoso> | mmm |
| 2022-10-04 11:49:59 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 250 seconds) |
| 2022-10-04 11:52:05 +0000 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2022-10-04 11:54:37 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 11:56:22 +0000 | lyle | (~lyle@104.246.145.85) |
| 2022-10-04 11:56:36 +0000 | pavonia | (~user@user/siracusa) |
| 2022-10-04 11:56:57 +0000 | <raehik> | dminuoso: It's a stretch but my pkg binrep is built on flatparse so is nice and fast? |
| 2022-10-04 11:57:24 +0000 | wonko | (~wjc@2a0e:1c80:11::50) (Ping timeout: 264 seconds) |
| 2022-10-04 11:57:26 +0000 | <raehik> | Problem being, there is very little error handling, and flatparse makes you do it yourself |
| 2022-10-04 11:58:05 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 12:02:22 +0000 | <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 12:02:50 +0000 | <Hecate> | https://flora.pm/packages/@hackage/binrep nice indeed! |
| 2022-10-04 12:03:33 +0000 | <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 12:03:56 +0000 | <dminuoso> | I *was* looking for a strict bytestring alternative without that internal streamingmechanism |
| 2022-10-04 12:04:17 +0000 | <dminuoso> | newtype Parser e a = Parser {runParser# :: ForeignPtrContents -> Addr# -> Addr# -> Res# e a} |
| 2022-10-04 12:04:19 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 12:04:23 +0000 | <dminuoso> | I was on the brink of constructing this myself. |
| 2022-10-04 12:04:36 +0000 | <dminuoso> | Yes this is lovely. :)\ |
| 2022-10-04 12:04:36 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 264 seconds) |
| 2022-10-04 12:05:06 +0000 | <raehik> | it's a wonderful pkg from András Kovács and I wish it was used more! |
| 2022-10-04 12:05:16 +0000 | <dminuoso> | raehik: No actually, *this* solves my problems |
| 2022-10-04 12:05:30 +0000 | <dminuoso> | This parser is so evidently absurdly cheap, that I can just takeBs and re-run a nested Parser |
| 2022-10-04 12:05:36 +0000 | yaroot | (~yaroot@p2790051-ipngn7801souka.saitama.ocn.ne.jp) (Remote host closed the connection) |
| 2022-10-04 12:05:40 +0000 | <dminuoso> | There wont even be a copy of the bytestring. |
| 2022-10-04 12:06:05 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 12:06:09 +0000 | yaroot | (~yaroot@p2790051-ipngn7801souka.saitama.ocn.ne.jp) |
| 2022-10-04 12:06:25 +0000 | <raehik> | yeah :D |
| 2022-10-04 12:07:17 +0000 | <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 12:07:23 +0000 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-04 12:07:48 +0000 | <dminuoso> | Recoverable failure, non-recovereable failure. It has all. |
| 2022-10-04 12:07:51 +0000 | <dminuoso> | Thank you raehik! |
| 2022-10-04 12:08:23 +0000 | <dminuoso> | Now I just neet a flatpack put equivalent. :p |
| 2022-10-04 12:08:25 +0000 | <raehik> | I'm very glad to help!! |
| 2022-10-04 12:08:50 +0000 | <dminuoso> | Or do you happen to know a Put equivalent of flatparse? |
| 2022-10-04 12:08:52 +0000 | <raehik> | dminuoso: you mean a serializer? haha https://hackage.haskell.org/package/mason |
| 2022-10-04 12:09:15 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-10-04 12:09:27 +0000 | <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 12:09:30 +0000 | <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 12:10:38 +0000 | <dminuoso> | Though mmm. mason *does* have a constant buffer mechanism |
| 2022-10-04 12:12:11 +0000 | <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 12:13:06 +0000 | <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 12:13:46 +0000 | <raehik> | similarly, there is Mason.Builder.primBounded for BoundedPrim |
| 2022-10-04 12:14:45 +0000 | <dminuoso> | Yeah I think this might fit the bill. |
| 2022-10-04 12:15:49 +0000 | <dminuoso> | utting :: Parser e a -> e -> (e -> e -> e) -> Parser e a |
| 2022-10-04 12:15:58 +0000 | <dminuoso> | Oh yeah, flatparse is definitely exactly what I want. |
| 2022-10-04 12:17:24 +0000 | <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 12:18:01 +0000 | <raehik> | "nice" as in lots of speed and a simplified lib I suppose |
| 2022-10-04 12:22:43 +0000 | dr_merijn | (~dr_merijn@86.86.29.250) (Ping timeout: 246 seconds) |
| 2022-10-04 12:24:35 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 12:26:15 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-10-04 12:26:43 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 12:26:43 +0000 | <dminuoso> | But for putting, I think I will eventually just write my own version of Put |
| 2022-10-04 12:26:52 +0000 | <dminuoso> | While mason is certainly nice, it has too much baggage I really dont care for |
| 2022-10-04 12:28:20 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) |
| 2022-10-04 12:31:29 +0000 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 258 seconds) |
| 2022-10-04 12:35:27 +0000 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-04 12:36:32 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 12:39:05 +0000 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2022-10-04 12:39:20 +0000 | kdaishi | (~Thunderbi@2a0c:5bc0:40:2e2f:b6bb:664c:380b:dc65) (Ping timeout: 268 seconds) |
| 2022-10-04 12:41:14 +0000 | rnat | (uid73555@id-73555.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 12:41:30 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 12:46:26 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds) |
| 2022-10-04 12:48:06 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 12:48:40 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 12:52:57 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 12:53:06 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 265 seconds) |
| 2022-10-04 13:04:00 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 13:05:51 +0000 | zebrag | (~chris@user/zebrag) |
| 2022-10-04 13:08:26 +0000 | _73 | (~user@2600:4040:5aa2:2000:ccdd:de39:6c57:78f9) (Remote host closed the connection) |
| 2022-10-04 13:08:35 +0000 | _73 | (~user@pool-173-76-236-42.bstnma.fios.verizon.net) |
| 2022-10-04 13:10:32 +0000 | frost | (~frost@user/frost) (Ping timeout: 252 seconds) |
| 2022-10-04 13:10:43 +0000 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-04 13:11:48 +0000 | vegetabelfodos | billcosby |
| 2022-10-04 13:14:34 +0000 | stackdroid18 | (~stackdroi@user/stackdroid) |
| 2022-10-04 13:15:29 +0000 | billcosby | (~vegetabel@user/vegetabelfodos) (Quit: quit) |
| 2022-10-04 13:17:42 +0000 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-10-04 13:18:22 +0000 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 246 seconds) |
| 2022-10-04 13:18:40 +0000 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-04 13:19:18 +0000 | acidjnk_new | (~acidjnk@p200300d6e7137a36b404354f0b8552f0.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-10-04 13:20:01 +0000 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2022-10-04 13:20:41 +0000 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 13:21:14 +0000 | dontdieych | (~quassel@146.56.130.54) |
| 2022-10-04 13:23:11 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 13:23:33 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 13:26:50 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 13:30:03 +0000 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 13:34:40 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) |
| 2022-10-04 13:35:30 +0000 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-04 13:35:41 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 13:38:25 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-10-04 13:39:24 +0000 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 264 seconds) |
| 2022-10-04 13:39:30 +0000 | dsrt^ | (~dsrt@c-76-17-6-165.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2022-10-04 13:40:11 +0000 | son0p | (~ff@181.136.122.143) (Ping timeout: 252 seconds) |
| 2022-10-04 13:49:50 +0000 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: leaving) |
| 2022-10-04 13:50:29 +0000 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
| 2022-10-04 13:57:16 +0000 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 13:58:13 +0000 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-10-04 13:58:45 +0000 | Joao003 | (~Joao003@187.85.87.16) |
| 2022-10-04 14:01:26 +0000 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 268 seconds) |
| 2022-10-04 14:05:41 +0000 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 14:06:14 +0000 | dontdieych | (~quassel@146.56.130.54) |
| 2022-10-04 14:09:08 +0000 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) |
| 2022-10-04 14:11:32 +0000 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-10-04 14:11:32 +0000 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-10-04 14:11:32 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2022-10-04 14:13:47 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:6f76:5354:52c9:73a2) (Quit: WeeChat 2.8) |
| 2022-10-04 14:14:11 +0000 | kenran | (~user@user/kenran) |
| 2022-10-04 14:17:25 +0000 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-10-04 14:18:26 +0000 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 14:19:08 +0000 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2022-10-04 14:21:23 +0000 | echoone | (~echoone@2a02:8109:a1c0:5d05:e839:fba:d2ce:cf82) |
| 2022-10-04 14:21:24 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 264 seconds) |
| 2022-10-04 14:21:25 +0000 | biberu\ | (~biberu@user/biberu) |
| 2022-10-04 14:22:06 +0000 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-10-04 14:24:33 +0000 | biberu | (~biberu@user/biberu) (Ping timeout: 252 seconds) |
| 2022-10-04 14:24:33 +0000 | biberu\ | biberu |
| 2022-10-04 14:24:44 +0000 | dontdieych | (~quassel@146.56.130.54) |
| 2022-10-04 14:26:09 +0000 | Joao003 | (~Joao003@187.85.87.16) (Quit: Client closed) |
| 2022-10-04 14:30:31 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2022-10-04 14:37:36 +0000 | dcoutts_ | (~duncan@host86-177-125-45.range86-177.btcentralplus.com) (Remote host closed the connection) |
| 2022-10-04 14:37:46 +0000 | Joao003 | (~Joao003@187.85.87.16) |
| 2022-10-04 14:37:53 +0000 | dcoutts_ | (~duncan@host86-177-125-45.range86-177.btcentralplus.com) |
| 2022-10-04 14:37:57 +0000 | Joao003 | (~Joao003@187.85.87.16) (Client Quit) |
| 2022-10-04 14:38:18 +0000 | inversed | (~inversed@90.209.137.56) (Read error: Connection reset by peer) |
| 2022-10-04 14:39:04 +0000 | inversed | (~inversed@90.209.137.56) |
| 2022-10-04 14:40:08 +0000 | infinity0 | (~infinity0@185.112.146.113) (Ping timeout: 268 seconds) |
| 2022-10-04 14:41:09 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 250 seconds) |
| 2022-10-04 14:41:40 +0000 | davean | (~davean@davean.sciesnet.net) (Ping timeout: 246 seconds) |
| 2022-10-04 14:41:58 +0000 | davean | (~davean@davean.sciesnet.net) |
| 2022-10-04 14:42:09 +0000 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) (Ping timeout: 252 seconds) |
| 2022-10-04 14:44:36 +0000 | dontdieych | (~quassel@146.56.130.54) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 14:45:43 +0000 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-10-04 14:45:50 +0000 | infinity0 | (~infinity0@185.112.146.113) |
| 2022-10-04 14:45:51 +0000 | MajorBiscuit | (~MajorBisc@c-001-001-038.client.tudelft.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2022-10-04 14:47:25 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 14:48:21 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-10-04 14:51:49 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 246 seconds) |
| 2022-10-04 14:55:39 +0000 | TonyStone | (~TonyStone@cpe-74-76-51-197.nycap.res.rr.com) |
| 2022-10-04 15:02:23 +0000 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 15:09:34 +0000 | dontdieych | (~quassel@132.226.169.184) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 15:10:09 +0000 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 15:10:12 +0000 | dontdieych | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 15:10:45 +0000 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 15:15:19 +0000 | dontdieych | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 15:16:41 +0000 | Kaipei | Kaiepi |
| 2022-10-04 15:18:19 +0000 | stackdroid18 | (~stackdroi@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-10-04 15:23:22 +0000 | jmtd | Jon |
| 2022-10-04 15:24:17 +0000 | crns | (~netcrns@user/crns) (Quit: gone) |
| 2022-10-04 15:24:36 +0000 | crns | (~netcrns@p4ff5e871.dip0.t-ipconnect.de) |
| 2022-10-04 15:24:36 +0000 | crns | (~netcrns@p4ff5e871.dip0.t-ipconnect.de) (Changing host) |
| 2022-10-04 15:24:36 +0000 | crns | (~netcrns@user/crns) |
| 2022-10-04 15:25:52 +0000 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-10-04 15:28:37 +0000 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Quit: WeeChat 3.6) |
| 2022-10-04 15:35:33 +0000 | mmhat | (~mmh@p200300f1c71ac65eee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-10-04 15:36:16 +0000 | acidjnk_new | (~acidjnk@p54ad5adb.dip0.t-ipconnect.de) |
| 2022-10-04 15:37:03 +0000 | shapr | (~user@68.54.166.125) (Ping timeout: 250 seconds) |
| 2022-10-04 15:40:20 +0000 | vglfr | (~vglfr@145.224.100.190) (Ping timeout: 265 seconds) |
| 2022-10-04 15:41:25 +0000 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-04 15:41:28 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 15:42:46 +0000 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 15:43:21 +0000 | tobiasBora | (~tobiasBor@2001:861:3381:7880:b41b:ebe4:a7ea:5772) |
| 2022-10-04 15:44:16 +0000 | <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 15:45:16 +0000 | <geekosaur> | --nix just means to use a nix-shell |
| 2022-10-04 15:45:36 +0000 | <geekosaur> | if you don't need one to access dependencies, you don't need --nix |
| 2022-10-04 15:45:58 +0000 | ellensol | (~ln@pc-ellar188.it.uu.se) |
| 2022-10-04 15:48:56 +0000 | son0p | (~ff@181.136.122.143) (Remote host closed the connection) |
| 2022-10-04 15:57:10 +0000 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-10-04 15:57:28 +0000 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2022-10-04 16:01:23 +0000 | levitating | (~irc@user/levitating) () |
| 2022-10-04 16:01:42 +0000 | <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 16:02:36 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 16:02:57 +0000 | <geekosaur> | usually it means non-Haskell dependencies |
| 2022-10-04 16:03:11 +0000 | <geekosaur> | stack wants to control ghc and Haskell dependencies itself |
| 2022-10-04 16:04:12 +0000 | echoone | (~echoone@2a02:8109:a1c0:5d05:e839:fba:d2ce:cf82) (Quit: Client closed) |
| 2022-10-04 16:05:37 +0000 | <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 16:06:49 +0000 | <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 16:06:57 +0000 | <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 16:07:00 +0000 | <geekosaur> | since it can rely on nix to provide them |
| 2022-10-04 16:07:52 +0000 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-10-04 16:07:55 +0000 | <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 16:08:02 +0000 | <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 16:08:21 +0000 | <tobiasBora> | ok thanks |
| 2022-10-04 16:08:45 +0000 | <geekosaur> | anywayloo0ks like that's from 2019 |
| 2022-10-04 16:09:06 +0000 | <geekosaur> | in 2022 stack has figured out which of its ghcs to use on nixos |
| 2022-10-04 16:09:57 +0000 | <tobiasBora> | ok good. So in 2022 --nix is not needed unless I have some non-haskell deps I want to use. |
| 2022-10-04 16:10:53 +0000 | <tobiasBora> | Btw if you have a reference (commit…) for this statement "in 2022…" I'd love to have it :-) |
| 2022-10-04 16:11:33 +0000 | <geekosaur> | you said it worked, that's all the proof I need 🙂 |
| 2022-10-04 16:11:47 +0000 | <geekosaur> | (I'm not a stack user and don't follow it that closely) |
| 2022-10-04 16:13:07 +0000 | <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 16:13:38 +0000 | elkcl_ | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) |
| 2022-10-04 16:14:54 +0000 | <geekosaur> | that would not tell stack which ghc bindist to install on nixos |
| 2022-10-04 16:15:14 +0000 | cyphase | (~cyphase@user/cyphase) |
| 2022-10-04 16:15:17 +0000 | <geekosaur> | I believe that's a stack data file that it downloads from a central repository |
| 2022-10-04 16:15:19 +0000 | massimo_zaniboni | (~quassel@mail.asterisell.com) |
| 2022-10-04 16:15:43 +0000 | shane | (~shane@ana.rch.ist) (Ping timeout: 268 seconds) |
| 2022-10-04 16:16:13 +0000 | shane | (~shane@ana.rch.ist) |
| 2022-10-04 16:16:22 +0000 | nschoe | (~quassel@2a01:e0a:8e:a190:824d:1eb5:b8c7:3d88) (Ping timeout: 268 seconds) |
| 2022-10-04 16:17:56 +0000 | <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 16:18:23 +0000 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-04 16:20:23 +0000 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 16:21:12 +0000 | davean | (~davean@davean.sciesnet.net) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | inversed | (~inversed@90.209.137.56) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | zxx7529 | (~Thunderbi@user/zxx7529) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | Sgeo | (~Sgeo@user/sgeo) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | lyle | (~lyle@104.246.145.85) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | mncheck | (~mncheck@193.224.205.254) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | coot | (~coot@213.134.171.3) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | alphabeta | (~kilolympu@213.144.144.24) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | ystael | (~ystael@user/ystael) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | [Leary] | (~Leary]@user/Leary/x-0910699) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | cods | (~fred@82-65-232-44.subs.proxad.net) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | Guest1698 | (~Guest1698@20.83.116.49) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | Ranhir | (~Ranhir@157.97.53.139) (*.net *.split) |
| 2022-10-04 16:21:12 +0000 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | zero | (~z@user/zero) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | JimL | (~quassel@89-162-2-132.fiber.signal.no) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | glguy | (~glguy@libera/staff-emeritus/glguy) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | joeyh | (~joeyh@kitenet.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | sympt | (~sympt@user/sympt) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | mesaoptimizer | (apotheosis@user/PapuaHardyNet) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | WarzoneCommand | (~Frank@77-162-168-71.fixed.kpn.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Logio | (em@kapsi.fi) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | pgray__ | (~pgray@c-24-143-114-36.customer.broadstripe.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | auri | (~auri@fsf/member/auri) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | tomboy64 | (~tomboy64@user/tomboy64) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | asm | (~alexander@user/asm) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | res0nat0r084490 | (~Fletch@dia.whatbox.ca) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Maja | (~quassel@178-37-215-128.adsl.inetia.pl) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | haskl | (~haskl@user/haskl) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | GoldsteinQ | (~goldstein@goldstein.rs) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | zachel | (~zachel@user/zachel) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | wagle | (~wagle@quassel.wagle.io) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | int-e | (~noone@int-e.eu) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | foul_owl | (~kerry@174-21-75-230.tukw.qwest.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | taeaad | (~taeaad@user/taeaad) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Zemyla | (~ec2-user@ec2-54-80-174-150.compute-1.amazonaws.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | adium | (adium@user/adium) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | hexology | (~hexology@user/hexology) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | anderson | (~ande@user/anderson) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Square | (~a@user/square) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Aleksejs | (~Aleksejs@107.170.21.106) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | mht-wtf | (~mht@2a03:b0c0:3:e0::1e2:c001) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | robertm | (robertm@lattice.rojoma.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | bwe_ | (~bwe@2a01:4f8:1c1c:4878::2) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | laman1 | (~laman@rego.ai) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | vjoki | (~vjoki@2a00:d880:3:1::fea1:9ae) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | gmc | (sid58314@id-58314.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | hendi | (sid489601@id-489601.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | glowcoil | (sid3405@id-3405.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | bbhoss | (sid18216@id-18216.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | sajith | (~sajith@user/sajith) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Jon | (jon@dow.land) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | acertain | (sid470584@id-470584.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | lally | (sid388228@id-388228.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | flukiluke | (~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | jocke-l | (jocke-l@a.x0.is) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | dexter1 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | Franciman | (~Franciman@mx1.fracta.dev) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | beaky | (~beaky@2a03:b0c0:0:1010::1e:a001) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | gregberns__ | (sid315709@id-315709.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | dy | (sid3438@user/dy) (*.net *.split) |
| 2022-10-04 16:21:13 +0000 | lexi-lambda | (sid92601@id-92601.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | dyniec | (~dyniec@mail.dybiec.info) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | liskin | (~liskin@xmonad/liskin) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | reda_ | (~reda@user/reda) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | incertia | (~incertia@d47-69-133-171.try.wideopenwest.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | h2t_ | (~h2t@user/h2t) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | SoF | (~skius@user/skius) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | PHO` | (~pho@akari.cielonegro.org) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Firedancer | (sid336191@id-336191.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | bjs | (sid190364@user/bjs) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | carter | (sid14827@id-14827.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | dpratt | (sid193493@id-193493.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | teehemkay_ | (sid14792@id-14792.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | hongminhee | (sid295@id-295.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | caasih | (sid13241@id-13241.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | bradparker | (sid262931@id-262931.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | dsal | (sid13060@id-13060.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | davetapley_ | (sid666@id-666.uxbridge.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | whez | (sid470288@id-470288.lymington.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | bookshelfdave | (sid28102@id-28102.ilkley.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | ario_ | (~ario@159.65.220.102) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | onosendi | (sid552923@user/onosendi) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Ekho | (~Ekho@user/ekho) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | tomjaguarpaw | (~tom@li367-225.members.linode.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Xe | (~cadey@tailscale/xe) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | kaskal | (~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | DigitalKiwi | (~kiwi@137.184.156.191) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | asivitz | (uid178348@id-178348.tinside.irccloud.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | elkcl | (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | lagash_ | (lagash@lagash.shelltalk.net) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | megaTherion | (~therion@unix.io) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | gff_ | (~gff@user/gff) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | FragByte | (~christian@user/fragbyte) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | piele | (~piele@tbonesteak.creativeserver.net) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | mzan | (~quassel@mail.asterisell.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | ddb | (~ddb@tilde.club) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Hafydd | (jc@user/hafydd) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | ajb | (~ajb@mimas.whatbox.ca) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | haasn | (~nand@haasn.dev) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | bjobjo | (~bjobjo@user/bjobjo) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Vq | (~vq@90-227-195-41-no77.tbcn.telia.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | cpli | (77fc530071@2604:bf00:561:2000::252) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | fvr | (ef3e56ca8b@2604:bf00:561:2000::3c4) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | sm2n | (ae95cb1267@user/sm2n) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | samhh | (7569f027cf@2604:bf00:561:2000::e4) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | natto | (~natto@140.238.225.67) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | wolfshappen | (~waff@irc.furworks.de) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | ell | (~ellie@user/ellie) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Inoperable | (~PLAYER_1@fancydata.science) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | tv | (~tv@user/tv) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | Igloo | (~ian@matrix.chaos.earth.li) (*.net *.split) |
| 2022-10-04 16:21:14 +0000 | cross | (~cross@spitfire.i.gajendra.net) (*.net *.split) |
| 2022-10-04 16:21:15 +0000 | elkcl_ | elkcl |
| 2022-10-04 16:21:24 +0000 | CiaoSen | (~Jura@p200300c95700eb002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-10-04 16:22:52 +0000 | davean | (~davean@davean.sciesnet.net) |
| 2022-10-04 16:22:52 +0000 | inversed | (~inversed@90.209.137.56) |
| 2022-10-04 16:22:52 +0000 | zxx7529 | (~Thunderbi@user/zxx7529) |
| 2022-10-04 16:22:52 +0000 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) |
| 2022-10-04 16:22:52 +0000 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-10-04 16:22:52 +0000 | lyle | (~lyle@104.246.145.85) |
| 2022-10-04 16:22:52 +0000 | mncheck | (~mncheck@193.224.205.254) |
| 2022-10-04 16:22:52 +0000 | coot | (~coot@213.134.171.3) |
| 2022-10-04 16:22:52 +0000 | alphabeta | (~kilolympu@213.144.144.24) |
| 2022-10-04 16:22:52 +0000 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-10-04 16:22:52 +0000 | ystael | (~ystael@user/ystael) |
| 2022-10-04 16:22:52 +0000 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2022-10-04 16:22:52 +0000 | cods | (~fred@82-65-232-44.subs.proxad.net) |
| 2022-10-04 16:22:52 +0000 | Guest1698 | (~Guest1698@20.83.116.49) |
| 2022-10-04 16:22:52 +0000 | Ranhir | (~Ranhir@157.97.53.139) |
| 2022-10-04 16:22:52 +0000 | kaskal | (~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0) |
| 2022-10-04 16:22:52 +0000 | DigitalKiwi | (~kiwi@137.184.156.191) |
| 2022-10-04 16:22:52 +0000 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-10-04 16:22:52 +0000 | asivitz | (uid178348@id-178348.tinside.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | lagash_ | (lagash@lagash.shelltalk.net) |
| 2022-10-04 16:22:52 +0000 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2022-10-04 16:22:52 +0000 | megaTherion | (~therion@unix.io) |
| 2022-10-04 16:22:52 +0000 | gff_ | (~gff@user/gff) |
| 2022-10-04 16:22:52 +0000 | zero | (~z@user/zero) |
| 2022-10-04 16:22:52 +0000 | JimL | (~quassel@89-162-2-132.fiber.signal.no) |
| 2022-10-04 16:22:52 +0000 | FragByte | (~christian@user/fragbyte) |
| 2022-10-04 16:22:52 +0000 | joeyh | (~joeyh@kitenet.net) |
| 2022-10-04 16:22:52 +0000 | glguy | (~glguy@libera/staff-emeritus/glguy) |
| 2022-10-04 16:22:52 +0000 | sympt | (~sympt@user/sympt) |
| 2022-10-04 16:22:52 +0000 | piele | (~piele@tbonesteak.creativeserver.net) |
| 2022-10-04 16:22:52 +0000 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) |
| 2022-10-04 16:22:52 +0000 | ddb | (~ddb@tilde.club) |
| 2022-10-04 16:22:52 +0000 | mesaoptimizer | (apotheosis@user/PapuaHardyNet) |
| 2022-10-04 16:22:52 +0000 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2022-10-04 16:22:52 +0000 | WarzoneCommand | (~Frank@77-162-168-71.fixed.kpn.net) |
| 2022-10-04 16:22:52 +0000 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-10-04 16:22:52 +0000 | Logio | (em@kapsi.fi) |
| 2022-10-04 16:22:52 +0000 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2022-10-04 16:22:52 +0000 | pgray__ | (~pgray@c-24-143-114-36.customer.broadstripe.net) |
| 2022-10-04 16:22:52 +0000 | auri | (~auri@fsf/member/auri) |
| 2022-10-04 16:22:52 +0000 | Hafydd | (jc@user/hafydd) |
| 2022-10-04 16:22:52 +0000 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2022-10-04 16:22:52 +0000 | ajb | (~ajb@mimas.whatbox.ca) |
| 2022-10-04 16:22:52 +0000 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) |
| 2022-10-04 16:22:52 +0000 | haasn | (~nand@haasn.dev) |
| 2022-10-04 16:22:52 +0000 | bjobjo | (~bjobjo@user/bjobjo) |
| 2022-10-04 16:22:52 +0000 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2022-10-04 16:22:52 +0000 | Vq | (~vq@90-227-195-41-no77.tbcn.telia.com) |
| 2022-10-04 16:22:52 +0000 | wrengr | (~wrengr@201.59.83.34.bc.googleusercontent.com) |
| 2022-10-04 16:22:52 +0000 | cpli | (77fc530071@2604:bf00:561:2000::252) |
| 2022-10-04 16:22:52 +0000 | adium | (adium@user/adium) |
| 2022-10-04 16:22:52 +0000 | Zemyla | (~ec2-user@ec2-54-80-174-150.compute-1.amazonaws.com) |
| 2022-10-04 16:22:52 +0000 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2022-10-04 16:22:52 +0000 | taeaad | (~taeaad@user/taeaad) |
| 2022-10-04 16:22:52 +0000 | foul_owl | (~kerry@174-21-75-230.tukw.qwest.net) |
| 2022-10-04 16:22:52 +0000 | int-e | (~noone@int-e.eu) |
| 2022-10-04 16:22:52 +0000 | lambdabot | (~lambdabot@haskell/bot/lambdabot) |
| 2022-10-04 16:22:52 +0000 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) |
| 2022-10-04 16:22:52 +0000 | wagle | (~wagle@quassel.wagle.io) |
| 2022-10-04 16:22:52 +0000 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) |
| 2022-10-04 16:22:52 +0000 | zachel | (~zachel@user/zachel) |
| 2022-10-04 16:22:52 +0000 | GoldsteinQ | (~goldstein@goldstein.rs) |
| 2022-10-04 16:22:52 +0000 | haskl | (~haskl@user/haskl) |
| 2022-10-04 16:22:52 +0000 | Maja | (~quassel@178-37-215-128.adsl.inetia.pl) |
| 2022-10-04 16:22:52 +0000 | res0nat0r084490 | (~Fletch@dia.whatbox.ca) |
| 2022-10-04 16:22:52 +0000 | asm | (~alexander@user/asm) |
| 2022-10-04 16:22:52 +0000 | fvr | (ef3e56ca8b@2604:bf00:561:2000::3c4) |
| 2022-10-04 16:22:52 +0000 | sm2n | (ae95cb1267@user/sm2n) |
| 2022-10-04 16:22:52 +0000 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-10-04 16:22:52 +0000 | samhh | (7569f027cf@2604:bf00:561:2000::e4) |
| 2022-10-04 16:22:52 +0000 | natto | (~natto@140.238.225.67) |
| 2022-10-04 16:22:52 +0000 | wolfshappen | (~waff@irc.furworks.de) |
| 2022-10-04 16:22:52 +0000 | ell | (~ellie@user/ellie) |
| 2022-10-04 16:22:52 +0000 | Inoperable | (~PLAYER_1@fancydata.science) |
| 2022-10-04 16:22:52 +0000 | tv | (~tv@user/tv) |
| 2022-10-04 16:22:52 +0000 | Igloo | (~ian@matrix.chaos.earth.li) |
| 2022-10-04 16:22:52 +0000 | cross | (~cross@spitfire.i.gajendra.net) |
| 2022-10-04 16:22:52 +0000 | hays | (~rootveget@fsf/member/hays) |
| 2022-10-04 16:22:52 +0000 | Xe | (~cadey@tailscale/xe) |
| 2022-10-04 16:22:52 +0000 | tomjaguarpaw | (~tom@li367-225.members.linode.com) |
| 2022-10-04 16:22:52 +0000 | Ekho | (~Ekho@user/ekho) |
| 2022-10-04 16:22:52 +0000 | ario_ | (~ario@159.65.220.102) |
| 2022-10-04 16:22:52 +0000 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) |
| 2022-10-04 16:22:52 +0000 | bookshelfdave | (sid28102@id-28102.ilkley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | whez | (sid470288@id-470288.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | davetapley_ | (sid666@id-666.uxbridge.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | dsal | (sid13060@id-13060.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | bradparker | (sid262931@id-262931.uxbridge.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | b20n | (sid115913@id-115913.uxbridge.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | caasih | (sid13241@id-13241.ilkley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | onosendi | (sid552923@user/onosendi) |
| 2022-10-04 16:22:52 +0000 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | hongminhee | (sid295@id-295.tinside.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | sphynx | (~xnyhps@2a02:2770:3:0:216:3eff:fe67:3288) |
| 2022-10-04 16:22:52 +0000 | kevinsjoberg | (sid499516@id-499516.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | teehemkay_ | (sid14792@id-14792.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | lightandlight | (sid135476@id-135476.helmsley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | NemesisD | (sid24071@id-24071.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | dpratt | (sid193493@id-193493.helmsley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | carter | (sid14827@id-14827.helmsley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | bjs | (sid190364@user/bjs) |
| 2022-10-04 16:22:52 +0000 | joel135 | (sid136450@id-136450.hampstead.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | Firedancer | (sid336191@id-336191.hampstead.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | PHO` | (~pho@akari.cielonegro.org) |
| 2022-10-04 16:22:52 +0000 | SoF | (~skius@user/skius) |
| 2022-10-04 16:22:52 +0000 | h2t_ | (~h2t@user/h2t) |
| 2022-10-04 16:22:52 +0000 | incertia | (~incertia@d47-69-133-171.try.wideopenwest.com) |
| 2022-10-04 16:22:52 +0000 | reda_ | (~reda@user/reda) |
| 2022-10-04 16:22:52 +0000 | liskin | (~liskin@xmonad/liskin) |
| 2022-10-04 16:22:52 +0000 | dyniec | (~dyniec@mail.dybiec.info) |
| 2022-10-04 16:22:52 +0000 | dy | (sid3438@user/dy) |
| 2022-10-04 16:22:52 +0000 | lexi-lambda | (sid92601@id-92601.hampstead.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | gregberns__ | (sid315709@id-315709.helmsley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | beaky | (~beaky@2a03:b0c0:0:1010::1e:a001) |
| 2022-10-04 16:22:52 +0000 | Franciman | (~Franciman@mx1.fracta.dev) |
| 2022-10-04 16:22:52 +0000 | dexter1 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) |
| 2022-10-04 16:22:52 +0000 | jocke-l | (jocke-l@a.x0.is) |
| 2022-10-04 16:22:52 +0000 | flukiluke | (~m-7humut@2603:c023:c000:6c7e:8945:ad24:9113:a962) |
| 2022-10-04 16:22:52 +0000 | lally | (sid388228@id-388228.uxbridge.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | glowcoil | (sid3405@id-3405.tinside.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | acertain | (sid470584@id-470584.hampstead.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | Jon | (jon@dow.land) |
| 2022-10-04 16:22:52 +0000 | bbhoss | (sid18216@id-18216.tinside.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | hendi | (sid489601@id-489601.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | sajith | (~sajith@user/sajith) |
| 2022-10-04 16:22:52 +0000 | gmc | (sid58314@id-58314.ilkley.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | laman1 | (~laman@rego.ai) |
| 2022-10-04 16:22:52 +0000 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 2022-10-04 16:22:52 +0000 | vjoki | (~vjoki@2a00:d880:3:1::fea1:9ae) |
| 2022-10-04 16:22:52 +0000 | bwe_ | (~bwe@2a01:4f8:1c1c:4878::2) |
| 2022-10-04 16:22:52 +0000 | robertm | (robertm@lattice.rojoma.com) |
| 2022-10-04 16:22:52 +0000 | mht-wtf | (~mht@2a03:b0c0:3:e0::1e2:c001) |
| 2022-10-04 16:22:52 +0000 | Aleksejs | (~Aleksejs@107.170.21.106) |
| 2022-10-04 16:22:52 +0000 | Square | (~a@user/square) |
| 2022-10-04 16:22:52 +0000 | hexology | (~hexology@user/hexology) |
| 2022-10-04 16:22:52 +0000 | anderson | (~ande@user/anderson) |
| 2022-10-04 16:22:52 +0000 | lieven | (~mal@ns2.wyrd.be) |
| 2022-10-04 16:22:52 +0000 | yahb2 | (~yahb2@2a01:4f8:c0c:5c7b::2) |
| 2022-10-04 16:22:52 +0000 | Guest585 | (~mike@user/feetwind) |
| 2022-10-04 16:22:52 +0000 | leah2 | (~leah@vuxu.org) |
| 2022-10-04 16:22:52 +0000 | lyxia | (~lyxia@poisson.chat) |
| 2022-10-04 16:22:52 +0000 | jimki | (~jmaki@gazorpazorp.fixme.fi) |
| 2022-10-04 16:22:52 +0000 | kronicmage | (user88019@neotame.csclub.uwaterloo.ca) |
| 2022-10-04 16:22:52 +0000 | iphy | (sid67735@id-67735.lymington.irccloud.com) |
| 2022-10-04 16:22:52 +0000 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-10-04 16:22:52 +0000 | farn | (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) |
| 2022-10-04 16:22:52 +0000 | nurupo | (~nurupo.ga@user/nurupo) |
| 2022-10-04 16:23:00 +0000 | SoF | (~skius@user/skius) (Max SendQ exceeded) |
| 2022-10-04 16:23:01 +0000 | CAT_S | (apic@brezn3.muc.ccc.de) (Max SendQ exceeded) |
| 2022-10-04 16:23:01 +0000 | sm2n | (ae95cb1267@user/sm2n) (Max SendQ exceeded) |
| 2022-10-04 16:23:01 +0000 | hays | (~rootveget@fsf/member/hays) (Max SendQ exceeded) |
| 2022-10-04 16:23:01 +0000 | wolfshappen | (~waff@irc.furworks.de) (Max SendQ exceeded) |
| 2022-10-04 16:23:13 +0000 | sm2n | (ae95cb1267@user/sm2n) |
| 2022-10-04 16:23:14 +0000 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-10-04 16:23:18 +0000 | SoF1 | (~skius@user/skius) |
| 2022-10-04 16:23:18 +0000 | wolfshappen | (~waff@irc.furworks.de) |
| 2022-10-04 16:24:00 +0000 | <tobiasBora> | geekosaur oh sure, but I am the one writting the nixos wiki (as I find the documentation really sparse) |
| 2022-10-04 16:24:10 +0000 | inversed | (~inversed@90.209.137.56) (Max SendQ exceeded) |
| 2022-10-04 16:24:36 +0000 | <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 16:29:08 +0000 | econo | (uid147250@user/econo) |
| 2022-10-04 16:30:54 +0000 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-10-04 16:32:15 +0000 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-10-04 16:32:42 +0000 | <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 16:33:38 +0000 | inversed | (~inversed@90.209.137.56) |
| 2022-10-04 16:34:25 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-04 16:35:18 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 16:36:12 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 16:37:33 +0000 | dontdieych_ | (~quassel@132.226.169.184) |
| 2022-10-04 16:40:01 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 16:40:51 +0000 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection) |
| 2022-10-04 16:41:46 +0000 | <tobiasBora> | ok thanks a lot! |
| 2022-10-04 16:41:54 +0000 | dontdieych_ | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 16:42:07 +0000 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) |
| 2022-10-04 16:44:55 +0000 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) |
| 2022-10-04 16:45:17 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 16:46:12 +0000 | dontdieych_ | (~quassel@132.226.169.184) |
| 2022-10-04 16:46:53 +0000 | dontdieych_ | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 16:48:00 +0000 | zxx7529 | (~Thunderbi@user/zxx7529) (Ping timeout: 265 seconds) |
| 2022-10-04 16:49:37 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 16:50:41 +0000 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Ping timeout: 260 seconds) |
| 2022-10-04 16:52:54 +0000 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 16:54:46 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-10-04 16:55:23 +0000 | Alex_test | (~al_test@94.233.240.222) (Quit: ;-) |
| 2022-10-04 16:55:32 +0000 | AlexZenon | (~alzenon@94.233.240.222) (Quit: ;-) |
| 2022-10-04 16:56:11 +0000 | AlexNoo | (~AlexNoo@94.233.240.222) (Quit: Leaving) |
| 2022-10-04 16:56:32 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 16:59:40 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection) |
| 2022-10-04 17:01:05 +0000 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-10-04 17:05:23 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 17:05:23 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-10-04 17:06:25 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 17:08:03 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 17:08:36 +0000 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 17:12:34 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 17:12:57 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 17:16:09 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-10-04 17:16:31 +0000 | AlexZenon | (~alzenon@94.233.240.222) |
| 2022-10-04 17:16:38 +0000 | AlexNoo | (~AlexNoo@94.233.240.222) |
| 2022-10-04 17:22:35 +0000 | Alex_test | (~al_test@94.233.240.222) |
| 2022-10-04 17:30:22 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-10-04 17:30:57 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 17:31:25 +0000 | massimo_zaniboni | mzan |
| 2022-10-04 17:32:33 +0000 | tobiasBora | (~tobiasBor@2001:861:3381:7880:b41b:ebe4:a7ea:5772) (Quit: Client closed) |
| 2022-10-04 17:32:50 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 17:33:21 +0000 | <dminuoso> | Is there a compact and efficient way to get a hexadecimal ASCII representation (Text or String) for a Word8? |
| 2022-10-04 17:33:55 +0000 | <dminuoso> | (0-padded if possible) |
| 2022-10-04 17:34:45 +0000 | <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 17:34:51 +0000 | <dminuoso> | But that's.. effort. :( |
| 2022-10-04 17:38:53 +0000 | <davean> | dminuoso: I spent some time optimizing that ages ago. |
| 2022-10-04 17:38:58 +0000 | <davean> | But compact? |
| 2022-10-04 17:39:08 +0000 | <davean> | miss has a fairly fast implimentation |
| 2022-10-04 17:39:51 +0000 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 17:40:18 +0000 | <dminuoso> | `miss` as in? |
| 2022-10-04 17:41:08 +0000 | <davean> | yes the package |
| 2022-10-04 17:41:14 +0000 | shapr | (~user@68.54.166.125) |
| 2022-10-04 17:41:25 +0000 | <davean> | I focused mroe on parsing it though |
| 2022-10-04 17:41:39 +0000 | <davean> | Sadly I never worked on breaking that stuff out |
| 2022-10-04 17:41:46 +0000 | <davean> | mlep should have a package |
| 2022-10-04 17:41:53 +0000 | dr_merijn | (~dr_merijn@86-86-29-250.fixed.kpn.net) |
| 2022-10-04 17:42:45 +0000 | <EvanR> | a table of 256 things? |
| 2022-10-04 17:43:10 +0000 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-10-04 17:43:34 +0000 | <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 17:43:40 +0000 | beteigeuze | (~Thunderbi@89.187.168.45) (Ping timeout: 246 seconds) |
| 2022-10-04 17:43:45 +0000 | <davean> | it VERY much depends on the surrounding code |
| 2022-10-04 17:43:50 +0000 | <EvanR> | Vector String, Vector Text |
| 2022-10-04 17:43:55 +0000 | <EvanR> | it's a constant table right |
| 2022-10-04 17:44:14 +0000 | <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 17:44:19 +0000 | <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 17:44:21 +0000 | <dminuoso> | Mmm |
| 2022-10-04 17:44:44 +0000 | <EvanR> | so it's too large... |
| 2022-10-04 17:44:46 +0000 | <dminuoso> | EvanR: Those suffer from indirection |
| 2022-10-04 17:44:47 +0000 | <davean> | EvanR: The nibble calculation part is like 10 assembly instructions, so it has a major size advantage. |
| 2022-10-04 17:45:08 +0000 | <davean> | it is slower than the lookup table though on desktop CPUs if you have a large loop |
| 2022-10-04 17:45:18 +0000 | <dminuoso> | I absolutely new how to do this in assembly |
| 2022-10-04 17:45:19 +0000 | <EvanR> | you said you wanted a String or Text so I'm not clear what is going on xD |
| 2022-10-04 17:45:29 +0000 | <dminuoso> | I want to pretty print mac addresses! |
| 2022-10-04 17:45:35 +0000 | <dminuoso> | :> |
| 2022-10-04 17:45:43 +0000 | <davean> | EvanR: Do you understand my explanation? |
| 2022-10-04 17:46:12 +0000 | <EvanR> | I understand this problem in the context of you are in a desert with nothing but 8 registers or something |
| 2022-10-04 17:46:32 +0000 | <davean> | Hum, thats not what I'm getting at |
| 2022-10-04 17:46:33 +0000 | <EvanR> | but like, if the goal is to construct a Text object |
| 2022-10-04 17:46:41 +0000 | <EvanR> | like, in the heap |
| 2022-10-04 17:46:59 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection) |
| 2022-10-04 17:47:11 +0000 | <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 17:47:19 +0000 | <dminuoso> | Rather than builder nonsense |
| 2022-10-04 17:47:26 +0000 | <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 17:47:53 +0000 | <dminuoso> | davean: It wouldnt necessarily pull everything into cache. |
| 2022-10-04 17:47:56 +0000 | <EvanR> | yeah I think I'm on the W of this XY |
| 2022-10-04 17:48:10 +0000 | <davean> | dminuoso: No, but has to pull the relivent parts, and memory latency cycles are intense |
| 2022-10-04 17:48:28 +0000 | <davean> | EvanR: Writes are buffered so you don't suffer any latency on them |
| 2022-10-04 17:48:49 +0000 | <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 17:48:58 +0000 | <davean> | dminuoso: exactly |
| 2022-10-04 17:49:28 +0000 | <davean> | even for a Sha1 you easily win on the calculation implimentation |
| 2022-10-04 17:49:33 +0000 | dontdieych_ | (~quassel@132.226.169.184) |
| 2022-10-04 17:49:40 +0000 | <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 17:49:43 +0000 | <davean> | The entire calculation fits inside a single memory latency |
| 2022-10-04 17:50:05 +0000 | dontdieych | (~quassel@132.226.169.184) (Ping timeout: 250 seconds) |
| 2022-10-04 17:50:32 +0000 | <EvanR> | ok 256 words and 256 utf8 different |
| 2022-10-04 17:50:38 +0000 | <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 17:52:02 +0000 | mbuf | (~Shakthi@49.204.133.164) (Remote host closed the connection) |
| 2022-10-04 17:54:57 +0000 | <EvanR> | how many words is a Text again, minimum xD |
| 2022-10-04 17:55:11 +0000 | <EvanR> | like 3 or 4 |
| 2022-10-04 17:55:16 +0000 | <davean> | EvanR: Why does that matter? |
| 2022-10-04 17:56:47 +0000 | <davean> | So its 2 words and a ByteArray# if you want to know |
| 2022-10-04 17:57:00 +0000 | <davean> | And a ByteArray is 2 Words and its contents |
| 2022-10-04 17:57:00 +0000 | <EvanR> | and while I still don't understand the goal, isn't everything in haskell doing indirections all the time |
| 2022-10-04 17:57:04 +0000 | <davean> | so min 5 |
| 2022-10-04 17:57:11 +0000 | <davean> | EvanR: Absolutely not! |
| 2022-10-04 17:57:17 +0000 | <davean> | where would you get that idea? |
| 2022-10-04 17:57:35 +0000 | <EvanR> | because my first approximation is that each expression is a heap object |
| 2022-10-04 17:57:51 +0000 | <EvanR> | accessed via a pointer |
| 2022-10-04 17:58:02 +0000 | <davean> | Oh god no |
| 2022-10-04 17:58:28 +0000 | <davean> | Thats what the big chunks are but no, not for anything hot unless you really screw up the optimizer |
| 2022-10-04 17:59:02 +0000 | <dminuoso> | https://gist.github.com/dminuoso/a49bd924e96c26fbd1d2869336bc6fc9 |
| 2022-10-04 17:59:06 +0000 | <davean> | Like using an existential |
| 2022-10-04 17:59:07 +0000 | <dminuoso> | I mean this was my first naive attempt |
| 2022-10-04 17:59:28 +0000 | <dminuoso> | Not entirely terrible, intToDigit is implemented very well |
| 2022-10-04 17:59:42 +0000 | <dminuoso> | Oh that final showHex is a typo of course. |
| 2022-10-04 17:59:55 +0000 | <davean> | Why are you doing DList and not poking the byte buffer directly? |
| 2022-10-04 18:00:35 +0000 | <dminuoso> | So this is an internal struggle right now with supporting both text pre 2.0 and post 2.0 |
| 2022-10-04 18:00:42 +0000 | <davean> | Also I think your better off doing a list directly in this case |
| 2022-10-04 18:00:45 +0000 | <dminuoso> | Now I could CPP this of course |
| 2022-10-04 18:00:56 +0000 | <dminuoso> | Yeah, I pondered about that too, Ill have to criterion this |
| 2022-10-04 18:01:24 +0000 | <dminuoso> | Just means I need to inline the showHex upper and lower part into the main list |
| 2022-10-04 18:01:30 +0000 | <dminuoso> | Then it would likely be better |
| 2022-10-04 18:01:49 +0000 | <davean> | https://hackage.haskell.org/package/text-2.0.1/docs/Data-Text.html#v:unpackCString-35- |
| 2022-10-04 18:02:13 +0000 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-10-04 18:02:17 +0000 | <davean> | er, you want the ascii version I think but you get the idea |
| 2022-10-04 18:02:35 +0000 | <davean> | Kinda the same thing here |
| 2022-10-04 18:02:36 +0000 | <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 18:03:16 +0000 | <davean> | Oh I've beaten it by like 2x with it. |
| 2022-10-04 18:03:19 +0000 | <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 18:04:06 +0000 | <davean> | dminuoso: you wanted compatible though :) |
| 2022-10-04 18:04:24 +0000 | <dminuoso> | Sure, the internal struggle is whether I want to use CPP or not |
| 2022-10-04 18:04:49 +0000 | <davean> | Yah I was avoiding CPP and version risks |
| 2022-10-04 18:05:48 +0000 | <dminuoso> | The version risks are not an issue |
| 2022-10-04 18:06:09 +0000 | <dminuoso> | I know to manage tight bounds |
| 2022-10-04 18:06:29 +0000 | <davean> | Why support pre 2.0 text at all? |
| 2022-10-04 18:06:40 +0000 | <dminuoso> | Because so many things have text < 2.0 bounds |
| 2022-10-04 18:06:46 +0000 | <davean> | like what? |
| 2022-10-04 18:06:54 +0000 | <dminuoso> | Fair chunks of hackage |
| 2022-10-04 18:06:59 +0000 | <dminuoso> | I dont quite recall |
| 2022-10-04 18:07:19 +0000 | <davean> | Its almost a year old |
| 2022-10-04 18:07:29 +0000 | <EvanR> | I'm pre 2.0 text. What changed? |
| 2022-10-04 18:07:36 +0000 | <dminuoso> | UTF16 -> UTF8 |
| 2022-10-04 18:07:41 +0000 | <geekosaur> | utf8 instead of some utf16 variant |
| 2022-10-04 18:07:41 +0000 | <EvanR> | oh nice |
| 2022-10-04 18:07:42 +0000 | <dminuoso> | For the internal representation |
| 2022-10-04 18:08:36 +0000 | <geekosaur> | I do have to wonder why so many things would have issues with text 2.0 |
| 2022-10-04 18:09:00 +0000 | <davean> | geekosaur: I didn't see much of any issues at all |
| 2022-10-04 18:09:00 +0000 | <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 18:09:07 +0000 | MajorBiscuit | (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Ping timeout: 248 seconds) |
| 2022-10-04 18:09:17 +0000 | <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 18:09:26 +0000 | <dminuoso> | And that thing constructs text buffers directly |
| 2022-10-04 18:09:38 +0000 | <dminuoso> | Or relies on its internal representation |
| 2022-10-04 18:09:49 +0000 | <geekosaur> | that said, there's the whole bounds thing |
| 2022-10-04 18:09:49 +0000 | <davean> | dminuoso: thats on Text 2.0 off hackage |
| 2022-10-04 18:10:03 +0000 | <dminuoso> | https://hackage.haskell.org/package/ip |
| 2022-10-04 18:10:10 +0000 | _73 | (~user@pool-173-76-236-42.bstnma.fios.verizon.net) (Remote host closed the connection) |
| 2022-10-04 18:10:11 +0000 | <dminuoso> | Nope, still on <1.3 |
| 2022-10-04 18:10:33 +0000 | <davean> | *off hackage* https://github.com/andrewthad/haskell-ip/commit/4bf13a8be73ddc0378cb5ea7ffb4cebfa20a7f96 |
| 2022-10-04 18:10:34 +0000 | <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 18:10:46 +0000 | <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 18:10:58 +0000 | <dminuoso> | davean: Ohh! That's new, nice. |
| 2022-10-04 18:11:22 +0000 | <geekosaur> | "switched some argument orders" ok, there's a good reason for <2 dependency |
| 2022-10-04 18:11:46 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 18:11:59 +0000 | <dminuoso> | This is going to be nice. :) |
| 2022-10-04 18:11:59 +0000 | <davean> | geekosaur: there is a compat package though |
| 2022-10-04 18:12:16 +0000 | <davean> | geekosaur: So you can just change an import |
| 2022-10-04 18:12:24 +0000 | <dminuoso> | With text-2.0 we will actually gain a *noticeable* speed up in our DNS automation. |
| 2022-10-04 18:12:37 +0000 | <davean> | dminuoso: Yah! So go Text 2.0 only |
| 2022-10-04 18:12:50 +0000 | <dminuoso> | I will wait for that change to hit hackage though. :) |
| 2022-10-04 18:13:05 +0000 | <davean> | dminuoso: Slap Andrew Martin about it |
| 2022-10-04 18:13:33 +0000 | <dminuoso> | Re dlist, you're right a list is way more sensible: https://gist.github.com/dminuoso/540361a14d721b430c4bd1f7b84b866a |
| 2022-10-04 18:14:05 +0000 | <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 18:14:25 +0000 | <dminuoso> | But `T.pack` is still _very_ fast for small lists |
| 2022-10-04 18:15:49 +0000 | <davean> | Sure |
| 2022-10-04 18:16:10 +0000 | <davean> | Also there are some pretty reliable optimizations for list building in GHC |
| 2022-10-04 18:16:17 +0000 | <davean> | I dobut you had to hand inline that |
| 2022-10-04 18:16:51 +0000 | <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 18:17:10 +0000 | <davean> | reasonable |
| 2022-10-04 18:17:26 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 18:17:43 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Remote host closed the connection) |
| 2022-10-04 18:18:49 +0000 | <davean> | dminuoso: Specificly I'd have done it via mconcat |
| 2022-10-04 18:18:56 +0000 | <davean> | (for reliability) |
| 2022-10-04 18:19:18 +0000 | <dminuoso> | Why would that be more reliable? |
| 2022-10-04 18:19:59 +0000 | <davean> | mconcat xss = [x | xs <- xss, x <- xs] |
| 2022-10-04 18:20:11 +0000 | <davean> | Thats a super inlinable construction that would ruin nofib if someone broke it |
| 2022-10-04 18:20:33 +0000 | <davean> | You'd have to break the core of the simplifier for it to happen |
| 2022-10-04 18:21:29 +0000 | <davean> | Your version is sorta the co of that |
| 2022-10-04 18:21:39 +0000 | <davean> | in that your version can have the shared parts lifted out |
| 2022-10-04 18:22:24 +0000 | <davean> | (See how that implimentation is directly a nested loop and just needs unrolling?) |
| 2022-10-04 18:22:29 +0000 | <dminuoso> | Im trying to imagine how you would use mconcat to that end. Mind giving me a pointer? |
| 2022-10-04 18:22:56 +0000 | <EvanR> | nofib? |
| 2022-10-04 18:22:57 +0000 | beteigeuze | (~Thunderbi@2001:8a0:61b5:6101:f0c:e4e3:bfdc:91df) |
| 2022-10-04 18:23:03 +0000 | <dminuoso> | EvanR: https://gitlab.haskell.org/ghc/nofib |
| 2022-10-04 18:23:26 +0000 | <davean> | EvanR: nofib is the benchmark suite GHC is optimized against |
| 2022-10-04 18:23:34 +0000 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.6) |
| 2022-10-04 18:23:41 +0000 | vglfr | (~vglfr@145.224.100.190) (Read error: Connection reset by peer) |
| 2022-10-04 18:24:09 +0000 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 2022-10-04 18:24:12 +0000 | <davean> | dminuoso: mconcat [showHex w1, ":", showHex w2, ":", ...] |
| 2022-10-04 18:24:54 +0000 | <dminuoso> | Outside of ":" it couldnt lift anything else out though |
| 2022-10-04 18:24:56 +0000 | <davean> | set showHex inlinable |
| 2022-10-04 18:25:00 +0000 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-04 18:25:17 +0000 | <davean> | dminuoso: you mean your version? I thought you were asking for my version |
| 2022-10-04 18:25:28 +0000 | <dminuoso> | No yours |
| 2022-10-04 18:25:38 +0000 | <dminuoso> | Or well, yes mine too |
| 2022-10-04 18:25:50 +0000 | <davean> | A compiler COULD do code deduplication on yours and regenerate showHex |
| 2022-10-04 18:26:15 +0000 | <davean> | Since you have the repeat code blocks |
| 2022-10-04 18:26:33 +0000 | <dminuoso> | Despite INLINE? |
| 2022-10-04 18:26:41 +0000 | fserucas | (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Client Quit) |
| 2022-10-04 18:26:45 +0000 | <davean> | https://gist.github.com/dminuoso/540361a14d721b430c4bd1f7b84b866a <-- no inline here |
| 2022-10-04 18:26:50 +0000 | <dminuoso> | Oh well I guess INLINE does *not* forbid subsequent passes to do CSE. |
| 2022-10-04 18:27:04 +0000 | <dminuoso> | Ahh that you mean |
| 2022-10-04 18:27:32 +0000 | <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 18:28:13 +0000 | <davean> | So it can fill execution units very well potentially |
| 2022-10-04 18:28:16 +0000 | moonsheep | (~user@user/moonsheep) |
| 2022-10-04 18:29:51 +0000 | <dminuoso> | Im still sadly missing a good mental model of how haskell code gets turned into assembly |
| 2022-10-04 18:30:22 +0000 | <dminuoso> | Or *machine code if you will |
| 2022-10-04 18:30:51 +0000 | <davean> | dminuoso: well uh yah, its complicated |
| 2022-10-04 18:30:52 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 18:31:05 +0000 | dontdieych_ | (~quassel@132.226.169.184) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-10-04 18:31:45 +0000 | <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 18:32:05 +0000 | <moonsheep> | oh boy, I've been there, and I ended up just giving up |
| 2022-10-04 18:33:10 +0000 | <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 18:34:26 +0000 | <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 18:34:43 +0000 | <dminuoso> | But Im really not sure how well that approximation is. |
| 2022-10-04 18:35:02 +0000 | <davean> | Its ... not terrible, it depends on the complexity. |
| 2022-10-04 18:35:07 +0000 | jespada | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-10-04 18:35:17 +0000 | jespada_ | (~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net) |
| 2022-10-04 18:36:12 +0000 | <davean> | dminuoso: Theres more to it than that, but yah |
| 2022-10-04 18:36:53 +0000 | dontdieych | (~quassel@132.226.169.184) |
| 2022-10-04 18:37:26 +0000 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-10-04 18:37:31 +0000 | <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 18:38:07 +0000 | geekosaur | tries to understand, but mostly the upper levels. codegen is uninteresting |
| 2022-10-04 18:38:20 +0000 | <geekosaur> | (usually) |
| 2022-10-04 18:38:25 +0000 | <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 18:38:53 +0000 | Guest112009 | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) |
| 2022-10-04 18:39:22 +0000 | <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 18:39:26 +0000 | <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 18:39:39 +0000 | <dminuoso> | And its usually also not economical to just think about performance and profile *when* a problem arises. |
| 2022-10-04 18:39:46 +0000 | <dminuoso> | EvanR: Absolutely. |
| 2022-10-04 18:40:00 +0000 | <davean> | EvanR: Very much so |
| 2022-10-04 18:40:04 +0000 | <dminuoso> | EvanR: I find that cache behavior is perhaps the single most predictable and tractable thing you can do! |
| 2022-10-04 18:40:12 +0000 | <davean> | Caches are all the same with a TINY number of variables |
| 2022-10-04 18:40:15 +0000 | <EvanR> | by what alien tech do you do that |
| 2022-10-04 18:40:27 +0000 | <davean> | EvanR: Huh?> |
| 2022-10-04 18:40:28 +0000 | <dminuoso> | Loading cache lines from memory is *absurdly* slow. Your CPU will stall for hundreds of cycles.. doing nothing. |
| 2022-10-04 18:40:34 +0000 | dontdieych | (~quassel@132.226.169.184) (Client Quit) |
| 2022-10-04 18:40:44 +0000 | <dminuoso> | (Ignoring the fine and grittier details of superscalar execution) |
| 2022-10-04 18:40:52 +0000 | <EvanR> | i know the principle, but you don't have like, "use cache here" instructions |
| 2022-10-04 18:40:59 +0000 | <dminuoso> | EvanR: You have. |
| 2022-10-04 18:41:00 +0000 | <EvanR> | that you can see or not see |
| 2022-10-04 18:41:10 +0000 | <davean> | You DO have use cache here, but also cache is ALWAYS used |
| 2022-10-04 18:41:12 +0000 | <dminuoso> | In Haskell you call these things unboxed/packed things. |
| 2022-10-04 18:41:23 +0000 | <EvanR> | >_> |
| 2022-10-04 18:41:24 +0000 | <dminuoso> | Using them directly influences caching behavior |
| 2022-10-04 18:41:26 +0000 | <davean> | well no, you have prefetch and fetch hints |
| 2022-10-04 18:41:33 +0000 | <davean> | but you can't not use cache on x86 |
| 2022-10-04 18:41:42 +0000 | <dminuoso> | well you can indirectly. :) |
| 2022-10-04 18:41:44 +0000 | <davean> | thats the ONLY place the execution units read from |
| 2022-10-04 18:41:46 +0000 | <EvanR> | yes it's an invisible benefactor |
| 2022-10-04 18:42:08 +0000 | <davean> | and all you have to do is reason about probability it is cycled out yet at a use site |
| 2022-10-04 18:42:24 +0000 | <EvanR> | where do you get the probability numbers? what do you compare them to? |
| 2022-10-04 18:42:25 +0000 | <davean> | And that comes down to addresses loaded and associtivity |
| 2022-10-04 18:42:31 +0000 | <davean> | This --^ |
| 2022-10-04 18:42:41 +0000 | zaquest | (~notzaques@5.130.79.72) (Ping timeout: 252 seconds) |
| 2022-10-04 18:42:52 +0000 | <EvanR> | does each computer come with a probability table |
| 2022-10-04 18:43:06 +0000 | vglfr | (~vglfr@145.224.100.190) (Ping timeout: 268 seconds) |
| 2022-10-04 18:43:12 +0000 | <[exa]> | EvanR: cache-oblivious algorithms are a thing |
| 2022-10-04 18:43:19 +0000 | <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 18:43:28 +0000 | <davean> | [exa]: I love those, but those do it via this |
| 2022-10-04 18:43:58 +0000 | <EvanR> | I can't remember if cache-oblivious is good or bad |
| 2022-10-04 18:44:19 +0000 | <davean> | cache oblivious means that no matter the cache, you'll be with a constant factor of optimal cache usage |
| 2022-10-04 18:44:23 +0000 | vglfr | (~vglfr@145.224.100.190) |
| 2022-10-04 18:44:26 +0000 | <davean> | to simplify it |
| 2022-10-04 18:44:29 +0000 | <[exa]> | davean: afaik the probability view of the cache is convertible to the owned unknown-cache-size |
| 2022-10-04 18:44:40 +0000 | <davean> | [exa]: well, and associtivity |
| 2022-10-04 18:44:43 +0000 | pavonia | (~user@user/siracusa) |
| 2022-10-04 18:44:44 +0000 | <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 18:45:12 +0000 | <[exa]> | d] run without OS |
| 2022-10-04 18:45:20 +0000 | <dminuoso> | d is the same as a here. |
| 2022-10-04 18:45:26 +0000 | <davean> | dminuoso: or you're on a CPU like Cell SPEs |
| 2022-10-04 18:45:28 +0000 | <[exa]> | ok :D |
| 2022-10-04 18:45:50 +0000 | <davean> | or a lot of ARMs have a program managed cache |
| 2022-10-04 18:46:02 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:5240:b54d:87d3:8846) |
| 2022-10-04 18:46:20 +0000 | <dminuoso> | That's just a weird way of phrasing x86 is the Python of CPUs. |
| 2022-10-04 18:46:22 +0000 | <dminuoso> | :p |
| 2022-10-04 18:46:46 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 258 seconds) |
| 2022-10-04 18:46:49 +0000 | <dminuoso> | Not great performance, questionable design, but a lot of people seem to... use it? |
| 2022-10-04 18:47:07 +0000 | <davean> | dminuoso: A lot of ARM cpus have both explicite and implicite cache sections |
| 2022-10-04 18:48:21 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-10-04 18:50:07 +0000 | <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 18:51:04 +0000 | <dminuoso> | EvanR: there is profilers like cachegrind |
| 2022-10-04 18:51:13 +0000 | <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 18:51:34 +0000 | <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 18:51:35 +0000 | <monochrom> | I was too busy learning modal logics and constructing Kripke examples / counterexamples, so you are all spared! >:) |
| 2022-10-04 18:51:40 +0000 | <davean> | What would have to happen for that NOT to be in cache? |
| 2022-10-04 18:51:56 +0000 | <davean> | 16 loads on a 16-way associative cache, by other threads, in between 2 instructions |
| 2022-10-04 18:52:18 +0000 | <EvanR> | where's the start of a cache line |
| 2022-10-04 18:53:28 +0000 | <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 18:53:30 +0000 | <int-e> | davean: well, you could get preempted |
| 2022-10-04 18:53:40 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2022-10-04 18:53:42 +0000 | <davean> | int-e: right, I was talking abotu that |
| 2022-10-04 18:53:56 +0000 | <davean> | int-e: Thats explicitely covered by what I said |
| 2022-10-04 18:53:57 +0000 | <dminuoso> | On virtually all modern x86 CPUs cache lines (all L1, L2 and L3) are 64 bytes |
| 2022-10-04 18:54:08 +0000 | <dminuoso> | On mod 64 boundaries |
| 2022-10-04 18:54:12 +0000 | <davean> | er, specificly 16 *aliased* loads |
| 2022-10-04 18:54:29 +0000 | <davean> | dminuoso: common cache line sizes are 32, 64, or 128 bytes |
| 2022-10-04 18:55:06 +0000 | <EvanR> | when you hear ghc's first generation fits in cache, is that L1 cache, or 1 cache line or |
| 2022-10-04 18:55:17 +0000 | <davean> | the z15 uses a 256 byte cache like |
| 2022-10-04 18:55:27 +0000 | <davean> | EvanR: L3 cache |
| 2022-10-04 18:56:03 +0000 | <dminuoso> | davean: For all of AMD processors (Zen, Zen2, Zen3), Intel processors (Xeon, Core) they are all 64 bytes. |
| 2022-10-04 18:56:27 +0000 | <dminuoso> | z15 is not x86/AMD64 |
| 2022-10-04 18:57:09 +0000 | <davean> | dminuoso: He asked where the start of a cache line is |
| 2022-10-04 18:57:35 +0000 | <davean> | 32 bytes will work on ARM too |
| 2022-10-04 18:57:42 +0000 | <davean> | which is a much more significant platform |
| 2022-10-04 18:57:55 +0000 | <davean> | (Most ARM is 64 bytes but not all) |
| 2022-10-04 18:59:51 +0000 | <davean> | here are ARMs with 32, 64, and 128 byte caches |
| 2022-10-04 19:00:04 +0000 | <dminuoso> | Unrelated, what are the necessary preconditions for foldr fusion to kick in, for something like `unpack bs = build (unpackFoldr bs)`? |
| 2022-10-04 19:00:14 +0000 | <dminuoso> | Is it sufficient that GHC inlines `unpack` into my code? |
| 2022-10-04 19:00:39 +0000 | <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 19:00:59 +0000 | <davean> | (A lot of the M and lower series are 32 byte) |
| 2022-10-04 19:12:52 +0000 | <davean> | dminuoso: you do networking equipment - do you not run your stuff on ARM CPUs a lot? |
| 2022-10-04 19:13:22 +0000 | <davean> | A lot of switches and such have those giant ARM CPU arrays |
| 2022-10-04 19:13:45 +0000 | <davean> | Some have MIPs still?! |
| 2022-10-04 19:13:50 +0000 | acidjnk_new | (~acidjnk@p54ad5adb.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-10-04 19:14:15 +0000 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) |
| 2022-10-04 19:15:44 +0000 | <darkling> | MIPS went handily from big workstations to embedded controllers quite nicely. :) |
| 2022-10-04 19:16:40 +0000 | <EvanR> | still haven't figured out what a MIP is and why MIPS has so many of them |
| 2022-10-04 19:16:51 +0000 | <davean> | EvanR: is that a joke? |
| 2022-10-04 19:16:53 +0000 | <EvanR> | yes |
| 2022-10-04 19:16:57 +0000 | rekahsoft | (~rekahsoft@142.189.68.220) (Ping timeout: 268 seconds) |
| 2022-10-04 19:17:20 +0000 | <sm> | they stockpiled them in secret |
| 2022-10-04 19:18:14 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 19:19:20 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-10-04 19:20:01 +0000 | codaraxis__ | (~codaraxis@user/codaraxis) |
| 2022-10-04 19:22:21 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:5240:b54d:87d3:8846) (Ping timeout: 260 seconds) |
| 2022-10-04 19:22:43 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 248 seconds) |
| 2022-10-04 19:24:03 +0000 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-10-04 19:24:06 +0000 | codaraxis___ | (~codaraxis@user/codaraxis) (Ping timeout: 260 seconds) |
| 2022-10-04 19:25:06 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 19:25:11 +0000 | ft | (~ft@p3e9bc57b.dip0.t-ipconnect.de) |
| 2022-10-04 19:27:13 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 19:28:34 +0000 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-10-04 19:29:27 +0000 | wonko | (~wjc@2a0e:1c80:11::50) |
| 2022-10-04 19:30:01 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:7209:4af1:2ab1:81b8) |
| 2022-10-04 19:32:18 +0000 | <phma> | In a stack project, should the *.cabal and *.lock files be committed or gitignored? |
| 2022-10-04 19:32:47 +0000 | motherfsck | (~motherfsc@user/motherfsck) (Quit: quit) |
| 2022-10-04 19:32:59 +0000 | <geekosaur> | *.cabal should be committed |
| 2022-10-04 19:35:08 +0000 | <phma> | they're generated from package.yaml and stack.yaml |
| 2022-10-04 19:35:28 +0000 | <davean> | yes, but they're required for the package to function. |
| 2022-10-04 19:35:39 +0000 | <davean> | And what is generated is critical |
| 2022-10-04 19:35:40 +0000 | <geekosaur> | package.yaml gets you only so far, and if you include the cabal file then cabal users can build it |
| 2022-10-04 19:35:55 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-04 19:36:02 +0000 | <davean> | It is absolutely a problem to not include the .cabal file |
| 2022-10-04 19:36:59 +0000 | <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 19:37:24 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 19:37:41 +0000 | <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 19:38:13 +0000 | <phma> | if I change the cabal file, but not package.yaml, stack changes it back |
| 2022-10-04 19:38:29 +0000 | hueso | (~root@user/hueso) |
| 2022-10-04 19:39:10 +0000 | <davean> | yes, it does |
| 2022-10-04 19:43:05 +0000 | <sm> | stack.yaml.lock might be overkill unless you found otherwise. Very few projects commit that |
| 2022-10-04 19:43:47 +0000 | <sm> | stack prioritized the cabal file if you change it directly. (And warns that the two are out of sync) |
| 2022-10-04 19:43:54 +0000 | <sm> | s/prioritized/prioritizes/ |
| 2022-10-04 19:44:18 +0000 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-04 19:44:29 +0000 | son0p | (~ff@181.136.122.143) (Ping timeout: 250 seconds) |
| 2022-10-04 19:45:16 +0000 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-04 19:47:57 +0000 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 252 seconds) |
| 2022-10-04 19:49:00 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 19:49:30 +0000 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-04 19:49:33 +0000 | lyle | (~lyle@104.246.145.85) (Quit: WeeChat 3.6) |
| 2022-10-04 19:50:18 +0000 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-04 19:51:46 +0000 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) |
| 2022-10-04 19:53:04 +0000 | kuribas | (~user@ptr-17d51emyfmo4vkmz9ge.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2022-10-04 19:58:29 +0000 | <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 19:58:32 +0000 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-10-04 19:58:39 +0000 | zeenk | (~zeenk@2a02:2f04:a20a:3e00:5712:52b0:ca1d:bc63) |
| 2022-10-04 19:59:34 +0000 | kenran | (~user@user/kenran) |
| 2022-10-04 19:59:44 +0000 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 20:00:16 +0000 | kenran | (~user@user/kenran) |
| 2022-10-04 20:00:42 +0000 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 20:01:14 +0000 | kenran | (~user@user/kenran) |
| 2022-10-04 20:02:11 +0000 | <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 20:02:28 +0000 | <dminuoso> | So its really mostly AMD64 in our datacenter. |
| 2022-10-04 20:05:46 +0000 | <dminuoso> | davean: Up until the past, much of the market was saturated by PowerPC really. |
| 2022-10-04 20:06:07 +0000 | <dminuoso> | At least the vendors I have been exposed to do not use ARM much |
| 2022-10-04 20:06:10 +0000 | <dminuoso> | Not in the past and not now |
| 2022-10-04 20:06:49 +0000 | <dminuoso> | Arista too uses x86 processors nowadays |
| 2022-10-04 20:07:04 +0000 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-10-04 20:07:12 +0000 | <dminuoso> | The only ARM-equipped hardware I know of is broadcom stuff |
| 2022-10-04 20:09:32 +0000 | _xor | (~xor@74.215.182.83) |
| 2022-10-04 20:10:00 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-04 20:12:39 +0000 | <mixphix> | hi. does anyone know where i can find the recent proposal (?) that expendad LambdaCase with \cases syntax? |
| 2022-10-04 20:12:49 +0000 | <mixphix> | my google fu is failing me |
| 2022-10-04 20:13:18 +0000 | <geekosaur> | https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst |
| 2022-10-04 20:13:38 +0000 | <mixphix> | thanks!! <3 |
| 2022-10-04 20:18:17 +0000 | <EvanR> | we finally get LambdaCase by default and now this? |
| 2022-10-04 20:18:34 +0000 | <EvanR> | can't wait until 2042 to get cases by default |
| 2022-10-04 20:18:42 +0000 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-10-04 20:18:47 +0000 | <yushyin> | \cases is a fun one |
| 2022-10-04 20:21:25 +0000 | <dminuoso> | EvanR: Sadly GHC2042 isn't available yet. The only time-travel we have is TardisT. |
| 2022-10-04 20:23:05 +0000 | kdaishi | (~Thunderbi@94.191.136.234.mobile.tre.se) (Read error: Connection reset by peer) |
| 2022-10-04 20:25:18 +0000 | <Lycurgus> | sadly, unfortunately, ima have to call dr_merijn to find out what's right for yous |
| 2022-10-04 20:25:21 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-10-04 20:29:13 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:7209:4af1:2ab1:81b8) (Ping timeout: 246 seconds) |
| 2022-10-04 20:29:57 +0000 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-10-04 20:30:26 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 20:33:56 +0000 | Guest112009 | (~bc@c-73-139-125-125.hsd1.fl.comcast.net) (Quit: Leaving) |
| 2022-10-04 20:47:40 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 20:53:23 +0000 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-10-04 20:57:58 +0000 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt juan@acm.org) |
| 2022-10-04 21:02:48 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-04 21:02:59 +0000 | chomwitt | (~chomwitt@2a02:587:dc14:f500:4d9:c26a:402f:bdab) (Ping timeout: 248 seconds) |
| 2022-10-04 21:04:13 +0000 | <EvanR> | is there any special cache orientation gotchas when it comes to SIMD like SSE2 operations |
| 2022-10-04 21:04:22 +0000 | <EvanR> | cache oriented |
| 2022-10-04 21:05:11 +0000 | <EvanR> | does that even use the same cache |
| 2022-10-04 21:07:52 +0000 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-10-04 21:11:24 +0000 | nschoe | (~quassel@2a01:e0a:8e:a190:b3be:cb6e:9642:a3bf) |
| 2022-10-04 21:11:24 +0000 | nschoe | (~quassel@2a01:e0a:8e:a190:b3be:cb6e:9642:a3bf) (Client Quit) |
| 2022-10-04 21:12:01 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-10-04 21:15:29 +0000 | causal | (~user@50.35.83.177) |
| 2022-10-04 21:17:33 +0000 | hays | (rootvegeta@fsf/member/hays) |
| 2022-10-04 21:17:54 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Remote host closed the connection) |
| 2022-10-04 21:19:00 +0000 | mmhat | (~mmh@p200300f1c71ac65eee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2022-10-04 21:20:23 +0000 | <mixphix> | yushyin: the `language-haskell` syntax highlighting doesn't support that yet, which is why i was asking! |
| 2022-10-04 21:23:35 +0000 | codaraxis___ | (~codaraxis@user/codaraxis) |
| 2022-10-04 21:23:44 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 21:27:11 +0000 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) |
| 2022-10-04 21:27:47 +0000 | codaraxis__ | (~codaraxis@user/codaraxis) (Ping timeout: 268 seconds) |
| 2022-10-04 21:28:04 +0000 | alphabeta | (~kilolympu@213.144.144.24) (Quit: See you later! :)) |
| 2022-10-04 21:29:35 +0000 | mikoto-chan | (~mikoto-ch@164.5.249.78) |
| 2022-10-04 21:29:41 +0000 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2022-10-04 21:32:07 +0000 | <dminuoso> | EvanR: cache is about memory not registers. |
| 2022-10-04 21:32:16 +0000 | mmhat | (~mmh@p200300f1c71ac6cfee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-10-04 21:32:50 +0000 | <dminuoso> | https://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Intel_Nehalem_arch.svg/1024px-Intel_Neha… |
| 2022-10-04 21:33:13 +0000 | <dminuoso> | This is a very decent architectural diagram that hopefully displays why SIMD is not different |
| 2022-10-04 21:33:26 +0000 | <dminuoso> | At least, again, on AMD64 processors like Intel Core or AMD Zen |
| 2022-10-04 21:33:33 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 21:33:51 +0000 | acidjnk_new | (~acidjnk@p200300d6e7137a8379ab296f9eafb66f.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-10-04 21:34:48 +0000 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2022-10-04 21:35:35 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 265 seconds) |
| 2022-10-04 21:37:38 +0000 | biberu | (~biberu@user/biberu) |
| 2022-10-04 21:38:54 +0000 | <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 21:39:14 +0000 | <dminuoso> | (that compilation happens right in the cpu itself in the decoders) |
| 2022-10-04 21:41:57 +0000 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-10-04 21:48:21 +0000 | mastarija | (~mastarija@2a05:4f46:e03:6000:f63b:c026:eeb8:e131) |
| 2022-10-04 21:49:43 +0000 | <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 21:51:22 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 21:54:23 +0000 | <dminuoso> | ls ^.. traverse . myGetter |
| 2022-10-04 21:55:01 +0000 | <dminuoso> | > [Just 1, Just 2] ^.. traverse . _Just |
| 2022-10-04 21:55:02 +0000 | <dminuoso> | > [Just 1, Just 2] ^.. traverse . _Just |
| 2022-10-04 21:55:05 +0000 | <lambdabot> | [1,2] |
| 2022-10-04 21:55:19 +0000 | titibandit | (~titibandi@xdsl-89-0-65-2.nc.de) (Remote host closed the connection) |
| 2022-10-04 21:56:41 +0000 | son0p | (~ff@181.136.122.143) |
| 2022-10-04 21:57:24 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 264 seconds) |
| 2022-10-04 21:57:26 +0000 | <c_wraith> | note that it *is* a bit different if the per-element lookup can fail |
| 2022-10-04 21:57:35 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-04 21:57:46 +0000 | <c_wraith> | but that's not relevant if you were using ^. before |
| 2022-10-04 21:58:07 +0000 | <c_wraith> | (unless you were using it really unusually) |
| 2022-10-04 21:58:29 +0000 | <dminuoso> | Mmm, can you build a Getter out of an AffineFold? |
| 2022-10-04 21:58:50 +0000 | <dminuoso> | % :t failing |
| 2022-10-04 21:58:51 +0000 | <yahb2> | <interactive>:1:1: error: ; • Variable not in scope: failing ; • Perhaps you meant ‘ceiling’ (imported from Prelude) |
| 2022-10-04 21:58:53 +0000 | <dminuoso> | :t failing |
| 2022-10-04 21:58:54 +0000 | <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 21:59:54 +0000 | <mastarija> | thanks |
| 2022-10-04 22:02:17 +0000 | mikoto-chan | (~mikoto-ch@164.5.249.78) (Ping timeout: 268 seconds) |
| 2022-10-04 22:02:47 +0000 | goig | (~goig@202.91.42.7) |
| 2022-10-04 22:02:53 +0000 | <goig> | What are the morphisms of the category of endofunctors? |
| 2022-10-04 22:03:08 +0000 | <goig> | How do we call a monoid in the category of sets? |
| 2022-10-04 22:06:41 +0000 | <dminuoso> | goig: morphisms in that category are just natural transformations |
| 2022-10-04 22:07:05 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-04 22:07:59 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-04 22:08:47 +0000 | <dminuoso> | Take note that the term `monoid` is just typical mathematical compact imprecision, that joke really reads as `a monad is a monoid in the monoidal category of endofunctors, equipped with a particular tensor. |
| 2022-10-04 22:09:05 +0000 | <dminuoso> | And a `monoid` in a `monoidal category` is a special construction with respect to that tensor |
| 2022-10-04 22:10:04 +0000 | <dminuoso> | The tensor in question for the joke is Endofunctor Componsition, represented as (:.:) |
| 2022-10-04 22:10:14 +0000 | mastarija | (~mastarija@2a05:4f46:e03:6000:f63b:c026:eeb8:e131) (Ping timeout: 268 seconds) |
| 2022-10-04 22:10:59 +0000 | <dminuoso> | It may be of interest, that other monoidal categories exist too. For example Applicative is the monoid of the monoidal category of Endofunctors, equipped with Day as its tensor. |
| 2022-10-04 22:11:15 +0000 | <dminuoso> | *An applicative is a monoid in the monoidal category... |
| 2022-10-04 22:12:04 +0000 | <goig> | The category of endofunctors should be monoidal if I understand it right |
| 2022-10-04 22:12:07 +0000 | <goig> | Day? |
| 2022-10-04 22:12:14 +0000 | ski | . o O ( <https://baldursgate.fandom.com/wiki/Tenser's_Transformation> ) |
| 2022-10-04 22:12:22 +0000 | <ski> | Day convolution |
| 2022-10-04 22:12:40 +0000 | <dminuoso> | data Day f g a = forall b c. Day (f b) (g c) (b -> c -> a) |
| 2022-10-04 22:13:27 +0000 | <ski> | <https://hackage.haskell.org/package/kan-extensions-5.2.5/docs/Data-Functor-Day.html> |
| 2022-10-04 22:13:52 +0000 | mmhat | (~mmh@p200300f1c71ac6cfee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.6) |
| 2022-10-04 22:14:44 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 265 seconds) |
| 2022-10-04 22:14:47 +0000 | <geekosaur> | "tenser", said the tensor… |
| 2022-10-04 22:14:49 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 22:15:34 +0000 | <dminuoso> | goig: Also being monoidal is not an intrinsic property of a category, just like being a semigroup is not an intrinsic property of an integer |
| 2022-10-04 22:15:51 +0000 | zeenk | (~zeenk@2a02:2f04:a20a:3e00:5712:52b0:ca1d:bc63) (Quit: Konversation terminated!) |
| 2022-10-04 22:16:12 +0000 | <monochrom> | I thought you would prefer functor composition so that you can envision join :: M∘M -> M as a binary operator. |
| 2022-10-04 22:16:16 +0000 | <dminuoso> | A monoidal Category is just any 3-tuple (C, ⊗, I) satisfying a bunch of laws. |
| 2022-10-04 22:16:43 +0000 | <dminuoso> | (And there may be multiple 3-tuples involving the same C) |
| 2022-10-04 22:18:00 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 2022-10-04 22:19:00 +0000 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:c9ff:16c0:a456:ab01) (Quit: caryhartline) |
| 2022-10-04 22:19:03 +0000 | <goig> | A monad then is a 3-tuple where the C is a category of endofunctors |
| 2022-10-04 22:19:40 +0000 | <dminuoso> | So (Hask, (:.:), Identity) is such an a monoidal category, it is the particular choice for the joke |
| 2022-10-04 22:20:21 +0000 | <dminuoso> | Where (:.:) is just endofunctor composition, so: (Maybe :.: IO) a ~~~ Maybe (IO a) |
| 2022-10-04 22:20:40 +0000 | <dminuoso> | ~~~ denoting equality up to isomorphism |
| 2022-10-04 22:20:47 +0000 | Guest41 | (~Guest41@181.229.251.140) |
| 2022-10-04 22:20:48 +0000 | mvk | (~mvk@2607:fea8:5ce3:8500::778c) (Ping timeout: 264 seconds) |
| 2022-10-04 22:20:58 +0000 | <goig> | Hmm, (:.:)? |
| 2022-10-04 22:20:59 +0000 | <monochrom> | OK I'm happy now. :) |
| 2022-10-04 22:21:09 +0000 | <goig> | oh |
| 2022-10-04 22:21:21 +0000 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2022-10-04 22:21:22 +0000 | <dminuoso> | It's just an operator style newtype constructor |
| 2022-10-04 22:21:25 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-10-04 22:22:04 +0000 | <dminuoso> | > newtype (:.:) f g p = Comp { unComp :: f (g p) } |
| 2022-10-04 22:22:06 +0000 | <lambdabot> | <hint>:1:1: error: parse error on input ‘newtype’ |
| 2022-10-04 22:22:07 +0000 | <dminuoso> | @let newtype (:.:) f g p = Comp { unComp :: f (g p) } |
| 2022-10-04 22:22:08 +0000 | <lambdabot> | Defined. |
| 2022-10-04 22:23:15 +0000 | <dminuoso> | goig: Its really the same as function composition, except at the type level (except it works only up to isomorphism, `Maybe (IO a)` is not the actual same type as `(Maybe :.: IO) a` |
| 2022-10-04 22:23:23 +0000 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-04 22:23:26 +0000 | <dminuoso> | At any rate |
| 2022-10-04 22:24:05 +0000 | <goig> | "Frankly I don't think category theory is particularly useful. It is do abstracted that it can describe everything, but at the same time conclude nothing" What's your take on their statement? |
| 2022-10-04 22:24:28 +0000 | Guest41 | (~Guest41@181.229.251.140) (Client Quit) |
| 2022-10-04 22:25:48 +0000 | <hpc> | i constantly find myself wishing for Monad in other languages to make some specific thing or another easier to write |
| 2022-10-04 22:26:19 +0000 | <dminuoso> | goig: So just a short glimpse, without going the painful details of the construction, demonstrating the laws, and so on: |
| 2022-10-04 22:26:38 +0000 | <dminuoso> | a monoid in the monoidal category of (C, (:.:), Identity) is equipped with two natural transformations: |
| 2022-10-04 22:26:49 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) |
| 2022-10-04 22:26:56 +0000 | <dminuoso> | μ: M ⊗ M → M |
| 2022-10-04 22:27:10 +0000 | <dminuoso> | μ: M :.: M → M |
| 2022-10-04 22:27:21 +0000 | <dminuoso> | η : Identity -> M |
| 2022-10-04 22:27:32 +0000 | <dminuoso> | Since these are natural transformations, we can reprsent them in Haskell too |
| 2022-10-04 22:28:05 +0000 | <qrpnxz> | idk about category theory, but are not the type classes in haskell undoubtedly useful? |
| 2022-10-04 22:28:12 +0000 | <dminuoso> | % type (~>) f g = forall a. f a -> f a |
| 2022-10-04 22:28:13 +0000 | <yahb2> | <interactive>:224:6: error: ; Illegal declaration of a type or class operator ‘~>’ ; Use TypeOperators to declare operators in type and declarations |
| 2022-10-04 22:28:18 +0000 | <dminuoso> | % :set -XTypeOperators |
| 2022-10-04 22:28:19 +0000 | <yahb2> | <interactive>:1:1: error: Not in scope: ‘Yahb2Defs.limitedPrint’ |
| 2022-10-04 22:28:25 +0000 | <dminuoso> | @let type (~>) f g = forall a. f a -> f a |
| 2022-10-04 22:28:26 +0000 | <lambdabot> | Defined. |
| 2022-10-04 22:28:28 +0000 | <dminuoso> | Here. |
| 2022-10-04 22:28:34 +0000 | <dminuoso> | So in haskell terms we can now say: |
| 2022-10-04 22:28:47 +0000 | <dminuoso> | μ :: M :.: M ~> M |
| 2022-10-04 22:28:53 +0000 | <dminuoso> | η : Identity ~> M |
| 2022-10-04 22:29:06 +0000 | <dminuoso> | And it turns out, these are exactly the two methods of monad |
| 2022-10-04 22:29:11 +0000 | <dminuoso> | > :t join |
| 2022-10-04 22:29:12 +0000 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2022-10-04 22:29:13 +0000 | <dminuoso> | :t join |
| 2022-10-04 22:29:14 +0000 | <lambdabot> | Monad m => m (m a) -> m a |
| 2022-10-04 22:29:33 +0000 | <goig> | `η : Identity -> M` Isn't identity an object? |
| 2022-10-04 22:29:44 +0000 | <dminuoso> | Hold on, its a natural transformation |
| 2022-10-04 22:29:49 +0000 | <dminuoso> | Observe that m (m a) ~~~ (m :.: m) a |
| 2022-10-04 22:29:52 +0000 | <ski> | in this instance, `Identity' is a functor |
| 2022-10-04 22:30:07 +0000 | <ski> | (which is an object, in the category of endofunctors) |
| 2022-10-04 22:30:13 +0000 | <dminuoso> | goig: In haskell lingo you would write: `forall a. Identity a -> M a` |
| 2022-10-04 22:30:20 +0000 | <dminuoso> | or given the above type synonym: Identity ~> M |
| 2022-10-04 22:30:31 +0000 | ski | idly wonders how much Haskell goig is familiar with |
| 2022-10-04 22:30:47 +0000 | <dminuoso> | :t join |
| 2022-10-04 22:30:48 +0000 | <lambdabot> | Monad m => m (m a) -> m a |
| 2022-10-04 22:30:54 +0000 | <dminuoso> | Observe that m (m a) ~~~ (m :.: m) a |
| 2022-10-04 22:31:00 +0000 | <dminuoso> | So we could thionk of join having the type signature: |
| 2022-10-04 22:31:08 +0000 | <dminuoso> | join :: (m :.: m) ~> m |
| 2022-10-04 22:31:14 +0000 | <dminuoso> | and similarly for `return` |
| 2022-10-04 22:31:16 +0000 | <dminuoso> | :t return |
| 2022-10-04 22:31:17 +0000 | <lambdabot> | Monad m => a -> m a |
| 2022-10-04 22:31:23 +0000 | <dminuoso> | Identity a ~~~ a |
| 2022-10-04 22:31:39 +0000 | burnsidesLlama | (~burnsides@client-8-86.eduroam.oxuni.org.uk) (Ping timeout: 265 seconds) |
| 2022-10-04 22:31:39 +0000 | <dminuoso> | So we can also write this as `Identity ~> m` |
| 2022-10-04 22:31:53 +0000 | <goig> | Iirc η is return in haskell |
| 2022-10-04 22:32:00 +0000 | <dminuoso> | Yes exactly |
| 2022-10-04 22:32:06 +0000 | <dminuoso> | And μ is just join |
| 2022-10-04 22:32:27 +0000 | <monochrom> | Yes join is a natural transformation. |
| 2022-10-04 22:32:37 +0000 | <goig> | Wait join? |
| 2022-10-04 22:32:43 +0000 | <dminuoso> | :t join |
| 2022-10-04 22:32:44 +0000 | <lambdabot> | Monad m => m (m a) -> m a |
| 2022-10-04 22:33:03 +0000 | <goig> | So :.: is >>= |
| 2022-10-04 22:33:07 +0000 | <dminuoso> | No |
| 2022-10-04 22:33:18 +0000 | <dminuoso> | `join` and `>>=` have the same power |
| 2022-10-04 22:33:38 +0000 | <dminuoso> | We could, in principle, define any Monad instance just in terms of `join` instead of (>>=) |
| 2022-10-04 22:33:51 +0000 | <monochrom> | So in a category of endofunctors using natural transformations for morphisms, you get to write "M :.: M -> M", the -> there is "generically a morphism in my category, oh but this means a natural transformation in my case". |
| 2022-10-04 22:34:25 +0000 | <dminuoso> | The reason you cant, and why join isnt even a method of typeclass is actually just a kind of accident and has to do with unrelated extensions. |
| 2022-10-04 22:34:31 +0000 | <dminuoso> | *of the typeclass Monad |
| 2022-10-04 22:35:12 +0000 | <dminuoso> | `join` used to be a method, but it had to be removed for reasons irrelevant to this discussion |
| 2022-10-04 22:35:26 +0000 | <goig> | I am still a bit confused about return tho. Identity is a particular object right? |
| 2022-10-04 22:35:35 +0000 | <dminuoso> | newtype Identity a = Identith a |
| 2022-10-04 22:35:37 +0000 | <dminuoso> | newtype Identity a = Identity a |
| 2022-10-04 22:35:41 +0000 | <dminuoso> | That's Identity . |
| 2022-10-04 22:35:47 +0000 | <ski> | goig : object of what ? |
| 2022-10-04 22:35:50 +0000 | <dminuoso> | It's is an endofunctor |
| 2022-10-04 22:35:55 +0000 | <monochrom> | I have doubts about that. join was not a method around 2000 when I was learning Haskell, and said extension didn't exist. |
| 2022-10-04 22:36:03 +0000 | <goig> | And M is a category. But there's only one identity object no? |
| 2022-10-04 22:36:52 +0000 | <ski> | `M' above is a monad |
| 2022-10-04 22:37:02 +0000 | <ski> | (not a category) |
| 2022-10-04 22:37:09 +0000 | <goig> | Newtype? |
| 2022-10-04 22:37:13 +0000 | <dminuoso> | goig: There is two different things we associate with the word "identity" here. |
| 2022-10-04 22:37:23 +0000 | <dminuoso> | goig: there is an identity with respect to the tensor (:.:) |
| 2022-10-04 22:37:27 +0000 | <monochrom> | M is an endofunctor. Identity is also an endofunctor. Both are objects in this context. |
| 2022-10-04 22:37:41 +0000 | <dminuoso> | that is, an identity on the *monoidal category* construction (which is Identity, with respect to (:.:)) |
| 2022-10-04 22:37:55 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 258 seconds) |
| 2022-10-04 22:38:23 +0000 | <dminuoso> | and there is an identity on the *monoid of the monoidal cagetory (of endofunctors)*, which happens to be a morphism (which in this case is a natural transformation) |
| 2022-10-04 22:40:02 +0000 | <goig> | Wait. So a monoid is an object in a monoidal category |
| 2022-10-04 22:40:13 +0000 | <monochrom> | No. |
| 2022-10-04 22:40:26 +0000 | <goig> | (Aka an object of C in (C,\otimes,I)) |
| 2022-10-04 22:40:49 +0000 | <dminuoso> | goig: "a monoid in a monoidal category" is a particular construction. Do not conflate this usage of the word "monoid" with any generic "monoid" |
| 2022-10-04 22:41:24 +0000 | <ski> | a monoid is an object in a monoidal category, *together* with two particular morphisms, satisfying three laws |
| 2022-10-04 22:41:29 +0000 | donato | (uid570353@id-570353.ilkley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-10-04 22:41:30 +0000 | <dminuoso> | given a monoidal category, *some* objects *may* be monoids. |
| 2022-10-04 22:41:40 +0000 | <dminuoso> | (that is, some objects may be "monoids in that monoidal category") |
| 2022-10-04 22:41:48 +0000 | mncheck | (~mncheck@193.224.205.254) (Ping timeout: 265 seconds) |
| 2022-10-04 22:41:51 +0000 | <goig> | Ya a monoid in a monoidal category. Not that semigroup or whatever else |
| 2022-10-04 22:41:57 +0000 | <dminuoso> | Right |
| 2022-10-04 22:43:00 +0000 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 264 seconds) |
| 2022-10-04 22:43:43 +0000 | <goig> | What are the monoids of the category of endofunctors? Actually, we have more than one category of endofunctors no? As it's always in the respect to a given category |
| 2022-10-04 22:44:33 +0000 | <dminuoso> | An monoid M in some monoidal category (C, ⊗, I), is an object of C equipped with two morphisms of that category μ and η. So that monoid in a monoidal category too is a 3-tuple (M, η, η) |
| 2022-10-04 22:44:54 +0000 | <dminuoso> | goig: ^- given this definition, you dont have monoids in C, you have monoids in (C, ⊗, I) |
| 2022-10-04 22:45:03 +0000 | <dminuoso> | So you must first decide on a tensor |
| 2022-10-04 22:45:38 +0000 | <dminuoso> | Note that both 3-tuples here have additional laws that must be satisfied. |
| 2022-10-04 22:45:56 +0000 | <dminuoso> | (Both sets of laws look very similarly: associativity, left and right unit) |
| 2022-10-04 22:46:03 +0000 | <dminuoso> | Lots of monoidiality here. |
| 2022-10-04 22:46:04 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-04 22:46:51 +0000 | <monochrom> | We haven't even touched on how the word "tensor product" is also much overloaded >:) |
| 2022-10-04 22:47:17 +0000 | <dminuoso> | If we pick (:.:) (endofunctor composition) as its tensor, then *every object* M in the category C that you can equip with two morphisms μ and η, satifsying some particular laws |
| 2022-10-04 22:47:21 +0000 | <dminuoso> | is called such a monoid |
| 2022-10-04 22:47:34 +0000 | <dminuoso> | And in that particular monoidal category, every such object is called a monad |
| 2022-10-04 22:47:38 +0000 | <moonsheep> | as I understand it, the main difference between cereal and binary is that one runs on strict bytestrings and the other on lazy ones, is that correct? |
| 2022-10-04 22:47:43 +0000 | <dminuoso> | nope |
| 2022-10-04 22:47:50 +0000 | <dminuoso> | both really are designed for lazy bytestrings |
| 2022-10-04 22:48:18 +0000 | <dminuoso> | They have some surrounding code to adapt for strict bytestrings, but the internal machinery is really meant for streaming. |
| 2022-10-04 22:48:26 +0000 | <goig> | "So that monoid in a monoidal category too is a 3-tuple (M, η, η)" Is (M, \eta, \eta) a typo or not? |
| 2022-10-04 22:48:31 +0000 | <dminuoso> | Yes sorry |
| 2022-10-04 22:48:35 +0000 | <moonsheep> | cereal's `encode' is strict, you need to use `encodeLazy' to use a lazy bs |
| 2022-10-04 22:48:42 +0000 | <moonsheep> | whereas in binary `encode' is lazy by default |
| 2022-10-04 22:49:05 +0000 | <dminuoso> | moonsheep: that's not really the point of it. |
| 2022-10-04 22:49:49 +0000 | ksu | (~ksu@user/prtr) (Ping timeout: 252 seconds) |
| 2022-10-04 22:49:50 +0000 | <dminuoso> | Those are just functions to `put` into the builder |
| 2022-10-04 22:49:50 +0000 | <moonsheep> | and either way I want to (de)serialize a TCP stream of which I receive small strict bytestrings one at a time |
| 2022-10-04 22:49:59 +0000 | <dminuoso> | moonsheep: use flatparse then. |
| 2022-10-04 22:50:02 +0000 | <dminuoso> | for serialization |
| 2022-10-04 22:50:13 +0000 | <moonsheep> | oh I didn't know about flatparse |
| 2022-10-04 22:50:16 +0000 | <dminuoso> | *deserialization |
| 2022-10-04 22:50:20 +0000 | <dminuoso> | mason for deserialization |
| 2022-10-04 22:50:26 +0000 | <goig> | dminuoso What about return... |
| 2022-10-04 22:50:28 +0000 | <moonsheep> | is it like attoparsec's incremental capabilities? |
| 2022-10-04 22:50:29 +0000 | <dminuoso> | I was presented these two libraries for just the same problem, today! |
| 2022-10-04 22:50:32 +0000 | zebrag | (~chris@user/zebrag) (Ping timeout: 268 seconds) |
| 2022-10-04 22:50:35 +0000 | <moonsheep> | damn |
| 2022-10-04 22:51:02 +0000 | <moonsheep> | I asked a similar question the other day and someone suggested profunctors and bidirectional parsing |
| 2022-10-04 22:51:05 +0000 | <dminuoso> | moonsheep: flatparse is, under the hood, just a bytestring buffer and two pointers. |
| 2022-10-04 22:51:15 +0000 | hays | (rootvegeta@fsf/member/hays) (Ping timeout: 248 seconds) |
| 2022-10-04 22:51:16 +0000 | <moonsheep> | I've been playing around with them, but I'm having real trouble trying to get things to work |
| 2022-10-04 22:51:28 +0000 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2022-10-04 22:51:35 +0000 | <dminuoso> | which means its extremely efficient, but it fundamentally can only work with a strict bytestring |
| 2022-10-04 22:51:54 +0000 | <dminuoso> | https://hackage.haskell.org/package/flatparse-0.3.5.1/docs/src/FlatParse.Basic.html#Parser |
| 2022-10-04 22:51:56 +0000 | <dminuoso> | newtype Parser e a = Parser {runParser# :: ForeignPtrContents -> Addr# -> Addr# -> Res# e a} |
| 2022-10-04 22:51:58 +0000 | <moonsheep> | can you keep incrementally feeding it small strict bytestrings though? |
| 2022-10-04 22:52:08 +0000 | <dminuoso> | Well you can just run new parsers every time. |
| 2022-10-04 22:52:20 +0000 | <dminuoso> | I do this for nested parsing |
| 2022-10-04 22:52:24 +0000 | <moonsheep> | but all those bytestrings are part of a larger stream |
| 2022-10-04 22:52:38 +0000 | <moonsheep> | they arrive in whatever chunks TCP feels lik¡e |
| 2022-10-04 22:52:41 +0000 | <dminuoso> | So I have a huge decoding tree, and while Im decoding, I discover the path in the tree. At each level I just `takeBs` and run a new parser |
| 2022-10-04 22:52:46 +0000 | <dminuoso> | Because of the construction, its all 0-copy |
| 2022-10-04 22:52:51 +0000 | <moonsheep> | hm |
| 2022-10-04 22:53:04 +0000 | <dminuoso> | moonsheep: then you fundamentally have a lazy bytestring problem. |
| 2022-10-04 22:53:16 +0000 | <dminuoso> | a lazy bytestring is just [ByteString] |
| 2022-10-04 22:53:16 +0000 | <moonsheep> | yes but I can't build a lazy bytestring from streaming data can I? |
| 2022-10-04 22:53:20 +0000 | <dminuoso> | Of course! |
| 2022-10-04 22:53:26 +0000 | <moonsheep> | how? |
| 2022-10-04 22:53:30 +0000 | <moonsheep> | fromChunks? |
| 2022-10-04 22:53:34 +0000 | <dminuoso> | Well rather |
| 2022-10-04 22:53:44 +0000 | <dminuoso> | Both binary and cereal let you deal with that |
| 2022-10-04 22:53:46 +0000 | <dminuoso> | they have a streaming interface |
| 2022-10-04 22:54:04 +0000 | <dminuoso> | You can either unsafeInterleaveIO and shove these chunks into a lazy list |
| 2022-10-04 22:54:12 +0000 | <dminuoso> | (which is absolutely terrible for a variety of reasons) |
| 2022-10-04 22:54:23 +0000 | <moonsheep> | what do you think of attoparsec? |
| 2022-10-04 22:54:34 +0000 | <moonsheep> | I always heard it was the best one of incremenntal parsing |
| 2022-10-04 22:54:44 +0000 | <dminuoso> | Or you use `binary` with `runGetIncremental` |
| 2022-10-04 22:54:47 +0000 | <moonsheep> | I know both binary and cereal have an incremental interface too |
| 2022-10-04 22:54:56 +0000 | <dminuoso> | I dont like attoparsec very much for what I do |
| 2022-10-04 22:55:07 +0000 | <dminuoso> | It has a static unoverridable hinting system |
| 2022-10-04 22:55:22 +0000 | <dminuoso> | Sorry no thats megaparsec |
| 2022-10-04 22:55:35 +0000 | <moonsheep> | what I don't like about attoparsec is that I'm not sure how to integrate it with a Putter in a way that makes sense |
| 2022-10-04 22:55:49 +0000 | <moonsheep> | hence why I'm tempted to just go with binary/cereal |
| 2022-10-04 22:55:53 +0000 | <dminuoso> | You will want to write both things separately anyway |
| 2022-10-04 22:55:54 +0000 | <moonsheep> | hence my original question |
| 2022-10-04 22:55:59 +0000 | <dminuoso> | so it doesnt matter whether you use different libraries |
| 2022-10-04 22:56:04 +0000 | <moonsheep> | yeah that's fair ig |
| 2022-10-04 22:56:10 +0000 | <dminuoso> | Do you need to incrementally produce output? |
| 2022-10-04 22:56:21 +0000 | <moonsheep> | the nice thing about binary/cereal is that they already have a fuckton of combinators that work really well |
| 2022-10-04 22:56:30 +0000 | <moonsheep> | dminuoso: no that's not necessary |
| 2022-10-04 22:56:33 +0000 | <moonsheep> | only input |
| 2022-10-04 22:56:40 +0000 | <dminuoso> | Consider `mason` for serialization then |
| 2022-10-04 22:56:45 +0000 | <moonsheep> | hmm, will do |
| 2022-10-04 22:56:48 +0000 | <dminuoso> | its extremely efficient too |
| 2022-10-04 22:56:50 +0000 | zebrag | (~chris@user/zebrag) |
| 2022-10-04 22:56:58 +0000 | <monochrom> | cereal and binary enjoyed a long period of cross pollination, so by now (even since years ago) they do the same thing. |
| 2022-10-04 22:56:58 +0000 | <moonsheep> | so then, does attoparsec+mason sound good? |
| 2022-10-04 22:56:59 +0000 | <dminuoso> | especially if the size is bounded or static |
| 2022-10-04 22:57:21 +0000 | <dminuoso> | if you're happy with attoparsec, sure |
| 2022-10-04 22:57:23 +0000 | <monochrom> | So I just use binary because it comes with GHC |
| 2022-10-04 22:57:24 +0000 | <moonsheep> | attoparsec for incremental parsing as the input arrives in small chunks, and mason for writing |
| 2022-10-04 22:57:36 +0000 | <moonsheep> | dminuoso: yeah I used it once for another purpose and it was fairly nice |
| 2022-10-04 22:57:53 +0000 | <moonsheep> | and really the one thing I absolutely need here is the incremental parsing, and hopefully good efficiency |
| 2022-10-04 22:57:56 +0000 | <moonsheep> | attoparsec claims to do both things |
| 2022-10-04 22:58:22 +0000 | <moonsheep> | monochrom: it does? |
| 2022-10-04 22:58:25 +0000 | <moonsheep> | I thought binary was a library |
| 2022-10-04 22:58:38 +0000 | <moonsheep> | https://hackage.haskell.org/package/binary |
| 2022-10-04 22:58:39 +0000 | <geekosaur> | a number of "boot libraries" come with ghc |
| 2022-10-04 22:58:43 +0000 | <moonsheep> | huh |
| 2022-10-04 22:58:44 +0000 | <dminuoso> | monochrom: Yeah its just very sad that binary has no sensible error recovery mechanism. :( |
| 2022-10-04 22:58:47 +0000 | <geekosaur> | because they're needed to build it |
| 2022-10-04 22:58:47 +0000 | <moonsheep> | I didn't know that |
| 2022-10-04 22:58:57 +0000 | <dminuoso> | And running nested parsers is very inefficient |
| 2022-10-04 22:59:01 +0000 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-10-04 22:59:28 +0000 | <moonsheep> | dminuoso: my error recovery policy is to simply terminate the connection, since both endpoints are expected to behave according to the protocol |
| 2022-10-04 22:59:29 +0000 | <geekosaur> | (binary is used to generate and read .hi module interface files, for instance) |
| 2022-10-04 22:59:42 +0000 | <moonsheep> | geekosaur: ah, that makes sense |
| 2022-10-04 23:00:32 +0000 | <dminuoso> | The only sensible error mechanism with `binary` is if you put ExceptT ontop of it. |
| 2022-10-04 23:01:02 +0000 | <dminuoso> | But since ExceptT is not CPSed, you can only pray for fusion |
| 2022-10-04 23:02:52 +0000 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-10-04 23:04:13 +0000 | <moonsheep> | by CPS do you mean continuation passing style? |
| 2022-10-04 23:04:26 +0000 | <dminuoso> | Yeah |
| 2022-10-04 23:05:10 +0000 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-10-04 23:06:35 +0000 | <moonsheep> | what exactly does CPS have to do witih the except monad? I thought it was simply a style of expressing "returning" something from a function that compilers used as an IR?(sorry I am really unsure about how this all works) |
| 2022-10-04 23:06:57 +0000 | <dminuoso> | newtype ExceptT e m a = ExceptT (m (Either e a)) |
| 2022-10-04 23:06:58 +0000 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 268 seconds) |
| 2022-10-04 23:07:15 +0000 | <dminuoso> | So with this you will be producing an Either as the result of the monad |
| 2022-10-04 23:07:21 +0000 | nate1 | (~nate@98.45.169.16) |
| 2022-10-04 23:08:18 +0000 | <moonsheep> | so what is fusion and how does it relate to producing an Either instead of a continuation? |
| 2022-10-04 23:08:27 +0000 | <moonsheep> | (which is, I assume, what you're referring to? |
| 2022-10-04 23:08:32 +0000 | <moonsheep> | ) |
| 2022-10-04 23:08:45 +0000 | <dminuoso> | So fusion/deforestation is an optimization where, for example in lists, intermediate lists are gotten rid of |
| 2022-10-04 23:09:14 +0000 | <moonsheep> | oh so you mean like getting rid of the list in `sum [1..10]'? |
| 2022-10-04 23:09:34 +0000 | <dminuoso> | This is very important, as in Haskell a list is essentially `data List a = Cons a (List a) | Nil`, which means *every* single element has to have a heap representation |
| 2022-10-04 23:10:15 +0000 | <moonsheep> | and fusion doesn't work if you don't return a continuation? |
| 2022-10-04 23:10:31 +0000 | cheater | (~Username@user/cheater) (Remote host closed the connection) |
| 2022-10-04 23:10:33 +0000 | <moonsheep> | or rather return with a continuation I suppose |
| 2022-10-04 23:10:55 +0000 | <dminuoso> | I guess it could perhaps with sufficient sorcery, much of the list fusion in GHC relies on constructing lists via `build` |
| 2022-10-04 23:11:06 +0000 | <dminuoso> | build :: forall a . (forall b . (a -> b -> b) -> b -> b) -> [a] |
| 2022-10-04 23:11:18 +0000 | <moonsheep> | damn that's a cursed type signature |
| 2022-10-04 23:11:25 +0000 | <dminuoso> | It's very simple really |
| 2022-10-04 23:11:25 +0000 | <moonsheep> | is that higher rank? |
| 2022-10-04 23:11:27 +0000 | <dminuoso> | :t foldr |
| 2022-10-04 23:11:28 +0000 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2022-10-04 23:11:30 +0000 | <geekosaur> | CPSed computations are almost trivial to fuse; anything else, you have to hope someone wrote an appropriate RULE that matches your use |
| 2022-10-04 23:11:55 +0000 | <geekosaur> | (or a built-in one like the one for basic list processing) |
| 2022-10-04 23:12:11 +0000 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-10-04 23:12:13 +0000 | <dminuoso> | moonsheep: observe that, we can think of a list as also being represented by `foldr` with the `t a` already applied. |
| 2022-10-04 23:12:33 +0000 | <moonsheep> | dminuoso: so by saying that except is not CPSed you meant that returning an either doesn't happen to match one of these predefined rules? |
| 2022-10-04 23:12:33 +0000 | <dminuoso> | So there is an isomorphism between: [a] and (a -> b -> b) -> b -> b |
| 2022-10-04 23:12:50 +0000 | <moonsheep> | that's hard to wrap my head around |
| 2022-10-04 23:13:00 +0000 | <geekosaur> | not quite |
| 2022-10-04 23:13:27 +0000 | <dminuoso> | moonsheep: viewed differently, the fundamental and characteristic thing you can do with a list is folding it. |
| 2022-10-04 23:13:32 +0000 | <geekosaur> | if it's CPSed then it can be fused. if it's not then it needs to match a RULE. there are a limited number of rules for (Except e a) |
| 2022-10-04 23:13:55 +0000 | <moonsheep> | right |
| 2022-10-04 23:14:00 +0000 | <geekosaur> | (there are many more for lists, some built-in) |
| 2022-10-04 23:14:10 +0000 | <jackdk> | moonsheep: http://data.tmorris.net/talks/list-folds/b30aa0fdff296c731bc5b1c824adf1d02b3b69d9/list-folds.pdf This is an excellent slide deck about this stuff - foldr "replaces the constructors" with functions |
| 2022-10-04 23:14:27 +0000 | <dminuoso> | moonsheep: so the trick with lists is, if you construct them via `build`, and you consume that list via `foldr` again, then you will achieve automatic short cut fusion |
| 2022-10-04 23:14:37 +0000 | <dminuoso> | there will not be a physical intermediate list |
| 2022-10-04 23:14:47 +0000 | <moonsheep> | that's interesting |
| 2022-10-04 23:14:59 +0000 | <moonsheep> | I had never seen folds as being such a fundamental universal property of lists |
| 2022-10-04 23:15:02 +0000 | <moonsheep> | merely as another utility function |
| 2022-10-04 23:15:11 +0000 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-04 23:15:24 +0000 | <geekosaur> | think of a fold (foldr in particular) as replacing [] with z and (:) with f |
| 2022-10-04 23:15:27 +0000 | <dminuoso> | but this relies on RULES, an optimization framework where you construct handwritten "match and replace" rules |
| 2022-10-04 23:15:41 +0000 | <moonsheep> | geekosaur: oh that makes so much sense, right |
| 2022-10-04 23:15:51 +0000 | <dminuoso> | moonsheep: in fact, this foldr representation is how you encode lists in Church representation in lambda calculus. |
| 2022-10-04 23:16:11 +0000 | <dminuoso> | or its one way at least. |
| 2022-10-04 23:16:43 +0000 | cheater | (~Username@user/cheater) |
| 2022-10-04 23:16:54 +0000 | <moonsheep> | I'm still not sure why `build' needs to be rank 2? |
| 2022-10-04 23:17:10 +0000 | <moonsheep> | why can't that `forall b.' be top-level? |
| 2022-10-04 23:17:12 +0000 | <dminuoso> | moonsheep: because it must be able to take any foldr type of function. |
| 2022-10-04 23:17:31 +0000 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-10-04 23:17:51 +0000 | <moonsheep> | how do you mean? |
| 2022-10-04 23:18:00 +0000 | <moonsheep> | "any folder type of the function"? |
| 2022-10-04 23:18:39 +0000 | <moonsheep> | hmm, maybe I shuold try to learn more about this type of more theoretical stuff |
| 2022-10-04 23:19:28 +0000 | <dminuoso> | monochrom: consider for a second how `build` would be used. |
| 2022-10-04 23:19:58 +0000 | <dminuoso> | Oops sorry, bad tab completion |
| 2022-10-04 23:20:17 +0000 | <dminuoso> | > myBuild g = g (:) [] |
| 2022-10-04 23:20:19 +0000 | <lambdabot> | <hint>:1:11: error: parse error on input ‘=’ |
| 2022-10-04 23:20:20 +0000 | <dminuoso> | @let myBuild g = g (:) [] |
| 2022-10-04 23:20:22 +0000 | <lambdabot> | Defined. |
| 2022-10-04 23:20:26 +0000 | <dminuoso> | :t myBuild |
| 2022-10-04 23:20:27 +0000 | <lambdabot> | ((a1 -> [a1] -> [a1]) -> [a2] -> t) -> t |
| 2022-10-04 23:20:28 +0000 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-10-04 23:20:32 +0000 | <dminuoso> | monochrom: ^- this is the inferred rank 1 type. |
| 2022-10-04 23:20:39 +0000 | <moonsheep> | oh right |
| 2022-10-04 23:20:40 +0000 | <dminuoso> | Gosh again. I meant moonsheep. |
| 2022-10-04 23:20:54 +0000 | <dminuoso> | We cant just pin this to `b`, that would not type checkl |
| 2022-10-04 23:21:23 +0000 | <dminuoso> | :t foldr |
| 2022-10-04 23:21:24 +0000 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2022-10-04 23:21:33 +0000 | <moonsheep> | hmm that makes sense I guess |
| 2022-10-04 23:21:41 +0000 | <moonsheep> | it's so hard to try to infer types in my head |
| 2022-10-04 23:21:42 +0000 | <EvanR> | dminuoso, sse2 is really just about registers? |
| 2022-10-04 23:21:50 +0000 | <dminuoso> | moonsheep: It might help to see the implicit quantification here. If we, assume the `t a` is implicitly applied, then this type becomes: |
| 2022-10-04 23:21:54 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) |
| 2022-10-04 23:22:12 +0000 | Tuplanolla | (~Tuplanoll@91-159-69-34.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-10-04 23:22:13 +0000 | <dminuoso> | EvanR: No its about special execution units |
| 2022-10-04 23:22:18 +0000 | <dminuoso> | or execution ports, rather. |
| 2022-10-04 23:22:25 +0000 | <dminuoso> | but also special registers |
| 2022-10-04 23:23:18 +0000 | <dminuoso> | On modern AMD64 processors you have whats called register files, which are just large chunks of registers of different types. Nowadays you have about ~200 regular registers (used for RAX, RBX, RCX, etc...) |
| 2022-10-04 23:23:31 +0000 | <EvanR> | but same memory and same cache system |
| 2022-10-04 23:23:36 +0000 | <dminuoso> | And maybe another ~100 SIMD registers |
| 2022-10-04 23:23:55 +0000 | <dminuoso> | Or even more, really depends on the exact model |
| 2022-10-04 23:24:09 +0000 | <EvanR> | 200 registers, that would definitely simplify a few things |
| 2022-10-04 23:24:19 +0000 | jargon | (~jargon@174-22-201-96.phnx.qwest.net) |
| 2022-10-04 23:24:32 +0000 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-04 23:24:48 +0000 | <dminuoso> | Yup, but you have only 8 architectural registers |
| 2022-10-04 23:24:54 +0000 | <dminuoso> | That you can semantically observe |
| 2022-10-04 23:25:18 +0000 | <dminuoso> | Under the hood these registers get renamed at the reservation station |
| 2022-10-04 23:25:53 +0000 | <dminuoso> | so what you perceive as RAX for a given instruction, will inside the reservation station use physical register 17 maybe (say because that register happens to be free and not in use) |
| 2022-10-04 23:26:46 +0000 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:2888:9a07:52ef:e042) (Ping timeout: 260 seconds) |
| 2022-10-04 23:27:05 +0000 | <dminuoso> | This allows the CPU to do multiple calculations with RAX in parallel (say because you first add two numbers into RAX and store into memory, and then multpile 2 different unrelated numbers into RAX too and store into memory). |
| 2022-10-04 23:27:22 +0000 | <dminuoso> | There will be no dependency between the two, so they *can* be executed perfectly in parallel |
| 2022-10-04 23:27:32 +0000 | <dminuoso> | No reason for the latter to wait until the former has been completed. |
| 2022-10-04 23:27:52 +0000 | <moonsheep> | dminuoso: I'm having a lot of trouble understanding, that `b' isn't supposed to be anything other than `t a' right? |
| 2022-10-04 23:27:57 +0000 | <dminuoso> | SIMD uses special registers (that are much wider) and special execution ports (special circuitry that can do SIMD) |
| 2022-10-04 23:28:13 +0000 | <dminuoso> | moonsheep: no its different. |
| 2022-10-04 23:28:18 +0000 | <dminuoso> | the `t a` is already been applied. |
| 2022-10-04 23:28:39 +0000 | <EvanR> | dminuoso, I believe you about this story. But I find it astonishing that any time constraints can be satisfied as advertised |
| 2022-10-04 23:28:44 +0000 | <EvanR> | given how dynamic it is |
| 2022-10-04 23:29:18 +0000 | <moonsheep> | but the type of `g (:) []' is `b' which must then somehow unify with `[a]'? |
| 2022-10-04 23:29:22 +0000 | <EvanR> | what if there is no free register for a given task |
| 2022-10-04 23:29:39 +0000 | <dminuoso> | EvanR: then the pipeline will stall/block. |
| 2022-10-04 23:30:04 +0000 | <dminuoso> | EvanR: whats even cooler, there's something sort of STMish in this whole process. |
| 2022-10-04 23:30:20 +0000 | <dminuoso> | because it can speculatively execute things ahead of type |
| 2022-10-04 23:30:22 +0000 | rockymarine | (~rocky@user/rockymarine) |
| 2022-10-04 23:30:25 +0000 | <dminuoso> | and then commit or rollback |
| 2022-10-04 23:30:30 +0000 | <moonsheep> | oh btw sorry if I'm interrupting this more serious conversation |
| 2022-10-04 23:30:33 +0000 | <dminuoso> | and thats why you need that many registers |
| 2022-10-04 23:30:37 +0000 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 265 seconds) |
| 2022-10-04 23:30:37 +0000 | <EvanR> | no I'm interrupting, carry on |
| 2022-10-04 23:30:39 +0000 | <dminuoso> | moonsheep: no worries, keep on |
| 2022-10-04 23:32:12 +0000 | <dminuoso> | EvanR: The latest Intel generation is able to competently execute 6 instructions per clock cycle steadily. |
| 2022-10-04 23:32:35 +0000 | <dminuoso> | But of course, if you look at the entirety, it requires very careful code to do this. |
| 2022-10-04 23:33:26 +0000 | <dminuoso> | For example, you have typically one complex and 3 simple decoders. So your machine code should ideally produce 1 complex instruction and 3 simple instructions in a cycle. |
| 2022-10-04 23:33:34 +0000 | <dminuoso> | Otherwise you will bottleneck on the decoder stage |
| 2022-10-04 23:34:07 +0000 | <dminuoso> | (that's 6 instructions per clock cycle.. per core. of course) |
| 2022-10-04 23:34:52 +0000 | <moonsheep> | > myBuild $ const $ const 1 |
| 2022-10-04 23:34:53 +0000 | <lambdabot> | 1 |
| 2022-10-04 23:34:56 +0000 | <moonsheep> | > build $ const $ const 1 |
| 2022-10-04 23:34:58 +0000 | <lambdabot> | error: |
| 2022-10-04 23:34:58 +0000 | <lambdabot> | • Variable not in scope: build :: (b0 -> b1 -> a0) -> t |
| 2022-10-04 23:34:58 +0000 | <lambdabot> | • Perhaps you meant ‘buildG’ (imported from Data.Graph) |
| 2022-10-04 23:35:01 +0000 | <moonsheep> | huh |
| 2022-10-04 23:35:10 +0000 | <dminuoso> | But the latest generation has 6 decoders, and incremeneted to 12 execution ports |
| 2022-10-04 23:35:15 +0000 | <EvanR> | are these time guarantees or is it "you will probably be able to do 6 instructions per cycle" |
| 2022-10-04 23:35:17 +0000 | <geekosaur> | @index build |
| 2022-10-04 23:35:17 +0000 | <lambdabot> | GHC.Exts, Distribution.Simple.Build |
| 2022-10-04 23:35:24 +0000 | <dminuoso> | EvanR: Not even probably. |
| 2022-10-04 23:35:28 +0000 | <dminuoso> | Just with targeted code. |
| 2022-10-04 23:35:31 +0000 | <geekosaur> | you want the one in GHS.Exts |
| 2022-10-04 23:35:31 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-04 23:35:34 +0000 | <dminuoso> | But locally it can occur. |
| 2022-10-04 23:35:38 +0000 | <geekosaur> | *GHC.Exts |
| 2022-10-04 23:35:43 +0000 | <EvanR> | not probably? |
| 2022-10-04 23:35:56 +0000 | <dminuoso> | You might have moments where a single core will execute 12 instructions in a single cycle |
| 2022-10-04 23:36:02 +0000 | <dminuoso> | Because you have 12 execution ports |
| 2022-10-04 23:36:05 +0000 | <moonsheep> | dminuoso: what's the difference? |
| 2022-10-04 23:36:23 +0000 | <moonsheep> | oh wait nevermind |
| 2022-10-04 23:36:30 +0000 | <moonsheep> | I just had a stroke disregard that |
| 2022-10-04 23:37:20 +0000 | argento | (~argent0@168-227-97-34.ptr.westnet.com.ar) |
| 2022-10-04 23:37:31 +0000 | goig | (~goig@202.91.42.7) (Quit: Client closed) |
| 2022-10-04 23:37:42 +0000 | <dminuoso> | EvanR: so on alder lake you have 1 complex and 5 simple decoders. In order to maintain that rate you have to a) have instructions of type [C,S,S,S,S,S,C,S,S,S,S,S,C,S,S,S,S,S.....], b) design all these instructions to use exactly the execution ports available |
| 2022-10-04 23:37:45 +0000 | <dminuoso> | Avoiding inter-dependencies |
| 2022-10-04 23:37:48 +0000 | <dminuoso> | And not use memory. |
| 2022-10-04 23:37:50 +0000 | <moonsheep> | btw how do you import modules with lambdabot? this the @index import them already? |
| 2022-10-04 23:37:59 +0000 | <dminuoso> | (Or at best use only things that are hot in L1) |
| 2022-10-04 23:38:27 +0000 | <dminuoso> | EvanR: this complex/simple thing is one of the things peephole optimizations passes in compilers will do by the way |
| 2022-10-04 23:38:32 +0000 | <geekosaur> | @let import GHC.Exts |
| 2022-10-04 23:38:33 +0000 | <lambdabot> | /sandbox/tmp/.L.hs:134:1: error: |
| 2022-10-04 23:38:33 +0000 | <lambdabot> | GHC.Exts: Can't be safely imported! The module itself isn't safe. |
| 2022-10-04 23:38:34 +0000 | <lambdabot> | | |
| 2022-10-04 23:38:34 +0000 | <dminuoso> | reorder instructions to keep the decoder stage happy |
| 2022-10-04 23:38:37 +0000 | <geekosaur> | welp |
| 2022-10-04 23:38:49 +0000 | <moonsheep> | @let import GHC.Base |
| 2022-10-04 23:38:50 +0000 | <geekosaur> | % import GHC.Exts |
| 2022-10-04 23:38:50 +0000 | <yahb2> | <no output> |
| 2022-10-04 23:38:50 +0000 | <lambdabot> | /sandbox/tmp/.L.hs:134:1: error: |
| 2022-10-04 23:38:51 +0000 | <lambdabot> | GHC.Base: Can't be safely imported! The module itself isn't safe. |
| 2022-10-04 23:38:51 +0000 | <lambdabot> | | |
| 2022-10-04 23:38:55 +0000 | <moonsheep> | > build $ const $ const 1 |
| 2022-10-04 23:38:57 +0000 | <lambdabot> | error: |
| 2022-10-04 23:38:57 +0000 | <lambdabot> | • Variable not in scope: build :: (b0 -> b1 -> a0) -> t |
| 2022-10-04 23:38:57 +0000 | <lambdabot> | • Perhaps you meant ‘buildG’ (imported from Data.Graph) |
| 2022-10-04 23:38:59 +0000 | <geekosaur> | % :t build |
| 2022-10-04 23:39:00 +0000 | <yahb2> | build :: (forall b. (a -> b -> b) -> b -> b) -> [a] |
| 2022-10-04 23:39:01 +0000 | raehik1 | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2022-10-04 23:39:04 +0000 | <moonsheep> | hmm |
| 2022-10-04 23:39:10 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-04 23:39:10 +0000 | <geekosaur> | % build $ const $ const |
| 2022-10-04 23:39:11 +0000 | <yahb2> | <interactive>:232:9: error: ; • Occurs check: cannot construct the infinite type: b ~ b0 -> b ; Expected type: (a -> b -> b) -> b -> b ; Actual type: (a -> b -> b) -> b -> b0 -> b... |
| 2022-10-04 23:39:33 +0000 | <moonsheep> | what does % do? |
| 2022-10-04 23:39:42 +0000 | <geekosaur> | uses yahb2 instead of lambdabot |
| 2022-10-04 23:39:49 +0000 | <moonsheep> | what's the difference? |
| 2022-10-04 23:39:52 +0000 | <geekosaur> | yahb2 is a sandboxed ghci |
| 2022-10-04 23:39:52 +0000 | xff0x | (~xff0x@2405:6580:b080:900:5451:f081:9268:d7a) |
| 2022-10-04 23:39:55 +0000 | <moonsheep> | why can one run unsafe code? |
| 2022-10-04 23:39:57 +0000 | <moonsheep> | geekosaur: ah |
| 2022-10-04 23:39:59 +0000 | <dminuoso> | EvanR: instructions can also be reordered with knowledge about execution ports (in nehalem FP mul and SSE MUL is on the same execution port, so if you can move two adjacent FP mul and SSE mul instructions apart from each other, you can avoid bottlenecking on that execution port) |
| 2022-10-04 23:40:04 +0000 | <geekosaur> | lambdabot is a tightly constrained Mueval |
| 2022-10-04 23:40:10 +0000 | <moonsheep> | % build $ const $ const 1 |
| 2022-10-04 23:40:10 +0000 | <yahb2> | <interactive>:234:23: error: ; • No instance for (Num b) arising from the literal ‘1’ ; Possible fix: ; add (Num b) to the context of ; a type expected by the context: ;... |
| 2022-10-04 23:40:14 +0000 | <dminuoso> | EvanR: and thats the sort of thing the intel compiler is particularly good with |
| 2022-10-04 23:40:15 +0000 | <geekosaur> | (which you can look up on hackage) |
| 2022-10-04 23:40:48 +0000 | <moonsheep> | anyway so I think now I get the difference (just experimented a bit on local ghci, don't want to flood the channel) |
| 2022-10-04 23:41:22 +0000 | <moonsheep> | so if you don't do the explicit forall you can return anything you want from g, whereas with it it must actually be a list constructed with (:) and [] |
| 2022-10-04 23:41:24 +0000 | <moonsheep> | is that it? |
| 2022-10-04 23:41:49 +0000 | <dminuoso> | EvanR: now note, that if you do something like fetch memory and then do a lot of operations on that memory, you might not even have the chance for speculative execution. If that CPU has to wait 100 cycles for data to arrive into L1 from main memory, that's potentially 600 instructions wasted. |
| 2022-10-04 23:41:59 +0000 | <dminuoso> | the cpu will do.. nothing in that time. |
| 2022-10-04 23:42:12 +0000 | <dminuoso> | which is why cache aware code is so important |
| 2022-10-04 23:42:16 +0000 | euandreh | (~euandreh@179.214.113.107) |
| 2022-10-04 23:43:10 +0000 | <dminuoso> | moonsheep: rather, with `build` you could otherwise only accept a fold that specifically folds into lists. |
| 2022-10-04 23:43:21 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 252 seconds) |
| 2022-10-04 23:43:38 +0000 | <dminuoso> | by taking a function polymorphic over its return type, `build` is able to work with any list producer |
| 2022-10-04 23:43:55 +0000 | <moonsheep> | hmm, right |
| 2022-10-04 23:44:20 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-04 23:44:24 +0000 | <dminuoso> | moonsheep: In a function of rank-2-type, its the implementor of that function that will decide on the choice of the type variable |
| 2022-10-04 23:44:28 +0000 | <Axman6> | > build (\ |
| 2022-10-04 23:44:30 +0000 | <lambdabot> | <hint>:1:9: error: |
| 2022-10-04 23:44:30 +0000 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 2022-10-04 23:44:35 +0000 | <dminuoso> | the supplier has to provide a polymorphic one |
| 2022-10-04 23:44:46 +0000 | tomgus1 | (~tomgus1@2a02:c7e:4229:d900:dea6:32ff:fe3d:d1a3) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2022-10-04 23:44:58 +0000 | <Axman6> | > build (\f b -> f 1 (f 2 (f 3 b))) |
| 2022-10-04 23:44:59 +0000 | <moonsheep> | oh right |
| 2022-10-04 23:45:00 +0000 | <lambdabot> | error: |
| 2022-10-04 23:45:00 +0000 | <lambdabot> | • Variable not in scope: |
| 2022-10-04 23:45:00 +0000 | <lambdabot> | build :: ((t1 -> t0 -> t0) -> t0 -> t0) -> t |
| 2022-10-04 23:45:06 +0000 | <Axman6> | % build (\f b -> f 1 (f 2 (f 3 b))) |
| 2022-10-04 23:45:06 +0000 | <yahb2> | [1,2,3] |
| 2022-10-04 23:45:09 +0000 | <dminuoso> | or *the caller |
| 2022-10-04 23:45:17 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-10-04 23:45:17 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-10-04 23:45:17 +0000 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-10-04 23:45:17 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-10-04 23:45:17 +0000 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-10-04 23:45:17 +0000 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-10-04 23:45:17 +0000 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-10-04 23:45:32 +0000 | tomgus1 | (~tomgus1@2e40cd7e.skybroadband.com) |
| 2022-10-04 23:45:36 +0000 | <dminuoso> | moonsheep: another view here with Axman6 presented, is that you can imagine this list to have "holes" in place of where (:) and [] otherwise are. |
| 2022-10-04 23:45:44 +0000 | califax | (~califax@user/califx) |
| 2022-10-04 23:46:04 +0000 | <dminuoso> | And `build` will just chose (:) and [] in those holes (thus rebuilding the list) |
| 2022-10-04 23:46:20 +0000 | <moonsheep> | yeah that makes sense |
| 2022-10-04 23:46:22 +0000 | <dminuoso> | > build (\f b -> 1 `f` (2 `f` (f `f` b))) |
| 2022-10-04 23:46:24 +0000 | <lambdabot> | error: |
| 2022-10-04 23:46:24 +0000 | <lambdabot> | • Variable not in scope: |
| 2022-10-04 23:46:24 +0000 | <lambdabot> | build :: ((t1 -> t0 -> t0) -> t0 -> t0) -> t |
| 2022-10-04 23:46:28 +0000 | <dminuoso> | % build (\f b -> 1 `f` (2 `f` (f `f` b))) |
| 2022-10-04 23:46:28 +0000 | <yahb2> | <interactive>:256:30: error: ; • Occurs check: cannot construct the infinite type: a ~ a -> b -> b ; • In the first argument of ‘f’, namely ‘f’ ; In the second argument of ‘f’, namely... |
| 2022-10-04 23:46:37 +0000 | <dminuoso> | % build (\f b -> 1 `f` (2 `f` (3 `f` b))) |
| 2022-10-04 23:46:38 +0000 | <yahb2> | [1,2,3] |
| 2022-10-04 23:46:48 +0000 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-10-04 23:46:55 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-10-04 23:47:05 +0000 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-10-04 23:47:08 +0000 | <dminuoso> | moonsheep: https://gist.github.com/dminuoso/af04270a918882b2cfa5b4eec74036ca |
| 2022-10-04 23:47:09 +0000 | <moonsheep> | funnily enough one of my earlier experiments was precisely a 1,2,3 list |
| 2022-10-04 23:47:22 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-10-04 23:47:22 +0000 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-10-04 23:47:27 +0000 | <moonsheep> | right |
| 2022-10-04 23:47:29 +0000 | <dminuoso> | If you align them like that, it becomes very obvious that you can turn the first into the second. |
| 2022-10-04 23:47:40 +0000 | <Axman6> | :t foldr |
| 2022-10-04 23:47:41 +0000 | <lambdabot> | Foldable t => (a -> b -> b) -> b -> t a -> b |
| 2022-10-04 23:47:48 +0000 | <moonsheep> | and the first one is just any old fold |
| 2022-10-04 23:48:06 +0000 | <dminuoso> | moonsheep: With that in mind, can you predict what this is going to do? |
| 2022-10-04 23:48:13 +0000 | <Axman6> | % :t \t -> build (\f b -> foldr f b t) |
| 2022-10-04 23:48:13 +0000 | <yahb2> | \t -> build (\f b -> foldr f b t) :: Foldable t => t a -> [a] |
| 2022-10-04 23:48:17 +0000 | <dminuoso> | foldr (:) [1] [1,2,3] |
| 2022-10-04 23:48:22 +0000 | <dminuoso> | moonsheep: ^- |
| 2022-10-04 23:48:28 +0000 | <dminuoso> | uhh |
| 2022-10-04 23:48:30 +0000 | <dminuoso> | foldr (:) [] [1,2,3] |
| 2022-10-04 23:48:32 +0000 | <dminuoso> | Sorry. |
| 2022-10-04 23:48:35 +0000 | <moonsheep> | rebuild the list |
| 2022-10-04 23:48:46 +0000 | <dminuoso> | Right. |
| 2022-10-04 23:48:51 +0000 | <moonsheep> | right that makes sense |
| 2022-10-04 23:49:10 +0000 | <dminuoso> | moonsheep: ANyway. Take note that each cons (:) will require a heap allocation |
| 2022-10-04 23:49:14 +0000 | <moonsheep> | since it's just doing 1 : 2 : 3 : [] |
| 2022-10-04 23:49:27 +0000 | <dminuoso> | So if you produce, consume, produce, consume lists constantly, this will generate a lot of allocations |
| 2022-10-04 23:49:28 +0000 | <moonsheep> | dminuoso: will that get optimized away with that fusion magic you were talking about? |
| 2022-10-04 23:49:29 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-10-04 23:49:36 +0000 | <dminuoso> | That's the thing |
| 2022-10-04 23:49:38 +0000 | <dminuoso> | You *want* it to go away |
| 2022-10-04 23:49:41 +0000 | <moonsheep> | right |
| 2022-10-04 23:50:06 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-04 23:50:40 +0000 | <dminuoso> | If you construct the list via `build`, and then someone uses that list via `foldr`, then there is a special RULES thing that will just rewrite the `build` to go away, and just fuse the functions together. |
| 2022-10-04 23:50:49 +0000 | <dminuoso> | Making the intermediate list and all allocations go poof |
| 2022-10-04 23:51:04 +0000 | <moonsheep> | that's clever |
| 2022-10-04 23:51:06 +0000 | <dminuoso> | And suddenly gaining additional inilining opportunities |
| 2022-10-04 23:51:13 +0000 | <moonsheep> | so I assume build is used internally by lots of library functions? |
| 2022-10-04 23:51:22 +0000 | <dminuoso> | Yes |
| 2022-10-04 23:51:23 +0000 | <moonsheep> | making inlining suddenly a lot more productive? |
| 2022-10-04 23:51:24 +0000 | <EvanR> | can rewrite rules make my entire program disappear because it's equivalent to doing nothing xD |
| 2022-10-04 23:51:39 +0000 | <dminuoso> | moonsheep: consider Data.ByteString.unpack :: ByteString -> [Word8] |
| 2022-10-04 23:51:40 +0000 | <EvanR> | that would be the best |
| 2022-10-04 23:51:45 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-04 23:51:47 +0000 | <ski> | foldr cons nil (build f) = f cons nil |
| 2022-10-04 23:51:49 +0000 | <dminuoso> | moonsheep: unpack bs = build (unpackFoldr bs) https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/src/Data.ByteString.html#unpack |
| 2022-10-04 23:51:53 +0000 | <moonsheep> | EvanR: "haskell code can have no side effects because no one will ever run it" -xkcd |
| 2022-10-04 23:52:02 +0000 | <EvanR> | lol |
| 2022-10-04 23:52:07 +0000 | <dminuoso> | Note how the list is build via unpackFoldr, and then presented via build |
| 2022-10-04 23:52:08 +0000 | <ski> | hah |
| 2022-10-04 23:52:14 +0000 | <dminuoso> | Such that if you decide to foldr over it, the list will go away. |
| 2022-10-04 23:52:21 +0000 | <EvanR> | xkcd should look at agda |
| 2022-10-04 23:52:27 +0000 | <dminuoso> | It will never exist in the first place. |
| 2022-10-04 23:52:53 +0000 | <dminuoso> | moonsheep: of course now the library author can write additional rules to make that foldr happen for you in special cases, such that you can pretend you're just doing normal list stuff. |
| 2022-10-04 23:52:55 +0000 | <moonsheep> | oh true, I would never have imagined it to have been implemented that way |
| 2022-10-04 23:52:59 +0000 | <monochrom> | But xkcd also needs to confine itself to talking about something people have heard of. |
| 2022-10-04 23:53:24 +0000 | <monochrom> | So let's say "haskell" is a social engineering compromise. |
| 2022-10-04 23:53:43 +0000 | <moonsheep> | wait what |
| 2022-10-04 23:53:46 +0000 | <dminuoso> | moonsheep: https://hackage.haskell.org/package/base-4.17.0.0/docs/src/GHC.Base.html#build |
| 2022-10-04 23:53:48 +0000 | <dminuoso> | take a quick look |
| 2022-10-04 23:53:57 +0000 | <dminuoso> | Look slightly below, you will see a section named RULES |
| 2022-10-04 23:54:09 +0000 | <dminuoso> | "fold/build" forall k z (g::forall b. (a->b->b) -> b -> b) . |
| 2022-10-04 23:54:11 +0000 | <moonsheep> | oh true |
| 2022-10-04 23:54:11 +0000 | <dminuoso> | foldr k z (build g) = g k z |
| 2022-10-04 23:54:14 +0000 | <moonsheep> | is that the GHC magic sauce? |
| 2022-10-04 23:54:15 +0000 | <dminuoso> | Without going into details, this means" |
| 2022-10-04 23:54:39 +0000 | <dminuoso> | If the optimizer ever sees `foldr k z (build g)` (matching the above signature) it is free to, without proving equality, statically replace it with `g k z` |
| 2022-10-04 23:54:49 +0000 | <dminuoso> | Thus the `build` call disappears entirely |
| 2022-10-04 23:54:53 +0000 | <dminuoso> | No list is ever constructed. |
| 2022-10-04 23:55:05 +0000 | <moonsheep> | that's really clever |
| 2022-10-04 23:55:58 +0000 | <dminuoso> | Actually its even stronger than "free to", it *will* replace it. |
| 2022-10-04 23:56:26 +0000 | <dminuoso> | GHC has, in addition, a lot of machinery to keep transforming code in happens of firing RULES like that. |
| 2022-10-04 23:56:26 +0000 | <moonsheep> | alright great and now I've forgotten why I even came here originally |
| 2022-10-04 23:56:29 +0000 | <moonsheep> | this is worse than wikiholes |
| 2022-10-04 23:56:31 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2022-10-04 23:56:47 +0000 | <EvanR> | your original question was optimized away |
| 2022-10-04 23:56:55 +0000 | wonko | (~wjc@2a0e:1c80:11::50) (Ping timeout: 268 seconds) |
| 2022-10-04 23:56:58 +0000 | <moonsheep> | true |
| 2022-10-04 23:57:08 +0000 | <geekosaur> | you were originally asking why dminuoso wanted ExceptT to be CPS-transformed |
| 2022-10-04 23:57:14 +0000 | <moonsheep> | oh yeah |
| 2022-10-04 23:57:17 +0000 | <dminuoso> | moonsheep: by the way, also note that the `foldr` also disappears of course. |
| 2022-10-04 23:57:27 +0000 | <dminuoso> | Its not needed, because the folding is already there from the `build` producer side. |
| 2022-10-04 23:57:33 +0000 | mixphix | (~cigsender@bras-base-otwaon237cw-grc-11-174-91-129-69.dsl.bell.ca) |
| 2022-10-04 23:57:37 +0000 | <moonsheep> | yeah that makes sense |
| 2022-10-04 23:57:39 +0000 | <dminuoso> | So we can just use that one, and fold it with whatever the original folder wanted. |
| 2022-10-04 23:57:40 +0000 | bgamari | (~bgamari@64.223.132.120) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-10-04 23:58:43 +0000 | <dminuoso> | moonsheep: with that machinery in place, you can potentially end in situations where instead of rebuilding a list countless times, instead you end up with a composed function `k` (from above) that does a bunch of things in a row |
| 2022-10-04 23:59:07 +0000 | <dminuoso> | its a very important optimization to make lists with the incredible allocation overhead usable |
| 2022-10-04 23:59:14 +0000 | <geekosaur> | and before that why it's difficult to interrupt a binary/cereal put, iirc (may have been get) |
| 2022-10-04 23:59:32 +0000 | <geekosaur> | which is where the ExceptT came in |
| 2022-10-04 23:59:40 +0000 | <moonsheep> | yeah I remember that |
| 2022-10-04 23:59:40 +0000 | <moonsheep> | anyway |
| 2022-10-04 23:59:56 +0000 | <moonsheep> | off I go I guess, I'll try mason+attoparsec |
