Monthly Archives: August 2018

[Ann] GeoHash for Pharo

Pharo package to decode/encode Geohashes to/from latitude and longitude (geolocation). See

Iceberg 1.2.2

Iceberg 1.2.2

# Bugfixes

#961 Authentification error while connecting with HTTPS
#965 Walkback – #nextChildNodeStartingFrom:suchThat:ifNone: committing selected code to branch (repo with ./dev/src)
#967 Merging a Commit that does not have Smalltalk Code
#962 DNU when loading with metacello and gitlocal

# Cleanups

#972 use instanceSide/classSide instead of other API
#964 Rename “Add Local Repository” into “Import from disk”


The iceberg team

[Ann] … with parent lookup

There are cases where you want to have an environment/dictionary that asks its parent when a key is not locally defined. For this you can use a PropertyEnvironment.

100% test coverage of a good and simple semantics.


Esteban’s log


This is my weekly ChangeLog, from 6 August 2018 to 12 August 2018.
You can see it in a better format by going here:


7 August 2018:

*    I've been working on a new ODBC driver for Pharo, made on UFFI and Garage. 
    Sadly, I cannot take the existing older ODBC driver as base because it was depending too much 
    on old FFI structure. Also, it didn't have any test or example so it was hard to take as 
    inspiration (too many differences to tacle).
    Anyway, the new ODBC driver will come soon(tm), in the mean time I needed to fix some issues on 
    * [case: 22287](
    * [case: 22300](
    This fixes some missing/incorrect parts on UFFI: first one adds a special handling for +size_t+ 
    types (needed because they behave differently in different platforms/architectures). And the second 
    fixes a problem when returning +enum+ values.

HDFS for Pharo :)


I would like to share one of my projects that I am working on in my PhD.
Since I am working on Big Data I wrote a library to access the Hadoop Distributed File System (HDFS).
We implemented it as a FileSystem in Pharo, using the webHDFS API of HDFS to access the files.
With this API you can browse the distributed file system and create/modify/delete directories and files.
Here is the git repository:
Documentation is in the readme.

About Iceberg design


I'll write down some of the reasons of the project's design, like that I can afterwards copy paste it in the wiki :).

First, this design did not came up from an egg. We worked on it for about two months. And it is thought to be backwards compatible and manage lots of metacello particularities. It may have things that are perfectible, sure, so let's discuss it.

One of the main problems we saw in metacello, and that Iceberg inherited, was the "source subdirectory" thing. This source directory had to be specified in the CLIENT, meaning that every time we clone a repository we should know by heart the directory chose by its developer. Moreover, we lack a standard way to do it, so everybody does as he feels (root directory, src, source, repository, mc....).

This has some bad consequences:
 - once a repository is referenced by some other project, it is more
complicated to change its source directory. Imagine that tomorrow we set as standard that all git repos should have the code in src. Then voyage should change. And all its clients too.
 - Making a typo in the code subdirectory means sometimes super ugly errors from metacello that are difficult to debug and understand (e.g., "Cannot resolve BaselineOfMetacello WTF")

Moreover, there was another problem that people started stumbling on: the fact that iceberg got confused sometimes thinking that an empty project was in filetree (to keep backwards compatibility with projects without a .properties).

So we decided that for this release we wanted to revert a bit that
situation. Think object: let's put the meta-data used to interpret a
project's structure inside the project itself.
The idea is that:

 - each project should contain both a .project and a .properties file. The first can contain arbitrary project meta-data (such as the source directory). The second contains the cypress properties, which are needed to correctly interpret the code inside the source directory.
 - a project without a .project file is an old project and cannot be
interpreted, because we don't know the source directory
 - a project without a .properties file is an old project and is by default transformed in a project with a #filetree properties file
 - an old project cloned from iceberg detects the missing .project file and gives the user the opportunity to declare it (and then commit it explicitly)
 - an old project cloned and loaded from a Metacello expression defining a source directory will honnor the source directory defined in the Metacello expression (for backwards compatibility, and we have ~500 tests about this).

# About defaults values / forcing the user to define a project

