Planet Smalltalk

December 02, 2016

The Weekly Squeak - Smalltalks 2016 Argentina Videos

Gilad Bracha – Utopia And Dystopia: Smalltalk And The Wider World

Many more videos available here:

December 01, 2016

Pharo News - Pharo Monthly Tech Talks

<p> We are organising a monthly chat around technical topics around Pharo. The next one will be Dec 13 16h UTC. </p> <p> We use <a href=""></a>. Every tech talk has a defined topic and is open to everyone interested. </p> <p> If you want to get notified an hour before it starts, you can subscribe to the events on the website of the Pharo Association. </p> <p> <a href="">Register for the Dec 13 TechTalk here</a> </p>

November 28, 2016

Cincom Smalltalk - Week Long Hackathon

Have you ever dreamed of working side-by-side with one of the rock stars of the software development community? This could be the chance of your life! The JCSE at Wits […]

The post Week Long Hackathon appeared first on Cincom Smalltalk.

Andres Valloud - Smalltalks 2016 videos now available

You can see the videos from the Smalltalks 2016 conference here.  Enjoy!

November 27, 2016

Smalltalk Jobs - Smalltalk Jobs- 11/27/16

  • Malta, NYSoftware Development Engineer (16002159) at GLOBALFOUNDRIES
    • Required Skills:
      • BS Degree in EE or CS
      • 4-6 years of relevant experience
      • Demonstrated experience in database application programming (DB2 preferred, but Oracle or mySQL acceptable)
      • Demonstrated programming skill in Java, Smalltalk or similar object-oriented language
      • Demonstrated experience in programming/scripting for Windows and Linux operating systems
    • Wanted Skills:
      • Master’s Degree in EE or CS
      • Semiconductor industry experience in test lab setup and characterization, compact modeling, and/or IC design
      • Linux system administration experience
      • Database administration experience
Good luck with your job hunting,
James T. Savidge

View James T. Savidge's profile on LinkedIn

This blog’s RSS Feed

Filed under: Employment Tagged: jobs, Smalltalk, Smalltalk jobs

November 26, 2016

Pharo Weekly - Doing one step at a time

19377 Pharo 6 Morph>>#showActions broken

19339 MethodAnnouncement should has methodPackage information and provide packagesAffected and protocolsAffected

19391 FuelPlatform-Core
19365 remove dependency of Catalog on Nautilus

19367 testClassRespectsPolymorphismWithTrait does suppose full image

19295 originAtCenter looks like deadCode

19372 MethodFinderTest is dependent>>#testSearchForAccessAtOne is dependent on result order

17771 Empty stderr/stdout files should be deleted on image shutdown
19361 Morph>>#showActions broken

18330 Fuel still has platform classes in Pharo6 like FLPharo11Platform.

19381 KMSingleKeyCombination should be not printed with forced uppercases

19382 #add:finalizing: in AlienWeakTable sends unexistent message #copyGrownBy

19364 We need to be able to read utf8 strings from ExternalData

19354 FFIExternalStructures allways recompile its accessors in their first use.

19331 ClassRepackaged and MethodRepackaged should be subclassed from ClassAnnouncement and MethodAnnouncement

19349 RPackageAnnouncement should be SystemAnnouncement subclass and work as other system changes

18881 ChangesBrowser executing refactoring changes in wrong order
19360 Deprecated #selector call in MetacelloVersionConstructor>>#verifyVersionImportPragmas:definedIn:

19352 Conflict on package renaming if tag exists

19362 Make OSWindow as optional and unloadable

18918 Typo on welcome screen
19378 Rendering text in athens is broken (still not fixed)

19363 remove dependency of Rubric on SmartSuggestions

19275 Installing / Uninstalling Metalinks clears method list selection

19358 solve Nautilus-Versionner dependency

19373 MethodFinder class>>#methodFor: should provide sorted result

19329 New SystemAnnouncement is needed to signal that class modification was completely installed

19303 Classes should define systemIconName instead of systemIcon

19359 ProtocolRemoved is not announced when Nautilus removes empty protocols
19350 SystemAnnouncer cannot be reset in minimal/bootstrapped Pharo

19328 Undeclared ShortRunArray again

19326 failing test: testClassRespectsPolymorphismWithTrait

19335 Syntax highlighting do not work on methods with primitives that uses “ec”

19340 Can not step over methods with meta links

19343 Spec is now dependent on FastTable

19351 ClassTagAnnouncement is needed to describe operations with class tags
19348 apply automatic deprecation rewrite because of 19347

19333 17 more tests failing due to MockSettings class(Object)>>doesNotUnderstand: #mocksystemsettings SettingTreeBuilder>>mocksystemse
19338 Revert 18233 (improving Pragma API)
19323 ClassRemoved should provide information about affected package

