PROJET AUTOBLOG


Sam et Max

source: Sam et Max

⇐ retour index

Redshift / F.lux pour éviter de s’exploser le yeux devant l’ordi

mardi 7 mai 2013 à 08:36

Si vous passez comme moi 34 heures par jour devant votre ordi au bout d’un moment vos yeux vont piquer un peu. Et là soit on arrête et on se repose soit on continue et on chiale.

Sur Ubuntu j’avais redshift et depuis que je suis sous Mac j’utilise f.lux que vous pouvez télécharger ici.

Ce petit logiciel va épargner vos yeux en ajustant la luminosité et la couleur de votre écran en fonction de l’heure de la journée.

Au début c’est asser désagrable je dois avouer car on a l’impression que l’écran vire sur un sale jaune orangé mais on s’y habitue au bout de quelques semaines.

Personnelement je le désactive de temps en temps la journéelorsque je bosse du design mais le réactive quand le soir arrive car c’est là où non seulement nos yeux ont passés des heures devant l’ordi mais ou l’ambiance de l’appartement diminue en luminosité laissant l’écran flashé 2.2 GigoWatts de lumière dans les yeux.

F.lux se lancera avec votre ordi, une icone dans la barre des tâches permettra de le désactiver au besoin.

Vos yeux vous diront merci.

flattr this!

Appeler du code C depuis Python avec ctypes

dimanche 5 mai 2013 à 08:55

On vous a dit et répété que Python c’était un super langage de glu et que ça pouvait très facilement s’interfacer avec les binaires produits par du C. Mais jusqu’à quel point ?

En vérité c’est extrêmement simple : Python permet de se mapper directement sur un .dll ou un .so, et d’appeler n’importe quelle fonction qu’il contient depuis le code Python comme si c’était une fonction normale. Il n’y a rien à installer, c’est fourni d’office.

On peut tester ça facilement. Je ponds une lib d’une folle puissance grâce à mes talents de codeurs C internationalement connus dans le quartier :

#include<stdio.h>
 
/*
Attend un pointeur sur un array de caractères (une chaîne en C) 
et l'affiche.
*/
dit_papa(char * p)
{
    printf("%s\n", p);
}
 
 
/*
Attend deux entiers et les multiple
*/
multiplier(long a, long b)
{
    return a * b;
}
 
/*
Attend un pointeur de pointeur sur un array de char
parce qu'on aime les risques.
*/
jakadi(char ** p)
{
    printf("%s\n", *p);
}

On compile tout ça. Comme je suis sous Nunux, j’utilise GCC et j’obtiens un .so, mais sous Windows c’est pareil avec VisualStudio et les .dll.

gcc -shared -Wl,-soname,ZeLib -o ZeLib.so -fPIC ZeLib.c

ZeLib.so est prête et frétille d’impatience à l’idée de vous servir. Il ne reste plus qu’à lancer le shell Python…

D’abord on fait ses imports, c’est dans la lib standard tout ça :

>>> import ctypes

Ensuite on se bind sur le binaire, il faut préciser un chemin absolu sinon ça ne marche pas :

>>> zelib = ctypes.CDLL("/home/sam/Work/projet/ZeLib.so")

Et derrière on peut appeler une fonction (Python fait la conversion entre tous les types de bases Python et C) :

>>> res = zelib.multiplier(2, 3)
>>> print res
6

Si on veut faire des chaînes, on ne peut pas passer de l’unicode. Comme mon shell a toutes les chaînes en unicode par défaut, je dois encoder dans le charset de sortie (sur mon système, c’est UTF8):

>>> zelib.dit_papa("papa".encode('utf8'))
papa
5

Notez au passage que la fonction retourne quelque chose même si je n’ai pas précisé de valeur de retour. Du coup j’aurais mieux fait de mettre un bon return 0 à la fin.

Si on veut appeler une fonction qui attend un pointeur, il faut d’abord caster son type en un type C, puis appeler by_ref dessus, qui va passer l’argument par référence, plutôt que par valeur :

>>> from ctypes import *
>>> s = ctypes.c_char_p('kiwi'.encode('utf8'))
>>> zelib.jakadi(byref(s))
kiwi
5

Voilà.

Voilà, voilà.

