How do I use the custom prelude from NoRedInk with stack? - haskell

I'm trying to write a desktop program using an elm frontend with haskell backend.
To make writing the backend code idiomatically similar to the front end code (and make sending data between them easier), it would be great to use No Red Ink's custom prelude.
Stack is my build tool.
It's the first time I've tried to use a custom prelude. I can't get it to even turn up. The key unresolvable error message for me is the one with no suggested "different approaches to resolving this":
In the dependencies for nri-prelude-0.6.0.6:
unix is a library dependency, but the package provides no library`
Here's everything I tried:
I tried adding -fplugin=NriPrelude.Plugin to my ghc options in my stack.yaml but it said
<command line>: Could not find module `NriPrelude.Plugin'
So I tried adding nri-prelude to my dependencies, resulting in a recommendation to add
- nri-prelude-0.6.0.6#sha256:4ccc7488149a0401a9241c9b64db22c48a8639afaae11cffb263da5226e8acde,5289
to my stack.yaml, which resulted in a recommendation to add
- terminfo-0.4.1.5#sha256:4d1790aeb354797955ca1cb67035ca80f66a0d9cc4e43a51c1c9d566e00ce350,1713
- unix-2.7.3#sha256:20079c504d0ca33fbf11de3a215d25220c8d43499a93049a8f2791323f3bd57b,6047
as well. This was a dead end for me because I got the error message:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for nri-prelude-0.6.0.6:
unix is a library dependency, but the package provides no library
needed due to Experiment-0.1.0.0 -> nri-prelude-0.6.0.6
Some different approaches to resolving this:
Plan construction failed.
I couldn't help but notice the empty list of approaches to resolving it this time.
Instead of going down that route I tried using a route that had worked for another library, by putting
- github: NoRedInk/haskell-libraries
commit: a202da122192ad2b9435f92086f5b4c5e304531b
in my stack.yaml. It didn't like that:
No cabal file found for Archive from https://github.com/NoRedInk/haskell-libraries/archive/a202da122192ad2b9435f92086f5b4c5e304531b.tar.gz
and when I tried
- github: NoRedInk/haskell-libraries/nri-prelude
commit: 8657ef0ea153a12fcaa0d048be98598512fe9df6
that didn't even parse:
Could not parse 'stack.yaml':
Aeson exception:
Error in $['extra-deps'][3]: failed to parse field 'extra-deps': parsing Text failed, expected String, but encountered Object
See http://docs.haskellstack.org/en/stable/yaml_configuration/

Related

What is the relationship between dependency constraints in "stack configuration", xxx.cabal, and cabal.config?

I haven't tried solving the issue yet; first I want to understand where the issue comes from:
TextTerra $ stack --nix test
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for TextTerra-0.1.0.0:
easytest-0.2 from stack configuration does not match ==0.2.1 (latest matching version is 0.2.1)
needed since TextTerra is a build target.
Some different approaches to resolving this:
* Set 'allow-newer: true' to ignore all version constraints and build anyway.
* Consider trying 'stack solver', which uses the cabal-install solver to attempt to find some working build configuration. This can be convenient when dealing with many complicated constraint
errors, but results may be unpredictable.
* Recommended action: try adding the following to your extra-deps in /home/brandon/workspace/TextTerra/stack.yaml:
- easytest-0.2.1
Plan construction failed.
There is now no other reference to easytest, particularly easytest-0.2; the single reference is what I just added:
TextTerra $ rg easytest
TextTerra.cabal
67: , easytest == 0.2.1
However, there was a reference to easytest-0.2 in cabal.config. I'm not aware of the relevance of this file as a quick search doesn't turn up much and removing the file has no effect on the build (in particular, I get the same error message above).
In...
easytest-0.2 from stack configuration does not match ==0.2.1
... the "stack configuration" means the set of packages specified through the resolver (typically a Stackage snapshot -- you can find lists of packages and versions in a snapshot at the Stackage site) and the extra-deps in stack.yaml, while the ==0.2.1 constraint is what your .cabal file is asking. The suggestions given by the error message (ignoring .cabal upper bounds with allow-newer, and adding packages to extra-deps) are appropriate in the cases in which you want, or need, to build with a specific resolver. If that is not the case (say, if you are trying to update an old project to a recent LTS snapshot), you can also change the resolver to something that includes the packages and versions you are looking for (if such a resolver is available).

