[Epic] Debugger

[ana-pantilie]

[ana-pantilie]

• [ ] Debugger working with multiple Tx modules

An untyped plutus program may have been composed from multiple modules (Tx haskell files), but we currently only show/highlight the Tx file provided by the user at the command-line.

Instead, read the filepath from the SrcSpans and update the tui’s SourceEditor accordingly.

[ana-pantilie]

• [ ] Implement a DAP debugger frontend

The debugger code is fairly modular and allows multiple "frontends". Currenlty we have 3 frontends: tui, cli and an internal testing-only frontend.

Add a DAP-protocol frontend

[ana-pantilie]

• [ ] Editing ScriptContext (Data) inside debugger

A way to edit with a nice UX the “script context” (last script arg) of a currently-debugging script inside the TUI, and restart the debugging.

[ana-pantilie]

• [ ] Marlowe script integration to the debugger

This is for allowing Marlowe scripts as the source program to the debugger , similar to what we do for PlutusTx.

An extra nice-to-have is the feature to step over the marlowe interpreter (not the underlying CEK interpreter). Perhaps this feature needs a lot of work.

[ana-pantilie]

• [ ] Aiken script integration with the Plutus debugger

After discussing with @KtorZ , I understood that Aiken script may have source-span annotations available.

Integrate into the Debugger UI the tracing/breakpointing of Aiken scripts, similar to what we currently do for PlutusTx

[ana-pantilie]

• [ ] Document debugger in RTD

Usage, examples

[ana-pantilie]

• [ ] Improve Debugger's PlutusTx SourceSpans

The sourcespans of the source file(s) are not very detailed or are missing. Find a way that could be improved or at least catalog and document their limitations.

1. look at bugs in getVarSourceSpan
2. we accumulate too many srcspans in a list and we arbitrarily choose to use&show the first one in the TUI. This is inaccurate. Perhaps it is better to show the most smallest sourcespan

[ana-pantilie]

• [ ] Log the context and env. var. state in Debugger

For TUI, and optionally CLI

It’s the implementation of @zliu41 's spike:

One option: for each variable in CoreExpr, try to solve the Show constraint for its type. If it is solvable, annotate the corresponding PLC term with the PLC code that shows the variable. Is it possible to do this just in time rather than ahead of time?

mpj wrote:

Another question: what do we do if we’ve got a value whose type is not fully concrete? e.g. what happens if you break inside id when evaluating id 1? We could check what the GHCi debugger does, it must have similar problems.

@effectfully wrote:

We might be able to get away with Debug.RecoverRTTI

[effectfully]

• [x] Use safeIndexOneCont in SteppableCek

SteppableCek needs to use safeIndexOneCont just like the normal CEK does, purely for consistency and keeping the two syntactically in sync