Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » manuel en français de TIGC (31 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

naPO

Ecrit le: Mardi 13 septembre 2005 à 07:41

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 2430

Membre n°17

Inscrit le 01 février 2004

La documentation de TIGCC est entièrement le produit de notre équipe et de nos contributeurs

Arrête de parler comme si tu étais le leader de la TIGCC Team.

Tel un automate, le dinosaure noir s'avance vers le chef des toutous-bombes et dit : "SCHNAAA SCHNAAA SCHNAPPI ! SCHNAPPI-SCHNAPPI-SCHNAPP !!!!!!" (en attendant une meilleure signature)

Avec de vrais morceaux de pattes d'eph :

./Post n°20 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 13 septembre 2005 à 07:52

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

1. Je parle comme un membre de l'équipe.
2. C'est qui le leader, à ton avis? #roll#

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°21 Marquer comme non lu.

naPO

Ecrit le: Mardi 13 septembre 2005 à 11:58

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 2430

Membre n°17

Inscrit le 01 février 2004

1. On dirait pas
2. Sebastian Reichelt.

Note aux autres : je pète la forme !

Tel un automate, le dinosaure noir s'avance vers le chef des toutous-bombes et dit : "SCHNAAA SCHNAAA SCHNAPPI ! SCHNAPPI-SCHNAPPI-SCHNAPP !!!!!!" (en attendant une meilleure signature)

Avec de vrais morceaux de pattes d'eph :

./Post n°22 Marquer comme non lu.
Sasume	Ecrit le: Mardi 13 septembre 2005 à 12:23
	-- Post locké --

./Post n°23 Marquer comme non lu.

LionelA

Ecrit le: Mardi 13 septembre 2005 à 13:02

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Bon ceci dit Kevin est le seul membre actif de tigcc team, c'est donc le leader, faut arreter de craquer et lui reconnaître ca.

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°24 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 13 septembre 2005 à 14:38

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

#23: en effet. C'est un fait et il faut faire avec, bien que ça ne fasse pas que des heureux dans la communauté. Par exemple:
si Sebastian était toujours actif, je pense que #2 serait moins vrai, puisque lui, il se bougeait en ce qui concerne la doc. Kevin, non, pas même pour son propre boulot (grays 3 plans - c'est chiant à faire, alors ça attendra), ou quand on lui donne une liste d'une quarantaine de fonctions simples, prêtes à intégrer, qui n'ont pas besoin de vérifications autres que les tournures anglaises...
Que ça l'embête de le faire, je comprends tout à fait. A ce moment-là, qu'il se fasse aider. Je connais très bien le système de la doc de TIGCC. Mais ce qui coince le plus pour moi, c'est le temps libre, puisque je suis encore étudiant. Que le boulot ait déjà été cassé plusieurs fois n'est pas motivant, mais ça moins de chances de se reproduire maintenant.

Kevin n'aime pas que je parle de ça - mais ça pénalise toute la communauté, et je ne me bats pas que pour moi !

Au passage, relevons le mépris contenu dans #17: "En particulier, une grande partie du travail provient de Zeljko Juric, un des 2 meilleurs programmeurs que la communauté TI a connus (l'autre étant Thomas Nussbaumer).". Même pas foutu de mentionner PpHd...

Lionel Debroux - membre de TICT.

./Post n°25 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 13 septembre 2005 à 15:56

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
si Sebastian était toujours actif, je pense que #2 serait moins vrai, puisque lui, il se bougeait en ce qui concerne la doc. Kevin, non,

<SARCASM>J'adore</SARCASM> ta manière de cracher sur mon travail alors que tu fous nettement moins que moi. Je m'occupe de TiEmu et de TIGCC, j'ai des projets TI aussi (mes TSRs, Backgammon etc.) et comme toi j'ai aussi des études à faire.

pas même pour son propre boulot (grays 3 plans - c'est chiant à faire, alors ça attendra),

Et ça dérange qui exactement? La routine de gris 3 plans est disponible sur mon site et sur le forum de TIGCC, tout ceux qui en ont besoin peuvent déjà l'utiliser. Alors la doc qui est essentiellement un copier-coller-éditer de celle des routines de gris 2 plans (comme l'explique mon readme), je ne vois pas en quoi elle serait tellement importante qu'elle devrait passer devant des fonctionnalités vraiment utiles en cours de développement ou encore sur mon TODO (genre la gestion du SilverLink sous Linux dans TiEmu 3 pour laquelle je viens d'implémenter une routine indispensable qui fait que ça marche maintenant et pas avant, genre encore la gestion des 89u/9xu/v2u dans ld-tigcc qui est encore à faire, genre la compatibilité de mes TSRs avec les nouveaux AMS etc. etc. etc.).

