Planet Squeak

blogs about Squeak, Pharo, Croquet and family
planet squeak - planet squeak es - planet squeak jp - planet croquet - planet squeak code - planet smalltalk

May 26, 2020

Gilad Bracha

Bits of History, Words of Advice

"Why do you jackasses use these inferior linguistic vehicles when we have something here that’s so
precious, so elegant, which gives me so much pleasure? How can you be so blind and so foolish?"
That debate you’ll never win, and I don’t think you ought to try.

- Alan Perlis, 1978

In the late 1970s, researchers at Xerox Parc invented modern computing.  Of course, there were others
elsewhere - but Parc made a vastly disproportionate contribution.

A large part of that was done in, and based upon, the Smalltalk programming language. Forty years
ago, Smalltalk's dynamic update and reflection capabilities were more advanced than in any
mainstream language today. The language leveraged those capabilities to provide an IDE that in
many ways still puts the eclipses, black holes, red dwarfs and other travesties that currently
masquerade under that term to shame.  The Smalltalk image provided a much better Docker than

Smalltalk and Smalltalkers invented not only IDEs, but window systems and their related paraphernalia
(pop-up menus, scroll bars, the bit-blt primitives that make them possible) as well as GUI builders,
unit testing, refactoring and agile development (ok, so nobody's perfect).

And yet, today Smalltalk is relegated to a small niche of true believers.  Whenever two or more
Smalltalkers gather over drinks, the question is debated: Why? 

The answer is unknowable, since we cannot run parallel universes and tweak things to see which
makes a difference

 I did describe such an alternate universe in a talk in 2016; it may be the best talk I ever gave.

Nevertheless, I think we can learn something from looking into this question. I'll relate parts of history
that I deem relevant, as I know them. I'm sure there are inaccuracies in the account below.
There are certainly people who were closer to the history than I.  My hope is that they'll expand on my
comments and correct me as needed. I'm sure I'll be yelled at for some of this. See if I care.

On with the show.

Lack of a Standard. Smalltalk had (and still has) multiple implementations - more so than much
more widely used languages. In a traditional business, having multiple sources for a technology
would be considered an advantage. However, in Smalltalk's case, things proved to be quite different. 

Each vendor had a slightly different version - not so much a different language, as a different platform.
In particular, Smalltalk classes do not have a conventional syntax; instead, they are defined via
reflective method invocation. Slight differences in the reflection API among vendors meant that the
program definitions themselves were not portable, irrespective of other differences in APIs used by the

There were of course efforts to remedy this. Smalltalk standardization efforts go back to the late 80s,
but were pushed further in the 90s. Alas, in practice they had very little impact.

Newspeak of course, fixed this problem thoroughly, along with many others. But we were poorly funded
after the 2008 crash, and never garnered much interest from the Smalltalk community.
The community's lack of interest in addressing weaknesses in the Smalltalk-80 model will be a
recurring theme throughout this post.

Business model. Smalltalk vendors had the quaint belief in the notion of "build a better mousetrap
and the world will beat a path to your door".  Since they had built a vastly better mousetrap, they
thought they might charge money for it. 

This was before the notion of open source was even proposed; though the Smalltalk compilers, tools
and libraries were provided in source form; only the VMs were closed source.

Alas, most software developers would rather carve their programs onto stone tablets using flint tools
held between their teeth than pay for tools, no matter how exquisite. Indeed, some vendors charged
not per-developer-seat, but per deployed instance of the software. Greedy algorithms are often
suboptimal, and this approach was greedier and less optimal than most. Its evident success speaks
for itself.

In one particularly egregious and tragic case, I'm told ParcPlace declined an offer from Sun
Microsystems to allow ParcPlace Smalltalk to be distributed on Sun workstations. Sun would pay a per
machine license fee, but it was nowhere near what ParcPlace was used to charging.

Eventually, Sun developed another language; something to do with beans, I forget. Fava, maybe?
Again, dwell on that and what alternative universe might have come about.

Performance and/or the illusion thereof.

Smalltalk was and is a lot slower than C, and more demanding in terms of memory. In the 1980s and
early 1990s, these were a real concern. In the mid-1990s, when we worked on Strongtalk, Swiss
banks were among our most promising potential customers. They already had Smalltalk applications
in the field. They could afford to do so where others could not. For example, they were willing to equip
their tellers with powerful computers that most companies found cost-prohibitive - IBM PCS with a
massive 32Mb of memory! 

It took a long time for implementation technology to catch up, and when it did, it got applied to lesser
languages. This too was a cruel irony. JITs originated in APL, but Smalltalk was also a pioneer in that
field (the Deutsch-Schiffman work), and even more so Self, where adaptive JITs were invented. 

Strongtalk applied Self's technology to Smalltalk, and made it practical. 

Examples: Self needed 64Mb, preferably 96, and only ran on Sun workstations. Strongtalk ran in 8Mb
on a PC. This mattered a lot. And Strongtalk had an FFI, see below.

Then, Java happened.  Strongtalk was faster than Java in 1997, but Strongtalk was acquired by Sun;
the VM technology was put in the service of making Java run fast.  

The Smalltalk component of Strongtalk was buried alive until it was too late. By the time I finally got it
open-sourced , bits had rotted or disappeared, the system had no support, and the world had moved on.
And yet, the fact that the Smalltalk community took almost no interest in the project is still telling.

Imagine if all the engineering efforts sunk into the JVM had focused on Smalltalk VMs.

It's also worth dwelling on the fact that raw speed is often much less relevant than people think.
Java was introduced as a client technology (anyone remember applets?). The vision was programs
running in web pages. Alas, Java was a terrible client technology. In contrast, even a Squeak
interpreter, let alone Strongtalk, had much better start up times than Java, and better interactive
response as well. It also had much smaller footprint. It was a much better basis for performant client
software than Java. The implications are staggering. 

On the one hand, Netscape developed a scripting language for the browser. After all Java wouldn't cut
it. Sun gave them permission to use the Java name for their language.  You may have heard of this
scripting language; it's called Javascript. 

Eventually, people found a way to make Javascript fast. Which people? Literally some of the same
people who made Strongtalk fast (Lars Bak), using much the same principles.

Imagine if Sun had a workable client technology. Maybe the Hot Java web browser would still be

On the other hand, the failure of Java on the client led to an emphasis on server side Java instead.
This seemed like a good idea at the time, but ultimately commoditized Sun's product and contributed
directly to Sun's downfall. Sun had a superb client technology in Strongtalk, but the company's
leadership would not listen. 

Of course, why would they? They had shut down the Self project some years earlier to focus on Java.
Two years later, they spent an order of magnitude more money than it cost to develop Self, to buy back
essentially the same technology so they could make Java performant.

Interaction with the outside world.

Smalltalk had its unique way of doing things. Often, though not always, these ways were much better
than mainstream practice. Regardless, it was difficult to interact with the surrounding software
environment. Examples:

FFIs. Smalltalk FFIs were awkward, restrictive and inefficient. After all, why would you want to reach
outside the safe, beautiful bubble into the dirty dangerous world outside?

We addressed this back in the mid-90s in Strongtalk, and much later, again, in Newspeak.  

Windowing. Smalltalk was the birthplace of windowing. Ironically, Smalltalks continued to run on top
of their own idiosyncratic window systems, locked inside a single OS window. 

Strongtalk addressed this too; occasionally, so did others, but the main efforts remained focused on
their own isolated world, graphically as in every other way. Later, we had a native UI for Newspeak as

Source control. The lack of a conventional syntax meant that Smalltalk code could not be managed
with conventional source control systems. Instead, there were custom tools. Some were great - but
they were very expensive.

In general, saving Smalltalk code in something so mundane as a file was problematic. Smalltalk used
something called file-out format, which is charitably described as a series of reflective API calls, along
with meta-data that includes things like times and dates when the code was filed out. This compounded
the source control problem.

Deployment. Smalltalk made it very difficult to deploy an application separate from the programming
environment. The reason for this is that Smalltalk was never a programming language in the traditional
sense. It was a holistically conceived programming system. In particular, the idea is that computation
take place among communicating objects, which all exist in some universe,  a "sea of objects". Some
of these object know how to create new ones; we call them classes (and that is why there was no
syntax for declaring a class, see above).

What happens when you try to take some objects out of the sea in which they were created (the IDE)?
Well, it's a tricky serialization problem.  Untangling the object graph is very problematic.

If you want to deploy an application by separating it from the IDE (to reduce footprint, or protect your IP,
or avoid paying license fees for the IDE on each deployed copy) it turns out to be very hard.

The Self transporter addressed this problem in a clever way. Newspeak addressed it much more
fundamentally and simply, both by recognizing that the traditional linguistic perspective need not
contradict the Smalltalk model, and by making the language strictly modular.

The problem of IP exposure is much less of a concern today. It doesn't matter much for server based
applications, or for open source software. Wasted footprint is still a concern, though in many cases you
can do just fine. Avi Bryant once explained to me how he organized the server for the late, great
Dabble DB. It was so simple you could just cry, and it performed like a charm using Squeak images.
Another example of the often illusory focus on raw performance.

So why didn't Smalltalk take over the world? 

With 20/20 hindsight, we can see that from the pointy-headed boss perspective, the Smalltalk value
proposition was: 

Pay a lot of money to be locked in to slow software that exposes your IP, looks weird on screen and
cannot interact well with anything else; it is much easier to maintain and develop though!

On top of that, a fair amount of bad luck.

And yet, those who saw past that, are still running Smalltalk systems today with great results; efforts to
replace them with modern languages typically fail at huge cost.

All of the problems I've cited have solutions and could have been addressed. 
Those of us who have tried to address them have found that the wider world did not want to listen -
even when it was in its own best interest. This was true not only of short sighted corporate leadership,
but of the Smalltalk community itself.  

My good friends in the Smalltalk community effectively ignored both Strongtalk and Newspeak.
It required commitment and a willingness to go outside their comfort zone.

I believe the community has been self-selected to consist of those who are not bothered by Smalltalk's
initial limitations, and so are unmotivated to address them or support those who do. In fact, they often
could not even see these limitations staring them in the face, causing them to adopt unrealistic
business policies that hurt them more than anyone else.

Perhaps an even deeper problem with Smalltalk is that it attracts people who are a tad too creative and
imaginative; organizing them into a cohesive movement is like herding cats.

Nevertheless, Smalltalk remains in use, much more so than most people realize. Brave souls continue
to work on Smalltalk systems, both commercial and open source. Some of the issues I cite have been
addressed to a certain degree, even if I feel they haven't been dealt with as thoroughly and effectively
as they might. More power to them. Likewise, we still spend time trying to bring Newspeak back to a
more usable state. Real progress is not made by the pedantic and mundane, but by the dreamers who
realize that we can do so much better.

Eppur si muove

by Gilad Bracha ( at May 26, 2020 07:44 PM

May 24, 2020


Roassal’ 1 hour XP: assembly code of GWBasic

Alexandre Bergel posted:
1 hour-project I just completed: visualizing the routines and their dependencies of each assembly source code files of the original source code of GWBasic (made in 1975 by bill gates and paul allen)
Here is the header of the main assembly file:
The dependencies of the routine is visualized here:
Source code of GWBasic is available here:
A. Bergel.

by Stéphane Ducasse at May 24, 2020 07:41 AM

May 21, 2020


[ANN] Smalltalkhub Readonly Migration tuesday 8hs – server maintenance / migration

Hi all,

We wanted to announce that, as announced previously, Smalltalkhub is going read only from tomorrow, 8h central Europe time.
This means the service could be down for a couple of hours until the sync of data is done.

Keep tuned,

Guille and Christophe in behalf of the RMoD team

by Stéphane Ducasse at May 21, 2020 05:25 PM

May 20, 2020


Deployment tips from the Pros

Hi Readers


Sven (the father of Zinc) pointed the following repos of his deployment scripts!


Hi Sanjay,

When you do a metacello configuration or baseline install with the command line tools, the image is saved automatically at the end (if the load is successful).

My current approach is described here

which is a newer version of

Much of this goes beyond Pharo and requires some Unix/Linux knowledge, but it is all standard stuff.


by Stéphane Ducasse at May 20, 2020 05:24 PM

[Ann] Box2DLiteForPharo

We want to thanks Eiichiro Ito for this!


Screenshot 2020-05-20 at 12.21.51

by Stéphane Ducasse at May 20, 2020 10:23 AM

May 15, 2020

Program in Objects

Covid-19 Tracker

Here’s a cool PharoJS application that tracks COVID-19 data from Johns Hopkins:

by smalltalkrenaissance at May 15, 2020 07:57 PM


[Ann] New book on git and Pharo

Hello we are happy to announce a new little book that we hope will help you to master git and Pharo.

Thanks for your reading


by Stéphane Ducasse at May 15, 2020 12:02 PM

May 14, 2020


About uptime in industrial setup


So here is a little anecdote from the real world. I was planning to update the OS on my Linux server, from Ubuntu 18.04 LTS to 20.04 LTS (Long Term Support). This small (Digital Ocean, 1GB RAM, 1 Core) cloud server runs 3 Pharo images with public facing web sites.

The machine itself reports:

$ uptime
12:37:50 up 530 days, 21:46,  1 user,  load average: 0.02, 0.04, 0.01

which means it hasn’t been powered down or didn’t restart in 530 days.

I was surprised to discover that 2 of the Pharo images on that machine did just as well:

$ ./
Connecting to Telnet REPL at locahost:41011
Connected to localhost.
Escape character is ‘^]’.
Neo Console (32 Bit)
pharo> get system.uptime
405 days 20 hours 29 minutes
pharo> quit

$ ./
Connecting to Telnet REPL at locahost:41001
Connected to localhost.
Escape character is ‘^]’.
Neo Console Pharo4.0 of 18 March 2013 update 40620

