Closed eposse closed 3 years ago
So the project fails to build. Either something's changed on the Hackage side, or perhaps you've changed the project config and forgot about it.
Anywho, I suspect that the version bound for QuickCheck specified in mparseco.cabal
is incorrect. There isn't a 2.14.2.0
version of QuickCheck available, only 2.14.2
. I believe, if you fix that, stuff should work (or at least complain about something else)
Thanks. It was indeed the QuickCheck version.
Yet, I do have another problem. I'm not sure it's a bug or not, so I don't know if I should open a new issue. Basically the problem now is that when I try to open the REPL on Atom for the file that defines the executable of my project it fails with the following:
Could not load module ‘Test.QuickCheck’
It is a member of the hidden package ‘QuickCheck-2.14.2’.
Perhaps you need to add ‘QuickCheck’ to the build-depends in your .cabal file.
It is a member of the hidden package ‘QuickCheck-2.13.2’.
Perhaps you need to add ‘QuickCheck’ to the build-depends in your .cabal file.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
But QuickCheck is on the build-depends of my cabal file!
The cabal file is as follows:
cabal-version: 3.0
-- Initial package description 'mparseco.cabal' generated by 'cabal init'.
-- For further documentation, see http://haskell.org/cabal/users-guide/
name: mparseco
version: 0.1.0.0
synopsis: A minimal monadic parsing combinator library.
description: mperseco is a minimalist monadic parser combinator library. It is essentially an implementation of the parsing combinators from Philip Wadler's seminal paper "[Monads for functional programming](https://link.springer.com/chapter/10.1007/978-3-662-02880-3_8)". It can be seen as a minimal subset of Haskell's well known library "[parsec](https://hackage.haskell.org/package/parsec)".
homepage: https://github.com/eposse/mperseco
-- bug-reports:
-- license:
license-file: LICENSE
author: Ernesto Posse
maintainer: eposse@gmail.com
copyright: (c) 2021-2025 Ernesto Posse
category: Parsing
stability: experimental
extra-source-files: CHANGELOG.md, README.md
tested-with: GHC == 8.8.3
library
exposed-modules: Mparseco
other-modules:
Mparseco.BasicParsers,
Mparseco.Core,
Mparseco.Tokenizer,
Mparseco.Utils
-- other-extensions:
build-depends: base ^>=4.13.0.0
hs-source-dirs: src
default-language: Haskell2010
test-suite mparseco-test
type: detailed-0.9
test-module: MparsecoTests
other-modules:
MparsecoTests.Properties,
MparsecoTests.Generators,
Mparseco,
Mparseco.BasicParsers,
Mparseco.Core,
Mparseco.Tokenizer,
Mparseco.Utils
hs-source-dirs: tests, src
build-depends:
base ^>=4.13.0.0,
Cabal ^>= 3.0.0.0,
QuickCheck,
cabal-test-quickcheck,
mparseco
default-language: Haskell2010
executable mparsecoexample
main-is: MparsecoExample.hs
other-modules:
Mparseco,
Mparseco.BasicParsers,
Mparseco.Core,
Mparseco.Tokenizer,
Mparseco.Utils
build-depends:
base ^>=4.13.0.0,
Cabal ^>= 3.0.0.0,
QuickCheck,
cabal-test-quickcheck,
mparseco
hs-source-dirs: examples, src
default-language: Haskell2010
The file I'm trying to run on REPL is MparsecoExample.hs.
When I build and run it in the command line with
cabal build
cabal run mparsecoexample
it runs correctly. Furthermore, the following also works correctly on the command-line:
cabal repl mparsecoexample
So it is something about opening REPL in Atom. What could be the problem? Why does ide-haskell-repl fail to find QuickCheck? I can't find any settings related to the libraries, and I have everything on default settings.
Hmm. Perhaps the component is misidentified, hence QuickCheck isn't brought into scope. Is this project open source? Can I find it somewhere to run some tests?
One culprit I can think of is that ide-haskell stack uses a somewhat old Cabal implementation to parse cabalfiles, perhaps it's unable to parse your cabalfile either because of some new stanza (I don't see any from a glance though) or simply because cabal-version
is too high. cabal-version: 1.12
is known to work. Yes, I know I need to update the cabalfile parser. Regrettably, it's a little complicated since it relies on poking through GHCJS internals. Perhaps I just need to change my approach and use a helper binary instead, but this will likely create compatibility issues. Anyway, if you can't share the project, try lowering the cabal-version
, perhaps that would work.
I've made the repo public at: https://github.com/eposse/mparseco.git. Try the 'tokex' branch.
I've tried setting cabal-version: 1.12 but I got a whole bunch of new errors, even after I updated the version range syntax to the old style: see the 'old-cabal' branch.
Okay, so I was right, apparently. Regrettably. I've tried to slap a fix together, but it's a little wonky. I need help testing before I'm confident enough to release.
So, the current state of GHCJS is... not great. I've tried an alternative (that being asterius), but it crashed and burned in many curious ways the moment I tried to parse some cabalfiles, so probably not a great option.
So helper binaries it is then. I've currently just put those into an npm package; I have no idea if any of those work at all, besides the Linux one, and they aren't small. For that reason, I'm not yet releasing the new version which uses those, but you can test the current master by cloning this repo then running apm install && apm link
in the cloned source tree root (warning: you'll end up downloading roughly 10MB of packaged binaries; those binaries are from https://github.com/atom-haskell/cabal2json, built on GitHub Actions)
I'm very curious as to the results, since testing on macOS is very complicated for me.
Honestly, I'm really not a fan of this "silently download binaries on installation" approach; I'm open to suggestions.
Sorry for the stream of consciousness, but it's 5:50 am here, and I really should've been sleeping by now.
Thanks, I'll try it tomorrow and post the results here.
The good news is: I've managed to figure out what's currently going on with GHCJS (zero docs, found some info in a random tweet)
Long story short, I've switched out the binaries for a nodejs executable script. This should be less prone to random breakage on different platforms, so I've released the updated ide-haskell-repl and ide-haskell-cabal. I still need to verify it works on Windows (because different path separators), but other than that it should work (fingers crossed).
Sorry this took a while.
tl;dr for posterity, iohk/haskell.nix has GHCJS based off GHC 8.10.5, but have to build it -- takes a few hours at best; I've set up a binary cache on cachix which has ghcjs derivations cached, currently based on nixpkgs-2105 and input-output-hk/haskell.nix@f9d261d6d90d4aebd97f7ae60c951fc9e1d98493; see https://github.com/atom-haskell/cabal2json/blob/master/default.nix for updates (which are not especially probable in the near future, but who knows)
Ok, I've installed the new versions of ide-haskell-repl and ide-haskell-cabal.
Overall it worked, but the first time I opened REPL it took quite a while, and I thought it was stuck. Subsequent times seem to be fast.
There is however one other thing is that I still get the following warnings:
<no location info>: warning: [-Wmissing-home-modules]
These modules are needed for compilation but not listed in your .cabal file's other-modules:
Mparseco
Mparseco.BasicParsers
Mparseco.Core
Mparseco.Tokenizer
Mparseco.Utils
Warning: The package has an extraneous version range for a dependency on an
internal library: mparseco -any && ==0.1.0.0, mparseco -any && ==0.1.0.0. This
version range includes the current package but isn't needed as the current
package's library will always be used.
The first warning seems wrong: the modules are listed in the "other-modules" section of the cabal file (both the library and the executable).
The second warning about the "extraneous version range" is very strange, as the cabal file doesn't specify that at all. This warning appears only the first time REPL is launched, though.
Sorry this took a while.
Not at all! I reported this on Saturday, and a working solution by Tuesday is a pretty quick turn-around!
Thanks!
the first time I opened REPL it took quite a while
cabal repl
may do quite a bit of stuff on the first launch. Building the project before starting repl helps in this regard.
Other than that, there is a relatively recent quirk in Atom where it semi-randomly suspends the event loop; doing some input, like clicking the mouse or typing something, wakes it up; this has an unfortunate consequence that working with external processes can "hang" indefinitely (until the event loop is woken up). It's easy enough to work around this for one-shot processes by forcefully spinning the event loop, but the workaround doesn't work with GHCi all that well. I'll see what I can do, though.
-Wmissing-home-modules
This is a quirk of GHCi, see https://github.com/haskell/cabal/issues/5917. The solution is probably to pass -Wno-missing-home-modules
explicitly, but this might break on earlier GHC versions. So I choose to ignore this for now.
Warning: The package has an extraneous version range
This is actually a bug in cabal, see e.g. https://github.com/haskell/cabal/pull/7470#issuecomment-875878507 ; not much I can do on my end except filtering that out explicitly, and I don't really like such ad-hoc solutions, they tend to haunt the code base forever.
FWIW, the last two issues happen during normal GHCi operation, and are not exclusive to ide-haskell-repl.
Ok, understood.
As far as I'm concerned the issue can be closed.
Thanks!
[Enter steps to reproduce:]
The project is local.
Throws the TypeError exception below, and a "Process crashed" message shown below.
Atom: 1.57.0 x64 Electron: 9.4.4 OS: Mac OS X 10.15.7 Thrown From: ide-haskell-repl package 0.10.1
Stack Trace
TypeError: Cannot read property 'stderr' of undefined
Error message
Process crashed while running request:
Commands
Non-Core Packages