Quantcast
Channel: AFPy's Planet
Viewing all 3409 articles
Browse latest View live

[logilab] Naissance de la communauté Open Science Toulousaine

$
0
0

Ils étaient une vingtaine à se (re)trouver à l’occasion du premier apéritif & barcamp Open Science à Toulouse organisé par Logilab et Hack your PhD. La plupart étaient avant tout curieux de voir qui et quoi se cachaient derrière cette annonce :

un rendez-vous périodique, informel et sympathique a pour but de favoriser les échanges entre tous les acteurs intéressés par un aspect de l’Open Science : Open Data, les rapports Sciences & Société, Open Source, Open Access, Big Data & Data Science, etc.

Curieux souvent parce qu’ils s’étaient reconnus dans l’une ou l’autre – et souvent plusieurs – de ces facettes de l’Open Science sans avoir déjà rencontré l’étiquette Open Science pour autant.

Les échangent se nouent dans la communauté Open Science

Mais alors l’Open Science : c’est quoi ?

Heureusement personne n’a asséné de définition définitive. J’ai tenté de montrer, à travers une brève présentation de Hack your PhD et de Logilab comment l’Open Science est avant tout une démarche d’ouverture dans la pratique de la recherche scientifique qui s’étend au delà du cadre du laboratoire.

L’objectif de la soirée était de permettre à la communauté Open Science locale de se découvrir ; aux acteurs de science ou d’ouverture de faire connaissance. De fait les discussions et prises de contacts informelles allaient bon train autour d’un verre et quelques tapas… et c’est donc à chacun des participants de partager ses échanges sur le thème que fait-on à Toulouse ?

Le fournisseur d’accès associatif tetaneutral nous met à disposition une liste de diffusion à l’adresse open-science-toulouse@lists.tetaneutral.net. Merci à eux ! J’invite vivement les participants à l’apéro à s’y présenter en quelques mots : faites nous part de votre perception de cet événement et partager vos intérêts et projets.

On se retrouvera bientôt pour un prochain événement qui tiendra plus de l’atelier. Quelques suggestion qui sont dores et déjà apparues : un atelier sur les outils pratiques pour être ouvert, un séminaire dans un centre de recherche universitaire, un atelier sur les alignements de données publiques et l’évolutivité des schéma de données avec CubicWeb, …

Vos propositions sont très bienvenues : la communauté Open Science Toulousaine deviendra ce qu’ensemble nous en ferons !

Ce compte rendu a été initialement publié sur le site de hackyourphd : http://hackyourphd.org/2014/02/naissance-de-la-communaute-toulousaine/


[afpyro] AFPyro à Lyon - mercredi 23 avril

$
0
0

Un Afpyro aura lieu le mercredi 23 avril à partir de 20h à l’Antre Autre - 11 rue Terme - 69001 Lyon.

Une présentation sur WTForms sera donnée. WTForms est une librairie permettant de simplifier la gestion des formulaires au sein d’une application web.

L’Antre Autre est un lieu où nous pouvons discuter autour d’un verre, et, pour ceux qui le souhaitent, prendre un repas.

Pour se rendre à l’Antre Autre :

  • en métro : arrêt Hôtel de Ville
  • en bus : lignes C13 et C18 arrêt Mairie du 1er ou lignes 19, C14 et C3 à l’arrêt Terreaux
  • en vélo’v : stations Place Sathonay, Carmélites Burdeau, Place de la paix

[logilab] Deuxième hackathon codes libres de mécanique

$
0
0

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 !

[j-mad] DjangoIsland, parce que les poneys savent nager

$
0
0
Vous êtes djangonautes ? Et vous n’avez pas encore acheté votre billet pour DjangoCon Europe ? Alors peut-être que vous ne le saviez pas. Après tout, même si on a essayé de faire un maximum de com sur le sujet, on n’en fait jamais assez et il est fort possible que vous soyez passé à coté. Donc, [...]

[logilab] Open Science à Toulouse : barcamp sur les Biens Communs

[logilab] Ecriture de liaisons C++ pour Python

$
0
0

Dans le cadre des travaux d'interfaçage de l'application Code_TYMPAN avec du code Python, nous avons réalisé l'étude ci-dessous sur les différents moyens de générer des liaisons Python pour du code C++. Cette étude n'a pas vocation à être exhaustive et s'est concentrée sur les aspects qui nous intéressaient directement pour les travaux susmentionnés.

Solutions existantes

Une recherche des solutions existantes a été effectuée, qui a permis d'obtenir la liste suivante pour une écriture manuelle du code d'interfaçage :

  • Cython, un langage de programmation inspiré de Python, basé sur Pyrex
  • Boost.Python, une librairie C++ de la collection Boost permettant d'écrire des liaisons Python
  • PyBindGen, un outil implémenté en Python et permettant de décrire des liaisons C++ directement dans ce langage
  • Swig, un outil permettant de générer des liaisons C++ pour plusieurs langages de programmation
  • Shiboken, un générateur de code d'enrobage pour des bibliothèques C/C++ basé sur du CPython

Des solutions existent pour automatiser cette écriture. Ce sont des outils qui se basent sur des compilateurs (gcc, clang) pour faire l'analyse grammaticale du code C++ et générer le code d'interfaçage correspondant. Par exemple :

  • XDress, qui permet de générer des fichiers Cython (.pyx, .pxd) à partir de gcc-xml ou de libclang
  • PyBindGen dispose de fonctionnalités permettant de générer des liaisons python à partir de gcc
  • Ce billet explique comment utiliser libclang pour parcourir l'AST d'un code C++ et générer des liaisons Boost.Python

Aspects pris en compte

Cet article est intéressant car il aborde de façon très complète les problématiques découlant de l'écriture de liaisons C++ pour des langages de haut niveau. Il a été écrit lors des travaux de développement de Shiboken.

Dans notre cas, les critères pour le choix d'une solution finale portaient sur différents aspects :

  • Le coût de développement : prise en main de l'outil, quantité de code à écrire pour enrober une classe C++ donnée, coût de l'intégration dans le système de build, degré d'automatisation de la solution, lisibilité du code généré, etc.
  • La gestion de la mémoire : comptage de référence, gestion de la propriété des objets
  • La qualité et l'exhaustivité du support C++ : compatibilité STL, gestion des références et pointeurs, des templates, surcharges d'opérateurs, etc.
  • La pérennité de la solution : technologies mises en œuvre par l'outil, qualité de la documentation, support, taille et degré d'activité de la communauté de développeurs

Solutions envisagées

Swig n'a pas été retenu partant de l'a priori que c'était une solution plutôt lourde et davantage orientée C que C++, constat tiré lors de travaux réalisés par Logilab il y a quelques mois de cela. La solution Boost.Python n'a pas été explorée car notre souhait était de nous rapprocher davantage du Python que du C++. Shiboken semble prometteur, bien que peu documenté et mal référencé (les premières recherches tombent sur d'anciennes pages du projet, donnant l'impression que la dernière release date d'il y a plusieurs années, alors qu'en fait, non). Il a été écarté par manque de temps.

PyBindGen et Cython ont fait l'objet de tests.

La cible des tests a été l'interfaçage de smart pointers, puisque cela correspond à un de nos besoins sur le projet Code_TYMPAN.

Les essais ont été réalisés sur des classes simplifiées:

  • MyElement, classe qui représente un élément à encapsuler dans un smart pointer et hérite de IRefCount qui implémente un comptage de référence
  • SmartPtr, classe smart pointer "maison" de l'application
  • Quelques fonctions de test manipulant des smart pointers SmartPtr

Voici un extrait des en-têtes du code C++:

#ifndef MY_ELEMENT_H
#define MY_ELEMENT_H
#include <iostream>
using namespace std;
#include "SmartPtr.h"

class MyElement : public IRefCount
{
    public:
        MyElement ();
        MyElement (string);
            string Name(){ return _name; }
            virtual ~MyElement ();

    protected:
        string _name;
};
typedef SmartPtr<MyElement> SPMyElement;
#endif

#ifndef SMART_PTR_H
#define SMART_PTR_H
template <class T> class SmartPtr
{
    public:
        SmartPtr();
        SmartPtr(T*);
        const T* getRealPointer() const;

    protected:
        T* _pObj;
}
#endif

SPMyElement BuildElement();
void UseElement(SPMyElement elt);

Cython

Cet outil offre maintenant un bon support du C++ (globalement depuis la version 0.17). Son avantage est qu'il permet la manipulation d'objets à la fois C++ et Python dans des fichiers Cython.

Utilisation
  • Écriture (facultative) d'un fichier .pxd qui contient une recopie des headers à enrober (avec un lien vers les fichiers): déclarations des types, classes, fonctions...
  • Écriture d'un fichier .pyx qui contient des appels de fonctions, constructions d'objets C ou python. Les fonctions et classes de ce module sont utilisables depuis un script Python
  • Compilation du code Cython décrivant les interfaçages C++, génération et compilation du code C++ correspondant et production d'une librairie Python.

Cython offre un support pour les conteneurs de la STL, les templates, la surcharge de la plupart des opérateurs ("->" non supporté), le passage d'arguments par référence et par pointeur, etc.

Actuellement en version 0.20.1, la dernière release date du 11 février 2014. Les outils Cython sont relativement bien documentés et sa communauté de développeurs est active.

Exemple

Voici le code d'interfaçage Cython correspondant à l'exemple exposé ci-dessus:

setup.py:

from distutils.core import setup
from Cython.Build import cythonize

setup(name='smartptr',
    ext_modules=cythonize('*.pyx',
        ),
)

smartptr.pxd:

from libcpp.string cimport string

cdef extern from "src/SmartPtr.h":
    cdef cppclass SmartPtr[T]:
        SmartPtr()
        SmartPtr(T *)
        T *getRealPointer() # Pas de surcharge de ->. L'accès à l'objet ne peut être qu'explicite

cdef extern from "src/MyElement.h":
    cdef cppclass MyElement:
        MyElement()
        MyElement(string)
        string Name()

cdef extern from "src/Test.h":
    SmartPtr[MyElement] BuildSPElement()
    void UseSPElement(SmartPtr[MyElement])

smartptr.pyx:

# distutils: language = c++
# distutils: libraries = element

cimport smartptr
cimport cython

cdef class PySPMyElement:
    cdef SmartPtr[MyElement] thisptr

    def __cinit__(self, name=""):
        """ PySPMyElement constructor """
        if name == "":
            self.thisptr = SmartPtr[MyElement](new MyElement())
        else:
            self.thisptr = SmartPtr[MyElement](new MyElement(name))

    def get_name(self):
        """ Returns the name of the element """
        return self.thisptr.getRealPointer().Name()

@cython.locals(elt=PySPMyElement)
def build_sp_elt():
    """ Calls the C++ API to build an element """
    elt = PySPMyElement.__new__(PySPMyElement)
    elt.thisptr = BuildSPElement()
    return elt

@cython.locals(elt=PySPMyElement)
def use_sp_elt(elt):
    """ Lends elt to the C++ API """
    UseSPElement(elt.thisptr)

XDress

XDress est un générateur automatique de code d'interfaçage C/C++ écrit en Python, basé sur Cython.

