Hi Jaromir,
thanks a lot for trying it out!! Your feedback means a lot to me. :-)
Indeed you hit a pretty unfortunate example. The TraceDebugger is not ready for all your clever investigations regarding non-local returns and unwinding. ;-) In fact, your example reveals another limitation that I forgot to mention in the announcement, which regards programs with irregular context switches - e.g., generators/coroutines, but also non-local returns through unwind contexts. This is because the TraceDebugger stores and displays all method invocations in a tree, but in the case of manual context switches, there is no single global tree - its structure would change over the execution time, and when selecting a method invocation, it is not even clear to what parent (sender) it would belong, as there might be multiple. The current solution is to display the tree from the perspective of the stack at the viewed point in time (see also the '@ <timeIndex>' in the window title), so it looks corrupted while stepping through Context>>#terminateTo: as the stack is being manipulated. (You would notice the same in a normal debugger if you turned off the optional primitive 196 in this method - for SimulationContexts this method always uses the fallback code.)
Nevertheless, I have pushed some changes that should allow you to step out of #terminateTo: again. (You can update the TraceDebugger from the window menu icon at the right top, like all of my tools.) At some point there will no method be displayed, but you can just step further and eventually return back to the starting point. :-) If you want to, you can also turn off the preference "Show call tree in TraceDebugger" to make the TraceDebugger look more like a normal debugger, which also solves the context switches issue. But in general - unless you are debugging unwinding stuff - I would not recommend that as it removes one important strength of the TraceDebugger. :-)
But again, this is really not a prime example for the TraceDebugger. Better use it to explore how the simulator works. :-) For example, you could do the following:
[ContextTest debug: #testBlockCannotReturn] debugTrace.
And in that trace debugger, you could select the start method, press Cmd + f(ind), and type "return:from:" to investigate the behavior of your solution there again, etc.
Thanks for your comments! This was a good chance for me to sort some things out! :-)
Best,
Christoph
---
Sent from Squeak Inbox Talk
On 2023-12-30T19:04:07+00:00, mail@jaromir.net wrote:
> Hi Christoph,
>
> This indeed sounds like a GREAT idea! I look forward to seeing your use
> cases to build the right intuition.
>
> In the meantime I've tried to debug/trace this example I've been working
> with lately:
>
> [^2] ensure: []
>
> If I start the debugger, hit `trace it` and then `step over`, it stops
> at Context>>terminate and the view gets corrupted (the initial part of
> the trace is hidden and can't be made visible unless clicking on some of
> the pink lines - but not every line does it...)
>
>
>
>
> If I then continue stepping over it ends up with some kind of error:
>
>
> Maybe this is just an unfortunate example... Or maybe I'm just doing
> something wrong...
>
> At any rate - THANKS for your effort!!
>
>
> On 30-Dec-23 4:37:28 PM, christoph.thiede(a)student.hpi.uni-potsdam.de
> wrote:
>
> >Thanks for the reply, Dave! I will try to post one or two concrete use
> >cases about the TraceDebugger in the next couple of days, so stay
> >tuned. :-)
> >
> >Best,
> >Christoph
> >
> >---
> >Sent from Squeak Inbox Talk
> ><https://github.com/hpi-swa-lab/squeak-inbox-talk>
> >
> >On 2023-12-29T11:01:10-06:00, lewis(a)mail.msen.com wrote:
> >
> > > This sounds like really interesting work! I love the idea of being
> > > able to interactively go back in "oops, I‘ve stepped too far, let‘s
> > > start all over again" situations. It will probably take some time for
> > > me and others to wrap our heads around the things you have done, so
> > > don't be surprised if you get a delayed response to this announcement
> > > :-)
> > >
> > > Congratulations!
> > > Dave
> > >
> > >
> > > On Fri, Dec 29 2023 at 01:42:16 AM +0100,
> > > christoph.thiede(a)student.hpi.uni-potsdam.de wrote:
> > > > Hi all!
> > > >
> > > > I‘m very excited to announce a project today that we have been
> > > > working on over the past two years: The *TraceDebugger* [1] is a
> >new
> > > > back-in-time/time-travel/omniscient debugging tool for Squeak that
> > > > allows you to record past method activations and states during
> > > > execution and explore them later.
> > > >
> > > > <https://github.com/hpi-swa-lab/squeak-tracedebugger>
> > > >
> > > > Metacellonew
> > > > baseline:'TraceDebugger';
> > > > repository:'github://hpi-swa-lab/squeak-tracedebugger';
> > > > /"repository:
> > > > 'github://hpi-swa-lab/squeak-tracedebugger:squeak60';"//"for Squeak
> > > > 6.0"/
> > > > get;
> > > > load.
> > > >
> > > > **What can it do? (Features)**
> > > >
> > > > - *Record all method activations and historic states:* Normally
> >step
> > > > through a program in the debugger while automatically recording its
> > > > execution.
> > > > - *Replay execution of a traced program:* Navigate through all
> > > > method invocations using the /*context tree*/ or the /*Step
> >Back/Step
> > > > Forward*/ buttons (to avoid these "oops, I‘ve stepped too far,
> > > > let‘s start all over again" situations).
> > > > - *Interact with historic states:* Inspect/explore snapshots of
> > > > objects or send them any message.
> > > > - *State-centric debugging using the ***/History Explorer*/**:*
> > > > Gather, explore, and visualize all changes to an object/expression
> > > > over the recorded time ("When did this
> >variable/collection/screenshot
> > > > change?").
> > > > - *Additional navigation tools* for searching and filtering the
> > > > context tree.
> > > > - *Focus on interactivity:* No hours of recording, no GBs of mem
> > > > consumption - at least for common small to medium programs.
> > > > - *UI resembles the classic Smalltalk debugger:* You'll find your
> > > > familiar stepping buttons, code browsing tools, inspectors, and
> > > > shortcuts - plus more.
> > > >
> > > > The TraceDebugger is a general-purpose tool and not tied to
> > > > particular domains. In the past months, we have successfully used
> >it
> > > > to understand several bugs and interaction patterns in the Trunk
> > > > (Morphic layout/rendering, compiler/decompiler, code simulation,
> > > > …). The tool is also self-supporting, so you can debug a
> > > > TraceDebugger from another TraceDebugger. :-)
> > > >
> > > > **What can‘t it do (yet)? (Limitations and future work)**
> > > >
> > > > - *High performance:* While (sufficiently) fast enough for most
> > > > small to medium workloads, tracing very compute- or mem-intensive
> > > > operations may require more time (ex.: compiler/decompiler
> > > > invocation: <1s, HTTPS request: <10s, tool building: <5m, complex
> > > > rendering: minutes up to hours).
> > > > - *Not a dataflow analyzer:* The TraceDebugger does not track
> > > > dataflow events (e.g., argument passing) but only state changes.
> > > > - *No tracing of external states/events* for FFI/OSProcess or
> >custom
> > > > VM modules.
> > > > - *No support for advanced language concepts* such as identity
> > > > forwarding/write barriers.
> > > >
> > > > **How does it work? (Implementation)**
> > > >
> > > > In one sentence: To record message sends and side effects, we
> > > > decorate the execution of certain bytecodes with tracing extensions
> > > > by modifying the code simulation using SimulationStudio [2].
> > > >
> > > > In one paragraph: The program is executed in a specialized code
> > > > simulator that overrides instructions for sending messages (e.g.,
> > > > send, superSend) and for performing side-effects (e.g.,
> >popIntoRcvr,
> > > > primitiveAtPut, push). All message sends are recorded in a tree and
> > > > all changed object slots are stored in a sparse time-dependent
> >memory
> > > > structure before they are overwritten. For time-traveling, the tree
> > > > is traversed using a cursor. For accessing historic objects, a
> >proxy
> > > > evaluates all messages sent to an object in another specialized
> > > > simulator (retracing simulator) that emulates historic states for
> >the
> > > > requested point in time by forwarding read primitives (e.g.,
> > > > pushRcvr, primitiveAt) to the recorded memory. For gathering state
> > > > changes in the History Explorer efficiently, the query is evaluated
> > > > in a range retracing simulator with vectorization and fork
> >semantics.
> > > >
> > > > In academic terms: We have published two papers about the
> > > > TraceDebugger that provide further details about its implementation
> > > > and its applications for program exploration, "Object-Centric
> > > > Time-Travel Debugging: Exploring Traces of Objects" [3] and
> > > > "Time-Awareness in Object Exploration Tools: Toward In Situ
> > > > Omniscient Debugging" [4].
> > > >
> > > > In Smalltalk: Just check out the code base and explore it by
> > > > yourself! The class comments in TraceDebugger
> ><code://TraceDebugger>
> > > > and TDBCursor <code://TDBCursor> should provide good starting
> >points.
> > > >
> > > > **How can I use it?**
> > > >
> > > > Please try it out and report feedback! The TraceDebugger supports
> > > > the latest Squeak Trunk and Squeak 6.0. You can either download a
> > > > prepared all-in-one bundle on GitHub:
> > > >
> > > > <https://github.com/hpi-swa-lab/squeak-tracedebugger/releases>
> > > >
> > > > Or you can install it into your own image using Metacello:
> > > >
> > > > Metacellonew
> > > > baseline:'TraceDebugger';
> > > > repository:'github://hpi-swa-lab/squeak-tracedebugger';
> > > > /"repository:
> > > > 'github://hpi-swa-lab/squeak-tracedebugger:squeak60';"//"for Squeak
> > > > 6.0"/
> > > > get;
> > > > load.
> > > >
> > > > To get started, just open a normal debugger (e.g., by selecting an
> > > > expression and pressing Cmd+Shift+D to debug it) and then press the
> > > > "Trace It" button on the right. There‘s also some pretty detailed
> > > > documentation in the Help Browser <code:// TraceDebugger showHelp>
> > > > that covers everything you should know.
> > > >
> > > > My goal is to improve convenience and provide a useful tool for the
> > > > community, so I‘m very excited to hear your impressions, ideas, and
> > > > thoughts. Here, on GitHub, or in a private message. Let‘s have a
> > > > great discussion! :-)
> > > >
> > > > Best,
> > > >
> > > > Christoph (and Marcel)
> > > >
> > > > PS: Props to Eliot who brought up the original idea of "subclassing
> > > > from Context" for other reasons four years ago. [5]
> > > >
> > > > [1] <https://github.com/hpi-swa-lab/squeak-tracedebugger>
> > > > [2] <https://github.com/LinqLover/SimulationStudio>
> > > > [3] Christoph Thiede, Marcel Taeumel, and Robert Hirschfeld. 2023.
> > > > Object-Centric Time-Travel Debugging: Exploring Traces of Objects.
> > > > <https://doi.org/10.1145/3594671.3594678> In /Companion Proceedings
> > > > of the 7th International Conference on the Art, Science, and
> > > > Engineering of Programming/ (/<Programming>'23 Companion/), March
> > > > 13–17, 2023, Tokyo, Japan. ACM, New York, NY, USA, 7 pages. DOI:
> > > > 10.1145/3594671.3594678 <https://doi.org/10.1145/3594671.3594678>.
> > > > PDF: <https://dl.acm.org/doi/pdf/10.1145/3594671.3594678>
> > > > [4] Christoph Thiede, Marcel Taeumel, and Robert Hirschfeld. 2023.
> > > > Time-Awareness in Object Exploration Tools: Toward In Situ
> >Omniscient
> > > > Debugging. <https://dl.acm.org/doi/10.1145/3622758.3622892> In
> > > > /Proceedings of the 2023 ACM SIGPLAN International Symposium on New
> > > > Ideas, New Paradigms, and Reflections on Programming and Software/
> > > > (/Onward! '23/), October 25–27, 2023, Cascais, Portugal. ACM, New
> > > > York, NY, USA, 14 pages. DOI: 10.1145/3622758.3622892
> > > > <https://doi.org/10.1145/3622758.3622892>. PDF:
> > > > <https://dl.acm.org/doi/pdf/10.1145/3622758.3622892>
> > > > [5]
> > > >
> ><http://lists.squeakfoundation.org/pipermail/squeak-dev/2019-October/204803.html>
> > > >
> > > > ---
> > > > /Sent from//Squeak Inbox Talk
> > > > <https://github.com/hpi-swa-lab/squeak-inbox-talk>/