Planet Smalltalk

August 27, 2016

BioSmalltalk - A ShapeIt2 wrapper is available


One of the latest additions in BioSmalltalk is a wrapper for running the well-known ShapeIt2 software (actually is ShapeIt v2). ShapeIt is a fast and accurate method for estimation of haplotypes (a.k.a. phasing) from a set of SNP genotypes (.ped format or its .bed/.bim/.fam binary version) and a genetic map (.map format), and produces as output, either a single set of estimated haplotypes, or a haplotype graph that encapsulates the uncertainty about the underlying haplotypes. The software is currently only available in Unix-like OS.


To use the wrapper the program binary must be in the system PATH environment variable and all input files, being binarized PLINK (bed, bim, fam) or textual PLINK (ped, map) must share the same name. The following expression launches ShapeIt2 from BioSmalltalk, setting several parameters such as:
  • The number of burn-in MCMC iterations
  • The input file name (without extension),
  • The output file name for the best haplotypes
  • The number of threads to use the multi-threading capabilities

BioShapeIt2WrapperR727 new
burn: 10;
inputBinarized: 'input_brangus';
outputMax: 'output_brangus';
thread: 8;
If you like to explicitly specify

BioShapeIt2WrapperR644 new
burn: 10;
inputTextual: 'input_brangus.ped';
inputMap: '';
outputMax: 'output_brangus';
thread: 8;


Now the BioShapeIt2Wrapper is a superclass for specialized subclasses, each one representing a particular release of ShapeIt2. When I started the wrapper the binary executable of ShapeIt2 was named "shapeit.v2.r644.linux.x86_64", then I checked "shapeit.v2.r727.linux.x64" was released but cannot be run in CentOS 6.x. So you want to keep older version, and also know which binaries are available (it does not mean they are installed in your system of course):

BioShapeIt2Wrapper releases
"an OrderedCollection('shapeit.v2.r644.linux.x86_64' 'shapeit.v2.r727.linux.x64')"

August 26, 2016

Pharo Weekly - TaskIt v2 is out

Hi all,

With Santi we wanted to share a new release of TaskIt, a concurrency management library for Pharo. TaskIt development is done entirely in github, using iceberg. Works like a charm. Please find below attached the changes log with more information.

Guille & Santi

TaskIt is a library that ease Process usage in Pharo. It provides abstractions to execute and synchronize concurrent tasks, and several pre-built mechanisms that are useful for many application developers. This chapter explores starts by familiarizing the reader with TaskIt’s abstractions, guided by examples and code snippets. At the end, we discuss TaskIt extension points and possible customizations.
ChangesLog TaskIt v0.2

Major Features

Task Runners
Futures with callbacks
Future combinators
Future synchronous access


Travis CI

Minor changes log (from commits)

Enhanced class comments
TKTWorker processes are terminated in case the worker is collected. See Issues #8 and #5
Process Dashboard. – Adds TKTTaskItProcessProvider by default with the extension package – Hides job and task fields since there are not reachable any more.

Pharo Weekly - An amazing experience to learn

Gour asked in the mailing-list how he can access the Pharo bugs tracker.  He should log because we use a professional service nicely offered to us.

Now he asked the following question:

do you believe it makes sense for a noob to create account
in case there are some low-hanging fruits to pick?

And here is the answer Ben did. I fully fully agree. I learned and I’m still learning a lot from reading bug fixes.

Definitely.  And not necessarily that you *solve* an issues, but that
I found a benefit from "goal directed learning".
When I started using Pharo I learned a lot from:
* trying to reproduce issues - which also benefits core developers if
you can gather more complete symptom info
* testing other people's solutions - putting halts in the changed code
and simultaneously stepping through the original and solution code.
Actually I was surprised at far into the depths of the system this led
me sometimes and how accessible they were.  Look for issue marked
"Fixed - review needed"

cheers -ben


Benoit St-Jean - Julia

If you need to do some serious maths/statistics stuff or just number crunching, there’s plenty of tools out there.

Being a happy Smalltalker/Pharoer/VisualWorker/VisualAger/Dolphiner/Squeaker, my favorite library is PolyMath (previously known as SciSmalltalk).  Otherwise, I’m a big fan of R (mostly because of the huge amount of packages available).  Hey! That’s a long way from my nightmare days of SAS and SPSS!

