Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #7714 > unrolled thread

gérer des fichiers log

Back to article view | Back to fr.comp.os.unix

Contents

  gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-05 21:41 +0200
    Re: gérer des fichiers log yamo' <yamo@beurdin.invalid> - 2021-07-06 09:44 +0200
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-06 14:15 +0200
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-16 22:50 +0200
    Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-06 13:04 +0000
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-06 21:03 +0200
        Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-06 19:52 +0000
          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-06 20:11 +0000
            Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-07 00:42 +0000
              Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-07 06:03 +0000
                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-16 23:03 +0200
                  Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-16 21:09 +0000
                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 00:32 +0200
                      Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-17 07:45 +0000
                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 22:15 +0200
                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:37 +0000
                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:36 +0000
                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 20:44 +0200
                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-18 07:29 +0000
                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 23:05 +0200
                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-21 06:36 +0000
                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 01:58 +0200
                              Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:41 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 19:23 +0200
                                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:29 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-24 17:40 +0200
                                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-24 17:21 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-26 01:15 +0200
                                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-26 14:24 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-28 22:02 +0200
                                      Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 19:12 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-26 03:23 +0200
                                          Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-26 16:45 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-27 17:33 +0200
                                              Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-10-01 16:54 +0000
                                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-10-22 23:41 +0200
                                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-12-19 19:19 +0100
                                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-12-28 12:18 +0100
                                                    Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-12-28 15:56 +0000
                                                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-01-02 00:54 +0100
                                            tags pour les logs Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-17 01:33 +0200
          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 00:06 +0200
            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:40 +0000
              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 18:43 +0200
                Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-18 07:30 +0000
                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 21:23 +0200
                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-20 19:32 +0000
                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-21 00:39 +0200
                        Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-21 06:42 +0000
                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-22 20:41 +0200
                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-22 18:58 +0000
                              Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-22 19:25 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 03:03 +0200
                                  Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-23 04:07 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 01:41 +0200
                                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:49 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 21:11 +0200
                                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:43 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-24 19:12 +0200
                                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-24 17:36 +0000
                                            Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 19:24 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-25 23:40 +0200
                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 02:32 +0200
                                Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:59 +0000
                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 19:23 +0200
                                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:40 +0000
                                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-25 21:04 +0200
                                        Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-26 14:30 +0000
                                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-27 15:32 +0200
                                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-27 15:44 +0000
                                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-16 23:25 +0200
                                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2022-09-17 05:56 +0000
                                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-17 15:46 +0200
                    Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-20 20:28 +0000
                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 23:33 +0200
                        Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-21 15:31 +0000
                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-22 17:12 +0200
                            Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-07-24 13:36 +0000
                              Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-24 14:09 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 14:44 +0200
                                  Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-09-23 12:54 +0000
                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-08-09 20:57 +0200
                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 14:38 +0200
    Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-23 04:03 +0000
    Re: g�rer des fichiers log garkbeda43 <nospam_garkbeda43@gmail.com.invalid> - 2022-06-11 02:27 -0500
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-30 16:42 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#7794

Le 24-09-2021, Marc SCHAEFER <schaefer@alphanet.ch> a écrit :
>
> Typiquement, sous UNIX, il m'est arrivé de configurer des applications
> de manière à ce que le le log aille dans:
>
>    /network/fs.toto.ch/logs/$CLIENT/application-${UNIQUE}.log
>
> et par la magie de l'automounter, les logs finissent sur le serveur
> fs.toto.ch, dans le répertoire correspondant au nom du client, dans un
> fichier correspondant au nom de l'application suffixée d'une valeur
> unique contenant la date.
>
> Evidemment, ça marche uniquement dans un réseau intégré ("domaine").
>
> Autre technique que j'ai utilisée: quand le programme se termine, le log
> est pushé sur le serveur par HTTPS.

Là, tu commences à parler de cas très particuliers et ce n'est
clairement plus le problème du développeur. C'est de l'administration
système pure. Bien sûr, il ne faut pas que le développeur gêne
l'administration système.

> Mais fais attention, tu poses des questions dans toutes les directions,
> donc tu risques d'avoir des réponses dans toutes les directions.

Voilà.

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

[toc] | [prev] | [next] | [standalone]

#7796

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > le bytecode c'est le truc qu'on fait interpréter par les JVM ?
> 
> Le bytecode pur est interprété, pas compilé, par la JVM.
> 
> > (dans ce cas là il y a un peu de compilation quand même, puisque c'est 
> > du code intermédiaire)

