Planet Smalltalk

February 18, 2017

Pharo Weekly - SHA256/512 Password Hashing for Pharo 5

Hi all,

I’ve updated my SHA256/512 password hashing library from NativeBoost to the
Pharo 5 FFI, added an authentication database that uses in-image persistence
and a very simple user interface written in Spec.

Blog post:


Pierce Ng - Logging libraries for Pharo 5

Below are the logging libraries that I've found for Pharo/Squeak:

  • Log4s
  • Nagare
  • OsmoSyslog
  • Syslog
  • SystemLogger
  • Toothpick

Log4s for Pharo is a port of the VA Smalltalk port of the popular Java logging framework Log4j. I installed it from Pharo 5's catalog browser. 206 of 207 tests passed, with 1 failure. None of the classes is commented, although being a port of Log4j, the Java documentation should work as reference.

Nagare is a "flexible logger which connects to Fluentd." It was written to run on VisualWorks, Squeak and Pharo. I installed it from the catalog browser. None of the classes is commented. No test suite. Documentation remains on the Google Code project wiki.

OsmoSyslog is a "log backend/target to use system syslog." AGPLv3+. I stopped there.

Syslog is an RFC5452 Syslog UDP client. I installed it using a Gofer snippet. It loads OSProcess. Every class has a class comment. Test suite has four tests. Because I have OSSubprocess in the same image I did not attempt to run the tests.

SystemLogger "is an easy to use, very lightweight, and highly configurable object logging framework." It failed to install from the catalog browser but loaded successfully using a Gofer snippet. Every class has a class comment. 17 of 19 tests passed, with 2 failures.

Toothpick is a port to Pharo of the Smalltalk library written to run on Dolphin, Squeak, VisualAge and VisualWorks. Documentation on the original site looks good. 16 of 19 tests passed, with 1 failure and 2 errors.

Pharo Weekly - Constant enhancements

19715 FastTableModel: Cant enable multiple selection

19211 sometimes I can not open changesort: receiver of endswith is nil

19718 Give Random an option to initialize its seed from /dev/random
19708 When test took too much time while forked processes was failed then TestFailedByForkedProcesses should be signalled

19714 Force migration of instances of EphemeronLayout and ImmediateLayout
19010 ImmediateLayout and EphemeronLayout have wrong object format

19710 Monticello should ignore the class definition of Context

19711 RPackage should not strongly depend on Monticello

19709 add example ComputedSlot

19707 remove Object>>#name hack in the BaselineOfIDE

19706 remove MBConfigurationInfoTest>>#testInitialization

19704 [Memory leak] Clipboard can produce memory leaks
19703 add empty ShortRunArray to Deprecated60
19698 Scoped button with a more meaningful tooltip

18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions

19183 ZnLogEvent open is broken

19701 Watchpoint should not ask for name

19700 testTimeStamp should not use hardcoded timestamp

19699 testProtocol should not test timestamp
19695 UUID>>#readHexFrom: accidentally overwrites an inherited method

19510 Nautilus Hierarchy view of superclasses does not show all the superclasses

19693 GTEventRecorder should be documented

19696 Debug world menu still use “Workspace” but open a playgound.
19689 Add method comments to cool block messages

19687 Improve UUID documentation, implementation and test coverage

19691 TabMorph background building animation should be in more priority than building process

19690 Help on Help includes examples that are not executable
18778 FileList “View as” does not work

19670 The tree widget for FastTable jumps to the selected element when expanding or collapsing a node

19630 Epicea Lost Changes Detector: MNU OmNullReference>>globalName

19674 Remove UUIDGenerator and rename NeoUUIDGenerator to UUIDGenerator

19681 #signalerContext should use #method, not #methodNode

19312 haltIf: should use recursionstopper

18722 GlobalIdentifier used for system settings persistence

19659 Tooltips of the class button does not changed
19677 Cannot parallel trace through same method

FileExists error in certain cases due to Epiciea vs new UUID

19673 Use NeoUUIDGenerator for UUID generation

19672 Cleanup some (Neo)UUIDGenerator dependencies
19680 DNU bug in SLICE 18901

19679 STON Update Feb 2017

19678 Zn Update Feb 2017

19671 The button “Class” stays blue until the cursor leaves it when switching to instance side view

19664 Removing a package with extensions let the extensions in the system and break their reload
19661 When coding in the debugger I get an error sourceNodeExecuted
18271 BaselineOfFileTree is in the old version

18837 RBParser should not crash when parsing a faulty method node

19655 Handle events during progressBar usage

18783 FileList: selected directory is changed after selecting a different folder

18699 MessageBrowser>>#wrapItem: may send #name to nil, raising Deprecated

This version addresses some bug fixes and synchronises those packages integrated using slices with the GToolkit repos. Changes:

– case 19575
– case 19646
– case 19604
– case 19542
– case 19260
– case 19454
– FastTable/List/Tree presentations can set rowHeight.
– Set to the Source presentation of a Context object doItReceiver and doItContext.
19651 showing a progress dialog each time I want to make an expandAll is incorrect
13159 ListDialogWindow – Grow Width to Fit List

19620 Unload Tool-TxWorkspace
18232 Breakpoints cannot be toggled in Nautilus method pane

