ucl-ingi/lepl1503-blog

Blog du projet P3 à l'UCLouvain

Blog du projet P3, LEPL1503

Ce blog comprend des informations utiles aux étudiants qui réalisent le projet du cours LEPL1503 à l'UCLouvain.

Ce blog est écrit en Markdown et est mis en ligne grâce à au logiciel Jekyll de GitHub.

Les étudiants sont encouragés à proposer des articles sur ce blog. Les étudiants dont les articles seront publiés recevront un bonus dans l'évaluation du cours.

Pour proposer un article pour le blog, nous vous invitons à réfléchir aux problèmes pratiques qui vous ont fait perdre du temps dans le cadre du projet et que vous avez résolu avec l'aide d'un des membres du groupe ou d'un tuteur. Décrivez brièvement ce problème en expliquant sa solution sous la forme d'un nouvelle issue.

Pour créer une issue sur GitHub, connectez-vous sur GitHub et choisissez un nom d'utilisateur et un mot de passe.

Lors de votre premier accès à https://github.com/UCL-INGI/LEPL1503-Blog, GitHub vous recommande de lire le tutoriel accessible depuis https://guides.github.com/activities/hello-world/, c'est une excellente idée.

Voici quelques copies d'écrans qui illustrent comment écrire un article sur le blog depuis le site GitHub. C'est aussi possible en ligne de commande bien entendu et ce serait un excellent sujet d'article pour le blog.

La première étape est d'aller dans la zone relative aux "Issues" le projet GitHub du blog.

Ensuite il faut créer une nouvelle "Issue".

Vous pouvez maintenant décrire votre idée d'article dans la nouvelle "Issue".

Votre "Issue" est maintenant prête vous pouvez commencer la discussion pour son amélioration.

La discussion de votre "Issue" est terminée et vous allez rassembler toutes les notes dans la discussion dans un article de blog. Pour cela, la première étape est de créer une copie (un fork) du repo.

Après quelques secondes, vous avez maintenant un repo GitHub contenant une copie de celui du blog. C'est ce repo que vous allez modifier et dans lequel vous allez préparer votre article.

Le repo du blog contient différents répertoires. C'est dans le répertoire _posts que vous trouverez les articles du blog en format Markdown.

Vous pouvez cliquer sur le bouton "Create New File" pour créer un nouveau fichier dans ce répertoire. La convention de nommage est de commencer par la date suivie d'un ou deux mots qui résument le contenu de l'article en terminant par l'extension .md comme le contenu est en Markdown.

Une fois votre fichier complet, vous pouvez écrire le message de commit qui décrit votre modification et créer une branche de façon à pouvoir soumettre un pull-request.

Vos modifications sont prêtes dans votre repo, vous devez maintenant les soumettre au repo original en cliquant sur "new pull request". Vérifiez que votre pull request est bien envoyée vers la branche master du repo UCL-INGI/LEPL1503-Blog

Pensez à ajouter un bref message qui décrit votre article et faites référence au numéro de l'"Issue" que vous résolvez.

GitHub va maintenant transférer votre modification vers le repo officiel sous la forme d'une pull-request qui pourra être facilement intégrée dans le blog afin de publier votre article.

lepl1503-blog's Issues

Executer du code C depuis Windows sans passer par Virtualbox

Automatiser la mesure du temps d'exécution de plusieurs exécutions

Permet de mesurer le temps d'exécution de plusieurs exécution d'un programme avec un nombre de threads variables automatiquement

Fonctions en BASH

Bonjour,

Voici ci-après une proposition d'article traitant des fonction en BASH. Je crois qu'à ce stade du projet, elles peuvent s'avérer d'une grande utilité pour executer nos programmes.

Merci de me signaler si des ajouts ou modifications doivent être apportés pour compléter l'article.

Matthieu Boucquey

Mesure de temps plus simples et recherche du nombre de threads optimal

Bonjour Monsieur,

Suite au récents articles publié sur le blog, j'ai écris un article sur certaines manières de prendre des mesures de temps plus simples ainsi qu'une manière de représenter les temps d’exécutions sous python.
Voici la proposition d'article.

Merci d'avance de votre réponse
Eliot Peeters

Utilisation de variables "magiques" - Makefile

Malgré qu'un bon Makefile n'ai pas de rapport direct avec la réussite d'un projet, il peut être très utile pour optimiser l'expension d'un project.

On ne voit pas nécessairement leur utilité dans un project ne contenant qu'un fichier, mais petit à petit, plus le repertoire prends de l'ampleur plus le makefile sera complexe. Dès lors, il pourrait à son tours causé des bug, alors qu'il ne devait être qu'un outils. ( Je parle par expérience .. 😪 )

En faisant des recherches sur comments optimiser mon makefile, je suis tombé sur des articles contenants des pages et des pages sur le thème.

