Monthly Archives: January 2017

Pharo 6 update catalog entries


in preparation of upcoming Pharo 6 release we already should do a pass on
all our external loadable projects:

– load them into Pharo 6 to see if they could be loaded cleanly
(due to automatic transformation of deprecated messages your packages
get dirty when converted)
– check if they are already/still working in Pharo 6 by using them
– check that the tests are running in Pharo 6
– check that we have a proper config with catalog methods and
that the latest config is in the MetaRepoForPharo60 repository!/~Pharo/MetaRepoForPharo60

I did a pass over most projects I implemented or contributed to
and we now have much more Pharo 6 based projects in catalog:

– Units, Artefact
– EventRecorder, Bugzilla, PunQlite, HubCap, VistaCursors, INIFile
– Pomodoro, DesktopManager, QuickAccess, WebBrowser, MessageFlowBrowser
– ScriptManager (now with icons)
– Tealight, Teapot, Nginx, NPMJS, GitHubAPI, FogBugz
– OSWindows, OSOSX, OSUnix, OSLinuxCentOS, OSLinuxUbuntu, OSRaspbian
– …

You should do the same with your projects!

Also if you have a project on SqueakSource, STHub or GitHub that
is not yet in the catalog it would be good to provide a ConfigurationOf…
with a catalog description. Using Versionner it is easy to create one
or generate the required catalog methods.

This would give more visibility to your projects!



I don’t know if there is an existing object reference crawler, but I ported mine from VW. It finds the shortest paths so it is good for finding the reference that is causing the memory leak.

location: ‘’
user: ”
password: ‘’

Once loaded, you can evaluate something like “ReferenceFinder findPathToInstanceOf: MyClass”. That will return a reference path or nil if no path exists from the Smalltalk global to an instance of MyClass. If you want to find a path to a particular instance, you can use “ReferenceFinder findPathTo: myInst”.

Consortium action 23/29 Jan


This is my weekly ChangeLog, from 23 January 2017 to 29 January 2017.
You can see it in a better format by going here:


27 January 2017:

