J'ai déjà parlé à plusieurs reprises sur ce blog de rss2email pour récupérer les flux rss. Avec plus d'une centaine de flux, il est un peu lent et consomme tout de même pas mal de CPU. Je me suis donc lancé dans un profilage du code pour comprendre ce qui consommait le plus.

Deux objectifs à ce billet :

• rapporter ma méthode
• demander à la communauté ce qu'on peut faire pour optimiser ce que j'ai identifié (cf la fin de ce billet)

Mise en place du profilage

On commence par cloner le dépôt de rss2email

git clone https://github.com/wking/rss2email
cd rss2email

ainsi que feedparser, la bibliothèque principale car je pressens qu'on va devoir y jeter un coup d'oeil.

git clone https://github.com/kurtmckee/feedparser.git

Je crée un virtualenv avec pew, comme suggéré par sametmax, c'est bien plus pratique.

pew new profiler

Construction et déploiement du code avec la méthode develop. Elle fait un lien symbolique, ce qui permet de ne pas avoir à faire une installation à chaque modification de code, ce qui est très intéressant lorsqu'on avance à petit pas dans le profilage.

cd feedparser
python setup.py develop
cd ..
# rss2email
python setup.py develop

On vérifie que ça tourne comme on l'attend. J'ai importé mes fichiers de conf et de base de données du serveur de prod pour être en condition de données réelles. L'option -n permet de faire un dry-run, c'est-à-dire de ne pas envoyer le courriel.

r2e -c rss2email.cfg  run 30 -n

J'installe la bibliothèque qui permet de profiler le CPU. Voir cette référence que j'ai trouvé utile pour les différentes méthodes de profilage en python.

pip install line_profiler

Pour activer le profilage sur une fonction, il suffit d'utiliser un décorateur.

@profile
def func(var):
    ...

On lance ensuite kernprof

kernprof -l -v r2e -c rss2email.cfg  run 30 -n

De manière récursive, je descend dans le code en répérant les fonctions qui prennent le plus de temps CPU.

Résultats

Le résultat est que le temps CPU est principalement utilisé par feedparser, que la moitié du temps sert à récupérer des données à travers le réseau (urllib) et l'autre moitié à faire du parsage de date. Ce parsage est traité en interne par feedparser.

Ces résultats sont rapportés dans ce ticket.

Regardons plus en détails. Il existe plusieurs formats à gérer. Pour mes flux, c'est principalement rfc822.

Le code commence par ceci

timezonenames = {
    'ut': 0, 'gmt': 0, 'z': 0,
    'adt': -3, 'ast': -4, 'at': -4,
    'edt': -4, 'est': -5, 'et': -5,
    'cdt': -5, 'cst': -6, 'ct': -6,
    'mdt': -6, 'mst': -7, 'mt': -7,
    'pdt': -7, 'pst': -8, 'pt': -8,
    'a': -1, 'n': 1,
    'm': -12, 'y': 12,
    'met': 1, 'mest': 2,
}

def _parse_date_rfc822(date):
    """Parse RFC 822 dates and times
    http://tools.ietf.org/html/rfc822#section-5
    There are some formatting differences that are accounted for:
    1. Years may be two or four digits.
    2. The month and day can be swapped.
    3. Additional timezone names are supported.
    4. A default time and timezone are assumed if only a date is present.
    """

    daynames = set(['mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun'])
    months = {
        'jan': 1, 'feb': 2, 'mar': 3, 'apr': 4, 'may': 5, 'jun': 6,
        'jul': 7, 'aug': 8, 'sep': 9, 'oct': 10, 'nov': 11, 'dec': 12,
    }

    parts = date.lower().split()

Avec le profilage, j'ai vu que 10% du temps était utilisé à construire le set(). Les avantages de set sont de garantir l'unicité et d'avoir des opérations de type union ou intersection (comme le dit la doc). Ici, daynames n'est pas modifié, on n'a pas donc besoin de fabriquer l'unicité sur quelque chose qu'on définit. Seule une itération est faite sur cet élément. Le set() ne me semble donc pas justifié.

J'ai ouvert un pull request pour corriger le set en tuple, et passer la déclaration en variable globale.

Si vous avez des suggestions pour améliorer les performances, n'hésitez pas à les partager sur github ou par email. Merci !

Note : email.utils.parsedate_tz semble être plus lent que l'implémentation de feedparser

Original post of François Boulogne.Votez pour ce billet sur Planet Libre.

Je parlais il y a peu du rétroportage de xfce-4.12 sur debian jessie. J'y proposais un script qui compilait les paquets, mais qui était très vilain.
Depuis, j'en ai profité pour l'améliorer et ajouter le support d'autres paquets, afin d'avoir la suite xfce-4.12 au complet.

Pour utiliser ce script, assurez-vous d'avoir mis dans votre sources.list la ligne suivante :

deb-src http://ftp.fr.debian.org/debian testing main

Et voilà le script en question :

#!/bin/sh
#Auteur :      thuban 
#licence :     GNU General Public Licence v3

