J’écris un court article sur un problème que je viens de rencontrer avec CMake qui m’a semblé étrange…
Continuer la lecture de Petit souci avec CMake : le passage au C++11
Archives de catégorie : Utilitaires
Petit précis du Git pratique
Git est un très bon logiciel de gestion de versions décentralisé qu’on ne présente plus (et pour ceux qui ne connaissent pas, il est toujours temps d’aller découvrir l’abondante documentation du projet), d’ailleurs créé par Linus Torvalds (qu’on ne présente plus non plus) et qui a depuis fait ses preuves pour gérer des projets d’une taille conséquente (comme, on pourrait le deviner, le kernel Linux).
Mais git est avant tout un outil très riche, et il n’est pas évident de maîtriser toutes ses spécificités – encore faut-il savoir qu’elles existent ! Les commandes Git, reposant en soi sur les mêmes principes que la plupart des VCS (ou logiciels de gestion de versions) et a fortiori des DCVS (VCS décentralisés), proposent beaucoup d’options utiles qui peuvent simplifier la vie des utilisateurs et de ceux qui utilisent un dépôt Git avec vous.
Voici donc un petit hall of fame des options que je suis bien content de connaître dans Git.
Quassel: No DockManager available
Il m’est arrivé un drôle de tour ce matin…
J’utilise Quassel IRC, un client IRC connecté à un serveur distant, ce qui permet notamment d’apparaître connecté et de lire ce qui s’est dit lorsque vous n’êtes pas là.
Le problème du jour n’est pas là : sur ma bonne vieille Ubuntu utilisant sa bonne vieille interface Unity, aujourd’hui, Quassel refuse de démarrer. Enfer et damnation.
Ou plus exactement : il se lance, mais sans fenêtre ! Il apparaît bien dans la liste des processus lancés, mais nulle part sur l’interface graphique, impossible d’interagir avec.
Lorsqu’on lance le programme (quasselclient) en console, une unique ligne cryptique apparaît : « No DockManager available » . Après quelques recherches, j’apprends que c’est un bug connu, mais réputé résolu et datant d’un autre âge… Mais alors quand on y est quand même confronté, que faire ?
Mon salut est tout simplement venu d’un « wipe out » : dans mon cas (Ubuntu), je suis allé dans le dossier de config de Quassel (~/.config/quassel-irc.org), et j’ai effacé tous les fichiers de config de Quassel comme un gros bourrin (rm *) !
Et là, pif paf pouf, après ça mon Quassel a remarché. Comme par magie. Bon évidemment je n’avais rien de très important dans ce dossier, mais n’oubliez pas de faire une sauvegarde ailleurs si vous essayez.
À bon entendeur…
Elluminate et Ubuntu
(La seule raison pour laquelle cet article est en rapport avec Québec, c’est qu’il parle de la plate-forme de cours en ligne utilisée à l’université : Elluminate)
Donc, étant actuellement sur une Ubuntu (et essayant vraiment de démarrer Windows aussi rarement que possible), j’aimerais dédier ce court article à quelques problèmes qu’on peut recontrer sur Ubuntu (13.04 ici) en se servant de Elluminate, la plate-forme de cours à distance utilisée pour les cours à l’université Laval…
Publier la documentation Doxygen d’un projet sur sa page Github
Je travaille actuellement sur un projet documenté avec Doxygen et hébergé sur Github.
Doxygen est un outil de documentation assez puissant qui permet de générer des documentations en HTML ou en LaTeX par exemple. Perso je trouve ça assez rude de juste publier le Doxyfile (le fichier de configuration à donner à Doxygen pour générer la doc) du projet et de laisser les gens la générer eux-mêmes (à leur place, j’aurais la flemme). En attendant, ce n’est pas un projet suffisamment gros pour nécessiter un site Web entier à lui tout seul.
Comment faire alors pour rendre la documentation déjà toute faite disponible au plus grand nombre ? C’est sans compter que chaque projet hébergé sur Github peut avoir une page web qui lui est dédiée. Github propose une page web pour chaque projet, Doxygen permet de générer des docs en HTML.
Vous avez compris en quoi consiste la manip ? Remplaçons la page Web par défaut de Github pour y héberger notre documentation Doxygen !
Continuer la lecture de Publier la documentation Doxygen d’un projet sur sa page Github
Installer la bibliothèque Google Test sur Ubuntu
Hello,
aujourd’hui j’ai voulu essayer d’installer la bibliothèque de tests unitaires produite par Google, googletest.
J’ai donc installé l’archive disponible sur leur page Google Code, et ai tenté de lancer la version Makefile de l’installation (étant sur Ubuntu)…
Et là, quelle ne fut pas ma surprise en voyant une flopée d’erreurs sortir de g++:
/home/baron_a/gtest-1.6.0/make/../include/gtest/internal/gtest-port.h:1379: undefined reference to `pthread_setspecific’
collect2: error: ld returned 1 exit status
Heureusement, cela semble être un problème bien connu et la résolution est simple: dans le Makefile de gtest il faut remplacer dans la (les?) ligne(s):
sample1_unittest : sample1.o sample1_unittest.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
l’option -lpthread par l’option -pthread (retirer le petit L au début, quoi, en gros), et voilà ça fonctionne ! \o/ Je me demande si ils le corrigeront un jour… Notez d’ailleurs qu’il y a d’autres moyens d’installation fournis, comme un CMakeLists.txt pour utiliser CMake.
J’ai également vu qu’il y avait un paquet nommé libgtest-dev dans Aptitude, mais je ne l’ai pas installé pour essayer.
For the World Is Hollow and I Have Touched the Skype (Ubuntu 13.04)
Aujourd’hui, un nouveau billet dans la catégorie « les petits problèmes de la vie de tous les jours sous Ubuntu »…
Cette fois-ci avec Skype, le célèbre logiciel de messagerie instantanée. J’ai d’abord eu des difficultés pour l’installer sur Ubuntu 13.04, pour ensuite me rendre compte que les notifications marchaient pas. Comment résoudre ces problèmes ? La réponse dans la suite !
Continuer la lecture de For the World Is Hollow and I Have Touched the Skype (Ubuntu 13.04)
Vérifier si une commande contient du texte ou pas en LaTeX
En ce moment, pour les besoins de mon projet de fin d’études, nous sommes en train de construire un template LaTeX afin d’avoir un truc modulable et facilement réutilisable pour tous les documents et rendus que nous avons à fournir aux professeurs niveau suivi.
Dans ce template LaTeX, il est pour le moment possible d’inclure dans le header de chaque page (fait avec le paquet fancyhdr au passage, peut-être que je ferai un autre article dessus) le logo du projet, et le logo d’un partenaire (dans notre cas, le LabEIP, instance d’Epitech nous suivant sur notre projet de fin d’études, l’EIP).
Inclure une image en LaTeX est relativement facile :
[cc lang= »latex »]
\newcommand{\PartnerLogo}{logo_eip.png}
\includegraphics[height=35pt]{\PartnerLogo}
[/cc]
Les problèmes arrivent lorsqu’on n’a pas de logo à mettre, ou qu’on n’a pas encore l’image, etc… tout en voulant conserver notre template et le garder le plus réutilisable possible, car la commande \includegraphics râle si on lui passe une chaîne vide.
[cc lang= »latex »]
\newcommand{\PartnerLogo}{}
\includegraphics[height=35pt]{\PartnerLogo} %% ça ne marche pas !
[/cc]
Une solution est d’utiliser le paquet etoolbox: il contient la commande \ifdefempty permettant de savoir si le résultat d’une commande est une chaîne de caractères vide ou pas, et de faire une action appropriée le cas échéant.
En pratique, ça s’utilise comme ça :
[cc lang= »latex »]
\ifdefempty{\PartnerLogo}
{} %% si aucun fichier n’est spécifié, on ne fait rien
{
\includegraphics[height=35pt]{\PartnerLogo} %% sinon, on affiche l’image
}
[/cc]
Et voilà, maintenant je peux aussi facilement utiliser mon template pour un projet où je n’ai pas de logo à mettre 😉
zsh: command not found: virtualenv
Je me refais une petite installation Linux en ce moment.
Au moment d’installer virtualenv, ce paquet très pratique pour Python, je suis resté sur le cul en ne voyant pas la commande « virtualenv » s’auto-compléter dans le terminal, et en voyant ça s’afficher si j’essaye quand même de la taper :
zsh: command not found: virtualenv
Enfer et damnation ! Comment cela se peut-il, je viens de l’installer ?
En fait la raison est plutôt bête, étant donné que je l’ai installé avec l’option –user de pip (non, ceci n’est pas un article sponsorisé par Sam&Max…), il est allé s’installer dans ~/.local/bin, plutôt que dans les dossiers généraux du système (pour qu’il ne soit installé que pour mon utilisateur), et mon PATH ne contenait pas (encore) ce dossier.
À partir de là la solution est triviale : il suffit de rajouter 2 petites lignes dans son .zshrc (ou le fichier de config du shell qu’on utilise, en gros)…
[cc lang= »bash »]
PATH=PATH:~/.local/bin
export PATH # il se peut que la syntaxe soit différente pour les shells utilisant setenv (tcsh, etc.)
[/cc]
puis de relancer la config du shell…
[cc lang= »bash »]
source ~/.zshrc
[/cc]
et pouf youplaboum ça y est ça fonctionne !
Mais c’est con comme problème…
« Ah… Ok … »
Parfois, je trouve que certaines choses sont vraiment débiles…
Débarquant récemment sur une Fedora toute fraîche (et oui, j’ai fini par mettre ma Debian à la retraite), je tente de lire un DVD commercial lambda sous VLC et… oups, ça ne marche pas !
Cascade d’erreurs comme quoi le média ne peut pas être lu.
Un problème classique sur Linux : les DVD du commerce sont chiffrés et dans la grande majorité des cas, une distribution Linux ne propose pas de base le paquet permettant de les décoder.
Bref, installation de ce fameux paquet, répondant au doux nom de libdvdcss.
Ça ne marche pas.
Passage par divers dépôts pour installer à peu près tous les codecs de la création…
Ça ne marche toujours pas.
Mon salut est venu au détour d’un forum technique… Le device utilisé par défaut par VLC pour la lecture des DVD est « /dev/dvd », visible comme entrée par défaut de la liste labelisée « Disc device » dans le menu « Open Disc ». J’ai changé cette entrée pour la dernière de la liste, « /dev/sr0 » (qui désigne, en effet, le lecteur CD également) et… Paf, ça marche.
Je crois que plusieurs images sont nécessaires pour exprimer mon sentiment à ce moment-là…
Ah, ça va mieux après !