Most complaints I hear about R is its inability to deal with large amounts of data and somewhat annoying syntax/style (I don’t get it!!!).

But there’s always Julia.  Give it a try!

Classé dans:Pharo, Smalltalk, statistiques Tagged: Julia, mathematics, Pharo, PolyMath, R, SciSmalltalk, Smalltalk, statistics

August 25, 2016

Göran Krampe - Benchmarking Spry vs Squeak

Spry is evolving quite nicely during my night hours. Focusing on performance is however still premature, but I do want to verify that I am not barking up the wrong tree, like ... in the wrong forest even. So I make trivial benchmarks from time to time, just to see and learn.

Some background on the Spry implementation may be interesting. Spry is implemented in Nim as a direct AST interpreter, it's not a JIT, in only about 2000 lines of code. It has a recursive classic "naive" design and uses a spaghetti stack of activation records, all allocated on the heap relying fully on Nim's GC to do it's work. It also relies on Nim's method dynamic dispatch in the interpreter loop for dispatching on the different AST nodes. Blocks are true closures and control structures like timesRepeat: are implemented as primitives, normally not cheating. Suffice to say, there are LOTS of things we can do to make Spry run faster!

The philosophy of implementation is to keep Spry very small and "shallow" which means we rely as much as possible on the shoulders of others. In this case, primarily Nim and it's superb features, performance and standard library.

Enough jibbering, let's do some silly damn lies - ehrm, I mean silly tests!

python | b r | b := OrderedCollection new. r := Random new. 2000000 timesRepeat: [b add: (r nextInt: 10)]. [b select: [:x | x > 8]] timeToRun

The above snippet runs in around 40 ms in latest Squeak 5.1. Nippy indeed! Ok, so in Spry then with a recently added primitive for select::

python b = [] 2000000 timesRepeat: [b add: (10 random)] [b select: [:x > 8]] timeToRun First of all, if this is the first Spry code you have seen, I hope you can tell it's Smalltalk-ish and it's even shorter. :) A few notes to make it clearer:

  • We don't declare local variable names in Spry.
  • Assignment uses = and equality uses ==, no big reason, just aligning slightly with other languages.
  • [] is the syntax for creating a Block (at parse time), which is the workhorse dynamic array (and code block), like an OrderedCollection.
  • Spry has no statement separators (!) so no . at the end, nor does it rely on line endings or indentation, same snippet can be written exactly the same on a single line.
  • You need (currently) a tad more parentheses in Spry code, for example we need (10 random) because Spry evaluates strictly from left to right.
  • Blocks don't declare variables either, they are "pulled in" using the syntax :foo. So blocks are often shorter than in Smalltalk like [:x > 8] or even [:a < :b].

Spry runs this in 1000 ms, not that shabby, but of course about 25x slower than Squeak. However... I think I can double the Spry speed and if so, then we are in "can live with that-country".

Just to prove Spry is just as dynamic and cool as Smalltalk (even more so actually in many parts), we can also implement select: in Spry itself (and for the more savvy out there, yes, detect: can also be implenented using the same non local return trick as Smalltalk uses):

```python spryselect: = method [:pred result = ([] clone) self reset [self end?] whileFalse: [

n = (self next)
do pred n then: [result add: n]]

^result] ```

Without explaining that code, how fast is the same test using this variant implemented in Spry itself? 8.8 seconds, not horrible, but... I think we prefer the primitive :)

Now... let's pretend this particular case is an important bottleneck in our 20 million dollar project. We just need to be faster! The Spry strategy is then to drop down to Nim and make a primitive that does everything in Nim. Such a 7-line primitive could look like this:

```nimrod nimMeth("selectLarger8"): # evalArgInfix(spry) pulls in the receiver on the left. # We convert it to the type we expect - SeqComposite is a super type # of Block, Paren, Curly. let self = SeqComposite(evalArgInfix(spry)) # We create a new empty Block to put the selected nodes in. let returnBlok = newBlok() # We perform a regular Nim iteration. self.nodes is a Nim seq[Node]. for each in self.nodes:

# For each element we convert to IntVal, which is the node type for a Spry int.
# This will cause a catchable exception if it's not an IntVal.
if IntVal(each).value > 8:

# A primitive always returns a Node or subclass thereof, like in this case a Blok. return returnBlok ``` Then it runs in 10 ms!

