Posté le 17/11/2007 à 19:00 Membre depuis le 17/06/2001, 421 messages
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.
Posté le 17/11/2007 à 19:21 Membre depuis le 23/01/2004, 12372 messages
Raaaaaaaaaaaaaah love Le pied !!! top
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 18/11/2007 à 06:04 Membre depuis le 10/06/2001, 40283 messages
Il y a plusieurs erreurs dans les améliorations du désassembleur:

* Le correctif pour MOVEQ (rev 2666) n'est pas bon. Justement, un move #n peut être autre chose qu'un moveq, c'est pour ça qu'on te demande de distinguer! Il faut faire ça à l'intérieur du désassembleur.
* Je ne suis pas sûr pour les *I (rev 2667) non plus. Un add #imm est-il toujours un addi?
* rev 2668: là, tu as changé par exemple st en sra, ça ne va pas, il faut faire un cas particulier pour bt. Changer dbt en dbra n'est pas correct non plus, parce que dbra veut dire dbf.

Je suis aussi contre ton copier-coller du désassembleur de UAE. Commençons par dire que j'ai fait beaucoup de merges, y compris pas mal de merges de UAE dans TiEmu, donc je sais de quoi je parle. Le copier-coller est à peu près la pire des méthodes en ce qui concerne les merges! Ça veut dire effectivement que ce code n'est plus mergeable, et donc qu'on ne profite pas des nouveautés de UAE, de plus, si une interface interne de UAE change, il faudra porter le désassembleur à la main. Donc je préfèrerais que tu revertes le copier-coller de la révision 2672 et que tu fasses tes modifications à l'intérieur des sources de UAE. Quelques règles pour faciliter les merges (qui m'ont bien servi sur mes projets qui ont de nombreux patches, notamment le GCC de TIGCC):
* ne pas faire des modifications qui ne changent rien au fonctionnement, en particulier:
- ne pas toucher à l'indentation (et autre formatage)! D'ailleurs, ne pas toucher à l'indentation même si on rajoute ou supprime des niveaux de profondeur (par exemple un if de plus ou de moins), il vaut mieux un bloc mal indenté que des diffs inutiles sur chaque ligne.
- ne pas rajouter/supprimer/corriger des commentaires
- ne pas faire des "nettoyages" dans le code qui n'est pas à toi, il vaut mieux du code sale que des diffs inutiles
* si on veut supprimer de grosses parties du code, utiliser des #if 0 plutôt que d'effacer de gros blocs qui risquent de changer dans l'un ou l'autre détail et donc de casser le merge (en revanche, pour quelques lignes, supprimer est mieux)
Avec ton copier-coller, tu es parti pour faire exactement le contraire (adapter l'indentation à ton système, faire des nettoyages, ...), et donc on ne pourra plus merger, donc je suis absolument contre.

D'ailleurs, j'ai fait pas mal de modifications sur le désassembleur de GDB aussi, je les ai bien faites à l'intérieur des sources de GDB!
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 18/11/2007 à 06:19 Membre depuis le 10/06/2001, 40283 messages
D'ailleurs, au lieu de bidouiller à fond le désassembleur de UAE comme tu es en train de le faire là, ne serait-il pas mieux de faire marcher le désassembleur de GDB/libopcodes sans le reste de GDB pour la version sans GDB, donc d'utiliser le même désassembleur partout? Si tu regardes dasm-tigcc, j'y ai réussi à peu près, mais il faudrait adapter ça à TiEmu (le but de l'exercice étant de faire ça sans avoir une deuxième copie du code de désassemblage de GDB, pour les raisons décrites dans le message précédent).
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 18/11/2007 à 07:50 Membre depuis le 17/06/2001, 421 messages
Kevin Kofler (./32) :
Il y a plusieurs erreurs dans les améliorations du désassembleur:

* Le correctif pour MOVEQ (rev 2666) n'est pas bon. Justement, un move #n peut être autre chose qu'un moveq, c'est pour ça qu'on te demande de distinguer! Il faut faire ça à l'intérieur du désassembleur.
* Je ne suis pas sûr pour les *I (rev 2667) non plus. Un add #imm est-il toujours un addi?
* rev 2668: là, tu as changé par exemple st en sra, ça ne va pas, il faut faire un cas particulier pour bt. Changer dbt en dbra n'est pas correct non plus, parce que dbra veut dire dbf.

Je suis aussi contre ton copier-coller du désassembleur de UAE. Commençons par dire que j'ai fait beaucoup de merges, y compris pas mal de merges de UAE dans TiEmu, donc je sais de quoi je parle. Le copier-coller est à peu près la pire des méthodes en ce qui concerne les merges! Ça veut dire effectivement que ce code n'est plus mergeable, et donc qu'on ne profite pas des nouveautés de UAE, de plus, si une interface interne de UAE change, il faudra porter le désassembleur à la main. Donc je préfèrerais que tu revertes le copier-coller de la révision 2672 et que tu fasses tes modifications à l'intérieur des sources de UAE. Quelques règles pour faciliter les merges (qui m'ont bien servi sur mes projets qui ont de nombreux patches, notamment le GCC de TIGCC):
* ne pas faire des modifications qui ne changent rien au fonctionnement, en particulier:
- ne pas toucher à l'indentation (et autre formatage)! D'ailleurs, ne pas toucher à l'indentation même si on rajoute ou supprime des niveaux de profondeur (par exemple un if de plus ou de moins), il vaut mieux un bloc mal indenté que des diffs inutiles sur chaque ligne.
- ne pas rajouter/supprimer/corriger des commentaires
- ne pas faire des "nettoyages" dans le code qui n'est pas à toi, il vaut mieux du code sale que des diffs inutiles
* si on veut supprimer de grosses parties du code, utiliser des #if 0 plutôt que d'effacer de gros blocs qui risquent de changer dans l'un ou l'autre détail et donc de casser le merge (en revanche, pour quelques lignes, supprimer est mieux)
Avec ton copier-coller, tu es parti pour faire exactement le contraire (adapter l'indentation à ton système, faire des nettoyages, ...), et donc on ne pourra plus merger, donc je suis absolument contre.

D'ailleurs, j'ai fait pas mal de modifications sur le désassembleur de GDB aussi, je les ai bien faites à l'intérieur des sources de GDB!


J'ai fait un copier/coller pensant que çà _te_ simplifierait le merge. Si tu penses qu'il vaut mieux modifier in-place alors pas de problème pour moi, je préfères cette solution qui 1) évite la duplication du code 2) me permet réellement de fixer le désassembleur (en particulier les addq/subq qui ne peuvent être fixés qu'en modifiant le fichier table68k et le générateur de CPU).

D'ailleurs, au lieu de bidouiller à fond le désassembleur de UAE comme tu es en train de le faire là, ne serait-il pas mieux de faire marcher le désassembleur de GDB/libopcodes sans le reste de GDB pour la version sans GDB, donc d'utiliser le même désassembleur partout? Si tu regardes dasm-tigcc, j'y ai réussi à peu près, mais il faudrait adapter ça à TiEmu (le but de l'exercice étant de faire ça sans avoir une deuxième copie du code de désassemblage de GDB, pour les raisons décrites dans le message précédent).


Le même désassembleur partout ? Celui qui utilise la syntaxe GDB ? Si c'est le cas, ce n'est pas ce qu'on me demande (syntaxe Motorola)...
Je vais quand même regarder dasm-tigcc.
Posté le 18/11/2007 à 08:41 Membre depuis le 10/06/2001, 40283 messages
roms (./34) :
J'ai fait un copier/coller pensant que çà _te_ simplifierait le merge.

Je ne t'en veux pas. smile Mais ça ne fait que compliquer les choses en réalité, donc il vaut mieux ne pas faire ça.
Si tu penses qu'il vaut mieux modifier in-place alors pas de problème pour moi, je préfères cette solution qui 1) évite la duplication du code 2) me permet réellement de fixer le désassembleur (en particulier les addq/subq qui ne peuvent être fixés qu'en modifiant le fichier table68k et le générateur de CPU).

