blog entries created by Nicolas Chauvat

Open Legislative Data Conference 2014

2014/06/10 by Nicolas Chauvat

I was at the Open Legislative Data Conference on may 28 2014 in Paris, to present a simple demo I worked on since the same event that happened two years ago.

The demo was called "Law is Code Rebooted with CubicWeb". It featured the use of the cubicweb-vcreview component to display the amendments of the hospital law ("loi hospitalière") gathered into a version control system (namely Mercurial).

The basic idea is to compare writing code and writing law, for both are collaborative and distributed writing processes. Could we reuse for the second one the tools developed for the first?

Here are the slides and a few screenshots.

http://www.logilab.org/file/253394/raw/lawiscode1.png

Statistics with queries embedded in report page.

http://www.logilab.org/file/253400/raw/lawiscode2.png

List of amendments.

http://www.logilab.org/file/253396/raw/lawiscode3.png

User comment on an amendment.

While attending the conference, I enjoyed several interesting talks and chats with other participants, including:

  1. the study of co-sponsorship of proposals in the french parliament
  2. data.senat.fr announcing their use of PostgreSQL and JSON.
  3. and last but not least, the great work done by RegardsCitoyens and SciencesPo MediaLab on visualizing the law making process.

Thanks to the organisation team and the other speakers. Hope to see you again!


Deuxième hackathon codes libres de mécanique

2014/04/07 by Nicolas Chauvat

Organisation

Le 27 mars 2014, Logilab a accueilli un hackathon consacré aux codes libres de simulation des phénomènes mécaniques. Etaient présents:

  • Patrick Pizette, Sébastien Rémond (Ecole des Mines de Douai / DemGCE)
  • Frédéric Dubois, Rémy Mozul (LMGC Montpellier / LMGC90)
  • Mickaël Abbas, Mathieu Courtois (EDF R&D / Code_Aster)
  • Alexandre Martin (LAMSID / Code_Aster)
  • Luca Dall'Olio, Maximilien Siavelis (Alneos)
  • Florent Cayré, Nicolas Chauvat, Denis Laxalde, Alain Leufroy (Logilab)

DemGCE et LMGC90

Patrick Pizette et Sébastien Rémond des Mines de Douai sont venus parler de leur code de modélisation DemGCE de "sphères molles" (aussi appelé smooth DEM), des potentialités d'intégration de leurs algorithmes dans LMGC90 avec Frédéric Dubois du LMGC et de l'interface Simulagora développée par Logilab. DemGCE est un code DEM en 3D développé en C par le laboratoire des Mines de Douai. Il effectuera bientôt des calculs parallèles en mémoire partagée grâce à OpenMP. Après une présentation générale de LMGC90, de son écosystème et de ses applications, ils ont pu lancer leurs premiers calculs en mode dynamique des contacts en appelant via l'interface Python leurs propres configurations d'empilements granulaires.

Ils ont grandement apprécié l'architecture logicielle de LMGC90, et en particulier son utilisation comme une bibliothèque de calcul via Python, la prise en compte de particules de forme polyhédrique et les aspects visualisations avec Paraview. Il a été discuté de la réutilisation de la partie post/traitement visualisation via un fichier standard ou une bibliothèque dédiée visu DEM.

Frédéric Dubois semblait intéressé par l'élargissement de la communauté et du spectre des cas d'utilisation, ainsi que par certains algorithmes mis au point par les Mines de Douai sur la génération géométrique d'empilements. Il serait envisageable d'ajouter à LMGC90 les lois d'interaction de la "smooth DEM" en 3D, car elles ne sont aujourd'hui implémentées dans LMGC90 que pour les cas 2D. Cela permettrait de tester en mode "utilisateur" le code LMGC90 et de faire une comparaison avec le code des Mines de Douai (efficacité parallélisation, etc.).

Florent Cayré a fait une démonstration du potentiel de Simulagora.

LMGC90 et Code_Aster dans Debian

Denis Laxalde de Logilab a travaillé d'une part avec Rémy Mozul du LMGC sur l'empaquetage Debian de LMGC90 (pour intégrer en amont les modifications nécessaires), et d'autre part avec Mathieu Courtois d'EDF R&D, pour finaliser l'empaquetage de Code_Aster et notamment discuter de la problématique du lien avec la bibliothèque Metis: la version actuellement utilisée dans Code_Aster (Metis 4), n'est pas publiée dans une licence compatible avec la section principale de Debian. Pour cette raison, Code_Aster n'est pas compilé avec le support MED dans Debian actuellement. En revanche la version 5 de Metis a une licence compatible et se trouve déjà dans Debian. Utiliser cette version permettrait d'avoir Code_Aster avec le support Metis dans Debian. Cependant, le passage de la version 4 à la version 5 de Metis ne semble pas trivial.

