IRCBrowse

2022/11/08

2022-11-08 00:01:49 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-08 00:02:27 +0100finsternis(~X@23.226.237.192) (Read error: Connection reset by peer)
2022-11-08 00:05:00 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 00:06:31 +0100causal(~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d)
2022-11-08 00:07:38 +0100abhiroop(~abhiroop@217-209-157-8-no2000.tbcn.telia.com)
2022-11-08 00:09:59 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 00:10:06 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-11-08 00:10:55 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Ping timeout: 260 seconds)
2022-11-08 00:11:26 +0100ph88(~ph88@2a02:8109:9e00:71d0:3734:2921:799c:a285) (Quit: Leaving)
2022-11-08 00:17:00 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 00:19:07 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:6245:cbff:fe9f:48b1) (Quit: Leaving)
2022-11-08 00:21:30 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2022-11-08 00:23:29 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-08 00:26:19 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds)
2022-11-08 00:26:49 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-11-08 00:26:55 +0100causal(~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0d) (Ping timeout: 252 seconds)
2022-11-08 00:28:25 +0100vn36(~vn36@123.63.203.210) (Ping timeout: 260 seconds)
2022-11-08 00:31:29 +0100freeside_(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 00:32:44 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 00:34:29 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-11-08 00:36:10 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de)
2022-11-08 00:38:50 +0100zeenk(~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494) (Quit: Konversation terminated!)
2022-11-08 00:40:14 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-08 00:40:18 +0100jmd_(~jmdaemon@user/jmdaemon)
2022-11-08 00:40:21 +0100causal(~user@50.35.83.177)
2022-11-08 00:40:54 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds)
2022-11-08 00:43:14 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-08 00:43:29 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 00:49:48 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 00:50:30 +0100ygsjg(~quassel@189.124.224.160)
2022-11-08 00:52:05 +0100acidjnk_new(~acidjnk@p200300d6e7137a80d16563246cd9a30d.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2022-11-08 00:52:08 +0100thegeekinside(~thegeekin@189.180.92.220)
2022-11-08 00:53:55 +0100zero(~z@user/zero)
2022-11-08 00:55:15 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-08 00:57:23 +0100yin(~z@user/zero) (Ping timeout: 268 seconds)
2022-11-08 01:04:49 +0100freeside_(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 01:10:39 +0100Tuplanolla(~Tuplanoll@91-159-69-11.elisa-laajakaista.fi) (Quit: Leaving.)
2022-11-08 01:11:46 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 01:14:05 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a)
2022-11-08 01:16:37 +0100tgi(~thegeekin@189.180.92.220)
2022-11-08 01:17:39 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 01:18:34 +0100thegeekinside(~thegeekin@189.180.92.220) (Ping timeout: 252 seconds)
2022-11-08 01:20:01 +0100thegeekinside(~thegeekin@189.180.92.220)
2022-11-08 01:23:01 +0100zeroyin
2022-11-08 01:23:34 +0100tgi(~thegeekin@189.180.92.220) (Ping timeout: 252 seconds)
2022-11-08 01:23:48 +0100tgi(~thegeekin@189.180.92.220)
2022-11-08 01:24:40 +0100thegeekinside(~thegeekin@189.180.92.220) (Ping timeout: 252 seconds)
2022-11-08 01:27:12 +0100thegeekinside(~thegeekin@189.180.92.220)
2022-11-08 01:29:44 +0100ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds)
2022-11-08 01:30:08 +0100beteigeuze1(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-08 01:30:20 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 01:30:29 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 260 seconds)
2022-11-08 01:30:29 +0100beteigeuze1beteigeuze
2022-11-08 01:30:50 +0100tgi(~thegeekin@189.180.92.220) (Ping timeout: 260 seconds)
2022-11-08 01:30:53 +0100ec_(~ec@gateway/tor-sasl/ec)
2022-11-08 01:36:00 +0100Feuermagier(~Feuermagi@user/feuermagier) (Remote host closed the connection)
2022-11-08 01:40:45 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2022-11-08 01:43:20 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) (Quit: Leaving)
2022-11-08 01:45:55 +0100yinzzz
2022-11-08 01:52:25 +0100barak(~barak@2a0d:6fc2:68c0:8900:b543:1b85:720f:c15) (Ping timeout: 260 seconds)
2022-11-08 01:56:44 +0100abhiroop(~abhiroop@217-209-157-8-no2000.tbcn.telia.com) (Ping timeout: 260 seconds)
2022-11-08 02:00:35 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2022-11-08 02:02:35 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 248 seconds)
2022-11-08 02:04:49 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds)
2022-11-08 02:08:03 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 02:11:07 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds)
2022-11-08 02:15:12 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-11-08 02:21:18 +0100fiddlerwoaroof(~fiddlerwo@user/fiddlerwoaroof) (Read error: Software caused connection abort)
2022-11-08 02:23:29 +0100glider(~glider@user/glider) (Read error: Software caused connection abort)
2022-11-08 02:24:10 +0100fiddlerwoaroof(~fiddlerwo@user/fiddlerwoaroof)
2022-11-08 02:24:19 +0100glider(~glider@user/glider)
2022-11-08 02:28:11 +0100xff0x(~xff0x@2405:6580:b080:900:a421:ba8e:4c73:4420) (Ping timeout: 248 seconds)
2022-11-08 02:28:19 +0100 <zzz> just a quick praise to everyone here for keeping this channel's spirit. great mood over the years, consistently
2022-11-08 02:28:43 +0100 <sm> nice zzz
2022-11-08 02:28:52 +0100 <sm> what would y'all say is the difference between LambdaCase and MultiWayIf, practically speaking ? Why would you choose one or the other ?
2022-11-08 02:29:34 +0100 <sm> ah, \case does pattern matching, \if matches true expressions
2022-11-08 02:29:39 +0100 <geekosaur> lambdacase is a partial workaround for not being able to do case matching on lambdas
2022-11-08 02:29:48 +0100 <geekosaur> yes
2022-11-08 02:30:38 +0100 <sm> thanks!
2022-11-08 02:31:01 +0100 <sm> I kept wanting to write \if, like \case.
2022-11-08 02:31:13 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-11-08 02:31:24 +0100 <monochrom> But MultiWayIf does not come with a lambda.
2022-11-08 02:31:31 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-11-08 02:31:56 +0100 <monochrom> But you can write "if|" :)
2022-11-08 02:32:27 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 248 seconds)
2022-11-08 02:32:28 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-11-08 02:32:41 +0100nate4(~nate@98.45.169.16)
2022-11-08 02:33:26 +0100 <sm> drat.. big set of choices here that are a mixture of truth and patterns...
2022-11-08 02:33:44 +0100 <zzz> sm: pattern guards?
2022-11-08 02:34:07 +0100 <zzz> f | Just x <- y , x = ...
2022-11-08 02:34:12 +0100 <sm> I expect so.. just a bit of work to see it clearly sometimes
2022-11-08 02:34:35 +0100 <sm> while manually shoving big blocks of code around
2022-11-08 02:35:02 +0100 <sm> yes that looks good, thank you
2022-11-08 02:36:34 +0100 <sm> wow.. this seems to work:
2022-11-08 02:36:34 +0100 <sm> | bool -> ...
2022-11-08 02:36:34 +0100 <sm> | Just val <- mval -> ...
2022-11-08 02:36:37 +0100 <monochrom> Compatible with MultiWayIf.
2022-11-08 02:37:34 +0100nate4(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2022-11-08 02:37:47 +0100Kaiepi(~Kaiepi@108.175.84.104) (Ping timeout: 248 seconds)
2022-11-08 02:38:02 +0100 <zzz> as long as you're not hoping others to read it :D
2022-11-08 02:39:52 +0100 <sm> well... I hope it'll be clearer overall in the end
2022-11-08 02:39:58 +0100 <yushyin> and now add MultiWayLambda to the mix
2022-11-08 02:40:09 +0100 <sm> and one can always comment
2022-11-08 02:40:10 +0100 <sm> MultiWayLambda you say..
2022-11-08 02:40:32 +0100 <sm> drat, can't have where embedded in multi-way if
2022-11-08 02:40:34 +0100 <monochrom> yikes haha
2022-11-08 02:41:10 +0100 <monochrom> Naw it would be an oxymoron.
2022-11-08 02:41:31 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds)
2022-11-08 02:43:15 +0100ss4(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2022-11-08 02:44:50 +0100sshine(~simon@exocortex.online) (Read error: Software caused connection abort)
2022-11-08 02:48:04 +0100 <sm> that's great.. haskell syntax is really clever. It takes some practice to remember the possibilities
2022-11-08 02:49:53 +0100 <maerwald[m]> sm: yes, people always jump heads on into type families and GADTs, but don't even understand basic haskell syntax :p
2022-11-08 02:50:06 +0100sshine(~simon@exocortex.online)
2022-11-08 02:50:41 +0100 <sm> FYI / mandatory readability check:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/07569b43dfb7ac6e8970567b52a168c99610…>)
2022-11-08 02:55:17 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 02:55:28 +0100meinside(uid24933@id-24933.helmsley.irccloud.com)
2022-11-08 02:56:06 +0100dagit(~dagit@2001:558:6025:38:6476:a063:d05a:44da) (Ping timeout: 255 seconds)
2022-11-08 02:56:10 +0100jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2022-11-08 02:56:26 +0100jinsun(~jinsun@user/jinsun)
2022-11-08 02:59:57 +0100another-axel-bee(~axel-bee@alexbenishek.com) (Read error: Software caused connection abort)
2022-11-08 03:00:05 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Ping timeout: 260 seconds)
2022-11-08 03:00:17 +0100axel-bee(~axel-bee@alexbenishek.com)
2022-11-08 03:01:41 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 03:01:48 +0100califax(~califax@user/califx) (Remote host closed the connection)
2022-11-08 03:02:35 +0100califax(~califax@user/califx)
2022-11-08 03:06:09 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 03:08:39 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2022-11-08 03:11:45 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-08 03:11:55 +0100 <zzz> you could do without multiwaif: https://paste.jrvieira.com/1667873477844
2022-11-08 03:13:26 +0100 <sm> if is a little clearer than repeating the var, I feel
2022-11-08 03:14:02 +0100 <zzz> also i have a typo. should be = intead of -> in the second example
2022-11-08 03:14:15 +0100 <monochrom> "where" doesn't work in all contexts.
2022-11-08 03:14:39 +0100 <sm> it still boggles my mind a little that ... <- ... can be used instead of a boolean here. I guess they are "guards", which can be either ?
2022-11-08 03:15:01 +0100califax(~califax@user/califx) (Remote host closed the connection)
2022-11-08 03:15:24 +0100califax(~califax@user/califx)
2022-11-08 03:15:34 +0100 <monochrom> MultiWayIf is really a guard syntax. And guard syntax allows pattern guards.
2022-11-08 03:16:13 +0100 <geekosaur> isn't it really short for `case () of () |`?
2022-11-08 03:16:34 +0100 <monochrom> Yes.
2022-11-08 03:16:46 +0100 <sm> 👍️
2022-11-08 03:16:50 +0100 <zzz> this is a style i enjoy: https://github.com/jrvieira/seis/blob/5396386b0a6e743c9b597532d1397d163f5b11cf/app/Main.hs#L120
2022-11-08 03:17:07 +0100Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2022-11-08 03:17:15 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 248 seconds)
2022-11-08 03:18:22 +0100Lord_of_Life_Lord_of_Life
2022-11-08 03:19:20 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Ping timeout: 260 seconds)
2022-11-08 03:25:03 +0100tgi(~thegeekin@189.180.92.220)
2022-11-08 03:25:59 +0100thegeekinside(~thegeekin@189.180.92.220) (Ping timeout: 260 seconds)
2022-11-08 03:28:27 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 03:28:54 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 03:32:33 +0100califax(~califax@user/califx) (Remote host closed the connection)
2022-11-08 03:32:59 +0100califax(~califax@user/califx)
2022-11-08 03:41:51 +0100berberman(~berberman@user/berberman)
2022-11-08 03:46:03 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 248 seconds)
2022-11-08 03:49:43 +0100raehik(~raehik@82.21.176.157)
2022-11-08 03:49:57 +0100zebrag(~chris@user/zebrag)
2022-11-08 03:52:30 +0100mshv22(~mshv22@76.115.19.239)
2022-11-08 03:53:13 +0100tcard(~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9) (Remote host closed the connection)
2022-11-08 03:58:07 +0100tcard(~tcard@2400:4051:5801:7500:19ce:ed82:2ab7:90f9)
2022-11-08 04:03:28 +0100ygsjg(~quassel@189.124.224.160) (Read error: Connection reset by peer)
2022-11-08 04:03:59 +0100ygsjg(~quassel@189.124.224.160)
2022-11-08 04:04:06 +0100mixfix41(~sdeny9ee@user/mixfix41)
2022-11-08 04:04:26 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.7.1)
2022-11-08 04:06:41 +0100raehik(~raehik@82.21.176.157) (Quit: WeeChat 3.7.1)
2022-11-08 04:09:12 +0100nineonine(~nineonine@2604:3d08:7780:cd00:997b:a50c:ac54:c195)
2022-11-08 04:13:29 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca)
2022-11-08 04:19:01 +0100td_(~td@83.135.9.26) (Ping timeout: 252 seconds)
2022-11-08 04:20:52 +0100td_(~td@83.135.9.57)
2022-11-08 04:21:25 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2022-11-08 04:23:45 +0100monaaraj(~MonAaraj@user/mon-aaraj/x-4416475)
2022-11-08 04:30:31 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2022-11-08 04:35:06 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 252 seconds)
2022-11-08 04:36:11 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 248 seconds)
2022-11-08 04:36:56 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2022-11-08 04:38:19 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 04:38:49 +0100talismanick(~talismani@76.133.152.122) (Ping timeout: 252 seconds)
2022-11-08 04:39:54 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2022-11-08 04:53:29 +0100sshine(~simon@exocortex.online) (Ping timeout: 260 seconds)
2022-11-08 04:53:37 +0100sshine(~simon@exocortex.online)
2022-11-08 04:53:44 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-11-08 04:54:27 +0100sagax(~sagax_nb@user/sagax)
2022-11-08 05:00:37 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-11-08 05:03:48 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 05:08:11 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 248 seconds)
2022-11-08 05:09:57 +0100king_gs(~Thunderbi@187.201.83.115)
2022-11-08 05:12:55 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-11-08 05:15:12 +0100bilegeek(~bilegeek@2600:1008:b04f:3c92:6adf:edcc:4896:94bb)
2022-11-08 05:18:10 +0100johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in)
2022-11-08 05:21:38 +0100mbuf(~Shakthi@49.205.82.149)
2022-11-08 05:21:58 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 05:28:57 +0100king_gs1(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 05:28:57 +0100king_gs(~Thunderbi@187.201.83.115) (Read error: Connection reset by peer)
2022-11-08 05:28:58 +0100king_gs1king_gs
2022-11-08 05:29:39 +0100mshv22(~mshv22@76.115.19.239) (Ping timeout: 260 seconds)
2022-11-08 05:30:30 +0100zebrag(~chris@user/zebrag) (Quit: Konversation terminated!)
2022-11-08 05:33:27 +0100mshv22(~mshv22@76.115.19.239)
2022-11-08 05:33:30 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-08 05:37:44 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 05:41:40 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 05:46:48 +0100mshv22(~mshv22@76.115.19.239) (Remote host closed the connection)
2022-11-08 05:47:11 +0100mshv22(~mshv22@76.115.19.239)
2022-11-08 05:47:11 +0100mshv22(~mshv22@76.115.19.239) (Client Quit)
2022-11-08 05:47:37 +0100mshv22(~mshv22@76.115.19.239)
2022-11-08 05:48:58 +0100vn36(~vn36@123.63.203.210)
2022-11-08 05:49:03 +0100Feuermagier(~Feuermagi@user/feuermagier)
2022-11-08 05:51:08 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 05:53:55 +0100vn36(~vn36@123.63.203.210) (Ping timeout: 260 seconds)
2022-11-08 05:54:08 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2022-11-08 05:55:54 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 05:57:20 +0100 <jackdk> I too like writing in the 404 style
2022-11-08 06:02:40 +0100byorgey(~byorgey@155.138.238.211) (Read error: Software caused connection abort)
2022-11-08 06:03:10 +0100krjst(~krjst@2604:a880:800:c1::16b:8001) (Read error: Software caused connection abort)
2022-11-08 06:04:22 +0100krjst(~krjst@2604:a880:800:c1::16b:8001)
2022-11-08 06:04:25 +0100cytokine_storm(~cytokine_@user/cytokine-storm/x-1083107)
2022-11-08 06:08:09 +0100ygsjg(~quassel@189.124.224.160) (Ping timeout: 260 seconds)
2022-11-08 06:08:22 +0100byorgey(~byorgey@155.138.238.211)
2022-11-08 06:08:38 +0100ygsjg(~quassel@189.124.224.160)
2022-11-08 06:09:12 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg)
2022-11-08 06:09:46 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Remote host closed the connection)
2022-11-08 06:10:05 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 06:16:54 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Ping timeout: 260 seconds)
2022-11-08 06:20:05 +0100sabx(~sabbas@user/sabbas) (Ping timeout: 246 seconds)
2022-11-08 06:21:07 +0100cytokine_storm(~cytokine_@user/cytokine-storm/x-1083107) (Ping timeout: 252 seconds)
2022-11-08 06:23:48 +0100barak(~barak@2a0d:6fc2:68c0:8900:b543:1b85:720f:c15)
2022-11-08 06:26:52 +0100 <zzz> oops: https://paste.jrvieira.com/1667885201583
2022-11-08 06:30:53 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca)
2022-11-08 06:34:13 +0100nate4(~nate@98.45.169.16)
2022-11-08 06:37:54 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Ping timeout: 255 seconds)
2022-11-08 06:37:59 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2022-11-08 06:40:35 +0100nate4(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2022-11-08 06:42:10 +0100razetime(~quassel@117.254.34.130)
2022-11-08 06:58:00 +0100sagax(~sagax_nb@user/sagax) (Read error: Connection reset by peer)
2022-11-08 06:58:14 +0100sagax(~sagax_nb@user/sagax)
2022-11-08 06:59:15 +0100razetime(~quassel@117.254.34.130) (Ping timeout: 260 seconds)
2022-11-08 06:59:23 +0100Ybombinator(~Ybombinat@85.254.75.39)
2022-11-08 06:59:51 +0100razetime(~quassel@117.254.35.109)
2022-11-08 07:00:54 +0100 <Ybombinator> Hi, (I'm on mobile data so sorry if I disconnect) what are type classes and type class constraints useful for in variables? I understand how they might be useful for functions but why not assign specific types for variables instead of type classes?
2022-11-08 07:01:20 +0100 <Axman6> do you have an example?
2022-11-08 07:01:42 +0100 <Ybombinator> what do you mean? of what?
2022-11-08 07:02:04 +0100 <Axman6> I'm not sure what you mean by your question
2022-11-08 07:02:28 +0100 <Ybombinator> what are type classes useful for in variables, why are they used?
2022-11-08 07:03:40 +0100 <Axman6> :t let addSeven x = let seven = (7 :: Num a => a) in x + seven in addSeven -- like this?
2022-11-08 07:03:41 +0100 <lambdabot> Num a => a -> a
2022-11-08 07:04:10 +0100 <Ybombinator> I know literals have type classes with restrictions, for example, type signature of 7 is "7 :: Num p => p" not "7 :: Int"
2022-11-08 07:04:19 +0100 <Ybombinator> but why?
2022-11-08 07:04:52 +0100 <Axman6> the literal "7" actually means "fromInteger (7 :: Integer)" - it's part of the language definition
2022-11-08 07:05:04 +0100mshv22(~mshv22@76.115.19.239) (Ping timeout: 252 seconds)
2022-11-08 07:05:05 +0100 <Axman6> maybe a better example is:
2022-11-08 07:05:39 +0100 <Axman6> :t read "8" -- generic in what type can be returned (but might fail at runtime if you can't parse "8" as the type you want
2022-11-08 07:05:40 +0100 <lambdabot> Read a => a
2022-11-08 07:06:20 +0100 <Axman6> > let r8 = (read 8 :: Read a => a) in (r8 :: Int, r8 :: Double, r8 :: Bool)
2022-11-08 07:06:21 +0100 <lambdabot> error:
2022-11-08 07:06:21 +0100 <lambdabot> • Could not deduce (Num String) arising from the literal ‘8’
2022-11-08 07:06:21 +0100 <lambdabot> from the context: Read a
2022-11-08 07:06:37 +0100 <Axman6> > let r8 = (read "8" :: Read a => a) in (r8 :: Int, r8 :: Double, r8 :: Bool)
2022-11-08 07:06:39 +0100 <lambdabot> (8,8.0,*Exception: Prelude.read: no parse
2022-11-08 07:08:34 +0100pepeiborra(sid443799@id-443799.ilkley.irccloud.com) (Read error: Software caused connection abort)
2022-11-08 07:08:38 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2022-11-08 07:08:45 +0100pepeiborra(sid443799@id-443799.ilkley.irccloud.com)
2022-11-08 07:09:07 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 07:10:04 +0100razetime(~quassel@117.254.35.109) (Ping timeout: 252 seconds)
2022-11-08 07:10:23 +0100 <Ybombinator> I didn't know about the fromInteger thing, thanks
2022-11-08 07:11:42 +0100 <Axman6> :t 7 <> mempty <> 8
2022-11-08 07:11:43 +0100 <lambdabot> (Num a, Monoid a) => a
2022-11-08 07:11:54 +0100 <Axman6> :t 7 <> mempty <> 8 :: Sum Integer
2022-11-08 07:11:55 +0100 <lambdabot> Sum Integer
2022-11-08 07:12:01 +0100 <Axman6> :t 7 <> mempty <> 8 :: Product Double
2022-11-08 07:12:03 +0100 <lambdabot> Product Double
2022-11-08 07:12:08 +0100 <Axman6> > 7 <> mempty <> 8 :: Product Double
2022-11-08 07:12:09 +0100 <lambdabot> Product {getProduct = 56.0}
2022-11-08 07:12:13 +0100 <Axman6> > 7 <> mempty <> 8 :: Product Double
2022-11-08 07:12:14 +0100 <lambdabot> Product {getProduct = 56.0}
2022-11-08 07:12:15 +0100 <Axman6> urgh
2022-11-08 07:12:45 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-08 07:21:12 +0100chomwitt(~chomwitt@2a02:587:7a0a:c00:1ac0:4dff:fedb:a3f1)
2022-11-08 07:22:28 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-11-08 07:22:53 +0100mbuf(~Shakthi@49.205.82.149) (Read error: Connection reset by peer)
2022-11-08 07:23:49 +0100razetime(~quassel@117.254.35.109)
2022-11-08 07:23:50 +0100mbuf(~Shakthi@49.205.82.149)
2022-11-08 07:30:44 +0100ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2022-11-08 07:31:11 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de)
2022-11-08 07:33:34 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2022-11-08 07:33:54 +0100razetime(~quassel@117.254.35.109) (Ping timeout: 260 seconds)
2022-11-08 07:34:05 +0100razetime(~quassel@117.193.2.237)
2022-11-08 07:37:10 +0100barak(~barak@2a0d:6fc2:68c0:8900:b543:1b85:720f:c15) (Quit: Leaving)
2022-11-08 07:42:31 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-11-08 07:43:04 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2022-11-08 07:43:41 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds)
2022-11-08 07:46:44 +0100Dykam(Dykam@dykam.nl) (Ping timeout: 248 seconds)
2022-11-08 07:47:06 +0100Dykam(Dykam@dykam.nl)
2022-11-08 07:47:22 +0100manwithl-(~manwithlu@194.177.28.176)
2022-11-08 07:48:52 +0100manwithluck(~manwithlu@194.177.28.176) (Ping timeout: 248 seconds)
2022-11-08 07:49:11 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-11-08 07:49:34 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2022-11-08 07:50:05 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer)
2022-11-08 07:53:08 +0100niko(niko@libera/staff/niko) (Ping timeout: 620 seconds)
2022-11-08 07:56:11 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-11-08 07:56:25 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds)
2022-11-08 07:57:05 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer)
2022-11-08 07:57:38 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 255 seconds)
2022-11-08 07:59:06 +0100chexum(~quassel@gateway/tor-sasl/chexum)
2022-11-08 08:03:13 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-11-08 08:04:06 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer)
2022-11-08 08:05:10 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Ping timeout: 260 seconds)
2022-11-08 08:08:12 +0100kenran(~user@user/kenran)
2022-11-08 08:09:30 +0100o(niko@libera/staff/niko)
2022-11-08 08:09:51 +0100oniko
2022-11-08 08:10:01 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 252 seconds)
2022-11-08 08:10:13 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-11-08 08:11:07 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer)
2022-11-08 08:13:04 +0100nineonine(~nineonine@2604:3d08:7780:cd00:997b:a50c:ac54:c195) (Remote host closed the connection)
2022-11-08 08:17:13 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-11-08 08:18:07 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Read error: Connection reset by peer)
2022-11-08 08:20:01 +0100zeenk(~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494)
2022-11-08 08:20:30 +0100machinedgod(~machinedg@clnet-p10-126.ikbnet.co.at)
2022-11-08 08:23:51 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-11-08 08:24:14 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2022-11-08 08:28:50 +0100jonathanx__(~jonathan@h-178-174-176-109.A357.priv.bahnhof.se) (Ping timeout: 246 seconds)
2022-11-08 08:36:49 +0100mncheck(~mncheck@193.224.205.254)
2022-11-08 08:37:04 +0100nate4(~nate@98.45.169.16)
2022-11-08 08:37:50 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2022-11-08 08:39:10 +0100razetime_(~quassel@117.193.2.237)
2022-11-08 08:39:10 +0100razetime_(~quassel@117.193.2.237) (Client Quit)
2022-11-08 08:39:11 +0100vglfr(~vglfr@145.224.100.100) (Read error: Connection reset by peer)
2022-11-08 08:39:24 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 08:40:24 +0100jonathanx(~jonathan@h-98-128-168-222.NA.cust.bahnhof.se)
2022-11-08 08:40:31 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-08 08:41:30 +0100nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-11-08 08:41:51 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 08:47:21 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2022-11-08 08:47:59 +0100razetime(~quassel@117.193.2.237) (Ping timeout: 260 seconds)
2022-11-08 08:48:39 +0100jtomas(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net)
2022-11-08 08:52:11 +0100mixfix41(~sdeny9ee@user/mixfix41) (Ping timeout: 248 seconds)
2022-11-08 08:52:52 +0100dagit(~dagit@2001:558:6025:38:6476:a063:d05a:44da)
2022-11-08 08:54:25 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2022-11-08 08:55:15 +0100michalz(~michalz@185.246.207.200)
2022-11-08 09:02:34 +0100sagax(~sagax_nb@user/sagax) (Ping timeout: 260 seconds)
2022-11-08 09:03:37 +0100razetime(~quassel@117.193.2.237)
2022-11-08 09:04:47 +0100bilegeek_(~bilegeek@242.sub-174-209-38.myvzw.com)
2022-11-08 09:07:35 +0100bilegeek(~bilegeek@2600:1008:b04f:3c92:6adf:edcc:4896:94bb) (Ping timeout: 260 seconds)
2022-11-08 09:07:46 +0100shriekingnoise(~shrieking@186.137.167.202) (Quit: Quit)
2022-11-08 09:08:59 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:7915:4565:2a54:1342)
2022-11-08 09:10:22 +0100acidjnk_new(~acidjnk@p200300d6e7137a80d16563246cd9a30d.dip0.t-ipconnect.de)
2022-11-08 09:11:05 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-11-08 09:11:19 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-08 09:11:45 +0100dagit(~dagit@2001:558:6025:38:6476:a063:d05a:44da) (Remote host closed the connection)
2022-11-08 09:11:46 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de) (Quit: leaving)
2022-11-08 09:11:55 +0100dagit(~dagit@2001:558:6025:38:6476:a063:d05a:44da)
2022-11-08 09:12:48 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a)
2022-11-08 09:13:33 +0100dagit(~dagit@2001:558:6025:38:6476:a063:d05a:44da) (Remote host closed the connection)
2022-11-08 09:14:53 +0100dagit(~dagit@2001:558:6025:38:6476:a063:d05a:44da)
2022-11-08 09:16:28 +0100bilegeek_(~bilegeek@242.sub-174-209-38.myvzw.com) (Quit: Leaving)
2022-11-08 09:16:35 +0100Kaiepi(~Kaiepi@108.175.84.104)
2022-11-08 09:17:49 +0100Batzy(~quassel@user/batzy)
2022-11-08 09:18:05 +0100Batzy(~quassel@user/batzy) (Client Quit)
2022-11-08 09:20:52 +0100sagax(~sagax_nb@user/sagax)
2022-11-08 09:22:16 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 09:23:03 +0100MajorBiscuit(~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl)
2022-11-08 09:26:59 +0100elkcl(~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru) (Read error: Connection reset by peer)
2022-11-08 09:27:07 +0100elkcl(~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru)
2022-11-08 09:33:07 +0100Batzy(~quassel@user/batzy)
2022-11-08 09:34:04 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de) (Ping timeout: 260 seconds)
2022-11-08 09:36:59 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 260 seconds)
2022-11-08 09:37:12 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2022-11-08 09:38:09 +0100razetime(~quassel@117.193.2.237) (Ping timeout: 260 seconds)
2022-11-08 09:38:47 +0100razetime(~quassel@117.193.2.237)
2022-11-08 09:39:22 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 09:40:02 +0100vn36(~vn36@123.63.203.210)
2022-11-08 09:42:02 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 09:42:19 +0100Guest75(~Guest75@178.141.177.81)
2022-11-08 09:42:19 +0100odnes(~odnes@5-203-252-50.pat.nym.cosmote.net)
2022-11-08 09:46:00 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 09:47:25 +0100cfricke(~cfricke@user/cfricke)
2022-11-08 09:47:29 +0100niko(niko@libera/staff/niko) (Ping timeout: 615 seconds)
2022-11-08 09:49:57 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de)
2022-11-08 09:50:27 +0100kuribas(~user@ptr-17d51eo9spiq814cpsf.18120a2.ip6.access.telenet.be)
2022-11-08 09:51:18 +0100odnes(~odnes@5-203-252-50.pat.nym.cosmote.net) (Quit: Leaving)
2022-11-08 09:51:24 +0100jonathanx(~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Remote host closed the connection)
2022-11-08 09:51:34 +0100danza(~francesco@45.red-79-153-2.dynamicip.rima-tde.net)
2022-11-08 09:51:42 +0100jonathanx(~jonathan@h-98-128-168-222.NA.cust.bahnhof.se)
2022-11-08 10:00:06 +0100aviladev[m](~aviladevm@2001:470:69fc:105::1:cbc7) (Quit: You have been kicked for being idle)
2022-11-08 10:00:07 +0100Neosake[m](~neosakema@2001:470:69fc:105::2:989e) (Quit: You have been kicked for being idle)
2022-11-08 10:01:13 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7)
2022-11-08 10:02:55 +0100nschoe(~q@2a01:e0a:8e:a190:819d:bc04:2515:8096)
2022-11-08 10:03:04 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Remote host closed the connection)
2022-11-08 10:08:07 +0100thyriaen(~thyriaen@2a01:aea0:dd4:470d:4c78:c477:402b:896a) (Remote host closed the connection)
2022-11-08 10:08:40 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de) (Remote host closed the connection)
2022-11-08 10:09:41 +0100chele(~chele@user/chele)
2022-11-08 10:10:23 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-08 10:10:27 +0100o(niko@libera/staff/niko)
2022-11-08 10:10:55 +0100oniko
2022-11-08 10:11:57 +0100Neuromancer(~Neuromanc@user/neuromancer)
2022-11-08 10:13:09 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-08 10:14:24 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2022-11-08 10:18:35 +0100sudden(~cat@user/sudden) (Ping timeout: 248 seconds)
2022-11-08 10:19:07 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2022-11-08 10:19:39 +0100sudden(~cat@user/sudden)
2022-11-08 10:22:01 +0100emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2022-11-08 10:22:26 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 10:24:16 +0100potash_(~foghorn@94-225-47-8.access.telenet.be) (Remote host closed the connection)
2022-11-08 10:24:39 +0100__monty__(~toonn@user/toonn)
2022-11-08 10:25:22 +0100vglfr(~vglfr@145.224.100.100) (Read error: Connection reset by peer)
2022-11-08 10:26:02 +0100potash(~foghorn@user/foghorn)
2022-11-08 10:26:39 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 10:33:34 +0100razetime(~quassel@117.193.2.237) (Ping timeout: 260 seconds)
2022-11-08 10:33:51 +0100 <kuribas> I wonder if garbage collection is really much worse than manual management.
2022-11-08 10:33:57 +0100razetime(~quassel@117.193.2.237)
2022-11-08 10:33:58 +0100 <kuribas> allocating data also is expensive.
2022-11-08 10:34:19 +0100 <kuribas> This article only shows 30% decrease because of garbage collection: https://blog.akquinet.de/2021/01/03/haskell-is-faster-than-rust-wait-a-sec/
2022-11-08 10:34:37 +0100 <kuribas> Except of course when you have lots of live data.
2022-11-08 10:35:04 +0100 <kuribas> But are the added headaches of rust memory management worth it for small gains?
2022-11-08 10:42:27 +0100 <merijn> kuribas: No, in many common usecases GC outperforms manual memory management
2022-11-08 10:42:37 +0100 <merijn> because most people are terrible at manual memory management
2022-11-08 10:42:50 +0100 <merijn> And write horribly inefficient malloc nonsense
2022-11-08 10:43:10 +0100 <dminuoso> More importantly GC outperforms *error-free* memory management by roughly 100%
2022-11-08 10:43:19 +0100vn36(~vn36@123.63.203.210) (Quit: leaving)
2022-11-08 10:43:53 +0100 <dminuoso> There's just too many programmers precoccupied by performance, when in reality 99% of the situations are not in bottlenecks, and by doing manual management they tend to introduce memory bugs every 20 lines of code (number is not real/up-to-scale)
2022-11-08 10:44:12 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7)
2022-11-08 10:45:22 +0100econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2022-11-08 10:46:35 +0100 <dminuoso> And I think any comparison of "GC vs non-GC" is difficult especially when you have handpicked a) the languages, b) the GC implementation and c) the software to benchmark against. You can, at best, compare a particular GC implementation with a particular code that assumes some of the semantics of that GC, against a particular non-GC-style code
2022-11-08 10:47:24 +0100CiaoSen(~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-11-08 10:47:55 +0100 <dminuoso> But that wont tell you much about the question "Is GC generally and or not?"
2022-11-08 10:56:57 +0100 <kuribas> merijn: that's what I would expect.
2022-11-08 11:02:29 +0100 <kuribas> merijn: malloc isn't cheap either.
2022-11-08 11:02:31 +0100teo(~teo@user/teo)
2022-11-08 11:03:17 +0100 <merijn> malloc is super expensive
2022-11-08 11:03:33 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 11:05:12 +0100 <dminuoso> I wonder, on linux does malloc yield the scheduler?
2022-11-08 11:07:21 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2022-11-08 11:07:39 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 248 seconds)
2022-11-08 11:07:55 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Ping timeout: 252 seconds)
2022-11-08 11:11:31 +0100biberu(~biberu@user/biberu) (Ping timeout: 252 seconds)
2022-11-08 11:11:58 +0100 <merijn> dminuoso: It Depends (TM)
2022-11-08 11:12:18 +0100ubert1(~Thunderbi@178.115.49.179.wireless.dyn.drei.com)
2022-11-08 11:12:37 +0100 <Athas> Wait, why would it yield?
2022-11-08 11:12:50 +0100 <Athas> I mean in a multi-threaded environment where the malloc() lock is held, sure, but in general?
2022-11-08 11:13:29 +0100 <merijn> Athas: even single threaded if you do a syscall you might yield, no?
2022-11-08 11:13:41 +0100ubert(~Thunderbi@91.141.75.105.wireless.dyn.drei.com) (Ping timeout: 246 seconds)
2022-11-08 11:13:41 +0100ubert1ubert
2022-11-08 11:14:17 +0100 <Athas> merijn: I don't think syscalls necessarily involve yielding.
2022-11-08 11:14:35 +0100 <Athas> And many calls to malloc() should not require syscalls.
2022-11-08 11:14:35 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 248 seconds)
2022-11-08 11:15:13 +0100 <merijn> Athas: I just said it *might*
2022-11-08 11:15:37 +0100 <Franciman> lol
2022-11-08 11:15:44 +0100 <Franciman> ops sorry, wrong chat
2022-11-08 11:16:36 +0100 <Maxdamantus> preemption should be a much more frequent cause for yielding.
2022-11-08 11:16:56 +0100 <Athas> Well, everything might yield, but it has more to do with the time slice being up than anything you're doing.
2022-11-08 11:18:56 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 246 seconds)
2022-11-08 11:19:09 +0100 <dminuoso> Athas: So if memory serves right, a lot of syscalls will at their end implicitly call into the scheduler, a kind of implicit cooperation
2022-11-08 11:19:48 +0100 <dminuoso> Without it, you would get quite horrid latency since otherwise every execution would get (on most default installations) 4ms of uninterrupted CPU time.
2022-11-08 11:20:03 +0100 <dminuoso> Im just not sure which syscalls this actually applies to
2022-11-08 11:22:39 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-11-08 11:23:48 +0100comerijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 11:24:11 +0100 <Maxdamantus> What does 4 ms correspond to? system calls are often much faster than that.
2022-11-08 11:24:30 +0100 <dminuoso> Maxdamantus: Most distributions configure preemption frequency to 250Hz
2022-11-08 11:25:15 +0100 <Maxdamantus> Sure, but system calls can be much more frequent than that (I'd usually expect in the order of a few MHz)
2022-11-08 11:25:34 +0100 <Maxdamantus> $ dd if=/dev/zero bs=1 of=/dev/null count=1M
2022-11-08 11:25:35 +0100 <Maxdamantus> 1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.302947 s, 3.5 MB/s
2022-11-08 11:25:48 +0100 <Maxdamantus> that's 7 million system calls per second.
2022-11-08 11:26:04 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-08 11:26:20 +0100 <dminuoso> Right, and that's what Im saying. System calls produce implicit yields, so amongst some other things, at the end of (some?) system calls the scheduler is called.
2022-11-08 11:27:03 +0100 <dminuoso> I just dont have reliable information whether a) this applies to all system calls, and b) what that interaction actually is (its presumably not an actual sched_yield, since that will unconditionally move the task to the end of the list)
2022-11-08 11:28:02 +0100 <dminuoso> Otoh, if you are doing number crunching a tight cpu loop, that does mean you will - in the absence of interrupts - get up to 4ms of uninterrupted CPU time
2022-11-08 11:28:28 +0100 <dminuoso> (well, "interrupts" heh. I mean the preempt timer generates interrupts)
2022-11-08 11:29:14 +0100 <Maxdamantus> So what's the difference in latency between 4 ms of uninterrupted CPU time in user space vs. 4 ms of unterrupted CPU time in user/kernel space?
2022-11-08 11:29:56 +0100 <dminuoso> Im just pointing out, that if you are in a tight cpu loop without syscalls, this can actually degrade system performance.
2022-11-08 11:30:06 +0100 <dminuoso> because the preempt frequency is that low.
2022-11-08 11:30:23 +0100 <dminuoso> the preempt frequencies are low because its assumed most software will frequently do system calls
2022-11-08 11:30:41 +0100 <dminuoso> and it turns out, if you do a fast sysenter you may not have to do a TLB flush
2022-11-08 11:31:10 +0100 <dminuoso> which makes it *much* faster than calling the scheduler via a timer IRQ
2022-11-08 11:31:22 +0100shailangsa(~shailangs@host109-159-108-137.range109-159.btcentralplus.com)
2022-11-08 11:32:01 +0100 <Maxdamantus> I imagine if there's an advantage to yielding in system calls, it probably has more to do with the fact that you've already left user space (switching contexts), so there isn't as much performance advantage in switching back to that specific context.
2022-11-08 11:32:16 +0100 <dminuoso> Maxdamantus: no the advantage is saving interrupt costs.
2022-11-08 11:32:41 +0100 <Maxdamantus> you mean context switching costs?
2022-11-08 11:32:47 +0100 <dminuoso> No interrupt costs.
2022-11-08 11:33:22 +0100 <dminuoso> So back in the old days to do a syscall, you would actually explicitly cause an interrupt (on linux this would be interrupted 0x80)
2022-11-08 11:33:40 +0100 <dminuoso> But interrupts have quite a bit of costs attached to them (because you must store and restore execution context)
2022-11-08 11:34:13 +0100 <dminuoso> for that reason, AMD and Intel have introduced SYSENTER and SYSCALL instructions, which provide a way to do fast interrupt free jumps to specific prepared handlers
2022-11-08 11:37:27 +0100 <dminuoso> So with that in place, it turns out that making frequent syscalls is cheap - so with that its been observed that software can very liberally and frequently do syscalls. Now, since a syscall is just kernel code, we can use the fact that we're already in kernel code, and just verify whether we should perhaps yield to the scheduler. If we for example assumed this would happen every 100 microseconds,
2022-11-08 11:37:29 +0100 <dminuoso> this would give us timeslices of up to 100 microseconds, but without having to program the APIC timer and inducing costly interrupts every 100 microseconds
2022-11-08 11:40:09 +0100 <dminuoso> Plus, even if there are costs attached, the thing is once we have a syscall - that cost is paid for already anyway.
2022-11-08 11:40:21 +0100 <dminuoso> Might as well do additional kernel work while we're in the kernel. :)
2022-11-08 11:40:39 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 260 seconds)
2022-11-08 11:40:52 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2022-11-08 11:42:55 +0100zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2022-11-08 11:42:59 +0100razetime(~quassel@117.193.2.237) (Ping timeout: 260 seconds)
2022-11-08 11:43:03 +0100razetime_(~quassel@117.193.2.237)
2022-11-08 11:44:05 +0100zaquest(~notzaques@5.130.79.72)
2022-11-08 11:46:50 +0100zmt00(~zmt00@user/zmt00) (Ping timeout: 260 seconds)
2022-11-08 11:47:07 +0100tgi(~thegeekin@189.180.92.220) (Ping timeout: 248 seconds)
2022-11-08 11:48:47 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-08 11:53:29 +0100jpds1(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2022-11-08 11:54:02 +0100jpds1(~jpds@gateway/tor-sasl/jpds)
2022-11-08 11:56:58 +0100xff0x(~xff0x@2405:6580:b080:900:88f3:132d:4c04:2bb3)
2022-11-08 11:59:39 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 12:02:07 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-08 12:04:23 +0100jtomas(~jtomas@191.red-88-17-199.dynamicip.rima-tde.net) (Quit: Leaving)
2022-11-08 12:05:59 +0100hsw(~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving)
2022-11-08 12:10:54 +0100chele_(~chele@user/chele)
2022-11-08 12:13:26 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 252 seconds)
2022-11-08 12:13:46 +0100cstml(~cstml@user/cstml)
2022-11-08 12:13:54 +0100chele(~chele@user/chele) (Ping timeout: 260 seconds)
2022-11-08 12:16:14 +0100Neuromancer(~Neuromanc@user/neuromancer) (Ping timeout: 260 seconds)
2022-11-08 12:20:37 +0100 <APic> ♥
2022-11-08 12:20:54 +0100vglfr(~vglfr@145.224.100.100) (Ping timeout: 260 seconds)
2022-11-08 12:21:56 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 12:28:29 +0100__monty__(~toonn@user/toonn) (Ping timeout: 260 seconds)
2022-11-08 12:28:43 +0100__monty__(~toonn@user/toonn)
2022-11-08 12:33:46 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-11-08 12:35:25 +0100machinedgod(~machinedg@clnet-p10-126.ikbnet.co.at) (Remote host closed the connection)
2022-11-08 12:38:13 +0100nate4(~nate@98.45.169.16)
2022-11-08 12:42:16 +0100Ybombinator(~Ybombinat@85.254.75.39) (Ping timeout: 252 seconds)
2022-11-08 12:42:53 +0100nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-11-08 12:43:26 +0100 <dminuoso> Heh that name. :)
2022-11-08 12:46:01 +0100cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.7.1)
2022-11-08 12:47:01 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq)
2022-11-08 12:55:02 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-08 12:55:12 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Quit: beteigeuze)
2022-11-08 12:55:44 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-08 12:57:53 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 12:58:17 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Client Quit)
2022-11-08 12:58:27 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 12:58:31 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt)
2022-11-08 12:58:44 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 13:00:03 +0100 <ephemient> sadly syscalls are no longer cheap due to software mitigations for hardware vulnerabilities (e.g. https://www.kernel.org/doc/html/latest/x86/pti.html flushes page tables on enter and exit)
2022-11-08 13:00:12 +0100biberu(~biberu@user/biberu)
2022-11-08 13:00:20 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 13:04:52 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 13:05:35 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 13:05:36 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 13:06:24 +0100teo(~teo@user/teo) (Ping timeout: 260 seconds)
2022-11-08 13:06:35 +0100teo(~teo@user/teo)
2022-11-08 13:10:15 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Ping timeout: 260 seconds)
2022-11-08 13:11:47 +0100arjun(~arjun@205.254.175.154)
2022-11-08 13:12:10 +0100arjun(~arjun@205.254.175.154) (Changing host)
2022-11-08 13:12:10 +0100arjun(~arjun@user/arjun)
2022-11-08 13:14:34 +0100ubert(~Thunderbi@178.115.49.179.wireless.dyn.drei.com) (Ping timeout: 260 seconds)
2022-11-08 13:15:00 +0100ubert(~Thunderbi@178.115.49.179.wireless.dyn.drei.com)
2022-11-08 13:15:35 +0100 <dminuoso> ephemient: Thats not entirely true.
2022-11-08 13:15:57 +0100 <dminuoso> You dont flush the entire TLB
2022-11-08 13:16:17 +0100 <dminuoso> At least not when PCID is supported
2022-11-08 13:16:55 +0100 <dminuoso> With a PCID TLB flush you can flush only the kernel page table entries
2022-11-08 13:17:24 +0100arjun(~arjun@user/arjun) (Quit: Leaving)
2022-11-08 13:17:47 +0100CiaoSen(~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2022-11-08 13:18:57 +0100 <dminuoso> But yes, non non-PCID capable systems, with PTI enabled, each syscall/interruption/exception will do a complete TLB flush.
2022-11-08 13:19:10 +0100 <dminuoso> (Which presumably can induce extreme performance penalties)
2022-11-08 13:20:08 +0100Guest75(~Guest75@178.141.177.81) (Quit: Client closed)
2022-11-08 13:21:21 +0100bjourne(~bjourne@2001:6b0:1:1140:42bf:ff4:f8fa:50e5) (Read error: Connection reset by peer)
2022-11-08 13:24:17 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 13:24:48 +0100kenran`(~user@user/kenran)
2022-11-08 13:25:01 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 13:26:08 +0100abhiroop(~abhiroop@ext-1-450.eduroam.chalmers.se)
2022-11-08 13:29:11 +0100kenran`(~user@user/kenran) (Remote host closed the connection)
2022-11-08 13:30:40 +0100abhiroop(~abhiroop@ext-1-450.eduroam.chalmers.se) (Ping timeout: 260 seconds)
2022-11-08 13:38:11 +0100abhiroop(~abhiroop@ext-1-450.eduroam.chalmers.se)
2022-11-08 13:39:48 +0100machinedgod(~machinedg@clnet-p10-126.ikbnet.co.at)
2022-11-08 13:42:20 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds)
2022-11-08 13:45:27 +0100zmt00(~zmt00@user/zmt00)
2022-11-08 13:46:53 +0100rembo10(~rembo10@main.remulis.com) (Quit: ZNC 1.8.2 - https://znc.in)
2022-11-08 13:49:03 +0100rembo10(~rembo10@main.remulis.com)
2022-11-08 13:52:34 +0100Neuromancer(~Neuromanc@user/neuromancer)
2022-11-08 13:53:06 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 13:53:45 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 13:59:32 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2022-11-08 14:00:07 +0100Guest75(~Guest75@178.141.177.81)
2022-11-08 14:03:39 +0100bjourne(~bjourne@2001:6b0:1:1140:42bf:ff4:f8fa:50e5)
2022-11-08 14:05:10 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 14:05:16 +0100Guest88(~Guest88@2001:e68:5470:3aaa:b978:4b50:ca1f:1e9b)
2022-11-08 14:06:03 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 14:06:32 +0100Guest88(~Guest88@2001:e68:5470:3aaa:b978:4b50:ca1f:1e9b) (Client Quit)
2022-11-08 14:17:31 +0100jmd_(~jmdaemon@user/jmdaemon) (Ping timeout: 248 seconds)
2022-11-08 14:19:04 +0100bcmiller(~bm3719@66.42.95.185) ()
2022-11-08 14:22:47 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-08 14:23:12 +0100moneypolo
2022-11-08 14:25:21 +0100cfricke(~cfricke@user/cfricke)
2022-11-08 14:25:23 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-08 14:25:55 +0100Techcable(~Techcable@user/Techcable) (Remote host closed the connection)
2022-11-08 14:28:36 +0100Techcable(~Techcable@user/Techcable)
2022-11-08 14:34:13 +0100 <freeside> so, i have just found myself doing `(fmap . fmap) myfunction <$> ...` Is there some idiom by which I can avoid quite so many fmaps?
2022-11-08 14:35:01 +0100 <kuribas> freeside: Compose?
2022-11-08 14:35:43 +0100 <freeside> do you mean Data.Functor.Compose?
2022-11-08 14:35:45 +0100 <kuribas> > fmap (+1) (Compose [Just 1, Nothing])
2022-11-08 14:35:46 +0100 <lambdabot> error:
2022-11-08 14:35:46 +0100 <lambdabot> • Data constructor not in scope: Compose :: [Maybe a0] -> f b
2022-11-08 14:35:46 +0100 <lambdabot> • Perhaps you meant variable ‘icompose’ (imported from Control.Lens)
2022-11-08 14:35:52 +0100 <kuribas> yes
2022-11-08 14:36:01 +0100 <freeside> i need to go learn Lens. :-o
2022-11-08 14:36:09 +0100 <kuribas> > fmap (+1) (Data.Functor.Compose [Just 1, Nothing])
2022-11-08 14:36:10 +0100 <lambdabot> error:
2022-11-08 14:36:10 +0100 <lambdabot> Not in scope: data constructor ‘Data.Functor.Compose’
2022-11-08 14:36:10 +0100 <lambdabot> No module named ‘Data.Functor’ is imported.
2022-11-08 14:36:30 +0100 <kuribas> freeside: Compose is not in lens...
2022-11-08 14:38:59 +0100 <dminuoso> freeside: You can also just write `fmap2 = fmap . fmap` and then proceed to use that.
2022-11-08 14:39:21 +0100 <dminuoso> Which is what I frequently do, it's usually more ergonomic than roundtripping through Compose
2022-11-08 14:40:00 +0100 <dminuoso> Making these types of surrogate bindings take minimal effort
2022-11-08 14:40:38 +0100 <freeside> that makes sense. I just didn't want to be inventing my own idioms if there was already an accepted way of doing that
2022-11-08 14:41:39 +0100 <freeside> i mean, we have zip, zip3, we have liftA, liftA2, liftA3
2022-11-08 14:42:04 +0100cfricke(~cfricke@user/cfricke) (Ping timeout: 260 seconds)
2022-11-08 14:44:17 +0100cfricke(~cfricke@user/cfricke)
2022-11-08 14:46:31 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2022-11-08 14:53:54 +0100doyougnu(~doyougnu@cpe-74-69-132-225.stny.res.rr.com)
2022-11-08 15:00:28 +0100acidjnk_new3(~acidjnk@p200300d6e7137a91c8a7e6211d36bcc5.dip0.t-ipconnect.de)
2022-11-08 15:00:50 +0100acidjnk_new(~acidjnk@p200300d6e7137a80d16563246cd9a30d.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2022-11-08 15:01:25 +0100abhiroop(~abhiroop@ext-1-450.eduroam.chalmers.se) (Ping timeout: 252 seconds)
2022-11-08 15:04:35 +0100freeside(~mengwong@bb115-66-48-84.singnet.com.sg) (Ping timeout: 260 seconds)
2022-11-08 15:06:08 +0100freeside(~mengwong@103.252.202.193)
2022-11-08 15:13:22 +0100comerijnmerijn
2022-11-08 15:17:38 +0100thegeekinside(~thegeekin@189.180.92.220)
2022-11-08 15:18:40 +0100Guest75(~Guest75@178.141.177.81) (Quit: Client closed)
2022-11-08 15:19:32 +0100ksu(~ksu@user/prtr)
2022-11-08 15:20:35 +0100shriekingnoise(~shrieking@186.137.167.202)
2022-11-08 15:21:27 +0100abhiroop(~abhiroop@ext-1-450.eduroam.chalmers.se)
2022-11-08 15:23:56 +0100CiaoSen(~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2022-11-08 15:25:40 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-11-08 15:25:56 +0100Guest75(~Guest75@178.141.177.81)
2022-11-08 15:26:24 +0100teo(~teo@user/teo) (Ping timeout: 260 seconds)
2022-11-08 15:26:24 +0100__monty__(~toonn@user/toonn) (Ping timeout: 260 seconds)
2022-11-08 15:26:24 +0100cstml(~cstml@user/cstml) (Ping timeout: 260 seconds)
2022-11-08 15:26:39 +0100__monty__(~toonn@user/toonn)
2022-11-08 15:26:46 +0100cstml(~cstml@cpc151611-shef16-2-0-cust313.17-1.cable.virginm.net)
2022-11-08 15:26:59 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Ping timeout: 260 seconds)
2022-11-08 15:33:34 +0100xilo(~xilo@84.32.165.17)
2022-11-08 15:33:44 +0100vglfr(~vglfr@145.224.100.100) (Read error: Connection reset by peer)
2022-11-08 15:34:08 +0100teo(~teo@user/teo)
2022-11-08 15:35:04 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 15:35:33 +0100xilo(~xilo@84.32.165.17) ()
2022-11-08 15:40:11 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 15:40:54 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 15:41:27 +0100vglfr(~vglfr@145.224.100.100) (Remote host closed the connection)
2022-11-08 15:43:38 +0100vglfr(~vglfr@145.224.100.100)
2022-11-08 15:48:05 +0100Sauvin(~sauvin@user/Sauvin) (Read error: Connection reset by peer)
2022-11-08 15:48:52 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-11-08 15:49:29 +0100Sauvin(~sauvin@user/Sauvin)
2022-11-08 15:53:54 +0100igghibu(~igghibu@37.120.201.87)
2022-11-08 15:54:54 +0100abhiroop(~abhiroop@ext-1-450.eduroam.chalmers.se) (Ping timeout: 252 seconds)
2022-11-08 15:55:02 +0100Sgeo(~Sgeo@user/sgeo)
2022-11-08 15:56:40 +0100jakalx(~jakalx@base.jakalx.net) ()
2022-11-08 15:58:17 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2022-11-08 16:01:59 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-08 16:12:33 +0100king_gs(~Thunderbi@187.201.83.115)
2022-11-08 16:16:57 +0100mikoto-chan(~mikoto-ch@164.5.249.78)
2022-11-08 16:17:01 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 252 seconds)
2022-11-08 16:21:51 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-11-08 16:32:19 +0100Techcable(~Techcable@user/Techcable) (Ping timeout: 260 seconds)
2022-11-08 16:34:12 +0100Techcable(~Techcable@user/Techcable)
2022-11-08 16:36:01 +0100king_gs(~Thunderbi@187.201.83.115) (Read error: Connection reset by peer)
2022-11-08 16:36:31 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 16:36:59 +0100 <bjourne> anyone know how to use custom error types in alex/happy? String appears to be hardcoded...
2022-11-08 16:38:01 +0100causal(~user@50.35.83.177) (Quit: WeeChat 3.7.1)
2022-11-08 16:38:45 +0100mikoto-chan(~mikoto-ch@164.5.249.78) (Quit: WeeChat 3.6)
2022-11-08 16:39:16 +0100CiaoSen(~Jura@p200300c9571247002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-11-08 16:39:20 +0100mikoto-chan(~mikoto-ch@164.5.249.78)
2022-11-08 16:39:45 +0100nate4(~nate@98.45.169.16)
2022-11-08 16:40:31 +0100ygsjg(~quassel@189.124.224.160) (Read error: Connection reset by peer)
2022-11-08 16:44:55 +0100santiagopim(~user@90.167.66.131)
2022-11-08 16:44:55 +0100nate4(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2022-11-08 16:46:43 +0100cfricke(~cfricke@user/cfricke) (Ping timeout: 252 seconds)
2022-11-08 16:47:44 +0100 <bjourne> they are https://github.com/haskell/alex/issues/178
2022-11-08 16:48:37 +0100 <Hecate> looks like you have to pester ericson2314 about https://github.com/haskell/alex/pull/174
2022-11-08 16:48:55 +0100 <ericson2314> hehehe
2022-11-08 16:49:09 +0100 <ericson2314> I screwed up the parser combinators
2022-11-08 16:49:51 +0100 <Hecate> ericson2314: wanna pair on that?
2022-11-08 16:50:04 +0100 <Hecate> maybe with bjourne so that some knowledge is transmitted outside of the inner circle
2022-11-08 16:50:19 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Ping timeout: 252 seconds)
2022-11-08 16:50:19 +0100machinedgod(~machinedg@clnet-p10-126.ikbnet.co.at) (Ping timeout: 252 seconds)
2022-11-08 16:52:42 +0100cfricke(~cfricke@user/cfricke)
2022-11-08 16:53:03 +0100 <ericson2314> Hecate: yeah maybe :)
2022-11-08 16:53:22 +0100 <ericson2314> I need to catch up on some regular work things this week or so
2022-11-08 16:53:23 +0100 <ericson2314> but then I should have more bandwidth for other stuff
2022-11-08 16:53:33 +0100shailangsa(~shailangs@host109-159-108-137.range109-159.btcentralplus.com) (Remote host closed the connection)
2022-11-08 16:53:41 +0100 <ericson2314> I did try to get a few admin tasks on alex/happy done over the weekend
2022-11-08 16:54:58 +0100shof(~shof@user/shof)
2022-11-08 16:55:47 +0100irrgit(~irrgit@146.70.27.250)
2022-11-08 16:56:59 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:7915:4565:2a54:1342) (Quit: WeeChat 2.8)
2022-11-08 16:59:09 +0100igghibu(~igghibu@37.120.201.87) (Quit: Textual IRC Client: www.textualapp.com)
2022-11-08 17:01:50 +0100mikoto-chan(~mikoto-ch@164.5.249.78) (Ping timeout: 260 seconds)
2022-11-08 17:03:41 +0100slack1256(~slack1256@191.126.227.81)
2022-11-08 17:06:30 +0100polomoney
2022-11-08 17:08:48 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 17:09:52 +0100 <slack1256> On the async package, it is recommended to use withAsync whenever possible to get a tree thread structure. This works well for statically known amounts of threads. What about for an unknown but bounded amount of threads? So far I am using `catch` and `link` to get the same semantics, but maybe it can be done better?
2022-11-08 17:11:38 +0100 <geekosaur> https://hackage.haskell.org/package/async-pool ?
2022-11-08 17:12:19 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 252 seconds)
2022-11-08 17:13:08 +0100cfricke(~cfricke@user/cfricke) (Ping timeout: 248 seconds)
2022-11-08 17:13:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Ping timeout: 260 seconds)
2022-11-08 17:16:00 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Remote host closed the connection)
2022-11-08 17:16:20 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 17:17:35 +0100jonathanx(~jonathan@h-98-128-168-222.NA.cust.bahnhof.se) (Remote host closed the connection)
2022-11-08 17:18:11 +0100 <bjourne> this haskell doesn't like [line, col] = getAllTextMatches (err =~ "[0-9]+") :: [String]
2022-11-08 17:20:20 +0100 <geekosaur> @where paste
2022-11-08 17:20:20 +0100 <lambdabot> Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com
2022-11-08 17:20:30 +0100 <geekosaur> include context and the error message
2022-11-08 17:25:31 +0100 <slack1256> geekosaur: this!
2022-11-08 17:28:04 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2022-11-08 17:28:22 +0100slac77925(~slack1256@191.125.227.88)
2022-11-08 17:29:23 +0100L29Ah(~L29Ah@wikipedia/L29Ah) ()
2022-11-08 17:30:39 +0100slack1256(~slack1256@191.126.227.81) (Ping timeout: 260 seconds)
2022-11-08 17:34:49 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2022-11-08 17:37:08 +0100abhiroop(~abhiroop@217-209-157-8-no2000.tbcn.telia.com)
2022-11-08 17:37:39 +0100teo(~teo@user/teo) (Ping timeout: 260 seconds)
2022-11-08 17:38:39 +0100teo(~teo@user/teo)
2022-11-08 17:42:51 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds)
2022-11-08 17:44:42 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2022-11-08 17:47:47 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Ping timeout: 246 seconds)
2022-11-08 17:49:18 +0100acidjnk_new3(~acidjnk@p200300d6e7137a91c8a7e6211d36bcc5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-11-08 17:49:40 +0100monaaraj(~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 252 seconds)
2022-11-08 17:51:14 +0100Bocaneri(~sauvin@user/Sauvin)
2022-11-08 17:51:21 +0100Sauvin(~sauvin@user/Sauvin) (Remote host closed the connection)
2022-11-08 17:51:28 +0100segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2022-11-08 17:51:38 +0100BocaneriGuest6797
2022-11-08 17:51:41 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de)
2022-11-08 17:51:57 +0100monaaraj(~MonAaraj@user/mon-aaraj/x-4416475)
2022-11-08 17:53:01 +0100slack1256(~slack1256@191.125.227.81)
2022-11-08 17:55:10 +0100slac77925(~slack1256@191.125.227.88) (Ping timeout: 252 seconds)
2022-11-08 17:58:07 +0100segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Read error: Connection reset by peer)
2022-11-08 18:02:31 +0100xilo(~xilo@84.32.165.17)
2022-11-08 18:04:53 +0100NehaPassiveIncom(~NehaPassi@2409:4089:211:37ff:8190:ef69:5139:1fa8)
2022-11-08 18:05:58 +0100 <NehaPassiveIncom> https://earnbysellinginternetpack.blogspot.com
2022-11-08 18:06:01 +0100NehaPassiveIncom(~NehaPassi@2409:4089:211:37ff:8190:ef69:5139:1fa8) (Client Quit)
2022-11-08 18:07:48 +0100 <geekosaur> sadly, can't delete messages on irc like you can on matrix…
2022-11-08 18:09:26 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 18:10:44 +0100Guest75(~Guest75@178.141.177.81) (Quit: Client closed)
2022-11-08 18:11:50 +0100MajorBiscuit(~MajorBisc@c-001-009-026.client.tudelft.eduvpn.nl) (Ping timeout: 260 seconds)
2022-11-08 18:12:00 +0100 <EvanR> sounds like a client problem xD
2022-11-08 18:12:28 +0100 <EvanR> (would be nice to delete message at least for your own self xD)
2022-11-08 18:12:41 +0100 <geekosaur> there's also the question of how you';d signal it to clients in the protocol
2022-11-08 18:13:36 +0100 <EvanR> yeah deleting messages on other people's client sounds like a big ask
2022-11-08 18:15:08 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2022-11-08 18:15:36 +0100abhiroop_(~abhiroop@217-209-157-8-no2000.tbcn.telia.com)
2022-11-08 18:15:42 +0100kuribas(~user@ptr-17d51eo9spiq814cpsf.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 27.1))
2022-11-08 18:16:04 +0100abhiroop(~abhiroop@217-209-157-8-no2000.tbcn.telia.com) (Ping timeout: 252 seconds)
2022-11-08 18:16:09 +0100 <geekosaur> flip side, doing IRC admin stuff is a massive pain from matrix, which is a large part of why I haven't migrated to element
2022-11-08 18:16:17 +0100king_gs(~Thunderbi@187.201.83.115)
2022-11-08 18:16:36 +0100 <geekosaur> (except on my phone)
2022-11-08 18:17:48 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de) (Quit: Leaving.)
2022-11-08 18:18:17 +0100razetime_(~quassel@117.193.2.237) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-11-08 18:21:27 +0100slack1256(~slack1256@191.125.227.81) (Read error: Connection reset by peer)
2022-11-08 18:22:54 +0100slack1256(~slack1256@186.11.28.28)
2022-11-08 18:23:04 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-11-08 18:24:19 +0100mikoto-chan(~mikoto-ch@164.5.249.78)
2022-11-08 18:26:23 +0100danso(danso@2600:3c03::f03c:91ff:fe05:6954) (Quit: ZNC - https://znc.in)
2022-11-08 18:27:26 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-08 18:27:40 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 18:27:51 +0100Guest6797Sauvin
2022-11-08 18:27:55 +0100danso(~danso@danso.ca)
2022-11-08 18:28:24 +0100 <ski> @type \cases -> ()
2022-11-08 18:28:25 +0100 <lambdabot> p -> ()
2022-11-08 18:29:13 +0100 <dolio> Weird.
2022-11-08 18:29:34 +0100monaaraj(~MonAaraj@user/mon-aaraj/x-4416475) (Ping timeout: 260 seconds)
2022-11-08 18:29:47 +0100mikoto-chan(~mikoto-ch@164.5.249.78) (Ping timeout: 248 seconds)
2022-11-08 18:30:02 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
2022-11-08 18:30:12 +0100 <geekosaur> ?
2022-11-08 18:30:40 +0100incertia(~incertia@209.122.71.127)
2022-11-08 18:31:07 +0100 <EvanR> cases is a new syntax that lambdabot doesn't know about yet?
2022-11-08 18:31:32 +0100 <[exa]> looks to me like a binding that it didn't see yet? :]
2022-11-08 18:32:14 +0100 <geekosaur> lambdabot is 9.0.1 last I checked, not 9.4
2022-11-08 18:32:43 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 18:33:05 +0100 <geekosaur> there's some updates needed for it to be upgraded (including some dependencies)
2022-11-08 18:33:20 +0100 <[exa]> oh noes there's a new keyword?
2022-11-08 18:33:23 +0100 <geekosaur> I think someone's trying to take over the deps so they can be upgraded
2022-11-08 18:33:53 +0100 <geekosaur> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst
2022-11-08 18:33:59 +0100 <yushyin> [exa]: just an extension to lambdacase, multiway lambdas!
2022-11-08 18:36:04 +0100litharge(litharge@libera/bot/litharge) (Quit: restarting)
2022-11-08 18:36:28 +0100litharge(litharge@libera/bot/litharge)
2022-11-08 18:36:32 +0100mbuf(~Shakthi@49.205.82.149) (Quit: Leaving)
2022-11-08 18:37:15 +0100abhiroop_(~abhiroop@217-209-157-8-no2000.tbcn.telia.com) (Ping timeout: 248 seconds)
2022-11-08 18:38:22 +0100 <ski> "Unlike `case', `cases' is not a keyword. Only the token sequence `\ cases' is treated specially (more precisely, lexically, `cases' is a varid rather than a reservedid, and it may be used as a variable).)
2022-11-08 18:39:27 +0100Kaipei(~Kaiepi@108.175.84.104)
2022-11-08 18:40:38 +0100king_gs(~Thunderbi@187.201.83.115) (Ping timeout: 246 seconds)
2022-11-08 18:42:45 +0100Kaiepi(~Kaiepi@108.175.84.104) (Ping timeout: 260 seconds)
2022-11-08 18:43:21 +0100ubert1(~Thunderbi@178.115.49.179.wireless.dyn.drei.com)
2022-11-08 18:44:09 +0100teo(~teo@user/teo) (Ping timeout: 260 seconds)
2022-11-08 18:44:10 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-11-08 18:44:18 +0100ubert(~Thunderbi@178.115.49.179.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
2022-11-08 18:44:18 +0100ubert1ubert
2022-11-08 18:48:28 +0100 <dolio> Oh right, of course.
2022-11-08 18:48:34 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Ping timeout: 252 seconds)
2022-11-08 18:50:58 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2022-11-08 18:52:09 +0100abhiroop_(~abhiroop@217-209-157-8-no2000.tbcn.telia.com)
2022-11-08 18:55:57 +0100king_gs(~Thunderbi@187.201.83.115)
2022-11-08 18:57:27 +0100pyrex_(~quassel@2601:645:8781:1c90::5cbe)
2022-11-08 18:57:37 +0100nschoe(~q@2a01:e0a:8e:a190:819d:bc04:2515:8096) (Ping timeout: 252 seconds)
2022-11-08 18:59:54 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 260 seconds)
2022-11-08 19:00:50 +0100pyrex(~quassel@user/pyrex) (Ping timeout: 260 seconds)
2022-11-08 19:02:49 +0100 <ski> still weird that it eats an extra parameter, there
2022-11-08 19:03:11 +0100abrar(~abrar@static-108-2-152-54.phlapa.fios.verizon.net)
2022-11-08 19:03:19 +0100 <ski> zzz : you could define ⌜ιMod :: (T -> T) -> (State -> State); ιMod f st = st {ι = f (ι st)}⌝, and ditto for ⌜λMod :: (Layer -> Layer) -> (T -> T)⌝,⌜φMod :: (Int -> Int) -> (T -> T)⌝,⌜τMod :: (Set' Int -> Set' Int) -> (T -> T)⌝,⌜μMod :: (Mode -> Mode) -> (State -> State)⌝, where ⌜T⌝ is whatever type the field ⌜ι⌝ has
2022-11-08 19:03:43 +0100 <ski> zzz : .. and then say ⌜(ιMod . φMod) (move 1 W) st⌝ instead of ⌜st { ι = (ι st) { φ = move 1 W f } }⌝, ⌜(ιMod . τMod) (\f -> if f ∈ t then del f t else add f t) st⌝ (or ⌜(ιMod . τMod) (cond (∈ t) (`del` t) (`add` t)) st⌝, given ⌜cond p t e x = if p x then t x else e x⌝) instead of ⌜st { ι = (ι st) { τ = if f ∈ t then del f t else add f t } }⌝, &c.
2022-11-08 19:03:44 +0100ddellacosta(~ddellacos@86.106.143.66)
2022-11-08 19:06:06 +0100 <ski> @where SEC
2022-11-08 19:06:06 +0100 <lambdabot> http://conal.net/blog/posts/semantic-editor-combinators/
2022-11-08 19:06:10 +0100 <ski> @wiki Tangible Value#IO
2022-11-08 19:06:10 +0100 <lambdabot> https://wiki.haskell.org/Tangible_Value#IO
2022-11-08 19:07:29 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-08 19:10:38 +0100nate4(~nate@98.45.169.16)
2022-11-08 19:13:18 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-08 19:16:15 +0100king_gs1(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 19:16:15 +0100king_gs(~Thunderbi@187.201.83.115) (Read error: Connection reset by peer)
2022-11-08 19:16:15 +0100king_gs1king_gs
2022-11-08 19:19:14 +0100acidjnk_new3(~acidjnk@p200300d6e7137a91c8a7e6211d36bcc5.dip0.t-ipconnect.de)
2022-11-08 19:19:55 +0100nate4(~nate@98.45.169.16) (Ping timeout: 248 seconds)
2022-11-08 19:21:02 +0100gmg(~user@user/gehmehgeh)
2022-11-08 19:26:34 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2022-11-08 19:27:31 +0100ub(~Thunderbi@178.115.49.179.wireless.dyn.drei.com)
2022-11-08 19:28:29 +0100irrgit(~irrgit@146.70.27.250) (Ping timeout: 260 seconds)
2022-11-08 19:30:03 +0100beteigeuze(~Thunderbi@a79-169-109-107.cpe.netcabo.pt) (Ping timeout: 248 seconds)
2022-11-08 19:31:43 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer)
2022-11-08 19:32:41 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-08 19:38:34 +0100Tuplanolla(~Tuplanoll@91-159-69-11.elisa-laajakaista.fi)
2022-11-08 19:39:03 +0100Guest79(~Guest79@80.208.65.12)
2022-11-08 19:41:06 +0100irrgit(~irrgit@89.47.234.26)
2022-11-08 19:41:19 +0100pyrex_(~quassel@2601:645:8781:1c90::5cbe) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-11-08 19:41:36 +0100pyrex(~quassel@user/pyrex)
2022-11-08 19:43:59 +0100 <Maxdamantus> 01:00:03 < ephemient> sadly syscalls are no longer cheap due to software mitigations for hardware vulnerabilities (e.g. https://www.kernel.org/doc/html/latest/x86/pti.html flushes page tables on enter and exit)
2022-11-08 19:44:07 +0100 <Maxdamantus> they never really were cheap anyway.
2022-11-08 19:44:38 +0100 <Maxdamantus> I remember doing those `dd` experiments before the whole spectre/meltdown thing and it would still only do a couple of million per second.
2022-11-08 19:45:31 +0100 <Maxdamantus> I'm fairly confident that if `read` on a /dev/zero fd were implemented in userspace, it would do a lot more than 7 million per calls per second.
2022-11-08 19:45:41 +0100 <geekosaur> with some exceptions; IIRC certain read-only syscalls (e.g. get time) were done by mapping certain parts of kernel memory into user processes?
2022-11-08 19:46:26 +0100 <geekosaur> but yes, I/O syscalls are never fast; save/restore processor state in particular only gets slower as they add more and fancier registers
2022-11-08 19:46:33 +0100 <Maxdamantus> Yes, aiui there are some things implemented in the VDSO that avoid the actual system call.
2022-11-08 19:46:35 +0100econo(uid147250@user/econo)
2022-11-08 19:46:53 +0100 <Maxdamantus> but those are things that could probably be optimised out by a smart runtime anyway.
2022-11-08 19:47:23 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de)
2022-11-08 19:48:14 +0100bjourne(~bjourne@2001:6b0:1:1140:42bf:ff4:f8fa:50e5) (Quit: Konversation terminated!)
2022-11-08 19:50:04 +0100abhiroop_(~abhiroop@217-209-157-8-no2000.tbcn.telia.com) (Ping timeout: 260 seconds)
2022-11-08 19:52:37 +0100Sauvin(~sauvin@user/Sauvin) (Read error: Connection reset by peer)
2022-11-08 19:52:44 +0100Bocaneri(~sauvin@user/Sauvin)
2022-11-08 19:52:59 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-11-08 19:53:08 +0100BocaneriGuest186
2022-11-08 19:53:24 +0100waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-11-08 19:54:34 +0100jakalx(~jakalx@base.jakalx.net)
2022-11-08 19:56:48 +0100Guest186Sauvin
2022-11-08 19:57:45 +0100Guest73(~Guest73@80.209.95.138.static.fibianet.dk)
2022-11-08 19:58:38 +0100Guest73(~Guest73@80.209.95.138.static.fibianet.dk) (Client Quit)
2022-11-08 20:00:22 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Remote host closed the connection)
2022-11-08 20:00:42 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 20:02:31 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 20:04:20 +0100Guest79(~Guest79@80.208.65.12) (Quit: Client closed)
2022-11-08 20:05:15 +0100ddellacosta(~ddellacos@86.106.143.66) (Ping timeout: 248 seconds)
2022-11-08 20:08:33 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Read error: Connection reset by peer)
2022-11-08 20:08:36 +0100wootehfoot(~wootehfoo@user/wootehfoot)
2022-11-08 20:10:07 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-08 20:13:56 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 20:16:47 +0100tzh_(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2022-11-08 20:18:05 +0100emergence(emergence@2607:5300:60:5910:dcad:beff:feef:5bc)
2022-11-08 20:18:10 +0100chele_(~chele@user/chele) (Remote host closed the connection)
2022-11-08 20:19:35 +0100troydm(~troydm@host-176-37-124-197.b025.la.net.ua)
2022-11-08 20:19:49 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Ping timeout: 260 seconds)
2022-11-08 20:22:58 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-11-08 20:25:37 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Remote host closed the connection)
2022-11-08 20:29:46 +0100ss4(~wootehfoo@user/wootehfoot)
2022-11-08 20:32:59 +0100freeside(~mengwong@103.252.202.193) (Ping timeout: 248 seconds)
2022-11-08 20:33:14 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Ping timeout: 260 seconds)
2022-11-08 20:34:13 +0100emmanuelux(~emmanuelu@user/emmanuelux)
2022-11-08 20:37:05 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 260 seconds)
2022-11-08 20:40:28 +0100Kaipii(~Kaiepi@108.175.84.104)
2022-11-08 20:41:42 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2022-11-08 20:43:44 +0100Kaipei(~Kaiepi@108.175.84.104) (Ping timeout: 260 seconds)
2022-11-08 20:44:22 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7)
2022-11-08 20:44:35 +0100fserucas(~fserucas@2001:818:e376:a400:fb92:70c1:dd88:c7d7) (Client Quit)
2022-11-08 20:45:00 +0100freeside(~mengwong@103.252.202.193)
2022-11-08 20:45:24 +0100jargon(~jargon@184.101.188.35) (Ping timeout: 248 seconds)
2022-11-08 20:45:29 +0100ubert(~Thunderbi@178.115.49.179.wireless.dyn.drei.com) (Ping timeout: 260 seconds)
2022-11-08 20:45:58 +0100ubert(~Thunderbi@178.115.49.179.wireless.dyn.drei.com)
2022-11-08 20:46:00 +0100ub1(~Thunderbi@178.115.49.179.wireless.dyn.drei.com)
2022-11-08 20:47:14 +0100ub(~Thunderbi@178.115.49.179.wireless.dyn.drei.com) (Ping timeout: 260 seconds)
2022-11-08 20:48:16 +0100ub1ub
2022-11-08 20:54:49 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 260 seconds)
2022-11-08 20:55:02 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2022-11-08 20:55:21 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2022-11-08 21:05:37 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2022-11-08 21:05:50 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:fa38:3bf7:7f25:d08f)
2022-11-08 21:15:29 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6) (Ping timeout: 252 seconds)
2022-11-08 21:16:44 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz) (Ping timeout: 246 seconds)
2022-11-08 21:19:09 +0100 <EvanR> a big part of the complexity of multicore programming seems to come from coherence of memory when multiple cores read and write the same shared memory. Since haskell "always writes, then reads" is there any performance improvement from side stepping all that
2022-11-08 21:19:21 +0100Guest75(~Guest75@178.141.177.81)
2022-11-08 21:20:10 +0100 <EvanR> i.e. you never need to read the previous value from heap objects, they only get written once
2022-11-08 21:21:35 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:fa38:3bf7:7f25:d08f) (Quit: WeeChat 2.8)
2022-11-08 21:21:43 +0100 <monochrom> I think yes. Especially given the stronger "if two threads write, they write the same thing anyway".
2022-11-08 21:23:07 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-11-08 21:23:28 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 21:23:35 +0100 <monochrom> Indeed Simon Marlow already allows GHC the "race condition" of "in rare cases two threads evaluating the same thunk may both do writes, but I don't care".
2022-11-08 21:25:26 +0100 <EvanR> oh, then that blows my question out of the water
2022-11-08 21:26:32 +0100 <monochrom> There is a white-hole mark to avoid that most of the time, but the purpose is just to avoid two threads duplicating the same work, i.e., just to save time. The white-hole marking is not "thread-safe" in the normal sense because, as in above, it doesn't have to be.
2022-11-08 21:27:28 +0100mixfix41(~sdeny9ee@user/mixfix41)
2022-11-08 21:28:00 +0100 <monochrom> But I feel that GHC can be even more aggressive than it currently is, there are more opportunities to exploit.
2022-11-08 21:29:20 +0100 <EvanR> even if it's correct to allow that race condition, two threads writing while others are reading means you still might still trigger some kind uh
2022-11-08 21:29:31 +0100 <EvanR> cache coherency activity
2022-11-08 21:30:18 +0100 <monochrom> OK so here is the white-hole workflow.
2022-11-08 21:30:29 +0100 <EvanR> I'm a noob. But I'm waiting for this book Art of Multiprocessor Programming
2022-11-08 21:31:34 +0100nate4(~nate@98.45.169.16)
2022-11-08 21:31:35 +0100 <monochrom> A thread sees a thunk and wants to evalute it. First it checks whether it's already marked as a "white hole"; if yes, it means some thread got there first, so just wait for the resolution.
2022-11-08 21:32:12 +0100 <monochrom> If no, then mark it as a white hole, do the evaluation, store the value there.
2022-11-08 21:33:09 +0100king_gs(~Thunderbi@2806:103e:29:47b9:f34b:ffff:4cfc:90a6)
2022-11-08 21:33:20 +0100libertyprime(~libertypr@118-92-78-165.dsl.dyn.ihug.co.nz)
2022-11-08 21:33:26 +0100 <EvanR> side tangent, what mechanism is used to 'wait'
2022-11-08 21:33:45 +0100 <monochrom> We don't guard against race conditions in this process. If two threads do the above simultaneously, sure both threads will store values there, but it's the same value, it doesn't hurt.
2022-11-08 21:33:50 +0100 <monochrom> I forgot.
2022-11-08 21:34:21 +0100mmhat(~mmh@p200300f1c70f4195ee086bfffe095315.dip0.t-ipconnect.de)
2022-11-08 21:34:41 +0100 <EvanR> they will store the same value, but will they store the same pointer?
2022-11-08 21:34:54 +0100 <monochrom> No, and it still doesn't hurt.
2022-11-08 21:35:08 +0100 <EvanR> but good to know in case you're accessing that pointer somehow xD
2022-11-08 21:35:19 +0100 <geekosaur> if you are, it's impure
2022-11-08 21:35:39 +0100mesaoptimizer2rstoenwdyuhnw
2022-11-08 21:35:48 +0100rstoenwdyuhnwquit
2022-11-08 21:35:52 +0100quit(~mesaoptim@user/PapuaHardyNet) (Quit: issued !quit command)
2022-11-08 21:36:02 +0100 <EvanR> does all this directly have to do with unsafeUnutterablePerformIO's "gotchas"
2022-11-08 21:36:22 +0100mesaoptimizermesaoptimizer2
2022-11-08 21:36:33 +0100 <monochrom> So both threads create heap objects independently. But firstly they have Leibniz-equal content. Secondly one of them loses, well that just means unreferenced heap object, i.e., normal garbage. Let GC worry about it.
2022-11-08 21:36:49 +0100nate4(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2022-11-08 21:36:59 +0100Topsi(~Topsi@ipb218f755.dynamic.kabel-deutschland.de)
2022-11-08 21:37:08 +0100pavonia(~user@user/siracusa)
2022-11-08 21:37:12 +0100 <EvanR> that it's not the same pointer even more requires there to be some kind of cache update
2022-11-08 21:37:25 +0100 <EvanR> but because of the white hole flag I guess it's rare
2022-11-08 21:38:12 +0100 <geekosaur> as for Unutterable, that blows up because an impure operation is unwrapped into an apparently pure one, and all sorts of things subsequently go wrong
2022-11-08 21:38:12 +0100ss4(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2022-11-08 21:38:52 +0100 <EvanR> e.g. if you take the leibniz seriously, you wouldn't even need to synchronize the pointer across cores, different cores see different pointers to the same data and it's OK xD
2022-11-08 21:39:05 +0100 <monochrom> Yeah, that.
2022-11-08 21:39:26 +0100 <EvanR> (but it probably is anyway, so... I think that answers my original question)
2022-11-08 21:39:33 +0100machinedgod(~machinedg@clnet-b05-118.ikbnet.co.at)
2022-11-08 21:39:44 +0100 <monochrom> Simon Marlow felt safe doing that because supposedly you're doing referentially transparent computing.
2022-11-08 21:40:44 +0100 <geekosaur> (with unsafePerformIO, the internals are still impure, only the result is "coerced" into apparent purity. accursedUnutterablePerformIO declares the internals as pure as well
2022-11-08 21:40:46 +0100 <geekosaur> )
2022-11-08 21:42:23 +0100myme(~myme@40.51-175-185.customer.lyse.net)
2022-11-08 21:43:04 +0100myme(~myme@40.51-175-185.customer.lyse.net) (Client Quit)
2022-11-08 21:43:21 +0100myme(~myme@40.51-175-185.customer.lyse.net)
2022-11-08 21:44:30 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-11-08 21:44:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Remote host closed the connection)
2022-11-08 21:46:04 +0100jackhill(~jackhill@kalessin.dragonsnail.net) (Ping timeout: 255 seconds)
2022-11-08 21:46:41 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-11-08 21:46:52 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de)
2022-11-08 21:47:46 +0100gmg(~user@user/gehmehgeh)
2022-11-08 21:50:49 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de) (Ping timeout: 260 seconds)
2022-11-08 21:51:37 +0100titibandit(~titibandi@xdsl-87-78-8-6.nc.de)
2022-11-08 21:51:56 +0100ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds)
2022-11-08 21:53:58 +0100moneyjoe
2022-11-08 21:54:10 +0100ec_(~ec@gateway/tor-sasl/ec)
2022-11-08 21:54:27 +0100joeGuest704
2022-11-08 21:54:45 +0100Guest704joeyjoe
2022-11-08 21:54:57 +0100joeyjoemoney
2022-11-08 22:01:41 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de) (Remote host closed the connection)
2022-11-08 22:03:28 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2022-11-08 22:04:18 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-11-08 22:04:43 +0100ft(~ft@p508dbd59.dip0.t-ipconnect.de)
2022-11-08 22:05:13 +0100gmg(~user@user/gehmehgeh)
2022-11-08 22:10:10 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2022-11-08 22:11:23 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-08 22:17:58 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2022-11-08 22:22:17 +0100caryhartline(~caryhartl@2603-8080-6a0e-8d88-f0f2-36eb-bc07-091c.res6.spectrum.com)
2022-11-08 22:26:45 +0100cheater(~Username@user/cheater) (Ping timeout: 260 seconds)
2022-11-08 22:32:40 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2022-11-08 22:33:10 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2022-11-08 22:34:42 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2022-11-08 22:36:49 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-11-08 22:37:22 +0100jcb`(~user@104-202-135-187.dyn.grandenetworks.net)
2022-11-08 22:38:06 +0100myme(~myme@40.51-175-185.customer.lyse.net) (Quit: WeeChat 3.7.1)
2022-11-08 22:39:15 +0100jcb`(~user@104-202-135-187.dyn.grandenetworks.net) ()
2022-11-08 22:41:04 +0100deathgrindfreak(~user@104-202-135-187.dyn.grandenetworks.net)
2022-11-08 22:43:54 +0100caryhartline(~caryhartl@2603-8080-6a0e-8d88-f0f2-36eb-bc07-091c.res6.spectrum.com) (Quit: caryhartline)
2022-11-08 22:45:00 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6)
2022-11-08 22:49:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:3d74:5eb7:3590:2ac6) (Ping timeout: 260 seconds)
2022-11-08 22:51:40 +0100nschoe(~q@2a01:e0a:8e:a190:59e0:6a55:8f76:edc2)
2022-11-08 22:51:40 +0100nschoe(~q@2a01:e0a:8e:a190:59e0:6a55:8f76:edc2) (Client Quit)
2022-11-08 22:56:27 +0100cheater(~Username@user/cheater)
2022-11-08 22:57:33 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2022-11-08 23:01:17 +0100thegeekinside(~thegeekin@189.180.92.220) (Remote host closed the connection)
2022-11-08 23:01:22 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2022-11-08 23:01:53 +0100jackhill(~jackhill@kalessin.dragonsnail.net)
2022-11-08 23:07:00 +0100freeside(~mengwong@103.252.202.193) (Ping timeout: 260 seconds)
2022-11-08 23:09:46 +0100cheater(~Username@user/cheater) (Ping timeout: 252 seconds)
2022-11-08 23:10:03 +0100cheater(~Username@user/cheater)
2022-11-08 23:10:23 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68) (Quit: Going elsewhere)
2022-11-08 23:11:46 +0100mvk(~mvk@2607:fea8:5ce3:8500::4b68)
2022-11-08 23:14:48 +0100thegeekinside(~thegeekin@189.180.92.220)
2022-11-08 23:15:27 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2022-11-08 23:19:00 +0100zeenk(~zeenk@2a02:2f04:a105:5d00:c862:f190:2ea:d494) (Quit: Konversation terminated!)
2022-11-08 23:20:59 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 246 seconds)
2022-11-08 23:21:42 +0100slac75772(~slack1256@191.126.227.81)
2022-11-08 23:23:39 +0100slack1256(~slack1256@186.11.28.28) (Ping timeout: 248 seconds)
2022-11-08 23:24:10 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-11-08 23:25:35 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2022-11-08 23:25:51 +0100bilegeek(~bilegeek@2600:1008:b047:b089:cb4:8edc:1ce0:e639)
2022-11-08 23:25:56 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-11-08 23:26:49 +0100gmg(~user@user/gehmehgeh)
2022-11-08 23:28:31 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2022-11-08 23:31:13 +0100gmg(~user@user/gehmehgeh) (Client Quit)
2022-11-08 23:32:16 +0100michalz(~michalz@185.246.207.200) (Remote host closed the connection)
2022-11-08 23:33:36 +0100machinedgod(~machinedg@clnet-b05-118.ikbnet.co.at) (Ping timeout: 252 seconds)
2022-11-08 23:35:33 +0100freeside(~mengwong@103.252.202.193)
2022-11-08 23:36:13 +0100Neuromancer(~Neuromanc@user/neuromancer) (Ping timeout: 252 seconds)
2022-11-08 23:38:38 +0100 <ski> could one thread possibly write half its value, then the other thread writes both its halves, then the first thread writes its other half ?
2022-11-08 23:39:33 +0100 <ski> i suppose it's always here writing a unit of memory which can be written atomically in a single instruction
2022-11-08 23:40:15 +0100freeside(~mengwong@103.252.202.193) (Ping timeout: 260 seconds)
2022-11-08 23:41:04 +0100 <geekosaur> I think ghc has an invariant that pointer writes are atomic?
2022-11-08 23:41:33 +0100 <geekosaur> (and fit in a standard register)
2022-11-08 23:43:22 +0100ub(~Thunderbi@178.115.49.179.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
2022-11-08 23:43:22 +0100ubert(~Thunderbi@178.115.49.179.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
2022-11-08 23:43:35 +0100ubert(~Thunderbi@178.115.40.19.wireless.dyn.drei.com)
2022-11-08 23:43:52 +0100 <ski> (first i was thinking of the value maybe being a large pointer that wouldn't necessarily have an atomic write. but presumably processors nowadays normally makes sure that the pointer/address size can be written atomically (?). then i was also wondering about, hm, an unboxed tuple, iow multiple values (perhaps the pure computation can generate structurally distinct, but observationally equivalent, values .. i
2022-11-08 23:43:54 +0100 <monochrom> By a happy coincidence, you may actually have cache-line-size atomicity.
2022-11-08 23:43:54 +0100ub(~Thunderbi@178.115.40.19.wireless.dyn.drei.com)
2022-11-08 23:43:58 +0100 <ski> guess distinct addresses of allocated memory is one instance of this). but possibly, when caching such, it'd write them to a fresh memory object, and then atomically store *its* address in a thunk, rather than storing the multiple values directly there)
2022-11-08 23:44:18 +0100 <money> Nice
2022-11-08 23:44:27 +0100deathgrindfreak(~user@104-202-135-187.dyn.grandenetworks.net) (Ping timeout: 248 seconds)
2022-11-08 23:45:10 +0100 <ski> atomicity for writing a whole cache-line .. hm, i suppose that makes sense. but what happens if two processors or cores modify their cache-lines at the same time, and then try to store back to memory ?
2022-11-08 23:45:49 +0100 <monochrom> You can build a very length heap object. That doesn't hurt. You either win or lose in submitting the address of your heap object.
2022-11-08 23:47:13 +0100 <ski> the large heap object fitting in a cache-line ?
2022-11-08 23:47:20 +0100 <ski> (or larger still ?)
2022-11-08 23:47:59 +0100 <monochrom> When two threads happen to evaluate the same thunk, and the result value will turn out to be a very lengthy heap object, the two threads build two independent heap objects in separate regions. During this time, no one is broadcasting any final address.
2022-11-08 23:48:38 +0100 <monochrom> The only real race is when the two threads both say "I'm done, this is the address of my answer".
2022-11-08 23:48:40 +0100 <ski> this happens for any object larger than what can atomically be stored ?
2022-11-08 23:49:12 +0100 <monochrom> There is no atomicity, nor is any needed, until either thread submits one single final address.
2022-11-08 23:49:59 +0100 <monochrom> Indeed the two threads even get separate heap regions called "nurseries", one nursery per thread.
2022-11-08 23:50:28 +0100 <monochrom> Something I learned just today from re-reading the "GHC execution model" slides.
2022-11-08 23:50:30 +0100jargon(~jargon@184.101.188.35)
2022-11-08 23:50:31 +0100 <ski> if threads can write a whole cache-line atomically, then they should be able to write a whole bunch of values (unboxed) into a thunk, with no problem, as long as they all fit in the cache-line simultaneously, no ?
2022-11-08 23:50:59 +0100 <ski> (possibly GHC doesn't do this .. i'm wondering if it possibly could do something along these lines)
2022-11-08 23:51:01 +0100 <monochrom> I brought up cache line because, only because, cache-line-level atomicity implies pointer atomicity.
2022-11-08 23:52:30 +0100 <ski> iow, as an optimization, instead of submitting a single final address, it sounds like it would be possible to submit multiple addresses and unboxed values, as long as there aren't too many of them
2022-11-08 23:53:46 +0100freeside(~mengwong@103.252.202.193)
2022-11-08 23:57:03 +0100beteigeuze(~Thunderbi@bl14-81-220.dsl.telepac.pt)
2022-11-08 23:57:07 +0100 <ski> (hm, also, in the write-to-separate-fresh-memory-blocks scenario, i wonder whether each thread could have different permissions to read and write so that only that thread can write (and none can read (or perhaps only that thread, if it wants to read what it's written already)), to begin with, and after it has finished writing, that page could be marked readable by other threads (and either writable turned
2022-11-08 23:57:13 +0100 <ski> off, if no need, or turned on for all threads), just before submitting its address to the shared thunk)
2022-11-08 23:58:59 +0100 <ski> .. perhaps the page permissions fiddling, and making sure everything in the same page can cope with the same permissions, would make this too costly, or to awkward, to use -- i dunno