| 2025-03-12 00:01:38 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-03-12 00:06:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 00:08:03 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a19a:8794:3896:90e9) (Quit: xff0x) |
| 2025-03-12 00:08:22 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-12 00:11:32 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9140:fdbd:b262:8bcd) |
| 2025-03-12 00:12:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-12 00:23:36 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 00:24:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 00:26:54 +0100 | tabaqui1 | (~root@87.200.129.102) (Ping timeout: 276 seconds) |
| 2025-03-12 00:27:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-03-12 00:28:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-12 00:29:09 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-03-12 00:29:40 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-12 00:39:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 00:42:04 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-12 00:43:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 00:45:06 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 00:46:27 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2025-03-12 00:54:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 00:58:30 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-03-12 00:59:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-03-12 00:59:33 +0100 | euouae | (~euouae@user/euouae) (Ping timeout: 245 seconds) |
| 2025-03-12 01:01:19 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f28ecd38ce1a7966a67.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-03-12 01:02:04 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-48-184-145-138-167.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2025-03-12 01:03:18 +0100 | enikar | (~enikar@user/enikar) (Ping timeout: 245 seconds) |
| 2025-03-12 01:09:01 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 01:10:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 01:13:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-12 01:14:03 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-12 01:14:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 01:16:16 +0100 | enikar | (~enikar@user/enikar) enikar |
| 2025-03-12 01:17:41 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 01:25:05 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-03-12 01:25:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 01:29:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 01:37:14 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2025-03-12 01:39:02 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-12 01:40:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 01:46:50 +0100 | sprotte24 | (~sprotte24@p200300d16f384d0018ca1d25abfd4f54.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-03-12 01:47:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-12 01:54:45 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 01:58:52 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-12 01:59:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 02:03:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-03-12 02:05:53 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9140:fdbd:b262:8bcd) (Ping timeout: 248 seconds) |
| 2025-03-12 02:14:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 02:16:26 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-03-12 02:19:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 02:22:56 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:c403:b663:f780:bd25) (Quit: Leaving) |
| 2025-03-12 02:29:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 02:31:02 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-48-184-145-138-167.dsl.bell.ca) |
| 2025-03-12 02:32:09 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-03-12 02:33:57 +0100 | califax | (~califax@user/califx) califx |
| 2025-03-12 02:34:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 02:35:59 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-48-184-145-138-167.dsl.bell.ca) (Ping timeout: 260 seconds) |
| 2025-03-12 02:41:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 02:45:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 02:45:25 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-12 02:49:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 02:55:50 +0100 | <monochrom> | Every formatter prioritizes minimizing diffs. This has the side effect of being more ugly and even religious. |
| 2025-03-12 02:58:34 +0100 | <monochrom> | But stepping back looking more holistically, that in turn is a side effect of the religion of "source code must be plain text files". |
| 2025-03-12 03:00:12 +0100 | <geekosaur> | the day I don't have to use grep because the tools are too dumb, you can take away my plain text files |
| 2025-03-12 03:00:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 03:01:22 +0100 | <geekosaur> | (the same applies to these overweening new messaging platforms, search is so limited and stupid that I don't even bother on Discord or non-bridged Matrix and I log the bridged rooms on IRC so I can use real search utils) |
| 2025-03-12 03:03:01 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2025-03-12 03:03:17 +0100 | <geekosaur> | (this is not religion, it's falling back on stone knives and bearskins) |
| 2025-03-12 03:03:17 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-03-12 03:04:52 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-12 03:05:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 03:09:24 +0100 | <monochrom> | You have an excellent reason, so I don't say that you follow a religion. Some other people use circular logic; that I call religion. |
| 2025-03-12 03:09:29 +0100 | Guest47 | (~Guest47@2600:387:f:7e18::6) |
| 2025-03-12 03:10:39 +0100 | Guest47 | (~Guest47@2600:387:f:7e18::6) (Client Quit) |
| 2025-03-12 03:15:09 +0100 | <geekosaur> | I'll also note that with LSPs, we're in at best the early Bronze age (granting that switching from plain text files might allow for improvements — but some of the LSPs I've used are at best Stone age, so I must wonder) |
| 2025-03-12 03:15:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 03:17:37 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-03-12 03:22:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-12 03:26:33 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 03:27:36 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-03-12 03:30:41 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-12 03:34:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 03:39:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-12 03:41:15 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-48-184-145-138-167.dsl.bell.ca) |
| 2025-03-12 03:49:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 03:54:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 03:58:50 +0100 | tavare | (~tavare@150.129.88.189) tavare |
| 2025-03-12 03:58:50 +0100 | tavare | (~tavare@150.129.88.189) (Changing host) |
| 2025-03-12 03:58:50 +0100 | tavare | (~tavare@user/tavare) tavare |
| 2025-03-12 04:03:51 +0100 | izzyfalco | (~jake_pers@user/izzyfalco) izzyfalco |
| 2025-03-12 04:05:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 04:05:18 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-12 04:09:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 04:11:57 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 04:16:39 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
| 2025-03-12 04:20:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 04:24:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-12 04:30:30 +0100 | enikar | (~enikar@user/enikar) (Quit: WeeChat 4.5.1) |
| 2025-03-12 04:34:04 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-12 04:35:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 04:40:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 04:43:31 +0100 | yegorc | (~yegorc@user/yegorc) (Quit: Leaving) |
| 2025-03-12 04:44:57 +0100 | izzyfalco | (~jake_pers@user/izzyfalco) (Ping timeout: 276 seconds) |
| 2025-03-12 04:51:13 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 04:55:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-12 04:57:21 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 04:58:27 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
| 2025-03-12 05:00:29 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-12 05:01:25 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-12 05:06:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:06:58 +0100 | euouae | (~euouae@user/euouae) euouae |
| 2025-03-12 05:13:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 05:18:43 +0100 | <euouae> | This thread <https://www.reddit.com/r/haskell/comments/5zjwym/when_is_undecidableinstances_okay_to_use/> has good info on UndecidableInstances, the other two were easier to understand |
| 2025-03-12 05:22:52 +0100 | <EvanR> | The constraint ‘Monad (t n)’ is no smaller than the instance head (Use UndecidableInstances to permit this) |
| 2025-03-12 05:22:58 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-12 05:23:16 +0100 | <EvanR> | it's really nice when the compiler knows that it will finish and not enter into an infinite loop |
| 2025-03-12 05:23:33 +0100 | <EvanR> | which these smaller conditions guarantee |
| 2025-03-12 05:24:19 +0100 | <euouae> | what I gathered from the reddit post is that the 's' is not getting smaller and that is the issue |
| 2025-03-12 05:24:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:24:40 +0100 | <euouae> | but at the same time it's fine because of the functional dependency | m -> s in the definition of MonadState in mtl |
| 2025-03-12 05:26:13 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 245 seconds) |
| 2025-03-12 05:26:51 +0100 | <EvanR> | the first thing I thought was "for some reason, this idea of default implementations that work for everything with a certain typeclass instance is frowned upon" and couldn't remember the reason |
| 2025-03-12 05:27:03 +0100 | <EvanR> | then ekmett gets to that in the response |
| 2025-03-12 05:27:16 +0100 | <EvanR> | it leads to overlapping instances |
| 2025-03-12 05:28:35 +0100 | <EvanR> | typeclasses aren't built to do the sort of "overriding" that you see in prototypal OOP. Your type either has a single instance for the class, or it doesn't. Not competing instances with priority |
| 2025-03-12 05:28:51 +0100 | <EvanR> | (unless you do overlapping instances and god help you) |
| 2025-03-12 05:29:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 05:30:14 +0100 | mange | (~user@user/mange) mange |
| 2025-03-12 05:31:23 +0100 | <c_wraith> | UndecidableInstances is basically always fine to turn on. It's when you do and then GHC tells you the next thing to do is turn on overlapping, you know you're doing something wrong. |
| 2025-03-12 05:32:56 +0100 | <euouae> | I wasn't sure in what situation I'd run into undecidability with instance declarations |
| 2025-03-12 05:33:15 +0100 | <euouae> | perhaps if I did `instance Foo (F x) => Foo x where ...`? |
| 2025-03-12 05:33:15 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:c559:e625:333a:3d27) (Read error: Connection reset by peer) |
| 2025-03-12 05:34:04 +0100 | <euouae> | but I'm assuming you're saying that the more important/encountered issue is overlapping instances |
| 2025-03-12 05:34:24 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:98ab:59f5:dcb3:c8fc) synchromesh |
| 2025-03-12 05:34:32 +0100 | <EvanR> | does the implied kind expected by the hypothetical Foo class make sense there |
| 2025-03-12 05:34:37 +0100 | <c_wraith> | yeah, that example would trigger it, but that's not a problem. The problem is that that instance overlaps everything |
| 2025-03-12 05:34:45 +0100 | <c_wraith> | So then ghc is going to tell you to allow overlapping |
| 2025-03-12 05:34:51 +0100 | <c_wraith> | and that's when things get fragile |
| 2025-03-12 05:35:09 +0100 | <EvanR> | ok nvm that |
| 2025-03-12 05:35:46 +0100 | <euouae> | oh I see |
| 2025-03-12 05:39:23 +0100 | <EvanR> | I tried it |
| 2025-03-12 05:39:37 +0100 | <EvanR> | GHC rejects my code because of overlapping instances |
| 2025-03-12 05:39:42 +0100 | <EvanR> | but at least doesn't tell me to turn it on xD |
| 2025-03-12 05:40:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:40:05 +0100 | <c_wraith> | I guess when overlapping was moved to a per-instance pragma, they decided not to advise turning it on |
| 2025-03-12 05:40:09 +0100 | <EvanR> | (and LANGUAGE OverlappingInstances is deprecated) |
| 2025-03-12 05:40:21 +0100 | <c_wraith> | when it was module level, it did just say "turn on this extension to allow this" |
| 2025-03-12 05:42:45 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 05:43:15 +0100 | <c_wraith> | A common way to end up needing UndecidableInstances without MPTCs or Overlapping is stuff like Fix. `newtype Fix f = Fix (f (Fix f))`. Attempting the automatic Show instance for that ends up with the compiler trying to write something like `instance Show (f (Fix f)) => Show (Fix f) ...` |
| 2025-03-12 05:43:32 +0100 | <c_wraith> | And in that case, the constraint is definitely larger than the instance head. |
| 2025-03-12 05:44:34 +0100 | <c_wraith> | On one hand, that's why the Show1 class exists. On the other, you can do it with UndecidableInstances and StandaloneDeriving. |
| 2025-03-12 05:45:44 +0100 | <EvanR> | I continued to try to troll ghc with some terrible overlapping instances |
| 2025-03-12 05:45:59 +0100 | <EvanR> | ghci told me to enable IncoherentInstances |
| 2025-03-12 05:46:16 +0100 | <c_wraith> | you should be getting nervous. |
| 2025-03-12 05:46:19 +0100 | <EvanR> | lol |
| 2025-03-12 05:46:53 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-12 05:46:55 +0100 | <euouae> | it's like those no-fault waivers |
| 2025-03-12 05:47:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 05:49:58 +0100 | <EvanR> | now it's telling me the reduction stack size of 201 ran out, and instead of increasing it, to disable the check if I'm sure type checking will terminate |
| 2025-03-12 05:50:28 +0100 | <c_wraith> | I'm sure nothing bad could happen |
| 2025-03-12 05:50:36 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2025-03-12 05:52:02 +0100 | <EvanR> | when someone said haskell is not a logic they weren't kidding |
| 2025-03-12 05:52:19 +0100 | <c_wraith> | pfft. It's a logic, it's just not a consistent one. |
| 2025-03-12 05:52:52 +0100 | <EvanR> | falso 9.6 |
| 2025-03-12 05:53:29 +0100 | <c_wraith> | inconsistent logics are nice because they let you prove anything, and so does Haskell |
| 2025-03-12 05:54:37 +0100 | <EvanR> | that being said, the type class system always terminates if you don't enable any dark magic pragmas right |
| 2025-03-12 05:55:04 +0100 | <EvanR> | so there's a way to use it semilogically |
| 2025-03-12 05:55:13 +0100 | <c_wraith> | yes. the solver always shrinks the problem with the default rules |
| 2025-03-12 05:56:26 +0100 | tusko | (uid478376@user/tusko) tusko |
| 2025-03-12 05:57:10 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.5.2) |
| 2025-03-12 05:57:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 06:02:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-12 06:06:07 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 06:06:58 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 272 seconds) |
| 2025-03-12 06:13:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 06:17:11 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-03-12 06:17:33 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-03-12 06:20:52 +0100 | sabathan | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-03-12 06:23:32 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) robobub |
| 2025-03-12 06:28:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 06:28:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 06:31:19 +0100 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-12 06:32:37 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-12 06:33:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 06:34:44 +0100 | <euouae> | alright thank you both! |
| 2025-03-12 06:34:46 +0100 | euouae | (~euouae@user/euouae) () |
| 2025-03-12 06:35:02 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 06:41:39 +0100 | michalz | (~michalz@185.246.207.221) |
| 2025-03-12 06:43:04 +0100 | k0zy | (~user@user/k0zy) k0zy |
| 2025-03-12 06:43:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 06:50:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 06:55:01 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-12 07:01:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 07:02:29 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
| 2025-03-12 07:04:13 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-12 07:07:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-12 07:14:33 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 07:16:15 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2025-03-12 07:17:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 07:18:58 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-12 07:22:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-03-12 07:25:26 +0100 | k0zy | (~user@user/k0zy) (Remote host closed the connection) |
| 2025-03-12 07:27:43 +0100 | k0zy | (~user@user/k0zy) k0zy |
| 2025-03-12 07:27:43 +0100 | Vajb | (~Vajb@85-76-36-81-nat.elisa-mobile.fi) (Read error: Connection reset by peer) |
| 2025-03-12 07:27:47 +0100 | T0NN | (~T0NN@2404:c0:2c10::16be:e80d) |
| 2025-03-12 07:29:30 +0100 | Vajb | (~Vajb@n83sqe30rcw6481fyv6-1.v6.elisa-mobile.fi) |
| 2025-03-12 07:29:37 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-03-12 07:32:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 07:32:56 +0100 | k0zy | (~user@user/k0zy) (Remote host closed the connection) |
| 2025-03-12 07:34:06 +0100 | T0NN | (~T0NN@2404:c0:2c10::16be:e80d) (Ping timeout: 240 seconds) |
| 2025-03-12 07:37:03 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-12 07:43:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 07:47:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 07:58:34 +0100 | k0zy | (~user@user/k0zy) k0zy |
| 2025-03-12 07:58:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 08:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-12 08:00:52 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-12 08:03:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 08:06:17 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180::ac59) CiaoSen |
| 2025-03-12 08:06:38 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 08:11:02 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-12 08:12:13 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-03-12 08:13:00 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2025-03-12 08:13:33 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-03-12 08:13:58 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-12 08:14:09 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-03-12 08:14:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 08:17:12 +0100 | p3n | (~p3n@217.198.124.246) p3n |
| 2025-03-12 08:17:12 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 08:19:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 08:19:16 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-12 08:28:18 +0100 | izzyfalco | (~jake_pers@user/izzyfalco) izzyfalco |
| 2025-03-12 08:29:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 08:36:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 08:40:42 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 244 seconds) |
| 2025-03-12 08:42:19 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-03-12 08:42:33 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-03-12 08:44:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 08:49:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 08:51:07 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-03-12 08:51:46 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2025-03-12 08:52:22 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 08:56:30 +0100 | chele | (~chele@user/chele) chele |
| 2025-03-12 08:56:31 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2025-03-12 08:56:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-12 08:58:56 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-03-12 08:59:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 09:03:10 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-12 09:04:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 09:06:42 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-03-12 09:10:26 +0100 | <kaol> | I just realized that I can use traverse instead of maybe (pure ()). Much nicer to look at. |
| 2025-03-12 09:10:35 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-03-12 09:10:54 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-03-12 09:14:25 +0100 | <ski> | or `for' |
| 2025-03-12 09:18:58 +0100 | <kaol> | Not unless I flip it. |
| 2025-03-12 09:22:35 +0100 | ft | (~ft@p508db291.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-03-12 09:24:40 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52ecd38ce1a7966a67.dip0.t-ipconnect.de) acidjnk |
| 2025-03-12 09:28:32 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-03-12 09:31:05 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Quit: ljdarj) |
| 2025-03-12 09:31:24 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-12 09:37:05 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 09:40:16 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-03-12 09:41:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-12 09:48:53 +0100 | tusko | (uid478376@user/tusko) (Quit: Connection closed for inactivity) |
| 2025-03-12 09:57:49 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 10:00:06 +0100 | stilgart | (~Christoph@chezlefab.net) stilgart |
| 2025-03-12 10:00:27 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-03-12 10:03:47 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-03-12 10:06:54 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
| 2025-03-12 10:08:29 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 10:13:51 +0100 | izzyfalco | (~jake_pers@user/izzyfalco) (Ping timeout: 252 seconds) |
| 2025-03-12 10:23:10 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 10:27:28 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-03-12 10:34:29 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-03-12 10:36:32 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-12 10:40:16 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2025-03-12 10:40:38 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-03-12 10:44:19 +0100 | <mauke> | rule of thumb: it's always traverse |
| 2025-03-12 10:48:00 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
| 2025-03-12 10:49:15 +0100 | tabaqui1 | (~root@87.200.129.102) tabaqui |
| 2025-03-12 10:49:55 +0100 | <dminuoso> | Also, you can just locally rename/constraint its type |
| 2025-03-12 10:49:59 +0100 | <dminuoso> | % withJust :: Maybe a -> (a -> IO b) -> IO (); withJust = for_b |
| 2025-03-12 10:49:59 +0100 | <yahb2> | <interactive>:343:57: error: [GHC-88464] ; Variable not in scope: for_b :: Maybe a -> (a -> IO b) -> IO () ; Suggested fix: Perhaps use ‘for_’ (imported from Data.Foldable) |
| 2025-03-12 10:50:02 +0100 | <dminuoso> | % withJust :: Maybe a -> (a -> IO b) -> IO (); withJust = for_ |
| 2025-03-12 10:50:02 +0100 | <yahb2> | <no output> |
| 2025-03-12 10:50:24 +0100 | <dminuoso> | Especially for using Traversable/Foldable instances that are not immediately clear |
| 2025-03-12 10:51:00 +0100 | preflex_ | (~preflex@user/mauke/bot/preflex) preflex |
| 2025-03-12 10:51:01 +0100 | pata | (~pata@185.57.29.142) |
| 2025-03-12 10:51:16 +0100 | Guest30566 | (~Guest3056@fixed-187-189-0-231.totalplay.net) |
| 2025-03-12 10:51:28 +0100 | <dminuoso> | Over all my Haskell time, my code complexity/tricky has followed a parabola. |
| 2025-03-12 10:51:33 +0100 | <kaol> | traverse @Maybe |
| 2025-03-12 10:52:58 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2025-03-12 10:53:05 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 10:53:43 +0100 | Guest71 | (~Guest3056@fixed-187-189-0-231.totalplay.net) |
| 2025-03-12 10:54:33 +0100 | preflex | (~preflex@user/mauke/bot/preflex) (Ping timeout: 252 seconds) |
| 2025-03-12 10:54:48 +0100 | preflex_ | preflex |
| 2025-03-12 10:55:48 +0100 | Clint | (~Clint@user/clint) (Ping timeout: 245 seconds) |
| 2025-03-12 10:56:51 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 265 seconds) |
| 2025-03-12 10:57:19 +0100 | Clint | (~Clint@user/clint) Clint |
| 2025-03-12 10:57:59 +0100 | <__monty__> | dminuoso: -x^2 or x^2? : > |
| 2025-03-12 10:58:19 +0100 | <dminuoso> | Heh. |
| 2025-03-12 10:59:02 +0100 | <dminuoso> | Right in the middle I was exploring all the type level tricks, dependent typing, effects, had it all. :-) |
| 2025-03-12 11:01:45 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-03-12 11:07:10 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 11:09:35 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 11:14:00 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-03-12 11:32:57 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
| 2025-03-12 11:34:54 +0100 | pata | (~pata@185.57.29.142) (Ping timeout: 240 seconds) |
| 2025-03-12 11:35:33 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.1) |
| 2025-03-12 11:47:49 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2025-03-12 11:48:34 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-03-12 11:49:09 +0100 | fp | (~Thunderbi@wireless-86-50-140-47.open.aalto.fi) fp |
| 2025-03-12 11:51:32 +0100 | xff0x | (~xff0x@2405:6580:b080:900:7a6d:e986:6f30:4a1b) |
| 2025-03-12 11:54:02 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 272 seconds) |
| 2025-03-12 11:55:39 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 12:00:27 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 276 seconds) |
| 2025-03-12 12:03:17 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-03-12 12:07:02 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:b341:438:8f09:aa92) ubert |
| 2025-03-12 12:10:51 +0100 | tavare | (~tavare@user/tavare) (Remote host closed the connection) |
| 2025-03-12 12:11:17 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
| 2025-03-12 12:13:35 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-03-12 12:14:56 +0100 | <[exa]> | so let's say I want to make some minor stats work with haskell and I want to have self-organizing maps implemented. Or k-means or any such thing. Involves matrices with tons (millions) of multidimensional (say 50D) points. What package to choose? The computation depends mainly on fast dot-products between slices of the matrices. |
| 2025-03-12 12:15:42 +0100 | <[exa]> | (I'd go accelerate but it sounds a bit like overkill, I don't need it blazing fast; I'm pretty much ok with just "not stupidly inefficient".) |
| 2025-03-12 12:17:44 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 12:19:27 +0100 | tabaqui | (~root@167.71.80.236) (Quit: WeeChat 4.5.1) |
| 2025-03-12 12:25:05 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 12:26:41 +0100 | tabaqui | (~root@167.71.80.236) (Client Quit) |
| 2025-03-12 12:28:54 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180::ac59) (Ping timeout: 268 seconds) |
| 2025-03-12 12:41:43 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 12:46:07 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-12 12:49:48 +0100 | sprotte24 | (~sprotte24@p200300d16f4b7200116db6fce964005a.dip0.t-ipconnect.de) |
| 2025-03-12 12:57:19 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180::ac59) CiaoSen |
| 2025-03-12 12:58:52 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-03-12 13:00:34 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 13:05:36 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
| 2025-03-12 13:09:39 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52ecd38ce1a7966a67.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-03-12 13:10:19 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52ecd38ce1a7966a67.dip0.t-ipconnect.de) acidjnk |
| 2025-03-12 13:14:59 +0100 | <cheater> | just use accelerate |
| 2025-03-12 13:17:09 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 13:24:16 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
| 2025-03-12 13:24:55 +0100 | Guest71 | (~Guest3056@fixed-187-189-0-231.totalplay.net) (Quit: Client closed) |
| 2025-03-12 13:24:55 +0100 | Guest30566 | (~Guest3056@fixed-187-189-0-231.totalplay.net) (Quit: Client closed) |
| 2025-03-12 13:28:07 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 13:28:09 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-03-12 13:30:37 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-12 13:32:21 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-12 13:33:54 +0100 | jespada | (~jespada@2800:a4:230e:8000:1050:5077:c5ef:191f) jespada |
| 2025-03-12 13:34:13 +0100 | enikar | (~enikar@user/enikar) enikar |
| 2025-03-12 13:35:07 +0100 | jespada_ | (~jespada@2800:a4:230e:8000:1050:5077:c5ef:191f) jespada |
| 2025-03-12 13:38:12 +0100 | jespada | (~jespada@2800:a4:230e:8000:1050:5077:c5ef:191f) (Ping timeout: 246 seconds) |
| 2025-03-12 13:48:12 +0100 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-03-12 13:53:33 +0100 | Square2 | (~Square4@user/square) Square |
| 2025-03-12 13:55:01 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
| 2025-03-12 13:55:22 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-03-12 13:59:59 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-12 14:02:38 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 14:04:51 +0100 | jespada_ | (~jespada@2800:a4:230e:8000:1050:5077:c5ef:191f) (Ping timeout: 252 seconds) |
| 2025-03-12 14:05:08 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52ecd38ce1a7966a67.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2025-03-12 14:07:53 +0100 | manwithluck | (~manwithlu@2a00:7c80:0:3c5::14) (Ping timeout: 245 seconds) |
| 2025-03-12 14:09:14 +0100 | jespada | (~jespada@2800:a4:22b4:9a00:f994:da25:97cf:4452) jespada |
| 2025-03-12 14:13:31 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 14:16:57 +0100 | fp | (~Thunderbi@wireless-86-50-140-47.open.aalto.fi) (Ping timeout: 276 seconds) |
| 2025-03-12 14:17:26 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-03-12 14:17:45 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-03-12 14:26:26 +0100 | <tomsmeding> | [exa]: if "not stupidly inefficient" is good enough: storable or unboxed vectors |
| 2025-03-12 14:26:46 +0100 | <tomsmeding> | also massiv exists |
| 2025-03-12 14:27:22 +0100 | <tomsmeding> | much easier to install than accelerate, currently |
| 2025-03-12 14:31:33 +0100 | <tomsmeding> | [exa]: hmatrix has faster routines on vectors (by writing them in C, which does vectorisation where GHC does not) |
| 2025-03-12 14:32:01 +0100 | <tomsmeding> | it also pollutes the instance namespace by putting Num, etc. instances on storable vectors |
| 2025-03-12 14:32:46 +0100 | <kuribas> | tomsmeding: doesn't accelerate use llvm? |
| 2025-03-12 14:32:51 +0100 | <tomsmeding> | yes |
| 2025-03-12 14:33:15 +0100 | <merijn> | Storable Vectors are great |
| 2025-03-12 14:33:22 +0100 | <tomsmeding> | I have an unmerged patch to accelerate to not link to LLVM but pass LLVM IR to clang instead, which makes the whole thing a lot easier to install |
| 2025-03-12 14:33:32 +0100 | <tomsmeding> | we hope to get it in somewhere this spring, but no guarantees |
| 2025-03-12 14:34:50 +0100 | <kuribas> | Shouldn't it be faster than massiv/hmatrix then? |
| 2025-03-12 14:34:54 +0100 | <tomsmeding> | yes |
| 2025-03-12 14:35:13 +0100 | <tomsmeding> | with the hackage-released versions of packages, you also need to install LLVM 9, both static and dynamic libraries |
| 2025-03-12 14:35:21 +0100 | <tomsmeding> | this was easy on ubuntu a few years ago |
| 2025-03-12 14:35:57 +0100 | <tomsmeding> | with git master versions of stuff, you can use LLVM 15, still static _and_ dynamic libraries, which is easy on current ubuntu and macOS |
| 2025-03-12 14:38:49 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-12 14:41:47 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-12 14:51:08 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 14:52:15 +0100 | forell_ | (~forell@host-178-216-90-220.sta.tvknaszapraca.pl) (Quit: ZNC - https://znc.in) |
| 2025-03-12 14:52:26 +0100 | <Inst> | btw probie thanks for teaching me how to abuse foldr on lists; after playing around for optimization, foldr is almost literally a for loop due to foldr triggering list fusion |
| 2025-03-12 14:54:37 +0100 | forell | (~forell@user/forell) forell |
| 2025-03-12 14:59:00 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:7180::ac59) (Ping timeout: 265 seconds) |
| 2025-03-12 14:59:14 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 15:03:11 +0100 | son0p | (~ff@2800:e6:4000:d723:c181:4205:f2b1:437a) (Read error: Connection reset by peer) |
| 2025-03-12 15:03:59 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-12 15:07:17 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52210926b325fe4262.dip0.t-ipconnect.de) |
| 2025-03-12 15:19:23 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-140e-55c2-d7c2-899b-0789.rev.sfr.net) alexherbo2 |
| 2025-03-12 15:22:55 +0100 | T0NN | (~T0NN@104.28.196.52) |
| 2025-03-12 15:23:18 +0100 | son0p | (~ff@2800:e6:4000:d723:c181:4205:f2b1:437a) son0p |
| 2025-03-12 15:23:35 +0100 | T0NN | (~T0NN@104.28.196.52) (Client Quit) |
| 2025-03-12 15:24:48 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 252 seconds) |
| 2025-03-12 15:24:54 +0100 | <carbolymer> | is Data.List.sortBy guaranteed to be stable over `[Foo]` if I have a trivial `instance Ord Foo where compare _ _ = LT` ? In other words, I expect it to not change the order of elements. |
| 2025-03-12 15:25:15 +0100 | T0NN | (~T0NN@104.28.196.52) |
| 2025-03-12 15:25:23 +0100 | <carbolymer> | `sortBy compare` I mean |
| 2025-03-12 15:25:55 +0100 | <carbolymer> | even simpler: `sortBy (\_ _ -> LT)` |
| 2025-03-12 15:26:14 +0100 | <tomsmeding> | I'm fairly sure yes |
| 2025-03-12 15:26:35 +0100 | T0NN | (~T0NN@104.28.196.52) (Client Quit) |
| 2025-03-12 15:26:51 +0100 | T0NN | (~T0NN@104.28.196.52) |
| 2025-03-12 15:27:14 +0100 | <tomsmeding> | looking at the implementation, for lists of length <=4 it has a manually written decision tree that, if I am to believe the comments, should only reorder if a preceding element is strictly greater than a following element |
| 2025-03-12 15:27:39 +0100 | <tomsmeding> | for longer lists, it splits the list into runs of alternatingly ascending/descending elements; in your case there's just one run, so the algorithm terminates there |
| 2025-03-12 15:28:10 +0100 | T0NN | (~T0NN@104.28.196.52) (Client Quit) |
| 2025-03-12 15:28:57 +0100 | <carbolymer> | that was my intuition, thanks tomsmeding for confirming ;] |
| 2025-03-12 15:28:59 +0100 | <tomsmeding> | carbolymer: from the haddocks of 'sort': The sort function implements a stable sorting algorithm. |
| 2025-03-12 15:29:21 +0100 | <tomsmeding> | it would be nice if this was also mentioned in 'sortBy', but I think we can extrapolate |
| 2025-03-12 15:30:39 +0100 | <carbolymer> | >otherwise, e. g., for _ _ -> GT, the ordered list simply does not exist |
| 2025-03-12 15:30:39 +0100 | <carbolymer> | I guess it's not true for all comparison functions in sortBy |
| 2025-03-12 15:31:11 +0100 | <carbolymer> | but in my quick test `sortBy (\_ _ -> GT)` results in just reversed list |
| 2025-03-12 15:34:53 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-03-12 15:45:39 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 15:47:40 +0100 | lottaquestions | (~nick@2607:fa49:5040:b100:5b52:ac7b:b1b7:f59f) lottaquestions |
| 2025-03-12 15:50:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-03-12 15:54:03 +0100 | T0NN | (~T0NN@193.42.62.209) |
| 2025-03-12 16:00:39 +0100 | <[exa]> | tomsmeding: iiiiiiiinteresting thanks! |
| 2025-03-12 16:07:05 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-03-12 16:14:08 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 245 seconds) |
| 2025-03-12 16:22:47 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-03-12 16:24:41 +0100 | Guest99 | (~Guest47@2600:387:f:7e18::6) |
| 2025-03-12 16:32:06 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-12 16:33:05 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 16:33:35 +0100 | T0NN | (~T0NN@193.42.62.209) (Quit: Client closed) |
| 2025-03-12 16:37:04 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-03-12 16:37:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-03-12 16:37:39 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 16:40:04 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2025-03-12 16:42:01 +0100 | Guest99 | (~Guest47@2600:387:f:7e18::6) (Quit: Client closed) |
| 2025-03-12 16:42:31 +0100 | <Inst> | when you're parallelizing a fold |
| 2025-03-12 16:42:46 +0100 | <Inst> | a foldr |
| 2025-03-12 16:43:46 +0100 | <Inst> | \a cont -> par cont a `pseq` ...; is it more correct to have par a cont or par cont a? |
| 2025-03-12 16:46:29 +0100 | <c_wraith> | that's going to be highly workload-dependent. There's no generally correct answer. |
| 2025-03-12 16:46:46 +0100 | <Inst> | thanks |
| 2025-03-12 16:47:50 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:91e8:307c:455b:5f65) |
| 2025-03-12 16:49:40 +0100 | <Inst> | what is the difference, though? |
| 2025-03-12 16:49:54 +0100 | <Inst> | par a cont should be generating a ton of sparks, but the cont can't return until all the sparks are generated, right? |
| 2025-03-12 16:50:42 +0100 | <c_wraith> | `par a b' creates a spark to evaluate a and returns b. |
| 2025-03-12 16:51:56 +0100 | <Inst> | i have two dummy cases under Data.Time benchmarking, the first is par a b, the second is par b a |
| 2025-03-12 16:53:01 +0100 | <ski> | `pseq (par cont a) (..)' seems a bit useless, the `a' will get ignored by the `pseq' ? |
| 2025-03-12 16:53:40 +0100 | <ski> | (well, i suppose it will be forced to WHNF. but not sparked) |
| 2025-03-12 16:53:43 +0100 | <Inst> | it's weird, because the par cont a, #1, generates more sparks, #2, fizzles more sparts, and #3, is faster |
| 2025-03-12 16:54:37 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-03-12 16:55:30 +0100 | <c_wraith> | It's all *very* dependent on context. the whole way par works only is effective because of laziness. |
| 2025-03-12 16:55:45 +0100 | <ski> | so, with `par cont a', you're sparking odd the recursive calls in `foldr'. each one performed would force its `a'. with `par a cont', you'd instead be sparking off the `a's all directly |
| 2025-03-12 16:55:59 +0100 | <ski> | s/odd/off/ |
| 2025-03-12 16:56:50 +0100 | <c_wraith> | foldr is too low-level to really parallelize in any meaningful way. |
| 2025-03-12 16:56:56 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 16:58:38 +0100 | <c_wraith> | all it does is hand control back to f immediately, with all other behavior up to f. |
| 2025-03-12 16:59:44 +0100 | <c_wraith> | Depending on what f does, it might make sense to do any number of different things in parallel. Or none. |
| 2025-03-12 17:01:04 +0100 | <ski> | mm |
| 2025-03-12 17:01:14 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 17:01:38 +0100 | <c_wraith> | and heck. Even where the input list is coming from matters. Does the generation of the input list have a linear data dependency? Well, then, you're not going to benefit a lot from attempting to process multiple elements in parallel. |
| 2025-03-12 17:01:43 +0100 | <Inst> | it's foldr (\a cont -> par cont a `pseq` a: cont) |
| 2025-03-12 17:01:49 +0100 | <Inst> | something like that |
| 2025-03-12 17:01:59 +0100 | <c_wraith> | oh. so you're actually writing parMap |
| 2025-03-12 17:02:24 +0100 | <Inst> | parMap iirc is implemented via Eval monad, which wraps unsafePerformIO |
| 2025-03-12 17:02:42 +0100 | <Inst> | i'm trying to set up parFold for a ParFoldable typeclass |
| 2025-03-12 17:03:39 +0100 | <Inst> | but yeah, I realize that doing it via monoids is the wrong interface, but might as well be there? |
| 2025-03-12 17:04:23 +0100 | <Inst> | so it's actually (\(a,b) cont -> let res = a <> b in par cont res `pseq` res : cont) |
| 2025-03-12 17:05:44 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2025-03-12 17:07:15 +0100 | <c_wraith> | that's going to parallelize horribly anyway. It's too low-level. |
| 2025-03-12 17:07:48 +0100 | <c_wraith> | It turns out this isn't just something you can sprinkle on top of existing code to get magic results. |
| 2025-03-12 17:08:02 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2025-03-12 17:08:07 +0100 | <c_wraith> | Which is why it really isn't a big thing |
| 2025-03-12 17:08:40 +0100 | <Inst> | monoid interface is too restrictive, and this type of large-array stuff i'm testing for is better done via a specialized library supporting massively parallel computing |
| 2025-03-12 17:08:56 +0100 | <Inst> | but the degenerate case, at least for me, seems to open up interesting questions |
| 2025-03-12 17:09:24 +0100 | <ski> | i don't really see the point of using `par cont (..)' here. what's the intent ? |
| 2025-03-12 17:09:37 +0100 | <c_wraith> | also, it turns out that [] is especially hostile to parallelization |
| 2025-03-12 17:09:50 +0100 | <Inst> | !!! |
| 2025-03-12 17:10:34 +0100 | <Inst> | ski: it's a stupid rabbit hole that I somehow expect has treasure instead of the usual contents of rabbit holes |
| 2025-03-12 17:11:01 +0100 | <Inst> | the interesting thing is that a cont, in this particular context, is effectively foldr' |
| 2025-03-12 17:11:23 +0100 | <Inst> | since it has to evaluate all the way to the end of the list before it returns anything |
| 2025-03-12 17:11:25 +0100 | <c_wraith> | well, not exactly. |
| 2025-03-12 17:11:38 +0100 | <Inst> | why not? |
| 2025-03-12 17:11:59 +0100 | <c_wraith> | Oh, in that order. Yes, it is. |
| 2025-03-12 17:12:22 +0100 | <c_wraith> | except it's creating a spark at every single level |
| 2025-03-12 17:12:37 +0100 | <Inst> | and that explains the contradiction, right? |
| 2025-03-12 17:13:00 +0100 | <c_wraith> | even if multiples of them fire, they're going to face blackhole contention or redundant work |
| 2025-03-12 17:13:39 +0100 | <Inst> | there's 80-90% conversion, efficient spark creation (iirc it generates less sparks overall), but it takes forever on a 10 million element list |
| 2025-03-12 17:13:49 +0100 | <Inst> | like 8 times the cont a version |
| 2025-03-12 17:13:57 +0100 | <Inst> | which has 60% conversion and creates 2-4 times more sparks |
| 2025-03-12 17:14:12 +0100 | <c_wraith> | please, do you know how ghc uses blackholes? |
| 2025-03-12 17:14:22 +0100 | <Inst> | no :( |
| 2025-03-12 17:14:49 +0100 | <c_wraith> | you need to understand how ghc implements lazy evaluation before you can really understand this. |
| 2025-03-12 17:16:15 +0100 | <c_wraith> | there is contention on trying to evaluate the same value twice in parallel |
| 2025-03-12 17:16:36 +0100 | <Inst> | and apparently it blocks threads? |
| 2025-03-12 17:16:52 +0100 | <c_wraith> | that's what contention does, yes |
| 2025-03-12 17:18:38 +0100 | <c_wraith> | The only way to make this pay off at the level par works at is to work with a very high-level understanding of what your code is doing. |
| 2025-03-12 17:19:08 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 17:19:24 +0100 | <c_wraith> | You can't just write a parallel fold. You need to consider what the fold is actually doing and parallelize that. |
| 2025-03-12 17:19:50 +0100 | <Inst> | thank you for answering why parFoldMap isn't a thing |
| 2025-03-12 17:19:54 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-12 17:20:56 +0100 | <Inst> | the actual goal here is to fold every element in the list with the adjacent element, producing a new list, then fold the resulting list until it reduces to one level |
| 2025-03-12 17:21:12 +0100 | <Inst> | so it's called recursively on itself until it matches [x] |
| 2025-03-12 17:21:49 +0100 | <ski> | sounds similar to a merge sort, in that tree aspect |
| 2025-03-12 17:22:42 +0100 | <Inst> | sorry, it's a dumb exercise, but i find it fun to think through and try to test |
| 2025-03-12 17:23:05 +0100 | <ski> | (or maybe you're combining each element with its next element, as opposed to ones at even indices with the following adjacent ones at odd indices) |
| 2025-03-12 17:23:31 +0100 | <Inst> | well tbh i probably should try implementing it imperatively in some other language |
| 2025-03-12 17:23:46 +0100 | <c_wraith> | Be sure to use linked lists in the other language, too. |
| 2025-03-12 17:24:00 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-03-12 17:24:26 +0100 | <c_wraith> | because that's the part that's leading to so many of these issues |
| 2025-03-12 17:25:19 +0100 | <ski> | > (zipWith (+) `ap` tail) [0 .. 7] |
| 2025-03-12 17:25:20 +0100 | <lambdabot> | [1,3,5,7,9,11,13] |
| 2025-03-12 17:25:23 +0100 | <ski> | > map (\[x,y] -> x + y) (chunk 2 [0 .. 7]) |
| 2025-03-12 17:25:24 +0100 | <lambdabot> | [1,5,9,13] |
| 2025-03-12 17:25:40 +0100 | <ski> | > (zipWith (+) `ap` tail) [0 .. 7] :: [Expr] |
| 2025-03-12 17:25:41 +0100 | <lambdabot> | [0 + 1,1 + 2,2 + 3,3 + 4,4 + 5,5 + 6,6 + 7] |
| 2025-03-12 17:25:45 +0100 | <ski> | > map (\[x,y] -> x + y) (chunk 2 [0 .. 7]) :: [Expr] |
| 2025-03-12 17:25:47 +0100 | <lambdabot> | [0 + 1,2 + 3,4 + 5,6 + 7] |
| 2025-03-12 17:26:14 +0100 | <ski> | (unclear which of these two options you're doing, in a pass) |
| 2025-03-12 17:26:32 +0100 | <Inst> | second |
| 2025-03-12 17:27:18 +0100 | <ski> | mm (as i initially was supposing) |
| 2025-03-12 17:27:38 +0100 | <ski> | presumably your combining function is associative |
| 2025-03-12 17:27:53 +0100 | <Inst> | yeah it's keyed to monoid |
| 2025-03-12 17:28:15 +0100 | <Inst> | chunking function is generating mempty to fill out if it's an odd length list |
| 2025-03-12 17:30:25 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 17:31:18 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 17:32:14 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-03-12 17:33:52 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-03-12 17:34:08 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 17:35:57 +0100 | Guest4 | (~Guest4@2804:14c:3f87:8149:ce7a:9b84:f941:24de) |
| 2025-03-12 17:40:30 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-03-12 17:41:09 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-03-12 17:42:03 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 17:42:03 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52210926b325fe4262.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2025-03-12 17:44:26 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-03-12 17:47:10 +0100 | yegorc | (~yegorc@user/yegorc) (Quit: Leaving) |
| 2025-03-12 17:47:43 +0100 | Guest4 | (~Guest4@2804:14c:3f87:8149:ce7a:9b84:f941:24de) () |
| 2025-03-12 17:48:54 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-03-12 17:52:05 +0100 | lottaquestions | (~nick@2607:fa49:5040:b100:5b52:ac7b:b1b7:f59f) (Quit: Konversation terminated!) |
| 2025-03-12 17:54:42 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-48-184-145-138-167.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2025-03-12 17:57:56 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-47-184-146-98-182.dsl.bell.ca) |
| 2025-03-12 18:00:40 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:98ab:59f5:dcb3:c8fc) (Read error: Connection reset by peer) |
| 2025-03-12 18:00:54 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-03-12 18:01:41 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:98ab:59f5:dcb3:c8fc) synchromesh |
| 2025-03-12 18:02:40 +0100 | tusko | (uid478376@user/tusko) tusko |
| 2025-03-12 18:06:12 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 18:07:36 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2025-03-12 18:07:50 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:98ab:59f5:dcb3:c8fc) (Remote host closed the connection) |
| 2025-03-12 18:09:47 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52dc57c47be76b3f6a.dip0.t-ipconnect.de) |
| 2025-03-12 18:10:29 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-12 18:11:36 +0100 | prasad | (~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) |
| 2025-03-12 18:31:02 +0100 | Pablo58 | (~Pablo@200.40.229.150) |
| 2025-03-12 18:32:37 +0100 | <juri_> | I just completed building a single head attention mechanism, in haskell. |
| 2025-03-12 18:33:35 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3504-140e-55c2-d7c2-899b-0789.rev.sfr.net) (Remote host closed the connection) |
| 2025-03-12 18:33:37 +0100 | Pablo58 | (~Pablo@200.40.229.150) () |
| 2025-03-12 18:33:38 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Read error: Connection reset by peer) |
| 2025-03-12 18:34:56 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 18:34:59 +0100 | <Inst> | well, this is new |
| 2025-03-12 18:35:18 +0100 | <Inst> | i just generated 1_999_999_998 sparks, and they all dudded |
| 2025-03-12 18:35:20 +0100 | <Inst> | i should celebrate |
| 2025-03-12 18:37:01 +0100 | <Inst> | (because I'm assuming this means that GHC generated a tight inner loop from foldr, and they were all unboxed, meaning WHNF, and inability to parallelize) |
| 2025-03-12 18:37:36 +0100 | <Inst> | (ironically, when I take out the par / pseq notation, the program runs slower by a factor of 3) |
| 2025-03-12 18:47:22 +0100 | <EvanR> | that's a lot of assuming |
| 2025-03-12 18:47:28 +0100 | <EvanR> | better to actually check somehow |
| 2025-03-12 18:48:08 +0100 | <int-e> | this did not spark joy |
| 2025-03-12 18:48:34 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52dc57c47be76b3f6a.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-03-12 18:51:57 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 18:54:29 +0100 | <Inst> | nah, it's running at the same speed, or even faster; I just think it's funny GHC is telling me "you don't know how to parallelize so I'm going to optimize the code away" |
| 2025-03-12 18:54:51 +0100 | <Inst> | putting the par / pseq notation back as bang patterns instead, it's running at the same speed without engaging the spark system |
| 2025-03-12 18:56:13 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
| 2025-03-12 19:01:52 +0100 | ft | (~ft@p508db291.dip0.t-ipconnect.de) ft |
| 2025-03-12 19:02:02 +0100 | michalz | (~michalz@185.246.207.221) (Ping timeout: 244 seconds) |
| 2025-03-12 19:06:43 +0100 | <Square2> | If you were to replicate a Haskell domain model in java (for JSON RPC purposes), when you control both client and server. And it's exploratory development, what approach would you take? |
| 2025-03-12 19:07:17 +0100 | <Square2> | I tried OpenApi but it seems to create as much problems as it solves. |
| 2025-03-12 19:07:51 +0100 | k_hachig_ | (~k_hachig@2607:fea8:351d:ef0:a56d:37e8:f63c:429c) k_hachig |
| 2025-03-12 19:07:57 +0100 | <Square2> | Also very work heavy to configure the schema part of it |
| 2025-03-12 19:07:59 +0100 | k_hachig_ | k_hachig |
| 2025-03-12 19:10:12 +0100 | michalz | (~michalz@185.246.207.205) |
| 2025-03-12 19:21:18 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:b341:438:8f09:aa92) (Remote host closed the connection) |
| 2025-03-12 19:39:01 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 19:39:25 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:e1d3:88d5:3ff2:2f10) (Quit: No Ping reply in 180 seconds.) |
| 2025-03-12 19:40:10 +0100 | jespada | (~jespada@2800:a4:22b4:9a00:f994:da25:97cf:4452) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-12 19:40:40 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:14e6:e5d:241a:b56c) fun-safe-math |
| 2025-03-12 19:43:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-12 19:47:30 +0100 | <tomsmeding> | juri_: in case you wrote it to be fast: what array library did you use? |
| 2025-03-12 19:53:39 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-12 19:55:22 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f52eca5d8b1f7f6f1d4.dip0.t-ipconnect.de) acidjnk |
| 2025-03-12 19:55:51 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2025-03-12 20:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-12 20:00:46 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-12 20:04:14 +0100 | jespada | (~jespada@2800:a4:22b4:9a00:f994:da25:97cf:4452) jespada |
| 2025-03-12 20:10:16 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2025-03-12 20:10:41 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:91e8:307c:455b:5f65) (Read error: Connection reset by peer) |
| 2025-03-12 20:12:09 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-12 20:14:34 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-03-12 20:16:09 +0100 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-12 20:16:26 +0100 | weary-traveler | (~user@user/user363627) (Ping timeout: 244 seconds) |
| 2025-03-12 20:20:23 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 20:20:30 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-03-12 20:22:24 +0100 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-03-12 20:25:06 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 20:29:27 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-03-12 20:37:49 +0100 | <Inst> | this is annoying, (+1) 2 isn't in WHNF, right? |
| 2025-03-12 20:39:32 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-03-12 20:43:49 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 248 seconds) |
| 2025-03-12 20:44:34 +0100 | <EvanR> | WHNFs aren't applications |
| 2025-03-12 20:44:41 +0100 | <EvanR> | that's an application |
| 2025-03-12 20:45:01 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-03-12 20:48:04 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 21:00:00 +0100 | hiecaq | (~hiecaq@user/hiecaq) (ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.0.92)) |
| 2025-03-12 21:04:37 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-03-12 21:07:21 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-03-12 21:07:35 +0100 | <c_wraith> | whnf doesn't reduce under a lambda, though, so (\_ -> 1 + 2) is in WHNF |
| 2025-03-12 21:07:35 +0100 | a_fantom | (~fantom@2.219.56.221) (Ping timeout: 244 seconds) |
| 2025-03-12 21:07:55 +0100 | <c_wraith> | IIRC, that's the main difference from HNF |
| 2025-03-12 21:08:43 +0100 | <tomsmeding> | I get WHNF and NF, but is HNF useful for anything? |
| 2025-03-12 21:08:53 +0100 | <EvanR> | so lambda is WHNF, regardless of what's in it |
| 2025-03-12 21:09:32 +0100 | <tomsmeding> | EvanR: it makes sense if you consider a lambda to be the "constructor" of the (->) type |
| 2025-03-12 21:11:30 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 21:11:55 +0100 | <c_wraith> | tomsmeding: HNF seems related to like... compiler optimizations. Find reducible expressions anywhere in the graph and reduce them at compile time, for instance. |
| 2025-03-12 21:12:18 +0100 | <tomsmeding> | c_wraith: but then why would it not reduce _all_ redexes? |
| 2025-03-12 21:12:21 +0100 | <c_wraith> | That's not quite the same, but the idea is related |
| 2025-03-12 21:12:28 +0100 | <tomsmeding> | only the one at the left seems awfully arbitrary |
| 2025-03-12 21:12:59 +0100 | <c_wraith> | I think it mostly makes for a really nice exercise to say "implement this optimization" |
| 2025-03-12 21:13:04 +0100 | <tomsmeding> | surely if I write 'Just (1 + 2)', a compiler should optimise that to Just 3? But as far as I understand, 'Just (1 + 2)' is in HNF |
| 2025-03-12 21:13:06 +0100 | <c_wraith> | so textbooks include it |
| 2025-03-12 21:13:10 +0100 | <tomsmeding> | heh |
| 2025-03-12 21:15:06 +0100 | <EvanR> | though Just (1 + 2) in isolation can't be simplified |
| 2025-03-12 21:15:11 +0100 | <EvanR> | in haskell |
| 2025-03-12 21:15:20 +0100 | tomsmeding | grumbles |
| 2025-03-12 21:15:24 +0100 | <tomsmeding> | 'Just (1 + 2 :: Int)' then |
| 2025-03-12 21:15:39 +0100 | <EvanR> | wouldn't that be nice |
| 2025-03-12 21:15:41 +0100 | <c_wraith> | or even Integer, for the really bold |
| 2025-03-12 21:15:51 +0100 | <int-e> | A pure lambda term is solvable iff it has a HNF. |
| 2025-03-12 21:15:51 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-12 21:16:03 +0100 | <int-e> | So there's some theoretical interest in HNFs. |
| 2025-03-12 21:16:11 +0100 | <c_wraith> | ah, I see. |
| 2025-03-12 21:17:30 +0100 | tomsmeding | had to look up "solvable" |
| 2025-03-12 21:17:44 +0100 | <tomsmeding> | I have never had to use something like that yet. :) |
| 2025-03-12 21:18:03 +0100 | <EvanR> | I don't see why my DOOM implementation in haskell doesn't just run at compile time! This long time joke apparently has become real in typescript recently |
| 2025-03-12 21:18:33 +0100 | <EvanR> | typescript... whose type system isn't particularly turing complete aiui |
| 2025-03-12 21:20:02 +0100 | <Inst> | iirc WHNF = constructor or partially applied lambda. What's in WHNF but not NF (unless it's been evaluated prior) is constructors holding unevaluated data afaik, right? |
| 2025-03-12 21:20:24 +0100 | <tomsmeding> | Inst: what do you mean with "partially applied lambda"? |
| 2025-03-12 21:20:36 +0100 | <tomsmeding> | `(\x y -> x + y) 2` is not WHNF |
| 2025-03-12 21:21:49 +0100 | <EvanR> | application is not WHNF |
| 2025-03-12 21:21:58 +0100 | <EvanR> | whatever is involved |
| 2025-03-12 21:22:49 +0100 | <tomsmeding> | if you see the lambda calculus as having just single-argument lambda functions (i.e. `\x y -> E` is sugar for `\x -> \y -> E`), then WHNF is "it's a constructor or a lambda" |
| 2025-03-12 21:23:09 +0100 | <tomsmeding> | and as I said, if you see lambda as the "constructor" of the function type, then it's just "it's a constructor" |
| 2025-03-12 21:23:23 +0100 | <EvanR> | it's constructors all the way down |
| 2025-03-12 21:23:34 +0100 | <tomsmeding> | you're not wrong |
| 2025-03-12 21:25:50 +0100 | <Inst> | but (\y -> 2 + y) is WHNF |
| 2025-03-12 21:26:01 +0100 | <tomsmeding> | yes, because it's a lambda |
| 2025-03-12 21:26:14 +0100 | <Inst> | yeah, partially applied lambda was confusing |
| 2025-03-12 21:26:35 +0100 | <tomsmeding> | if you add multi-argument lambdas to your language, the definition of WHNF gets a bit more intricate |
| 2025-03-12 21:26:43 +0100 | izzyfalco | (~jake_pers@user/izzyfalco) izzyfalco |
| 2025-03-12 21:26:46 +0100 | <tomsmeding> | with only single-argument lambdas, it's very straightforward |
| 2025-03-12 21:27:33 +0100 | <Inst> | by the way, are there any good parallelization exercises for working with the spark parallelism system? |
| 2025-03-12 21:28:27 +0100 | <Inst> | I'm sort of getting tired of trying to implement parFold, it's fun when I see huge improvements (moved from 80 seconds to 0.7 seconds), but ultimately it's not going to ever really be useful |
| 2025-03-12 21:31:19 +0100 | <Inst> | it's funny in a way, Chalmers starts their intro programming with Haskell in IO |
| 2025-03-12 21:34:02 +0100 | <Inst> | actually, no, I thought Columbia had a course wherein they taught you par and rpar before they taught you recursion, but it's only titled that way and it's a normal haskell course :( |
| 2025-03-12 21:34:11 +0100 | <Inst> | https://www.cs.columbia.edu/~sedwards/classes/2023/4995-fall/index.html |
| 2025-03-12 21:36:40 +0100 | sdrfan123 | (~sdrfan123@2607:fb90:ad22:c6ba:1965:cecd:386e:8114) |
| 2025-03-12 21:37:15 +0100 | jespada | (~jespada@2800:a4:22b4:9a00:f994:da25:97cf:4452) (Ping timeout: 244 seconds) |
| 2025-03-12 21:38:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 21:41:39 +0100 | jespada | (~jespada@r190-135-78-231.dialup.adsl.anteldata.net.uy) jespada |
| 2025-03-12 21:46:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-03-12 21:47:40 +0100 | <Noinia> | hmm, does anyone know how to coerce 'Folds' from the lens package? I.e. I'm trying to implement a function 'test :: forall s s' a. Coercible s s' => Fold s a -> Fold s' a. I can write test myFold = \f -> contramap coerce . myFold f . coerce. But the 'contramap coerce' is bothering me; that does not necessarily seem zero-cost. Any way around that? |
| 2025-03-12 21:52:52 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-12 21:56:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 21:59:11 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-03-12 21:59:35 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 21:59:42 +0100 | izzyfalco | (~jake_pers@user/izzyfalco) (Ping timeout: 252 seconds) |
| 2025-03-12 22:00:57 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 22:01:14 +0100 | tabaqui | (~root@167.71.80.236) (Client Quit) |
| 2025-03-12 22:01:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-03-12 22:01:47 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 22:02:04 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds) |
| 2025-03-12 22:02:04 +0100 | ljdarj1 | ljdarj |
| 2025-03-12 22:02:10 +0100 | tabaqui | (~root@167.71.80.236) (Client Quit) |
| 2025-03-12 22:03:35 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 22:03:45 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
| 2025-03-12 22:04:24 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 22:05:30 +0100 | tabaqui | (~root@167.71.80.236) (Client Quit) |
| 2025-03-12 22:07:10 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 22:08:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:09:39 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2025-03-12 22:12:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 22:17:39 +0100 | tabaqui | (~root@167.71.80.236) (Quit: WeeChat 4.5.1) |
| 2025-03-12 22:22:25 +0100 | tusko | (uid478376@user/tusko) (Quit: Connection closed for inactivity) |
| 2025-03-12 22:23:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:26:55 +0100 | cheater_ | (~Username@user/cheater) cheater |
| 2025-03-12 22:27:22 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 244 seconds) |
| 2025-03-12 22:27:31 +0100 | cheater_ | cheater |
| 2025-03-12 22:28:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 22:30:16 +0100 | jespada | (~jespada@r190-135-78-231.dialup.adsl.anteldata.net.uy) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-12 22:37:42 +0100 | sdrfan123 | (~sdrfan123@2607:fb90:ad22:c6ba:1965:cecd:386e:8114) (Quit: Client closed) |
| 2025-03-12 22:39:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:43:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 22:45:38 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 22:47:34 +0100 | fantom | (~fantom@2.219.56.221) |
| 2025-03-12 22:48:23 +0100 | tusko | (uid478376@user/tusko) tusko |
| 2025-03-12 22:49:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-12 22:51:33 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-03-12 22:51:56 +0100 | xkuru | (~xkuru@user/xkuru) xkuru |
| 2025-03-12 22:53:52 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 22:54:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:57:00 +0100 | <Inst> | c_wraith: thanks for the warning, I finally understand why lists are so hard to parallelize. They're effectively a one-channel stream, so i need a long computation to spark and parallelize the next computation before the first computation finishes, and even then, I'll have problems with blackholing / blocking, as you've said. |
| 2025-03-12 22:58:16 +0100 | <EvanR> | there are a few conal videos where he wants to do parallel computation (eventually, in hardware) and he rejects linked list in favor of array (of size power of 2) |
| 2025-03-12 22:59:03 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-12 22:59:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 23:00:17 +0100 | <juri_> | FWIW, repa seems to be useful for these things. |
| 2025-03-12 23:01:14 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 23:01:54 +0100 | <juri_> | they use Vector internally, but wrap that in an interesting interface. |
| 2025-03-12 23:02:39 +0100 | sdrfan123 | (~sdrfan123@2607:fb90:ad22:c6ba:1965:cecd:386e:8114) |
| 2025-03-12 23:03:02 +0100 | <EvanR> | I guess IRL you would also want to align your power of 2 size array/vector with the cache lines |
| 2025-03-12 23:03:38 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection) |
| 2025-03-12 23:03:39 +0100 | <juri_> | oh, it's much more complicated than that. :) |
| 2025-03-12 23:04:11 +0100 | <EvanR> | :( |
| 2025-03-12 23:04:14 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 23:05:45 +0100 | <juri_> | the real problem is: modern computers have an architecture that looks uniform from one angle, but if you get out a stopwatch... has layers of caches, dumb rules, and in order to get real performance, you need to almost hand compile, and back, just so you get your units-of-work in the right sizes for all of the different cache subsystems. |
| 2025-03-12 23:06:22 +0100 | <juri_> | (source: I write ~AVX512 assembly by hand, to make LLMs go faster) |
| 2025-03-12 23:06:40 +0100 | Square | (~Square@user/square) Square |
| 2025-03-12 23:07:46 +0100 | <Inst> | i'm just doing exercises, i have a strong feeling and others have suggested what i'm trying to do is dumb |
| 2025-03-12 23:08:20 +0100 | <Inst> | but honestly, tbh, the vision in my head of this tree lazily being populated outwards from the bottom left corner is beautiful |
| 2025-03-12 23:09:06 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-03-12 23:09:33 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 245 seconds) |
| 2025-03-12 23:09:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 23:10:18 +0100 | <EvanR> | is it populating an actual data structure before doing anything else |
| 2025-03-12 23:10:48 +0100 | <EvanR> | because you get better laziness by having a plan lined for consuming the tree |
| 2025-03-12 23:10:52 +0100 | <EvanR> | lined up |
| 2025-03-12 23:11:07 +0100 | <EvanR> | one which lets you forget parts you don't need anymore, before the whole tree is created |
| 2025-03-12 23:12:32 +0100 | <Inst> | it's doing it simultaneously |
| 2025-03-12 23:14:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 23:15:38 +0100 | michalz | (~michalz@185.246.207.205) (Remote host closed the connection) |
| 2025-03-12 23:18:13 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-12 23:25:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 23:26:03 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 244 seconds) |
| 2025-03-12 23:27:13 +0100 | dibblego | (~dibblego@116-255-1-119.ip4.superloop.au) |
| 2025-03-12 23:27:14 +0100 | dibblego | (~dibblego@116-255-1-119.ip4.superloop.au) (Changing host) |
| 2025-03-12 23:27:14 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2025-03-12 23:27:29 +0100 | sdrfan123 | (~sdrfan123@2607:fb90:ad22:c6ba:1965:cecd:386e:8114) (Quit: Client closed) |
| 2025-03-12 23:30:19 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-03-12 23:31:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 23:31:53 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 23:31:59 +0100 | tabaqui | (~root@167.71.80.236) (Client Quit) |
| 2025-03-12 23:32:02 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 23:32:19 +0100 | tabaqui | (~root@167.71.80.236) tabaqui |
| 2025-03-12 23:33:48 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 23:34:55 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2025-03-12 23:36:23 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-12 23:40:54 +0100 | <EvanR> | juri_, are there any debuggers or simulators that can help with that? |
| 2025-03-12 23:41:07 +0100 | <EvanR> | or is it like, write code, try it, see if it's faster |
| 2025-03-12 23:41:20 +0100 | <EvanR> | and guess at why or why not |
| 2025-03-12 23:43:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 23:46:02 +0100 | catties | Catty |
| 2025-03-12 23:47:51 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |