gérer des fichiers log

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> Une application web n'est-elle pas une application graphique?

Non, c'est une application client/serveur. Le client (le browser web)
peut-être une application graphique (firefox, Chrome) ou pas (links,
lynx, w3m).

merci, comme je n'y connais rien en mobile (entre autres) je ne savais
pas du tout quoi répondre :-)

J'ai aussi conçu des applications desktop client/serveur.

D'autant plus que les applications web modernes ne font souvent que
chercher des données en web pour les affichers grÍ¢ce au javascript
local, ce qui ressemble beaucoup Í  une application desktop qui se
connecte Í  une base de données.

Pour clarifier la discussion, posons:

- application bureau (desktop) monolithique

pas d'usage du réseau, d'une base de données réseau,
etc

- application bureau client/serveur

utilisation d'une base de données SQL ou autre, y.c.
données sur le web (REST/HTTP)

- application web classique client/serveur

présentation par le serveur, mise en forme par le client
(peu/pas de javascript)

- application web moderne client/serveur

très similaire Í  "application bureau client/serveur"

- application mobile native

très similaire Í  "application bureau client/serveur"

- application mobile Progressive Web App

très similaire Í  "application mobile native" sauf que
100% HTML/CSS/JS

Et il y a des variations, des combinaisons, etc.

Il ne me semblait pas que le fait que l'application soit bureau ou non
change grand chose: il faut des configs quelque part (locale ou
distante, possible aussi pour une application bureau client/serveur).

c'est pas gênant ? (et STDOUT est fait pour quoi ?)

Pour une application qui ne communique en fait pas avec l'utilisateur en
console, on peut définir stdout comme les notifications normales et
stderr comme les erreurs.

Pour une application qui communique avec l'utilisateur en console (pas
ton cas me semble-t-il), stdin/stdout est pour l'interaction
utilisateur, stderr pour les erreurs.

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

il me semble que la seule chose que ça fait en plus c'est générer des
fichiers de code, correspondant aux fichiers d'interfaces graphiques
édités (comme Glade).

Ok, ce ne sont pas des logs.

saurais tu définir ce que c'est qu'un core, précisément ?
(je devine, mais le risque de malentendu est élevé, alors ... autant
prévenir ;-) )

Je regrette le mot de core.

Disons qu'une application a d'un cÍ´té de la logique métier, et de
l'autre les fonctions techniques de support. Après on peut aller plus
en détail.

si j'ai bien compris, ça me donne l'avantage de pouvoir rester
intégralement dans le répertoire de compilation (par ex pour tous ceux
qui compilent Í  partir des sources),

bien sͻr, c'est un autre avantage de cette technique.

et pour un intégrateur, ça sera très facile de changer tout ça comme il
veut, alors qu'au contraire ça serais très difficile pour lui de
modifier du code source ?

