Git: keeping your repo in sync

Another really nice blog post around pharo and git

We want more ūüôā

How to contribute to Pharo 70


Here is a nice tutorial explaining how to contribute to Pharo 70.


[Pharo 70 alpha] Integration log restarts


We do not have yet an automated mail after each integration. So I will
do it by hand.¬†I’m going over the green issues that you can see here:

You can comments them in

Here are the current integration items

[Pharo 70] Build 23 / PR 132

[Pharo 70] Build 22 / PR 169

[Pharo 70] Build 21 / PR 187

[Pharo 70] build 19 / PR-168

[Pharo 70] Build 18 / PR 66

[Pharo 70] Build 17 / PR 185

Moldable brick editor – alpha


We are very happy to announce the alpha version of a moldable editor built in Brick ( which is based on Bloc ( This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors.

Take a look at this 2 min video:

The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters.

The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260  lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor.

Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area.

The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure ( is theoretically thread-safe, but it still needs to be proven in practice.

We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector.


This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable.

We will continue the work on this over the next period and we expect to announce new developments soon.

If you want to play with it, you can load the code like this (works in both Pharo 6 and 7):
Iceberg enableMetacelloIntegration: true.
Metacello new
load: #development

Please let us know what you think.

Alex and Doru

Live coding Survey

Dear Pharoers,

Live programming frees developers from the “edit-compile-run” loop and allows people to interact with running programs very easily. Live programming is getting popular, but many of its features have been present in Smalltalk for a very long time.

We want to understand how Smalltalk software developers use live programming features in practice. We would be grateful if you could participate in our 10-minute survey on this subject:

As a thank you for your participation, you will be able to participate in a raffle to win a Smalltalk book of your choice. If you wish to participate, you will need to share your email with us, so that we can contact you.

We will appreciate if you share the survey
By participating in the survey you will:
–¬†help me to successfully finish my PhD,
– push Smalltalk awareness in Live Programming research community,
– bring new integrated electronic communication ideas, and
– bring new ideas to improve our Smalltalk Live Programming experience ūüôā
We will close the survey on Wednesday, August 9, 2017 AoE.

Thank you and we really hope you enjoy participating in our survey!
Juraj Kubelka, PhD Student at the University of Chile
Romain Robbes, Professor at Free University of Bozen-Bolzano
Alexandre Bergel, Professor at the University of Chile

Another supercool enhancement in bootstrap

we are checking a huge pull request #177 ( that will change some basics of the bootstrap process:
Now we will bootstrap a smaller image that will not include compiler/parser. Compiler and related packages are exported and loaded using a binary exporter named Hermes.
The compiler is then used to load FileSystem and Monticello. The rest of the bootstrap process will be the same as before.
As the result we will have faster bootstrap and better system modularization and possibilities.
It required some modularization efforts:
– simplified initialization scripts
– Use Zinc converters and encoders instead of FilePathEncoder and old TextConverter
– Use Stdio instead of FileStream
– Using File instead of FileSystem
– Deprecated FileStream & childs (Moved to Deprecated70)
– Extracted Path classes to their on package: FileSystem-Path
– Moved OpalEncoders to their own package. They are required by the runtime (not only for compilation)
– Introduced AsciiCharset in the kernel to answer to #isLetter #isUppercase and so on without requiring full Unicode tables from the beginning
– Cleaning up a bit the full exception logging infrastructure (streams, transcript, files, stack printing…)
– Split Ring methods required for system navigation to the Ring-Navigation package
– Remove usages of #translated in the kernel
– Refactored the bootstrapping classes to remove duplications
– Cleaning up dependencies in CompiledMethod>>printOn:
– fix path printing
We need to merge these changes at once and of course it can cause some conflicts with the existing pull requests or external code. Anyway, we need to merge it as soon as possible.
So please, try to look at the PR and test the resultant image [1] to avoid some major problems.
— Pavel

How to publish github managed project to Pharo Catalog

Hi Norbert,

I manage some of my projects already in GitHub. For example Tealight which is also in catalog.

Anything you have to do is
1) to create a “tag” in git¬† (see¬†, I name the tags with the according version number like 0.0.2 following semantic versioning (
2) provide a ConfigurationOf (as you had in the past) where the “version” references the “git tag” with the same name
a) also #stable has to point to the “version” as it was in the past
optional:  b) the #development should point to the Baseline in the git branch that you typically use for development (this allows for loading of bleeding edge as before)
3) upload the Configuration to a MetaRepo as before to appear in catalog

1) I have two tagged versions for Tealight on Git (0.0.1 and 0.0.2)

2) In my ConfigurationOfTealight (which I also manage in git) I reference the tag, for example in version 0.0.2 I reference the tag with the same name “github://astares/Tealight:0.0.2/repository”:

Side note: a) now you can use your #stable definition in the ConfigurationOf as before
b) Your #development definition should point to the master branch (or whatever the development branch is)


Iceberg is managed in a similar way (but is now included in the image and the catalog part is only for compatibility).

Hope this helps.


Pharo 6.1 (summer) released!

We are releasing Pharo 6.1.
Usually, between each major version we just apply bugfixes changing the build number and not announcing new versions but this time is different since the fixes applied required a new VM.
The principal reason for the new version is to update Iceberg support, bringing it to macOS 64bits version.
So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes:
– running on macOS 64bits
– adds cherry pick
– adds major improvements on performance for big repositories
– adds pull request review plugin
– repositories browser: group branches by remote
– adds bitbucket and gitlab to recognised providers on metacello integration
– uses libgit v0.25.1 as backend
– several bugfixes
Other important change:
– linux vm by default is now vm threaded heartbeat.
We still miss 64bits Windows (sorry for that), but we are getting there. I hope to have it running right after ESUG.
To download 6.1 version, you can go to page, or with zeroconf:
wget -O- | bash

System Monitoring Images & Nagios

I just made it nagios compatible. I developed it because I’m using munin [1]. You can look at this [2] blog post how to do it. If you have questions just ask.