*    I worked a bit with [iceberg]( Finally merged the branch +multi-remotes+
onto +0.4-dev+ just to realise immediately there is a [bug]( 😦

Anyway… this is at least partially solved so I will integrate it directly.

*    Fixed [case: 19592]( (PharoVM shown as Squeak Cog VM on Windows task Manager).

*    I worked with Clement to figure out why +supportsWriteBarrier+ was answering +false+ in windows builds.

Turns out it was a combined bug:

First, a problem in the VM and double castings (weird, isn’t?). This is already taken care by Clement.

Second (and this is ‘my’ side of the problem), PharoVM builds needed to include a couple of flags I was
not inclding:


with this two things fixed, now everything should be fine in Windows side. Curiously, even if the method
was answering false, the ‘write barrier’ was actually working 🙂

26 January 2017:

*    Spent some time verifying some issues with VM on Windows.

* Why +SqueakSSL+ is not working? [case: 19605]( This looks to be an invalid issue, since I cannot prove it (nor Torsten).
* Why +Smalltalk vm supportsWriteBarrier+ answers +false+ ? This is weird, since my own builds (which are the same) answers correctly +true+ . Anyway, I will try triggering a new build, and hope for the best.

*    I submited a fix for [case: 19315]( The patch contains both my workaround plus the fix suggested by Phil
(in a slightly different way)… yeah, I know this is redundant but I want to be sure this damn bug
is fixed for good 🙂

23 January 2017:

*    I made a small iteration on the new mail service over this thingy… now I export the log in my own
variation of the [AsciiDoc]( format.

I choose to do it like this because format is more legible (and +Pillar+ already has one exporter to it :P)

*    I added +AioPlugin+ to all linux distros (they will be available in latest VM).

As with SqueakSSL, I have no idea why it was missing 😛


More Enhancements for Pharo 60

19601 [Epicea] Epicea monitor is off by default

19600 [Epicea] OmNullReference shuld provide #globalName

19590 Integrate new Epicea release
19593 TClassDescription>>#isTestCase should be in SUnit-Core

19558 GtDebugger should not call #updateSelectionInterval in #updateBrowser

19596 move #outerMostContext to the KernelPackage

19597 move #definitionForNautilus &co. to the Kernel

19595 Protocol *GT-SpotterExtensions-Core-private in MCWorkingCopy should be moved to accessing

19594 isTestMethods &co. should be SUnit extensions, not part of Nautilus

19574 update BaselineOfIDE
19554 #~~ should be a primitive and a compile-time inlined selector to be consistent with #==

19573 more rigid ThemeIcons defaultUrl

19534 Unify Epicea UIs
19556 Glamour version 4.31

– fixes example GLMBasicExamples>>#morphWithCustomInteraction
– adds example GLMBasicExamples>>#changingTabsInComposite
– case 19505 Setting the selection using #initialize: does not work in a pharo script presentation.
– case 19504 Glamour should preserve the selection when updating a text presentation
– Put example browser into World / Help menu.
– better tests for the FT renderer in Glamour
– synchronize packages with Pharo
19570 QA 3.3.0

19557 GTDebugger should use FastTable in the object inspector for thisContext

19561 Drag&Drop FastTable Example Does Not Work

19536 “Instance variables not read and written” critique false positive on classes with certain slots

19559 GTMoldableDebugger>>updateBrowser should not call #update

19551 GLMPopper should accept cmd L shortcut to remote popup and cancel text changes

19552 Cancelling changes by cmd L should not request user confirmation

19565 QA v3.2.11
19548 Fix Spec Integration class comments and examples

19545 Add comment about OC translator subclasses (for effect / for value)

19555 Nautilus should sort all binary methods before non-binary methods

19550 Typo in settings: Popup notifaction –> Popup notification

19509 controling class assignment

19515 complileSilently:classified: method does not set properly the package

19217 Add printOn: method on WeakAnnouncementSubscription to improve readibility

19540 TabMorph should refresh content in background by defer message

19532 Improve TBehaviour >> lookupSelector:

19501 GlobalIdentifierTest leaves a file present in $data directory

19531 Latest GTTools integration broke the bootstrap
19521 localMethods should be moved to TBehavior where localSelectors methods are defined

19528 Split larger variable entries in the Variables menu into submenus

19529 Mouseover an empty submenu causes UI lockdown

19526 readString should check NULL condition

19520 Epicea: Tests lacking files cleanup

19514 ConfigurationOfFuel has no latest FuelTests version

19421 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions

19512 References to Tab -> should be TabMorph

18729 DNU on showing menu in CriticBrowser (code pane)

19491 ClassRemoved announced when it is not removed from superclass subclasses list

19490 ClassAdded should be announcer after notifying superclass about new subclass

19494 ClassModificationApplied is not announced when traitComposition of class or trait is changed
19493 Load new FastTable config

19488 STONWriterTests>>#testDictionaryWithComplexKeys is order dependent

19495 TabMorph should fork morph building in lesser priority than active process
19486 TabMorph helper method to prevent blinking when morph retrieval is too fast

19469 Debbuging Super call inside a debugger does not call the super method but the self one.

19306 taskbarIcon on class side should be defined only in Object class by using taskbarIconName redefined by subclasses

19479 Typo in name attribute of GRVariableAssignedLiteralRule

19478 Criticsbrowser shows a refactoring class name instead of the text diff

19438 Widen tolerance for DelayScheduler timing tests
19484 BaselineOfMorphic references unexisting class

19483 Add bootstrap specific code in Monticello

Consortium action 16/22 Jan

This is my weekly ChangeLog, from 16 January 2017 to 22 January 2017.
You can see it in a better format by going here:


20 January 2017:

* I’m still fixing a couple of final failing tests on iceberg,  multi-remotes branch. Problem is that there are still somethings to understand on the “command line  backend” (we need to find a better name for this), and the #pushTo: method: if I do it as I think is correct, a couple of failing tests appear… but then, I need to reflect if this is a problem on the functionality or on the tests.

19 January 2017:

* I think I finally got the problem with FT2Plugin!
Yesterday night talking in slack I realised that there was actually duplicated
instances of FT2Handle hierarchy with exactly same handle  (pointer address). This, of
course, causes a double free when those instances are released… and
that’s the VM crash 🙂
So I quickly sketched a workaround, that you can see here:
“This should only be sent from the finalizer.
It runs inside a mutex because in strange cases it can happen that this is
executed twice,
causing a primitiveFailed to be raised.”
self class destroyMutex critical: [ | handleToRelease |
self isValid ifFalse: [ ^self ].
handleToRelease := self handle copy.
self primDestroyHandle.
“This is super-ugly, but it will prevent duplicated handles to be released”
FT2Handle allSubInstancesDo: [ :each |
(handleToRelease = each handle) ifTrue: [ each beNull ] ] ]
and so far nobody who is testing it crashed!
This can be important, but of course… now we need to realise why the
duplicated instances are happening.
* I spent some time preparing a new way to annoy people 🙂
I prepared a way to send a digest mail about my activity (this stream) to
pharo-dev list.
I hope it will not be too much.

18 January 2017:

* … and still some more work on iceberg, this time making some test
pass on the command line backend (who is just a fallback, but well… we still
need it around).
* Still working on UFFI 64bits. Now I introduced a new hierarchy, FFIArchitecture
for now with two children:
* FFI_i386
* FFI_x86_64
the purpose is obvious: to allow UFFI to handle differences between different
architectures (for example,
long has to be parsed to FFIInt32 in i386 and to FFIInt64 in x86_64).

17 January 2017:

* I’m working on the UFFI support for 64bits.
In general, it works fine, but there is a huge problem with structures. What’s
this problem? Well, let’s take
this simple structure as example:
struct point {
unsigned long x;
unsigned long y;
Well, thing is in 32bits sizeof(struct point) = 8 while in 64bits sizeof(struct
point) = 16, and of
course this breaks our current implementation which would be something like this
^ handle unsignedLongAt: 1
^ handle unsignedLongAt: 5
and of course, this is not correct for 64bits.
My solution is quite simple, instead hardcoding the field offsets, I store those
values into class variables
that can be calculated each session (but just once).
So, this structure would end looking like this:
^ handle unsignedLongAt: OFFSET_X
^ handle unsignedLongAt: OFFSET_Y
this would solve the problem for most of the cases, but there is still the issue
that emerges when complete
implementation of the struct changes between platforms. I’m planning to
implement a strategy pattern to solve
this, but not yet (probably I will wait until having a concrete case).
This seems to be working, but now I have other problems not related to UFFI:
many people has implemented
void * parameters of funtions as unsigned long (including me, time ago) which
was correct in 32bits but
it is not in 64bits. So now I need to review this implementations to see where a
fix is needed.
But this is not directly a problem of UFFI, I think.
* I worked with Nico on fixing libgit2 backend tests for iceberg.
Now (more thanks to Nico than me, heh), test for multi-remotes branch are
passing for linux but still not for macOS (and forget it about Pharo 5.0).
I suspect a problem with VM, I need to review if I can configure smalltalkci
to work with latest vm instead stable.

15 January 2017:

* … and now I restored the posix permissions to windows platform. Next latest VM
will have this change, I hope that will end the problems with FilePlugin, but we’ll see.
* I just fixed a problem with FilePlugin on macOS: the problem was when
determining if a symlink is also a
‘/tmp’ asFileReference isDirectory
was answering false, because it is a symlink and when trying to resolve the
symlink to obtain the
attributes, there was a cyclic condition that was transforming ‘/tmp’ into
‘/private/tmp’ and then
back to ‘/tmp’, and because of that the test for directory was failing.


Pharo by Example 50 Released!

Dear book readers, Pharoers and others

I would like to announce the release of the PDF  version of the new edition of Pharo by Example. Pharo by Example has been adapted to Pharo 50. The printed version is under checking.

I would like to thank Dmitri Zagidulin, Nicolai Hess and Dimitris Chloupis (especially for the cover) for their help. Now Pharo by Example is available in the Pillar format so this means that we will soon publish an HTML version. I want to thanks Damien Cassou, Cyril Ferlicot, Yann and Thibault for their work on Pillar.

The PDF version benefits from a really cool design made by Damien Pollet.


Doing is more difficult that talking, but at the end you have something in your hands 🙂


Pharo is string-safe :)

This might be interesting to some people for testing purposes. You all heard stories how certain input caused certain systems to crash. Here is someone who collected lots of these strings.

Big List of Naughty Strings

Luckily, Pharo can at least read them all in, without problems, as far as I can see.‘ asUrl retrieveContents lines.


PS: You won’t see all the weird/exotic Unicode characters (choosing a different font like Arial Unicode MS shows a lot more).

Pharo deployed with Snapcraft

Hi all,

Just wanted to share this:
It is basically the code to generate a snap package of the pharo-vm using snapcraft. Using this, the VM is generated and packaged with all dependencies. This should help in running pharo in different linux distributions.
I invite you to check it, report problems and submit fixes.

A little expression interpreter

I released a version of a little expression interpreter for the new book: Object-oriented programming and design with Pharo.

Typos are welcome as pull requests.


Under the cover of the bootstrap

Guillermo P. one of the lead bootstrapper with Pavel. K and C. Demarey explained the under the cover decisions made around the Pharo 7.0 bootstrap…

Is there a scope and purpose statement for the bootstrap somewhere?

Not writen that I know of. Maybe we should do it. But from many discussions here in the team I’d define the pharo bootstrap as a pharo environment that is
– minimal (in the sense that it keeps only stuff required to run)
– clean (in the sense that there is the less dead code and dead dependencies as possible)
– and is able to grow (in the sense that you can install new code on it). Think that Pharo is not just the bootstrap. People will not accept a Pharo without a development environment, without a debugger or a workspace.

These three points are a long term goal I woud say, and particularly the last point is in big conflict with the first one. You can have an image that executes code but has no compiler for example.
So making a trade-off but always going towards that goal, what we decided with Christophe one year and a half ago to:

– select a minimal set of packages that would belong to the bootstrap image
* To run, you need the Kernel.
* To be able to install new code you need some kind of I/O and some way to transform the input as classes/methods. Thus we chose to put also basic command line handlers, files, and the compiler. We discussed about putting a flavour of Fuel (say Tanker) instead of the compiler, but Tanker was not stable as it was only experimental and nobody used it for real; the compiler was much more stable as we use it everyday; and besides, Tanker was depending on the class builder, so it only allowed us to remove the compiler but not the class builder.
* To be clean, we started looking at the dependencies of those packages.
– We finished in a selection of about 53 packages. Remember that Pharo itself has nowadays around 464 packages…
RPackageOrganizer default packages size “464”
So this was as good as a ~10% of the original image. Good enough to have a first version.

– And we started working on dependency analyses on them. The following report made by Christophe lists all the bootstrap packages and their dependencies, and reports when a new dependency is introduced.

See what the dependency graph looks of the bootstrap

and extrapolate to the entire image :).
And that, after we worked a LOT to cut off/separate/untangle/decouple those 53 packages from the rest, rewrite parts of the system (a big example of it is the SessionManager).
Now, this is of course not the end. There are still lots of things to do.

– the kernel can be still cleaned up even more
– we could implement some sort of binary serializer specialized for classes and methods to shrink even more the bootstrap
– the rest of the image has still to be cleaned. Nowadays on top of the bootstrap Monticello and Metacello are bootstrapped using manual a approach and afterwards, the rest of the image is loaded by using a Baseline

That baseline can be enhanced, splitted in smaller baselines. This require non-bootstrap packages to be revisited, have checked their dependencies and so on…

So what you see in that list is the result of several decisions and a lot of work. And the focus was to release something and not die in the process. Hope that answers the question (I will copy past this and put it into some wiki btw)