Stack: GHCJS?

[jkozlowski]

Are there plans to support GHCJS in the same first class way as GHC (i.e. getting the binaries etc.)?

[snoyberg]

Not yet, but I like the idea. Let's use this issue as a discussion point for it.

[jkozlowski]

Thanks for a quick reply. I already saw some calls for better distribution on the ghcjs github (https://github.com/ghcjs/ghcjs/issues/231). I think if it would be just as painless to get ghcjs through stack as it is ghc (including getting ghcjs packages from stackage) it would greatly help with adoption.

[cocreature]

Just to show that there's interest: I'm interested :)

[bitemyapp]

This hinges in part on GHC 7.10 compatibility does it not?

[mgsloan]

Nah, GHCJS works fine with 7.8.4. Infact I've found it more of a challenge to boot it with 7.10. I didn't realize there were compatibility issues with 7.10? (though further discussion of that should go in a different issue, if one doesn't already exist)

Anyway, agreed that this would be a nice thing to have! It's particularly useful when sharing code between the client and server. Currently I need to remember to run my ghcjs build script, and otherwise the protocol types can go out of sync.

[bitemyapp]

Having an ez-pz way to get people going with GHCJS would be wonderful.

[jkozlowski]

This hinges in part on GHC 7.10 compatibility does it not?

GHCJS compatiblity? Granted that it's on a branch, but I am running on 7.10 fine (https://github.com/ghcjs/ghcjs/wiki/GHCJS-with-GHC-7.10)

[bitemyapp]

@jkozlowski I thought Stack was GHC 7.8 only and didn't know GHCJS worked with 7.8

[jkozlowski]

So, would the first step be to get binary builds setup somewhere/somehow? I don't know if FP Complete already does that somehow, or it exists somewhere else (no official ones, according to my issue on ghcjs github).

[snoyberg]

We do already have Docker images with ghcjs binaries. Another option is just automating the process of building ghcjs

[krisajenkins]

+1! Stack has now addressed every problem I have with Haskell adoption, save this one. I'm using Elm for frontend stuff, but I'm using it at its limits and would love to use GHCJS if you could work your supermagic on the install-process. :-)

[mgsloan]

It'll be awesome to have full stack support for GHCJS in the future. However, for now stack's docker images do help a ton to make it easy to do development on GHCJS. Here's what I'm using for the new School of Haskell:

Have something like this in your stack.yaml:

resolver: lts-2.14
docker:
  enable: true
  repo: fpco/stack-ghcjs-build

fpco/stack-ghcjs-build is a ~4.5gb or so image, which doesn't have all of stackage installed. If you want that, there's a 16GB image with all of stackage at fpco/stack-ghcjs-full. Other images are here.

Then, you can do this to build and install ghcjs dependencies:

stack exec -- cabal --config-file=cabal-ghcjs-config update
stack exec -- cabal --config-file=cabal-ghcjs-config install --ghcjs all-the-ghcjs-stuff-i-want/ to-install/

Why the --config-file=cabal-ghcjs-config? I found it to be necessary in order to avoid dependency issues. For simpler usecases it might be fine to omit, though. This causes a new config file to be initialized and used by ghcjs, instead of using the global stackage config file used by cabal. This isn't perfect, because it means the packages shared by your server and client could have different versions. For example, you might end up with a different version of aeson than is in the stackage snapshot.

[luite]

How important is it to have 7.8 compatibility in GHCJS? I'm working on putting together a release, based on the improved-base branch, but this currently only has 7.10 compatibility. Dropping 7.8 saves a bit of maintenance (different set of boot packages, and some API's in GHC have been improved in 7.10), but it's not impossible to support it a bit longer.

The 7.10.2 release candidate works fine by the way, no workarounds needed anymore.

[krisajenkins]

Doesn't matter to me at all. I'd like to move everything to 7.10. #onevote

[jkozlowski]

@mgsloan You workflow sounds like a nice workaround, I'll give it a try this weekend if I find some time. I am currently just using a hand built ghcjs that was built into a sandbox.

But also if it already is possible, maybe just automating those steps (with the caveats that it pulls in a massive docker image) would be already a step in the right direction. Just a thought/

[snoyberg]

@luite I'm definitely OK with the release with only 7.10.2 support. Want to touch base next week about figuring out a good release strategy that could give stack users easy access to GHCJS?

[luite]

Sure. I just returned from travels and I'm dedicating some time the coming weeks to finally sort out the long standing issues and get a release out of the door.

[cstrahan]

@bitemyapp: Having an ez-pz way to get people going with GHCJS would be wonderful.

