Connexion avec TiEmu - Page 6

Dès que j'ai un peu de temps, je me pencherais sérieusement sur le problème...

Kevin Kofler (./148) :
C'est fait: http://svn.tilp.info/cgi-bin/viewcvs.cgi?rev=2596&root=tiemu&view=rev

ok merci j'essaie ça ce soir.

rom> Merci pour le gfm, mais est-ce qu'il est possible de télécharger les sources sans passer par SVN ?

J'étais pas trop libre ces jours-ci, mais je préfère également la nouvelle fenêtre registres

Il y aura un RPM quand ça sera sorti officiellement.

Les specfiles sont dans le SVN et a priori devraient compiler, rien ne t'empêche de compiler tes propres RPMs.

Les touches non alphabétiques, vous vous en servez pour quoi au juste ? il n'y a pas une possibilité de prendre en compte toutes les touches potentiellement alphabétiques ? (ça n'en fait qu'une de plus)
(27 touches : de <AD01> à <AD10>, de <AC01> à <AC10> et de <AB01> à <AB07>)

Les touches non-alphabétiques sont mappées aux touches des calculatrices, par exemple MODE, HOME etc.

Et on ne peut pas mapper les touches n'importe comment non plus, parce que les layouts sont censés être compatibles VTI. (En même temps, ça fait aussi une manière simple de régler le problème du 'M', on regarde ce que fait VTI et on essaie de faire la même chose. )

Twindruff (./152) :

Kevin Kofler (./148) :
C'est fait: http://svn.tilp.info/cgi-bin/viewcvs.cgi?rev=2596&root=tiemu&view=rev

ok merci j'essaie ça ce soir.

en fait c'est pas évident à compiler, je crois que je vais attendre la prochaine release

Kevin > ok tu ne peux pas faire n'importe quoi, mais de toute façon même si tu gères indépendamment du layout tout sauf les lettres alphabétiques tu auras des petites différences pour l'utilisateur puisque notamment sur le clavier US la disposition des touches est différente des claviers européens (en fait tu as la touche <BKSL> qui est sur la rangée du milieu en Europe et sur la rangée du haut aux USA). Du coup les nombres de touches non-alphabétiques par ligne sur la droite du clavier principal sont les suivants : 3/2/3 sur le clavier US, 2/2/4 sur le clavier français, 2/3/3 sur les autres claviers européens.

Si on appelle A à H les fonctions disponibles via ces touches, ça peut donner le résultat suivant :

...[A][B][C] vs ...[A][B]... vs ...[A][B]...
...[D][E]...    ......[E][C]    ...[D][E][C]
...[F][G][H]    [D][F][G][H]    ...[F][G][H]

L'idée que j'avais était que, peut-être, vous n'aviez besoin que de 7 fonctions et il était possible de ne pas utiliser [D] ^^
Sinon effectivement il faudrait je suppose que dans le cas des touches <AC10> et <AB07> tu interroges XKB pour savoir si la touche correspond à un M (resp. à une virgule) pour savoir si tu prends le caractère ou la fonction [D]

Martial Demolins (./163) :
Autre chose, les parenthèses ne sont pas au même endroit pour TiEmu et VTI.

chez moi si

Au fait, il y a 2 autres layouts bizarres*: le Dvorak et le layout "traditionnel" turc (je ne sais pas combien il est encore utilisé, vu qu'il y a aussi un QWERTY turc).
http://en.wikipedia.org/wiki/Keyboard_layout

* Pour moi, un layout n'est pas "bizarre" s'il a une lettre (sans diacritiques) partout où le QWERTY a une lettre et l'inverse.

Twindruff (./164) :

Martial Demolins (./163) :
Autre chose, les parenthèses ne sont pas au même endroit pour TiEmu et VTI.

chez moi si

Sous Window$, elles sont au même endroit, pas sous X11. Je compte corriger ça aussi.
Elles sont une ligne trop bas, c'est ça? Parce que si elles ne sont pas au même endroit selon le layout, ça ne va pas être gagné pour corriger ça.

Euh...

Sur un clavier QWERTZ, elles sont là sur VTI et TiEmu sous Window$:
1234567890ß´
QWERTZUIOPÜ+
et là sur TiEmu sous X11:
1234567890ß´
QWERTZUIOPÜ+

Une demande, serait-il possible d'implémenter des breakpoints sur des bits (quand on utilise des bits comme flags, en asm c'est tout de même fréquent, au moins pour moi) ?

