Hello tout le monde :-)
Salut Gontran :-)
Je partage les 2 limitations que tu rencontres mais je ne suis que
partiellement d'accord sur la solution que tu apportes à la première
limitation.
Je m'explique :
Ce qui semble poser problème c'est la présentation à l'écran des erreurs
(l'indentation).
Maintenant il faut faire attention à une chose : le contenu de l'erreur
est différente de sa présentation à l'écran.
Pour moi les niveaux qu'on avait choisit au départ sont bons : QUIET,
ERROR, WARNING, INFO, DETAIL, FULL.
Un niveau 1,2,3,..., N n'a aucun sens du point de vue de l'utilisateur
car il ne sait pas à l'avance ce qu'il va rencontrer comme message.
Je ne vois pas comment un utilisateur peut utiliser Ncooker -v4
<command> plutôt que Ncooker -v3. Le seul sens que ça à c'est au niveau
visuel : je veux 3 indentations ou 4 car je sais que j'aurais plus ou
moins d'infos.
Pour moi ce qui intéresse l'utilisateur c'est le contenu de l'info.
Après c'est à nous de faire en sorte qu'elle soit affichée correctement.
Avec QUIET, ERROR, WARNING, DETAIL, FULL on couvre tous les besoins
amha. C'est à nous de choisir pour chaque message dans quelle catégorie
il est et comment l'afficher selon le context où il est utilisé.
Quand on regarde les exemples que tu donnes (ils sont très bons amha) on
voit qu'une même indentation peut correspondre à 2 choses en fait :
soit c'est un message de verbosité supérieur comme ici :
Checking build file ... <-- Verbosité DETAIL
Getting file content ... <-- Verbosité FULL
Checking syntax ... <-- Verbosité FULL
Checking do_preconfig function ... <-- Verbosité FULL
Checking do_config function ... <-- Verbosité FULL
Soit c'est un message qui peut être de versbosité inférieure ou
supérieure selon le context, comme tu l'as illustrée avec la fonction
check qui peut-être appelée directement ou en tant que sous étape d'une
autre étape (pack dans ton exemple).
Pour moi si un message est d'un niveau DETAIL il doit l'être dans tous
les cas. C'est à dire qu'il est DETAIL même s'il est utilisé dans une
sous étape de niveau DETAIL.
En revanche ce qu'il serait sympa c'est qu'il soit indenté car faisant
partie d'une sous étape.
exemple (pas forcément en cohérence avec l'état actuel d'Ncooker mais
peut importe) :
Ncooker -v INFO pack foobar
packing foobar......... <-- Verbosité INFO
checking foobar..... <-- Verbosité INFO
Ncooker -v DETAIL pack foobar
packing foobar......... <-- Verbosité INFO
checking foobar..... <-- Verbosité INFO
checking build file <-- Verbosité DETAIL
Ncooker -v INFO check foobar.nbuild
checking foobar..... <-- Verbosité INFO
Ncooker -v DETAIL check foobar.nbuild
checking foobar..... <-- Verbosité INFO
checking build file <-- Verbosité DETAIL
Voilà ce que je souhaiterai obtenir.
Sommes nous déjà d'accord sur ce point, avant de discuter technique ?
++
CHicha
Gontran wrote:
Comme solution à ce problème, je propose d'abandonner le nommage des niveaux
INFO, DETAIL et FULL pour utiliser à la place des niveaux numérotés de 1 à N,
"N" étant « théoriquement » infini, mais dans la pratique, il faudra se
limiter à un nombre de niveaux raisonnable :-). Les développeurs utiliserait
print_msg de cette manière :
print_msg 1 "ce message est affiché si le niveau de verbosité est au minimum
1"
print_msg 2 "ce message est affiché si le niveau de verbosité est au minimum
2"
print_msg 3 "ce message est affiché si le niveau de verbosité est au minimum
3"
print_msg 4 "ce message est affiché si le niveau de verbosité est au minimum
4"
...
Le niveau de verbosité serait toujours sélectionné de la même façon, mais en
indiquant un nombre :
Ncooker -v 1 <command>
Ncooker -v 2 <command>
Ncooker -v 3 <command>
Ncooker -v 4 <command>
...
(Les niveaux QUIET, ERROR et WARNING seraient néanmoins conservés, et la liste
complète des niveaux de verbosité successifs serait QUIET, ERROR, WARNING, 1,
2, 3, 4, ... N)
Chaque niveau appliquerait à ses messages une indentation correspondant à son
degré de détail.
* Autre problème rencontré : dans mon exemple précédent, j'utilise la commande
pack. Mais tous les messages ne sont pas affichés uniquement par cette
commande. En fait, le code de la commande pack se présente ainsi :
print_msg "INFO" "Creation of the ${dir} package ..."
run_command check ${dir}
print_msg "DETAIL" "Preparing packaging environment ..."
<...>
On voit que le premier message est affiché par la commande Pack, mais que ceux
qui suivent sont affichés par la commande Check de Ncooker. Puis, lorsque la
commande Check se termine, la commande Pack continue à afficher ses propres
messages.
Pour que l'affichage des messages se présente correctement à l'écran, il faut
que la commande Check commence au niveau "DETAIL" de verbosité :
print_msg "DETAIL" "Checking ${dir} directory content ..."
print_msg "FULL" "Checking infos file ..."
<...>
en procédant ainsi, l'enchevêtrement des messages des commandes Pack et Check
passe inaperçu grâce à une indentation correcte.
Le problème est que la commande Check n'est pas utilisée que par la commande
Pack. Elle peut également être lancée à partir de la ligne de commande. Et
comme les messages affichés ne commencent qu'au niveau DETAIL, l'utilisateur
qui fait :
$ NCooker -v INFO check <paquet>
ne verra aucun message s'afficher ! :-)
Pour bien faire, il faudrait que la commande Check commence l'affichage de ses
messages au niveau INFO, mais dans ce cas, le problème se déplace au niveau
de son utilisation par la commande Pack.
Cet exemple montre le cas particulier de la commande Check par Pack, mais ce
problème peut se poser avec tout autre commande/module utilisé par une autre
commande/module.
Je propose une solution qui repose sur la solution précédente (niveau de 1
N). L'idée est que les développeurs n'aient plus à se prendre la tête pour
savoir à quel niveau de verbosité ils doivent commencer l'affichage de leurs
messages selon que leur module est appelé en ligne de commande ou par un
autre module : ce serait _toujours_ le niveau 1.
Ensuite, je propose d'ajouter deux nouvelles fonctions au gestionnaire de
messages : shiftMsgLevel() et unshiftMsgLevel(). Elles seraient utilisés pour
appliquer et annuler un décalage dans les niveaux de verbosité des messages.
Par exemple :
Commande Pack :
print_msg 1 "Creation of the ${dir} package ..."
shiftMsgLevel
run_command check ${dir}
unshiftMsgLevel
print_msg 2 "Preparing packaging environment ..."
<...>
Commande Check :
print_msg 1 "Checking ${dir} directory content ..."
print_msg 2 "Checking infos file ..."
<...>
La commande Pack affiche son message de niveau 1. Puis elle appelle
shiftMsgLevel() pour appliquer un décalage de niveau pour les prochains
messages. La « quantité » de décalage correspondrait au niveau du dernier
message affiché par print_msg, donc ici 1.
Lorsque la commande Check va afficher son premier message de niveau 1, la
fonction print_msg va appliquer ce décalage de « 1 », ce qui fait que le
premier message de check va devenir un message de niveau 2, et donc avoir une
indentation plus importante. Il va se passer la même chose pour le second
message de Check, qui va passer du niveau 2 au niveau 3.
Une fois que la commande Check est terminé, on revient dans la commande pack
pour exécuter la fonction unshiftMsgLevel afin d'annuler le décalage demandé
précédemment. Ainsi, les message suivants de Pack s'afficheront avec le
niveau correct.
Les appels successifs de la fonction shiftMsgLevel permettrait d'accumuler les
décalages, c'est-à-dire que que si la commande Check fait appel à un autre
module et qu'un décalage à déjà lieu, le nouvel appel à shiftMsgLevel
appliquera un nouveau décalage en tenant compte du décalage actuel. De la
même manière, la fonction unshiftMsgLevel permettrait de revenir aux
décalages précédents de manière successive.
Voilà le principe :-)
Je pense que ces solutions permettent de rendre le gestionnaire de messages
plus souple et plus pratique. Dites-moi ce que vous en pensez.
++
Gontran
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
