| 2023-04-18 00:00:55 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-04-18 00:10:34 +0200 | <Inst> | okay, freaking cabal won't build my monomer, even though i downgraded back to 9.4.4 |
| 2023-04-18 00:10:37 +0200 | <Inst> | ghc |
| 2023-04-18 00:11:05 +0200 | <monochrom> | Do you mind trying 9.2.*? |
| 2023-04-18 00:11:45 +0200 | <Inst> | will try, also, edmundnoble seems supportive, so that's a production haskeller, just not sure what i need to know, because I think FP discord (and others there agree) is like bottom 25th percentile of Haskell skill, and I'm like bottom 25th percentile of theirs |
| 2023-04-18 00:11:53 +0200 | <monochrom> | To a large extent, people who want stable are still at 9.2, and people who want new have moved on to 9.6. |
| 2023-04-18 00:11:57 +0200 | <Inst> | will try 9.2.2 |
| 2023-04-18 00:12:10 +0200 | <Inst> | i tried 9.6, it simply doesn't work with monomer |
| 2023-04-18 00:12:38 +0200 | <Inst> | and monomer itself is wonky, like, i have a click tracker that's producing 2 clicks for some reason when i clcik rapidly on a button |
| 2023-04-18 00:13:25 +0200 | elain4 | (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-04-18 00:14:01 +0200 | <Inst> | installing 9.2.7 now |
| 2023-04-18 00:15:56 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-04-18 00:18:13 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5432:460c:c9d6:3538) |
| 2023-04-18 00:23:05 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5432:460c:c9d6:3538) (Ping timeout: 260 seconds) |
| 2023-04-18 00:23:09 +0200 | barak | (~barak@77.125.91.113) (Remote host closed the connection) |
| 2023-04-18 00:23:26 +0200 | alexherbo2 | (~alexherbo@2a02-8440-2140-b0a8-4dcf-c179-4324-b99f.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-18 00:23:36 +0200 | barak | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) |
| 2023-04-18 00:24:56 +0200 | it_ | (~quassel@v2202212189510211193.supersrv.de) (Remote host closed the connection) |
| 2023-04-18 00:26:11 +0200 | it_ | (~quassel@v2202212189510211193.supersrv.de) |
| 2023-04-18 00:26:52 +0200 | <Inst> | yeah, i know what happened, the partial build locked the cabal system into trying to build 9.6.1, which needs fiddling to work, at the very least |
| 2023-04-18 00:29:17 +0200 | y04nn | (~username@2a03:1b20:5:f011::aaae) |
| 2023-04-18 00:37:05 +0200 | mncheckm | (~mncheck@193.224.205.254) (Ping timeout: 240 seconds) |
| 2023-04-18 00:37:52 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::4) (Ping timeout: 248 seconds) |
| 2023-04-18 00:44:44 +0200 | oac | (~oac@50-93-248-155.fttp.usinternet.com) (Quit: oac) |
| 2023-04-18 00:51:08 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::4) |
| 2023-04-18 00:52:26 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-04-18 00:54:56 +0200 | heraldo | (~heraldo@user/heraldo) (Ping timeout: 248 seconds) |
| 2023-04-18 00:58:00 +0200 | jargon | (~jargon@174-22-213-236.phnx.qwest.net) |
| 2023-04-18 01:04:07 +0200 | barak | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) (Remote host closed the connection) |
| 2023-04-18 01:04:27 +0200 | thegeekinside | (~thegeekin@189.180.119.50) |
| 2023-04-18 01:04:31 +0200 | barak | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) |
| 2023-04-18 01:05:04 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 248 seconds) |
| 2023-04-18 01:06:52 +0200 | falafel | (~falafel@2603-8000-d700-115c-d504-7657-372e-1c6d.res6.spectrum.com) |
| 2023-04-18 01:07:11 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-04-18 01:07:40 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-18 01:13:04 +0200 | acidjnk | (~acidjnk@p200300d6e715c4910c85db67594b9b68.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-04-18 01:14:54 +0200 | Katarushisu0 | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2023-04-18 01:16:28 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Ping timeout: 276 seconds) |
| 2023-04-18 01:19:19 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2023-04-18 01:20:07 +0200 | Katarushisu0 | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2023-04-18 01:22:08 +0200 | barak | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) (Ping timeout: 248 seconds) |
| 2023-04-18 01:22:11 +0200 | barak_ | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) |
| 2023-04-18 01:26:15 +0200 | barak | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) |
| 2023-04-18 01:26:34 +0200 | barak_ | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) (Read error: Connection reset by peer) |
| 2023-04-18 01:32:25 +0200 | opticblast | (~Thunderbi@172.58.87.218) (Ping timeout: 256 seconds) |
| 2023-04-18 01:36:26 +0200 | <maralorn> | pepeiborra: I am trying to run HeapSize.recursiveSize on some values but I apparently always get interrupted by the garbage collector. Is there a trick for what I can do about that? |
| 2023-04-18 01:37:45 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-183-107.46.114.pool.telefonica.de) (Ping timeout: 240 seconds) |
| 2023-04-18 01:37:55 +0200 | NiceBird | (~NiceBird@185.133.111.196) (Ping timeout: 276 seconds) |
| 2023-04-18 01:44:15 +0200 | elain4 | (~textual@2601:5c0:8200:990:2967:7d1e:b120:3523) |
| 2023-04-18 01:44:44 +0200 | <maralorn> | Ah, apparently I had thunks in there … |
| 2023-04-18 01:47:38 +0200 | noxp | (~psy@104-62-224-96.lightspeed.chrlnc.sbcglobal.net) |
| 2023-04-18 01:50:25 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-04-18 01:50:25 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-18 01:50:56 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-18 01:51:21 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-18 01:52:13 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-18 01:53:12 +0200 | mauke_ | (~mauke@user/mauke) |
| 2023-04-18 01:55:06 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 255 seconds) |
| 2023-04-18 01:55:06 +0200 | mauke_ | mauke |
| 2023-04-18 01:56:03 +0200 | barak | (~barak@2a0d:6fc2:68c0:a400:74a7:4a2d:bdfd:481e) (Ping timeout: 260 seconds) |
| 2023-04-18 01:56:17 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) |
| 2023-04-18 01:56:48 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 248 seconds) |
| 2023-04-18 02:00:13 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) (Excess Flood) |
| 2023-04-18 02:00:14 +0200 | falafel | (~falafel@2603-8000-d700-115c-d504-7657-372e-1c6d.res6.spectrum.com) (Ping timeout: 265 seconds) |
| 2023-04-18 02:00:41 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) |
| 2023-04-18 02:02:41 +0200 | <maralorn> | Tried disabling the GC that helped a bit. Still a bit hit and miss though. |
| 2023-04-18 02:03:00 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) (Excess Flood) |
| 2023-04-18 02:03:22 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) |
| 2023-04-18 02:04:46 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-04-18 02:04:48 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 248 seconds) |
| 2023-04-18 02:05:52 +0200 | califax | (~califax@user/califx) |
| 2023-04-18 02:06:04 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-04-18 02:09:56 +0200 | dcleonarski | (~user@2804:d51:4793:c800:b0e2:a2e8:89a0:4c46) (Remote host closed the connection) |
| 2023-04-18 02:14:33 +0200 | zeenk2 | (~zeenk@188.26.30.104) |
| 2023-04-18 02:14:44 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) (Ping timeout: 265 seconds) |
| 2023-04-18 02:19:11 +0200 | opticblast | (~Thunderbi@172.58.87.218) |
| 2023-04-18 02:20:24 +0200 | zeenk2 | (~zeenk@188.26.30.104) (Quit: Konversation terminated!) |
| 2023-04-18 02:23:46 +0200 | <maralorn> | I get the feeling that HeapSize is underrepresenting the size of Text. |
| 2023-04-18 02:24:03 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 260 seconds) |
| 2023-04-18 02:25:07 +0200 | AlexNoo_ | (~AlexNoo@178.34.150.15) |
| 2023-04-18 02:26:08 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) (Read error: Connection reset by peer) |
| 2023-04-18 02:26:36 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Remote host closed the connection) |
| 2023-04-18 02:27:27 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-04-18 02:28:14 +0200 | chanceyan | (~chanceyan@user/chanceyan) |
| 2023-04-18 02:28:48 +0200 | elain4 | (~textual@2601:5c0:8200:990:2967:7d1e:b120:3523) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-04-18 02:30:13 +0200 | chanceyan | (~chanceyan@user/chanceyan) (Client Quit) |
| 2023-04-18 02:33:38 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-04-18 02:37:45 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds) |
| 2023-04-18 02:40:25 +0200 | ft | (~ft@i59F54987.versanet.de) (Ping timeout: 240 seconds) |
| 2023-04-18 02:42:23 +0200 | ft | (~ft@87.122.11.39) |
| 2023-04-18 02:48:09 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-04-18 02:50:55 +0200 | y04nn | (~username@2a03:1b20:5:f011::aaae) (Ping timeout: 252 seconds) |
| 2023-04-18 02:58:48 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2023-04-18 02:59:24 +0200 | koley | (~koley@eth-east-parth2-46-193-66-191.wb.wifirst.net) |
| 2023-04-18 03:07:57 +0200 | <koley> | Hey, I don't know how to really ask my question, but I'm currently fighting a very weird issue: when building with `ghc` directly or running `stack ghci`, everything works fine, but trying to compile it with `stack build` (or `cabal build` for that matter) fails because of GHC complains cause it can't deduce constraints that seem obvious from the context |
| 2023-04-18 03:08:49 +0200 | <sclv> | ghc never deduces constraints |
| 2023-04-18 03:09:01 +0200 | <koley> | wdym |
| 2023-04-18 03:09:01 +0200 | <sclv> | you always need to give them explicitly |
| 2023-04-18 03:09:08 +0200 | <koley> | right ok that wasn't clear |
| 2023-04-18 03:09:09 +0200 | <koley> | hold on |
| 2023-04-18 03:09:15 +0200 | <koley> | For example, let's say I have a class `Foo a` with a function `someVal :: a` |
| 2023-04-18 03:09:21 +0200 | <sclv> | when using ghc directly you just happen to get things in scope automatically |
| 2023-04-18 03:10:02 +0200 | <sclv> | ok, go on |
| 2023-04-18 03:10:05 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) |
| 2023-04-18 03:10:07 +0200 | <koley> | in a function with constraints `(Show a, Foo a) => ...`, if i write `show (someVal :: a)`, it will complain that it couldn't deduce `Foo a1` (and `Show a1` as well) |
| 2023-04-18 03:10:22 +0200 | <sclv> | oh right, this is defaulting! |
| 2023-04-18 03:10:38 +0200 | <sclv> | ghci has “extended default rules” on to make the repl easier |
| 2023-04-18 03:10:39 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer) |
| 2023-04-18 03:10:56 +0200 | <monochrom> | ghci has extra "helpful" defaulting to pick a preferred instance so as to be able to proceed. |
| 2023-04-18 03:11:24 +0200 | <koley> | Ok, but why does it work if I just do `ghc ../app/Main.hs` (with no other options) but not through stack/cabal ? |
| 2023-04-18 03:11:32 +0200 | <sclv> | you could add the flag to your ghc invocation but i recommend using more explicit signatures. the extended rules are dodgy and only useful for rapid development |
| 2023-04-18 03:11:47 +0200 | <monochrom> | So that a "simple" "print []" does not error out with the "stupid" error of "I don't know how to print [] unless you tell me the element type". |
| 2023-04-18 03:11:49 +0200 | zer0bitz_ | (~zer0bitz@2001:2003:f443:d600:a0d9:2bf4:3f2:ae1) |
| 2023-04-18 03:11:56 +0200 | <koley> | What should I add here then? |
| 2023-04-18 03:12:13 +0200 | <koley> | I though `show (someVal :: a)` was explicit enough |
| 2023-04-18 03:12:33 +0200 | <monochrom> | But no, this is not stupid or simple, it matters. If the element type is Char, [] is printed as ""; otherwise, [] is printed as []. It matters. ghci is wrong. |
| 2023-04-18 03:12:55 +0200 | zer0bitz | (~zer0bitz@2001:2003:f443:d600:3487:52ee:852d:d7d6) (Ping timeout: 252 seconds) |
| 2023-04-18 03:13:38 +0200 | <monochrom> | someVal :: Int |
| 2023-04-18 03:13:49 +0200 | <monochrom> | or whatever is appropriate instead of Int. |
| 2023-04-18 03:13:54 +0200 | <sclv> | also you may need quantification flags on |
| 2023-04-18 03:13:54 +0200 | <monochrom> | Pick a concrete type. |
| 2023-04-18 03:14:33 +0200 | <koley> | Well, except I can't do that; it's in an instance like `(Show a, Foo a) => Show (Bar a)` |
| 2023-04-18 03:14:34 +0200 | <monochrom> | Likewise you are supposed to have no luck with "show minBound". |
| 2023-04-18 03:14:45 +0200 | <sclv> | this isn’t defaulting then |
| 2023-04-18 03:14:53 +0200 | <koley> | ah |
| 2023-04-18 03:14:56 +0200 | <sclv> | it’s different sets if extensions enables |
| 2023-04-18 03:15:26 +0200 | <koley> | What? |
| 2023-04-18 03:15:29 +0200 | <sclv> | ghc has a big set enabled, but often the cabal file specifies another one. let me double check details |
| 2023-04-18 03:16:11 +0200 | <monochrom> | Oh, do you mean Haskell2010 vs GHC2021? |
| 2023-04-18 03:16:30 +0200 | <koley> | the cabal file has Haskell2010 |
| 2023-04-18 03:16:38 +0200 | <sclv> | https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html |
| 2023-04-18 03:16:44 +0200 | <sclv> | yah. |
| 2023-04-18 03:16:46 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-04-18 03:17:24 +0200 | <koley> | ok so changing it to ghc2021 fixed it! |
| 2023-04-18 03:17:36 +0200 | <sclv> | having the a on the outside and the inside be the same requires scoped type variables, an extension in the ghc set but not the h2020 set |
| 2023-04-18 03:17:43 +0200 | <sclv> | yay |
| 2023-04-18 03:18:05 +0200 | <koley> | Thanks! |
| 2023-04-18 03:19:56 +0200 | <koley> | ScopedTypeVariables works as well, wouldn't have guessed that it had something to do with it |
| 2023-04-18 03:20:02 +0200 | <koley> | tbf i'm very much still a noob lol |
| 2023-04-18 03:20:07 +0200 | <koley> | anyway thanks both of you :) |
| 2023-04-18 03:21:34 +0200 | <Axman6> | yeah that's the classic scoped type variables problem - did it get enabled by default in GHC2021? |
| 2023-04-18 03:21:37 +0200 | noxp | (~psy@104-62-224-96.lightspeed.chrlnc.sbcglobal.net) (Quit: Leaving) |
| 2023-04-18 03:23:21 +0200 | <yushyin> | yes |
| 2023-04-18 03:26:13 +0200 | xff0x | (~xff0x@2405:6580:b080:900:1f6d:bb02:ed12:309d) (Ping timeout: 250 seconds) |
| 2023-04-18 03:27:23 +0200 | koley | (~koley@eth-east-parth2-46-193-66-191.wb.wifirst.net) () |
| 2023-04-18 03:29:58 +0200 | Igloo | (~ian@matrix.chaos.earth.li) (Ping timeout: 252 seconds) |
| 2023-04-18 03:37:29 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-18 03:37:29 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-18 03:37:29 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-18 03:40:06 +0200 | Igloo | (~ian@matrix.chaos.earth.li) |
| 2023-04-18 03:46:37 +0200 | opticblast | (~Thunderbi@172.58.87.218) (Ping timeout: 276 seconds) |
| 2023-04-18 03:52:28 +0200 | JScript | (~JScript@45.248.77.204) (Ping timeout: 276 seconds) |
| 2023-04-18 03:54:44 +0200 | falafel | (~falafel@2603-8000-d700-115c-995e-95f4-3442-4b6d.res6.spectrum.com) |
| 2023-04-18 03:54:58 +0200 | ubert | (~Thunderbi@p548c84d6.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2023-04-18 03:55:17 +0200 | ubert | (~Thunderbi@p548c84d6.dip0.t-ipconnect.de) |
| 2023-04-18 03:59:11 +0200 | falafel | (~falafel@2603-8000-d700-115c-995e-95f4-3442-4b6d.res6.spectrum.com) (Ping timeout: 246 seconds) |
| 2023-04-18 04:04:17 +0200 | oac | (~oac@50-93-248-155.fttp.usinternet.com) |
| 2023-04-18 04:05:25 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2023-04-18 04:06:05 +0200 | Techcable | (~Techcable@user/Techcable) (Ping timeout: 250 seconds) |
| 2023-04-18 04:08:25 +0200 | td_ | (~td@i53870920.versanet.de) (Ping timeout: 240 seconds) |
| 2023-04-18 04:10:08 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-04-18 04:10:31 +0200 | td_ | (~td@i53870902.versanet.de) |
| 2023-04-18 04:11:05 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-04-18 04:13:58 +0200 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 252 seconds) |
| 2023-04-18 04:15:25 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-18 04:20:55 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2023-04-18 04:22:33 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 250 seconds) |
| 2023-04-18 04:26:45 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-04-18 04:36:08 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-04-18 04:36:45 +0200 | thegeekinside | (~thegeekin@189.180.119.50) (Ping timeout: 240 seconds) |
| 2023-04-18 04:37:45 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-04-18 04:41:15 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-18 04:42:30 +0200 | krei-se | (~krei-se@p50874388.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-04-18 04:43:00 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-18 04:45:32 +0200 | krei-se | (~krei-se@p57af2733.dip0.t-ipconnect.de) |
| 2023-04-18 04:51:40 +0200 | JScript | (~JScript@103.137.12.221) |
| 2023-04-18 04:51:42 +0200 | JScript | (~JScript@103.137.12.221) (Max SendQ exceeded) |
| 2023-04-18 04:52:10 +0200 | JScript | (~JScript@103.137.12.221) |
| 2023-04-18 04:55:32 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-04-18 04:57:03 +0200 | Techcable | (~Techcable@user/Techcable) |
| 2023-04-18 04:58:00 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5432:460c:c9d6:3538) |
| 2023-04-18 04:59:30 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-18 04:59:30 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-04-18 04:59:30 +0200 | finn_elija | FinnElija |
| 2023-04-18 05:00:03 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 255 seconds) |
| 2023-04-18 05:04:57 +0200 | jero98772 | (~jero98772@2800:484:1d84:9000::4) (Remote host closed the connection) |
| 2023-04-18 05:18:25 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-04-18 05:20:45 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 240 seconds) |
| 2023-04-18 05:27:03 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 255 seconds) |
| 2023-04-18 05:29:07 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-04-18 05:30:24 +0200 | <Inst> | okay, i'm stuck |
| 2023-04-18 05:30:36 +0200 | <Inst> | is there a way to unzip a file from within Haskell? |
| 2023-04-18 05:30:52 +0200 | <Inst> | what i'm trying to do right now is with monomer, since monomer doesn't prepackage its own assets within the library |
| 2023-04-18 05:31:05 +0200 | danrh | (~danrh@2607:fea8:86a2:e930:d120:6ae1:d426:8aaf) |
| 2023-04-18 05:31:21 +0200 | <Inst> | to run an IO action within the file that checks if the assets exist, and if they don't, download them from a websource |
| 2023-04-18 05:31:27 +0200 | <Inst> | but the google web source is storing it as a zip |
| 2023-04-18 05:32:39 +0200 | <Inst> | also, what |
| 2023-04-18 05:32:40 +0200 | <Inst> | https://twitter.com/zhuowei/status/1610071092416110596 |
| 2023-04-18 05:32:52 +0200 | oac | (~oac@50-93-248-155.fttp.usinternet.com) (Quit: oac) |
| 2023-04-18 05:39:38 +0200 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-04-18 05:41:59 +0200 | danrh | (~danrh@2607:fea8:86a2:e930:d120:6ae1:d426:8aaf) (Read error: Connection reset by peer) |
| 2023-04-18 05:42:56 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-18 06:06:36 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-04-18 06:14:13 +0200 | trev | (~trev@user/trev) |
| 2023-04-18 06:18:36 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2023-04-18 06:21:41 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:5432:460c:c9d6:3538) (Remote host closed the connection) |
| 2023-04-18 06:23:03 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3df9:f2b9:6cdb:aef1) |
| 2023-04-18 06:24:21 +0200 | mbuf | (~Shakthi@49.207.178.186) |
| 2023-04-18 06:25:18 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-18 06:27:41 +0200 | drdo2 | (~drdo@bl14-14-164.dsl.telepac.pt) |
| 2023-04-18 06:29:31 +0200 | drdo | (~drdo@bl7-76-103.dsl.telepac.pt) (Ping timeout: 240 seconds) |
| 2023-04-18 06:29:31 +0200 | drdo2 | drdo |
| 2023-04-18 06:29:58 +0200 | <Inst> | welp, finally got it working, but via a very hacky asset checker |
| 2023-04-18 06:30:18 +0200 | <Inst> | now to figure out how to hook GHCup up to Monomer |
| 2023-04-18 06:30:41 +0200 | <Inst> | maerwald, just in case you're interested |
| 2023-04-18 06:49:31 +0200 | pyook | (~puke@user/puke) (Remote host closed the connection) |
| 2023-04-18 06:49:44 +0200 | pyook | (~puke@user/puke) |
| 2023-04-18 06:55:54 +0200 | nain | (~nain@169.150.196.132) |
| 2023-04-18 07:00:01 +0200 | <sm> | go Inst |
| 2023-04-18 07:01:31 +0200 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2023-04-18 07:01:51 +0200 | pavonia | (~user@user/siracusa) |
| 2023-04-18 07:03:33 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-04-18 07:05:38 +0200 | trev | (~trev@user/trev) |
| 2023-04-18 07:06:15 +0200 | <Inst> | thanks |
| 2023-04-18 07:10:23 +0200 | mmhat | (~mmh@p200300f1c7106e9dee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-04-18 07:11:09 +0200 | bgs | (~bgs@212.85.160.171) |
| 2023-04-18 07:11:35 +0200 | mmhat | (~mmh@p200300f1c7106e9dee086bfffe095315.dip0.t-ipconnect.de) (Client Quit) |
| 2023-04-18 07:17:26 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-04-18 07:19:15 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-18 07:29:45 +0200 | JScript | (~JScript@103.137.12.221) (Ping timeout: 240 seconds) |
| 2023-04-18 07:32:40 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-18 07:35:16 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-04-18 07:46:02 +0200 | barak | (~barak@bzq-84-110-161-42.cablep.bezeqint.net) |
| 2023-04-18 07:47:21 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-04-18 07:48:29 +0200 | tr_ev | (~trev@user/trev) |
| 2023-04-18 07:48:35 +0200 | tr_ev | trev |
| 2023-04-18 07:51:46 +0200 | nek0 | (~nek0@2a01:4f8:222:2b41::12) |
| 2023-04-18 07:53:05 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) (Ping timeout: 240 seconds) |
| 2023-04-18 07:53:46 +0200 | barak | (~barak@bzq-84-110-161-42.cablep.bezeqint.net) (Read error: Connection reset by peer) |
| 2023-04-18 07:55:12 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) |
| 2023-04-18 07:56:14 +0200 | JScript | (~JScript@103.137.12.220) |
| 2023-04-18 08:02:05 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) (Ping timeout: 240 seconds) |
| 2023-04-18 08:04:10 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) |
| 2023-04-18 08:09:24 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2023-04-18 08:09:27 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-04-18 08:10:44 +0200 | gensyst | (~gensyst@user/gensyst) |
| 2023-04-18 08:10:56 +0200 | <gensyst> | Hi, is this dangerous? https://dpaste.com/726FFYSE6 |
| 2023-04-18 08:10:56 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-04-18 08:11:16 +0200 | <gensyst> | I wonder if I really have to do a pattern match on foo to extract the pointer later on, to make sure the ptr is alive when I work on it. |
| 2023-04-18 08:11:35 +0200 | <gensyst> | (fyi i have some reasons to do that finalizer shenanigans, instead of using foreignptr) |
| 2023-04-18 08:15:25 +0200 | nain | (~nain@169.150.196.132) (Ping timeout: 252 seconds) |
| 2023-04-18 08:17:14 +0200 | kee | (~~kee@user/wizzwizz4) (Ping timeout: 265 seconds) |
| 2023-04-18 08:25:57 +0200 | kee | (~~kee@user/wizzwizz4) |
| 2023-04-18 08:28:34 +0200 | michalz | (~michalz@185.246.207.203) |
| 2023-04-18 08:33:03 +0200 | kenran | (~user@user/kenran) |
| 2023-04-18 08:33:25 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) (Ping timeout: 240 seconds) |
| 2023-04-18 08:33:36 +0200 | JScript | (~JScript@103.137.12.220) (Ping timeout: 248 seconds) |
| 2023-04-18 08:33:57 +0200 | <[exa]> | gensyst: why can't you do just with newForeignPtr and share the other Foo data with the finalizer function? |
| 2023-04-18 08:34:33 +0200 | CiaoSen | (~Jura@ip-109-43-178-39.web.vodafone.de) |
| 2023-04-18 08:35:09 +0200 | ryantrinkle | (~ryantrink@140.174.248.64) (Ping timeout: 255 seconds) |
| 2023-04-18 08:35:31 +0200 | Vq | (~vq@90-230-208-28-no77.tbcn.telia.com) |
| 2023-04-18 08:35:34 +0200 | <[exa]> | anyway yeah I think there's nothing to prevent your finalizer being run when you still hold the Ptr |
| 2023-04-18 08:38:24 +0200 | Square | (~Square4@user/square) |
| 2023-04-18 08:38:49 +0200 | mncheck | (~mncheck@193.224.205.254) |
| 2023-04-18 08:39:13 +0200 | Square | (~Square4@user/square) (Client Quit) |
| 2023-04-18 08:39:44 +0200 | Square | (~Square4@user/square) |
| 2023-04-18 08:47:14 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:7947:e8a0:99b6:e45a) |
| 2023-04-18 08:51:23 +0200 | kuribas | (~user@2a02:1808:5:e31e:4cb2:f1e7:308c:b866) |
| 2023-04-18 08:52:17 +0200 | coot | (~coot@213.134.170.228) |
| 2023-04-18 08:55:27 +0200 | ft | (~ft@87.122.11.39) (Quit: leaving) |
| 2023-04-18 09:03:07 +0200 | kuribas | (~user@2a02:1808:5:e31e:4cb2:f1e7:308c:b866) (Ping timeout: 248 seconds) |
| 2023-04-18 09:03:56 +0200 | kuribas | (~user@2a02:1808:5:e31e:7ed0:d5b7:3a88:e8cd) |
| 2023-04-18 09:04:01 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:3df9:f2b9:6cdb:aef1) (Ping timeout: 240 seconds) |
| 2023-04-18 09:04:05 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-04-18 09:04:35 +0200 | Batzy | (~quassel@user/batzy) (Ping timeout: 260 seconds) |
| 2023-04-18 09:04:56 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 260 seconds) |
| 2023-04-18 09:06:10 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:aa:e7be:a5cb:6ac0) |
| 2023-04-18 09:07:51 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-18 09:08:31 +0200 | Batzy | (~quassel@user/batzy) |
| 2023-04-18 09:10:14 +0200 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2023-04-18 09:10:20 +0200 | califax_ | (~califax@user/califx) |
| 2023-04-18 09:10:53 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2023-04-18 09:11:37 +0200 | califax_ | califax |
| 2023-04-18 09:11:38 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-a8d7-8dc6-1c8c-d61e.rev.sfr.net) |
| 2023-04-18 09:12:30 +0200 | jargon | (~jargon@174-22-213-236.phnx.qwest.net) (Ping timeout: 255 seconds) |
| 2023-04-18 09:12:57 +0200 | kuribas | (~user@2a02:1808:5:e31e:7ed0:d5b7:3a88:e8cd) (Remote host closed the connection) |
| 2023-04-18 09:13:09 +0200 | kuribas | (~user@2a02:1808:5:e31e:7ed0:d5b7:3a88:e8cd) |
| 2023-04-18 09:13:22 +0200 | acidjnk | (~acidjnk@p200300d6e715c449e993588d69a2b1db.dip0.t-ipconnect.de) |
| 2023-04-18 09:13:51 +0200 | Wstfgl0_ | (~Me-me@146.102.215.218.dyn.iprimus.net.au) |
| 2023-04-18 09:14:37 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) (Ping timeout: 250 seconds) |
| 2023-04-18 09:14:46 +0200 | Wstfgl0_ | Me-me |
| 2023-04-18 09:16:19 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-18 09:16:44 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-18 09:18:08 +0200 | falafel | (~falafel@2603-8000-d700-115c-4927-b1d5-99ef-f5e0.res6.spectrum.com) |
| 2023-04-18 09:20:29 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-a8d7-8dc6-1c8c-d61e.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-18 09:21:22 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 276 seconds) |
| 2023-04-18 09:23:28 +0200 | kuribas | (~user@2a02:1808:5:e31e:7ed0:d5b7:3a88:e8cd) (Remote host closed the connection) |
| 2023-04-18 09:23:37 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-04-18 09:23:55 +0200 | <dminuoso> | gensyst: I would say its dangerous, yes. Consider that doPointerStuff can simply be inlined. |
| 2023-04-18 09:24:14 +0200 | <dminuoso> | And depending on the surrounding code, that can cause the GC to trigger much easlier. |
| 2023-04-18 09:24:45 +0200 | <dminuoso> | And if you do a non-inline, its still dangerous because if a GC occurs right in the middle of doPointerStuff but before ptr is used, that finalizer gets called too. |
| 2023-04-18 09:25:42 +0200 | <dminuoso> | You really want to use a ForeignPtr + withForeignPtr. |
| 2023-04-18 09:25:54 +0200 | <dminuoso> | GHC has special support for exactly what you're attempting to do. |
| 2023-04-18 09:26:02 +0200 | <dminuoso> | https://hackage.haskell.org/package/base-4.18.0.0/docs/Foreign-ForeignPtr.html#v:withForeignPtr |
| 2023-04-18 09:26:57 +0200 | <dminuoso> | Take note that this makes use of special primops that you cannot simply mimic. |
| 2023-04-18 09:27:18 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-04-18 09:27:32 +0200 | <dminuoso> | Well I suppose you can use keepAlive# manually if for some reason you're forced to use that custom-but-not-real-ForeignPtr |
| 2023-04-18 09:27:33 +0200 | pyook | (~puke@user/puke) (Remote host closed the connection) |
| 2023-04-18 09:27:53 +0200 | pyook | (~puke@user/puke) |
| 2023-04-18 09:28:55 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-18 09:30:01 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-04-18 09:32:00 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2023-04-18 09:32:43 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 09:32:55 +0200 | <dminuoso> | gensyst: https://gist.github.com/dminuoso/b8c602ed0c0e7b2f57ff3f0b39e70285 |
| 2023-04-18 09:32:57 +0200 | <dminuoso> | If you must |
| 2023-04-18 09:38:17 +0200 | nain | (~nain@169.150.196.132) |
| 2023-04-18 09:43:38 +0200 | jwiegley | (~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-18 09:45:08 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2023-04-18 09:49:04 +0200 | <jackdk> | gensyst: this is your libzip thing, right? where `zip_fclose` can return an `int` and you want to ensure that's available to Haskell whenever it happens to be finalised? |
| 2023-04-18 09:55:46 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-04-18 09:56:37 +0200 | mbuf | (~Shakthi@49.207.178.186) (Quit: Leaving) |
| 2023-04-18 09:58:40 +0200 | <Inst> | if I give a rough outline of this project, could you tell me if I'm doing something wrong? |
| 2023-04-18 09:59:06 +0200 | <Inst> | monomer for GUI output, use System.Process to call GHCup (at this stage), collect data from System.Process, feed it back to monomer, ??? profit? |
| 2023-04-18 09:59:15 +0200 | <Inst> | it seems really dumb and trivial |
| 2023-04-18 09:59:26 +0200 | <Inst> | like, maybe System.Process isn't the right way to do this? |
| 2023-04-18 09:59:45 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 240 seconds) |
| 2023-04-18 10:01:40 +0200 | vglfr | (~vglfr@46.96.155.105) |
| 2023-04-18 10:03:40 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2023-04-18 10:04:05 +0200 | falafel | (~falafel@2603-8000-d700-115c-4927-b1d5-99ef-f5e0.res6.spectrum.com) (Ping timeout: 260 seconds) |
| 2023-04-18 10:04:06 +0200 | witcher | (~witcher@wiredspace.de) (Remote host closed the connection) |
| 2023-04-18 10:04:21 +0200 | witcher | (~witcher@wiredspace.de) |
| 2023-04-18 10:04:44 +0200 | phma | (~phma@host-67-44-208-106.hnremote.net) (Read error: Connection reset by peer) |
| 2023-04-18 10:05:39 +0200 | phma | (phma@2001:5b0:215d:98b8:e349:d2b0:ba66:968) |
| 2023-04-18 10:06:34 +0200 | <tomsmeding> | Inst: don't see a problem |
| 2023-04-18 10:07:29 +0200 | <tomsmeding> | calling ghcup as a separate process is going to be less performant than calling ghcup as a library, but ~all that ghcup does is IO-bound anyway, so it's not like that's going to really matter |
| 2023-04-18 10:07:56 +0200 | <tomsmeding> | is monomer easy to compile and make work cross-platform these days? |
| 2023-04-18 10:12:15 +0200 | <gensyst> | [exa], probably foreignptr will work in this case, thanks |
| 2023-04-18 10:12:28 +0200 | <gensyst> | dminuoso, thanks for the insights. good to keep at the back of my mind on how GC works |
| 2023-04-18 10:13:06 +0200 | <gensyst> | jackdk, yeah it's related, although in this case it was about keeping the zip alive while the file is operated on (if the zip closes prematurely, the file operations will error). |
| 2023-04-18 10:13:24 +0200 | <gensyst> | jackdk, to deal with the file, your resourcet idea will work excellent |
| 2023-04-18 10:13:37 +0200 | <gensyst> | jackdk, (but for the zip, foreignptr will be fine because the zip close func returns void) |
| 2023-04-18 10:17:17 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-04-18 10:18:12 +0200 | nain | (~nain@169.150.196.132) (Ping timeout: 255 seconds) |
| 2023-04-18 10:18:52 +0200 | nain | (~nain@169.150.196.132) |
| 2023-04-18 10:20:22 +0200 | <Inst> | tomsmeding: on Windows, you need a few workarounds for sdl2; i.e, the latest sdl2 will fail, and has to be configured via mingw first |
| 2023-04-18 10:21:30 +0200 | <Inst> | the biggest drawback of monomer as brainless haskell is that you'd need to configure cabal to install the assets that monomer relies on; it requires an icon to boot as well as typefaces to display any text |
| 2023-04-18 10:21:35 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:aa:e7be:a5cb:6ac0) (Remote host closed the connection) |
| 2023-04-18 10:21:44 +0200 | <Inst> | alternately, as I do, I have some code that detects whether the assets exists, and if not, downloads them from the web |
| 2023-04-18 10:22:01 +0200 | <Inst> | but the problem is, on Windows, the default icon is bmp, so you'd need to convert png to bmp |
| 2023-04-18 10:22:27 +0200 | <Inst> | otherwise: it is so delightfully brainless |
| 2023-04-18 10:22:48 +0200 | <Inst> | absolutely great, just the maintainer / developer needs help, and I'm not sure whether he wants to accept such |
| 2023-04-18 10:23:09 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) (Ping timeout: 255 seconds) |
| 2023-04-18 10:23:27 +0200 | drdo | (~drdo@bl14-14-164.dsl.telepac.pt) |
| 2023-04-18 10:26:07 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 260 seconds) |
| 2023-04-18 10:31:12 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-04-18 10:33:00 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2023-04-18 10:42:02 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 255 seconds) |
| 2023-04-18 10:42:37 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds) |
| 2023-04-18 10:43:04 +0200 | vpan | (~0@mail.elitnet.lt) |
| 2023-04-18 10:44:04 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2023-04-18 10:45:18 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-18 10:45:52 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-04-18 10:50:09 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2023-04-18 10:51:43 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 276 seconds) |
| 2023-04-18 10:52:32 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Remote host closed the connection) |
| 2023-04-18 10:52:51 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2023-04-18 10:53:25 +0200 | NiceBird | (~NiceBird@185.133.111.196) |
| 2023-04-18 10:58:42 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-18 11:01:23 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-04-18 11:02:09 +0200 | cyphase | (~cyphase@user/cyphase) (Read error: Connection reset by peer) |
| 2023-04-18 11:04:16 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2023-04-18 11:04:22 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) |
| 2023-04-18 11:05:22 +0200 | cyphase | (~cyphase@user/cyphase) (Client Quit) |
| 2023-04-18 11:11:58 +0200 | acidjnk | (~acidjnk@p200300d6e715c449e993588d69a2b1db.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2023-04-18 11:13:42 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2023-04-18 11:13:43 +0200 | calamaxes[m] | (~calamaxes@2001:470:69fc:105::3:47b2) |
| 2023-04-18 11:13:54 +0200 | ph88 | (~ph88@84-29-20-195.cable.dynamic.v4.ziggo.nl) |
| 2023-04-18 11:20:10 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6486:e69a:524e:7c3f) |
| 2023-04-18 11:21:49 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-04-18 11:22:01 +0200 | chanceyan | (~chanceyan@user/chanceyan) |
| 2023-04-18 11:23:28 +0200 | <gensyst> | Will a data structure ever be partially garbage collected, or is zero references for all records needed before it's garbage collected? |
| 2023-04-18 11:23:56 +0200 | <gensyst> | (basically, only some records have zero count, but the outer data structure has zero count) |
| 2023-04-18 11:24:04 +0200 | <gensyst> | hmm |
| 2023-04-18 11:24:20 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6486:e69a:524e:7c3f) (Ping timeout: 246 seconds) |
| 2023-04-18 11:25:12 +0200 | <tomsmeding> | gensyst: if the fields are lifted, then those are separately gc'd, right? |
| 2023-04-18 11:25:21 +0200 | <[exa]> | gensyst: depends on boxing status of the fields btw. Also AFAIK there's no reference counting |
| 2023-04-18 11:26:14 +0200 | chanceyan | (~chanceyan@user/chanceyan) (Client Quit) |
| 2023-04-18 11:26:16 +0200 | JScript | (~JScript@103.137.12.221) |
| 2023-04-18 11:26:19 +0200 | JScript | (~JScript@103.137.12.221) (Max SendQ exceeded) |
| 2023-04-18 11:26:48 +0200 | JScript | (~JScript@103.137.12.221) |
| 2023-04-18 11:26:51 +0200 | chanceyan | (~chanceyan@user/chanceyan) |
| 2023-04-18 11:26:52 +0200 | JScript | (~JScript@103.137.12.221) (Max SendQ exceeded) |
| 2023-04-18 11:26:56 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 11:27:30 +0200 | JScript | (~JScript@103.137.12.221) |
| 2023-04-18 11:27:34 +0200 | JScript | (~JScript@103.137.12.221) (Max SendQ exceeded) |
| 2023-04-18 11:27:41 +0200 | chanceyan | (~chanceyan@user/chanceyan) (Client Quit) |
| 2023-04-18 11:28:01 +0200 | JScript | (~JScript@103.137.12.221) |
| 2023-04-18 11:28:41 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2023-04-18 11:30:08 +0200 | ub | (~Thunderbi@p548c84d6.dip0.t-ipconnect.de) |
| 2023-04-18 11:30:45 +0200 | ubert | (~Thunderbi@p548c84d6.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-04-18 11:30:45 +0200 | ub | ubert |
| 2023-04-18 11:32:24 +0200 | <hellwolf[m]> | $ cabal run maths/lorenz.hs -- +RTS -N -s -ls | wc -l |
| 2023-04-18 11:32:39 +0200 | <hellwolf[m]> | It looks to me that cabal run cannot run it in multiple threads? |
| 2023-04-18 11:33:25 +0200 | ubert1 | (~Thunderbi@2a02:8109:abc0:6434:b660:4b0:ed52:1706) |
| 2023-04-18 11:33:54 +0200 | <dcoutts_> | hellwolf[m]: you're probably passing the RTS options to cabal, not passing them through to the program you're running |
| 2023-04-18 11:34:22 +0200 | <dcoutts_> | try cabal run blah.hs --RTS -- +RTS -N -s -ls |
| 2023-04-18 11:34:25 +0200 | <hellwolf[m]> | I used "--" |
| 2023-04-18 11:34:29 +0200 | <dcoutts_> | that's not relevant |
| 2023-04-18 11:34:45 +0200 | <dcoutts_> | ghc: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args> |
| 2023-04-18 11:34:45 +0200 | <dcoutts_> | ghc: |
| 2023-04-18 11:34:45 +0200 | <dcoutts_> | ghc: +RTS Indicates run time system options follow |
| 2023-04-18 11:34:45 +0200 | <dcoutts_> | ghc: -RTS Indicates program arguments follow |
| 2023-04-18 11:34:45 +0200 | <dcoutts_> | ghc: --RTS Indicates that ALL subsequent arguments will be given to the |
| 2023-04-18 11:34:46 +0200 | <dcoutts_> | ghc: program (including any of these RTS flags) |
| 2023-04-18 11:34:47 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2023-04-18 11:35:43 +0200 | <dcoutts_> | the program (cabal in this case) doesn't even see the RTS flags, whether or not they're before/after an argument "--" |
| 2023-04-18 11:35:59 +0200 | <dcoutts_> | You need --RTS as in the help text above |
| 2023-04-18 11:36:11 +0200 | <hellwolf[m]> | didnt' quite help |
| 2023-04-18 11:36:38 +0200 | <hellwolf[m]> | https://pastebin.com/UzTVi8dV |
| 2023-04-18 11:36:40 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-183-107.46.114.pool.telefonica.de) |
| 2023-04-18 11:36:43 +0200 | <hellwolf[m]> | this is the program |
| 2023-04-18 11:36:55 +0200 | <hellwolf[m]> | I ran with |
| 2023-04-18 11:36:55 +0200 | <hellwolf[m]> | ``` |
| 2023-04-18 11:36:55 +0200 | <hellwolf[m]> | cabal run maths/lorenz.hs -- --RTS +RTS -N -s -ls | wc -l |
| 2023-04-18 11:37:05 +0200 | <hellwolf[m]> | using threadscope to examine it |
| 2023-04-18 11:37:14 +0200 | <hellwolf[m]> | but only one core is used |
| 2023-04-18 11:37:33 +0200 | <hellwolf[m]> | $ cat /proc/cpuinfo | grep process | wc -l |
| 2023-04-18 11:37:33 +0200 | <hellwolf[m]> | 12 |
| 2023-04-18 11:38:31 +0200 | <dcoutts_> | You can see in threadscope what the process command line was, so you can check if the RTS flags are being passed through correctly |
| 2023-04-18 11:39:15 +0200 | <dcoutts_> | you can also just invoke the executable directly, rather than using cabal run |
| 2023-04-18 11:39:24 +0200 | hellwolf[m] | uploaded an image: (20KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/GOfWcUZsRHbUjJgpzXjnTGZg/image.png > |
| 2023-04-18 11:39:40 +0200 | <hellwolf[m]> | yea I was trying to be concise, since I didn't bother to create the boilerplate of a cabal project yet. |
| 2023-04-18 11:40:09 +0200 | <hellwolf[m]> | or it could be that I am using parallel wrong. |
| 2023-04-18 11:40:13 +0200 | <hellwolf[m]> | but I am out of idea now |
| 2023-04-18 11:40:15 +0200 | <dcoutts_> | ok good, so the arguments pass through is working |
| 2023-04-18 11:40:33 +0200 | <dcoutts_> | getting parallelism working effectively is always a bit tricky |
| 2023-04-18 11:40:39 +0200 | <hellwolf[m]> | it could be that I should just build the binary :) but I am holding out until I write that boilerplate |
| 2023-04-18 11:41:16 +0200 | <hellwolf[m]> | hellwolf 1026118 117 0.0 1075846068 5284 pts/8 Rl+ 12:40 0:03 /home/hellwolf/.cabal/script-builds/ac8d3cc4be766b05a3a70d903b54553ae32b9452686cda2325fe93f04510cf46/dist-newstyle/build/x86_64-linux/ghc-9.4.2/fake-package-0/x/cabal-script-lorenz.hs/build/cabal-script-lorenz.hs/cabal-script-lorenz.hs --RTS +RTS -N -s -ls |
| 2023-04-18 11:44:04 +0200 | <hellwolf[m]> | SPARKS: 101 (100 converted, 0 overflowed, 0 dud, 0 GC'd, 1 fizzled) |
| 2023-04-18 11:44:15 +0200 | <hellwolf[m]> | ^-- |
| 2023-04-18 11:44:15 +0200 | <hellwolf[m]> | ``` |
| 2023-04-18 11:44:15 +0200 | <hellwolf[m]> | $ cabal run maths/lorenz.hs -- +RTS -N -s -ls | wc -l |
| 2023-04-18 11:44:21 +0200 | <hellwolf[m]> | output from |
| 2023-04-18 11:44:30 +0200 | <hellwolf[m]> | so the sparks were definitely created |
| 2023-04-18 11:44:36 +0200 | <hellwolf[m]> | just that there was no other cores being used |
| 2023-04-18 11:46:48 +0200 | gensyst | (~gensyst@user/gensyst) (Quit: Leaving) |
| 2023-04-18 11:47:53 +0200 | <hellwolf[m]> | I suspect I am just using parallel wrong, but I can't understand why |
| 2023-04-18 11:53:12 +0200 | hellwolf[m] | uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/yZGsHLKJixesvtlDzFyCwGzd/image.png > |
| 2023-04-18 11:53:48 +0200 | CiaoSen | (~Jura@ip-109-43-178-39.web.vodafone.de) (Remote host closed the connection) |
| 2023-04-18 11:56:35 +0200 | <probie> | hellwolf[m]: do you get a different result if you force (i.e `rnf`) `rs` before the call to `mapM`? |
| 2023-04-18 11:57:28 +0200 | <hellwolf[m]> | ``` |
| 2023-04-18 11:57:28 +0200 | <hellwolf[m]> | mapM (\(p,v) -> putStrLn (showFullFloat p . ("\t" ++) . showFullFloat v $ "")) (force rs) |
| 2023-04-18 11:57:28 +0200 | <hellwolf[m]> | I just tried to use `force` from deepseq |
| 2023-04-18 11:57:29 +0200 | <hellwolf[m]> | same result |
| 2023-04-18 11:58:17 +0200 | <hellwolf[m]> | The fact that only one HEC is being used at any given time is very suspiious |
| 2023-04-18 11:58:24 +0200 | <hellwolf[m]> | ``` |
| 2023-04-18 11:58:24 +0200 | <hellwolf[m]> | Productivity 100.0% of total user, 99.9% of total elapsed |
| 2023-04-18 11:58:24 +0200 | <hellwolf[m]> | That core is fully utilized |
| 2023-04-18 11:59:44 +0200 | <probie> | What if you explicitly pass a number of capabilities (e.g. `+RTS -N4`)? |
| 2023-04-18 12:00:01 +0200 | <hellwolf[m]> | didn't help |
| 2023-04-18 12:00:49 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 12:00:58 +0200 | acidjnk | (~acidjnk@p200300d6e715c44958402cbcae5898a8.dip0.t-ipconnect.de) |
| 2023-04-18 12:01:55 +0200 | hellwolf[m] | uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/IepDCFamdEbshrWVJXWZvznx/image.png > |
| 2023-04-18 12:01:58 +0200 | <hellwolf[m]> | now I get that! |
| 2023-04-18 12:01:58 +0200 | <hellwolf[m]> | :D |
| 2023-04-18 12:04:01 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 240 seconds) |
| 2023-04-18 12:07:30 +0200 | <probie> | That's interesting. When I tried the code you posted on pastebin (with `let rs = parMap (rpar `dot` rdeepseq)`), it used multiple physical cores without needing any change |
| 2023-04-18 12:07:52 +0200 | <hellwolf[m]> | you didn't do anything? |
| 2023-04-18 12:07:53 +0200 | <hellwolf[m]> | what's your ghc version |
| 2023-04-18 12:08:05 +0200 | <probie> | 9.2.4 |
| 2023-04-18 12:08:23 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 250 seconds) |
| 2023-04-18 12:09:26 +0200 | <hellwolf[m]> | let me use nix to try that verison |
| 2023-04-18 12:09:46 +0200 | <hellwolf[m]> | I had to use rdeepseq |
| 2023-04-18 12:09:57 +0200 | <hellwolf[m]> | which is quite clean still semantically |
| 2023-04-18 12:10:16 +0200 | <hellwolf[m]> | I'd avoid usint strictness notations, that feels ugly and black magic |
| 2023-04-18 12:10:35 +0200 | <hellwolf[m]> | mapM (\(p,v) -> putStrLn (showFullFloat p . ("\t" ++) . showFullFloat v $ "")) |
| 2023-04-18 12:10:35 +0200 | <hellwolf[m]> | (rs `using` parBuffer 100 rdeepseq) -- rs <-- without using parallel, slow slow slow |
| 2023-04-18 12:10:39 +0200 | <hellwolf[m]> | that's all I dd |
| 2023-04-18 12:11:36 +0200 | <hellwolf[m]> | it didn't help with 9.2.4 |
| 2023-04-18 12:11:44 +0200 | <hellwolf[m]> | still needed the rdeepseq |
| 2023-04-18 12:11:49 +0200 | <hellwolf[m]> | but I am more or less happy now |
| 2023-04-18 12:12:28 +0200 | <hellwolf[m]> | still clean enough, all I needed is in the very end of the program to use parBuffer to inject parallel computation semantics |
| 2023-04-18 12:13:14 +0200 | <probie> | I get the same usage on 8.10.7 (although it's a lot slower). I also don't get any noticeable difference between `rseq` and `rdeepseq` (I do actually have one more change, I calculate a thousand points instead of a hundred so it takes longer) |
| 2023-04-18 12:14:05 +0200 | <hellwolf[m]> | hmm, weird indeed. |
| 2023-04-18 12:14:21 +0200 | <hellwolf[m]> | oh, but it could be the difference between our parallel package? |
| 2023-04-18 12:14:31 +0200 | <hellwolf[m]> | but I doubt, that package is quite stable |
| 2023-04-18 12:14:40 +0200 | <hellwolf[m]> | (I am using the latest cabal index) |
| 2023-04-18 12:16:31 +0200 | nain | (~nain@169.150.196.132) (Remote host closed the connection) |
| 2023-04-18 12:20:20 +0200 | <probie> | I'm on 3.2.2.0 for parallel. I'm also on Linux. |
| 2023-04-18 12:23:25 +0200 | <hellwolf[m]> | yea, me too |
| 2023-04-18 12:23:25 +0200 | <hellwolf[m]> | I am out of idea :/ |
| 2023-04-18 12:23:25 +0200 | <hellwolf[m]> | you also using cabal run? |
| 2023-04-18 12:24:23 +0200 | <probie> | I'm also using `cabal run`. I don't think there's anything wrong with your install. I think `rseq` should actually be insufficient, since that should just be evaluating the tuple to whnf (and not the doubles). Maybe `-O2` is doing something on my machine that it's not doing on yours? |
| 2023-04-18 12:26:05 +0200 | <hellwolf[m]> | how could that be :) |
| 2023-04-18 12:26:35 +0200 | <hellwolf[m]> | model name : Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz |
| 2023-04-18 12:26:40 +0200 | <hellwolf[m]> | NixOS 22.05 |
| 2023-04-18 12:26:44 +0200 | <hellwolf[m]> | what else can be different :) |
| 2023-04-18 12:28:45 +0200 | <probie> | Nevermind, I think it is just differences in the code, we're running. Since I still had `let rs = parMap (rpar `dot` rdeepseq) ...` instead of `let rs = map ...`, evaluating the tuple to whnf was actually causing full evaluation, which is why `rseq` was working for me |
| 2023-04-18 12:29:06 +0200 | <probie> | s/code, we/code we/ |
| 2023-04-18 12:30:45 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-04-18 12:31:49 +0200 | vglfr | (~vglfr@46.96.155.105) (Ping timeout: 276 seconds) |
| 2023-04-18 12:34:08 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-04-18 12:35:27 +0200 | <maralorn> | My programming has a Productivity 88.8% of total user, 92.8% of total elapsed. I have heard that’s "too low". Yet, my eventlog doesn’t really look like it’s keeping more data in memory than it should. So is this productivity something I should just accept or is it still probably indicative of a problem? |
| 2023-04-18 12:36:01 +0200 | <maralorn> | s/programming/program/ |
| 2023-04-18 12:47:45 +0200 | <[exa]> | who measured your productivity? |
| 2023-04-18 12:47:48 +0200 | <[exa]> | I'd blame them. |
| 2023-04-18 12:59:11 +0200 | xff0x | (~xff0x@2405:6580:b080:900:47f6:92dd:c4d9:cca7) |
| 2023-04-18 13:01:40 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) |
| 2023-04-18 13:04:26 +0200 | <Inst> | hmmm, not sure, but this might be a problem with using System.Process |
| 2023-04-18 13:04:36 +0200 | zeenk | (~zeenk@2a02:2f0e:7900:da01:b4a3:67c4:d0e3:beb0) (Remote host closed the connection) |
| 2023-04-18 13:04:40 +0200 | <Inst> | stdout via Windows might not be the same as on Posix systems |
| 2023-04-18 13:05:43 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-04-18 13:09:20 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-18 13:17:48 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-18 13:21:13 +0200 | jjhoo | (~jahakala@user/jjhoo) (Ping timeout: 252 seconds) |
| 2023-04-18 13:21:15 +0200 | mikko | (~mikko@user/mikko) (Ping timeout: 260 seconds) |
| 2023-04-18 13:22:52 +0200 | vglfr | (~vglfr@46.96.155.105) |
| 2023-04-18 13:23:10 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 276 seconds) |
| 2023-04-18 13:23:23 +0200 | jjhoo | (~jahakala@user/jjhoo) |
| 2023-04-18 13:28:51 +0200 | <hellwolf[m]> | <maralorn> "My programming has a Productivit..." <- Have you fed that into threadscope to examine in details? |
| 2023-04-18 13:28:51 +0200 | <hellwolf[m]> | Sometimes it could be too-eager GC activity, and RTS option related to GC could be used to tune that. |
| 2023-04-18 13:31:34 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 13:36:11 +0200 | mikko | (~mikko@dsl-trebng22-58c1a8-185.dhcp.inet.fi) |
| 2023-04-18 13:36:12 +0200 | mikko | (~mikko@dsl-trebng22-58c1a8-185.dhcp.inet.fi) (Changing host) |
| 2023-04-18 13:36:12 +0200 | mikko | (~mikko@user/mikko) |
| 2023-04-18 13:40:53 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-04-18 13:42:07 +0200 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-04-18 13:43:15 +0200 | ft | (~ft@p4fc2a88b.dip0.t-ipconnect.de) |
| 2023-04-18 13:46:45 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2023-04-18 13:49:50 +0200 | <dminuoso> | Is there a fancy way to test whether the most-significant bit is set? |
| 2023-04-18 13:51:09 +0200 | <Rembane> | dminuoso: Do you want more fancy than bit-anding with the greatest power of two of the number and then checking if the result is not equal to zero? |
| 2023-04-18 13:51:28 +0200 | <dminuoso> | Something as sleek as countLeadingZeros without having to update to GHC 9.6 :p |
| 2023-04-18 13:51:28 +0200 | <Rembane> | Where number is number data type. |
| 2023-04-18 13:51:32 +0200 | <Rembane> | Oh |
| 2023-04-18 13:52:02 +0200 | <Rembane> | Can you copy-paste the function into your codebase? :) |
| 2023-04-18 13:52:37 +0200 | <ncf> | why do you need GHC 9.6 for that? it was added in base 4.8 |
| 2023-04-18 13:52:58 +0200 | <dminuoso> | ncf: Ohh! I totally read that as base 4.18 |
| 2023-04-18 13:53:11 +0200 | <dminuoso> | I wish we didnt have that decoupled base versioning |
| 2023-04-18 13:53:15 +0200 | <dminuoso> | Its incredibly confusing |
| 2023-04-18 13:53:23 +0200 | <dminuoso> | Thanks that helps |
| 2023-04-18 13:53:32 +0200 | <ncf> | i'd just use finiteBitSize with testBit though |
| 2023-04-18 13:53:48 +0200 | <dminuoso> | Mmm. I guess that works too. |
| 2023-04-18 13:54:10 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-04-18 13:55:26 +0200 | <tomsmeding> | testBit is probably faster, given that countLeadingZeros is more powerful (though perhaps the difference will be small in practice) |
| 2023-04-18 13:56:11 +0200 | <dminuoso> | tomsmeding: Oh I know. Im overoptimizing code I know to be in the coldest path of the stack mostly just because its fun. |
| 2023-04-18 13:56:23 +0200 | <dminuoso> | So that argument weighs heavily now. |
| 2023-04-18 13:56:33 +0200 | <dminuoso> | Damn. |
| 2023-04-18 13:57:39 +0200 | <tomsmeding> | :D |
| 2023-04-18 13:57:40 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2023-04-18 13:58:17 +0200 | <dminuoso> | But seriously, I think sometimes its good practice to write space or time optimized code, even if its not necessary |
| 2023-04-18 13:58:23 +0200 | <dminuoso> | Especially if you dont get to do this otherwise |
| 2023-04-18 13:58:36 +0200 | <dminuoso> | If it occurs in library code, there's at least a good chance it might help somebody./ |
| 2023-04-18 14:00:04 +0200 | anpad | (~pandeyan@user/anpad) |
| 2023-04-18 14:01:55 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 14:04:59 +0200 | vglfr | (~vglfr@46.96.155.105) (Ping timeout: 260 seconds) |
| 2023-04-18 14:05:55 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2023-04-18 14:11:58 +0200 | ryantrinkle | (~ryantrink@38.27.99.245) |
| 2023-04-18 14:12:27 +0200 | acidjnk | (~acidjnk@p200300d6e715c44958402cbcae5898a8.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-04-18 14:19:03 +0200 | zer0bitz_ | (~zer0bitz@2001:2003:f443:d600:a0d9:2bf4:3f2:ae1) () |
| 2023-04-18 14:23:28 +0200 | zer0bitz | (~zer0bitz@2001:2003:f443:d600:a0d9:2bf4:3f2:ae1) |
| 2023-04-18 14:25:22 +0200 | ChanServ | +o litharge |
| 2023-04-18 14:25:23 +0200 | litharge | -bo lambdap237!*@*$##fix_your_connection litharge |
| 2023-04-18 14:29:07 +0200 | <dminuoso> | Unrelatedly, if you roundtrip a Word8 through Word16 via fromIntegral, is there an actual guarantee this will preserve the original number? |
| 2023-04-18 14:29:22 +0200 | <dminuoso> | The Haskell Report is very silent on this. The only extremely vague is this: |
| 2023-04-18 14:29:28 +0200 | <dminuoso> | For coercing between any two integer types, use fromIntegral. Coercing word types (see Data.Word) to |
| 2023-04-18 14:29:31 +0200 | <dminuoso> | and from integer types preserves representation, not sign. |
| 2023-04-18 14:30:04 +0200 | <dminuoso> | Very sadly, it doesnt really say anything else about what fromIntegral even does when the input number does not fit into the output type. |
| 2023-04-18 14:30:07 +0200 | acidjnk | (~acidjnk@p200300d6e715c449cd2640c690c889f7.dip0.t-ipconnect.de) |
| 2023-04-18 14:31:52 +0200 | vglfr | (~vglfr@88.155.49.118) |
| 2023-04-18 14:32:20 +0200 | elain4 | (~textual@2601:5c0:8200:990:98bc:8094:4755:4c83) |
| 2023-04-18 14:32:23 +0200 | <[exa]> | that's truly vaguest. |
| 2023-04-18 14:34:00 +0200 | <dminuoso> | The only other bit I can find is in the example code of the prelude mentioning `fromIntegral = fromInteger . toInteger` |
| 2023-04-18 14:34:24 +0200 | <dminuoso> | But the standard prescribes no behavior to fromInteger |
| 2023-04-18 14:35:31 +0200 | qhong | (~qhong@DN160vrd000d6kpg009l6c0000fj.stanford.edu) |
| 2023-04-18 14:35:32 +0200 | <probie> | dminuoso: which also means how literals are handled is underspecified :'). What is `256 :: Word8` according to the report? |
| 2023-04-18 14:35:34 +0200 | <dminuoso> | What's a little worrying is that 23.1 Unsigned integral types mentions |
| 2023-04-18 14:35:40 +0200 | <dminuoso> | `All arithmetic is performed modulo 2ˆn, where n is the number of bits in the type.` |
| 2023-04-18 14:36:42 +0200 | <dminuoso> | So with a slight bit of creativitiy, you could read into that that (fromIntegral x) doesnt truncate but gives you (x `mod` maxBound) |
| 2023-04-18 14:37:04 +0200 | <dminuoso> | which wouldnt quite work in general, as fromIntegral doesnt require Bounded. |
| 2023-04-18 14:37:26 +0200 | <dminuoso> | probie: Pretty sure that desugars into a use of fromIntegral |
| 2023-04-18 14:37:45 +0200 | <dminuoso> | but then again, no, I would have found that mention |
| 2023-04-18 14:38:06 +0200 | <dminuoso> | Ah no it is |
| 2023-04-18 14:38:12 +0200 | <probie> | No, it desugars into `fromInteger` |
| 2023-04-18 14:38:19 +0200 | <dminuoso> | Translation: The integer literal i is equivalent to fromInteger i , where fromInteger is a method in class Num (see Section 6.4.1). |
| 2023-04-18 14:38:41 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-04-18 14:38:51 +0200 | <dminuoso> | So judging from this, an implementation that just does (`mod` maxBound) seems compliant. |
| 2023-04-18 14:39:10 +0200 | <dminuoso> | though no, again that doesnt work without the Bounded constraint |
| 2023-04-18 14:39:49 +0200 | <dminuoso> | From an implementation point of view there's obviously only one thing to do (which is to truncate MSBs) - but its just a little disturbing that its not specified. |
| 2023-04-18 14:40:19 +0200 | <__monty__> | ¯\_(ツ)_/¯ (`mod` 2^∞) seems perfectly cromulent to me. |
| 2023-04-18 14:40:49 +0200 | <probie> | dminuoso: what predefined Integral types apart from Integer aren't instances of Bounded? |
| 2023-04-18 14:40:55 +0200 | <dminuoso> | __monty__: thing is, Amazon is out of ∞GiB memory modules. |
| 2023-04-18 14:41:02 +0200 | <dminuoso> | So I cant work with that (yet) |
| 2023-04-18 14:41:31 +0200 | <dminuoso> | probie: Integer |
| 2023-04-18 14:41:37 +0200 | <__monty__> | But that would imply you can only use Bounded types anyway, so it still reduces to not being a practical worry ; ) |
| 2023-04-18 14:42:52 +0200 | <probie> | `mod` 2^∞ is just id |
| 2023-04-18 14:42:52 +0200 | y04nn | (~username@2a03:1b20:5:f011::aaae) |
| 2023-04-18 14:43:17 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-18 14:43:35 +0200 | <dminuoso> | probie: Im still running quickcheck tests on that to be sure. |
| 2023-04-18 14:43:39 +0200 | <dminuoso> | Will let you know when its done. |
| 2023-04-18 14:43:55 +0200 | <dminuoso> | Actually, we dont need a Bounded constraint on Integral |
| 2023-04-18 14:44:09 +0200 | <dminuoso> | Its sufficient for Num to carry the modulo behavior on fromInteger |
| 2023-04-18 14:44:16 +0200 | <dminuoso> | So I guess it *is* compliant./ |
| 2023-04-18 14:44:40 +0200 | <dminuoso> | (`mod` maxBound) is conforming then. |
| 2023-04-18 14:45:18 +0200 | y04nn | (~username@2a03:1b20:5:f011::aaae) (Read error: Connection reset by peer) |
| 2023-04-18 14:48:30 +0200 | <mauke> | did you mean `mod` (maxBound + 1) |
| 2023-04-18 14:49:04 +0200 | <dminuoso> | mauke: mmm, yeah I suppose. |
| 2023-04-18 14:50:31 +0200 | <mauke> | .oO( I know my standard C unsigned integer semantics ) |
| 2023-04-18 15:03:02 +0200 | barcisz90 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 15:04:43 +0200 | barcisz9048 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 15:06:51 +0200 | elain4 | (~textual@2601:5c0:8200:990:98bc:8094:4755:4c83) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2023-04-18 15:07:10 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 276 seconds) |
| 2023-04-18 15:08:28 +0200 | barcisz90 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 276 seconds) |
| 2023-04-18 15:11:40 +0200 | hayden_ | (~hayden@158.123.160.43) (Quit: Leaving) |
| 2023-04-18 15:11:48 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-18 15:16:25 +0200 | hayden_ | (~hayden@158.123.160.43) (Remote host closed the connection) |
| 2023-04-18 15:16:32 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2023-04-18 15:16:42 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-18 15:23:19 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 15:23:27 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6486:e69a:524e:7c3f) |
| 2023-04-18 15:24:31 +0200 | heraldo | (~heraldo@user/heraldo) |
| 2023-04-18 15:27:02 +0200 | hayden_ | (~hayden@158.123.160.43) (Quit: Leaving) |
| 2023-04-18 15:28:00 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6486:e69a:524e:7c3f) (Ping timeout: 248 seconds) |
| 2023-04-18 15:30:03 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2023-04-18 15:33:01 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2023-04-18 15:33:52 +0200 | heraldo | (~heraldo@user/heraldo) (Ping timeout: 248 seconds) |
| 2023-04-18 15:38:17 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-18 15:38:17 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-18 15:38:17 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-18 15:39:03 +0200 | pyook | (~puke@user/puke) (Ping timeout: 255 seconds) |
| 2023-04-18 15:41:58 +0200 | barcisz904811 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 15:44:11 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 250 seconds) |
| 2023-04-18 15:45:31 +0200 | barcisz9048 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 276 seconds) |
| 2023-04-18 15:48:39 +0200 | dsrt^ | (~dsrt@c-76-105-96-13.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2023-04-18 15:54:56 +0200 | barcisz904811100 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 15:54:57 +0200 | AlexNoo_ | AlexNoo |
| 2023-04-18 15:56:24 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 15:57:30 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-18 15:58:25 +0200 | barcisz904811 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 240 seconds) |
| 2023-04-18 15:59:05 +0200 | barcisz904811100 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 240 seconds) |
| 2023-04-18 16:06:48 +0200 | <ski> | > (10 :: Word8) `mod` (maxBound + 1) |
| 2023-04-18 16:06:49 +0200 | <lambdabot> | *Exception: divide by zero |
| 2023-04-18 16:08:25 +0200 | <ski> | (although, obviously we ought to have `mod n 0 = n' .. cf. `gcd 0 0 = 0') |
| 2023-04-18 16:11:10 +0200 | elain4 | (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) |
| 2023-04-18 16:11:19 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 256 seconds) |
| 2023-04-18 16:13:05 +0200 | barcisz71 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 16:14:03 +0200 | acidjnk | (~acidjnk@p200300d6e715c449cd2640c690c889f7.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2023-04-18 16:16:07 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 252 seconds) |
| 2023-04-18 16:16:58 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-04-18 16:17:40 +0200 | barcisz71 | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 265 seconds) |
| 2023-04-18 16:19:38 +0200 | <dminuoso> | ski: hah I see a recursive problem here. |
| 2023-04-18 16:20:00 +0200 | <dminuoso> | but we can fix that with sprinkling in some toInteger |
| 2023-04-18 16:20:04 +0200 | thegeekinside | (~thegeekin@189.180.119.50) |
| 2023-04-18 16:20:38 +0200 | <dminuoso> | Mmm, not entirely though |
| 2023-04-18 16:22:32 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-04-18 16:22:33 +0200 | <ski> | recursive problem ? |
| 2023-04-18 16:23:42 +0200 | <dminuoso> | Well I suppose we cant sensibly implement fromIntegral in terms of `mod` |
| 2023-04-18 16:24:39 +0200 | <dminuoso> | To get maxBound + 1 to work right, you would go through toInteger for the modular arithmatic to work right, we would need a separate fromIntegral (one that explicitly truncates) |
| 2023-04-18 16:24:50 +0200 | <dminuoso> | To get back to the original type |
| 2023-04-18 16:25:07 +0200 | <ski> | @type fromInteger |
| 2023-04-18 16:25:08 +0200 | <lambdabot> | Num a => Integer -> a |
| 2023-04-18 16:25:19 +0200 | <dminuoso> | Right, but as per haskell report its behavior is not defined |
| 2023-04-18 16:25:33 +0200 | <dminuoso> | (whether we talk about fromInteger or fromIntegral is pretty much irrelevant) |
| 2023-04-18 16:25:50 +0200 | <dminuoso> | its what sparked my comments |
| 2023-04-18 16:26:15 +0200 | <ski> | mhm |
| 2023-04-18 16:28:13 +0200 | <dminuoso> | But I guess if we look even closer, much of the numeric interface isnt prescribed any behavior. |
| 2023-04-18 16:28:36 +0200 | <dminuoso> | Say what (+) even means/does |
| 2023-04-18 16:28:55 +0200 | <geekosaur> | this is why nobody likes Num |
| 2023-04-18 16:29:12 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2023-04-18 16:29:43 +0200 | <probie> | The interface can't be meaningfully prescribed behaviour, only specific instances of it |
| 2023-04-18 16:29:47 +0200 | <dminuoso> | Is there some general behavior/abstraction in mathematics that encompasses what we tend to mean by addition? |
| 2023-04-18 16:29:54 +0200 | <dminuoso> | probie: why *cant* it? |
| 2023-04-18 16:30:21 +0200 | <probie> | Because all `Num` promises is that `(+) :: a -> a -> a`. It can't promise semantics for new instances |
| 2023-04-18 16:30:30 +0200 | <dminuoso> | Surely with denotational semantics there should be some mathematical model to pin it to. |
| 2023-04-18 16:30:50 +0200 | <dminuoso> | probie: it can easily mandate laws. |
| 2023-04-18 16:31:04 +0200 | <probie> | It can suggest laws |
| 2023-04-18 16:31:05 +0200 | <dminuoso> | Like it does for Functor |
| 2023-04-18 16:31:55 +0200 | <dminuoso> | Well the haskell report phrases stronger than a suggestion. |
| 2023-04-18 16:32:01 +0200 | <dminuoso> | They state that instances "should satisfy..." |
| 2023-04-18 16:32:03 +0200 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-04-18 16:32:17 +0200 | <probie> | should isn't must |
| 2023-04-18 16:32:25 +0200 | <dminuoso> | but its stronger than `may` |
| 2023-04-18 16:34:20 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-18 16:35:51 +0200 | <probie> | without falling back to something like "the expected behaviour of addition", what would like the report to say? |
| 2023-04-18 16:36:16 +0200 | <probie> | s/would like/would you like/ |
| 2023-04-18 16:37:28 +0200 | <probie> | remember, you can't even ask for something like associativity because we have floats and doubles |
| 2023-04-18 16:37:42 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2023-04-18 16:39:51 +0200 | <dminuoso> | Yes, that may be a good thing even. |
| 2023-04-18 16:40:06 +0200 | <dminuoso> | It might teach people that float/double really isnt the same as integers. |
| 2023-04-18 16:40:41 +0200 | <dminuoso> | To give you an interface that *looks* like it has all the same properties and laws of standard algebra with integers might have been one of the worst things that langauges have done with IEEE 754 |
| 2023-04-18 16:41:04 +0200 | acidjnk | (~acidjnk@p200300d6e715c424008a03a563343fd8.dip0.t-ipconnect.de) |
| 2023-04-18 16:41:19 +0200 | <geekosaur> | isn't there some variant algebra which covers (even was built around) IEEE 754? |
| 2023-04-18 16:41:44 +0200 | ski | idly notes that `real' in SML was demoted from `eqtype' status, due to floating-point imprecision |
| 2023-04-18 16:42:42 +0200 | hayden_ | (~hayden@158.123.160.43) |
| 2023-04-18 16:43:25 +0200 | hayden_ | (~hayden@158.123.160.43) (Remote host closed the connection) |
| 2023-04-18 16:51:05 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 16:54:20 +0200 | Inst | (~Inst@2601:6c4:4081:54f0:71a6:8347:491d:ec1e) (Read error: Connection reset by peer) |
| 2023-04-18 16:55:55 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds) |
| 2023-04-18 17:09:31 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-04-18 17:11:17 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 250 seconds) |
| 2023-04-18 17:13:31 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
| 2023-04-18 17:14:11 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6486:e69a:524e:7c3f) |
| 2023-04-18 17:15:54 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-18 17:16:14 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) |
| 2023-04-18 17:19:19 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-18 17:23:45 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-04-18 17:33:05 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds) |
| 2023-04-18 17:35:17 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-04-18 17:36:51 +0200 | <carbolymer> | I'm troubleshooting haskdogs, and it seems that `ghc-pkg find-module Data.Aeson` this does not find aeson package. Should I do something to make cabal update ghc-pkg database? |
| 2023-04-18 17:37:42 +0200 | ub | (~Thunderbi@p200300ecdf114f0c8b5919de55b87561.dip0.t-ipconnect.de) |
| 2023-04-18 17:38:01 +0200 | ubert | (~Thunderbi@p548c84d6.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2023-04-18 17:38:01 +0200 | ubert1 | ubert |
| 2023-04-18 17:38:01 +0200 | ubert | 082AASMYS |
| 2023-04-18 17:38:01 +0200 | ub | 074AAT82Q |
| 2023-04-18 17:38:18 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 17:40:00 +0200 | <geekosaur> | --package-db ~/.cabal/store/ghc-<version> |
| 2023-04-18 17:40:46 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-18 17:40:48 +0200 | <geekosaur> | hm, actually that might need to point at the package db and not just the directoryy it's in |
| 2023-04-18 17:41:06 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) |
| 2023-04-18 17:41:18 +0200 | <geekosaur> | --package-db ~/.cabal/store/ghc-<version>/package.db |
| 2023-04-18 17:43:41 +0200 | econo | (uid147250@user/econo) |
| 2023-04-18 17:43:58 +0200 | <carbolymer> | hmm, how can I get this path using cabal? i.e. I have different ghc versions for different projects |
| 2023-04-18 17:44:08 +0200 | <carbolymer> | or how can I get short ghc version from ghc itself? |
| 2023-04-18 17:44:46 +0200 | <monochrom> | ghc --numeric-version :) |
| 2023-04-18 17:47:02 +0200 | <geekosaur> | also this is the entire store, not limited to the versions associated with a given package |
| 2023-04-18 17:47:11 +0200 | <geekosaur> | I'm not sure how you get that |
| 2023-04-18 17:47:25 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Ping timeout: 252 seconds) |
| 2023-04-18 17:48:13 +0200 | <carbolymer> | monochrom: thx |
| 2023-04-18 17:48:24 +0200 | <carbolymer> | now it resolved aeson, but it can't resolve Prelude >.> |
| 2023-04-18 17:48:58 +0200 | <geekosaur> | looks like that is dist-newstyle/packagedb/ghc-<version> |
| 2023-04-18 17:49:20 +0200 | <geekosaur> | right, you'll need a separate package-db option to re-include the global package db |
| 2023-04-18 17:50:11 +0200 | <monochrom> | Are you trying to reinvent my https://github.com/treblacy/hasdoc ? >:) |
| 2023-04-18 17:50:59 +0200 | <geekosaur> | haskdogs is a tags file generator |
| 2023-04-18 17:51:20 +0200 | <geekosaur> | which doesn't know about cabal or stack so it fails on those |
| 2023-04-18 17:51:35 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-18 17:51:39 +0200 | <carbolymer> | geekosaur: actually it does, but I don't know why it started failing now |
| 2023-04-18 17:53:15 +0200 | <carbolymer> | https://github.com/grwlf/haskdogs/blob/master/src/Main.hs#L202 |
| 2023-04-18 17:53:50 +0200 | <geekosaur> | oh, hm, while the cache references stuff in the store, it doesn't contain them. not sure how you get a package-db that references only the versions/builds in the store that a given cabal package actually uses |
| 2023-04-18 17:55:10 +0200 | <geekosaur> | (which I assume would be needed to actually build the package with all the right versions) |
| 2023-04-18 17:57:54 +0200 | <sclv> | this old-style interaction with the packagedb just won’t work anymore imho |
| 2023-04-18 17:57:58 +0200 | <carbolymer> | et voila! |
| 2023-04-18 17:57:58 +0200 | <carbolymer> | haskdogs --use-stack OFF --deps-dir "$XDG_DATA_HOME/haskdogs" --ghc-pkg-args "--package-db $CABAL_DIR/store/ghc-`ghc --numeric-version`/package.db --package-db `ghc --print-global-package-db`" |
| 2023-04-18 17:57:59 +0200 | kspalaiologos | (~kspalaiol@user/kspalaiologos) |
| 2023-04-18 17:58:19 +0200 | <sclv> | or i guess will, but is janky |
| 2023-04-18 17:58:27 +0200 | <carbolymer> | janky af |
| 2023-04-18 17:58:48 +0200 | <carbolymer> | but it's what we've got so ¯\_(ツ)_/¯ |
| 2023-04-18 17:58:57 +0200 | <sclv> | if the goal is just to scan for lists of deps or something i’d think it can be done more directly |
| 2023-04-18 17:59:03 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:7947:e8a0:99b6:e45a) (Quit: WeeChat 2.8) |
| 2023-04-18 17:59:37 +0200 | <sclv> | like with a plan.json or the like |
| 2023-04-18 18:00:04 +0200 | kspalaiologos | (~kspalaiol@user/kspalaiologos) (Client Quit) |
| 2023-04-18 18:00:20 +0200 | <monochrom> | You can just say --package-db global |
| 2023-04-18 18:01:06 +0200 | <monochrom> | err, actually you can just say --global |
| 2023-04-18 18:01:50 +0200 | <janus> | wz1000: the download link in your discourse post is also broken. should use underscores, not dots. e.g. 9_4_5 not 9.4.5 |
| 2023-04-18 18:03:35 +0200 | <carbolymer> | monochrom: ooh, that's nice, thanks! |
| 2023-04-18 18:04:54 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6486:e69a:524e:7c3f) (Remote host closed the connection) |
| 2023-04-18 18:08:01 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2023-04-18 18:12:13 +0200 | <janus> | interesting that haskell.org just returns 500 if there are two dots in the extension |
| 2023-04-18 18:12:23 +0200 | <janus> | almost thought there was something wrong with server at first |
| 2023-04-18 18:14:44 +0200 | <monochrom> | I don't think that's true. https://downloads.haskell.org/~ghc/9.2.5/docs/users_guide.html.tar.xz has two dots in the extension and works. |
| 2023-04-18 18:14:46 +0200 | berberman | (~berberman@user/berberman) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-04-18 18:15:07 +0200 | berberman | (~berberman@user/berberman) |
| 2023-04-18 18:16:59 +0200 | <janus> | downloads is different, that's true. but e.g. https://www.haskell.org/ghc/download_ghc_9.4.5.html looks so innocent, yet explodes |
| 2023-04-18 18:17:32 +0200 | <janus> | the URLs look static, that makes it more surprising that it can make a 500 |
| 2023-04-18 18:18:18 +0200 | <monochrom> | Oh! Internal error, not even 404, yeah that's a GHC panic. :) |
| 2023-04-18 18:21:05 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-18 18:21:25 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) |
| 2023-04-18 18:24:00 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 248 seconds) |
| 2023-04-18 18:25:22 +0200 | vpan | (~0@mail.elitnet.lt) (Quit: Leaving.) |
| 2023-04-18 18:34:59 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-04-18 18:38:33 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-18 18:45:46 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-18 18:50:14 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2023-04-18 18:51:35 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 18:53:31 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-18 18:55:53 +0200 | 082AASMYS | (~Thunderbi@2a02:8109:abc0:6434:b660:4b0:ed52:1706) (Remote host closed the connection) |
| 2023-04-18 18:56:03 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2023-04-18 18:59:32 +0200 | <wz1000> | janus: fixed, thanks |
| 2023-04-18 19:03:48 +0200 | Square | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2023-04-18 19:06:27 +0200 | Nolrai | (~Nolrai@c-98-232-218-193.hsd1.or.comcast.net) |
| 2023-04-18 19:11:35 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-04-18 19:13:11 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-04-18 19:14:46 +0200 | trev | (~trev@user/trev) |
| 2023-04-18 19:19:14 +0200 | oac | (~oac@50-93-248-155.fttp.usinternet.com) |
| 2023-04-18 19:25:25 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-04-18 19:27:00 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2023-04-18 19:28:40 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2023-04-18 19:30:01 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-183-107.46.114.pool.telefonica.de) (Ping timeout: 240 seconds) |
| 2023-04-18 19:31:50 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-178-126.46.114.pool.telefonica.de) |
| 2023-04-18 19:33:27 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-18 19:33:48 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 19:34:10 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) |
| 2023-04-18 19:38:57 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-18 19:44:08 +0200 | <sm> | not yet.. |
| 2023-04-18 19:45:01 +0200 | <sm> | lots of nice fixes in 9.4.5 ❤️ |
| 2023-04-18 19:45:48 +0200 | <c_wraith> | Is 9.6 going to have a similar release? |
| 2023-04-18 19:50:11 +0200 | <geekosaur> | I think this is mostly backports from 9.6? |
| 2023-04-18 19:52:33 +0200 | ubert | (~Thunderbi@p548c84d6.dip0.t-ipconnect.de) |
| 2023-04-18 19:52:48 +0200 | <geekosaur> | no milestone for 9.6.2, one open issue for 9.2.8, no milestone for 9.4.6 |
| 2023-04-18 19:52:49 +0200 | 074AAT82Q | (~Thunderbi@p200300ecdf114f0c8b5919de55b87561.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2023-04-18 19:53:28 +0200 | <geekosaur> | oh whoops, milestone list oisn't sorted |
| 2023-04-18 19:53:49 +0200 | <geekosaur> | 9.6.2 -> 29 issues open |
| 2023-04-18 20:09:13 +0200 | Nolrai | (~Nolrai@c-98-232-218-193.hsd1.or.comcast.net) (Quit: Client closed) |
| 2023-04-18 20:10:39 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2023-04-18 20:11:04 +0200 | hgolden | (~hgolden@cpe-172-251-233-141.socal.res.rr.com) |
| 2023-04-18 20:13:25 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 20:20:17 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) (Remote host closed the connection) |
| 2023-04-18 20:20:36 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) |
| 2023-04-18 20:24:10 +0200 | msavoritias | (cb716af6b3@irc.cheogram.com) (Ping timeout: 260 seconds) |
| 2023-04-18 20:26:56 +0200 | ph88 | (~ph88@84-29-20-195.cable.dynamic.v4.ziggo.nl) (Quit: Leaving) |
| 2023-04-18 20:27:05 +0200 | jpds2 | (~jpds@gateway/tor-sasl/jpds) |
| 2023-04-18 20:27:12 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-04-18 20:27:52 +0200 | grnman_ | (~michaelsc@c-66-176-3-51.hsd1.fl.comcast.net) |
| 2023-04-18 20:28:34 +0200 | msavoritias | (cb716af6b3@irc.cheogram.com) |
| 2023-04-18 20:28:43 +0200 | <Guillaum[m]> | At which point is it completely insane to build an `Ord` instance based on `Hashable`, something such as `compare a b = if a == b then EQ else compare (hash a) (hash b)`. (Actually, I'm thinking about something a bit more evoluted where if comparing on hash returns EQ, I'll use another salt. |
| 2023-04-18 20:28:43 +0200 | <Guillaum[m]> | X problem: I'm removing an Ord instance on a datastructure because it was buggy, not lawful, slow and leading to confusion and unfortunately somewhere in the codebase it does not build anymore because we use a Map based lru cache. |
| 2023-04-18 20:28:43 +0200 | <Guillaum[m]> | Or alternate question: is there a way to recover a "safe" Ord instance based on some other instances? |
| 2023-04-18 20:28:50 +0200 | jpds1 | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 255 seconds) |
| 2023-04-18 20:37:26 +0200 | <monochrom> | If hash has collisions, then "compare (hash a) (hash b)" can give false equality. |
| 2023-04-18 20:37:41 +0200 | <monochrom> | If hash has no collisions, then "a == b" is unnecessary. |
| 2023-04-18 20:38:38 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7843-6da6-1e4a-20b9.rev.sfr.net) (Ping timeout: 260 seconds) |
| 2023-04-18 20:40:36 +0200 | oac | (~oac@50-93-248-155.fttp.usinternet.com) (Remote host closed the connection) |
| 2023-04-18 20:40:58 +0200 | <monochrom> | Ideally you just s/Map/HashMap/ and use unordered-containers and you're done. |
| 2023-04-18 20:41:27 +0200 | hochata | (~user@user/hochata) |
| 2023-04-18 20:41:42 +0200 | <monochrom> | Since HashMap knows how to cope with collisions. |
| 2023-04-18 20:41:44 +0200 | <c_wraith> | ugh, is that my lru-cache? |
| 2023-04-18 20:42:16 +0200 | <c_wraith> | or I guess lrucache |
| 2023-04-18 20:44:04 +0200 | elain4 | (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Quit: Textual IRC Client: www.textualapp.com) |
| 2023-04-18 20:44:48 +0200 | <c_wraith> | I always wanted to go and make the backing type flexible, but every attempt more than doubled the complexity of the API |
| 2023-04-18 20:44:56 +0200 | elain4 | (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) |
| 2023-04-18 20:45:21 +0200 | <Guillaum[m]> | c_wraith: that lrucaching, which handle colision with an internal Ord based datastructure |
| 2023-04-18 20:45:38 +0200 | <c_wraith> | ah, a different one |
| 2023-04-18 20:46:40 +0200 | <Guillaum[m]> | monochrom: and if I use a salt that I increase everytime `compare (hashWithSalt salt a) (hashWithSalt salt b)` returns `Eq`. I'm afraid about some weird behavior of the internal Map because this would not respect the property that if "a < b && b < c => a < c". |
| 2023-04-18 20:46:52 +0200 | <Guillaum[m]> | c_wraith: I'll have a look at `lru-cache`, maybe I may use it as a drop in replacment. |
| 2023-04-18 20:47:09 +0200 | <c_wraith> | nah, it wouldn't help. still needs Ord |
| 2023-04-18 20:47:24 +0200 | <monochrom> | c_wraith: Have you tried, God forbid, backpack? >:D |
| 2023-04-18 20:47:44 +0200 | <c_wraith> | no, that's a thing I haven't tried |
| 2023-04-18 20:47:52 +0200 | <monochrom> | Oh haha OK now you need both hashing and Ord. |
| 2023-04-18 20:49:10 +0200 | <c_wraith> | though I've taken to using backpack features to rename modules to get around changes between library versions. |
| 2023-04-18 20:50:00 +0200 | <monochrom> | A usual way of creating a private Ord and disallowing other people to use it is to create a newtype wrapper and write your Ord for the newtype only, and also not exporting the newtype, so no one else can use it so no harm done. |
| 2023-04-18 20:59:39 +0200 | <Guillaum[m]> | monochrom: that's true. However the `Ord` instance I need to write is HUGE, and I cannot use any generic approach, because actually this type is recursive. But I agree with this approach, maybe I'll write it manually. |
| 2023-04-18 21:11:49 +0200 | pkal | (soju@2a01:4f8:1c1c:bd2c::1) (Killed buffer) |
| 2023-04-18 21:20:45 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-04-18 21:20:49 +0200 | nate1 | (~nate@98.45.169.16) |
| 2023-04-18 21:22:19 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-04-18 21:22:24 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 21:25:25 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2023-04-18 21:25:44 +0200 | elain4 | (~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Quit: Textual IRC Client: www.textualapp.com) |
| 2023-04-18 21:38:39 +0200 | doyougnu | (~doyougnu@cpe-74-69-132-225.stny.res.rr.com) (Ping timeout: 250 seconds) |
| 2023-04-18 21:53:49 +0200 | czy | (~user@host-140-25.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection) |
| 2023-04-18 21:56:14 +0200 | <mmynsted[m]> | I am looking at Data.Function.fix and am unclear about what this is doing and why it is useful. The example shown in the hackage docs makes some sense but not why I should want to do this. |
| 2023-04-18 21:56:25 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-04-18 21:57:36 +0200 | <c_wraith> | mmynsted[m]: It's an abstraction of general recursion, so it can be used for any loop. But you also never need to use it for anything. |
| 2023-04-18 21:57:45 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-04-18 21:57:52 +0200 | vglfr | (~vglfr@88.155.49.118) (Ping timeout: 248 seconds) |
| 2023-04-18 21:58:14 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-04-18 21:58:50 +0200 | <c_wraith> | mmynsted[m]: as a practical use case, sometimes it's nice to declare a loop and run it in the same place without assigning a name to the loop |
| 2023-04-18 22:00:20 +0200 | <monochrom> | mmynsted[m]: See my http://www.vex.net/~trebla/haskell/fix.xhtml |
| 2023-04-18 22:00:38 +0200 | <monochrom> | Oh nevermind, you ask about use cases. |
| 2023-04-18 22:01:18 +0200 | <monochrom> | Well, I guess my article touches on that a little bit too. Anonymous recursion. |
| 2023-04-18 22:01:31 +0200 | <monochrom> | Anonymous, in-place recursion. |
| 2023-04-18 22:03:15 +0200 | <monochrom> | You may have: main = do { v <- newIORef initval; let { myloop = ... }; myloop; ... } |
| 2023-04-18 22:04:01 +0200 | <monochrom> | Sometimes you get tired of that, and this is a tiny little bit nicer: main = do { v <- newIORef initval; fix (\myloop -> ...); ... } |
| 2023-04-18 22:04:37 +0200 | <monochrom> | Sometimes both suck and we still don't know of an elegant way. :) |
| 2023-04-18 22:05:05 +0200 | <c_wraith> | on a recent bit of code, I ran into something like the pattern monochrom is describing, and I wanted to clean it up with a use of fix. So then I figured I might as well use it for all recursion in that module, because why use multiple different approaches? |
| 2023-04-18 22:05:43 +0200 | Sciencentistguy7 | (~sciencent@hacksoc/ordinary-member) |
| 2023-04-18 22:07:09 +0200 | <c_wraith> | (which is also the reason I ended up using STM for all references in the module, even the ones that were never going to be part of a contested transaction) |
| 2023-04-18 22:07:41 +0200 | Sciencentistguy | (~sciencent@hacksoc/ordinary-member) (Ping timeout: 250 seconds) |
| 2023-04-18 22:07:42 +0200 | Sciencentistguy7 | Sciencentistguy |
| 2023-04-18 22:09:40 +0200 | <yushyin> | i have used it in AoC puzzles. as an argument to other higher order functions. keeps some of the solutions a one-liner, what would otherwise be more elegant with a helper function |
| 2023-04-18 22:10:17 +0200 | <mmynsted[m]> | Interesting |
| 2023-04-18 22:12:03 +0200 | <mmynsted[m]> | Still reading through the web link . . . |
| 2023-04-18 22:14:48 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-04-18 22:15:59 +0200 | catch22 | (~catch22@2406:3400:418:d7e0:67c:16ff:fe3e:b769) |
| 2023-04-18 22:16:24 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-04-18 22:20:02 +0200 | <mmynsted[m]> | Okay, nice! Thanks to each of you! It abstracts away the recursion boilerplate making the function its self more visible. |
| 2023-04-18 22:21:12 +0200 | <mmynsted[m]> | I can see how this could be an improvement. |
| 2023-04-18 22:23:26 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-18 22:24:39 +0200 | <Guillaum[m]> | mmynsted: one use case I like with fix is with anonymous recursion and caching / memoization. Imagine you want to cache a function such as `factorial :: Int -> Int`. That's "trivial" to write a "cache" function, something such as: "cache :: (Int -> Int) -> Int -> Int; cache f input = if input in "theCache" then read theCache input else output = f input; writeInTheCache output; ..." (That's pseudo code indeed). |
| 2023-04-18 22:25:28 +0200 | <Guillaum[m]> | mmynsted: have a look at https://hackage.haskell.org/package/memoize-1.1.2/docs/Data-Function-Memoize.html for such an API. However, for recursive function, you cannot apply this pattern, because it will cache the "outer" call, but not the recursive calls |
| 2023-04-18 22:26:20 +0200 | <Guillaum[m]> | mmynsted: If instead your recursion is written in a way that it can be used with "fix", then you can write a function (called memoFix in the above memoize package) which takes care of passing the memoized function to the recursion. |
| 2023-04-18 22:28:03 +0200 | <mmynsted[m]> | Right. I can see that. I am thinking of fibonacci sequence. The numbers are predictable and computed recursively, so I could store the function "result" in a tree or something. The recursive part could be abstracted using `fix`. . . |
| 2023-04-18 22:28:56 +0200 | mmynsted[m] | looks up Data.Function.Memoize |
| 2023-04-18 22:29:50 +0200 | <Guillaum[m]> | Yes, fibonacci is a perfect example of this. (but who uses fibonnaci in real life ? ;) |
| 2023-04-18 22:30:10 +0200 | <mmynsted[m]> | Hahaha good point |
| 2023-04-18 22:34:46 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-04-18 22:34:51 +0200 | <mmynsted[m]> | Wow, I am again so thankful I can go from the Hackage doc directly to the source. |
| 2023-04-18 22:35:56 +0200 | <mmynsted[m]> | There is much going on in Data.Function.Memoize but I can see how this works and would be useful (at least for fibonacci). |
| 2023-04-18 22:37:25 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) (Read error: Connection reset by peer) |
| 2023-04-18 22:38:04 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) |
| 2023-04-18 22:38:20 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-04-18 22:38:21 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-18 22:38:50 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 22:39:31 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Client Quit) |
| 2023-04-18 22:39:53 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) (Read error: Connection reset by peer) |
| 2023-04-18 22:39:54 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 22:40:18 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) |
| 2023-04-18 22:41:53 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) (Read error: Connection reset by peer) |
| 2023-04-18 22:42:19 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) |
| 2023-04-18 22:42:46 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-04-18 22:43:20 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-04-18 22:44:57 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-18 22:45:53 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) (Read error: Connection reset by peer) |
| 2023-04-18 22:46:23 +0200 | AlexNoo | (~AlexNoo@178.34.150.15) |
| 2023-04-18 22:49:04 +0200 | hochata | (~user@user/hochata) (Ping timeout: 248 seconds) |
| 2023-04-18 22:50:25 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-04-18 22:50:25 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-04-18 22:50:25 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-04-18 22:52:43 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) |
| 2023-04-18 22:54:24 +0200 | <mauke> | you can also do this with types: https://hackage.haskell.org/package/data-fix-0.3.2/docs/Data-Fix.html |
| 2023-04-18 22:56:02 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca) |
| 2023-04-18 22:56:26 +0200 | <mauke> | instead of defining a recursive type (like `data IntTree = Leaf Int | Branch IntTree IntTree`) you can leave the recursion open: `data IntTreeX r = Leaf Int | Branch r r` |
| 2023-04-18 22:56:40 +0200 | <mauke> | and then IntTree = Fix IntTreeX |
| 2023-04-18 22:56:47 +0200 | <mauke> | (if you squint a bit) |
| 2023-04-18 22:57:21 +0200 | merijn | (~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds) |
| 2023-04-18 22:58:05 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2023-04-18 23:00:46 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-04-18 23:06:00 +0200 | coot | (~coot@213.134.170.228) (Quit: coot) |
| 2023-04-18 23:06:11 +0200 | <mmynsted[m]> | :-) wow |
| 2023-04-18 23:06:38 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 23:07:01 +0200 | <mmynsted[m]> | Also now fully distracted reading through http://www.vex.net/~trebla/haskell/index.xhtml |
| 2023-04-18 23:07:10 +0200 | <monochrom> | haha |
| 2023-04-18 23:07:27 +0200 | bgs | (~bgs@212.85.160.171) (Remote host closed the connection) |
| 2023-04-18 23:08:34 +0200 | <mmynsted[m]> | I do not think I want to check my cabal defaults... I am sure they are wrong. |
| 2023-04-18 23:10:08 +0200 | <geekosaur> | if you haven't changed anything they're probably fine |
| 2023-04-18 23:10:45 +0200 | <monochrom> | No, some of the defaults actually make no sense for devs. |
| 2023-04-18 23:11:16 +0200 | <monochrom> | Make great sense for non-dev xmonad users, but not devs. |
| 2023-04-18 23:11:31 +0200 | <monochrom> | For example, don't build docs, don't build profiling versions. |
| 2023-04-18 23:12:55 +0200 | <mmynsted[m]> | profiling shows neither True nor False |
| 2023-04-18 23:13:09 +0200 | <monochrom> | For example, symlink exes, setting you up for future broken links because the origins are in some directory you will erase one day just because you move on to a new GHC version and ghcup suggests "you may like to erase that directory now, you don't need it any more". |
| 2023-04-18 23:13:29 +0200 | <mmynsted[m]> | Okay documentation is set to True. :-) |
| 2023-04-18 23:14:03 +0200 | <monochrom> | Although, profiling is now much more interesting than a boolean. |
| 2023-04-18 23:22:40 +0200 | <mmynsted[m]> | Hmm. I am interested in profiling properly. I am guessing that is a rabbit hole for another day. |
| 2023-04-18 23:23:12 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 248 seconds) |
| 2023-04-18 23:28:29 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2023-04-18 23:38:17 +0200 | <tomsmeding> | setting profiling to true by default is not a good idea |
| 2023-04-18 23:38:22 +0200 | <tomsmeding> | slows down compilation considerably :p |
| 2023-04-18 23:38:41 +0200 | <tomsmeding> | iirc |
| 2023-04-18 23:39:30 +0200 | <tomsmeding> | or wait, that's false; it doesn't slow down _compilation_, it slows down your executables because it puts "check points" (cost centres, officially) at every function, meaning that ghc can do a lot less useful inlining |
| 2023-04-18 23:39:51 +0200 | <tomsmeding> | then recently there's -fprof-late or something like that, but details |
| 2023-04-18 23:44:32 +0200 | <monochrom> | True, I normally disable profiling too. |
| 2023-04-18 23:45:21 +0200 | <monochrom> | I also know how to cause profiling to convert a constant-space program to a linear-space program. >:) |
| 2023-04-18 23:46:39 +0200 | <monochrom> | Oh compilation is slowed down too, because turning on profiling means building two binaries, not just one. |
| 2023-04-18 23:46:49 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.) |
| 2023-04-18 23:46:51 +0200 | <monochrom> | Well, two binaries for libraries. |
| 2023-04-18 23:47:02 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) |
| 2023-04-18 23:47:26 +0200 | <sm> | yeah, it doubles compilation time (and disk space for deps) |
| 2023-04-18 23:48:08 +0200 | <sm> | or maybe deps are installed with profiled and non-profiled versions by default these days, not sure |
| 2023-04-18 23:48:28 +0200 | Nolrai | (~Nolrai@c-98-232-218-193.hsd1.or.comcast.net) |
| 2023-04-18 23:49:02 +0200 | <geekosaur> | that's --enable-library-profiling in cabal |
| 2023-04-18 23:50:38 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Quit: Connection closed) |
| 2023-04-18 23:50:59 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) |
| 2023-04-18 23:52:32 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 248 seconds) |
| 2023-04-18 23:53:48 +0200 | Nolrai | (~Nolrai@c-98-232-218-193.hsd1.or.comcast.net) (Quit: Client closed) |
| 2023-04-18 23:54:55 +0200 | smallville7123_ | (~JScript@cpe-172-193-72-46.qld.foxtel.net.au) |
| 2023-04-18 23:57:41 +0200 | JScript | (~JScript@103.137.12.221) (Ping timeout: 256 seconds) |
| 2023-04-18 23:58:09 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-04-18 23:58:25 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca) (Ping timeout: 240 seconds) |
| 2023-04-18 23:59:45 +0200 | barcisz | (~barcisz@79.191.65.29.ipv4.supernova.orange.pl) (Ping timeout: 240 seconds) |