Yup, it's cheating, but the 20 million dollar project wouldn't care... The thing to realize here is that its MUCH easier to cheat in Spry than it is in Squeak/Pharo. But... yes, you would need to know how to make a primitive, and as a primitive it's compiled code so you can't mess with it live, and it also presumes that each node is an IntVal. However, Spry (when I fix error handling) should gracefully handle if it isn't an IntVal, that will trigger a Nim exception that the Spry interpreter should catch.

If you have made primitives in Squeak/Pharo you know it's much more complicated. You need to take great care with allocation since the GC can move things under your feet. You must convert things to C and so on, and building the stuff is messy. Spry on the other hand shares the underlying data structures with Nim. In other words, Spry nodes are Nim objects. It's trivial to work with them, allocate new ones like newBlok() above creates a new block and so on. This is a huge deal! Recently when I started integrating libui with Spry (a pretty slick movie) I got callbacks from libui back into Spry working in like... 30 minutes of thinking. That's HUGE! Doing callbacks from C or C++ back into Squeak has been a really messy and complicated thing for YEARS. Not sure if it's any better.

Also, going pure Nim would be much faster still since it would use a seq[int] and not a seq[Node] (boxed ints) - a vast difference. So if we really wanted to work with large blocks of integers, a special such node type could easily be made that exposes primitives for it. Kinda like the FloatArray thing in Squeak, etc.

String finding

Let's look at another example where Spry actually beats Squeak. And by beat I mean really beat, by factor 4x! The test is to use findString:startingAt: in a fairly large string, to find a match, 2 million times.

python | s time | "A file with a mixed text 15712 bytes, hit is at 11499, 6 partial hits before that." s := (StandardFileStream oldFileNamed: 'string.txt') contentsOfEntireFile. time := [2000000 timesRepeat: [ s findString: 'native threads and super high performance garbage' startingAt: 12 ]] timeToRun

This snippet runs in 135 seconds in Squeak 5.1. The corresponding Spry code is:


A file with a mixed text 15712 bytes, hit is at 11499, 6 partial hits before that.

s = readFile "string.txt" time = ([2000000 timesRepeat: [ s findString: "native threads and super high performance garbage" startingAt: 12 ]] timeToRun) `` Again, note how Smalltalkish the code looks - and ... you know, come on Smalltalk... reading a file? It shouldn't need to be(StandardFileStream oldFileNamed: 'string.txt') contentsOfEntireFile` for such a common and mundane task!

You gotta admit, readFile "string.txt" is nicer. But hey, says the careful reader, what the heck is that? Yes, Spry supports "prefix functions" that take arguments from the right, Rebol style. It isn't used much in Spry code, but for some things it really reads better. For example, in Spry we do echo "hey" instead of Transcript show: 'hey'. That's another thing that is overly verbose in Smalltalk and should IMHO be fixed, at least just to save poor newbies their fingers. Anyway (end of rant)....

...Spry runs that in 33 seconds! And just to get a sense for how large the primitive is in Spry, it's exactly 5 lines of code: nimrod nimMeth("findString:startingAt:"): let self = StringVal(evalArgInfix(spry)).value let sub = StringVal(evalArg(spry)).value let start = IntVal(evalArg(spry)).value newValue(find(self, sub, start))

It's quite easy to follow. We just pull in arguments and unbox them into Nim string, int, int - and then we call Nim's find and we finish by using newValue() to box the answer as a Spry IntVal again. This shows how easily - no... trivially we can map Spry behaviors to Nim library code which runs at the speed of C/C++.

Speeding up Spry

