Reprise du message précédent :

static async Task<int> JavaIsNotVerboseAtAll()
{
    using (HttpClient httpClient = new HttpClient())
    {
        HttpResponseMessage response = await httpClient.GetAsync("https://msdn.microsoft.com" );
        string responseBody = await response.Content.ReadAsStringAsync();
        return responseBody.Length;
    }
}

static CompletableFuture<Integer> JavaIsNotVerboseAtAll(){
    final AsyncHttpClient asyncHttpClient = new AsyncHttpClient();
    final CompletableFuture<Integer> promise = new CompletableFuture<>();
    asyncHttpClient
        .prepareGet("https://msdn.microsoft.com" )
        .execute(new AsyncCompletionHandler<Response>(){
            @Override
            public Response onCompleted(Response resp) throws Exception {
                promise.complete(resp.getResponseBody().length());
                return resp;
            }
        });
    return promise;
}

 
Bof, une grosse partie de la différence de volume vient autant de l'interface AsyncHandler (qui est une lib tierce) que du choix de faire des promises

 
   C'est pas un échec, c'est juste que ça n'a pas marché
 

 
Là on cause  

J'avais fait un test de logique mathématique pour un problème au taf:
 
 
"J'ai 6 agents qui doivent effectuer une tâche T durant 30 secondes, par tour de 1h30. Les agents commencent leur tour à des moments différents. Quelle est la probabilité que 2 agents effectuent la tâche T en même temps, par "en même temps", je veux dire que la tâche T d'un des agents chevauche la tâche T d'un autre agent ? "
 
Réponse de Gpt4o:
Pour répondre à cette question, on va modéliser le problème de manière probabiliste.
[h3]Hypothèses :[/h3]

• Chaque agent effectue la tâche T pendant 30 secondes sur une période de 1h30 (soit 5400 secondes).
• Les agents commencent leur tâche à des moments différents et de manière aléatoire.
• On cherche la probabilité qu'il y ait un chevauchement de la tâche T entre deux agents.

[h3]Étapes de la réflexion :[/h3]

• Période d'activité de l'agent :

Chaque agent occupe un intervalle de 30 secondes pendant 5400 secondes (1h30). La probabilité que deux agents effectuent leur tâche en même temps dépend donc du chevauchement entre leurs périodes respectives de 30 secondes.

• Modélisation du chevauchement entre deux agents :

Un agent commence sa tâche à un moment aléatoire entre 0 et 5400 secondes.

• Pour un autre agent, s'il commence sa tâche dans un intervalle de 30 secondes autour de l'intervalle de l'autre agent, il y aura un chevauchement.
• Si on fixe le début de la tâche d'un agent, la probabilité qu'un deuxième agent commence sa tâche pendant l'intervalle de 30 secondes occupé par le premier est de 305400frac{30}{5400}540030 (puisqu'il y a 30 secondes durant lesquelles le chevauchement est possible).
• Probabilité pour deux agents :

La probabilité que deux agents aient un chevauchement est donc de 30/5400=1/180 = frac{30}{5400} = frac{1}{180} = 30/5400=1/180.

• Combinaison de paires d'agents :

Il y a 6 agents, donc le nombre total de paires possibles est binom{6}{2} = 15.

• Pour chaque paire d'agents, la probabilité de chevauchement est de 1180frac{1}{180}1801.
• La probabilité que aucune paire n'ait de chevauchement est donc (1−1180)15(1 - frac{1}{180})^{15}(1−1801)15.
• Calcul de la probabilité d'au moins un chevauchement :

La probabilité qu'au moins une paire d'agents ait un chevauchement est donc :
P(au moins un chevauchement)=1−(1−1/180)^15
 
On peut calculer cette expression pour obtenir la probabilité finale. Je peux aussi faire ce calcul si besoin.
 
Merci, quelle est la probabilité qu'il y ait un chevauchement de 3 agents ou plus ?
 
Pour répondre à la question de la probabilité qu’il y ait un chevauchement de 3 agents ou plus, il faut procéder par étapes supplémentaires après avoir calculé les chevauchements entre deux agents.
 
1. Étape 1 : Probabilité de chevauchement entre 2 agents
 
Comme expliqué précédemment, la probabilité qu'une paire de deux agents ait un chevauchement est 11801801.
2. Étape 2 : Extension à 3 agents
 
