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.

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

Strange stack.yaml behavior: extra-deps, aeson and GHCJS #2556

Closed
mchaver opened this issue Sep 1, 2016 · 12 comments
Closed

Strange stack.yaml behavior: extra-deps, aeson and GHCJS #2556

mchaver opened this issue Sep 1, 2016 · 12 comments

Comments

@mchaver
Copy link

mchaver commented Sep 1, 2016

(Moved this over from ghcjs github issues because I thought it was more appropriate here)

If you want to compile with ghcjs and stack, you can put declare the compiler in stack.yaml

compiler: ghcjs-0.2.0.20160414_ghc-7.10.3
compiler-check: match-exact
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.20160414_ghc-7.10.3:
        url: https://s3.amazonaws.com/ghcjs/ghcjs-0.2.0.20160414_ghc-7.10.3.tar.gz
        sha1: 6d6f307503be9e94e0c96ef1308c7cf224d06be3

This works pretty well. However, once you add anything if you add certain packages to extra-deps like aeson-0.8.0.2 (see my comment below), stack will complain that it is missing ghcjs-base, and most likely ghcjs-prim as well, depending on what you import.

While constructing the BuildPlan the following exceptions were encountered:

--  While attempting to add dependency,
    Could not find package ghcjs-base in known packages

--  Failure when adding dependencies:    
      ghcjs-base: needed (-any), stack configuration has no specified version

So you have to manually add these packages:

- location:
    git: [email protected]:ghcjs/ghcjs-base.git
    commit: 552da6d30fd25857a2ee8eb995d01fd4ae606d22
  extra-dep: true
- location:
    git: [email protected]:ghcjs/ghcjs.git
    commit: ce7b5736b53eb34ef5b913efdc560c7dafaf0b79
  extra-dep: true
  subdirs:
  - lib/ghcjs-prim

However, the commits I have here don't seem to match up with the compiler version because once I add ghcjs-base and ghcjs-prim as extra-deps and use toJSVal in some code, I get:

uncaught exception in Haskell main thread: h$ap_1_0_fast: unexpected closure type: -1

If I remove the extra-deps, ghcjs-base and ghcjs-prim, that error goes away, but I am prevented from using packages outside of the stack declaration.

Run into the same issue if you do stack --compiler ghcjs-0.2.0.20160414_ghc-7.10.3 and have extra-deps.

Related issue:
#2436

@mchaver
Copy link
Author

mchaver commented Sep 1, 2016

It looks like only when you add certain packages to the extra-deps will it say that it is missing ghcjs-base or ghcjs-prim. For example:

This works fine:

extra-deps:
- prelude-extras-0.4.0.3

This breaks (but works if you switch the compiler to ghc):

extra-deps:
- aeson-0.8.0.2

@mchaver
Copy link
Author

mchaver commented Sep 2, 2016

More details:

If you add a version of aeson that exists in the resolver to cabal (and not stack.yaml). It will compile and run fine. If you add the same version to the extra-deps of stack.yaml, you will get that ghcjs-base and ghcjs-prim error.

@mchaver mchaver changed the title Strange stack.yaml behavior: extra-deps and GHCJS Strange stack.yaml behavior: extra-deps, aeson and GHCJS Sep 2, 2016
@mchaver
Copy link
Author

mchaver commented Sep 2, 2016

I think I've found the issue, ghcjs-base version in the compiler I am using is not compatible with aeson-0.8.0.2. This is pretty clear when you try it in cabal:

rejecting: ghcjs-base-0.2.0.0/installed-5c7... (conflict: aeson==0.8.0.2,
ghcjs-base => aeson==0.9.0.1/installed-b24...)

but you wouldn't be able to tell that from the stack error. I wonder if there is a better way to show that in stack.

Edit: this is issue is somewhat orthogonal to this issue. Even if you put a compatible version of aeson in extra-deps, you still get the ghcjs-base issue.

@tolysz
Copy link
Collaborator

tolysz commented Sep 2, 2016

You are using a very old ghcjs snapshot... the version (lts-6.14)from #2495 already has quite new versions.
For new aeson out of the box you need to use ghcjs80 branch

