2024/12/28

Newest at the top

2024-12-28 12:55:00 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2024-12-28 12:54:46 +0100 <SrPx> is it possible to reload ghci with an actual function, not ':r'? i'm trying to call it from an IO block
2024-12-28 12:52:41 +0100acidjnk_new3(~acidjnk@p200300d6e7283f42bc4ebb891d7561a4.dip0.t-ipconnect.de) acidjnk
2024-12-28 12:50:36 +0100euleritian(~euleritia@dynamic-176-007-157-163.176.7.pool.telefonica.de) (Ping timeout: 252 seconds)
2024-12-28 12:50:09 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-12-28 12:49:45 +0100tv(~tv@user/tv) tv
2024-12-28 12:48:07 +0100 <Leary> SrPx: You don't need to run anything; it runs automatically when you save changes to the files.
2024-12-28 12:45:26 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-12-28 12:42:47 +0100 <SrPx> basically just open the repl and watch a named pipe for a lightweight communication between my VIM and it
2024-12-28 12:41:59 +0100 <SrPx> oh never mind sonnet provided an easy / obvious solution
2024-12-28 12:40:40 +0100lxsameer(~lxsameer@Serene/lxsameer) lxsameer
2024-12-28 12:39:09 +0100 <SrPx> __monty__: every time I make a change it takes that amount of time. yet `:r` on the repl is instant. so ideally all I need is a way to talk to the repl (from another terminal) quickly. almost considering spawning a socket but there must be a built in way
2024-12-28 12:37:51 +0100tnt2tnt1
2024-12-28 12:37:51 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 265 seconds)
2024-12-28 12:37:05 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2024-12-28 12:36:48 +0100 <__monty__> SrPx: Is it too slow just the first time or every time? I don't think you can speed up `cabal run` much but maybe watching the files with something like ghcid or entr and running `cabal build` whenever the project changes will avoid having to pay the full price of compilation the moment you run code from your editor?
2024-12-28 12:36:00 +0100acidjnk_new3(~acidjnk@p200300d6e7283f42bc4ebb891d7561a4.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2024-12-28 12:32:34 +0100 <SrPx> yes but it is still a repl, not sure how that helps with running it from a separate terminal?
2024-12-28 12:32:28 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-12-28 12:31:56 +0100tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2024-12-28 12:31:20 +0100ljdarj1ljdarj
2024-12-28 12:31:20 +0100ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 260 seconds)
2024-12-28 12:31:08 +0100ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2024-12-28 12:29:34 +0100 <Leary> It watches your source and test files for changes and reloads a repl in the background.
2024-12-28 12:28:58 +0100 <SrPx> that would be ideal
2024-12-28 12:28:54 +0100 <SrPx> Leary: I've seen ghciwatch but it seemed unrelated, so you mean it can keep a repl open, and then allow me to access it in a separate terminal?
2024-12-28 12:28:18 +0100 <mauke> (IIRC there is no 'optimization' setting in *.cabal files; you'd have to do soemthing like 'ghc-options: -O2')
2024-12-28 12:28:12 +0100 <Leary> SrPx: When I say repl, I really mean indirectly via ghcid/ghciwatch, as I recommended earlier. They can run `-- $> <code>` comments embedded in haskell files and be made to watch e.g. your .hvml test file for changes.
2024-12-28 12:28:04 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-12-28 12:27:20 +0100 <mauke> yes
2024-12-28 12:26:42 +0100 <SrPx> I had to set 'optimization: 2' on cabal.project because setting it on HVM3.cabal was being ignored for some reason
2024-12-28 12:26:09 +0100 <SrPx> that goes in cabal.project?
2024-12-28 12:25:37 +0100 <mauke> just set the optimization level to 1 or 0 for dev
2024-12-28 12:25:08 +0100 <SrPx> __monty__: yes but it seems like `cabal run hvml` is slower than `:r` on `cabal repl` (which is quite fast it seems)
2024-12-28 12:24:02 +0100euleritian(~euleritia@dynamic-176-007-157-163.176.7.pool.telefonica.de)
2024-12-28 12:23:17 +0100 <__monty__> Just have your editor run `cabal run hvml` instead of `hvml`? (Modulo `--` to pass options to hvml rather than Cabal or something.)
2024-12-28 12:22:57 +0100 <SrPx> because if I'm editing "foo.hvml" I want to be able to run it there, rather than moving to another tab (of the cabal repl) and typing its full path
2024-12-28 12:22:23 +0100 <SrPx> so basically you're saying I need to use the repl instead of my editor to run files I test, which kinda sucks
2024-12-28 12:21:43 +0100 <SrPx> Leary: that doesn't fit my project. it is a language and I'm iteratively extending it and testing (by opening foo.hvml files and running them on my editor). so, I need a quick feedback loop where I change something on the Haskell project, move to my editor, and run an hvml file there
2024-12-28 12:20:04 +0100 <Leary> `cabal install` is not intended for development. Things that can be tested with interpreted code should be run in repl, things that need compilation should be `test-suite`s or `benchmark`s in your .cabal file with appropriate optimisation flags.
2024-12-28 12:19:23 +0100 <SrPx> ah that's better but still takes ~3s
2024-12-28 12:18:55 +0100sawilagar(~sawilagar@user/sawilagar) sawilagar
2024-12-28 12:18:30 +0100sawilagar(~sawilagar@user/sawilagar) (Remote host closed the connection)
2024-12-28 12:18:24 +0100 <mauke> any reason you're not using 'cabal run'?
2024-12-28 12:17:12 +0100 <SrPx> but I'd like to call it from a standalone terminal, not from inside cabal repl. can I replicate that quick reload without having to be inside cabal repl?
2024-12-28 12:16:31 +0100 <SrPx> im testing cabal repl and it seems to work decently enough, without optimizations though
2024-12-28 12:16:24 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-12-28 12:15:59 +0100 <SrPx> that's how I work usually, but cabal install taking forever is making this miserable
2024-12-28 12:15:40 +0100 <SrPx> mauke: 1. make some change to the project. 2. cabal install. 3. run the file I want to test (ex: 'hvml run my_file.hvml').
2024-12-28 12:12:54 +0100 <mauke> heh, that readme is functionally meaningless