One option would be Nix :). Yes, Nix has it's own learning curve, but one can ignore most of it if all they want/need to do is get ghcjs installed. @ryantrinkle provides a script to automate the install of Nix and ghcjs, and uninstalling is as easy as rm -rf /nix.

[krisajenkins]

FWIW, Nix (on OSX) defeated me. I'm still hoping for stack to nail it. Plus, I don't think I could recommend Nix to someone who just wants to get started with Haskell, the way I feel I could recommend stack. That alone is priceless.

[luite]

With GHC 7.10.2 (release candidate), installation from source should actually become doable for mere mortals (but packages may still be preferred due to the build time and setup of dependencies). I'm readying the improved-base branch for release, installation goes like:

http://lpaste.net/135131

And there's a script for Windows that builds everything from source on a clean Windows installation:

https://github.com/ghcjs/ghcjs/blob/improved-base/utils/install.ps1

Ooh and and what's this? A REPL?

luite@Luites-MacBook-Pro:~/ghcjs/ghcjs$ ghcjs --interactive
GHCJSi, version 0.1.0-7.10.1.20150612: http://www.github.com/ghcjs/ghcjs/  :? for help
Prelude> let x = 5
Prelude> let y = x
Prelude> let x = 6
Prelude> x + y
11

Prelude> foreign import javascript unsafe "Math.sin($1)" js_sin :: Double -> Double
Prelude> js_sin x
-0.27941549819892586

Prelude> 

(See WIP in ghcjsi branch)

[ghost]

@luite AHHH Must Have!

Presently only able to build using the Nix script provided by @ryantrinkle and am eagerly awaiting a 'push button' install.

[mmaz]

@luite that branch is unbelievably exciting! If in the future, emacs-haskell-mode could plumb through toghcjsi automatically by invoking stack ghc for GHCJS projects, that would be an incredible development environment!

[joelburget]

Big +1. Exciting stuff :)

[CRogers]

Something I'm interested in is having support for mixing ghcjs and ghc projects. For example, I often want to have something like:

• A client project compiled with ghcjs
• A server project compiled with ghc
• A library with shared code that gets compiled with both ghc and ghcjs

Some way to have this just work with stack would be great.

@luite GHCJSi is super exciting :D

[manyoo]

+1 ! I’m currently starting working on such a project. Before stack, I tried to use cabal sandbox, but when compiling ghcjs code, it can’t find the ghcjs packages like ghcjs-base installed in the global ghcjs package directory. Now, I’ve removed the cabal sandbox, and use stack for server side ghc code, and cabal with no sandbox for client side ghcjs code. If stack can make it easy to work in such setup, it would be really awesome!

Eric Wong
Professional Web Developer.

On Jun 25, 2015, at 2:55 PM, Callum Rogers [email protected] wrote:

Something I'm interested in is having support for a mixing ghcjs and ghc projects. For example, I often want to have something like:

A client project compiled with ghcjs
A server project compiled with ghc
A library with shared code that gets compile with both ghc and ghcjs
Some way to have this just work with stack would be great.

@luite https://github.com/luite GHCJSi is super exciting :D

—
Reply to this email directly or view it on GitHub https://github.com/commercialhaskell/stack/issues/337#issuecomment-115130526.

[jkozlowski]

+1 that would be perfect.

[cdepillabout]

@luite: let me join in and say that I'm excited about ghcjs and ghc-7.10.2.

@CRogers: that's the exact same setup that I would be envisioning.

[luite]

