# fiche_synthese.tex:

l11 : Toujours donner le vrai nom quand tu donnes un acronyme pour la première fois.
l12 : s/permit/permits  non ?
l12 : the assembly instruction, explique un peu. Là on sait pas si tu parles de l'assemblée nationale ou bien d'une instruction assembleur :P
l13 : where are variables currently located
l14 : explique rapidement ce que veut dire unwind ?
l31 : s/computation/computations non ?

l76 : have been tested il me semble.
l87-88 : Je comprends pas. C'est pas included plutôt que including ?
Dans cette suite de paragraphes : Beaucoup de redondance, regarde les débuts
des deux derniers : The implmentation is not yet release-ready et juste après
The implementation is not production-ready. Pareil pour les infos des deux §
précédents, j'ai l'impression de lire 2 fois de suite la même chose.

l134 : supprime la , ou le . qui sont adjacents.

# report.tex

l77 : s/whose/which/
l88 : onto the stack in reversed order iirc.
l111 : the decision of using it is up to the compiler on x86\_64 System V
l113 : s/subtracting/substracting
l153 : s/tha/that
l195 : donner un lien vers la stack-unwinding library ?
l215 pour le torbrowser, euh tu fais ça comment ? Parce c'est quand même
majoritairement un gros bout de python autour d'un firefox un tout petit peu
moddé. Il n'y a pas un autre exemple ?
l221 : s/was forced to/ had to/ pour éviter la redondance non ?
l229 : idem que pour DWARF, donner le vrai nom de l'acronyme.
l236-237 : ,\ldots{} et non , \ldots. L'avantage de passer l'argument vide,
c'est que ça te mets le bon espacement après :P

## subsection 1.6 : How big are FDEs?

C'est très (trop ?) court. Si tu peux mettre l'histogramme avec pour compléter
ça serait pas mal, là on se demande à quel point il est utile de faire une
subsection pour ça.

## subsection 1.7 : Unwinding state-of-the-art

Pareil trop court je pense. Tu peux pas reparler un peu de C++ et de leur
version de l'unwinding ? Ou alors, vite fait parler du caching pour qu'on
comprenne ce qu'il se passe.

l555 : conciseness plutôt que brevity non ? brevity est assez peu courant.
l736 : justifie un peu pourquoi -O2 et pas -O3 éventuellement. On comprend pas
vraiment pourquoi tu ne fais pas du -O3.

Dans cette subsection aussi, il y a un travail pour ordonner les case du switch
selon les fréquences d'apparition des instructions DWARF ou bien c'est juste en
ordre croissant ?

l775 ; le bout de code collé à gauche, c'est un peu tout moche non ?

l807 : un néophyte ne sait pas à quoi correspond /proc. Tu perds tou·te·s les
catégoricien·ne·s là ^^
l833 : the waste of space je pense. Là ça fait bizarre à lire.
l876 : \ehelfs file ou alors to shrink the size of \eh_elfs
l880 : the major optimization that reduced ou bien The optimization that most
reduced non ?
l922 : Si c'est zasy to prove, pourquoi ne pas le mettre, même en annexe ?  À
moins que tu laisses un hint pour une question facile ?
l986 : natural enough setup, tu veux pas plutôt mettre legitimate ou un truc
dans ce genre ? On trouve pas ce genre de setup dans une forêt ou au fond d'un
lac ^^
l997-998 : concordance : being linked et being very light. Tu te réfère
toujours à l'intérêt du début de la phrase.

l1003 : and to implement.
l1011 : vanilla version, c'est standard en anglais t'es sûr ?

l1058 : start swappping -> explique ce que c'est, encore une fois tu as des
béotiens devant toi ^^

l119-1123 : Ok, joli nombre mais ça compare à quoi ? c'est combien sans, etc ?
l1125 : are most probably, je comprends pas. faut réorganiser les mots "are most probably due to"
ou alors en supprimer un mais là c'est weird.

l1181 : should be implemented plutôt que are necessary to implement je pense.

Ça manque d'une conclusion je pense.

Remarque générale : listings, j'aime pas, je trouve ça moche, et la coloration syntaxique est un peu nulle.
Je préfère largement minted, ça utilise pygmentize en background, et c'est assez magique :3