Bon attention quand même, le C n’est pas aussi conciliant que le Python : le debug est plus dur (pas de stacktrace, mais un bon vieux core dump), pas de completion dans ipython, et on peut même planter la VM si on se débrouille bien :-)

P.S: je ne vais pas mettre le code C à télécharger et le code Python, franchement, il est pas énorme. Donc petite exception dans cet article : y a rien à DL et la syntaxe est pas à base de comments.

flattr this!

Alors, on passe à Ubuntu 13.04 ?

samedi 4 mai 2013 à 09:06

J’ai utilisé Ubuntu 13.04 depuis quelques jours. C’est un bon cru : l’interface est fluide (n’oubliez pas d’installer preload) et quelques ajouts ergonomiques sympas ont fait leur apparition.

Mais globalement, je reste en 12.04 car :

Si vous devez installer une nouvelle version, installez la 13.04. Sinon, ne faites pas l’update, ça ne vaut pas le coup.

P.S: Ubuntu 13.04 vient avec Python 2.7 par défaut, et pas Python 3. C’est la 2eme fois qu’ils reportent. Qu’est-ce que je vous disais, déjà ?

flattr this!

Paramètres par défaut pour la commande py.test

vendredi 3 mai 2013 à 10:23

Je ne fais plus de tests unittaires sans pytest, et je me retrouve souvent à rentrer les mêmes paramètres de la commande encore et encore. Parfois, quand j’utilise des wrappers tels que django-pytest et pytest-django (ça s’invente pas), je ne peux même pas passer d’arguments directement à py.test.

On peut y remédier en créant un fichier de config à la racine du projet. Nommez le fichier tox.ini, car c’est aussi le nom du fichier de configuration de l’outil de tests tox, et il est compatible, donc autant avoir un seul format. Dedans, créez une section pytest, et vous pouvez configurer la lib la dedans.

En l’occurrence, le settings “addopts”, pour “add options” (ajouter options), permet de spécifier les options de la ligne de commande à toujours ajouter à py.test.

Mon fichier contient toujours au moins ceci :

[pytest]
addopts = --ignore="virtualenv" --capture=no

Ainsi py.test ignore toujours le dossier virtualenv (qui est un lien vers l’env virtuel de mon projet) car je ne veux pas qu’il lance les tests de ce dossier. Et il ne capture pas stdout, ce qui me permet d’utiliser ipdb pendant les tests unittaires. Parfois j’utilise aussi --maxfail=1 quand je veux qu’il s’arrête dès la première erreur rencontrée.

Pour ne pas aller dans ce dossier et ne pas capturer stdout.

flattr this!

J’avais dis que je répondrais à tous les mails…

jeudi 2 mai 2013 à 09:34

Bon, vous connaissez le principe, un mec me pose une question dans un mail, je répond et je m’aperçois que j’ai un DELIVERY FAILURE.

En l’occurrence, si j’avais lu le mail avant de cliquer, j’aurais eu l’air moins con : pouete@….

un tuto sur “Parser du HTML/XML”

Ca m’amuse d’écrire des petits scripts qui récupèrent les vidéos des
replays télés, pour plein de raisons (7 ou 15 jours c’est court, j’aime
bien ne pas dépendre de la qualité du site distant, ni de ma connexion
pour regarder ensuite…). Chacun ses perversions

Le système est le toujours le même. Sur la page de replay, il y a un
identifiant de vidéo, que l’on passe à un site (WAT pour
TF1/TMC/NT1/HD1, Brightcove pour BFMTV,
http://prod-kernnrj12v5.integra.fr/videoinfo pour cherie25 et nrj12,
Akamai pour France TV/Pluzz/TV5 Monde…), qui nous renvoie la vraie
adresse de la vidéo. Il y a souvent un peu de XML à parser, avec
plusieurs lignes parmi lesquelles on choisira la meilleure qualité vidéo
(HD, SD, BD, Ipad, Iphone), le bitrate le plus élevé.

Donc on parse du HTML et du XML pour un petit script de rien.

Hello bilou,

Il y a des choses que je n’ai pas compris dans le mail, et j’aurais voulu te poser moult questions : “est-ce que tu propose un tuto suite à cette expérience ou tu en demande un ?” mais l’adresse de réponse est “pouete”.

Met un addresse Yopmail ou spamgourmet la prochaine fois, ça permettra de te répondre.

flattr this!

I'm richer than you! infinity loop