| 2022-11-19 00:01:00 +0100 | <Guest99> | @geekosaur I knew I was missing the obvious! 🙄 Thank you! 👍 |
| 2022-11-19 00:01:01 +0100 | <lambdabot> | Unknown command, try @list |
| 2022-11-19 00:02:29 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Quit: Leaving.) |
| 2022-11-19 00:02:55 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) (Client Quit) |
| 2022-11-19 00:03:05 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) |
| 2022-11-19 00:03:07 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 00:03:08 +0100 | <roconnor> | sclv: davean: I was wrong v1-register requires dist to be build, i.e. v1-build to have run. |
| 2022-11-19 00:04:38 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-19 00:04:51 +0100 | <roconnor> | and even if it did build, it registers the target install location, but there is no command to move a build from dist-newstyle to the install location (AFAIK). |
| 2022-11-19 00:11:48 +0100 | tomku | (~tomku@user/tomku) (Ping timeout: 248 seconds) |
| 2022-11-19 00:14:57 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-19 00:21:50 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 240 seconds) |
| 2022-11-19 00:23:54 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-19 00:27:00 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 00:28:25 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-19 00:38:20 +0100 | tomku | (~tomku@user/tomku) |
| 2022-11-19 00:38:42 +0100 | poscat0x04 | (~poscat@2408:8206:4823:fd6f:98ab:5c38:136c:5932) |
| 2022-11-19 00:39:48 +0100 | poscat | (~poscat@114.245.106.84) (Ping timeout: 260 seconds) |
| 2022-11-19 00:40:45 +0100 | <roconnor> | and running ghc-pkg register by hand doesn't seem possible because I need to generateRegistrationInfo first. |
| 2022-11-19 00:40:58 +0100 | Guest99 | (~Guest99@2607:fb91:30b:a443:3fd:394e:ecd:5968) (Ping timeout: 260 seconds) |
| 2022-11-19 00:41:54 +0100 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 260 seconds) |
| 2022-11-19 00:42:31 +0100 | m5zs7k | (aquares@web10.mydevil.net) |
| 2022-11-19 00:42:59 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-11-19 00:43:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 00:44:54 +0100 | <roconnor> | I guess registering packages wtih cabal v2 just isn't going to be possible. I don't quite understand why the new cabal is deficient in this way. |
| 2022-11-19 00:45:30 +0100 | <roconnor> | I guess I just don't understand how it is supposed to be used. |
| 2022-11-19 00:45:36 +0100 | <sclv> | the intention is that everyone who needs it can use the setup.hs workflow |
| 2022-11-19 00:45:59 +0100 | <sclv> | personally i don't know if i agree with that intention, but that's the reasoning |
| 2022-11-19 00:46:18 +0100 | <roconnor> | oh I see. |
| 2022-11-19 00:46:20 +0100 | <sclv> | but that certainly underlines that the setup.hs haddock path with backpack _must_ be fixed |
| 2022-11-19 00:46:59 +0100 | <roconnor> | yeah, I was under the impression that it would simply never be fixed because it is a depricated build method. |
| 2022-11-19 00:47:06 +0100 | <sclv> | and also i'm extremely open to trying to improve the v2 story with stuff like registration -- as i mentioned earlier i did get in a patch that helped with some v2 build stuff already for package managers dealing with v2-built _executables_ |
| 2022-11-19 00:47:10 +0100 | <roconnor> | but it sounds like it isn't depricated. |
| 2022-11-19 00:47:22 +0100 | <sclv> | setup.hs is not at all deprecated -- its the "raw truth" underlying cabal v1 and v2 both |
| 2022-11-19 00:47:31 +0100 | <sclv> | its only cabal v1 which is deprecated |
| 2022-11-19 00:48:08 +0100 | <roconnor> | I'm a bit surprised that cabal v2-haddock works so well with setup haddock being broken. |
| 2022-11-19 00:48:12 +0100 | <sclv> | my view is that v2-build should also allow access to low level stuff like generating conf files, etc. however other people have argued the other way |
| 2022-11-19 00:49:13 +0100 | <roconnor> | All right. I think next week I'll go back to using setup to build but see if I can replace haddockPhase with a call to cabal haddock. |
| 2022-11-19 00:49:29 +0100 | <sclv> | fgaz' comments here express the view i'm trying to summarize https://github.com/haskell/cabal/issues/3586#issuecomment-1266463088 |
| 2022-11-19 00:49:36 +0100 | <sclv> | sorry this is so painful for you! |
| 2022-11-19 00:50:00 +0100 | <roconnor> | I kinda chalk it up to using backpack in the first place. |
| 2022-11-19 00:50:08 +0100 | <sclv> | is there a ticket filed against the cabal repo for Cabal haddock not working with backpack? |
| 2022-11-19 00:50:09 +0100 | <roconnor> | It is just too new. |
| 2022-11-19 00:50:15 +0100 | acidjnk | (~acidjnk@p200300d6e7137a305cc03b10fd7a2523.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 00:50:29 +0100 | <sclv> | its sadly not that new, just hasn't had enough adapters yet. we need people on the bleeding edge otherwise things will never get fixed |
| 2022-11-19 00:50:40 +0100 | <geekosaur> | ^ |
| 2022-11-19 00:50:51 +0100 | <geekosaur> | it's older than, say, linear haskell |
| 2022-11-19 00:50:56 +0100 | <geekosaur> | but people are using that |
| 2022-11-19 00:50:58 +0100 | <sclv> | if there's no ticket for the underlying issue you'd like to get fixed, please please file one! |
| 2022-11-19 00:51:10 +0100 | <roconnor> | So I was following up on my Aug 6th comments in https://github.com/haskell/cabal/issues/7987 |
| 2022-11-19 00:51:33 +0100 | <roconnor> | Yes I sould say that issue is the issue. |
| 2022-11-19 00:51:37 +0100 | <geekosaur> | sadly there's something of a doc shortage re backpack, plus stack doesn't support it yet which locks out a goodly chunk of the potential userbase |
| 2022-11-19 00:51:48 +0100 | <roconnor> | I guess I haven't tried ghc 9.4. |
| 2022-11-19 00:52:43 +0100 | <sclv> | ok thanks for the link roconnor. i added some attention flags and milestoned it to try to keep it in the air |
| 2022-11-19 00:52:56 +0100 | <roconnor> | I can give ghc 9.4 a try next week, but I would guess it is still broken. |
| 2022-11-19 00:53:33 +0100 | <roconnor> | btw, the haddock generated files have been broken for a while. Now it is also crashing. |
| 2022-11-19 00:53:49 +0100 | <roconnor> | but the cabal haddock generated files seem just perfect! |
| 2022-11-19 00:53:59 +0100 | <sclv> | that doesn't mean someone will get to it anytime soon, but at least its something we can try to get eyes on |
| 2022-11-19 00:54:59 +0100 | <sclv> | i think what's hapening is v2-haddock already has to have a better sense of directory structure etc because it already handles multiple components (packages). the underlying setup.hs mechanism has this hard one-component logic built in. but that's just a wild ass guess |
| 2022-11-19 00:59:51 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 2022-11-19 01:10:04 +0100 | mauke_ | (~mauke@p5091177f.dip0.t-ipconnect.de) |
| 2022-11-19 01:11:52 +0100 | mauke | (~mauke@p57b6eb34.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-11-19 01:20:28 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Remote host closed the connection) |
| 2022-11-19 01:21:21 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Remote host closed the connection) |
| 2022-11-19 01:25:01 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-19 01:25:38 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Client Quit) |
| 2022-11-19 01:29:20 +0100 | denh^ | (~denl@76.145.185.103) |
| 2022-11-19 01:39:10 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-11-19 01:39:51 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 01:41:09 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-11-19 01:43:50 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-19 01:44:34 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-19 01:44:34 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-19 01:44:34 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-19 01:44:40 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 01:48:21 +0100 | caryhartline | (~caryhartl@2600:1700:2d0:8d30:3193:f3f8:77d4:386c) (Quit: caryhartline) |
| 2022-11-19 01:50:22 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::efb) |
| 2022-11-19 02:01:42 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-19 02:03:13 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 02:03:40 +0100 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.7.1) |
| 2022-11-19 02:04:22 +0100 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-19 02:05:35 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-19 02:05:45 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 02:06:15 +0100 | ub | (~Thunderbi@178.115.40.94.wireless.dyn.drei.com) |
| 2022-11-19 02:06:48 +0100 | caryhartline | (~caryhartl@107.140.218.181) |
| 2022-11-19 02:06:56 +0100 | ubert1 | (~Thunderbi@178.165.197.162.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2022-11-19 02:07:30 +0100 | ubert | (~Thunderbi@178.165.197.162.wireless.dyn.drei.com) (Ping timeout: 256 seconds) |
| 2022-11-19 02:07:30 +0100 | ub | ubert |
| 2022-11-19 02:08:17 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-19 02:10:20 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 256 seconds) |
| 2022-11-19 02:10:33 +0100 | nilradical | (~nilradica@user/naso) |
| 2022-11-19 02:15:13 +0100 | nilradical | (~nilradica@user/naso) (Client Quit) |
| 2022-11-19 02:16:10 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Ping timeout: 260 seconds) |
| 2022-11-19 02:17:21 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-19 02:19:20 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 02:36:19 +0100 | srz | (~srz@179.36.119.226) |
| 2022-11-19 02:36:44 +0100 | KaitoDaumoto | (~asdf@user/kaitodaumoto) (Read error: Connection reset by peer) |
| 2022-11-19 02:44:20 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 02:46:50 +0100 | ft | (~ft@i59F54BF7.versanet.de) (Ping timeout: 240 seconds) |
| 2022-11-19 02:48:49 +0100 | ft | (~ft@87.122.4.81) |
| 2022-11-19 03:07:24 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-19 03:10:35 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2022-11-19 03:10:53 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2022-11-19 03:12:24 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-19 03:16:09 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-11-19 03:20:38 +0100 | razetime | (~quassel@117.193.6.219) |
| 2022-11-19 03:22:08 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 03:27:34 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 03:28:19 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 03:32:49 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 03:37:08 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) (Ping timeout: 260 seconds) |
| 2022-11-19 03:40:26 +0100 | razetime | (~quassel@117.193.6.219) (Ping timeout: 256 seconds) |
| 2022-11-19 03:45:10 +0100 | pfurla | (~pfurla@2804:14d:5c5a:b298:9141:4b85:8142:1856) |
| 2022-11-19 03:46:28 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 03:47:44 +0100 | pfurla | (~pfurla@2804:14d:5c5a:b298:9141:4b85:8142:1856) (Client Quit) |
| 2022-11-19 03:48:51 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2022-11-19 03:51:15 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 04:06:53 +0100 | td_ | (~td@83.135.9.5) (Ping timeout: 256 seconds) |
| 2022-11-19 04:08:05 +0100 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 2022-11-19 04:08:46 +0100 | td_ | (~td@83.135.9.60) |
| 2022-11-19 04:12:02 +0100 | bilegeek | (~bilegeek@2600:1008:b069:2ea1:a3d0:790d:f039:13b9) |
| 2022-11-19 04:13:43 +0100 | marc__ | (~marc@5.83.191.214) |
| 2022-11-19 04:16:15 +0100 | goepsilongo | (~goepsilon@2603-7000-ab00-00e5-392a-bca4-733f-bcd4.res6.spectrum.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-19 04:16:46 +0100 | goepsilongo | (~goepsilon@2603-7000-ab00-00e5-392a-bca4-733f-bcd4.res6.spectrum.com) |
| 2022-11-19 04:17:16 +0100 | marc___ | (~marc@5.83.191.79) (Ping timeout: 256 seconds) |
| 2022-11-19 04:17:59 +0100 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-19 04:40:07 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-11-19 04:40:30 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 256 seconds) |
| 2022-11-19 04:45:02 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-11-19 04:47:44 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds) |
| 2022-11-19 04:48:06 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-11-19 04:48:18 +0100 | Batzy | (~quassel@user/batzy) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-11-19 04:48:42 +0100 | Batzy | (~quassel@user/batzy) |
| 2022-11-19 04:50:45 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2022-11-19 04:51:05 +0100 | jargon | (~jargon@184.101.188.35) |
| 2022-11-19 04:52:54 +0100 | caryhartline | (~caryhartl@107.140.218.181) (Quit: caryhartline) |
| 2022-11-19 04:55:17 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2022-11-19 05:01:21 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) (Remote host closed the connection) |
| 2022-11-19 05:02:20 +0100 | tdammers | (~tdammers@77.109.72.118.res.static.edpnet.net) (Ping timeout: 246 seconds) |
| 2022-11-19 05:02:56 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2022-11-19 05:03:29 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-11-19 05:13:20 +0100 | srz_ | (~srz@179.36.74.229) |
| 2022-11-19 05:15:38 +0100 | srz | (~srz@179.36.119.226) (Ping timeout: 256 seconds) |
| 2022-11-19 05:16:41 +0100 | tdammers | (~tdammers@77.109.72.118.res.static.edpnet.net) |
| 2022-11-19 05:17:43 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 256 seconds) |
| 2022-11-19 05:21:03 +0100 | srz_ | (~srz@179.36.74.229) (Remote host closed the connection) |
| 2022-11-19 05:25:13 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-11-19 05:33:34 +0100 | mixfix41 | (~sdeny9ee@user/mixfix41) (Ping timeout: 260 seconds) |
| 2022-11-19 05:39:46 +0100 | dextaa9 | (~DV@user/dextaa) |
| 2022-11-19 05:41:58 +0100 | dextaa | (~DV@user/dextaa) (Ping timeout: 268 seconds) |
| 2022-11-19 05:41:59 +0100 | dextaa9 | dextaa |
| 2022-11-19 05:59:02 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-19 06:00:24 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-19 06:01:22 +0100 | mvk | (~mvk@2607:fea8:5ce3:8500::efb) (Quit: Going elsewhere) |
| 2022-11-19 06:05:24 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 268 seconds) |
| 2022-11-19 06:08:16 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-11-19 06:08:40 +0100 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2022-11-19 06:21:36 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 06:26:04 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 06:28:25 +0100 | jmcantrell | (~jmcantrel@user/jmcantrell) (Quit: Reconnecting) |
| 2022-11-19 06:28:51 +0100 | jmcantrell | (~jmcantrel@user/jmcantrell) |
| 2022-11-19 06:32:24 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-11-19 06:33:05 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-11-19 06:33:43 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2022-11-19 06:36:31 +0100 | VY2 | (~user@213.24.133.139) |
| 2022-11-19 06:44:45 +0100 | razetime | (~quassel@117.193.6.219) |
| 2022-11-19 07:03:37 +0100 | mauke_ | mauke |
| 2022-11-19 07:08:53 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-19 07:11:19 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-19 07:11:20 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-19 07:11:20 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-19 07:11:48 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2022-11-19 07:14:04 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-19 07:33:20 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-19 07:36:04 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 260 seconds) |
| 2022-11-19 07:41:21 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 07:48:54 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 07:50:12 +0100 | mauke | mauke_ |
| 2022-11-19 07:50:17 +0100 | mauke_ | mauke |
| 2022-11-19 08:13:33 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) |
| 2022-11-19 08:23:41 +0100 | freeside_ | (~mengwong@103.252.202.193) |
| 2022-11-19 08:24:15 +0100 | freeside | (~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds) |
| 2022-11-19 08:32:56 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89a4:6d1:4909:326f) (Remote host closed the connection) |
| 2022-11-19 08:39:02 +0100 | Dutchgriffon | (~Laurens@70.36.53.134) (Read error: Connection reset by peer) |
| 2022-11-19 08:41:43 +0100 | bilegeek | (~bilegeek@2600:1008:b069:2ea1:a3d0:790d:f039:13b9) (Remote host closed the connection) |
| 2022-11-19 08:42:03 +0100 | bilegeek | (~bilegeek@2600:1008:b069:2ea1:a3d0:790d:f039:13b9) |
| 2022-11-19 08:42:34 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 260 seconds) |
| 2022-11-19 08:51:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-19 09:02:34 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-11-19 09:03:50 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-19 09:08:32 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-11-19 09:11:50 +0100 | VY2 | (~user@213.24.133.139) (Remote host closed the connection) |
| 2022-11-19 09:13:55 +0100 | Guest75 | (~Guest75@178.141.130.118) |
| 2022-11-19 09:15:35 +0100 | Techcable | (~Techcable@user/Techcable) (Ping timeout: 260 seconds) |
| 2022-11-19 09:16:42 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-19 09:19:48 +0100 | bilegeek | (~bilegeek@2600:1008:b069:2ea1:a3d0:790d:f039:13b9) (Quit: Leaving) |
| 2022-11-19 09:27:33 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-19 09:31:34 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-11-19 09:34:36 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) (Read error: Connection reset by peer) |
| 2022-11-19 09:34:38 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 2022-11-19 09:34:49 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-19 09:37:32 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-19 09:37:35 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-19 09:45:40 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-11-19 09:47:13 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-19 09:48:16 +0100 | acidjnk | (~acidjnk@p200300d6e7137a305cc03b10fd7a2523.dip0.t-ipconnect.de) |
| 2022-11-19 09:48:57 +0100 | phma | (phma@2001:5b0:211f:71d8:b1fb:b9c3:f43b:db91) (Read error: Connection reset by peer) |
| 2022-11-19 09:49:39 +0100 | foul_owl | (~kerry@174-21-75-230.tukw.qwest.net) (Ping timeout: 260 seconds) |
| 2022-11-19 09:49:48 +0100 | phma | (~phma@host-67-44-208-214.hnremote.net) |
| 2022-11-19 09:53:51 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-11-19 09:53:52 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Ping timeout: 256 seconds) |
| 2022-11-19 09:55:22 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-11-19 10:00:03 +0100 | RowanG[m] | (~rowang077@2001:470:69fc:105::1:ca9f) (Quit: You have been kicked for being idle) |
| 2022-11-19 10:03:17 +0100 | foul_owl | (~kerry@157.97.134.158) |
| 2022-11-19 10:05:48 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 10:07:46 +0100 | Neuromancer | (~Neuromanc@user/neuromancer) |
| 2022-11-19 10:09:12 +0100 | gmg | (~user@user/gehmehgeh) |
| 2022-11-19 10:12:23 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-19 10:14:30 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 260 seconds) |
| 2022-11-19 10:21:48 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) |
| 2022-11-19 10:26:03 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-19 10:28:40 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-11-19 10:31:50 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 240 seconds) |
| 2022-11-19 10:32:30 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-19 10:32:45 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) |
| 2022-11-19 10:34:18 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-11-19 10:35:07 +0100 | wonko | (~wjc@2a0e:1c80:2:0:45:15:19:130) (Quit: See You Space Cowboy..) |
| 2022-11-19 10:39:27 +0100 | razetime | (~quassel@117.193.6.219) (Ping timeout: 260 seconds) |
| 2022-11-19 10:39:55 +0100 | razetime | (~quassel@117.193.6.219) |
| 2022-11-19 10:41:21 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-19 10:47:31 +0100 | jargon | (~jargon@184.101.188.35) (Remote host closed the connection) |
| 2022-11-19 10:55:55 +0100 | freeside_ | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-19 10:56:08 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-19 10:56:35 +0100 | img | (~img@user/img) |
| 2022-11-19 11:10:00 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-19 11:10:22 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-19 11:10:45 +0100 | Xeroine | (~Xeroine@user/xeroine) (Ping timeout: 256 seconds) |
| 2022-11-19 11:12:50 +0100 | Xeroine | (~Xeroine@user/xeroine) |
| 2022-11-19 11:14:24 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-11-19 11:15:10 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-19 11:20:31 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 268 seconds) |
| 2022-11-19 11:22:29 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 11:25:40 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Ping timeout: 256 seconds) |
| 2022-11-19 11:26:51 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 11:27:18 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-19 11:28:40 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-11-19 11:29:00 +0100 | chomwitt | (~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1) |
| 2022-11-19 11:35:07 +0100 | acidjnk | (~acidjnk@p200300d6e7137a305cc03b10fd7a2523.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 11:38:31 +0100 | michalz | (~michalz@185.246.207.197) |
| 2022-11-19 11:43:35 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2022-11-19 11:44:22 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Ping timeout: 256 seconds) |
| 2022-11-19 11:46:18 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Quit: Konversation terminated!) |
| 2022-11-19 11:47:39 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 268 seconds) |
| 2022-11-19 11:49:00 +0100 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2022-11-19 11:53:53 +0100 | biberu | (~biberu@user/biberu) |
| 2022-11-19 11:55:23 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 11:56:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-19 11:58:10 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-19 11:59:51 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 12:00:03 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 256 seconds) |
| 2022-11-19 12:00:15 +0100 | chromoblob | (~user@37.113.164.122) |
| 2022-11-19 12:00:56 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-19 12:02:31 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 12:03:31 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-11-19 12:04:01 +0100 | Vajb | (~Vajb@2001:999:504:3ad6:52a4:a3b5:32d8:e74d) |
| 2022-11-19 12:04:26 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-19 12:05:38 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-11-19 12:06:03 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-19 12:06:21 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) |
| 2022-11-19 12:08:27 +0100 | money | Guest1295 |
| 2022-11-19 12:09:34 +0100 | acidjnk | (~acidjnk@p200300d6e7137a3011d75adc93e5c26c.dip0.t-ipconnect.de) |
| 2022-11-19 12:11:10 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) (Ping timeout: 260 seconds) |
| 2022-11-19 12:15:02 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2022-11-19 12:15:40 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 12:16:55 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-19 12:17:26 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 12:20:20 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Remote host closed the connection) |
| 2022-11-19 12:29:12 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 12:29:45 +0100 | sagex | (~sagex@2600:1700:42d8:4530:2ef0:5dff:fede:e8) |
| 2022-11-19 12:30:16 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-19 12:30:56 +0100 | haskl | (~haskl@user/haskl) (Read error: Connection reset by peer) |
| 2022-11-19 12:33:03 +0100 | haskl | (~haskl@user/haskl) |
| 2022-11-19 12:33:55 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-19 12:34:44 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 248 seconds) |
| 2022-11-19 12:34:44 +0100 | AlexZenon | (~alzenon@178.34.161.167) (Ping timeout: 260 seconds) |
| 2022-11-19 12:37:05 +0100 | AlexZenon | (~alzenon@178.34.161.167) |
| 2022-11-19 12:46:34 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 12:46:51 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Ping timeout: 260 seconds) |
| 2022-11-19 12:48:45 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-19 12:52:48 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-19 12:54:16 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-11-19 12:55:55 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-11-19 12:58:49 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2022-11-19 13:04:00 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 13:05:58 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Ping timeout: 268 seconds) |
| 2022-11-19 13:12:04 +0100 | marc__ | (~marc@5.83.191.214) (Ping timeout: 260 seconds) |
| 2022-11-19 13:12:46 +0100 | acidjnk | (~acidjnk@p200300d6e7137a3011d75adc93e5c26c.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 13:16:36 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-11-19 13:16:58 +0100 | Guest75 | (~Guest75@178.141.130.118) (Ping timeout: 260 seconds) |
| 2022-11-19 13:18:34 +0100 | marc__ | (~marc@5.83.191.214) |
| 2022-11-19 13:21:05 +0100 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-11-19 13:24:16 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-19 13:25:58 +0100 | acidjnk | (~acidjnk@p200300d6e7137a3011d75adc93e5c26c.dip0.t-ipconnect.de) |
| 2022-11-19 13:31:08 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-19 13:35:08 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) |
| 2022-11-19 13:36:11 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 268 seconds) |
| 2022-11-19 13:42:27 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2022-11-19 13:42:38 +0100 | mmhat | (~mmh@p200300f1c704687fee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-19 13:45:17 +0100 | kuribas | (~user@ptr-17d51enw7vbqv4wetdn.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2022-11-19 13:47:38 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-11-19 13:53:30 +0100 | goepsilongo | (~goepsilon@2603-7000-ab00-00e5-392a-bca4-733f-bcd4.res6.spectrum.com) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-11-19 13:53:54 +0100 | goepsilongo | (~goepsilon@2603-7000-ab00-00e5-4167-a449-9ece-260f.res6.spectrum.com) |
| 2022-11-19 13:54:44 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Quit: Leaving.) |
| 2022-11-19 14:08:02 +0100 | fockerize | (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) |
| 2022-11-19 14:08:04 +0100 | Techcable | (~Techcable@user/Techcable) |
| 2022-11-19 14:08:15 +0100 | razetime | (~quassel@117.193.6.219) (Ping timeout: 268 seconds) |
| 2022-11-19 14:13:01 +0100 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-19 14:16:06 +0100 | img | (~img@user/img) |
| 2022-11-19 14:18:19 +0100 | acidjnk | (~acidjnk@p200300d6e7137a3011d75adc93e5c26c.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 14:21:08 +0100 | razetime | (~quassel@117.193.3.223) |
| 2022-11-19 14:29:14 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 268 seconds) |
| 2022-11-19 14:36:10 +0100 | xff0x | (~xff0x@ai071162.d.east.v6connect.net) |
| 2022-11-19 14:42:40 +0100 | <WarzoneCommand> | is there an easy way to make GHC monomorphize a function and all of its dependant functions? More concretely, I have some function like "convexHull :: IsAPoint point => [point] -> Polygon point" , but the polymorphic version is about 50 times slower than when I manually monomorphize it to something like convexHull :: [Point Int] -> Polygon (Point Int). I kind of want the compiler to do that for |
| 2022-11-19 14:42:46 +0100 | <WarzoneCommand> | me.... |
| 2022-11-19 14:43:24 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-11-19 14:43:47 +0100 | <Axman6> | add specialise pragmas |
| 2022-11-19 14:43:54 +0100 | <WarzoneCommand> | the only things that I can somehow think of are: 1) use backpack for all of this stuff (but that seems like a bit of a hassle in itself), or 2) put a specialize pragma in the module in which I've implemented convexHull (that only partially works though) |
| 2022-11-19 14:44:34 +0100 | <WarzoneCommand> | moreover, I can't put the specialize pragma in the "clients" module, so I would have to guess all interesting definitions for 'point' |
| 2022-11-19 14:44:36 +0100 | <Axman6> | or specialisable... I think that's a thing... |
| 2022-11-19 14:44:44 +0100 | <tomsmeding> | SPECIALIZE |
| 2022-11-19 14:44:54 +0100 | <Axman6> | but spelt correctly |
| 2022-11-19 14:45:08 +0100 | <tomsmeding> | well, your spelling was more correct, but unfortunately ghc wants american spelling :p |
| 2022-11-19 14:45:22 +0100 | <Axman6> | i believe it supports both? |
| 2022-11-19 14:45:52 +0100 | <tomsmeding> | ooh |
| 2022-11-19 14:45:52 +0100 | <mauke> | "(UK spelling also accepted.)" |
| 2022-11-19 14:45:53 +0100 | <WarzoneCommand> | for specialize supposedly one can also use the british spelling :P |
| 2022-11-19 14:46:00 +0100 | <tomsmeding> | seems to work |
| 2022-11-19 14:46:17 +0100 | <mauke> | it doesn't have to be in the same module |
| 2022-11-19 14:46:18 +0100 | <WarzoneCommand> | seems specializable is not a thing yet (https://gitlab.haskell.org/ghc/ghc/-/issues/12463 ?) |
| 2022-11-19 14:46:37 +0100 | <mauke> | "Moreover, you can also SPECIALIZE an imported function provided it was given an INLINABLE pragma at its definition site" |
| 2022-11-19 14:47:10 +0100 | fockerize | (~finn@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 240 seconds) |
| 2022-11-19 14:47:54 +0100 | <WarzoneCommand> | mauke: I think that I will have to add inlinable pragamas on pretty much everything; only adding it to the main "convexHull" function does not seem to help |
| 2022-11-19 14:48:27 +0100 | <mauke> | yeah, probably |
| 2022-11-19 14:48:42 +0100 | <WarzoneCommand> | that seems fairly annoying and/or error prone :( |
| 2022-11-19 14:53:55 +0100 | Lycurgus | (~juan@user/Lycurgus) |
| 2022-11-19 14:53:59 +0100 | <WarzoneCommand> | hmm this is really weird |
| 2022-11-19 14:55:49 +0100 | <Lycurgus> | convex hull, and you doin linear program or branch and bound or sthn? |
| 2022-11-19 14:55:50 +0100 | <WarzoneCommand> | if I put the SPECIALZE convexHull :: [Point Int] -> .." pragma in my module that implements convex hull, I get the speedup I expect. But even if I make everything in that module inlinable (but not in modules imported by my convex-hull implementation module) and put the specialize pragma instead at the client module, it does not work |
| 2022-11-19 14:55:56 +0100 | <Lycurgus> | *are you |
| 2022-11-19 14:56:10 +0100 | <Lycurgus> | *programming |
| 2022-11-19 14:56:37 +0100 | <WarzoneCommand> | I'm maintaining a library doing all sorts of geometric algorithms |
| 2022-11-19 14:56:42 +0100 | <Lycurgus> | ah |
| 2022-11-19 14:57:03 +0100 | <Lycurgus> | that kind of convexity |
| 2022-11-19 14:57:24 +0100 | <WarzoneCommand> | it's the same type of convexity you encounter when doing linear programming ;) |
| 2022-11-19 14:58:01 +0100 | <Lycurgus> | yeah, conceotually |
| 2022-11-19 14:58:10 +0100 | <Lycurgus> | *conceptually |
| 2022-11-19 15:02:15 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 15:06:07 +0100 | acidjnk | (~acidjnk@p200300d6e7137a4619037b2a1cfeb60c.dip0.t-ipconnect.de) |
| 2022-11-19 15:11:53 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-19 15:14:09 +0100 | <WarzoneCommand> | Oh, awesome, apparently there is -fspecialise-aggressively -fexpose-all-unfoldings . Compiling my libraries/benchmarks with those options seems to achieve the running time performance that I want |
| 2022-11-19 15:16:52 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-11-19 15:17:04 +0100 | <Hecate> | tomsmeding: ping! wanna see a magic trick? |
| 2022-11-19 15:23:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-11-19 15:25:26 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-11-19 15:27:17 +0100 | coot | (~coot@213.134.171.3) (Quit: coot) |
| 2022-11-19 15:27:24 +0100 | Axman6 | wants to see a magic trick |
| 2022-11-19 15:31:37 +0100 | Rembane | too |
| 2022-11-19 15:33:52 +0100 | acidjnk | (~acidjnk@p200300d6e7137a4619037b2a1cfeb60c.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 15:36:10 +0100 | <codedmart> | If I have `newtype SomeThing (n1 :: Symbol) i1 (n2 :: Symbol) i2 a = Something { unSomeThing :: a }` can that be made variadic? Where I can have 2 or 3 iN arguments? |
| 2022-11-19 15:40:19 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-19 15:43:49 +0100 | <[Leary]> | codedmart: `newtype SomeThing (nis :: [(Symbol, k)]) a`? So long as the `i`s are homogeneous. I doubt there's a sane way if they aren't. |
| 2022-11-19 15:44:54 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 260 seconds) |
| 2022-11-19 15:45:08 +0100 | beteigeuze | (~Thunderbi@bl14-81-220.dsl.telepac.pt) |
| 2022-11-19 15:46:57 +0100 | elevenkb | (~elevenkb@105.184.125.168) |
| 2022-11-19 15:47:33 +0100 | Guest1295 | money |
| 2022-11-19 15:47:51 +0100 | mmhat | (~mmh@p200300f1c704687fee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 15:57:21 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt https://tinyurl.com/4m8d4kd5) |
| 2022-11-19 15:58:14 +0100 | coot | (~coot@213.134.171.3) |
| 2022-11-19 15:58:19 +0100 | <codedmart> | @[Leary] ok cool I guess a more concrete example that I am unsure how to do is something like this: https://gist.github.com/codedmart/21769ea29d914032492e4954d771528d |
| 2022-11-19 15:58:19 +0100 | <lambdabot> | Unknown command, try @list |
| 2022-11-19 15:59:02 +0100 | <codedmart> | I am not sure how you would handle the instance with `nis`'s |
| 2022-11-19 15:59:36 +0100 | coot | (~coot@213.134.171.3) (Client Quit) |
| 2022-11-19 16:00:02 +0100 | <c_wraith> | what would it even mean for that to be variadic? |
| 2022-11-19 16:00:07 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-19 16:00:39 +0100 | <[Leary]> | codedmart: Recurse. It's a list, so assume you have the instance for the tail at hand and use it. |
| 2022-11-19 16:00:43 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) () |
| 2022-11-19 16:01:27 +0100 | mmhat | (~mmh@p200300f1c72dc6c9ee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-11-19 16:02:25 +0100 | <[Leary]> | You might need some auxiliary type families or classes for the constraints too. |
| 2022-11-19 16:02:33 +0100 | <money> | yeah |
| 2022-11-19 16:02:34 +0100 | <money> | asap |
| 2022-11-19 16:03:17 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-11-19 16:10:55 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-19 16:13:22 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 16:14:03 +0100 | <codedmart> | c_wraith All I am really after is trying to be able to use `SomeThing` with either `(n1 :: Symbol) i1 (n2 :: Symbol) i2 a` or `(n1 :: Symbol) i1 (n2 :: Symbol) i2 (n3 :: Symbol) i3 a` |
| 2022-11-19 16:14:18 +0100 | <c_wraith> | right. what does that even mean? |
| 2022-11-19 16:14:22 +0100 | <codedmart> | Just trying to mess around with somethings and expand my understanding. |
| 2022-11-19 16:14:41 +0100 | <c_wraith> | types exist only at compile time |
| 2022-11-19 16:14:57 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-11-19 16:15:14 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-11-19 16:20:29 +0100 | fr33domlover | (~fr33domlo@towards.vision) |
| 2022-11-19 16:20:54 +0100 | razetime | (~quassel@117.193.3.223) (Ping timeout: 256 seconds) |
| 2022-11-19 16:24:45 +0100 | <codedmart> | c_wraith This isn't really anything useful. So what does it even mean? Good question. As I was messing around with `SomeThing` that took 2 symbols, 2 ids, and a type. I was wondering what it would look like to see if I could make that take either 2 or 3. So if I called `mkMyId` I would end up with either `(1, 2)` or `(1, 2, 3)`. |
| 2022-11-19 16:25:19 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-11-19 16:25:44 +0100 | <codedmart> | @[Leary] I am not really sure I understand what you mean by "It's a list, so assume you have the instance for the tail at hand and use it." |
| 2022-11-19 16:25:44 +0100 | <lambdabot> | Unknown command, try @list |
| 2022-11-19 16:26:07 +0100 | yuribarros_ | (~Srain@189.6.35.188) |
| 2022-11-19 16:27:02 +0100 | <yuribarros_> | Hi everyone |
| 2022-11-19 16:27:11 +0100 | <yuribarros_> | Is this a place for a beginner Cabal question? |
| 2022-11-19 16:27:17 +0100 | <geekosaur> | yes |
| 2022-11-19 16:28:36 +0100 | razetime | (~quassel@117.193.6.219) |
| 2022-11-19 16:29:15 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-19 16:35:01 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-19 16:35:20 +0100 | <[Leary]> | codedmart: It's the same as value-level recursion on a list, but in constraints. First write the base case: `instance (...) => MyId (Something '[] a) where {...}`, then recurse: `instance (MyId (Something nis a), ...) => MyId (Something ('(n,i):nis) a) where {...}`. |
| 2022-11-19 16:36:05 +0100 | elevenkb | (~elevenkb@105.184.125.168) (Remote host closed the connection) |
| 2022-11-19 16:36:22 +0100 | Lumia | (~Lumia@user/Lumia) |
| 2022-11-19 16:37:10 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds) |
| 2022-11-19 16:38:21 +0100 | <yuribarros_> | I am trying to add a lib that implements the bindings of a C program called GDAL, and I am trying to add it to my cabal.project: |
| 2022-11-19 16:38:37 +0100 | <yuribarros_> | ``` |
| 2022-11-19 16:38:40 +0100 | <yuribarros_> | packages: . |
| 2022-11-19 16:38:40 +0100 | <yuribarros_> | source-repository-package |
| 2022-11-19 16:38:41 +0100 | <yuribarros_> | type: git |
| 2022-11-19 16:38:41 +0100 | <yuribarros_> | location: https://github.com/albertov/bindings-gdal |
| 2022-11-19 16:38:41 +0100 | <yuribarros_> | tag: 331a6e28d3b310d2cf595d8cf5112db1a7f45a88 |
| 2022-11-19 16:38:41 +0100 | <yuribarros_> | subdir: bindings-gdal |
| 2022-11-19 16:38:43 +0100 | <yuribarros_> | ``` |
| 2022-11-19 16:39:04 +0100 | <yuribarros_> | This is the whole cabal.project |
| 2022-11-19 16:39:19 +0100 | <yuribarros_> | But when I run cabal install, it gives: |
| 2022-11-19 16:39:35 +0100 | <yuribarros_> | dist-newstyle/src/bindings-_-37db898ef890c9a9/bindings-gdal: getDirectoryContents:openDirStream: does not exist (No such file or directory) |
| 2022-11-19 16:39:42 +0100 | <yuribarros_> | What could this be? |
| 2022-11-19 16:40:10 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-19 16:40:17 +0100 | <sclv> | you should not set a subdir |
| 2022-11-19 16:40:30 +0100 | <sclv> | the package is in the main dir of the tepot |
| 2022-11-19 16:40:35 +0100 | <sclv> | er repo |
| 2022-11-19 16:42:23 +0100 | <yuribarros_> | Thanks, I misunderstood the meaning of subdir. This worked. |
| 2022-11-19 16:43:00 +0100 | bobbingbob | (~bobbingbo@2604:3d09:207f:f650::b469) |
| 2022-11-19 16:47:32 +0100 | Lumia | (~Lumia@user/Lumia) (Ping timeout: 248 seconds) |
| 2022-11-19 16:49:40 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-11-19 16:51:29 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-11-19 16:53:38 +0100 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-11-19 16:56:32 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-11-19 16:58:48 +0100 | califax | (~califax@user/califx) |
| 2022-11-19 16:59:50 +0100 | Lumia | (~Lumia@user/Lumia) |
| 2022-11-19 17:00:30 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-19 17:01:36 +0100 | <tomsmeding> | Hecate: yes! |
| 2022-11-19 17:01:53 +0100 | <codedmart> | @[Leary] OK appreciate the help. A little bit further, but still not sure where to look for answers https://gist.github.com/codedmart/21769ea29d914032492e4954d771528d#file-main-hs-L44-L45 |
| 2022-11-19 17:01:53 +0100 | <lambdabot> | Unknown command, try @list |
| 2022-11-19 17:10:25 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) |
| 2022-11-19 17:10:52 +0100 | chovelyoukai | (~Lumia@user/Lumia) |
| 2022-11-19 17:13:11 +0100 | <[Leary]> | codedmart: You can do the same as you did above for the `n` and the `i`, but now you want to combine them into the type and method you get from the tail instance. Tupling them together would be the simplest option. |
| 2022-11-19 17:13:32 +0100 | <money> | Sounds good |
| 2022-11-19 17:14:10 +0100 | Lumia | (~Lumia@user/Lumia) (Ping timeout: 256 seconds) |
| 2022-11-19 17:15:04 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) (Ping timeout: 252 seconds) |
| 2022-11-19 17:15:12 +0100 | acidjnk | (~acidjnk@p200300d6e7137a4619037b2a1cfeb60c.dip0.t-ipconnect.de) |
| 2022-11-19 17:15:45 +0100 | kenran | (~user@user/kenran) |
| 2022-11-19 17:16:28 +0100 | <codedmart> | [Leary] the tail instance is `names` right? But names is not destructured. It is still `[(Symbol, i)]` |
| 2022-11-19 17:17:07 +0100 | <Hecate> | tomsmeding: https://github.com/Kleidukos/get-tested/ |
| 2022-11-19 17:18:18 +0100 | Digit | (~user@user/digit) |
| 2022-11-19 17:18:31 +0100 | <tomsmeding> | that looks useful for people using haskell in CI |
| 2022-11-19 17:18:35 +0100 | <tomsmeding> | which is not me, currently :p |
| 2022-11-19 17:19:49 +0100 | <tomsmeding> | Hecate: why the versionList? |
| 2022-11-19 17:19:59 +0100 | <tomsmeding> | things that GH Actions has images for? |
| 2022-11-19 17:21:39 +0100 | <Hecate> | tomsmeding: It's the list of GHC versions that the Haskell GH Action officially supports |
| 2022-11-19 17:21:44 +0100 | chovelyoukai | (~Lumia@user/Lumia) (Ping timeout: 260 seconds) |
| 2022-11-19 17:21:53 +0100 | <Hecate> | but maybe I'm mis-understanding your question |
| 2022-11-19 17:22:04 +0100 | <tomsmeding> | you didn't :) |
| 2022-11-19 17:23:41 +0100 | <[Leary]> | codedmart: Hm? The only destructuring you need is the "pattern match" you're already doing in the instance heads. The instance on the tail makes `UniqueIdentity (SomethingV nis a)` and `mkMyId :: SomethingV nis a -> _` directly available, you just need to use them. |
| 2022-11-19 17:25:28 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-11-19 17:28:43 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 256 seconds) |
| 2022-11-19 17:31:54 +0100 | chovelyoukai | (~Lumia@user/Lumia) |
| 2022-11-19 17:31:55 +0100 | <fgaz> | Hecate: re https://merveilles.town/@hecate/109371325444699866 I had sourcehut and/or nix in mind |
| 2022-11-19 17:32:31 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2022-11-19 17:33:10 +0100 | <fgaz> | I actually tried to get sourcehut support in haskell-ci, but my pr didn't get much attention https://github.com/haskell-CI/haskell-ci/pull/563 |
| 2022-11-19 17:33:52 +0100 | <Hecate> | fgaz: if Sourcehut's CI can get configuration dynamically at runtime, PR welcome on get-tested |
| 2022-11-19 17:37:01 +0100 | <fgaz> | it can't. well, a job can technically submit other jobs through a token but I'd rather not do that. but sequential jobs would be fine by me, hence the shell array |
| 2022-11-19 17:39:40 +0100 | euandreh | (~Thunderbi@179.214.113.107) (Ping timeout: 256 seconds) |
| 2022-11-19 17:41:20 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2022-11-19 17:41:36 +0100 | ddellacosta | (~ddellacos@89.45.224.202) |
| 2022-11-19 17:46:32 +0100 | <WarzoneCommand> | hmm, does anyone know why I have to explicitly provide the Coercible (F a result d) (F b result' d) here? I would think/hope ghc could derrive that from the other ones: https://paste.tomsmeding.com/QbfDddDO |
| 2022-11-19 17:47:02 +0100 | ddellacosta | (~ddellacos@89.45.224.202) (Ping timeout: 256 seconds) |
| 2022-11-19 17:47:16 +0100 | <tomsmeding> | Coercibility of the type parameters of a data type doesn't necessarily imply that the data type itself can be coerced |
| 2022-11-19 17:47:22 +0100 | <tomsmeding> | this has to do with _roles_ |
| 2022-11-19 17:47:32 +0100 | <c_wraith> | roles don't even apply here. That's a type family |
| 2022-11-19 17:47:41 +0100 | <c_wraith> | type families can do anything |
| 2022-11-19 17:47:55 +0100 | <tomsmeding> | yeah, point being that for normal ADTs, the roles are such that this can indeed be inferred |
| 2022-11-19 17:48:17 +0100 | <tomsmeding> | but one can specify something different for a data type, and type families can yield anything, so ghc can't assume the roles are right |
| 2022-11-19 17:48:19 +0100 | <WarzoneCommand> | sure, but I've provided the type family above; it is just a function here. I.e. can I get GHC to somehow expand the def of F before checking here? |
| 2022-11-19 17:48:42 +0100 | <tomsmeding> | it's not a function if d is zero, right? |
| 2022-11-19 17:48:57 +0100 | ddellacosta | (~ddellacos@143.244.47.100) |
| 2022-11-19 17:49:06 +0100 | <tomsmeding> | though I guess then the result->result' constraint would work |
| 2022-11-19 17:49:17 +0100 | <c_wraith> | GHC doesn't make any real use of the fact that type families are closed |
| 2022-11-19 17:49:38 +0100 | <tomsmeding> | also it would have to do induction in this case, even if it did unfold and try case analysis :p |
| 2022-11-19 17:49:43 +0100 | causal | (~user@50.35.83.177) |
| 2022-11-19 17:49:52 +0100 | <c_wraith> | It still treats them as if they're open in every way except that it prevents adding new instances |
| 2022-11-19 17:50:06 +0100 | <WarzoneCommand> | hmm, fair enough at the induction part I guess |
| 2022-11-19 17:50:30 +0100 | <WarzoneCommand> | hmm, that is kind of a shame I guess |
| 2022-11-19 17:50:49 +0100 | <tomsmeding> | even if it did consider closedness of the TyFam in these cases, it can't just go case-analysis on anything because that might explode combinatorially in exponentially many cases to check |
| 2022-11-19 17:51:49 +0100 | <WarzoneCommand> | that statement is kind of vague. |
| 2022-11-19 17:52:49 +0100 | <tomsmeding> | you can construct a sequence of n type families for which your situation holds (i.e. the roles end up being right for coercibility -- I forget which role that is exactly), but where proving that requires exploring 2^n possible instantiations of type variables |
| 2022-11-19 17:53:07 +0100 | <tomsmeding> | though I guess one could say that ghc should just explore up to a certain depth or time limit |
| 2022-11-19 17:53:10 +0100 | <WarzoneCommand> | also, I'm not sure I would buy that argument; i.e. I don't think the compiler should try to outsmart me on that; even if I wrote s.t. that requires expanding exponentially many cases I would like GHC to just do that rather than refuse because it may have been more expensive than it thinks I may have anticipated |
| 2022-11-19 17:55:28 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-11-19 17:56:53 +0100 | <WarzoneCommand> | anyway; I guess I'll just use the explicit constraint, and hope it doesn't leak out too far into my API |
| 2022-11-19 17:57:50 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 240 seconds) |
| 2022-11-19 18:00:51 +0100 | <maralorn> | How does ghc profiling interact with lazyness? Will the time spent while calculating a thunk be attributed to the function which forced the thunk or the function which defined that thunk? |
| 2022-11-19 18:01:29 +0100 | <geekosaur> | the former |
| 2022-11-19 18:02:22 +0100 | <maralorn> | Are you sure? |
| 2022-11-19 18:03:07 +0100 | <geekosaur> | it's not uncommon that all your time spent ends up in the function which prints the result |
| 2022-11-19 18:03:58 +0100 | <maralorn> | kk |
| 2022-11-19 18:04:08 +0100 | yuribarros | (~yuribarro@2804:14c:65e4:865c::1000) |
| 2022-11-19 18:04:33 +0100 | <codedmart> | [Leary] does this look like I am getting closer? Still a bit unsure on the last ??? if I have the rest right. |
| 2022-11-19 18:04:39 +0100 | yuribarros | (~yuribarro@2804:14c:65e4:865c::1000) () |
| 2022-11-19 18:05:05 +0100 | <codedmart> | And maybe tuple is wrong here? Should I do a list? |
| 2022-11-19 18:05:42 +0100 | <geekosaur> | I mean, it's not like the time is directly attributed to printing; it will be clear that your thunks are getting forced at that point, as the time will be attributed to your thunk but as part of the total time for the I/O |
| 2022-11-19 18:11:46 +0100 | yuribarros_ | (~Srain@189.6.35.188) (Quit: yuribarros_) |
| 2022-11-19 18:12:01 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 18:12:29 +0100 | yuribarros | (~Srain@189.6.35.188) |
| 2022-11-19 18:16:14 +0100 | mmhat | (~mmh@p200300f1c72dc6c9ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.7.1) |
| 2022-11-19 18:16:46 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-19 18:20:37 +0100 | <[Leary]> | codedmart: Yes, you are. For the last ???, you just need to give `mkMyId` a `SomethingV nis a`. Since `nis` is phantom, you can make one of those with the `a` you have on hand. |
| 2022-11-19 18:20:51 +0100 | acidjnk | (~acidjnk@p200300d6e7137a4619037b2a1cfeb60c.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-11-19 18:22:08 +0100 | <codedmart> | [Leary] It isn't this is it: mkMyId (SomeThingV a) = (getField @n a, SomeThingV a)? |
| 2022-11-19 18:22:47 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-11-19 18:26:59 +0100 | <[Leary]> | You need to apply the `mkMyId` from the tail, and be sure it's used at the right type. |
| 2022-11-19 18:27:06 +0100 | denh^ | (~denl@76.145.185.103) (Remote host closed the connection) |
| 2022-11-19 18:27:56 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-11-19 18:28:16 +0100 | <[Leary]> | Re tuples, I would make the type a type-level list, and the function's return value an HList---that would provide better utility. But it isn't necessary for this example. |
| 2022-11-19 18:30:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-11-19 18:30:02 +0100 | <codedmart> | I am still confused here "`mkMyId` from the tail, and be sure it's used at the right type." nis is the tail right? |
| 2022-11-19 18:30:07 +0100 | <codedmart> | call mkMyId on nis? |
| 2022-11-19 18:33:12 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 18:33:49 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2022-11-19 18:34:50 +0100 | razetime | (~quassel@117.193.6.219) (Remote host closed the connection) |
| 2022-11-19 18:36:45 +0100 | sagex | (~sagex@2600:1700:42d8:4530:2ef0:5dff:fede:e8) (Ping timeout: 260 seconds) |
| 2022-11-19 18:37:42 +0100 | <codedmart> | [Leary] I tried `mkMyId (SomeThingV a) = (getField @n a, mkMyId names)` but that is an illegal term-level use. |
| 2022-11-19 18:37:48 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-19 18:38:19 +0100 | <codedmart> | I am definitely missing some minor concepts here... |
| 2022-11-19 18:39:50 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 18:40:15 +0100 | <[Leary]> | I'm saying you need to recurse here, using the `mkMyId` from the "previous"/"smaller"/"tail" step/instance on the RHS. That means using it /at/ the `nis` type. Maybe reread what I wrote a bit earlier? I don't know how to make this clearer without just giving you the answer. |
| 2022-11-19 18:40:31 +0100 | <[Leary]> | In any case, I'm done for the day, so you'll have to figure it out without me. |
| 2022-11-19 18:40:57 +0100 | <codedmart> | [Leary] Thanks for your help! |
| 2022-11-19 18:41:50 +0100 | srz | (~srz@181.228.49.93) |
| 2022-11-19 18:51:04 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 256 seconds) |
| 2022-11-19 18:52:46 +0100 | cheater | (~Username@user/cheater) |
| 2022-11-19 18:58:45 +0100 | acidjnk | (~acidjnk@p200300d6e7137a4619037b2a1cfeb60c.dip0.t-ipconnect.de) |
| 2022-11-19 19:04:42 +0100 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-19 19:06:34 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 19:08:12 +0100 | dolio | (~dolio@130.44.134.54) |
| 2022-11-19 19:09:13 +0100 | finsternis | (~X@23.226.237.192) |
| 2022-11-19 19:10:33 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-11-19 19:11:50 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 240 seconds) |
| 2022-11-19 19:13:22 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-19 19:13:52 +0100 | econo | (uid147250@user/econo) |
| 2022-11-19 19:14:59 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 19:17:43 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-11-19 19:17:56 +0100 | <maralorn> | geekosaur: I am looking at the eventlog visualisation with speedscope. |
| 2022-11-19 19:17:57 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Quit: Leaving.) |
| 2022-11-19 19:18:24 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-19 19:18:27 +0100 | <maralorn> | Related I am running: cabal build --ghc-option=-ddump-file-prefix=DUMP --ghc-option=-ddump-to-file --ghc-option=-ddump-simpl, but ghc is dumping the core to stdout and doesn‘t create the file. What am I doing wrong? |
| 2022-11-19 19:21:30 +0100 | <geekosaur> | I thought cabal itself used/overrode some of the dump stuff, although I may be wrong or out of date on that |
| 2022-11-19 19:23:46 +0100 | euandreh | (~Thunderbi@179.214.113.107) |
| 2022-11-19 19:24:03 +0100 | dsrt^ | (~dsrt@76.145.185.103) |
| 2022-11-19 19:25:22 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2022-11-19 19:25:41 +0100 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-11-19 19:26:38 +0100 | AlexNoo_ | (~AlexNoo@178.34.162.26) |
| 2022-11-19 19:26:44 +0100 | dolio | (~dolio@130.44.134.54) |
| 2022-11-19 19:27:52 +0100 | <maralorn> | Well, I have to admit looking at the core doesn’t illuminate me either way. |
| 2022-11-19 19:28:51 +0100 | Alex_test | (~al_test@178.34.161.167) (Ping timeout: 256 seconds) |
| 2022-11-19 19:29:32 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-11-19 19:29:36 +0100 | AlexZenon | (~alzenon@178.34.161.167) (Ping timeout: 256 seconds) |
| 2022-11-19 19:30:10 +0100 | AlexNoo | (~AlexNoo@178.34.161.167) (Ping timeout: 256 seconds) |
| 2022-11-19 19:30:33 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-19 19:34:11 +0100 | Alex_test | (~al_test@178.34.162.26) |
| 2022-11-19 19:34:17 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-19 19:35:00 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 248 seconds) |
| 2022-11-19 19:35:02 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-19 19:35:48 +0100 | <maralorn> | I have done a supposedly benign small refactor and my program performance went down by a factor of 7. I have no clue what’s wrong. Profiling tells me I am loosing 80% of the time in a previously very fast function, which I didn’t touch in the refactor. |
| 2022-11-19 19:36:12 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 19:36:23 +0100 | <c_wraith> | high chance you're passing something unevaluated to those functions now, whereas previously you were passing them something evaluated. |
| 2022-11-19 19:36:48 +0100 | <maralorn> | So all of this seems like a laziness problem, but I am using -XStrict and I have looked really hard at the code and everything should be evaluated … |
| 2022-11-19 19:37:00 +0100 | <c_wraith> | Though there are other potential culprits, like adding a new module boundary and losing specialization because of it |
| 2022-11-19 19:37:28 +0100 | <c_wraith> | -XStrict is a lie and shouldn't be used. :P |
| 2022-11-19 19:37:37 +0100 | AlexZenon | (~alzenon@178.34.162.26) |
| 2022-11-19 19:38:02 +0100 | <maralorn> | I am very certain I know what -XStrict does, and I want my program to do what it does. |
| 2022-11-19 19:38:17 +0100 | <c_wraith> | But it doesn't prevent building up nested thunks, which is most of my point |
| 2022-11-19 19:38:25 +0100 | <maralorn> | But apparently it’s not strict enough.^^ |
| 2022-11-19 19:38:37 +0100 | <c_wraith> | Ah, then you *don't* know what it does! |
| 2022-11-19 19:40:52 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 248 seconds) |
| 2022-11-19 19:45:20 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-11-19 19:45:52 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-11-19 19:47:12 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 255 seconds) |
| 2022-11-19 19:49:09 +0100 | <monochrom> | Tautology pro tip: If the computer doesn't do what you think, then you don't know what it does. |
| 2022-11-19 19:49:54 +0100 | <monochrom> | Or in general s/the computer/objective reality/ |
| 2022-11-19 19:51:34 +0100 | <c_wraith> | -XStrict really is a lot less magical than people think. It's easier to just use space invariants correctly than it is to get correct behavior using -XStrict if you don't know how to reason with space invariants. |
| 2022-11-19 19:56:00 +0100 | <davean> | -XStrict should generally hurt performance. |
| 2022-11-19 19:56:08 +0100 | <davean> | If it doesn't your code is probably terrible |
| 2022-11-19 19:56:24 +0100 | <monochrom> | :) |
| 2022-11-19 19:56:41 +0100 | <EvanR> | so your code is either terrible or slow |
| 2022-11-19 19:56:57 +0100 | <davean> | EvanR: hum? XStrict slows down code |
| 2022-11-19 19:57:52 +0100 | <EvanR> | I guess that's why they didn't call it -XFast |
| 2022-11-19 19:58:08 +0100 | <monochrom> | Therefore, by or-introduction, the code is terrible or slow, as said. :) |
| 2022-11-19 19:59:37 +0100 | AlexNoo_ | AlexNoo |
| 2022-11-19 20:00:22 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2022-11-19 20:06:15 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-11-19 20:09:57 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-19 20:11:57 +0100 | <tomsmeding> | maralorn: rnf the inputs to that function and check how much time you're losing to rnf? |
| 2022-11-19 20:15:59 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 20:20:24 +0100 | loonycyborg_ | (loonycybor@chat.chantal.wesnoth.org) (Quit: ZNC - http://znc.sourceforge.net) |
| 2022-11-19 20:20:48 +0100 | loonycyborg | (loonycybor@wesnoth/developer/loonycyborg) |
| 2022-11-19 20:21:45 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-19 20:25:17 +0100 | Guest7132 | (~Guest71@ext-1-450.eduroam.chalmers.se) |
| 2022-11-19 20:27:36 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-11-19 20:29:21 +0100 | kenran | (~user@user/kenran) |
| 2022-11-19 20:29:26 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2022-11-19 20:30:09 +0100 | hnOsmium0001 | (uid453710@user/hnOsmium0001) (Quit: Connection closed for inactivity) |
| 2022-11-19 20:33:23 +0100 | LemanR | (~LemanR@pool-74-109-28-147.phlapa.fios.verizon.net) |
| 2022-11-19 20:33:40 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2022-11-19 20:33:41 +0100 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2022-11-19 20:33:41 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-19 20:34:16 +0100 | LemanR | (~LemanR@pool-74-109-28-147.phlapa.fios.verizon.net) (Client Quit) |
| 2022-11-19 20:35:50 +0100 | chovelyoukai | (~Lumia@user/Lumia) (Remote host closed the connection) |
| 2022-11-19 20:36:15 +0100 | chovelyoukai | (~Lumia@user/Lumia) |
| 2022-11-19 20:37:48 +0100 | Guest7132 | (~Guest71@ext-1-450.eduroam.chalmers.se) (Quit: Client closed) |
| 2022-11-19 20:38:36 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-11-19 20:38:45 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 20:40:42 +0100 | <Guillaum[m]> | Do you know which lens operator I can use to `over` but with a monadic context? I would like to apply a function on all the "targets" of a lens/traversal, but threading a monadic context (actually, an evaluation cache which can optimise the operation). |
| 2022-11-19 20:41:59 +0100 | fr33domlover | (~fr33domlo@towards.vision) (Quit: The Lounge - https://thelounge.chat) |
| 2022-11-19 20:42:29 +0100 | <c_wraith> | Guillaum[m]: technically... id does the job. Lens provides it with several names, like %%~ |
| 2022-11-19 20:42:51 +0100 | <c_wraith> | :t (%%~) |
| 2022-11-19 20:42:52 +0100 | <lambdabot> | forall k (f :: k -> *) s (t :: k) a (b :: k). LensLike f s t a b -> (a -> f b) -> s -> f t |
| 2022-11-19 20:43:04 +0100 | <c_wraith> | :t mapMOf |
| 2022-11-19 20:43:05 +0100 | <lambdabot> | LensLike (WrappedMonad m) s t a b -> (a -> m b) -> s -> m t |
| 2022-11-19 20:43:20 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-19 20:44:04 +0100 | fr33domlover | (~fr33domlo@towards.vision) |
| 2022-11-19 20:44:10 +0100 | chovelyoukai | (~Lumia@user/Lumia) (Ping timeout: 268 seconds) |
| 2022-11-19 20:44:13 +0100 | <Guillaum[m]> | That's exactly what I was looking for. Thank you. I tried to hoogle it, but based on a generalization of `over`, so I tried `ASetter s t a b -> (a -> m b) -> s -> m t`. I was not that far. |
| 2022-11-19 20:44:20 +0100 | <Guillaum[m]> | Thank you! |
| 2022-11-19 20:44:31 +0100 | <c_wraith> | you're welcome |
| 2022-11-19 20:46:06 +0100 | bgamari_ | (~bgamari@64.223.170.234) |
| 2022-11-19 20:48:56 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 2022-11-19 20:49:08 +0100 | bgamari | (~bgamari@68.238.49.149) (Ping timeout: 248 seconds) |
| 2022-11-19 20:54:59 +0100 | Topsi | (~Topsi@dyndsl-091-096-207-214.ewe-ip-backbone.de) |
| 2022-11-19 20:55:40 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 20:57:42 +0100 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-11-19 21:03:44 +0100 | <alexfmpe[m]> | is there an Integer equivalent of GHC.TypeLits.Nat ? |
| 2022-11-19 21:07:35 +0100 | <geekosaur> | I thought as of 9.2 that was promoted Natural? |
| 2022-11-19 21:08:06 +0100 | <geekosaur> | I'm probably confused, as usual for type level stuff |
| 2022-11-19 21:10:44 +0100 | <alexfmpe[m]> | well, sure but I meant is there a negative-value-allowing version of that |
| 2022-11-19 21:11:33 +0100 | <geekosaur> | not afaik; type level doesn't handle negative numbers well last I checked (but as I said, not great at type level stuff) |
| 2022-11-19 21:11:46 +0100 | <c_wraith> | it still doesn't. |
| 2022-11-19 21:12:10 +0100 | srz | (~srz@181.228.49.93) (Ping timeout: 256 seconds) |
| 2022-11-19 21:12:44 +0100 | lechner | (~lechner@debian/lechner) (Ping timeout: 256 seconds) |
| 2022-11-19 21:13:40 +0100 | <alexfmpe[m]> | sad noises |
| 2022-11-19 21:14:06 +0100 | lechner | (~lechner@debian/lechner) |
| 2022-11-19 21:15:53 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-11-19 21:28:14 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 21:33:39 +0100 | pyrex | (~pyrex@user/pyrex) |
| 2022-11-19 21:34:39 +0100 | `2jt | (~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Ping timeout: 260 seconds) |
| 2022-11-19 21:41:05 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 260 seconds) |
| 2022-11-19 21:56:45 +0100 | pavonia | (~user@user/siracusa) |
| 2022-11-19 21:57:50 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 240 seconds) |
| 2022-11-19 21:59:29 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) |
| 2022-11-19 22:04:02 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-19 22:10:26 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 22:15:07 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2022-11-19 22:16:20 +0100 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2022-11-19 22:24:41 +0100 | <maralorn> | <c_wraith> "-XStrict really is a lot less..." <- What are Space invariants ? |
| 2022-11-19 22:24:43 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) |
| 2022-11-19 22:25:25 +0100 | yuribarros | (~Srain@189.6.35.188) (Ping timeout: 260 seconds) |
| 2022-11-19 22:25:58 +0100 | <maralorn> | Strict shouldn't hurt performance if you put a lazy pattern before everything, that's not certain to be used, right? |
| 2022-11-19 22:26:07 +0100 | <money> | no |
| 2022-11-19 22:26:26 +0100 | <maralorn> | I mean it's just an inversion of defaults, right? |
| 2022-11-19 22:27:12 +0100 | <davean> | maralorn: Those defaults are REALLY important, and that inversion changes what can be optimized, etc. It changes the MEANING of the code. |
| 2022-11-19 22:27:14 +0100 | accord | (uid568320@id-568320.hampstead.irccloud.com) |
| 2022-11-19 22:27:18 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-11-19 22:28:06 +0100 | <davean> | You can't recover laziness ever |
| 2022-11-19 22:28:23 +0100 | <davean> | You can sorta hack a few cases |
| 2022-11-19 22:28:34 +0100 | <money> | Word |
| 2022-11-19 22:29:07 +0100 | InstX1 | (~Liam@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 252 seconds) |
| 2022-11-19 22:30:45 +0100 | Topsi | (~Topsi@dyndsl-091-096-207-214.ewe-ip-backbone.de) (Ping timeout: 256 seconds) |
| 2022-11-19 22:33:15 +0100 | caryhartline | (~caryhartl@107-140-218-181.lightspeed.rcsntx.sbcglobal.net) |
| 2022-11-19 22:37:40 +0100 | xilo | (~yourname@84.32.165.17) (Quit: leaving) |
| 2022-11-19 22:40:57 +0100 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 256 seconds) |
| 2022-11-19 22:43:17 +0100 | SrainUser | (~Srain@189.6.35.188) |
| 2022-11-19 22:47:09 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 22:48:00 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) |
| 2022-11-19 22:49:18 +0100 | xilo | (~yourname@84.32.165.17) |
| 2022-11-19 22:51:03 +0100 | xilo | (~yourname@84.32.165.17) (Quit: leaving) |
| 2022-11-19 22:51:55 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-11-19 22:52:31 +0100 | wroathe | (~wroathe@50.205.197.50) |
| 2022-11-19 22:52:31 +0100 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2022-11-19 22:52:31 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-19 22:53:39 +0100 | chromoblob | (~user@37.113.164.122) (Ping timeout: 268 seconds) |
| 2022-11-19 22:54:21 +0100 | sawilagar | (~sawilagar@user/sawilagar) |
| 2022-11-19 22:54:55 +0100 | xilo | (~yourname@84.32.165.17) |
| 2022-11-19 22:55:16 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-11-19 22:55:28 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) |
| 2022-11-19 22:58:58 +0100 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2022-11-19 23:00:10 +0100 | <maralorn> | davean: Is there an explanation how laziness makes optimization easier somewhere? Every time I hear about optimization I hear, that ghc can profit from knowing if something is strict. |
| 2022-11-19 23:00:19 +0100 | EvanR | (~EvanR@user/evanr) |
| 2022-11-19 23:00:59 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) |
| 2022-11-19 23:01:18 +0100 | <maralorn> | And I don‘t understand what you mean with "you can‘t recover laziness" you mean the compiler can always analyze that something should be more strict, but never that something should be more lazy? |
| 2022-11-19 23:01:55 +0100 | <maralorn> | I simply enabled Strict when I noticed, that I was putting bang patterns in a lot of places. |
| 2022-11-19 23:03:01 +0100 | <maralorn> | And since then everytime I bind something which I maybe won‘t need I put a ~ in front of it. |
| 2022-11-19 23:05:06 +0100 | <maralorn> | Just searched "-XStrict considered harmful" sadly that article hasn‘t been written yet. |
| 2022-11-19 23:05:40 +0100 | ddellacosta | (~ddellacos@143.244.47.100) (Ping timeout: 260 seconds) |
| 2022-11-19 23:05:50 +0100 | <darkling> | I think that once you've made an operation non-lazy, everything that subsequently uses its result has to wait for the whole result to be built, and can't process incrementally, as it could do if the operation were lazy. |
| 2022-11-19 23:06:15 +0100 | <darkling> | (I'm making vague guesses here based on my very limited mental model of all this. I'm definitely not definitive.) |
| 2022-11-19 23:06:18 +0100 | <Guillaum[m]> | Another question related to threading a monad, but not in a lens anymore, in a Stream (from streaming). I've implemented `mapStateStream :: Monad m => r -> (a -> State r b) -> S.Stream (S.Of a) m () -> S.Stream (S.Of b) m r` which basically apply a transformation to all item of the Stream (so it is a like a "map"), but with a monadic context, which is unfortunately not the same as the one of the stream (i.e. m is not State r b). |
| 2022-11-19 23:06:27 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-11-19 23:07:22 +0100 | <Guillaum[m]> | maralorn: maybe a bit unrelated, but in our codebase, we tried to switch `-XStrictData` on. The result was most computation were using less memory, but some computation were never terminating. |
| 2022-11-19 23:08:20 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 256 seconds) |
| 2022-11-19 23:08:25 +0100 | <maralorn> | darkling: Well, you have to do the work at some point, right? And my understanding is: If that’s the case then the sooner you do, the better. If you won‘t need some data, then of course not calculating it is faster. |
| 2022-11-19 23:08:57 +0100 | <EvanR> | unless you're putting bang basically everywhere, I hypothesize you're using too many bangs already |
| 2022-11-19 23:09:07 +0100 | <maralorn> | Guillaum[m]: My Impression with Strict and StrictData is, that it is hard to change it after the fact. |
| 2022-11-19 23:09:15 +0100 | <EvanR> | often it's unnecessary or wrong ime |
| 2022-11-19 23:09:26 +0100 | <darkling> | maralorn: I think of it as a pipeline. If you can pass small items through the pipeline, processing them as you go, you're going to have lower latency than if you do the first operation for everything, then the second operation for everything, then... |
| 2022-11-19 23:09:46 +0100 | <geekosaur> | no streaming optimizations, yeh |
| 2022-11-19 23:10:13 +0100 | <maralorn> | You mean no fusion? |
| 2022-11-19 23:10:30 +0100 | <geekosaur> | correct |
| 2022-11-19 23:10:33 +0100 | <EvanR> | If you won't need some data, of course not calculating it is faster, until it's not because "not calculating it" can mean create a thunk, which takes up space |
| 2022-11-19 23:10:56 +0100 | wroathe | (~wroathe@50.205.197.50) |
| 2022-11-19 23:10:56 +0100 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2022-11-19 23:10:56 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-11-19 23:11:10 +0100 | <maralorn> | That is true, but often fusion happens in one statement. |
| 2022-11-19 23:11:42 +0100 | <janus> | davean: if 'you can never recover laziness', how does idris work? e.g. https://www.idris-lang.org/docs/idris2/current/base_docs/docs/Data.Stream.html |
| 2022-11-19 23:11:52 +0100 | <maralorn> | EvanR: That is also true, my main reason for putting bang patterns everywhere is that I really need to avoid memory leaks. |
| 2022-11-19 23:12:11 +0100 | <EvanR> | then you gotta put bangs or strict fields precisely where the leak would happen |
| 2022-11-19 23:12:31 +0100 | <maralorn> | Honestly, the issue is that I can‘t. |
| 2022-11-19 23:12:43 +0100 | <EvanR> | which isn't necessarily obvious sometimes, but bangs everywhere can be harmful |
| 2022-11-19 23:13:29 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::7fe) (Remote host closed the connection) |
| 2022-11-19 23:13:52 +0100 | zeenk | (~zeenk@2a02:2f04:a208:3600::fba) |
| 2022-11-19 23:13:52 +0100 | <maralorn> | My central program state is a huge record, and it contains lists and maybes and other potentially lazy stuff. |
| 2022-11-19 23:14:43 +0100 | hnOsmium0001 | (uid453710@user/hnOsmium0001) |
| 2022-11-19 23:14:54 +0100 | nate4 | (~nate@98.45.169.16) |
| 2022-11-19 23:14:58 +0100 | <maralorn> | In my benchmark I have about 1.000.000 state transitions and if I don‘t force it after every transition thinks go wrong very quickly. |
| 2022-11-19 23:15:06 +0100 | <maralorn> | *things go wrong |
| 2022-11-19 23:15:09 +0100 | <Hecate> | yummy |
| 2022-11-19 23:15:12 +0100 | <Hecate> | -XStrictData |
| 2022-11-19 23:15:14 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 260 seconds) |
| 2022-11-19 23:15:18 +0100 | <EvanR> | yeah records with fields that accumulate over the course of loops probably need some form of strictification, if not just careful construction / update |
| 2022-11-19 23:15:37 +0100 | <EvanR> | in both cases you don't have to do any forcing after the fact |
| 2022-11-19 23:16:02 +0100 | <maralorn> | carefull construction is kinda annoying. |
| 2022-11-19 23:16:14 +0100 | <maralorn> | Because I can screw it up. |
| 2022-11-19 23:16:45 +0100 | <EvanR> | yeah that's why there's the strict field + proper long term data structure |
| 2022-11-19 23:16:53 +0100 | <maralorn> | I would immediately use StrictMaybe if that wouldn’t break support of all libraries. |
| 2022-11-19 23:17:22 +0100 | <maralorn> | But Maybe, just Maybe I should use StrictMaybe anyway. |
| 2022-11-19 23:17:36 +0100 | <EvanR> | I dunno if that's worth it |
| 2022-11-19 23:17:39 +0100 | <maralorn> | Then I would have a typecheck for strictness in the right moment. |
| 2022-11-19 23:17:59 +0100 | <EvanR> | just apply Just to an evaluated result when you are updating that field with a Just |
| 2022-11-19 23:18:25 +0100 | <EvanR> | if the field is strict, Nothing doesn't take any special measures |
| 2022-11-19 23:18:35 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 23:19:35 +0100 | <maralorn> | Anyways you people have not brought me sufficient evidence to disable -XStrict.^^ It also wouldn‘t be the right move, right now seeing that my program is (probably) not strict enough with Strict. |
| 2022-11-19 23:19:40 +0100 | nate4 | (~nate@98.45.169.16) (Ping timeout: 260 seconds) |
| 2022-11-19 23:19:40 +0100 | <EvanR> | totally useless thoughts, better to keep long term huge state data in some sort of database instead and use views into it, views which won't be around long so doesn't matter if they are strict |
| 2022-11-19 23:19:52 +0100 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-11-19 23:20:56 +0100 | <maralorn> | A typical program lifetime is a few seconds to a few minutes and state will never be needed for the next run. A database sounds definitely wrong for my use case. |
| 2022-11-19 23:20:56 +0100 | king_gs | (~Thunderbi@2806:103e:29:bfeb:c988:bbd5:2586:4924) (Quit: king_gs) |
| 2022-11-19 23:21:43 +0100 | <EvanR> | not necessarily a RDBMS, just something designed to hold a bunch of heterogeneous data fully evaluated and update efficiently |
| 2022-11-19 23:21:55 +0100 | <EvanR> | i.e. not records of lists |
| 2022-11-19 23:22:07 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) |
| 2022-11-19 23:23:15 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 268 seconds) |
| 2022-11-19 23:25:22 +0100 | <EvanR> | definitely wrong, but not because the program only lasts a few seconds. More like we don't have a nice library to do what I said, that I know of |
| 2022-11-19 23:25:26 +0100 | <maralorn> | Well, I don‘t have records of lists for perfomance critical data.^^ |
| 2022-11-19 23:26:10 +0100 | <maralorn> | But I have a record containing strict maps of records containing maybes … |
| 2022-11-19 23:26:18 +0100 | <EvanR> | records of maps of records with maps for indexing into sets, in other words a database xD |
| 2022-11-19 23:26:38 +0100 | <maralorn> | Yeah, sure. |
| 2022-11-19 23:26:42 +0100 | c209e6dc-4d76-47 | (~aditya@2601:249:4300:1296:195:dac6:592c:a55a) |
| 2022-11-19 23:26:56 +0100 | <maralorn> | You are right. |
| 2022-11-19 23:27:14 +0100 | <EvanR> | Maybe might even be a symptom of classic "gratuitous NULL" syndrome xD |
| 2022-11-19 23:27:46 +0100 | <maralorn> | Maybe is a symptom of running your program in unreliable contexts … |
| 2022-11-19 23:28:20 +0100 | <maralorn> | If the state of the world is messy my representation of the worlds get’s messy … |
| 2022-11-19 23:31:42 +0100 | <EvanR> | another traditional application of databaseism |
| 2022-11-19 23:31:59 +0100 | <EvanR> | messy world, messed up changing requirements |
| 2022-11-19 23:34:37 +0100 | freeside | (~mengwong@103.252.202.193) |
| 2022-11-19 23:34:55 +0100 | <maralorn> | What the fuck … Changing Strict to StrictData reduced my benchmark duration from 24s to 4s … |
| 2022-11-19 23:34:57 +0100 | <maralorn> | I am obviously convinced now. |
| 2022-11-19 23:35:04 +0100 | <maralorn> | Sadly I haven‘t learned a lot. |
| 2022-11-19 23:35:11 +0100 | <maralorn> | Still don‘t know what the problem is. |
| 2022-11-19 23:35:33 +0100 | <maralorn> | At least it wasn’t a problem of too much lazyness … |
| 2022-11-19 23:35:34 +0100 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-11-19 23:36:30 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 240 seconds) |
| 2022-11-19 23:37:30 +0100 | mei | (~mei@user/mei) (Ping timeout: 240 seconds) |
| 2022-11-19 23:39:10 +0100 | Kaiepi | (~Kaiepi@108.175.84.104) (Ping timeout: 240 seconds) |
| 2022-11-19 23:39:19 +0100 | freeside | (~mengwong@103.252.202.193) (Ping timeout: 256 seconds) |
| 2022-11-19 23:39:26 +0100 | titibandit | (~titibandi@xdsl-87-78-52-100.nc.de) (Remote host closed the connection) |
| 2022-11-19 23:41:23 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-11-19 23:42:18 +0100 | srz | (~srz@181.228.49.93) |
| 2022-11-19 23:43:26 +0100 | srz | (~srz@181.228.49.93) (Remote host closed the connection) |
| 2022-11-19 23:46:56 +0100 | srz | (~srz@181.228.49.93) |
| 2022-11-19 23:49:00 +0100 | <davean> | janus: They do explicite codata, which is much less than laziness |
| 2022-11-19 23:51:18 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) (Remote host closed the connection) |
| 2022-11-19 23:51:57 +0100 | alternateved | (~user@staticline-31-183-171-154.toya.net.pl) |
| 2022-11-19 23:52:33 +0100 | alternateved | (~user@staticline-31-183-171-154.toya.net.pl) (Remote host closed the connection) |
| 2022-11-19 23:54:53 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-11-19 23:58:29 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:e090:a1b4:58fc:3f99) |
| 2022-11-19 23:59:42 +0100 | bjourne | (~bjorn@94.191.152.93) |