Non, pas difficile, si ton application est disponible en code source.
Ce qui est obligatoire si tu veux de la portabilité UNIX et pas
seulement tourner sous Linux par exemple. Et il faut aussi que toutes
tes dépendances (de compilation et d'exécution) soient disponibles dans
un environnement de développement de l'intégrateur.

Ca me rappelle une question lié Í  un module pour le logiciel R. Le
développeur a eu de la peine Í  comprendre, initialement, que s'il
voulait de la compatibilité UNIX, il fallait distribuer le *code source*
du module et laisser l'intégrateur le compiler pour la plateforme
concernée! (un peu comme ce que font certains langages modernes avec
la compilation finale du bytecode en code architecture-spécifique au
déploiement, mais en C).

par exemple, si un novice qui compilerais mon application Í  partir des
sources, sous windows, me dit :

Microsoft est un autre cas, que je ne traiterai pas, sinon qu'il existe
aujourd'hui également bash sous cet environnement propriétaire, un
kernel Linux installé par défaut et un système de virtualisation qui
permet même l'exécution de programmes graphiques X11 (en béta).

Sous Microsoft, il devrait être bientÍ´t possible de simplement donner Í 
disposition une image de conteneur sans devoir trop réfléchir aux
spécificités de cet environnement propriétaire complexe, et de rester
100% sous environnement standard UNIX pour le développement et la
compilation.

Í  ce moment lÍ , qu'est ce que je fais, moi ? :-D

Il te faut traiter le problème soit en émulation (== le standard est le
monde UNIX, Microsoft est en compatibilité), soit créer une intégration
complètement différente pour le monde Microsoft.

En résumé, un wrapper script bash pour UNIX, un script bash pour
Microsoft (ou un script batch MS-DOS suivant la version de l'OS).

Et si tu as bien fait les choses, tu n'as pas trop de dépendances
Microsoft Í  rajouter dans ton programme en Ada.

> y a t il une habitude, pour nommer les fichiers de backup ?

c'est pas qqch Í  base de '~' ?

C'est ce que font certains programmes, p.ex. Emacs.

ou alors ça n'est que sous windows, que les gens font ça ?

Aucune idée sous le monde Microsoft.

en attendant, j'ai besoin d'un minimum pour mon confort dans le travail,
et en même temps j'essaye de faire le moins possible de choses qui
embêtent les autres :-)

C'est une bonne stratégie.

Le 22-07-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :

In article <60f83dc1$0$3743$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Thomas , dans le message
<fantome.forums.tDeContes-8A99BF.23331420072021@news.free.fr>, a écrit :
> dans ce cas, pourrais tu m'aider Í  le poser mieux, stp ?

Désolé, je n'ai pas vraiment l'énergie.

ah bon. tant pis, dommage.

(si tu l'avais eue, je suis sur que j'aurais pu bcp apprendre,
même s'il serait forcément resté qques points de désaccords dus Í  ce que
j'ai déjÍ  appris ailleurs et Í  la différence des environnements et
contextes dans lesquels chacun évolue.)

Je crois que ce que Nicolas veut t'expliquer (ainsi que Marc en fait),
c'est que tu dis que tu ne veux t'en occuper que d'un point de vue
développeur et pas administrateur système, mais toutes tes questions
sont orientée administration système.

J'ai eu l'impression que tu l'avais compris Í  un moment mais avec
d'autres réponses de ta part je n'en suis pas sÍ»r.

En gros, le développeur, il balance tout ce qui ne s'affiche pas dans
l'interface graphique dans stout et dans stderr. Point bare. Tout le
reste, c'est de l'administration système.

Techniquement parlant, le développeur de l'application peut choisir un
nom de fichier pour ses logs. Mais c'est juste de l'ingérence dans
l'administration système. Ça n'a aucun sens de demander des bonnes
pratiques de nomage de fichiers de logs d'un point de vue développeur et
pas administrateur système.

C'est Í  celui qui lance le logiciel de choisir dans quels fichiers et
dans quels répertoires les logs sont enregistrés. C'est Í  celui qui
lance l'application de choisir combien de temps les logs sont conservés.
C'est Í  celui qui lance l'application de choisir la taille maximale qui
peut être prise sur le disque dur. C'est Í  celui qui lance l'application
de choisir si les fichiers doivent être archivés ou supprimés.

Le plus simple est donc de tout balancer dans stdout et stderr et de
laisser celui qui lance l'application rediriger o͹ bon lui semble. Celui
qui lance l'application peut avoir laissé ce qui a été fait par
l'administrateur système. Qui peut laisser ce qui a été fait par le
mainteneur du package de la distribution.

Tout ce que tu veux faire en plus de stderr et stdout va juste
compliquer les choses Í  celui qui veut mettre en place une politique de
logrotate. C'est donc de l'administration système et ça doit être pris
en compte comme tel. Tu ne peux pas demander des bonnes pratiques Í  ce
niveau en demandant aux autres d'arrêter de regarder les choses d'un
point de vue administrateur système.

--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io

Stéphane CARPENTIER , dans le message
<slrnsfo5r3.2gt.sc@scarpet42p.localdomain>, a écrit :

Je crois que ce que Nicolas veut t'expliquer (ainsi que Marc en fait),
c'est que tu dis que tu ne veux t'en occuper que d'un point de vue
développeur et pas administrateur système, mais toutes tes questions
sont orientée administration système.

Bien résumé.

En gros, le développeur, il balance tout ce qui ne s'affiche pas dans
l'interface graphique dans stout et dans stderr. Point bare. Tout le
reste, c'est de l'administration système.

<snip>

VoilÍ .

Voire encore mieux : une application graphique, souvent on la lance
elle-même depuis un bureau graphique, et on ne voit jamais les sorties
standard, donc elle ne devrait strictement rien écrire dessus Í  part en cas
d'échec catastrophique.

Et une application graphique n'a pas vocation Í  tourner indéfiniment, donc
elle ne devrait pas générer des logs durables.

Il peut bien sͻr y avoir des exceptions, mais comme justement ce sont des
exceptions, on ne peut rien dire sans savoir en quoi ce sont des exceptions.

In article <sddoan$flh$1@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

- si tu le mémorises sous forme d'un handle de répertoire ouvert,
parfait

je n'ai pas entendu dire qu'on pouvait faire ça en ada,
ça doit être une fonction spécifique UNIX ?

- si tu le mémorises sous forme de chemin, alors tu as le même
risque si quelqu'un modifie l'arborescence

Ce problème ne se pose pas si on ne change pas le répertoire courant.

Et si tu génères uniquement des logs dans stdout et stderr, le besoin du
répertoire courant est inutile, sauf si tu charges des fichiers
relativement Í  lui (ce qui me semble une bonne pratique), mais alors il
n'y a rien Í  faire: juste ouvrir les fichiers (config p.ex.) avec le
chemin indiqué par l'utilisateur (relatif ou absolu).

si je te comprend bien, l'avantage de se référer au répertoire courant,
sans le mémoriser ni le changer, c'est qu'il supporte les renommages en
cours d'exécution ?
et si on supprime ce répertoire, qu'est ce que ça donne ?


(sujet connexe)
bon, a priori, je n'ai pas besoin de pousser la résilience de mon
logiciel au point o͹ on puisse le changer de place pendant son
exécution,
ça me parait raisonnable de demander Í  l'utilisateur de le fermer pour
faire ça.

(je comprend tout Í  fait que ça puisse être un besoin pour les serveurs,
par exemple)

Donc KISS: ne pas changer le répertoire courant.

j'étais de ton avis donc tu n'as pas tellement eu Í  me convaincre,
donc je vais virer tout ça et gérer les chemins autrement :-)

