show 315 results

Blog entries

  • InfoLab Rennes - 17 décembre

    2013/12/18 by Arthur Lutz

    InfoLab Rennes - 17 décembre

    Le mardi 17 décembre, nous avons participé à la 4ème rencontre du groupe national infolab à Rennes. Voici quelques notes et reflexions prises à cette occasion. La journée a été dense, donc vous ne trouverez que des bribes des sujets dans ce compte rendu.

    http://www.fing.org/local/cache-vignettes/L680xH165/_info_lab_V3_logo_petit-d6f63.jpg

    Présentation générale le matin

    Une présentation générale de la mission "infolab" menée par le Fing a permis d'initier la réflexion et la discussion sur ce qu'est un infolab. Sarah Labelle (Université Paris XIII), Amandine Brugières (Poitiers), Claire Gallon (Nantes, Libertic), Simon Chignard (Rennes), Charles Nepote (Marseille), et Thierry Marcou (Paris) se sont succédé pour expliquer les réflexions et outils en cours d'élaboration. Nous avons noté :

    • une liste de 150 outils répertoriés pour aider à manipuler les données,
    • un prototype de méthodologie,
    • des documents récapitulatifs sur les différents métiers autour de la donnée.

    L'assemblée se pose la question de comment rendre accessible les technologies, les données, les outils. Il nous semble qe cette démarche n'est possible qu'en ayant des mécanismes transparents, reproductibles et collaboratifs. Nous y voyons donc les principes de "logiciel libre", des "standards" et des "outils collaboratifs". Comment rendre le traitement de la donnée reproductible et transparent ?

    À Logilab, nous avons adoptés les outils suivants pour traiter la données :

    • CubicWeb (en python) avec un certain nombre de cubes (modules type plugins)
    • les standards du web sémantique pour faire de la publication et de l'échange de données (publication de dumps, negociation de contenu et sparql endpoints),
    • les outils de versionning et de collaboration (en logiciel libre) : mercurial qui permettent une co-construction décentralisée sur du code source, mais aussi sur certaines données (voir par exemple les jeux de données publié sur github).

    Au sujet de l'annuaire des outils : comporte-t-il une évaluation de l'accessibilité ? D'un outil WYSIWYG à un outil de programmation... quelle grille de notation ? Faut-il faire son propre graphisme ou est-ce "configurable" sans compétence... Grille d'évaluation aussi sur l'autonomie de l'outil ? Par exemple utiliser Google Drive pose des questions des droits sur les données (exemple récent sur la propriété des données lorsqu'elles sont affichées sur une carte google à travers l'API). Dans le domaine du logiciel libre, avec lequel nous pouvons établir un bon nombre de parallèles, il existe des méthodes formelles d'évaluation.

    D'autres questions ont été abordées :

    • stockage et pérennité des démarches et des données : dans l'industrie logicielle une formalisation pertinente en rapport avec cette question est le semantic versionning qui permet d'établir une traçabilité. Sur l'archivage, de nombreuses solutions sont envisageables mais pas forcément formalisées (stockage P2P, hébergement mutualisé, etc).
    • le contrôle d'accès : qui accède comment, comment partage-t-on de manière sécurisée ? Ceci nous fait penser aux études menées par le MIT sur leur projet OpenPDS.
    • comment rendre le crowdsourcing efficace ? Des outils comme CrowdCarfting (PyBossa en Python) permettraient de "simplement" définir une application de crowdsourcing (eg. cartographie, annotation d'image, classement d'image, OCR collaboratif, etc.) mais comment faire le lien avec les données "officielles" ?

    Atelier l'après-midi

    Suite à une visite du labfab de Rennes, nous avons participé aux ateliers, étant deux personnes de chez Logilab, nous avons pu participer à trois ateliers :

    • travail sur la charte des infolabs,
    • datavisualisation et réflexions autour des données,
    • comment mener une campagne de crowdsourcing et sur quels types de données.

    Dans l'atelier sur le crowdsourcing, nous avons parlé rapidement de CKAN et http://datahub.io/ qui sont des moteurs de recherche sur les jeux de données ouverts.

    La suite

    Nous avons participé à DataPride (à Nantes) et comptons participer dans le futur à DataLab (à Nantes) et DataShacker (à Paris), s'agit-il d'initiatives "compatibles" avec les principes des infolabs ? Sont-ce des infolabs ? La suite de l'initiative nous le dira sûrement.

    Les prochaines rencontres Infolab auront probablement lieu à Bordeaux en janvier et à Paris lors de Futur en Seine (du 12 au 15 juin : au CNAM, à la Gaité Lyrique, au Square Emile Chautemps).


  • Lecture de données tabulées avec Numpy -- Retour d'expérience sur dtype

    2013/12/17 by Damien Garaud

    Ce billet est un petit retour d'expérience sur l'utilisation de Numpy pour lire et extraire des données tabulées depuis des fichiers texte.

    Chaque section, hormis les objectifs ou la conclusion, correspond soit à une difficulté rencontrée, une remarque technique, des explications et références vers la documentation officielle sur un point précis qui m'a fait patauger quelques temps. Il y a de forte chance, pour certains d'entre vous, que les points décrits ici vous paraissent évidents, que vous vous disiez "mais qui ne sait pas ça ?!". J'étais moi-même le premier étonné, depuis que je connais Numpy, de ne pas savoir ce genre de choses. Je l'étais moins quand autour de moi, mes camarades ne semblaient pas non plus connaître les petites histoires numpysiennes que je vais vous conter.

    http://www.logilab.org/file/203839/raw/numpylogo.png

    Objectifs

    Le Pourquoi et le Où on va au fait ?

    J'avais sous la main des fichiers aux données tabulées, type CSV, où les types de données par colonne étaient clairement identifiés. Je ne souhaitais pas passer du temps avec le module csv de la bibliothèque standard à convertir chaque élément en type de base, str, flottants ou dates. Numpy étant déjà une dépendance du projet, et connaissant la fonction np.genfromtxt, j'ai évidemment souhaité l'utiliser.

    Il était nécessaire de ne lire que certaines colonnes. Je souhaitais associer un nom à chaque colonne. L'objectif était ensuite d'itérer sur ces données ligne par ligne et les traiter dans des générateurs Python. Je n'utilise pas ici Numpy pour faire des opérations mathématiques sur ces tableaux à deux dimensions avec des types hétérogènes. Et je ne pense d'ailleurs pas qu'il soit pertinent d'utiliser ce type de tableau pour faire ces opérations.

    dtypes différents, str et extraction de chaînes vides

    On utilise ici l'argument dtype des fonctions telles que np.genfromtxt pour lire des fichiers tabulés dont les colonnes sont de types différents.

    Attention au dtype à passer à np.genfromtxt ou np.recfromtxt quand on parse des données tabulée (file ou stream). Pour parser une colonne de chaînes de caratères, lui passer [('colname', str)] renvoie des chaînes vides si les autres dtypes sont de types différents.

    Il faut préciser la taille :

    dtype=[('colname', str, 10)]
    # or
    dtype=[('colname', 'S10')]
    

    Ou alors prendre un "vrai" objet str Python :

    dtype=[('colname', object)]
    

    aussi équivalent à:

    dtype=[('colname', 'object')]
    

    Et oui, je suis littéralement tombé sur l'évidence, les "types Numpy", c'est du type C. Et les chaînes, c'est du char * et il y a donc besoin de la taille. La solitude s'est fait moindre quand j'ai su que je n'étais pas le seul à être tombé sur des données tronquées voire vides.

    dtype et tableau à zéro dimension

    Attention au tableau Numpy 0D quand le contenu tabulé à parser n'a qu'une seule ligne (cas d'un np.[rec]array avec plusieurs dtypes). Impossible d'itérer sur les éléments puisque dimension nulle.

    Supposons que vous ayez un fichier tabulé d'une seule ligne :

    Name,Play,Age
    Coltrane,Saxo,28
    

    J'utilise np.genfromtxt en précisant le type des colonnes que je souhaite récupérer (je ne prends pas en compte ici la première ligne).

    data = np.genfromtxt(filename, delimiter=',',
                         dtype=[('name', 'S12'), ('play', object), ('age', int)],
                         skip_header=1)
    

    Voici la représentation de mon array :

    array(('Coltrane', 'Saxo', 28),
        dtype=[('name', 'S12'), ('play', 'O'), ('age', '<i8')])
    

    Si dans votre code, vous avez eu la bonne idée de parcourir vos données avec :

    for name, instrument, age in data:
        # ...
    

    vous pourrez obenir un malheureux TypeError: 'numpy.int64' object is not iterable par exemple. Vous n'avez pas eu de chance, votre tableau Numpy est à zéro dimension et une shape nulle (i.e. un tuple vide). Effectivement, itérer sur un objet de dimension nulle n'est pas chose aisée. Ce que je veux, c'est un tableau à une dimension avec un seul élément (ici un tuple avec mes trois champs) sur lequel il est possible d'itérer.

    Pour cela, faire:

    >>> print data
    array(('Coltrane', 'Saxo', 28),
          dtype=[('name', 'S12'), ('play', 'O'), ('age', '<i8')])array(('babar', 42.), dytpe=[('f0', 'S5'), ('f1', '<f8')])
    >>> print data.shape, data.ndim
    (), 0
    >>> data = data[np.newaxis]
    >>> print data.shape, data.ndim
    (1,), 1
    

    dtype et str : chararray ou ndarray de strings ?

    Pour les chararray, lire help(np.chararray) ou http://docs.scipy.org/doc/numpy/reference/generated/numpy.chararray.html. En particulier:

    The chararray class exists for backwards compatibility with Numarray, it is not recommended for new development. Starting from numpy 1.4, if one needs arrays of strings, it is recommended to use arrays of dtype object_, string_ or unicode_, and use the free functions in the numpy.char module for fast vectorized string operations.

    On fera donc la distinction entre:

    # ndarray of str
    na = np.array(['babar', 'celeste'], dtype=np.str_)
    # chararray
    ca = np.chararray(2)
    ca[0], ca[1] = 'babar', 'celeste'
    

    Le type de tableau est ici différent : np.ndarray pour le premier et np.chararray pour le second. Malheureusement pour np.recfromtxt et en particulier pour np.recarray, si on transpose le label de la colonne en tant qu'attribut, np.recarray il est transformé en chararray avec le bon type Numpy --- |S7 dans notre cas --- au lieu de conserver un np.ndarray de type |S7.

    Exemple :

    from StringIO import StringIO
    rawtxt = 'babar,36\nceleste,12'
    a = np.recfromtxt(StringIO(rawtxt), delimiter=',', dtype=[('name', 'S7'), ('age', int)])
    print(type(a.name))
    

    Le print rend bien un objet de type chararray. Alors que :

    a = np.genfromtxt(StringIO(rawtxt), delimiter=',', dtype=[('name', 'S7'), ('age', int)])
    print(type(a['name']))
    

    affiche ndarray. J'aimerais que tout puisse être du même type, peu importe la fonction utilisée. Au vue de la documentation et de l'aspect déprécié du type charray, on souhaiterait avoir que du ndarray de type np.str. J'ai par ailleurs ouvert le ticket Github 3993 qui n'a malheureusement que peu de succès :-(

    Tableau de chaînes : quel dtype ?

    Si certains se demandent quoi mettre pour représenter le type "une chaîne de caractères" dans un tableau numpy, ils ont le choix :

    np.array(['coltrane', 'hancock'], dtype=np.str)
    np.array(['coltrane', 'hancock'], dtype=np.str_)
    np.array(['coltrane', 'hancock'], dtype=np.string_)
    np.array(['coltrane', 'hancock'], dtype='S')
    np.array(['coltrane', 'hancock'], dtype='S10')
    np.array(['coltrane', 'hancock'], dtype='|S10')
    

    Les questions peuvent être multiples : est-ce la même chose ? pourquoi tant de choses différentes ? Pourquoi tant de haine quand on lit la doc Numpy et que l'info ne saute pas aux yeux ? À savoir que le tableau construit sera identique dans chacun des cas. Il existe peut-être même d'autres moyens de construire un tableau de type identique en lui passant encore un n-ième argument dtype différent.

    • np.str représente le type str de Python. Il est converti automatiquement en type chaines de caractère Numpy dont la longueur correspond à la longueur maximale rencontrée.
    • np.str_ et np.string_ sont équivalents et représentent le type "chaîne de caractères" pour Numpy (longueur = longueur max.).
    • Les trois autres utilisent la représentation sous forme de chaîne de caractères du type np.string_.
      • S ne précise pas la taille de la chaîne (Numpy prend donc la chaîne la plus longue)
      • S10 précise la taille de la chaîne (données tronquées si la taille est plus petite que la chaîne la plus longue)
      • |S10 est strictement identique au précédent. Il faut savoir qu'il existe cette notation <f8 ou >f8 pour représenter un flottant. Les chevrons signifient little endian ou big endian respectivement. Le | sert à dire "pas pertinent". Source: la section typestr sur la page http://docs.scipy.org/doc/numpy/reference/arrays.interface.html

    À noter que j'ai particulièrement apprécié l'utilisation d'un symbole pour spécifier une information non pertinente --- depuis le temps que je me demandais ce que voulait bien pouvoir dire ce pipe devant le 'S'.

    Conclusion (et pourquoi pas pandas ?)

    http://www.logilab.org/file/203841/raw/pandas_logo.png

    Pandas, bibliothèque Python d'analyse de données basée sur Numpy, propose, via sa fonction read_csv, le même genre de fonctionnalités. Il a l'avantage de convertir les types par colonne sans lui donner d'information de type, qu'on lise toutes les colonnes ou seulement quelques unes. Pour les colonnes de type "chaîne de caractères", il prend un dtype=object et n'essaie pas de deviner la longueur maximale pour le type np.str_. Vous ne rencontrerez donc pas "le coup des chaînes vides/tronquées" comme avec dtype='S'.

    Je ne m'étalerai pas sur tout le bien que je pense de cette bibliothèque. Je vous invite par ailleurs à lire/ parcourir un billet de novembre qui expose un certain nombre de fonctionnalités croustillantes et accompagné d'un IPython Notebook.

    Et pourquoi pas Pandas ? Il ne me semble pas pertinent de dépendre d'une nouvelle bibliothèque, aussi bien soit-elle, pour une fonction, aussi utile soit-elle. Pandas est un projet intéressant, mais jeune, qui ne se distribue pas aussi bien que Numpy pour l'instant. De plus, le projet sur lequel je travaillais utilisait déjà Numpy. Je n'avais besoin de rien d'autre pour réaliser mon travail, et dépendre de Pandas ne me semblait pas très pertinent. Je me suis donc contenté des fonctions np.{gen,rec}fromtxt qui font très bien le boulot, avec un dtype comme il faut, tout en retenant les boulettes que j'ai faites.


  • A retrospective of 10 years animating the pylint free software projet

    2013/11/25 by Sylvain Thenault

    was the topic of the talk I gave last saturday at the Capitol du Libre in Toulouse.

    Here are the slides (pdf) for those interested (in french). A video of the talk should be available soon on the Capitol du Libre web site. The slides are mirrored on slideshare (see below):


  • Retrieve Quandl's Data and Play with a Pandas

    2013/10/31 by Damien Garaud

    This post deals with the Pandas Python library, the open and free access of timeseries datasets thanks to the Quandl website and how you can handle datasets with pandas efficiently.

    http://www.logilab.org/file/186707/raw/scrabble_data.jpg http://www.logilab.org/file/186708/raw/pandas_peluche.jpg

    Why this post?

    There has been a long time that I want to play a little with pandas. Not an adorable black and white teddy bear but the well-known Python Data library based on Numpy. I would like to show how you can easely retrieve some numerical datasets from the Quandl website and its API, and handle these datasets with pandas efficiently trought its main object: the DataFrame.

    Note that this blog post comes with a IPython Notebook which can be found at http://nbviewer.ipython.org/url/www.logilab.org/file/187482/raw/quandl-data-with-pandas.ipynb

    You also can get it at http://hg.logilab.org/users/dag/blog/2013/quandl-data-pandas/ with HG.

    Just do:

    hg clone http://hg.logilab.org/users/dag/blog/2013/quandl-data-pandas/
    

    and get the IPython Notebook, the HTML conversion of this Notebook and some related CSV files.

    First Step: Get the Code

    At work or at home, I use Debian. A quick and dumb apt-get install python-pandas is enough. Nevertheless, (1) I'm keen on having a fresh and bloody upstream sources to get the lastest features and (2) I'm trying to contribute a little to the project --- tiny bugs, writing some docs. So I prefer to install it from source. Thus, I pull, I do sudo python setup.py develop and a few Cython compiling seconds later, I can do:

    import pandas as pd
    

    For the other ways to get the library, see the download page on the official website or see the dedicated Pypi page.

    Let's build 10 brownian motions and plotting them with matplotlib.

    import numpy as np
    pd.DataFrame(np.random.randn(120, 10).cumsum(axis=0)).plot()
    

    I don't very like the default font and color of the matplotlib figures and curves. I know that pandas defines a "mpl style". Just after the import, you can write:

    pd.options.display.mpl_style = 'default'
    
    http://www.logilab.org/file/186714/raw/Ten-Brownian-Motions.png

    Second Step: Have You Got Some Data Please ?

    Maybe I'm wrong, but I think that it's sometimes a quite difficult to retrieve some workable numerial datasets in the huge amount of available data over the Web. Free Data, Open Data and so on. OK folks, where are they ? I don't want to spent my time to through an Open Data website, find some interesting issues, parse an Excel file, get some specific data, mangling them to get a 2D arrays of floats with labels. Note that pandas fits with these kinds of problem very well. See the IO part of the pandas documentation --- CSV, Excel, JSON, HDF5 reading/writing functions. I just want workable numerical data without making effort.

    A few days ago, a colleague of mine talked me about Quandl, a website dedicated to find and use numerical datasets with timeseries on the Internet. A perfect source to retrieve some data and play with pandas. Note that you can access some data about economics, health, population, education etc. thanks to a clever API. Get some datasets in CSV/XML/JSON formats between this date and this date, aggregate them, compute the difference, etc.

    Moreover, you can access Quandl's datasets through any programming languages, like R, Julia, Clojure or Python (also available plugins or modules for some softwares such as Excel, Stata, etc.). The Quandl's Python package depends on Numpy and pandas. Perfect ! I can use the module Quandl.py available on GitHub and query some datasets directly in a DataFrame.

    Here we are, huge amount of data are teasing me. Next question: which data to play with?

    Third Step: Give some Food to Pandas

    I've already imported the pandas library. Let's query some datasets thanks to the Quandl Python module. An example inspired by the README from the Quandl's GitHub page project.

    import Quandl
    data = Quandl.get('GOOG/NYSE_IBM')
    data.tail()
    

    and you get:

                  Open    High     Low   Close    Volume
    Date
    2013-10-11  185.25  186.23  184.12  186.16   3232828
    2013-10-14  185.41  186.99  184.42  186.97   2663207
    2013-10-15  185.74  185.94  184.22  184.66   3367275
    2013-10-16  185.42  186.73  184.99  186.73   6717979
    2013-10-17  173.84  177.00  172.57  174.83  22368939
    

    OK, I'm not very familiar with this kind of data. Take a look at the Quandl website. After a dozen of minutes on the Quandl website, I found this OECD murder rates. This page shows current and historical murder rates (assault deaths per 100 000 people) for 33 countries from the OECD. Take a country and type:

    uk_df = Quandl.get('OECD/HEALTH_STAT_CICDHOCD_TXCMILTX_GBR')
    

    It's a DataFrame with a single column 'Value'. The index of the DataFrame is a timeserie. You can easily plot these data thanks to a:

    uk_df.plot()
    
    http://www.logilab.org/file/186711/raw/GBR-oecd-murder-rates.png

    See the other pieces of code and using examples in the dedicated IPython Notebook. I also get data about unemployment in OECD for the quite same countries with more dates. Then, as I would like to compare these data, I must select similar countries, time-resample my data to have the same frequency and so on. Take a look. Any comment is welcomed.

    So, the remaining content of this blog post is just a summary of a few interesting and useful pandas features used in the IPython notebook.

    • Using the timeseries as Index of my DataFrames
    • pd.concat to concatenate several DataFrames along a given axis. This function can deal with missing values if the Index of each DataFrame are not similar (this is my case)
    • DataFrame.to_csv and pd.read_csv to dump/load your data to/from CSV files. There are different arguments for the read_csv which deals with dates, mising value, header & footer, etc.
    • DateOffset pandas object to deal with different time frequencies. Quite useful if you handle some data with calendar or business day, month end or begin, quarter end or begin, etc.
    • Resampling some data with the method resample. I use it to make frequency conversion of some data with timeseries.
    • Merging/joining DataFrames. Quite similar to the "SQL" feature. See pd.merge function or the DataFrame.join method. I used this feature to align my two DataFrames along its Index.
    • Some Matplotlib plotting functions such as DataFrame.plot() and plot(kind='bar').

    Conclusion

    I showed a few useful pandas features in the IPython Notebooks: concatenation, plotting, data computation, data alignement. I think I can show more but this could be occurred in a further blog post. Any comments, suggestions or questions are welcomed.

    The next 0.13 pandas release should be coming soon. I'll write a short blog post about it in a few days.

    The pictures come from:


  • PyConFr

    2013/10/28 by Alain Leufroy
    http://www.pycon.fr/2013_static/pyconfr/images/banner.png

    Logilab était au rendez-vous annuel des pythonistes de tous genres : la conférence PYCONFR organisée par l'AFPy, qui avait lieu cette année à l'université de Strasbourg.

    Si vous n'y étiez pas, voici un petit aperçu de ce que vous avez raté, sachant que le programme était chargé.

    Où en est le packaging ?

    Nos amis de Unlish ont fait une présentation de l'état actuel de la distribution de paquets python.

    Après une présentation générale de PyPI, ils ont décrit les derniers changements qui ont permis d'améliorer la disponibilité des paquets python.

    L'information la plus importante concernait Wheel qui est le format désormais recommandé pour fournir des binaires précompilés. Fini les .egg de setuptools ! Ceci devrait faire sourir plus d'un mainteneur de paquet ou administrateur système.

    Wheel est un format de fichier de distribution. Ce format clair et succinct est décrit par la PEP427. Il vise à simplifier la fabrication des paquets pour les distributions de vos OS favoris.

    Les versions récentes de l'installeur pip peuvent gérer les paquets Wheel qui sont compatibles avec le système d'installation décrit dans la PEP376. Il faut toutefois, pour l'instant, dire explicitement à pip de prendre en compte ces fichiers dès qu'ils sont disponibles, grâce à l'option --use-wheel.

    Vous disposez ainsi des avantages de pip (gestion claire et simple des dépendances, freeze, désinstallation, etc.) et ceux d'une distribution de paquets précompilés (installation rapide et simple, environnement de développement non requis, etc.).

    Les paquets Wheel prennent en compte les implementations de python et leurs ABIs. Vous pouvez donc fournir des paquets Wheel (et les signer) facilement pour des versions spécifiques de Jython, Pypy, IronPython, etc.

    $ python setup.py bdist_wheel
    $ pypy setup.py bdist_wheel
    

    Cela ne vous dispense pas de distribuer les sources de votre paquet ;)

    $ python setup.py sdist
    

    Python dans Mercurial

    http://www.selenic.com/hg-logo/logo-droplets-50.png

    Pierre-Yves David et Alexis Métaireau ont fait un petit rappel des trucs vraiment géniaux dans Mercurial comme les revsets et les templates.

    Le coeur de leur présentation concernait l'utilisation de Python pour écrire Mercurial.

    D'après son auteur, Mercurial existe aujourd'hui grâce à Python. En effet Python a permis à Matt Mackall d'écrire une preuve de son concept en à peine deux semaines -- il n'avait pas plus de temps à y dédier donc l'implementation en C n'était pas envisageable.

    Rappelons qu'avant de changer le langage d'implementation il est toujours intéressant de se poser des questions sur les algorithmes utilisés. Nous avons vu quelques exemples d'optimisation en Python qui ont permis de d'accélérer Mercurial, et quelques astuces pour contourner les lenteurs que l'on rencontre avec l'interpréteur CPython (lazy import, low-level access, etc.).

    Les autres avantages notables de l'utilisation de Python viennent de sa flexibilité. Les extensions pour Mercurial peuvent grâce à cela changer le comportement interne de Mercurial. Par exemple largefiles et watchman améliorent grandement la gestion des gros fichiers et la mise à jour des informations du dépôt.

    Hy, lisp on Python

    http://docs.hylang.org/en/latest/_images/hy_logo-smaller.png

    Julien Danjou a présenté une implémentation de Lisp basé sur la VM de Python. En effet Python peut être vu comme un sous-ensemble de Lisp.

    Hy interprète un script écrit dans un dialecte de Lisp et le convertit en arbre syntaxique Python classique, qui est ensuite exécuté par l'interpréteur Python.

    [Python] .py -(parse)---> AST -(compile)-> .pyc -(run)-> python vm
                          /
    [Lisp]   .hy -(parse)/
    

    tip

    hy2py permet de montrer l'équivalent Python d'un script Lisp.

    Il y a donc une grande interopérabilité entre ce qui est implémenté en Hy et ce qui l'est en Python. Aucun souci pour importer les autres modules Python, quels qu'ils soient.

    Hy supporte presque toutes les versions de Python et beaucoup d'interpréteurs, notamment pypy.

    De nombreuses fonctions de common Lisp sont disponibles, et Hy se rapproche de Clojure pour la définition des classes.

    Pour ceux qui sont intéressés par Hy, notez qu'il manque encore quelques petites choses :

    • les cons cells sont en cours de discussion
    • il faudra faire sans les macroexpand pour vous aider dans vos macros
    • les fonctions de Common Lisp ne sont pas toutes présentes
    • le dialect de Lisp nécessite, pour l'instant, de mixer les [...]` et les (...)`, mais ceci devrait changer.
    • Hy n'est pas présent à l'exécution, il y a donc forcément des limitations.

    Python pour la Robotique

    Il y avait une présentation bien sympathique d'une équipe qui participe régulièrement aux championnats de france de robotique.

    Ils utilisent une carte basée sur un SoC ARM sur laquelle ils disposent d'un Gnu/Linux et d'un interpréteur Python (2.7).

    Ils ont codé en C/C++ quelques routines de bas niveau pour un maximum de réactivité. Mise à part cela, tout le reste est en Python, notamment leurs algorithmes pour gérer la stratégie de leurs robots.

    Python leur facilite énormément la vie grâce au prototypage rapide, à la rapidité pour corriger leur code (surtout avec le manque de sommeil durant la compétition), à la souplesse pour simuler en amont, analyser des logs, etc.

    Un Python dans la maison

    http://hackspark.fr/skin/frontend/base/default/images/logo3d_hackspark_small.png

    Il y avait aussi la présentation d'un projet (Hack'Spark!) jeune mais déjà fonctionnel de domotique. La petite démonstration en direct du système était du plus bel effet ;)

    Et, pour moins de 100 euros vous pourrez allumer la lumière chez vous depuis une interface web ! Perso, je m'y mets ce mois ;)

    Framework Graphique Kivy

    http://kivy.org/logos/kivy-logo-black-64.png

    Kivy est entièrement écrit en Python/Cython et utilise OpenGL. Il a donc un très bon support sur les machines récentes (Linux, BSD, MacOs, Android, iOS, Rpi, etc.). Et il n'a rien a envier aux autres frameworks.

    Kivy semble particulièrment pratique pour mener à bien des projets sur les plateformes mobiles comme les téléphones portables et les tablettes (Android et iOS).

    De plus, parmi les outils fournis avec Kivy vous pourrez trouver quelques trucs pour simplifier votre développement :

    • PyJNIus utilise l'interface JNI de la VM Java (via Cython). Il sert de proxy sur les classes Java et vous donne donc accès à l'ensemble de l'API Android.
    • PyObjus est le pendant de PyJNIus pour ObjectiveC sous iOS.
    • Plyer essaie de rassembler en une API commune de plus haut niveau PyJNIus et PyObjus, ce qui permet de coder une seule fois pour les deux plateformes.
    • Buildozer aide à la compilation de projet pour Android de manière plus simple qu'avec Python for Android.

    Nous avons eu droit à une présentation des concepts et comment les mettre en œuvre en direct. Je sens que ça va me simplifier la vie !


  • SaltStack Paris Meetup - some of what was said

    2013/10/09 by Arthur Lutz

    Last week, on the first day of OpenWorldForum 2013, we met up with Thomas Hatch of SaltStack to have a talk about salt. He was in Paris to give two talks the following day (1 & 2), and it was a great opportunity to meet him and physically meet part of the French Salt community. Since Logilab hosted the Great Salt Sprint in Paris, we offered to co-organise the meetup at OpenWorldForum.

    http://saltstack.com/images/SaltStack-Logo.png http://openworldforum.org/static/pictures/Calque1.png

    Introduction

    About 15 people gathered in Montrouge (near Paris) and we all took turns to present ourselves and how or why we used salt. Some people wanted to migrate from BCFG2 to salt. Some people told the story of working a month with CFEngine and meeting the same functionnality in two days with salt and so decided to go for that instead. Some like salt because they can hack its python code. Some use salt to provision pre-defined AMI images for the clouds (salt-ami-cloud-builder). Some chose salt over Ansible. Some want to use salt to pilot temporary computation clusters in the cloud (sort of like what StarCluster does with boto and ssh).

    When Paul from Logilab introduced salt-ami-cloud-builder, Thomas Hatch said that some work is being done to go all the way : build an image from scratch from a state definition. On the question of Debian packaging, some efforts could be done to have salt into wheezy-backports. Julien Cristau from Logilab who is a debian developer might help with that.

    Some untold stories where shared : some companies that replaced puppet by salt, some companies use salt to control an HPC cluster, some companies use salt to pilot their existing puppet system.

    We had some discussions around salt-cloud, which will probably be merged into salt at some point. One idea for salt-cloud was raised : have a way of defining a "minimum" type of configuration which translates into the profiles according to which provider is used (an issue should be added shortly). The expression "pushing states" was often used, it is probably a good way of looking a the combination of using salt-cloud and the masterless mode available with salt-ssh. salt-cloud controls an existing cloud, but Thomas Hatch points to the fact that with salt-virt, salt is becoming a cloud controller itself, more on that soon.

    Mixing pillar definition between 'public' and 'private' definitions can be tricky. Some solutions exist with multiple gitfs (or mercurial) external pillar definitions, but more use cases will drive more flexible functionalities in the future.

    Presentation and live demo

    For those in the audience that were not (yet) users of salt, Thomas went back to explaining a few basics about it. Salt should be seen as a "toolkit to solve problems in a infrastructure" says Thomas Hatch. Why is it fast ? It is completely asynchronous and event driven.

    He gave a quick presentation about the new salt-ssh which was introduced in 0.17, which allows the application of salt recipes to machines that don't have a minion connected to the master.

    The peer communication can be used so as to add a condition for a state on the presence of service on a different minion.

    While doing demos or even hacking on salt, one can use salt/test/minionswarm.py which makes fake minions, not everyone has hundreds of servers in at their fingertips.

    Smart modules are loaded dynamically, for example, the git module that gets loaded if a state installs git and then in the same highstate uses the git modules.

    Thomas explained the difference between grains and pillars : grains is data about a minion that lives on the minion, pillar is data about the minion that lives on the master. When handling grains, the grains.setval can be useful (it writes in /etc/salt/grains as yaml, so you can edit it separately). If a minion is not reachable one can obtain its grains information by replacing test=True by cache=True.

    Thomas shortly presented saltstack-formulas : people want to "program" their states, and formulas answer this need, some of the jinja2 is overly complicated to make them flexible and programmable.

    While talking about the unified package commands (a salt command often has various backends according to what system runs the minion), for example salt-call --local pkg.install vim, Thomas told this funny story : ironically, salt was nominated for "best package manager" at some linux magazine competition. (so you don't have to learn how to use FreeBSD packaging tools).

    While hacking salt, one can take a look at the Event Bus (see test/eventlisten.py), many applications are possible when using the data on this bus. Thomas talks about a future IOflow python module where a complex logic can be implemented in the reactor with rules and a state machine. One example use of this would be if the load is high on X number of servers and the number of connexions Y on these servers then launch extra machines.

    To finish on a buzzword, someone asked "what is the overlap of salt and docker" ? The answer is not simple, but Thomas thinks that in the long run there will be a lot of overlap, one can check out the existing lxc modules and states.

    Wrap up

    To wrap up, Thomas announced a salt conference planned for January 2014 in Salt Lake City.

    Logilab proposes to bootstrap the French community around salt. As the group suggest this could take the form of a mailing list, an irc channel, a meetup group , some sprints, or a combination of all the above. On that note, next international sprint will probably take place in January 2014 around the salt conference.


  • Setup your project with cloudenvy and OpenStack

    2013/10/03 by Arthur Lutz

    One nice way of having a reproducible development or test environment is to "program" a virtual machine to do the job. If you have a powerful machine at hand you might use Vagrant in combination with VirtualBox. But if you have an OpenStack setup at hand (which is our case), you might want to setup and destroy your virtual machines on such a private cloud (or public cloud if you want or can). Sure, Vagrant has some plugins that should add OpenStack as a provider, but, here at Logilab, we have a clear preference for python over ruby. So this is where cloudenvy comes into play.

    http://www.openstack.org/themes/openstack/images/open-stack-cloud-computing-logo-2.png

    Cloudenvy is written in python and with some simple YAML configuration can help you setup and provision some virtual machines that contain your tests or your development environment.

    http://www.python.org/images/python-logo.gif

    Setup your authentication in ~/.cloudenvy.yml :

    cloudenvy:
      clouds:
        cloud01:
          os_username: username
          os_password: password
          os_tenant_name: tenant_name
          os_auth_url: http://keystone.example.com:5000/v2.0/
    

    Then create an Envyfile.yml at the root of your project

    project_config:
      name: foo
      image: debian-wheezy-x64
    
      # Optional
      #remote_user: ec2-user
      #flavor_name: m1.small
      #auto_provision: False
      #provision_scripts:
        #- provision_script.sh
      #files:
        # files copied from your host to the VM
        #local_file : destination
    

    Now simply type envy up. Cloudenvy does the rest. It "simply" creates your machine, copies the files, runs your provision script and gives you it's IP address. You can then run envy ssh if you don't want to be bothered with IP addresses and such nonsense (forget about copy and paste from the OpenStack web interface, or your nova show commands).

    Little added bonus : you know your machine will run a web server on port 8080 at some point, set it up in your environment by defining in the same Envyfile.yml your access rules

    sec_groups: [
        'tcp, 22, 22, 0.0.0.0/0',
        'tcp, 80, 80, 0.0.0.0/0',
        'tcp, 8080, 8080, 0.0.0.0/0',
      ]
    

    As you might know (or I'll just recommend it), you should be able to scratch and restart your environment without loosing anything, so once in a while you'll just do envy destroy to do so. You might want to have multiples VM with the same specs, then go for envy up -n second-machine.

    Only downside right now : cloudenvy isn't packaged for debian (which is usually a prerequisite for the tools we use), but let's hope it gets some packaging soon (or maybe we'll end up doing it).

    Don't forget to include this configuration in your project's version control so that a colleague starting on the project can just type envy up and have a working setup.

    In the same order of ideas, we've been trying out salt-cloud <https://github.com/saltstack/salt-cloud> because provisioning machines with SaltStack is the way forward. A blog about this is next.


  • Rencontre autour de SaltStack lors de l'OpenWorldForum

    2013/09/25 by Arthur Lutz

    Suite à l'organisation du sprint français autour de SaltStack, nous continuons d'essayer de fédérer la communauté française utilisatrice (ou tout simplement curieuse) de solutions de gestion centralisées autour de la technologie Salt (qui est écrit en Python et que nous pouvons donc facilement adapter à nos besoins en contribuant au projet).

    http://openworldforum.org/static/pictures/Calque1.png http://saltstack.com/images/SaltStack-Logo.png

    Au sein de l'OpenWorldForum nous animons un SaltStack meetup / BOF le jeudi 3 octobre de 18h30 à 20h30 avec Thomas Hatch fondateur de SaltStack. La totalité de l’événement (dont le meetup) est gratuit, il suffit de s'inscrire.

    Logilab tiendra un stand le jeudi et le vendredi lors du forum, n'hésitez pas à venir discuter avec nous. Le TDI (Test-Driven Infrastructure), qui consiste à appliquer le TDD (Test-driven development) (développement piloté par les tests) à l'administration système sera un des thèmes de notre présence.


  • DebConf13 report

    2013/09/25 by Julien Cristau

    As announced before, I spent a week last month in Vaumarcus, Switzerland, attending the 14th Debian conference (DebConf13).

    It was great to be at DebConf again, with lots of people I hadn't seen since New York City three years ago, and lots of new faces. Kudos to the organizers for pulling this off. These events are always a great boost for motivation, even if the amount of free time after coming back home is not quite as copious as I might like.

    One thing that struck me this year was the number of upstream people, not directly involved in Debian, who showed up. From systemd's Lennart and Kay, to MariaDB's Monty, and people from upstart, dracut, phpmyadmin or munin. That was a rather pleasant surprise for me.

    Here's a report on the talks and BoF sessions I attended. It's a bit long, but hey, the conference lasted a week. In addition to those I had quite a few chats with various people, including fellow members of the Debian release team.

    http://debconf13.debconf.org/images/logo.png

    Day 1 (Aug 11)

    Linux kernel : Ben Hutchings made a summary of the features added between 3.2 in wheezy and the current 3.10, and their status in Debian (some still need userspace work).

    SPI status : Bdale Garbee and Jimmy Kaplowitz explained what steps SPI is making to deal with its growth, including getting help from a bookkeeper recently to relieve the pressure on the (volunteer) treasurer.

    Hardware support in Debian stable : If you buy new hardware today, it's almost certainly not supported by the Debian stable release. Ideas to improve this :

    • backport whole subsystems: probably not feasible, risk of regressions would be too high
    • ship compat-drivers, and have the installer automatically install newer drivers based on PCI ids, seems possible.
    • mesa: have the GL loader pick a different driver based on the hardware, and ship newer DRI drivers for the new hardware, without touching the old ones. Issue: need to update libGL and libglapi too when adding new drivers.
    • X drivers, drm: ? (it's complicated)

    Meeting between release team and DPL to figure out next steps for jessie. Decided to schedule a BoF later in the week.

    Day 2 (Aug 12)

    Munin project lead on new features in 2.0 (shipped in wheezy) and roadmap for 2.2. Improvements on the scalability front (both in terms of number of nodes and number of plugins on a node). Future work includes improving the UI to make it less 1990 and moving some metadata to sql.

    jeb on AWS and Debian : Amazon Web Services (AWS) includes compute (ec2), storage (s3), network (virtual private cloud, load balancing, ..) and other services. Used by Debian for package rebuilds. http://cloudfront.debian.net is a CDN frontend for archive mirrors. Official Debian images are on ec2, including on the AWS marketplace front page. build-debian-cloud tool from Anders Ingeman et al. was presented.

    openstack in Debian : Packaging work is focused on making things easy for newcomers, basic config with debconf. Advanced users are going to use puppet or similar anyway. Essex is in wheezy, but end-of-life upstream. Grizzly available in sid and in a separate archive for wheezy. This work is sponsored by enovance.

    Patents : http://patents.stackexchange.com, looks like the USPTO has used comments made there when rejecting patent applications based on prior art. Patent applications are public, and it's a lot easier to get a patent application rejected than invalidate a patent later on. Should we use that site? Help build momentum around it? Would other patent offices use that kind of research? Issues: looking at patent applications (and publicly commenting) might mean you're liable for treble damages if the patent is eventually granted? Can you comment anonymously?

    Why systemd? : Lennart and Kay. Pop corn, upstart trolling, nothing really new.

    Day 3 (Aug 13)

    dracut : dracut presented by Harald Hoyer, its main developer. Seems worth investigating replacing initramfs-tools and sharing the maintenance load. Different hooks though, so we'll need to coordinate this with various packages.

    upstart : More Debian-focused than the systemd talk. Not helped by Canonical's CLA...

    dh_busfactor : debhelper is essentially a one-man show from the beginning. Though various packages/people maintain different dh_* tools either in the debhelper package itself or elsewhere. Joey is thinking about creating a debhelper team including those people. Concerns over increased breakage while people get up to speed (joeyh has 10 years of experience and still occasionally breaks stuff).

    dri3000 : Keith is trying to fix dri2 issues. While dri2 fixed a number of things that were wrong with dri1, it still has some problems. One of the goals is to improve presentation: we need a way to sync between app and compositor (to avoid displaying incompletely drawn frames), avoid tearing, and let the app choose immediate page flip instead of waiting for next vblank if it missed its target (stutter in games is painful). He described this work on his blog.

    security team BoF : explain the workflow, try to improve documentation of the process and what people can do to help. http://security.debian.org/

    Day 4 (Aug 14)

    day trip, and conference dinner on a boat from Neuchatel to Vaumarcus

    Day 5 (Aug 15)

    git-dpm : Spent half an hour explaining git, then was rushed to show git-dpm itself. Still, needs looking at. Lets you work with git and export changes as quilt series to build a source package.

    Ubuntu daily QA : The goal was to make it possible for canonical devs (not necessarily people working on the distro) to use ubuntu+1 (dev release). They tried syncing from testing for a while, but noticed bug fixes being delayed: not good. In the previous workflow the dev release was unusable/uninstallable for the first few months. Multiarch made things even more problematic because it requires amd64/i386 being in sync.

    • 12.04: a bunch of manpower thrown at ubuntu+1 to keep backlog of technical debt under control.
    • 12.10: prepare infrastructure (mostly launchpad), add APIs, to make non-canonical people able to do stuff that previously required shell access on central machines.
    • 13.04: proposed migration. britney is used to migrate packages from devel-proposed to devel. A few teething problems at first, but good reaction.
    • 13.10 and beyond: autopkgtest runs triggered after upload/build, also for rdeps. Phased updates for stable releases (rolled out to a subset of users and then gradually generalized). Hook into errors.ubuntu.com to match new crashes with package uploads. Generally more continuous integration. Better dashboard. (Some of that is still to be done.)

    Lessons learned from debian:

    • unstable's backlog can get bad → proposed is only used for builds and automated tests, no delay
    • transitions can take weeks at best
    • to avoid dividing human attention, devs are focused on devel, not devel-proposed

    Lessons debian could learn:

    • keeping testing current is a collective duty/win
    • splitting users between testing and unstable has important costs
    • hooking automated testing into britney really powerful; there's a small but growing number of automated tests

    Ideas:

    • cut migration delay in half
    • encourage writing autopkgtests
    • end goal: make sid to testing migration entirely based on automated tests

    Debian tests using Jenkins http://jenkins.debian.net

    • https://github.com/h01ger/jenkins-job-builder
    • Only running amd64 right now.
    • Uses jenkins plugins: git, svn, log parser, html publisher, ...
    • Has existing jobs for installer, chroot installs, others
    • Tries to make it easy to reproduce jobs, to allow debugging
    • {c,sh}ould add autopkgtests

    Day 6 (Aug 16)

    X Strike Force BoF : Too many bugs we can't do anything about: {mass,auto}-close them, asking people to report upstream. Reduce distraction by moving the non-X stuff to separate teams (compiz removed instead, wayland to discuss...). We should keep drivers as close to upstream as possible. A couple of people in the room volunteered to handle the intel, ati and input drivers.

    reclass BoF

    I had missed the talk about reclass, and Martin kindly offered to give a followup BoF to show what reclass can do.

    Reclass provides adaptors for puppet(?), salt, ansible. A yaml file describes each host:

    • can declare applications and parameters
    • host is leaf in a dag/tree of classes

    Lets you put the data in reclass instead of the config management tool, keeping generic templates in ansible/salt.

    I'm definitely going to try this and see if it makes it easier to organize data we're currently putting directly in salt states.

    release BoF : Notes are on http://gobby.debian.org. Basic summary: "Releasing in general is hard. Releasing something as big/diverse/distributed as Debian is even harder." Who knew?

    freedombox : status update from Bdale

    Keith Packard showed off the free software he uses in his and Bdale's rockets adventures.

    This was followed by a birthday party in the evening, as Debian turned 20 years old.

    Day 7 (Aug 17)

    x2go : Notes are on http://gobby.debian.org. To be solved: issues with nx libs (gpl fork of old x). Seems like a good thing to try as alternative to LTSP which we use at Logilab.

    lightning talks

    • coquelicot (lunar) - one-click secure(ish) file upload web app
    • notmuch (bremner) - need to try that again now that I have slightly more disk space
    • fedmsg (laarmen) - GSoC, message passing inside the debian infrastructure

    Debconf15 bids :

    • Mechelen/Belgium - Wouter
    • Germany (no city yet) - Marga

    Debconf14 presentation : Will be in Portland (Portland State University) next August. Presentation by vorlon, harmoney, keithp. Looking forward to it!

    • Closing ceremony

    The videos of most of the talks can be downloaded, thanks to the awesome work of the video team. And if you want to check what I didn't see or talk about, check the complete schedule.


  • JDEV2013 - Software development conference of CNRS

    2013/09/13 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!


show 315 results