Newest at the top
| 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. |
| 2025-01-08 20:05:51 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-01-08 20:05:39 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 20:02:30 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2025-01-08 19:56:21 +0100 | Guest20 | (~Guest20@136.158.16.131) () |
| 2025-01-08 19:56:11 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-08 19:55:53 +0100 | Guest20 | (~Guest20@136.158.16.131) |
| 2025-01-08 19:51:53 +0100 | <mari41300> | well does not sound wrong but not sure whether the structure of the cabal file could affect compilation in the interpreter. I would be surprised |
| 2025-01-08 19:48:05 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-01-08 19:46:43 +0100 | <smiesner> | maybe that's the wrong way? |
| 2025-01-08 19:46:33 +0100 | <smiesner> | i list Lexer and Parser (as i named the modules) in exposed-modules of the library in my cabal file |
| 2025-01-08 19:45:40 +0100 | <mari41300> | hmm single package then |
| 2025-01-08 19:45:39 +0100 | <smiesner> | :r does not rebuild the parsers |
| 2025-01-08 19:45:18 +0100 | <smiesner> | my project? so far only happy and alex files :) |
| 2025-01-08 19:44:40 +0100 | fun-safe-math | (~fun-safe-@2601:1c2:1b7f:801f:9be8:50a:7d0a:fa49) fun-safe-math |
| 2025-01-08 19:44:21 +0100 | <mari41300> | not sure, i think recompiling worked fine for me when i had the chance to leverage the repl. Maybe a complex project with multiple packages? |