2025-09-11 00:00:09 +0200 | <biberao> | sm i dont? |
2025-09-11 00:00:13 +0200 | <biberao> | to install ghcup» |
2025-09-11 00:00:15 +0200 | <biberao> | ? |
2025-09-11 00:00:20 +0200 | <biberao> | i was advise to do that |
2025-09-11 00:00:30 +0200 | <biberao> | how do i now use ghcup with vscode? |
2025-09-11 00:00:43 +0200 | <biberao> | do i need to install vscode on wsl? |
2025-09-11 00:02:57 +0200 | <haskellbridge> | <sm> ah yes, it looks like you maybe do need wsl to make ghcup run on windows. I would just use stack personally. |
2025-09-11 00:03:29 +0200 | <haskellbridge> | <sm> I'm pretty sure vscode does not require wsl. ghcup is the only tool that needs it. |
2025-09-11 00:03:57 +0200 | <geekosaur> | uh? ghcup was fixed for windows some time back, including `ghcup tui`. it even has a PowerShell invocation to download and run it initially |
2025-09-11 00:04:18 +0200 | <haskellbridge> | <sm> that's what I thought too. I'm just looking at the options at https://www.haskell.org/ghcup/# |
2025-09-11 00:04:38 +0200 | <geekosaur> | Click "show all platforms" |
2025-09-11 00:04:39 +0200 | <biberao> | oh so i dont need wsl then? |
2025-09-11 00:04:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-09-11 00:04:50 +0200 | <haskellbridge> | <sm> ah, you have to click Show all platforms. page needs an update maybe, maerwald |
2025-09-11 00:05:17 +0200 | <biberao> | so ill remove wsl |
2025-09-11 00:05:43 +0200 | <biberao> | i dont see that |
2025-09-11 00:05:48 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Quit: ljdarj) |
2025-09-11 00:05:48 +0200 | jreicher | (~user@user/jreicher) jreicher |
2025-09-11 00:05:49 +0200 | <biberao> | show all platforms |
2025-09-11 00:06:21 +0200 | <biberao> | can you link please? |
2025-09-11 00:07:09 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-09-11 00:07:36 +0200 | <biberao> | do i need to install msys2? |
2025-09-11 00:07:43 +0200 | <haskellbridge> | <sm> https://kf8nh.com/_heisenbridge/media/matrix.org/iLBLcdfMQQpypjSGmPcQVjqa/tTWuaB_EmLU/Screenshot%2… |
2025-09-11 00:08:06 +0200 | <geekosaur> | it's in small text (and hard to see against the background) right under the Linux/POSIX/WSL2 instruction box |
2025-09-11 00:08:40 +0200 | <haskellbridge> | <sm> biberao maybe.. what makes you ask that ? |
2025-09-11 00:09:07 +0200 | <biberao> | i was asking the place |
2025-09-11 00:09:28 +0200 | <geekosaur> | ghc installs msys2 itself since it needs a specific non-default msys2 toolchain |
2025-09-11 00:10:06 +0200 | <biberao> | s i do the curl and then do that command? |
2025-09-11 00:10:36 +0200 | <geekosaur> | if you're using the windows instructions there should be a PowerShell invocation |
2025-09-11 00:10:40 +0200 | <biberao> | ok |
2025-09-11 00:10:42 +0200 | <biberao> | thanks |
2025-09-11 00:10:46 +0200 | <geekosaur> | you won't have curl unless you are using wsl2 |
2025-09-11 00:10:54 +0200 | <biberao> | oh i didnt see the url embedded sorry |
2025-09-11 00:11:03 +0200 | <biberao> | thank you |
2025-09-11 00:11:05 +0200 | <biberao> | ! |
2025-09-11 00:11:10 +0200 | <biberao> | ill remove wsl2 i dont need ikt |
2025-09-11 00:12:03 +0200 | <biberao> | thank you very much |
2025-09-11 00:12:17 +0200 | <haskellbridge> | <sm> no problem |
2025-09-11 00:15:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 00:16:02 +0200 | Taneb | (~Taneb@ip87-106-35-210.pbiaas.com) (Ping timeout: 260 seconds) |
2025-09-11 00:20:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
2025-09-11 00:26:40 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
2025-09-11 00:31:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 00:36:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
2025-09-11 00:37:44 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 248 seconds) |
2025-09-11 00:45:17 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 250 seconds) |
2025-09-11 00:45:41 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 00:47:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 00:49:24 +0200 | trickard_ | trickard |
2025-09-11 00:50:40 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
2025-09-11 00:52:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-09-11 00:53:44 +0200 | <monochrom> | Belated: I will design a CPU such that every program is "one" instruction. >:) (Related: a library, called Tweeter, that contains every function implementable in 150 bytes or less.) |
2025-09-11 00:54:11 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-11 00:54:26 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
2025-09-11 00:58:41 +0200 | <arahael> | Big library! |
2025-09-11 01:03:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 01:03:52 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 01:04:23 +0200 | davidlbowman | (~dlb@user/davidlbowman) (Quit: WeeChat 4.1.1) |
2025-09-11 01:05:14 +0200 | EvanR | (~EvanR@user/evanr) (Ping timeout: 256 seconds) |
2025-09-11 01:05:27 +0200 | biberao | (~m@user/biberao) (Quit: WeeChat 3.8) |
2025-09-11 01:05:51 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-11 01:06:06 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
2025-09-11 01:06:37 +0200 | <monochrom> | It answers the kind of questions like "I'm defining foo f g h x y = f (g x) (h x y), why isn't it in Prelude already!" |
2025-09-11 01:09:27 +0200 | itaipu | (~itaipu@168.121.97.28) (Ping timeout: 258 seconds) |
2025-09-11 01:10:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 01:11:14 +0200 | acidjnk | (~acidjnk@p200300d6e7171978f1deda3d99afd1a1.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
2025-09-11 01:13:35 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Quit: ljdarj) |
2025-09-11 01:14:55 +0200 | itaipu | (~itaipu@168.121.97.28) itaipu |
2025-09-11 01:17:52 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
2025-09-11 01:21:35 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 01:22:10 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
2025-09-11 01:22:14 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Ping timeout: 256 seconds) |
2025-09-11 01:23:09 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 01:26:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 01:27:03 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 01:28:07 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
2025-09-11 01:28:16 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
2025-09-11 01:28:17 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
2025-09-11 01:32:10 +0200 | karenw | (~karenw@user/karenw) karenw |
2025-09-11 01:33:08 +0200 | sprotte24 | (~sprotte24@p5b039f5e.dip0.t-ipconnect.de) (Quit: Leaving) |
2025-09-11 01:37:23 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 01:40:38 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-11 01:40:39 +0200 | Googulator61 | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
2025-09-11 01:42:00 +0200 | pabs3 | (~pabs3@user/pabs3) (Read error: Connection reset by peer) |
2025-09-11 01:42:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-09-11 01:43:18 +0200 | pabs3 | (~pabs3@user/pabs3) pabs3 |
2025-09-11 01:46:15 +0200 | itaipu | (~itaipu@168.121.97.28) (Ping timeout: 258 seconds) |
2025-09-11 01:47:20 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2025-09-11 01:47:23 +0200 | acidjnk | (~acidjnk@p200300d6e717192649d3cadc2eaa05e5.dip0.t-ipconnect.de) acidjnk |
2025-09-11 01:53:10 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 01:58:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-09-11 02:01:06 +0200 | mikess | (~sam@user/mikess) mikess |
2025-09-11 02:02:14 +0200 | acidjnk | (~acidjnk@p200300d6e717192649d3cadc2eaa05e5.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
2025-09-11 02:03:19 +0200 | itaipu | (~itaipu@168.121.97.28) itaipu |
2025-09-11 02:04:57 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 02:05:04 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 02:08:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 02:10:39 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
2025-09-11 02:14:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 02:15:16 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
2025-09-11 02:21:10 +0200 | otto_s | (~user@p5b0442fa.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
2025-09-11 02:22:49 +0200 | otto_s | (~user@p5de2f433.dip0.t-ipconnect.de) |
2025-09-11 02:24:18 +0200 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) robobub |
2025-09-11 02:24:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 02:31:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
2025-09-11 02:31:42 +0200 | mange | (~mange@user/mange) mange |
2025-09-11 02:35:25 +0200 | karenw_ | (~karenw@user/karenw) karenw |
2025-09-11 02:36:19 +0200 | Axma39609 | Axman6 |
2025-09-11 02:37:43 +0200 | karenw | (~karenw@user/karenw) (Ping timeout: 265 seconds) |
2025-09-11 02:38:54 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) szkl |
2025-09-11 02:40:37 +0200 | xff0x | (~xff0x@2405:6580:b080:900:c68c:683e:9c65:6f0a) (Ping timeout: 265 seconds) |
2025-09-11 02:41:27 +0200 | mikess | (~sam@user/mikess) (Ping timeout: 258 seconds) |
2025-09-11 02:46:03 +0200 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
2025-09-11 02:57:07 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 02:58:17 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
2025-09-11 03:13:01 +0200 | jmcantrell_ | (~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1) |
2025-09-11 03:18:38 +0200 | vetkat | (~vetkat@user/vetkat) (Ping timeout: 258 seconds) |
2025-09-11 03:19:22 +0200 | vetkat | (~vetkat@user/vetkat) vetkat |
2025-09-11 03:22:25 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 03:34:15 +0200 | EvanR | (~EvanR@user/evanr) EvanR |
2025-09-11 03:40:22 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
2025-09-11 03:42:03 +0200 | <L29Ah> | https://bpa.st/RAGA how can this sad state of affairs be helped, except perhaps putting every record type in its own module? |
2025-09-11 03:56:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 03:59:27 +0200 | karenw_ | (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
2025-09-11 04:00:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 04:02:38 +0200 | <pavonia> | Wasn't there an extension for that purpose? |
2025-09-11 04:03:00 +0200 | <jackdk> | Try enabling `{-# LANGUAGE DisambiguateRecordFields #-}` |
2025-09-11 04:03:26 +0200 | <pavonia> | Yeah https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/disambiguate_record_fields.html |
2025-09-11 04:07:21 +0200 | <L29Ah> | jackdk: i did |
2025-09-11 04:07:33 +0200 | <L29Ah> | this is the result |
2025-09-11 04:07:45 +0200 | <jackdk> | It might be `DuplicateRecordFields` that you need |
2025-09-11 04:07:49 +0200 | <L29Ah> | jackdk: i did |
2025-09-11 04:08:28 +0200 | <pavonia> | The ambiguity cannot be resolved in all cases, adding type annotations should help in those cases |
2025-09-11 04:08:31 +0200 | <L29Ah> | apparently it can't do anything when it doesn't see the constructor right at the record mutation |
2025-09-11 04:08:31 +0200 | <jackdk> | Then, respectfully, why did you not open with this information? |
2025-09-11 04:08:40 +0200 | <L29Ah> | i added the type annotation as you can see |
2025-09-11 04:08:59 +0200 | <Leary> | I don't believe there's any extension that allows this out-of-the-box. Technically, I think you can do it with OverloadedRecordUpdate and some boilerplate, but I wouldn't say it's better than the alternative. |
2025-09-11 04:09:02 +0200 | <L29Ah> | jackdk: because i thought it is obvious |
2025-09-11 04:09:41 +0200 | <L29Ah> | Leary: the current boilerplate is crazy and seems like it will go on like that for a while -- https://gitlab.haskell.org/ghc/ghc/-/issues/16232 |
2025-09-11 04:09:58 +0200 | <jackdk> | I just noticed the record update is applied to the `def` and then you do the type application. You may have luck with `def @LlamaRequest` because then GHC may figure out the type of the record being updated |
2025-09-11 04:10:41 +0200 | <glguy> | that isn't enough (I tried earlier) |
2025-09-11 04:11:31 +0200 | <glguy> | in the case the work around is to use the named default value for that type and avoid def |
2025-09-11 04:11:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 04:13:17 +0200 | <L29Ah> | glguy: named default value doesn't seem to change anything |
2025-09-11 04:13:34 +0200 | <L29Ah> | deff :: LlamaRequest |
2025-09-11 04:13:34 +0200 | <L29Ah> | defined at the top level, that is |
2025-09-11 04:14:03 +0200 | <glguy> | Oh, I forgot which issue you were running into. sorry. your original separate module solution seems best if you have to use duplicate record fields |
2025-09-11 04:15:19 +0200 | <L29Ah> | i don't strictly have to but aeson's generics work the best without mangling the field names |
2025-09-11 04:16:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 04:17:25 +0200 | <jackdk> | L29Ah: GHC 9.8.4 accepts this code but warns that type-directed record updates will be eventually deprecated and removed. The key difference is using a type annotation on `def` instead of a type application (either before or after the record update) https://www.irccloud.com/pastebin/kc8TPwKu/Encode.hs |
2025-09-11 04:18:41 +0200 | <L29Ah> | jackdk: it is already removed in 9.12 IIRC |
2025-09-11 04:18:49 +0200 | <glguy> | that file loads in 9.12 |
2025-09-11 04:19:22 +0200 | <L29Ah> | nvm thanks |
2025-09-11 04:19:31 +0200 | <glguy> | but it doesn't seem great to rely on it sticking around in any case |
2025-09-11 04:20:41 +0200 | <L29Ah> | i have a gut feeling that it won't be purged before 16232 gets in |
2025-09-11 04:22:22 +0200 | <L29Ah> | https://gitlab.haskell.org/ghc/ghc/-/issues/25075#note_576241 |
2025-09-11 04:23:55 +0200 | <L29Ah> | https://github.com/ghc-proposals/ghc-proposals/pull/366 me pushe dislike so very hard!! |
2025-09-11 04:23:59 +0200 | <jackdk> | https://github.com/ghc-proposals/ghc-proposals/pull/537#issuecomment-1327646670 there is an open proposal around having some form of type-signature-directed record updates stick around |
2025-09-11 04:26:00 +0200 | <jackdk> | Remark: I generally recommend against using `class Default` because it's got no laws, and so it's very difficult to write a function that usefully generalises over `Default` instances, which to me is one of the two main points of having a typeclass (the other being to have GHC build a function in a type-directed manner, which also doesn't apply here). |
2025-09-11 04:26:54 +0200 | <jackdk> | I tend to use generic-lens or generic-optics to do record updates unless I'm building a library where I need to not blow out the dependency footprint, which can look pretty nice with OverloadedLabels |
2025-09-11 04:27:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 04:32:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
2025-09-11 04:33:52 +0200 | <geekosaur> | Default can also bite you with unexpected types having Default instances |
2025-09-11 04:34:06 +0200 | <geekosaur> | xmonad has already had a bug caused by it |
2025-09-11 04:36:37 +0200 | <L29Ah> | could be argued about Monoid/mempty likewise |
2025-09-11 04:37:11 +0200 | <L29Ah> | i try not to forget toplevel function signatures and decomposition to help with that |
2025-09-11 04:38:57 +0200 | <jackdk> | Hard disagree re: Monoid because `mempty` has sensible behavior because of the laws that describe its interactions with `(<>)` |
2025-09-11 04:39:15 +0200 | <geekosaur> | ^ |
2025-09-11 04:39:38 +0200 | <geekosaur> | Default just does whatever whoever added the instance wanted… but defaults depend on context |
2025-09-11 04:40:06 +0200 | <geekosaur> | like, arguments could be made that the Default instance for Int should be 1 (think the addition vs. multiplication divide) |
2025-09-11 04:40:28 +0200 | <monochrom> | I just cite the PHP example. Call it a strawman or anecdotal or whatever. There is a time type in PHP, then someone decreed that it has a default value and it is 0. Fortunately, someone else has the sanity to point out what's wrong with it. |
2025-09-11 04:40:34 +0200 | <L29Ah> | oh Int has Default, great |
2025-09-11 04:41:06 +0200 | <jackdk> | https://hackage.haskell.org/package/acme-default has much better instances |
2025-09-11 04:41:11 +0200 | <geekosaur> | (->) e has a default |
2025-09-11 04:41:20 +0200 | <geekosaur> | (which is what bit us) |
2025-09-11 04:41:43 +0200 | <geekosaur> | _lots_ of things have defaults. are they useful in all cases? not a chance |
2025-09-11 04:43:02 +0200 | <monochrom> | I am OK with Default as long as you don't inflict your personalized idea of "default Int" on me. |
2025-09-11 04:43:27 +0200 | <monochrom> | But then that's just another way to say that I accept Monoid not Default. |
2025-09-11 04:43:30 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 04:44:00 +0200 | <monochrom> | (Int, (+)) has a default. (Int, (*)) has a default. There are others. Int alone has no default. |
2025-09-11 04:44:01 +0200 | <geekosaur> | there's no way to not inflict a personalized idea if it's a typeclass |
2025-09-11 04:44:51 +0200 | <geekosaur> | the typeclass police should arrest Default |
2025-09-11 04:45:28 +0200 | <mauke> | (->) e had a default |
2025-09-11 04:46:26 +0200 | <monochrom> | Actually, isn't (->)e the wrong kind for Default? |
2025-09-11 04:46:53 +0200 | <mauke> | implied (Default a) => Default ((->) e a) |
2025-09-11 04:47:00 +0200 | <monochrom> | Oh, that. |
2025-09-11 04:47:03 +0200 | <dibblego> | every time I look at Default, it is worse than my imagination approximates, but I assume it is ((->) e e) |
2025-09-11 04:47:09 +0200 | <dibblego> | oh |
2025-09-11 04:47:39 +0200 | <monochrom> | Hey at least it's palatable to math "pointwise extension" :) |
2025-09-11 04:48:00 +0200 | <geekosaur> | hint: const |
2025-09-11 04:48:00 +0200 | <dibblego> | :) |
2025-09-11 04:48:27 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-09-11 04:48:27 +0200 | <jackdk> | monochrom: I think "(Int, (+)) has a default" muddies the waters. I would say "(Int, (+)) has an identity element" or "... a neutral element" |
2025-09-11 04:48:57 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
2025-09-11 04:49:01 +0200 | <mauke> | because what I really wanted was (Default a, Applicative f) => Default (f a), but that's not legal |
2025-09-11 04:49:08 +0200 | <geekosaur> | I took the point as "that's a better notion of "default" than Default is |
2025-09-11 04:49:10 +0200 | <geekosaur> | " |
2025-09-11 04:49:11 +0200 | <monochrom> | I want to muddle the water so much it wraps around and clarifies to "why not do it properly and make a Monoid". |
2025-09-11 04:49:27 +0200 | <jackdk> | OK |
2025-09-11 04:50:24 +0200 | <monochrom> | Alternatively or equivalently I want to hijack the "plain English" word "default" and re-define it to be monoid identity. |
2025-09-11 04:51:40 +0200 | <mauke> | anyway, the controversial (e -> a) and (IO a) instances have been removed |
2025-09-11 04:51:52 +0200 | <mauke> | and the controversial Bool instance added |
2025-09-11 04:52:00 +0200 | <dibblego> | alternatively, s/Default/Hyperfault |
2025-09-11 04:52:17 +0200 | <geekosaur> | how about just "Fault" |
2025-09-11 04:52:53 +0200 | <monochrom> | I thought people knew better than a default Bool. |
2025-09-11 04:53:08 +0200 | <monochrom> | You have like 50% chance of being wrong. |
2025-09-11 04:53:13 +0200 | <mauke> | I do, but it was a user request |
2025-09-11 04:53:44 +0200 | <monochrom> | But OK, there is a selection bias. The Default library is doomed to attract a certain kind of people... |
2025-09-11 04:54:01 +0200 | <mauke> | by Neil Mitchell, possibly? |
2025-09-11 04:59:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 05:05:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-09-11 05:10:38 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
2025-09-11 05:17:07 +0200 | aforemny_ | (~aforemny@i59F4C711.versanet.de) aforemny |
2025-09-11 05:17:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 05:17:24 +0200 | aforemny | (~aforemny@i59F4C7D6.versanet.de) (Ping timeout: 256 seconds) |
2025-09-11 05:22:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-09-11 05:33:06 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 05:38:22 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 05:48:11 +0200 | Googulator61 | Googulator |
2025-09-11 05:48:53 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 05:49:30 +0200 | <probie> | monochrom: the default Bool should be `False`. I flipped a coin and that was the result (also, just having false and implication gives us everything in classical logic, so maybe it is a slightly better choice than true) |
2025-09-11 05:52:26 +0200 | Square2 | (~Square@user/square) Square |
2025-09-11 05:52:30 +0200 | <L29Ah> | i did an anonymous mmap and that was the result of unsafeCoerce |
2025-09-11 05:53:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 05:56:34 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
2025-09-11 06:04:46 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 06:10:52 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
2025-09-11 06:11:29 +0200 | <monochrom> | probie: That is just not true. (pun! don't take it seriously >:) ) |
2025-09-11 06:12:03 +0200 | hjj123 | (~hjj123@178.155.115.231) |
2025-09-11 06:13:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
2025-09-11 06:23:40 +0200 | hjj123 | (~hjj123@178.155.115.231) (Quit: Client closed) |
2025-09-11 06:24:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 06:26:14 +0200 | trickard | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-11 06:26:27 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 06:29:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
2025-09-11 06:30:42 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz |
2025-09-11 06:33:45 +0200 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 258 seconds) |
2025-09-11 06:34:59 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
2025-09-11 06:39:27 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-11 06:39:40 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 06:40:11 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 06:42:26 +0200 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
2025-09-11 06:45:39 +0200 | michalz | (~michalz@185.246.207.201) |
2025-09-11 06:46:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 06:58:12 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 07:03:34 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-09-11 07:11:43 +0200 | mulk | (~mulk@p5b2dc694.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
2025-09-11 07:13:06 +0200 | mulk | (~mulk@pd95144c3.dip0.t-ipconnect.de) mulk |
2025-09-11 07:14:01 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz |
2025-09-11 07:14:05 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 07:18:36 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
2025-09-11 07:18:59 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
2025-09-11 07:19:08 +0200 | karenw_ | (~karenw@user/karenw) karenw |
2025-09-11 07:21:09 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-11 07:21:23 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 07:29:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 07:34:42 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
2025-09-11 07:37:28 +0200 | Pixi | (~Pixi@user/pixi) (Ping timeout: 248 seconds) |
2025-09-11 07:45:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 07:46:43 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 07:47:24 +0200 | Sgeo_ | (~Sgeo@user/sgeo) Sgeo |
2025-09-11 07:50:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-09-11 07:50:25 +0200 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 258 seconds) |
2025-09-11 07:51:13 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
2025-09-11 07:56:43 +0200 | Pixi | (~Pixi@user/pixi) Pixi |
2025-09-11 07:57:44 +0200 | kaskal | (~kaskal@84-115-230-9.cable.dynamic.surfer.at) (Ping timeout: 248 seconds) |
2025-09-11 07:58:11 +0200 | kaskal | (~kaskal@2a02:8388:15bf:c200:3edd:e10d:d41e:f619) kaskal |
2025-09-11 08:01:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 08:02:59 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 272 seconds) |
2025-09-11 08:03:17 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
2025-09-11 08:06:12 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-09-11 08:07:24 +0200 | Square2 | (~Square@user/square) (Ping timeout: 256 seconds) |
2025-09-11 08:09:32 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 08:10:45 +0200 | m1dnight_ | (~m1dnight@109.236.62.133) (Read error: Connection reset by peer) |
2025-09-11 08:11:52 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-11 08:12:06 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 08:14:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-09-11 08:16:35 +0200 | m1dnight_ | (~m1dnight@109.236.62.134) m1dnight |
2025-09-11 08:23:46 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
2025-09-11 08:23:52 +0200 | ridcully | (~ridcully@p508ac996.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2025-09-11 08:24:05 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 08:25:41 +0200 | Guest59 | (~Guest59@205.254.174.179) |
2025-09-11 08:29:18 +0200 | jcarpenter2 | (~lol@96.78.87.197) (Ping timeout: 260 seconds) |
2025-09-11 08:32:36 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 08:36:54 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
2025-09-11 08:42:47 +0200 | posixlycorrect | (~posixlyco@user/posixlycorrect) posixlycorrect |
2025-09-11 08:43:19 +0200 | hiredman | (~hiredman@frontier1.downey.family) (Ping timeout: 258 seconds) |
2025-09-11 08:45:14 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 258 seconds) |
2025-09-11 08:45:30 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 08:45:41 +0200 | hiredman | (~hiredman@frontier1.downey.family) hiredman |
2025-09-11 08:45:52 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
2025-09-11 08:46:15 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 08:49:45 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b980:50d7:d756:5d4d:269d) |
2025-09-11 08:50:53 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz |
2025-09-11 08:51:13 +0200 | Guest59 | (~Guest59@205.254.174.179) (Quit: Client closed) |
2025-09-11 08:51:39 +0200 | <kqr> | tomsmeding, you know, I might be able to un-duplicate a few of the duplicate cards by adding spurious information that doesn't affect the game. however, it's still going to be over 100 cards, so 64 bits are not enough. |
2025-09-11 08:53:00 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 256 seconds) |
2025-09-11 08:53:42 +0200 | ft | (~ft@p4fc2a25a.dip0.t-ipconnect.de) (Quit: leaving) |
2025-09-11 08:54:03 +0200 | <kqr> | tomsmeding, I'm thinking of two possible avenues forward, both representing a card with a Word8. either keeping the possibility of duplicates and storing hands as short bytestrings... or setting some extra bits, making the conditionals more complicated, and trying to store them in an intset |
2025-09-11 08:54:31 +0200 | peterbecich | (~Thunderbi@syn-172-222-149-049.res.spectrum.com) peterbecich |
2025-09-11 08:58:45 +0200 | tromp | (~textual@2001:1c00:3487:1b00:4ca2:8197:56e4:708) |
2025-09-11 08:59:57 +0200 | karenw_ | (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
2025-09-11 09:00:03 +0200 | caconym747 | (~caconym@user/caconym) (Quit: bye) |
2025-09-11 09:00:44 +0200 | caconym747 | (~caconym@user/caconym) caconym |
2025-09-11 09:02:24 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
2025-09-11 09:03:24 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 09:07:55 +0200 | <probie> | kqr: What is the maximum number of cards in a hand, the maximum number of distinct cards and that maximum number of duplicates? |
2025-09-11 09:08:05 +0200 | <probie> | s/that maximum/the maximum/ |
2025-09-11 09:27:22 +0200 | ubert | (~Thunderbi@178.165.191.145.wireless.dyn.drei.com) ubert |
2025-09-11 09:28:56 +0200 | acidjnk | (~acidjnk@p200300d6e7171926a81168b3bd2506b7.dip0.t-ipconnect.de) acidjnk |
2025-09-11 09:32:53 +0200 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
2025-09-11 09:33:15 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
2025-09-11 09:38:34 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
2025-09-11 09:42:48 +0200 | <kqr> | probie, maximum number of cards in a hand is theoretically just over 50, but that rarely happens in practice. just over half of them can be duplicates (almost all cards exist in pairs, some in quadruples). but all 50 in a hand could also be distinct. |
2025-09-11 09:43:11 +0200 | chele | (~chele@user/chele) chele |
2025-09-11 09:44:06 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer) |
2025-09-11 09:45:14 +0200 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) m1dnight |
2025-09-11 09:47:09 +0200 | <probie> | So unique cards held in hand is storable in a Word64. |
2025-09-11 09:48:49 +0200 | m1dnight_ | (~m1dnight@109.236.62.134) (Ping timeout: 255 seconds) |
2025-09-11 09:49:52 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
2025-09-11 09:51:16 +0200 | <probie> | If we assume 52 distinct cards with maximally 4 copies of each, there is a pretty naive representation that fits into 4 `Word64`s |
2025-09-11 09:52:35 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
2025-09-11 09:53:22 +0200 | <tomsmeding> | at that point you're 4*8 = 32 bytes in though, and it's not fully clear whether that's better than a ShortByteString of length ~15 (one byte per card in hand) |
2025-09-11 09:53:41 +0200 | <kqr> | I agree |
2025-09-11 09:53:49 +0200 | <tomsmeding> | (be sure to use ShortByteString, not ByteString, because the latter is pinned and that is complete overkill in this situation) |
2025-09-11 09:55:11 +0200 | peterbecich | (~Thunderbi@syn-172-222-149-049.res.spectrum.com) (Ping timeout: 250 seconds) |
2025-09-11 09:55:46 +0200 | <tomsmeding> | also the 4-Word64 representation is not naturally canonical; if you remove a card from the hand, either you now have to deal with duplicates living in unpredictable Word64s, or you have to explicitly normalise the bits to the left-most Word64s or something |
2025-09-11 09:55:52 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
2025-09-11 09:56:11 +0200 | <tomsmeding> | the solution is clearly to just model a different game where duplicates are not a thing and use a single Word64 |
2025-09-11 09:56:32 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
2025-09-11 09:59:10 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
2025-09-11 10:00:29 +0200 | <dminuoso> | Oh my. I found something that Python genuinely got right compared to Haskell: They have 1-tuples. |
2025-09-11 10:00:47 +0200 | <dminuoso> | Very happy about it, too. |
2025-09-11 10:01:11 +0200 | <dminuoso> | (Except the moments you accidentally create them, they they are annoying due to lack of a functional type system, but hey you cant have everything) |
2025-09-11 10:02:36 +0200 | <probie> | doesn't `Solo` exist? |
2025-09-11 10:06:14 +0200 | <tomsmeding> | dminuoso: a friend of mine has somehow accidentally ended up with a comma at the end of a line multiple times |
2025-09-11 10:06:29 +0200 | <tomsmeding> | the resulting bugs were interesting |
2025-09-11 10:07:04 +0200 | <tomsmeding> | also, what do you use 1-tuples for? |
2025-09-11 10:07:19 +0200 | <[exa]> | tuplic consistency!!1 |
2025-09-11 10:07:55 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 10:08:17 +0200 | <[exa]> | the only good use I found for tuples was with DB-ish and CSV-ish frontends, there it nicely says that the thing is a row not just a piece of data |
2025-09-11 10:08:24 +0200 | <[exa]> | *1-tuples |
2025-09-11 10:08:46 +0200 | <tomsmeding> | right |
2025-09-11 10:08:59 +0200 | <tomsmeding> | % import qualified Language.Haskell.TH as TH |
2025-09-11 10:08:59 +0200 | <yahb2> | <no output> |
2025-09-11 10:09:04 +0200 | <tomsmeding> | % :seti -XTemplateHaskell |
2025-09-11 10:09:04 +0200 | <yahb2> | <no output> |
2025-09-11 10:09:05 +0200 | <[exa]> | also I recall it was called Only instd of Solo, kinda wondering what's the difference there |
2025-09-11 10:09:16 +0200 | <tomsmeding> | % $(pure $ TH.TupE [Just (TH.LitE (TH.IntegerL 42))]) |
2025-09-11 10:09:16 +0200 | <yahb2> | MkSolo 42 |
2025-09-11 10:09:17 +0200 | tremon | (~tremon@83.80.159.219) tremon |
2025-09-11 10:09:17 +0200 | lbseale | (~quassel@user/ep1ctetus) (Ping timeout: 260 seconds) |
2025-09-11 10:09:23 +0200 | <tomsmeding> | [exa]: Only was a library |
2025-09-11 10:09:25 +0200 | <tomsmeding> | @hackage only |
2025-09-11 10:09:25 +0200 | <lambdabot> | https://hackage.haskell.org/package/only |
2025-09-11 10:09:29 +0200 | <tomsmeding> | oh |
2025-09-11 10:09:39 +0200 | <tomsmeding> | bastards |
2025-09-11 10:09:41 +0200 | <tomsmeding> | @hackage Only |
2025-09-11 10:09:41 +0200 | <lambdabot> | https://hackage.haskell.org/package/Only |
2025-09-11 10:10:09 +0200 | <[exa]> | O_o |
2025-09-11 10:10:29 +0200 | <[exa]> | ^ lexical form of wtfface very relevant in this situation |
2025-09-11 10:10:47 +0200 | <tomsmeding> | :D |
2025-09-11 10:12:14 +0200 | <[exa]> | interestingly all Only definitions in the packages are newtypes but Solo from base is `data` |
2025-09-11 10:13:41 +0200 | <[exa]> | which kinda makes sense for more consistency with tuples I guess, the actual workalike of the newtypish Only in base would rather be `Identity` then |
2025-09-11 10:13:46 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
2025-09-11 10:13:52 +0200 | <tomsmeding> | [exa]: this one isn't https://hackage.haskell.org/package/OneTuple-0.4.1.1/docs/Data-Tuple-Solo.html |
2025-09-11 10:14:03 +0200 | <tomsmeding> | I had this one in mind actually but forgot that it wasn't called Only |
2025-09-11 10:15:17 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 10:15:22 +0200 | <[exa]> | that looks kinda isomorphic to the one from base actually |
2025-09-11 10:16:27 +0200 | <tomsmeding> | it's meant to, it's a compatibility package |
2025-09-11 10:17:23 +0200 | Square3 | (~Square4@user/square) Square |
2025-09-11 10:17:37 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 10:17:41 +0200 | <[exa]> | ok tuplic consistency has been reached |
2025-09-11 10:21:50 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
2025-09-11 10:34:08 +0200 | Sgeo_ | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
2025-09-11 10:35:10 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
2025-09-11 10:36:26 +0200 | img | (~img@user/img) img |
2025-09-11 10:39:05 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 258 seconds) |
2025-09-11 10:45:35 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 10:51:20 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 10:55:45 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
2025-09-11 11:05:03 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
2025-09-11 11:05:03 +0200 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
2025-09-11 11:05:03 +0200 | haritz | (~hrtz@user/haritz) haritz |
2025-09-11 11:07:36 +0200 | <Square3> | I'm thinking I could generate .proto files from a big domain model using template haskell. But I wonder 1) is this a sane usecase for TH 2) Are there some best practice / support for generating things other than haskell code with TH? |
2025-09-11 11:18:11 +0200 | <dminuoso> | tomsmeding: Well what do people use 1-element lists for? |
2025-09-11 11:18:48 +0200 | <dminuoso> | probie: Sure I mean there is things isomorphic to it, but thats not quite the same. |
2025-09-11 11:18:58 +0200 | <dminuoso> | Say you have some typeclass machinery that works over n-tuples. |
2025-09-11 11:19:13 +0200 | <dminuoso> | If you want to tap into that, you need to special case the 1-tuple and it looks awkward |
2025-09-11 11:19:25 +0200 | <dminuoso> | (), Solo 1, (1, 2), (1, 2, 3) |
2025-09-11 11:19:27 +0200 | <dminuoso> | Just not pleasant. |
2025-09-11 11:19:43 +0200 | <dminuoso> | Besides, that Solo will not have sufficient instances across the ecosystem |
2025-09-11 11:21:03 +0200 | <lortabac> | overloaded parenthesis for both grouping and tuples is not ideal |
2025-09-11 11:21:41 +0200 | <dminuoso> | lortabac: python gets away syntactically by just having (1,) a 1-tuple |
2025-09-11 11:21:43 +0200 | <lortabac> | but it looks nice |
2025-09-11 11:21:58 +0200 | <dminuoso> | And since a trailing comma is allowed in general, it fits nicely in |
2025-09-11 11:22:12 +0200 | <lortabac> | dminuoso: that would be inconsistent with sections |
2025-09-11 11:22:20 +0200 | <dminuoso> | Indeed |
2025-09-11 11:22:20 +0200 | <lortabac> | (in Haskell) |
2025-09-11 11:22:26 +0200 | Rain | (\@user/Rain-:22721) (Quit: ZNC 1.9.1 - https://znc.in) |
2025-09-11 11:22:32 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
2025-09-11 11:23:01 +0200 | <dminuoso> | Personally I would have preferred an underscore for a section |
2025-09-11 11:23:07 +0200 | <dminuoso> | i.e. (1,_) |
2025-09-11 11:23:24 +0200 | <lortabac> | yes it's clearer |
2025-09-11 11:23:42 +0200 | <lortabac> | but at the same time things like (+ 1) are nice |
2025-09-11 11:24:04 +0200 | <lortabac> | tuple sections are good for consistency but probably not the best choice indeed |
2025-09-11 11:24:45 +0200 | <dminuoso> | Its always easy to critize these things in hindsight *after* 37 additional extensions have developed. |
2025-09-11 11:25:21 +0200 | <dminuoso> | Which underlines again the need for a time machine. |
2025-09-11 11:27:05 +0200 | <lortabac> | also, TBH the lack of singleton tuple is a very minor problem |
2025-09-11 11:27:09 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-09-11 11:27:22 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 11:27:42 +0200 | <dminuoso> | Dunno, I like the consistency in these things. Im also a fan of having nullary typeclasses. |
2025-09-11 11:27:51 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
2025-09-11 11:29:01 +0200 | <dminuoso> | When working with things like postgresql-simple a singleton tuple would feel nice |
2025-09-11 11:30:55 +0200 | <tomsmeding> | dminuoso: typeclass machinery doesn't generalise over n-tuples at all |
2025-09-11 11:31:06 +0200 | <tomsmeding> | TemplateHaskell does, but as I showed above, that is aware of Solo |
2025-09-11 11:31:11 +0200 | <tomsmeding> | % $(pure $ TH.TupE [Just (TH.LitE (TH.IntegerL 42))]) |
2025-09-11 11:31:11 +0200 | <yahb2> | MkSolo 42 |
2025-09-11 11:31:54 +0200 | <tomsmeding> | and what people use 1-element lists for is cases where you want a list in the first place, i.e. you have a dynamically sized vector (that you don't want to put in an array for some reason) |
2025-09-11 11:32:07 +0200 | <tomsmeding> | tuples are not dynamically sized so that use case doesn't apply |
2025-09-11 11:33:07 +0200 | <tomsmeding> | "looks awkward" I can get on board with, but I think tuple sections are also nice, and I don't think the consistency in "(), Solo 1, (1, 2), (1, 2, 3)" is worth enough to not have tuple sections |
2025-09-11 11:33:42 +0200 | <dminuoso> | tomsmeding: Like I said, I would have preferred (1, _) as tuple section syntax anyway. |
2025-09-11 11:33:44 +0200 | <dminuoso> | :p |
2025-09-11 11:33:44 +0200 | <tomsmeding> | Solo not having sufficient instances across the ecosystem is also fair |
2025-09-11 11:33:53 +0200 | <tomsmeding> | ah I missed that bit |
2025-09-11 11:34:11 +0200 | <tomsmeding> | Agda does something like that |
2025-09-11 11:34:22 +0200 | <tomsmeding> | _+ 3 :: Int -> Int |
2025-09-11 11:34:35 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 11:34:57 +0200 | <dminuoso> | yeah and more crazily you can declare arbitrary mixfix things with that. |
2025-09-11 11:35:01 +0200 | <tomsmeding> | yes |
2025-09-11 11:35:11 +0200 | <dminuoso> | Even if then else is user definable this way, its crazy. |
2025-09-11 11:35:12 +0200 | <tomsmeding> | if_then_else_ : Bool -> a -> a -> a |
2025-09-11 11:35:20 +0200 | <dminuoso> | I dont even want to know how that parser is written. |
2025-09-11 11:35:40 +0200 | ski | would like "composite sections", like `(1 + 2 *)' (being `\x -> 1 + 2 * x') |
2025-09-11 11:35:41 +0200 | <tomsmeding> | I hear that it's not actually that terrible, but I've never looked at it |
2025-09-11 11:36:00 +0200 | <tomsmeding> | ski: they already work if the precedence works out; `(1 * 2 +)' does work |
2025-09-11 11:36:07 +0200 | <tomsmeding> | % :t (1 * 2 +) |
2025-09-11 11:36:07 +0200 | <yahb2> | (1 * 2 +) :: Num a => a -> a |
2025-09-11 11:36:30 +0200 | <ski> | yes, but this is specifically for the other way around, with precedence & associativity |
2025-09-11 11:36:47 +0200 | <tomsmeding> | at that point I'd feel more for dminuoso's syntax |
2025-09-11 11:36:49 +0200 | <tomsmeding> | (1 + 2 * _) |
2025-09-11 11:36:52 +0200 | <ski> | @type (?f . ?g .) |
2025-09-11 11:36:53 +0200 | <lambdabot> | error: |
2025-09-11 11:36:53 +0200 | <lambdabot> | The operator ‘.’ [infixr 9] of a section |
2025-09-11 11:36:53 +0200 | <lambdabot> | must have lower precedence than that of the operand, |
2025-09-11 11:36:58 +0200 | <ski> | this is annoying |
2025-09-11 11:37:02 +0200 | <tomsmeding> | fair |
2025-09-11 11:37:44 +0200 | <tomsmeding> | because (.) is defined infixr |
2025-09-11 11:38:02 +0200 | <tomsmeding> | in general though, GHC doesn't know anything about actual associativity of operators |
2025-09-11 11:38:13 +0200 | ski | also would not be a fan of `_' for sections |
2025-09-11 11:39:21 +0200 | <tomsmeding> | dminuoso: have you thought about combining mixfix with precedence and associativity |
2025-09-11 11:39:36 +0200 | <tomsmeding> | if not, then yes agda does that too |
2025-09-11 11:40:26 +0200 | <ski> | people might start wanting `(0,(1,_),3)' to mean `\x -> (0,(1,x),3)' (rather than `(0,\x -> (1,x),3)'). the problem is one of delimitation, how far out does it "extend". if you insist on a missing operand at the start, or the end, with no extra syntax before/after those, that solves that issue |
2025-09-11 11:41:12 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
2025-09-11 11:41:14 +0200 | <tomsmeding> | but then you're drawing an arbitrary line where \x -> (1,2,x) can be a section and \x -> (1,x,2) cannot |
2025-09-11 11:41:20 +0200 | <tomsmeding> | er, s/,/+/g |
2025-09-11 11:41:27 +0200 | <ski> | yes |
2025-09-11 11:41:47 +0200 | <ski> | i consider tuple sections to be a different animal than operator sections |
2025-09-11 11:41:49 +0200 | <tomsmeding> | currently there is also an arbitrary line: the partially-applied operator must be at the top level |
2025-09-11 11:41:58 +0200 | <tomsmeding> | I'm not sure your arbitrary line is better |
2025-09-11 11:42:11 +0200 | <tomsmeding> | neither is fully general |
2025-09-11 11:42:15 +0200 | <ski> | mm |
2025-09-11 11:42:39 +0200 | <tomsmeding> | yours is more general than the current one, granted |
2025-09-11 11:42:48 +0200 | <ski> | "where \x -> (1,2,x) can be a section" -- not with non-tuple sections |
2025-09-11 11:42:50 +0200 | tromp | (~textual@2001:1c00:3487:1b00:4ca2:8197:56e4:708) (Ping timeout: 245 seconds) |
2025-09-11 11:43:00 +0200 | <tomsmeding> | yeah sorry I wrote tuples but I meant + |
2025-09-11 11:43:08 +0200 | <tomsmeding> | with TupleSections both are already possible |
2025-09-11 11:43:15 +0200 | <tomsmeding> | and I presume they would remain possible with your proposal |
2025-09-11 11:43:18 +0200 | <ski> | ah, so `\x -> 1 + 2 + x' ? |
2025-09-11 11:43:21 +0200 | ridcully | (~ridcully@p57b5234b.dip0.t-ipconnect.de) ridcully |
2025-09-11 11:43:26 +0200 | <tomsmeding> | yes, versus `\x -> 1 + x + 2' |
2025-09-11 11:43:50 +0200 | <tomsmeding> | and if you say + is commutative, sure, some other non-commutative operator :p |
2025-09-11 11:43:50 +0200 | <ski> | having non-numeric precedences would also be nice |
2025-09-11 11:44:03 +0200 | <tomsmeding> | Agda has fractional precedences |
2025-09-11 11:44:12 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 11:44:23 +0200 | <ski> | but you'd want to be able to declare precedence groups, and after-the-fact include more operators into existing groups |
2025-09-11 11:44:28 +0200 | petrichor | (~jez@user/petrichor) (Remote host closed the connection) |
2025-09-11 11:44:43 +0200 | <tomsmeding> | that sounds equivalent to numeric precedences, except for less names? |
2025-09-11 11:44:58 +0200 | <tomsmeding> | an actual serious generalisation would be a precedence lattice |
2025-09-11 11:45:14 +0200 | <tomsmeding> | but then that feels hard to usably accomplish in practice |
2025-09-11 11:45:43 +0200 | <tomsmeding> | and usefully -- you get the same problem as we currently have with needing to depend on half of hackage just to give all the instances for your new fancy data type |
2025-09-11 11:46:49 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Quit: Client closed) |
2025-09-11 11:46:49 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 11:47:35 +0200 | <ski> | also, if `A o B p C q D' is legal, where `o',`p',`q' are infix operators, and `A',`B',`C',`D' are atomic expressions (or expressions of less precedence than the respective adjacent operators), a useful rule to ponder having, would be that `A o B q D' and `A o C q D' also (ignoring types) ought to be legal |
2025-09-11 11:48:20 +0200 | <ski> | this is a kind of abstract transitivity of precedences & associativity |
2025-09-11 11:49:39 +0200 | <ski> | having a prefix/suffix version of `(...)' (grouping) would violate this, btw, so that probably still ought to be an exception |
2025-09-11 11:50:12 +0200 | <ski> | (note that `A o' there is basically a prefix operator, and `q D' a suffix operator) |
2025-09-11 11:50:15 +0200 | petrichor | (~jez@user/petrichor) (Client Quit) |
2025-09-11 11:51:02 +0200 | <tomsmeding> | % 1 == 2 && 3 == 4 |
2025-09-11 11:51:02 +0200 | <yahb2> | False |
2025-09-11 11:51:07 +0200 | <tomsmeding> | % 1 == 3 == 4 |
2025-09-11 11:51:08 +0200 | <yahb2> | <interactive>:89:1: error: [GHC-88747] ; Precedence parsing error ; cannot mix ‘==’ [infix 4] and ‘==’ [infix 4] in the same infix expression |
2025-09-11 11:51:17 +0200 | <tomsmeding> | this rule is currently false in haskell |
2025-09-11 11:51:37 +0200 | <tomsmeding> | (if I'm reading you correctly) |
2025-09-11 11:52:15 +0200 | <tomsmeding> | (this is not about types, while the types differ here you could define operators with these precedences where all the types are the same) |
2025-09-11 11:52:22 +0200 | <ski> | so, more generally, you could say `o B p C q' (where `o' is prefix and `q' suffix), then also `o B q' and `o C q' (assuming the associativity of both `B' and `C' is below that of `q' resp. `o') |
2025-09-11 11:53:40 +0200 | <ski> | mm yes, i should express that `p' is the intermediate operator, inbetween `o' and `q', here .. hmm |
2025-09-11 11:56:06 +0200 | <ski> | the idea is that if you have an AST, left-leaning, or right-leaning, not requiring explicit grouping, then removing the intermediate node (and its side-subtree, not on the path), that should not suddenly cause you to require grouping being inserted, to cope with the two nodes/operators now being directly in contact to each other |
2025-09-11 11:56:41 +0200 | <ski> | i suppose s/AST/CST/ |
2025-09-11 11:57:46 +0200 | <ski> | the point, is that if you have abstract precedences, then it would be too much work, to specify every possible interaction between pairs of operators |
2025-09-11 11:58:34 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 11:58:58 +0200 | <ski> | you'd want some notion of transitivity, to be able to infer that if `+' binds more loosely than `*', and `*' binds more loosely than `^', then `+' binds more loosely than `^' |
2025-09-11 12:00:19 +0200 | <ski> | (so, the question is how to tractably, modularly, specify the partial order of precedence) |
2025-09-11 12:01:04 +0200 | fp | (~Thunderbi@2001-14ba-6e24-3000--198.rev.dnainternet.fi) fp |
2025-09-11 12:01:06 +0200 | <ski> | (btw, `if ... then ... else' would be a prefix operator, here, as well) |
2025-09-11 12:01:15 +0200 | <ski> | (or, at least, could be) |
2025-09-11 12:01:43 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
2025-09-11 12:03:49 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 255 seconds) |
2025-09-11 12:04:08 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 12:04:16 +0200 | <ski> | oh .. right. i kinda started thinking about this, when reading some papers by Annika Aasa, about parsing. and also then looking a bit at Agda parsing |
2025-09-11 12:05:20 +0200 | fp | (~Thunderbi@2001-14ba-6e24-3000--198.rev.dnainternet.fi) (Ping timeout: 245 seconds) |
2025-09-11 12:08:55 +0200 | petrichor | (~jez@user/petrichor) (Quit: ZNC 1.10.1 - https://znc.in) |
2025-09-11 12:10:35 +0200 | trickard_ | trickard |
2025-09-11 12:11:19 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
2025-09-11 12:13:57 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz |
2025-09-11 12:14:09 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 12:14:41 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
2025-09-11 12:15:31 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 255 seconds) |
2025-09-11 12:16:52 +0200 | petrichor | (~jez@user/petrichor) (Client Quit) |
2025-09-11 12:18:11 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
2025-09-11 12:21:17 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) segfaultfizzbuzz |
2025-09-11 12:23:34 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
2025-09-11 12:24:40 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
2025-09-11 12:26:20 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 12:35:26 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
2025-09-11 12:37:17 +0200 | poscat | (~poscat@user/poscat) poscat |
2025-09-11 12:38:58 +0200 | poscat0x04 | (~poscat@user/poscat) (Ping timeout: 260 seconds) |
2025-09-11 12:39:01 +0200 | <ski> | "Parsing as Deduction" by Fernando C. N. Pereira,David H. D. Warren in 1983-06-15 at <https://dl.acm.org/doi/pdf/10.3115/981311.981338> |
2025-09-11 12:39:06 +0200 | mari-estel | (~mari-este@user/mari-estel) () |
2025-09-11 12:39:08 +0200 | <ski> | "Metamorphosis Grammar" (by Alain Colmerauer in 1978-05 ?) at <https://www.site.uottawa.ca/~szpak/pub/P4P/P4P_03_Metamorphosis_grammars.pdf> |
2025-09-11 12:39:19 +0200 | <ski> | "Concrete Syntax for Data Objects in Functional Languages" by Annika Aasa,Kent Petersson,Dan Synek in 1988-07 at <https://web.archive.org/web/20070207110810/http://www.cs.chalmers.se/~kentp/conc.ps> |
2025-09-11 12:39:29 +0200 | <ski> | "Recursive descent parsing of user defined distfix operators" (Lic. th.) by Annika Aasa in 1989 (at ?) |
2025-09-11 12:39:37 +0200 | <ski> | "Precedences in Specifications and Implementations of Programming Languages" by ibid in 1991 at <https://web.archive.org/web/20070701130745/http://www.cs.chalmers.se/~annika/plilp91.ps>,<https://link.springer.com/content/pdf/10.1007/3-540-54444-5_98.pdf> |
2025-09-11 12:39:44 +0200 | <ski> | "User Defined Syntax" (Ph. D. diss.) by ibid in 1992 at <https://web.archive.org/web/20050424185150/http://www.cs.chalmers.se/~annika/aasa-thesis.ps> |
2025-09-11 12:39:50 +0200 | <ski> | "Precedences in Specifications and Implementations of Programming Languages" by ibid in 1995 at <https://web.archive.org/web/20070701130745/http://www.cs.chalmers.se/~annika/tcs95.ps> |
2025-09-11 12:39:58 +0200 | <ski> | cf. <https://web.archive.org/web/20070701130745/http://www.cs.chalmers.se/~annika/> |
2025-09-11 12:40:01 +0200 | <ski> | "Parsing Mixfix Operators" by Nils Anders Danielsson,Ulf Norell in 2008-09 at <https://www.cse.chalmers.se/~nad/publications/danielsson-norell-mixfix.pdf> |
2025-09-11 12:41:06 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 256 seconds) |
2025-09-11 12:41:33 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
2025-09-11 12:42:10 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
2025-09-11 12:47:47 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 12:48:34 +0200 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
2025-09-11 12:54:19 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
2025-09-11 12:56:02 +0200 | __monty__ | (~toonn@user/toonn) toonn |
2025-09-11 13:00:04 +0200 | caconym747 | (~caconym@user/caconym) (Quit: bye) |
2025-09-11 13:01:15 +0200 | ubert | (~Thunderbi@178.165.191.145.wireless.dyn.drei.com) (Quit: ubert) |
2025-09-11 13:02:14 +0200 | caconym747 | (~caconym@user/caconym) caconym |
2025-09-11 13:03:07 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
2025-09-11 13:03:35 +0200 | fp | (~Thunderbi@wireless-86-50-140-161.open.aalto.fi) fp |
2025-09-11 13:08:40 +0200 | [exa] | (~exa@user/exa/x-3587197) (Remote host closed the connection) |
2025-09-11 13:12:17 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 13:20:41 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-11 13:20:58 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
2025-09-11 13:25:04 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
2025-09-11 13:27:43 +0200 | [exa] | (~exa@user/exa/x-3587197) [exa] |
2025-09-11 13:28:15 +0200 | Alleria_ | (~Alleria@user/alleria) (Read error: Connection reset by peer) |
2025-09-11 13:28:47 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 13:28:49 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 250 seconds) |
2025-09-11 13:30:31 +0200 | SlackCoder | (~SlackCode@208.26.70.132) SlackCoder |
2025-09-11 13:33:01 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
2025-09-11 13:35:08 +0200 | Alleria | (~Alleria@user/alleria) Alleria |
2025-09-11 13:38:20 +0200 | jbalint | (~jbalint@2600:6c44:117f:e98a:40bb:52ad:62b8:5122) (Read error: Connection reset by peer) |
2025-09-11 13:42:16 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 248 seconds) |
2025-09-11 13:44:29 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
2025-09-11 13:46:39 +0200 | Guest56 | (~Guest56@37.111.214.210) |
2025-09-11 13:47:39 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 13:49:49 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
2025-09-11 13:50:44 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-09-11 13:54:03 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 13:54:30 +0200 | jbalint | (~jbalint@syn-071-090-116-115.res.spectrum.com) |
2025-09-11 13:56:25 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 13:58:27 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
2025-09-11 13:59:27 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine) |
2025-09-11 14:02:37 +0200 | SlackCoder | (~SlackCode@208.26.70.132) (Quit: Leaving) |
2025-09-11 14:02:43 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 14:05:06 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Quit: Leaving) |
2025-09-11 14:05:07 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
2025-09-11 14:05:28 +0200 | Guest56 | (~Guest56@37.111.214.210) (Quit: Client closed) |
2025-09-11 14:11:24 +0200 | xff0x | (~xff0x@2405:6580:b080:900:4d35:2673:a36a:250b) |
2025-09-11 14:19:37 +0200 | tremon | (~tremon@83.80.159.219) tremon |
2025-09-11 14:20:45 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 245 seconds) |
2025-09-11 14:21:06 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 14:26:59 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-11 14:27:59 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
2025-09-11 14:28:18 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 14:37:42 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 14:38:16 +0200 | trickard | (~trickard@cpe-54-98-47-163.wireline.com.au) (Ping timeout: 248 seconds) |
2025-09-11 14:42:07 +0200 | jreicher | (~user@user/jreicher) (Ping timeout: 258 seconds) |
2025-09-11 14:42:07 +0200 | trickard_ | (~trickard@cpe-54-98-47-163.wireline.com.au) |
2025-09-11 14:42:34 +0200 | jreicher | (~user@user/jreicher) jreicher |
2025-09-11 14:43:35 +0200 | petrichor | (~jez@user/petrichor) (Quit: ZNC 1.10.1 - https://znc.in) |
2025-09-11 14:45:14 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
2025-09-11 14:46:07 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) |
2025-09-11 14:48:02 +0200 | <kqr> | I have a CPU bound loop that is embarassingly parallel. What would be the modern way to split that up into equal chunks and run each of them on a separate core? I tried naïvely using forConcurrently from the async library, but that seemed like it ended up causing more contention and context switches because the evaluation went a lot slower with it. |
2025-09-11 14:48:17 +0200 | <kqr> | (I did compile with -threaded and run with -N2 to test.) |
2025-09-11 14:49:25 +0200 | <merijn> | kqr: Yeah, forConcurrently for CPU bound tasks spawns a lot more threads than useful |
2025-09-11 14:51:04 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 248 seconds) |
2025-09-11 14:51:08 +0200 | <merijn> | kqr: Fortunately for you, I had exactly this issue, approximately a decade ago and I got so tired of reinventing the wheel for myself that this exists: https://hackage-content.haskell.org/package/broadcast-chan-0.3.0/docs/BroadcastChan.html#g:4 |
2025-09-11 14:51:29 +0200 | <kqr> | Since these are very short-lived tasks I also suspect it'd benefit from setting up the plumbing first and then using light operations to throw tasks at workers. |
2025-09-11 14:51:59 +0200 | <merijn> | kqr: That's pretty much what the linked code does :p |
2025-09-11 14:52:14 +0200 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
2025-09-11 14:52:42 +0200 | <L29Ah> | kqr: https://hackage.haskell.org/package/parallel-io-0.3.5/docs/Control-Concurrent-ParallelIO-Local.html maybe |
2025-09-11 14:52:48 +0200 | <merijn> | Ignore the large dependency list shown by hackage, it's not great at showing dependencies for multi-lib packages. The core library I linked has a transitive dependency tree of 3 (including base and transformers) |
2025-09-11 14:55:37 +0200 | <kqr> | merijn, if I understand it correctly, the parFoldMap would be setting up the plumbing afresh each time it is called, so if I use that I would want it to wrap a larger piece of work. Alternatively I could spawn a few workers and hand them BroadcastChan handles to receive work from if I want to schedule smaller pieces of work at a time? |
2025-09-11 14:59:23 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
2025-09-11 14:59:26 +0200 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
2025-09-11 15:02:20 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 15:05:58 +0200 | mange | (~mange@user/mange) (Quit: Zzz...) |
2025-09-11 15:06:13 +0200 | AndreiDuma | (~AndreiDum@user/AndreiDuma) AndreiDuma |
2025-09-11 15:08:26 +0200 | <kqr> | L29Ah, I tested that first because it was easiest to adapt the code to. Takes 2.5× longer than single-threaded when I run it with two threads. It seems like it doesn't pin the processes to threads and just go with it, but swap them around or something, because none of the cores are particularly utilised while it runs in parallel. |
2025-09-11 15:09:28 +0200 | <L29Ah> | sounds strange, it worked well for me |
2025-09-11 15:10:12 +0200 | <L29Ah> | -O2 -threaded -rtsopts "-with-rtsopts -N" |
2025-09-11 15:10:57 +0200 | <kqr> | https://entropicthoughts.com/pastes/Main-e34639.hs.html That's the code, compiled -threaded and run +RTS -N2. I don't think I'm using it wrong. |
2025-09-11 15:11:37 +0200 | AndreiDuma | (~AndreiDum@user/AndreiDuma) (Quit: My Mac has gone to sleep. ZZZzzz…) |
2025-09-11 15:12:59 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 248 seconds) |
2025-09-11 15:13:27 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
2025-09-11 15:20:06 +0200 | <merijn> | kqr: the conduit library lets you stream jobs into parallel workers |
2025-09-11 15:20:48 +0200 | <merijn> | kqr: That's what I did, use conduit to stream task descriptions into workers, then reassemble after processing in parallel |
2025-09-11 15:28:43 +0200 | <merijn> | kqr: For large inputs I'm not at all surprised it's slower |
2025-09-11 15:29:07 +0200 | <merijn> | Since it just immediately forks of N (where N is your input size) forkIO threads, then has them fighting over the available RTS capabilities to finish |
2025-09-11 15:29:19 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
2025-09-11 15:29:23 +0200 | <merijn> | Which is fine if they're largely blocking, but pointless for CPU bound work |
2025-09-11 15:30:27 +0200 | <merijn> | kqr: The parMapM/parMapM_ in the conduit library are pretty nice if you want to stream a large number of jobs: https://hackage-content.haskell.org/package/broadcast-chan-0.3.0/docs/BroadcastChan-Conduit.html#v… |
2025-09-11 15:42:05 +0200 | <L29Ah> | kqr: lgtm, i use it similarily in hyborg |
2025-09-11 15:42:51 +0200 | <L29Ah> | merijn: are you sure you don't have funny thread-blocking things like unsafePerformIO in your workload? |
2025-09-11 15:43:07 +0200 | <L29Ah> | or those "safe" FFI calls |
2025-09-11 15:43:26 +0200 | <L29Ah> | er kqr |
2025-09-11 15:43:47 +0200 | <merijn> | unsafePerformIO itself should be fine |
2025-09-11 15:43:51 +0200 | <merijn> | and safe FFI calls too |
2025-09-11 15:44:21 +0200 | <L29Ah> | unsafePerformIO stops all the other threads until finished IIRC |
2025-09-11 15:44:33 +0200 | <merijn> | That's definitely not true |
2025-09-11 15:45:24 +0200 | <merijn> | The closest thing to that that is true is unsafe foreign calls block garbage collection (and can thus block other capabilities if they need to GC) |
2025-09-11 15:46:03 +0200 | <merijn> | but unsafe foreign calls are a far cry from unsafePerformIO |
2025-09-11 15:47:59 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
2025-09-11 15:48:18 +0200 | <tomsmeding> | IIRC parallel evaluation of a thunk that is an unsafePerformIO will lock |
2025-09-11 15:48:42 +0200 | <tomsmeding> | but that is redundant parallel evaluation of _one_ thunk, which is not helpful anyway |
2025-09-11 15:48:50 +0200 | <merijn> | tomsmeding: Yes |
2025-09-11 15:49:14 +0200 | <merijn> | something with blackholing/grey holing |
2025-09-11 15:49:19 +0200 | <merijn> | And I always forget which is which |
2025-09-11 15:49:24 +0200 | <tomsmeding> | ¯\_(ツ)_/¯ |
2025-09-11 15:50:17 +0200 | <tomsmeding> | merijn: unsafePerformIO does something more special than normal blackholing though, which is what all thunks do to catch <<loop>> |
2025-09-11 15:50:22 +0200 | <L29Ah> | it is helpful if it is a thing like a static array read |
2025-09-11 15:50:27 +0200 | <tomsmeding> | there is this noDuplicate# call where I don't know what it does |
2025-09-11 15:50:34 +0200 | <L29Ah> | while waiting for a lock is very expensive compared to the read |
2025-09-11 15:50:41 +0200 | <merijn> | tomsmeding: Yeah, <<loop>> is blackholing, I think the parallel evaluation thing is greyholing |
2025-09-11 15:50:43 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
2025-09-11 15:50:48 +0200 | <tomsmeding> | L29Ah: a static array read should probably use unsafeDupablePerformIO if you care about parallel efficiency |
2025-09-11 15:50:58 +0200 | <tomsmeding> | because that doesn't do the additional noDuplicate stuff |
2025-09-11 15:51:01 +0200 | <tomsmeding> | ah |
2025-09-11 15:51:19 +0200 | <L29Ah> | https://github.com/haskell/unix/issues/157 yes but people don't believe |
2025-09-11 15:51:28 +0200 | <L29Ah> | anyway that's just my guess re kqr's lack of performance |
2025-09-11 15:52:07 +0200 | <merijn> | L29Ah: I mean, the "forces the program to run single-threaded" is still wrong |
2025-09-11 15:52:08 +0200 | <L29Ah> | mayhaps lock trashing would result in worse-than-single-thread performance |
2025-09-11 15:52:21 +0200 | <L29Ah> | yes it is imprecise, sorry :] |
2025-09-11 15:52:25 +0200 | <merijn> | L29Ah: And tbh, I don't think unsafePerformIO has any meaningful impact on any of the operations that unix does |
2025-09-11 15:52:49 +0200 | <L29Ah> | it does when you have millions of files to poke in your backup program |
2025-09-11 15:53:48 +0200 | <tomsmeding> | L29Ah: I think the unix maintainers will be more eager to make the changes you request if you come with an actual benchmark :) |
2025-09-11 15:54:18 +0200 | <tomsmeding> | because "unsafePerformIO makes your code run single-threaded" is simply false, but it may well be that due to some other effects, that ends up being the case in your particular use-case |
2025-09-11 16:06:50 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-09-11 16:08:22 +0200 | <EvanR> | not all IO actions even do I/O |
2025-09-11 16:10:28 +0200 | <EvanR> | or access shared resources |
2025-09-11 16:13:26 +0200 | SlackCoder | (~SlackCode@remote.nationalgallery.org.ky) SlackCoder |
2025-09-11 16:15:13 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
2025-09-11 16:16:57 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
2025-09-11 16:17:19 +0200 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
2025-09-11 16:33:06 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) Inline |
2025-09-11 16:35:23 +0200 | jbalint | (~jbalint@syn-071-090-116-115.res.spectrum.com) (Quit: Bye!) |
2025-09-11 16:39:10 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 244 seconds) |
2025-09-11 16:39:20 +0200 | emperori | (~emperori@223.187.122.81) |
2025-09-11 16:43:54 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Read error: Connection reset by peer) |
2025-09-11 16:43:57 +0200 | emperori | (~emperori@223.187.122.81) (Read error: Connection reset by peer) |
2025-09-11 16:44:21 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-09-11 16:45:24 +0200 | Guest56 | (~Guest56@140.235.141.169) |
2025-09-11 16:45:31 +0200 | Guest56 | (~Guest56@140.235.141.169) (Client Quit) |
2025-09-11 16:45:55 +0200 | afu1101 | (~afu1101@140.235.141.167) |
2025-09-11 16:46:29 +0200 | afu1101 | (~afu1101@140.235.141.167) (Client Quit) |
2025-09-11 16:46:59 +0200 | mari81549 | (~mari-este@user/mari-estel) mari-estel |
2025-09-11 16:47:28 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2) |
2025-09-11 16:47:49 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) Inline |
2025-09-11 16:48:37 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 258 seconds) |
2025-09-11 16:48:52 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
2025-09-11 16:48:58 +0200 | mari-estel | (~mari-este@user/mari-estel) (Read error: Connection reset by peer) |
2025-09-11 16:49:50 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 16:59:47 +0200 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
2025-09-11 17:00:53 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
2025-09-11 17:01:08 +0200 | califax | (~califax@user/califx) califx |
2025-09-11 17:06:57 +0200 | fp | (~Thunderbi@wireless-86-50-140-161.open.aalto.fi) (Ping timeout: 248 seconds) |
2025-09-11 17:07:13 +0200 | petrichor | (~jez@user/petrichor) (Ping timeout: 250 seconds) |
2025-09-11 17:07:55 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
2025-09-11 17:09:20 +0200 | petrichor | (~jez@user/petrichor) petrichor |
2025-09-11 17:13:36 +0200 | SlackCoder | (~SlackCode@remote.nationalgallery.org.ky) (Remote host closed the connection) |
2025-09-11 17:18:48 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) |
2025-09-11 17:23:07 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 258 seconds) |
2025-09-11 17:23:41 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 250 seconds) |
2025-09-11 17:27:00 +0200 | trickard_ | trickard |
2025-09-11 17:27:11 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
2025-09-11 17:27:45 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) Inline |
2025-09-11 17:33:05 +0200 | <geekosaur> | there is one sense in which it may have that effect: the difference between `unsafePerformIO` and `unsafeDupablePerformIO` |
2025-09-11 17:35:21 +0200 | merijn | (~merijn@77.242.116.146) merijn |
2025-09-11 17:37:40 +0200 | NucleusBiffBot | (~nucleusbi@user/NucleusBiffBot) NucleusBiffBot |
2025-09-11 17:37:41 +0200 | NucleusBiffBot | (~nucleusbi@user/NucleusBiffBot) () |
2025-09-11 17:41:10 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-09-11 17:45:44 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 258 seconds) |
2025-09-11 17:46:03 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
2025-09-11 17:46:13 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
2025-09-11 17:47:50 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-11 17:48:00 +0200 | Googulator | (~Googulato@2a01-036d-0106-217b-fd1e-c506-2528-080c.pool6.digikabel.hu) |
2025-09-11 17:50:10 +0200 | MelodyOwO | (~MelodyOwO@user/MelodyOwO) MelodyOwO |
2025-09-11 18:03:43 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
2025-09-11 18:08:04 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 256 seconds) |
2025-09-11 18:13:16 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
2025-09-11 18:14:03 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) (Quit: Client closed) |
2025-09-11 18:15:10 +0200 | AndreiDuma | (~AndreiDum@user/AndreiDuma) AndreiDuma |
2025-09-11 18:15:51 +0200 | AndreiDuma | (~AndreiDum@user/AndreiDuma) (Client Quit) |
2025-09-11 18:15:58 +0200 | Enrico63 | (~Enrico63@2a0b:e541:10d0:0:9efc:e8ff:fe24:3213) Enrico63 |
2025-09-11 18:18:36 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) (Remote host closed the connection) |
2025-09-11 18:18:49 +0200 | humodz | (~humodz@user/humodz) humodz |
2025-09-11 18:19:09 +0200 | inline | (~inline@ip-005-146-196-014.um05.pools.vodafone-ip.de) Inline |
2025-09-11 18:20:57 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
2025-09-11 18:25:58 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
2025-09-11 18:27:46 +0200 | emperori | (~emperori@223.187.127.81) |
2025-09-11 18:39:54 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 18:40:12 +0200 | hellwolf | (~user@2f26-cc5a-24cf-d632-0f00-4d40-07d0-2001.sta.estpak.ee) (Ping timeout: 252 seconds) |
2025-09-11 18:45:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-09-11 18:45:25 +0200 | <EvanR> | and accursedUnutterablePerformIO? |
2025-09-11 18:46:07 +0200 | hellwolf | (~user@9629-38e7-765b-6e41-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
2025-09-11 18:46:42 +0200 | <geekosaur> | only if you want to share your address space with an imp 🙂 |
2025-09-11 18:53:32 +0200 | ft | (~ft@p4fc2a25a.dip0.t-ipconnect.de) ft |
2025-09-11 18:54:02 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
2025-09-11 18:54:16 +0200 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
2025-09-11 18:54:44 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
2025-09-11 18:56:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-11 18:56:55 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
2025-09-11 18:57:15 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
2025-09-11 18:58:32 +0200 | sprotte24 | (~sprotte24@p5dd5d928.dip0.t-ipconnect.de) |