#Description : rétroportage de xfce4.12
# Il FAUT ABSOLUMENT AVOIR DANS LE SOURCES.LIST : 
# deb-src http://ftp.fr.debian.org/debian testing main

sudo apt-get update

mkdir -p xfce-backport
cd xfce-backport

INSTALLED=$(mktemp)

installdeb() {
    for pkg in *.deb; do
        if [ -z "$(grep $pkg $INSTALLED)" ]; then
            sudo dpkg -i $pkg
            if [ $? -eq 0 ]; then
                echo $pkg >> $INSTALLED
            fi
        fi
    done
}

backport() {
    sudo apt-get -y build-dep $1
    apt-get source $1
    cd $1*
    if [ $? -eq 0 ]; then
        dch -i  "handylinux backport"
        #debuild
        debuild -us -uc -b
        cd ..
        installdeb
    fi
}



PKGLIST="libxfce4util libxfce4ui xfconf garcon
xfce4-settings xfce4-panel xfdesktop4 xfce4-session xfwm4 xfce4-appfinder exo
xfce4-terminal xfce4-battery-plugin xfce4-weather-plugin xfce4-whiskermenu-plugin
xfce4-cpufreq-plugin xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-volumed
xfce4-mount-plugin xfce4-notifyd xfce4-mailwatch-plugin xfce4-xkb-plugin
xfce4-places-plugin xfce4-power-manager xfce4-notes-plugin
xfce4-sensors-plugin xfce4-settings xfce4-taskmanager thunar
thunar-archive-plugin thunar-volman tumbler orage xfce4 gtk2-engines-xfce
xfce4-battery-plugin xfce4-clipman xfce4-dict xfce4-diskperf-plugin xfce4-equake-plugin
xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-indicator-plugin 
xfce4-linelight-plugin xfce4-mailwatch-plugin xfce4-messenger-plugin xfce4-mpc-plugin
xfce4-netload-plugin xfce4-places-plugin xfce4-quicklauncher-plugin xfce4-screenshooter
xfce4-smartbookmark-plugin xfce4-wavelan-plugin
xfce4-weather-plugin xfce4-wmdock-plugin xfce4-pulseaudio-plugin
xfce4-systemload-plugin xfce4-timer-plugin xfce4-verve-plugin
thunar-media-tags-plugin xfce4-goodies
"

#counter
N=0
TOT=$(echo $PKGLIST | wc -w)



for pkg in $PKGLIST; do
    N=$(($N+1))
    echo ""
    echo "===> Prepare $pkg"
    echo ""
    notify-send "$N/$TOT $pkg"
    backport $pkg
done

echo "Fini!"

exit 0

Les paquets seront installés au fur et à mesure. En redémarrant votre session, vous pourrez profiter de xfce-4.12.
— (permalink)

Original post of Thuban.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.

Nouvelle en grande pompe : le gouvernement Français désire porter le développement d’un système d’exploitation souverain Français. Bonne nouvelle ou échec en perspective? Je penche pour la seconde solution.

Ce n’est pas la première fois que le gouvernement nous parle d’un « FranceOS ». S’il fallait que je soit mauvaise langue je dirai qu’il a déjà existé et s’appelait Mandriva. Le tout est de réfléchir au pourquoi de cet OS et à son potentiel succès. L’OS made-in-france pourrait, selon Numerama, reposer sur CLIP, un OS basé sur Linux et développé par l’ANSSI (l’Agence nationale de la sécurité des systèmes d’information) qui se veut hautement sécurisé. On parle aussi d’Orange comme travaillant déjà sur le projet.

Dommage, ce sera sans doute un échec!

Pourquoi pas? Parce que personne ne l’attend

Les raisons qui poussent le gouvernent sont semble-t-il nobles : lutter contre le trusting des systèmes d’exploitation US, favoriser le développement des produit Français et promouvoir le savoir-faire logiciel de l’hexagone en renforçant la sécurité de l’utilisateur. Oui mais voila, personne ne désire voir débarquer un nouvel OS.

Je désire un OS massivement utilisé sur PC? J’ai déjà Microsoft Windows. J’aime le beau design et mon image est plus importante que mon usage? J’ai déjà Mac OS (oui, j’ai envie de troller les mac-addicts). Je préfère un OS qui se pliera à mes exigences ou qui me garantira sécurité? J’ai une pléthore d’OS basés sur BSD ou Linux. Bref, tout le monde a déjà ce qui lui faut.

Qu’à cela ne tienne. Il y a le désir et le besoin. Pas de chance, je ne pense vraiment pas que le besoin actuel des utilisateurs se situe au niveau des système d’exploitation, même Français.

Pourquoi pas? Parce qu’on est pas en Corée

Pour imposer un OS, il n’y a pas 36 solutions : où on est excellent, où on est incontournable, où on est un vendeur hors-norme… N’ayant aucune de ces cartes dans sa poche, il ne reste finalement au gouvernement que le totalitarisme pour réussir à imposer son produit. Semble-t-il nous sommes encore un peu dans un état de droit. Ce sera donc difficile de pousser l’OS dans nos chaumière.

