Insertion dans un fichier pour un logger.

Bonjour, Je vais exposer plus précisément mon problème d'origine ( quelques posts plus bas) ainsi que la seule solution que j'ai trouvée pour le moment ( non testé).

Je vous présente ma solution car elle me parait assez couteuse en temps pour un class de log qui se veux discrète et très légère.

Au début de mon prog, j'ai une ptite phase d'initialisation dan laquelle je cré un fichier ( le rempalce, vide si existant ) de log, dans lequel j'insérer quelques balises xml, dont une ouverte, destiné a contenir tout mes log .

Ensuite dans mon prog j'ajoute en fin de fichiers des balises ( qui seront contenu dans celle ouverte précédement ) pour chaque log.

Enfin lors de phase de fermetur de mon programme j'ajoute la balise de fin ( sa fermeture).

Tout va bien dans le meilleur des monde, *sauf* que lors d'un crash avant la phase de fermeture, je me retrouve avec un fichier xml mal formé ( absence de la fermeture de la balise root ) et donc inexploitable a mois de modifier moi même le fichier à la main, ce qui devient TRES vite fastidieux après la 10ième fois.

Il me faut donc un moyen d'avoir quoi qu'il arrive un fichier xml bien formé.
Je ne connais pas de solution pour faire ca a la volée lors de l'ouverture de mon document par IE par exemple. [ le document xml est transformé en xhtml par du xslt ].

Seul moyen que j'ai trouvé :

//Initialisation
Créer le fichier au départ, en gardant en mémoire la position (seekp() sur notre stream ) de l'endroit juste aprés que la balise principale soit ouverte.

// A chaque log
On se place en "position" et on ajoute ce qu'on doit ajouter, puis on garde la position en fin d'ajout en mémoire . Et ensuite on ajoute la fermeture de la balise principale.

// Phase de fermeture
Rien

Ca me parait assez barbare mais je ne voit pas mieux ... vous avez des idées?

Une idée comme ça (jamais utilisé, j'ai arrêté d'essayer du XML pour mes logs, ça coûte trop cher et j'ai pas les moyens).
Ton exécutable pourrait générer un XML non valide (sans <root> et </root>)
tu fais un programme qui lit logs et éventuellement ajoute la racine root pour que ton fichier d'origine devienne un XML valide pour être lu par firefox par exemple.

Sinon, une autre idée plus dur... évite les crash ;)

L'idée m'était venu aussi de faire a l'arrache un petit prog qui ajoute la balise si elle n'y est pas ... bon ca force a cliquer dessus entra chaque crash, c'est pas inhumain, mais il y a peut-etre mieux ^^

qu'est ce que vous pensez de mon idée de noob qui consisterai à écrire les logs dans une base de données ? les fichiers n'étant pas fait pour insérer des trucs

<disgressions>
L'XML pour le log me parait bizarre -- j'analyse régulièrement des logs qui font déjà facilement dans la 100aine de méga, avec vim, c'est un vrai bonheur.

Perso, j'aime bien les crashs, ça fait des core, et ça s'analyse bien mieux qu'un log jamais assez verbeux.
</>

Ton fichier de log, tu l'ouvres bien avec un outil, non ?
Ne peut-il pas ajouter ce qui manque à la volée?
- Si tu lances une commande depuis un shell, se faire un script qui rajoute ce qui manque est immédiat.
- Si tu doubles-cliques sur ton fichier, associes-lui un batch/script qui rajoute ce qui manque éventuellement (suite à un grep sur les résultats de head et de tail -- ou autres équivalents pour ta plateforme), et lances ensuite l'application qui te permet de manipuler ton fichier de log depuis ce même script.

Citation:

---

Si tu doubles-cliques sur ton fichier, associes-lui un batch/script qui rajoute ce qui manque éventuellement (suite à un grep sur les résultats de head et de tail -- ou autres équivalents pour ta plateforme), et lances ensuite l'application qui te permet de manipuler ton fichier de log depuis ce même script.

---

Je suis sous windows mais je vais voir l'equivalent .
[ j'ouvre le tout en double-click sous IE ]

Concernant la bdd je trouve ca un peu artiellerie lourde pour un simple log :)

Citation:

---

Perso, j'aime bien les crashs, ça fait des core, et ça s'analyse bien mieux qu'un log jamais assez verbeux.

---

Tu as sans doute raison, mais pour le moment je me contente de choses simple :) je verrai les dump de la mémoire lors de crash plus tard :) Mais l'idée est interessante .

bah je sais pas sqlite c pas tres lourd par exemple comme bd. et t'as des viewers sympa qui vont avec les bdd

et puis quand on veut faire de l'insertion, c'est plus "un simple log" ^^

Je fais de l'insertion juste pour eviter les bug sur crash, en pratique, je n'ai vraiment pas besoin d'insertion :)

Citation:

---

Envoyé par Luc Hermitte

...
Perso, j'aime bien les crashs, ça fait des core, et ça s'analyse bien mieux qu'un log jamais assez verbeux.

---

Aimer les cores, c'est à limite du masochisme quand même :lol:

Mais, pour le verbeux, et l'utilité des cores
j'aurais catégorisé en 2 groupes les logs :
- le log d'exploitation qui permet de suivre où en être en traitement, avec des erreurs techniques (erreur BD, disque) possible pouvant être reprise plus tard, lutôt pour des non développeurs.
- les traces (qui permettent de suivre l'états de variables dans une boucle par exemple) permettant de remonter des erreurs fonctionnelles - Le programme ne core pas mais ne fait pas ce qu'il faut - à destination des développeurs.

mais aucun des deux ne sont utiles dans le cas d'un core, au mieux le deuxième pourrait donner une piste si assez complet.


mamelouk:
inserer un log dans une base ça semble en effet un peu lourd.
Je ne vois pas comment on pourrait justifier qu'un traitement à planter parce que le logger à eu un deadlock lors de l'insertion d'une trace dans la base.

Citation:

---

Envoyé par Clad3

Tu as sans doute raison, mais pour le moment je me contente de choses simple je verrai les dump de la mémoire lors de crash plus tard Mais l'idée est interessante .

---

Refaire une IHM pour utiliser un core ? (conjointement avec ton binaire en mode debug ) c'est pas un peu trop aussi ça ?

Citation:

---

Envoyé par Hylvenir

Aimer les cores, c'est à limite du masochisme quand même :lol:

---

C'est generalement parmi les problemes les plus faciles a debugger. Les pires, c'est "le resultat ne correle pas avec les mesures physiques; non, vous ne pouvez pas avoir les donnees initiales ayant servit aux calculs ni les mesures".

C'est drôle aussi quand le résultat est différent entre deux lancements
ou que le résultat devient bon en changeant les options de compil (optimisation, debug).

Citation:

---

Envoyé par Hylvenir

le résultat devient bon en changeant les options de compil (optimisation, debug).

---

Dicotomie sur les bibliotheques, puis sur les fichiers, puis sur les fonctions puis on decoupe la fonction, et on regarde l'assembleur genere pour une fonction minimale. Been there, done that, got the T-shirt yet another bug in the optimizer mais le plus souvent, c'est "qu'on est con...". C'est du boulot, mais assez routinier.

j'irai pour la dernière option pratiquement dans tous les cas ;)

Citation:

---

Envoyé par Hylvenir

j'irai pour la dernière option pratiquement dans tous les cas ;)

---

Même si j'ai rapporté des bugs pour tous les compilateurs que j'ai utilisé de manière professionnelle, je suis dans ton cas: la plupart des problème proviennent du programme, pas du compilateur.