Monthly Archives: April 2017

20000 issues mark in FogBugz :)


our community today hit the 20000 issues mark in FogBugz.

And a good change to once again say THANK YOU, especially to the ones who care most on

– updating the bug tracker
– fixing issues
– reviewing issues
– integrating issues
– doing also the boring tasks in caring about the bugtracker
– pushing Pharo in the right direction

Just wow and impressive! Pharo 6 will be another nice milestone in a lively open source
Smalltalk system that we all wanted to see becoming a reality!

Torsten Bergmann <>

Smalltalk jobs in Germany

Dear Pharoers
For our business unit Pension Management we are currently looking for a
Software-Developer (m/w) About us
Collogia Unternehmensberatung AG is based in Cologne (Germany) and focused on IT-Consulting and software development. Since 1979 we successfully carry out projects and maintain IT-systems for the banking and insurance branch, public organisations or companies in all industries. Our competence centers are SAP-Consulting, Project management, IT-Services und Pension-Management.
The business unit „Pension Management“ is specialised on pension administration and actuarial services. CollPhir® (http://http://www.collphir.deis an in-house development. CollPhir® is an administration system for pension funds and other company pension solutions.
Your Profile
• Successfully completed study of computer
science, mathematics oder a comparable quali cation
• Profound knowledge in object-oriented soft- ware development, software engineering, e.g. methods, technologies, process design, data modeling, OOA/OOD, UML
• Experience with project management
• Team-oriented and working in a structured,
systematic and deadline-focused way
• Good knowledge with MS-Office
• Working language is German, therefore a very good knowledge of the German language (written/spoken) is needed
Your Tasks
• Development of high quality Client/Server-Software based on Visual Works Smalltalk
• Technological evolution of our in- house development CollPhir® (
• Development of functional and technical speci cations based on the analysis and requirements of our clients
• Consulting of our clients in requests regarding information technology
• Technical support CollPhir®
Your Benefits
• Inviting projects
• Attrractive workplace
• Mentoring
• Targeted training
• Fexible working hours model
• Attractive salary model
Contact Dr. Michael Höhnerbach
CEO Pension Management E-Mail:
Ubierring 11 • 50678 Köln Web: |

Gathering statistics on messages sent to an object

If you subscribe to pharo-dev you will have seen that I’ve been looking
at the primitives used in DiskStore.

As part of that investigation I wanted to get an idea of which messages
are typically sent to DiskStore and how often.

Denis Kudriashov provided a neat package that implements a “halt on
next object call”.  I’ve been wanting to play with the package for a
while and decided this was a good opportunity.

I’ve extended that package to keep count of how many times messages are
sent to a target object, e.g.:

| point trace |

point := 2@3.
trace := ExternalSendStats logStatsFor: point.
trace stats.
“a Dictionary(
#y->1 )”

The package is probably too simplistic, and there’s bound to be other
ways to do this, but it met my immediate needs and gave me a chance to
try out the Ghost package.  I’ll extend it if and when I need to.

Many thanks to Denis for making the Ghost package available, and
hopefully this is useful for someone, or at least triggers some new

Denis’ original article is at:

The extensions can be installed with:

Metacello new
baseline: ‘AkgGhost’;
repository: ‘github://akgrant43/akg-ghost:master/mc’;



Hi Alistair.

Do you know that you are able to count any message send? (not only external).
For this you need prevent meta recursion. Now inside message processing you do:
aMessage sendTo: anObject

which produces another intercepting message #perform:withArguments which repeats original message send.

Fortunately Ghost handles such kind of meta recursion and there is no infinite loop here: any self-sends are ignored in such cases.
If you want intercept any message try following code:
ExternalSendTrace>>send: aMessage to: anObject
| method |
announcer announce: (ExternalSendAnnouncement message: aMessage trace: self).
method := anObject class lookupSelector: aMessage selector.
^GHMetaMessages executeWith: anObject andArguments: aMessage arguments method: method
In that case we lookup and execute method by using mirror primitive which not sends any message to object.
For example:
rect := 10@30 corner: 100@300.
trace := ExternalSendStats logStatsFor: rect.
rect area.
trace stats.
 “a Dictionary(#area->1 #height->1 #width->1 )”
Best regards,

Pharo Sprint App to improve coordination during Pharo Sprint


We are happy to announce a new application called Pharo Sprint App. The main idea of the application comes from the whiteboard that have been used during Pharo Sprints and was also adopted in Chile.
As the Pharo Sprint is organized in several places around the world, we miss the connection with other guys. For that reason we decided to move the physical whiteboard to the internet and developed Pharo Sprint App.
How does it work? Participants choose a case from the ‘proposed’ or ‘all’ list. Once they are done, they move it to the ‘done’ list. We believe that the application will encourage other people, especially newcomers, to join us during the events and have a fun, together with other developers.
How To Use It?
• Execute the image, using the corresponding VM for Pharo 6
• Run the application from World Menu / Communication / Pharo Sprint
• Login, using your FogBugz account, wait a bit, then choose a case and have a happy programming 🙂

Everybody participating in the sprints should use the Pharo Sprint image.

The upcoming event is on Friday April 28
The application is deployed in Pharo 6 (32 and 64bits). More details are available at:
I will appreciate any feedback.
Have a fun! 🙂

Snap package for Pharo 6

Hi Everyone,

I’ve made a snap package for Pharo 6 which I think is far enough along
for some wider testing.

To get Pharo up and running on Ubuntu 16.04:

# Install Pharo
$ sudo snap install –edge pharo –classic
# If your system isn’t configured for threaded heartbeat:
$ sudo pharo.config
# Download the latest Pharo 6 image
$ pharo.getimage
# Go…
$ pharo.ui Pharo.image
# or:
$ pharo Pharo.image eval 4+3

To get a list of available commands:

$ snap info pharo

If you’re on Debian or Ubuntu 14.04 you’ll need to install snapd, see

The VM is the threaded heartbeat, dated 201704101933.

The installation flags are:

–edge – The edge channel is for development versions.  It
progresses to beta, candidate and then stable.
–classic – Snap packages are normally sandboxed for security
reasons.  Since Pharo is a development environment
in which we want to be able to run any executable,
or load any library, it is installed with access to
the entire system (as the running user).

Why use snap packages?

– They include all dependencies.  In particular, for the 32 bit
versions, this means that it isn’t necessary to install all the 32 bit
architecture and associated dependencies.
– Including dependencies means that there shouldn’t be any problems with
incompatible library versions when upgrading.

Why not use snap packages?

– It’s a relatively new technology, with a number of rough edges.
– There may still be issues with its sandboxing that I haven’t
discovered yet.
– Please let me know of any others to be listed here.
– Because the package uses classic confinement, it isn’t
cross-distribution in practice (unfortunately).

If you don’t trust me to configure your system correctly (which requires

– All the scripts that make up the sub-commands are visible, e.g.
pharo.config can be viewed at /snap/pharo/current/usr/bin/CONFIG

The packaging code is at:

I’m interested to know if people would like to see this eventually
become a supported package format.


64 bits call for tests

Hello list,

We are approaching to release and one big thing of this one is the 64bits supports for Pharo (limited, since there is still not support for Windows, but it will arrive, eventually 😉 )
I asked you to test a couple of months ago but now we are in better shape to do it.
– VM and image are getting more and more stable and crashes shouldn’t happen (but that’s why I want you to test: to discover possible bugs/crashes)
– I made 64bits a zeroconf citizen:
Now, you can test it by just doing:
curl | bash
(In linux or mac, remember it will not work for Windows)

[Consortium] 3-9 April 2017


This is my weekly ChangeLog, from 3 April 2017 to 9 April 2017.
You can see it in a better format by going here:


7 April 2017:

*    Fixed the small but annoying [issue 323](
(DNU when creating a local repository )

*    Today I’m working on [Iceberg](

I fixed a bug on locating existing repositories for +gitlocal:+ Metacello protocol, but most amusing,
I added a new plugin: “Install Baseline”, who allows you to install a project from a baseline listed in
“Packages” tab from repositories browser.

6 April 2017:

*    I worked a lot preparing the new deployment model for VMs.

Basically, now it will be like this:

* nightly builds will be still built by our CI (to produce test VMs)
* latest VMs will be produced on opensmalltalk-vm, using blessed sources.
* stable VMs will be promoted by me 🙂

I’m thinking on change a bit this scheme, but for now it will work like that.

I finisged the [OpenSmalltalk]( part, now I need to adapt
also [Pharo-Project]( (tomorrow).

Then, we still need to fix one problem with a primitive… and we will be good to go.

*    I worked on [case: 19921](, to allow Athens to run fine on 64bits (linux).

5 April 2017:

*    I worked on +UnifiedFFI+, making sure different architectures of linux (i386, x86_64) will have methods to
find their libraries.

In particular, I added: +#unix32ModuleName+ and +#unix64ModuleName+. Both are redirecting to
+#unixModuleName+ by default as a way to provide backward compatibility (also, libraries could)
be in same place in different architectures, like the case of libraries distributed by ourselves
(libgit2, libssl, libssh2, libsdl2).

4 April 2017:

*    I made some fixes on [Iceberg]( in particular, this two issues:

* [Issue 317](, which adds the posibility of removing a package from FileSystem.
* [Issue 319](, forcing unix line endings to commit messages (as is required by git).

*    I fixed a problem when building the VM for Windows: thing is, as it was, it was building cairo library without
freetype support, so frameworks like Roassal to fail.

Problem was that pkgconfig was failing to find correct version of +freetype+ effectively letting it outside.

I needed to change the build script (for Windows) to this:

cd $(CAIRODIR) \
&& ./configure \
–host=i686-w64-mingw32 \
–disable-silent-rules \
–disable-xlib \
–disable-dependency-tracking \
&& sed -i ‘/.* sh .\/make-/i\\ttest -e \$$\@ \&\& rm \$$\@’ test/Makefile \
&& make \
&& make install

Now averything seems working.


New Success story: iPOS

A new success story on an integrate Point Of Sales.



Commander library


I am glad to announce Commander library which implements command pattern based on first class objects.
In Commander every application action is implemented as separate class with #execute method and all state required for execution.
Commands are reusable objects and applications provide various ways to access them: shortcuts, context menu, buttons, etc.. This information is attached to command classes as activator objects. Currently there are three types of activators:
– CmdShortcutCommandActivator
– CmdContextMenuCommandActivator
– CmdDragAndDropCommandActivator
Activators are declared in command class side methods marked with pragma #commandActivator. For example following method will allow RenamePackageCommand to be executed by shortcut in possible system browser:
RenamePackageCommand class>>packageBrowserShortcutActivator
      ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext
And for context menu it will be:
RenamePackageCommand class>>packageBrowserMenuActivator
       ^CmdContextMenuCommandActivator byRootGroupItemFor: PackageBrowserContext
Activators are always declared with application context where they can be applied (PackageBrowserContext in example). Application should provide such contexts with information about application state. Every widget can bring own context to interact with application as separate tool. For example system browser shows multiple panes which provide package context, class context and method context. And depending on context browser shows different menu and provides different shortcuts.
Best regards,

Registration to PharoDays

The registration for pharo days is now open