Glamorous Toolkit v0.6.42
New native windows backend. Class Coder. Extended parsing support.
Glamorous Toolkit v.0.6.42 brings with it a new native window backend for Mac, an initial Class Coder, extended parsing support, stability throughout the board and in particular in the debugging department, and a few other things.
New native window support
The initial native window support we announced two months ago felt great both due to separate windows and due to the retina display support. So, we went further and explored a new solution based on the Glutin library. Beside proving to be more stable, it also brings new abilities such as the possibility of having transparent windows.
It currently works reliably on Mac.
Coder
For most of the existence of the Glamorous Toolkit project, the prominent part was the moldable way to view software. Over the past few months we worked intensively on applying the same principles on the way to create software, too. We call the overall project Coder.
Coder is made of multiple pieces, some of which have been seen before. At the core, we have the Source Coder, with several flavors including the Method Coder for editing a single method. These pieces can then be assembled in larger pieces such as a query tool:
or a Class Coder. For example, below we see such a Coder opened on the GtMethodCoder class: on top you see a pane-based navigation view which can hidden or changed to a tree representation, and below we see a Class Coder for the selected class made of multiple Method Coders.
As we are still in an alpha state, the concrete interface of the Coder is still under development, but this initial effort already shows that we are close to providing a complete development experience.
Expanded parsing support
Glamorous Toolkit ships with two distinct parsing technologies. Why? Because of two reasons. First, parsing needs are pervasive during development, and developers deserve more than just regex. Second, Glamorous Toolkit is a platform with which to construct system specific environments, and this also implies dealing with multiple languages.
SmaCC, the Smalltalk Compiler-Compiler originally developed by John Brant, received new browsing and debugging support. SmaCC relies on its own language to express the parser productions, and the productions can also be extended with Pharo code. To this end, we worked on producing an editing experience similar to the one of the Class Coder. This is quite relevant in that it shows we can now edit a second language with the same experience as the one for Pharo.
And, we went ahead and spent some time on making debugging SmaCC parsers more accessible … and fun. So, now you can test a specific production against a input string and see the matching productions unfolding live.
PetitParser2, developed by Jan Kurš , is the second parsing engine that we ship in Glamorous Toolkit (this is the second incarnation of the original PetitParser built by Lukas Renggli). Why two engines? They are simply useful in different contexts. While SmaCC provides support for creating static parsers, PetitParser offers the possibility of defining dynamic parsers.
In this case, too, we wanted to have explicit support in the development environment. As a parser is expressed as Pharo code, we molded Coder to adapt to the specifics of PetitParser. In particular, PP2CompositeNode, the typical root class to inherit from when defining a custom parser, defines a caching mechanism: a parser is created in a method, and automagically cached in an instance variable with the same name. In this way, the programmer only has to define a sub-parser in a method and refer to that sub-parser through the instance variable and the magic does the rest. So, Coder makes the references to those instance variables expand to reveal the implementing method:
We also extended the inspector with dedicated views. For example, below we have a new browser of a parser that complements a graphical notation with quick navigation.
Profiling from Playground
On another note, we also added an initial support for profiling code right in the Playground. It’s implemented as a set of inspector extensions over the existing MessageTally infrastructure.
Improved text and documentation look
We worked on the fonts we use and on how we use them.
And on refining Documenter. Because details matter.
A more detailed list of changes can be found at: https://github.com/feenkcom/gtoolkit/milestone/4?closed=1
Have fun,
