TiRex - C'est parti !!! - Page 5

Si les archives sont censées regrouper les meilleures productions réalisées, alors tu as oublié Crono Fanatasy.

Paris ne s'est pas faite en un jour, je lui ai envoyé pas mal de fichiers, mais il faut séparer le bon grain de l'ivraie...

1. il manque toute les docs de prog de tifr (90
2. il manque des tonnes de prog asm (les plus interessants)
3. j'aime pas la team.
4. je sens que ca va se finir comme #ti.

Bon je conviens que mon post est pas tres sympat, mais c'est en souvenir de l'ancien temps.. j'espere que certaines personnes auront evolués!

Sinon c'est du graphiti tout craché..

c'est quoi le pb avec la team ?

NB: il y a desja des prog obso genre romedit.. meme pas executable..

Alors petit bilan :

- pas de news depuis 6 jours
- archives toujours pas à jour
- erreurs signalées tjrs non-corrigées

TiRex ça va partir

>-pas de news depuis 6 jours
Pas grand chose a signaler depuis 6 jours
Pour le reste c'est vrai que ca avance pas très vite pour l'instant mais bon c'est que le début!

Les gars ne sont pas non plus constemment devant leur pc les gars. lol.

Uther Lightbringer a écrit :
>-pas de news depuis 6 jours
Pas grand chose a signaler depuis 6 jours Pour le reste c'est vrai que ca avance pas très vite pour l'instant mais bon c'est que le début!

si si justement y'avais des trucs
ah par contre y'a une news qui a été rajoutée avec 1 semaine de retard

Je viens de regarder le "dictionnaire" de Ti-Rex et il y a pas mal d'erreurs ou d'omissions:
* C: Ça fait des mois que notre projet s'appelle TIGCC et non pas TI-GCC.
* CAS: Le CAS n'est pas le système d'exploitation, c'est le système de calcul formel. Il est intégré à AMS, mais ce n'est pas AMS.
* DoorsOS: Nulle part n'est-il dit que ce kernel est très vieux et qu'il ne faut pas l'utiliser.
* Gris: Il y a écrit "mais 7 sont envisageables", alors qu'on en est déjà à 8.
* Kernel: Définition largement incomplète (en 2 lignes). Il manque des tas d'informations. Aussi, nulle part n'est-il dit que le kernel prend de la place en mémoire et représente un risque de stabilité et qu'il faut donc éviter d'en utiliser un si c'est possible (c'est-à-dire s'il y a des alternatives _nostub aux programmes qu'on veut utiliser).
* Librairie: Il n'y a pas besoin de librairie pour effacer l'écran!!! http://tigcc.ticalc.org/doc/graph.html#ClrScr. Ça fait 3 ans que la documentation de TIGCC existe et il y en a toujours qui ne l'ont pas lue!
* Niveaux de gris: Voir Gris.
* OS: Il est dit "Il peut également s'agir d'un kernel permettant l'exécution des programmes assembleur sur la calculatrice.", sans préciser que cette appellation est à tord. Un "kernel" n'est pas un système d'exploitation (ni d'ailleurs un kernel au sens strict, mais bon).
* PlusShell: Voir DoorsOS.
* PreOs: Entrée manquante. Pourquoi tous les autres kernels sont mentionnés et pas lui?
* ROM: Voir CAS.
* RPN: Il faudrait parler de RPN de Lars Frederiksen!
* Shell: Il faudrait préciser que ce terme est parfois utilisé à tord pour désigner un "kernel".

a peut pres d'accord avec Kevin sauf le :
"Aussi, nulle part n'est-il dit que le kernel prend de la place en mémoire et représente un risque de stabilité et qu'il faut donc éviter d'en utiliser un si c'est possible (c'est-à-dire s'il y a des alternatives _nostub aux programmes qu'on veut utiliser). ".
Quoi que c'est vrai que le kernel représente un risque de stabilité car il intègre un anti-crash, mais je doute que cette remarque soit vonlontaire de la part de Kevin.

Et on peut très bien utiliser les lib pour effacer l'écran(quelles qu'elle soient). On peut même faire sans lib avec un simple memset. Il s'agit ici juste d'un example