ah bon,
pour moi la compilation c'est transformer le code source en qqch de plus 
compact, pas pas forcément du code natif
(mais c'est pas le sujet d'ici)


> > par contre, si c'est le logiciel lui-même qui doit envoyer ses logs au 
> > serveur, je ne crois pas que ça puisse très bien marcher si c'est 
> > l'intégrateur qui est chargé de gérer les fichiers !

[comme dit Stéphane CARPENTIER  : administration système pure]

(dans ce cas là c'est pas le logiciel lui-même qui gère ça, c'est toi 
l'administrateur système qui a parametré ce qu'il fallait autour)


> Mais fais attention, tu poses des questions dans toutes les directions,
> donc tu risques d'avoir des réponses dans toutes les directions.

je crois que tu veux dire que je m'éparpille, et que tu me suggère de me 
recentrer sur ce qui est important pour moi tout de suite.

je t'approuve, et je vais tenter de le faire :-)

ce que je te propose c'est que,
pour un certain nb de choses où je pense avoir compris ce que j'ai à 
faire,
je vais juste faire des affirmations, sans être certain que j'ai raison,
mais comme ça si c'est le cas tu pourras juste les couper dans tes 
réponses suivantes,
ça nous permettra d'avancer plus vite :-)


> 
> >> Ah, le debug je l'activerais optionnellement et à part.
> > 
> > oui, ça c'est déjà fait (mais si on l'active il faut bien que je le 
> > traite).
> > 
> > (heu ... ça veut dire quoi "à part" ?)
> 
> dans un fichier séparé.

ok,
quand j'ai fait les fichiers ça a fait partie de mes réflexes.

mais avec les sorties standards, ça me semble plus compliqué.
(d'où les questions suivantes)

> 
> > as tu des exemples d'opérations normales ?
> > (on était en mode graphique, là)
> 
> L'application graphique a réussi à charger le fichier toto.
> Le fichier toto a été modifié en appliquant l'instruction blala.
> 
> (c'est du debug, donc).

oui :-)
donc ... debug : stdout ou stderr ?
ou peut être que ça dépend si on est en GUI ou en CLI ?

ou alors dis-tu comme Stéphane CARPENTIER : c'est pas forcément très 
utile de se casser la tête avec ça ?


> 
> > quand tu dis "version du programme",
> > est-ce que tu parles seulement d'une option "--version",
> > ou bien est-ce que ça vaut aussi pour la version du programme qui est 
> > affichée automatiquement quand on active le debug ?
> 
> Là je ne suis plus, désolé.

désolé, c'est moi qui n'ai pas pris le temps de bien poser les choses :

- je n'ai pas d'option "--version",
est-ce nécessaire ? je ne pense pas, il y a un équivalant dans la GUI.

- je n'ai pas d'option "--help",
est-ce nécessaire ? je ne pense pas, il suffira de taper un truc 
incorrect (par ex "--help").

en fait ce que j'ai, c'est du debug optionnel, et quand on l'active ça 
affiche la version du programme, sinon non.

vu ce que tu dis sur --help, je suppose que pour --version c'est pareil :
- si j'avais fait une option "--version", ça serais allé sur stdout,
- mais quand on active le debug, ça va avec le debug qq soit le 
traitement.


> 
> > j'ai oublié de te demander, mais je suppose que si on a un "usage: ..." 
> > c'est pareil.

> Donc, dans ce cas de mettre l'erreur (mauvais arguments) et le message
> d'"usage" dans stderr.
> 
> Par contre, si tu traites un --help, alors je mettrais la "réponse" dans
> stdout.

merci pour la distinction :-)


> > si on active le debug, est ce qu'on doit n'avoir aucun msg de debug, 
> > mais avoir la version qui s'affiche en plus ?
> 
> Je ne vois pas pourquoi la version serait nécessaire, ou alors au début
> du debug pour t'aider à trier les éventuels rapports de bug?

c'était comme ça quand je l'ai repris, alors j'ai supposé que ça faisait 
partie des "bonnes pratiques" d'avoir la version qui s'affiche au début 
du debug
(de mon coté je n'en sais pas plus)

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

[toc] | [prev] | [next] | [standalone]

#7760

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

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

> > que me conseillerais tu ?
> 
> Difficile à dire. Peut-être devrais-tu commencer à décrire exactement ce
> que fait ton application.  Jusqu'ici on a compris que ça permettait
> d'éditer des fichiers d'interfaces graphiques (IHM/GUI) et que ça
> générait des logs.

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).

