Interpréteur Lisp
Projet de GL2 semestre 2 master 1 2018-2019 de l'université d'Artois à Lens
Arthur Brandao c2311b345a Ajout tests | преди 5 години | |
---|---|---|
.settings | преди 5 години | |
lib | преди 5 години | |
src | преди 5 години | |
test | преди 5 години | |
.classpath | преди 5 години | |
.directory | преди 5 години | |
.gitignore | преди 5 години | |
.gitlab-ci.yml | преди 5 години | |
.project | преди 5 години | |
README.md | преди 5 години | |
build.xml | преди 5 години | |
checklinks.sh | преди 5 години | |
org.eclipse.jdt.annotation_2.2.200.v20180921-1416.jar | преди 5 години |
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.
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
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
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>
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">