> ~/.<nom-application>/
> plutÍ´t que
> ~/.config/<nom-application>/

Les deux existent, le ~/.config est une convention plutÍ´t récente des
GUI comme GNOME ou kde, me semble-t-il.

ah, tant mieux !
alors j'invite tous les developpeurs qui me lisent Í  préférer
~/.config/<nom-application>/ pour ranger leurs données :-)

Mais le mieux est de consulter
le Filesystem Hierarchy Standard (même s'il devient apparemment
obsolète).

qu'est ce que c'est ?
(il a peut être besoin d'une mise Í  jour ?)

> perso, je n'aime pas me retrouver avec une quantité astronomique de ~/.*
> :-(

Ca ne gêne pas sous UNIX, ce sont des fichiers cachés

"tant mieux" pour la vie de tous les jours,

sauf que de temps en temps on a besoin de les afficher quand même,
autant en interface graphique qu'en ligne de commande.
et lÍ  le rangement en sous-répertoires retrouve tout son intérêt pour la
commodité.

> j'aimerais bcp mieux que tout ça soit rangé dans un répertoire, mais
> pour ça il faut que bcp de développeurs se mettent d'accord ..... !
>
> (`~/.config/` ? `~/.hidden-data/` ?)

Alternative: ne pas imposer ce choix Í  l'utilisateur, mais passer le nom
du fichier de config en argument, éventuellement avec une
préconfiguration classique dans le wrapper.

(voir plus bas)

> aurais tu des tuyaux Í  me donner, pour lire un fichier de configuration
> d'une manière qui soit Í  la fois suffisamment fiable et pas trop
> casse-pied Í  programmer ?

en fait, je pense que j'aurai l'occasion de faire une fenêtre de
"préférences", qui va éditer "en mode graphique" un fichier de ce genre
(donc ce fichier sera écrit et lu symétriquement, et pas édité Í  la
main).

Par contre, ça ne résout pas le pb de la localisation de ce fichier ...

> tu veux dire que tu trouves acceptable que ça soit le comportement par
> défaut, mais que tu veux pouvoir le modifier par la ligne de commande,
> c'est ça ?

oui, ou le fichier de config *doit* être spécifié systématiquement en
ligne de commande; les deux me vont car dans le 2e cas ... on peut faire
un wrapper pour réduire au 1er cas.

j'ai cru comprendre que pour permettre aux utilisateurs de Windows de
double cliquer sur un fichier pour l'ouvrir, il est nécessaire de
prendre en charge l'indication du fichier cliqué comme argument unique
(je ne sais pas comment ça se passe sur les autres plateformes)

donc, comment faire qqch qui réponde Í  ton besoin et qui soit compatible
avec ce comportement de Windows ?
(en essayant d'éviter des galipettes du genre : lire le fichier pour
savoir si c'est un fichier de config ou un document utilisateur)

(voir l'autre branche du fil)

> en fait, a priori j'étais comme toi, je trouvais ça saugrenu qu'un
> logiciel autre qu'un shell modifie son répertoire courant (et je me
> demande pourquoi l'API Ada nous donne cette possibilité)

sémantiquement, tu vas changer de répertoire Í  chaque fois que tu veux
relativement exprimer un chemin depuis ce répertoire, mais il faut faire
attention Í  bien faire ce que l'utilisateur s'attend.

dans quels cas on peut vouloir exprimer un chemin relativement depuis un
autre répertoire ?
(voir plus bas)

> - soit on considère que c'est équivalent Í  une application CLI Í  qui on
> passe le nom du fichier comme argument, avec un chemin
> - soit on considère que c'est équivalent Í  un shell dans lequel on fait
> des `cd`, et Í  la fin on passe le nom du fichier comme argument, sans
> chemin
>
> je crois que toi et moi on est tous les 2 sur la 1ere alternative,
> mais je devine que le mainteneur précédent (ou le précédent encore) qui
> a programmé ça était sur la 2eme :-)
>
> un avis lÍ  dessus ?

Il me semblerait logique que le répertoire courant dans lequel on a
démarré l'application (en shell ou en GUI) soit le premier présenté par
la boÍ®te de sélection, et ensuite il me semblerait logique que la boÍ®te
de sélection retourne le chemin relatif depuis ce répertoire courant du
fichier sélectionné, ou le chemin absolu si la personne a choisi
d'entrer un chemin absolu ou a cliqué sur autre chose que le répertoire
courant.

ok, quand on change de répertoire, on bascule en "tout en chemins
absolus" pour designer les fichiers voulus, mais on ne touche pas au
répertoire courant.

> si une application graphique ne devrais /jamais/ changer de répertoire
> courant,
> - est ce que c'est un domaine strictement réservé aux shells,
> - ou est ce qu'il y a d'autres cas de figure o͹ c'est approprié qu'un
> logiciel le fasse ?

Je pense qu'une application quelconque a plein de raison de changer de
répertoire courant (p.ex. lancer un logiciel complémentaire dans son
environnement propre),

ah oui, ça pourrais m'arriver plus tard :-)
(mais Il me semble que je pourrais aussi donner tous les paramètres en
chemins absolus)

mais elle peut sauvegarder le répertoire
précédent et y revenir

ok pour celui lÍ ,

y a-t-il d'autres exemples ? pour la curiosité :-)

> disons que, quelle que soit la méthode utilisée par l'application pour
> définir un chemin dont elle aura besoin au cours de sa vie, changer la
> structure des répertoires pendant qu'elle tourne est risqué :
> j'ai entendu dire que la pratique est de lire le fichier de config au
> démarrage, mais pas de vérifier régulièrement s'il a été modifié.

C'est juste: il ne faudrait changer aucun des chemins absolus qui
figureraient dans la config. Par contre, si tout est exprimé
relativement au répertoire courant, le risque n'existe pas.

il ne faudrait changer aucun des chemins qui figureraient dans la config.
y compris la partie écrite des chemins relatifs.
Par contre, si je t'ai bien compris, on peut changer le chemin du
répertoire courant parce qu'il est "mémorisé sous forme de handle" (ou
équivalent)

>> Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin
>> de créer des fichiers de logs plutÍ´t que d'utiliser stdout et stderr,
>
> en plus, pas Í  la place.

Ah, des logs supplémentaires? Pourquoi?

- parce que je ne sens pas la prise en charge d'un wrapper script qui va
marcher Í  tous les coups sur toutes les plateformes
(voir l'autre branche du fil)
- pour, Í  la fois, te contenter avec les sorties standards, et me
contenter avec des fichiers écrits immédiatement

Comment? Combien?

ça dépend comment on compte, mais en gros, chaque msg Í  logger est
dupliqué (voire * 3 avec l'interface graphique).

> c'est pour ça qu'il est imaginable d'ignorer les erreurs d'écriture
> quand il y en a, considérant que c'est rattrapable via stdout et stderr
> (mais en fait c'est ce que j'avais écrit juste avant, non ?)

Je ne comprends pas ce que tu entends par erreur d'écriture et en
particulier avec stdout et stderr.

si je te comprend bien, écrire sur stdout et stderr ne provoque jamais
aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce
qu'on y envoie tombe dans un puits sans fond ?


quand je reçois un msg Í  traiter, j'ai 3 interfaces Í  ma disposition :
- les sorties standards
- les fichiers de logs
- l'interface graphique

ce dont je parlais était d'ignorer les erreurs d'écriture dans les
fichiers de logs, puisque les sorties standards suffisent pour récupérer
l'information.

cad de ne pas indiquer sur les sorties standards et dans l'interface
graphique, qu'on a eu une erreur au moment d'écrire dans les fichiers de
logs.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

In article <sddpd1$flh$3@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> il me semble que la seule chose que ça fait en plus c'est générer des
> fichiers de code, correspondant aux fichiers d'interfaces graphiques
> édités (comme Glade).

Ok, ce ne sont pas des logs.

difficile de penser Í  tout préciser quand on a le nez dans le guidon et
que notre environnement nous parait évident :-)


les logs, c'est juste pour avoir une trace de ce qui n'a pas marché
comme prévu.

mais j'ai quand même besoin qu'un novice qui a installé ça Í  partir des
sources, sans intégrateur entre nous 2, puisse m'envoyer un fichier de
logs suffisamment simplement,
pour me permettre de comprendre ce qui ne marche pas chez lui alors que
ça marche chez moi.

> saurais tu définir ce que c'est qu'un core, précisément ?
> (je devine, mais le risque de malentendu est élevé, alors ... autant
> prévenir ;-) )

Je regrette le mot de core.

Disons qu'une application a d'un cÍ´té de la logique métier, et de
l'autre les fonctions techniques de support. Après on peut aller plus
en détail.

je ne vois pas bien ce que tu veux dire, mais ça m'intéresse :-)
si tu as la patience, je veux bien que tu ailles plus en détail :-)

(mais pour moi c'est pas prioritaire par rapport aux réponses qui me
permettent de savoir quoi faire concrètement)

> et pour un intégrateur, ça sera très facile de changer tout ça comme il
> veut, alors qu'au contraire ça serais très difficile pour lui de
> modifier du code source ?

Non, pas difficile, si ton application est disponible en code source.

ah bon ? ça m'étonne.
si c'est vraiment simple ça m'arrangerais bien, ça pourrais changer la
suite :-)