Given all this, it would still be nice to improve Spry to come say ... within 10x of Cog for general code, perhaps in this case shave it down from 1000 ms to around 300 ms. The things that I do know I should do to improve speed in general are the following:

  • Formalize binding phase in Spry. This means caching the binding of words "in place", especially words resolving to funcs and methods. This would eliminate a HUGE amount of idiotic lookups that Spry currently performs every time it runs a block or function and profiles have already shown that this is priority UNO to fix since it alone usually eats 50% of runtime.
  • Move to a stackless design of the interpreter. Exactly what performance improvement this would give, I am not sure. But it would remove the growing intertwined C stack and enable things like Spry stack manipulations, continuations, coroutines etc, so we really want it!
  • Profile the interpreter to see what low hanging fruit exists after the above. :)

I hope this got you interested in Spry!

Pharo Weekly - Custom GTDebugger for Seaside

As presented at ESUG on Monday, we now have a custom GTDebugger for Seaside. This was built by Andrei as an initial experiment.
As we do not know much about Seaside-specific debugging problems, we asked a couple of Seaside users to describe issues that would be useful to be addressed in the debugger, and Andrei allocated some 4h to construct some of these in an custom debugger for Seaside.
Two of the issues that popped up are:
– get a quick view of the current request context
– get an overview of the current component nesting
They are now addressed like depicted in the screenshot below.seaside-debugger.png
You should look at this debugger as a beginning. Beside the current basic extensions one added value is that we now have the scaffolding to build more. Please take a look at it and let’s try to identify more concrete issues that might be addressed. It would be great if this would be taken over by the Seaside community.
The debugger can be loaded on top of a Pharo 6.0 with Seaside inside like this:
Gofer new
    smalltalkhubUser: ‘Moose’ project: ‘GToolkit’;
    package: ‘GT-SeasideDebugger’;
#GTSeasideDebugger asClass register

Eliot Miranda - We are very happy to make the following announcement

Hi, We are very happy to make the following announcement: Lam Research, a leading supplier of wafer fabrication equipment and services to the global semiconductor industry, is an experienced user of the Smalltalk programming language. Smalltalk is a key component in Lam’s software control system for a broad range of the equipment it manufactures. Tudor […]

Pharo Weekly - More Enhancements

18980 QA v3.2.5

18903 CriticBrowser browser senders broken

18970 Add missing class comments for some RBToken classes
18936 RBParser allows pragmas after method code

18829 Add a RefactoringFramework System HelpTopic

18955 DoubleLinkedList and its test should be in its own package

18967 wrong title for “add trait” dialog

18954 ClassTest>>#testMethodsReferencingClass and testMethodsReferencingClasses should not use external packages

18975 copy sort –> sorted

18976 SmallDictionary>>#associationAt:ifPresent: is not implemented

18972 Group browse scoped class sync

18964 support for <sampleInstance>
18957 Class copy should not change the name of the instance variables

18434 Metacello-ProfSef classes sends wrong methods

18959 Create a class with a not existing trait does not suggest to create a new trait

18969 RBParser gets stuck in an endless loop if literal array contains an error
18158 MessageSend should not care about obsolete classes
18953 remove Regex dependency from SplitJoinTest>>#testSplitJoinBoundaryCases

18916 simplify asSlotCollection for bootstrap

18938 Remove RBClassInstVarNotInitializedRule, it is a bad rule
18949 reduce direct references to OpalCompiler

18951 Add helper methods to get all assignment nodes of a slot

18952 adopt some extensions of AST-Core from Reflectivity
18944 misspackaged Intege r>> readFrom: radix:

18945 do not require a Text in MockSourceEditor

18937 RBRefactoryTestDataApp and RBSmallintTestObject #fileBlocks sends undefined #asFilename

18940 simplify deferFlushDuring:

18942 workaround: fix adding ivars to classes with class vars

18939 New critic for catching redundant periods after statements
18917 simplify trait name validation for bootstrap

18941 ClassBuilderWarning should not override defaultAction

18602 Dependency-Analyzer v1.19

18925 cleanup InMidstOfFileinNotification

16789 RBUnaryAccessingMethodWithoutReturnRule refers to #nodes instead of #statements

18894 RBPatternParser should respect RBErrorNode when parsing pattern blocks II

18928 ambigous isArray for RBArrayNode

18914 Improve MethodClassifier classification based on selector parts

18888 Move Pharo bootstrap rule to Renraku model

18910 MNU: OrderedCollection>>parent: when trying to rewrite a tree with RBParseTreeRewriter

