Sortie d'un explorateur de fichiers graphique : EINSTEIN - Page 5

Lancer Einstein depuis un shell? 'Faut être tordu là... (désolé nEUrOne)...

A mon avis il n'a pas fait ça Je disais ça parceque c'est la seule manière de "saturer" la pile à mon avis.
Il n'a pas parlé de plantage mais simplement de bug, donc je pense que le problème n'est pas un débordmeent de pile.

nan, il n'a pas fait ca

> j'ai uniquement créé le fichier de 10ko, lancé einstein, essayé de compressé .. et ca a planté !

Quel plantage? tu te souviens?

Ouai, si tu peux donner plus de détails ça m'aiderait.

y aurait il moyen de "cacher" a einstein les dossiers 0001 et 0002? ca ne derange pas qu'ils existent quelque part mais si on pouvait ne pas les avois dans le bureau ca serait bien. tictex ne voit pas ces dossiers, shl les voit et preos browser ne voit que le dossier 0001

Tu vois les dossiers 000x dans Einstein
Tu as bien la première version sortie publiquement (début Novembre) ?

Il serait d'une grande utilité qu'Einstein puisse, lors de son utilisation, mettre le dossier "main" comme dossier courant, car à chaque fois que cela n'est pas le cas, affiche : "einsppg not found" ... Et s'il restoré à la fin le dossier précédement utilisé se serait encore mieux !

Je vais faire mieux que ça : einsdata et einsppg pourront se trouver n'importe où, dans la version 3.1 !

Thibaut a écrit :
Tu vois les dossiers 000x dans Einstein Tu as bien la première version sortie publiquement (début Novembre) ?

oui. et sur v200 ams 2.07

Merde !
Il sont pourtant marqués twin, ou in-use

shl et preos browser me montrent le dossier 0001. et ils n'apparaisent pas (les dossiers) dans var-link.

tu testes le premier caractère du nom du dossier, si c'est '0' tu ne l'affiches pas...

Ximoon
a écrit : tu testes le premier caractère du nom du dossier, si c'est '0' tu ne l'affiches pas...

Plus généralement, si la valeur est inférieure à 'A', tu ne l'affiches pas.

Mais le mieux est d'utiliser les ROM_CALLs appropriés pour obtenir la liste des dossiers, ils sautent automatiquement ces répertoires.

ce serait pas plutot 'a' la plus petite valeur a afficher ?

Non, le code ASCII de 'a' est 97 et celui de 'A' est 65.

oui mais tout les noms de dossier sont en lowercase non ?

Ah ok, je vois ce que tu veux dire.
Oui, c'est vrai que les noms de dossiers sont en lowercase, donc c'est sûrement 'a', la plus petite lettre à afficher. Enfin, moi je resterais prudent et j'accepterais jusqu'à 'A', plutôt...

mouais, remarque je n'est pas considéré les caractères accentués, grecs et caractères spéciaux que l'AMS accepte

Le plantage:

y'a eut une fuite de mémoire de ~45ko

ARff
ta pas encore compris neurone

Comment tu croit qu'il fait pout compresser ton fichier de 9999% ?

???

lol oué godzil

Kevin > Mais le mieux est d'utiliser les ROM_CALLs appropriés pour obtenir la liste des dossiers.

C'est malheureusment trop lent si la calculatrice comporte beaucoup de dossiers ou de fichiers dans un répertoire, car c'est le même code qui liste+trie la FAT et les VATs dans Einstein : il considère les dossiers comme... des fichiers de "type" FLD ! La fonction de tri place ce type en premier, suivit des EXE, PPG, etc...

Je ne peux pas changer ça, où le support natif des sous-répertoires va se compliquer.
Je vais simplement éliminer les fichiers commençant par '0'.

les dossiers, tu veux dire

Einstein considère les dossiers comme des fichiers (dont le contenu est une VAT)

a vi, c vrai que t'utilise un truc tordus

C'est un peu dommage qu'AMS ne gère pas les sous-dossiers (ça ralentirait un peu, même si ça n'était pas très bien fait). Mais ne pas les gérer permet d'éviter des abus...
On ne peut pas faire grand chose contre la lenteur du tri. Une solution facile consiste à avoir un maximum de répertoires, idéalement un par programme. Mais beaucoup de programmeurs ne font des programmes qui ne trouvent les fichiers additionnels que s'ils sont dans main...

Je vais simplement éliminer les fichiers commençant par '0'.

Elimine tous les fichiers commençant par un code strictement inférieur à 'A' (65, 0x41), AMS considère tous ces fichiers comme temporaires:
(tiams.h) #define IsTempNameChar(c) (c <= '@')

Ok merci

> On ne peut pas faire grand chose contre la lenteur du tri.

Ce n'est pas ça qui est lent. Je me suis mal exprimé au post #143.
Tu peux tester : crée un dossier avec plein de fichiers dedans, 500 par exemple (tu peux les créer en quelques secondes avec un code Basic), tu verras qu'Einstein l'ouvre très rapidement !
Ce qui serait lent, c'est d'obtenir la liste des fichiers par une ROM_CALL (actuellement, je l'obtiens par lecture directe le la FAT).

Ce qui serait lent, c'est d'obtenir la liste des fichiers par une ROM_CALL (actuellement, je l'obtiens par lecture directe le la FAT).

Si ce que tu as fait est stable, c'est déjà bien. Car ça n'est pas propre de lire directement dans la VAT. Il me semble que c'est exactement ce que font les librairies kernel du genre filelib, qui ne font pas parties des librairies les plus stables (peut-être que c'est l'écriture dans la VAT, et pas la lecture, qui plante)...