I would like to produce an HTML / JS page with reflex-dom (only client side, frontend).
However, I use the singletons package (2.6) and it seems that it cannot be compiled with ghcjs or ghc 8.6.5 (singletons 2.5.1, broken-unpatched). Therefore, the reflex-platform solutions, reflex-stone or equivalent did not help me.
I saw that ghcjs 8.8 or 8.10 could be installed through haskell.nix, but I did not find how.
How can I do it?
Or maybe, is there a way to use GHCJS (or reflex-platform solutions) with recent packages (that need ghc 8.8 or +)?
Is there a way to use ghcjs-8.8 or 8.10 with the reflex-platform?
First of all I would like to highlight that I'm not in any way related to GHC or GHCJS projects development, just another person who encountered similar issues, so take it with a grain of salt.
Currently GHCJS supports <= 8.6.5 out of the box. There is some development going on now and we will probably see officially supported 8.10 soon.
Meanwhile you can try to build the following branches on your own risk:
8.10
8.8
The ghcjs-8.10.7 compiler is in the nixpkgs-unstable branch, so you should be able to nix-build haskell.compiler.ghcjs810. Note that after commit 41f40771488e99c914a3da5de086cf794242c6d7 something happened to make it stop building, I don't know if this has been resolved. But if you rewind to that point your build should work.
Note also that it produces very large and rather slow executables because the optimizer is disabled. Ghcjs-8.6.0.1 is more usable in this respect.
Related
I want to use Haskell on my computer currently running Windows 10 build 1803, and I am using a broadband connection of 25 Mbps. As of 2018, the Haskell compiler version known as ghc is 8.4.3.
First I download the stack from www.haskellstack.org/ The download is pretty fast since the file is small.
Upon installing stack and updating the stack to its path, I download ghc. The download is extremely slow. After downloading a mere 2.40 or 1.32 MB's it becomes still and after 30 minutes or so, it shows a socket connection error. I copied the error and searched for it in Stack Overflow, but it seemed futile.
As a solution to this, I uninstalled the sole version of stack and installed the Haskell platform which came bundled with ghc and other features along with Cabal and Stack. However upon starting a project using stack, it does not detect the ghc compiler and automatically tries to download the ghc version 8.4.3. Please note that I have added ghc to the path because whenever I type ghc in command line, it gives me the Haskell terminal, and also I have checked the environment variables.
No matter what I do I cannot let stack detect the ghc already coming from Haskell platform and prevent it from automatically downloading its own version of ghc, prior to which it gets stuck at 0.66% forever.
I am from India. Is the server providing the ghc through stack have no support in my country? Or is there any way out! I seemingly cannot install any Haskell packages, for my Haskell project!
You can try adding a mirror to speed it up, take a look at TsingHua stackage mirror.
Reference:
A set of useful alternative package index mirrors?
use alternative mirror with stack 2.1.1
I am relatively new to haskell, stack, ghc, etc.
Have been trying a few projects with ghcjs and haven't been able to build any of them, including reflex-dom-stack-demo. I am getting the following error:
In the dependencies for semigroupoids-5.0.0.4:
tagged-0.8.1 from stack configuration does not match >=0.8.5 && <1 (latest matching version is 0.8.5)
needed due to ghcjs-0.2.0 -> semigroupoids-5.0.0.4
Now I cannot understand whether I misconfigured something or there is truly a broken dependency. Deleted ~/.stack multiple times throughout my experiments.
I found this bug in stackage but am unsure whether this is what affects me, and whether it would be fixed once the fix moves through.
Using Ubuntu 17.10..
Any insight is welcome.
The recomended way to create a development environnement for reflex-dom is to use try-reflex.
It is tricky to build reflex-dom with stack, because some needed changes have not yet been added to the upstream libraries.
If you really want to build a reflex-dom environnement with stack, please consider these hints:
Do not use a GHC compiler with a version higher than 8.0.2
Do not use the reflex /reflex-dom versions from Hackage, they are outdated.
Use versions of reflex / reflex-dom from Github.
This repo contains a stack.yaml file, that used to work.
You may also try the stack.yaml file from the answer to this SO question.
I am using alternative version numbering approach for my projects. I have encountered strange behavior by cabal and stack that does not allow me to fully enjoy benefits of this approach. Both cabal and stack enforce version to be of format Int.Int.Int, which does not cover the case of another version format I use for branches (0.x.x, 1.x.x, 1.0.x, etc).
If I have line version: 0.x.x in my .cabal file, I am getting Parse of field 'version' failed. error when running cabal build or Unable to parse cabal file {PROJECT_NAME}.cabal: NoParse "version" 5 when running stack init.
Is there a way to disable version parsing on cabal and stack commands? Is there a flag for it? Or do I have to request this kind of change (adding flags, disabling version parsing) from the developers of cabal and stack?
Why is there any parsing at all? How does it help with building a package? Does cabal or stack automatically increment build numbers on some event? If yes, where could I read more about this? How could I influence the way version numbering incrementation gets implemented in cabal and stack? I want developers of haskell packages take into account the possibility of alternative version numbering approaches.
PS. For all interested folks, I want to quickly summarize the idea behind "weird" version numbers, such as 0.x.x, 1.x.x, 1.0.x. I use the version numbers with x's to describe streamlines of development that allow code changes while such version numbers as 1.0.0, 1.1.0, 2.35.46 are used to describe frozen states of development (to be precise, they are used for released versions of software). Note that such version numbers as 0.x.0, 1.x.15, 2.x.23 are also possible (used for snapshots/builds of software) and they mean that codebase has been inherited from branches with version numbers 0.x.x, 1.x.x and 2.x.x correspondingly.
Why do I need such version numbers as 0.x.x, 1.x.x and 2.x.x at all? In brief, different number of x's mean branches of different types. For example, version number pattern N.x.x is used for support branches, while pattern N.M.x is used for release branches. Idea behind support branches is that they get created due to incompatibility of the corresponding codebases. Release branches get created due to feature freeze in corresponding codebase. For example, branches 1.0.x, 1.1.x, 1.2.x, ... get created as a result of feature freezes (or releases) in branch 1.x.x.
I know this is all confusing, but I worked hard to establish this version numbering approach and I continue working on awareness about the inconsistencies of version numbering through my presentations and other projects. This all makes sense once you think more about the pitfalls of semver approach (you can find detailed slideshare presentation on the matter following the link). But I do not want to defend it for now. For the time being, I just want cabal and stack to stop enforcing their, as I perceive them, unjustified rules to my project. Hope you can help me with that.
You can't. The version will be parsed to Version, which is:
data Version = PV0 {-# UNPACK #-} !Word64
| PV1 !Int [Int]
Stack uses Cabal as a library but has its own Version type:
newtype Version =
Version {unVersion :: Vector Word}
deriving (Eq,Ord,Typeable,Data,Generic,Store,NFData)
Neither cabal nor stack have a way to customize the parsing. You have to write your own variant of those programs if you want to use another version type. But then again, you're not winning anything at that point: neither Hackage nor Stackage will recognize your package's version.
So the 1.x.x isn't possible at the moment. You could exchange x with 99999999 or something similar to mitigate the problem. That being said, it's not clear what cabal install should then install. The 99999999 version? Or the latest stable variant?
If you can express the semantics, a discussion on the mailing list as well as a feature request might change the behaviour in the (far away) future, but for now, you either have to patch the programs yourself or use another numbering scheme.
Is there a way to disable version parsing on cabal and stack commands? Is there a flag for it?
No.
Or do I have to request this kind of change (adding flags, disabling version parsing) from the developers of cabal and stack?
You can of course ask, but there are so many outstanding issues that you are unlikely to get any traction. You will have to be very convincing -- convincing enough to overturn more than 20 years of experience that says the current versioning scheme is basically workable. Realistically, if you want this to happen you'll probably have to maintain a fork of these tools yourself, and provide an alternative place to host packages using this scheme.
Why is there any parsing at all? How does it help with building a package?
Packages specify dependencies, and for each dependency, specify what version ranges they work with. The build tools then use a constraint solver to choose a coherent set of package/version pairs to satisfy all the (transitive) dependencies. To do this, they must at a minimum be able to check whether a given version is in a given range -- which requires parsing the version number at least a little bit.
Does cabal or stack automatically increment build numbers on some event? If yes, where could I read more about this?
There is nothing automatic. But you should take a look at the Package Version Policy, which serves as a social contract between package maintainers. It lets one package maintainer say, "I am using bytestring version 0.10.0.1 and it seems to work. I'm being careful about qualifying all my bytestring imports; therefore I can specify a range like >=0.10 && <0.11 and be sure that things will just work, while giving the bytestring maintainer the ability to push security and efficiency updates to my users." without having to pore through the full documentation of bytestring and hope its maintainer had written about what his version numbers mean.
How could I influence the way version numbering incrementation gets implemented in cabal and stack?
As with your previous question about changing the way the community does things, I think modifications to the Package Versioning Policy are going to be quite difficult, especially changes as radical as you seem to be proposing here. The more radical the change, the more carefully motivated it will have to be to gain traction.
I honestly don't know what a reasonable place to take such motivation and discussion would be; perhaps the haskell-cafe mailing list or similar.
One of my cabal libraries has hit this GHC bug. I currently have a workaround in the source, however since this GHC bug was now fixed in 7.8.3, I'm planning to remove the workaround soon. I'm not sure how to handle the situation to make the library refuse to build on GHC 7.8.0-7.8.2 though. Ideally I'd like that the user gets a nice error message ("GHC 7.8.0-7.8.2 have a bug preventing this library to build correctly, please use 7.8.3+" for instance).
Maybe some cabal flag? Or some CPP magic? I think the fix is in base, maybe I can condition on that, although it seems tricky or impossible.
Or I could carry the workaround for a very long time, until the issue is completely moot, but since mostly early adopters would have used 7.8.2 and earlier, I'm thinking it should not be a problem to drop the support, with a proper warning.
GHC 7.8.3 incremented the version number of base from 4.7.0.0 (used by the previous 7.8 releases) to 4.7.0.1. You can use the build-depends cabal field to exclude that version, for instance by adding the constraint base <=4.7.0.0 || >4.7.0.0.
I have the Haskell Platform 2012.4 installed on Windows. I would like to try the new extensions in GHC 7.6.2. It looks like the GHC 7.6.2 x86_64 download does not include an installer and is just the binaries. What is the proper way to get the latest version installed and set as the default for building Haskell projects? Thanks.
If you download GHC itself, you just get GHC and a tiny handful of libraries. If you download the Haskell Platform, you get GHC plus a much bigger collection of libraries. However, the Haskell Platform is updated infrequently, so you'll get an older version of GHC.
If you're asking "how do I install the Haskell Platform and then make it work with a newer GHC?", then the answer is "you don't". Haskell libraries have to be compiled for the specific version of GHC you're using.
You basically have two options:
Use the Haskell Platform, together with the version of GHC that it supplies.
Use the latest GHC, and compile whatever libraries you want manually.
On Linux it's not too bad, but Haskell libraries that bind to external C code tend to be fiddly to build on Windows. (Stuff like OpenGL, zlib, etc.) Packages that are 100% vanilla Haskell code are drop-dead easy to compile on any system.
I haven't done this and I'm at work so I can't test it out, but looking at the GHC docs I would think you can use the --with-compiler=path flag to select which version of GHC to use?
See also this question, related to using cabal with multiple versions of ghc installed. I would guess that you probably want to use cabal-dev or something to sandbox this, otherwise your package database may become a mess.
EDIT: As far as a default, I think you can set that in a cabal configuration file. See the comments to the accepted answer in that question I linked.
The other answers here are great, and I wanted to add that the current best way to get the latest version of GHC installed is to look at haskell.org's installation instructions. I bounced between lots of different options before I landed there, and I think it's the best source of truth from what I can tell.
To summarize the current instructions: if you already have chocolately set up, "at an elevated command prompt, run choco install haskell-dev, followed by refreshenv."