[mOved] PedroM - Nom de fichiers longs - Page 1

Voila ce que je propose pour les noms de fichiers longs :

SYM_ENTRY.name = 'hd@XXXX'
etc.
Avec hd@xxxx un nom special. xxxx est l'handle contenant le nom complet et reel du fichier.
Ca marchera avec les programmes actuels correctement, et on pourra utiliser les noms longs.

Question: Est-ce que je dois reexporter des fonctions de VAT, ou faire en sorte que les fonctions de VAT traduisent cela a la volee ? (Pb compatibilite).


Evolution: Le faire dans la table folder pourrait servir a faire des sous-dossiers en utilisant des noms de fichiers longs pour les dossiers ('home\bin' et 'home\temp' et 'home' sont 3 fichiers a la racine de Home Folder).

Je pense que de traduire ça à la volee serait intressant mais comme tu le dit il risque d'avoir des noms d'incompatibilité et donc faut voir.

Mais c'est vraiment interessant.

Enfoiré il va falloir que j'adapte TIM! Au moins je saurais quoi faire de la place que j'avais en trop sur TI92+ en mode liste
Utilser un Handle supplémentaire par fichier c'est pas un peu violent?
Je pense en effet qu'il suffirait de rajouter une fonction du style: char *SYM_LongName(SYM_ENTRY)

un handle de plus par fichier, ca me parait assez lourd aussi
sinon, c une bonne idée

C'est compatible. Mais y'a un gros probleme : C pas compatible avec les archives !
...
Je vais revoir ma copie. Si vous avez des idees.

Pourquoi pas faire 2 VAT, une de l'AMS fichiers avec des noms court et une avec des fichiers long?

Les shells qui seront développé liront le contenus de la VAT2 et la compatibilitée serat assuré avec la VAT1 celle de l'AMS. Mais bon faut pas que ça prennent beaucoup de place? Une VAT ne contient que des pointeurs.... Donc je pense que c'est une bonne méthode mais bon il y a des contraintes?

Le problème c'est que les fichiers de la VAT2 seraient invisibles pour les shell utilisant la VAT1. non moi je pense que l'idée de PpHd n'était pas mauvaise. sauf qu'au lieu de créer un handle par fichier j'aurais mis une référence dans une table des noms de fichiers. Et j'aurais gardé les ancien ROMCALLS il arrait juste fallu rajouter 2 ROMCALLS genre:
char *SYM_GetLongName(SYM_ENTRY)
void SYM_SetLongName(SYM_ENTRY, char*)

est-ce bien utils les noms long ???

Je vois pas le problème, ça évite des incompatibilité car le shell qui utilise des noms court ne dois surtout pas avoir des noms long à la place car il n'as pas était développé dans cette objectif et donc les noms sortiront de l'écran....

Je pense qu'il faut faire un peu comme Windows le fait avec MS-Dos, les programmes crée dans la VAT2 seront ajouté dans la VAT1 mais en coupant les noms avec un caractère du genre -puis suivit d'un chiffre.... Les programmes ancien utiliseront la VAT1 et les nouveau la VAT2....

est-ce bien utils les noms long ???

C'est aussi la question que je me pose, mais tant que ca reste compatible, pourquoi pas.

bah... ça prend de la place dans la (les) vat.

Bas c'est juste des pointeur... Donc perdre quelque petit ko je ne voit pas que ça prend énormément de place, surtout qu'on est sur pedrom et donc on as assez d'espace pour faire certaine choses.

Faut surtout voir ça avec Pphp au point de vue de la compatibilitée et surtout de l'implantation.

ué, mais c pas pasque y a plein de place qu'il faut la gaspiller avec des truc assez peu utiles. Surtout quand ça risques de créer des problèmes.

Pour moi c'est assez utile et ça prend pas beaucoup de place en soit donc je ne voit pas pourquoi ne pas développer ce genre de fonction, Pedrom ce rapproche de l'AMS mais faut pas qu'il devient identique à l'AMS. Pedrom au contraire doit intégrer ce genre de fonction et faciliter la vie au programmeur car les noms de fichiers longs sont assez utile surtout pour classer des cours....

