Stage 2015 - Journal de bord

Week 15 Jun

Mon 15 Jun

Premières modifications du code des classes réalisées lors du PIDR
Création d’une classe à part qui réalise le travail qui était fait avant dans le Harvester (version avec objets)

Modifier le code du Harvester pour l’intégrer au travail déjà effectué

Retirer de la liste les clics rageurs sur Run quand du code ne fonctionne pas

Vérifier le bon fonctionnement du Harvester et des nouvelles méthodes afin d’être sûr que l’on récupère bien les bonnes erreurs

Tue 16 Jun

Correction de quelques bugs dans les ré-exécutions de codes élève
Réimplémentation de la classe de statistiques (on oublie le csv pour l’instant, étant donné qu’il y a des virgules dans les logs d’erreur)

Résoudre le problème des codes Python qui font des erreurs d’interprétation (affiche “null” pour le moment)

Finir les tests éventuels (clics rageurs, fonctionnement global)

Finir l’intégration avec le code d’Hervé

Etudier le cas des boucles infinies dans le code élève

Wed 17 Jun

Jabber fonctionne sur ma machine
Exécution sur plus de branches que par le passé (environ 20 branches avant l’arrêt du programme, soit à cause de la mémoire, soit à cause du processeur)
Résultats obtenus sur 100 branches
On vérifie que si l’exécution est stoppée manuellement, c’est que l’élève a potentiellement réalisé une boucle infinie, et on en gère l’exécution
Le code fonctionne, mais il peut parfois s’arrêter sans aucune bonne raison apparente
Plusieurs tentatives pour réduire l’espace mémoire utilisé par le programme, sans succès

Récupérer une nouvelle machine

Rendre le code propre dans toutes les classes déjà écrites

Problème sur les leçons traitant de la récursivité

Etudier la rétrocompatibilité du programme (exercices qui ont changé de nom…)

Est-ce que ça a vraiment un intérêt, étant donné que ce sont, pour la plupart d’entre eux, des exercices qui n’existent plus actuellement dans la PLM ? Pour l’instant, ça ne fonctionne pas vraiment.

Réaliser des tests sur de grandes masses de données

Pour cela, il faut une machine plus puissante et surveiller l’exécution du code pendant toute sa durée, quitte à relancer le code plusieurs fois. Le test a été effectué sur 150 branches pour un total de près de 6600 fichiers.

Thu 18 Jun

Premiers tests de création d’un jar pour l’exécution à distance (ça fonctionne bien en console)
Leçons sur la récursivité normalement toutes gérées
Javadoc créée dans les classes qui concernent mon travail

Commenter le code

Fri 19 Jun

Vérification approfondie des erreurs récupérées : certaines erreurs n’ont pas de consistance puisque l’exercice n’existe plus dans la PLM
Refactoring du code terminé
Fusion du code avec le code d’Hervé
Jar prêt à être exécuté sous réserve de surveillance accrue
Débug du code qui peut maintenant s’exécuter sur n’importe quelle machine possédant au moins 2Go de RAM disponible pour Java et un processeur lambda (joue sur la vitesse de calcul)

Lancer le programme sur toutes les branches

Créer un jar

Gérer les boucles infinies

Week 22 Jun

Mon 22 Jun

Correction de quelques bugs sur l’exécution des exercices qui ont changé de nom
Etude de la PLM pour l’implantation des mondes erreurs

S’occuper de l’exécution des exercices sur la Moria

Vérifier si les exercices à exécuter sont présents dans la liste des exercices encore implantés

Créer un monde erreur

Implanter le monde erreur et tester son exécution

Tue 23 Jun

Correction d’un bug dans le reparcours des branches
Etude approfondie de la PLM

Wed 24 Jun

Nouvelle recorrection dans le reparcours des traces
Accueil des deux nouveaux stagiaires
Première tentative d’ajout de mondes leurre

Thu 25 Jun

Premiers mondes leurre ajoutés (il faut encore que ça affiche le bon message dans la PLM, et là, c’est une autre paire de manche…)
Plusieurs essais réalisés, mais je ne sais pas si les mondes leurres sont testés ou non

Vérifier que les mondes leurre sont compilés

Faire afficher le bon message à la PLM

Fri 26 Jun

Les mondes leurre ne sont ni testés, ni compilés (il doit probablement y avoir quelque chose à faire avec getCompilableContent)
Le code avance vers sa structure finale, il reste seulement à modifier quelques classes…

Continuer de modifier les classes attenantes à l’ajout d’un test d’un monde leurre