Je souhaiterais donc écrire un post contenant les méthodes principales qui peuvent être utiliser pour écrire un makefile digne de servir de fondations pour tout vos projets !!

Comme teaser, voici quelques examples venant de mon makefile:

# Initialisé des variables :
CC=gcc
CFLAGS=-g -Wall -Werror
CUnit=-lcunit
GMP=-lgmp

OBJ_PATH=UTILS
INPUT_FILE_EXAMPLE=Input-Output/example_input.txt

Ou encore :

all: main

# make
main: main.c factorisation.o LinkedList.o
	$(CC) $(CFLAGS) -o $@ $^ $(GMP) $(CUnit)

factorisation.o: $(OBJ_PATH)/initial/factorisation.*
	$(CC) $(CFLAGS) -c $(OBJ_PATH)/withLinkedL/$(*F).c

LinkedList.o: $(OBJ_PATH)/withLinkedL/LinkedList.*
	$(CC) $(CFLAGS) -c $(OBJ_PATH)/withLinkedL/$(*F).c

Voilà une partie de mon makefile qui peut encore être refactoriser pour le rendre plus fiable à long terme. Après tout, un bon développeur est un développeur paresseux, moins on répète de code, moins il y a de chances de faire d'erreur de copiage 😇.

Quelques flags utiles pour la compilation

Pour compiler un fichier c, il suffit d'utiliser la commande :
gcc fichier.c -o fichier (avec -o fichier pour que le nom de l'executable soit "fichier")
Néanmoins dans certains cas on peut rencontrer des problèmes à la compilation en utilisant certains include.
Si vous désirez utiliser #include <math.h>, la librairie de maths, vous devrez rajouter un "-lm" comme flag dans la commande gcc : gcc fichier.c -o fichier -lm
Idem si vous souhaitez utiliser #include <pthread.h>, il fait rajouter un flag -lpthread.
Enfin si vous voulez utilisez les tests CUnit, vous devrez également ajouter un flag -lcunit.
Sans ces flags, le terminal vous donnera une erreur vous disant que les commandes utilisées par ces librairies ne sont pas reconnues.

Utilisation des alias dans le terminal

L'utilisation des alias dans le shell (bash pour les explications qui suivent) est un outil à connaître absolument par la simplicité de sa mise en place et par le temps qu'il fait gagner quand on l'exploite bien.

Il est en effet courant de taper très régulièrement la même commande dans notre terminal. Par exemple, si mon projet en cours se trouve dans le dossier ~/Documents/University/LEPL1503/ProjetP3 et que j'y accède souvent, je dois sans cesse entrer la commande suivante dans mon terminal:

$ cd ~/Documents/University/LEPL1503/ProjetP3

Cela est assez chronophage et ennuyant, et les alias permettent de recourir à ce problème. Ils nous permettront par exemple d'écrire directement $ cd_p3 au lieu de la commande complète.

Pour créer vos propres alias, suivez ces quelques étapes:

1. Ouvrez le fichier .bashrc dans le dossier "home" ~/ avec votre éditeur de texte préféré (ici SublimeText)

$ subl ~/.bashrc

2. Ajoutez votre alias comme nouvelle ligne à la fin du fichier .bashrc, sous la forme suivante:

alias name="command"

Attention, il ne faut pas d'espace autour du signe = et pas de ; en fin de ligne !
Par exemple, à la fin du fichier .bashrc, écrivez:

...
# User specific aliases and functions
alias cd_p3="cd ~/Documents/University/LEPL1503/ProjetP3"

3. Enregistrez vos modifications et fermez le fichier .bashrc

4. Pour que vos modifications prennent effet, fermez et relancez votre terminal ou entrez la commande suivante:

$ source ~/.bashrc

Votre alias est maintenant fonctionnel. Ainsi, les deux commandes suivantes auront le même effet:

$ cd_p3

$ cd ~/Documents/University/LEPL1503/ProjetP3

Remarques:

• Vous pouvez ajouter plusieurs alias:

alias first_alias="some command"
alias other_alias="other command"

• Vous pouvez ajouter plusieurs lignes de commande pour un seul alias. Les lignes seront exécutées une à une et seulement après le succès de la ligne précédente. Pour cela, utiliser le marqueur &&. Par exemple:

alias my_cmd="first command && second command && third command"

• Les alias que vous avez définis sont accessibles et fonctionnels dans n'importe quel dossier et de manière permanente. Vous pouvez bien entendu les supprimer et les modifier dans le fichier .bashrc à tout moment.

• Il est également possible d'ajouter des alias qui prennent des arguments. Pour plus d'infos, cet article est très complet.

Permettre à Jenkins d'effectuer des tests et de publier un feedback

Jusqu'à présent, nous avons vu comment configurer Jenkins afin qu'il valide tout nouveau push effectué sur notre directory. Ici, nous allons voir comment lui faire effectuer différents tests qui permettront de voir directement si votre nouveau push est valide où s'il introduit un bug quelconque qui empêcherait votre programme de fonctionner.
Tout d'abord, il faut savoir que Jenkins NE PEUT PAS supprimer un push. Il peut seulement rejeter automatiquement une pull request lorsque celle-ci échoue aux tests. Il ne servira donc ici qu'à vérifier que votre push ne contient pas d'erreurs.
Pour utiliser ce logiciel dans ce but, il faut d'abord créer un fichier makefile contenant les instructions que vous souhaitez passer à Jenkins. Ce peuvent être des compilations de programmes, des exécutions de tests CUnit, mais également des utilisations d'outils de débugage tels que valgrind ou cppchceck. Pensez également à introduire une commande make clean pour supprimer tout fichier indésirable.
Ensuite, rendez-vous sur jenkins dans l'onglet configure (configurer en français, à gauche avec le rouage) du job lié à votre projet et dans la partie BUILD, dans la console de l'option "Exécuter un script shell", effectuez un make clean avant de faire la commande make qui permet d'exécuter les instructions de Jenkins. N'oubliez pas d'apply et de sauver pour appliquer ces changements à Jenkins.
Enfin, pour récupérer les résultats de vos tests, rendez-vous dans la partie "Actions à la suite du build" et sous "Ajouter une action après le build", sélectionner à chaque fois un "Publish..." au nom d'un des outils de test que vous avez fait effectuer avec la commande make. Recopiez le nom du fichier sous lequel vous avez fait sauvegarder votre rapport de test (càd les instructions --xml-file="valgrind.xml" etc. de votre Makefile) précdé de */ dans l'onglet "Patern". Apply et sauvegardez pour conserver vos modifications et vous devriez trouvez les résultats publiés par les outils de test à chaque nouveau build en cliquant dessus sur Jenkins. N'oubliez pas également de garder l'option "Publish build status to GitLab" afin de voir les résultats de jenkins depuis votre répertoire git.

Pour vérifier que tout fonctionne, rendez-vous sur votre répertoire gitlab et effectuez un push avec qui passe les tests et un qui les échoue (cela fonctionne même avec un seul test échoué). Après quelques instants, un V devrait apparaître pour le push valide et une croix dans le cas d'un push échoué.

En espérant que tout ceci ait été utile,
Tim Bary

Note : pour la compilation des programmes, il est nécessaire de rajouter l'option -std=c99 entre la mention gcc et le -o afin d'éviter une cascade d'erreurs de compilation une fois jenkins lancé.

Comment faire pour écrire un article ?

Première étape : écrire une issue sur GitHub
Deuxième étape : en discuter sur GitHub et améliorer le texte proposé
Troisième étape : créer une pull request pour intégrer l'article sur le blog

Créer un thread à partir d'une fonction à plusieurs arguments

Vous avez enfin fini d'implémenter votre algorithme et tout fonctionne à merveille lorsque vous décidez de passer à l'étape suivante: passer votre algorithme en multithread !

Seulement un problème se pose, votre fonction prend trois arguments et la foncion pthread_create refuse de la prendre ! En cherchant un peu, on peut se rendre compte que c'est normal, car la fonction pthread_create est défini ainsi dans sa manpage :

#include <pthread.h>

int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
                   void *(*start_routine) (void *), void *arg);

