[comment]: <> "LTeX: language=fr"
# Travail de Bachelor - PV Semaine 3

**Date** : 02/06/2025

**Lieu** : Salle D2021

**Heure** : 8:15-8:54


| Participants   | Présence | Rôle                                  |
| -------------- | :------: | ------------------------------------- |
| Bapst Frédéric | présent  | participant            |
| Michel Luca    | présent  | participant, organisateur, secrétaire               |

Agenda de séance :

- Retour sur le PV de la séance précédente
- Retour sur la dernière version du cahier des charges
- Bref aperçu de la présentation à l'intention de M. Wicht
- Questions/Réponses

## 1. Points discutés

### Retour sur le PV de la séance précédente

Pas de commentaires.

### Retour sur la dernière version du cahier des charges

Pas de commentaires, la version 0.3.0 est validée.

### Aperçu de la présentation à l'intention de M. Wicht

M. Michel n'a pas commencé la présentation, les points suivants doivent y figurer :

**Décrire la POC de M. Julmy**

- Features implémentées
- Fonctionnement de l'instrumentation
- WAIL

**Brièvement introduire WASM**

**Définir les objectifs du projet**

Distinguer les features que l'on pense réalisables et les autres (*Wrappers*)

**Décrire le planning**

**Présenter les défis**

- Types de nombres supportés par JS
- Système de logging plus concis
- Faisabilité des *Wrappers*

**Présenter la démo du PS5**

- Certains overflows sont attendus
- Le logging n'est pas ergonomique

### Wrappers

L'implémentation des *wrappers* sera compliquée.

L'espace mémoire alloué pour les types de nombres est plus petit que celui nécessaire à des objets. Il faudrait donc utiliser des pointeurs par exemple, mais cela demande de modifier le comportement de **toutes** les opérations sur les types ciblés afin de garantir le bon fonctionnement du programme. 

### Architecture de l'instrumentation

Il serait envisageable d'utiliser un langage autre que JS, capable d'être compilé vers du WASM. Cela comporte cependant des inconvénients :

- Perte de confort des utilisateurs (et altération du public cible)
- Perte des fonctionnalités de la librairie WAIL

Si l'on se dirige vers une version locale, l'utilisation de COWAC demanderait le déploiement local des applications pour les utilisateurs, or ça n'est pas toujours possible. Encore une fois, cela changerait le public cible.

De par le fait que JS ne met pas à disposition des types d'entiers, il faut envisager des manières de simuler ces types si l'on décide de faire l'instrumentation via des fonctions JS pures. Il serait par exemple possible d'utiliser le type *BigInt* proposé par JS (avec une grande perte de performances cependant).

WAIL est une librairie amateur potentiellement limitée, il faut prendre ça en compte.

Implémenter diverses variantes de l'architecture pourrait être instructif, mais c'est un processus chronophage.

Prendre contact avec M. Julmy afin de lui demander si le logiciel implémenté durant ce travail de bachelor peut également s'appeler COWAC.

Citer M. Julmy dans les remerciements du rapport.

Se pencher sur l'implémentation de COJAC afin d'avoir une piste d'implémentation.

### Questions

Le dépot JS de M. Julmy doit-il être mis à jour par ce travail de bachelor ?

Non, créer un nouveau dépot si nécessaire.

## 2. Décisions

Aucune.

## 3. Prochaines étapes

| Tâche | Délai | Participants |
| ----- | ----- | ------------ |
| Conception de la nouvelle architecture d'instrumentation | 09/06/2025 | Luca Michel        |

> Prochain meeting: **09/06/2025, 8:15-9:00**