Logs: liberachat/#haskell
| 2026-03-23 12:08:37 | <Freakie> | yeah force works but it's a *big* hammer |
| 2026-03-23 12:11:11 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-23 12:14:23 | <Freakie> | I need to find something less intrusive than `force` because of how many iterations the algorithm makes (like millions of calls to the function) unfortunately |
| 2026-03-23 12:14:43 | <[exa]> | try moving the `force` one level down |
| 2026-03-23 12:14:54 | <[exa]> | depeper into expression or something |
| 2026-03-23 12:15:18 | <[exa]> | that should allow you to locate the unevaluated data |
| 2026-03-23 12:15:44 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-23 12:15:44 | <[exa]> | when you got that, you'll just add the missing ! that causes the issue |
| 2026-03-23 12:17:07 | × | czan quits (~czan@user/mange) (Quit: Zzz...) |
| 2026-03-23 12:17:48 | <Freakie> | i'm considering just adding another accumulator argument to the function that is built during the loop and then just appended to the rest of the accumulator |
| 2026-03-23 12:18:14 | <Freakie> | that should at least reduce the work `force` needs to linear complexity |
| 2026-03-23 12:20:17 | <Freakie> | ideally you should be able to just `seq` or `$! ` the accumulator/constructor as you thread it along but I can only assume that I'm doing it in the wrong places |
| 2026-03-23 12:22:18 | <Freakie> | but are space leaks supposed to happen for data that isn't thunks? |
| 2026-03-23 12:22:29 | <Freakie> | aren't thunks* |
| 2026-03-23 12:26:38 | → | traxex joins (traxex@user/traxex) |
| 2026-03-23 12:28:07 | <[exa]> | yeah if all data is already forced, the "lazy" space leaks won't happen |
| 2026-03-23 12:28:37 | <Freakie> | what i'm saying is there aren't any thunks (at least not any constructors tagged as such) taking that much space |
| 2026-03-23 12:28:54 | <[exa]> | btw not sure if $! will help here -- it forces the argument, you probably want to force the result |
| 2026-03-23 12:28:55 | <Freakie> | hence why I mentioned CONSTR_NOCAF and whether or not it might be a symptom |
| 2026-03-23 12:29:26 | <[exa]> | yes the NOCAF corresponds to the label of your data types, probably of the Arc1 |
| 2026-03-23 12:29:31 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-23 12:29:31 | <[exa]> | btw all constructors start as thunks |
| 2026-03-23 12:30:02 | <[exa]> | (essentially all non-trivial ones, that is) |
| 2026-03-23 12:30:24 | <Freakie> | right but I'm saying that there aren't any thunk *constructors* so my question is whether or not CONSTR_NOCAF can be lazy in some other sense |
| 2026-03-23 12:30:30 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2026-03-23 12:31:17 | <[exa]> | it might be that the unevaluated thunk just holds the CONSTR_NOCAF, not that the CONSTR_NOCAF is the issue |
| 2026-03-23 12:31:58 | <Freakie> | wouldn't the heap profile still show a thunk somewhere? like my priority queues basically take 0 space on the heap because the elements are recorded separately |
| 2026-03-23 12:32:37 | <[exa]> | not necessarily |
| 2026-03-23 12:33:22 | <[exa]> | you might have a thunk that says something like `if something then xxx else yyy` with `something` already known ofc, but it just holds both `xxx` and `yyy` because the runtime didn't care to force it yet |
| 2026-03-23 12:33:48 | <[exa]> | in your case the `xxx` or `yyy` might be a huge list of arcs or so |
| 2026-03-23 12:34:18 | <Freakie> | think I basically need some heuristic to determine when to force if this is supposed to be feasible |
| 2026-03-23 12:34:31 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-23 12:34:57 | <[exa]> | nah, you just need to find the expression that holds it :) |
| 2026-03-23 12:35:10 | <[exa]> | that's the nitpicky part of the job, once identified it's easy |
| 2026-03-23 12:35:42 | <Freakie> | that's kinda the thing though, I know exactly which lines of code produce the data |
| 2026-03-23 12:35:58 | <[exa]> | try putting `force` in front of them and see if it fixes it |
| 2026-03-23 12:36:03 | <Freakie> | already have |
| 2026-03-23 12:36:18 | <[exa]> | did it help? |
| 2026-03-23 12:36:24 | <Freakie> | problem is forcing the accumulator every single iteration kills performance |
| 2026-03-23 12:36:39 | <[exa]> | ah so it's the accumulator `acc` right? |
| 2026-03-23 12:36:45 | <Freakie> | yes |
| 2026-03-23 12:36:56 | <[exa]> | try forcing just the stuff that goes into it (you're appending a head there right?) |
| 2026-03-23 12:37:40 | <[exa]> | :t \x xs -> ((:) $! x) xs |
| 2026-03-23 12:37:41 | <lambdabot> | a -> [a] -> [a] |
| 2026-03-23 12:37:48 | <[exa]> | perhaps like this ^ |
| 2026-03-23 12:38:13 | <Freakie> | I have tried playing around with something similar but I think I did it the other way around |
| 2026-03-23 12:38:26 | <[exa]> | yeah you don't want to deepseq the tail there |
| 2026-03-23 12:38:40 | <Freakie> | no just normal `seq` |
| 2026-03-23 12:38:53 | <[exa]> | ok that might work quickly |
| 2026-03-23 12:39:03 | <[exa]> | but try `force` on the actual element |
| 2026-03-23 12:39:39 | <Freakie> | but man some of these combinators twist my brain |
| 2026-03-23 12:40:02 | <[exa]> | L35 here https://pastebin.com/uB36SXJ2 : `force arc` instd of `arc` |
| 2026-03-23 12:40:32 | <Freakie> | but it's already been forced at the let expression? with strictness on teh lhs |
| 2026-03-23 12:40:45 | <[exa]> | `force` is deep, ! is shallow |
| 2026-03-23 12:41:04 | <Freakie> | but if the result has been forced, there shouldn't be more to unpack from it when appending? |
| 2026-03-23 12:42:16 | <[exa]> | I know it doesn't make much sense logically but that's the issue with debugging, we're trying to find a minor inconsistency, the least assumptions you drag in the less probability that you assume yourself into longer debug |
| 2026-03-23 12:42:58 | × | m1dnight quits (~m1dnight@d8D861A17.access.telenet.be) (Ping timeout: 248 seconds) |
| 2026-03-23 12:43:20 | <[exa]> | the exercise is "force helps globally and !s have failed" => "find the smallest piece of code where force helps locally and focus the !s there" |
| 2026-03-23 12:44:15 | → | m1dnight joins (~m1dnight@d8D861A17.access.telenet.be) |
| 2026-03-23 12:44:17 | <Freakie> | honestly seems like nothing works |
| 2026-03-23 12:44:27 | <[exa]> | except for the global force on the accumulator? |
| 2026-03-23 12:44:45 | <Freakie> | pretty much |
| 2026-03-23 12:45:13 | <[exa]> | can you try wrapping the accumulator call in something that does `nf` on the result of it? |
| 2026-03-23 12:45:25 | × | Vizious quits (~bes@user/Vizious) (Read error: Connection reset by peer) |
| 2026-03-23 12:46:04 | → | Vizious joins (~bes@user/Vizious) |
| 2026-03-23 12:46:08 | <Freakie> | do you mean `rnf` or is it some other package? |
| 2026-03-23 12:46:17 | <[exa]> | as in: outputInternalArcsPQ1' pq1 req x acc = id $! outputInternalArcsPQ1 pq1 req x acc |
| 2026-03-23 12:46:27 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-23 12:46:53 | <Freakie> | seems my catchphrase today is "will try" |
| 2026-03-23 12:46:59 | → | haritz joins (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2026-03-23 12:46:59 | × | haritz quits (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2026-03-23 12:46:59 | → | haritz joins (~hrtz@user/haritz) |
| 2026-03-23 12:47:12 | [exa] | afk teaching |
| 2026-03-23 12:47:14 | <[exa]> | good luck :) |
| 2026-03-23 12:48:33 | <Freakie> | I also managed to find the worst of both worlds by trying to force the list at the end of the global loop iteration which had the effect of ballooning the runtime without reducing the heap data |
| 2026-03-23 12:49:01 | <Freakie> | which at least supports the behavior |
| 2026-03-23 12:50:49 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-23 12:52:42 | <Freakie> | it's interesting to see how the garbage collection time gets completely dwarfed when forcing things though |
| 2026-03-23 12:52:49 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 245 seconds) |
| 2026-03-23 12:56:38 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-23 12:57:02 | → | ystael joins (~ystael@user/ystael) |
| 2026-03-23 13:00:46 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-23 13:03:55 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-23 13:07:36 | → | weary-traveler joins (~user@user/user363627) |
| 2026-03-23 13:15:22 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-23 13:20:07 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-23 13:25:14 | → | fp1 joins (~Thunderbi@2001:708:150:10::8465) |
| 2026-03-23 13:25:51 | × | fp quits (~Thunderbi@130.233.70.34) (Ping timeout: 244 seconds) |
| 2026-03-23 13:25:51 | fp1 | is now known as fp |
| 2026-03-23 13:28:27 | → | Square2 joins (~Square@user/square) |
| 2026-03-23 13:45:02 | × | fp quits (~Thunderbi@2001:708:150:10::8465) (Ping timeout: 252 seconds) |
| 2026-03-23 13:48:14 | → | fp joins (~Thunderbi@130.233.70.34) |
| 2026-03-23 13:57:40 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-23 14:02:01 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-03-23 14:03:14 | × | mistivia quits (~mistivia@user/mistivia) (Remote host closed the connection) |
| 2026-03-23 14:03:33 | → | mistivia joins (~mistivia@user/mistivia) |
| 2026-03-23 14:05:19 | × | mistivia quits (~mistivia@user/mistivia) (Remote host closed the connection) |
| 2026-03-23 14:05:44 | → | craunts795335385 joins (~craunts@152.32.99.2) |
| 2026-03-23 14:06:05 | → | mistivia joins (~mistivia@user/mistivia) |
| 2026-03-23 14:13:26 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
All times are in UTC.