Quant à l’exporter… no comment!

Pourquoi pas? Parce ce que développer un OS aujourd’hui est insensé

Je ne dis pas que les groupes français sont incapables de développer un OS Français. Je pense juste que c’est insensé. D’ailleurs, de grands groupe internationaux s’y sont cassés les dents. Pour goûter aux succès de WebOS ou Tizen (pourtant largement poussé par Samsung), autant arrêter de suite.

Alors pourquoi un échec à venir avec les OS? Comme je le disais plus tôt, les gens n’attendent plus d’OS supplémentaires. Même Chrome OS est à la peine. Finalement, ce qui crée de l’attractivité ce sont bien les applications (novatrices) et les WebServices. Si Apple a su s’imposer avec son système, il l’a fait avec un énorme renfort de design et d’ergonomie et là encore, on est loin de ce sur quoi travaille la France avec son OS CLIP. Bref, on est à des année lumière de séduire le grand publique…

Original post of Geek de France.Votez pour ce billet sur Planet Libre.

Pour organiser les prochains JDLL qui se dérouleront le 2 et 3 avril à Lyon, nous avons besoin de contributeurs pour assurer la réussite de cet évènement.

N'hésitez pas à relayer l'information à vos proches et connaissances et noter cette date dans votre agenda.

Créativité, Citoyenneté, Diversité : Le logiciel libre, du code, mais pas que !

Fort du succès des précédentes éditions, nous avons le plaisir d’annoncer la 17ième édition des Journées du Logiciel Libre (JDLL) ces 2 et 3 avril 2016 à Lyon. Le comité d’organisation des JDLL, la Maison Pour Tous, Salle des Rancy et l’Association Lyonnaise pour le Développement de l’Informatique Libre (ALDIL) vous proposent un temps de partage où tous les publics, curieux, amateurs et passionnés, se rencontrent.

Vous êtes libriste et utilisatrice⋅teur, développeuse⋅eur, créatrice⋅teur, joueuse⋅eur, bricoleuse⋅eur, artiste ? Vous souhaitez faire découvrir et partager vos plaisirs et petits bonheurs numériques ? Alors ce message vous concerne !

Thème(-s) 2016

Le thème de cette année est : « Créativité, Citoyenneté, Diversité : Le logiciel libre, du code, mais pas que ! » Sur le week-end, nous vous proposons d’intervenir pour échanger sur les domaines suivants :

• Diversité (diversité du numérique libre, diversité des publics) et accessibilité
• Engagement (parce que parler politique aux JDLL, c’est possible !)
• Biens communs et Open Data
• Reconditionnement, recyclage, éviter l’obsolescence programmée (ou pas)
• … mais aussi, encore et toujours l’actualité du développement et des usages du logiciel libre

Participation : mode d’emploi

Profitez de cet événement pour découvrir et échanger avec de nombreux participants. L’année précédente, grâce à vous, les JDLL ont accueilli plus de 1800 personnes sur les deux journées. Intéressés pour nous aider à réitérer l’exploit ? Les JdLL reçoivent des publics variés, n’hésitez pas faire des propositions pour les enfants, les adultes, les seniors, les associations, les entreprises, les collectivités territoriales, les novices comme les experts (et les licornes).

Participer aux JDLL c’est facile et ouvert à tous ! Nous faisons appel à vous pour alimenter le programme avec vos projets, connaissances, expériences et engagements.

Nous vous proposons 5 types de contributions :

• Stand au sein du village associatif
• Conférence de 20 ou 40 minutes suivies d’un échange (débats, tables rondes)
• Atelier de 45 minutes ou 1h15
• Démonstrations et présentations (logiciels, projets libres, DIY…)
• Animations ouvertes

Vous pouvez combiner plusieurs types de contributions, n’hésitez pas à être nombreux pour assurer la présence de votre collectif sur toutes les activités (par exemple une démo, une conférence suivie d’un atelier, un stand).

Faites nous parvenir vos propositions de participation via la page dédiée : http://www.jdll.org/jdll-presentation-generale/participer/formulaire-de-proposition/

Les propositions sont à envoyer jusqu’au 4 février 2016, afin de nous permettre de préparer au mieux le planning.

Un message de confirmation vous sera envoyé automatiquement.

Partage et informations complémentaires

Et bien sûr, n’hésitez pas à partager cet appel auprès de vos canaux respectifs :-)

Les outils de communication (bannières, logos…) sont à votre disposition pour participer à la promotion de l’événement : http://www.jdll.org/pratique/medias/

Pour obtenir plus d’informations, vous pouvez vous rendre sur le site des Journées du Logiciel Libre : http://jdll.org/

N’oubliez pas que nous sommes disponibles pour toute question : jdll@jdll.org

2016 nIQnutn CC-BY

Original post of nIQnutn.Votez pour ce billet sur Planet Libre.