Bonjour à toi journal !

Je cherche actuellement à optimiser _et_ à surveiller le comportement d'une application en C un peu complexe.
Par surveiller, je veux dire "est-ce que l'application a bien exécuté cette fonction ?", "quel est le résultat de cette opération ?".

Pour la surveillance, rien de plus simple que de mettre des traces dans le logiciel, à coup de "fprintf(stderr, "Trace gna gna gna\n");", on se rend compte très vite du comportement de la bête. On peut même post-processer les traces sur des exécutions "longues".

On peut pousser plus loin la logique et essayer d'optimiser l'application à partir de ces informations. Par exemple, on peut ajouter un "fprintf(stderr, "%ld trace \n", get_cycle());" pour ajouter un élément "timing" à la trace.
Mais les mesures de temps sont forcément imprécises (elles dépendent des tampons sur le flux, etc...).

A partir de là, on pourrait penser à un thread qui ne servirait qu'à collecter les informations ou alors à une zone de mémoire partagée entre l'application et un collecteur de données. Mais ça demandent un investissement et un temps de développement plus important que de placer des "fprintf" dans un code.

Notez que le passage d'un profileur type gprof/sprof n'est pas toujours d'un grand secours quand le code contient de grosses fonctions, des inlines et des macros. :)

Je suis donc à la recherche d'un outil qui permettent "d'instrumenter" le code (par exemple en insérant des appels à des macros dans le code) puis de le tracer avec des mesures de temps, a l'exécution.

J'ai déjà utiliser le Posix Thread Trace Toolkit [1] et c'est plutôt pas mal. Malheureusement les points de trace sont limités aux fonctions de manipulation de thread. (A ma connaissance, il n'est pas possible de spécifier des points de trace arbitraires dans le code d'une application).

Pour un peu plus préciser ce qui me ferait rêver, j'ai trouvé une interface "TimeDoctor" [2] qui affiche des évènements. On pourrait imaginer que chaque ligne constitue un thread de l'application, et que chaque évènements soient liés à une activité particulière du thread (appel d'une macro dans le thread).

Avez-vous des pistes ?

[1] : http://nptltracetool.sourceforge.net/
[2] : http://sourceforge.net/project/screenshots.php?group_id=1747(...)

> Lire le journal (12 commentaires, moyenne: 2,8).

Salut à toi journal !

Aujourd'hui je veux te parler de dl.free.fr le service d'échange de fichiers de free et te donner une petite astuce.

Au début de ce service les fichiers étaient disponibles directement, on pouvait donc les télécharger simplement avec un
wget urlFichier
On pouvait reprendre un téléchargement interrompu avec un
wget -c urlFichier

Depuis la mise à jour du service, wget urlFichier, retourne la page html du service.

Pour continuer à télécharger avec wget, il faut maintenant faire :


#First step is set cookie
wget --save-cookies cookie.txt --keep-session-cookies urlFichier -O tmpFile

#Second step is retry with cookie
wget -c --load-cookies cookie.txt urlFichier

#Then clean tmp file
rm tmpFile cookie.txt


A nous les reprises de téléchargements sur dl.free.fr avec wget !

> Lire le journal (5 commentaires, moyenne: 3).

Salut à toi Journal !

Je t'écris pour te poser une question "technique", limite philosophique.

Suite à ce journal : http://linuxfr.org/~Montaigne/24628.html, je me suis demandé comment pourrait faire une application sous linux en user-space, pour auto-générer son code. Je cherchais une solution efficace et performante (en c par exemple).

La première solution à laquelle j'ai pensé est relativement sale : j'écris du code dans un .c (fwrite...), je le compile avec un appel à gcc (system...) sous forme de .so que j'ouvre avec dlopen.

En deuxième solution, je voyais "smasher" la stack de mon propre programme, mais là je trouve ça... inqualifiablement affreux.

Cher lecteur, connais-tu une solution à cet épineux problème ? A noter que je n'y vois pas d'intérêt pratique, c'est juste pour la culture.

Merci !

> Lire le journal (24 commentaires, moyenne: 3).