Monthly Archives: March 2018

[Testers Required] New FreeType implementation using FFI

I have implemented the backend of FreeType using only FFI calls.

So the whole implementation is in the image side, the current plugin has a lot of problems handling the release of the pointers. The new implementation is using the mechanism that is already present in UFFI to release the Heap pointers, so it should be more stable and easier to modify if there is an issue.
The FT2Plugin is not used anymore in this version.
I have tested it in the different platforms, but beside OSX I have only made a smoke test. I need some users to try it, so I ask you if you can test in different installations.
The image can be downloaded from the CI
Thanks to all!!

[Ann] Highcharts JS Wrapper and the Web Stack


We’re happy to announce a new version of the Highcharts JS Wrapper and the Web Stack hosted at This is a multi-release announcement of the following related project versions:

  • HighchartsSt v6.0.0
    • Updated Highcharts and Highstock JS libraries to version 6.0.3
    • Improved Importing Tools
    • Improved Travis CI integration
  • Willow v7.0.0. Changes since latest announcement:
    • Added composition of table row commands
    • Refactored a bunch of common utilities into it’s own project
    • Improved JSScript extensions
  • Willow-Bootstrap v7.0.0
    • Updated Willow base support to v7.0.0
    • Improved Radio Web Views
  • Willow-JQueryUI v6.0.0
    • Updated Willow base support to v7.0.0
    • Improved Radio Web Views
  • Willow-SpinKit v4.0.0
    • Updated Willow base support to v7.0.0
  • Willow-Playground v3.0.0

    • Updated dependencies to the latest versions
    • You can now grab a ready to use image from the releases page
  • RenoirSt v4.1.0
    • Add another way of creating descendant combinators for cases when the right part of the expression needs parenthesis
    • Updated dependencies

SemanticUI and Materialize CSS integration are still a work in progress.

Find a more detailed changelog and migration instructions on the release pages of each repository.

Special thanks to Ignacio Martinez and Juan Escalada for contributing some of the new features. Also to Maxi Tabacman and Mariano Martinez Peck for the Highcharts update.
Anyone interested in joining our ba-st projects is welcomed, and you can also get some interesting ideas in crafting lint rules to support team coding standards.


Gabriel Cotelli, Maxi Tabacman and all the contributors.

Understanding MetaLinks


I did last week a short lecture at VUB Brussels. Topic: MetaLinks.

New Files in Pharo – Migration Guide, How To’s and examples