Voir les tickets:

Replier LibAster dans Code_Aster

Alain Leufroy et Nicolas Chauvat de Logilab ont travaillé à transformer LibAster en une liste de pull request sur la forge bitbucket de Code_Aster. Ils ont présenté leurs modifications à Mathieu Courtois d'EDF R&D ce qui facilitera leur intégration.

Voir les tickets:

Suppression du superviseur dans Code_Aster

En fin de journée, Alain Leufroy, Nicolas Chauvat et Mathieu Courtois ont échangé leurs idées sur la simplification/suppression du superviseur de commandes actuel de Code_Aster. Il est souhaitable que la vérification de la syntaxe (choix des mots-clés) soit dissociée de l'étape d'exécution.

La vérification pourrait s'appuyer sur un outil comme pylint, la description de la syntaxe des commandes de Code_Aster pour pylint pourrait également permettre de produire un catalogue compréhensible par Eficas.

L'avantage d'utiliser pylint serait de vérifier le fichier de commandes avant l'exécution même si celui-ci contient d'autres instructions Python.

Allocation mémoire dans Code_Aster

Mickaël Abbas d'EDF R&D s'est intéressé à la modernisation de l'allocation mémoire dans Code_Aster et a listé les difficultés techniques à surmonter ; l'objectif visé est un accès facilité aux données numériques du Fortran depuis l'interface Python. Une des difficultés est le partage des types dérivés Fortran en Python. Rémy Mozul du LMGC et Denis Laxalde de Logilab ont exploré une solution technique basée sur Cython et ISO-C-Bindings. De son côté Mickaël Abbas a contribué à l'avancement de cette tâche directement dans Code_Aster.

Doxygen pour documentation des sources de Code_Aster

Luca Dall'Olio d'Alneos et Mathieu Courtois ont testé la mise en place de Doxygen pour documenter Code_Aster. Le fichier de configuration pour doxygen a été modifié pour extraire les commentaires à partir de code Fortran (les commentaires doivent se trouver au dessus de la déclaration de la fonction, par exemple). La configuration doxygen a été restituée dans le depôt Bitbucket. Reste à évaluer s'il y aura besoin de plusieurs configurations (pour la partie C, Python et Fortran) ou si une seule suffira. Une configuration particulière permet d'extraire, pour chaque fonction, les points où elle est appelée et les autres fonctions utilisées. Un exemple a été produit pour montrer comment écrire des équations en syntaxe Latex, la génération de la documentation nécessite plus d'une heure (seule la partie graphique peut être parallélisée). La documentation produite devrait être publiée sur le site de Code_Aster.

La suite envisagée est de coupler Doxygen avec Breathe et Sphinx pour compléter la documentation extraite du code source de textes plus détaillés.

La génération de cette documentation devrait être une cible de waf, par exemple waf doc. Un aperçu rapide du rendu de la documentation d'un module serait possible par waf doc file1.F90 [file2.c [...]].

Voir Code Aster #18 configure doxygen to comment the source files

Catalogue d'éléments finis

Maximilien Siavelis d'Alneos et Alexandre Martin du LAMSID, rejoints en fin de journée par Frédéric Dubois du LMGC ainsi que Nicolas Chauvat et Florent Cayré de Logilab, ont travaillé à faciliter la description des catalogues d'éléments finis dans Code_Aster. La définition de ce qui caractérise un élément fini a fait l'objet de débats passionnés. Les points discutés nourriront le travail d'Alexandre Martin sur ce sujet dans Code_Aster. Alexandre Martin a déjà renvoyé aux participants un article qu'il a écrit pour résumer les débats.

Remontée d'erreurs de fortran vers Python

Mathieu Courtois d'EDF R&D a montré à Rémy Mozul du LMGC un mécanisme de remontée d'exception du Fortran vers le Python, qui permettra d'améliorer la gestion des erreurs dans LMGC90, qui a posé problème dans un projet réalisé par Denis Laxalde de Logilab pour la SNCF.

Voir aster_exceptions.c

Conclusion

Tous les participants semblaient contents de ce deuxième hackathon, qui faisait suite à la première édition de mars 2013 . La prochaine édition aura lieu à l'automne 2014 ou au printemps 2015, ne la manquez pas !


SaltStack Paris Meetup on Feb 6th, 2014 - (S01E02)

