Bonjour,
Je viens de pousser deux petites branches et j'aimerais votre avis.
https://gitlab.com/monnier/typer/-/compare/master...broken-tests-2021-04
La première ne devrait être controversée, il y avait des tests brisés dans eval_test.ml. Un trio utilisait une fonction pour l'évaluation qui effaçait les types dans le mauvais environnement. Un autre test (Let3) testait ce qui était en fait du code incorrect, une déclaration qui faisait référence à un type définie dans le même bloc de déclarations. Depuis 77981fd4dc8bc6af20e1db5148a9fb14f4adc07a, seules les définitions peuvent être récursives.
https://gitlab.com/monnier/typer/-/compare/broken-tests-2021-04...dunify-tes...
La deuxième ajoute des fichiers dune pour rouler les tests. J'ai dû faire un changement à la structure du projet. Avec le système actuel, chaque test est un exécutable indépendant qui est compilé à partir des fichiers ml que ocamlbuild trouve en suivant les dépendances. Dune par contre de supporte pas d'avoir un même fichier dans plusieurs targets. J'ai donc séparé l'essentiels des fichiers de Typer dans une bibliothèque et j'ai créé deux exécutables, typer_cli (un executable ne peut pas avoir le même nom qu'une bibliothèque) et debug_util qui, avec les tests, linkent vers cette bibliothèque.
Le principal avantage est que Dune s'occupe maintenant de coordonner nos tests. Ça nous permet de ne plus avoir à maintenir tests/utest_main.ml. Le principal défaut est qu'il faut s'habituer aux nouvelles commandes. J'ai mis à jour le Makefile pour que l'adaptation soit plus facile.
Qu'est-ce que vous en pensez? Simon
Afficher les réponses par date
Je viens de pousser deux petites branches et j'aimerais votre avis.
https://gitlab.com/monnier/typer/-/compare/master...broken-tests-2021-04
La première ne devrait être controversée, il y avait des tests brisés dans eval_test.ml. Un trio utilisait une fonction pour l'évaluation qui effaçait les types dans le mauvais environnement.
LGTM, merci.
Un autre test (Let3) testait ce qui était en fait du code incorrect, une déclaration qui faisait référence à un type définie dans le même bloc de déclarations. Depuis 77981fd4dc8bc6af20e1db5148a9fb14f4adc07a, seules les définitions peuvent être récursives.
En fait, le code n'était pas incorrect. Il a été rendu invalide par 77981fd4dc8bc6af20e1db5148a9fb14f4adc07a, en effet, mais c'est une faiblesse de la correction que j'ai installée.
Ceci dit, je ne pense pas qu'on va la corriger mieux dans le futur proche, donc tu peux effectivement éliminer ce test (et de toute façon ce test était trop "contrived", donc si on veut réintroduite cette fonctionalité, il faudrait mettre un test un peu plus convaincant).
https://gitlab.com/monnier/typer/-/compare/broken-tests-2021-04...dunify-tests
[ BTW, pour la petite histoire: quand j'ai vu tes push j'ai d'abord compris "dunify" comme étant "d|unify" plutôt que "dun[e]ify", alors j'étais perplexe un p'tit moment parce que le code ne semblait pas avoir grand chose à voir avec l'unification. ;-) ]
La deuxième ajoute des fichiers dune pour rouler les tests. J'ai dû faire un changement à la structure du projet. Avec le système actuel, chaque test est un exécutable indépendant qui est compilé à partir des fichiers ml que ocamlbuild trouve en suivant les dépendances. Dune par contre de supporte pas d'avoir un même fichier dans plusieurs targets. J'ai donc séparé l'essentiels des fichiers de Typer dans une bibliothèque et j'ai créé deux exécutables, typer_cli (un executable ne peut pas avoir le même nom qu'une bibliothèque) et debug_util qui, avec les tests, linkent vers cette bibliothèque.
Je préfèrerais ne pas changer le nom de l'exécutable; on peut appeler la bibliothèque `typerlib`?
Stefan