Re: Ada.Directories

Le 3 nov. 07 à 08:21, Jean-Pierre Rosen a écrit :

> Thomas De Contes a écrit :
>
>> quelques questions et commentaires sur Ada.Directories


>> Pourquoi [...]
> La définition d'un tel paquetage est toujours un compromis délicat  
> entre
> utilisabilité et portabilité. Si ce paquetage n'a été introduit qu'en
> Ada 2005, c'est que l'on trouvait qu'il était trop difficile de  
> définir
> quelque chose de suffisemment portable. Et les gens qui ont fait ce
> paquetage connaissaient bien de nombreux OS!

ok :-)

Je pose les questions qui me viennent naturellement, mais de toutes  
façons je vais me débrouiller pour utiliser ce paquetage en l'état :-)
Si t'as pas le temps de répondre à tous mes messages, mets celui là  
en dernier, stp :-)


>>
>> portabilité :
>>
>> J'aimerais faire l'application la plus portable possible, mais j'ai
>> un peu de mal à savoir quoi faire
> Si l'on veut *vraiment* être portable, c'est très difficile. Si  
> l'on se
> limite à quelques systèmes (Windows, Unix) on y arrive assez bien.

ok :-)
bon ben, je crois que je vais commencer comme ça, et je verrai si on  
me rapporte des bugs :-)

> Je ne
> connais pas le problème du Mac.

