Outils

Outils Markdown pour Notepad++

Il y a très longtemps, j’avais parlé des outils XML pour Notepad++. Parlons aujourd’hui des outils Markdown !

Coloration syntaxique

Il n’y a pas de coloration syntaxique pour ce langage par défaut…

npp md avant

Avant…

On va commencer par remédier à ce défaut ! Notepad++ permet de définir des langages utilisateurs pour permettre la coloration syntaxique des langages non supportés nativement. On parle de « User Defined Language« .  Le dépôt GitHub markdown-plus-plus fournit plusieurs fichiers XML contenant des définitions de « User Defined Languages » pour le markdown. La section Usage du README explique comment importer ces fichiers.

Il est ensuite possible de sélectionner ce nouveau langage depuis le menu Langage. Il est sélectionné automatiquement si votre fichier porte l’une des extensions indiquer dans la configuration du langage importée. Il est possible d’en rajouter si jamais vous le souhaitez.

npp md apres

À mi-chemin

Visualisation

Maintenant que le texte est correctement coloré, il ne reste plus qu’avoir une visualisation du rendu ! Il existe un autre dépôt GitHub avec tout ce qu’il faut : MarkdownViewerPlusPlus ! Comme précédemment, le README vous explique tout ce que vous devez savoir.

Une fois le plugin installé et Notepad++ redémarré, un petit bouton avec un M blanc sur fond noir apparaît dans la barre d’outils. Il permet d’ouvrir la fenêtre de visualisation.

npp md apercu

Fini !

Aide-mémoire

En bonus, n’oublie pas de mettre ce Markdown Cheatsheet dans vos marque-pages !

Publicités

Mes plugins Eclipse

Cela fait des années que j’utilise Eclipse, par choix ou par obligation. On dira ce qu’on voudra, c’est quand même un IDE très puissant et la multitude de plugins disponibles contribue à sa versatilité quand tu travailles avec plusieurs langages pour un même projet. Cet article présente quelques plugins que j’utilise et s’enrichira au fil des découvertes 🙂

Eclipse logo

CMake Editor

CMake Editor rajoute un éditeur dédiés aux fichiers CMake. Il propose bien sûr la coloration syntaxique et l’autocomplétion :

eclipse-plugin-cmake-editor-autocompletion

Une entrée est créée dans Windows / Preferences / CMakeEd pour configurer la coloration syntaxique et pour gérer ses templates, qui sont accessibles via l’autocomplétion.

Enfin, l’éditeur est par défaut associé aux fichiers CMake :

eclipse-plugin-cmake-editor-association

CMake Editor est disponible sur le marketplace.

Eclox

Eclox permet une intégration rapide de Doxygen dans Eclipse. Vous pouvez le configurer dans Windows / Preferences / Doxygen :