ou quand on lui donne une liste d'une quarantaine de fonctions simples, prêtes à intégrer, qui n'ont pas besoin de vérifications autres que les tournures anglaises...

Mais elles ont besoin d'une heure de modifications des cross-references dans les 2 sens chacune, donc je compte une quarantaine d'heures de travail! Si elles étaient vraiment prêtes à intégrer, ce serait déjà fait. (Et non, je ne peux rien merger sans corriger les cross-references, il suffit d'une seule cross-reference pas à jour et la doc entière ne compile pas.)

De plus, tous tes address hacks nécessitent une vérification (tu as déjà soumis assez de code bogué, je ne prends plus de code de toi sans le relire voire tester), et il faut aussi rajouter AMS 1.00 là où c'est possible (version que, comme tu le sais très bien, tu as complètement ignorée).

Que ça l'embête de le faire, je comprends tout à fait. A ce moment-là, qu'il se fasse aider.

Par qui? Je ne peux pas te faire confiance pour vérifier tes propres patches et de plus tu n'as pas le temps. Bhuvanesh Bhatt n'a pas fait grand chose non plus, par manque de temps je suppose. Qui d'autre proposerais-tu (sachant qu'il faut une bonne maîtrise de l'anglais et de l'orthographe américaine, et une bonne maîtrise des TIs aussi)?

Kevin n'aime pas que je parle de ça - mais ça pénalise toute la communauté, et je ne me bats pas que pour moi !

Pénalise en quoi? Les fonctions sont pour la plupart déjà dans unknown.h, tout le monde peut les utiliser avec ou sans tes modifs. (Il n'y a pas de doc, du moins pas dans TIGCC, et alors? J'ai utilisé pas mal de fonctions de unknown.h dans Gosper89.)

Je signale aussi que j'ai fait un effort de merge des docs contribuées pour TIGCC 0.96 Beta 1, j'ai mergé toutes les contributions de Wazabbe et de Sébastien Leurent et les petites contributions, et aussi une partie des tiennes, il ne reste plus qu'une partie de tes contributions et mes gris à 3 plans qui sont déjà disponibles séparément.

Au passage, relevons le mépris contenu dans #17: "En particulier, une grande partie du travail provient de Zeljko Juric, un des 2 meilleurs programmeurs que la communauté TI a connus (l'autre étant Thomas Nussbaumer).". Même pas foutu de mentionner PpHd...

Je ne mets pas PpHd au même niveau que Thomas et Zeljko, désolé.
-Edité le Mardi 13 septembre 2005 à 15:59 par Kevin Kofler-
-Edité le Mardi 13 septembre 2005 à 16:01 par Kevin Kofler-

./Post n°26 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 13 septembre 2005 à 18:19

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> > si Sebastian était toujours actif, je pense que #2 serait moins vrai, puisque lui, il se bougeait en ce qui concerne la doc. Kevin, non,
> <SARCASM>J'adore</SARCASM> ta manière de cracher sur mon travail alors que tu fous nettement moins que moi. Je m'occupe de TiEmu et de TIGCC, j'ai des projets TI aussi (mes TSRs, Backgammon etc.) et comme toi j'ai aussi des études à faire.
Je ne sais pas si la remarque sur le fait que je ne foute rien est en général ou sur TIGCC, mais dans les deux cas, tu connais la réponse:
* en général: ma santé ne me permet pas de faire les mêmes horaires que toi. Tu as de la chance de pouvoir passer des nuits à bosser pour tes cours et TI...
* sur TIGCC: j'aime bien faire la doc, mais ça ne me motive pas quand (pseudo-syntaxe regex style grep): j'y passe des journées; (on la casse, j'y passe des heures pour mettre à jour){4,6}; on la casse. D'autre part, il y a au moins une contribution sur tprbuilder, une qui viendra sur le linker, un certain nombre de bug/pessimization reports.

> > ou quand on lui donne une liste d'une quarantaine de fonctions simples, prêtes à intégrer, qui n'ont pas besoin de vérifications autres que les tournures anglaises...
> Mais elles ont besoin d'une heure de modifications des cross-references dans les 2 sens chacune, donc je compte une quarantaine d'heures de travail!
Je pense que ce chiffre est exagéré: même la dernière fois, je n'y ai pas passé plus de 12h. Mais puisque c'est à refaire à chaque modification, il faut passer à des méthodes plus efficaces - et surtout, réutilisables... Le gros problème de cette cross-ref est l'existence de liens relatifs. Si tous les liens étaient absolus, le problème serait beaucoup plus simple à régler. C'est donc la première chose à faire. Ce n'est pas autrement que j'avais commencé à m'y prendre, en 2003 je crois...

> (Et non, je ne peux rien merger sans corriger les cross-references, il suffit d'une seule cross-reference pas à jour et la doc entière ne compile pas.)
Oh, je sais, j'ai beaucoup utilisé le système... Mais Sebastian et moi t'avons tous les deux dit de faire un bout de code pour updater les cross-references. C'était il y a un certain temps, et les choses ont changé depuis. En effet, comme je t'ai écrit récemment sur le forum de TIGCC/TICT, parce que je l'ai vu il y a peu avec RC_479/47A, la cross-ref est incomplète (manifestement rien pour les ROM_CALLs qu'AMS lui-même n'appelle pas, dont 479 "link_printf" - s'il était pris en compte, on le trouverait dans 47A et vcbprintf), et elle ne tient pas compte des AMS 3.xx (peut-être même les 2.07 - 2.09 ?).

A moyen terme, si tu veux avoir une cross-ref complète, il faudra donc que tu relances la génération de cette cross-ref ([References] In/Out), après avoir étendu un poil les outils de Sebastian (format supplémentaire BFD + programmes auxiliaires) pour prendre en compte les ROM_CALLs non appelés par AMS, et toujours générer des références absolues. A mon avis, tu perdras carrément du temps à la corriger: il vaut mieux la regénérer à chaque version d'AMS. Ca doit certes prendre un peu de temps, puisque le graphe a quelques miliers de sommets et énormément d'arcs. Mais si ça n'a pas changé, ton convertisseur CHM -> QT Assistant est également lent.

Attention aux ROM_CALLs supprimés dans des versions récentes d'AMS, qui pointent sur un ER_THROW_ROM_RESIDENT_ROUTINE_NOT_AVAILABLE (ou quelque chose comme ça): comme l'outil ne gère pas non plus les A_LINE comme des instructions __noreturn__, tu avais déjà dû corriger les OSV*Timer, et il faudra corriger les handshake et timers (je crois) d'AMS 2.07-2.09 supprimés sous les AMS 2.xx.

Evidemment, les cross-refs existent aussi dans les See Also - mais si tu supprimes le problème de la correction simultanée des [References] et des See Also=, ça simplifie, car il n'est pas nécessaire de parcourir le fichier en entier, et de tenir compte des sections (pas remplacer dans les sections [Description], dans les blocs de code entre pre, etc.).
L'architecture que j'avais commencé à faire pour faire des références absolues à partir des références relatives (puisqu'une fois qu'on a fait ça, le déplacement d'un fichier se fait par rechercher/remplacer dans fichiers) devrait toujours tenir. Maintenant, je la fais avec des scripts sh éventuellement et surtout des outils GNU, au lieu d'utiliser le tree de WinXP:
* génération d'une liste de fichiers .hsh, .hsf, en utilisant par exemple find . -iname *.hs? >files.txt
* reparser ce fichier pour éliminer ce qui est superflu (le ./ en début, notamment). sed ou Perl font ça très bien.
Le programme qui update les See Also prend la liste des fichiers, génère en interne les noms courts (liens relatifs), et ensuite lit chaque fichier à updater. Jusqu'à la ligne See Also=, il réécrit tel quel. Il change la ligne See Also= en remplaçant les adresses relatives par des adresses absolues. Il réécrit le reste tel quel.

J'ai peut-être oublié un truc, mais ça me paraît être la voie raisonnable, qui facilite énormément les problèmes d'update des cross-ref, et qui pare au futur - c'est bien celle-là dans laquelle on avait commencé à s'engager !

> De plus, tous tes address hacks nécessitent une vérification (tu as déjà soumis assez de code bogué, je ne prends plus de code de toi sans le relire voire tester), et il faut aussi rajouter AMS 1.00 là où c'est possible (version que, comme tu le sais très bien, tu as complètement ignorée).
Comme tu le sais très bien aussi, car je te l'ai dit au moins deux fois je crois, je ne dispose pas de cette version d'AMS. C'est donc la seule raison du fait que j'ai "ignoré" AMS 1.00 92+, puisque personne ne m'a jamais testé les hacks ou envoyé cette version !
Il est trivial de voir qu'un certain nombre de Value et Address Hacks ne sont pas faisables sous AMS 1.00 92+, pour cause d'absence des ROM_CALLs utilisés comme base du hack. A moins que - j'y pense à l'instant - tu fasses un hack triple AMS 1.00 92+ / AMS intermédiaires / AMS où le hack n'est pas nécessaire, ce qui aura pour effet principal d'alourdir le hack pour 0% des calculatrices, puisque cette version est dépassée depuis 1998 - ! - et que de nombreux programmes ne la supportent pas, à commencer par DoorsOS et autres). La compatibilité avec les vieux AMS, je suis pour, d'où les Address/Value Hacks, mais peut-être pas à n'importe quel prix, quand même !

> > Que ça l'embête de le faire, je comprends tout à fait. A ce moment-là, qu'il se fasse aider.
> Par qui ?
C'est bien ça le problème...
> Je ne peux pas te faire confiance pour vérifier tes propres patches
En effet, je l'ai d'ailleurs écrit à plusieurs reprises.
> et de plus tu n'as pas le temps.
Plutôt, oui.
> Bhuvanesh Bhatt n'a pas fait grand chose non plus, par manque de temps je suppose.
Probable.
> Qui d'autre proposerais-tu (sachant qu'il faut une bonne maîtrise de l'anglais et de l'orthographe américaine, et une bonne maîtrise des TIs aussi) ?
C'est pas compliqué: personne, puisque personne n'est à la fois (ayant suffisamment de temps), (pas juge et partie), (parlant et écrivant correctement l'anglais), (maîtrisant bien les TI-68k)...

> Je signale aussi que j'ai fait un effort de merge des docs contribuées pour TIGCC 0.96 Beta 1, j'ai mergé toutes les contributions de Wazabbe et de Sébastien Leurent et les petites contributions,
En effet. A noter que ces contributions, étant encore plus anciennes, n'avaient pas de cross-ref - donc, pas de problème, il suffisait de les ajouter. C'est maintenant que les problèmes commencent.
-Edité le Mardi 13 septembre 2005 à 18:20 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°27 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 13 septembre 2005 à 23:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
Je pense que ce chiffre est exagéré: même la dernière fois, je n'y ai pas passé plus de 12h. Mais puisque c'est à refaire à chaque modification, il faut passer à des méthodes plus efficaces - et surtout, réutilisables... Le gros problème de cette cross-ref est l'existence de liens relatifs. Si tous les liens étaient absolus, le problème serait beaucoup plus simple à régler. C'est donc la première chose à faire. Ce n'est pas autrement que j'avais commencé à m'y prendre, en 2003 je crois...

Ça ne résout rien comme problème, de mettre les liens en absolu. Il y a toujours à peu près le même nombre d'endroits à éditer.

La seule solution est d'éliminer complètement les noms de répertoire et de laisser le système d'aide chercher les fichiers lui-même. De plus, il faudrait un moyen de gérer facilement les changements de nom (ROM_CALL_nnn -> foo_bar_baz).

Oh, je sais, j'ai beaucoup utilisé le système... Mais Sebastian et moi t'avons tous les deux dit de faire un bout de code pour updater les cross-references. C'était il y a un certain temps, et les choses ont changé depuis. En effet, comme je t'ai écrit récemment sur le forum de TIGCC/TICT, parce que je l'ai vu il y a peu avec RC_479/47A, la cross-ref est incomplète (manifestement rien pour les ROM_CALLs qu'AMS lui-même n'appelle pas, dont 479 "link_printf" - s'il était pris en compte, on le trouverait dans 47A et vcbprintf), et elle ne tient pas compte des AMS 3.xx (peut-être même les 2.07 - 2.09 ?).

