1

Voilà le récapitulatif des propositions faites dans le topic "Connextion avec TiEmu":

* multi-fenêtre polluant => debugger style VTi (je pense utiliser des fenetres dockables ce qui permettrait d'avoir 2 modes de présentation: l'actuel et VTi)
* le toolkit GTK et ses dépendances
* utiliser la même police que la fenêtre register dans les autres fenêtres
* Si on appuie sur F11 lors du chargement (preloading débugger), au tout début ça fait crasher TiEmu, et vers la fin ça affiche les fenêtres du débogueur, mais elles sont toutes grisées et la calc semble fonctionner normalement (mais dur à reproduire ça, ça doit être à un moment très précis).
* Si on appuie sur F12 lors du chargement (preloading debugger), le menu des ROMs se présente, mais on peut choisir ce qu'on veut, ça ne change strictement rien, et le modèle de calc par défaut se charge. Le clignotement du curseur dans HOME est alors anormal (trop rapide), mais régulier.
* ça serait possible que les deux touches Ctrl soient reconnues comme <> svp?

post 297 (Pollux):
<<
- débuggeur
* F5 sur un breakpoint ne fait que relancer le debugger sans rien exécuter
* F8 foire qd la fonction skippée contient un breakpoint (freeze jusqu'à ce qu'on fasse F11)
- fenêtre code
* désassembleur :
- je trouve pas les 0 inutiles très lisible : rol.l #$00000007,d0 :/ (VTI, lui, supprime toujours les 0 de tête)
- c'est un peu dommage de pas pouvoir distinguer move.l de moveq, idem pour addq/subq (perso j'arrive
pas à compter les cycles ou la taille du premier coup d'oeil si il faut regarder les opérandes en détail
pour savoir si c'est un moveq ou un move.l)
- movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI
- movem.l prend 2 octets de trop donc il "mange" l'instruction suivante
- pour les adressages indexés :
* il vaudrait mieux mettre la constante avant le registre, c'est mieux d'avoir lea ($42,a3),a3 pour
voir du premier coup d'oeil que a3 et a3 c'est bien le même registre
* (a3,d0.l*1) : le *1 ne sert à rien, surtout sur 68000
* VTI utilise lea (-$c,a3),a3 au lieu de lea ($fff4,a3),a3, c'est plus lisible
- il y a "trap .l" au lieu de "trap #$C"
- rts.l trifus
- il y a "bt<tab>.b" au lieu de "bt.b<tab>" (et sinon bra serait plus joli que bt smile )
* impossible de savoir si l'instruction sélectionnée est l'instruction courante sad
* les "= bidule" pourraient peut-être être colorés, je ne sais pas si c'est possible (d'ailleurs les conventions
ne sont pas très cohérentes, un coup c'est [42a1], un coup c'est [$42a1], un coup c'est = $42a1)
- fenêtre registres
* les "D3=" sont sélectionnables hum
* le double clic ne sélectionne qu'un groupe de chiffres ou un groupe de lettres mais pas la valeur hexa entière
- fenêtre stack
* +4 / +2 / 0 / +2 / +4 / ... au lieu de -4 / -2 / 0 / +2 / +4 / ...
- fenêtre memory
* scroll un peu lent
* pas de raccourcis clavier cry
- idée d'amélioration : ajouter via le clic droit "ouvrir cette adresse dans la fenêtre memory"
(sur toutes les adresses, aussi bien dans code/disassembly/memory/stack [bon ok pour les 2 derniers c'est un peu plus
compliqué puisque ça marche par octet ou par mot, mais au moins pour les deux premiers ce serait cool])
>>
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

2

ça serait possible que les deux touches Ctrl soient reconnues comme <> svp


Je veux bien mais je mappe la touche Ctrl/Diamond où ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

3

