New post
Question
· Dec 20, 2018

How would you build a Time Travel Debugger?

#Debugging #Caché

I've been looking at the idea of developing a Time Travel Debugger utility.

It would take a debug target and have a few options such as stack depth and disclude system code.

The debugger would either be started from an external tool, or triggered from a line of code inserted into a method that I want to record.

The debugger would execute the code from start to end and record the full stack on each step to the configured depth.

A visualisation tool would provide a set of controls to play the recording forwards and backwards and provide various ways to search and jump to points in the recording.

The idea is that the TTD code be added at the start of CSP pages or async processes where time itself is an important factor, or where its fiddly to attach a debugger.

I already have a stack record method which is able to take a very detailed snapshot of the stack and record it as a single JSON object.

The next stage is to figure out which are the best ways to start a debugger and step through the process. For a code triggered TTD I started to look at using system events to pause a process, job of a debugger process and restart the process, but it wasn't doing what I expected.

I've been experimenting with the %Studio.Debugger and %Debugger.System classes, but realise that I am scrabbling around in the dark a little with these classes.

I was hoping someone had any developer notes, a reference implementation or any advice to speed up these efforts?

Discussion (4)1
Log in or sign up to continue
Dmitry Maslennikov · Dec 20, 2018

Every debugging tied very much with an editor of code. So, the first question should be, which editor should be used. The studio already has some debugging options, Atelier, too. I'm working hard now on VisualStudio code, and they also have good ways for debugging and hope I will manage to add good debugger for VSCode as well, but not only me who can do it. George James already has their debugger and introduced their work on the same debugger in VSCode.

0 0
Dmitry Maslennikov · Dec 20, 2018

Sounds wonderful.

But, I hope you don't do it from scratch and reuse some already developed components. Developing editor, from scratch is too difficult, and TDD is the last thing to do on the list. And when you say IDE, it means much more than just Editor. And is VSCode is not IDE but has a lot of possibilities already. You can look at Monaco editor, which can work in a browser, but it is also an engine for VSCode. So, it would be possible to reuse some functionality from VSCode extension.

0 0
Sean Connelly · Dec 20, 2018

The IDE (or enhanced code editor if you like) is actually dog food for my own standards based UI library.

In terms of building web based editors I've been building them from scratch for years so I am fairly comfortable with the level of difficulty. There is a screen shot below of one.

And yes, TTD will be one of the last features, but, I do want to prove the concept up front and inject any design decisions into the foundations so that I don't end up with lots of code re-factoring.

I've not used Monaco, mainly ACE. Perhaps there is some synergy between the two projects to use Monaco.

Any help with the original question would be much appreciated.

0 0