Just a quick heads-up: As from the latest commit, GHCJSi supports evaluating code in the browser. Just npm install -g socket.io first (and don't forget to set NODE_PATH) and go to http://localhost:6400 after starting GHCJSi, before running any code. This gives you DOM access and should open up new fun ways to experiment and interact with Haskell and JS libraries. I've also fixed loading Haskell modules from disk (cabal repl works now out of the box) and declarations in the REPL.

http://hdiff.luite.com/tmp/ghcjsi1.png

But I'm going back to preparing the libraries and release now, after recovering from a four-day GHCJSi code-binge. It's quite addictive! GHCJSi is far from production ready, so it's not going to be in the next release, but it's definitely coming.

[CRogers]

GHCJSi supports evaluating code in the browser

That is incredibly exciting - I never even imagined you'd be able to do
that!

On Thu, 25 Jun 2015 13:56 Luite Stegeman [email protected] wrote:

Just a quick heads-up: As from the latest commit, GHCJSi supports
evaluating code in the browser. Just npm install -g socket.io first (and
don't forget to set NODE_PATH) and go to http://localhost:6400 after
starting GHCJSi, before running any code. This gives you DOM access and
should open up new fun ways to experiment and interact with Haskell and JS
libraries. I've also fixed loading Haskell modules from disk (cabal repl
works now out of the box) and declarations in the REPL.

http://hdiff.luite.com/tmp/ghcjsi1.png

But I'm going back to preparing the libraries and release now, after
recovering from a four-day GHCJSi code-binge. It's quite addictive! GHCJSi
is far from production ready, so it's not going to be in the next release,
but it's definitely coming.

—
Reply to this email directly or view it on GitHub
https://github.com/commercialhaskell/stack/issues/337#issuecomment-115243752
.

[alexanderkjeldaas]

+1 just posting my interest in stack+ghcjs. I do not care about 7.8 vs 7.10.

[vikasmenon]

+1. This would be neat.

[jkozlowski]

@snoyberg and @luite: did you guys manage to agree on something?

[snoyberg]

I just spoke with @mgsloan about this actually. He's been working on some code recently using GHCJS and stack, so he has a better feel for the requirements than I do. I haven't yet touched base with Luite unfortunately.

[jkozlowski]

@mgsloan: I only just tried your workaround, and got:
WARNING: Using boot2docker is NOT supported, and not likely to perform well. and then a bunch of errors. So I guess the docker support is not full on Mac OS X.

[snoyberg]

@jkozlowski I believe that's currently the case, but it's being worked on. I'd suggest we move the Docker discussion though to a different issue, I'm sure @manny-fp will have some advice since he uses our Docker support on Mac OS X regularly.

[jkozlowski]

Thanks.

[cies]

ghcjs(i) and stack, the next frontier in Haskell for web development?

[AKurilin]

Do you guys have a guess of what the roadmap for ghcjs support would be once 7.10.2 is out and available through stack?

[kfigiela]

Any updates on that? We're migrating all projects in our company to Stack so GHCJS support is essential.

[kgadek]

@mgsloan , is there any consensus on requirements, overall design and maybe a roadmap? Would be lovely.

As far as I was told, cabal got support for ghcjs in one day or something, didn't it? Would this be also true for stack?
I'm wondering if it would be feasible to patch stack to operate with ghcjs instead of ghc. How much work would that be?

[mgsloan]

Cool to see that so many of you are interested in GHCJS support! I've been busy with other things. The core of "support building GHCJS code" should indeed be pretty easy.

I started implementing the simple part a while back, but then got stuck on some gnarly issues testing it, mainly regarding getting ghcjs properly setup (see the end of this comment). If someone would like to step in and take this over, feel free to let me know! Otherwise, I'll be revisiting this in the next few days. I'm hoping the new GHC version + more recent ghcjs will resolve these things.

The branch: https://github.com/commercialhaskell/stack/tree/337-ghcjs

Design

• Use a separate stack.yaml file for GHCJS. This means that for a client + server project, you'll need to do stack --stack-yaml=stack-ghcjs.yaml build && stack build to build it. I thought about this a lot, and it's the only sensible choice:
  
  
  
  • All of the project configuration settings that apply to GHC builds also validly apply to GHCJS builds, so there should be two different configs.
  
  
  • When writing a client + server project, you'll need to copy the output javascript to a place that your server code expects. So, it makes sense to have multiple phases to the build instead of having a single stack build.
  
  
• This stack.yaml file specifies use-ghcjs: true, which causes the appropriate flags to be used. We might consider specifying this setting in a different way - something like compiler: ghcjs.

Beyond core functionality

• Have stack setup automatically install + boot ghcjs.
• Have stack-ghcjs-build images for LTS-3. This should resolve the issues I was having with testing this.
• Possibly have stackage snapshots that are specific to ghcjs?

Gnarly issues which caused this work to get derailed

• If I use an lts-2 version of the stack-ghcjs-build image, then while you have cabal install 1.22.*, the cabal package is Cabal-1.18, which doesn't support GHCJS. So, I can't use that image, which is what easily allowed me to use GHCJS with stack in the past.
• Tried and failed to get ghcjs built with GHC-7.10.1. Things might work out better with 7.10.2. I am currently waiting on a build of it.

Call to action

If you really care about this and you're comfortable getting GHCJS setup, please feel free to tackle this. I haven't been using GHCJS much lately, and have a lot of other stuff to work on, so this isn't exactly a burning priority for me.

[mtolly]

Very excited :)

Just in case you haven't seen it, here's the extra steps needed for 7.10 support; with it I was able to build GHCJS successfully with 7.10.1.

[kgadek]

@mgsloan I have successfully built stack HEAD @ 4d4b8b5 with this change, so Cabal 1.22 seems to work. stack test was successful.

