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