Si on regarde le troisième argument, qui correspond à la fonction que le thread fera tourner, on peut lire void *(*start_routine) (void *). Cette expression se décortique en trois parties:

• void *: cela signifie que votre fonction doit retourner un pointeur void
• (*start_routine): c'est ce que vous allez réellement écrire en argument, celà représente simplement un pointeur vers votre fonction.
• (void *): cela indique que votre fonction doit prendre en argument un pointeur void

Mais comment gérer un seul pointeur void ? Ma fonction à besoin de trois arguments de types différent !

Pas de panique c'est en réalité assez simple. Nous allons créer une structure contenant tous vos arguments avec le bon type, et ensuite caster le pointer de cette structure en void *. De cette façon, il suffira de recaster la structure dans l'autre sens dans votre fonction, et vous pourrez ainsi faire passer autant d'arguments que vous voudrez !

Par exemple, une fonction

char foo(char *str, int index){
    return str[index];
}

deviendra

typedef struct foo_args{
    char *ptr;
    char *str;
    int index;
} foo_args_t;

void *foo(void *arguments){
    foo_args_t *args = (foo_args_t *) arguments
    char *ptr = args->ptr;
    char *str = args->str;
    int index = args->index;

    *ptr = str[index];
    return NULL
}

On remarquera que j'ai ajouté un argument ptr qui me sert à stocker la réponse plutôt que de la retourner, puisqu'on nous impose de retourner un pointeur et qu'en général je ne veux pas retourner un pointeur vers une variable locale (elle disparaitrait à la fin de l'exécution de ma fonction).