diff --git a/stack.yaml b/stack.yaml
index 71af5bd..a1e1461 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -1,12 +1,8 @@
 packages:
 - .
 extra-deps:
-- path-0.5.2
-- Win32-notify-0.3.0.1
-- hfsevents-0.1.5
-- project-template-0.2.0
 - filelock-0.1.0.1
-resolver: lts-2.17
+resolver: nightly-2015-07-24
 image:
   container:
     base: "fpco/ubuntu-with-libgmp:14.04"

@kfigiela has a working instruction on how to build ghcjs with GHC 7.10.2. Could you please post it here?

[kfigiela]

In order to build GHCJS with GHC 7.10 you'll need to use improved-base branch. Here's „cookbook” that we use in our team. Note that official tutorial seems to be out of date a little bit, this is what works for us:

cabal install Cabal cabal-install # has to be newer than 1.22.3, I have Cabal 1.22.4 and cabal-install 1.22.6

# Ensure that you have correct cabal binary in your $PATH
cabal sandbox init

### ensure that Cabal lib is new enough, sandbox env may not see the Cabal lib you installed in the first step
cabal install Cabal

export PATH=`pwd`/.cabal-sandbox/bin:$HOME/.cabal/bin:$PATH
# or
# export PATH=`pwd`/.cabal-sandbox/bin:$HOME/Library/Haskell/bin:$PATH

# I recommend to use zsh-autoenv-plugin or smartcd instead of setting this globally

cabal install alex happy

git clone https://github.com/ghcjs/ghcjs.git -b improved-base

cabal install ./ghcjs ./ghcjs/lib/ghcjs-prim

ghcjs-boot --dev --no-prof --no-haddock --ghcjs-boot-dev-branch improved-base --shims-dev-branch improved-base

@mgsloan – what is the current status of this feature? What is done and what is to be done? I won't be able to take this over, but in case somebody would this information would be very helpful.

[wdanilo]

@mgsloan I'm also very interested in GHCJS support. In fact it is crucial for us, because we've just moved over stack and we were sure that it supports GHCJS out of the box. Unfortunately it is a kind of blocker for us and we would be very helpful for any kind of help.
You've told, that it is almost done - @kgadek, @kfigiela or other guys from our company would love to help you setup the environment if there will be any problems with ghcjs itself - but I know that with the newest ghc it works like a charm without any complications. Anyway if there would be any problems we can even give you a pre-configured remote machine with everything set-up.

I would be very thankful for help with this issue. We are slowly digging into Stack, so we will definitively contribute more actively in its development in the future, but for now you are my hope! :D

[luite]

I've also been distracted by other projects recently.

If you run cabal sdist from the improved-base branch, you get a ghcjs tar.gz archive that should be very similar to what should be released soon, and it should build/boot without trouble with GHC 7.10.2. Let me know if any changes in GHCJS are required to make the integration easier.

I'd be happy to discuss requirements. I'm flying to Canada in about a week and the last week of August (the week before ICFP) I'll be mostly offline for hiking.

[wdanilo]

@mgsloan, @luite : so if you Luite will be off in a week, is it possible we will resolve this issue in this week somehow? :)

[luite]

Sorry I just meant that I'll probably be unresponsive for a few days due to travels, I'll only really be offline the hiking week

[mgsloan]

@luite See you at ICFP! :D

I probably ought to have tried harder to get GHCJS going 7.10, but I had really been hoping to be able to use existing docker images.

@mgsloan I'm also very interested in GHCJS support. In fact it is crucial for us, because we've just moved over stack and we were sure that it supports GHCJS out of the box. Unfortunately it is a kind of blocker for us and we would be very helpful for any kind of help.

Have you seen this comment about how to easily use stack with GHCJS? Albeit not improved-base ghcjs, but still, might get you unblocked: https://github.com/commercialhaskell/stack/issues/337#issuecomment-113482050

This approach can still work if your main project code is using ghc 7.10 - just have a separate stack.yaml for your ghcjs build. Alternatively, directly use the docker image with docker run, bypassing the need for a stack config.

[ryantrinkle]

Hi guys,

In case it's useful to anyone, my repo at https://github.com/ryantrinkle/try-reflex contains working build scripts and package sets that work for both ghcjs-with-ghc-7.10 (on my develop branch) and ghcjs improved-base (on my ghcjs-improved-base branch). Just clone it and run the ./try-reflex script to get a shell with a complete (booted) ghcjs environment; delete reflex* out of packages.nix before doing that if you don't want to get any of my stuff, just the bare ghcjs. On linux, my cache should serve you binaries for nearly all of these things.

