Hi, I'm aware of the debug adapter protocol <https://microsoft.github.io/debug-adapter-protocol/> but I have not used it yet. The external stg interpreter debugger has a terminal based UI currently, because I was focusing on the debug and profile features so far and not on UI. My debugger is programmable though, you can write a debug script to automate the breakpoint setup along with other debug commands. see: https://youtu.be/wt6iCgYmVGA?t=2809
Cheers, Csaba On Thu, Dec 2, 2021 at 4:08 PM YueCompl <compl....@icloud.com> wrote: > This sounds pretty exciting! > > Can we expect a full fledged stepping debugger integrated with IDEs via > https://github.com/phoityne/haskell-debug-adapter ? > https://github.com/phoityne/ghci-dap is still quite limited feature-wise. > > On 2021-12-02, at 22:52, Csaba Hruska <csaba.hru...@gmail.com> wrote: > > Hello, > > Today I'll do a presentation about the external stg interpreter. > If you are interested please join and ask questions. > https://skillsmatter.com/meetups/13654-haskell-stg-interp > > Regards, > Csaba Hruska > > Abstract: > Haskell: Why and How the External STG Interpreter is Useful > > The external STG interpreter is a from scratch implementation of the STG > machine in Haskell. Currently it supports almost all GHC primops and RTS > features. It can run real world Haskell programs that were compiled with > GHC Whole Program Compiler (GHC-WPC). GHC-WPC is a GHC fork that exports > the whole program STG IR. > > The external STG interpreter is an excellent tool to study the runtime > behaviour of Haskell programs, i.e. it can run/interpret GHC or Pandoc. The > implementation of the interpreter is in plain simple Haskell, so it makes > compiler backend and tooling development approachable for everyone. It > already has a programmable debugger which supports step-by-step evaluation, > breakpoints and execution region based inspection. It also can export the > whole program memory state and call-graphs to files for further > investigation. These features make it easy to find a memory leak or to > identify a performance bottleneck in a large real world Haskell application. > > https://github.com/grin-compiler/ghc-whole-program-compiler-project > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs