Internship around 3D/Pharo

With the people that did a nice virtual

and event touch with Pharo



[Ann] Nano Pi Neo + MCP9808 :)

Nano Pi Neo running PharoThings and controlling the GPIOs to take the temperature out of the MCP9808 sensor and turn on/off a LED


Great job allex.

[Call for testers] Pharo Launcher 1.4.5

Hi all,

We have been working these last ~two weeks with Christophe on the stability of the launcher. We have prepared version 1.4.5, and we would like to have some feedback.
So, we would really LOVE, if somebody can play with this version and send us feedback. Specially, if your username in your machine has characters that encoded take more than 1 byte, we really would like your feedback. We have tested with japanese characters, and others like î,ü, etc, but the more the better.
The main focus was on:

 – correct management of encodings (in all platforms)
   – of environment variables
   – of files and paths
   – of commands called through OSProcess
 – better error management in case of edge cases (like when we cannot determine the version of an image)
Just FYI: the major limitation of the launcher right now (and it was like that since ever) is that we cannot call external processes with non-ascii characters in windows. This happens because ProcessWrapper uses the ascii version of the windows API to create a process.
With what we have learnt this week, we would like to push some of these fixes to Pharo7 too soon:
 – Correct encoding/decoding of environment variables in linux/osx
 – Ability to access the encoded version of environment variables in linux/osx to give users control over the encoding they want (or even access binary data)
 – Correct encoding/decoding of environment variables in windows by using the correct windows API (current primitiveGetenv in windows uses Ascii version too…)
In the long term, we also need a solution to enhance or replace ProcessWrapper using the W (wide) version of the windows API. But that is far more work…
GC, Guille & Christophe

MDL in Pharo at Google Dev Fest Brussels

Philippe Back from HighOctane is presenting MDL Seaside at Google DevFest Brussels. MDL developed by Cyril Ferlicot and available at

Well done Phil!




[Ann] Release version v1.3.0 of MDL

Add compatibility for Gemstone smalltalk (b83d742) and (622dbdb)
MDLCell should implement an offset feature (0ae17ef)
MDLCell should allow to rorder the cells depending on the layout (desktop/tablet/phone) (a8e77dd)

Add OrderedDictionary to Gemstone compatibility package (b83d742)
GemStone expects Blocks for ifNotNil: and friends. What does this code do? (b83d742)
Bug Fixes

Closing button of MDLDialogWidget should not be of submit type but of button type (9d54da1)
MDLMenuButtonWidget should use the ID system of MDLWidget (8ad61b9)
MDLCalendar should use the id system of MDLWidget instead of recreating one (01e1f61)
Month and year selection does not work on MDLCalendarWidget (dc915cd)
First snackbar demo is broken (9497c65)

Deprecate #mdlMultilineTextField since we already have #mdlTextArea which is the common name in HTML5 (ef1e0a6)
Deprecate MDLCheckboxWidget since it does not brings anything more than the brushes (0630493)
Typo in MDLProgressBarWidget, #hyde should be #hide (a362b33)
Remove dependency to Morphic (#detectIndex:) (ab02a1f)
MDLCardTitleText should not be able to respond to #borde or #expand (7f2e2cf)
Remove dependency to JQueryUI (9ed3a6f)
Remove duplication between MDLButton and MDLAnchorButton (99b3266)
MDLCardTag has unused variables (431d7d1)
MDLCardMenu should not be able to respond to #borde or #expand (b59094d)
Remove dependency to Seaside-Development (89fa553)
Deprecate useless MDLFooterLogo since we already have MDLLogo (fa7d7985)
Remove duplication between MDLIconToggleLabel and MDLIcon>>#toggle (fa7d798)

Improve code coverage. This release increased the code coverage from 3% to 61%
Add tests. The number of tests increased from 8 to 485
Add Coverall to CI (5a37a85)
Add Demo about not raised colored buttons (7a55891)

Add demo on Elevation (f9a387c)
**UX: ** Icons in list should be clickable (43e3187)
**UX: ** Improve global UX of the demo (43e3187)
Add demo about MDLBadge>>noBackaground (f097d8f)
Add demo to explicit MDLBadge>>overlap option (f097d8f)
Add demo about MDLCell>>#hideDesktop/#hideTablet/#hidePhone (aabc92b)
Add demo about MDLCell>>#stretch/#bottom/#top/#middle (250a4b2)

Neo* libraries Migration to GitHub/Tonel/TravisCI


I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI.
So far I did the following:

More will follow, in particular Zinc/Zodiac and STON, both of which are more complex.

The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1.
By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5.

After a while I will switch the Catalog entries and declare these repo the main ones.


Key questions/answers about Tonel

> Hi,
> So the future for Pharo is Iceberg/git/tonel and that is fine.
> My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other  Smalltalk implementations ? What is the official answer here ?

In absence of Iceberg, Tonel can be used as any other MCRepository. You can save and read your packages as it would be with a “metadataless filetree”.
That means, in Pharo without iceberg you need to save/read from your cloned repository.
Saving to your cloned repository  will write files to disk. Which means you need to go there and do a regular git commit/push cycle.

While this is annoying compared with the usage of Iceberg, is perfectly doable: it is the same as while using metadataless filetree.

Tonel is tested to work up to Pharo 3. Older Pharos may work (there is no reason why not) but maybe some minor adjustments are needed.

I designed Tonel to be easily portable. I didn’t used a lot of Pharo elements that would have done my life a lot easier (like using RBParser instead parsing manual). This way other dialects can take it and make it work. Now, making it work, is a problem of other dialects users (I’m willing to help, but that work will fall in other persons).
I know it is already ported to Gemstone and it was being ported to Squeak.

> A second question: suppose a repo is converted, is then still possible to copy a version  over to an old MC repo ? Just to keep it in sync.

You can save your packages as you want.
You can save a package with Iceberg and then read it with Monticello.,
And viceversa.
Now, it you want to “transfer” the history from git to an mcz, you will need to do some migration tool.


> Thx,
> Sven