je crois que dans la plupart des cas c'est suffisant de le considérer  
comme un unix
(je crois qu'il n'y a pas de compilateur pour mac os 9, en tout cas  
moi je ne m'en occupe plus)

>
>> Quand on veut utiliser dossier/sous-dossier/ , apparemment il ne faut
>> surtout pas utiliser cette chaîne telle quelle dans les sous
>> programmes de Ada.Directories, mais il faut la construire :
>> Compose(Compose( Current_Directory , "dossier" ), "sous-dossier" )
>>
>> Sinon, par exemple avec Create_Path, sous windows on risquerait de se
>> retrouver avec un dossier qui s'appelle "dossier/sous-dossier/"
> Ne pas oublier que sous certains systèmes (VMS), ce n'est pas un  
> simple
> caractère qui sépare les dossiers: la partie "répertoires" est mise
> entre crochets.

ok, donc c'est impératif


>
>> Il y a Dir_Seps , mais apparemment il est très très peu utilisé
> ?? Pas dans Directories

pardon, c'était dans le corps,
et j'ai oublié que t'es sous windows, donc peut être qu'en plus t'as  
pas le même corps que moi

>
>> Donc finalement, ce qu'il y a à faire,
>> c'est de ne jamais utiliser dans un nom des caractères qui peuvent
>> éventuellement être utilisés comme séparateurs (il n'y a que '/' et
>> '\' ?), et ne jamais les utiliser directement comme séparateurs non
>> plus ?
> Pour Dos et Unix, il faut au moins ajouter ';', ':', éventuellement  
> '$'
> et '%', '<', '>'.

Alors, sous unix, ':' par exemple, ça va poser de gros pbs si ça se  
retrouve dans le PATH,
mais il me semble qu'au niveau du noyau il n'y a que '/' et ASCII.NUL  
qui soient interdits dans le nom d'un fichier
D'ailleurs la fonction Is_Valid_Simple_Name est formelle là dessus,  
tous les autres caractères sont autorisés

(En fait, sur chaque système, gnat doit autoriser tout ce qui est  
autorisé par le système, pour que ceux qui se fichent de la  
portabilité puissent faire ce qu'ils veulent ?)

Les autres c'est à cause des shells, je suppose ?

> Si on ajoute VMS, il y en a d'autres.

(il y a encore bcp de gens qui utilisent vms ? j'en ai jamais entendu  
parler ailleurs qu'ici)

>
>> En fait, je crois que ce qu'il y a de plus compliqué, c'est le fait
>> qu'on peut se retrouver sur une plate-forme donnée avec un fichier
>> dont le nom contient un caractère qui sert de séparateur sur une
>> autre plate-forme
> Oui. En pratique, les lettres, chiffres, '-' et '_' sont sûrs (et à  
> mon
> avis suffisants).

> Le reste est potentiellement dangereux.

même '.' et ' ' ?


>
>> D'ailleurs, ça serait bien d'avoir qqch qui nous donne la racine,
>> puisque c'est dépendant de la plate-forme
> C'est quoi, la racine?

bon en fait c'est pas grave, parce que finalement c'est pas très  
propre de "ranger" des choses à la racine :-)

> En Dos, il y en a une par disque.

ah bon, je pensais simplement au disque de démarrage
(c'est quand même un disque spécial pour le système, puisque c'est  
sur celui ci qu'il est installé, ça je crois pas que ça puisse être  
dépendant de l'OS)

> Et même en
> Unix, il peut y en avoir plusieurs, si l'on considère les chroot.

ah bon ?
Je croyais qu'un logiciel à un moment donné avait une seule racine,  
qui peut correspondre à des endroits différents du disque dur selon  
les chroot qui ont été faits avant (non ?)
(Mais bon je connais pas bien chroot)

>
>> Et même, si c'était possible, les chemins qui nous indiquent
>> directement là où mettre les préférences des applications, etc
>> (Par exemple, les préférences sous mac os x c'est ~/Library/
>> Preferences/)
> Là, il faut abandonner tout espoir de portabilité!

Ah bon alors tant pis, j'abandonne l'idée de m'adapter au maximum à  
chaque système, pour l'instant

Est ce qu'il y a d'autres chemins "de référence" qu'on peut obtenir  
de manière portable, que
- Current_Directory
(Est ce qu'on est sur que cette fonction renvoie tjr un dossier  
existant, et *jamais* d'erreur, quelles que soient les circonstances  
(et bien sur quel que soit l'OS) ?)
- Containing_Directory( Ada.Command_Line.Command_Name ) , qui donne  
le dossier qui contient l'application
?

>
>> Je suis sous mac os x, avec un systeme de fichier qui est case-
>> insensitive,
>> Mais si on crée un fichier avec des majuscules et des minuscules
>> mélangées, il s'en souvient
>> Simplement on peur relire le fichier en indiquant d'autres majuscules
>> et minuscules
> Pareil sous Dos
>>
>> J'ai Ada.Directories.Validity "the POSIX version of this package"
>> avec Is_Path_Name_Case_Sensitive return True;
> ?? Pas vu ça dans la norme

Excuses moi, j'ai fait un très très gros raccourci à base de mots clé  
ada, pour dire que chez moi la fonction Is_Path_Name_Case_Sensitive  
renvoie True :-)

Bon ben, je sais pas sous quels systèmes ça renvoie False, mais si  
c'est exprès, en l'état ça va :-)

(C'est bête, simplement, qu'on ne puisse pas se servir de  
Is_Path_Name_Case_Sensitive pour savoir si "unfichier" et "unFichier"  
désignent le même fichier ou pas)


>
>> ergonomie :
>>
>> Je trouve que les procédures pour "partir à la recherche" du contenu
>> d'un dossier sont assez lourdes à utiliser
>> (pas vous ?)
> C'est un schéma d'itérateur très classique.

ah
en fait je vois pas tellement l'intérêt d'un itérateur
(mais bon, j'ai pas encore tout vu, je comprendrai probablement plus  
tard)

>
>> Pourquoi ne pas avoir fait tout simplement une fonction qui renvoie
>> un tableau d'Unbounded_String ?
> Et si on a des dizaines de milliers de fichiers?

Ca arrive, d'avoir des dizaines de milliers de fichiers dans le même  
dossier ??
souvent ?

En fait, dans ce cas là, je vois l'intérêt de mettre un filtre "en  
entrée",
Mais si on veut traiter tous les fichiers, ça sera pas plus rapide de  
faire ça avec un itérateur, que si la fonction construit la liste  
avant de la renvoyer, si ?

>>
>> Personnellement, je trouve que le paramètre Pattern n'a rien à  
>> faire là
>> Amha, la moindre des choses, ça serait de mettre une valeur par
>> défaut qui ne filtre rien (j'espère que c'est pas dépendant de la
>> plate-forme, au moins)
> C'est le cas dans Start_Search:
>     Filter    : in Filter_Type := (others => True)

Le parametre Filter est juste comme il faut
(D'ailleurs je trouve qu'il a tout à fait sa place là, vu qu'il  
filtre selon le type de fichier : c'est plus compliqué à faire après)

Mais je parlais de Pattern :
Pour que ça ne filtre pas, on doit le mettre à ""
Alors pourquoi ne pas avoir mis la valeur "" par défaut ?? Je vois  
pas l'intérêt de nous demander de préciser ce paramètre à chaque  
fois ...



ps :
Ada.Directories a d'autres enfants que Ada.Directories.Validity ?
j'ai cru en apercevoir, mais là ils m'échappent


-- 
j'agis contre l'assistanat, je travaille dans une SCOP !


_______________________________________________
Site WWW de l'association Ada-France: http://www.ada-france.org/
[email protected]
http://www.ada-france.org/mailman/listinfo/ada-france