Logs on 2022-08-28 (liberachat/#haskell)

00:00:09	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
00:03:14	→	shapr joins (~user@68.54.166.125)
00:05:06	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 260 seconds)
00:06:08	→	enek joins (~enek@pool-100-11-18-203.phlapa.fios.verizon.net)
00:09:15	→	jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
00:15:45	→	euandreh joins (~euandreh@179.214.113.107)
00:17:14	→	instantaphex joins (~jb@c-73-171-252-84.hsd1.fl.comcast.net)
00:18:20	×	causal quits (~user@50.35.83.177) (Quit: WeeChat 3.6)
00:21:19	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Quit: segfaultfizzbuzz)
00:21:34	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
00:23:12	×	eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
00:23:37	→	azimut joins (~azimut@gateway/tor-sasl/azimut)
00:23:39	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
00:26:56	×	jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
00:28:22	→	matthewmosior joins (~matthewmo@173.170.253.91)
00:29:39	×	ober_ quits (~ober@c-24-61-80-64.hsd1.ma.comcast.net) (Quit: Leaving)
00:29:42	×	bitdex_ quits (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
00:30:47	→	bitdex_ joins (~bitdex@gateway/tor-sasl/bitdex)
00:31:17	×	Midjak quits (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
00:36:24	<segfaultfizzbuzz>	oh lol i found the stack segfault on macos/m1 thing, it's a known issue looks like https://github.com/commercialhaskell/stack/issues/5607
00:37:50	<segfaultfizzbuzz>	oh wow if you use bash like the github issue says it doesn't segfault. how can this be!! lol
00:38:29	×	gurkenglas quits (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
00:51:57	×	enek quits (~enek@pool-100-11-18-203.phlapa.fios.verizon.net) (Quit: Textual IRC Client: www.textualapp.com)
00:52:35	→	eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
00:52:54	<dsal>	Yeah, I've run into that.
00:57:33	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
01:00:35	→	jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
01:03:21	×	eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
01:09:03	→	jmorris joins (uid537181@id-537181.uxbridge.irccloud.com)
01:12:20	×	L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
01:14:58	→	eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
01:26:51	×	jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
01:27:45	→	razetime joins (~quassel@117.254.35.219)
01:28:52	→	nate4 joins (~nate@98.45.169.16)
01:40:32	×	mvk quits (~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 255 seconds)
01:45:58	→	kannon joins (~NK@135-180-47-54.fiber.dynamic.sonic.net)
01:50:41	×	kannon quits (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds)
01:58:16	×	[itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds)
01:58:22	×	matthewmosior quits (~matthewmo@173.170.253.91) (Remote host closed the connection)
01:58:28	→	matthewmosior joins (~matthewmo@173.170.253.91)
02:02:19	→	[itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
02:02:21	×	xff0x quits (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 260 seconds)
02:02:33	×	bitmapper quits (uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity)
02:04:14	→	xff0x joins (~xff0x@2405:6580:b080:900:1b20:aae8:b54a:f45a)
02:10:18	×	beteigeuze quits (~Thunderbi@bl11-28-222.dsl.telepac.pt) (Ping timeout: 268 seconds)
02:12:46	×	td_ quits (~td@94.134.91.193) (Ping timeout: 268 seconds)
02:14:24	→	td_ joins (~td@94.134.91.78)
02:16:15	×	nate4 quits (~nate@98.45.169.16) (Read error: Connection reset by peer)
02:16:31	→	nate4 joins (~nate@98.45.169.16)
02:16:47	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
02:17:41	→	kannon joins (~NK@135-180-47-54.fiber.dynamic.sonic.net)
02:18:51	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
02:25:43	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
02:32:05	→	Furor joins (~colere@about/linux/staff/sauvin)
02:34:32	×	Colere quits (~colere@about/linux/staff/sauvin) (Ping timeout: 255 seconds)
02:35:47	→	ddellacosta joins (~ddellacos@89.46.62.222)
02:36:53	Furor	is now known as Colere
02:45:21	×	bontaq quits (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 252 seconds)
02:53:34	→	dtman34 joins (~dtman34@c-73-62-246-247.hsd1.mn.comcast.net)
02:58:02	×	FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
02:58:02	→	finn_elija joins (~finn_elij@user/finn-elija/x-0085643)
02:58:02	finn_elija	is now known as FinnElija
03:00:02	×	haasn quits (~nand@haasn.dev) (Quit: ZNC 1.7.5+deb4 - https://znc.in)
03:01:22	→	haasn joins (~nand@haasn.dev)
03:02:26	×	dtman34 quits (~dtman34@c-73-62-246-247.hsd1.mn.comcast.net) (Ping timeout: 260 seconds)
03:03:36	×	xff0x quits (~xff0x@2405:6580:b080:900:1b20:aae8:b54a:f45a) (Ping timeout: 260 seconds)
03:05:31	→	xff0x joins (~xff0x@ai071162.d.east.v6connect.net)
03:06:16	×	Me-me quits (~me-me@v.working.name) (Changing host)
03:06:16	→	Me-me joins (~me-me@user/me-me)
03:06:22	→	dtman34 joins (~dtman34@c-73-62-246-247.hsd1.mn.comcast.net)
03:12:39	×	matthewmosior quits (~matthewmo@173.170.253.91) (Remote host closed the connection)
03:13:55	<segfaultfizzbuzz>	dsal: are you still using stack on m1/macos or did you switch to something else?
03:14:35	<dsal>	segfaultfizzbuzz: yeah, I'm using stack with nix integration
03:15:27	×	azimut quits (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
03:15:56	→	azimut joins (~azimut@gateway/tor-sasl/azimut)
03:17:01	×	xff0x quits (~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 260 seconds)
03:20:51	×	kannon quits (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
03:24:41	→	matthewmosior joins (~matthewmo@173.170.253.91)
03:27:56	→	kannon joins (~NK@135-180-47-54.fiber.dynamic.sonic.net)
03:33:01	×	matthewmosior quits (~matthewmo@173.170.253.91) (Remote host closed the connection)
03:37:51	→	matthewmosior joins (~matthewmo@173.170.253.91)
03:45:11	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
03:50:04	×	nate4 quits (~nate@98.45.169.16) (Read error: Connection reset by peer)
03:50:29	→	nate4 joins (~nate@98.45.169.16)
03:51:17	×	vglfr quits (~vglfr@145.224.94.75) (Read error: Connection reset by peer)
03:52:35	→	vglfr joins (~vglfr@145.224.94.75)
03:53:46	×	raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds)
03:57:25	linux	is now known as Linux
03:57:59	→	matthewmosior joins (~matthewmo@173.170.253.91)
04:00:02	→	xff0x joins (~xff0x@ai071162.d.east.v6connect.net)
04:06:30	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
04:08:08	×	ChaiTRex quits (~ChaiTRex@user/chaitrex) (Ping timeout: 268 seconds)
04:09:48	→	ChaiTRex joins (~ChaiTRex@user/chaitrex)
04:12:56	×	vglfr quits (~vglfr@145.224.94.75) (Read error: Connection reset by peer)
04:13:00	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
04:14:15	→	vglfr joins (~vglfr@145.224.94.75)
04:14:26	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
04:20:31	→	radhika joins (uid560836@id-560836.helmsley.irccloud.com)
04:20:53	<radhika>	Hi.. this is a generic question.. I am trying to learn web dev and started with Spock
04:21:04	<radhika>	Kept getting multiple error messages
04:21:36	×	califax quits (~califax@user/califx) (Remote host closed the connection)
04:21:44	<radhika>	Specifically this video
04:21:49	<radhika>	https://youtube.com/watch?v=Orm-jIIgVD0&feature=share
04:21:58	→	califax joins (~califax@user/califx)
04:22:29	<radhika>	I keep getting multiple error messages which when googled says Spock is not compatible with current ghc I have installed
04:23:13	<radhika>	When I try to install ghc 8.2 it gives fdiagnostics colour error
04:23:29	<radhika>	On googling that I saw that that version is not maintained
04:24:18	<radhika>	Is there anyone who is learning Spock or any other simple framework currently?
04:24:55	<radhika>	In general how do u learn it? I have tried multiple tutorials and example.. many of them have non compatibility issue..
04:25:56	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
04:26:20	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
04:26:52	<dmj`>	radhika: IHP seems to have good docs https://ihp.digitallyinduced.com/
04:29:03	×	razetime quits (~quassel@117.254.35.219) (Ping timeout: 268 seconds)
04:32:16	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 260 seconds)
04:32:23	<radhika>	@dmj hi.. So Spock does not work any more??
04:32:23	<lambdabot>	<unknown>.hs:1:3:Parse error: ..
04:32:47	<radhika>	Are there simpler frameworks for beginners??
04:34:24	<radhika>	In general how do u check if ur ghc installation matches or is compatible with different packages or frameworks that u want to learn
04:34:54	<dsal>	You'd normally use your stack or cabal or nix project to manage that.
04:34:55	<glguy>	radhika: the package maintainer is supposed to communicate which versions are supported using version bounds
04:35:00	<dsal>	How did you install ghc?
04:35:09	<glguy>	but some both bother because it can be a lot of work to keep them accurate
04:35:20	<radhika>	Ghcup
04:35:57	<radhika>	That’s the recommended way from Haskell site?
04:36:02	<dsal>	Is there a reason you want 8.2?
04:36:12	<radhika>	No
04:36:26	<radhika>	Spock was giving errors with 8.7
04:36:30	<dsal>	Anyway, if you start a new project with stack or cabal, you can specify your dependencies.
04:36:33	<radhika>	I googled the error
04:36:38	<dsal>	I've never used spock. scotty is pretty easy.
04:37:00	<radhika>	Saw message that ghc 8.2 is last compatible version
04:37:05	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
04:37:08	<dsal>	You've not really described the error in any way I think anyone can guess about, but if you're starting, you might try something more recent in general.
04:37:15	<radhika>	That’s why 8.2
04:37:59	<radhika>	@dsal yes.. hence the question how do you know which frameworks are compatible with a particular ghc version
04:37:59	<lambdabot>	Maybe you meant: keal eval
04:38:22	<glguy>	radhika: @ is for bot commands, you don't need to write it
04:38:35	<radhika>	Ok
04:38:37	<glguy>	Spock builds with ghc 8.10.7 and that's the ghcup recommended version
04:40:39	<dsal>	radhika: That's kind of a difficult way to think about things. Each version of each package will have a list of its dependencies and version bounds for each, which might include base deps and stuff. Something like stackage is easier to manage this graph most of the time. I don't see spock in recent releases at all.
04:41:40	<radhika>	Dsal understood.. that’s why it would help if you could let me know how to go about it.. I spent a lot of time just on this yesterday 😅
04:42:22	<radhika>	Shouldn’t stack new project name resolver-lts version number automatically take care of this issue?
04:42:24	<dsal>	Sure, you're asking about a specific library I don't know. It's probably fine, but I don't know it and I don't see it where I typically get libraries.
04:42:43	<dsal>	It should if that library's in the LTS resolver.
04:43:25	<radhika>	Dsal and that can be verified from stackage right?
04:43:36	<dsal>	e.g., https://www.stackage.org/lts-19.20/hoogle?q=spock
04:43:51	<dsal>	I only see one result. I don't know if it's the one you need or not.
04:44:17	<dsal>	For what it sounds like you're doing, I use this one: https://www.stackage.org/lts-19.20/hoogle?q=scotty
04:44:19	<glguy>	"cabal repl --build-dep Spock -w ghc-8.10.7" was enough to get Spock up and built. if you set ghc-8.10.7 as your default GHC in ghcup (or pick it with -w) you'll be good to go
04:45:37	<dsal>	Not knowing what the error is, it's hard to understand what you're running into. glguy knows what he's talking about more than I do by far. :)
04:45:38	<radhika>	Dsal glguy thanks for the tips.. I will have another go at it. Fact is I have nuked installations number of times just because of tooling.. will re try and see
04:45:43	<radhika>	Thanks again
04:47:55	→	jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
04:48:36	×	shapr quits (~user@68.54.166.125) (Ping timeout: 260 seconds)
04:53:42	×	jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
04:54:20	×	ddellacosta quits (~ddellacos@89.46.62.222) (Ping timeout: 268 seconds)
04:54:51	→	jmd_ joins (~jmdaemon@user/jmdaemon)
04:56:11	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds)
05:01:44	×	jmd_ quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
05:02:27	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
05:03:13	→	bilegeek joins (~bilegeek@2600:1008:b045:672c:5812:f108:9f:4ee1)
05:05:44	×	kannon quits (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
05:07:12	→	L29Ah joins (~L29Ah@wikipedia/L29Ah)
05:07:37	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
05:07:45	→	razetime joins (~quassel@117.254.35.219)
05:08:03	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
05:17:49	×	zebrag quits (~chris@user/zebrag) (Quit: Konversation terminated!)
05:18:29	→	famubu joins (~famubu@14.139.174.50)
05:18:30	×	famubu quits (~famubu@14.139.174.50) (Changing host)
05:18:30	→	famubu joins (~famubu@user/famubu)
05:24:09	×	[itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
05:25:20	×	mrd quits (~mrd@45.61.147.211) (Changing host)
05:25:20	→	mrd joins (~mrd@user/mrd)
05:25:33	←	mrd parts (~mrd@user/mrd) ()
05:26:56	<famubu>	Is it possible to have a type which accepts two arguments? I was trying to have something like ` data Vect (n::Int) a = Cons a (Vect n a)`
05:28:34	<famubu>	Oh, `data Vect n a = Cons a (Vect n a)` runs without error. They explicit type was causing trouble.
05:29:35	→	talismanick joins (~talismani@2601:200:c100:3850::dd64)
05:32:11	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
05:32:21	×	Guest4172 quits (~chenqisu1@183.217.200.212) (Ping timeout: 260 seconds)
05:37:04	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
05:38:20	→	bilegeek_ joins (~bilegeek@219.sub-174-209-41.myvzw.com)
05:39:37	→	mbuf joins (~Shakthi@122.165.55.71)
05:40:50	×	bilegeek quits (~bilegeek@2600:1008:b045:672c:5812:f108:9f:4ee1) (Ping timeout: 255 seconds)
05:41:21	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 252 seconds)
05:51:55	<dsal>	If you mean `n :: Int` you'd just say `Int` and not name it.
05:55:31	→	coot joins (~coot@213.134.176.158)
06:01:37	→	zebrag joins (~chris@user/zebrag)
06:03:36	→	wei2912 joins (~wei2912@138.75.147.149)
06:05:44	×	zebrag quits (~chris@user/zebrag) (Client Quit)
06:16:02	<famubu>	dsal: But what if we wanted to refer to that particular n in the construct? (Is that even possible?)
06:17:00	<fvr>	famubu: you will have this instead `data Vect a = Cons a (Vect Int a)`
06:17:18	<dsal>	You can make n a variable, or you can use Int
06:18:04	<dsal>	There are a few other kind of hacky things you can do, but it's not clear why you'd want that.
06:23:06	→	nate4 joins (~nate@98.45.169.16)
06:30:14	×	tzh quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
06:30:36	×	shriekingnoise quits (~shrieking@186.137.167.202) (Quit: Quit)
06:32:23	×	notzmv quits (~zmv@user/notzmv) (Ping timeout: 268 seconds)
06:32:49	×	hgolden quits (~Howard@cpe-172-251-233-141.socal.res.rr.com) (Quit: Leaving)
06:33:41	→	slaydr joins (~slaydr@173.239.197.75)
06:34:09	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
06:34:31	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 252 seconds)
06:40:23	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
06:40:47	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
06:45:51	×	qrpnxz quits (~qrpnxz@fsf/member/qrpnxz) (Ping timeout: 260 seconds)
06:47:03	→	nattiestnate joins (~nate@202.138.250.6)
06:47:51	→	qrpnxz joins (~qrpnxz@fsf/member/qrpnxz)
06:48:11	×	famubu quits (~famubu@user/famubu) (Ping timeout: 260 seconds)
06:54:36	→	takuan joins (~takuan@178-116-218-225.access.telenet.be)
06:55:41	→	famubu joins (~famubu@14.139.174.50)
06:56:34	→	Guest\|18 joins (~Guest\|18@2-107-248-53-dynamic.dk.customer.tdc.net)
06:57:26	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
06:57:59	→	acidjnk joins (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
06:58:48	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
07:08:15	→	toeffel joins (~toeffel@user/toeffel)
07:09:12	→	gmg joins (~user@user/gehmehgeh)
07:15:25	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
07:17:01	→	axeman joins (~quassel@net-93-65-246-244.cust.vodafonedsl.it)
07:23:11	×	Vajb quits (~Vajb@2001:999:705:3c86:e7ea:442b:1e01:22d8) (Read error: Connection reset by peer)
07:23:47	→	Vajb joins (~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi)
07:26:00	→	gurkenglas joins (~gurkengla@p548ac72e.dip0.t-ipconnect.de)
07:28:15	→	matthewmosior joins (~matthewmo@173.170.253.91)
07:29:42	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
07:30:12	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
07:32:12	×	famubu quits (~famubu@14.139.174.50) (Ping timeout: 268 seconds)
07:33:06	×	Guest\|18 quits (~Guest\|18@2-107-248-53-dynamic.dk.customer.tdc.net) (Ping timeout: 260 seconds)
07:37:45	×	axeman quits (~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 268 seconds)
07:40:20	×	radhika quits (uid560836@id-560836.helmsley.irccloud.com) (Quit: Connection closed for inactivity)
07:48:14	×	machinedgod quits (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 268 seconds)
07:52:21	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:d256:ff55:46cc:bc89)
07:53:31	×	acidjnk quits (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
07:57:35	→	lisbeths joins (uid135845@id-135845.lymington.irccloud.com)
08:00:23	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:d256:ff55:46cc:bc89) (Remote host closed the connection)
08:00:42	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:1194:9d69:3198:4ddf)
08:08:19	→	olle joins (~olle@h-94-254-63-12.NA.cust.bahnhof.se)
08:08:30	→	jmd_ joins (~jmdaemon@user/jmdaemon)
08:09:12	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
08:14:57	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:1194:9d69:3198:4ddf) (Remote host closed the connection)
08:15:15	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:7323:e5c3:cf25:ff32)
08:21:02	×	Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer)
08:21:31	→	elkcl joins (~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru)
08:22:46	×	jmd_ quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
08:23:07	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
08:28:08	→	nilradical joins (~nilradica@user/naso)
08:28:16	→	axeman joins (~quassel@net-93-65-246-244.cust.vodafonedsl.it)
08:32:44	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
08:37:59	→	MoC joins (~moc@user/moc)
08:38:46	×	jmorris quits (uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
08:40:00	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
08:40:38	→	notzmv joins (~zmv@user/notzmv)
08:40:40	×	nilradical quits (~nilradica@user/naso) (Remote host closed the connection)
08:41:52	→	nilradical joins (~nilradica@user/naso)
08:41:59	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
08:42:07	×	nattiestnate quits (~nate@202.138.250.6) (Quit: WeeChat 3.6)
08:42:26	×	eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
08:44:22	→	Guest4172 joins (~chenqisu1@183.217.200.212)
08:44:57	→	matthewmosior joins (~matthewmo@173.170.253.91)
08:45:30	→	kannon joins (~NK@135-180-47-54.fiber.dynamic.sonic.net)
08:45:51	×	nilradical quits (~nilradica@user/naso) (Remote host closed the connection)
08:46:14	→	nilradical joins (~nilradica@user/naso)
08:46:21	×	nilradical quits (~nilradica@user/naso) (Remote host closed the connection)
08:47:14	→	wonko joins (~wjc@2a0e:1c80:2::130)
08:47:34	→	nilradical joins (~nilradica@user/naso)
08:47:49	→	frost joins (~frost@user/frost)
08:47:59	→	nate4 joins (~nate@98.45.169.16)
08:49:30	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:7323:e5c3:cf25:ff32) (Ping timeout: 252 seconds)
08:49:50	×	kannon quits (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds)
08:51:09	→	acidjnk joins (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
08:52:59	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 268 seconds)
08:53:52	←	jakalx parts (~jakalx@base.jakalx.net) ()
08:55:37	→	ten_finger_typis joins (~ten_finge@adsl-84-226-91-51.adslplus.ch)
09:00:53	×	nilradical quits (~nilradica@user/naso) (Remote host closed the connection)
09:01:33	<ten_finger_typis>	Morning. I am trying to understand a bit more about unsafeCoerce. It is safe, if the two types have the same representation, but what about GADTs like lists or Maybe. Is the following safe?
09:01:33	<ten_finger_typis>	f :: [a] -> Int
09:01:34	<ten_finger_typis>	f x = length (unsafeCoerce x :: [()])
09:01:59	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:14aa:bc5f:ec5b:98ab)
09:02:04	→	nilradical joins (~nilradica@user/naso)
09:06:48	×	nilradical quits (~nilradica@user/naso) (Remote host closed the connection)
09:07:03	→	nilradical joins (~nilradica@user/naso)
09:10:21	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds)
09:12:21	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
09:17:23	→	jakalx joins (~jakalx@base.jakalx.net)
09:20:37	→	alternateved joins (~user@staticline-31-183-146-203.toya.net.pl)
09:20:44	×	notzmv quits (~zmv@user/notzmv) (Ping timeout: 268 seconds)
09:20:46	×	toeffel quits (~toeffel@user/toeffel) (Quit: quit)
09:21:19	×	axeman quits (~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 268 seconds)
09:21:21	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
09:23:30	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
09:25:08	×	bilegeek_ quits (~bilegeek@219.sub-174-209-41.myvzw.com) (Quit: Leaving)
09:25:29	×	ChaiTRex quits (~ChaiTRex@user/chaitrex) (Remote host closed the connection)
09:26:13	→	ChaiTRex joins (~ChaiTRex@user/chaitrex)
09:28:06	→	Midjak joins (~Midjak@82.66.147.146)
09:37:10	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:14aa:bc5f:ec5b:98ab) (Ping timeout: 252 seconds)
09:39:35	→	pretty_dumm_guy joins (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
09:40:43	×	ChaiTRex quits (~ChaiTRex@user/chaitrex) (Remote host closed the connection)
09:40:43	→	king_gs joins (~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec)
09:41:07	→	ChaiTRex joins (~ChaiTRex@user/chaitrex)
09:42:55	→	eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
09:47:51	×	eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds)
09:48:52	×	talismanick quits (~talismani@2601:200:c100:3850::dd64) (Ping timeout: 244 seconds)
09:49:38	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:dee3:1ebd:2b27:6d24)
09:51:38	→	mima joins (mmh@gateway/vpn/airvpn/mima)
09:56:12	→	kilolympus joins (~kilolympu@90.203.82.22)
09:57:53	×	Vajb quits (~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) (Read error: Connection reset by peer)
09:58:33	<kilolympus>	Are compiler versions in the Hackage build runner determined based on anything?
09:59:10	<kilolympus>	Our project is trying to build with 9.2.4 here: https://hackage.haskell.org/package/discord-haskell-1.15.1/reports/
09:59:19	<kilolympus>	while it built with 8.10.2 before: https://hackage.haskell.org/package/discord-haskell-1.15.0/reports/
09:59:34	<kilolympus>	The diff between those two versions are almost negligible: https://github.com/discord-haskell/discord-haskell/compare/210e46bef7138540774f24cfc4cbb0b6a20420cb..1d41dc6e73e1d53ec93f1d87d91a16594830c44b
10:00:08	→	Vajb joins (~Vajb@2001:999:705:3c86:e7ea:442b:1e01:22d8)
10:01:28	<kilolympus>	For info, the two versions were published by different people but I don't think the user's own PC environment would have affected this
10:02:56	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:dee3:1ebd:2b27:6d24) (Remote host closed the connection)
10:03:17	→	__monty__ joins (~toonn@user/toonn)
10:03:45	×	nilradical quits (~nilradica@user/naso) ()
10:05:52	→	mastarija joins (~mastarija@2a05:4f46:e03:6000:d36e:4952:1bda:e264)
10:05:56	×	wonko quits (~wjc@2a0e:1c80:2::130) (Ping timeout: 260 seconds)
10:07:13	×	king_gs quits (~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec) (Quit: king_gs)
10:15:59	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds)
10:17:14	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
10:26:46	→	bontaq joins (~user@ool-45779fe5.dyn.optonline.net)
10:30:23	→	gehmehgeh joins (~user@user/gehmehgeh)
10:31:42	×	gmg quits (~user@user/gehmehgeh) (Ping timeout: 268 seconds)
10:31:45	×	stefan-_ quits (~cri@42dots.de) (Ping timeout: 252 seconds)
10:32:06	gehmehgeh	is now known as gmg
10:37:15	×	gmg quits (~user@user/gehmehgeh) (Ping timeout: 268 seconds)
10:40:51	→	tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
10:41:39	×	yaroot quits (~yaroot@p2550227-ipngn11101souka.saitama.ocn.ne.jp) (Ping timeout: 248 seconds)
10:42:06	×	vglfr quits (~vglfr@145.224.94.75) (Ping timeout: 268 seconds)
10:43:27	→	gmg joins (~user@user/gehmehgeh)
10:44:55	→	stefan-_ joins (~cri@42dots.de)
10:46:25	×	gmg quits (~user@user/gehmehgeh) (Remote host closed the connection)
10:46:41	×	wei2912 quits (~wei2912@138.75.147.149) (Quit: Lost terminal)
10:47:04	×	gurkenglas quits (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
10:47:13	→	gmg joins (~user@user/gehmehgeh)
10:47:23	→	titibandit joins (~titibandi@xdsl-87-78-66-58.nc.de)
10:50:27	×	cheater quits (~Username@user/cheater) (Ping timeout: 252 seconds)
10:51:00	→	cheater joins (~Username@user/cheater)
10:58:12	×	ten_finger_typis quits (~ten_finge@adsl-84-226-91-51.adslplus.ch) (Ping timeout: 252 seconds)
11:02:40	→	gurkenglas joins (~gurkengla@p548ac72e.dip0.t-ipconnect.de)
11:19:38	<Franciman>	does anbody use haskell in semantic web applications?
11:20:11	×	econo quits (uid147250@user/econo) (Quit: Connection closed for inactivity)
11:26:00	<darkling>	I found quite a few RDF libraries searching on hackage a while ago. I haven't used Haskell enough to get around to the semweb side of things yet, though.
11:26:17	→	axeman joins (~quassel@net-93-65-246-244.cust.vodafonedsl.it)
11:26:39	<darkling>	With that level of support, I'd be surprised if there weren't people using them somewhere.
11:29:20	→	jmd_ joins (~jmdaemon@user/jmdaemon)
11:29:35	×	mastarija quits (~mastarija@2a05:4f46:e03:6000:d36e:4952:1bda:e264) (Ping timeout: 255 seconds)
11:30:51	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
11:31:43	→	notzmv joins (~zmv@user/notzmv)
11:33:29	×	gmg quits (~user@user/gehmehgeh) (Remote host closed the connection)
11:34:01	×	pretty_dumm_guy quits (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5)
11:34:23	→	pretty_dumm_guy joins (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
11:34:32	→	gmg joins (~user@user/gehmehgeh)
11:38:52	×	jmd_ quits (~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
11:42:11	×	alternateved quits (~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection)
11:43:07	→	random-jellyfish joins (~random-je@user/random-jellyfish)
11:44:38	→	vglfr joins (~vglfr@145.224.94.78)
11:44:57	→	eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
11:46:17	×	qhong quits (~qhong@rescomp-21-400677.stanford.edu) (Read error: Connection reset by peer)
11:47:31	→	qhong joins (~qhong@rescomp-21-400677.stanford.edu)
11:48:03	×	tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
11:49:03	→	mastarija joins (~mastarija@2a05:4f46:e03:6000:4bd1:c2b:75be:ac1b)
11:49:56	×	axeman quits (~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 268 seconds)
11:49:58	×	eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds)
11:50:31	→	zeenk joins (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f)
11:51:21	×	szkl quits (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
11:52:50	×	mastarija quits (~mastarija@2a05:4f46:e03:6000:4bd1:c2b:75be:ac1b) (Client Quit)
11:53:53	×	instantaphex quits (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds)
11:57:21	→	tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
11:58:29	×	mbuf quits (~Shakthi@122.165.55.71) (Remote host closed the connection)
11:59:36	→	mbuf joins (~Shakthi@122.165.55.71)
12:00:26	←	jakalx parts (~jakalx@base.jakalx.net) ()
12:01:10	→	jakalx joins (~jakalx@base.jakalx.net)
12:04:23	×	coot quits (~coot@213.134.176.158) (Quit: coot)
12:04:56	×	acidjnk quits (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
12:08:13	×	titibandit quits (~titibandi@xdsl-87-78-66-58.nc.de) (Remote host closed the connection)
12:12:12	<albet70>	@djinn a->b->a
12:12:12	<lambdabot>	f a _ = a
12:12:48	<albet70>	@hoogle a->b->b
12:12:49	<lambdabot>	Prelude seq :: forall (r :: RuntimeRep) a (b :: TYPE r) . a -> b -> b
12:12:49	<lambdabot>	GHC.Conc par :: a -> b -> b
12:12:49	<lambdabot>	GHC.Conc pseq :: a -> b -> b
12:14:43	→	vspecky joins (~vspecky@223.190.87.252)
12:15:02	×	mbuf quits (~Shakthi@122.165.55.71) (Remote host closed the connection)
12:15:54	→	mbuf joins (~Shakthi@122.165.55.71)
12:26:37	<vspecky>	Hey there, I'm a recently graduated software engineer currently exploring haskell (and purescript) and functional programming in general. Also a newbie to IRC in general. Nice to be here!
12:29:24	×	koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 268 seconds)
12:29:53	→	alternateved joins (~user@staticline-31-183-146-203.toya.net.pl)
12:31:06	→	causal joins (~user@50.35.83.177)
12:31:32	<geekosaur>	o/
12:36:20	→	nate4 joins (~nate@98.45.169.16)
12:37:32	→	Topsi joins (~Topsi@dyndsl-095-033-090-077.ewe-ip-backbone.de)
12:41:46	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 268 seconds)
12:44:28	×	tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
12:45:54	×	lisbeths quits (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
12:46:22	×	kaskal quits (~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in)
12:47:46	×	random-jellyfish quits (~random-je@user/random-jellyfish) (Quit: Client closed)
12:49:59	→	kaskal joins (~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0)
12:51:22	→	lisbeths joins (uid135845@id-135845.lymington.irccloud.com)
12:51:56	×	vspecky quits (~vspecky@223.190.87.252) (Quit: Leaving)
12:53:20	→	Pickchea joins (~private@user/pickchea)
12:55:07	×	Guest4172 quits (~chenqisu1@183.217.200.212) (Ping timeout: 252 seconds)
13:02:42	→	toeffel joins (~toeffel@user/toeffel)
13:05:56	→	axeman joins (~quassel@net-93-65-246-244.cust.vodafonedsl.it)
13:06:39	<Franciman>	ty darkling
13:07:21	×	razetime quits (~quassel@117.254.35.219) (Ping timeout: 260 seconds)
13:08:17	×	L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
13:10:43	×	mima quits (mmh@gateway/vpn/airvpn/mima) (Ping timeout: 268 seconds)
13:16:03	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
13:18:39	→	eikke joins (~NicolasT@user/NicolasT)
13:19:14	→	razetime joins (~quassel@117.254.34.136)
13:27:29	→	acidjnk joins (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
13:34:17	×	Midjak quits (~Midjak@82.66.147.146) (Read error: Connection reset by peer)
13:35:12	→	Midjak joins (~Midjak@82.66.147.146)
13:37:03	×	eikke quits (~NicolasT@user/NicolasT) (Read error: Connection reset by peer)
13:39:26	→	eikke joins (~NicolasT@user/NicolasT)
13:41:54	×	wolfshappen quits (~waff@irc.furworks.de) (Ping timeout: 244 seconds)
13:44:40	×	frost quits (~frost@user/frost) (Ping timeout: 252 seconds)
13:44:54	→	matthewmosior joins (~matthewmo@173.170.253.91)
13:46:20	→	wolfshappen joins (~waff@irc.furworks.de)
13:51:25	×	Pickchea quits (~private@user/pickchea) (Ping timeout: 268 seconds)
14:02:02	→	coot joins (~coot@213.134.176.158)
14:04:18	×	gmg quits (~user@user/gehmehgeh) (Remote host closed the connection)
14:05:14	→	gmg joins (~user@user/gehmehgeh)
14:13:02	×	razetime quits (~quassel@117.254.34.136) (Ping timeout: 268 seconds)
14:13:39	→	razetime joins (~quassel@117.254.34.154)
14:15:08	→	radhika joins (uid560836@id-560836.helmsley.irccloud.com)
14:19:41	×	wolfshappen quits (~waff@irc.furworks.de) (Ping timeout: 260 seconds)
14:24:44	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
14:34:27	→	wolfshappen joins (~waff@irc.furworks.de)
14:41:24	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds)
14:41:51	×	acidjnk quits (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
14:42:09	→	tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
14:44:24	→	acidjnk joins (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
14:48:02	×	coot quits (~coot@213.134.176.158) (Quit: coot)
14:52:16	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:caf3:451b:8c00:3fe3)
14:54:05	×	jespada quits (~jespada@cpc121060-nmal24-2-0-cust249.19-2.cable.virginm.net) (Read error: Connection reset by peer)
14:54:30	→	jespada joins (~jespada@cpc121060-nmal24-2-0-cust249.19-2.cable.virginm.net)
14:54:43	→	Pickchea joins (~private@user/pickchea)
14:59:21	×	razetime quits (~quassel@117.254.34.154) (Ping timeout: 260 seconds)
14:59:24	→	razetime_ joins (~quassel@117.193.4.187)
15:01:41	→	gustik joins (~gustik@2a01:c844:2457:2220:475d:34f:d571:996f)
15:02:25	×	gmg quits (~user@user/gehmehgeh) (Ping timeout: 268 seconds)
15:03:05	×	toeffel quits (~toeffel@user/toeffel) (Ping timeout: 252 seconds)
15:04:08	×	tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
15:04:32	→	L29Ah joins (~L29Ah@wikipedia/L29Ah)
15:04:38	→	gmg joins (~user@user/gehmehgeh)
15:07:55	×	Pickchea quits (~private@user/pickchea) (Ping timeout: 268 seconds)
15:08:36	×	alternateved quits (~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection)
15:10:15	<Linux>	/join #kernel
15:10:20	<Linux>	Eep.
15:10:22	→	alternateved joins (~user@staticline-31-183-146-203.toya.net.pl)
15:11:39	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:caf3:451b:8c00:3fe3) (Remote host closed the connection)
15:11:58	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:5f1e:cc4a:57b6:cd25)
15:12:59	→	coot joins (~coot@213.134.176.158)
15:14:05	×	eikke quits (~NicolasT@user/NicolasT) (Ping timeout: 268 seconds)
15:14:51	×	bgamari quits (~bgamari@64.223.169.142) (Read error: Connection reset by peer)
15:15:01	→	jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
15:16:50	→	biberu\ joins (~biberu@user/biberu)
15:17:21	→	tcard_ joins (~tcard@p945242-ipngn9701hodogaya.kanagawa.ocn.ne.jp)
15:17:42	→	Noinia joins (~Frank@77-162-168-71.fixed.kpn.net)
15:17:52	→	drdo5 joins (~drdo@roach0.drdo.eu)
15:17:56	→	lambdap237 joins (~lambdap@static.167.190.119.168.clients.your-server.de)
15:17:59	→	MironZ2 joins (~MironZ@nat-infra.ehlab.uk)
15:17:59	→	ell9 joins (~ellie@user/ellie)
15:18:05	→	bollu5 joins (~bollu@159.65.151.13)
15:18:09	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:5f1e:cc4a:57b6:cd25) (Remote host closed the connection)
15:18:24	→	Alex_test_ joins (~al_test@178.34.163.186)
15:18:25	→	AlexZenon_2 joins (~alzenon@178.34.163.186)
15:18:26	→	orcus- joins (~orcus@user/brprice)
15:18:28	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:61c0:691c:619d:f0a1)
15:18:39	→	raym_ joins (~raym@user/raym)
15:19:22	→	stilgart joins (~Christoph@chezlefab.net)
15:19:28	→	takuan_dozo joins (~takuan@178-116-218-225.access.telenet.be)
15:19:30	→	mmarusea1ph2 joins (~mihai@198.199.98.239)
15:19:34	→	glider joins (~glider@user/glider)
15:19:46	×	acidjnk quits (~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
15:19:49	→	Furor joins (~colere@about/linux/staff/sauvin)
15:20:03	→	uroboros joins (~ouroboros@user/ouroboros)
15:20:10	→	kaol joins (~kaol@94-237-42-30.nl-ams1.upcloud.host)
15:20:13	→	bgamari joins (~bgamari@64.223.130.166)
15:20:13	×	razetime_ quits (~quassel@117.193.4.187) (Ping timeout: 268 seconds)
15:20:15	→	axeman_ joins (~quassel@net-93-65-246-244.cust.vodafonedsl.it)
15:20:19	→	eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
15:20:25	→	hrberg_ joins (~quassel@171.79-160-161.customer.lyse.net)
15:20:28	→	bontaq` joins (~user@ool-45779fe5.dyn.optonline.net)
15:20:28	→	turlando_ joins (~turlando@user/turlando)
15:20:36	→	aforemny_ joins (~aforemny@static.248.158.34.188.clients.your-server.de)
15:20:41	→	dysfigured joins (dfg@dfg.rocks)
15:20:42	→	Jonno_FT1 joins (~come@api.carswap.me)
15:20:45	→	Unode_ joins (~Unode@194.94.44.220)
15:20:49	→	mjs2600_ joins (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net)
15:20:51	→	gff_ joins (~gff@user/gff)
15:20:53	→	opqdonut_ joins (opqdonut@pseudo.fixme.fi)
15:20:57	→	einfair_ joins (~einfair@broadband-90-154-71-147.ip.moscow.rt.ru)
15:20:58	→	Clint_ joins (~Clint@user/clint)
15:21:02	→	rembo10_ joins (~rembo10@main.remulis.com)
15:21:05	→	goldstein joins (~goldstein@goldstein.rs)
15:21:05	→	perrierj1 joins (~perrier-j@modemcable012.251-130-66.mc.videotron.ca)
15:21:10	→	lbseale_ joins (~quassel@user/ep1ctetus)
15:21:11	→	tompaw_ joins (~tompaw@static-47-206-100-136.tamp.fl.frontiernet.net)
15:21:11	→	aku_ joins (~aku@163.172.137.34)
15:21:13	→	xerox__ joins (~edi@user/edi)
15:21:14	→	jao- joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
15:21:18	→	ezzieygu1wuf joins (~Unknown@user/ezzieyguywuf)
15:21:21	→	oats_ joins (~thomas@user/oats)
15:21:24	→	kraftwerk28_ joins (~kraftwerk@178.62.210.83)
15:21:29	×	orcus quits (~orcus@user/brprice) (Ping timeout: 252 seconds)
15:21:29	×	thaumavorio quits (~thaumavor@thaumavor.io) (Ping timeout: 252 seconds)
15:21:29	×	ouroboros quits (~ouroboros@user/ouroboros) (Ping timeout: 252 seconds)
15:21:29	×	takuan quits (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 252 seconds)
15:21:30	×	perrierjouet quits (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Ping timeout: 252 seconds)
15:21:30	×	Rembane quits (~Rembane@li346-36.members.linode.com) (Ping timeout: 252 seconds)
15:21:30	×	aforemny quits (~aforemny@static.248.158.34.188.clients.your-server.de) (Ping timeout: 252 seconds)
15:21:30	×	Alex_test quits (~al_test@178.34.163.186) (Ping timeout: 252 seconds)
15:21:30	×	AlexZenon quits (~alzenon@178.34.163.186) (Ping timeout: 252 seconds)
15:21:30	×	mmaruseacph2 quits (~mihai@198.199.98.239) (Ping timeout: 252 seconds)
15:21:30	×	aku quits (~aku@163.172.137.34) (Ping timeout: 252 seconds)
15:21:30	×	Unode quits (~Unode@194.94.44.220) (Ping timeout: 252 seconds)
15:21:30	×	stilgart_ quits (~Christoph@chezlefab.net) (Ping timeout: 252 seconds)
15:21:30	×	xerox quits (~edi@user/edi) (Ping timeout: 252 seconds)
15:21:30	×	Henkru quits (henkru@kapsi.fi) (Ping timeout: 252 seconds)
15:21:30	×	jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 252 seconds)
15:21:30	×	mbuf quits (~Shakthi@122.165.55.71) (Ping timeout: 252 seconds)
15:21:30	×	raym quits (~raym@user/raym) (Ping timeout: 252 seconds)
15:21:30	×	hughjfchen quits (~hughjfche@vmi556545.contaboserver.net) (Ping timeout: 252 seconds)
15:21:30	×	ystael quits (~ystael@user/ystael) (Ping timeout: 252 seconds)
15:21:30	×	acarrico quits (~acarrico@dhcp-68-142-48-19.greenmountainaccess.net) (Ping timeout: 252 seconds)
15:21:30	×	malte quits (~malte@mal.tc) (Ping timeout: 252 seconds)
15:21:30	×	ezzieyguywuf quits (~Unknown@user/ezzieyguywuf) (Ping timeout: 252 seconds)
15:21:30	×	adium quits (adium@user/adium) (Ping timeout: 252 seconds)
15:21:30	×	sudden quits (~cat@user/sudden) (Ping timeout: 252 seconds)
15:21:30	×	WzC quits (~Frank@77-162-168-71.fixed.kpn.net) (Ping timeout: 252 seconds)
15:21:30	×	drdo quits (~drdo@roach0.drdo.eu) (Ping timeout: 252 seconds)
15:21:30	×	tompaw quits (~tompaw@static-47-206-100-136.tamp.fl.frontiernet.net) (Ping timeout: 252 seconds)
15:21:30	×	lbseale quits (~quassel@user/ep1ctetus) (Ping timeout: 252 seconds)
15:21:30	×	bcmiller quits (~bm3719@66.42.95.185) (Ping timeout: 252 seconds)
15:21:30	×	kraftwerk28 quits (~kraftwerk@178.62.210.83) (Ping timeout: 252 seconds)
15:21:30	×	dfg quits (~dfg@user/dfg) (Ping timeout: 252 seconds)
15:21:30	×	Hecate quits (~mariposa@user/hecate) (Ping timeout: 252 seconds)
15:21:30	×	Clint quits (~Clint@user/clint) (Ping timeout: 252 seconds)
15:21:30	×	MironZ quits (~MironZ@nat-infra.ehlab.uk) (Ping timeout: 252 seconds)
15:21:30	×	oats quits (~thomas@user/oats) (Ping timeout: 252 seconds)
15:21:30	×	cjay quits (cjay@nerdbox.nerd2nerd.org) (Ping timeout: 252 seconds)
15:21:30	×	bah quits (~bah@l1.tel) (Ping timeout: 252 seconds)
15:21:30	×	turlando quits (~turlando@user/turlando) (Ping timeout: 252 seconds)
15:21:30	×	axeman quits (~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 252 seconds)
15:21:30	×	bontaq quits (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 252 seconds)
15:21:30	×	Colere quits (~colere@about/linux/staff/sauvin) (Ping timeout: 252 seconds)
15:21:30	×	biberu quits (~biberu@user/biberu) (Ping timeout: 252 seconds)
15:21:30	×	tcard quits (~tcard@p945242-ipngn9701hodogaya.kanagawa.ocn.ne.jp) (Ping timeout: 252 seconds)
15:21:30	×	GoldsteinQ quits (~goldstein@goldstein.rs) (Ping timeout: 252 seconds)
15:21:30	×	TheCoffeMaker_ quits (~TheCoffeM@200.126.129.149) (Ping timeout: 252 seconds)
15:21:30	×	kaol_ quits (~kaol@94-237-42-30.nl-ams1.upcloud.host) (Ping timeout: 252 seconds)
15:21:30	×	glider_ quits (~glider@user/glider) (Ping timeout: 252 seconds)
15:21:30	×	Philonous quits (~Philonous@user/philonous) (Ping timeout: 252 seconds)
15:21:30	×	ell quits (~ellie@user/ellie) (Ping timeout: 252 seconds)
15:21:30	×	lambdap23 quits (~lambdap@static.167.190.119.168.clients.your-server.de) (Ping timeout: 252 seconds)
15:21:30	×	rembo10 quits (~rembo10@main.remulis.com) (Ping timeout: 252 seconds)
15:21:30	×	opqdonut quits (opqdonut@pseudo.fixme.fi) (Ping timeout: 252 seconds)
15:21:30	×	gff quits (~gff@75-174-108-23.boid.qwest.net) (Ping timeout: 252 seconds)
15:21:30	×	_xor quits (~xor@74.215.182.83) (Ping timeout: 252 seconds)
15:21:30	×	hrberg quits (~quassel@171.79-160-161.customer.lyse.net) (Ping timeout: 252 seconds)
15:21:30	×	einfair__ quits (~einfair@broadband-90-154-71-147.ip.moscow.rt.ru) (Ping timeout: 252 seconds)
15:21:30	×	xsarnik quits (xsarnik@lounge.fi.muni.cz) (Ping timeout: 252 seconds)
15:21:30	×	tv quits (~tv@user/tv) (Ping timeout: 252 seconds)
15:21:30	×	Jonno_FTW quits (~come@user/jonno-ftw/x-0835346) (Ping timeout: 252 seconds)
15:21:30	×	mjs2600 quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 252 seconds)
15:21:30	×	dumptruckman quits (~dumptruck@23-239-13-163.ip.linodeusercontent.com) (Ping timeout: 252 seconds)
15:21:30	×	bollu quits (~bollu@159.65.151.13) (Ping timeout: 252 seconds)
15:21:30	×	tessier quits (~treed@98.171.210.130) (Ping timeout: 252 seconds)
15:21:30	×	wz1000 quits (~zubin@static.11.113.47.78.clients.your-server.de) (Ping timeout: 252 seconds)
15:21:30	×	hippoid quits (~idris@c-98-220-13-8.hsd1.il.comcast.net) (Ping timeout: 252 seconds)
15:21:30	×	sagax quits (~sagax_nb@user/sagax) (Ping timeout: 252 seconds)
15:21:30	×	leah_ quits (lp0@heathens.club) (Ping timeout: 252 seconds)
15:21:30	×	wagle quits (~wagle@quassel.wagle.io) (Ping timeout: 252 seconds)
15:21:30	→	mbuf joins (~Shakthi@122.165.55.71)
15:21:30	→	dumptruckman joins (~dumptruck@23-239-13-163.ip.linodeusercontent.com)
15:21:30	→	Rembane joins (~Rembane@li346-36.members.linode.com)
15:21:30	→	tessier joins (~treed@98.171.210.130)
15:21:31	uroboros	is now known as ouroboros
15:21:31	Unode_	is now known as Unode
15:21:31	lambdap237	is now known as lambdap23
15:21:34	→	Philonous_ joins (~Philonous@user/philonous)
15:21:34	MironZ2	is now known as MironZ
15:21:34	ell9	is now known as ell
15:21:34	bollu5	is now known as bollu
15:21:40	→	hughjfchen joins (~hughjfche@vmi556545.contaboserver.net)
15:21:45	biberu\	is now known as biberu
15:21:54	→	hippoid joins (~idris@c-98-220-13-8.hsd1.il.comcast.net)
15:21:57	→	sudden joins (~cat@user/sudden)
15:21:57	→	malte joins (~malte@mal.tc)
15:21:59	→	_xor joins (~xor@74.215.182.83)
15:22:02	→	tv joins (~tv@user/tv)
15:22:16	→	thaumavorio joins (~thaumavor@thaumavor.io)
15:22:17	→	leah_ joins (lp0@heathens.club)
15:22:19	→	mima joins (mmh@gateway/vpn/airvpn/mima)
15:22:30	→	xsarnik joins (xsarnik@lounge.fi.muni.cz)
15:22:34	→	wz1000 joins (~zubin@static.11.113.47.78.clients.your-server.de)
15:22:36	→	wagle joins (~wagle@quassel.wagle.io)
15:22:44	→	acarrico joins (~acarrico@dhcp-68-142-48-19.greenmountainaccess.net)
15:23:55	oats_	is now known as oats
15:24:21	→	Henkru joins (henkru@kapsi.fi)
15:24:42	→	TheCoffeMaker joins (~TheCoffeM@user/thecoffemaker)
15:25:39	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:61c0:691c:619d:f0a1) (Remote host closed the connection)
15:25:40	aforemny_	is now known as aforemny
15:25:56	→	bcmiller joins (~bm3719@66.42.95.185)
15:25:58	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:e602:ace1:30ba:5cc)
15:26:14	→	cjay joins (cjay@nerdbox.nerd2nerd.org)
15:26:22	→	Hecate joins (~mariposa@user/hecate)
15:26:22	→	bah joins (~bah@l1.tel)
15:26:24	→	ystael joins (~ystael@user/ystael)
15:27:20	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
15:27:50	→	adium joins (adium@user/adium)
15:28:18	→	razetime joins (~quassel@117.254.35.219)
15:32:27	→	machinedgod joins (~machinedg@d198-53-218-113.abhsia.telus.net)
15:33:28	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:e602:ace1:30ba:5cc) (Remote host closed the connection)
15:33:47	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d)
15:43:57	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d) (Remote host closed the connection)
15:44:18	→	zxx7529 joins (~Thunderbi@user/zxx7529)
15:44:18	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d)
15:44:41	→	toeffel joins (~toeffel@user/toeffel)
15:45:15	→	splitted joins (~root@88.160.31.174)
15:47:13	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d) (Remote host closed the connection)
15:47:55	Clint_	is now known as Clint
16:00:12	×	M3w0[m] quits (~M3w0matri@2001:470:69fc:105::2:55b3) (Quit: You have been kicked for being idle)
16:01:45	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds)
16:04:12	→	nilradical joins (~nilradica@user/naso)
16:04:24	×	perrierj1 quits (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.6)
16:04:46	→	perrierjouet joins (~perrier-j@modemcable012.251-130-66.mc.videotron.ca)
16:05:32	×	splitted quits (~root@88.160.31.174) (Remote host closed the connection)
16:06:26	→	shapr joins (~user@68.54.166.125)
16:07:48	→	tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
16:08:21	×	coot quits (~coot@213.134.176.158) (Quit: coot)
16:08:37	→	raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
16:09:35	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:361c:1634:7cfb:4544)
16:14:49	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:361c:1634:7cfb:4544) (Remote host closed the connection)
16:14:55	→	koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com)
16:15:07	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:bfb4:5236:6588:c29c)
16:21:01	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
16:26:25	←	olle parts (~olle@h-94-254-63-12.NA.cust.bahnhof.se) ()
16:27:52	×	nilradical quits (~nilradica@user/naso) ()
16:34:26	→	matthewmosior joins (~matthewmo@173.170.253.91)
16:34:45	×	alternateved quits (~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection)
16:36:38	→	jmdaemon joins (~jmdaemon@user/jmdaemon)
16:36:49	→	nate4 joins (~nate@98.45.169.16)
16:39:09	×	toeffel quits (~toeffel@user/toeffel) (Ping timeout: 252 seconds)
16:40:50	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
16:41:26	←	jakalx parts (~jakalx@base.jakalx.net) ()
16:43:27	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
16:43:37	→	jmd_ joins (~jmdaemon@user/jmdaemon)
16:44:19	×	jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 248 seconds)
16:44:35	→	waleee joins (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
16:45:39	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:bfb4:5236:6588:c29c) (Remote host closed the connection)
16:45:57	→	yvan-sraka joins (~yvan-srak@2a02:2788:224:71c:906a:4715:8c98:d126)
16:48:31	→	jakalx joins (~jakalx@base.jakalx.net)
16:54:18	→	toeffel joins (~toeffel@user/toeffel)
16:54:51	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds)
16:59:19	→	tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net)
17:04:27	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 252 seconds)
17:06:15	→	econo joins (uid147250@user/econo)
17:09:42	→	dwt_ joins (~dwt_@c-98-198-103-176.hsd1.tx.comcast.net)
17:12:27	×	shapr quits (~user@68.54.166.125) (Ping timeout: 268 seconds)
17:12:28	×	vglfr quits (~vglfr@145.224.94.78) (Read error: Connection reset by peer)
17:13:05	→	vglfr joins (~vglfr@145.224.94.78)
17:15:55	×	geekosaur quits (~geekosaur@xmonad/geekosaur) (Quit: Leaving)
17:16:00	×	tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
17:16:28	×	yvan-sraka quits (~yvan-srak@2a02:2788:224:71c:906a:4715:8c98:d126) (Remote host closed the connection)
17:18:23	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 252 seconds)
17:18:39	→	n8chan joins (~nate@98.45.169.16)
17:19:19	→	nate4 joins (~nate@98.45.169.16)
17:21:05	×	neightchan quits (~nate@98.45.169.16) (Ping timeout: 268 seconds)
17:21:40	→	beteigeuze joins (~Thunderbi@bl11-28-222.dsl.telepac.pt)
17:22:21	×	notzmv quits (~zmv@user/notzmv) (Ping timeout: 268 seconds)
17:25:50	×	mbuf quits (~Shakthi@122.165.55.71) (Quit: Leaving)
17:27:07	→	geekosaur joins (~geekosaur@xmonad/geekosaur)
17:27:53	×	pavonia quits (~user@user/siracusa) (Quit: Bye!)
17:29:09	→	shriekingnoise joins (~shrieking@186.137.167.202)
17:30:32	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
17:30:46	×	jao- quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
17:31:04	×	zeenk quits (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!)
17:31:44	×	shriekingnoise quits (~shrieking@186.137.167.202) (Remote host closed the connection)
17:33:54	→	shriekingnoise joins (~shrieking@186.137.167.202)
17:34:02	×	AlexZenon_2 quits (~alzenon@178.34.163.186) (Ping timeout: 268 seconds)
17:34:02	×	Alex_test_ quits (~al_test@178.34.163.186) (Ping timeout: 268 seconds)
17:35:46	→	jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
17:37:39	×	vglfr quits (~vglfr@145.224.94.78) (Ping timeout: 248 seconds)
17:39:18	×	razetime quits (~quassel@117.254.35.219) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
17:40:14	→	Alex_test joins (~al_test@178.34.163.186)
17:40:19	→	AlexZenon joins (~alzenon@178.34.163.186)
17:41:44	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 255 seconds)
17:43:14	→	nate4 joins (~nate@98.45.169.16)
17:45:21	×	jmd_ quits (~jmdaemon@user/jmdaemon) (Quit: ZNC 1.8.2 - https://znc.in)
17:49:11	→	tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
17:51:27	opqdonut_	is now known as opqdonut
17:52:56	×	Luj quits (~Luj@2a01:e0a:5f9:9681:8b11:280b:5dc6:2dbd) (Quit: The Lounge - https://thelounge.chat)
17:55:01	→	coot joins (~coot@213.134.176.158)
17:55:54	×	lisbeths quits (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
18:00:33	×	nate4 quits (~nate@98.45.169.16) (Ping timeout: 252 seconds)
18:02:39	→	Luj joins (~Luj@2a01:e0a:5f9:9681:193b:902c:4a27:b473)
18:04:54	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
18:10:06	→	eikke joins (~NicolasT@user/NicolasT)
18:10:51	→	rburkholder joins (~blurb@96.45.2.121)
18:11:51	→	nate4 joins (~nate@98.45.169.16)
18:16:05	→	vglfr joins (~vglfr@145.224.94.75)
18:21:27	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
18:21:56	→	notzmv joins (~zmv@user/notzmv)
18:23:11	→	beteigeuze1 joins (~Thunderbi@bl11-28-222.dsl.telepac.pt)
18:24:02	×	beteigeuze quits (~Thunderbi@bl11-28-222.dsl.telepac.pt) (Read error: Connection reset by peer)
18:24:02	beteigeuze1	is now known as beteigeuze
18:26:11	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds)
18:28:19	→	zeenk joins (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f)
18:36:26	→	Lord_of_Life_ joins (~Lord@user/lord-of-life/x-2819915)
18:36:58	×	Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds)
18:39:11	Lord_of_Life_	is now known as Lord_of_Life
18:54:54	×	radhika quits (uid560836@id-560836.helmsley.irccloud.com) (Quit: Connection closed for inactivity)
18:57:56	×	gurkenglas quits (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
18:58:00	→	lortabac joins (~lortabac@2a01:e0a:541:b8f0:3570:6165:e2af:8564)
19:00:01	→	aeka` joins (~aeka@2606:6080:2001:6:e14e:c3f3:8562:6916)
19:00:16	×	aeka quits (~aeka@2606:6080:2001:9:2679:addd:655:8142) (Ping timeout: 260 seconds)
19:00:23	aeka`	is now known as aeka
19:03:41	×	gustik quits (~gustik@2a01:c844:2457:2220:475d:34f:d571:996f) (Quit: Leaving)
19:04:24	×	toeffel quits (~toeffel@user/toeffel) (Quit: quit)
19:05:12	→	mikoto-chan joins (~mikoto-ch@164.5.249.78)
19:09:42	→	gurkenglas joins (~gurkengla@p548ac72e.dip0.t-ipconnect.de)
19:12:36	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
19:13:09	×	zxx7529 quits (~Thunderbi@user/zxx7529) (Ping timeout: 252 seconds)
19:13:27	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
19:13:54	→	wonko joins (~wjc@2a0e:1c80:2::130)
19:14:28	→	kannon joins (~NK@135-180-47-54.fiber.dynamic.sonic.net)
19:14:37	<segfaultfizzbuzz>	what is a "spine-nonstrict data structure" -- someone said that anynoe experienced with haskell knows to avoid these
19:14:50	<segfaultfizzbuzz>	so as to not have space leaks
19:15:11	×	mikoto-chan quits (~mikoto-ch@164.5.249.78) (Ping timeout: 268 seconds)
19:15:49	<c_wraith>	well that's obviously a false assertion
19:15:58	<c_wraith>	as a spine-strict list would cause a lot of space leaks
19:15:59	<segfaultfizzbuzz>	heh ok
19:16:00	<geekosaur>	who is "someone"?
19:16:11	<segfaultfizzbuzz>	some forum post
19:16:17	<segfaultfizzbuzz>	no idea who
19:16:36	<segfaultfizzbuzz>	what does spine-strict or spine-nonstrict
19:16:38	<c_wraith>	the thing is, you need to actually think about evaluation patterns. any "always X" is wrong
19:17:05	<geekosaur>	anyway a spine-nonstrict data structure is one in which the association between individual components is not strict. so for a list, it's the tail that links list elements together (and is nonstrict)
19:17:14	→	justsomeguy joins (~justsomeg@user/justsomeguy)
19:17:32	<geekosaur>	trees are also often nonstrict. this is usually a good thing as it permits sharing
19:17:42	<segfaultfizzbuzz>	sharing between threads?
19:18:13	<c_wraith>	the saving grace for thinking about evaluation patterns is that there are patterns which if applied locally consistently result in good global behavior.
19:18:14	<geekosaur>	no. if I change a given node in a tree, only the parent nodes need to be copied; child nodes can be shared
19:18:32	<geekosaur>	\(between the modified tree and the original)
19:18:45	×	kannon quits (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
19:18:48	<segfaultfizzbuzz>	i see
19:19:31	×	axeman_ quits (~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 260 seconds)
19:19:44	<geekosaur>	whereas if it's stricyt it would force copying of the entire tree to update a single node
19:19:50	<geekosaur>	*strict
19:19:59	<c_wraith>	I... don't think that's the same thing
19:20:06	<dolio>	Yeah, that's not true.
19:20:21	<segfaultfizzbuzz>	it seems like as you write down lines of code the probability that one line depends on some other line goes up quite rapidly over time--there is a "mixing coefficient" and it trends upwards
19:20:21	<davean>	segfaultfizzbuzz: they're crazy - you USUALLY want spine lazy
19:20:58	<segfaultfizzbuzz>	granted with functional programming you can try to minimize, control, and limit the growth of this mixing coefficient
19:21:05	<c_wraith>	there's a certain cargo cult of strictness in Haskell, though. You see a lot of bad advice out of them.
19:21:41	<davean>	people don't get what non-strictness means and things like liveness and persistence and sharing ...
19:21:56	<davean>	and they think in general strictness increases computational efficience which is very wrong
19:22:38	<segfaultfizzbuzz>	i think my primary reason for being strictness-oriented is fear
19:22:52	<geekosaur>	that may apply to most of the strictness cabal
19:22:56	→	Sgeo joins (~Sgeo@user/sgeo)
19:23:03	<davean>	segfaultfizzbuzz: so to get to the actual question, "spine-lazy" usually goes along with strict leaves
19:23:05	<segfaultfizzbuzz>	and my second reason is that it seems like if a block of code has a high mixing coefficient then strictness seems like it would make sense, at least for that block
19:23:24	<geekosaur>	that, and looking for simplistic ways out of having to actually understand their code
19:23:30	<c_wraith>	What you actually should do is learn how evaluation works in Haskell. It's a completely different approach than most languages, but it is logical and predictable.
19:23:30	<davean>	in that the local actual components often are more efficient to be computed promptly, but the overall structure is what gets shared and can limit control flow of other parts of the program
19:23:40	<davean>	and also what has to go with the useful parts of liveness control
19:23:44	<segfaultfizzbuzz>	c_wraith: yeah i am kind of in the middle of that, [exa] had been helping me
19:24:12	<davean>	c_wraith: its ... predictable? I mean SORTA technically, for a given compiler, but like its REALLY hard to predict for GHC.
19:24:15	<davean>	c_wraith: I mean in specific
19:24:23	<davean>	but I also care about the very precise details often
19:24:32	<davean>	because I'm often targetting assembly optimal output
19:25:14	<segfaultfizzbuzz>	davean: yeah i'm unlikely to ever understand code at the level of assembly, it is far far too complex
19:25:34	→	mikoto-chan joins (~mikoto-ch@164.5.249.78)
19:25:40	<segfaultfizzbuzz>	i am very aware that my primate brain is very limited so i just want the necessary and most powerful abstractions
19:25:50	<c_wraith>	I will say that RULES pragmas tend to break reasonability. And the full laziness transform is probably a mistake. If people want that result, they should just write that code.
19:26:47	<c_wraith>	GHC does too much magic to allow bad code to perform well, and sometimes it messes up good code.
19:28:43	→	acidjnk joins (~acidjnk@p200300d6e7137a4628adea4619d717ec.dip0.t-ipconnect.de)
19:28:55	<davean>	segfaultfizzbuzz: assembly is the MOST trivial
19:29:12	<davean>	segfaultfizzbuzz: its hard to write things in because its SO SIMPLE
19:29:19	<davean>	there is almost nothing to understand at all
19:29:43	<davean>	c_wraith: The full laziness transform is the only thing that really causes me issues ever
19:30:01	×	mima quits (mmh@gateway/vpn/airvpn/mima) (Ping timeout: 260 seconds)
19:30:27	<davean>	c_wraith: I just fought with it the other day, where duplicating a line of code (with a TINY fmap) took the compute time from 15 seconds in 10MiB to 100s of GiBs and OOM hours later
19:30:39	→	michalz joins (~michalz@185.246.204.75)
19:30:44	<c_wraith>	yeah, it's a rough one. It makes your code do something other than what you actually wrote.
19:30:50	<c_wraith>	If you wrote it that way for a reason....
19:30:50	<segfaultfizzbuzz>	davean: i mean okay you say that but there are like a zillion instructions and then consider their interactions and soforth, it's impossible
19:30:52	<davean>	and convincing GHC it was WRONG AND IT MUST NOT DO THAT was super annoying
19:31:04	<davean>	segfaultfizzbuzz: No, they don't interact
19:31:20	<segfaultfizzbuzz>	ever, in any context?
19:31:25	<davean>	segfaultfizzbuzz: and there are like 20 main ones, they have procedurally defined variation and then there are a few hundred specialized ones you can mostly ignore
19:31:35	<davean>	segfaultfizzbuzz: Yes, definitionally
19:31:42	<davean>	segfaultfizzbuzz: Assembly is too simple for any interactions at all
19:31:42	<segfaultfizzbuzz>	i think i know maybe eight instructions and i don't have the judgement to know which others are worth knowing
19:31:44	<c_wraith>	They certainly interact in edge cases. setting the FP mode, for instance.
19:32:00	<davean>	c_wraith: no, they set registers
19:32:08	<davean>	c_wraith: the instructions work directly from the register state
19:32:28	<davean>	theres no interaction between instructions, its all the register sets and it has nothing to do with the previsious instructions
19:32:51	<davean>	so every instruction can be analyized in complete isolation from what came befor
19:33:14	<segfaultfizzbuzz>	right but then there are lots of registers and you have to thnik about how an earlier instruction can impact a subsequent one
19:33:23	→	Pickchea joins (~private@user/pickchea)
19:33:34	<c_wraith>	I suppose very technically, that's true. But without complete visibility into contents of registers you might think never get touched, you can end up mistaking function.
19:33:39	<davean>	segfaultfizzbuzz: depends on the architecture, but there really aren't many, and most of them are the same specification for register
19:33:51	<segfaultfizzbuzz>	aren't there like 60 or something on x86
19:33:57	<davean>	theres like the control register, the IP, the FP, and then some general purpose ones. one general purpose one is often
19:33:57	<segfaultfizzbuzz>	i forget the number, but it isn't small
19:34:05	<davean>	"special" in that its teh default hard coded into some instructions
19:34:14	<davean>	segfaultfizzbuzz: They're almost all identical
19:34:14	<c_wraith>	x86 is kind of a worst-case for understandability. :P
19:34:26	<segfaultfizzbuzz>	and mov means copy lol
19:34:29	<davean>	x86 is kinda the worst case, but even there MOST of those registers are copy paste
19:34:34	<darkling>	If you have trouble with x86 assembly, try ARM. That's much nicer.
19:35:15	<davean>	segfaultfizzbuzz: and futher, MOST of THOSE 60ish registers are vector registers and not relivent to almost all code
19:35:30	<davean>	segfaultfizzbuzz: so even THAT claim is basicly meaningless in practice, even if they weren't copy and paste
19:35:49	<davean>	and even beyond that only like 4 have a special meaning thats relivent
19:36:23	<davean>	Honestly you could probably learn enough assembly to write basic integer programs in an 8 hour work day
19:36:49	<segfaultfizzbuzz>	probably you have spent hundreds of hours staring at assembly so it is familiar to you but even if i could somehow determine which instructions were worth paying attention to it is very unlikely that i would reach fluency
19:36:56	<darkling>	It's very very tedious, though...
19:37:04	<segfaultfizzbuzz>	and i also feel skeptical that programmers can defeat computers for much longer
19:37:07	<davean>	darkling: extremely tedious
19:37:40	<segfaultfizzbuzz>	we are maybe ten or twenty years away from programming ending up like the go board game, i think
19:37:41	<davean>	segfaultfizzbuzz: I wrote my first assembly program in under 6 hours - I happen to know because it was a game dev project back when I was first starting game dev in 1998 and I had to make it to school :-p
19:38:07	<darkling>	I tried the Advent of Code last year in Z80 assembler. I got to about day 4. :/
19:38:23	<davean>	segfaultfizzbuzz: really you're just scared
19:38:37	<davean>	segfaultfizzbuzz: ignorance generates fear
19:39:04	<davean>	You've built it up as some mythical beast, you haven't actually gone "Ok, what do I actually need to know to do X"
19:39:27	<segfaultfizzbuzz>	davean: partially that, partially it's that i intentionally avoid learning things which deteriorate in their value,... x86 has held up much better over time than i projected
19:39:50	<segfaultfizzbuzz>	i think that if itanium or whatever had taken off my point might have been more salient
19:40:21	<davean>	segfaultfizzbuzz: The thing is all assemblies are the same, it doesn't matter which you learn, they follow a principal and almost any language you learn educates you more about programming
19:40:28	<davean>	segfaultfizzbuzz: I programmed Itanium too
19:40:35	<davean>	In 2003
19:40:41	<segfaultfizzbuzz>	davean: there are probably some more fundamental things, ... and i think, so probably this has to do with the speed of light
19:40:56	<davean>	that was the hardest assembly I ever learned, it took like 2 days to get sufficient to be compitent, but I wasn't able to beat compilers
19:41:04	<segfaultfizzbuzz>	probably the speed of light means that a program is always about some kind of spatially local state
19:41:11	<darkling>	davean: I can think of at least two architectures that are very different at the assembly level to things like x86 or ARM, but those are pretty much dead and gone. :)
19:41:28	<segfaultfizzbuzz>	and so therefore something like a CPU is "inevitable"
19:41:37	<davean>	darkling: A few, but even like a dataflow processor is actually fairly similar
19:41:54	<davean>	darkling: Honestly, in a way a VLIW is the "most" different I've ever actually seen
19:41:58	<davean>	since it requires different thinking
19:42:05	<segfaultfizzbuzz>	i've also heard that we use CPU rather than FPGA for compute because FPGA layout is slow
19:42:18	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
19:42:26	×	Midjak quits (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
19:42:27	<davean>	segfaultfizzbuzz: You seem to hear a lot instead of learn a lot ;)
19:42:35	<darkling>	The CM-1 and CM-2 were one-bit processors runinng in parallel. No registers at all.
19:42:41	<davean>	darkling: I've seen those
19:42:50	<davean>	I know people who worked on those
19:43:03	<segfaultfizzbuzz>	uh, well the speed of light was my observation, but the FPGA thing is not
19:43:04	<davean>	By which I mean on the design of them
19:43:11	<darkling>	And the Transputer had a stack.
19:43:14	<davean>	segfaultfizzbuzz: yes, I'm talking about the FPGA thing
19:43:29	<davean>	darkling: oh lots of assemblies are stack based
19:43:31	<monochrom>	w00t transputer
19:43:37	<davean>	thats not really different than registers
19:43:38	<darkling>	Itanium was register-based, but you had to spend extra work on sequencing and combining the instructions into the VLIW.
19:43:42	<segfaultfizzbuzz>	davean: the question here partially is, is this whole concept of registers and assembly and cache hierarchy and whatnot physically inevitable
19:43:56	<davean>	segfaultfizzbuzz: Even a stack is effectively registers
19:44:05	<segfaultfizzbuzz>	right, local state
19:44:26	<davean>	a stack is a variable number of "real" registers, which is abstracted over
19:44:33	<segfaultfizzbuzz>	register, stack, cache are eskimo words for spatially localized state
19:45:04	<davean>	segfaultfizzbuzz: A specific sort really
19:45:25	<segfaultfizzbuzz>	so there is localized state, there is sequentiality, and then there is some kind of irreducible mixing
19:46:03	<davean>	darkling: I will say that there is a weird similarity between dataflow systems and VLIW
19:46:05	<monochrom>	Local state is probably inevitable. Note that sometimes it is encoded as control points.
19:46:19	<davean>	segfaultfizzbuzz: the thing is if you learned Itanium it would have been useful - what do you think modern GPUs look like?
19:46:32	×	jao quits (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
19:46:33	<segfaultfizzbuzz>	what is a control point
19:46:40	<segfaultfizzbuzz>	davean: lol gpus are itanium? haha
19:46:48	<davean>	segfaultfizzbuzz: They're VLIQW
19:46:51	<monochrom>	For example "I'm at line 10".
19:46:52	<c_wraith>	well, they're massively data parallel
19:46:52	<davean>	*VLIW
19:47:02	<davean>	c_wraith: very specificly they're VLIW
19:47:19	<monochrom>	For example program counter.
19:47:45	→	ddellacosta joins (~ddellacos@143.244.47.77)
19:48:41	<davean>	c_wraith: I mean they're also a weird VLIW sometimes
19:49:05	<segfaultfizzbuzz>	davean: well i will complain a bit that we still aren't referencing a paper or proving that this whole approach is inevitable
19:49:55	<segfaultfizzbuzz>	we might imagine an FPGA which could be reprogrammed extraordinarily quickly (after every clock or something) or other ways of doing things
19:50:27	<davean>	segfaultfizzbuzz: they tend to wear out.
19:50:31	<davean>	depending on the design
19:50:37	<monochrom>	If you change the circuit every clock cycle, I will then just declare that the circuit is your local state.
19:50:37	<davean>	you don't want too many rewrite cycles.
19:50:45	<davean>	But infact there was a design that did that for temporal locality
19:51:03	<monochrom>	In the same way if your program counter changes every clock cycle, that's your local state.
19:51:54	<segfaultfizzbuzz>	there is a compelling argument that we need to be using electrons, albeit there are some very new developments in photonics which may decrease the size advantage gap,...
19:52:01	<monochrom>	Indeed "program counter" is an index to an array of circuits.
19:54:06	<segfaultfizzbuzz>	davean: so is there a blog post on your 20 instructions of importance?
19:54:26	<davean>	segfaultfizzbuzz: I will say programming OoO assembly and VLIW assembly has taught me SPECIFICLY why spine-lazy is a good datastructure approach often
19:54:38	<monochrom>	In general, I'm pretty sure the Church-Turing thesis already implies you must have local state or encoding thereof.
19:54:38	<segfaultfizzbuzz>	oh wow okay so this is a very sophisticated question then
19:54:38	<davean>	segfaultfizzbuzz: oh no, most assembly tutorials handle that
19:54:55	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
19:55:07	<segfaultfizzbuzz>	i mean i read an introduction to riscv once
19:56:15	<segfaultfizzbuzz>	davean: since you seem to really understand performance i have an embarassingly bad question
19:57:12	<davean>	I have about 5 more minutes
19:57:27	<segfaultfizzbuzz>	which is that the (cringey, i know) programming language shootout normally has not that many problems to solve but it seems like haskell should have a better showing there if it wants to live up to its claims (10% of C),... plus not uncommonly there is some compilation flaw
19:57:57	<davean>	oh man I don't think anyone has updated those in 15 years
19:58:02	<davean>	since BOS was working on them
19:58:17	<monochrom>	Yeah they now have real-world real jobs.
19:58:17	<segfaultfizzbuzz>	yeah, so, maybe someone should do that? :-P
19:58:28	<dolio>	Why, though?
19:58:35	<davean>	No one cares
19:58:42	<segfaultfizzbuzz>	lol ok
19:58:48	<segfaultfizzbuzz>	haskell wants to be unknown
19:58:51	<davean>	I could make something cool, or update someone else's out of date toy test case
19:59:01	<[exa]>	it's a test, takes out people who believe random stuff on the internet
19:59:08	<davean>	segfaultfizzbuzz: last I knew it was generally better than most of the options on there but I haven't looked in years
19:59:14	<segfaultfizzbuzz>	i mean, haskell is also random stuff on the internet lol
19:59:37	<davean>	segfaultfizzbuzz: If you look at the code for those, many of the languages aren't actually doing the same thing
19:59:45	<davean>	its not a senible comparison to start with
19:59:50	<segfaultfizzbuzz>	yeah there is a lot of false comparison
19:59:57	→	jao joins (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
20:00:00	<davean>	some to some degree its a game of how infidelious (sp?) you're willing to be
20:00:13	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
20:00:15	<segfaultfizzbuzz>	what we don't have a good way of measuring is "idiomatic speed"
20:00:25	<segfaultfizzbuzz>	which is how much domain knowledge/special stuff you need to know to go fast
20:00:40	<davean>	man I haven't used "infidelious" as a word in a long time, glad I didn't butcher that
20:00:43	<segfaultfizzbuzz>	hahah
20:00:45	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
20:00:57	<davean>	segfaultfizzbuzz: honestly one thing I've learned with Haskell is that there is a HUGE spectrum of "idiomatic speed" in Haskell
20:01:01	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
20:01:04	<dolio>	Even if all the examples were up to date and accurate, the premise leads people to make stupid decisions.
20:01:04	<darkling>	Sounds like a character from some minor Opera Buffa. :)
20:01:06	<davean>	Several orders of magnitude
20:01:17	<dolio>	Because they'll just go, "C is fastest, so everyone should use C."
20:01:17	<davean>	and some forms of thinking lead to space leaks and slowness and other people just never experience them
20:01:39	<davean>	dolio: I beat a C with Haskell for a talk ;)
20:01:43	<segfaultfizzbuzz>	i am not smart enough to write or read C,... i am probably also not smart enough to read or write haskell but at least it follows some rules
20:01:51	<davean>	(now I'm being a little infidelious but not too badly)
20:02:14	<monochrom>	In idiomatic C, people do not use proper data structures. If they need a priority queue, they just put things in an array in arbitrary order and then do linear search every time.
20:02:23	<segfaultfizzbuzz>	haha
20:02:37	<[exa]>	that approach is underrated
20:02:37	<segfaultfizzbuzz>	because it's so fast that you don't have to write good code
20:02:41	×	justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 244 seconds)
20:02:49	<dolio>	Because, for example, they haven't taken monochrom's class, and learned that most people are really bad at writing C, so they shouldn't.
20:02:52	<davean>	[exa]: that approach is optimal for small n :-p
20:02:57	<monochrom>	You can probably even see that in the Linux kernel for many past versions.
20:03:22	<[exa]>	yeah, surprisingly most people's n is small
20:03:30	<segfaultfizzbuzz>	davean: yeah, i can tell from your most recent statement that you actually do know how to code :^)
20:03:30	<davean>	[exa]: its about judgement, sometimes that is what you SHOULD do, and knowing when to do that vs. the complicated version is what seperates the compitent from the incompitent
20:04:12	<[exa]>	davean: yeah (or simply account for programmer time spent nerding about the best algorithm :D )
20:04:14	<darkling>	If you've only got three items, bubble sort is going to be pretty fast and simple...
20:04:30	<darkling>	If you've got a million items, it'd be a disaster.
20:04:51	<davean>	darkling: right which is why almost all sort implimentations switch short algs when the n gets small
20:04:55	<monochrom>	But I learned that from the code library that the U of Waterloo team brought to the ACM programming contests. Recall that U of Waterloo consistently places like the top 5 or even top 3.
20:04:59	<davean>	(including on the specific sub problem)
20:05:18	<davean>	monochrom: learned what specificly?\
20:05:18	<monochrom>	And considering that the ACM programming contests give you large n's.
20:05:32	<segfaultfizzbuzz>	okay so if i can ask a very boring practical question about strictness/laziness and fear:
20:05:44	<davean>	I'm a bit out of my 5 minutes
20:05:51	<davean>	I'm sure other people can help you though :)
20:05:53	<segfaultfizzbuzz>	davean: that's fine thanks for the input :-)
20:05:56	<monochrom>	That when you need a priority queue for Dijkstra's shortest path, you just throw things an an array and do linear search every time.
20:06:18	<monochrom>	Or perhaps s/you/they/
20:06:40	<segfaultfizzbuzz>	so suppose someone is writing a rest backend which updates a database
20:06:47	<segfaultfizzbuzz>	or talks to a database i should say
20:07:07	<monochrom>	Although, I think I heard that at some point the Linux kernel changelog also had "we finally use a real priority queue".
20:07:20	<segfaultfizzbuzz>	the rest backend must respond to each command in full
20:08:02	<segfaultfizzbuzz>	it would be too stressfull to think about a rest query which hangs around un-evaluated in part while other rest commands do their thing
20:08:38	<segfaultfizzbuzz>	so at some top level there is some kind of per-request strictness mandate
20:08:42	<geekosaur>	if it must respond in full then it'll force evaluation
20:09:00	<segfaultfizzbuzz>	and then,... won't that almost always bubble all the way down?
20:09:24	<segfaultfizzbuzz>	like you might make an individual rest command faster or terminate for more cases or whatever, but
20:10:11	<[exa]>	segfaultfizzbuzz: the queries are usually some kind of IO actions, not really simple to have them hanging around unevaluated. You eitehr run the IO or not.
20:10:14	<segfaultfizzbuzz>	you can't like visit amazon.com and have your query hanging around for an hour while their backend decides that it can't yet justify evaluating your entire query, right?
20:10:37	<geekosaur>	IO forces evaluation, in general
20:10:57	<geekosaur>	laziness comes in when for example some part of the query isn't relevant to the result
20:11:10	<geekosaur>	so it won't be evaluated
20:11:18	<segfaultfizzbuzz>	right, i can make sense of query-internal laziness
20:11:28	<segfaultfizzbuzz>	but "exterior" laziness makes me quiver with fear
20:11:38	<[exa]>	that's the right reaction IMO
20:11:43	<geekosaur>	that's just silly
20:11:50	<geekosaur>	hm, is it?
20:11:59	<[exa]>	and that's why you don't unsafePerformIO
20:12:01	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 260 seconds)
20:12:17	<geekosaur>	right, unsafePerformIO is another question
20:12:23	<segfaultfizzbuzz>	because unsafePerformIO can cause the evaluation to be postponed?
20:12:50	<geekosaur>	because it does an IO evaluation lazily instead of letting the IO force evaluation
20:13:08	<[exa]>	yeah, it's one of the easiest ways to have strictness/laziness exhibit external actions
20:13:17	<geekosaur>	because unsafePerformIO makes a strict IO operation look like a lazy operation
20:14:14	<[exa]>	and while it has uses (Debug.Trace afaik?), I'd sanely choose to have stuff organized in actual production code
20:14:47	<geekosaur>	Debug.Trace, yes. where a large part of the point is showing when something is lazily evaluated
20:15:15	<geekosaur>	by doing the IO at that point instead of the IO strictifying evaluation
20:16:59	→	beteigeuze1 joins (~Thunderbi@bl11-28-222.dsl.telepac.pt)
20:17:22	×	lortabac quits (~lortabac@2a01:e0a:541:b8f0:3570:6165:e2af:8564) (Quit: WeeChat 2.8)
20:17:30	<[exa]>	segfaultfizzbuzz: in short, you don't need to worry-- all externally visible actions (except timing etc.) are written in a strict DSL (the IO monad) unless you decide to explicitly break it, with your own consequences
20:17:43	×	beteigeuze quits (~Thunderbi@bl11-28-222.dsl.telepac.pt) (Read error: Connection reset by peer)
20:17:43	beteigeuze1	is now known as beteigeuze
20:18:06	<qrpnxz>	all IO is lazy, it just so happens that that the dependency chain of the subsequent continuations passed to >>= makes them happen in order once the action is needed (main is forced)
20:18:46	<qrpnxz>	in other words, if you never make main depend on an IO action, it doesn't happen
20:19:33	<qrpnxz>	so i wouldn't say that unsafePerformIO makes an action any lazier with that respect
20:22:02	<Hecate>	lazy IO is the work of the Devil
20:22:13	<dolio>	No it isn't.
20:22:14	<qrpnxz>	that's another kind of lazy IO 😃
20:22:21	<qrpnxz>	and i do avoid it at all costs
20:22:29	<Hecate>	qrpnxz: ;-D
20:22:53	→	ten_finger_typis joins (~ten_finge@adsl-84-226-91-51.adslplus.ch)
20:23:00	<geekosaur>	let's just say anyting designated "unsafe" is so designated for a reason
20:23:33	<geekosaur>	this includes things that are based on unsafeInterleaveIO (and are typically regarded as "lazy I/O")
20:24:03	<qrpnxz>	unsafeInterleaveIO is pretend play IO. You set up all these dependency chains for nothing because the IO happens whenever it bloody wants
20:24:10	→	matthewmosior joins (~matthewmo@173.170.253.91)
20:24:17	<Hecate>	qrpnxz: btw, I'm interested in your usage of effectful
20:24:24	<qrpnxz>	Hecate: oh?
20:24:26	<qrpnxz>	what's up
20:24:31	<segfaultfizzbuzz>	anyway i think the thing that makes me the most nervous about laziness is that my mission-critical rest backend might fail to complete evaluation of a rest command or a certain command might cause a space leak which is otherwise not visible
20:24:38	<Hecate>	qrpnxz: I'm co-maintainer and avid user, so I'm interested in you as a user :)
20:24:46	<qrpnxz>	ah! :)
20:24:59	<qrpnxz>	i'm having fun with it.
20:25:08	<Hecate>	kewl
20:25:25	<geekosaur>	segfaultfizzbuzz, if it has to respond and that response depends on evaluation then it will complete evaluation
20:25:33	←	jakalx parts (~jakalx@base.jakalx.net) (Error from remote client)
20:25:38	<qrpnxz>	It just makes me so happy honestly, because it makes reality that old idea of "have an effect for different IO things without having to use IO everywhere and it actually composes"
20:25:42	<Hecate>	qrpnxz: fun fact, I replaced a DataKind affixed to a Session type by an effect in the stack, in Flora
20:25:59	<Hecate>	qrpnxz: oh yeah it's beautiful
20:26:03	<segfaultfizzbuzz>	it might be nice if there was some way to have per-action memory pressure
20:26:32	<segfaultfizzbuzz>	so i could say, here is 64MB for a rest command, become more strict the closer you get to 64MB
20:26:39	<geekosaur>	space leaks are more complicated but boil down to letting too many things pile up until the response forces them. whether this happens or not, or even matters, depends on what you're doing
20:26:54	<qrpnxz>	Hecate: what is Flora?
20:27:31	<ten_finger_typis>	I am trying to understand a bit more about unsafeCoerce. It is safe, if the two types have the same representation, but what about GADTs like lists or Maybe. Is the following safe or can it give an incorrect result for some list?
20:27:32	<ten_finger_typis>	f :: [a] -> Int
20:27:32	<ten_finger_typis>	f x = length (unsafeCoerce x :: [()])
20:28:09	<qrpnxz>	that use would not be safe, you don't know that `a` has same rep as ()
20:28:11	<monochrom>	qrpnxz: I used unsafeInterleaveIO to develope a joke unsafeInterleaveIO-passing style :)
20:28:19	<Hecate>	qrpnxz: good question: https://github.com/flora-pm/flora-server/wiki/What-is-Flora
20:28:19	<qrpnxz>	lol
20:28:37	×	Topsi quits (~Topsi@dyndsl-095-033-090-077.ewe-ip-backbone.de) (Read error: Connection reset by peer)
20:28:46	<ten_finger_typis>	@qr
20:28:46	<lambdabot>	Maybe you meant: wn v url src rc pl id do bf arr @ ? .
20:28:52	<qrpnxz>	oh interesting
20:29:55	<qrpnxz>	ten_finger_typis: this would be allowed: f x = length (fmap (unsafeCoerce :: _ -> Any) x)
20:29:57	<ten_finger_typis>	@qrpnxz but does that actually matter in this case?
20:29:57	<lambdabot>	Unknown command, try @list
20:30:01	<monochrom>	That one is safe, although why bother, length is already polymorphic.
20:30:22	<qrpnxz>	unsafeCoerce, and worse unsafeCoerce#, are good ways to segfault a normally unbreakable haskell program
20:30:23	<qrpnxz>	so watch out
20:30:41	<ten_finger_typis>	yes ;-)
20:30:42	<qrpnxz>	monochrom: yeah lol
20:31:13	<ten_finger_typis>	good advice using that fmap to Any
20:31:14	<monochrom>	Wait, a normally unbreakable program shouldn't be affected.
20:31:28	→	jakalx joins (~jakalx@base.jakalx.net)
20:31:38	→	pavonia joins (~user@user/siracusa)
20:31:38	<monochrom>	It is the nomrally rejected program that gets accepted and then segfaults.
20:32:04	<monochrom>	Although, maybe you define unbreakable to include unrunnable.
20:32:17	<qrpnxz>	i mean a program you would have written properly, but instead did something crazy with unsafe. Sprinkling unsafeCoerce in an already sane program shouldn't do anything yes
20:32:28	→	bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
20:32:31	<monochrom>	Oh, that.
20:32:39	<ten_finger_typis>	What about this?
20:32:39	<ten_finger_typis>	f x = length (unsafeCoerce :: [(Any)])
20:32:43	<ten_finger_typis>	What about this?
20:32:43	<ten_finger_typis>	f x = length (unsafeCoerce :: [(Any)])
20:32:47	<ten_finger_typis>	What about this?
20:32:48	<ten_finger_typis>	f x = length (unsafeCoerce x :: [(Any)])
20:33:20	<monochrom>	The representation of the spine of [X] is independent of X.
20:33:24	<qrpnxz>	i would think unsafe coerce of [a] to [Any] should be okay, but i've not seen documentation particularly blessing that
20:33:35	×	bitdex_ quits (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds)
20:33:52	<monochrom>	So in the eyes of length, which only cares about the spine, you can make it [X] or [Y] or [Any].
20:34:17	×	vglfr quits (~vglfr@145.224.94.75) (Read error: Connection reset by peer)
20:34:26	<monochrom>	Although, I haven't checked what happens when there is also fusion.
20:34:29	→	vglfr joins (~vglfr@145.224.94.75)
20:35:04	<qrpnxz>	good question
20:35:18	×	goepsilongo quits (~goepsilon@2806:101e:9:5045:107a:c190:12f7:570c) (Quit: Textual IRC Client: www.textualapp.com)
20:35:33	<qrpnxz>	however length is implemented it would ignore the element (it's poly so it can't do anything with it) so i would think fusion doesn't change anything
20:35:48	<monochrom>	I think it doesn't break fusion. Or rather, fusion doesn't break my model.
20:36:26	<monochrom>	Yeah, that.
20:36:33	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
20:36:59	<ten_finger_typis>	For context, I have been playing around with existential types,
20:37:02	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
20:37:12	<ten_finger_typis>	data A = forall a . Typeable a => A a
20:37:13	<ten_finger_typis>	listLength :: A -> Maybe Int
20:37:13	<ten_finger_typis>	listLength (A a)
20:37:14	<ten_finger_typis>	\| App con _ <- R.typeOf a
20:37:14	<monochrom>	"Safe unsafeCoerce for Free! A Sequel to Theorems for Free!"
20:37:14	<ten_finger_typis>	, Just HRefl <- con `eqTypeRep` R.typeRep @[]
20:37:15	<ten_finger_typis>	= Just $ length (unsafeCoerce a :: [()])
20:37:15	<ten_finger_typis>	\| True
20:37:16	<ten_finger_typis>	= Nothing
20:37:28	<geekosaur>	@where paste
20:37:28	<lambdabot>	Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com
20:37:40	×	coot quits (~coot@213.134.176.158) (Quit: coot)
20:37:42	<geekosaur>	please don't just blat code into the channel
20:37:51	<ten_finger_typis>	sorry, thanks for the link
20:38:00	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
20:38:18	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
20:39:09	<qrpnxz>	"coerce: theorems for less" "unsafeCoerce: freer theorems" "unsafeCoerce#: theorems gives you their wallet!"
20:39:52	<monochrom>	Sounds like "shut up and take my money" :)
20:40:41	<qrpnxz>	Hecate: since you say you are co-mantainer, I'll bring up a PR i just made... https://github.com/haskell-effectful/effectful/pull/94 :)
20:41:20	<hpc>	qrpnxz: if the program has no semantics, it has no bugs either
20:41:38	<qrpnxz>	unfortunately also no features :(
20:41:42	<monochrom>	But every program has semantics.
20:41:54	<monochrom>	But you could s/semantics/specification
20:41:57	×	tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
20:41:58	<qrpnxz>	"it's supposed to segfault!"
20:42:15	<[exa]>	"the code is the specification!!!"
20:42:29	<qrpnxz>	amen
20:42:36	<monochrom>	This is why I keep my expectations low.
20:42:41	<[exa]>	:]
20:42:41	<ten_finger_typis>	so in the `listLength` functionabove the `fmap unsafeCoerce` would not wok because the type in the list would be ambiguous
20:43:00	<qrpnxz>	Any is specifically made so that anything can be unsafeCoerced into it
20:43:34	<monochrom>	If you present a glass half-filled with water, some see it as half-empty, some others see it as half-full. I see "at least there is a glass".
20:43:46	<ten_finger_typis>	yes, and that extends to thinks like [X] = [Any]
20:43:48	<ten_finger_typis>	?
20:43:51	<darkling>	But it's clearly twice the size it needs to be.
20:44:02	<monochrom>	haha
20:44:03	<qrpnxz>	i don't make that assumption generally, but i would think likely
20:44:40	<ten_finger_typis>	thanks
20:44:41	<qrpnxz>	fmap is definitely okay, not fmapping is probably okay. I'm team definitely okay, personally.
20:45:09	<segfaultfizzbuzz>	if i write assembly "in haskell" can haskell still limit the damage i do?
20:45:28	<qrpnxz>	idk what writing assembly in haskell looks like
20:45:40	<segfaultfizzbuzz>	so for example if i have a haskell function mapping FooType to BarType
20:46:06	<segfaultfizzbuzz>	can i put assembly "on the interior" of that function ?
20:46:37	→	mima joins (mmh@gateway/vpn/airvpn/mima)
20:46:50	<Hecate>	qrpnxz: I saw it :) But at this level I have to defer to Andrzej
20:46:57	<qrpnxz>	👍
20:46:57	<Hecate>	and also I'm flying abroad like tomorrow
20:47:16	<qrpnxz>	business or pleasure?
20:47:20	<Hecate>	vacations!
20:47:24	<qrpnxz>	yay!
20:47:26	<monochrom>	Perhaps you can s/asm/C/ and investigate first what happens when Haskell calls a C function.
20:47:26	<Hecate>	so, cruelly needed
20:47:27	<segfaultfizzbuzz>	and be guaranteed that, worst case is that i mangle the map from FooType to BarType, rather than cause my inkjet printer to demand ink
20:47:48	<segfaultfizzbuzz>	monochrom: ok
20:47:58	<qrpnxz>	if "asm in haskell" is like "C in haskell", then you should be able to break the rules and launch nukes
20:48:05	<Hecate>	qrpnxz: btw, we're always interested in experience feedbacks, so don't hesitate to publish a post / tweet / post on Reddit about your experience with Effectful
20:48:06	<monochrom>	But we already know the answer, don't we? Haskell does not limit the damage of foreign functions.
20:48:13	<qrpnxz>	you have to make the choice and tag with IO or not an extern call
20:48:28	<qrpnxz>	Hecate: 👍 will consider
20:49:15	<segfaultfizzbuzz>	so maybe FFI is the wrong way to "do asm in haskell"
20:49:16	<monochrom>	As for causing an inkjet printer to demand ink, isn't that the job of an OS?
20:49:34	<monochrom>	Err I mean the job of an OS to stop that.
20:49:35	<segfaultfizzbuzz>	monochrom: i was making a joke in lieu of "launch nukes"
20:49:36	<qrpnxz>	i think CUPS is userspace :)
20:50:04	<ten_finger_typis>	qrpnxz: I do not know how I could get fmap to work in that example
20:50:07	<segfaultfizzbuzz>	qrpnxz: lol
20:50:13	<qrpnxz>	i like launch nukes because that's how bad it could hypothetically be xD
20:50:33	<segfaultfizzbuzz>	i am more afraid of printer ink
20:50:35	<qrpnxz>	ten_finger_typis: idk what you mean by how. Does it not type check?
20:50:51	→	tromp joins (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
20:51:11	<monochrom>	What is with this obsession with length (unsafeCoerse xs)?
20:51:13	<qrpnxz>	segfaultfizzbuzz: tbh if my printer just started printing a bunch of all black pages none stop i'd freak out and get quite irate xD
20:51:26	→	kannon joins (~NK@108-216-157-82.lightspeed.sntcca.sbcglobal.net)
20:51:31	<segfaultfizzbuzz>	qrpnxz: so you agree xD
20:51:45	<qrpnxz>	i can't say that's worse than nukes, but it pretty bad
20:51:48	<qrpnxz>	:)
20:52:01	<qrpnxz>	monochrom: maybe the length is 42 :)
20:52:12	<segfaultfizzbuzz>	yeah on a log scale it's like only one step worse
20:52:19	<qrpnxz>	xD
20:52:23	<monochrom>	No no no.
20:52:37	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
20:52:57	<monochrom>	If you waste ink, it runs you into debt, you'll be miserable.
20:53:07	<monochrom>	If you launch nuke, all your debts are over.
20:53:26	<segfaultfizzbuzz>	monochrom: btw if i search for hakell c ffi i get a guide to a method which "is discouraged" https://wiki.haskell.org/Foreign_Function_Interface
20:53:49	<qrpnxz>	if we amortize the printer damage caused by nukes into all other cotidian printer issues, we see that the typical printer issue is about as bad as a nuke /s
20:54:18	<monochrom>	Oh, that one. It just means s/ccall/capi/ throughout the article and you'll be fine.
20:54:24	<qrpnxz>	lol
20:54:36	<monochrom>	This is what's wrong with the haskell wiki.
20:54:42	<segfaultfizzbuzz>	monochrom: oh ok the writing should clarify that
20:54:50	<qrpnxz>	feel free to edit :)
20:54:51	<geekosaur>	back in the day, ghc compiled haskell via c and there was no problem
20:55:01	<monochrom>	People are too polite to edit, no? So add a sentence instead of editing or deleting.
20:55:04	<geekosaur>	eventually ghc started compiling directly to asm
20:55:36	<qrpnxz>	and now there's even llvm backend i think
20:55:40	<geekosaur>	this made calling some C functions or referring to some C values mroe difficult, because they were actually C preprocessor defines
20:56:08	<geekosaur>	llvm still has this problem since it's not going through C any more
20:56:25	<monochrom>	Although, in the off chance you're still using Hugs, it doesn't have capi, you're stuck with ccall, which is the only standardized one.
20:56:26	<geekosaur>	so capi was developed, which makes FFI go via the C compiler instead of direct to asm
20:56:33	<qrpnxz>	:o
20:56:39	<ten_finger_typis>	wait, it looks like I do not need coerce at all, GHC knows that it's list and that's enough: https://paste.tomsmeding.com/rzrG5Ogj
20:56:42	<geekosaur>	(or llvm IR)
20:57:50	<monochrom>	Consider the infamous errno :)
20:58:24	<geekosaur>	well, that's still going to be infamous 🙂
20:59:15	<monochrom>	Also sorry geekosaur last time I put up an unnecessary argument. On second thought I agree that capi uniformly is the better idea. Although, last time I was really whining about the haskell wiki.
20:59:42	<geekosaur>	yes
20:59:50	<geekosaur>	I just logged in and popped up the page in question
21:00:05	<monochrom>	Even I teach my students that even errno is not simple at all, not going to be a simple global "int errno;".
21:00:08	<geekosaur>	(account creation is disabled currently so there's not much segfaultfizzbuzz will be able to do)
21:01:07	×	__monty__ quits (~toonn@user/toonn) (Quit: leaving)
21:01:19	<hpc>	"simple global" you say :D
21:02:44	<darkling>	Global variables? Just say errno.
21:02:49	<monochrom>	haha
21:03:36	<apache2>	lol monochrom, arrays?!? real C programmers just use labels and volatile stack variables
21:04:19	<geekosaur>	anyone want to check my changes to https://wiki.haskell.org/Foreign_Function_Interface ?
21:04:25	<int-e>	darkling: err... no?
21:04:35	<monochrom>	haha
21:04:56	→	justsomeguy joins (~justsomeg@user/justsomeguy)
21:05:47	<apache2>	also why would you need linear search
21:06:12	<monochrom>	Are you suggesting bogosearch instead? :)
21:06:14	<apache2>	the hardware already has a builtin btree
21:06:30	<monochrom>	Wait, that's new to me.
21:06:37	<apache2>	you can just use ring2 page faults
21:06:38	<int-e>	which hardware?
21:06:43	<monochrom>	Oh hahahaha
21:06:46	<int-e>	ah
21:06:48	<apache2>	amd64?
21:06:49	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds)
21:06:55	×	takuan_dozo quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
21:06:56	<int-e>	page tables
21:07:07	<int-e>	not quite a btree
21:07:16	<apache2>	alright, close enough
21:07:23	<monochrom>	Next time I teach data structures I'll keep that in mind >:)
21:07:40	<qrpnxz>	darkling: lmao
21:08:14	<qrpnxz>	geekosaur: thanks for the edit
21:08:22	<apache2>	in idiomatic C you could use binary search though
21:08:25	<int-e>	monochrom: is there a constant time version of bogosearch? (pick random index, write key there, return index)
21:08:30	<apache2>	or skip lists; skip lists are easy in C
21:08:33	<int-e>	(it's definitely bogus)
21:08:51	<monochrom>	I thought bogo-anything is meant to take at least exponential time...
21:09:00	<apache2>	if search.h didn't suck so badly you could use anything in there
21:09:16	<qrpnxz>	int-e: that would not help because it still has to check every index, and it will still stop on exactly the same condition: needle index
21:09:56	<int-e>	qrpnxz: nah, it returns a valid index for the key
21:10:04	<kilolympus>	Does using "awaitForever yield" as a Conduit in the "conduit" library impact performance? Or is it fused away in compilation?
21:10:06	<apache2>	int-e you can do constant
21:10:07	<qrpnxz>	?
21:10:12	<apache2>	n^2 inserts
21:10:16	<int-e>	qrpnxz: that's why it's writing the key
21:10:17	<int-e>	;)
21:10:23	<apache2>	with n
21:10:25	<int-e>	it's a joke. probably a bad one.
21:10:28	<apache2>	lookup time
21:10:35	<apache2>	whoah my enter key is crapping out, sorry
21:10:51	<monochrom>	qrpnxz, int-e's method is known as "planting evidence" in law and law enforcement circles.
21:11:01	<qrpnxz>	lol
21:11:38	<qrpnxz>	kilolympus: i don't think there's a fusion rule for that, but if you can statically see that you are doing that... don't?
21:11:56	<kilolympus>	Mmmmmm good point amazing point
21:11:57	<qrpnxz>	and if it's dynamic that it might do that, then the rule wouldn't trigger anyway and it's okay
21:12:16	<kilolympus>	Thanks qrpnxz !
21:12:20	<qrpnxz>	👍
21:12:54	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
21:15:22	×	_xor quits (~xor@74.215.182.83) (Read error: Connection reset by peer)
21:18:11	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds)
21:22:14	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
21:29:41	×	gmg quits (~user@user/gehmehgeh) (Quit: Leaving)
21:31:33	×	kannon quits (~NK@108-216-157-82.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 244 seconds)
21:34:59	×	acidjnk quits (~acidjnk@p200300d6e7137a4628adea4619d717ec.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
21:38:56	×	ormaaj quits (~ormaaj@user/ormaaj) (Quit: Reconnecting)
21:39:21	→	ormaaj joins (~ormaaj@user/ormaaj)
21:45:53	<mrianbloom>	Is it possible to have a default associated type family that is applied to any type that isn't specified by another instance?
21:46:26	×	tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
21:49:55	<glguy>	mrianbloom: you can have a default on the class that's used as the default for any instance you define
21:50:35	×	justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 255 seconds)
21:51:56	×	Pickchea quits (~private@user/pickchea) (Quit: Leaving)
21:54:40	→	justsomeguy joins (~justsomeg@user/justsomeguy)
21:55:50	<mrianbloom>	Are there any restrictions on that, like for example this code snippet doesn't compile:
21:56:09	<mrianbloom>	https://www.irccloud.com/pastebin/OuX1GiPO/
21:56:44	×	michalz quits (~michalz@185.246.204.75) (Remote host closed the connection)
21:56:47	×	azimut quits (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
21:56:47	<glguy>	The default implementations don't get to assume that the instance uses the default associated type family
21:57:00	<glguy>	you'll need to assert that in the context of those default implementations
21:57:21	→	azimut joins (~azimut@gateway/tor-sasl/azimut)
21:57:24	<mrianbloom>	Is see, with a unification constraint?
21:57:34	<glguy>	yeah, like this: https://hackage.haskell.org/package/generic-trie-0.3.1/docs/src/Data.GenericTrie.Internal.html#TrieKey
22:00:06	<mrianbloom>	I feel like I may done that initially but there were downstream consequences I couldn't satisfy...
22:01:39	<mrianbloom>	I guess the use of the newtype TrieRepDefault helps with that.
22:02:03	<pareto-optimal-d>	I'm writing a blog post about "Why use Nix+Cabal over Cabal" and was curious if others found this point compelling: I can get a ghci repl with lens in 3s versus 3m with just cabal-install.
22:02:38	<glguy>	pareto-optimal-d: after the first time cabal repl without nix is also very fast, so it's not saving 3m every time, just the first time
22:02:44	<glguy>	so not particularly compelling for me, at least
22:02:56	×	pretty_dumm_guy quits (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 268 seconds)
22:02:57	<qrpnxz>	if anything i'm using uses lens, i already have lens installed. It's a one time cost no?
22:03:09	<glguy>	I lose much more time trying to make nix work in all the other cases, so the time savings dries up
22:04:04	<glguy>	the compelling thing for nix is that it's easier for people who aren't you to just reproduce something you've done
22:04:11	<pareto-optimal-d>	Thank you. I agree with that. The place I can think of it mattering is if you want to try a new GHC version, that's the time when the cache helps the most I think. Also for things like Gloss or gl which have native deps.
22:04:22	<glguy>	but for the nix user it's just more work
22:04:36	<qrpnxz>	i don't find nix particularly more reproducible than an RPM
22:04:52	<qrpnxz>	or probably even a dpkg
22:05:09	<qrpnxz>	but nix script might be easier to run?
22:05:18	<pareto-optimal-d>	Another point I'm making you may find compelling is reproducible and fast rebasing. Like rebasing two commits over 6 months between two commit hashes. I don't often need that... but when I do it's very useful to be able to kick that off in the background while I explore other things.
22:06:54	<pareto-optimal-d>	I can personally say that I had a lot of breakages around ubuntu upgrades and have very few with nix upgrades qrpnxz. I know that debian has it's reproducibility project, but not sure if RPM does. I guess you are talking about subjective reproducibility rather than objective reproducibility since that's most relevant to your experience developing Haskell?
22:07:03	×	zeenk quits (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!)
22:07:36	<qrpnxz>	i've never had an issue in debian, basically ever that i can recal. On fedora i have some software stability issues, but just because the software is so new, not even a packaging problem.
22:09:13	<qrpnxz>	idk what you mean about subjective reproducible
22:11:12	<qrpnxz>	i can't speak for ubuntu, because i don't really ever use it. Not a trustworthy company. I don't feel they really add anything worthwhile to debian either
22:11:34	×	mikoto-chan quits (~mikoto-ch@164.5.249.78) (Ping timeout: 268 seconds)
22:11:36	<qrpnxz>	I do like their design, at least in the past, i don't even know what ubuntu look like now
22:12:27	<qrpnxz>	i think about 5 year i used ubuntu, it worked okay, but got bloated, and their upgrades are inferior to Debian, so when i had to upgrade, i upgraded to debian lol
22:14:03	<qrpnxz>	debian was pretty much the only system up until recently (now Fedora too, kind of) that officially supported in place major version update of the system. There's reports of people that have the same Debian install since like version 3. Reliable af.
22:14:26	<qrpnxz>	every other OS is like dark ages wipe the drive and reinstall
22:14:54	<qrpnxz>	actually mind blowing. Not surprising rolling release got so popular. That's the stupidest model ever
22:16:23	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
22:17:10	<pareto-optimal-d>	I used to use Debian around squeeze.
22:17:40	→	kannon joins (~NK@76.243.126.210)
22:18:20	×	kannon quits (~NK@76.243.126.210) (Read error: Connection reset by peer)
22:18:28	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
22:18:35	<ten_finger_typis>	can TypeAnnotations be used with operators? something like: a < @Int b
22:18:54	<glguy>	ten_finger_typis: I'd try using: (<) @Int
22:18:58	<glguy>	but I don't remember
22:19:26	<pareto-optimal-d>	By subjective reproducibility I mean the parts that are part of your anectdotal but important experience.
22:19:26	<pareto-optimal-d>	As opposed to objective as in docker images are composed of timestamps which are a source of entropy making it less reproducible qrpnxz
22:19:59	→	bilegeek joins (~bilegeek@2600:1008:b044:1225:6505:fd25:5d3:3087)
22:20:03	<qrpnxz>	"docker images are composed of timestamps" ?!?!
22:20:26	→	zer0bitz joins (~zer0bitz@2001:2003:f748:2000:4dbc:af65:e687:45de)
22:21:30	<pareto-optimal-d>	https://mobile.twitter.com/lorenc_dan/status/1343921457143934977
22:22:42	→	kannon joins (~NK@76.243.126.210)
22:23:44	<qrpnxz>	ah, well yes timestamps can make it annoying to easily see that a build is the same
22:23:58	×	ten_finger_typis quits (~ten_finge@adsl-84-226-91-51.adslplus.ch) (Quit: Client closed)
22:24:10	<qrpnxz>	docker images have timestamps, i wouldn't say "are composed of timestamps"
22:24:56	<pareto-optimal-d>	Well you can't guarantee things don't depend on those timestamps, which make it not reproducible right?
22:25:49	<glguy>	these tools all run into the same problems t hat they're only as reproducible as the tools they use can guarantee
22:26:15	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
22:26:25	<qrpnxz>	seems kind of insane to in any way depend on those timestamps, but hypothetically, sure. Would your rather your build reproducibly accidentally work? Or actually see that something utterly insane is happening?
22:26:47	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
22:26:55	<pareto-optimal-d>	Actually qrpnxz I first learned about timestamp issues from debian working towards reproducible builds:
22:26:55	<pareto-optimal-d>	https://lwn.net/Articles/757118/
22:28:35	<qrpnxz>	yes, that was a good effort
22:28:44	<qrpnxz>	lol they got a wobsite: https://isdebianreproducibleyet.com/
22:28:54	×	justsomeguy quits (~justsomeg@user/justsomeguy) (Ping timeout: 244 seconds)
22:30:15	<pareto-optimal-d>	The nixos minimal iso is 100% 😊
22:30:15	<pareto-optimal-d>	https://discourse.nixos.org/t/nixos-unstable-s-iso-minimal-x86-64-linux-is-100-reproducible/13723
22:30:41	<pareto-optimal-d>	Oh wait 99.37 now https://r13y.com/
22:30:52	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds)
22:31:14	<pareto-optimal-d>	s/37/77/
22:31:36	<qrpnxz>	that's nice
22:31:52	→	[itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
22:32:14	<pareto-optimal-d>	So importance of that for me is being able to rule out the whole ugly class of build issues
22:33:05	×	tv quits (~tv@user/tv) (Quit: derp)
22:33:25	→	tv joins (~tv@user/tv)
22:33:36	→	mikoto-chan joins (~mikoto-ch@164.5.249.78)
22:34:50	<pareto-optimal-d>	Or if I absolutely have to do that busy work, I can take solace in the fact that no one else will have to in the entire community.
22:36:28	×	[itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
22:36:45	→	[itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
22:50:48	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
22:51:28	×	MoC quits (~moc@user/moc) (Quit: Konversation terminated!)
22:52:54	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
22:55:20	×	phma quits (phma@2001:5b0:210d:2468:ee36:3a6:50fd:1e95) (Read error: Connection reset by peer)
22:55:41	→	szkl joins (uid110435@id-110435.uxbridge.irccloud.com)
23:00:25	×	kannon quits (~NK@76.243.126.210) (Ping timeout: 244 seconds)
23:02:23	<alexfmpe[m]>	can you have let/where bindings inside of a class instance? I'd like to be able to share big chunks of implementation between two methods but only on a few specific instances, so factoring it out into a new method doesn't make sense.
23:02:23	<alexfmpe[m]>	The alternative would be having silly named utils at the module scope for the benefit of their respective instances
23:03:32	<geekosaur>	no
23:04:05	→	merijn joins (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
23:07:04	×	mjs2600_ quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 268 seconds)
23:08:19	×	wonko quits (~wjc@2a0e:1c80:2::130) (Ping timeout: 248 seconds)
23:09:32	×	merijn quits (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
23:09:42	×	aeka quits (~aeka@2606:6080:2001:6:e14e:c3f3:8562:6916) (Ping timeout: 244 seconds)
23:13:23	→	Guest4172 joins (~chenqisu1@183.217.200.212)
23:16:31	×	matthewmosior quits (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
23:18:08	→	phma joins (~phma@host-67-44-208-66.hnremote.net)
23:21:01	×	eikke quits (~NicolasT@user/NicolasT) (Ping timeout: 255 seconds)
23:21:04	×	Tuplanolla quits (~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) (Quit: Leaving.)
23:22:09	→	jmorris joins (uid537181@id-537181.uxbridge.irccloud.com)
23:25:09	→	aeka joins (~aeka@user/hiruji)
23:30:36	→	matthewmosior joins (~matthewmo@173.170.253.91)
23:34:50	×	eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
23:37:56	→	shapr joins (~user@76.73.156.98)
23:43:11	×	euandreh quits (~euandreh@179.214.113.107) (Ping timeout: 260 seconds)
23:44:52	→	euandreh joins (~euandreh@179.214.113.107)
23:47:37	×	themc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection)
23:47:55	×	geekosaur quits (~geekosaur@xmonad/geekosaur) (Quit: Leaving)
23:48:06	→	eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
23:48:30	→	asd1123 joins (~asd112345@2001:999:250:841b:41b5:1bba:4b73:1c6a)
23:49:57	×	asd1123 quits (~asd112345@2001:999:250:841b:41b5:1bba:4b73:1c6a) (Quit: Leaving)
23:50:46	×	segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds)
23:51:22	→	justsomeguy joins (~justsomeg@user/justsomeguy)
23:52:00	→	jero98772 joins (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff)
23:54:10	→	segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
23:58:19	→	talismanick joins (~talismani@c-67-174-251-163.hsd1.ca.comcast.net)

All times are in UTC on 2022-08-28.