Newest at the top
| 2026-02-12 04:41:00 +0100 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-20-76-67-111-168.dsl.bell.ca) (Remote host closed the connection) |
| 2026-02-12 04:34:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-12 04:31:58 +0100 | Square | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2026-02-12 04:30:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-12 04:25:52 +0100 | Square | (~Square4@user/square) Square |
| 2026-02-12 04:25:12 +0100 | Square | (~Square4@user/square) (Remote host closed the connection) |
| 2026-02-12 04:19:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2026-02-12 04:17:09 +0100 | td_ | (~td@i5387091F.versanet.de) td_ |
| 2026-02-12 04:15:16 +0100 | td_ | (~td@i5387093E.versanet.de) (Ping timeout: 246 seconds) |
| 2026-02-12 04:15:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-12 04:05:25 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2026-02-12 04:00:39 +0100 | <geekosaur> | occasionally clearing hie-bios's cache (~/.cache/hie-bios) helps, if it gets corrupted then things may get rebuilt unexpectedly |
| 2026-02-12 03:57:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-12 03:54:06 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-02-12 03:53:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-12 03:49:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-02-12 03:47:07 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 264 seconds) |
| 2026-02-12 03:42:21 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-02-12 03:41:57 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-02-12 03:35:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-12 03:33:56 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-02-12 03:33:07 +0100 | <feetwind> | `cabal repl all --enable-multi-repl` seemingly works as it ought to, not trying to rebuild transitive deps of each target, even if one's build fails along the way. that's pretty useful actually even tho multi repl is limited |
| 2026-02-12 03:27:23 +0100 | <haskellbridge> | <sm> and would be easier to troubleshoot outside of HLS |
| 2026-02-12 03:27:09 +0100 | <haskellbridge> | <sm> if you can figure out what it's doing, maybe you can test the same commands at cli and see if there's excessive rebuilding going on or something. This is pretty common |
| 2026-02-12 03:25:25 +0100 | <feetwind> | but otoh nice to not have such a long build if `subcmd` is just a little test script or whatever. ah well |
| 2026-02-12 03:24:28 +0100 | <feetwind> | i will see if just having lots of hie components is behind very long waits sometimes, probably nicer to have my app as `app subcmd ...` |
| 2026-02-12 03:24:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-12 03:22:50 +0100 | <haskellbridge> | <sm> it's not super robust. But it's valuable enough to be worth babysitting |
| 2026-02-12 03:22:03 +0100 | <feetwind> | yeah that's what i end up doing, but then that was what hls was supposed to help with in the first place ๎นป |
| 2026-02-12 03:21:30 +0100 | <haskellbridge> | <sm> one of the things that may help is ensuring your project has built cleanly before starting hls |
| 2026-02-12 03:20:21 +0100 | <haskellbridge> | <sm> persistent startup errors usually require more careful troubleshooting |
| 2026-02-12 03:19:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-12 03:19:58 +0100 | <haskellbridge> | <sm> I'm used to restarting it any time things stop working. Can be several times a day depending what I'm doing |
| 2026-02-12 03:19:40 +0100 | <feetwind> | hm fair enough/good to hear. i struggle a lot with it hanging on startup if there's a type/out of scope error in some module in lib, depended on by one or more exes or tests, which seems to cause many (maybe infinite?) attempts to rebuild. it surprises me that -fdefer-type-errors and co don't let the lsp proceed anyway |
| 2026-02-12 03:16:47 +0100 | <geekosaur> | and my xmonad dev environment (the various xmonad-related packages plus my own config as a separate package) |
| 2026-02-12 03:15:54 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
| 2026-02-12 03:14:58 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Read error: Connection reset by peer) |
| 2026-02-12 03:14:13 +0100 | <geekosaur> | I use it a fair bit on the cabal codebase itself (14 packages, mostly internal) without problems |
| 2026-02-12 03:09:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-12 03:07:05 +0100 | <feetwind> | do people have good experiences [i.e., doesnt crash or hang "randomly"] with haskell-language-server in multi cabal pkg projects? |
| 2026-02-12 03:05:50 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-02-12 03:05:20 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-02-12 03:04:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-12 03:03:53 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 260 seconds) |
| 2026-02-12 03:02:37 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
| 2026-02-12 03:00:30 +0100 | ezzieygu1wuf | (~Unknown@user/ezzieyguywuf) (Read error: Connection reset by peer) |
| 2026-02-12 02:59:30 +0100 | otto_s | (~user@p4ff27e90.dip0.t-ipconnect.de) |
| 2026-02-12 02:57:55 +0100 | otto_s | (~user@p4ff27fce.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2026-02-12 02:55:08 +0100 | Square2 | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2026-02-12 02:54:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |