| 2023-06-21 00:01:26 +0200 | ft | (~ft@p4fc2afc9.dip0.t-ipconnect.de) |
| 2023-06-21 00:02:03 +0200 | <ijqq> | I have haskell language server set up, and now I can go to the definition of functions I've locally defined. When I hover over library functions, e.g. asum from Data.Foldable or intercalate from Data.List, the popup shows a link to the function source code for my local install. However, I can't jump to definition for those library functions. |
| 2023-06-21 00:02:19 +0200 | <ijqq> | Is there a way to make it work so that I am able to do it? |
| 2023-06-21 00:02:56 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-06-21 00:04:43 +0200 | <geekosaur> | not yet |
| 2023-06-21 00:05:18 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-21 00:06:06 +0200 | <geekosaur> | https://github.com/haskell/haskell-language-server/issues/708 |
| 2023-06-21 00:09:50 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-06-21 00:13:00 +0200 | Angelz | (~Angelz@2605:6400:30:fc15:9bd1:2217:41cd:bb15) (Ping timeout: 240 seconds) |
| 2023-06-21 00:13:28 +0200 | <ijqq> | Ah okay, I did see that issue but I thought that since HLS clearly knows where the source file is, there would be a fix. |
| 2023-06-21 00:14:32 +0200 | <ijqq> | Oh nevermind, I missunderstood |
| 2023-06-21 00:14:33 +0200 | <ijqq> | Ignroe me |
| 2023-06-21 00:14:35 +0200 | <ijqq> | Ignore* |
| 2023-06-21 00:15:32 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 00:18:18 +0200 | <ijqq> | I didn't realise the source is just a html page not the actual source |
| 2023-06-21 00:18:44 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 240 seconds) |
| 2023-06-21 00:19:06 +0200 | <ijqq> | Which is obvious oops |
| 2023-06-21 00:19:22 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-06-21 00:20:09 +0200 | pavonia | (~user@user/siracusa) |
| 2023-06-21 00:24:52 +0200 | bilegeek_ | (~bilegeek@79.sub-174-209-41.myvzw.com) (Quit: Leaving) |
| 2023-06-21 00:29:55 +0200 | samhh | (7569f027cf@2604:bf00:561:2000::e4) (Server closed connection) |
| 2023-06-21 00:29:55 +0200 | samhh_ | samhh |
| 2023-06-21 00:30:06 +0200 | samhh_ | (7569f027cf@2604:bf00:561:2000::e4) |
| 2023-06-21 00:34:55 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 00:35:54 +0200 | berberman | (~berberman@user/berberman) (Server closed connection) |
| 2023-06-21 00:36:15 +0200 | berberman | (~berberman@user/berberman) |
| 2023-06-21 00:37:06 +0200 | smoge | (~smoge@2603-7000-4b42-1100-45e9-092e-53fe-8cc3.res6.spectrum.com) (Quit: Client closed) |
| 2023-06-21 00:38:47 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-06-21 00:38:52 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 00:43:43 +0200 | Angelz | (Angelz@2605:6400:30:fc15:d55b:fa6c:bd14:9973) |
| 2023-06-21 00:44:21 +0200 | diod | (~diod@bras-base-london140cw-grc-07-142-112-183-155.dsl.bell.ca) |
| 2023-06-21 00:45:02 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-21 00:49:03 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 00:52:06 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-06-21 00:53:40 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2023-06-21 00:55:35 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2023-06-21 00:55:55 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-06-21 00:59:59 +0200 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) (Server closed connection) |
| 2023-06-21 01:00:08 +0200 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) |
| 2023-06-21 01:00:10 +0200 | canta1 | (~canta@cvm0.d5k.one) (Server closed connection) |
| 2023-06-21 01:00:32 +0200 | canta1 | (~canta@cvm0.d5k.one) |
| 2023-06-21 01:12:56 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 01:13:20 +0200 | Reinhilde | Ellenor |
| 2023-06-21 01:15:21 +0200 | <ijqq> | http://sprunge.us/s3Ta6g would anybody be able to help me? i'm trying to cabal install https://github.com/arybczak/ghc-tags and i get errors about base |
| 2023-06-21 01:16:04 +0200 | <ijqq> | i have ghcup too, but seeing this message i don't really know how to go about fixing it |
| 2023-06-21 01:16:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-06-21 01:17:16 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 252 seconds) |
| 2023-06-21 01:17:31 +0200 | <Nosrep> | newer version of ghc i think |
| 2023-06-21 01:17:39 +0200 | <Nosrep> | 9.6 needed |
| 2023-06-21 01:17:52 +0200 | <ijqq> | is it saying that I need base ver 4.18, but i don't have that installed? |
| 2023-06-21 01:18:13 +0200 | <Nosrep> | think so, don't really use cabal |
| 2023-06-21 01:18:19 +0200 | <Nosrep> | that's the only way i'm reading it that makes sense |
| 2023-06-21 01:18:22 +0200 | <c_wraith> | ijqq: no, it's saying that you have it installed and ghc-tags doesn't say it supports 4.18 |
| 2023-06-21 01:18:39 +0200 | <c_wraith> | and 4.18 just means a recent version of GHC |
| 2023-06-21 01:18:57 +0200 | <c_wraith> | just tell cabal --allow-newer=base |
| 2023-06-21 01:19:45 +0200 | k``` | (~user@136.56.140.2) (Ping timeout: 240 seconds) |
| 2023-06-21 01:19:57 +0200 | <c_wraith> | it *probably* will work. base 4.18 didn't change much that already existed. |
| 2023-06-21 01:20:34 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 252 seconds) |
| 2023-06-21 01:20:39 +0200 | diod | (~diod@bras-base-london140cw-grc-07-142-112-183-155.dsl.bell.ca) (Quit: Client closed) |
| 2023-06-21 01:22:17 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-06-21 01:22:25 +0200 | <ijqq> | i tried this `cabal install --allow-newer=base ghc-tags`it said the same |
| 2023-06-21 01:22:58 +0200 | <ijqq> | btw i'm running this command in a directory where i haven't done any cabal init or anything, maybe that is an issue? |
| 2023-06-21 01:26:52 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-06-21 01:27:20 +0200 | <geekosaur> | no, you shouldn't need to cabal init to install an executable |
| 2023-06-21 01:28:32 +0200 | <geekosaur> | cabal install ghc-tags --allow-newer=base,ghc-prim |
| 2023-06-21 01:28:38 +0200 | <geekosaur> | is working for me |
| 2023-06-21 01:28:56 +0200 | <geekosaur> | or at least it's trying to build now |
| 2023-06-21 01:29:15 +0200 | <ijqq> | oh it's trying to build for me now too |
| 2023-06-21 01:29:21 +0200 | <ijqq> | maybe it was the ghc-prim? |
| 2023-06-21 01:29:33 +0200 | <c_wraith> | probably |
| 2023-06-21 01:29:34 +0200 | <ijqq> | what is that btw? |
| 2023-06-21 01:29:48 +0200 | <c_wraith> | a wrapper exposing a bunch of ghc internals |
| 2023-06-21 01:30:07 +0200 | <c_wraith> | data types, primitives, etc |
| 2023-06-21 01:30:21 +0200 | <ijqq> | ah right |
| 2023-06-21 01:30:41 +0200 | wroathe | (~wroathe@user/wroathe) (Quit: Lost terminal) |
| 2023-06-21 01:33:40 +0200 | <ijqq> | so "constraint from user target" means the requirement imposed by the library i'm trying to install? |
| 2023-06-21 01:34:11 +0200 | <geekosaur> | generally, yes |
| 2023-06-21 01:34:29 +0200 | <geekosaur> | "user target" is what you're installing |
| 2023-06-21 01:34:31 +0200 | exeo | (~exeo@97-119-96-49.omah.qwest.net) |
| 2023-06-21 01:35:36 +0200 | <geekosaur> | but ghc-tags uses ghc-lib and ghc-lib-parser, which have tight version constraints |
| 2023-06-21 01:36:31 +0200 | <ijqq> | http://sprunge.us/wS9zWi |
| 2023-06-21 01:36:38 +0200 | <geekosaur> | ghc-lib-parser just failed for me |
| 2023-06-21 01:36:42 +0200 | <ijqq> | :( |
| 2023-06-21 01:36:56 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 240 seconds) |
| 2023-06-21 01:37:05 +0200 | <ijqq> | yep same |
| 2023-06-21 01:37:47 +0200 | <c_wraith> | So yeah... lots of libraries still aren't compatible with recent versions of ghc. |
| 2023-06-21 01:37:53 +0200 | <geekosaur> | versioning makes me think it's using the one for ghc 9.4, which won't fly with 9.6. trying an allow-newer |
| 2023-06-21 01:40:06 +0200 | <ijqq> | so I have ghcup which allows me to change my ghc install. so is there some way to get cabal to tell me which version of ghc i need in order to install a package? and then I can change my ghc version in ghcup and be assured that there won't be any conflicts? |
| 2023-06-21 01:40:44 +0200 | <c_wraith> | if you use `ghcup tui' it will list what versions of base come with each version of ghc. That's about the most effective approach I know |
| 2023-06-21 01:40:45 +0200 | <geekosaur> | no, because packages only contain that information in the form of constraints on packages that come with ghc |
| 2023-06-21 01:41:02 +0200 | <c_wraith> | as version conflicts are usually on the base package. |
| 2023-06-21 01:41:10 +0200 | <c_wraith> | (though sometimes they aren't... then have fun!) |
| 2023-06-21 01:41:28 +0200 | exeo | (~exeo@97-119-96-49.omah.qwest.net) (Ping timeout: 252 seconds) |
| 2023-06-21 01:41:49 +0200 | <ijqq> | hmm perhaps it is because i'm new and i don't really understand it, but i though the whole installing packages would be a better experience for a cool language like hasklel |
| 2023-06-21 01:41:54 +0200 | <geekosaur> | in this case, ghc-tags excludes the versions of base, ghc-prim, and ghc-lib that come with ghc 9.6, but accept the ones that come with 9.4 |
| 2023-06-21 01:42:24 +0200 | <ijqq> | i mean npm, cargo, pip generally tend to get it right |
| 2023-06-21 01:42:42 +0200 | <ijqq> | ok |
| 2023-06-21 01:42:47 +0200 | <geekosaur> | so cabal install -w ghc-9.4.5 (because I have that 9.4 version installed) |
| 2023-06-21 01:42:59 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2023-06-21 01:43:05 +0200 | <geekosaur> | that said I did an allow-newer on ghc-lib and it seems to be going |
| 2023-06-21 01:43:08 +0200 | <ijqq> | so do i need to change ghc in ghcup? |
| 2023-06-21 01:43:16 +0200 | <ijqq> | to 9.4.x? |
| 2023-06-21 01:43:27 +0200 | <geekosaur> | just install it, you don't have to set it as current, just use -w to specify it |
| 2023-06-21 01:43:37 +0200 | <c_wraith> | npm and pip usually don't get it right, in my experience. |
| 2023-06-21 01:44:03 +0200 | <c_wraith> | cargo does, but mostly because not breaking it is a primary concern in rust. |
| 2023-06-21 01:44:07 +0200 | exeo | (~exeo@97-119-96-49.omah.qwest.net) |
| 2023-06-21 01:46:20 +0200 | aforemny | (~aforemny@2001:9e8:6cef:c900:b77d:1f31:7b2d:1e41) (Ping timeout: 240 seconds) |
| 2023-06-21 01:47:34 +0200 | <ijqq> | yeah fair enough, i just figured the smart haskell guys probably had a good solution for it |
| 2023-06-21 01:47:39 +0200 | <ijqq> | im sure once i get used to it it should be fine |
| 2023-06-21 01:47:53 +0200 | <geekosaur> | stack has a solution, not necessarily the best one |
| 2023-06-21 01:48:01 +0200 | lottaquestions_ | (~nick@2607:fa49:503f:6d00:ed09:2f19:74f7:7b05) (Quit: Konversation terminated!) |
| 2023-06-21 01:48:09 +0200 | <c_wraith> | There really isn't a solution to "people change their libraries, breaking downstream stuff" |
| 2023-06-21 01:48:30 +0200 | <geekosaur> | (the package has to come with a stack.yaml which tells it among other things what ghc version to install) |
| 2023-06-21 01:49:20 +0200 | aforemny | (~aforemny@i59F516E1.versanet.de) |
| 2023-06-21 01:49:24 +0200 | <geekosaur> | okay, ghc-tags really does not support ghc 9.6 |
| 2023-06-21 01:49:27 +0200 | <geekosaur> | use ghc 9.4 |
| 2023-06-21 01:50:42 +0200 | <ijqq> | what i meant is for a library version x, if you can specify all the dependencies down the the commit hash, then it should be possible to recreate that same environment for the person downloading it? |
| 2023-06-21 01:51:06 +0200 | <c_wraith> | ijqq: that doesn't cover how to interoperate with other libraries |
| 2023-06-21 01:51:09 +0200 | bilegeek | (~bilegeek@79.sub-174-209-41.myvzw.com) |
| 2023-06-21 01:51:48 +0200 | <c_wraith> | Admittedly, you're looking at an executable, which is somewhat simpler in that sense. |
| 2023-06-21 01:52:14 +0200 | <c_wraith> | But the general case is that you haven't solved the problem yet by specifying only dependencies |
| 2023-06-21 01:52:29 +0200 | mauke_ | (~mauke@user/mauke) |
| 2023-06-21 01:52:49 +0200 | lottaquestions | (~nick@2607:fa49:503f:6d00:ee98:182c:4ae3:99fe) |
| 2023-06-21 01:53:32 +0200 | <ijqq> | so if i write a library and my library version x depends on two libraries, version y and z and i know this, surely someone else can recreate that build? |
| 2023-06-21 01:54:06 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 01:54:18 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 252 seconds) |
| 2023-06-21 01:54:19 +0200 | mauke_ | mauke |
| 2023-06-21 01:54:23 +0200 | <c_wraith> | but what if they use another library that depends on different versions of the dependencies? |
| 2023-06-21 01:55:52 +0200 | <c_wraith> | Library dependencies can be part of their public interface, not just their implementation |
| 2023-06-21 01:57:31 +0200 | <c_wraith> | cabal v1 not having any answer to this is what led to "cabal hell" and the creation of stack. Cabal v2 has much better answers in place - but they still can't help if you're asking it to do something where the pieces legitimately don't work together |
| 2023-06-21 01:58:04 +0200 | <ijqq> | thanks for the help geekosaur, i've got it working now |
| 2023-06-21 01:58:30 +0200 | <ijqq> | ah yep i see what you mean |
| 2023-06-21 02:04:59 +0200 | gurkenglas | (~user@dynamic-089-204-130-184.89.204.130.pool.telefonica.de) (Ping timeout: 246 seconds) |
| 2023-06-21 02:10:12 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 240 seconds) |
| 2023-06-21 02:13:21 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-06-21 02:13:21 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-06-21 02:13:21 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-21 02:14:48 +0200 | diod | (~diod@bras-base-london140cw-grc-07-142-112-183-155.dsl.bell.ca) |
| 2023-06-21 02:14:57 +0200 | diod | (~diod@bras-base-london140cw-grc-07-142-112-183-155.dsl.bell.ca) () |
| 2023-06-21 02:22:30 +0200 | siers | (~ij@user/ij) (Server closed connection) |
| 2023-06-21 02:22:51 +0200 | siers | (~ij@user/ij) |
| 2023-06-21 02:23:59 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-06-21 02:24:08 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-06-21 02:32:00 +0200 | thegeekinside | (~thegeekin@189.180.9.45) (Ping timeout: 240 seconds) |
| 2023-06-21 02:45:05 +0200 | dsrt^ | (~dsrt@c-71-204-38-59.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2023-06-21 02:47:51 +0200 | catch22 | (~catch22@2406:3400:418:d7e0:67c:16ff:fe3e:b769) (Quit: Leaving) |
| 2023-06-21 02:48:05 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 02:48:35 +0200 | robertm | (robertm@lattice.rojoma.com) (Server closed connection) |
| 2023-06-21 02:48:54 +0200 | robertm | (robertm@lattice.rojoma.com) |
| 2023-06-21 03:05:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-21 03:06:57 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-21 03:08:00 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2023-06-21 03:11:18 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-06-21 03:12:33 +0200 | xff0x_ | (~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 246 seconds) |
| 2023-06-21 03:17:25 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-06-21 03:17:36 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-06-21 03:20:20 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-06-21 03:39:23 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:347f:c197:daa9:fd59) |
| 2023-06-21 03:40:28 +0200 | <Athas> | I really could use a Trifunctor... I guess maybe that's a sign I'm doing something dumb. |
| 2023-06-21 03:42:20 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 240 seconds) |
| 2023-06-21 03:43:05 +0200 | <dsal> | What's that do? |
| 2023-06-21 03:43:32 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:347f:c197:daa9:fd59) (Ping timeout: 240 seconds) |
| 2023-06-21 03:50:26 +0200 | <Axman6> | Trifunctor f where fmap3 :: (a -> b) -> (i -> j) -> (y -> z) -> f a i y -> f b j z? |
| 2023-06-21 03:54:07 +0200 | <probie> | Can we jam in some covariant/contravariant markers so we don't risk needing 8 different classes? :p |
| 2023-06-21 03:54:50 +0200 | <Axman6> | jackdk: Does the FunctorOf stuff help with ^ ? |
| 2023-06-21 04:01:08 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 04:01:57 +0200 | <jackdk> | Axman6: yes, because it just boils down to a functor from (->) to transformations between bifunctors (which could further get boiled down; this is why Iceland_Jack's stuff also wants some idea of "type class backends") |
| 2023-06-21 04:02:05 +0200 | <jackdk> | s/just// |
| 2023-06-21 04:06:33 +0200 | <probie> | If I have two functions which are equivalent (up to functional extensionality), but in some situations I know one is preferable over the other because of some rewrite rules that may fire, is it absurd to go `f = pickDef (def1, def2)` with `pickDef (x,_) = x` (with immediate inlining on `f` and late inlining on `pickDef` so it can be detected by rewrite rules)? |
| 2023-06-21 04:07:11 +0200 | rf | (~rf@2605:59c8:179c:f610:fdc:f9e0:5115:df48) (Ping timeout: 260 seconds) |
| 2023-06-21 04:07:58 +0200 | rf | (~rf@2605:59c8:179c:f610:2cda:5953:da36:7a10) |
| 2023-06-21 04:08:04 +0200 | benjaminbellick | (~user@ool-4575ce40.dyn.optonline.net) |
| 2023-06-21 04:08:56 +0200 | <Axman6> | Sounds like it could be fragile |
| 2023-06-21 04:15:27 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-06-21 04:15:48 +0200 | <Axman6> | Reminds me of some of the work I did on GHC, changing the LLVM backend to using the HDoc type for more efficient file generation - the trick there to make sure things were fast was to include SPECIALISE pragmas for both SDoc and HDoc |
| 2023-06-21 04:17:08 +0200 | <probie> | It's already relying on other rewrite rules, so we're in a fragile space to begin with. The problem is that I have two classes of functions, let's call them A and B. I can cheaply compose 2 As, or 2 Bs or an A with a B, but not a B with an A |
| 2023-06-21 04:18:02 +0200 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 252 seconds) |
| 2023-06-21 04:20:38 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-06-21 04:20:38 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-06-21 04:20:38 +0200 | finn_elija | FinnElija |
| 2023-06-21 04:20:53 +0200 | <probie> | There's also a third class C, which can compose with anything without issue, but I think we can just ignore that |
| 2023-06-21 04:24:53 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2023-06-21 04:26:44 +0200 | phma | (phma@2001:5b0:211f:2f08:1cac:200:a297:82b8) (Read error: Connection reset by peer) |
| 2023-06-21 04:27:10 +0200 | phma | (~phma@host-67-44-208-160.hnremote.net) |
| 2023-06-21 04:27:14 +0200 | falafel | (~falafel@2607:fb91:86c:d890:a3d3:8ef4:9c53:4539) |
| 2023-06-21 04:27:30 +0200 | jargon | (~jargon@32.sub-174-205-224.myvzw.com) |
| 2023-06-21 04:29:56 +0200 | dtman34 | (~dtman34@2601:447:d000:93c9:49a3:2ee1:9e07:c081) (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) |
| 2023-06-21 04:35:38 +0200 | td_ | (~td@i53870919.versanet.de) (Ping timeout: 252 seconds) |
| 2023-06-21 04:36:07 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
| 2023-06-21 04:37:35 +0200 | td_ | (~td@i5387092F.versanet.de) |
| 2023-06-21 04:38:46 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:291c:968d:11e3:9e1a) |
| 2023-06-21 04:41:34 +0200 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:89b:a33a:757:b886) |
| 2023-06-21 04:43:21 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:291c:968d:11e3:9e1a) (Ping timeout: 260 seconds) |
| 2023-06-21 04:44:19 +0200 | xff0x_ | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2023-06-21 04:45:30 +0200 | eggplant_ | (~Eggplanta@2600:1700:38c5:d800:89b:a33a:757:b886) (Ping timeout: 240 seconds) |
| 2023-06-21 04:46:56 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 04:49:10 +0200 | <Axman6> | Hey haskellers... does anyone know what the python name for concat is? relying on my IDE is not working out after using [ ... ].<tab> :') |
| 2023-06-21 04:49:24 +0200 | <dsal> | join? |
| 2023-06-21 04:50:10 +0200 | <dsal> | I've managed to avoid python long enough that none of my python scripts work anymore and I don't know how to fix them. |
| 2023-06-21 04:50:54 +0200 | <Axman6> | yeah I thought that too, but doesn't seem to be a thing |
| 2023-06-21 04:51:09 +0200 | <dsal> | I think join is backwards in python |
| 2023-06-21 04:51:50 +0200 | <jackdk> | It's a method on the delimiter, not the container: `':'.join(['a', 'b', 'c'])` |
| 2023-06-21 04:52:06 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89b:a33a:757:b886) |
| 2023-06-21 04:52:30 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 252 seconds) |
| 2023-06-21 04:55:30 +0200 | <probie> | Axman6: list(itertools.chain(*someList)) |
| 2023-06-21 05:03:36 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 05:05:38 +0200 | srk- | (~sorki@user/srk) |
| 2023-06-21 05:06:11 +0200 | srk| | (~sorki@user/srk) |
| 2023-06-21 05:07:32 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 05:08:18 +0200 | systemhalted | (~systemhal@103.252.216.58) |
| 2023-06-21 05:09:01 +0200 | srk | (~sorki@user/srk) (Ping timeout: 260 seconds) |
| 2023-06-21 05:09:22 +0200 | srk| | srk |
| 2023-06-21 05:09:52 +0200 | srk- | (~sorki@user/srk) (Ping timeout: 240 seconds) |
| 2023-06-21 05:11:08 +0200 | systemhalted | (~systemhal@103.252.216.58) (Remote host closed the connection) |
| 2023-06-21 05:13:12 +0200 | bilegeek | (~bilegeek@79.sub-174-209-41.myvzw.com) (Quit: Leaving) |
| 2023-06-21 05:18:32 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-06-21 05:20:52 +0200 | aforemny | (~aforemny@i59F516E1.versanet.de) (Ping timeout: 240 seconds) |
| 2023-06-21 05:21:49 +0200 | srk- | (~sorki@user/srk) |
| 2023-06-21 05:21:55 +0200 | aforemny | (~aforemny@i59F516E6.versanet.de) |
| 2023-06-21 05:22:12 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Ping timeout: 240 seconds) |
| 2023-06-21 05:22:56 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 240 seconds) |
| 2023-06-21 05:25:20 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2023-06-21 05:25:32 +0200 | srk | (~sorki@user/srk) (Ping timeout: 240 seconds) |
| 2023-06-21 05:25:32 +0200 | srk- | srk |
| 2023-06-21 05:26:57 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (Remote host closed the connection) |
| 2023-06-21 05:27:51 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2023-06-21 05:32:56 +0200 | rf | (~rf@2605:59c8:179c:f610:2cda:5953:da36:7a10) (Ping timeout: 260 seconds) |
| 2023-06-21 05:34:25 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) |
| 2023-06-21 05:38:46 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) |
| 2023-06-21 05:45:33 +0200 | <glguy> | ijqq: are you doing your toml dev on a public repo? |
| 2023-06-21 05:47:41 +0200 | <davean> | Someone is doing toml work? I've been wanting better toml handling. |
| 2023-06-21 05:49:16 +0200 | <glguy> | davean: I've build building a library https://glguy.net/gitea/glguy/toml - what better handling do you have in mind? |
| 2023-06-21 05:49:51 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::2) (Remote host closed the connection) |
| 2023-06-21 05:49:51 +0200 | <glguy> | I have an old one that wasn't complete and I wanted to go back and redo it to fit the 1.0.0 spec tightly |
| 2023-06-21 05:50:16 +0200 | <glguy> | and then ijqq happened to be using toml as a project for learning parsing, I think |
| 2023-06-21 05:53:40 +0200 | <glguy> | My initial goals were to figure out what was needed to actually lex toml with alex and then to get a solid understanding of what toml's actual rules for defining tables are. I don't find it very intuitive and doing the implementation helped there |
| 2023-06-21 05:56:24 +0200 | <davean> | glguy: so its been a while since I last tried to use it - when I did I ran into several issues. I don't have a list handy ATM. |
| 2023-06-21 05:57:55 +0200 | <glguy> | anyway, I don't think my library is anything ground breaking, but it's been a fun distraction |
| 2023-06-21 06:02:03 +0200 | <davean> | I look forward to trying it. |
| 2023-06-21 06:02:32 +0200 | hugo | (znc@2001:6b0:17:f0a0::17) (Ping timeout: 240 seconds) |
| 2023-06-21 06:04:32 +0200 | hdggxin | (~hdggxin@122.175.41.19) |
| 2023-06-21 06:04:52 +0200 | ft | (~ft@p4fc2afc9.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-06-21 06:06:19 +0200 | anthezium | (~ted@97-120-70-39.ptld.qwest.net) (Ping timeout: 260 seconds) |
| 2023-06-21 06:08:09 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-06-21 06:12:52 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2023-06-21 06:13:10 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2023-06-21 06:16:03 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-06-21 06:16:16 +0200 | arrowhead | (~arrowhead@2603-7000-9b3f-6934-a971-d3cb-1596-4118.res6.spectrum.com) |
| 2023-06-21 06:16:30 +0200 | Inst_ | (~Inst@c-76-101-10-131.hsd1.fl.comcast.net) |
| 2023-06-21 06:17:16 +0200 | Inst | (~Inst@2601:6c4:4081:2fc0:9dc5:964c:79f7:7570) (Ping timeout: 260 seconds) |
| 2023-06-21 06:20:30 +0200 | arrowhead | (~arrowhead@2603-7000-9b3f-6934-a971-d3cb-1596-4118.res6.spectrum.com) (Ping timeout: 240 seconds) |
| 2023-06-21 06:20:51 +0200 | <Axman6> | probie: yeah that's what the internet said too and it makes me very sad needing an import for concat |
| 2023-06-21 06:21:24 +0200 | <Axman6> | probie: there's also this... hack: sum(xxs,[]) |
| 2023-06-21 06:22:46 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
| 2023-06-21 06:24:30 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 06:30:04 +0200 | jargon | (~jargon@32.sub-174-205-224.myvzw.com) (Remote host closed the connection) |
| 2023-06-21 06:31:57 +0200 | trev | (~trev@user/trev) |
| 2023-06-21 06:32:55 +0200 | anthezium | (~ted@75.164.14.110) |
| 2023-06-21 06:46:55 +0200 | xerox | (~edi@user/edi) (Server closed connection) |
| 2023-06-21 06:47:03 +0200 | xerox | (~edi@user/edi) |
| 2023-06-21 06:50:56 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2023-06-21 07:00:35 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 07:03:00 +0200 | falafel | (~falafel@2607:fb91:86c:d890:a3d3:8ef4:9c53:4539) (Ping timeout: 240 seconds) |
| 2023-06-21 07:07:39 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-06-21 07:08:16 +0200 | ijqq | (uid603979@id-603979.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-06-21 07:12:32 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Remote host closed the connection) |
| 2023-06-21 07:16:24 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-06-21 07:16:59 +0200 | theodorc | (theodorc@cassarossa.samfundet.no) (Server closed connection) |
| 2023-06-21 07:17:23 +0200 | theodorc | (theodorc@cassarossa.samfundet.no) |
| 2023-06-21 07:18:44 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2023-06-21 07:19:33 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-06-21 07:19:59 +0200 | mmhat | (~mmh@p200300f1c702b0fdee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-06-21 07:20:12 +0200 | chromoblob | (~user@37.113.180.121) (Ping timeout: 240 seconds) |
| 2023-06-21 07:20:16 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-06-21 07:25:08 +0200 | ddellaco1 | (~ddellacos@143.244.47.100) (Ping timeout: 240 seconds) |
| 2023-06-21 07:34:30 +0200 | stallmanator | (~stallmana@user/stallmanator) (Server closed connection) |
| 2023-06-21 07:34:52 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2023-06-21 07:34:56 +0200 | stallmanator | (~stallmana@user/stallmanator) |
| 2023-06-21 07:37:59 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-06-21 07:39:46 +0200 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) (Ping timeout: 240 seconds) |
| 2023-06-21 07:40:55 +0200 | chromoblob | (~user@37.113.180.121) |
| 2023-06-21 07:42:53 +0200 | kimiamania6 | (~6790af62@user/kimiamania) (Quit: Ping timeout (120 seconds)) |
| 2023-06-21 07:42:57 +0200 | mmhat | (~mmh@p200300f1c702b0fdee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8) |
| 2023-06-21 07:43:40 +0200 | jonathan | (~jonathan@c83-252-3-92.bredband.tele2.se) |
| 2023-06-21 07:45:53 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) (Ping timeout: 265 seconds) |
| 2023-06-21 07:46:10 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Remote host closed the connection) |
| 2023-06-21 07:46:40 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2023-06-21 07:46:50 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) |
| 2023-06-21 07:47:06 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 260 seconds) |
| 2023-06-21 07:49:41 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) (Client Quit) |
| 2023-06-21 07:49:55 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) |
| 2023-06-21 07:51:53 +0200 | michalz | (~michalz@185.246.207.217) |
| 2023-06-21 07:56:20 +0200 | acidjnk | (~acidjnk@p200300d6e7072f41dcd5446dd0ee4e5a.dip0.t-ipconnect.de) |
| 2023-06-21 07:59:31 +0200 | gurkenglas | (~user@dynamic-089-204-130-184.89.204.130.pool.telefonica.de) |
| 2023-06-21 08:07:50 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:1e1c:e5dd:2e78:d325) |
| 2023-06-21 08:10:38 +0200 | <sm> | hey all. Why would the max residency reported by +RTS -s be quite a bit (eg 3x) smaller than the max Real Mem usage observed with mac activity monitor ? |
| 2023-06-21 08:13:32 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 240 seconds) |
| 2023-06-21 08:19:30 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 240 seconds) |
| 2023-06-21 08:22:40 +0200 | taupiqueur2 | (~taupiqueu@2a02-8440-2440-b664-9c72-b816-0500-13c5.rev.sfr.net) (Ping timeout: 265 seconds) |
| 2023-06-21 08:23:39 +0200 | <int-e> | sm: residency counts live data on the heap *after* each garbage collection |
| 2023-06-21 08:25:12 +0200 | <int-e> | So it doesn't account for having a from-space, a to-space, and the actual garbage that wasn't copied during (copying) GC. |
| 2023-06-21 08:25:56 +0200 | <int-e> | So I think a factor of 2-3 is actually expected with the copying garbage collector. |
| 2023-06-21 08:26:32 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-06-21 08:27:21 +0200 | shapr | (~user@2600:1700:c640:3100:c563:6739:a435:1e16) (Ping timeout: 260 seconds) |
| 2023-06-21 08:27:54 +0200 | <int-e> | "each garbage collection" - I guess that's only for major collections. |
| 2023-06-21 08:28:48 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-06-21 08:29:42 +0200 | tubogram44711 | (~tubogram@user/tubogram) (Ping timeout: 240 seconds) |
| 2023-06-21 08:36:39 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 08:38:17 +0200 | <sm> | int-e: ah, thanks! |
| 2023-06-21 08:38:56 +0200 | <sm> | it would be nice if RTS could report the actual max memory used.. much more convenient than trying to watch it with top |
| 2023-06-21 08:39:34 +0200 | noctux1 | (hFX4m9Jjsv@user/noctux) (Server closed connection) |
| 2023-06-21 08:39:54 +0200 | noctux1 | (88FTKVRINY@user/noctux) |
| 2023-06-21 08:41:36 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 258 seconds) |
| 2023-06-21 08:42:54 +0200 | yaroot | (~yaroot@p3136152-ipngn5601souka.saitama.ocn.ne.jp) (Remote host closed the connection) |
| 2023-06-21 08:43:41 +0200 | yaroot | (~yaroot@2400:4052:ac0:d900:1cf4:2aff:fe51:c04c) |
| 2023-06-21 08:43:55 +0200 | bsima | (~bsima@2604:a880:400:d0::19f1:7001) (Server closed connection) |
| 2023-06-21 08:44:14 +0200 | bsima | (~bsima@143.198.118.179) |
| 2023-06-21 08:45:29 +0200 | <jade[m]1> | I wonder whether this would better to represent with a state monad that collects the intermediate states... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/51118610c5107520de0520939442e1f4a89c…>) |
| 2023-06-21 08:49:22 +0200 | shailangsa | (~shailangs@host86-186-142-69.range86-186.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2023-06-21 08:50:52 +0200 | <Axman6> | Hmmm, does a type level for loop make much sense? I want to secify some type parameters as a type level list, and then run some code with with each set of those types... |
| 2023-06-21 08:52:46 +0200 | exeo | (~exeo@97-119-96-49.omah.qwest.net) (Remote host closed the connection) |
| 2023-06-21 08:52:56 +0200 | <probie> | a loop as opposed to just a regular map? |
| 2023-06-21 08:52:56 +0200 | tubogram44711 | (~tubogram@user/tubogram) |
| 2023-06-21 08:53:09 +0200 | exeo | (~Ozymandia@97-119-96-49.omah.qwest.net) |
| 2023-06-21 08:53:23 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 08:55:23 +0200 | <jackdk> | Like bringing a typelevel list of `Symbol` down to value level, and then doing something with the result? sure, why not? |
| 2023-06-21 08:57:42 +0200 | tubogram44711 | (~tubogram@user/tubogram) (Ping timeout: 240 seconds) |
| 2023-06-21 08:57:52 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2023-06-21 09:01:15 +0200 | user___ | (~user@162.255.84.96) (Server closed connection) |
| 2023-06-21 09:01:38 +0200 | user___ | (~user@162.255.84.96) |
| 2023-06-21 09:04:09 +0200 | <Axman6> | I can't quite figure out in my head how to do it. Will need to have a play another day. I feel I want something like... forEachOf @(size,showDoThing) @[(1,True),(4,False)] (someThing :: Foo size doSomething => m something) |
| 2023-06-21 09:04:52 +0200 | <Axman6> | uh, showDoThing = doSomething |
| 2023-06-21 09:05:09 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 09:05:30 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 252 seconds) |
| 2023-06-21 09:05:39 +0200 | <Axman6> | My specific usecase is working with Clash, and I'd love to be able to write testbenches where you can run them with a bunch of different type level params |
| 2023-06-21 09:06:21 +0200 | fendor | (~fendor@2a02:8388:1640:be00:7aca:a77a:4a28:631a) |
| 2023-06-21 09:08:46 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-06-21 09:09:43 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 09:10:29 +0200 | exeo | (~Ozymandia@97-119-96-49.omah.qwest.net) (Quit: Leaving) |
| 2023-06-21 09:13:25 +0200 | troydm | (~troydm@user/troydm) (Ping timeout: 240 seconds) |
| 2023-06-21 09:13:52 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2023-06-21 09:16:11 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-06-21 09:20:05 +0200 | ripspin | (~chatzilla@1.145.245.25) |
| 2023-06-21 09:20:44 +0200 | sap | (~sap@169.84-49-96.nextgentel.com) |
| 2023-06-21 09:20:52 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-06-21 09:21:28 +0200 | sap | (~sap@169.84-49-96.nextgentel.com) (Client Quit) |
| 2023-06-21 09:21:40 +0200 | sap | (~sap@169.84-49-96.nextgentel.com) |
| 2023-06-21 09:24:19 +0200 | sap | (~sap@169.84-49-96.nextgentel.com) (Read error: Connection reset by peer) |
| 2023-06-21 09:25:00 +0200 | <jackdk> | Axman6: try a HList of singletons |
| 2023-06-21 09:29:48 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-06-21 09:30:53 +0200 | <Lears> | That or a helper class like `class For (c :: k -> Constraint) (ts :: [k]) where forTypes :: (forall proxy a. c a => proxy a -> r) -> [r]`. |
| 2023-06-21 09:32:33 +0200 | Co0kie | (~Jura@145.224.73.17) |
| 2023-06-21 09:33:33 +0200 | sap | (~sap@169.84-49-96.nextgentel.com) |
| 2023-06-21 09:35:14 +0200 | troydm | (~troydm@user/troydm) |
| 2023-06-21 09:35:32 +0200 | sap | (~sap@169.84-49-96.nextgentel.com) (Read error: Connection reset by peer) |
| 2023-06-21 09:43:27 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-06-21 09:44:01 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 09:44:07 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2023-06-21 09:47:16 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-06-21 09:49:13 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 256 seconds) |
| 2023-06-21 09:50:32 +0200 | mxs | (~mxs@user/mxs) (Ping timeout: 240 seconds) |
| 2023-06-21 09:51:08 +0200 | APic | (apic@apic.name) (Ping timeout: 240 seconds) |
| 2023-06-21 09:51:33 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2023-06-21 09:53:10 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-06-21 09:53:13 +0200 | bgs | (~bgs@212-85-160-171.dynamic.telemach.net) |
| 2023-06-21 09:57:19 +0200 | ggVGc | (~ggVGc@a.lowtech.earth) (Server closed connection) |
| 2023-06-21 09:57:41 +0200 | ggVGc | (~ggVGc@a.lowtech.earth) |
| 2023-06-21 09:59:58 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-06-21 10:01:54 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 10:06:12 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2023-06-21 10:10:19 +0200 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Server closed connection) |
| 2023-06-21 10:10:42 +0200 | perrierjouet | (~perrier-j@modemcable048.127-56-74.mc.videotron.ca) |
| 2023-06-21 10:14:54 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Server closed connection) |
| 2023-06-21 10:15:11 +0200 | Katarushisu | (~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) |
| 2023-06-21 10:17:35 +0200 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2023-06-21 10:18:25 +0200 | cheater | (~Username@user/cheater) (Read error: Connection reset by peer) |
| 2023-06-21 10:20:27 +0200 | cheater | (~Username@user/cheater) |
| 2023-06-21 10:21:44 +0200 | califax | (~califax@user/califx) (Ping timeout: 240 seconds) |
| 2023-06-21 10:23:50 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-06-21 10:28:11 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-06-21 10:35:28 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89b:a33a:757:b886) (Remote host closed the connection) |
| 2023-06-21 10:35:32 +0200 | Co0kie | (~Jura@145.224.73.17) (Ping timeout: 240 seconds) |
| 2023-06-21 10:39:27 +0200 | califax | (~califax@user/califx) |
| 2023-06-21 10:44:45 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-06-21 10:44:59 +0200 | Fangs | (sid141280@id-141280.hampstead.irccloud.com) (Server closed connection) |
| 2023-06-21 10:45:14 +0200 | Fangs | (sid141280@id-141280.hampstead.irccloud.com) |
| 2023-06-21 10:46:07 +0200 | danse-nr3_ | (~francesco@151.46.135.20) |
| 2023-06-21 10:50:54 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 10:53:51 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-06-21 10:59:00 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-06-21 10:59:57 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-06-21 11:02:16 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-06-21 11:04:47 +0200 | oneeyedalien_ | (~oneeyedal@user/oneeyedalien) |
| 2023-06-21 11:05:41 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2023-06-21 11:06:30 +0200 | oneeyedalien | (~oneeyedal@user/oneeyedalien) (Ping timeout: 252 seconds) |
| 2023-06-21 11:07:23 +0200 | Inst[m] | (~instrmatr@2001:470:69fc:105::1:903e) (Remote host closed the connection) |
| 2023-06-21 11:08:06 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2023-06-21 11:09:46 +0200 | phma | (~phma@host-67-44-208-160.hnremote.net) (Read error: Connection reset by peer) |
| 2023-06-21 11:10:11 +0200 | phma | (phma@2001:5b0:211f:2f08:cc02:19f0:c9b8:d000) |
| 2023-06-21 11:12:29 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2023-06-21 11:12:52 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds) |
| 2023-06-21 11:13:01 +0200 | chromoblob | (~user@37.113.180.121) (Ping timeout: 258 seconds) |
| 2023-06-21 11:15:00 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds) |
| 2023-06-21 11:15:00 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2023-06-21 11:17:34 +0200 | ubert | (~Thunderbi@2a02:8109:abc0:6434:8a6c:e7c0:d456:af5) |
| 2023-06-21 11:19:39 +0200 | Boarders___ | (sid425905@id-425905.lymington.irccloud.com) (Server closed connection) |
| 2023-06-21 11:20:00 +0200 | Boarders___ | (sid425905@id-425905.lymington.irccloud.com) |
| 2023-06-21 11:22:10 +0200 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) |
| 2023-06-21 11:24:31 +0200 | cfricke_ | (~cfricke@user/cfricke) |
| 2023-06-21 11:26:25 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-06-21 11:26:25 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 240 seconds) |
| 2023-06-21 11:28:08 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2023-06-21 11:28:35 +0200 | ddellaco1 | (~ddellacos@146.70.168.10) |
| 2023-06-21 11:35:58 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89b:a33a:757:b886) |
| 2023-06-21 11:36:12 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-06-21 11:36:19 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 256 seconds) |
| 2023-06-21 11:38:00 +0200 | yaroot | (~yaroot@2400:4052:ac0:d900:1cf4:2aff:fe51:c04c) (Ping timeout: 240 seconds) |
| 2023-06-21 11:40:26 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:89b:a33a:757:b886) (Ping timeout: 260 seconds) |
| 2023-06-21 11:40:36 +0200 | gurkenglas | (~user@dynamic-089-204-130-184.89.204.130.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2023-06-21 11:41:58 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-06-21 11:42:45 +0200 | yaroot | (~yaroot@p3438127-ipngn9401souka.saitama.ocn.ne.jp) |
| 2023-06-21 11:44:00 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-06-21 11:44:56 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 240 seconds) |
| 2023-06-21 11:47:01 +0200 | nefercheprure | TMA |
| 2023-06-21 11:49:12 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds) |
| 2023-06-21 11:50:52 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) (Ping timeout: 252 seconds) |
| 2023-06-21 11:51:47 +0200 | hyvoid | (~hyenavoid@222-0-178-69.static.gci.net) |
| 2023-06-21 11:52:28 +0200 | gurkenglas | (~user@dynamic-089-204-130-184.89.204.130.pool.telefonica.de) |
| 2023-06-21 11:56:59 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-06-21 12:01:26 +0200 | danse-nr3__ | (~francesco@151.44.193.186) |
| 2023-06-21 12:01:27 +0200 | danse-nr3_ | (~francesco@151.46.135.20) (Read error: Connection reset by peer) |
| 2023-06-21 12:02:45 +0200 | <kuribas> | ugh, cassava is failing because there is no trailing newline in the csv file. |
| 2023-06-21 12:02:59 +0200 | carter | (sid14827@id-14827.helmsley.irccloud.com) (Server closed connection) |
| 2023-06-21 12:03:07 +0200 | <Hecate> | kuribas: that sucks but also CSV is a mine field of oddities :D |
| 2023-06-21 12:03:24 +0200 | <kuribas> | that's why I'd expect a CSV parser to be very lenient. |
| 2023-06-21 12:03:28 +0200 | carter | (sid14827@id-14827.helmsley.irccloud.com) |
| 2023-06-21 12:04:16 +0200 | texasmynsted | (~username@99.96.221.112) (Server closed connection) |
| 2023-06-21 12:04:39 +0200 | texasmynsted | (~username@99.96.221.112) |
| 2023-06-21 12:06:27 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-06-21 12:06:38 +0200 | xff0x_ | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds) |
| 2023-06-21 12:07:24 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Ping timeout: 265 seconds) |
| 2023-06-21 12:07:50 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-06-21 12:11:16 +0200 | ceoarrrrrrrrrrrr | (~ceoarrrrr@c-71-204-38-59.hsd1.ga.comcast.net) |
| 2023-06-21 12:15:59 +0200 | truckasaurus | (sid457088@id-457088.helmsley.irccloud.com) (Server closed connection) |
| 2023-06-21 12:16:08 +0200 | truckasaurus | (sid457088@id-457088.helmsley.irccloud.com) |
| 2023-06-21 12:20:19 +0200 | Guest2244 | (~m-mzmz6l@vmi833741.contaboserver.net) (Server closed connection) |
| 2023-06-21 12:20:36 +0200 | root | (~m-mzmz6l@vmi833741.contaboserver.net) |
| 2023-06-21 12:21:00 +0200 | root | Guest5986 |
| 2023-06-21 12:22:03 +0200 | phma | (phma@2001:5b0:211f:2f08:cc02:19f0:c9b8:d000) (Read error: Connection reset by peer) |
| 2023-06-21 12:22:27 +0200 | phma | (phma@2001:5b0:211f:2f08:cc02:19f0:c9b8:d000) |
| 2023-06-21 12:22:51 +0200 | <Guillaum[m]> | I had success with -fbreak-on-exceptions + :trace to locate exception source in GHCI only for small functions. Trying it on a complexe task (including threads) does not work (i.e. it never breaks on the exception, which are then caught by the local handler). Is this a known limitation (I cannot find anything on the issue tracker), or do I miss something obvious? |
| 2023-06-21 12:24:21 +0200 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-06-21 12:29:07 +0200 | tom__ | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) |
| 2023-06-21 12:32:52 +0200 | tom_ | (~tom@2a00:23c8:970c:4801:c75:579a:9201:4dd9) (Ping timeout: 240 seconds) |
| 2023-06-21 12:37:31 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-06-21 12:38:20 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-06-21 12:42:16 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds) |
| 2023-06-21 12:46:08 +0200 | DigitalKiwi | (~kiwi@2604:a880:400:d0::1ca0:e001) (Quit: quite.) |
| 2023-06-21 12:49:36 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:fdcc:20d2:cb27:c10f) |
| 2023-06-21 12:54:00 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:fdcc:20d2:cb27:c10f) (Ping timeout: 240 seconds) |
| 2023-06-21 12:55:20 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2023-06-21 12:55:37 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2023-06-21 12:57:14 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-06-21 13:00:56 +0200 | ddellaco1 | (~ddellacos@146.70.168.10) (Ping timeout: 260 seconds) |
| 2023-06-21 13:04:32 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Ping timeout: 240 seconds) |
| 2023-06-21 13:07:15 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) (Read error: Connection reset by peer) |
| 2023-06-21 13:07:33 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) |
| 2023-06-21 13:07:36 +0200 | xff0x_ | (~xff0x@ai098135.d.east.v6connect.net) |
| 2023-06-21 13:08:09 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2023-06-21 13:12:58 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-06-21 13:13:58 +0200 | gmg_ | (~user@user/gehmehgeh) |
| 2023-06-21 13:14:56 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2023-06-21 13:15:35 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-06-21 13:17:40 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-06-21 13:18:42 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) (Read error: Connection reset by peer) |
| 2023-06-21 13:21:10 +0200 | Helle | (~helle@user/Helle) (Server closed connection) |
| 2023-06-21 13:21:17 +0200 | Helle | (~helle@user/Helle) |
| 2023-06-21 13:21:31 +0200 | gemmaro | (~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) |
| 2023-06-21 13:22:32 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 252 seconds) |
| 2023-06-21 13:27:29 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) |
| 2023-06-21 13:29:29 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 258 seconds) |
| 2023-06-21 13:29:39 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (Server closed connection) |
| 2023-06-21 13:29:58 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 2023-06-21 13:30:31 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-06-21 13:32:00 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) (Read error: Connection reset by peer) |
| 2023-06-21 13:32:28 +0200 | Vq | (~vq@90-227-195-9-no77.tbcn.telia.com) |
| 2023-06-21 13:33:27 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-06-21 13:37:10 +0200 | SoF | (~skius@user/skius) |
| 2023-06-21 13:37:36 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-06-21 13:37:52 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 240 seconds) |
| 2023-06-21 13:42:07 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) |
| 2023-06-21 13:42:55 +0200 | ncf | (~n@monade.li) (Server closed connection) |
| 2023-06-21 13:43:14 +0200 | ncf | (~n@monade.li) |
| 2023-06-21 13:43:43 +0200 | APic | (apic@185.203.114.119) |
| 2023-06-21 13:46:45 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) (Ping timeout: 246 seconds) |
| 2023-06-21 13:49:05 +0200 | <merijn> | I have no idea how that's implemented |
| 2023-06-21 13:49:40 +0200 | <merijn> | Guillaum[m]: fyi, if you build with profiling and run with the -xc RTS option you will get tracebacks for every thrown (annoyingly also caught ones, but oh well) on stderr |
| 2023-06-21 13:51:15 +0200 | <Guillaum[m]> | merijn: rebuilding in profiling is 20 minutes, when starting the repl and loading all module is 2 minutes here ;) But yes, that's the other option I have. Thank you. |
| 2023-06-21 13:52:14 +0200 | Inst_ | (~Inst@c-76-101-10-131.hsd1.fl.comcast.net) (Ping timeout: 252 seconds) |
| 2023-06-21 13:52:15 +0200 | <merijn> | Guillaum[m]: on the bright side, that's mostly the first time (because it needs to build and install the profiled versions of your dependencies) |
| 2023-06-21 13:52:38 +0200 | <danse-nr3__> | kuribas, there seems to already be an issue about that https://github.com/haskell-hvr/cassava/issues/121, you could chime in to give it more weight |
| 2023-06-21 13:53:09 +0200 | <kuribas> | danse-nr3__: thanks, I will! |
| 2023-06-21 13:53:17 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d523:1039:6a67:e484) |
| 2023-06-21 13:53:22 +0200 | Inst | (~Inst@c-76-101-10-131.hsd1.fl.comcast.net) |
| 2023-06-21 13:53:24 +0200 | APic | (apic@185.203.114.119) (Ping timeout: 246 seconds) |
| 2023-06-21 13:53:28 +0200 | <merijn> | Guillaum[m]: After that initial build it should take meaningfully longer to build profiling than non-profiling (unless your regular rebuilds also take 20 minutes, in which case it's probably time to fix that instead ;)) |
| 2023-06-21 13:53:57 +0200 | <kuribas> | danse-nr3__: ah no, that one is about an extra trailing newline. My issue is that there is no trailing newline in the end of the file. |
| 2023-06-21 13:54:21 +0200 | <merijn> | kuribas: cassava also breaks on CSVs exported by MS Office due to the utf8 BOM |
| 2023-06-21 13:54:30 +0200 | <merijn> | cassava is not very robust, imo |
| 2023-06-21 13:54:33 +0200 | <danse-nr3__> | kuribas, oh, sorry |
| 2023-06-21 13:54:42 +0200 | gemmaro | (~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) (Remote host closed the connection) |
| 2023-06-21 13:55:13 +0200 | <danse-nr3__> | merijn, do you know of any better alternative? |
| 2023-06-21 13:55:54 +0200 | <kuribas> | merijn: indeed |
| 2023-06-21 13:56:32 +0200 | <merijn> | danse-nr3__: Crying :) |
| 2023-06-21 13:56:36 +0200 | <merijn> | + whiskey |
| 2023-06-21 13:56:41 +0200 | <danse-nr3__> | XD |
| 2023-06-21 13:56:41 +0200 | <dminuoso> | I should write |
| 2023-06-21 13:56:49 +0200 | <dminuoso> | A flatparse based csv parser. |
| 2023-06-21 13:57:02 +0200 | <merijn> | danse-nr3__: tbh, my better alternative would be "not using CSV files" :p |
| 2023-06-21 13:57:13 +0200 | <danse-nr3__> | gosh quite a price to pay |
| 2023-06-21 13:57:24 +0200 | <dminuoso> | It's a negative price. |
| 2023-06-21 13:57:30 +0200 | <dminuoso> | You get paid in warm feelings. |
| 2023-06-21 13:57:36 +0200 | <merijn> | I didn't say it was a practical alternative :P |
| 2023-06-21 13:57:40 +0200 | <Guillaum[m]> | merijn: 20 minutes is the build of the 1k+ modules in 200 packages we have. I'm not including the hackage dependencies ;) There may be a bit of possible improvment in the build (such as removing edges), but that's unfortunately slow. "no profiling" build takes 7 minutes. |
| 2023-06-21 13:57:51 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:d523:1039:6a67:e484) (Ping timeout: 258 seconds) |
| 2023-06-21 13:57:59 +0200 | <dminuoso> | danse-nr3__: But seriously, just handroll a parser in whatever parsing library you fancy. |
| 2023-06-21 13:57:59 +0200 | <merijn> | Wait |
| 2023-06-21 13:58:08 +0200 | <merijn> | Why is the profiling build over 2x slower?? |
| 2023-06-21 13:58:08 +0200 | <probie> | One doesn't pick the format of data they're given |
| 2023-06-21 13:58:14 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 13:58:14 +0200 | <merijn> | That smells like a bug |
| 2023-06-21 13:58:15 +0200 | <dminuoso> | CSV is not hard, especially if you dont care about all kinds of CSV varieties. |
| 2023-06-21 13:58:35 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) |
| 2023-06-21 13:58:47 +0200 | <kuribas> | merijn: so ... excell? |
| 2023-06-21 13:59:31 +0200 | <Guillaum[m]> | merijn: I'm interested here, because profiling build had always been slower from my point of view since I'm using haskell, but maybe I'm doing something stupid. Note that it was 30x time slower since recently when I removed `-fexternal-interpreter` and instead moved to "double build" (i.e. static + dynamic) for profiling and template haskell. |
| 2023-06-21 13:59:44 +0200 | <danse-nr3__> | yea dminuoso but if we do not contribute to what already exists it will hardly ever get better ... :P |
| 2023-06-21 13:59:45 +0200 | <merijn> | Guillaum[m]: I mean, 1k modules in 200 packages that somehow always evolve in lockstep sounds like "someone fucked up the architecture design" :) |
| 2023-06-21 13:59:53 +0200 | <dminuoso> | danse-nr3__: cassava is beyond repair. |
| 2023-06-21 13:59:59 +0200 | <danse-nr3__> | XD |
| 2023-06-21 13:59:59 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (Server closed connection) |
| 2023-06-21 14:00:28 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2023-06-21 14:00:32 +0200 | <merijn> | Guillaum[m]: At any rate, I don't think profiling builds should be meaninfully slower than regular ones, so that might be worth asking about in #ghc whether you should make a ghc issue |
| 2023-06-21 14:01:14 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-06-21 14:02:23 +0200 | <dminuoso> | danse-nr3__: No but seriously, cassava isnt really bad. It's just a very simplistic and minimalistic library. |
| 2023-06-21 14:02:55 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 265 seconds) |
| 2023-06-21 14:02:58 +0200 | <dminuoso> | It comes at the price of having almost entirely useless errors. |
| 2023-06-21 14:03:05 +0200 | <kuribas> | dminuoso: no, it's bad. It has some weird error handling behaviour with empty cells. |
| 2023-06-21 14:03:35 +0200 | <dminuoso> | kuribas: Right, because its a very simple and naive attoparsec parser. |
| 2023-06-21 14:03:41 +0200 | <Guillaum[m]> | merijn: that's a 10+ years old codebase which survived a change from make + cabal to stack to bazel to nix, so maybe some stuff are indeed poorly architectured. However, except from trying to change the way packages are split in order to reduce the amount of rebuild after a change in some "hot" files, I have no idea about what a good architecture can be. Do you have a reference for that? |
| 2023-06-21 14:03:41 +0200 | <Guillaum[m]> | I've already reported the performances problem with -fexternal-interpreter years ago, but definitiely, I could maybe open a ticket and do some more robust benchmarks. |
| 2023-06-21 14:03:50 +0200 | mxs | (~mxs@user/mxs) |
| 2023-06-21 14:03:51 +0200 | <kuribas> | dminuoso: and minimalistic for me would mean "just load CSV" into a nested list strings. |
| 2023-06-21 14:04:48 +0200 | <danse-nr3__> | kuribas, that would not provide the type safety one expects? |
| 2023-06-21 14:04:52 +0200 | <dminuoso> | kuribas: I think part of the problem is something as mundane as "here turn this string an int/float/whatever" is somewhat annoying in Haskell. |
| 2023-06-21 14:05:09 +0200 | <dminuoso> | So a list of strings wouldnt be comfortable to use |
| 2023-06-21 14:05:26 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2023-06-21 14:06:03 +0200 | <kuribas> | dminuoso: not nearly as annoying as the ad-hoc conversion in python or clojure. |
| 2023-06-21 14:06:30 +0200 | <kuribas> | But yeah, I'd want a parsing step after getting the strings. |
| 2023-06-21 14:06:33 +0200 | <dminuoso> | Dunno, being able to say `int("1")` is quite comfortable. |
| 2023-06-21 14:06:58 +0200 | <dminuoso> | It's the reality of purity that an equivalent isnt as much fun. |
| 2023-06-21 14:07:06 +0200 | <dminuoso> | The correct equivalent would be readIO |
| 2023-06-21 14:07:20 +0200 | <dminuoso> | i.e. `readIO :: Read a => String -> IO a` |
| 2023-06-21 14:07:23 +0200 | <kuribas> | dminuoso: what about int(3.2)? |
| 2023-06-21 14:07:29 +0200 | <merijn> | Guillaum[m]: I realise that with giant legacy code getting things "optimal" can be hard (or not feasible to make time for), but the main thing is minimising the dependencies. In principle packages should only rebuild if one of their dependency packages changes, which should only happen if they recompile due to code changes |
| 2023-06-21 14:07:53 +0200 | <dminuoso> | kuribas: If it useful to 90% of users, its useful to all of them. |
| 2023-06-21 14:08:03 +0200 | <danse-nr3__> | kuribas, maybe you can define your type as being made of strings and parse them afterwards |
| 2023-06-21 14:08:04 +0200 | <kuribas> | oh, and: int("3.2") => ValueError: invalid literal for int() with base 10: '3.2' |
| 2023-06-21 14:08:07 +0200 | <merijn> | Guillaum[m]: One thing I can imagine is that, if you have quite some hackage dependencies, then new hackage releases can cause new build plans causing your core libraries to recompile and cascading through the entire thing |
| 2023-06-21 14:08:22 +0200 | <dminuoso> | kuribas: They are reasonable behaviors. |
| 2023-06-21 14:08:30 +0200 | <kuribas> | dminuoso: it's incosistent. |
| 2023-06-21 14:08:45 +0200 | <dminuoso> | If the goal is to do just "one singular type of conversion", Im not so sure. |
| 2023-06-21 14:08:50 +0200 | Xe | (~cadey@tailscale/xe) (Server closed connection) |
| 2023-06-21 14:09:01 +0200 | <merijn> | Guillaum[m]: if that's the case, you could try generating some freeze files for hackage dependencies so churn on hackage doesn't continually invalidate your builds |
| 2023-06-21 14:09:03 +0200 | <kuribas> | int(float("3.2")) => 3 |
| 2023-06-21 14:09:07 +0200 | <dminuoso> | I mean I would be pissed if `int("3.2")` produced 3. |
| 2023-06-21 14:09:13 +0200 | <dminuoso> | That'd be PHP level of insanity. |
| 2023-06-21 14:09:15 +0200 | Xe | (~cadey@tailscale/xe) |
| 2023-06-21 14:09:33 +0200 | <kuribas> | but int(3.2) can produce 3 ? |
| 2023-06-21 14:09:39 +0200 | <merijn> | Guillaum[m]: if that's not the issue, then the churn is from within your own packages and then the question would be can you figure out/eliminate why those are rebuilding |
| 2023-06-21 14:09:42 +0200 | <dminuoso> | Sure because type(3.2) == <type 'float'> |
| 2023-06-21 14:09:49 +0200 | <danse-nr3__> | oh kuribas there is also https://hackage.haskell.org/package/cassava-0.5.3.0/docs/Data-Csv.html#g:6 |
| 2023-06-21 14:10:01 +0200 | <dminuoso> | Of course it begs the question of what int(<float>) even does |
| 2023-06-21 14:10:05 +0200 | <merijn> | Guillaum[m]: because in principle cabal is pretty decent at making no-op builds fast |
| 2023-06-21 14:10:19 +0200 | <kuribas> | dminuoso: in other words, if you use `int`, it will silently truncate floats. |
| 2023-06-21 14:10:19 +0200 | <Guillaum[m]> | merijn: our hackage dependencies are strictly pinned with nix, so usually that's not the problem. But actually, you are right, some packages deep in the dependency tree could be split between a package for type and a package for some operations in order to avoid recompiling too much. |
| 2023-06-21 14:10:30 +0200 | <kuribas> | dminuoso: in csv, or other formats. |
| 2023-06-21 14:10:56 +0200 | <dminuoso> | kuribas: Under the assumption that you are being handed a list of strings, int() wouldnt do magic truncation. |
| 2023-06-21 14:11:17 +0200 | <merijn> | Guillaum[m]: yeah if you have a types module that everything depends on (and is relatively stable) and functionality that changes a lot, minimising the packages/modules that import/touch the functionality can save you a lot of time |
| 2023-06-21 14:11:17 +0200 | <kuribas> | dminuoso: that assumption doesn't hold in python. |
| 2023-06-21 14:11:18 +0200 | <dminuoso> | It would just fail if the csv contained a fractional number |
| 2023-06-21 14:11:44 +0200 | gmg_ | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2023-06-21 14:11:55 +0200 | <kuribas> | oh well, for csv it does: "Each row read from the csv file is returned as a list of strings. " |
| 2023-06-21 14:12:02 +0200 | <Guillaum[m]> | merijn: thank you for the discussion, by the way a cleaning of the dependency tree is something I've scheduled for our next "consolidation week" (one week where we are not working on feature, but on "general quality" of the codebase). |
| 2023-06-21 14:13:08 +0200 | <kuribas> | dminuoso: IMO it would be more consistent if int is strict, and you use round or floor for truncating. |
| 2023-06-21 14:13:32 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-06-21 14:13:51 +0200 | <dminuoso> | I dont like the name `round` honestly, because it seems to suggest there is one singular authoritative method of rounding |
| 2023-06-21 14:13:54 +0200 | <dminuoso> | But sure. |
| 2023-06-21 14:15:02 +0200 | <dminuoso> | Unless we had `round :: (RealFrac a, Integral b) => RoundingStrategy -> a -> b` |
| 2023-06-21 14:15:30 +0200 | gmg_ | (~user@user/gehmehgeh) |
| 2023-06-21 14:16:13 +0200 | <dminuoso> | Ill just make the blind assumption that `int(<float>)` in Python will just floor. *shrugs* |
| 2023-06-21 14:16:21 +0200 | <kuribas> | in p ython: "if two multiples are equally close, rounding is done toward the even choice" |
| 2023-06-21 14:16:41 +0200 | <kuribas> | I think this is the most common? At least python documented it :) |
| 2023-06-21 14:16:51 +0200 | <dminuoso> | Most common really depends on who you ask. |
| 2023-06-21 14:17:05 +0200 | <dminuoso> | In finance the bankers method is most commonly used. |
| 2023-06-21 14:17:17 +0200 | <dminuoso> | That doesnt make it useful as an implicit default though. |
| 2023-06-21 14:18:18 +0200 | <dminuoso> | Also its the default behavior in IEEE 754 |
| 2023-06-21 14:18:20 +0200 | <merijn> | Guillaum[m]: I managed to cut down my compile times by about half, simply from flatting/reducing dependencies on central core modules in the past |
| 2023-06-21 14:18:56 +0200 | <dminuoso> | Perhaps thats actually another argument why int(<float>) isnt too bad, if it follows IEEE 754. |
| 2023-06-21 14:21:55 +0200 | AndreasK | (sid320732@id-320732.uxbridge.irccloud.com) (Server closed connection) |
| 2023-06-21 14:22:07 +0200 | AndreasK | (sid320732@id-320732.uxbridge.irccloud.com) |
| 2023-06-21 14:24:21 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 260 seconds) |
| 2023-06-21 14:27:59 +0200 | <Guillaum[m]> | merijn: I do have a module which takes, alone, 3 minutes to compile (lot and lot of deriving instances) and it depends on everything. But actually it only depends on types which are rarelly changing, so this is one of the first step. |
| 2023-06-21 14:28:12 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-06-21 14:28:33 +0200 | <merijn> | Guillaum[m]: Yeah, that sounds like an easy win |
| 2023-06-21 14:28:44 +0200 | APic | (apic@apic.name) |
| 2023-06-21 14:28:45 +0200 | danse-nr3__ | (~francesco@151.44.193.186) (Ping timeout: 240 seconds) |
| 2023-06-21 14:30:38 +0200 | danse-nr3__ | (~francesco@151.44.193.186) |
| 2023-06-21 14:30:59 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 14:33:26 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-06-21 14:35:32 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2023-06-21 14:36:22 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-06-21 14:42:50 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-06-21 14:43:15 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-06-21 14:48:00 +0200 | danse-nr3__ | (~francesco@151.44.193.186) (Ping timeout: 246 seconds) |
| 2023-06-21 14:49:16 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-06-21 14:50:18 +0200 | gensyst | (~gensyst@user/gensyst) |
| 2023-06-21 14:51:26 +0200 | <gensyst> | How could my tasty test be failing suddenly at one point? It just silently fails and aborts and reports FAIL. putStrLns reveal the point at which it aborts and FAILs. and onException doesn't catch any exception at all! |
| 2023-06-21 14:51:33 +0200 | <gensyst> | what could be going on? |
| 2023-06-21 14:52:41 +0200 | <gensyst> | the funny part is, if I run with --quickcheck-tests=1 over and over again, each 1 test PASSes fine. |
| 2023-06-21 14:52:55 +0200 | <gensyst> | but when I run with --quickcheck-tests=2 then the second test always FAILs (as I described) |
| 2023-06-21 14:53:20 +0200 | <gensyst> | I can't think of anything that would cause the 2nd test to be dependent on the 1st (and even if they did, i can't think of anything that would make onException not trigger at all) |
| 2023-06-21 14:53:45 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) (Remote host closed the connection) |
| 2023-06-21 14:56:20 +0200 | danse-nr3__ | (~francesco@151.44.193.186) |
| 2023-06-21 14:59:01 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-06-21 14:59:34 +0200 | <gensyst> | I can't think of anything that would cause the 2nd test to be dependent on the 1st (and even if they did, i can't think of anything that would make onException not trigger at all) |
| 2023-06-21 14:59:40 +0200 | cafkafk | (~cafkafk@fsf/member/cafkafk) |
| 2023-06-21 14:59:41 +0200 | <gensyst> | my bad, sorry for repeat |
| 2023-06-21 15:00:01 +0200 | <gensyst> | (and never mind, think i solved it already...) |
| 2023-06-21 15:00:30 +0200 | <ryantrinkle> | monochrom, c_wraith: this is my code: |
| 2023-06-21 15:00:30 +0200 | <ryantrinkle> | something :: (forall x. Typeable x => Proxy x -> k) -> k |
| 2023-06-21 15:00:30 +0200 | <ryantrinkle> | something f = f Proxy |
| 2023-06-21 15:00:46 +0200 | <ryantrinkle> | No instance for (Typeable x0) arising from a use of ‘f’ |
| 2023-06-21 15:01:05 +0200 | <ryantrinkle> | because there isn't actually any concrete type that's getting instantiated there |
| 2023-06-21 15:01:37 +0200 | <ryantrinkle> | so what i was hoping to do was to effectively wish a fresh Typeable instance into existence at runtime |
| 2023-06-21 15:03:01 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 15:06:54 +0200 | oo_miguel | (~Thunderbi@78.11.179.96) |
| 2023-06-21 15:08:00 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2023-06-21 15:08:42 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-06-21 15:09:54 +0200 | <gensyst> | ryantrinkle, is obsidian still all-in on haskell? |
| 2023-06-21 15:10:11 +0200 | <gensyst> | (and nix/nixos/postgres etc.) |
| 2023-06-21 15:10:32 +0200 | <gensyst> | (and of course reflex/obelisk) |
| 2023-06-21 15:11:24 +0200 | <dminuoso> | ryantrinkle: I think you must bury the dictionary in a GADT. |
| 2023-06-21 15:11:36 +0200 | <dminuoso> | Like `constraints` does |
| 2023-06-21 15:11:57 +0200 | <Lears> | ryantrinkle: Is `something \p -> ...` just a trick to introduce a fresh type `x` with `Typeable`? If so, the implementation can just instantiate `x` as `()`, or anything else; it actually doesn't matter. |
| 2023-06-21 15:12:13 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-06-21 15:12:23 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-06-21 15:12:44 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-06-21 15:13:39 +0200 | edm | (sid147314@id-147314.hampstead.irccloud.com) (Server closed connection) |
| 2023-06-21 15:13:55 +0200 | snek | (sid280155@id-280155.lymington.irccloud.com) (Server closed connection) |
| 2023-06-21 15:14:10 +0200 | <Lears> | Oh... maybe precisely because it's Typeable, it does matter. Hmm, ignore me for now. |
| 2023-06-21 15:14:29 +0200 | edm | (sid147314@2a03:5180:f:4::2:3f72) |
| 2023-06-21 15:14:31 +0200 | snek | (sid280155@2a03:5180:f:2::4:465b) |
| 2023-06-21 15:16:21 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-06-21 15:18:22 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-06-21 15:20:20 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 15:25:15 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 256 seconds) |
| 2023-06-21 15:27:18 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-06-21 15:31:32 +0200 | acidjnk | (~acidjnk@p200300d6e7072f41dcd5446dd0ee4e5a.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-06-21 15:31:52 +0200 | mustafa__ | (sid502723@id-502723.hampstead.irccloud.com) () |
| 2023-06-21 15:32:31 +0200 | mustafa_ | (sid502723@rockylinux/releng/mustafa) |
| 2023-06-21 15:34:19 +0200 | mustafa_ | mustafa |
| 2023-06-21 15:35:22 +0200 | michals | (~user@cfeld-pcx40162.desy.de) |
| 2023-06-21 15:35:30 +0200 | kmein | (~weechat@user/kmein) (Server closed connection) |
| 2023-06-21 15:36:16 +0200 | kmein | (~weechat@user/kmein) |
| 2023-06-21 15:37:24 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 15:41:44 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-06-21 15:41:44 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-06-21 15:41:44 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-21 15:42:31 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 260 seconds) |
| 2023-06-21 15:46:47 +0200 | cfricke_ | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2023-06-21 15:49:45 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2023-06-21 15:52:45 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2023-06-21 15:53:36 +0200 | danse-nr3__ | (~francesco@151.44.193.186) (Remote host closed the connection) |
| 2023-06-21 15:54:00 +0200 | danse-nr3__ | (~francesco@151.44.193.186) |
| 2023-06-21 15:54:33 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 15:56:32 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds) |
| 2023-06-21 15:57:26 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-06-21 15:57:50 +0200 | Inst_ | (~Inst@2601:6c4:4081:2fc0:61ec:e42a:c603:c093) |
| 2023-06-21 15:58:53 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-06-21 15:58:53 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-06-21 15:58:53 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-06-21 15:58:59 +0200 | Inst | (~Inst@c-76-101-10-131.hsd1.fl.comcast.net) (Ping timeout: 258 seconds) |
| 2023-06-21 15:59:00 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2023-06-21 16:01:30 +0200 | danse-nr3_ | (~francesco@151.46.172.229) |
| 2023-06-21 16:01:56 +0200 | danse-nr3__ | (~francesco@151.44.193.186) (Read error: Connection reset by peer) |
| 2023-06-21 16:02:43 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:38f8:4900:37c0:4176) |
| 2023-06-21 16:07:11 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:38f8:4900:37c0:4176) (Ping timeout: 256 seconds) |
| 2023-06-21 16:07:18 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2023-06-21 16:07:41 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2023-06-21 16:08:09 +0200 | <Lears> | ryantrinkle: If you can suffer the monadic interface: https://gist.github.com/LSLeary/f1268e8b4fca2c7747baf4536127d38c |
| 2023-06-21 16:08:38 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2023-06-21 16:11:24 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) |
| 2023-06-21 16:14:58 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:1e1c:e5dd:2e78:d325) (Quit: WeeChat 2.8) |
| 2023-06-21 16:15:32 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) (Ping timeout: 240 seconds) |
| 2023-06-21 16:21:37 +0200 | <c_wraith> | Lears: that seems like the type of withFresh could tell the caller more. In particular, the caller should know that x will always be a Z with some number of S constructors wrapping it, but the type isn't communicating that. |
| 2023-06-21 16:23:31 +0200 | <Lears> | The `Z` and `S`s are implementation details, only exposed by the Typeable dictionary because it can't be helped. I don't see why they should show up in the interface. |
| 2023-06-21 16:24:48 +0200 | <c_wraith> | I suppose that makes sense if the only thing you want the Typeable dictionary to communicate is that it's not the same as any other invocation within the scope of some runFresh |
| 2023-06-21 16:24:52 +0200 | Phytolizer | (~Phytolize@139.138.137.75) |
| 2023-06-21 16:24:55 +0200 | Phytolizer | (~Phytolize@139.138.137.75) () |
| 2023-06-21 16:25:19 +0200 | <Lears> | Yeah, that's the intention. |
| 2023-06-21 16:25:21 +0200 | <c_wraith> | But that's not what people usually expect when they see Typeable. They expect that they're supposed to branch on the type. |
| 2023-06-21 16:25:32 +0200 | <c_wraith> | So the use of Typeable is sort of misleading |
| 2023-06-21 16:26:16 +0200 | <Lears> | Can't you still branch on this? I haven't thought too much about it... |
| 2023-06-21 16:27:41 +0200 | <c_wraith> | you can only branch on equality with other Typeable dictionaries if you don't know about S and Z |
| 2023-06-21 16:28:46 +0200 | acidjnk | (~acidjnk@p200300d6e7072f41682e2ef333aef3bc.dip0.t-ipconnect.de) |
| 2023-06-21 16:31:56 +0200 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-06-21 16:40:30 +0200 | Arsen | (arsen@gentoo/developer/managarm.dev.Arsen) (Server closed connection) |
| 2023-06-21 16:40:52 +0200 | Arsen | (arsen@gentoo/developer/managarm.dev.Arsen) |
| 2023-06-21 16:40:54 +0200 | natto | (~natto@140.238.225.67) (Server closed connection) |
| 2023-06-21 16:43:00 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds) |
| 2023-06-21 16:43:15 +0200 | natto | (~natto@140.238.225.67) |
| 2023-06-21 16:45:03 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-06-21 16:45:57 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) |
| 2023-06-21 16:50:12 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) (Ping timeout: 240 seconds) |
| 2023-06-21 16:50:43 +0200 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-06-21 16:58:30 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-06-21 17:12:07 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 17:12:48 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-06-21 17:15:00 +0200 | ai5lk | (~ai5lk@209-188-121-236.taosnet.com) |
| 2023-06-21 17:15:31 +0200 | ai5lk | shef |
| 2023-06-21 17:16:35 +0200 | exeo__ | (~Ozymandia@97-119-96-49.omah.qwest.net) |
| 2023-06-21 17:18:20 +0200 | exeo__ | (~Ozymandia@97-119-96-49.omah.qwest.net) (Client Quit) |
| 2023-06-21 17:19:11 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-06-21 17:20:46 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-06-21 17:21:46 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) |
| 2023-06-21 17:22:06 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-06-21 17:23:04 +0200 | kupi_ | (uid212005@2a03:5180:f:4::3:3c25) |
| 2023-06-21 17:23:48 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 252 seconds) |
| 2023-06-21 17:24:54 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-06-21 17:25:52 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) (Ping timeout: 240 seconds) |
| 2023-06-21 17:26:41 +0200 | michals | (~user@cfeld-pcx40162.desy.de) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2023-06-21 17:31:22 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 258 seconds) |
| 2023-06-21 17:34:21 +0200 | barcisz | (~barcisz@public-gprs530047.centertel.pl) |
| 2023-06-21 17:37:00 +0200 | ByronJohnson | (~bairyn@50-250-232-19-static.hfc.comcastbusiness.net) (Ping timeout: 252 seconds) |
| 2023-06-21 17:38:24 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-06-21 17:39:00 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-06-21 17:39:18 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 17:40:17 +0200 | EvanR | (~EvanR@user/evanr) (Read error: Connection reset by peer) |
| 2023-06-21 17:40:42 +0200 | EvanR | (~EvanR@user/evanr) |
| 2023-06-21 17:42:06 +0200 | gurkenglas | (~user@dynamic-089-204-130-184.89.204.130.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-06-21 17:42:50 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds) |
| 2023-06-21 17:43:15 +0200 | <carbolymer> | why `print z` hangs here? https://bpa.st/RIC7E |
| 2023-06-21 17:43:51 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 260 seconds) |
| 2023-06-21 17:45:48 +0200 | <carbolymer> | is it trying to compute whole left part of the tree and then do the z? |
| 2023-06-21 17:48:22 +0200 | barcisz | (~barcisz@public-gprs530047.centertel.pl) (Quit: Connection closed) |
| 2023-06-21 17:49:39 +0200 | zups | (~meow@2a01:4f9:c010:6036::1) (Server closed connection) |
| 2023-06-21 17:49:52 +0200 | <EvanR> | right, what should it print? |
| 2023-06-21 17:50:25 +0200 | zups | (~meow@2a01:4f9:c010:6036::1) |
| 2023-06-21 17:50:26 +0200 | <ryantrinkle> | gensyst: yep pretty much |
| 2023-06-21 17:50:51 +0200 | <ryantrinkle> | we use Haskell, Nix, and Postgres for pretty much everything |
| 2023-06-21 17:50:59 +0200 | <ryantrinkle> | we do write embedded software in Rust now |
| 2023-06-21 17:52:14 +0200 | <ryantrinkle> | Lears: oh yeah that is an interesting approach |
| 2023-06-21 17:52:24 +0200 | <ryantrinkle> | I could probably keep an IORef Nat somewhere and then lift that |
| 2023-06-21 17:52:25 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-06-21 17:52:29 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2023-06-21 17:53:16 +0200 | <ryantrinkle> | gensyst: i'm also finally hitting the talk circuit again lol https://munihac.de/2023.html#speakers |
| 2023-06-21 17:55:44 +0200 | mauke | (~mauke@user/mauke) |
| 2023-06-21 17:56:55 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) |
| 2023-06-21 17:59:36 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-06-21 18:01:39 +0200 | taupiqueur2 | (~taupiqueu@2a02-842a-8180-4601-2db0-0a0e-5cae-f87b.rev.sfr.net) (Ping timeout: 256 seconds) |
| 2023-06-21 18:04:06 +0200 | zaidhaan | (~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9) |
| 2023-06-21 18:04:32 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) (Server closed connection) |
| 2023-06-21 18:04:52 +0200 | erisco | (~erisco@d24-141-66-165.home.cgocable.net) |
| 2023-06-21 18:07:44 +0200 | ddellacosta | (~ddellacos@146.70.166.166) |
| 2023-06-21 18:07:48 +0200 | falafel | (~falafel@2607:fb91:86c:d890:f891:31c0:6626:dee4) |
| 2023-06-21 18:09:50 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 18:13:32 +0200 | <gensyst> | ryantrinkle, great to hear :) |
| 2023-06-21 18:13:56 +0200 | mmhat | (~mmh@2003:f1:c702:b0fd:ee08:6bff:fe09:5315) |
| 2023-06-21 18:14:32 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2023-06-21 18:15:15 +0200 | codaraxis | (~codaraxis@user/codaraxis) |
| 2023-06-21 18:16:26 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-06-21 18:18:51 +0200 | ubert | (~Thunderbi@2a02:8109:abc0:6434:8a6c:e7c0:d456:af5) (Remote host closed the connection) |
| 2023-06-21 18:21:19 +0200 | danse-nr3_ | (~francesco@151.46.172.229) (Remote host closed the connection) |
| 2023-06-21 18:22:03 +0200 | danse-nr3_ | (~francesco@151.46.172.229) |
| 2023-06-21 18:22:15 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-06-21 18:27:15 +0200 | elkcl | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Read error: Connection reset by peer) |
| 2023-06-21 18:31:51 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) |
| 2023-06-21 18:35:52 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) (Ping timeout: 240 seconds) |
| 2023-06-21 18:37:01 +0200 | mmhat | (~mmh@2003:f1:c702:b0fd:ee08:6bff:fe09:5315) (Quit: WeeChat 3.8) |
| 2023-06-21 18:37:58 +0200 | elkcl | (~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) |
| 2023-06-21 18:38:36 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-21 18:39:28 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:38f8:4900:37c0:4176) |
| 2023-06-21 18:42:30 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds) |
| 2023-06-21 18:43:01 +0200 | zaidhaan | (~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9) (Read error: Connection reset by peer) |
| 2023-06-21 18:43:36 +0200 | zaidhaan | (~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9) |
| 2023-06-21 18:47:31 +0200 | Guest87 | (~Guest87@mob-31-158-213-218.net.vodafone.it) |
| 2023-06-21 18:47:50 +0200 | Guest87 | (~Guest87@mob-31-158-213-218.net.vodafone.it) (Client Quit) |
| 2023-06-21 18:55:19 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 258 seconds) |
| 2023-06-21 18:56:31 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 18:57:10 +0200 | hisa38 | (~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) |
| 2023-06-21 18:57:23 +0200 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) (Quit: Leaving.) |
| 2023-06-21 18:58:21 +0200 | acarrico | (~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) |
| 2023-06-21 19:02:40 +0200 | user_____ | (~user@x5271795e.dyn.telefonica.de) |
| 2023-06-21 19:02:44 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 19:03:30 +0200 | Cale | (~cale@cpe80d04ade0a03-cm80d04ade0a01.cpe.net.cable.rogers.com) (Server closed connection) |
| 2023-06-21 19:03:53 +0200 | Cale | (~cale@cpe80d04ade0a03-cm80d04ade0a01.cpe.net.cable.rogers.com) |
| 2023-06-21 19:06:52 +0200 | danse-nr3_ | (~francesco@151.46.172.229) (Ping timeout: 240 seconds) |
| 2023-06-21 19:09:25 +0200 | ByronJohnson | (~bairyn@50.250.232.19) |
| 2023-06-21 19:12:01 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Remote host closed the connection) |
| 2023-06-21 19:12:23 +0200 | rf | (~rf@2605:59c8:179c:f610:29c8:b31f:9422:dd37) |
| 2023-06-21 19:13:30 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 19:13:44 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2023-06-21 19:14:09 +0200 | danse-nr3_ | (~francesco@151.46.172.229) |
| 2023-06-21 19:16:36 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-21 19:18:54 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-06-21 19:19:34 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Client Quit) |
| 2023-06-21 19:22:25 +0200 | shef | (~ai5lk@209-188-121-236.taosnet.com) (Quit: WeeChat 3.8) |
| 2023-06-21 19:22:44 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 240 seconds) |
| 2023-06-21 19:27:16 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-06-21 19:27:41 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 19:32:12 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 19:32:32 +0200 | danse-nr3_ | (~francesco@151.46.172.229) (Ping timeout: 240 seconds) |
| 2023-06-21 19:34:37 +0200 | EvanR_ | (~EvanR@user/evanr) |
| 2023-06-21 19:34:48 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 258 seconds) |
| 2023-06-21 19:35:27 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 19:35:49 +0200 | EvanR | (~EvanR@user/evanr) (Read error: Connection reset by peer) |
| 2023-06-21 19:36:43 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 258 seconds) |
| 2023-06-21 19:36:44 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2023-06-21 19:37:13 +0200 | EvanR_ | EvanR |
| 2023-06-21 19:37:44 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-06-21 19:41:39 +0200 | pat67 | (~pat67@89.187.175.5) |
| 2023-06-21 19:42:05 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 258 seconds) |
| 2023-06-21 19:43:07 +0200 | gmg_ | gmg |
| 2023-06-21 19:43:12 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 19:44:02 +0200 | pat_ | (~pat67@pool-100-36-172-241.washdc.fios.verizon.net) |
| 2023-06-21 19:44:31 +0200 | pat__ | (~pat67@pool-100-36-172-241.washdc.fios.verizon.net) |
| 2023-06-21 19:44:37 +0200 | ijqq | (uid603979@2a03:5180:f:1::9:374b) |
| 2023-06-21 19:45:13 +0200 | chromoblob | (~user@37.113.180.121) |
| 2023-06-21 19:45:57 +0200 | <jade[m]1> | I'm trying to find a paper but I can't remember what it's called |
| 2023-06-21 19:46:17 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) |
| 2023-06-21 19:46:20 +0200 | <jade[m]1> | I think it was constructor ???? and talked about kinds of typeclass parameters |
| 2023-06-21 19:47:52 +0200 | pat67 | (~pat67@89.187.175.5) (Ping timeout: 240 seconds) |
| 2023-06-21 19:48:16 +0200 | pat_ | (~pat67@pool-100-36-172-241.washdc.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2023-06-21 19:48:39 +0200 | <ijqq> | http://sprunge.us/ZEh9Dy is there a better way of writing this function? |
| 2023-06-21 19:48:47 +0200 | taupiqueur3 | (~taupiqueu@2a02-842a-8180-4601-e0bc-b2a7-45f7-a4fd.rev.sfr.net) |
| 2023-06-21 19:49:08 +0200 | <ijqq> | i feel like it fits a pattern |
| 2023-06-21 19:49:41 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 246 seconds) |
| 2023-06-21 19:49:43 +0200 | <Nosrep> | that's just replicateM isnt it |
| 2023-06-21 19:49:51 +0200 | chromoblob | (~user@37.113.180.121) (Ping timeout: 260 seconds) |
| 2023-06-21 19:49:56 +0200 | <ncf> | yes https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/Control-Applicative-Combinators.… |
| 2023-06-21 19:50:12 +0200 | taupiqueur2 | (~taupiqueu@2a02:842a:8180:4601:2db0:a0e:5cae:f87b) (Ping timeout: 240 seconds) |
| 2023-06-21 19:51:15 +0200 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (Server closed connection) |
| 2023-06-21 19:51:27 +0200 | aweinstock | (~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) |
| 2023-06-21 19:51:55 +0200 | <ijqq> | oh cool, thank you |
| 2023-06-21 19:52:36 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 19:53:12 +0200 | <EvanR> | @src replicateM |
| 2023-06-21 19:53:12 +0200 | <lambdabot> | replicateM n x = sequence (replicate n x) |
| 2023-06-21 19:53:34 +0200 | <ijqq> | also what is the naming scheme for the letters? |
| 2023-06-21 19:53:52 +0200 | <jade[m]1> | you mean the M |
| 2023-06-21 19:54:08 +0200 | <jade[m]1> | that's just because it is inside the monad |
| 2023-06-21 19:54:11 +0200 | <ijqq> | like i see there is msum and asum and I assume a is for applicative and m for monad. but there what is the m meaning because it works for applicative? |
| 2023-06-21 19:54:26 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-21 19:54:34 +0200 | <EvanR> | it requires Monad powers in this case |
| 2023-06-21 19:54:56 +0200 | <jade[m]1> | I think it's back from when there was no applicative typeclass |
| 2023-06-21 19:55:06 +0200 | taupiqueur3 | (~taupiqueu@2a02-842a-8180-4601-e0bc-b2a7-45f7-a4fd.rev.sfr.net) (Ping timeout: 260 seconds) |
| 2023-06-21 19:55:18 +0200 | <jade[m]1> | and monads were defined by their own without the hierarchy |
| 2023-06-21 19:55:18 +0200 | <EvanR> | :t replicateM |
| 2023-06-21 19:55:19 +0200 | <lambdabot> | Applicative m => Int -> m a -> m [a] |
| 2023-06-21 19:55:22 +0200 | <EvanR> | I'm wrong! |
| 2023-06-21 19:55:42 +0200 | <Nosrep> | i just assumed it's some leftover quirk from long time ago |
| 2023-06-21 19:55:55 +0200 | <ijqq> | oh interesting. so there used to be monad and functor but no applicative? |
| 2023-06-21 19:56:03 +0200 | taupiqueur3 | (~taupiqueu@2a02:842a:8180:4601:7129:fa0f:75f4:74d9) |
| 2023-06-21 19:56:08 +0200 | <EvanR> | and before that there was no monad |
| 2023-06-21 19:56:18 +0200 | <EvanR> | you had lazy list I/O |
| 2023-06-21 19:56:23 +0200 | <jade[m]1> | yes, the discovery of applicative as an "in between" and the hierarchy was not always there |
| 2023-06-21 19:56:33 +0200 | <ijqq> | oh cool |
| 2023-06-21 19:56:49 +0200 | <ijqq> | btw how long ago was this? How long have guys been using haskell? |
| 2023-06-21 19:56:55 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Remote host closed the connection) |
| 2023-06-21 19:57:03 +0200 | <ijqq> | must be cool using it and then seeing lots of new features coming out in real time |
| 2023-06-21 19:57:15 +0200 | <jade[m]1> | I just know this from hearsay, I've been seriously using haskell for like uhh a year? |
| 2023-06-21 19:57:26 +0200 | <jade[m]1> | serious being not so serious actually |
| 2023-06-21 19:57:29 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2023-06-21 19:57:30 +0200 | rf | (~rf@2605:59c8:179c:f610:29c8:b31f:9422:dd37) (Ping timeout: 240 seconds) |
| 2023-06-21 19:57:33 +0200 | <jade[m]1> | just like, more often |
| 2023-06-21 19:57:51 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-06-21 19:58:29 +0200 | <Nosrep> | maybe it was a pre https://wiki.haskell.org/Functor-Applicative-Monad_Proposal thing |
| 2023-06-21 19:59:04 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 19:59:07 +0200 | <EvanR> | applicative programming started getting formalized out of folklore around 2004 |
| 2023-06-21 19:59:42 +0200 | <ncf> | the naming scheme is a huge mess |
| 2023-06-21 20:00:06 +0200 | <EvanR> | the changes to the class hierarchy came much later |
| 2023-06-21 20:00:33 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-06-21 20:00:37 +0200 | <ncf> | look at traverse/mapM/sequenceA/sequence/for/forM |
| 2023-06-21 20:01:12 +0200 | <EvanR> | Monads for Functional Programming Phil Wadler 1992 |
| 2023-06-21 20:01:17 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2023-06-21 20:01:42 +0200 | <ijqq> | interesting |
| 2023-06-21 20:01:46 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-06-21 20:01:55 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7129-fa0f-75f4-74d9.rev.sfr.net) |
| 2023-06-21 20:02:29 +0200 | <EvanR> | we're about due for another seismic event, category theory programming pattern to be discovered and change the whole stdlib xD |
| 2023-06-21 20:02:55 +0200 | <EvanR> | Arrow kind of fizzled |
| 2023-06-21 20:02:57 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2023-06-21 20:03:36 +0200 | <jade[m]1> | EvanR: I honestly doubt that |
| 2023-06-21 20:03:41 +0200 | <jade[m]1> | but also, I know nothing |
| 2023-06-21 20:03:52 +0200 | <ijqq> | i was reading about some standards to formally there is haskell 98 and 2010? and are there any plans for anything after that? |
| 2023-06-21 20:04:31 +0200 | <Nosrep> | there were plans but they kinda died |
| 2023-06-21 20:04:40 +0200 | <Nosrep> | look up haskell-prime or haskell 2020 or something |
| 2023-06-21 20:04:48 +0200 | <ncf> | GHC2021 :p |
| 2023-06-21 20:04:57 +0200 | <EvanR> | standards would be helpful if it were remotely possible to have anything other than GHC |
| 2023-06-21 20:05:09 +0200 | <jade[m]1> | JHC? |
| 2023-06-21 20:05:13 +0200 | <EvanR> | but the causation isn't going the other way |
| 2023-06-21 20:06:23 +0200 | <EvanR> | other haskell compilers can strive for haskell98 or 2010 |
| 2023-06-21 20:11:08 +0200 | falafel | (~falafel@2607:fb91:86c:d890:f891:31c0:6626:dee4) (Ping timeout: 240 seconds) |
| 2023-06-21 20:14:14 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8) |
| 2023-06-21 20:14:39 +0200 | <EvanR> | Hugs still has some interest, it has a snazzy record system |
| 2023-06-21 20:15:04 +0200 | <ijqq> | yes i took out a book by graham hutton on haskell and it was referencing hugs |
| 2023-06-21 20:15:29 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-06-21 20:20:28 +0200 | jero98772 | (~jero98772@2800:484:1d7f:5d36::4) |
| 2023-06-21 20:20:37 +0200 | ripspin | (~chatzilla@1.145.245.25) (Remote host closed the connection) |
| 2023-06-21 20:29:07 +0200 | zaidhaan | (~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9) (Quit: WeeChat 3.8) |
| 2023-06-21 20:32:06 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-06-21 20:33:54 +0200 | alexherbo2 | (~alexherbo@2a02-842a-8180-4601-7129-fa0f-75f4-74d9.rev.sfr.net) (Remote host closed the connection) |
| 2023-06-21 20:35:20 +0200 | witcher | (~witcher@wiredspace.de) (Remote host closed the connection) |
| 2023-06-21 20:35:36 +0200 | witcher | (~witcher@wiredspace.de) |
| 2023-06-21 20:37:07 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-06-21 20:37:25 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds) |
| 2023-06-21 20:38:55 +0200 | defanor | (~defanor@tart.uberspace.net) (Server closed connection) |
| 2023-06-21 20:39:11 +0200 | defanor | (~defanor@tart.uberspace.net) |
| 2023-06-21 20:42:18 +0200 | user_____ | (~user@x5271795e.dyn.telefonica.de) (Read error: Connection reset by peer) |
| 2023-06-21 20:44:26 +0200 | gensyst | (~gensyst@user/gensyst) (Quit: Leaving) |
| 2023-06-21 20:52:20 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 240 seconds) |
| 2023-06-21 20:52:51 +0200 | candlestick | (~tls@179.152.251.228) |
| 2023-06-21 20:52:57 +0200 | candlestick | (~tls@179.152.251.228) () |
| 2023-06-21 20:54:42 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-06-21 20:55:09 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 21:04:30 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-06-21 21:04:39 +0200 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) (Server closed connection) |
| 2023-06-21 21:04:59 +0200 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:9506:825b:e271:15c3) |
| 2023-06-21 21:05:26 +0200 | Square | (~Square@user/square) |
| 2023-06-21 21:06:00 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 21:07:42 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-06-21 21:11:27 +0200 | user_____ | (~user@82.113.121.94) |
| 2023-06-21 21:12:00 +0200 | <monochrom> | jade[m]1: Are you look for "MP Jones. A system of constructor classes: overloading and implicit higher-order polymorphism. Journal of Functional Programming, 5(1):1–36, January 1995."? (I found in Haskell 2020 Report, Bibliography [8] :) ) |
| 2023-06-21 21:12:43 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Remote host closed the connection) |
| 2023-06-21 21:13:03 +0200 | <jade[m]1> | I was indeed, thank you very much :D |
| 2023-06-21 21:13:09 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 21:13:25 +0200 | <monochrom> | Err Haskell 2010! I was living in an ideal world. |
| 2023-06-21 21:13:50 +0200 | <Nosrep> | :( |
| 2023-06-21 21:14:05 +0200 | <monochrom> | An ideal world in which Haskell had a 2020 standard, and C stopped at C11. |
| 2023-06-21 21:14:07 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 21:14:32 +0200 | <Square> | Anyone know of a Haskell conference this autumn? September or later. |
| 2023-06-21 21:15:17 +0200 | <monochrom> | Maybe Haskell Love again. |
| 2023-06-21 21:15:18 +0200 | <[exa]> | Square: well ICFP is happening sometime in september, right? |
| 2023-06-21 21:16:16 +0200 | <Square> | I'm not a researcher. I'm more into Haskell for applications. |
| 2023-06-21 21:17:23 +0200 | <jade[m]1> | [exa]: In Seattle, damn |
| 2023-06-21 21:17:37 +0200 | <jade[m]1> | I think I just missed everything going on in europe haha |
| 2023-06-21 21:17:48 +0200 | <jade[m]1> | s/just/just barely/ |
| 2023-06-21 21:18:19 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq) |
| 2023-06-21 21:19:40 +0200 | enoq | (~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) |
| 2023-06-21 21:20:42 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-06-21 21:20:51 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-06-21 21:23:14 +0200 | <Square> | monochrom, That looks like it fits my bill. Hope it happens this year too. |
| 2023-06-21 21:25:35 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 258 seconds) |
| 2023-06-21 21:26:55 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:dcc4:bf2d:7f23:5ca4) |
| 2023-06-21 21:27:32 +0200 | chromoblob | (~user@37.113.180.121) |
| 2023-06-21 21:35:41 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:38f8:4900:37c0:4176) (Remote host closed the connection) |
| 2023-06-21 21:38:37 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 258 seconds) |
| 2023-06-21 21:40:11 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 21:47:11 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 256 seconds) |
| 2023-06-21 21:47:57 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 21:48:18 +0200 | EvanR | (~EvanR@user/evanr) (Read error: Connection reset by peer) |
| 2023-06-21 21:48:35 +0200 | EvanR | (~EvanR@user/evanr) |
| 2023-06-21 21:52:51 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 256 seconds) |
| 2023-06-21 21:55:43 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2023-06-21 21:59:18 +0200 | shapr | (~user@2600:1700:c640:3100:d4c2:f56d:9cf0:2080) |
| 2023-06-21 21:59:20 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-06-21 22:02:47 +0200 | vgtw_ | (~vgtw@user/vgtw) |
| 2023-06-21 22:02:50 +0200 | vgtw | (~vgtw@user/vgtw) (Ping timeout: 252 seconds) |
| 2023-06-21 22:03:10 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) |
| 2023-06-21 22:03:45 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 246 seconds) |
| 2023-06-21 22:08:49 +0200 | ft | (~ft@p4fc2afc9.dip0.t-ipconnect.de) |
| 2023-06-21 22:10:43 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-06-21 22:14:12 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2023-06-21 22:14:52 +0200 | <EvanR> | monochrom, or C stopped at 89 which was technically just in time for haskell |
| 2023-06-21 22:22:59 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:dcc4:bf2d:7f23:5ca4) (Quit: WeeChat 2.8) |
| 2023-06-21 22:23:28 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Ping timeout: 258 seconds) |
| 2023-06-21 22:25:11 +0200 | arrowhead | (~arrowhead@2603-7000-9b3f-6934-6cb3-bb7b-d4df-ef98.res6.spectrum.com) |
| 2023-06-21 22:29:26 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-06-21 22:36:03 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-06-21 22:36:14 +0200 | merijn | (~merijn@c-001-001-001.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds) |
| 2023-06-21 22:39:04 +0200 | EvanR_ | (~EvanR@user/evanr) |
| 2023-06-21 22:39:36 +0200 | EvanR | (~EvanR@user/evanr) (Ping timeout: 260 seconds) |
| 2023-06-21 22:40:14 +0200 | jrm | (~jrm@user/jrm) (Server closed connection) |
| 2023-06-21 22:41:35 +0200 | jrm | (~jrm@user/jrm) |
| 2023-06-21 22:42:19 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-06-21 22:49:16 +0200 | jonathan | (~jonathan@c83-252-3-92.bredband.tele2.se) (Ping timeout: 265 seconds) |
| 2023-06-21 22:49:17 +0200 | arrowhead | (~arrowhead@2603-7000-9b3f-6934-6cb3-bb7b-d4df-ef98.res6.spectrum.com) (Read error: Connection reset by peer) |
| 2023-06-21 22:50:12 +0200 | kmein | (~weechat@user/kmein) (Ping timeout: 240 seconds) |
| 2023-06-21 22:50:16 +0200 | rf | (~rf@2605:59c8:179c:f610:1ba8:9082:34c2:6f4b) |
| 2023-06-21 22:50:55 +0200 | arrowhead | (~arrowhead@74.66.76.151) |
| 2023-06-21 22:53:36 +0200 | califax | (~califax@user/califx) |
| 2023-06-21 22:53:52 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 22:55:32 +0200 | user_____ | (~user@82.113.121.94) (Ping timeout: 240 seconds) |
| 2023-06-21 22:56:00 +0200 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2023-06-21 22:58:44 +0200 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-06-21 23:00:23 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2023-06-21 23:00:39 +0200 | codaraxis__ | (~codaraxis@user/codaraxis) |
| 2023-06-21 23:02:21 +0200 | kupi_ | (uid212005@2a03:5180:f:4::3:3c25) (Quit: Connection closed for inactivity) |
| 2023-06-21 23:03:52 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 240 seconds) |
| 2023-06-21 23:07:10 +0200 | exeo | (~Ozymandia@97-119-96-49.omah.qwest.net) |
| 2023-06-21 23:09:23 +0200 | coot | (~coot@89.69.206.216) |
| 2023-06-21 23:11:17 +0200 | acidjnk | (~acidjnk@p200300d6e7072f41682e2ef333aef3bc.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2023-06-21 23:12:24 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2023-06-21 23:13:19 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2023-06-21 23:15:30 +0200 | farn | (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) (Ping timeout: 255 seconds) |
| 2023-06-21 23:15:45 +0200 | EvanR | (~EvanR@user/evanr) |
| 2023-06-21 23:16:19 +0200 | EvanR_ | (~EvanR@user/evanr) (Read error: Connection reset by peer) |
| 2023-06-21 23:17:01 +0200 | farn | (~farn@2a03:4000:7:3cd:d4ab:85ff:feeb:f505) |
| 2023-06-21 23:18:06 +0200 | <ddrone[m]> | TIL about Clerk, the "notebook"-style tool for Clojure that takes just plain source with comments and then renders the result in the browser: https://clerk.vision/ |
| 2023-06-21 23:18:13 +0200 | <ddrone[m]> | Does anything similar exist for Haskell? |
| 2023-06-21 23:18:31 +0200 | <Rembane> | Literate programming + pandoc maybe? |
| 2023-06-21 23:19:05 +0200 | <Rembane> | Oh. This one too! https://github.com/IHaskell/IHaskell |
| 2023-06-21 23:22:10 +0200 | <ddrone[m]> | IHaskell is just Jupyter kernel, which isn't exactly the workflow that Clerk has |
| 2023-06-21 23:22:32 +0200 | <ddrone[m]> | Clerk just takes plain source file and then processes it, without having to use any sort of specialized UI |
| 2023-06-21 23:23:59 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 23:24:02 +0200 | <EvanR> | is it for visualizing random code, or is it for crafting presentable documents |
| 2023-06-21 23:27:14 +0200 | <ddrone[m]> | I'd say second |
| 2023-06-21 23:27:16 +0200 | <ddrone[m]> | Here's an example https://snapshots.nextjournal.com/clerk-demo/build/f8112d44fa742cd0913dcbd370919eca249cbcd9/notebo… |
| 2023-06-21 23:27:55 +0200 | <ddrone[m]> | I guess another thing this reminds me of is Racket's Scribble documentation system |
| 2023-06-21 23:28:00 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 23:28:46 +0200 | <EvanR> | it's like literate programming but with pictures |
| 2023-06-21 23:29:04 +0200 | coot | (~coot@89.69.206.216) (Quit: coot) |
| 2023-06-21 23:29:16 +0200 | <EvanR> | looks good |
| 2023-06-21 23:29:19 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-06-21 23:31:54 +0200 | <ddrone[m]> | Yeah |
| 2023-06-21 23:31:56 +0200 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-06-21 23:32:22 +0200 | <ddrone[m]> | This video has even more demos (which I can't find published online) with animations that have parameters one can control in the browser via sliders https://www.youtube.com/watch?v=B9kqD8vBuwU |
| 2023-06-21 23:33:55 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-06-21 23:33:57 +0200 | <chromoblob> | is unsafePerformIO in the standard? |
| 2023-06-21 23:34:34 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:38f8:4900:37c0:4176) |
| 2023-06-21 23:36:34 +0200 | adium | (adium@user/adium) (Server closed connection) |
| 2023-06-21 23:36:37 +0200 | <geekosaur> | not that I see |
| 2023-06-21 23:36:39 +0200 | <dolio> | No. |
| 2023-06-21 23:37:30 +0200 | adium | (adium@user/adium) |
| 2023-06-21 23:37:30 +0200 | <EvanR> | unsafeNonstandardPerformIO |
| 2023-06-21 23:37:40 +0200 | <dolio> | There is `unsafeLocalState`, which is for calling pure foreign functions that pass arguments via pointers and such. And only a few IO actions are well defined within it. |
| 2023-06-21 23:38:57 +0200 | <chromoblob> | phew |
| 2023-06-21 23:39:07 +0200 | <chromoblob> | hehe |
| 2023-06-21 23:39:45 +0200 | <chromoblob> | a paper is posted on HN that mentions "Haskell's (standard) unsafePerformIO" |
| 2023-06-21 23:39:59 +0200 | <chromoblob> | author is misinformed |
| 2023-06-21 23:40:16 +0200 | rf | (~rf@2605:59c8:179c:f610:1ba8:9082:34c2:6f4b) (Ping timeout: 260 seconds) |
| 2023-06-21 23:40:25 +0200 | <EvanR> | that makes it sound like the secret sauce behind how haskell does anything |
| 2023-06-21 23:40:28 +0200 | <geekosaur> | even the documentation for unsafePerformIO specifies that behavior may differ between implementations |
| 2023-06-21 23:40:31 +0200 | <EvanR> | bog standard unsafePerformIO everywhere |
| 2023-06-21 23:40:46 +0200 | <dolio> | Well, unsafeLocalState has the same type signature. But a lot of things that people think are okay to do are officially "undefined behavior." |
| 2023-06-21 23:40:53 +0200 | michalz | (~michalz@185.246.207.217) (Remote host closed the connection) |
| 2023-06-21 23:41:19 +0200 | phma | (phma@2001:5b0:211f:2f08:cc02:19f0:c9b8:d000) (Read error: Connection reset by peer) |
| 2023-06-21 23:41:23 +0200 | <geekosaur> | accursedUnutterablePerformIO |
| 2023-06-21 23:41:43 +0200 | phma | (~phma@host-67-44-208-160.hnremote.net) |
| 2023-06-21 23:41:59 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) |
| 2023-06-21 23:42:50 +0200 | jargon | (~jargon@174.205.224.32) |
| 2023-06-21 23:43:26 +0200 | <chromoblob> | dolio: is it in the standard? |
| 2023-06-21 23:43:35 +0200 | fendor | (~fendor@2a02:8388:1640:be00:7aca:a77a:4a28:631a) (Remote host closed the connection) |
| 2023-06-21 23:43:36 +0200 | <darkling> | thatPerformIOYouMetOnceAtAParty |
| 2023-06-21 23:43:41 +0200 | <dolio> | Yes. |
| 2023-06-21 23:45:14 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-06-21 23:46:12 +0200 | segfaultfizzbuzz | (~segfaultf@12.172.217.142) (Ping timeout: 240 seconds) |
| 2023-06-21 23:47:59 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-06-21 23:48:48 +0200 | <geekosaur> | https://www.haskell.org/onlinereport/haskell2010/haskellch8.html doesn't seem to say anything about it |
| 2023-06-21 23:49:54 +0200 | <dolio> | It's in chapter 30. |
| 2023-06-21 23:51:25 +0200 | <monochrom> | The Haskell Report needs an index for questions like this. :) |
| 2023-06-21 23:51:34 +0200 | <sm> | just curious.. 1 / 72.35 has a repeating periodic cycle of 1446 decimals. What haskell type/library would let me print as many of these as I want ? |
| 2023-06-21 23:51:42 +0200 | monochrom | re-tells himself the Aesop tale of the world conference of mice |
| 2023-06-21 23:52:19 +0200 | <sm> | Eg Double shows about 16, Decimal shows 255 |
| 2023-06-21 23:53:01 +0200 | <sm> | so if I wanted to print say 10000 decimal places to search for cycles, I'd use.... ? |
| 2023-06-21 23:53:41 +0200 | <EvanR> | > showFFloat (Just 2000) (1/72.35) "" |
| 2023-06-21 23:53:42 +0200 | <lambdabot> | "0.0138217000691085010000000000000000000000000000000000000000000000000000000... |
| 2023-06-21 23:53:51 +0200 | <EvanR> | ok not Double |
| 2023-06-21 23:54:10 +0200 | <EvanR> | you can use a long division loop |
| 2023-06-21 23:54:37 +0200 | <EvanR> | on the number 1000 / 7235 to keep it simple |
| 2023-06-21 23:54:49 +0200 | <EvanR> | 100 / 7235 |
| 2023-06-21 23:55:28 +0200 | sm | wants Mathematica in haskell |
| 2023-06-21 23:55:56 +0200 | <glguy> | sm: https://hackage.haskell.org/package/scientific-0.3.7.0/docs/Data-Scientific.html#v:fromRationalRep… |
| 2023-06-21 23:56:00 +0200 | user____ | (~user@x5271795e.dyn.telefonica.de) |
| 2023-06-21 23:56:27 +0200 | <sm> | nice! |
| 2023-06-21 23:56:28 +0200 | <monochrom> | Yeah actually printing out unlimited digits still does not tell you the period. You really need to do long division and watch for a remainder that shows up for the 2nd time. |
| 2023-06-21 23:56:29 +0200 | <glguy> | If that's not the answer see if the answer is elsewhere in that module. I'm lobbing this in from my phone |
| 2023-06-21 23:56:53 +0200 | <sm> | looks good to me, I'm calling this solved |
| 2023-06-21 23:57:13 +0200 | <monochrom> | For example suppose you have merely seen 336336. You still do not know whether it's 336-repeated or it's 336336337-repeated |
| 2023-06-21 23:57:34 +0200 | <glguy> | monochrom: I stopped counting at 33... |
| 2023-06-21 23:57:41 +0200 | <monochrom> | :) |
| 2023-06-21 23:57:59 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-06-21 23:58:13 +0200 | <monochrom> | There is some halting problem lurking somewhere in there. |
| 2023-06-21 23:58:43 +0200 | <EvanR> | long division on integers uses a finite amount of state, so it must repeat |