mais peut être as tu besoin d'autres détails ?

> Toute application a toujours un core et une partie framework ou
> bibliothèque où l'on regroupe les éléments essentiels.

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 ;-) )


>  
> > parallèlement à ça, j'aime mieux que des fichiers de log soient générés 
> > immédiatement, en plus de stdout et stderr,
> 
> Non, ceci serait de la duplication de travail par rapport à écrire un
> simple wrapper shell du genre:
> 
> #! /bin/bash

merci bcp pour l'exemple :-)

> . ~/.config-APPLICATION/defines

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),
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 ?

> > est ce que de ton point de vue, c'est à moi de faire le wrapper ?
> 
> Vu que tu viens d'exprimer le besoin de sauver des fichiers logs,
> oui :)

ça génère qques inconvénients supplémentaires, notamment pour la 
portabilité :

par exemple, si un novice qui compilerais mon application à partir des 
sources, sous windows, me dit :
- que ça ne marche pas,
- que quand il clique sur le wrapper, ça lui ouvre le script dans un 
éditeur de texte,
- que quand il clique sur l'exécutable, ça ne lui affiche aucune fenêtre 
"shell" (je ne sais plus comment ils appellent ça sous windows), donc il 
ne sait pas comment afficher les erreurs

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


> 
> > ben non, justement, comme c'est ajouté à la fin ça casse l'extension ! 
> 
> C'était exprès. En tant qu'utilisateur, je ne veux pas qu'il soit trop
> facile de se tromper entre un original et une vieille copie.
> 
> Il faut choisir le bon backup, et le renommer pour y accéder, cela me
> semble une excellente chose à faire pour éviter la confusion.

bon argument :-)


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

c'est pas qqch à base de '~' ?
ou alors ça n'est que sous windows, que les gens font ça ?

> 
> Si ton application plante tellement souvent qu'il est une opération très
> courante de devoir accéder aux backups et pas aux originaux

je vais tacher d'arranger ça ;-)

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 :-)

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

[toc] | [prev] | [next] | [standalone]

#7766

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.

[toc] | [prev] | [next] | [standalone]

#7777

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/

[toc] | [prev] | [next] | [standalone]

#7782

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=224&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
:)

[toc] | [prev] | [next] | [standalone]

#7795

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

> 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

chez moi je n'ai que le `make all` pour l'instant.

si j'ai bien compris, le ./configure on le fait comme on veut à 
l'intérieur, il n'y a que la façon de lui passer les arguments qui doit 
plus ou moins respecter un usage.

il y a quand même un truc qui m'échappe :
pourquoi la généralité c'est bcp plus `./configure` que `make config` ?

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

ok, c'est pas ce à quoi je pensais en disant "modifier du code source" 
:-)

mais du coup, entretemps, j'ai eu l'idée qui te permettra,
en attendant mieux, de commenter juste une ligne pour arrêter 
complètement la génération de fichiers log par le logiciel,
pour te permettre de gérer ça juste avec les sorties standards sans être 
dérangé :-)



> > 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 ?
> 
> C'est une déclaration d'interface, je pense ?

oui, en ada on dit une "spécification" :-)

> 
> Dans ce cas, je vois deux idées:
> 
>    - injecter une dépendance à un module de configuration générale,

>        -> variante dynamique

je ne sais pas s'il y a qqch qui existe déjà pour faire ça en ada.

mais c'est pas grave,
ce qui me *** c'est l'analyse de texte, et en fait il y en a déjà pour 
lire les fichiers de l'application (qui sont aussi en texte),
donc un peu plus tard, je pourrai reprendre ça pour lire le fichier de 
config :-)

> 
>    - dans le fichier Ada écrire MCC_MSG_ERROR_LOG_FILE_NAME plutôt
>      que "rapid_errors.log"

>         -> variante statique

oui, c'est du Preprocessing :-)
je n'en ai jamais fait, mais j'ai vu qu'on peut en faire aussi en ada :-)
d'ailleurs il y a des cas où ça aiderais à l'optimisation ! il faudrait 
que je regarde ça de plus près !

