Logs: liberachat/#xmonad
| 2025-10-24 15:31:48 | <liskin> | I think xquartz was rootless? |
| 2025-10-24 15:42:42 | <geekosaur> | supported both modes |
| 2025-10-24 15:43:28 | <geekosaur> | the biggest issue was the Core Graphics folks constantly changing or removing APIs needed for XQuartz to work… and to be quite honest I wouldn't bet on the core Wayland devs doing the same thing |
| 2025-10-24 15:50:28 | × | yecinem_ quits (~yecinem@p200300ee0f0876008e234cd803b8a022.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2025-10-24 17:19:56 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 17:28:04 | <Enrico63> | geekosaur, regarding my querstion, I've read through the logs. To summarize, xss-lock / xsecurelock is a solution, xlock / xautolock is another solution, whereas xscreensaver is an alternative solution on its own. Of these, xscreensaver used to be insecure but that's not the case anymore. xlock is still insecure, for the same reason xscreensaver |
| 2025-10-24 17:28:05 | <Enrico63> | was. Is it correct? |
| 2025-10-24 17:28:36 | <Enrico63> | Oh, liskin is online too :) |
| 2025-10-24 17:29:10 | <geekosaur> | Pretty much, yes |
| 2025-10-24 17:37:00 | <Enrico63> | But so I'd expect xlock and xss-lock to be listed together, as they are in https://wiki.archlinux.org/title/Session_lock, but xsecurelock is listed with them. Ok, I see why you say "pretty much". From https://github.com/google/xsecurelock I see that xsecurelock can be used with xscreensaver too. |
| 2025-10-24 17:57:31 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 18:19:06 | → | mathstuf joins (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) |
| 2025-10-24 18:20:34 | <mathstuf> | hi, im looking at splitting LayoutClass into a PureLayout class so that i can use the pure layouts to just tile some rectangles (the goal is to use xmonad layouts for river, see https://github.com/xmonad/xmonad/issues/525) |
| 2025-10-24 18:21:35 | <mathstuf> | however, when i make `instance PureLayout l a => LayoutClass l a`, i get overlapping instances (after adding UndecidableInstances extension) |
| 2025-10-24 18:22:15 | <mathstuf> | perhaps i should instead make `PureLayout` and `XLayout` and then have a class that is implemented for each? |
| 2025-10-24 18:22:28 | <mathstuf> | but i think that is still has issues because nothing stops a type from implementing both PureLayout and XLayout |
| 2025-10-24 18:23:23 | <mathstuf> | (my haskell is very rusty at this point) |
| 2025-10-24 18:31:55 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-24 18:55:30 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-24 19:49:04 | → | yauhsien joins (~Yau-Hsien@36-229-172-92.dynamic-ip.hinet.net) |
| 2025-10-24 19:51:02 | × | yauhsien quits (~Yau-Hsien@36-229-172-92.dynamic-ip.hinet.net) (Read error: Connection reset by peer) |
| 2025-10-24 19:51:37 | → | yauhsien joins (~Yau-Hsien@36-229-172-92.dynamic-ip.hinet.net) |
| 2025-10-24 20:04:35 | × | td_ quits (~td@2001:9e8:19e0:2a00:334f:6dc4:3cb7:9653) (Ping timeout: 244 seconds) |
| 2025-10-24 20:06:37 | → | td_ joins (~td@i53870931.versanet.de) |
| 2025-10-24 20:23:56 | × | yauhsien quits (~Yau-Hsien@36-229-172-92.dynamic-ip.hinet.net) (Quit: Leaving) |
| 2025-10-24 20:31:58 | × | mathstuf quits (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) (Ping timeout: 244 seconds) |
| 2025-10-24 21:24:57 | <geekosaur> | !tell mathstuf `LayoutClass l a` matches anything and would overlap with every other instance. The context does not act as a constraint on matching instances! It's only checked after choosing an instance. |
| 2025-10-25 01:24:23 | → | mathstuf joins (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) |
| 2025-10-25 01:24:43 | <Leary> | mathstuf: Ordinarily, you should write `newtype Pure l a = MkPure (l a); instance PureLayout l a => LayoutClass (Pure l) a` instead, then following the data declaration for a pure layout L: `deriving LayoutClass via Pure L`. However, I fear the bad type role of `X` will stymie this approach. |
| 2025-10-25 01:25:00 | <Leary> | To fix the type role, the newtypes over which `X` is written should be inlined into the `X` constructor, then the `deriving` clause for `(Functor, ..., MonadReader XConf)` done `via ReaderT XConf (StateT XState IO)`. |
| 2025-10-25 01:27:10 | <mathstuf> | thanks! ill take a look at that approach |
| 2025-10-25 02:32:51 | <mathstuf> | note that i am not sure that X is involved as PureLayout instances should not need to communicate with X |
| 2025-10-25 02:33:07 | <mathstuf> | but maybe compiler errors will guide me htere |
| 2025-10-25 02:33:12 | × | td_ quits (~td@i53870931.versanet.de) (Ping timeout: 252 seconds) |
| 2025-10-25 02:35:06 | → | td_ joins (~td@i5387091A.versanet.de) |
| 2025-10-25 02:50:09 | <geekosaur> | but LayoutClass does, since doLayout is in X |
| 2025-10-25 02:51:06 | <geekosaur> | which is why it would interfere with "deriving LayoutClass via" |
| 2025-10-25 02:55:35 | <mathstuf> | doLayout would stay in LayoutClass |
| 2025-10-25 02:55:50 | <geekosaur> | right, but you're deriving LayoutClass |
| 2025-10-25 02:56:09 | <mathstuf> | the default `doLayout` wouldnt suffice? |
| 2025-10-25 02:56:34 | <geekosaur> | that's not the question. the question is whether the type roles on X would pass muster with deriving-via |
| 2025-10-25 02:58:03 | <geekosaur> | ghc won't allow automatic deriving if a type variable involved has a `nominal` type role |
| 2025-10-25 02:59:15 | <geekosaur> | even if you would write the exact same instance yourself; you're assumed to know what you're doing, the compiler doesn't assume it knows what you're doing |
| 2025-10-25 03:15:15 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-10-25 03:28:02 | <mathstuf> | oh, not sure i was looking at `deriving` at all |
| 2025-10-25 03:28:24 | <mathstuf> | is `instance (PureLayout l a) => LayoutClass l a where …` not suitable? |
| 2025-10-25 03:29:16 | <Leary> | mathstuf: Check the logs in the topic for a line you missed. |
| 2025-10-25 03:30:20 | <mathstuf> | ah |
| 2025-10-25 03:31:20 | <mathstuf> | too much Rust :) |
| 2025-10-25 03:44:51 | × | redgloboli quits (~redglobol@user/redgloboli) (Quit: ...enter the matrix...) |
| 2025-10-25 03:46:28 | <geekosaur> | it does take some getting used to |
| 2025-10-25 03:46:30 | → | redgloboli joins (~redglobol@user/redgloboli) |
| 2025-10-25 03:46:48 | <geekosaur> | also, different FP languages have different solutions to the problem type roles solve here |
| 2025-10-25 03:47:57 | <geekosaur> | (one could in fact argue that type roles are a hack around Haskell's type system not being strong enough… but I don't think anyone gets this simultaneously right and practicably usable, except SML/NJ and OCaml in some situations) |
| 2025-10-25 03:49:18 | <mathstuf> | oh i did lots more haskell years ago (i contributed X.H.DynamicBars and X.H.ToggleHooks) |
| 2025-10-25 03:49:27 | <mathstuf> | though i admit i was not mucking with typeclasses that much there |
| 2025-10-25 03:49:48 | <geekosaur> | and I don't think type roles existed back then |
| 2025-10-25 03:50:23 | <geekosaur> | xmonad's core predates them by something like a decade, which is why we don't declare any type roles and therefore ghc takes the safe default of "nominal" |
| 2025-10-25 03:50:46 | <Leary> | No, even if you tried to declare a less restrictive role, GHC would reject it. |
| 2025-10-25 03:52:04 | <Leary> | The issue is that GHC has to give conservative roles to things like `ReaderT r f a` since `a` is under an unknown `f`, and `X` inherits the bad role from it. |
| 2025-10-25 03:52:57 | <Leary> | If GHC would look under the newtypes itself, it could re-infer `representable` after `f` is specialised to `IO`, alas ... |
| 2025-10-25 03:57:28 | <Leary> | Err, `representational`*. |
| 2025-10-25 04:01:13 | × | td_ quits (~td@i5387091A.versanet.de) (Ping timeout: 264 seconds) |
| 2025-10-25 04:02:40 | → | td_ joins (~td@i53870908.versanet.de) |
| 2025-10-25 05:01:53 | → | Enrico63 joins (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) |
| 2025-10-25 05:27:17 | × | mathstuf quits (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) (Ping timeout: 256 seconds) |
| 2025-10-25 06:18:11 | × | ft quits (~ft@p4fc2aaeb.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-10-25 06:24:18 | × | Enrico63 quits (~Enrico63@host-82-59-110-109.retail.telecomitalia.it) (Quit: Client closed) |
| 2025-10-25 11:10:23 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-10-25 11:23:39 | × | Leary quits (~Leary@user/Leary/x-0910699) (Remote host closed the connection) |
| 2025-10-25 11:34:07 | → | Leary joins (~Leary@user/Leary/x-0910699) |
| 2025-10-25 11:54:56 | → | ft joins (~ft@mue-88-130-106-235.dsl.tropolys.de) |
| 2025-10-25 11:59:25 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-10-25 12:29:32 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-10-25 14:46:23 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection timed out) |
| 2025-10-25 14:51:13 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-10-25 15:27:22 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds) |
| 2025-10-25 16:16:44 | → | L29Ah joins (~L29Ah@wikipedia/L29Ah) |
| 2025-10-25 16:28:00 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-10-25 21:00:21 | × | _qw quits (~eqw@user/eqw) (Ping timeout: 252 seconds) |
| 2025-10-25 21:25:26 | → | _qw joins (~eqw@user/eqw) |
| 2025-10-25 23:13:46 | × | td_ quits (~td@i53870908.versanet.de) (Ping timeout: 256 seconds) |
| 2025-10-25 23:15:41 | → | td_ joins (~td@i5387090B.versanet.de) |
| 2025-10-26 00:48:28 | → | mathstuf joins (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) |
| 2025-10-26 00:53:22 | × | ft quits (~ft@mue-88-130-106-235.dsl.tropolys.de) (Ping timeout: 240 seconds) |
| 2025-10-26 00:55:21 | → | ft joins (~ft@mue-88-130-106-050.dsl.tropolys.de) |
| 2025-10-26 01:34:31 | × | ft quits (~ft@mue-88-130-106-050.dsl.tropolys.de) (Ping timeout: 240 seconds) |
| 2025-10-26 01:36:40 | → | ft joins (~ft@mue-88-130-105-028.dsl.tropolys.de) |
| 2025-10-26 02:38:45 | × | mathstuf quits (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) (Ping timeout: 244 seconds) |
| 2025-10-26 02:40:16 | → | mathstuf joins (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) |
| 2025-10-26 03:45:02 | × | td_ quits (~td@i5387090B.versanet.de) (Ping timeout: 240 seconds) |
| 2025-10-26 03:47:17 | → | td_ joins (~td@i53870936.versanet.de) |
| 2025-10-26 03:58:02 | → | ChubaDuba joins (~ChubaDuba@176.212.36.137) |
| 2025-10-26 03:59:06 | × | ChubaDuba quits (~ChubaDuba@176.212.36.137) (Client Quit) |
| 2025-10-26 04:13:49 | <mathstuf> | it seems the roadblock is actually that `deriving` doesnt support binary constraings (LayoutClass) |
| 2025-10-26 04:27:42 | × | mathstuf quits (~mathstuf@c-73-130-147-217.hsd1.pa.comcast.net) (Ping timeout: 256 seconds) |
| 2025-10-26 04:48:09 | <Leary> | @tell mathstuf: Oops, try `StandaloneDeriving` instead: `deriving via Pure instance LayoutClass L a` |
| 2025-10-26 04:48:09 | <lambdabot> | Consider it noted. |
| 2025-10-26 05:32:23 | <haskellbridge> | <Primrose (== Léana)> Hello, |
| 2025-10-26 05:32:23 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/IeQlBrIYrwNctkEVlLuiYPvs/X0iwyh8Ww4k (3 lines) |
All times are in UTC.