18911 unify property API of CompiledMethod with all the others (Class, AST…)

18912 update comment Deprecation

18907 Prevent LanguageEnvironment sublclasses to be in startup list

18906 SessionManager default should store the new instance when no default defined

18908 Prevent Symbol subclasses to be in startup list

18909 Monkey broken because System-CommandLine-TextSupport unloaded in 60164

18866 Rename protocol window title is ambiguous

18897 Monkey crashing with MessageNotUnderstood: VTermOutputDriver>>color256:
18891 MethodFinderTest>>#testGreaterThanANumber is dependent on order

18889 CriticsBrowser “BlockCannotReturn”

18896 add support for ignored fields in structures

18898 Sista Encoder update for release.
18890 Parser cant not parse faulty or unfinished blocks with return caret

18893 MCStWriterTest>>#expectedClassMethodDefinition will always fail on bootstrapped image

18892 simplify isBlockReturn: to use encoder

18887 QA 3.2.4

18878 MNU ReINvocationSequenceRule isArchitecturalRule

18886 parsing an unfinished block with invalid expressions in its body should not create only a single parse error node

18883 SystemReporter calls deprecated #name on MCWorkingCopy
18875 RBRemoveClassRefactoring applicable despite showing a warning

18793 Add CTGrid

18876 Rename BinaryFileStream >> setAtEnd -> setToEnd

18816 Failing test: ChangesBrowserTest.testInitializeWidgets

18846 <script:> and <script> pragmas do not always work

18782 Add DateAndTime class>>readFrom:defaultOffset:

18870 Delivery preparation hook for announcement

18861 TaskbarMorph reports damage outside its own area

18868 Announcements subscription should supports exclusion like exceptions by minus

18867 MetaceloPackageSpec workingCopyNameFor call name which could lead to deprecation warning when current version is array

18865 can not open critics browser on a package from nautilus package pane menu

18856 After Epicea integration: “an OmReference(Pharo_2elhj7i:199) not found in OmSessionStore”

17710 rename variable do not update class template

18855 reduce calls on #compiledMethod in RGMethodDefinition

18860 cleanup after running RGMethodDefintionTest

18858 #testUndeclared fails: missing ivars in RadioButtonModel

18821 format code creates invalid pragma statement

18843 #digitLength is implemented in SmallInteger and in BigInteger but not in Integer

18763 Update CriticBrowser to the latest Renraku changes

18781 Do it in File Browser text pane yields MNU: RubTextEditor>>doIt

18857 #hasSpecialSelector:ifTrueSetByte: can be removed
18854 Unload System-CommandLine-TextSupport

18831 Integrate new Epicea version

18768 Inlined method const could be implemented by metalinks

18835 Update RBParser-Nodes class comments

18836 Second cleaning of Spec-Polywidgets and adding test

18845 Move MIMEHeaderValue from Mail to MIME package

18749 QA v3.2.1
18749 QA v3.2.1

18845 Move MIMEHeaderValue from Mail to MIME package

18840 Cleaning of Spec-example, adding their tests

18848 Traits do not show up when using sendersOfIt

18802 Versionner puts a MCLazyVersionInfo(package name) instead of the package name

18844 Move String>>#join: to correct protocol

18838 ScrollSyncExample seems dont really work

18769 Add test for Spec-Core-Widgets

18841 Margin improvements

August 24, 2016

Pharo Weekly - Updated OpenCL bindings


I have just finished updating the OpenCL bindings and the VirtualGPU to use the UnifiedFFI in Pharo 5. All of the examples have been tested in Mac OS X El Capitan 10.11.6.
Best regards,
P.S: Do not confuse the VirtualGPU with the AbstractGPU. The AbstractGPU is an abstraction layer above Vulkan, Direct3D 12 and Metal. The AbstractGPU is used as the foundation for Woden 2.

Torsten Bergmann - ESUG 2016 - First slides

First slides of ESUG 2016 are available on Slideshare.

Later all the slides, videos and all will be archived on

Pharo Weekly - Windows Installer

PhyloclassTalk includes a Windows Installer written in Unicode NSIS.
It has two generators for this: A code generator written in Pharo to generate the NSIS script, and an image builder batch script which downloads image from ZeroConf, loads everything through Metacello, and launches NSIS to generate the executable file.

