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

CodeJam is a programming contest. It includes a lot of problems.
For each problems, 2 data sets are provided: a small one and a large one. It is really interesting to learn programming.
You can try a solution on the small data set and also send it to the CodeJam web site to know if it is correct and then try on the larger data set.

CJSover is a framework written in Pharo to easily implement algorithms to solve CodeJam problems.
It simplifies data file reading and writing. I also implemented some (really naïve and non-optimized ;-)) solutions to some problems.
And for those “solved” problems, I commit here the correct solution to then be able to run automated tests that re-run them.

HOW TO USE

$git clone https://github.com/LucFabresse/CJSolver.git CJSolver.git$ cd CJSolver.git
$sh newImage.sh # this will download the Pharo VM + Pharo image + load the CJSolver code$ ./pharo-ui cjsolver.image

I did this small framework because:
- I want that students learn Pharo,
- I want that students participate to some programming contests using Pharo,
- I want to show students that YES, we can also implement these problems in Pharo

or implement solution to new problems,
and have fun ;-)

# 1- Create a category

Before creating a block, you probably need to create a category. By default, in Phratch there are 10 shown categories. Each of these categories has 4 properties:

• a label, which is shown as the name of the category (for example “Motion”)
• a color, which is the color of the blocks inside the category. For now, the category has not necessarily the same color because the display of a category is based on an image in the scrachSkin subdirectory. This point is not explained here. We will use a basic color for the category.
• an order number, which represents the place of your category in the display screen.
• a viewer page, which represents how the category is displayed when we click on it. Most of the categories have the basic behavior (displaying blocks), but sometimes, we can need specific ones. For example,the category “Variables” has some buttons (Make a variable, Make a list and Make a block). Here we will use the basic viewer page.

So, let’s go for creating our own category.
In the Pharo environment, create a class which is a subclass of PhratchCategory, like the following one:

PhratchCategory subclass: #PhratchCategoryMyFirst
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: ‘MyOwnBlocks’

color
^(Color r: 0.1 g: 0.2 b: 0.7)

where the color can have others values.

label
^'my category'

This label will be used to place your future block in this category and is used for the display.

order
^9

which gives the place where the category will be placed.

Your first category is done. Congratulation !
To see it in Phratch, just relaunch Phratch, with this command:

PhratchFrameMorph closeAndOpen.

Your empty category is available in the Phratch environment.

A last thing about category: when a category is created, a new setting appears in the Setting browser. This setting allows to show or hide the category in Phratch. By default, the value is true.

# 2- Create a specific sprite

In Phratch a block is a message sent to a Sprite. By default the Sprite “Sprite1” is a PhratchSpriteMorph. If you need to have a specific behavior, just create a subclass of it. Then, you will have the possibility to select this new specific sprite when creating a new sprite in Phratch.

In this tutorial, we do not create a new sprite. We will use the generic one.

# 3- Create a first blocks

In PhratchSpriteMorph, create a protocol “*MyOwnBlocks”, to be clean with the modularity of the system.
Then you can add your behavior. It can be what you want. For example, I want to open a Transcript. For that, my method is:

openTranscript
^Transcript open

For now, the method is not visible in Phratch. To make it visible, add the following pragma:

openTranscript
<phratchItem: 'open a transcript'
kind: #-
category: 'my category'
defaultValues: #()
subCategory: #a
special: #()>
^Transcript open

When updating the view in Phratch, by clicking on “My category” a new block appears. By clicking on this block a transcript appears.
You have written your first block !

The pragma used to declare a new block in Phratch has the following form:

<phratchItem: '' kind: #- category: '' defaultValues: #() subCategory: #a special: #()>
• phratchItem contains the label of the block. It contains also the entry for parameters.
• kind is the kind of block. By default “#-“ means that the block is a CommandBlockMorph.
• defaultValues is an array with the default parameter if your block needs them.
• subCategory is a symbol that allows you to order blocks inside your category.
• special is an array with special behavior that should be executed on the block before the block execution (the main use is the parametrization of the block itself).

Let’s go for another example. Write this method, which open a Nautilus browser a a specific class:

openBrowserOn: aStringClass
<phratchItem: 'open a browser on: $String$'
kind: #-
category: 'my category'
defaultValues: #('Collection')
subCategory: #a
special: #()>
Nautilus fullOnClass: (Smalltalk at: aStringClass asSymbol)

Here, you can see that a parameter is present in phratchItem: this parameter is a String. So, we have a block that open a browser on a class that you can parametrize. The default value is ‘Collection’. You can change it by an existing class.

In Phratch environment, click on this new block, you will see a browser on Collection.

# 5- Types

All types are declared in the class PhratchType.
Each type is declared with the pragma <phratchType: #’’>. You can browse these methods to see existing types.

# 6- Kind of blocks

A block can have multiple forms. In our examples, we manipulated the CommandBlockMorph. It exists multiple ones. You can see them as subclasses of BlockMorph.
The main ones are CommandBlockMorph that executes a command, ReporterBlockMorph that returns a value, BooleanBlockMorph that returns a boolean.

I stopped this tutorial here. It is enough to write simple blocks in Phratch. You can discover kinds of block or types by right-clicking on an existing block of the system, then ‘show block’ in the menu. You will see the method and particularly the associated pragma.

Dear smalltalkers, phratchers and everybody interested to help Phratch development.
We need you as an international community. Phratch needs your help to be multilingual.

The most of work is already done, It is based on the Scratch work (Thank you for all the supported languages). Now, as Phratch has a lot of new features, we need to translate each of these new features.

For each of the following languages (ar, bg, ca, cs, da, de, el, es, et, eu, fa, fi, fr_CA, gl, he, hr, ht, hu, id, is, it, ja_hira, ja, kn, ko, lt, mk, mn, mr, ms, ne, nl, no, pl, pt_br, pt, ro, ru, rw, sk, sl, sv, th, tr, uk, vi, zh_cn, zh_tw), we need to complete the lines available in the phratch issue tracker (https://code.google.com/p/phratch/issues/detail?id=120). You can post your work as a comment or send me a mail, I will then integrate it in Phratch.

For each expression there is a msgid in english, that should not be changed. Then, there is a msgstr that should be complete in the specific language. All elements in the  (like $Number$) are variables, they should not be changed but they have to be integrated in your translation. For example, in french:
===
msgid “replace costume $Number$ with $NewCostume$”
msgstr “remplacer le costume $Number$ avec $NewCostume$”
===

There is less than 130 small expressions. It is 1 or 2 hours of work, and it helps us a lot.

Lots of fonts are available for LaTeX here

1. Example: install the emerald package


wget http://mirrors.ctan.org/fonts/emerald.zip
unzip emarald.zip

ln -s ~/Libary/texmf .texmf # because I am on mac

cp -fr emeral/tex/latex/emarald/ ~/.texmf/
cp -fr emeral/fonts ~/.texmf/

cd ~/.texmf
texhash .

cd ~/.texmf/fonts/map/dvips/emerald.map
updmap updmap --enable Map emerald.map


2. emerald-test.tex


\documentclass[11pt]{article}

\usepackage{emerald}
\usepackage{lipsum}

\title{Emerald testing}
\author{Luc Fabresse}
\date{}

\setlength{\parskip}{2ex}

\newcommand{\showFontaux}{normalfont}
\newcommand{\showFont}[1]{%
\renewcommand{\showFontaux}{#1}%
\csname \showFontaux \endcsname%
\marginpar{\vspace*{0.6cm}\small\csname \showFontaux \endcsname #1}%
\lipsum[2]%
\normalfont
}

\begin{document}
\maketitle

We are going to try a series of standard Laserwriter fonts.

\showFont{ECFAugie}
\showFont{ECFJD}
\showFont{ECFAPictureAlphabet}
\showFont{ECFIntimacy}
\showFont{ECFIntimacyDeux}
\showFont{ECFMovieola}
\showFont{ECFMovieolaTitleType}
\showFont{ECFPookie}
\showFont{ECFPookieType}
\showFont{ECFSkeetch}
\showFont{ECFSpankysBungalow}
\showFont{ECFSpankysBungalowItalico}
\showFont{ECFSpankysBungalowBlanco}
\showFont{ECFSpankysBungalowBlancoItalico}
% \showFont{ECFSyriac}
\showFont{ECFTallPaul}
\showFont{ECFTeenSpirit}
\showFont{ECFWebster}

\end{document}


3. Compile and see

pdflatex emerald-test.tex


Do you know Lego MindStorms ? The last one is the Ev3 serie (http://www.lego.com/fr-fr/mindstorms/). One particularity of this version compared to the previous ones is the possibility to plug a Wifi key and connect via TCP.

So, if you have this material (one Mindstorms Ev3, one compatible Wifi key), you can control your robot with Pharo !

Gofer it
package: 'ConfigurationOfJetStorm';
(Smalltalk at: #ConfigurationOfJetStorm) loadBleedingEdge.

I know also that for Christmas, it is not possible to learn a new API, we all have a lot of other things to do ! So, you can play with it into Phratch.

For that, just load Phratch and the package EV3Phratch as follow.

Gofer it
package: 'ConfigurationOfPhratch';
(Smalltalk at: #ConfigurationOfPhratch) loadBleedingEdge.
Gofer it
package: 'EV3Phratch';
load.

Have fun !

Packt publishing offers great discount on their books this Christmas.

Following on from the success of last year’s festive offer, the publisher will be celebrating the holiday season with an even bigger $5 Bonanza. From December 19th, customers will be able to get any eBook or Video from Packt for just$5. This sale covers every title in the 1700+ range and customers can grab as many as they like until January 3rd 2014 – more information is available at http://bit.ly/1jdCr2W

I continue to develop Phratch, the port of Scratch in Pharo. Phratch is a visual programming language on top of Pharo.

There are lots of new features:

• Settings
• FileSystems
• Metacello
• integration of BYOB (allows to build your own blocks)
• integration of Color and Files
• a lot of new useful blocks
• projects saved with Fuel
• possibility to implement new features without modifying the core of the system
• possibility to customize the environment: add new categories, add new kinds of Sprite, add new blocks.

Phratch is available for Pharo2.0 with the following configuration:

Gofer it
url: 'http://smalltalkhub.com/mc/JLaval/Phratch/main'
package: 'ConfigurationOfPhratch';
((Smalltalk at: #ConfigurationOfPhratch) project version: '1.0') load.
(Smalltalk at: #PhratchFrameMorph) open perform: #saveImageForEndUserSilently.

I hope to write documentations about all of the new features asap.

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:

Reviewers:

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

Members:

• 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