Of course, I realize this repo won't be directly usable by your tooling, but I thought I'd bring it up in case it might be useful for reference. Also, please feel free to get in touch if there are any questions I might be able to answer based on that. @cstrahan also knows that system inside and out, too (he took responsibility for getting the scripts upstream into nixpkgs and made a huge number of improvements to it).

[kgadek]

Ok, I'll admit that even after this discussion I have no idea what's the status.

As far as I understood, using docker means basically calling cabal there. In other words, this is as good as using cabal on bare metal and not using stack at all?

Also, I'm not sure what is the current issue. If that's the ghcjs not working, I believe @kfigiela has a working setup.

I didn't quite get the actual status of the https://github.com/commercialhaskell/stack/tree/337-ghcjs branch. @mgsloan what is there? What's done, what's to be done, what's "unknown" and to be researched?

[mgsloan]

Ok, I'll admit that even after this discussion I have no idea what's the status.

what is there? What's done, what's to be done, what's "unknown" and to be researched?

This thread is getting long and unwieldy. I've split off a couple of issues to reduce confusion:

1) We need to support building code with ghcjs. The initial code for this is very minimal, and just enables passing in the --ghcjs flag and nothing else https://github.com/commercialhaskell/stack/issues/748

2) We need to support automatically installing GHCJS, in the same way that installing GHC is automated: https://github.com/commercialhaskell/stack/issues/749 . I'd been hoping that this bit can come after adding support for building code with GHCJS. However, given the issues I've had with getting it setup locally, it might actually be best to get this done first.

As far as I understood, using docker means basically calling cabal there. In other words, this is as good as using cabal on bare metal and not using stack at all?

No, stack is still run inside the docker container. Other than the stack solver command, I don't think cabal-install is ever run by stack. The benefit of this is that you can use a docker image that already has ghcjs + libraries installed.

Also, I'm not sure what is the current issue. If that's the ghcjs not working, I believe @kfigiela has a working setup.

That's the current issue for me, yes. I am running into the issue described here while booting: https://github.com/ghcjs/ghcjs/issues/374

@ryantrinkle 's try-reflex setup works perfectly. Pretty nifty! As he mentions, I don't see how to directly use the results with stack.

[mgsloan]

Good news everyone! @kfigiela's instructions for building and booting ghcjs worked, so I spent the last few hours implementing initial stack support.

Things now seem to work decently on the 337-ghcjs branch!

I haven't used this for anything big, so who knows what may be missing. Considering how many people are interested in getting this soon, I figured it's better to push something unpolished for people to play with. If you want to try it out, I've pushed a fork of ghcjs-dom-hello which has a stack.yaml which works with my stack branch.

There are a couple caveats:

• You can only use the ghc-7.10 resolver, as otherwise stack will try to install non-ghcjs versions of ghcjs's boot packages. This means that any dependencies need to specified as fixed versions in extra-deps. I'm pretty sure we're going to need ghcjs specific stackage snapshots.
• I found an issue with ghcjs --install-executable, and committed a change which fixes it to the branch 383-fix-install-executable of my fork (and opened a PR). Without this fix, installing any package with an executable will fail with ghcjs yielding usage information for ghcjs --install-executable.

[mgsloan]

As I've noted on #748, I've decided to have the resolver specify the GHCJS version. Once that's implemented, there will be no more use-ghcjs field / flag!

[kgadek]

It seems that stack solver doesn't work with GHCJS…?

Other than that, it does seem that this works for us. Great job, @mgsloan ! Now we shall wait for LTS Haskell for GHCJS and it would be… just awesome :)

[kfigiela]

@mgsloan, great job! Indeed it does work.

During setting up everything I found some minor issues:

• stack ghci does not work properly. It calls ghc --interactive ..., but should call ghcjs --interactive .... It could be fixed for future compability, as it's now experimental feature of ghcjs (see https://github.com/ghcjs/ghcjs/tree/ghcjsi branch). I used --with-ghc flag, but it didn't help, but this is another story. I'm using ghcjs with changes merged from ghcjsi branch. This seems to be ghcjs bug (it's ignoring $GHC_PACKAGE_PATH). However, from what I see in my case this variable has the following value: GHC_PACKAGE_PATH=/Users/kamilfigiela/NewByteOrder/development/nodelab-gui/.stack-work/install/x86_64-osx/ghc-7.10/7.10.2-ghcjs/pkgdb:/Users/kamilfigiela/.stack/snapshots/x86_64-osx/ghc-7.10/7.10.2-ghcjs/pkgdb:/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/package.conf.d – the last component is non-js package db – possibly it should point to somewhere in ~/.ghcjs.
• as @kgadek said, stack solver does call Cabal without ghcjs flags – ghcjs-dom-hello is a good test case:

