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
Related
I don't get the point about Stack.
I used to write my Haskell code in my favourite environment, ran or compiled using GHC(i), and if necessary, installed packages using Cabal. Now, that apparently is not the way to go any more, but I don't understand how to work with Stack. So far, I have only understood that I need to write stack exec ghci instead ghci to start a repl.
Apart from that, the docs always talk about 'projects' for which I have to write some yaml files. But I probably don't have any project -- I just want to launch a GHCi repl and experiment a bit with my ideas. At the moment, this fails with the unability to get the packages that I want to work with installed.
How is working with Stack meant? Is there any explanation of their use cases? Where do I find my use case in there?
Edit. My confusion comes from the fact that I want to work with some software (IHaskell) whose installation guide explains the installation via stack. Assuming I already have a GHCi installed whose package base I maintain e.g. using Cabal. How would I have to set up stack.yaml to make stack use my global GHCi for that project?
First, notice that stack will use its own package base independent from cabal. AFAIK they can't be shared... hence, if you run stack build it'll download packages (including the compiler) on its own package database.
Nevertheless stack allows to use a system compiler (but not other libraries). To do so, in the stack.yaml you must have the following two lines
resolver: lts-XX.XX -- keep reading below
system-ghc: True
The version of the stackage snapshot can be found in: https://www.stackage.org/. Each snapshot works with a different version of the compiler. Be sure to use a snapshot with the same compiler version you have in you system. If it happens your system ghc is greater than any lts, then you can set allow-newer: true in stack.yaml.
Now, if getting a different database from stack feels wrong to you, notice that you can build the project with cabal too, since stack at the end of the day spits out a cabal file. Probably, It wont work out of the box if you build with cabal. You can modify the cabal file to match exactly the version of the packages of the snapshot you are using
In summary:
You can use your system-wide ghc
you can not share libraries installed with cabal.
you can use cabal to build the project, probably modifying the ihaskell.cabal file to match versions of the stackage's snapshot.
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'm working on a fairly simple text-editor for Haskell, and I'd like to be able to highlight static errors in code when the user hits "check."
Is there a way to use the GHC-API to do a "dry-run" of compiling a haskell file without actually compiling it? I'd like to be able to take a string and do all the checks of normal compilation, but without the output. The GHC-API would be ideal because then I wouldn't have to parse command-line output from GHC to highlight errors and such.
In addition, is it possible to do this check on a string, instead of on a file? (If not, I can just write it to a temp file, which isn't terribly efficient, but would work).
If this is possible, could you provide or point me to an example how how to do this?
This question ask the same thing, but it is from three years ago, at which time the answer was "GHC-API is new and there isn't good documentation yet." So my hope is that the status has changed.
EDIT: the "dry-run" restriction is because I'm doing this in a web-based setting where compilation happens server side, so I'd like to avoid unnecessary disk reads/write every time the user hits "check". The executable would just get thrown away anyways, until they had a version ready to run.
Just to move this to an answer, this already exists as ghc-mod, here's the homepage. This already has frontends for Emacs, Sublime, and Vim so if you need examples of how to use it, there are plenty. In essence ghc-mod is just what you want, a wrapper around the GHC API designed for editors.
I have a stack which was originally built in Hypercard then migrated to Metacard. Obviously, it has expanded greatly over that time. Some core features broke when I tried to migrate to Runrev which is why I've waited till now to finally do that. I'm keeping it as a stack rather than an exe so I can save changes to it. I've built a standalone player to launch it and that is working. I've included the revmessagebox.rev stack in the Standalone Stack settings. This does add it but, incorrectly. I can put messages to it from my stack but, it won't run commands and it's missing all it's icons. I'm also included the revimagelibrary.rev and revtools.rev stacks in the hopes of fixing this but, no dice. I was also hoping that including revimagelibrary.rev would get my old Metacard icons to display but, no dice. I appreciate any help I can get on this.
Rich
I don't think you can. The message box is part of the IDE and requires the development environment to run. When you build a standalone your scripts etc are compiled and an interpreter for commands is no longer present.
To replicate it in a standalone you could use a simple window with a field to accept text and would require you passing the text entered to a "Do" command. The other functions present with the message box (accessed via the icons you mentioned) are also development tools and don't make much sense in a standalone.
The message box is not only integrated into the IDE, the engine also has hooks that directly support it. I'm not sure those hooks are included with the engine that is built into a standalone, so even if you adapt the existing message box for your standalone it still may not work correctly.
The solution, as others have said, is to build your own stack that functions as a pseudo-message box. It is easy to display messages in your own stack, and pretty easy to execute simple commands using the "do" command. It is somewhat more difficult to execute complex or multi-line commands. But I agree with Dunbarx that I'd assess the need for such a thing if you are planning this standalone for distribution. It's a non-standard interface element.
What James said. But note that though the msg box is indeed integral to the IDE, it is still just a stack, and that stack can be replicated to whatever extent you need.
That said, the msg box is usually used as a development tool, to test short scripts (usually one-liners), to get or set property values quickly, as a simple calculator, that sort of stuff. If you need that sort of functionality, you should probably integrate it more comprehensively into the structure of your project.
Craig Newman