TI-Lib - Page 1

Voilà, je propose de faire une librairie dynamique standard contenant toutes les fonctions de base que bcp de personnes ont en triple sur leur calc (voire bcp plus) :

Fonctions de fichiers :
fopen/fclose/fgetc/fputc/fprintf/fseek/ftell

Fonctions de stdio :
clrscr/fputchar/printf/atoi/atol

Fonctions de jeux :
OpenFile/CloseFile/_rowread/rand
GrayOn/GrayOff/etc...

OpenFile et CloseFile sont des fonctions très utiles permettant d'ouvrir des fichiers binaires en lectures, de manière bcp plus adaptée aux jeux que fopen/fclose :

void *OpenFile(char *file);
void CloseFile(char *file);

OpenFile recherche 'file' dans le répertoire courant, puis dans tous les répertoires de la calc. CloseFile permet de fermer le fichier sans avoir à sauvegarder de handle/FILE, et marche aussi si OpenFile a renvoyé NULL Bien entendu, ces fonctions ne s'adressent pas à des progs susceptibles de créer un fichier du même nom que 'file' (mais dans les jeux ce n'est pas le cas)
Bien entendu je publierai la source pour que vous puissiez le rajouter à tigcc.a si vous voulez


L'objet de cette lib est de permettre à TI-GCC et GTC d'exploiter enfin les possibilités du mode Kernel, ce qui n'était vraiment pas le cas avant Et rien n'empêche les progs ASM de l'utiliser...

Je précise la convention d'appel : regparm(2) (contrairement à tigcc.a qui est en regparm(4))
La taille devrait tourner aux alentours de 3 ko, donc je pense que ce serait une bonne idée de l'intégrer au kernel, pas dans la partie TSR mais dans la partie archive comme ça pas de mauvais prétexte pour ne pas l'utiliser

Si vous pensez qu'il manque des fonctions ou que certaines sont en trop, exprimez-vous

Rajoute toutes les fonctions graphique necessaire..
Le must serai une fusion de GX X Gen.. mais faut pas rever.. !)

NB: Si tu veux je te donne les sources de XLib....

Pollux : cette librairie existe déjà elle s'appelle stdlib... tu la connais mieux que tout le monde, d'ailleurs.

bien sûr que fopen/etc... viennent de stdlib

