Monthly Archives: February 2017

Agile visualisation book….

Just a little announce to tell you that the nice Agile visualisation book is now part of the Pharo books on

Great job Alexandre Bergel!


Trick to get one single menu

Hi Pablo,

Concerning the World menu you first define your menu in a method, and
tag it with a dedicated pragma, for example in Dr. Geo I wrote:

worldMenu: aBuilder
(aBuilder item: ‘New’ translated)
action: [DrGeo newFullScreen];
icon: ThemeIcons current smallNewIcon;
order: 0.
(aBuilder item: ‘Open’ translated)
action: [DrGeo openFigureThumbnail: nil];
icon: ThemeIcons current smallOpenIcon;
order: 1.
(aBuilder item: ‘Quit’ translated) action: [DrGeo quit]; order: 999

Then you register this as your new world menu using the pragma name:

WorldState desktopMenuPragmaKeyword: ‘drgeoMenu’.

Pharo Bootstrapping


I have published a short video of the Pharo bootstrapping from a Ring model that is browsed and modified by the Calypso browser.

No audio, please enable subtitles for the description.

— Pavel

Four new chapters…


I just released four new chapters for the Learning OO programming and design with Pharo.

  • 6 Objects and Classes
  • 7 LateBinding
  • 13 Inheritance
  • 14 Understanding Super

Super thanks to Hayatou Oumarou for his deep reviews of the book.


Voyage: Unique vs Multiple repos

> Hi,
> It looks like Voyage will duplicate in repo A the instance saved in repo
> B in the first place. These two instances of an identical object will
> have different ID.
> The following script shows this behaviour:
> | orga repo1 repo2|
> repo1 := VOMongoRepository host: ‘localhost’ database: ‘test1’.
> repo2 := VOMongoRepository host: ‘localhost’ database: ‘test2’.
> orga := ‘Pharo’ -> 13.
> repo1 save: orga.
> repo2 save: (‘Hilaire’ -> orga).
> repo2 selectAll: Association.
> => an OrderedCollection(‘Hilaire’->’Pharo’->13 ‘Pharo’->13)
> How do you guys avoid such duplication of identical instances in two
> different repo?
> Let’s say you want to have in one repository a collection of reference
> data, but these data are used by other instanced saved in another repo.
> Then from time to time this data may need to be edited, copy of these
> data will then be obsolete.
> Thanks
> Hilaire

Hi Hilaire,

Voyage will not handle that kind of problem. Voyage will not know anything about instance A being saved in repo1 AND repo2.
Also, I do not think it should

I think you have a design problem if you want something like that to work…
let’s explore the consequence of implementing something that would automatise that:

– you could have a “meta-cache” in the image with the objects in all repos, then on save you first check if is there and to which repository it belongs
– but that will not solve the problem, because object could be in repoX but not at the moment in the image, so you need to go to the repository to verify if is already there
– and that, for each repository you will want to handle.

So, how to handle this? Not to having the problem

– if one object can be on repo1 and repo2, then probably you need to join those repositories
– if that duplicated value is an enum type (like enum objects), then you do not want to persist that: what you do is to persist a reference, then on materialisation you refer to your enum (I do that a lot, in some apps)\
– if you want to have for example, your list of organisations in one repository and then one repository for each organisation, you can still apply same pattern as before, but instead enums you persist a reference to your organisation and then on materialisation you can repoint to it.
For example, this lates approach would be defined something like this:

We have objects Organisation, User (with organisation as attribute).

in repo1 you want to keep all organisations
in repo2 you want all users

then you do something like this:

User class>>mongoOrganisation

^ VOToOneDescription new
attributeName: ‘organisation’;
accessor: (MAPluggableAccessor
read: [ :user | repo1 keyOf: user organisation ]
write: [ :user :value | user organisation: (repo1 selectOne: Organisation where: { ‘_id’ -> value } asDictionary ) ] );

Something like that.


Pharo + HAL = archived great papers


HAL is not Inria specific, here is some more infos (from ):
HAL is an open archive where authors can deposit scholarly documents from all academic fields.
I have setup a collection at HAL. For now it is empty, we should fill it and then add it to the website (and announce it then, not now…).

The collection automatically has every paper on HAL that has “PHARO” as a keyword in the field “Project/Collaboration”.