pour toi, ça ne serais pas trop rigide, de ne plus rien pouvoir 
configurer post-compilation ?



> > 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.

tu sauvegardes tes données avec un CVS ?

moi je sauvegarde 1 fois par jour, donc si je travaille 1 journée 
entière, j'aime bien avoir des fichiers de backup intermédiaires :-)

et si je te suis bien, dans tous les logiciels que tu fais, même pour 
les autres, tu n'as jamais besoin d'en faire non plus ?

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

si je t'ai bien suivi, tous ces logiciels ajoutent tjr à la fin du nom 
après leur extension "ordinaire", pour t'empêcher d'ouvrir le fichier de 
backup par erreur ?


> 
> > 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
> :)

je ne suis pas sur de comprendre la question.
- comme tu m'a dit avoir le point de vue d'un intégrateur, je pars de 
l'hypothèse où tu aurais à intégrer le logiciel que je développe.
- je souhaite que, malgré la part de conseils qu'on me donne ici 
auxquels je ne souhaite pas me conformer, je réussisse à "arrondir les 
angles" suffisamment pour que ça ne te rende pas la tache trop 
désagréable :-)

j'ai l'impression qu'on en prend le chemin, j'espère que tu la partages 
(l'impression) :-)

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

[toc] | [prev] | [next] | [standalone]

#7800

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> pourquoi la généralité c'est bcp plus `./configure` que `make config` ?

configure est tout un environnement à son (autoconf), qui génère tout
y.c. Makefile.

> oui, c'est du Preprocessing :-)

tout à fait.

Tu peux alors centraliser tes définitions dans un fichier de
constantes/préprocessing généré par le configurateur avant compilation.

> pour toi, ça ne serais pas trop rigide, de ne plus rien pouvoir 
> configurer post-compilation ?

Ca dépend de l'application, mais dans certains cas c'est acceptable, en
particulier si c'est open source.

> tu sauvegardes tes données avec un CVS ?

Non, je les mets à disposition à plusieurs endroit de manière
journalisée :)

Et un de ces endroits fait effectivement une sauvegarde automatique hors
site.

> et si je te suis bien, dans tous les logiciels que tu fais, même pour 
> les autres, tu n'as jamais besoin d'en faire non plus ?

Pas sûr de comprendre en quoi avoir un système qui me permet de
retrouver mes données hors site en cas de problème, à chaque
modification que je trouve importante est insuffisant?

> si je t'ai bien suivi, tous ces logiciels ajoutent tjr à la fin du nom 
> après leur extension "ordinaire", pour t'empêcher d'ouvrir le fichier de 
> backup par erreur ?

ah non, ils ne m'empêchent de rien du tout?!

D'ailleurs j'aimais bien l'idée du système de fichier à versionning de
VMS: le fichier toto devient toto;1 si on le modifie. C'est ainsi que je
vois l'idée que certains programmes ajoutent un ".orig" ou un ~: du
versionning du pauvre.

[toc] | [prev] | [next] | [standalone]

#7802

In article <siq061$3u2$2@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > pourquoi la généralité c'est bcp plus `./configure` que `make config` ?
> 
> configure est tout un environnement à son (autoconf), qui génère tout
> y.c. Makefile.

je ne comprend pas ...
peux tu reformuler stp ? :-)

> 
> > oui, c'est du Preprocessing :-)
> 
> tout à fait.
> 
> Tu peux alors centraliser tes définitions dans un fichier de
> constantes/préprocessing généré par le configurateur avant compilation.

oui, pour éviter que le préprocessing soit éparpillé :-)

je ne vais pas le faire immédiatement,
mais il me manquait qqch pour transmettre des données entre le Makefile 
et le code ada, on dirait que c'est l'outil qu'il me manquait :-)

et en plus ça permet d'éliminer plein de code mort à la compilation :-)


> 
> > pour toi, ça ne serais pas trop rigide, de ne plus rien pouvoir 
> > configurer post-compilation ?
> 
> Ca dépend de l'application, mais dans certains cas c'est acceptable, en
> particulier si c'est open source.

je verrai ça plus tard.

il y a un coté pratique à avoir des constantes à la compilation,
mais à moyen/long terme, le fichier de config me parait acceptable aussi,
surtout si je veux pouvoir éditer des préférences :-)
(et rien n'empêche d'en avoir 2 : un pour l'intégrateur et un pour la 
GUI ;-) )