First, notice that even when the repositories you load are just marked as "dirty".
This is because in memory we add a project to your repository. But you're not forced to commit it.Actually, you can still load packages and baselines from that repository without committing.

This is in line with Iceberg's "explicitness". We try to not do any
destructive operation without asking the user first (that's why we have several preview windows for pushing, pulling, checkout, merge..., and why
contrastingly with monticello we show the committed changes on the commit window...). So, instead of transparently "adding the file" we have decided to modify the project in memory and let the user the responsibility to commit that file.

If there's a drawback, is that the repository is marked as dirty. Which is a bit noisy, yes, but still I think it's not so bad compared with the previous drawbacks.
To solve this, we could have some default values, yes, and only mark it as dirty if the project does not follow the default value.
This could work, but right now all projects use different names for their source directories.
So the question is, what would be a good default? I'd like to use 'src' since this is short, well known and less alien (all these in the sense that we do not lose anything and we have a lot to gain by using it). However, not much repositories use 'src' so it will still produce a lot of "noise"...

But still! Committing that file is a one-time operation. Once people fix their repositories adding the project meta-data, you will not see them dirty anymore. So we can see this as a transition noise too...

Of course, new ideas are welcome. I'll let Pablo and Esteban add their points of view on this too.

New Iceberg Version 1.2.1 +]
Thanks to all brave users, issue reporters, and contributors :).

This version includes the implementation of projects.
Projects are a way of defining basic metadata of the repository.
Now, this metadata just includes the source directory.

This means that people do not need anymore to provide ALL THE TIME the source directory.
Instead, every repository includes a project file that provides it.
Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :).

This version is integrated in the latest Pharo 7 images.

#New Features

 - #866 Introduce first version of Projects


 - #870 Improving tests of Metacello Integration
 - #903 Split basic tests from metacello tests in CI
 - #914 Sync Wiki with documentation directory automatically
 - #934 Manually check metacello integration dialogs
 - #935 Try to refrite the metacello integration tests.
 - #940 Installation in new Pharo should also bootstrap pharo repository


 - #675 The History of a Method in Calypso should show a progress bar.
 - #788 Show progress during network operations (fetch,push, ...) Libgit.
 - #875 Tonel plugin does not delete .filetree Migration
 - #897 Update to OSSubprocess 1.0.1
 - #911 Repair Checkout branch should appear in "no project found"
 - #933 Fix Edit repository dialog
 - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor
 - #944 Extract pharo repository bootstrap code into iceberg

#Bug Fixes

 - #828 Convert sources to tonel raises an Exception
 - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong
 - #849 VM crash while saving credentials Credential Manager
 - #851 .properties file is not create if project is imported and not
 - #869 Error msg after an http timeout is unreadable
 - #873 Error with credential provider Credential Manager
 - #874 The integration with Metacello does not work when there is a src
directory, but not project file.
 - #880 Putting "." in project src field gives dnu
 - #884 Edit Project Dialog tries to select 'src' folder as default, but
does not handle if it does not exists
 - #886 Edit Project Dialog does not allow to select the root of the
repository as source directory
 - #888 Could not locate repository does not have subdirectory anymore.
 - #889 Loading an unborn project through metacello does not work
 - #894 GitHubAPI fails when the API responds with a 204 No Content
 - #901 I get a DNU projectName....
 - #902 Edit project metadata does not detect default format
 - #918 Cloning pharo from a sync'ed repository does not correctly show
dirty packages
 - #928 Pull request cancel
 - #930 Changed ivar/slot name in stateful trait not recognized as a change
 - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg
has been removed
 - #932 Pharo repository forgets packages
 - #938 Do not catch assertion failures
 - #941 Iceberg pre-installed repository has wrong repair action
 - #946 Fixing Metacello Integration Tests
 - #948 Cloning from github creates an invalid remote
 - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug
 - #951 New project window should be coherent on the vocabulary UI
 - #953 Make remote request anonymous enhancement
 - #952 Cannot Clone Pharo Repository Pharo plugin bug
 - #955 Repair actions for repositories with fetch required are wrong UI bug

Pablo Tesone.
tesonep at