Oui, c'est mieux de modifier in-place, et vas-y pour les modifications à table68k et newcpu. En revanche, il faudra bien tester ça, pour ne pas casser l'émulateur en améliorant le désassembleur. wink
Le même désassembleur partout ? Celui qui utilise la syntaxe GDB ? Si c'est le cas, ce n'est pas ce qu'on me demande (syntaxe Motorola)...

Il est déjà patché pour sortir une sortie en la syntaxe Motorola de GNU as, à la base, il sort de la syntaxe MIT (sick). Je pourrais le modifier pour sortir le format VTI aussi, mais je n'ai pas envie de le faire, je veux une sortie consistente avec les outils de TIGCC. Mais je ne serais pas opposé à une option ("VTI format", "GNU as format").
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 18/11/2007 à 09:08 Membre depuis le 17/06/2001, 421 messages

Oui, c'est mieux de modifier in-place, et vas-y pour les modifications à table68k et newcpu. En revanche, il faudra bien tester ça, pour ne pas casser l'émulateur en améliorant le désassembleur. wink


J'avais déjà modifié ces fichiers et c'est sans pitié: lorsque les modifications sont incomplètes => le générateur et l'émulateur plante!

Il est déjà patché pour sortir une sortie en la syntaxe Motorola de GNU as. A la base, il sort de la syntaxe MIT. Je pourrais le modifier pour sortir le format VTI aussi, mais je n'ai pas envie de le faire, je veux une sortie consistente avec les outils de TIGCC. Mais je ne serais pas opposé à une option ("VTI format", "GNU as format").

