Interpréteur Lisp
Projet de GL2 semestre 2 master 1 2018-2019 de l'université d'Artois à Lens

Arthur Brandao c2311b345a Ajout tests %!s(int64=5) %!d(string=hai) anos
.settings 1b02fa5c02 TP2 %!s(int64=5) %!d(string=hai) anos
lib f112304372 ajout support pitest %!s(int64=5) %!d(string=hai) anos
src 7b119000f9 Suppr param inutile %!s(int64=5) %!d(string=hai) anos
test c2311b345a Ajout tests %!s(int64=5) %!d(string=hai) anos
.classpath 1019f345e5 Update .classpath %!s(int64=5) %!d(string=hai) anos
.directory 06b87599a6 Suppr git submodules %!s(int64=5) %!d(string=hai) anos
.gitignore 7b356da5cb Rien %!s(int64=5) %!d(string=hai) anos
.gitlab-ci.yml 168e8a634a Remise valeur par default CI config %!s(int64=5) %!d(string=hai) anos
.project b4a6f34647 Changement nom projet %!s(int64=5) %!d(string=hai) anos
README.md 02eb943291 Ajout info Submodule %!s(int64=5) %!d(string=hai) anos
build.xml eb4a905471 Reactivation pitest %!s(int64=5) %!d(string=hai) anos
checklinks.sh 5376653a54 Remise chemin vers test %!s(int64=5) %!d(string=hai) anos
org.eclipse.jdt.annotation_2.2.200.v20180921-1416.jar 1b02fa5c02 TP2 %!s(int64=5) %!d(string=hai) anos

README.md

Projet interpréteur lisp

Qualité Tests réussis Couverture de code

Voir sur SonarQube

La page Lisp sur wikipedia et la page Scheme sur wikipedia fournissent l'historique et les fonctionnalités du langage.

Le comportement de l'interpréteur (le tests) sont validés à l'aide de l'interpréteur JScheme.

Le nombre de tests augmentera au cours du semestre jusqu'à obtenir un interpréteur pleinement fonctionnel.

Ce projet est basé sur le travail de Peter Norvig en Python.

Peter Norvig a aussi proposé une version Java de son interpréteur. Cette version a été conçue à la naissance du langage, et ne peut pas être considérée comme une conception oriénté objet d'un interpréteur Lisp.

Plus récemment, une version Java a été proposée par Remy Forax. Si cette solution utilise des concepts avancés et récents de Java (lambdas et streams), le code reste proche de la version python, donc pas vraiment orienté objet.

On pourrait imaginer, dans un futur proche, passer de la réalisation d'un simple interpréteur à un système d'exploitation complet.

Pour déclarer ce projet comme source upstream

Il suffit de déclarer une fois ce projet comme dépôt distant de votre fork :

$ git remote add upstream https://forge.univ-artois.fr/m1-2018-2019/TDD2019IMPL.git

Ensuite, à chaque mise à jour de ce projet, vous pouvez mettre à jour votre fork à l'aide des commandes suivantes :

$ git pull upstream master
$ git push

Si vous ne voyez plus vos tests dans votre projet

Il suffit de rajouter le projet de tests comme un sous module du projet :

$ git submodule add https://forge.univ-artois.fr/m1-2018-2019/TDD2019TESTS.git
# remplacer le chemin absolu https://forge.univ-artois.fr/m1-2018-2019/TDD2019TESTS.git 
# par ../../m1-2018-2019/TDD2019TESTS.git dans le fichier `.gitmodules`.
$ git commit -m "Les tests sont de retour"
$ git push

Commandes submodule (Lien vers les git des tests)

Pour initialiser les submodules :

$ git submodule update --init

Pour initialiser un submodule précis :

$ git submodule update --init <nom_dossier_submodule>

Pour mettre à jour les submodules :

$ git submodule update --remote

Pour mettre à jour un submodule précis :

$ git submodule update --remote <nom_dossier_submodule>

Note à propos de PiTest

Avec la configuration par defaut du build.xml :

<!-- ligne 114 -->
<target name="m1" description="Verification des projets de TDD2019" depends="clean,build,tests,mutationCoverage" />

<!-- Define the SonarQube target -->
<target name="sonar" depends="m1" description="Analyse le code avec SonarQube">

La commande ant -Detudiant=prenom_nom sonar (qui est utilisé pour valider le code dans l'intégration continue de Gitlab), ne va pas lancer les tests sonar si tous les tests unitaires ne passent pas (ce qui peut être gênant). Ceci est causé par la dépendance qu'a sonar vers m1 et m1 vers mutationCoverage. Si tous les tests unitaires ne sont pas passés alors PiTest (mutationCoverage) va échouer, hors comme sa dépendance échoue, m1 échoue. Donc sonar ne se lance pas car sa dépendance à échoué.

Pour résoudre le problème j'ai déplacé le test de mutation. Il n'est plus exécuté en tant que dépendance de m1, mais en tant que subant. Ce qui permet en cas d'erreur de ne pas faire échouer m1 et donc permettre de lancer sonar. Le nouveau code est le suivant.

<!-- ligne 114 -->
<target name="m1" description="Verification des projets de TDD2019" depends="clean,build,tests">
	<subant failonerror="false" target="mutationCoverage">
		<fileset dir="." includes="build.xml" />
	</subant>
</target>

<!-- Define the SonarQube target -->
<target name="sonar" depends="m1" description="Analyse le code avec SonarQube">