IRCBrowse

2023/06/06

2023-06-06 00:00:05 +0200 <EvanR> not all reals that square to zero equal zero!
2023-06-06 00:00:38 +0200 <EvanR> is tattooed all over my face
2023-06-06 00:00:52 +0200barzo_(~hd@31.223.56.153) (Quit: Leaving)
2023-06-06 00:01:34 +0200alexherbo2(~alexherbo@2a02-842a-8180-4601-d889-32cf-7779-fb04.rev.sfr.net) (Remote host closed the connection)
2023-06-06 00:04:27 +0200 <EvanR> there's a countable number of fourier series, so a countable number of functions that matter. At least for writing WinAMP visualizations
2023-06-06 00:05:40 +0200 <ncf> EvanR: doesn't x² = 0 → x = 0 hold constructively? i feel like it should
2023-06-06 00:06:37 +0200falafel(~falafel@cpe-70-93-29-179.natsow.res.rr.com) (Ping timeout: 240 seconds)
2023-06-06 00:07:27 +0200 <ncf> maybe it doesn't hold in things that aren't quite the Dedekind reals though
2023-06-06 00:08:55 +0200 <monochrom> Oh! With infinitestimals like "dx" you have "dx^2 = 0 but dx ≠ 0"
2023-06-06 00:09:27 +0200 <hpc> are they reals though?
2023-06-06 00:09:32 +0200 <monochrom> No.
2023-06-06 00:09:45 +0200 <monochrom> Ah, right, "real" was mentioned, heh.
2023-06-06 00:09:56 +0200 <EvanR> the nilpotent infinitesimals from SDG are subsets of the real line
2023-06-06 00:10:44 +0200 <EvanR> a subset
2023-06-06 00:11:44 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-06-06 00:12:26 +0200 <ncf> for some slightly different definition of the real line, possibly
2023-06-06 00:12:39 +0200 <ncf> > In E, the axiom of microaffinity and related axioms hold for the ring y(R1). [Technical comment: This ring will usually not be the ring of Dedekind real numbers in E.]
2023-06-06 00:12:40 +0200 <lambdabot> <hint>:1:5: error: parse error on input ‘,’
2023-06-06 00:12:44 +0200 <ncf> (from https://rawgit.com/iblech/internal-methods/master/slides-leipzig2018.pdf)
2023-06-06 00:12:54 +0200 <EvanR> no definition needed, just say "in a suitable closed cartesian category" or some such
2023-06-06 00:13:22 +0200 <ncf> well the reals aren't exactly part of the structure of a ccc :p
2023-06-06 00:13:33 +0200 <EvanR> "suitable"
2023-06-06 00:13:45 +0200user____3(~user@dynamic-046-114-181-157.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-06-06 00:13:51 +0200 <ncf> that's where the definition is then
2023-06-06 00:14:57 +0200 <EvanR> foundations just get in the way, get the good stuff
2023-06-06 00:15:02 +0200 <EvanR> get to the*
2023-06-06 00:15:35 +0200blackpill0w(~blackpill@user/blackpill0w)
2023-06-06 00:16:01 +0200 <EvanR> pay no attention to the money I spent to have the one true definition of real numbers crammed down my throat, no one has a monopoly on maths
2023-06-06 00:18:09 +0200 <EvanR> kock-lawvere axiom can be used to prove not all reals that square to zero equal zero. It also violates the law of excluded middle, which is what makes it constructive
2023-06-06 00:20:09 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-06-06 00:23:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 00:24:02 +0200 <hpc> doesn't constructive just mean independent of LEM?
2023-06-06 00:26:13 +0200 <ncf> yeah, i guess some would use 'intuitionistic' instead. not that it matters a lot, but 'constructive axiom' sounds a bit like an antinomy
2023-06-06 00:31:07 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2023-06-06 00:31:46 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 00:32:05 +0200blackpill0w(~blackpill@user/blackpill0w) (Quit: Leaving)
2023-06-06 00:34:20 +0200 <EvanR> to be allowed in constructive fight club you have to prove yourself by beating a LEM piñata or similar rite of passage
2023-06-06 00:35:07 +0200 <EvanR> but yeah that axiom is not independent
2023-06-06 00:35:18 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-06-06 00:35:35 +0200euandreh(~Thunderbi@189.6.18.7)
2023-06-06 00:37:18 +0200 <EvanR> "Either the one or the other has to leave the scene" --kock
2023-06-06 00:37:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 00:38:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 00:43:08 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-06-06 00:43:27 +0200euandreh(~Thunderbi@189.6.18.7)
2023-06-06 00:47:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 00:50:06 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:00:39 +0200reach(~reach@2607:fea8:4c0:990:399a:69de:44e1:1e42)
2023-06-06 01:02:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 01:05:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:06:57 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-06-06 01:09:45 +0200paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
2023-06-06 01:11:47 +0200mauke_(~mauke@user/mauke)
2023-06-06 01:12:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 01:12:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:13:08 +0200mauke(~mauke@user/mauke) (Ping timeout: 240 seconds)
2023-06-06 01:13:08 +0200mauke_mauke
2023-06-06 01:13:41 +0200machinedgod(~machinedg@93-136-226-84.adsl.net.t-com.hr) (Ping timeout: 256 seconds)
2023-06-06 01:15:23 +0200euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 256 seconds)
2023-06-06 01:15:49 +0200euandreh(~Thunderbi@189.6.18.7)
2023-06-06 01:18:05 +0200paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com)
2023-06-06 01:18:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 01:21:34 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:27:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 01:28:17 +0200acidjnk(~acidjnk@p200300d6e7072f49f87e9b16d0682c76.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-06-06 01:28:58 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:35:29 +0200reach(~reach@2607:fea8:4c0:990:399a:69de:44e1:1e42) (Ping timeout: 265 seconds)
2023-06-06 01:42:46 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-06-06 01:45:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 01:46:32 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:47:03 +0200segfaultfizzbuzz(~segfaultf@23.93.74.212)
2023-06-06 01:47:36 +0200 <segfaultfizzbuzz> "Widely used math libraries (e.g., libm in glibc or Intel’s math library) do not produce correctly rounded results for all inputs." <-- fascinating
2023-06-06 01:48:08 +0200 <segfaultfizzbuzz> from: https://dl.acm.org/doi/pdf/10.1145/3434310
2023-06-06 01:49:00 +0200 <EvanR> table maker's dilemma?
2023-06-06 01:50:05 +0200ham(~ham@user/ham)
2023-06-06 01:52:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 01:55:12 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 01:56:13 +0200 <segfaultfizzbuzz> EvanR: what's that?
2023-06-06 01:56:23 +0200 <segfaultfizzbuzz> which wrong value to use in a mathematical table?
2023-06-06 02:04:05 +0200cheater(~Username@user/cheater) (Read error: Connection reset by peer)
2023-06-06 02:04:51 +0200cheater(~Username@user/cheater)
2023-06-06 02:12:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 02:13:57 +0200segfaultfizzbuzz(~segfaultf@23.93.74.212) (Ping timeout: 250 seconds)
2023-06-06 02:14:09 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 02:23:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 02:25:22 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 02:29:34 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:581a:6724:1eaa:89a2)
2023-06-06 02:33:28 +0200xff0x_(~xff0x@ai098135.d.east.v6connect.net) (Ping timeout: 240 seconds)
2023-06-06 02:33:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 02:35:47 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 02:39:00 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2023-06-06 02:45:07 +0200oo_miguel(~Thunderbi@77.252.47.84) (Ping timeout: 240 seconds)
2023-06-06 02:45:26 +0200nate2(~nate@98.45.169.16)
2023-06-06 02:54:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 02:55:25 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 02:57:22 +0200boukenshaou(~Boukensha@223.178.84.62) (Remote host closed the connection)
2023-06-06 03:04:31 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-06 03:06:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 03:09:58 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 03:10:41 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-06-06 03:13:24 +0200wroathe(~wroathe@207.153.38.140)
2023-06-06 03:13:24 +0200wroathe(~wroathe@207.153.38.140) (Changing host)
2023-06-06 03:13:24 +0200wroathe(~wroathe@user/wroathe)
2023-06-06 03:16:48 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-06-06 03:16:53 +0200xff0x_(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-06-06 03:16:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 03:21:40 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 03:31:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 03:34:29 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 03:41:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 03:42:34 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 03:43:02 +0200reach(~reach@2607:fea8:4c0:990:399a:69de:44e1:1e42)
2023-06-06 03:44:27 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:1021:1d21:ada2:fc1d)
2023-06-06 03:48:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 03:48:37 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-06-06 03:48:51 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:1021:1d21:ada2:fc1d) (Ping timeout: 250 seconds)
2023-06-06 03:49:11 +0200reach(~reach@2607:fea8:4c0:990:399a:69de:44e1:1e42) (Remote host closed the connection)
2023-06-06 03:51:07 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 03:56:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 03:57:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 03:58:48 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-06-06 04:00:11 +0200telser(~quassel@user/telser) (Ping timeout: 246 seconds)
2023-06-06 04:01:46 +0200telser(~quassel@user/telser)
2023-06-06 04:02:43 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:581a:6724:1eaa:89a2) (Ping timeout: 250 seconds)
2023-06-06 04:02:48 +0200[_](~itchyjunk@user/itchyjunk/x-7353470)
2023-06-06 04:03:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 04:03:31 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 240 seconds)
2023-06-06 04:03:56 +0200[_][itchyjunk]
2023-06-06 04:05:06 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 04:06:41 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e)
2023-06-06 04:09:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 04:11:01 +0200zaquest(~notzaques@5.130.79.72) (Remote host closed the connection)
2023-06-06 04:12:45 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 04:17:03 +0200zaquest(~notzaques@5.130.79.72)
2023-06-06 04:19:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 04:21:33 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-06-06 04:21:33 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-06-06 04:21:33 +0200finn_elijaFinnElija
2023-06-06 04:23:16 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 04:32:22 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
2023-06-06 04:33:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 04:33:44 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 04:36:46 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:1021:1d21:ada2:fc1d)
2023-06-06 04:39:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 04:40:36 +0200mei(~mei@user/mei) (Ping timeout: 265 seconds)
2023-06-06 04:41:17 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 04:44:57 +0200mei(~mei@user/mei)
2023-06-06 04:52:07 +0200td_(~td@i53870929.versanet.de) (Ping timeout: 240 seconds)
2023-06-06 04:54:15 +0200td_(~td@i53870912.versanet.de)
2023-06-06 04:55:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 04:58:40 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 05:09:01 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e) (Remote host closed the connection)
2023-06-06 05:10:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 05:10:33 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 256 seconds)
2023-06-06 05:12:21 +0200rekahsoft(~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca)
2023-06-06 05:12:57 +0200rekahsoft(~rekahsoft@bras-base-orllon1122w-grc-04-174-88-193-177.dsl.bell.ca) (Remote host closed the connection)
2023-06-06 05:14:56 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 05:22:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 05:25:29 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 250 seconds)
2023-06-06 05:26:20 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 05:26:49 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-06-06 05:30:11 +0200motherfs1(~motherfsc@user/motherfsck)
2023-06-06 05:32:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 05:36:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 05:42:49 +0200ec_(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-06-06 05:43:12 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 05:45:45 +0200nate2(~nate@98.45.169.16)
2023-06-06 05:50:12 +0200nate2(~nate@98.45.169.16) (Ping timeout: 250 seconds)
2023-06-06 05:52:48 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Ping timeout: 250 seconds)
2023-06-06 05:57:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 05:59:07 +0200tzh(~tzh@24.21.73.154)
2023-06-06 05:59:17 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 06:00:51 +0200 <Clinton[m]> When I do the following:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/d0727032e48f0dc9c105d3ca3f03de625dee…>)
2023-06-06 06:01:26 +0200 <Clinton[m]> * When I do the following:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6c08f15f23b34f431d785a044a3021412e1c…>)
2023-06-06 06:06:19 +0200 <c_wraith> That mostly comes down to m being fully unconstrained. I realize it's a simplified example, but why do you have that?
2023-06-06 06:07:05 +0200 <c_wraith> like, the only value of type `forall m. m a' is bottom
2023-06-06 06:07:32 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds)
2023-06-06 06:09:32 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-06-06 06:11:06 +0200 <Clinton[m]> c_wraith: I was just simplifying the example. This has the same problem:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/743a6c888ed6b108b797bf2f5b638f922265…>)
2023-06-06 06:12:22 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-06-06 06:12:31 +0200 <Clinton[m]> * c_wraith: I was just simplifying the example. This has the same problem:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/e089360c81e5d13d15554b5712cb82044c28…>)
2023-06-06 06:12:40 +0200 <Clinton[m]> * c_wraith: I was just simplifying the example. This has the same problem, with no bottoms:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/930dc762294d5a2f9a5590d6fe0823609913…>)
2023-06-06 06:13:30 +0200 <EvanR> Clinton your matrix bridge has a serious echo effect now
2023-06-06 06:14:18 +0200 <Clinton[m]> EvanR: Sorry? My matrix bridge?
2023-06-06 06:14:56 +0200 <Clinton[m]> * matrix bridge? I didn't know I had one.
2023-06-06 06:15:15 +0200 <EvanR> https://i.imgur.com/gxtk9Jc.png
2023-06-06 06:15:37 +0200 <glguy> when you edit your message it retransmits
2023-06-06 06:20:16 +0200chromoblob(~user@37.113.158.8)
2023-06-06 06:26:27 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 265 seconds)
2023-06-06 06:26:35 +0200m5zs7k(aquares@web10.mydevil.net) (Ping timeout: 250 seconds)
2023-06-06 06:26:44 +0200 <c_wraith> Clinton[m]: what you really want is some way of putting a Representational role on m, but I don't know how to do that for something that's used only inside another definition
2023-06-06 06:27:02 +0200m5zs7k(aquares@web10.mydevil.net)
2023-06-06 06:27:59 +0200 <c_wraith> or rather, on m's argument.
2023-06-06 06:28:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 06:29:12 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 06:30:25 +0200 <sm> Clinton: in other words, editing and quoting previous messages is noisy for the native IRC users here, so best to do those sparingly
2023-06-06 06:31:21 +0200 <jackdk> May be possible to adapt the QuantifiedConstraints trick in https://ryanglscott.github.io/2018/03/04/how-quantifiedconstraints-can-let-us-put-join-back-in-mon… but I can't figure out how to do it with `m` not being the typeclass parameter
2023-06-06 06:32:26 +0200myxos(~myxos@cpe-65-28-251-121.cinci.res.rr.com) (Ping timeout: 246 seconds)
2023-06-06 06:36:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 06:37:15 +0200bliminse(~bliminse@user/bliminse) (Remote host closed the connection)
2023-06-06 06:37:29 +0200motherfsck(~motherfsc@user/motherfsck) (Quit: quit)
2023-06-06 06:39:53 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 06:42:29 +0200falafel(~falafel@cpe-70-93-29-179.natsow.res.rr.com)
2023-06-06 06:44:00 +0200myxos(~myxos@cpe-65-28-251-121.cinci.res.rr.com)
2023-06-06 06:47:26 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e)
2023-06-06 06:51:58 +0200 <Clinton[m]> Here's the answer, I actually used this trick in a library I wrote 5 years ago when I was trying to learn Haskell (properly): https://hackage.haskell.org/package/map-classes... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/58a21be0f37d792ef99a477a366ea2936d49…>)
2023-06-06 06:54:31 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-06-06 06:58:54 +0200 <c_wraith> ah, that's nice. I was looking for something in that direction, but Coyoneda is a nice touch.
2023-06-06 07:00:55 +0200trev(~trev@user/trev)
2023-06-06 07:00:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 07:01:08 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 246 seconds)
2023-06-06 07:03:53 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 07:10:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 07:12:05 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 07:13:20 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 07:15:58 +0200bliminse(~bliminse@user/bliminse)
2023-06-06 07:19:03 +0200coot(~coot@89.69.206.216)
2023-06-06 07:20:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 07:24:08 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 07:24:39 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 250 seconds)
2023-06-06 07:24:44 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-06-06 07:26:25 +0200thegeekinside(~thegeekin@189.217.90.138) (Ping timeout: 240 seconds)
2023-06-06 07:26:47 +0200thegeekinside(~thegeekin@189.217.90.138)
2023-06-06 07:29:58 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-06-06 07:30:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 07:33:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 07:39:08 +0200titibandit(~titibandi@user/titibandit)
2023-06-06 07:51:53 +0200michalz(~michalz@185.246.207.197)
2023-06-06 07:56:40 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-06-06 07:56:57 +0200chromoblob(~user@37.113.158.8)
2023-06-06 08:03:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 08:04:42 +0200jonathan_(~jonathan@83.177.239.48)
2023-06-06 08:07:07 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 08:08:55 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:1021:1d21:ada2:fc1d) (Ping timeout: 265 seconds)
2023-06-06 08:11:27 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds)
2023-06-06 08:12:11 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:24fa:d550:62e1:3add)
2023-06-06 08:12:48 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-06-06 08:13:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 08:16:51 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 08:17:08 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 265 seconds)
2023-06-06 08:19:03 +0200jonathan_(~jonathan@83.177.239.48) (Read error: Connection reset by peer)
2023-06-06 08:23:17 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 08:25:45 +0200titibandit(~titibandi@user/titibandit) (Ping timeout: 240 seconds)
2023-06-06 08:28:19 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-06-06 08:32:09 +0200forell(~forell@user/forell) (Ping timeout: 265 seconds)
2023-06-06 08:42:00 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-06-06 08:42:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 08:43:02 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 08:44:01 +0200acidjnk(~acidjnk@p200300d6e7072f266d84e9375f346e43.dip0.t-ipconnect.de)
2023-06-06 08:45:07 +0200mauke(~mauke@user/mauke) (Ping timeout: 240 seconds)
2023-06-06 08:48:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 08:48:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 08:51:12 +0200cfricke(~cfricke@user/cfricke)
2023-06-06 08:53:01 +0200paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (Remote host closed the connection)
2023-06-06 08:56:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 08:57:48 +0200perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca) (Ping timeout: 240 seconds)
2023-06-06 08:59:21 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 08:59:34 +0200paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com)
2023-06-06 09:01:07 +0200taupiqueur3(~taupiqueu@2a02:842a:8180:4601:5472:ee1d:5e4f:9dc7)
2023-06-06 09:03:01 +0200taupiqueur2(~taupiqueu@2a02-842a-8180-4601-d889-32cf-7779-fb04.rev.sfr.net) (Ping timeout: 240 seconds)
2023-06-06 09:04:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 09:04:45 +0200titibandit(~titibandi@user/titibandit)
2023-06-06 09:04:55 +0200gensyst(~gensyst@user/gensyst)
2023-06-06 09:06:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 09:09:17 +0200 <gensyst> Can forkOn be used as an alternative to forkOS? I.e., does a **capability** also stick to one OS thread for foreign calls?
2023-06-06 09:10:59 +0200 <dminuoso> gensyst: No, a capability can have multiple OS threads.
2023-06-06 09:12:37 +0200 <gensyst> dminuoso, do you know where i could find this in documentation?
2023-06-06 09:12:51 +0200 <dminuoso> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/scheduler#capabilities
2023-06-06 09:13:05 +0200 <dminuoso> A capability is more like a virtual CPU.
2023-06-06 09:13:37 +0200 <dminuoso> Note in this section `A list of worker threads [is one of the important components of a Capability]`
2023-06-06 09:14:18 +0200 <gensyst> nice
2023-06-06 09:14:30 +0200 <dminuoso> Or maybe think of it as an STG cpu
2023-06-06 09:14:41 +0200falafel(~falafel@cpe-70-93-29-179.natsow.res.rr.com) (Ping timeout: 265 seconds)
2023-06-06 09:14:58 +0200perrierjouet(~perrier-j@modemcable048.127-56-74.mc.videotron.ca)
2023-06-06 09:15:15 +0200 <dminuoso> It's Tasks that have a 1-to-1 corresponce to OS threads.
2023-06-06 09:16:24 +0200chele(~chele@user/chele)
2023-06-06 09:16:41 +0200 <dminuoso> I dont quite understand when forkOn is really useful, its haddock documentation is somewhat lacking.
2023-06-06 09:16:55 +0200 <gensyst> I didn't even know about this wiki.
2023-06-06 09:17:18 +0200 <dminuoso> Yeah GHC has a very extensive wiki.
2023-06-06 09:19:59 +0200 <gensyst> dminuoso, is it possible to keep a forkOS bound thread alive for future use? so: A. ask the system to "keep thread alive". B. execute normal things on the bound thread. C. install a handler (GC finalizer) that gets (potentially sometime later) called on the *same* bound thread. D. after normal termination of my code, i uninstall the handler.
2023-06-06 09:20:22 +0200 <gensyst> s/uninstall the handler/uninstall the handler and ask system to "no longer keep thread alive"
2023-06-06 09:20:56 +0200 <dminuoso> gensyst: Of course. Use an MVar or TVar to communicate runnable things with that thread.
2023-06-06 09:21:08 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 240 seconds)
2023-06-06 09:21:25 +0200 <dminuoso> Keeping it alive amounts to just reading off that MVar/TVar in an infinite loop.
2023-06-06 09:22:13 +0200kmein_kmein
2023-06-06 09:22:26 +0200 <dminuoso> And a "handler" would amount to just some `finally` or an exit branch in `readTVarIO \case Exit -> ...`
2023-06-06 09:23:31 +0200 <gensyst> dminuoso, i tried doing a channel for this but this has too much overhead (we're talking crazy tens of microseconds per call). Therefore I want to have my normal ordinary code (non-finalizer) just be on the same fixed bound thread (no MVars involved). It would be OK though if the finalizer only had to involve MVars.
2023-06-06 09:24:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 09:24:56 +0200 <gensyst> so, it turned out that switching between threads in a tight loop is a no-go. so that sort of thing won't work for me for the *normal code*.
2023-06-06 09:25:04 +0200 <dminuoso> gensyst: So in principle attaching a finalizer could be done with a simple IO wrapper.
2023-06-06 09:25:15 +0200 <dminuoso> There
2023-06-06 09:26:26 +0200forell(~forell@user/forell)
2023-06-06 09:26:58 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 09:27:51 +0200 <dminuoso> Say some equivalent of a `newtype IOKeep t a = IOKeep { runIOKeep :: ReaderT t (IO a) } deriving MonadIO`
2023-06-06 09:29:17 +0200mc47(~mc47@xmonad/TheMC47)
2023-06-06 09:29:32 +0200 <dminuoso> Alternatively you could perhaps use qualified do-notation/rebindable syntax/manual (>>=)/(>>)/fmap/(<*>) replacement that uses touch# everywhere.
2023-06-06 09:29:46 +0200 <dminuoso> But I would go with that IOKeep first maybe
2023-06-06 09:30:07 +0200ddellacosta(~ddellacos@146.70.171.100) (Ping timeout: 240 seconds)
2023-06-06 09:30:22 +0200 <dminuoso> As for a something better than a TChan.. I dont know.
2023-06-06 09:31:17 +0200zaidhaan(~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9)
2023-06-06 09:31:24 +0200 <dminuoso> Ah you could even use https://hackage.haskell.org/package/base-4.18.0.0/docs/System-Mem-Weak.html#v:addFinalizer instead of touch#
2023-06-06 09:31:28 +0200 <dminuoso> Is probably more comfortable
2023-06-06 09:31:50 +0200zaidhaan(~zai@2001:f40:960:1c54:3c0f:370:d2d1:4fb9) (Client Quit)
2023-06-06 09:32:06 +0200ddellacosta(~ddellacos@143.244.47.72)
2023-06-06 09:34:03 +0200 <gensyst> dminuoso, the finalizer i mentioned was indeed done with mkWeakIORef, but the problem is there was no guarantee it would execute on the same original bound thread
2023-06-06 09:34:13 +0200gmg(~user@user/gehmehgeh)
2023-06-06 09:34:18 +0200 <dminuoso> Mmm
2023-06-06 09:34:18 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 09:34:35 +0200 <gensyst> (this was btw my motivation to ask about forkOn - whether i could somehow execute the thing on the original thread (after keeping the original thread alive somehow))
2023-06-06 09:34:35 +0200 <dminuoso> Well, you can forkOS a finalizer thread that waits on an MVar.
2023-06-06 09:34:37 +0200 <dminuoso> Ohh
2023-06-06 09:34:40 +0200 <dminuoso> Hold on, that's what you had.
2023-06-06 09:34:46 +0200 <dminuoso> I recall the previous discussion
2023-06-06 09:35:13 +0200 <dminuoso> No actually, you should be able to do *that*
2023-06-06 09:35:28 +0200 <dminuoso> forkOS a thread that waits on an MVar, and in the finalizer you just put a token into the MVar.
2023-06-06 09:36:03 +0200 <gensyst> dminuoso, but i still have to execute the normal code on that thread first..
2023-06-06 09:36:14 +0200 <dminuoso> gensyst: You can have multiple bound threads.
2023-06-06 09:36:28 +0200 <gensyst> it needs to be the same (due to c ffi)
2023-06-06 09:36:44 +0200 <gensyst> (thread local state stuff)
2023-06-06 09:37:20 +0200 <dminuoso> Mmm
2023-06-06 09:37:41 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-06 09:37:55 +0200 <Profpatsch> I can lift an Applicative into a Monoid with Ap, but can I get a Monoid instance out of an Applicative somehow? Does that even make sense?
2023-06-06 09:38:56 +0200 <Profpatsch> Probably not
2023-06-06 09:38:58 +0200 <dminuoso> Profpatsch: In a categorical sense applicatives are monoids
2023-06-06 09:39:05 +0200 <dminuoso> If you're just after something monoidy looking.
2023-06-06 09:39:38 +0200 <dminuoso> Profpatsch: Though whats wrong with Ap.
2023-06-06 09:39:59 +0200 <Profpatsch> In particular, I want to define a thingy that combines a parser and a json schema encoding
2023-06-06 09:40:48 +0200 <Profpatsch> My parser is a normal applicative, and my schema encoder was a Map [Text] Encoding before, which is Monoid so the full type is isomorphic to (Map [Text] Encoding, Parser a) which is Applicative
2023-06-06 09:41:33 +0200srk(~sorki@user/srk) (Remote host closed the connection)
2023-06-06 09:41:52 +0200srk(~sorki@user/srk)
2023-06-06 09:42:16 +0200 <Profpatsch> But turning the Map [Text] into a nested schema is kind of a bore, and I can’t easily add more fields to the recursive “layers” (it’s a tree of objects with annotations and encodings at the leaves), so I thought about using Free AnnF Encoding instead
2023-06-06 09:42:22 +0200 <Profpatsch> but that’s not Monoid
2023-06-06 09:42:42 +0200hisa380(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net)
2023-06-06 09:43:15 +0200lewisje(~lewisje@74.215.20.3) (Quit: Leaving)
2023-06-06 09:43:19 +0200 <dminuoso> gensyst: So Im just staring at the RTS, and it seems that if you forkOS inside a bound thread, the implementation currently will put it on the same OS thread.
2023-06-06 09:43:42 +0200 <dminuoso> Look at how forkOS_createThread just calls phread_create(&tid, NULL, forkOS_createThreadWrapper, (void*)entry);
2023-06-06 09:44:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 09:44:16 +0200 <dminuoso> So if Im right, you should be able to double forkOS (such that you can kick off a finalizer worker that waits on an MVar in the main thread)
2023-06-06 09:44:31 +0200hisa38(~hisa38@104-181-102-238.lightspeed.wepbfl.sbcglobal.net) (Ping timeout: 240 seconds)
2023-06-06 09:44:31 +0200hisa380hisa38
2023-06-06 09:45:06 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 09:45:13 +0200 <Profpatsch> gensyst: like https://hackage.haskell.org/package/unagi-chan for example
2023-06-06 09:45:38 +0200 <gensyst> dminuoso, interesting! but after doing forkOS, can i always just keep running subsequent code, even if the previous forkOS is just waiting? (I'm guessing that's fine because normall Haskell code, including an infinite mvar waiting.) just runs normally on any haskell thread and only the C FFI run on the os thread. So there's no OS thread that's blocking.
2023-06-06 09:46:08 +0200 <gensyst> s/waiting,)/waiting,
2023-06-06 09:46:33 +0200 <dminuoso> gensyst: the forkOS itself is not waiting.
2023-06-06 09:46:54 +0200 <dminuoso> But honestly I dont know what the RTS is *supposed* to do here.
2023-06-06 09:46:59 +0200nate2(~nate@98.45.169.16)
2023-06-06 09:47:13 +0200 <dminuoso> Given that double forkOS does not give you a documented guarantee
2023-06-06 09:48:26 +0200 <gensyst> dminuoso, that might call for a new "forkOSSame ::"? might be worth asking for?
2023-06-06 09:48:51 +0200 <dminuoso> gensyst: No clue, this type of discussion is better held in #ghc, the mailing list or the GHC issue tracker.
2023-06-06 09:50:04 +0200 <dminuoso> gensyst: Most of the code surrounding this is very old and was written by Simon Marlow.
2023-06-06 09:50:12 +0200 <dminuoso> Might want to ping him perhaps
2023-06-06 09:50:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 09:51:31 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-06-06 09:52:11 +0200 <dminuoso> gensyst: Note when I say `double forkOS` I mean it in a nested fashion of course.
2023-06-06 09:52:35 +0200 <dminuoso> `forkOS f >> forkOS f` gives you no guarantees (since there could be preemption in between them, with the second IO action being executed in another Taskj)
2023-06-06 09:53:00 +0200 <dminuoso> So something like `forkOS (forkOS f >> f)`
2023-06-06 09:53:11 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 09:54:24 +0200 <dminuoso> It largely boils down to what rts_evalStableIO does really
2023-06-06 09:55:36 +0200 <Profpatsch> gensyst: why are you trying to cross the C/Haskell FFI interface in a tight loop in the first place anyway?
2023-06-06 09:55:46 +0200 <Profpatsch> Nothing good can come of this
2023-06-06 09:56:21 +0200 <Profpatsch> Chunk it up to bigger things on the C side, something that’s a few ms of work at least
2023-06-06 09:57:04 +0200 <Profpatsch> I think even if you get past this MVar problem, you will probably notice that C FFI is not free in that it also takes a considerable amount of time to context switch (at least iirc)
2023-06-06 09:57:24 +0200 <Profpatsch> Maybe I’m wrong, but I’d be surprised
2023-06-06 09:59:02 +0200 <dminuoso> gensyst: It's relatively crazy that forkOS isnt built upon haskell threads.
2023-06-06 09:59:28 +0200 <merijn> dminuoso: It is? Unless I misunderstand what you mean?
2023-06-06 09:59:31 +0200 <dminuoso> Ah but hold on -> no now that I understand how it works, nested forkOS wont work.
2023-06-06 09:59:38 +0200CiaoSen(~Jura@145.224.74.19)
2023-06-06 09:59:53 +0200 <ncf> monochrom: your insight appears in the beginning of chapter 4 in Escardó's "Synthetic topology of data types and classical spaces" (i am reading it now)
2023-06-06 10:00:22 +0200 <dminuoso> merijn: Its not. Its a bare bone pthread_create that directly calls into rts_evalStableIO
2023-06-06 10:00:39 +0200 <dminuoso> Which is a variant of rts_evalStableIOMain
2023-06-06 10:00:55 +0200 <merijn> dminuoso: Which is a Haskell threat? :p
2023-06-06 10:00:59 +0200 <merijn> *thread
2023-06-06 10:01:08 +0200 <dminuoso> mmm
2023-06-06 10:01:56 +0200titibandit(~titibandi@user/titibandit) (Ping timeout: 268 seconds)
2023-06-06 10:04:20 +0200 <dminuoso> merijn: How is forkOS pinned to a particular OS thread then?
2023-06-06 10:05:37 +0200m5zs7k(aquares@web10.mydevil.net) (Ping timeout: 240 seconds)
2023-06-06 10:05:42 +0200 <dminuoso> Is it rts_lock()?
2023-06-06 10:06:03 +0200m5zs7k(aquares@web10.mydevil.net)
2023-06-06 10:06:08 +0200 <merijn> dminuoso: Keep in mind I haven't looked at the actual implementation, but afaik the only way threads move from capabilities is via work stealing
2023-06-06 10:06:17 +0200 <merijn> so I imagine they just have a flag set that prevents stealing
2023-06-06 10:06:23 +0200 <dminuoso> merijn: No, there's no such flag.
2023-06-06 10:06:46 +0200 <dminuoso> There's virtually no difference between rts_evalStableIO and rts_evalStableIOMain other than some top level handler stuff
2023-06-06 10:06:59 +0200 <dminuoso> However, forkOS surrounds its rts_evalStableIO call with rts_lock and rts_unlock
2023-06-06 10:08:12 +0200 <dminuoso> Ahh.. indeed.
2023-06-06 10:08:18 +0200 <dminuoso> rts_lock bounds the current task
2023-06-06 10:08:38 +0200 <int-e> dminuoso: https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/Schedule.c#L341-356 is one possible alternative starting point for digging deeper
2023-06-06 10:10:17 +0200chromoblob(~user@37.113.158.8)
2023-06-06 10:10:40 +0200 <dminuoso> int-e: Okay yeah that fits my findings. So rts_lock() bounds the current task, then the rts_eval* stuff can run which puts it on the runqueue.
2023-06-06 10:12:45 +0200MQ-17J(~MQ-17J@104.28.248.165)
2023-06-06 10:12:49 +0200MQ-17J(~MQ-17J@104.28.248.165) (Client Quit)
2023-06-06 10:13:29 +0200titibandit(~titibandi@user/titibandit)
2023-06-06 10:14:16 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-06-06 10:15:04 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 265 seconds)
2023-06-06 10:15:40 +0200 <dminuoso> Ah shame
2023-06-06 10:15:42 +0200 <dminuoso> do mv <- newEmptyMVar; forkOS (forkIO (putMVar mv =<< isCurrentThreadBound) >> pure ()); print =<< readMVar mv
2023-06-06 10:15:44 +0200 <dminuoso> Gives me a `False`.
2023-06-06 10:16:31 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-06-06 10:16:33 +0200 <int-e> as it should, otherwise all threads forked from `main` would be bound.
2023-06-06 10:16:47 +0200 <dminuoso> Why would they? Is main bound?
2023-06-06 10:16:50 +0200 <int-e> yes
2023-06-06 10:17:48 +0200 <int-e> (if you use the threaded RTS)
2023-06-06 10:18:04 +0200 <dminuoso> That's interesting
2023-06-06 10:19:07 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-06-06 10:19:33 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-06-06 10:23:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 10:26:31 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 10:27:26 +0200tzh(~tzh@24.21.73.154) (Quit: zzz)
2023-06-06 10:31:32 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 265 seconds)
2023-06-06 10:31:50 +0200jargon(~jargon@184.101.71.62) (Remote host closed the connection)
2023-06-06 10:38:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 10:39:31 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds)
2023-06-06 10:39:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 10:42:47 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 10:45:28 +0200machinedgod(~machinedg@93-136-136-2.adsl.net.t-com.hr)
2023-06-06 10:49:25 +0200cheater(~Username@user/cheater) (Ping timeout: 256 seconds)
2023-06-06 10:50:24 +0200cheater(~Username@user/cheater)
2023-06-06 10:51:16 +0200shriekingnoise_(~shrieking@186.137.175.87) (Ping timeout: 268 seconds)
2023-06-06 10:51:49 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:24fa:d550:62e1:3add) (Remote host closed the connection)
2023-06-06 10:54:51 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1)
2023-06-06 11:00:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 11:02:36 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-06-06 11:02:38 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds)
2023-06-06 11:04:37 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 11:05:20 +0200Lord_of_Life_Lord_of_Life
2023-06-06 11:05:27 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2023-06-06 11:10:39 +0200chromoblob(~user@37.113.158.8)
2023-06-06 11:15:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 11:19:17 +0200mmhat(~mmh@p200300f1c7066881ee086bfffe095315.dip0.t-ipconnect.de)
2023-06-06 11:19:20 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 11:21:26 +0200random-jellyfish(~random-je@user/random-jellyfish)
2023-06-06 11:22:32 +0200dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-06-06 11:24:04 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1) (Remote host closed the connection)
2023-06-06 11:33:42 +0200MasseR46(thelounge@2001:bc8:62c:1e19::1) (Quit: The Lounge - https://thelounge.chat)
2023-06-06 11:34:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 11:36:00 +0200__monty__(~toonn@user/toonn)
2023-06-06 11:36:13 +0200MasseR46(thelounge@2001:bc8:62c:1e19::1)
2023-06-06 11:36:58 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 11:41:12 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds)
2023-06-06 11:44:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 11:45:06 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 11:45:07 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com)
2023-06-06 11:52:43 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-06 11:53:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 11:54:07 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 11:54:15 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 11:54:38 +0200thegeekinside(~thegeekin@189.217.90.138) (Remote host closed the connection)
2023-06-06 11:56:27 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de) (Quit: leaving)
2023-06-06 11:57:14 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 250 seconds)
2023-06-06 12:08:05 +0200phma_(phma@2001:5b0:2143:8e68:6bbc:8a93:7b53:3876)
2023-06-06 12:08:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 12:09:25 +0200phma(phma@2001:5b0:2144:22d8:cadc:c651:310f:c9a8) (Read error: Connection reset by peer)
2023-06-06 12:11:07 +0200xff0x_(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
2023-06-06 12:11:28 +0200 <gensyst> dminuoso, so nested forkOS solution is out of the question? :(
2023-06-06 12:11:36 +0200 <gensyst> (sorry stepped out for a while)
2023-06-06 12:12:14 +0200 <gensyst> looking at the implementation, do you think it would be a hard thing to add a "forkOS_SAME" to GHC?
2023-06-06 12:12:14 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 12:12:19 +0200 <dminuoso> gensyst: After some more careful research, yes.
2023-06-06 12:12:33 +0200 <dminuoso> gensyst: Mmm, well you would rather need a fork# primop variant
2023-06-06 12:12:44 +0200 <dminuoso> I suspect it wouldnt be hard
2023-06-06 12:12:50 +0200user____3(~user@dynamic-046-114-177-202.46.114.pool.telefonica.de)
2023-06-06 12:13:37 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-06-06 12:15:18 +0200 <dminuoso> See rts/PrimOps.cmm
2023-06-06 12:15:25 +0200zer0bitz(~zer0bitz@user/zer0bitz)
2023-06-06 12:16:08 +0200 <dminuoso> A version of createThread in rts/Threads.c
2023-06-06 12:16:12 +0200 <dminuoso> Fed all the way into a primop
2023-06-06 12:16:34 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-06-06 12:16:35 +0200 <dminuoso> Say forkBound#
2023-06-06 12:17:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 12:18:48 +0200zer0bitz_(~zer0bitz@user/zer0bitz) (Ping timeout: 265 seconds)
2023-06-06 12:20:57 +0200zer0bitz_(~zer0bitz@user/zer0bitz)
2023-06-06 12:21:03 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 12:21:37 +0200zer0bitz(~zer0bitz@user/zer0bitz) (Ping timeout: 240 seconds)
2023-06-06 12:30:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 12:34:04 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 12:38:11 +0200__monty__(~toonn@user/toonn) (Ping timeout: 246 seconds)
2023-06-06 12:39:08 +0200CiaoSen(~Jura@145.224.74.19) (Ping timeout: 265 seconds)
2023-06-06 12:45:11 +0200thegeekinside(~thegeekin@189.217.90.138)
2023-06-06 12:47:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 12:51:10 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 12:51:24 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 250 seconds)
2023-06-06 12:53:30 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1)
2023-06-06 12:53:50 +0200xff0x_(~xff0x@ai098135.d.east.v6connect.net)
2023-06-06 13:01:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 13:01:33 +0200thegeekinside(~thegeekin@189.217.90.138) (Read error: Connection reset by peer)
2023-06-06 13:03:05 +0200YoungFrog(~youngfrog@2a02:a03f:ca07:f900:3990:663b:be50:9418) (Ping timeout: 250 seconds)
2023-06-06 13:04:18 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 13:04:20 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 13:08:26 +0200CiaoSen(~Jura@145.224.74.19)
2023-06-06 13:10:01 +0200taupiqueur4(~taupiqueu@2a02-842a-8180-4601-fc1a-de08-4257-8549.rev.sfr.net)
2023-06-06 13:10:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 13:11:19 +0200taupiqueur3(~taupiqueu@2a02:842a:8180:4601:5472:ee1d:5e4f:9dc7) (Ping timeout: 250 seconds)
2023-06-06 13:13:01 +0200robosexual(~robosexua@5.167.244.138)
2023-06-06 13:17:41 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 13:21:07 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-06-06 13:21:44 +0200zxrom(~zxrom@mm-26-33-212-37.vitebsk.dynamic.pppoe.byfly.by) (Ping timeout: 268 seconds)
2023-06-06 13:22:14 +0200 <merijn> gensyst: I mean, at this point I think (assuming this is still the same issue) it's literally easier to fix the RTS to support the functionality you want, rather than this kinda hacky Haskell side implementation :p
2023-06-06 13:22:23 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-06-06 13:23:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 13:25:15 +0200extor(~extor@ns3018124.ip-149-202-82.eu) (Ping timeout: 256 seconds)
2023-06-06 13:26:57 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 13:31:28 +0200 <merijn> (assuming this is still somehow related to the finalizer problem)
2023-06-06 13:32:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 13:34:17 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 13:38:59 +0200titibandit(~titibandi@user/titibandit)
2023-06-06 13:47:02 +0200user____3gurkenglas
2023-06-06 13:48:30 +0200nate2(~nate@98.45.169.16)
2023-06-06 13:48:39 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-06-06 13:52:01 +0200gurkenglas(~user@dynamic-046-114-177-202.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-06-06 13:53:07 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-06-06 14:00:35 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 268 seconds)
2023-06-06 14:01:47 +0200freeside(~mengwong@103.252.202.189)
2023-06-06 14:01:47 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1) (Ping timeout: 265 seconds)
2023-06-06 14:04:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 14:04:55 +0200cheater(~Username@user/cheater) (Ping timeout: 256 seconds)
2023-06-06 14:06:54 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 14:07:08 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 240 seconds)
2023-06-06 14:13:11 +0200jero98772(~jero98772@2800:484:1d7f:5d36::1)
2023-06-06 14:13:16 +0200cheater(~Username@user/cheater)
2023-06-06 14:18:55 +0200cheater(~Username@user/cheater) (Ping timeout: 250 seconds)
2023-06-06 14:21:11 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-06-06 14:24:09 +0200cheater(~Username@user/cheater)
2023-06-06 14:24:44 +0200freeside(~mengwong@103.252.202.189)
2023-06-06 14:27:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 14:29:11 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 14:30:47 +0200cheater(~Username@user/cheater) (Ping timeout: 265 seconds)
2023-06-06 14:33:12 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 265 seconds)
2023-06-06 14:33:21 +0200 <maerwald[m]> merijn: you at Zurihac?
2023-06-06 14:35:16 +0200 <merijn> maerwald[m]: No, my life calendar during June/July is already more than overfull for me to fit it in this year :)
2023-06-06 14:37:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 14:38:51 +0200cheater(~Username@user/cheater)
2023-06-06 14:40:56 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 14:45:19 +0200dminuoso(~dminuoso@user/dminuoso) (Quit: ZNC 1.8.2 - https://znc.in)
2023-06-06 14:46:30 +0200Nikopol(nikopol@user/astrorigin)
2023-06-06 14:46:55 +0200dminuoso(~dminuoso@user/dminuoso)
2023-06-06 14:47:32 +0200user____3(~user@dynamic-046-114-177-202.46.114.pool.telefonica.de)
2023-06-06 14:47:35 +0200user____3gurkenglas
2023-06-06 14:48:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 14:48:12 +0200Alex_test(~al_test@178.34.162.37) (Quit: ;-)
2023-06-06 14:48:55 +0200AlexZenon(~alzenon@178.34.162.37) (Quit: ;-)
2023-06-06 14:49:17 +0200AlexNoo(~AlexNoo@178.34.162.37) (Quit: Leaving)
2023-06-06 14:49:23 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-06-06 14:50:15 +0200 <maerwald[m]> booo
2023-06-06 14:50:55 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 14:51:17 +0200zxrom(~zxrom@37.212.22.227)
2023-06-06 14:52:11 +0200 <merijn> maerwald[m]: Why? What's up?
2023-06-06 14:53:22 +0200mc47(~mc47@xmonad/TheMC47)
2023-06-06 14:53:28 +0200 <maerwald[m]> Nothing
2023-06-06 14:54:47 +0200machinedgod(~machinedg@93-136-136-2.adsl.net.t-com.hr) (Ping timeout: 256 seconds)
2023-06-06 14:58:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 15:01:13 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 15:01:31 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-06-06 15:06:07 +0200cfricke(~cfricke@user/cfricke) (Ping timeout: 256 seconds)
2023-06-06 15:06:56 +0200cheater(~Username@user/cheater)
2023-06-06 15:12:30 +0200bonz060(~quassel@2001:bc8:47a4:a23::1) (Quit: No Ping reply in 180 seconds.)
2023-06-06 15:19:21 +0200cheater_(~Username@user/cheater)
2023-06-06 15:22:28 +0200cheater(~Username@user/cheater) (Ping timeout: 265 seconds)
2023-06-06 15:23:21 +0200cheater__(~Username@user/cheater)
2023-06-06 15:23:21 +0200cheater__cheater
2023-06-06 15:24:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 15:25:07 +0200cheater_(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-06-06 15:26:24 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2023-06-06 15:26:45 +0200AlexNoo(~AlexNoo@178.34.162.37)
2023-06-06 15:26:54 +0200AlexZenon(~alzenon@178.34.162.37)
2023-06-06 15:28:17 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 15:29:54 +0200Alex_test(~al_test@178.34.162.37)
2023-06-06 15:30:42 +0200Yumemi(~Yumemi@chamoin.net) (Quit: .)
2023-06-06 15:32:32 +0200Yumemi(~Yumemi@chamoin.net)
2023-06-06 15:36:29 +0200vandita(~vandit@87-97-88-195.pool.digikabel.hu) (Ping timeout: 265 seconds)
2023-06-06 15:38:01 +0200 <gensyst> merijn, adding a new forkOSSame e.g. would require RTS changes right?
2023-06-06 15:38:09 +0200vandita(~vandit@91-83-10-39.pool.digikabel.hu)
2023-06-06 15:38:10 +0200 <gensyst> or mkWeakRefSame
2023-06-06 15:38:16 +0200freeside(~mengwong@103.252.202.189)
2023-06-06 15:38:18 +0200 <gensyst> (same as in, same as original bound thread)
2023-06-06 15:38:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 15:38:44 +0200 <gensyst> (i.e. i'm wondering, the ideas we were floating earlier, weren't they already RTS changes?)
2023-06-06 15:38:56 +0200 <merijn> gensyst: Probably? Is this still related to your finalizer changes
2023-06-06 15:39:22 +0200 <merijn> gensyst: yes, but changing the RTS to have better functionality wrt finalizers is probably more generally useful :)
2023-06-06 15:39:25 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-06-06 15:39:38 +0200 <gensyst> yeah it is
2023-06-06 15:40:25 +0200dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds)
2023-06-06 15:42:40 +0200 <merijn> And I don't think 1 is much easier than the other, so you'd be better off doing the more useful thing
2023-06-06 15:43:17 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 265 seconds)
2023-06-06 15:45:13 +0200cheater(~Username@user/cheater) (Ping timeout: 256 seconds)
2023-06-06 15:46:55 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-06-06 15:56:20 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-06 15:58:09 +0200mei(~mei@user/mei) (Ping timeout: 250 seconds)
2023-06-06 16:00:27 +0200random-jellyfish(~random-je@user/random-jellyfish) (Quit: Client closed)
2023-06-06 16:00:45 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 250 seconds)
2023-06-06 16:01:53 +0200thegeekinside(~thegeekin@189.217.90.138)
2023-06-06 16:02:33 +0200mei(~mei@user/mei)
2023-06-06 16:03:30 +0200thegeekinside(~thegeekin@189.217.90.138) (Read error: Connection reset by peer)
2023-06-06 16:15:49 +0200CiaoSen(~Jura@145.224.74.19) (Ping timeout: 256 seconds)
2023-06-06 16:17:31 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 16:17:52 +0200shriekingnoise(~shrieking@186.137.175.87)
2023-06-06 16:20:42 +0200cheater(~Username@user/cheater)
2023-06-06 16:22:03 +0200end\(~end@2001:470:69fc:105::3:673f)
2023-06-06 16:22:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 16:23:52 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 16:23:57 +0200thegeekinside(~thegeekin@189.217.90.138)
2023-06-06 16:29:51 +0200captnemo(~captnemo@193.32.127.239)
2023-06-06 16:34:47 +0200cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-06-06 16:35:38 +0200Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat)
2023-06-06 16:35:44 +0200end\end`
2023-06-06 16:35:56 +0200Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net)
2023-06-06 16:36:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 16:37:14 +0200cheater(~Username@user/cheater)
2023-06-06 16:38:38 +0200end`end|
2023-06-06 16:39:15 +0200end|end_
2023-06-06 16:39:36 +0200end_end-
2023-06-06 16:39:49 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 16:40:35 +0200end-(~end@2001:470:69fc:105::3:673f) (Changing host)
2023-06-06 16:40:35 +0200end-(~end@user/end/x-0094621)
2023-06-06 16:40:41 +0200captnemo(~captnemo@193.32.127.239) (Quit: WeeChat 3.8)
2023-06-06 16:46:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 16:47:05 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 240 seconds)
2023-06-06 16:49:07 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 16:52:23 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-06-06 16:56:29 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds)
2023-06-06 16:58:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 16:59:42 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-06-06 17:00:48 +0200bontaq(~user@ool-45779b84.dyn.optonline.net)
2023-06-06 17:02:09 +0200gensyst(~gensyst@user/gensyst) (Quit: Leaving)
2023-06-06 17:06:26 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2023-06-06 17:08:56 +0200random-jellyfish(~random-je@user/random-jellyfish)
2023-06-06 17:09:07 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 17:11:59 +0200simendsjo(~user@84.211.91.241)
2023-06-06 17:14:37 +0200random-jellyfish(~random-je@user/random-jellyfish) (Quit: Client closed)
2023-06-06 17:17:58 +0200kmein(~weechat@user/kmein) (Quit: ciao kakao)
2023-06-06 17:18:10 +0200motherfs1motherfsck
2023-06-06 17:20:29 +0200kmein(~weechat@user/kmein)
2023-06-06 17:21:51 +0200simendsjo(~user@84.211.91.241) (Ping timeout: 265 seconds)
2023-06-06 17:23:49 +0200Sauvin(~sauvin@user/Sauvin) (Ping timeout: 265 seconds)
2023-06-06 17:24:29 +0200mauke(~mauke@user/mauke)
2023-06-06 17:28:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 17:30:19 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-06-06 17:31:03 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 17:36:35 +0200le_ka(~l_k@213.24.134.106)
2023-06-06 17:38:56 +0200AlexNoo_(~AlexNoo@178.34.160.87)
2023-06-06 17:39:00 +0200vglfr(~vglfr@cli-188-239-201-89.bbn.slav.dn.ua)
2023-06-06 17:41:06 +0200syminical(~quassel@2601:406:8481:950:2083:c0dd:fbbb:ef04)
2023-06-06 17:41:37 +0200Alex_test(~al_test@178.34.162.37) (Ping timeout: 240 seconds)
2023-06-06 17:41:48 +0200AlexZenon(~alzenon@178.34.162.37) (Ping timeout: 240 seconds)
2023-06-06 17:42:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 17:42:31 +0200AlexNoo(~AlexNoo@178.34.162.37) (Ping timeout: 256 seconds)
2023-06-06 17:43:56 +0200ripspin(~chatzilla@1.145.216.252)
2023-06-06 17:44:12 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 17:44:49 +0200dcoutts(~duncan@ip-185-104-136-57.ptr.icomera.net)
2023-06-06 17:46:21 +0200Alex_test(~al_test@178.34.160.87)
2023-06-06 17:47:03 +0200AlexZenon(~alzenon@178.34.160.87)
2023-06-06 17:48:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 17:49:29 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 17:50:01 +0200nate2(~nate@98.45.169.16)
2023-06-06 17:50:43 +0200le__ka(~l_k@213.24.134.106)
2023-06-06 17:52:29 +0200le_ka(~l_k@213.24.134.106) (Ping timeout: 246 seconds)
2023-06-06 17:53:04 +0200vandita(~vandit@91-83-10-39.pool.digikabel.hu) (Ping timeout: 248 seconds)
2023-06-06 17:53:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 17:54:37 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-06-06 17:55:17 +0200vandita(~vandit@79.120.162.139)
2023-06-06 18:00:14 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection)
2023-06-06 18:00:17 +0200 <jade[m]> hm, I seem to be getting an unused-imports warning even though I do use the imports and removing them breaks my program?
2023-06-06 18:00:34 +0200YoungFrog(~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be)
2023-06-06 18:01:10 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 18:01:15 +0200 <jade[m]> app/Style.hs:8:1: warning: [-Wunused-imports]... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/97b04b63b05acfd0ab00c8f7bd9a67af5527…>)
2023-06-06 18:01:36 +0200 <jade[m]> removing the line in question I get a big error with all of them missing
2023-06-06 18:01:54 +0200 <jade[m]> oh fuck im so stupid
2023-06-06 18:03:00 +0200 <jade[m]> for some reason it marked the whole line both with hlint and ghc, but it only referred to some of them
2023-06-06 18:03:22 +0200 <[exa]> another problem successfully rubberducked. next!
2023-06-06 18:03:45 +0200 <jade[m]> oddly enough it does mark only the one in question if it's just one
2023-06-06 18:03:55 +0200 <jade[m]> but with more it shows the entire line as redundant
2023-06-06 18:03:55 +0200neohtetxyz[m](~neohtetxy@2001:470:69fc:105::3:314c) (Remote host closed the connection)
2023-06-06 18:03:56 +0200 <[exa]> jade[m]: yeah combining error locations sensibly is kinda hard
2023-06-06 18:04:39 +0200 <[exa]> you'd say that just highlighting the "shortest span" would be helpful, but that confuses people for being a little misleadingly specific to the whole given span
2023-06-06 18:05:25 +0200 <jade[m]> makes sense
2023-06-06 18:05:47 +0200notzmv(~zmv@user/notzmv)
2023-06-06 18:06:14 +0200 <[exa]> others may freak out if they get a separate message for each extra identifier
2023-06-06 18:06:29 +0200 <[exa]> kinda guess this was the easiest minimal-questionable-effort soluton
2023-06-06 18:07:57 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1) (Remote host closed the connection)
2023-06-06 18:08:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 18:09:28 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-06-06 18:11:28 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-06-06 18:11:51 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 18:18:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 18:18:40 +0200kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2023-06-06 18:20:15 +0200__monty__(~toonn@user/toonn)
2023-06-06 18:21:34 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 18:22:46 +0200dsrt^(~dsrt@c-71-204-38-59.hsd1.ga.comcast.net) (Remote host closed the connection)
2023-06-06 18:23:05 +0200dcoutts(~duncan@ip-185-104-136-57.ptr.icomera.net) (Ping timeout: 240 seconds)
2023-06-06 18:25:33 +0200econo(uid147250@user/econo)
2023-06-06 18:26:12 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-06 18:26:37 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2023-06-06 18:26:54 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-06-06 18:27:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 18:28:07 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-06-06 18:32:08 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 18:32:42 +0200coot(~coot@89.69.206.216) (Quit: coot)
2023-06-06 18:35:15 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-06-06 18:41:37 +0200__monty__(~toonn@user/toonn) (Ping timeout: 240 seconds)
2023-06-06 18:43:34 +0200 <probie> Can I get GHC to call foreign code with GHC's own calling convention?
2023-06-06 18:45:51 +0200vandita(~vandit@79.120.162.139) (Ping timeout: 250 seconds)
2023-06-06 18:48:30 +0200oac(~oac@72-50-214-210.fttp.usinternet.com)
2023-06-06 18:48:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 18:48:44 +0200cheater(~Username@user/cheater)
2023-06-06 18:48:59 +0200_koolazer(~koo@user/koolazer) (Remote host closed the connection)
2023-06-06 18:49:16 +0200koolazer(~koo@user/koolazer)
2023-06-06 18:51:36 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 18:52:21 +0200 <carbolymer> is `cabal get` able to reach to custom repository, besides hackage? it returns `There is no package` when I try to do that
2023-06-06 18:52:54 +0200vandita(~vandit@193-110-63-33.cable-modem.hdsnet.hu)
2023-06-06 18:52:55 +0200 <[exa]> hm, any ideas on terse way sto write a condition that "the list is exactly someGivenList++aSingleExtraElement"?
2023-06-06 18:53:55 +0200 <carbolymer> [exa]: (`==` aSingleExtraElement) . head . reverse
2023-06-06 18:53:55 +0200 <carbolymer> ?
2023-06-06 18:54:01 +0200 <probie> and that single extra element is always at the end?
2023-06-06 18:54:11 +0200 <carbolymer> [exa]: plus account for empty lists etc
2023-06-06 18:54:14 +0200 <[exa]> ohhhh reverse
2023-06-06 18:54:57 +0200 <[exa]> anyway yeah the extra element is exactly at the end
2023-06-06 18:55:10 +0200 <[exa]> thx carbolymer that was the hint I needed :D
2023-06-06 18:55:25 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e) (Remote host closed the connection)
2023-06-06 18:55:30 +0200 <carbolymer> [exa]: yw
2023-06-06 18:55:42 +0200 <mauke> list == someGivenList ++ [aSingleExtraElement]
2023-06-06 18:57:43 +0200 <[exa]> mauke: yeah that would be the other way, list == someGiveList ++ [last list]
2023-06-06 18:58:35 +0200captnemo(~captnemo@193.32.127.239)
2023-06-06 18:58:59 +0200ripspin(~chatzilla@1.145.216.252) (Remote host closed the connection)
2023-06-06 18:59:11 +0200 <mauke> take (length list - 1) list, but that doesn't stream well
2023-06-06 18:59:29 +0200 <[Leary]> Use `init`?
2023-06-06 18:59:44 +0200 <mauke> ah, right
2023-06-06 19:00:01 +0200AlexNoo_AlexNoo
2023-06-06 19:00:04 +0200 <mauke> init list == someGivenList
2023-06-06 19:00:59 +0200 <[exa]> oh yeah, true
2023-06-06 19:01:15 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-06-06 19:02:50 +0200mokee(~mokee@37.228.215.134)
2023-06-06 19:02:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 19:04:35 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 19:06:24 +0200freeside(~mengwong@103.252.202.189)
2023-06-06 19:06:50 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1)
2023-06-06 19:07:13 +0200simendsjo(~user@84.211.91.241)
2023-06-06 19:10:59 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 250 seconds)
2023-06-06 19:12:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 19:13:17 +0200Vajb(~Vajb@2001:999:584:b338:66d5:8cec:693:8212)
2023-06-06 19:16:05 +0200dcoutts(~duncan@212.221.20.36)
2023-06-06 19:16:19 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 19:17:34 +0200mi7(~mi7@76.132.133.207)
2023-06-06 19:21:23 +0200zer0bitz_(~zer0bitz@user/zer0bitz) (Read error: Connection reset by peer)
2023-06-06 19:22:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 19:24:28 +0200zer0bitz(~zer0bitz@user/zer0bitz)
2023-06-06 19:25:20 +0200syminical_(~quassel@2601:406:8481:950:2083:c0dd:fbbb:ef04)
2023-06-06 19:25:51 +0200tcard_(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
2023-06-06 19:25:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 19:26:11 +0200emergence(thelounge@2607:5300:60:5910:dcad:beff:feef:5bc) (Remote host closed the connection)
2023-06-06 19:26:12 +0200eggplant_(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-06 19:27:55 +0200rubin55(sid175221@id-175221.hampstead.irccloud.com) (Ping timeout: 256 seconds)
2023-06-06 19:28:20 +0200tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Ping timeout: 250 seconds)
2023-06-06 19:28:20 +0200robobub(uid248673@id-248673.uxbridge.irccloud.com) (Ping timeout: 250 seconds)
2023-06-06 19:28:29 +0200econo(uid147250@user/econo) (Ping timeout: 256 seconds)
2023-06-06 19:28:29 +0200NemesisD(sid24071@id-24071.lymington.irccloud.com) (Ping timeout: 256 seconds)
2023-06-06 19:28:29 +0200edmundnoble(sid229620@id-229620.helmsley.irccloud.com) (Ping timeout: 256 seconds)
2023-06-06 19:28:46 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 250 seconds)
2023-06-06 19:28:46 +0200syminical(~quassel@2601:406:8481:950:2083:c0dd:fbbb:ef04) (Ping timeout: 250 seconds)
2023-06-06 19:29:12 +0200elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru) (Ping timeout: 250 seconds)
2023-06-06 19:29:50 +0200econo(uid147250@user/econo)
2023-06-06 19:30:31 +0200emergence(thelounge@2607:5300:60:5910:dcad:beff:feef:5bc)
2023-06-06 19:31:44 +0200edmundnoble(sid229620@id-229620.helmsley.irccloud.com)
2023-06-06 19:31:44 +0200rubin55(sid175221@id-175221.hampstead.irccloud.com)
2023-06-06 19:31:44 +0200simendsjo(~user@84.211.91.241) (Read error: Connection reset by peer)
2023-06-06 19:31:50 +0200NemesisD(sid24071@id-24071.lymington.irccloud.com)
2023-06-06 19:32:04 +0200shapr(~user@2600:1700:c640:3100:a42a:82d6:7ced:1441)
2023-06-06 19:32:52 +0200__monty__(~toonn@user/toonn)
2023-06-06 19:32:59 +0200robobub(uid248673@id-248673.uxbridge.irccloud.com)
2023-06-06 19:36:18 +0200zxrom(~zxrom@37.212.22.227) (Quit: Leaving)
2023-06-06 19:38:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 19:38:15 +0200eggplant_(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Remote host closed the connection)
2023-06-06 19:38:47 +0200 <shapr> Has anyone hit the problem with connection and the fork from cryptonite to crypton?
2023-06-06 19:38:56 +0200 <shapr> Is there a known fix for the connection library?
2023-06-06 19:39:08 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 19:40:54 +0200elkcl(~elkcl@broadband-37-110-27-252.ip.moscow.rt.ru)
2023-06-06 19:43:28 +0200syminical_(~quassel@2601:406:8481:950:2083:c0dd:fbbb:ef04) (Ping timeout: 248 seconds)
2023-06-06 19:44:31 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-06-06 19:45:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 19:47:17 +0200Me-me(~me-me@user/me-me) (Quit: Disconnecting on purpose.)
2023-06-06 19:47:24 +0200acidjnk(~acidjnk@p200300d6e7072f266d84e9375f346e43.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-06-06 19:47:43 +0200Guest36(~Guest26@2401:4900:60f3:fecd:d446:76fc:8aa7:e5e)
2023-06-06 19:47:47 +0200acidjnk(~acidjnk@p200300d6e7072f266d84e9375f346e43.dip0.t-ipconnect.de)
2023-06-06 19:48:01 +0200Me-me(~me-me@2602:ff16:3:0:1:dc:beef:d00d)
2023-06-06 19:48:18 +0200EvanR(~EvanR@user/evanr) (Remote host closed the connection)
2023-06-06 19:48:38 +0200EvanR(~EvanR@user/evanr)
2023-06-06 19:48:46 +0200fr33domlover(~fr33domlo@towards.vision) (Quit: Ping timeout (120 seconds))
2023-06-06 19:48:49 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 19:48:50 +0200beaky(~beaky@2a03:b0c0:0:1010::1e:a001) (Read error: Connection reset by peer)
2023-06-06 19:48:59 +0200amir(sid22336@user/amir) (Read error: Connection reset by peer)
2023-06-06 19:49:06 +0200Franciman(~Franciman@mx1.fracta.dev) (Read error: Connection reset by peer)
2023-06-06 19:49:08 +0200amir(sid22336@user/amir)
2023-06-06 19:49:08 +0200beaky(~beaky@2a03:b0c0:0:1010::1e:a001)
2023-06-06 19:49:09 +0200fr33domlover(~fr33domlo@towards.vision)
2023-06-06 19:49:14 +0200siers(~ij@user/ij) (Quit: ZNC 1.8.2 - https://znc.in)
2023-06-06 19:49:27 +0200delyan(sid523379@id-523379.hampstead.irccloud.com) (Ping timeout: 256 seconds)
2023-06-06 19:49:27 +0200JSharp(sid4580@id-4580.lymington.irccloud.com) (Ping timeout: 256 seconds)
2023-06-06 19:49:32 +0200darkling(~darkling@2001-ba8-1f1-f0e6-0-0-0-2.autov6rev.bitfolk.space) (Remote host closed the connection)
2023-06-06 19:49:35 +0200siers(~ij@user/ij)
2023-06-06 19:49:41 +0200Franciman(~Franciman@2a02:c207:2044:6185::1)
2023-06-06 19:49:42 +0200darkling(~darkling@2001-ba8-1f1-f0e6-0-0-0-2.autov6rev.bitfolk.space)
2023-06-06 19:49:46 +0200h2t(~h2t@user/h2t) (Quit: ZNC - https://znc.in)
2023-06-06 19:49:46 +0200srk(~sorki@user/srk) (Quit: ZNC 1.8.1 - https://znc.in)
2023-06-06 19:49:46 +0200pierrot(~pi@user/pierrot) (Quit: ZNC 1.8.2 - http://znc.in)
2023-06-06 19:49:48 +0200nurupo(~nurupo.ga@user/nurupo) (Quit: nurupo.ga)
2023-06-06 19:50:00 +0200h2t(~h2t@user/h2t)
2023-06-06 19:50:03 +0200nurupo(~nurupo.ga@user/nurupo)
2023-06-06 19:50:05 +0200srk(~sorki@user/srk)
2023-06-06 19:50:39 +0200delyan(sid523379@id-523379.hampstead.irccloud.com)
2023-06-06 19:50:46 +0200JSharp(sid4580@id-4580.lymington.irccloud.com)
2023-06-06 19:51:08 +0200pierrot(~pi@user/pierrot)
2023-06-06 19:54:36 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-06-06 19:59:56 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-06-06 20:01:09 +0200Guest36(~Guest26@2401:4900:60f3:fecd:d446:76fc:8aa7:e5e) (Quit: Client closed)
2023-06-06 20:02:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:03:10 +0200 <shapr> Perhaps I should be consistently using cabal.freeze files?
2023-06-06 20:03:13 +0200shaprgrumbles
2023-06-06 20:06:09 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:09:38 +0200vglfr(~vglfr@cli-188-239-201-89.bbn.slav.dn.ua) (Remote host closed the connection)
2023-06-06 20:09:52 +0200 <Vq> shapr: Is that like a flake.lock?
2023-06-06 20:10:34 +0200vglfr(~vglfr@188.239.201.89)
2023-06-06 20:10:51 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-06-06 20:11:03 +0200 <sm> or something like a stackage snapshot ?
2023-06-06 20:11:18 +0200 <sm> anyway yes, it sounds like you should be doing something like that in the face of crypton* chaos
2023-06-06 20:11:43 +0200 <sm> life is too short for non-reproducible build plans
2023-06-06 20:11:49 +0200 <jean-paul[m]> cabal freeze dumps the versions it has right now, so you're isolated from future cabal updates
2023-06-06 20:12:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:12:31 +0200 <jean-paul[m]> it's been unclear to me whether it's a good idea to have these in version control or not, but now it is clear that not having them is definitely worse
2023-06-06 20:13:08 +0200 <sclv> i think you need to constrain the version for tls: https://github.com/haskell-tls/hs-tls/issues/455
2023-06-06 20:14:02 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:14:20 +0200 <jean-paul[m]> and warp-tls and http-client-tls and maybe some other stuff
2023-06-06 20:14:48 +0200 <shapr> Vq: haha, it's kinda like that, yeah. But only if I were using haskell.nix which I'm not
2023-06-06 20:15:07 +0200 <shapr> sclv: Tried that, it's not enough
2023-06-06 20:16:21 +0200 <shapr> I hit a problem with WarpTLS picking up crypton-x509 when I was depending on x509 in the rest of the package
2023-06-06 20:17:13 +0200Vqhasn't looked into haskell.nix yet
2023-06-06 20:18:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:19:15 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:24:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:24:55 +0200captnemo(~captnemo@193.32.127.239) (Quit: WeeChat 3.8)
2023-06-06 20:25:08 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:29:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:30:40 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-06-06 20:32:49 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:38:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:39:32 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-06-06 20:40:04 +0200chele(~chele@user/chele) (Remote host closed the connection)
2023-06-06 20:43:34 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-06-06 20:43:55 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 265 seconds)
2023-06-06 20:47:40 +0200Sgeo(~Sgeo@user/sgeo)
2023-06-06 20:48:21 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:51:30 +0200shapr(~user@2600:1700:c640:3100:a42a:82d6:7ced:1441) (Remote host closed the connection)
2023-06-06 20:52:16 +0200shapr(~user@2600:1700:c640:3100:a42a:82d6:7ced:1441)
2023-06-06 20:53:05 +0200gmg(~user@user/gehmehgeh)
2023-06-06 20:53:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 20:57:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 20:57:48 +0200Vajb(~Vajb@2001:999:584:b338:66d5:8cec:693:8212) (Ping timeout: 240 seconds)
2023-06-06 20:59:02 +0200ddellacosta(~ddellacos@143.244.47.72) (Quit: WeeChat 3.8)
2023-06-06 20:59:17 +0200ft(~ft@p4fc2a88b.dip0.t-ipconnect.de)
2023-06-06 21:00:16 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-06-06 21:04:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 21:05:19 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 21:06:55 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Remote host closed the connection)
2023-06-06 21:07:34 +0200Vajb(~Vajb@2001:999:250:2079:66be:70d5:dda1:734b)
2023-06-06 21:07:46 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-06-06 21:14:28 +0200eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-06-06 21:16:43 +0200Vajb(~Vajb@2001:999:250:2079:66be:70d5:dda1:734b) (Ping timeout: 256 seconds)
2023-06-06 21:17:10 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net)
2023-06-06 21:17:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 21:21:04 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 21:22:01 +0200tzh_(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-06-06 21:22:07 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Ping timeout: 268 seconds)
2023-06-06 21:22:29 +0200Vajb(~Vajb@2001:999:484:a37d:e618:9886:4843:f5d8)
2023-06-06 21:24:25 +0200gurkenglas(~user@dynamic-046-114-177-202.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-06-06 21:32:53 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-06-06 21:33:14 +0200mi7(~mi7@76.132.133.207) (Read error: Connection reset by peer)
2023-06-06 21:35:32 +0200 <eugenrh> Hello! I keep reading that foldr works on infinite lists.. and I'm frustrated because I fail to understand how that's possible..
2023-06-06 21:36:10 +0200 <geekosaur> because it can produce results before reaching the end of the list, as it works lazily
2023-06-06 21:36:23 +0200 <geekosaur> so it's only as infinite as what is demanded of it
2023-06-06 21:36:36 +0200 <eugenrh> an example, please?
2023-06-06 21:36:48 +0200 <dolio> > foldr (:) [] [1..]
2023-06-06 21:36:49 +0200 <lambdabot> [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,...
2023-06-06 21:37:25 +0200 <mauke> > foldr (\x z -> x) 42 [0..]
2023-06-06 21:37:27 +0200 <lambdabot> 0
2023-06-06 21:38:07 +0200 <mauke> z is the result of folding the rest of the infinite list. we don't use it, so nothing happens
2023-06-06 21:38:14 +0200 <geekosaur> note that this requires a lazy operation as well; if it is strict then it will demand the whole list, which obviously doesn't work for infinite lists
2023-06-06 21:38:32 +0200 <geekosaur> as mauke just showed
2023-06-06 21:38:44 +0200zxrom(~zxrom@mm-163-23-212-37.vitebsk.dynamic.pppoe.byfly.by)
2023-06-06 21:38:52 +0200 <geekosaur> (more specifically strict in its second parameter)
2023-06-06 21:38:59 +0200 <eugenrh> ok, I read about that short-circuiting..
2023-06-06 21:39:29 +0200czy(~user@host-140-24.ilcub310.champaign.il.us.clients.pavlovmedia.net)
2023-06-06 21:39:31 +0200 <dolio> Oh yeah.
2023-06-06 21:39:53 +0200 <dolio> > foldr (\n b -> n > 10 || b) False [0..]
2023-06-06 21:39:55 +0200 <lambdabot> True
2023-06-06 21:40:53 +0200moet(~moet@mobile-166-171-249-181.mycingular.net)
2023-06-06 21:41:22 +0200 <mauke> > foldr f z [0 ..]
2023-06-06 21:41:23 +0200 <lambdabot> f 0 (f 1 (f 2 (f 3 (f 4 (f 5 (f 6 (f 7 (f 8 (f 9 (f 10 (f 11 (f 12 (f 13 (f ...
2023-06-06 21:41:47 +0200 <mauke> as long as f doesn't use its second argument too much, we'll terminate :-)
2023-06-06 21:41:52 +0200 <jade[m]> lambdabot foes that?
2023-06-06 21:41:55 +0200 <jade[m]> that's cool
2023-06-06 21:42:07 +0200 <jade[m]> s/foes/does
2023-06-06 21:42:12 +0200 <moet> hi, what is a good way to monitor/poll sysfs nodes for changes in haskell? the documentation i've found says that sysfs can be monitored with poll/select (not with inotify), so I'm trying to use GHC's Control.Concurrent.threadWaitRead or GHC.Event.registerFd, but both seem to continuiously signal "ready to read"
2023-06-06 21:42:13 +0200 <geekosaur> you can, too; look at the `simple-reflect` package
2023-06-06 21:42:13 +0200 <mauke> we're cheating, of course
2023-06-06 21:43:17 +0200user____3(~user@dynamic-046-114-177-202.46.114.pool.telefonica.de)
2023-06-06 21:43:26 +0200 <eugenrh> it seems like all those examples don't have too much practicality...
2023-06-06 21:43:34 +0200 <moet> i wonder if maybe these facilities (threadWaitRead and registerFd) are only good when it's a file stream which is continually appended (ie. not a node for which you seek 0 before reads)
2023-06-06 21:44:17 +0200 <jade[m]> eugenrh: the one dealing with booleans is actually really interesting
2023-06-06 21:45:10 +0200 <dolio> > any (> 10) [0..]
2023-06-06 21:45:11 +0200 <lambdabot> True
2023-06-06 21:45:14 +0200 <geekosaur> simple examples do tend to be too simple to be practical, though. the interesting ones tend to be harder to tease apart / have too many moving parts
2023-06-06 21:45:37 +0200 <mauke> you asked how it's possible. these are just proofs of concept
2023-06-06 21:45:51 +0200 <mauke> we can do a lazy map in terms of foldr
2023-06-06 21:45:54 +0200 <jean-paul[m]> zip [0..] something is simple but also plenty practical and useful
2023-06-06 21:46:13 +0200 <mauke> zip in terms of foldr? that sounds non-trivial
2023-06-06 21:46:24 +0200 <dolio> Yeah, zip is tricky.
2023-06-06 21:46:55 +0200 <jean-paul[m]> oh, I missed the foldr context.
2023-06-06 21:47:14 +0200 <mauke> :t let xmap f xs = foldr (\x z -> f x : z) [] xs in xmap
2023-06-06 21:47:15 +0200 <lambdabot> Foldable t1 => (t2 -> a) -> t1 t2 -> [a]
2023-06-06 21:47:58 +0200 <mauke> > let xmap f xs = foldr (\x z -> f x : z) [] xs in take 5 (xmap show [0 ..])
2023-06-06 21:48:00 +0200 <lambdabot> ["0","1","2","3","4"]
2023-06-06 21:48:11 +0200 <mauke> > let xmap f xs = foldr (\x z -> f x : z) [] xs in xmap show [0 ..]
2023-06-06 21:48:12 +0200 <lambdabot> ["0","1","2","3","4","5","6","7","8","9","10","11","12","13","14","15","16",...
2023-06-06 21:48:37 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-06 21:48:50 +0200 <merijn> moet: pretty sure sysfs *is* always read to read, that's why polling is suggested
2023-06-06 21:49:13 +0200 <eugenrh> thanks, lot's of answers.. I'll check them carefully.
2023-06-06 21:50:49 +0200 <merijn> eugenrh: A tried and tested method is: grab a pen and paper and do step by step substitution of function definitions into expressions (which is basically what people were showing with lambdabot)
2023-06-06 21:51:30 +0200nate2(~nate@98.45.169.16)
2023-06-06 21:51:54 +0200 <moet> merijn: polling as in poll() or polling as in just read it over and over
2023-06-06 21:52:43 +0200 <merijn> moet: Depends on where you read that :p
2023-06-06 21:52:54 +0200 <merijn> moet: I would interpret it as "reading over and over"
2023-06-06 21:53:22 +0200 <merijn> moet: the RTS uses epoll/kqueue internally, so it's notion of "readable" is "whenever epoll/kqueue signal it's readable"
2023-06-06 21:54:07 +0200 <ncf> > let zip = foldr (\x f ys -> foldr (\y z -> (x,y) : f (tail ys)) [] ys) (const []) in zip [0..5] [6..15]
2023-06-06 21:54:08 +0200 <lambdabot> [(0,6),(1,7),(2,8),(3,9),(4,10),(5,11)]
2023-06-06 21:54:19 +0200 <ncf> ugly
2023-06-06 21:54:28 +0200 <merijn> I still find simple-reflect the simplest example to ponder :p
2023-06-06 21:54:33 +0200 <merijn> > foldr f z [a,b,c]
2023-06-06 21:54:35 +0200 <lambdabot> f a (f b (f c z))
2023-06-06 21:56:23 +0200nate2(~nate@98.45.169.16) (Ping timeout: 256 seconds)
2023-06-06 21:57:13 +0200 <moet> merijn: ok, thanks.. i was searching hard for a wrong answer I guess :)
2023-06-06 21:58:04 +0200 <merijn> moet: I mean, it's possible the RTS happens to be wrong in this specific case, but seems unlikely compared to "sysfs is always readable and therefore threadWaitRead always immediately returns ready"
2023-06-06 22:02:19 +0200 <jade[m]> <lambdabot> " [(0,6),(1,7),(2,8),(3,9),(4,10)..." <- where's the code for this? the bridge might have dropped it
2023-06-06 22:02:34 +0200 <moet> yes, merijn, i think you are right; i was expecting sysfs nodes to behave like sockets, but it seems they are just always ready
2023-06-06 22:03:59 +0200 <ncf> jade[m]: <ncf> > let zip = foldr (\x f ys -> foldr (\y z -> (x,y) : f (tail ys)) [] ys) (const []) in zip [0..5] [6..15]
2023-06-06 22:04:15 +0200 <ncf> (use an irc client i'm BEGGING you)
2023-06-06 22:04:35 +0200 <jade[m]> thanks, I probably should
2023-06-06 22:06:38 +0200 <ncf> i can recommend thelounge if you don't like terminals
2023-06-06 22:08:32 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 22:08:33 +0200 <jade[m]> I do like terminals very much actually haha
2023-06-06 22:08:46 +0200 <jade[m]> thanks flr the suggestion, I'm currently on mobile (android)
2023-06-06 22:08:53 +0200 <jade[m]> s/flr/for
2023-06-06 22:09:25 +0200 <ncf> then the reference is weechat (there's an android relay client thing)
2023-06-06 22:09:54 +0200 <ncf> alternatively glguy has an irc client written in haskell
2023-06-06 22:10:05 +0200 <jade[m]> thanks! what about RevolutionIRC? That one is mentioned on the libera chat website
2023-06-06 22:10:11 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 22:11:52 +0200thegeekinside(~thegeekin@189.217.90.138) (Remote host closed the connection)
2023-06-06 22:12:15 +0200 <ncf> if you only need a client for android, sure. note however that you will have to set up some kind of bouncer if you want to have persistent sessions
2023-06-06 22:12:32 +0200 <ncf> (similarly to how you'd set up a matrix instance, or use someone else's)
2023-06-06 22:13:03 +0200 <jade[m]> ah, yeah my main use case is desktop, so I might just keep being on the bridge here and get a proper irc client for desktop
2023-06-06 22:13:22 +0200robosexual(~robosexua@5.167.244.138) (Quit: WeeChat 3.8)
2023-06-06 22:13:46 +0200 <probie> As far as an android client goes, I've had a good experience with Goguma. It probably doesn't hurt that the bouncer I'm using is Soju, which is written by the same author
2023-06-06 22:14:57 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455)
2023-06-06 22:15:07 +0200merijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds)
2023-06-06 22:15:29 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
2023-06-06 22:18:58 +0200Jade128(~Jade128@ip-178-200-061-149.um45.pools.vodafone-ip.de)
2023-06-06 22:19:10 +0200 <Jade128> I think I made it?
2023-06-06 22:19:30 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:2881:d3bd:5594:8455) (Ping timeout: 250 seconds)
2023-06-06 22:19:32 +0200 <ncf> yes
2023-06-06 22:19:44 +0200 <Jade128> very cool, thank you
2023-06-06 22:20:56 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 22:22:43 +0200Jade128(~Jade128@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Remote host closed the connection)
2023-06-06 22:24:08 +0200Jade128(~Jade128@ip-178-200-061-149.um45.pools.vodafone-ip.de)
2023-06-06 22:24:28 +0200trev(~trev@user/trev) (Quit: trev)
2023-06-06 22:24:43 +0200Jade128(~Jade128@ip-178-200-061-149.um45.pools.vodafone-ip.de) (Remote host closed the connection)
2023-06-06 22:24:51 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 22:25:05 +0200chromoblob(~user@37.113.158.8)
2023-06-06 22:28:40 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-06-06 22:28:58 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-06-06 22:30:25 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-06 22:31:38 +0200chromoblob(~user@37.113.158.8)
2023-06-06 22:32:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 22:34:38 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 22:42:14 +0200comerijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-06-06 22:42:31 +0200powenz9dn2d(~tux@77.234.193.84)
2023-06-06 22:45:24 +0200Pickchea(~private@user/pickchea)
2023-06-06 22:45:44 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 22:46:36 +0200jinsun(~jinsun@user/jinsun)
2023-06-06 22:46:38 +0200jinsun_(~jinsun@user/jinsun)
2023-06-06 22:46:38 +0200jinsunGuest5469
2023-06-06 22:46:38 +0200jinsun_jinsun
2023-06-06 22:46:56 +0200Guest5469(~jinsun@user/jinsun) (Client Quit)
2023-06-06 22:48:58 +0200zeenk(~zeenk@2a02:2f04:a106:3c00::7fe)
2023-06-06 22:49:11 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 22:50:22 +0200pavonia(~user@user/siracusa)
2023-06-06 22:53:15 +0200le__ka(~l_k@213.24.134.106) (Quit: Leaving)
2023-06-06 22:53:49 +0200chomwitt(~chomwitt@2a02:587:7a17:7500:1ac0:4dff:fedb:a3f1) (Remote host closed the connection)
2023-06-06 22:55:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 22:59:27 +0200moet(~moet@mobile-166-171-249-181.mycingular.net) (Quit: thanks)
2023-06-06 22:59:44 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 265 seconds)
2023-06-06 23:05:47 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 23:07:35 +0200freeside(~mengwong@103.252.202.189)
2023-06-06 23:11:08 +0200mechap(~mechap@user/mechap) (Ping timeout: 240 seconds)
2023-06-06 23:12:18 +0200freeside(~mengwong@103.252.202.189) (Ping timeout: 265 seconds)
2023-06-06 23:12:29 +0200mechap(~mechap@user/mechap)
2023-06-06 23:12:31 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-06-06 23:13:04 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2023-06-06 23:15:14 +0200powenz9dn2d(~tux@77.234.193.84) (Konversation terminated!)
2023-06-06 23:16:45 +0200comerijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds)
2023-06-06 23:22:20 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:9507:927b:4547:5b8e)
2023-06-06 23:29:05 +0200chromoblob(~user@37.113.158.8) (Ping timeout: 240 seconds)
2023-06-06 23:30:06 +0200comerijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl)
2023-06-06 23:34:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 23:34:59 +0200comerijn(~merijn@c-001-001-004.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds)
2023-06-06 23:36:00 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 23:36:53 +0200vandita(~vandit@193-110-63-33.cable-modem.hdsnet.hu) (Ping timeout: 246 seconds)
2023-06-06 23:39:13 +0200vandita(~vandit@178-164-208-246.pool.digikabel.hu)
2023-06-06 23:39:29 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-06-06 23:41:39 +0200AlexNoo_(~AlexNoo@178.34.160.87)
2023-06-06 23:41:39 +0200AlexNoo(~AlexNoo@178.34.160.87) (Read error: Connection reset by peer)
2023-06-06 23:41:43 +0200phma_phma
2023-06-06 23:47:20 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 23:48:34 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Quit: leaving)
2023-06-06 23:50:27 +0200zero(~z@user/zero)
2023-06-06 23:50:59 +0200ec_(~ec@gateway/tor-sasl/ec)
2023-06-06 23:53:31 +0200yin(~z@user/zero) (Ping timeout: 250 seconds)
2023-06-06 23:58:08 +0200ec_(~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds)
2023-06-06 23:59:27 +0200sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)