par exemple (j'ai déjÍ  donné cette url) :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tki/mcc
_tki/mcc-msg.ads?revision"4&view=markup ( https://urlpetite.fr/5j2 )
comment t'y prendrais-tu ?

> par exemple, si un novice qui compilerais mon application Í  partir des
> sources, sous windows, me dit :

Microsoft est un autre cas, que je ne traiterai pas, sinon qu'il existe
aujourd'hui également bash sous cet environnement propriétaire,

> Í  ce moment lÍ , qu'est ce que je fais, moi ? :-D

Il te faut traiter le problème soit en émulation (== le standard est le
monde UNIX, Microsoft est en compatibilité), soit créer une intégration
complètement différente pour le monde Microsoft.

En résumé, un wrapper script bash pour UNIX, un script bash pour
Microsoft (ou un script batch MS-DOS suivant la version de l'OS).

hou la ...
ça me parait très compliqué de me lancer lÍ  dedans, alors que je n'ai
aucun windows pour tester

d'autant plus qu'il me semble que sous UNIX les environnements
graphiques sont (très) divers,
et (Í  ma connaissance) n'étant pas normalisés, j'imagine que les
ajustements, même marginaux, pour obtenir par ex qu'on puisse double
cliquer sur un fichier, ou le glisser sur l'icÍ´ne de l'application, pour
l'ouvrir, peuvent avoir la même diversité.

bref, en l'état de mes connaissances, même si je me décidais Í  fournir
des wrapper scripts, je poserais quand même comme requis que mon
application soit capable de fonctionner sans.

(voir l'autre branche du fil)

Et si tu as bien fait les choses, tu n'as pas trop de dépendances
Microsoft Í  rajouter dans ton programme en Ada.

si qqch n'est pas portable, je tacherai de le rendre portable, plutÍ´t
que de remplacer une dépendance UNIX par une dépendance Microsoft.

>> > y a t il une habitude, pour nommer les fichiers de backup ?
>
> c'est pas qqch Í  base de '~' ?

C'est ce que font certains programmes, p.ex. Emacs.

et quand c'est toi qui en as besoin, quel nom donnes tu ?

(rappel : cette question c'est pour tous les fichiers écrits, pas que
les logs)

> en attendant, j'ai besoin d'un minimum pour mon confort dans le travail,
> et en même temps j'essaye de faire le moins possible de choses qui
> embêtent les autres :-)

C'est une bonne stratégie.

merci :-)

c'est dans cette perspective que je pense que je vais ne pas faire de
wrapper script et conserver les fichiers de logs,
mais en faisant tout ce qui me parait acceptable pour que ça soit le
moins gênant possible pour toi, si jamais un jour tu devais être
l'intégrateur de mon logiciel :-)

j'espère que dans cette perspective tu veux bien continuer Í  échanger
avec moi sur ce sujet :-)

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

