Newest at the top
| 2024-04-29 23:25:48 +0200 | <tomsmeding> | but surely those regions are still about the source, not about the core? |
| 2024-04-29 23:25:21 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 252 seconds) |
| 2024-04-29 23:24:55 +0200 | <shapr> | Well, you get more regions with more depth, but I wouldn't expect this sort of size explosion |
| 2024-04-29 23:24:28 +0200 | <tomsmeding> | so you'd expect that to scale about linearly with program text size divided by the average variable name length? |
| 2024-04-29 23:23:52 +0200 | <tomsmeding> | I see |
| 2024-04-29 23:23:40 +0200 | <shapr> | tomsmeding: the mix file holds the list of regions that can be annotated, it's later turned into the pretty html output: https://wiki.haskell.org/Haskell_program_coverage |
| 2024-04-29 23:23:39 +0200 | <tomsmeding> | those are long arrays |
| 2024-04-29 23:23:11 +0200 | <shapr> | https://github.com/AccelerateHS/accelerate/blob/master/src/Data/Array/Accelerate/Test/NoFib/Issues… |
| 2024-04-29 23:23:07 +0200 | tomsmeding | has no reference here |
| 2024-04-29 23:22:59 +0200 | <shapr> | 82kb source file turned into a 440kb mix file |
| 2024-04-29 23:21:50 +0200 | <shapr> | wow, hpc produced a 440k mix file |
| 2024-04-29 23:20:59 +0200 | <tomsmeding> | surely it's the former, you don't want core coverage, you want haskell coverage |
| 2024-04-29 23:20:42 +0200 | <tomsmeding> | if the former, then core size is irrelevant |
| 2024-04-29 23:20:34 +0200 | <tomsmeding> | does it do that at the source level or in core after optimisation |
| 2024-04-29 23:20:26 +0200 | <shapr> | now that you mention it, lemme check the size of the mix files |
| 2024-04-29 23:20:14 +0200 | <shapr> | iirc, hpc puts a counter on every little definition |
| 2024-04-29 23:20:07 +0200 | <tomsmeding> | because compilation is definitely slow, but that's not the issue at hand here |
| 2024-04-29 23:20:04 +0200 | <shapr> | that's my guess |
| 2024-04-29 23:19:53 +0200 | <tomsmeding> | that there's just a huge amount of core, you mean? |
| 2024-04-29 23:19:19 +0200 | <shapr> | but that's just a guess |
| 2024-04-29 23:19:16 +0200 | <shapr> | I would guess it's related to the specialize things in that bug report |
| 2024-04-29 23:18:58 +0200 | <tomsmeding> | I wonder why HPC is tripping on it |
| 2024-04-29 23:18:53 +0200 | <tomsmeding> | the `accelerate` package itself is actually not anything special, it's just haskell |
| 2024-04-29 23:18:25 +0200 | <tomsmeding> | the latter just has an interpreter in normal haskell |
| 2024-04-29 23:18:15 +0200 | <shapr> | ah, not a problem then |
| 2024-04-29 23:18:15 +0200 | <tomsmeding> | not in `accelerate` |
| 2024-04-29 23:18:09 +0200 | <tomsmeding> | the LLVM stuff is in accelerate-llvm{,-native,-ptx} |
| 2024-04-29 23:17:26 +0200 | <shapr> | I'd see an error, right? |
| 2024-04-29 23:17:20 +0200 | <shapr> | I'm using nixos, and LLVM is not in scope, could that be it? |
| 2024-04-29 23:16:46 +0200 | <tomsmeding> | (which HPC might actually be fine with considering that's just FFI calls in the end) |
| 2024-04-29 23:16:17 +0200 | <tomsmeding> | this is not even the backend, which does runtime code generation using LLVM |
| 2024-04-29 23:16:16 +0200 | <shapr> | but again, doesn't help me poke at kudzu |
| 2024-04-29 23:15:53 +0200 | <shapr> | I'd believe that |
| 2024-04-29 23:15:47 +0200 | <tomsmeding> | surely this is a bug somewhere |
| 2024-04-29 23:14:44 +0200 | <shapr> | looks like it sticks on "sort:" |
| 2024-04-29 23:14:03 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-29 23:12:45 +0200 | <tomsmeding> | does it spin infinitely on one case or does it progress super slowly |
| 2024-04-29 23:12:15 +0200 | <shapr> | heh, ok |
| 2024-04-29 23:12:12 +0200 | <tomsmeding> | at least then you know what you're getting :p |
| 2024-04-29 23:12:07 +0200 | <tomsmeding> | try `cabal run nofib-accelerate -f nofib --enable-coverage` |
| 2024-04-29 23:11:47 +0200 | <tomsmeding> | can `cabal test` die |
| 2024-04-29 23:11:45 +0200 | <tomsmeding> | it doesn't even write the file until it's done? |
| 2024-04-29 23:11:44 +0200 | <shapr> | I can re-run with --test-show-details=direct if you want |
| 2024-04-29 23:11:33 +0200 | <shapr> | so either it's not writing to the file, or it writes at the end |
| 2024-04-29 23:11:25 +0200 | <shapr> | doctest.log is the only file |
| 2024-04-29 23:10:58 +0200 | <tomsmeding> | find dist-newstyle/ -name '*-test.log' |
| 2024-04-29 23:10:45 +0200 | andrewboltachev | (~andrewbol@178.141.238.156) (Quit: Client closed) |
| 2024-04-29 23:10:43 +0200 | <tomsmeding> | dist-newstyle/build/.../test/*-test.log |
| 2024-04-29 23:10:34 +0200 | <shapr> | oh |
| 2024-04-29 23:10:27 +0200 | <tomsmeding> | at it prints the log location when it's done |