›

Aide pour le debugger

colas_colas_ Membre
dans API AppKit #1

Bonsoir !


Avis aux pros du débogage !


 


Je me demande si la chose suivante est possible avec le debugger.


 


Je lance mon programme, sans aucun point d'arrêt.


À un moment j'appuie sur pause.


Là , j'aimerais pouvoir voir les objets en mémoire, cliquer sur l'un pour accéder à  sa classe et voir la valeur de ses properties.


 


Merci !


Colas


Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    Bah Heu oui, Just do it.
  • colas_colas_ Membre
    #3

    :-)


     


    mais encore ?


     


    Par exemple, une fois que j'ai cliqué sur pause, j'arrive sur cet écran. Mais je ne sais comment voir les objets qui sont en mémoire...


    Sur quel bouton dois-je cliquer ?!


     


     


     


    Merci !!!


  • AliGatorAliGator Membre, Modérateur
    #4
    Il fait que tu remontes dans une frame correspondant a du code à  toi pour voir tes variables à  toi dans leur contexte.
  • colas_colas_ Membre
    #5

    Est-ce que ce que tu appelles frame correspond à  la liste de méthodes appelées sur la gauche ?


     


    Dans ce cas, si je stoppe le programme en appuyant sur pause et non grâce à  un point d'arrêt, il y a des chances que le programme soit juste en mode "j'attends un event"... et donc, il n'y aura pas de frames à  moi, non ?


  • AliGatorAliGator Membre, Modérateur
    #6
    Tout a fait. Sauf si tu tombes par hasard sur un bon moment.


    Mais en même temps c'est logique au moment où tu fais pause tu es dans un contexte où il manipule rien de tes méthodes et objets or une variable n'a en général de sens que dans un contexte (une variable déclarée dans le corps d'une fonction n'existera que quand la fonction est exécutée et pas à  l'extérieur)


    Après si tu veux accéder à  des objets qui existent même si tu n'as pas fait pause dans une frame qui les manipule, par exemple une property de ton rootViewController ou quoi, bah il va falloir aller le chercher. Genre y accéder en tapant dans la console "expr UIViewController* $rvc = [[[[UIApplication sharedApplication] delegate] window] rootViewController]" et tu peux ensuite faire des trucs comme "po $rvc.proprieteAInspecter"
  • colas_colas_ Membre
    #7

    OK, c'est ce que je faisais, mais c'est un peu galère car il me semblait qu'il n'y avait pas d'autocomplétion. D'ailleurs l'autocomplétion est un peu aléatoire, des fois elle marche des fois non.


     


    Au passage, j'apprends la syntaxe expr UIViewController* $rvc = [[[[UIApplication sharedApplication] delegate] window] rootViewController] qui va m'être très utile... Merci !!! Génial !


     


    À part et po et expr, y a-t-il d'autres formules magiques à  connaà®tre ?


     


    Au passage, une autre question. Dans le debugger, il est impossible d'accéder au constantes des enums, genre UITableViewScrollDirectionVertical, non ? Y a-t-il un moyen de s'en sortir ?


  • AliGatorAliGator Membre, Modérateur
    #8
    Le REPL du débugger est parfois un peu capricieux en effet. S'il ne reconnait pas ton enum, tu peux toujours lui passer la valeur numérique à  la place. Par exemple passer 4 au lieu de NSUTF8StringEncoding etc.
    C'est vrai que c'est pas la panacée dans ce cas, ces petits caprices de LLDB, mais bon, faut faire avec.

    Sinon, non, à  part "po" (qui est en fait un raccourci pour la commande "print-object"), "p" (raccourci pour "print", pour les types non-objet comme les int ou CGRect ou autre) et "expr", ce sont les plus utiles. Y'en a d'autres mais qui sont bcp moins fréquemment utilisés (déjà  "expr" est méconnu).

    Quand tu utilises "expr" ça ne fait qu'exécuter une instruction. Si tu veux déclarer une variable dans le cadre de LLDB, comme là  avec la variable $rvc, il faut que cette variable commence par un "$" pour qu'elle puisse être déclarée localement dans le cadre du débuggeur.
  • colas_colas_ Membre
    #9

    Et oui, faut faire avec !


     


    Je retiens :


    po


    p


    expr


     


    Autre bug (?) du debugger, quand on lui demande la frame d'un UIView, assez souvent il est très mécontent.


  • AliGatorAliGator Membre, Modérateur
    #10
    Ouais y'a des fois où faut caster le résultat dans tous les sens pour avoir ce qu'on veut, genre même si nous on sait que la frame d'une UIView c'est un CGRect, faut caster explicitement le résultat car il est perdu et ne sait pas quel est le type de la valeur de retour (pourtant elle est clairement indiquée dans le .h mais ça ne lui suffit pas toujours). Ils ont des progrès à  faire de ce côté LLDB...
  • colas_colas_ Membre
    #11

    Mais paradoxalement, si je lui demande



    
po self.myCollectionView.scrollDirection

    il me répond pas 0 ou 1, mais il me réponde UICollectionViewScrollDirectionHorizontal !!!


     


    D'ailleurs, j'ai l'impression que po a fait du progrès. Je n'utilise presque plus p... po passe sur les structures, les entiers, etc.


  • HerveHerve Membre
    #12

    Pourquoi n'utilises tu pas plutôt NSLog? Les vérifs en console sont plus efficaces à  mon avis que ce que tu veux faire (je n'utilise jamais les breakpoints pour ma part il faut dire...)


     


    Tu peux ainsi vérifier les instanciations, les valeurs crées, etc.


  • CéroceCéroce Membre, Modérateur
    #13
    Sûrement parce que pour mettre des NSLog() il faut modifier et recompiler son code, qu'on ne peut voir que ce qu'on a prévu de voir et un tas d'autres raisons.
  • HerveHerve Membre
    #14


    Qu'on ne peut voir que ce qu'on a prévu de voir.




    Bien vu! (si j'ose dire...)

Connectez-vous ou Inscrivez-vous pour répondre.