pour classer des cours, y a des dossiers
La gestions des sous-dossiers seraient plus utils que les nom longs. Enfin bon, si PpHd juge sa utile, je v pas l'empécher de le faire

Ca ce discute mais je trouve ça vraiment interessant et je jugfe ça très utile.
Je trouve que ceux qui on développer un shell sont contre cette idée car tout simplement ils n'on pas envie de modifier leur programme????

Pour la question d'incompatibilité si on utilise 2 VATs, il ne devrait pas en avoir....

>>Je trouve que ceux qui on développer un shell sont contre cette idée car tout simplement ils n'on pas envie de modifier leur programme????

Ca pourrait être un argument, en effet

PpHd a écrit :
SYM_ENTRY.name = 'hd@XXXX'
etc.
Avec hd@xxxx un nom special. xxxx est l'handle contenant le nom complet et reel du fichier. Ca marchera avec les programmes actuels correctement, et on pourra utiliser les noms longs.

Et si on efface un fichier avec un shell qui accède à la VAT directement (en utilisant les RAM_CALLs exporté par un kernel, comme (au hasard) PreOs ), on leake de la mémoire.

Bref, cette méthode marcherait si les programmes utilisaient les ROM_CALLs proprement pour accéder à la RAM. Hélas, à cause des kernels, elle ne marchera pas.

vbrai que la gestion des sous-repertoires serait plus prioritaire, à mes yeux, que les noms longs...

Mais 2 VATs serait l'idéal, celle de l'AMS pour la compatibilitée et celle de pedrom avec des noms long et sous dossiers mais reste un problème pour les programmes crées dans les sous dossiers? Je pense que si on veut une compatibilitée parfaite, il faut faire 2 VATs mais les fonctions de modification de la VAT2 ne seront pas identique au fonctions de l'AMS.

Et si on efface un fichier avec un shell qui accède à la VAT directement (en utilisant les RAM_CALLs exporté par un kernel, comme (au hasard) PreOs ), on leake de la mémoire. Bref, cette méthode marcherait si les programmes utilisaient les ROM_CALLs proprement pour accéder à la RAM. Hélas, à cause des kernels, elle ne marchera pas.

C'est en effet un problème: il faudrait que le clean vérifie aussi les références et supprime celles qui ne sont plus valides.

geogeo
a écrit : Mais 2 VATs serait l'idéal, celle de l'AMS pour la compatibilitée et celle de pedrom avec des noms long et sous dossiers mais reste un problème pour les programmes crées dans les sous dossiers? Je pense que si on veut une compatibilitée parfaite, il faut faire 2 VATs mais les fonctions de modification de la VAT2 ne seront pas identique au fonctions de l'AMS.

Ça ne marchera pas à cause des !"§$%&/()=? de kernels qui permettent l'accès direct à la VAT, ce qui désynchroniserait les 2 VATs très rapidement.

Il suffit de modifier PreOS dans PedroM pour qu'il renvois vers le rom_call, nan ??

dans ce cas la non vu qu'il y aurait 2 VAT. De toute facon je suis convaincu que 2 VAT n'est pas le meilleur système.

Faut trouver d'autres solutions et surtout c'est à PpHd de prend celle qui lui semble le mieux.

PpHd, il me semble que ça fait 2 fois que tu fais l'erreur.

MacIntoc
a écrit : est-ce bien utils les noms long ???

Pareil

Noms longs / sous-dossier : meme combat (Cf premier post).
Les sous-dossiers seront des noms long a la racine des dossiers.

Autre idee:
Pour chaque variable:
Size.w / Data / Tag / SignatureNomLong / Nom.

Ca marchera relativement bien si je mets a jour PedroM. Le seul probleme est que si quelqu'un fait une copie directement des fichiers, les noms de fichiers longs seront perdus (Signature cassee). Pas si grave.
Par contre, en link, en envoyant de PedroM a PedroM, on garde les noms longs

Vous en pensez quoi ?

certes mais comment tu compte gérer les répertoires avec cette méthode?

Les repertoires ont des noms fichiers longs a la racine. Au lieu de sauver 'local', on sauve comme nom 'usr/local'