2013/12/20 by Nicolas Chauvat

Logilab has set up the second meetup for salt users in Paris on Feb 6th, 2014 at IRILL, near Place d'Italie, starting at 18:00. The address is 23 avenue d'Italie, 75013 Paris.

Here is the announce in french http://www.logilab.fr/blogentry/1981

Please forward it to whom may be interested, underlining that pizzas will be offered to refuel the chatters ;)

Conveniently placed a week after the Salt Conference, topics will include anything related to salt and its uses, demos, new ideas, exchange of salt formulas, commenting the talks/videos of the saltconf, etc.

If you are interested in Salt, Python and Devops and will be in Paris at that time, we hope to see you there !


JDEV2013 - Software development conference of CNRS

2013/09/14 by Nicolas Chauvat

I had the pleasure to be invited to lead a tutorial at JDEV2013 titled Learning TDD and Python in Dojo mode.

http://www.logilab.org/file/177427/raw/logo_JDEV2013.png

I quickly introduced the keywords with a single slide to keep it simple:

http://Python.org
+ Test Driven Development (Test, Code, Refactor)
+ Dojo (house of training: Kata / Randori)
= Calculators
  - Reverse Polish Notation
  - Formulas with Roman Numbers
  - Formulas with Numbers in letters

As you can see, I had three types of calculators, hence at least three Kata to practice, but as usual with beginners, it took us the whole tutorial to get done with the first one.

The room was a class room that we set up as our coding dojo with the coder and his copilot working on a laptop, facing the rest of the participants, with the large screen at their back. The pair-programmers could freely discuss with the people facing them, who were following the typing on the large screen.

We switched every ten minutes: the copilot became coder, the coder went back to his seat in the class and someone else stood up to became the copilot.

The session was allocated 3 hours split over two slots of 1h30. It took me less than 10 minutes to open the session with the above slide, 10 minutes as first coder and 10 minutes to close it. Over a time span of 3 hours, that left 150 minutes for coding, hence 15 people. Luckily, the whole group was about that size and almost everyone got a chance to type.

I completely skipped explaining Python, its syntax and the unittest framework and we jumped right into writing our first tests with if and print statements. Since they knew about other programming languages, they picked up the Python langage on the way.

After more than an hour of slowly discovering Python and TDD, someone in the room realized they had been focusing more on handling exception cases and failures than implementing the parsing and computation of the formulas because the specifications where not clearly understood. He then asked me the right question by trying to define Reverse Polish Notation in one sentence and checking that he got it right.

Different algorithms to parse and compute RPN formulas where devised at the blackboard over the pause while part of the group went for a coffee break.

The implementation took about another hour to get right, with me making sure they would not wander too far from the actual goal. Once the stack-based solution was found and implemented, I asked them to delete the files, switch coder and start again. They had forgotten about the Kata definition and were surprised, but quickly enjoyed it when they realized that progress was much faster on the second attempt.

Since it is always better to show that you can walk the talk, I closed the session by praticing the RPN calculator kata myself in a bit less than 10 minutes. The order in which to write the tests is the tricky part, because it can easily appear far-fetched for such a small problem when you already know an algorithm that solves it.

Here it is:

import operator

OPERATORS = {'+': operator.add,
             '*': operator.mul,
             '/': operator.div,
             '-': operator.sub,
             }

def compute(args):
    items = args.split()
    stack = []
    for item in items:
        if item in OPERATORS:
            b,a = stack.pop(), stack.pop()
            stack.append(OPERATORS[item](a,b))
        else:
            stack.append(int(item))
    return stack[0]

with the accompanying tests:

import unittest
from npi import compute

class TestTC(unittest.TestCase):

    def test_unit(self):
        self.assertEqual(compute('1'), 1)

    def test_dual(self):
        self.assertEqual(compute('1 2 +'), 3)

    def test_tri(self):
        self.assertEqual(compute('1 2 3 + +'), 6)
        self.assertEqual(compute('1 2 + 3 +'), 6)

    def test_precedence(self):
        self.assertEqual(compute('1 2 + 3 *'), 9)
        self.assertEqual(compute('1 2 * 3 +'), 5)

    def test_zerodiv(self):
        self.assertRaises(ZeroDivisionError, compute, '10 0 /')

unittest.main()

Apparently, it did not go too bad, for I had positive comments at the end from people that enjoyed discovering in a single session Python, Test Driven Development and the Dojo mode of learning.

I had fun doing this tutorial and thank the organizators for this conference!


The Great Salt Sprint Paris Location is Logilab

