A few days of vacation for me usually means a time to relax, recharge a bit, do things with the family, catch up on TODO items, and play with new tech I’ve been meaning to play with or make progress on projects of my own.
Today I experimented with GToolkit a moldable software analysis framework built on top of Pharo Smalltalk. What I really want is a set of tools to analyze large codebases AND (as is in vogue right now) something that can scale up to be “IntelliJ but for microservices”. Maybe GToolkit is that tool, maybe not.
When I first started playing with Pharo a couple years ago I was frustrated a bit with “what do I do now?” and “where do I put my stuff?“. Took me a while to figure it out (create new classes using the browser, activate them with either the playground, add them to the menu, or use the example runner functionality).
GToolkit feels like the same thing to me, but different. Except I plan on using GToolkit for software analysis done using code, not just my own developer productivity tools.
When you boot up GToolkit you see the Coder/Playground; Git analysis (a repo / diff browser not just for Smalltalk code); Morphic World (an escape hatch into Pharo). There’s a lot of additional power buried in GToolkit and finding it and using it is sometimes not obvious.
But I found GtDocumenter, GToolkit’s Jupyter notebook notebook style interface
GtDocumenter texts are written in Pillar, with a nice interface for displaying, executing and saving. It looks like:
So my next question was: “Given I want to store my analysis in files in the file system, how do I interact with them?“.
I don’t yet understand how or where to store my analysis for the long term in GToolkit, so right now in folders they go. But it’s not a simple matter of File -> New Document -> GtDocumenter.
Run this in a playground
ui := BrFileSelectOrCreate new.
ui okAction: [:baz | |bfr|
bfr := baz asFileReference.
(GtDocumenter forFile:brf) inspect.
ui. "HIT THE INSPECT BUTTON".
When you select or create a new file GToolkit will create a new window with the GtDocumenter all set up.
I got a number of hints by looking around the GToolkit Smalltalk image and searching the GToolkit Discord server.
GtDocumenter is also used for Smalltalk class comments
In Pharo / Smalltalk there’s a place for methods, class comments, and a calculated place for references. GtDocumenter is used for class comments - in more sustained projects one could create a class (using GToolkit’s Coder tool) and keep your analysis document in there. This is a relatively centralized place: keep the human analysis document close to your class which probably holds small methods you use in your analysis document.
Probably long term I’d move to this approach, but for now since I have PlantUML files, Graphviz documents, Word documents (Microsoft shop), Powerpoint presentations etc on my file system .pillar files in the file sysitem too might just outweigh the more native “everything’s in the image” of Smalltalk philosophy.
I need to learn more about how to completely mold my GToolkit development environment. I’m sure I’ll learn and experiment more in the coming months and years (there’s apparently some nice Jenkins exploration tools buried in there, helpful as my work sometimes includes helping oddball Jenkins build problems). For now being able to load executable documentation into the environment will get me a long way.