Time traveling visual debugger

[breandan]

Debugging Kotlin∇ code within IntelliJ IDEA can be somewhat cumbersome due to the functional API structure (lots of deeply-nested stack traces and context switching). To facilitate more user-friendly debugging, we should add support for visual debugging by exposing Kaliningraph’s built-in graph visualization capabilities. For example, the user could attach a debugger to the computation graph by writing fn.debug(bindings), which would open a browser window and allow them to replay the rewriting steps, see numerical values flowing through the nodes and step forward and backward through time.

Alternatively, a better approach might be to reuse Buche, which is specifically designed for visual debugging. In this case, we would simply need to attach to the browser using a background process then write the logs to e.g. standard output. Perhaps it is possible to get Buche to play together with Kotlin/JS somehow, need to investigate this approach further to understand its complexity as compared with Kweb rendering.

[therealansh]

Hey @breandan , I am new to Kotlin and would like to learn more of it. Can i try on this one? Do this project have any slack or discord?

[breandan]

Hi @therealansh, welcome to the Kotlin community! PRs are certainly welcome. You might have a look at the Rewriter.kt or PrefAttach.kt demos in Kaliningraph and try to reproduce it using the Kotlin∇ computation graph. We don't have a dedicated Slack or Discord, but I try to be responsive on GitHub and often hang out on the #mathematics channel of the Kotlin Slack. Feel free to ping me wherever if you have any questions.

[therealansh]

Hey @breandan where should I implement these files? Any specific directory?

[breandan]

You will need to make changes to the core API. In particular, when DEBUG mode (cf. EAGER mode) is enabled, each recursive call to df() and apply(vararg xs: Fun<X>) could pause execution, append toGraph() to the debugger stack and await the → key to be pressed. If pausing execution is too complicated, I would just write the intermediate graphs to a stack and return immediately.

You could add a demo for the debugger to samples, e.g. something like this:

fun main() {
  DEBUG = true
  val x by DReal.Var()
  val y by DReal.Var()
  val f = x * (-sin(x * y) + y) * 4
  f(x to 0, y to 1) // This should open a browser window with the debugger stack navigable using ←/→ keys
}

If you're feeling ambitious, it would be nice to improve the graph visualization algorithm somehow, instead of just displaying the static graph, it would be nice to see edges labeled with values flowing across them (e.g. see the reduction semantics). For that, you may need to modify Kaliningraph's implementation to make UnlabeledEdge a LabeledEdge and update render().

Again, feel free to ping me if you have questions about any of this. Thanks!

[therealansh]

Hey @breandan So i have a couple of questions. So as i can see in the PrefAttach and Rewrite there is a animate function which seems to be missing in main but present in test which actually opens the web using KWeb. Do we have to re-implement this function in KotlinGrad api or should we also implement this in Kaliningraph main src.
Also what i have understood is that we have to call toGraph() in the function as

fun apply(vararg xs: Fun<X>): SFun<X>{
    if(EAGER){stack??.push(toGraph()}
    when (op) {
      Monad.id -> this
      Monad.sin -> (xs[0] as SFun<X>).sin()
      Monad.cos -> (xs[0] as SFun<X>).cos()
      Monad.tan -> (xs[0] as SFun<X>).tan()
      Monad.`-` -> -(xs[0] as SFun<X>)
    }
}

Similar with the df() recursive call. Here how can we access the debugger stack by getStackTrace() ? or it will be just an empty stack when we initialise the function. Thanks for helping in advance i am new to this big codebase so might take a few days to get along.

[breandan]

Yep, that’s a good point. We separated the Kweb dependency from the main library to avoid dependency bloat. If you want to use Kweb for your debugger implementation, you can just add a testImplementation instance to the dependencies section of core/build.gradle.kts and implement your animate functionality in the test directory.

I guess the simplest debugger implementation would just accumulate intermediate graphs in a mutable variable, which could be read asynchronously. If you want to define a custom function debugApply which is called when the DEBUG flag is set, that would also probably work. A better solution would be to make it functional, i.e. your solution would need to return a Pair<SFun<X>, List<SFun<X>>> instead of writing to some separate data structure.