Il est aussi très utile de choisir Doxygen comme outil de documentation dans les options de l’éditeur C/C++. Ainsi, quand taperez /**<ENTRÉE> (ou /*!<ENTRÉE> ou peut-être d’autres débuts de commentaire Doxygen valide) juste avant le corps d’une fonction, d’une énumération, d’une variable, un bloc de documentation Doxygen sera automatiquement créé.

Le plugin offre aussi un éditeur pour les fichiers Doxygen :

Enfin, un bouton avec un @ bleu apparaît dans la barre d’outils pour générer la documentation en un clic !

Eclox est disponible sur le martketplace.

JSON Editor Plugin

On a toujours besoin d’un éditeur JSON. JSON Editor Pluging fait bien le taf. Une entrée dans les préférences permet de configurer le formatage et la coloration syntaxique. Le plus est que la structure du fichier JSON est montrée dans la vue Outline :

JSON Editor Plugin est disponible sur le marketplace.

QuickImage

Quand vous travaillez sur des GUI, vous avez souvent des images à gérer. Le plugin Quick Image est une simple visionneuse d’images, indiquant quelques informations basiques, suffisante pour ce que j’avais à faire :

eclipse-plugin-quick-image

QuickImage est disponible sur le marketplace.


Lister les répertoires présents dans le path

J’étais (malheureusement) déjà grand quand j’ai découvert awk :

Bien qu’il soit rebutant aux premiers abords, on arrive assez rapidement à faire des choses sympathiques !

Cet article vous montre une ligne simple pour lister les répertoires présents dans le path grâce à awk. La première chose à faire est d’envoyer le contenu de la variable d’environnement PATH à awk grâce à un pipe. Le programme awk commence  par changer le séparateur de champ (FS pour Field Separator) dans BEGIN puis boucle pour afficher les champs.

Voici la commande complète pour Unix :

echo $PATH | awk 'BEGIN {FS=":"} { for(i = 1; i <= NF; i++) print $i}'

Sous Windows, le séparateur est différent et la récupération de la valeur de la variable d’environnement est différente. De plus, Cmder (la ligne de commande que j’utilise depuis près d’un an et demi sous Windows) n’aime pas les chevrons donc j’utilise une boucle while à la place de la boucle for :

echo %PATH% | awk 'BEGIN {FS=";"} { i = 0; while(i++ != NF) print $i}'

Pour finir, notez que la boucle commence à l’indice 1 et termine à l’indice NF (pour Number of Fields) inclus puisque $0 est l’argument entier et que $1 à $n correspondent aux morceaux de l’argument découpé selon FS.


Activer la compilation multicœur dans Eclipse CDT

Mon premier article sur ce blog expliquait comment dire à make d’utiliser plusieurs cœurs lors de la compilation. Il suffit d’utiliser l’option -j pour spécifier le nombre de jobs pouvant s’exécuter en parallèle. Si vous utilisez Eclipse CDT et son builder interne, il existe aussi une option activer la compilation multicœur. Je l’ai trouvé par hasard aujourd’hui, elle est dans les propriétés du projet puis C/C++ Build et Behavior :

eclipse-compilation-multicoeur

J’ai étonné que cette option ne soit pas cochée par défaut et j’ai bien sûr immédiatement testé ça. Mon projet n’est pas encore très gros, il n’a que 78 fichiers. En l’activant, je suis passé de 31s.792 ms à 13s.114 ms pour le builder. Wouhou !


Créer son propre archétype Maven

Aujourd’hui, j’ai enfin pris le temps de voir comment créer son propre archétype Maven. L’idée m’était venue en octobre, notamment avec la lecture de cet article, Maven pour les nuls… les archetypes. Avoir son propre archétype permet de créer un nouveau projet en respectant une structure donnée très simplement. Il est ainsi possible d’uniformiser les développements au sein de l’entreprise en fournissant un modèle qui sera commun à tous les projets. Pour cette expérimentation, j’ai choisi de créer un modèle de projet avec une structure ressemblant à celle que pourrait avoir un projet en C sur MCU et dont l’artéfact généré serait un zip contenant l’intégralité du projet. Je travaille dans Eclipse Mars pour plus de faciliter mais vous pourriez très bien faire la même chose avec un éditeur de texte et la ligne de commande.

Création du modèle de projet

La première étape est de créer un projet tel que j’aimerais que Maven le génère avec mon archétype. Une fois cette coquille créée, je demanderai à Maven de générer l’archétype à partir de ce modèle (template, en anglais). Voici à quoi ressemble mon projet :

maven - archetype - 1 - template

La seconde étape est la personnalisation du fichier pom.xml pour générer non pas un jar mais un zip du projet. Pour cela, il faut utiliser le plugin Assembly de Maven. En suivant les conseils de la section Usage, j’ai rajouté l’utilisation de ce plugin, j’ai choisi le mode project et j’ai demandé à ce que la cible qui va bien d’Assembly soit appelée lors de la phase package du projet. Enfin, j’ai changé le type de packaging du projet de jar vers pom pour ne plus générer de jar mais uniquement le zip d’Assembly. Voici le pom.xml :

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.gradot</groupId>
    <artifactId>mcu-project-template</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                    <descriptorRefs>
                        <descriptorRef>project</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>

Création du projet Maven de l’archétype

À ce state, je possède donc un modèle de projet avec la structure et le packaging souhaités. En exécutant mvn package sur le projet, on constate en effet que le dossier de sortie target contient bien 3 archives (zip, tar.gz, targ.bz2). Il faut donc maintenant créer le projet Maven de l’archétype en lui-même, à partir de ce projet template, grâce à la commande mvn archetype:create-from-project. J’ai essayé de le faire directement avec un launch configuration d’Eclipse mais j’ai obtenu l’erreur suivante :

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.4:
create-from-project (default-cli) on project mcu-project-template: 
${maven.home} is not specified as a directory: 
'/home/pgradot/Documents/workspace-mars/mcu-project-template/EMBEDDED'. -> [Help 1]

Cela semble être dû à un bug de l’intégration de Maven dans Eclipse. La solution de contournement est simple :  exécuter la commande via le terminal. Le projet Maven de l’archétype est alors disponible dans target/generated-sources/archetype. Pour plus de facilité pour la suite, j’ai créé un projet Eclipse en utilisant une non-default location pointant vers l’emplacement du projet Maven de l’archétype :

maven - archetype - 2 - create eclipse project

Enfin, j’ai rajouté la nature Maven au projet Eclipse en faisant un clic-droit puis Configure / Convert to Maven project. On peut maintenant regarder le contenu de l’archétype et notamment retrouver les fichiers de notre projet template :maven - archetype - 3 - archetype content

Hic ! Les dossiers vides ne sont pas gardés lors de la génération de l’archétype…

Publication et utilisation de ce nouvel archétype

Pour publier l’archétype et ainsi le rendre disponible, il suffit d’appeler la cible install du projet (ou deploy, si les dépôts sont configurés) et l’artéfact de l’archétype se retrouve dans le dépôt local de Maven :

$ ls -l /home/pgradot/.m2/repository/com/gradot/mcu-project-template-archetype
/1.0.0-SNAPSHOT/
total 20
-rw-rw-r-- 1 pgradot pgradot   96 mai   10 08:34 m2e-lastUpdated.properties
-rw-rw-r-- 1 pgradot pgradot  726 mai   10 08:30 maven-metadata-local.xml
-rw-rw-r-- 1 pgradot pgradot 3241 mai   10 08:30 mcu-project-template-archetype
-1.0.0-SNAPSHOT.jar
-rw-rw-r-- 1 pgradot pgradot  988 mai   10 08:24 mcu-project-template-archetype
-1.0.0-SNAPSHOT.pom
-rw-rw-r-- 1 pgradot pgradot  238 mai   10 08:30 _remote.repositories

Je peux maintenant créer un nouveau projet dans Eclipse et demander à Maven d’utiliser mon nouvel archétype (il faut penser à cocher qui va bien la case si l’archétype a été buildé en snapshot, ce qui est le cas ici) :maven - archetype - 4 - create projet

Pour finir je peux constater que j’obtiens un projet semblable à mon projet template (aux dossier vides près… ) et qui se package comme il faut !

maven - archetype - 5 - result