> > et si je te suis bien, dans tous les logiciels que tu fais, même pour 
> > les autres, tu n'as jamais besoin d'en faire non plus ?
> 
> Pas sûr de comprendre en quoi avoir un système qui me permet de
> retrouver mes données hors site en cas de problème, à chaque
> modification que je trouve importante est insuffisant?

tu choisis tes critères,
moi j'aime bien avoir la journalisation comme tu dis ci dessous ;-)

en fait journalisation et sauvegarde n'ont pas exactement le même rôle

moi je n'ai pas de VCS interne, je n'ai que celui qui est publique,
sur lequel je m'efforce de ne publier que des trucs "publiables",
pas des états intermédiaires qui ne marchent pas ;-)


> D'ailleurs j'aimais bien l'idée du système de fichier à versionning de
> VMS: le fichier toto devient toto;1 si on le modifie. C'est ainsi que je
> vois l'idée que certains programmes ajoutent un ".orig" ou un ~: du
> versionning du pauvre.

d'où l'idée que j'ai proposée en démarrant ce fil, avec les n° 
incrémentés dans le nom du fichier ;-)
mais je comprend que ça soit aux utilisateurs de le gérer, et pas aux 
applications.

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

[toc] | [prev] | [next] | [standalone]

#7804

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> configure est tout un environnement à son (autoconf), qui génère tout
>> y.c. Makefile.
> 
> je ne comprend pas ...
> peux tu reformuler stp ? :-)

Une introduction se trouve ici:

   https://fr.wikipedia.org/wiki/Autoconf

[toc] | [prev] | [next] | [standalone]

#8015

In article <siq061$3u2$2@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > pourquoi la généralité c'est bcp plus `./configure` que `make config` ?
> 
> configure est tout un environnement à son (autoconf), qui génère tout
> y.c. Makefile.

est-ce qu'il vaut mieux que je reste à `make config` tant que je 
n'utilise pas autoconf ?
ou bien, est-ce que c'est bien d'imiter autoconf pour ne pas dépayser 
ceux qui en ont l'habitude ?

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

[toc] | [prev] | [next] | [standalone]

#8017

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> est-ce qu'il vaut mieux que je reste à `make config` tant que je 
> n'utilise pas autoconf ?

tant que c'est documenté dans un fichier INSTALL ...

[toc] | [prev] | [next] | [standalone]

#8018

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > est-ce qu'il vaut mieux que je reste à `make config` tant que je 
> > n'utilise pas autoconf ?
> 
> tant que c'est documenté dans un fichier INSTALL ...

ok, merci :-)

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

[toc] | [prev] | [next] | [standalone]

#7747

Thomas , dans le message
<fantome.forums.tDeContes-34DA16.21230820072021@news.free.fr>, a écrit :
> Nicolas me suggérais par ex d'utiliser un "timestamp" à la seconde, 
> plutôt qu'un "timestamp" au jour + un n° incrémental,

Mais pour ton problème clarifié, je ne suggère rien du tout car il est
fondamentalement mal posé.

[toc] | [prev] | [next] | [standalone]

#7750

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

> Thomas , dans le message
> <fantome.forums.tDeContes-34DA16.21230820072021@news.free.fr>, a écrit :
> > Nicolas me suggérais par ex d'utiliser un "timestamp" à la seconde, 
> > plutôt qu'un "timestamp" au jour + un n° incrémental,
> 
> Mais pour ton problème clarifié, je ne suggère rien du tout car il est
> fondamentalement mal posé.

dans ce cas, pourrais tu m'aider à le poser mieux, stp ?

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

[toc] | [prev] | [next] | [standalone]

#7754

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.

[toc] | [prev] | [next] | [standalone]

#7755

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.)

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

[toc] | [prev] | [next] | [standalone]

#7769

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

[toc] | [prev] | [next] | [standalone]

#7770

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.

[toc] | [prev] | [next] | [standalone]

#7786

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

> 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 en cas d'échec catastrophique, comment sait on par quels états on est 
passés avant, qui nous ont conduits à la catastrophe ?


> 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.

mais, comment savoir si / en quoi ce sont des exceptions, si on n'a pas 
l'énergie pour communiquer ?

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

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | fr.comp.os.unix

csiph-web