get system.uptime
530 days 21 hours 44 minutes



So both Pharo 7 and Pharo 4 kept on doing their jobs for a very long time. I think this is a testament to the stability of Pharo and to what is possible.



by Stéphane Ducasse at May 14, 2020 01:19 PM

Tech talk: Pharo 90 development status

Here are the slides of the april tech talk about Pharo 90 status.



by Stéphane Ducasse at May 14, 2020 10:04 AM

May 13, 2020

Program in Objects

What are good reasons to use Smalltalk?

<noscript><a href="" target="_blank">Take Our Poll</a></noscript>

Thanks for participating in the poll.

by smalltalkrenaissance at May 13, 2020 07:41 PM

May 11, 2020


Official Pharo consortium Call. Pharo needs you: Perfect time to join

Dear Pharo users, lovers, businessers


You may not know it clearly but the Pharo consortium succeeds to pay one full time engineer: Esteban Lorenzano. Due to legal concerns with the Inria foundation effort, Inria converted the position of Esteban into a permanent position. It was a great deal
because it secures Esteban.
Now based on contracts between the consortium and Lifeware ( ) and Schmidt ( the consortium is able to pay another engineer: Pablo Tesone until
April 2021. All this was announced at ESUG 2019 but not all of you may have known it.
<Mini news>

</mini news>
Now THE announce.

During the last consortium meeting, we learned that David Margery (the Inria software manager that is managing around 10 ofconsortiums for Inria) wants to propose to Inria to allocate another permanent position to Pharo even if the consortium does not raise two full salaries.

This will secure the effort of the consortium for the coming years.
We were excited by the news because such positions are rare and lifelong!

David is building a case to defend his proposal:

David told us that having more industrial partners (even first entry
ones) will really help our case: the fact that members are willing to pay to secure

the future of Pharo is the key indicator, the amount paid being only secondary.

Therefore the consortium is sending an official call. If you hesitated to join the consortium this is clearly the moment.  Your money will be multiplied. Because a full job for an expert engineer is around 90 K so if we get 8 new members at 1/2 K we
have a strong multiplication effect and this will have an important impact on Pharo.
So I hope that we convince you that you can get a real impact on Pharo. The consortium engineering team wants to thank all the current consortium member because they make Pharo happening.

S. on the behalf of the consortium.

by Stéphane Ducasse at May 11, 2020 09:48 AM

May 06, 2020


[ANN] Ansible v1.0.0

Ansible, ansible is an amqp client for pharo reached it’s v1.0.0 version.



The Buenos Aires Smalltalk team

by Stéphane Ducasse at May 06, 2020 08:06 PM

May 05, 2020


[ANN] HighchartsSt v11.0.0

HighchartsSt, a highcharts js api wrapper for pharo smalltalk reached it’s v11.0.0version.



The Buenos Aires Smalltalk team

by Stéphane Ducasse at May 05, 2020 08:13 PM

Program in Objects

What is your "spirit programming language"?

The definition of a “spirit animal”:

In certain spiritual traditions or cultures, spirit animal refers to a spirit which helps guide or protect a person on a journey and whose characteristics that person shares or embodies. It is also metaphor, often humorous, for someone or something a person relates to or admires.

Someone at Quora asked: How do you decide what is your “spirit programming language”?

I found this question intriguing. It speaks to the special nature of programming languages and how one may have a particular affinity to a specific language. I think many developers do have a spirit programming language, even if they don’t realize it.

Here was my answer…

There are several things you may consider:

  1. which language offers the most job opportunities — this is decidedly a very pragmatic consideration because we all have to eat
  2. which language appeals to you aesthetically and philosophically — this is, of course, very much a matter of individual taste
  3. which language is primarily used in your preferred application domain — assuming, of course, that you have a preferred application domain
  4. which language you find very easy to use and makes you most productive — this can only come from your personal experience
  5. which language is most versatile — it can do nearly everything with equal aplomb

So, based on these considerations, you might choose one of the following as your “spirit programming language”:

  1. Python or Java — at Indeed, they have the most job postings
  2. if you’re inclined toward functional programming, look at Elixir; if you’re inclined toward object-oriented programming, look at Pharo
  3. if your preferred domain is front-end web, JavaScript is really your only choice; if you prefer data science, Python is your best choice
  4. without doubt, Smalltalk (or Pharo) is the most productive language, by far, because it’s so ridiculously easy to use
  5. there are several enormously versatile languages to choose from: C++, Java, Python, Smalltalk (or Pharo)

Smalltalk (Pharo) became my “spirit programming language” because:

Use Pharo for back-end web with Seaside and Teapot frameworks.

Use Pharo for front-end web with Amber and PharoJS.

Use Pharo for data science with PolyMath, Roassal, and Moose.

Use Pharo for machine learning with TensorFlow and Keras.

Use Pharo for Internet of Things with PharoThings.

Use Pharo for robotics with PhaROS.

Use Pharo for virtual reality:

Use Pharo for scripting the Unreal game engine:

Here’s a fantastic Roassal demonstration:

Here’s a great demonstration of Pharo’s live coding:

Here’s a nice game for mobile that was written in VisualWorks Smalltalk: HexSolve.

by smalltalkrenaissance at May 05, 2020 01:39 PM


[ANN] Willow-SpinKit v8.0.0

Willow-SpinKit, integration between willow and spinkit reached it’s v8.0.0 version.


Migration Guide


The Buenos Aires Smalltalk team

by Stéphane Ducasse at May 05, 2020 07:58 AM

May 04, 2020


[Ann] Willow-Bootstrap v12.0.0

Willow-Bootstrap, integration between willow & bootstrap 3/4 reached it’s v12.0.0 version.

Non breaking changes

Breaking changes


The Buenos Aires Smalltalk team

by Stéphane Ducasse at May 04, 2020 04:31 PM

May 03, 2020


[Preview] New type of web application using HTML, CSS and Pharo

I have published my first demo of a new type of webapplication based on a
tiny Smalltalk image running in the browser, acting as the JS-engine. Create
a dynamic application using Smalltalk only, with the direct manipulation
you’re familiar with from Smalltalk. And …(in the near future)… with the
same debugging capabilities. Still work in progress, but hopefully providing
an idea of what’s in store.

Feel free to ask questions.

Erik Steel

by Stéphane Ducasse at May 03, 2020 08:34 PM

ReMobidyc preview

ReMobidyc is a new nice and clean re implementation of the concepts used in the Mobidyc multiagents simulator. An exciting projet with a super nice implementation.



It defines a DSL for describing Animat behavior.

Goat is Animat with
    energy [kcal]
    basal_metabolism [kcal/s].
to metabolize is
   presume my sugar >= 0
   my delta sugar” = – my basal_metabolism.
Goat metabolize where
   my sugar -> my energy
   my basal_metabolism -> my basal_metabolism.


by Stéphane Ducasse at May 03, 2020 10:15 AM

May 02, 2020

Pierce Ng

Updating GlorpSQLite for Pharo 8

I've started to update Glorp and GlorpSQLite for Pharo 8. This post lists the stuff to be handled.

Changes in Pharo

First, changes in Pharo from version to version. Glorp's TimedProxyReaper uses a weak-valued dictionary to hold TimedProxy instances. In Pharo 6, WeakValueDictionary>>at:put: essentially does the following:

WeakValueAssociation key: key value: anObject

In Pharo 7, that became:

WeakValueAssociation key: key value: anObject asSetElement

This required TimedProxy to implement #asSetElement.

In Pharo 8, #asSetElement is deprecated in favour of #asCollectionElement.

WeakValueAssociation key: key value: anObject asCollectionElement

So TimedProxy now also needs #asCollectionElement.

New SQLite Binding

The Pharo community has consolidated around Pharo-SQLite3 as the definitive SQLite binding going forward. GlorpSQLite uses the now-legacy UDBC-SQLite binding currently. This change should be straightforward.

Glorp Changes

Todd Blanchard has been working on Ruby on Rails-style ActiveRecord for Glorp, and testing the changes with PostgreSQL.


With independently evolving drivers for SQLite, PostgreSQL and MySQL, and the ActiveRecord work changing Glorp itself, the time has come to set up CI for Glorp.

by Pierce Ng at May 02, 2020 01:16 PM

May 01, 2020


[ANN] Willow v13.0.0 [v13.0.0] released!

Willow, the web interaction library that eases the burden of creating ajax-based web applications reached it’s v13.0.0 version.

Breaking Changes

Non breaking changes


The Buenos Aires Smalltalk team

by Stéphane Ducasse at May 01, 2020 06:40 AM

April 30, 2020


Projects for Season of Docs 2020

Pharo is applying to season of docs 2020

We have several tasks for technical writers:

All our books, booklets are hosted at

We favor small tasks, fast iteration for great results. Since we are authors beside programming Pharo we know and understand the constraints and process of documenting.

Do not hesitate to contact us because you can get an impact!

The Pharo consortium /

by Stéphane Ducasse at April 30, 2020 12:41 PM

[ann] Stable release of Roassal3 version 0.9

Stable release of Roassal3 version 0.9:
The Roassal Visualization Engine.
Contribute to ObjectProfile/Roassal3 development by creating an account on GitHub.

by Stéphane Ducasse at April 30, 2020 09:31 AM

April 28, 2020


Consortium Pharo VM statement

As promised the consortium engineering team composed of G. Polito, P. Tesone, E. Lorenzano, M. Denker, C. Demarey and S. Ducasse produced a statement about the Pharo VM. This statement was reviewed by the Pharo board and follows decisions taken during the 2019 consortium general assembly held during PharoDays.

S. Ducasse on the behalf of the consortium

Statement about the VM-2

by Stéphane Ducasse at April 28, 2020 08:05 AM

April 24, 2020


Showing off with test numbers ;)

