TiGcc: éviter de tout recompiler - Page 2

certains ne sont pas objectifs au sujet de mode kernel...
mais tu ne l'est pas non plus !

http://www.linux-france.org/prj/jargonf/S/standard.html

format kernel estLe un standart sur TI.
Peut-etre pas le seul, mais c'en est un.

Un standard est une norme qu'il faut respecter soit parce qu'un organisme en a décidé ainsi autoritairement (standard de jure),

Ce n'est pas le cas ici.

soit parce que tout le monde
fait comme ça et que si on ne suit pas, on n'aura pas de clients (standard de facto).

Ça non plus.

Dark Angel ne serait-il pas un défenseur du mode kernel par hasard ? Ca ne fait qu'un an que je viens ici, je ne connais pas tout...

> soit parce que tout le monde fait comme ça et que si on ne suit pas, on n'aura pas de clients (standard de facto).
En effet, c'est faux également. Il y a de moins en moins de programmes kernel qui sortent (combien de kernel pour un _nostub ?). Ca fait assez longtemps que le kernel n'est plus obligatoire (grâce à Zeljko Juric entre autres; je rappelle aux bonnes volontés qu'elles sont les bienvenues pour aider à documenter AMS, c'est à dire les fonctions d'unknown.h/les fonctions accessibles avec la dernière VTI de JM/les fonctions qui n'ont pas de nom).

Dark Angel ne serait-il pas un défenseur du mode kernel par hasard

Si. Pourquoi ? C'est une tare ?
c'est lui qui a programmé Total Destruction, avec Genlib

En effet, c'est faux également. Il y a de moins en moins de programmes kernel qui sortent (combien de kernel pour un _nostub ?).

Et combien de BONS prog nostub pr un bon prog kernel ?
/me dit que ta réponse, ou celle de Kevin, ne sera pas objective... pas plus que celle de qui que ce soit d'autre, puisque nous avons tous nos préférences au sujet des jeux

> Si. Pourquoi ? C'est une tare ?
Etre un programmeur sous kernel ne veut pas dire être un mauvais programmeur, je l'ai déjà dit... Je ne partage pas l'opinion des programmeurs kernels sur la façon dont on peut utiliser la 89/92+/V200, mais ça ne veut en aucun cas dire qu'ils sont mauvais.

> c'est lui qui a programmé Total Destruction, avec Genlib
Merci de me l'apprendre. Je ne connaissais pas du tout Dark Angel, tout comme plein d'autres personnes qui ne viennent plus que rarement ici ('Blue_Z'...)


"je rappelle aux bonnes volontés qu'elles sont les bienvenues pour aider à documenter AMS, c'est à dire les fonctions d'unknown.h/les fonctions accessibles avec la dernière VTI de JM/les fonctions qui n'ont pas de nom".
C'est parce que j'ai dit 'bonne volonté' que vous ne l'avez pas remarqué ?
(Non, je plaisante. C'est pas sympa de ma part de dire ça...)

Si vous voulez nous aider pour la documentation, veuillez envoyer un mail (en anglais) à Team@tigcc.ticalc.org.

ça ne veut en aucun cas dire qu'ils sont mauvais

=> OK

peut-être que ça veut dire que leurs programmes le sont ?
(je provoque c pas méchant)

Merci de me l'apprendre

=> De rien

Je ne connaissais pas du tout Dark Angel, tout comme plein d'autres personnes qui ne viennent plus que rarement ici ('Blue_Z'...)

ET oui, les anciens...
ils s'en vont, d'autres arrivent...
des ambitions différentes, des gouts différents...
les temps changet, les gens changent...
(argh... encore un peu, et je pars dans la philo )

C'est parce que j'ai dit 'bonne volonté' que vous ne l'avez pas remarqué ?

Je sais que ce travail est fort important...
Mais je ne l'ai pas cité car je ne trouvais pas gd chose à y répondre...
(je n'ai déjà quasiment pas le temps de coder... et coder me plait plus que documenter. De plus, il faut bien que des gens codent pr utiliser ce que vous documentez (sinon, ça sert à rien de documenter))

Oui, mais on documente d'abord et on code après. Ça permet d'utiliser ce qu'on a documenté.

pour ce que j'utilise de Rom_call (quoique, des fois, si j'utilisais certains RC, ça me faciliterai la vie... mais je perdrai bien souvent de la compatibilité)

ma fois, je suis arrivé dans la communauté voila bien longtemps...
j'ai documenté (j'ai qd même fait un tuto C à mon arrivée !)
maintenant, je code

