GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-12T15:10:14Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24506RTS crash with 9.8.12024-03-12T15:10:14ZSophie TaylorRTS crash with 9.8.1## Summary
I'm working on implementing a production system via a rete network, using STM. When I add certain productions, I get an exception thrown due to a `lens` `Fold` folding an empty list. When trying to debug this in GHCi I added ...## Summary
I'm working on implementing a production system via a rete network, using STM. When I add certain productions, I get an exception thrown due to a `lens` `Fold` folding an empty list. When trying to debug this in GHCi I added a breakpoint to the function where the empty Fold occurs, and before the Fold even happens, about two seconds after hitting the breakpoint, GHCi crashes with the following:
```haskell
ghci> :break Rete.ReteEffect.matchFromToken
Breakpoint 0 activated at src/Rete/ReteEffect.hs:(437,34)-(470,85)
ghci> import ForTesting
ghci> testCommand "add rules {\"rule\" (state <snake> * *) (<n1> <n2> <n3>) (<c> <g> <b>) --> (<n1> <n2> <n3>) (<c> <g> <b>)}"
Stopped in Rete.ReteEffect.matchFromToken, src/Rete/ReteEffect.hs:(437,34)-(470,85)
_result :: Sem r Core.WME.RuleMatch = _
tok :: Core.WME.WMEToken ? Core.WME.IsProductionToken = _
token :: Rete.Types.Tokens.WMEToken' Core.WME.WMEMetadata = _
[src/Rete/ReteEffect.hs:(437,34)-(470,85)] ghci> <interactive>: internal error: evacuate: strange closure type 636340344
Stack trace:
0x7fffef73027f set_initial_registers (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffee1de088 dwfl_thread_getframes (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffee1ddbdb get_one_thread_cb (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffee1ddeea dwfl_getthreads (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffee1de417 dwfl_getthread_frames (/nix/store/8hy9xdnczdpn846qpsybwlpk5l607lbj-elfutils-0.189/lib/libdw-0.189.so)
0x7fffef730887 libdwGetBacktrace (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73902d rtsFatalInternalErrorFn (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef739200 barf (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef716171 evacuate1 (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef71beac scavenge_block1 (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef7658b7 scavenge_loop1 (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef75a702 scavenge_until_all_done (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef75c193 GarbageCollect (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73d320 scheduleDoGC (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73e339 schedule (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef73ebdc scheduleWorker (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffef7431dd workerStart (/nix/store/20m2ha1x3rq3aiwg87asapqxv2hzgzw1-ghc-9.8.1/lib/ghc-9.8.1/lib/x86_64-linux-ghc-9.8.1/libHSrts-1.0.2_thr-ghc9.8.1.so)
0x7fffee29fdd4 start_thread (/nix/store/aw2fw9ag10wr9pf0qk4nk5sxi0q0bn56-glibc-2.37-8/lib/libc.so.6)
0x7fffee3219b0 __clone3 (/nix/store/aw2fw9ag10wr9pf0qk4nk5sxi0q0bn56-glibc-2.37-8/lib/libc.so.6)
(GHC version 9.8.1 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Error: cabal: repl failed for cosmothought-core-0.1.0.0. The build process
terminated with exit code -6
```
## Steps to reproduce
Most convenient as a Nix flake:
1. grab from https://gitlab.com/spacekitteh/cosmothought/-/tree/repro-24506?ref_type=heads, ensure the current branch is `repro-24506`
2. `nix develop`
3. `cabal repl core`
5. `ghci> import ForTesting`
6. Optionally, `ghci> :break Rete.ReteEffect.producePatternMap` for a stack trace of the segfault. Sometimes, it doesn't produce a stacktrace, but it often does.
7. `ghci> repro24506`
8. Sometimes, a single invocation of `repro24506` doesn't result in the segfault; just run `repro24506` again until it does.
~~Alternatively, it can be reproduced in `gdb` using `cosmothought-core-oneoff`; but this requires setting a breakpoint. If you run `gdb --args cosmothought-core-oneoff +RTS -DS`, and set a breakpoint on `cosmothoughtzmcorezm0zi1zi0zi0zminplace_ReteziReteBuilder_createOrShareAlphaNodes_info`, it will barf during Sanity checking.~~ Ok that's due to setting the breakpoint incorrectly, see https://gitlab.haskell.org/ghc/ghc/-/issues/24506#note_552349
The exact value for the strange closure type changes from run to run. Sometimes, it just segfaults instead of printing the backtrace.
The problem is almost certainly in the `core/src/Rete` modules, in particular, how I'm using `stm-hamt's`.
I'm trying to narrow it down in order to find a minimal test case, but it's difficult.
## Expected behavior
Not crash.
## Things tried
- `+RTS --nonmoving-gc` and `--copying-gc` both segfault
- `-O0 -fno-static-argument-transformation` still segfaults
- `+RTS -C0 -V0` with non-threaded runtime still segfaults
- Linked with `-debug`
- `+RTS -DS` doesn't produce anything immediately obvious to me
## Possibly related
~~#24443 ~~ Nope, just a coincidence, but a strange one
## Environment
* GHC version used: 9.8.1
* Operating System: NixOS
* System Architecture: x64https://gitlab.haskell.org/ghc/ghc/-/issues/19857GHC 8.6.1 lost fix for #60982023-11-02T14:37:27ZRoland SennGHC 8.6.1 lost fix for #6098## Summary
Issue #6098 got fixed in GHC 7.8.1. The bug re-appeared in GHC versions >= 8.6.1
## Steps to reproduce
See ticket #6098
## Expected behavior
The output of `head allItems` should be `1` and not an error message.
## Envir...## Summary
Issue #6098 got fixed in GHC 7.8.1. The bug re-appeared in GHC versions >= 8.6.1
## Steps to reproduce
See ticket #6098
## Expected behavior
The output of `head allItems` should be `1` and not an error message.
## Environment
* GHC version used: >= 8.6.1
* Operating System: Debian 10
## Comment
Unfortunately there is no test case and no reference to the patch that was
used to fix #6098.https://gitlab.haskell.org/ghc/ghc/-/issues/19559The GHCi debugger loses type constraints2022-01-20T10:27:34ZRoland SennThe GHCi debugger loses type constraints## Summary
The GHCi debugger loses the type constraints of the breakpoint variables..
## Steps to reproduce
`Foo.hs` is a simplified version of testcase `break012`:
````
foo :: (Num a1, Num a2) => a2 -> (a2, a1 -> a1 -> a1)
foo i = l...## Summary
The GHCi debugger loses the type constraints of the breakpoint variables..
## Steps to reproduce
`Foo.hs` is a simplified version of testcase `break012`:
````
foo :: (Num a1, Num a2) => a2 -> (a2, a1 -> a1 -> a1)
foo i = let incr = i + 1
add = (+)
in (incr,add)
````
Observe the following GHCi session:
````
$ ghci Foo.hs
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Foo.hs, interpreted )
Ok, one module loaded.
ghci> :st foo 5 `seq` ()
Stopped in Main.foo, Foo.hs:4:12-21
_result :: (a2, a1 -> a1 -> a1) = _
add :: a1 -> a1 -> a1 = _
incr :: a2 = _
[Foo.hs:4:12-21] ghci> add 40 2
<interactive>:2:5: error:
• No instance for (Num a1) arising from the literal ‘40’
Cannot resolve unknown runtime type ‘a1’
Use :print or :force to determine these types
Relevant bindings include it :: a1 (bound at <interactive>:2:1)
These potential instances exist:
instance Num Integer -- Defined in ‘GHC.Num’
instance Num Double -- Defined in ‘GHC.Float’
instance Num Float -- Defined in ‘GHC.Float’
...plus two others
...plus one instance involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the first argument of ‘add’, namely ‘40’
In the expression: add 40 2
In an equation for ‘it’: it = add 40 2
[Foo.hs:4:12-21] ghci>
````
The types of all breakpoint variables lack `Num` contraints!
## Expected behavior
The types of the 2 breakpoint variables (`_result`, `add`) should have a `Num` constraint for `a1`.
The type of `incr` should be `Integer`. The correct types are:
````
_result :: Num a1 => Integer -> (Integer, a1 -> a1 -> a1) = _
add :: Num a1 => a1 -> a1 -> a1 = _
incr :: Integer = _
````
The result of `add 40 2` should be `42` and not an error message.
## Environment
* GHC versions used: 7.10.3, 8.10.2, 9.0.1, HEAD
(in 7.10.3 only the `_result` breakpoint variable is shown)
* Operating System: Linux Debian 10
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/18558GHCi Debugger hangs in nested break in an eta reduced function2020-08-10T14:47:35ZRoland SennGHCi Debugger hangs in nested break in an eta reduced function## Summary
GHCi hangs when setting a breakpoint in an eta reduced function and re-evaluating this function when the breakpoint is hit.
## Steps to reproduce
Use the module `Hang.hs`:
````
module Hang where
foo :: Int -> Int
foo = ba...## Summary
GHCi hangs when setting a breakpoint in an eta reduced function and re-evaluating this function when the breakpoint is hit.
## Steps to reproduce
Use the module `Hang.hs`:
````
module Hang where
foo :: Int -> Int
foo = bar
bar :: Int -> Int
bar n = 2 * n
````
Do the following steps:
````
ghci Hang.hs
:break foo
foo 1 -- Evaluate function foo. GHCi stops at breakpoint
foo 2 -- Re-evaluate function foo from the breakpoint
````
-> GHCi now hangs!
## Expected behavior
GHCi should not hang, it should stop at a nested breakpoint
## Note
When I remove the eta reduction in the function `foo`
````
foo :: Int -> Int
foo x = bar x
````
then everything works fine!
## Environment
* GHC version used: 7.10.3 - 8.10.2 and HEAD
Optional:
* Operating System: Debian 9
* System Architecture: x86-64https://gitlab.haskell.org/ghc/ghc/-/issues/17833break006 fails in validate build2022-02-23T14:10:22ZÖmer Sinan Ağacanbreak006 fails in validate buildThis breakage is introduced with !1869 (not yet merged), but I think !1869 does not the root cause of the failure, instead the changes in Core after !1869 reveals one of the many bugs in RtClosureInspect (which is known to be very buggy)...This breakage is introduced with !1869 (not yet merged), but I think !1869 does not the root cause of the failure, instead the changes in Core after !1869 reveals one of the many bugs in RtClosureInspect (which is known to be very buggy).
<details>
<summary>Panic (with call stack)</summary>
```
<interactive>: panic! (the 'impossible' happened)
(GHC version 8.11.0.20200212:
ASSERT failed!
in_scope InScope {wild_00}
tenv [alJ :-> 'LiftedRep, alK :-> 'LiftedRep, alL :-> a_I17l[rt],
alM :-> ()]
tenvFVs {a_I17l[rt]}
cenv []
cenvFVs {}
tys [q_alJ]
cos []
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1187:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1257:5 in ghc:Outputable
assertPprPanic, called at compiler/types/TyCoSubst.hs:629:56 in ghc:TyCoSubst
checkValidSubst, called at compiler/types/TyCoSubst.hs:661:29 in ghc:TyCoSubst
substTy, called at compiler/simplCore/SimplEnv.hs:904:18 in ghc:SimplEnv
substTy, called at compiler/simplCore/Simplify.hs:1045:14 in ghc:Simplify
simplType, called at compiler/simplCore/Simplify.hs:911:31 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:951:5 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:1372:5 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:1468:10 in ghc:Simplify
simplNonRecE, called at compiler/simplCore/Simplify.hs:1389:11 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:1376:10 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:1376:10 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:1376:10 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:1376:10 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:928:5 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:1782:10 in ghc:Simplify
completeCall, called at compiler/simplCore/Simplify.hs:1759:22 in ghc:Simplify
simplIdF, called at compiler/simplCore/Simplify.hs:900:61 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:918:23 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:918:23 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:918:23 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:918:23 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:922:18 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:868:30 in ghc:Simplify
simplExprC, called at compiler/simplCore/Simplify.hs:1893:19 in ghc:Simplify
rebuildCall, called at compiler/simplCore/Simplify.hs:1871:5 in ghc:Simplify
rebuildCall, called at compiler/simplCore/Simplify.hs:1789:10 in ghc:Simplify
completeCall, called at compiler/simplCore/Simplify.hs:1759:22 in ghc:Simplify
simplIdF, called at compiler/simplCore/Simplify.hs:900:61 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:918:23 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:922:18 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:922:18 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:868:30 in ghc:Simplify
simplExprC, called at compiler/simplCore/Simplify.hs:1893:19 in ghc:Simplify
rebuildCall, called at compiler/simplCore/Simplify.hs:1871:5 in ghc:Simplify
rebuildCall, called at compiler/simplCore/Simplify.hs:1789:10 in ghc:Simplify
completeCall, called at compiler/simplCore/Simplify.hs:1759:22 in ghc:Simplify
simplIdF, called at compiler/simplCore/Simplify.hs:900:61 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:918:23 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:922:18 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:1372:5 in ghc:Simplify
simplLam, called at compiler/simplCore/Simplify.hs:1468:10 in ghc:Simplify
simplNonRecE, called at compiler/simplCore/Simplify.hs:973:31 in ghc:Simplify
simplExprF1, called at compiler/simplCore/Simplify.hs:889:5 in ghc:Simplify
simplExprF, called at compiler/simplCore/Simplify.hs:868:30 in ghc:Simplify
simplExprC, called at compiler/simplCore/Simplify.hs:854:5 in ghc:Simplify
simplExpr, called at compiler/simplCore/SimplCore.hs:610:14 in ghc:SimplCore
simplExprGently, called at compiler/simplCore/SimplCore.hs:577:30 in ghc:SimplCore
simplifyExpr, called at compiler/main/HscMain.hs:1898:26 in ghc:HscMain
hscCompileCoreExpr', called at compiler/main/HscMain.hs:1891:37 in ghc:HscMain
hscCompileCoreExpr, called at compiler/main/HscMain.hs:1670:20 in ghc:HscMain
hscParsedStmt, called at compiler/GHC/Runtime/Eval.hs:216:19 in ghc:GHC.Runtime.Eval
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
</details>
(GHC.Runtime.Eval is the new name of RtClosureInspect after the module renaming
work)
In !1869 we'll be marking this test as broken, referencing this issue.https://gitlab.haskell.org/ghc/ghc/-/issues/16840"panic! (the 'impossible' happened)" attempting to print the contents of a mu...2021-06-29T14:01:50ZAnthony Berent"panic! (the 'impossible' happened)" attempting to print the contents of a mutable vector in GHCi# Summary
I got an panic when trying to print the contents of a mutable vector while debugging using "toList $ freeze t" in GHCi (t is my vector).
The full message is:
```
[/home/anthony/haskell/SubStringSearching/app/Main.hs:32:7-17]...# Summary
I got an panic when trying to print the contents of a mutable vector while debugging using "toList $ freeze t" in GHCi (t is my vector).
The full message is:
```
[/home/anthony/haskell/SubStringSearching/app/Main.hs:32:7-17] >toList $ freeze t
<interactive>:39:17: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
No skolem info:
[s_I8aZ[rt]]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcErrors.hs:2891:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[/home/anthony/haskell/SubStringSearching/app/Main.hs:32:7-17] >
```
# Steps to reproduce
* In GHCi set a breakpoint on line 37 of the attached source code [Main.hs](/uploads/e5a86827ffee9892909bbbd1a5df58c1/Main.hs)
* Step through the code until it reaches Main.hs:32:7-17
* Run the command: *toList $ freeze t*
# Expected behavior
Not a panic, probably print the contents of t.
# Environment
* GHC version used: 8.6.5 for x86_64-unknown-linux
Optional:
* Operating System: Ubuntu 19.04
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/14628Panic (No skolem Info) in GHCi2023-11-02T14:36:37ZAndreas KlebingerPanic (No skolem Info) in GHCiLoading the following code in GHCi causes a panic.
Versions affected at least 8.2.2 and 8.0.2
```
module Main where
import System.IO
import Control.Monad.IO.Class
import Control.Monad.Trans.State
import Text.Printf
putArrayBytes :: H...Loading the following code in GHCi causes a panic.
Versions affected at least 8.2.2 and 8.0.2
```
module Main where
import System.IO
import Control.Monad.IO.Class
import Control.Monad.Trans.State
import Text.Printf
putArrayBytes :: Handle -- ^ output file handle
-> [String] -- ^ byte-strings
-> IO Int -- ^ total number of bytes written
putArrayBytes outfile xs = do
let writeCount x = modify' (+ length x) >> liftIO (putLine x) :: MonadIO m => StateT Int m ()
execStateT (mapM_ writeCount xs) 0
where putLine = hPutStrLn outfile . (" "++) . concatMap (printf "0x%02X,")
{-
ghci:
:break 12 46
:trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
snd $ runStateT _result 0
-}
main = undefined
```
```
Configuring GHCi with the following packages:
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( C:\test\test.hs, interpreted )
Ok, one module loaded.
Loaded GHCi configuration from C:\Users\Andi\AppData\Local\Temp\ghci34988\ghci-script
*Main> :break 12 46
Breakpoint 0 activated at C:\test\test.hs:12:46-63
*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, C:\test\test.hs:12:46-63
_result :: StateT Int m () = _
putLine :: [Char] -> IO () = _
x :: [Char] = "123456789"
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main> snd $ runStateT _result 0
<interactive>:3:7: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
No skolem info:
m_I5Cm[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler\typecheck\TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main> :r
[1 of 1] Compiling Main ( C:\test\test.hs, interpreted )
Ok, one module loaded.
*Main> :break 12 46
Breakpoint 1 activated at C:\test\test.hs:12:46-63
*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, C:\test\test.hs:12:46-63
_result :: StateT Int m () = _
putLine :: [Char] -> IO () = _
x :: [Char] = "123456789"
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main> snd $ runStateT _result 0
<interactive>:7:7: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
No skolem info:
m_I5Nz[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler\typecheck\TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main>
```
Maybe related to #13393.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic (No skolem Info) in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Loading the following code in GHCi causes a panic.\r\n\r\nVersions affected at least 8.2.2 and 8.0.2\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport System.IO\r\nimport Control.Monad.IO.Class\r\nimport Control.Monad.Trans.State\r\nimport Text.Printf\r\n\r\nputArrayBytes :: Handle -- ^ output file handle\r\n -> [String] -- ^ byte-strings\r\n -> IO Int -- ^ total number of bytes written\r\nputArrayBytes outfile xs = do\r\n let writeCount x = modify' (+ length x) >> liftIO (putLine x) :: MonadIO m => StateT Int m ()\r\n execStateT (mapM_ writeCount xs) 0\r\n where putLine = hPutStrLn outfile . (\" \"++) . concatMap (printf \"0x%02X,\")\r\n\r\n{-\r\nghci:\r\n:break 12 46\r\n:trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]\r\nsnd $ runStateT _result 0\r\n-}\r\n\r\nmain = undefined\r\n}}}\r\n\r\n\r\n\r\n{{{\r\nConfiguring GHCi with the following packages:\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( C:\\test\\test.hs, interpreted )\r\nOk, one module loaded.\r\nLoaded GHCi configuration from C:\\Users\\Andi\\AppData\\Local\\Temp\\ghci34988\\ghci-script\r\n*Main> :break 12 46\r\nBreakpoint 0 activated at C:\\test\\test.hs:12:46-63\r\n*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]\r\nStopped in Main.putArrayBytes.writeCount, C:\\test\\test.hs:12:46-63\r\n_result :: StateT Int m () = _\r\nputLine :: [Char] -> IO () = _\r\nx :: [Char] = \"123456789\"\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main> snd $ runStateT _result 0\r\n\r\n<interactive>:3:7: error:<interactive>: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-mingw32):\r\n No skolem info:\r\n m_I5Cm[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler\\utils\\Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler\\utils\\Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler\\typecheck\\TcErrors.hs:2653:5 in ghc:TcErrors\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main> :r\r\n[1 of 1] Compiling Main ( C:\\test\\test.hs, interpreted )\r\nOk, one module loaded.\r\n*Main> :break 12 46\r\nBreakpoint 1 activated at C:\\test\\test.hs:12:46-63\r\n*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]\r\nStopped in Main.putArrayBytes.writeCount, C:\\test\\test.hs:12:46-63\r\n_result :: StateT Int m () = _\r\nputLine :: [Char] -> IO () = _\r\nx :: [Char] = \"123456789\"\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main> snd $ runStateT _result 0\r\n\r\n<interactive>:7:7: error:<interactive>: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-mingw32):\r\n No skolem info:\r\n m_I5Nz[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler\\utils\\Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler\\utils\\Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler\\typecheck\\TcErrors.hs:2653:5 in ghc:TcErrors\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main>\r\n}}}\r\n\r\nMaybe related to #13393.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14400Make :sprint, :print, and :force work with cyclical structures2020-01-23T19:27:39ZDavid FeuerMake :sprint, :print, and :force work with cyclical structures```
> t = "hi" : t
> :force t
```
never completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable ...```
> t = "hi" : t
> :force t
```
never completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable representation of the graph.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make :sprint, :print, and :force work with cyclical structures","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{\r\n> t = \"hi\" : t\r\n> :force t\r\n}}}\r\n\r\nnever completes, because GHC races around and around in a loop forever. It would seem better to keep a hashset of nodes that have already been visited to avoid getting stuck, and print out a reasonable representation of the graph.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13201Type-level naturals aren't instantiated with GHCi debugger2020-07-16T13:19:02ZHiromi IshiiType-level naturals aren't instantiated with GHCi debuggerGHCi debugger cannot use the information of specific value type-level natural number, even if it is explicitly specified.
For example, consider the following code:
```hs
{-# LANGUAGE DataKinds, KindSignatures, StandaloneDeriving, TypeO...GHCi debugger cannot use the information of specific value type-level natural number, even if it is explicitly specified.
For example, consider the following code:
```hs
{-# LANGUAGE DataKinds, KindSignatures, StandaloneDeriving, TypeOperators #-}
module Main where
import GHC.TypeLits
data Foo (n :: Nat) = Foo
deriving instance KnownNat n => Show (Foo n)
fooSucc :: Foo n -> Foo (n + 1)
fooSucc Foo = Foo
foos :: Foo n -> [Foo (n + 1)]
foos f = loop 5
where
loop 0 = []
loop n = fooSucc f : loop (n - 1)
main :: IO ()
main = print $ foos (Foo :: Foo 5)
```
Loading it with GHCi Debugger, we cannot `show` the value of `f`, because GHCi debugger doesn't know the specific value of `n` (in`Foo n`), even though we specify it in `main`!
```hs
ghci> :l tmp.hs
[1 of 1] Compiling Main ( tmp.hs, interpreted )
Ok, modules loaded: Main.
ghci> :break foos
Breakpoint 0 activated at tmp.hs:13:10-15
ghci> :set stop :list
ghci> main
Stopped in Main.foos, tmp.hs:13:10-15
_result :: [Foo (n + 1)] = _
loop :: (Num t, Eq t) => t -> [Foo (n + 1)] = _
12 foos :: Foo n -> [Foo (n + 1)]
13 foos f = loop 5
14 where
ghci> :step
Stopped in Main.foos.loop, tmp.hs:16:14-37
_result :: [Foo (n + 1)] = _
f :: Foo n = _
n :: Integer = 5
15 loop 0 = []
16 loop n = fooSucc f : loop (n - 1)
17
ghci> :t f
f :: Foo n
ghci> f
<interactive>:8:1: error:
• No instance for (KnownNat n) arising from a use of ‘print’
• In a stmt of an interactive GHCi command: print it
```
Of course, we can inspect the internal representation via `:print` or `:force` command, but it is rather impractical when we cannot easily read its pretty form from its internal representation .
I tested this with GHC 7.0.1 and 7.0.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type-level naturals aren't instantiate with GHCi debugger","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHCi debugger cannot use the information of specific value type-level natural number, even if it is explicitly specified.\r\n\r\nFor example, consider the following code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds, KindSignatures, StandaloneDeriving, TypeOperators #-}\r\nmodule Main where\r\nimport GHC.TypeLits\r\n\r\ndata Foo (n :: Nat) = Foo\r\nderiving instance KnownNat n => Show (Foo n)\r\n\r\n\r\nfooSucc :: Foo n -> Foo (n + 1)\r\nfooSucc Foo = Foo\r\n\r\nfoos :: Foo n -> [Foo (n + 1)]\r\nfoos f = loop 5\r\n where\r\n loop 0 = []\r\n loop n = fooSucc f : loop (n - 1)\r\n\r\nmain :: IO ()\r\nmain = print $ foos (Foo :: Foo 5)\r\n}}}\r\n\r\nLoading it with GHCi Debugger, we cannot `show` the value of `f`, because GHCi debugger doesn't know the specific value of `n` (in`Foo n`), even though we specify it in `main`!\r\n\r\n{{{#!hs\r\nghci> :l tmp.hs\r\n[1 of 1] Compiling Main ( tmp.hs, interpreted )\r\nOk, modules loaded: Main.\r\n\r\nghci> :break foos\r\nBreakpoint 0 activated at tmp.hs:13:10-15\r\n\r\nghci> :set stop :list\r\nghci> main\r\nStopped in Main.foos, tmp.hs:13:10-15\r\n_result :: [Foo (n + 1)] = _\r\nloop :: (Num t, Eq t) => t -> [Foo (n + 1)] = _\r\n12 foos :: Foo n -> [Foo (n + 1)]\r\n13 foos f = loop 5\r\n14 where\r\n\r\nghci> :step\r\nStopped in Main.foos.loop, tmp.hs:16:14-37\r\n_result :: [Foo (n + 1)] = _\r\nf :: Foo n = _\r\nn :: Integer = 5\r\n15 loop 0 = []\r\n16 loop n = fooSucc f : loop (n - 1)\r\n17 \r\n\r\nghci> :t f\r\nf :: Foo n\r\n\r\nghci> f\r\n\r\n<interactive>:8:1: error:\r\n • No instance for (KnownNat n) arising from a use of ‘print’\r\n • In a stmt of an interactive GHCi command: print it\r\n}}}\r\n\r\nOf course, we can inspect the internal representation via `:print` or `:force` command, but it is rather impractical when we cannot easily read its pretty form from its internal representation .\r\n\r\nI tested this with GHC 7.0.1 and 7.0.2.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12139Add TUI (text-based user interface) for GHCi debugger2019-09-26T10:05:39ZsiddhanathanAdd TUI (text-based user interface) for GHCi debuggerGDB has a really nice TUI mode: https://upload.wikimedia.org/wikipedia/commons/4/47/GDB_TUI.png
It's a curses interface which highlights the line number you're on, and also shows the surrounding lines.
GHCi currently allows stepping th...GDB has a really nice TUI mode: https://upload.wikimedia.org/wikipedia/commons/4/47/GDB_TUI.png
It's a curses interface which highlights the line number you're on, and also shows the surrounding lines.
GHCi currently allows stepping through with the `:step` command, which displays line and column numbers. It would be nice to have some visual indication along with these numbers.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add TUI (text-based user interface) for GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GDB has a really nice TUI mode: https://upload.wikimedia.org/wikipedia/commons/4/47/GDB_TUI.png\r\n\r\nIt's a curses interface which highlights the line number you're on, and also shows the surrounding lines.\r\n\r\nGHCi currently allows stepping through with the `:step` command, which displays line and column numbers. It would be nice to have some visual indication along with these numbers.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10160GHCi :sprint has odd/unhelpful behavior for values defined within the REPL2021-11-15T21:21:26ZbitemyappGHCi :sprint has odd/unhelpful behavior for values defined within the REPLWanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain ...Wanted to use :sprint to help learners visualise thunk evaluation behavior in their data. Ran into some behaviors that a few people I checked with didn't have a good explanation for. I couldn't find anything in the user guide to explain this. I don't think it technically violates Haskell Report requirements, but it makes :sprint considerably less useful if you're teaching somebody non-strictness.
Examples with code in the REPL:
```
Prelude> let x = [1, 2, 3 :: Integer]
Prelude> :sprint x
x = [1,2,3]
-- errr, what?
Prelude> let x = Just (1 :: Integer)
Prelude> :sprint x
x = Just 1
Prelude> let just = Just
Prelude> let x = just (1 :: Integer)
Prelude> :sprint x
x = _
Prelude> let x = Just (undefined :: Integer)
Prelude> :sprint x
x = Just _
Prelude> let x = just (undefined :: Integer)
Prelude> :sprint x
x = _
Prelude> let x = [1, 2, 3 :: Integer]
Prelude> let y = x
Prelude> :sprint y
y = [1,2,3]
Prelude> let x = 1 : 2 : (3 :: Integer) : []
Prelude> :sprint x
x = [1,2,3]
Prelude> let x = [1] ++ [2] ++ [(3 :: Integer)]
Prelude> :sprint x
x = _
Prelude> let y = (:)
Prelude> let x = 1 `y` (2 `y` ((3 :: Integer) `y` []))
Prelude> :sprint x
x = _
Prelude> x
[1,2,3]
Prelude> :sprint x
x = [1,2,3]
```
So the behavior here seems to be:
Constructors used directly in the construction of data and are not passed functions (including polymorphic vals awaiting concrete instances)/bottoms are immediately evaluated
Example, but with loading data from a file:
Contents of the file:
```
x :: Num a => [a]
x = [1, 2, 3]
```
GHCi session:
```
Prelude> :t x
x :: Num a => [a]
Prelude> :sprint x
x = _
Prelude> x
[1,2,3]
Prelude> :sprint x
x = _
-- ^^ this is expected
```
Then when x is loaded from a file, but has a different type:
```
Prelude> :t x
x :: [Integer]
Prelude> :sprint x
x = _
Prelude> head x
1
Prelude> :sprint x
x = [1,2,3]
-- ^^ this is not
```
Now, this is a bit confusing. Earlier I was able to get :sprint to return \[1, _, _\] when I evaluated head x, but a couple hours later when I went to write this ticket, I couldn't reproduce that behavior.
Is there documentation that explains:
1. Why data is shown as having been evaluated at time of declaration (seemingly) by :sprint when it's defined in the GHCi
1. Why declaring code in GHCi and loading it from a file behaves differently with :sprint (I considered let expression in the implicit GHCi do-block...couldn't find anything to explain this)
1. Why evaluating 'head x' forces the other values as well
Are any of these behaviors a bug? If not, are they documented anywhere? Is the "eager" treatment of constructors in GHCi a performance thing? That seems strange given I didn't have -fobject-code turned on.
:sprint not demonstrating semantics that match what I expect from a non-strict language hinders its utility as a teaching tool and means the only robust option for learners that I can find is testing evaluation with bottom values.
```
-- So that you know i picked "7.8.4" as the version consciously
[callen@atlantis ~/Work/fpbook]$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
[callen@atlantis ~/Work/fpbook]$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.8.4
```https://gitlab.haskell.org/ghc/ghc/-/issues/9643ghci must be restarted to use break point more than once?2019-07-07T18:39:41Zdsamperighci must be restarted to use break point more than once?When I set a break point (in main say) I stop there when I run
the function, but if I run the function again the break point is
ignored. Restarting ghci and resetting the break point makes it
effective again, but this seems strange. Is t...When I set a break point (in main say) I stop there when I run
the function, but if I run the function again the break point is
ignored. Restarting ghci and resetting the break point makes it
effective again, but this seems strange. Is this a bug or a feature?
Also, when I run :trace after stopping at a break point, the remainder of the function is run, and :back complains that I cannot go backwards because I am not at a break point.
Thanks,
Dominick
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci must be restarted to use break point more than once?","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"When I set a break point (in main say) I stop there when I run\r\nthe function, but if I run the function again the break point is\r\nignored. Restarting ghci and resetting the break point makes it\r\neffective again, but this seems strange. Is this a bug or a feature?\r\n\r\nAlso, when I run :trace after stopping at a break point, the remainder of the function is run, and :back complains that I cannot go backwards because I am not at a break point.\r\n\r\nThanks,\r\nDominick","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8925:print and :sprint sometimes fully evaluates strings2019-07-07T18:42:47Zsoapie:print and :sprint sometimes fully evaluates stringsNot too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string:
```
Prelude> let a = map (Debug.Trace.trace "!!!") "abc"
Prelude> a `seq` ()
()
Prelude> :sprint...Not too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string:
```
Prelude> let a = map (Debug.Trace.trace "!!!") "abc"
Prelude> a `seq` ()
()
Prelude> :sprint a
a = _ : _ -- looks fine
Prelude> length a
3
Prelude> :sprint a
a = "!!! -- strange!
a!!!
b!!!
c"
```
What I expect to see is `a = [_,_,_]`. `:print` behaves similarly. Since neither `:print` nor `:sprint` is supposed to force any evaluation this seems like a bug. At least it can make debugging quite confusing if you're not aware of it!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":print and :sprint sometimes fully evaluates strings","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"Not too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string: \r\n\r\n{{{\r\nPrelude> let a = map (Debug.Trace.trace \"!!!\") \"abc\"\r\nPrelude> a `seq` ()\r\n()\r\nPrelude> :sprint a\r\na = _ : _ -- looks fine\r\nPrelude> length a\r\n3\r\nPrelude> :sprint a\r\na = \"!!! -- strange!\r\na!!!\r\nb!!!\r\nc\"\r\n}}}\r\n\r\nWhat I expect to see is `a = [_,_,_]`. `:print` behaves similarly. Since neither `:print` nor `:sprint` is supposed to force any evaluation this seems like a bug. At least it can make debugging quite confusing if you're not aware of it!","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3786showing function arguments when stopped at its definition2020-08-30T11:36:32Zphercekshowing function arguments when stopped at its definitionIt would be cool if GHCi debugger could grab not only the free variables in the selected expression but, in one case, a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case, the...It would be cool if GHCi debugger could grab not only the free variables in the selected expression but, in one case, a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case, the debugger should provide the bindings for the function arguments. If a function uses pattern matching or when there are multiple equations with different formal argument names then there may not be any suitable name for the for the actual argument value. Because of this, we introduce the function argument names like: _arg1, _arg2, ... _argN. Numbering starts from 1 for the first formal argument of a function.\[\[BR\]\]
The special _argN names should be provided always, even when there is a unique name for the argument in the source code.
This request was discussed here:
http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17204
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"showing function argumetns when stopped at its definition","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be cool if GHCi debugger could grab not only the free variables in the selected expression but, in one case, a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case, the debugger should provide the bindings for the function arguments. If a function uses pattern matching or when there are multiple equations with different formal argument names then there may not be any suitable name for the for the actual argument value. Because of this, we introduce the function argument names like: _arg1, _arg2, ... _argN. Numbering starts from 1 for the first formal argument of a function.[[BR]]\r\nThe special _argN names should be provided always, even when there is a unique name for the argument in the source code.\r\n\r\nThis request was discussed here:\r\nhttp://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17204","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2946tracing should be controled by a global flag2020-08-30T11:36:59Zphercektracing should be controled by a global flagInstead of ":trace" and ":trace \<expr\>" command there should be one command ":set trace on/off" and a new command ":debug \<expr\>".
":set trace" would control a global flag indicating whether tracing should be active or not. If traci...Instead of ":trace" and ":trace \<expr\>" command there should be one command ":set trace on/off" and a new command ":debug \<expr\>".
":set trace" would control a global flag indicating whether tracing should be active or not. If tracing is active then:\[\[BR\]\]
- ":continue" would behave like current ":trace",\[\[BR\]\]
- forcing a value using ":force \<expr\>" woudl work like current ":trace \<expr\>" but ignoring breakpoitns,\[\[BR\]\]
- ":debug \<expr\>" would work like current ":trace \<expr\>",\[\[BR\]\]
- and ":main ..." would start Main.main with tracing on from the very beginning.\[\[BR\]\]
If tracing is not active then ":continue", ":force", ":main" would behave like they do now and ":debug \<expr\>" would be the same as current "\<expr\>".
Reasoning:
I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an \<expr\> is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if \<expr\> is typed on the ghci command line directly then tracing is never extended.
This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use ":continue" or ":trace" based on a global flag). This would also allow to start tracing from the very beggining of ":main" instead of setting a break at Main.main with a script set to ":trace" and then running ":main ...".
Related discussion is here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html
I do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tracing should be controled by a global flag (it should not be resume context specific)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Instead of \":trace\" and \":trace <expr>\" command there should be one command \":set trace on/off\" and a new command \":debug <expr>\".\r\n\r\n\":set trace\" would control a global flag indicating whether tracing should be active or not. If tracing is active then:[[BR]]\r\n * \":continue\" would behave like current \":trace\",[[BR]]\r\n * forcing a value using \":force <expr>\" woudl work like current \":trace <expr>\" but ignoring breakpoitns,[[BR]]\r\n * \":debug <expr>\" would work like current \":trace <expr>\",[[BR]]\r\n * and \":main ...\" would start Main.main with tracing on from the very beginning.[[BR]]\r\nIf tracing is not active then \":continue\", \":force\", \":main\" would behave like they do now and \":debug <expr>\" would be the same as current \"<expr>\".\r\n\r\nReasoning:\r\n\r\n I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an <expr> is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if <expr> is typed on the ghci command line directly then tracing is never extended.\r\n\r\n This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use \":continue\" or \":trace\" based on a global flag). This would also allow to start tracing from the very beggining of \":main\" instead of setting a break at Main.main with a script set to \":trace\" and then running \":main ...\".\r\n\r\nRelated discussion is here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html\r\n\r\nI do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2945add command :mergetrace2020-08-30T11:37:23Zphercekadd command :mergetraceCurrently trace history is stored in "Resume" context. I'm not aware of any good reason for this but it results in problems during debugging. The point is that one cannot extend currently active trace history using ":trace \<varId\>" whi...Currently trace history is stored in "Resume" context. I'm not aware of any good reason for this but it results in problems during debugging. The point is that one cannot extend currently active trace history using ":trace \<varId\>" while stopped at breakpoint. The nested trace history is extended instead. But the nested history is freed when the ":trace \<varId\>" command finishes so there is no access to the trace data. This makes it hard to investigate why the output of the trace command looks the way it was printed: it is not possible to investigate values of variables which contributed to the \<varId\> value.
A discussion about the reasons for global trace history is here:
http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"trace history should not be context/resume specific but global","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently trace history is stored in \"Resume\" context. I'm not aware of any good reason for this but it results in problems during debugging. The point is that one cannot extend currently active trace history using \":trace <varId>\" while stopped at breakpoint. The nested trace history is extended instead. But the nested history is freed when the \":trace <varId>\" command finishes so there is no access to the trace data. This makes it hard to investigate why the output of the trace command looks the way it was printed: it is not possible to investigate values of variables which contributed to the <varId> value.\r\n\r\nA discussion about the reasons for global trace history is here:\r\n http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2803bring full top level of a module in scope when a breakpoint is hit in the module2023-11-02T14:31:34Zphercekbring full top level of a module in scope when a breakpoint is hit in the moduleIt should do something like `:module + *ModuleWhereBreakpointWasHit` and remove the added top level symbols of `ModuleWhereBreakpointWasHit` when we leave it.
The goal is so that the functions which are in scope when we hit a breakpoint ...It should do something like `:module + *ModuleWhereBreakpointWasHit` and remove the added top level symbols of `ModuleWhereBreakpointWasHit` when we leave it.
The goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression.
This feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740\##2803
1. .. and a realated thing: When I do something like `:module + ModName` and later I do `:module + *ModName` then the non-exported symbols from `ModName` are not added into the scope.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mnislaih@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bring full top level of a module in scope when a breakpoint is hit in the module","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":["mnislaih@gmail.com"],"type":"FeatureRequest","description":"It should do something like {{{:module + *ModuleWhereBreakpointWasHit}}} and remove the added top level symbols of {{{ModuleWhereBreakpointWasHit}}} when we leave it.\r\nThe goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression.\r\nThis feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740#comment:4\r\n\r\n... and a realated thing: When I do something like {{{:module + ModName}}} and later I do {{{:module + *ModName}}} then the non-exported symbols from {{{ModName}}} are not added into the scope.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/2737add :tracelocal to ghci debugger to trace only the expressions in a given fun...2020-08-30T11:38:00Zphercekadd :tracelocal to ghci debugger to trace only the expressions in a given functionAs there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the sear...As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough).
:tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint).
Note that the results from the trace history may not be from the expected scope but the same problem is with "printf debugging" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope.
This should be a cheap way to make ghci debugger better than just plain "printf debugging", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead.
Here is the url of the thread head where this proposal started to evolve:
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015840.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"add :tracelocal to ghci debugger to trace only the expressions in a given function","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":["debugger"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough).\r\n\r\n:tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint).\r\n\r\nNote that the results from the trace history may not be from the expected scope but the same problem is with \"printf debugging\" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope. \r\n\r\nThis should be a cheap way to make ghci debugger better than just plain \"printf debugging\", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead.\r\n\r\nHere is the url of the thread head where this proposal started to evolve:\r\nhttp://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015840.html","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1532Implicit parameters are not available in breakpoints2021-06-28T19:14:45ZmnislaihImplicit parameters are not available in breakpointsWe may want to leave this for after 6.8
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type ...We may want to leave this for after 6.8
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Implicit parameters are not available in breakpoints","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"We may want to leave this for after 6.8","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1530debugging :steps inside TH spliced code need to be bypassed2021-06-28T19:23:42Zmnislaihdebugging :steps inside TH spliced code need to be bypassedSee test dynbrk005 for an example
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.6.1 |
| Type ...See test dynbrk005 for an example
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mnislaih@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"debugging :steps inside TH spliced code need to be bypassed","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmarhaskell@gmail.com"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["mnislaih@gmail.com"],"type":"Bug","description":"See test dynbrk005 for an example","type_of_failure":"OtherFailure","blocking":[]} -->