IRCBrowse

2021/04/03

2021-04-03 00:16:02 +0200Shadorain(uid453914@gateway/web/irccloud.com/x-vkkeirbfznabxptu)
2021-04-03 01:04:23 +0200Buliarous(~gypsydang@unaffiliated/buliarous) (Ping timeout: 252 seconds)
2021-04-03 01:19:57 +0200srk(~sorki@gateway/tor-sasl/sorki) (Ping timeout: 240 seconds)
2021-04-03 01:21:14 +0200srk(~sorki@gateway/tor-sasl/sorki)
2021-04-03 01:21:15 +0200hacxman(~hexo@gateway/tor-sasl/hexo)
2021-04-03 01:21:57 +0200hexo(~hexo@gateway/tor-sasl/hexo) (Ping timeout: 240 seconds)
2021-04-03 01:21:58 +0200hacxmanhexo
2021-04-03 02:12:24 +0200ericsagn1(~ericsagne@2405:6580:0:5100:8e7d:1650:be7b:bbf2) (Ping timeout: 246 seconds)
2021-04-03 02:21:03 +0200mc47(~yecinem@196.179.170.230) (Remote host closed the connection)
2021-04-03 02:24:47 +0200ericsagn1(~ericsagne@2405:6580:0:5100:38ef:e5ed:8c96:cda5)
2021-04-03 02:34:25 +0200evanjs(~evanjs@075-129-098-007.res.spectrum.com) (Read error: Connection reset by peer)
2021-04-03 02:36:10 +0200evanjs(~evanjs@075-129-098-007.res.spectrum.com)
2021-04-03 02:51:06 +0200notis(~notis@185.51.134.222) (Ping timeout: 240 seconds)
2021-04-03 03:00:02 +0200gazler__(~gazler@195.107.2.81.in-addr.arpa)
2021-04-03 03:02:51 +0200gazler_(~gazler@195.107.2.81.in-addr.arpa) (Ping timeout: 268 seconds)
2021-04-03 04:07:19 +0200growpotk-(~growpotki@130-45-30-154.dyn.grandenetworks.net)
2021-04-03 04:35:34 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Read error: Connection reset by peer)
2021-04-03 04:35:56 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-04-03 04:50:02 +0200Shadorain(uid453914@gateway/web/irccloud.com/x-vkkeirbfznabxptu) (Quit: Connection closed for inactivity)
2021-04-03 04:53:50 +0200growpotk-(~growpotki@130-45-30-154.dyn.grandenetworks.net) (Ping timeout: 268 seconds)
2021-04-03 04:57:14 +0200theDon(~td@muedsl-82-207-238-162.citykom.de) (Ping timeout: 260 seconds)
2021-04-03 04:58:42 +0200theDon(~td@muedsl-82-207-238-112.citykom.de)
2021-04-03 05:05:54 +0200abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net)
2021-04-03 05:37:34 +0200ajc(~ajc@69.231.232.79) (Remote host closed the connection)
2021-04-03 05:37:58 +0200ajc(~ajc@69.231.232.79)
2021-04-03 05:44:09 +0200ericsagn1(~ericsagne@2405:6580:0:5100:38ef:e5ed:8c96:cda5) (Ping timeout: 246 seconds)
2021-04-03 05:57:21 +0200ericsagn1(~ericsagne@2405:6580:0:5100:d0a0:d77a:4eaa:16c)
2021-04-03 06:25:06 +0200coldpress(~coldpress@128.9.105.34.bc.googleusercontent.com) (Ping timeout: 240 seconds)
2021-04-03 06:52:00 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 06:53:59 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection)
2021-04-03 06:54:35 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 06:56:11 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection)
2021-04-03 06:57:15 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 06:58:12 +0200coldpress(~coldpress@128.9.105.34.bc.googleusercontent.com)
2021-04-03 07:19:19 +0200growpotkin(~growpotki@130-45-30-154.dyn.grandenetworks.net) (Quit: ZNC 1.8.2 - https://znc.in)
2021-04-03 07:23:27 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Quit: rcirc on GNU Emacs 27.2)
2021-04-03 07:24:15 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 07:52:50 +0200 <Solid> I probably missed the discussions around this, but why does `statusBarProp' take an 'X PP` and return something in IO?
2021-04-03 07:52:58 +0200palo1(~weechat@c-base/crew/palo)
2021-04-03 07:52:59 +0200 <Solid> this makes composition kind of awkward
2021-04-03 07:53:19 +0200 <Solid> well, in my case anyways
2021-04-03 07:53:28 +0200abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Quit: leaving)
2021-04-03 07:56:20 +0200palo(~weechat@c-base/crew/palo) (Ping timeout: 265 seconds)
2021-04-03 07:56:20 +0200palo1palo
2021-04-03 08:26:21 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection)
2021-04-03 08:29:07 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 08:34:15 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Remote host closed the connection)
2021-04-03 08:36:08 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net) (Read error: Connection reset by peer)
2021-04-03 08:37:02 +0200davemq(~davemq@99-179-0-50.lightspeed.austtx.sbcglobal.net)
2021-04-03 08:38:03 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 08:47:47 +0200thoros(~thoros@194-166-47-167.hdsl.highway.telekom.at)
2021-04-03 08:50:01 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com) (Ping timeout: 268 seconds)
2021-04-03 10:09:51 +0200 <mc47[m]> How so? That way all the statusBar functions have the same interface (at least with respect to the return type and the PP)
2021-04-03 10:32:38 +0200 <Liskni_si> on the other hand if we make statsuBarProp pure, it becomes easier to use than statusBarPipe which may nudge users towards not using pipes :-)
2021-04-03 10:33:37 +0200 <Liskni_si> anyway I just realized that withSB and withEasySB are unnecessarily IO, which would make composition awkward in my config :-)
2021-04-03 10:37:08 +0200materiyolo(~materiyol@112.204.174.249)
2021-04-03 10:45:07 +0200 <Liskni_si> hm, but by making statusBarProp pure, we'll be quite limited in what we can do there: it might be a good idea to identify dynamic status bars via Data.Unique rather than the command line, for example
2021-04-03 10:46:31 +0200 <Liskni_si> oh and since dynamicSBs is pure, withSB should definitely also be pure
2021-04-03 10:46:54 +0200 <Liskni_si> (and we might want to be consistent in the SB vs SBs thing too)
2021-04-03 10:47:29 +0200 <Solid> mc47[m]: http://ix.io/2UT2
2021-04-03 10:47:53 +0200 <Solid> maybe it's just my use-case, I don't know
2021-04-03 10:49:57 +0200 <Liskni_si> does <> work for Monoid a => IO a ?
2021-04-03 10:51:39 +0200 <Solid> IO has a Monoid a => Monoid (IO a) instance
2021-04-03 10:51:48 +0200 <Solid> I would guess it's just liftA2'ing (<>)
2021-04-03 10:52:06 +0200 <Liskni_si> then it'd probably be acceptable, yeah
2021-04-03 10:52:14 +0200 <Liskni_si> the relevant discussion was here: https://github.com/xmonad/xmonad-contrib/pull/443#discussion_r566106540
2021-04-03 10:53:02 +0200 <Liskni_si> and we apparently ended up somewhere in the middle: doesn't evaluate the SBC argument but still returns IO
2021-04-03 10:54:13 +0200 <Liskni_si> I'd personally prefer the variant that doesn't evaluate and doesn't return IO as I (intend to) compose withSB with docks and ewmh and withUrgency and other XConfig combinators
2021-04-03 10:54:29 +0200 <Liskni_si> but your config would benefit from the other variant
2021-04-03 10:56:54 +0200 <Liskni_si> (actually, I don't intend to use withSB at all, I'll have dynamicSBs the type of which is perfect now: evaluates but still manages to be pure to compose with other XConfig → XConfig stuff)
2021-04-03 10:56:55 +0200 <Solid> would it? something that takes a `PP` instead of an `X PP` and that doesn't return IO sounds exactly like what I want
2021-04-03 10:57:22 +0200 <Solid> or do you mean withSB shouldn't return IO
2021-04-03 10:57:24 +0200 <Liskni_si> it'd have to be X PP still but that's a minor detail
2021-04-03 10:57:39 +0200 <Solid> yeah that's not too bothersome
2021-04-03 10:58:06 +0200 <Liskni_si> oh, I think I was talking about withSB the whole time
2021-04-03 10:58:15 +0200 <Liskni_si> whereas you're talking about statusBarProp, sorry
2021-04-03 10:59:07 +0200 <Solid> ah I see
2021-04-03 10:59:34 +0200 <Solid> I have no opinion about withSB; for me that's just a matter of =<< vs. <$>
2021-04-03 11:00:33 +0200 <Liskni_si> well the idea was that if withSB is IO StatusBarConfig -> XConfig -> IO XConfig, your last config works as well
2021-04-03 11:00:46 +0200 <mc47[m]> Well I see your points, it would be better if we return a pure value in the statusBarProp
2021-04-03 11:01:10 +0200 <mc47[m]> It just wouldn't be usable the same way as
2021-04-03 11:01:48 +0200 <mc47[m]> statusBarPipe, which might be okay so users are nudged to the better alternative
2021-04-03 11:02:30 +0200 <mc47[m]> The IO in withSB is unnecessary, I forgot why I had it that way
2021-04-03 11:04:34 +0200 <mc47[m]> Liskin_si the problem with Data.Unique is that it doesn't have a Show instance, which means we can't persist it between restarts
2021-04-03 11:05:04 +0200 <Liskni_si> mc47[m]: oh
2021-04-03 11:13:09 +0200 <mc47[m]> I still think that we should keep X PP though
2021-04-03 11:14:39 +0200 <Liskni_si> we absolutely have to keep X PP
2021-04-03 11:15:13 +0200 <Solid> you can probably abuse Data.Unique.hashUnique and store that Int instead
2021-04-03 11:15:22 +0200 <Liskni_si> none of those clickablePP, dynamicIconsPP, workspaceNamesPP would work without X PP
2021-04-03 11:15:40 +0200 <Solid> you'll have a problem when the Ints wrap around but that's probably not going to be an issue for xmonad
2021-04-03 11:16:03 +0200 <Solid> oh but you can't construct back a unique
2021-04-03 11:16:04 +0200 <Solid> meh
2021-04-03 11:16:42 +0200 <Liskni_si> we don't really need an actual Unique, any global counter would be fine
2021-04-03 11:17:10 +0200 <mc47[m]> If people really need to launch the same command, they can always add a space to the end
2021-04-03 11:18:19 +0200 <Liskni_si> yeah, that's a good point
2021-04-03 11:38:17 +0200idhugo(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net)
2021-04-03 11:44:10 +0200materiyolo(~materiyol@112.204.174.249) (Read error: Connection reset by peer)
2021-04-03 11:46:26 +0200lchapoguzman(~manjaro-i@172.56.17.65)
2021-04-03 11:50:27 +0200idhugo(~idhugo@87-49-147-45-mobile.dk.customer.tdc.net) (Quit: Leaving)
2021-04-03 11:57:09 +0200mc47(~yecinem@196.179.170.230)
2021-04-03 12:01:33 +0200ericsagn1(~ericsagne@2405:6580:0:5100:d0a0:d77a:4eaa:16c) (Ping timeout: 258 seconds)
2021-04-03 12:09:11 +0200 <mc47> I'll push a PR so we have something concrete to evaluate
2021-04-03 12:13:33 +0200ericsagn1(~ericsagne@2405:6580:0:5100:4487:11af:62b0:68c1)
2021-04-03 13:03:05 +0200azg256(~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 13:32:26 +0200lchapoguzman(~manjaro-i@172.56.17.65) (Remote host closed the connection)
2021-04-03 13:33:02 +0200geekosaur(ac3a5331@172.58.83.49)
2021-04-03 13:53:11 +0200seschwar(~seschwar@unaffiliated/seschwar)
2021-04-03 14:51:29 +0200 <psibi[m]> Solid: Thanks for the org mode support, I'm already finding it quite handy!
2021-04-03 15:07:54 +0200azg256(~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 15:09:10 +0200azg256(~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 15:21:23 +0200materiyolo(~materiyol@112.204.174.249)
2021-04-03 15:30:29 +0200 <Solid> psibi[m]: awesome! I'm glad you like it :)
2021-04-03 15:30:43 +0200mc47(~yecinem@196.179.170.230) (Remote host closed the connection)
2021-04-03 15:30:51 +0200mc47(~yecinem@196.179.170.230)
2021-04-03 15:35:57 +0200hexo(~hexo@gateway/tor-sasl/hexo) (Ping timeout: 240 seconds)
2021-04-03 15:35:57 +0200srk(~sorki@gateway/tor-sasl/sorki) (Ping timeout: 240 seconds)
2021-04-03 15:50:28 +0200geekosaur(ac3a5331@172.58.83.49) (Quit: Connection closed)
2021-04-03 15:57:06 +0200seschwar(~seschwar@unaffiliated/seschwar) (Quit: :wq)
2021-04-03 15:57:37 +0200azg256(~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 15:58:28 +0200azg256(~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 16:09:36 +0200ericsagn1(~ericsagne@2405:6580:0:5100:4487:11af:62b0:68c1) (Ping timeout: 246 seconds)
2021-04-03 16:14:07 +0200Shadorain(uid453914@gateway/web/irccloud.com/x-cpxcxkqoopjeuddr)
2021-04-03 16:21:59 +0200ericsagn1(~ericsagne@2405:6580:0:5100:7445:6b92:4b01:cfc6)
2021-04-03 16:34:55 +0200mc47(~yecinem@196.179.170.230) (Remote host closed the connection)
2021-04-03 16:38:40 +0200azg256(~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 16:40:56 +0200azg256(~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 16:51:30 +0200rekahsoft(~rekahsoft@cpe0008a20f982f-cm64777d666260.cpe.net.cable.rogers.com)
2021-04-03 17:04:22 +0200azg256(~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 17:05:02 +0200azg256(~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 17:18:26 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net) (Remote host closed the connection)
2021-04-03 17:22:29 +0200_ashbreeze_(~mark@64.85.214.234.reverse.socket.net)
2021-04-03 17:29:04 +0200azg256(~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 17:29:54 +0200azg256(~azg256@78-56-98-5.static.zebra.lt)
2021-04-03 17:49:59 +0200Buliarous(~gypsydang@unaffiliated/buliarous)
2021-04-03 18:11:35 +0200qbit2821(~qbit2821@94-255-133-216.cust.bredband2.com)
2021-04-03 18:13:15 +0200qbit2821(~qbit2821@94-255-133-216.cust.bredband2.com) (Client Quit)
2021-04-03 18:17:02 +0200geekosaur(82650c7a@130.101.12.122)
2021-04-03 18:55:56 +0200ericsagn1(~ericsagne@2405:6580:0:5100:7445:6b92:4b01:cfc6) (Ping timeout: 258 seconds)
2021-04-03 18:59:51 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Quit: WeeChat 3.1)
2021-04-03 19:02:39 +0200thoros(~thoros@194-166-47-167.hdsl.highway.telekom.at) (Quit: WeeChat 3.0.1)
2021-04-03 19:07:46 +0200ericsagn1(~ericsagne@2405:6580:0:5100:1b1e:6b9b:245f:d5e2)
2021-04-03 19:22:13 +0200materiyolo(~materiyol@112.204.174.249) (Quit: WeeChat 3.0.1)
2021-04-03 19:31:40 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-04-03 19:34:17 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Client Quit)
2021-04-03 19:45:42 +0200geekosaur(82650c7a@130.101.12.122) (Ping timeout: 240 seconds)
2021-04-03 19:59:13 +0200geekosaur(82650c7a@130.101.12.122)
2021-04-03 20:21:54 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-04-03 20:23:41 +0200 <Liskni_si> Solid: although #501 is significantly less crap than it was at start, it's still way below our standard I'd say
2021-04-03 20:25:21 +0200 <Liskni_si> oh fuck I commented on some previous version of it
2021-04-03 20:25:24 +0200 <Liskni_si> fuck
2021-04-03 20:37:21 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 246 seconds)
2021-04-03 20:40:30 +0200seschwar(~seschwar@unaffiliated/seschwar)
2021-04-03 20:41:36 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-04-03 20:48:09 +0200 <Solid> Liskni_si: well I did miss some obvious bits
2021-04-03 20:48:15 +0200 <Solid> like ScreenId having an Integral instance
2021-04-03 20:48:51 +0200 <Solid> that's rather embarrassing
2021-04-03 20:50:21 +0200growpotkin(~growpotki@130-45-30-154.dyn.grandenetworks.net)
2021-04-03 20:52:07 +0200 <Solid> and yes it's still pretty bad
2021-04-03 20:52:54 +0200 <Solid> but someone once told me something about how first-time contributors benefit from having their first pr merged quickly-ish :P
2021-04-03 21:44:02 +0200 <Liskni_si> yeah it's a difficult trade-off, I still don't really know how to get it right :-/
2021-04-03 21:50:42 +0200abhixec(~abhixec@c-67-169-139-16.hsd1.ca.comcast.net)
2021-04-03 21:54:59 +0200xaltsc(~xaltsc@unaffiliated/xaltsc) (Ping timeout: 245 seconds)
2021-04-03 21:56:38 +0200 <mc47[m]> Solid: in general, but in this case they'll learn that they should take it slowly and write smaller first PRs :p
2021-04-03 21:57:11 +0200xaltsc(~xaltsc@unaffiliated/xaltsc)
2021-04-03 22:08:51 +0200azg256(~azg256@78-56-98-5.static.zebra.lt) (Quit: leaving)
2021-04-03 22:13:27 +0200seschwar(~seschwar@unaffiliated/seschwar) (Quit: :wq)
2021-04-03 22:18:49 +0200notis(~notis@185.51.134.222)
2021-04-03 22:23:49 +0200Shadorain(uid453914@gateway/web/irccloud.com/x-cpxcxkqoopjeuddr) (Quit: Connection closed for inactivity)
2021-04-03 22:49:31 +0200geekosaur(82650c7a@130.101.12.122) (Quit: Connection closed)
2021-04-03 23:35:10 +0200ericsagn1(~ericsagne@2405:6580:0:5100:1b1e:6b9b:245f:d5e2) (Ping timeout: 246 seconds)
2021-04-03 23:47:47 +0200ericsagn1(~ericsagne@2405:6580:0:5100:4c29:bb07:9985:fb29)
2021-04-03 23:50:51 +0200ADG1089(~aditya@223.235.216.238)
2021-04-03 23:51:28 +0200mc47(~yecinem@196.179.170.230)