In article <sddopq$flh$2@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
>> > Une application web n'est-elle pas une application graphique?
>>
>> Non, c'est une application client/serveur. Le client (le browser web)
>> peut-être une application graphique (firefox, Chrome) ou pas (links,
>> lynx, w3m).
>
> merci, comme je n'y connais rien en mobile (entre autres) je ne savais
> pas du tout quoi répondre :-)

J'ai aussi conçu des applications desktop client/serveur.

D'autant plus que les applications web modernes ne font souvent que
chercher des données en web pour les affichers grÍ¢ce au javascript
local, ce qui ressemble beaucoup Í  une application desktop qui se
connecte Í  une base de données.

dis moi si je me trompe : il me semble qu'il reste une /grosse/
différence :
- une application desktop est un exécutable compilé pour la plateforme
qui l'exécute,
- une application web est interprétée par un navigateur.
avec des avantages et des inconvénients de chaque coté

Pour clarifier la discussion, posons:

- application bureau (desktop) monolithique

pas d'usage du réseau, d'une base de données réseau,
etc

- application bureau client/serveur

utilisation d'une base de données SQL ou autre, y.c.
données sur le web (REST/HTTP)

- application web classique client/serveur

présentation par le serveur, mise en forme par le client
(peu/pas de javascript)

- application web moderne client/serveur