- idée d'amélioration : ajouter via le clic droit "ouvrir cette adresse dans la fenêtre memory"
(sur toutes les adresses, aussi bien dans code/disassembly/memory/stack [bon ok pour les 2 derniers c'est un peu plus compliqué puisque ça marche par octet ou par mot, mais au moins pour les deux premiers ce serait cool])

Cette fonction existe déjà dans la fenêtre code/disassembly (menu bouton droit, view memory). Dans la fenêtre register, je viens de le rajouter en même temps que "le double clic ne sélectionne qu'un groupe de chiffres ou un groupe de lettres mais pas la valeur hexa entière".
Par contre, à rajouter dans la fentre heap/stack.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

4

5

J'ai l'impression qu'on parle pas de la même chose... Qu'entends-tu par "<>" ? Equivalence ou "<" et ">" ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

6

<> c'est pour symboliser #diamond#
avatar
Combien de tas de bois une marmotte pourrait couper si une marmotte pouvait couper du bois ?

7

8

Martial Demolins (./7) :
J'ai pas fait de <> grin

Je crois que c'est mio qui avait demandé à ce que les deux touches Ctrl fassent le diamand. Ca pose un problème?


Non, c en cours.

Par contre:
fenêtre stack: +4 / +2 / 0 / +2 / +4 / ... au lieu de -4 / -2 / 0 / +2 / +4 / ...

Je dois tourner l'ensemble de la fenêtre ou simplement la première colonne ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

9

Actuellement fait:

- ça serait possible que les deux touches Ctrl soient reconnues comme <>; fait aussi pour Shift
- le double clic ne sélectionne qu'un groupe de chiffres ou un groupe de lettres mais pas la valeur hexa entière
- idée d'amélioration : ajouter via le clic droit "ouvrir cette adresse dans la fenêtre memory"
(sur toutes les adresses, aussi bien dans code/disassembly/memory/stack [bon ok pour les 2 derniers c'est un peu plus
compliqué puisque ça marche par octet ou par mot, mais au moins pour les deux premiers ce serait cool]) => fait sur toutes les fenêtres du debugger
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

10

11

tu pourrais mettre la touche du pavé numérique pour les 89 aussi

Tu parles de la touche ENTER je suppose... ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

12

- fenêtre memory: pas de raccourcis clavier


Des raccourcis pour quelles actions ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

13

14

Actuellement fait:

- je trouve pas les 0 inutiles très lisible : rol.l #$00000007,d0 :/ (VTI, lui, supprime toujours les 0 de tête)
- c'est un peu dommage de pas pouvoir distinguer move.l de moveq,
- movem.l prend 2 octets de trop donc il "mange" l'instruction suivante
- il y a "trap .l" au lieu de "trap #$C"
- rts.l (heu!??)
- il y a "bt<tab>.b" au lieu de "bt.b<tab>" (et sinon bra serait plus joli que bt)


Par contre, pour:

- c'est un peu dommage de pas pouvoir distinguer addq/subq


Là, çà va être plus difficile sans toucher à l'UAE. Je préfère ne pas y toucher pour des raisons de maintenabilité et de debug...
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

15


fenêtre memory: scroll un peu lent


C grandement lié à la coloration sur changement de valeur. Il y a là, je pense, un choix à faire: coloration mais lent ou pas de coloration et rapide.

fenetre memory: pas de raccourcis clavier: Ajouter/Suprimer des onglets, et se déplacer d'onglet en onglet. Pour pouvoir naviguer sans toucher à la souris quoi.


Pas tout à fait exact: l'ajout/supression d'onglet se fait déjà par +/-.

J'ai mis en place les shortcuts suivants: F1 à F6 est équivalent aux 6 boutons de la barre d'outil, F7/F8 = move backward/forward into tabs.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

16

roms (./15) :
C grandement lié à la coloration sur changement de valeur. Il y a là, je pense, un choix à faire: coloration mais lent ou pas de coloration et rapide.

Sinon tu mets un timer avec détection de l'arret de scroll non? C'est pas très élégant mais bon. On fait ca en javascript pour les mousemove qui doivent gérer des affichages concernant beaucoup de données en fonction de x et y. Ca soulage pas mal le truc.
Tout ce qui passe pas par le port 80, c'est de la triche.

17

18

F5 sur un breakpoint ne fait que relancer le debugger sans rien exécuter


Quelqu'un peut confirmer ? Chez moi, j'ai bien le comportement attendu.

Pour la touche ENTER sur ti89, c'est fait.

Par contre, qu'est ce que je fais pour la fenêtre stack ? Dois-je inverser l'ordre ?

Sinon, à regarder de plus près, je constate effectivement pas mal de différences entre le désassembleur UAE et celui de VTi. Je vois aussi pas mal d'inconsistences dans le désassembleur de l'UAE. Le problème, c'est qu'à force de mettre des rustines, je me demande si je devrais pas plutôt en réécrire un...
En fait, j'évite de toucher au déssasembleur de l'UAE directement, je reparse la sortie à la volée et fait les corrections nécessaires. Car le désassembleur de l'UAE est un composant à part qui peut être upgradé et ça m'évite donc de faire un backport des modifs.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

19


* il vaudrait mieux mettre la constante avant le registre, c'est mieux d'avoir lea ($42,a3),a3 pour voir du premier coup d'oeil que a3 et a3 c'est bien le même registre
* (a3,d0.l*1) : le *1 ne sert à rien, surtout sur 68000
* VTI utilise lea (-$c,a3),a3 au lieu de lea ($fff4,a3),a3, c'est plus lisible
* les conventions ne sont pas très cohérentes, un coup c'est [42a1], un coup c'est [$42a1], un coup c'est = $42a1)


Fait.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

20

Tant qu'on y est à parler du désassembleur de UAE, voilà mon feature request à moi: afficher du GNU as valide (comme c'est déjà fait par le désassembleur GDB dans TiEmu+GDB), notamment:
- $ -> 0x
- * -> .
- rajouter les % devant les noms de registres
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

21

22

Kevin Kofler (./20) :
Tant qu'on y est à parler du désassembleur de UAE, voilà mon feature request à moi: afficher du GNU as valide (comme c'est déjà fait par le désassembleur GDB dans TiEmu+GDB), notamment:
- $ -> 0x
- * -> .
- rajouter les % devant les noms de registres

