Today I looked at getting Glamour and Torch working in Pharo 3.0
- ConfigurationOfMondrian refers to a stable version of ProfStef, which isn't defined for 3.0
- GLMUITheme has UThemeWatery2 as ancestor, which is removed. UIThemeWatery works fine
- RectangleMorph behavior was moved to BorderedMorph, so GLMPaneScroller needs a different
- old version of Grease-Pharo-Core is loaded, using BlockContext (refering to squeaksource instead
With those changes, most browsers work. GLMBasicExamples open works, most examples work.
Action List -> Inspect has a problem.
(ConfigurationOfTorch project version: '1.4') load
should refer to smalltalkhub
refers to an older version of ConfigurationOfGlamour
AST changes seem to be substantial. Changes needed in TCParser?
I have this issue:
- I have a moose metamodel model;
- I need to get data from the remote location
- I’d like to generate model based on metadescription and serialise it to MSE on remote location
- and then load it into the moose to do analysis
I don’t want to put all Moose at the remote location just to generate a model and serialise it.
I know that Hapax possibly isn't fully ported to Pharo, but running
the Hapax tests causes my Moose 4.5 image to hang (I've loaded
everything in the SqS Hapax repository). What image and package
loading order should one use to load Hapax? I'm interested in the
information retrieval part for natural language analysis, could that
part be repackaged in its own package?
I want to integrate Hismo into my model. I’ve checked Modeling History to Understand Software Evolution and looked inside a Moose image, but it will be still nice to see some guide about integrating Hismo into your model. If you have some knowledge - please let me know.
the contents say:
This distribution was built October 29, 2013.
Probably should say 4.9, right?
Also, I find it interesting that the package-cache has the Athens and font
MCZ files in it - was that intentional?
Finally, in the pharo-vm subdirectory, the PharoV10.sources are present.
Which really isn't needed - the PharoV20.sources are in the main directory.
So, this is just another 3.8MB of compressed file that gets passed around.
I'm looking at the moose_suite_4_9-win.zip version of the release.
Not really a complaint, just a set of observations.
Now, off to play with the new version (for a while, before jumping on Moose
We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow
tests but they needed attention anyway). It took about 4 people looking
into issues for a total probably around 2 man-days of effort. The largest
impediment was actually SmalltalkHub being down for one day :).
What posed problems:
- RB visitor now has correct visit* methods instead of accept* methods. The
deprecation messages helped quite a bit. This meant (1) that we had to
rename in our visitors the methods, and (2) that we had to change the old
- RB nodes do not answer to #isLiteral anymore. Instead, they answer
correctly to #isLiteralNode so that to avoid confusion with
Object>>#isLiteral. This is good, and this meant that we had to hunt all
#isLiteral usages in Moose.
- Categories are no longer mapped on RPackages through 1-to-1. This is also
good because it is an important step in Pharo. Although originally we said
we want to keep 1-to-1, this is probably a better solution now. For Moose,
this meant that some of our older tests setup had to be modified a bit to
rely on RPackage only.
- Some Morphs rely now on Announcements, and this had a little impact on
the assumptions we make when we suspend announcements (to avoid infinite
loops) that are being sent between Morphic and Glamour. We fixed this in
- In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory
without a deprecation. For this one, we should add a deprecation for the
- flatCollect had a conflicting behavior in Pharo. We are now integrating
the Moose version so that it returns the same species.
- The new SpecDebugger expects the registered Inspector to be based on
Spec, and this causes problems with the GTInspector. This problem still has
to be fixed in Pharo.
All in all, we encountered no significant problems and the problems we
faced came from deep into Pharo. So, if your code is not relying directly
on RB, RPackage or the Debugger, you are likely to have a smooth transition.
"Every thing has its own flow"