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:
Pharo 4.0 is out.
One of the most prominent changes is the addition of the Glamorous Toolkit as part of the core distribution. Namely, Pharo ships with GTPlayground, GTInspector and GTSpotter.
These are not regular tools. Besides the interesting interaction features that they come with, these tools are moldable. They empower developers to extend them cheaply to match custom needs. And when we say cheap, we mean minutes cheap. In other words, we actually mean too cheap to matter. This is a major departure from traditional IDE concepts and we claim that moldable tools have a significant impact on development.
Ok, that is our claim. But, how could we communicate the importance and reach of these tools?
If moldability is a concept applicable and useful in many contexts, it should follow that it is also applicable and useful in many corners of the core Pharo system. Is it really so? Let's visualize this impact.
We start from the map of Pharo. The picture below shows a circular tree map of the Pharo classes nested in packages.
Of these, we highlight the classes that have at least on extension either for the GTInspector or for GTSpotter.
Given that not all classes in a package are equally important and used explicitly, it is often enough to extend the more prominent classes with custom inspection. Thus, as soon as one class is extended, we also highlight the package. The result can be seen below.
The full script that reproduces the above picture can be found here http://ws.stfx.eu/LYN3N20P3HFC (just paste the url in GTSpotter), and it can be run in Moose 5.1.
We have extensions in 112 classes spread in 45 packages (out of a total of 277 non-test packages). These are just the extensions that ship by default with Pharo. There exist other such extensions both for core classes or for domain specific classes that are packaged elsewhere.
Most of these extensions are simple presentations or search processors. While there are indeed some presentations that rely on more sophisticated visualization engines, it is not the fanciness of the presentation that is the most important. The power of the mechanism comes from the integration of these presentation in a continuous browsing or search workflow that opens new development possibilities. For example, the visualization from this post was created with the Roassal engine by using a playground and a preview in an embedded inspector.
Moldability is a far reaching concept, and we have only started to explore its possibilities.
Pharo 4.0 is here!
Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.
Many things have changed in Pharo. Here are some highlights:
- Inspector/Playground/Spotter are new moldable development tools for inspecting, coding and searching objects.
- Slots model instance variables as first class entities and enable meta-programming on this level.
- ShoreLine reporter introduces a way to report system errors and collect statistics, that we will use for future improvements
- Dark theme.
These are just the more prominent highlights, but the details are just as important. We have closed 1700 issues in Pharo 4. Take a moment to go through a more detailed recount of the progress: ChangeLogs.
Pharo is improving on many fronts, but one of the most prominent changes is the addition of moldable tools for inspection and search. These tools provide extension mechanisms that allow every object to define ways in which it can be understood effectively. To provide an idea of the impact of the already existing extensions, the map below shows the Pharo classes grouped in packages, highlighting in red those parts of the system that have at least one such custom view coming with the main distribution. The spread of these extensions shows that moldability is powerful mechanism that can be used in many contexts.
Remember that Pharo is your platform. We thank all the contributors of this release:
Clara Allende, Jean-Baptiste Arnaud, Jean-Christophe Bach, Philippe Back, Clement Bera, Alexandre Bergel, Torsten Bergmann, Vincent Blondeau, Noury Bouraqadi, Santiago Bragagnolo, Johan Brichau, Sven Van Caekenberghe, Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Andrei Chis, Ben Coman, Bernardo Contreras, Tommaso Dal Sasso, Jan Van De Sandt, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Stephane Ducasse, Stephan Eggermont, Luc Fabresse, Johan Fabry, Hilaire Fernandes, Jerome Garcia, Tudor Girba, Thierry Goubier, Jigyasa Grover, Kris Gybels, Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Pavel Krivanek, Juraj Kubelka, Jan Kurs, Laurent Laffont, Jannik Laval, Kevin Lanvin, Max Leske, David Lewis, Diego Lont, Esteban Lorenzano, Tim Mackinnon, Attila Magyar, Esteban Maringolo, Stefan Marr, Max Mattone, Martin Mc Clure, Eliot Miranda, Alain Plantec, Guillermo Polito, Damien Pollet, Stefan Reichhart, Mark Rizun, Udo Schneider, Ignacio Sniechowski, Henrik Sperre Johansen, Igor Stasenko, Aliaksei Syrel, Ciprian Teodorov, Camille Teruel, Sebastian Tleye, Yuriy Tymchuk, Peter Uhnak, Andres Valloud, Sven Van Caekenberghe, Thomas Vincent, Jan Vrany, Martin Walk, Richard Wettel, Dmitri Zagidulin
And all those who contributed indirectly, by reporting bugs, participating in discussion threads and providing feedback.
Pharo 4.0 is another big step. And, the best is yet to come.
The Pharo Team
String>>asClass is a scripting convenience method that looks up a class based on its name. While in scripts it can be tolerated, using it in production code is an anti-pattern.
Stephane recently pointed out that some classes already exist in Glamour that make use of #asClass. For example:
#GLMSystemWindowBrick asClassIfAbsent: [
^ self asMorph openInWindow ].
^ #GLMSystemWindowBrick asClass new
This code should clearly not exist, but this is not what this post is about. The question is, how can we quickly find out where is
String>>asClass used inside Glamour.
Let’s use Spotter. We start from finding the
We dive in (Cmd+RightArrow):
We see that there are 10 senders. To find those that are in Glamour, we simply filter by the
Quick and easy.