[comment]: <> "LTeX: language=fr" # Travail de Bachelor - PV Kick off **Date** : 19/05/2025 **Lieu** : Salle D2021 **Heure** : 15:00-16:16 | Participants | Présence | Rôle | | -------------- | :------: | ------------------------------------- | | Bapst Frédéric | présent | participant, organisateur | | Michel Luca | présent | participant, secrétaire | ## 1. Points discutés ### Administratif L'accès à une [fork du GitLab de M. Julmy](https://gitlab.forge.hefr.ch/frederic.bapst/25-ps-5-web-assembly) a été donné à M. Michel (en tant que reporter). Un [repository voué au TB](https://gitlab.forge.hefr.ch/frederic.bapst/25-tb-wasm-instrumentation) a également été créé. L'expert de ce projet est M. Baptiste Wicht, l'un des premiers contributeurs de COJAC. M. Michel doit prendre contact avec l'expert afin de : - présenter brièvement l'état actuel du projet en spécifiant ce que la POC de M. Julmy est capable de faire - lui indiquer le lien du repository du projet (les droits d'accès devront lui être attribués) - discuter du canal de communication qui sera utilisé (Teams par exemple) et créer ce canal - discuter des informations qui doivent lui parvenir (PV, versions du cahier des charges et du rapport, avancement du projet...) - fixer les deux séances avec M. Wicht, une sur la fin de la seconde semaine ou la troisième semaine et l'autre dans le courant de la sixième semaine Mettre M. Bapst en copie pour toute communication avec l'expert. Les visites de M. Wicht se feront normalement uniquement avec M. Michel et les PV de ces séances devront être communiquées à M. Bapst. Ces séances ont pour but de présenter le cahier des charges (première séance) et l'état du projet dans sa globalité. Elles doivent être agrémentées de quelques slides et préparées à l'avance par M. Michel. Bien consulter les directives de TB notamment pour la rédaction du rapport. Jeter aussi un coup d'œil au pense-bête de Mme. Chabbi qui a été fourni à M. Michel sous format papier. M. Michel devra rédiger une première ébauche du cahier des charges dans le courant de la semaine afin de pouvoir le terminer dans le courant de la semaine prochaine. Exceptionnellement une seconde séance aura lieu ce mercredi à 10:15. Les réunions hebdomadaires se dérouleront le lundi à 8:15 et dureront environ 45 minutes sauf exceptions. Un flyer devra être fait durant le projet, les consignes ayant trait à ce flyer parviendront ultérieurement à M. Michel. Une affiche présentant le projet devra être faite environ deux semaines avant l'exposition. Cette affiche devra contenir le moins de texte possible. Le flyer peut se permettre d'être un peu plus verbeux. M. Michel préférerait avoir sa défense orale dès l'après-midi du lundi 01/09/2025. Attention à bien mettre la branche main à jour le plus régulièrement possible. ### Technique M. Michel a consulté le rapport de M. Julmy ainsi que la documentation de COJAC. Il y a des circonstances dans lesquelles les overflows et autres anomalies sont attendus (hash, et ainsi de suite). COWAC ne donne cependant pas d'informations quant à l'endroit où les anomalies surviennent, ce qui ne permet pas de déterminer si ces anomalies sont attendues ou non. COJAC, par opposition, donne accès au stack trace, noms de fonctions, localisation des anomalies et ainsi de suite. Cette fonctionnalité n'est pas forcément implémentable en WASM mais il semblerait qu'il existe une section dans le code binaire WASM, la "custom section", qui pourrait contenir le nom des fonctions. Il n'est pas certain que ces informations soient disponibles dans les jeux browser, mais il serait intéressant de voir si d'autres environnements mettent ces informations à disposition. Le projet de M. Julmy se concentrait sur les applications web, ce projet en fera de même dans un premier temps, mais un objectif secondaire pourrait consister à étendre les fonctionnalités de COWAC hors de l'environnement d'un browser, ce qui donnerait par exemple la possibilité d'interagir avec des fichiers. Dans la mesure où initialement seules les applications web seront visées, il est nécessaire de garder en tête qu'une partie du code traité sera (presque) toujours écrite en JS et que WASM est par défaut complètement "sandboxé". La technique d'instrumentation actuelle se base sur une combinaison de WAIL et d'user scripts. Leur utilisation amène un certain confort et peut être maintenue. Il est cependant possible qu'une nouvelle librairie javascript existe, creuser le sujet. #### Améliorations requises Les améliorations de la POC de COWAC se divisent sur deux axes. Le premier vise à améliorer certains aspects de la logique du programme, notamment la définition de blocs de code WASM et la logique de contrôle des anomalies. Le second axe vise à étendre les fonctionnalités de COWAC et à compléter le "numerical sniffer". Le blocs de code WASM sont pour l'instant écrits en dur dans les programmes, il faut améliorer la logique de création de ces blocs pour la rendre plus maintenable et modulable. Concernant les fonctionnalités à ajouter à COWAC, deux sont requises : - Le "numerical sniffer" ne considère pour l'instant que les additions et soustractions, il faut étendre cette fonctionnalité aux divisions et multiplications - La fonctionnalité ["double-as-float"](https://github.com/Cojac/Cojac/wiki#31---double-as-float-behavior) de COJAC, permettant de vérifier doit également être implémentée #### Améliorations supplémentaires proposées Le projet présentera également une ou plusieurs POC de nouvelles fonctionnalités. Les propositions de M. Bapst sont les suivantes : La logique de contrôle des anomalies se fait via des fonctions WASM qui substituent les opérations arithmétiques, effectuent le contrôle d'anomalies puis appellent une fonction de logging javascript si une anomalie est détectée. Il serait préférable que le contrôle et l'exécution de l'opération substituée se fasse directement en javascript. À l'origine ce fonctionnement avait été jugé nécessaire afin de garantir que les calculs soient faits de la bonne manière mais JS et WASM sont tous deux censés suivre les mêmes normes IEEE. L'implémentation de la fonctionnalité ["wrapper"](https://github.com/Cojac/Cojac/wiki#4---cojac-the-enriching-wrapper) de COJAC serait une piste à creuser, mais cela n'est pas forcément faisable (au niveau de l'interaction entre WASM et JS). L'implémentation du [calcul par intervalle](https://github.com/Cojac/Cojac/wiki#43---wrapper-interval-computation) serait également intéressante. Changer radicalement la représentation interne → nombres à virgule fixe, posit unum, ... Synthétiser le logging (si on a la localisation de l'anomalie, résumer les occurrences de cette dernière). Instrumenter du code JS. Étendre l'instrumentation côté machine à l'aide de WASI. M. Michel propose aussi de factoriser la déclaration des fonctions "custom", notamment dans l'idée de faciliter l'extension du programme. #### Autres Étudier le cadre des fonctionnalités qui seront implémentées (si on prend en charge toutes les opérations sur les floats, doit-on prendre le calcul de vecteurs de float en compte aussi ?). Citer dans l'introduction les motivations derrière l'utilisation de WASM afin de montrer l'intérêt du projet. Mesurer l'impact sur les performances, par exemple en effectuant tous les calculs en JS. ## 2. Décisions La documentation (PV, rapport, cahier des charges) sera à disposition dans le repository, dans un dossier docs. Elle sera rédigée sur une branche `docs` qui sera merge dans `main` à chaque changement. M. Michel travaillera en présentiel à l'HEIA les lundis et mardis, dans la salle D2018. ## 3. Prochaines étapes | Tâche | Délai | Participants | | ----- | ----- | ------------ | | Prendre contact avec M. Wicht | 20/05/2025, 17:00 | Luca Michel | | Ébauche du cahier des charges | 20/05/2025, 17:00 | Luca Michel | > Prochain meeting: **21/05/2025, 10:15-11:00**