Recherche propriétaires de Voyage 200 et 89 Titanium pour beta-testing (Einstein) - Page 4

C'est quoi ce bordel.

Il y a aussi un autre cas qui peut créer des fichiers comme ça, c'est avec la variable "semi-système" regeq.
Bref, il faut toujours tester si le handle est non-nul, sinon, le fichier est à considérer effacé (le mieux est probablement de ne pas afficher du tout un fichier au handle nul).

OK. Je vais me plonger à nouveau dans ce code bordélique pour essayer de trouver l'endroit et la manière de corriger ça.

Comment oses-tu mettre en doute Einstein, ce génie incontesté !

./91 > Ahem!

Mais sinon pour répondre aux deux questions ^^' :

./89 > Avec SStart 1.30 et le leakwatch activé en combinaison avec CommandPost+ 2.02

./90 > Yep c'est exactement ca et je vois que ca

Personne n'a pu triturer la version compilée avec GTC encore ? Elle est ici

Dude : Spécialement pour toi : Fichier joint : esGTC.zip
Peux-tu me dire si le crash a encore lieu quand tu lances cette version à parti d'un kbdprgmX en Basic ?
Chez moi ça semble marcher

Ca marche je te teste ca
Pour la version qui est en ./83 j'ai l'impression qu'il n'y a pas de différences
Ca marche tout aussi bien, que ce soit compilé avec GTC ou TIGCC
(Faudrait peut-etre juste faire un comparatif des deux sur ton systeme de compression )

Y'as de raison que ce soit différent, en fait c'est exactement le même code source Il n'y a pas un poil d'octet de code C ou ASM qui soit différent. Seule change l'organisation des fichiers sources.

Donc la version compilée avec GTC ne plante pas ? Tu as testé à nouveau toutes les fonctions une à une et tout roule ? J'ai eu un crash bizarre ce midi. C'est peut-être le même crash que tu as eu l'autre jour avec la version TIGCC (ce qui voudrait dire que le problème vient du code et pas du compilateur).

J'ai réorganisé les sources pour qu'on voit mieux ce qui change entre GTC et TIGCC. Tu verras que la plus grosse partie des fichiers ne change pas.
Les fichiers spécifiques à chaque compilateur sont dans des dossiers séparés. Mais tu verras que seule la syntaxe ASM change dans ces fichiers (en gros : on vire les % devant les noms de registres et on remplace les ";" et les "|" par des "//", c'est à peu près tout).

http://alineasofts.free.fr/index.php?e=mc2&fichier=einstein&rubrique=Einstein

J'ai remarqué que tu as toujours des section ".data" au début de tes fichiers .asm. Ça fait longtemps (TIGCC 0.95 Beta 1) que ce n'est plus nécessaire, et ça crée quelques problèmes (par exemple le linker n'optimise pas à l'intérieur d'une section de données, et ça casse aussi si tu actives les fichiers de données externes un jour), donc je te conseille de les enlever.

OK c'est fait.

./101 & ./102 > D'accord

Pour répondre a tes questions de ./101 >
J'ai pas trop vu de changement
J'ai toujours ce probleme de kbdprgmX (et j'ai essayé avec un autre kbdprgmX recodé a peu pres pareil : variables locales, boites de dialogues, tests, affectations, suppression de vars, mais ca ne bug pas là! J'avoue ne pas comprendre d'où viens le probleme avec cette histoire de kbdprgmX...bref!)
Sinon j'ai un petit bug sur certains programmes kernels: ils ne se lancent tout simplement pas. On dirait que PreOS ne trouve pas stdlib...c'est bizzar. Je testerai ca plus en detail et te dirai
Pour la version que tu as mise en ./102 : je viens juste de la mettre sur ma calc, donc le temps que je teste un peu tout et t'aura mon rapport
J'irai voir les sources aussi si j'ai le temps

> Sinon j'ai un petit bug sur certains programmes kernels: ils ne se lancent tout simplement pas.
Eh bien c'est une bonne chose, tout le monde sait très bien que le kernel c'est moche et nul et buggé


Oui, j'avais envie de mettre une petite touche d'humour pour le vendredi soir (et non pas lancer un troll #attention"), mais ce n'est même pas drôle (même si je rigole devant mon PC en écrivant ça ^^), et je sors tout de suite

Ah si si ! Merci pour cette pointe d'humour

Dude : Normalement, la nouvelle version ne plante plus quand il y a des fichiers dont le handle est nul. C'est peut-être pour ça que tu n'arrives plus à la faire crasher ?

Lionel
(Zut! Deja parti ^^)

Thibaut > Negatif! Je viens d'essayer la nouvelle version et ce bug persiste
Tu as dû mal comprendre mon post ou alors je me suis peut-etre mal exprimé (ou les deux )
Ce que je voulais dire, c'est que j'ai un kbdprgm6 en basic qui me lance Einstein, et que si j'essais de reproduire le bug sur un kbdprgm8 réécrit sur le modèle du 6 le bug n'apparait pas
J'y comprend rien, l'un marche, l'autre non.
Pourtant a y regarder de pres on dirait que les deux sont identiques (au niveau structures (if, boites de dialogues, création de vars locales, suppression de vars, etc...) car je l'ai pas mal allégé )
Si t'as une idée...

Sinon pour revenir au Kernel je vais essayer de te trouver un cas qui marche a tous les coups pour que tu vois

OK ! C'est sympa merci

Alors, pour mon kbdprgm6 (basic) ca reste un mystere, mais par contre j'ai galéré a te trouver un exemple concret pour l'histoire de lancement de certains programmes kernels
Enfin, c'est bon je l'ai :
Essais de lancer PCT (le shell) depuis Einstein
Chez moi ca ne marche pas
Par contre je te laisse le soin de trouver pourquoi ^^

C'est un manque de mémoire peut-être ?
Je vais tester ça.

En effet, ça ne se lance pas. Aucune idée sur la raison !
Tu tournes avec la version de GTC ou de TIGCC toi ?

Dude (./110) :
Alors, pour mon kbdprgm6 (basic) ca reste un mystere,

Thibaut, testes-tu si le handle du fichier est H_NULL maintenant?

En fait je teste si le bit local est à 1 ou pas. C'est cette macro qui permet de déterminer si Einstein va insérer ou pas un fichier dans sa FAT virtuelle :

#define Affichable(fichierSE)\
        (!(fichierSE).flags.bits.hidden && (fichierSE).name[0] != '0' && !(fichierSE).flags.bits.local)

Mon cher Martial, puisque ton Tetris n'a toujours pas atterri dans ma boîte mail, j'ai niouzé sur autre chose. Ca sera prêt le week end prochain ? hein dis

Envoie-les chier ! Un Tetris est bien plus important qu'une famille !!

Pour te repondre Thibaut :
J'utilise la version que tu as postée en ./83 , puisqu'apres essais de la version que tu m'as filé en ./99 [edit] elles semblent etre sensiblement les [/edit] meme
C'est donc une version compilée avec GTC

./112 > Si ca peut t'aider a trouver une solution je crois que tous les TSRs de Flanker ne marchent pas non plus
Alors que le shell de stdlib lance tout ca tres bien