AviBlog

En vrac

Plusieurs choses en vrac pendant que j'y pense

Read More

Les joies des mises à jour

J'ai eu l'idée saugrenue de mettre à jour le PC de ma chère et tendre qui tourne sur Kubuntu, vers la dernière 10.04LTS. Avec un lot de problèmes associés.

Read More

Mise à jour de la traduction progit

Voila le travail de traduction en cours (une compil au vol) du livre progit avec :

• Traductions par votre serviteur jusqu'au chapitre 5
• Premier jet des traductions des figures

Vous pouvez le télécharger ici

Tout commentaire, fichier d'annotation okular est bienvenu.

MàJ : Le fichier d'origine a été remplacé par un lien sur la section téléchargement du dépôt de trad française de progit.

Blog en cours de migration

Voilà, j'ai commencé la migration, mais ça ne se passe pas sans mal.

Principalement, j'ai deux gros points de résistance :

• Le nouveau moteur est prévu pour tourner sur php5, tandis que les pages perso de Free ne proposent que php4. Du coup, il y a un certain nombre de fonctions qui n'existent pas ou dont la signature n'est pas correcte. Résultat, il semble que j'ai perdu l'encodage correct de mes billets dans la migration.
•  Free applique une politique de sécurité en désactivant des fonctions et fonctionnalités de php. Résultat : certaines fonctions telles que flock renvoient des erreurs.

Ça va donc tanguer pendant quelques temps...

Python, la puissance du langage

Pour graffle2svg , j’ai besoin de parser du RTF (format pseudo ouvert). En gros, pour définir les couleurs de police, je dois transformer une déclaration du type

defn= '{\colortbl;\red255\green255\blue255;\red75\green75\blue75;}foo'

en un tableau du type [”#000000”, “#ffffff”, “#4b4b4b”] (le premier point-virgule signifie déclaration vide, donc couleur par défaut).

En python, avec les expressions rationnelles, c’est limpide :

endidx = defn.find("}", startidx)
primitive_reg = re.compile(r"(\D+)(\d+)")
for colordef in defn[startidx-1:endidx-1].split(";"):
    color = {'red':0, 'green':0, 'blue':0}
    for primitivedef in colordef.split('\\'):
         primitive_match = primitive_reg.match(primitivedef)
         if primitive_match is not None:
            primitive, value = primitive_match.groups()
            color[primitive] = int(value)
    self.color.append("#%02x"%color['red'] + "%02x"%color['green'] + "%02x"%color['blue'])

Dix lignes, pas mal !

-i : l'option de Git qui sauve les bordéliques

Imaginez un gars qui code (n’allez pas chercher loin), mais qui n’arrive pas à développer de manière organisée. Bien sur, ce type utilise déjà une gestion de version pour limiter les dégâts, genre git.

Mais, n’empêche, quand il commence à modifier son projet, il papillonne à droite et à gauche, si bien que sa copie de travail ressemble assez rapidement à un champ de bataille. On lui a pourtant dit qu’il fallait mieux créer une branche de développement par sujet de modification pour travailler plus efficacement, mais le naturel étant ce qu’il est, sa copie de travail rassemble souvent des modifications liées à des sujets différents, voire pire, des modifications dans le même fichier…

Et c’est là que Git lui sauve encore la mise. Avec l’option -i de la commande add, il peut revoir chaque section modifiée d’un fichier et décider de l’inclure ou non dans son prochain commit. Et voilà comment on redonne forme à un tas des modifications !

Maintenant, poussons le bouchon un peu plus loin : même avec cette option magique, notre développeur a effectué une suite de validations sans queue ni tête. Il n’a rien publié encore, le résultat de ses élucubrations n‘étant vraiment pas prêt pour être vu par ses pairs. git rebase -i à la rescousse ! Avec cette commande, il peut réécrire son historique de validation, modifiant tel commit, fusionnant deux commits qui se rapportent au même sujet, divisant un commit mal formé.

Avec ses options magiques, il devient possible de rendre limpide et présentable ce qui au départ se présentait comme un travail expérimental…

Et on ne m'a rien dit

Certains savent que lors du lancement de mon blog, j'ai opté pour un moteur atypique : "pivotlog":http://www.pivotlog.net/ J'étais étonné de ne pas voir arriver de mises à jour depuis un certain temps, mais ce n'est que ce soir que j'ai appris que j'étais sur une branche morte de développement, le nouvel axe se nommant à présent "PivotX":http://www.pivotx.net . Il y a les instructions pour un migration, ce qui va bientôt s'avérer nécessaire... J'en profiterai pour me repayer une petite mise en page maison. À suivre.

Dix ans d'ignorance

En regardant cette présentation , j'ai fait plus qu'apprendre une chose, j'ai surtout corrigé une misconception flagrante. Dans mon esprit, quand des fonctions non appelées dans un programmes sont compilées, elles disparaissent du programme final. C'est le comportement par défaut en Pascal, et mes années Delphi m'y ont habitué. Mais ce n'est pas le cas partout. Mais comme l'explique l'intervenant, depuis l'origine d'Unix, le linker à toujours géré les sections de code comme un container unique de symboles. Par défaut, il intègre tous les fichiers objets qui lui sont passés... Grâce à l'option du linker ??-gc-sections??, on peut déjà éliminer les sections dont aucune fonction n'est appelée mais si un symbole du container est appelé, alors tout le container est inclus dans le code final. Pour mimer le fonctionnement de Pascal, il faut en plus passer à gcc les options ??-ffunction-sections -fdata-sections?? pour le forcer à mettre chaque fonction et chaque variable globale dans sa propre section et ainsi permettre au linker de laisser choir les fonctions non appelées. Cependant, et la conférence ne l'aborde pas, cette option a des effets néfastes sur les capacités de debug et de profilage. Bref, je présente mes excuses aux personnes nombreuses à qui j'ai pu soutenir que gcc avait une intelligence intégrée qu'il ne présente effectivement pas.