18233 improving Pragma API

19320 Improve MethodClassifier logic
19251 Interval with step=0 is possible to create but most operations raise non-obvious exceptions

19290 helpAtCenter morphic property is only set to true

19297 Scrollbar lastPaneColor can be turned into an instance variable

19318 Add new Colors package to the BaselineOfPharoBootstrap
19296 PluggableButtonMorph property lastState can be turned into an instance variable

19293 mouseOverBorderStyle property in IconicButton can be turned in instance variables

17456 use fasttable for the add to package MC repository

19313 Move Color to Kernel

19316 Integrate BaselineOfPharoBootstrap

19299 Missing border after dragging out of a window group

18286 Provide notice of missing package description in CatalogBrowser

19309 RBSourceRegexRefactoring calls not existing method on RBClass

Pharo Weekly - Towards true headless


I am working on removing most of windowing code from the VM, and in trying to unify the platform specific code of the VM. In the MinimalistHeadless branch of I made the following changes:

– Unified standard CMake building scripts for Unixes. I hate autoconf. I want to use them in Windows too.
– Refactoring the Unix entry points. I am trying to remove a lot of code for simplfying stuff.
– Null window driver for true headless.
– Optional SDL2 based traditional display backend for compatibility reasons, and because the extra Morphic worlds using OSWindow are a bit unstable.

So far I managed to run a standard Pharo 6 image using this custom VM in Linux. Windows and Mac are coming next. Hopefully this is going to fix the problems with duplicated events when using OSWindow in Windows.

I am also planning on making a standard interface for embedding the VM in an application, at least as a static library. With this new building system, this seems to be easy to do.

BTW. When I tried the minimalistic Pharo image, in a completely headless VM, I got the following error:

[ “Ugh …. now this is a biggie – a system that does not support
any of the display depths at all.”
‘Fatal error: This system has no support for any display depth at all.’
inContext: thisContext.
Smalltalk quitPrimitive “There is no way to continue from here” ] in DisplayScreen>>findAnyDisplayDepth
DisplayScreen class>>startUp

As a workaround, I am doing the following for ioHasDisplayDepth with the null driver:

sqInt ioHasDisplayDepth(sqInt depth)
return true;

In DisplayScreen class >> startUp we have the following:
startUp “DisplayScreen startUp”
Display setExtent: self actualScreenSize depth: Display nativeDepth.
Display beDisplay

Does it make sense, to always trying to create a display in startup time?

Best regards,

November 23, 2016

Pharo Weekly - New Animation Package


I am happy to release the Animation package at last!!/~ThibaultRaffaillac/Animation
This is a general animation system, which can turn any setter message into a smooth transition (provided the target value supports + and *Float).

AnimationProperty new at: morph set: #position: to: 100@100 during: 2 seconds easing: #backOut.
AnimationProperty new at: morph set: #color: to: Color red during: 2 seconds easing: #linear.
AnimationProperty new at: morph set: #title: to: ‘tutututu’ during: 2 seconds easing: #linear.

