2025/12/06

Newest at the top

2025-12-06 22:45:14 +0100gmg(~user@user/gehmehgeh) gehmehgeh
2025-12-06 22:44:13 +0100polux(~polux@51-15-169-172.rev.poneytelecom.eu) (Ping timeout: 244 seconds)
2025-12-06 22:43:21 +0100trickard_(~trickard@cpe-85-98-47-163.wireline.com.au)
2025-12-06 22:42:46 +0100trickard(~trickard@cpe-85-98-47-163.wireline.com.au) (Ping timeout: 244 seconds)
2025-12-06 22:42:07 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-12-06 22:38:13 +0100jmcantrell_(~weechat@user/jmcantrell) jmcantrell
2025-12-06 22:37:26 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-12-06 22:37:03 +0100 <hololeap> http://dpaste.com/BJFDH62NW
2025-12-06 22:36:19 +0100lambda_gibbon(~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11)
2025-12-06 22:35:56 +0100 <hololeap> it's the same error, so it doesn't seem to only be due to partial application
2025-12-06 22:35:30 +0100 <geekosaur> I think there's a [proposal for it, but it is actually hard given how ghc works iirc
2025-12-06 22:35:26 +0100 <hololeap> class (forall (m :: Maybe MatchMode). Ord (MatchLogic t m DepSpec))
2025-12-06 22:35:23 +0100 <hololeap> if I change it to:
2025-12-06 22:31:54 +0100 <hololeap> is this just a limitation of GHC? something that could be implemented in the future?
2025-12-06 22:31:25 +0100 <hololeap> I read here that "type synonym family" is just a type family: https://gitlab.haskell.org/ghc/ghc/-/issues/23860
2025-12-06 22:30:41 +0100lambda_gibbon(~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11) (Ping timeout: 256 seconds)
2025-12-06 22:30:04 +0100 <int-e> or a type synonym, as the error says; the story is the same: you can't use them partially applied
2025-12-06 22:28:20 +0100 <int-e> ...that MatchLogic is a 3 argument type family and you can't have partially applied type families.
2025-12-06 22:28:09 +0100 <hololeap> *Monad
2025-12-06 22:28:02 +0100 <hololeap> I'm trying to make it so that it enforces that any MatchLogic defined in an instance of IsDepSet must be a Mond
2025-12-06 22:28:00 +0100 <int-e> sorry
2025-12-06 22:27:57 +0100 <int-e> hololeap: my guess would be that http://dpaste.com/69GNP6AQJ
2025-12-06 22:27:12 +0100humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2025-12-06 22:26:42 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-12-06 22:26:24 +0100 <hololeap> source code: http://dpaste.com/69GNP6AQJ
2025-12-06 22:26:16 +0100 <hololeap> can someone help me understand this error? http://dpaste.com/F4ATVZPHF
2025-12-06 22:23:30 +0100lambda_gibbon(~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11)
2025-12-06 22:22:04 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-12-06 22:18:19 +0100 <[exa]> yushyin: thanks!
2025-12-06 22:18:12 +0100 <[exa]> interesting
2025-12-06 22:14:51 +0100 <davean> Lots of worry about a thing, but I never found the discussion of how they settled on that thing, etc
2025-12-06 22:13:47 +0100 <davean> but that wouldn't be as clean IMO
2025-12-06 22:13:40 +0100 <davean> One could also have a realtime thread for the renderer, but that wouldn't accomplish the restart portion, one could use something like hint for the config and update the datastructure for the renderer ...
2025-12-06 22:11:49 +0100lambda_gibbon(~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11) (Ping timeout: 260 seconds)
2025-12-06 22:10:59 +0100 <davean> and I was missing something huge reading the discussions about it
2025-12-06 22:10:45 +0100 <davean> It seemed like everyone got on the same page of how to go about those projects somewhere else that I couldn't find
2025-12-06 22:10:20 +0100 <davean> like I'd probably go about running a pauseless-GC renderer with a standard control process and make the control process restartable but the renderer not.
2025-12-06 22:09:39 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2025-12-06 22:09:38 +0100 <davean> I did see people worrying about pause times, but I didn't even see discussions of the pauseless GC or seperating out a rendering process from a control process or anything
2025-12-06 22:08:45 +0100 <davean> I didn't get deep enough into them to figure it out
2025-12-06 22:08:00 +0100 <davean> so very confused
2025-12-06 22:07:57 +0100 <davean> I didn't even see places it would differ from the automation
2025-12-06 22:07:43 +0100 <davean> Their custom Setup.hs stuff, all the hand done stuff for straight bindings ...
2025-12-06 22:05:16 +0100 <davean> it confused me
2025-12-06 22:05:13 +0100 <davean> I mean I looked at some of that code and I was lacking the context for why they went about it the way they did
2025-12-06 22:05:00 +0100lambda_gibbon(~lambda_gi@2603:7080:ee00:37d8:35d4:1aac:9a2f:cd11)
2025-12-06 22:04:44 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-12-06 22:02:48 +0100 <geekosaur> one would think, sadly that's exactly where waymonad and the new attempt failed. I don't know why either but suspect I won't do any better if I try to pick up e.g. the work done by the folks on discourse (look for "wlroots" and "tinywl-hs")
2025-12-06 22:00:48 +0100 <davean> I've not gotten into it much but I really have wondered whats going on with them running into issues with the parts I think should be the easy parts
2025-12-06 21:57:53 +0100 <davean> Every time I've looked in at waymonad I've been confused about the things they were running into issues with, like I don't get why they have issues with the bindings