J'ai regardé dasm-tigcc... Je pense qu'il me sera plus facile et plus rapide de modifier dasm-uae dans un premier temps mais je suis intéressé par 1) l'idée d'avoir un désassembleur à option 2) un code de désassembleur commun. Donc, je me tâte...
Posté le 19/11/2007 à 21:58 Membre depuis le 17/06/2001, 421 messages
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


C'est fait:
- possibilité de choisir entre la font par défaut ou une font personnalisé (qui par défaut, est celle qui était utilisée dans la fenêtre register). Tout peut être paramétré: police, style et taille,
- utilisation de la même police dans toutes les fenêtres sauf la fenêtre bkpt. J'estime que çà n'avait pas d'utilité car çà allongeait le texte donc c'était moins lisible.
Posté le 19/11/2007 à 21:59 Membre depuis le 23/01/2004, 12372 messages
ouéééééééééééééééééééééééééééé tu pooooooooooooootr !!!!!! love top boing bisoo
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 20/11/2007 à 09:01 Membre depuis le 17/06/2001, 421 messages
Martial Demolins (./38) :
tu pooooooooooooootr !!!!!!

Je sais pas ce que tu as voulu dire mais les smileys sont plus convaincants ;-) J'espère qu'il y a pas trop d'étrangers sur le forum parce que les pauvres, je les plains !

Sinon, j'ai commencé à modifier l'UAE: j'ai fixé la plupart instructions incorrectes (ori/andi/eori, add/subi/cmpi, move/addq/subq). Je suis en train de comparer avec le m68k manual pour voir si il y en d'autres...

Dès que j'ai terminé, je mettrais à disposition une pre-release pour que tout un chacun puisse me dire 1) si les modifications faites correspondent aux modifs attendues 2) si d'autres modifs doivent être faites.
Posté le 20/11/2007 à 17:33 Membre depuis le 10/06/2001, 40283 messages
roms (./39) :
J'espère qu'il y a pas trop d'étrangers sur le forum parce que les pauvres, je les plains !

