Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)

[Csaba Hruska]

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.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:
>
> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211205/d0de5d8f/attachment.html>