Planet Smalltalk

October 17, 2017

Cincom Smalltalk - Smalltalk Digest: October Edition

The October Edition of the Cincom Smalltalk Digest.

The post Smalltalk Digest: October Edition appeared first on Cincom Smalltalk.

ESUG news - Toronto User Group: Monday, November 13

The next meeting of the Toronto Smalltalk User Group meeting will be Monday, November 13:

A follow up on Kruti Dave's work on programming environments for naive programmers, Matthew Ralston's work on context-less methods in Pharo/Squeak Smalltalk, and a discussion on what was presented at ESUG.

More infos:

Cincom Smalltalk - Smalltalks 2017 – Additional Activities Registration Now Open

Smalltalks 2017 is the 11th conference on Smalltalk-based technologies, research and industry applications.  This renowned conference will be held in La Plata, Argentina on November 8-10 at Universidad Nacional de […]

The post Smalltalks 2017 – Additional Activities Registration Now Open appeared first on Cincom Smalltalk.

October 15, 2017

Pharo Weekly - Open AL script

Hi Phil,

I did that using Ronie’s OpenAL binding and Merwann’s wav parser back in 2014-2015:

owner: ‘ronsaldo’
project: ‘OpenAL’

owner: ‘MerwanOuddane’
project: ‘WAVParser’

I did things such as (build yourself something derived from this code I did not check if it works):