$ stack solver
This command is not guaranteed to give you a perfect build plan
It's possible that even with the changes generated below, you will still need to do some manual tweaking
Asking cabal to calculate a build plan, please wait
flags:
  text:
    integer-simple: false
extra-deps:
- cairo-0.13.1.0
- gio-0.13.1.0
- glib-0.13.2.1
- gtk3-0.14.0
- mtl-2.2.1
- pango-0.13.1.0
- text-1.2.1.3
- utf8-string-1
- webkitgtk3-0.14.1.0

Here it should not ask for webkitgtk3 as we're going to build with ghcjs. In https://github.com/ghcjs/ghcjs-dom/blob/master/ghcjs-dom.cabal there's condition for dependencies: if !impl(ghcjs) || flag(webkit) which seems to be ignored by stack.

[mgsloan]

@kfigiela Thanks for trying it out! Yes, I haven't added support for ghcjsi. I can try blindly adding that in in my next change, though. That's curious that the GHC_PACKAGE_PATH variable has a non-js DB, I'll need to look into that.

Along with fixing solver and taking a swing at ghcjsi support, next up is removing the use-ghcjs flag and instead have a compiler resolver that looks like ghcjs-0.1.0_ghc-7.10.2. A bit ugly to have both versions, but it's necessary. Is there already a way of formatting the full ghcjs version number that should be used? If there's already a consistent and not too ugly way to do that, I'd prefer to remain consistent with it.

[mgsloan]

I've pushed a new implementation which is based on a resolver setting. The resolver looks like ghcjs-0.1.0_ghc-7.10.2. It now uses ghcjs to build the Setup.hs files, and then runs the resulting javascript in node.

This works for all stack commands except setup, ghc, runghc, and ide. It'd be easy to add support for something like ghc, but should stack ghc run ghcjs? Maybe there should be a new stack ghcjs command for that.

Since I think this is now in pretty good shape, I've opened a PR for it: https://github.com/commercialhaskell/stack/pull/802

[snoyberg]

Since #802 is merged and the only remaining item is being tracked by #749, I'd recommend closing this issue. @mgsloan any objection?

[mgsloan]

Sounds good to me!

[xavier83]

Is there a howto/wiki to setup and get started on ghcjs using stack?

[vertexcite]

You need to be using a stack built from master, to do that, run:

$ stack upgrade --git

Then, add

resolver: ghcjs-0.1.0.20150924_ghc-7.10.2
compiler-check: match-exact

to ~/.stack/stack.yaml

Then run

$ stack setup