Oui, c'est en cours...

C'est fait! Donc, possibilité de déclencher un break chaque fois que un ou plusieurs bits sont dans l'état voulu lors d'une écriture.

tiemu est combien de fois plus lent avec cette nouvelle feature ?

J'imagine qu'il n'est plus lent que quand la feature est activée

Concernant la lenteur du debugger, j'ai fait un peu de profiling durant mes vacances sur la côte. Et quelques optimisations:
- la première ouverture des fenetres prenait 1016 ms; c'est passé à 406 ms soit -60%
- j'ai gratté ~230 ms à chaque refresh des fenêtres. Ca n'en prend plus que 30 ms.
- la fenetre code consomme 15 ms pour se rafraichir
- la fenetre memory consomme 15ms aussi
- etonnament, la fenetre register en consomme 30ms. Sans coloration rouge sur changement de valeur, elle n'en prend meme pas 15ms.

Si on ne conserve affichée que la fenetre code et registers, j'arrive à avoir un déplacement du curseur en temps réel (step over, touche F8 maintenue enfoncée), c-à-d que le rafraichissement a lieu suffisamment vite pour se terminer avant la prochaine répétition de touche.

Question: quelles sont les fenêtres que vous voulez voir ouvertes par défaut ? Toutes, aucunes ?

Ton profiling, c'était sur la version sans GDB, n'est-ce pas? Je suppose que dans la version avec GDB, Insight/GDB prend une partie non-négligeable du temps aussi.

D'ailleurs, pour les fenêtres ouvertes par défaut, la question s'applique aussi aux fenêtres Insight. La version officielle d'Insight n'affiche que le Source Window par défaut. J'ai rajouté la console GDB, mais ce n'est peut-être pas si utile que ça (personnellement, je connais bien les commandes GDB essentielles, donc la fenêtre m'est utile, mais pour les autres?). Je me demande donc si je devrais cacher la console GDB par défaut comme le fait Insight à la base, ça contribuerait aussi à réduire un peu le bordel des fenêtres.

L'époque où j'avais décidé de l'afficher par défaut, c'était l'époque où le débogueur bas-niveau affichait toutes les fenêtres par défaut, donc c'était bizarre de n'avoir qu'une seule fenêtre Insight. Mais maintenant la tendance est de n'afficher que l'essentiel par défaut, ce qui est AMHA une bonne idée.

(Désolé, j'ai toujours pas répondu à tes mails, Romain...)
L'accélération des ouvertures et rafraîchissements de fenêtres est une excellente chose
Avec TIEmu, je préfère moi aussi n'avoir que les fenêtres essentielles ouvertes par défaut.

Pourrais-tu définir "les fenêtres essentielles" s'il te plaît? L'objectif de nos questions était de savoir quelles fenêtres vous retenez "essentielles".

J'ai gardé ta terminologie "essentiel", mais du coup, j'ai répondu à côté de la question. Vive moi
Le triplet Debugger, Memory, Registers me convient.

1. Ce que tu appelles "Debugger" est la fenêtre "Disassembly".
2. C'est impossible de n'afficher que ça dans la version avec GDB, au moins le Source Window de Insight est non-négociable (parce que 1. c'est AMHA essentiel, 2. ça contrôle toutes les autres fenêtres Insight et 3. Insight s'attend à ce que cette fenêtre soit toujours ouverte, déjà cacher ça quand on ne débogue pas est un hack).