A moyen terme, si tu veux avoir une cross-ref complète, il faudra donc que tu relances la génération de cette cross-ref ([References] In/Out), après avoir étendu un poil les outils de Sebastian (format supplémentaire BFD + programmes auxiliaires) pour prendre en compte les ROM_CALLs non appelés par AMS, et toujours générer des références absolues. A mon avis, tu perdras carrément du temps à la corriger: il vaut mieux la regénérer à chaque version d'AMS. Ca doit certes prendre un peu de temps, puisque le graphe a quelques miliers de sommets et énormément d'arcs. Mais si ça n'a pas changé, ton convertisseur CHM -> QT Assistant est également lent.

On ne peut pas raisonnablement regénérer les cross-references, on perdrait les nombreuses modifications manuelles qui y ont été apportées.

Attention aux ROM_CALLs supprimés dans des versions récentes d'AMS, qui pointent sur un ER_THROW_ROM_RESIDENT_ROUTINE_NOT_AVAILABLE (ou quelque chose comme ça): comme l'outil ne gère pas non plus les A_LINE comme des instructions __noreturn__, tu avais déjà dû corriger les OSV*Timer, et il faudra corriger les handshake et timers (je crois) d'AMS 2.07-2.09 supprimés sous les AMS 2.xx.

Les ER_THROW, ce sera sans doûte mieux avec mes patches pour libopcodes dans TiEmu. Le problème est vraiment celui des éditions manuelles. (Quant aux fonctions qui n'existent plus, je ne vois pas pourquoi ils seraient dans les cross-refs, je ne vois pas pourquoi elles seraient documentées dans TIGCC, d'ailleurs.)