Hernan Morales

August 22, 2016

Torsten Bergmann - ESUG 2016, 13th Innovation Technology Awards - Kit

Kit (Programming for the rest of us) is one of the candidates for the ESUG Technology Awards

Torsten Bergmann - ESUG 2016, 13th Innovation Technology Awards - Educational Bureau

Educational Bureau (using Phratch based on Pharo) is one of the candidates for the ESUG Technology Awards. Video is here.

Torsten Bergmann - ESUG 2016, 13th Innovation Technology Awards - Woden 2 Game System

Woden 2 Game System is one of the candidates for the ESUG Technology Awards

Pharo News - [ANN] Agile Visualisation Book released

<p>Alexandre writes:</p> <p>&quot; It is a great pleasure to announce the release of Agile Visualization. Agile Visualization is a book about the Roassal Visualization engine.</p> <p>Paperback, eBook (PDF), and a free HTML format chapters are available from <a href=""></a> The book has 235 pages and covers the essential aspects of Roassal. Copies of the book will be sold at ESUG’16. Screenshots and codes contained in the book were produced on Pharo. However, most of the covered code and topics _equally_run on VisualWorks (from version 7.4 (!)).</p> <p>We would like to thank all the contributors and users of Roassal who have deeply impacted and shaped Agile Visualization. The book is dedicated to the Smalltalk community at large. Big big thanks to our sponsors, Lam Research, Object Profile, and ESUG. </p>

August 21, 2016

Cincom Smalltalk - Follow Along with #ESUG16 Updates from Twitter

Last year, we followed along with attendees at the European Smalltalk User Group Conference through Twitter, providing live updates from folks attending the conference and posting things on Twitter. We […]

The post Follow Along with #ESUG16 Updates from Twitter appeared first on Cincom Smalltalk.

August 19, 2016

Torsten Bergmann - Cuis now runs on Spur!

Additionally to Squeak and Pharo now also Cuis Smalltalk runs on the faster Spur version of the virtual machine. Nice!

August 18, 2016

Pharo Weekly - Examples and Examplar methods now reconciled!

Hi all

I implemented the <examplar> to behave as suggested by Torsten in thread more than a year ago if I got it correctly and it is available in less than 5 min (I loved it). An examplar is JUST a class method returning an instance. For example🙂, here I just define a class method returning a grid object.

CTGrid class >> grid22
“self grid22”
| grid1 |
grid1 := self new: 2.
grid1 atRow: 1 atColumn: 1 put: 1.
grid1 atRow: 1 atColumn: 2 put: 3.
grid1 atRow: 2 atColumn: 1 put: 2.
grid1 atRow: 2 atColumn: 2 put: 4.
^ grid1

You can use this method as any class method in the past. NOTHING new!!
So in particular your test can use it to build a fixture (yes reuse). You can use this method in several test cases (yes reuse).

Now nautilus supports nicely <examplar> methods: you can execute them and get a cool GTInspector open on them. So this is similar to the method exampleSomething pattern from Nautilus point of view.

And now people can use exampleSomething to create/open/display… their lovely examples (that may not return instances) – no stress you have the example you always liked (me too). And we get examplar methods that must return an instance but can behave as example from Nautilus perspective. So a nice win/win:

Better documentation of classes, better code reuse, nice integration and dead simple implementation: One class, 3 methods, no more  :)

If you want to try

If you want to try you can load the CTGrid packages.

ScriptLoader new unloadPackageNamed: ‘Collections-Grid’.
ScriptLoader new unloadPackageNamed: ‘Collections-Grid-Tests’.
“Because there were not good and will be removed from the image”
Gofer it
url: ‘;;
configurationOf: ‘Grid’;

Click on class side of CTGrid and press the triangle and yes you get an inspector on this instance.


Smalltalk Jobs - Smalltalk Jobs – 8/18/16

There is a Smalltalk/Java job in the auto industry near Ingolstadt.  You need:

  • Smalltalk, Java, and SQL.
  • XML
  • REST interfaces
  • Either freelance or permanent.
  • Experience in the auto sector and with large customers.


Filed under: Employment