Tu n'as pas compris: "risque de stabilité" = "risque pour la stabilité" = "ça risque de planter". Et l'anti-crash n'est pas de la stabilité! Un plantage est un plantage, qu'il soit récupéré par un anti-crash ou non!

Et, bien qu'on puisse utiliser une librairie pour effacer l'écran, il est stupide de le faire, parce qu'il y a un ROM_CALL qui fait exactement la même chose! On ne gagne strictement rien à utiliser une librairie pour cela!!!

Et je suis désolé, mais j'ai de plus en plus l'impression que tu fasses exprès de ne pas comprendre ce que je dis.

Je ne vois pas en quoi mon message est partial!

Forcément en dissuadant d'emblée de programmer en kernel tu peux ensuite affirmer que personne n'utilise plus ce mode!
Ton message est partial en ceci qu'à la place de mettre quelque chose d'objectif tu en profites pour poignarder ce pauvre kernel dans le dos... pas très sport!
Un programme kernel a autant de chance de planter qu'un programme nostub, il ne faut pas abuser!
Mais le débat n'est pas à (re)faire dans ce topic ci.

En bon français "risque de stabilité" signifie que c'est que c'est dangeureux d'avoir une calculatice stable et que c'est pour ca qu'il ne faut pas utiliser le kernel : pour garder sa calculatrice instable.

je doute que cette remarque soit vonlontaire de la part de Kevin.

J'ai très bien compris que tu voulais parler d'un risque pour la stabilité(et non d'un risque de stabilité), mais j'ai touvé marrant que tu dise l'inverse de ce que tu voulait dire c'est tout.
Et pour effacer l'ecran je répete que c'est un exemple facile a comprendre et qui reflète bien ce que peut être l'utilité d'une librairie, d'ailleurs les ROMCALLs c'est un peu comme une lib dynamique(je sais c'est pas vraiment pareil mais ca a quand même des points communs).

Rahhhhhhhhhhhhhhhhhhhhhhhhhhhhh
Vous allez pas ENCORE refaire un débat Kernel Nostub ici bordel ??? 300 topics ça vous suffit pas, il en faut un 301-eme ?

La FAQ n'est pas à jour, point, c'est normal vu qu'elle a été au moins partiellement reprise de Ti-fr, donc ça date. Le reste à propos de kernel nostub, y'a un autre topic pour ça.

le kernel ne peut etre que plyus stable que le nostub.....
D'ailleur si on oublie de desalouer 140Ko de ram en nostub.. la calc on fait comment pour recuperer la ram???? avec un kernel on a pas ce probleme!

Il suffit de programmer proprement (c'est-à-dire ne pas oublier de désallouer ce qu'on a alloué).

Et pour répondre à ta question précise: [2nd]+[gauche]+[droite]+[ON] ou [2nd]+[HAND]+[ON] selon le modèle. C'est pratique si on n'a rien à réinstaller après un reset.

oui bien sur.. mais il ne faut pas oublier les problemes de certains lanceurs archivé qui plante..
Et puis la stabilité ne se defini pas par rapport auc programmeurs, mais par rapport au system d'exploitation qui doit justement faire face aux oublits des programmeurs...

Du balais !

Je viens de voir la liste de liens vers les derniers programmes de Ti-Calc. Je ne sais pas comment ça marche, mais tant qu'à leecher, autant le faire bien : mettre des liens vers la page de description plutot que vers un .zip dont on ne connait RIEN à part le nom (ni type, ni langage, ni screenshot, etc...).

Vertyos,#143->ce serait judicieux en effet...

Yop, je suis de retour après un crash de disque dur.
Vertyos, bonne idée, j'ai modifié le script, ca pointe vers les descriptions désormais.
Concernant le Dico : y'a quelques erreurs c vrai, merci de nous les avoir signalé.

Un truc util..
lorsque qun poste un prog, => creation de compte, et il a droit de modifier tous les progs qu'il a posté..

Rom1-TiRex
a écrit : Vertyos, bonne idée, j'ai modifié le script, ca pointe vers les descriptions désormais.

V voir ça, si je reposte pas c'est que c'est nikel

Bah c'est nickel

Ce serait en effet bien qu'un programmeur puisse uploader tout seul ses progs ... même si ca peut laisser la place a certaines conneries, je pense que ca faciliterait la mise à jour des archives etc.