External dependencies, Haskell, stack: should I modify something or 'import' suppose to be sufficient?

I am pretty new to Haskell as well as stack.
import Data.Set
import Data.Stack
The statements above trigger compilation error: Could not find module 'Data.Set'. Perhaps you meant 'Data.Int'. I tried to google and found nothing similar.
Hence, my question is: do I need to specify external dependencies manually or just my stack build command somewhy fails to grab appropriate modules from somewhat cache or repository?
In case I have to specify my dependencies manually, should I prefer .cabal or .yaml? What's the correct way to deal with versioning?
[Do] I need to specify external dependencies manually [...]?
Yes.
Since you are using Stack, it is easy to specify the dependent packages you import in your code. Depend on your Stack version, the default configuration might be a little bit different:
If you created your project with the latest version of Stack, you will see package.yaml in the root of your project (hpack is used in this case to specify the configurations). You need to add package dependencies there, e.g., containers for Data.Set. Here's an example of a dependencies section in one of my projects:
dependencies:
- base >= 4.7 && < 5
- containers
- time
- network
- bytestring
If you are using an older version of stack and do not see package.yaml, you need to edit your-project-name.cabal to add the dependencies. Here's the complete document telling you how to do it: https://docs.haskellstack.org/en/stable/GUIDE/#adding-dependencies
Personally, I prefer the new system with hpack (package.yaml). Basically, it is simpler, and it saves you time declaring all modules you have (not about dependency). If you have package.yaml, do not edit .cabal, which is automatically generated by hpack.

jOOQ generated code cannot be compiled?

I have used this tool: https://github.com/etiennestuder/gradle-jooq-plugin
from jOOQ's official website to generate code from my database.
Yet if I set
directory = 'src/main/java'
when I run "gradle build", I get all these compile errors like:
database/information_schema/InformationSchema.java:218: error: no suitable constructor found for SchemaImpl(String,<null>)
super("INFORMATION_SCHEMA", null);
^
constructor SchemaImpl.SchemaImpl(Name) is not applicable
(actual and formal argument lists differ in length)
constructor SchemaImpl.SchemaImpl(String) is not applicable
(actual and formal argument lists differ in length)
Any fix for this?
Note that I wanted to put the generated code into the src folder because I want to use them in my code. I've heard to put them in the target or build folder instead, but I'm not sure how do you access those classes from target or build folder?
Thanks!
I was on 3.7. Now I switch to 3.9, everything turns out to be fine...
I've written a short blog post about this. Starting with jOOQ 3.16 and #12601, there's an additional compilation error in case users use:
An older version of org.jooq:jooq (the runtime library)
A newer version of org.jooq:jooq-codegen (the code generation library)
In general, the runtime library version >= codegen library version. The new compilation error might look like this:
[ERROR] …/DefaultCatalog.java:[53,73] cannot find symbol
[ERROR] symbol: variable VERSION_3_17
[ERROR] location: class org.jooq.Constants

Haskell: Failed to load interface for 'Graphics.Gloss'

Haskell Community.
I am a newbie in Haskell, can only implement simple Haskell functions.
I tried out one Haskell game program that was open source. While running it, GHC gave the following errors:
HexDame.hs:1:1: error:
Failed to load interface for ‘Graphics.Gloss’
Perhaps you meant
Graphics.GL (from OpenGLRaw-3.1.0.0)
Graphics.GL.HP (from OpenGLRaw-3.1.0.0)
Graphics.GL.NV (from OpenGLRaw-3.1.0.0)
Use -v to see a list of the files searched for.
HexDame.hs:2:1: error:
Failed to load interface for ‘Graphics.Gloss.Interface.Pure.Game’
Use -v to see a list of the files searched for.
HexDame.hs:3:1: error:
Failed to load interface for ‘Graphics.Gloss.Data.Extent’
Use -v to see a list of the files searched for.
I am unsure whether Gloss is installed or not. I am using GHC on Windows on a proxy network. The 'cabal update' solution is also not working.
For other information, I had downloaded the entire Haskell package from the website, so I presume it includes all necessary packages, including GLUT.
Please suggest solutions.

Resolving GHC 'I found a duplicate definition for symbol ...'

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.

Resources