# Newcomer help wanted in the Haskell Debugger

**URL:** <https://discourse.haskell.org/t/newcomer-help-wanted-in-the-haskell-debugger/14164>\
**Category:** Announcements\
**Created:** [May 28, 2026, 3:45pm UTC](https://discourse.haskell.org/t/newcomer-help-wanted-in-the-haskell-debugger/14164 "2026-05-28T15:45:31Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![romes](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/romes/32/2912_2.png) [@romes](https://discourse.haskell.org/u/romes)\
**Post date:** [May 28, 2026, 3:45pm UTC](https://discourse.haskell.org/t/newcomer-help-wanted-in-the-haskell-debugger/14164/1 "2026-05-28T15:45:31Z")

</div>

Hi all,

In preparation for ZuriHac, I’d love to have some help on a [few  
haskell-debugger issues](https://github.com/well-typed/haskell-debugger/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22help%20wanted%22).

These issues are especially relevant here because they will help more people  
use the debugger, and I do hope to onboard more people to using it in Zurich!

(Hopefully, some of you will even want to hack on these or other Haskell  
debugger features/bugs there).

If you want to work on any of these, do reply in the issue thread, to make sure  
two people don’t end up doing overlapping work:

- [Emacs Support](https://github.com/well-typed/haskell-debugger/issues/213): we’ve got instructions and tested the debugger with [VSCode](https://well-typed.github.io/haskell-debugger/), [nvim-dap](https://codeberg.org/mfussenegger/nvim-dap/wiki/Debug-Adapter-installation#haskell-hdb), and [vimspector](https://github.com/well-typed/haskell-debugger/issues/316); however, we need an Emacs user to take the lead in setting up `haskell-debugger` with a DAP plugin, testing it, and writing down how to do it for other users (@simonpj is on Emacs, and I have yet to get him to try the debugger).

- [Installing with stack fails](https://github.com/well-typed/haskell-debugger/issues/309): Stack users! Please help make the debugger installable using stack. I don’t know what the required details are, so do come help.

- [Ship via GHCup](https://github.com/well-typed/haskell-debugger/issues/319): GHCup now supports 3rd party tools, and @hasufell suggested we start distributing `haskell-debugger` through GHCup in this way. Installation is currently a bit subtle (because of the flags we must pass to `cabal-install`), so providing ready to use binaries in GHCup would be excellent.

- [New Debugger Logo](https://github.com/well-typed/haskell-debugger/issues/210): We would love to have a cool logo for the debugger VSCode extension! It should ideally be recognizable when seen at a “small” scale on the VSCode marketplace.

---

<div class="post-metadata">

**Author:** ![mpilgrem](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mpilgrem/32/2529_2.png) [@mpilgrem](https://discourse.haskell.org/u/mpilgrem)\
**Post date:** [May 28, 2026, 6:09pm UTC](https://discourse.haskell.org/t/newcomer-help-wanted-in-the-haskell-debugger/14164/2 "2026-05-28T18:09:07Z")

</div>

I’ll have a stab at the Stack installation angle.

EDIT1: I tried (on Windows):

```plaintext
> stack unpack haskell-debugger
> cd haskell-debugger-0.13.1.0
> # Create a stack.yaml file with a suitable snapshot (see below)
> stack build

```

with `stack.yaml`:

```plaintext
snapshot: nightly-2026-05-27 # GHC 9.12.4
compiler: ghc-9.14.1 # GHC 9.14.1 or later is needed

extra-deps:
- dap-0.5.0.0@sha256:09f487806436461b0af84c15d82e4b74d361a4238480d8e80e8ade358a50f08e,2324
- ghc-stack-annotations-0.1.0.0@sha256:56bdded7dc6a72ea338b96fdb9da1806c583bfdf3286aa9d092bf072d36bac21,1643
- haskell-debugger-view-0.2.1.0@sha256:a6cad0c90bcc03be18b5435fc9222a9c97b3dc53b2b1c66c068ee5bfaa9af57e,1973

```

GHC 9.14.1 could not compile module `GHC.Debugger.Monad`, failing with:

```plaintext
haskell-debugger\GHC\Debugger\Monad.hs:629:13: error: [GHC-83865]
    • Couldn't match expected type: IO ProcessHandle
                  with actual type: Win32-2.14.2.1:System.Win32.DebugApi.Internal.PHANDLE
                                    -> IO ProcessHandle
    • Probable cause: ‘mkProcessHandle’ is applied to too few arguments
      In a stmt of a 'do' block:
        ph <- mkProcessHandle (fromIntegral pid) False
      In the expression:
        do bi_h <- socketToHandle sock ReadWriteMode
           pidLine <- annotateCallStackIO $ hGetLine bi_h
           pid <- case readMaybe pidLine :: Maybe Int of
                    Just pid -> pure pid
                    Nothing
                      -> fail
                           $ "invalid external interpreter PID on socket: " ++ show pidLine
           ph <- mkProcessHandle (fromIntegral pid) False
           ....
      In the third argument of ‘Control.Exception.bracketOnError’, namely
        ‘(\ (sock, _)
            -> do bi_h <- socketToHandle sock ReadWriteMode
                  pidLine <- annotateCallStackIO $ hGetLine bi_h
                  pid <- case readMaybe pidLine :: Maybe Int of
                           Just pid -> pure pid
                           Nothing
                             -> fail
                                  $ "invalid external interpreter PID on socket: " ++ show pidLine
                  ....)’
    |
629 | ph <- mkProcessHandle (fromIntegral pid) False
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

```

That does not appear to be a Stack-related problem.

EDIT2: I then looked at the GitHub repository, and tried:

```plaintext
> git clone https://github.com/well-typed/haskell-debugger.git
> cd haskell-debugger
> # Edit the custom snapshot.yaml (see below)
> stack -w stack-windows.yaml build

```

using `snapshot.yaml`:

```plaintext
# A bespoke snapshot for GHC 9.14.1. There is no Stackage snapshot for
# GHC 9.14.1.
#
# The relevant package versions in this snapshot are known, by testing, to work
# together, not withstanding the upper bounds on dependencies specified in their
# Cabal files.
snapshot: nightly-2026-05-27 # GHC 9.12.4.
compiler: ghc-9.14.1

packages:
- dap-0.7.0.0@sha256:4eb00ced16dfec6ed1ef4705db8c57a32b657978bcd773c06a027fcf15e4a8f6,2324
- ghc-stack-annotations-0.1.0.0@sha256:56bdded7dc6a72ea338b96fdb9da1806c583bfdf3286aa9d092bf072d36bac21,1643

```

That failed during the build with:

```plaintext
haskell-debugger > configure (lib + sub-lib + exe)
haskell-debugger > Configuring haskell-debugger-0.13.1.0...
haskell-debugger > Error: [Cabal-8010]
haskell-debugger > Encountered missing or private dependencies:
haskell-debugger > dap >=0.7 && <0.8 (missing)
haskell-debugger >

```

which I do not understand because:

```plaintext
> stack -w stack-windows.yaml exec -- ghc-pkg list dap
D:\sr\programs\x86_64-windows\ghc-9.14.1\lib\package.conf.d
    (no packages)
D:\sr\snapshots\0f13af98\pkgdb
    dap-0.7.0.0

D:\Users\mike\Code\Haskell\haskell-debugger\.stack-work\install\0f13af98\pkgdb
    (no packages)

```

shows that dap-0.7.0.0 is an installed package and (extract)

```plaintext
stack -w stack-windows.yaml ls dependencies
Cabal 3.16.0.0
...
cryptohash-sha1 0.11.101.0
data-fix 0.3.4
...
zlib-clib 1.3.1

```

appears to imply that `dap` is, in fact, not a direct or indirect dependency. So, I am puzzled …

EDIT3: … but now, looking at `haskell-debugger.cabal`, `dap` is also a named private sub-library (an internal library). ~~However, it is not referenced as [`haskell-debugger:dap`](https://cabal.readthedocs.io/en/stable/cabal-package-description-file.html#pkg-field-build-depends) in the Cabal file, as I would expect.~~ Perhaps that is the source of the problem …

EDIT4: If I rename the internal library in the Cabal file to be distinct from the name of a dependency package (`dap` → `hdb-dap`), Stack no longer falls over. (I don’t know if that reflects a Stack problem or a problem with the `Cabal` library that ships with GHC 9.14.1.) However, GHC 9.14.1 still cannot compile module `GHC.Debugger.Monad` - for what appears to be the same reason as above.

EDIT5: I am now fairly confident that the internal library problem is a bug in Stack 3.9.3 and earlier itself. I’m looking into that.

EDIT6: The internal library bug revealed by this experience is now fixed in the `master` branch version of Stack and Stack 3.11.1 (release candidate).