19641 CantFindOriginError when Source file is missing on Windows

19632 TabMorph should defer only notification about ready morph
19635 DisplayScreen has depth 1 on Linux
19635 DisplayScreen has depth 1 on Linux

19634 WriteBarrier mirror methods should be moved to MirrorPrimitives
17352 DisplayScreen should have a class initialization method

19544 Better method comment for RubEditingMode>>interactive

19614 Better names for NoModificationError and friends

18767 Remove external dependencies from Collection-Tests

19325 Warning: dependency declared not detected as a dependency

19624 Wrong deprecated message in ifEmpty:ifNotEmptyDo:

19625 Catalog: loaded config should not be displayed with white icon

19129 Deprecation: The method Object>>name called from ClassHierarchyTest>>#testSubclasses has been deprecated.

Pierce Ng - SHA256/512 Password Hashing for Pharo 5

I've updated my SHA256/512 password hashing library to Pharo 5's FFI and moved it from SS3 to GH.

In the GH repo, C source files are in the src-c directory. Compile with the Makefile there. Move the .so or .dylib file to where the VM can find it.

To load the Smalltalk code, in a Pharo playground:

Metacello new 
  baseline: 'PasswordCrypt'; 
  repository: 'github://PierceNg/PasswordCrypt/src-st'; 

Run the tests in TestRunner. Provided the Pharo VM can find the shared library, all 12 tests should pass.

This version adds an authentication database that uses in-image persistence, accessed programmatically via the PCAuthenticator uniqueInstance, and a very simple user interface invoked thusly:

PCAuthenticatorUI new openWithSpec

Currently PCAuthenticator hardcodes to SHA256. It should be straightforward to make the hashing algorithm pluggable, including from other shared libraries. Hosting on GH makes it easier for forks and PRs.

February 17, 2017

Cincom Smalltalk - Final Voting to Take Place for the Red Hat International Women in Open Source Academic Awards 2017

After having completed two initial rounds, the final voting round is now open for the Red Hat International Women in Open Source Academic Awards 2017.  The final online voting round […]

The post Final Voting to Take Place for the Red Hat International Women in Open Source Academic Awards 2017 appeared first on Cincom Smalltalk.

Cincom Smalltalk - Smalltalk Digest: February Edition

Latest News and Updates New Year’s Resolution Leads to Interesting Outcome — Web Start-Up Bets on RSVP Event-Management Package A Worthwhile Cause — Cycle for Survival – Help Battle Cancer […]

The post Smalltalk Digest: February Edition appeared first on Cincom Smalltalk.

Pharo Weekly - Some cool libraries for Pharo

Pharo Weekly - Pharo papers

I was mildly curious about how many papers touched on Pharo.

1,110 on google scholar for…
“pharo” “programming”

1,630 on normal google for…
“pharo” “programming” “abstract” “introduction” “conclusion”
“references” filetype:pdf

Probably a lot of overlap between them.
cheers -ben

Benoit St-Jean - Google Fights

Who’s more referenced by Google?  Here’s the answer to this Google fight between Squeak and PharoGoogleFight anything you want! Quick, funny, and not serious at all!



Classé dans:Pharo, Smalltalk, Squeak Tagged: google, Google Fight, GoogleFight, Pharo, Smalltalk, Squeak

February 16, 2017

Torsten Bergmann - Blog post about Calypso navigation model

Blog post on Calypso navigation model. Calypso is a new system browser for Pharo.

Torsten Bergmann - Sensor Network

This is a demo for creating a spec with Roassal Pharo Smalltalk:

Torsten Bergmann - Pharo OpenPONK article

An article about OpenPONK (former DynaCase) tool found on Read more. The tool is written in Pharo.

Torsten Bergmann - Smalltalk from outer space

To quote Global Chief Technology Officer for Capgemini’s Insights & Data organisation, Ron Tolido:
Question: What is your favourite technology of all time?
Answer: That would have to be the MacBook Air; I’ve had quite a few by now and they still amaze me. In terms of programming languages, I still consider Smalltalk coming from outer space.

February 15, 2017

ESUG news - UK Smalltalk Meeting Feb 27

The next meeting of the UK Smalltalk User Group Meeting will be on Monday, February 27th.

We'll meet at our usual venue The Counting House at 7pm.

If you'd like to join us, you can just show up at the pub. You can also sign up in advance at the meeting's Meetup page.

Pharo News - Pharo Association: Join or Renew now!

<p> The new Pharo Association website is up and running for some month.  </p> <p> If you are a member, it will bug you once a year to renew. </p> <p> If you were a member in the past and have not been bugged by the system to renew until now, please subscribe now as a new member. </p> <p> (We added all active members, but as the old system was purely manual, people did not get asked to renew very consistently and you might not be in the system anymore) </p> <p> See the website for more information: </p> <p> <a href=""></a> </p>

Torsten Bergmann - Code Completion in Pharo

Lukas, a student at the Faculty of Information Technology of the Czech Technical University in Prague decided to make Code Completion in Pharo the topic of his Bachelor's degree and he will try to improve it. You can help him by filling out this survey. I personally would like to see templates in the code completion similar to what Eclipse provides.