Evidemment, les cross-refs existent aussi dans les See Also - mais si tu supprimes le problème de la correction simultanée des [References] et des See Also=, ça simplifie,

Non, ça ne change pas grand chose au problème. Comme déjà dit, la seule solution est d'éliminer le nom du répertoire entièrement.

L'architecture que j'avais commencé à faire pour faire des références absolues à partir des références relatives (puisqu'une fois qu'on a fait ça, le déplacement d'un fichier se fait par rechercher/remplacer dans fichiers) devrait toujours tenir.

Oui, mais sans code, ton "architecture" ne me sert à rien. Si je code un tel outil, je trouve la bonne architecture moi-même. #roll#

Il est trivial de voir qu'un certain nombre de Value et Address Hacks ne sont pas faisables sous AMS 1.00 92+, pour cause d'absence des ROM_CALLs utilisés comme base du hack.

Et c'est pour ça qu'il faut que je vérifie pour chacun s'il marche ou pas. 5 heures de tests (soit en exécutant le truc, soit en le vérifiant manuellement au débogueur) minimum.

> Qui d'autre proposerais-tu (sachant qu'il faut une bonne maîtrise de l'anglais et de l'orthographe américaine, et une bonne maîtrise des TIs aussi) ?
C'est pas compliqué: personne, puisque personne n'est à la fois (ayant suffisamment de temps), (pas juge et partie), (parlant et écrivant correctement l'anglais), (maîtrisant bien les TI-68k)...

Alors arrête de suggérer de me faire aider, la suggestion est totalement inutile et stupide si tu n'as personne à proposer pour m'aider.

> Je signale aussi que j'ai fait un effort de merge des docs contribuées pour TIGCC 0.96 Beta 1, j'ai mergé toutes les contributions de Wazabbe et de Sébastien Leurent et les petites contributions,
En effet. A noter que ces contributions, étant encore plus anciennes, n'avaient pas de cross-ref - donc, pas de problème, il suffisait de les ajouter. C'est maintenant que les problèmes commencent.

C'est totalement faux. C'était pire, parce qu'il fallait en plus rajouter les cross-refs existants (depuis le hsf de unknown.h), et après les corriger. Parce que déplacer un fichier de unknown.h vers graphing.h ou autre, ça veut dire des tonnes de cross-refs (dans les 2 sens!) à corriger.

./Post n°28 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 14 septembre 2005 à 11:18

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> > Je pense que ce chiffre est exagéré: même la dernière fois, je n'y ai pas passé plus de 12h. Mais puisque c'est à refaire à chaque modification, il faut passer à des méthodes plus efficaces - et surtout, réutilisables... Le gros problème de cette cross-ref est l'existence de liens relatifs. Si tous les liens étaient absolus, le problème serait beaucoup plus simple à régler. C'est donc la première chose à faire. Ce n'est pas autrement que j'avais commencé à m'y prendre, en 2003 je crois...
> Ça ne résout rien comme problème, de mettre les liens en absolu. Il y a toujours à peu près le même nombre d'endroits à éditer.
Evidemment, mais les références absolues sont éditables par rechercher/remplacer multiple - il y a tout plein de softs au minimum gratuits pour ça...
En fait, je me suis planté hier, puisque quand on passe les références en absolu, il faut aussi corriger les <A HREF="$$LINK(fonction)">nom</A>, en mettant fonction comme lien absolu et nom sans chemin - mais détecter si on a affaire à cette construction ou pas est facile, n'est-ce pas ?
> La seule solution est d'éliminer complètement les noms de répertoire et de laisser le système d'aide chercher les fichiers lui-même.
Il faut alors gérer correctement les définitions multiples (alloca, top_estack, etc.), par exemple en prenant le premier header dans lequel est la fonction cherchée. Mais c'est moyen, car tu perds la possibilité d'utiliser rechercher/remplacer multiple.
> De plus, il faudrait un moyen de gérer facilement les changements de nom (ROM_CALL_nnn -> foo_bar_baz).
Ben, l'utilisation de références absolues permet de faire une grosse partie du boulot, en utilisant rechercher/remplacer multiple "unknown.h/ROM_CALL_nnn" -> "[fichier approprié.h]/foo_bar_baz", non ? Après ça, il reste à modifier la partie nom des <A HREF=...> mentionnés ci-dessus, ce qui doit là aussi pouvoir se faire par rechercher-remplacer multiple ">ROM_CALL_nnn</A>" -> ">foo_bar_baz</A>".
Note que pour ça, il faudrait déjà qu'ils y soient, ces fichiers... Et ils n'y sont pas tous, d'une part pour un petit manque des outils de Sebastian, d'autre part car les ROM_CALLs récents ne sont pas pris en compte...

> On ne peut pas raisonnablement regénérer les cross-references, on perdrait les nombreuses modifications manuelles qui y ont été apportées.
* Les See Also=, évidemment. Mais je ne parle pas de regénérer celles-là, juste de tout passer en références absolues !
* Les [References] In= Out=: y en a-t-il qui s'amusent à modifier à la main ce truc auto-généré, autrement bien sûr que pour faire les déplacements / renommages de fichiers (ce que j'ai fait comme toi, évidemment) ?