Je réexplique : c'est une librairie dynamique (eh oui Kevin ) avec les fonctions les plus utilisées de stdio (et qq unes de stdlib ) ainsi que des fonctions de gray, pour éviter d'avoir des Hello world de 350 octets (c'est le cas avec TI-GCC, si en plus tu veux le faire en gris ton prog prend plus de 1 ko )

Pendant qu'on y est, pour ceux que ça intéresse : http://www.genezis.fr.fm/OpenFile.zip

Mais non !!!!! je te parlais de la librairie qui-fait-tout de GTC ! elle s'appelle bien stdlib.89z ?

Je pense que vous vous en doûtiez déjà, mais je vais quand-même le dire: je suis contre!
tigcc.a est vraiment la meilleure solution.

En tout cas, ne comptez pas sur nous pour officiellement supporter une librairie dynamique pour stdio/stdlib: à vous de créer les headers modifiés. Nous, on n'en veut pas.

Pollux: ca t'interesse de mettre des routines graphique dedant?
Parce que tu peux faire ce que tu veux avec XLib.. je m'en tape.. (meme pas besoin de me cité..), comme pas exemple diminuer les boucle par 2 et les rendre plus flexible..

Enfin a toi de voir...

Pour l'instant le but est de créer une librairie minimale regroupant toutes les fonctions communes, pour les jeux comme pour les utilitaires. Après on peut tjs faire une autre lib fusion de GX/X/Gen Je ne comprends d'ailleurs pas pkoi vous publiez pas vos sources

Kevin>

tigcc.a est vraiment la meilleure solution.
En tout cas, ne comptez pas sur nous pour officiellement supporter une librairie dynamique pour stdio/stdlib: à vous de créer les headers modifiés. Nous, on n'en veut pas

Pkoi? Si tu ne veux pas du mode kernel, tu t'en fous de savoir ce que font ceux qui prog en mode kernel... Il suffit de rajouter #include <tilib.h> à la fin de doors.h, c tout ce que je demande

Pollux a écrit :
Kevin>

Pkoi? Si tu ne veux pas du mode kernel, tu t'en fous de savoir ce que font ceux qui prog en mode kernel... Il suffit de rajouter #include <tilib.h> à la fin de doors.h, c tout ce que je demande

Non.
1. Ce n'est pas propre de la part d'un compilateur de rajouter une dépendance vers une DLL externe sans que l'utilisateur le demande explicitement. Seule exception: si la DLL est livrée avec le système (par exemple KERNEL32.DLL et CRTDLL.DLL sous Windows, libc.so sous Linux, ...). J'utilise aussi MinGW et pas Cygwin pour ça.
2. Nous ne supportons officiellement que les routines de tigcc.a. Inclure automatiquement ton header voudrait dire supporter officiellement tes routines. Et non, nous ne sommes pas intéressés par l'idée de faire une DLL kernel officiellement supportée et avec nos routines, nous préférons tigcc.a en statique, cf. numéro 1.

Si les programmeurs veulent utiliser ta DLL kernel, ils n'ont qu'à inclure ton header (qu'ils récupéreront chez toi, pas chez nous - nous, on ne supporte que tigcc.a).

Parfaitement d'accord avec Kevin.

> Ce n'est pas propre de la part d'un compilateur de rajouter une dépendance vers une DLL externe sans que l'utilisateur le demande explicitement. Seule exception: si la DLL est livrée avec le système (par exemple KERNEL32.DLL et CRTDLL.DLL sous Windows, libc.so sous Linux, ...). J'utilise aussi MinGW et pas Cygwin pour ça.
c bien pour ça que j'ai proposé une intégration dans PreOS (j'attends la réponse de PpHd)
et puis si on continue ton raisonnement, tant qu'on y est, pkoi ne pas arrêter supporter le kernel? il n'est pas livré avec le système

Pour le moment, je crois qu'il n'est pas prévu d'arrêter le support du kernel... A moins que des utilisateurs soient trop *pénibles*...
Si Kevin voulait imposer toutes ses idées de programmation (et je n'ai pas l'impression que ça soit son genre), le kernel ne serait plus supporté depuis plus d'un an, le DLL n'aurait peut-être même pas été fait...

Et tu ne pourrais pas aider à documenter les fonctions des versions d'AMS, plutôt que de faire des trucs inutiles (ben oui, ça sera incompatible avec TIGCC, donc poubelle). C'est comme faire un ROM qui ne gère même pas le calcul: poubelle !

Psss..
Et oui Si TIGCC ne supporte plus le kernel. ce sera la preuve de leur totalitarisme.. au fait ya pas l'auteur de doorsos qui a participer a l'elabiration de tigcc (le linker..) ..
Je pense pas qu'il soit d'accord avec ces idées .. (meme si il n'est plus actif..)

Quel respect

"Et tu ne pourrais pas aider à documenter les fonctions des versions d'AMS, plutôt que de faire des trucs inutiles (ben oui, ça sera incompatible avec TIGCC, donc poubelle). C'est comme faire un ROM qui ne gère même pas le calcul: poubelle ! "

Lol ce sera certainement mieux programmé que la lib TIGCC.. donc ce sera surment votre lib qui deviendra inutil.. et c'est surment ca qui vous gene plus qu'autre chose..

Pollux: si je ne diffuse pas mes sources, c'est que j'ai un peu honte.. ya des truc qui sont pas top

Pollux a écrit :
> Ce n'est pas propre de la part d'un compilateur de rajouter une dépendance vers une DLL externe sans que l'utilisateur le demande explicitement. Seule exception: si la DLL est livrée avec le système (par exemple KERNEL32.DLL et CRTDLL.DLL sous Windows, libc.so sous Linux, ...). J'utilise aussi MinGW et pas Cygwin pour ça.
c bien pour ça que j'ai proposé une intégration dans PreOS (j'attends la réponse de PpHd)
et puis si on continue ton raisonnement, tant qu'on y est, pkoi ne pas arrêter supporter le kernel? il n'est pas livré avec le système

1. J'aurais bien voulu bien faire ça, mais il faut rester compatibles avec les vieux programmes.
2. Le kernel n'est nécessaire que si le programmeur (l'utilisateur de TIGCC) le demande explicitement.

>XDanger:
>(ben oui, ça sera incompatible avec TIGCC, donc poubelle)
Pas nécessairement. Juste que le header nécessaire ne sera pas livré avec TIGCC, ça c'est sûr.

TiMad, si seulement tu pouvais présenter des arguments plutôt que des insultes...

<< Lol ce sera certainement mieux programmé que la lib TIGCC.. donc ce sera surment votre lib qui deviendra inutil.. >>

TIGCCLIB est très bien programmée! Il n'y a pratiquement pas de bogues dans tigcc.a. (Je ne suis au courant d'aucun bogue dans la version la plus récente).

Sinon je suis POUR une fusion X/Gen/GX ! en triant le meilleur de chaque librairie pour pas avoir des fonctions "en double" (pour le but final). Ca serait le !

Je suis sûr que vous vous en foutez, mais je suis sontre un support officiel de la lib par tigcc (pour les mêmes raisons que Kévin).

moi aussi. je suis aussi sur que vous vous en foutez, mais je suis contre les kernel )

KK: bien programmé mais ptetre peut etre pas optimisée

Carrément pas optimisé.

Ils prétendent se soucier de l'optimisation en taille, mais leur librairie est inutilement grosse.
Et après ils veulent faire la leçon à ceux qui programment soi-disant mal (TiMad avec la DLL de Xlib)

microbug a écrit :
moi aussi. je suis aussi sur que vous vous en foutez, mais je suis contre les kernel )

Pour l'optimisation: TIGCCLIB est beaucoup plus optimisée que AMS!

impressionnant coimme reference

Même le plus débutant des newbies ferait mieux qu'AMS, alors...

Kevin Kofler
a écrit : 2. Le kernel n'est nécessaire que si le programmeur (l'utilisateur de TIGCC) le demande explicitement.

Vous pouvez alors adopter sur ce même principe la librairie de Pollux mettant un #define USE_TI_LIB par exemple, vérifiant si le programme est bien kernel ...

Non, parce que Ti-Lib n'est pas à nous (et donc pas supporté officiellement par nous) et que de toute façon on est contre.

D'accord.

alors ca c'est loin, tres loin d'etre une reference,

l'AMS ? c clair !