Preos 0.71 - Page 2

Pas eu le temps de regarder. Je verrais d'abord si c'est visible sous VTI.

xertu: Peux-tu tester la RC3 ? Elle est sortie ce matin, et devrait (j'espere) corriger ce probleme.
Flanker: Peux tu tester sur 92+ avec hw2patch : j'ai peur d'avoir fait un code regression pour hw2patch: installe id puis preos 0.71 RC3, puis etient la calc, enleve une pile, remet la, et rallume. Normalement pas de crash.

Voilà je l'ai testé il n'y a plus ce problème , plus de message d'erreur. Mais j'ai essayer de démarer d'autre prog pour le tester a fond mais pas possible de demarer des prog comme cf, smq zelda.... en fait je crois que aucun prog qui ont besoin d'un kernel ne marche. La calculatrice crash à chaque fois. ( sauf pour les prog nostub ) .
Dommage peut-etre une rc4.

>Mais j'ai essayer de démarer d'autre prog pour le tester a fond mais pas possible de demarer des prog comme cf, smq zelda.... en fait je crois que aucun prog qui ont besoin d'un kernel ne marche.
Y'a un message d'erreur affiche ? Ca crashe direct ?

Et si tu installes direct preos puis id, ca plante aussi ?

En fait quand j'entre le nom du prog la calculatrice reste bloqué avec ecrit sous la barre de commande BUSY.
Sinon avec preos puis id ca plante pas.

Je vais finir par me tirer une balle dans la tete
Bon je repars investiguer ce que j'ai casse.
(Mais tu peux quand meme lancer les progs _nostub ?)

>Mais tu peux quand meme lancer les progs _nostub
OUI je l'ai déjà dit.

Ce qu' il y a de bien dans preos 70-71 c'est qu'il peut faire tourner des très vieux prog comme zelda89, avec les preos 6x il y avait plein de bug c'etait injouable maintenant c'est mieux.
Comme quoi preos 70-71(rc 1-2) est bcp plus stable.

Ou plus chanceuse / malchanceuse

Ben finalement, j'ai pas trouve le bug
Flanker, tu peux essayer aussi ?

ok, je ferais ça dans l'après midi

PpHd > faudra faire un up du topic, sinon j'y penserai jamais
et ce w-e je suis rentré à Paris, donc je peux pas

xertu: Peux tu telecharger ddump et me faire un ddump avant id, apres id, et apres preos, et envoie le moi a mon adresse mail, svp.
Merci.

Voilà j'ai tout envoyer, sur le message il n'y a pas d'objet ( j'ai oublier)

Merci je l'ai recu. T'aurais pas oublie les attachements ?

Les attachements c'est bien les dumpfiles.
si oui je les ai tous renommé pour que tu t'y retrouve.

Ok bug trouve. Merci beaucoup xertu pour tous tes efforts. RC4 pour demain si j'ai le temps ce soir.

question, vu que le site est mort et que j'ai pas gardé de RC j'ai pas vérifie. est ce qu'il existe un RAM_CALL du style kernel_getSystemDir? sinon ca pourait être utile de le créer

Flanker m'a demande la meme... Je sens qu'il va falloir que je la mette.

const char *kernel__GetSystemDir();

(Chaine ANSI et pas SYM_STR) Ca irait ? (Kevin, Flanker votre opinion).

Ou mieux:

char *kernel__GetEnv(const char *name);

mais ca serait plus complique a faire... J'hesite. (Et surtout comment stocker les variables d'environnements ?)

Je me demande aussi si une simple variable ne serait pas suffisante.

La preimière me semble bien la senconde, je suis pas sur d'avoir bien compris. Tu voudrais par exemple un
char *dir = kernel__GetEnv("SYSTEM");

C'est un peu lourd si ca ne sert qu'a ca car je ne vois pas a quoi de plus ca servirait.

Ben regarde a quoi peut servir getenv sous Unix. Mais c'est vrai que ca serait plus lourd. Une variable serait simple et pas trop gourmand (~12 octets de plus)

une variable serait simple, mais par contre il faudrait pouvoir la transformer simplement en SYM_STR, qqc du genre :

 dc.b  0
kernel::GetSystemDir
 dc.b   'main',0

comme ça, un simple

 move.l  #kernel::GetSystemDir,a0
\loop:
 tst.b   (a0)+
 bne     \loop
 subq.l  #1,a0

permet de le transformer en SYM_STR

Par exemple

        lea     -20(a7),a7                              ; Stack frame
        pea     (a7)                                    ; Push stack frame ptr
        pea     (a0)                                    ; Push org lib name
        ROM_THROW StrToTokN                             ; Convert ANSI c to SYMSTR Ti 

ça fait la même chose ?
mon code est pas plus court ?

4 octets plus loin, mais sans aucune contrainte sur kernel::GetSystemDir

PpHd :
Flanker m'a demande la meme... Je sens qu'il va falloir que je la mette.

const char *kernel__GetSystemDir();

(Chaine ANSI et pas SYM_STR) Ca irait ? (Kevin, Flanker votre opinion).

Vas-y, rajoute encore un RAM_CALL, j'ai déjà abandonné tout essai d'argumentation avec toi.
L'inflation de version des dépendances continue...

Oui mais cette fois-ci j'ai ton accord

Ben regarde a quoi peut servir getenv sous Unix. Mais c'est vrai que ca serait plus lourd. Une variable serait simple et pas trop gourmand (~12 octets de plus)

Certes mais même sur pedrom ou l'emploi des variables d'environnement serait utilie, on utilise de variable TIOS classiques(Path est un liste, ...). Du coup l'interet devient relativement limité.

Kevin Kofler
:

PpHd :
Flanker m'a demande la meme... Je sens qu'il va falloir que je la mette.

const char *kernel__GetSystemDir();

(Chaine ANSI et pas SYM_STR) Ca irait ? (Kevin, Flanker votre opinion).

Vas-y, rajoute encore un RAM_CALL, j'ai déjà abandonné tout essai d'argumentation avec toi.
L'inflation de version des dépendances continue...

autant tous les rajouter d'un coup, plutôt que de faire une version par RAM_CALL rajouté