I have on my computer (macOS High Sierra) multiple installations of the standard (Glasgow) Haskell compiler. The oldest one (as far as I can remember) is a minimal installation, while I obtained the most recent version form the "Platform" installer, something like five or six months ago. I'm trying to get rid of the whole ecosystem (ghc, stack, cabal, and friends), mostly because I don't know what tools I will be using in the case I'll plan to get back using the language.
So my questions are:
Where does the minimal/"Platform" installer installs Haskell and all related stuff?
How can one remove the whole Haskell language and all its components mentioned above (in the case of a "Platform" install, and even in the case of a minimal installation)?
EDIT: I've just remembered of the uninstall-hs command (see also here), should I run this instead of removing files manually?
I think I have come up with a solution and I'll answer the latter question first:
All the details I was looking for (what effectively is installed after launching the minimal / "Platform" installer, and, most importantly, where these guys were placed) can be found in the documentation welcome file at /Library/Haskell/Doc/Start.html. More precisely:
On Mac OS X, the Haskell Platform is installed in two major pieces: GHC and Haskell Platform. They are installed respectively in: /Library/Frameworks/GHC.framework and /Library/Haskell. Executables are symlinked in /usr/local/bin [...].
There are also another two or three directories in the home folder, namely ~/.ghc and ~/.stack.
As said in the OP, the script uninstall-hs done its work, showing a (at least I hope so) comprehensive list of all the files that constitutes the Haskell "sdk" actually installed.
Feel free to post your answers, I hope this post will be useful to the community.
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.
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.
For non trivial projects is commonly split it in several packages (in particular, I work usually with Visual Studio C# solutions containing 1-10 projects).
My current Haskell workflow is perform cabal clean && cabal configure && cabal install --force-reinstall for each time I modify some package that is used in another one.
That's works fine but I wish work with several Haskell projects as if only one be (ideally if A and B projects was modified then using ghci A detect changes on B).
The proposed solution (if possible) should work fine too if certain package A (in development) is shared in several "workspaces".
I looked for, but the unique related response (Haskell Cafe, Working with multiple projects 2009) suggest my current workflow as solution.
Any tutorial explaining it (workspaces, shared "in development" packages, ...) will be welcome!
Thanks a lot!!! :)
(I'm working with ghc)
So, basically you can use cabal-dev to make a local sandbox of the packages you want to use for a given project. This is will stop different projects that may have conflicting package requirements from mucking every thing up.
Here is a good post on reddit explaining the basics.
http://www.reddit.com/r/haskell/comments/f3ykj/psa_use_cabaldev_to_solve_dependency_problems/
Suppose I want to use different versions of GHC, each of them with a different binary name.
Question 1. Can I use ./configure --prefix=ghc-some-version-dir for each of the installations and create symbolic links ghc-7.4.1, ghc-7.6.2, ghc-head without problems?
That is, after the installation and creation of binaries from source code. Using virtual environments would still be needed for building projects and its dependencies.
Question 2. What prevents us from uploading ghc to Hackage with a package name ghc-version having a binary name that depends on its version? e.g. one could cabal install ghc-version-7.6.2 and get a binary ghc-7.6.2 in ~/.cabal/bin
You don't need to do anything special. GHC already installs all of its executables with versioned names and links from the non-versioned name to the most recently installed version, e.g. a link from "ghc" to "ghc-7.6.1" or whatever you installed last. When you build from the repository, the version number is quite long and includes the date you built it.
I don't know for sure why GHC isn't on Hackage, but I presume it's because the build system is very complicated, and that cabal-izing it (and maintaining the cabalization) would be more work than it's worth.
There are several soluttions
Just use chroot
Use a package manager that handles multiple versions of the same library/software such as nix
There are scripts which have been written to handle this such as https://github.com/spl/multi-ghc
Use gnu stow as described in Brent Yorgey blog post.
Ben Millwood has a solution where he just uses the -w flag, read his comment at:https://plus.google.com/u/0/100165496075034135269/posts/VU9FupRvRbU
Several months ago, I was inspired by the magnificent book ANSI Common Lisp written by Paul Graham, and the statement that Lisp could be used as a secret weapon in your web development, published by the same author on his blog. Wow, that is amazing. That is something that I have been looking for long time. The author really developed a successful web applcation and sold it to Yahoo.
With those encouraging images, I determined to spend some time (1 year or 2 year, who knows) on learning Common Lisp. Maybe someday I will development my web application and turn into a great Lisp expert. In fact, this is the second time for me to get to study Lisp. The first time was a couple of years ago when I was fascinated by the famous book SICP but found later Scheme was so unbelievably immature for real life application.
After reading some chapters of ANSI Common Lisp, I was pretty sure that is a great book full of detailed exploration of Common Lisp. Then I began to set up a web server in Common Lisp. After all, this should be the best way if you want to learn something. Demonstrations are always better than definations.
As suggested by the book Practical Common Lisp (by the way, this is also a great book), I chose to install AllegroServe on some Common Lisp implementation. Then, from somewhere else, I learned that Hunchentoot seems to be better than AllegroServe. (I don't remember where and whom this word is from. So don't argue with me.)
Ironically, you know what, I never could installed the two packages on any Common Lisp implementation. More annoyingly, I even don't know why. The machine always spit up a lot of jargon and lead me into a chaos. I've tried searching the internet and have not found anything.
Could anybody who has successfully installed these packages in Linux tell me how you did it? Have you run into any trouble? How did you figured out what is wrong and fixed it? The more detailed, the more helpful.
Have you tried these instructions?
I already had a working SBCL installation so I've only followed the second half of the instructions. It sets up a very minimal web app, so it lets you see just how to structure your own web app.
These instructions might not be quite what you're looking for - they're for setting up a web server (on Ubuntu) with remote interaction with emacs/SLIME, but I guess "remote interaction" could just as well mean localhost.
Basically, these installation steps are from this article A Simple Lisp Webapp for beginners, recommended by Frank Shearar (thanks again). But I didn't follow the exact steps because (1) I'd like to install Common Lisp with a local user; (2) I am not familiar with a few things the author mentioned. You can check out the original article or you can just follow me here. I am afraid my instructions are much easier to follow. :)
Three packages need to be downloaded before installation. sbcl binary and source packages can be downloaded here, and smanek package can be downloaded here.
sbcl-1.0.38-x86-linux-binary.tar.bz2
sbcl-1.0.38-source.tar.bz2
smanek-trivial-lisp-webapp-3681c1
Note: The version number may have changed when you see this essay. So don't bother to get the exact packages. However, this is right packages working for me.
Here is what I do (replace YOURPATH with your real path and I assume you are using BASH):
1. Install the binary sbcl package
tar jxf sbcl-1.0.38-x86-linux-binary.tar.bz2
cd sbcl-1.0.38-x86-linux
INSTALL_ROOT=YOURPATH sh install.sh
cd ..
Well, the binary sbcl package has been installed now. When the install program complains with something like "no manual found", it is OK since the manual stuff is not included in the binary package. Let it be.
2. Set the PATH and SBCL_HOME
export PATH=YOURPATH/bin/:$PATH
export SBCL_HOME=YOURPATH/lib/sbcl/
3. Install the source sbcl package
tar jxf sbcl-1.0.38-source.tar.bz2
cd sbcl-1.0.38
sh make.sh
export SBCL_HOME=''
INSTALL_ROOT=YOUROTHTERPATH sh install.sh
cd ..
NOTE: You may need to specify another directory for installation, or it will be installed into the same directory the binary sbcl resides in.
4. Set the PATH and SBCL_HOME
export PATH=YOUROTHERPATH/bin/:$PATH
export SBCL_HOME=YOUROTHERPATH/lib/sbcl/
5. Install the smanek package
unzip smanek-trivial-lisp-webapp-36816c1.zip
cd smanek-trival-lisp-webapp-36816c1
cd scripts
./startserver.sh
When it says "Webserver started on port 8080", you can visit "http://localhost:8080" in your web browser. It is there, right?
6. A few notes
After putting the three packages in one directory, you can run the above scripts one by one or in a batch. Remember to replace the PATHs with your real paths.
I suspect Shaneal Manek has hacked the asdf and hunchentoot packages a lot, as I didn't find anything in the $HOME/.sbclrc and $HOME/.sbcl. Thank you, Shaneal Manek, you've helped a lot of people a lot.
I still feel hateful toward those who always says a lot but does a little. Even people are angry, it is still evident that it is what they say matters, not how they say it. Nevertheless, I was wrong to say something bad in a bad mood.
5 years later.
it very easy with quicklisp. I assume you have installed SBCL or other CL implementation.
Go to your REPL and evalute
(ql:quickload :aserve)
start AllegroServe
(net.aserve:start :port 8000)
publish some HTML files
(net.aserve:publish-file :path "/" :file "~/hello.html")
Go to http://localhost:8000/
Happy hacking!.
read more about Introduction to AllegroServe Tutorial
Paul Graham has, for starters :-)
I too have found Common Lisp a lot of work to get past step one. The environment is terrible when you're just getting started, there's not a clear One True Path to get to the point where you can bang in some code and see some results (like there is with Python, for example). Like you, I wasted a lot of time jumping from one implementation to another. So my advice is:
I suggest you just pick one and ignore all other advice until you get it going.
If you're not in the mood, just get Apache and write some PHP :-)