February 14, 2017

UK Smalltalk - UK Smalltalk User Group Meeting - Monday, February 27th

The next meeting of the UK Smalltalk User Group will be on Monday, February 27th.

We'll meet at our usual venue, the Counting House, from 7pm onwards.

If you'd like to join us, you can show up at the pub. You can also sign up in advance on the meeting's Meetup page.

February 13, 2017

Torsten Bergmann - XML Magritte Generator for Pharo

Pharo Weekly - Consortium action 6 feb/12 feb


This is my weekly ChangeLog, from 6 February 2017 to 12 February 2017.
You can see it in a better format by going here:


9 February 2017:

* I finished the work started yesterday and now there is a [Pull Request](
enabling the use of SSH for iceberg

8 February 2017:

* I worked with Pablo on *iceberg*, in [issue 275]( (enable
use of ssh-agent). It is very important to provide an easy way to use the tool (otherwise you need to provide
your username/password, and there is people who do not like this).

After one afternoon of hard work, we now have an “almost” working version, as you can see
This thing in fact should be working, but there are still some UI missing stuff and it is not validated on
other platforms (linux and windows)… ut it ‘should’ work… we’ll see tomorrow

7 February 2017:

* I’m working on restore the testing of VM builds, and so far linux tests are passing. There are some problems
in macOS (probably due to missing chunks when performing the merge), and windows is still not tested at all.

So, I will work tomorrow on those to see if we can have finished the process this week: I need to have a stable
VM to continue with iceberg development (users will need to have a new VM, so better to have it tested :P)

6 February 2017:

* Working a bit on VM, I integrated a [pull request]( that
will enhance the build process in linux platforms.

This was submited by [Holger](, and is part of his work to create VM package versions.


Benoit St-Jean - Gnochon : c’est parti!


Gnochon sur Squeak 5.1 (32bit)

1-Mise à jour

Gnochon, c’est parti!  Déjà quelques leçons d’apprises!

1-Quand tu pars de rien, sans t’inspirer d’aucun code source des autres, c’est long et compliqué!  Tout est à faire et à penser.
2-Les pions vont causer 99% de tes problèmes.  Les pions sont tes ennemis!
3-La vie d’un développeur est plus compliquée quand tu désires supporter deux environnements, Squeak et Pharo.


Gnochon sur Pharo 5.0

2-Le premier adversaire


Dès que Gnochon sera en mesure de jouer une partie complète, j’ai décidé que le premier programme qu’il affronterait serait Chess, disponible sur SqueakSource et qui tourne sur Squeak!  Le projet est situé ici.  Ce programme tourne à environ 50000 NPS (nodes per second) sur mon ordinateur.  Évidemment, pour le battre je devrai être plus rapide!


Finalement, pour rester dans le thème des échecs, j’ai découvert Lozza, un jeu d’échecs en ligne. Une petite merveille simple et efficace d’un programmeur nommé Colin Jenkins. Il permet même d’analyser des positions à partir de chaînes FEN.  Et pour les curieux, la position sur l’échiquier est un problème de mat en 13!  Essayez-vous : c’est beaucoup plus facile que c’en a l’air!


Lozza. Les blancs jouent et matent en 13 coups!

Classé dans:échecs, échecs, chess, Chess, Gnochon, informatique, jeux, Pharo, programmation, Smalltalk, Squeak Tagged: échecs, Chess, Colin Jenkins, FEN, Gnochon, Lozza, nodes per second, noeuds par seconde, Notation Forsyth-Edwards, NPS, Pharo, Squeak, Squeaksource

February 12, 2017

Pharo Weekly - Inspector performance improvement


Andrei and Alex did a great job at improving the performance and scalability of the inspector.

There are a couple of main improvements:
– Added FastTable support for the Raw presentation for all objects. This implied completing the support for the tree presentation binding to fast table.
– Moved the Items presentation for collections to FastTable.
– Improved the rendering of Glamour to no longer rely on the default Morph>>#adoptPaneColor. It turns out that using adoptPaneColor triggers a relayout of the morph, even if it is not visible. We extended PanelMorph in the context of Glamour with a less needy logic.

I will not tell you how fast it is. I would rather want you to play with it :).

The change is already in the Moose image. It is not yet in Pharo, but it will be soon. In the meantime you can be load it in Pharo 6 like this:

Gofer new
smalltalkhubUser: ‘Moose’ project: ‘GToolkit’;
package: ‘ConfigurationOfGToolkitCore’;
(#ConfigurationOfGToolkitCore asClass project version: #stable) load

To play with it, try this with both the current version and the new one and the Spec Inspector if you want (just make sure you save the image beforehand):

collection := (1 to: 100000000) asArray.
[collection inspect] timeToRun.

collection := (1 to: 100000000).
[collection inspect] timeToRun.

(for these two ones notice that Items do not appear at all in the old implementation)

[World inspect] timeToRun.

There are still a couple of issues open, such as the sorting of the columns. We would need your help with testing this, and report possible missing issues.


“Obvious things are difficult to teach.”

February 11, 2017

Smalltalk Jobs - Smalltalk Jobs – 2/11/17

  • Buenos Aires, ArgentinaKapital Financial Developer – Associate (Job ID 160128692) at J.P. Morgan
    • Required Skills:
      • The candidate should have an understanding of an object oriented programming language (e.g. Java, C++, C#, Smalltalk) and their underlying principles
      • Data modelling
      • Code version control
      • Understanding of coding optimizations
      • Enthusiasm for increasing knowledge of financial markets and products
      • Willingness to adopt and contribute to an agile development process
    • Wanted Skills:
      • Smalltalk
  • Miami, FLSr. SmallTalk Developer through Cognizant
    • Required Skills:
      • 6+ Years of IT Experience
      • Strong hands-on experience with VisualWorks 7.9 Smalltalk development
      • Should have excellent knowledge on the OOPS Concepts.
      • Should work independently in SmallTalk technology
      • Experience in Onsite / offshore model
    • Wanted Skills:
      • Experience in .Net technologies.
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

February 10, 2017

Benoit St-Jean - 1001001 SOS


I’ve been dealing a lot with bit operations lately.  And doing lots of benchmarking, like here. As I was looking for a bit count method in Pharo (it used to be there but it no longer exists in Pharo 5.0), I got curious about the many different versions of bit counting algorithms I could find on the internet.

What’s so special about bit operations you ask?  Not much.  Except when you have to do it really fast on 64bit integers!  Like in a chess program!  Millions of times per position. So instead of copying the #bitCount method that was in Squeak, I decided I’d have a look at what is available on the net…

So I decided to share what I found.  This could potentially be useful for people who have to deal with bit counting a lot. Especially if you deal with 14 bits or less!

Here’s a typical run of the different bit counting algorithms I have tested on Squeak 5.1 64bit.

Number of [myBitCount1 (128 bits)] per second: 0.061M
Number of [myBitCount1 (14 bits)] per second: 1.417M
Number of [myBitCount1 (16 bits)] per second: 1.271M
Number of [myBitCount1 (30 bits)] per second: 0.698M
Number of [myBitCount1 (32 bits)] per second: 0.651M
Number of [myBitCount1 (60 bits)] per second: 0.362M
Number of [myBitCount1 (64 bits)] per second: 0.131M
Number of [myBitCount1 (8 bits)] per second: 2.255M
Number of [myBitCount2 (128 bits)] per second: 0.286M
Number of [myBitCount2 (14 bits)] per second: 3.623M
Number of [myBitCount2 (16 bits)] per second: 3.630M
Number of [myBitCount2 (30 bits)] per second: 2.320M
Number of [myBitCount2 (32 bits)] per second: 2.336M
Number of [myBitCount2 (60 bits)] per second: 1.415M
Number of [myBitCount2 (64 bits)] per second: 1.208M
Number of [myBitCount2 (8 bits)] per second: 4.950M
Number of [myBitCount3 (128 bits)] per second: 0.498M
Number of [myBitCount3 (14 bits)] per second: 4.556M
Number of [myBitCount3 (16 bits)] per second: 4.673M
Number of [myBitCount3 (30 bits)] per second: 3.401M
Number of [myBitCount3 (32 bits)] per second: 3.401M
Number of [myBitCount3 (60 bits)] per second: 2.130M
Number of [myBitCount3 (64 bits)] per second: 1.674M
Number of [myBitCount3 (8 bits)] per second: 4.938M
Number of [myBitCount4 (128 bits)] per second: 0.041M
Number of [myBitCount4 (14 bits)] per second: 5.333M
Number of [myBitCount4 (16 bits)] per second: 4.819M
Number of [myBitCount4 (30 bits)] per second: 2.841M
Number of [myBitCount4 (32 bits)] per second: 2.674M
Number of [myBitCount4 (60 bits)] per second: 1.499M
Number of [myBitCount4 (64 bits)] per second: 0.270M
Number of [myBitCount4 (8 bits)] per second: 7.435M
Number of [myBitCount5 (128 bits)] per second: 0.377M
Number of [myBitCount5 (14 bits)] per second: 3.937M
Number of [myBitCount5 (16 bits)] per second: 3.035M
Number of [myBitCount5 (30 bits)] per second: 2.137M
Number of [myBitCount5 (32 bits)] per second: 2.035M
Number of [myBitCount5 (60 bits)] per second: 1.386M
Number of [myBitCount5 (64 bits)] per second: 1.188M
Number of [myBitCount5 (8 bits)] per second: 4.167M
Number of [myBitCount6 (128 bits)] per second: 0.381M
Number of [myBitCount6 (14 bits)] per second: 5.195M
Number of [myBitCount6 (16 bits)] per second: 3.552M
Number of [myBitCount6 (30 bits)] per second: 2.488M
Number of [myBitCount6 (32 bits)] per second: 2.364M
Number of [myBitCount6 (60 bits)] per second: 1.555M
Number of [myBitCount6 (64 bits)] per second: 1.284M
Number of [myBitCount6 (8 bits)] per second: 5.571M
Number of [myPopCount14bit (14 bits)] per second: 18.349M
Number of [myPopCount14bit (8 bits)] per second: 18.519M
Number of [myPopCount24bit (14 bits)] per second: 7.407M
Number of [myPopCount24bit (16 bits)] per second: 7.463M
Number of [myPopCount24bit (8 bits)] per second: 7.018M
Number of [myPopCount32bit (14 bits)] per second: 4.963M
Number of [myPopCount32bit (16 bits)] per second: 5.013M
Number of [myPopCount32bit (30 bits)] per second: 4.608M
Number of [myPopCount32bit (32 bits)] per second: 4.619M
Number of [myPopCount32bit (8 bits)] per second: 4.608M
Number of [myPopCount64a (14 bits)] per second: 2.778M
Number of [myPopCount64a (16 bits)] per second: 2.793M
Number of [myPopCount64a (30 bits)] per second: 2.751M
Number of [myPopCount64a (32 bits)] per second: 2.703M
Number of [myPopCount64a (60 bits)] per second: 2.809M
Number of [myPopCount64a (64 bits)] per second: 1.385M
Number of [myPopCount64a (8 bits)] per second: 2.755M
Number of [myPopCount64b (14 bits)] per second: 3.063M
Number of [myPopCount64b (16 bits)] per second: 3.096M
Number of [myPopCount64b (30 bits)] per second: 3.106M
Number of [myPopCount64b (32 bits)] per second: 3.053M
Number of [myPopCount64b (60 bits)] per second: 3.008M
Number of [myPopCount64b (64 bits)] per second: 1.444M
Number of [myPopCount64b (8 bits)] per second: 3.091M
Number of [myPopCount64c (14 bits)] per second: 1.625M
Number of [myPopCount64c (16 bits)] per second: 1.600M
Number of [myPopCount64c (30 bits)] per second: 1.542M
Number of [myPopCount64c (32 bits)] per second: 1.529M
Number of [myPopCount64c (60 bits)] per second: 1.566M
Number of [myPopCount64c (64 bits)] per second: 1.082M
Number of [myPopCount64c (8 bits)] per second: 3.945M

Now, since method #myBitCount2 is similar to the #bitCount method in Squeak, that means there is still place for improvement as far as a faster #bitCount is needed.  Now the question is : do we optimize it for the usual usage (SmallInteger), for 64bit integer or we use an algorithm that performs relatively well in most cases?  Obviously, since I will always be working with 64bit positive integers, I have the luxury to pick a method that precisely works best in my specific case!

All test code I have used can be found here.

Note: Rush fans have probably noticed the reference in the title…

Classé dans:optimisation, performance, Pharo, programming, Smalltalk, Squeak Tagged: algorithms, bit count, bit counting, bit manipulation, bit operations, bitCount, integers, Pharo, Rush, Smalltalk, Squeak

Benoit St-Jean - Bits and Pieces

Often times, we take stuff for granted.  But while preparing to embark on a crazy project (description in French here and Google translation in English here), I wanted to benchmark the bit manipulation operations in both Squeak and Pharo, for the 32bit and 64bit images (I am on Windows so the 64bit VM is not available for testing yet but it’ll come!).  So essentially, it was just a test to compare the VM-Image-Environment combo!

To make a long story short, I was interested in testing the speed of 64bit operations on positive integers for my chess program. I quickly found some cases where LargePositiveInteger operations were more than 7-12 times slower than the SmallInteger equivalences and I became curious since it seemed like a lot.  After more testing and discussions (both offline and online), someone suggested that some LargePositiveInteger operations could possibly be slow because they were not inlined in the JIT.  It was then recommended that I override those methods in LargePositiveInteger (with primitives 34 to 37), thus shortcutting the default and slow methods in Integer (corresponding named primitives, primDigitBitAnd, primDigitBitOr, primDigitBitXorprimDigitBitShiftMagnitude in LargeIntegers module).  I immediately got a 2-3x speedup for LargePositiveInteger but…

Things have obviously changed in the Squeak 64bit image since some original methods (in class Integer) like #bitAnd: and #bitOr: are way faster than the overrides (in class LargePositiveInteger )!  Is it special code in the VM that checks for 32bit vs 64bit (more precisely, 30bit vs 60bit integers)?  Is it in the LargeIntegers module?

Here are 2 typical runs for Squeak 5.1 32bit (by the way, Pharo 32bit image performs similarly) and Squeak 5.1 64bit images  :

Squeak 5.1 32bit

Number of #allMask: per second: 7.637M
Number of #anyMask: per second: 8.333M
Number of #bitAnd: per second: 17.877M
Number of #bitAnd2: per second: 42.105M
Method #bitAnd2: seems to work properly! Overide of #bitAnd: in LargeInteger works!
Number of #bitAt: per second: 12.075M
Number of #bitAt:put: per second: 6.287M
Number of #bitClear: per second: 6.737M
Number of #bitInvert per second: 5.536M
Number of #bitOr: per second: 15.764M
Number of #bitOr2: per second: 34.409M
Method #bitOr2: seems to work properly! Overide of #bitOr: in LargeInteger works!
Method #bitShift2: (left & right shifts) seems to work properly! Overide of #bitShift: in LargeInteger works!
Number of #bitXor: per second: 15.385M
Number of #bitXor2: per second: 34.043M
Method #bitXor2: seems to work properly! Overide of #bitXor: in LargeInteger works!
Number of #highBit per second: 12.451M
Number of #<< per second: 6.517M 
Number of #bitLeftShift2: per second: 8.399M 
Number of #lowBit per second: 10.702M 
Number of #noMask: per second: 7.064M 
Number of #>> per second: 7.323M
Number of #bitRightShift2: per second: 29.358M

Squeak 5.1 64bit

Number of #allMask: per second: 36.782M
Number of #anyMask: per second: 41.026M
Number of #bitAnd: per second: 139.130M
Number of #bitAnd2: per second: 57.143M
Method #bitAnd2: seems to work properly! Overide of #bitAnd: in LargeInteger works!
Number of #bitAt: per second: 23.358M
Number of #bitAt:put: per second: 8.649M
Number of #bitClear: per second: 38.554M
Number of #bitInvert per second: 29.630M
Number of #bitOr: per second: 139.130M
Number of #bitOr2: per second: 58.182M
Method #bitOr2: seems to work properly! Overide of #bitOr: in LargeInteger works!
Method #bitShift2: (left & right shifts) seems to work properly! Overide of #bitShift: in LargeInteger works!
Number of #bitXor: per second: 55.172M
Number of #bitXor2: per second: 74.419M
Method #bitXor2: seems to work properly! Overide of #bitXor: in LargeInteger works!
Number of #highBit per second: 7.921M
Number of #<< per second: 10.127M 
Number of #bitLeftShift2: per second: 12.800M 
Number of #lowBit per second: 6.823M 
Number of #noMask: per second: 39.024M 
Number of #>> per second: 23.188M
Number of #bitRightShift2: per second: 56.140M

So now, I’m left with 2 questions :

  1. Why exactly does the override work (in 32bit images)?
  2. What changed so that things are different in Squeak 5.1 64bit image (overrides partially work)?

If you’re curious/interested, the code I have used to test is here.

Leave me a comment (or email) if you have an explanation!

To be continued…

Classé dans:Cog, informatique, Machine virtuelle, optimisation, performance, Pharo, programmation, programming, Smalltalk, Squeak, VM, Windows Tagged: #bitAnd:, #bitOr:, #bitShift:, #bitXor:, 32bit, 64bit, bit, bit manipulation, bit operations, image, integer, LargeIntegers, LargePositiveInteger, module, named primitive, primDigitBitAnd, primDigitBitOr, primDigitBitShiftMagnitude, primDigitBitXor, primitive, SmallInteger

February 09, 2017

The Weekly Squeak - Call for Papers – 10th ACM SIGPLAN International Conference on Software Language Engineering

**Call for Papers**
10th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2017)
23-24 October 2017, Vancouver, Canada
(Co-located with SPLASH 2017)
General chair:
   Benoit Combemale, University of Rennes 1, France
Program co-chairs:
   Marjan Mernik, University of Maribor, Slovenia
   Bernhard Rumpe, RWTH Aachen University, Germany
Artifact evaluation chairs
   Tanja Mayerhofer, TU Wien, Austria
   Laurence Tratt, King’s College London, UK
Follow us on twitter:
Software Language Engineering (SLE) is the application of systematic, disciplined, and measurable approaches to the development, use, deployment, and maintenance of software languages. The term “software language” is used broadly, and includes: general-purpose programming languages; domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and metamodeling languages (e.g. SysML and UML); data models and ontologies (e.g. XML-based and OWL-based languages and vocabularies).
### Important Dates
Fri 2 Jun 2017 – Abstract Submission
Fri 9 Jun 2017 – Paper Submission
Fri 4 Aug 2017 – Author Notification
Thu 10 Aug 2017 – Artifact Submission
Fri 1 Sep 2017 – Artifact Notification
Fri 8 Sep 2017 – Camera Ready Deadline
Sun 22 Oct – SLE workshops
Mon 23 Oct – Tue 24 Oct 2017 – SLE Conference
### Topics of Interest
SLE aims to be broad-minded and inclusive about relevance and scope. We solicit high-quality contributions in areas ranging from theoretical and conceptual contributions to tools, techniques, and frameworks in the domain of language engineering. Topics relevant to SLE cover generic aspects of software languages development rather than aspects of engineering a specific language. In particular, SLE is interested in principled engineering approaches and techniques in the following areas:
* Language Design and Implementation
   * Approaches and methodologies for language design
   * Static semantics (e.g., design rules, well-formedness constraints)
   * Techniques for behavioral / executable semantics
   * Generative approaches (incl. code synthesis, compilation)
   * Meta-languages, meta-tools, language workbenches
* Language Validation
   * Verification and formal methods for languages
   * Testing techniques for languages
   * Simulation techniques for languages
* Language Integration and Composition
   * Coordination of heterogeneous languages and tools
   * Mappings between languages (incl. transformation languages)
   * Traceability between languages
   * Deployment of languages to different platforms
* Language Maintenance
   * Software language reuse
   * Language evolution
   * Language families and variability
* Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance)
* Empirical evaluation and experience reports of language engineering tools
   * User studies evaluating usability
   * Performance benchmarks
   * Industrial applications
### Types of Submissions
* **Research papers**: These should report a substantial research contribution to SLE or successful application of SLE techniques or both. Full paper submissions must not exceed 12 pages including bibliography in ACM SIGPLAN conference style (
* **Tool papers**: Because of SLE’s interest in tools, we seek papers that present software tools related to the field of SLE. Selection criteria include originality of the tool, its innovative aspects, and relevance to SLE. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must provide a tool description of 4 pages including bibliography in ACM SIGPLAN conference style (, and a demonstration outline including screenshots of up to 6 pages. Tool demonstrations must have the keywords “Tool Demo” or “Tool Demonstration” in the title. The 4-page tool description will, if the demonstration is accepted, be published in the proceedings. The 6-page demonstration outline will be used by the program committee only for evaluating the submission.
* **Industrial papers**: These should describe real-world application scenarios of SLE in industry, explained in their context with an analysis of the challenges that were overcome and the lessons which the audience can learn from this experience. Industry paper submissions must not exceed 6 pages including bibliography in ACM SIGPLAN conference style (
* **New ideas / vision papers**: New ideas papers should describe new, non-conventional SLE research approaches that depart from standard practice. They are intended to describe well-defined research ideas that are at an early stage of investigation. Vision papers are intended to present new unifying theories about existing SLE research that can lead to the development of new technologies or approaches. New ideas / vision papers must not exceed 4 pages including bibliography in ACM SIGPLAN conference style (
### Artifact evaluation
Authors of accepted papers at SLE 2017 are encouraged to submit their experiment results used for underpinning research statements to an artifact evaluation process. This submission is voluntary and will not influence the final decision regarding the papers.
Papers that go through the Artifact Evaluation process successfully receive a seal of approval printed on the first page of the paper in the proceedings. Authors of papers with accepted artifacts are encouraged to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library.
### Publications
All submitted papers will be reviewed by at least three members of the program committee. All accepted papers, including tool papers, industrial papers and new ideas / vision papers will be published in ACM Digital Library.
Selected accepted papers will be invited to a special issue of the Computer Languages, Systems and Structures (COMLAN) journal.
### Awards
* **Distinguished paper**: Award for most notable paper, as determined by the PC chairs based on the recommendations of the program committee.
* **Distinguished reviewer**: Award for distinguished reviewer, as determined by the PC chairs using feedback from the authors.
* **Distinguished artifact**: Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee.
### Program Committee
Marjan Mernik (co-chair), University of Maribor, Slovenia
Bernhard Rumpe (co-chair), RWTH Aachen University, Germany
Mark van den Brand, TU Eindhoven, The Netherlands
Ruth Breu, University of Innsbruck, Austria
Jordi Cabot, ICREA, Spain
Walter Cazzola, University of Milan, Italy
Marsha Chechik, University of Toronto, Canada
Tony Clark, Middlesex University, UK
Tom Dinkelaker, Ericsson, Germany
Bernd Fischer, Stellenbosch University, South Africa
Sebastian Gerard, CEA, France
Jeff Gray, University of Alabama, USA
Esther Guerra, Autonomous University of Madrid, Spain
Michael Homer, Victoria University of Wellington, New Zealand
Ralf Lämmel, University of Koblenz-Landau, Germany
Tihamer Levendovszky, Microsoft, USA
Gunter Mussbacher, McGill University, Canada
Terence Parr, University of San Francisco, USA
Jaroslav Porubän, University of Košice, Slovakia
Jan Ringert, Tel Aviv University, Israel
Julia Rubin, University of British Columbia, Canada
Tony Sloane, Macquarie University, Australia
Eugene Syriani, University of Montreal, Canada
Emma Söderberg, Google, Denmark
Eric Van Wyk, University of Minnesota, USA
Jurgen Vinju, CWI, Netherlands
Eric Walkingshaw, Oregon State University, USA
Andreas Wortmann, RWTH Aachen University, Germany
Tian Zhang, Nanjing University, China
### Contact
For any question, please contact the organizers via email:

February 08, 2017

Eliot Miranda - Smalltalk, Scanning and S^HControl Structures

Here’s what I hope you’ll agree is a nice example of bytecode analysis and of creating custom control structures in Smalltalk. One might think that a dynamically-typed language like Smalltalk is difficult to analyze. But in fact there are many ways of analyzing it, and this post concerns analyzing bytecode. Further, languages that support closures […]

Pharo Weekly - Book Farm back in shape


I realised that jenkins dropped the connection to the github repositories of the books and that they were not updated.
You can find my current evening occupation: Learning OOP with Pharo 🙂
I fixed some problems in UnifiedFFI and clean a bit before restarting to work on Pillar.
And we get more green books job.

February 07, 2017

February 06, 2017

Pharo Weekly - Consortium action 30 Jan/5 Feb


This is my weekly ChangeLog, from 30 January 2017 to 5 February 2017.
You can see it in a better format by going here:


3 February 2017:

*    Still on [iceberg](, this time I addresed two issues:

* [issue 269](, which is an improvement on the way we visualise trees (showing just those that have changes, this is very important in big repositories)
* [issue 270](, which addreses a problem I left there when working on multi-remotes: it was showing incorrect data between the real outgoing commits and the ones shown in the browser.

I made a couple of pull requests with them (yep, still using the plugin I developed yesterday :P)

2 February 2017:

*    I spent last two days working on adapt [Iceberg]( infrastructure to accept

Well… not totally true. What in fact I made was to *start* to program a way to add plugins, which for now
are just allowed in repositories pane on repositories browser. But well, the rudiments are there.

What actually took most of my time was the development of the first plugin (you know, I do not believe too much
on “developments in abstract”, I need concrete cases to test my ideas): an Pull Request creator. With this, you
can do from iceberg the same kind of work you do in github web page 🙂

So, now you can have a beutiful pull request dialog, along with several validations… Now, you may wonder why
I needed to develop such kind of tool (after all, you can always go to the web page and do the same). And the
answer is that in the new process we are starting to create for Pharo, we need to be able to do things like:

. create a fix
. create a branch from pharo-core sources, named for example issue-12345 (something that would usually belong to a SLICE)
. sends commits to that branch while working on the issue
. send a Pull Request of the issue (what now is to commit the SLICE to inbox and changing status on the bug tracker)

so, to make this process easy, we need to be able to complete the full cycle from Pharo, exactly as we do it now.

Pull Requests are a necessary step to fulfill this requirement.

31 January 2017:

*    Working on [iceberg](, I fixed a bug that happened when trying to clone a recently created repository
(without branchs yet).


February 04, 2017

Marten Feldtmann - Gemstone/S – Application Example

We had a request for a “smaller” demo sometimes around December: the topic was to enable users to select attribute and values to initiate queries against a data set and visualize them in GoogleMaps. This visualized objects where houses in Germany.

To strip the demo down we produced static data files on a server and the user was only able to select one attribute with specific values and then we showed the result. The GUI was done by using Sencha Architect which is based on Sencha ExtJS JS library.

Demo published – product bought. That was worth it.

Now in January we had to rebuild the demo. The dataset grew much more (estimated to cover whole Germany in the autumn of this year). The original plans where to use a relational database (and NOT Gemstone/S – a company decision)  (and the relational database was the source of the data) and write the server part in PHP or whatever.

But as a new project it was another good testing candidate for PUM and our whole software infrastructure and I sat down, defined the model, the API and rebuild the system in a few days including the whole stuff like uploading, downloading, user management, project management (access restriction) and the whole GUI.

The system had been finished 14 days before needed.

The interesting part of the project was, that now parts of Gemstone/S were used which I never really needed before: searching and indexing facilities of Gemstone/S were needed here and the project showed the drawbacks of the Gemstone/S system in this area.

After the system had been finished, I did a closer look toward searching and indexing and compared the result of Gemstone/S against SQLite3 – perhaps an unfair comparision, because SQLite3 is a file based system.

The system under SQLite3 had only ONE table – more was not needed. The table itselfs contains the data of the houses and and also shows up an internal hierarchical structure of the objects (4 layers).

On the top layer (such as Germany) Gemstone/S had to handle the same amount of items as SQLite3. Doing queries on this layer the only difference is the raw spped of the system – here SQLite3 was two times faster than the Gemstone/S working on a multi million items containing IdentitySet.

By adding indexes on the table (actually for each attribute – so many indexes were added), SQLite3 performed up to 10 times faster than the raw (not indexing) Gemstone/S. These numbers are only valid for a warmed-up Gemstone/S database.

The situation changed, when one is leaving the top most level. SQLite3 still has to query the whole table (with additional where clauses to find the sub-layers) again and can not improve very much here. In this example the second layer has only 1/128 members of the top layer and now Gemstone/S (unindexed) is good in time with SQLite3 (indexed). Of course SQLite3 users could introduce 128 additional tables (and copy data from the large table to the new table) and woul0d win again – but I assume, that this is not the way, relational users are thinking about solutions.

Playing with indexes showed quite some problems with Gemstone/S. As long as you have only one index you are on the good path. Adding a second (and more) index(es): times  got worse – simply because Gemstone/S chooses the wrong index.

Another problem was shown by using the streaming facility: the today implementation does assume, that an index MUST be available on that set, which is queried. But the programming guide also said, that on not so large sets one should not create indexes. So in my hierarchy I have nodes, where the sets are very large and some nodes, where the sets only contain 100 items. The streaming approach can not be used in general on all nodes – thats pretty bad. I would liek to see a more general interface for queries.

Another problem I found was, that the non-streaming approach make an assumption, that the result of a query should only be a small set – and behaves very badly (in milliseconds), when the result set is around 1/3 of the total set. It executes the query and creates a temporary set to hold the items found – adding millions of items takes quite some time here.

So today (with 3.3.3) I am only considering to use one index to use and the streaming approach whenever possible.

The rest of the system is the same (as in all other examples I posted): Gemstone/S 3.3.3, Linux, Apache frontend http, load balancing. Modelling in PUM, Source code gcreation for Topaz (Server) and Sencha ExtJS (client).

On a positive side: Dale got an example application from me,showing all these problems and he is using it in improving the index system in Gemstone/S 3.4 and the first numbers he gave to me looked promising.

After all: the systems for two customers went online yesterday.

Filed under: Smalltalk Tagged: ExtJS, Gemstone/S, Google Maps, PUM, Sencha, Smalltalk