2013/07/12 by Nicolas Chauvat
http://farm1.static.flickr.com/183/419945378_4ead41a76d_m.jpg

We're happy to be part of the second Great Salt Sprint that will be held at the end of July 2013. We will be hosting the french sprinters on friday 26th in our offices in the center of Paris.

The focus of our Logilab team will probably be Test-Driven System Administration with Salt, but the more participants and the topics, the merrier the event.

Please register if you plan on joining us. We will be happy to meet with fellow hackers.

photo by Sebastian Mary under creative commons licence.


Réseau social ouvert et distribué avec CubicWeb

2012/07/18 by Nicolas Chauvat

Qu'est-ce qu'un réseau social ?

  • descriptions de personnes (profil, histoire, etc)
  • liens avec les autres membres (carnet adresses, etc)
  • création de groupes
  • partage de contenu (photos, vidéos, présentations, etc)
  • discussion (blog, commentaires, forums, messages, microblog)
  • mise en relation (boulot, ludo, dodo, etc)
  • recommandation (lien, livre, achat, film, music, etc)
  • présence (fait quoi, avec qui, où, etc)

Et l'interopérabilité ?

  • nombreuses applications / plate-formes
  • en majorité centralisées et fermées
  • ouverture progressive: protocoles et API en cours de dév
  • réseaux ouverts et distribués: appleseed, diaspora, onesocialweb, etc.
  • pourrait-on faire autrement ?

API: openstack

  • découverte / discovery = xrd
  • identité / identity = openid
  • contrôle d'accès / access control = oauth
  • activités / streams = activity streams
  • personnes / people = portable contacts
  • applications = opensocial

Et en utilisant les standards du Web ?

Architecture ouverte et distribuée

  • vocabulaires RDF et protocole HTTP + REST
  • chacun son serveur
  • GET et éventuellement copie locale
  • abonnement si nécessaire (pubsub, xmpp, atom ?)
  • permissions gérées localement

=> social semantic network

Pourquoi CubicWeb ?

  • plate-forme pour web sémantique (semantic web framework)
  • conçu pour avoir composants à assembler
  • chacun peut définir son application sur mesure
  • fait pour publier html et rdf en parallèle
  • fait pour exporter et importer données
  • déjà foaf, skos, sioc, doap, rss, atom, etc.

Exemple

  • (micro)blog + book + link + file
  • pourrait ajouter: musique, photos, etc.
  • mais aussi: journal, recherche appartement, etc.

Et ensuite ?

Il y a bien longtemps...

  • découverte = who et cat /etc/passwd | cut -d: -f1
  • identité = login
  • contrôle accès = chmod, chgrp, su
  • activités = .plan
  • personnes = .addressbook
  • applications = vim ~/public_html/me.html

Note

Ce texte a été présenté en août 2010, lors de la conférence française des utilisateurs de Python (PyCon-Fr 2010)


Generating a user interface from a Yams model

2012/01/09 by Nicolas Chauvat

Yams is a pythonic way to describe an entity-relationship model. It is used at the core of the CubicWeb semantic web framework in order to automate lots of things, including the generation and validation of forms. Although we have been using the MVC design pattern to write user interfaces with Qt and Gtk before we started CubicWeb, we never got to reuse Yams. I am on my way to fix this.

Here is the simplest possible example that generates a user interface (using dialog and python-dialog) to input data described by a Yams data model.

First, let's write a function that builds the data model:

def mk_datamodel():
    from yams.buildobjs import EntityType, RelationDefinition, Int, String
    from yams.reader import build_schema_from_namespace

    class Question(EntityType):
        number = Int()
        text = String()

    class Form(EntityType):
        title = String()

    class in_form(RelationDefinition):
        subject = 'Question'
        object = 'Form'
        cardinality = '*1'

    return build_schema_from_namespace(vars().items())

Here is what you get using graphviz or xdot to display the schema of that data model with:

import os
from yams import schema2dot

datamodel = mk_datamodel()
schema2dot.schema2dot(datamodel, '/tmp/toto.dot')
os.system('xdot /tmp/toto.dot')
http://www.logilab.org/file/87002?vid=download

To make a step in the direction of genericity, let's add a class that abstracts the dialog API:

class InterfaceDialog:
    """Dialog-based Interface"""
    def __init__(self, dlg):
        self.dlg = dlg

    def input_list(self, invite, options) :
        assert len(options) != 0, str(invite)
        choice = self.dlg.radiolist(invite, list=options, selected=1)
        if choice is not None:
            return choice.lower()
        else:
            raise Exception('operation cancelled')

    def input_string(self, invite, default):
        return self.dlg.inputbox(invite, init=default).decode(sys.stdin.encoding)

