Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)
csaba.hruska at gmail.com
Sun Dec 5 15:37:23 UTC 2021
I'm aware of the debug adapter protocol
<https://microsoft.github.io/debug-adapter-protocol/> but I have not used
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
My debugger is programmable though, you can write a debug script to
automate the breakpoint setup along with other debug commands.
On Thu, Dec 2, 2021 at 4:08 PM YueCompl <compl.yue at 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.hruska at gmail.com> wrote:
> Today I'll do a presentation about the external stg interpreter.
> If you are interested please join and ask questions.
> Csaba Hruska
> 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.
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs