Planet Smalltalk

July 27, 2014

Pharo Weekly - Another powerweek for Pharo

13701 Duplicated methods in menuMorph

13700 AlignmentMorph cleaning

13683 Morph>>changeColor should be an extension of ColorPicker

13687 HSVAColorSelectorMorph should be moved to ColorPicker

13697 Yet another cleanup of MessageBrowser API

13698 Small cleanup of Model and the UI package

13696 Nautilus Refactoring 1: Classlist widget

13694 Small cleanup in System-Changes

13695 cleanup MessageBrowser API a little

13666 Small Code critique cleanup of Kernel

13677 Move WindowEvent to Morphic-Core

13692 Small cleanup GroupManageUI: #prettyName not needed (same as printString now on methods and classes)

13670 Encoder (class from Old Compiler) is referenced by BlockLocalTempCounter

13691 Small Code Critique clean in Morphic-Widgets-Pluggable

13689 Wrong context when debugging a warning

13684 missing code completion in Spotlight

13519 Problem when printing heaps

13571 Something is completely broken regarding Slice submission

13675 safer windows enumeration

13676 safer usage of KMBuffer in HandMorph >> #generateMouseEvent:

13669 CompilerNotifying test failing on main build

13674 safer access to top current window

13667 Delete empty package System-Tools

13664 Remove all references to CodeHolder

13629 Polymorph-Widgets still extends ThreadSafeTranscript

13661 Shadow variables in kernel Context

13662 Merging Opal branch with trunk

13625 we can merge System-Tools with Tool-Base

13570 Add-Halo, menu, mouse on export…. hangs image

13654 Pressing Enter in EyeInspector gives MNU: TextModel>>asText

13653 Add Additional Basic Pharo help to the System Help browser

13660 reduce references to StringHolder

13655 System-Localization and Gettext have classes with identical names

13656 remove CompiledMethod searchForClass and searchForSelector

13657 Remove at: check from RBConsistencyCheckRule

13648 remove VTermInputDriver

13651 move font related methods in BitBlt to Graphics-Fonts package

13649 move ThreadSafeTranscript >> #codePaneMenu:shifted: to Tool-Transcript package

13647 unimplemented #poolDictionaries called by Class, TClass and Trait

13652 move class side ThreadSafeTranscript examples, menuCommandOn: and open to Tool-Transcript package

13645 Small CodeCritique Cleanup of Network-Mail

13643 Move extensions of Package Compiler to Kernel

13642 remove registration of #userManager from ToolsRegistry

12975 Metacello ProfStef use inexistant browse:selector:

13644 Small Codecritic cleanup of Network-MIME

13646 MIMELocalFileDocument seems to be dead code

13638 remove SUnitUnloader

13588 Rename inst var should rename accessors too

13568 Better error message when using “-” prefix

13632 MetaLinks for Globals

13633 Some repacking of Network: NetworkSystemSettings and RFC822

13634 remove empty package PackageInfo

13568 Better error message when using “-” prefix

13632 MetaLinks for Globals

13633 Some repacking of Network: NetworkSystemSettings and RFC822

13634 remove empty package PackageInfo

13630 Links on Class Variables

10034 Remove PackageInfo from system

13623 Move DynamicMessageImplementor close to DebugSession

13621 remove old BreakPoints for now

13624 remove DifferatorSystemSettings

13622 Small Cleanup related to StringHolder and Explorer

13620 LinkWrapper Slot: first working version

13611 add MorphicCoreUIManager

13619 Small cleanup related to Explorer

13604 MorphicModel: ivar accessor only used by Slide and not needed even there

13617 Fixing some tools package extension

13613 move tests from Multilingual-OtherLanguages to Multilingual-Tests package

13614 move RBProgramNode>>#method to accessing category

13616 Lost browseChangesFile: was lost

13608 remove ThumbnailMorph

13610 Taskbar can be packaged separately

13612 Move polymorph extension to workspace

13609 WorkArea could be removed

13615 Finish to split Tools

13592 Small RB Tests cleanup

13589 deprecated TimeStamp

13590 TimeStamp has still instances

13591 unload tests Metacello-TestsTutorial

Jordi Delgado - ESUG 2014 REMINDER: 11th Innovation Technology Awards

ESUG 2014, 11th Innovation Technology Awards

Have you written innovative Smalltalk? The developers of any Smalltalk-based software can enter by submitting a 3-5min video of their software. Entrants demo their systems in a session at the end of Monday August 18th 2014, after which the conference attendees vote. (A vote consists in providing a sorted list of 3 preferred pieces of software.)

The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros. The results are announced in the Awards ceremony that is held during the social event.

Applicants should provide the following information on the conference registration server. Once you have registered your personal info, an 'Awards' menu allows submitting your software. You can provide this information when you first register, or login again later and update your details. The registration server will open soon. You can start preparing your software right now though.

Info to provide:

  • Name of the software
  • Licence information (free, shareware, or commercial)
  • Name of the Smalltalk dialect used
  • Name, Affiliation and Country of developers

Besides, it would be great if the submission could include:

  • URL for a video (3-5 min) showing a screencast / demo of the software
  • URL for downloading the software or at least a runnable demo
  • Deadline: August 15th

Any Smalltalker can apply (students, companies, ...). The presented piece of code/software should be written in Smalltalk or directly support Smalltalk (e.g. Smalltalk VM). All Smalltalk dialects are accepted. The applicant should be "strongly related" to the presented code, be it as an author, as owner of the copyright/copyleft, or as an official representative of the copyright/copyleft owner.

July 26, 2014

Pharo Weekly - A PharoLauncher lover

Torsten Bergman wrote the following:

PharoLauncher [1] allows you to work with many Pharo images. You can download fresh images, clone existing ones and with its access to the Pharo CI it allows you to easily reproduce errors in specific Pharo image versions. I REALLY like this tool when working with Pharo. There is a customizable hardware key on my laptop that I can just press to open PharoLauncher, manage and launch the images and dive into the world of Pharo. To optimize my Pharo "easy access workflows" further I wanted all the images that I started with PharoLauncher: - to share a common metacello repository cache (where all the mcz are stored independent from image location) for faster loading - to have the possibility to preset the Squeaksource, SS3 and STHub password already - to set my authors name All this is already explained in Marianos blog posts [2] and [3] and the PharoEnterprise book [4]. Nonetheless I would like to share the script that I personally use. Maybe (in an adopted version) it is usefull for other PharoLauncher users as well: ===================================================================== COMMON SETTINGS FOR ALL PHARO IMAGES WHEN STARTED USING PHAROLAUNCHER ===================================================================== Open any Pharo 3.0/4.0 image and execute StartupPreferencesLoader preferencesGeneralFolder fullName in a workspace to find out the common preferences folder on your local machine. You can put a Smalltalk script into this folder, for instance "" that is evaluated each time an image runs. I've found the following script very useful: ----------------------------------------------------------------- | sharedPackageCacheDirectory | "Never apply to PharoLauncher itself" (SmalltalkImage current imageName includesSubstring: 'Launcher') ifTrue: [ ^self ]. "ask if script should be applied" (UIManager default confirm: 'Apply init script from ', StartupPreferencesLoader preferencesGeneralFolder fullName,' to image') ifFalse: [^self ]. "Use a shared package cache to store Monticello MCS files for all images" sharedPackageCacheDirectory := 'C:\Pharo\commonpackage-cache' asFileReference ensureCreateDirectory; yourself. MCCacheRepository default directory: sharedPackageCacheDirectory. "Set password for Squeaksource" (MCRepositoryGroup default repositories select: [:each | (each isKindOf: MCHttpRepository) and: [((each locationWithTrailingSlash includesSubstring: '') or: [each locationWithTrailingSlash includesSubstring: ''])] ]) do: [:each | each user: 'squeaksourceuser'; password: 'secretsqueaksourcepassword']. "Set password for SmalltalkHub (hub and HTTP repos)" (MCRepositoryGroup default repositories select: [:each | (each isKindOf: MCSmalltalkhubRepository) and: [each locationWithTrailingSlash includesSubstring: ''] ]) do: [:each | each user: 'PharoUser'; password: 'sthubpassword']. (MCRepositoryGroup default repositories select: [:each | (each isKindOf: MCHttpRepository) and: [each locationWithTrailingSlash includesSubstring: ''] ]) do: [:each | each user: 'PharoUser'; password: 'sthubpassword']. "Set author name" Author fullName: 'PharoUser'. UIManager default inform: 'Script applied'. ----------------------------------------------------------------- Hope it is usefull for others too. Bye T. [1]!/~Pharo/PharoLauncher [2] [3] [4]

Pierce Ng - ROEing

I’ve been playing with the OpenFootball data using ROE. ROE provides RAArrayRelation, which shares a common superclass with RASQLRelation. As its name implies, RAArrayRelation uses an in-memory array object and does not involve any underlying SQL database.

In my OpenFootball data crunching, I tried JOINing instances of both. When the left side of the JOIN is the RASQLiteRelation instance, the operation threw an SQLite exception “no such table” because ROE expected the right side to also be an RASQLiteRelation on the same underlying database. When the left side is the RAArrayRelation instance, the operation sends #tuples to the right side, which resulted in a DNU. I’ve tried a few implementations of RASQLiteRelation>>tuples, but so far no success. Even if I get a working implementation, the implication of #tuples is that all matching rows from the SQLite database are loaded into memory, which is not always performant or feasible.

The reason for using an RAArrayRelation is to create a new relation unlike any existing one. The alternative is to create an RASQLiteRelation instance on a new, empty table. However, ROE does not support creating tables in the underlying database. Of course, I can use the given database connection to CREATE TABLE via direct SQL, but that doesn’t feel satisfying.

July 25, 2014

Torsten Bergmann - Private Pharocloud Smalltalk source code repository

How to run a private Smalltalk source code repository on Pharocloud is explained here.

Joachim Tuchel - Glorp: How to create Foreign Keys with ON DELETE SET NULL

Just in case you need to define a foreign key constraint in your Glorp Descriptor System that set the foreign key to null on deletion rather than throw an SQL error, look no further, here is how to do it

Ricardo Moran - Leap Motion & Ableton Live

Hola a todos!!!

Hoy les voy a hablar sobre la combinación del poderoso Leap Motion con Ableton live.

Para introducirlos en el tema, el Ableton es un software de producción musical de cualquier estilo basado en una interfaz simple en donde podes crear música desde cero con plugins, sintetizadores y/o un teclado midi, también usado para hacer música en vivo. Es popular en el género de la electrónica y también es usado por productores famosos como Hardwell, DVBBS, Skrillex, dimitri vegas y muchos más…

¡Ahora la parte interesante! con el Leap Motion se crearon diferentes plugins para combinar este chiquito pero poderoso dispositivo con Ableton.

¿Qué es lo que se puede hacer con él? esa respuesta es muy amplia ya que directamente se puede hacer lo que uno quiera, mientras cada uno a su gusto lo configure según sus necesidades. Se puede tocar el piano, manejar efectos tales como filtros y otros, subir/activar volúmenes de diferentes pistas y muchísimas cosas más, pero.. la mas importante y a lo que viene esta publicación, es poder tocar en vivo una canción entera con todas sus partes.

¿Cómo es posible esto? es posible gracias a Uwyn quien creó una app llamada GECO que funciona como interfaz entre el Leap motion y Ableton live y se encuentra disponible en el AIR SPACE STORE  (corre sobre Windows y MAC). La app te permite, con gestos predeterminados, asignarlos a diferentes acciones en el Ableton. Por ejemplo, uno puede decir que bajando la mano en linea recta puede subir y bajar el volumen de la pista deseada o manejar un filtro en su cantidad. En el momento de tocar en vivo, lo principal es asignar movimientos para poder ir activando las diferente partes (o samples) previamente creados y así unificarlos de una forma con el fin de crear un tema completo.

A continuación, les muestro un video de Uriel Yehezkel tocando con Leap motion en Ableton Live.


July 24, 2014

Pharo Weekly - Deprecator

Hello Pharo users,

I’m pleased to announce the release of Deprecator.
It’s a prototype of a small tool that permits you to deprecate method by annotating them with a <deprecated: …> pragma.
This pragma takes a rewrite expression as argument that specifies how to rewrite the message send to the deprecated method. 
If such a deprecated method is executed, a warning is thrown and a debugger opens.
This debugger has a little ‘Rewrite’ button that permits to rewrite the sending method according to the rewrite expression and then resume the execution with the new rewritten sending method :)
The implementation is a proof-of-concept and is a bit hacky here and there, but it works. 
You have a class C with a method that you deprecate. 
Its rewrite expression tells that if it’s executed as the result of a message send of the form: 
<receiver> deprecatedMethodArg1: <arg1> arg2: <arg2>
this message send should be rewritten to: 
<receiver> replacementMethodArg1: <arg2> arg2: <arg1>.
 Note you can change the order of arguments or even the receiver.
C>>deprecatedMethodArg1: o1 arg2: o2
<deprecated: ‘`@receiver replacementMethodArg1: `@arg2 arg2: `@arg1′>
  ^ #deprecated
C>>replacementMethodArg1: o1 arg2: o2
^ #replacement
^ self deprecatedMethodArg1: 1 + 1 arg2: 2 + 2.
Then if you execute C new senderMethod, and then click on the “Rewrite” button of the debugger, then sending method is rewritten to:
^ self replacementMethodArg1: 2 + 2 arg2: 1 + 1.
and the result is #replacement
The repo is on sSmalltalkHub:
user: ”
password: ”
I hope for comments, feature suggestions, code reviews, contributors, etc :) 
BTW, if you have a better name for this project let me know! 
For example, I thought about Ammonite because it’s an extinct animal (analogy with deprecated) and it fits the sea naming theme.

Smalltalk Jobs - Say hello to our new volunteer!

Please welcome our latest volunteer Deanna Simpson.

She is a long time member of the Smalltalk community, and she will be reporting on the open Smalltalk positions she finds in Canada.

We are still looking for volunteers to help us increase our coverage in other parts of the world. If you are interested in helping, please contact one of us to let us know.

James T. Savidge
View James T. Savidge's profile on LinkedIn

This blog’s RSS Feed

Filed under: Community Tagged: Smalltalk jobs

Yoshiki Ohshima - [仕事?] J言語をOMeta2/Squeakで作る

APLの集まりに参加した関係上、私も処理系の1つぐらいは作らなくてはな、ということで雑用に追われる中(実は転職しました)ちょっと作ってみました。 実装の都合上、シンボルはAPLのシンボルではなく、ASCIIベースでやっているJ言語のものを使っています。 実装に使う言語はOMeta2/Squeakで、パーザーとインタープリターをそれぞれ別のクラスとします。あ、ちなみに世界に蓄積された「効率の良いAPL処理系を作る」ためのノウハウ( ...

July 23, 2014

Torsten Bergmann - Package Dependencies Analysis in Pharo with new features

Package Dependencies Analysis in Pharo has new features. Read more

Smalltalk Jobs - Smalltalk Job in Canada

Job Title Junior Software Developer
Reports to Chief Technical Officer
Closing Date for Applications August 1, 2014
Submission Information Bruce Kowbel, COO

Position Summary

Based in SageTea’s Ottawa office and reporting to the Chief Technical Officer with guidance from the senior software developers, the Junior Software Developer will become part of a team creating a tool that redefines how software is created.


  • Develop and augment software features
  • Create object-oriented software features as defined by the Chief Technical Officer and senior software developers
  • Document all work and design notes
  • Demonstrate new features internally
  • Test all features to verify they comply with the design
  • Follow standard coding conventions
  • Read and understand functional and technical documents
  • Report on current progress and meet deadlines
  • Identify technical deficiencies in design
  • Multitask to handle several priorities

Skills and Qualifications

  • Bachelor’s degree
  • Minimum 2 years related experience
  • Strong object-oriented development background
  • Knowledge of VisualWorks Smalltalk is an asset
  • Excellent communication skills in English (both written and verbal)

Filed under: Employment

Smalltalk Jobs - Smalltalk Jobs 7/23/2014

Nice looking Smalltalk/Gemstone job in banking in Zuerich. 

Zuerich is a nice city and there are loads of banks.

Filed under: Employment

Pharo News - Pharo4: already over 100 updates!

<p>The development of Pharo4 has started to pick up speed. We already are at update #117.</p> <p>Some examples:</p> <ul><li> The dark theme has been integrated</li><li> Cleanups related to dead code (e.g. PackageInfo)</li><li> First class instance variables (Slots) and Globals</li><li> Improved refactoring (see <a href="">here</a>)</li><li> Smart breakkpoints (see <a href="">blog</a>)</li></ul> <p>The latest build is available from the <a href="">ci server</a>.</p>

Pharo News - Pharo4: already over 100 updates!

<p>The development of Pharo4 has started to pick up speed. We already are at update #117.</p> <p>Some examples:</p> <ul><li> The dark theme has been integrated</li><li> Cleanups related to dead code (e.g. PackageInfo)</li><li> First class instance variables (Slots) and Globals</li><li> Improved refactoring (see <a href="">here</a>)</li><li> Smart breakkpoints (see <a href="">blog</a>)</li></ul> <p>The latest build is available from the <a href="">ci server</a>.</p>

Torsten Bergmann - Smart Breakpoints alpha Release

Torsten Bergmann - ScienceSmalltalk v0.12

There is a new release of SciSmalltalk v 0.12 (written in Pharo Smalltalk) available. Also check out the project page on GitHub.

Beside many others you can use it for mathematical epidemiology modeling, look here for a quick start example on how to obtain the numerical solution of a simple one-dimensional Ordinary Differential Equation (ODE) and visualizing results using Graph-ET.

Torsten Bergmann - Essence# Invoking .NET with out/ref parameters

A detailed story on invoking .NET methods that have “out” or “ref” parameters from Essence#, a Smalltalk for .NET platform.

Torsten Bergmann - Improved refactorings

More improvements on the refactoring side of life.

Essence# - Invoking .Net methods that have “out” or “ref” parameters

The latest release of Essence# introduces the ability to invoke .Net methods that have “out” or “ref” parameters. This post will explain what those are, why supporting them is a technical challenge, and how to pass such parameters to .Net methods that use them.

Conceptually, there are only two ways to pass parameters to functions: By value or by reference. Although there are (usually rather old or even ancient) programming languages that pass all parameters “by reference,” most programming languages pass parameters “by value” in the default case. And some languages, such as Essence#, pass all parameters “by value.”

The following example will be used to illustrate the difference in the semantics:

var x = 3;
var y = f(x);

If the variable x is passed to the function f as a “by value” parameter, then it will be impossible for the function f to change the value of the variable x. However, if the variable x is passed to the function f as a “by reference” parameter, then the function f will be able to change the value of the variable x (although it may nevertheless refrain from doing so.)

Although there is more than one way to implement the two different ways of passing parameters, conceptually the difference is that, when arguments are passed “by value,” only the value of the argument is passed in to the function being called, whereas when arguments are passed “by reference,” the address of the argument (typically, the address of a variable) is passed in to the function being called. In the latter case, the called function may use that address to assign a new value to the variable–although it need not do so.

In fact, many languages implement “pass by value” semantics by physically passing in the address of the arguments that are passed “by value,” but nevertheless disallowing assignment to function parameters. As Peter Deutsch famously said, “you can cheat as long as you don’t get caught.” However, neither the CLR nor the DLR’s LINQ expression compiler cheat in that way: Unless a parameter is declared to require “pass by reference” semantics, arguments are passed by copying their values into the activation frame of the function being invoked.

So the problem for languages implemented on the CLR, such as Essence#, that have no syntax for specifying that parameters will be passed “by reference,” is that there’s no straightforward way to invoke the methods of CLR types that have any “pass by reference” parameters, where the intended usage is that the called method will, as part of its normal operation, assign a new value to an argument that is passed by reference.

And there’s an additional complication: Some methods that use “pass by reference” parameters will neither need nor use the initial value of the parameter, because they only set its value, and never “read” it. Conversely, others will use the initial value to compute and set a new value for the argument. And yet others may do one or the other with the same parameter, depending on the state of the receiver and the value of other parameters.

The C# language attempts to reduce the ambiguity regarding the usage model of “by reference” parameters by requiring that the method definer use different syntax to declare parameters, depending on whether the method will or will not use the initial value of a “by reference” parameter to compute and then set the argument’s new value. In the C# syntax, a parameter that is passed by reference must have one of two keywords as a prefix: out or ref.

The C# out keyword causes the compiler to require that the method that declares the parameter must first assign a value to the parameter before the parameter can be used–and before the method can return. That makes it impossible to use or access the initial value of the parameter. In contrast, the C# ref keyword causes the compiler to require that whoever invokes the method must first assign a value to the parameter.

But C# is not the only language used on the CLR, and the CLR itself does not enforce any constraints on the usage of “by reference” parameters. A .Net language’s compiler may do so, but such is not required by the CLR. That means there may exist .Net types that have methods that use “pass by reference” parameters that do not abide by the rules of C#.

The reflection metadata provided by the CLR does reveal, for each method parameter, whether it is a “pass by value” or a “pass by reference” parameter.  It may also reveal whether the intended usage of a “pass by reference” parameter is as a C#-style out parameter. But compilers are not required to provide that particular piece of metadata. The parameter may be used as an out parameter even if the reflection metadata makes no such claim. The only information provided by the reflection metadata that must be accurate is whether or not the parameter requires that its corresponding argument be passed “by value” or “by reference.”

So for now, Essence# deals with .Net method parameters that require that arguments must be passed by reference in one of two ways:

If the actual argument at runtime is anything other than a block or delegate, the dynamic binding subsystem will create and initialize a new variable that will be passed as the argument. Unless the reflection metadata claims that the parameter is an “out” parameter, the variable will be initialized to have the same value as the argument specified by the invoking code. The method will then be invoked with that new variable as the argument corresponding to the “by reference” parameter. When the method completes, the value of the created variable that was passed in as the actual argument will be assigned to the expression that represents the originally-specified argument. That assignment may cause an exception, and it may fail to update the original variable. I’m researching improvements, perhaps using the DLR’s Meta Object Protocol.

However, if the actual argument at runtime is a block or delegate, then the dynamic binding subsystem will create and initialize a new variable that will be passed as the argument (just as it does for the other case.) The method will then be invoked with that new variable as the argument corresponding to the “by reference” parameter (still essentially the same procedure as in the other case.) But when the method completes, the procedure is different: The one-argument block or delegate that was the originally-specified argument will be invoked, with the newly-created variable as its argument. That permits the caller to access the value of the “out” parameter, because its value will be the value of the block (or delegate) argument. Note, however, that the block or delegate must have an arity of one, and if it’s a delegate, its parameter type must be assignable from the parameter type of the invoked method’s parameter.

Example Usage

Let’s assume that we want to invoke the method Get as defined in the C# class named ValueModel shown below:

class ValueModel {
        private static readonly Object notAValue = new Object();

        protected Object value = notAValue;

        public bool HasValue {
                get {return value != notAValue;}

        public void Set(Object newValue) {
                value = newValue;

        public bool Get(out Object value) {
                if (HasValue) {
                        value = this.value;
                        return true;
                return false;

If we have an instance of the above ValueModel class in a variable named model (in an Essence# block or method,) we can invoke the Get method as follows:

[:model |
        | value |
        (model get: [:v | value := v])
                ifTrue: [value doSomethingUseful]

Or more simply, we could just do:

[:model | model get: [:value | value doSomethingUseful]]

Important: If the .Net method being invoked returns a boolean value, then the block will only be invoked if the .Net method returns true. But if the .Net method has a return type of void, or has a return type other than Boolean, then the block will always be invoked.

July 22, 2014

ESUG news - [ANN] SciSmalltalk v0.12

We are to happy to announce SciSmalltalk v0.12

SciSmalltalk is a new Smalltalk project, similar to existing scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby.

SciSmalltalk already provides the following basic functionalities:

  • complex and quaternions extensions,
  • random number generators,
  • fuzzy algorithms,
  • LAPACK linear algebra package,
  • Didier Besset's numerical methods,
  • Ordinary Differential Equation (ODE) Solver).

Everything is available herehere>*

This version should work on Pharo 2.0/3.0/4.0 and also Squeak 4.5 (to be confirmed).

We are a small community, we are looking for more volunteers to contribute code and documentation. Please join us at :!forum/scismalltalk

Essence# - Acts: New Release Of Essence# Introduces Threads

Essence# was released to the public almost 2 months ago. Since that time, the following features and capabilities have been added: Exceptions, Collections, Traits, Announcements and .Net Events, passing blocks as parameters to .Net methods where the corresponding parameter is a .Net delegate, and defining Essence# classes that represent .Net generic type definitions.

And now the ‘Acts’ release of Essence# introduces support for Threads, (asynchronous) Tasks, Semaphores, Monitors and Mutexes, the ability to call .Net methods that use “out” or “ref” parameters, the ability to convert Essence# arrays into .Net arrays (with any .Net type as the element type,) the ability to create such arrays, and the ability to construct closed generic types from open generic type definitions, and create instances of those types. And it fixes various bugs.

The Acts release can be downloaded from the Essence# site on CodePlex (which gets you the installer.) Alternatively, the code for the run time system (written in C#) can be obtained from theEssence# CodePlex site using Git, and the code for the Essence# Standard Library can be obtained from GitHub. And the example scripts can also be downloaded from the Scripts repository on GitHub.

The Essence# Development Plan

Before getting into the details of the new features and capabilities introduced in this release, I should explain the overall development plan:

The highest priority goes to making the compiler and the run time system work correctly. The next priority is adding whatever features to the compiler and/or the run-time system may be required to a) have a fully-functional programming language that conforms to the ANSI Smalltalk standard to the extent that that’s possible on .Net, and b) to enable the maximal degree of interoperability with .Net that is possible without compromising support for the language’s conformance to the ANSI Smalltalk standard. Next to lowest priority is adding whatever classes or methods to the Essence# Standard Library may be required in order to conform to the ANSI Smalltalk standard. And everything and anything else has the lowest priority.

Essence# will stay in alpha until both the language and the standard class library provide full ANSI Smalltalk compatibility, to the extent that that’s possible on .Net.  It will remain in beta until Essence# code a) can be compiled to .DLLs and .EXEs, and b) can be debugged using the Visual Studio debugger. The second requirement depends on the first–debugging with Visual Studio is simply not possible using the type of  (CLR) methods that the Essence# compiler currently generates (which .Net calls “dynamic methods.”)

Typically, when support for new feature domains is added to Essence# (e.g, exceptions, collections, events, threads, files/streams, etc.,) the first step will be releasing Essence# classes that simply wrap the native .Net classes for that feature domain. In some cases, nothing more will be needed. But in most cases, in order to provide ANSI Smalltalk conformance,  it will be necessary (in later releases) to add more classes and methods to the Essence# Standard Library that provide an ANSI Smalltalk facade over the native .Net classes.

Completing the task of adding Essence# classes that wrap (directly represent) the native .Net classes that are needed to complete the planned feature set of the Esssence# Standard Library has priority over implementing Essence# classes that adapt those classes so that they provide an API that conforms to the ANSI Smalltalk standard. That’s why this release does only the former, and not the latter (with some minor exceptions.) It’s also why the same will be true for the next major feature domain: Streams and files.

Using the Essence# Concurrency Classes

This release implements Essence# classes that represent (“wrap”) many of the core .Net classes for multitasking and concurrency that are defined in the .Net System.Threading namespace, such as Thread, Monitor, WaitHandle, EventWaitHandleSemaphoreSlim, Mutex, SpinLock, SpinWait, ReaderWriterLockSlim and ThreadPool.  It also implements Essence# classes that represent (“wrap”) many of the classes defined in the .Net System.Threading.Tasks namespace, such as Task, TaskScheduler and Parallel.

The new classes reside in the Essence# Standard Library in the namespaces CLR.System.Threading and CLR.System.Threading.Tasks. In a few cases, the Essence# class name is not the same as the .Net class name. Examples: CLR.System.Threading.Semaphore -> System.Threading.SemaphoreSlim, CLR.System.Threading.ReaderWriterLock -> System.Threading.ReaderWriterLockSlim.

Note that these new classes are not defined–and therefore not visible–in the default system namespace (“Smalltalk.”)

Also note that, in some cases, the new classes represent (“wrap”) .Net generic type definitions (“open generic types,”) which means one cannot create instances of such types. To create instances, it is first necessary to construct a “closed generic type” by supplying a generic type argument that corresponds to each of the generic type parameters of the generic type definition. This version of the Essence# Standard Library also includes Essence# classes that do just that for the .Net classes Task`1 (“Task<>” using C# syntax), TaskCompletionSource`1 (“TaskCompletionSource<>” using C# syntax) and ThreadLocal`1 (“ThreadLocal<>” using C# syntax.) Those classes wrap generic types that are constructed by supplying System.Object as the generic type argument to the base generic type definition. They reside in the namespace Smalltalk.Multitasking, and are named Smalltalk.Multitasking.Task (which represents the .Net type Task<System.Object>), Smalltalk.Multitasking.TaskCompletionSource (which represents the .Net type TaskCompletionSource<System.Object>) and Smalltalk.Multitasking.ThreadLocal (which represents the .Net type ThreadLocal<System.Object>).

You should also know that an Essence# class that represents any closed generic type inherits from the Essence# class that represents the corresponding open generic type definition. So the class Smalltalk.Set–which represents the .Net type System.Collections.Generic.HashSet<Object>)–inherits from the Essence# class that represents the .Net type System.Collections.Generic.HashSet<>, and Smalltalk.Multitasking.Task inherits from the Essence# class that represents the .Net type System.Threading.Tasks.Task<> (using C# syntax for the type names.)

If you browse the Essence# code that implements the new classes, what you won’t see is an Essence# method that corresponds to every method and property of the corresponding .Net type. They are there nonetheless, and you can call them in spite of the fact that you don’t see the method definitions in the Essence# code. And that’s true of any and all Essence# classes that represent (“wrap”) a .Net type. If the .Net type represented by an Essence# class has a property or method named “Start,” you can invoke the method or get the value of the property by sending the message #start (or #Start, if you prefer) to an instance of the .Net type, even though there is no such method defined in the Essence# code.

Generally, a method will only be defined in Essence# code when the corresponding .Net method requires 2 or more parameters, or when the type has constructors that require any arguments. Normally, methods in Essence# code only need to be explicitly defined to access a .Net property, or to invoke a .Net method with less than 2 parameters, when it is desired to use a different name for the Essence# message than the one defined by .Net (perhaps because the message selector traditionally used in Smalltalk for the operation with the same semantics is different.)

However, if the class is a native Essence# class which does not “wrap” a .Net type, then almost all methods not inlined by the compiler (or not added dynamically by sending a message such as #addMethod: to the class) must be explicitly defined, with a very small number of exceptions (currently, those would be #doesNotUnderstand:, #ensure:, #ifCurtailed: and #on:do:). The compiler inlines many of the same messages as would be the case in other Smalltalk implementations.

You can print out a list of all the methods defined by an Essence# class (including those that come from traits, or are inherited from its superclasses) by using the ES command line program to run code on the command line (e.g, using the Windows CommandPrompt) such as the following, which will print out the names of all the methods of class Array:

Array allSelectorsDo: [:selector | System.Console writeLine: selector]

Example Of Thread Usage

The methods #newProcess, #newProcessAt:, #fork and #forkAt: have been added to class Block as an initial stab at giving blocks standard behavior with respect to threads (“processes.”) Here’s an example of using blocks to start threads, and of using CLR.System.Threading.Semaphore to schedule threads:

| semaphore|
semaphore := CLR.System.Threading.Semaphore new.

[semaphore wait. 
System.Console writeLine: 'Thread one reporting'] fork.

[System.Console writeLine: 'Thread two reporting'. 
semaphore signal] fork.

The #fork message creates a Thread from the block that is its receiver, and starts it running. The first thread immediately begins waiting on the semaphore.  The second thread writes out a message to the console, and then signals the semaphore, which causes the first thread to stop waiting on the semaphore and write out its own message to the console.

And that’s it for now. I’ll publish more posts over the next week that describe and explain the other new features and capabilities, such as calling .Net methods that require “out” or “ref” parameters.



Smalltalk Jobs - Smalltalk Jobs – 7/22/2014

Smalltalk position in Tours France with a contract company, Neo-Soft.

For this Smalltalk position they look for someone on Unix to make changes in Smalltalk and Java. In addition you need to understand COBOL and MVS.

More information in French here.

Filed under: Employment

Smalltalk Jobs - Smalltalk Jobs – 7/21/14

  • Atlanta, GASmalltalk Developer through Evolutyz
    • Required Skills:
      • 5+ years of Smalltalk Development experience
      • IBM Visual Age version 5.0+
      • Version Control using VisualAge – ENVY
      • SQL Server 2008
      • SDLC LifeCycle
      • Familiar with consuming Webservices from Smalltalk
    • Additional listings: VDart, VDart
  • Fremont, CASoftware Engineer 1 at Lam Research
    • Required Skills:
      • MS/BS in EE/CS or related fields
      • Working knowledge of object-oriented design methods and languages
      • Working knowledge of multi-threaded software
      • Basic knowledge of real-time operating system, hardware and software interface, real-time control, motion control
      • Basic knowledge of at least 1 communication protocol
    • Wanted Skills:
      • Smalltalk
      • Working knowledge of Visual Studio
      • Working knowledge of relational database (SQL server preferred)
  • Fremont, CASoftware Engineer 2 at Lam Research
    • Required Skills:
      • Must be proficient in C, C++, and Java
      • Must have used any of the following tools in academic projects tools: ClearQuest, ClearCase, SVN, CVS, GIT, Eclipse
      • Unix
      • Must be familiar with Multi Threading, Inter Process Communications, Memory Management
      • Code analysis using profilers and debuggers etc
    • Wanted Skills:
      • QNX or VxWorks
      • ControlWorks and/or Smalltalk
Good luck with your job hunting,
James T. Savidge

View James T. Savidge's profile on LinkedIn

This blog’s RSS Feed

Filed under: Employment

July 21, 2014

Cincom Smalltalk - Smalltalk Digest: July Edition

The July edition of The Cincom Smalltalk Digest is available now.

Cincom Smalltalk - Contributed Components

A new feature of our website is the Contributed Components Directory.

Pharo Weekly - SciSmalltalk new version

Dear all,

we are to happy to announce SciSmalltalk v0.12

SciSmalltalk is a new Smalltalk project, similar to existing
scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby.
SciSmalltalk already provide the following basic functionalities:

- complex and quaternions extensions,
- random number generators,
- fuzzy algorithms,
- LAPACK linear algebra package,
- Didier Besset's numerical methods,
- Ordinary Differential Equation (ODE) Solver).

Everything is available here:
All the code is available under the MIT licence.

We have more than 424 green unit tests and we run a CI job here:

This version should work on Pharo 2.0/3.0/4.0 and also Squeak 4.5 (to
be confirmed).

We are a small community, we are looking for more volunteers to
contribute code and documentation. Please join us at :!forum/scismalltalk


July 20, 2014

Pharo Weekly - Another week of changes

Another great list of changes and improvements in Pharo.

13605 Slider can use setValueSelector instead of accessor everywhere

13603 remove extensions classOrMetaClass and messageName form Context

13598 MorphicModel ivar open: not used

13602 SmalltalkImage >> #openLog dependent on Tools

13601 Add in group DNU

13600 DiffereratorSettings –> move to TextDiffBuilder

13594 Reduce references to CodeHolder

13597 Implement #readsSlot and #writesSlot on CompiledMethod (and tests)

13595 PluggableSystemWindow is dead code

13596 remove package TT.cs

13592 Small RB Tests cleanup

13589 deprecated TimeStamp

13590 TimeStamp has still instances

13591 unload tests Metacello-TestsTutorial


13576 Small code critique cleanup Graphics-Primitives

13587 add tests to make sure globals and class vars use the right bindings

13580 move UnixEnvironment and Win32Environment to NativeBoost


13574 ModelOrNil has only one sender so we should rewrite it and remove it.

13578 safer RPackageOrganizer>>systemMethodRemovedActionFrom:

13585 use term Class Variable, not Shared Variablem in ClassModification

13584 Forward code generation for Globals and Class Vars to meta object

13586 Class Variables should be ClassVariables, not Globals

13581 move ThreadSafeTranscriptPluggableTextMorph to own package named Tool-Transcript

13583 #senders and #implementors on Symbol

13579 MCPatchOperation >> #patchWrapper should be moved to package Polymorph-Tools-Diff

13582 Deprecated #classSymbol

13552 First Class Variables: improve reflective API, ClassBuilder use objects, not string for Globals

13275 RBSmalllintChecker checks classes not defined in environment

13577 UIManager should not use WorldState for defer:

13575 TreeModel in checklist mode gives unchecked items hardcoded color

13571 Something is completely broken regarding Slice submission

13558 PluggableTextFieldMorph should be packaged in PluggableTextMorph

12879 Rename and Recategorize RPackage>>#correspondingMcPackage

13572 little clean of SimpleSwitchMorph and comment

13515 GrafPort and EllipseMidpointTracer should not be in Morphic package

13563 Fix sender of deprecated RPackageOrganizer>>#renamePackage:in: method

6765 Refactoring Extract into Temporary should modify all duplicates

13565 extensions of Polymorph on Polymorph class should be folded in these classes

5618 Refactoring: Cannot permutate arguments

13540 Debugger: method refactoring option

13569 Small Code critique cleanup of MonticelloGUI

13567 Small code critique clean Polymorph

12205 Cleanup gofer>>#directory:

13125 The Find&Replace dialog does not honor the Appearance font size setting

11287 Form class>>fromUserWithExtent: freezes because Rectangle class>>originFromUser:grid: is broken.

13550 Should remove the 30 inbox from pharo 40alpha

13564 Fix all users of TimeStamp: remove Tests, change two remaining clients

13562 remove UUIDGeneration seed generation from sound input

13561 remove some unload class methods

13560 remove DSA seed generation from sound input

13555 IconicListItem should be packaged in Widgets-Basic

13556 ImagePreviewMorph could be packaged close to AlphaImageMorph

13559 ControlButtonMorph and PluggableButtonMorph could be moved to Widgets-Base

13557 Github zip download does not check for the existence of file with the same name

13551 Not all SmartSugs works in Debugger

12790 AthensSurfaceExamples class side examples do not work due to subclassResponsibility

13538 RowScrollerMorph us unused and undocumented


Essence# - Appe’s New ‘Playgrounds’: Back To The Future, One More Time

So Wired thinks Apple’s Playgrounds development paradigm is revolutionary?

Not so much: Smalltalk programmers have been coding with analogous capabilities since before Steve Jobs ever saw his now famous demo at Xerox PARC.

The Smalltalk development environment now has close to 40 years of maturity and experience behind it. And its cool features from 1979 still haven’t all been added to the IDEs of other languages, to say nothing of the ones added since then.


July 18, 2014

Nicolas Petton - Farewell RMoD!

Today is my last day at RMoD.

The last two years have been an incredibly rich experience, and I’m profoundly sad to leave my colleagues. I have in the past two years met and worked with a lot of very smart people and many of them became very close friends. I’m still saying goodbye to people, so I’ll make this post short. :)

The first thing that comes to my mind when I think about the last two years is that I’m very proud of having been part of RMoD. It hasn’t always been easy, but it has been all in all a very joyful experience.

I will of course stay around, and come back to visit the team around February next year.

In two weeks I’ll be packing my stuff to go to Stockholm, where I will be working in another development team. It’s a totally new adventure that will begin, so stay tuned!