We are very happy to make the following announcement:
Lam Research, a leading supplier of wafer fabrication equipment and services to the global semiconductor industry, is an experienced user of the Smalltalk programming language. Smalltalk is a key component in Lam's software control system for a broad range of the equipment it manufactures. Tudor Girba is a leading member of the tools and environment development effort in Pharo, having architected the Glamorous Toolkit for live programming. Eliot Miranda is author of the Cog virtual machine that underlies Pharo and other Smalltalk dialects.
Lam has engaged Tudor and Eliot to explore potential enhancements in Lam's use of Smalltalk. These enhancements range from running highly optimized Smalltalk on low cost, single board computers, to enhancing Lam's Smalltalk development practices with state-of-the-art live programming. During the engagement, Tudor and Eliot successfully moved a key communication component of the control system to Pharo. It was a challenging task aimed at extending the reach of Lam’s system to the Pharo world including the option of executing on ARM processors.
Tudor Girba, Eliot Miranda and Chris Thorgrimsson
We are happy to announce version 6.0 of the Moose Suite, the platform for software and data analysis built in Pharo:
The key highlights are:
- It is based on Pharo 5.0 including the latest version of the Glamorous Toolkit.
- Roassal2 comes with several enhancements.
- Famix features a new and generic query API engine.
- Moose Finder and GTInspector come with more custom presentations and visualizations.
- SmaCC comes with a dedicated debugger.
- The debuggers for Glamour, PetitParser and Announcements received a new update.
- DeepTraverser is an order of magnitude faster.
The Moose Suite 6.0 comes for each platform as a separate bundle:
The Moose Suite 6.0 can also be loaded in a Pharo 5.0 image either from the Configuration Browser, or by executing the following script:
smalltalkhubUser: 'Moose' project: 'Moose';
The Moose team
Over the last couple of weeks I worked on a new importer for Java code that can be used for Moose, and I am happy to announce that I released version 1.0.1.
jdt2famix is an open-source project, and the repository can be on Github. It is implemented in Java as a standalone project, and it is based on JDT Core (developed as part of the Eclipse project and available under the EPL2 license) and Fame for Java (originally developed by Adrian Kuhn and is available under the LGPL license).
The current implementation has an extensive coverage of entities that it can import, namely:
- classes, parameterizable classes, parameterized types, enums, anonymous classes, inner classes
- annotation types, annotation type attributes
- annotation instances, annotation instance attributes
- methods, constructors, class initializers
- parameters, local variables
- attributes, enum values
- invocations, constructor invocations, class instantiations
- thrown exceptions, caught exceptions, declared exceptions
- comments associated with named entities
- source anchors for named entities
The simplest way to use it is through the command line:
- Download and unzip the self contained binary 1.0.1 release.
- Go to the root folder where you have the sources and dependency libraries of a Java system (e.g.,
The result will be an MSE file having the same name as the name of the folder from which you executed the command (e.g.,
Let’s look at a concrete example. For this purpose, we pick the Maven project. We first download the 3.3.9 sources. These are only the plain sources, but to be able to import the complete model, we also need to have the dependencies available in the same folder.
As Maven is a Maven project (no pun intended), we can use the configuration to download the dependencies locally:
mvn dependency:copy-dependencies -DoutputDirectory=dependencies -DoverWriteSnapshots=true -DoverWriteReleases=false
(If you do not have a Maven project, you have to adapt this step and obtain the dependencies depending on the specifics of your project)
Then we simply execute:
And we get a
maven-3.3.9.mse file that we can load into Moose.
Over the past year, I conducted an informal study on how developers think about code reading. The study took the form of a dialogue that I have with software engineers. I had it in various forms with more than 1000 engineers.
The dialog goes like this:
Me: I help teams to not read code.
Engineer: Not to read code?
Engineer: Intriguing. What do you mean?
Me: Well. Do you agree if I say that you spend 50% or more of your time reading code?
Engineer: Hmm. Yes.
Me: Ok. When was the last time you talked about it?
Engineer: About what?
Me: About how you read code?
Engineer: Talk about reading code … I don’t remember … never?
Me: In fact, nobody really talks about it. Is it not strange that we are spending most of our budget on something we never talk about?
Engineer: Indeed. I never thought of it in this way …
Me: I think we have to start talking about it. If we would talk about it we would see that we do not really want to read code. We want to understand code.
Me: This means that reading is just the approach we employ. Yet, reading is the most manual way to retrieve information out of data. And our systems are just that: data. So, not only that code reading is expensive, it is also the least scalable approach.
Engineer: Hmm… so, what is the solution?
Me: The solution is to look at programmers at what they are: programmers. Their job is to automate someone else’s decision making and they can use exactly the skills they are paid for to improve their own decisions...
The amazing thing is that I encountered only minimal deviations from this dialogue regardless of the experience level, programming technology background, domain and even country of the interviewee.
GTSpotter is moldable. The default Pharo 5.0 image comes out-of-the-box with 122 distinct types of search processors. Understanding and controlling these processors is key for using Spotter to its full extent.
The first thing about it is to learn what these extensions mean. Each of these extensions is defined in a method, and the average size of such a method is 8.5 lines of code (including the header and the annotation line). In most cases, the code of the method is the best description of what they do.
Let’s take an example:
title: 'Instance methods';
allCandidates: [ self methods ];
itemName: [ :method | method selector ];
As this method is defined in
TClass, the search processor will get activated when Spotter will get to a class object. In this case, there will appear a search category that:
- will be entitled
- will be applied to
- will use the
method selector as textual description for the item, and
- will filter using a
Most Spotter extensions look like this. Once you know how to read one, you will understand most of the others.
While each search processor can be small and easy to understand in isolation, understanding the overall landscape of all extensions is another problem on its own. To make it easier to grasp what exists, there are several places to look at.
First, the Spotter help lists all extensions available in the image split by name of the corresponding classes. This is a useful entry point to get a quick overview.
However, if you look for live examples you can simply inspect GTSpotter, and you will get the list of all extensions.
These two tools can allow you to keep track of extensions. Keep in mind that the default start object when opening Spotter is an instance of
GTSpotter. Thus, to look only for the top level extensions, we can inspect this expression:
GTSpotter spotterExtendingMethods select: [ :each | each methodClass = GTSpotter ]
In the Moose image, this returns 25 extensions. But, what if you do not want all these extensions?
For this you can turn to the Settings Browser. Every extension in the image gets associated dynamically a setting element. Unchecking the setting will disable the corresponding extension. These settings can also be stored and loaded for use in further images like any other settings.
This mechanism can also be useful if you want to change the way a search works. For example, the top search for classes happens based on a substring filter strategy:
allCandidates: [ Smalltalk allClassesAndTraits ];
keyBinding: $b meta;
If you want to use a regular expression instead, you disable the default class search in the Settings Browser, and add another extension method in your own package with a regular expression filter:
allCandidates: [ Smalltalk allClassesAndTraits ];
keyBinding: $b meta;
Done. Now, you can search for classes using regular expressions. In the same way you can manage all other extensions.