Newest at the top
| 2025-01-08 21:07:00 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-08 21:04:40 +0100 | visilii | (~visilii@213.24.125.237) (Ping timeout: 265 seconds) |
| 2025-01-08 21:03:50 +0100 | hseg | (~gesh@46.120.21.249) (Ping timeout: 272 seconds) |
| 2025-01-08 21:00:44 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-08 21:00:35 +0100 | visilii_ | (~visilii@188.254.110.9) |
| 2025-01-08 21:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-08 20:55:56 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-08 20:55:26 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-08 20:53:50 +0100 | <c_wraith> | I might need to compile it as a sublibrary |
| 2025-01-08 20:53:26 +0100 | <c_wraith> | Huh. Looks like cabal might override the -O2 in an OPTIONS_GHC pragma |
| 2025-01-08 20:52:07 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-08 20:41:28 +0100 | raym | (~ray@user/raym) raym |
| 2025-01-08 20:35:57 +0100 | <tomsmeding> | which sounds like what you want here |
| 2025-01-08 20:35:51 +0100 | <tomsmeding> | > So GHC guarantees to inline precisely the code that you wrote, no more and no less. |
| 2025-01-08 20:35:44 +0100 | <tomsmeding> | but the GHC user's guide says: ( https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#inline-and-noinline-pr… ) |
| 2025-01-08 20:35:15 +0100 | <tomsmeding> | yeah this may be too much trickery |
| 2025-01-08 20:33:15 +0100 | <c_wraith> | Huh. Not sure how INLINE interacts with this. |
| 2025-01-08 20:30:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-08 20:28:16 +0100 | <tomsmeding> | ctrl-D is often faster than typing "exit" ... oh too late |
| 2025-01-08 20:28:10 +0100 | mari41300 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-08 20:28:06 +0100 | <mari41300> | sorry i'm tired. See you all o/ |
| 2025-01-08 20:27:55 +0100 | <mari41300> | :P |
| 2025-01-08 20:27:51 +0100 | <mari41300> | exit |
| 2025-01-08 20:27:37 +0100 | <tomsmeding> | c_wraith: is it just one function? mark them as INLINE, use them (trivially, in a wrapper function) in two separate modules, compile those two modules with different options? |
| 2025-01-08 20:27:21 +0100 | <smiesner> | thanks all :) |
| 2025-01-08 20:27:08 +0100 | <smiesner> | tomsmeding: will try that for sure! |
| 2025-01-08 20:24:02 +0100 | <tomsmeding> | if that works, then you can `:def R \_ -> Prelude.return ":!cabal build\n:r"` to define a ghci command :R that first builds and then reloads ;) |
| 2025-01-08 20:23:37 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-01-08 20:23:13 +0100 | <tomsmeding> | smiesner: also try running 'cabal build' in another terminal, and then :r |
| 2025-01-08 20:21:37 +0100 | l__k | (~student@188.254.126.139) (Ping timeout: 252 seconds) |
| 2025-01-08 20:18:53 +0100 | l_k | (~student@213.24.133.217) |
| 2025-01-08 20:18:23 +0100 | plitter | (~plitter@user/plitter) plitter |
| 2025-01-08 20:17:20 +0100 | OftenFaded53 | (~OftenFade@user/tisktisk) () |
| 2025-01-08 20:17:11 +0100 | <c_wraith> | (my point is to demonstrate how much easier a time GHC has when you write code that's easily amenable to optimization, instead of making it apply the slow -O2 stuff to find places to optimize) |
| 2025-01-08 20:15:49 +0100 | <c_wraith> | usually you'd only run benchmarks with the options you're actually using. My case is uncommon in that what I really want to demonstrate is the difference between them. (One benchmark is unaffected, a different one improves immensely) |
| 2025-01-08 20:14:55 +0100 | <mari41300> | well i guess it would be common for benchs to be run multiple times with different opts |
| 2025-01-08 20:14:10 +0100 | l_k | (~student@81.177.126.233) (Ping timeout: 252 seconds) |
| 2025-01-08 20:14:02 +0100 | <c_wraith> | err, benchmark suite |
| 2025-01-08 20:13:55 +0100 | <c_wraith> | mari41300: I can't compile my test suite with -O1 and -O2 simultaneously. The best I could manage is moving it into multiple modules with different ghc options per module and duplicating the definition between multiple modules. That's not great for maintainability |
| 2025-01-08 20:13:34 +0100 | OftenFaded53 | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-08 20:11:26 +0100 | <mari41300> | i did not get what you meant c_wraith |
| 2025-01-08 20:11:24 +0100 | l__k | (~student@188.254.126.139) |
| 2025-01-08 20:10:14 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-08 20:10:04 +0100 | <mari41300> | hm but odd that the cabal repl does not detect changes cabal build would |
| 2025-01-08 20:08:57 +0100 | <haskellbridge> | <sm> also, if you are reloading a lot, I find this really useful in .ghci: :def rmain \args -> return $ ":reload\n:main "<>args |
| 2025-01-08 20:08:34 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-01-08 20:08:01 +0100 | <haskellbridge> | <sm> I meant, try to get ghcid doing the regeneration as well as compilation. Or, and this might be simpler, run watchexec to regenerate the parser continually, and just reload ghci when you need |
| 2025-01-08 20:07:16 +0100 | <smiesner> | thanks, will look into it! |
| 2025-01-08 20:06:16 +0100 | <haskellbridge> | <sm> smiesner: ghcid is flexible in which ghci commands it can run on change, including :! shell commands I expect. I'd try to get that working in a side window. Then if you :r in your ghci window the parser will already be regenerated. |
| 2025-01-08 20:06:11 +0100 | <c_wraith> | huh. I found a case where I'd really like to benchmark the difference between -O2 and default in a single criterion suite, but... uh... The levels don't work right for that. |