Si on était partis sur une autre architecture que celle que tu proposes, et que j'avais commencé à écrire du code (que maintenant je ferais différemment, en utilisant des langages de scripting là où c'est adapté, ce je ne savais pas faire auparavant) pour tout passer en références absolues, je pense qu'il y avait une bonne raison. Il faut que je retrouve la série de mails, mais ce devrait être assez facile, car je sais quoi, où et quand chercher.

> (Quant aux fonctions qui n'existent plus, je ne vois pas pourquoi ils seraient dans les cross-refs, je ne vois pas pourquoi elles seraient documentées dans TIGCC, d'ailleurs.)
Certes, mais cela implique de faire exprès de ne pas les prendre en compte dans la génération de la cross-reference - ce qui n'était pas le cas à l'époque où j'avais fait corriger OSV*Timer, la cross-ref de ces fonctions étant au moins partiellement due à la non-interprétation de la A-Line comme __noreturn__.

> > Il est trivial de voir qu'un certain nombre de Value et Address Hacks ne sont pas faisables sous AMS 1.00 92+, pour cause d'absence des ROM_CALLs utilisés comme base du hack.
> Et c'est pour ça qu'il faut que je vérifie pour chacun s'il marche ou pas.
Oui, mais uniquement pour ceux dont le ROM_CALL utilisé comme base du hack est de nombre <= 0x2AB, ce qui n'est pas le cas de tous...

Lionel Debroux - membre de TICT.

./Post n°29 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mercredi 14 septembre 2005 à 12:52

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
* Les [References] In= Out=: y en a-t-il qui s'amusent à modifier à la main ce truc auto-généré, autrement bien sûr que pour faire les déplacements / renommages de fichiers (ce que j'ai fait comme toi, évidemment) ?