Or equivalently (don’t choke):
morph position: (100@100 during: 2 seconds easing: #backOut).
morph color: (Color red during: 2 seconds).
morph title: (‘tutututu’ during: 2 seconds).

It basically sends the setter message repeatedly during the target delay, each time with a slightly different value. It should also work with Bloc, although the update mechanism depends on Morphic’s deferredUIMessage at the moment.


ps: Thanks to anonymous contributor for the second syntax, it was a lot of fun – and evil laughs🙂

November 22, 2016

Benoit St-Jean - Freewill in progress (5)


Not much new code was done since the last update.  But since I usually like to put my projects aside for a while just to have those « WTF-was-I-thinking » moments looking back at my own code, I took some time to scribble a skeleton of a FAQ and design a logo.

So coding of Freewill restarts today… with a fresh look at my code!


Classé dans:Pharo, Smalltalk, Squeak Tagged: Freewill, genetic algorithms, Pharo, Smalltalk, Squeak

Smalltalk Jobs - Smalltalk Jobs – 11/22/16

Two jobs, one in Frankfurt and one close to Amsterdam.

In Frankfurt there is permanent position in a mobility group that needs German, UML certification, and OOA/OOD.

Near Amsterdam there is a temporary job that needs 3 years of Smalltalk.  It looks like Dutch will be necessary as well.


Filed under: Employment

Bee SmaRT - Plugging Bee JIT and Compiler

This post should have been written long time ago. By now I already forgot many of the difficulties I found when plugging the JIT and Smalltalk compiler to Bee, but on the upside I now have a much bigger picture of the system so I can describe more things with more details than before.

Where can we start? A good place can be to compare our self-hosted runtime against the host VM. What are the differences between the JIT in Bee and the host VM? To answer that, we have to understand what a JIT is, what it is made of, and how it is plugged to the system. Good! now we have some concrete things we can describe.

What is a JIT compiler

Just-in-time compiler. Well, the last word tells most: it is a compiler, and the JIT part refers to the fact that it is thought for working simultaneously with the program being run, unlike things like GCC to mention some compiler, which are used to compile programs before they are run.

Smalltalk code, in most implementations is compiled to bytecodes. This comes from its early history, the famous Blue Book describes bytecodes extensively. When saving a method, the Smalltalk compiler is triggered to convert the text to bytecodes. So you might think that the Smalltalk compiler is a kind of JIT-compiler, but it is not. At least not in the usual sense of the word, or what is generally known as an actual JIT-compiler. After compilation to bytecodes, at the point where the method is actually going to be invoked, those bytecodes have to be executed in some way. That is, invocation of a method means having computations done to alter the program's execution context. The approach that JIT-based VMs take to execute methods is to translate them to native code just before execution.

In the case of Bee, the VM translates the method's bytecodes to native code. Running a method is actually executing the native code derived from the method's bytecodes. Bee is not an interpreted Smalltalk, which means that always, before any method is run, it will be nativized. Generation of a method's native code can be done at any time before its execution. Usually nativization happens during lookup: the activation of a message-send will cause the invocation of a compiled method; the lookup algorithm checks if that method has native code already generated, and if not, asks the JIT to translate from bytecodes to native code.

But lookup is not the only moment at which native code for a method can be generated. Nativization could be done ahead-of-time (AOT), and a JIT-compiler that allows for this is sometimes called an AOT-compiler. Bee not only provides, but also requires, an AOT-compiler, as we will see below.

Internals of JIT compilers

The main work that our JIT compiler accomplishes is to convert from bytecodes to native code, but how does this conversion work? To start grabbing an idea, we can first see how bytecodes look like, and how they relate to source code. Consider this simple method:

    ^3 + 4

The Smalltalk compiler will process this text and produce a CompiledMethod with these bytecodes:

[16r18] load R with SmallInteger 3
[16r19] push SmallInteger 4
[16rF7] send selector #+
[16r48] return

Basically, what we have is a stack machine with some special registers: R is the receiver and return register, there are some more (not mentioned here). Then the work the JIT has to do is to transform bytecodes to native instructions.

In this case, what we will get is something like:

prologue: ...
method: mov EAX, 7      ;  load R with SmallInteger 3
        push 9          ;push SmallInteger 4
        call lookup #+
epilogue: ...

The method label describes the most interesting part, where bytecodes got converted to native instructions (EAX is both the receiver and return register in our calling convention). The labels prologue and epilogue consist of a few instructions for constructing and desconstructing a stack frame.

The way our JIT-compiler is implemented is very straightforward: it iterates each bytecode, assembling the corresponding native instructions each time:

    self emitPrologueAndAlign.
        [self bytecodeIndex < self bytecodeSize] whileTrue: [
            self saveBytecodeNativeAddress.
            self translateSingleBytecode: self nextBytecode].
    self emitEpilogue

Plugging the JIT compiler to a classic VM

The final step, when you have a JIT compiler that is able to translate any method, is to plug it to the VM. There are a few places there that are affected by its presence, mainly the lookup mechanism and the Garbage Collector. In the case of a classic VM, the typical places would be:

Implementation of lookup

The VM will check if the method found has native code and if not trigger the nativizer, like in the following simplified code:

void lookupAndInvoke(oop *receiver, oop *selector) {
    Method *method = global_cache->lookup(receiver, selector);

    if (method->native_code() == nil)


void GlobalLookupCache::lookup(oop *receiver, oop *selector)
    Class *class = receiver->class();
    Method *method = lookup_in_cache(class, selector);
    if (method != nil)
        return method;

    method = class->find_in_method_dictionary(selector);
    this->add_to_cache(class, selector, method);

We don't provide here a description of how the cache is indexed exactly, but you can think of it as if it were just a low-level C array or vector.

When methods are changed in the system

The VM needs to be told when any method is changed in the system, so that it can update the cache. This is usually done with a primitive:

MethodDictionary>>#flushFromCache: aSymbol
    <primitive: FlushFromCodeCache>

The primitive could be implemented with something like this:

void FlushFromCodeCache(oop *selector)

During GC

The low level array pointers have to be updated, as compiled methods, classes and selectors could be moved. This will require just a special case in the GC to trace the pointers in the array.

Finally, to make all this work, the VM is compiled to native instructions. Then both the JIT, the primitives and the GC are just called from the corresponding places to make things work. How does Bee JIT differ from the one of the VM then?

Plugging the JIT to Bee self-hosted runtime

The first thing to notice is that Bee JIT is implemented in Smalltalk. Thus, it consists of a bunch of compiled methods, and not of "native code". So Bee JIT cannot be just linked into Bee self-hosted runtime and start nativizing methods as required during lookup. That takes a bit more of effort, as it requires someone to first convert the JIT methods to native code, a chicken and egg problem. But this  problem can be "easily" fixed: we can take our Smalltalk JIT and execute it inside the host VM, using it to translate its own methods! That would be, to nativize itself ahead-of-time. The result is a set of compiled methods with their associated native instructions.

We have to be careful, and make out nativized JIT behave slightly different than the host VM JIT, as it should not generate code with references to the host VM. For example, when a message-send bytecode is translated, instead of calling the host VM lookup, it has to call a different one which is stored in Bee kernel. The problem of referencing external things, particularly objects in Bee kernel, is already solved by our Smalltalk libraries framework. The final step to plug the nativizer is then to generate a Smalltalk library, one that can be loaded by Bee kernel, and that contains both the JIT methods and their corresponding native code.

As for plugging the JIT to the Smalltalk world, many things are simplified because all things are implemented within the same paradigm. The lookup is already coded in Smalltalk, and the only thing needed is to call our JIT when finding a method that doesn't have native code yet:

Object>>#_lookupAndInvoke: selector
    | cm nativeCode |
    cm := anObject _cachedLookup: selector.
    cm == nil ifTrue: [^anObject doesNotUnderstandSelector: selector].
    cm prepareForExecution.
    nativeCode := cm nativeCode.
    ^anObject _transferControlTo: nativeCode code

    self isNativized ifFalse: [self nativize].
    nativeCode refresh

nativeCode := BeeNativizationEnvironment current nativeCodeFor: self

Regarding the global lookup cache, as it contains just a reachable Smalltalk array, there is no need to make a special case for traversing it during GC. The #flushFromCache: implementation is not a primitive anymore, it just another Smalltalk method that traverses the cache looking for methods that correspond the flushed selector.

GlobalDispatchCache>>#flush: selector for: behavior
    | index |
    index := self indexOf: selector with: behavior.
        at: index put: nil;
        at: index + 2 put: nil;
        at: index + 4 put: nil

Interestingly, the #nativize method is dynamically bound, and is loaded when the JIT compiler library is bound, only if we tell Bee to load the JIT. We can, using the same technique we used for the JIT, ship any other library pre-nativized, so that we don't need to load the JIT if we don't want to, or if we don't plan to dynamically modify code:

Besides, the Smalltalk compiler is also packaged in an optional library, so we can get the following workflow:

This can be good for saving system resources, and also for performance reasons: as the code shipped with our libraries is nativized ahead of time, we can afford spend more time optimizing it, delivering code that is much faster than naively JITted code. I'll write more about that in the future, but that's going to be in another post, I hope you enjoyed this one!

November 21, 2016

Pharo Weekly - Chip8 Emulator

Pharo is a great community. Thursday I asked if we got an emulator for Chip8 ( and I started to code it but got sick and Monday Henrik sent a little mail with a full implementation. Super cool🙂!/~Latsabben/Chip8

Do not let your kids get close to your keyboard and have fun.

| program emulator |
“C8Programs downloadGamesPackZophar.”
program := C8Programs programNamed: ‘ZopharPack:PONG’.
emulator := C8Emulator new.
emulator loadProgram: program.
emulator asMorph
extent: 800@600;
primaryColor: Color gray;
secondaryColor: Color black;
disabledColor: (Color orange alpha: 0.3);
instructionsPerStep: 10;

November 20, 2016

Smalltalk Jobs - Smalltalk Jobs – 11/20/16

  • Bangalore, IndiaDeveloper through Wipro
    • Required Skills:
      • 3-5 Years Experience
      • Smalltalk
      • .NET
      • C#
      • Manual Testing
      • Coding Standards
    • Wanted Skills:
      • CA7 – Mainframe Production Control Scheduling Program
      • QMF
  • Warren or Basking Ridge, NJProgrammer at Chubb
    • Required Skills:
      • Overall experience of one to three years in IT
      • Server-side Java/J2EE (1-2 years)
      • Smalltalk development (1-2 years)
      • Mainframe development (1 – 2 years)
      • Familiarity with: JSP, JSF, JPA, JMS, EJB, JUNIT, COBOL, CICS, MQ, COBOL, DB2, JCL, ZEKE, CLISTS.
      • Experience with Java, JEE, XML, Web Services (SOA, REST),IBM WAS, RAD, RTC)
      • Good understanding of ORACLE and DB2
      • Understanding of Domain Driven Design
      • Mapping XML to Domain Objects to Databases
    • Wanted Skills:
      • Insurance Industry Experience
      • Web 2.0 with Ajax, DOJO, HTML and Javascript
      • Building browser based user interfaces
      • Web usability
      • Bachelor’s Degree in Computer Science or a similar major preferred
  • Fremont, CASoftware Engineer 1 (Recent Graduate) at Lam Research
    • Required Skills:
      • Obtaining a BS, MS in electrical engineering, computer science, software engineering or related field
      • Good knowledge of object-oriented design methods and languages
      • Basic knowledge of real-time operating system, hardware and software interface, real-time control, motion control
      • The ability to effectively use Windows based applications
      • Evidence of strong analytical, problem solving, influence, teamwork, business partnering, and communication skills (both written and verbal)
      • The ability to work and deliver results in a dynamic, cross functional, team orientated environment
      • Knowledge and interest in the semiconductor industry
      • A genuine interest in advanced technology and an on-going desire to learn
    • Wanted Skills:
      • Smalltalk
      • Adobe Acrobat and/or PhotoShop
  • Mumbai, IndiaKapital Financial Developer through Randstad Technologies
    • Required Skills:
      • an understanding of an object oriented programming language (e.g. Java, C++, C#, Python, Ruby, Smalltalk) and their underlying principles
      • SmallTalk experience
      • Total industry experience of 10+ years
      • Data modelling
      • Code version control
      • Understanding of performant coding and optimisations
      • Enthusiasm for increasing knowledge of financial markets and products is essential
      • Willingness to adopt an agile development process
Good luck with your job hunting,
James T. Savidge

View James T. Savidge's profile on LinkedIn

This blog’s RSS Feed

Filed under: Employment Tagged: jobs, Smalltalk, Smalltalk jobs

Pharo News - [ANN] Pharo MOOC: Online Course

<p> The Pharo MOOC is a new online course about Live Object Programming in Pharo. </p> <ul> <li>More information and registration <a href="">here</a></li> <li>The Teaser-trailer is <a href="">online</a>: </li> </ul> <iframe width="640" height="480" autoplay="false" src="" frameborder="0" allowfullscreen></iframe>

Pharo News - Pharo 5.0 Released!

<p> Dear World, </p> <p> The time has come for <a href="">Pharo 5.0</a>! </p> <p> <strong>Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.</strong> </p> <p> <img src="/web/files/posts/pharo50-screenshot.png" width="100px%"/> </p> <p> This is our most significant release yet. Here are some highlights: </p><ul> <li>The PharoVM is now based on Spur, the new memory management, and it brings with it a 35% speedup!</li> <li>A new unified foreign function interface (UFFI) replaced NativeBoost to provide a strong Spur-compatible framework for interfacing with the outside world.</li> <li>The Glamorous Toolkit now includes the GTDebugger to offer a moldable infrastructure that allows the developer to customise the debugger deeply.</li> <li>The underlying Reflectivity mechanism has reached maturity with multiple pieces coming together to empower developers to instrument their own systems. For example, we now have breakpoints implemented as just a simple extension of this mechanism.</li> <li>QualityAssistant is now part of the image to provide live feedback during development.</li> </ul> <p> These are just the more prominent highlights, but the details are just as important. We have closed 2446 issues in Pharo 5.0. Take a moment to go through a <a href="">more detailed recount of the progress</a>. </p> <p> While the technical improvements are significant, just think of getting 30% faster out-of-the-box, still the most impressive fact is that the new code that got in the main Pharo 5.0 image was contributed by 100 people. Together we have touched 43% of the classes, and 20% of the methods. The following visualisation rendered with Roassal in Pharo 5.0 is dedicated to this effort. The picture shows the touched classes and packages in gray, the authors and the links to the changed classes in red, and, using an automatically generated visual id, you can spot authors that have worked on similar projects. </p> <p> <img src="/web/files/posts/pharo50-contributors.png" width="100px%"/> </p> <p> Pharo is more than code. It is an exciting project involving energetic people. We thank all the contributors of this release: </p> <p> Abdelghani Alidra, Clara Allende, David Allouche, Nicolas Anquetil, Thibault Arloing, Jean Baptiste Arnaud, Mangesh Bendre, Clement Bera, Alexandre Bergel, Torsten Bergmann, Usman Bhatti, Vincent Blondeau, Johan Brichau, Camillo Bruni, Miguel Campusano, Damien Cassou, Nicolas Cellier, Danny Chan, Andrei Chis, Christopher Coat, Ben Coman, Bernardo Contreras, Gabriel Omar Cotelli, Tommaso Dal Sasso, Paul De Bruicker, Sean De Nigris, Christophe Demarey, Simon Denier, Marcus Denker, Martin Dias, John Dougan, Stephane Ducasse, Stephan Eggermont, Johan Fabry, Sergio Fedi, Cyril Ferlicot, Holger Hans Peter Freyther, Joshua Gargus, Tudor Girba, Thierry Goubier, Kris Gybels, Norbert Hartl, Thomas Heniart, Dale Henrichs, Nicolai Hess, Alejandro Infante, Henrik Johansen, Goran Krampe, Pavel Krivanek, Juraj Kubelka, Denis Kudriashov, Matthieu Lacaton, Laurent Laffont, Kevin Lanvin, Jannik Laval, Alexander Lazarević, Skip Lentz, Max Leske, Dave Lewis, Esteban Lorenzano, Sheridan Mahoney, Mariano Martinez Peck, Max Mattone, John McIntosh, Rene Meusel, Eliot Miranda, Henrik Nergaard, Marion Noirbent, Merwan Ouddane, Nick Papoulias, Nicolas Passerini, Alain Plantec, Guillermo Polito, Damien Pollet, Baptiste Quide, Andreas Raab (RIP), Alain Rastoul, Stefan Reichhart, Lukas Renggli, Mark Rizun, Michael Rueger, Valentin Ryckewaert, Ronie Salgado, Udo Schneider, Boris Spasojevic, Igor Stasenko, Roger Stebler, Serge Stinckwich, Aliaksei Syrel, Camille Teruel, Pablo Tesone, Yuriy Tymchuk, Peter Uhnak, Masashi Umezawa, Dion Stewart, Sven Van Caekenberghe, Jan Van De Sandt, Benjamin Van Ryseghem, Toon Verwaest, Franck Warlouzet. </p> <p> (If you contributed with Pharo 5.0 development in any way and we missed your name, please send us a mail and we will add you). </p> <p> Enjoy! </p> <p> <em>The Pharo Team</em> </p> <ul> <li>Try Pharo: <a href=""></a></li> <li>Learn Pharo: <a href=""></a></li> </ul>

November 16, 2016

Nicolas Petton - Interview with Damien Cassou

This is the sixth post of my series of interviews of my colleagues at FTGP.

This is my second interview of Damien, the first one was done when we were both working at Inria, in the RMoD team. Back then we shared our office together with Benjamin, another former member of RMoD now working with us!

With Damien we often hack Emacs packages, pair program and discuss nerd things like self-hosting or Free Software.

Damien Cassou at work image

Figure 1: Damien at work

Read the interview.

Pharo Weekly - Bloc and Brick on github

Hi all,
I am pleased to announce that Bloc and Brick successfully moved to GitHub.
This means that the versions on SmalltalkHub are no longer maintained.
You can find installation procedures on github.

– a single place for all graphics-related projects (Bloc, Brick and maybe Sparta and Roassal in the future, i hope)
– benefit from git possibilities
– benefit from github tools
– more visibility

Some news in Bloc:

  • End of Athens support
  • Support for MS Windows (libMoz2D binary)
  • Static linear and radial GradientPaints
  • BoxShadow effect based on Sparta filters
  • Improvement of BlAnimation
  • Drag & Drop basis

Not much news in Brick:

  • Now Brick is based on the latest version of Bloc
  • Now Brick includes Styles and Theme (moved from Bloc to Brick)
  • First attempt for ColorPalette api (to be confirmed)
  • Material stuff is moved on a separated package (Brick-Material)
  • No more dependencies to PetitCSS / PetitParser in Styles (full smalltalk api)
  • [Warning] TextInput-related widgets are broken, waiting for SpartaEditor api
  • [Warning] Brick has been updated and moved to Github yesterday so it is possible that there are some issues during installation (not yet well tested)

Thanks for your interest in Bloc & Brick,
Best regards,

Pharo Weekly - NeoCSV at Work :)


I know a lot of people are interested in (public) datasets (to use as examples). The website contains a (small) number of interesting ones. Here is how to access them using NeoCSV.

(NeoCSVReader on:
 '' asUrl retrieveContents readStream) upToEnd.


ZnClient new
 url: '';
 contentReader: [ :entity | (NeoCSVReader on: entity readStream) upToEnd ];

Of course, they don't use UTF-8 and don't advertise it, so on some datasets you need to do something extra.

(NeoCSVReader on:
     value: ZnCharacterEncoder latin1
     during: [ '' asUrl retrieveContents ])
     readStream) upToEnd.

(Warning: this last example is quite large, 500K records).


November 15, 2016

Cincom Smalltalk - Cincom Smalltalk Helps Nielsen Scarborough Measure Primetime Television Ratings in the 2016 Presidential Election

According to Variety, 40.77 million Americans watched Donald Trump win the 2016 presidential election on the night of November 8. This number was calculated according to Nielsen’s preliminary primetime ratings between the […]

The post Cincom Smalltalk Helps Nielsen Scarborough Measure Primetime Television Ratings in the 2016 Presidential Election appeared first on Cincom Smalltalk.

November 14, 2016

Pharo Weekly - WKHTML2PDF for Pharo 50/60


WKHTML2PDF is now available for Pharo 5/6. You can load it from Catalog in Pharo 5/6. So if you like to convert HTML or URLs to a 
PDF use 

        convert: ''
        toFile: 'pharo.pdf'

then check it out. Note that I only had the need to make it work on Windows. If someone
adopts to Linux/Mac tell me and we include the contribution.

Project is on STHub as before:!/~TorstenBergmann/WKHTML2PDF 


Torsten Bergmann - Scripting Unreal with Pharo

Kilon is working on bridging with CPP code (using shared memory approach). Still not finished - but he made some progress by remote driving Unreal engine. Read more.

Torsten Bergmann - Refactoring Example in Smalltalk

A nice example of the refactoring capabilities of Smalltalk (here Pharo). Refactor until you are satisfied with the code and make sure your tests run green.

Cincom Smalltalk - ‹Programming› 2017 Call for Papers

<Programming> 2017, the International Conference on the Art, Science and Engineering of Programming, will take place in Brussels, Belgium on April 3-6, 2017. This new conference and journal (with an […]

The post ‹Programming› 2017 Call for Papers appeared first on Cincom Smalltalk.

November 13, 2016

Pharo Weekly - Scripting Unreal with Pharo

Annnddddd…. I DID IT !!!

I accomplished connecting Pharo with Unreal so I can script it with Pharo. It works from inside the editor and for the game as standalone. True live coding🙂
I am amazed how fast it is, but then I guess it should be expected with shared memory.  You can watch a short demo here
When I first created the loop, nothing happened.
So naturally I expected that my CPPBridge was not working, my loop is basically going from 1 to 150 (z axis), 10 times. After inserting a delay of just 10 milliseconds I could see movement.
So apparently without the delay Pharo , Unreal and CPPBridge are so fast that do 10 times movement of 1 to 150 in under one frame !!!!! So now I will have to slow down thing to make them work as I want !!! LOL!!!! I expected to be fast but nowhere that fast.
Not that I am complaining.
But this is just the first step, now I will slowly and steadily start to wrap Unreal Engine 4.13 API for Pharo.
Its a dream to use Pharo professionally🙂
Dimitris Chloupis

November 11, 2016

Pharo Weekly - Sven’s Magic Touch

I wanted to get all the lines of

And ZnEasy get: ‘;

did not like to proceed…

Here is Sven trip and tricks at work!

This page returns text that is latin1 (iso-8859-1) encoded, but describes it as ‘text/plain’ without further qualification. Zn then assumes the encoding is utf8 (the most reasonable default today). Mime-types can specify the encoding as follows: ‘text/plain;charset=utf8’ or ‘text/plain;charset=latin1’.

Here is how to override the default in Zn

value: ZnCharacterEncoder latin1
during: [
ZnClient new
get: ‘’ ]) lines.

The above will give you an array of 336531 words (it is a bit slow because it is lot of data).

This is a common problem😉

November 10, 2016

Pharo Weekly - new back end


We have changed the backend of the Pharo Association.

If you ever joined the association in the past, please consider to re-subscribe.

We have added already all existing active members, in this case you should
have already received a new password.

For all questions, do not hesitate to contact


November 09, 2016

Pharo Weekly - Breaking the 4GB barrier with Pharo 6 64-bit

OK, I am quite excited about the future possibilities of 64-bit Pharo. So I played a bit more with the current test version [1], trying to push the limits. In the past, it was only possible to safely allocate about 1.5GB of memory even though a 32-bit process’ limit is theoretically 4GB (the OS and the VM need space too).

Allocating a couple of 1GB ByteArrays is one way to push memory use, but it feels a bit silly. So I loaded a bunch of projects (including Seaside) to push the class/method counts (7K classes, 100K methods) and wrote a script [2] that basically copies part of the class/method metadata including 2 copies of each’s methods source code as well as its AST (bypassing the cache of course). This feels more like a real object graph.
I had to create no less than 7 (SEVEN) copies (each kept open in an inspector) to break through the mythical 4GB limit (real allocated & used memory).
Screen Shot 2016-11-09 at 11.25.28.png

I also have the impression that the image shrinking problem is gone (closing everything frees memory, saving the image has it return to its original size, 100MB in this case).
Great work, thank you. Bright future again.
PS: Yes, GC is slower; No, I did not yet try to save such a large image.
| meta |
ASTCache reset.
meta := Dictionary new.
Smalltalk allClassesAndTraits do: [ :each | | classMeta methods |
  (classMeta := Dictionary new)
    at: #name put: each name asSymbol;
    at: #comment put: each comment;
    at: #definition put: each definition;
    at: #object put: each.
  methods := Dictionary new.
  classMeta at: #methods put: methods.
  each methodsDo: [ :method | | methodMeta |
    (methodMeta := Dictionary new)
      at: #name put: method selector;
      at: #source put: method sourceCode;
      at: #ast put: method ast;
      at: #args put: method argumentNames asArray;
      at: #formatted put: method ast formattedCode;
      at: #comment put: (method comment ifNotNil: [ :str | str withoutQuoting ]);
      at: #object put: method.
    methods at: method selector put: methodMeta ].
  meta at: each name asSymbol put: classMeta ].

Sven Van Caekenberghe
Proudly supporting Pharo

November 08, 2016

Pharo Weekly - PetitParser2


I am happy to announce the availability of PetitParser2, a wonderful redesign developed by Jan Kurš of the original PetitParser.
– it introduces the compiler facility that speeds up parsers by a factor of ~2-5x
– it introduces the possibility of parsing streams without having them in memory
– it comes with a new structure internally that makes it more flexible
– it introduces asPParser (not a typo) to be able to have the new version working in parallel with the classic asParser
The version is already present in the latest Moose 6.1 in parallel with PetitParser. Also, several of the parsers that are shipping with PetitParser were already copied to PetitParser2 as well.
You can find more details here:
Some more documentation will follow.
I think Jan did a wonderful job and the result is quite exciting. Please take a look and let us know what you think.

Pharo Weekly - A cool automatic method categoriser


I have been enhancing the old method classifier developed by Diego Fernandez and I release it now so that others can have a look and that as part of the process we get a better method categorizer. Check the package comment at the end of this blog to see possibilities.

You can install

MCSmalltalkhubRepository owner: ‘Pharo’ project: ‘Pharo60Inbox’ user: ” password: ”


Here is a typical example:

| myRule | 
myRule := MethodCategorizationRule whenSelectorMatches: 'initialize*' categorizeIn: #initialization. 

(AutomaticMethodCategorizer using: myRule) categorizeAllMethodsOf: MyClass

API You can categorize at different levels of granularity.

  • categorizeAllMethodsOf: aClass
  • categorizeAllUncategorizedMethodsOf: aClass
  • categorizeMethod: aMethod
  • categorizeMethods: methods

Now the package includes also a little tool: a ProtocolAnalyzer

ProtocolAnalyzer to the Rescue

ProtocolAnalyzer is a tool to collect some analyses on selectors categorisation.

 First some simple statistics

The following shows that in the image in which this comment was written most of the printOn: messages are all categorized in printing.

self new statisticFor: #printOn:

{377->#printing. 3->#accessing. 1->#ui. 1->#private. 1->#transmitting}


Now for initialize we see that it is not the case.

 self new statisticFor: #initialize

{934->#initialization. 85->#’initialize-release’. 50->#initialize. 10->#’as yet unclassified’. 7->#accessing. 5->#initializing. 3->#’instance initalization’. 1->#’initalize-release’. 1->#testing. 1->#’class initialization’. 1->#actions. 1->#drawing. 1->#displaying. 1->#tests. 1->#shout} {867->#initialization. 85->#’initialize-release’. 12->#’as yet unclassified’. 8->#initializing. 6->#accessing. 3->#’instance initalization’. 1->#’initalize-release’. 1->#testing. 1->#’class initialization’. 1->#’updating screen’. 1->#actions. 1->#drawing. 1->#displaying. 1->#tests. 1->#shout}


Miscategorized methods

Now we can get a list of all miscategorized method definitions.

self new findInconsistenciesForASelector: #initialize thatIsNotInProtocol: ‘initialization’


Fixing miscategorized methods


self new fixInconsistenciesOf: #printOn: toBeInProtocol: ‘printing’


Package Comment as a Kind of Analysis

I’m a package to support the analysis and application of consistent rule-based method categorisation. I have been designed some years ago by Diego Fernandez and evolved by Stéphane Ducasse. Now it got released so that people can play with it and decide what to do. My main classes are AutomaticMethodCategorizer MethodCategorizationRule and ProtocolAnalyzer

Now the design of this method categoriser is less efficient than the default one. AutomaticMethodCategorizer is based on first class rules while MethodCategorizer is based on dictionaries.

AutomaticMethodCategorizer is more flexible:

  • It can manage different rules groups
  • The order of the rules can be changed.

One possibilty can be to

  • Extract ProtocolAnalyzer as a separate project
  • Create classes out of the dictionaries of MethodCategorizer and make the lookup customizable In any case it would be good
  • To generate refactorings so that we can use the current tools to see the result of a classification
  • To put the classification on so that methods are automatically classified on accept.

Now if you want to help please contact me.