très similaire Í  "application bureau client/serveur"

- application mobile native

très similaire Í  "application bureau client/serveur"

- application mobile Progressive Web App

très similaire Í  "application mobile native" sauf que
100% HTML/CSS/JS

pour l'instant, celle que je fais semble être :
une "application bureau monolithique"
(d'après ta description, parce que d'après ce que dis Stephane c'est pas
sur, puisqu'il y a une bibliothèque. je ne saisis pas encore bien toutes
les nuances)

pour ma part, je me vois faire :
- application bureau client/serveur
- (peut être) application web classique client/serveur

pour l'instant c'est tout, et c'est encore du futur ...

Il ne me semblait pas que le fait que l'application soit bureau ou non
change grand chose: il faut des configs quelque part (locale ou
distante, possible aussi pour une application bureau client/serveur).

il me semble qu'il y a des contraintes diverses, non ?

par exemple, peut on passer un argument Í  une application web pour
qu'elle lise un fichier de config local ?
clairement, les logs sont gérés directement par le serveur,
les potentielles mauvaises pratiques n'affectent pas l'usager, Í  qui on
n'a pas besoin de demander d'envoyer ses fichiers de logs pour
comprendre le pb.

tandis qu'avec une application bureau client/serveur, il y a une part de
chaque coté, le serveur ne gère pas tout.

> c'est pas gênant ? (et STDOUT est fait pour quoi ?)

Pour une application qui ne communique en fait pas avec l'utilisateur en
console, on peut définir stdout comme les notifications normales et
stderr comme les erreurs.

est ce que le debug équivaut Í  des "notifications normales", ou est ce
que c'est autre chose ?

Pour une application qui communique avec l'utilisateur en console (pas
ton cas me semble-t-il),

en fait, le "gros morceau" est une application graphique, mais :
- le même exécutable peut aussi être utilisé en CLI Í  la place
- d'autres exécutables, qui servent aux tests, font les 2 en même temps

comment me conseilles tu de gérer ça ?

stdin/stdout est pour l'interaction
utilisateur, stderr pour les erreurs.

quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive
mode permits only one file on the command line",
comment les catégorises tu ? interaction utilisateur ou erreurs ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

je n'ai pas entendu dire qu'on pouvait faire ça en ada,
ça doit être une fonction spécifique UNIX ?

POSIX, oui. Ca fait 25 ans que je n'ai plus écrit d'Ada.

si je te comprend bien, l'avantage de se référer au répertoire courant,
sans le mémoriser ni le changer, c'est qu'il supporte les renommages en
cours d'exécution ?

VoilÍ .

et si on supprime ce répertoire, qu'est ce que ça donne ?

Le répertoire n'est plus accessible avec son nom, mais reste accessible
Í  tous ceux qui ont encore son handle, avec quelques bizarreries:

schaefer@reliand:~$ mkdir /tmp/tt
schaefer@reliand:~$ cd /tmp/tt
schaefer@reliand:/tmp/tt$ rmdir /tmp/tt
schaefer@reliand:/tmp/tt$ ls
schaefer@reliand:/tmp/tt$ touch abcd
touch: cannot touch 'abcd': No such file or directory
schaefer@reliand:/tmp/tt$ ls -la
total 0
schaefer@reliand:/tmp/tt$ pwd
/tmp/tt
schaefer@reliand:/tmp/tt$ /bin/pwd
/bin/pwd: couldn't find directory entry in '..' with matching i-node

bon, a priori, je n'ai pas besoin de pousser la résilience de mon
logiciel au point o͹ on puisse le changer de place pendant son
exécution,

C'était pour te faire comprendre la philosophie complètement différente
de UNIX concernant les chemins. Il n'est en général pas une bonne
pratique de `deviner' o͹ est "son" répertoire. Soit c'est en dur
(/etc/application/), ~/.application, etc), soit c'est une variable
d'environnement, soit c'est configuré quelque part.

Et changer le répertoire courant durant l'exécution, c'est changer
la référence et donc on a des soucis pour tous les arguments de ligne de
commande qui sont en fait des fichiers exprimés relativement (au
répertoire courant au moment du lancement).

le Filesystem Hierarchy Standard (même s'il devient apparemment
obsolète).

qu'est ce que c'est ?
(il a peut être besoin d'une mise Í  jour ?)

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Apparemment c'est surtout que certaines distributions ont laissé tombé.

et lÍ  le rangement en sous-répertoires retrouve tout son intérêt pour
la commodité.

C'est juste.

en fait, je pense que j'aurai l'occasion de faire une fenêtre de
"préférences", qui va éditer "en mode graphique" un fichier de ce genre
(donc ce fichier sera écrit et lu symétriquement, et pas édité Í  la
main).

Dommage, j'adore quand je peux générer ce genre de fichier
automatiquement, par exemple pour préconfigurer une salle de machines
ou tester des applications automatiquement.

Donc: configuration stocké en format texte, dans
~/.config/application/config par exemple.

Quel format texte? Totalement égal si je peux le générer avec un
template.

j'ai cru comprendre que pour permettre aux utilisateurs de Windows de
double cliquer sur un fichier pour l'ouvrir, il est nécessaire de

Microsoft est pour moi hors sujet.

prendre en charge l'indication du fichier cliqué comme argument unique
(je ne sais pas comment ça se passe sur les autres plateformes)

La plupart du temps le GUI va simplement lancer /usr/bin/toto
nom-fichier-double-cliqué. Toutefois, la plupart des GUI permettent de
configurer le comportement avec des templates (exemple: programme %f
dans l'association MIME), il me semble.

donc, comment faire qqch qui réponde Í  ton besoin et qui soit compatible
avec ce comportement de Windows ?

Si tu veux faire une application multi-plateforme, tu peux corriger les
problèmes Microsoft soit dans ton application, soit simplement, et cela
serait mon approche, livrer un wrapper (sous forme batch Microsoft ou
autre) qui corrige les problèmes de compatibilité de cette plateforme ?

Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne
vais pas trop élaborer.

D'autant plus qu'on peut facilement tourner du Linux sur Microsoft
aujourd'hui, y compris bientÍ´t en mode graphique.

dans quels cas on peut vouloir exprimer un chemin relativement depuis un
autre répertoire ?

C'était lié Í  ton file-browser qui change de répertoire courant. Le
comportement recommandé est de ne pas changer de répertoire courant,
pour que les noms de fichiers exprimés relativement en ligne de commande
soient toujours ouverts au bon endroit sans devoir y préfixer le
répertoire courant au moment du lancement du programme.

ok, quand on change de répertoire, on bascule en "tout en chemins
absolus" pour designer les fichiers voulus, mais on ne touche pas au
répertoire courant.

Soit relatif au répertoire courant, soit absolu, Í  choix.

mais elle peut sauvegarder le répertoire
précédent et y revenir

ok pour celui lÍ ,

Sous forme de handle de préférence, car sous forme de chemin -> on
revient au problème que le chemin est moins fort pour identifier que le
handle.

y a-t-il d'autres exemples ? pour la curiosité :-)

Aucune idée :)

Je constate aussi qu'il y a un problème inhérent aux GUI ou plutÍ´t aux
applications qui n'acceptent pas d'être lancées deux fois.

Exemple: je lance deux fois loffice dans deux répertoires différents. La
construction même de loffice fait que le deuxième lancement ouvre en
fait une deuxième fenêtre dans le 1er programme, avec l'environnement
d'exécution du 1er programme (y.c. son répertoire courant).

Pour moi, c'est un bug, mais c'est Í  quoi s'attendent les utilisateurs
Microsoft et Apple.

Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.

gnumeric sous UNIX/X11 par exemple a le comportement auquel je
m'attends, mais pas libreoffice.

- parce que je ne sens pas la prise en charge d'un wrapper script qui va
marcher Í  tous les coups sur toutes les plateformes
(voir l'autre branche du fil)

Un script pour chaque plateforme, plutÍ´t.

si je te comprend bien, écrire sur stdout et stderr ne provoque jamais
aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce
qu'on y envoie tombe dans un puits sans fond ?

Du point de vue de ton application, il est possible que l'écriture dans
ces fichiers retourne une erreur, oui. A toi de la traiter (p.ex. en
l'ignorant ou en la reportant au niveau supérieur: exemple: erreur
d'écriture dans stdout -> warning unique dans stderr).

ce dont je parlais était d'ignorer les erreurs d'écriture dans les
fichiers de logs, puisque les sorties standards suffisent pour récupérer
l'information.

Erreur d'écriture dans fichier de log -> erreur dans stderr et dialogue
graphique vu que c'est quand même quelque chose de rare.

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> modifier du code source ?

Non, pas difficile, si ton application est disponible en code source.

ah bon ? ça m'étonne.
si c'est vraiment simple ça m'arrangerais bien, ça pourrais changer la
suite :-)

Bien souvent, les applications UNIX sont données en source, on fait
./configure --avec-les-trucs-qui-nous-arrangent
make all install

et on a configuré les chemins qu'on veut.

Et si ton application est packagée dans une distribution particulière,
alors en général on va paramétrer tout ça pour que cela respecte les
conventions de cette distribution, de préférence.

http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tki/mcc
_tki/mcc-msg.ads?revision"4&view=markup ( https://urlpetite.fr/5j2 )
comment t'y prendrais-tu ?

C'est une déclaration d'interface, je pense ?

Dans ce cas, je vois deux idées:

- injecter une dépendance Í  un module de configuration générale,
avec des valeurs par défaut (un espèce de "registry" de
configuration o͹ chaque package chercherait des valeurs par
une clé, ici p.ex. la clé Mcc.Msg.ErrorsLogFile_Name
-> variante dynamique

- dans le fichier Ada écrire MCC_MSG_ERROR_LOG_FILE_NAME plutÍ´t
que "rapid_errors.log" et avant de compiler,
appliquer un changement en fonction du fichier configure pour
cette définition, avec des valeurs par défaut
-> variante statique

La première idée est plus puissante, mais complexifie le logiciel. La
deuxième complexifie la phase de génération de l'application / du
package.

et quand c'est toi qui en as besoin, quel nom donnes tu ?

En général mes fichiers sont gérés en contrÍ´le de version (CVS ou Git),
donc je n'ai pas de fichiers de backup.

Mais certains logiciels que j'utilisent ont une convention .old, .orig,
.bak, ~ ... ça m'est assez égal je dois dire.

moins gênant possible pour toi, si jamais un jour tu devais être
l'intégrateur de mon logiciel :-)

Bon, le souci c'est que je ne suis même pas sÍ»r de comprendre l'objectif
:)

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

- une application desktop est un exécutable compilé pour la plateforme
qui l'exécute,

correct, sauf si c'est du bytecode ou du script (python, perl), lÍ  il
n'y a pas de phase de compilation.

par exemple, peut on passer un argument Í  une application web pour
qu'elle lise un fichier de config local ?

Non, bien sÍ»r, il y a des différences.

tandis qu'avec une application bureau client/serveur, il y a une part de
chaque coté, le serveur ne gère pas tout.

Et le client peut envoyer ses logs au serveur, ou pas.

est ce que le debug équivaut Í  des "notifications normales", ou est ce
que c'est autre chose ?

Ah, le debug je l'activerais optionnellement et Í  part.

stdout: informations normales (version du programme, opérations
normales)

stderr: erreurs, évt. debug.

quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive
mode permits only one file on the command line",
comment les catégorises tu ? interaction utilisateur ou erreurs ?

erreurs.

On doit pouvoir faire

ton-programme 2>/dev/null

et n'avoir que des informations et aucun message d'erreur.