Entre la lisibilité et le standard, personnellement mon choix serait vite fait smile

23

> $ -> 0x
> rajouter les % devant les noms de registres
Je suis pour, à condition de laisser à l'utilisateur le choix entre ces deux conventions, selon ce à quoi il est habitué.
Personnellement, je me vois mal utiliser la convention que tu proposes. Sans syntax highlighting qui met les "%" en une couleur peu visible et les registres en une couleur bien visible (ce que fait l'IDE), les "%" diminuent la lisibilité.
Comme d'autres, je suis surtout habitué à la représentation de VTI. Je n'ai utilisé TIEmu non-GDB qu'assez sporadiquement depuis qu'il est arrivé dans un état utilisable par tous les développeurs (été 2005) - parce que je n'ai pas fait grand chose depuis ce moment, tout simplement. TIEmu GDB, à l'époque, en était à ses balbutiements (lire: inutilisable) et je ne l'ai pas utilisé depuis.

avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

24

25

Lionel Debroux (./23) :
> $ -> 0x
> rajouter les % devant les noms de registres
Je suis pour, à condition de laisser à l'utilisateur le choix entre ces deux conventions, selon ce à quoi il est habitué.
Personnellement, je me vois mal utiliser la convention que tu proposes. Sans syntax highlighting qui met les "%" en une couleur peu visible et les registres en une couleur bien visible (ce que fait l'IDE), les "%" diminuent la lisibilité.
Comme d'autres, je suis surtout habitué à la représentation de VTI. Je n'ai utilisé TIEmu non-GDB qu'assez sporadiquement depuis qu'il est arrivé dans un état utilisable par tous les développeurs (été 2005) - parce que je n'ai pas fait grand chose depuis ce moment, tout simplement. TIEmu GDB, à l'époque, en était à ses balbutiements (lire: inutilisable) et je ne l'ai pas utilisé depuis.


Personnellement, je ne me suis jamais fait à l'assembleur GNU que je trouve pas très lisible. Actuellement, mon objectif est de modifier le désassembleur de l'UAE pour qu'il ressemble au plus près à la syntaxe Motorola, celle utilisée par 95% des logiciels Motorola.

C'est ce qui manque, les options. grin Tout doit être configuré pareil pour tout le monde malheureusement, et les consensus ne sont pas faciles à trouver entre les fanas de ci et les habitués de ça...

Ma politique est d'implémenter le comportement qui satisfasse la majorité d'utilisateur. Dans l'hypothèse où une position est moins tranchée alors je code une option qui laisse le choix. Mais je préfère éviter les options car il faut les maintenir et les tester...

Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

26


impossible de savoir si l'instruction sélectionnée est l'instruction courante


Pourtant, la surbrillance est en bleu et l'instruction sélectionnée est en vert. Quelque chose m'échappe ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

27

28

Martial Demolins (./27) :
quand on sélectionne l'instruction courante, elle devient bleu, on voit plus de vert. quand on scroll, on reste en bleu, et l'instruction courante n'est plus sur la page. Donc on ne peut pas savoir si l'instruction courante est celle sélectionnée ou si elle est en-dehors de la page. smile


J'ai deux solutions:
- soit je met l'instruction courante en italique,
- soit je met dans la colonne de gauche (icone) une flèche colorée.

Que souhaitez-vous ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

29

30

Martial Demolins (./29) :
Tu vas faire quelque chose pour la taille des fontes des différentes fenêtres (pour que le débogueur tienne plus sur du A0) ? grin


Oui, c'est la prochaine étape... Je vais ajouter la possibilité de sélectionner en option une fonte (fonte et taille) commune à toutes les fenêtres.
Ensuite, je compte étudier la possibilité de créer des fenêtres dockables qui pourraient être rassemblés en un unique tableau de bord, sur option.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"