I cloned this and now it proposes to build again every time as I’ll use cabal REPL.
Can anybody please help me telling, how to restore cabal repl, set to the original unmodified state?
Can you give an example of what you mean? The command you are running, and the output?
Here is example…
- HGCi works normally - with a little change, propt λ: which I defined.
It begins this way…
myhaskell % ghci
Loaded package environment from /Users/polarit/.ghc/aarch64-darwin-9.4.8/environments/default
GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/xyz/.ghci
λ:
exit this way…
λ: :q
Leaving GHCi.
myhaskell %
- This is the altered cabal REPL
myhaskell % cabal repl
Resolving dependencies...
Build profile: -w ghc-9.4.8 -O1
In order, the following will be built (use -v for more details):
- fake-package-0 (lib) (first run)
Configuring library for fake-package-0..
Warning: No exposed modules
GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/xyz/.ghci
Loaded GHCi configuration from /var/folders/nn/nk195p6n2038d_1ml53718lm0000gp/T/cabal-repl.-28504/setcwd.ghci
λ: :q
Leaving GHCi.
myhaskell %
I don’t even understand, 1. why does it propose to build some fake package on cabal in the beginning and
2. why does it tell “Leaving GHCI.” although I was running cabal repl ! and
3. why cabal REPL is using the settings given to GHCi ( prompt λ: ? )
If you do cabal repl -b aeson -b servant then cabal brings the aeson and servant packages into scope by creating a “fake package” that depends on them both. I guess you do cabal rep with no -b then it still creates a fake package, that depends on nothing.
Because cabal repl is a wrapper around ghci.
Presumably because of this line
Loaded GHCi configuration from /Users/xyz/.ghci
Did you configure prompt λ: in that file? Because cabal repl is ghci it just picks up the normal configuration of ghci.
1 Like
Yes, I added that prompt by myself and there was nothing mystic yet cauz I could also cancel the setting otherwise as the git I downloaded and run.
I don’t know what aeson and servant do to my GHC, thus I’ll just stepwise kill all the suspective files created after downloading of the git snippet, listing first also the unvisible files with (unix/linux/mac) command lst -lrta. Maybe I’ll next destroy all of my GHC and upgrade ghcup, ghc, hls, stack and cabal with hope I’ll get rid of all garbage. I have still GHC version 9.4.8 as recommended by GHCup tui version 0.1.30.0.
Well, before doing all that, I’ll do virus scanning of the GHC beginning from the root ~/.ghcup/bin/
How about using the latest GHC 9.10.1, is it stable version? Is the recommended 9.4.8 kind of LTS version and the first selection for production, industrial, commercial, science or which ever use?
Currently, the GHC developers classify all of GHC 9.6.6, 9.8.2 and 9.10.1 as (EDIT) ‘current stable releases’: see Download — The Glasgow Haskell Compiler.
I am not in ‘industry’ but I understand that what ‘industry’ uses is path dependent for each user and, consequently, varies from user to user. That is because moving from one version of GHC to another brings costs (of the change) as well as benefits. I have seen some industry users say that when they move, they can ‘jump over’ some major versions.
The GHCup project weighs up various things when thinking about what GHC version to recommend. For example, see the discussion here: [RFC][GHCup] Should GHC 9.6.4 be 'recommended'?.
At Stackage, currently the most recent LTS uses GHC 9.6.6 and nightly uses GHC 9.8.2: see https://www.stackage.org/. That project tends to avoid the first minor version (sometimes, versions) of a new major version of GHC. I think it waits for users on the ‘cutting edge’ to reveal any bugs from use that are then fixed in later minor versions. A key FAQ is “Why is Stackage LTS still on an older version of GHC?” - see GitHub - commercialhaskell/stackage: Stable Haskell package sets: vetted consistent packages from Hackage.
3 Likes
Noted. I’ve updated my post to be more precise. Do you interpret the ‘blue blob - current major series’ against the GHC 9.10 series as ‘not-stable’? I don’t really follow why GHC 9.2 is ‘yellow blob’ and GHC 9.4 is ‘green blob’, when both are ‘stable but no future releases planned’.
Thank you for good instructions!
I managed to build another project using package haskell-say-1.0.0.0. It has taken lots of time and two rounds because the template to be filled was much longer than I imagined. There were errors and some missing things in the first round. Is there some special name for simple type of project? I think I selected a wrong type, maybe default template for new project.
Now I know much better how it builds. Here you see the result of my first project:
[...]
Ok, three modules loaded.
Loaded GHCi configuration from /Users/polarit/.cache/stack/ghci-script/b7c53a5d/ghci-script
ghci> main
________________________________________________________
/ \
| Hello world! How are you? We are now in Haskell. |
\____ _____________________________________________/
\ /
\ /
\/
_____ _____
\ \ \ \
\ \ \ \
\ \ \ \
\ \ \ \ \-----------|
\ \ \ \ \ |
\ \ \ \ \---------|
/ / / \
/ / / \ \-------|
/ / / ^ \ \ |
/ / / / \ \ \ ----|
/ / / / \ \
/____/ /____/ \____\
ghci>
Yeah, the template for cabal init seems far too big to me. That’s why I prefer to use something as small as possible, like this: haskell-simple-start/my-dummy-package.cabal at master · tomjaguarpaw/haskell-simple-start · GitHub
(I have seen even simpler versions around, I think, but I’m not sure where.)
This was the most minimal thing I could come up with: "Is cabal-install stable enough yet that GHC should be inflicting it on newbies?" - #12 by jaror, but it won’t build anything; it will only install dependencies.
1 Like
Ah, so I could omit build-type at least. Thanks!
I created this project with stack - not cabal:
stack new my-project were the init was much bigger than in cabal.
Build has added to project-folder also a cabal file, I dont know why. Perhaps some missing things were taken from my earlier cabal project.
Btw, I have yesterday upgraded my ghc from 9.4.8 to 9.6.6. It was quite quick and easy using ghcup tui.
I have then built my project with ghc 9.6.6. I have used cabal packet say-haskell in build-debendences, maybe that is the reason for a extra-long build type required by stack.
1 Like
To (try to!) clarify matters:
-
“Stack” is the name for a CLI-based tool, which I commonly write as
stack; -
As for the name “Cabal”:
So where does stack fit in all of that? It’s an alternative to cabal-the-command only: stack also relies on cabal-the-library (and hence cabal-the specification). That’s why there’s a new .cabal file in your renewed project…as I dimly recall; @mpilgrem can let me know if I’m wrong.
The package description and the role of cabal file within it is presented quite well here. I found this just today.
1 Like
@atravers has correctly explained part of what you were asking, and you have found Stack’s online ‘getting started’ tutorial which, I hope, will answer many of your questions.
On the ‘size’ of Stack’s ‘init’: when you first run any of Stack’s main commands, Stack sets itself up (one time only).
When you first run any of Stack’s commands that needs a specified version of GHC, and it is not already available, Stack will try to set it up (again, one time only).
When you command stack init for an existing project without a Stack project-level configuration, Stack tries to create a configuration from the project’s packages’ description files (eg Cabal files) - and reports what it is doing.
When you command stack new, Stack sets up a simple one-project package from a template and then, effectively, does stack init. The project templates have fields that can populated with descriptive information (for example, the project’s author’s name and email address). A Stack user usually sets up that descriptive information (common to most projects) in Stack’s global configuration. Until you do that, you will get messages like:
Note: The following parameters were needed by the template but
not provided: author-email, author-name, category,
copyright and github-username.
You can provide them in Stack's global configuration file
(D:\sr\config.yaml) like this:
templates:
params:
author-email: value
author-name: value
category: value
copyright: value
github-username: value
Or you can pass each one on the command line as
parameters like this:
stack new testnew3 new-template -p
"author-email:value" -p "author-name:value" -p
"category:value" -p "copyright:value" -p
"github-username:value"
All of that, first time out, can generate a lot of messages but, unlike cabal init, Stack should not ask you for input during the process. Stack choses not to take an ‘interactive’ approach to set up.
1 Like
One other thing: you can use Stack with a Stack-supplied version of GHC. You can also use Stack with a version of GHC that you have supplied yourself and is on the PATH - known as a ‘system GHC’.
It sounds like you have taken the ‘system GHC’ route, because you have used GHCup’s TUI interface to install versions of GHC on to your system and make one of them (at a time) available on the PATH.
To tell Stack to use a ‘system GHC’ there are two key Stack configuration options. They can be specified at the command line or in Stack configuration files. They are:
--system-ghc (system-ghc: true) - tell Stack to try to use GHC on the PATH, if it is the specified version.
--no-install-ghc (install-ghc: false) - tell Stack to stop trying to supply a GHC, if the correct version of GHC is not already available to Stack.
1 Like
…but thank you for providing that link anyway - if I do manage to get back into Haskell development, I’ll definitely be remembering this thread!
This was yesterday one of my errors, still in the second round that I did’n select anything for GHC or PATH, then stack build has used very long time installing some GHC.
Today I found somewhere a clever line command, somehow related to this matter:
$(stack exec which my-executable)
I could not resist temptation to use it immediately, so if I understand anything, it’s a global setting of project/package setting system GHC PATH which shall be automatically used next time I build something in stack. I didn’t find anymore where that was told.
I’ll try to read this tutorial (1. to 15.) carefully before I do build next time anything.
stack exec which -- my-executable will execute command which my-executable in the Stack environment, and POSIX shell’s $() allows the use of the output of the command in other commands.
However, if all you want to do is run the my-executable that has been built by Stack, you can simply command stack exec my-executable because - in the Stack environment - Stack has put the location of that executable file on the PATH.
Or, you can use stack build --copy-bins (stack install, for short) to copy the built executable file to a defined location which you may have added to your PATH. In which case you can simply command my-executable (outside of the Stack environment) after stack install.
1 Like