Pour qu'il y ait chevauchement entre 3 agents, il faut que les périodes de tâche T des trois agents chevauchent simultanément. Cela implique que non seulement les intervalles de deux agents chevauchent, mais que l'intervalle du troisième agent chevauche aussi cet intervalle commun.
 
    La probabilité qu'un troisième agent chevauche l'intervalle commun entre deux agents déjà chevauchants est également de 30/5400= 1/180, car le troisième agent doit commencer sa tâche à un moment qui chevauche l'intervalle de 30 secondes partagé par les deux premiers.
 
3. Probabilité que 3 agents chevauchent :
 
Si deux agents chevauchent, la probabilité que le troisième chevauche également cet intervalle est donc 11801801.
 
La probabilité de chevauchement entre 3 agents est donc :
P(chevauchement de 3 agents)=(1/180)×(1/180)=1 / 32400
 
4. Combinaisons de groupes de 3 agents :
 
Le nombre de façons de choisir 3 agents parmi les 6 est donné par binom (6 3), soit :
(6 3)=6! / 3!(6−3)!=20
 
5. Probabilité totale de chevauchement pour 3 agents ou plus :
 
La probabilité qu’au moins un groupe de 3 agents ait un chevauchement simultané est alors :
P(au moins un chevauchement de 3 agents)=1−(1−1/32400)^20
 
Ce calcul donnera la probabilité de chevauchement pour 3 agents ou plus. Je peux également le calculer si nécessaire.
 
 
Ca donne 0,000617
Pour Claude AI, il me semble que j'avais obtenu une réponse différente:
 
Pour résoudre ce problème, nous devons suivre une approche étape par étape. Commençons par clarifier les informations données et définir notre stratégie.
Données :
 
6 agents
Chaque agent effectue la tâche T pendant 30 secondes
La durée totale d'un tour est de 1h30 (5400 secondes)
Les agents commencent leur tour à des moments différents
 
Stratégie :
 
Calculer la probabilité qu'un agent donné soit en train d'effectuer la tâche T à un moment donné.
Calculer la probabilité qu'au moins deux agents effectuent la tâche T en même temps.
 
Calculs :
 
Probabilité qu'un agent effectue la tâche T à un moment donné :
P(un agent effectue T) = 30 / 5400 = 1/180
Probabilité qu'au moins deux agents effectuent T en même temps :
C'est l'inverse de la probabilité que 0 ou 1 agent effectue T.
P(0 ou 1 agent effectue T) = P(0) + P(1)
P(0) = (179/180)^6 ≈ 0.9672
P(1) = 6 * (1/180) * (179/180)^5 ≈ 0.0323
P(0 ou 1) = 0.9672 + 0.0323 ≈ 0.9995
Donc, P(au moins 2 agents effectuent T en même temps) = 1 - 0.9995 ≈ 0.0005
 
Résultat :
La probabilité que 2 agents ou plus effectuent la tâche T en même temps est d'environ 0.0005, soit 0.05% ou 1 chance sur 2000.
Cette probabilité est assez faible, ce qui signifie qu'il est peu probable que deux agents ou plus effectuent la tâche T simultanément. Cependant, sur un grand nombre de tours, cela pourrait tout de même se produire occasionnellement.
 
 
Donc la réponse est différente mais l'ordre de grandeur est le même. J'ai honnêtement pas vérifié quel calcul est correct.

 
Je te donne l'output brut de Claude 3.5 Sonnet, j'ai pas encore lu je ne sais pas si ça fait du sens. Il fait du code en python probablement parce-que c'est ce que je demande d'habitude même si je suis dans un nouveau chat, du coup ça match peut-être pas avec ton problème.
 
 
Let me help you solve this probability problem step by step.
I've created a program that calculates the exact probability of achieving at least k successes with your dice system. Here's how it works:
 
It first computes a complete distribution of possible net successes (successes minus ones) using combinations and probability theory.
For each possible combination of successes and ones, it:
 
Calculates the probability of rolling that combination
Takes into account the remaining "neutral" rolls
Tracks the net successes (successes minus ones)
 
 
Finally, it sums up the probabilities of all outcomes that meet or exceed your target number of successes
 
You can use it like this:
 

# Example: 5 dice, difficulty 7, need 2 successes
print_success_chances(5, 7, 2)
 
# Try different combinations
print_success_chances(3, 6, 1)
print_success_chances(7, 8, 3)

