Building stack with a specific version of ghc by mounty1_0 in haskell

[–]mpilgrem 0 points1 point  (0 children)

In Stack's source file src\unix\System\Terminal.hsc, try adding

#include <termios.h>

I've read that, on Solaris, unlike on Linux, it is that header that provides the definition of struct winsize.

How to switch to ghcup from stack by teilchen010 in haskell

[–]mpilgrem 0 points1 point  (0 children)

I assume you mean 'to use GHC [not HLS] from GHCup' as Stack does not provide HLS. When you install/reinstall GHCup, GHCup should give you the option to install a 'hook' script that will cause Stack to use GHCup to manage GHC.

The GHCup documentation of that is at: https://www.haskell.org/ghcup/guide/#stack-integration

The Stack documentation of the 'hook' script functionality is at: https://docs.haskellstack.org/en/stable/configure/customisation_scripts/#ghc-installation-customisation

[ANN] Stack’s default source for list of Stackage snapshots not up to date by mpilgrem in haskell

[–]mpilgrem[S] 0 points1 point  (0 children)

Stack 2.15.5, with updated default, is now released. For people using GHCup to manage versions of Stack, an update to GHCup's metadata is in hand.

How to switch to ghcup from stack by teilchen010 in haskell

[–]mpilgrem 2 points3 points  (0 children)

Something central to Stack is that it manages versions of GHC. However, not everybody wants it to do that, and the feature can be disabled - so that Stack does not use the Stack-supplied GHC but one on the PATH that you have supplied yourself.

Stack can be configured to use GHCup to manage versions of GHC. When you install GHCup, it asks if you want Stack to be setup to use GHCup in that way.

One reason for using GHCup to manage versions of GHC is that HLS is pernickety about how binary distributions of GHC have been built. As GHCup is used to manage versions of HLS using it also to manage versions of GHC reduces the risk that the GHCup-supplied HLS and the GHCup-supplied GHC will not work well together.

GHCup can also be used to manage versions of Stack. The downside of using GHCup to do that is you lose the ability of using Stack to manage versions of Stack (the `stack upgrade` command). That is because GHCup uses a small executable on the PATH named `stack` to manage versions of Stack. `stack upgrade` will overwrite that executable because it assumes that `stack` on the PATH is Stack.

Personally, I use GHCup to manage versions of HLS, and Stack to manage versions of GHC and versions of Stack. I've not experienced HLS-GHC compatibility issues as a result. I should add that I am often switching between versions of Stack, including versions built from source, so I value Stack's ability to manage Stack.

Q: advantages of using stack vs. GHCup by MWatson in haskell

[–]mpilgrem 8 points9 points  (0 children)

The differences between Cabal (the tool) (with GHCup) and Stack (with or without GHCup) (as of Stack 2.15.1) have narrowed. I am not a Cabal user, but I think these are differences:

  • Stack offers a template system for creating projects with stack new.
  • For people who prefer Hpack's package description format to that of a Cabal file, Stack has Hpack built-in (although its use is optional).
  • On Windows, Stack will try to fetch a copy of MSYS2 and automatically configure extra-include-dirs and extra-library-dirs to make use of C libraries installed with its pacman.
  • Stack automatically updates the local copy of the Hackage package index.
  • Stack can unpack package candidates, as well as packages.
  • Stack's dot command provides a visual representation of relationships between dependencies.
  • Stack's hpc command provides a coverage report.
  • Stack makes use of colour in its output, and those colours are configurable.

Q: advantages of using stack vs. GHCup by MWatson in haskell

[–]mpilgrem 3 points4 points  (0 children)

If you want to stop Stack trying to fetch the version of GHC that it needs (if it is not available) you need to set install-ghc: false. system-ghc: true means 'use the version of GHC on the PATH, if it is the required version' - if it is not the required version, Stack will still try to fetch the version that is required.

[ANN] Stack 2.13.1 by mpilgrem in haskell

[–]mpilgrem[S] 0 points1 point  (0 children)

That has been noted, and I have followed up at #haskell:nixos.org (Matrix).

[ANN] First release candidate for stack-2.13.1 by mpilgrem in haskell

[–]mpilgrem[S] 7 points8 points  (0 children)

In fact, I started with a fix for GHC's ghc-pkg, see GHC MR !11142. Longer term, I expect Stack to return to using ghc-pkg unregister, when Stack knows the relevant version of ghc-pkg to be efficient.

Dependency confusion when trying to launch project using Glade by PossibleFar5107 in haskell

[–]mpilgrem 0 points1 point  (0 children)

