Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

windows binaries hanging/slow due to many files in PATH #791

Closed
simonmichael opened this issue May 30, 2018 · 2 comments
Closed

windows binaries hanging/slow due to many files in PATH #791

simonmichael opened this issue May 30, 2018 · 2 comments
Labels
A-BUG Something wrong, confusing or sub-standard in the software, docs, or user experience. packaging Dependencies, version constraints, packaging.. platform:windows

Comments

@simonmichael
Copy link
Owner

simonmichael commented May 30, 2018 •
edited
Loading

The windows binaries on the download page appear to hang at startup (eg hledger --version) on a windows 10 machine with some symbolic links present in %PATH%. A fresh dev build does not hang. I suspect the binaries (and stack-ghc8[02].yaml) need to be updated with a newer version of the directory lib which fixes this issue. This is currently blocked on appveyor build issues (the latest looks like commercialhaskell/stack#3950).
@simonmichael simonmichael added A-BUG Something wrong, confusing or sub-standard in the software, docs, or user experience. platform:windows packaging Dependencies, version constraints, packaging.. labels May 30, 2018
simonmichael added a commit that referenced this issue May 30, 2018
@simonmichael
windows: note issue url (#791)
93e61ec
@simonmichael simonmichael changed the title windows binaries hanging due to symlinks ? windows binaries hanging/slow due to many files in PATH May 30, 2018
@simonmichael
Copy link
Owner Author

simonmichael commented May 30, 2018 •
edited
Loading

The directory upgrade didn't help. Instead it was caused by "a very large amount of small text log files in \WINDOWS\System32".

It appeared that a newer build made with ghc 8.4 did not have the issue. Perhaps the newer base or directory packages made windows filesystem operations more efficient ?

Currently the windows binaries are built with ghc 8.2 to avoid
haskell/network#313 /
commercialhaskell/stack#3944 /
commercialhaskell/stack#4346 .

Actions:

  • switch the binaries to ghc 8.4 asap (when a workaround arrives for the above)
  • ideally, reproduce the issue, or at least mimic it on unix, and confirm/clarify the ghc 8.4 fix
  • look for efficiency gains in the addon-detecting code in Hledger.Cli.CliOptions

simonmichael added a commit that referenced this issue May 30, 2018
@simonmichael
site: download: windows: mention #791
0d989a8 
[ci skip]
@simonmichael
Copy link
Owner Author

Windows binaries are built with GHC 8.6 these days, I'm going to assume this is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-BUG Something wrong, confusing or sub-standard in the software, docs, or user experience. packaging Dependencies, version constraints, packaging.. platform:windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@simonmichael