A frog around the world

First, a quick news. Scilab 5.2.2 has been released a few days and he now available in the Debian archive (Debian Unstable for now).
It is mostly a performance improvements and bug fixes release. See the changelog.

Second, for a second year, Scilab is part of the Google Summer of Code v2010. I am admin (and also mentor) this year again.
Google just released the list of accepted students. We have 9 students (against 7 last year). 2 are working on experimental projects, the other should have a finished result by the end of the GSoC.

Extends Scilab UI Control - Han Dong
Extension of Scilab User Interface construction (uicontrol) by providing more elements (tree, image display, etc).

Simulink import in Xcos - Jerzy Zagorski
Importation of most of the Simulink schemas from Xcos.

Cumulative distribution function improvements - Michael Zhang
Improvement and extension of the current cumulative distribution functions (CFD) into Scilab.

Metanet and Boost.graph - Balša Raičević
Extension of the Metanet capabilities in term of graphs by Boost.graph

SOAP Client/server - Artem Glebov
Making available from Scilab both SOAP client and server capabilities as an ATOMS module.

Database module + fuzzySQL - Igor Gridchyn
Allow to access to most databases systems from Scilab. Based on this work, the FuzzySQL will be introduced, a SQL extension to allow flexible conditions in queries.

Python import - Baozeng Ding
Introduction of a mechanism to load and use Python code (objects in particular) from Scilab.

Experimental projects:
Use Eigen into Scilab - Joseph Fahnbulleh
Base some components of the Scilab core code on the Eigen library which is a state-of-the-art C++ linear algebra library. This work will be a joint mentoring between Gaël Guennebaud from the Eigen team and Scilab R & D team.

Hybrid Automata module - Ievgen Ivanov
Provide a convenient environment for direct modeling of hybrid automata in Scilab/Xcos.

In the numerical computing world, the cornerstones libraries are BLAS and LAPACK. They have been used in most of the numerical software for decades (like Scilab, R, numpy, OpenOffice with calc, etc).

During that time, many implementations appeared to improve the performances taking advantages of clusters, multicore, SEE{1,2,3,4}, various levels of cache...
Between the reference BLAS (refblas) to an optimized one like ATLAS or MKL (Math Kernel Library by Intel - non-free), it is not rare to have a 15 factor.

In Debian, we use by default the reference implementation of BLAS (168 reverse dependencies) and LAPACK (178 reverse dependencies). If the results are usually bad, they are pretty easy to use. What is hard to use, is switch between highly optimized libraries.
For now, the main one in the archive is ATLAS. ATLAS build process will launch many computations to know what will work best on the architecture. Results are usually excellent.

1) Upload of a refactoring of the ATLAS package.
I have been working on this for a while and after 19 uploads into Debian Experimental and I am happy (and kind of relief) to upload into debian unstable the release 3.8.3 of ATLAS.

The new key elements in this release are:

• Package of the release 3.8.3 ... Long overdue
• Much more packages for recent architectures (sse3, core2sse3, etc)
• A simplified maintenance
• Easy to build a custom package: fakeroot debian/rules custom
• Easy upgrade to version 3.9.X when it is stable
• 12 bugs closed in Debian (including 4 RCs)
• 6 bugs closed in Launchpad.
• MMX optimized package removed

Note that, as before, all prebuilt binaries of ATLAS will be always slower than if you built them on the target architecture (but using Debian binary packages will save a few kilograms of Uranium).

And one of most important feature is the capability to switch to any ATLAS implementation.

2) Switch between the different implementation
The problem in Debian (and Ubuntu) was that it was hard to switch between the ref BLAS/LAPACK and the optimized libraries. The user has to play with the LD_LIBRARY_PATH to use the various optimized packages and since there is no convention between the various distribution, the upstream developer has to develop crappy tricks to handle such things.

It is why I implemented the following proposal: Handle different versions of BLAS and LAPACK.

The main idea is to use the update-alternatives system to allow a quick and easy switch. For example:

# update-alternatives --config libblas.so.3gf 
There are 3 choices for the alternative libblas.so.3gf (providing /usr/lib/libblas.so.3gf).

  Selection    Path                                           Priority   Status
------------------------------------------------------------
* 0            /usr/lib/atlas-core2sse3/atlas/libblas.so.3gf   55        auto mode
  1            /usr/lib/atlas-base/atlas/libblas.so.3gf        35        manual mode
  2            /usr/lib/atlas-core2sse3/atlas/libblas.so.3gf   55        manual mode
  3            /usr/lib/libblas/libblas.so.3gf                 10        manual mode

# update-alternatives --config liblapack.so.3gf
There are 3 choices for the alternative liblapack.so.3gf (providing /usr/lib/liblapack.so.3gf).

  Selection    Path                                             Priority   Status
------------------------------------------------------------
* 0            /usr/lib/atlas-core2sse3/atlas/liblapack.so.3gf   55        auto mode
  1            /usr/lib/atlas-base/atlas/liblapack.so.3gf        35        manual mode
  2            /usr/lib/atlas-core2sse3/atlas/liblapack.so.3gf   55        manual mode
  3            /usr/lib/lapack/liblapack.so.3gf                  10        manual mode