Just to add, stack had a fixed list of packages (from ghcjs-boot) it will not touch: ghcjs-base, or aeson is in that list

EDIT: it is still possible to do what you want, but without stack... you will need to put your desired newboot libraries and ask ghcjs to perform boot.

@mchaver
Copy link
Author

mchaver commented Sep 2, 2016

@tolysz I guess it is not really clear where I should be looking for the latest stable version of ghcjs for stack. I was assuming https://s3.amazonaws.com/ghcjs since that where the stack documentation points to.

@tolysz
Copy link
Collaborator

tolysz commented Sep 2, 2016

I need to apologize @mchaver . I provide only a "community" builds based on the ghcjs snapshot with packages + ghc versions matching given lts or nightly. The nightly version is quite close to luite's ghcjs80 version so I can build it via cron.

I have scripts I use to build them in my github (somewhere), but they are like moving a target, and they need to be adapted from time to time to match both stackage and ghcjs changes.

Until ghcjs and ghcjs-boot are together there is no way of making any "official" builds, as packages which are used to boot might differ from the snapshot ones, breaking new packages.
Eg. the link above say ghc-7.10.3 but it uses base-4.8.0.0(from 7.10.1)... which is wrong! the "community" one have a correct base-4.8.2.0.

My packages are only a proof of concept - showing that ghcjs could have "official" release via stackage... but the build will differ with every snapshot.

;) I do not want to make such big commitment and add http://tolysz.org/ghcjs/untested link to the how to install page, as my solution needs a CI building it via multiple node and OS versions.

One other point is the naming convention, I try to use 9006014 for lts-6.14 and 820160902 for nightly-2016-09-02... the official seems to only tag the source snapshot date which is meaningless, as it does not say which libraries or versions does it have.
with a separate ghcjs-boot we could simply place booted libraries in the cabal/snapshot directory tree.

EDIT: the reason I needed to start playing with this was to include "my" modified version of aeson :) but I notice the "community" needs any "stack" based build first.

@mchaver
Copy link
Author

mchaver commented Sep 5, 2016

The answer is here: ghcjs/ghcjs#513

This isn't really a stack issue. You must compile ghcjs with the version of aeson that you, then with that build you can only use that one version of aeson. In stack you should leave any reference to aeson out.

@mchaver mchaver closed this as completed Sep 5, 2016
@sjakobi
Copy link
Member

sjakobi commented Sep 5, 2016

Looks like stack could help keep people from running into this issue by emitting a warning in case of bad configurations.

What precisely is the condition that stack should look out for here?

@sjakobi sjakobi reopened this Sep 5, 2016
@sjakobi
Copy link
Member

sjakobi commented Sep 5, 2016

Looks like stack could help keep people from running into this issue by emitting a warning in case of bad configurations.

Closing in favor of @tolysz's more detailed comment: #1530 (comment)

@sjakobi sjakobi closed this as completed Sep 5, 2016
@mchaver
Copy link
Author

mchaver commented Sep 5, 2016

When you build the ghcjs compiler, it assumes a number of packages (for example, attoparse, bytestring, text, aeson, etc.). Once the compiler is built, you cannot change the version number of those packages and they are treated sort of like native libraries. Stack needs to know that you are compiling with ghcjs, figure out what packages/versions the compiler depends on, and if you are using extra-deps, don't break if you are pointing to the correct version, and grab it from ~/.ghcjs. That way you can support both ghc and ghcjs with one stack.yaml.

@tolysz
Copy link
Collaborator

tolysz commented Sep 5, 2016

:P @sjakobi
https://github.com/commercialhaskell/stack/blob/master/src/Stack/Constants.hs#L250
Stack has it hard coded, it should be generated from the actual boot.
#1530

There are dozens of issues around installing via stack!
I try to build more recent snapshot of ghcjs for stack http://tolysz.org/ghcjs/untested

Could we focus more effort on that?
I test if it builds https://github.com/tolysz/reflex-todomvc/ with build.sh

@tolysz
Copy link
Collaborator

tolysz commented Sep 5, 2016

@mchaver :) I can use lts-6.15 and have the same versions with ghc and ghcjs... please try my suggestion :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants