IRCBrowse

2023/02/21

2023-02-21 00:00:11 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 255 seconds)
2023-02-21 00:02:08 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-02-21 00:02:45 +0100oxide(~lambda@user/oxide) (Ping timeout: 260 seconds)
2023-02-21 00:09:53 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-02-21 00:09:53 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-02-21 00:09:53 +0100wroathe(~wroathe@user/wroathe)
2023-02-21 00:14:43 +0100wroathe(~wroathe@user/wroathe) (Ping timeout: 246 seconds)
2023-02-21 00:16:54 +0100jespada(~jespada@77.98.179.16)
2023-02-21 00:19:58 +0100jespada_(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 246 seconds)
2023-02-21 00:27:48 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq)
2023-02-21 00:30:57 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2023-02-21 00:35:04 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 00:39:21 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 00:42:21 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds)
2023-02-21 01:01:08 +0100jwiegley(~jwiegley@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in)
2023-02-21 01:01:08 +0100johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in)
2023-02-21 01:09:58 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 01:14:49 +0100GuestW48(~GuestW48@46.146.247.46) (Quit: Client closed)
2023-02-21 01:15:21 +0100slack1256(~slack1256@186.11.53.84) (Ping timeout: 255 seconds)
2023-02-21 01:17:13 +0100mauke_(~mauke@user/mauke)
2023-02-21 01:18:30 +0100mauke(~mauke@user/mauke) (Ping timeout: 255 seconds)
2023-02-21 01:18:31 +0100mauke_mauke
2023-02-21 01:19:42 +0100elevenkb(~elevenkb@105.226.22.146) (Quit: Client closed)
2023-02-21 01:21:34 +0100random-jellyfish(~random-je@user/random-jellyfish) (Quit: Client closed)
2023-02-21 01:22:24 +0100sympt(~sympt@user/sympt)
2023-02-21 01:23:09 +0100mncheck(~mncheck@193.224.205.254) (Ping timeout: 268 seconds)
2023-02-21 01:28:07 +0100Tuplanolla(~Tuplanoll@91-159-68-152.elisa-laajakaista.fi) (Quit: Leaving.)
2023-02-21 01:33:20 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-02-21 01:33:57 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 01:36:20 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-02-21 01:36:20 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-02-21 01:36:20 +0100wroathe(~wroathe@user/wroathe)
2023-02-21 01:38:18 +0100wroathe(~wroathe@user/wroathe) (Client Quit)
2023-02-21 01:39:14 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-02-21 01:39:14 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-02-21 01:39:14 +0100wroathe(~wroathe@user/wroathe)
2023-02-21 01:45:15 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-02-21 01:45:59 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 01:46:20 +0100Square2(~Square4@user/square)
2023-02-21 01:47:31 +0100tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Quit: leaving)
2023-02-21 01:50:28 +0100king_gs(~Thunderbi@187.201.41.239)
2023-02-21 01:51:54 +0100prasadi01Newuser(~Thunderbi@c-73-22-232-123.hsd1.il.comcast.net)
2023-02-21 01:53:26 +0100nabaiste^(~nabaiste@c-24-30-76-89.hsd1.ga.comcast.net)
2023-02-21 01:53:52 +0100acidjnk(~acidjnk@p200300d6e715c4362c639e785d9ee9c9.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-02-21 01:57:30 +0100tessier(~treed@ip72-197-145-89.sd.sd.cox.net)
2023-02-21 02:00:38 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 02:02:30 +0100prasadi01Newuser(~Thunderbi@c-73-22-232-123.hsd1.il.comcast.net) (Ping timeout: 246 seconds)
2023-02-21 02:03:09 +0100Everything(~Everythin@46.185.124.65)
2023-02-21 02:04:52 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-02-21 02:05:29 +0100prasadi01Newuser(~Thunderbi@c-73-22-232-123.hsd1.il.comcast.net)
2023-02-21 02:09:52 +0100king_gs(~Thunderbi@187.201.41.239) (Read error: Connection reset by peer)
2023-02-21 02:09:56 +0100king_gs1(~Thunderbi@2806:103e:29:1779:2613:110c:f586:495b)
2023-02-21 02:10:01 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds)
2023-02-21 02:10:26 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 02:10:27 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-02-21 02:12:13 +0100king_gs1king_gs
2023-02-21 02:12:50 +0100jinsl(~jinsl@2408:8207:2557:8800:211:32ff:fec8:6aea) (Ping timeout: 255 seconds)
2023-02-21 02:12:54 +0100jinsl-(~jinsl@2408:8207:2558:e50:211:32ff:fec8:6aea)
2023-02-21 02:13:42 +0100prasadi01Newuser(~Thunderbi@c-73-22-232-123.hsd1.il.comcast.net) (Ping timeout: 246 seconds)
2023-02-21 02:15:07 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 246 seconds)
2023-02-21 02:15:39 +0100dcoutts_(~duncan@host86-167-90-212.range86-167.btcentralplus.com) (Ping timeout: 255 seconds)
2023-02-21 02:16:35 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-02-21 02:21:32 +0100oxide(~lambda@user/oxide)
2023-02-21 02:21:50 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 255 seconds)
2023-02-21 02:22:25 +0100sammelweis(~quassel@c-68-48-18-140.hsd1.mi.comcast.net)
2023-02-21 02:26:29 +0100Kuttenbrunzer(~Kuttenbru@2a02:8108:8b80:1d48::160)
2023-02-21 02:26:54 +0100xff0x(~xff0x@ai081074.d.east.v6connect.net) (Ping timeout: 252 seconds)
2023-02-21 02:28:19 +0100khumba(~khumba@user/khumba) ()
2023-02-21 02:30:03 +0100Square2(~Square4@user/square) (Ping timeout: 255 seconds)
2023-02-21 02:32:06 +0100Kuttenbrunzer(~Kuttenbru@2a02:8108:8b80:1d48::160) (Remote host closed the connection)
2023-02-21 02:35:47 +0100elbear(~lucian@188.25.92.21)
2023-02-21 02:40:15 +0100elbear(~lucian@188.25.92.21) (Ping timeout: 260 seconds)
2023-02-21 02:42:31 +0100gpncarl(~gpncarl@222.249.231.4)
2023-02-21 02:44:52 +0100gpncarl_(~gpncarl@222.249.231.4) (Ping timeout: 246 seconds)
2023-02-21 02:44:54 +0100oxide(~lambda@user/oxide) (Ping timeout: 255 seconds)
2023-02-21 02:49:12 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-02-21 02:50:12 +0100daylily[m](~daylilies@2001:470:69fc:105::3:1d06)
2023-02-21 02:55:46 +0100robobub(uid248673@id-248673.uxbridge.irccloud.com)
2023-02-21 03:01:35 +0100sammelweis(~quassel@c-68-48-18-140.hsd1.mi.comcast.net) (Quit: No Ping reply in 180 seconds.)
2023-02-21 03:03:40 +0100mikess_(~sam@user/mikess) (Quit: Reconnecting)
2023-02-21 03:03:54 +0100mikess(~sam@user/mikess)
2023-02-21 03:09:14 +0100gmg(~user@user/gehmehgeh)
2023-02-21 03:09:53 +0100daylily[m](~daylilies@2001:470:69fc:105::3:1d06) (Quit: Reconnecting)
2023-02-21 03:09:57 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 03:10:08 +0100daylily[m](~daylilies@2001:470:69fc:105::3:1d06)
2023-02-21 03:10:59 +0100gehmehgeh(~user@user/gehmehgeh) (Ping timeout: 255 seconds)
2023-02-21 03:11:20 +0100mikess(~sam@user/mikess) (Quit: leaving)
2023-02-21 03:11:21 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-02-21 03:11:51 +0100masterbuilder(~master@user/masterbuilder) (Quit: leaving)
2023-02-21 03:12:21 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net) (Ping timeout: 255 seconds)
2023-02-21 03:14:19 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net)
2023-02-21 03:27:51 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 03:28:28 +0100falafel(~falafel@2607:fb91:143f:e47f:e6ea:7941:8274:fc1b)
2023-02-21 03:29:23 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 03:29:59 +0100harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2023-02-21 03:34:57 +0100mikess(~sam@user/mikess)
2023-02-21 03:35:00 +0100king_gs(~Thunderbi@2806:103e:29:1779:2613:110c:f586:495b) (Quit: king_gs)
2023-02-21 03:35:32 +0100mikess(~sam@user/mikess) (Client Quit)
2023-02-21 03:36:02 +0100mikess(~sam@user/mikess)
2023-02-21 03:40:00 +0100telser(~quassel@user/telser) (Ping timeout: 248 seconds)
2023-02-21 03:40:43 +0100telser(~quassel@user/telser)
2023-02-21 03:53:08 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 03:56:15 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 03:57:18 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 246 seconds)
2023-02-21 03:59:00 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 04:01:24 +0100jero98772(~jero98772@2800:484:1d80:d8ce:9bb4:3da:515:fe96) (Remote host closed the connection)
2023-02-21 04:02:35 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Client Quit)
2023-02-21 04:03:09 +0100razetime(~Thunderbi@43.254.111.18)
2023-02-21 04:08:03 +0100mikess(~sam@user/mikess) (Quit: leaving)
2023-02-21 04:08:45 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 04:13:32 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 255 seconds)
2023-02-21 04:14:46 +0100jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2023-02-21 04:15:23 +0100jpds(~jpds@gateway/tor-sasl/jpds)
2023-02-21 04:15:27 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2023-02-21 04:15:52 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 246 seconds)
2023-02-21 04:17:35 +0100califax(~califax@user/califx) (Ping timeout: 255 seconds)
2023-02-21 04:17:53 +0100califax_(~califax@user/califx)
2023-02-21 04:18:56 +0100califax_califax
2023-02-21 04:24:09 +0100Guest7(~Guest7@138-51-70-192-lsn-2.nat.utoronto.ca)
2023-02-21 04:26:01 +0100use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection)
2023-02-21 04:26:20 +0100use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf)
2023-02-21 04:27:29 +0100Guest7(~Guest7@138-51-70-192-lsn-2.nat.utoronto.ca) (Client Quit)
2023-02-21 04:29:27 +0100mikoto-chan(~mikoto-ch@2001:999:70d:3f0d:268a:86d8:cb4d:8855)
2023-02-21 04:29:34 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 04:32:05 +0100razetime(~Thunderbi@43.254.111.18) (Read error: Connection reset by peer)
2023-02-21 04:34:41 +0100gmg(~user@user/gehmehgeh) (Ping timeout: 255 seconds)
2023-02-21 04:37:19 +0100harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-02-21 04:38:10 +0100razetime(~Thunderbi@43.254.111.18)
2023-02-21 04:40:08 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-02-21 04:42:42 +0100gmg(~user@user/gehmehgeh)
2023-02-21 04:42:46 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 04:44:53 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 04:47:12 +0100td_(~td@i5387093A.versanet.de) (Ping timeout: 248 seconds)
2023-02-21 04:47:26 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 04:48:07 +0100 <segfaultfizzbuzz> is there an unscientific guide as to at what point i might generally expect problems with summation when using f16, f32, and f64, in regards to N, the number of items i am summing?
2023-02-21 04:48:27 +0100 <segfaultfizzbuzz> that is to say "once N is bigger than X, you should start to worry about your summation being accurate", what is X?
2023-02-21 04:48:38 +0100 <segfaultfizzbuzz> for each of f16, f32, f64
2023-02-21 04:49:18 +0100td_(~td@i5387093F.versanet.de)
2023-02-21 04:51:16 +0100 <Axman6> you could just use my foldl-statistics package, which implements kahan summation (IIRC, pretty sure that's what it's called)
2023-02-21 04:51:35 +0100 <segfaultfizzbuzz> thanks, right, but my question is, as a rule of thumb, when will i need it
2023-02-21 04:51:48 +0100 <segfaultfizzbuzz> is it at 10,000 items, at a million, at a trillion items?
2023-02-21 04:53:18 +0100 <Axman6> you could probably read the paper(s) by kahan et al. to find out
2023-02-21 04:53:51 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 04:54:50 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-02-21 04:54:50 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-02-21 04:54:50 +0100finn_elijaFinnElija
2023-02-21 04:55:49 +0100 <Axman6> there's probably several factors to consider, including the range of values, if you're dding numbers in the range of 10^10 and 10^-10, you're probably going to lose precision
2023-02-21 04:56:09 +0100 <segfaultfizzbuzz> yes i know the distribution and magnitude of the numbers is significant
2023-02-21 04:56:25 +0100 <segfaultfizzbuzz> which is why i introduced this as an unscientific question
2023-02-21 04:56:25 +0100 <Axman6> I wonder if adding things using Scientific would be guaranteed to mintain full precision
2023-02-21 04:58:11 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 05:00:00 +0100telser(~quassel@user/telser) (Ping timeout: 248 seconds)
2023-02-21 05:00:22 +0100telser(~quassel@user/telser)
2023-02-21 05:08:22 +0100tessier(~treed@ip72-197-145-89.sd.sd.cox.net) (Ping timeout: 246 seconds)
2023-02-21 05:10:36 +0100tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-02-21 05:12:57 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net) (Ping timeout: 255 seconds)
2023-02-21 05:13:53 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net)
2023-02-21 05:20:56 +0100wroathe(~wroathe@user/wroathe) (Ping timeout: 255 seconds)
2023-02-21 05:21:03 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 255 seconds)
2023-02-21 05:27:08 +0100razetime(~Thunderbi@43.254.111.18) (Remote host closed the connection)
2023-02-21 05:29:08 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds)
2023-02-21 05:32:11 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 255 seconds)
2023-02-21 05:32:47 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 05:35:01 +0100stackdroid18(14094@de1.hashbang.sh) (Quit: hasta la vista... tchau!)
2023-02-21 05:37:45 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-02-21 05:38:07 +0100thegeekinside(~thegeekin@189.180.66.126) (Ping timeout: 246 seconds)
2023-02-21 05:39:47 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 05:40:55 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 246 seconds)
2023-02-21 05:41:13 +0100johnw(~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net)
2023-02-21 05:41:44 +0100jwiegley(~jwiegley@2600:1700:cf00:db0:a854:9d9d:a060:90b3)
2023-02-21 05:41:46 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-02-21 05:43:11 +0100merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 248 seconds)
2023-02-21 05:43:25 +0100thegeekinside(~thegeekin@189.180.66.126)
2023-02-21 05:44:55 +0100waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 252 seconds)
2023-02-21 05:45:18 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-02-21 05:45:49 +0100mikoto-chan(~mikoto-ch@2001:999:70d:3f0d:268a:86d8:cb4d:8855) (Ping timeout: 246 seconds)
2023-02-21 05:47:04 +0100Everything(~Everythin@46.185.124.65) (Quit: leaving)
2023-02-21 05:47:39 +0100Sgeo(~Sgeo@user/sgeo)
2023-02-21 05:54:23 +0100elbear(~lucian@188.25.92.21)
2023-02-21 05:58:51 +0100elbear(~lucian@188.25.92.21) (Ping timeout: 255 seconds)
2023-02-21 05:58:52 +0100Vajb(~Vajb@2001:999:484:9db9:7ff5:c370:5511:7e1c) (Read error: Connection reset by peer)
2023-02-21 05:59:59 +0100Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi)
2023-02-21 06:00:10 +0100polyphem(~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) (Ping timeout: 252 seconds)
2023-02-21 06:02:00 +0100abhixec(~abhinav@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
2023-02-21 06:03:07 +0100razetime(~Thunderbi@43.254.111.18)
2023-02-21 06:05:05 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 252 seconds)
2023-02-21 06:06:36 +0100gpncarl_(~gpncarl@222.249.231.4)
2023-02-21 06:06:47 +0100p0lyph3m(~polyphem@2a02:810d:840:8754:4d31:9178:35f:6608) (Ping timeout: 264 seconds)
2023-02-21 06:07:21 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 06:08:40 +0100gpncarl(~gpncarl@222.249.231.4) (Ping timeout: 268 seconds)
2023-02-21 06:08:51 +0100abhixec(~abhinav@c-67-169-139-16.hsd1.ca.comcast.net)
2023-02-21 06:09:10 +0100Vajb(~Vajb@hag-jnsbng11-58c3a5-27.dhcp.inet.fi) (Read error: Connection reset by peer)
2023-02-21 06:09:53 +0100Vajb(~Vajb@2001:999:484:9db9:7ff5:c370:5511:7e1c)
2023-02-21 06:10:12 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 06:14:37 +0100elbear(~lucian@188.25.92.21)
2023-02-21 06:19:06 +0100elbear(~lucian@188.25.92.21) (Ping timeout: 255 seconds)
2023-02-21 06:24:36 +0100gpncarl(~gpncarl@210.12.195.2)
2023-02-21 06:25:00 +0100gpncarl_(~gpncarl@222.249.231.4) (Ping timeout: 246 seconds)
2023-02-21 06:30:56 +0100zmt00(~zmt00@user/zmt00) (Quit: Leaving)
2023-02-21 06:31:45 +0100 <Inst> what's the official stance on operator overloading too much?
2023-02-21 06:33:21 +0100zmt00(~zmt00@user/zmt00)
2023-02-21 06:36:36 +0100 <Inst> as in, i've defined Rock >= Paper = False
2023-02-21 06:36:42 +0100 <c_wraith> operators are names. They can be good or bad. *overloading* in particular is sketchy, just like overloading names is.
2023-02-21 06:36:58 +0100 <Inst> and custom Show instances
2023-02-21 06:37:00 +0100 <c_wraith> yeah, that's sketchy. Ord is assumed to define a total order
2023-02-21 06:37:05 +0100 <Inst> okay, thanks
2023-02-21 06:37:07 +0100 <Inst> not good practice
2023-02-21 06:37:37 +0100 <c_wraith> Show is less constrained, though. Some people think it should always generate valid Haskell code, but really it's just for debugging anyway.
2023-02-21 06:37:59 +0100 <c_wraith> also, sometimes derived Show instances are terrible
2023-02-21 06:38:47 +0100 <Inst> it shouldn't be used in production code iirc, because String is cancer
2023-02-21 06:38:52 +0100 <Inst> showt or something like that
2023-02-21 06:39:11 +0100talismanick(~talismani@45.23.184.231)
2023-02-21 06:39:14 +0100 <c_wraith> String is fine unless you're handing binary data or megabytes of data
2023-02-21 06:40:00 +0100 <c_wraith> (though there are cases like Filepath where String is *semantically* wrong, and those ones are sketchy)
2023-02-21 06:40:14 +0100razetime(~Thunderbi@43.254.111.18) (Quit: See You Space Cowboy)
2023-02-21 06:41:10 +0100elbear(~lucian@188.25.92.21)
2023-02-21 06:44:41 +0100nabaiste^(~nabaiste@c-24-30-76-89.hsd1.ga.comcast.net) (Remote host closed the connection)
2023-02-21 06:45:21 +0100 <Inst> new sanctioned prelude when?
2023-02-21 06:45:23 +0100 <sm> String is cancer is hyperbole
2023-02-21 06:48:06 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 06:48:11 +0100gpncarl_(~gpncarl@222.249.231.4)
2023-02-21 06:48:15 +0100gpncarl(~gpncarl@210.12.195.2) (Ping timeout: 248 seconds)
2023-02-21 06:51:04 +0100 <Inst> list vs array basically comes down to lists are terrible at random access, right?
2023-02-21 06:51:13 +0100 <Inst> but have O(1) append to front
2023-02-21 06:53:02 +0100 <sm> That sounds right. Lists can change size easily and are handy for lazy algorithms. On a practical level they are also much easier because built in.
2023-02-21 06:53:17 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 06:54:10 +0100 <sm> and of course "terrible" depends on scale
2023-02-21 06:54:17 +0100 <c_wraith> It's also worth pointing out that algorithms that work on *text* basically can't use random access once you work with the entirety of unicode
2023-02-21 06:54:38 +0100 <c_wraith> Like, unicode is just too complex to treat that way
2023-02-21 06:55:08 +0100 <Inst> tbh i'm sort of wondering as to whether "lazy in the spine, strict in the leaves" is even good practice, i'm starting to appreciate how fully lazy lists can be useful
2023-02-21 06:56:10 +0100GuestW48(~GuestW48@46.146.247.46)
2023-02-21 06:56:38 +0100JimL(~quassel@89-162-26-217.fiber.signal.no) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2023-02-21 06:57:15 +0100 <Inst> the thunks are a series of function evaluations, right?
2023-02-21 06:57:35 +0100 <Inst> *applications, right?
2023-02-21 06:57:50 +0100 <Inst> if I have a datatype that's a long chain of function applications, it might be best not to fully evaluate via any strictness
2023-02-21 06:58:14 +0100 <sm> yes, sometimes laziness is what you want
2023-02-21 06:58:49 +0100 <Inst> so i can random access the thunk i want and only evaluate that one, instead of having to evaluate everything else along the way
2023-02-21 06:59:16 +0100jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2023-02-21 07:02:17 +0100jakalx(~jakalx@base.jakalx.net)
2023-02-21 07:06:35 +0100gastus(~gastus@5.83.191.28)
2023-02-21 07:06:54 +0100 <gastus> How to have a query('select') return rows with names which can be typed ?
2023-02-21 07:07:02 +0100 <gastus> something like uery() as {name: string} in TypeScript ?
2023-02-21 07:10:55 +0100falafel(~falafel@2607:fb91:143f:e47f:e6ea:7941:8274:fc1b) (Ping timeout: 260 seconds)
2023-02-21 07:11:39 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-02-21 07:24:10 +0100elbear(~lucian@188.25.92.21) (Ping timeout: 246 seconds)
2023-02-21 07:25:37 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 07:27:30 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 07:38:37 +0100Inst(~Inst@2601:6c4:4081:54f0:d621:5cdd:9051:c240) (Read error: Connection reset by peer)
2023-02-21 07:42:29 +0100delYsid(~user@user/delYsid)
2023-02-21 07:43:43 +0100codaraxis(~codaraxis@user/codaraxis) (Quit: Leaving)
2023-02-21 07:44:12 +0100trev(~trev@user/trev)
2023-02-21 07:47:59 +0100michalz(~michalz@185.246.207.215)
2023-02-21 07:48:19 +0100lagash_(~lagash@lagash.shelltalk.net) (Ping timeout: 246 seconds)
2023-02-21 07:49:04 +0100motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 248 seconds)
2023-02-21 07:52:03 +0100MelMalikEllenor
2023-02-21 07:52:52 +0100analoq(~yashi@user/dies) (Ping timeout: 246 seconds)
2023-02-21 07:54:44 +0100analoq(~yashi@user/dies)
2023-02-21 07:55:37 +0100lagash_(~lagash@lagash.shelltalk.net)
2023-02-21 07:59:01 +0100elbear(~lucian@188.25.92.21)
2023-02-21 08:02:03 +0100motherfsck(~motherfsc@user/motherfsck)
2023-02-21 08:02:31 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-02-21 08:08:55 +0100mastarija(~mastarija@188.252.197.148)
2023-02-21 08:12:05 +0100kenran(~user@user/kenran)
2023-02-21 08:12:30 +0100czy(~user@host-140-23.ilcub310.champaign.il.us.clients.pavlovmedia.net) (Ping timeout: 255 seconds)
2023-02-21 08:12:33 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2023-02-21 08:12:37 +0100mei(~mei@user/mei)
2023-02-21 08:14:07 +0100elbear(~lucian@188.25.92.21) (Ping timeout: 248 seconds)
2023-02-21 08:19:35 +0100motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 255 seconds)
2023-02-21 08:20:12 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 08:23:43 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2023-02-21 08:29:42 +0100lottaquestions_(~nick@2607:fa49:503e:7100:ab:1d1a:a3a6:1b51) (Remote host closed the connection)
2023-02-21 08:30:07 +0100lottaquestions_(~nick@2607:fa49:503e:7100:376d:3f27:951:60f7)
2023-02-21 08:32:45 +0100thegeekinside(~thegeekin@189.180.66.126) (Ping timeout: 255 seconds)
2023-02-21 08:38:11 +0100motherfsck(~motherfsc@user/motherfsck)
2023-02-21 08:50:00 +0100elbear(~lucian@109.101.137.234)
2023-02-21 08:55:55 +0100mncheckm(~mncheck@193.224.205.254)
2023-02-21 08:57:15 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 08:58:38 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 08:59:03 +0100mikoto-chan(~mikoto-ch@2001:999:70d:3f0d:268a:86d8:cb4d:8855)
2023-02-21 09:02:47 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:1c4d:fe05:e8b3:ebb4)
2023-02-21 09:07:23 +0100fryguybob(~fryguybob@cpe-24-94-51-210.stny.res.rr.com) (Ping timeout: 246 seconds)
2023-02-21 09:08:00 +0100aweinstock(~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com) (Ping timeout: 248 seconds)
2023-02-21 09:09:06 +0100mjrosenb(~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net)
2023-02-21 09:09:29 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-02-21 09:11:17 +0100 <mjrosenb> I'm getting `Map.!: given key is not an element in the map` with a single entry in the call stack. I kind of suspect this is coming from lens, not any use of ! that I have directly
2023-02-21 09:11:32 +0100 <mjrosenb> a) Is there anything I can do to get an actual call stack?
2023-02-21 09:12:02 +0100 <mjrosenb> b) what in lens is likely to produce this error? at and ix both don't use (!) from what I can tell.
2023-02-21 09:14:52 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 09:16:21 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 09:17:03 +0100 <sm> mjrosenb: you can build with profiling enabled and then run with +RTS -xc to get a call stack (actually many call stacks, yours among them)
2023-02-21 09:18:04 +0100 <sm> searching the web might tell more
2023-02-21 09:18:43 +0100 <mjrosenb> sm: caveat: this isn't using ghc, it is using ghcjs. Is there a way of doing things like -xc with ghcjs?
2023-02-21 09:19:03 +0100 <sm> though the internet tells me that message comes from elm..
2023-02-21 09:19:05 +0100 <sm> don't know, sorry
2023-02-21 09:20:10 +0100 <sm> a dumb way to debug is walk an error call through your code line by line until you find where it fails
2023-02-21 09:20:50 +0100ell(~ellie@user/ellie) (Quit: ill be backkk)
2023-02-21 09:23:05 +0100 <mjrosenb> yeah, I tried that, there is a bit too much code and a bit too much state to make that easy.
2023-02-21 09:24:24 +0100 <mjrosenb> blech.
2023-02-21 09:24:25 +0100 <mjrosenb> ghcjs: unrecognised flag: --enable-profiling
2023-02-21 09:25:06 +0100 <sm> enabling/doing profiling is extremely hard I find, except with stack build --profile
2023-02-21 09:25:33 +0100 <sm> for ghc[js] it might be -prof
2023-02-21 09:25:39 +0100 <sm> ...and something else..
2023-02-21 09:25:45 +0100mauke(~mauke@user/mauke) (Quit: bbl)
2023-02-21 09:27:19 +0100 <mjrosenb> ahh, indeed. that is working better
2023-02-21 09:27:34 +0100mjrosenbwonders where the `--enable-profiling` misinformation came from
2023-02-21 09:30:12 +0100 <sm> that's a cabal build flag
2023-02-21 09:30:25 +0100 <sm> every tool does it differently :)
2023-02-21 09:34:14 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba)
2023-02-21 09:34:24 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 09:34:34 +0100nschoe(~q@141.101.51.197)
2023-02-21 09:35:01 +0100 <mjrosenb> whooo!
2023-02-21 09:35:06 +0100 <mjrosenb> CallStack (from -prof): Match.Builder.CAF (<entire-module>) rts.js:6048:15
2023-02-21 09:35:18 +0100 <mjrosenb> I have... a module
2023-02-21 09:35:39 +0100 <mjrosenb> which eliminates 95% of the places that I need to look!
2023-02-21 09:36:38 +0100Hammdist(~Hammdist@67.169.114.135) (Ping timeout: 260 seconds)
2023-02-21 09:37:00 +0100elbear(~lucian@109.101.137.234) (Ping timeout: 252 seconds)
2023-02-21 09:37:56 +0100MajorBiscuit(~MajorBisc@c-001-020-009.client.tudelft.eduvpn.nl)
2023-02-21 09:37:59 +0100motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 264 seconds)
2023-02-21 09:39:27 +0100fryguybob(~fryguybob@cpe-24-94-51-210.stny.res.rr.com)
2023-02-21 09:39:30 +0100acidjnk(~acidjnk@p200300d6e715c433acad43775727ee93.dip0.t-ipconnect.de)
2023-02-21 09:41:09 +0100aweinstock(~aweinstoc@cpe-74-76-189-75.nycap.res.rr.com)
2023-02-21 09:41:24 +0100cfricke(~cfricke@user/cfricke)
2023-02-21 09:41:41 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 09:42:02 +0100zeenk(~zeenk@2a02:2f04:a214:1e00::7fe)
2023-02-21 09:43:55 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 09:45:59 +0100elbear(~lucian@109.101.137.234)
2023-02-21 09:46:49 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7)
2023-02-21 09:55:05 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-02-21 09:57:07 +0100ell(~ellie@user/ellie)
2023-02-21 09:57:32 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 09:57:37 +0100rlj(~rlj@c-5eea7342-74736162.cust.telenor.se)
2023-02-21 09:58:06 +0100ell(~ellie@user/ellie) (Remote host closed the connection)
2023-02-21 09:58:42 +0100elbear(~lucian@109.101.137.234) (Ping timeout: 255 seconds)
2023-02-21 09:58:59 +0100discuss9128(~discuss91@137.132.215.133)
2023-02-21 09:59:57 +0100elbear(~lucian@109.101.137.234)
2023-02-21 10:00:32 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Remote host closed the connection)
2023-02-21 10:04:22 +0100SoF(~skius@user/skius) (Quit: Ping timeout (120 seconds))
2023-02-21 10:04:52 +0100SoF(~skius@user/skius)
2023-02-21 10:04:55 +0100ell(~ellie@user/ellie)
2023-02-21 10:06:39 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-02-21 10:13:54 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2023-02-21 10:16:00 +0100elbear(~lucian@109.101.137.234) (Quit: leaving)
2023-02-21 10:20:38 +0100stilgart(~Christoph@chezlefab.net) (Ping timeout: 255 seconds)
2023-02-21 10:21:20 +0100stilgart(~Christoph@chezlefab.net)
2023-02-21 10:23:12 +0100GuestW48(~GuestW48@46.146.247.46) (Quit: Client closed)
2023-02-21 10:25:01 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 10:26:03 +0100Axman6(~Axman6@user/axman6) (Ping timeout: 240 seconds)
2023-02-21 10:26:50 +0100freeside(~mengwong@122.11.248.245)
2023-02-21 10:27:07 +0100mikoto-chan(~mikoto-ch@2001:999:70d:3f0d:268a:86d8:cb4d:8855) (Ping timeout: 248 seconds)
2023-02-21 10:36:54 +0100mikoto-chan(~mikoto-ch@2001:999:70d:3f0d:268a:86d8:cb4d:8855)
2023-02-21 10:41:12 +0100mauke(~mauke@user/mauke)
2023-02-21 10:42:54 +0100discuss9128(~discuss91@137.132.215.133) (Quit: Client closed)
2023-02-21 10:44:41 +0100kuribas(~user@ptr-17d51eohw70nwasehcd.18120a2.ip6.access.telenet.be)
2023-02-21 10:45:50 +0100tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz)
2023-02-21 10:47:55 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 260 seconds)
2023-02-21 10:51:10 +0100_xor(~xor@72.49.195.228)
2023-02-21 10:55:34 +0100ft(~ft@p3e9bc443.dip0.t-ipconnect.de) (Quit: leaving)
2023-02-21 10:58:56 +0100mmhat(~mmh@2003:f1:c71c:17cb:ee08:6bff:fe09:5315)
2023-02-21 11:01:00 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 11:02:36 +0100random-jellyfish(~random-je@user/random-jellyfish)
2023-02-21 11:02:51 +0100acidjnk(~acidjnk@p200300d6e715c433acad43775727ee93.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-02-21 11:03:55 +0100gpncarl_(~gpncarl@222.249.231.4) (Ping timeout: 252 seconds)
2023-02-21 11:05:19 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Ping timeout: 248 seconds)
2023-02-21 11:06:35 +0100cfricke(~cfricke@user/cfricke) (Ping timeout: 248 seconds)
2023-02-21 11:07:59 +0100freeside(~mengwong@122.11.248.245) (Ping timeout: 264 seconds)
2023-02-21 11:08:20 +0100freeside(~mengwong@122.11.248.245)
2023-02-21 11:08:43 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds)
2023-02-21 11:08:50 +0100acidjnk(~acidjnk@p200300d6e715c433acad43775727ee93.dip0.t-ipconnect.de)
2023-02-21 11:13:31 +0100freeside(~mengwong@122.11.248.245) (Ping timeout: 248 seconds)
2023-02-21 11:15:31 +0100jespada(~jespada@77.98.179.16) (Remote host closed the connection)
2023-02-21 11:16:19 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-02-21 11:17:13 +0100gpncarl_(~gpncarl@222.249.231.4)
2023-02-21 11:17:52 +0100Axman6(~Axman6@user/axman6)
2023-02-21 11:18:44 +0100dcoutts_(~duncan@host86-153-135-38.range86-153.btcentralplus.com)
2023-02-21 11:20:50 +0100 <sm> mjrosenb: nice
2023-02-21 11:21:11 +0100dcoutts(~duncan@host86-167-90-212.range86-167.btcentralplus.com) (Ping timeout: 264 seconds)
2023-02-21 11:21:32 +0100 <sm> it sounds like a large minified js, unfortunately. Any luck ?
2023-02-21 11:25:13 +0100ph88(~ph88@ip5b426553.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2023-02-21 11:26:49 +0100 <cheater> can someone tell me why "2" and "running clients" never gets printed? http://sprunge.us/8tgb1e
2023-02-21 11:27:12 +0100 <cheater> i used to know why but i forgot :p
2023-02-21 11:27:13 +0100 <merijn> cheater: That pastebin immediately disconnects me?
2023-02-21 11:27:21 +0100 <cheater> ???
2023-02-21 11:27:28 +0100Square2(~Square4@user/square)
2023-02-21 11:27:42 +0100 <merijn> This site can’t be reachedsprunge.us unexpectedly closed the connection.
2023-02-21 11:27:55 +0100 <cheater> https://paste.tomsmeding.com/MQePIeIx
2023-02-21 11:28:42 +0100 <merijn> cheater: race kills the slowest action, afaik?
2023-02-21 11:29:01 +0100 <merijn> So as soon as runServer finishes, the second argument (do block) gets killed
2023-02-21 11:29:02 +0100 <cheater> hmm
2023-02-21 11:29:16 +0100 <cheater> right
2023-02-21 11:29:35 +0100 <cheater> what's the best way to run two threads again so they both finish?
2023-02-21 11:29:54 +0100 <cheater> no wait i guess i don't want that
2023-02-21 11:29:55 +0100 <Hecate> https://play-haskell.tomsmeding.com/saved/lGo1Z5va
2023-02-21 11:29:58 +0100 <Hecate> cheater: ^
2023-02-21 11:30:51 +0100 <cheater> Hecate: did you change nothing?
2023-02-21 11:31:34 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 11:32:32 +0100 <cheater> Hecate: why link me to that?
2023-02-21 11:32:35 +0100 <cheater> i'm confused
2023-02-21 11:33:23 +0100 <Hecate> cheater: you can provide people with a playground of your code so that we can experiment with it from the browser :)
2023-02-21 11:33:31 +0100 <Hecate> or see the Core generated by your code ;)
2023-02-21 11:41:23 +0100econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2023-02-21 11:41:31 +0100teo(~teo@user/teo)
2023-02-21 11:41:46 +0100 <[Leary]> tomsmeding: The playground doesn't handle `forever` very well. It would be good if it printed output produced prior to the time-out.
2023-02-21 11:44:15 +0100mmhat(~mmh@2003:f1:c71c:17cb:ee08:6bff:fe09:5315) (Ping timeout: 252 seconds)
2023-02-21 11:44:37 +0100mmhat(~mmh@p200300f1c71c1721ee086bfffe095315.dip0.t-ipconnect.de)
2023-02-21 11:45:16 +0100pja(~pja@2a02:8010:6098:0:e65f:1ff:fe1f:660f) (Quit: WeeChat 3.7.1)
2023-02-21 11:45:20 +0100abcdw(8c3442b76e@user/abcdw) ()
2023-02-21 11:46:08 +0100APic(apic@apic.name) (Ping timeout: 255 seconds)
2023-02-21 11:47:12 +0100ubert1(~Thunderbi@2a02:8109:abc0:6434:2da3:d0c8:ac16:be0)
2023-02-21 11:47:56 +0100CiaoSen(~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2023-02-21 11:53:03 +0100talismanick(~talismani@45.23.184.231) (Ping timeout: 252 seconds)
2023-02-21 11:53:21 +0100mikoto-chan(~mikoto-ch@2001:999:70d:3f0d:268a:86d8:cb4d:8855) (Quit: WeeChat 3.6)
2023-02-21 12:01:06 +0100xff0x(~xff0x@ai081074.d.east.v6connect.net)
2023-02-21 12:07:03 +0100Square2Square
2023-02-21 12:10:28 +0100gpncarl_(~gpncarl@222.249.231.4) (Ping timeout: 246 seconds)
2023-02-21 12:18:31 +0100akegalj(~akegalj@93.138.138.10)
2023-02-21 12:21:45 +0100shapr(~user@net-5-88-239-92.cust.vodafonedsl.it)
2023-02-21 12:21:58 +0100Guest80(~Guest@2409:4073:210:5665:5582:5742:1289:a32d)
2023-02-21 12:22:17 +0100gpncarl_(~gpncarl@222.249.231.4)
2023-02-21 12:32:13 +0100Guest80(~Guest@2409:4073:210:5665:5582:5742:1289:a32d) (Ping timeout: 260 seconds)
2023-02-21 12:43:24 +0100APic(apic@apic.name)
2023-02-21 12:52:19 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 12:56:07 +0100_xor(~xor@72.49.195.228) (Ping timeout: 252 seconds)
2023-02-21 12:57:23 +0100_xor(~xor@72.49.195.228)
2023-02-21 13:12:13 +0100delYsid(~user@user/delYsid) (ERC 5.4.1 (IRC client for GNU Emacs 30.0.50))
2023-02-21 13:13:25 +0100gastus(~gastus@5.83.191.28) (Remote host closed the connection)
2023-02-21 13:13:40 +0100gastus(~gastus@5.83.191.28)
2023-02-21 13:17:35 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds)
2023-02-21 13:18:00 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 13:18:29 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 13:21:11 +0100 <eldritchcookie[m> how do i translate my haskell application?
2023-02-21 13:21:29 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-02-21 13:21:43 +0100jbalint(~jbalint@2600:6c44:117f:e98a:816a:9488:fb1:7b7) (Quit: Bye!)
2023-02-21 13:21:53 +0100jbalint(~jbalint@2600:6c44:117f:e98a:816a:9488:fb1:7b7)
2023-02-21 13:24:02 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 268 seconds)
2023-02-21 13:25:19 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-02-21 13:26:20 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 13:32:00 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 255 seconds)
2023-02-21 13:32:30 +0100cfricke(~cfricke@user/cfricke)
2023-02-21 13:40:38 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 13:43:29 +0100 <akegalj> eldritchcookie[m: maybe some of these packages could help https://hackage.haskell.org/packages/search?terms=i18n
2023-02-21 13:45:20 +0100mmhat(~mmh@p200300f1c71c1721ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.8)
2023-02-21 13:51:08 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 13:53:09 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net) (Ping timeout: 255 seconds)
2023-02-21 13:54:01 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net)
2023-02-21 13:54:16 +0100cheater_(~Username@user/cheater)
2023-02-21 13:56:13 +0100cheater_(~Username@user/cheater) (Read error: Connection reset by peer)
2023-02-21 13:56:58 +0100cheater_(~Username@user/cheater)
2023-02-21 13:57:38 +0100lyle(~lyle@104.246.145.237)
2023-02-21 13:57:39 +0100cheater(~Username@user/cheater) (Ping timeout: 255 seconds)
2023-02-21 13:57:43 +0100cheater_cheater
2023-02-21 13:59:54 +0100Midjak(~Midjak@82.66.147.146)
2023-02-21 14:01:42 +0100xff0x(~xff0x@ai081074.d.east.v6connect.net) (Ping timeout: 255 seconds)
2023-02-21 14:02:48 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 14:03:24 +0100xff0x(~xff0x@178.255.149.135)
2023-02-21 14:09:03 +0100xff0x(~xff0x@178.255.149.135) (Ping timeout: 268 seconds)
2023-02-21 14:10:38 +0100xff0x(~xff0x@2405:6580:b080:900:98be:c248:cb93:86bb)
2023-02-21 14:12:58 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 246 seconds)
2023-02-21 14:14:27 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2023-02-21 14:17:03 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 14:17:51 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 248 seconds)
2023-02-21 14:17:52 +0100enoq(~enoq@2a05:1141:1f5:5600:b9c9:721a:599:bfe7) (Quit: enoq)
2023-02-21 14:21:59 +0100xff0x(~xff0x@2405:6580:b080:900:98be:c248:cb93:86bb) (Ping timeout: 246 seconds)
2023-02-21 14:23:55 +0100xff0x(~xff0x@ai081074.d.east.v6connect.net)
2023-02-21 14:28:31 +0100gpncarl(~gpncarl@222.249.231.4)
2023-02-21 14:30:10 +0100use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection)
2023-02-21 14:30:23 +0100CiaoSen(~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2023-02-21 14:30:29 +0100use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf)
2023-02-21 14:30:43 +0100m1dnight(~christoph@78.22.0.121) (Ping timeout: 252 seconds)
2023-02-21 14:30:51 +0100gpncarl_(~gpncarl@222.249.231.4) (Ping timeout: 248 seconds)
2023-02-21 14:31:23 +0100m1dnight(~christoph@78-22-0-121.access.telenet.be)
2023-02-21 14:32:13 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 246 seconds)
2023-02-21 14:33:15 +0100jero98772(~jero98772@2800:484:1d80:d8ce:afc:ac:1a46:ba2c)
2023-02-21 14:35:34 +0100c0c0(~coco@212.51.146.137)
2023-02-21 14:46:28 +0100c0c0(~coco@212.51.146.137) (Quit: WeeChat 3.7.1)
2023-02-21 14:47:41 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 14:51:27 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:1c4d:fe05:e8b3:ebb4) (Ping timeout: 248 seconds)
2023-02-21 14:52:35 +0100polyphem(~polyphem@2a02:810d:840:8754:4d31:9178:35f:6608)
2023-02-21 14:53:19 +0100thegeekinside(~thegeekin@189.180.66.126)
2023-02-21 14:55:11 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 248 seconds)
2023-02-21 14:56:11 +0100polyphem_(~rod@2a02:810d:840:8754:56e9:3db:815e:932d)
2023-02-21 14:57:20 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer)
2023-02-21 14:57:50 +0100cheater_(~Username@user/cheater)
2023-02-21 15:01:28 +0100cheater(~Username@user/cheater) (Ping timeout: 268 seconds)
2023-02-21 15:01:34 +0100cheater_cheater
2023-02-21 15:03:50 +0100akegalj(~akegalj@93.138.138.10) (Quit: Lost terminal)
2023-02-21 15:04:47 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 15:05:02 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 15:09:03 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Ping timeout: 248 seconds)
2023-02-21 15:09:16 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2023-02-21 15:12:48 +0100 <akadude[m]> Can you recommend a package that allows to generate a type of tags for a sum-type, like this:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6f629f96c0094021e7707e46a0de9e0f51cb…>)
2023-02-21 15:13:19 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 15:14:05 +0100 <segfaultfizzbuzz> is there such a thing as a lazy/nonstrict language (like haskell) but which is strict by compilation? put another way, do i *need* a runtime to do lazy evaluation? i guess that's just --XStrict or whateer the option is, eh?
2023-02-21 15:15:13 +0100ystael(~ystael@user/ystael)
2023-02-21 15:15:25 +0100 <akadude[m]> What does "strict by compilation" means?
2023-02-21 15:17:15 +0100enoq(~enoq@194-208-133-121.lampert.tv)
2023-02-21 15:17:27 +0100 <merijn> segfaultfizzbuzz: The question is: what do you mean by "need" and "runtime" ;)
2023-02-21 15:17:48 +0100 <merijn> segfaultfizzbuzz: Do you need a separate "runtime system" library that gets linked into code? No.
2023-02-21 15:18:09 +0100 <geekosaur> any strict language can be made lazy by replacing values with functions that produce those values; it's just inefficient
2023-02-21 15:18:15 +0100 <merijn> But keep in mind that even (hosted) C has a runtime system (granted, a far more minimal one than Haskell(
2023-02-21 15:20:00 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 15:20:29 +0100 <merijn> segfaultfizzbuzz: Before any tries to answer this question, I think we should maybe clarify what you think the runtime system is/does and why you think this relates to strict vs laziness
2023-02-21 15:21:34 +0100gastus(~gastus@5.83.191.28) (Ping timeout: 246 seconds)
2023-02-21 15:23:43 +0100gastus(~gastus@5.83.191.28)
2023-02-21 15:25:04 +0100acidjnk(~acidjnk@p200300d6e715c433acad43775727ee93.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-02-21 15:27:16 +0100 <mauke> > dataTypeConstrs (dataTypeOf False)
2023-02-21 15:27:18 +0100 <lambdabot> [False,True]
2023-02-21 15:27:57 +0100 <mauke> > dataTypeConstrs (dataTypeOf (Just 'x'))
2023-02-21 15:27:59 +0100 <lambdabot> [Nothing,Just]
2023-02-21 15:28:41 +0100 <mauke> akadude[m]: does that count?
2023-02-21 15:32:23 +0100 <segfaultfizzbuzz> merijn: well my poor-quality impression is that i guess somehow something (GHC/haskell runtime?) decides what uh, thunk? code? is being invoked, perhaps via some IO, and then from that heuristically decides what needs to be evaluated,...
2023-02-21 15:33:00 +0100 <mauke> what's heuristic about it?
2023-02-21 15:33:51 +0100 <segfaultfizzbuzz> well haskell is not lazy but rather nonstrict, right? so sometimes it will decide that something needs to be evaluated based on some kind of guess rather than empirical need
2023-02-21 15:34:06 +0100 <segfaultfizzbuzz> kind of like speculative evaluation,... or this is my impression anyway
2023-02-21 15:34:47 +0100 <mauke> lazy is a subset of non-strict
2023-02-21 15:35:06 +0100 <segfaultfizzbuzz> right, you could call that "strictly lazy" lol
2023-02-21 15:35:26 +0100 <mauke> laziness is about caching expressions when they are evaluated
2023-02-21 15:35:45 +0100 <segfaultfizzbuzz> oh wow what? it's about caching?
2023-02-21 15:35:58 +0100 <segfaultfizzbuzz> that's rather interesting
2023-02-21 15:36:28 +0100 <mauke> consider something like f x = x + x; f (sqrt 5)
2023-02-21 15:36:45 +0100 <mauke> a strict language would evaluate sqrt 5 before calling f
2023-02-21 15:36:55 +0100 <merijn> segfaultfizzbuzz: That's not "the runtime", GHC just generates code for "what happens when this is evaluated"
2023-02-21 15:37:01 +0100 <mauke> a non-strict language enters f first
2023-02-21 15:37:10 +0100 <merijn> segfaultfizzbuzz: The runtime does not control evaluation
2023-02-21 15:37:20 +0100 <merijn> The code does
2023-02-21 15:37:22 +0100 <segfaultfizzbuzz> oh,... but IO...?
2023-02-21 15:37:35 +0100 <mauke> and as far as I know, "laziness" refers to not evaluating sqrt 5 twice
2023-02-21 15:37:37 +0100 <merijn> segfaultfizzbuzz: the "the runtime does IO" story is a lie
2023-02-21 15:37:48 +0100 <merijn> segfaultfizzbuzz: A useful lie, that helps people get started
2023-02-21 15:37:52 +0100 <segfaultfizzbuzz> merijn: hmmmm?
2023-02-21 15:37:59 +0100 <merijn> but a lie not remotely resembling reality nonetheless
2023-02-21 15:38:54 +0100_xor(~xor@72.49.195.228) (Ping timeout: 255 seconds)
2023-02-21 15:38:57 +0100 <merijn> segfaultfizzbuzz: The "IO execution" and "Haskell evaluation" code that we often tell beginners are "completely" separate are completely intertwined and mixed together during code generation
2023-02-21 15:39:03 +0100Vajb(~Vajb@2001:999:484:9db9:7ff5:c370:5511:7e1c) (Ping timeout: 246 seconds)
2023-02-21 15:39:24 +0100rlj(~rlj@c-5eea7342-74736162.cust.telenor.se) (Quit: Client closed)
2023-02-21 15:39:53 +0100 <merijn> They are *conceptually* separate. And the compiler is tasked with maintaining that conceptual separation, we should not be able to observe that in the actual machine code it's not there
2023-02-21 15:40:01 +0100 <mauke> well, the "runtime" in that sense is just some instructions baked into the compiled code
2023-02-21 15:40:03 +0100master_(~master@user/masterbuilder)
2023-02-21 15:40:08 +0100master_(~master@user/masterbuilder) (Client Quit)
2023-02-21 15:40:21 +0100 <merijn> mauke: Well, that was kinda what I was getting at with my question "what is a runtime"
2023-02-21 15:40:32 +0100 <mauke> right
2023-02-21 15:40:48 +0100 <merijn> A compiler can "simply" emit all the assembly for the runtime directly embedded into the executable. Is that a runtime still? Yes? no?
2023-02-21 15:40:48 +0100 <segfaultfizzbuzz> hmm okay. so only garbage collection comes from the runtime but not the eval
2023-02-21 15:41:02 +0100masterbuilder(~masterbui@user/masterbuilder)
2023-02-21 15:41:05 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2023-02-21 15:41:46 +0100 <merijn> segfaultfizzbuzz: The main reason the runtime is a "separate" library we link into the program is mostly pragmatics: only have to compile it once instead of for every program and the separation makes it easier to maintain/hack on the runtime
2023-02-21 15:42:10 +0100 <merijn> segfaultfizzbuzz: Conceptually you could "just" insert the assembly code for the GC directly into every executable
2023-02-21 15:42:33 +0100 <segfaultfizzbuzz> interesting
2023-02-21 15:42:48 +0100 <mauke> you could argue that the code for stack management in function calls is part of the "C runtime"
2023-02-21 15:42:50 +0100Vajb(~Vajb@2001:999:230:f561:4ee8:ad7f:13ff:9959)
2023-02-21 15:42:56 +0100 <mauke> if you squint hard
2023-02-21 15:43:09 +0100_xor(~xor@72.49.195.228)
2023-02-21 15:43:10 +0100 <mauke> uh, in the context of C, I mean
2023-02-21 15:43:17 +0100 <merijn> segfaultfizzbuzz: If you are curious about getting an idea of how GHC operates at a more fundamental implementation level, I recommend reading the STG paper
2023-02-21 15:43:26 +0100Guest45(~Guest45@global-5-144.n-2.net.cam.ac.uk)
2023-02-21 15:43:35 +0100 <merijn> segfaultfizzbuzz: And ezyang's draft about the RTS
2023-02-21 15:44:12 +0100 <segfaultfizzbuzz> merijn: i had started working with exa on that, i am more like a mathematician and when i hit the assembly code in the STG paper i go blind
2023-02-21 15:44:21 +0100 <merijn> segfaultfizzbuzz: How to compile a lazy functional language to asm: https://www.microsoft.com/en-us/research/wp-content/uploads/1992/04/spineless-tagless-gmachine.pdf
2023-02-21 15:44:54 +0100 <merijn> segfaultfizzbuzz: And the RTS: http://ezyang.com/jfp-ghc-rts-draft.pdf
2023-02-21 15:45:10 +0100 <segfaultfizzbuzz> merijn: so i was trying to understand lazy evalutaion at a more abstract level but i can't understand what the "graph" is in the first place
2023-02-21 15:45:26 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 15:45:31 +0100 <geekosaur> I don't actually recommend the STG paper, it's not about how lazy languages work, it's about how to optimize them
2023-02-21 15:45:46 +0100 <segfaultfizzbuzz> but from what you are saying i would infer that the "graph" is *not* the program state
2023-02-21 15:46:01 +0100 <mauke> consider expressions and how you'd represent them as a tree
2023-02-21 15:46:04 +0100 <merijn> segfaultfizzbuzz: I don't recall much assembly in the STG paper
2023-02-21 15:46:14 +0100 <mauke> like a * (b + c)
2023-02-21 15:46:36 +0100 <merijn> geekosaur: If the context is "how does Haskell evaluation (at an actual implementation level) function" I think it's relevant
2023-02-21 15:46:38 +0100 <Guest45> Hi everyone, trying haskell after a very long time. When I am running stack build, I am getting this error message (I am wondering how to resolve this error message):
2023-02-21 15:46:39 +0100 <Guest45> Could not load module ‘Crypto.Number.Basic’
2023-02-21 15:46:39 +0100 <Guest45> It is a member of the hidden package ‘cryptonite-0.30’.
2023-02-21 15:46:44 +0100 <merijn> geekosaur: Not sure what else you'd recommend?
2023-02-21 15:47:15 +0100 <merijn> Guest45: Sounds like you forgot to list cryptonite as a dependency in your cabal file/whatever the yaml nonsense hpack uses
2023-02-21 15:47:40 +0100 <merijn> Guest45: You cannot access packages not explicitly listed as dependencies
2023-02-21 15:47:52 +0100 <segfaultfizzbuzz> my program is a tree, right? an AST in particular. but somehow this becomes a graph
2023-02-21 15:48:17 +0100 <merijn> segfaultfizzbuzz: It's a graph because we allow recursive references
2023-02-21 15:48:34 +0100 <merijn> segfaultfizzbuzz: "let ones = 1 : ones" is obviously not a tree, that's a cycle right there
2023-02-21 15:48:35 +0100 <segfaultfizzbuzz> so "the graph" *is* the AST?
2023-02-21 15:48:50 +0100 <segfaultfizzbuzz> and it is *not* the program state?
2023-02-21 15:49:00 +0100 <merijn> segfaultfizzbuzz: No, the graph is the expressions referring too other expressions
2023-02-21 15:49:32 +0100 <akadude[m]> mauke: yes, thanks, looks like it
2023-02-21 15:50:05 +0100 <segfaultfizzbuzz> let me fix that: "AST with cycles allowed" is precisely equal to "the graph"?
2023-02-21 15:50:07 +0100 <merijn> i.e. "let ones = 1 : ones in ones" is "ones" which refers to 1 thing, a : constructor, which refers to two things "1" and the "ones" mentioned at the start
2023-02-21 15:50:19 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 15:50:44 +0100 <mauke> segfaultfizzbuzz: it's not exactly the syntax tree
2023-02-21 15:50:45 +0100_xor(~xor@72.49.195.228) (Quit: WeeChat 3.8)
2023-02-21 15:50:45 +0100 <merijn> segfaultfizzbuzz: The AST refers to the abstract structure of the syntax, the graph in the STG refers to the graph of expressions that arise as we evaluate the program described by that AST
2023-02-21 15:51:11 +0100 <segfaultfizzbuzz> merijn: so then the graph *is* the program state
2023-02-21 15:51:30 +0100 <mauke> part of it, yes
2023-02-21 15:51:52 +0100 <segfaultfizzbuzz> if i read a picture of a dog into RAM then the dog picture appears somewhere in the graph
2023-02-21 15:52:29 +0100 <mauke> as long as some value in your program is still referring to the picture, yes
2023-02-21 15:52:51 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 15:52:56 +0100 <mauke> but the program is allowed to forget about things as it proceeds
2023-02-21 15:52:58 +0100ph88(~ph88@ip5b426553.dynamic.kabel-deutschland.de)
2023-02-21 15:53:10 +0100 <mauke> > let x = 42 in "no"
2023-02-21 15:53:15 +0100 <lambdabot> "no"
2023-02-21 15:53:41 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-02-21 15:53:41 +0100wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-02-21 15:53:41 +0100wroathe(~wroathe@user/wroathe)
2023-02-21 15:54:06 +0100 <segfaultfizzbuzz> so the graph *is* the complete program state, including the "binary/asm"
2023-02-21 15:55:21 +0100 <mauke> I don't think about it that way
2023-02-21 15:55:40 +0100 <mauke> for example, a unix process has a "current working directory" that is not stored within the haskell universe, so to speak
2023-02-21 15:55:54 +0100 <segfaultfizzbuzz> well i can't understand the STG without knowing what the G is, exactly
2023-02-21 15:56:33 +0100 <mauke> I'm pretty sure the graph is a runtime representation of expression
2023-02-21 15:56:48 +0100 <mauke> +s
2023-02-21 15:58:02 +0100 <mauke> in a "conventional" language, you may have some code (list of instructions) and an environment that just maps names to values
2023-02-21 15:58:29 +0100 <mauke> but with non-strict semantics, the environment may contain full (unevaluated) expressions
2023-02-21 15:59:43 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-02-21 15:59:48 +0100 <mauke> and expressions can refer to each other and even themselves (or rather, expressions that refer to names can be bound to the same names), and that's how you get loops in the structure
2023-02-21 16:00:04 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 16:00:17 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-02-21 16:00:29 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-02-21 16:00:32 +0100jpds(~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection)
2023-02-21 16:00:46 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-02-21 16:00:56 +0100Luj(~Luj@2a01:e0a:5f9:9681:40ef:5a70:1bf4:6920) (Quit: Ping timeout (120 seconds))
2023-02-21 16:01:15 +0100 <mauke> "forcing" a lazy value means evaluating the subexpression and replacing it by its result in the graph
2023-02-21 16:01:15 +0100Luj(~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb)
2023-02-21 16:01:19 +0100gastus(~gastus@5.83.191.28) (Ping timeout: 252 seconds)
2023-02-21 16:01:19 +0100jpds(~jpds@gateway/tor-sasl/jpds)
2023-02-21 16:01:25 +0100califax(~califax@user/califx)
2023-02-21 16:01:45 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 16:02:16 +0100 <raehik> is there ever any performance to be gained by passing around `Addr#` and `a -> (# State# RealWorld, a #)` instead of `Ptr Word8` and `IO a`
2023-02-21 16:02:30 +0100wroathe(~wroathe@user/wroathe) (Ping timeout: 246 seconds)
2023-02-21 16:02:45 +0100 <geekosaur> merijn, sorry for delay, had some things come up elsewhere. but the STG paper is about how STG, not why STG
2023-02-21 16:02:57 +0100 <raehik> or will GHC almost certainly remove the indirections in the latter
2023-02-21 16:03:00 +0100 <segfaultfizzbuzz> so the graph contains either thunks or values (which are not thunks)
2023-02-21 16:03:14 +0100 <geekosaur> The Wikipedia overview of graph reduction does a somewhat better job of the why, although not to my mind ideal
2023-02-21 16:04:03 +0100 <segfaultfizzbuzz> and then the thunk contains some code, which may point at some other values, or some other thunks, including itself
2023-02-21 16:04:13 +0100 <mauke> segfaultfizzbuzz: you don't need to explicitly distinguish between the two, I think
2023-02-21 16:04:57 +0100 <segfaultfizzbuzz> not distinguishing sounds unsafe
2023-02-21 16:05:40 +0100 <mauke> consider 'x = 4; y = 2 + 2'
2023-02-21 16:05:48 +0100__monty__(~toonn@user/toonn)
2023-02-21 16:06:33 +0100 <mauke> ignoring optimization for a moment, you could represent this as x being bound to "the expression 4" and y to "the expression 2 + 2"
2023-02-21 16:06:51 +0100 <segfaultfizzbuzz> ok...
2023-02-21 16:06:57 +0100 <mauke> the first time the value of y is demanded, it will be reduced to 4
2023-02-21 16:07:05 +0100 <segfaultfizzbuzz> right
2023-02-21 16:07:07 +0100 <mauke> that is, "the expression 4", just like x
2023-02-21 16:07:14 +0100 <segfaultfizzbuzz> yes
2023-02-21 16:07:28 +0100 <mauke> in this model it's all just expressions
2023-02-21 16:08:42 +0100 <segfaultfizzbuzz> so (1) the AST is promoted to a graph (but not *the* graph) by allowing cycles and then
2023-02-21 16:09:21 +0100 <merijn> raehik: In the tight loops parts where that overhead matters I would expect it optimised away
2023-02-21 16:09:52 +0100 <segfaultfizzbuzz> (2) some kind of program initialization creates **the graph** by looking at main or something and reading some initial things into memory
2023-02-21 16:10:26 +0100waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-02-21 16:12:09 +0100oxide(~lambda@user/oxide)
2023-02-21 16:12:47 +0100 <segfaultfizzbuzz> and then (3) something (a thread? possibly several threads?) looks at this graph, but somehow it can jump around however it pleases in this graph and make decisions about which expressions to evaluate (because not being able to jump around would be considered strict eval)
2023-02-21 16:12:58 +0100gastus(~gastus@5.83.191.28)
2023-02-21 16:13:43 +0100 <segfaultfizzbuzz> so haskell is 1 and 2 and 3 and that's it... or i am looking to correct those anyway
2023-02-21 16:14:35 +0100CiaoSen(~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de)
2023-02-21 16:18:18 +0100 <segfaultfizzbuzz> oh right and let me add to 3: the "thing" (thread?) can modify the graph (?) such as reading some values into memory or perhaps replacing aan expression with a value via evaluation
2023-02-21 16:18:33 +0100 <lyxia> the thing can be called a virtual machine
2023-02-21 16:19:04 +0100 <segfaultfizzbuzz> but the thing/vm is stateless...?
2023-02-21 16:19:19 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 16:19:53 +0100 <segfaultfizzbuzz> but i am guessing from the silence that this description is correct?
2023-02-21 16:20:12 +0100 <lyxia> it's stateful, your previous messages are right
2023-02-21 16:20:28 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-02-21 16:20:32 +0100oxide(~lambda@user/oxide) (Ping timeout: 248 seconds)
2023-02-21 16:20:36 +0100Guest45(~Guest45@global-5-144.n-2.net.cam.ac.uk) (Quit: Client closed)
2023-02-21 16:21:13 +0100 <segfaultfizzbuzz> the graph being the program state and the vm being stateful seems like a contradiction, and
2023-02-21 16:21:24 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:6866:bb15:ee8d:e014)
2023-02-21 16:21:32 +0100 <lyxia> except the part about "not jumping around would be considered strict eval"
2023-02-21 16:21:48 +0100 <lyxia> it's just different rules about where to jump when evaluating an expression
2023-02-21 16:21:52 +0100 <segfaultfizzbuzz> how does the vm decide where to jump (especially if that is not decided at runtime, per above discussion)?
2023-02-21 16:22:00 +0100MajorBiscuit(~MajorBisc@c-001-020-009.client.tudelft.eduvpn.nl) (Ping timeout: 255 seconds)
2023-02-21 16:23:31 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 246 seconds)
2023-02-21 16:24:03 +0100MajorBiscuit(~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a)
2023-02-21 16:25:33 +0100 <segfaultfizzbuzz> lyxia: i thought that the key difference between lazy and strict eval was that the vm can go "outside in" on the graph, to "leap wherever it pleases" and not be pinned to reduction of any specific subregion of the graph?
2023-02-21 16:26:24 +0100Charles(~Charles@host-23-251-65-156.VALOLT4.epbfi.com)
2023-02-21 16:26:28 +0100 <kaol> JOSE is... Something. All I have is a Text like "Bearer asdf" where asdf is a JWT and how do I verify it with this. There's verifyJWS' and I already found something for the first argument but is there some Text -> JWS t0 p0 h0 somewhere?
2023-02-21 16:26:35 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-02-21 16:26:41 +0100 <geekosaur> with strict eval any portion of the graph is reduced as soon as it's visited; with non-strict, it's reduced when its value is needed
2023-02-21 16:29:29 +0100 <lyxia> the best way to understand this might be to just read the paper that defines the syntax and the operational semantics
2023-02-21 16:29:37 +0100 <kaol> I guess decodeCompact is it.
2023-02-21 16:29:43 +0100 <segfaultfizzbuzz> geekosaur: if i could understand this distinction i think i would understand a lot more,... so the vm is say, a single thread, and the thread has an idea of "where it currently is"
2023-02-21 16:29:51 +0100 <lyxia> https://www.microsoft.com/en-us/research/wp-content/uploads/1992/04/spineless-tagless-gmachine.pdf sections 4 and 5
2023-02-21 16:30:05 +0100oxide(~lambda@user/oxide)
2023-02-21 16:30:12 +0100 <segfaultfizzbuzz> for strict eval we can immediately know what to do, but for lazy eval we need more state, in particular a way of defining "need"
2023-02-21 16:30:34 +0100cfricke(~cfricke@user/cfricke) (Quit: WeeChat 3.8)
2023-02-21 16:30:51 +0100GuestW48(~GuestW48@46.146.247.46)
2023-02-21 16:32:02 +0100 <lyxia> no in either case we know exactly what to do
2023-02-21 16:32:21 +0100 <segfaultfizzbuzz> "when the value of the thunk is required, the thunk is forced" -- page 11...
2023-02-21 16:32:37 +0100 <int-e> The big differences to strict evaluation are that to do lazy evaluation you need a (heap) representation for unevaluated values, and you must be able to replace such a value by the final value once it has been computed.
2023-02-21 16:32:38 +0100 <lyxia> if you have a function application f x, in a strict language you evaluate x, push its value on the stack, then jump to f
2023-02-21 16:33:00 +0100 <lyxia> in a lazy language you immediately push x on the stack and jump to f
2023-02-21 16:33:35 +0100 <geekosaur> you push the thunk corresponding to x, without evaluating it first
2023-02-21 16:34:06 +0100 <int-e> Where x is an expression? If it were a variable, it would already be evaluated in a strict language.
2023-02-21 16:34:18 +0100 <lyxia> right
2023-02-21 16:34:48 +0100 <geekosaur> evaluation happens when its value is needed, which is often later when output is done that involves the value of x as possibly modified by other expressions it becomes associated with (for exaple, `x + 1` does not force evaluation of x, it just creates a new thunk)
2023-02-21 16:35:18 +0100 <segfaultfizzbuzz> lyxia: lazy evaluation does not jump as it pleases, but rather it is *strictly outermost* whereas strict eval is *strictly innermost*?
2023-02-21 16:39:26 +0100 <lyxia> something like that but I'm not sure those word make sense if you haven't already looked at the formalism
2023-02-21 16:40:29 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-02-21 16:42:11 +0100 <int-e> . o O ( All this jumping around is making me dizzy. )
2023-02-21 16:42:27 +0100 <segfaultfizzbuzz> lyxia: actually i am thinking "strictly outermost eval" and "strictly innermost eval" is very likely to clear up my confusion here
2023-02-21 16:42:44 +0100 <segfaultfizzbuzz> because at the end of the day we are talking about a computer, and *something* must be strict
2023-02-21 16:43:22 +0100 <segfaultfizzbuzz> that is to say *somehow* the computer needs to determine what happens next
2023-02-21 16:43:39 +0100 <segfaultfizzbuzz> so therefore "lazy" and "nonstrict" are incredibly misleading terms
2023-02-21 16:44:40 +0100 <segfaultfizzbuzz> because i was thinking that the vm (threads?) would be able to leap around the graph however it pleases, potentially based on complicated heuristics
2023-02-21 16:45:01 +0100 <int-e> You say "jumping around", I see "jmp *%rbx".
2023-02-21 16:45:40 +0100 <segfaultfizzbuzz> int-e: i would guess the difference here is that leaping (jumping around) would not carry the stack/cache?
2023-02-21 16:45:52 +0100 <segfaultfizzbuzz> we will call it "leaping"
2023-02-21 16:46:14 +0100 <int-e> no, there's still a stack
2023-02-21 16:46:15 +0100 <segfaultfizzbuzz> and so the conclusion here is that lazy or nonstrict evaluation does not leap?
2023-02-21 16:46:36 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-02-21 16:47:07 +0100 <segfaultfizzbuzz> like, get a big sheet of paper, draw your initial program graph on it with pencil
2023-02-21 16:47:13 +0100 <int-e> There are several levels of abstraction here and I have no clue which level we're at... I suspect we're merrily jumping around across all of them.
2023-02-21 16:47:36 +0100 <segfaultfizzbuzz> hahaha i am trying to think about a sheet of paper and pencil if that is at all useful?
2023-02-21 16:47:47 +0100 <segfaultfizzbuzz> imagine instructing a 5th grader in how to do this
2023-02-21 16:48:30 +0100 <segfaultfizzbuzz> by hand
2023-02-21 16:48:32 +0100 <int-e> I'd do the expression level outermost reduction, probably. Fully symbolic, no sign of jumps, not even graphs.
2023-02-21 16:48:43 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 16:48:50 +0100 <int-e> Or, if I really want graphs, graphs encoded with `let`.
2023-02-21 16:49:17 +0100mmhat(~mmh@p200300f1c71c1721ee086bfffe095315.dip0.t-ipconnect.de)
2023-02-21 16:49:17 +0100mmhat(~mmh@p200300f1c71c1721ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2023-02-21 16:49:25 +0100 <segfaultfizzbuzz> right but the point, again, is that it is outermost
2023-02-21 16:49:57 +0100Sgeo(~Sgeo@user/sgeo)
2023-02-21 16:50:35 +0100 <int-e> (having `let` makes finding the "outermost" redex harder)
2023-02-21 16:51:02 +0100 <mjrosenb> htm, does ghcjs not support -fprof-auto or -fprof-auto-calls? both of them seem to lead to a runtime error
2023-02-21 16:51:10 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 16:51:19 +0100 <segfaultfizzbuzz> for example, the graph reduction cannot say: "ah look, lots of network bandwidth is suddenly available, i am going to suspend my fibonacci calculation and leap to the file upload"
2023-02-21 16:51:44 +0100 <int-e> "graph reduction" absolutely can do that
2023-02-21 16:51:56 +0100JimL(~quassel@89-162-26-217.fiber.signal.no)
2023-02-21 16:52:01 +0100 <segfaultfizzbuzz> oh?
2023-02-21 16:52:02 +0100 <int-e> that notion is so abstract that it doesn't come with a predefined reduction strategy.
2023-02-21 16:52:17 +0100 <segfaultfizzbuzz> graph reduction in general can, but outermost evaluation cannot
2023-02-21 16:52:33 +0100 <int-e> (a strategy picks a next redex out of the available redexes)
2023-02-21 16:52:36 +0100 <segfaultfizzbuzz> because the outermost evaluation may have concluded that fibonacci is what it is currently doing
2023-02-21 16:52:54 +0100 <segfaultfizzbuzz> what is a redex? and what is the difference between a redex and a thunk?
2023-02-21 16:53:14 +0100 <merijn> segfaultfizzbuzz: redex = REDucible EXpression
2023-02-21 16:53:17 +0100 <int-e> "file upload" also seems to be way outside the formalism
2023-02-21 16:53:34 +0100 <segfaultfizzbuzz> ok so a redex is something which has not been reduced to a value (so, not a 32 bit integer)
2023-02-21 16:53:36 +0100 <int-e> though I'm sure there are ways to squeeze it in
2023-02-21 16:54:03 +0100ddellacosta(~ddellacos@146.70.166.221) (Ping timeout: 255 seconds)
2023-02-21 16:54:20 +0100 <segfaultfizzbuzz> int-e: well, fine, "the GPU is now at 0% utilization, i am going to switch to this matrix multiplication task rather than my CPU integer fibonacci task"
2023-02-21 16:54:22 +0100 <int-e> sorry for expanding the vocabulary
2023-02-21 16:54:24 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 16:54:32 +0100 <segfaultfizzbuzz> int-e: no problem
2023-02-21 16:54:37 +0100 <lyxia> If I were to teach a 5th grader operational semantics I would give them lots of examples to work through. I think that would work better than throw around buzzwords that are bound to be misinterpreted.
2023-02-21 16:55:08 +0100 <segfaultfizzbuzz> "graph reduction in general can, but outermost evaluation cannot" -- is this true?
2023-02-21 16:55:22 +0100polyphem_(~rod@2a02:810d:840:8754:56e9:3db:815e:932d) (Ping timeout: 246 seconds)
2023-02-21 16:56:23 +0100polyphem_(~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17)
2023-02-21 16:57:17 +0100 <GuestW48> What is the quickest way to check if a package (by name) on stackage (curent project lts), can this be done using some tool from cli?
2023-02-21 16:57:28 +0100acidjnk(~acidjnk@p200300d6e715c43364f4044e674f7620.dip0.t-ipconnect.de)
2023-02-21 16:57:45 +0100 <int-e> Graph reduction has rules for replacing subgraphs (patterns) by different subgraphs, and a graph to perform these reductions on. Any pattern match can qualify for reduction, so it can be completely nondeterministic.
2023-02-21 16:59:00 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 16:59:26 +0100 <segfaultfizzbuzz> so there is "graph reduction in general" and then there is haskell, which is nonstrict/lazy. i am guessing here that haskell is a specialization of general graph reduction?
2023-02-21 16:59:51 +0100 <segfaultfizzbuzz> equivalently, haskell is outermost evaluation rather than any graph reduction evaluation?
2023-02-21 17:00:33 +0100 <int-e> It's the outermost strategy that makes this mostly deterministic. (When compiling Haskell code, the evaulation order is *not* fully specified; if you have x + y where x,y :: Int, then the compiler can evaluate x first or y first.)
2023-02-21 17:01:07 +0100 <int-e> "the compiler" -- it happens at runtime but it's the compiler that makes this choice.
2023-02-21 17:02:15 +0100 <segfaultfizzbuzz> so you are confirming that haskell is a restrictive outermost specialization of general graph reduction?
2023-02-21 17:02:31 +0100 <int-e> yes
2023-02-21 17:02:37 +0100 <segfaultfizzbuzz> ah!!!
2023-02-21 17:03:04 +0100 <segfaultfizzbuzz> thank you that brings great relief
2023-02-21 17:03:29 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-02-21 17:03:42 +0100 <segfaultfizzbuzz> and i am guessing as a really bad programmer that this specialization is motivated by the need to have some kind of local state, such as in a vm thread of execution or similar?
2023-02-21 17:03:57 +0100 <segfaultfizzbuzz> for practical performance reasons or other heuristics
2023-02-21 17:05:56 +0100 <lyxia> GuestW48: stack install my-package? It's odd that there isn't an eqivalent to cabal info
2023-02-21 17:07:26 +0100 <int-e> segfaultfizzbuzz: I'd say the practical motivation is to avoid computing values that aren't used. This has theoretical backing (left-most outermost reduction is *normalizing* (yay, more vocabulary) in the lambda calculus)
2023-02-21 17:08:15 +0100 <int-e> segfaultfizzbuzz: low-level concerns only enter the picture when you flesh out the details of how graph reduction is actually implemented, as the STG paper does.
2023-02-21 17:09:37 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-02-21 17:09:38 +0100albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-02-21 17:09:43 +0100 <segfaultfizzbuzz> if what i am hearing is correct then i would formally recommend that haskell folks call their language outermost rather than lazy
2023-02-21 17:09:54 +0100 <segfaultfizzbuzz> (or nonstrict)
2023-02-21 17:09:55 +0100 <GuestW48> lyxia: I've read that `stack install package` is not what it seems to be
2023-02-21 17:10:08 +0100jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2023-02-21 17:10:26 +0100jinsun(~jinsun@user/jinsun)
2023-02-21 17:11:27 +0100 <int-e> segfaultfizzbuzz: Funny. I'm pretty sure the report actually says "non-strict".
2023-02-21 17:12:11 +0100 <segfaultfizzbuzz> yes i added that correction
2023-02-21 17:12:16 +0100 <int-e> segfaultfizzbuzz: Anyway, "lazy" is stronger than "outermost". It also implies that values are shared, so that evaluating them once benefits all uses of the value.
2023-02-21 17:13:11 +0100 <segfaultfizzbuzz> shared across threads? there seems to be a reluctance to say thread...
2023-02-21 17:13:39 +0100 <lyxia> GuestW48: I mean whatever it is, if it's not in your snapshot it's going to fail so you can use that to tell whether a package is in your snapshot
2023-02-21 17:14:59 +0100 <int-e> I guess the sharing is already implied when you do graph reduction (because it's a graph rather than a tree *because of* sharing)
2023-02-21 17:15:41 +0100 <segfaultfizzbuzz> well i mean when i am looking at my big piece of paper, my friends might come and go and help me reduce my graph
2023-02-21 17:15:42 +0100 <int-e> > let x = [1..1000000] in x + x -- only evaluates x once, not twice; the two uses of `x` *share* the value.
2023-02-21 17:15:44 +0100 <lambdabot> error:
2023-02-21 17:15:44 +0100 <lambdabot> • No instance for (Num [Integer])
2023-02-21 17:15:44 +0100 <lambdabot> arising from a use of ‘e_111000000’
2023-02-21 17:15:49 +0100 <int-e> oops
2023-02-21 17:15:58 +0100 <int-e> > let x = sum [1..1000000] in x + x
2023-02-21 17:16:00 +0100 <lambdabot> 1000001000000
2023-02-21 17:16:12 +0100 <segfaultfizzbuzz> ok but you can share due to something about how threads work
2023-02-21 17:16:22 +0100 <int-e> it has nothing to do with threads
2023-02-21 17:16:23 +0100 <segfaultfizzbuzz> this would be impractical if you had to go all the way to RAM
2023-02-21 17:17:06 +0100 <geekosaur> how does someone get this confused?
2023-02-21 17:17:50 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 17:18:01 +0100 <lyxia> by trying to guess what's in the paper withour reading it
2023-02-21 17:18:13 +0100 <int-e> threads are a complication that interferes with graph reduction (yes, sharing works across threads and one thread will benefit when another thread evaluates a value that the first thread needs).
2023-02-21 17:18:36 +0100 <segfaultfizzbuzz> i am looking at the paper, as i have made several attempts with STG papers, and it contains so much jargon that i can't understand
2023-02-21 17:19:20 +0100 <int-e> I wouldn't worry about threads or IO or any of that when learning about lazy evaluation.
2023-02-21 17:20:06 +0100foul_owl(~kerry@157.97.134.63) (Read error: Connection reset by peer)
2023-02-21 17:20:42 +0100 <segfaultfizzbuzz> int-e: so if i did not have outermost evaluation then i may sometimes evaluate x twice is the point?
2023-02-21 17:21:14 +0100 <int-e> this is more about graph reduction than about strategy.
2023-02-21 17:21:51 +0100 <segfaultfizzbuzz> is there a language which is built on "general graph reduction" rather than a specialization to strict/nonstrict/lazy eval?
2023-02-21 17:21:57 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 252 seconds)
2023-02-21 17:22:22 +0100 <int-e> geekosaur: It may be jumping too many steps of a staircase at once, resulting in a tumble.
2023-02-21 17:22:41 +0100 <geekosaur> segfaultfizzbuzz, the point here is that when parts of a program hold a "value", they hold a thunk. that thunk can be updated by one of the holders, and the other holders will hold the updated thunk. (here a "thunk" is basically a pointer)
2023-02-21 17:23:13 +0100 <int-e> And of course, we're constantly mixing levels of abstraction.
2023-02-21 17:23:15 +0100 <geekosaur> so once the subgraph has been evaluated, all other references to it have the evaluated value instead of having to re-evaluate the subgraph
2023-02-21 17:23:30 +0100 <segfaultfizzbuzz> int-e: for the most part i am trying to focus on the highest level of abstraction
2023-02-21 17:23:37 +0100 <geekosaur> this is why we use a reducible tree
2023-02-21 17:23:40 +0100 <segfaultfizzbuzz> int-e: again, paper and pencil on a big sheet of paper
2023-02-21 17:24:17 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-02-21 17:25:05 +0100 <geekosaur> and to answer your question about general graph reduction, I think lisp/scheme count there?
2023-02-21 17:26:52 +0100ubert(~Thunderbi@p200300ecdf130131a36700041663782c.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2023-02-21 17:26:52 +0100ubert1ubert
2023-02-21 17:27:07 +0100 <segfaultfizzbuzz> oh really? i thought they were strict...
2023-02-21 17:27:13 +0100 <int-e> For pen&paper I'd start with things like let x = sum [1..2] in x + x --> ... --> let x = 3 in x + x --> 3 + 3 --> 6
2023-02-21 17:29:09 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds)
2023-02-21 17:29:16 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 17:29:24 +0100 <GuestW48> lyxia: and what `stack install package` is going to do else?
2023-02-21 17:33:30 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 246 seconds)
2023-02-21 17:34:35 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-02-21 17:35:44 +0100 <geekosaur> segfaultfizzbuzz, they're strict unless you introduce laziness with a lambda. but they're also raw ASTs and therefore trees (unloess you use something like MacLisp (nconc) to introduce a loop). but they still make more sense when treated as trees
2023-02-21 17:37:19 +0100cheater_(~Username@user/cheater)
2023-02-21 17:38:05 +0100 <int-e> They have a runtime system that provides garbage collection; strictness doesn't save you from needing that.
2023-02-21 17:39:43 +0100foul_owl(~kerry@157.97.134.62)
2023-02-21 17:39:59 +0100cheater(~Username@user/cheater) (Ping timeout: 248 seconds)
2023-02-21 17:40:03 +0100cheater_cheater
2023-02-21 17:41:37 +0100 <segfaultfizzbuzz> so then the answer i suppose is that there is not a language (not not a well-known one, anyway) which is based on general graph reduction
2023-02-21 17:43:10 +0100 <geekosaur> general graph reduction is a hard problem, iirc
2023-02-21 17:43:30 +0100ddellacosta(~ddellacos@143.244.47.71)
2023-02-21 17:43:48 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 17:48:30 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 17:48:30 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 255 seconds)
2023-02-21 17:49:01 +0100 <int-e> "based on"... Haskell comes pretty close anyway. Note that the compiler, as part of optimizing code, routinely does reductions that are not outermost at all.
2023-02-21 17:49:46 +0100 <int-e> (keyword "partial evaluation"?)
2023-02-21 17:51:16 +0100 <c_wraith> Haskell is supposed to guarantee termination if there is a terminating evaluation order. That's about as strong a statement as is made
2023-02-21 17:51:55 +0100 <int-e> I'd also ask why you'd want to implement arbitrary graph reduction in the first place, in the context of programming. Though there are some fun variants (like interaction nets with their alluring promise of great parallelism that's, so far, all eaten up by bookkeeping overhead when you actually implement them)
2023-02-21 17:52:18 +0100 <c_wraith> someone who used to be a regular here has a language/vm based on optimal reduction
2023-02-21 17:52:32 +0100 <c_wraith> they've posted about it in the /r/haskell subreddit a few times.
2023-02-21 17:53:40 +0100 <c_wraith> https://github.com/VictorTaelin/Formality
2023-02-21 17:54:01 +0100 <c_wraith> IIRC. maybe I'm mixing stuff up
2023-02-21 17:54:38 +0100ubert(~Thunderbi@2a02:8109:abc0:6434:2da3:d0c8:ac16:be0) (Remote host closed the connection)
2023-02-21 17:54:57 +0100 <int-e> the keyword does turn up at least
2023-02-21 17:55:42 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 17:58:09 +0100 <int-e> c_wraith: there's also https://github.com/HigherOrderCO/HVM in that niche
2023-02-21 17:58:28 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-02-21 18:01:46 +0100werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Client Quit)
2023-02-21 18:01:52 +0100cheater(~Username@user/cheater) (Read error: Connection timed out)
2023-02-21 18:01:59 +0100polyphem(~polyphem@2a02:810d:840:8754:4d31:9178:35f:6608) (Ping timeout: 264 seconds)
2023-02-21 18:02:09 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
2023-02-21 18:03:20 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 18:03:21 +0100cheater(~Username@user/cheater)
2023-02-21 18:03:22 +0100ddellacosta(~ddellacos@143.244.47.71) (Quit: WeeChat 3.8)
2023-02-21 18:05:34 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 18:05:35 +0100oxide(~lambda@user/oxide) (Ping timeout: 252 seconds)
2023-02-21 18:05:59 +0100polyphem_(~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) (Ping timeout: 260 seconds)
2023-02-21 18:07:47 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 252 seconds)
2023-02-21 18:08:24 +0100ddellacosta(~ddellacos@146.70.165.157)
2023-02-21 18:12:11 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 252 seconds)
2023-02-21 18:15:08 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 18:17:18 +0100 <int-e> c_wraith: oh and by the same person/people (not sure how many there are)
2023-02-21 18:19:43 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 246 seconds)
2023-02-21 18:20:35 +0100polyphem_(~rod@2a02:810d:840:8754:b293:2a07:4a12:170f)
2023-02-21 18:20:50 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 18:22:01 +0100zeenk(~zeenk@2a02:2f04:a214:1e00::7fe) (Quit: Konversation terminated!)
2023-02-21 18:22:38 +0100 <segfaultfizzbuzz> " HVM shares the same initial core as Rust (an affine λ-calculus), has great memory management (no thunks, no garbage-collection). Some people think interaction nets are an overhead, but that's not the case - they're the lack of overhead. " fun quote
2023-02-21 18:22:59 +0100 <segfaultfizzbuzz> "For example, a lambda on HVM uses only 2 64-bit pointers, which is about as lightweight as it gets. "
2023-02-21 18:24:07 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 18:24:52 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 18:25:12 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Quit: No Ping reply in 180 seconds.)
2023-02-21 18:26:11 +0100shapr(~user@net-5-88-239-92.cust.vodafonedsl.it) (Ping timeout: 255 seconds)
2023-02-21 18:26:29 +0100sammelweis(~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10)
2023-02-21 18:27:48 +0100Vq(~vq@90-227-195-41-no77.tbcn.telia.com) (Quit: Server maintenance)
2023-02-21 18:28:02 +0100enoq(~enoq@194-208-133-121.lampert.tv) (Quit: enoq)
2023-02-21 18:29:46 +0100 <segfaultfizzbuzz> "Interaction nets are essentially deterministic and cannot model non-deterministic computations directly." - very interesting
2023-02-21 18:31:13 +0100Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-02-21 18:31:56 +0100Vq(~vq@90-227-195-41-no77.tbcn.telia.com)
2023-02-21 18:32:23 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds)
2023-02-21 18:33:21 +0100 <segfaultfizzbuzz> "non-linearity of the STG model" - interesting
2023-02-21 18:34:03 +0100Lord_of_Life_Lord_of_Life
2023-02-21 18:34:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Remote host closed the connection)
2023-02-21 18:35:45 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 18:36:25 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 18:39:21 +0100Atrx(~Atrx@2401:4900:1cb9:134a:e0f0:9862:78c9:557e)
2023-02-21 18:39:34 +0100Atrx(~Atrx@2401:4900:1cb9:134a:e0f0:9862:78c9:557e) (Client Quit)
2023-02-21 18:39:35 +0100gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 3.8)
2023-02-21 18:40:47 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 248 seconds)
2023-02-21 18:42:37 +0100random-jellyfish(~random-je@user/random-jellyfish) (Quit: Client closed)
2023-02-21 18:42:54 +0100MajorBiscuit(~MajorBisc@2001:1c00:2408:a400:67e:5371:52a7:9b9a) (Quit: WeeChat 3.6)
2023-02-21 18:43:06 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 18:43:22 +0100cheater_(~Username@user/cheater)
2023-02-21 18:43:40 +0100ec_(~ec@gateway/tor-sasl/ec)
2023-02-21 18:45:11 +0100ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 255 seconds)
2023-02-21 18:45:32 +0100cheater(~Username@user/cheater) (Ping timeout: 252 seconds)
2023-02-21 18:46:15 +0100cheater__(~Username@user/cheater)
2023-02-21 18:46:15 +0100cheater__cheater
2023-02-21 18:46:18 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 18:48:46 +0100werneta(~werneta@137.79.195.231)
2023-02-21 18:48:48 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 255 seconds)
2023-02-21 18:49:42 +0100cheater_(~Username@user/cheater) (Ping timeout: 255 seconds)
2023-02-21 18:51:33 +0100GuestW48(~GuestW48@46.146.247.46) (Quit: Client closed)
2023-02-21 18:54:09 +0100 <segfaultfizzbuzz> as to why i am trying to chase general graph reduction, i think that i am interested in what would constitute a formal program specification language rather than implementation,... whenever i chase programming, all the materials i come across assume i care about implementation
2023-02-21 18:54:16 +0100 <segfaultfizzbuzz> either in part or in entirety
2023-02-21 18:54:20 +0100Square(~Square4@user/square) (Ping timeout: 252 seconds)
2023-02-21 18:58:42 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 19:00:19 +0100acarrico(~acarrico@dhcp-68-142-49-163.greenmountainaccess.net) (Quit: Leaving.)
2023-02-21 19:01:22 +0100acarrico(~acarrico@dhcp-68-142-49-163.greenmountainaccess.net)
2023-02-21 19:02:04 +0100teo(~teo@user/teo) (Ping timeout: 246 seconds)
2023-02-21 19:05:03 +0100wootehfoot(~wootehfoo@user/wootehfoot)
2023-02-21 19:12:12 +0100ubert(~Thunderbi@84.140.138.216)
2023-02-21 19:13:16 +0100coot(~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot)
2023-02-21 19:17:40 +0100oxide(~lambda@user/oxide)
2023-02-21 19:19:00 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 19:20:45 +0100nschoe(~q@141.101.51.197) (Ping timeout: 255 seconds)
2023-02-21 19:23:41 +0100 <sclv> formal specification that's not interested in implementation is _not_ given in terms of graph reduction.
2023-02-21 19:23:43 +0100dsrt^(~dsrt@c-24-30-76-89.hsd1.ga.comcast.net)
2023-02-21 19:24:04 +0100 <sclv> its just the semantics of the typed lambda calculus under non-strict evaluation order
2023-02-21 19:24:14 +0100 <sclv> graph reduction is just one way to model/implement that
2023-02-21 19:24:59 +0100 <sclv> if you're looking at graph reduction you're necessarily looking at implementation
2023-02-21 19:30:51 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Remote host closed the connection)
2023-02-21 19:31:31 +0100freeside(~mengwong@103.252.202.170)
2023-02-21 19:33:30 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 260 seconds)
2023-02-21 19:35:12 +0100CiaoSen(~Jura@p200300c9570460002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2023-02-21 19:36:30 +0100freeside(~mengwong@103.252.202.170) (Ping timeout: 268 seconds)
2023-02-21 19:37:08 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-02-21 19:39:09 +0100econo(uid147250@user/econo)
2023-02-21 19:40:09 +0100sidy(~sidy@user/sidy)
2023-02-21 19:41:46 +0100Charles(~Charles@host-23-251-65-156.VALOLT4.epbfi.com) (Quit: Client closed)
2023-02-21 19:43:11 +0100slack1256(~slack1256@186.11.53.84)
2023-02-21 19:43:43 +0100gastus(~gastus@5.83.191.28) (Ping timeout: 248 seconds)
2023-02-21 19:44:22 +0100gastus(~gastus@5.83.191.28)
2023-02-21 19:47:33 +0100brettgilio(~brettgili@x-irc.gq) (Read error: Connection reset by peer)
2023-02-21 19:49:48 +0100use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Quit: use-value)
2023-02-21 19:50:59 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-02-21 19:51:12 +0100elevenkb(~elevenkb@105.225.107.83)
2023-02-21 19:53:19 +0100vgtw(~vgtw@user/vgtw) (Ping timeout: 248 seconds)
2023-02-21 19:53:28 +0100vgtw_(~vgtw@user/vgtw)
2023-02-21 19:57:51 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Quit: Leaving)
2023-02-21 19:58:42 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 19:59:43 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 20:00:07 +0100mixfix41(~sdenynine@user/mixfix41)
2023-02-21 20:00:47 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 264 seconds)
2023-02-21 20:03:03 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds)
2023-02-21 20:07:59 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 264 seconds)
2023-02-21 20:10:53 +0100L29Ah(~L29Ah@wikipedia/L29Ah) ()
2023-02-21 20:12:12 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-02-21 20:12:12 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Write error: Connection reset by peer)
2023-02-21 20:12:12 +0100califax(~califax@user/califx) (Write error: Connection reset by peer)
2023-02-21 20:12:12 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Read error: Connection reset by peer)
2023-02-21 20:12:31 +0100Tuplanolla(~Tuplanoll@91-159-68-152.elisa-laajakaista.fi)
2023-02-21 20:12:51 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2023-02-21 20:13:02 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 20:13:02 +0100elevenkb(~elevenkb@105.225.107.83) (Quit: Client closed)
2023-02-21 20:13:16 +0100gmg(~user@user/gehmehgeh)
2023-02-21 20:13:57 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2023-02-21 20:14:39 +0100oxide(~lambda@user/oxide) (Quit: oxide)
2023-02-21 20:14:43 +0100ubert(~Thunderbi@84.140.138.216) (Remote host closed the connection)
2023-02-21 20:15:11 +0100califax(~califax@user/califx)
2023-02-21 20:19:46 +0100polyphem_(~rod@2a02:810d:840:8754:b293:2a07:4a12:170f) (Ping timeout: 246 seconds)
2023-02-21 20:20:49 +0100polyphem_(~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17)
2023-02-21 20:33:45 +0100elevenkb(~elevenkb@105.225.107.83)
2023-02-21 20:38:36 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 20:41:23 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-02-21 20:41:25 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-02-21 20:41:40 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-02-21 20:43:47 +0100cidkid(~cidkid@98.97.12.238)
2023-02-21 20:43:53 +0100cidkid(~cidkid@98.97.12.238) (Client Quit)
2023-02-21 20:45:16 +0100cidkidnix(~cidkidnix@98.97.12.238)
2023-02-21 20:46:46 +0100falafel(~falafel@2607:fb91:143f:e47f:35cb:dbbe:627:16bc)
2023-02-21 20:50:31 +0100ec_(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-02-21 20:52:58 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-02-21 20:53:46 +0100elevenkb(~elevenkb@105.225.107.83) (Quit: Client closed)
2023-02-21 20:56:26 +0100ft(~ft@p3e9bc443.dip0.t-ipconnect.de)
2023-02-21 20:57:21 +0100lyle(~lyle@104.246.145.237) (Quit: WeeChat 3.8)
2023-02-21 20:59:03 +0100elevenkb(~elevenkb@105.225.107.83)
2023-02-21 20:59:15 +0100 <cidkidnix> Hey ya'll is there a way to force getting some package from something like https://ghc.gitlab.haskell.org/head.hackage/, instead of the main hackage repo? Ex if the versions were the same is there a (relatively) nice way to force it to use the one from the external repository?
2023-02-21 21:00:15 +0100 <geekosaur> shouldn't it take it from the first repo listed in the config file that has it?
2023-02-21 21:01:07 +0100 <cidkidnix> Ah I see, it should take the package from the first repo that's listed?
2023-02-21 21:01:34 +0100 <geekosaur> that is certainly what I would expect
2023-02-21 21:01:44 +0100 <geekosaur> so given its nature I'd list head.hackage first
2023-02-21 21:10:20 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:6866:bb15:ee8d:e014) (Ping timeout: 260 seconds)
2023-02-21 21:10:43 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:9c53:942a:1acd:fd47)
2023-02-21 21:13:52 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 21:14:15 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:9c53:942a:1acd:fd47) (Client Quit)
2023-02-21 21:16:19 +0100bjobjo(~bjobjo@user/bjobjo) (Quit: leaving)
2023-02-21 21:16:44 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2023-02-21 21:23:20 +0100bjobjo(~bjobjo@user/bjobjo)
2023-02-21 21:24:53 +0100mechap(~mechap@user/mechap)
2023-02-21 21:25:17 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 255 seconds)
2023-02-21 21:25:24 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53) (Ping timeout: 255 seconds)
2023-02-21 21:25:53 +0100NiceBird(~NiceBird@185.133.111.196)
2023-02-21 21:35:25 +0100justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds)
2023-02-21 21:36:57 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Remote host closed the connection)
2023-02-21 21:37:29 +0100mastarija(~mastarija@188.252.197.148) (Quit: WeeChat 3.7.1)
2023-02-21 21:37:48 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 21:39:28 +0100segfaultfizzbuzz(~segfaultf@108.211.201.53)
2023-02-21 21:46:00 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net) (Ping timeout: 268 seconds)
2023-02-21 21:46:23 +0100cassaundra(~cassaundr@c-73-25-18-25.hsd1.or.comcast.net)
2023-02-21 21:47:17 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 21:47:36 +0100harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2023-02-21 21:48:57 +0100pavonia(~user@user/siracusa)
2023-02-21 21:51:16 +0100elevenkb(~elevenkb@105.225.107.83) (Quit: Client closed)
2023-02-21 21:52:15 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Remote host closed the connection)
2023-02-21 21:54:12 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 21:55:50 +0100falafel(~falafel@2607:fb91:143f:e47f:35cb:dbbe:627:16bc) (Ping timeout: 260 seconds)
2023-02-21 21:56:33 +0100wootehfoot(~wootehfoo@user/wootehfoot)
2023-02-21 21:59:09 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds)
2023-02-21 22:00:34 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 22:01:13 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl)
2023-02-21 22:02:55 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-02-21 22:04:19 +0100 <mauke> what's a good module for basic http requests?
2023-02-21 22:05:39 +0100 <sm> http-conduit ? req ?
2023-02-21 22:05:54 +0100merijn(~merijn@c-001-001-006.client.esciencecenter.eduvpn.nl) (Ping timeout: 255 seconds)
2023-02-21 22:08:08 +0100 <mauke> http-conduit doesn't look great (FUD in the docs)
2023-02-21 22:10:27 +0100 <slack1256> wreq too
2023-02-21 22:12:44 +0100 <mauke> is there anything that doesn't build on http-client?
2023-02-21 22:12:55 +0100dcoutts__(~duncan@host86-153-135-38.range86-153.btcentralplus.com)
2023-02-21 22:13:11 +0100ec(~ec@gateway/tor-sasl/ec)
2023-02-21 22:13:18 +0100cidkidnix(~cidkidnix@98.97.12.238) (Quit: Client closed)
2023-02-21 22:14:53 +0100 <romes[m]> Hi 👋 I’m trying to understand if the code in cabal-install to compute a package’s unit-id (hashedInstalledPackageId in Distribution.Client.PackageHash is too tied in to cabal-install or whether it could be feasibly moved to the Cabal package?
2023-02-21 22:14:53 +0100 <romes[m]> * Hi 👋 I’m trying to understand if the code in cabal-install to compute a package’s unit-id (hashedInstalledPackageId in Distribution.Client.PackageHash) is too tied in to cabal-install or whether it could be feasibly moved to the Cabal package?
2023-02-21 22:14:54 +0100kuribas(~user@ptr-17d51eohw70nwasehcd.18120a2.ip6.access.telenet.be) (Remote host closed the connection)
2023-02-21 22:15:16 +0100 <sclv> why
2023-02-21 22:15:18 +0100 <romes[m]> * Hi 👋 I’m trying to understand if the code in cabal-install to compute a package’s unit-id (hashedInstalledPackageId in Distribution.Client.PackageHash) is too tied in to cabal-install or whether it could be feasibly moved to the Cabal package?
2023-02-21 22:15:30 +0100 <sclv> why
2023-02-21 22:15:35 +0100NiceBird(~NiceBird@185.133.111.196) (Quit: Leaving)
2023-02-21 22:15:35 +0100 <[exa]> romes[m]: posting once is typically enough, peope will just take a moment to answer
2023-02-21 22:15:37 +0100 <geekosaur> please don't do matrix edits, it's just sent yopur message 3 times
2023-02-21 22:16:07 +0100 <romes[m]> Sorry, I forgot this channel was bridged
2023-02-21 22:17:39 +0100 <geekosaur> in any case that question probably belongs in #hackage:libera.chat
2023-02-21 22:18:05 +0100 <romes[m]> sclv: on my current work on plugin abi incompatibility, everything points to a solution that involves having ghc compute its own unit-id exactly as cabal would
2023-02-21 22:19:11 +0100 <[exa]> romes[m]: does the source depend much on the commandline tool facilities?
2023-02-21 22:19:50 +0100elevenkb(~elevenkb@105.225.107.83)
2023-02-21 22:20:45 +0100 <romes[m]> and this path ultimately also enables us to handle wired-in packages without the -this-unit-id package hack
2023-02-21 22:20:50 +0100 <romes[m]> so, right now, seems like the elegant solution
2023-02-21 22:21:14 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2023-02-21 22:22:06 +0100slack1256(~slack1256@186.11.53.84) (Ping timeout: 255 seconds)
2023-02-21 22:22:29 +0100 <romes[m]> [exa]: I’ve read through it but couldn’t reach good conclusions. Hence my reaching out here :)
2023-02-21 22:23:45 +0100 <[exa]> like, I'd ask in #hackage and if no one really objects, just send a PR. :D
2023-02-21 22:24:48 +0100 <romes[m]> I’ll ask there, thank you. I’d be happy to submit a PR, but i’m mostly probing for feasibility, there’s still a lot of code for that bit (particularly the arguments passed to that function)
2023-02-21 22:28:56 +0100ddellacosta(~ddellacos@146.70.165.157) (Quit: WeeChat 3.8)
2023-02-21 22:34:56 +0100gawen_(~gawen@user/gawen)
2023-02-21 22:35:20 +0100gawen(~gawen@user/gawen) (Ping timeout: 268 seconds)
2023-02-21 22:38:47 +0100 <sm> G'day all. A reminder that the first Haskell Tiny Game Jam has one more week to run. We have 41 entries so far, more welcome! https://github.com/haskell-game/tiny-games-hs
2023-02-21 22:42:27 +0100elevenkb(~elevenkb@105.225.107.83) (Quit: Client closed)
2023-02-21 22:46:23 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-02-21 22:47:21 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-02-21 22:47:34 +0100coot(~coot@213.134.171.3)
2023-02-21 22:47:43 +0100 <eldritchcookie[m> i am having a problem with ambiguous types, it probably is something really simple that i am missing.
2023-02-21 22:47:54 +0100 <Rembane> eldritchcookie[m: Do you have an example?
2023-02-21 22:48:03 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-02-21 22:48:51 +0100 <eldritchcookie[m> yeah
2023-02-21 22:49:23 +0100 <eldritchcookie[m> connect::forall f t p es. (SocketE f t p :> es,S.Family f) => SocketAddress f -> Eff es ()
2023-02-21 22:49:23 +0100 <eldritchcookie[m> connect addr = do
2023-02-21 22:49:23 +0100 <eldritchcookie[m> (SocketERep sock ) <- getStaticRep @(SocketE f t p)
2023-02-21 22:49:23 +0100 <eldritchcookie[m> unsafeEff_ $ S.connect sock addr
2023-02-21 22:50:11 +0100 <eldritchcookie[m> this fails with Could not deduce (SocketE f t0 p0 :> es)... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/3c9798409ffcde5941862372182ef92501c3…>)
2023-02-21 22:50:41 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-02-21 22:52:43 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf)
2023-02-21 22:52:55 +0100 <mauke> is ScopedTypeVariables on?
2023-02-21 22:53:01 +0100 <eldritchcookie[m> yes
2023-02-21 22:53:41 +0100 <[Leary]> The issue isn't in `connect`, it's `connect` itself. It takes a `SocketAddress f` and produces an `Eff es ()`, so GHC can know about `f` and `es` from context. It can't infer `t` and `p`, however.
2023-02-21 22:54:00 +0100 <[Leary]> If you want to use it with TypeApplications, enable AllowAmbiguousTypes.
2023-02-21 22:55:58 +0100 <eldritchcookie[m> sorry doesn the getStaticRep @(SocketE f t p) line fix the t and p types?
2023-02-21 22:56:27 +0100 <mauke> no, that's part of the function body, which is irrelevant (according to the ^ explanation)
2023-02-21 22:57:40 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2023-02-21 22:57:47 +0100 <[Leary]> The problem is that you'd have to do `connect @_ @t @p` when you want to use the function. Haskell doesn't have TypeApplications by default, so GHC considers this erroneous.
2023-02-21 22:58:00 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6111:c483:164:5daf) (Ping timeout: 255 seconds)
2023-02-21 22:59:56 +0100 <eldritchcookie[m> ok why is it not complaining about the thing i wrote before ?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/714bdc27262b982b3aad5c39962b0363008f…>)
2023-02-21 23:00:57 +0100 <[Leary]> The type variables all feature in the explicit argument.
2023-02-21 23:01:02 +0100 <mauke> in that one all the type variables actually appear in the type
2023-02-21 23:03:57 +0100 <eldritchcookie[m> ok just tell me if i turn on allow ambiguous types will anyone using specifically runSocket be able to get a compile time error due to ambigous types?
2023-02-21 23:07:08 +0100 <[Leary]> It won't have any effect on `runSocket`, it just lets you write things like `connect`.
2023-02-21 23:08:39 +0100 <eldritchcookie[m> can a user writing something using connect get a type error?
2023-02-21 23:09:32 +0100trev(~trev@user/trev) (Remote host closed the connection)
2023-02-21 23:09:59 +0100 <[Leary]> Any use without the explicit TypeApplications I showed above will be an error.
2023-02-21 23:16:27 +0100jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) ()
2023-02-21 23:17:04 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-02-21 23:21:11 +0100michalz(~michalz@185.246.207.215) (Remote host closed the connection)
2023-02-21 23:25:24 +0100slack1256(~slack1256@186.11.53.84)
2023-02-21 23:30:06 +0100EvanR(~EvanR@user/evanr) (Remote host closed the connection)
2023-02-21 23:31:32 +0100darchitect(~darchitec@2a00:23c6:3584:df01:a0b8:952b:135:dbe4)
2023-02-21 23:33:04 +0100EvanR(~EvanR@user/evanr)
2023-02-21 23:33:40 +0100mcglk_(~mcglk@131.191.19.145)
2023-02-21 23:35:57 +0100mcglk(~mcglk@131.191.49.120) (Ping timeout: 252 seconds)
2023-02-21 23:40:25 +0100 <eldritchcookie[m> ok i know what my mistake was i forgot to turn on the ghc plugin for the effect system so now it works fine, guess i will put a warning to use the plugin
2023-02-21 23:42:25 +0100 <AWizzArd> What extension introduces the curly braces syntax for `forall`? Such as: p :: forall {k} (a :: k). Proxy a
2023-02-21 23:43:59 +0100bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-02-21 23:46:20 +0100kurbus(~kurbus@user/kurbus)
2023-02-21 23:49:21 +0100biberu(~biberu@user/biberu) (Read error: Connection reset by peer)
2023-02-21 23:50:19 +0100 <geekosaur> no extension, unless maybe TypeApplications. but it's only available from 9.0.1 on
2023-02-21 23:50:49 +0100 <AWizzArd> geekosaur: interesting, ic. Do you happen to know where this syntax is documented?
2023-02-21 23:51:07 +0100 <geekosaur> https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/users_guide/exts/type_applications.html#manual…
2023-02-21 23:51:19 +0100 <geekosaur> (9.6.1 only because that's what I have open)
2023-02-21 23:52:00 +0100 <AWizzArd> geekosaur: excellent
2023-02-21 23:52:12 +0100darchitect(~darchitec@2a00:23c6:3584:df01:a0b8:952b:135:dbe4) (Ping timeout: 246 seconds)
2023-02-21 23:52:43 +0100 <AWizzArd> I stumbled upon p :: forall {k} (a :: k). Proxy a vs p :: forall k (a :: k). Proxy a
2023-02-21 23:53:53 +0100biberu(~biberu@user/biberu)
2023-02-21 23:53:59 +0100kurbus(~kurbus@user/kurbus) (Quit: Client closed)
2023-02-21 23:55:02 +0100elevenkb(~elevenkb@105.225.107.83)
2023-02-21 23:57:34 +0100dcoutts__(~duncan@host86-153-135-38.range86-153.btcentralplus.com) (Ping timeout: 252 seconds)