Hi Jaromir,
On 2024-01-06T23:23:36+00:00, mail@jaromir.net wrote:
> Hi Christoph,
>
> On 06-Jan-24 9:51:56 PM, christoph.thiede(a)student.hpi.uni-potsdam.de
> wrote:
>
> >Hi Jaromir,
> >On 2024-01-04T15:14:55+00:00, mail(a)jaromir.net wrote:
> >
> > > Hi Christoph,
> > > thanks again for your help!
> > >
> > >
> > > On 04-Jan-24 1:59:00 AM,
> >christoph.thiede(a)student.hpi.uni-potsdam.de
> > > wrote:
> > >
> > > >Hi Jaromir,
> > > >
> > > > > >
> >[...]
> > >
> > >
> > > >But as you say, snapshots can be helpful in certain situations ...
> > > >fascinating how a limitation can evolve as a feature ...
> > > >
> > > >(By the way, there is also a preference called "Replace inspectors
> >with
> > > >explorers in TraceDebugger". But it does not really look nice,
> >that's
> > > >why its labeled as experimental.)
> > >
> > > Cool! For this to look more reasonably you could hide the "value"
> >areas
> > > that display the Inspector's values... (screenshot). The debugging is
> >so
> > > much more dynamic this way :)
> >
> >Interesting! But two issues are remaining (at least for me):
> >
> >(1) You cannot fully read longer values. In inspectors, we have
> >linebreaks and vertical scrolling and the value can use up 60% of the
> >inspector's space. In explorers, we could only allow horizontal
> >scrolling, which is less convenient.
> True
>
> >
> >(2) Where do you evaluate custom do-its in the debugger? I do this all
> >the time. I guess you could you the main contents pane for this, but
> >then it will always be styled badly, and you cannot see your do-its and
> >longer methods at the same time ...
> Hmm, main pane usually... but I personally spend more time staring at
> things than doing them ;)
I also do this sometimes. But mainly my philosophy of Squeak is that you are having vivid conversations with the system and many of its objects all the time. Don't assume things, but ask the system straight up about it! (What is your home method? What instruction will you execute next? Have you already been terminated? How do you simulate that primitive? And with the TraceDebugger also: What have you done before? When/why did your program counter change?) Having that direct access to objects through print-its/debug-its is a luxury that's still not available in many mainstream languages. But sometimes, our tools are not yet capable or intuitive enough to help with this - e.g., we cannot see what happens inside the VM, we don't have good tools for debugging (or tracing) multiple processes, and the interfaces that we've ve got for expressing and answering our questions do not always align directly to our mental model, thus making question answering harder than "staring" and hypothetizing by yourself. That's just my "OO-extremist" perspective, of course. :-)
Best,
Christoph
>
> Thanks again,
> Jaromir
>
> >
> >
> > >
> > >
> > > >
> > > >
> > > > > Understood, thanks. I have noticed, however, that your stepping
> > > >methods like stepOver, stepInto and stepThrough are sometimes
> > > >substantially simpler than their traditional counterparts. How come?
> >Is
> > > >there some tradeoff or have you truly refactored and simplified the
> > > >traditional ones? (Which are very opaque and really hard to truly
> > > >understand)
> > > >
> > > >I would say it's a mixture of both - refactoring and a different
> >model.
> > > >I put some effort in separating model (TDBCursor) and view
> > > >(TraceDebugger) from each other better than the Debugger does (so
> > > >TDBCursor is also usable by itself as a scriptable time-travel
> > > >debugger). The stepping logic in the normal Debugger is also a bit
> > > >scattered in Debugger, Process, and Context. Some things are not
> > > >required in the TraceDebugger, such as the need for the ingenious
> > > >#runUntilErrorOrReturnFrom: because all contexts during tracing must
> >be
> > > >simulated.
> > >
> > > Ahh, true... is this the source of the performance limitation? I
> >tried
> > > to debug some stepOver execution in the Trace debugger and sometimes
> >a
> > > step takes a minute or two.
> >
> >Exactly! If we run certain methods outside of the simulator, we might
> >miss not only parts of the context tree but also changes to variables
> >which I would find even more annoying.
> >Still, I'm aware that this is probably the main limitation of the
> >TraceDebugger, so there is already an open issue for that:
> >https://github.com/hpi-swa-lab/squeak-tracedebugger/issues/106 In a
> >nutshell, users could opt in to skipping certain
> >methods/classes/packages that they consider not relevant for the
> >current debugging session to improve performance (or even make trace
> >debugging of larger programs feasible at all). But this is hard:
> >SimulationStudio must use something like #runUntilErrorOrReturnFrom: to
> >step over irrelevant message sends but reenable the simulation for
> >*every* control flow that exists the context - including exceptions
> >that are eventually resumed and return back into the method stepped
> >over. Same for methods that are activated from within the skipped code
> >that should not be ignored - this would only be possible using
> >breakpoints aka method wrappers. Plus the aforementioned issue of
> >missing state changes. I have been thinking about these issues for a
> >couple of months and my preliminary conclusion is that these
> >requirements go beyond what can be achieved with code simulation. I see
> >greater potential in migrating all the tracing logic away from
> >simulation to method wrappers + bytecode instrumentation, as they have
> >a significantly smaller execution overhead and could be
> >enabled/disabled per method. But that will be a major rewrite ...
> >
> > >
> > > >Some things also cannot work like in the normal Debugger due to the
> > > >possibility of stepping backwards, such as the updates to the window
> > > >label in case of an unhandled error: Normal Debugger uses a
> > > >Notification for this (see #handleLabelUpdatesIn:whenExecuting:),
> >which
> > > >only works one-way, whereas the TraceDebugger uses a more functional
> > > >approach to detect whether the exception handler is still on the
> >stack
> > > >(see TraceDebugger>>#labelString). Oops, this seems to be broken in
> >the
> > > >trunk: the "ZeroDivide:" should actually disappear again once after
> > > >some steps ...
> > >
> > > Thanks again!
> > > >
> > > >
> > > >Best,
> > > >Christoph
> > > >
> > > >---
> > > >Sent from Squeak Inbox Talk
> > > ><https://github.com/hpi-swa-lab/squeak-inbox-talk>
> > > >
> > > >On 2024-01-04T00:03:13+00:00, mail(a)jaromir.net wrote:
> > > >
> > > > > Hi Christoph,
> > > > >
> > > > > Thanks a lot for your explanations - very helpful!
> > > > >
> > > > > a few more notes inlined:
> > > > >
> > > > >
> > > > > On 02-Jan-24 7:53:31 PM,
> > > >christoph.thiede(a)student.hpi.uni-potsdam.de
> > > > > wrote:
> > > > >
> > > > > >Hi Jaromir,
> > > > > >
> > > > > >thanks again for your messages, please keep them coming! And
> > > >squeak-dev
> > > > > >is totally the right place for them IMO. :-)
> > > > > >
> > > > > >
> > > > > >Regarding the openPath bug: Thanks for the pointer, I have
> >uploaded
> > > > > >Collections-ct.1061 to the inbox which would fix it. However, it
> >is
> > > >a
> > > > > >bit surprising that PluggableTreeItemNode>>#asString (and also
> > > > > >Context>>#printString by the way) answers texts not strings, so
> > > >maybe
> > > > > >this needs further discussion.
> > > > > >
> > > > > >
> > > > > > > Or when you open an inspector on a context the context's
> >state
> > > >gets
> > > > > >frozen in time and won't change when you proceed debugging -
> >another
> > > > > >groundbreaking change!
> > > > > >
> > > > > >Yes, these "snapshot inspectors" (or also "snapshot explorers")
> >have
> > > > > >their pros and cons. As a con, I often found it inconvenient
> >that I
> > > > > >cannot watch the changing state of certain objects in extra
> >windows
> > > >as
> > > > > >I am stepping through a TraceDebugger. But always updating these
> > > > > >inspectors depending on the current time of the TraceDebugger
> >might
> > > >be
> > > > > >confusing as well because there is no clear visual connection
> >...
> > > >It's
> > > > > >an unsolved UX problem for me.
> > > > >
> > > > > It depends: sometimes I like to see the states changing in an
> > > >inspector
> > > > > and sometimes I desperately want to compare past and present
> >states.
> > > >It
> > > > > almost sounds like a preference :) Btw. I usually use the
> >Explorer
> > > > > instead of Inspector but what annoys me is the Explorer (unlike
> >the
> > > > > Inspector) doesn't update the states automatically: I have to
> >refresh
> > > > > manually (switch to Inspector and back or collapse the hierarchy
> >and
> > > > > open again - is there possibly something to make the Explorer
> >update
> > > > > automatically? Thanks!)
> > > > >
> > > > >
> > > > > >But I'm glad they work well for you. :-) If you have any better
> > > >ideas,
> > > > > >let me know!
> > > > > >
> > > > > >
> > > > > >Regarding your questions about the behavior of code when being
> >run
> > > >in
> > > > > >the TraceDebugger:
> > > > > >
> > > > > > > If I turn off the preference "Show call tree in
> >TraceDebugger" am
> > > >I
> > > > > >right to expect the Trace debugger behavior would be equivalent
> >to
> > > >the
> > > > > >traditional one?
> > > > > >
> > > > > >Yes and no. :-) First, the representation of the traced program
> >in
> > > >the
> > > > > >TraceDebugger (stack vs tree) does not influence the execution
> > > > > >semantics of the program. It's just that in rare situations with
> > > > > >irregular context switches, the tree model is currently unable
> >to
> > > > > >locate certain contexts at certain points in time. That's why
> >these
> > > > > >contexts are skipped as you step through a program in the
> > > >TraceDebugger
> > > > > >with the context tree activated.
> > > > > >
> > > > > >Second, code that is simulated inside the TraceDebugger is (or
> > > >should)
> > > > > >behave exactly as the same code being run in a normal simulator
> > > >(like
> > > > > >when you step through an expression or use Context
> > > > > >class>>#runSimulated:). There are however two exceptions to this
> > > > > >invariant:
> > > > > >
> > > > > >(1) Bugs in the simulation engine: We (that's an including we!)
> >have
> > > > > >been working on fixing these bugs so that all code can behave
> > > >exactly
> > > > > >then same when being simulated. Still, there are some open known
> > > >(and
> > > > > >likely further unknown) issues (e.g., you cannot simulate a
> > > >simulator
> > > > > >which is executing a failed primitive:
> > > > >
> > > >
> > >ContextrunSimulated:[ContextrunSimulated:[#()tryPrimitive:60withArgs:#(0)]]),
> > > > > >so this delightful quest is still going on. :-)
> > > > > >
> > > > > >(2) Context primitives 195-197 (#findNextUnwindContextUpTo:,
> > > > > >#terminateTo:, #findNextHandlerContextStarting) always fail when
> >the
> > > > > >context is executed in SimulationStudio (which also includes the
> > > > > >TraceDebugger): This is due to the nature of SimulationStudio,
> >which
> > > > > >subclasses from Context (see SimulationContext) to make parts of
> >the
> > > > > >simulated code execution customizable. The VM, however, is not
> > > >prepared
> > > > > >to the existence of such subclass objects of Context and will
> >always
> > > > > >fail when these primitives are invoked on an object that is not
> > > >exactly
> > > > > >of the class Context, so the methods execute their fallback code
> > > > > >instead. So this is a visible difference in the execution
> >semantics
> > > > > >between normal VM and SimulationStudio/TraceDebugger.
> > > > >
> > > > > Understood, thanks. I have noticed, however, that your stepping
> > > >methods
> > > > > like stepOver, stepInto and stepThrough are sometimes
> >substantially
> > > > > simpler than their traditional counterparts. How come? Is there
> >some
> > > > > tradeoff or have you truly refactored and simplified the
> >traditional
> > > > > ones? (Which are very opaque and really hard to truly understand)
> > > > >
> > > > > >
> > > > > >
> > > > > >However, now you might say: This makes sense when I evaluate
> > > > > >Simulatordebug:[thisContextfindNextHandlerContextStarting]
> >because
> > > >when
> > > > > >I inspect thisContext in that debugger, it shows a subclass of
> > > >Context;
> > > > > >but when I do
> >[thisContextfindNextHandlerContextStarting]debugTrace,
> > > > > >thisContext actually is an instance of Context itself, so how
> >can
> > > >the
> > > > > >VM detect this? And you would be right, because when you
> >*inspect* a
> > > > > >context in the TraceDebugger, it is a Context instance indeed,
> >but
> > > >not
> > > > > >when you actually *execute* it in the TraceDebugger, as you can
> >see
> > > > > >when you evaluate [thisContextclass]debugTrace ... The
> >explanation
> > > >for
> > > > > >that lies in TDBTrace>>#enableSimulatorDuring:, but to cut it
> >short,
> > > >we
> > > > > >convert all (non-dead) Context instances from the
> >TraceDebugger's
> > > >tree
> > > > > >to a subclass of SimulationContext temporarily during each step
> >to
> > > > > >achieve two things: First, to not confuse observant users like
> >you
> > > >with
> > > > > >the existence of these subclasses (well, maybe that did not work
> >too
> > > > > >well), and second, to make it possible to resume from a trace
> > > >debugger
> > > > > >at any point, which will execute the process in the regular VM;
> >and
> > > >as
> > > > > >noted before, the VM can only handle Context instances, so it
> >would
> > > > > >fail when scheduling the process otherwise (you can actually
> >observe
> > > > > >that when trying to proceed from
> > > > > >Simulatordebug:[thisContextfindNextHandlerContextStarting]).
> >(Fun
> > > >fact:
> > > > > >Not all VMs handle Context subinstances that carefully: SqueakJS
> > > >will
> > > > > >seriously mix up the context/object layout, while TruffleSqueak
> >will
> > > > > >terminate as soon as you instantiate (!) any subinstance of
> >Context,
> > > >so
> > > > > >I'm gladful that the OpenSmalltalk VM is as tolerant as it is.)
> > > > > >
> > > > > >I hope this was a bit interesting to you!
> > > > >
> > > > > Will study, thanks!
> > > > >
> > > > > >
> > > > > >
> > > > > > > Example: do step through to the [^2] block and then step
> >through
> > > > > >again
> > > > > > >
> > > > > > > [^2] ensure: []
> > > > > > >
> > > > > > > Traditionally, you end up in the unwind block.
> > > > > > > In the new Trace debugger you end up with the #cannotReturn:
> > > >context
> > > > > >as if the computation just ran until the end.
> > > > > >
> > > > > >Hm, I cannot reproduce this. If I step through ^2 and then step
> > > >through
> > > > > >again, I land in Context>>terminateTo:. Are you using the latest
> > > > > >version of trunk and TraceDebugger? However, you currently end
> >up in
> > > > > >#cannotReturn: when stepping beyond the
> > > >ProcessoractiveProcesssuspend
> > > > > >in the bottom context of a process using the TraceDebugger. This
> >is
> > > > > >because other than the normal debugger, the TraceDebugger does
> >not
> > > >yet
> > > > > >honor the suspended/terminated state of the interrupted process.
> > > >Maybe
> > > > > >it should ...
> > > > > >
> > > > > >Thanks for your thoughts and I'm always happy about more! :-)
> > > > > >
> > > > > >Best,
> > > > > >Christoph
> > > > > >
> > > > > >---
> > > > > >Sent from Squeak Inbox Talk
> > > > > ><https://github.com/hpi-swa-lab/squeak-inbox-talk>
> > > > > >
> > > > > >On 2024-01-01T19:25:04+00:00, mail(a)jaromir.net wrote:
> > > > > >
> > > > > > > Hi Christoph,
> > > > > > >
> > > > > > > sorry, a follow-up question :)
> > > > > > >
> > > > > > > If I turn off the preference "Show call tree in
> >TraceDebugger" am
> > > >I
> > > > > > > right to expect the Trace debugger behavior would be
> >equivalent
> > > >to
> > > > > >the
> > > > > > > traditional one?
> > > > > > >
> > > > > > > In other words: if I run the traditional debugger and the
> >Trace
> > > >one
> > > > > >side
> > > > > > > by side, should they display analogous steps?
> > > > > > >
> > > > > > > In the other message I wrote about a different way to
> >simulate
> > > > > >primitive
> > > > > > > calls.
> > > > > > >
> > > > > > > However, I've noticed other irregularities so that's why I
> > > >started
> > > > > > > wondering maybe my assumption was wrong and the Trace
> >debugger is
> > > > > > > designed to present the simulation differently. Please
> >advise.
> > > > > > >
> > > > > > > Example: do step through to the [^2] block and then step
> >through
> > > > > >again
> > > > > > >
> > > > > > > [^2] ensure: []
> > > > > > >
> > > > > > > Traditionally, you end up in the unwind block.
> > > > > > > In the new Trace debugger you end up with the #cannotReturn:
> > > >context
> > > > > >as
> > > > > > > if the computation just ran until the end.
> > > > > > >
> > > > > > > Is this expected? (My guess is it isn't but can't figure out
> >why)
> > > > > > >
> > > > > > > Thanks again,
> > > > > > > Jaromir
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 01-Jan-24 3:31:29 PM, "Jaromir Matas" <mail(a)jaromir.net>
> > > >wrote:
> > > > > > >
> > > > > > > >Hi Christoph,
> > > > > > > >
> > > > > > > >Is it ok that I ask questions about the new debugger? What
> >would
> > > >be
> > > > > >the
> > > > > > > >best format for such a "Q&A" - here or perhaps within a
> >topic on
> > > > > > > >squeak-smalltalk/squeak-object-memory? I don't expect a
> >flood of
> > > > > > > >questions but to get a bit familiar with your debugger it
> >would
> > > >help
> > > > > > > >tremendously to be able to ask right away instead of
> >trudging
> > > > > >through
> > > > > > > >the code/help :) The code usually helps to understand
> >**how**
> > > >things
> > > > > > > >work, the mechanics, but rarely **why**, the intentions.
> > > > > > > >
> > > > > > > > > you can also turn off the preference "Show call tree in
> > > > > > > >TraceDebugger"
> > > > > > > >
> > > > > > > >Thanks, that helps to familiarize myself with the new
> > > > > >functionalities
> > > > > > > >"step-by-step", and not be overwhelmed by all the might of
> >the
> > > >call
> > > > > > > >tree :) Being able to go back is already a hell of an
> > > >improvement!
> > > > > >Or
> > > > > > > >when you open an inspector on a context the context's state
> >gets
> > > > > >frozen
> > > > > > > >in time and won't change when you proceed debugging -
> >another
> > > > > > > >groundbreaking change!
> > > > > > > >
> > > > > > > >Question:
> > > > > > > >In the traditional debugger, when you step into a primitive,
> >the
> > > > > > > >primitive gets executed and the simulation moves over the
> > > >primitive
> > > > > > > >call. The Trace debugger, however, starts executing the
> >fallback
> > > > > >code
> > > > > > > >of the primitive call - why is that?
> > > > > > > >
> > > > > > > >Screenshot after step into #terminateTo:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >Thanks again,
> > > > > > > >Jaromir
> > > > > > > >
> > > > > > > >On 31-Dec-23 2:16:32 AM,
> > > > > >christoph.thiede(a)student.hpi.uni-potsdam.de
> > > > > > > >wrote:
> > > > > > > >
> > > > > > > >>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
> > > > > > > >><https://github.com/hpi-swa-lab/squeak-inbox-talk>
> > > > > > > >>
> > > > > > > >>On 2023-12-30T19:04:07+00:00, mail(a)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>/
> >
> >Best,
> >Christoph
> >
> >---
> >Sent from Squeak Inbox Talk
> ><https://github.com/hpi-swa-lab/squeak-inbox-talk>
---
Sent from Squeak Inbox Talk