Planet Smalltalk

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”
http://tiny.cc/pharo-scholar

1,630 on normal google for…
“pharo” “programming” “abstract” “introduction” “conclusion”
“references” filetype:pdf
http://tiny.cc/pharo-papers

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!

googlefight_between_squeak_and_pharo

 


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 modeling-languages.com. 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="https://association.pharo.org">https://association.pharo.org</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

Hello!

This is my weekly ChangeLog, from 6 February 2017 to 12 February 2017.
You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/2/2017&to=12/2/2017

ChangeLog
=========

9 February 2017:
—————-

* I finished the work started yesterday and now there is a [Pull Request](https://github.com/npasserini/iceberg/pull/276)
enabling the use of SSH for iceberg

8 February 2017:
—————-

* I worked with Pablo on *iceberg*, in [issue 275](https://github.com/npasserini/iceberg/issues/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
[here](https://github.com/estebanlm/iceberg/commits/dev-0.4)
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](https://github.com/pharo-project/pharo-vm/pull/114) that
will enhance the build process in linux platforms.

This was submited by [Holger](https://github.com/zecke), and is part of his work to create VM package versions.

cheers!
Esteban


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

gnochon_coding

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_coding_pharo

Gnochon sur Pharo 5.0

2-Le premier adversaire

squeak_chess

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!

3-Lozza

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

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

Hi,

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’;
load.
(#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.

Cheers,
Doru


http://www.tudorgirba.com
http://www.feenk.com

“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

bitcounting

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

sle17-banner
========================================================================
**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: https://twitter.com/sleconf
========================================================================
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 (http://www.sigplan.org/Resources/Author/).
* **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 (http://www.sigplan.org/Resources/Author/), 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 (http://www.sigplan.org/Resources/Author/).
* **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 (http://www.sigplan.org/Resources/Author/).
### 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: sle2017@inria.fr

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

Hi

https://ci.inria.fr/pharo-contribution/view/Books/

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.
Stef

February 07, 2017

February 06, 2017

Pharo Weekly - Consortium action 30 Jan/5 Feb

Hello!

This is my weekly ChangeLog, from 30 January 2017 to 5 February 2017.
You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=30/1/2017&to=5/2/2017

ChangeLog
=========

3 February 2017:
—————-

*    Still on [iceberg](https://github.com/npasserini/iceberg), this time I addresed two issues:

* [issue 269](https://github.com/npasserini/iceberg/issues/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](https://github.com/npasserini/iceberg/issues/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](https://github.com/npasserini/iceberg) infrastructure to accept
plugins.

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](https://github.com/npasserini), I fixed a bug that happened when trying to clone a recently created repository
(without branchs yet).

cheers!
Esteban


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

February 03, 2017

Pharo News - Next Pharo Sprints 2017

<p> We organise one Pharo “Sprint” per month were we meet to work on boring issue tracker entries together. </p> <p> Goals of the next sprints: </p><ul> <li>Clean issue tracker to prepare for release Pharo6</li> <li>Remove Pharo6 tag from not-important cases</li> <li>Check Pharo5 Issues and pending back-ports</li> </ul> <p> Remotely, you can join us on Slack. During the sprint, we will try to synchronize local and remote Pharo sprinters. In the past people organised local sprints at the same time (e.g. Santiago/Chile). </p> <p> There will be an event on the association website for each sprint. The next dates are: </p><ul> <li>Mar 03 <a href="https://association.pharo.org/event-2451866">Event Pharo Association</a></li> <li>Mar 31</li> <li>Apr 28</li> <li>Jun 02</li> <li>Jun 30</li> </ul>

February 01, 2017

David Buck (Simberon) - Base source code - the good, the bad and the ugly

Smalltalk is one of the very few development environments where developers get easy access to all the source code of all the frameworks they use.  This comes in very handy when there are problems you need to debug and you need to step through the framework to figure them out.  It also allows you to see how the framework expects to call your code.

Smalltalk also allows you to make changes to that framework.  Environments like VisualWorks even allow you to keep your base changes in your own packages so that they're loaded in when you load the rest of your code from the version control system.

The problem with all of that is that developers begin to feel too free that they can change anything they want.  If they don't like the colors of controls, they can change them.  Do you want to add new options to the controls? Sure, go ahead. Do you want lists that format their contents into columns?  Just write it.  Many companies develop their own frameworks on to of the vendor-supplied framework.

It makes for an incredibly flexible system but there's one huge drawback.  When you upgrade to a new version of the base, the vendor has made changes and now all of your modifications don't work.  It's a long and painful process to find the pieces that are wrong and either fix them or re-write them.

I'm currently working on two upgrades for VisualWorks customers.  Both of them have built their own frameworks on top of the VisualWorks framework.  Both are encountering problems upgrading to the latest version because some very basic things have changed in the base.  Normally, these are details that only the vendor needs to worry about, but when you build your own framework with intimate knowledge of how the base framework operates, you're going to run into problems.

I don't really have a good solution for these customers except to fix the problems as I come across them.  It would have been nice if they didn't have this strong dependency on the base but given that they do, I can't really change that.  They just have to understand that it makes upgrades more difficult and expensive.

Do developers in other languages have these problems as well?  Do you need to make sweeping changes to your Java application whenever a new version of Java or one of your framework libraries comes out?  Do you customize your framework libraries?  Is this just a Smalltalk headache?  Let me hear from you.

David Buck (Simberon) - Base source code - the good, the bad and the ugly

Smalltalk is one of the very few development environments where developers get easy access to all the source code of all the frameworks they use.  This comes in very handy when there are problems you need to debug and you need to step through the framework to figure them out.  It also allows you to see how the framework expects to call your code.

Smalltalk also allows you to make changes to that framework.  Environments like VisualWorks even allow you to keep your base changes in your own packages so that they're loaded in when you load the rest of your code from the version control system.

The problem with all of that is that developers begin to feel too free that they can change anything they want.  If they don't like the colors of controls, they can change them.  Do you want to add new options to the controls? Sure, go ahead. Do you want lists that format their contents into columns?  Just write it.  Many companies develop their own frameworks on to of the vendor-supplied framework.

It makes for an incredibly flexible system but there's one huge drawback.  When you upgrade to a new version of the base, the vendor has made changes and now all of your modifications don't work.  It's a long and painful process to find the pieces that are wrong and either fix them or re-write them.

I'm currently working on two upgrades for VisualWorks customers.  Both of them have built their own frameworks on top of the VisualWorks framework.  Both are encountering problems upgrading to the latest version because some very basic things have changed in the base.  Normally, these are details that only the vendor needs to worry about, but when you build your own framework with intimate knowledge of how the base framework operates, you're going to run into problems.

I don't really have a good solution for these customers except to fix the problems as I come across them.  It would have been nice if they didn't have this strong dependency on the base but given that they do, I can't really change that.  They just have to understand that it makes upgrades more difficult and expensive.

Do developers in other languages have these problems as well?  Do you need to make sweeping changes to your Java application whenever a new version of Java or one of your framework libraries comes out?  Do you customize your framework libraries?  Is this just a Smalltalk headache?  Let me hear from you.