Le _rowread de TIGCClib - Page 3

Thibeau: Si tu veux que tes fonctions soient prisent en compte, tu as cas me les envoyer et je les mets dans XLib bien entendu avec tout ce qui va avec...

squale > bien vrai ! bcp attaque le C (comme je l'ai fait) mais n'arrive pas à tout, on pert patience. Alors le mieux est de bien apprendre avec des bouquins (car ton tuto squale, dans l'état où tu l'a distribué pour la dernière fois, ne permet pas de tout comprendre car il ne fait pas 400 pages ! tu expliques bcp de choses , mais pas tout, et je crois que pour réussir à bien coder, il faut aussi s'appuyer sur d'autre doc, comme des livres ect, ce que font peu de newbie.

mon tuto n'est pas conçu pr être utilisé seul.
Je l'ai conçu pr permettre aux débuttants de débuter... et leur permettre d'atteindre un niveau qui leur permettre de continuer l'apprentissage du C seul...

en effet .
il initie bien à la prog C sur TI, mais il faut ensuite apprendre de soi même.
D'ailleurs il avance toujours le tuto ?

TiMad : je m'en fout qu'elles soient prises en compte. Le truc c'est que Kevin m'avait pris la tête (faut voir le topic, on avait passé 2-3 pages à s'engueuler) pour que je l'autorise à les reprendre pour TIGCClib, et je constate plusieurs mois après qu'il n'en a rien fait

Thibaut
a écrit : Je n'ai jamais rien fait pour TIGCC mais c'est pas pour autant que je ne programme pas... bien qu'on puisse dire que j'ai fait quelque chose pour votre compilateur : Kevin m'avait FAIT CHIER pour que je vous offre des routines optimisées de la bibliothèque Azur (d'où est tirée la fonction des posts #36 et #40), et je vois qu'elles n'ont toujours pas été intégrées à TIGCC.

Parce que je me suis rendu compte qu'elles étaient mal programmés (modification de l'octet devant la chaîne de caractères, ce qui peut créer des ennuis dans certains cas - tu n'as toujours pas corrigé ça que je sache) et que Greg Dietsche a implémenté la seule nouveauté que tes routines apportaient (correction du problème du gaspillage de place dans les fichiers créés) dans les routines existantes, ce qui fait que je ne vois plus aucun intérêt de changer les routines. (Pourquoi changer une routine qui fonctionne?)

squale92 a écrit :
slubman> exact, sans TIGCC, la prog sur TI ne serait pas ce que c'est
il y aurait bcp moins de newbies passé pr coder un jeu raté et partir ensuite, vu que seuls les gars motivés à mort auraient appris l'ASM (alors que plein de gars pas motivé (ou peu) commencent le C et laissent vite tomber, après avoir vu qu'ils ne pouvaient pas égaler les Grands Jeux en une semaine)

Raaah... Je n'aime pas trop l'inefficacité du C par rapport à l'assembleur, mais il faut aussi voir que des jeux comme TI-Chess n'ont été possibles que grâce à GCC!

Cher Kevin, puis-je vous rappeler (pourtant à l'époque c'était une des raisons qui vous poussait à me demander l'autorisation de reprendre mes routines) que mes fonctions ptrennent moins de place (il y a par exemple un gain de 100 octets entre votre fopen et le mien !!) que celles de TIGCC ?
Pourtant vous êtes bien le monsieur qui prétend toujours vouloir optimiser les programmes en taille plutôt qu'en vitesse ?

Et puis vous avez tout à fait le droit de corriger ce qui ne vous plaît pas dans mon implémentation (conversion ANSI->SYM_STR)

On n'en est pas à 100 octets près dans un programme en C. Il est beaucoup plus important d'avoir des routines bien testées qui marchent bien.
Et désolé, mais je n'ai pas le temps de bien tester tes routines en ce moment. On a déjà assez de trucs à faire: par exemple mettre à jour dialogs.h: Jocelyn Berrendonner nous a envoyé une nouvelle documentation, mais elle n'est pas parfaite et donc on doit vérifier tout ce qu'il dit (surtout pour vérifier ce qui se passe sur les différentes versions d'AMS) et corriger les nombreuses fautes d'anglais.

Le problème cher Kevin, c'est que nulle part vous n'êtes à 100 octets près !
100 octets par ci pour la détection automatique de la cal en début de prog
100 octets par là pour fopen
1000 octets vers là pour telle macro (qui aurait pu être implémentée en une fonction) appelée x fois (tu as vu le post #50 de ce topic ?)
100 octets ....


Vous avez vu la taille monstrueuse des programmes générés avec TIGCC ?
Malheureusement, nous, les users, on a le droit de fermer notre gueule et de vous laisser imposer vos idées parcequ'on a le choix entre ça et l'ASM.

Thibaut
a écrit : 1000 octets vers là pour telle macro (qui aurait pu être implémentée en une fonction) appelée x fois (tu as vu le post #50 de ce topic ?)

_rowread est déjà une fonction, justement pour des questions de place (message #15)!

Vous avez vu la taille monstrueuse des programmes générés avec TIGCC ?

Si vous voulez un programme optimisé, pourquoi programmez-vous en C?
Pour les programmes optimisés, il y a l'assembleur. Une grande partie de la perte de place est due à GCC (qui optimise toujours mieux que le compilateur Sierra utilisé par TI pourtant), pas à TIGCCLIB! Si notre fopen est gros, c'est aussi parce qu'il est écrit en C.

Thibaut
a écrit : Malheureusement, nous, les users, on a le droit de fermer notre gueule et de vous laisser imposer vos idées parcequ'on a le choix entre ça et l'ASM.

Eh ben, si t'es pas content personne ne t'oblige à utiliser TIGCC, t'as qu'à utiliser le compilateur AZUR
Et plus sérieusement, personne ne t'empeche de télécharger les sources de TIGCC et d'implémenter toi-même les changements que tu veux (c'est ce que je suis en train de faire moi, étant donné que Kevin à refusé à plusieurs reprises d'implémenter mes idées géniales dans TIGCC).
Ils ne sont pas payés pour te faire plaisir que je sache

Alors acceptez les contributions visant à améliorer ce problème de place : je vous ai offert une fonction qui ferait gagner 100 octets, vous n'en profitez pas. 100 multiplié par N refus, ça fait beaucoup !
Si tu n'as vraiment pas le temps de la corriger, je peux le faire pour toi.

Tu cites le post #15, alors moi je te cite le post #51

NITRO JE SUIS DESOLE MAIS QUE JE SACHE EN DIMINUANT LA PLACE PRISE PAR LES BINAIRES GENERES PAR TIGCC ILS FERONT PLAISIR A BEAUCOUP D'AUTRES QUE MOI

Bon: Vu que je n'ai pas le temps de m'occuper de toutes vos contributions (qu'il faut tester etc.) et que de toute façon ce n'est pas moi qui décide en définitive ce qui va dans TIGCCLIB et ce qui n'y va pas, contactez Sebastian et Zeljko directement. De toute façon, ce sont eux qui décident en fin de compte.

100 octets ça commence à faire en effet .... surtout si de la place est "perdue" comme ça sur plusieurs fonctions. Enfin, je ne connais rien à l'ASM, et je débute en C, donc je ne prefère rien dire (il faudrait que je connaisse mieux le sujet). Mais quand même, TIGCC est cool quand même pour les programmeurs C !!
toutefois, si qq'un assure que ses routines sont meilleures que celles de TIGCC et qu'elles sont fiables (cad approuvé par les meilleurs), ben ça serait cool de les distribuer , enfin ça sera à vous de voir.

Thibaut a écrit :
NITRO JE SUIS DESOLE MAIS QUE JE SACHE EN DIMINUANT LA PLACE PRISE PAR LES BINAIRES GENERES PAR TIGCC ILS FERONT PLAISIR A BEAUCOUP D'AUTRES QUE MOI

Et que je sache la TIGCC Team n'est pas une action bénévole dévouée corps et âme dont le seul but est de faire plaisir aux gens. Ils ont une vie aussi à coté (au cas où tu aurais oublié ce détail) et tester des routines sensées remplacer d'autres routines qui sont deja 100% stables, ce n'est pas prioritaire, et ça ne se fait pas en claquant des doigts.

>Nitro: C'ést quoi les idees geniales ?
Ca me rappelle la modif que j'ai dite sur le __save__sp__ permettant d'economiser 2 octets. Enfin bon.

PpHd a écrit :
>Nitro: C'ést quoi les idees geniales ? Ca me rappelle la modif que j'ai dite sur le __save__sp__ permettant d'economiser 2 octets. Enfin bon.

Ta modif nécessite des changements au code du patcheur (pour que le __save__sp__ soit garanti être suffisamment proche de _main), ce qui ne vaut vraiment pas le coup pour 2 octets.

Nitro : met-toi au courant de l'histoire avant de vouloir me faire la leçon

Kevin Kofler a écrit :
Ta modif nécessite des changements au code du patcheur (pour que le __save__sp__ soit garanti être suffisamment proche de _main), ce qui ne vaut vraiment pas le coup pour 2 octets.

LOL. Le mec qui est pour l'optimisation en taille du code tout le temps, m'a sorti cette phrase.

Pim> mon tuto n'avance plus. (son contenu)
Mais il est en cours de remise à jour (changement de présentation, il sera plus progressif aussi)

Qd je pourrai, je voudrai rajouter quelques trucs...
j'ai aussi quelques fichiers txt que j'ai tapé à l'arrach que je voudrai intégrer...
mais g pas mal de choses à faire avant

Kevin> moué... mais bon
C vrai que le C est plus aisé à coder... mais moins efficace dans certains cas...
Le mieux est à mon avis le mix des deux dans un programme...

Thibaut a écrit :
Nitro : met-toi au courant de l'histoire avant de vouloir me faire la leçon

Je suis tres bien au courant de l'histoire, et je suis 100% d'accord avec Kevin

Ben non t'as pas trop l'air au courant, sinon tu n'aurais pas dit ça. Tu ne devais pas être là à l'époque du fameux topic.

Thibaut
a écrit : Ben non t'as pas trop l'air au courant, sinon tu n'aurais pas dit ça. Tu ne devais pas être là à l'époque du fameux topic.

Bien sur que j'etais la, je suis sur tous les forums TI depuis l'époque de Roby... Je sais tres bien que Kevin t'as fait chier, et alors ?

Et alors ne va pas me dire d'arrêter de râler parceque ces fonctions n'ont pas été intégrées si tu sais que j'ai des raisons étant donné le mal qu'on a eu a se mettre d'accord (si tu te souviens de l'engueulade de 3 pages).

Moi, j'étais surtout intéressé quand nos routines avaient encore un bogue que les tiennes n'avaient pas. Mais il a été corrigé entretemps.

Et j'étais beaucoup plus intéressé par les routines qui apportent vraiment de nouvelles fonctionnalités que par celles qui réimplémentent bêtement les routines qu'on a déjà. C'est pour ça que je te faisais ch**r pour que tu nous permettes d'utiliser tout ton runtime.

>> "réimplémentent bêtement les routines qu'on a déjà"

Tu te venges là, tu me provoque à ton tour ?
Ou dis moi ce qu'il y a de bête à reprogrammer des fonctions plus rapides et moins grosses

au lieu de débattre dans le vent, là ou aucun des deux voudra reconnaitre qu'il a en partie tord et que l'autre a en partie raison, codez, messieurs



(et je vioens foutre la merde en plus )

PpHd>Genlib rulezz
certes, et avec AS+CC,comment on fait???