GTDebugger in Pharo 5.0

After GTInspector, GTPlayground, and GTSpotter, it is time for GTDebugger to enter the main Pharo arena. GTDebugger is part of the Glamorous Toolkit project and it is mainly driven by Andrei Chis. Since several years it acts as the default debugger in the Moose environment. Still, even if it is a mature implementation, the debugger is a critical development tool in Pharo and a new solution can affect significantly the workflow of developers. This post offers an overview of these differences and some practical information.

We should note from the start that, to make the transition smoother, GTDebugger can be easily turned on/off through a setting.


The generic stack debugger

The default incarnation of the GTDebugger comes with a slightly different interface than the previous debugger, so let’s take a tour.

Similar to the classic debugger structure, the stack is on top-left, and code is on the top-right, and the variables are offered at the bottom.

In the current state, the GTDebugger is implemented in Glamour, and this influences the way actions are being distributed. Thus, the stack manipulation actions (e.g., step into or step over) are offered in the stack pane, while code related actions (e.g., browse) are offered in the code pane.


One thing to note is that the variables at the bottom are offered in a fully functional GTInspector.


Another particularity is that the stack highlights some of the entries. For example, in the below screenshot you can observe a debugging session corresponding to the start of an inspector. The second method activation is highlighted in blue to denote that it is a method situated in the same class as the current method, and the following two are marked with black to show that they belong to the same package:


The moldable debugger

While the generic debugger has only minor differences to the classic one, the main difference comes from what cannot be easily seen. Like all other tools from the Glamorous Toolkit, GTDebugger is moldable by design. In the case of the inspector each object can influence the displayed presentations. In the case of the debugger, it is the execution context that can decide the presentation and interaction logic.

This means that we can easily create custom debuggers for different libraries. The main distribution comes with two such custom debuggers: the SUnit debugger, and the bytecode debugger. These are both useful and provide examples of how the debugger can be customized.

The SUnit debugger) provides a simple customization that shows a diff view when assert:equals: is present in the debugged stack. This might sound trivial, and it indeed it is relevant in only some cases, but detecting fine-grained differences between the expected result and the provided result is a problem is every IDE I know. It is indeed simple, but it is one of those examples of how simple things should actually be simple. This is important because simple things add up and they end up constructing the overall user experience.

This extension is found in the GT-SUnitDebugger package and it totals 132 lines of code. That should fall in the inexpensive category.

Let’s now take a look at the bytecode debugger. This one again customizes the presentation in a couple of ways:

  • a new bytecode view appears to the right of the code pane, and
  • the inspector variables appear listed with more bytecode-relevant labels (e.g., 1, rcv1).


Another relevant part in a debugger is the way we can navigate the execution space. Thus, actions such as 'step over' should be controllable by the programmer of a debugger. In the case of the bytecode debugger, a desired action is to be able to step to a specific bytecode.


The implementation of this debugger consists of 165 lines of code.


The GTDebugger is a new take on debugging. At first glance, it looks similar to any other debugger, but its moldable nature and customization costs measured in only hundreds of lines of code paves the way for a significant departure from classic debugging.

To get you started, the core distribution comes with two concrete custom incarnations. Actually there are three: the generic stack debugger is implemented in the same way. There exists others for different libraries, such as PetitParser or Glamour, but these default ones already offer a beginning of documentation.

You can read more about the GTDebugger here:

Posted by Tudor Girba at 8 January 2016, 11:01 am with tags gt, moose, analysis, pharo link

GT Spotter at the ESUG 2015 Innovation Technology Awards 

GT Spotter, the novel Pharo search interface, just entered the ESUG 2015 Innovation Technology Awards competition.


GT Spotter is part of the Glamorous Toolkit project and it offers an elegantly uniform search interface for any objects, including classes, packages, methods, senders, files, playground pages, examples, projects, and even your custom objects. It can be easily extended, currently featuring more than 100 such extensions.

