Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais... si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut
* ni ajouter de breakpoint à la volée
* ni modifier de variable à la volée
* ni faire du pas-à-pas
Non, ce n'est ni ce que j'ai dit, ni ce que je crois.
Dans quel monde tu vis ?
Dans un monde où les bancs industriels coûte cher, ils sont donc partagés. Donc quand tu as une après midi sur le banc pour faire tes tests, tu y restes coûte que coûte. Si tu trouves un bug rapidement à 14h30. Tu as deux choix, soit tu corrigse et recompiles, mais le temps de recompilation (4h) me donnera un nouvel essai dans, heu ben demain en fait. Sauf que le lendemain, je n'ai pas de créneau avant 16h.
Pour optimiser mon temps sur le banc, je recommence en « corrigeant » le bug dans le débugger. A ce point, j'ai deux choix, soit je contourne le bug à chaque fois manuellement (avec une interface graphique), avec gdb, je peux scripter cette partie et gagner du temps.
Il est possible qu'une bonne interface graphique de debug permette de scripter, mais je n'en connais pas.
Est-ce qu'avec ton gdb tu peux exprimer une condition pour activer ou non un breakpoint (genre "arrête-toi ici seulement si ceci et cela" en ayant accès à toute l'expressivité de groovy et même ta logique métier) ?
Oui.
Est-ce que tu peux sélectionner une ligne de ton programme et cliquer/taper le raccourci clavier "j'ai pas mis de breakpoint mais relance le flot d'exécution jusqu'à cette ligne peu importe ce qu'il se passe" ?
Je ne suis pas sûr de comprendre le « peu importe ce qu'il se passe ».
Est-ce que tu peux abandonner le contexte courant ("drop frame" dans IntelliJ, désolé flemme de chercher mieux) en revenant au début de ta méthode et en remettant tout le contexte (variables, paramètres, etc.) dans l'état où il était au début histoire de revoir ce qu'il se passe ?
Je ne sais pas le faire, mais il me semble que gdb sait faire depuis quelques versions.
[^] # Re: smart pointer
Posté par Anthony Jaguenaud . En réponse au journal Retour aux sources. Évalué à 5.
Non, ce n'est ni ce que j'ai dit, ni ce que je crois.
Dans un monde où les bancs industriels coûte cher, ils sont donc partagés. Donc quand tu as une après midi sur le banc pour faire tes tests, tu y restes coûte que coûte. Si tu trouves un bug rapidement à 14h30. Tu as deux choix, soit tu corrigse et recompiles, mais le temps de recompilation (4h) me donnera un nouvel essai dans, heu ben demain en fait. Sauf que le lendemain, je n'ai pas de créneau avant 16h.
Pour optimiser mon temps sur le banc, je recommence en « corrigeant » le bug dans le débugger. A ce point, j'ai deux choix, soit je contourne le bug à chaque fois manuellement (avec une interface graphique), avec gdb, je peux scripter cette partie et gagner du temps.
Il est possible qu'une bonne interface graphique de debug permette de scripter, mais je n'en connais pas.
Oui.
Je ne suis pas sûr de comprendre le « peu importe ce qu'il se passe ».
Je ne sais pas le faire, mais il me semble que gdb sait faire depuis quelques versions.