And now let's put everything together:

datamodel = mk_datamodel()

import dialog
ui = InterfaceDialog(dialog.Dialog())
ui.dlg.setBackgroundTitle('Dialog Interface with Yams')

objs = []
for entitydef in datamodel.entities():
    if entitydef.final:
        continue
    obj = {}
    for attr in entitydef.attribute_definitions():
        if attr[1].type in ('String','Int'):
            obj[str(attr[0])] = ui.input_string('%s.%s' % (entitydef,attr[0]), '')
    try:
        entitydef.check(obj)
    except Exception, exc:
        ui.dlg.scrollbox(str(exc))

print objs
http://www.logilab.org/file/87001?vid=download

The result is a program that will prompt the user for the title of a form and the text/number of a question, then enforce the type constraints and display the inconsistencies.

The above is very simple and does very little, but if you read the documentation of Yams and if you think about generating the UI with Gtk or Qt instead of dialog, or if you have used the form mechanism of CubicWeb, you'll understand that this proof of concept opens a door to a lot of possibilities.

I will come back to this topic in a later article and give an example of integrating the above with pigg, a simple MVC library for Gtk, to make the programming of user-interfaces even more declarative and bug-free.


Drawing UML diagrams with Python

2011/09/26 by Nicolas Chauvat
http://www.umlgraph.org/doc/seq-eg.gif?vid=download

It started with a desire to draw diagrams of hierarchical systems with Python. Since this is similar to what we do in CubicWeb with schemas of the data model, I read the code and realized we had that graph submodule in the logilab.common library. This module uses dot from graphviz as a backend to draw the diagrams.

Reading about UML diagrams drawn with GraphViz, I learned about UMLGraph, that uses GNU Pic to draw sequence diagrams. Pic is a language based on groff and the pic2plot tool is part of plotutils (apt-get install plotutils). Here is a tutorial. I have found some Python code wrapping pic2plot available as plugin to wikipad. It is worth noticing that TeX seems to have a nice package for UML sequence diagrams called pgf-umlsd.

Since nowadays everything is moving into the web browser, I looked for a javascript library that does what graphviz does and I found canviz which looks nice.

If (only) I had time, I would extend pyreverse to draw sequence diagrams and not only class diagrams...


Setting up my Microsoft Natural Keyboard under Debian Squeeze

2011/06/08 by Nicolas Chauvat

I upgraded to Debian Squeeze over the week-end and it broke my custom Xmodmap. While I was fixing it, I realized that the special keys of my Microsoft Natural keyboard that were not working under Lenny were now functionnal. The only piece missing was the "zoom" key. Here is how I got it to work.

I found on the askubuntu forum an solution to the same problem, that is missing the following details.

To find which keysym to map, I listed input devices:

$ ls /dev/input/by-id/
usb-Logitech_USB-PS.2_Optical_Mouse-mouse        usb-Logitech_USB-PS_2_Optical_Mouse-mouse
usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse  usb-Microsoft_Natural??_Ergonomic_Keyboard_4000-event-kbd

then used evtest to find the keysym:

$ evtest /dev/input/by-id/usb-Microsoft*

then used udevadm to find the identifiers:

$ udevadm info --export-db | less

then edited /lib/udev/rules.d/95-keymap.rules to add:

ENV{ID_VENDOR}=="Microsoft", ENV{ID_MODEL_ID}=="00db", RUN+="keymap $name microsoft-natural-keyboard-4000"

in the section keyboard_usbcheck

and created the keymap file:

$ cat /lib/udev/keymaps/microsoft-natural-keyboard-4000
0xc022d pageup
0xc022e pagedown

then loaded the keymap:

$ /lib/udev/keymap /dev/input/by-id/usb-Microsoft_Natural®_Ergonomic_Keyboard_4000-event-kbd /lib/udev/keymaps/microsoft-natural-keyboard-4000

then used evtest again to check it was working.

Of course, you do not have to map the events to pageup and pagedown, but I found it convenient to use that key to scroll up and down pages.

Hope this helps :)


SemWeb.Pro - first french Semantic Web conference, Jan 17/18 2011

2010/09/21 by Nicolas Chauvat

SemWeb.Pro, the first french conference dedicated to the Semantic Web will take place in Paris on January 17/18 2011.

One day of talks, one day of tutorials.

Want to grok the Web 3.0? Be there.

Something you want to share? Call for papers ends on October 15, 2010.

http://www.semweb.pro/semwebpro.png