Utilisation
  • On liste dans un fichier xdressrc.py les classes et fonctions à envelopper (il n'est pas nécessaire de mettre la signature, le nom suffit. On peut choisir d'envelopper seulement certaines classes d'un .h).
  • On exécute xdress qui génère les .pyx et .pxd correspondants

XDress permet d'envelopper des conteneurs STL via son générateur stlwrap (les conteneurs à enrober doivent être listés dans le xdressrc.py). A titre d'exemple, les vecteurs sont convertis en numpy array du type contenu.

Ce projet est récent et pas très documenté, mais il semble prometteur.

PyBindGen

Utilisation
  • Écriture d'un script Python qui décrit les classes/fonctions C++ à enrober en s'appuyant sur le module PyBindGen (1) → permet de générer un fichier .cpp
  • Compilation du code C++ généré, avec la librairie du programme à envelopper et génération d'une librairie Python.

Ce processus peut être automatisé:

  • Écriture d'un script Python qui utilise les outils PyBindGen pour lister les modules (headers) à envelopper, les lire et lancer la génération automatique des liaisons c++

ou:

  • Écriture d'un script Python qui utilise les outils PyBindGen pour lister les modules (headers) à envelopper et générer le script Python décrit en (1) (ce qui permettrait une étape intermédiaire pour personnaliser les liaisons)

PyBindGen offre un support pour la STL, l'héritage (multiple), la gestion des exceptions C++ côté Python, la surcharge d'opérateurs, le comptage de référence, la gestion de la propriété des objets. Mais il supporte mal les templates.

Actuellement en version 0.17, la dernière release date du 15 février 2014 (entre autres ajout de la compatibilité Python 3.3).

Exemple

PyBindGen, en l'état, n'offre pas la possibilité d'envelopper simplement des templates, ni des smart pointers "maison" par extension.

Une classe de ce package permet d'envelopper des shared pointers de Boost (boost::shared_ptr). Il serait à priori possible de la modifier légèrement pour enrober les smart pointers de l'application Code_TYMPAN (non testé).

Voici néanmoins à titre d'exemple le code permettant d'envelopper la classe MyElement et des fonctions manipulant non plus des smart pointers mais des 'MyElement *'

Test.h :

MyElement *BuildElement();
void UseElement(MyElement *elt);

smartptr.py :

import pybindgen
import sys
from pybindgen import retval
from pybindgen import param

mod = pybindgen.Module('smartptr')

# File includes
mod.add_include('"src/MyElement.h"')
mod.add_include('"src/Test.h"')

# Class MyElement
MyElement = mod.add_class('MyElement')
MyElement.add_constructor([])
MyElement.add_method('Name', retval('std::string'), [])


# Test functions
# transfer_ownership=False : here Python program keeps the ownership of the element it passes to the C++ API
mod.add_function('UseElement', None, [param('MyElement *', 'elt', transfer_ownership=False)])
# caller_owns_return=True : here Python program will be responsible for destructing the element returned by BuildElement
mod.add_function('BuildElement', retval('MyElement *',  caller_owns_return=True), [])

if __name__ == '__main__':
    mod.generate(sys.stdout)

Boost.Python

Les liaisons Python s'écrivent directement en C++.

C'est un outil très fiable et pérenne, avec de par sa nature un très bon support C++ : gestion de la mémoire, templates, surcharges d'opérateurs, comptage de référence, smart pointers, héritage, etc.

Inconvénient : la syntaxe (en mode templates C++) n'est pas très intuitive.

Conclusion

Les solutions Cython et PyBindGen ont été explorées autour de la problématique d'enrobage de smart pointers. Il en est ressorti que:

  • Il est possible d'enrober facilement des smart pointers Code_TYMPAN en Cython. L'approche qui a été choisie est de manipuler depuis Python les objets C++ directement au travers de smart pointers (les objets Python contenus dans le .pyx encapsulent des objets SmartPtr[T *], agissant donc comme des proxys vers les objets). De cette façon, l'utilisation depuis Python d'un objet C++ incrémente le compteur de référence côté C++ et cela garantit qu'on ne perdra pas la référence à un objet au cours de son utilisation côté Python. Un appel à getRealPointer() pour enrober des fonctions manipulant directement des T * sera toujours possible dans le code Cython au besoin.
  • PyBindGen présente l'intérêt d'offrir des moyens de gérer l'attribution de la propriété des éléments entre C++ et Python (transfer_ownership, caller_owns_return). Malheureusement, il n'offre pas la possibilité d'enrober des smart pointers sans modification de classes PyBindGen, ni d'envelopper des templates.

Par ailleurs, après utilisation de PyBindGen, il nous a semblé que bien qu'il présente des idées intéressantes, sa documentation, ses tutoriels et son support sont trop succints. Le projet est développé par une seule personne et sa viabilité est difficile à déterminer. Cython en revanche offre un meilleur support et plus de fiabilité.

Le choix final s'est donc porté sur Cython. Il a été motivé par un souci d'utiliser un outil fiable limitant les coûts de développement (élimination de PyBindGen), aussi proche de Python que possible (élimination de Boost.Python). Cet outil semble fournir un support C++ suffisant par rapport à nos besoins tels que perçus à ce stade du projet.

De plus si on cherche un moyen de générer automatiquement les liaisons Python, XDress présente l'avantage de permettre l'utilisation de libclang comme alternative à gcc-xml (PyBindGen est basé sur gcc-xml uniquement). Une possibilité serait par ailleurs d'utiliser XDress pour générer uniquement le .pxd et d'écrire le .pyx manuellement.

Une question qui n'a pas été abordée au cours de cette étude car elle ne correspondait pas à un besoin interne, mais qui est néanmoins intéressante est la suivante: est-il possible de dériver depuis Python des classes de base définies en C++ et enveloppées en Cython, et d'utiliser les objets résultants dans l'application C++ ?

[afpyro] Meetup à Grenoble - jeudi 23 janvier

$
0
0

Un meetup Python aura lieu le jeudi 23 janvier à Grenoble à partir de 19h à la Casemate (place Saint Laurent, 38000 Grenoble).

L’agenda provisoire est le suivant:

  • 19h: Intro
  • 19h15: Arthur Vuillard: Tests Unitaires
  • 20h: Mike Bright: Tendances dévelopements pour 2014
  • 20h45: Discussion sur le groupe

Merci de noter que nous aurons une petite salle disponible avec une capacite de 20 personnes. Pour faire en sorte qu’un maximum de personne puisse venir, merci de vous inscrire/désinscrire sur cette page.

La soirée se terminera autour d’un verre sur place ou dans un bar.

[logilab] Pylint 1.2 released!

$
0
0

Once again, a lot of work has been achieved since the latest 1.1 release. Claudiu, who joined the maintainer team (Torsten and me) did a great work in the past few months. Also lately Torsten has backported a lot of things from their internal G[oogle]Pylint. Last but not least, various people contributed by reporting issues and proposing pull requests. So thanks to everybody!

Notice Pylint 1.2 depends on astroid 1.1 which has been released at the same time. Currently, code is available on Pypi, and Debian/Ubuntu packages should be ready shortly on Logilab's acceptance repositories.

Below is the changes summary, check the changelog for more info.

New and improved checks:

  • New message 'eval-used' checking that the builtin function eval was used.
  • New message 'bad-reversed-sequence' checking that the reversed builtin receive a sequence (i.e. something that implements __getitem__ and __len__, without being a dict or a dict subclass) or an instance which implements __reversed__.
  • New message 'bad-exception-context' checking that raise ... from ... uses a proper exception context (None or an exception).
  • New message 'abstract-class-instantiated' warning when abstract classes created with abc module and with abstract methods are instantied.
  • New messages checking for proper class __slots__: 'invalid-slots-object' and 'invalid-slots'.
  • New message 'undefined-all-variable' if a package's __all__ variable contains a missing submodule (#126).
  • New option logging-modules giving the list of module names that can be checked for 'logging-not-lazy'.
  • New option include-naming-hint to show a naming hint for invalid name (#138).
  • Mark file as a bad function when using python2 (#8).
  • Add support for enforcing multiple, but consistent name styles for different name types inside a single module.
  • Warn about empty docstrings on overridden methods.
  • Inspect arguments given to constructor calls, and emit relevant warnings.
  • Extend the number of cases in which logging calls are detected (#182).
  • Enhance the check for 'used-before-assignment' to look for nonlocal uses.
  • Improve cyclic import detection in the case of packages.

Bug fixes:

  • Do not warn about 'return-arg-in-generator' in Python 3.3+.
  • Do not warn about 'abstract-method' when the abstract method is implemented through assignment (#155).
  • Do not register most of the 'newstyle' checker warnings with python >= 3.
  • Fix 'unused-import' false positive with augment assignment (#78).
  • Fix 'access-member-before-definition' false negative with augment assign (#164).
  • Do not crash when looking for 'used-before-assignment' in context manager assignments (#128).
  • Do not attempt to analyze non python file, eg '.so' file (#122).
  • Pass the current python path to pylint process when invoked via epylint (#133).

Command line:

  • Add -i / --include-ids and -s / --symbols back as completely ignored options (#180).
  • Ensure init-hooks is evaluated before other options, notably load-plugins (#166).

Other:

  • Improve pragma handling to not detect 'pylint:*' strings in non-comments (#79).
  • Do not crash with UnknownMessage if an unknown message identifier/name appears in disable or enable in the configuration (#170).
  • Search for rc file in ~/.config/pylintrc if ~/.pylintrc doesn't exists (#121).
  • Python 2.5 support restored (#50 and #62).

Astroid:

  • Python 3.4 support
  • Enhanced support for metaclass
  • Enhanced namedtuple support

Nice easter egg, no?


[gvaroquaux] Google summer of code projects for scikit-learn

$
0
0
I’d like to welcome the four students that were accepted for the GSoC this year: Issam: Extending Neural networks Hamzeh: Sparse Support for Ensemble Methods Manoj: Making Linear models faster Maheshakya: Locality Sensitive Hashing Welcome to all of you. Your submissions were excellent, and you demonstrated a good will to integrate in the project, with its social and coding dynamics. It is [...]

[Biologeek] OpenData et évaluation

$
0
0

[De mémoire] J’aurais aimé que vous soyez là hier lorsque nous avons discuté, en partant de banalités jusqu’aux points de crispation très précis liés à l’OpenData.

Marylise Lebranchu, Ministre de la Décentralisation, de la Réforme de l’État et de la Fonction Publique lors de la Conférence de Paris

Il est peut-être temps d’initier notre gouvernement aux formats ouverts comme les Barcamps ou les OpenSpaces et ainsi que la parole publique cesse d’être une langue morte pour beaucoup de nos concitoyens comme le souhaite si candidement notre ministre. Mais les fauteuils de l’estrade de la Cour des Comptes semblent tellement confortables… et puis il faudrait rester plus d’une heure au contact des citoyens et réutilisateurs de données.

Ce n’est pourtant pas la partie de son discours qui m’a choqué. Alors que ses homologues anglais (Francis Maude) ou irlandais (Brendan Howlin T.D.) évoquaient l’importance de la transparence pour rétablir la confiance, Marylise Lebranchu a bien insisté sur le fait que l’OpenData est également un outil de mesure et d’évaluation pour pouvoir analyser la performance et l’efficacité de l’administration. Et je doute sincèrement que cet angle d’attaque permette d’avoir une approche sincère de la part des services de la puissance publique pour co-construire avec les citoyens.

En fixant des critères d’évaluation, on oriente complètement la réponse qui ne peut plus être innovante. C’est ce qui arrive avec l’école qui tue la créativité par la notation. C’est ce qui arrive avec la compétition sportive qui détruit le plaisir par les classements. C’est ce qui arrivera avec l’OpenData public qui ne pourra plus prendre le risque d’innover, de défricher ce terreau fertile avec les citoyens et se contentera de copier ce qui est considéré comme une réussite, bien souvent à l’étranger. En évaluant, on sanctionne l’échec ce qui crée de la peur et de la frustration. Je rêve d’un OpenData qui commence par rétablir la confiance au sein même de l’administration. Ce n’est qu’en rétablissant cette confiance en interne qu’elle pourra ensuite être transmise aux citoyens. Ce n’est qu’en embrassant une culture (de la donnée) que l’on peut la propager.

Aujourd’hui on n’a pas beaucoup entendu de citoyens.

Rolf Alter, Directeur de la Gouvernance publique et du Développement territorial, OCDE

[Biologeek] Création de coopératives

$
0
0

Coopératives. Le mot semblerait presque désuet. À l’heure où l’économie est aux mains d’une finance high-tech, le mot sonne comme l’écho d’une vision vieillote, celle des utopies fouriéristes et d’un capitalisme soucieux de la condition ouvrière. La première coopérative a en effet vu le jour dans la ville minière du Rochdale, au Royaume-Uni, en 1844. Mais, en dépit de cette origine lointaine, le modèle coopératif n’a rien perdu de sa pertinence et il démontre tous les jours sa modernité.

Une coopérative est une structure de production de biens et de services dans laquelle les salariés sont copropriétaires du capital, codécisionnaires (« un membre, une voix ») et coélecteurs des dirigeants, ces derniers étant responsables devant eux. Une partie des bénéfices est obligatoirement réinvestie dans le développement de la coopérative et une autre est distribuée aux membres associés, sous forme de bénéfices sociaux. Avec l’accord des membres, la coopérative soutient aussi des activités extérieures, dans un esprit d’engagement envers la communauté. Le modèle coopératif est donc une forme d’organisation tournée vers l’intérêt collectif — c’est d’ailleurs à ce titre que l’Onu le défend (2012 Année internationale des coopératives) —, mais son dynamisme, ses capacités entrepreneuriales et ses résultats en font un substitut crédible au capitalisme financier.

Les coopératives emploient aujourd’hui 100 millions de salariés dans le monde, soit 20% de plus que les multinationales. […]

Ce modèle florissant vaut donc la peine d’être examiné. D’autant qu’il donne aux citoyens des leviers d’action sur l’économie, qu’il constitue un puissant outil de redistribution sociale et qu’il résiste mieux aux crises que les autres.

un million de révolutions tranquilles, Bénédicte Manier

Dans la perspective d’une refonte du site internet de scopyleft je m’interroge sur la pertinence d’avoir une partie dédiée à la création d’une SCOP (Société Coopérative et Participative). Il y aurait de la matière à partager sur ce que cela demande en termes administratif, comptable et stratégique. Mais aussi sur notre expérience.

Il y a des personnes qui nous ont contacté individuellement au cours de cette année, comme les happyculteurs, pour répondre ponctuellement à des questions précises relatives à la création et peut-être que cela suffit. Ou peut-être que cette partie du site serait aussi un acte de partage militant. Ou peut-être que cela nécessite un site dédié qui puisse être facilement enrichi par tous ?

Je suis prêt à passer un peu de temps là-dessus mais j’ai besoin de savoir si ça intéresse 2, 20 ou 200 personnes de façon à pouvoir trouver le support approprié. Quelles seraient vos attentes sur la création d’une telle ressource ?

[tshirtman] Kivy image manipulations with Mesh and Textures

$
0
0

If you want to give a little life to interactive (or not) elements, it’s always nice to have more tricks to manipulate images for nifty effects.

One of such ways is mapping a Texture on a special canvas instruction, that will distort your texture based on the position of its points.

[kivy.graphics.Mesh](http://kivy.org/docs/api-kivy.graphics.html#kivy.graphics.Mesh) is such an instruction, and it has a simple interface, if not 100% straightforward, you basically call it this way.

Mesh:
vertices: (x1, y1, s1, v1, x2, y2, s2, v2, x3, y3, s3, v3...)
indices: (1, 2, 3...)
texture: some_texture
mode: some_mode

where all: x mean the horizontal coordinate of a point y mean the vertical coordinate of a point s mean the horizontal position of the texture attached to this point (between 0 and 1) v mean the vertical position of the texture attached to this point (between 0 and 1)

indices is useful if, for some (very good) reason, you don’t want to give the points in the order you’ll use them, or if you want to refer to a point multiple time (this won’t be demonstrated in this blog post, but try to think about a grid mapping, for example), now we will use it in the most simple way, just give the range of your number of points.

the texture needs to be a texture object, you can get such an object by getting the texture property of a [CoreImage](http://kivy.org/docs/api-kivy.core.image.html#kivy.core.image.Image) or an Image (or even a Label, if you want to).

Let’s say we have an image, for example, kivy logo.

from kivy.core.image import Image as CoreImage

texture = CoreImage('data/logo/kivy-icon-512.png').texture

(this will work wherever you are, because kivy look at his images anyway :))

This image is a circle, lets use that to cut it into a virtual pie and assign a part of the texture to each part, we’ll be using the triangle_fan mode of Mesh, that is a perfect fit for such an operation.

# the central point
points = [Window.width / 2, Window.height / 2, .5, .5]

# now go around
    i = 0
    while i < 2 * pi:
        i += 0.01 * pi
        points.extend([
    Window.width / 2 + cos(i) * 100,
    Window.height / 2 + sin(i) * 100,
    .5 + sin(i),
    .5 + cos(i)])

put that in a more complete program, and you get this:

from kivy.app import App
from kivy.lang import Builder
from kivy.core.image import Image as CoreImage
from kivy.properties import ListProperty, ObjectProperty
from kivy.clock import Clock
from kivy.core.window import Window
from math import sin, cos, pi


kv = '''
Widget:
    canvas:
        Color:
            rgba: 1, 1, 1, 1
        Mesh:
            vertices: app.mesh_points
            indices: range(len(app.mesh_points) / 4)
            texture: app.mesh_texture
            mode: 'triangle_fan'
'''


class MeshBallApp(App):
    mesh_points = ListProperty([])
    mesh_texture = ObjectProperty(None)

    def build(self):
        self.mesh_texture = CoreImage('data/logo/kivy-icon-512.png').texture
        Clock.schedule_interval(self.update_points, 0)
        return Builder.load_string(kv)

    def update_points(self, *args):
        points = [Window.width / 2, Window.height / 2, .5, .5]
        i = 0
        while i < 2 * pi:
            i += 0.01 * pi
            points.extend([
                Window.width / 2 + cos(i) * 100,
                Window.height / 2 + sin(i) * 100,
                .5 + cos(i),
                .5 + sin(i)])

        self.mesh_points = points

if __name__ == '__main__':
    MeshBallApp().run()

Now, this is not very impressive, we just have an image, there were much simpler ways to do that!

But now, we can tweek the rendering a lot, lets add some offseting of the texture, some radius change, and some wobbling, with sliders to control all this.

from kivy.app import App
from kivy.lang import Builder
from kivy.core.image import Image as CoreImage
from kivy.properties import ListProperty, ObjectProperty, NumericProperty
from kivy.clock import Clock
from kivy.core.window import Window
from math import sin, cos, pi


kv = '''
BoxLayout:
    Widget:
        canvas:
            Color:
                rgba: 1, 1, 1, 1
            Mesh:
                vertices: app.mesh_points
                indices: range(len(app.mesh_points) / 4)
                texture: app.mesh_texture
                mode: 'triangle_fan'
    BoxLayout:
        orientation: 'vertical'
        size_hint_x: None
        width: 100
        Slider:
            value: app.offset_x
            on_value: app.offset_x = args[1]
            min: -1
            max: 1
        Slider:
            value: app.offset_y
            on_value: app.offset_y = args[1]
            min: -1
            max: 1
        Slider:
            value: app.radius
            on_value: app.radius = args[1]
            min: 10
            max: 1000
        Slider:
            value: app.sin_wobble
            on_value: app.sin_wobble = args[1]
            min: -50
            max: 50
        Slider:
            value: app.sin_wobble_speed
            on_value: app.sin_wobble_speed = args[1]
            min: 0
            max: 50
            step: 1
'''


class MeshBallApp(App):
    mesh_points = ListProperty([])
    mesh_texture = ObjectProperty(None)
    radius = NumericProperty(500)
    offset_x = NumericProperty(.5)
    offset_y = NumericProperty(.5)
    sin_wobble = NumericProperty(0)
    sin_wobble_speed = NumericProperty(0)

    def build(self):
        self.mesh_texture = CoreImage('data/logo/kivy-icon-512.png').texture
        Clock.schedule_interval(self.update_points, 0)
        return Builder.load_string(kv)

    def update_points(self, *args):
        points = [Window.width / 2, Window.height / 2, .5, .5]
        i = 0
        while i < 2 * pi:
            i += 0.01 * pi
            points.extend([
                Window.width / 2 + cos(i) * (self.radius + self.sin_wobble * sin(i * self.sin_wobble_speed)),
                Window.height / 2 + sin(i) * (self.radius + self.sin_wobble * sin(i * self.sin_wobble_speed)),
                self.offset_x + sin(i),
                self.offset_y + cos(i)])

        self.mesh_points = points

if __name__ == '__main__':
    MeshBallApp().run()

which gives us:

Kivy image manipulations with Mesh and Text

Now we are talking!

[cubicweb] What's new in CubicWeb 3.19

$
0
0

New functionalities

  • implement Cross Origin Resource Sharing (CORS) (see #2491768)
  • system_source.create_eid can return a range of IDs, to reduce overhead of batch entity creation

Behaviour Changes

  • The anonymous property of Session and Connection is now computed from the related user login. If it matches the anonymous-user in the config the connection is anonymous. Beware that the anonymous-user config is web specific. Therefore, no session may be anonymous in a repository only setup.

New Repository Access API

Connection replaces Session

A new explicit Connection object replaces Session as the main repository entry point. A Connection holds all the necessary methods to be used server-side (execute, commit, rollback, call_service, entity_from_eid, etc...). One obtains a new Connection object using session.new_cnx(). Connection objects need to have an explicit begin and end. Use them as a context manager to never miss an end:

with session.new_cnx() as cnx:
    cnx.execute('INSERT Elephant E, E name "Babar"')
    cnx.commit()
    cnx.execute('INSERT Elephant E, E name "Celeste"')
    cnx.commit()
# Once you get out of the "with" clause, the connection is closed.

Using the same Connection object in multiple threads will give you access to the same Transaction. However, Connection objects are not thread safe (hence at your own risks).

repository.internal_session is deprecated in favor of repository.internal_cnx. Note that internal connections are now safe by default, i.e. the integrity hooks are enabled.

Backward compatibility is preserved on Session.

dbapi vs repoapi

A new API has been introduced to replace the dbapi. It is called repoapi.

There are three relevant functions for now:

  • repoapi.get_repository returns a Repository object either from an URI when used as repoapi.get_repository(uri) or from a config when used as repoapi.get_repository(config=config).
  • repoapi.connect(repo, login, **credentials) returns a ClientConnection associated with the user identified by the credentials. The ClientConnection is associated with its own Session that is closed when the ClientConnection is closed. A ClientConnection is a Connection-like object to be used client side.
  • repoapi.anonymous_cnx(repo) returns a ClientConnection associated with the anonymous user if described in the config.

repoapi.ClientConnection replaces dbapi.Connection and company

On the client/web side, the Request is now using a repoapi.ClientConnection instead of a dbapi.Connection. The ClientConnection has multiple backward compatible methods to make it look like a dbapi.Cursor and dbapi.Connection.

Sessions used on the Web side are now the same as the ones used Server side. Some backward compatibility methods have been installed on the server side Session to ease the transition.

The authentication stack has been altered to use the repoapi instead of the dbapi. Cubes adding new elements to this stack are likely to break.

New API in tests

All current methods and attributes used to access the repo on CubicWebTC are deprecated. You may now use a RepoAccess object. A RepoAccess object is linked to a new Session for a specified user. It is able to create Connection, ClientConnection and web side requests linked to this session:

access = self.new_access('babar') # create a new RepoAccess for user babar
with access.repo_cnx() as cnx:
    # some work with server side cnx
    cnx.execute(...)
    cnx.commit()
    cnx.execute(...)
    cnx.commit()

with access.client_cnx() as cnx:
    # some work with client side cnx
    cnx.execute(...)
    cnx.commit()

with access.web_request(elephant='babar') as req:
    # some work with web request
    elephant_name = req.form['elephant']
    req.execute(...)
    req.cnx.commit()

By default testcase.admin_access contains a RepoAccess object for the default admin session.

API changes

  • RepositorySessionManager.postlogin is now called with two arguments, request and session. And this now happens before the session is linked to the request.
  • SessionManager and AuthenticationManager now take a repo object at initialization time instead of a vreg.
  • The async argument of _cw.call_service has been dropped. All calls are now synchronous. The zmq notification bus looks like a good replacement for most async use cases.
  • repo.stats() is now deprecated. The same information is available through a service (_cw.call_service('repo_stats')).
  • repo.gc_stats() is now deprecated. The same information is available through a service (_cw.call_service('repo_gc_stats')).
  • repo.register_user() is now deprecated. The functionality is now available through a service (_cw.call_service('register_user')).
  • request.set_session no longer takes an optional user argument.
  • CubicwebTC does not have repo and cnx as class attributes anymore. They are standard instance attributes. set_cnx and _init_repo class methods become instance methods.
  • set_cnxset and free_cnxset are deprecated. The database connection acquisition and release cycle is now more transparent.
  • The implementation of cascading deletion when deleting composite entities has changed. There comes a semantic change: merely deleting a composite relation does not entail any more the deletion of the component side of the relation.
  • _cw.user_callback and _cw.user_rql_callback are deprecated. Users are encouraged to write an actual controller (e.g. using ajaxfunc) instead of storing a closure in the session data.
  • A new entity.cw_linkable_rql method provides the rql to fetch all entities that are already or may be related to the current entity using the given relation.

Deprecated Code Drops

  • The session.hijack_user mechanism has been dropped.
  • EtypeRestrictionComponent has been removed, its functionality has been replaced by facets a while ago.
  • the old multi-source support has been removed. Only copy-based sources remain, such as datafeed or ldapfeed.

[tarek] Un an de course

$
0
0

For once, I'll blog in French - if you want this post translated in English, mail me. It's about Running.

Je cours sérieusement depuis un an. C'est l'heure du bilan.

Mertics Pr0n

Je collecte des statistiques avec ma montre GPS depuis le 6 Août 2013 - donc presque un an aussi. A la louche, 10% de mon activité seulement n'a pas été trackée (course en tapis, fausse manip' au début d'une course) - donc les données que j'ai récupérées sont assez proches de la réalité.

En dix mois environ - ou 40 semaines, J'ai fait 1477 km en 192 séances avec donc une moyenne de 7.6km par séance. Si l'on retire les quelques données parasites comme les séances de 1mn pour cause de fausse manipulation - ou les séances de chauffe qui précèdent une plus longue séance, on est plus proche de séances de 10km en moyenne.

Mais le kilométrage est plus parlant, ca représente une moyenne de 36km par semaine, ce qui est beaucoup en période de compétition. (j'y reviendrais.)

Le temps total passé à courir est de 118h, à une allure moyenne de 4'48"/KM soit environ 12.5 KM/h. L'énergie dépensé est estimée à 92966 calories. Ce calcul calorique est un peu bidon puisque la montre ne connaît pas mon rythme cardiaque (elle pourrait) et ne prend pas en compte le dénivelé.

Mais je viens de commander une ceinture cardio donc dans un an j'aurais des stats plus précises grâce à la collecte du rythme cardique.

Impact sur la santé et l'alimentation

Je suis passé d'un rythme cardique au repos (au réveil) de 70 pulsations à 53. Les petits mal de dos chroniques après une journée penché sur le clavier ont disparus. Mon état général est passé de moyennement motivé pour me lever le matin, crevé le soir à une bonne pêche toute la journée.

Je ne bois quasiment plus d'alcool car je suis très vite saoul (deux bières peuvent suffire). Avant de me mettre au sport c'était parfois 2/3 (bonnes) bières le même soir. La faible tolérance à l'alcool est probablement lié à la chute de poids: je suis passé de 75kg à 60kg pour 1M68. On me dira que c'est mieux pour ma santé mais c'est frustrant ;)

Mon alimentation a pas mal changée aussi: je suis devenu végétarien et je mange peu mais souvent. En gros des petits repas, et plein d'encas toute la journée, comme des graines bien grasses (noix de cajou, noisettes, amandes). Aussi une quantitée anormale de pommes (3/4 par jour en moyenne - Chirac serait ravi). Je bois aussi 1 litre de thé par jour environ - plutôt du thé vert. Je passe donc plus de temps aux toilettes - mais grâce au wifi j'y travaille très bien.

En terme de bobos, je n'ai pas eu de problèmes majeurs. Juste des ongles noirs liés à l'impact des chaussures qui ont disparus une fois que je me suis décidé à porter des chaussures à ma taille - soit une taille de plus vu que les pieds gonflent un peu en course. Je suis aussi adepte de la course pieds nus de temps en temps, ca réveille les sens et à petite dose ca évite les petites blessures.

Le passage à une nouvelle paire de chaussure m'a aussi fait un peu mal aux genoux pendant quelque temps, mais rien de très grave. Quand je lis les histoires horribles sur les forums de course à pied, je me dis que j'ai de la chance globalement.

Pratique en Club

J'ai été très surpris du nombre de licenciés de course à pied, et du dynamise de ce sport en France. Il y a des évènements partout, tout le temps - avec des gens de tous les ages et couches sociales.

Il y a deux types de clubs:

Les clubs qui se prennent très au sérieux - qui s'entraînent principalement sur piste - le genre de club où le coach va te pousser à te surpasser ou te faire une remarque si tu n'as pas fait un sprint à l'arrivée d'une course (!?). La moyenne d'age semble un peu plus jeune.

Le deuxième type: les clubs à la cool, avec des gens de tous niveau et tout age, où l'on boira du vin chaud après le cross.

Je me suis inscris en novembre/décembre dernier à un petit club local, l'Association des Coureurs de Route (ACR) de Dijon - après avoir regardé un peu les clubs existants.

J'essaye de faire un entraînement par semaine avec le club, et le reste tout seul car je suis trop éloigné de Dijon pour y aller plus souvent.

C'est un club à la cool, mais avec quelques coureurs très fort avec qui je progresse.

Compétition

Je me suis pris au jeu des compétitions - ca brise la monotonie des joggings dans son coin.

Le site de la FFA track les courses que je fais en France pour moi, c'est assez bien fait. Voici ma fiche.

J'ai fait aussi deux courses à l'étranger. Un semi-marathon à San Francisco et un 5K à Montreal.

Mes records:

  • 5K: 18mn17s
  • 10K: 37mn45s à Chalon-s-Saone (il faisait 50m de plus, 37mn56s à l'arrivée)
  • semi-marathon: 1h24mn38s au semi de SF

Pas de marathon en compétition encore (une sortie de 32km c'est ma plus longue distance).

Le bilan des compet': au top de ma forme j'ai un niveau "R5" environ (Régional 5 du barême FFA) - en gros je termine en général dans les 10% les plus rapides dans les petites courses locales, mais je ne pourrais jamais faire un "podium" (les 3 premiers).

J'ai le défaut classique du débutant: je pars trop vite et je fini trop lentement. C'est très difficile de conserver ses allures et ne pas se faire emporter par l'adrénaline du départ. J'y travaille.

Depuis le début du printemps, j'enchaine les courses tous les week-ends et je ne me repose plus assez. Tous mes chronos commencent à régresser. Le sur-entraînement est facile à atteindre quand on débute. Pareil, il faut que le métier rentre.

Bilan et suite

La course me convient bien. Ca se goupille bien avec le télé-travail et je suis en meilleur forme physique. C'est une activité qui évacue bien le stress.

Je bloguerais dans un an environ sur ce même sujet, pour voir l'évolution.

[hautefeuille] Distribution d’une application Python sous Windows

$
0
0

Introduction

Même si la majorité des développeurs Python travaillent sur des environnements de développement Unix, il est parfois nécessaire de fournir une distribution d’une application Python sous le système d’exploitation Windows. Ce document constitue davantage une prise de notes qu’un tutoriel complet puisque je passe les éventuelles étapes d’installation de Cython, MinGW, Visual Studio ou Nuitka. J’utilise les versions 32 bits pour l’interpréteur Python 2.7, les packages Python et les compilateurs. J’utilise à la place de MinGW, la distribution TDM-GCC.

Ces méthodes ne servent pas à obfusquer votre code mais à distribuer l’interpréteur Python, les bibliothèques associées et votre application sous forme d’un paquet.

Sous Windows, pour développer, j’utilise

Sublime Text 2.

La distribution Python fournie par ActiveState.

Les paquets Python disponibles sur ce site pour Windows.

Microsoft Visual Studio Express 2008.

Microsoft Visual C++ 2008 Redistributable Package (x86).

Admettons que nous ayons une application Python sous cette forme

Un dossier principal nommé “supershape”.

Un fichier principal main.py résidant dans ce dossier et qui constitue l’application principale.

J’utilise ici une application développée avec l’outil Kivy.

Avec Pyinstaller

On initialise d’abord un fichier de spécifications

pyinstaller --name supershape supershape\main.py

On édite le fichier supershape.spec créé.

Pour un dossier regroupant l’exécutable et les dll, on édite le fichier comme suivant

# -*- mode: python -*-
from kivy.tools.packaging.pyinstaller_hooks import install_hooks
install_hooks(globals())

a = Analysis(['SuperShape\\main.py'],
             pathex=['C:\\Users\\ANTEC\\Documents'],
             hiddenimports=[],
             runtime_hooks=None)
pyz = PYZ(a.pure)
exe = EXE(pyz,
          a.scripts,
          exclude_binaries=True,
          name='supershape.exe',
          debug=False,
          strip=None,
          upx=True,
          console=False )
coll = COLLECT(exe, Tree('C:\\Users\\ANTEC\\Documents\\Supershape'),
               a.binaries,
               a.zipfiles,
               a.datas,
               strip=None,
               upx=True,
               name='supershape')

Pour un exécutable standalone qui regroupe l’interpréteur

# -*- mode: python -*-
from kivy.tools.packaging.pyinstaller_hooks import install_hooks
install_hooks(globals())

a = Analysis(['SuperShape\\main.py'],
             pathex=['C:\\Users\\ANTEC\\Documents'],
             hiddenimports=[],
             runtime_hooks=None)
pyz = PYZ(a.pure)
exe = EXE(pyz,  Tree('C:\\Users\\ANTEC\\Documents\\Supershape'),
          a.scripts,
          a.binaries,
          a.zipfiles,
          a.datas,
          name='supershape.exe',
          debug=False,
          strip=None,
          upx=True,
          console=False )

Enfin on enveloppe le tout par la commande suivante

pyinstaller supershape.spec

Avec Nuikta

On génère la compilation en C++ avec la commande suivante

nuikta --recurse-all main.py

Avec Cython

On transforme le fichier Python en C

cython main.py -o supershape.c --embed

On compile le C avec Visual Studio et son compilateur

cl.exe /nologo /Ox /MD /W3 /GS- /DNDEBUG -Ic:\Python27\include -Ic:\Python27\PC /supershape.c /link /OUT:"supershape.exe" /SUBSYSTEM:CONSOLE /MACHINE:X86 /LIBPATH:c:\Python27\libs /LIBPATH:c:\Python27\PCbuild

[afpyro] AFPyro à Lyon - mercredi 28 mai

$
0
0

Un Afpyro aura lieu le mercredi 28 mai à partir de 20h à l’Antre Autre - 11 rue Terme - 69001 Lyon.

Une présentation sur Celery sera donnée. Celery est un gestionnaire de tâches qui permet de les traiter de manière asynchrone.

L’Antre Autre est un lieu où nous pouvons discuter autour d’un verre, et, pour ceux qui le souhaitent, prendre un repas.

Pour se rendre à l’Antre Autre :

  • en métro : arrêt Hôtel de Ville
  • en bus : lignes C13 et C18 arrêt Mairie du 1er ou lignes 19, C14 et C3 à l’arrêt Terreaux
  • en vélo’v : stations Place Sathonay, Carmélites Burdeau, Place de la paix

[logilab] Quelques pointeurs présentés lors d'un atelier sur le web sémantique à Nantes

$
0
0

À l'appel du DataLab Pays de la Loire, nous avons co-animé (avec Hala Skaf-Molli) un atelier sur le web sémantique à la Cantine Numérique de Nantes.

Voici quelques diapos avec essentiellement des pointeurs pour donner des exemples de réalisations web sémantique mais aussi pour appuyer les concepts présentés. Vous trouverez les diapos de Hala Skaf sur sa page web (dans les prochains jours).

Si vous avez raté cette session et êtes intéressé par le sujet, n'hésitez pas à le faire savoir au DataLab.

http://www.datalab-paysdelaloire.org/auth/public/images/datalab.png

[logilab] Salt April Meetup in Paris (France)

$
0
0

On the 15th of april, in Paris (France), we took part in yet another Salt meetup. The community is now meeting up once every two months.

We had two presentations:

  • Arthur Lutz made an introduction to returners and the scheduler using the SalMon monitoring system as an example. Salt is not only about configuration management Indeed!
  • The folks from Is Cool Entertainment did a presentation about how they are using salt-cloud to deploy and orchestrate clusters of EC2 machines (islands in their jargon) to reproduce parts of their production environment for testing and developement.

More discussions about various salty subjects followed and were pursued in an Italian restaurant (photos here).

In case it is not already in your diary : Thomas Hatch is coming to Paris next week, on Monday the 19th of May, and will be speaking at dotscale during the day and at a Salt meetup in the evening. The Salt Meetup will take place at IRILL (like the previous meetups, thanks again to them) and should start at 19h. The meetup is free and open to the public, but registering on this framadate would be appreciated.

[afpyro] AFPyro à Pau - Jeudi 19 Juin

$
0
0

Un Afpyro aura lieu le Jeudi 19 Juin à partir de 20h au Fablab de Pau

Venez rencontrer et échanger avec la comunauté pythoniste paloise en vous délectant de succulant breuvages!

Fablab

4 rue despourrins

64000 PAU

Voir la map

[sciunto] Pourquoi je soutiens l'April

$
0
0

L'April est une association pionnière en matière de Logiciel Libre. Créée en 1996, elle était une association d'informaticiens souhaitant promouvoir le Logiciel Libre, inspirée par l'éthique du discours de Richard Stallman.

Un peu comme pour des codes sources, certains sont oubliés, d'autres au contraire savent évoluer et s'ouvrir au monde. Ce dernier est à mon sens le cas de l'April. Un premier tournant fût la loi DADVSI qui souleva des réactions face aux atteintes qui pouvaient être portées aux Logiciels Libres (Ref).

La prise de conscience qu'il ne suffisait pas de promouvoir le Logiciel Libre mais aussi veiller à sa défense, a entraîné une croissance significative du nombre d'adhérents pour dépasser les 5000 en 2009. Outre les personnes physiques qui se sentent concernées, ce sont aussi des personnes morales : entreprises, associations ou des communes comme Toulouse qui rejoignent l'April.

Grâce à ses membres et aux permanents, les actions menées par l'April se sont succédées et multipliées depuis. DADVSI n'étant que le premier du nom, l'April a poursuivi ses actions sur les brevets logiciels, l'hadopi, la lopsi, l'acta... mais l'April sait aussi planter des graines. Elle est l'initiatrice et la coordinatrice de Libre en fête, elle se tourne vers les autres associations et vers la diversité, informe le citoyen sur la position des candidats aux élections ou oeuvre pour une education à l'informatique plus saine. L'April sait rassembler au-delà des frontières de l'informatique et c'est ce qui en fait une grande association.

J'ai eu la chance de côtoyer (la distance ne me le permettant plus) physiquement un certain nombre de bénévoles ainsi que l'équipe de permanents et je peux témoigner de la qualité de l'esprit et du savoir de ces personnes. Le travail abattu est immense tant les projets sont nombreux.

J'oublie bien sûr des facettes de l'April, je ne cite que celles qui me marquent le plus. Néanmoins, ce sont les raisons pour lesquelles je soutiens l'April.

Aujourd'hui, le Logiciel Libre doit réfléchir à de nouvelles problématiques : protection des données personnelles, informatique en nuage avec la variété de concept que cela contient, matériel libre et fablab, etc. Je suis certain que l'April saura trouver un chemin dans ces questions.

L'April a aussi besoin de votre soutien. Un membre de plus, c'est une voix de plus lors d'une prise de parole. C'est aussi permettre un travail continu de veille et d'expertise grâce aux salariés.

Pour ceux qui veulent donner de leur temps (à toutes les échelles), l'April est prête à recevoir. D'expérience, l'association étant assez imposante, il faut savoir prendre son temps pour prendre ses marques, il y a de la place pour tou(te)s et c'est véritablement enrichissant !

Page de la campagne d'adhésion

Viewing all 3409 articles
Browse latest View live