You are currently browsing the category archive for the ‘Perl’ category.
Dans la vie numérique, j’aime git et j’aime les wiki que ce soit pour un usage collaboratif ou personnel.
Celles et ceux d’entre vous qui me suivent savent que j’utilise zim afin de conserver mes notes privées ou n’ayant aucun intérêt à être divulguées. Zim se définit comme un wiki de bureau.
Il se trouve que je viens d’avoir un nouveau besoin : répertorier des petits bouts de code présentant des syntaxes ou des usages de bibliothèques que j’ai cherché au moins une fois. Zim ne propose pas de coloration syntaxique pour ça et la demande de colorisation de texte est un bug ouvert (d’après mon souvenir).
Bref, toujours curieux, toujours prêt à tester de nouvelles solutions, je me suis mis à chercher des wikis en ligne avec git comme gestionnaire de version. En effet, je veux retrouver les avantages que j’ai avec Zim à savoir :
- reposer sur des fichiers textes avec de préférence une syntaxe non ésotérique
- être accessible hors ligne, ce qui signifie avoir une copie locale complète
Ce dernier point étant important, car si mon serveur tombe ou si je n’ai plus de moyen de me connecter, je veux toujours accéder à mes données.
J’ai trouvé et testé deux solutions. Il en existe peut être d’autres qui m’ont échappé. La première se nomme gitit. C’est codé en haskell, ca ressemble beaucoup à mediawiki. L’installation sur un serveur debian s’est passée sans encombre à l’aide du paquet fourni et de la doc. J’ai été vraiment séduit à l’usage notamment par le support de différents langages de balisage léger, l’export dans N formats (epub, pdf, tex et j’en passe), c’est pandoc qui est derrière, donc du costaud. A noté aussi le support mathml et la possibilité de faire des slides en html5 (j’ai trouvé ça génial).
J’ai été déçu quand je me suis rendu compte que le support coloration syntaxique demandait de recompiler le logiciel (sauf si j’ai raté quelque chose, le paquet debian ne semble pas avoir ce support). ce n’est pas insurmontable, mais sur le coup, je n’ai pas eu envie.
Retour moteur de recherche et je suis tombé sur ikiwiki. Après un coup de ménage sur le serveur, j’installe donc ce palindrome. Là aussi, paquet + doc rendent ça très facile. Au passage, heureusement que les lib perl sont empaquetées, il y en a une belle quantité.
Je n’ai pas pris l’installation manuelle, la version "automatique" + ajustement ultérieur m’a semblé suffisant. L’interface par défaut est moins sexy que gitit, mais on peut trouver quelques css. Il existe aussi une foule de greffons dont un qui gère des refs via bibtex. Pas encore testé, mais ça m’intéresse grandement. Coté fonctionnalité, j’ai presque l’impression que c’est le négatif que gitit. J’aimerai voir tous les avantages que j’ai cité dans gitit chez ikiwiki. Notamment, pas de mathml mais un greffon qui fait du dvipng 
Ikiwiki fait un build des pages grâce à un hook git, donc dès que vous poussez votre version, ça reconstruit un html statique à partir du (des) fichier(s) modifié(s) servi par votre serveur web. Etant donné les langages et le plus grand nombre de greffons, ikiwiki remporte mon intérêt. En effet, je peux coder un peu en perl et j’ai vu qu’il est possible de coder des greffons en python.
Une remarque importante est que ikiwiki peut être utilisé comme un blog statique. J’ai remarqué qu’un certain nombre d’auteurs retournait sur ce genre de solution après une expérience de CMS comme wordpress. Il est vrai que la légèreté (important pour les lecteurs aux faibles débits et les auto-hébergés) et l’atout rédactionnel déporté sont intéressants. L’intérêt que je verrai à ikiwiki pour cet usage serait les commentaires gérés sans service externe (cf ce blog à titre d’exemple).
Même si je n’ai pas encore rendu Zim, je me rend compte que ikiwiki serait plus adapté à mes usages. Zim m’aide beaucoup en tant que wiki, mais peu en terme d’utilisation et de fonctionnalité. Je n’aime pas l’éditeur d’équation, l’import d’image ou l’absence de support syntaxique.
Si certain(e)s ont un expérience dans ce domaine, je suis preneur ; autrement je vous laisse décrouvrir 
L’April possède un wiki de travail permettant aux membres et aux non-membres de participer à l’élaboration de divers travaux. Ce wiki fonctionne grâce à mediawiki.
Récemment, j’ai mis en place un sélecteur de licence permettant à un contributeur d’apposer facilement une licence parmi une sélection (ou de mettre une licence ‘custom’ si aucune n’est satisfaisante). Ceci se fait très facilement en modifier la page spéciale MediaWiki:Licenses. Il suffit d’y faire une liste de modèles et ces modèles insère le texte adéquat de la licence (ou un lien y référant). La question de la licence est bien évidemment centrale dans ce type d’outil de travail, il en va de la possibilité de diffuser et de réutiliser les productions des contributeurs.
Ceci étant fait, il s’est posé la question des fichiers ayant été envoyés par le passé pour lesquels il n’y avait pas eu de licence précisée (environ 1200 fichiers). Pour palier ce manque, j’ai écris quelques lignes de code afin de mettre à jour automatiquement ces fichiers en question.
J’avais pour point de départ un fichier csv que j’ai parsé à l’aide d’un premier code perl pour créer des fichiers dont la syntaxe est de type ini, facile à manipuler. Je produit un fichier par utilisateur concerné. Chaque entrée concernant un fichier dont la licence est à préciser.
Un courriel est envoyé à chaque personne pour demander de compléter le champ licence, puis, à la réception de celui-ci, il est lu par un deuxième script via la bibliothèque Config::IniFiles. Les informations sont ajoutées à la page mediawiki idoine, comme l’aurait fait le sélecteur de licence, via la bibliothèque WWW::Mechanize.
Le choix de perl s’est fait lorsque j’ai appris (merci VX et Tangui) que la bibliothèque perl mechanize était bien mieux documentée que la bibliothèque python (devinette inside via 3 exemples). C’est tout de même plus rassurant…
Ca se code tout seul… si on n’oublie pas les deux lignes pour se loguer à mediawiki avant (certains comprendront 
). En espérant que cela serve ou donne des idées à quelqu’un.
L’avantage de faire une thèse est de réfléchir à ses méthodes de travail et d’organisation. Dans les productions scientifiques, les figures prennent une place très importante et requièrent donc d’y consacrer du temps.
Mon objectif est d’optimiser au maximum la production de mes figures. J’ai choisi d’utiliser quasi-exclusivement LaTeX pour mes figures pour des raisons de qualité, du coté "codage" (les avantages de l’approche code vont être largement mis en exergue ici) et de manipulation de formats.
Sources des figures
Mes figures sont de trois types :
- Chemfig pour les formules chimiques (.chem)
- Tikz pour les schémas (.pgf)
- Gnuplot avec la sortie Lua/Tikz (.plt -> .tikz)
Production des figures
La production des figures est réalisée à l’aide d’un makefile et de deux scripts shells. Un premier script nommé tikzmaker encapsule le fichier tikz (.pgf) avec une entête Latex en utilisant le paquet standalone, ce qui donne un .tex. De même, un script chemmaker transforme mes .chem en .tex.
Gnuplot se charge de produire un fichier .tikz à partir du fichier .plt. Ce fichier tikz passe aussi à travers tikzmaker pour avoir un .tex.
Ces fichier tex sont ensuite compilés en eps et pdf puis en svg avec pdf2svg.
Ce sont toutes ces étapes qui sont automatisées avec un makefile. Cela fait maintenant plusieurs mois que j’utilise cette mécanique que je trouve très satisfaisante. On voit ici que l’approche code permet de modifier des figures extrêmement rapidement grâce à l’automatisation totale. Par ailleurs, cette approche peut permettre de versionner ses figures ; chose que je n’ai pas encore fait mais qui se mettra facilement en place si la nécessité apparaît.
Traduction
Comme je l’ai dis, cette mécanique existe chez moi depuis un moment, j’en avais déjà parlé à l’occasion de précédents billets. La partie innovante de cet article est la traduction. En effet, je dois parfois intégrer mes figures dans des articles en anglais ou dans des documents pour des congrès internationaux. A d’autres moments, ce sont des figures en français dont j’ai besoin.
Dans l’action, il y a deux possibilités : soit on modifie le fichier source en changeant toutes les chaines d’une langue à une autre, soit on duplique le code et on traduit la copie. Chacune de ses méthodes a son inconvénient. Pour la première, je risque d’osciller entre version anglaise et française au gré de mes besoins. la perte de temps est considérable car je dois refaire ce que j’avais fait. Pour la seconde méthode, je ne traduis qu’une seule fois, mais si je modifie la figure, alors je dois reporter les modifications sur mes traductions, chose qu’on ne manquera pas d’oublier et on se perdra dans les sources après quelques mois.
L’idée est d’utiliser un outil dédié à la traduction. A l’occasion de l’écriture d’un code (inforevealer) que j’ai un peu complètementabandonné par manque de temps, j’ai découvert le projet po4a qui s’appuie sur gettext pour traduire les fichiers qui ne sont pas du code (tex, ini, text…). Ce projet est codé en perl, il faudra adapter un peu le logiciel en ajoutant un module.
Le but de po4a est d’aller chercher les chaines de caractères dans nos fichiers .pgf et .plt. Les .chem n’ont, chez moi, pas de contenu à traduire. Ces chaines sont stockées dans un fichier .pot que l’on copiera en fr.po. Ce fichier fr.po est le fichier dans lequel il faudra traduire les différentes chaines.
Je crée d’abord un fichier de configuration pour po4a (ex po4a.cfg) :
[po_directory] po/
[type: Gnuplot] plot/plot.plt fr:plot/plot.fr.plt
[type: Tikz] fig/fig.pgf fr:fig/fig.fr.pgf
La première ligne nous dit que les traductions se trouveront dans le répertoire po/ (à créer). Il faudra y créer un fichier .pot (le nom n’importe pas) vide. Ensuite on lancera une première fois la commande :
po4a po4a.cfg
Puis on ajoute notre traduction fr :
cp po/master.pot po/fr.po
On traduit et on lance une nouvelle fois :
po4a po4a.cfg
Ceci fait, le fichier plot/plot.plt sera traduit en plot/plot.fr.plt et il suffira de relancer le makefile pour compiler la figure francophone. Ceci décrit donc le déroulement du processus de traduction.
Comme vous l’avez remarqué, il faut indiquer un type (ici Gnuplot et Tikz). Ces types, je les ai créé en ajoutant des bibliothèques perl dans /usr/share/perl5/vendor_perl/Locale/Po4a (chemin sur archlinux). C’est assez simple à réaliser (à condition de connaître un peu perl et les expressions rationnelles). Le fichier Ini.pm offre une bonne base pour la syntaxe. En passant, remarquez que le copyright de ce fichier (sous GPL) est attribué à BitDefender (j’aime ces petites découvertes dans les codes). Pour les fichiers gnuplot, j’ai pris le parti de mettre les chaines à traduire entre double quotes, les autres entre simple quotes. De ce fait, j’utilise pour le moment un copie du fichier Ini.pm pour Gnuplot.pm. Cependant, ce code ne permet de récupérer qu’une chaine par ligne. C’est assez peu gênant, mais j’améliorerai ça plus tard. Pour les fichiers Tikz, il suffit de récupérer le contenu des node{} au lieu des double quotes en prenant garde qu’il peut y avoir des options (node[above] {}).
Voilà pour la partie technique. Les avantages que je vois à cette méthode sont les suivantes :
Un fichier unique pour toutes mes traductions.
Pas de redondance de traduction : si "theory" apparaît 10 fois dans 10 fichiers différents, la traduction me sera demandée qu’une fois. Sachant que les figures voient apparaître des termes récurrents, c’est un gain non négligeable.
Pas de duplication de code à proprement parler. En pratique, il l’est : plot.plt et plot.fr.plt, mais on ne modifiera que plot.plt car plot.fr.plt est généré à partir de plot.plt et fr.po par po4a.
Les codes (tikzmaker, makefile…) sont tous triviaux, néanmoins s’ils intéressent quelqu’un, je peux les mettre à disposition. Pour les bibliothèques perl, elles sont en cours de test… mais j’ai déjà une bonne dizaine de figures traduites avec succès.
Quelque soit la distribution, il peut être utile d’avoir une copie de sa documentation sous le coude, au cas où. En effet, on peut se retrouver parfois sans connection internet et souhaiter jeter un coup d’oeil dans la documentation.
Avec le wiki de archlinux.fr, le wiki d’archlinux.org est une vraie mine d’or. la propriété de ce dernier wiki est d’avoir à la fois la documentation en anglais mais aussi (lorsqu’elles sont disponibles) les traductions en d’autres langues. Je dois dire que la structure est efficace. Les pages de bases sont en anglais et les traductions ont pour titre
Page_title_(Français)
Des redirections peuvent exister pour traduire les titres…
Arch-wiki-docs
Dans le dépôt community, il existe un paquet qui permet d’obtenir une copie de la documentation sur son disque. C’est arch-wiki-docs. Ce paquet contient déjà la doc, et il est mis à jour régulièrement.
Formidable me direz-vous… sauf que ce paquet contient toutes les langues, donc trop de choses comme l’on fait remarqué certaines personnes sur ce fil de discussion (anglais).
ArchDocumentalist
Le code original était un mélange de perl et de script shell. J’ai donc pris l’initiative de réécrire un code, entièrement en perl cette fois ci (fabuleux langage au passage ! ). Le dépôt git se trouve là et j’ai empaqueté le script dans AUR. Donc
yaourt -S archdocumentalist
pour l’installer.
L’utilisation est fort simple :
archdocumentalist.pl FR /tmp
et le répertoire /tmp/arch-wiki-FR contiendra les pages. Ouvrez index.html. Vous pouvez générer d’autres langues. Ex : remplacez FR par EN.
A la limite, la doc peut être mise à jour tous les mois par une tâche cron.
PS : je conseille d’installer un navigateur en console pour lire la doc (si tout venait à lâcher ce qui arrive une fois par siècle.)
PPS : évitez /tmp comme répertoire de stockage d’une doc
Qui n’a jamais eu une fois un soucis d’accents en LaTeX ? Je pense que quiconque l’a expérimenté, a eu au moins une fois des surprises. Généralement, ces surprises interviennent lorsqu’on passe un fichier tex d’une machine à l’autre. Il faut dire que lorsqu’on fait souvent ces changements ou que l’on envoie fréquemment des sources, il est pénible de changer l’encodage du fichier et les directives d’appel de paquets qui vont avec. (\usepackage[latin1]{inputenc} & cie)
La solution face à ce problème est d’encoder ses accents de cette mani\`ere.
Voici un petit script perl qui peut sans doute être plus éléguant mais qui tourne bien et qui converti les accents en encodage latex et réciproquement. Je l’ai déjà bien utilisé, et je peux vous dire que je n’ai pas de problème. Par ailleurs, un fichier à l’extension .save est créé par sécurité.
La lecture d’un code source est pénible lorsqu’il est rempli d’antislash, c’est pourquoi j’ai implémenté la fonction inverse (option -a). On peut passer plusieurs fichiers tex en argument.
Billet court, mais qui j’espère vous soulagera l’existence.
Je montrais il y a quelques temps mon bureau sur LXDE personnalisé. J’utilisais à l’époque (cf article) le script de chipster en perl, disponible sur le forum d’archlinux. Celui-ci était une écriture complète d’un programme générant un calendrier.
Ce que j’avais souligné à l’époque était qu’il ne génère qu’un seul mois. J’avais fait alors quelques modifications pour qu’il m’en génère deux, l’un en dessous de l’autre. Modifications qui était pour le moins douteuses, c’est pourquoi je ne l’avais pas publié (et aussi parce qu’aucune licence n’était attachée à ce script et que je n’ai pas demandé d’autorisation…).
Ce qui ne me satisfaisait pas était le fait que l’on ne pouvais générer que les mois les uns en dessous des autres, sauf gros changements dans le code. Mais, je m’en étais accommodé.
Je suis passé il y a quelques mois à une version de développement de mandriva (plus ou moins gelée) sur mes deux PC (pour des raisons X et Y pas importantes ici). Et là, le script de ne fonctionnait plus dans conky ni celui que j’ai modifié, ni l’original. La raison en était fort simple, l’appel de
${execp perl mon_script_perl.pl}
tronque la sortie standard. :/ Je n’ai aucune idée du pourquoi. A vrai dire, je ne suis même pas allé voir sur le site du projet, enfin, pas encore. Mon réflexe était de refaire une modification du script qui génère le calendrier pour le générer par morceaux. Un bon contournement de problème comme il se doit 
et puis, quand j’ai vu l’état du script, j’ai tout bonnement décidé de le réécrire.
Je me suis basé désormais sur le petit programme nommé cal, écrit en C. (oui, vous l’avez deviné, je l’avais déjà patché lui aussi pour mon conky avant d’adopter le script de chipster) Cal permet de sortir un mois d’une année donnée, dans la langue qui va bien… pratique, on réutilise. La réécriture me permet enfin d’avoir ce que je voulais depuis le début : pouvoir choisir le nombre de mois mis sur la largeur et sur la hauteur. Et j’ai ajouté le "workaround" monstrueux en attendant que j’aille faire un tour sur le site du projet.
Voilà le résultat sur mon dépôt git. Des mises à jour pourront suivre pour la correction d’éventuels bugs ou pour des améliorations du code.
Protéger grub, pourquoi ?
Il est possible de protéger grub de l’édition en ajoutant un mot de passe. L’objectif est d’améliorer la sécurité en empêchant l’édition de grub et donc d’un accès root. Bien sûr, une telle protection est inutile si on peut démarrer sur un média externe comme une clef USB ou un lecteur optique. Un liveCD/USB permettrait de se donner un accès root. Il convient donc de protéger le bios également et de supprimer le démarrage sur média externe. Les puristes iront jusqu’à poser un cadenas sur la machine, protéger l’entrée de la salle par biométrie… bref, je m’égare.
Protéger grub, comment ?
Dans une console, on peut utiliser grub-md5-crypt :
grub-md5-crypt
Password:
Retype password:
$1$AvIeV/$e6WXVU5ubnIIZDgwuQ9iF.
Il suffit alors d'ajouter la ligne suivante password --md5 $1$AvIeV/$e6WXVU5ubnIIZDgwuQ9iF. dans le fichier /boot/grub/menu.lst et c'est tout
Et pour les anti-consoles ?
Mandriva propose bien sûr une alternative à la console pour protéger son grub. Si vous démarrez la version actuelle du centre de contrôle Mandriva et allez dans l’onglet approprié, vous verrez cette interface.
Il y a en fait trois problèmes :
Premièrement, je ne trouve pas la présentation astucieuse. Comme vous pouvez le voir, il faut aller dans "avancé" pour activer la protection dont le mot de passe se trouve dans la fenêtre principale.
Deuxièmement, la case protection se retrouve être décoché si vous revenez plus tard dans cette interface alors que la protection est active et fonctionnelle.
Troisièmement, il est impossible de désactiver la protection…
Autant de soucis méritent un patch
J’ai donc ajouté plutôt une case à cocher dans l’interface principale, case qui va (dé)griser les champs pour le mot de passe selon qu’elle est active ou non. Le fait que la case précédente était toujours décochée venait simplement d’un oubli et la désactivation de la fonctionnalité était aussi un cas oublié. Tout ceci se retrouve donc dans le patch que j’ai proposé. La nouvelle interface deviendra (si mon patch est accepté) :
Peut-on faire encore mieux ?
Je pense que oui En effet, il faut garder en tête que lorsqu’on souhaitera éditer le grub (en pressant p), il faudra entrer son mot de passe en clavier qwerty (donc en aveugle si vous avez tout autre clavier). Mon idée serait de vérifier le clavier utilisé lorsque l’utilisateur a activé la fonctionnalité et afficher un petit message informatif dans les cas nécessaires.
Certains le savent, je veux m’investir au plus près du code source. Je fouine donc à travers les projets à la recherche d’une correction que je peux apporter. Mes connaissances en programmation ne sont pas encyclopédique, mais je me débrouille. Je profite de ce billet pour lancer un appel (cf partie sur Tilda)
Manque de traduction dans drakxservices (Mandriva)
Le premier patch concerne un bug que j’ai ouvert lorsque je me suis mis pour la première fois au test de distributions en développement. Ouvert fin 2008, le bug n’avait pas été corrigé, notamment à cause d’un flottement sur la personne responsable. Il était temps de prendre le taureau par les cornes et de faire un coup de perl.
Ce qui semblait à première vue un simple manque de traduction était en fait des chaines inexistantes dans les .po. Il s’avère qu’en fait, certaines chaines étaient connues et pour cause, elles apparaissent dans un hash. Mais pour les services n’apparaissant pas dans le hash, la description était directement recherché dans /etc. J’en ai donc profité pour compléter la table.
Tilda : erreur de segmentation
Un problème que j’avais remarqué sur la 2010.0, mais j’avais oublié d’ouvrir un rapport… le logiciel tilda déjà discuté ici ne se lançait pas à cause d’une erreur de segmentation. Ce n’était pas le cas sous mandriva 2009.1 bien que la version du logiciel n’ai pas changé. Je suis parvenu à corriger l’erreur de segmentation. Si vous lisez le rapport vous verrez que j’ai supprimé l’appel à
gdk_x11_window_set_user_time ()
Selon moi, il n’y a pas d’intérêt, mais je connais très mal les API utilisé dans tilda. Si quelqu’un sait… De plus, je vais reporter le patch upstream, mais le projet semble abandonné à mon plus grand regret, j’aurai vraiment bien aimé le reprendre, mais mes compétences ne me le permettent pas encore.
Imageshack-uploader : corrections de warnings en partie dus à des changements chez ffmpeg
J’ai eu l’occasion d’aider une personne sur la mailing liste francophone d’entraide à la création de RPM pour mandriva. Le résultat se trouve là. Le patch a permis de compiler correctement le logiciel. il n’y a pas vraiment de commentaire particulier à faire si ce n’est le warning
httprequest.cpp: In member function ‘QNetworkProxy&
HTTPRequest::getProxy()’:
httprequest.cpp:37: attention : reference to local variable ‘p’ returned
où il manque visiblement une donnée membre du type QNetworkProxy. Je n’ai pas remonté ce point. Ce soucis de ce projet est l’organisation, il n’y a pas sur leur gestionnaire de version les codes des différentes versions. On est ainsi obligé de prendre le code sur le dépôt à moins de démanteler le .deb founit.
Cet article, qui s’adresse avant tout aux plus scientifiques d’entre vous (quoique…) a pour but d’automatiser une tâche d’ajustements (ou fit par anglicisme) de courbes et d’en récupérer les informations (coefficients et compagnie). Je vais en profiter pour faire l’apologie du logiciel que je vais utiliser : gnuplot. La motivation de cet article fait suite à certaines requêtes de personnes visitant mon blog qui doivent être insatisfaites.
Position du problème
Le problème est le suivant. On dispose de deux fichiers. L’un (weight.txt) possède deux colonnes : abscisse et ordonnée d’un nuage de point. Sur ce nuage de point, je désire connaître une pente locale sur un certain intervalle. Justement, ces intervalles sont donnés dans un second fichier (range.txt) sous la forme de deux colonnes : début et fin.
On voit donc se dessiner la petite mécanique : prendre un intervalle dans le fichier range.txt, effectuer un fit sur les données de weight.txt à l’aide d’une droite, et envoyer la pente (et son incertitude au moins) dans un fichier tiers.
Gnuplot
Gnuplot est un logiciel de tracé et de tracé uniquement (mais qui n’a rien à voir avec GNU). Il ne permet pas de traiter des données, mais au moins, ce qu’il fait, il le fait bien. Enfin, quand je dis tracé seulement, nous n’en ferons aucun ici. La petite exception, c’est l’ajustement. Son usage se fait en console ce qui lui vaut les foudre de certains : "c’est d’un autre temps". Oui, gnuplot est un vieux logiciel, mais si il a traversé les âges, c’est bien une preuve de son efficacité.
Justement, le fait qu’il soit un logiciel de type CLI (command line interface) permet d’automatiser des tâches par des "scripts" si on peut les nommer comme cela. Rapidement, les avantages. Automatisation comme je l’ai dit, adaptation rapide et conservation du "moyen" utilisé pour générer le graphique car je conserve toujours un graphique avec son fichier de commande gnuplot. Même si un jour je venais à changer de logiciel, j’ai un fichier texte interopérable qui me dit comment j’ai fait et que j’ai pu commenter et que je peux réadapter.
Bref, gnuplot c’est ce qu’il nous faut !
(A noter qu’il existe des interfaces graphiques (GUI) pour gnuplot comme cet addon pour emacs ; jamais testé par mes soins, je n’en vois pas l’intérêt ).
Automatisation
Afin d’automatiser complétement le traitement, je vais écrire un petit script perl comme j’aime le faire. Plutôt que de faire un long discours, voilà ce script que je vais commenter.
Après les ouvertures de fichiers, j’effectue les choses suivantes à chaque intervalle :
Écriture d’un fichier gnuplot.gnu avec la ligne
fit \[$range[0]:$range[1]\] coeffa*x+coeffb \"weight\.txt\" u 1:2:(0.01) via coeffa,coeffb
où $range[0] et $range[1] sont les éléments d’un tableau du script perl qui donne l’intervalle. On donne ensuite la formule d’ajustement ; ici, une droite, rien de méchant. Le fichier en question en utilisant les colonnes 1 et 2 (abscisse et ordonnée) et une erreur sur l’ordonnée de 0.01 que j’ai estimé par rapport à l’appareil de mesure. Nous verrons plus tard son intérêt. Ce "fit" se fait via les deux coefficients en question.
On referme le fichier et on lance la danse de gnuplot.
Gnuplot produit en plus de la sortie dans la console, un fichier fit.log (valeur par défaut de la variable FIT_LOG) contenant toutes les informations du processus : une précieuse ressource. En voici un extrait :
After 9 iterations the fit converged.
final sum of squares of residuals : 97.494
rel. change during last iteration : -3.45394e-07
degrees of freedom (FIT_NDF) : 18
rms of residuals (FIT_STDFIT) = sqrt(WSSR/ndf) : 2.3273
variance of residuals (reduced chisquare) = WSSR/ndf : 5.41633
Final set of parameters Asymptotic Standard Error
======================= ==========================
coeffa = 0.0930301 +/- 0.0009025 (0.9701%)
coeffb = -128.167 +/- 2.924 (2.281%)
correlation matrix of the fit parameters:
coeffa coeffb
coeffa 1.000
coeffb -1.000 1.000
J’ai enlevé les informations de base (heure, fichier, fonction utilisée…) ainsi que les étapes. Je reviendrai sur certaines de ces infos…
Vous l’aurez compris, la ligne désirée est :
coeffa = 0.0930301 +/- 0.0009025 (0.9701%)
Je vais donc utiliser l’expression rationnelle (ou régulière) suivante :
if ($_ =~ s/(\w+)\s+=\s(.*?)\s+\+\/\-\s+(.*?)\s+\((.*?)\%\)/$1 $2 $3 $4/)
qui donne dans $_ la variable, la valeur, l’erreur et le pourcentage. Ce scalaire est "splité" avec les espaces ensuite… et j’écris ce que je veux dans un fichier.
Et voilà ! c’est gagné ! Simple non ?
Précisions concernant les ajustements
L’algorithme utilisé par gnuplot est celle de Levenberg-Marquardt. Méthode connue et reconnue, robuste, implémentée dans la plupart des logiciels. Loin d’être un parfait connaisseur, je vais mettre le doigt sur quelques points clefs lorsqu’on réalise un ajustement.
Pour ceux qui ne connaissent pas du tout les ajustements, l’objectif est de réduire le carré (pour des raisons de signe) de la différence entre la fonction est le point, divisé par le poids (incertitude) du point pour toute la courbe (somme). C’est le "khi 2" comme on le prononce en français.
Erreurs
On considère que les incertitudes ont une distribution gaussienne (pour des raisons de théorème central limite). Ainsi si la fonction passe dans les points à "la boite d’incertitude" près, alors la racine du chi 2 divisée par le nombre de point doit être de l’ordre de 1. Dans le fit.log :
rms of residuals (FIT_STDFIT) = sqrt(WSSR/ndf) : 2.3273
ce qui est réconfortant. Si la valeur était bien plus grande, alors l’ajustement ne serait sans doute pas très bon. Il faut revoir la fonction choisie. Si cette valeur était très petite, alors il est fort possible que l’incertitude soit sur évaluée. La conséquence pour une droite, c’est que la pente n’est pas bien définie car différentes pentes vont passées par les barres d’erreur.
Dans le cas où aucune erreur n’est spécifiée, elle est unitaire. Si c’est la même pour tous les points, on peut l’ajouter comme dit ci-dessus dans la commande fit. Sinon, on spécifie par une troisième colonne dans le fichier la valeur pour chaque point.
Degrés de liberté
Toujours dans le log du fit :
degrees of freedom (FIT_NDF) : 18
C’est la différence entre le nombre de point de l’intervalle et le nombre de coefficient. Ce nombre doit être suffisamment grand bien sûr. Cette valeur est utile pour interpréter quantitativement un chi 2 à l’aide d’une table de chi 2 afin de connaître la probabilité d’arriver à un tel chi 2.
Valeurs initiales et non linéarité
Il est important, pour ne pas dire vital, de définir les valeurs des coefficients pour l’ajustement. Par défaut, ils sont égaux à 1. Pour notre régression affine, cela ne nous affectera pas le résultat, mais dans le cas d’une fonction non linéaire, il peut exister des minima locaux que l’on veut éviter. Parfois, l’ajustement peut se retrouver piégé dans un minimum non souhaité et le résultat est erroné. Il convient d’initialiser les variables comme coeffa=10.
Matrice de corrélation
Gnuplot affiche aussi la matrice de corrélation des paramètres. Elle peut s’avérer utile lorsque des ajustements non linéaires sont réalisés. En effet, on est amené à fixer des paramètres pour ne faire varier que les autres de manière à approcher au mieux l’extremum global que j’ai expliqué ci-dessus. Dans ce cas, on a une information du style : "si je fais varier le paramètre a, de combien cela influence-t-il le paramètre b,c,d…". Cela peut aider dans le cas de fonction compliquée à élaborer une stratégie.
Limite d’arrêt
Vous verrez dans un fit.log la ligne suivante :
limit for stopping : 1e-05
Ceci correspond au critère de convergence du fit. Si la variation relative du WSSR est inférieure à cette limite, on considère que l’on a convergé. On peut modifier cette valeur comme ceci : FIT_LIMIT=1e-7.
Deux autres paramètres sont modifiables et permettent de modifier le comportement de l’algorithme. Cependant, je ne connais pas suffisamment de choses sur l’algorithme pour m’y aventurer, mais il est bon de savoir que c’est possible.
Conclusion
Voilà un article entre science et logiciel libre. Je me devais de livrer au moins une fois des louanges de gnuplot. Malgré les logiciels que l’on m’a présenté comme miraculeux, j’y suis toujours revenu pour sa performance, sa flexibilité, son interopérabilité… je m’arrête là Par ailleurs, vous voyez que les ajustements sont en fait tout un art loin d’être trivial.
Allez, un article pour présenter mon tout dernier bureau sous LXDE. Un article en partie rédigé depuis longtemps et que j’avais annoncé à droite et à gauche, alors il est temps de le lâcher.
Pourquoi LXDE ?
Auparavant, j’étais un KDEiste convaincu. Aujourd’hui, je le reste pour leurs logiciels, mais relativement peu pour le bureau. Celui-ci est trop lourd à mon goût, et trop bling bling comme on dit. LXDE est pour moi une vraie bête de concours. Simple, léger, suffisamment paramétrable et sexy.
Menu Openbox
J’ai choisi de changer le menu (clic sur le bureau) qui par défaut est celui de LXDE (géré par PCManFM) par le menu de Openbox. Puisque LXDE se base sur celui-ci, c’est très simple. Dans PCManFM, le gestionnaire de fichiers : Edition > Preférences > Desktop > et on désactive la gestion du bureau. Un avantage est que l’on peut alors ajouter des bureaux très facilement par un clic droit sur le bureau. Le clic central permet quant à lui propose une autre présentation. Tout cela doit être largement paramétrable dans les fichiers de configuration d’openbox, mais je ne suis pas encore allé jusque là.
Fond d’écran
Avec le choix d’openbox pour gérer le bureau, le papier peint n’est plus géré. Il faut savoir que openbox ne gère pas cet élément esthétique. "Mais c’est trop nul !" meuh non, on va utiliser le programme feh pour cela.
@feh –bg-scale /home/user/Image/fond.jpg
On peut l’ajouter dans .~/config/lxpanel/lxsession/LXDE/autostart Rien de plus simple en somme… Le fond d’écran de aaron4evr utilisé ici provient de ce site et est disponible en licence CC BY-NC-ND
Terminal "Drop-down"
En guise de terminal pour les petites actions rapides, j’ai choisi Tilda. Dans Tilda, j’aime la manière dont je peux le paramétrer. C’est simple et efficace. Il gère en outre très bien la transparence. Je vois deux défauts : il ne semble plus être maintenu actuellement. La dernière version date d’avril 2008. De plus, il existe un bug qui empêche l’ouverture d’URL, ce que je trouve gênant. J’ai regardé rapidement le code ; la fonctionnalité n’est tout simplement pas implémentée. Un petit tour dans le code de lxterminal (la console de LXDE) montre que LXDE a repris une partie du code de tilda pour la gestion des URL, mais ce n’est guerre plus avancé. Pour ceux qui douterait de l’échange de code entre projets, voilà un formidable exemple ! Je regarderai cela plus en détail quand j’en aurai l’occasion, mais je ne maîtrise pas les API utilisées.
Un autre candidat est yakuake. Le projet est bien actif, mais j’ai trouvé la gestion du paramétrage très mauvaise car dispersée dans plusieurs menus. De plus, j’ai été incapable de gérer la transparence. Dans le panneau de configuration, il est indiqué que cela ne fonctionne qu’avec certains thèmes, mais même en changeant, rien n’y fait. Aucune information probante n’a été trouvé.
GNU Screen et Irssi
Je n’utilise pas les fonctionnalités fournies par tilda pour gérer les onglets. Je préfère utiliser GNU screen car cela me donne des raccourcis claviers que je pourrais retrouver dans d’autres situations (connection ssh, utilisation d’un autre Unix…). Irssi est actuellement lancé automatiquement dans irssi. Newsbeuter l’accompagne, mais je n’ai pas encore eu le temps de l’utiliser vraiment et de quitter thunderbird de ce coté. Pour la lacune de tilda dans l’ouverture des URL, j’utilise le petit script perl openurl.pl dans irssi (c’est sans doute là où la lacune est la plus contraignante).
Conky ou les informations sur le bureau
Conky permet d’afficher sur votre bureau divers informations telles que :
- Occupation du processeur/RAM/Disques durs
- Processus
- Heure, jour…
- Et tout autre texte que vous souhaitez afficher…
En effet, il est possible d’ajouter la sortie d’un programme. Certains vont par exemple afficher la musique jouée actuellement. Pour ma part, j’ai un calendrier et un fortune.
Le calendrier affiche deux mois consécutifs. Je n’utilise plus mon ancien script bash et le programme cal (que j’avais modifié et compilé à la barbare pour une question d’alignement), mais plutôt un script perl de Chipster que j’ai modifié à ma sauce afin justement d’afficher deux mois (rapidement, je dois rendre ça propre, mais ça tourne parfaitement). En effet, quand on se retrouve le 31, on est bien content d’avoir une idée de la semaine suivante
Pour fortune, je le fais lire un fichier personnel qui comporte de petites phrases (souvent des citations de séries ou films) afin de les mémoriser naturellement. Simple et efficace.
D’autres choses sont possibles, comme afficher une carte satellite sur votre bureau !
Conky peut être effrayant, mais une fois que l’on s’y met, c’est relativement simple. On peut d’ailleurs très bien s’en sortir en copiant collant des conkyrc données par de nombreux forumeurs (sur le forum d’archlinux par ex) et blogueurs. Je dirai que l’avantage certain de conky est la possibilité de changer de bureau et de retrouver son petit panneau d’informations sous KDE, GNOME etc.
Voilà, je suis preneur de tout commentaire.
Adhérer April
CC-BY-SA
La Quadrature du Net
Planet-libre
Wikio
