search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
4k stars 843 forks source link

GHCJS? #337

Closed jkozlowski closed 9 years ago

jkozlowski commented 9 years ago

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

snoyberg commented 9 years ago

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

jkozlowski commented 9 years ago

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 commented 9 years ago

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

bitemyapp commented 9 years ago

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

mgsloan commented 9 years ago

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 commented 9 years ago

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

jkozlowski commented 9 years ago

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 commented 9 years ago

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

jkozlowski commented 9 years ago

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 commented 9 years ago

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

krisajenkins commented 9 years ago

+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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

jkozlowski commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

Big +1. Exciting stuff :)

CRogers commented 9 years ago

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

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

@luite GHCJSi is super exciting :D

manyoo commented 9 years ago

+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 https://github.com/commercialhaskell/stack/issues/337#issuecomment-115130526.

jkozlowski commented 9 years ago

+1 that would be perfect.

cdepillabout commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 notifications@github.com 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 commented 9 years ago

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

vikasmenon commented 9 years ago

+1. This would be neat.

jkozlowski commented 9 years ago

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

snoyberg commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

Thanks.

cies commented 9 years ago

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

akurilin commented 9 years ago

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 commented 9 years ago

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

kgadek commented 9 years ago

@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 commented 9 years ago

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

Beyond core functionality

Gnarly issues which caused this work to get derailed

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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