PpHd Le 26/08/2003 à 17:16 Voila,
J'aimerais un petit debat sur le format de fichiers longs (>64Kb) pour PedroM.
Les contraintes:
1. Fichier > 64 Kb.
2. Les programmes existants ne doivent pas planter a cause de cela.
3. Compatibilite archive/Heap.
4. Transfert de fichiers sur la ti. Reception on-pc.
+++++++++++++++++++++++++++++++++++++++++++
Ce que je propose:
Format:
0x00,0x02,0x00,0xZZ,0x00,0xF8
Puis: Size.l
Puis le programme.
A la rigeur ZZ peut etre le TAG du programme.
Transfert de fichiers:
1. Auto decoupage en fichier de type personnalises on-pc.
2. Auto recollage apres reception des fichiers on-calc.
Alors ? Plus simple ? Des problemes? Faites fonctionner votre cervelle.
>4. Transfert de fichiers sur la ti. Reception on-pc.
Est ce que les logs ti verifie la taille ou c' est la calc qui le refuse ?
si ce n' est que les logs ce sera modifiable.
PpHd Le 27/08/2003 à 12:41 Le protocole de Ti du link ne supporte pas les fichiers de + de 64K. En effet, la taille d'un paquet de donnee est au max de 64K, et on ne peut envoyer plusieurs paquets sans creer pas mal de problemes avec les programmes de links.
comment ça serait en archive ? les fichiers sont aussi limités à 64ko, non ?
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
Je fais sûrement une erreur, mais il me semble que ce serait plutôt ça :
0x00,0x02,0x00,0xZZ,0xF8
Sinon, dans ton cas, le TIOS penserait que le tag est 0x00, non ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
je dirais plutôt
00 04 00 ZZ 00 F8
(où ZZ est une valeur hexa)
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
j'aimerais quand même bien savoir comment ça sera en archive. Si on écrit à la bourrin à cheval sur deux secteurs, ça risque d'être un peu le bordel pour faire un garbage, non ?
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
peut etre en splitant le fichier au moment de l'archiver?
Et si le fichier dépasse 128 ko ?
PpHd Le 02/09/2003 à 08:46 Il n'y aura aucun probleme pour l'archivage. La routine de GC se chargera de gerer ces fichiers comme il faut.
Je comptais specifier mettre un entete de secteur specifiant le nombre de secteur reserves. Enfin, tout ca pour dire que je pourrais toujours m'arranger avec la routine de GC.
PpHd > Je pense que l'idée est bonne, le seul problème c'est que tu va avoir un Kevin qui va te geuler apres parce que c'est incompatible avec AMS....
Sinon il faudrait trouver un moyen (enfin sa doit pas etre dur) pour pouvoir gerer ses fichiers sur PC, cad les générer, si on a aucun programmes qui le fasse (il me semble que TIGCC geule si sa dépasse 64Ko) sa ne servirait a rien.. Faire un "splitteur" on PC sa pourrait etre bien interessant
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
PpHd Le 02/09/2003 à 15:42 Bien sur. On-pc, ca sera plusieurs fichiers separes. Seulement on-calc, ca sera lineaire. Mais je suis pas sur de le faire. C'est pas facile. Et j'ai du boulot.
PpHd Le 03/09/2003 à 09:04 Vu votre motivation, je laisse tomber.
Moi sa m'interesse... mais bon apriori pas bcp de personne n'ose donner des idée pour PedroM...
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
PpHd Le 03/09/2003 à 15:13 A la rigueur, si je suis motive, je ferrais les fichiers longs, les noms longs, les repertoires hierarchique et les raccourcis dans une FAT differente de la VAT avec d'autres fonctions pour la gerer.
Mais bon, flemme.
Le bug des TI-89 HW1 est résolu au fait ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Uther Le 03/09/2003 à 21:47 Disons que je suis interessé mais je n'ai pas énormément d'idée sur la question d'autant que j'ai encore des lacune sur la gestion des variable et de la VAT TI.
PpHd Le 04/09/2003 à 09:19 Comme j'ai dit, je ferais un truc totalement incompatible, et puis voila. Une nouvelle FAT. C'est le mieux, je pense.
Une nouvelle VAT ? Elle apporterait quoi de neuf par rapport à l'ancienne ? Les sous-répertoires peuvent être gérés sans aucune modification.
Pour la gestion de l'archive, j'ai l'impression que ça va être un gros bordel, non ? Si 2 fichiers de + de 64ko occupent 3 secteurs, comment on pourrait faire le garbage ?
Ou alors, il faut abandonner complètement le coup de la sectorisation de l'archive et refaire un truc qui ressemble au heapcompress de la RAM. Je pense que c'est carrément plus simple à implémenter que le garbage actuel (pas d'algo d'optimisation à écrire) et cela permettrait de supporter les fichiers longs sans pb.
Par contre, cela va augmenter le temps du garbage si peu de fichiers sont effacés et beaucoup archivés.
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)
<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant
PpHd Le 08/09/2003 à 09:07 1. Faux, les sous-repertoires ne peuvent pas etre gerer sans modification: tous les programmes assument que les entrees d'un folder sont des fichiers et non un folder. Tu ne verras jamais un programme teste le bit folder d'une entree d'un folder. Et le folder racine ne peut pas contenir de fichiers.
2. Le garbage, ben je me demerderais. C'est pas si complique.