To the attention of the authors
• The deposit must be made in agreement with the co-authors and in the respect for the policy of the publishers.
• The deposit is subject of a control, HAL reserves the right to refuse items that do not meet the criteria of the archive.
• Any deposit is definitive, no withdrawals will be made after the on-line posting of the publication.
• Text files in pdf format or image files are sent to CINES ( for long-term archiving.

To the attention of the readers
• In a context of electronic distribution, every author keep all its intellectual property rights.

PharoDays 2017 at Lille 18/19 May

Dear Pharoers

I’m happy to tell you that we will organise a new edition of the PharoDays at Lille the 18 et 19 of May.
The program and registration will be announced soon.
The setup will be similar to the ones of previous editions: Little cool presentations and hacking/discussions sessions
and a great social event.
So reserve the dates.
PS: for students, we got some sponsoring from inria and cristal and if you need support let us know.

First release of Woden 2


Finally I am glad to announce a. I made a hopefully simplified process for loading Woden 2 out of the box.

For loading and testing Woden 2, follow the instructions at:

In this release, I am not loading the level editor by default because it depends on an outdated version of Bloc. Until I fix the dependency problem of the Level editor, it will remain unusable.

Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which can be unstable. This is tested on OS X El Capitan. I do not know whether it will work or not on OS X Sierra.

Best regards,


Data encryption solutions

I have been tasked with throwing together a small web app that will hold the passwords to different projects for my company.

I would like to use seaside to do this, but the biggest requirement is that we need to be able to either:

– encrypt the entire database, so that if the machine was compromised physically, the data would be useless.


– encrypt the username and password fields to facilitate the above, also.

i am thinking that the first option might be easiest to implement.

any ideas on how i would pull this off with pharo?



Have a look at the ApplicationSecurity package:


The NativeBoost version of my SQLite library supports SQLcipher which adds
transparent full database encryption to SQLite. It is not in the UFFI version
yet though.


If it help I’m using NaCl to do secure the passwords. You should not store the passwords of your users, not even encrypted.

For securing the passwords I use Sha-512 over the salted password.
super initialize.
salt := (Nacl randomBytes: 16)

User>>setPassword: aPassword
hashedPassword := Nacl hash: (salt , aPassword asByteArray)

User>>validatePassword: aPassword
^ hashedPassword asByteArray = (Nacl hash: salt asByteArray , aPassword asByteArray)

Notice that:
1) I have a different salt for each password, if a bad guy want the passwords he is going to need a different rainbow table for each user.
2) I do not store the password. I do not even store the hash of the plain password.
3) Still I’m able to validate the password.

* Note that I’m using Nacl>>randomBytes: to generate a cryptographically safe random value. Here is not really necessary, BUT you should use it if you are creating Session-IDs or Tokens.

Encrypting the database is *tricky*. You not only have to encrypt the database, but also secure the key. First you need to know how much security you want:
1) Be secure if someone hack into the user running pharo.
3) Be secure if someone steal the server.
4) Be secure if someone has physical access to the running server. (All your keys are in RAM)
2) Be secure if someone hack root. (I doubt anything is going to save you here)

For most projects/business (unless working with really sensitive data, such as medical data) securing the OS (users and root) and encrypting the hard-disk should be enough. Also do not forget to encrypt the connections. If everything is on the same server just use https. But you may need more if you use Load Balancers, multiple servers and databases.



Hi Alejandro,

Coincidentally, I’ve just updated my SHA256/512 password hashing library, which
wraps a C library of the same. The salt is variable length between 8 and 16
octets long, and the output is in the informally standard md5crypt format





This is speculation without knowing your scope and architecture,
but perhaps part of the puzzle is two factor authentication
via a $20 Yubico FIDO U2F Security Key.

BSD licensed C library for server-side..

cheers -ben
P.S. It might be cool to link the yubico client-side libraries (LGPL)
into the VM for Iceberg to authenticate via U2F to github.

Building Pharo VM as simple as

$ git clone
$ cd pharo-vm/opensmalltalk-vm/build.macos32x86/pharo.cog.spur
$ ./mvm -f

for linux you can:

$ cd pharo-vm/opensmalltalk-vm//build.linux32x86/pharo.cog.spur/build
$ ./mvm