Bah, je suis "étranger" et j'ai compris ce qu'il voulait dire. wink ("Tu poutres", c'est-à-dire "you rule".) Cela dit, c'est vrai que ce genre de slang n'est pas toujours évident à comprendre. sad
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 21/11/2007 à 00:06 Membre depuis le 23/01/2004, 12372 messages
Romain : Je trouve ça super, même si tu n'implémentes pas souvent d'options, que tu aies fait la fonte paramétrable, autant Kevin que moi vont y trouver leur bonheur! top
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 21/11/2007 à 13:38 Membre depuis le 17/06/2001, 421 messages
Voilà ce qui est fait (au passage, j'ai fixé: addi/subi/cmpi et andi/ori/eori):
roms (./1) :
- c'est un peu dommage de pas pouvoir distinguer move.l de moveq, idem pour addq/subq
- 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
- il y a "bt<tab>.b" au lieu de "bt.b<tab>" (et sinon bra serait plus joli que bt smile )


Ce qui va être fait (effectivement, çà sucks grave):

- movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI


J'ai construit une release dispo sur http://www.lievin.net/downloads/lpg/tiemu3nogdb.zip. Je vous encourage à la tester pour vérifier que vos demandes ont été prises en compte correctement. Si d'autres modifs doivent être fait, c'est le moment car après je m'attaque au dock. Il faut comprendre que je ne me sers pas de TiEmu très souvent donc je vois pas forcément les défauts d'une utilisation quotidienne. N'hésitez pas à "bug-reporter"...

Sinon, je pensais rajouter dans le menu de la fenetre source/code un item "Go to vector" permettant de choisir un vecteur à désassembler directement. Utile / Inutile ?
Posté le 21/11/2007 à 13:54 Membre depuis le 10/06/2001, 40283 messages
roms (./42) :
Ce qui va être fait (effectivement, çà sucks grave):

- movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI

TiEmu+GDB affiche ça correctement pratiquement depuis son existence, comme pour pratiquement toutes les autres demandes d'amélioration de l'assembleur d'ailleurs. Je ne comprends pas pourquoi vous utilisez la version sans GDB si vous déboguez!
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 21/11/2007 à 15:05 Membre depuis le 28/10/2001, 7625 messages
Oh, un troll...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 21/11/2007 à 18:58 Membre depuis le 17/06/2001, 421 messages
Je ne comprends pas pourquoi vous utilisez la version sans GDB si vous déboguez!


Peut-être que tu devrais te poser la question du "Pourquoi" ? Problème d'ergonomie, d'habitudes, ...? Je n'en ai aucune idée.

J'imagine qu'un certain nombre de personnes se contentent de la version sans GDB car elle suffit à leur besoin. D'autres préfèreront des outils plus sophistiqués et utiliseront alors la version GDB.
Je pense que ces deux outils ont leur place car ils peuvent correspondent chacun à des besoins/usages différents. L'important, pour ma part, est que l'utilisateur ait le choix.

Qu'en pense les gens ici ?
Posté le 21/11/2007 à 20:16 Membre depuis le 23/01/2004, 12372 messages
J'en pense que je suis entièrement d'accord avec toi!

J'ai reporté un bug à Kevin sur irc :
Sur un "bra ." ("bra *" en syntaxe Motorola), les interruptions s'arrêtent. Par exemple, l'écran repasse en noir et blanc. Kevin m'a répondu que c'était le "bra ." mon bug, vu qu'il faut que j'utilise les breakpoints (mais sans GDB, buggué à l'époque avec les programmes kernel) ^^
Autre chose, VTI propose une option "ignore auto-interrupts", qui éxécute les auto-ints, mais ne les fait pas tracer par le débogueur quand on débogue. Kevin m'a dit un truc qui revenait à "tant pis". Mais quand on se retrouve dans une int de gris HW2 ou une int clavier AMS, c'est la galère...

Tout le monde a toujours demandé que l'ergonomie soit revue au niveau des fenêtres : VTI tiens dans un mouchoir de poche, TiEmu ne tient pas sur mon écran en 1280*1024...
Enfin tu viens de le faire, mais Kevin n'a jamais voulu en entendre parlé. Pour la commodité, il m'est arrivé de déboguer avec VTI sous Wine...

Parce que quand les demandes sont toujours rejetées sous un prétexte quelconque, surtout quand toutes les demandes vont dans le même sens, il ne faut pas s'étonner de voir les gens rester sur un débogueur "obsolète et non-libre".

(tiens au passage tu pourras prendre en compte le feature request et le bug cheeky grin)

Je suis certain que les quelques options paramétrables que tu as rajoutées vont permettre d'augmenter la communauté des utilisateurs parce que chacun pourra trouver chaussure à son pied. smile

Merci en tout cas opru tout le boulot que tu viens de réaliser, on a attendu mais c'est suepr! top
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 22/11/2007 à 08:31 Membre depuis le 28/10/2001, 7625 messages
> Merci en tout cas opru tout le boulot que tu viens de réaliser, on a attendu mais c'est suepr!
Tu étais pressé, Martial, ou bien tu as bu ? grin
(J'écris ça parce que ça arrive à tout le monde de faire des fautes de frappe, mais 3 permutations dans la même phrase, c'est inhabituellement élevé ^^)

A part ça, +1, même si je ne me souviens pas d'avoir utilisé VTI depuis que je tourne (GNU/)Linux la plupart du temps (en particulier, jamais sous Wine).
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 22/11/2007 à 12:46 Membre depuis le 10/06/2001, 40283 messages
Écoute, j'ai bien dit que si les interruptions ne s'exécutent effectivement pas sur un bra ., c'est un bogue, cela dit ce n'est pas très important à corriger comme bogue. cheeky J'ai énormément de trucs à faire déjà! Ne penses-tu pas que je devrais plutôt utiliser mon temps sur les bogues critiques comme les infos de débogage relogées à la mauvaise adresse pour les programmes kernel?

Pour les interruptions, si on ne les saute pas, on se fait taper dessus par toi, si on les saute, on se fait taper dessus par ceux qui mettent tout leur code dans les gestionnaires d'interruption (ils se reconnaîtront), donc on ne peut pas gagner. Actuellement, on les saute pour le débogage niveau C et on les exécute pour le débogage niveau assembleur, je ne vois pas trop comment faire mieux.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 22/11/2007 à 14:16 Membre depuis le 28/10/2001, 7625 messages
> Actuellement, on les saute pour le débogage niveau C et on les exécute pour le débogage niveau assembleur, je ne vois pas trop comment faire mieux.
Si, en donnant le choix à l'utilisateur grin

Je ne dis pas que c'est trivial à coder, ni que c'est la première chose à faire avant tout le reste. En revanche, je dis que quand il y a deux habitudes incompatibles, si le but est que tout le monde soit content - cela comprend en particulier le fait qu'aucun utilisateur ne change sa façon de coder - il faut supporter les deux habitudes...
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Posté le 22/11/2007 à 21:44 Membre depuis le 17/06/2001, 421 messages
J'ai corrigé de problème:

movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI


Je m'occuperais des fenêtres dockables la semaine prochaine pour cause de boulot. Ca laisse le temps à tout un chacun de tester TiEmu; je vais mettre à jour le tarball précédent dans les minutes qui suivent...
Posté le 22/11/2007 à 22:11 Membre depuis le 23/01/2004, 12372 messages
Kevin Kofler (./48) :
J'ai énormément de trucs à faire déjà! Ne penses-tu pas que je devrais plutôt utiliser mon temps sur les bogues critiques comme les infos de débogage relogées à la mauvaise adresse pour les programmes kernel?

Ah mais là, je te crayonne totalement Kevin, ce n'est pas une priorité en effet cheeky
Kevin Kofler (./48) :
Pour les interruptions, si on ne les saute pas, on se fait taper dessus par toi, si on les saute, on se fait taper dessus par ceux qui mettent tout leur code dans les gestionnaires d'interruption (ils se reconnaîtront), donc on ne peut pas gagner. Actuellement, on les saute pour le débogage niveau C et on les exécute pour le débogage niveau assembleur, je ne vois pas trop comment faire mieux.

VTI propose une simple case à cocher. Il est vrai que je ne me rends pas compte de ce que ça engendre comme code au niveau de TiEmu. Mais s'il est déjà capable de gérer les deux possibilités suivant le langage débogué, la majorité du code permettant de le faire est déjà en place, non?
Lionel Debroux (./47) :
Tu étais pressé, Martial, ou bien tu as bu ?

Ca me fait ça depuis que j'ai remplacé mon clavier, ça me le faisait beaucoup moins avant (j'en ai été étonné d'ailleurs), j'essarai de mieux relire, désolé grin
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 23/11/2007 à 21:56 Membre depuis le 10/06/2001, 40283 messages
Martial Demolins (./51) :
VTI propose une simple case à cocher. Il est vrai que je ne me rends pas compte de ce que ça engendre comme code au niveau de TiEmu. Mais s'il est déjà capable de gérer les deux possibilités suivant le langage débogué, la majorité du code permettant de le faire est déjà en place, non?

Pas tout à fait, vu que le débogage dans GDB est à un niveau plus haut que celui dans la fenêtre Disassembly ou même le "Step/Next ASM Insn" dans GDB/Insight.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 28/11/2007 à 21:30 Membre depuis le 17/06/2001, 421 messages
Je n'ai pas encore eu le temps de m'occupper du dock, je suis actuellement un peu débordé... Et çà risque d'être encore décalé car j'ai reçu un mail de Debian me demandant si je souhaites continuer le packaging de tilp/tiemu à la place de Julien. A défaut, ces packages disparaîtront.

En attendant, vous pouvez toujours me faire part de vos remarques (attendues) concernant la pre-release faite sur le forum.

Posté le 28/11/2007 à 21:45 Membre depuis le 23/01/2004, 12372 messages
Kevin, tu me fais un rpm pour que je puisse tester? cheeky
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 29/11/2007 à 18:06 Membre depuis le 10/06/2001, 40283 messages
Alors déjà, il faut d'abord que je corrige le bogue que ça plante dès que tu le lances sous F8, sinon tu ne pourras tester rien du tout. grin
Et ensuite, désolé, mais ma priorité est d'avoir des RPMs pour CalcForge corrigeant ce bogue, donc la dernière release stable + backports de bugfixes seulement. Je ne nie pas que les modifications de Romain sont utiles, mais ils ont besoin de plus de tests avant de finir sur CalcForge.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 29/11/2007 à 20:27 Membre depuis le 17/06/2001, 421 messages
Kevin Kofler (./55) :
Je ne nie pas que les modifications de Romain sont utiles, mais ils ont besoin de plus de tests avant de finir sur CalcForge.

Tout à fait d'accord...
Posté le 30/11/2007 à 21:18 Membre depuis le 17/06/2001, 421 messages
J'ai décidé d'accepter la proposition de reprendre la maintenance des paquets Debian. Ces paquets n'étaient plus mis à jour depuis longtemps et ils étaient sur le point d'être supprimés.

Donc, je m'occuperais du dock plus tard (probablement courant décembre).
Posté le 30/11/2007 à 21:30 Membre depuis le 23/01/2004, 12372 messages
cry je le touchait presque des doigts grin
avatarMon journal de bord <flux rss manuel> asTI68k : WIP </flux>

Le modernisme ne diffère guère de la libre pensée absolue que par sa prétention de demeurer catholique.
Posté le 30/11/2007 à 23:31 Membre depuis le 10/06/2001, 40283 messages
roms (./57) :
J'ai décidé d'accepter la proposition de reprendre la maintenance des paquets Debian. Ces paquets n'étaient plus mis à jour depuis longtemps et ils étaient sur le point d'être supprimés.

Tu feras comment pour les mises à jour pour stable (parce qu'à l'intérieur de stable, c'est mort)? Tu passeras par backports.debian.org ou tu continueras sur CalcForge?
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 01/12/2007 à 18:53 Membre depuis le 17/06/2001, 421 messages
Je travaillerais sur 2 fronts:
- fourniture de paquets à la demande pour Debian qui seront sponsorisés par JB,
- fourniture régulière de paquets sur CalcForge, comme je le faisait avant.

Concernant CalcForge, j'envisage la création d'un repository sur mon serveur perso car il tourne sous Debian. Ce repository sera ensuite copié/synchronisé sur CalcForge.

Je suis actuellement en train de mettre à jour les scripts Debian (car mes paquets sont des paquets 'native' ce qui n'est pas correct) et de scripter le bouzin pour me faciliter la tâche.