Skip to content
Max Willembrinck edited this page Nov 2, 2021 · 17 revisions

Welcome to the SeekerDebugger wiki!

Examples, and documentation goes here. At the moment, there is only content related to the "Seeker(Pre-alpha) in Moose Installation Workshop".

Seeker in Moose Installation

Installing Seeker.

Begin by executing the following code in a Playground of a Moose 9 image.

Metacello new
    baseline: 'Seeker';
    repository: 'github://maxwills/SeekerDebugger:main';
    onWarning: [ :ex | ex resume ];
    load.

You should have a look at the readme in Seeker main repository.
It includes the quick reference document.

Does it works?

Use the Seeker Warmup command to browse a TestCase to begin a Seeker Debugging session, and try launching queries. Go to world menu 'Library' and click on 'Seeker Warmup'. Then right-click a test case and select Debug it With Seeker.

Stepping actions

Seeker allows to step backwards an execution. Use the extension toolbar for that.
Currently, Up, Down, and Next Iteration buttons don't work.
All StDebugger stepping actions have been modified, so they can work along with Seeker. This means that StDebugger stepping actions might behave slightly different while Seeker is tracking the execution.

  1. Restarting a Context while using Seeker will effectively restore the execution state (undoing global changes).
  2. Run To command can reverse the execution. (However, it doesn't always works).

How to debug with Seeker

Seeker is an StDebugger extension that enables time traveling functionalities and the usage of Time Traveling Queries. Whenever StDebugger

1. Debugging a TestCase with Seeker

2. Debugging from Playground (Or most code presenters)

Select the code, right click on it, and choose 'Debug it with Seeker'.

3. Programmatically opening a Seeker Debug Session.

Use SeekerSessionHelpers debugSession: aBlock. The execution corresponds to every instruction executed by a Block.

To conditionally start a debugging session, use SeekerSessionHelpers debugSessionIfKeysPressed: aBlock. It will open a Seeker debugging session only if cmd+shift is pressed during the instruction execution.

No breakpoints. Use Seeker Markers instead.

Breakpoints (or Halts) are not supported in the current version. Instead, you can use Seeker Markers to create bookmarks in your execution. Use any of the following functions:

SeekerSessionHelpers marker

SeekerSessionHelpers marker: aString

These functions do nothing. However, they'll be identified by seeker, creating timestamps so you can time-travel from one to another. The example used is: GeneralSeekerExamples >> #markersExample

Writing your own Queries.

As an example, put this code in a class side method.

MyQueries class >> allAssignmentsVariables: seeker
  |query t|
  "Lists the variable name for all the assignments of an execution."
  t := AutoType new.
  query := Query from: seeker programStates
    select: [:state| state node isAssignment] 
    collect: [:state| t newWith
  		bytecodeIndex: state bytecodeIndex;
		varNam: state node variable variable name;
		endWith].
   seeker ui showResult: query asSeekerResultsCollection  

Then From Seeker Scripting tab, execute MyQueries allAssignmentsVariables: seeker. The result should appear in the Query tab. (It needs to be changed manually at the moment)

What is in the query?

  • From.
  • Select.
  • Collect.

Queries definition location

Current queries are (mostly) defined as instance methods of the class SeekerTraceQueriesInterface.

Customizing the conditional debugging modifier keys

The keys combination that will trigger a programmatic conditional seeker debugging session is coded in the method: SeekerGlobals >> #updateModifierKeys:. To customize the combination, modify that method.