You have several kinds of developers

Pharo core development team is of the fourth kind and it eats its own dog food.

As of today any PR integration is validated with 67392 tests (not counting the VM tests, the project tests like iceberg).


S. Ducasse (a test infected developer and super happy to be infected else I could not work).

by Stéphane Ducasse at April 24, 2020 10:51 AM

April 21, 2020


Participate to the Magic Literal XP

Dear all,

We are running a large XP for a research around Magic Literals.

A magic literal is a literal (number, booleans,…) that is used to denote something but that it not immediately obvious to the code reader: it can be for example a number but could be also a string, a character or boolean (this is what we want to discover).
When you read the code you should be puzzled by the usage of this magic encoding and this is what we want to understand and that you report to use using a special tool.
Now identifying magic literal is not easy and we want to measure them.
We already did a publication at ESUG last year (but we only did an XP with 100 methods) and now we want to go the world. If you want to read it
Our idea is to have result first in Smalltalk and then, only then check with Java :).
But for that we should show to the world that we did a large XP.  So we build one and now we need you to help.
First we need to evaluate the situation and understand the different cases, as not all literals are “magic”. You can help us in this. It can take you 30 min for one experience.
In the shared directory
there are images for different experiments (on whole Pharo, on Roassal, Polymath, VM maker, Seaside project, …)
We want to compare the analysis of an expert and an external person on a domain this is why we will cross comparison
between roassal expert and roassal newbie (same for Seaside, Polymath, VMMaker)
These images contain the code and the tool for the experiment and they should be open with Pharo80 you can get from