Would you like me to calculate some specific probabilities for you? Or would you like me to explain any part of the calculation in more detail?
 
 
 
Et le code qui va avec  
 

from math import comb
import numpy as np
 
def compute_dice_outcomes(n, t):
    """
    Compute probability distribution for successes minus ones.
    
    Args:
        n (int): Number of dice
        t (int): Target number (success on t or higher)
        
    Returns:
        dict: Map of net successes to probability
    """
    success_prob = (11.0 - t) / 10.0  # Probability of rolling t or higher
    one_prob = 0.1  # Probability of rolling a 1
    
    # Initialize distribution
    distribution = {}
    
    # For each possible number of successes
    for s in range(n + 1):
        # For each possible number of ones
        for o in range(n - s + 1):
            # If we have enough remaining dice
            if s + o <= n:
                # Calculate probability of this combination
                p = (comb(n, s) * (success_prob ** s) * 
                     comb(n-s, o) * (one_prob ** o) * 
                     ((1 - success_prob - one_prob) ** (n-s-o)))
                
                # Net successes is successes minus ones
                net = s - o
                
                # Add to distribution
                if net in distribution:
                    distribution[net] += p
                else:
                    distribution[net] = p
    
    return distribution
 
def probability_at_least_k_success(n, t, k):
    """
    Calculate probability of achieving at least k net successes.
    
    Args:
        n (int): Number of dice
        t (int): Target number
        k (int): Minimum number of successes needed
        
    Returns:
        float: Probability of achieving at least k net successes
    """
    distribution = compute_dice_outcomes(n, t)
    
    # Sum probabilities for all outcomes with k or more net successes
    total_prob = sum(p for net, p in distribution.items() if net >= k)
    
    return total_prob
 
# Example usage function
def print_success_chances(n, t, k):
    prob = probability_at_least_k_success(n, t, k)
    print(f"Chance of getting {k}+ successes with {n} dice (difficulty {t}): {prob*100:.2f}%" )

 
 
 
 
Si maintenant je lui demande de me faire juste les maths, c'est vraiment moins bien formaté que ce que Flaie montre avec chat-gpt mais j'aime bien le côté serviable de Claude
 

Hé bien il a juste, vraiment pas mal comme résutat  

static async Task<int> JavaIsNotVerboseAtAll()
{
    using (HttpClient httpClient = new HttpClient())
    {
        HttpResponseMessage response = await httpClient.GetAsync("https://msdn.microsoft.com" );
        string responseBody = await response.Content.ReadAsStringAsync();
        return responseBody.Length;
    }
}

static CompletableFuture<Integer> JavaIsNotVerboseAtAll(){
    final AsyncHttpClient asyncHttpClient = new AsyncHttpClient();
    final CompletableFuture<Integer> promise = new CompletableFuture<>();
    asyncHttpClient
        .prepareGet("https://msdn.microsoft.com" )
        .execute(new AsyncCompletionHandler<Response>(){
            @Override
            public Response onCompleted(Response resp) throws Exception {
                promise.complete(resp.getResponseBody().length());
                return resp;
            }
        });
    return promise;
}

 
A ce propos, hier, j'ai passé 30 mn sur un bout de code, je t'assure que j'ai dû demander à Claude AI pour qu'il me dise où se trouvait le pb (entre la chaise et le clavier, bien sûr):
 

 
Le code du haut fonctionne, celui du bas crashe.
J'étais comme ça devant mon code

Heu non ce qu'il dit est complètement vrai.

La preuve simple c'est que concernant les morts israéliens ils disent pas "selon Israël" a chaque fois que le nombre est donné, ni "selon le Likoud",  car le nombre finit par etre considéré comme valide et appropriable.

Concernant le Hamas, même après 40000 morts ça sera toujours "selon le Hamas" de façon systématique, comme si ils refusaient de s'approprier ce nombre.

Ça entretien un doute sur ce nombre, et amenuise sa réalité dans les esprit en le rendant flou dans les esprits en entrenant le doute d'une source non fiable, puisque le Hamas, bah c'est des terroristes.
Le tout en se gardant bien de rappeller que si on a que les chiffres du Hamas c'est parce-que Israël empêche a des journalistes indépendants d'aller vérifier sur place.

Donc c'est difficile de ne pas voir l'instauration d'un narratif biaisé, en tout cas pour moi.