Week 29 Jun

Mon 29 Jun

Premier affichage du bon résultat mais problème au niveau de son obtention

Tue 30 Jun

Le code est committé dans mon repo forké de la PLM (http://www.github.com/Glasfeu/PLM)
Il permet d’ajouter des mondes leurre en java, scala et python, mais affiche pour le moment la même erreur (voir Todo du 25 juin)
Les trois langages suscités sont obligatoires pour qu’une erreur soit testée

Utiliser la structure de Vector<Vector<World>> pour tester plusieurs résultats faux

Trouver le moyen de changer le message qui s’affiche selon l’exercice lancé

Réfléchir à la manière d’ajouter les mondes leurre dans la PLM

Wed 01 Jul

Avancée dans les deux premiers points du jour précédent

Thu 02 Jul

Utilisation possible de plusieurs fichiers leurre dans un exercice donné (il faut donner comme nom à ces fichiers <exo>CommonErr[0-9]* avec un ordre à respecter absolument (en gros, pas de fichier CommonErr3 sans un CommonErr0, 1 et 2))

Vérifier les résultats de la réexecution des codes élèves (il y a des résultats étranges)

Problème trouvé : le code élève n’est pas exécuté, donc évidemment, ça rend les choses un peu plus compliquées. Il y a eu un autre petit problème, une inversion entre deux mondes, mais le problème n’en est plus un.

Fri 03 Jul

Solution au problème : le programme n’a pas le temps de modifier le currentWorld. Du coup, il faut rajouter une méthode permettant d’attendre le runner de Game.java.
Nouveau problème : les tests ont été effectués avec un Thread.sleep(x) avec x = 1000 (ne fonctionne pas) et x = 5000 (fonctionne parfois). On a plus de 48000 fichiers d’erreur. Un simple calcul nous donne une durée d’exécution comprise entre 13 heures 20 minutes et 66 heures et 40 minutes pour environ 1386 branches sur l’intervalle d’attente de 1 seconde à 5 secondes.
Si la solution à ce problème est trouvée, il est possible de modifier l’implémentation de la gestion des boucles infinies, avec un timer. L’idée est de mesurer le temps que prend la solution à se compiler et s’exécuter et, à l’aide d’un facteur multiplicateur compris entre 1,1 et 2, estimer le temps avant le timeout pour le code de l’élève. Si ce temps est dépassé, on lui annonce gentillement que sa solution n’en est pas une dans un temps raisonnable.

Régler les temps d’exécution pour la réexécution des codes élève

Etudier la question des temps d’exécution pour les boucles infinies

Week 06 Jul

Mon 06 Jul

Regénération d’un jar de la PLM avec une modification de Game.java permettant l’attente du Thread lancé par runner.
Ajout d’un timeout pour l’exécution du code élève, basé sur 15 secondes au maximum.
Modification de la classe Exercise pour permettre de “choisir” le message à afficher. Celui-ci doit être écrit dans le fichier <exo>CommonErr[0-9]*.html correspondant à l’erreur trouvée, et doit être au même endroit que le fichier portant le même nom avec l’extension .java.

Essayer de trouver le meilleur temps avant le timeout en fonction de l’exercice

Tester l’exécution du programme

Lancer l’exécution du programme sur une machine plus puissante

Etudier le cas d’un changement de langue pour l’affichage du texte des mondes leurre

Tue 07 Jul

Récupération et exécution du code correction de l’exercice. Le but est de trouver le temps d’exécution de ce code pour obtenir un timeout en fonction de celui-ci. On stocke dans une hashmap les temps d’exécution de ces codes en fonction de l’exercice, pour qu’on ne réalise pas à nouveau ces exécutions lors des autres exécutions futures, étant donné que l’ordinateur ne change théoriquement pas.

Wed 08 Jul

Correction de plusieurs bugs dans la réexécution du code de l’élève, dus au fait que certains exercices aient changé de nom.
Correction d’un bug dans le calcul du temps de compilation et d’exécution du code de la correction.

Améliorer le moyen d’exécuter la correction d’un exercice

Plutôt que d’exécuter le code de la correction à la manière de celui du code élève, il faudrait voir pour utiliser le demoRunner et attendre la fin de la démo. Pour cela, il faut modifier le jar de la PLM que l’on embarque dans le reaper.

Thu 09 Jul

Vérification de l’absence d’autres bugs

Fri 10 Jul

Amélioration du code de ré-exécution du code des élèves
Correction d’un bug dans la PLM empechant le bon fonctionnement de la ré-exécution du code des élèves (problème dans le clipping pour l’univers des tortues)

Sat 11 Jul

Modifications mineures dans le code du reaper et de la PLM (parcours des branches aléatoire)
Exécution du code pour obtenir les erreurs par Martin Quinson

Sun 12 Jul

Fin de l’exécution du code
Récupération des fichiers de log d’élèves (43K)

Week 13 Jul

Wed 15 Jul

Mise sous forme de tableur des fichiers de log
Recherche d’un critère d’importance des erreurs : selon le nombre de fois où l’erreur est apparue et selon la moyenne du nombre de soumissions par élève
Début de l’étude des erreurs importantes

Thu 16 Jul

Suite de l’étude des erreurs importantes
Un premier problème se pose : parfois, une erreur peut etre atteinte par plusieurs codes différents - l’idée d’un retour élève sur la pertinence du message d’aide affiché prend son sens ici.

Fri 17 Jul

Suite de l’étude des erreurs importantes
Certaines code d’erreurs trouvés dans l’ancienne version de la PLM mènent à la bonne solution

Week 20 Jul

Mon 20 Jul

Etude d’un nouvel exercice

Gérer les différents cas de boucles infinies dans le test du code élève dans la PLM

Le problème vient du fait que la PLM exécute les codes de solution et d’erreur avant le lancement complet de l’univers. Si l’un de ces codes donne une boucle infinie, il s’exécute… indéfiniment. L’idée serait d’utiliser un timeout (encore…), mais qui nous dit que le monde obtenu après avoir arreté l’exécution sera celui obtenu par l’élève

Tue 21 Jul

Modification du programme de la PLM déjà écrit pour tester les erreurs communes, suite à une erreur survenue à l’ajout de plus d’une erreur dans plus d’un monde.

Refactorer le code de test des mondes erreur dans la PLM

Regarder et modifier le canvas du baseball sur webPLM

A noter, l’aide de Tanguy pour les formules.

Wed 22 Jul

Refactoring du code de test de la PLM
Etude du code de la vue du monde du baseball sur webPLM
Ecriture de quelques formules qui peuvent permettre de reprendre ce code

Thu 23 Jul

Fin de l’étude du graphisme du monde du baseball
Suite de l’étude des erreurs de l’exercice du lundi 20 juillet

Trouver un moyen de regarder plus vite les erreurs fréquentes

En une semaine, certes sans faire uniquement cette étude des erreurs, regarder les 944 erreurs communes d’un monde est fastidieux et relativement ennuyeux… C’est une mécanique, et comme toutes les mécaniques en informatique, on doit pouvoir trouver un moyen de l’automatiser. De plus, tous les fichiers n’ont pas été regardés : je m’étais souvent arreté (à partir du deuxième jour sur cet exercice) au premier fichier de chaque branche, étant donné que le code reste toujours très similaire entre les commits d’une meme branche. Aussi, si une semaine a suffi pour obtenir ce résultat (7 fichiers de leurre à la fin de cette journée), il semble que ça deviendra vite impossible de tout regarder, en sachant que, par exemple, l’exercice sur la Moria compte pas moins de 4 fois ce nombre de fichiers d’erreur…

Fri 24 Jul

Etude des erreurs sur le meme exercice

Week 27 Jul

Mon 27 Jul

Correction d’un bug dans le parcours des erreurs classiques dans le client lourd de la PLM (il ne regardait pas tous les mondes et causait donc un problème).
Etude d’un nouvel exercice (le deuxième).

Tue 28 Jul

Fin de l’étude du second exercice -> 85% des erreurs sont traitées (bien ou non, en tout cas, on arrive au meme monde), 10% sont des boucles infinies qu’on ne peut pas vraiment tester et le reste représente les erreurs qui ne sortent qu’une fois ou deux et qui ne sont pas pertinentes.

Attaquer l’étude d’un nouvel exercice

Je vais attendre le retour de Matthieu avant de toucher à webPLM, pour la simple et bonne raison que je n’ai aucune idée d’où regarder pour commencer…

Préparer un mail à envoyer pour OverCode

Finalement, Martin a envoyé le mail…

Wed 29 Jul

Recherche et étude de l’exercice suivant

Thu 30 Jul

Suite de l’étude

Fri 31 Jul

Suite et fin de l’étude
Début d’un nouvel exercice

Week 03 Aug

Mon 03 Aug

Suite de l’étude précédente (à cette occasion, il y a eu un petit problème : je suis tombé sur un exercice pour lequel les versions 2.4.11, 2.5 et web mènent à une erreur, mais pas dans la version pre-2.6, ce qui est plutot incompréhensible, vu que le code en faute n’a pas été modifié depuis mars 2015. La ligne en cause est dans la traduction en python de la commande forward() qui lui donnait un paramètre et que ce paramètre est interdit dans l’exercice en question. Le problème est que l’on obtient alors des fichiers d’erreurs inexistantes, et que ce problème peut (et sera sans nul doute) retrouvé dans de nombreux autres exercices…)

Tue 04 Aug

Suite de l’étude précédente
Liste des grandes étapes de l’intégration à webPLM
- Merge de la master vers library et résolution des conflits
- Remote de la branche library de BuggleInc pour récupérer les dernières mises à jour
- Merge et résolution des conflits
- Vérification du bon fonctionnement du code et correction des éventuelles erreurs du programme
- Refactoring du code et nouvelle vérification du programme
- Mise en production
- Création de l’outil de retour sur les erreurs classiques
  - A ce propos, une question se pose : dans quoi doit-on mettre ces retours élèves sur les indices ?

Regarder comment intégrer les erreurs classiques à webPLM

La question est maintenant : faut-il attendre ce qu’est en train de faire Tanguy ou pas ? L’implémentation peut-elle changer entre-temps ? Et si oui, vais-je avoir suffisamment de temps pour m’en occuper tout en regardant les erreurs des étudiants ?
- Finalement, il a été décidé d’intégrer le travail déjà fait depuis le jar à webPLM. Il ne reste plus qu’à bien merger, résoudre tous les conflits et vérifier le bon fonctionnement du programme, avant de revenir à l’étude des erreurs classiques.

Wed 05 Aug

Premier merge du code de la PLM : de la master modifiée à library dans mon fork de la PLM.
Résolution de tous les conflits à la main (20 fichiers incriminés).

Récupérer les dernières modifications de la branche library en utilisant un remote

Thu 06 Aug

Résolution d’erreurs sur les chemins des fichiers depuis le jar qui a impliqué un gros refactoring du code puisque la structure de recherche a complètement changé.
Résolution d’un bug qui écrivait un commentaire sur la traduction à la place de l’indice

Afficher le bon indice au bon moment

Traduire les indices en français

Comment je suis censé faire ça ?
- Changer la forme des fichiers <exo>CommonErr[0-9]*.html en rajoutant la langue dans l’extension.

Fri 07 Aug

Le bon indice s’affiche au bon moment dans webPLM –> le jar est pret à etre mis en prod sans les traductions
Correction des conflits
Des problèmes entre Java 7 et Java 8 peuvent encore exister

Faire l’intégration de feedback sur les indices

Trouver une structure pour stocker le feedback sur les indices

Week 10 Aug

Mon 10 Aug

Traduction des 9 fichiers html de l’anglais vers le français
Réflexion sur la manière de poser la question du feedback sur les indices aux utilisateurs pour qu’ils ne passent pas leur chemin dès l’apparition de la question

Ajouter un mécanisme de passage d’indice différent

Il reste un ajustement ou deux pour gérer plusieurs lignes dans les indices (pour l’instant, ça ne fonctionne que pour une seule ligne).

Tue 11 Aug

Plusieurs lignes peuvent etre écrites dans les fichiers d’indice et il n’y a pas de limite pour le nombre de caractères qui composent ces indices.
Transformation de la vue dans le monde des buggles de webPLM.

Faire le rapport

Wed 12 Aug

Le monde du baseball a été arrangé grace à l’aide de Tanguy.

Thu 13 Aug

Journée exclusivement réservée à l’implémentation d’erreurs classiques.
- Puisque la quantité prime sur la qualité, et malgré le fait que l’on sache pertinemment que la plupart des erreurs trouvées après la réexécution du code élève ne corresponde pas du tout à l’erreur effectivement lue, la première erreur trouvée dans les fichiers qui correspondra à celle affichée dans le tableur résultat sera celle qui sera traduite en Java sans aucune autre forme de jugement. Le résultat sera ensuite brièvement commenté dans le fichier html correspondant et il n’y aura pas de traduction en français avant la fin de l’étude des 8000 lignes ou des 200 exercices de la PLM.

Fri 14 Aug

Journée exclusivement réservée à la rédaction du rapport.
Tous les problèmes qui pourront etre rencontrés durant ces deux journées ne seront traités qu’à partir de la dernière semaine.

Files

stage2015carpentier.org

Latest commit

History