Integrated Desktop - Page 5

Bon, je suis désolé, je mets du temps, mais c'est parce que je galère vraiment à débugger... J'ai passé 1 heure à trouver un bug tout bête (une erreur bête de ma part).
J'espère finir pour ce soir.
Pour l'instant, apparemment la fonction d'ajout d'entrée marche. Il ne me reste plus que la fonction "changer le commentaire", puis je sors la béta.

jackiechan : chouette

croustx a écrit :
Bon, moi aussi g un bug :
J'installe ID, pas de problème, mais quand j'installe PreOS juste après : plantage ("busy" sans rien de +)

Mmm. Quel version de PreOS ? Seul ID est installé avant de mettre PreOS ? Ca le fait à chaque fois ? Quelle base de données tu utilises et quels sont les progs de BDD qui sont sur ta calc ?

J'ai trouvé ce qui fait ramer le Desktop quand on a plein de fichiers texte dessus, c'est leur routine de tri alphabétique en bubble sort

Tu sais bien qu'ils sont tous excellents les algorithmes utilisés dans AMS...

ExtendeD a écrit :
Mmm. Quel version de PreOS ?

La dernière

Seul ID est installé avant de mettre PreOS ?

Oui

Ca le fait à chaque fois ?

nan

Quelle base de données tu utilises et quels sont les progs de BDD qui sont sur ta calc ?

A vrai dire, aucun pour le moment

ExtendeD a écrit :
J'ai trouvé ce qui fait ramer le Desktop quand on a plein de fichiers texte dessus, c'est leur routine de tri alphabétique en bubble sort

Et pas moyen de trier le tout toi-même? BubbleSort est rapide (O(n)) quand l'entrée est déjà triée.

J'arrive pas à trouver un hack pour intercepter le tri.

Et ils font un HeapDeref() toutes les 3 lignes pour trouver le pointeur sur la liste du dossier 'All', je sais pas comment ils ont codé ça pour que ça fasse ça, c'est allucinant.

erf...
une "erreur de conception" de plus dans la ROM ?

Peut-être que c'est une variable locale dont la visibilité est restreinte à une seule boucle, mais c'est stupide. Ils ne doivent de toute façon jamais regarder le code en assembleur (sinon ils se seraient peut-être rendus compte que le compilateur utilisé est tout simplement une honte à la programmation)...
GCC (et sûrement GTC) ne sont pas toujours très fins, car aucun compilateur n'est parfait; mais ils sont quand même plus fins que le compilateur de TIFS... Notamment, je n'ai jamais vu de branchements stupides avec TIGCC...

Kevin : ce que je peux faire c'est trier directement la liste chaînée des ACB au rafraîchissement du Desktop.
Mais pourquoi le bubble sort est en O(n) pour les listes triées ? il y a toujours les 2 boucles for imbriquées. La seule différence est qu'il n'y a pas de swap des 2 objets, non ? (et c'est pas ça qui prend du temps, c'est plutôt l'OO_getAppAttr x 2 et le stricmp sur les titres, ainsi que le recomptage du nombre d'apps installées à chaque fin de la plus grand boucle for alors qu'il n'a pas changé !).

Une implémentation de BubbleSort codée avec le minimum d'intelligence parcourt une seule fois le tout quand les données sont déjà triées, constate qu'il n'y avait aucun échange à faire dès le premier passage et laisse tomber. Mais ils doivent avoir fait une implémentation complètement idiote chez TI.

Ils sortent d'où leurs programmeurs

> ils font un HeapDeref() toutes les 3 lignes pour trouver le pointeur sur la liste du dossier 'All'
Je pense à une macro du genre :
#define GetDesktopFolderPtr(folder) ((DesktopFolder *)HeapDeref(folder))
Ca me semble probable

Certaines parties d'AMS sont mieux codees en ASM que d'autres. Comme s'ils ne compilaient pas AMS avec les meme options partout. Par ex, les rom_calls MD5_* sont correctes.

Meme si on y trouve une perle :
move.l 4(a7),d0
move.l 8(a7),d1
rol.l d1,d0
rts
(Remarque, ceci est pardonnable si on reflechit un minimum.)

Ben oui, ils ont été obligés d'utiliser une procédure à part pour le rotate parce que le C ne le gère pas. Et comme leur compilateur ne permet pas le passage par registres (vive TIGCC ), c'est le mieux qu'ils pouvaient faire.

Je suis prêt à parier que le fait de recompiler AMS avec GCC peut faire gagner au moins une dizaine de 10 KO...
C'est hallucinant le nombre de trucs que GCC a et que le compilateur de TIFS n'a pas... GTC sera peut-être meilleur que le compilateur de TIFS, d'ailleurs (même si on ne peut pas vraiment comparer un programme en ASM et un OS complet...)