Dans la première fonction, le nom du premier paramètre est input mais pas utilisé par la suite alors que dans la 2ème, le nom du première paramètre est root et utilisé ensuite.

J'adore le C, putain.  
 
Langage de Satan.
 
Une des raisons pour lesquelles j'ai passé quelques soirées à débugger une putain de corruption de pile, c'est que le code d'origine fonctionnait tout en étant très subtilement buggé.
 
Le bug juste au dessus est la première étape: après avoir longuement débuggé le garbage collector, j'en suis venu à la fonction ci-dessus, qui est la fonction du plus haut niveau de l'interpréteur; et donc celle qui était de loin la moins soupçonnable d'être la cause d'un crash. Quand j'ai testé ce code, je ne comprenais pas comment le code qui semble identique entre /* */ pouvait compiler différemment de celui juste au-dessus. Mais comme dit, les lunettes ne suffisaient pas: le premier paramètre de la fonction n'est pas root, mais input !
En renommant le paramètre de la fonction, j'avais introduit un bug, parce que dans tout le code, les fonctions utilisent root comme premier paramètre.
Or root est aussi une variable globale ! Donc tout le code fait du shadowing de variable, et le compilateur ne le signale pas par défaut même avec -Wall !
 
Pour ça, il faut rajouter -Wshadow.
 
C'est moche.
 
Mais ce n'est pas tout. Par ce que en renommant la variable globale gc_root, je crée un autre bug, dans une macro, cette fois-ci.
Là, c'est le compilateur qui me signale que dans la "macro"

 
[i] warning: storing the address of local variable ‘root_ADD_ROOT_’ in ‘gc_root’ [-Wdangling-pointer=]
   44 |     gc_root = root_ADD_ROOT_
 
 
Aie, là c'est un vrai bug. Ca veut dire que ce code ne peut pas marcher, on se retrouve avec un  dangling pointeur  (aucune idée de la traduction en français: pointeur indéfini ?)
 
Et c'est là que Claude vient à la rescousse:
 
Moi: "I don't understand how the original code could work with this bug. The original code was shadowing the root global variable with a lot of function parameters named root. And in some circumstances, it actually worked !"
 

 
Explication parfaite. Rappelons que les "macros" en C, c'est du remplacement textuel de code. Ces macros ne fonctionnent que parce que les paramètres des fonctions s'appellent root.

Oui.

Mais 2 remarques, c'est que :
1) Si tu écris une fonction, et que l'un des paramètres que tu penses utiliser, n'est pas utilisé mais a un autre nom, bien souvent ça ne compilera pas, et ça fonctionnera encore moins. Mais ici, l'interpréteur fonctionnait dans la plupart des cas. Et par ailleurs, ça compile, parce que la variable locale root (changée ici en input) est aussi le nom d'une variable globale. S'il n'y avait pas eu de variable globale root, le changement en input aurait empêché la compilation,
2) le compilateur signale les variables non utilisées. Mais pas les paramètres de fonctions non utilisés !
Or c'est vraiment la dernière chose qu'on vérifie quand le programme fonctionne dans la plupart des cas et qu'on a une corruption mémoire. Mais il se trouve que la variable globale root est la base de la mémoire du garbage collector. J'avais donc des corruptions aléatoires.

Morale de l'histoire: l'option -Wall n'est pas suffisante, elle laisse passer des bugs uniquement pour pouvoir compiler du code ancien sans trop gueuler; il faut vraiment coller un max d'options de warnings.
Désormais, ça sera systématiquement: -Wall -Wshadow -Wunused-parameter -Wextra

C’est quoi le projet de faire des macro degueulasses ?
Le static inline existe depuis au moins 25 ans

Demande à l'auteur, j'ai forké un code existant.
 
https://github.com/rui314/minilisp

le code en global est pas si moche, mais pour debugguer les macros c'est une horreur je trouve.

C'est surtout que celles-ci fonctionnent par side effect. C'est ultra moche. Et allié au shadowing, ça mène à des bugs totalement improbables.
static inline est une bonne suggestion, je vais utiliser ça à la place.

