| 2026-06-30 00:08:31 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 00:15:09 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 00:26:37 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 00:28:00 +0000 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2026-06-30 00:30:44 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 00:36:50 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def672da110570be53229.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-30 00:36:59 +0000 | acidjnk | (~acidjnk@p200300d6e74def672da110570be53229.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-06-30 00:41:55 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 00:46:53 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 268 seconds) |
| 2026-06-30 00:57:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:01:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 01:06:50 +0000 | xff0x | (~xff0x@2405:6580:b080:900:e4cf:554c:fb5:7866) (Ping timeout: 245 seconds) |
| 2026-06-30 01:08:26 +0000 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2026-06-30 01:10:58 +0000 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 276 seconds) |
| 2026-06-30 01:10:58 +0000 | polykernel_ | polykernel |
| 2026-06-30 01:12:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:16:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 01:26:43 +0000 | ft | (~ft@p3e9bc5ec.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2026-06-30 01:27:22 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 01:28:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:31:53 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2026-06-30 01:32:31 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-06-30 01:32:36 +0000 | absentia | (~henricus@user/absentia) absentia |
| 2026-06-30 01:32:57 +0000 | <absentia> | i appear to be struggling with haskell text parsing |
| 2026-06-30 01:33:07 +0000 | <absentia> | it's not much, 300k lines and 25MB of UTF8 |
| 2026-06-30 01:33:14 +0000 | jrm | (~jrm@user/jrm) jrm |
| 2026-06-30 01:33:23 +0000 | <absentia> | but it is stateful, i need to thread a cache through the parse, updated by each line |
| 2026-06-30 01:33:40 +0000 | <absentia> | attoparsec.text still chokes, takes several minutes |
| 2026-06-30 01:34:11 +0000 | <absentia> | accumulating into a vector for each line |
| 2026-06-30 01:35:11 +0000 | <jreicher> | Parsing is not stateful. |
| 2026-06-30 01:35:25 +0000 | <jreicher> | Sorry, I should say it's not side-effecting |
| 2026-06-30 01:35:36 +0000 | <jreicher> | You can write it with a state monad if you want |
| 2026-06-30 01:35:40 +0000 | <absentia> | jreicher: they're weechat logs |
| 2026-06-30 01:35:43 +0000 | <absentia> | i manually implemented a state monad |
| 2026-06-30 01:35:59 +0000 | <absentia> | the idea is when you see a PRIVMSG log line, you look up the hostname associated with that nick in a cache |
| 2026-06-30 01:36:02 +0000 | <jreicher> | You mean you didn't use the state monad supplied by Haskell? |
| 2026-06-30 01:36:06 +0000 | <absentia> | the cache is populated by earlier JOIN/PART/QUIT messages |
| 2026-06-30 01:36:19 +0000 | <absentia> | jreicher: so what do i do, do i stack StateT on top of Parser? |
| 2026-06-30 01:36:34 +0000 | <absentia> | some LLM actually advised not to do this, it will be slow |
| 2026-06-30 01:36:53 +0000 | <absentia> | instead my parser just returns (s, a) |
| 2026-06-30 01:36:53 +0000 | <jreicher> | Would you prefer something that's fast and broken, or slow and works? |
| 2026-06-30 01:36:56 +0000 | <mauke> | StateT Parser feels wrong |
| 2026-06-30 01:37:01 +0000 | <absentia> | it's already slow and works |
| 2026-06-30 01:37:03 +0000 | <absentia> | but thank you for presuming |
| 2026-06-30 01:37:11 +0000 | <jreicher> | Oh I thought you said it was broken |
| 2026-06-30 01:37:11 +0000 | <absentia> | my issue is i want it to be fast and working |
| 2026-06-30 01:37:13 +0000 | <EvanR> | when you are parsing and have a state, you have to decide when the state is reset if ever |
| 2026-06-30 01:37:17 +0000 | <absentia> | jreicher: where did i say that |
| 2026-06-30 01:37:17 +0000 | <mauke> | wouldn't that give you stateful construction of a (pure) parser? |
| 2026-06-30 01:37:22 +0000 | <absentia> | jreicher: maybe you should work on your reading comprehension |
| 2026-06-30 01:37:32 +0000 | <absentia> | jreicher: instead of projecting whatever wh*te nonsense you have going on up there |
| 2026-06-30 01:37:52 +0000 | <monochrom> | I think they mean StateT Foo Parser but they don't tell you what's Foo. |
| 2026-06-30 01:37:53 +0000 | <EvanR> | this is no longer serious! |
| 2026-06-30 01:38:00 +0000 | <mauke> | er, yes |
| 2026-06-30 01:38:03 +0000 | <jreicher> | absentia: it's what I thought you meant by "I appear to be struggling" and also "chokes". It's a simple misunderstanding, and you don't need to be so harsh about it. |
| 2026-06-30 01:38:10 +0000 | <mauke> | StateT s Parser |
| 2026-06-30 01:38:13 +0000 | <absentia> | anyway |
| 2026-06-30 01:38:22 +0000 | <absentia> | mauke: Parser does not instance MonadState or whatever |
| 2026-06-30 01:38:40 +0000 | <absentia> | attoparsec explicitly diverges from parsec and megaparsec in this way, supposedly for performance |
| 2026-06-30 01:38:51 +0000 | <mauke> | ?? |
| 2026-06-30 01:38:55 +0000 | <monochrom> | But crucially whether this is fast or slow depends on Foo, along with a hundred other "details" not revealed. |
| 2026-06-30 01:39:07 +0000 | <absentia> | https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-Internal-Types.html#t:P… |
| 2026-06-30 01:39:20 +0000 | <mauke> | my concern was the layering |
| 2026-06-30 01:39:26 +0000 | <absentia> | https://hackage.haskell.org/package/parsec-3.1.18.0/docs/Text-Parsec.html#t:ParsecT |
| 2026-06-30 01:39:34 +0000 | <mauke> | specifically StateT-around-Parser vs ParserT-around-State |
| 2026-06-30 01:39:37 +0000 | <absentia> | mauke: i'm saying, there is no other possible layering |
| 2026-06-30 01:39:40 +0000 | <monochrom> | But really the moment I saw "LLM said ..." I turned off. |
| 2026-06-30 01:39:52 +0000 | <absentia> | and the only possible layering is nonsensical for the reason you pointed out |
| 2026-06-30 01:40:09 +0000 | <absentia> | because there is no ParsecT in Attoparsec instancing MonadState |
| 2026-06-30 01:40:14 +0000 | <absentia> | there is in Parsec |
| 2026-06-30 01:40:41 +0000 | <absentia> | so actually what i have are s -> Parser (s, a) |
| 2026-06-30 01:40:42 +0000 | <mauke> | why do you keep talking about instances |
| 2026-06-30 01:40:47 +0000 | <monochrom> | The 3 times I took a look at what Google AI said, they were all wrong. In fact in one case, it said "X is true" where the very references it cited said "X is false". |
| 2026-06-30 01:40:49 +0000 | <absentia> | mauke: where do the stateful effects come from |
| 2026-06-30 01:41:02 +0000 | <absentia> | without a monad instance |
| 2026-06-30 01:41:30 +0000 | <mauke> | wait, now it's about Monad? |
| 2026-06-30 01:41:54 +0000 | <absentia> | the hell... all i'm saying is there is no MonadState instance for Attoparsec.Text.Parser |
| 2026-06-30 01:41:56 +0000 | <mauke> | I do assume there is a Monad instance, yes |
| 2026-06-30 01:42:02 +0000 | <mauke> | I don't care about MonadState |
| 2026-06-30 01:42:05 +0000 | <absentia> | therefore i thread my own state through |
| 2026-06-30 01:42:19 +0000 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2026-06-30 01:42:33 +0000 | <absentia> | i should really just profile it at this point |
| 2026-06-30 01:42:40 +0000 | <absentia> | instead of guessing |
| 2026-06-30 01:42:48 +0000 | <absentia> | but it's aggravating that something as simple as text parsing is so damn slow |
| 2026-06-30 01:42:52 +0000 | <mauke> | IIRC all MonadState gives you is the ability to write 'put x' instead of 'lift (put x)' |
| 2026-06-30 01:43:23 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 01:43:25 +0000 | <absentia> | mauke: so what is it that gives you the ability to lift |
| 2026-06-30 01:43:29 +0000 | ft | (~ft@p3e9bccb7.dip0.t-ipconnect.de) ft |
| 2026-06-30 01:43:31 +0000 | jrm | (~jrm@user/jrm) jrm |
| 2026-06-30 01:43:36 +0000 | <mauke> | monad transformer |
| 2026-06-30 01:43:41 +0000 | <absentia> | yeah. it doesn't instance that either. |
| 2026-06-30 01:43:48 +0000 | <absentia> | maybe that's closer to what i meant |
| 2026-06-30 01:44:13 +0000 | <EvanR> | there are ways to parse really fast, and break things |
| 2026-06-30 01:44:21 +0000 | <geekosaur> | if it claims to be ParsecT then it ought to be (that's what the trailing T by convention means) |
| 2026-06-30 01:44:32 +0000 | <absentia> | there is only ParsecT in Parsec |
| 2026-06-30 01:44:37 +0000 | <absentia> | there is no transformer in Attoparsec |
| 2026-06-30 01:44:40 +0000 | <absentia> | it only instances monad |
| 2026-06-30 01:44:47 +0000 | <absentia> | in fact monadplus and monadfail |
| 2026-06-30 01:44:58 +0000 | <geekosaur> | maybe that's the wrong way to go then. |
| 2026-06-30 01:45:21 +0000 | <absentia> | well attoparsec is allegedly "faster" without the ability to lift stateful computations |
| 2026-06-30 01:45:31 +0000 | <absentia> | but it still takes like 10 minutes to parse 25MB |
| 2026-06-30 01:45:40 +0000 | <geekosaur> | also if you want really fast you probably want flatparse, but the price you pay is inconvenience |
| 2026-06-30 01:45:51 +0000 | <absentia> | sometimes i wonder why i didn't write this in python or C or something |
| 2026-06-30 01:46:01 +0000 | <absentia> | it's just shocking to me because i've written minimax engines in haskell |
| 2026-06-30 01:46:08 +0000 | <absentia> | but it just absolutely shits the bed on plaintext processing |
| 2026-06-30 01:46:10 +0000 | <EvanR> | python, that blazing fast language |
| 2026-06-30 01:46:20 +0000 | <absentia> | yeah but do you think it would take 10 minutes to parse 25MB? |
| 2026-06-30 01:46:31 +0000 | <absentia> | i even tried the naive caveman approach |
| 2026-06-30 01:46:33 +0000 | <absentia> | T.splitOn |
| 2026-06-30 01:46:34 +0000 | <EvanR> | you sound like you don't know what you're doing honestly |
| 2026-06-30 01:46:35 +0000 | <absentia> | etc |
| 2026-06-30 01:46:43 +0000 | <geekosaur> | that sounds bad enough that I wonder if you're doing something really wrong |
| 2026-06-30 01:46:46 +0000 | <absentia> | should i just poste the goddamn code |
| 2026-06-30 01:47:02 +0000 | <mauke> | that usually helps :-) |
| 2026-06-30 01:47:07 +0000 | <EvanR> | messing up basic haskell fundamentals |
| 2026-06-30 01:47:13 +0000 | <mauke> | EvanR: ? |
| 2026-06-30 01:47:14 +0000 | <absentia> | https://bpa.st/V2MQ |
| 2026-06-30 01:47:26 +0000 | <EvanR> | in the old days that would cause an early exit for too much stack used |
| 2026-06-30 01:47:30 +0000 | <monochrom> | This is known as "information hiding". |
| 2026-06-30 01:47:33 +0000 | <absentia> | go and audit the code |
| 2026-06-30 01:47:37 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2026-06-30 01:47:40 +0000 | <absentia> | i seriously don't see why this should be non performant |
| 2026-06-30 01:47:54 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-30 01:48:11 +0000 | Digit | (~user@user/digit) (Remote host closed the connection) |
| 2026-06-30 01:48:41 +0000 | <absentia> | like you have to be fucking kidding me if this performs so poorly |
| 2026-06-30 01:48:52 +0000 | <absentia> | there aren't even any explicit lists |
| 2026-06-30 01:49:03 +0000 | <absentia> | yes Vector.snoc is O(n) but spatial locality and cache lines etc |
| 2026-06-30 01:49:19 +0000 | <absentia> | rather shit asymptotics than shotgun random accessing memory and cache missing all the time |
| 2026-06-30 01:49:21 +0000 | <monochrom> | Well that does it. |
| 2026-06-30 01:49:32 +0000 | <absentia> | monochrom: seen this talk by Stroustrup? |
| 2026-06-30 01:49:38 +0000 | <absentia> | https://www.youtube.com/watch?v=OB-bdWKwXsU&t=44m38s |
| 2026-06-30 01:49:39 +0000 | <monochrom> | No. |
| 2026-06-30 01:49:43 +0000 | <absentia> | he says caches beat asymptotics |
| 2026-06-30 01:49:45 +0000 | <absentia> | every time |
| 2026-06-30 01:49:59 +0000 | <absentia> | vectors >>> linked lists |
| 2026-06-30 01:50:00 +0000 | <monochrom> | Well he hasn't seen your example. |
| 2026-06-30 01:50:06 +0000 | <EvanR> | lol |
| 2026-06-30 01:50:10 +0000 | <absentia> | there must be something quite unique about GHC.... |
| 2026-06-30 01:50:17 +0000 | <monochrom> | Also he is not using immutable vectors. |
| 2026-06-30 01:50:21 +0000 | <EvanR> | are you thinking Vector is C++ vector |
| 2026-06-30 01:50:27 +0000 | <absentia> | is it the linalg vector |
| 2026-06-30 01:50:34 +0000 | <absentia> | what am i supposed to use then |
| 2026-06-30 01:50:37 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 01:50:38 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 244 seconds) |
| 2026-06-30 01:50:58 +0000 | <EvanR> | some humility |
| 2026-06-30 01:51:11 +0000 | <absentia> | i think liberians love to project all their own flaws unto everyone else.... |
| 2026-06-30 01:51:22 +0000 | Digit | (~user@user/digit) Digit |
| 2026-06-30 01:51:35 +0000 | <absentia> | can you point out the "basic haskell fundamentals" that are obviously absent from my code EvanR |
| 2026-06-30 01:51:58 +0000 | <EvanR> | e.g. trying to do the equivalent of repeatedly appending an item to the end of a list |
| 2026-06-30 01:52:07 +0000 | <absentia> | i literally came out the gate with that |
| 2026-06-30 01:52:17 +0000 | <monochrom> | Stroustrup is working with, say, "after every 1000 snocs, move to a new location". But Haskell Vector's is after every 1 snoc, move to a new location. |
| 2026-06-30 01:52:17 +0000 | <absentia> | and acknowledged the poor asymptotics, but cited Stroustrup's pragmatics |
| 2026-06-30 01:52:27 +0000 | <absentia> | ok. let's try with plain lists |
| 2026-06-30 01:52:31 +0000 | <EvanR> | quadratic, sure |
| 2026-06-30 01:52:42 +0000 | <EvanR> | but you sounded surprised that it was slow |
| 2026-06-30 01:52:50 +0000 | <absentia> | because i also tried it with lists |
| 2026-06-30 01:52:52 +0000 | <absentia> | it was still pitiful |
| 2026-06-30 01:52:59 +0000 | <absentia> | something like 3000 lines a minute |
| 2026-06-30 01:53:05 +0000 | <absentia> | i am importing 21M |
| 2026-06-30 01:53:18 +0000 | <EvanR> | lists are pretty bad for a lot of things but now we're talking hypotheticals again |
| 2026-06-30 01:53:19 +0000 | <absentia> | then again it was not a controlled experiment |
| 2026-06-30 01:53:23 +0000 | <absentia> | i will try this exact code with lists |
| 2026-06-30 01:55:09 +0000 | <monochrom> | You should go back to C++. Because even when you attempt Haskell, you're just translating C++ to Haskell word by word. That is doomed to make slow programs. There are ways to write fast Haskell programs, but first you must not presume that C++ best practices become Haskell best practices. Some do, some others are the exact opposite. You have to start from scratch. Or just go back to the C++ comfort zone. |
| 2026-06-30 01:55:44 +0000 | <absentia> | why are liberians content to make assuming gender a hate crime |
| 2026-06-30 01:55:50 +0000 | <absentia> | but go on to assume all sorts of other intangible things about you |
| 2026-06-30 01:56:02 +0000 | <absentia> | i've written a naive bayesian filter in haskell |
| 2026-06-30 01:56:06 +0000 | <absentia> | half the functions are pointfree |
| 2026-06-30 01:56:20 +0000 | <absentia> | i've even written a chess engine in haskell |
| 2026-06-30 01:56:31 +0000 | <absentia> | it will go up to 4ply within 2 minutes on a $5 VPS |
| 2026-06-30 01:56:55 +0000 | <EvanR> | C++ in any language |
| 2026-06-30 01:57:03 +0000 | <EvanR> | just as bad as haskell in any language |
| 2026-06-30 01:57:23 +0000 | <jreicher> | Hmm. I would have thought all the takes in the do blocks would be OK... |
| 2026-06-30 01:59:51 +0000 | <monochrom> | Haskell's Vector snoc performs a relocation (really a copy --- the old version still exists) every time. You lose cache locality already. It never benefits from what Stroustrup hoped for. |
| 2026-06-30 02:00:01 +0000 | <absentia> | is this because of immutability |
| 2026-06-30 02:00:05 +0000 | <absentia> | is it literally a malloc per snoc |
| 2026-06-30 02:00:13 +0000 | <monochrom> | Yes and yes. |
| 2026-06-30 02:00:20 +0000 | <absentia> | maybe my friend's intuition was right after all... |
| 2026-06-30 02:00:25 +0000 | <absentia> | he was sniffing out excessive memory allocation |
| 2026-06-30 02:00:51 +0000 | <absentia> | hm |
| 2026-06-30 02:01:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 02:01:37 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:01:42 +0000 | <absentia> | accumulating into a list and then V.fromList'ing doesn't seem to yield much improvement either |
| 2026-06-30 02:01:55 +0000 | <absentia> | ok |
| 2026-06-30 02:01:59 +0000 | <monochrom> | Becasue xs ++ [x] is even worse. |
| 2026-06-30 02:02:01 +0000 | <absentia> | well maybe it only took two minutes that time |
| 2026-06-30 02:02:18 +0000 | <absentia> | i mean V.fromList after the final iteration |
| 2026-06-30 02:02:24 +0000 | <absentia> | or recursive call |
| 2026-06-30 02:02:52 +0000 | luke | (~luke@user/luke) (Remote host closed the connection) |
| 2026-06-30 02:03:06 +0000 | luke | (~luke@user/luke) luke |
| 2026-06-30 02:04:31 +0000 | <mauke> | ok, I've watched the stroustrup thing. he's talking about std::vector vs std::list |
| 2026-06-30 02:04:56 +0000 | <mauke> | i.e. a mutable, resizable (dynamic) array vs. a mutable, doubly-linked list |
| 2026-06-30 02:05:10 +0000 | <mauke> | neither of those map to haskell Vector and [] |
| 2026-06-30 02:06:01 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-30 02:06:01 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 02:06:34 +0000 | <absentia> | well thanks for this then |
| 2026-06-30 02:06:35 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-06-30 02:06:41 +0000 | <absentia> | a list yields non-negligible improvement |
| 2026-06-30 02:07:24 +0000 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
| 2026-06-30 02:08:53 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-06-30 02:09:14 +0000 | <absentia> | https://arxiv.org/abs/1808.08329 |
| 2026-06-30 02:09:17 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:09:22 +0000 | <absentia> | sensational paper headlines considered harmful |
| 2026-06-30 02:10:10 +0000 | <monochrom> | I use lazy lists all the time. But as loops, not data. |
| 2026-06-30 02:10:20 +0000 | <absentia> | [1..] is great sure |
| 2026-06-30 02:10:28 +0000 | <absentia> | i find lazy eval extremely difficult to reason about |
| 2026-06-30 02:10:33 +0000 | <monochrom> | Add line numbers: zip [1..] myLines |
| 2026-06-30 02:10:51 +0000 | <absentia> | in terms of performance |
| 2026-06-30 02:11:22 +0000 | <monochrom> | But everyone agrees that lists are terrible for data, lazy or not, Haskell or C. |
| 2026-06-30 02:12:00 +0000 | <mauke> | I don't! |
| 2026-06-30 02:12:10 +0000 | <monochrom> | The world is not a boolean question like "should you use lists or not". |
| 2026-06-30 02:12:57 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 248 seconds) |
| 2026-06-30 02:13:08 +0000 | <mauke> | the snoc thing reminds me of Larry Wall's "Doing linear scans over an associatvie array is like clubbing someone to death with a loaded Uzi" |
| 2026-06-30 02:13:21 +0000 | <jreicher> | absentia: I believe the computation time of lazy should be no worse than strict. Only the memory use is a bit unpredictable. |
| 2026-06-30 02:14:29 +0000 | <jreicher> | So if you are seeing worse times, I don't think laziness is the reason. |
| 2026-06-30 02:15:24 +0000 | <absentia> | i should have just profiled this from the very beginning |
| 2026-06-30 02:15:24 +0000 | <mauke> | memory has a time all of its own |
| 2026-06-30 02:15:26 +0000 | <absentia> | and it would have been obvious |
| 2026-06-30 02:15:34 +0000 | <mauke> | particularly if your space leak runs into swap :-( |
| 2026-06-30 02:15:54 +0000 | <jreicher> | mauke: yeah, well, thrashing is completely its own thing. |
| 2026-06-30 02:16:47 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:16:52 +0000 | <jreicher> | absentia: why didn't you profile it earlier? Just curious |
| 2026-06-30 02:16:56 +0000 | <monochrom> | Well GC takes time too. And it shows up asymptotically too. If you use linear space, GC time is at least quadratic in total. |
| 2026-06-30 02:17:59 +0000 | <absentia> | jreicher: because i was fed up doing all this other auxiliary work just to get this parser going |
| 2026-06-30 02:18:16 +0000 | <absentia> | i already had to replatform the project on top of debian trixie because bullseye is being EOL'd, all packages out of date |
| 2026-06-30 02:18:19 +0000 | <absentia> | can't update stack resolver |
| 2026-06-30 02:18:29 +0000 | <absentia> | so ok, vacate the VPS, move the platform over, upgrade stack, upgrade libs |
| 2026-06-30 02:18:44 +0000 | <absentia> | then before i can write any code, now i have to set up a profiling harness and benchmark |
| 2026-06-30 02:18:50 +0000 | <absentia> | which probably means installing and setting up hspec |
| 2026-06-30 02:18:54 +0000 | <absentia> | and this just feels like an actual job now |
| 2026-06-30 02:19:02 +0000 | <absentia> | but it's just me being stubborn |
| 2026-06-30 02:19:08 +0000 | <absentia> | i knew from the get-go the first move is always to profile |
| 2026-06-30 02:19:15 +0000 | <absentia> | just wanted to fuck around i guess, idk |
| 2026-06-30 02:19:25 +0000 | <jreicher> | Only if performance is a requirement, and the runtime behaviour is opaque. |
| 2026-06-30 02:19:36 +0000 | <absentia> | based on the old numbers it would have taken 117 hours |
| 2026-06-30 02:19:39 +0000 | <absentia> | not really acceptable |
| 2026-06-30 02:20:00 +0000 | <jreicher> | I wouldn't expect to need a profiler for a simple assembler program, but I would (potentially) for an apparently simple SQL query. (For example) |
| 2026-06-30 02:20:11 +0000 | <monochrom> | I have my share of not even reading the error message. |
| 2026-06-30 02:20:20 +0000 | <jreicher> | Naughty boy |
| 2026-06-30 02:20:25 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 248 seconds) |
| 2026-06-30 02:20:33 +0000 | davidlbowman | (~davidlbow@user/davidlbowman) davidlbowman |
| 2026-06-30 02:20:39 +0000 | <jreicher> | ^boy^person. Very sorry |
| 2026-06-30 02:20:48 +0000 | <monochrom> | No worries. :) |
| 2026-06-30 02:21:36 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 02:26:09 +0000 | finsternis | (~X@23.226.237.192) (Remote host closed the connection) |
| 2026-06-30 02:26:23 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 02:28:22 +0000 | td_ | (~td@i53870922.versanet.de) (Ping timeout: 265 seconds) |
| 2026-06-30 02:29:45 +0000 | td_ | (~td@i53870912.versanet.de) |
| 2026-06-30 02:32:08 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:37:25 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-06-30 02:47:33 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 02:50:36 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 265 seconds) |
| 2026-06-30 02:51:50 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 02:56:53 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 03:02:53 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 03:07:21 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 03:26:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 03:30:06 +0000 | ft | (~ft@p3e9bccb7.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2026-06-30 03:33:38 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 03:41:54 +0000 | ft | (~ft@p3e9bc446.dip0.t-ipconnect.de) ft |
| 2026-06-30 03:44:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 03:49:00 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 04:00:03 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:04:29 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 04:10:04 +0000 | johna321 | (~johna321@c-76-110-10-66.hsd1.fl.comcast.net) |
| 2026-06-30 04:15:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:19:45 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 04:28:34 +0000 | machinedgod | (~machinedg@d108-173-95-19.abhsia.telus.net) (Ping timeout: 276 seconds) |
| 2026-06-30 04:46:10 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 04:50:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-06-30 04:57:24 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-06-30 04:59:14 +0000 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-06-30 05:01:32 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 05:08:27 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 252 seconds) |
| 2026-06-30 05:12:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 05:16:59 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-06-30 05:27:44 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-06-30 05:31:59 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 245 seconds) |
| 2026-06-30 05:32:31 +0000 | johna321 | (~johna321@c-76-110-10-66.hsd1.fl.comcast.net) (Ping timeout: 265 seconds) |
| 2026-06-30 05:38:56 +0000 | divlamir | (~divlamir@user/divlamir) (Remote host closed the connection) |
| 2026-06-30 05:39:08 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 05:43:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 05:47:15 +0000 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2026-06-30 05:47:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-06-30 05:54:00 +0000 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2026-06-30 06:10:13 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Quit: peterbecich) |
| 2026-06-30 06:10:44 +0000 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-06-30 06:13:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:15:10 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2026-06-30 06:17:40 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-06-30 06:26:47 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-06-30 06:28:41 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:35:27 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 261 seconds) |
| 2026-06-30 06:39:08 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-06-30 06:44:20 +0000 | czan | (~czan@user/mange) (Quit: Quittin' time!) |
| 2026-06-30 06:46:06 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 06:49:04 +0000 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 245 seconds) |
| 2026-06-30 06:52:57 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-06-30 06:53:43 +0000 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-06-30 07:02:31 +0000 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-06-30 07:10:08 +0000 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2026-06-30 07:11:36 +0000 | ft | (~ft@p3e9bc446.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2026-06-30 07:13:01 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) ft |
| 2026-06-30 07:14:18 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-06-30 07:15:22 +0000 | rainbyte | (~rainbyte@181.47.219.31) (Remote host closed the connection) |
| 2026-06-30 07:15:41 +0000 | rainbyte | (~rainbyte@181.47.219.31) rainbyte |
| 2026-06-30 07:18:43 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-06-30 07:20:17 +0000 | michalz | (~michalz@185.246.207.193) |
| 2026-06-30 07:26:01 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) |
| 2026-06-30 07:32:47 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) (Read error: No route to host) |
| 2026-06-30 07:36:35 +0000 | jaror | (~jaror@user/jaror) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 07:37:00 +0000 | jaror | (~jaror@user/jaror) jaror |
| 2026-06-30 07:38:17 +0000 | schuelermine | (~Thunderbi@user/schuelermine) schuelermine |
| 2026-06-30 07:45:26 +0000 | chele | (~chele@user/chele) chele |
| 2026-06-30 07:51:14 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 248 seconds) |
| 2026-06-30 07:51:52 +0000 | schuelermine | (~Thunderbi@user/schuelermine) schuelermine |
| 2026-06-30 07:58:00 +0000 | fp | (~Thunderbi@130.233.70.229) fp |
| 2026-06-30 07:58:42 +0000 | schuelermine | (~Thunderbi@user/schuelermine) (Ping timeout: 256 seconds) |
| 2026-06-30 08:04:57 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 08:09:31 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:12:44 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat) |
| 2026-06-30 08:16:51 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) terrorjack |
| 2026-06-30 08:23:40 +0000 | ft | (~ft@p3e9bca38.dip0.t-ipconnect.de) (Quit: leaving) |
| 2026-06-30 08:34:42 +0000 | CiaoSen | (~Jura@2a02:3100:661d:600:4e50:ddff:fe9b:8922) CiaoSen |
| 2026-06-30 08:36:54 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
| 2026-06-30 08:40:52 +0000 | jaror6 | (~jaror@user/jaror) jaror |
| 2026-06-30 08:42:32 +0000 | jaror | (~jaror@user/jaror) (Ping timeout: 262 seconds) |
| 2026-06-30 08:42:32 +0000 | jaror6 | jaror |
| 2026-06-30 08:42:45 +0000 | Ranhir | (~Ranhir@157.97.53.139) (Ping timeout: 272 seconds) |
| 2026-06-30 08:45:34 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 08:46:41 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:47:22 +0000 | Ranhir | (~Ranhir@157.97.53.139) Ranhir |
| 2026-06-30 08:49:10 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:50:37 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:53:16 +0000 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2026-06-30 08:54:08 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-06-30 08:55:11 +0000 | CiaoSen | (~Jura@2a02:3100:661d:600:4e50:ddff:fe9b:8922) (Ping timeout: 252 seconds) |
| 2026-06-30 08:57:43 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-06-30 08:58:21 +0000 | fp | (~Thunderbi@130.233.70.229) (Ping timeout: 252 seconds) |
| 2026-06-30 09:01:51 +0000 | acidjnk_new | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) |
| 2026-06-30 09:02:01 +0000 | acidjnk | (~acidjnk@p200300d6e74def67cefedba3bc5cab81.dip0.t-ipconnect.de) acidjnk |
| 2026-06-30 09:03:01 +0000 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-06-30 09:05:07 +0000 | danza | (~danza@user/danza) danza |
| 2026-06-30 09:08:26 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |