66
67

stack-0.1.8.0 is out (github.com)

akurilin が 投稿

全 34 件のコメント
並べ替え:
ベスト
トップ新着論争中古い順Q&A

[–]ephrion 28ポイント29ポイント  (0子コメント)

GHCJS can now be used with stackage snapshots via the new compiler field.

awww man this is really exciting

[–]massysett 20ポイント21ポイント  (1子コメント)

The Haddock bug was the last reason I was keeping cabal around. If you find bugs in stack, report them; the team is fixing them pretty quickly.

[–]andrewthad 2ポイント3ポイント  (0子コメント)

The haddock issue I reported got fixed in under two weeks. I'm really pleased with how fast the turnaround is on bugfixes.

[–]massysett 32ポイント33ポイント  (11子コメント)

Just today I was thinking of how skeptical I was of Stackage and Stack. Seemed to me there wasn't much wrong with cabal and raw Hackage.

Now I realize there was a lot wrong with it; I had just grown used to fixing the problems. But I suddenly realized how much of an improvement stack was when I was (recursively enough) building stack using stack. The dependency graph had over 100 packages in it. In the cabal and raw Hackage days, I would have crossed my fingers and hoped something like this could build. Some things would probably break along the way, and sometimes I could fix it, sometimes not.

Now, with stack, I don't cross my fingers. I expect it to build. And it does.

So in a short time I went from a skeptic to someone who can't remember how I ever got along without these tools. If you're wondering if you should get on board, do it.

oh - and stack upgrade worked--not by downloading a binary, but by fetching the stack code from somewhere and building it using the old stack.

[–]haskman 2ポイント3ポイント  (0子コメント)

Agreed! I have several old private projects with multiple old dependencies. With stack I am always able to build each project independently (and not by deleting all ghc packages and starting from scratch). Once you get used to it, going back to cabal is difficult, and unnecessary.

[–]decimalplaces 0ポイント1ポイント  (4子コメント)

I would prefer it downloaded a binary. What is the advantage of compiling locally?

[–]MdxBhmt 5ポイント6ポイント  (0子コメント)

To prove a point

[–]borsboom 6ポイント7ポイント  (0子コメント)

It also means that if you built your own stack binary on a platform that we don't provide binaries for, you can still use stack upgrade. That said, there are plans to provide a binary upgrade path as well: https://github.com/commercialhaskell/stack/issues/1238.

[–]Crandom 3ポイント4ポイント  (1子コメント)

To get a prereleased version of stack.

[–]existsforall 0ポイント1ポイント  (0子コメント)

I am mad in love with stack

[–]guaraqe 0ポイント1ポイント  (1子コメント)

Can I ask a question? As I understand, stackage is a coherent subset of hackage that works well together. Being a subset, shouldn't cabal be able to reproduce this stability using the dependency solver, at least in a single install basis? Or is there something else I missed?

[–]massysett 0ポイント1ポイント  (0子コメント)

You can use Stackage without using stack. The "QuickStart" at stackage.org tells you how to use Stackage with cabal. You drop in a configuration file that tells cabal exactly which package versions to use.

stack is easier to use because it does the right thing by default, unlike cabal which requires you to explicitly set up sandboxes. stack also caches the packages it builds and shares them across your system, which saves a lot of time when you have multiple projects.

[–]StackLover -5ポイント-4ポイント  (1子コメント)

Yeah, cabal has become useless thanks to stack... they should have focused more on the UX part rather than trying to implement some over engineered noreinstall solver nobody needs anymore thanks to stackage... ໒( ･ Ĺ̯ ･ )७

[–]andrewthad 1ポイント2ポイント  (0子コメント)

I use stack rather than cabal-install. I agree that is better for most use cases, but your comment is not in good taste. Besides, stack still uses cabal-install for dependency solving when you use packages that aren't on stackage, so you're likely still using that solver whether you appreciate it or not.

[–]drb226 2ポイント3ポイント  (11子コメント)

Are there blog posts or screencasts yet about the ghcjs/stack workflow? I'm looking forward to the day when it is effortless to add ghcjs to a project.

[–]mgsloan 5ポイント6ポイント  (1子コメント)

Hey! No blog post yet, but here's the current documentation https://github.com/commercialhaskell/stack/blob/master/doc/ghcjs.md . Please let me know if there are any good ways to make this more effortless.

