Logs on 2025-05-18 (liberachat/#haskell)

00:02:51	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
00:03:11	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
00:03:46	×	jespada quits (~jespada@r179-25-150-22.dialup.adsl.anteldata.net.uy) (Ping timeout: 252 seconds)
00:05:36	×	acidjnk quits (~acidjnk@p200300d6e71c4f65f1ead88f57001215.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
00:08:02	×	sprotte24 quits (~sprotte24@p200300d16f06fd00c9f6fa4fdf16930b.dip0.t-ipconnect.de) (Quit: Leaving)
00:12:17	×	Tuplanolla quits (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
00:14:52	→	craunts joins (~craunts@136.158.8.87)
00:32:06	×	Guest57 quits (~Guest11@syn-024-165-041-231.res.spectrum.com) (Ping timeout: 240 seconds)
00:32:59	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
00:33:20	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
00:34:00	×	ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds)
00:35:57	→	Guest11 joins (~Guest11@syn-024-165-041-231.res.spectrum.com)
00:47:06	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
00:47:28	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
00:53:27	×	harveypwca quits (~harveypwc@2601:246:d080:f6e0:27d6:8cc7:eca9:c46c) (Quit: Leaving)
00:55:37	×	Square2 quits (~Square@user/square) (Ping timeout: 265 seconds)
00:59:48	<sm>	watch = ["util", "exec", "--", "sh", "-c", """
00:59:49	<sm>	watchexec --wrap-process=session --no-vcs-ignore --ignore .jj/working_copy/working_copy.lock -c clear --bell "date; echo; jj --no-pager $@"
00:59:49	<sm>	""", ""]
01:01:49	×	end quits (~end@user/end/x-0094621) (Ping timeout: 252 seconds)
01:02:10	×	bcksl quits (~bcksl@user/bcksl) (Ping timeout: 260 seconds)
01:02:47	×	sus0 quits (zero@user/zeromomentum) (Ping timeout: 252 seconds)
01:05:41	<sm>	I forgot a `--watch .jj` in there, more efficient
01:06:05	<sm>	now I can have an updating log, op log etc like in Martin's video
01:09:59	<sm>	and I can keep an eye on what other jj tools (like VJJ) are doing
01:10:29	×	peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
01:11:11	→	peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
01:25:17	→	craunts7 joins (~craunts@136.158.8.87)
01:25:22	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
01:25:44	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
01:26:11	→	bcksl joins (~bcksl@user/bcksl)
01:27:06	×	craunts quits (~craunts@136.158.8.87) (Ping timeout: 252 seconds)
01:27:07	craunts7	is now known as craunts
01:27:10	×	ttybitnik quits (~ttybitnik@user/wolper) (Quit: Fading out...)
01:27:12	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
01:31:14	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
01:31:35	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
01:35:21	→	end joins (~end@user/end/x-0094621)
01:36:21	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
01:41:40	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
01:44:55	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
01:45:16	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
01:46:09	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
01:48:30	→	hiecaq joins (~hiecaq@user/hiecaq)
01:54:54	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
01:58:03	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
02:01:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
02:01:46	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
02:05:03	×	op_4 quits (~tslil@user/op-4/x-9116473) (Remote host closed the connection)
02:05:39	→	op_4 joins (~tslil@user/op-4/x-9116473)
02:05:47	→	joeyadams joins (~textual@syn-162-154-010-038.res.spectrum.com)
02:14:06	×	manwithluck quits (~manwithlu@2a09:bac5:5082:2387::38a:10) (Ping timeout: 276 seconds)
02:14:09	×	td_ quits (~td@i53870928.versanet.de) (Ping timeout: 245 seconds)
02:16:02	→	td_ joins (~td@i5387091A.versanet.de)
02:16:14	<ski>	oh .. sorry, for some reason i missed the paste, Leary
02:19:19	<Leary>	No worries.
02:24:02	→	JuanDaugherty joins (~juan@user/JuanDaugherty)
02:25:11	×	gmg quits (~user@user/gehmehgeh) (Remote host closed the connection)
02:29:14	<ski>	i was reminded of `IVar's, but it doesn't look like what you're doing is that similar to that (except `Identified', slightly)
02:31:30	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
02:31:52	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
02:40:33	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
02:46:33	×	peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
02:54:47	×	JuanDaugherty quits (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
02:55:49	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
02:56:09	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
03:00:32	×	bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Read error: Connection reset by peer)
03:00:32	×	chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
03:00:32	×	chiselfuse quits (~chiselfus@user/chiselfuse) (Remote host closed the connection)
03:00:32	×	califax quits (~califax@user/califx) (Remote host closed the connection)
03:00:32	×	ChaiTRex quits (~ChaiTRex@user/chaitrex) (Remote host closed the connection)
03:00:52	→	califax joins (~califax@user/califx)
03:00:55	→	bitdex joins (~bitdex@gateway/tor-sasl/bitdex)
03:00:58	→	chexum joins (~quassel@gateway/tor-sasl/chexum)
03:01:02	→	ChaiTRex joins (~ChaiTRex@user/chaitrex)
03:01:10	→	chiselfuse joins (~chiselfus@user/chiselfuse)
03:01:45	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
03:04:11	×	Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds)
03:05:24	×	ystael quits (~ystael@user/ystael) (Ping timeout: 245 seconds)
03:13:32	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
03:16:21	→	peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
03:16:22	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
03:19:56	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
03:33:31	→	aforemny joins (~aforemny@i59F4C598.versanet.de)
03:33:35	×	Unicorn_Princess quits (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
03:35:14	×	aforemny_ quits (~aforemny@2001:9e8:6ce3:4b00:63e7:2449:7739:bbf2) (Ping timeout: 272 seconds)
03:42:31	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
03:43:08	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Client Quit)
03:47:26	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
03:48:54	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
03:49:14	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
03:56:02	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
03:56:24	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:02:05	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:02:27	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:08:37	×	poscat quits (~poscat@user/poscat) (Remote host closed the connection)
04:11:39	→	poscat joins (~poscat@user/poscat)
04:16:36	→	j1n37- joins (~j1n37@user/j1n37)
04:17:04	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
04:17:35	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 260 seconds)
04:17:52	→	haskellbridge joins (~hackager@syn-096-028-224-255.res.spectrum.com)
04:17:52	ChanServ	sets mode +v haskellbridge
04:21:53	→	j1n37 joins (~j1n37@user/j1n37)
04:22:07	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:22:27	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:22:44	×	haskellbridge quits (~hackager@syn-096-028-224-255.res.spectrum.com) (Ping timeout: 272 seconds)
04:23:00	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 252 seconds)
04:23:42	×	Guest11 quits (~Guest11@syn-024-165-041-231.res.spectrum.com) (Ping timeout: 240 seconds)
04:24:12	→	haskellbridge joins (~hackager@syn-096-028-224-255.res.spectrum.com)
04:24:12	ChanServ	sets mode +v haskellbridge
04:25:32	<geekosaur>	network back, IP address changed so matrix-side may be a little flaky until the new one propagates
04:28:53	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
04:30:20	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:30:42	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:36:26	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:36:47	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:42:14	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:42:34	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:45:24	×	Nosrep quits (~Nosrep@user/nosrep) (Ping timeout: 245 seconds)
04:48:59	<sm>	hurrah!
04:50:29	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:50:50	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
04:52:23	→	Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915)
04:55:25	→	Frostillicus joins (~Frostilli@71.174.119.69)
04:56:19	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
04:56:40	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
05:00:10	×	Frostillicus quits (~Frostilli@71.174.119.69) (Ping timeout: 260 seconds)
05:01:05	×	jmcantrell quits (~weechat@user/jmcantrell) (Quit: WeeChat 4.6.2)
05:07:18	×	joeyadams quits (~textual@syn-162-154-010-038.res.spectrum.com) (Quit: Textual IRC Client: www.textualapp.com)
05:07:43	→	robobub joins (uid248673@id-248673.uxbridge.irccloud.com)
05:14:40	<haskellbridge>	<magic_rb> i seem to recall some people hosted these temporary file sharing services and those would work, they all skipped my mind though just now
05:14:42	<haskellbridge>	<sm> matrix ?
05:14:42	<haskellbridge>	<sm> or https://pub.microbin.eu ?
05:14:42	<haskellbridge>	<magic_rb> https://pub.microbin.eu/upload/zebra-eagle this works
05:14:42	<haskellbridge>	<sm> excellent pastebin
05:14:42	<haskellbridge>	<magic_rb> dmjio i was talking about the photo thing right, so that is how it looks now
05:14:42	<haskellbridge>	<magic_rb> you can tag photos, rename them, javascript free
05:14:44	<haskellbridge>	<magic_rb> and its stored in git+git-annex
05:14:45	<haskellbridge>	<magic_rb> https://paste.tomsmeding.com/fxesVbzl like that
05:14:47	<haskellbridge>	<magic_rb> the database is just a cache for the toml files and can be evicted at any point
05:14:48	<haskellbridge>	<sm> test
05:21:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
05:21:46	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
05:25:51	×	craunts quits (~craunts@136.158.8.87) (Quit: Ping timeout (120 seconds))
05:26:06	→	craunts joins (~craunts@136.158.8.87)
05:33:02	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
05:36:44	→	j1n37- joins (~j1n37@user/j1n37)
05:36:50	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 272 seconds)
05:38:19	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
05:38:41	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
05:44:22	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
05:44:44	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
05:45:39	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
05:50:26	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
05:50:52	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
05:52:28	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
05:57:22	×	euleritian quits (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Remote host closed the connection)
05:57:46	→	euleritian joins (~euleritia@77.23.248.100)
05:57:57	×	euleritian quits (~euleritia@77.23.248.100) (Remote host closed the connection)
06:00:21	×	craunts quits (~craunts@136.158.8.87) (Ping timeout: 248 seconds)
06:01:14	→	euleritian joins (~euleritia@77.23.248.100)
06:01:30	→	wootehfoot joins (~wootehfoo@user/wootehfoot)
06:02:26	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
06:02:49	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
06:03:52	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
06:09:42	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
06:09:55	×	euleritian quits (~euleritia@77.23.248.100) (Remote host closed the connection)
06:10:19	→	euleritian joins (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
06:16:30	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
06:16:57	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
06:20:36	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
06:25:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
06:25:47	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
06:26:14	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
06:36:39	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
06:37:56	→	werneta joins (~werneta@syn-071-083-160-242.res.spectrum.com)
06:45:01	→	j1n37 joins (~j1n37@user/j1n37)
06:45:11	→	craunts joins (~craunts@136.158.8.87)
06:45:24	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 245 seconds)
06:48:44	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
06:49:05	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
06:50:09	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
06:51:16	×	craunts quits (~craunts@136.158.8.87) (Read error: Connection reset by peer)
06:51:38	→	craunts joins (~craunts@136.158.8.87)
06:52:06	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
06:56:34	×	craunts quits (~craunts@136.158.8.87) (Ping timeout: 252 seconds)
07:00:00	×	caconym7 quits (~caconym@user/caconym) (Quit: bye)
07:00:39	→	caconym7 joins (~caconym@user/caconym)
07:05:21	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Ping timeout: 248 seconds)
07:07:30	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
07:08:49	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
07:09:10	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
07:13:43	→	craunts joins (~craunts@136.158.8.87)
07:14:36	×	poscat quits (~poscat@user/poscat) (Remote host closed the connection)
07:16:15	→	poscat joins (~poscat@user/poscat)
07:17:38	×	craunts quits (~craunts@136.158.8.87) (Client Quit)
07:18:52	×	peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds)
07:23:06	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
07:23:28	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
07:29:50	→	Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
07:31:59	→	j1n37- joins (~j1n37@user/j1n37)
07:32:03	→	ljdarj joins (~Thunderbi@user/ljdarj)
07:32:36	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 276 seconds)
07:36:35	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
07:36:58	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
07:37:15	→	Digit joins (~user@user/digit)
07:41:03	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
07:44:54	→	acidjnk joins (~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de)
07:47:09	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
07:47:32	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
07:50:56	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
07:51:17	×	ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds)
07:52:18	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
07:59:23	×	weary-traveler quits (~user@user/user363627) (Remote host closed the connection)
08:00:25	→	sus0 joins (zero@user/zeromomentum)
08:02:29	→	Tuplanolla joins (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi)
08:03:59	<haskellbridge>	<sm> what's Haskell's killer domain, for https://news.ycombinator.com/item?id=44018922 ?
08:05:40	×	Digit quits (~user@user/digit) (Ping timeout: 260 seconds)
08:05:58	<haskellbridge>	<sm> "high-assurance computing and prototyping/research"
08:06:28	<Rembane>	Also parsers and compilers
08:06:32	<haskellbridge>	<hellwolf> ecosystem of PL nerds
08:06:57	<Rembane>	And research in lazily evaluated programming languages
08:09:37	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
08:09:59	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
08:17:08	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
08:17:29	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
08:18:17	<haskellbridge>	<maerwald> High assurance computing?
08:18:41	<haskellbridge>	<maerwald> GHC and its RTS are underspecified black boxes
08:19:39	<haskellbridge>	<sm> better: "High assurance applications and prototyping/research"
08:20:33	<haskellbridge>	<sm> this is in context of the above article, where each language gets 4-6 words for a general audience
08:21:37	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
08:21:42	<haskellbridge>	<sm> * 1-6
08:23:53	→	__monty__ joins (~toonn@user/toonn)
08:26:51	→	ljdarj joins (~Thunderbi@user/ljdarj)
08:29:55	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
08:32:12	×	tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
08:42:57	→	JuanDaugherty joins (~juan@user/JuanDaugherty)
08:42:58	×	Frostillicus quits (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
08:43:21	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
08:43:42	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
08:47:24	→	Digit joins (~user@user/digit)
08:51:40	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
08:52:00	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
08:56:50	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
09:02:04	→	Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
09:03:24	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
09:03:45	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
09:04:31	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
09:06:12	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
09:08:07	→	srazkvt joins (~sarah@user/srazkvt)
09:15:44	→	gmg joins (~user@user/gehmehgeh)
09:17:45	×	JuanDaugherty quits (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
09:19:54	→	j1n37 joins (~j1n37@user/j1n37)
09:21:06	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 252 seconds)
09:23:44	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
09:24:05	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
09:29:21	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
09:29:43	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
09:36:40	×	Frostillicus quits (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 260 seconds)
09:39:49	→	Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
09:40:19	→	lxsameer joins (~lxsameer@Serene/lxsameer)
09:44:11	<lxsameer>	hey folks, how do you model a data type with one constructor, in such a way that every value of that type is a distinct value, so no two value are equal? the constructor does not take any input. it's literally `data X = X`
09:45:38	<lxsameer>	for example, in an implementation of this type in an imperative lang, they just left it to the memory manager to choose a distinct address for each new value
09:45:50	<lxsameer>	and compare elements of this type based on their address
09:47:00	<tomsmeding>	lxsameer: give it an Int field, don't export the constructor, and expose a smart constructor that increments a global IORef?
09:47:14	<tomsmeding>	obligatory warning: use atomicModifyIORef', and put NOINLINE on functions with unsafePerformIO
09:47:19	×	Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer)
09:47:47	<lxsameer>	tomsmeding: thank you
09:48:42	→	j1n37- joins (~j1n37@user/j1n37)
09:48:58	×	econo_ quits (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
09:49:24	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 244 seconds)
09:50:09	×	Frostillicus quits (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 248 seconds)
09:50:37	<mauke>	instance Eq X where _ == _ = False
09:53:38	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
09:54:02	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
09:55:56	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
10:02:30	<lxsameer>	mauke: a value is still equal to itself
10:04:11	<mauke>	equal in what sense?
10:04:34	<lxsameer>	sameness
10:09:22	<mauke>	what does that mean
10:10:01	<lxsameer>	a = X; b = X; c = a; a /= b; a == c
10:10:04	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
10:13:27	<mauke>	oh, you want it to be equal
10:13:43	<mauke>	yeah, that's not a thing
10:15:40	×	turlando quits (~turlando@user/turlando) (Quit: No Ping reply in 180 seconds.)
10:16:14	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
10:16:35	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
10:16:56	→	turlando joins (~turlando@user/turlando)
10:20:38	×	notzmv quits (~daniel@user/notzmv) (Ping timeout: 265 seconds)
10:21:59	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
10:22:21	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
10:34:37	×	ChaiTRex quits (~ChaiTRex@user/chaitrex) (Remote host closed the connection)
10:35:01	→	ChaiTRex joins (~ChaiTRex@user/chaitrex)
10:35:23	<tomsmeding>	the fact that you need ugliness like unsafePerformIO in my suggestion shows what you're asking for :p
10:35:39	<lxsameer>	ah haskell has a Unique type too
10:35:46	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
10:36:08	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
10:36:13	<lxsameer>	essentially it seems like the same thing that tomsmeding suggested
10:36:28	<tomsmeding>	yes, but you still need to write the unsafePerformIO yourself
10:36:51	<tomsmeding>	well here is indeed precisely what I suggested, lol https://hackage.haskell.org/package/ghc-internal-9.1201.0/docs/src/GHC.Internal.Data.Unique.html#Unique
10:37:04	<tomsmeding>	except you probably need another unsafePerformIO around newUnique
10:38:18	<tomsmeding>	the comments below newUnique are interesting to read: apparently it was an MVar before, then it became STM, and then it became an IORef
10:38:55	<tomsmeding>	given current state of things in GHC Haskell, I would never even consider using something else than an IORef, but because these things harken from >12 years ago, perhaps the runtime behaved differently
10:40:12	×	wootehfoot quits (~wootehfoo@user/wootehfoot) (Ping timeout: 272 seconds)
10:40:45	<Rembane>	So things became less and less safe and faster and faster over time?
10:40:56	×	euleritian quits (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds)
10:41:22	→	euleritian joins (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
10:44:18	<lxsameer>	hmmmm but i think it's better to rethink the approach
10:44:31	→	wootehfoot joins (~wootehfoo@user/wootehfoot)
10:46:08	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
10:46:37	×	euleritian quits (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
10:46:55	→	euleritian joins (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
10:48:43	<tomsmeding>	Rembane: why less safe?
10:49:27	<tomsmeding>	the move from MVar to STM lost fairness; I would not call that "safety", but it's perhaps close enough. But STM -> IORef doesn't lose anything
10:49:38	<Rembane>	tomsmeding: Maybe I have misunderstood everything but I thought MVar was more safe than STM that was more safe than IORef, but I don't know why. So it might just be something I got wrong.
10:49:41	<tomsmeding>	(in this particular application)
10:49:47	<Rembane>	Got it!
10:49:53	<lxsameer>	tomsmeding: no, I'm trying to port a legacy code (which is in very old scheme) to haskell, what is happening there is not necessarily the right way to implement it in haskell
10:50:08	<lxsameer>	ah sorry, it wasn't for me
10:50:41	<tomsmeding>	Rembane: MVar is a mutable variable with guaranteed FIFO queueing; STM is optimistic concurrency that has various sources of overhead but avoids locking in the happy path of no contention
10:50:43	→	LainIwakura joins (~LainIwaku@user/LainIwakura)
10:50:58	<tomsmeding>	STM doesn't give any concurrency guarantees, just the observation that in practice it works really well
10:51:07	<tomsmeding>	IORef is just... a mutable thing
10:51:22	<Rembane>	tomsmeding: Maybe that's the point. Hm... because I've learned them in the context of concurrency.
10:51:24	<tomsmeding>	it seems to me that "obviously" atomicModifyIORef' is the fastest
10:51:37	<tomsmeding>	it does just an atomic update, whereas MVar and STM do a whole lot more
10:51:45	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
10:52:07	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
10:52:20	<tomsmeding>	lxsameer: I'm not saying you're doing the wrong thing, just indicating that what you're doing isn't very haskell-like, and the language complains by making you do ugly things. :)
10:52:54	tomsmeding	works almost daily with programs that use this particular ID generation trick, so I'm tainted too
10:52:55	<lxsameer>	tomsmeding: that's a good summary of it
10:54:14	<tomsmeding>	Rembane: I learned them in the context of concurrency too! Specifically, in the context of having to teach concurrency to bachelor students in a course that uses haskell :p
10:54:26	<tomsmeding>	(I knew them decently well before that, but more in detail now)
10:54:43	→	fp1 joins (~Thunderbi@hof1.kyla.fi)
10:55:01	<Rembane>	tomsmeding: That's a really good trick to learn something! :D
10:55:07	<tomsmeding>	it is :)
10:55:14	<tomsmeding>	just a bit hard to pull off, sometimes
10:55:34	<Rembane>	Totally. "Hi there friends, of course you want to learn this complicated thing..."
10:56:50	<tomsmeding>	Rembane: in some senses, STM is safer than MVar: you get actual transactions that act like transactions, in that they're atomic; with MVars, you have to do the work yourself so that you don't get into deadlocks
10:57:14	<tomsmeding>	you can do the classical thing of having two MVars, A and B, and have thread 1 lock A and then B, and have thread 2 lock B and then A
10:57:18	<tomsmeding>	voilà, deadlock
10:57:20	<Rembane>	\œ/
10:57:43	<Rembane>	tomsmeding: It just struck me that it's such a luxury to have proper transactions outside of a database.
10:57:47	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
10:58:07	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
10:58:21	<tomsmeding>	on the other hand, MVar gives you fairness, whereas with STM, if you have very long transactions and multiple of those are trying to run concurrently, they can restart and restart and restart and never actually finish
10:58:45	<tomsmeding>	there is always a probability of one finishing and getting out of the livelock, but it can take a while in the absolute worst case
10:59:10	×	troydm quits (~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset)
10:59:23	<tomsmeding>	Rembane: it is absolutely a luxury, and it's almost impossible to do it with a sensible API in a non-pure langugae
10:59:28	<tomsmeding>	so haskell is blessed :)
10:59:44	<Rembane>	tomsmeding: It's so good. :D
11:00:25	→	zlqrvx joins (~zlqrvx@2001:8003:8c8b:e00:374a:bdcb:457c:d1e3)
11:01:44	→	jespada joins (~jespada@r167-61-146-44.dialup.adsl.anteldata.net.uy)
11:03:39	×	euleritian quits (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds)
11:05:22	→	euleritian joins (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
11:07:49	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
11:07:56	×	LainIwakura quits (~LainIwaku@user/LainIwakura) (Quit: Client closed)
11:08:11	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
11:13:54	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
11:25:21	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
11:30:47	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
11:33:09	×	lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds)
11:50:41	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 248 seconds)
11:52:06	→	j1n37 joins (~j1n37@user/j1n37)
11:59:10	×	euleritian quits (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
11:59:43	→	euleritian joins (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
12:03:13	×	euphores quits (~SASL_euph@user/euphores) (Quit: Leaving.)
12:05:07	×	rvalue quits (~rvalue@user/rvalue) (Ping timeout: 252 seconds)
12:06:28	→	rvalue- joins (~rvalue@user/rvalue)
12:06:56	rvalue-	is now known as rvalue
12:12:18	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
12:15:10	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
12:15:32	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
12:18:11	→	euphores joins (~SASL_euph@user/euphores)
12:28:06	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
12:34:00	×	jespada quits (~jespada@r167-61-146-44.dialup.adsl.anteldata.net.uy) (Ping timeout: 260 seconds)
12:36:16	×	euleritian quits (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Remote host closed the connection)
12:36:37	→	euleritian joins (~euleritia@77.23.248.100)
12:38:08	→	Digitteknohippie joins (~user@user/digit)
12:39:09	×	Digit quits (~user@user/digit) (Ping timeout: 245 seconds)
12:39:21	→	jespada joins (~jespada@r186-48-57-38.dialup.adsl.anteldata.net.uy)
12:40:19	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
12:46:25	×	img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
12:47:44	→	img joins (~img@user/img)
12:51:16	×	euleritian quits (~euleritia@77.23.248.100) (Ping timeout: 244 seconds)
12:51:36	→	euleritian joins (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
12:54:31	×	euleritian quits (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
12:54:50	→	euleritian joins (~euleritia@77.23.248.100)
13:04:20	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
13:04:43	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
13:07:20	×	fp1 quits (~Thunderbi@hof1.kyla.fi) (Ping timeout: 252 seconds)
13:09:22	→	lxsameer joins (~lxsameer@Serene/lxsameer)
13:11:23	Digitteknohippie	is now known as Digit
13:11:43	×	FragByte quits (~christian@user/fragbyte) (Quit: Quit)
13:13:42	→	FragByte joins (~christian@user/fragbyte)
13:15:23	×	euleritian quits (~euleritia@77.23.248.100) (Ping timeout: 252 seconds)
13:16:14	→	Square2 joins (~Square@user/square)
13:17:53	→	euleritian joins (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
13:19:03	×	img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
13:20:22	→	img joins (~img@user/img)
13:24:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
13:24:47	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
13:27:25	×	wickedjargon quits (~user@2001:569:fc3c:d000:49fd:4f0f:5c90:505) (Remote host closed the connection)
13:28:57	→	ttybitnik joins (~ttybitnik@user/wolper)
13:29:50	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
13:32:28	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
13:32:51	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
13:34:06	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.5.2)
13:34:17	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:39:35	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.5.2)
13:39:44	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:40:54	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:41:03	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:41:15	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:42:16	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:43:40	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:43:50	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:44:57	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:45:19	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:45:44	→	Guest45 joins (~Guest45@2a00:9fe0:0:c::1:102a)
13:46:02	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
13:51:15	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.5.2)
13:52:16	→	Nosrep joins (~Nosrep@user/nosrep)
13:52:21	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:52:45	×	acidjnk quits (~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
13:53:55	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:54:05	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:54:23	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:54:34	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
13:54:55	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
13:55:02	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:55:24	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:55:34	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:56:33	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:56:54	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
13:57:15	×	GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Client Quit)
13:57:34	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
13:59:14	×	pavonia quits (~user@user/siracusa) (Quit: Bye!)
14:05:08	→	tinjamin4 joins (~tinjamin@banshee.h4x0r.space)
14:10:49	→	Digitteknohippie joins (~user@user/digit)
14:11:52	×	Digit quits (~user@user/digit) (Ping timeout: 244 seconds)
14:20:37	×	lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 248 seconds)
14:25:24	×	Digitteknohippie quits (~user@user/digit) (Ping timeout: 245 seconds)
14:25:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
14:25:45	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
14:29:46	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
14:29:51	×	gmg quits (~user@user/gehmehgeh) (Remote host closed the connection)
14:30:11	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
14:33:59	→	sajenim joins (~sajenim@user/sajenim)
14:34:06	<sajenim>	#join #kernel
14:34:11	<sajenim>	sorry
14:42:49	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
14:43:14	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
14:46:45	→	Digit joins (~user@user/digit)
14:53:54	→	michalz joins (~michalz@185.246.207.221)
14:58:21	Digit	is now known as digitteknohippie
14:58:44	digitteknohippie	is now known as Digit
15:01:27	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
15:08:54	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
15:09:15	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
15:12:37	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
15:14:55	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
15:15:16	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
15:22:36	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
15:22:58	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
15:23:21	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
15:28:44	×	Guest45 quits (~Guest45@2a00:9fe0:0:c::1:102a) (Quit: Client closed)
15:35:01	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
15:35:22	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
15:43:09	→	lxsameer joins (~lxsameer@Serene/lxsameer)
15:48:17	×	hiecaq quits (~hiecaq@user/hiecaq) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.0.92))
15:50:07	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
15:50:29	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
15:51:12	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
16:05:09	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
16:05:33	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
16:06:16	×	lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds)
16:07:36	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
16:10:44	×	euleritian quits (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
16:11:01	→	euleritian joins (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
16:17:34	→	j1n37- joins (~j1n37@user/j1n37)
16:17:54	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 245 seconds)
16:22:05	→	j1n37 joins (~j1n37@user/j1n37)
16:23:08	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 252 seconds)
16:27:17	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
16:27:38	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
16:31:11	×	euleritian quits (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
16:35:15	×	srazkvt quits (~sarah@user/srazkvt) (Quit: Konversation terminated!)
16:35:16	→	euleritian joins (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
16:39:18	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
16:39:41	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
16:45:09	→	ljdarj1 joins (~Thunderbi@user/ljdarj)
16:45:09	×	Pozyomka quits (~pyon@user/pyon) (Ping timeout: 248 seconds)
16:45:22	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
16:45:31	×	euleritian quits (~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
16:45:43	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
16:46:26	→	euleritian joins (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
16:47:49	→	lxsameer joins (~lxsameer@Serene/lxsameer)
16:49:14	×	ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
16:49:14	ljdarj1	is now known as ljdarj
16:50:22	→	euouae joins (~euouae@user/euouae)
16:51:03	<euouae>	Hello I have a project where I read stuff from a "stream" (I call it that) and then I either: 1) output or 2) prepend to "stream" for subsequent reads.
16:51:28	<euouae>	What I want to ask is if Haskell has something that I can use that does this already, a sort of byte deque.
16:52:03	<euouae>	What I thought about doing is using a list of strings and a lens to treat them as one string
16:54:55	→	Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
16:57:08	<euouae>	Nevermind I guess that's what I'll do :)
16:57:08	×	euouae quits (~euouae@user/euouae) ()
16:59:15	×	tomboy64 quits (~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
16:59:29	→	tomboy64 joins (~tomboy64@user/tomboy64)
16:59:53	→	acidjnk joins (~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de)
17:01:43	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
17:02:03	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
17:02:17	×	robertm quits (robertm@lattice.rojoma.com) (Quit: ,,,)
17:05:08	→	robertm joins (robertm@lattice.rojoma.com)
17:07:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
17:07:48	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
17:11:10	×	Frostillicus quits (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
17:17:22	→	notzmv joins (~daniel@user/notzmv)
17:23:35	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
17:23:57	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
17:24:19	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
17:26:17	→	ystael joins (~ystael@user/ystael)
17:29:21	×	tomboy64 quits (~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
17:29:29	→	tomboy65 joins (~tomboy64@user/tomboy64)
17:30:25	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
17:30:46	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
17:36:07	→	j1n37- joins (~j1n37@user/j1n37)
17:37:01	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 276 seconds)
17:37:12	×	Nosrep quits (~Nosrep@user/nosrep) (Ping timeout: 252 seconds)
17:41:57	→	peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
17:44:44	<__monty__>	@tell euouae Consider looking at Data.Sequence for double-ended operations.
17:44:44	<lambdabot>	Consider it noted.
17:45:26	→	tzh joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net)
17:46:21	→	Sgeo joins (~Sgeo@user/sgeo)
17:47:54	<monochrom>	Although, it is not very fast.
17:47:57	→	tromp joins (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
17:49:57	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
17:50:21	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
17:55:49	×	euleritian quits (~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
17:56:57	→	euleritian joins (~euleritia@77.23.248.100)
17:58:07	→	Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542)
17:58:47	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
17:59:08	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
17:59:14	×	tomboy65 quits (~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
17:59:29	→	tomboy64 joins (~tomboy64@user/tomboy64)
18:07:53	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
18:08:17	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
18:13:57	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
18:14:19	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
18:16:04	→	jmcantrell joins (~weechat@user/jmcantrell)
18:16:45	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
18:27:18	×	peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
18:27:46	→	peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
18:29:12	×	tomboy64 quits (~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
18:29:29	→	tomboy64 joins (~tomboy64@user/tomboy64)
18:29:39	×	jmcantrell quits (~weechat@user/jmcantrell) (Ping timeout: 260 seconds)
18:29:41	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
18:32:17	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
18:32:39	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
18:41:10	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
18:41:32	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
18:42:42	→	sprotte24 joins (~sprotte24@p200300d16f0fc00010c55f6c38487736.dip0.t-ipconnect.de)
18:45:01	×	peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
18:46:10	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 260 seconds)
18:46:22	→	j1n37 joins (~j1n37@user/j1n37)
18:50:04	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
18:50:27	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
18:53:28	→	bitmapper joins (uid464869@id-464869.lymington.irccloud.com)
18:53:28	→	GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano)
18:55:33	<__monty__>	Neither is `[String]` for operations on both ends though.
18:55:41	<__monty__>	It's plenty fast for AoC : )
18:59:07	→	peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
19:00:03	×	caconym7 quits (~caconym@user/caconym) (Quit: bye)
19:00:42	→	caconym7 joins (~caconym@user/caconym)
19:01:26	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
19:01:49	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:03:22	×	peterbecich quits (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
19:07:42	→	target_i joins (~target_i@user/target-i/x-6023099)
19:12:27	→	Digitteknohippie joins (~user@user/digit)
19:12:27	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
19:12:48	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:13:50	×	Digit quits (~user@user/digit) (Ping timeout: 272 seconds)
19:19:32	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
19:19:54	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:21:05	→	gmg joins (~user@user/gehmehgeh)
19:24:01	×	infinity0 quits (~infinity0@pwned.gg) (Ping timeout: 252 seconds)
19:30:34	Digitteknohippie	is now known as Digit
19:32:18	→	j1n37- joins (~j1n37@user/j1n37)
19:32:39	×	wootehfoot quits (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
19:32:43	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 244 seconds)
19:33:34	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
19:33:57	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:38:25	<[exa]>	is there any technical difference between packages OpenGLRaw and gl ? The FFI code looks kinda confusingly same to me, I expected I'd be able to see at least something that's different
19:39:54	→	pavonia joins (~user@user/siracusa)
19:41:03	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
19:41:23	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:44:41	→	infinity0 joins (~infinity0@pwned.gg)
19:46:26	<EvanR>	both OpenGLRaw and gl are supposed to be a direct reflection of the C api
19:46:42	<EvanR>	so I expect no difference if they both achieved
19:47:05	<EvanR>	why do we need two, not sure, but OpenGLRaw originally didn't exist
19:47:31	<EvanR>	I mean we don't need two, but why did OpenGLRaw happen I don't know
19:47:40	<[exa]>	like, gl seems a lil more organized
19:47:50	<[exa]>	but that's it
19:48:05	<[exa]>	I expected e.g. some radically different way to get the gl function pointers or so
19:48:14	<EvanR>	that would be OpenGL not-Raw
19:48:19	<EvanR>	it's radically different
19:49:05	→	Pozyomka joins (~pyon@user/pyon)
19:49:45	<[exa]>	nah the OpenGL is very wrapped
19:51:19	<[exa]>	ok anyway I just wanted to change the way the ffi is done a very little and see if it explodes
19:51:29	<[exa]>	gl rebuilds itself automatically -> win
19:51:44	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
19:52:04	×	lxsameer quits (~lxsameer@Serene/lxsameer) (Ping timeout: 245 seconds)
19:52:07	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:58:43	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
19:59:04	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
19:59:10	<[exa]>	and whoa, it works
20:00:11	<[exa]>	is there anything very wrong about marking FFI imports in an essentially singlethreaded application as `unsafe` ?
20:01:31	<tomsmeding>	[exa]: unsafe is, ironically, typically the safer option
20:01:55	<tomsmeding>	GHC guarantees that the GC will not run during an unsafe FFI call
20:01:57	<[exa]>	for me it somehow kills like 80% of the call overhead
20:02:13	<tomsmeding>	so you can pass unpinned stuff to C and they won't move under C's feeet
20:02:22	<bwe>	I am loading a couple of hundred HTML files from SQLite DB, perform some parsing on them, creating a result data type from them. For this I fmap over all result rows of a SQL select. This exhausts the memory, the OS kills ghci altogether. -- It appears that after each entry is processed, the garbage collection does not happen. Solution would be using some streaming framework. But this is another rabbit hole (I want to avoid to open).
20:02:23	<bwe>	-- Which alternatives to streaming frameworks do you recommend to let the garbage collection happen after each entry of a list has been processed?
20:02:35	<tomsmeding>	[exa]: during a 'safe' FFI call, the GC can run; the point of a 'safe' FFI call is that the C you call can _call back to Haskell_
20:02:44	<[exa]>	....which is quite a relief when trying to smash 60 batches of glDrawWhatever calls per second to the GPU.
20:02:50	<[exa]>	yeah
20:02:54	<tomsmeding>	to accomplish this, GHC starts a new capability, which has overhead
20:03:17	<[exa]>	yes, a scary lot of overhead.
20:04:38	<EvanR>	bwe, make sure to evaluate each parse result before going on to the next one
20:04:40	<tomsmeding>	bwe: I feel like this is not due to "GC not running", but because if you return something from IO, that thing gets evaluated first
20:05:11	<tomsmeding>	if that "thing" is a list, that list is not returned in a streaming fashion
20:05:44	<tomsmeding>	if it's a list of IO actions then it's even worse because all the IO actions need to run before the return can happen
20:05:46	<[exa]>	bwe: you can insert the GC call yourself but as pointed out above, it might be that you are accidentally doing a space leak somewhere which GC can't solve
20:05:47	<tomsmeding>	but also check EvanR's suggestion
20:06:01	<tomsmeding>	if you're running out of memory then GC will _definitely_ have attempted to run
20:06:10	<[exa]>	+1 ^
20:06:14	<tomsmeding>	so the fact that you run out of memory proves that manually calling GC will not help
20:06:17	<monochrom>	The worst nightmare is that GC ran and found nothing to free, so you spent both memory and time.
20:06:34	<bwe>	monochrom: that's what I assume is happening.
20:06:49	<EvanR>	well that would require the gc running
20:06:54	<EvanR>	at least once
20:07:10	<tomsmeding>	GC will run every n bytes allocated
20:07:14	<monochrom>	Theorem: A linear-space algorithm takes at least quadratic time in a GCed language. >:)
20:07:17	<tomsmeding>	n < amount of memory in your system
20:07:41	<[exa]>	bwe: btw what's the type of the sql result structure?
20:07:48	<[exa]>	(I suspect selda)
20:09:05	<bwe>	[exa]: loadRawHtmls :: IO [HTML]
20:09:17	<bwe>	[exa]: Confirmed. It's selda.
20:09:56	<[exa]>	can selda stream the results?
20:10:01	<tomsmeding>	that `IO [HTML]` type confirms what I wrote
20:10:30	<bwe>	[exa]: Not out of the box.
20:11:02	<EvanR>	a long list of file contentses is par for the course for web tech. You just need to make sure the results are all fully evaluated and compacted before returning the list
20:11:21	<EvanR>	and for good measure make sure it's not HTML = String
20:11:31	<tomsmeding>	yeah I guess you might try `sequence . fmap (map Control.DeepSeq.force)`
20:11:47	<bwe>	EvanR: I took my time to take your input in :). No, it's Text.
20:12:23	<bwe>	EvanR: So, lazy evaluation waits until full list is completed and only then GC can free the memory.
20:12:25	<EvanR>	a list of 100 big Text should be fine, as long as that's what it is
20:12:31	<EvanR>	no
20:12:47	<tomsmeding>	the IO action only returns when it's done
20:12:56	<[exa]>	bwe: what is your result type, roughly?
20:12:58	<tomsmeding>	it's done when all 100 HTML buffers have been read
20:13:08	<tomsmeding>	hence, all will be live in memory when the `IO [HTML]` action returns
20:13:17	<[exa]>	bwe: a lot of the job can be done by including a few strictness exclamation marks here and there
20:13:26	<monochrom>	It is not going to be as false-dichotomy as "more lazy is less space" or "more lazy is more space" because both have counterexamples.
20:13:29	<[exa]>	also Data.Vector.Strict, Data.Map.Strict, etc etc
20:13:51	<tomsmeding>	bwe: how large are the HTML strings? WOuld simply keeping the 100 strings in memory already be enough to exhaust your memory, or is there something else going on?
20:14:53	<EvanR>	I probably misunderstood, but you can't expect gc to collector strings before they you even start using them (after the IO finishes and returns them)
20:15:00	<EvanR>	collect your*
20:15:05	<bwe>	tomsmeding: 1.5 MB
20:15:18	<tomsmeding>	assuming you don't have a PC from the 90s, that should be okay
20:15:42	<[exa]>	like, that's a bit too much even for a pretty wild space leak
20:15:43	<EvanR>	1.5 MB you exhausted my entire floppy disk
20:16:02	<[exa]>	EvanR: try the bigger floppies I heard they have more space
20:16:06	<EvanR>	lol
20:16:10	<tomsmeding>	% :t traverse @[] Control.Exception.evaluate
20:16:10	<yahb2>	traverse @[] Control.Exception.evaluate :: [b] -> IO [b]
20:16:20	<monochrom>	zip diskettes
20:16:25	<tomsmeding>	bwe: do that to your [HTML]
20:16:41	<tomsmeding>	the @[] is just to make the type here nicer
20:17:07	<mauke>	% :t traverse Control.Exception.evaluate
20:17:07	<yahb2>	traverse Control.Exception.evaluate ; :: Traversable t => t b -> IO (t b)
20:17:21	<mauke>	% :t traverse Control.Exception.evaluate `asAppliedTo` []
20:17:21	<yahb2>	<interactive>:1:37: error: [GHC-88464] ; Variable not in scope: ; asAppliedTo :: (t0 b0 -> IO (t0 b0)) -> [a0] -> t
20:17:50	<mauke>	huh
20:18:35	<bwe>	tomsmeding: The problem is that the function is an IO action because it will only return once it has read all of its input?
20:18:41	<mauke>	then where do I remember that from
20:18:51	<tomsmeding>	surely a function that reads 1.5 MB total will by itself not exhaust memory
20:18:55	<tomsmeding>	there is something going on that we're not seeing
20:19:13	<[exa]>	bwe: just to take a slightly more doubtful approach to the issue you might want to try to process a few smaller fractions of the HTML to see if it stops crashing at some point. Having tiny 1.5MB expanded to OOM seems a bit weird nowadays, instinctively I'd say there might be a corner case where the program actually explodes
20:19:41	tomsmeding	nods
20:19:48	<[exa]>	(as in, some html so weird that it recurses infinitely. e.g. some binary ballast which doesn't parse well.)
20:20:02	<mauke>	I've seen processing ~35 MB of XML take about 2 GB of memory
20:20:20	<bwe>	tomsmeding: I considered profiling a couple of times. But I aborted that mission because it frustrated me to not being able to do it in ghci directly.
20:20:31	<Rembane>	There's the HAHAHA-attack, right?
20:20:42	<mauke>	not an attack
20:21:06	<mauke>	it involved an arrow-based xml parser and keeping everything as Strings
20:21:10	<EvanR>	bwe, a "normal" IO [Text] which gets each Text using I/O will "return" when it built the whole list
20:21:21	<Rembane>	mauke: Got it.
20:21:37	<EvanR>	there are abnormal methods though, depends on how your library works
20:22:02	<EvanR>	(unsafeInterleaveIO)
20:23:36	<EvanR>	to "normally" avoid collecting all the Text in memory before going on you would do some kind of streaming
20:23:46	<mauke>	(I managed to drastically reduce memory use by first discovering that the http endpoint in question could also deliver json and using aeson, and then switching to a streaming json parser)
20:31:10	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
20:31:31	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
20:34:40	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
20:37:36	<bwe>	[exa]: I might try in increments, starting with single HTML, to see how much the memory consumption is. Can I profile this on ghci?
20:38:17	<[exa]>	technically yes, but I wouldn't bother for the first try
20:38:39	<[exa]>	I expect there's an outlier that you'll simply detect manually
20:38:51	<[exa]>	also, Debug.Trace that prints progress helps a lot in such cases
20:39:21	tomsmeding	. o O ( :set +s )
20:40:39	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
20:40:39	×	haskellbridge quits (~hackager@syn-096-028-224-255.res.spectrum.com) (Read error: Connection reset by peer)
20:41:01	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
20:42:03	<bwe>	tomsmeding: Ok. Is it now the IO returning only after the list is complete? Or is it an edge case in parsing? Or both?
20:42:35	<tomsmeding>	uh, I'm not sure what I'm supposed to base my answer on :)
20:43:51	<bwe>	[exa]: well, that means picking single parsers and running them with :set +s on ghci to see which is an outlier.
20:44:24	<tomsmeding>	bwe: does memory already blow up on a single HTML document?
20:44:37	<EvanR>	rofile stuff in isolation and see how it performs
20:44:53	tomsmeding	. o O ( read-only file )
20:44:53	<bwe>	tomsmeding: No. I can take 100. If I take 300 or so, it blows up.
20:45:05	<tomsmeding>	is memory usage linear in the number of documents?
20:45:28	→	haskellbridge joins (~hackager@syn-096-028-224-255.res.spectrum.com)
20:45:28	ChanServ	sets mode +v haskellbridge
20:46:08	<[exa]>	tomsmeding: I sent the unsafe FFI question to gl maintainers, let's see. :D
20:47:07	<EvanR>	I don't think opengl callsback into your program for anything
20:47:20	<tomsmeding>	opengl has no fucking clue how to call into haskell
20:47:49	→	merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
20:48:10	<tomsmeding>	[exa]: passing a haskell function pointer into C requires an explicit `foreign export`; that's easy to grep for
20:48:40	<[exa]>	grep says nope
20:48:48	<tomsmeding>	(as expected) good
20:48:50	[exa]	happy
20:48:59	→	visilii_ joins (~visilii@46.61.242.71)
20:49:15	<tomsmeding>	[exa]: are all those FFI calls short?
20:49:19	×	visilii quits (~visilii@85.94.27.197) (Ping timeout: 252 seconds)
20:49:28	<tomsmeding>	a long-lasting unsafe FFI call is not great because it blocks GC for a long time
20:49:30	<[exa]>	instant
20:49:36	<tomsmeding>	ok then no problem
20:50:04	<[exa]>	as in, the longest ones are the swapbufferish ones that might wait for a vblank or so, for astonishing 15 milliseconds or so
20:50:06	<EvanR>	though if you only have 1 thread there's no much for the GC to do during that time
20:50:08	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
20:50:12	<tomsmeding>	(GC will still decide to run and pause the other threads while it waits for an unsafe FFI call to complete; this can cause _significant_ pointless idle time)
20:50:32	<EvanR>	but now I'm wondering what "essentially single threaded" means
20:50:33	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
20:50:36	<[exa]>	spoiler: there's no other threads. :D
20:50:39	<EvanR>	is that the same thing as "not single threaded"
20:50:44	×	michalz quits (~michalz@185.246.207.221) (Remote host closed the connection)
20:50:49	<haskellbridge>	<magic_rb> I think 15ms is significant
20:50:59	<EvanR>	yes
20:51:13	<tomsmeding>	(this is an issue in accelerate (CPU backend): we do unsafe FFI calls to the individual kernels, and when GC attemps to run you get momentary big vertical blank space in your thread utilisation profiler)
20:51:17	<haskellbridge>	<magic_rb> If you can afford it you can try a foreign primop if youre minmaxing perf here, but you need to be careful with times, gc and shit
20:51:32	<tomsmeding>	but if no other threads then nobody cares :)
20:52:05	<haskellbridge>	<magic_rb> Interesting that gc wont say "welp, better luck some other time" and instead will pause anyway
20:52:19	<tomsmeding>	¯\_(ツ)_/¯
20:52:25	<haskellbridge>	<magic_rb> Why not let the other threads run and only do GC when the unsafe ffi one returns, weird
20:52:41	<tomsmeding>	magic_rb: because those other threads might start more unsafe FFI calls in the meantime
20:52:45	<tomsmeding>	and GC might never get to run
20:52:51	<haskellbridge>	<magic_rb> Ah ig
20:52:53	<tomsmeding>	and then you run out of memory and the user is unhappy
20:53:00	<[exa]>	magic_rb: tbh I got rid of the 95% of the program runtime which it spent spinning in some place in RTS in `threadPaused()`. It's strictly less broken than before.
20:53:09	<tomsmeding>	:D
20:53:14	<tomsmeding>	by switching from safe to unsfe?
20:53:17	<[exa]>	yap
20:53:20	<tomsmeding>	neat
20:53:21	<haskellbridge>	<magic_rb> Then youd need a accounting system of "only so many unsafe ffis can run in sequence without a gc" or something
20:53:25	<[exa]>	https://github.com/ekmett/gl/issues/26
20:53:31	<tomsmeding>	I guess?
20:53:37	[exa]	realizes it's maintained by ekmett
20:53:47	<[exa]>	good
20:54:58	<tomsmeding>	bodes well for actually getting a response, I guess :)
20:55:46	<[exa]>	yeah well let's see
20:55:55	<bwe>	tomsmeding: megabytes per single html parsed (for batch of `n`): 1: 3 GB, 10: 2.3 GB, 100: 1.5 GB (so, yes, a single html of 1.5 MB causes 1 GB while parsing)
20:56:12	<[exa]>	at wurst I'm going to learn what's broken in my code by smashing the unsafe everywhere.
20:56:23	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
20:56:30	<bwe>	tomsmeding: the memory consumption is excessively yet decreases with increasing batch size
20:56:32	<tomsmeding>	bwe: memory usage decreases when you pase more html files?
20:56:37	<tomsmeding>	oh
20:56:43	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
20:56:48	<haskellbridge>	<magic_rb> I should check what my ffi is doing in my FUSE bindings
20:56:56	<[exa]>	there's some shared stuff I guess
20:57:01	<tomsmeding>	what is memory usage if you parse _one_ html file, and _two_ html files? Not all files in various batch sizes, but just one or two files?
20:57:36	<tomsmeding>	also, get a better html parser?
20:58:20	<[exa]>	bwe: is that parsed with pandoc?
20:58:40	<bwe>	[exa]: no, scalpel.
20:59:44	<bwe>	tomsmeding: _one_: 3 GB, _two_: 2.2 GB (already divided by no. of files)
21:00:43	<tomsmeding>	bwe: you saying "already divided by" makes it sound like you're still parsing the whole lot instead of just one file
21:01:14	<EvanR>	one file takes 3 gigs, damn
21:02:14	<bwe>	tomsmeding: parsing one: 3124089080 bytes; parsing two: 4545550056 bytes
21:02:26	<[exa]>	bwe: which scrapers? is it possible that you have scrapers with lots of matches but you filter the matches manually and/or only take first finds?
21:02:42	<tomsmeding>	bwe: impressive
21:03:24	<tomsmeding>	does this memory usage occur in similar amounts in compiled code? ghci does not optimise, and optimisation might improve things
21:04:00	<bwe>	tomsmeding: better html parser... Give me one better than TagSoup or fast-tagsoup.
21:04:23	tomsmeding	. o O ( it says "fast" so it's probably faster )
21:04:52	<EvanR>	there are better parsers, you just may not have written it yourself yet
21:05:00	<tomsmeding>	I never use html parsers in haskell so I won't be able to advise there
21:05:50	<bwe>	well, I considered naively cutting out irrelevant parts from the html before I feed it to the parser...
21:06:21	<bwe>	EvanR: What's your advice?
21:07:17	<bwe>	[exa]: I need to check that tomorrow. -- Sounds like you've got some specific experience there, do you?
21:07:29	×	loonycyborg quits (loonycybor@wesnoth/developer/loonycyborg) (Ping timeout: 244 seconds)
21:08:47	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
21:09:10	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
21:09:33	<EvanR>	I don't have a clear picture of the whole thing being measured. TagSoup can lazily stream tags so shouldn't use much memory, when doing something very simple with it.
21:12:21	<bwe>	(Well, the problem happens already with a single html file as I end up with GB memory consumption.)
21:12:28	×	tromp quits (~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
21:12:34	→	loonycyborg joins (loonycybor@wesnoth/developer/loonycyborg)
21:13:34	<EvanR>	is that total GB in memory at once or something like GB per second or something
21:13:35	<[exa]>	bwe: not really, got triggered into a vaguely similar issue once with pandoc but certainly didn't explode _that_ much
21:14:21	<EvanR>	if it's total GB in memory at once I'd like to see the minimum expression which does that
21:15:14	<EvanR>	(yes, reverse (replicate 3billion ())
21:16:19	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
21:16:43	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
21:18:22	<bwe>	[exa]: ...so I get, that filtering matches requires going over the full list of matches while taking only first find does not.
21:18:41	<tomsmeding>	if the filtering happens in IO, yes
21:18:56	<tomsmeding>	this depends very much on what exactly the type of the filtering function is
21:19:30	<tomsmeding>	`take 1 (filter p l)` takes just as much memory as `find p l`
21:19:37	→	tromp joins (~textual@2001:1c00:3487:1b00:f1c1:5955:9038:8985)
21:19:51	<EvanR>	all matches can be a lazy list
21:20:04	<bwe>	tomsmeding: What can I do so that after parsing of first html (within IO) the allocated memory is released (except for the result)?
21:20:07	<[exa]>	bwe: that is a quite likely source of memory being stuck around, yes
21:20:17	→	j1n37 joins (~j1n37@user/j1n37)
21:20:32	<[exa]>	bwe: force the result with something like deepSeq or so
21:20:37	<tomsmeding>	bwe: this depends quite strongly on the precise types and the structure of your code; this cannot be answered in general
21:20:58	<tomsmeding>	perhaps Control.DeepSeq.force, but this not always applicable or the right choice
21:21:21	×	j1n37- quits (~j1n37@user/j1n37) (Ping timeout: 248 seconds)
21:21:33	<EvanR>	map parse longList, if consumed lazily would forget parts of longList if not referenced anywhere
21:21:52	<[exa]>	oh look at this beauty here: https://hackage.haskell.org/package/deepseq-1.5.1.0/docs/Control-DeepSeq.html#v:-60--36--33--33--62-
21:21:55	<[exa]>	bwe: ^
21:22:10	<tomsmeding>	however, if you use the result of `map parse longList` twice, then the whole list will be retained until the second use
21:22:12	<EvanR>	I am suspicious deepseq is the answer to these questions
21:22:23	<EvanR>	the whole list of results
21:22:35	<bwe>	EvanR: Can you elaborate, please?
21:22:42	<EvanR>	on what
21:22:44	<[exa]>	if deepseq isn't an answer, it's either ghci or programming bug, yes.
21:22:56	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
21:23:18	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
21:23:32	<[exa]>	bwe: can you use that <$!!> instead of your fmap and see what changed?
21:29:05	×	tomboy64 quits (~tomboy64@user/tomboy64) (Ping timeout: 265 seconds)
21:30:39	×	loonycyborg quits (loonycybor@wesnoth/developer/loonycyborg) (Ping timeout: 272 seconds)
21:30:54	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
21:31:08	<bwe>	[exa]: It's not drop-in replacement for <$>. It requires some NFData constraint on `a` for `IO a`. Adding `Generic` to the deriving clause does not dedicates it an instance of NFData.
21:31:17	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
21:32:20	<tomsmeding>	`instance NFData ThatType` will do, it will use the Generic instance
21:32:23	→	tomboy64 joins (~tomboy64@user/tomboy64)
21:32:31	<bwe>	EvanR: nvm, I misread as deepseq _not_ to be the answer to these questions. -- Still, are you talking about using deepseq for the list of htmls or within parsing a single one?
21:32:47	<[exa]>	bwe: for each one
21:33:57	<EvanR>	if it would "work" then it would work better to put strict fields on the right fields and make sure you're evaluating results at the right time
21:34:23	<EvanR>	with bang patterns or a "primed" version of whatever utility, like modifyIOref'
21:35:57	<EvanR>	which is also good in the case that deepseq doesn't work
21:44:59	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
21:45:20	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
21:45:27	<bwe>	[exa]: Done. It didn't crash. System memory remained constant. Still 986 GB memory consumed (of course, this seemed to have been rolled over).
21:45:56	<[exa]>	how do you measure the consumption btw
21:46:09	<[exa]>	oh btw I read it's fixed?
21:46:11	<bwe>	[exa]: ghci :set +s
21:47:18	<[exa]>	ah that's reporting _allocated_ memory instead of actual resident memory
21:47:27	<[exa]>	(iirc)
21:48:05	<bwe>	sorry for being imprecise, I used `consumed` wrongly.
21:48:23	<[exa]>	ah np, just that a huge number there is kindof expected
21:48:24	<bwe>	Still, I have an average 1.3 GB per html memory allocated.
21:48:53	→	j1n37- joins (~j1n37@user/j1n37)
21:49:03	<EvanR>	ideally you keep resident memory at a minimum, but this can still cause unlimited "total allocated" to be huge, especially if the computation takes a while
21:49:06	→	peterbecich joins (~Thunderbi@syn-047-229-123-186.res.spectrum.com)
21:49:08	<[exa]>	it's not small for sure but a few gigs allocated this way doesn't mean a big issue
21:49:32	<bwe>	What does this result of the DeepSeq experiment mean now?
21:49:35	<EvanR>	the idea is you can easily gc lots of temporaries with the generational gc
21:49:55	<EvanR>	space leaks are when the resident memory grows to huge before the computation is over
21:49:59	<[exa]>	ghc RTS allocates a few bytes for basically each program step, but that's OK since that allocation is essentially no-op
21:50:18	<EvanR>	compared to malloc yes
21:50:28	×	j1n37 quits (~j1n37@user/j1n37) (Ping timeout: 268 seconds)
21:51:29	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
21:51:54	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
21:52:07	<EvanR>	huge live memory -> slow gc, slow everything. low live memory (regardless of total objects ever) -> fast gc
21:52:27	<[exa]>	bwe: btw for the simplest demonstration of what likely happened try `foldl' (+) 0 [1..100000000]` and then without the tick.
21:54:06	<bwe>	EvanR: What's the generational GC?
21:54:19	<EvanR>	ghc's gc is generational
21:54:32	<[exa]>	bwe: anyway in short, if deepseq helped, it was a normal space leak, and ghc can't solve that effectively since it would need to guess which parts of the program to force into evaluation to actually save memory (generally a hard problem)
21:54:37	[exa]	off, good luck!
21:54:49	<EvanR>	it collects recent garbage faster, which is luckily most garbage
21:54:56	<bwe>	[exa]: Kudos, thanks for your help!
21:55:56	<EvanR>	and immutable data can only reference older data, making it a good fit for haskell
21:58:46	→	hiredman joins (~hiredman@frontier1.downey.family)
21:58:51	<bwe>	EvanR: So, I've got a space leak that eats up my live (system's) memory. Therefore gc becomes slow.
21:59:41	×	tromp quits (~textual@2001:1c00:3487:1b00:f1c1:5955:9038:8985) (Quit: My iMac has gone to sleep. ZZZzzz…)
22:00:05	<EvanR>	sounds like it
22:00:56	<EvanR>	dumb as nail step 0 sanity check: write some lazy code in ghci which you know should be fast and not use much live memory, and make sure your tools confirm it
22:01:28	<bwe>	Shouldn't the profiler help me finding the space leak?
22:01:42	<EvanR>	so at least you are working with two extremes with two different characters
22:01:49	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
22:01:56	<EvanR>	dumb efficient code and real space leaking code
22:02:04	<EvanR>	and can tell the difference
22:02:05	→	ljdarj1 joins (~Thunderbi@user/ljdarj)
22:02:10	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
22:02:18	<EvanR>	if you already know all this then ignore me
22:02:56	<EvanR>	personally I've only been able to use profiling to notice a speak leak and not solve any
22:03:02	<EvanR>	space*
22:04:08	→	loonycyborg joins (loonycybor@wesnoth/developer/loonycyborg)
22:04:09	×	ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds)
22:04:09	ljdarj1	is now known as ljdarj
22:09:23	<bwe>	EvanR: I don't. - How do you solve a space leak?
22:09:49	<darkling>	Meteor patches. :)
22:12:08	<EvanR>	step 0, make sure it's a space leak by looking at a profile and judging that the problem shouldn't be amassing so much live memory
22:12:34	<EvanR>	the result might be, it's not actually a space leak and your problem is just that bad
22:13:55	<EvanR>	otherwise step 1, figure out your main driver of evaluation. Like printing out lines of outputs, writing to IORef, storing to a database. These can be quite late in the game so
22:14:24	<EvanR>	step 2, trace backward to see if you can evaluate something sooner using bang patterns, strict record fields, "primed utilities"
22:15:27	<EvanR>	or the evaluate :: a -> IO a thing from Control.Exceptions, which obviously only works in IO
22:17:33	<EvanR>	iterating step 2 might not fix it, but it ideally does
22:18:53	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
22:20:04	<EvanR>	(note storing to IORef or MVar doesn't automatically evaluate anything, but there are primed utilities for that)
22:25:37	→	JuanDaugherty joins (~juan@user/JuanDaugherty)
22:26:21	×	ttybitnik quits (~ttybitnik@user/wolper) (Ping timeout: 276 seconds)
22:29:39	<haskellbridge>	<thirdofmay18081814goya> at the point of a type error, is it possible to introspect the state of the constraints stack?
22:30:26	<bwe>	Then, what does cause the space leak in the first place? A (temporary) value that is only kept longer in memory after its initial use because another use has not completed yet.
22:31:24	<EvanR>	it's usually a thunk that is holding a bunch of data, and you thought it was evaluated already, letting all that data go
22:31:40	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
22:31:51	<EvanR>	the solution is to make sure it gets evaluated at the time you wanted
22:32:05	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
22:32:06	<int-e>	In Haskell a common source of space leaks is so-called thunks, an implementation detail of lazy evaluation. Basically, rather than storing a value, the heap contains an object describing how to compute the value, and pointers to all the required ingredients. Which can also be thunks, so this can build up to a sizeable amount of memory.
22:32:42	<bwe>	... and I do that with the prime variants of functions, bang pattern etc.
22:33:17	<EvanR>	if necessary yeah, the reasons for it being necessary are the deviled details, but those are the tools to control the when and what
22:33:54	<EvanR>	for a simple example of details
22:34:03	<EvanR>	consider let x = f a b c in y
22:34:34	<EvanR>	if you evaluate y and the value of x is not used any time soon, then f, a, b, and c are all waiting around
22:34:52	<bwe>	(consuming memory)
22:34:54	<EvanR>	(if x is not used at all then it should be collected)
22:35:19	<EvanR>	solution let !x = f a b c in y
22:35:42	<EvanR>	which is the same as let x = f a b c in x `seq` y
22:36:00	<bwe>	evaluate x (so you can let go of f, a, b, c in memory)
22:36:13	<EvanR>	yes as long as f a b and c aren't also needed for something
22:36:25	<bwe>	what if?
22:36:37	<bwe>	evaluate that thing, too?
22:37:22	<EvanR>	there's no one size fits all solution, even this example may actually benefit from leaving the bang off
22:37:33	<EvanR>	f, a, b, and c may take up less memory than the result
22:37:53	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
22:37:59	<EvanR>	programs can grow or shrink as they are "reduced"
22:38:14	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
22:41:31	<EvanR>	this is why you usually don't see anyone recommending put ! on every binding
22:42:19	×	mhatta quits (~mhatta@www21123ui.sakura.ne.jp) (Remote host closed the connection)
22:44:10	→	mhatta joins (~mhatta@www21123ui.sakura.ne.jp)
22:45:28	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
22:45:44	→	va10323 joins (~v324@2802:8010:a026:e900:f93f:d782:dc7c:aeed)
22:45:49	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
22:51:16	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
22:51:16	<bwe>	Does the ghci interactive debugger show the thunks (currently kept in memory) / showing the currently allocated memory? ... I still wonder how to pinpoint the location of the space leaks in my code.
22:51:44	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
22:54:09	×	target_i quits (~target_i@user/target-i/x-6023099) (Quit: leaving)
22:54:13	<bwe>	Thanks for your inputs, anyways. It gives how I approach things now a different spin: Being aware of where yet to be evaluated stuff occupies memory because it hasn't been used in the second, third place yet.
22:54:28	<bwe>	(and solving by enforcing the evaluation)
22:56:52	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
22:57:15	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
23:01:21	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
23:03:59	<EvanR>	ghci can show thunks I think, not sure what the flag is
23:05:24	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
23:05:47	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
23:12:50	→	weary-traveler joins (~user@user/user363627)
23:14:30	<geekosaur>	use :print or :sprint instead of just typing the expression
23:14:54	<geekosaur>	most useful at breakpoints, since for top level stuff it'll just show _\|_
23:15:34	×	__monty__ quits (~toonn@user/toonn) (Quit: leaving)
23:16:39	×	todi quits (~todi@p57803331.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
23:19:08	<haskellbridge>	<sm> bwe some related resources, possibly helpful: https://academy.fpblock.com/haskell/tutorial/all-about-strictness , https://github.com/haskell-perf/checklist , https://haskell.foundation/hs-opt-handbook.github.io
23:19:23	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
23:19:44	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
23:21:56	→	todi joins (~todi@p57803331.dip0.t-ipconnect.de)
23:25:29	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
23:25:50	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
23:28:50	×	sprotte24 quits (~sprotte24@p200300d16f0fc00010c55f6c38487736.dip0.t-ipconnect.de) (Quit: Leaving)
23:32:24	→	jmcantrell joins (~weechat@user/jmcantrell)
23:37:04	→	craunts7 joins (~craunts@136.158.8.87)
23:37:21	→	xff0x joins (~xff0x@om126236151042.32.openmobile.ne.jp)
23:37:33	×	sabathan2 quits (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
23:37:54	→	sabathan2 joins (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
23:37:56	×	acidjnk quits (~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
23:45:23	×	j1n37- quits (~j1n37@user/j1n37) (Read error: Connection reset by peer)
23:48:28	→	j1n37 joins (~j1n37@user/j1n37)
23:48:38	×	Tuplanolla quits (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
23:52:36	×	merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
23:53:03	<haskellbridge>	<thirdofmay18081814goya> hm is it possible to introspect the state of "TcM" (the type checker monad) at the point of a particular type error?
23:53:12	<haskellbridge>	<thirdofmay18081814goya> e.g. query its stateful values
23:53:26	<haskellbridge>	<thirdofmay18081814goya> can it get dumped anywhere?
23:54:28	→	Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
23:56:01	×	ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
23:58:16	×	xff0x quits (~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
23:59:57	×	Frostillicus quits (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds)

All times are in UTC on 2025-05-18.