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 (ghcjs/ghcjs#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 notifications@github.com 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 #337 (comment).

[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.

[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: #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: fpco/stackage-curator#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
• d0dea54

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 notifications@github.com
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
#337 (comment)
.

[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