Re: gérer des fichiers log

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=224&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/