eBooks sur TI - Page 3

KerNO a tout ce qu'il me faut, à savoir une protection anti-crash et la redéfinition des temps d'auto-repeat à l'allumage de la calculette. Je n'ai pas besoin d'un kernel qui prend beaucoup plus de place, parce que je ne m'en sers pas.
Et en effet, moi non plus, j'ai peu de plantages. Rien de commun avec ce que j'avais la dernière fois que j'ai utilisé un kernel, UniversalOS 1.14 à l'époque (trois plantages de programmes en BASIC en quelques jours...). J'ai eu quelques plantages depuis un an, au moins deux étaient dus à tthdex et deux étaient dus à KerNO (un pour vérifier que c'était bien le fait de KerNO et pas d'autre chose), des bugs que j'ai reportés et qui ont été corrigés.
PreOS est plus stable qu'avant (j'avais réussi à planter la 0.52 ou la 0.54, je ne sais plus, sur ma VTI, en deux minutes, simplement en éteignant la VTI avec DIAMOND + OFF... éteindre la calculette est une opération normalement très risquée et très rare, comme chacun sait...), mais ça n'est toujours pas ça: la procédure de désinstallation faisait planter il n'y a pas si longtemps (OK, KerNO aussi, mais ça fait des mois que ça a été corrigé, et c'est tout récent pour PreOS)...

Bof préos j'ai pas aimé parce qu'il me stolait (volait) de la mémoire (2-3 ko) à chaque récupération de crash ou de ESC-ON. Je ne sais pas de quelle version il s'agissait.

De toute façon, pas la peine de tester les versions les plus récentes, c'est toujours le cas. ExtendeD et moi, et aussi PpHd lui-même, nous avons fait notre possible pour éviter les leaks de mémoire dans l'anti-crash pour programmes _nostub, mais il en reste toujours. La méthode de PreOs est d'effectuer un reset partiel, ce qui a l'avantage de marcher même en cas de variables système corrompues, mais ce qui rend très difficile d'éviter des leaks dus à la mémoire allouée à l'initialisation par AMS qui est allouée 2 fois. KerNO utilise tout simplement ER_throw pour retourner à AMS.

Tu es sûr que c'était pas le programme qui crashait qui provoquait ça? En tout cas maintenant c'est très certainement réglé, mais comme je disais plus haut si tu n'en a pas l'utilité, pas la peine de le mettre ...

Il faut considérer un anti crash plus comme une deuxième chance d'archiver ce qui ne l'était pas avant un crash pour pouvoir faire un vrai reset de toutes façons, on n'est jamais trop prudent ...

Tu es sûr que c'était pas le programme qui crashait qui provoquait ça? En tout cas maintenant c'est très certainement réglé, mais comme je disais plus haut si tu n'en a pas l'utilité, pas la peine de le mettre ...

Non! Tu appuyes 15 fois sur ESC-ON de suite et tu perds 40 ko!

La méthode de PreOs est d'effectuer un reset partiel, ce qui a l'avantage de marcher même en cas de variables système corrompues, mais ce qui rend très difficile d'éviter des leaks dus à la mémoire allouée à l'initialisation par AMS qui est allouée 2 fois. KerNO utilise tout simplement ER_throw pour retourner à AMS.

Ca explique tout! Il est vrai que ça ne doit pas être facile!

Il faut considérer un anti crash plus comme une deuxième chance d'archiver ce qui ne l'était pas avant un crash pour pouvoir faire un vrai reset de toutes façons, on n'est jamais trop prudent ...

Effectivement...

ESC + ON sert à éviter de perdre des données suite à un plantage.

Ça ne sert à rien si on a tout archivé, ce qui est toujours conseillé. Il peut toujours y avoir un plantage irrécupérable!
Personnellement, je trouve que l'anti-crash n'est pas une fonctionnalité très utile.

La fonctionnalité la plus utile est de concevoir des programmes STABLES! C'est tout! Y'a pas de miracle... Mais beaucuop trop de gens s'en tapent et voilà le résultat.
Perso l'anti-crash me sert pour récupérer des erreurs de mes progs pdt le test. Par exemple si j'ai une Adress Error, je peux sûrement trouver pourquoi, et il y aura beaucoup de chances que ce ne soit pas grave (une mauvaise instruction c'est tout). Maintenant si c'est dû à un débordement de pile ou à un ROM_CALL erroné (callback, ou utilisation hasardive du registre a6)... c'est clair qu'il n'y a pas de miracle!

> Mais beaucoup trop de gens s'en tapent et voilà le résultat.
Le but de ce post n'est pas de lancer une flamewar, mais de répéter les faits:
les vieux kernels et programmes kernel, surtout ceux d'avant AMS 2.xx, utilisaient des choses absolument horribles (adresses absolues pour accéder à des variables système)... Ca n'est vraiment pas du code fool-proof, car c'est potentiellement cassé par tout update du système, qui n'était vraiment pas imprévisible (la Flash ROM, ça peut servir à quoi ?). Et on a vu ce qui s'est passé...

Les programmes _nostub ne sont pas épargnés, mais la majorité des trucs qui sont breakés sont breakés par la faute de TI et affectent aussi les programmes kernel. Structures différentes selon les versions d'AMS (ça existe, et c'est catastrophique pour certaines d'entre elles: incluez donc une structure qui n'est pas la même sous toutes les versions d'AMS dans une autre structure...), ROM_CALLs enlevés (OSVRegister/FreeTimer...), types de paramètres différents ou affectations différentes des routines (EM_blockErase, EM_blockVerifyErase, ROM_CALL_168, 12C/HeapWalk, VarInit/is0, init_float/is1... VarInit et init_float sont tous deux réimplémentés sous des numéros différents sous AMS 2.xx, 40C pour VarInit et 3F9 pour init_float). Ceci dit, enlever certains ROM_CALLs, notamment EM_blockErase, n'était pas forcément un mal...

Ouais. J'ai pas encore compris qu'est-ce qui embêtait tant TI dans nos jeux/progs. Pourquoi s'acharnent-ils à limiter les progs à 24 ko?
Mais bon c'est vrai que tout ça est CATASTROPHIQUE!
>> Mais beaucoup trop de gens s'en tapent et voilà le résultat.
C'est vrai p*tain! Le nombre de progs STABLES que j'aie trouvé sur internet est quasiment nul! Et particulièrement pour ce qu'il s'agit des jeux. Et je me permets d'émettre cette critique car il s'agit d'une chose à laquelle je fais beaucoup attention. D'ailleurs je serais curieux de savoir si Text Walker ou Mario a déjà planté chez quelqu'un...
L'autre jour j'avais un copain qui me dit "Ton agenda il a planté!". "Super" que je lui réponds... "Et que faisais-tu juste avant de le lancer?" -- "Heu... Kirby!", "Ah ben voilà pourquoi!". Moi j'ai du réinstaller la ROM car kirby me l'a bouzillée! Un fopen plantait (allez savoir pourquoi!). Et mon agenda n'est pas à l'abri d'un fopen raté; s'il ne trouve pas le fichier, il en crée un nouveau, et s'il reçoit une adresse erronée à l'écriture, un plantage est inévitable. Heureusement que le fichier utilisé est TOUJOURS un fichier temporaire donc jamais de risque de plantage. D'ailleurs l'enregistrement se fait ainsi:
(Le fichier de base est archivé depuis belle lurette)
-On recrée le fichier TEMPoraire!
-On l'archive
-On désarchive le vrai fichier
-On copie TEMP sur vrai_fichier
-On archive vrai_fichier
-On désarchive TEMP
-On supprime TEMP
Et c'est terminé. Aucune faille possible apparemment... Mais si l'OS a suffisamment planté pour ne pas être capable de faire ces opérations...

Ouai mais pour les progs stable la plupart du temps c'est assez compliqué, puisque l'AMS peut être facteur de plantage. Le prog n'a pas été testé sur toute les ROM et encore moins sur tous les models et hardwares. AUssi dans le eadme il y a des indication comme quoi il n'a étai testé que sur telle ou telle ROM... il faut en prendre compte. Mais tu as raison, si beaucoup de programmeur ce mettait à éviter tout plantage, les programmes serait plus stable, or plus personnes juge sur calcualtrice ce travail inutile et pénible.

Mais par contre je trouve que les progs et jeux récents sont vraiment plus stable qu'avant.

C'est clair s'ils sont en _nostub, c'est généralement plus compatible qu'en mode kernel!

C'est pas forcément vrai -> cf topic kernel vs nostub pour plus de détails

Comment on fait pour rechercher des topics sur yaronet?

avec le moteur de recherche par exemple, lien en haut à droite
(enfin quand ça marche )