IRCBrowse

2025/05/18

2025-05-18 00:02:19 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 00:02:42 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 00:05:50 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-05-18 00:06:37 +0200 <kaol> cabal v2 sucks. I want to edit one file and I can't figure how to do an incremental compile. It always worked just fine with v1. I seem to be stuck in a hell of waiting for 150 modules to build every time instead.
2025-05-18 00:08:02 +0200 <monochrom> I never experieinced that.
2025-05-18 00:08:20 +0200 <kaol> "cabal build > Up to date" no it isn't you idiot program.
2025-05-18 00:12:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-05-18 00:16:36 +0200 <kaol> Okay, I switched from bumping the project version number in cabal to just twiddling with build-depends instead. That avoids doing the full compile at least. Now I just change base's upper bound every time to trigger the check to see that one module that's changed.
2025-05-18 00:16:51 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
2025-05-18 00:17:12 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-05-18 00:18:12 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-05-18 00:18:30 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 00:18:53 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 00:20:43 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net)
2025-05-18 00:24:39 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 00:25:00 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 00:25:30 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 00:26:17 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2025-05-18 00:26:20 +0200 <hololeap> I've seen doctests change some obscure thing and cause a bunch of modules to get rebuilt
2025-05-18 00:28:42 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 272 seconds)
2025-05-18 00:28:51 +0200 <kaol> And even that build-dependency trick is not quite clean. It triggers dependency checks for all of my executables and libraries, not just the one I'm editing. Those take time.
2025-05-18 00:29:58 +0200 <kaol> And all I'm really doing is just cabal build. This is the kind of usability issues that make me think that cabal developers never use the program themselves.
2025-05-18 00:30:33 +0200 <EvanR> you're changing the version numbers on base but don't want it to recompile everything?
2025-05-18 00:30:53 +0200 <kaol> I'm only doing it to have it notice a change to one module file.
2025-05-18 00:31:04 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 00:31:10 +0200 <kaol> The upper bound. I'm not obviously changing ghc in between.
2025-05-18 00:31:21 +0200 <EvanR> changing 1 module file shouldn't trigger a full rebuild, unless it's something everything depends on
2025-05-18 00:31:40 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 00:31:46 +0200 <kaol> Changing 1 module file gets completely ignored. That's the problem.
2025-05-18 00:31:55 +0200 <EvanR> o_O
2025-05-18 00:31:59 +0200 <kaol> I'm manipulating my cabal file just to make cabal build catch that.
2025-05-18 00:32:03 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 00:32:28 +0200 <EvanR> are you sure that file is listed in the cabal other modules
2025-05-18 00:32:30 +0200notzmv(~daniel@user/notzmv) (Ping timeout: 272 seconds)
2025-05-18 00:34:39 +0200 <Clint> as opposed to exposed-modules?
2025-05-18 00:34:41 +0200 <kaol> It makes no difference whether I have it in other-modules or not.
2025-05-18 00:34:55 +0200 <kaol> v1 never cared about that.
2025-05-18 00:35:41 +0200 <monochrom> I guess with 150 modules, one is not inclined to list them anywhere.
2025-05-18 00:36:19 +0200 <kaol> I just want the behavior that cabal build does if I have a compile error in one module. It works as expected as long as I don't have it compile successfully.
2025-05-18 00:36:38 +0200 <kaol> As long as it is in that state I can change any module and it sees the change.
2025-05-18 00:36:53 +0200 <kaol> But once it compiles once, it never checks any files for changes again.
2025-05-18 00:36:58 +0200 <kaol> Unless I edit my cabal file.
2025-05-18 00:37:19 +0200 <kaol> Which triggers all sorts of dependency checks as well which is slow.
2025-05-18 00:38:32 +0200 <kaol> If cabal build is not the supposed way to use cabal then what is?
2025-05-18 00:38:41 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 00:38:45 +0200 <kaol> If I can't even build my project anymore after it succeeds once?
2025-05-18 00:39:05 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 00:40:14 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 260 seconds)
2025-05-18 00:46:07 +0200 <sm> kaol, that's not working as intended. It'll take some work, but maybe you can minimise it to identify the cause, or share the repo
2025-05-18 00:46:25 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2025-05-18 00:47:31 +0200 <sm> there's also the #hackage channel where cabal developers are
2025-05-18 00:49:09 +0200notzmv(~daniel@user/notzmv) notzmv
2025-05-18 00:49:47 +0200 <sm> also mention your cabal --version
2025-05-18 00:50:30 +0200Guest11(~Guest11@syn-024-165-041-231.res.spectrum.com)
2025-05-18 00:52:13 +0200 <kaol> https://gitlab.com/piperka/piperka and cabal-install version 3.10.3.0
2025-05-18 00:55:55 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net)
2025-05-18 00:56:25 +0200 <sm> kaol, this project doesn't build easily, I wonder which ghc --version you have
2025-05-18 00:56:46 +0200 <sm> 9.6 I guess
2025-05-18 00:58:07 +0200 <sm> no good.. I would try to reproduce your issue, but I can't resolve your dependencies
2025-05-18 00:58:35 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 00:58:56 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 00:59:08 +0200 <kaol> I'm using 9.6.6 currently.
2025-05-18 01:00:49 +0200Frostillicus(~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
2025-05-18 01:07:18 +0200Guest11(~Guest11@syn-024-165-041-231.res.spectrum.com) (Ping timeout: 240 seconds)
2025-05-18 01:08:42 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 01:09:05 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 01:10:12 +0200 <sm> --allow-newer gets farther, but I failed to make cabal build text-icu on mac. But try simplifying your project until it works. Changing a .hs file should definitely trigger recompilation
2025-05-18 01:11:20 +0200Guest11(~Guest11@syn-024-165-041-231.res.spectrum.com)
2025-05-18 01:14:40 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 01:15:00 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 01:17:18 +0200Guest57(~Guest11@syn-024-165-041-231.res.spectrum.com)
2025-05-18 01:18:06 +0200Guest11(~Guest11@syn-024-165-041-231.res.spectrum.com) (Ping timeout: 240 seconds)
2025-05-18 01:21:00 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2025-05-18 01:21:39 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds)
2025-05-18 01:21:48 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds)
2025-05-18 01:22:22 +0200Lord_of_Life_Lord_of_Life
2025-05-18 01:22:59 +0200 <kaol> "cabal install --only-dependencies --force-reinstalls --overwrite-policy=always" works as well to clear whatever's blocking the module file change check.
2025-05-18 01:23:44 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-05-18 01:25:04 +0200 <kaol> No wait, that didn't. I still needed to edit my cabal file.
2025-05-18 01:29:50 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds)
2025-05-18 01:36:36 +0200 <Leary> kaol: Your `hs-source-dirs` are overlapping between components. This can cause problems due to the way GHC searches for modules; try separating them.
2025-05-18 01:38:45 +0200 <sm> 🚀
2025-05-18 01:39:42 +0200 <Leary> (I'm not claiming this is the solution, but it's the thing that looks most wrong in the .cabal file)
2025-05-18 01:41:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 01:42:33 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 01:42:54 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 01:43:26 +0200hiredman(~hiredman@frontier1.downey.family) (Quit: Lost terminal)
2025-05-18 01:44:43 +0200ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-05-18 01:48:29 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds)
2025-05-18 01:48:29 +0200ljdarj1ljdarj
2025-05-18 01:50:13 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 248 seconds)
2025-05-18 01:50:44 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 01:50:48 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 01:51:09 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 01:53:51 +0200sus0(zero@user/zeromomentum) zeromomentum
2025-05-18 01:56:50 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 01:57:10 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 02:02:51 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 02:03:11 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 02:03:46 +0200jespada(~jespada@r179-25-150-22.dialup.adsl.anteldata.net.uy) (Ping timeout: 252 seconds)
2025-05-18 02:05:36 +0200acidjnk(~acidjnk@p200300d6e71c4f65f1ead88f57001215.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2025-05-18 02:08:02 +0200sprotte24(~sprotte24@p200300d16f06fd00c9f6fa4fdf16930b.dip0.t-ipconnect.de) (Quit: Leaving)
2025-05-18 02:12:17 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-05-18 02:14:52 +0200craunts(~craunts@136.158.8.87)
2025-05-18 02:32:06 +0200Guest57(~Guest11@syn-024-165-041-231.res.spectrum.com) (Ping timeout: 240 seconds)
2025-05-18 02:32:59 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 02:33:20 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 02:34:00 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds)
2025-05-18 02:35:57 +0200Guest11(~Guest11@syn-024-165-041-231.res.spectrum.com)
2025-05-18 02:47:06 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 02:47:28 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 02:53:27 +0200harveypwca(~harveypwc@2601:246:d080:f6e0:27d6:8cc7:eca9:c46c) (Quit: Leaving)
2025-05-18 02:55:37 +0200Square2(~Square@user/square) (Ping timeout: 265 seconds)
2025-05-18 02:59:48 +0200 <sm> watch = ["util", "exec", "--", "sh", "-c", """
2025-05-18 02:59:49 +0200 <sm> watchexec --wrap-process=session --no-vcs-ignore --ignore .jj/working_copy/working_copy.lock -c clear --bell "date; echo; jj --no-pager $@"
2025-05-18 02:59:49 +0200 <sm> """, ""]
2025-05-18 03:01:49 +0200end(~end@user/end/x-0094621) (Ping timeout: 252 seconds)
2025-05-18 03:02:10 +0200bcksl(~bcksl@user/bcksl) (Ping timeout: 260 seconds)
2025-05-18 03:02:47 +0200sus0(zero@user/zeromomentum) (Ping timeout: 252 seconds)
2025-05-18 03:05:41 +0200 <sm> I forgot a `--watch .jj` in there, more efficient
2025-05-18 03:06:05 +0200 <sm> now I can have an updating log, op log etc like in Martin's video
2025-05-18 03:09:59 +0200 <sm> and I can keep an eye on what other jj tools (like VJJ) are doing
2025-05-18 03:10:29 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
2025-05-18 03:11:11 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-05-18 03:25:17 +0200craunts7(~craunts@136.158.8.87)
2025-05-18 03:25:22 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 03:25:44 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 03:26:11 +0200bcksl(~bcksl@user/bcksl) bcksl
2025-05-18 03:27:06 +0200craunts(~craunts@136.158.8.87) (Ping timeout: 252 seconds)
2025-05-18 03:27:07 +0200craunts7craunts
2025-05-18 03:27:10 +0200ttybitnik(~ttybitnik@user/wolper) (Quit: Fading out...)
2025-05-18 03:27:12 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 03:31:14 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 03:31:35 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 03:35:21 +0200end(~end@user/end/x-0094621) end^
2025-05-18 03:36:21 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
2025-05-18 03:41:40 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 03:44:55 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 03:45:16 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 03:46:09 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2025-05-18 03:48:30 +0200hiecaq(~hiecaq@user/hiecaq) hiecaq
2025-05-18 03:54:54 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
2025-05-18 03:58:03 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 04:01:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 04:01:46 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 04:05:03 +0200op_4(~tslil@user/op-4/x-9116473) (Remote host closed the connection)
2025-05-18 04:05:39 +0200op_4(~tslil@user/op-4/x-9116473) op_4
2025-05-18 04:05:47 +0200joeyadams(~textual@syn-162-154-010-038.res.spectrum.com)
2025-05-18 04:14:06 +0200manwithluck(~manwithlu@2a09:bac5:5082:2387::38a:10) (Ping timeout: 276 seconds)
2025-05-18 04:14:09 +0200td_(~td@i53870928.versanet.de) (Ping timeout: 245 seconds)
2025-05-18 04:16:02 +0200td_(~td@i5387091A.versanet.de) td_
2025-05-18 04:16:14 +0200 <ski> oh .. sorry, for some reason i missed the paste, Leary
2025-05-18 04:19:19 +0200 <Leary> No worries.
2025-05-18 04:24:02 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-05-18 04:25:11 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2025-05-18 04:29:14 +0200 <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)
2025-05-18 04:31:30 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 04:31:52 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 04:40:33 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 04:46:33 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-05-18 04:54:47 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-05-18 04:55:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 04:56:09 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 05:00:32 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Read error: Connection reset by peer)
2025-05-18 05:00:32 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2025-05-18 05:00:32 +0200chiselfuse(~chiselfus@user/chiselfuse) (Remote host closed the connection)
2025-05-18 05:00:32 +0200califax(~califax@user/califx) (Remote host closed the connection)
2025-05-18 05:00:32 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2025-05-18 05:00:52 +0200califax(~califax@user/califx) califx
2025-05-18 05:00:55 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) bitdex
2025-05-18 05:00:58 +0200chexum(~quassel@gateway/tor-sasl/chexum) chexum
2025-05-18 05:01:02 +0200ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2025-05-18 05:01:10 +0200chiselfuse(~chiselfus@user/chiselfuse) chiselfuse
2025-05-18 05:01:45 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-05-18 05:04:11 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds)
2025-05-18 05:05:24 +0200ystael(~ystael@user/ystael) (Ping timeout: 245 seconds)
2025-05-18 05:13:32 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 05:16:21 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-05-18 05:16:22 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
2025-05-18 05:19:56 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 05:33:31 +0200aforemny(~aforemny@i59F4C598.versanet.de) aforemny
2025-05-18 05:33:35 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2025-05-18 05:35:14 +0200aforemny_(~aforemny@2001:9e8:6ce3:4b00:63e7:2449:7739:bbf2) (Ping timeout: 272 seconds)
2025-05-18 05:42:31 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 05:43:08 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Client Quit)
2025-05-18 05:47:26 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
2025-05-18 05:48:54 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 05:49:14 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 05:56:02 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 05:56:24 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:02:05 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:02:27 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:08:37 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-05-18 06:11:39 +0200poscat(~poscat@user/poscat) poscat
2025-05-18 06:16:36 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 06:17:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-05-18 06:17:35 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 260 seconds)
2025-05-18 06:17:52 +0200haskellbridge(~hackager@syn-096-028-224-255.res.spectrum.com) hackager
2025-05-18 06:17:52 +0200ChanServ+v haskellbridge
2025-05-18 06:21:53 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 06:22:07 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:22:27 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:22:44 +0200haskellbridge(~hackager@syn-096-028-224-255.res.spectrum.com) (Ping timeout: 272 seconds)
2025-05-18 06:23:00 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 252 seconds)
2025-05-18 06:23:42 +0200Guest11(~Guest11@syn-024-165-041-231.res.spectrum.com) (Ping timeout: 240 seconds)
2025-05-18 06:24:12 +0200haskellbridge(~hackager@syn-096-028-224-255.res.spectrum.com) hackager
2025-05-18 06:24:12 +0200ChanServ+v haskellbridge
2025-05-18 06:25:32 +0200 <geekosaur> network back, IP address changed so matrix-side may be a little flaky until the new one propagates
2025-05-18 06:28:53 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 06:30:20 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:30:42 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:36:26 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:36:47 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:42:14 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:42:34 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:45:24 +0200Nosrep(~Nosrep@user/nosrep) (Ping timeout: 245 seconds)
2025-05-18 06:48:59 +0200 <sm> hurrah!
2025-05-18 06:50:29 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:50:50 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 06:52:23 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2025-05-18 06:55:25 +0200Frostillicus(~Frostilli@71.174.119.69)
2025-05-18 06:56:19 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 06:56:40 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 07:00:10 +0200Frostillicus(~Frostilli@71.174.119.69) (Ping timeout: 260 seconds)
2025-05-18 07:01:05 +0200jmcantrell(~weechat@user/jmcantrell) (Quit: WeeChat 4.6.2)
2025-05-18 07:07:18 +0200joeyadams(~textual@syn-162-154-010-038.res.spectrum.com) (Quit: Textual IRC Client: www.textualapp.com)
2025-05-18 07:07:43 +0200robobub(uid248673@id-248673.uxbridge.irccloud.com) robobub
2025-05-18 07:14:40 +0200 <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
2025-05-18 07:14:42 +0200 <haskellbridge> <sm> matrix ?
2025-05-18 07:14:42 +0200 <haskellbridge> <sm> or https://pub.microbin.eu ?
2025-05-18 07:14:42 +0200 <haskellbridge> <magic_rb> https://pub.microbin.eu/upload/zebra-eagle this works
2025-05-18 07:14:42 +0200 <haskellbridge> <sm> excellent pastebin
2025-05-18 07:14:42 +0200 <haskellbridge> <magic_rb> dmjio i was talking about the photo thing right, so that is how it looks now
2025-05-18 07:14:42 +0200 <haskellbridge> <magic_rb> you can tag photos, rename them, javascript free
2025-05-18 07:14:44 +0200 <haskellbridge> <magic_rb> and its stored in git+git-annex
2025-05-18 07:14:45 +0200 <haskellbridge> <magic_rb> https://paste.tomsmeding.com/fxesVbzl like that
2025-05-18 07:14:47 +0200 <haskellbridge> <magic_rb> the database is just a cache for the toml files and can be evicted at any point
2025-05-18 07:14:48 +0200 <haskellbridge> <sm> test
2025-05-18 07:21:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 07:21:46 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 07:25:51 +0200craunts(~craunts@136.158.8.87) (Quit: Ping timeout (120 seconds))
2025-05-18 07:26:06 +0200craunts(~craunts@136.158.8.87)
2025-05-18 07:33:02 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-05-18 07:36:44 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 07:36:50 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 272 seconds)
2025-05-18 07:38:19 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 07:38:41 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 07:44:22 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 07:44:44 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 07:45:39 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 07:50:26 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 07:50:52 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 07:52:28 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-05-18 07:57:22 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Remote host closed the connection)
2025-05-18 07:57:46 +0200euleritian(~euleritia@77.23.248.100)
2025-05-18 07:57:57 +0200euleritian(~euleritia@77.23.248.100) (Remote host closed the connection)
2025-05-18 08:00:21 +0200craunts(~craunts@136.158.8.87) (Ping timeout: 248 seconds)
2025-05-18 08:01:14 +0200euleritian(~euleritia@77.23.248.100)
2025-05-18 08:01:30 +0200wootehfoot(~wootehfoo@user/wootehfoot) wootehfoot
2025-05-18 08:02:26 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 08:02:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 08:03:52 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 08:09:42 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-05-18 08:09:55 +0200euleritian(~euleritia@77.23.248.100) (Remote host closed the connection)
2025-05-18 08:10:19 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-18 08:16:30 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 08:16:57 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 08:20:36 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 08:25:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 08:25:47 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 08:26:14 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-05-18 08:36:39 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 08:37:56 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) werneta
2025-05-18 08:45:01 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 08:45:11 +0200craunts(~craunts@136.158.8.87)
2025-05-18 08:45:24 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 245 seconds)
2025-05-18 08:48:44 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 08:49:05 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 08:50:09 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 08:51:16 +0200craunts(~craunts@136.158.8.87) (Read error: Connection reset by peer)
2025-05-18 08:51:38 +0200craunts(~craunts@136.158.8.87)
2025-05-18 08:52:06 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 08:56:34 +0200craunts(~craunts@136.158.8.87) (Ping timeout: 252 seconds)
2025-05-18 09:00:00 +0200caconym7(~caconym@user/caconym) (Quit: bye)
2025-05-18 09:00:39 +0200caconym7(~caconym@user/caconym) caconym
2025-05-18 09:05:21 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Ping timeout: 248 seconds)
2025-05-18 09:07:30 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 09:08:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 09:09:10 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 09:13:43 +0200craunts(~craunts@136.158.8.87)
2025-05-18 09:14:36 +0200poscat(~poscat@user/poscat) (Remote host closed the connection)
2025-05-18 09:16:15 +0200poscat(~poscat@user/poscat) poscat
2025-05-18 09:17:38 +0200craunts(~craunts@136.158.8.87) (Client Quit)
2025-05-18 09:18:52 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds)
2025-05-18 09:23:06 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 09:23:28 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 09:29:50 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-05-18 09:31:59 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 09:32:03 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-05-18 09:32:36 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 276 seconds)
2025-05-18 09:36:35 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 09:36:58 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 09:37:15 +0200Digit(~user@user/digit) Digit
2025-05-18 09:41:03 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2025-05-18 09:44:54 +0200acidjnk(~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de) acidjnk
2025-05-18 09:47:09 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 09:47:32 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 09:50:56 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
2025-05-18 09:51:17 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 248 seconds)
2025-05-18 09:52:18 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 09:59:23 +0200weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-05-18 10:00:25 +0200sus0(zero@user/zeromomentum) zeromomentum
2025-05-18 10:02:29 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla
2025-05-18 10:03:59 +0200 <haskellbridge> <sm> what's Haskell's killer domain, for https://news.ycombinator.com/item?id=44018922 ?
2025-05-18 10:05:40 +0200Digit(~user@user/digit) (Ping timeout: 260 seconds)
2025-05-18 10:05:58 +0200 <haskellbridge> <sm> "high-assurance computing and prototyping/research"
2025-05-18 10:06:28 +0200 <Rembane> Also parsers and compilers
2025-05-18 10:06:32 +0200 <haskellbridge> <hellwolf> ecosystem of PL nerds
2025-05-18 10:06:57 +0200 <Rembane> And research in lazily evaluated programming languages
2025-05-18 10:09:37 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 10:09:59 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 10:17:08 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 10:17:29 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 10:18:17 +0200 <haskellbridge> <maerwald> High assurance computing?
2025-05-18 10:18:41 +0200 <haskellbridge> <maerwald> GHC and its RTS are underspecified black boxes
2025-05-18 10:19:39 +0200 <haskellbridge> <sm> better: "High assurance applications and prototyping/research"
2025-05-18 10:20:33 +0200 <haskellbridge> <sm> this is in context of the above article, where each language gets 4-6 words for a general audience
2025-05-18 10:21:37 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 10:21:42 +0200 <haskellbridge> <sm> * 1-6
2025-05-18 10:23:53 +0200__monty__(~toonn@user/toonn) toonn
2025-05-18 10:26:51 +0200ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-05-18 10:29:55 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 10:32:12 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2025-05-18 10:42:57 +0200JuanDaugherty(~juan@user/JuanDaugherty) JuanDaugherty
2025-05-18 10:42:58 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
2025-05-18 10:43:21 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 10:43:42 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 10:47:24 +0200Digit(~user@user/digit) Digit
2025-05-18 10:51:40 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 10:52:00 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 10:56:50 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp)
2025-05-18 11:02:04 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-05-18 11:03:24 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 11:03:45 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 11:04:31 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 11:06:12 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 11:08:07 +0200srazkvt(~sarah@user/srazkvt) srazkvt
2025-05-18 11:15:44 +0200gmg(~user@user/gehmehgeh) gehmehgeh
2025-05-18 11:17:45 +0200JuanDaugherty(~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-05-18 11:19:54 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 11:21:06 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 252 seconds)
2025-05-18 11:23:44 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
2025-05-18 11:24:05 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 11:29:21 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 11:29:43 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 11:36:40 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 260 seconds)
2025-05-18 11:39:49 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-05-18 11:40:19 +0200lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-05-18 11:44:11 +0200 <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`
2025-05-18 11:45:38 +0200 <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
2025-05-18 11:45:50 +0200 <lxsameer> and compare elements of this type based on their address
2025-05-18 11:47:00 +0200 <tomsmeding> lxsameer: give it an Int field, don't export the constructor, and expose a smart constructor that increments a global IORef?
2025-05-18 11:47:14 +0200 <tomsmeding> obligatory warning: use atomicModifyIORef', and put NOINLINE on functions with unsafePerformIO
2025-05-18 11:47:19 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2025-05-18 11:47:47 +0200 <lxsameer> tomsmeding: thank you
2025-05-18 11:48:42 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 11:48:58 +0200econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2025-05-18 11:49:24 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 244 seconds)
2025-05-18 11:50:09 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 248 seconds)
2025-05-18 11:50:37 +0200 <mauke> instance Eq X where _ == _ = False
2025-05-18 11:53:38 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 11:54:02 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 11:55:56 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-05-18 12:02:30 +0200 <lxsameer> mauke: a value is still equal to itself
2025-05-18 12:04:11 +0200 <mauke> equal in what sense?
2025-05-18 12:04:34 +0200 <lxsameer> sameness
2025-05-18 12:09:22 +0200 <mauke> what does that mean
2025-05-18 12:10:01 +0200 <lxsameer> a = X; b = X; c = a; a /= b; a == c
2025-05-18 12:10:04 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 12:13:27 +0200 <mauke> oh, you *want* it to be equal
2025-05-18 12:13:43 +0200 <mauke> yeah, that's not a thing
2025-05-18 12:15:40 +0200turlando(~turlando@user/turlando) (Quit: No Ping reply in 180 seconds.)
2025-05-18 12:16:14 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 12:16:35 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 12:16:56 +0200turlando(~turlando@user/turlando) turlando
2025-05-18 12:20:38 +0200notzmv(~daniel@user/notzmv) (Ping timeout: 265 seconds)
2025-05-18 12:21:59 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 12:22:21 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 12:34:37 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2025-05-18 12:35:01 +0200ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2025-05-18 12:35:23 +0200 <tomsmeding> the fact that you need ugliness like unsafePerformIO in my suggestion shows what you're asking for :p
2025-05-18 12:35:39 +0200 <lxsameer> ah haskell has a Unique type too
2025-05-18 12:35:46 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 12:36:08 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 12:36:13 +0200 <lxsameer> essentially it seems like the same thing that tomsmeding suggested
2025-05-18 12:36:28 +0200 <tomsmeding> yes, but you still need to write the unsafePerformIO yourself
2025-05-18 12:36:51 +0200 <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#U…
2025-05-18 12:37:04 +0200 <tomsmeding> except you probably need another unsafePerformIO around newUnique
2025-05-18 12:38:18 +0200 <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
2025-05-18 12:38:55 +0200 <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
2025-05-18 12:40:12 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Ping timeout: 272 seconds)
2025-05-18 12:40:45 +0200 <Rembane> So things became less and less safe and faster and faster over time?
2025-05-18 12:40:56 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds)
2025-05-18 12:41:22 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
2025-05-18 12:44:18 +0200 <lxsameer> hmmmm but i think it's better to rethink the approach
2025-05-18 12:44:31 +0200wootehfoot(~wootehfoo@user/wootehfoot) wootehfoot
2025-05-18 12:46:08 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 12:46:37 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-05-18 12:46:55 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-18 12:48:43 +0200 <tomsmeding> Rembane: why less safe?
2025-05-18 12:49:27 +0200 <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
2025-05-18 12:49:38 +0200 <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.
2025-05-18 12:49:41 +0200 <tomsmeding> (in this particular application)
2025-05-18 12:49:47 +0200 <Rembane> Got it!
2025-05-18 12:49:53 +0200 <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
2025-05-18 12:50:08 +0200 <lxsameer> ah sorry, it wasn't for me
2025-05-18 12:50:41 +0200 <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
2025-05-18 12:50:43 +0200LainIwakura(~LainIwaku@user/LainIwakura) LainIwakura
2025-05-18 12:50:58 +0200 <tomsmeding> STM doesn't give any concurrency guarantees, just the observation that in practice it works really well
2025-05-18 12:51:07 +0200 <tomsmeding> IORef is just... a mutable thing
2025-05-18 12:51:22 +0200 <Rembane> tomsmeding: Maybe that's the point. Hm... because I've learned them in the context of concurrency.
2025-05-18 12:51:24 +0200 <tomsmeding> it seems to me that "obviously" atomicModifyIORef' is the fastest
2025-05-18 12:51:37 +0200 <tomsmeding> it does just an atomic update, whereas MVar and STM do a whole lot more
2025-05-18 12:51:45 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 12:52:07 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 12:52:20 +0200 <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. :)
2025-05-18 12:52:54 +0200tomsmedingworks almost daily with programs that use this particular ID generation trick, so I'm tainted too
2025-05-18 12:52:55 +0200 <lxsameer> tomsmeding: that's a good summary of it
2025-05-18 12:54:14 +0200 <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
2025-05-18 12:54:26 +0200 <tomsmeding> (I knew them decently well before that, but more in detail now)
2025-05-18 12:54:43 +0200fp1(~Thunderbi@hof1.kyla.fi) fp
2025-05-18 12:55:01 +0200 <Rembane> tomsmeding: That's a really good trick to learn something! :D
2025-05-18 12:55:07 +0200 <tomsmeding> it is :)
2025-05-18 12:55:14 +0200 <tomsmeding> just a bit hard to pull off, sometimes
2025-05-18 12:55:34 +0200 <Rembane> Totally. "Hi there friends, of course you want to learn this complicated thing..."
2025-05-18 12:56:50 +0200 <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
2025-05-18 12:57:14 +0200 <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
2025-05-18 12:57:18 +0200 <tomsmeding> voilà, deadlock
2025-05-18 12:57:20 +0200 <Rembane> \œ/
2025-05-18 12:57:43 +0200 <Rembane> tomsmeding: It just struck me that it's such a luxury to have proper transactions outside of a database.
2025-05-18 12:57:47 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 12:58:07 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 12:58:21 +0200 <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
2025-05-18 12:58:45 +0200 <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
2025-05-18 12:59:10 +0200troydm(~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)
2025-05-18 12:59:23 +0200 <tomsmeding> Rembane: it is absolutely a luxury, and it's almost impossible to do it with a sensible API in a non-pure langugae
2025-05-18 12:59:28 +0200 <tomsmeding> so haskell is blessed :)
2025-05-18 12:59:44 +0200 <Rembane> tomsmeding: It's so good. :D
2025-05-18 13:00:25 +0200zlqrvx(~zlqrvx@2001:8003:8c8b:e00:374a:bdcb:457c:d1e3)
2025-05-18 13:01:44 +0200jespada(~jespada@r167-61-146-44.dialup.adsl.anteldata.net.uy) jespada
2025-05-18 13:03:39 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 265 seconds)
2025-05-18 13:05:22 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
2025-05-18 13:07:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 13:07:56 +0200LainIwakura(~LainIwaku@user/LainIwakura) (Quit: Client closed)
2025-05-18 13:08:11 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 13:13:54 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-05-18 13:25:21 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 13:30:47 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 13:33:09 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds)
2025-05-18 13:50:41 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 248 seconds)
2025-05-18 13:52:06 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 13:59:10 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-05-18 13:59:43 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-18 14:03:13 +0200euphores(~SASL_euph@user/euphores) (Quit: Leaving.)
2025-05-18 14:05:07 +0200rvalue(~rvalue@user/rvalue) (Ping timeout: 252 seconds)
2025-05-18 14:06:28 +0200rvalue-(~rvalue@user/rvalue) rvalue
2025-05-18 14:06:56 +0200rvalue-rvalue
2025-05-18 14:12:18 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 14:15:10 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 14:15:32 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 14:18:11 +0200euphores(~SASL_euph@user/euphores) euphores
2025-05-18 14:28:06 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-05-18 14:34:00 +0200jespada(~jespada@r167-61-146-44.dialup.adsl.anteldata.net.uy) (Ping timeout: 260 seconds)
2025-05-18 14:36:16 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Remote host closed the connection)
2025-05-18 14:36:37 +0200euleritian(~euleritia@77.23.248.100)
2025-05-18 14:38:08 +0200Digitteknohippie(~user@user/digit) Digit
2025-05-18 14:39:09 +0200Digit(~user@user/digit) (Ping timeout: 245 seconds)
2025-05-18 14:39:21 +0200jespada(~jespada@r186-48-57-38.dialup.adsl.anteldata.net.uy) jespada
2025-05-18 14:40:19 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 14:46:25 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2025-05-18 14:47:44 +0200img(~img@user/img) img
2025-05-18 14:51:16 +0200euleritian(~euleritia@77.23.248.100) (Ping timeout: 244 seconds)
2025-05-18 14:51:36 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
2025-05-18 14:54:31 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-05-18 14:54:50 +0200euleritian(~euleritia@77.23.248.100)
2025-05-18 15:04:20 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 15:04:43 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 15:07:20 +0200fp1(~Thunderbi@hof1.kyla.fi) (Ping timeout: 252 seconds)
2025-05-18 15:09:22 +0200lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-05-18 15:11:23 +0200DigitteknohippieDigit
2025-05-18 15:11:43 +0200FragByte(~christian@user/fragbyte) (Quit: Quit)
2025-05-18 15:13:42 +0200FragByte(~christian@user/fragbyte) FragByte
2025-05-18 15:15:23 +0200euleritian(~euleritia@77.23.248.100) (Ping timeout: 252 seconds)
2025-05-18 15:16:14 +0200Square2(~Square@user/square) Square
2025-05-18 15:17:53 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
2025-05-18 15:19:03 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2025-05-18 15:20:22 +0200img(~img@user/img) img
2025-05-18 15:24:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 15:24:47 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 15:27:25 +0200wickedjargon(~user@2001:569:fc3c:d000:49fd:4f0f:5c90:505) (Remote host closed the connection)
2025-05-18 15:28:57 +0200ttybitnik(~ttybitnik@user/wolper) ttybitnik
2025-05-18 15:29:50 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 15:32:28 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 15:32:51 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 15:34:06 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.5.2)
2025-05-18 15:34:17 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:39:35 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.5.2)
2025-05-18 15:39:44 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:40:54 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:41:03 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:41:15 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:42:16 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:43:40 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:43:50 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:44:57 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:45:19 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:45:44 +0200Guest45(~Guest45@2a00:9fe0:0:c::1:102a)
2025-05-18 15:46:02 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-05-18 15:51:15 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Quit: WeeChat 4.5.2)
2025-05-18 15:52:16 +0200Nosrep(~Nosrep@user/nosrep) Nosrep
2025-05-18 15:52:21 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:52:45 +0200acidjnk(~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2025-05-18 15:53:55 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:54:05 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:54:23 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:54:34 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 15:54:55 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 15:55:02 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:55:24 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:55:34 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:56:33 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:56:54 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 15:57:15 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) (Client Quit)
2025-05-18 15:57:34 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 15:59:14 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2025-05-18 16:05:08 +0200tinjamin4(~tinjamin@banshee.h4x0r.space)
2025-05-18 16:10:49 +0200Digitteknohippie(~user@user/digit) Digit
2025-05-18 16:11:52 +0200Digit(~user@user/digit) (Ping timeout: 244 seconds)
2025-05-18 16:20:37 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 248 seconds)
2025-05-18 16:25:24 +0200Digitteknohippie(~user@user/digit) (Ping timeout: 245 seconds)
2025-05-18 16:25:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 16:25:45 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 16:29:46 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 16:29:51 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2025-05-18 16:30:11 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 16:33:59 +0200sajenim(~sajenim@user/sajenim) sajenim
2025-05-18 16:34:06 +0200 <sajenim> #join #kernel
2025-05-18 16:34:11 +0200 <sajenim> sorry
2025-05-18 16:42:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 16:43:14 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 16:46:45 +0200Digit(~user@user/digit) Digit
2025-05-18 16:53:54 +0200michalz(~michalz@185.246.207.221)
2025-05-18 16:58:21 +0200Digitdigitteknohippie
2025-05-18 16:58:44 +0200digitteknohippieDigit
2025-05-18 17:01:27 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-05-18 17:08:54 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 17:09:15 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 17:12:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 17:14:55 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 17:15:16 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 17:22:36 +0200xff0x(~xff0x@om126236151042.32.openmobile.ne.jp) (Read error: Connection reset by peer)
2025-05-18 17:22:58 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 17:23:21 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 17:28:44 +0200Guest45(~Guest45@2a00:9fe0:0:c::1:102a) (Quit: Client closed)
2025-05-18 17:35:01 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 17:35:22 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 17:43:09 +0200lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-05-18 17:48:17 +0200hiecaq(~hiecaq@user/hiecaq) (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.0.92))
2025-05-18 17:50:07 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 17:50:29 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 17:51:12 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 18:05:09 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 18:05:33 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 18:06:16 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds)
2025-05-18 18:07:36 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 18:10:44 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-05-18 18:11:01 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-18 18:17:34 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 18:17:54 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 245 seconds)
2025-05-18 18:22:05 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 18:23:08 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 252 seconds)
2025-05-18 18:27:17 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 18:27:38 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 18:31:11 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2025-05-18 18:35:15 +0200srazkvt(~sarah@user/srazkvt) (Quit: Konversation terminated!)
2025-05-18 18:35:16 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de)
2025-05-18 18:39:18 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 18:39:41 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 18:45:09 +0200ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-05-18 18:45:09 +0200Pozyomka(~pyon@user/pyon) (Ping timeout: 248 seconds)
2025-05-18 18:45:22 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 18:45:31 +0200euleritian(~euleritia@dynamic-176-006-136-230.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2025-05-18 18:45:43 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 18:46:26 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de)
2025-05-18 18:47:49 +0200lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2025-05-18 18:49:14 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds)
2025-05-18 18:49:14 +0200ljdarj1ljdarj
2025-05-18 18:50:22 +0200euouae(~euouae@user/euouae) euouae
2025-05-18 18:51:03 +0200 <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.
2025-05-18 18:51:28 +0200 <euouae> What I want to ask is if Haskell has something that I can use that does this already, a sort of byte deque.
2025-05-18 18:52:03 +0200 <euouae> What I thought about doing is using a list of strings and a lens to treat them as one string
2025-05-18 18:54:55 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-05-18 18:57:08 +0200 <euouae> Nevermind I guess that's what I'll do :)
2025-05-18 18:57:08 +0200euouae(~euouae@user/euouae) ()
2025-05-18 18:59:15 +0200tomboy64(~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
2025-05-18 18:59:29 +0200tomboy64(~tomboy64@user/tomboy64) tomboy64
2025-05-18 18:59:53 +0200acidjnk(~acidjnk@p200300d6e71c4f033d258f2e8b70eea4.dip0.t-ipconnect.de) acidjnk
2025-05-18 19:01:43 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 19:02:03 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 19:02:17 +0200robertm(robertm@lattice.rojoma.com) (Quit: ,,,)
2025-05-18 19:05:08 +0200robertm(robertm@lattice.rojoma.com) robertm
2025-05-18 19:07:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 19:07:48 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 19:11:10 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
2025-05-18 19:17:22 +0200notzmv(~daniel@user/notzmv) notzmv
2025-05-18 19:23:35 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 19:23:57 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 19:24:19 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-05-18 19:26:17 +0200ystael(~ystael@user/ystael) ystael
2025-05-18 19:29:21 +0200tomboy64(~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
2025-05-18 19:29:29 +0200tomboy65(~tomboy64@user/tomboy64) tomboy64
2025-05-18 19:30:25 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 19:30:46 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 19:36:07 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 19:37:01 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 276 seconds)
2025-05-18 19:37:12 +0200Nosrep(~Nosrep@user/nosrep) (Ping timeout: 252 seconds)
2025-05-18 19:41:57 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-05-18 19:44:44 +0200 <__monty__> @tell euouae Consider looking at Data.Sequence for double-ended operations.
2025-05-18 19:44:44 +0200 <lambdabot> Consider it noted.
2025-05-18 19:45:26 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net)
2025-05-18 19:46:21 +0200Sgeo(~Sgeo@user/sgeo) Sgeo
2025-05-18 19:47:54 +0200 <monochrom> Although, it is not very fast.
2025-05-18 19:47:57 +0200tromp(~textual@2001:1c00:3487:1b00:ace7:b293:8f4:7479)
2025-05-18 19:49:57 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 19:50:21 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 19:55:49 +0200euleritian(~euleritia@ip4d17f864.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2025-05-18 19:56:57 +0200euleritian(~euleritia@77.23.248.100)
2025-05-18 19:58:07 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess
2025-05-18 19:58:47 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 19:59:08 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 19:59:14 +0200tomboy65(~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
2025-05-18 19:59:29 +0200tomboy64(~tomboy64@user/tomboy64) tomboy64
2025-05-18 20:07:53 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 20:08:17 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 20:13:57 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 20:14:19 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 20:16:04 +0200jmcantrell(~weechat@user/jmcantrell) jmcantrell
2025-05-18 20:16:45 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2025-05-18 20:27:18 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich)
2025-05-18 20:27:46 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-05-18 20:29:12 +0200tomboy64(~tomboy64@user/tomboy64) (Read error: Connection reset by peer)
2025-05-18 20:29:29 +0200tomboy64(~tomboy64@user/tomboy64) tomboy64
2025-05-18 20:29:39 +0200jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 260 seconds)
2025-05-18 20:29:41 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 20:32:17 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 20:32:39 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 20:41:10 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 20:41:32 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 20:42:42 +0200sprotte24(~sprotte24@p200300d16f0fc00010c55f6c38487736.dip0.t-ipconnect.de)
2025-05-18 20:45:01 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-05-18 20:46:10 +0200j1n37-(~j1n37@user/j1n37) (Ping timeout: 260 seconds)
2025-05-18 20:46:22 +0200j1n37(~j1n37@user/j1n37) j1n37
2025-05-18 20:50:04 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 20:50:27 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 20:53:28 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com) bitmapper
2025-05-18 20:53:28 +0200GdeVolpiano(~GdeVolpia@user/GdeVolpiano) GdeVolpiano
2025-05-18 20:55:33 +0200 <__monty__> Neither is `[String]` for operations on both ends though.
2025-05-18 20:55:41 +0200 <__monty__> It's plenty fast for AoC : )
2025-05-18 20:59:07 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-05-18 21:00:03 +0200caconym7(~caconym@user/caconym) (Quit: bye)
2025-05-18 21:00:42 +0200caconym7(~caconym@user/caconym) caconym
2025-05-18 21:01:26 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 21:01:49 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:03:22 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2025-05-18 21:07:42 +0200target_i(~target_i@user/target-i/x-6023099) target_i
2025-05-18 21:12:27 +0200Digitteknohippie(~user@user/digit) Digit
2025-05-18 21:12:27 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 21:12:48 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:13:50 +0200Digit(~user@user/digit) (Ping timeout: 272 seconds)
2025-05-18 21:19:32 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 21:19:54 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:21:05 +0200gmg(~user@user/gehmehgeh) gehmehgeh
2025-05-18 21:24:01 +0200infinity0(~infinity0@pwned.gg) (Ping timeout: 252 seconds)
2025-05-18 21:30:34 +0200DigitteknohippieDigit
2025-05-18 21:32:18 +0200j1n37-(~j1n37@user/j1n37) j1n37
2025-05-18 21:32:39 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2025-05-18 21:32:43 +0200j1n37(~j1n37@user/j1n37) (Ping timeout: 244 seconds)
2025-05-18 21:33:34 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
2025-05-18 21:33:57 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:38:25 +0200 <[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
2025-05-18 21:39:54 +0200pavonia(~user@user/siracusa) siracusa
2025-05-18 21:41:03 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 21:41:23 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:44:41 +0200infinity0(~infinity0@pwned.gg) infinity0
2025-05-18 21:46:26 +0200 <EvanR> both OpenGLRaw and gl are supposed to be a direct reflection of the C api
2025-05-18 21:46:42 +0200 <EvanR> so I expect no difference if they both achieved
2025-05-18 21:47:05 +0200 <EvanR> why do we need two, not sure, but OpenGLRaw originally didn't exist
2025-05-18 21:47:31 +0200 <EvanR> I mean we don't need two, but why did OpenGLRaw happen I don't know
2025-05-18 21:47:40 +0200 <[exa]> like, gl seems a lil more organized
2025-05-18 21:47:50 +0200 <[exa]> but that's it
2025-05-18 21:48:05 +0200 <[exa]> I expected e.g. some radically different way to get the gl function pointers or so
2025-05-18 21:48:14 +0200 <EvanR> that would be OpenGL not-Raw
2025-05-18 21:48:19 +0200 <EvanR> it's radically different
2025-05-18 21:49:05 +0200Pozyomka(~pyon@user/pyon) pyon
2025-05-18 21:49:45 +0200 <[exa]> nah the OpenGL is very wrapped
2025-05-18 21:51:19 +0200 <[exa]> ok anyway I just wanted to change the way the ffi is done a very little and see if it explodes
2025-05-18 21:51:29 +0200 <[exa]> gl rebuilds itself automatically -> win
2025-05-18 21:51:44 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer)
2025-05-18 21:52:04 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 245 seconds)
2025-05-18 21:52:07 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:58:43 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 21:59:04 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 21:59:10 +0200 <[exa]> and whoa, it works
2025-05-18 22:00:11 +0200 <[exa]> is there anything very wrong about marking FFI imports in an essentially singlethreaded application as `unsafe` ?
2025-05-18 22:01:31 +0200 <tomsmeding> [exa]: unsafe is, ironically, typically the safer option
2025-05-18 22:01:55 +0200 <tomsmeding> GHC guarantees that the GC will not run during an unsafe FFI call
2025-05-18 22:01:57 +0200 <[exa]> for me it somehow kills like 80% of the call overhead
2025-05-18 22:02:13 +0200 <tomsmeding> so you can pass unpinned stuff to C and they won't move under C's feeet
2025-05-18 22:02:22 +0200 <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).
2025-05-18 22:02:23 +0200 <bwe> -- Which alternatives to streaming frameworks do you recommend to let the garbage collection happen after each entry of a list has been processed?
2025-05-18 22:02:35 +0200 <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_
2025-05-18 22:02:44 +0200 <[exa]> ....which is quite a relief when trying to smash 60 batches of glDrawWhatever calls per second to the GPU.
2025-05-18 22:02:50 +0200 <[exa]> yeah
2025-05-18 22:02:54 +0200 <tomsmeding> to accomplish this, GHC starts a new capability, which has overhead
2025-05-18 22:03:17 +0200 <[exa]> yes, a scary lot of overhead.
2025-05-18 22:04:38 +0200 <EvanR> bwe, make sure to evaluate each parse result before going on to the next one
2025-05-18 22:04:40 +0200 <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
2025-05-18 22:05:11 +0200 <tomsmeding> if that "thing" is a list, that list is not returned in a streaming fashion
2025-05-18 22:05:44 +0200 <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
2025-05-18 22:05:46 +0200 <[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
2025-05-18 22:05:47 +0200 <tomsmeding> but also check EvanR's suggestion
2025-05-18 22:06:01 +0200 <tomsmeding> if you're running out of memory then GC will _definitely_ have attempted to run
2025-05-18 22:06:10 +0200 <[exa]> +1 ^
2025-05-18 22:06:14 +0200 <tomsmeding> so the fact that you run out of memory proves that manually calling GC will not help
2025-05-18 22:06:17 +0200 <monochrom> The worst nightmare is that GC ran and found nothing to free, so you spent both memory and time.
2025-05-18 22:06:34 +0200 <bwe> monochrom: that's what I assume is happening.
2025-05-18 22:06:49 +0200 <EvanR> well that would require the gc running
2025-05-18 22:06:54 +0200 <EvanR> at least once
2025-05-18 22:07:10 +0200 <tomsmeding> GC will run every n bytes allocated
2025-05-18 22:07:14 +0200 <monochrom> Theorem: A linear-space algorithm takes at least quadratic time in a GCed language. >:)
2025-05-18 22:07:17 +0200 <tomsmeding> n < amount of memory in your system
2025-05-18 22:07:41 +0200 <[exa]> bwe: btw what's the type of the sql result structure?
2025-05-18 22:07:48 +0200 <[exa]> (I suspect selda)
2025-05-18 22:09:05 +0200 <bwe> [exa]: loadRawHtmls :: IO [HTML]
2025-05-18 22:09:17 +0200 <bwe> [exa]: Confirmed. It's selda.
2025-05-18 22:09:56 +0200 <[exa]> can selda stream the results?
2025-05-18 22:10:01 +0200 <tomsmeding> that `IO [HTML]` type confirms what I wrote
2025-05-18 22:10:30 +0200 <bwe> [exa]: Not out of the box.
2025-05-18 22:11:02 +0200 <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
2025-05-18 22:11:21 +0200 <EvanR> and for good measure make sure it's not HTML = String
2025-05-18 22:11:31 +0200 <tomsmeding> yeah I guess you might try `sequence . fmap (map Control.DeepSeq.force)`
2025-05-18 22:11:47 +0200 <bwe> EvanR: I took my time to take your input in :). No, it's Text.
2025-05-18 22:12:23 +0200 <bwe> EvanR: So, lazy evaluation waits until full list is completed and only then GC can free the memory.
2025-05-18 22:12:25 +0200 <EvanR> a list of 100 big Text should be fine, as long as that's what it is
2025-05-18 22:12:31 +0200 <EvanR> no
2025-05-18 22:12:47 +0200 <tomsmeding> the IO action only returns when it's done
2025-05-18 22:12:56 +0200 <[exa]> bwe: what is your result type, roughly?
2025-05-18 22:12:58 +0200 <tomsmeding> it's done when all 100 HTML buffers have been read
2025-05-18 22:13:08 +0200 <tomsmeding> hence, all will be live in memory when the `IO [HTML]` action returns
2025-05-18 22:13:17 +0200 <[exa]> bwe: a lot of the job can be done by including a few strictness exclamation marks here and there
2025-05-18 22:13:26 +0200 <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.
2025-05-18 22:13:29 +0200 <[exa]> also Data.Vector.Strict, Data.Map.Strict, etc etc
2025-05-18 22:13:51 +0200 <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?
2025-05-18 22:14:53 +0200 <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)
2025-05-18 22:15:00 +0200 <EvanR> collect your*
2025-05-18 22:15:05 +0200 <bwe> tomsmeding: 1.5 MB
2025-05-18 22:15:18 +0200 <tomsmeding> assuming you don't have a PC from the 90s, that should be okay
2025-05-18 22:15:42 +0200 <[exa]> like, that's a bit too much even for a pretty wild space leak
2025-05-18 22:15:43 +0200 <EvanR> 1.5 MB you exhausted my entire floppy disk
2025-05-18 22:16:02 +0200 <[exa]> EvanR: try the bigger floppies I heard they have more space
2025-05-18 22:16:06 +0200 <EvanR> lol
2025-05-18 22:16:10 +0200 <tomsmeding> % :t traverse @[] Control.Exception.evaluate
2025-05-18 22:16:10 +0200 <yahb2> traverse @[] Control.Exception.evaluate :: [b] -> IO [b]
2025-05-18 22:16:20 +0200 <monochrom> zip diskettes
2025-05-18 22:16:25 +0200 <tomsmeding> bwe: do that to your [HTML]
2025-05-18 22:16:41 +0200 <tomsmeding> the @[] is just to make the type here nicer
2025-05-18 22:17:07 +0200 <mauke> % :t traverse Control.Exception.evaluate
2025-05-18 22:17:07 +0200 <yahb2> traverse Control.Exception.evaluate ; :: Traversable t => t b -> IO (t b)
2025-05-18 22:17:21 +0200 <mauke> % :t traverse Control.Exception.evaluate `asAppliedTo` []
2025-05-18 22:17:21 +0200 <yahb2> <interactive>:1:37: error: [GHC-88464] ; Variable not in scope: ; asAppliedTo :: (t0 b0 -> IO (t0 b0)) -> [a0] -> t
2025-05-18 22:17:50 +0200 <mauke> huh
2025-05-18 22:18:35 +0200 <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?
2025-05-18 22:18:41 +0200 <mauke> then where do I remember that from
2025-05-18 22:18:51 +0200 <tomsmeding> surely a function that reads 1.5 MB total will by itself not exhaust memory
2025-05-18 22:18:55 +0200 <tomsmeding> there is something going on that we're not seeing
2025-05-18 22:19:13 +0200 <[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
2025-05-18 22:19:41 +0200tomsmedingnods
2025-05-18 22:19:48 +0200 <[exa]> (as in, some html so weird that it recurses infinitely. e.g. some binary ballast which doesn't parse well.)
2025-05-18 22:20:02 +0200 <mauke> I've seen processing ~35 MB of XML take about 2 GB of memory
2025-05-18 22:20:20 +0200 <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.
2025-05-18 22:20:31 +0200 <Rembane> There's the HAHAHA-attack, right?
2025-05-18 22:20:42 +0200 <mauke> not an attack
2025-05-18 22:21:06 +0200 <mauke> it involved an arrow-based xml parser and keeping everything as Strings
2025-05-18 22:21:10 +0200 <EvanR> bwe, a "normal" IO [Text] which gets each Text using I/O will "return" when it built the whole list
2025-05-18 22:21:21 +0200 <Rembane> mauke: Got it.
2025-05-18 22:21:37 +0200 <EvanR> there are abnormal methods though, depends on how your library works
2025-05-18 22:22:02 +0200 <EvanR> (unsafeInterleaveIO)
2025-05-18 22:23:36 +0200 <EvanR> to "normally" avoid collecting all the Text in memory before going on you would do some kind of streaming
2025-05-18 22:23:46 +0200 <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)
2025-05-18 22:31:10 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 22:31:31 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 22:34:40 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-05-18 22:37:36 +0200 <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?
2025-05-18 22:38:17 +0200 <[exa]> technically yes, but I wouldn't bother for the first try
2025-05-18 22:38:39 +0200 <[exa]> I expect there's an outlier that you'll simply detect manually
2025-05-18 22:38:51 +0200 <[exa]> also, Debug.Trace that prints progress helps a lot in such cases
2025-05-18 22:39:21 +0200tomsmeding. o O ( :set +s )
2025-05-18 22:40:39 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 22:40:39 +0200haskellbridge(~hackager@syn-096-028-224-255.res.spectrum.com) (Read error: Connection reset by peer)
2025-05-18 22:41:01 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 22:42:03 +0200 <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?
2025-05-18 22:42:35 +0200 <tomsmeding> uh, I'm not sure what I'm supposed to base my answer on :)
2025-05-18 22:43:51 +0200 <bwe> [exa]: well, that means picking single parsers and running them with :set +s on ghci to see which is an outlier.
2025-05-18 22:44:24 +0200 <tomsmeding> bwe: does memory already blow up on a single HTML document?
2025-05-18 22:44:37 +0200 <EvanR> rofile stuff in isolation and see how it performs
2025-05-18 22:44:53 +0200tomsmeding. o O ( read-only file )
2025-05-18 22:44:53 +0200 <bwe> tomsmeding: No. I can take 100. If I take 300 or so, it blows up.
2025-05-18 22:45:05 +0200 <tomsmeding> is memory usage linear in the number of documents?
2025-05-18 22:45:28 +0200haskellbridge(~hackager@syn-096-028-224-255.res.spectrum.com) hackager
2025-05-18 22:45:28 +0200ChanServ+v haskellbridge
2025-05-18 22:46:08 +0200 <[exa]> tomsmeding: I sent the unsafe FFI question to gl maintainers, let's see. :D
2025-05-18 22:47:07 +0200 <EvanR> I don't think opengl callsback into your program for anything
2025-05-18 22:47:20 +0200 <tomsmeding> opengl has no fucking clue how to call into haskell
2025-05-18 22:47:49 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-18 22:48:10 +0200 <tomsmeding> [exa]: passing a haskell function pointer into C requires an explicit `foreign export`; that's easy to grep for
2025-05-18 22:48:40 +0200 <[exa]> grep says nope
2025-05-18 22:48:48 +0200 <tomsmeding> (as expected) good
2025-05-18 22:48:50 +0200[exa]happy
2025-05-18 22:48:59 +0200visilii_(~visilii@46.61.242.71)
2025-05-18 22:49:15 +0200 <tomsmeding> [exa]: are all those FFI calls short?
2025-05-18 22:49:19 +0200visilii(~visilii@85.94.27.197) (Ping timeout: 252 seconds)
2025-05-18 22:49:28 +0200 <tomsmeding> a long-lasting unsafe FFI call is not great because it blocks GC for a long time
2025-05-18 22:49:30 +0200 <[exa]> instant
2025-05-18 22:49:36 +0200 <tomsmeding> ok then no problem
2025-05-18 22:50:04 +0200 <[exa]> as in, the longest ones are the swapbufferish ones that might wait for a vblank or so, for astonishing 15 milliseconds or so
2025-05-18 22:50:06 +0200 <EvanR> though if you only have 1 thread there's no much for the GC to do during that time
2025-05-18 22:50:08 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 22:50:12 +0200 <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)
2025-05-18 22:50:32 +0200 <EvanR> but now I'm wondering what "essentially single threaded" means
2025-05-18 22:50:33 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 22:50:36 +0200 <[exa]> spoiler: there's no other threads. :D
2025-05-18 22:50:39 +0200 <EvanR> is that the same thing as "not single threaded"
2025-05-18 22:50:44 +0200michalz(~michalz@185.246.207.221) (Remote host closed the connection)
2025-05-18 22:50:49 +0200 <haskellbridge> <magic_rb> I think 15ms is significant
2025-05-18 22:50:59 +0200 <EvanR> yes
2025-05-18 22:51:13 +0200 <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)
2025-05-18 22:51:17 +0200 <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
2025-05-18 22:51:32 +0200 <tomsmeding> but if no other threads then nobody cares :)
2025-05-18 22:52:05 +0200 <haskellbridge> <magic_rb> Interesting that gc wont say "welp, better luck some other time" and instead will pause anyway
2025-05-18 22:52:19 +0200 <tomsmeding> ¯\_(ツ)_/¯
2025-05-18 22:52:25 +0200 <haskellbridge> <magic_rb> Why not let the other threads run and only do GC when the unsafe ffi one returns, weird
2025-05-18 22:52:41 +0200 <tomsmeding> magic_rb: because those other threads might start more unsafe FFI calls in the meantime
2025-05-18 22:52:45 +0200 <tomsmeding> and GC might never get to run
2025-05-18 22:52:51 +0200 <haskellbridge> <magic_rb> Ah ig
2025-05-18 22:52:53 +0200 <tomsmeding> and then you run out of memory and the user is unhappy
2025-05-18 22:53:00 +0200 <[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.
2025-05-18 22:53:09 +0200 <tomsmeding> :D
2025-05-18 22:53:14 +0200 <tomsmeding> by switching from safe to unsfe?
2025-05-18 22:53:17 +0200 <[exa]> yap
2025-05-18 22:53:20 +0200 <tomsmeding> neat
2025-05-18 22:53:21 +0200 <haskellbridge> <magic_rb> Then youd need a accounting system of "only so many unsafe ffis can run in sequence without a gc" or something
2025-05-18 22:53:25 +0200 <[exa]> https://github.com/ekmett/gl/issues/26
2025-05-18 22:53:31 +0200 <tomsmeding> I guess?
2025-05-18 22:53:37 +0200[exa]realizes it's maintained by ekmett
2025-05-18 22:53:47 +0200 <[exa]> good
2025-05-18 22:54:58 +0200 <tomsmeding> bodes well for actually getting a response, I guess :)
2025-05-18 22:55:46 +0200 <[exa]> yeah well let's see
2025-05-18 22:55:55 +0200 <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)
2025-05-18 22:56:12 +0200 <[exa]> at wurst I'm going to learn what's broken in my code by smashing the unsafe everywhere.
2025-05-18 22:56:23 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Remote host closed the connection)
2025-05-18 22:56:30 +0200 <bwe> tomsmeding: the memory consumption is excessively yet decreases with increasing batch size
2025-05-18 22:56:32 +0200 <tomsmeding> bwe: memory usage decreases when you pase more html files?
2025-05-18 22:56:37 +0200 <tomsmeding> oh
2025-05-18 22:56:43 +0200sabathan2(~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr)
2025-05-18 22:56:48 +0200 <haskellbridge> <magic_rb> I should check what my ffi is doing in my FUSE bindings
2025-05-18 22:56:56 +0200 <[exa]> there's some shared stuff I guess
2025-05-18 22:57:01 +0200 <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?
2025-05-18 22:57:36 +0200 <tomsmeding> also, get a better html parser?
2025-05-18 22:58:20 +0200 <[exa]> bwe: is that parsed with pandoc?
2025-05-18 22:58:40 +0200 <bwe> [exa]: no, scalpel.
2025-05-18 22:59:44 +0200 <bwe> tomsmeding: _one_: 3 GB, _two_: 2.2 GB (already divided by no. of files)
2025-05-18 23:00:43 +0200 <tomsmeding> bwe: you saying "already divided by" makes it sound like you're still parsing the whole lot instead of just one file
2025-05-18 23:01:14 +0200 <EvanR> one file takes 3 gigs, damn
2025-05-18 23:02:14 +0200 <bwe> tomsmeding: parsing one: 3124089080 bytes; parsing two: 4545550056 bytes
2025-05-18 23:02:26 +0200 <[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?
2025-05-18 23:02:42 +0200 <tomsmeding> bwe: impressive
2025-05-18 23:03:24 +0200 <tomsmeding> does this memory usage occur in similar amounts in compiled code? ghci does not optimise, and optimisation might improve things
2025-05-18 23:04:00 +0200 <bwe> tomsmeding: better html parser... Give me one better than TagSoup or fast-tagsoup.
2025-05-18 23:04:23 +0200tomsmeding. o O ( it says "fast" so it's probably faster )
2025-05-18 23:04:52 +0200 <EvanR> there are better parsers, you just may not have written it yourself yet
2025-05-18 23:05:00 +0200 <tomsmeding> I never use html parsers in haskell so I won't be able to advise there
2025-05-18 23:05:50 +0200 <bwe> well, I considered naively cutting out irrelevant parts from the html before I feed it to the parser...
2025-05-18 23:06:21 +0200 <bwe> EvanR: What's your advice?
2025-05-18 23:07:17 +0200 <bwe> [exa]: I need to check that tomorrow. -- Sounds like you've got some specific experience there, do you?