Oui, Sebastian a fait des modifs manuelles au moment de la conversion, et j'en ai fait certaines aussi pour corriger des erreurs.

Si on était partis sur une autre architecture que celle que tu proposes, et que j'avais commencé à écrire du code (que maintenant je ferais différemment, en utilisant des langages de scripting là où c'est adapté, ce je ne savais pas faire auparavant) pour tout passer en références absolues, je pense qu'il y avait une bonne raison. Il faut que je retrouve la série de mails, mais ce devrait être assez facile, car je sais quoi, où et quand chercher.

Sebastian pense qu'il y a des soucis de vitesse s'il faut à chaque fois chercher les fichiers. Faudrait qu'on fasse ça en 2 passes (génération d'un index et utilisation de cet index), probablement.

> (Quant aux fonctions qui n'existent plus, je ne vois pas pourquoi ils seraient dans les cross-refs, je ne vois pas pourquoi elles seraient documentées dans TIGCC, d'ailleurs.)
Certes, mais cela implique de faire exprès de ne pas les prendre en compte dans la génération de la cross-reference - ce qui n'était pas le cas à l'époque où j'avais fait corriger OSV*Timer, la cross-ref de ces fonctions étant au moins partiellement due à la non-interprétation de la A-Line comme __noreturn__.

Les fonctions OSV*Timer n'apparaissent pas du tout dans les cross-references. N'oublie pas que TIGCCLIB utilise sa propre implémentation depuis qu'AMS les a supprimées et que celle-ci se base directement sur l'AI5.

./Post n°30 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 14 septembre 2005 à 15:05

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> > * Les [References] In= Out=: y en a-t-il qui s'amusent à modifier à la main ce truc auto-généré, autrement bien sûr que pour faire les déplacements / renommages de fichiers (ce que j'ai fait comme toi, évidemment) ?
> Oui, Sebastian a fait des modifs manuelles au moment de la conversion, et j'en ai fait certaines aussi pour corriger des erreurs.
Oui, forcément, à commencer par les OSV*Timer probablement, voir plus bas...
Avez-vous gardé une trace de ces modifs, qu'il faudra de toute façon refaire si vous supportez les ROM_CALLs plus récents que le callgraph ?

> Sebastian pense qu'il y a des soucis de vitesse s'il faut à chaque fois chercher les fichiers. Faudrait qu'on fasse ça en 2 passes (génération d'un index et utilisation de cet index), probablement.
En effet, et c'était prévu de faire en deux passes, cf #26, qui ne dit cependant pas explicitement qu'on génère l'index une seule fois, et que le programme de passage aux références absolues utilise cet index.

> Les fonctions OSV*Timer n'apparaissent pas du tout dans les cross-references.
Donc elles ont dû être enlevées, puisqu'elles y étaient (ou auraient dû y être, puisque les OSV*Timer contenaient des références Out, donc les fichiers correspondants à ces références auraient dû avoir OSV*Timer comme références In) - sinon, je n'aurais rien reporté dessus.
> N'oublie pas que TIGCCLIB utilise sa propre implémentation depuis qu'AMS les a supprimées et que celle-ci se base directement sur l'AI5.
Je sais. Comme vous avez faits des cross-references pour d'autres fonctions directement implémentées dans TIGCCLIB, comme les fonctions ANSI C de manipulation de fichiers:
(fopen)
Uses: HeapAlloc, HeapAllocPtr, HeapFreePtr, HeapSize, HLock, SaveScrState, RestoreScrState, strpbrk, DerefSym, SymAdd, SymDel, SymFind
Used by: freopen
(freopen)
Uses: fclose, fopen
il aurait été possible de le faire aussi pour les OSV*Timer (mais en fait, je viens de relire les routines, il n'y en a pas de références externes, ce qui règle la question).

Lionel Debroux - membre de TICT.

./Post n°31 Marquer comme non lu.

Lionel Debroux

Ecrit le: Samedi 17 septembre 2005 à 10:35

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Je me dis de plus en plus que ce dont on parle plus haut doit être relativement facile à faire en Perl, notamment grâce aux capacités de reconnaissance dans les chaînes (regex), mais pas seulement (hashes et/ou tableaux pour les correspondances nom relatif -> nom absolu ?).

Lionel Debroux - membre de TICT.