[–]drb226 4ポイント5ポイント  (0子コメント)

It would be more convenient if there were:

  • a stack new template that sets up a yesod project with ghcjs on the client side
  • some way to call "stack test" once on such a project and have it configured to compile everything and do all the right things
  • some way to run yesod devel such that code changes, including the ghcjs portion, are hot swapped with near-instant compile times

For example, with clojure and clojurescript this is possible like so:

  • lein new figwheel # new project template
  • lein test # to test
  • lein uberjar # to compile to a .jar
  • lein figwheel # very fast live code reload

[edit] Another amazing convenience that comes with lein figwheel is a clojurescript repl that automatically connects to your browser. You can write (js/alert "hi") in the repl and the browser will pop up that alert. You can inspect the state of refs and manually invoke callbacks. It's amazing.

[–]mallai 1ポイント2ポイント  (0子コメント)

See compiler setting.

[–]vagif 3ポイント4ポイント  (6子コメント)

It is pretty effortless now, but takes a long time to install:

cabal install http://ghcjs.luite.com/master.tar.gz
ghcjs-boot --dev

[–]mgsloan 2ポイント3ポイント  (0子コメント)

Note that you need cabal-install >= 1.22.4 in order for ghcjs-boot to work properly. This is one of the things that stack setup ensures.

[–]Crandom 1ポイント2ポイント  (3子コメント)

This is how to install with cabal, though.

[–]vagif 2ポイント3ポイント  (2子コメント)

Which you are advised to do anyway given a bleeding edge (bugs) of ghcjs.

Once installed with cabal you can use it from stack by simply adding

compiler: ghcjs-0.2.0_ghc-7.10.2

to your stack.yaml

For example current release snapshots of ghcjs have missing module XHR. So i have to install from git. And stack currently does not support that option.

[–]existsforall 1ポイント2ポイント  (1子コメント)

if you point to release snapshot as in below what is the difference ?

https://github.com/commercialhaskell/stack/issues/337#issuecomment-152779649

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"

[–]vagif 1ポイント2ポイント  (0子コメント)

No, current release snapshots still missing XHR. That's my point. There are still too many bugs in ghcjs to rely on releases.

[–]existsforall 1ポイント2ポイント  (0子コメント)

well you dont quite know what's behind that version. some libs still use JSRef, some require the new JSVal.

Again, stack just saves the day in a breeze as you can point to the build of your choice

https://github.com/commercialhaskell/stack/issues/337#issuecomment-152779649

I ddi not play with the new 0.1.8.0 but that should further extend that scheme as I understood

[–]haskman 2ポイント3ポイント  (0子コメント)

Putting this in my stack.yaml just works for me (with preinstalled ghcjs binaries on my path) -

compiler: ghcjs-0.2.0_ghc-7.10.2

[–]Hrothen 2ポイント3ポイント  (2子コメント)

I've been wondering for a while, but why does stack install binaries in .local/bin? As far as I can find no other program uses that path, so why not just put the bin dir under .stack/?

[–]snoyberg 2ポイント3ポイント  (1子コメント)

The install guide has a section on paths, which links to issue #153 where this was discussed.

[–]Hrothen 0ポイント1ポイント  (0子コメント)

I've read that issue, and it's actually not technically "discussed", one guy suggests it and no one has a problem with it. I'll grant that apparently two other things use it though, so it's not as silly as creating a totally new path just for your project that has no association with it.

[–]eacameron 1ポイント2ポイント  (0子コメント)

Amazing work!

[–]LadenSwallow 1ポイント2ポイント  (1子コメント)

What happened to 0.1.7.0?

[–]borsboom 3ポイント4ポイント  (0子コメント)

Looks like this post linked to the changelog rather than the release announcement, but in there it says:

Note that, starting with v0.1.8.0, releases of Stack will always have an even-numbered second-to-last version component. Odd second-to-last version components are reserved for unstable builds.

[–]Hrothen 0ポイント1ポイント  (0子コメント)

Relative local-bin-path paths will be relative to the project's root directory, not the current working directory. #1340

Hmm, the linked issue implies local-bin-path is used when building with stack build but according to the documentation it's only when using --copy-bins or stack install. Did that behavior get changed?

[–]Darwin226 0ポイント1ポイント  (0子コメント)

Still haven't managed to get a single sample project working with GHCJS on Windows.