Logs on 2022-11-15 (liberachat/#haskell)
| 00:01:39 | <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? |
| 00:02:22 | <twb> | I know how to do it in C but not in haskell |
| 00:04:14 | × | Techcable quits (~Techcable@user/Techcable) (Ping timeout: 260 seconds) |
| 00:05:42 | <Axman6> | if it's doable in C using standard system calls it should be doable in Haskell |
| 00:07:30 | <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. |
| 00:09:16 | <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. |
| 00:09:26 | <jean-paul[m]> | does this kind of thing exist anywhere in the Haskell ecosystem? |
| 00:09:26 | × | mmhat quits (~mmh@p200300f1c71c150dee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 00:11:26 | <twb> | jean-paul[m]: so the app still has to be patched? |
| 00:11:58 | <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" |
| 00:14:18 | <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 |
| 00:14:38 | → | libertyprime joins (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) |
| 00:16:43 | × | CiaoSen quits (~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 00:17:44 | × | Tuplanolla quits (~Tuplanoll@91-159-68-194.elisa-laajakaista.fi) (Quit: Leaving.) |
| 00:20:02 | → | CiaoSen joins (~Jura@p5dcc1f3a.dip0.t-ipconnect.de) |
| 00:23:17 | <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 |
| 00:23:44 | <geekosaur> | python e.g. doesn't care so much about crossplatform |
| 00:29:02 | → | InstX1 joins (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 00:29:03 | <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" |
| 00:30:09 | × | kenaryn quits (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Quit: leaving) |
| 00:30:12 | <twb> | sort of surprising Windows doesn't have socket activation yet |
| 00:30:40 | <geekosaur> | it may, it just doesn't use file descriptors to represent sockets, they're a completely different namespace |
| 00:30:51 | <twb> | gotcha |
| 00:31:06 | <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. |
| 00:31:11 | <geekosaur> | similarly withh mailbboxes and other non-file things |
| 00:32:06 | → | kenaryn joins (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 00:32:11 | × | kenaryn quits (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Client Quit) |
| 00:32:24 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 00:33:49 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 00:33:50 | → | slac65015 joins (~slack1256@191.126.99.192) |
| 00:35:50 | × | slack1256 quits (~slack1256@186.11.56.146) (Ping timeout: 240 seconds) |
| 00:36:33 | × | CiaoSen quits (~Jura@p5dcc1f3a.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 00:37:07 | × | InstX1 quits (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 00:38:13 | → | CiaoSen joins (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 00:39:48 | → | InstX1 joins (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 00:40:49 | × | emmanuelux quits (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 00:41:00 | polo | is now known as money |
| 00:57:30 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4b68) |
| 00:58:41 | × | ChaiTRex quits (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 01:00:09 | → | ChaiTRex joins (~ChaiTRex@user/chaitrex) |
| 01:01:22 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 01:04:13 | → | califax joins (~califax@user/califx) |
| 01:08:17 | → | srz joins (~srz@179.36.85.167) |
| 01:13:15 | × | xcmw quits (~textual@50.93.222.82) (Ping timeout: 268 seconds) |
| 01:13:59 | × | Kaipei quits (~Kaiepi@108.175.84.104) (Ping timeout: 260 seconds) |
| 01:15:30 | × | xff0x quits (~xff0x@2405:6580:b080:900:fc69:8fe6:1c5d:8fdb) (Ping timeout: 240 seconds) |
| 01:16:47 | × | acidjnk quits (~acidjnk@p200300d6e7137a015d19df638f338baf.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 01:17:10 | × | Maeda quits (~Maeda@91-161-10-149.subs.proxad.net) (Ping timeout: 240 seconds) |
| 01:18:43 | money | is now known as polo |
| 01:19:03 | polo | is now known as money |
| 01:21:02 | → | wroathe joins (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 01:21:03 | × | wroathe quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 01:21:03 | → | wroathe joins (~wroathe@user/wroathe) |
| 01:21:42 | money | is now known as polo |
| 01:24:12 | → | Maeda joins (~Maeda@91-161-10-149.subs.proxad.net) |
| 01:24:18 | <kronicmage> | anyone know how to make stack compile a project with -XGHC2021 by default? |
| 01:24:36 | <kronicmage> | it doesn't seem to accept it in the `default-extensions:` field of package.yaml |
| 01:25:39 | <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 |
| 01:30:34 | → | justsomeguy joins (~justsomeg@user/justsomeguy) |
| 01:34:20 | × | justsomeguy quits (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 01:37:22 | × | dfee quits (~dfee@162-227-164-101.lightspeed.sntcca.sbcglobal.net) (Quit: dfee) |
| 01:37:56 | → | evanvarvell joins (~evanvarve@097-088-181-216.res.spectrum.com) |
| 01:39:48 | <sm> | some related discussion at https://github.com/commercialhaskell/stack/issues/5739 .. have you got an up to date stack ? |
| 01:41:02 | → | razetime joins (~quassel@117.193.3.56) |
| 01:42:33 | <kronicmage> | sm: yes according to ghcup |
| 01:42:53 | <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 |
| 01:46:14 | × | ec quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
| 01:47:54 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 01:53:24 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 01:54:30 | → | xff0x joins (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 01:55:18 | × | Guest75 quits (~Guest75@178.141.177.81) (Ping timeout: 260 seconds) |
| 01:57:54 | <sm> | got a paste of your yaml ? |
| 01:58:19 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 02:02:20 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 02:04:02 | <Axman6> | Generally, cabal is better at keeping up to date with GHC for things like this |
| 02:05:01 | <kronicmage> | sm: https://paste.tomsmeding.com/E1RImxWt |
| 02:05:58 | × | caryhartline quits (~caryhartl@2600:1700:2d0:8d30:1d0b:eb23:aba0:7ca3) (Quit: caryhartline) |
| 02:06:43 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 260 seconds) |
| 02:08:25 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::4b68) (Quit: Going elsewhere) |
| 02:09:28 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4b68) |
| 02:09:37 | <ephemient> | I think that's a hpack issue, not stack specifically: https://github.com/sol/hpack/issues/481 |
| 02:10:46 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::4b68) (Client Quit) |
| 02:11:50 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4b68) |
| 02:12:41 | → | frase joins (~Fraser@159.196.13.21) |
| 02:12:54 | <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 |
| 02:13:19 | <sm> | so: default-language: GHC2021 |
| 02:13:34 | <frase> | FOSDEM 2023 Haskell devroom CfP: https://discourse.haskell.org/t/fosdem-2023-haskell-devroom-call-for-participation/5310 |
| 02:13:47 | <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 |
| 02:14:55 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 268 seconds) |
| 02:15:04 | <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." |
| 02:17:25 | × | InstX1 quits (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 02:17:44 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::4b68) (Quit: Going elsewhere) |
| 02:18:36 | <sm> | kronicmage: oh correction: in package.yaml it would be `language: GHC2021`, per docs: https://github.com/sol/hpack#common-fields |
| 02:19:39 | → | ddellacosta joins (~ddellacos@89.45.224.150) |
| 02:20:03 | <kronicmage> | sm: ah i guess the latest stack still doesn't ship the appropriate hpack version then |
| 02:20:08 | <kronicmage> | standalone hpack can do it, but my stack still cannot |
| 02:20:21 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4b68) |
| 02:20:33 | ← | twb parts (~twb@159-196-230-25.9fc4e6.mel.nbn.aussiebb.net) (rcirc on GNU Emacs 28.1) |
| 02:20:34 | <sm> | stack --version tells which hpack you have built in to stack. The latest stack has the latest hpack |
| 02:20:43 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::4b68) (Client Quit) |
| 02:20:49 | <sm> | 0.35 on my machine |
| 02:22:03 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4b68) |
| 02:22:08 | <geekosaur> | alos, make sure you're using the right resolver: one based on 8.10.7 or 9.0.2 won't support GHC2021 |
| 02:22:20 | <geekosaur> | that came in with ghc 9.2.x |
| 02:22:42 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 02:25:13 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 02:28:11 | → | bobbingbob joins (~bobbingbo@2604:3d09:207f:f650::b469) |
| 02:34:15 | × | beteigeuze quits (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds) |
| 02:34:43 | × | forell quits (~forell@user/forell) (Ping timeout: 260 seconds) |
| 02:37:10 | × | CiaoSen quits (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 02:39:23 | × | waleee quits (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds) |
| 02:41:04 | → | forell joins (~forell@user/forell) |
| 02:41:45 | → | mixfix41 joins (~sdenynine@user/mixfix41) |
| 02:42:18 | → | off^ joins (~off@76.145.185.103) |
| 02:43:22 | × | srz quits (~srz@179.36.85.167) (Remote host closed the connection) |
| 02:44:31 | × | ystael quits (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 02:44:33 | <kronicmage> | geekosaur: ah yes that's it |
| 02:44:41 | <kronicmage> | the lts is still on ghc 9.0.2 alas :/ |
| 02:45:53 | → | waleee joins (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 02:46:16 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 02:48:32 | <kronicmage> | anyone know how to use haskell-language-server with alex/happy files? |
| 02:56:57 | → | jinsun joins (~jinsun@user/jinsun) |
| 02:59:30 | × | sh1n quits (~sh1n@186.152.126.112) (Remote host closed the connection) |
| 02:59:45 | <sm> | twb: nice to hear of gitit users.. maybe there's something in the issue tracker ? |
| 03:00:26 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 03:04:50 | × | jero98772 quits (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 03:05:01 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 03:05:10 | → | hsw_ joins (~hsw@112-104-142-182.adsl.dynamic.seed.net.tw) |
| 03:05:56 | → | wroathe_ joins (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 03:05:56 | × | wroathe_ quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Client Quit) |
| 03:06:43 | × | hsw quits (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 256 seconds) |
| 03:07:09 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 03:07:56 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 03:09:38 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 03:10:07 | × | euandreh quits (~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds) |
| 03:11:07 | × | td_ quits (~td@83.135.9.3) (Ping timeout: 260 seconds) |
| 03:12:23 | × | forell quits (~forell@user/forell) (Ping timeout: 256 seconds) |
| 03:12:47 | → | td_ joins (~td@83.135.9.38) |
| 03:14:39 | × | youziqi quits (~youziqi@103.37.140.125) (Ping timeout: 256 seconds) |
| 03:16:48 | → | youziqi joins (~youziqi@103.37.140.93) |
| 03:18:26 | → | forell joins (~forell@user/forell) |
| 03:19:30 | × | bobbingbob quits (~bobbingbo@2604:3d09:207f:f650::b469) (Ping timeout: 240 seconds) |
| 03:20:46 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 03:24:36 | × | zeenk quits (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 03:26:42 | × | infinity0 quits (~infinity0@pwned.gg) (Ping timeout: 252 seconds) |
| 03:28:10 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 03:29:26 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 03:32:47 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 03:33:13 | × | euandreh quits (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 03:33:58 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 03:37:50 | × | ddellacosta quits (~ddellacos@89.45.224.150) (Ping timeout: 240 seconds) |
| 03:38:27 | × | razetime quits (~quassel@117.193.3.56) (Ping timeout: 256 seconds) |
| 03:40:09 | × | euandreh quits (~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds) |
| 03:42:04 | → | finsternis joins (~X@23.226.237.192) |
| 03:42:51 | × | terrorjack quits (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 03:44:10 | → | terrorjack joins (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 03:48:02 | × | shriekingnoise quits (~shrieking@186.137.167.202) (Ping timeout: 268 seconds) |
| 03:53:50 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 03:54:47 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 03:55:50 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 03:56:01 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::4b68) (Ping timeout: 256 seconds) |
| 03:58:51 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 04:01:33 | → | shriekingnoise joins (~shrieking@186.137.167.202) |
| 04:05:39 | × | slac65015 quits (~slack1256@191.126.99.192) (Read error: Connection reset by peer) |
| 04:08:22 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 04:10:14 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 04:13:13 | × | euandreh quits (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 04:15:13 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 04:19:43 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 04:23:52 | × | ezzieyguywuf quits (~Unknown@user/ezzieyguywuf) (Remote host closed the connection) |
| 04:25:06 | × | iteratee quits (~kyle@162.218.222.107) (Read error: Connection reset by peer) |
| 04:27:08 | → | ezzieyguywuf joins (~Unknown@user/ezzieyguywuf) |
| 04:28:19 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 04:30:17 | → | iteratee joins (~kyle@162.218.222.107) |
| 04:31:01 | → | razetime joins (~quassel@117.193.3.56) |
| 04:35:42 | → | Genius123 joins (~Genius123@71.169.167.129) |
| 04:35:48 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 04:40:27 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 04:45:19 | × | Vajb quits (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 04:45:35 | → | Vajb joins (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 04:49:19 | × | off^ quits (~off@76.145.185.103) (Remote host closed the connection) |
| 04:49:35 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 04:50:50 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 04:51:33 | × | youziqi quits (~youziqi@103.37.140.93) (Ping timeout: 268 seconds) |
| 04:51:33 | → | mbuf joins (~Shakthi@49.204.118.25) |
| 04:51:38 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds) |
| 04:51:57 | → | youziqi joins (~youziqi@103.37.140.125) |
| 04:53:04 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 04:57:47 | × | euandreh quits (~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds) |
| 04:58:08 | → | Techcable joins (~Techcable@user/Techcable) |
| 05:02:54 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 05:12:27 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 05:21:19 | × | waleee quits (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds) |
| 05:29:10 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds) |
| 05:31:11 | × | Vajb quits (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 05:31:16 | × | thyriaen quits (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 05:31:18 | → | Vajb joins (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 05:31:34 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 05:34:01 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 05:34:05 | × | wroathe quits (~wroathe@user/wroathe) (Quit: leaving) |
| 05:34:12 | × | zaquest quits (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 05:34:23 | → | wroathe joins (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 05:34:24 | × | wroathe quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 05:34:24 | → | wroathe joins (~wroathe@user/wroathe) |
| 05:35:06 | → | chromoblob joins (~user@37.113.164.122) |
| 05:35:22 | → | zaquest joins (~notzaques@5.130.79.72) |
| 05:54:49 | × | libertyprime quits (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds) |
| 05:55:01 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 256 seconds) |
| 05:56:55 | × | xff0x quits (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds) |
| 05:58:50 | → | xff0x joins (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 06:00:57 | → | takuan joins (~takuan@178-116-218-225.access.telenet.be) |
| 06:03:44 | → | michalz joins (~michalz@185.246.207.197) |
| 06:09:11 | × | wroathe quits (~wroathe@user/wroathe) (Quit: leaving) |
| 06:09:33 | → | libertyprime joins (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) |
| 06:11:44 | × | califax quits (~califax@user/califx) (Ping timeout: 255 seconds) |
| 06:12:33 | → | califax joins (~califax@user/califx) |
| 06:13:59 | → | bgs joins (~bgs@212-85-160-171.dynamic.telemach.net) |
| 06:20:55 | → | aliosablack joins (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 06:23:45 | → | califax_ joins (~califax@user/califx) |
| 06:24:44 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 06:27:30 | × | califax quits (~califax@user/califx) (Quit: ZNC 1.8.2 - https://znc.in) |
| 06:27:32 | califax_ | is now known as califax |
| 06:44:20 | × | pieguy128 quits (~pieguy128@65.93.192.212) (Quit: ZNC 1.8.2 - https://znc.in) |
| 06:44:22 | → | kenran joins (~user@user/kenran) |
| 06:44:43 | → | pieguy128 joins (~pieguy128@65.93.192.212) |
| 06:53:21 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 06:57:21 | <tomsmeding> | dminuoso: how do I efficiently parse an array using flatparse? |
| 06:59:01 | <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 |
| 06:59:03 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 06:59:16 | <tomsmeding> | (or a non-binary file format, for that matter) |
| 06:59:36 | <tomsmeding> | frase: not yet listed on https://fosdem.org/2023/schedule/tracks/ |
| 07:00:34 | → | titibandit joins (~titibandi@xdsl-78-35-167-196.nc.de) |
| 07:00:42 | → | machinedgod joins (~machinedg@clnet-p10-126.ikbnet.co.at) |
| 07:03:40 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 07:05:59 | × | jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 07:15:11 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds) |
| 07:16:13 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 07:16:33 | → | TheCreatorOfCrea joins (~TheCreato@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de) |
| 07:18:45 | <TheCreatorOfCrea> | Hi. I’m stumped… I thought this syntax was normal Haskell: data T = T { x :: Eq a => a } |
| 07:18:59 | × | bgs quits (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 07:20:19 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 07:20:32 | → | enoq joins (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 07:20:53 | <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 () } |
| 07:21:55 | → | Kaipei joins (~Kaiepi@108.175.84.104) |
| 07:23:35 | <c_wraith> | TheCreatorOfCrea: those are existential, because they contain a type that doesn't appear in the head. |
| 07:23:42 | <sm> | TheCreatorOfCrea: I believe you would have to declare s and its constraint the left hand side, ie make s a parameter of Betty |
| 07:24:05 | <c_wraith> | TheCreatorOfCrea: existentials probably aren't what you want. Especially not the existential typeclass anti-pattern |
| 07:24:51 | <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. |
| 07:24:51 | <TheCreatorOfCrea> | sm: Yeah, I read that giving contexts to data type declarations would result in cumbersomeness. :) |
| 07:25:06 | <c_wraith> | Constraints should be where they provide value |
| 07:25:42 | <TheCreatorOfCrea> | sm: I want to constrain the `speak` function’s type. Because that’s a normal thing we do to function types. |
| 07:26:03 | <c_wraith> | constrain places where the constraint lets you do something |
| 07:26:07 | <c_wraith> | Otherwise, don't |
| 07:26:38 | <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… |
| 07:26:52 | <sm> | record accessor functions are expected, required I assume, to operate on the record - not just have any arbitrary type you choose |
| 07:26:54 | <c_wraith> | yes, because you're creating existentials |
| 07:27:11 | <c_wraith> | existential types require an extension |
| 07:27:17 | × | cheater quits (~Username@user/cheater) (Remote host closed the connection) |
| 07:28:07 | <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? |
| 07:28:22 | <sm> | hmm, maybe listen to c_wraith not me, it's late here |
| 07:28:31 | <sm> | and I don't have GHC in front of me |
| 07:28:34 | <c_wraith> | TheCreatorOfCrea: because you're creating existential types |
| 07:28:51 | → | chromoblob joins (~user@37.113.164.122) |
| 07:29:36 | <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? |
| 07:29:55 | <c_wraith> | It's not what you want. |
| 07:29:59 | <TheCreatorOfCrea> | sm: I’m just as tired. :) |
| 07:30:14 | <TheCreatorOfCrea> | c_wraith: How did you determine that? |
| 07:30:38 | <c_wraith> | because you're not writing code in one of the patterns where it helps more than it causes problems |
| 07:31:34 | <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 |
| 07:31:43 | <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. :) |
| 07:31:57 | <c_wraith> | TheCreatorOfCrea: because you're describing the existential typeclass anti-pattern |
| 07:32:11 | <TheCreatorOfCrea> | c_wraith: Not saying you’re wrong, btw. |
| 07:35:18 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 07:35:25 | → | cheater joins (~Username@user/cheater) |
| 07:36:12 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 07:38:24 | × | euandreh quits (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 07:40:31 | × | cheater quits (~Username@user/cheater) (Read error: Connection reset by peer) |
| 07:43:09 | <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 |
| 07:43:10 | <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? |
| 07:44:02 | <TheCreatorOfCrea> | s/or/of/ |
| 07:45:11 | <TheCreatorOfCrea> | c_wraith: The objects are so state can be carried in the closure. |
| 07:45:25 | <c_wraith> | Hmm. Ok, I misread what you were looking for based on your first example not being a function. |
| 07:45:43 | <c_wraith> | you want to require that the functions inside the record are polymorphic? |
| 07:46:51 | → | cheater joins (~Username@user/cheater) |
| 07:47:23 | <TheCreatorOfCrea> | c_wraith: One of the functions only, yes. |
| 07:47:49 | <TheCreatorOfCrea> | c_wraith: Possibly without the whole type turning into existential dread. ;) |
| 07:47:59 | <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 |
| 07:48:10 | <tomsmeding> | ) |
| 07:48:15 | <c_wraith> | TheCreatorOfCrea: then you want a higher-rank type |
| 07:48:25 | <c_wraith> | TheCreatorOfCrea: the RankNTypes extension will do the job |
| 07:48:39 | <c_wraith> | (the reason why it's a higher-rank type is that it makes the type of the constructor higher-rank) |
| 07:49:06 | <tomsmeding> | (then you get: { draw :: forall area. IsArea area => area -> outM (), ...}) |
| 07:49:08 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 07:49:26 | <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. |
| 07:49:39 | <tomsmeding> | it lets you avoid higher-rank types :p |
| 07:49:52 | <tomsmeding> | which is not necessarily something to want per se, but it makes type inference nicer sometiems |
| 07:50:18 | <tomsmeding> | a situation where you _cannot_ do the simple thing I mentioned is if you want a list of Visibles with different 'area' variables |
| 07:50:20 | × | Unicorn_Princess quits (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 07:50:31 | <TheCreatorOfCrea> | Yes, higher rank types seem very close to that existential thing, no? ^^ |
| 07:50:42 | <c_wraith> | very close, but the exact opposite. :) |
| 07:50:51 | <c_wraith> | I like higher-rank types quite a lot |
| 07:50:58 | <c_wraith> | They actually are closely related. |
| 07:51:00 | <tomsmeding> | higher-rank types is having nested foralls in types (i.e. universally quantified types); existenials are existentially quantified types |
| 07:51:04 | <c_wraith> | mathematically they're duals |
| 07:51:16 | <tomsmeding> | you can encode the latter with the former, and in haskell you have to, because haskell doesn't have native existentials (yet) :) |
| 07:51:26 | <c_wraith> | uhc does. |
| 07:51:32 | <tomsmeding> | O.o |
| 07:51:40 | <c_wraith> | but you can't put a constraint on an existentially-quantified type |
| 07:51:44 | <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. |
| 07:51:45 | <tomsmeding> | okay, *ghc doesn't have native existentials |
| 07:53:11 | → | use-value1 joins (~Thunderbi@2a00:23c6:8a03:2f01:d5b6:b99f:4049:77a7) |
| 07:54:34 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:bd85:df8c:c85c:33a7) |
| 07:55:07 | <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. ;) |
| 07:55:16 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 07:55:30 | × | use-value quits (~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Ping timeout: 240 seconds) |
| 07:55:30 | use-value1 | is now known as use-value |
| 07:55:40 | <tomsmeding> | "dual" is not well-defined |
| 07:55:47 | <tomsmeding> | it kinda means what you just wrote :p |
| 07:55:56 | <c_wraith> | In this case, it means that you can represent either one in terms of the other, with some juggling |
| 07:55:58 | <tomsmeding> | in specific contexts it has very specific meanings, but in general it's just this vague concept |
| 07:56:40 | <TheCreatorOfCrea> | lol. okay, I’m relieved then. :D … |
| 07:56:49 | → | causal joins (~user@50.35.83.177) |
| 07:57:02 | <c_wraith> | like... `Foo -> exists a. a' is the same thing as `Foo -> (forall a. a -> b) -> b' |
| 07:57:06 | <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 |
| 07:57:16 | <tomsmeding> | but not always |
| 07:57:26 | <c_wraith> | you can change between exists and forall with a CPS transform |
| 07:59:04 | <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. |
| 07:59:26 | <c_wraith> | ah, sorry. yes, it's *that* existential! |
| 07:59:41 | TheCreatorOfCrea | is now known as ExistentialDread |
| 07:59:46 | <tomsmeding> | :p |
| 08:00:01 | <tomsmeding> | ooh, precisely 16 chars |
| 08:01:19 | <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. ;) |
| 08:08:53 | × | razetime quits (~quassel@117.193.3.56) (Ping timeout: 268 seconds) |
| 08:10:11 | → | mmhat joins (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) |
| 08:10:15 | × | DDR quits (~DDR@2604:3d08:4c7f:8250:7335:db3e:c155:4272) (Ping timeout: 260 seconds) |
| 08:16:42 | <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? |
| 08:17:08 | <tomsmeding> | an implementation necessarily exists, because there, well, exists one? |
| 08:17:20 | <dminuoso> | Given that you can mechanically transform one into the other, I would say if one must exist, the other does anyway. |
| 08:18:05 | <dminuoso> | tomsmeding: By `array` do you mean `Array`? |
| 08:18:14 | <tomsmeding> | dminuoso: yes, or Vector, or similar things |
| 08:18:56 | <tomsmeding> | I can see how to build a list, but not how to build an Array without an intermediate list |
| 08:19:01 | <dminuoso> | tomsmeding: Well, you can simply parse into a CStringLen I suppose. |
| 08:19:02 | <tomsmeding> | (relevant for very large inputs) |
| 08:19:10 | <dminuoso> | And then memcpy it out |
| 08:19:17 | <tomsmeding> | oh with IO |
| 08:19:17 | <dminuoso> | (Or have your Array point into the buffer) |
| 08:19:28 | <dminuoso> | Well you dont need IO to create a CStringLen |
| 08:19:36 | <dminuoso> | You just have to worry about lifetime |
| 08:19:51 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 08:19:51 | <tomsmeding> | in my case the elements of the array wouldn't be bytes |
| 08:19:58 | <tomsmeding> | they would be further parseable things |
| 08:20:12 | <dminuoso> | Is the memory represeentation the same? |
| 08:20:16 | <dminuoso> | (Or well I guess not?) |
| 08:20:38 | <tomsmeding> | not necessarily, array of Texts is a possibility |
| 08:21:07 | <dminuoso> | It's a good question actually, Im fairly sure this will involve unsafePerformIO'ing |
| 08:21:22 | <tomsmeding> | that's what I was fearing |
| 08:21:29 | <tomsmeding> | if Parser was ParserT then you could do this |
| 08:21:30 | <dminuoso> | Well, without IO you dont have a mechanism to copy a buffer over. |
| 08:21:35 | <tomsmeding> | but that brings other downsides |
| 08:21:43 | <dminuoso> | Yeah |
| 08:21:59 | <Franciman> | maybe with linear types one day |
| 08:22:08 | <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. |
| 08:22:11 | <tomsmeding> | hmmm, well linear types are here |
| 08:22:30 | → | razetime joins (~quassel@117.193.3.56) |
| 08:22:44 | <tomsmeding> | dminuoso: prototype use case: csv parser |
| 08:23:04 | → | fserucas joins (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) |
| 08:23:05 | <tomsmeding> | tried to write a csv parser in parsec, worked but used GOBS of memory and was slow |
| 08:24:09 | <dminuoso> | tomsmeding: Im almost tempted to say, do it the other way around. |
| 08:24:16 | × | Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 08:24:45 | <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 |
| 08:26:15 | <tomsmeding> | hmm, but I'd like my csv to be an array of arrays |
| 08:26:21 | <dminuoso> | So? |
| 08:26:25 | <tomsmeding> | though I guess having an intermediate list for the rows is less bad |
| 08:26:38 | → | pavonia joins (~user@user/siracusa) |
| 08:26:46 | <tomsmeding> | dminuoso: if I only invoke flatparse for the cell values, I'm not getting much use out of flatparse :p |
| 08:27:06 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 08:27:08 | <tomsmeding> | which is a valid conclusion, albeit a somewhat unsatisfying one |
| 08:27:09 | <dminuoso> | That depends on whether the cell values require actual parsing or not. |
| 08:27:18 | <tomsmeding> | true |
| 08:27:30 | <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 |
| 08:28:02 | <dminuoso> | For a while I longed for an IOful Parser too |
| 08:28:02 | <tomsmeding> | well there are quotes in csv sometimes, so those need to be parsed |
| 08:28:07 | <tomsmeding> | but apart from that, not much |
| 08:29:00 | <dminuoso> | I mean ultimately its not much work to put that in, but it will prevent a lot of cute optimizations |
| 08:29:16 | <dminuoso> | Since if we pass a State# RealWorld token around, it can no longer freely reorder things as it pleases |
| 08:29:28 | <dminuoso> | (But I guess the reordering is already hard anyway) |
| 08:29:39 | <tomsmeding> | yeah allowing arbitrary IO doesn't feel like the correct solution either |
| 08:29:40 | <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#. |
| 08:29:51 | <dminuoso> | ExistentialDread: accursedUnutterablePerformIO? |
| 08:29:52 | <tomsmeding> | accursedUnutterablePerformIO? |
| 08:29:53 | <tomsmeding> | lol |
| 08:30:06 | <dminuoso> | It's not quite worse than unsafeCoerce# though |
| 08:30:13 | <tomsmeding> | it's in bytestring, if you want to find it |
| 08:30:29 | <dminuoso> | It's just more evil in that it can give the appearance of working but producing a lot of indirect problems |
| 08:30:31 | <tomsmeding> | the # makes it scarier |
| 08:30:40 | <dminuoso> | whereas misuse of unsafeCoerce# tends to outright crash your program |
| 08:31:00 | <tomsmeding> | crash >>>>>> spurious failures |
| 08:31:30 | <ExistentialDread> | dminuoso: Yes! That was it! But yes, only the description is worse/funnier. :) |
| 08:32:11 | <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" |
| 08:32:19 | <ExistentialDread> | dminuoso: Best served with a delicious side of mkTrCon? :D |
| 08:32:20 | <dminuoso> | That is the simplifier will do that. |
| 08:32:52 | <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! |
| 08:33:20 | <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. |
| 08:34:14 | <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 |
| 08:35:53 | → | `2jt joins (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 08:36:10 | → | cfricke joins (~cfricke@user/cfricke) |
| 08:36:22 | <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 |
| 08:36:36 | <dminuoso> | both of which are reasons that I wanted this in the first palce. |
| 08:36:53 | <dminuoso> | Being able to just peek and poke buffers during a parser would be superb. |
| 08:37:26 | <tomsmeding> | you can probably mess up the parser completely with IO though, but I guess that's not too easy to do accidentally |
| 08:37:32 | <dminuoso> | How so? |
| 08:37:47 | <dminuoso> | As long as you dont *poke* into the buffer its fine, but honestly you can do that without IO too. |
| 08:37:48 | <tomsmeding> | messing with the buffer you're parsing, for one |
| 08:37:51 | <tomsmeding> | right |
| 08:38:05 | <Franciman> | dminuoso: is ghc inliner nondeterministic? |
| 08:38:13 | <dminuoso> | Franciman: Non-deterministic in what sense? |
| 08:38:20 | <tomsmeding> | your parsing results can be nondeterministic (from the perspective of the parser), which is... questionable, if not directly harmful |
| 08:38:43 | <Franciman> | i mean you are saying, regarding the malloc example above, that sometimes things can be double freed because of the above mentioned issue |
| 08:39:02 | <dminuoso> | Franciman: double free is probably not quite realistic because we mostly use pinned memory for most thing. |
| 08:39:03 | <Franciman> | i was wondering whether you can rely on ghc to not change the status quo in future recompilations |
| 08:39:08 | <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* |
| 08:39:22 | <dminuoso> | Franciman: but two allocations being aliased together - that's really the problem in most misuses of accursedUnutterablePerformIO |
| 08:39:39 | <Franciman> | i see |
| 08:39:49 | <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 |
| 08:39:59 | <Franciman> | i see |
| 08:40:01 | <Franciman> | thanks |
| 08:40:01 | <dminuoso> | tomsmeding: I dont think that is what non-deterministic means. |
| 08:40:08 | <dminuoso> | hard-to-predict is something very different |
| 08:40:20 | <tomsmeding> | I know, I mean nondeterministic in the random sense |
| 08:40:39 | <dminuoso> | well, the ghc simplifier does not act randomly |
| 08:40:43 | <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 |
| 08:40:49 | <dminuoso> | It will deterministically produce the same results on the same inputs |
| 08:41:28 | <dminuoso> | tomsmeding: Im not sure any useful knowledge can be obtained from that assumption. |
| 08:41:37 | <dminuoso> | Fairly sure that "hard-to-predict" is the better mind model |
| 08:42:03 | <dminuoso> | non-deterministic algorithms have a very specific meaning |
| 08:42:07 | <dminuoso> | And it's not that |
| 08:42:19 | <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 |
| 08:42:44 | <tomsmeding> | but perhaps you're right |
| 08:43:32 | <dminuoso> | Nevertheless you are right, that code changes can have non-local effects |
| 08:43:34 | <tomsmeding> | perhaps: "it is deterministic, but hard to predict, and furthermore dependent on more inputs than you're thinking of" |
| 08:43:47 | <dminuoso> | And that non-locality is what you seem to be hinting at |
| 08:43:50 | <tomsmeding> | yeah |
| 08:44:01 | <tomsmeding> | perhaps not in the most productive wording |
| 08:44:17 | <dminuoso> | If you want cute puns, perhaps spooky action might be nice? |
| 08:44:25 | <tomsmeding> | oh yeah |
| 08:44:36 | → | coot joins (~coot@213.134.171.3) |
| 08:46:13 | <dminuoso> | tomsmeding: Look at this by the way: https://gist.github.com/dminuoso/148ba87e77894d5fcacd6c164976aaee |
| 08:46:30 | <dminuoso> | I think flatparse helped me appreciate the simplicity of pointers |
| 08:46:46 | <dminuoso> | For too long I thought `binary` was a good thing. |
| 08:47:46 | <dminuoso> | It turned out, for my protocol, writing to a buffer from the end towards the start _greatly_ simplifies the encoding style. |
| 08:48:01 | <dminuoso> | And I didnt really like repeatedly running runGet, and then copying buffers over |
| 08:48:24 | <dminuoso> | `Data.ByteString.Builder.Prim` is a wonderful module |
| 08:48:34 | <dminuoso> | My favourite module of the month |
| 08:48:47 | → | tabaqui joins (~root@85.106.195.55) |
| 08:48:49 | × | tabaqui quits (~root@85.106.195.55) (Client Quit) |
| 08:48:59 | × | shriekingnoise quits (~shrieking@186.137.167.202) (Quit: Quit) |
| 08:49:13 | → | cafkafk joins (~cafkafk@fsf/member/cafkafk) |
| 08:49:26 | <tomsmeding> | dminuoso: looks like C |
| 08:49:28 | <tomsmeding> | ;) |
| 08:49:37 | → | tabaqui joins (~root@85.106.195.55) |
| 08:49:37 | × | tabaqui quits (~root@85.106.195.55) (Client Quit) |
| 08:49:37 | <dminuoso> | Yes, nothing wrong with that. |
| 08:50:02 | <dminuoso> | Haskell is a better C. |
| 08:50:12 | <tomsmeding> | functional core, imperative shell, with contained, abstracted imperative modules |
| 08:50:26 | <tomsmeding> | but cool |
| 08:50:28 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 08:50:37 | <tomsmeding> | I find the untypedness of Ptr a bit queasy |
| 08:50:43 | <tomsmeding> | but it works |
| 08:50:44 | <dminuoso> | How is it untyped? |
| 08:50:46 | <dminuoso> | Its very typed. |
| 08:50:53 | <dminuoso> | data Ptr a |
| 08:50:56 | <tomsmeding> | :t plusPtr |
| 08:50:58 | <lambdabot> | error: Variable not in scope: plusPtr |
| 08:51:02 | <tomsmeding> | :t Foreign.Ptr.plusPtr |
| 08:51:03 | <lambdabot> | GHC.Ptr.Ptr a -> Int -> GHC.Ptr.Ptr b |
| 08:51:07 | <dminuoso> | Oh, that's strange |
| 08:51:08 | <tomsmeding> | how is this typed |
| 08:51:19 | × | libertyprime quits (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds) |
| 08:51:21 | <tomsmeding> | also minusPtr, but plusPtr is the worst one |
| 08:51:26 | <dminuoso> | But for what its worth, you can very trivially make a type safe copy of this |
| 08:51:31 | <tomsmeding> | yeah |
| 08:51:32 | × | mmhat quits (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 08:51:35 | <dminuoso> | minusPtr is horribly misnamed. |
| 08:51:54 | <dminuoso> | A few days ago I kept not understanding some type errors since I expected `minusPtr :: Ptr a -> Int -> Ptr b` |
| 08:52:01 | <tomsmeding> | heh |
| 08:52:35 | <tomsmeding> | well in C you have both, ptr-int=ptr and ptr-ptr=int |
| 08:52:49 | → | acidjnk joins (~acidjnk@p200300d6e7137a17b1807064f1abc0ef.dip0.t-ipconnect.de) |
| 08:52:57 | <pavonia> | :t Foreign.Ptr.minusPtr |
| 08:52:58 | <lambdabot> | GHC.Ptr.Ptr a -> GHC.Ptr.Ptr b -> Int |
| 08:53:29 | × | econo quits (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 08:53:31 | → | tabaqui joins (~root@85.106.195.55) |
| 08:53:33 | × | tabaqui quits (~root@85.106.195.55) (Client Quit) |
| 08:53:33 | <dminuoso> | tomsmeding: sure, but then we should have `reallyUnsafePlusPtr :: Ptr a -> Ptr b -> Int` |
| 08:53:44 | <tomsmeding> | lol |
| 08:53:46 | × | ExistentialDread quits (~TheCreato@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de) (Quit: Client closed) |
| 08:53:47 | <tomsmeding> | please no |
| 08:53:51 | <tomsmeding> | that operation makes no semantic sense |
| 08:53:55 | <dminuoso> | Why not? |
| 08:53:58 | <dminuoso> | C has it too! |
| 08:54:11 | <dminuoso> | (Yes yes, you cant have `int` there but ptr_size_t_something_something |
| 08:54:22 | → | tabaqui joins (~root@85.106.195.55) |
| 08:54:23 | <dminuoso> | One of those awefully named types. |
| 08:54:36 | <tomsmeding> | wasn't it monochrom that shared this math concept page where you have a difference between points and vectors between them |
| 08:54:38 | <tomsmeding> | ptrdiff_t |
| 08:54:43 | × | tabaqui quits (~root@85.106.195.55) (Client Quit) |
| 08:54:50 | → | mmhat joins (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) |
| 08:55:18 | → | kuribas joins (~user@ptr-17d51epp9boz5wcvhgl.18120a2.ip6.access.telenet.be) |
| 08:55:49 | <dminuoso> | Speaking of reallyUnsafe, I love the name of this thing: |
| 08:55:51 | <dminuoso> | reallyUnsafePtrEquality :: a -> a -> Int# |
| 08:55:56 | <tomsmeding> | oh no it was ski https://math.ucr.edu/home/baez/torsors.html |
| 08:56:24 | <dminuoso> | tomsmeding: Will you be attending NL FP day? |
| 08:56:26 | <dminuoso> | You should come |
| 08:56:30 | <tomsmeding> | will you? |
| 08:56:34 | <tomsmeding> | I think so |
| 08:56:37 | <dminuoso> | Yes, I shall |
| 08:56:38 | → | zeenk joins (~zeenk@2a02:2f04:a208:3600::7fe) |
| 08:56:49 | → | libertyprime joins (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) |
| 08:56:58 | → | tabaqui joins (~root@85.106.195.55) |
| 08:56:59 | <dminuoso> | Will probably make turn it into a combined FP day + followed by family vacation in Amsterdam |
| 08:57:17 | → | nschoe joins (~q@2a01:e0a:8e:a190:932f:d0ab:eeaa:3346) |
| 08:58:28 | × | tabaqui quits (~root@85.106.195.55) (Client Quit) |
| 08:58:41 | × | rembo10 quits (~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 08:59:01 | <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 |
| 08:59:13 | <dminuoso> | That finally helped me understand a lot about ForeignPtr |
| 08:59:33 | <tomsmeding> | dminuoso: registered |
| 08:59:39 | <dminuoso> | data ForeignPtrContents = PlainForeignPtr !(IORef Finalizers) | FinalPtr | MallocPtr (MutableByteArray# RealWorld) !(IORef Finalizers) | PlainPtr (MutableByteArray# RealWorld) |
| 09:00:00 | <dminuoso> | So its those MutableByteArray# that keep them alive (obviously only if they are created with MallocPtr or PlainPtr |
| 09:00:14 | <dminuoso> | But thats fine, since in case of PlainForeignPtr, FinalPtr it is not the GCs job to clean them up |
| 09:00:30 | <dminuoso> | tomsmeding: nice, see you there then |
| 09:00:37 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 09:00:52 | → | rembo10 joins (~rembo10@main.remulis.com) |
| 09:00:58 | → | tabaqui joins (~root@85.106.195.55) |
| 09:01:13 | → | ExistentialDread joins (~Existenti@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de) |
| 09:01:18 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 09:02:20 | <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 |
| 09:02:21 | <lambdabot> | 48 |
| 09:02:47 | ExistentialDread | ponders if this already exists… |
| 09:03:31 | <dminuoso> | :i ($) |
| 09:03:33 | <dminuoso> | % :i ($) |
| 09:03:33 | <yahb2> | ($) :: (a -> b) -> a -> b -- Defined in ‘GHC.Base’ ; infixr 0 $ |
| 09:03:36 | <dminuoso> | This you mean? |
| 09:03:58 | <dminuoso> | ExistentialDread: Noet that ($) has some additional tricks to it that GHC hides from you (notably it will work with runST) |
| 09:04:12 | <dminuoso> | Because in reality: ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b infixr 0 |
| 09:04:29 | <ExistentialDread> | dminuoso: not its distinct difference from ($), in that example $ 3+3 $ 2+2 $ 1+1 does not work |
| 09:04:47 | <dminuoso> | What do you mean? |
| 09:05:17 | <ExistentialDread> | > let { example a b c = a * b * c } in example $ 3+3 $ 2+2 $ 1+1 |
| 09:05:19 | <lambdabot> | <Integer -> Integer -> Integer> |
| 09:05:21 | <dminuoso> | Oh |
| 09:06:05 | <dminuoso> | ExistentialDread: Yes, its been long known that ($) has the wrong fixity. |
| 09:06:23 | <dminuoso> | But thats a hole we will not climb out ever again. |
| 09:07:06 | <ExistentialDread> | dminuoso: Wait, it doesn’t have infixr 0? |
| 09:07:28 | <dminuoso> | ExistentialDread: The only difference between ($) and (¤) is that your has infixl and ($) has infixr |
| 09:07:40 | <dminuoso> | (well and that ($) is levity polymorphic, but you can easily fix that for your version) |
| 09:07:40 | <ExistentialDread> | dminuoso: Custom Preludes might beg do differ? :D |
| 09:07:47 | <dminuoso> | ExistentialDread: what do you mean? |
| 09:08:16 | <dminuoso> | Well yes, you can provide an alternate Prelude with your own ($) |
| 09:08:20 | <ExistentialDread> | dminuoso: Well I can make my own Prelude, with ($) defined like (¤), and blackjack! :D |
| 09:08:43 | <dminuoso> | It just creates extra friction for outside users/contributors though |
| 09:08:50 | <dminuoso> | (which is a general problem with custom preludes) |
| 09:08:55 | <dminuoso> | But yes, you can do that. |
| 09:09:02 | <ExistentialDread> | dminuoso: What outside users/contributors? XD |
| 09:09:16 | <dminuoso> | ExistentialDread: However, ($) has that levity trick up its sleeve that you cannot easily address. |
| 09:09:27 | <dminuoso> | especially since ($) disappears in GHC |
| 09:09:32 | <ExistentialDread> | dminuoso: Levity? |
| 09:09:49 | <dminuoso> | ExistentialDread: Try yusing (¤) with runST |
| 09:10:06 | <dminuoso> | % import Control.Monad.ST |
| 09:10:06 | <yahb2> | <no output> |
| 09:10:11 | <dminuoso> | % runST ¤ pure 1 |
| 09:10:11 | <yahb2> | <interactive>:28:7: error: ; Variable not in scope: (¤) :: t0 -> f0 a1 -> t |
| 09:10:22 | <dminuoso> | % > let { (¤) :: (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1 |
| 09:10:22 | <yahb2> | <interactive>:30:1: error: parse error on input ‘>’ |
| 09:10:24 | <ExistentialDread> | dminuoso: I could define it like ($) too, and use {-# INLINE (¤) #-} too, no? |
| 09:10:55 | <ExistentialDread> | > let { (¤) :: (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1 |
| 09:10:57 | <lambdabot> | error: |
| 09:10:57 | <lambdabot> | • Couldn't match type ‘f0 a0’ with ‘forall s. ST s y’ |
| 09:10:57 | <lambdabot> | Expected type: f0 a0 -> y |
| 09:11:53 | <dminuoso> | > let { (¤) :: forall r x (y :: TYPE r). (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1 |
| 09:11:55 | <lambdabot> | error: |
| 09:11:55 | <lambdabot> | Not in scope: type constructor or class ‘TYPE’ |
| 09:11:58 | <dminuoso> | Mmm |
| 09:12:03 | <dminuoso> | Why doesnt GHCi parse this? |
| 09:12:07 | <dminuoso> | % let { (¤) :: forall r x (y :: TYPE r). (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1 |
| 09:12:07 | <yahb2> | <interactive>:32:31: error: ; Not in scope: type constructor or class ‘TYPE’ |
| 09:12:12 | <dminuoso> | Ah |
| 09:12:22 | <dminuoso> | % import GHC.Exts (TYPE) |
| 09:12:22 | <yahb2> | <no output> |
| 09:12:24 | <dminuoso> | % let { (¤) :: forall r x (y :: TYPE r). (x -> y) -> x -> y; x ¤ y = x y; infixl 0 ¤; } in runST ¤ pure 1 |
| 09:12:24 | <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... |
| 09:12:37 | <dminuoso> | Note however: |
| 09:12:40 | <dminuoso> | $ runST $ pure 1 |
| 09:12:42 | <dminuoso> | % runST $ pure 1 |
| 09:12:42 | <yahb2> | 1 |
| 09:13:37 | <dminuoso> | ExistentialDread: If memory serves right, there exists a special hack in GHC to erase ($) completely. |
| 09:13:43 | <dminuoso> | Avoiding this problem |
| 09:13:56 | <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. :) |
| 09:13:58 | <dminuoso> | And sorry, its not about levity - that was a misphrasing. |
| 09:14:03 | <dminuoso> | ExistentialDread: And no, you will want that too. |
| 09:14:08 | <dminuoso> | ExistentialDread: Thats just levity polymorphism |
| 09:14:16 | <dminuoso> | Such that it will work with things like unboxed prims |
| 09:14:53 | <dminuoso> | % import GHC.Prim |
| 09:14:53 | <yahb2> | <no output> |
| 09:15:07 | <dminuoso> | % import GHC.Word (Word(..)) |
| 09:15:07 | <yahb2> | <no output> |
| 09:15:18 | <dminuoso> | % :set -XMagicHash |
| 09:15:18 | <yahb2> | <no output> |
| 09:15:51 | <dminuoso> | % W# $ int2Word# $ 10# |
| 09:15:51 | <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... |
| 09:16:16 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 09:16:20 | × | cafkafk quits (~cafkafk@fsf/member/cafkafk) (Quit: WeeChat 3.3) |
| 09:16:24 | <dminuoso> | Ah |
| 09:16:41 | <dminuoso> | That is strange huh. |
| 09:17:06 | <dminuoso> | ExistentialDread: Anyway, the forall quantification thing is a different problem and that is unaddressable without a hack like GHC has. |
| 09:17:13 | <dminuoso> | But its only a mild problem |
| 09:17:17 | → | cafkafk joins (~cafkafk@fsf/member/cafkafk) |
| 09:17:41 | <dminuoso> | Especially since BlockArguments largely voids the need for it |
| 09:18:31 | <dminuoso> | So you can mostly just gloss over it. |
| 09:20:09 | <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 |
| 09:20:18 | × | ExistentialDread quits (~Existenti@2a0a-a547-2a05-1-16ed-bddb-d561-780c.ipv6dyn.netcologne.de) (Quit: ExistentialDread) |
| 09:20:44 | <dminuoso> | Oh hah, no actually the trick for ($) is different! |
| 09:20:45 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 09:20:55 | <dminuoso> | GHC enables QuickLook for ($) |
| 09:20:59 | <dminuoso> | Okay now that is cute. |
| 09:21:16 | <dminuoso> | And it suggests you could just enable ImpredicativeTypes on the definition site for ¤ |
| 09:21:24 | <dminuoso> | (Or do you need it in call-sites?) |
| 09:22:21 | <dminuoso> | But it seems there a special typing rule for it, Ugh. |
| 09:22:25 | <dminuoso> | Before quick look |
| 09:25:19 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection) |
| 09:25:26 | → | chromoblob joins (~user@37.113.164.122) |
| 09:25:54 | → | ubert1 joins (~Thunderbi@178.165.184.78.wireless.dyn.drei.com) |
| 09:27:44 | × | ubert quits (~Thunderbi@77.119.222.7.wireless.dyn.drei.com) (Ping timeout: 260 seconds) |
| 09:27:44 | ubert1 | is now known as ubert |
| 09:28:29 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 09:29:27 | <tomsmeding> | call-sites I thnk |
| 09:29:56 | → | califax joins (~califax@user/califx) |
| 09:30:03 | <tomsmeding> | the quick look idea is to be cleverer in inferring the instantiation of function argument types |
| 09:30:26 | → | MajorBiscuit joins (~MajorBisc@145.94.173.65) |
| 09:30:42 | × | titibandit quits (~titibandi@xdsl-78-35-167-196.nc.de) (Remote host closed the connection) |
| 09:31:14 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 09:47:39 | → | Guest75 joins (~Guest75@178.141.177.81) |
| 09:49:19 | × | Feuermagier quits (~Feuermagi@user/feuermagier) (Read error: Connection reset by peer) |
| 09:49:32 | → | Feuermagier joins (~Feuermagi@user/feuermagier) |
| 10:02:25 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 10:04:00 | <dminuoso> | Ah yes that makes sense |
| 10:04:08 | × | Guest75 quits (~Guest75@178.141.177.81) (Ping timeout: 260 seconds) |
| 10:07:59 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 10:08:00 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 10:09:09 | × | libertyprime quits (~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds) |
| 10:10:30 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds) |
| 10:16:53 | × | poscat quits (~poscat@114.245.106.84) (Quit: Bye) |
| 10:17:08 | → | poscat joins (~poscat@2408:8206:4823:fd6f:98ab:5c38:136c:5932) |
| 10:17:57 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 10:18:00 | × | Genius123 quits (~Genius123@71.169.167.129) (Quit: Client closed) |
| 10:20:36 | → | Guest75 joins (~Guest75@178.141.177.81) |
| 10:24:52 | × | ft quits (~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving) |
| 10:25:49 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 10:26:38 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 10:30:02 | → | zarel[m] joins (~zarelitma@2001:470:69fc:105::1:fcfb) |
| 10:30:25 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 256 seconds) |
| 10:31:43 | × | `2jt quits (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 252 seconds) |
| 10:32:15 | → | mei joins (~mei@user/mei) |
| 10:33:43 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 10:38:11 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 10:39:21 | × | xff0x quits (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds) |
| 10:44:55 | × | potash quits (~foghorn@user/foghorn) (Remote host closed the connection) |
| 10:46:06 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 10:46:25 | → | potash joins (~foghorn@user/foghorn) |
| 10:46:49 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 10:57:26 | <kuribas> | finally, a haskell meeting close to me :) https://www.reddit.com/r/haskell/comments/yt5xoc/cfp_fosdem_haskell_devroom_sun_20230205_brussels/ |
| 10:57:33 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 10:57:37 | <kuribas> | would they accept talks about idris? |
| 10:57:48 | <kuribas> | 30 minutes seems very short though... |
| 10:58:10 | <dminuoso> | kuribas: Ask Athas? |
| 10:58:18 | <dminuoso> | He seems to be one of the organizers |
| 10:59:30 | <kuribas> | dminuoso: right, thanks! |
| 10:59:49 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 11:02:42 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 11:03:35 | × | Batzy quits (~quassel@user/batzy) (Quit: No Ping reply in 180 seconds.) |
| 11:03:59 | → | sammelweis joins (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 11:05:02 | → | Batzy joins (~quassel@user/batzy) |
| 11:05:51 | × | vglfr quits (~vglfr@145.224.100.100) (Read error: Connection reset by peer) |
| 11:06:01 | → | Inst joins (~Inst@2601:6c4:4081:54f0:155b:1b8c:fa18:504e) |
| 11:06:05 | <Inst> | how much would it cost |
| 11:06:15 | <Inst> | to get tvx (iirc) updated to support windows? |
| 11:06:34 | <Inst> | oh, it's vty |
| 11:08:12 | <tomsmeding> | kuribas: https://set.win.tue.nl/nl-fp-day-2023/ |
| 11:08:27 | <dminuoso> | Inst: Contact Galois Inc and find out. |
| 11:08:43 | <Inst> | Galois tbh should do it for free |
| 11:08:57 | <dminuoso> | Oh really. |
| 11:08:59 | <Inst> | the story I recall is that the Brick maintainer tried to get vty updated for Windows support |
| 11:09:06 | <Inst> | no one wanted to do it |
| 11:09:12 | <dminuoso> | The kind of expectancoes of software users is crazy. |
| 11:09:14 | <Inst> | well, I mean, I guess Galois isn't Tweag? |
| 11:09:21 | <dminuoso> | You are not entitled to free software, sorry. |
| 11:09:36 | <Inst> | so we should pay for GHCJS? |
| 11:09:49 | <dminuoso> | No Im saying, if someone does provide a product for free, great, say thank you. |
| 11:09:57 | <tomsmeding> | developer A releasing software for free does not beget you right to free software from developer B |
| 11:09:59 | <dminuoso> | But if you demand or expect something, then pay for it? |
| 11:10:18 | <tomsmeding> | you can still ask them, though :p |
| 11:10:29 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 11:10:53 | <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. |
| 11:11:22 | <dminuoso> | Or, and this happens somewhat frequently, if I need a prompt fix. |
| 11:11:34 | × | potash quits (~foghorn@user/foghorn) (Ping timeout: 260 seconds) |
| 11:12:11 | → | potash joins (~foghorn@user/foghorn) |
| 11:13:12 | × | euandreh quits (~Thunderbi@179.214.113.107) (Remote host closed the connection) |
| 11:13:30 | <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." |
| 11:13:37 | <dminuoso> | Was a fun afternoon :> |
| 11:13:37 | → | euandreh joins (~Thunderbi@179.214.113.107) |
| 11:20:10 | × | jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 240 seconds) |
| 11:20:18 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 11:21:59 | × | youziqi quits (~youziqi@103.37.140.125) (Ping timeout: 256 seconds) |
| 11:22:22 | → | beteigeuze joins (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 11:22:28 | <merijn> | kuribas: NL-FP is happening back at it's usual time in January next year |
| 11:22:49 | <merijn> | oh, tomsmeding already linked it :) |
| 11:24:16 | → | youziqi joins (~youziqi@103.37.140.125) |
| 11:24:27 | <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 |
| 11:24:51 | <merijn> | There's also the Clean addicts showing up every year :p |
| 11:28:05 | × | ygsjg quits (~quassel@189.124.224.160) (Remote host closed the connection) |
| 11:30:45 | → | xff0x joins (~xff0x@2405:6580:b080:900:3e39:3b08:3cd:f770) |
| 11:31:43 | <dminuoso> | NL-FP has only clean addicts. |
| 11:31:57 | <dminuoso> | The haskellers are just outsiders that are.. tolerated. |
| 11:32:00 | <dminuoso> | :p |
| 11:32:52 | <dminuoso> | Seriously, last time I was there, every second talk was about mTask |
| 11:32:59 | <dminuoso> | Was a bit silly :D |
| 11:34:45 | × | Raito_Bezarius quits (~Raito@wireguard/tunneler/raito-bezarius) (Quit: free()) |
| 11:35:29 | × | potash quits (~foghorn@user/foghorn) (Read error: Connection reset by peer) |
| 11:36:07 | → | potash joins (~foghorn@user/foghorn) |
| 11:38:26 | × | califax quits (~califax@user/califx) (Ping timeout: 255 seconds) |
| 11:40:24 | × | razetime quits (~quassel@117.193.3.56) (Ping timeout: 268 seconds) |
| 11:42:17 | → | califax joins (~califax@user/califx) |
| 11:50:04 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 11:55:34 | <Inst> | by the way, does this count as a bug? |
| 11:55:49 | <Inst> | I'm doing an accum parameter sum on a list of size 100,000,000 |
| 11:56:10 | <Inst> | a direct call on the prelude sum is about 90% slower than the accum parameter sum |
| 11:56:32 | <dminuoso> | Can you share the respective code snippets? |
| 11:58:49 | × | youziqi quits (~youziqi@103.37.140.125) (Ping timeout: 256 seconds) |
| 12:00:25 | <Inst> | https://paste.tomsmeding.com/yDDLPuhC |
| 12:00:50 | <Inst> | https://paste.tomsmeding.com/JkvKMc30 |
| 12:00:54 | <[Leary]> | Your `base` is probably old. iirc sum/product only switched to strict folds somewhat recently. |
| 12:01:01 | <Inst> | on 9.2.4 |
| 12:01:15 | → | chele joins (~chele@user/chele) |
| 12:01:17 | <dminuoso> | Inst: How did you run the code? |
| 12:01:33 | <Franciman> | Inst: version 4.17.0 of base? |
| 12:01:35 | <Inst> | cabal file build |
| 12:01:41 | <Franciman> | 4.17.0.0 |
| 12:01:41 | <Inst> | should be 4.17.0 of base, let me retry and force that |
| 12:01:55 | → | youziqi joins (~youziqi@103.37.140.93) |
| 12:02:20 | <dminuoso> | Also, please share the full code |
| 12:02:30 | <dminuoso> | I dont see the imports, so I dont know whether you use Data.Foldable or Data.List |
| 12:02:50 | <dminuoso> | (They export different `sum` implementations) |
| 12:03:13 | <Franciman> | i think they use prelude ?! |
| 12:03:41 | <dminuoso> | Maybe, but the code is too sketchy - I dont want to assume here. |
| 12:03:45 | <Inst> | my sytem i think is broken |
| 12:04:02 | <dminuoso> | I think this is already in "make a reproducer repo" territory |
| 12:04:03 | <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 |
| 12:04:36 | <Inst> | it's stuck on 4.16.3.0 |
| 12:04:43 | <dminuoso> | Franciman: Ohh I was thinking of GHC.List. |
| 12:04:46 | <dminuoso> | Thanks good catch |
| 12:06:12 | × | ridcully quits (~ridcully@pd951fa32.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 12:06:28 | × | Techcable quits (~Techcable@user/Techcable) (Read error: Connection reset by peer) |
| 12:06:47 | → | infinity0 joins (~infinity0@pwned.gg) |
| 12:07:51 | <Inst> | i can't seem to get my cabal to support 4.17.0.0 |
| 12:07:51 | → | Achylles joins (~Achylles_@2804:431:d724:7309:7501:feac:f03e:5f7f) |
| 12:07:55 | <Inst> | that requires 9.4, doesn't it? |
| 12:08:35 | <[Leary]> | 4.16.3 should be new enough |
| 12:09:31 | <Inst> | i can try to put it to |
| 12:09:33 | <Inst> | main :: IO () |
| 12:09:33 | <Inst> | main = defaultMain [bgroup "MySum" [ bench "[1..100_000_000]" $ nf accumSum ([1..100000000] :: [Int])] |
| 12:09:34 | <Inst> | ,bgroup "PrSum" [ bench "[1..100_000_000]" $ nf (foldl' (+) 0) ([1..100000000] :: [Int])]] |
| 12:10:28 | → | ridcully joins (~ridcully@p57b52925.dip0.t-ipconnect.de) |
| 12:10:50 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 12:11:13 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 12:11:56 | <Inst> | still getting the same result |
| 12:11:59 | <Inst> | is something wrong with GHC? |
| 12:12:12 | <Inst> | like, foldl' / foldr etc are idiomatic, accum parameter is a pseudo-imperative performance hack |
| 12:15:30 | × | nschoe quits (~q@2a01:e0a:8e:a190:932f:d0ab:eeaa:3346) (Ping timeout: 260 seconds) |
| 12:16:56 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 12:17:09 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 12:18:05 | → | Techcable joins (~Techcable@user/Techcable) |
| 12:18:11 | × | Techcable quits (~Techcable@user/Techcable) (Remote host closed the connection) |
| 12:19:19 | <Inst> | via fp discord, we got the same benchmarks via eta expansion |
| 12:20:25 | → | Techcable joins (~Techcable@user/Techcable) |
| 12:21:10 | <Inst> | so foldl' isn't that badly off |
| 12:21:24 | <Inst> | whew, i was annoyed that i'd be stuck coding pseudo-imperative accum params forever |
| 12:25:01 | → | razetime joins (~quassel@117.254.34.170) |
| 12:25:16 | × | mmhat quits (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 12:26:03 | → | CiaoSen joins (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 12:27:05 | → | mmhat joins (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) |
| 12:27:37 | × | Techcable quits (~Techcable@user/Techcable) (Read error: Connection reset by peer) |
| 12:30:41 | → | InstX1 joins (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 12:31:30 | × | phma quits (~phma@host-67-44-208-73.hnremote.net) (Read error: Connection reset by peer) |
| 12:32:18 | → | phma joins (~phma@2001:5b0:215d:9748:5bc9:473d:a4cc:a159) |
| 12:33:59 | × | mmhat quits (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 12:35:26 | → | mmhat joins (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) |
| 12:35:54 | × | InstX1 quits (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 268 seconds) |
| 12:38:50 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 240 seconds) |
| 12:40:13 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 12:40:46 | <dminuoso> | Inst: Cannot reproduce. https://paste.tomsmeding.com/0o2RP5qm |
| 12:42:55 | <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 |
| 12:43:21 | → | chromoblob joins (~user@37.113.164.122) |
| 12:43:50 | <dminuoso> | The accumSum code appears to compile into the same code, Im not quite sure why we have ~20% difference between them |
| 12:45:49 | × | euandreh quits (~Thunderbi@179.214.113.107) (Quit: euandreh) |
| 12:46:10 | → | euandreh2 joins (~Thunderbi@179.214.113.107) |
| 12:47:06 | <dminuoso> | https://paste.tomsmeding.com/pWiiAgHs |
| 12:48:10 | <dminuoso> | accumSum = \ (ls_a1uG :: [Int]) -> case $wgo 0# ls_a1uG of ww_s4lx { __DEFAULT -> I# ww_s4lx } |
| 12:48:12 | euandreh2 | is now known as euandreh |
| 12:48:18 | <dminuoso> | Mmm, whats the meaning of this `{ __DEFAULT -> I# ww_s4lx }` here? |
| 12:48:53 | <dminuoso> | Or the entire element `ww_s4lx { __DEFAULT -> I# ww_s4lx }` even |
| 12:49:51 | → | marc__ joins (~marc@5.83.191.99) |
| 12:50:19 | <marc__> | Does anybody know a flutter like implementation in a functional language like Haskell offering direct hardware rendering and web support ? |
| 12:52:54 | × | ec quits (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 12:53:33 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 12:54:22 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 12:55:41 | → | Raito_Bezarius joins (~Raito@wireguard/tunneler/raito-bezarius) |
| 12:58:25 | → | fockerize joins (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 12:59:11 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 12:59:11 | × | Raito_Bezarius quits (~Raito@wireguard/tunneler/raito-bezarius) (Max SendQ exceeded) |
| 12:59:32 | <zzz> | The package location glob './vendor/*/*.cabal' does not match any files or directories. <- what does this mean? |
| 13:00:04 | × | marc__ quits (~marc@5.83.191.99) (Ping timeout: 260 seconds) |
| 13:01:52 | <zzz> | oh nvm |
| 13:01:56 | <zzz> | my mistake |
| 13:01:59 | → | marc__ joins (~marc@5.83.191.99) |
| 13:03:25 | × | beteigeuze quits (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 256 seconds) |
| 13:04:44 | × | cfricke quits (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 13:08:45 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 13:08:50 | → | nschoe joins (~q@2a01:e0a:8e:a190:a039:6fb1:ed57:342c) |
| 13:09:15 | × | chromoblob quits (~user@37.113.164.122) (Read error: Connection reset by peer) |
| 13:11:13 | → | mikoto-chan joins (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) |
| 13:12:25 | → | lyle joins (~lyle@104.246.145.85) |
| 13:12:33 | → | Techcable joins (~Techcable@user/Techcable) |
| 13:13:31 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 13:14:29 | → | chromoblob joins (~user@37.113.164.122) |
| 13:15:26 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Quit: No Ping reply in 180 seconds.) |
| 13:16:35 | → | Raito_Bezarius joins (~Raito@wireguard/tunneler/raito-bezarius) |
| 13:16:55 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 13:17:32 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 13:17:45 | × | mikoto-chan quits (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Quit: WeeChat 3.6) |
| 13:17:53 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 13:18:38 | → | sammelweis joins (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 13:18:39 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 13:21:17 | × | Raito_Bezarius quits (~Raito@wireguard/tunneler/raito-bezarius) (Max SendQ exceeded) |
| 13:21:30 | → | sh1n joins (~sh1n@186.152.126.112) |
| 13:21:32 | × | marc__ quits (~marc@5.83.191.99) (Ping timeout: 268 seconds) |
| 13:23:12 | → | marc__ joins (~marc@5.83.191.99) |
| 13:24:38 | × | ec quits (~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds) |
| 13:24:39 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 13:26:42 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 13:28:17 | → | Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 13:28:23 | → | Raito_Bezarius joins (~Raito@wireguard/tunneler/raito-bezarius) |
| 13:28:50 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 240 seconds) |
| 13:29:27 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 13:30:55 | → | jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 13:31:56 | → | noctuks joins (v2dJtUbze5@user/noctux) |
| 13:32:18 | → | chromoblob joins (~user@37.113.164.122) |
| 13:33:16 | × | CiaoSen quits (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Quit: CiaoSen) |
| 13:36:20 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 13:36:59 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 13:37:51 | → | beteigeuze joins (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 13:49:39 | × | fockerize quits (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 260 seconds) |
| 13:51:36 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 13:52:35 | → | califax joins (~califax@user/califx) |
| 13:54:08 | → | mikoto-chan joins (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) |
| 13:55:25 | → | `2jt joins (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 13:55:30 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 13:57:54 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 13:59:04 | → | slack1256 joins (~slack1256@191.125.99.216) |
| 14:02:51 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 14:03:35 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 14:04:21 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 14:05:35 | → | jero98772 joins (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 14:10:03 | → | fockerize joins (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 14:10:05 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 14:11:30 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 14:13:38 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 14:15:46 | × | nschoe quits (~q@2a01:e0a:8e:a190:a039:6fb1:ed57:342c) (Remote host closed the connection) |
| 14:15:59 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 14:16:59 | → | nschoe joins (~q@2a01:e0a:8e:a190:e046:20e5:49d3:6cb9) |
| 14:17:35 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 14:28:05 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 14:29:13 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 14:30:30 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 14:31:23 | → | InstX1 joins (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 14:33:30 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds) |
| 14:33:32 | → | ystael joins (~ystael@user/ystael) |
| 14:35:47 | × | InstX1 quits (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 14:36:19 | × | fockerize quits (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 260 seconds) |
| 14:38:12 | → | shriekingnoise joins (~shrieking@186.137.167.202) |
| 14:42:02 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 14:42:02 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 14:42:59 | → | doyougnu joins (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 14:45:13 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 14:45:27 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 14:45:27 | → | allbery_b joins (~geekosaur@xmonad/geekosaur) |
| 14:45:30 | allbery_b | is now known as geekosaur |
| 14:54:25 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 14:55:05 | × | auri quits (~auri@fsf/member/auri) (Ping timeout: 246 seconds) |
| 14:55:26 | × | sagax quits (~sagax_nb@user/sagax) (Ping timeout: 246 seconds) |
| 14:55:50 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 240 seconds) |
| 14:56:13 | → | auri joins (~auri@fsf/member/auri) |
| 14:59:08 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 14:59:50 | × | evanvarvell quits (~evanvarve@097-088-181-216.res.spectrum.com) (Quit: Leaving) |
| 15:00:09 | × | beteigeuze quits (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 15:02:55 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 15:03:44 | × | troydm quits (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 260 seconds) |
| 15:09:03 | ← | jakalx parts (~jakalx@base.jakalx.net) () |
| 15:09:06 | <slack1256> | Does levity polymorphism interact with laziness somehow? |
| 15:12:03 | × | mikoto-chan quits (~mikoto-ch@85-76-104-247-nat.elisa-mobile.fi) (Ping timeout: 256 seconds) |
| 15:12:26 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:bd85:df8c:c85c:33a7) (Quit: WeeChat 2.8) |
| 15:12:40 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 15:14:53 | <merijn> | slack1256: Define "interact"? |
| 15:14:55 | × | slack1256 quits (~slack1256@191.125.99.216) (Ping timeout: 260 seconds) |
| 15:16:14 | <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 |
| 15:16:41 | <merijn> | romes[m]: It's address equality |
| 15:16:49 | <romes[m]> | OK, thank you |
| 15:16:53 | <merijn> | romes[m]: Pretty sure the docs say that somewhere |
| 15:17:04 | <romes[m]> | :) |
| 15:17:47 | <merijn> | hmm, it doesn't |
| 15:18:04 | <merijn> | OTOH, you can infer it from the fact that it's "Eq (Ptr a)" rather than "Eq a => Eq (Ptr a)" |
| 15:21:00 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 15:22:11 | → | vglfr joins (~vglfr@145.224.100.100) |
| 15:23:29 | <merijn> | oh dear... |
| 15:23:47 | <merijn> | I had the audacity to add template-haskell as a dependency and now the compiler crashes |
| 15:24:04 | <maerwald> | welcome to GHC |
| 15:24:17 | <merijn> | Something's fucky |
| 15:24:20 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 15:24:29 | <merijn> | Why is ghc 8.10 trying to dlopen ghc9.2 libs |
| 15:24:31 | × | razetime quits (~quassel@117.254.34.170) (Ping timeout: 256 seconds) |
| 15:25:08 | × | vglfr quits (~vglfr@145.224.100.100) (Client Quit) |
| 15:25:22 | → | vglfr joins (~vglfr@145.224.100.100) |
| 15:27:28 | × | vglfr quits (~vglfr@145.224.100.100) (Client Quit) |
| 15:27:42 | → | vglfr joins (~vglfr@145.224.100.100) |
| 15:28:45 | × | vglfr quits (~vglfr@145.224.100.100) (Client Quit) |
| 15:28:46 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 15:29:04 | → | vglfr joins (~vglfr@145.224.100.100) |
| 15:33:49 | <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) |
| 15:35:07 | <maerwald> | TH with boot files is also fun |
| 15:35:10 | <maerwald> | lol |
| 15:35:18 | <maerwald> | there are dark corners you don't wanna know |
| 15:35:24 | <merijn> | I'm not smart enough for boot files, somehow they never work when I try to use them |
| 15:36:14 | → | razetime joins (~quassel@117.254.34.209) |
| 15:36:50 | → | Guest7869 joins (~coco@85.195.206.136) |
| 15:38:22 | → | beteigeuze joins (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 15:39:19 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 15:51:21 | × | Guest7869 quits (~coco@85.195.206.136) (Quit: WeeChat 3.5) |
| 15:51:49 | → | c0c0 joins (~coco@85.195.206.136) |
| 15:55:57 | × | Achylles quits (~Achylles_@2804:431:d724:7309:7501:feac:f03e:5f7f) (Remote host closed the connection) |
| 15:58:05 | × | jludwig quits (~justin@li657-110.members.linode.com) (Quit: ZNC - https://znc.in) |
| 15:59:06 | → | jludwig joins (~justin@li657-110.members.linode.com) |
| 16:02:04 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 16:02:22 | → | cfricke joins (~cfricke@user/cfricke) |
| 16:06:25 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 16:08:16 | × | kenran quits (~user@user/kenran) (Remote host closed the connection) |
| 16:13:04 | × | mei quits (~mei@user/mei) (Remote host closed the connection) |
| 16:13:45 | → | mei joins (~mei@user/mei) |
| 16:19:49 | <tomsmeding> | maerwald: the recommended (and default) ghc version in ghcup is not supported by the default hls version |
| 16:20:08 | <tomsmeding> | I can see how it happens but it's a kinda unfortunate situation for newcomers :p |
| 16:22:36 | <merijn> | What's the recommended version? |
| 16:28:34 | × | cheater quits (~Username@user/cheater) (Remote host closed the connection) |
| 16:34:45 | → | moonsheep joins (~user@user/moonsheep) |
| 16:34:55 | → | cheater joins (~Username@user/cheater) |
| 16:34:55 | <moonsheep> | does this look alright? https://github.com/haskell/network/compare/master...jlagarespo:network:master |
| 16:35:13 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 16:35:21 | → | ub joins (~Thunderbi@178.165.184.78.wireless.dyn.drei.com) |
| 16:35:49 | <tomsmeding> | merijn: 9.2.5 |
| 16:36:20 | <moonsheep> | shapr: not sure how to respond through lambdabot, but this may be of interest to you |
| 16:36:43 | <moonsheep> | is there a way to locate the context of a lambdabot message in the logs? |
| 16:37:05 | <shapr> | hi moonsheep ! |
| 16:37:26 | <shapr> | thanks for the link |
| 16:37:38 | <merijn> | moonsheep: It looks sensible enough at first glance |
| 16:37:54 | <moonsheep> | there's many things that smell of bad code to me, but it's a codebase I'm very unfamiliar with |
| 16:38:09 | <moonsheep> | so I tried to go with the general vibe of it if that makes sense |
| 16:38:11 | <merijn> | although from a "clean diff" perspective the gratuitous whitespace changes are a bit yikes :) |
| 16:38:21 | <moonsheep> | oh yeah I gotta sort that out |
| 16:38:30 | <moonsheep> | I'm not used to that whitespacing style |
| 16:38:35 | × | razetime quits (~quassel@117.254.34.209) (Ping timeout: 260 seconds) |
| 16:38:45 | <geekosaur> | moonsheep, sadly the logs are not searchable (well, it offsers searching but that does nothing) |
| 16:39:06 | <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 |
| 16:39:11 | <moonsheep> | geekosaur: ah alright |
| 16:39:40 | <merijn> | moonsheep: I'm to lazy/busy to really review it in depth, but nothing jumps out as wildly wrong |
| 16:39:47 | <moonsheep> | good to know |
| 16:39:55 | <merijn> | moonsheep: Historical artifact perhaps (the class thing) |
| 16:39:58 | → | razetime joins (~quassel@117.193.4.187) |
| 16:40:06 | <moonsheep> | yeah most likely |
| 16:40:22 | <moonsheep> | still I think it would be cleaner to do everything through the class and with separate types for different address families |
| 16:40:32 | <moonsheep> | this way you could ensure type-safe addresses |
| 16:40:42 | <moonsheep> | it would perhaps complicate mixing different addresses a bit |
| 16:40:48 | <moonsheep> | which explains the SockAddr type |
| 16:41:52 | <geekosaur> | my guess is so it could be extended to support OSI, which has a rather different view of things |
| 16:41:58 | <geekosaur> | but OSI is pretty much dead |
| 16:42:02 | <merijn> | moonsheep: The class approach always seems like a great idea |
| 16:42:13 | <merijn> | moonsheep: But in my experience often isn't, especially here :p |
| 16:42:26 | <moonsheep> | hmm, alright then |
| 16:42:52 | <merijn> | I tried that approach once while implementing ZeroMQ in Haskell, it was a PITA to deal with :p |
| 16:42:54 | <moonsheep> | the most annoying bit is peekAddress, which I have a feeling is 50% of the reason for doing everything with a single type |
| 16:43:02 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 16:43:07 | <moonsheep> | merijn: well it's hard to argue with experience :p |
| 16:44:36 | → | chromoblob joins (~user@37.113.164.122) |
| 16:45:32 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:c1d7:1626:4211:cf1c) |
| 16:46:18 | <moonsheep> | merijn: oh I hadn't noticed the whitespace changes in HsNet.h |
| 16:46:26 | <moonsheep> | yeah I have my editor configured to automatically do that |
| 16:46:30 | <moonsheep> | I'll fix that in a sce |
| 16:46:47 | <moonsheep> | by the way, I added the stack lock file |
| 16:46:53 | <moonsheep> | I heard it's good practice in order to ensure reproducible builds |
| 16:46:55 | <moonsheep> | is that so? |
| 16:47:31 | <merijn> | That depends on whether you use stack at all? :p |
| 16:47:38 | <moonsheep> | network does |
| 16:48:50 | <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 |
| 16:49:49 | <moonsheep> | do I count as part of "other people"? |
| 16:49:54 | <moonsheep> | I certainly use stack |
| 16:49:58 | <moonsheep> | (and love it) |
| 16:49:58 | × | razetime quits (~quassel@117.193.4.187) (Ping timeout: 268 seconds) |
| 16:50:07 | → | razetime joins (~quassel@117.193.7.92) |
| 16:50:15 | <merijn> | moonsheep: I meant as in "I don't think the core maintainers use stack themselves" (although I might be wrong) |
| 16:50:21 | <moonsheep> | ah |
| 16:50:34 | <moonsheep> | well either way it doesn't hurt to include a lock file, now does it? |
| 16:50:49 | <merijn> | I have no idea, because I don't use stack either :p |
| 16:51:41 | <moonsheep> | well I'm no expert but I'm fairly sure not |
| 16:51:58 | <moonsheep> | can someone more knowledgable enlighten us? |
| 16:52:24 | × | ajb quits (~ajb@mimas.whatbox.ca) (Quit: bye) |
| 16:52:54 | × | Guest75 quits (~Guest75@178.141.177.81) (Quit: Client closed) |
| 16:54:43 | <moonsheep> | alright, the diff should update automatically |
| 16:55:06 | <moonsheep> | anyway, my only remaining concern is whether any ifdefs are required around stuff (like the inclusion of if_packet.h) |
| 16:55:29 | <moonsheep> | do I have to check for AF_PACKET support like I have to for unix sockets? |
| 16:57:32 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 16:57:50 | <geekosaur> | it's probably a good idea for portability |
| 16:59:55 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 260 seconds) |
| 17:00:00 | <moonsheep> | how do I do that thoguh? |
| 17:00:25 | <moonsheep> | one of the #ifdef HAVE_x_H? |
| 17:00:30 | <moonsheep> | where are those defined? |
| 17:00:41 | <moonsheep> | there's no include from linux/ either |
| 17:00:46 | <moonsheep> | so I have no reference |
| 17:00:51 | × | beteigeuze quits (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Remote host closed the connection) |
| 17:00:57 | <moonsheep> | how can I easily contact the maintainers? |
| 17:01:05 | <geekosaur> | those usually come from a configure script. and most things don't include stuff from linux/ directly |
| 17:01:07 | <moonsheep> | if someone knows it must be them |
| 17:01:21 | <moonsheep> | geekosaur: well I'm pretty sure I need it for the struct |
| 17:01:26 | <geekosaur> | rather something in /usr/include would #include something from either linux/ or asm/ |
| 17:02:36 | <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>) |
| 17:02:56 | × | MajorBiscuit quits (~MajorBisc@145.94.173.65) (Ping timeout: 268 seconds) |
| 17:03:04 | <moonsheep> | according to https://man7.org/linux/man-pages/man7/packet.7.html I have to include three headers |
| 17:03:33 | → | KaitoDaumoto joins (~asdf@user/kaitodaumoto) |
| 17:04:08 | → | beteigeuze joins (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 17:04:51 | → | dfee joins (~dfee@162-227-164-101.lightspeed.sntcca.sbcglobal.net) |
| 17:09:10 | × | Sauvin quits (~sauvin@user/Sauvin) (Ping timeout: 240 seconds) |
| 17:10:00 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 17:10:59 | → | stef204 joins (~stef204@user/stef204) |
| 17:12:11 | × | xacktm quits (~xacktm@user/xacktm) (Ping timeout: 256 seconds) |
| 17:12:17 | → | thyriaen joins (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 17:12:35 | × | thyriaen quits (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Remote host closed the connection) |
| 17:12:44 | → | ajb joins (~ajb@mimas.whatbox.ca) |
| 17:13:20 | × | polo quits (sid532813@user/polo) () |
| 17:14:22 | → | thyriaen joins (~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) |
| 17:14:32 | → | Tuplanolla joins (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
| 17:15:38 | → | Sauvin joins (~sauvin@user/Sauvin) |
| 17:17:34 | → | econo joins (uid147250@user/econo) |
| 17:18:49 | → | werneta joins (~werneta@137.78.30.207) |
| 17:21:10 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 240 seconds) |
| 17:22:32 | → | bontaq joins (~user@ool-45779fe5.dyn.optonline.net) |
| 17:23:16 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 17:24:06 | → | xacktm joins (~xacktm@user/xacktm) |
| 17:25:04 | × | mbuf quits (~Shakthi@49.204.118.25) (Quit: Leaving) |
| 17:25:40 | × | doyougnu quits (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Remote host closed the connection) |
| 17:26:10 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 17:28:03 | × | machinedgod quits (~machinedg@clnet-p10-126.ikbnet.co.at) (Ping timeout: 256 seconds) |
| 17:35:58 | × | cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.7.1) |
| 17:36:38 | × | cafkafk quits (~cafkafk@fsf/member/cafkafk) (Ping timeout: 255 seconds) |
| 17:36:39 | × | moonsheep quits (~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 17:38:21 | × | thyriaen quits (~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) (Remote host closed the connection) |
| 17:39:21 | → | jmdaemon joins (~jmdaemon@user/jmdaemon) |
| 17:40:14 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 17:40:23 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 17:40:24 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:c1d7:1626:4211:cf1c) (Quit: WeeChat 2.8) |
| 17:41:59 | → | Guest70 joins (~Guest70@162.253.129.2) |
| 17:42:19 | <Guest70> | hi |
| 17:42:28 | × | coldtom quits (~coldtom@coldrick.cc) (Quit: Well, that's got rid of me) |
| 17:42:49 | → | coldtom joins (~coldtom@coldrick.cc) |
| 17:43:01 | × | Guest70 quits (~Guest70@162.253.129.2) (Client Quit) |
| 17:44:47 | <geekosaur> | missed 'em |
| 17:44:51 | <geekosaur> | oh well |
| 17:44:55 | <segfaultfizzbuzz> | lol i wanted to say hi to Guest70 |
| 17:45:04 | <segfaultfizzbuzz> | you never know they might be the next bill gates |
| 17:47:10 | <segfaultfizzbuzz> | is "as lazy as possible but never slower/higher latency than strict eval" a meaningful concept? |
| 17:47:51 | <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? |
| 17:48:11 | → | chromoblob joins (~user@37.113.164.122) |
| 17:48:47 | <[exa]> | segfaultfizzbuzz: "as lazy as possible" is basically leaving the computer with guessing which stuff will be evaluated or not |
| 17:49:14 | <[exa]> | segfaultfizzbuzz: which is a pretty hard problem even in a very optimistic case |
| 17:49:44 | <segfaultfizzbuzz> | [exa]: kinda except you can observe program execution and make a statistical model... |
| 17:50:23 | <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 |
| 17:52:29 | × | kuribas quits (~user@ptr-17d51epp9boz5wcvhgl.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 17:54:19 | → | tzh_ joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 17:54:40 | × | coldtom quits (~coldtom@coldrick.cc) (Quit: Well, that's got rid of me) |
| 17:54:56 | → | coldtom joins (~coldtom@coldrick.cc) |
| 17:56:23 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Ping timeout: 260 seconds) |
| 17:57:58 | × | coldtom quits (~coldtom@coldrick.cc) (Client Quit) |
| 17:58:14 | → | coldtom joins (~coldtom@coldrick.cc) |
| 18:05:01 | × | nschoe quits (~q@2a01:e0a:8e:a190:e046:20e5:49d3:6cb9) (Remote host closed the connection) |
| 18:05:14 | → | dsrt^ joins (~dsrt@76.145.185.103) |
| 18:06:13 | → | nschoe joins (~q@2a01:e0a:8e:a190:14fb:d85b:4ae9:96c6) |
| 18:08:59 | × | razetime quits (~quassel@117.193.7.92) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 18:09:56 | → | troydm joins (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 18:10:05 | <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 |
| 18:11:02 | <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" |
| 18:11:52 | <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 |
| 18:11:58 | <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 |
| 18:12:24 | <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 |
| 18:12:40 | × | mixfix41 quits (~sdenynine@user/mixfix41) (Read error: Connection reset by peer) |
| 18:13:36 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 18:13:48 | <davean> | I can make SOME programmers lower latency always, in either direction |
| 18:14:02 | <davean> | Given some input |
| 18:14:09 | <davean> | This is basicly queueing theory |
| 18:14:20 | <segfaultfizzbuzz> | i mean, you can always automatically tack on a timeout for a lazy function call |
| 18:14:58 | <segfaultfizzbuzz> | so you can always have a deterministic bound for "maximum latency to TIMEOUT error result" |
| 18:15:02 | <davean> | Taht doesn't help you - evaluating the timeout is latency |
| 18:15:22 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 18:16:07 | <segfaultfizzbuzz> | ...maybe the ISA needs to support latency bounds? |
| 18:16:18 | <davean> | No, that doesn't help you, latency bounds *are latency* |
| 18:16:53 | <davean> | There exists a piece of hardware, it can service so many of so many types of calls per cycle |
| 18:17:10 | <davean> | when an event happens it has to process some sequence of instructions to service that event |
| 18:17:22 | → | titibandit joins (~titibandi@xdsl-78-35-167-196.nc.de) |
| 18:17:33 | <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... |
| 18:17:49 | <davean> | knowing the time isn't the problem\ |
| 18:20:21 | <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 |
| 18:20:23 | <davean> | "customers" |
| 18:20:34 | <davean> | So you can induse a higher latency |
| 18:20:39 | <davean> | *induce |
| 18:20:47 | <davean> | It can go in the other direction too |
| 18:21:05 | <segfaultfizzbuzz> | sorry i didn't understand the "clerk" -- is this a thread of execution or perhaps a core? |
| 18:21:06 | <davean> | Because you are forced to reduce all expressions to be strict, you can be forced to do more work |
| 18:21:18 | <davean> | clerk is more an instruction unit |
| 18:21:27 | <segfaultfizzbuzz> | ok so part of a core? |
| 18:21:36 | <davean> | Yes, but that doesn't really matter |
| 18:21:42 | <davean> | there is work that has to be done and things that can do it |
| 18:22:27 | × | beteigeuze quits (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 256 seconds) |
| 18:24:16 | × | nschoe quits (~q@2a01:e0a:8e:a190:14fb:d85b:4ae9:96c6) (Quit: Switching off) |
| 18:24:28 | <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 |
| 18:24:49 | <davean> | No, that doesn't help, because there are only so many clerks. |
| 18:24:53 | <davean> | They could have been doing other work |
| 18:25:12 | <davean> | Which is exactly why I started referencing queuing |
| 18:25:47 | <segfaultfizzbuzz> | this would likely be enforced by the runtime and not the program itself |
| 18:25:55 | <segfaultfizzbuzz> | are you speaking from *within* the program? |
| 18:26:11 | <davean> | I'm talking about the programs actual execution |
| 18:26:12 | <segfaultfizzbuzz> | the program itself would have some annotation which would say certain segments were latency sensitive |
| 18:26:47 | × | earthy quits (~arthurvl@2a02-a469-f5e2-1-ba27-ebff-fea0-40b0.fixed6.kpn.net) (Quit: WeeChat 2.3) |
| 18:26:53 | <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 |
| 18:27:08 | <segfaultfizzbuzz> | ok yeah i don't understand what you are saying unfortunately but thanks for trying |
| 18:27:33 | × | troydm quits (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 256 seconds) |
| 18:27:46 | <davean> | The latency of the program *is litterly its instruction queue evaluation strategy*, and the optimality of that varies. |
| 18:28:06 | <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 |
| 18:28:36 | <segfaultfizzbuzz> | hmm interesting |
| 18:28:37 | <davean> | Thats not relivent, the electroncis are cycle based. |
| 18:28:49 | <segfaultfizzbuzz> | instruction queue is serial? |
| 18:29:01 | <davean> | Almost. |
| 18:29:08 | <segfaultfizzbuzz> | like strictly a mapping from natural numbers to instructions? |
| 18:29:18 | <segfaultfizzbuzz> | uh bad choice of strictly lol |
| 18:29:31 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds) |
| 18:29:39 | × | stef204 quits (~stef204@user/stef204) (Quit: WeeChat 3.7.1) |
| 18:29:45 | <davean> | Pretty close, I mean often you get 6 wide, etc, but there are exactly a set of units that evaluate them |
| 18:29:55 | <davean> | which you might have 2 ALUs, and 1 comparator for example |
| 18:30:03 | → | earthy joins (~arthurvl@2a02-a469-f5e2-1-ba27-ebff-fea0-40b0.fixed6.kpn.net) |
| 18:30:15 | <davean> | but it is exactly fixed width and only certain instructions can fit to certain units |
| 18:30:21 | <davean> | electronics aren't magic |
| 18:31:26 | <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 |
| 18:31:36 | <segfaultfizzbuzz> | right |
| 18:31:37 | <davean> | You only have so many anti aircraft guns |
| 18:31:39 | <davean> | https://pubsonline.informs.org/doi/abs/10.1287/opre.5.5.644 |
| 18:31:47 | <davean> | I reference this to show this general problem exists very broadly |
| 18:32:05 | <davean> | There is only so much service to go around for so many customers at a time |
| 18:32:16 | <segfaultfizzbuzz> | but even with "strict" eval you can also be "swamped by bombers" |
| 18:32:50 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 18:32:56 | <davean> | Yes, you get swamped in different cases |
| 18:32:58 | <segfaultfizzbuzz> | i think i am thinking here that "intelligent eval" is the synthesis of "lazy eval" and "eager eval" |
| 18:33:03 | <davean> | which is why NEITHER has the lowest latency |
| 18:33:21 | <davean> | Given a given PATTERN of events one will win or the other |
| 18:33:29 | <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 |
| 18:33:32 | <davean> | If I can pick the pattern, I can pick which wins |
| 18:33:48 | <segfaultfizzbuzz> | right |
| 18:33:57 | <segfaultfizzbuzz> | but also most of the time a mixed process is best |
| 18:34:02 | <davean> | Which is why I said *latency* was a very strict metric |
| 18:34:26 | <davean> | Latency is one of the strictest metrics you can have |
| 18:34:28 | <segfaultfizzbuzz> | sure, input your cost function and find the strategy which produces the best cost function |
| 18:34:47 | <segfaultfizzbuzz> | energy use, probability of exceeding one second to result, et cetera |
| 18:35:27 | <davean> | "segfaultfizzbuzz is "as lazy as possible but never slower/higher latency than strict eval" a meaningful concept?" <--- so, no, its not |
| 18:35:38 | <davean> | Notably Haskell isn't lazy, its non-strict |
| 18:35:48 | <davean> | you're talking more about non-strict |
| 18:35:56 | <segfaultfizzbuzz> | ok sure |
| 18:36:13 | <davean> | And non-strict can come up with whatever you decide is best, because everything fits in it |
| 18:36:40 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 18:37:10 | <segfaultfizzbuzz> | yeah interesting hmm |
| 18:37:14 | <davean> | but to be clear, no decision procedure other than the oracle can be universally lowest latency across programs and event streams |
| 18:37:29 | <davean> | because whatever decision you make, in SOME programs, I can screw with your latency |
| 18:37:30 | → | beteigeuze joins (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) |
| 18:37:54 | <segfaultfizzbuzz> | right it becomes an ML problem and there ain't no free lunch |
| 18:37:57 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 18:38:53 | <davean> | No, no |
| 18:39:10 | <davean> | If you COULD pick the lowest latency one for any input program that *is a solution to the halting problem* |
| 18:39:14 | <davean> | we're not talking ML here |
| 18:39:21 | <davean> | we're talking fundimental mathematics |
| 18:39:23 | <segfaultfizzbuzz> | ok |
| 18:39:33 | <davean> | It *can not exist* |
| 18:40:54 | <davean> | If you can tell me the latency I know if the program halts :-p |
| 18:40:59 | <segfaultfizzbuzz> | haha |
| 18:41:28 | <segfaultfizzbuzz> | well regardless in "real world situations" it seems like it would be useful to build hybrid execution strategies |
| 18:41:33 | <davean> | We do |
| 18:41:36 | <davean> | We already have that |
| 18:41:41 | <davean> | Thats how GHC works |
| 18:41:49 | <segfaultfizzbuzz> | ghc observes the program execution? |
| 18:41:50 | × | beteigeuze quits (~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 240 seconds) |
| 18:42:03 | <davean> | No, it does compile time demand annalysis |
| 18:42:11 | <davean> | runtime would be a JIT |
| 18:42:14 | <davean> | other people do that |
| 18:43:05 | <segfaultfizzbuzz> | hm ok |
| 18:43:12 | <segfaultfizzbuzz> | thanks for the teachings, i need to run unfortunately |
| 18:43:15 | <davean> | You could ALSO JIT GHC |
| 18:43:20 | <davean> | No one has |
| 18:43:38 | <segfaultfizzbuzz> | pretty wild since it's a mature research language |
| 18:44:00 | <[exa]> | > kinda except you can observe program execution and make a statistical model... |
| 18:44:02 | <lambdabot> | <hint>:1:79: error: |
| 18:44:03 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 18:44:21 | <segfaultfizzbuzz> | [exa]: ok i'll hang around for your comment, what would you like to say? |
| 18:44:29 | <[exa]> | (apologies to lambdabot I'm still in the olden mail years) |
| 18:44:34 | <segfaultfizzbuzz> | haha |
| 18:45:16 | <[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 |
| 18:45:33 | <segfaultfizzbuzz> | yeah i think that's because it is early days for statistics |
| 18:45:47 | <davean> | [exa]: I mean it fails for assembly in general, it works for small parts of assembly :) |
| 18:45:48 | → | thyriaen joins (~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) |
| 18:45:49 | <geekosaur> | uh |
| 18:46:07 | <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 |
| 18:46:08 | <[exa]> | segfaultfizzbuzz: I invite you to go tell this to statisticians here |
| 18:46:39 | <geekosaur> | I'm no statistician, but I know Itanium failed because this didn't work |
| 18:46:41 | <davean> | <having just cited queueing theory, comment about not talking about distributions> |
| 18:46:55 | <geekosaur> | even at assembly level |
| 18:47:12 | <[exa]> | c'mon I said it "kinda works optimistically" |
| 18:47:26 | <[exa]> | no sight of optimality |
| 18:48:02 | <geekosaur> | statistics has been around for longer than computers, and CS is quite aware of it |
| 18:48:13 | <davean> | [exa]: oh sure, I just meant some parts it doesn't work on. Like how long an FPU will take for FPU scheduling |
| 18:48:27 | <[exa]> | segfaultfizzbuzz: so well, imagine a computer program that simulates a decision of whatever branch/strictness predictor you have, and does precisely the opposite |
| 18:48:31 | <geekosaur> | one problem with taking the statistical route is you pay *heavily* if you end up out on the long tail |
| 18:49:53 | <[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 |
| 18:50:21 | <geekosaur> | that failed in Babbage's time, arguably 🙂 |
| 18:51:51 | <monochrom> | You need to say "kinda works kinda optimistically". The same way we sometimes have "unique up to unique isomorphism" >:) |
| 18:51:57 | <davean> | geekosaur: I was trying to explain that to him above! |
| 18:52:21 | → | beteigeuze joins (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 18:52:38 | <davean> | I was specificily trying to get into the tail component |
| 18:52:51 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 260 seconds) |
| 18:53:04 | <[exa]> | they timed out :( |
| 18:53:22 | <davean> | Lol, yes they did |
| 18:53:24 | <[exa]> | that's one way to battle undecidability I guess. |
| 18:53:27 | <int-e> | nobody predicted that |
| 18:53:34 | <[exa]> | lol |
| 18:53:37 | <monochrom> | hahaha |
| 18:53:47 | <davean> | int-e: well, other than some anti aircraft gunners in the first world war :) |
| 18:54:25 | <int-e> | davean: I was replying to "they timed out" but I guess that works too |
| 18:54:40 | <davean> | int-e: Me too |
| 18:54:46 | <monochrom> | I kinda did and always do. This is why my policy is "don't answer to answer, just don't answer". :) |
| 18:55:00 | <davean> | The queuing theory field was largely developed around your battle timing out |
| 18:55:53 | → | MajorBiscuit joins (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) |
| 18:56:34 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 18:57:01 | × | beteigeuze quits (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 256 seconds) |
| 18:58:16 | <monochrom> | Now I remember: https://danluu.com/cocktail-ideas/ applies. |
| 19:00:44 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 19:01:30 | <int-e> | . o O ( Aka "I could implement Twitter over an extended weekend". ) |
| 19:01:45 | <dminuoso> | `data Ptr a = Ptr Addr# deriving (Eq, Ord)` - how can this function in GHC, given that `class Eq a where ...` without polykinds enabled? |
| 19:02:33 | <dolio> | Yeah, I was wondering that, too. |
| 19:02:38 | <dolio> | Might be some magic. |
| 19:03:15 | <geekosaur> | what version of ghc? |
| 19:03:28 | <dminuoso> | % data MyPtr = MyPtr Addr# deriving Eq |
| 19:03:28 | <yahb2> | <no output> |
| 19:03:40 | <dminuoso> | Lets say 9.0.2 or newer |
| 19:04:11 | <geekosaur> | 9.0.2 rules out what I was thinking (iirc ghc2021 enables polykinds and is on by default in ghc 9.2+) |
| 19:04:34 | <geekosaur> | but then Ptr was H98 |
| 19:04:37 | <dminuoso> | % import GHC.Exts |
| 19:04:37 | <yahb2> | <no output> |
| 19:04:43 | <dminuoso> | % :set -XMagicHash |
| 19:04:43 | <yahb2> | <no output> |
| 19:04:50 | <dminuoso> | % :t (unsafeCoerce# 3# :: Addr#) == (unsafeCoerce# 3# :: Addr#) |
| 19:04:50 | <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 ... |
| 19:05:11 | <dolio> | It goes back pretty far. |
| 19:05:17 | <monochrom> | Try putting that into your MyPtr type. |
| 19:05:31 | × | MajorBiscuit quits (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) (Ping timeout: 256 seconds) |
| 19:05:35 | <geekosaur> | afaik it doesn't compare the Addr#s, just the pointers to the MyPtr itself |
| 19:05:37 | <dminuoso> | % :t MyPtr (unsafeCoerce# 3# :: Addr#) == MyPtr (unsafeCoerce# 3# :: Addr#) |
| 19:05:37 | <yahb2> | MyPtr (unsafeCoerce# 3# :: Addr#) == MyPtr (unsafeCoerce# 3# :: Addr#) ; :: Bool |
| 19:05:38 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 268 seconds) |
| 19:05:39 | <monochrom> | But it smells deep magic, yeah. |
| 19:06:08 | × | thyriaen quits (~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) (Quit: Leaving) |
| 19:06:32 | <dolio> | That code is in base 4.0.0.0. Hackage doesn't seem to have docs for the 3.x versions. |
| 19:06:37 | <dminuoso> | geekosaur: If that was the case, Eq on Ptr would not be useful much. You have reallyUnsafePtrEquality for that. |
| 19:06:53 | <dminuoso> | I would really expect Eq on Ptr to do equality on the contained Addr# |
| 19:07:04 | <EvanR> | Axman6, according to network package docs, Handle isn't recommended for networking and we should use Socket instead |
| 19:07:19 | <EvanR> | not that it helps do nonstandard stuff with it |
| 19:09:40 | → | stef204 joins (~stef204@user/stef204) |
| 19:09:56 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 19:10:05 | <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 |
| 19:10:47 | <EvanR> | reallyUnsafe = evenMoreProofObligations? xD |
| 19:10:48 | <int-e> | dminuoso: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Infer.hs#L520-527 seems relevant |
| 19:12:08 | <monochrom> | Nice, thanks int-e. |
| 19:12:41 | <dminuoso> | int-e: Is there some wired-in Addr type, perhaps? |
| 19:14:19 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 260 seconds) |
| 19:14:22 | <int-e> | there's also this https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L2379-2411 |
| 19:14:30 | <monochrom> | Addr# would be the wired-in address type. Just like Int# is wired-in machine-size int. |
| 19:14:56 | <int-e> | So... hmm. The note doesn't seem accurate. |
| 19:15:07 | <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 |
| 19:15:21 | <dminuoso> | Hence "will this box Addr# into Addr too? Where is that Addr type? |
| 19:15:36 | <int-e> | It's probably accurate for `Show` but we're talking about Eq and Ord. |
| 19:15:38 | <dolio> | It might know how to equate Addr#, though. |
| 19:15:39 | <monochrom> | Oh! Sorry, then I don't know. |
| 19:15:49 | <dolio> | No reason to box for that. |
| 19:16:14 | <geekosaur> | or might know that it can box Addr# into an Int |
| 19:16:18 | <int-e> | We can't derive Show for types having an Addr# field. |
| 19:16:52 | <geekosaur> | that kills that, then |
| 19:16:55 | <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 |
| 19:17:11 | <dminuoso> | prim_eq mmm |
| 19:17:45 | <dminuoso> | https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L2407 |
| 19:17:48 | <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. |
| 19:17:54 | <int-e> | dminuoso: it's extractd from the primOrdOps thing that I linked just before |
| 19:18:00 | <dminuoso> | https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Tc/Deriv/Generate.hs#L1600 |
| 19:18:02 | <dminuoso> | Here we go |
| 19:18:12 | <monochrom> | I don't know what happens to "reallyUnsafe" etc. |
| 19:18:14 | <dminuoso> | int-e: Yeah, so this is where it comes from. Nice. |
| 19:18:41 | <monochrom> | (I have a guess. Those mean you have to know how GHC generates code.) |
| 19:19:01 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 19:19:45 | <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. |
| 19:19:55 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection) |
| 19:20:34 | <EvanR> | so that would make C unsafe but not really unsafe? xD |
| 19:20:51 | <dminuoso> | geekosaur: Okay so that answers that question. Equality on Ptr will do an equality check on the contained Addr# pointer. |
| 19:20:55 | <EvanR> | because a lot of effort is placed in modern C on not asking or tell what the compiler does |
| 19:21:00 | <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. |
| 19:21:07 | <monochrom> | I guess that depends on how much UB you have in your C code? :) |
| 19:21:57 | <EvanR> | inActualityUnsafe haha |
| 19:22:19 | <monochrom> | There are people who take the stance "C means C without UB". To them C is merely unsafe, yeah. |
| 19:22:22 | <dminuoso> | int-e, EvanR: reallyUnsafePtrEquality |
| 19:22:24 | <EvanR> | turnsOutIt'sUnsafe |
| 19:22:25 | <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 |
| 19:22:25 | <dminuoso> | https://stackoverflow.com/a/24602066/6636995 |
| 19:22:28 | <dminuoso> | Sorry ^- that link |
| 19:22:39 | <dminuoso> | That's some quite disgusting fact about reallyUnsafePtrEquality |
| 19:22:58 | <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. |
| 19:23:20 | <monochrom> | i.e., exactly you need to know what your C compiler actually do and count on it. |
| 19:23:41 | <int-e> | dminuoso: "I hate indirections" |
| 19:23:47 | <EvanR> | that seems to be status quo back in the days of B |
| 19:23:57 | <dminuoso> | So I guess reallyUnsafePtrEquality can work on thunks too. |
| 19:24:13 | <int-e> | dminuoso: they should've done the performGC, then recheck thing. |
| 19:24:28 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 19:24:30 | <dminuoso> | int-e: Yeah, that note about the performMinorGC is truly even more terrifying. |
| 19:24:36 | <int-e> | (which has to be done carefully, because of opportunistic CSE)) |
| 19:24:42 | <dminuoso> | "Look, just perform a garbage collecting before comparing for equality. Obviously!" |
| 19:25:59 | <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 |
| 19:26:25 | <segfaultfizzbuzz> | to those who were trying to talk to me, i am reading the irc archive :-) pardon the timeout |
| 19:26:25 | <dminuoso> | int-e: Ohhh static indirections that are cleaned up by GC?! |
| 19:26:33 | <dminuoso> | I see. |
| 19:26:47 | → | kenran joins (~user@user/kenran) |
| 19:26:51 | <monochrom> | Yeah make sure you evaluate everything and then perform GC. Turn on StrictData or something. :) |
| 19:26:53 | <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. |
| 19:27:16 | <EvanR> | dminuoso, having trouble following that linked example. They read in 1 Bool and print out 2? |
| 19:27:49 | <monochrom> | I think the first "True" line is user input. |
| 19:27:56 | <int-e> | dminuoso: I don't think it can move those. |
| 19:27:57 | <dminuoso> | Yup, its the line echo from readLn |
| 19:28:05 | <EvanR> | I see, so Nothing is not necessarily the same object as Nothing |
| 19:28:22 | <dminuoso> | EvanR: no it is. |
| 19:28:36 | <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. |
| 19:28:40 | <EvanR> | not according to reallyUnsafePtrEquality#? |
| 19:28:43 | <monochrom> | Oh, you're looking at laziness forming an "if ... then ... else ..." thunk and leaving it unevaluated. |
| 19:28:50 | <EvanR> | oh |
| 19:28:56 | <dminuoso> | EvanR: but the thing is reallyUnsafePtrEquality# just works on whatever address there physically ends up. Thunks, indirections.. |
| 19:29:15 | <monochrom> | So obviously it has a different address from False's, even though eventually it could be evaluated to False one day. |
| 19:29:26 | <dminuoso> | int-e: I guess reallyUnsafePtrEquality# just compares *entry* code pointer? |
| 19:29:28 | <c_wraith> | Is backpack usable these days? |
| 19:29:35 | <dminuoso> | (whatever that entry code pointer is) |
| 19:29:51 | <dminuoso> | c_wraith: Sure, aside from the complete lack of documentation. |
| 19:30:07 | <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 |
| 19:30:09 | <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 |
| 19:30:18 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 19:30:27 | <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" |
| 19:30:30 | <dminuoso> | Nothing beyond that |
| 19:30:30 | <int-e> | dminuoso: No, it compares the heap object address |
| 19:30:34 | <c_wraith> | monochrom: in GHC, all evaluated Falses have the same pointer. (all evaluated nullary constructors, in general) |
| 19:30:35 | <monochrom> | Oh wait the "print $ a == a'" gets it evaluated. I need a different explanation. But what they said above about an indirection. |
| 19:30:55 | × | fserucas quits (~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Quit: Leaving) |
| 19:31:21 | <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. |
| 19:31:29 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 19:32:12 | <EvanR> | c_wraith, so Nothing is the same as False? Again haskell trying to compete with javascript or ruby |
| 19:32:22 | <dminuoso> | int-e: Okay, what about an indirection closure then? What would it use for that? |
| 19:32:24 | <c_wraith> | EvanR: I worded that poorly... :P |
| 19:32:34 | <int-e> | "it"? |
| 19:32:36 | <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. |
| 19:32:54 | <c_wraith> | EvanR: *each* nullary constructor exists on the heap exactly once, in an evaluated form. |
| 19:33:15 | <EvanR> | ok and the types have their own objects |
| 19:33:19 | <c_wraith> | yes |
| 19:33:22 | <int-e> | dminuoso: reallyUnsafePtrEquality does not look at the heap. |
| 19:33:26 | <EvanR> | what a waste of space! |
| 19:33:59 | <int-e> | dminuoso: it makes no difference whether there's an indirection there, or a thunk, or a constructor |
| 19:34:08 | <int-e> | or a Fun |
| 19:34:09 | <int-e> | FUN |
| 19:34:09 | <monochrom> | Ugh nullary constructors don't even exist on the heap. They're in a static data segment. |
| 19:34:12 | <dminuoso> | int-e: then how can a performMinorGC have any impact? |
| 19:34:21 | → | gmg joins (~user@user/gehmehgeh) |
| 19:34:57 | <int-e> | dminuoso: because it changes values in the stack to point to the new heap, and it elides indirections from the heap representation. |
| 19:35:03 | <c_wraith> | monochrom: ok, fair. Each evaluated nullary constructor has exactly one in memory *somewhere*. :P |
| 19:35:22 | <dolio> | Or is it? |
| 19:35:30 | <int-e> | and while the GC is running, all the values that might feed into primitive operations like rUPE are on the stack |
| 19:35:33 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 256 seconds) |
| 19:35:35 | <dminuoso> | int-e: Just to avoid confusion, when you mean elide indirections from the heap represetation, do you mean eliminiating indirect thunks? |
| 19:35:46 | <dminuoso> | (that is thunks of type indirect) |
| 19:36:06 | <monochrom> | Yes. |
| 19:36:11 | <int-e> | it's called an indirection inside GHC, there are no indirect thunks. |
| 19:36:32 | <monochrom> | Anyone who pointed to the Ind object are modified to point to Nothing directly. |
| 19:36:36 | <int-e> | an indirection might point to a thunk, so that terminology becomes confusing |
| 19:36:51 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 19:37:02 | <monochrom> | Perhaps the wording "path compression" helps, if you've seen it before. |
| 19:38:16 | <dminuoso> | Indirections just occur if the original closure was not large enough for the computed value, right? |
| 19:38:22 | → | CiaoSen joins (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 19:38:43 | <dolio> | That's not the only possibility. |
| 19:40:26 | × | coot quits (~coot@213.134.171.3) (Quit: coot) |
| 19:41:07 | <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. |
| 19:42:18 | <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. |
| 19:42:31 | <dolio> | Or maybe at most two or something. |
| 19:42:38 | <dolio> | Then GC can fix things up later. |
| 19:43:57 | <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. |
| 19:44:29 | <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) |
| 19:45:42 | <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. |
| 19:45:47 | <int-e> | (I'm not sure, I definitely don't know the exact conditions for when GHC's runtime creates indirections.) |
| 19:46:05 | <dolio> | Makes it harder to overflow the stack. |
| 19:46:15 | <dolio> | Back when that mattered. |
| 19:47:22 | <int-e> | let y = x won't create an indirecion. |
| 19:48:22 | × | cheater quits (~Username@user/cheater) (Quit: BitchX: more nutritious than a six-pack.) |
| 19:48:42 | <dolio> | Well, I don't think GHC will literally compile that to an actual operation. |
| 19:49:50 | <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. |
| 19:50:22 | <dolio> | You probably need to try harder to make this case matter in actual Haskell code. |
| 19:50:23 | <int-e> | naively, it'll allocate a register, copy the register that holds x, and then jump to the entry point for `loop` again. |
| 19:51:12 | <int-e> | I guess you have something like y = id x in mind, hmm. That would build a thunk though, not an indirection. |
| 19:51:33 | <dolio> | It's when you're evaluating one of the ys. |
| 19:52:03 | <int-e> | pretty sure it isn't |
| 19:52:14 | <int-e> | we got stack overflows instead, because of update frames |
| 19:52:30 | <int-e> | before GHC learned to grow the stack on the heap instead. |
| 19:52:30 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 19:52:41 | <dolio> | Not from this case, you didn't. |
| 19:53:03 | <dolio> | Unless they threw out the optimization that specifically gets talked about in, like, STG papers. |
| 19:53:05 | <int-e> | it's no different from the usual iterate (+1) 0 !! 1000000 case, is it? |
| 19:53:37 | <dolio> | That one isn't just a string of updates, there are (+1) operations at every step. |
| 19:53:45 | <dolio> | Every thunk is different. |
| 19:53:59 | <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? |
| 19:54:01 | <int-e> | well, you either have that or you have neither thunk nor indirection. |
| 19:54:33 | <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. |
| 19:54:48 | → | cheater joins (~Username@user/cheater) |
| 19:54:53 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 19:56:04 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 19:56:09 | <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 |
| 19:56:29 | <int-e> | dolio: there's the selector thunk story which is related but again different. |
| 19:57:33 | × | cheater quits (~Username@user/cheater) (Client Quit) |
| 19:58:15 | <int-e> | Which will help for f (a, b) = if b == 0 then a else f (a, b - 1) |
| 19:58:42 | → | waleee joins (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 20:00:23 | <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) |
| 20:00:24 | <int-e> | err. f (~(a, b)) = if b == 0 then a else f (a, b - 1) |
| 20:01:08 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 20:01:10 | <dolio> | ./Foo +RTS -K1k |
| 20:01:14 | <dolio> | No stack overflow. |
| 20:01:47 | <dolio> | Uses 8GB of memory, though, so there's probably a thunk. |
| 20:05:08 | → | cheater joins (~Username@user/cheater) |
| 20:05:49 | <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. |
| 20:06:12 | <int-e> | (if you don't optimize or protect against inlining `g`) |
| 20:07:47 | <int-e> | (tail recursion is the difference to (+1)) |
| 20:07:49 | <dolio> | How do you avoid overflowing the stack while also pushing 100 million update frames on it? |
| 20:08:10 | <int-e> | you don't have to push an update frame if you do tail recursion |
| 20:08:27 | <int-e> | the update is done by the caller with the final result |
| 20:09:04 | <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 |
| 20:09:08 | <int-e> | ...that's wrong. the update frame was put there by the caller |
| 20:09:30 | <int-e> | (cps transform makes this confusing) |
| 20:09:41 | → | machinedgod joins (~machinedg@clnet-b05-118.ikbnet.co.at) |
| 20:09:57 | <int-e> | there is no value to rewrite |
| 20:10:17 | <int-e> | functions have results |
| 20:11:39 | → | polo joins (sid532813@id-532813.tinside.irccloud.com) |
| 20:12:31 | → | coot joins (~coot@213.134.171.3) |
| 20:12:50 | × | earthy quits (~arthurvl@2a02-a469-f5e2-1-ba27-ebff-fea0-40b0.fixed6.kpn.net) (Quit: WeeChat 2.3) |
| 20:13:02 | × | polo quits (sid532813@id-532813.tinside.irccloud.com) (Changing host) |
| 20:13:02 | → | polo joins (sid532813@user/polo) |
| 20:13:06 | polo | is now known as money |
| 20:13:23 | → | wootehfoot joins (~wootehfoo@user/wootehfoot) |
| 20:13:55 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 20:15:27 | <dolio> | If you feed (+1) into my g function, it will overflow the stack. |
| 20:16:12 | <int-e> | Yes. But... actually not because of update frames. It'll be all the pending +1 operations. |
| 20:16:32 | <int-e> | g finishes without overflowing the stack |
| 20:16:34 | <dolio> | It will also have many more update frames. |
| 20:16:50 | <dolio> | Update frames happen when you evaluate the result of g to print it. |
| 20:17:43 | → | bgs joins (~bgs@212-85-160-171.dynamic.telemach.net) |
| 20:19:41 | → | random-jellyfish joins (~random-je@user/random-jellyfish) |
| 20:21:55 | <int-e> | Hmm |
| 20:24:47 | × | mmhat quits (~mmh@p200300f1c7050cb8ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 20:24:58 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 20:25:09 | → | mmhat joins (~mmh@p200300f1c7050c1bee086bfffe095315.dip0.t-ipconnect.de) |
| 20:25:42 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 20:25:56 | → | akirksall joins (~akirksall@cpe-24-90-197-230.nyc.res.rr.com) |
| 20:27:36 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 260 seconds) |
| 20:27:42 | <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. |
| 20:27:57 | <dolio> | And we're printing the outermost one. |
| 20:28:55 | <dolio> | id not using stack is essential for the update frame rule to kick in. |
| 20:31:56 | → | sammelweis joins (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 20:34:32 | ← | akirksall parts (~akirksall@cpe-24-90-197-230.nyc.res.rr.com) () |
| 20:38:43 | → | srz joins (~srz@devil.dm.uba.ar) |
| 20:38:52 | → | jlgw joins (~jw@83-233-104-81.cust.bredband2.com) |
| 20:39:53 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 20:41:06 | → | chromoblob joins (~user@37.113.164.122) |
| 20:44:25 | × | kenran quits (~user@user/kenran) (Remote host closed the connection) |
| 20:44:54 | → | freeside_ joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 20:46:06 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Remote host closed the connection) |
| 20:46:37 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 252 seconds) |
| 20:47:04 | × | lyle quits (~lyle@104.246.145.85) (Quit: WeeChat 3.7.1) |
| 20:50:34 | → | pavonia joins (~user@user/siracusa) |
| 20:54:10 | × | srz quits (~srz@devil.dm.uba.ar) (Ping timeout: 268 seconds) |
| 20:55:55 | <monochrom> | Ugh, if I compile with -prof, it grows stack (near the end), and overflows 1k stack. |
| 20:56:04 | × | enoq quits (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 20:56:45 | → | troydm joins (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 20:58:10 | × | coot quits (~coot@213.134.171.3) (Quit: coot) |
| 21:03:54 | → | moonsheep joins (~user@user/moonsheep) |
| 21:03:56 | × | moonsheep quits (~user@user/moonsheep) (Client Quit) |
| 21:04:00 | × | waleee quits (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 260 seconds) |
| 21:05:16 | × | werneta quits (~werneta@137.78.30.207) (Ping timeout: 268 seconds) |
| 21:06:02 | <EvanR> | overflows a 1k stack, there goes my haskell on arduino project |
| 21:06:02 | → | waleee joins (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 21:06:18 | <monochrom> | Turn off profiling and you'll be alright. :) |
| 21:07:09 | <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. |
| 21:10:46 | <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. |
| 21:12:05 | × | michalz quits (~michalz@185.246.207.197) (Remote host closed the connection) |
| 21:12:14 | <dolio> | Yeah, could be. |
| 21:12:27 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 21:12:34 | <geekosaur> | that might conceivably be considered a bug |
| 21:13:12 | → | ft joins (~ft@p508dbd59.dip0.t-ipconnect.de) |
| 21:14:20 | → | beteigeuze joins (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 21:14:28 | × | irrgit_ quits (~irrgit@89.47.234.26) (Quit: Leaving) |
| 21:14:31 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 21:14:40 | <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. |
| 21:15:01 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 21:15:39 | <dolio> | Like, if you take the iterations way down, and remove the stack limit, does it show some 1000-fold nesting of cost centers? |
| 21:16:22 | × | freeside_ quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 268 seconds) |
| 21:16:36 | × | ub quits (~Thunderbi@178.165.184.78.wireless.dyn.drei.com) (Ping timeout: 260 seconds) |
| 21:16:36 | → | werneta joins (~werneta@137.79.197.69) |
| 21:16:39 | → | emmanuelux joins (~emmanuelu@user/emmanuelux) |
| 21:21:27 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 21:26:46 | × | wootehfoot quits (~wootehfoo@user/wootehfoot) (Ping timeout: 252 seconds) |
| 21:28:28 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 21:29:11 | × | `2jt quits (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 260 seconds) |
| 21:37:23 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 256 seconds) |
| 21:40:35 | → | Guest75 joins (~Guest75@178.141.177.81) |
| 21:44:44 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 21:46:37 | → | eggplantade joins (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) |
| 21:47:23 | × | werneta quits (~werneta@137.79.197.69) (Ping timeout: 260 seconds) |
| 21:47:59 | → | kenaryn joins (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 21:50:50 | × | eggplantade quits (~Eggplanta@2600:1700:38c5:d800:ac76:5dba:fbad:434b) (Ping timeout: 240 seconds) |
| 21:52:05 | → | chromoblob joins (~user@37.113.164.122) |
| 21:54:30 | → | catern joins (~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407) |
| 21:58:21 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 22:00:03 | <monochrom> | No. |
| 22:02:26 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 22:05:29 | × | rendar quits (~Paxman@user/rendar) (Ping timeout: 260 seconds) |
| 22:07:27 | → | coot joins (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 22:07:48 | <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. |
| 22:08:05 | → | werneta joins (~werneta@137.78.30.207) |
| 22:09:13 | <monochrom> | It would rather report "cost centre foo has 10^100 entries" than report "foo -> foo -> foo..." 10^100 times. |
| 22:10:12 | → | fockerize joins (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 22:12:07 | × | zeenk quits (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 22:12:45 | <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. |
| 22:20:15 | <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. |
| 22:21:15 | → | slack1256 joins (~slack1256@186.11.56.146) |
| 22:22:07 | <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. |
| 22:22:24 | <slack1256> | I need the type to constraint `try @ThisType` on the source code. |
| 22:23:31 | <geekosaur> | I suspect you'd need to get a ghci built for profiling, which would mean building ghc yourself |
| 22:23:54 | × | gmg quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 22:23:58 | <monochrom> | I suspect that -xc results in a similar message anyway. |
| 22:24:12 | <monochrom> | http://www.vex.net/~trebla/haskell/exception-tutorial.xhtml#supertyping is what actually helps. |
| 22:24:12 | <geekosaur> | have you tried using a typed hole ? `try @_` |
| 22:24:47 | <slack1256> | geekosaur: That is an great idea, let me try |
| 22:25:07 | <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. |
| 22:25:19 | <slack1256> | Wait, I thought @_ on type applications did not mean "type hole". Instead they meant "omit binding this type variable |
| 22:25:37 | <geekosaur> | hm, possibly |
| 22:25:38 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 22:26:06 | × | bgs quits (~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection) |
| 22:27:17 | <geekosaur> | come to think of it, if @_ did what I wanted then it wouldn't be necessary… |
| 22:27:33 | <geekosaur> | (the TypeApplication, that is) |
| 22:27:39 | <geekosaur> | sad |
| 22:28:44 | <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. |
| 22:28:56 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 22:29:22 | <monochrom> | Every exception type has a Typeable instance (because superclass of Exception) so you aren't really using extra features. |
| 22:30:18 | <geekosaur> | actually, every type has a Typeable instance these days |
| 22:30:19 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 260 seconds) |
| 22:30:23 | <geekosaur> | ghc uses them internally |
| 22:30:49 | → | sammelweis joins (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 22:30:51 | <monochrom> | Well at least those are not exposed, while Exception's is. |
| 22:31:23 | <geekosaur> | you have to declare them to use them (deriving Typeable, but LANGUAGE DeriveTypeable is gone) but they're there |
| 22:31:37 | <monochrom> | ghci needs it for sure. Compiled code though still has type erasure to the maximum extent. |
| 22:31:47 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 22:32:11 | <geekosaur> | right, you'd only see it in compiled code if you did something that captured the dictionary |
| 22:34:25 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 22:35:33 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 22:35:39 | <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 |
| 22:35:46 | × | shapr quits (~user@68.54.166.125) (Remote host closed the connection) |
| 22:37:18 | <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. |
| 22:37:41 | <monochrom> | Ah. |
| 22:38:15 | <int-e> | Err, I meant to link to https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/ThreadPaused.c#L81 |
| 22:38:16 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds) |
| 22:39:29 | → | sammelweis joins (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 22:40:07 | × | titibandit quits (~titibandi@xdsl-78-35-167-196.nc.de) (Remote host closed the connection) |
| 22:40:36 | <dolio> | Maybe it's faster to push update frames and only coalesce them on certain events. |
| 22:40:39 | <int-e> | (and that indeed produces indirections to a thunk, which may later be updated by another indirection) |
| 22:43:15 | <dolio> | It would be a little surprising if hitting a hard stack limit is the only even that causes it. |
| 22:43:29 | × | sammelweis quits (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Client Quit) |
| 22:43:37 | <int-e> | it's the soft stack limit |
| 22:43:39 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com) |
| 22:44:12 | <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. |
| 22:44:12 | <int-e> | so the point where a new stack chunk would have to be allocated |
| 22:45:37 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 22:45:44 | <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) |
| 22:46:05 | → | thyriaen joins (~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) |
| 22:46:30 | <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. |
| 22:47:03 | → | sammelweis joins (~quassel@c-68-48-18-140.hsd1.mi.comcast.net) |
| 22:47:10 | <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) |
| 22:48:09 | <int-e> | (Hmm, can an exception trigger both? I don't know.) |
| 22:48:13 | <dolio> | There are other situations like this, too, although I forget what a good example is. |
| 22:48:57 | <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. |
| 22:50:00 | <int-e> | one thing that comes to mind is reference counting and efforts to make it more lazy |
| 22:50:31 | <dolio> | Oh, I mean something that GHC actually does. |
| 22:50:38 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 22:51:19 | <int-e> | not bothering with atomic operations when entering a thunk, even though that might cause duplicate evaluation |
| 22:51:42 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 22:53:54 | × | random-jellyfish quits (~random-je@user/random-jellyfish) (Quit: Client closed) |
| 22:55:30 | × | chromoblob quits (~user@37.113.164.122) (Ping timeout: 240 seconds) |
| 22:56:25 | <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? |
| 22:57:17 | × | freeside quits (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 22:57:35 | → | tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 22:58:20 | <dolio> | And that saves time when you're not evaluating loops, which is most of the time. |
| 22:58:29 | × | coot quits (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 22:59:25 | × | mmhat quits (~mmh@p200300f1c7050c1bee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 23:01:06 | <int-e> | yes, lazy black-holing is related... but conflicts with what you want for SMP |
| 23:01:35 | <dolio> | Sure. |
| 23:02:26 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 268 seconds) |
| 23:02:32 | → | mmhat joins (~mmh@p200300f1c7050c1bee086bfffe095315.dip0.t-ipconnect.de) |
| 23:03:09 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 23:05:23 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 23:07:22 | × | machinedgod quits (~machinedg@clnet-b05-118.ikbnet.co.at) (Ping timeout: 268 seconds) |
| 23:09:39 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Ping timeout: 260 seconds) |
| 23:10:32 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 23:11:21 | × | johnw quits (~johnw@2600:1700:cf00:db0:99a3:483a:651:9bf1) (Quit: ZNC - http://znc.in) |
| 23:15:17 | × | tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 23:17:51 | × | vglfr quits (~vglfr@145.224.100.100) (Ping timeout: 268 seconds) |
| 23:22:17 | → | freeside joins (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 23:31:39 | → | johnw joins (~johnw@2600:1700:cf00:db0:6d6a:a571:6c8a:51fc) |
| 23:36:01 | × | use-value quits (~Thunderbi@2a00:23c6:8a03:2f01:d5b6:b99f:4049:77a7) (Remote host closed the connection) |
| 23:36:20 | → | use-value joins (~Thunderbi@2a00:23c6:8a03:2f01:d5b6:b99f:4049:77a7) |
| 23:39:10 | × | fockerize quits (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 240 seconds) |
| 23:39:40 | × | cheater quits (~Username@user/cheater) (Read error: Connection reset by peer) |
| 23:42:34 | × | Guest75 quits (~Guest75@178.141.177.81) (Quit: Client closed) |
| 23:44:37 | → | segfaultfizzbuzz joins (~segfaultf@12.172.217.142) |
| 23:44:40 | × | segfaultfizzbuzz quits (~segfaultf@12.172.217.142) (Remote host closed the connection) |
| 23:45:36 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 23:51:38 | → | mixfix41 joins (~sdeny9ee@user/mixfix41) |
| 23:54:11 | × | stiell quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds) |
| 23:54:23 | × | causal quits (~user@50.35.83.177) (Quit: WeeChat 3.7.1) |
| 23:54:30 | × | CiaoSen quits (~Jura@p200300c95701f1002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 23:55:00 | → | stiell joins (~stiell@gateway/tor-sasl/stiell) |
| 23:56:54 | × | mixfix41 quits (~sdeny9ee@user/mixfix41) (Ping timeout: 260 seconds) |
| 23:57:57 | → | slac39565 joins (~slack1256@191.126.227.195) |
| 23:58:52 | → | mixfix41 joins (~sdeny9ee@user/mixfix41) |
All times are in UTC on 2022-11-15.