Sortie officielle de PreOs 0.62 - Page 2

> Ce qui me gêne le plus c'est qu'on répandent l'idée que les programmes pour kernel plantent plus souvent que les programmes en _nostub. Si on compare des programmes pour kernel qui ont été programmés il y a plus de 2 ans, et les programmes _nostub actuels, c'est complétement idiot.

D'accord.
Mais c'est un fait difficilement discutable que beaucoup de programmes kernels plantent de façon grave souvent, et que peu de programmes _nostub obligent à des resets fréquents. Je sais de quoi je parle pour avoir vu mes camarades pester contre DoorsOS et en avoir fait moi-même l'expérience au moment où je ne connaissais rien à ma calculette (oui, j'ai installé des kernels il y a bientôt 2 ans; le nombre de bugs me les a fait désinstaller prestement)...

Bien sûr, beaucoup de programmes kernels ont été écrits il y a longtemps, au moment où la calculette était encore mal connue, et ils risquent donc plus de planter que les programmes _nostub écrits plus récemment (qui eux, sont à jour au point protection HW2 et toutes les réjouissances plus récentes de TI). Il y a un certain nombre de kernels / de programmes sous kernel qui ne marchent même pas sous les AMS 2.xx !
Les kernels sont des reliquats du temps où on ne connaissait pas/mal les ROM_CALLs (ça ne date pas d'hier).

Cela n'enlève rien au fait que ceux qui ont programmé/programment les kernels sont doués pour la programmation.

squale92: tu utilises quels programmes _nostub pour avoir à effectuer des hot reboots ??

et les programmes kernels sont souvent codé en ASM, alors que les programmes nostub sont souvent codés en C !!!
et en ASM, on a plus de chances de se planter, vu que ce n'est pas un compilo qui fait pas mal de choses !

pas mal de progs nostub que j'utilise et qui me forcent au hot-reboot sont ceux que jk'écrais, entre autres
(faut dire que je suis pas super fort en ASM => asm on-calc, je suis bien content d'avoir preOS )

Bref, arrêtez de dire que le mode kernel est à bannir parcequ'il est instable

superware: JM a bosse dur sur txtrider pour qu'Unios evite les configurations memoire ou txtrider plante. Bref, il a decortique les bugs de txtrider et fait en sorte qu'ils n'arrivent pas. Je n'ai pas passe du temps sur comment corriger txtrider pour qu'il marche (Je vais finir par le dessassembler !)

Pourquoi perdre son temps avec TxtRider? Il suffit d'utiliser HibText à la place! Et il est donné avec la source, lui.

Euh... je n'ai rien fait pour que txtrider marche

Il m'est déjà arrivé de faire en sorte que tel ou tel programme programme marche, mais pas celui-là. En fait, il n'y en a qu'un seul, qui utilisait incorrectement gray4lib, mais je n'ai jamais forcé les choses : j'ai juste implémenté gray4lib d'une manière un peu particulière, tout en respectant toutes les normes.

Mais il est vrai que j'ai bossé sur txtrider pour Universal OS. Et ce n'est pas le seul problème. Au moindre problème que je rencontrais lors de l'utilisation d'un programme, je cherchais le bug et je corrigeais Universal OS s'il s'y trouvait.

>Euh... je n'ai rien fait pour que txtrider marche
bouhh, fallait pas casser le mythe !

Bouh, pkoi avoir sorti une mise a jour d'unios alors (v1.30).
Bouh, au boulot.

> pas mal de progs nostub que j'utilise et qui me forcent au hot-reboot sont ceux que jk'écrais, entre autres
OK. Je ne fais pas d'ASM on-calc, donc c'est sûr que je ne crains pas d'avoir ce problème...

Et c'est plus intéressant d'utiliser Hib-Text que TxtRider, car Hib-Text est stable, lui.

PpHd, tu parles de "Test de la touche [ON] dans l'AI6, autoint qui semble aussi déclenchée lorsque les piles sont faibles." ?
Le bug n'était pas de txtrider mais d'Universal OS.

XDanger> lol

moi, je n'ai JAMAIS eu de pb avec TxtRider...
(du moins en le lançant de la ligne de cd)

Crois-moi si tu veux, mais je n'ai jamais réussi à lire un texte avec txtrider sur DoorsOS II 0.98 (j'ai essayé plusieurs fois), pas plus sur les calculettes de mes camarades que sur ma VTI !

arf, bizarre...
mais bon, maintenant, DoorsOS est plus que largement dépassé

C'est clair que txtrider a tjrs marché normalement, le seul et unique bug que j'ai eu est que ça quite lorsque on descend vite ds le marque page.

Txtrider fait des access a des vars globales non geres par le kernel

Donc ne te reste plus qu'à lui permettre ?

A trouver les equivalents , oui.

à coups de désassembleur !!! et en plus il parait que txtrider est tres mal codé !

Normal, c'est un programme pour kernel.

"Programme pour kernel" ... je me marre

kevin inside

> et en plus il parait que txtrider est tres mal codé
Ca c'est assez vrai. Et le fait qu'il soit sous kernel n'arrange rien. Je n'ai peut-être pas eu de chance, mais je vous redis que je n'ai jamais réussi à lire un texte avec txtrider, alors que j'ai essayé quatre fois avec hibtext: ça a marché trois fois (la fois où ça a raté, c'était que le texte était trop gros, le bug a été reporté à hibou et corrigé; txtrider faisait pire)...

Voici un bug apparu sur la calculette d'un de mes camarades (peut-être dû à txtrider)... Il a dû faire un reset complet car sa calculette était bloquée dans l'écran WINDOW, avec les paramètres décrits ci-dessous. Tout appui à une touche du clavier déclenchait 'Protected memory violation'. Je lui ai dit la vérité: son problème venait du kernel...
Variables:
xmin = 0. (pour le moment, rien d'anormal...)
xmax = 0.0212490002125E-7032. (les fonctions de floating-point sont-elles censées laisser de tels nombres ?)
xscl = 2.4:0002124:8002E-1635? (est-ce un nombre ?) Le ? à droite indique que le chiffre était en-dehors de l'écran de la 89...
ymin = 0.02124;8002124<E-6992. (est-ce un nombre ?)
ymax = <.<76002124=>E-16381. (est-ce un nombre ?)
yscl = 0.003<=1<0003<<=E1108. (est-ce un nombre ?)
xres = 0. (est-ce une valeur valide pour xres ?).

Comme vous pouvez le constater, ça ressemble fort aux vecteurs d'exception d'AMS 2.xx (c'était une 2.05 avec probablement DoorsOS II 0.98).

TxtRider doit avoir mis à 0 le pointeur utilisé par AMS pour accéder à ces variables système...
Et un bogue de plus... À rajouter aux écrans bleus et autres problèmes divers...

c'est moi ou le site de la T3 est down?

Chez moi il marche bien...

oui maintenant il marche a nouveau chez moi aussi

Correction d'un bug de genlib dans stdlib.
XDanger: Dis leur de passer a preos 0.62

lol... certain programmes de la tigcc ^ tict sont bien moins programmé que certains prog kernel... alors bon l'excuse kernel => mauvais programme
c'est un peu se foutre de la gueule du monde surtout quand on voit certains code!

je suis d'accord avec timad