Faire connaître une extension à Gedit pour la coloration syntaxique
Suite au développement d’un nouveau langage, j’ai créé la coloration syntaxique associée. Je la charge dans le répertoire contenant les .lang de gedit (/usr/share/gtksourceview-X.Y/language-specs/) et si je demande à gedit de les colorer fichier par fichier, ça marche. Mais à chaque réouverture de fichier, je suis obligé de déclarer le type de coloration voulue.
On trouve de nombreux tutoriels pour la création de coloration pour Gedit (http://doc.ubuntu-fr.org/creer_un_jeu_de_couleurs_pour_gedit par exemple). Mais pas grand chose sur la reconnaissance des extensions. Je vais ici faire fonctionner la reconnaissance pour un utilisateur unique.
Je vais juste montrer la ligne indiquant le nom associé à l’extension dans les fichiers .lang :
<language _name="Xxx tongue" mimetypes="text/x-xxx">
Ici, le nom du langage est x-xxx. Il va falloir ensuite indiquer un mime type pour que les extensions .xxx comme étant des fichiers x-xxx.
Pour cela, on crée un fichier xxx.xml comme suit :
<?xml version="1.0" encoding="utf-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="text/x-xxx">
<comment>xxx file</comment>
<glob pattern="*.xxx"/>
<acronym>XXX</acronym>
<expanded-acronym>XXX File</expanded-acronym>
</mime-type>
<mime-info>
Dans le glob pattern on donne les extensions associées au type : *.xxx ici.
Ce fichier est placé dans ~/.local/share/mime/packages/.
Puis on effectue les commandes suivantes :
#!/bin/bash cd ~/.local/share update-mime-database mime/
Ici on affecte que les variables de l’utilisateur (dans le ~/.local). Afin de vérifier que l’extension est bien reconnue, on lance la commande suivante sur un fichier ayant la bonne extension :
#!/bin/bash touch ~/a.xxx<code> gnomevfs-info ~/a.xxx rm ~/a.xxx
Le résultat de la commande donne dans la rubrique MIME-TYPE :text/x-xxx.
Ensuite, en ouvrant les fichiers avec la bonne extension avec Gedit, nous avons la bonne coloration syntaxique.
Code::blocks problème avec la touche espace
Si vous utilisez code::blocks, il est possible que la touche espace ne fonctionne pas pour faire des espaces mais seulement pour l’auto-complétion. Si vous rencontrez ce problème, il faut désactiver le plugin code completion, en attendant mieux.
Allez dans le menu plugin, puis manage plugins et mettre code completion à disable.
EDIT : Comme indiqué dans les commentaires, enlevez le plugin est une mauvaise idée. Mais en attendant, ça fonctionnait.
On m’a indiqué de modifier le clavier du système (France autre par défaut, par France). Pour cela, sous Gnome, allez dans : Système -> Préférences -> Clavier.
Sous unity, dans la barre de recherche des programmes, tapez juste clavier et vous obtenez le bon programme.
Allez dans l’onglet agencement et cliquez sur ajouter, choisir France et le faire monter.
Et ça devrait fonctionner.
Et voici le lien donné par Cenwen (encore merci!), http://www.siteduzero.com/forum-83-671936-p1-probleme-avec-code-blocks-sous-linux-espace-ne-marche-pas.html.
Si vous faîtes de la mise en donnée massive ou que vous avez parfois besoin de modifier la même occurrence dans beaucoup de fichiers en simultané. Voici un petit script qui peut vous aider.
Le problème est simple rechercher tous les fichiers dans une sous-arborescence de répertoires avec find afin d’y modifier une occurrence avec sed.
#! /bin/bash # On vérifie que le bon nombre d'arguments a été envoyé au script. if [ $# -ne 3 ] ; then echo " Usage : " $0 " 'FILES' 'STRING TO REPLACE' 'REPLACEMENT STRING' " exit fi # On charge les arguments FILE=$1 TEXTE=$2 REPLACE=$3 # Oncherche l'ensemble des fichiers concernés. FILES=`find -name "$FILE"` # On applique les modifications for i in $FILES; do sed "s/$TEXTE/$REPLACE/g" "$i" > tmp mv tmp $i done
Pour se servir du script :
script.sh ‘*.txt’ ‘Salut mon amour’ ‘Adieu traîtresse’
Qui permettra de modifier toutes vos lettres d’amour en une commande. ![]()
Bon le script doit être améliorable en modifiant directement le fichier sans passer par tmp et le find peut être améliorer à souhait.
Utiliser OpenMP avec Code::Blocks
Afin d’accélérer un code sans entrer dans une ingénierie trop développée, j’ai décidé d’utiliser OpenMP pour paralléliser des tâches et casser des boucles. Ceci peut être très avantageux, sur un bi-processeur, mon code a réduit de 72 % son temps d’exécution . Je ne sais pas pourquoi mais par défaut (constaté sous Windows seulement) mon programme se lance sur le processeur occupé. En parallélisant, le processeur totalement libre est utilisé (d’où un gain supérieur à 50% en utilisant schedule et sections). J’ai probablement un montage particulier sur la machine en question.
Afin de tester la bonne portabilité de ce code, j’ai voulu le tester sous Ubuntu. Je vais donc dans ce petit billet vous expliquer comment utiliser OpenMP avec Code::Blocks sous Ubuntu (et probablement d’autres distributions GNU/Linux) et sous Windows.
Ce billet concerne la version 10.05 de Code::Blocks.
Sous Ubuntu
Installer OpenMP GNU GCC :
sudo apt-get install libgomp1 # pour les 32 bits sudo apt-get install lib64gomp1 # Pour les 64 bits
Installer GNU GCC (ou autre).
Installer Code::blocks:
sudo apt-get install codeblocks
On va compiler le hello_world suivant:
#include <iostream>
#include <omp.h>
using namespace std;
int
main () {
int nthreads, tid;
/* Fork a team of threads with each thread having a private tid variable */
#pragma omp parallel private(tid)
{
/* Obtain and print thread id */
tid = omp_get_thread_num();
cout << "Hello World from thread " << tid << endl;
/* Only master thread does this */
if (tid == 0)
{
nthreads = omp_get_num_threads();
cout << "Number of threads = " << nthreads << endl;
}
} /* All threads join master thread and terminate */
return 0;
}
Code::Blocks repère les compilateurs classiques installés à son lancement. Donc, il n’y a rien à faire de ce point de vue.
Collez le code ci-dessus dans main.cpp (après avoir créer le projet hello_omp).
Il va falloir maintenant indiquer que nous utilisons OpenMP et où se trouve la librairie. Dans le menu, project -> Buid options, aller dans l’onglet Compiler Settings, sous onglet Other options et mettre -fopenmp comme sur l’image suivante.
Ensuite, aller dans l’onglet Linker Settings et cliquer sur add pour indiquer où se trouve libgomp1.so. Voir image ci-dessous. Pour trouver libgomp.so, dans un terminal, tapez : locate libgomp. Prendre lalirairie se situant dans votre dernière version de GCC.
Pour moi ce chemin est : /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/libgomp.so
Voilà, vous pouvez compiler, vous obtiendrez le résultat suivant :
Hello World from thread Hello World from thread 10 Number of threads = 2
Comme on peut le voir la résolution parallèle de l’affichage Hello se superpose.
Sous Windows
C’est globalement la même chose sauf qu’il faut réinstaller MinGW.
Vous installez Code::Blocks avec l’installeur récupérer sur le site en lien au début du billet. Par défaut, Code::Blocks installe MinGW. Mais ce n’est pas une version assez récente pour supporter OpenMP.
Il faut donc récupérer un version plus récente de MinGW, par exemple là : http://www.tdragon.net/recentgcc/
Installer cette version non officielle de MinGW dans C:\MinGW.
Aller dans le répertoire de Code::Blocks (C:\Program files\Codeblocks) et supprimer le répertoire MinGW. Copier le répertoire C:\MinGW en lieu et place de celui que vous venez de supprimer. Pour ma part, j’ai d’abord changer le MinGW en MinGW_save au cas où.
Ensuite, créez le projet hello_omp et mettez le code ci-dessus dans le main.cpp.
Aller dans Project -> Build options, pour ajouter comme précedemment -fopenmp à l’endroit désigné par la première photo. Si vous ne voulez compiler que des programmes avec OpenMP, vous pouvez mettre ces options en dures dans Settings -> Compiler and debugger (valable aussi pour GNU/Linux) avec la fenêtre suivante.
Ensuite, on indique où se situe la DLL gomp1.dll. Comme sur l’image ci-dessous ou comme sur la seconde image du billet.
Chez moi l’adresse de la DLL est : C:\Program Files\CodeBlocks\MinGW\bin\libgomp-1.dll
Plus qu’à compiler et voir l’affichage pas terrible obtenu.
Bonne compilation.
Montage NFS sur réseau local
Afin de simplifier les échanges de données entre les PC de la maison, j’ai réalisé un montage NFS des espaces à partager. Le montage NFS permet d’accéder çà un disque dur physiquement comme s’il était sur la machine de travail, tandis que l’espace est sur un “serveur”.
J’ai changé récemment de PC, et je n’ai pas la volonté de transférer le disque dur. Afin d’accéder aux données sur l’ancienne machine, ceci est le plus simple. Mes deux machines ne sont pas toujours allumés, ceci est aussi une spécificité du montage qui va être fait.
Pour commencer, il faut installer les paquets nécessaires :
Sur le serveur:
sudo apt-get install nfs-common nfs-kernel-server
Sur le client :
sudo apt-get install nfs-common
Ensuite il faut réaliser les manips suivantes sur le serveur:
sudo gedit /etc/exports
Et on ajoute :
/Répertoire_à_partager_sur_Serveur/ 192.168.0.1/20(rw,all_squash,anonuid=1000,anongid=1000,sync)
Le premier élément est le répertoire que nous voulons partager, le second la ou les adresses IP autorisées à faire le montage (on peut mettre une seule IP 192.168.0.1, une plage d’IP sous la forme 192.168.0.1/20 ou 192.168.0.*). Le montage peut se faire simultanément sur plusieurs machines. Avec l’option rw les utilisateurs du montage peuvent lire et effacer des données en ne mettant que r, ils ne pourront que lire (et donc rien supprimer ou ajouter).
On redémarre le client:
sudo /etc/init.d/nfs-kernel-server restart
Il faut ensuite gérer la sécurité du système, en modifiant les fichiers /etc/hosts.deny et /etc/hosts.allow:
sudo gedit /etc/hosts.deny
Et on ajoute :
portmap:ALL nfsd:ALL mountd:ALL
sudo gedit /etc/hosts.allow
Et on ajoute :
portmap: 192.168.0.1/20 lockd: 192.168.0.1/20 nfsd: 192.168.0.1/20 mountd: 192.168.0.1/20 rquotad: 192.168.0.1/20 statd: 192.168.0.1/20
En mettant bien les IP correspondant à votre exportation, bien sûr.
Maintenant on va sur le client :
On crée le point de montage:
mkdir /home/partage/
On modifie la table des montages :
sudo gedit /etc/fstab
Et on ajoute à la fin :
192.168.1.1:/Répertoire_à_partager_sur_Serveur /home/partage nfs user,noauto 0 0
Où 192.168.0.1 est l’IP du serveur.
Mettre noauto rend le montage nfs manuel. Si le serveur est forcément allumé lorsque ce PC est mis en marche, vous pouvez mettre auto et le montage se fera tout seul. Le fait de mettre user avant noauto autorise tout compte de la machine à réaliser le montage nfs. Si vous voulez restreindre cette possibilité, créez un groupe nfs et incluez-y les comptes voulus.
Si vous conservez comme moi, l’option noauto, il faut créer un lanceur, à l’endroit voulu (par exemple /usr/bin pour être dans $PATH):
sudo gedit /usr/bin/mount_nfs
Et mettre dedans :
#! /bin/bash mount /home/partage
Ensuite rendez le script éxecutable :
sudo chmod +x /usr/bin/mount_nfs
Lancez la commande
mount_nfs
Et vous avez accès au montage.
J’ai des fichiers stockés sur un montage NFS. Ce type de montage est pratique. Seulement, l’augmentation du nombre de démons NFS peut saturer le réseau en direction de la machine hébergeant le montage (voire la machine elle-même).
Afin de réduire le nombre de démon NFS, lorsqu’on travaille sur une machine vers laquelle le montage est exporté et qu’on a un nombre conséquent de fichiers à compresser une solution est d’aller travailler sur l’hôte. Pour faciliter cela, j’ai réalisé les scripts suivants :
Pour la compression (choix de gzip).
#! /bin/bash
# FONCTION PAS FORCEMENT UTILE
compressd () {
for i in "$@"
do
gzip $i
done
}
dir=`pwd`
NFS="192.168.0.3" # IP A MODIFIER
# TEST SI ON EST SUR LA BONNE MACHINE
if [ "$(hostname)" == $NFS ]; then
compressd $@
else
ssh -t $NFS -- "cd \"$dir\"; gzip \"$@\"; "
fi
Pour la décompression :
#! /bin/bash
#Usage : Faire un alias sur le fichier alias extract="bash extract.sh"
# extract <fichier>
extractd () {
if [ -f $1 ] ; then
case $1 in
*.tar.bz2) tar xvjf $1 ;;
*.tar.gz) tar xvzf $1 ;;
*.tar.xz) tar xvJf $1 ;;
*.bz2) bunzip2 $1 ;;
*.rar) unrar x $1 ;;
*.gz) gunzip $1 ;;
*.tar) tar xvf $1 ;;
*.tbz2) tar xvjf $1 ;;
*.tgz) tar xvzf $1 ;;
*.zip) unzip $1 ;;
*.Z) uncompress $1 ;;
*.7z) 7z x $1 ;;
*.xz) unxz $1 ;;
*.exe) cabextract $1 ;;
*) echo "\`$1': unrecognized file compression" ;;
esac
else
echo "\`$1' is not a valid file"
fi
}
NFS="192.168.0.3" # IP A MODIFIER
# TEST SI ON EST SUR LA BONNE MACHINE
if [ "$(hostname)" == $NFS ]; then
extractd $@
else
ssh -t $NFS -- "cd \"$dir\"; extract \"$@\" ; " # Attention il faut le même alias sur toutes les machines!!!
fi
Il faut ensuite faire attention à bien gérer les alias sur les machines. Avec un peu de chance $HOME/.bashrc est sur le montage NFS.
Compiler un programme OpenCV avec code::blocks sous Windows
OpenCV est une librairie graphique multi-plateforme et je m’en sers pour une application qui doit pouvoir tourner à la fois sur Linux et Windows (http://opencv.willowgarage.com/wiki/).
Pour utiliser OpenCV sur Linux, c’est très simple.
sudo apt-get install libhighgui-dev sudo apt-get install libcv-dev sudo apt-get install libcvaux-dev
Et pour compiler un programme utilisant OpenCV :
g++ -o hello_world hello_world.cpp `pkg-config --cflags --libs opencv`
Ce qui revient à :
g++ -o hello_world hello_world.cpp -I/usr/include/opencv -lml -lcvaux -lhighgui -lcv -lcxcore
Pour utiliser OpenCV sous Windows, c’est moins simple.
Après avoir installer OpenCV, ajouter dans les variables d’environnement à la variable PATH le chemin suivant (chemin par défaut de l’installeur) :
C:\OpenCV2.2\bin
Ensuite lancer Code::Blocks, charger votre code qui utilise OpenCV et HighGui.
Il faut maintenant le compiler:

Faîtes un clic droit sur votre_prog (ici test_opencv) et aller dans “Build options”.
Faîtes les ajouts suivants :

Et ceux-ci:

Voilà, vous pouvez désormais compiler votre programme.
localepurge – espace disque faible
Je suis arrivé à manquer d’espace disque sur ma partition principale. J’ai donc lancé les classiques:
sudo apt-get clean sudo apt-get autoclean sudo apt-get autoremove
Je n’ai rien gagné! J’assure au moins les bases sur mon système.
Après quelques recherches, j’ai trouvé l’existence de localepurge (disponibles dans les dépôts Ubuntu).
Je l’installe en lui demandant de garder les variables en fr_FR*. Et le lance. J’obtiens :
localepurge: Disk space freed in /usr/share/locale: 82396 KiB localepurge: Disk space freed in /usr/share/man: 4496 KiB localepurge: Disk space freed in /usr/share/gnome/help: 22360 KiB localepurge: Disk space freed in /usr/share/omf: 2944 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 3760 KiB Total disk space freed by localepurge: 115956 KiB
Un gain de 115 Mo, c’est toujours ça de pris.
En analysant mon disque dur c’est .local/share/gvfs-metadata qui prend le plus de place.
Les conseils que je vois sont de purement et simplement le supprimer.
Quel en est votre expérience? Comment au moins réduire sa taille?
Je n’ai pour le moment rien tenter.
Retarder le Swap
Afin de contrôler la manière dont le kernel gère la swap, il existe le paramètre swappiness.
Ce paramètre contrôle la tendance qu’aura le kernel a délesté des processus hors de la RAM vers la SWAP. le fait de swapper ralentit énormément les processus, car les vitesses d’accès aux disques durs sont beaucoup plus lent que les vitesses d’accès à la RAM.
La swappiness peut avoir une valeur comprise entre 0 et 100. A 100, le kernel swappera dès que possible. A 0 le kernel ne swappera jamais.
Il peut être dangereux de ne pas swapper s’il est possible de remplir sa mémoire vive. Par contre swapper continuellement ralentit les processus. D’expérience, j’ai vu certains de mes processus être 20 fois plus lents à cause de la SWAP.
Par défaut dans Ubuntu, la valeur de la swappiness est de 60. C’est une valeur tout à fait raisonnable. Si vous connaissez bien votre gestion de la mémoire, je vous laisse juger de la valeur idéale. Par contre, si vous êtes un utilisateur qui ne remplit jamais sa RAM, il faut réduire cette valeur. Chez moi, j’ai 2 Go de RAM, je sais que je ne dépasse jamais les 1.6 Go d’utilisé. J’ai donc descendu la valeur à 15. Je ne swapperais que si je dépasse les 1.7 Go d’utilisation.
Pour vérifier votre valeur de la swappiness
more /proc/sys/vm/swappiness
Pour changer temporairement sa valeur, on revient au défaut à chaque redémarrage.
sudo sysctl vm.swappiness=15
Pour rendre le changement permanent:
sudo gedit /etc/sysctl.conf
On cherche vm.swappiness dans le fichier et le modifie, s’il n’existe pas, ajoutez le.
vm.swappiness=15
On sauvegarde et la valeur sera effective au redémarrage suivant.
En passant, pour accélérer le boot, j’ai fait ça aussi :
sudo gedit /etc/init.d/rc
Et j’ai remplacé CONCURRENCY=none par CONCURRENCY=shell (apparemment obsolète mettre startpar). Ça n’a rien à voir avec la SWAP et la différence est dure à voir.
Sûrement comme vous, mon écran me casse les yeux le soir. ![]()
Suite à une série de billets sur le sujet, j’ai voulu essayer les deux programmes les plus présentés.
Pour cela, j’ai chercher Redshift dans les dépôts Ubuntu.
Après installation, pour l’essayer :
redshift -l LAT:LON
On obtient les valeurs de sa latitude et Longitude sur de nombreux sites de géolocalisation.
En quelques secondes, la couleur de l’écran change pour devenir moins agressive (si c’est le soir).
Par contre, il faut un temps d’adaptation pour ne pas être gêné par ce changement de couleurs.
Pour installer f.lux, j’ai choisit la version en ligne de commande, qu’on installe comme suit:
wget -c https://secure.herf.org/flux/xflux.tgz
tar -xvzf xflux.tgz
rm -rf xflux.tgz
sudo cp xflux /usr/bin/
sudo chmod 755 /usr/bin/xflux
On lance le programme, comme suit:
xflux -l LAT, LON
Il faut avoir arrêté Redshift précédemment, bien sûr.
Conclusions:
J’ai choisit f.lux, car le programme est moins agressif que redshift sur l’adoucissement des couleurs.
Quelque soit votre choix, c’est très efficace et l’impact visuel des premières secondes s’estompe rapidement.
Je conseille très fortement d’ajouter la ligne de commande qui va bien dans vos programmes au démarrage.
Petit aparté, si quelqu’un connaît un équivalent pour windows, pour les malchanceux au travail.