WAVParser wavFromStream: (‘resources/music/spellNoise.wav’ asFileReference readStream binary readStream).
contextAttributes := ALContextAttributes new.
device := OpenALC openDefaultDevice.
context := device createContext: contextAttributes asList.
context process.
context currentDuring: [
“Create the buffer”
buffer := self makeBufferFromHeader: wav header data: wav data asByteArray.
“Create the source”
source := OpenAL genSource.
OpenAL sourcei: source param: AL_BUFFER value: buffer.
“Play the source”
OpenAL sourcePlay: source.
“Play for sometime ”
(Delay forSeconds: wav header soundDuration) wait.
“Delete the source and the buffer”
OpenAL deleteSource: source;
deleteBuffer: buffer
OpenALC nullCurrentContext.
context destroy.
device close.

MyClass>>makeBufferFromHeader: header data: data
| buffer |
buffer := OpenAL genBuffer.
OpenAL bufferData: buffer format: (self readFormatFromHeader: header) data: data size: data size freq: header sampleRate.
^ buffer

MyClass>>readFormatFromHeader: header
^ header channels = 1
ifTrue: [
header bitsPerSample = 8
ifTrue: [ AL_FORMAT_MONO8 ]
ifFalse: [ AL_FORMAT_MONO16 ] ]
ifFalse: [
header bitsPerSample = 8
ifFalse: [ AL_FORMAT_STEREO16 ] ]

I am pretty sure with a little work those things could work again. I have never succeeded in playing mp3 files from Pharo though (but I’m on mac and I remembered trying solutions that did not work on Mac but may work on other OS).

Have fun guys 🙂

Stefan Marr - Debugging Concurrency Is Hard, but We Can Do Something About It!

When we have to debug applications that use concurrency, perhaps written in Java, all we get from the debugger is a list of threads, perhaps some information about held locks, and the ability to step through each thread separately.

What we usually don’t get is any kind of high-level support for the concurrency abstractions that we used in our applications. We might have used a library for actors, channels from CSP, Java’s fork/join pool, or perhaps even some software transactional memory. This means, in the debugger, we cannot reason anymore about the same concepts we used to built the application. Instead, we can only vaguely recognize them from how the threads interact. We might see that one thread puts an object, which is perhaps a message, into another object, which represents a mailbox. But we don’t get any support to actually follow that message as it is being processed. We also have no way of jumping from the point where we spawn a fork/join task to its activation to see the computation unfold recursively and in parallel. And wouldn’t it be nice if we could simple set a breakpoint on a promise and see where we continue executing when it got resolved?

I am pretty sure these things would make it easier to understand what’s going on in my applications. Unfortunately, debugger support for such high-level concepts is rare or non-existing.

One of the biggest problems is that there are too many different concurrency models, concepts, languages, and libraries. This means designing debugging support for all these variations is a huge problem. And using the same debugger for Akka actors, Erlang, Pony, or your favorite actor library doesn’t seem feasible. Not to mention all those other systems. You want to debug goroutines and their use of channels, Clojure’s core.async, or perhaps Java’s JCSP?

Turns out, building a debugger for all these things isn’t impossible. We can design the debugger in a way that it can remain completely oblivious of the various concurrency concepts. This means, it can be used for a wide range of concurrent systems without having to be adapted specifically for them. To make this work, we propose the Kómpos protocol to communicate the necessary details from a language runtime to the debugger in a concurrency-agnostic way.

For a small demo, see the video below. The abstract for our paper describing the details of the approach, as well as links to it follow afterwards.

For questions or comments, please find me on Twitter @smarr.


Today’s complex software systems combine high-level concurrency models. Each model is used to solve a specific set of problems. Unfortunately, debuggers support only the low-level notions of threads and shared memory, forcing developers to reason about these notions instead of the high-level concurrency models they chose.

This paper proposes a concurrency-agnostic debugger protocol that decouples the debugger from the concurrency models employed by the target application. As a result, the underlying language runtime can define custom breakpoints, stepping operations, and execution events for each concurrency model it supports, and a debugger can expose them without having to be specifically adapted.

We evaluated the generality of the protocol by applying it to SOMns, a Newspeak implementation, which supports a diversity of concurrency models including communicating sequential processes, communicating event loops, threads and locks, fork/join parallelism, and software transactional memory. We implemented 21 breakpoints and 20 stepping operations for these concurrency models. For none of these, the debugger needed to be changed. Furthermore, we visualize all concurrent interactions independently of a specific concurrency model. To show that tooling for a specific concurrency model is possible, we visualize actor turns and message sends separately.

  • A Concurrency-Agnostic Protocol for Multi-Paradigm Concurrent Debugging Tools, S. Marr, C. Torres Lopez, D. Aumayr, E. Gonzalez Boix, H. Mössenböck; In Proceedings of the 13th ACM SIGPLAN International Symposium on Dynamic Languages, DLS'17, ACM, 2017.
  • Paper: HTML, PDF
  • DOI: 10.1145/3133841.3133842
  • BibTex: bibtex
      abstract = {Today's complex software systems combine high-level concurrency models. Each model is used to solve a specific set of problems. Unfortunately, debuggers support only the low-level notions of threads and shared memory, forcing developers to reason about these notions instead of the high-level concurrency models they chose.
      This paper proposes a concurrency-agnostic debugger protocol that decouples the debugger from the concurrency models employed by the target application. As a result, the underlying language runtime can define custom breakpoints, stepping operations, and execution events for each concurrency model it supports, and a debugger can expose them without having to be specifically adapted.
      We evaluated the generality of the protocol by applying it to SOMns, a Newspeak implementation, which supports a diversity of concurrency models including communicating sequential processes, communicating event loops, threads and locks, fork/join parallelism, and software transactional memory. We implemented 21 breakpoints and 20 stepping operations for these concurrency models. For none of these, the debugger needed to be changed. Furthermore, we visualize all concurrent interactions independently of a specific concurrency model. To show that tooling for a specific concurrency model is possible, we visualize actor turns and message sends separately.},
      acceptancerate = {0.64},
      author = {Marr, Stefan and Torres Lopez, Carmen and Aumayr, Dominik and Gonzalez Boix, Elisa and Mössenböck, Hanspeter},
      blog = {},
      booktitle = {Proceedings of the 13th ACM SIGPLAN International Symposium on Dynamic Languages},
      day = {24},
      doi = {10.1145/3133841.3133842},
      html = {},
      interhash = {fd0460a53c7ec4f41c14ccb10cc22a9f},
      intrahash = {9f119d2833c39979c7d679e49b067abe},
      isbn = {978-1-4503-5526-1/17/10},
      location = {Vancouver, Canada},
      month = oct,
      note = {(acceptance rate 64%)},
      numpages = {12},
      pdf = {},
      publisher = {ACM},
      series = {DLS'17},
      title = {{A Concurrency-Agnostic Protocol for Multi-Paradigm Concurrent Debugging Tools}},
      year = {2017},
      month_numeric = {10}

October 12, 2017

Pharo Weekly - Building-With Versus Building-On

Pharo Weekly - Libusb binding


A bit late, there is a Libusb [1] binding (using UFFI) and support for the Human Interface Device [2] (that uses the binding but is written in pure Smalltalk) for Pharo.
Everything is on the github repository [3]. « Install »  and « Quick start »  sections give you all you need to start using the project.
One could also have a look at the wiki [4].
It works on Linux but hasn’t been tested on Mac OS nor Windows (it should work since libusb library works on these platforms).
Do not forget to install the 32 bits versions of libusb on your computer.
The purpose of this library is to provide the ability to use USB devices directly from Pharo.
For example, one could get data from a PS3 controller, a mouse, a keyboard, an Arduino device, etc…

Pharo Weekly - Last PR log



20442 open the welcome window

20462 An error in the Tests never break the build


20440 integrate ReferenceFinder


20461 Update Hermes to v2.2.1


20410 Undeclared variables should be compiled with explicit class UndeclaredVariable


20421 Email should run in a node and separate stage to be sent


20447 SystemVersion>>highestUpdate not initialized and nil


20459 Comment class ImportingResourceHelp

20444 FFIExternalStructurePlatformTests cleanup (is32/64bit)

20445 Uncategorized or wrongly categorized deepCopy, veryDeepCopy, shallowCopy and postCopy methods


20458 Two uncommented classes in Reflectivity package

20446 Properly categorize finalize and finalizeValues


20443 SDL_Event not initialized


20435 The CI process should fail if the conversion fails


20415 Restore the extra morphic worlds properly on startup


20434 use Ring2 during the bootstrap


20431 Move initialization of Color, InstructionStream and SmallInteger


20437 Uncategorized methods in RFCondition and RFMessageNode


20436 Pull request URL in build information e-mail is wrong


20423 Add health check that all class instance variable names in the system are lowercase


20429 ContextTest>>#testSetUp is dependent on Opal

20433 Fix the parsing of the PR description when sending the mail


20428 ClassTest (Kernel-Tests) is dependent on System-Changes

20424 standalone SUnit tests are failing after integration of the new version of Hermes


Torsten Bergmann - Libusb binding and HID for Pharo

There is a Libusb  binding (using UFFI) and support for the Human Interface Device - HID (that uses the binding but is written in pure Smalltalk) for Pharo. Code is on GitHub.

Read the announcement

Torsten Bergmann - Software exploration tool Moose2Model for developers (ABAP, SAP, Java, Smalltalk, …) – Roadmap

There is a Software exploration tool Moose2Model for developers (ABAP, SAP, Java, Smalltalk, …) written in Pharo. You can now read the Roadmap. You can see some of this in the ESUG 2017 presentation of Rainer Winkler

Torsten Bergmann - Pharo success story: Driving ATMs in Moscow streets (Videos)

As I already reported here Pharo 1.1 was used to build ATM-kind software in Russian Bank. Such devices could be found in Moscow streets. Now there are two videos available on that, one showing the system in action

 and one showing it in Pharo development environment:

October 11, 2017

Noury Bouraqadi - Pharo MOOC is coming…

The Pharo MOOC will start october 16th, 2017 on France Université Numérique (FUN). This MOOC is free and fully available in French and in English. Registration web page: If you are either a beginner or an expert in object-oriented programming, this MOOC will change the way you program with objects: come and learn or… Continue reading

October 10, 2017

Pharo Weekly - The story around PharoMinimal


What is the story around PharoMinimal and related images ?

Is there a writeup somewhere with instructions ?

Right now the minimal (Metacello) image based on Pharo 7 is used only as intermediate step in building of the full Pharo and the only real (successful) attempt to use it for something else is PharoLambda (
In general it can be used for building of own (server) applications. E.g. this way you can install and run Teapot on it:
./pharo Pharo7.0-metacello-32bit-d13eed2.image config ConfigurationOfTeapot –install=stable
./pharo Pharo7.0-metacello-32bit-d13eed2.image eval –no-quit “Teapot on GET: ‘/welcome’ -> ‘Hello World’; start.”
You can load baselines from the Git repositories too but we currently do not have any command line handler for it so you need to do it using “eval” command or *.st flile. Something like this:
Metacello new
baseline: ‘Seaside3’;
repository: ‘github://SeasideSt/Seaside:master/repository’;
To make it more usable we probably should extend it with SUnit and Fuel. If you want to extend it with some packages from vanilla Pharo, you should load them using FileTree from your local Pharo repository clone.
Gofer it
url: ‘filetree:///path-to-my-pharo-repository-clone/pharo/src’;
package: ‘Multilingual-OtherLanguages’;
package: ‘Multilingual-TextConverterOtherLanguages’;
It still needs some care. E.g. some classes from Zinc are not properly initialized (I know about DigitalSignatureAlgorithm MD5NonPrimitive RxMatcher RxParserRxsPredicate SHA1 ZnByteEncoder ZnConstants ZnMimeType ZnNetworkingUtils ZnServer ZnSingleThreadedServer TextConstants TextAction TextStyle).
I tried to load Seaside into it today (from the example above) and it failed (some strange error probalby related to Unicode processing). But we will fix it. If you will tell me what exactly you need we can make it work together as in case of PharoLambda.
followed by
Hi Pavel,

Thanks a lot for the explanation. To summarise: 70-minimal is the one with monticello and metacello in it that can load code via the config handler.

I was confused, because that failed for me.

Now, first doing

$ ./pharo pharo-minimal.image eval ‘ZnMimeType initialize’

fixed my loading problem. I also did the following because some of my project don’t separate tests (I known 😉

$ ./pharo pharo-minimal.image eval –save ‘Object subclass: #TestCase’

With those fixes I was able to load different projects

$ ./pharo pharo-minimal config ConfigurationOfZTimestamp –install=stable

$ ./pharo pharo-minimal config ConfigurationOfNeoConsole –install=bleedingEdge

The image remains equally fast in startup

$ time ./pharo pharo-minimal.image eval ZTimestamp now
real    0m0.062s
user    0m0.025s
sys     0m0.029s

And it works perfectly as a server, like

$ ./pharo pharo-minimal eval –no-quit ‘NeoConsoleTelnetServer new start’ &

$ telnet localhost 4999
Connected to localhost.
Escape character is ‘^]’.
Neo Console (32 Bit)
> get
known metrics:
system.status – Simple system status – Total allocated memory – Free memory
memory.gc – Garbage collect, return free memory
system.uptime – Image uptime human readeable
system.uptimeseconds – Image uptime seconds – Current date
system.time – Current time
system.timestamp – Current timestamp
process.count – Current process count
process.list – Current list of processes
system.version – Image version info
system.mcversions – Monticello packages version info
> get process.list
Delay Scheduling Process
Low Space Watcher
Idle Process
WeakArray Finalization Process
NeoConsoleTelnetServer port 4999
NeoConsoleTelnetServer port 4999 Connection Handler
> SessionManager default startupList collect: #handledId

#(#SmallInteger #Delay #ProcessorScheduler #OSPlatform #FileLocator #MCMethodDefinition #WeakArray #FileStream #MultiByteFileStream #EndianDetector #Symbol #LanguageEnvironment #Stdio #NonInteractiveTranscript #WeakFinalizationList #DiskStore #BasicCommandLineHandler #SourceFileArray #ASTCache #UUIDGenerator #InternetConfiguration #ZnLogEvent #ZnServer #Color #UIManagerSessionHandler #ZTimestamp)
Connection closed by foreign host.

Image size remains ~11Mb.

Very nice !

Pharo Weekly - Seaside on minimal Pharo 70


I was successfully able to run Seaside on the minimal Pharo 7.0. After the release cleanup the resultant image has about 12.4 MiB.
The loading script expects that in the working directory you have the Pharo repository clone (in a floder named ‘pharo’). You should modify the loading script to point to your real Pharo repository clone. This clone is needed to load SUnit into the minimal image. You should have PharoV60.sources reachable from the image.
The Seaside is loaded from my fork (github://pavel-krivanek/Seaside:minimalPharo/repository). I had to create a modified version because the original baseline broke the ZincHTTPComponents.
The strange line:
Smalltalk vm parameterAt: 25 put: (Smalltalk vm parameterAt: 25) * 50.
…sets the garbage collector. Without this the Seaside loading can fail on insufficient object memory.
wget -O – | bash
pharo Pharo.image –save –quit
pharo Pharo.image –no-quit
Starting of the image takes about 0.1 s on my machine.
— Pavel

October 08, 2017

October 07, 2017

Pharo Weekly - Fun with UI Avatars

I came across, a web service that creates avatar images based on some parameters.

From Pharo, the shortest invocation would be something like
Making use of the full builder interface of ZnClient that would look more like
ZnClient new
host: ‘‘;
addPath: #api;
queryAt: #name put: ‘Albert Einstein’;
queryAt: #size put: 128;
queryAt: #color put: ‘FFF’;
queryAt: #background put: ‘0D8ABC’;
queryAt: #rounded put: true;
accept: ZnMimeType imagePng;
enforceHttpSuccess: true;
enforceAcceptContentType: true;
contentReader: [ :entity | ImageReadWriter formFromStream: entity readStream ];
Anyway, it is cool to have an environment that makes this kind of experimentation so much fun.
It is probably easy to implement this avatar image generation directly in Pharo …

Stefan Marr - Hello Canterbury!

In case you have been reading the previous post or following me on Twitter or Facebook, you might know that I had the silly idea of cycling from Linz in Austria all the way to Canterbury in England.

And, I made it :)

After 12.5 days of cycling, I arrived in sunny Canterbury. My legs felt great, and my butt didn’t mind. It was a quite interesting journey, for large parts through Germany, but also the Netherlands, Belgium, and France. The third and forth day were the biggest challenges. The landscape was very nice, but very hilly. Compared to the ca. 100-120km on later days, I also cycled an extra 30-40km, which in combination was a little exhausting. Expect for those two days, I don’t think I pushed myself very much. On the contrary, it was pretty relaxed cycling. Especially along the Rhine the landscape was nice, the cycle paths pretty flat, and every 2km or so, there was another castle, which made the ride interesting.

Another thing I enjoyed was the absence of borders. I don’t even remember much signage. However, the cycling infrastructure could change noticeably all of a sudden. Germany, you could learn a lot from the Netherlands in that regard…

If you’re interested in my whole trip, the route was this:

More pictures and details on the separate days are on the Komoot pages: Day 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13

It was the first time for me to do such a cycling trip. While I did train since April, cycling in the mornings, and a bit more on the weekends, I actually only did a single 120km trip before. From that perspective, I have to say, it all went surprisingly well.

And besides spending a few days in Brussels to see friends, and an extra day in Lille, because I missed it a little, the trip was completed pretty much in one go. Originally I planed another day of rest, but it wasn’t really necessary, and so I just had a short day in-between and then continued on.

The final day of the trip was also a short one. I suppose, I could have gone the whole way from Lille to Canterbury in a single day. But I wanted to spend a night in Calais, refreshing some good memories, having some crêpe and cider, looking out on the channel, and enjoying Europe for one more night.

The next morning, England welcomed me on a lovely sunny and warm late summer day. After a rather steep climb up the hill in Dover, to see the castle and take a scenic long-distance cycling path, I arrived in Canterbury. You see the picture above. Bright and sunny :)

And that’s where this story ends, and a whole new one starts: being a lecturer at the University of Kent.

October 06, 2017

Pharo Weekly - Bugfix and enhancements release v0.2.5 for OSSubprocess

Dear all,

I have just released a new bugfix and enhancements release v0.2.5 for OSSubprocess as you can see in [1].
This new release is thanks to the awesome work of Guillermo Polito [2]. He found a problem (and a fix) that would hung/block the Pharo image in a wait state. This problem has been forever and I have faced it myself. It would only happen when using #waitForExit and under certain scenario.  Because of that, I recommend everyone to move to this release.
Aside from that serious bug, he has also done quite some improvements in the tests and in the Travis setup. Once this PR [3] has been merged and SmalltalkCI updated, our Travis build [4] should show all green builds for Linux/OSX and Pharo 5.0 and 6.1.
I have also copied the configuration into Pharo 5.0 and 6.0 catalog so as of tomorrow, it should be there.

Pharo Weekly - Iceberg version 0.6

Hi all,

I released Iceberg version 0.6. It includes a lot of small tweaks and fixes, but the most important inclusion is tonel file format which aims to replace file tree.
Tonel is a file-per-class file format for monticello repositories. It’s purpose is to reduce the amount of files touched each operation, make the IO faster an compact the repositories database.
It has also as an objective to offer an “easy-to-read” format, so people wanting to understand a chunk of code will recognise it easily.
For testing, I migrated several of my projects to Tonel and I’ve been using it, you can see some as examples: (this was just an example and it has some minimal errors already fixed)
We plan to migrate Pharo development to tonel to address some problems we have:
– since it has to read/write a lot of files, IO operations are slow
– and even much more slow in Windows
– Windows also has a problem with longpaths.
Iceberg 0.6 will be integrated to Pharo7 soon 🙂
To update Pharo 6.1, there are instructions in the readme:
now, if you wan to migrate your projects to Tonel (from FileTree), here is a script you can use:
btw, tonel is independent of Iceberg and can be used with plain Monticello (but it is a metadaless format, history will reside on git, not on monticello).

Pharo Weekly - PharoLauncher 1.0.1

Hi all,

I just released a new version of the PharoLauncher 1.0.1.
Here are major improvements since last version:

  • Pharo launcher is now distributed with a Pharo 60 image with a 32-bits threaded VM (to avoid hangs when using OSProcess).
  • Add a VM management utility able to find (and download) the appropriate VM for a given image. So, the launcher is NOT shipped anymore with an extra VM. It will fetch required VM when needed.
  • Pharo Launcher files (images, VMs) are now considered as user Documents (easier to find). Consequently, they are now stored in the standard documents folder, i.e.
    • $HOME/Documents/Pharo on OS X,
    • $HOME/My Documents/Pharo on windows,
    • $HOME/Pharo on Linux (some linux distributions provide a document folder but some others not, so we put it in the HOME directory in all cases).
    • In this folder, you will find your images and virtual machines needed to run images.
  • Use of ProcessWrapper to run images on Windows.
  • Adds download of sources file for Pharo images > 60.
  • Left panel is now used for official images and Jenkins jobs templates and right panel is used for local images.
  • New mooc entry with the image ready to start the Pharo Mooc.
  • New deprecated category to find old official Pharo images.
  • Use system unzip when possible (Pharo unzip does not manage file permissions nor symbolic links).
You can get platform bundles from


For those wanted more info on how the adequate VM is computed, here is the process:
  1. determine the image format version
  2. find (and optionnaly fetch) a compatible VM (a VM able to run this image format) and run the image to get its Pharo version number
  3. find (and optionnaly fetch) the appropriate VM for this specific Pharo image version. Sources files are also downloaded with the VM when applicable.
  4. run the image with the appropriate VM

Pharo Weekly - [Fun] SVG snippet

Load XMLParser from catalog and load Athens-SVG from the Pharo/Athens repository
xmlDoc := XMLDOMParser parseUrl: ‘‘.
svg := AthensSVGConverter new importXMLDocument: xmlDoc.
svg transform: ‘scale(0.5)’.
surface := AthensCairoSurface extent: 500 @ 500.
surface drawDuring: [ :aCanvas | svg renderOn: aCanvas ].
surface asForm.

Screen Shot 2017-10-06 at 17.20.39


October 03, 2017

Marten Feldtmann - PUM – VA Smalltalk 9/64 bit

Well, porting was done within one hour – feels and smells like VA 8.6.3, but now with 64 bit !

Filed under: Smalltalk Tagged: PUM, VASmalltalk 9

Benoit St-Jean - Travailler avec GitHub

Je dois humblement avouer que la récente migration de Pharo vers une intégration totale avec GitHub me donne du fils à retordre. Nouvelle façon de storer le code, nouvel outil (Iceberg) et nouveau paradigme.  Je travaille en Smalltalk depuis 25 ans avec les mêmes outils de gestion de code (ENVY, Store, STS, Polytron, Monticello, etc) alors la transition vers GitHub me donne du fil à retordre.  ENVY et Store me sont tellement familiers autant dans leur fonctionnement que dans leur fonctionnalités que du jour au lendemain, je me suis trouvé perdu dans ce nouvel univers!

Donc, à défaut de savoir par où commencer, je me suis mis à chercher un guide du genre Best Practices assez simple pour que je puisse l’utiliser facilement et ainsi sortir de ce qui me semble un parfait merdier dans ma tête! Et je suis tombé sur l’article (même s’il date, les explications font totalement du sens dans ma tête!) A successful Git branching model.

Je vous ferai part de mes  aventures bientôt !


Classé dans:Pharo, Smalltalk Tagged: ENVY, GitHub, Monticello, Polytron, repository, Store, STS

Benoit St-Jean - VMProfiler et le profilage de code

J’avoue honteusement que cette annonce est passée sous mon radar. Tout autant que les articles subséquents. Un nouveau profiler développé par Sophie Kaleba (son blogue est ici) est maintenant disponible pour Pharo.

En préambule, elle vous explique comment obtenir le projet et l’installer dans votre image ainsi qu’elle vous fait un rapide survol de ce que l’outil peut faire et toutes les statistiques qu’il est en mesure de vous offrir.

Le premier article vous introduit au fonctionnement et aux fonctionnalité de base de l’outil.

Le deuxième article détaille les différentes informations relatives au temps d’exécution du code Pharo.

Finalement, le dernier article porte sur les autres données fournies par le profiler tels que la mémoire consommée/disponible, le garbage collection, les événements de la VM, etc.

Bref, VMProfiler est un outil vital quand vient le temps d’optimiser la performance de votre application!

Classé dans:Machine virtuelle, Pharo, Smalltalk, VM Tagged: machine virtuelle, optimisation, Pharo, Smalltalk, Sophie Kaleba, VM, VMProfiler

October 02, 2017

Pharo Weekly - About getting lines

$ cat > /tmp/lines.txt

Here are different ways to get lines
(FileLocator temp / ‘lines.txt’) contents lines.

‘/tmp/lines.txt’ asFileReference contents lines.

‘/tmp/lines.txt’ asFileReference readStreamDo: [ :in |
Array streamContents: [ :out |
[ in atEnd ] whileFalse: [ out nextPut: in nextLine ] ] ].

(File named: ‘/tmp/lines.txt’) readStreamDo: [ :in |
| characterStream |
characterStream := ZnCharacterReadStream on: in.
Array streamContents: [ :out |
[ characterStream atEnd ] whileFalse: [ out nextPut: characterStream nextLine ] ] ].

They all return #(‘one’ ‘two’ ‘three’).

In the last, more complex example, you first get a binary stream (and a ‘line’ is a character based concept), so wrapping the binary stream in a character read stream (which does know about lines) solves the problem.



Pharo Weekly - From the trenches: esteban’ log


This is my weekly ChangeLog, from 25 September 2017 to 1 October 2017.
You can see it in a better format by going here:


28 September 2017:

*    I spent my day preparing [iceberg 0.6]( to be released
and I think I didn’t do a bad you.

* I integrate two PR to dev-0.5 and then merge it to dev-0.6
* I closed issues [#470]( and [#239](
* I fixed a problem on cherry-pick and renamed/removed classes (not reported as issue, but there)
* I added a “full sync” option meant to verify the full repository differences (this is useful in certain cases)

… and I’m still trying to get a loadable version of latest metacello (which will come with tonel integration)

27 September 2017:

*    I’m still making latest [metacello]( version to work properly
on Pharo, so we can integrate it into Pharo 7.0 (and we can also update Iceberg).

Right now, I have what I think is a “working version”, but I’m still figuring out how to include it
into Pharo (other than regular merge in image, export… which I think will be our approach until
we have subtrees)

24 September 2017:

*    I forget to say that friday with Ronie we made win32 headless version work 🙂

Now, it just remains win64 version… and of course, we will need to start test intensively so we can
have good support for the moment of release.

Pharo Weekly - Sqlite under Linux


I managed to get Sqlite work with Pharo under linux (Fedora), in both 32 and 64 bit. The setup has nothing to do with LD_LIBRARY_PATH. I’ll use those example under fedora linux.
First, of course, you need to install either UDBCSqlite or Garage-Sqlite drivers
You first need to have sqlite3 libs installed on your system
$ rpm -qa | grep sqlite
=> for 64 bits version
=> for 32 bits version
Then find the path of your library
$ rpm -ql sqlite-libs.i686
/usr/lib/ -> this is your path in 32 bits
$ rpm -ql sqlite-libs.x86_64
/usr/lib64/ -> this is your path in 64 bits

Under Linux, you have to give the library path inside Pharo Image, or link the library from pharo VM folder:

1. Update library path from pharo image

Using UDBDSQLite, update to return the path of the library on your system

UDBCSQLite3Library >> library

Smalltalk os isMacOS ifTrue: [ ^ #sqlite3 ].

^ ‘sqlite3’


UDBCSQLite3Library >> library

Smalltalk os isMacOS ifTrue: [ ^ #sqlite3 ].


If you are using Garage,Update:

GASqlite3FFI >> library

^ ‘/usr/lib/’

2. link the library from VM folder:

ln -s /usr/lib/ libsqlite3 or ln -s /usr/lib64/ sqlite3 if the module name is sqlite3 in your library method.

Then your test should pass green.
The reason it pass under windows is because the method library return by default sqlite3, which is the dll name you put under pharo VM directory to get it work.
On linux, unless you link your library in the VM folder, the image has no clue where to find sqlite3.
Hope this helps.

Benoit St-Jean - Étude sur les langages de programmation et la qualité du code

Un excellent article sur une étude comparative de divers langages de programmation et la qualité (selon divers critères) de chacun de ceux-ci.  L’étude a analysé 728 projects, 63 million de lignes de code, 29000 programmeurs, 1.5 million de commits dans 17 languages de programmation de projets hébergés sur GitHub.

On regrettera toutefois que Smalltalk (ou Pharo) n’ait pas été inclus dans l’étude mais ce sera pour une prochaine fois!

Mon petit doigt me dit qu’en fait de qualité, de taille du code source, de bogues et des autres paramètres étudiés, Smalltalk aurait torché tous les autres langages mentionnés dans l’étude!

Classé dans:langage de programmation, Pharo, programmation, Smalltalk Tagged: analyse, étude, bogues, C, Clojure, CoffeeScript, comparaison, Erlang, GitHub, Go!, Haskell, Java, JavaScript, Objective-C, Perl, Pharo, PHP, Python, Ruby, Scala, Smalltalk, TypeScript

October 01, 2017

Marten Feldtmann - Elections and Gemstone/S again

Last weekend we had general elections in Germany – and most of you may know the results.

Located at the ARD-Hauptstadtstudio for five days we collect all needed results for the main broadcaster ARD and around 15 other tv-studios in various towns in Germany (broadcaster BR, SR, SWR, NDR, RBB, WDR, Deutsche Welle, HR)

Again this was an election with Smalltalk taking part in our presentation of the results – with Gemstone/S as the “backbone” for the Internet presentation systems and the Internet input system. We presented the results for the SWR in Baden-Württemberg and Rheinland-Pfalz on the Internet.

Technically the systems were used as described here and here .


Filed under: Smalltalk Tagged: elections, ExtJS, Gemstone/S, PUM, Sencha