Thanks to this, it is just trivial to switch from one to the other...

Conclusion:
I just pushed the changes into Debian unstable for blas, lapack and atlas.
I have been testing a lot these deep modifications and I fixed all the problems that I found. However, in case I missed something, please report a bug...

Here is a quick list of new things around Scilab (note that it is slightly modified message of the one I sent on the dev mailing list).

• Sagemath - it is a software which combines the power of various opensource software.
  A Experimental "Scilab/Sage package" is planed for Sage 3.4 and an experimental package by Jaap Spies is already available
• Debian/Ubuntu
  Packages are available on my Scilab homepage
  Debian packages are up-to-date (5.0.3-2). I will to upload the new Ubuntu's packages in 2009 (for now, it is 5.0.3-1 which is working too). I might backport them to Debian Lenny (future stable) & Ubuntu Hardy.
• Mandriva
  Tomasz Pawel Gajc (a regular Mandriva contributor) created a package available on zarb.org
• Opensuse
  A Scilab package for Opensuse has been created by Andrea Florio.
  It is available on packman
  and should be included in the next version of opensuse.
  Note that Mandriva & Opensuse packages have been created for Scilab 5.0.3 and I applied most of their patches (or update some part of the code) for Scilab 5.0.4.
• Redhat/Fedora
  The work is still going on.
  They are also doing a great work packaging the misc dependencies but they are a bit stuck about the JOGL packaging (jogl and glugen should produce two different packages ... which I should also do in Debian/Ubuntu too)

• Arch Linux
  It is also available under Arch Linux by Simon Lipp (one of our former trainee).

• Gentoo
  A bit stuck for now but some activities have been seen lately around on jrosetta (one of the dependency introduced by Scilab 5).
• Slackware
  Scilab has been packaged by the Italian Slackware community. It is available on their website. I don't know if it is going to be included in Slackware by default or not;

Aujourd'hui, j'étais présent à Mont de Marsan aux RMLL: les rencontres mondiales du Logiciel Libre. Outre assister à quelques conférences, j'étais surtout présent pour présenter un travail qui m'a bien occupé (tout en me passionnant) ces derniers mois: le changement de licence de Scilab.
J'ai effectué cette présentation dans la section communauté des RMLL. Clin d'oeil, le responsable de cette section est Benoît Sibaud, président de l'APRIL qui est justement l'auteur de la page détaillant les, désormais anciens, problèmes de licence Scilab.
Présentation qui s'est très bien déroulée avec des questions souvent judicieuses et pertinentes.
J'ai assisté à quelques présentations intéressantes comme celle de Lucas Nussbaum sur le fonctionnement de Debian, de Hugues Prisker de EDF R & D sur le calcul HPC et le libre chez EDF ou de Arnaud Laprévote sur le projet GGCC

Pour ceux que ça intéresse: Passage de Scilab sous une licence libre aux RMLL le 3 juillet 2008

Un article sur le fonctionnement du logiciel libre a été publié sur 01net et qui cite comme exemple le fonctionnement de Scilab.

Voici les deux passages qui parlent de Scilab :

Parmi les communautés les plus actives, citons Apache, Eclipse, Mozilla, MySQL, ObjectWeb, OpenOffice.org, Scilab... Certaines réunissent des millions de contributeurs bénévoles.

(soit dit en passant, j'aimerais bien savoir quelles communautés réunissent des millions de contributeurs).

C'est le cas de PSA ou de Dassault Aviation, qui ont adhéré au consortium Scilab, que pilote l'Inria (Institut national de recherche en informatique et automatique). A l'origine, les chercheurs entendaient limiter l'hégémonie du logiciel de calcul scientifique MatLab, édité par l'Américain Mathworks, et vendu plusieurs milliers d'euros. Un prix hors de portée de nombre de PME spécialisées en ingénierie. « Dans le cadre de ses premières expériences en logiciels libres, l'Inria a décidé dès 1994 d'adapter au web Scilab, son propre logiciel de calcul », raconte Didier Halgand, le responsable marketing du consortium.

Scilab annonce 15 000 téléchargements par mois et 250 000 utilisateurs. Surtout, il rassemble des fleurons de l'industrie. Outre Dassault Aviation et PSA, EADS, EDF, Renault et Thales co-financent cette initiative à hauteur de 2 000 à 25 000 euros par an, selon le nombre d'utilisateurs. En contrepartie, l'équipe de développeurs effectue la maintenance et la mise à jour du logiciel. Scilab est utilisé par Dassault Aviation pour ses maquettes de simulation. Le constructeur du Rafale n'effectue pas directement de développements. En revanche, il tient, en tant qu'utilisateur, à faire entendre sa voix pour orienter ceux-ci vers les points qu'il juge prioritaires. Cela lui sert également à connaître les risques présentés par le logiciel sur une portion limitée de ses activités.