Re :-)
Gontran wrote:
Merci pour ces explications, Chicha, je pense que je commence à mieux cerner
ce que tu veux faire :-)
Je commence à comprendre aussi ce qui te chiffonnait... :-) Merci de ta
patience ;-)
Ok, je comprends mieux :-) J'ai tout de même quelques doutes sur le fait qu'un
message de niveau DETAIL reste toujours de niveau DETAIL quelle que soit le
positionnement de l'étape. J'aurais quand même tendance à penser que ça
dépend du contexte d'utilisation.
Oui, tu as raison c'est pas aussi simple que ce que j'ai proposé.
Par exemple, si « Ncooker -v INFO pack » m'affiche :
Creation of the working_dir package ...
Checking working_dir directory content ... [ OK ] <- affiché par Check
Preparing packaging environment ... [ OK ]
Create "working_dir" NBUILD package ... [ OK ]
Cleaning packaging environment ... [ OK ]
Cela signifie que le seul message de niveau INFO de la commande Check est
celui que j'ai annoté. Dans le contexte d'utilisation de la commande Pack, ça
me convient parfaitement, et les messages affichés me paraissent adaptés pour
le niveau INFO. Mais si je lance « Ncooker -v INFO check », il va m'afficher
uniquement :
Checking working_dir directory content ... [ OK ]
Il n'y aura pas ces messages :
Checking "infos" file ...
Checking "build" file ...
Checking "desc" file ...
Checking "changelog" file ...
qui ne me paraisse pourtant pas être du « détail » dans ce nouveau contexte où
je cherche à vérifier la validité de mon paquet. J'aimerai savoir directement
si un fichier contient une erreur ou non. Si c'est le cas, je sélectionnerai
alors le niveau DETAIL pour savoir précisément quel est l'élément fautif du
dit fichier.
Ton exemple est bon est montre bien la limite de "ma thèse" ;-)
Je pense que faire en sorte que chaque commande/module commence son affichage
à partir du niveau INFO, et que le gestionnaire de messages se débrouille
pour réaliser les décalages de niveau nécessaires simplifierait grandement la
vie des développeurs. :-)
Oui, en y réfléchissant bien, tu as raison.
Oui, c'est une distinction qui peut se voir de cette manière :-)
Si je comprends bien, ce qui te gène à ce niveau, c'est le fait que 1, 2 ou 3
soit moins parlant que INFO, DETAIL ou FULL. Pourquoi ne pas faire un mix de
nos deux solutions alors ?
Ce qui me gêne surtout c'est de proposer à l'utilisateur de faire
Ncooker -v 1 ou -v2 ... même s'il peut aussi faire -v INFO ou -v DETAIL.
Pour moi les seuls possibilités de verbosités sont NONE, ERROR, WARNING,
INFO, DETAIL et FULL, car elles ont vraiment un sens explicite, simple
et naturelles. Maintenant dans le fonctionnement interne de Ncooker ça
ne me déranges pas... (voir plus loin).
- On garde INFO, DETAIL et FULL (avec FULL : affichage de tout ce qui arrive)
Ok :-) (on est d'accord, il n'y aura pas de -v 1 ou -v 2.... ?
- Chaque commande/module commence l'affichage de ces messages avec le niveau
INFO (pour simplifier la vie des développeurs)
Ok à 100 %
- On utilise les fonctions shiftMsgLevel() et unshiftMsgLevel() pour décaler
le niveau des messages des commandes/modules appelés. Si un message décalé
dépasse le niveau FULL, il reste forcé à FULL. Ainsi, il seront tous affichés
si le niveau FULL est sélectionné.
Ok à 100 %. Je suis quand même entrain de réfléchir à une autre solution
qui permet d'éviter d'avoir à utiliser shiftMsgLevel.
Je te propose un truc à la fin du mail. Mais dans tous les cas ta
solution est sympa :-)
késtenpense ? :o)=)
Que du bien :-)
Une ébauche de solution alternative à shiftMsgLevel() :
Comme on l'a évoqué il y a des commandes et des modules : chaque
commande peut-être tantôt utilisée de façon primaire ou de façon
secondaire, tertiaire... (en tant que sous commande). De même un module
peut faire appel à un autre module. Ce dernier devient dans le contexte
courant un module secondaire.
Comme tu l'as proposé tous les commandes/modules commencent leur
verbosité à INFO (ERROR et WARNING sont à part, mais ça ne nous a pas
posé de problème jusqu'ici et il n'y a pas de raisons que ça nous en
pose...).
Mon idée est qu'il y ait une variable globale, définie dans le module de
gestion des messages, qui définisse le contexte de verbosité.
Chaque module/commande initialise cette variable quand il est appelé, et
la reset quand il a terminé son boulot. la fonction d'initialisation
initialise (quel beau pléonasme :-) ) la verbosité en fonction de son
état au moment où elle est appellée. En gros ça consiste à faire un
shiftMsgLevel/unshiftMsgLevel mais qu'une seule fois au début et une
seule fois à la fin de chaque module/commande.
Comme je suis sûre que c'est pas clair je donne un exemple (tout ça est
une idée en construction qui ne demande qu'à être améliorée...) :
Soit CONTEXT_VERBOSITY_LEVEL cette variable (les noms des variables et
fonctions restent à définir...)
Par défaut ,
CONTEXT_VERBOSITY_LEVEL=NONE
Je fais Ncooker -v DETAIL pack toto
la commande pack va appeler au début de son processus la fonction
init_context_verbosity_level().
init_context_verbosity_level() va détecter que le niveau de verbosité
courante est NONE et va donc l'incrémenté à INFO.
Tous les messages de la commande pack (envoyés via print_msg) et ayant
la verbosité INFO et DETAIL seront affichés.
Au court de son processus, la commande pack va appeller la commande check.
Cette dernière va à son tour appeller init_context_verbosity_level() au
début de son procéssus. Celle-ci va détecter que le niveau de verbosité
courant est INFO et va l'incrémenter à DETAIL. Tous les messages de la
commande check ayant la verbosité INFO vont donc passer en verbosité
DETAIL et seront affichés (car l'utilisateur l'a choisit via -v DETAIL).
Tous les messages de la commande check ayant la verbosité DETAIL ou
supérieur vont passer à FULL et ne seront donc pas affichés.
Quand la commande (sous commande dans notre context) check a finit son
boulot elle va appeler la fonction reset_verbosity_level() et va
repasser la main à la commande pack.
La fonction reset_verbosity_level() va détecter que le niveau courant
est DETAIL et va le décrémenter à INFO.
Comme on revient dans la commande pack tout va bien :-)
Qu'est-ce que tu en penses ? (ainsi que tous ceux que ça intéresse... :-) )
++
Chicha
