IRCBrowse

2022/11/15

2022-11-15 00:00:11 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 255 seconds)
2022-11-15 00:02:33 +0100ChaiTRex(~ChaiTRex@user/chaitrex)
2022-11-15 00:02:39 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-11-15 00:06:30 +0100TonyStone31(~TonyStone@cpe-74-76-57-186.nycap.res.rr.com) (Quit: Leaving)
2022-11-15 00:15:22 +0100 <Axman6> Guest75: that particular JSON encoding isn't something I've seen elsewhere, if you look at the SumEncoding for aeson you'll see how things are usually done (https://hackage.haskell.org/package/aeson-2.1.1.0/docs/Data-Aeson.html#t:SumEncoding) the closest you'd get is TaggedObject { tagFieldName = "constructor", contentsFieldName = "params" }, but that won't store the fields in an array (... but worth testing, it's not clear to me what happens when you don't ha
2022-11-15 00:15:22 +0100 <Axman6> ve record fields names)
2022-11-15 00:16:01 +0100 <Axman6> dminuoso: is there a flatparse json decoder yet? I started writing one and then remembered how tedious it would be :P
2022-11-15 00:17:29 +0100 <Guest75> Axman6: great, thanks! That should be much better, 'cause parsing ADT definition manually is a hard way
2022-11-15 00:18:15 +0100 <Axman6> _if_ you can use one of the formats Aeson supports, then generics are usually a good option, but sometimes people insist on weird encodings which aren't well supported
2022-11-15 00:19:01 +0100 <Axman6> Also look at the `Options` type to see what modifiers you can apply https://hackage.haskell.org/package/aeson-2.1.1.0/docs/Data-Aeson.html#t:Options
2022-11-15 00:20:03 +0100 <monochrom> Woah, undocumented GHC option -dno-suppress-stg-free-vars which is deprecated and replaced by undocumented option -dno-suppress-stg-exts
2022-11-15 00:20:49 +0100 <Guest75> Aeson should probably be sufficient ('cause I'm based on it's types and stanard ones like String/Integer etc)
2022-11-15 00:22:53 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 00:23:45 +0100 <EvanR> String...
2022-11-15 00:26:00 +0100 <Axman6> Don't use String for data - for errors it's ok, but generally you want to use Text (and it will play even better with Aeson)
2022-11-15 00:27:05 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-11-15 00:31:54 +0100twb(~twb@159-196-230-25.9fc4e6.mel.nbn.aussiebb.net)
2022-11-15 00:32:30 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-11-15 00:32:33 +0100 <monochrom> I propose to KISS by re-interpreting "equivalent to" very liberally and relaxedly. Use DeriveGeneric and derive Generic, yes. Then aeson will auto-generate a format. This format is different from the one asked for, sure, but it is "equivalent".
2022-11-15 00:33:04 +0100 <twb> So I use gitit and it works Just Fine. My only beef is when nobody is using it, it's still constantly using a bit of CPU (1% to 3% of a core), and always in kernel "R" state, not "S" state.
2022-11-15 00:33:27 +0100 <twb> Is this a well-known thing, like "oh just add +RTS -idle-harder -RTS to the command line" ?
2022-11-15 00:33:28 +0100 <geekosaur> +RTS -V0?
2022-11-15 00:34:01 +0100 <geekosaur> the RTS wakes up every couple hundredths of a second to do profiling if enabled, check if a GC is needed, etc.
2022-11-15 00:34:59 +0100 <twb> Is there any downside to that?
2022-11-15 00:35:32 +0100 <twb> The docs say "don't use -V, use -C or -i"
2022-11-15 00:35:36 +0100 <geekosaur> it ends up checking that at entry to every function
2022-11-15 00:36:06 +0100 <geekosaur> but if you really want to knock down idle runtime at the expense of general runtime it'll work
2022-11-15 00:36:52 +0100 <geekosaur> also if you're doing lots of FFI to functions that don't like to be interrupted by SIGALRM every couple hundredths of a second
2022-11-15 00:37:25 +0100 <twb> AFAIK gitit doesn't do much FFI; it's pretty much just pandoc + fork+exec git + barebones HTTP
2022-11-15 00:38:16 +0100 <geekosaur> yes, if you had thta particular problem you would know about it, trust me 🙂
2022-11-15 00:38:17 +0100 <Axman6> might be worth compiling it with profiling (if needed?) and getting it to dump an event log to see what it's actually doing
2022-11-15 00:38:38 +0100 <twb> I don't care *that* much
2022-11-15 00:39:00 +0100 <geekosaur> because FFI would be failing in very odd ways
2022-11-15 00:39:04 +0100 <twb> Really my goal is "make gitit not show at the top of top(1) all the time" and maybe "reduce electricity bill slightly
2022-11-15 00:39:19 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Ping timeout: 256 seconds)
2022-11-15 00:40:26 +0100 <twb> OK this whole discussion is moot: Nov 15 10:40:12 heavy gitit[4157461]: gitit: Most RTS options are disabled. Link with -rtsopts to enable them.
2022-11-15 00:40:49 +0100 <twb> I'll just put up with it :P
2022-11-15 00:41:34 +0100 <geekosaur> I would also second profiling, though, as xmonad doesn't show in the top of top
2022-11-15 00:42:00 +0100 <Axman6> +RTS --help would tell you what is enabled I think, and there might be some useful things you can do without recompiling
2022-11-15 00:42:09 +0100machined1od(~machinedg@clnet-b05-118.ikbnet.co.at) (Ping timeout: 256 seconds)
2022-11-15 00:42:12 +0100 <twb> Maybe something I did in the systemd-level hardening pissed off the runtime
2022-11-15 00:43:20 +0100 <twb> https://paste.debian.net/1260728/
2022-11-15 00:43:48 +0100 <twb> MemoryDenyWriteExecute=yes maybe if ghc gets pissy about "NX bit"
2022-11-15 00:44:23 +0100 <Axman6> I'd be surprised, GHC doesn't do any runtime code generation, which is what usually gets tripped up by that, afaiui
2022-11-15 00:44:27 +0100 <monochrom> Oddly, that hypothesis can be easily tested by lauching gitit from a normal shell prompt.
2022-11-15 00:45:41 +0100Maeda(~Maeda@91-161-10-149.subs.proxad.net) (Ping timeout: 268 seconds)
2022-11-15 00:46:57 +0100 <twb> Yeah I did just test with all those commented out. gitit uses no CPU until the first HTTP request, thereafter it stays in R state.
2022-11-15 00:47:24 +0100 <geekosaur> that rules out -V
2022-11-15 00:47:30 +0100aliosablack(~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 240 seconds)
2022-11-15 00:47:52 +0100 <geekosaur> profiling is warranted
2022-11-15 00:48:09 +0100 <monochrom> Does gitit use threads? Is -threaded worth it?
2022-11-15 00:48:41 +0100 <twb> I have no idea if it uses threads. https://github.com/jgm/gitit is the codebase.
2022-11-15 00:49:11 +0100 <monochrom> No worries, I was just hoping that someone else already knows.
2022-11-15 00:49:43 +0100 <twb> And the only interesting thing Debian seems to do is remove plugins at configure time: https://sources.debian.org/src/gitit/0.13.0.0%2Bdfsg-2/debian/rules/#L13
2022-11-15 00:50:13 +0100 <twb> I sort of assume happstack http stuff uses green threads because how could an httpd *not* be threaded
2022-11-15 00:50:36 +0100 <twb> I can at least see there is 1 process and 6 threads inside it, looking at it from the linux side
2022-11-15 00:54:09 +0100slack1256(~slack1256@186.11.56.146)
2022-11-15 00:54:20 +0100 <Guest75> Axman6: thanks for advice on Strings vs. Text. Btw I again realized I need JSON for the schema of the ADT, not for the data (and for the data too in fact). Having schema for ADT want to generate/construct a piece of JavaScript (ReactJS) UI, where e.g. one might make up valid tree structure of that type. I'm thinking I might put the whole thing the
2022-11-15 00:54:21 +0100 <Guest75> other way: have "thing X" with all the metadata, incl. UI (e.g. icons) and then from it generate the ADT def
2022-11-15 00:55:10 +0100 <geekosaur> twb, so it's already using the threaded runtime. (Haskell still has threads without it but they'd be green threads that wouldn't show up that way)
2022-11-15 00:55:33 +0100 <twb> ah right
2022-11-15 00:55:48 +0100 <twb> I was stupid and didn't realize green threads are (obviously!) invisible to linux
2022-11-15 00:55:49 +0100 <geekosaur> also it's possible to use processes instead of threads for an http server, and apache at least can be so configured
2022-11-15 00:56:15 +0100 <twb> yeah or just have crap experience, like busybox httpd :-)
2022-11-15 00:56:36 +0100 <geekosaur> but in haskell there are lots of advantages to using real threads, and things like STM make it easy and safe
2022-11-15 00:56:47 +0100slac26443(~slack1256@191.126.99.192) (Ping timeout: 268 seconds)
2022-11-15 00:57:17 +0100Maeda(~Maeda@91-161-10-149.subs.proxad.net)
2022-11-15 00:57:24 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-11-15 01:01:39 +0100 <twb> Actually tangential, since I'm thinking of it... is "don't bind to 1234/tcp, instead do systemd/launchd socket activation (i.e. use already-open file descriptor 3)" an easy thing to add to a haskell daemon?
2022-11-15 01:02:22 +0100 <twb> I know how to do it in C but not in haskell
2022-11-15 01:04:14 +0100Techcable(~Techcable@user/Techcable) (Ping timeout: 260 seconds)
2022-11-15 01:05:42 +0100 <Axman6> if it's doable in C using standard system calls it should be doable in Haskell
2022-11-15 01:07:30 +0100 <jean-paul[m]> I keep thinking it would be cool if there were a standard way to make transport and protocol orthogonal in Haskell apps/libraries. But there doesn't seem to be - it seems more like all the libraries have their own custom "open a socket and bind it to something" functionality built in that's not extensible or composeable.
2022-11-15 01:09:16 +0100 <jean-paul[m]> with the Twisted library in Python most libraries support systemd socket activation out of the box - you just pass in an `AdoptedStreamServerEndpoint` instead of a `TCP4StreamServer` or whatever.
2022-11-15 01:09:26 +0100 <jean-paul[m]> does this kind of thing exist anywhere in the Haskell ecosystem?
2022-11-15 01:09:26 +0100mmhat(~mmh@p200300f1c71c150dee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1)
2022-11-15 01:11:26 +0100 <twb> jean-paul[m]: so the app still has to be patched?
2022-11-15 01:11:58 +0100 <twb> as an end user, what I'd _ideally_ like is for daemons to just go "I noticed systemd socket-activated me, so automatically using that"
2022-11-15 01:14:18 +0100 <Axman6> GHC's Handle type (and Handle__) is quite flexible, I'm sure all this could be done, but whether it has been or not, I couldn't say. https://hackage.haskell.org/package/base-4.14.1.0/docs/src/GHC.IO.Handle.Types.html#Handle
2022-11-15 01:14:38 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-15 01:16:43 +0100CiaoSen(~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2022-11-15 01:17:44 +0100Tuplanolla(~Tuplanoll@91-159-68-194.elisa-laajakaista.fi) (Quit: Leaving.)
2022-11-15 01:20:02 +0100CiaoSen(~Jura@p5dcc1f3a.dip0.t-ipconnect.de)
2022-11-15 01:23:17 +0100 <geekosaur> I think you won't find much oif that because base tries too hard to be crossplatform and you straight-up can't do that with windows sockets
2022-11-15 01:23:44 +0100 <geekosaur> python e.g. doesn't care so much about crossplatform
2022-11-15 01:29:02 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net)
2022-11-15 01:29:03 +0100 <jean-paul[m]> twb: If it's a library, those things are generally accepted as an argument. If it's an application, there's a convention for a string representation that can be given as input (in config file or argv or whatever) - eg "systemd:name=web-server" or "tcp:interface=127.0.0.1:port=12345"
2022-11-15 01:30:09 +0100kenaryn(~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Quit: leaving)
2022-11-15 01:30:12 +0100 <twb> sort of surprising Windows doesn't have socket activation yet
2022-11-15 01:30:40 +0100 <geekosaur> it may, it just doesn't use file descriptors to represent sockets, they're a completely different namespace
2022-11-15 01:30:51 +0100 <twb> gotcha
2022-11-15 01:31:06 +0100 <jean-paul[m]> Indeed. You can pass "Handles" across processes in Windows. Just not with any of the APIs that POSIX people are used to.
2022-11-15 01:31:11 +0100 <geekosaur> similarly withh mailbboxes and other non-file things
2022-11-15 01:32:06 +0100kenaryn(~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr)
2022-11-15 01:32:11 +0100kenaryn(~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Client Quit)
2022-11-15 01:32:24 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-11-15 01:33:49 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-11-15 01:33:50 +0100slac65015(~slack1256@191.126.99.192)
2022-11-15 01:35:50 +0100slack1256(~slack1256@186.11.56.146) (Ping timeout: 240 seconds)
2022-11-15 01:36:33 +0100CiaoSen(~Jura@p5dcc1f3a.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
2022-11-15 01:37:07 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds)
2022-11-15 01:38:13 +0100CiaoSen(~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-11-15 01:39:48 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net)
2022-11-15 01:40:49 +0100emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2022-11-15 01:41:00 +0100polomoney
2022-11-15 01:57:30 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-15 01:58:41 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-11-15 02:00:09 +0100ChaiTRex(~ChaiTRex@user/chaitrex)
2022-11-15 02:01:22 +0100califax(~califax@user/califx) (Remote host closed the connection)
2022-11-15 02:04:13 +0100califax(~califax@user/califx)
2022-11-15 02:08:17 +0100srz(~srz@179.36.85.167)
2022-11-15 02:13:15 +0100xcmw(~textual@50.93.222.82) (Ping timeout: 268 seconds)
2022-11-15 02:13:59 +0100Kaipei(~Kaiepi@108.175.84.104) (Ping timeout: 260 seconds)
2022-11-15 02:15:30 +0100xff0x(~xff0x@2405:6580:b080:900:fc69:8fe6:1c5d:8fdb) (Ping timeout: 240 seconds)
2022-11-15 02:16:47 +0100acidjnk(~acidjnk@p200300d6e7137a015d19df638f338baf.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-11-15 02:17:10 +0100Maeda(~Maeda@91-161-10-149.subs.proxad.net) (Ping timeout: 240 seconds)
2022-11-15 02:18:43 +0100moneypolo
2022-11-15 02:19:03 +0100polomoney
2022-11-15 02:21:02 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-11-15 02:21:03 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2022-11-15 02:21:03 +0100wroathe(~wroathe@user/wroathe)
2022-11-15 02:21:42 +0100moneypolo
2022-11-15 02:24:12 +0100Maeda(~Maeda@91-161-10-149.subs.proxad.net)
2022-11-15 02:24:18 +0100 <kronicmage> anyone know how to make stack compile a project with -XGHC2021 by default?
2022-11-15 02:24:36 +0100 <kronicmage> it doesn't seem to accept it in the `default-extensions:` field of package.yaml
2022-11-15 02:25:39 +0100 <geekosaur> it should be language, not an extension as such. but I have no idea whether package.yaml lets you specify that; you may have to switch to using a cabal file
2022-11-15 02:30:34 +0100justsomeguy(~justsomeg@user/justsomeguy)
2022-11-15 02:34:20 +0100justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2022-11-15 02:37:22 +0100dfee(~dfee@162-227-164-101.lightspeed.sntcca.sbcglobal.net) (Quit: dfee)
2022-11-15 02:37:56 +0100evanvarvell(~evanvarve@097-088-181-216.res.spectrum.com)
2022-11-15 02:39:48 +0100 <sm> some related discussion at https://github.com/commercialhaskell/stack/issues/5739 .. have you got an up to date stack ?
2022-11-15 02:41:02 +0100razetime(~quassel@117.193.3.56)
2022-11-15 02:42:33 +0100 <kronicmage> sm: yes according to ghcup
2022-11-15 02:42:53 +0100 <kronicmage> the thread seems to imply it should have the correct behaviour by default now but that doesn't seem to be the case for me
2022-11-15 02:46:14 +0100ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds)
2022-11-15 02:47:54 +0100ec(~ec@gateway/tor-sasl/ec)
2022-11-15 02:53:24 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 02:54:30 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2022-11-15 02:55:18 +0100Guest75(~Guest75@178.141.177.81) (Ping timeout: 260 seconds)
2022-11-15 02:57:54 +0100 <sm> got a paste of your yaml ?
2022-11-15 02:58:19 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-15 03:02:20 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 03:04:02 +0100 <Axman6> Generally, cabal is better at keeping up to date with GHC for things like this
2022-11-15 03:05:01 +0100 <kronicmage> sm: https://paste.tomsmeding.com/E1RImxWt
2022-11-15 03:05:58 +0100caryhartline(~caryhartl@2600:1700:2d0:8d30:1d0b:eb23:aba0:7ca3) (Quit: caryhartline)
2022-11-15 03:06:43 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 260 seconds)
2022-11-15 03:08:25 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Quit: Going elsewhere)
2022-11-15 03:09:28 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-15 03:09:37 +0100 <ephemient> I think that's a hpack issue, not stack specifically: https://github.com/sol/hpack/issues/481
2022-11-15 03:10:46 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Client Quit)
2022-11-15 03:11:50 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-15 03:12:41 +0100frase(~Fraser@159.196.13.21)
2022-11-15 03:12:54 +0100 <sm> kronicmage: I'm not finding it in hpack changelog, but judging by dates that PR adding `default-language` should be in hpack 0.35, which is probably in your stack --version
2022-11-15 03:13:19 +0100 <sm> so: default-language: GHC2021
2022-11-15 03:13:34 +0100 <frase> FOSDEM 2023 Haskell devroom CfP: https://discourse.haskell.org/t/fosdem-2023-haskell-devroom-call-for-participation/5310
2022-11-15 03:13:47 +0100 <ephemient> or, if you get rid of package.yaml and just use myproject.cabal, I would expect stack (using the cabal library) to handle GHC2021
2022-11-15 03:14:55 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 268 seconds)
2022-11-15 03:15:04 +0100 <sm> "FOSDEM, Europe’s largest free software conference, will feature a Haskell devroom (specialist track). The Call for Participation is open now, until 2022-11-28. ... FOSDEM 2023 will be held on 4 & 5 February 2023, in Brussels. For more information see the official site: FOSDEM 2023 - Home. The Haskell devroom will take place on Sunday 5 February, from 13:10 to 17:00 UTC+1. Presentations will be also be streamed live and published afterwards."
2022-11-15 03:17:25 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds)
2022-11-15 03:17:44 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Quit: Going elsewhere)
2022-11-15 03:18:36 +0100 <sm> kronicmage: oh correction: in package.yaml it would be `language: GHC2021`, per docs: https://github.com/sol/hpack#common-fields
2022-11-15 03:19:39 +0100ddellacosta(~ddellacos@89.45.224.150)
2022-11-15 03:20:03 +0100 <kronicmage> sm: ah i guess the latest stack still doesn't ship the appropriate hpack version then
2022-11-15 03:20:08 +0100 <kronicmage> standalone hpack can do it, but my stack still cannot
2022-11-15 03:20:21 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-15 03:20:33 +0100twb(~twb@159-196-230-25.9fc4e6.mel.nbn.aussiebb.net) (rcirc on GNU Emacs 28.1)
2022-11-15 03:20:34 +0100 <sm> stack --version tells which hpack you have built in to stack. The latest stack has the latest hpack
2022-11-15 03:20:43 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Client Quit)
2022-11-15 03:20:49 +0100 <sm> 0.35 on my machine
2022-11-15 03:22:03 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-15 03:22:08 +0100 <geekosaur> alos, make sure you're using the right resolver: one based on 8.10.7 or 9.0.2 won't support GHC2021
2022-11-15 03:22:20 +0100 <geekosaur> that came in with ghc 9.2.x
2022-11-15 03:22:42 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2022-11-15 03:25:13 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2022-11-15 03:28:11 +0100bobbingbob(~bobbingbo@2604:3d09:207f:f650::b469)
2022-11-15 03:34:15 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds)
2022-11-15 03:34:43 +0100forell(~forell@user/forell) (Ping timeout: 260 seconds)
2022-11-15 03:37:10 +0100CiaoSen(~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2022-11-15 03:39:23 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds)
2022-11-15 03:41:04 +0100forell(~forell@user/forell)
2022-11-15 03:41:45 +0100mixfix41(~sdenynine@user/mixfix41)
2022-11-15 03:42:18 +0100off^(~off@76.145.185.103)
2022-11-15 03:43:22 +0100srz(~srz@179.36.85.167) (Remote host closed the connection)
2022-11-15 03:44:31 +0100ystael(~ystael@user/ystael) (Ping timeout: 260 seconds)
2022-11-15 03:44:33 +0100 <kronicmage> geekosaur: ah yes that's it
2022-11-15 03:44:41 +0100 <kronicmage> the lts is still on ghc 9.0.2 alas :/
2022-11-15 03:45:53 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-11-15 03:46:16 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-11-15 03:48:32 +0100 <kronicmage> anyone know how to use haskell-language-server with alex/happy files?
2022-11-15 03:56:57 +0100jinsun(~jinsun@user/jinsun)
2022-11-15 03:59:30 +0100sh1n(~sh1n@186.152.126.112) (Remote host closed the connection)
2022-11-15 03:59:45 +0100 <sm> twb: nice to hear of gitit users.. maybe there's something in the issue tracker ?
2022-11-15 04:00:26 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 04:04:50 +0100jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection)
2022-11-15 04:05:01 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds)
2022-11-15 04:05:10 +0100hsw_(~hsw@112-104-142-182.adsl.dynamic.seed.net.tw)
2022-11-15 04:05:56 +0100wroathe_(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-11-15 04:05:56 +0100wroathe_(~wroathe@207-153-38-140.fttp.usinternet.com) (Client Quit)
2022-11-15 04:06:43 +0100hsw(~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 256 seconds)
2022-11-15 04:07:09 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-11-15 04:07:56 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2022-11-15 04:09:38 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 04:10:07 +0100euandreh(~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds)
2022-11-15 04:11:07 +0100td_(~td@83.135.9.3) (Ping timeout: 260 seconds)
2022-11-15 04:12:23 +0100forell(~forell@user/forell) (Ping timeout: 256 seconds)
2022-11-15 04:12:47 +0100td_(~td@83.135.9.38)
2022-11-15 04:14:39 +0100youziqi(~youziqi@103.37.140.125) (Ping timeout: 256 seconds)
2022-11-15 04:16:48 +0100youziqi(~youziqi@103.37.140.93)
2022-11-15 04:18:26 +0100forell(~forell@user/forell)
2022-11-15 04:19:30 +0100bobbingbob(~bobbingbo@2604:3d09:207f:f650::b469) (Ping timeout: 240 seconds)
2022-11-15 04:20:46 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-15 04:24:36 +0100zeenk(~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!)
2022-11-15 04:26:42 +0100infinity0(~infinity0@pwned.gg) (Ping timeout: 252 seconds)
2022-11-15 04:28:10 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 04:29:26 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 04:32:47 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds)
2022-11-15 04:33:13 +0100euandreh(~Thunderbi@179.214.113.107) (Remote host closed the connection)
2022-11-15 04:33:58 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 04:37:50 +0100ddellacosta(~ddellacos@89.45.224.150) (Ping timeout: 240 seconds)
2022-11-15 04:38:27 +0100razetime(~quassel@117.193.3.56) (Ping timeout: 256 seconds)
2022-11-15 04:40:09 +0100euandreh(~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds)
2022-11-15 04:42:04 +0100finsternis(~X@23.226.237.192)
2022-11-15 04:42:51 +0100terrorjack(~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat)
2022-11-15 04:44:10 +0100terrorjack(~terrorjac@2a01:4f8:1c1e:509a::1)
2022-11-15 04:48:02 +0100shriekingnoise(~shrieking@186.137.167.202) (Ping timeout: 268 seconds)
2022-11-15 04:53:50 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds)
2022-11-15 04:54:47 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 04:55:50 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2022-11-15 04:56:01 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Ping timeout: 256 seconds)
2022-11-15 04:58:51 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 05:01:33 +0100shriekingnoise(~shrieking@186.137.167.202)
2022-11-15 05:05:39 +0100slac65015(~slack1256@191.126.99.192) (Read error: Connection reset by peer)
2022-11-15 05:08:22 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 05:10:14 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 05:13:13 +0100euandreh(~Thunderbi@179.214.113.107) (Remote host closed the connection)
2022-11-15 05:15:13 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 05:19:43 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-15 05:23:52 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Remote host closed the connection)
2022-11-15 05:25:06 +0100iteratee(~kyle@162.218.222.107) (Read error: Connection reset by peer)
2022-11-15 05:27:08 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2022-11-15 05:28:19 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds)
2022-11-15 05:30:17 +0100iteratee(~kyle@162.218.222.107)
2022-11-15 05:31:01 +0100razetime(~quassel@117.193.3.56)
2022-11-15 05:35:42 +0100Genius123(~Genius123@71.169.167.129)
2022-11-15 05:35:48 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 05:40:27 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 05:45:19 +0100Vajb(~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer)
2022-11-15 05:45:35 +0100Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi)
2022-11-15 05:49:19 +0100off^(~off@76.145.185.103) (Remote host closed the connection)
2022-11-15 05:49:35 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 05:50:50 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 05:51:33 +0100youziqi(~youziqi@103.37.140.93) (Ping timeout: 268 seconds)
2022-11-15 05:51:33 +0100mbuf(~Shakthi@49.204.118.25)
2022-11-15 05:51:38 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds)
2022-11-15 05:51:57 +0100youziqi(~youziqi@103.37.140.125)
2022-11-15 05:53:04 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-15 05:57:47 +0100euandreh(~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds)
2022-11-15 05:58:08 +0100Techcable(~Techcable@user/Techcable)
2022-11-15 06:02:54 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.)
2022-11-15 06:12:27 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-15 06:21:19 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds)
2022-11-15 06:29:10 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds)
2022-11-15 06:31:11 +0100Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer)
2022-11-15 06:31:16 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection)
2022-11-15 06:31:18 +0100Vajb(~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d)
2022-11-15 06:31:34 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 06:34:01 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2022-11-15 06:34:05 +0100wroathe(~wroathe@user/wroathe) (Quit: leaving)
2022-11-15 06:34:12 +0100zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2022-11-15 06:34:23 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2022-11-15 06:34:24 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2022-11-15 06:34:24 +0100wroathe(~wroathe@user/wroathe)
2022-11-15 06:35:06 +0100chromoblob(~user@37.113.164.122)
2022-11-15 06:35:22 +0100zaquest(~notzaques@5.130.79.72)
2022-11-15 06:54:49 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-15 06:55:01 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 256 seconds)
2022-11-15 06:56:55 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds)
2022-11-15 06:58:50 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2022-11-15 07:00:57 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2022-11-15 07:03:44 +0100michalz(~michalz@185.246.207.197)
2022-11-15 07:09:11 +0100wroathe(~wroathe@user/wroathe) (Quit: leaving)
2022-11-15 07:09:33 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-15 07:11:44 +0100califax(~califax@user/califx) (Ping timeout: 255 seconds)
2022-11-15 07:12:33 +0100califax(~califax@user/califx)
2022-11-15 07:13:59 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2022-11-15 07:20:55 +0100aliosablack(~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1)
2022-11-15 07:23:45 +0100califax_(~califax@user/califx)
2022-11-15 07:24:44 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 07:27:30 +0100califax(~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in)
2022-11-15 07:27:32 +0100califax_califax
2022-11-15 07:44:20 +0100pieguy128(~pieguy128@65.93.192.212) (Quit: ZNC 1.8.2 - https://znc.in)
2022-11-15 07:44:22 +0100kenran(~user@user/kenran)
2022-11-15 07:44:43 +0100pieguy128(~pieguy128@65.93.192.212)
2022-11-15 07:53:21 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 07:57:21 +0100 <tomsmeding> dminuoso: how do I efficiently parse an array using flatparse?
2022-11-15 07:59:01 +0100 <tomsmeding> as in, suppose I'm parsing a binary file format and I see a header for a list of N items, and I want to put those items in an array without an intermediate phase in a list
2022-11-15 07:59:03 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds)
2022-11-15 07:59:16 +0100 <tomsmeding> (or a non-binary file format, for that matter)
2022-11-15 07:59:36 +0100 <tomsmeding> frase: not yet listed on https://fosdem.org/2023/schedule/tracks/
2022-11-15 08:00:34 +0100titibandit(~titibandi@xdsl-78-35-167-196.nc.de)
2022-11-15 08:00:42 +0100machinedgod(~machinedg@clnet-p10-126.ikbnet.co.at)
2022-11-15 08:03:40 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 08:05:59 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds)
2022-11-15 08:15:11 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds)
2022-11-15 08:16:13 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-15 08:16:33 +0100TheCreatorOfCrea(~TheCreato@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de)
2022-11-15 08:18:45 +0100 <TheCreatorOfCrea> Hi. I’m stumped… I thought this syntax was normal Haskell: data T = T { x :: Eq a => a }
2022-11-15 08:18:59 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2022-11-15 08:20:19 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 08:20:32 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7)
2022-11-15 08:20:53 +0100 <TheCreatorOfCrea> If it’s not valid, then how do I express that A field in my record should be a function that can take any value of a certain class? As in: data Betty = Betty { speak :: Speakable s => s -> IO () }
2022-11-15 08:21:55 +0100Kaipei(~Kaiepi@108.175.84.104)
2022-11-15 08:23:35 +0100 <c_wraith> TheCreatorOfCrea: those are existential, because they contain a type that doesn't appear in the head.
2022-11-15 08:23:42 +0100 <sm> TheCreatorOfCrea: I believe you would have to declare s and its constraint the left hand side, ie make s a parameter of Betty
2022-11-15 08:24:05 +0100 <c_wraith> TheCreatorOfCrea: existentials probably aren't what you want. Especially not the existential typeclass anti-pattern
2022-11-15 08:24:51 +0100 <c_wraith> As much as you think you want the constraint in the data type, that's not really a useful spot to have it.
2022-11-15 08:24:51 +0100 <TheCreatorOfCrea> sm: Yeah, I read that giving contexts to data type declarations would result in cumbersomeness. :)
2022-11-15 08:25:06 +0100 <c_wraith> Constraints should be where they provide value
2022-11-15 08:25:42 +0100 <TheCreatorOfCrea> sm: I want to constrain the `speak` function’s type. Because that’s a normal thing we do to function types.
2022-11-15 08:26:03 +0100 <c_wraith> constrain places where the constraint lets you do something
2022-11-15 08:26:07 +0100 <c_wraith> Otherwise, don't
2022-11-15 08:26:38 +0100 <TheCreatorOfCrea> But somehow, GHC complains when I use a type signature with a context in record syntax, but not when I do that for top level type signatures…
2022-11-15 08:26:52 +0100 <sm> record accessor functions are expected, required I assume, to operate on the record - not just have any arbitrary type you choose
2022-11-15 08:26:54 +0100 <c_wraith> yes, because you're creating existentials
2022-11-15 08:27:11 +0100 <c_wraith> existential types require an extension
2022-11-15 08:27:17 +0100cheater(~Username@user/cheater) (Remote host closed the connection)
2022-11-15 08:28:07 +0100 <TheCreatorOfCrea> sm: Yes, but they be functions to have additional parameters, and those parameters can be type variables, so why can’t they class-constrained type variables?
2022-11-15 08:28:22 +0100 <sm> hmm, maybe listen to c_wraith not me, it's late here
2022-11-15 08:28:31 +0100 <sm> and I don't have GHC in front of me
2022-11-15 08:28:34 +0100 <c_wraith> TheCreatorOfCrea: because you're creating existential types
2022-11-15 08:28:51 +0100chromoblob(~user@37.113.164.122)
2022-11-15 08:29:36 +0100 <TheCreatorOfCrea> c_wraith: Ok, I’ll look into using existentials is the right thing to do here.  (I don’t want to use it just because things don’t work that I expect to, but because it makes actually sense.) Can you tell me what concrete language extension that would be?
2022-11-15 08:29:55 +0100 <c_wraith> It's not what you want.
2022-11-15 08:29:59 +0100 <TheCreatorOfCrea> sm: I’m just as tired. :)
2022-11-15 08:30:14 +0100 <TheCreatorOfCrea> c_wraith: How did you determine that?
2022-11-15 08:30:38 +0100 <c_wraith> because you're not writing code in one of the patterns where it helps more than it causes problems
2022-11-15 08:31:34 +0100 <c_wraith> TheCreatorOfCrea: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/existential_quantification.html this is the section of the user guide that describes the extension
2022-11-15 08:31:43 +0100 <TheCreatorOfCrea> c_wraith: How could you possibly know that? (Seriously, all I told you was an analogy of an extremely simplified essence of the problem I had. :)
2022-11-15 08:31:57 +0100 <c_wraith> TheCreatorOfCrea: because you're describing the existential typeclass anti-pattern
2022-11-15 08:32:11 +0100 <TheCreatorOfCrea> c_wraith: Not saying you’re wrong, btw.
2022-11-15 08:35:18 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2022-11-15 08:35:25 +0100cheater(~Username@user/cheater)
2022-11-15 08:36:12 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 08:38:24 +0100euandreh(~Thunderbi@179.214.113.107) (Remote host closed the connection)
2022-11-15 08:40:31 +0100cheater(~Username@user/cheater) (Read error: Connection reset by peer)
2022-11-15 08:43:09 +0100 <TheCreatorOfCrea> c_wraith: Here’s a less simplified version: I have a data Visible outM = Visible { draw :: AreaFlex -> outM (), … }, that is used for objects that should be drawn into the surface outM at the pixel location given by AreaFlex. AreaFlex offers a minimum, ideal and maximum area, so the object can choose what suits it best. But I also have a
2022-11-15 08:43:10 +0100 <TheCreatorOfCrea> AreaAbs, that offers only one size. Now I want draw to be able to use both AreaFlex and AreaAbs, and in the future two more types or area definitions. How would I do that the right way then?
2022-11-15 08:44:02 +0100 <TheCreatorOfCrea> s/or/of/
2022-11-15 08:45:11 +0100 <TheCreatorOfCrea> c_wraith: The objects are so state can be carried in the closure.
2022-11-15 08:45:25 +0100 <c_wraith> Hmm. Ok, I misread what you were looking for based on your first example not being a function.
2022-11-15 08:45:43 +0100 <c_wraith> you want to require that the functions inside the record are polymorphic?
2022-11-15 08:46:51 +0100cheater(~Username@user/cheater)
2022-11-15 08:47:23 +0100 <TheCreatorOfCrea> c_wraith: One of the functions only, yes.
2022-11-15 08:47:49 +0100 <TheCreatorOfCrea> c_wraith: Possibly without the whole type turning into existential dread. ;)
2022-11-15 08:47:59 +0100 <tomsmeding> TheCreatorOfCrea: would this be an acceptable variant: data Visible outM area = Visible { draw :: area -> outM (), ... }, where the functions taking a Visible have an "IsArea area =>" constraint (or whatever your typeclass is
2022-11-15 08:48:10 +0100 <tomsmeding> )
2022-11-15 08:48:15 +0100 <c_wraith> TheCreatorOfCrea: then you want a higher-rank type
2022-11-15 08:48:25 +0100 <c_wraith> TheCreatorOfCrea: the RankNTypes extension will do the job
2022-11-15 08:48:39 +0100 <c_wraith> (the reason why it's a higher-rank type is that it makes the type of the constructor higher-rank)
2022-11-15 08:49:06 +0100 <tomsmeding> (then you get: { draw :: forall area. IsArea area => area -> outM (), ...})
2022-11-15 08:49:08 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-15 08:49:26 +0100 <TheCreatorOfCrea> tomsmeding: I already tried that, and realized that that would mean carrying that area parameter through all the other types and functions that use it. I don’t know if that is necessary.
2022-11-15 08:49:39 +0100 <tomsmeding> it lets you avoid higher-rank types :p
2022-11-15 08:49:52 +0100 <tomsmeding> which is not necessarily something to want per se, but it makes type inference nicer sometiems
2022-11-15 08:50:18 +0100 <tomsmeding> a situation where you _cannot_ do the simple thing I mentioned is if you want a list of Visibles with different 'area' variables
2022-11-15 08:50:20 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving)
2022-11-15 08:50:31 +0100 <TheCreatorOfCrea> Yes, higher rank types seem very close to that existential thing, no? ^^
2022-11-15 08:50:42 +0100 <c_wraith> very close, but the exact opposite. :)
2022-11-15 08:50:51 +0100 <c_wraith> I like higher-rank types quite a lot
2022-11-15 08:50:58 +0100 <c_wraith> They actually are closely related.
2022-11-15 08:51:00 +0100 <tomsmeding> higher-rank types is having nested foralls in types (i.e. universally quantified types); existenials are existentially quantified types
2022-11-15 08:51:04 +0100 <c_wraith> mathematically they're duals
2022-11-15 08:51:16 +0100 <tomsmeding> you can encode the latter with the former, and in haskell you have to, because haskell doesn't have native existentials (yet) :)
2022-11-15 08:51:26 +0100 <c_wraith> uhc does.
2022-11-15 08:51:32 +0100 <tomsmeding> O.o
2022-11-15 08:51:40 +0100 <c_wraith> but you can't put a constraint on an existentially-quantified type
2022-11-15 08:51:44 +0100 <TheCreatorOfCrea> tomsmeding: Yes, the lists would indeed all be passed the same area type, since they would all be drawn to the same area by definition.
2022-11-15 08:51:45 +0100 <tomsmeding> okay, *ghc doesn't have native existentials
2022-11-15 08:53:11 +0100use-value1(~Thunderbi@2a00:23c6:8a03:2f01:d5b6:b99f:4049:77a7)
2022-11-15 08:54:34 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:bd85:df8c:c85c:33a7)
2022-11-15 08:55:07 +0100 <TheCreatorOfCrea> c_wraith: I never got the gist of what “dual” actually means other than “a very specific kind of mirrored/opposite/symmetry thing, but I don’t know in what way specifically”. (I find math syntax incomprehensible, because I work so differently, so most math pages look like very hard to parse gibberish to me. ;)
2022-11-15 08:55:16 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-15 08:55:30 +0100use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Ping timeout: 240 seconds)
2022-11-15 08:55:30 +0100use-value1use-value
2022-11-15 08:55:40 +0100 <tomsmeding> "dual" is not well-defined
2022-11-15 08:55:47 +0100 <tomsmeding> it kinda means what you just wrote :p
2022-11-15 08:55:56 +0100 <c_wraith> In this case, it means that you can represent either one in terms of the other, with some juggling
2022-11-15 08:55:58 +0100 <tomsmeding> in specific contexts it has very specific meanings, but in general it's just this vague concept
2022-11-15 08:56:40 +0100 <TheCreatorOfCrea> lol. okay, I’m relieved then. :D …
2022-11-15 08:56:49 +0100causal(~user@50.35.83.177)
2022-11-15 08:57:02 +0100 <c_wraith> like... `Foo -> exists a. a' is the same thing as `Foo -> (forall a. a -> b) -> b'
2022-11-15 08:57:06 +0100 <tomsmeding> usually there's some kind of "flipping arrows" involved, where if you write function types with arrows (like in haskell), the arrows go the other way in the dual
2022-11-15 08:57:16 +0100 <tomsmeding> but not always
2022-11-15 08:57:26 +0100 <c_wraith> you can change between exists and forall with a CPS transform
2022-11-15 08:59:04 +0100 <TheCreatorOfCrea> c_wraith: At least that much I already know. :) I didn’t make the link between “exists (in the logic context)” and “existential (quantification, in the Haskell context)" yet. But it should have been obvious.
2022-11-15 08:59:26 +0100 <c_wraith> ah, sorry. yes, it's *that* existential!
2022-11-15 08:59:41 +0100TheCreatorOfCreaExistentialDread
2022-11-15 08:59:46 +0100 <tomsmeding> :p
2022-11-15 09:00:01 +0100 <tomsmeding> ooh, precisely 16 chars
2022-11-15 09:01:19 +0100 <ExistentialDread> Thanks a lot to everyone, btw. :) This channel is always appreciated a lot. … And I’m sorry for being a bit upset sometimes when I come here. I conveniently blame it on my genes. ;)
2022-11-15 09:08:53 +0100razetime(~quassel@117.193.3.56) (Ping timeout: 268 seconds)
2022-11-15 09:10:11 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de)
2022-11-15 09:10:15 +0100DDR(~DDR@2604:3d08:4c7f:8250:7335:db3e:c155:4272) (Ping timeout: 260 seconds)
2022-11-15 09:16:42 +0100 <ExistentialDread> BTW: Can it be said that existential quantification (∃) is problematic because an implementation might not exist (as in, in some way analogous to partial functions and to failing at runtime), while universal quantification (∀) is not, because all implementations have to exist?
2022-11-15 09:17:08 +0100 <tomsmeding> an implementation necessarily exists, because there, well, exists one?
2022-11-15 09:17:20 +0100 <dminuoso> Given that you can mechanically transform one into the other, I would say if one must exist, the other does anyway.
2022-11-15 09:18:05 +0100 <dminuoso> tomsmeding: By `array` do you mean `Array`?
2022-11-15 09:18:14 +0100 <tomsmeding> dminuoso: yes, or Vector, or similar things
2022-11-15 09:18:56 +0100 <tomsmeding> I can see how to build a list, but not how to build an Array without an intermediate list
2022-11-15 09:19:01 +0100 <dminuoso> tomsmeding: Well, you can simply parse into a CStringLen I suppose.
2022-11-15 09:19:02 +0100 <tomsmeding> (relevant for very large inputs)
2022-11-15 09:19:10 +0100 <dminuoso> And then memcpy it out
2022-11-15 09:19:17 +0100 <tomsmeding> oh with IO
2022-11-15 09:19:17 +0100 <dminuoso> (Or have your Array point into the buffer)
2022-11-15 09:19:28 +0100 <dminuoso> Well you dont need IO to create a CStringLen
2022-11-15 09:19:36 +0100 <dminuoso> You just have to worry about lifetime
2022-11-15 09:19:51 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2022-11-15 09:19:51 +0100 <tomsmeding> in my case the elements of the array wouldn't be bytes
2022-11-15 09:19:58 +0100 <tomsmeding> they would be further parseable things
2022-11-15 09:20:12 +0100 <dminuoso> Is the memory represeentation the same?
2022-11-15 09:20:16 +0100 <dminuoso> (Or well I guess not?)
2022-11-15 09:20:38 +0100 <tomsmeding> not necessarily, array of Texts is a possibility
2022-11-15 09:21:07 +0100 <dminuoso> It's a good question actually, Im fairly sure this will involve unsafePerformIO'ing
2022-11-15 09:21:22 +0100 <tomsmeding> that's what I was fearing
2022-11-15 09:21:29 +0100 <tomsmeding> if Parser was ParserT then you could do this
2022-11-15 09:21:30 +0100 <dminuoso> Well, without IO you dont have a mechanism to copy a buffer over.
2022-11-15 09:21:35 +0100 <tomsmeding> but that brings other downsides
2022-11-15 09:21:43 +0100 <dminuoso> Yeah
2022-11-15 09:21:59 +0100 <Franciman> maybe with linear types one day
2022-11-15 09:22:08 +0100 <dminuoso> But I think any use of unsafePerformIO here is mildly safe as long as you can force them before the lifetime of the original buffer expires.
2022-11-15 09:22:11 +0100 <tomsmeding> hmmm, well linear types are here
2022-11-15 09:22:30 +0100razetime(~quassel@117.193.3.56)
2022-11-15 09:22:44 +0100 <tomsmeding> dminuoso: prototype use case: csv parser
2022-11-15 09:23:04 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7)
2022-11-15 09:23:05 +0100 <tomsmeding> tried to write a csv parser in parsec, worked but used GOBS of memory and was slow
2022-11-15 09:24:09 +0100 <dminuoso> tomsmeding: Im almost tempted to say, do it the other way around.
2022-11-15 09:24:16 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-11-15 09:24:45 +0100 <dminuoso> That is, start with IO + a Ptr of some kind, and invoke flatparse for every substring. Given that flatparse has essentially no overhead, this is probably better than unsafePerformIO'ing in flatparse
2022-11-15 09:26:15 +0100 <tomsmeding> hmm, but I'd like my csv to be an array of arrays
2022-11-15 09:26:21 +0100 <dminuoso> So?
2022-11-15 09:26:25 +0100 <tomsmeding> though I guess having an intermediate list for the rows is less bad
2022-11-15 09:26:38 +0100pavonia(~user@user/siracusa)
2022-11-15 09:26:46 +0100 <tomsmeding> dminuoso: if I only invoke flatparse for the cell values, I'm not getting much use out of flatparse :p
2022-11-15 09:27:06 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 09:27:08 +0100 <tomsmeding> which is a valid conclusion, albeit a somewhat unsatisfying one
2022-11-15 09:27:09 +0100 <dminuoso> That depends on whether the cell values require actual parsing or not.
2022-11-15 09:27:18 +0100 <tomsmeding> true
2022-11-15 09:27:30 +0100 <dminuoso> That is, if you only intend to read an already UTF8 encoded string into a Text (post 2.0), yeah flatparse wont do much
2022-11-15 09:28:02 +0100 <dminuoso> For a while I longed for an IOful Parser too
2022-11-15 09:28:02 +0100 <tomsmeding> well there are quotes in csv sometimes, so those need to be parsed
2022-11-15 09:28:07 +0100 <tomsmeding> but apart from that, not much
2022-11-15 09:29:00 +0100 <dminuoso> I mean ultimately its not much work to put that in, but it will prevent a lot of cute optimizations
2022-11-15 09:29:16 +0100 <dminuoso> Since if we pass a State# RealWorld token around, it can no longer freely reorder things as it pleases
2022-11-15 09:29:28 +0100 <dminuoso> (But I guess the reordering is already hard anyway)
2022-11-15 09:29:39 +0100 <tomsmeding> yeah allowing arbitrary IO doesn't feel like the correct solution either
2022-11-15 09:29:40 +0100 <ExistentialDread> dminuoso: I recently saw an even more evil function than unsafePerformIO, but I can’t find it anymore. I think it was even worse than unsafeCoerce#.
2022-11-15 09:29:51 +0100 <dminuoso> ExistentialDread: accursedUnutterablePerformIO?
2022-11-15 09:29:52 +0100 <tomsmeding> accursedUnutterablePerformIO?
2022-11-15 09:29:53 +0100 <tomsmeding> lol
2022-11-15 09:30:06 +0100 <dminuoso> It's not quite worse than unsafeCoerce# though
2022-11-15 09:30:13 +0100 <tomsmeding> it's in bytestring, if you want to find it
2022-11-15 09:30:29 +0100 <dminuoso> It's just more evil in that it can give the appearance of working but producing a lot of indirect problems
2022-11-15 09:30:31 +0100 <tomsmeding> the # makes it scarier
2022-11-15 09:30:40 +0100 <dminuoso> whereas misuse of unsafeCoerce# tends to outright crash your program
2022-11-15 09:31:00 +0100 <tomsmeding> crash >>>>>> spurious failures
2022-11-15 09:31:30 +0100 <ExistentialDread> dminuoso: Yes! That was it! But yes, only the description is worse/funnier. :)
2022-11-15 09:32:11 +0100 <dminuoso> ExistentialDread: What makes accursedUnutterablePerformIO so evil, imagine that an IO action has two `malloc 4096` inside somewhere for some reason. Now, if you use that primitive, it will expose these internal mallocs for reordering... or.. it will just say "look at that, two uses of `malloc 4096` - lets just alias into a single let binding"
2022-11-15 09:32:19 +0100 <ExistentialDread> dminuoso: Best served with a delicious side of mkTrCon? :D
2022-11-15 09:32:20 +0100 <dminuoso> That is the simplifier will do that.
2022-11-15 09:32:52 +0100 <dminuoso> ExistentialDread: So it will suddenly alias two mutable buffers together. So you will have things pointing into a suddenly shared buffer, the buffer might get double freed, all kinds of crazy fun!
2022-11-15 09:33:20 +0100 <dminuoso> And because mostly this actually tends to not outright crash, you will have severe memory corruption that can have distant effects like either crashing, or just producing strange results.
2022-11-15 09:34:14 +0100 <dminuoso> It is a useful primitive because it allows for very aggressive reordering/sharing, but in the presence of memory allocation/deallocation it can be disastrous
2022-11-15 09:35:53 +0100`2jt(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net)
2022-11-15 09:36:10 +0100cfricke(~cfricke@user/cfricke)
2022-11-15 09:36:22 +0100 <dminuoso> tomsmeding: I mean one big advantage of including a State# RealWorld token, is that it suddenly enables things like IORefs for state keeping or just diagnostics in the parser
2022-11-15 09:36:36 +0100 <dminuoso> both of which are reasons that I wanted this in the first palce.
2022-11-15 09:36:53 +0100 <dminuoso> Being able to just peek and poke buffers during a parser would be superb.
2022-11-15 09:37:26 +0100 <tomsmeding> you can probably mess up the parser completely with IO though, but I guess that's not too easy to do accidentally
2022-11-15 09:37:32 +0100 <dminuoso> How so?
2022-11-15 09:37:47 +0100 <dminuoso> As long as you dont *poke* into the buffer its fine, but honestly you can do that without IO too.
2022-11-15 09:37:48 +0100 <tomsmeding> messing with the buffer you're parsing, for one
2022-11-15 09:37:51 +0100 <tomsmeding> right
2022-11-15 09:38:05 +0100 <Franciman> dminuoso: is ghc inliner nondeterministic?
2022-11-15 09:38:13 +0100 <dminuoso> Franciman: Non-deterministic in what sense?
2022-11-15 09:38:20 +0100 <tomsmeding> your parsing results can be nondeterministic (from the perspective of the parser), which is... questionable, if not directly harmful
2022-11-15 09:38:43 +0100 <Franciman> i mean you are saying, regarding the malloc example above, that sometimes things can be double freed because of the above mentioned issue
2022-11-15 09:39:02 +0100 <dminuoso> Franciman: double free is probably not quite realistic because we mostly use pinned memory for most thing.
2022-11-15 09:39:03 +0100 <Franciman> i was wondering whether you can rely on ghc to not change the status quo in future recompilations
2022-11-15 09:39:08 +0100 <ExistentialDread> dminuoso: Sounds like the RAM variant of a virus I once saw: It worked by slowly corrupting your disk, bit by bit, so by the time you noticed, all your backups where already corrupt too. An advanced version even avoided files/blocks that would crash the system, to not alert the user. Ransomware is nothing against that monster… *shudder*
2022-11-15 09:39:22 +0100 <dminuoso> Franciman: but two allocations being aliased together - that's really the problem in most misuses of accursedUnutterablePerformIO
2022-11-15 09:39:39 +0100 <Franciman> i see
2022-11-15 09:39:49 +0100 <tomsmeding> Franciman: perhaps, but any _code_ changes can influence what the inliner does, even code changes seemingly unrelated to the code in question -- so you should basically assume that the inliner is nondeterministic
2022-11-15 09:39:59 +0100 <Franciman> i see
2022-11-15 09:40:01 +0100 <Franciman> thanks
2022-11-15 09:40:01 +0100 <dminuoso> tomsmeding: I dont think that is what non-deterministic means.
2022-11-15 09:40:08 +0100 <dminuoso> hard-to-predict is something very different
2022-11-15 09:40:20 +0100 <tomsmeding> I know, I mean nondeterministic in the random sense
2022-11-15 09:40:39 +0100 <dminuoso> well, the ghc simplifier does not act randomly
2022-11-15 09:40:43 +0100 <tomsmeding> the inliner probably isn't, but for your own sanity, if you are thinking about using that fact for program correctness, you should assume it is
2022-11-15 09:40:49 +0100 <dminuoso> It will deterministically produce the same results on the same inputs
2022-11-15 09:41:28 +0100 <dminuoso> tomsmeding: Im not sure any useful knowledge can be obtained from that assumption.
2022-11-15 09:41:37 +0100 <dminuoso> Fairly sure that "hard-to-predict" is the better mind model
2022-11-15 09:42:03 +0100 <dminuoso> non-deterministic algorithms have a very specific meaning
2022-11-15 09:42:07 +0100 <dminuoso> And it's not that
2022-11-15 09:42:19 +0100 <tomsmeding> well I could see Franciman wanting to assume in the future that no code changes means no change in simplifier behaviour, but then forgetting that they updated a dependency
2022-11-15 09:42:44 +0100 <tomsmeding> but perhaps you're right
2022-11-15 09:43:32 +0100 <dminuoso> Nevertheless you are right, that code changes can have non-local effects
2022-11-15 09:43:34 +0100 <tomsmeding> perhaps: "it is deterministic, but hard to predict, and furthermore dependent on more inputs than you're thinking of"
2022-11-15 09:43:47 +0100 <dminuoso> And that non-locality is what you seem to be hinting at
2022-11-15 09:43:50 +0100 <tomsmeding> yeah
2022-11-15 09:44:01 +0100 <tomsmeding> perhaps not in the most productive wording
2022-11-15 09:44:17 +0100 <dminuoso> If you want cute puns, perhaps spooky action might be nice?
2022-11-15 09:44:25 +0100 <tomsmeding> oh yeah
2022-11-15 09:44:36 +0100coot(~coot@213.134.171.3)
2022-11-15 09:46:13 +0100 <dminuoso> tomsmeding: Look at this by the way: https://gist.github.com/dminuoso/148ba87e77894d5fcacd6c164976aaee
2022-11-15 09:46:30 +0100 <dminuoso> I think flatparse helped me appreciate the simplicity of pointers
2022-11-15 09:46:46 +0100 <dminuoso> For too long I thought `binary` was a good thing.
2022-11-15 09:47:46 +0100 <dminuoso> It turned out, for my protocol, writing to a buffer from the end towards the start _greatly_ simplifies the encoding style.
2022-11-15 09:48:01 +0100 <dminuoso> And I didnt really like repeatedly running runGet, and then copying buffers over
2022-11-15 09:48:24 +0100 <dminuoso> `Data.ByteString.Builder.Prim` is a wonderful module
2022-11-15 09:48:34 +0100 <dminuoso> My favourite module of the month
2022-11-15 09:48:47 +0100tabaqui(~root@85.106.195.55)
2022-11-15 09:48:49 +0100tabaqui(~root@85.106.195.55) (Client Quit)
2022-11-15 09:48:59 +0100shriekingnoise(~shrieking@186.137.167.202) (Quit: Quit)
2022-11-15 09:49:13 +0100cafkafk(~cafkafk@fsf/member/cafkafk)
2022-11-15 09:49:26 +0100 <tomsmeding> dminuoso: looks like C
2022-11-15 09:49:28 +0100 <tomsmeding> ;)
2022-11-15 09:49:37 +0100tabaqui(~root@85.106.195.55)
2022-11-15 09:49:37 +0100tabaqui(~root@85.106.195.55) (Client Quit)
2022-11-15 09:49:37 +0100 <dminuoso> Yes, nothing wrong with that.
2022-11-15 09:50:02 +0100 <dminuoso> Haskell is a better C.
2022-11-15 09:50:12 +0100 <tomsmeding> functional core, imperative shell, with contained, abstracted imperative modules
2022-11-15 09:50:26 +0100 <tomsmeding> but cool
2022-11-15 09:50:28 +0100tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2022-11-15 09:50:37 +0100 <tomsmeding> I find the untypedness of Ptr a bit queasy
2022-11-15 09:50:43 +0100 <tomsmeding> but it works
2022-11-15 09:50:44 +0100 <dminuoso> How is it untyped?
2022-11-15 09:50:46 +0100 <dminuoso> Its very typed.
2022-11-15 09:50:53 +0100 <dminuoso> data Ptr a
2022-11-15 09:50:56 +0100 <tomsmeding> :t plusPtr
2022-11-15 09:50:58 +0100 <lambdabot> error: Variable not in scope: plusPtr
2022-11-15 09:51:02 +0100 <tomsmeding> :t Foreign.Ptr.plusPtr
2022-11-15 09:51:03 +0100 <lambdabot> GHC.Ptr.Ptr a -> Int -> GHC.Ptr.Ptr b
2022-11-15 09:51:07 +0100 <dminuoso> Oh, that's strange
2022-11-15 09:51:08 +0100 <tomsmeding> how is this typed
2022-11-15 09:51:19 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-15 09:51:21 +0100 <tomsmeding> also minusPtr, but plusPtr is the worst one
2022-11-15 09:51:26 +0100 <dminuoso> But for what its worth, you can very trivially make a type safe copy of this
2022-11-15 09:51:31 +0100 <tomsmeding> yeah
2022-11-15 09:51:32 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1)
2022-11-15 09:51:35 +0100 <dminuoso> minusPtr is horribly misnamed.
2022-11-15 09:51:54 +0100 <dminuoso> A few days ago I kept not understanding some type errors since I expected `minusPtr :: Ptr a -> Int -> Ptr b`
2022-11-15 09:52:01 +0100 <tomsmeding> heh
2022-11-15 09:52:35 +0100 <tomsmeding> well in C you have both, ptr-int=ptr and ptr-ptr=int
2022-11-15 09:52:49 +0100acidjnk(~acidjnk@p200300d6e7137a17b1807064f1abc0ef.dip0.t-ipconnect.de)
2022-11-15 09:52:57 +0100 <pavonia> :t Foreign.Ptr.minusPtr
2022-11-15 09:52:58 +0100 <lambdabot> GHC.Ptr.Ptr a -> GHC.Ptr.Ptr b -> Int
2022-11-15 09:53:29 +0100econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2022-11-15 09:53:31 +0100tabaqui(~root@85.106.195.55)
2022-11-15 09:53:33 +0100tabaqui(~root@85.106.195.55) (Client Quit)
2022-11-15 09:53:33 +0100 <dminuoso> tomsmeding: sure, but then we should have `reallyUnsafePlusPtr :: Ptr a -> Ptr b -> Int`
2022-11-15 09:53:44 +0100 <tomsmeding> lol
2022-11-15 09:53:46 +0100ExistentialDread(~TheCreato@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de) (Quit: Client closed)
2022-11-15 09:53:47 +0100 <tomsmeding> please no
2022-11-15 09:53:51 +0100 <tomsmeding> that operation makes no semantic sense
2022-11-15 09:53:55 +0100 <dminuoso> Why not?
2022-11-15 09:53:58 +0100 <dminuoso> C has it too!
2022-11-15 09:54:11 +0100 <dminuoso> (Yes yes, you cant have `int` there but ptr_size_t_something_something
2022-11-15 09:54:22 +0100tabaqui(~root@85.106.195.55)
2022-11-15 09:54:23 +0100 <dminuoso> One of those awefully named types.
2022-11-15 09:54:36 +0100 <tomsmeding> wasn't it monochrom that shared this math concept page where you have a difference between points and vectors between them
2022-11-15 09:54:38 +0100 <tomsmeding> ptrdiff_t
2022-11-15 09:54:43 +0100tabaqui(~root@85.106.195.55) (Client Quit)
2022-11-15 09:54:50 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de)
2022-11-15 09:55:18 +0100kuribas(~user@ptr-17d51epp9boz5wcvhgl.18120a2.ip6.access.telenet.be)
2022-11-15 09:55:49 +0100 <dminuoso> Speaking of reallyUnsafe, I love the name of this thing:
2022-11-15 09:55:51 +0100 <dminuoso> reallyUnsafePtrEquality :: a -> a -> Int#
2022-11-15 09:55:56 +0100 <tomsmeding> oh no it was ski https://math.ucr.edu/home/baez/torsors.html
2022-11-15 09:56:24 +0100 <dminuoso> tomsmeding: Will you be attending NL FP day?
2022-11-15 09:56:26 +0100 <dminuoso> You should come
2022-11-15 09:56:30 +0100 <tomsmeding> will you?
2022-11-15 09:56:34 +0100 <tomsmeding> I think so
2022-11-15 09:56:37 +0100 <dminuoso> Yes, I shall
2022-11-15 09:56:38 +0100zeenk(~zeenk@2a02:2f04:a208:3600::7fe)
2022-11-15 09:56:49 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-15 09:56:58 +0100tabaqui(~root@85.106.195.55)
2022-11-15 09:56:59 +0100 <dminuoso> Will probably make turn it into a combined FP day + followed by family vacation in Amsterdam
2022-11-15 09:57:17 +0100nschoe(~q@2a01:e0a:8e:a190:932f:d0ab:eeaa:3346)
2022-11-15 09:58:28 +0100tabaqui(~root@85.106.195.55) (Client Quit)
2022-11-15 09:58:41 +0100rembo10(~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in)
2022-11-15 09:59:01 +0100 <dminuoso> merijn: By the way, in case you didnt catch that in #ghc, it turns out that ForeignPtr are kept alive through well the finalizer _field_, but not via an actual finalizer
2022-11-15 09:59:13 +0100 <dminuoso> That finally helped me understand a lot about ForeignPtr
2022-11-15 09:59:33 +0100 <tomsmeding> dminuoso: registered
2022-11-15 09:59:39 +0100 <dminuoso> data ForeignPtrContents = PlainForeignPtr !(IORef Finalizers) | FinalPtr | MallocPtr (MutableByteArray# RealWorld) !(IORef Finalizers) | PlainPtr (MutableByteArray# RealWorld)
2022-11-15 10:00:00 +0100 <dminuoso> So its those MutableByteArray# that keep them alive (obviously only if they are created with MallocPtr or PlainPtr
2022-11-15 10:00:14 +0100 <dminuoso> But thats fine, since in case of PlainForeignPtr, FinalPtr it is not the GCs job to clean them up
2022-11-15 10:00:30 +0100 <dminuoso> tomsmeding: nice, see you there then
2022-11-15 10:00:37 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2022-11-15 10:00:52 +0100rembo10(~rembo10@main.remulis.com)
2022-11-15 10:00:58 +0100tabaqui(~root@85.106.195.55)
2022-11-15 10:01:13 +0100ExistentialDread(~Existenti@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de)
2022-11-15 10:01:18 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 268 seconds)
2022-11-15 10:02:20 +0100 <ExistentialDread> > let { (¤) :: (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; example a b c = a * b * c } in example ¤ 3+3 ¤ 2+2 ¤ 1+1
2022-11-15 10:02:21 +0100 <lambdabot> 48
2022-11-15 10:02:47 +0100ExistentialDreadponders if this already exists…
2022-11-15 10:03:31 +0100 <dminuoso> :i ($)
2022-11-15 10:03:33 +0100 <dminuoso> % :i ($)
2022-11-15 10:03:33 +0100 <yahb2> ($) :: (a -> b) -> a -> b -- Defined in ‘GHC.Base’ ; infixr 0 $
2022-11-15 10:03:36 +0100 <dminuoso> This you mean?
2022-11-15 10:03:58 +0100 <dminuoso> ExistentialDread: Noet that ($) has some additional tricks to it that GHC hides from you (notably it will work with runST)
2022-11-15 10:04:12 +0100 <dminuoso> Because in reality: ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b infixr 0
2022-11-15 10:04:29 +0100 <ExistentialDread> dminuoso: not its distinct difference from ($), in that example $ 3+3 $ 2+2 $ 1+1 does not work
2022-11-15 10:04:47 +0100 <dminuoso> What do you mean?
2022-11-15 10:05:17 +0100 <ExistentialDread> > let { example a b c = a * b * c } in example $ 3+3 $ 2+2 $ 1+1
2022-11-15 10:05:19 +0100 <lambdabot> <Integer -> Integer -> Integer>
2022-11-15 10:05:21 +0100 <dminuoso> Oh
2022-11-15 10:06:05 +0100 <dminuoso> ExistentialDread: Yes, its been long known that ($) has the wrong fixity.
2022-11-15 10:06:23 +0100 <dminuoso> But thats a hole we will not climb out ever again.
2022-11-15 10:07:06 +0100 <ExistentialDread> dminuoso: Wait, it doesn’t have infixr 0?
2022-11-15 10:07:28 +0100 <dminuoso> ExistentialDread: The only difference between ($) and (¤) is that your has infixl and ($) has infixr
2022-11-15 10:07:40 +0100 <dminuoso> (well and that ($) is levity polymorphic, but you can easily fix that for your version)
2022-11-15 10:07:40 +0100 <ExistentialDread> dminuoso: Custom Preludes might beg do differ? :D
2022-11-15 10:07:47 +0100 <dminuoso> ExistentialDread: what do you mean?
2022-11-15 10:08:16 +0100 <dminuoso> Well yes, you can provide an alternate Prelude with your own ($)
2022-11-15 10:08:20 +0100 <ExistentialDread> dminuoso: Well I can make my own Prelude, with ($) defined like (¤), and blackjack! :D
2022-11-15 10:08:43 +0100 <dminuoso> It just creates extra friction for outside users/contributors though
2022-11-15 10:08:50 +0100 <dminuoso> (which is a general problem with custom preludes)
2022-11-15 10:08:55 +0100 <dminuoso> But yes, you can do that.
2022-11-15 10:09:02 +0100 <ExistentialDread> dminuoso: What outside users/contributors? XD
2022-11-15 10:09:16 +0100 <dminuoso> ExistentialDread: However, ($) has that levity trick up its sleeve that you cannot easily address.
2022-11-15 10:09:27 +0100 <dminuoso> especially since ($) disappears in GHC
2022-11-15 10:09:32 +0100 <ExistentialDread> dminuoso: Levity?
2022-11-15 10:09:49 +0100 <dminuoso> ExistentialDread: Try yusing (¤) with runST
2022-11-15 10:10:06 +0100 <dminuoso> % import Control.Monad.ST
2022-11-15 10:10:06 +0100 <yahb2> <no output>
2022-11-15 10:10:11 +0100 <dminuoso> % runST ¤ pure 1
2022-11-15 10:10:11 +0100 <yahb2> <interactive>:28:7: error: ; Variable not in scope: (¤) :: t0 -> f0 a1 -> t
2022-11-15 10:10:22 +0100 <dminuoso> % > let { (¤) :: (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1
2022-11-15 10:10:22 +0100 <yahb2> <interactive>:30:1: error: parse error on input ‘>’
2022-11-15 10:10:24 +0100 <ExistentialDread> dminuoso: I could define it like ($) too, and use {-# INLINE (¤) #-} too, no?
2022-11-15 10:10:55 +0100 <ExistentialDread> > let { (¤) :: (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1
2022-11-15 10:10:57 +0100 <lambdabot> error:
2022-11-15 10:10:57 +0100 <lambdabot> • Couldn't match type ‘f0 a0’ with ‘forall s. ST s y’
2022-11-15 10:10:57 +0100 <lambdabot> Expected type: f0 a0 -> y
2022-11-15 10:11:53 +0100 <dminuoso> > let { (¤) :: forall r x (y :: TYPE r). (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1
2022-11-15 10:11:55 +0100 <lambdabot> error:
2022-11-15 10:11:55 +0100 <lambdabot> Not in scope: type constructor or class ‘TYPE’
2022-11-15 10:11:58 +0100 <dminuoso> Mmm
2022-11-15 10:12:03 +0100 <dminuoso> Why doesnt GHCi parse this?
2022-11-15 10:12:07 +0100 <dminuoso> % let { (¤) :: forall r x (y :: TYPE r). (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1
2022-11-15 10:12:07 +0100 <yahb2> <interactive>:32:31: error: ; Not in scope: type constructor or class ‘TYPE’
2022-11-15 10:12:12 +0100 <dminuoso> Ah
2022-11-15 10:12:22 +0100 <dminuoso> % import GHC.Exts (TYPE)
2022-11-15 10:12:22 +0100 <yahb2> <no output>
2022-11-15 10:12:24 +0100 <dminuoso> % let { (¤) :: forall r x (y :: TYPE r). (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1
2022-11-15 10:12:24 +0100 <yahb2> <interactive>:36:90: error: ; • Couldn't match type: forall s. ST s y ; with: f0 a0 ; Expected: f0 a0 -> y ; Actual: (forall s. ST s y) -> y ; • In the fi...
2022-11-15 10:12:37 +0100 <dminuoso> Note however:
2022-11-15 10:12:40 +0100 <dminuoso> $ runST $ pure 1
2022-11-15 10:12:42 +0100 <dminuoso> % runST $ pure 1
2022-11-15 10:12:42 +0100 <yahb2> 1
2022-11-15 10:13:37 +0100 <dminuoso> ExistentialDread: If memory serves right, there exists a special hack in GHC to erase ($) completely.
2022-11-15 10:13:43 +0100 <dminuoso> Avoiding this problem
2022-11-15 10:13:56 +0100 <ExistentialDread> (y :: TYPE r) looks *so* evil. I mean I’m already for doing away with having a separate language for types and another half one for kinds and whatnot, in favor of just using normal Haskell code syntax for ALL the things. :)
2022-11-15 10:13:58 +0100 <dminuoso> And sorry, its not about levity - that was a misphrasing.
2022-11-15 10:14:03 +0100 <dminuoso> ExistentialDread: And no, you will want that too.
2022-11-15 10:14:08 +0100 <dminuoso> ExistentialDread: Thats just levity polymorphism
2022-11-15 10:14:16 +0100 <dminuoso> Such that it will work with things like unboxed prims
2022-11-15 10:14:53 +0100 <dminuoso> % import GHC.Prim
2022-11-15 10:14:53 +0100 <yahb2> <no output>
2022-11-15 10:15:07 +0100 <dminuoso> % import GHC.Word (Word(..))
2022-11-15 10:15:07 +0100 <yahb2> <no output>
2022-11-15 10:15:18 +0100 <dminuoso> % :set -XMagicHash
2022-11-15 10:15:18 +0100 <yahb2> <no output>
2022-11-15 10:15:51 +0100 <dminuoso> % W# $ int2Word# $ 10#
2022-11-15 10:15:51 +0100 <yahb2> <interactive>:46:1: error: ; • Expecting a lifted type, but ‘Word#’ is unlifted ; • In the first argument of ‘($)’, namely ‘W#’ ; In the expression: W# $ int2Word# $ 10# ; In an...
2022-11-15 10:16:16 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.)
2022-11-15 10:16:20 +0100cafkafk(~cafkafk@fsf/member/cafkafk) (Quit: WeeChat 3.3)
2022-11-15 10:16:24 +0100 <dminuoso> Ah
2022-11-15 10:16:41 +0100 <dminuoso> That is strange huh.
2022-11-15 10:17:06 +0100 <dminuoso> ExistentialDread: Anyway, the forall quantification thing is a different problem and that is unaddressable without a hack like GHC has.
2022-11-15 10:17:13 +0100 <dminuoso> But its only a mild problem
2022-11-15 10:17:17 +0100cafkafk(~cafkafk@fsf/member/cafkafk)
2022-11-15 10:17:41 +0100 <dminuoso> Especially since BlockArguments largely voids the need for it
2022-11-15 10:18:31 +0100 <dminuoso> So you can mostly just gloss over it.
2022-11-15 10:20:09 +0100 <ExistentialDread> I think I’m too tired. ^^ I worked right through the night. (It’s 10:20 AM here now) So I’ll wish everyone a good … day. /bye
2022-11-15 10:20:18 +0100ExistentialDread(~Existenti@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de) (Quit: ExistentialDread)
2022-11-15 10:20:44 +0100 <dminuoso> Oh hah, no actually the trick for ($) is different!
2022-11-15 10:20:45 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-15 10:20:55 +0100 <dminuoso> GHC enables QuickLook for ($)
2022-11-15 10:20:59 +0100 <dminuoso> Okay now that is cute.
2022-11-15 10:21:16 +0100 <dminuoso> And it suggests you could just enable ImpredicativeTypes on the definition site for ¤
2022-11-15 10:21:24 +0100 <dminuoso> (Or do you need it in call-sites?)
2022-11-15 10:22:21 +0100 <dminuoso> But it seems there a special typing rule for it, Ugh.
2022-11-15 10:22:25 +0100 <dminuoso> Before quick look
2022-11-15 10:25:19 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection)
2022-11-15 10:25:26 +0100chromoblob(~user@37.113.164.122)
2022-11-15 10:25:54 +0100ubert1(~Thunderbi@178.165.184.78.wireless.dyn.drei.com)
2022-11-15 10:27:44 +0100ubert(~Thunderbi@77.119.222.7.wireless.dyn.drei.com) (Ping timeout: 260 seconds)
2022-11-15 10:27:44 +0100ubert1ubert
2022-11-15 10:28:29 +0100califax(~califax@user/califx) (Remote host closed the connection)
2022-11-15 10:29:27 +0100 <tomsmeding> call-sites I thnk
2022-11-15 10:29:56 +0100califax(~califax@user/califx)
2022-11-15 10:30:03 +0100 <tomsmeding> the quick look idea is to be cleverer in inferring the instantiation of function argument types
2022-11-15 10:30:26 +0100MajorBiscuit(~MajorBisc@145.94.173.65)
2022-11-15 10:30:42 +0100titibandit(~titibandi@xdsl-78-35-167-196.nc.de) (Remote host closed the connection)
2022-11-15 10:31:14 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-15 10:47:39 +0100Guest75(~Guest75@178.141.177.81)
2022-11-15 10:49:19 +0100Feuermagier(~Feuermagi@user/feuermagier) (Read error: Connection reset by peer)
2022-11-15 10:49:32 +0100Feuermagier(~Feuermagi@user/feuermagier)
2022-11-15 11:02:25 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 11:04:00 +0100 <dminuoso> Ah yes that makes sense
2022-11-15 11:04:08 +0100Guest75(~Guest75@178.141.177.81) (Ping timeout: 260 seconds)
2022-11-15 11:07:59 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-15 11:08:00 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2022-11-15 11:09:09 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-15 11:10:30 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds)
2022-11-15 11:16:53 +0100poscat(~poscat@114.245.106.84) (Quit: Bye)
2022-11-15 11:17:08 +0100poscat(~poscat@2408:8206:4823:fd6f:98ab:5c38:136c:5932)
2022-11-15 11:17:57 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds)
2022-11-15 11:18:00 +0100Genius123(~Genius123@71.169.167.129) (Quit: Client closed)
2022-11-15 11:20:36 +0100Guest75(~Guest75@178.141.177.81)
2022-11-15 11:24:52 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving)
2022-11-15 11:25:49 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 11:26:38 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 11:30:02 +0100zarel[m](~zarelitma@2001:470:69fc:105::1:fcfb)
2022-11-15 11:30:25 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 256 seconds)
2022-11-15 11:31:43 +0100`2jt(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 252 seconds)
2022-11-15 11:32:15 +0100mei(~mei@user/mei)
2022-11-15 11:33:43 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 11:38:11 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-15 11:39:21 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds)
2022-11-15 11:44:55 +0100potash(~foghorn@user/foghorn) (Remote host closed the connection)
2022-11-15 11:46:06 +0100Lycurgus(~juan@user/Lycurgus)
2022-11-15 11:46:25 +0100potash(~foghorn@user/foghorn)
2022-11-15 11:46:49 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 11:57:26 +0100 <kuribas> finally, a haskell meeting close to me :) https://www.reddit.com/r/haskell/comments/yt5xoc/cfp_fosdem_haskell_devroom_sun_20230205_brussels/
2022-11-15 11:57:33 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 11:57:37 +0100 <kuribas> would they accept talks about idris?
2022-11-15 11:57:48 +0100 <kuribas> 30 minutes seems very short though...
2022-11-15 11:58:10 +0100 <dminuoso> kuribas: Ask Athas?
2022-11-15 11:58:18 +0100 <dminuoso> He seems to be one of the organizers
2022-11-15 11:59:30 +0100 <kuribas> dminuoso: right, thanks!
2022-11-15 11:59:49 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 12:02:42 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2022-11-15 12:03:35 +0100Batzy(~quassel@user/batzy) (Quit: No Ping reply in 180 seconds.)
2022-11-15 12:03:59 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-15 12:05:02 +0100Batzy(~quassel@user/batzy)
2022-11-15 12:05:51 +0100vglfr(~vglfr@145.224.100.100) (Read error: Connection reset by peer)
2022-11-15 12:06:01 +0100Inst(~Inst@2601:6c4:4081:54f0:155b:1b8c:fa18:504e)
2022-11-15 12:06:05 +0100 <Inst> how much would it cost
2022-11-15 12:06:15 +0100 <Inst> to get tvx (iirc) updated to support windows?
2022-11-15 12:06:34 +0100 <Inst> oh, it's vty
2022-11-15 12:08:12 +0100 <tomsmeding> kuribas: https://set.win.tue.nl/nl-fp-day-2023/
2022-11-15 12:08:27 +0100 <dminuoso> Inst: Contact Galois Inc and find out.
2022-11-15 12:08:43 +0100 <Inst> Galois tbh should do it for free
2022-11-15 12:08:57 +0100 <dminuoso> Oh really.
2022-11-15 12:08:59 +0100 <Inst> the story I recall is that the Brick maintainer tried to get vty updated for Windows support
2022-11-15 12:09:06 +0100 <Inst> no one wanted to do it
2022-11-15 12:09:12 +0100 <dminuoso> The kind of expectancoes of software users is crazy.
2022-11-15 12:09:14 +0100 <Inst> well, I mean, I guess Galois isn't Tweag?
2022-11-15 12:09:21 +0100 <dminuoso> You are not entitled to free software, sorry.
2022-11-15 12:09:36 +0100 <Inst> so we should pay for GHCJS?
2022-11-15 12:09:49 +0100 <dminuoso> No Im saying, if someone does provide a product for free, great, say thank you.
2022-11-15 12:09:57 +0100 <tomsmeding> developer A releasing software for free does not beget you right to free software from developer B
2022-11-15 12:09:59 +0100 <dminuoso> But if you demand or expect something, then pay for it?
2022-11-15 12:10:18 +0100 <tomsmeding> you can still ask them, though :p
2022-11-15 12:10:29 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 12:10:53 +0100 <dminuoso> Even bug fixing is just a free gift. If I have a GHC issue that nobody wants to fix, well if I want it fixed, I either pay well typed (or someone else), or do it myself.
2022-11-15 12:11:22 +0100 <dminuoso> Or, and this happens somewhat frequently, if I need a prompt fix.
2022-11-15 12:11:34 +0100potash(~foghorn@user/foghorn) (Ping timeout: 260 seconds)
2022-11-15 12:12:11 +0100potash(~foghorn@user/foghorn)
2022-11-15 12:13:12 +0100euandreh(~Thunderbi@179.214.113.107) (Remote host closed the connection)
2022-11-15 12:13:30 +0100 <dminuoso> I recently learned Obj-C because for our business we needed a quick fix to the SOGo groupware. It seemed just rude to open up an issue that goes along the lines of "This product, which generates revenue, crucially needs a fix, best by tomorrow."
2022-11-15 12:13:37 +0100 <dminuoso> Was a fun afternoon :>
2022-11-15 12:13:37 +0100euandreh(~Thunderbi@179.214.113.107)
2022-11-15 12:20:10 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 240 seconds)
2022-11-15 12:20:18 +0100Lycurgus(~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5)
2022-11-15 12:21:59 +0100youziqi(~youziqi@103.37.140.125) (Ping timeout: 256 seconds)
2022-11-15 12:22:22 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-15 12:22:28 +0100 <merijn> kuribas: NL-FP is happening back at it's usual time in January next year
2022-11-15 12:22:49 +0100 <merijn> oh, tomsmeding already linked it :)
2022-11-15 12:24:16 +0100youziqi(~youziqi@103.37.140.125)
2022-11-15 12:24:27 +0100 <merijn> kuribas: Idris would 100% be on topic for NL-FP, since it's not specifically a haskell...conference? meetup? I dunno, both descriptions seem off :p
2022-11-15 12:24:51 +0100 <merijn> There's also the Clean addicts showing up every year :p
2022-11-15 12:28:05 +0100ygsjg(~quassel@189.124.224.160) (Remote host closed the connection)
2022-11-15 12:30:45 +0100xff0x(~xff0x@2405:6580:b080:900:3e39:3b08:3cd:f770)
2022-11-15 12:31:43 +0100 <dminuoso> NL-FP has only clean addicts.
2022-11-15 12:31:57 +0100 <dminuoso> The haskellers are just outsiders that are.. tolerated.
2022-11-15 12:32:00 +0100 <dminuoso> :p
2022-11-15 12:32:52 +0100 <dminuoso> Seriously, last time I was there, every second talk was about mTask
2022-11-15 12:32:59 +0100 <dminuoso> Was a bit silly :D
2022-11-15 12:34:45 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius) (Quit: free())
2022-11-15 12:35:29 +0100potash(~foghorn@user/foghorn) (Read error: Connection reset by peer)
2022-11-15 12:36:07 +0100potash(~foghorn@user/foghorn)
2022-11-15 12:38:26 +0100califax(~califax@user/califx) (Ping timeout: 255 seconds)
2022-11-15 12:40:24 +0100razetime(~quassel@117.193.3.56) (Ping timeout: 268 seconds)
2022-11-15 12:42:17 +0100califax(~califax@user/califx)
2022-11-15 12:50:04 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2022-11-15 12:55:34 +0100 <Inst> by the way, does this count as a bug?
2022-11-15 12:55:49 +0100 <Inst> I'm doing an accum parameter sum on a list of size 100,000,000
2022-11-15 12:56:10 +0100 <Inst> a direct call on the prelude sum is about 90% slower than the accum parameter sum
2022-11-15 12:56:32 +0100 <dminuoso> Can you share the respective code snippets?
2022-11-15 12:58:49 +0100youziqi(~youziqi@103.37.140.125) (Ping timeout: 256 seconds)
2022-11-15 13:00:25 +0100 <Inst> https://paste.tomsmeding.com/yDDLPuhC
2022-11-15 13:00:50 +0100 <Inst> https://paste.tomsmeding.com/JkvKMc30
2022-11-15 13:00:54 +0100 <[Leary]> Your `base` is probably old. iirc sum/product only switched to strict folds somewhat recently.
2022-11-15 13:01:01 +0100 <Inst> on 9.2.4
2022-11-15 13:01:15 +0100chele(~chele@user/chele)
2022-11-15 13:01:17 +0100 <dminuoso> Inst: How did you run the code?
2022-11-15 13:01:33 +0100 <Franciman> Inst: version 4.17.0 of base?
2022-11-15 13:01:35 +0100 <Inst> cabal file build
2022-11-15 13:01:41 +0100 <Franciman> 4.17.0.0
2022-11-15 13:01:41 +0100 <Inst> should be 4.17.0 of base, let me retry and force that
2022-11-15 13:01:55 +0100youziqi(~youziqi@103.37.140.93)
2022-11-15 13:02:20 +0100 <dminuoso> Also, please share the full code
2022-11-15 13:02:30 +0100 <dminuoso> I dont see the imports, so I dont know whether you use Data.Foldable or Data.List
2022-11-15 13:02:50 +0100 <dminuoso> (They export different `sum` implementations)
2022-11-15 13:03:13 +0100 <Franciman> i think they use prelude ?!
2022-11-15 13:03:41 +0100 <dminuoso> Maybe, but the code is too sketchy - I dont want to assume here.
2022-11-15 13:03:45 +0100 <Inst> my sytem i think is broken
2022-11-15 13:04:02 +0100 <dminuoso> I think this is already in "make a reproducer repo" territory
2022-11-15 13:04:03 +0100 <Franciman> dminuoso: wait, from here: https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-List.html i see that sum is the same as the one exported from Foldable
2022-11-15 13:04:36 +0100 <Inst> it's stuck on 4.16.3.0
2022-11-15 13:04:43 +0100 <dminuoso> Franciman: Ohh I was thinking of GHC.List.
2022-11-15 13:04:46 +0100 <dminuoso> Thanks good catch
2022-11-15 13:06:12 +0100ridcully(~ridcully@pd951fa32.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2022-11-15 13:06:28 +0100Techcable(~Techcable@user/Techcable) (Read error: Connection reset by peer)
2022-11-15 13:06:47 +0100infinity0(~infinity0@pwned.gg)
2022-11-15 13:07:51 +0100 <Inst> i can't seem to get my cabal to support 4.17.0.0
2022-11-15 13:07:51 +0100Achylles(~Achylles_@2804:431:d724:7309:7501:feac:f03e:5f7f)
2022-11-15 13:07:55 +0100 <Inst> that requires 9.4, doesn't it?
2022-11-15 13:08:35 +0100 <[Leary]> 4.16.3 should be new enough
2022-11-15 13:09:31 +0100 <Inst> i can try to put it to
2022-11-15 13:09:33 +0100 <Inst> main :: IO ()
2022-11-15 13:09:33 +0100 <Inst> main = defaultMain [bgroup "MySum" [ bench "[1..100_000_000]" $ nf accumSum ([1..100000000] :: [Int])]
2022-11-15 13:09:34 +0100 <Inst> ,bgroup "PrSum" [ bench "[1..100_000_000]" $ nf (foldl' (+) 0) ([1..100000000] :: [Int])]]
2022-11-15 13:10:28 +0100ridcully(~ridcully@p57b52925.dip0.t-ipconnect.de)
2022-11-15 13:10:50 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-15 13:11:13 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-15 13:11:56 +0100 <Inst> still getting the same result
2022-11-15 13:11:59 +0100 <Inst> is something wrong with GHC?
2022-11-15 13:12:12 +0100 <Inst> like, foldl' / foldr etc are idiomatic, accum parameter is a pseudo-imperative performance hack
2022-11-15 13:15:30 +0100nschoe(~q@2a01:e0a:8e:a190:932f:d0ab:eeaa:3346) (Ping timeout: 260 seconds)
2022-11-15 13:16:56 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-15 13:17:09 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-15 13:18:05 +0100Techcable(~Techcable@user/Techcable)
2022-11-15 13:18:11 +0100Techcable(~Techcable@user/Techcable) (Remote host closed the connection)
2022-11-15 13:19:19 +0100 <Inst> via fp discord, we got the same benchmarks via eta expansion
2022-11-15 13:20:25 +0100Techcable(~Techcable@user/Techcable)
2022-11-15 13:21:10 +0100 <Inst> so foldl' isn't that badly off
2022-11-15 13:21:24 +0100 <Inst> whew, i was annoyed that i'd be stuck coding pseudo-imperative accum params forever
2022-11-15 13:25:01 +0100razetime(~quassel@117.254.34.170)
2022-11-15 13:25:16 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1)
2022-11-15 13:26:03 +0100CiaoSen(~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-11-15 13:27:05 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de)
2022-11-15 13:27:37 +0100Techcable(~Techcable@user/Techcable) (Read error: Connection reset by peer)
2022-11-15 13:30:41 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net)
2022-11-15 13:31:30 +0100phma(~phma@host-67-44-208-73.hnremote.net) (Read error: Connection reset by peer)
2022-11-15 13:32:18 +0100phma(~phma@2001:5b0:215d:9748:5bc9:473d:a4cc:a159)
2022-11-15 13:33:59 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1)
2022-11-15 13:35:26 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de)
2022-11-15 13:35:54 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 268 seconds)
2022-11-15 13:38:50 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 240 seconds)
2022-11-15 13:40:13 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 13:40:46 +0100 <dminuoso> Inst: Cannot reproduce. https://paste.tomsmeding.com/0o2RP5qm
2022-11-15 13:42:55 +0100 <dminuoso> And in fact, the generated core output looks optimal for prelude `sum`, it compiles directly into the tightest loop possible with an bunboxed Int# counter
2022-11-15 13:43:21 +0100chromoblob(~user@37.113.164.122)
2022-11-15 13:43:50 +0100 <dminuoso> The accumSum code appears to compile into the same code, Im not quite sure why we have ~20% difference between them
2022-11-15 13:45:49 +0100euandreh(~Thunderbi@179.214.113.107) (Quit: euandreh)
2022-11-15 13:46:10 +0100euandreh2(~Thunderbi@179.214.113.107)
2022-11-15 13:47:06 +0100 <dminuoso> https://paste.tomsmeding.com/pWiiAgHs
2022-11-15 13:48:10 +0100 <dminuoso> accumSum = \ (ls_a1uG :: [Int]) -> case $wgo 0# ls_a1uG of ww_s4lx { __DEFAULT -> I# ww_s4lx }
2022-11-15 13:48:12 +0100euandreh2euandreh
2022-11-15 13:48:18 +0100 <dminuoso> Mmm, whats the meaning of this `{ __DEFAULT -> I# ww_s4lx }` here?
2022-11-15 13:48:53 +0100 <dminuoso> Or the entire element `ww_s4lx { __DEFAULT -> I# ww_s4lx }` even
2022-11-15 13:49:51 +0100marc__(~marc@5.83.191.99)
2022-11-15 13:50:19 +0100 <marc__> Does anybody know a flutter like implementation in a functional language like Haskell offering direct hardware rendering and web support ?
2022-11-15 13:52:54 +0100ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2022-11-15 13:53:33 +0100ec(~ec@gateway/tor-sasl/ec)
2022-11-15 13:54:22 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 13:55:41 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius)
2022-11-15 13:58:25 +0100fockerize(~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr)
2022-11-15 13:59:11 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-11-15 13:59:11 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius) (Max SendQ exceeded)
2022-11-15 13:59:32 +0100 <zzz> The package location glob './vendor/*/*.cabal' does not match any files or directories. <- what does this mean?
2022-11-15 14:00:04 +0100marc__(~marc@5.83.191.99) (Ping timeout: 260 seconds)
2022-11-15 14:01:52 +0100 <zzz> oh nvm
2022-11-15 14:01:56 +0100 <zzz> my mistake
2022-11-15 14:01:59 +0100marc__(~marc@5.83.191.99)
2022-11-15 14:03:25 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 256 seconds)
2022-11-15 14:04:44 +0100cfricke(~cfricke@user/cfricke) (Ping timeout: 260 seconds)
2022-11-15 14:08:45 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 14:08:50 +0100nschoe(~q@2a01:e0a:8e:a190:a039:6fb1:ed57:342c)
2022-11-15 14:09:15 +0100chromoblob(~user@37.113.164.122) (Read error: Connection reset by peer)
2022-11-15 14:11:13 +0100mikoto-chan(~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi)
2022-11-15 14:12:25 +0100lyle(~lyle@104.246.145.85)
2022-11-15 14:12:33 +0100Techcable(~Techcable@user/Techcable)
2022-11-15 14:13:31 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 14:14:29 +0100chromoblob(~user@37.113.164.122)
2022-11-15 14:15:26 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.)
2022-11-15 14:16:35 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius)
2022-11-15 14:16:55 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-15 14:17:32 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2022-11-15 14:17:45 +0100mikoto-chan(~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Quit: WeeChat 3.6)
2022-11-15 14:17:53 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2022-11-15 14:18:38 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-15 14:18:39 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 14:21:17 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius) (Max SendQ exceeded)
2022-11-15 14:21:30 +0100sh1n(~sh1n@186.152.126.112)
2022-11-15 14:21:32 +0100marc__(~marc@5.83.191.99) (Ping timeout: 268 seconds)
2022-11-15 14:23:12 +0100marc__(~marc@5.83.191.99)
2022-11-15 14:24:38 +0100ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds)
2022-11-15 14:24:39 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 14:26:42 +0100ec(~ec@gateway/tor-sasl/ec)
2022-11-15 14:28:17 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2022-11-15 14:28:23 +0100Raito_Bezarius(~Raito@wireguard/tunneler/raito-bezarius)
2022-11-15 14:28:50 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 240 seconds)
2022-11-15 14:29:27 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 260 seconds)
2022-11-15 14:30:55 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-11-15 14:31:56 +0100noctuks(v2dJtUbze5@user/noctux)
2022-11-15 14:32:18 +0100chromoblob(~user@37.113.164.122)
2022-11-15 14:33:16 +0100CiaoSen(~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Quit: CiaoSen)
2022-11-15 14:36:20 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2022-11-15 14:36:59 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 14:37:51 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-15 14:49:39 +0100fockerize(~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 260 seconds)
2022-11-15 14:51:36 +0100califax(~califax@user/califx) (Remote host closed the connection)
2022-11-15 14:52:35 +0100califax(~califax@user/califx)
2022-11-15 14:54:08 +0100mikoto-chan(~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi)
2022-11-15 14:55:25 +0100`2jt(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net)
2022-11-15 14:55:30 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2022-11-15 14:57:54 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 14:59:04 +0100slack1256(~slack1256@191.125.99.216)
2022-11-15 15:02:51 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 15:03:35 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 15:04:21 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 15:05:35 +0100jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff)
2022-11-15 15:10:03 +0100fockerize(~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr)
2022-11-15 15:10:05 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2022-11-15 15:11:30 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 15:13:38 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 15:15:46 +0100nschoe(~q@2a01:e0a:8e:a190:a039:6fb1:ed57:342c) (Remote host closed the connection)
2022-11-15 15:15:59 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2022-11-15 15:16:59 +0100nschoe(~q@2a01:e0a:8e:a190:e046:20e5:49d3:6cb9)
2022-11-15 15:17:35 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 15:28:05 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2022-11-15 15:29:13 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 15:30:30 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 15:31:23 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net)
2022-11-15 15:33:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds)
2022-11-15 15:33:32 +0100ystael(~ystael@user/ystael)
2022-11-15 15:35:47 +0100InstX1(~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds)
2022-11-15 15:36:19 +0100fockerize(~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 260 seconds)
2022-11-15 15:38:12 +0100shriekingnoise(~shrieking@186.137.167.202)
2022-11-15 15:42:02 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2022-11-15 15:42:02 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds)
2022-11-15 15:42:59 +0100doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com)
2022-11-15 15:45:13 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2022-11-15 15:45:27 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b)))
2022-11-15 15:45:27 +0100allbery_b(~geekosaur@xmonad/geekosaur)
2022-11-15 15:45:30 +0100allbery_bgeekosaur
2022-11-15 15:54:25 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 15:55:05 +0100auri(~auri@fsf/member/auri) (Ping timeout: 246 seconds)
2022-11-15 15:55:26 +0100sagax(~sagax_nb@user/sagax) (Ping timeout: 246 seconds)
2022-11-15 15:55:50 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 240 seconds)
2022-11-15 15:56:13 +0100auri(~auri@fsf/member/auri)
2022-11-15 15:59:08 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2022-11-15 15:59:50 +0100evanvarvell(~evanvarve@097-088-181-216.res.spectrum.com) (Quit: Leaving)
2022-11-15 16:00:09 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection)
2022-11-15 16:02:55 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-15 16:03:44 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 260 seconds)
2022-11-15 16:09:03 +0100jakalx(~jakalx@base.jakalx.net) ()
2022-11-15 16:09:06 +0100 <slack1256> Does levity polymorphism interact with laziness somehow?
2022-11-15 16:12:03 +0100mikoto-chan(~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Ping timeout: 256 seconds)
2022-11-15 16:12:26 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:bd85:df8c:c85c:33a7) (Quit: WeeChat 2.8)
2022-11-15 16:12:40 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-15 16:14:53 +0100 <merijn> slack1256: Define "interact"?
2022-11-15 16:14:55 +0100slack1256(~slack1256@191.125.99.216) (Ping timeout: 260 seconds)
2022-11-15 16:16:14 +0100 <romes[m]> Hi! How does the Eq instance for `Ptr` behave? Is it pointer equality as in comparing addresses? I checked the source but it's automatically derived so I'm unsure
2022-11-15 16:16:41 +0100 <merijn> romes[m]: It's address equality
2022-11-15 16:16:49 +0100 <romes[m]> OK, thank you
2022-11-15 16:16:53 +0100 <merijn> romes[m]: Pretty sure the docs say that somewhere
2022-11-15 16:17:04 +0100 <romes[m]> :)
2022-11-15 16:17:47 +0100 <merijn> hmm, it doesn't
2022-11-15 16:18:04 +0100 <merijn> OTOH, you can infer it from the fact that it's "Eq (Ptr a)" rather than "Eq a => Eq (Ptr a)"
2022-11-15 16:21:00 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-11-15 16:22:11 +0100vglfr(~vglfr@145.224.100.100)
2022-11-15 16:23:29 +0100 <merijn> oh dear...
2022-11-15 16:23:47 +0100 <merijn> I had the audacity to add template-haskell as a dependency and now the compiler crashes
2022-11-15 16:24:04 +0100 <maerwald> welcome to GHC
2022-11-15 16:24:17 +0100 <merijn> Something's fucky
2022-11-15 16:24:20 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2022-11-15 16:24:29 +0100 <merijn> Why is ghc 8.10 trying to dlopen ghc9.2 libs
2022-11-15 16:24:31 +0100razetime(~quassel@117.254.34.170) (Ping timeout: 256 seconds)
2022-11-15 16:25:08 +0100vglfr(~vglfr@145.224.100.100) (Client Quit)
2022-11-15 16:25:22 +0100vglfr(~vglfr@145.224.100.100)
2022-11-15 16:27:28 +0100vglfr(~vglfr@145.224.100.100) (Client Quit)
2022-11-15 16:27:42 +0100vglfr(~vglfr@145.224.100.100)
2022-11-15 16:28:45 +0100vglfr(~vglfr@145.224.100.100) (Client Quit)
2022-11-15 16:28:46 +0100Sgeo(~Sgeo@user/sgeo)
2022-11-15 16:29:04 +0100vglfr(~vglfr@145.224.100.100)
2022-11-15 16:33:49 +0100 <merijn> maerwald: I had the audacity to define a TH function in a module whose transitive dependencies included C symbols (which are absent from the dynamic lib GHC produces and attempts to load == crisis)
2022-11-15 16:35:07 +0100 <maerwald> TH with boot files is also fun
2022-11-15 16:35:10 +0100 <maerwald> lol
2022-11-15 16:35:18 +0100 <maerwald> there are dark corners you don't wanna know
2022-11-15 16:35:24 +0100 <merijn> I'm not smart enough for boot files, somehow they never work when I try to use them
2022-11-15 16:36:14 +0100razetime(~quassel@117.254.34.209)
2022-11-15 16:36:50 +0100Guest7869(~coco@85.195.206.136)
2022-11-15 16:38:22 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-15 16:39:19 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-15 16:51:21 +0100Guest7869(~coco@85.195.206.136) (Quit: WeeChat 3.5)
2022-11-15 16:51:49 +0100c0c0(~coco@85.195.206.136)
2022-11-15 16:55:57 +0100Achylles(~Achylles_@2804:431:d724:7309:7501:feac:f03e:5f7f) (Remote host closed the connection)
2022-11-15 16:58:05 +0100jludwig(~justin@li657-110.members.linode.com) (Quit: ZNC - https://znc.in)
2022-11-15 16:59:06 +0100jludwig(~justin@li657-110.members.linode.com)
2022-11-15 17:02:04 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 17:02:22 +0100cfricke(~cfricke@user/cfricke)
2022-11-15 17:06:25 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 17:08:16 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2022-11-15 17:13:04 +0100mei(~mei@user/mei) (Remote host closed the connection)
2022-11-15 17:13:45 +0100mei(~mei@user/mei)
2022-11-15 17:19:49 +0100 <tomsmeding> maerwald: the recommended (and default) ghc version in ghcup is not supported by the default hls version
2022-11-15 17:20:08 +0100 <tomsmeding> I can see how it happens but it's a kinda unfortunate situation for newcomers :p
2022-11-15 17:22:36 +0100 <merijn> What's the recommended version?
2022-11-15 17:28:34 +0100cheater(~Username@user/cheater) (Remote host closed the connection)
2022-11-15 17:34:45 +0100moonsheep(~user@user/moonsheep)
2022-11-15 17:34:55 +0100cheater(~Username@user/cheater)
2022-11-15 17:34:55 +0100 <moonsheep> does this look alright? https://github.com/haskell/network/compare/master...jlagarespo:network:master
2022-11-15 17:35:13 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 17:35:21 +0100ub(~Thunderbi@178.165.184.78.wireless.dyn.drei.com)
2022-11-15 17:35:49 +0100 <tomsmeding> merijn: 9.2.5
2022-11-15 17:36:20 +0100 <moonsheep> shapr: not sure how to respond through lambdabot, but this may be of interest to you
2022-11-15 17:36:43 +0100 <moonsheep> is there a way to locate the context of a lambdabot message in the logs?
2022-11-15 17:37:05 +0100 <shapr> hi moonsheep !
2022-11-15 17:37:26 +0100 <shapr> thanks for the link
2022-11-15 17:37:38 +0100 <merijn> moonsheep: It looks sensible enough at first glance
2022-11-15 17:37:54 +0100 <moonsheep> there's many things that smell of bad code to me, but it's a codebase I'm very unfamiliar with
2022-11-15 17:38:09 +0100 <moonsheep> so I tried to go with the general vibe of it if that makes sense
2022-11-15 17:38:11 +0100 <merijn> although from a "clean diff" perspective the gratuitous whitespace changes are a bit yikes :)
2022-11-15 17:38:21 +0100 <moonsheep> oh yeah I gotta sort that out
2022-11-15 17:38:30 +0100 <moonsheep> I'm not used to that whitespacing style
2022-11-15 17:38:35 +0100razetime(~quassel@117.254.34.209) (Ping timeout: 260 seconds)
2022-11-15 17:38:45 +0100 <geekosaur> moonsheep, sadly the logs are not searchable (well, it offsers searching but that does nothing)
2022-11-15 17:39:06 +0100 <moonsheep> anyway, the main smell for me is the fact that there is a SocketAddress class but it is only instanced by SockAddr, which has a bunch of constructors
2022-11-15 17:39:11 +0100 <moonsheep> geekosaur: ah alright
2022-11-15 17:39:40 +0100 <merijn> moonsheep: I'm to lazy/busy to really review it in depth, but nothing jumps out as wildly wrong
2022-11-15 17:39:47 +0100 <moonsheep> good to know
2022-11-15 17:39:55 +0100 <merijn> moonsheep: Historical artifact perhaps (the class thing)
2022-11-15 17:39:58 +0100razetime(~quassel@117.193.4.187)
2022-11-15 17:40:06 +0100 <moonsheep> yeah most likely
2022-11-15 17:40:22 +0100 <moonsheep> still I think it would be cleaner to do everything through the class and with separate types for different address families
2022-11-15 17:40:32 +0100 <moonsheep> this way you could ensure type-safe addresses
2022-11-15 17:40:42 +0100 <moonsheep> it would perhaps complicate mixing different addresses a bit
2022-11-15 17:40:48 +0100 <moonsheep> which explains the SockAddr type
2022-11-15 17:41:52 +0100 <geekosaur> my guess is so it could be extended to support OSI, which has a rather different view of things
2022-11-15 17:41:58 +0100 <geekosaur> but OSI is pretty much dead
2022-11-15 17:42:02 +0100 <merijn> moonsheep: The class approach always seems like a great idea
2022-11-15 17:42:13 +0100 <merijn> moonsheep: But in my experience often isn't, especially here :p
2022-11-15 17:42:26 +0100 <moonsheep> hmm, alright then
2022-11-15 17:42:52 +0100 <merijn> I tried that approach once while implementing ZeroMQ in Haskell, it was a PITA to deal with :p
2022-11-15 17:42:54 +0100 <moonsheep> the most annoying bit is peekAddress, which I have a feeling is 50% of the reason for doing everything with a single type
2022-11-15 17:43:02 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 17:43:07 +0100 <moonsheep> merijn: well it's hard to argue with experience :p
2022-11-15 17:44:36 +0100chromoblob(~user@37.113.164.122)
2022-11-15 17:45:32 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:c1d7:1626:4211:cf1c)
2022-11-15 17:46:18 +0100 <moonsheep> merijn: oh I hadn't noticed the whitespace changes in HsNet.h
2022-11-15 17:46:26 +0100 <moonsheep> yeah I have my editor configured to automatically do that
2022-11-15 17:46:30 +0100 <moonsheep> I'll fix that in a sce
2022-11-15 17:46:47 +0100 <moonsheep> by the way, I added the stack lock file
2022-11-15 17:46:53 +0100 <moonsheep> I heard it's good practice in order to ensure reproducible builds
2022-11-15 17:46:55 +0100 <moonsheep> is that so?
2022-11-15 17:47:31 +0100 <merijn> That depends on whether you use stack at all? :p
2022-11-15 17:47:38 +0100 <moonsheep> network does
2022-11-15 17:48:50 +0100 <merijn> tbh, I suspect the stack.yaml exists mostly for "other people" since it's a widely used core package and might want to try accomoating stack
2022-11-15 17:49:49 +0100 <moonsheep> do I count as part of "other people"?
2022-11-15 17:49:54 +0100 <moonsheep> I certainly use stack
2022-11-15 17:49:58 +0100 <moonsheep> (and love it)
2022-11-15 17:49:58 +0100razetime(~quassel@117.193.4.187) (Ping timeout: 268 seconds)
2022-11-15 17:50:07 +0100razetime(~quassel@117.193.7.92)
2022-11-15 17:50:15 +0100 <merijn> moonsheep: I meant as in "I don't think the core maintainers use stack themselves" (although I might be wrong)
2022-11-15 17:50:21 +0100 <moonsheep> ah
2022-11-15 17:50:34 +0100 <moonsheep> well either way it doesn't hurt to include a lock file, now does it?
2022-11-15 17:50:49 +0100 <merijn> I have no idea, because I don't use stack either :p
2022-11-15 17:51:41 +0100 <moonsheep> well I'm no expert but I'm fairly sure not
2022-11-15 17:51:58 +0100 <moonsheep> can someone more knowledgable enlighten us?
2022-11-15 17:52:24 +0100ajb(~ajb@mimas.whatbox.ca) (Quit: bye)
2022-11-15 17:52:54 +0100Guest75(~Guest75@178.141.177.81) (Quit: Client closed)
2022-11-15 17:54:43 +0100 <moonsheep> alright, the diff should update automatically
2022-11-15 17:55:06 +0100 <moonsheep> anyway, my only remaining concern is whether any ifdefs are required around stuff (like the inclusion of if_packet.h)
2022-11-15 17:55:29 +0100 <moonsheep> do I have to check for AF_PACKET support like I have to for unix sockets?
2022-11-15 17:57:32 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 17:57:50 +0100 <geekosaur> it's probably a good idea for portability
2022-11-15 17:59:55 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 260 seconds)
2022-11-15 18:00:00 +0100 <moonsheep> how do I do that thoguh?
2022-11-15 18:00:25 +0100 <moonsheep> one of the #ifdef HAVE_x_H?
2022-11-15 18:00:30 +0100 <moonsheep> where are those defined?
2022-11-15 18:00:41 +0100 <moonsheep> there's no include from linux/ either
2022-11-15 18:00:46 +0100 <moonsheep> so I have no reference
2022-11-15 18:00:51 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection)
2022-11-15 18:00:57 +0100 <moonsheep> how can I easily contact the maintainers?
2022-11-15 18:01:05 +0100 <geekosaur> those usually come from a configure script. and most things don't include stuff from linux/ directly
2022-11-15 18:01:07 +0100 <moonsheep> if someone knows it must be them
2022-11-15 18:01:21 +0100 <moonsheep> geekosaur: well I'm pretty sure I need it for the struct
2022-11-15 18:01:26 +0100 <geekosaur> rather something in /usr/include would #include something from either linux/ or asm/
2022-11-15 18:02:36 +0100 <geekosaur> like, I just went poking for an errno and /usr/include/errno.h is just "#include <asm/errno.h>" (and that points to <asm-generic/errno.h> and that references <asm-generic/errno-base.h>)
2022-11-15 18:02:56 +0100MajorBiscuit(~MajorBisc@145.94.173.65) (Ping timeout: 268 seconds)
2022-11-15 18:03:04 +0100 <moonsheep> according to https://man7.org/linux/man-pages/man7/packet.7.html I have to include three headers
2022-11-15 18:03:33 +0100KaitoDaumoto(~asdf@user/kaitodaumoto)
2022-11-15 18:04:08 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-15 18:04:51 +0100dfee(~dfee@162-227-164-101.lightspeed.sntcca.sbcglobal.net)
2022-11-15 18:09:10 +0100Sauvin(~sauvin@user/Sauvin) (Ping timeout: 240 seconds)
2022-11-15 18:10:00 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2022-11-15 18:10:59 +0100stef204(~stef204@user/stef204)
2022-11-15 18:12:11 +0100xacktm(~xacktm@user/xacktm) (Ping timeout: 256 seconds)
2022-11-15 18:12:17 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-11-15 18:12:35 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection)
2022-11-15 18:12:44 +0100ajb(~ajb@mimas.whatbox.ca)
2022-11-15 18:13:20 +0100polo(sid532813@user/polo) ()
2022-11-15 18:14:22 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a)
2022-11-15 18:14:32 +0100Tuplanolla(~Tuplanoll@91-159-68-152.elisa-laajakaista.fi)
2022-11-15 18:15:38 +0100Sauvin(~sauvin@user/Sauvin)
2022-11-15 18:17:34 +0100econo(uid147250@user/econo)
2022-11-15 18:18:49 +0100werneta(~werneta@137.78.30.207)
2022-11-15 18:21:10 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 240 seconds)
2022-11-15 18:22:32 +0100bontaq(~user@ool-45779fe5.dyn.optonline.net)
2022-11-15 18:23:16 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 268 seconds)
2022-11-15 18:24:06 +0100xacktm(~xacktm@user/xacktm)
2022-11-15 18:25:04 +0100mbuf(~Shakthi@49.204.118.25) (Quit: Leaving)
2022-11-15 18:25:40 +0100doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Remote host closed the connection)
2022-11-15 18:26:10 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 18:28:03 +0100machinedgod(~machinedg@clnet-p10-126.ikbnet.co.at) (Ping timeout: 256 seconds)
2022-11-15 18:35:58 +0100cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.7.1)
2022-11-15 18:36:38 +0100cafkafk(~cafkafk@fsf/member/cafkafk) (Ping timeout: 255 seconds)
2022-11-15 18:36:39 +0100moonsheep(~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2))
2022-11-15 18:38:21 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) (Remote host closed the connection)
2022-11-15 18:39:21 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2022-11-15 18:40:14 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 18:40:23 +0100chele(~chele@user/chele) (Remote host closed the connection)
2022-11-15 18:40:24 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:c1d7:1626:4211:cf1c) (Quit: WeeChat 2.8)
2022-11-15 18:41:59 +0100Guest70(~Guest70@162.253.129.2)
2022-11-15 18:42:19 +0100 <Guest70> hi
2022-11-15 18:42:28 +0100coldtom(~coldtom@coldrick.cc) (Quit: Well, that's got rid of me)
2022-11-15 18:42:49 +0100coldtom(~coldtom@coldrick.cc)
2022-11-15 18:43:01 +0100Guest70(~Guest70@162.253.129.2) (Client Quit)
2022-11-15 18:44:47 +0100 <geekosaur> missed 'em
2022-11-15 18:44:51 +0100 <geekosaur> oh well
2022-11-15 18:44:55 +0100 <segfaultfizzbuzz> lol i wanted to say hi to Guest70
2022-11-15 18:45:04 +0100 <segfaultfizzbuzz> you never know they might be the next bill gates
2022-11-15 18:47:10 +0100 <segfaultfizzbuzz> is "as lazy as possible but never slower/higher latency than strict eval" a meaningful concept?
2022-11-15 18:47:51 +0100 <segfaultfizzbuzz> that is to say, is it simply a matter of more R&D that people are still talking about strictness at all in haskell (needing to annotate etc), or is there a fundamental issue?
2022-11-15 18:48:11 +0100chromoblob(~user@37.113.164.122)
2022-11-15 18:48:47 +0100 <[exa]> segfaultfizzbuzz: "as lazy as possible" is basically leaving the computer with guessing which stuff will be evaluated or not
2022-11-15 18:49:14 +0100 <[exa]> segfaultfizzbuzz: which is a pretty hard problem even in a very optimistic case
2022-11-15 18:49:44 +0100 <segfaultfizzbuzz> [exa]: kinda except you can observe program execution and make a statistical model...
2022-11-15 18:50:23 +0100 <segfaultfizzbuzz> i should say that i would be quite happy distinguishing between "early program execution" and "equilibrium program execution" where the runtime learns to execute the program
2022-11-15 18:52:29 +0100kuribas(~user@ptr-17d51epp9boz5wcvhgl.18120a2.ip6.access.telenet.be) (Remote host closed the connection)
2022-11-15 18:54:19 +0100tzh_(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2022-11-15 18:54:40 +0100coldtom(~coldtom@coldrick.cc) (Quit: Well, that's got rid of me)
2022-11-15 18:54:56 +0100coldtom(~coldtom@coldrick.cc)
2022-11-15 18:56:23 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Ping timeout: 260 seconds)
2022-11-15 18:57:58 +0100coldtom(~coldtom@coldrick.cc) (Client Quit)
2022-11-15 18:58:14 +0100coldtom(~coldtom@coldrick.cc)
2022-11-15 19:05:01 +0100nschoe(~q@2a01:e0a:8e:a190:e046:20e5:49d3:6cb9) (Remote host closed the connection)
2022-11-15 19:05:14 +0100dsrt^(~dsrt@76.145.185.103)
2022-11-15 19:06:13 +0100nschoe(~q@2a01:e0a:8e:a190:14fb:d85b:4ae9:96c6)
2022-11-15 19:08:59 +0100razetime(~quassel@117.193.7.92) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-11-15 19:09:56 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-11-15 19:10:05 +0100 <davean> segfaultfizzbuzz: a statisticaly model still involves cases where its not so you are higher latency. Just because on average you're MASSIVELY higher performing doesn't mean you don't have edge cases where you have higher latency
2022-11-15 19:11:02 +0100 <segfaultfizzbuzz> right i meant that as an argument but not as a proof that "more R&D may be able to resolve the lazy/strict dichotomy"
2022-11-15 19:11:52 +0100 <davean> No, but it can't because latency is a very strict metric and a decision can come from outside the system, and just checking if something is evaluated or not adds latency
2022-11-15 19:11:58 +0100 <segfaultfizzbuzz> it might be the case that whatever the evaluation strategy, the probability of a very long or nonterminating program goes up dramatically as the program complexity goes beyond some level
2022-11-15 19:12:24 +0100 <davean> There is no amount of research that can make latency equal. It can make it neglagable and usually faster, but it can't make the worst case better
2022-11-15 19:12:40 +0100mixfix41(~sdenynine@user/mixfix41) (Read error: Connection reset by peer)
2022-11-15 19:13:36 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 19:13:48 +0100 <davean> I can make SOME programmers lower latency always, in either direction
2022-11-15 19:14:02 +0100 <davean> Given some input
2022-11-15 19:14:09 +0100 <davean> This is basicly queueing theory
2022-11-15 19:14:20 +0100 <segfaultfizzbuzz> i mean, you can always automatically tack on a timeout for a lazy function call
2022-11-15 19:14:58 +0100 <segfaultfizzbuzz> so you can always have a deterministic bound for "maximum latency to TIMEOUT error result"
2022-11-15 19:15:02 +0100 <davean> Taht doesn't help you - evaluating the timeout is latency
2022-11-15 19:15:22 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 19:16:07 +0100 <segfaultfizzbuzz> ...maybe the ISA needs to support latency bounds?
2022-11-15 19:16:18 +0100 <davean> No, that doesn't help you, latency bounds *are latency*
2022-11-15 19:16:53 +0100 <davean> There exists a piece of hardware, it can service so many of so many types of calls per cycle
2022-11-15 19:17:10 +0100 <davean> when an event happens it has to process some sequence of instructions to service that event
2022-11-15 19:17:22 +0100titibandit(~titibandi@xdsl-78-35-167-196.nc.de)
2022-11-15 19:17:33 +0100 <segfaultfizzbuzz> this sounds like a very detailed computer architecture question--if you can't afford to fetch the current time and check it, then you would think that you can burn some transistors so that you always know what time it is...
2022-11-15 19:17:49 +0100 <davean> knowing the time isn't the problem\
2022-11-15 19:20:21 +0100 <davean> if you are lazy there can exist somewhere a non-reduced expression, if that happens to be the one you need and you need it now while it is unreduced, there are only so many "clerks" to service so many
2022-11-15 19:20:23 +0100 <davean> "customers"
2022-11-15 19:20:34 +0100 <davean> So you can induse a higher latency
2022-11-15 19:20:39 +0100 <davean> *induce
2022-11-15 19:20:47 +0100 <davean> It can go in the other direction too
2022-11-15 19:21:05 +0100 <segfaultfizzbuzz> sorry i didn't understand the "clerk" -- is this a thread of execution or perhaps a core?
2022-11-15 19:21:06 +0100 <davean> Because you are forced to reduce all expressions to be strict, you can be forced to do more work
2022-11-15 19:21:18 +0100 <davean> clerk is more an instruction unit
2022-11-15 19:21:27 +0100 <segfaultfizzbuzz> ok so part of a core?
2022-11-15 19:21:36 +0100 <davean> Yes, but that doesn't really matter
2022-11-15 19:21:42 +0100 <davean> there is work that has to be done and things that can do it
2022-11-15 19:22:27 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 256 seconds)
2022-11-15 19:24:16 +0100nschoe(~q@2a01:e0a:8e:a190:14fb:d85b:4ae9:96c6) (Quit: Switching off)
2022-11-15 19:24:28 +0100 <segfaultfizzbuzz> unfortunately i can't connect this to a direct refutation of my question -- you could imagine introducing a "time counter" alongside the "program counter", so "time taken" is defined and up-to-date at all times, and there could be a "timeout" register... if the "time counter" ever exceeds the timeout, the program instantly returns to some marked instruction and sets a timeout flag
2022-11-15 19:24:49 +0100 <davean> No, that doesn't help, because there are only so many clerks.
2022-11-15 19:24:53 +0100 <davean> They could have been doing other work
2022-11-15 19:25:12 +0100 <davean> Which is exactly why I started referencing queuing
2022-11-15 19:25:47 +0100 <segfaultfizzbuzz> this would likely be enforced by the runtime and not the program itself
2022-11-15 19:25:55 +0100 <segfaultfizzbuzz> are you speaking from *within* the program?
2022-11-15 19:26:11 +0100 <davean> I'm talking about the programs actual execution
2022-11-15 19:26:12 +0100 <segfaultfizzbuzz> the program itself would have some annotation which would say certain segments were latency sensitive
2022-11-15 19:26:47 +0100earthy(~arthurvl@2a02-a469-f5e2-1-ba27-ebff-fea0-40b0.fixed6.kpn.net) (Quit: WeeChat 2.3)
2022-11-15 19:26:53 +0100 <davean> Your adhoc patching over the things you're thinking about, thats not a solution, thats just hiding the problem till you spot it again
2022-11-15 19:27:08 +0100 <segfaultfizzbuzz> ok yeah i don't understand what you are saying unfortunately but thanks for trying
2022-11-15 19:27:33 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 256 seconds)
2022-11-15 19:27:46 +0100 <davean> The latency of the program *is litterly its instruction queue evaluation strategy*, and the optimality of that varies.
2022-11-15 19:28:06 +0100 <segfaultfizzbuzz> it seems impossible that a piece of electronics can't (1) receive information on what time it is and (2) abort when that time exceeds some limit
2022-11-15 19:28:36 +0100 <segfaultfizzbuzz> hmm interesting
2022-11-15 19:28:37 +0100 <davean> Thats not relivent, the electroncis are cycle based.
2022-11-15 19:28:49 +0100 <segfaultfizzbuzz> instruction queue is serial?
2022-11-15 19:29:01 +0100 <davean> Almost.
2022-11-15 19:29:08 +0100 <segfaultfizzbuzz> like strictly a mapping from natural numbers to instructions?
2022-11-15 19:29:18 +0100 <segfaultfizzbuzz> uh bad choice of strictly lol
2022-11-15 19:29:31 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-15 19:29:39 +0100stef204(~stef204@user/stef204) (Quit: WeeChat 3.7.1)
2022-11-15 19:29:45 +0100 <davean> Pretty close, I mean often you get 6 wide, etc, but there are exactly a set of units that evaluate them
2022-11-15 19:29:55 +0100 <davean> which you might have 2 ALUs, and 1 comparator for example
2022-11-15 19:30:03 +0100earthy(~arthurvl@2a02-a469-f5e2-1-ba27-ebff-fea0-40b0.fixed6.kpn.net)
2022-11-15 19:30:15 +0100 <davean> but it is exactly fixed width and only certain instructions can fit to certain units
2022-11-15 19:30:21 +0100 <davean> electronics aren't magic
2022-11-15 19:31:26 +0100 <davean> There is a classic problem of tasking antiaircraft guns to shoot down enemy bombers, if a bomber makes it through you blew past your latency bound
2022-11-15 19:31:36 +0100 <segfaultfizzbuzz> right
2022-11-15 19:31:37 +0100 <davean> You only have so many anti aircraft guns
2022-11-15 19:31:39 +0100 <davean> https://pubsonline.informs.org/doi/abs/10.1287/opre.5.5.644
2022-11-15 19:31:47 +0100 <davean> I reference this to show this general problem exists very broadly
2022-11-15 19:32:05 +0100 <davean> There is only so much service to go around for so many customers at a time
2022-11-15 19:32:16 +0100 <segfaultfizzbuzz> but even with "strict" eval you can also be "swamped by bombers"
2022-11-15 19:32:50 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-15 19:32:56 +0100 <davean> Yes, you get swamped in different cases
2022-11-15 19:32:58 +0100 <segfaultfizzbuzz> i think i am thinking here that "intelligent eval" is the synthesis of "lazy eval" and "eager eval"
2022-11-15 19:33:03 +0100 <davean> which is why NEITHER has the lowest latency
2022-11-15 19:33:21 +0100 <davean> Given a given PATTERN of events one will win or the other
2022-11-15 19:33:29 +0100 <segfaultfizzbuzz> which is to say that you incur a cost to "think about your evaluation" and that often it will be worthwhile to perform that thinking
2022-11-15 19:33:32 +0100 <davean> If I can pick the pattern, I can pick which wins
2022-11-15 19:33:48 +0100 <segfaultfizzbuzz> right
2022-11-15 19:33:57 +0100 <segfaultfizzbuzz> but also most of the time a mixed process is best
2022-11-15 19:34:02 +0100 <davean> Which is why I said *latency* was a very strict metric
2022-11-15 19:34:26 +0100 <davean> Latency is one of the strictest metrics you can have
2022-11-15 19:34:28 +0100 <segfaultfizzbuzz> sure, input your cost function and find the strategy which produces the best cost function
2022-11-15 19:34:47 +0100 <segfaultfizzbuzz> energy use, probability of exceeding one second to result, et cetera
2022-11-15 19:35:27 +0100 <davean> "segfaultfizzbuzz is "as lazy as possible but never slower/higher latency than strict eval" a meaningful concept?" <--- so, no, its not
2022-11-15 19:35:38 +0100 <davean> Notably Haskell isn't lazy, its non-strict
2022-11-15 19:35:48 +0100 <davean> you're talking more about non-strict
2022-11-15 19:35:56 +0100 <segfaultfizzbuzz> ok sure
2022-11-15 19:36:13 +0100 <davean> And non-strict can come up with whatever you decide is best, because everything fits in it
2022-11-15 19:36:40 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-15 19:37:10 +0100 <segfaultfizzbuzz> yeah interesting hmm
2022-11-15 19:37:14 +0100 <davean> but to be clear, no decision procedure other than the oracle can be universally lowest latency across programs and event streams
2022-11-15 19:37:29 +0100 <davean> because whatever decision you make, in SOME programs, I can screw with your latency
2022-11-15 19:37:30 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-15 19:37:54 +0100 <segfaultfizzbuzz> right it becomes an ML problem and there ain't no free lunch
2022-11-15 19:37:57 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 19:38:53 +0100 <davean> No, no
2022-11-15 19:39:10 +0100 <davean> If you COULD pick the lowest latency one for any input program that *is a solution to the halting problem*
2022-11-15 19:39:14 +0100 <davean> we're not talking ML here
2022-11-15 19:39:21 +0100 <davean> we're talking fundimental mathematics
2022-11-15 19:39:23 +0100 <segfaultfizzbuzz> ok
2022-11-15 19:39:33 +0100 <davean> It *can not exist*
2022-11-15 19:40:54 +0100 <davean> If you can tell me the latency I know if the program halts :-p
2022-11-15 19:40:59 +0100 <segfaultfizzbuzz> haha
2022-11-15 19:41:28 +0100 <segfaultfizzbuzz> well regardless in "real world situations" it seems like it would be useful to build hybrid execution strategies
2022-11-15 19:41:33 +0100 <davean> We do
2022-11-15 19:41:36 +0100 <davean> We already have that
2022-11-15 19:41:41 +0100 <davean> Thats how GHC works
2022-11-15 19:41:49 +0100 <segfaultfizzbuzz> ghc observes the program execution?
2022-11-15 19:41:50 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 240 seconds)
2022-11-15 19:42:03 +0100 <davean> No, it does compile time demand annalysis
2022-11-15 19:42:11 +0100 <davean> runtime would be a JIT
2022-11-15 19:42:14 +0100 <davean> other people do that
2022-11-15 19:43:05 +0100 <segfaultfizzbuzz> hm ok
2022-11-15 19:43:12 +0100 <segfaultfizzbuzz> thanks for the teachings, i need to run unfortunately
2022-11-15 19:43:15 +0100 <davean> You could ALSO JIT GHC
2022-11-15 19:43:20 +0100 <davean> No one has
2022-11-15 19:43:38 +0100 <segfaultfizzbuzz> pretty wild since it's a mature research language
2022-11-15 19:44:00 +0100 <[exa]> > kinda except you can observe program execution and make a statistical model...
2022-11-15 19:44:02 +0100 <lambdabot> <hint>:1:79: error:
2022-11-15 19:44:03 +0100 <lambdabot> parse error (possibly incorrect indentation or mismatched brackets)
2022-11-15 19:44:21 +0100 <segfaultfizzbuzz> [exa]: ok i'll hang around for your comment, what would you like to say?
2022-11-15 19:44:29 +0100 <[exa]> (apologies to lambdabot I'm still in the olden mail years)
2022-11-15 19:44:34 +0100 <segfaultfizzbuzz> haha
2022-11-15 19:45:16 +0100 <[exa]> segfaultfizzbuzz: that thing with statistics kinda works optimistically with smaller languages (like, that's what branch predictors do, right), but for anything more complex than assembly it fails in most terrible ways
2022-11-15 19:45:33 +0100 <segfaultfizzbuzz> yeah i think that's because it is early days for statistics
2022-11-15 19:45:47 +0100 <davean> [exa]: I mean it fails for assembly in general, it works for small parts of assembly :)
2022-11-15 19:45:48 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a)
2022-11-15 19:45:49 +0100 <geekosaur> uh
2022-11-15 19:46:07 +0100 <segfaultfizzbuzz> the biggest problem i have with how computer science is written is that it tends to ignore the fact that substantially all inputs come from some form of distribution
2022-11-15 19:46:08 +0100 <[exa]> segfaultfizzbuzz: I invite you to go tell this to statisticians here
2022-11-15 19:46:39 +0100 <geekosaur> I'm no statistician, but I know Itanium failed because this didn't work
2022-11-15 19:46:41 +0100 <davean> <having just cited queueing theory, comment about not talking about distributions>
2022-11-15 19:46:55 +0100 <geekosaur> even at assembly level
2022-11-15 19:47:12 +0100 <[exa]> c'mon I said it "kinda works optimistically"
2022-11-15 19:47:26 +0100 <[exa]> no sight of optimality
2022-11-15 19:48:02 +0100 <geekosaur> statistics has been around for longer than computers, and CS is quite aware of it
2022-11-15 19:48:13 +0100 <davean> [exa]: oh sure, I just meant some parts it doesn't work on. Like how long an FPU will take for FPU scheduling
2022-11-15 19:48:27 +0100 <[exa]> segfaultfizzbuzz: so well, imagine a computer program that simulates a decision of whatever branch/strictness predictor you have, and does precisely the opposite
2022-11-15 19:48:31 +0100 <geekosaur> one problem with taking the statistical route is you pay *heavily* if you end up out on the long tail
2022-11-15 19:49:53 +0100 <[exa]> segfaultfizzbuzz: people thought for a long time that this can be solved by just banning all programs that would do the predictions; unfortunately like 90 years ago it turned out that's ineffective
2022-11-15 19:50:21 +0100 <geekosaur> that failed in Babbage's time, arguably 🙂
2022-11-15 19:51:51 +0100 <monochrom> You need to say "kinda works kinda optimistically". The same way we sometimes have "unique up to unique isomorphism" >:)
2022-11-15 19:51:57 +0100 <davean> geekosaur: I was trying to explain that to him above!
2022-11-15 19:52:21 +0100beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt)
2022-11-15 19:52:38 +0100 <davean> I was specificily trying to get into the tail component
2022-11-15 19:52:51 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 260 seconds)
2022-11-15 19:53:04 +0100 <[exa]> they timed out :(
2022-11-15 19:53:22 +0100 <davean> Lol, yes they did
2022-11-15 19:53:24 +0100 <[exa]> that's one way to battle undecidability I guess.
2022-11-15 19:53:27 +0100 <int-e> nobody predicted that
2022-11-15 19:53:34 +0100 <[exa]> lol
2022-11-15 19:53:37 +0100 <monochrom> hahaha
2022-11-15 19:53:47 +0100 <davean> int-e: well, other than some anti aircraft gunners in the first world war :)
2022-11-15 19:54:25 +0100 <int-e> davean: I was replying to "they timed out" but I guess that works too
2022-11-15 19:54:40 +0100 <davean> int-e: Me too
2022-11-15 19:54:46 +0100 <monochrom> I kinda did and always do. This is why my policy is "don't answer to answer, just don't answer". :)
2022-11-15 19:55:00 +0100 <davean> The queuing theory field was largely developed around your battle timing out
2022-11-15 19:55:53 +0100MajorBiscuit(~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net)
2022-11-15 19:56:34 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 19:57:01 +0100beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 256 seconds)
2022-11-15 19:58:16 +0100 <monochrom> Now I remember: https://danluu.com/cocktail-ideas/ applies.
2022-11-15 20:00:44 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 20:01:30 +0100 <int-e> . o O ( Aka "I could implement Twitter over an extended weekend". )
2022-11-15 20:01:45 +0100 <dminuoso> `data Ptr a = Ptr Addr# deriving (Eq, Ord)` - how can this function in GHC, given that `class Eq a where ...` without polykinds enabled?
2022-11-15 20:02:33 +0100 <dolio> Yeah, I was wondering that, too.
2022-11-15 20:02:38 +0100 <dolio> Might be some magic.
2022-11-15 20:03:15 +0100 <geekosaur> what version of ghc?
2022-11-15 20:03:28 +0100 <dminuoso> % data MyPtr = MyPtr Addr# deriving Eq
2022-11-15 20:03:28 +0100 <yahb2> <no output>
2022-11-15 20:03:40 +0100 <dminuoso> Lets say 9.0.2 or newer
2022-11-15 20:04:11 +0100 <geekosaur> 9.0.2 rules out what I was thinking (iirc ghc2021 enables polykinds and is on by default in ghc 9.2+)
2022-11-15 20:04:34 +0100 <geekosaur> but then Ptr was H98
2022-11-15 20:04:37 +0100 <dminuoso> % import GHC.Exts
2022-11-15 20:04:37 +0100 <yahb2> <no output>
2022-11-15 20:04:43 +0100 <dminuoso> % :set -XMagicHash
2022-11-15 20:04:43 +0100 <yahb2> <no output>
2022-11-15 20:04:50 +0100 <dminuoso> % :t (unsafeCoerce# 3# :: Addr#) == (unsafeCoerce# 3# :: Addr#)
2022-11-15 20:04:50 +0100 <yahb2> <interactive>:1:2: error: ; • Couldn't match a lifted type with an unlifted type ; When matching types ; a0 :: * ; Addr# :: TYPE 'AddrRep ; • In the first argument of ...
2022-11-15 20:05:11 +0100 <dolio> It goes back pretty far.
2022-11-15 20:05:17 +0100 <monochrom> Try putting that into your MyPtr type.
2022-11-15 20:05:31 +0100MajorBiscuit(~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Ping timeout: 256 seconds)
2022-11-15 20:05:35 +0100 <geekosaur> afaik it doesn't compare the Addr#s, just the pointers to the MyPtr itself
2022-11-15 20:05:37 +0100 <dminuoso> % :t MyPtr (unsafeCoerce# 3# :: Addr#) == MyPtr (unsafeCoerce# 3# :: Addr#)
2022-11-15 20:05:37 +0100 <yahb2> MyPtr (unsafeCoerce# 3# :: Addr#) == MyPtr (unsafeCoerce# 3# :: Addr#) ; :: Bool
2022-11-15 20:05:38 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 268 seconds)
2022-11-15 20:05:39 +0100 <monochrom> But it smells deep magic, yeah.
2022-11-15 20:06:08 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) (Quit: Leaving)
2022-11-15 20:06:32 +0100 <dolio> That code is in base 4.0.0.0. Hackage doesn't seem to have docs for the 3.x versions.
2022-11-15 20:06:37 +0100 <dminuoso> geekosaur: If that was the case, Eq on Ptr would not be useful much. You have reallyUnsafePtrEquality for that.
2022-11-15 20:06:53 +0100 <dminuoso> I would really expect Eq on Ptr to do equality on the contained Addr#
2022-11-15 20:07:04 +0100 <EvanR> Axman6, according to network package docs, Handle isn't recommended for networking and we should use Socket instead
2022-11-15 20:07:19 +0100 <EvanR> not that it helps do nonstandard stuff with it
2022-11-15 20:09:40 +0100stef204(~stef204@user/stef204)
2022-11-15 20:09:56 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 20:10:05 +0100 <EvanR> a paper I was reading clarifies the word unsafe as they used it in some name, that it requires additional proof obligations from the programmer that the compiler can't check. Now I'm seeing if that applies to anything that comes up with unsafe in the name, or if it's just a tautology
2022-11-15 20:10:47 +0100 <EvanR> reallyUnsafe = evenMoreProofObligations? xD
2022-11-15 20:10:48 +0100 <int-e> dminuoso: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Infer.hs#L520-527 seems relevant
2022-11-15 20:12:08 +0100 <monochrom> Nice, thanks int-e.
2022-11-15 20:12:41 +0100 <dminuoso> int-e: Is there some wired-in Addr type, perhaps?
2022-11-15 20:14:19 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 260 seconds)
2022-11-15 20:14:22 +0100 <int-e> there's also this https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L2379-2411
2022-11-15 20:14:30 +0100 <monochrom> Addr# would be the wired-in address type. Just like Int# is wired-in machine-size int.
2022-11-15 20:14:56 +0100 <int-e> So... hmm. The note doesn't seem accurate.
2022-11-15 20:15:07 +0100 <dminuoso> monochrom: Sure but the note suggests that it does some `box Int# into Int by just stripping the trailing # off`. So I would expect this to occur with `Addr#` too
2022-11-15 20:15:21 +0100 <dminuoso> Hence "will this box Addr# into Addr too? Where is that Addr type?
2022-11-15 20:15:36 +0100 <int-e> It's probably accurate for `Show` but we're talking about Eq and Ord.
2022-11-15 20:15:38 +0100 <dolio> It might know how to equate Addr#, though.
2022-11-15 20:15:39 +0100 <monochrom> Oh! Sorry, then I don't know.
2022-11-15 20:15:49 +0100 <dolio> No reason to box for that.
2022-11-15 20:16:14 +0100 <geekosaur> or might know that it can box Addr# into an Int
2022-11-15 20:16:18 +0100 <int-e> We can't derive Show for types having an Addr# field.
2022-11-15 20:16:52 +0100 <geekosaur> that kills that, then
2022-11-15 20:16:55 +0100 <int-e> Digging further into Eq, this is also relevant: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L2513-2518
2022-11-15 20:17:11 +0100 <dminuoso> prim_eq mmm
2022-11-15 20:17:45 +0100 <dminuoso> https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L2407
2022-11-15 20:17:48 +0100 <monochrom> EvanR: That definition of "unsafe" applies to unsafePerformIO (you prove that your use case doesn't have an actual effect) and vector's unsafeIndex (you prove that your use case doesn't have array-out-of-bounds). I don't know how much it extends to other functions, but I bet most.
2022-11-15 20:17:54 +0100 <int-e> dminuoso: it's extractd from the primOrdOps thing that I linked just before
2022-11-15 20:18:00 +0100 <dminuoso> https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L1600
2022-11-15 20:18:02 +0100 <dminuoso> Here we go
2022-11-15 20:18:12 +0100 <monochrom> I don't know what happens to "reallyUnsafe" etc.
2022-11-15 20:18:14 +0100 <dminuoso> int-e: Yeah, so this is where it comes from. Nice.
2022-11-15 20:18:41 +0100 <monochrom> (I have a guess. Those mean you have to know how GHC generates code.)
2022-11-15 20:19:01 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 20:19:45 +0100 <dminuoso> int-e: So that table from my second to last link https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L2384-2411 seems to be the associating prim types with the necessary primops for lt, le, eq, ge and gt.
2022-11-15 20:19:55 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection)
2022-11-15 20:20:34 +0100 <EvanR> so that would make C unsafe but not really unsafe? xD
2022-11-15 20:20:51 +0100 <dminuoso> geekosaur: Okay so that answers that question. Equality on Ptr will do an equality check on the contained Addr# pointer.
2022-11-15 20:20:55 +0100 <EvanR> because a lot of effort is placed in modern C on not asking or tell what the compiler does
2022-11-15 20:21:00 +0100 <int-e> EvanR: My understanding has always been that the "reallyUnsafe" is to say "this may look like a safe operation, but it is, actually, unsafe" (it has some fancy effects, most notably that two values that once compared equal can later become unequal. and then equal once again, I think.
2022-11-15 20:21:07 +0100 <monochrom> I guess that depends on how much UB you have in your C code? :)
2022-11-15 20:21:57 +0100 <EvanR> inActualityUnsafe haha
2022-11-15 20:22:19 +0100 <monochrom> There are people who take the stance "C means C without UB". To them C is merely unsafe, yeah.
2022-11-15 20:22:22 +0100 <dminuoso> int-e, EvanR: reallyUnsafePtrEquality
2022-11-15 20:22:24 +0100 <EvanR> turnsOutIt'sUnsafe
2022-11-15 20:22:25 +0100 <int-e> EvanR: otoh people sometimes assume that reallyUnsafePtrEquality# can compare distinct heap objects as equal, and that actually never happens; there can't be any GC in the middle of it because it's between heap checks
2022-11-15 20:22:25 +0100 <dminuoso> https://stackoverflow.com/a/24602066/6636995
2022-11-15 20:22:28 +0100 <dminuoso> Sorry ^- that link
2022-11-15 20:22:39 +0100 <dminuoso> That's some quite disgusting fact about reallyUnsafePtrEquality
2022-11-15 20:22:58 +0100 <monochrom> But there are other people who take the stance "well without UB you can't even write non-toy programs" so you get into reallyUnsafe territory.
2022-11-15 20:23:20 +0100 <monochrom> i.e., exactly you need to know what your C compiler actually do and count on it.
2022-11-15 20:23:41 +0100 <int-e> dminuoso: "I hate indirections"
2022-11-15 20:23:47 +0100 <EvanR> that seems to be status quo back in the days of B
2022-11-15 20:23:57 +0100 <dminuoso> So I guess reallyUnsafePtrEquality can work on thunks too.
2022-11-15 20:24:13 +0100 <int-e> dminuoso: they should've done the performGC, then recheck thing.
2022-11-15 20:24:28 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 20:24:30 +0100 <dminuoso> int-e: Yeah, that note about the performMinorGC is truly even more terrifying.
2022-11-15 20:24:36 +0100 <int-e> (which has to be done carefully, because of opportunistic CSE))
2022-11-15 20:24:42 +0100 <dminuoso> "Look, just perform a garbage collecting before comparing for equality. Obviously!"
2022-11-15 20:25:59 +0100 <int-e> dminuoso: Oh right, static indirections are a thing too... that's a detail that would have escaped me. Still, I basically know all this so I'm not upset :P
2022-11-15 20:26:25 +0100 <segfaultfizzbuzz> to those who were trying to talk to me, i am reading the irc archive :-) pardon the timeout
2022-11-15 20:26:25 +0100 <dminuoso> int-e: Ohhh static indirections that are cleaned up by GC?!
2022-11-15 20:26:33 +0100 <dminuoso> I see.
2022-11-15 20:26:47 +0100kenran(~user@user/kenran)
2022-11-15 20:26:51 +0100 <monochrom> Yeah make sure you evaluate everything and then perform GC. Turn on StrictData or something. :)
2022-11-15 20:26:53 +0100 <dminuoso> Yeah it makes sense to me now as well. That primitive deserves its name, but I think the haddock should really point all thesee things out.
2022-11-15 20:27:16 +0100 <EvanR> dminuoso, having trouble following that linked example. They read in 1 Bool and print out 2?
2022-11-15 20:27:49 +0100 <monochrom> I think the first "True" line is user input.
2022-11-15 20:27:56 +0100 <int-e> dminuoso: I don't think it can move those.
2022-11-15 20:27:57 +0100 <dminuoso> Yup, its the line echo from readLn
2022-11-15 20:28:05 +0100 <EvanR> I see, so Nothing is not necessarily the same object as Nothing
2022-11-15 20:28:22 +0100 <dminuoso> EvanR: no it is.
2022-11-15 20:28:36 +0100 <int-e> dminuoso: Which means that even after fully evaluating everything you'll need and performing a GC, some Nothings may still be different from others.
2022-11-15 20:28:40 +0100 <EvanR> not according to reallyUnsafePtrEquality#?
2022-11-15 20:28:43 +0100 <monochrom> Oh, you're looking at laziness forming an "if ... then ... else ..." thunk and leaving it unevaluated.
2022-11-15 20:28:50 +0100 <EvanR> oh
2022-11-15 20:28:56 +0100 <dminuoso> EvanR: but the thing is reallyUnsafePtrEquality# just works on whatever address there physically ends up. Thunks, indirections..
2022-11-15 20:29:15 +0100 <monochrom> So obviously it has a different address from False's, even though eventually it could be evaluated to False one day.
2022-11-15 20:29:26 +0100 <dminuoso> int-e: I guess reallyUnsafePtrEquality# just compares *entry* code pointer?
2022-11-15 20:29:28 +0100 <c_wraith> Is backpack usable these days?
2022-11-15 20:29:35 +0100 <dminuoso> (whatever that entry code pointer is)
2022-11-15 20:29:51 +0100 <dminuoso> c_wraith: Sure, aside from the complete lack of documentation.
2022-11-15 20:30:07 +0100 <EvanR> this raises the question of how you could ever use reallyUnsafePtrEquality# for fun and profit, which I guess is what you were just discussing
2022-11-15 20:30:09 +0100 <int-e> You can also start out with a single thunk and get unlucky with parallel evaluation and get two different heap objects for it as a result. This gets worse when it involves unsafe code... oh the perils of dupablePerformIO
2022-11-15 20:30:18 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-11-15 20:30:27 +0100 <dminuoso> Last time I talked to Ed, it was "read the original PhD thesis and browse through my repositories to see how backpack functions and is to be used"
2022-11-15 20:30:30 +0100 <dminuoso> Nothing beyond that
2022-11-15 20:30:30 +0100 <int-e> dminuoso: No, it compares the heap object address
2022-11-15 20:30:34 +0100 <c_wraith> monochrom: in GHC, all evaluated Falses have the same pointer. (all evaluated nullary constructors, in general)
2022-11-15 20:30:35 +0100 <monochrom> Oh wait the "print $ a == a'" gets it evaluated. I need a different explanation. But what they said above about an indirection.
2022-11-15 20:30:55 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Quit: Leaving)
2022-11-15 20:31:21 +0100 <int-e> dminuoso: The entry pointer is a further indirection, and it doesn't uniquely determine a value either, since the rest of the heap objects may be part of it.
2022-11-15 20:31:29 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-15 20:32:12 +0100 <EvanR> c_wraith, so Nothing is the same as False? Again haskell trying to compete with javascript or ruby
2022-11-15 20:32:22 +0100 <dminuoso> int-e: Okay, what about an indirection closure then? What would it use for that?
2022-11-15 20:32:24 +0100 <c_wraith> EvanR: I worded that poorly... :P
2022-11-15 20:32:34 +0100 <int-e> "it"?
2022-11-15 20:32:36 +0100 <monochrom> http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf slide 39 applies. You have the address of an "Ind" object on the heap.
2022-11-15 20:32:54 +0100 <c_wraith> EvanR: *each* nullary constructor exists on the heap exactly once, in an evaluated form.
2022-11-15 20:33:15 +0100 <EvanR> ok and the types have their own objects
2022-11-15 20:33:19 +0100 <c_wraith> yes
2022-11-15 20:33:22 +0100 <int-e> dminuoso: reallyUnsafePtrEquality does not look at the heap.
2022-11-15 20:33:26 +0100 <EvanR> what a waste of space!
2022-11-15 20:33:59 +0100 <int-e> dminuoso: it makes no difference whether there's an indirection there, or a thunk, or a constructor
2022-11-15 20:34:08 +0100 <int-e> or a Fun
2022-11-15 20:34:09 +0100 <int-e> FUN
2022-11-15 20:34:09 +0100 <monochrom> Ugh nullary constructors don't even exist on the heap. They're in a static data segment.
2022-11-15 20:34:12 +0100 <dminuoso> int-e: then how can a performMinorGC have any impact?
2022-11-15 20:34:21 +0100gmg(~user@user/gehmehgeh)
2022-11-15 20:34:57 +0100 <int-e> dminuoso: because it changes values in the stack to point to the new heap, and it elides indirections from the heap representation.
2022-11-15 20:35:03 +0100 <c_wraith> monochrom: ok, fair. Each evaluated nullary constructor has exactly one in memory *somewhere*. :P
2022-11-15 20:35:22 +0100 <dolio> Or is it?
2022-11-15 20:35:30 +0100 <int-e> and while the GC is running, all the values that might feed into primitive operations like rUPE are on the stack
2022-11-15 20:35:33 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 256 seconds)
2022-11-15 20:35:35 +0100 <dminuoso> int-e: Just to avoid confusion, when you mean elide indirections from the heap represetation, do you mean eliminiating indirect thunks?
2022-11-15 20:35:46 +0100 <dminuoso> (that is thunks of type indirect)
2022-11-15 20:36:06 +0100 <monochrom> Yes.
2022-11-15 20:36:11 +0100 <int-e> it's called an indirection inside GHC, there are no indirect thunks.
2022-11-15 20:36:32 +0100 <monochrom> Anyone who pointed to the Ind object are modified to point to Nothing directly.
2022-11-15 20:36:36 +0100 <int-e> an indirection might point to a thunk, so that terminology becomes confusing
2022-11-15 20:36:51 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 20:37:02 +0100 <monochrom> Perhaps the wording "path compression" helps, if you've seen it before.
2022-11-15 20:38:16 +0100 <dminuoso> Indirections just occur if the original closure was not large enough for the computed value, right?
2022-11-15 20:38:22 +0100CiaoSen(~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-11-15 20:38:43 +0100 <dolio> That's not the only possibility.
2022-11-15 20:40:26 +0100coot(~coot@213.134.171.3) (Quit: coot)
2022-11-15 20:41:07 +0100 <dolio> Like, if you imagine a loop like `foo x 0 = x ; foo x n = let y = x in loop y (n-1)`, and you imagine not just inlining it, you don't want to write back to `n` thunks whenver you compute a final value.
2022-11-15 20:42:18 +0100 <dolio> So you use indirections. Naively you might write something that has to follow O(n) indirections, depending on which `y` you're looking at. But GHC instead points them all at one spot, so they all end up with at most one indirection, I think.
2022-11-15 20:42:31 +0100 <dolio> Or maybe at most two or something.
2022-11-15 20:42:38 +0100 <dolio> Then GC can fix things up later.
2022-11-15 20:43:57 +0100 <int-e> There's a fun case where a thread receives an asynchronous exception... where the stack is unwound into thunks up to the point where the exception is caught.
2022-11-15 20:44:29 +0100 <int-e> dolio: hmm, wouldn't that just accumulate update frames on the stack (well, ignoring the fact that there's a tail call optimization that would get rid of that)
2022-11-15 20:45:42 +0100 <dolio> Well, you could. But it's better to have a rule to not push another update frame if one is already on the stack. Instead just write an indirection to that update frame.
2022-11-15 20:45:47 +0100 <int-e> (I'm not sure, I definitely don't know the exact conditions for when GHC's runtime creates indirections.)
2022-11-15 20:46:05 +0100 <dolio> Makes it harder to overflow the stack.
2022-11-15 20:46:15 +0100 <dolio> Back when that mattered.
2022-11-15 20:47:22 +0100 <int-e> let y = x won't create an indirecion.
2022-11-15 20:48:22 +0100cheater(~Username@user/cheater) (Quit: BitchX: more nutritious than a six-pack.)
2022-11-15 20:48:42 +0100 <dolio> Well, I don't think GHC will literally compile that to an actual operation.
2022-11-15 20:49:50 +0100 <dolio> But if you ended up with the equivalent of that in STG, the semantics are to build a thunk for y that refers to x.
2022-11-15 20:50:22 +0100 <dolio> You probably need to try harder to make this case matter in actual Haskell code.
2022-11-15 20:50:23 +0100 <int-e> naively, it'll allocate a register, copy the register that holds x, and then jump to the entry point for `loop` again.
2022-11-15 20:51:12 +0100 <int-e> I guess you have something like y = id x in mind, hmm. That would build a thunk though, not an indirection.
2022-11-15 20:51:33 +0100 <dolio> It's when you're evaluating one of the ys.
2022-11-15 20:52:03 +0100 <int-e> pretty sure it isn't
2022-11-15 20:52:14 +0100 <int-e> we got stack overflows instead, because of update frames
2022-11-15 20:52:30 +0100 <int-e> before GHC learned to grow the stack on the heap instead.
2022-11-15 20:52:30 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Quit: Leaving)
2022-11-15 20:52:41 +0100 <dolio> Not from this case, you didn't.
2022-11-15 20:53:03 +0100 <dolio> Unless they threw out the optimization that specifically gets talked about in, like, STG papers.
2022-11-15 20:53:05 +0100 <int-e> it's no different from the usual iterate (+1) 0 !! 1000000 case, is it?
2022-11-15 20:53:37 +0100 <dolio> That one isn't just a string of updates, there are (+1) operations at every step.
2022-11-15 20:53:45 +0100 <dolio> Every thunk is different.
2022-11-15 20:53:59 +0100 <WarzoneCommand> does anyone know what the latest recommended way of setting up doctest with cabal is? What I would like is: cabal test <name-of-the-doctest-testsuite> 1) automatically figures out which files have doctests, 2) runs all of them, and 3) it selects automatically whatever cabal default extensions I've set in my cabal file. Does something like that currently exist?
2022-11-15 20:54:01 +0100 <int-e> well, you either have that or you have neither thunk nor indirection.
2022-11-15 20:54:33 +0100 <WarzoneCommand> I have/had some hacky doctest.hs in which I've manually collected some hs files to run doctest on + some big list of ghc flags to pass. But that is not particularly nice.
2022-11-15 20:54:48 +0100cheater(~Username@user/cheater)
2022-11-15 20:54:53 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2022-11-15 20:56:04 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 20:56:09 +0100 <WarzoneCommand> the cabal bugtrackers states something about code-gen and test drivers ( https://github.com/haskell/cabal/pull/7688 ) but it is not clear to me whether that is just an experiment or that this has crystalized out properly somehow
2022-11-15 20:56:29 +0100 <int-e> dolio: there's the selector thunk story which is related but again different.
2022-11-15 20:57:33 +0100cheater(~Username@user/cheater) (Client Quit)
2022-11-15 20:58:15 +0100 <int-e> Which will help for f (a, b) = if b == 0 then a else f (a, b - 1)
2022-11-15 20:58:42 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-11-15 21:00:23 +0100 <dolio> g f x 0 = x ; g f x n = let y = f x in g f y (n-1) ; main = print (g id 5 100000000)
2022-11-15 21:00:24 +0100 <int-e> err. f (~(a, b)) = if b == 0 then a else f (a, b - 1)
2022-11-15 21:01:08 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 21:01:10 +0100 <dolio> ./Foo +RTS -K1k
2022-11-15 21:01:14 +0100 <dolio> No stack overflow.
2022-11-15 21:01:47 +0100 <dolio> Uses 8GB of memory, though, so there's probably a thunk.
2022-11-15 21:05:08 +0100cheater(~Username@user/cheater)
2022-11-15 21:05:49 +0100 <int-e> I think it builds the whole chain of applications of `f`-s as a thunk, but because `id` is properly tail recursive, evaluating that thunk chain doesn't blow up the stack.
2022-11-15 21:06:12 +0100 <int-e> (if you don't optimize or protect against inlining `g`)
2022-11-15 21:07:47 +0100 <int-e> (tail recursion is the difference to (+1))
2022-11-15 21:07:49 +0100 <dolio> How do you avoid overflowing the stack while also pushing 100 million update frames on it?
2022-11-15 21:08:10 +0100 <int-e> you don't have to push an update frame if you do tail recursion
2022-11-15 21:08:27 +0100 <int-e> the update is done by the caller with the final result
2022-11-15 21:09:04 +0100 <geekosaur> also if it's updating the same thing it doesn't push a new update frame, it just rewrites the value in the existing one
2022-11-15 21:09:08 +0100 <int-e> ...that's wrong. the update frame was put there by the caller
2022-11-15 21:09:30 +0100 <int-e> (cps transform makes this confusing)
2022-11-15 21:09:41 +0100machinedgod(~machinedg@clnet-b05-118.ikbnet.co.at)
2022-11-15 21:09:57 +0100 <int-e> there is no value to rewrite
2022-11-15 21:10:17 +0100 <int-e> functions have results
2022-11-15 21:11:39 +0100polo(sid532813@id-532813.tinside.irccloud.com)
2022-11-15 21:12:31 +0100coot(~coot@213.134.171.3)
2022-11-15 21:12:50 +0100earthy(~arthurvl@2a02-a469-f5e2-1-ba27-ebff-fea0-40b0.fixed6.kpn.net) (Quit: WeeChat 2.3)
2022-11-15 21:13:02 +0100polo(sid532813@id-532813.tinside.irccloud.com) (Changing host)
2022-11-15 21:13:02 +0100polo(sid532813@user/polo)
2022-11-15 21:13:06 +0100polomoney
2022-11-15 21:13:23 +0100wootehfoot(~wootehfoo@user/wootehfoot)
2022-11-15 21:13:55 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 21:15:27 +0100 <dolio> If you feed (+1) into my g function, it will overflow the stack.
2022-11-15 21:16:12 +0100 <int-e> Yes. But... actually not because of update frames. It'll be all the pending +1 operations.
2022-11-15 21:16:32 +0100 <int-e> g finishes without overflowing the stack
2022-11-15 21:16:34 +0100 <dolio> It will also have many more update frames.
2022-11-15 21:16:50 +0100 <dolio> Update frames happen when you evaluate the result of g to print it.
2022-11-15 21:17:43 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2022-11-15 21:19:41 +0100random-jellyfish(~random-je@user/random-jellyfish)
2022-11-15 21:21:55 +0100 <int-e> Hmm
2022-11-15 21:24:47 +0100mmhat(~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-11-15 21:24:58 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 21:25:09 +0100mmhat(~mmh@p200300f1c7050c1bee086bfffe095315.dip0.t-ipconnect.de)
2022-11-15 21:25:42 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2022-11-15 21:25:56 +0100akirksall(~akirksall@cpe-24-90-197-230.nyc.res.rr.com)
2022-11-15 21:27:36 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 260 seconds)
2022-11-15 21:27:42 +0100 <dolio> It's true that id doesn't use any stack of its own. But it ensures that GHC builds 100 million updating closures that point to one another.
2022-11-15 21:27:57 +0100 <dolio> And we're printing the outermost one.
2022-11-15 21:28:55 +0100 <dolio> id not using stack is essential for the update frame rule to kick in.
2022-11-15 21:31:56 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-15 21:34:32 +0100akirksall(~akirksall@cpe-24-90-197-230.nyc.res.rr.com) ()
2022-11-15 21:38:43 +0100srz(~srz@devil.dm.uba.ar)
2022-11-15 21:38:52 +0100jlgw(~jw@83-233-104-81.cust.bredband2.com)
2022-11-15 21:39:53 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-15 21:41:06 +0100chromoblob(~user@37.113.164.122)
2022-11-15 21:44:25 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2022-11-15 21:44:54 +0100freeside_(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 21:46:06 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection)
2022-11-15 21:46:37 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 252 seconds)
2022-11-15 21:47:04 +0100lyle(~lyle@104.246.145.85) (Quit: WeeChat 3.7.1)
2022-11-15 21:50:34 +0100pavonia(~user@user/siracusa)
2022-11-15 21:54:10 +0100srz(~srz@devil.dm.uba.ar) (Ping timeout: 268 seconds)
2022-11-15 21:55:55 +0100 <monochrom> Ugh, if I compile with -prof, it grows stack (near the end), and overflows 1k stack.
2022-11-15 21:56:04 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq)
2022-11-15 21:56:45 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-11-15 21:58:10 +0100coot(~coot@213.134.171.3) (Quit: coot)
2022-11-15 22:03:54 +0100moonsheep(~user@user/moonsheep)
2022-11-15 22:03:56 +0100moonsheep(~user@user/moonsheep) (Client Quit)
2022-11-15 22:04:00 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds)
2022-11-15 22:05:16 +0100werneta(~werneta@137.78.30.207) (Ping timeout: 268 seconds)
2022-11-15 22:06:02 +0100 <EvanR> overflows a 1k stack, there goes my haskell on arduino project
2022-11-15 22:06:02 +0100waleee(~waleee@h-176-10-137-138.NA.cust.bahnhof.se)
2022-11-15 22:06:18 +0100 <monochrom> Turn off profiling and you'll be alright. :)
2022-11-15 22:07:09 +0100 <monochrom> I'm looking at the cmm code, and comparing with vs without profiling. It does look like the stack growth is caused by profiling instrumentation.
2022-11-15 22:10:46 +0100 <monochrom> I.e., in that example, one has to build a thunk for "y = f x" and later evaluate it. Without profiling, that thunk is trivial, as is its evaluation because f=id. With profiling, the thunk seems to request going through a bean counter first, so maybe the bean counter consumes stack.
2022-11-15 22:12:05 +0100michalz(~michalz@185.246.207.197) (Remote host closed the connection)
2022-11-15 22:12:14 +0100 <dolio> Yeah, could be.
2022-11-15 22:12:27 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 22:12:34 +0100 <geekosaur> that might conceivably be considered a bug
2022-11-15 22:13:12 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de)
2022-11-15 22:14:20 +0100beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt)
2022-11-15 22:14:28 +0100irrgit_(~irrgit@89.47.234.26) (Quit: Leaving)
2022-11-15 22:14:31 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2022-11-15 22:14:40 +0100 <dolio> It keeps track of nested costs. I don't know what it would report in this case, but possibly it can't actually do its report without making this case use stack.
2022-11-15 22:15:01 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2022-11-15 22:15:39 +0100 <dolio> Like, if you take the iterations way down, and remove the stack limit, does it show some 1000-fold nesting of cost centers?
2022-11-15 22:16:22 +0100freeside_(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds)
2022-11-15 22:16:36 +0100ub(~Thunderbi@178.165.184.78.wireless.dyn.drei.com) (Ping timeout: 260 seconds)
2022-11-15 22:16:36 +0100werneta(~werneta@137.79.197.69)
2022-11-15 22:16:39 +0100emmanuelux(~emmanuelu@user/emmanuelux)
2022-11-15 22:21:27 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 22:26:46 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Ping timeout: 252 seconds)
2022-11-15 22:28:28 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 22:29:11 +0100`2jt(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 260 seconds)
2022-11-15 22:37:23 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 256 seconds)
2022-11-15 22:40:35 +0100Guest75(~Guest75@178.141.177.81)
2022-11-15 22:44:44 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 268 seconds)
2022-11-15 22:46:37 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b)
2022-11-15 22:47:23 +0100werneta(~werneta@137.79.197.69) (Ping timeout: 260 seconds)
2022-11-15 22:47:59 +0100kenaryn(~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr)
2022-11-15 22:50:50 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds)
2022-11-15 22:52:05 +0100chromoblob(~user@37.113.164.122)
2022-11-15 22:54:30 +0100catern(~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407)
2022-11-15 22:58:21 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds)
2022-11-15 23:00:03 +0100 <monochrom> No.
2022-11-15 23:02:26 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2022-11-15 23:05:29 +0100rendar(~Paxman@user/rendar) (Ping timeout: 260 seconds)
2022-11-15 23:07:27 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-11-15 23:07:48 +0100 <monochrom> In fact I think I read somewhere in the GHC user's guide that the profiler run time detects reentrance and prevents reporting unbounded nesting.
2022-11-15 23:08:05 +0100werneta(~werneta@137.78.30.207)
2022-11-15 23:09:13 +0100 <monochrom> It would rather report "cost centre foo has 10^100 entries" than report "foo -> foo -> foo..." 10^100 times.
2022-11-15 23:10:12 +0100fockerize(~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr)
2022-11-15 23:12:07 +0100zeenk(~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!)
2022-11-15 23:12:45 +0100 <monochrom> So for our example, time profiling (-p) reports the nesting MAIN->CAF->main->g->g.y (the chain stops there), and g.y has n entries. Memory cost-centre profiling with eventlog (-hc -l) and eventlog2html shows just a depth-4 tree of cost-centres, too.
2022-11-15 23:20:15 +0100 <monochrom> TIL emacs auto-revert-mode. Super useful when I have loaded a foo.dump-stg-final files into emacs and want it auto-refreshed every time I recompile.
2022-11-15 23:21:15 +0100slack1256(~slack1256@186.11.56.146)
2022-11-15 23:22:07 +0100 <slack1256> Is there an equivalent to '-xc' for ghci? I can trigger an exception on a IO action, but I just get the `displayException` message, not the type.
2022-11-15 23:22:24 +0100 <slack1256> I need the type to constraint `try @ThisType` on the source code.
2022-11-15 23:23:31 +0100 <geekosaur> I suspect you'd need to get a ghci built for profiling, which would mean building ghc yourself
2022-11-15 23:23:54 +0100gmg(~user@user/gehmehgeh) (Quit: Leaving)
2022-11-15 23:23:58 +0100 <monochrom> I suspect that -xc results in a similar message anyway.
2022-11-15 23:24:12 +0100 <monochrom> http://www.vex.net/~trebla/haskell/exception-tutorial.xhtml#supertyping is what actually helps.
2022-11-15 23:24:12 +0100 <geekosaur> have you tried using a typed hole ? `try @_`
2022-11-15 23:24:47 +0100 <slack1256> geekosaur: That is an great idea, let me try
2022-11-15 23:25:07 +0100 <monochrom> And if you aren't inclined to modify your code... The code I show on that page could also be manually done on the REPL.
2022-11-15 23:25:19 +0100 <slack1256> Wait, I thought @_ on type applications did not mean "type hole". Instead they meant "omit binding this type variable
2022-11-15 23:25:37 +0100 <geekosaur> hm, possibly
2022-11-15 23:25:38 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 23:26:06 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2022-11-15 23:27:17 +0100 <geekosaur> come to think of it, if @_ did what I wanted then it wouldn't be necessary…
2022-11-15 23:27:33 +0100 <geekosaur> (the TypeApplication, that is)
2022-11-15 23:27:39 +0100 <geekosaur> sad
2022-11-15 23:28:44 +0100 <slack1256> But the advice given by the page linked by monochrom has a great outlook. I will use the Typeable instance and the `typeOf` combinator. I have avoided Typeable all my life, lol.
2022-11-15 23:28:56 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2022-11-15 23:29:22 +0100 <monochrom> Every exception type has a Typeable instance (because superclass of Exception) so you aren't really using extra features.
2022-11-15 23:30:18 +0100 <geekosaur> actually, every type has a Typeable instance these days
2022-11-15 23:30:19 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142) (Ping timeout: 260 seconds)
2022-11-15 23:30:23 +0100 <geekosaur> ghc uses them internally
2022-11-15 23:30:49 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-15 23:30:51 +0100 <monochrom> Well at least those are not exposed, while Exception's is.
2022-11-15 23:31:23 +0100 <geekosaur> you have to declare them to use them (deriving Typeable, but LANGUAGE DeriveTypeable is gone) but they're there
2022-11-15 23:31:37 +0100 <monochrom> ghci needs it for sure. Compiled code though still has type erasure to the maximum extent.
2022-11-15 23:31:47 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds)
2022-11-15 23:32:11 +0100 <geekosaur> right, you'd only see it in compiled code if you did something that captured the dictionary
2022-11-15 23:34:25 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-15 23:35:33 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 23:35:39 +0100 <int-e> dolio: Oh... I understand now. Either version of the code produces 100M update frames. However, the `id` case has them all adjacent and that means that when the stack overflows (which does happen!), there's an opportunity to *squeeze* it. rts/ThreadPaused.c
2022-11-15 23:35:46 +0100shapr(~user@68.54.166.125) (Remote host closed the connection)
2022-11-15 23:37:18 +0100 <int-e> Which probably also explains monochrom's stack overflow... profiling leaves cost center information on the stack, so the update frames are no longer adjacent.
2022-11-15 23:37:41 +0100 <monochrom> Ah.
2022-11-15 23:38:15 +0100 <int-e> Err, I meant to link to https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/ThreadPaused.c#L81
2022-11-15 23:38:16 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds)
2022-11-15 23:39:29 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-15 23:40:07 +0100titibandit(~titibandi@xdsl-78-35-167-196.nc.de) (Remote host closed the connection)
2022-11-15 23:40:36 +0100 <dolio> Maybe it's faster to push update frames and only coalesce them on certain events.
2022-11-15 23:40:39 +0100 <int-e> (and that indeed produces indirections to a thunk, which may later be updated by another indirection)
2022-11-15 23:43:15 +0100 <dolio> It would be a little surprising if hitting a hard stack limit is the only even that causes it.
2022-11-15 23:43:29 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Client Quit)
2022-11-15 23:43:37 +0100 <int-e> it's the soft stack limit
2022-11-15 23:43:39 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com)
2022-11-15 23:44:12 +0100 <dolio> Like, probably every time you have to allocate a new chunk, you should check if your entire chunk is update frames or something, and not do that.
2022-11-15 23:44:12 +0100 <int-e> so the point where a new stack chunk would have to be allocated
2022-11-15 23:45:37 +0100Lycurgus(~juan@user/Lycurgus)
2022-11-15 23:45:44 +0100 <int-e> I really should've found this sooner, but I expected this to happen closer to the GC code. (it belongs under rts/sm, to my mind)
2022-11-15 23:46:05 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1)
2022-11-15 23:46:30 +0100 <int-e> More precisely, `threadPaused` is where the code ends up when a heap or stack check fails, so either of those can trigger a stack squeeze.
2022-11-15 23:47:03 +0100sammelweis(~quassel@c-68-48-18-140.hsd1.mi.comcast.net)
2022-11-15 23:47:10 +0100 <int-e> (The former means the nursery is full, or an async exception is being delivered... the latter means the current stack chunk is full)
2022-11-15 23:48:09 +0100 <int-e> (Hmm, can an exception trigger both? I don't know.)
2022-11-15 23:48:13 +0100 <dolio> There are other situations like this, too, although I forget what a good example is.
2022-11-15 23:48:57 +0100 <dolio> Like, you could do checks all the time to detect a bad state, but that's expensive, so you run the dumb way most of the time, but whenever you're paused for something else, you do the check to see if you're in a bad state.
2022-11-15 23:50:00 +0100 <int-e> one thing that comes to mind is reference counting and efforts to make it more lazy
2022-11-15 23:50:31 +0100 <dolio> Oh, I mean something that GHC actually does.
2022-11-15 23:50:38 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-15 23:51:19 +0100 <int-e> not bothering with atomic operations when entering a thunk, even though that might cause duplicate evaluation
2022-11-15 23:51:42 +0100segfaultfizzbuzz(~segfaultf@12.172.217.142)
2022-11-15 23:53:54 +0100random-jellyfish(~random-je@user/random-jellyfish) (Quit: Client closed)
2022-11-15 23:55:30 +0100chromoblob(~user@37.113.164.122) (Ping timeout: 240 seconds)
2022-11-15 23:56:25 +0100 <dolio> Yeah, maybe it's black holes? Like, you can just naively evaluate a loop for a bit, and when you pause for GC, you can look at what you're doing and figure out you're in a loop?
2022-11-15 23:57:17 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds)
2022-11-15 23:57:35 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-15 23:58:20 +0100 <dolio> And that saves time when you're not evaluating loops, which is most of the time.
2022-11-15 23:58:29 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-11-15 23:59:25 +0100mmhat(~mmh@p200300f1c7050c1bee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1)