Kevin> Est-ce que n'importe qui peut documenter une fonction, où alors il faut bien s'y connaître en C et en TI-68k ? (genre moi, tu penses que j'en suis capable ?)

Bon, ce qu'il faut faire, c'est:
* Tu regardes la liste des fonctions de unknown.h.
* Tu demandes à Sebastian (Sebastian@tigcc.ticalc.org) quelles fonctions ont déjà été documentées sans qu'on ait eu le temps d'intégrer leur documentation dans les bêtas/releases TIGCC.
* Parmi les fonctions pas encore documentées, tu regardes si tu en trouves avec des noms intéressants.
* Tu télécharges les sources de TIGCC (qui contiennent les sources des docs).
* Si la fonction est documentée dans le SDK, tu lis la documentation dans le SDK et tu vérifies si elle est correcte (en ce qui concerne: AMS minimal requis, détails de fonctionnement, surtout si la fonctionnalité complète est implémentée dans tous les AMS qui contiennent la fonction, etc.).
* Si la fonction n'est pas documentée dans le SDK:
- tu vérifies si le prototype est connu. Si ce n'est pas le cas, soit tu essayes de deviner le prototype, soit tu essayes de le trouver au débogueur de VTI (dur), soit tu laisses tomber et tu attends qu'un expert qui sait bien utiliser le débogueur de VTI trouve le prototype.
- tu regardes sous quelles versions de AMS la fonction existe.
- tu essayes d'appeler la fonction avec tous les paramètres que tu peux imaginer, sous toutes les versions de AMS, et tu regardes ce qui se passe ("black box reverse-engineering"). La méthode de reverse-engineering au débogueur de VTI est également acceptée, mais nécessite des connaissances en assembleur.
* Tu (re)formules la documentation en:
- pour les fonctions documentées dans le SDK, ne pas copiant des phrases du SDK de manière reconnaissable pour des raisons de droits d'auteur.
- utilisant des termes plus simples que ceux de TI si possible. (Mais ne change pas les termes qui apparaissent dans des noms de fonctions ou de types de données par exemple! Explique-les plutôt s'ils sont compliqués.)
- suivant le style linguistique de la documentation de TIGCC (à part les fautes d'anglais de Zeljko ).
- évitant de faire des fautes d'anglais.
- pour les fonctions documentées dans le SDK, corrigeant les erreurs de contenu et complétant ce qui est incomplet dans le SDK.
- écrivant tout ce qui est nécessaire pour tout décrire/expliquer, mais pas plus.
- donnant un petit exemple si la fonction est compliquée à utiliser.
- utilisant le format HSF de Sebastian, documenté dans les sources de TIGCC.

> tu lis la documentation dans le SDK et tu vérifies si elle est correcte
> pour les fonctions documentées dans le SDK, corrigeant les erreurs de contenu et complétant ce qui est incomplet dans le SDK
Il y en a vraiment besoin... Par exemple, je crois que c'est HomeAlone (ROM_CALL 506) qui est dit comme existant sur toutes les versions d'AMS...

Parfois, il y a besoin de voir ce que fait la fonction quand tu lui passes des paramètres incorrects. Ca peut lancer une erreur, renvoyer un message d'erreur, ou renvoyer n'importe quoi... Il y a une des fonctions qui rend la XR_string du langage courant sous AMS 2.xx si le paramètre est incorrect, d'après ce que j'ai pu voir..

> mais je perdrai bien souvent de la compatibilité
En effet, beaucoup de fonctions n'existent en ROM_CALL que sous AMS 2.xx... Mais il y a des wrappers pour AMS 1.01/1.05 (les versions avec 0x3CC ROM_CALLs) pour certaines d'entre elles (j'ai dû en faire environ une dizaine).

Kevin Kofler a écrit :
toutes les versions de AMS, et tu regardes ce qui se passe ("black box reverse-engineering"). La méthode de reverse-engineering au débogueur de VTI est également acceptée, mais nécessite des connaissances en assembleur.

Black box? Tu m'étonnes. Si tu veux obtenir une réponse couillon t'as qu'à posser une question imbécile. Et si tu fais black box le 99.99% des fois tu poses des questions imbéciles. Dans le meilleur des cas la fonction retourne n'importe quoi. Dans le pire, tu lui files un pointeur vers un endroit critique de la RAM et la fonction te bousille la calc. Pas très marrant. Je suis plutôt partidaire du debugger.

Oulàlà je ne comprend rien à ton Français

Thibaut a écrit :
Oulàlà je ne comprend rien à ton Français

Bref tu peux pas deviner ce que fait une fonction en lui envoyant n'importe quoi comme parametre et en regardant ce qu'elle retourne. Meme plus, si on a mauvaise chance et la fonction recevait un pointeur ou elle devait ecrire un resultat et tu lui files, dissons, un $40000, ca y est il bousille tous tes interrupt vectors.

Ok c'est 1024 fois plus clair

N'insulte pas mon noble charabia :^)

Je serais heureux de parler aussi bien anglais que toi pour le français ! Moi, c'est tout le temps que j'écris des phrases illisibles comme la tienne !

Je ne suis pas vraiment d'accord. Sa phrase n'est pas illisible. Ce n'est pas de l'excellent français, mais on peut comprendre le sens.

Disons qu'on a beaucoup de mal

Moi, j'ai très bien compris le message #44 dès le départ.

Bon c'est vrai que c'est pas si terrible

Kevin Kofler
a écrit : Si vous voulez nous aider pour la documentation, veuillez envoyer un mail (en anglais) à Team@tigcc.ticalc.org.

En Anglais c quoi ce cirque ???? Yn est français que je sache... Ticalc attendra pour la traduction, pas l'inverse... sinon je veux bien essayer de jeter un oeil si on m'explique quoi documenter...

Je ne sais pas si tu as compris mon message:
* Il s'agit de la documentation de TIGCC, qui est un projet international.
* La personne qui s'occupe de la documentation de TIGCC est Sebastian Reichelt, qui ne parle (presque) pas français, d'où la nécessité d'écrire en anglais. (D'ailleurs, le mieux est de contacter directement Sebastian à Doc@tigcc.ticalc.org ou Sebastian@tigcc.ticalc.org. Pas la peine de contacter toute l'équipe. Et si tu contactes Sebastian directement, tu peux aussi parler allemand si tu préfères. )
* La documentation de TIGCC est en anglais, donc si vous voulez nous aider, la connaissance de l'anglais est un prérequis de toute façon.

le site de la tigcc est hébergé par ticalc
ce qui explique l'adresse en ...@tigcc.ticalc.org

et l'équiipe de tigcc est internationale, ce qui explique le pkoi de l'anglais