As part of the PhaROS and related projects, Santiago Bragagnolo had developed TaksIt a  framework for to ease handling concurrency. Expressing and managing concurrent computations is indeed a concern of importance to develop applications that scale. A robotic application often have different processes dealing with different activities (e.g. preception, planning, …).

TaskIT provides abstractions to schedule and/or parallelize of the execution of pieces of code. They will be described in the forthcoming chapter of the Pharo for the Entreprise book. First content is already available online. You can also get the code by evaluating the following expression in a Pharo workspace:

Gofer it
smalltalkhubUser: 'sbragagnolo' project: 'TaskIT';
configurationOf: 'TaskIT';
loadVersion: #bleedingEdge


PhaROS has being in this last edition of FOSDEM (2014) we are proud to share our time and space with a lot of open source projects. Thank you very much for good feelings, feedback and sharing this amazing time.
Video and photos from this great event will be soon available here. Meanwhile, here are the slides

Keep tuned!

PhaROS tool has the mission of installing and creating packages into a ROS installation.

For doing this we have several commands, from installing and creating to administrating repositories, so you can manage your own packages and creating templates without major problems.

Install PhaROS tool

We are working for having this package in Ubuntu and ROS repositories, but meanwhile you can download it from here: pharos-deb

Once downloaded just execute

sudo dpkg -i pharos.deb

pharos –help


Install PhaROS based Package

pharos install PACKAGE [OPTIONS]


pharos install esug –location=/home/user/ros/workspace –version=2.0


pharos install –help

 Create PhaROS based Package

pharos create PACKAGE [OPTIONS]


pharos create –location=/home/user/ros/workspace –version=2.0 –author=YourName –author-email=YourEmail

Tip: Be sure the email is a correct one. If is not a correctly spelled one you will notice during last step.
pharos create –help

Register Repository of packages

pharos register-repository –url=anUrl –package=aPackage [ OPTIONS ]


pharos register-repository –url= –package=YourProjectDirectory –directory=YourProjectDirectory

Tip: If your repository requires user/password for reading add –user=User –password=Password to the example.
Disclaimer: User/Password will be stored in a text file without any security.

pharos register-repository –help

Listing registered repositories

pharos list-repositories

Creating a directory for your own project repository

pharos create-repository PACKAGENAME [ OPTIONS ]


pharos create-repository example –user=UserName >
pharos create-repository example –user=UserName  –output=


pharos create-repository –help




We are now really glad to present an enhanced way to deal with PhaROS.

Since we want to keep with the ROS community spirit of collaborative development for robotics, we introduce now our own command for managing packages made in PhaROS.

This command is mean to install existing packages and create new packages with cool snippets and examples for going faster through the learning time.

PhaROS tool is made completely in Pharo smalltalk and it allows to deploy an existent package into a pharo 1.4/2.0/3.0 in any distribution of ROS that uses catkin package. It automatize the generation xml, makefiles, type and scripts creation, going on the direction of letting the pharo programmer to focus just in programming and not in infrastructure stuff.

For Installing and Using please check this post: using-pharos-tool







After 3 years of work, Nick is about to finish his PhD. His defense is planned on the 19th of December 2013 at 10:00.  It will be held at Ecole des Mines de Douai. You’ll find below the abstract and the keywords that describe his work entitled: “Remote debugging and reflection in resource constrained devices”. The committee gathers the following people:


  • Marianne Huchard, Professor at University of Montpellier, LIRMM Laboratory, France
  • Alain Plantec, Associate Professor at University of Brest, Lab-STICC Laboratory, France


  • Roel Wuyts, Professor at K University of Leuven, Belgium
  • Serge Stinckwich, Associate Professor at University of Brest, and member of the IRD research Institute, Bondy, France

Advisor: Stéphane DUCASSE, Research Director at INRIA, Scientific Director of INRIA Lille, Head of the RMoD Team, France


  • Luc Fabresse, Associate Professor at Ecole des Mines of Douai, France
  • Marcus Denker, Researcher at INRIA Lille, RMoD Team, France
  • Noury Bouraqadi, Associate Professor at Ecole des Mines de Douai, France

Summary of the PhD

Building software for devices that cannot locally support development tools can be challenging. These devices have either limited computing power to run an IDE (e.g smartphones), lack appropriate input/output interfaces (display, keyboard, mouse) for programming (e.g mobile robots) or are simply unreachable for local development (e.g cloud servers). In these situations developers need appropriate infrastructure to remotely develop and debug applications.

Yet remote debugging solutions can prove awkward to use due to their distributed nature. Empirical studies show us that on average 10.5 minutes per coding hour (over five 40-hour work weeks per year) are spend for re-deploying applications while fixing bugs or improving functionality. Moreover current solutions lack facilities that would otherwise be available in a local setting because its difficult to reproduce them remotely (e.g., object-centric debugging). This fact can impact the amount of experimentation during a remote debugging session – compared to a local setting.

In this dissertation in order to overcome these issues we first identify four desirable properties that an ideal solution for remote debugging should exhibit, namely: interactiveness, instrumentation, distribution and security. Interactiveness is the ability of a remote debugging solution to incrementally update all parts of a remote application without losing the running context (i.e without stopping the application). Instrumentation is the ability of a debugging solution to alter the semantics of a running process in order to assist debugging. Distribution is the ability of a debugging solution to adapt its framework while debugging a remote target. Finally security refers to the availability of prerequisites for authentication and access restriction.

