Busy discovering Haskell libs. Found FLTKHS for GUI building. Its example fltks-hello-world works great as a skeleton for discovering the all the lib has to offer. However: when changing anything in the source file (fltkhs-hello-world.hs), does one need to stack build it all over? GHCi doesn't seem to grasp the FLTKHS imports, so the REPL is IMO no viable option. Interested in your way of working to learn....
Found out that future builds are way quicker. Not as fast as GHCi though...
Related
Long story short, I'd like some guidance on what's the (best) way to have Haskell work on Archlinux.
By work I mean all, in terms of the ghci command line tool, installing packages I don't have - such as vector-space, which this answer to a question of mine refers to -, and any other thing that could be necessary to a Haskell obstinate learner.
Archlinux wikipage on Haskell lists three (alternative?) packages for making Haskell work on the system, namely ghc, cabal-install, and stack. I have the first and the third installed on my system, but I think I must have installed the latter later (unless it's a dependency to ghc) while tampering around (probably in relation to Vim as a Haskell IDE). Furthermore, I have a huge amount of haskell-* packages installed (why? Who knows? As a learner I must have come multiple times to the point of say uh, let's try this!).
Are there any pros and cons ("cons", ahah) about each of those packages?
Can they all be used with/without conflicts?
Does any of them make any other superfluous?
Is there anything else I should be aware of which I seem apparently ignorant about based of what I've written?
Arch Linux's choice of providing dynamically linked libraries in their packages tends to get in the way if you are looking to develop Haskell code. As an Arch user myself, my default advice would be to not use Arch's Haskell packages at all, and instead to install whatever you need through ghcup or Stack, starting from the guidance in their respective project pages.
You are basically there. Try the following:
ghci: If you get the Haskell REPL then it works.
stack ghci: Again you should get the Haskell REPL. There are a lot of versions of GHC, and stack manages these along with the libraries. Whenever you use a new version of GHC stack will download it and create a local installation for you.
stack is independent of your Linux package manager. The trouble is that your distro will only have the Haskell libraries it actually needs for any applications it has integrated, and once you step outside of those you are in dependency hell with no support. So I recommend that you avoid your distro Haskell packages. stack does everything you need.
If you installed stack from your Linux package manager then you might want to uninstall it and use a personal copy (i.e. in your ~/.local directory) instead. Then you can always say stack update to check you have the latest version.
Once you have stack going, create a project by saying stack new my-project simple. Then go into the project folder and start editing. You can work with just a .hs file and GHC if you really want, but its painful; you will do much better with stack, even if you are just messing around.
You'll also need an editor. Basic functionality like syntax highlighting is available in pretty much everything, but once you get past Towers of Hanoi you are going to want something better. I use Atom with ide-haskell-ghcide. This uses the Haskell Language Server under the hood, so you will need to install that too. I know a bunch of other editors have HLS support, but I don't have experience with them.
Does for anyone else stack compile & link the whole project when only stack ghci is asked for?
Shouldn't it skip the former and jump into ghci right away to load sources? I've observed it to do both for me on most of my projects and therefore it's doing seemingly superfluous work. Is this by design, or might have I misconfigured some of my stack projects?
Perhaps is this done by cabal underneath without stack asking for it?
And at any rate, is there something I could do to skip the compilation + linking when I just want to enter stack ghci?
From the Haskell Tool Stack Documentation:
Speeding up initial load
There are two ways to speed up the initial startup of ghci:
--no-build, to skip an initial build step. This only works if the dependencies have already been built.
You can also have stack ghci skip loading sources (if you know you only want one file loaded in, and can do it by hand) by using:
--no-load, to skip loading all defined modules into ghci. You can then directly use :load MyModule to load a specific module in your project.
I've just realized that -fobject-code may also play a part in this. I'm unsure where it is being set (not on the command line, not in the .cabal/package.yaml file and not in ~/.ghci either).
Nevertheless when I negate it with --ghci-options=-fbyte-code the recompilation doesn't seem to be taking place.
I still hope to hear others' responses as I'd like to understand more thoroughly why the -fobject-code may require minutes for full recompilation on initial load, since :reloading only takes about a second after a file has changed. (E.g. with ghcid too.)
I took the habit of managing my post-install setup things in the Setup.hs. The advantages are clear: it's coded in haskell, and it has access to the app data directory, where the binary will get installed.
I'm using it now for instance, to copy the QML data files and icons that a haskell QML application needs to the installation folder.
This all worked well until recently, but now stack started optimizing the build a lot, and if it detects that no haskell files changed, it won't re-trigger the Setup.hs. That obviously doesn't work for me, because I'd like my QML files and icons to get copied every time I run stack install during development.
I can't find a flag for stack that would trigger just the Setup.hs and nothing else (or little else -- certainly clean and --reconfigure force rebuilding too many things). How are people doing that? Should I write a shell script? But it'll have trouble finding the target directory for the installation, plus it's less portable that the haskell in my Setup.hs?
I feel stack are probably right in their reasoning and if my current way was really correct they would have enabled this scenario by now. So either there's a stack flag that I don't see, either I'm doing it wrong I think.
NOTE: stack is so smart that not even touch Setup.hs or of another .hs file helps to re-trigger its execution. I must physically change the contents of one file.
NOTE2: Ah, I re-discovered stack path to find out target path information. I could use that from a shell script to install the files. Still feels like a shame to write that in shell when I have haskell...
NOTE3: posted the question on the stack mailing list now...
NOTE4: actually opened a stack bug now
I recently finished the book "learnyouahaskell" and now I would like to apply my acquired knowledge by building a yesod application.
However I am not sure about how to get started.
There seems to be two options on how to set up a yesod project. One is with Stack, and the other is with cabal sandboxes.
But what are the differences (If any?) and the similarities between them? Does one count as best practice whereas the other doesn't?
The yesod quickstart suggests using stack, is this fine or should I use cabal sanbox?
There are actually three different packages that are being talked about here.
cabal-install is the current stable binary to build your applications.
stack was just released to the public recently. I believe it is trying to replace cabal-install as a better, more convenient tool. At the very least, it is showing the Haskell community a different way of something things.
Cabal is the library that both cabal-install and stack are based off of.
As for the differences between the first two tools.
cabal-install is a mature application used nearly everywhere within the Haskell community (at least in open source, I have no idea what people are doing behind closed doors).
stack is still a new (at least to the public) application used in some newer projects. Some more information can be found here. But some of the highlights are:
running stack build in a projects directory will install GHC (Haskell compiler) as well as the needed dependencies for the project.
stack, by default, runs off of stackage. Which is a curated version of hackage. Meaning you can expect the different packages to play nicely with each other. Leading to reproducible builds.
You can still fall back on hackage should you choose to.
The great thing about these two applications is that they can be used by different people for the same project. If you decide you want to use cabal-install with sandboxes, and someone comes along and wants to help with your project, they can just add the files that stack needs and they can use stack while you continue to use cabal-install. Or vice-versa.
here is one persons experience after using stack for the first time. They claim that it is a little bit easier to get started because there are a couple less steps required to get started. If nothing else, people highlight the pros and cons of each tool.
Note: I'm still fairly new to Haskell, and have never actually used stack. I've actually been told to stay away from it unless building something in yesod.
Edit: As stated in a comment under this answer, I believe I have mis-represented what people have told me about stack. The comments people have given me when I asked if I should switch over to stack were more along the lines of, If you are comfortable enough using cabal sandboxes, there is no reason to switch over to stack unless you are having issues.
The lead developer of Yesod (Michael Snoyman) is actively involved with the Stack tool. So, I would recommend you to set up Yesod with Stack. Also, Yesod has a quite a complex set of dependencies and using Stackage as the default curated source, helps very much in the installation process (which Stack takes care of by default).
Also read this post for understanding the differences of Stack from cabal.
I'm working on a Python/Haskell project and I'm looking for alternatives to Makefile. Obvious choices are Python SCons and Haskell Shake. Since I have no experience with either of them, I'd like to ask if there is any comparison of their drawbacks and advantages.
Update: The project has somewhat complex requirements for building:
Let the user configure the build - like options to enable/disable, paths to tools etc.
There are both Haskell and Python files generated at compile time. Their dependencies should work properly.
There are multiple Haskell programs that share most of the source files. I'd like so that:
it's possible to build each one individually, not building the sources that aren't needed;
source files aren't built multiple times when compiling multiple programs;
yet achieve parallelism during compilation, if possible.
Check for several installed programs on target systems and their paths (like python, flock etc.)
Check for dependencies on target systems, both Python, Haskell.
Parametrize the build according to the dependencies - if the dependencies for testing are missing, it should still be possible to build the project, skipping the tests (and informing the user about it).
There is a Why Shake? document that gives reasons to chose Shake over other build systems, but it does not focus on a comparison to SCons.
Update: All of your requirements seem easy enough to express in Shake (ask on StackOverflow if you get stuck with any of them). As to Shake vs SCons:
Shake is particularly good at dealing with generated files with dependencies that cannot be statically predicted, particularly if you are generating the files from programs you compile.
Building the Haskell parts of your project is likely to be harder than building the Python (since Haskell has a richer structure and more complex compiler). Using Shake makes it easier to tap into existing examples of compiling Haskell and use libraries for parsing Haskell if you need it.
There is a SCons wiki page that compares it to other build tools, unfortunately there is no comparison there with Haskell/Shake.
Also, this question may help.
SCons really shines as compared to other tools (especially make and cmake) by its Python syntax, and its implicit dependency system that is very accurate and easy to use.