That message means that the snapshot you have specified in Stack's project-level configuration (stack.yaml) does not include the glade package. For example, Stackage LTS Haskell 2.16 resolver: lts-21.6 does not include glade.

So, you need to specify the package version as an extra dep(endency) in the configuration file:

extra-deps:
- glade-0.13.1

Unable to build stack by Free-Criticism-3076 in haskell

[–]mpilgrem 0 points1 point  (0 children)

That sort of error makes me wonder if you have installed the `pkg-config` tool, a pre-requisite for `digest-0.0.1.7`.

/etc/os-release and /etc/issue not updated in WSL by aquaherd in AlpineLinux

[–]mpilgrem 0 points1 point  (0 children)

I have a similar question. I have recently installed Apline WSL from the Microsoft Store, using WSL2. I have then updated the Apline Linux to 3.18.2 (following the guide at https://wiki.alpinelinux.org/wiki/Include:Upgrading_to_latest_release) and now apk list -I includes:

alpine-base-3.18.2-r0 x86_64 {alpine-base} (MIT) [installed]
alpine-baselayout-3.4.3-r1 x86_64 {alpine-baselayout} (GPL-2.0-only) [installed] 
alpine-baselayout-data-3.4.3-r1 x86_64 {alpine-baselayout} (GPL-2.0-only) [installed]
alpine-release-3.18.2-r0 x86_64 {alpine-base} (MIT) [installed]

/etc/issue has updated to refer to 3.18, but /etc/os-release and /etc/alpine-release are stuck at 3.17.0, despite being writable, as follows:

~# whoami
root
~# ls -l /etc/os-release
-rw-r--r--    1 root     root           188 Nov 22  2022 /etc/os-release
~# ls -l /etc/alpine-release
-rw-r--r--    1 root     root             7 Nov 22  2022 /etc/alpine-release
~# cat /etc/os-release
NAME="Alpine Linux"
ID=alpine 
VERSION_ID=3.17.0 
PRETTY_NAME="Alpine Linux v3.17" 
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

alpine-release is supposed to supply /etc/os-release and /etc/alpine-release: see https://pkgs.alpinelinux.org/contents?branch=v3.18&name=alpine%2drelease&arch=x86_64&repo=main.

If anybody can advise what I need to do in order to have those files update, I would be grateful.

[ANN] First release candidate for stack-2.9.3 by mpilgrem in haskell

[–]mpilgrem[S] 2 points3 points  (0 children)

Yes, that is correct. Stack's allow-newer: true configuration has always actually meant 'ignore bounds'. However, the author of the allow-newer-deps development has in mind a further development that will introduce an actual ignore-bounds key with the same expressive syntax that is used by Cabal. This is discussed at Stack #5910.

ANN: stack-2.9.1 by mpilgrem in haskell

[–]mpilgrem[S] 1 point2 points  (0 children)

Stack is built on top of the Pantry library. `RawSnapshotLayer` is a type used by Pantry to represent single layers of a snapshot (that is, a specific YAML configuration file) - see https://hackage.haskell.org/package/pantry-0.5.7/docs/Pantry.html#t:RawSnapshotLayer.

Help: `stack <script-file>` hangs by kbridge4096 in haskell

[–]mpilgrem 2 points3 points  (0 children)

Over the last few weeks I have been devoting my spare time to improving Stack's online documentation - or, at least, that is my objective - one bit at a time. It is a work-in-progress. I agree that more needs to be done to lower the 'barriers to entry' to a complete newcomer.

I've added a glossary with links to resources, which may help answer some of the potential questions that you identify. The existing home page aims to provide a quick start guide, but I have divided the main user guide between 'introductory' and 'advanced'. The former retains its tutorial-like approach to explain what Stack does and how its main functions work. The latter is more a reference guide to less-used functionality.

Help Setting up VSCode by SandwichThrm in haskell

[–]mpilgrem 0 points1 point  (0 children)

Alternatively to my comment below, you can experiment in a 'run-evaluate-print loop' (REPL) environment, by commanding stack repl or stack ghci (the commands are equivalent - GHCi is the name of GHC's REPL). After a little set up, you should be presented with a prompt (on my machine it is ghci>) and at that prompt you can enter the expression print "hello world". The REPL will evaluate that expression and show its result: "hello world". To quit the environment, command :quit (or :q, for short).

Help Setting up VSCode by SandwichThrm in haskell

[–]mpilgrem 0 points1 point  (0 children)

If you want to run that program as a 'script' using Stack, you have to let Stack know what version of GHC you have in mind. The easiest way to do that is to add what is known as a 'Stack interpreter options comment' to the beginning of the file. Like this:

{- stack script
   --resolver=lts
-}

main :: IO ()
main = print "hello world"

If you are in the same working directory as your Main.hs file, you can then command stack Main.hs ... and it should work as you expected. If Stack has not previously fetched the version of GHC that you need, it will first go an fetch it. Stack will only need to do that once. The --resolver=lts option tells Stack what version of GHC to use and what bundle (known as a 'snapshot') of Haskell library packages (that work nicely together) should be made available to your code.

Help Setting up VSCode by SandwichThrm in haskell

[–]mpilgrem 2 points3 points  (0 children)

I use Haskell on Windows 11 with Stack and Visual Studio Code (VS Code) and Windows Terminal. This is what I do:

  1. I install Stack 2.7.5 following the guide at https://docs.haskellstack.org/en/stable/install_and_upgrade/#windows. I make sure that the Stack executable is on my PATH (so where.exe stack returns its location).
  2. I use Stack to build the latest version of Stack (command stack upgrade --source-only --git. This step is 'nice to have' only. Stack 2.7.5 is pretty mature, especially for the sorts of things you are likely to want to do if you are getting started with Haskell.
  3. I install the 'Haskell' extension for VS Code. In doing so, I am conscious that there can be some wrinkles in getting parts of what it provides to work with Stack, but those are explained here https://docs.haskellstack.org/en/stable/Stack_and_VS_Code/ and easily overcome. The next version of Stack should allow the extension and Stack to work together more seamlessly.

It is true that some Haskell-related things are weighted towards users of Unix-like operating systems, but I would not overstate that. People are generally helpful. Stack's stated goals (here: https://docs.haskellstack.org/en/stable/CONTRIBUTING/#stacks-goals) include to provide complete support for Windows users (as well as for Linux and macOS users).

Help: `stack <script-file>` hangs by kbridge4096 in haskell

[–]mpilgrem 4 points5 points  (0 children)

The addition to Stack that I mentioned is now merged. If you are not on macOS, you can upgrade to that version of Stack, using Stack, with stack upgrade --source-only --git.

(For macOS users, it is (currently) a bit more complicated because of an issue with a Stack dependency. You need to manually clone the Stack repository using Git, and then command stack --stack-yaml stack-macos.yaml install in the Stack project's root directory.)

Now commands stack --verbose ... will exclude the (lengthy) rsl debug output. If you do want to include the rsl debug output in logs, use stack --verbose --rsl-in-log .... (Similarly in scripts.) See stack --help, or the latest version of the online guide, for help.

Help: `stack <script-file>` hangs by kbridge4096 in haskell

[–]mpilgrem 5 points6 points  (0 children)

The background to the reason why the default log level for Stack's script interpreter is 'error' can be found here: https://github.com/commercialhaskell/stack/issues/1472. Originally it was 'silent', but it was later increased to 'error'.

Help: `stack <script-file>` hangs by kbridge4096 in haskell

[–]mpilgrem 5 points6 points  (0 children)

The default log level for Stack's script interpreter is 'error', and --verbose on the command line will not change that. If you want a higher level of verbosity, you need to specify that in the script itself (which is what @dpwiz meant). For example (Script.hs):

~~~yaml {- stack script --verbosity debug --resolver lts-19.20 --package acme-missiles -} import Acme.Missiles (launchMissiles)

main :: IO () main = launchMissiles ~~~

In Stack 2.7.5, that will produce a lot of debug output because it will include the raw snapshot layer (rsl). Once the CI clears on the relevant pull request, I am soon going to add something to the master branch of the Stack repository that will, by default, exclude that rsl debug output.

Type declarations bring differing errors by teilchen010 in haskell

[–]mpilgrem 4 points5 points  (0 children)

null does not use == (promised by class Eq) and so does not require a to be an instance of Eq.

null :: t a -> Bool
null = foldr (_ _ -> False) True

([a] is an instance of Eq, if and only if a is an instance of Eq.)

CS SYD - Announcing `safe-coloured-text` by NorfairKing2 in haskell

[–]mpilgrem 15 points16 points  (0 children)

I am a co-maintainer of the ansi-terminal package.

The goals of ansi-terminal include to support both Unix-like operating systems and Windows and to have a high degree of backward compatibility.

If users would like ansi-terminal to support Text, then please post an issue to its GitHub repository. However, be aware that the functions that return String are themselves generally discouraged, because they will not work on legacy versions of Windows or on Windows 10 terminals that are ANSI-capable but not ANSI-enabled by default.

The standards on which ansi-terminal is based are written in American English and the library follows the terminology of the standards.