Given these properties we propose Mercury, a remote debugging model and architecture for reflective OO languages. Mercury supports interactiveness through a mirror-based remote meta-level that is causally connected to its target, instrumentation through reflective intercession by reifying the underlying execution environment, distribution through an adaptable middleware and security by decomposing and authenticating access to reflective facilities. We validate our proposal through a prototype implementation in the Pharo programming language using a diverse experimental setting of multiple constraint devices. We exemplify remote debugging techniques supported by Mercury’s properties, such as remote agile debugging and remote object instrumentation and show how these can solve in practice the problems we have identified.

Keywords: Remote Debugging, Reflection, Mirrors, Interactiveness, Instrumentation, Distribution, Security, Agile Development


In a recent experiment we demoed a scenario of how a robot can be used to help shoppers (see Video below). The robot computes the optimal path for picking items of an arbitrary shopping list. It carries the bag and guides the shopper to items locations.  As we explain in the slideshow (below the video), there are other possible applications of mobile robots in a shopping. We also give a quick overview of hardware and software. We reused some existing ROS packages that we combined with our own software built using the PhaROS client based on Pharo a Smalltalk inspired OO dynamic language.

Video: A Robot Made to Help Shoppers

Slideshow about the RoboShop project

Being a TDD fan, I’m writing tests all the time. And I sometimes ended up having groups of nearly identical tests:

  • they use exactly the same objects, send the same messages,
  • but they differ only by values.

In a discussion on the Pharo-dev mailing list, Laurent Laffont pointed what is done in PhpUnit and suggested to have something similar in Pharo. After a few hours hacking I’ve my parametrized tests working and integrated with the test runner to ease debugging.

I’ve introduced a ParameterizedTestCase which supports both “plain” tests as well as parametrized tests. This class should be subclassed as in the following example:

ParameterizedTestCase subclass: #ExampleOfParameterizedTestCase
        instanceVariableNames: ”
        classVariableNames: ”
        poolDictionaries: ”
        category: ‘ParameterizedTests’

A test method is any method that is marked with the pragma testParametersSelector: as in the following example:

ExampleOfParameterizedTestCase>>#should: value1 plus: value2 equals: expectedSum
        <testParametersSelector: #givenValuesAndTheirExpectSum>
        self assert: value1 + value2 equals: expectedSum

The argument of the pragma testParametersSelector: is the selector of a method that provides a collection of arrays. Each array gathers parameters for a different test case. In our example the method givenValuesAndTheirExpectSum is defined as following:

        ^{{1. 2. 3}.
        {10. 20. 30}.
        {100. 200. 300}}

Since we have three arrays of parameters, we will have 3 different test cases all three with the same test selector, but each with a different parameters array. This is displayed by the test runner as shown in picture 1.


Picture 1: Passing Parametrized Test

If any of the parameters arrays leads to a test failure, the Test Runner will display the failing test selector as well as the parameters that lead to the defect. For demo purpose, let’s introduce some invalid parameters and change the previous givenValuesAndTheirExpectSum method as following:

        ^{{1. 2. 3}.
        {10. 2. 30}.
        {100. 200. 0}}

I have changed the second and the third parameter arrays. The Test Runner detects indeed 2 failing tests out of 3 runs as shown in picture 2. As you can see the parameters that lead to the defect are displayed so, one can identify the origin of the defect.


Picture 2: Failing Parametrized Test

I have developed and tested parametrized tests under Pharo 2.0. If you want to try it, you can install it by evaluating the following expression in a workspace.

Gofer it
        url: ‘’;
        package: ‘ParameterizedTests’;

It is worth noting that although in the examples I have given above data is hard coded, nothing prevent from adopting an approach as suggested by Frank Shearar in his Squeak Check project. Method that return the array of parameters can rely on any arbitrary complex data generator class, that may produce different data randomly each time tests are run.

At the ESUG 2013 conference, we presented the current status of the RoboShop project. Santiago did a great job and now we are able to run tests of our scenario of a helper robot  in a shopping mall. Based on a map built using laser SLAM, the robot computes the shortest path to fetch items listed by a customer in a shopping list. The slides below include a video of the first tests. They also give a bird’s eye view of the architecture, where we use Pharo for orchestration. We also reuse existing software from the ROS community through our client PhaROS.

Deep into Pharo is the second volume of a series of books covering Pharo. Whereas the first volume is intended for newcomers, this second volume covers deeper topics.

External Page: cover.min.jpg

TopicsYou will learn about Pharo frameworks and libraries such as Glamour, PetitParser, Roassal, FileSystem, Regex, and Socket.
You will explore the language with chapters on exceptions, blocks, small integers, and floats.
You will discover tools such as profilers, Metacello and Gofer.

In the RoboShop project, we aim at developing a platform for robotic applications in a shopping mall. We took the decision to use ROS, the robotic middleware backed by the Open Source Robotic Foundation. We also wanted to continue using our favorite language Pharo. This is how we end up developing PhaROS, a client for Pharo-based ROS nodes.

Today, we are glad to announce that the first version of PhaROS is now officially available, that is there is :

There is still much to do in PhaROS, and more broadly in the RoboShop project. But, so far we already have a PhaROS node that wraps the robot that we are using. We connected it to the gmapping SLAM algorithm and we have used it to buid a map of our lab. More to come soon.