IRCBrowse

2023/03/21

2023-03-21 00:05:01 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2023-03-21 00:05:58 +0100harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-03-21 00:06:22 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-03-21 00:17:26 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-03-21 00:19:33 +0100irrgit__(~irrgit@86.106.90.226)
2023-03-21 00:22:21 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2023-03-21 00:23:28 +0100irrgit_(~irrgit@146.70.27.218) (Ping timeout: 276 seconds)
2023-03-21 00:31:12 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Remote host closed the connection)
2023-03-21 00:31:25 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 00:35:47 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 250 seconds)
2023-03-21 00:38:46 +0100Umeaboy(~Umeaboy@94-255-145-133.cust.bredband2.com)
2023-03-21 00:41:29 +0100zeenk(~zeenk@2a02:2f04:a307:2300::7fe) (Quit: Konversation terminated!)
2023-03-21 00:41:38 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 00:46:33 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 256 seconds)
2023-03-21 00:46:46 +0100elevenkb(~elevenkb@105.186.233.148)
2023-03-21 00:49:22 +0100pavonia(~user@user/siracusa)
2023-03-21 00:58:21 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 01:09:51 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94)
2023-03-21 01:14:19 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94) (Ping timeout: 256 seconds)
2023-03-21 01:23:13 +0100Umeaboy(~Umeaboy@94-255-145-133.cust.bredband2.com) (Quit: Leaving)
2023-03-21 01:31:32 +0100gdd(~gdd@2001:470:1f13:187:2eb4:3062:b059:4462) (Ping timeout: 265 seconds)
2023-03-21 01:31:53 +0100 <dminuoso> https://gist.github.com/dminuoso/e17a7de0657cb707078176bdb081b806
2023-03-21 01:31:57 +0100gdd(~gdd@2001:470:1f13:187:2eb4:3062:b059:4462)
2023-03-21 01:32:00 +0100dminuosohas a low tolerance for Show
2023-03-21 01:33:22 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 01:33:49 +0100acidjnk_new(~acidjnk@p200300d6e715c4967481643c9dce377b.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-03-21 01:35:29 +0100 <geekosaur> I'm confused. where does `Control.Concurrent.myThreadId` roundtrip through Show?
2023-03-21 01:37:49 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 265 seconds)
2023-03-21 01:38:14 +0100 <dminuoso> geekosaur: Oh, if you ever want to visualize it (say the thread id in a logger), you cant do much with a ThreadId other than show it.
2023-03-21 01:38:28 +0100 <dminuoso> I suppose I can just use myThreadId instead of the manual IO action at least.
2023-03-21 01:39:44 +0100 <geekosaur> oh, right. that's kinda useless
2023-03-21 01:40:12 +0100 <geekosaur> although I guess yours also has the advantage that it doesn't pin the thread since it goes behind the RTS's back
2023-03-21 01:40:34 +0100 <dminuoso> myThreadId doesnt really do anything else
2023-03-21 01:40:46 +0100 <geekosaur> see the comment on ThreadId
2023-03-21 01:41:06 +0100 <dminuoso> ah huh
2023-03-21 01:42:21 +0100 <dminuoso> So I guess I save myself an extra allocation.
2023-03-21 01:42:35 +0100 <dminuoso> Good. So I can finally label my software with high performance.
2023-03-21 01:46:38 +0100 <dminuoso> On that note should probably bind getThreadId to ThreadId# -> IO CULLong instead to sequence it properly
2023-03-21 01:46:50 +0100 <dminuoso> Otherwise lazyness could bite me back
2023-03-21 01:46:55 +0100 <dminuoso> Perhaps?
2023-03-21 01:49:02 +0100mauke_(~mauke@user/mauke)
2023-03-21 01:51:12 +0100mauke(~mauke@user/mauke) (Ping timeout: 264 seconds)
2023-03-21 01:51:12 +0100mauke_mauke
2023-03-21 01:52:05 +0100 <c_wraith> hidden deep in base, there's https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-Conc-Sync.html#v:threadCapability
2023-03-21 01:52:33 +0100 <c_wraith> Which seems like exactly the primitive you'd want for striping a data structure
2023-03-21 01:53:16 +0100mrmr9(~mrmr@user/mrmr)
2023-03-21 01:53:49 +0100 <dminuoso> striping?
2023-03-21 01:54:34 +0100 <c_wraith> Sometimes (depending on the use case) you can split your data structure into multiple independent sections so that concurrent access to different sections doesn't cause contention
2023-03-21 01:55:05 +0100 <c_wraith> It works great for things that work like counters
2023-03-21 01:55:50 +0100 <dminuoso> Given that you dont have guarantees about capabilities, how is the capability number going to help?
2023-03-21 01:56:03 +0100 <dminuoso> That is, you might end up with some capabilities unused
2023-03-21 01:56:20 +0100sp00kins(~sp00kins@2601:5c9:4200:77b::b6)
2023-03-21 01:56:33 +0100inversed(~inversed@bcdcac82.skybroadband.com) (Ping timeout: 246 seconds)
2023-03-21 01:57:20 +0100 <c_wraith> well, striping based on capability id is going to prevent active contention unless the capability changes threads inside the critical section
2023-03-21 01:58:04 +0100 <c_wraith> doing something like may let you drastically reduce the contention in an STM system, for instance
2023-03-21 01:58:59 +0100 <dminuoso> Sure, but it would need some careful deliberation. If you do something naive like "let n be the capability number, so a worker always works every nth element" it could leave work undone
2023-03-21 01:59:26 +0100 <dminuoso> But maybe you and I are thinking of different workloads or ways to stripe
2023-03-21 01:59:46 +0100 <c_wraith> well sure. doing that would be incorrect. You'd do something like "this thread is on capability 1, so it uses the TVars in bucket 1"
2023-03-21 02:00:50 +0100 <dminuoso> Ohh I see.
2023-03-21 02:00:53 +0100 <c_wraith> though given that capability count can increase at runtime, you'd probably want a mod or something in there to deal with suddenly seeing capability id 1000 when you only have 8 buckets
2023-03-21 02:01:10 +0100 <dminuoso> So something like capability indexed "workers" (fsvo worker)
2023-03-21 02:01:26 +0100 <c_wraith> well. capability-indexed data.
2023-03-21 02:01:43 +0100 <dminuoso> right
2023-03-21 02:02:13 +0100 <c_wraith> but yeah. for *some* use cases, that can really help.
2023-03-21 02:02:36 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds)
2023-03-21 02:02:51 +0100 <c_wraith> there are plenty of use cases where it's bad, of course :)
2023-03-21 02:02:53 +0100 <dminuoso> That's a cool trick to remember definitely.
2023-03-21 02:06:55 +0100elevenkb(~elevenkb@105.186.233.148) (Quit: Client closed)
2023-03-21 02:10:31 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-03-21 02:11:13 +0100inversed(~inversed@bcdcac82.skybroadband.com)
2023-03-21 02:16:38 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-03-21 02:20:42 +0100 <Artem[m]> anyone knows what means .\ at the end of a function name in a .prof file? When I have a function foo in my program, the profiling report would occasionally (for some foos) include foo.\. I use automatic cost center inclusion for all functions if this matters.
2023-03-21 02:20:52 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:20:54 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:20:58 +0100 <slack1256> Artem[m]: I want to know too...
2023-03-21 02:21:07 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:21:08 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:21:20 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:21:20 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:21:29 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:21:30 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:21:39 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:21:40 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:21:50 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:21:50 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:22:00 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:22:01 +0100bramhaag(~bramhaag@134.195.121.39) (Read error: Connection reset by peer)
2023-03-21 02:22:12 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:22:13 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:22:26 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:22:26 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:22:42 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:22:43 +0100bramhaag(~bramhaag@134.195.121.39) (Read error: Connection reset by peer)
2023-03-21 02:23:06 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:23:06 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:23:41 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:23:42 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:24:42 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:24:43 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:25:53 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:25:54 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:26:03 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:26:04 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:26:13 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:26:13 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:26:23 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:26:24 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:26:34 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:26:35 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:26:45 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:26:45 +0100bramhaag(~bramhaag@134.195.121.39) (Remote host closed the connection)
2023-03-21 02:26:58 +0100bramhaag(~bramhaag@134.195.121.39)
2023-03-21 02:27:29 +0100mrmr9(~mrmr@user/mrmr) (Read error: Connection reset by peer)
2023-03-21 02:29:24 +0100mrmr9(~mrmr@user/mrmr)
2023-03-21 02:31:47 +0100mrmr9(~mrmr@user/mrmr) (Read error: Connection reset by peer)
2023-03-21 02:32:21 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de) (Ping timeout: 250 seconds)
2023-03-21 02:35:08 +0100 <bramhaag> I'm trying to parse a programming language with many ambiguities. It is so ambiguous that lexing does not make a lot of sense. I wanted to use parser combinators, but megaparsec does not have a built-in way to generate all parse trees, and ReadP is not flexible enough for my use case. Happy in GLR mode will be my last resort, does anyone have any
2023-03-21 02:35:08 +0100 <bramhaag> other suggestions maybe?
2023-03-21 02:36:45 +0100mrmr9(~mrmr@user/mrmr)
2023-03-21 02:39:03 +0100mrmr9(~mrmr@user/mrmr) (Read error: Connection reset by peer)
2023-03-21 02:44:27 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 255 seconds)
2023-03-21 02:48:37 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-03-21 02:53:27 +0100 <sm> bramhaag: even megaparsec's expression parser ?
2023-03-21 02:55:02 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 02:56:58 +0100 <bramhaag> sm: tbh haven't tried the expression parser. Though I'm not sure if it can deal with custom disambiguation heuristics?
2023-03-21 02:57:58 +0100 <sm> probably not, but it helps parse "combinations of things in any order" so I figured it might be worth a try
2023-03-21 02:58:12 +0100 <bramhaag> An example of what I'm trying to parse: https://paste.tomsmeding.com/2asgHwHG Keywords are not reserved, and marked with * * here. Disambiguation rule is as follows: if ambiguity arises, uppercase words are considered keywords, otherwise identifiers
2023-03-21 02:58:14 +0100 <sm> you could process the result further afterward
2023-03-21 03:01:01 +0100sp00kins(~sp00kins@2601:5c9:4200:77b::b6) (Quit: sp00kins)
2023-03-21 03:01:54 +0100sp00kins(~sp00kins@c-73-171-2-129.hsd1.va.comcast.net)
2023-03-21 03:02:16 +0100 <bramhaag> I think it would be easiest to apply said heuristic to a parse forest, as in that case the ambiguous situations are clear. I don't see an immediate way to disambiguate the result of a megaparsec parser
2023-03-21 03:03:17 +0100sp00kins(~sp00kins@c-73-171-2-129.hsd1.va.comcast.net) (Client Quit)
2023-03-21 03:07:39 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 260 seconds)
2023-03-21 03:11:34 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94)
2023-03-21 03:16:07 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94) (Ping timeout: 250 seconds)
2023-03-21 03:19:20 +0100wroathe(~wroathe@user/wroathe) (Quit: leaving)
2023-03-21 03:19:21 +0100sagax(~sagax_nb@user/sagax) (Remote host closed the connection)
2023-03-21 03:20:59 +0100phma(~phma@2001:5b0:211c:53d8:9ceb:db03:6719:e454) (Ping timeout: 248 seconds)
2023-03-21 03:30:25 +0100hrberg(~quassel@171.79-160-161.customer.lyse.net) (Ping timeout: 250 seconds)
2023-03-21 03:32:22 +0100hrberg(~quassel@171.79-160-161.customer.lyse.net)
2023-03-21 03:34:41 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 03:39:21 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 255 seconds)
2023-03-21 03:42:12 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-03-21 03:43:29 +0100cassiopea(~cassiopea@user/cassiopea)
2023-03-21 03:46:55 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-03-21 03:53:25 +0100gehmehgeh(~user@user/gehmehgeh)
2023-03-21 03:54:28 +0100jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection)
2023-03-21 03:56:26 +0100gmg(~user@user/gehmehgeh) (Ping timeout: 255 seconds)
2023-03-21 04:00:33 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 04:02:06 +0100razetime(~Thunderbi@43.254.111.18)
2023-03-21 04:07:56 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 268 seconds)
2023-03-21 04:10:49 +0100Katarushisu1(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net)
2023-03-21 04:12:39 +0100Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Ping timeout: 255 seconds)
2023-03-21 04:12:39 +0100Katarushisu1Katarushisu
2023-03-21 04:15:23 +0100td_(~td@i5387092A.versanet.de) (Ping timeout: 265 seconds)
2023-03-21 04:17:04 +0100td_(~td@i5387090D.versanet.de)
2023-03-21 04:25:27 +0100waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 250 seconds)
2023-03-21 04:30:37 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 04:31:41 +0100motherfsck(~motherfsc@user/motherfsck)
2023-03-21 04:38:55 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 276 seconds)
2023-03-21 04:39:19 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 250 seconds)
2023-03-21 04:44:36 +0100razetime(~Thunderbi@43.254.111.18) (Ping timeout: 255 seconds)
2023-03-21 04:47:16 +0100razetime(~Thunderbi@43.254.111.18)
2023-03-21 04:47:17 +0100motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 265 seconds)
2023-03-21 04:48:01 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-03-21 04:48:01 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-03-21 04:48:01 +0100finn_elijaFinnElija
2023-03-21 04:48:25 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 04:49:38 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 04:54:03 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 255 seconds)
2023-03-21 04:55:02 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 246 seconds)
2023-03-21 04:58:41 +0100motherfsck(~motherfsc@user/motherfsck)
2023-03-21 05:01:54 +0100mbuf(~Shakthi@49.207.178.186)
2023-03-21 05:03:02 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 05:07:35 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 260 seconds)
2023-03-21 05:14:16 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 05:20:23 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 05:20:31 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 276 seconds)
2023-03-21 05:21:34 +0100msavoritias(cb716af6b3@irc.cheogram.com) (Ping timeout: 252 seconds)
2023-03-21 05:23:03 +0100trev(~trev@user/trev)
2023-03-21 05:24:24 +0100vglfr(~vglfr@88.155.43.4)
2023-03-21 05:25:25 +0100jakalx(~jakalx@base.jakalx.net) ()
2023-03-21 05:27:43 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Remote host closed the connection)
2023-03-21 05:27:56 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 05:31:28 +0100mikoto-chan(~mikoto-ch@dy54z4y1t9qnwdj1ryyby-4.rev.dnainternet.fi)
2023-03-21 05:32:47 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 246 seconds)
2023-03-21 05:37:55 +0100harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2023-03-21 05:38:15 +0100Square(~Square4@user/square) (Ping timeout: 250 seconds)
2023-03-21 05:39:36 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 05:39:50 +0100bontaq(~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 246 seconds)
2023-03-21 05:40:04 +0100johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in)
2023-03-21 05:43:53 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 250 seconds)
2023-03-21 05:44:52 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4)
2023-03-21 05:51:38 +0100gdr3941(~user@2601:483:4800:5740:bd6c:6a59:14bf:bde4) (Ping timeout: 252 seconds)
2023-03-21 05:53:07 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 05:55:17 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-03-21 05:57:30 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 252 seconds)
2023-03-21 06:01:31 +0100foul_owl(~kerry@157.97.134.62) (Quit: WeeChat 2.3)
2023-03-21 06:03:48 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 06:08:08 +0100echoreply(~echoreply@45.32.163.16) (Quit: WeeChat 2.8)
2023-03-21 06:09:13 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 06:09:26 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 06:15:34 +0100echoreply(~echoreply@2001:19f0:9002:1f3b:5400:ff:fe6f:8b8d)
2023-03-21 06:16:42 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 265 seconds)
2023-03-21 06:19:15 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 06:24:13 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 268 seconds)
2023-03-21 06:24:52 +0100shriekingnoise(~shrieking@186.137.175.87) (Quit: Quit)
2023-03-21 06:25:13 +0100shriekingnoise(~shrieking@186.137.175.87)
2023-03-21 06:25:37 +0100razetime(~Thunderbi@43.254.111.18) (Quit: See You Space Cowboy)
2023-03-21 06:25:51 +0100razetime(~Thunderbi@43.254.111.18)
2023-03-21 06:28:03 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 06:31:55 +0100mikoto-chan(~mikoto-ch@dy54z4y1t9qnwdj1ryyby-4.rev.dnainternet.fi) (Ping timeout: 248 seconds)
2023-03-21 06:32:25 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 250 seconds)
2023-03-21 06:34:24 +0100slack1256(~slack1256@181.42.50.18) (Ping timeout: 255 seconds)
2023-03-21 06:37:08 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 06:41:51 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 06:42:35 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 248 seconds)
2023-03-21 06:50:43 +0100motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 260 seconds)
2023-03-21 07:00:29 +0100jakalx(~jakalx@base.jakalx.net)
2023-03-21 07:01:48 +0100foul_owl(~kerry@71.212.143.88)
2023-03-21 07:04:31 +0100shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 276 seconds)
2023-03-21 07:06:42 +0100harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-03-21 07:07:21 +0100msavoritias(cb716af6b3@irc.cheogram.com)
2023-03-21 07:08:41 +0100johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net)
2023-03-21 07:09:00 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 07:12:06 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-03-21 07:14:42 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 265 seconds)
2023-03-21 07:14:55 +0100razetime(~Thunderbi@43.254.111.18) (Ping timeout: 276 seconds)
2023-03-21 07:19:14 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2023-03-21 07:24:48 +0100trev(~trev@user/trev) (Ping timeout: 255 seconds)
2023-03-21 07:39:33 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-03-21 07:43:06 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 07:46:36 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 265 seconds)
2023-03-21 07:48:00 +0100pyook(~pyook@user/puke)
2023-03-21 07:48:39 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 255 seconds)
2023-03-21 07:49:52 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2023-03-21 07:53:32 +0100trev(~trev@user/trev)
2023-03-21 07:58:21 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 08:00:20 +0100byorgey(~byorgey@155.138.238.211) (Quit: Lost terminal)
2023-03-21 08:06:04 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 08:06:12 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 252 seconds)
2023-03-21 08:06:24 +0100Guest9660(~Md@2a02:6b66:d2b1:0:2917:6e02:d698:a5d8)
2023-03-21 08:10:46 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 265 seconds)
2023-03-21 08:11:14 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 08:11:51 +0100freeside(~mengwong@103.252.202.85)
2023-03-21 08:15:55 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 248 seconds)
2023-03-21 08:17:17 +0100razetime(~Thunderbi@117.193.0.81)
2023-03-21 08:19:12 +0100razetime(~Thunderbi@117.193.0.81) (Client Quit)
2023-03-21 08:19:28 +0100freeside(~mengwong@103.252.202.85) (Ping timeout: 265 seconds)
2023-03-21 08:20:15 +0100kenran(~user@user/kenran)
2023-03-21 08:22:13 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 08:23:54 +0100titibandit_(~titibandi@xdsl-87-78-162-189.nc.de)
2023-03-21 08:24:47 +0100titibandit_(~titibandi@xdsl-87-78-162-189.nc.de) (Remote host closed the connection)
2023-03-21 08:29:07 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-03-21 08:32:17 +0100gehmehgeh(~user@user/gehmehgeh) (Ping timeout: 255 seconds)
2023-03-21 08:32:31 +0100vglfr(~vglfr@88.155.43.4) (Ping timeout: 265 seconds)
2023-03-21 08:32:38 +0100freeside(~mengwong@122.11.248.245)
2023-03-21 08:33:54 +0100vicfred(~vicfred@user/vicfred)
2023-03-21 08:36:43 +0100vicfred(~vicfred@user/vicfred) (Client Quit)
2023-03-21 08:37:15 +0100vicfred(~vicfred@user/vicfred)
2023-03-21 08:44:20 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-03-21 08:44:36 +0100smallville7123(~Android@cpe-172-193-72-46.qld.foxtel.net.au)
2023-03-21 08:46:02 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2023-03-21 08:49:46 +0100machinedgod(~machinedg@node-1w7jr9yirp0ap2d6xfacos1ph.ipv6.telus.net)
2023-03-21 08:54:11 +0100zeenk(~zeenk@2a02:2f04:a307:2300::7fe)
2023-03-21 08:56:38 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:6861:4c48:824b:2934)
2023-03-21 08:57:10 +0100euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 265 seconds)
2023-03-21 09:00:15 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de)
2023-03-21 09:02:20 +0100CiaoSen(~Jura@p200300c9571fe6002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2023-03-21 09:05:05 +0100vpan(~0@212.117.1.172)
2023-03-21 09:05:11 +0100 <dminuoso> bramhaag: Why does lexing not make a lot of sense?
2023-03-21 09:05:40 +0100 <dminuoso> I think most issues from "lexing is difficult" arise from thinking about lexing in the wrong direcftion.
2023-03-21 09:06:01 +0100 <dminuoso> That is, lexers dont push tokens into a parser, a parser demands tokens as needed - and you can do that with non-determinism just fine.
2023-03-21 09:06:08 +0100 <tomsmeding> bramhaag: https://hackage.haskell.org/package/Earley also seems to give you all parse trees
2023-03-21 09:06:12 +0100 <dminuoso> (It might have severe performance implications, but that's another story)
2023-03-21 09:08:30 +0100mastarija(~mastarija@188.252.199.22)
2023-03-21 09:08:58 +0100 <mauke> oh, like perl-style context-dependent lexing?
2023-03-21 09:11:27 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds)
2023-03-21 09:11:54 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-03-21 09:12:56 +0100econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2023-03-21 09:19:19 +0100hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 246 seconds)
2023-03-21 09:20:10 +0100 <tomsmeding> Artem[m]: isn't that a lambda within foo?
2023-03-21 09:23:34 +0100vicfred(~vicfred@user/vicfred) (Quit: leaving)
2023-03-21 09:23:40 +0100tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2023-03-21 09:24:59 +0100Guest9660(~Md@2a02:6b66:d2b1:0:2917:6e02:d698:a5d8) (Quit: Leaving)
2023-03-21 09:28:10 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 276 seconds)
2023-03-21 09:28:21 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds)
2023-03-21 09:28:35 +0100smallville7123(~Android@cpe-172-193-72-46.qld.foxtel.net.au) (Ping timeout: 265 seconds)
2023-03-21 09:30:25 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-03-21 09:30:59 +0100acidjnk_new(~acidjnk@p200300d6e715c49690267839e4058790.dip0.t-ipconnect.de)
2023-03-21 09:32:36 +0100foul_owl(~kerry@71.212.143.88) (Ping timeout: 255 seconds)
2023-03-21 09:33:48 +0100gehmehgeh(~user@user/gehmehgeh)
2023-03-21 09:34:24 +0100hugo(znc@verdigris.lysator.liu.se)
2023-03-21 09:39:03 +0100chomwitt(~chomwitt@2a02:587:7a19:3600:1ac0:4dff:fedb:a3f1)
2023-03-21 09:39:33 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 09:43:10 +0100ft(~ft@p3e9bc443.dip0.t-ipconnect.de) (Quit: leaving)
2023-03-21 09:46:56 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 246 seconds)
2023-03-21 09:47:27 +0100 <mon_aaraj> I've been wanting to learn (well, i actually want to "grok") can extensions for a while. I do know that when employed in haskell, they allow us to make abstractions more efficient (i've heard about how it can make stuff faster), what else do kan extensions allow? and what resources would you recommend for me to learn or grok kan extensions, at least for a programming context?
2023-03-21 09:48:16 +0100foul_owl(~kerry@157.97.134.63)
2023-03-21 09:48:33 +0100chele(~chele@user/chele)
2023-03-21 09:50:26 +0100 <dminuoso> mauke: many parsers do it that way.
2023-03-21 09:50:56 +0100 <dminuoso> Fairly sure even GHC does it
2023-03-21 09:51:26 +0100 <dminuoso> The happy documentation has some extensive examples in this direction
2023-03-21 09:51:49 +0100 <dminuoso> In fact, if you think about how production rules are made, you cant really do it any other way
2023-03-21 09:58:20 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 10:00:08 +0100JonathanWatson[m(~jjwmatrix@2001:470:69fc:105::2:a544) (Quit: You have been kicked for being idle)
2023-03-21 10:00:42 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-03-21 10:03:10 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 252 seconds)
2023-03-21 10:03:49 +0100razetime(~Thunderbi@117.193.0.81)
2023-03-21 10:06:02 +0100michalz(~michalz@185.246.207.215)
2023-03-21 10:06:33 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 10:06:46 +0100 <tomsmeding> bramhaag: to be honest, that sounds like a pretty bad programming language to work in, if its syntax is dependent on whether whole expressions end up ambiguous or not :p
2023-03-21 10:11:15 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 250 seconds)
2023-03-21 10:13:40 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 10:20:09 +0100elkcl_(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru)
2023-03-21 10:22:07 +0100elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Ping timeout: 276 seconds)
2023-03-21 10:22:07 +0100elkcl_elkcl
2023-03-21 10:28:19 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-03-21 10:29:39 +0100jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-03-21 10:31:11 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-03-21 10:31:33 +0100Putonlalla(~Putonlall@it-cyan.it.jyu.fi) (Ping timeout: 255 seconds)
2023-03-21 10:32:00 +0100euandreh(~Thunderbi@189.6.18.7)
2023-03-21 10:33:28 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-03-21 10:35:29 +0100Umeaboy(~Umeaboy@94-255-145-133.cust.bredband2.com)
2023-03-21 10:38:29 +0100vglfr(~vglfr@88.155.27.80)
2023-03-21 10:44:31 +0100pyook(~pyook@user/puke) ()
2023-03-21 10:47:52 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-03-21 10:50:36 +0100 <dminuoso> Is there an elegant way to express `let [a,b,c,d] = take 4 xs` without triggering incomppete-uni-patterns?
2023-03-21 10:50:48 +0100 <dminuoso> Something that will locally suppress this error?
2023-03-21 10:51:17 +0100 <dminuoso> maybe a kind of `let [a,b,c,d] | magicGhcThing = take 4 xs` ?
2023-03-21 10:52:09 +0100 <dminuoso> Gah I clearly recall this exists.
2023-03-21 10:52:23 +0100 <merijn> ~ ? :p
2023-03-21 10:53:10 +0100 <dminuoso> merijn: not enough on 9.2.6
2023-03-21 10:53:22 +0100 <dminuoso> pattern coverage checker has become good
2023-03-21 10:54:11 +0100 <dminuoso> Ohh no, I was thinking about considerAccessible
2023-03-21 10:54:21 +0100 <dminuoso> Ah, but perhaps I can use this.
2023-03-21 10:56:02 +0100 <dminuoso> Perhaps pattern synonym + COMPLETE is the only solution here
2023-03-21 10:57:25 +0100elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Remote host closed the connection)
2023-03-21 10:58:31 +0100 <tomsmeding> dminuoso: is that 4 a static or runtime value
2023-03-21 10:58:53 +0100 <tomsmeding> let a :> b :> c :> d :> HNil = take @4 xs
2023-03-21 10:59:28 +0100elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru)
2023-03-21 11:00:18 +0100Putonlalla(~Putonlall@it-cyan.it.jyu.fi)
2023-03-21 11:01:28 +0100 <dminuoso> tomsmeding: its static and in reality its 16.
2023-03-21 11:01:46 +0100 <dminuoso> IP addresses as usual :)
2023-03-21 11:01:56 +0100 <tomsmeding> ah :)
2023-03-21 11:02:12 +0100 <tomsmeding> but yeah, the "right" solution is to use a length-indexed vector
2023-03-21 11:02:20 +0100 <tomsmeding> where right /= most convenient
2023-03-21 11:03:12 +0100 <tomsmeding> if you feel really adventurous you can replace "take @4 xs" by "unsafeCoerce (take 4 xs)" above
2023-03-21 11:03:31 +0100 <tomsmeding> if you've checked that the HList implementation is representationally equivalent to usual lists >:D
2023-03-21 11:04:51 +0100 <tomsmeding> dminuoso: also what if xs is too short
2023-03-21 11:05:40 +0100 <Umeaboy> What am I doing wrong here? I was planning to use an already built rpm from petersen to build ghc for Mageia: https://copr.fedorainfracloud.org/coprs/umeaman/ghc/build/5685686/
2023-03-21 11:06:01 +0100 <Umeaboy> I know the package exists because I can download it manually.
2023-03-21 11:06:44 +0100 <Umeaboy> I see that it's missing an xml file, but if one uses the instructions to add external repos it should find it.
2023-03-21 11:07:04 +0100 <dminuoso> tomsmeding: its never going to happen
2023-03-21 11:07:07 +0100 <Umeaboy> I'd like some help if anyone is willing to help.
2023-03-21 11:07:15 +0100gemmaro(~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc)
2023-03-21 11:07:42 +0100 <dminuoso> tomsmeding: this is the full original line:
2023-03-21 11:07:46 +0100 <dminuoso> let [w1, w2, w3, w4, w5, w6, w7, w8, w9, w10, w11, w12, w13, w14, w15, w16] = take 16 (ws ++ repeat 0)
2023-03-21 11:07:58 +0100 <dminuoso> I kind of wish pattern coverage would *see* that cant possibly be partial.
2023-03-21 11:08:04 +0100 <tomsmeding> dminuoso: that `++ repeat 0`
2023-03-21 11:08:24 +0100 <dminuoso> tomsmeding: Dont ask.
2023-03-21 11:08:43 +0100 <tomsmeding> let w1 :> ... :> w16 :> HNil = takeStream @16 (paddedStream 0 ws)
2023-03-21 11:08:44 +0100tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
2023-03-21 11:08:52 +0100 <tomsmeding> data Stream a = More a (Stream a)
2023-03-21 11:09:22 +0100 <dminuoso> I think I may as well just use a pattern synonym then
2023-03-21 11:09:28 +0100 <tomsmeding> paddedStream p (x:xs) = x `More` paddedStream p xs ; paddedStream p [] = fix (p `More`)
2023-03-21 11:09:29 +0100 <dminuoso> rather than sprinkle hlists over this
2023-03-21 11:09:39 +0100 <tomsmeding> :p yeah
2023-03-21 11:10:14 +0100 <dminuoso> Alternatively maybe a GHC plugin!
2023-03-21 11:10:25 +0100 <tomsmeding> O.o
2023-03-21 11:10:26 +0100 <dminuoso> Id love to explain that to my colleagues.
2023-03-21 11:10:36 +0100 <dminuoso> "But there was this benign warning..
2023-03-21 11:10:50 +0100 <[Leary]> It's not like you need HList. You can just use the stream constructor itself in your pattern match, right?
2023-03-21 11:11:31 +0100 <tomsmeding> fair point
2023-03-21 11:12:02 +0100 <[Leary]> Write a `padToStream :: a -> [a] -> Stream a`, then do `let w1:.w2:. (...) = padToStream ws in (...)`.
2023-03-21 11:12:22 +0100 <[Leary]> (where data Stream a = a :. Stream a)
2023-03-21 11:13:17 +0100mbuf(~Shakthi@49.207.178.186) (Quit: Leaving)
2023-03-21 11:14:55 +0100hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 265 seconds)
2023-03-21 11:17:49 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 265 seconds)
2023-03-21 11:19:29 +0100ubert1(~Thunderbi@2a02:8109:abc0:6434:de79:4694:671d:d823)
2023-03-21 11:21:35 +0100hugo(znc@verdigris.lysator.liu.se)
2023-03-21 11:28:49 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 11:31:40 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94)
2023-03-21 11:31:50 +0100hugo(znc@verdigris.lysator.liu.se) (Ping timeout: 265 seconds)
2023-03-21 11:32:43 +0100son0p(~ff@181.136.122.143) (Ping timeout: 250 seconds)
2023-03-21 11:33:00 +0100phma(~phma@2001:5b0:211c:53d8:fa79:3596:87fb:9a7b)
2023-03-21 11:35:55 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94) (Ping timeout: 248 seconds)
2023-03-21 11:38:28 +0100hugo(znc@verdigris.lysator.liu.se)
2023-03-21 11:40:38 +0100yoneda(~mike@193.206.102.122)
2023-03-21 11:44:31 +0100jerg(~jerg@2001:a61:2611:1701:e737:6af:a06e:d388)
2023-03-21 11:49:15 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-03-21 11:49:53 +0100__monty__(~toonn@user/toonn)
2023-03-21 11:57:12 +0100chomwitt(~chomwitt@2a02:587:7a19:3600:1ac0:4dff:fedb:a3f1) (Ping timeout: 264 seconds)
2023-03-21 11:58:22 +0100freeside_(~mengwong@202.161.55.11)
2023-03-21 12:00:55 +0100freeside(~mengwong@122.11.248.245) (Ping timeout: 276 seconds)
2023-03-21 12:11:37 +0100kenaryn(~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr)
2023-03-21 12:12:00 +0100MasseR46(thelounge@2001:bc8:47a0:1521::1)
2023-03-21 12:14:56 +0100vglfr(~vglfr@88.155.27.80) (Ping timeout: 246 seconds)
2023-03-21 12:19:43 +0100 <Artem[m]> <tomsmeding> "Artem: isn't that a lambda..." <- Oh, that makes sense, thank you. Judging by the line numbers reported, it's a branch of a case, but it'd make sense that it's turned into a lambda I guess
2023-03-21 12:20:02 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 268 seconds)
2023-03-21 12:21:17 +0100nschoe(~q@141.101.51.197)
2023-03-21 12:22:03 +0100kenaryn(~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Quit: leaving)
2023-03-21 12:27:35 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-03-21 12:31:30 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-03-21 12:36:12 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 255 seconds)
2023-03-21 12:38:53 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-03-21 12:40:23 +0100 <dminuoso> Is there a reason why one might call `unmask bracket acq rel foo` rather than `bracket acq rel (unmask foo)`?
2023-03-21 12:40:41 +0100 <dminuoso> err, `unmask (bracket acq rel foo)` vs `bracket acq rel (unmask foo)`
2023-03-21 12:42:16 +0100 <Artem[m]> Actually, there's a lambda there
2023-03-21 12:43:18 +0100 <dminuoso> Oh, sure. Im just rewriting a snippet I was staring it.
2023-03-21 12:43:23 +0100 <dminuoso> Think bracket_ then.
2023-03-21 12:43:42 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-03-21 12:47:07 +0100kee(~~kee@user/wizzwizz4) (Ping timeout: 252 seconds)
2023-03-21 12:47:29 +0100euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 246 seconds)
2023-03-21 12:47:47 +0100notzmv(~zmv@user/notzmv)
2023-03-21 12:48:54 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 12:51:55 +0100kee(~~kee@user/wizzwizz4)
2023-03-21 12:53:35 +0100CiaoSen(~Jura@p200300c9571fe6002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-03-21 13:06:11 +0100xff0x(~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 264 seconds)
2023-03-21 13:06:17 +0100euandreh(~Thunderbi@189.6.18.7)
2023-03-21 13:07:57 +0100xff0x(~xff0x@178.255.149.135)
2023-03-21 13:10:42 +0100dsrt^(~dsrt@c-24-30-76-89.hsd1.ga.comcast.net) (Remote host closed the connection)
2023-03-21 13:22:33 +0100xff0x(~xff0x@178.255.149.135) (Ping timeout: 255 seconds)
2023-03-21 13:23:13 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 250 seconds)
2023-03-21 13:23:48 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2023-03-21 13:24:16 +0100xff0x(~xff0x@ai098135.d.east.v6connect.net)
2023-03-21 13:27:18 +0100razetime(~Thunderbi@117.193.0.81) (Quit: See You Space Cowboy)
2023-03-21 13:34:36 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 265 seconds)
2023-03-21 13:34:38 +0100 <Artem[m]> dminuoso: I'm sorry for not being clear but I was replying to something else (my own message above)
2023-03-21 13:34:51 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-03-21 13:36:34 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-03-21 13:41:11 +0100son0p(~ff@181.136.122.143)
2023-03-21 13:43:18 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-03-21 13:44:25 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-03-21 13:44:45 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 265 seconds)
2023-03-21 13:46:13 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de) (Ping timeout: 276 seconds)
2023-03-21 13:47:30 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de)
2023-03-21 13:57:32 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 14:01:08 +0100Guest19(~Guest19@145.107.112.113)
2023-03-21 14:04:13 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 246 seconds)
2023-03-21 14:09:42 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 14:13:45 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 14:13:59 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 14:14:20 +0100 <dminuoso> Artem[m]: Ah, well incidentally it was right in my context too. :-P
2023-03-21 14:14:36 +0100 <dminuoso> Given that bracket takes a function as its third argument bracket :: IO a -> (a -> IO b) -> (a -> IO c) -> IO c
2023-03-21 14:18:34 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de) (Ping timeout: 246 seconds)
2023-03-21 14:19:45 +0100CiaoSen(~Jura@p200300c9571fe6002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2023-03-21 14:20:40 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 276 seconds)
2023-03-21 14:23:56 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 14:31:22 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de)
2023-03-21 14:39:35 +0100vglfr(~vglfr@88.155.34.83)
2023-03-21 14:47:12 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer)
2023-03-21 14:51:11 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2023-03-21 14:51:43 +0100stackdroid18(14094@de1.hashbang.sh)
2023-03-21 14:52:33 +0100kaskal(~kaskal@089144220250.atnat0029.highway.webapn.at) (Ping timeout: 255 seconds)
2023-03-21 14:57:15 +0100notzmv(~zmv@user/notzmv) (Ping timeout: 265 seconds)
2023-03-21 15:00:43 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de) (Ping timeout: 248 seconds)
2023-03-21 15:00:48 +0100jerg(~jerg@2001:a61:2611:1701:e737:6af:a06e:d388) (Quit: Leaving)
2023-03-21 15:02:22 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de)
2023-03-21 15:04:13 +0100motherfsck(~motherfsc@user/motherfsck)
2023-03-21 15:05:21 +0100jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff)
2023-03-21 15:05:22 +0100irrgit__(~irrgit@86.106.90.226) (Read error: Connection reset by peer)
2023-03-21 15:05:42 +0100ratapaca(~ratapaca@98.40.240.33)
2023-03-21 15:06:22 +0100ratapaca(~ratapaca@98.40.240.33) (Client Quit)
2023-03-21 15:06:35 +0100jushur(~human@user/jushur)
2023-03-21 15:11:47 +0100jero98772(~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Read error: Connection reset by peer)
2023-03-21 15:18:51 +0100mmhat(~mmh@p200300f1c715f7a1ee086bfffe095315.dip0.t-ipconnect.de)
2023-03-21 15:18:53 +0100mmhat(~mmh@p200300f1c715f7a1ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2023-03-21 15:20:39 +0100kimjetwav(~user@2607:fea8:235e:b600:9f24:e4a7:bfdd:ae72) (Ping timeout: 250 seconds)
2023-03-21 15:21:19 +0100geekosaur(~geekosaur@xmonad/geekosaur) (Ping timeout: 248 seconds)
2023-03-21 15:21:44 +0100thegeekinside(~thegeekin@189.141.115.134)
2023-03-21 15:27:53 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 15:28:07 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 15:31:03 +0100CiaoSen(~Jura@p200300c9571fe6002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2023-03-21 15:33:01 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds)
2023-03-21 15:33:30 +0100vglfr(~vglfr@88.155.34.83) (Ping timeout: 255 seconds)
2023-03-21 15:33:51 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-03-21 15:34:46 +0100shriekingnoise(~shrieking@186.137.175.87)
2023-03-21 15:35:54 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.8)
2023-03-21 15:36:01 +0100geekosaur(~geekosaur@xmonad/geekosaur)
2023-03-21 15:39:28 +0100mei(~mei@user/mei) (Remote host closed the connection)
2023-03-21 15:41:55 +0100mei(~mei@user/mei)
2023-03-21 15:42:30 +0100Sgeo(~Sgeo@user/sgeo)
2023-03-21 15:42:57 +0100Square(~Square4@user/square)
2023-03-21 15:47:35 +0100vglfr(~vglfr@88.155.34.83)
2023-03-21 15:49:00 +0100chomwitt(~chomwitt@ppp-94-67-191-224.home.otenet.gr)
2023-03-21 15:50:53 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca)
2023-03-21 15:56:19 +0100jushur(~human@user/jushur) (Quit: ¯\_(ツ)_/¯)
2023-03-21 15:59:09 +0100Guest72(~Guest72@ext-1-398.eduroam.chalmers.se)
2023-03-21 15:59:39 +0100 <Guest72> Hi! Does anyone know if forkIO reuses threadIDs?
2023-03-21 16:00:03 +0100 <Guest72> Create a thread, kill it with killThread, create a new thread. What is the convention when creating the threadID of the new thread? Their lifetimes never overlapped
2023-03-21 16:00:31 +0100 <TheMatten[m]> Is there equivalent of https://gitlab.haskell.org/ghc/ghc-wasm-meta for JS backend?
2023-03-21 16:00:56 +0100lagash(lagash@lagash.shelltalk.net) (Quit: ZNC - https://znc.in)
2023-03-21 16:02:29 +0100lagash(lagash@lagash.shelltalk.net)
2023-03-21 16:03:35 +0100 <geekosaur> Guest72, it could, but if you are holding an old ThreadId then it won't (and in fact won't gc the old thread)
2023-03-21 16:04:49 +0100 <Guest72> Hm I am not retaining them, so that should be fine
2023-03-21 16:05:16 +0100 <Guest72> There does not seem to be a way to query the RTS of how many threads are alive
2023-03-21 16:08:23 +0100gemmaro(~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) (Ping timeout: 260 seconds)
2023-03-21 16:10:30 +0100 <merijn> Guest72: Threads aren't GCed until there are no more references to the ThreadId, so a threadid can never refer to a "different thread", as the original will only disappear when there's no mor references
2023-03-21 16:10:50 +0100 <merijn> ah, I'm too slow
2023-03-21 16:11:23 +0100 <Guest72> I've read the documentation, I understand that. I was merely wondering if there are any assumptions to be made of how threadIDs are generated
2023-03-21 16:12:29 +0100 <tokie> I am reading a haskell book and one of the exercises in the Applicative chapter is having me implement Functor and Applicative for a given newtype called 'Constant', and I am super stuck on how to write the pure function: https://play.haskell.org/saved/u9NPjWc0 any thoughts?
2023-03-21 16:13:23 +0100 <merijn> tokie: That type on pure seems (aka *is*) to restrictive
2023-03-21 16:13:53 +0100 <tokie> i thought the type of pure is sorta defined by the Applicative class? i.e. it must be pure a -> f a
2023-03-21 16:14:06 +0100vglfr(~vglfr@88.155.34.83) (Ping timeout: 265 seconds)
2023-03-21 16:14:16 +0100 <merijn> tokie: Yes, but you're already using 'a' for the first argument to Constant, which is probably confusing you
2023-03-21 16:14:50 +0100 <merijn> Consider rewriting the Applicative instance as "instance Monoid x => Applicative (Constant x) where pure :: a -> Constant k a"
2023-03-21 16:15:05 +0100 <merijn> eh
2023-03-21 16:15:07 +0100 <merijn> s/k/x
2023-03-21 16:16:24 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Quit: WeeChat 3.8)
2023-03-21 16:17:53 +0100 <tokie> like this? https://play.haskell.org/saved/BmMHfxX7
2023-03-21 16:18:47 +0100 <merijn> tokie: Right, at which point you should get a type error for your current implementation of pure :)
2023-03-21 16:18:49 +0100 <tokie> i would think that wouldn't work because 'a' is the type that's lifted into Constant
2023-03-21 16:18:57 +0100 <tokie> merijn: right
2023-03-21 16:19:12 +0100 <tokie> i understand that type error
2023-03-21 16:19:27 +0100 <merijn> tokie: So, to avoid spoilers, the best hint I can give is "now stare and meditate really hard what the only possible implementation could be" :)
2023-03-21 16:19:38 +0100vpan(~0@212.117.1.172) (Remote host closed the connection)
2023-03-21 16:19:40 +0100 <tokie> i do like that you didn't give the answer, lol
2023-03-21 16:19:42 +0100 <merijn> Don't forget to revisit your Functor implementation for inspiration too
2023-03-21 16:19:42 +0100 <tokie> thanks
2023-03-21 16:20:36 +0100 <merijn> tokie: Consider this: Why does your fmap implementation not use the function you give it?
2023-03-21 16:22:15 +0100 <merijn> tokie: Or, consider this, according to functor and applicative laws "fmap f (pure x)" is equivalent to "pure (f x)". So consider the implications of f = (+1) and x = 5
2023-03-21 16:22:23 +0100mastarija(~mastarija@188.252.199.22) (Quit: WeeChat 3.7.1)
2023-03-21 16:26:04 +0100lagash(lagash@lagash.shelltalk.net) (Quit: ZNC - https://znc.in)
2023-03-21 16:27:09 +0100 <Guest72> If I have tried to write some code where I continuously kill workers and spawn the same number of new ones, but the threadIDs keep increasing, does that mean that I am spawning more than I am killing?
2023-03-21 16:27:16 +0100 <Guest72> I am not retaining the ThreadIDs in any datastructures of my own
2023-03-21 16:27:36 +0100 <EvanR> Guest72, I'm kind of glad you can't find out all active threadIDs. Probably would be abused more than used for justice xD
2023-03-21 16:27:47 +0100 <Guest72> Lmao
2023-03-21 16:27:50 +0100 <Guest72> Agreed
2023-03-21 16:27:59 +0100 <Guest72> I m trying something out, feels greasy
2023-03-21 16:28:03 +0100 <Guest72> I am*
2023-03-21 16:28:05 +0100 <merijn> Guest72: Pretty sure threadids basically just increment until they roll over
2023-03-21 16:28:14 +0100 <glguy> Guest72: file descriptor behavior in POSIX is defined to reuse the lowest available number, but things like process ids typically just continually increment
2023-03-21 16:28:20 +0100 <glguy> I'd expect thread ids to work like process ids
2023-03-21 16:28:48 +0100 <Guest72> That is my understanding/guess as well, but it never hurts to ask
2023-03-21 16:28:50 +0100 <merijn> Guest72: So the ability to get a "reused" threadid is mostly theoretical
2023-03-21 16:28:58 +0100 <EvanR> if you can't observe threads remaining after welcome ran out, it's not happening
2023-03-21 16:28:58 +0100 <Guest72> Great
2023-03-21 16:29:45 +0100 <Guest72> I will assume things are fine for now
2023-03-21 16:29:51 +0100 <Guest72> We will see if things blow up
2023-03-21 16:30:32 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-03-21 16:30:42 +0100 <EvanR> you can attach a finalizer to the threads which print a final "I'm dead (threadID)"
2023-03-21 16:30:42 +0100lagash(lagash@lagash.shelltalk.net)
2023-03-21 16:31:46 +0100 <merijn> The trickiest bit is that you need to do some complicated weak reference dance if you wanna store threadids without them accidentally keeping the thread alive
2023-03-21 16:32:14 +0100 <Guest72> I have no desire to keep the threadIDs around though
2023-03-21 16:32:21 +0100 <merijn> but if you're not doing that and not doing stupid things (like trying to recover threadid's from user input), you should be fine
2023-03-21 16:32:40 +0100 <Guest72> I tried an alternative approach where I 'reset' a thread instead, but I don't have time to finish implementing this now
2023-03-21 16:32:42 +0100 <Guest72> https://stackoverflow.com/questions/75802589/haskell-asychronous-exceptions
2023-03-21 16:32:45 +0100 <Guest72> Any input is welcome
2023-03-21 16:32:54 +0100 <Guest72> I have to sign off now, but thanks for the discussion
2023-03-21 16:32:56 +0100 <EvanR> yeah a weak reference on the threadID itself, weak refs have a finalizer feature
2023-03-21 16:33:04 +0100Guest72(~Guest72@ext-1-398.eduroam.chalmers.se) (Quit: Client closed)
2023-03-21 16:36:24 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94)
2023-03-21 16:36:40 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-03-21 16:36:50 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2023-03-21 16:38:45 +0100ddellacosta(~ddellacos@146.70.165.10) (Quit: WeeChat 3.8)
2023-03-21 16:40:12 +0100ddellacosta(~ddellacos@146.70.165.10)
2023-03-21 16:40:38 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:a807:948e:ff4f:3b94) (Ping timeout: 246 seconds)
2023-03-21 16:41:45 +0100jushur(~human@user/jushur)
2023-03-21 16:47:41 +0100Guest19(~Guest19@145.107.112.113) (Quit: Client closed)
2023-03-21 16:48:38 +0100EvanR(~EvanR@user/evanr) (Quit: Leaving)
2023-03-21 16:55:40 +0100Vq(~vq@90-227-192-206-no77.tbcn.telia.com) (Ping timeout: 265 seconds)
2023-03-21 16:57:12 +0100Vq(~vq@90-227-192-206-no77.tbcn.telia.com)
2023-03-21 17:05:57 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com) (Ping timeout: 250 seconds)
2023-03-21 17:05:59 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-03-21 17:06:22 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2023-03-21 17:07:05 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-03-21 17:09:33 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-03-21 17:12:13 +0100EvanR(~EvanR@user/evanr)
2023-03-21 17:14:35 +0100 <c_wraith> EvanR: https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-Conc.html#v:listThreads
2023-03-21 17:14:44 +0100 <c_wraith> note, however, that it's still buggy
2023-03-21 17:14:57 +0100 <c_wraith> It crashes ghci if run interactively
2023-03-21 17:15:13 +0100 <EvanR> I'm flabbergasted
2023-03-21 17:16:43 +0100perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca)
2023-03-21 17:20:04 +0100 <geekosaur> <<loop>>?
2023-03-21 17:21:08 +0100sp00kins(~sp00kins@c-71-62-172-98.hsd1.va.comcast.net)
2023-03-21 17:21:57 +0100waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-03-21 17:22:35 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-03-21 17:22:49 +0100 <c_wraith> oh, it doesn't crash ghci by itself. You have to fork a few threads off first. Then you start seeing heap corruption when you call listThreads.
2023-03-21 17:23:03 +0100 <c_wraith> stuff like internal error: scavenge_one: strange object 655378800
2023-03-21 17:23:19 +0100motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 276 seconds)
2023-03-21 17:23:39 +0100 <c_wraith> so.. something is not ok in ghc 9.6.1, as yet!
2023-03-21 17:26:18 +0100 <EvanR> jeez
2023-03-21 17:27:56 +0100 <geekosaur> interesting, doesn't exist in 9.2.5
2023-03-21 17:29:50 +0100econo(uid147250@user/econo)
2023-03-21 17:37:09 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05)
2023-03-21 17:38:00 +0100 <c_wraith> no, listThreads is new to 9.6
2023-03-21 17:38:12 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05) (Remote host closed the connection)
2023-03-21 17:38:14 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:6861:4c48:824b:2934) (Quit: WeeChat 2.8)
2023-03-21 17:38:26 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05)
2023-03-21 17:38:36 +0100krei-se(~krei-se@p57af2793.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
2023-03-21 17:38:43 +0100krei-se-(~krei-se@p50874388.dip0.t-ipconnect.de)
2023-03-21 17:40:42 +0100nschoe(~q@141.101.51.197) (Ping timeout: 268 seconds)
2023-03-21 17:49:58 +0100cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-03-21 17:50:28 +0100cheater(~Username@user/cheater)
2023-03-21 17:55:34 +0100cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-03-21 17:56:54 +0100CiaoSen(~Jura@p200300c9571fe6002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2023-03-21 17:58:14 +0100lagash(lagash@lagash.shelltalk.net) (Quit: ZNC - https://znc.in)
2023-03-21 17:59:40 +0100lagash(lagash@lagash.shelltalk.net)
2023-03-21 18:01:11 +0100chele(~chele@user/chele) (Remote host closed the connection)
2023-03-21 18:05:59 +0100cheater(~Username@user/cheater)
2023-03-21 18:07:37 +0100cheater_(~Username@user/cheater)
2023-03-21 18:10:33 +0100cheater(~Username@user/cheater) (Ping timeout: 255 seconds)
2023-03-21 18:10:42 +0100cheater_cheater
2023-03-21 18:11:54 +0100tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-03-21 18:14:22 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2023-03-21 18:16:22 +0100coot_(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2023-03-21 18:18:15 +0100jushur(~human@user/jushur) (Quit: ¯\_(ツ)_/¯)
2023-03-21 18:19:46 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Ping timeout: 265 seconds)
2023-03-21 18:19:48 +0100coot_coot
2023-03-21 18:19:51 +0100jushur(~human@user/jushur)
2023-03-21 18:19:59 +0100waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 264 seconds)
2023-03-21 18:21:31 +0100waleee(~waleee@h-176-10-137-138.NA.cust.bahnhof.se)
2023-03-21 18:24:11 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-03-21 18:24:35 +0100cheater_(~Username@user/cheater)
2023-03-21 18:25:24 +0100mei(~mei@user/mei) (Ping timeout: 255 seconds)
2023-03-21 18:27:07 +0100cheater(~Username@user/cheater) (Ping timeout: 248 seconds)
2023-03-21 18:27:09 +0100cheater_cheater
2023-03-21 18:27:21 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 256 seconds)
2023-03-21 18:27:52 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 18:29:09 +0100mei(~mei@user/mei)
2023-03-21 18:31:45 +0100zeenk(~zeenk@2a02:2f04:a307:2300::7fe) (Quit: Konversation terminated!)
2023-03-21 18:31:58 +0100ubert1(~Thunderbi@2a02:8109:abc0:6434:de79:4694:671d:d823) (Quit: ubert1)
2023-03-21 18:32:05 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1))
2023-03-21 18:35:26 +0100yoneda(~mike@193.206.102.122) (Quit: leaving)
2023-03-21 18:36:50 +0100cheater_(~Username@user/cheater)
2023-03-21 18:37:50 +0100cheater__(~Username@user/cheater)
2023-03-21 18:38:11 +0100cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-03-21 18:38:15 +0100cheater__cheater
2023-03-21 18:41:36 +0100cheater_(~Username@user/cheater) (Ping timeout: 264 seconds)
2023-03-21 18:47:08 +0100troydm(~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset)
2023-03-21 18:48:14 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05) (Remote host closed the connection)
2023-03-21 18:48:25 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2023-03-21 18:49:07 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 246 seconds)
2023-03-21 18:50:47 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 18:53:13 +0100EvanR(~EvanR@user/evanr) (Quit: Leaving)
2023-03-21 18:54:04 +0100EvanR(~EvanR@user/evanr)
2023-03-21 18:54:15 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 18:54:28 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 19:01:53 +0100troydm(~troydm@user/troydm)
2023-03-21 19:05:23 +0100cheater_(~Username@user/cheater)
2023-03-21 19:07:39 +0100cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-03-21 19:07:58 +0100cheater__(~Username@user/cheater)
2023-03-21 19:07:58 +0100cheater__cheater
2023-03-21 19:09:55 +0100cheater_(~Username@user/cheater) (Ping timeout: 260 seconds)
2023-03-21 19:12:08 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 19:12:22 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 19:14:32 +0100codaraxis(~codaraxis@user/codaraxis)
2023-03-21 19:14:48 +0100gabiruh_gabiruh
2023-03-21 19:15:05 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 19:15:19 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 19:17:10 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05)
2023-03-21 19:21:06 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-03-21 19:22:20 +0100cheater_(~Username@user/cheater)
2023-03-21 19:22:31 +0100cheater(~Username@user/cheater) (Ping timeout: 260 seconds)
2023-03-21 19:22:35 +0100cheater_cheater
2023-03-21 19:23:41 +0100 <Square> Anyone know if someone works on a JVM backend, with GHC's new pluggable backend support?
2023-03-21 19:24:05 +0100lbseale_(~quassel@user/ep1ctetus)
2023-03-21 19:25:01 +0100lbseale(~quassel@user/ep1ctetus) (Ping timeout: 265 seconds)
2023-03-21 19:25:15 +0100CiaoSen(~Jura@p200300c9571fe6002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-03-21 19:29:57 +0100mei(~mei@user/mei) (Remote host closed the connection)
2023-03-21 19:32:24 +0100mei(~mei@user/mei)
2023-03-21 19:32:34 +0100vglfr(~vglfr@88.155.10.218)
2023-03-21 19:38:37 +0100jushur(~human@user/jushur) (Quit: ¯\_(ツ)_/¯)
2023-03-21 19:40:20 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-03-21 19:41:57 +0100cheater_(~Username@user/cheater)
2023-03-21 19:43:53 +0100motherfsck(~motherfsc@user/motherfsck)
2023-03-21 19:43:55 +0100cheater(~Username@user/cheater) (Ping timeout: 248 seconds)
2023-03-21 19:44:21 +0100 <[exa]> Square: there was eta but not sure what's the status of that
2023-03-21 19:45:40 +0100 <Square> [exa], last I checked it seemed like abandon ware. One could hope this new GHC functionality could make maintenance easier?
2023-03-21 19:45:47 +0100 <Square> ...for a similar project
2023-03-21 19:46:08 +0100 <[exa]> I kinda guess there's no real need for that at this point, for javafolk most of the design space is covered by scala
2023-03-21 19:46:37 +0100 <[exa]> but yeah generally it should be much simpler now
2023-03-21 19:46:46 +0100cheater_(~Username@user/cheater) (Ping timeout: 265 seconds)
2023-03-21 19:46:56 +0100 <geekosaur> my strong impression from last time this was considered is that the main reason for a JVM-backed ghc was access to Java classes, but FFIing to them would be really problematic because Java and Haskell types don't line up real well
2023-03-21 19:47:08 +0100 <[exa]> related reading: https://wiki.haskell.org/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F
2023-03-21 19:47:10 +0100 <geekosaur> also the JVM was missing some key features like tail calls at the time
2023-03-21 19:48:51 +0100 <Square> geekosaur, I think the tail call feature has been added to the JVM since.
2023-03-21 19:49:23 +0100 <geekosaur> right, but that still leaves the problem that Haskell and Java types pretty much don't mix
2023-03-21 19:49:42 +0100 <geekosaur> the old "primitive" types do, but modern Java doesn't even use them
2023-03-21 19:50:14 +0100 <Square> geekosaur, true. Java got a version of sum types recently. Not sure if that could help it along.
2023-03-21 19:50:43 +0100 <[exa]> Square: citation needed on the tail calls in jvm
2023-03-21 19:52:22 +0100 <[exa]> anyway, why java?
2023-03-21 19:52:49 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 276 seconds)
2023-03-21 19:53:16 +0100jushur(~human@user/jushur)
2023-03-21 19:53:39 +0100 <Square> [exa], googled. Seem I might be wrong. I was sure I read that somewhere. I know Scala team wanted it. https://bugs.openjdk.org/browse/JDK-6804517
2023-03-21 19:54:20 +0100 <Square> [exa], a way to migrate parts of a codebase to Haskell
2023-03-21 19:54:39 +0100 <geekosaur> tail calls will be very important for an implementation of STG for the JVM
2023-03-21 19:57:31 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 20:05:49 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-03-21 20:06:04 +0100 <[exa]> Square: plain rewrite >>>>> migrate parts
2023-03-21 20:06:16 +0100califax(~califax@user/califx)
2023-03-21 20:06:32 +0100 <Square> [exa], my superiors don't dig that =/
2023-03-21 20:07:05 +0100 <Square> [exa], any ideas on how I can convince them?
2023-03-21 20:07:05 +0100mikoto-chan(~mikoto-ch@87-95-58-79.bb.dnainternet.fi)
2023-03-21 20:08:40 +0100 <[exa]> ah you don't own the project... in that case probably better not push too much
2023-03-21 20:08:41 +0100 <Square> (I've made a very complete POC on all essential parts in semi short time, but they are dead set on partial rewrite)
2023-03-21 20:08:44 +0100 <[exa]> (or try scala)
2023-03-21 20:09:41 +0100 <Square> I used Scala professionally pre version 3. I just found Haskell >>>>> Scala.
2023-03-21 20:09:57 +0100euandreh1(~Thunderbi@189.6.18.7)
2023-03-21 20:10:42 +0100euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 255 seconds)
2023-03-21 20:10:43 +0100euandreh1euandreh
2023-03-21 20:11:23 +0100ft(~ft@p3e9bc443.dip0.t-ipconnect.de)
2023-03-21 20:14:55 +0100gurkenglas(~gurkengla@dynamic-002-247-245-038.2.247.pool.telefonica.de) (Ping timeout: 276 seconds)
2023-03-21 20:15:06 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Remote host closed the connection)
2023-03-21 20:15:20 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 20:15:39 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 255 seconds)
2023-03-21 20:16:00 +0100gurkenglas(~gurkengla@dynamic-089-204-139-175.89.204.139.pool.telefonica.de)
2023-03-21 20:16:15 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-03-21 20:18:40 +0100 <sm> Square: maybe there are are some parts you can break out as separate processes ?
2023-03-21 20:21:11 +0100machinedgod(~machinedg@node-1w7jr9yirp0ap2d6xfacos1ph.ipv6.telus.net) (Quit: Lost terminal)
2023-03-21 20:21:32 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-03-21 20:23:25 +0100stackdroid18(14094@de1.hashbang.sh) (Quit: hasta la vista... tchau!)
2023-03-21 20:26:01 +0100 <EvanR> java-bridge worked as far as I could tell but that was years ago
2023-03-21 20:26:24 +0100 <EvanR> it spawned a jvm and did a bunch of marshalling through JNI
2023-03-21 20:29:43 +0100 <shapr> I want to use inline-rust
2023-03-21 20:31:45 +0100cheater(~Username@user/cheater)
2023-03-21 20:32:11 +0100 <Square> EvanR, sm, I'll look into that
2023-03-21 20:33:24 +0100slack1256(~slack1256@181.42.50.18)
2023-03-21 20:36:28 +0100jushur(~human@user/jushur) (Quit: ¯\_(ツ)_/¯)
2023-03-21 20:37:56 +0100cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-03-21 20:38:26 +0100kimjetwav(~user@2607:fea8:235e:b600:3d66:fa8b:402c:9466)
2023-03-21 20:39:39 +0100cheater(~Username@user/cheater)
2023-03-21 20:46:25 +0100 <jean-paul[m]> There's a thing called inline-java now.
2023-03-21 20:47:09 +0100stef204(~stef204@user/stef204)
2023-03-21 20:48:43 +0100cheater(~Username@user/cheater) (Ping timeout: 276 seconds)
2023-03-21 20:52:28 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05) (Remote host closed the connection)
2023-03-21 20:52:38 +0100cheater(~Username@user/cheater)
2023-03-21 20:55:15 +0100 <Umeaboy> How come noarch is not selectable as chroot in copr? There are some noarch only packages.
2023-03-21 20:56:26 +0100vglfr(~vglfr@88.155.10.218) (Ping timeout: 246 seconds)
2023-03-21 20:57:31 +0100 <geekosaur> because, while you can have noarch packages, you cannot have a working system composed only of noarch packages
2023-03-21 20:58:35 +0100 <geekosaur> closest you get here is to build your noarch packages on multiple archs and then verify they're identical
2023-03-21 20:58:46 +0100cheater(~Username@user/cheater) (Ping timeout: 252 seconds)
2023-03-21 21:01:06 +0100cheater(~Username@user/cheater)
2023-03-21 21:01:12 +0100cheater(~Username@user/cheater) (Remote host closed the connection)
2023-03-21 21:06:29 +0100cheater(~Username@user/cheater)
2023-03-21 21:10:29 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2023-03-21 21:12:58 +0100irrgit_(~irrgit@86.106.90.226)
2023-03-21 21:20:24 +0100 <jean-paul[m]> What does "&" signify in `foreign import capi unsafe "foo.h &some_foo" ...`?
2023-03-21 21:21:24 +0100 <ddellacosta> function pointer I believe
2023-03-21 21:22:42 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2023-03-21 21:23:02 +0100trev(~trev@user/trev) (Remote host closed the connection)
2023-03-21 21:23:44 +0100 <jean-paul[m]> That was my first guess ... but some_foo doesn't appear to be anything but a regular ol' C function.
2023-03-21 21:24:09 +0100jushur(~human@user/jushur)
2023-03-21 21:24:15 +0100 <geekosaur> it means a value. (I think the intent is to suggest that the ffi is taking a pointer to the value, ,but it also works with e.g. CPP defines which don't have pointers)
2023-03-21 21:24:50 +0100 <jean-paul[m]> Ohh, right, so you get a pointer to the function ... okay, that fits.
2023-03-21 21:24:59 +0100 <jean-paul[m]> Thanks ddellacosta, geekosaur
2023-03-21 21:25:12 +0100 <EvanR> address of some_foo
2023-03-21 21:25:55 +0100kenran(~user@user/kenran)
2023-03-21 21:26:37 +0100 <geekosaur> oh, sorry, I ewas thinking of `value`. lemme dig
2023-03-21 21:28:00 +0100 <geekosaur> ah, half right. If a Haskell program needs to access a C variable bar of integer type, `foreign import ccall "&" bar :: Ptr CInt` must be used to obtain a pointer referring to the variable. The variable can be read and updated using the routines provided by the module Foreign.Storable (cf. Section 37).
2023-03-21 21:28:12 +0100 <geekosaur> (per Haskell2010)
2023-03-21 21:28:45 +0100 <geekosaur> so it's a (pointer to a) variable
2023-03-21 21:28:52 +0100mikoto-chan(~mikoto-ch@87-95-58-79.bb.dnainternet.fi) (Ping timeout: 268 seconds)
2023-03-21 21:30:09 +0100Midjak(~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
2023-03-21 21:33:00 +0100ph88(~ph88@ip5b426553.dynamic.kabel-deutschland.de)
2023-03-21 21:34:26 +0100lagash(lagash@lagash.shelltalk.net) (Quit: ZNC - https://znc.in)
2023-03-21 21:37:35 +0100lagash(lagash@lagash.shelltalk.net)
2023-03-21 21:40:59 +0100mei(~mei@user/mei) (Remote host closed the connection)
2023-03-21 21:43:17 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:f11a:e633:cebd:41d0)
2023-03-21 21:43:26 +0100mei(~mei@user/mei)
2023-03-21 21:47:58 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds)
2023-03-21 21:48:40 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 246 seconds)
2023-03-21 21:48:57 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 21:49:28 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:f11a:e633:cebd:41d0) (Quit: WeeChat 2.8)
2023-03-21 21:52:57 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05)
2023-03-21 21:53:00 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Quit: leaving)
2023-03-21 21:53:39 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-03-21 21:53:41 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 250 seconds)
2023-03-21 21:55:05 +0100slac33371(~slack1256@191.126.99.81)
2023-03-21 21:55:34 +0100slac33371(~slack1256@191.126.99.81) (Remote host closed the connection)
2023-03-21 21:55:48 +0100 <Athas> Time to go through the GHC update dance again! Every time this happens, I feel the urge to decrease my dependency footprint.
2023-03-21 21:57:27 +0100slack1256(~slack1256@181.42.50.18) (Ping timeout: 260 seconds)
2023-03-21 21:57:35 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:b104:ea11:1f21:4a05) (Ping timeout: 256 seconds)
2023-03-21 21:58:12 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 21:58:15 +0100zer0bitz(~zer0bitz@2001:2003:f443:d600:f18c:e067:2e85:d2af) (Read error: Connection reset by peer)
2023-03-21 22:02:43 +0100 <EvanR> that's it. This time no dependence on GHC
2023-03-21 22:02:53 +0100xsarnik(xsarnik@lounge.fi.muni.cz) (Quit: Ping timeout (120 seconds))
2023-03-21 22:03:08 +0100 <EvanR> chatGPT should be able to compile my haskell or at least interpret it right
2023-03-21 22:03:25 +0100xsarnik(xsarnik@lounge.fi.muni.cz)
2023-03-21 22:04:08 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-03-21 22:05:09 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-03-21 22:06:31 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-03-21 22:14:17 +0100merijn(~merijn@c-001-001-015.client.esciencecenter.eduvpn.nl)
2023-03-21 22:18:09 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-03-21 22:19:24 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-03-21 22:19:28 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-03-21 22:19:30 +0100merijn(~merijn@c-001-001-015.client.esciencecenter.eduvpn.nl) (Ping timeout: 265 seconds)
2023-03-21 22:19:41 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net) (Ping timeout: 256 seconds)
2023-03-21 22:19:48 +0100califax(~califax@user/califx)
2023-03-21 22:19:52 +0100michalz(~michalz@185.246.207.215) (Remote host closed the connection)
2023-03-21 22:20:14 +0100MironZ2(~MironZ@nat-infra.ehlab.uk)
2023-03-21 22:21:15 +0100MironZ(~MironZ@nat-infra.ehlab.uk) (Ping timeout: 248 seconds)
2023-03-21 22:21:15 +0100MironZ2MironZ
2023-03-21 22:24:25 +0100gdr3941(~user@c-73-58-202-143.hsd1.tn.comcast.net)
2023-03-21 22:28:27 +0100nschoe(~q@2a01:e0a:8e:a190:a230:bd48:1492:9e9a)
2023-03-21 22:30:07 +0100cassiopea(~cassiopea@user/cassiopea) (Ping timeout: 276 seconds)
2023-03-21 22:37:22 +0100cassiopea(~cassiopea@user/cassiopea)
2023-03-21 22:39:58 +0100 <mesaoptimizer2> EvanR: I used chatGPT-4 to migrate my project from Golang to Haskell. It was fun. Had to debug a bit of hallucination but the logic was sound in general
2023-03-21 22:40:54 +0100 <mesaoptimizer2> Hell, I spent 4.5 hours setting up emacs as an IDE for Haskell, and it took me only 6 hours to migrate the project. Things are going to be very different in an year or two
2023-03-21 22:41:42 +0100 <mesaoptimizer2> (Why did it take me 4.5 hours? Well, Fedora ghcup issues, then emacs HLS issues)
2023-03-21 22:47:08 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-03-21 22:56:00 +0100zeenk(~zeenk@2a02:2f04:a307:2300::7fe)
2023-03-21 22:57:45 +0100nullsh(nullsh@user/nexeq) (Changing host)
2023-03-21 22:57:45 +0100nullsh(nullsh@user/nullsh)
2023-03-21 22:59:14 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2023-03-21 22:59:27 +0100sp00kins(~sp00kins@c-71-62-172-98.hsd1.va.comcast.net) (Quit: sp00kins)
2023-03-21 23:03:15 +0100nschoe(~q@2a01:e0a:8e:a190:a230:bd48:1492:9e9a) (Quit: Switching off)
2023-03-21 23:08:26 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2023-03-21 23:09:20 +0100ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-03-21 23:11:10 +0100kimiamania(~65804703@user/kimiamania) (Quit: Ping timeout (120 seconds))
2023-03-21 23:11:17 +0100Umeaboy(~Umeaboy@94-255-145-133.cust.bredband2.com) (Quit: Leaving)
2023-03-21 23:11:33 +0100kimiamania(~65804703@user/kimiamania)
2023-03-21 23:11:42 +0100mjs2600(~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 265 seconds)
2023-03-21 23:11:55 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-03-21 23:12:09 +0100mjs2600(~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net)
2023-03-21 23:13:38 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Ping timeout: 265 seconds)
2023-03-21 23:14:21 +0100mei(~mei@user/mei) (Remote host closed the connection)
2023-03-21 23:16:09 +0100ec(~ec@gateway/tor-sasl/ec)
2023-03-21 23:16:42 +0100mei(~mei@user/mei)
2023-03-21 23:16:59 +0100inversed(~inversed@bcdcac82.skybroadband.com) (Quit: Connection error?!)
2023-03-21 23:19:38 +0100inversed(~inversed@bcdcac82.skybroadband.com)
2023-03-21 23:24:26 +0100 <Square> what is the notion like "exp1 / exp2" seen on anchor here called https://en.wikipedia.org/wiki/Lambda_cube#(%CE%BB%E2%86%92)_Simply_typed_lambda_calculus ? Some predicate implies something?
2023-03-21 23:25:58 +0100 <Square> Also, what is required to understand the expression? How would one actually read/word it?
2023-03-21 23:26:13 +0100 <Square> for simply typed case
2023-03-21 23:26:41 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-03-21 23:26:49 +0100 <geekosaur> did you follow the link "typing rule"?
2023-03-21 23:26:51 +0100qhong(~qhong@rescomp-21-400677.stanford.edu) (Ping timeout: 248 seconds)
2023-03-21 23:26:57 +0100 <geekosaur> (type theory has its own notation)
2023-03-21 23:28:24 +0100 <Square> geekosaur, ops. I did not. thanks
2023-03-21 23:30:30 +0100zeenk(~zeenk@2a02:2f04:a307:2300::7fe) (Quit: Konversation terminated!)
2023-03-21 23:32:40 +0100merijn(~merijn@c-001-001-015.client.esciencecenter.eduvpn.nl)
2023-03-21 23:34:49 +0100stef204(~stef204@user/stef204) (Quit: WeeChat 3.8)
2023-03-21 23:38:34 +0100lxi(~quassel@2a02:2f08:4706:3500:ae8e:3958:a6a4:da79)
2023-03-21 23:44:20 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-03-21 23:45:28 +0100codaraxis__(~codaraxis@user/codaraxis)
2023-03-21 23:45:31 +0100codaraxis(~codaraxis@user/codaraxis) (Ping timeout: 276 seconds)
2023-03-21 23:57:56 +0100 <EvanR> Square, where exactly on the page are you referring