Open jamespwilliams opened 2 years ago
jneira
commented
2 years ago @jamespwilliams hi, thanks for the bug report, as the cradle is a bios one, could you share the output to call directly the hie-bios program build/ihp-lib/.hie-bios, calld in th eproject root dir, where hie.yaml lives?
jamespwilliams
commented
2 years ago Hey, thanks for the response, build/ihp-lib/.hie-bios is a symlink to a file containing the following:
make print-ghc-options GHC_RTS_FLAGS='' | tr ' ' '\n' > "$HIE_BIOS_OUTPUT"
echo "$HIE_BIOS_ARG" >> "$HIE_BIOS_OUTPUT"
find . -name '*.hs' >> "$HIE_BIOS_OUTPUT"It fails when I try to execute it directly with the following error:
./build/ihp-lib/.hie-bios: 1: ./build/ihp-lib/.hie-bios: cannot create : Directory nonexistent
make: *** [/nix/store/31170mzlvjrhhl380kv4lj66dqpgpzxa-ghc-8.10.4-with-packages/bin/../lib/IHP/Makefile.dist:162: print-ghc-options] Broken pipe
./build/ihp-lib/.hie-bios: 2: ./build/ihp-lib/.hie-bios: cannot create : Directory nonexistent
./build/ihp-lib/.hie-bios: 3: ./build/ihp-lib/.hie-bios: cannot create : Directory nonexistentBut I think this is because HIE_BIOS_OUTPUT isn't defined. I'm not sure what the value of that would normally be when it's loaded by haskell-language-server. I'm unfamiliar with this stuff unfortunately. Perhaps this is an issue with IHP's configuration and not haskell-language-server itself.
jamespwilliams
commented
2 years ago Just tried export HIE_BIOS_OUTPUT=.hie-bios-output which makes build/ihp-lib/.hie-bios run without an error. But the issue of haskell-language-server -d . hanging still persists.
jamespwilliams
commented
2 years ago Hm, so I've done some reading and it seems like the output hie-bios check Main.hs might be relevant. It's taking a long time, been running at least 5 minutes, but it appears to be doing stuff according to strace, and it's using 100% of the CPU. I'm running this all on a fairly low-spec VM, so I wonder whether it's just running something really complicated and slow. But I'm not exactly sure what would be so complicated.
I'll leave it to run for a bit and see what happens. hie-bios debug Main.hs looks reasonable, I think:
$ hie-bios debug Main.hs
Root directory: /home/jpw/ihp/blog
Component directory: /home/jpw/ihp/blog
GHC options: -threaded -i. -ibuild -iConfig -iIHP -iIHP/IDE -XOverloadedStrings -XNoImplicitPrelude -XImplicitParams -XRank2Types -XDisambiguateRecordFields -XNamedFieldPuns -XDuplicateRecordFields -XOverloadedLabels -XFlexibleContexts -XTypeSynonymInstances -XFlexibleInstances -XQuasiQuotes -XTypeFamilies -XPackageImports -XScopedTypeVariables -XRecordWildCards -XTypeApplications -XDataKinds -XInstanceSigs -XDeriveGeneric -XMultiParamTypeClasses -XTypeOperators -XDeriveDataTypeable -XMultiWayIf -XUndecidableInstances -XBlockArguments -XPartialTypeSignatures -XLambdaCase -Wno-unsafe -Wno-name-shadowing -Wno-monomorphism-restriction -Wno-safe -Wno-missing-local-signatures -Wno-missing-home-modules -XDefaultSignatures -XEmptyDataDeriving -XBangPatterns -XBlockArguments -XMultiWayIf -XFunctionalDependencies -fbyte-code -Wno-partial-type-signatures -XPartialTypeSignatures -XStandaloneDeriving -XDerivingVia -Werror=missing-fields -fwarn-incomplete-patterns -XTemplateHaskell -j -package-env - -package ihp -rtsopts=all ./Application/Script/Prelude.hs ./Application/Helper/View.hs ./Application/Helper/Controller.hs ./build/Generated/Types.hs ./Web/Routes.hs ./Web/Types.hs ./Web/FrontController.hs ./Web/Controller/Prelude.hs ./Web/Controller/Static.hs ./Web/View/Prelude.hs ./Web/View/Static/Welcome.hs ./Web/View/Layout.hs ./Setup.hs ./Main.hs ./Config/Config.hs
GHC library directory: CradleSuccess "/nix/store/31170mzlvjrhhl380kv4lj66dqpgpzxa-ghc-8.10.4-with-packages/lib/ghc-8.10.4"
GHC version: CradleSuccess "8.10.4"
Config Location: /home/jpw/ihp/blog/hie.yaml
Cradle: Cradle {cradleRootDir = "/home/jpw/ihp/blog", cradleOptsProg = CradleAction: Bios}
Dependencies:
mpscholten
commented
2 years ago In IHP v0.15 we've upgrade the HLS to 1.4. Can you give that a try and report back if the problem is still appearing then?
barnabasmolnar
commented
2 years ago @mpscholten
Not the OP but I have a similar issue. Unfortunately upgrading hasn't solved the problem. Takes about 4 minutes or so on average for HLS to become operational/responsive. In my case, I'm running IHP in a WSL2 distro, not sure if that makes a difference.
jamespwilliams
commented
2 years ago I've updated my IHP (and in turn am now running HLS 1.4) - haskell-language-server -d . still hangs on "Type checking the files" seemingly indefinitely - I left it for an hour, with no progress, like before. Just like before, strace suggests that it's making no syscalls. See the issue description for an example strace log.
Here's the result of running hie-bios check Main.hs:
$ time hie-bios check Main.hs
Main.hs:9:1:Warning: The import of `Web.FrontController' is redundant
except perhaps to import instances from `Web.FrontController'
To import instances alone, use: import Web.FrontController()
Main.hs:12:1:Warning: Orphan instance:
instance IHP.RouterSupport.FrontController
IHP.FrameworkConfig.RootApplication
To avoid this
move the instance declaration to the module of the class or of the type, or
wrap the type with a newtype and declare the instance on the new type.
Main.hs:17:1:Warning: Orphan instance:
instance IHP.Job.Types.Worker IHP.FrameworkConfig.RootApplication
To avoid this
move the instance declaration to the module of the class or of the type, or
wrap the type with a newtype and declare the instance on the new type.
hie-bios check Main.hs 377.81s user 0.41s system 90% cpu 6:58.97 total
Your environment
Output of
haskell-language-server --probe-toolsorhaskell-language-server-wrapper --probe-tools:Which OS do you use: Debian 10
Which lsp-client do you use: N/A
Describe your project (alternative: link to the project): https://github.com/jamespwilliams/ihp-blog, this is the default project generated by
ihp-new(IHP is https://github.com/digitallyinduced/ihp)Contents of
hie.yaml:Steps to reproduce
Clone https://github.com/jamespwilliams/ihp-blog, run
haskell-language-server -d ..Expected behaviour
Not sure, but I expect some output rather than just hanging.
Actual behaviour
haskell-language-serverhangs at "Type checking the files". I've left it for half-an-hour and it's made no progress.Include debug information
Execute in the root of your project the command
haskell-language-server --debug .and paste the logs here:Debug output:
``` haskell-language-server version: 1.2.0.0 (GHC: 8.10.4) (PATH: /nix/store/f18pwxhycvvnsim59bzrnspgzcbq82dw-haskell-language-server-1.2.0.0/bin/haskell-language-server) ghcide setup tester in /home/jpw/ihp/blog. Report bugs at https://github.com/haskell/haskell-language-server/issues Step 1/4: Finding files to test in /home/jpw/ihp/blog Found 15 files Step 2/4: Looking for hie.yaml files that control setup Found 1 cradle (/home/jpw/ihp/blog/hie.yaml) Step 3/4: Initializing the IDE 2021-09-21 13:44:53.214250551 [ThreadId 7] DEBUG hls: Initializing exports map from hiedb 2021-09-21 13:44:53.214589829 [ThreadId 7] DEBUG hls: Done initializing exports map from hiedb (0) Step 4/4: Type checking the files ```Paste the logs from the lsp-client, e.g. for VS Code
LSP logs:
N/A (not actually using a LSP yet)strace logs:
Running `strace haskell-language-server -d .` yields the following at the end: ``` write(1, "tep 4/4: Type checking the files"..., 33tep 4/4: Type checking the files ) = 33 futex(0x864b108, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x864b110, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x6ecd438, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x862c40c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY ``` So it appears to be hanging on that final futex wait.