Certaines parties d'AMS sont mieux codees en ASM que d'autres. Comme s'ils ne compilaient pas AMS avec les meme options partout. Par ex, les rom_calls MD5_* sont correctes.

C'est peut-être en partie parce que les sources du MD5 sont publics... Il se peut qu'ils aient (presque / en partie) recopié le source ASM d'une implémentation disponible publiquement...

Les fonctions de chaînes de caractères et de copie/déplacement de blocs sont suffisament bien codées pour qu'on puisse dire qu'ils l'ont fait en assembleur.

En effet, certaines fonctions sont bien faites.
Mais memset contient une horreur dans les branchements qui serait plutôt plus digne d'un compilateur (et ce n'est pas la seule fonction qui contient cela, PpHd avait parlé de cela dans son coup de gueule sur AMS 2.08)...
bne.s __continue__
bra.s __end
continue:
...
end:
movem.l (sp)+,....
(unlk a6)
rts...

Les romcalls : er_* / longjmp / meme* /str* font parties de la lib statique offerte par motorola. Donc ca reste correct.

Voilà, j'ai enfin sorti mon prog : ID-Editor.
Je suis désolé d'avoir mis autant de tps, mais il me restait quelques bugs assez désagréables (Merci ExtendeD)...

Si vous n'arrivez pas à télécharger le fichier à cause du test de referrer de Lycos, voilà la solution:
wget --referer=http://membres.lycos.fr/jackiechan/index.html http://membres.lycos.fr/jackiechan/IDEditor.zip

C'est ça qui ne marche pas??? Ca marche comment, ça empêche de mettre des liens à l'extérieur? Avant ça marchait pourtant...

Tant pis, j'ai mis un lien vers le site. Comme ça on peut le télécharger du site.

Au fait, j'espère que tu définis SET_FILE_IN_USE_BIT... Parce que sinon, il va y avoir de gros ennuis avec les boîtes de dialogues qui effacent la copie en RAM du programme en cours d'utilisation s'il est archivé. Cf. http://tigcc.ticalc.org/doc/httigcc.html#advanced_fileinuse (il faut aussi avoir une version suffisante de TIGCC - 0.94 bêta 21 minimum - pour que ça marche).

Ah. Bah c'était ça en fait, le bug dont je te parlais en mini-msg...
Mais en mettant SET_FILE_IN_USE_BIT, ça ne change rien (ça bugge autant), il faut quand même que je recalcule l'adresse de la structure SYM_ENTRY pour que ça ne plante plus.
Donc sans le SET_FILE_IN_USE_BIT, mais en recalculant l'adresse de la structure SYM_ENTRY, ça marche. Je dois quand même mettre SET_FILE_IN_USE_BIT ?

jackiechan a écrit :
Ah. Bah c'était ça en fait, le bug dont je te parlais en mini-msg...
Mais en mettant SET_FILE_IN_USE_BIT, ça ne change rien (ça bugge autant), il faut quand même que je recalcule l'adresse de la structure SYM_ENTRY pour que ça ne plante plus. Donc sans le SET_FILE_IN_USE_BIT, mais en recalculant l'adresse de la structure SYM_ENTRY, ça marche. Je dois quand même mettre SET_FILE_IN_USE_BIT ?

Oui. Le bogue dont je te parle n'a rien à voir avec l'adresse de la structure SYM_ENTRY (qui d'ailleurs peut aussi être changée par autre chose que ça, il ne faut jamais laisser traîner un pointeur SYM_ENTRY à travers des instructions qui pourraient causer une réorganisation de la RAM (heap compression), à moins d'avoir verrouillé les blocs de la VAT avec FolderOp avant; c'est pour ça que tu as toujours ce bogue-là avec SET_FILE_IN_USE_BIT; mais évidemment la suppression de fichiers change aussi les pointeurs SYM_ENTRY), mais le problème est que le programme est effacé de la RAM avant que son exécution soit finie! Donc, la prochaine fois qu'un bloc est alloué, il peut écraser une partie de ton programme, d'où plantage.

ok, c'est corrigé

y a une bonne ame charitable pour me donner un lien pour la derniere rom sur 92+ merci

Kevin Kofler a écrit :
Une implémentation de BubbleSort codée avec le minimum d'intelligence parcourt une seule fois le tout quand les données sont déjà triées, constate qu'il n'y avait aucun échange à faire dès le premier passage et laisse tomber. Mais ils doivent avoir fait une implémentation complètement idiote chez TI.

Il me semble qu'un tri qui utilise 2 for n'est pas un bubble, mais un tri ripple qui a "l'avantage" d'avoir tjrs un temps d'execution constant

Sinon un buble normalement contient une boucle infinie, suivit d'un for et la boucle infinie est cassé a partir du moment ou il n'y a pas eu d'échanges.

Ben la boucle infini peut être remplacé par un for si on connai à l'avance le nombre d'éléments à trier!!!
Ce qui m'etonnerait sur une TI