Planet Squeak

blogs about Squeak, Pharo, Croquet and family
planet squeak - planet squeak es - planet squeak jp - planet croquet - planet squeak code - planet smalltalk

April 27, 2016

Torsten Bergmann

Genetic Algorithm for Pharo

A genetic algorithm implementation is available from the Pharo Catalog provided by Alexandre Bergel.

I helped Alexandre in providing the config for this. I like the package. His genetic algorithm code is nice and interesting - it allows to play with Genetic algorithms in the regular Smalltalk tools (workspace, inspectors, ...) and the package also provides Roassal visualizations for them.
You definitely should check this package out. Code is on STHub.

by Torsten ( at April 27, 2016 01:41 PM

April 25, 2016

Torsten Bergmann

Arff Generator in Pharo

Weka is a collection of machine learning algorithms for data mining tasks. Weka defines a format called "Arff" to be used for data importation. On GitHub you will now find an Arff generator written in Pharo.

by Torsten ( at April 25, 2016 12:40 PM

Changing Pharo background picture

Want to style your Pharo image with a wallpaper image? Peter describes the possible options in detail.

by Torsten ( at April 25, 2016 10:27 AM

JSON persistency with SQLite database in Pharo

as described by Pierce on his blog. Really nice!

by Torsten ( at April 25, 2016 10:25 AM

April 23, 2016

Torsten Bergmann

Scratch performance

Tim optimized Scratch for the Raspberry Pi ... now it runs much faster. Read more.

by Torsten ( at April 23, 2016 09:00 AM

April 21, 2016

Torsten Bergmann

Minimal tODE API

The GemStone/S GCI code was ported to UFFI and now allows to have a minimal tODE API for accessing the object database from Pharo 5.0. Read more.

by Torsten ( at April 21, 2016 06:07 AM

April 20, 2016

Torsten Bergmann

Mocketry 3.0

New version of Mocketry 3.0 for Pharo is available. Read more.

by Torsten ( at April 20, 2016 09:20 PM


Newton's method for vector problems (experimental) is in ‪#‎PolyMath‬ Extensions. Read more

by Torsten ( at April 20, 2016 06:59 PM

Pillar 3.0.0 release

is available. Read more.

by Torsten ( at April 20, 2016 06:27 PM

Alternate Reality Kit by Randall Smith at Xerox PARC 1986

by Torsten ( at April 20, 2016 08:57 AM

April 18, 2016

Torsten Bergmann

Algernon-Launcher for Squeak

Back from the days when I used Squeak there was a nice tool called "Algernon" which was a simple "type in search" tool. I used it very often.

Later in Pharo days such a tool was missing - but after a while the "Spotter" tool for Pharo was provided by the GT team based on the same idea.

The nice thing is that now also the Algernon code was updated for latest Squeak in a project called "Algernon-Launcher".

BTW: Spotter does not allow to evaluate the given text as expressions, but the tool is extendable and maybe should provide this Algernon feature by default as well.

by Torsten ( at April 18, 2016 03:46 PM

April 15, 2016

Göran Krampe

Spry Modules

As discussed in the previous article I want Spry to have a trivially accessible persistence mechanism enabling something similar to the Smalltalk image model, but based on a database. The memory organisation in Spry is basically nested Maps. After dwelling a bit on the inevitable hard question about modules and namespaces I have decided on a design that I hope will turn out simple and reasonably powerful!

Smalltalk has a Dictionary holding all the globals forming "the roots" of the object memory. In Smalltalk this Dictionary is also itself a global variable accessible as Smalltalk, in other words Smalltalk == (Smalltalk at: #Smalltalk). The primary use of Smalltalk is to hold all classes by name, so they are all reachable as globals. Obviously Smalltalk can also hold any kind of object (not just classes) as a global.

Spry also has such a top level Dictionary, but in Spry we call a Dictionary a Map to be a little bit more aligned in terminology with other languages (and it's shorter). This top level Map is the root Map and it is accessible via the word root. In Spry the root word is actually bound to a primitive function returning this Map, so in Spry we also have root == (root at: 'root).

Ok, so Spry has a Map of globals and one way of using Spry is simply by populating root with words bound to functions making these functions globally accessible, it's how I have done it so far. Yeah, yeah, I know, but for smaller systems it probably works just fine!



But we do want a Module concept and given that I once designed a Namespace model for Squeak (that never was accepted) - it was inevitable I guess that it would reappear in Spry! :)

As many other languages do, I also simplify by making a "Module" do double duty as a "Namespace". It's a reasonable approximation although to be precise a Module is normally a deployment, versioning and distribution unit and a Namespace should ideally be aligned with how we humans are organised, but... whatever. In Spry I also simplify by not allowing nesting of Modules. A Module is simply a Map bound to a global word.

Modules need to have meta information about them. In Nim we use a Foo.nimble file to contain this meta information. In the JavaScript world there is a package.json file containing meta information. In Spry, since a Module is a Map, we let the _meta key hold a Map of meta information:

_meta = { name = "Foo" version = "1.0" author = "Göran Krampe" }

The name of the Module is thus only kept as meta information, this means that the code loading the module into our system decides what the Module should actually be named - thus we can choose to load a Module Foo by the name Foo2 if we already have a Module called Foo in the system. It could for example be used to have two different versions of the same Module loaded at the same time.

So how do we refer to things in different Modules? Obviously we can do it manually using (root at: 'Network) at: 'Socket, it's just a global Map after all, but Network at: 'Socket is simpler. I am also introducing yet another word type - a Module qualified word. It would look like Network::Socket and be evaluated as Network at: 'Socket. If we load another Foo as Foo2, then all existing references like Foo::Cat will of course not refer to the new Foo2, but we could easily scan for them and modify them, if we so wish.

To import... or not!

Finally, we face the issue of imports. Almost all programming languages use imports, often per class or file, but also per module. It's worth recognizing what true purpose they actually serve.

  1. One use of them is to avoid typing long names in the actual code, but ... that would typically only be an issue if module names where.. say very long like com.MyCoolCompany.ProjectX.Base.Common, but they aren't in Spry, since we don't allow nesting nor do we want people to use Internet domain names like that.

  2. It can be used to constrain the allowed references a Module can have, but... in my experience it's not often used to do that. One could however imagine a system of declarative rules of what modules can access what other module, or which group of modules can depend on which other group. In fact, I designed such a tool for Java back in ... waaay back.

  3. To enhance completion, only completing within the imported union of modules. I don't really view this as a critical thing, and it can also be solved using heuristics. Smalltalk systems also complete these days, and not having imports hasn't really made it less useful.

  4. To act as documentation for a Module showing what other Modules it uses, but... then we should not allow fully qualified references in the code since that invalidates this purpose. And we could trivially scan and find all usages within the Module without the import statements.

To sum it up...

In my proposal for Squeak there were no imports either, the idea was to always have the full reference in the source code, but to let browsers "render them short" if the unqualified name still was unique in the image. In Spry I am opting for a slightly different approach:

This means we can still use Socket in short form, but be aware that it means "Give me the first thing you find called Socket". If we qualify it means "Give me Socket in the Network module".

Thus, if we let root at: 'modules be a Block of the modules that wish to participate in such an ordered lookup - that should be enough!

Next Steps

So I will:

When this works it's getting time to hook into Sophia!

Happy Sprying!

April 15, 2016 10:00 PM

April 14, 2016

Torsten Bergmann

IWST 2016 - International Workshop on Smalltalk Technologies


by Torsten ( at April 14, 2016 07:20 PM

VM Learning: Call Stack Management

Want to learn about virtual machine construction. Then check out this one.

by Torsten ( at April 14, 2016 06:16 AM

April 13, 2016

Torsten Bergmann

Generate Spec CRUD applications

Code is on STHub and a video is here:

by Torsten ( at April 13, 2016 10:42 AM

Open WebBrowser from Pharo

A simple package for unform and platform independent WebBrowser access for Pharo:

Read more here.

by Torsten ( at April 13, 2016 08:28 AM

PARROT AR Drone 2.0 with Pharo

Repo with code is here. Read more here.

by Torsten ( at April 13, 2016 08:23 AM

April 12, 2016

Torsten Bergmann

Joystick test in Pharo

Joystick test (part of OSWindow project in Pharo)

by Torsten ( at April 12, 2016 09:07 AM

Video on how to report a Pharo bug and contribute by fixing it

Short video on how to report a bug in Pharo and fix it.

by Torsten ( at April 12, 2016 09:03 AM

April 08, 2016

Göran Krampe

Spry image model

In developing Spry - renamed from Ni - I am getting closer to the Really Fun Stuff.

As a Smalltalker I dream "bigger" than just managing source code as text in files...

I mean, source code in files; how quaint, how seventies! - Kent Beck

Smalltalk uses the "image model" in which the system is alive and running all the time, the full development environment is also live together with your application, and we are in fact modifying object structures when we develop Smalltalk programs. We can also snapshot that object memory onto disk and fire it up somewhere else. Several Lisp implementations have used a similar approach I think.

The image model has tons of really cool benefits, I don't have time repeating all of them, but a modern implementation of the idea should take a few things into account that was not considered in the 1970s:

Some argue that the image model has downsides - like being an "ivory tower" incapable of interacting with the outside world. The Smalltalk environments have indeed historically suffered a bit in varying degree, but we can easily find ways around those issues while still reaping the awesomeness of a fully live programming environment, especially if we give the above items proper thought from the start.

With Spry I think I have a beginning to a novel approach... as well as taking the above into account.

The Smalltalk model

Most Smalltalks (not all) have been image based and the image has simply been a "memory snapshot" of the whole system down to a single disk file. Although quite novel both then and now - the concept of a single dump onto a file is rather primitive. Today we have TONS of different advanced database engines to choose from - why not use one of them instead?

Yes, GemStone is a remarkable exception to the traditional Smalltalk image model. Already in the late 1980s they realized that the object memory could be made transparently distributed, multiuser, transactional and persistent. GemStone is simply DARN cool and I haven't seen anything even close in other languages. But it's not open source, and it's expensive. And... can be a bit complex too.

Can we do something similar to GemStone but much simpler? Let's start in the single user perspective. Assume we have a transparently integrated advanced and super fast database engine. Sure, single user, but that will give us a strong platform to stand on for code management, IDE development and a lot more.

Storage format

But hold on - first we need to decide on a suitable format to store in a database.

I thought briefly about the binary path where we simply store pages of RAM onto disk in order to avoid serialization/deserialization - but I opted out. It's complicated and it doesn't fit well into the idea of having future multiple implementations of the Spray VM catering to different eco systems. I also think CPUs are insanely fast these days so serialization/deserialization is not a bottleneck.

So let's presume we serialize, in what format? Definitely in a readable format I would say. What about JSON then? Mmm, JSON is simple and TONS of databases these days rely on it, and in fact Spry will have really nice abilities to manipulate and integrate JSON - but we have a more natural choice in Spry.

Spry is homoiconic and has a simple and easily parsed free form syntax of its own. In the name of unifying concepts and simplicity - we obviously just use Spry! This would be slightly in analogy with the storeOn: and readFrom: mechanisms that Smalltalk had from the start storing data "as code". But Spry is MUCH cleaner and consistent here, in the way Lisp is. The data model of Spry, including the model of executable code, is the AST tree and the syntax of Spry mirrors this tree.


After some optimizations in the current parser I made some tests on my laptop. I daftly generated some fake "data" in the Spry syntax and can happily note that Spry compiles (deserializes) about 10Mb source per second into AST nodes. And it seems to scale pretty fine too. The serialization step is even faster.


To put some icing on that cake I threw in LZ4 compression which is wickedly fast, so fast it isn't even noticed even when doing a full back to back cycle of a 430 Mb source file. And source is very amenable to compression, although my sample is repetitive so not a good reference.

Here is a trivial Spry script that reads a compressed file, uncompresses it, compiles it (deserialize) and then serializes it again and compresses it before writing it back on disk:


!/usr/bin/env spry

writeFile "" compress serialize deserialize uncompress readFile "" ``` These commands I defined in prefix fashion which means the evaluation ends up as a chain from right to left. One could just as easily have defined them as infix to get a reverse evaluation, or one could use an Elixir style "pipe" function to get that effect. Spry is flexible here and obviously some kind of editor support or conventions may be needed to avoid confusion.

So where are we now? We can read and write files (trivial of course), compress/uncompress strings using liblz4 and serialize/deserialize strings into and from Spry AST nodes. This means we can now store and load code as well as data, and we could trivially extend the REPL with a regular "image model".


But let's go all the way. Files are neat, but a really good database is better. I hunted high and low for something that seemed easy to use, with an interesting set of features and really, really good performance. I ended up choosing Sophia and I have a Nim wrapper of the C API of Sophia already cooking. I have a feeling this is going to be a blast, terabyte image size? No problem.

When the wrapper is working it's time to start thinking of how the memory model can be partitioned, manipulated through transaction boundaries, but that will be another article for another day!

If you want to chat about Spry, join up at! Or at #spry on freenode.

April 08, 2016 10:00 PM

April 06, 2016

Torsten Bergmann

Pharo Pomodoro (updated) - version 1.6

Updated the code of Pomodoro timer for Pharo 5 once again:

demonstrated in a new video:

by Torsten ( at April 06, 2016 10:53 PM

New version of Mocketry 3.0

is available. Read more here.

by Torsten ( at April 06, 2016 01:41 PM

MessageFlowBrowser updated for Pharo 5

I updated my MessageFlowBrowser for Pharo 5 and added a new video:

by Torsten ( at April 06, 2016 08:59 AM

TDOOOP Slides from ETAPS 2016

Interesting Slides from Oscar Nierstrasz from an invited talk at European Joint Conferences on Theory and Practice of Software (ETAPS 2016) with the provocative title "The Death of Object-Oriented Programming" (TDOOOP)

 As meanwhile any technology claims to be object orientied (or object based) I would rather say

"OOP is dead long live REAL OOP (with Smalltalk and Pharo)"

by Torsten ( at April 06, 2016 08:49 AM

Pharo Days 2016 Session 2 GT Moldable Tools

by Torsten ( at April 06, 2016 06:44 AM

Pharo Days 2016 Session 1

by Torsten ( at April 06, 2016 06:43 AM

Linear Algebra Package for Smalltalk built upon LAPACK

called Smallapack. Check out out here.

by Torsten ( at April 06, 2016 06:38 AM

April 01, 2016

Torsten Bergmann

Pharo and CentOS

I created another video on my CentOS support for Pharo

by Torsten ( at April 01, 2016 07:01 AM

March 31, 2016

Torsten Bergmann

Man page support in OSUnix

I now provide Unix man page support in OSUnix for Pharo,
here an example in Ubuntu:

by Torsten ( at March 31, 2016 06:47 PM


docu is here.

by Torsten ( at March 31, 2016 12:33 PM