Hi all,
I’ve put some minutes summarizing the new APIs provided by the combination of the new File implementation and the Zn encoders. They all basically follow the decorator pattern to stack different responsibilities such as buffering, encoding, line ending conversions.
Please, do not hesitate to give your feedback.
1. Basic Files
By default files are binary. Not buffered.
(File named: ‘name’) readStream.
(File named: ‘name’) readStreamDo: [ :stream | … ].
(File named: ‘name’) writeStream.
(File named: ‘name’) writeStreamDo: [ :stream | … ].
2. Encoding
To add encoding, wrap a stream with a corresponding ZnCharacterRead/WriteStream.
utf8Encoded := ZnCharacterReadStream on: aBinaryStream encoding: ‘utf8’.
utf16Encoded := ZnCharacterReadStream on: aBinaryStream encoding: ‘utf16’.
utf8Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: ‘utf8’.
utf16Encoded := ZnCharacterWriteStream on: aBinaryStream encoding: ‘utf16’.
3. Buffering
To add buffering, wrap a stream with a corresponding ZnBufferedRead/WriteStream.
bufferedReadStream := ZnBufferedReadStream on: aStream.
bufferedWriteStream := ZnBufferedWriteStream on: aStream.
It is in general better to buffer the reading on the binary file and apply the encoding on the buffer in memory than the other way around. See
[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: ‘utf8’) upToEnd
]] timeToRun. “0:00:00:09.288”
[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnBufferedReadStream on: (ZnCharacterReadStream on: binaryFile encoding: ‘utf8’)) upToEnd
]] timeToRun. “0:00:00:14.189”
4. File System
By default, file system files are buffered and utf8 encoded to keep backwards compatibility.
‘name’ asFileReference readStreamDo: [ :bufferedUtf8Stream | … ].
‘name’ asFileReference writeStreamDo: [ :bufferedUtf8Stream | … ].
FileStream also provides access to plain binary files using the #binaryRead/WriteStream messages. Binary streams are buffered by default also.
‘name’ asFileReference binaryReadStreamDo: [ :bufferedBinaryStream | … ].
‘name’ asFileReference binaryWriteStreamDo: [ :bufferedBinaryStream | … ].
If you want a file with another encoding (to come in the PR, you can specify it while obtaining the stream:
‘name’ asFileReference
    readStreamEncoded: ‘utf16’
    do: [ :bufferedUtf16Stream | … ].
‘name’ asFileReference
    writeStreamEncoded: ‘utf8’
    do: [ :bufferedUtf16Stream | … ].
5. Line Ending Conventions
If you want to write files following a specific line ending convention, use the ZnNewLineWriterStream.
This stream decorator will transform any line ending (cr, lf, crlf) into a defined line ending.
By default it chooses the platform line ending convention.
lineWriter := ZnNewLineWriterStream on: aStream.
If you want to choose another line ending convention you can do:
lineWriter forCr.
lineWriter forLf.
lineWriter forCrLf.
lineWriter forPlatformLineEnding.
6. About performance questions
Well, I’d say it we did it in the name of modularity. And yes, I believe that having separate responsibilities help in designing, testing and ensuring more easily the correctness of each of the parts in isolation.

I’ve done also some profiling and it does not look like we’ve lost in performance either (reading and decoding a 35MB file):
[file := Smalltalk sourcesFile fullName.
(File named: file) readStreamDo: [ :binaryFile |
(ZnCharacterReadStream on: (ZnBufferedReadStream on: binaryFile) encoding: ‘utf8’) next: binaryFile size.
]] timeToRun. “0:00:00:01.976”
[file := Smalltalk sourcesFile fullName.
(MultiByteFileStream fileNamed: file)
converter: (TextConverter newForEncoding: ‘utf8’);
] timeToRun. “0:00:00:02.147”

Woden with Vulkan and openGL on Windows

woden_windows.png I just managed to get Woden working with Vulkan, and OpenGL on Windows. Finally, smooth movement (My tearing was Linux failure). My only complain is that it takes too long on loading a Pharo image on Windows.

Ronie Salgado

Bloc, brick and GT update


Here is an update of the work on Bloc, Brick and GT. As always, please do let us know what you think.

– Improved the deletion in the text editor and covered the scenarios with examples
– Worked on the text selection. Still work needed for selection to be production ready:
– Balanced rope structure for even better performance of the editor. Overall, the performance of the text editor improved 2x.
– Selectable curves:

– Resizer overlay. The tweet below also shows how we can now easily script dragging behavior in examples:

– Diagrammer is a new engine for drawing diagrams based on Bloc. This is the first version, and we will continue working on it in the following weeks, so stay tuned for more news. This is also one of the first Bloc applications:
– Andrei put together a beautiful description of a scenario in which an application is molded interactively in the Playground & Inspector. The subject is face recognition, and the resulting code is both functional and explainable. This is intended as a tutorial material that shows what moldable development means and how it changes the way we program:

Have fun,
The feenk team

Cruiser: A Pharo app packager

Hi Pharoers!

I pleased to announce you the first release of Cruiser: a tool to package your Pharo applications. The idea is to quickly convert an application from a development environment to a production one. A production environment means:

  • No writing on the disk
  • No access to the source code (by the shortcuts, debugger,…)
  • No error displaying on the interface
  • The only thing accessible is the user application

I let you discover it on:


OSSubprocess for 64bits

Hi guys,

Thanks for Guillermo Polito we now have 64 bits support for OSSubprocess. You can see the required changes in this PR [1]. I made a branch called `support64bits` so that you can help us test it even if CI said it was good [2]. If you do test it and come back to us with the results, please tell us which OS you used.
To install from the branch:
Metacello new
  configuration: ‘OSSubprocess’;
  repository: ‘github://marianopeck/OSSubprocess:support64bits/repository’;
version: #stable;
Roadmap: Current release is v0.2.5. So I will let that release for Pharo <= 5.0. I will make a new release with the Pharo 64 bits and call it v0.3. That release should be used for Pharo 6.x. Once v0.3 is out, I will make a new release v0.4 with some changes I wanted to do since a loooong time and its a small refactor to minimize OSSubprocess dependency on OSProcesses primitives (at VM side). This is thanks to Holger Freyther and Alistair Grant [3]. As that requires a new VM, then v0.4 should be used in Pharo >= 7.0.

Pavel resurrecting terminal emulation


Guille is working on the Iceberg improvements and he wanted to be able to open a terminal window on top of the repository and interact with it via the command line. So we looked at this issue because I already in December made some experiments with the terminal emulation in Pharo.

In past, the Squeak had a working terminal emulation that used PseudoTTYPlugin. The VM is not built with this code for a long time but I tried to replace it with a small C library and then wrote an FFI interface to it. Together with that, I ported most of the old code Squeak code to Pharo.

With Guille we tried to avoid usage of such external library and wrote an FFI interface to all the required LibC functions. We were successful but we realized that there are several issues that are limiting us.

When you want to execute a separate process for the program that you want to open in terminal (typically the Bash), you need to redirect the standard IO files, create a fork of your process, do some additional initialization in it and call ‘exec’ on it. In the parent process, you change redirected IO files back to the original values.

But the problem is that between the FFI calls from Smalltalk the VM can do a lot of things including garbage collection etc. On OS X the fork() function has the following limitation described in man:

“There are limits to what you can do in the child process. To be totally safe you should restrict your yourself to only executing async-signal safe operations until such time as one of the exec functions is called.  All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe.  If you need to use these frameworks in the child process, you must exec.  In this situation it is reasonable to exec your-self. yourself.”

As the result in most cases (but not all) the fork() and exec() pair from the Smalltalk side fails on OS X. Linux does not have this limitation however even there we found an issue. It is bound to the fact that fork() makes a fork of all the parent process that uses the same resources. As soon as Pharo is opened in a window and X11 is involved (the window wants to be repainted), it can lead to the VM crash.

So we learned that unfortunately we currently cannot use image-only FFI code for this task. We need a C library or VM plugin.

The repository of the terminal emulator is here:

and can be loaded using the following code:

Metacello new
baseline: ‘TerminalEmulator’;
repository: ‘github://pavel-krivanek/terminal/src’;

#TerminalEmulator asClass compileLibrary.

It compiles and links the small library with only one function using the GCC so the machine needs to have a proper development environment.
The terminal emulator is in very early stage and has a lot of issues like processes cleanup, drawing, keyboard input etc. etc. If you are interested in it, feel free to contribute.

— Pavel