Monthly Archives: April 2019

[Ann] Two nice books for the forthcoming mooc!

To support the start of the new season of the Pharo Mooc (https://www.fun-mooc.fr/courses/course-v1:inria+41010+self_paced/about) on May 6th, we are happy to announce a new version of the book: TinyBlog: a First web App in Pharo in English and French.

 

http://books.pharo.org/tinyblog-tutorial/ and http://books.pharo.org/tinyblog-tutoriel/

Stéphane, Luc and Olivier. http://mooc.pharo.org

Advertisements

Best paper award in the “Industrial Robot” category @ ICARSC 2019

IMTDouai Team (L. Fabresse/N. Bouraqadi) just won the Best paper award in the “Industrial Robot” category @ ICARSC 2019 () with our paper titled “PolySLAM: A 2D Polygon-based SLAM Algorithm” implemented in Pharo @johannDichtl @glozenguez

Well done!

Agile Artificial Intelligence

Dear All, I have a good and bad news
the good news is that the book Agile Artificial Intelligence will be published by Apress, a major publisher in computer science. This will bring visibility to Pharo at a large scale
👍🏻

3
The bad news is that the website https://agileartificialintelligence.github.io/ will be shut off soon
Agile Artificial Intelligence
Source of the book Agile Artificial Intelligence
However, the source code given in the book will have its own GitHub repository and will remain free of access

[Pre-ann] Spec 2.0 Gtk3 bindings

People that assisted to Pharo Days 2019 (or that follow my twitter account) already know this, but it needs to be formally announced: 
 
We are working on Spec 2.0, and it will provide not just the classic Morphic bindings but also a new option for developers: Gtk3 bindings!
Why we want a Spec 2.0 with different backends?
There are reasons that converged to decide us to make it:
  • First, to provide a validated abstract Spec 2.0 that can be used with different backends, preparing Pharo to be able to switch backends without needing to recreate the full IDE from scratch each time (a problem we have partially now in our way to deprecate Morphic).
  • Second, because we receive from different sources the requirement of having the possibility of developing real native-looking desktop applications. Yes, in moment where people talk about the cloud, SaaS and web-applications as the “next big thing” (something that is been declared since years, by the way), we believe is important to provide this, for two big reasons: 
    1. Because there is still an important place for desktop applications market and most medium-size to big business still require them.
    2. Because Pharo itself is a desktop application! (And we need to provide the best experience possible on it).
For us, this is a fundamental step to continue improving Pharo itself, and it matches also the work we are doing on going real-headless:  Pharo users will be able to start the Morphic world, a Gtk application or the next backend to come.
Why Gtk3?
There are some other important players in the “native widgets scene”, so why we choose Gtk3? 
Again, several reasons  were taken into account: 
  • Gtk3 is cross platform. Yes, technically is just “native” in linux, but it works on Windows and macOS too. 
  • It is very mature and popular.
  • It is made in plain C.
Next step: tool migration
The only way to know if you have covered what is needed is actually taking real-life use cases and implementing them. We have a list of tools that needs to be migrated and we are starting from them: 
  1. Old GT tools will be replaced by new Spec tools (while preserving its power).
  2. Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
  3. Pharo launcher as a standalone application is a good example of what you can do with the Gtk3 bindings.
And that’s it. Pharo 8.0 will come with Spec 2.0 and users will be able to benefit of it immediately 🙂
Pharo 80 will not need Gtk3. We will provide packages for Gtk3 for the people that need it. We will also release Spec20 soon so that people can try Spec 20 – independently of Gtk3
Pharo Consortium mainly Esteban, Pablo and Guille

[ann] Workflow engine in Pharo

Hello everyone,
we’ve been working on a workflow engine written in Pharo. You can check it out at: https://github.com/skaplar/NewWave
It is still in the early development and we discussed about making it public so everyone interested can join, take a look or provide any kind of feedback. I’m also at discord so you can contact me @skaplar.
Best regards,
Sebastijan Kaplar

Looking in the future @Pharodays

Really great talks at PharoDays

  • Object centric debuggers
  • New test infrastructure
  • Example driven development
  • Spec2 with GTK backend
  • UI testing

About Performance Issues

Hi, this will be a long mail. I have organized it in different sections.

This work is sponsored by the Pharo consortium and financially supported by Lifeware and Schmidt.
Summary:
======

– There are performance issues in Pharo 7.
– I have made benchmarks.
– With Guille we made an improvement in saving source code in methods.
– More improvements to come.
– Automation and CI in the future.

Background
=========

Since the release of Pharo 7 (and before it), it was notorious that
there exists a performance regression in the normal execution of the
image. By checking the usual operations, we have seen ( and many have
also detected) that there was an issue with the loading, compilation,
and unloading of code. Also with the creation of classes, traits and
the use of slots.

Benchmarks
=========

Although we were sure that there is a performance regression, we have
to show it in a way we can test it and measure it. If we cannot
measure it or repeat its execution it is worthless.
For doing so, I have created an initial set of micro-benchmarks to
cover normal operations of the image.

The set of benchmarks is available here:
https://github.com/tesonep/pharo-benchmarks

These benchmarks are developed on top of SMark, only adding a command
line tool and the ability to generate a CSV file.

The idea is to run the benchmarks in different versions of Pharo an
assert that we are not breaking anything.

The first results were basically a nightmare, some operations take
almost 20 times more in Pharo 7. Especially, the ones that are
compiling methods.

In the attached document, there is the detail of all the benchmarks,
the different results and the analysis of the improvements and
regressions (Positive percentages are regressions (more time),
negative are improvements (less time)).

I have checked the results in OSX with 64 bits images. But as the
problem is in pure Smalltalk implementations the problems are (and the
solutions) cross platforms.

First Improvement
==============

Having the benchmarks, it was easy to start looking for the problems.
Thanks to the help of Guille we have detected some problems in the
implementation of SourceFile. Objects of this class have the
responsibility to handle the save of the source code when a method is
modified.

Improving this implementation we have gotten to results similar to
Pharo 6 in the compilation of methods.

Comparing a stock Pharo8 image with the one with the fix, we have the
following improvements:

AddingAnInstanceVariableToAClassWithASubclass -3.96%
AddingAnInstanceVariableToAClassWithoutASubclassAndInstances -15.91%
AddingAnInstanceVariableToAClassWithoutSubclasses -28.50%
ClassAndSubclassCreation -25.67%
ClassUsingATrait -90.05%
SimpleClassCreation -26.55%
TraitCreation -92.95%
TraitCreationUsingOtherTrait -91.68%
CompileAMethodAndModifyIt -32.92%
CompileAMethodInAClassUsingATrait -83.28%
CompileAMethodInATraitNotUsed -85.12%
CompileAMethodInATraitUsed -88.16%
CompileANewMethod -40.73%
CompileANewMethodUsingInstanceVariable -33.93%
MethodAccessingAGlobal -47.57%

Again there are more details in the attached file.

Also, we have ported this fix to Pharo 7.

Next Steps
========

– Making it a part of the CI infrastructure: making it run in each PR
and build to detect regressions in the changes.

– Adding more micro and macro benchmarks. I have a list of things to
test, but I am open to more:

# Micro

– Slot Implementation
– Process handling
– Refactorings
– Files (open / write / read)

# Macro

– Loading:  Moose  / Seaside
– Recompile All
– Condense Sources
– Startup
– Shutdown

We also know that there are platform related issues (especially
Windows), so the idea it will be the same, build a benchmark, measure
it, improve it.

The idea is to have a more robust way of detecting and handling the
performance of Pharo. Of course, I am open to all your comments.

Cheers,
Pablo