To participate in the experiment:

– Step 1.

go to the document

– Step 2.

select one experiment to do (for example put your name in the column ‘Doing’) add your expertise to the sheet

– Step 3.

please select the experiments in numerical order, e.g. do the
Pharo-1 experiment before the Pharo-2 one.
Note that a Lot will contain also some other methods because we are mixing methods to collect more information
so do not be surprised to see other methods that Polymath’s ones in the polymath XP.

– Step 4.

Get the tool on the experiment. From the list grab an inspector and execute MLSExperimentPresenter openOnSample: self ‘ with the batch you chose as argument
Screenshot 2020-04-21 at 17.06.13.png
You should get the following tool (with different colors 🙂 – yes that theme is funky)
Screenshot 2020-04-21 at 17.07.10.png

– Step 5.

decide whether each literal presented is Magic or not (unabling ‘Hide completed’ can help)
Remember: ‘A magic literal is a literal (number, booleans,…) that is used to denote something but that it not immediately obvious
to the code reader’

– Step 6.

completing one experiment should take less than 30 minutes

– Step 7.

when done, save the result (button at the bottom of MLSExperimentPresenter)
– this will give a STON file named after your batch.

– Step 8.

You need to send us this file (email at

Your identity will be discarded from the data (anonymous answers). But we will owe you a beer at ESUG or Pharodays 🙂
We will use it only to assess your expertise in Pharo and/or the project evaluated.

Many thanks for your help in improving pharo and our understanding of the literals (magic or not)

Nicolas, Stephane, Julien, Christopher and Oleksandr

by Stéphane Ducasse at April 21, 2020 03:18 PM

New blog post on the

by Stéphane Ducasse at April 21, 2020 02:01 PM

April 18, 2020


[Ann] Pharo Launcher 2.0

Big thanks to Christophe Demarey for his great job. Here is the anounce.


Hi all,

Pharo Launcher 2.0 has just been released! It is available from

Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher.

Here is the changelog:
Pharo Launcher v2.0


The list of closed issue is too long (68) to be listed but you can browse it here:

Here are some highlights

New features:


Bug fixes:

Fix use of system unzip on Windows

The Pharo team.


by Stéphane Ducasse at April 18, 2020 08:39 AM

April 16, 2020


Quuve: an advanced portfolio manager in Pharo

It is impressive. Quuve was a really advanced portfolio manager developed in Pharo.

Quuve overview

by Stéphane Ducasse at April 16, 2020 12:30 PM

April 14, 2020


[Ann] About GCC dead store code deletion

Pablo Tesone from the Pharo consortium wrote a nice blog post about GCC dead store code deletion and the bugs it can introduce in the VM.

by Stéphane Ducasse at April 14, 2020 04:56 PM

April 07, 2020


[Ann] Rewrite tool in Spec2.0

Dear friends,

I would like to announce that Sebastian, an intern of my company, just ported the RewriteTool to Spec2.

You may find the install instructions in the following link 🙂  

Please, help us to test it, any feedback is welcome.


Juan P.


by Stéphane Ducasse at April 07, 2020 12:14 PM