I'm getting the following error when trying to install the contravariant library (which is needed for lens) with Cabal:
``src/Data/Functor/Contravariant.hs:96:1:
StateVar-1.1.0.0:Data.StateVar can't be safely imported! The module itself isn't safe.''
I've not had any success googling solutions, and tried a few fixes (such as getting rid of all my Haskell packages (with ``rm -r ~/.ghc'') and starting again), but I'm not really clear on what's causing this error to occur. I'm using ghc 7.4.1 - could that be the problem?
Thanks,
Reuben
Posting the correct answer from comments as community-wiki:
Looks like you're being hit by interactions between an old GHC and the
lack of Safe Haskell annotations (in the library) that are redundant
with newer GHC versions. Cf. http://github.com/ekmett/ersatz/issues/13
Related
I'm trying to compile a Salesforce sfdx plugin which is a node project with (among others) the following dependency chain that ultimately leads to fake-timers#^7.1.0:
#salesforce/command#2.2.0 -> #oclif/test#^1.2.4 -> fancy-test#^1.4.3 -> #types/sinon#* -> #sinonjs/fake-timers#^7.1.0.
When compiling it with the Typescript compiler tsc, I get the following error:
node_modules/#sinonjs/fake-timers/types/fake-timers-src.d.ts:11:28 - error TS2304: Cannot find name 'queueMicrotask'.
11 queueMicrotask: typeof queueMicrotask;
~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 1.
This looks like a bug in fake-timers-src.d.ts but introduced in 7.1.0 so I could try to lock the version at 7.0.5 but that might break all kinds of other things.
Does anybody who uses/maintains fake-timers know how to fix this? Or will this be fixed in a future version?
BTW I'm a total NodeJS n00b so if there's something really obvious here that I'm missing, please be kind and just tell me what it is :)
Thanks!
Frans
Frans! fatso83 from the Sinon team here :)
The problem here has all to do with TypeScript and nothing to do with Node, so I feel your pain. No wonder you are wondering. The problem is that the definitions are probably missing that property. For version 7 we tried to generate TypeScript definitions from JSDoc. This works reasonably well for simpler type, but ultimately, TypeScript is more powerful in describing types than JSDoc (like the typeof operator), so it was an uphill battle that would never result in the same quality as the types available from the external Definitely Typed project. We ended up abandoning that effort and therefore this will not be fixed, but it will naturally go away with version 8 (that will not be shipping its own types).
What you can do is this: npm install #sinonjs/fake-timers#6 (which is the previous version) and npm install #types/sinonjs__fake-timers#6 (which are the externally maintained types).
You might find some background for this in this issue.
In a Haskell project, I am using a dependency which I know contains type error. But that's actually fine as I never call this code.
So I want to enable defer-type-errors but only for that dependent package.
Is there a way to scope that compiler instruction somewhere (stack ? cabal?)
If you really have to you can set ghc options per package in stack.yaml, namely:
ghc-options:
your_package_name: -fdefer-type-errors
I'm not sure whether it's compatible with ghcjs.
But please be sure to make the users of your package aware, maybe include a disclaimer in the document in big bold fonts.
I created some code in the past which use Data.Bytestring.Lazy. Now, when I try to compile it, everithing what I get is a bunch of errors. Example of error:
Couldn't match expected type `BL.ByteString'
with actual type `bytestring-0.10.0.2:Data.ByteString.Lazy.Internal.ByteString'
In the return type of a call of `decompress'
In the second argument of `decrypt', namely `(decompress fc)'
In the second argument of `BL.filter', namely
`(decrypt (extractKey tkey) (decompress fc))'
... And many errors like this ...
My import of bytestring: import Data.ByteString.Lazy as BL.
What to do with this?
EDIT:
THANKS for help. With explicit package version, everything works fine. But, I don't like this solution. When I try to unregister one of the two installed bytestring packages. Many packages will be broken. The newest package version break small amount of packages (no core packages). How to repair packeges which are destroyed by unregistering package?
EDIT:
No, it's not working fine with explicit package version. I wrote edit before I tried it physically. It was mistake. Nothing works.
Yes, I have solved the problem. The evil package was zlib which uses old version of bytestring, but all packages for encryption uses the new version. When I threw away code for compression, my program compiled. Now, I'm looking for some compression algorithms...
When running Haskell programs that import several packages like this one:
import Text.Feed.Import
import Network.HTTP
main = do
page <- simpleHTTP (getRequest "http://stackoverflow.com")
print $ page
I get an error like this one (Note: This question intends to solve the general problem, this specific case is just an example) :
GHCi runtime linker: fatal error: I found a duplicate definition for symbol get_current_timezone_seconds
whilst processing object file
/usr/lib/ghc/time-1.4.0.1/HStime-1.4.0.1.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry
Reinstalling the packages (e.g. HTTP and feed in the above case) as described in this previous post doesn't help. How can I resolve this issue?
Why this error occurs
This issue is not specific to a single package (e.g. it was described here in relation to Yesod three years ago), but is caused by the different libraries you import (e.g. HTTP and feed) linking to different versions of a single library (this issue occurs only for libraries that export C-style symbols. Their symbol names are not unique. time is one of those packages.).
As denoted in the error message, the library that causes the issues in this specific case is time-1.4.0.1.
Diagnosing the exact problem
First, you need to identify which different versions exist of your library. You can do this by checking the packages using ghc-pkg describe <packagename>, or just take a look into your cabal installation directory (usually ~/.cabal/lib).
At the time of writing this, the issue was caused by both time-1.4.0.1 and time-1.4.1 being installed. By using ghc-pkg describe I figured out that feed (and only feed, in my case), linked to time-1.4.1 whereas about 100 libraries linked to time-1.4.0.1.
How to resolve
Identify the library version (of the library that causes the error, as denoted in the error message) as described above that fewer packages depend on. You'll need to rebuild all packages that depend on it. In my case this is time-1.4.1.
Then, uninstall the package:
$ ghc-pkg unregister time-1.4.1 --force
unregistering time-1.4.1 would break the following packages: feed-0.3.9.2 (ignoring)
Note that the feed package is now broken and needs to be rebuilt and reinstalled. After rebuilding however, it won't link to time-1.4.1 but time-1.4.0.1 (in my specific case). This re-linking will resolve the duplicate symbol problem.
$ cabal install feed
If the error still occurs after that, re-check all dependencies as described above. You need to make sure any library you import will show the same library it's linked to when analyzed with ghc-pkg describe <pkg>
Update: In order to find out, which packages depend on the problematic library, simply use ghc-pkg unregister without the --force flag (Thanks to John J. Camilleri for pointing that out!). Note that if no packages depend on said problematic package, it will be removed.
An alternative cause of the same problem, is when using common symbols in an external library, on windows. I have an issue with a fortran code base using the common symbols. It is better explained here> https://gitlab.haskell.org/ghc/ghc/-/issues/6107
This only happens in dynamic linking, so ghc works, but ghci does not.
I'm trying to compile some code in Real World Haskell - Chapter 24. LineCount.hs.
I have not made any changes to the code.
However, when I do:
ghc -O2 --make -threaded LineCount.hs
(as instructed in the book), I get the message:
MapReduce.hs:6:7: Not in scope: `rnf'
What might I be doing wrong?
A quick search showed up that there was some trouble with the packages parallel and strict-concurrency in the past, and that reinstalling them would fix the issue. However, I tried that and it didn't work. Moreover, it is noted there that that issue was fixed sometime in 2010:
https://groups.google.com/forum/?fromgroups=#!msg/happs/gOieP4xfpNc/nrasm842JlUJ
Note: I get various other errors when compiling other files in the same chapter. For example, on compiling Strat.hs I get: Module Control.Parallel.Strategies' does not exportparZipWith'. On compiling LineChunks.hs I get: Module Control.Parallel.Strategies' does not exportrnf'.
Honestly, as a novice Haskell programmer I expected to run into trouble once I started modifying code - but I didn't expect to have trouble with code from a book!
The function is no longer called rnf. It's called rdeepseq now. Just replace it. :)
You can find the contents of the parallel package online by googling "control parallel strategies hackage", or clicking here.