Newest at the top
| 2024-10-15 16:23:48 +0200 | <yin> | got it. ty |
| 2024-10-15 16:18:10 +0200 | <[exa]> | in the meantime I'd just go library and have a commented out version which does the common stanza (so that you don't expose a library where you don't want to) |
| 2024-10-15 16:17:33 +0200 | <[exa]> | yin: like you can "autogenerate" them by copying them over, which will certainly cause HLS not to even think about touching them... so I'd say yes |
| 2024-10-15 16:15:56 +0200 | <yin> | [exa]: would this be an appropriate solution? https://cabal.readthedocs.io/en/3.4/cabal-package.html#autogenerated-modules-and-includes |
| 2024-10-15 16:09:57 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-10-15 16:09:18 +0200 | ash3en | (~Thunderbi@89.246.174.164) (Client Quit) |
| 2024-10-15 16:07:53 +0200 | ash3en | (~Thunderbi@89.246.174.164) ash3en |
| 2024-10-15 16:05:28 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-10-15 16:04:06 +0200 | petrichor | (~znc-user@user/petrichor) petrichor |
| 2024-10-15 16:03:26 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2024-10-15 16:03:07 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Remote host closed the connection) |
| 2024-10-15 16:02:08 +0200 | <yin> | [exa]: i see |
| 2024-10-15 16:01:36 +0200 | <[exa]> | https://cabal.readthedocs.io/en/3.4/cabal-package.html#common-stanzas |
| 2024-10-15 16:01:32 +0200 | <[exa]> | in your case you'll probably need the library to disambiguate. By common I meant the common stanza, which doesn't solve it |
| 2024-10-15 16:01:12 +0200 | CiaoSen | (~Jura@2a05:5800:211:b700:ca4b:d6ff:fec1:99da) (Ping timeout: 252 seconds) |
| 2024-10-15 16:00:12 +0200 | <yin> | i'm trying `library shared`. what did you mean by "common"? |
| 2024-10-15 16:00:02 +0200 | <[exa]> | it needs to pick a configuration, so you could just say "use the app one for this" |
| 2024-10-15 15:59:50 +0200 | <[exa]> | can you configure HLS to default safely somehow? |
| 2024-10-15 15:58:35 +0200 | <yin> | but there has to be a way to get around it |
| 2024-10-15 15:58:27 +0200 | <yin> | i imagine so |
| 2024-10-15 15:58:19 +0200 | <[exa]> | ok that's more of a HLS issue then I guess |
| 2024-10-15 15:58:02 +0200 | <[exa]> | ahhhhhhh so |
| 2024-10-15 15:56:52 +0200 | <yin> | this is my problem ^ |
| 2024-10-15 15:56:34 +0200 | <yin> | the thing is, if i add `hs-source-dirs: test, app` to my test executable section of the .cabal file, the language server complains about the module being an ambiguous target :/ |
| 2024-10-15 15:55:33 +0200 | <[exa]> | the problem is that you have a long list of modules in the executable and in the test sections, right? |
| 2024-10-15 15:53:00 +0200 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-10-15 15:52:10 +0200 | <yin> | [exa]: oh i'm not really sure what you mean |
| 2024-10-15 15:51:56 +0200 | <yin> | [exa]: yes but this feels weird. it's not really a library, it's a module for main. the test executable uses it because, well, it's testing it |
| 2024-10-15 15:51:17 +0200 | <[exa]> | (`common` & `import` in the cabal file should do that) |
| 2024-10-15 15:50:42 +0200 | <[exa]> | yin: you should be able to share the common values somehow to just avoid copypaste right? |
| 2024-10-15 15:49:27 +0200 | <[exa]> | generally any concurrency models out there don't play very happily with the signal handling |
| 2024-10-15 15:49:18 +0200 | <yin> | should i use a library section instead of having an other-modules field in both my main and test executables? |
| 2024-10-15 15:48:47 +0200 | <[exa]> | also quite surprising that the ctrl+c may be delivered elsewhere and discarded there |
| 2024-10-15 15:48:32 +0200 | <[exa]> | like, you're certainly not the last person solving this here :) |
| 2024-10-15 15:47:27 +0200 | Square | (~Square4@user/square) Square |
| 2024-10-15 15:46:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-10-15 15:46:40 +0200 | hgolden__ | (~hgolden@static-198-44-129-115.cust.tzulo.com) (Ping timeout: 244 seconds) |
| 2024-10-15 15:46:26 +0200 | <haskellbridge> | <hellwolf> Maybe I should have a program level of C-c check; I will read that article you sent. Thanks. |
| 2024-10-15 15:45:03 +0200 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/tpZzlfdRhDNQsmsyRCoQScYT/r4rovgobKJ4 (3 lines) |
| 2024-10-15 15:45:03 +0200 | <haskellbridge> | <hellwolf> https://hackage.haskell.org/package/temporary-1.3/docs/src/System.IO.Temp.html#withTempDirectory |
| 2024-10-15 15:44:08 +0200 | hgolden_ | (~hgolden@169.150.203.10) hgolden |
| 2024-10-15 15:43:49 +0200 | <[exa]> | anyway afaik the bracket there should be removing the directory no matter what |
| 2024-10-15 15:42:38 +0200 | <[exa]> | http://neilmitchell.blogspot.com/2015/05/handling-control-c-in-haskell.html quite relevant |
| 2024-10-15 15:42:27 +0200 | <haskellbridge> | <hellwolf> but probably that withSystemTempDirectory didn't use bracket. |
| 2024-10-15 15:42:17 +0200 | <haskellbridge> | <hellwolf> I would have expected bracket style code can clean up things even when SIGINT/SIGEXIT is involved |
| 2024-10-15 15:40:56 +0200 | <[exa]> | ah signals |
| 2024-10-15 15:38:15 +0200 | <haskellbridge> | <hellwolf> I might need to read into withSystemTempDirectory or use my own withSystemTempDirectory if it has flaws. |
| 2024-10-15 15:37:58 +0200 | <haskellbridge> | more damning problem is that the library code "withSystemTempDirectory" doesn't clean up the temp directory when I use ^C... that's annoying af |
| 2024-10-15 15:37:58 +0200 | <haskellbridge> | <hellwolf> so perhaps I should give it up for a while. |
| 2024-10-15 15:37:19 +0200 | <haskellbridge> | <hellwolf> alright, I will try a bit more another day. In this particular case, I am not sure if I can get much from withCreateProces vs createProcess. |