(Second part copied from https://github.com/commercialhaskell/stack/issues/749#issuecomment-143248083 )

[fizruk]

@xavier83 there is no official howto/wiki AFAIK.

For old base GHCJS you can use what @vertexcite suggested.
Probably you'd want to add that resolver for a particular GHCJS project, so GHCJS won't be turned on by default.

For GHCJS master (a.k.a. "improved base"), you can place this in your stack.yaml (copied from https://github.com/commercialhaskell/stack/pull/1030#issuecomment-144570922):

resolver: ghcjs-0.2.0.20151001_ghc-7.10.2
compiler-check: match-exact
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.20151001_ghc-7.10.2:
        url: "https://github.com/fizruk/ghcjs/releases/download/v0.2.0.20151001/ghcjs-0.2.0.20151001.tar.gz"

NOTE: for the latter to work you'll currently need stack upgrade --git (it has to do with setup-info bug fixed in #1083).

[bitemyapp]

@vertexcite @fizruk thank you both for sharing these, this is very helpful!

[GetContented]

@fizruk could you create a wiki page for it?

[fizruk]

@GetContented I have now created a wike page for Stack & GHCJS.

[GetContented]

@fizruk Thank you :)

[xavier83]

@fizruk awesome. Thanks :+1:

[mgsloan]

@fizruk Good stuff, thanks! Most of it's spot on, I've updated with some more info and a correction for the versions (stack setup isn't supported by any released version of GHCJS).

[dredozubov]

Looking forward for it in the next release! It'll be _extremely_ useful.

[k-bx]

@fizruk can you take a look please?

$ cat stack.yaml
resolver: ghcjs-0.2.0.20151001_ghc-7.10.2
compiler-check: match-exact
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.20151001_ghc-7.10.2:
        url: "https://github.com/fizruk/ghcjs/releases/download/v0.2.0.20151001/ghcjs-0.2.0.20151001.tar.gz"

packages:
- '.'
$ stack setup
Warning: /Users/kb/workspace/ghcjs-stack-play/stack.yaml: Unrecognized field in SetupInfo: ghcjs
Warning: https://raw.githubusercontent.com/fpco/stackage-content/master/stack/stack-setup-2.yaml: Unrecognized field in SetupInfo: ghcjs
No information found for ghcjs-0.2.0.20151001_ghc-7.10.2.
Supported versions for OS key 'macosx': 7.8.4, 7.10.1, 7.10.2
$ stack --version
Version 0.1.5.0 X86_64

[kfigiela]

@k-bx: you need to stack upgrade --git. Make sure that you have Cabal library version 1.22.4 installed (my coleague had 1.22.2 and then ghcjs-boot phase failed, maybe stack could check that?)

[fizruk]

@k-bx you need to upgrade stack to HEAD, see Stack & GHCJS wiki

[k-bx]

Sorry, my bad, mis-read wiki.

[tinkyholloway]

I've been working to the instructions at Stack & GHCJS.

I've found a problem with hsc2hs (whatever that is) when fails on a build of network-2.6.2.1:

hsc2hs-ghcjs-0.2.0.20151001-7.10.2.bin: hsc2hs: rawSystem: runInteractiveProcess: exec: does not exist (No such file or directory)

hsc2hs is present:

✔ ~/.stack/programs/x86_64-osx/ghcjs-0.2.0.20151001_ghc-7.10.2/bin
13:07 $ ~/.stack/programs/x86_64-osx/ghcjs-0.2.0.20151001_ghc-7.10.2/bin/hsc2hs-ghcjs
hsc2hs-ghcjs-0.2.0.20151001-7.10.2.bin: hsc2hs: rawSystem: runInteractiveProcess: exec: does not exist (No such file or directory)

[luite]

Ok this is likely a problem with how hsc2hs is dealt with in GHCJS. It's the only tool that isn't stand-alone, but a wrapper that calls an existing hsc2hs provided by GHC.

Handling of these files is not quite complete yet, but something should probably change. I wonder if GHCJS should even attempt to support them, since it's really for getting information from the C compiler.

[tinkyholloway]

@luite said:

It's ... a wrapper that calls an existing hsc2hs provided by GHC

A ha! Adding ~/.stack/programs/x86_64-osx/ghc-7.10.2/bin/hsc2hs to my path fixed it. Thank you.

[erikkaplun]

will we be seeing any GHCJS related doc on https://www.stackage.org at some point?

[bitemyapp]

@eallik @snoyberg related to Stackage, being able to list available snapshots (LTS, nightly) would be nice. If that is possible, it was impossible to find via the website.

Would a separate set of Stackage snapshots for what's "known good" w/ GHCJS be sensible?

[mgsloan]

@eallik Possibly! I don't think there's much to stackage itself related to GHCJS, though, so I imagine that this will be documented in stack / in tutorials elsewhere.

@bitemyapp If you want to read the nitty-gritty of the decision making process on that, here's the issue related to adding support for using GHCJS with stackage snapshots: https://github.com/commercialhaskell/stack/issues/1190 . So, essentially there is no need for a separate set of stackage snapshots, and ghcjs-only packages will probably get added to stackage.

[bitemyapp]

@mgsloan I had assumed there wouldn't be a separate compiler field, but rather that snapshots and compilers would be bolted together with a separate submission process for GHCJS.

Much as GHCJS has done a great job with compatibility, I'm not sure it makes sense to elide the distinction in the snapshots when that distinction is made for major GHC versions.

[mgsloan]

Yes, once there's a version of GHCJS on hackage, it would be good to get it and its associated libraries into stackage. I suppose when that happens, it'll be desireable to have just plain ghcjs be a valid value for compiler, where the ghc and ghcjs version is provided by the snapshot.

Until then, manually specifying the compiler is the best way I can think of for this to work.

[erikkaplun]

@mgsloan how about your own comment here 3 months ago? there seems to be quite a bit of information in this thread that solely applies to using stack with GHCJS? shouldn't that constitute the GHCJS specific portion of the doc?

[mgsloan]

@eallik I didn't properly understand how GHCJS worked 3 months ago. Another relevant issue is here: https://github.com/fpco/stackage-curator/issues/8 . Which doc do you think this stuff should be added to?

[erikkaplun]

I'm not sure; so one can just use stack/stackage with GHCJS without having to know about how stack works with GHCJS?

[mgsloan]

@eallik It should be pretty straightforward, but the docs certainly deserved more polish. I've done that in the following commits:

• A diff of a change to Stack & GHCJS wiki page
• https://github.com/commercialhaskell/stack/commit/d0dea5466e6544fa538d61ba9e1bb34990cc4c0d

Another benefit of using the same stackage snapshots for GHCJS is that you can take existing stack projects intended for GHC and build them with GHCJS via stack build --compiler ghcjs-0.1.0.20150924_ghc-7.10.2. Once ghcjs is in stackage snapshots, it will be possible to just do stack build --compiler ghcjs or perhaps even stack build --ghcjs

[erikkaplun]

Thank you! Exactly what I meant :)

[nrolland]

I updated @fizruk's build as of 2015-10-29

resolver: ghcjs-0.2.0.20151029_ghc-7.10.2
compiler-check: match-exact
setup-info:
  ghcjs:
      source:
            ghcjs-0.2.0.20151029_ghc-7.10.2:
                    url: "https://github.com/nrolland/ghcjs/releases/download/v0.2.0.20151029/ghcjs-0.2.0.20151029.tar.gz"

also had success setuping + building with

resolver: lts-3.0
packages:
- '.'
compiler-check: match-exact
setup-info:
  ghcjs:
      source:
            ghcjs-0.2.0.20151029_ghc-7.10.2:
                    url: "https://github.com/nrolland/ghcjs/releases/download/v0.2.0.20151029/ghcjs-0.2.0.20151029.tar.gz"

and stack setup --compiler ghcjs-0.2.0.20151029_ghc-7.10.2 stack build --compiler ghcjs-0.2.0.20151029_ghc-7.10.2

[emmanueltouzery]

I'm not really sure if this is the right place to ask, but... I have a working setup, there's just one little hitch: stack install works, until the copying bit: then it says Couldn't find executable cigale-web in directory [..]. Indeed in that directory, there is no cigale-web executable, but instead there is a cigale-web.exe subfolder (that ideally stack could copy recursively to my local-bin-path).

I'll probably handle this in a custom Setup.hs, but maybe there is a nicer solution that I'm missing here? Or is this still TODO?

[mgsloan]

@emmanueltouzery Yeah, you should just use stack build for ghcjs. stack install is just an alias for stack build --copy, adding on the extra copy step. Feel free to open an issue about that. While this should work in theory, it's actually kinda nice, I'd rather not have node versions of haskell exes laying around on my PATH.

[snoyberg]

I've actually had use cases where copying the JavaScript files elsewhere
would have been convenient

On Mon, Jan 25, 2016, 10:41 PM Michael Sloan [email protected]
wrote:

@emmanueltouzery https://github.com/emmanueltouzery Yeah, you should
just use stack build for ghcjs. stack install is just an alias for stack
build --copy, adding on the extra copy step. Feel free to open an issue
about that. While this should work in theory, it's actually kinda nice, I'd
rather not have node versions of haskell exes laying around on my PATH.

—
Reply to this email directly or view it on GitHub
https://github.com/commercialhaskell/stack/issues/337#issuecomment-174656040
.

[agocorona]

So finally there is first class install for ghcjs?.

I would like to install it in remote servers with scarce resources. For example in free instances of Cloud9 to enable users to clone and run example code. I can not do an installation from source there.

As a workaround, anyone know how to package and install the binaries manually? cloud9 workspaces are docker instances, so I can compile it in docker locally and translate the binaries.

[mgsloan]

So finally there is first class install for ghcjs?.

Stack has supported setting up GHCJS since v0.1.8, back in November of 2015

I would like to install it in remote servers with scarce resources. For example in free instances of Cloud9 to enable users to clone and run example code. I can not do an installation from source there.

Perhaps use docker? You may need to figure out how to do a binary distribution of GHCJS, afaik no one has figured out how to do a binary distribution, other than mechanisms like docker.

[ryantrinkle]

@mgsloan Maybe we can get stack to use nix's binary package distribution infrastructure somehow?

[mgsloan]

@ryantrinkle Perhaps so! Yes, nix is also a great approach, as demonstrated by your repo https://github.com/reflex-frp/reflex-platform

[geraldus]

Looks like runInteractiveProcess issue is still appears (I got it on my Travis GHCJS build via stack using LTS 7.7 with according compiler snapshot from Marcin).

Sample error message:

hsc2hs: rawSystem: runInteractiveProcess: exec: does not exist (No such file or directory)

To resolve this I added stack --no-terminal --install-ghc install hsc2hs in build section for GHCJS case (see this commit).

[haskellstudio]

hsc2hs: rawSystem: runInteractiveProcess: exec: does not exist (No such file or directory)

i resolve this by :

vim ~/.bash_profile 
export PATH=$PATH:/Users/yourMacUserName/.stack/programs/x86_64-osx/ghc-8.0.1/bin:/Users/hack/.local/bin

because hsc2hs is in /Users/yourMacUserName/.stack/programs/x86_64-osx/ghc-8.0.1/bin