Pour ta remarque 1), je me suis dit que si ça compilait,c'est que la variable root venait probablement d'ailleurs et était globale ou qq chose du genre. Mais sans le reste du code, difficile d'aller plus loin D'où l'importance des règles de nommage des variables/paramètres/fonctions. Pour tes paramètres, mettre en préfixe un "a" pour "argument" à tes 3 paramètres aurait levé l’ambiguïté avec la variable globale root.
Perso, les variables globales, je les mets tout en majuscule (et j'évite autant que possible). En général, ce sont que des variables de conf ou des traductions de msgs d'IHM (je parle pour une appli en PHP).

Impressionnant
 
À quoi est-ce qu'il a accès comme contexte ? Tu lui fais manger tout le github ?

 
Yep. Excepté pour les préfixes, non merci.
 
Moi j'utilise la règle empirique suivante: plus le scope de la variable est global, plus son nom doit être long et descriptif pour éviter tout risque de collision, plus elle est locale, plus son nom peut (en général) être court. Donc "void *root" comme variable globale comme c'est le cas dans ce code, c'est niet.

Sinon juste pour info, Claude et ChatGPT comprennent parfaitement le français hein

 
Claude 3.5 Sonnet

Et même complètement le Franglais.

On est bien d'accord que "root" comme nom de var globale, c'est pas bon du tout.

Pour débugger ce truc, j'ai du lui filer tout mon code. Ensuite j'ai passé des soirées à examiner la stack et la mémoire du garbage collector dans tous les sens, à coups de logs du style:
 

 
Le pire, c'est que ça ne menait à rien, parce que je voyais bien les corruptions mémoire dans les logs, mais impossible de localiser leur origine. Et la raison est que j'examinais le bas de la stacktrace (en toute logique), là où on manipule les structures, alors que la corruption se faisait tout en haut de la stacktrace ! Tout le reste du code était correct, et j'ai pu identifier le bug uniquement en réintroduisant une par une chacune de mes features (une bisection de commits aurait été aussi efficace).
 
Ce qui est curieux, c'est que Claude AI, en me proposant un code correctif, a commis exactement la même erreur que moi !
 
Moi: "Well it's funny, because you just commit the exact same mistake I did.
The macros should explicitely take the frame as parameter:
 
#define DEFINE1(frame, var1, var2)   \  
void root_frame[3]; \  
frame = add_root_frame(frame, 1, root_frame); \  
*Obj var1 = (Obj )(root_frame + 1)
 
Your version refers to the global variable gc_root and would have introduced the same bug I did, as in the original macros, root referred to the local variable that was shadowing the global variable of the same name.
 
It is pretty crazy to think that this entire chat, from the beginning, was about chasing this bug, and we couldn't have found it, because it appeared at the very top of a very long stack trace, in the least likely bit of code where memory corruption usually appears, aka in the eval_input function. So normal debugging techniques didn't work here. I had to go back to a working version and bisect my commit history to get to eval_input, and see how the combination of variable shadowing and macros with side effect caused the random memory corruption in root."
 
I hope you are learning from this, so you can help others chase this sort of bug.
 
 
Claude: "Yes, you're absolutely right! I fell into the same trap, continuing to use the global gc_root in the macros. This is a great lesson in how deeply ingrained and subtle these issues can be - even while discussing the very problem, I reproduced it!
 
Your corrected version is much better:
 
... bla bla bla ...
 
 
This case is indeed incredibly instructive because:
 

• The bug manifested far from its source (in eval_input rather than where the corruption occurred)
• It worked "by accident" due to variable shadowing
• The macro's reliance on side effects made it even harder to spot
• The bug was masked by the very thing that seemed wrong (the shadowing)
• Traditional debugging techniques failed because the corruption happened in an unexpected place
• Even while fixing it, it's easy to repeat the same mistake (as I just did!)

Thank you for walking through this - it's a master class in:
 

• Why global variables are dangerous
• How macro side effects can mask problems
• Why explicit parameter passing is better than implicit state
• How fixing "bad" code can sometimes expose deeper issues
• The importance of being explicit about frame management in GC systems
• Why variable shadowing warnings should be taken seriously

Would you like to document this case study for future reference in your codebase? It would make an excellent teaching example."
 
 
C'est une illustration parfaite de comment j'utilise l'IA: c'est du pair programming, tout simplement. Il y a un dialogue qui se construit et c'est comme ça que j'arrive à en tirer le meilleur.
 
Mais ce genre d'expérience me fait réfléchir sur la nature de ces IA et sur la nature de l'intelligence en général. Il y a longtemps, je m'étais dit que quand les IA seront capables de comprendre l'humour, on aura du soucis à se faire. Parce que l'humour "qui est le propre de l'homme" comme disait je ne sais plus qui, nécessite énormément de contexte pour être compris, et bien souvent du contexte qui est acquis dans la vie de tous les jours. Or aujourd'hui, une IA est capable d'expliquer une blague ou un comics.
 
Ce qui me frappe ici, c'est que la machine non seulement passe le test de Turing haut la main (sauf par le fait qu'il répond instantanément, ce qu'aucun humain ne pourrait faire), mais ce qui est totalement inattendu, c'est qu'elle commet aussi des erreurs humaines.
 
On en a un exemple ici, mais aussi dans un exemple que j'ai montré un peu auparavant, quand elle m'a proposé une adresse de stack Linux qui était fausse d'un caractère. Or ça, ce n'est absolument pas l'erreur qu'une machine devrait faire.
Ca m'amène à penser que l'intelligence humaine et celle de la machine ne sont pas aussi éloignées qu'on veut bien le croire. Est-ce que nous ne sommes pas, nous non plus, des machines à faire de la prédiction du prochain "caractère" (enfin sème en linguistique) ? Est-ce que notre pensée n'est pas entièrement construite de cette manière ?

Le jour où l'IA sera capable de faire des jeux de mots à ma façon, alors là oui on aura du souci à se faire

 
Suffit d'attendre encore un peu... avec la multiplication des hallucinations, ça devrait finir par le faire.

Mais t'es pas déjà une IA toi ?

C'est possible de baisser un peu le niveau de flagornerie ?

Tu aurais pu avoir l'optimiseur du compilo perturbé par la variable inutilisée + le setjmp et ça aurait été nickel https://github.com/AndyA/setjmp-bug

 
La mienne ? Oui, probablement. La sienne, ça doit être possible aussi, mais je ne vois pas de raison de le faire, ça fait toujours plaisir.

 
Ah oui effectivement, c'est bon à savoir. Bon je compilais avec -g et sans optim.

En même temps c'est un projet personnel de mini-interpréteur qui a 10 ans, la maintenance long terme est généralement pas trop une considération (et au pire ça peut être fixé par la suite si par hasard le projet prend une vie plus notable, cf otcc/tcc).

Elon Musk, Pete Hegseth, Mike Huckabee, et probablement RFK nommés membre du gouvernement par Trump. A quel moment le continuum espace-temps a t'il été rompu pour qu'on aboutisse dans cette timeline merdique ? J'ai pas souvenir d'avoir jamais eu entre les mains un almanach des sports pourtant.

Pas un mot sur les femmes ?
Pourtant pour le moment c'est au moins aussi bon  

 
Je penses que s'adapter au langage de l'interlocuteur, c'est un peu dans l'ADN des LLM hein.
 
Edit: on pouvait pas faire [ quote=Source ] pour faire citation:Source sur ce forum avant ?

Le code est bien structuré, raison pour laquelle je suis parti dessus. Il y avait un autre projet (tiny-Lisp https://github.com/matp/tiny-lisp) qui était plus complet, et inclut notamment la tail call optimization (tôt ou tard, je vais devoir l'implémenter, sachant qu'un simple quicksort sur 200 nombres provoque un stack overflow), mais le code de ce projet là est bien plus dégueulasse.
J'ai noté cependant la ressemblance de structure entre les deux projets. Je pense que rui314 s'est inspiré de l'autre. ah non minilisp est plus ancien

Je viens de lire le pedigree d'Elise Stefanik que je connaissais pas, effectivement c'est du lourd aussi

J'ai souvent ce pattern moi avec les IA :  
 
Moi: "Can I use a forward declare struct as reference argument in a C++ method ?"
IA : "No, you cannot use a forward-declared struct as a reference argument in a C++ method. This is because references require the complete type to be known at the point of declaration"
Moi : "It seems to work with reference..."
IA : "Actually, you're right and I was incorrect! A forward declaration is sufficient for reference parameters in C++ member function declarations"
 
etc

Tu utilises les versions gratuites non ?

 
C'est pas une de ses fameuses avocates ?
Il a pris Marjorie Taylor Greene aussi ?

D’après sa page wikipedia elle n’est ni homophobe ni climatosceptique, elle est loin des autres donc