Here is the original trailer:

And an updated overview slideshow:

Posted by Tudor Girba at 12 July 2015, 1:01 pm with tags analysis, moose, tooling link

Scoping for a specific search category in GTSpotter

GTSpotter let’s you search flexibly for all sorts of objects, and the results are typically split into multiple search categories. In this post we take a quick look at scoping your search to a specific category only.

Let’s say that you want to search for some Collection* package. Typing Collec produces matches in multiple search categories, including classes, packages or implementors:


Using a hashed word filters the search for the category name. In our case, adding #pa retrieves only the desired packages:


Posted by Tudor Girba at 23 April 2015, 10:27 pm with tags analysis, moose, pharo, analysis, spike link

Spotting objects from GTInspector

GTInspector enables fine-grained interaction with objects, but it is less tuned to quick searching within the context of the object. At the same time, GTSpotter allows you to quickly search for objects.

It is only natural to link the two. We already have a way to get from GTSpotter to GTInspector as the default action in GTSpotter is to inspect. For example, suppose you inspect a directory.


While, the inspector already allows you to navigate through folders, it is often more convenient to dive through the file system with GTSpotter. To achieve this, you would need to jump from inspector to spotter.

In our example, as the FileReference class already offers spotter extensions, the inspector offers a magnifier glass icon on the top right. Clicking that icon triggers an instance of GTSpotter that is scoped to our FileReference object.


From here, GTSpotter works as expected with full diving and previewing possibilities.


As the default action is inspection, pressing Enter on a file or directory opens an inspector on that object.


The integration is far from perfect. For example, at the end of the interaction you end up with two windows (one for the initial Playground, and one for the Inspector) without any casual connection between the two. Nevertheless, this is a cheap extension that allows you to leverage the power of GTSpotter for any object.

Posted by Tudor Girba at 16 March 2015, 9:05 am with tags tooling, moose, pharo, analysis link

Boosting GTSpotter with preview capabilities

GTSpotter is a novel search interface for spotting objects that we introduced a short while ago. It is part of the Glamorous Toolkit and it is now also available by default in the latest Pharo 4.0.

You trigger it with Shift+Enter and you search. For example, GTSpotter allows you to search through the file system. It looks like this:


Pressing Enter inspects the file. However, before pressing Enter it would be mighty useful to take a peak into that file, would it not? To this end, we introduced the Preview capability. Pressing Cmd+P toggles the preview. As we are looking at an st file, we even get code highlighting.


The preview of a picture file shows the picture.


And for a folder it shows its contents.


Obviously, these previews are not hardcoded in a central place. Instead, like in the case of the GTInspector, each object can decide how to be previewed. By default, the preview consists of the basic object structure.


By adding dedicated extension methods in desired classes allows you to customize the preview. For example, the below code shows how the source code preview of a CompiledMethod is being defined:

CompiledMethod>>spotterPreviewCodeIn: aComposite
     <spotterPreview: 10>
     aComposite pharoMethod
          title: [ self gtDisplayString ];
          display: [:compiledMethod |
               ' ', compiledMethod getSource];
          smalltalkClass: #methodClass;
          entity: self


Combining the preview ability with the diving option described in the previous post, opens new possibilities for GTSpotter. For example, besides fast file browsing, GTSpotter now also can replace the myriads of windows produced by Implementors/Senders/References. For example, in the picture below, searching for do: provides the list of implementors, and diving into a method shows more implementors and senders.


Let’s take another example: an often occurring need consists in finding previous loading scripts. Combining the search through the history of GTPlayground pages with the preview of a page provides a quick and convenient solution.


Adding preview increases dramatically the usefulness of the interface. It is now up to you to fine tune its behavior to fit your workflows.

Posted by Tudor Girba at 2 February 2015, 7:50 pm with tags tooling, moose, pharo, analysis link
<< 1 2 3 4 5 6 7 8 >>