Les fichiers de conf en xml, quel intérêt ?

Le Tue, 19 Oct 2010 21:08:32 +0200,
Aeris <aeris@imirhil.fr> écrivait :

JKB wrote:

La lecture se fait en plusieurs étapes :
1/ lecture du fichier en mode binaire, stockage dans une table et
analyse de la table à grands coups de métriques pour savoir dans
quel encodage est le fichier.
2/ récupération de l'encodage ayant le meilleur taux de
vraisemblance.
3/ si le taux est de 1, le fichier est correct. S'il est différent
de 1, il y a une erreur et on envoie un message d'insulte en
refusant de continuer.
4/ on relit le fichier en mode caractère (octet ou non) en

fonction

de l'encodage trouvé en supprimant les commentaires et les retours

à

la ligne.
5/ on convertit le fichier lu dans un encodage fixe et connu (par
exemple UTF-8) en vérifiant soit que tous les caractères sont
convertibles, soit qu'on remplace les caractères non convertibles
par le caractère le plus proche dans l'encodage cible.
6/ on analyse la structure pour voir si ce contenu est
cohérent (ne pas avoir par exemple de lignes comme A=1=1... Ou des
délimiteurs qui ne sont pas fermés... Ça dépend de la syntaxe

utilisée).

7/ on analyse le contenu.

Donc si je résume, on part d'un bête fichier de configuration.
On fout un gros coup d'analyse de grammaire contextuelle là dedans, une des
pires à analyser informatiquement.
On balance des probas dignes d'un docteur de mathématiques avancées pour
l'informatique, à grand coup de calcul de vraisemblances, de probabilités...
On fait un programme en logique floue pour être capable de gérer le cas du
"proba encodage < 1" ou même "plusieurs encodages à proba maximale
identique".
On fait bien sûr 4 ou 5 lectures du fichier, et on prend bien soin de
stocker tout ça dans de superbes grosses structures de données (qui pèseront
100x le fichier à lui tout seul), histoire qu'on ne puisse pas faire de
lecture en flux continu (qui a dit SAX?).
Ensuite là on prend son pied à gros coup d'algos bien goulus qui vont
tripatouiller les structures dans tous les coins, histoire de trouver ce que
ce fichier veut bien dire (ou pas).
Et voila, on a un joli fichier de conf de 10ko........ et un algo
probabilistique contextuel de 140MO qui ne peut pas tourner sur une machine
à moins de 3Go de RAM et 4Ghz de CPU. Et encore, il n'a même pas le luxe
d'avoir 100% de probabilité d'avoir détecter le bon encodage!

Contrairement à ce que tu penses, il te suffit d'une lecture du
fichier pour détecter le bon encodage. Et l'algorithme est un grand
classique. Quant à tes structures de fichiers, c'est un simple
tableau de caractères. Rien d'exceptionnel. L'algo lui-même est en
O(2L) si ma mémoire est bonne, avec L, la longueur de ta zone de mémoire.
Pas de quoi fouetter un chat.

Je ne parle même pas de la complexité à y intégrer un nouvel encodage,

Hors de propo, ce sont des fichiers d'encodage annexe. Rajouter un
nouvel encodage ne coûte quasiment rien.

à
être robuste aux changements (oups, j'ai changé le format de mon fichier, je
rappelle le docteur es Math et le linguisticien?),

Hors de propo.

à résister à l'analyse
d'un fichier de 10Mo (oups, NotEnoughMemoryException...), à avoir un code
portable (oups, j'ai compilé sur une machine UTF8 mais je l'exécute sur une
machine ISO88591).

Qu'est-ce qu'il ne faut pas lire. J'arrête là. Au fait, c'est
exactement à cause de ce dernier problème que j'ai commencé à écrire
des routines de conversion il y a des lustres.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB , dans le message <slrnibrisq.gq8.jkb@rayleigh.systella.fr>, a
écrit :

La structure XML, c'est la structure du XML.

Tu es fatiguant à asséner des platitudes sur des sujets que tu ignores comme
si c'étaient des arguments. La structure du XML, c'est aussi bien :

<convert
input="some_file"
output="some_other_file"
mode="auto"
quality="10"
/>

Que :

<convert:convert xmlns:convert="http://www.example.com/xmlns/convert>
<convert:param>
<convert:param-name>input</convert:param-name>
<convert:param-type>string</convert:param-type>
<convert:param-value>some_file</convert:param-value>
</convert:param>
<convert:param>
<convert:param-name>output</convert:param-name>
<convert:param-type>string</convert:param-type>
<convert:param-value>some_other_file</convert:param-value>
</convert:param>
<convert:param>
<convert:param-name>mode</convert:param-name>
<convert:param-type>enum</convert:param-type>
<convert:param-value>auto</convert:param-value>
</convert:param>
<convert:param>
<convert:param-name>quality</convert:param-name>
<convert:param-type>integer</convert:param-type>
<convert:param-value>10</convert:param-value>
</convert:param>
</convert:convert>

Les deux sont du XML bien formé (à moins d'une erreur de frappe de ma part),
les deux disent la même chose, mais le premier est parfaitement lisible, et
pas le second.

<EOT>

You keep using that word. I do not think it means what you think it means.

Nicolas George <nicolas$george@salle-s.org> wrote:

Les deux sont du XML bien formé (à moins d'une erreur de frappe de ma part),
les deux disent la même chose, mais le premier est parfaitement lisible, et
pas le second.

Le second me rappelle un fichier de conf de hald qu'il a fallu que
je toutouille pour régler mon serveur X. Là je me suis dit qu'il y avait
des baffes qui se perdaient, et que les programmeurs qui ont pondu ça
on aurait mieux fait de les envoyer faire les chiottes. D'ailleurs on
dit que la principale raison pour laquelle les productions de Microsoft
sont aussi médiocres, c'est qu'ils recrutent tous les ans les meilleurs
diplômés des meilleures universités, qui n'ont rien de plus pressé que
d'appliquer froidement les dernières fadaises qu'on leur a enseignées
à la fac.


--

Michel TALON

Michel Talon a écrit :

qui n'ont rien de plus pressé que
d'appliquer froidement les dernières fadaises qu'on leur a enseigné es
à la fac.

bon ok

le xml est un méta format
et que tu le veuilles ou pas ,c'est très puissant
c'est la mise en application du design pattern mcv

en gros xml + feuille de style cela donne le html actuel
ou le format de fichier open office
ou de manière plus modeste le format de fichier qui traine sur la page
http://remyaumeunier.chez-alice.fr/codeSourceGene/essai.TxtImg
je peux enrichir le format en 3 coups de cuillères à pot


pour les fichiers de config
cela permet de créer des paires de clés valeur
associées à un contexte ,structure dans laquelle est effectuée
l'association

avec un simple cerveau cela permet de comprendre en principe à quoi
correspond l'association je n'ai plus à connaitre la syntaxe d'un
fichier de config ou à savoir

machinBidule 10:1215, -avkj :1536 fait la même chose que
trucMucheAlaCon -bphkt 123:1579



à titre personnel je serai pour que tous les fichiers
de config respectent un certain formalisme

et pour faire passer la pilule aux vieux râleurs impénitents il
suffirait de leur dire que le xml et le Latext c'est exactement la mêm e
chose ben là subitement cela devient super puissant, super vieux, et
l'on se demande même comment on a pu s'en passer




remy









--
http://remyaumeunier.chez-alice.fr/

remy <remy@fctpas.fr> wrote:

Michel Talon a écrit :

> qui n'ont rien de plus pressé que
> d'appliquer froidement les dernières fadaises qu'on leur a enseignées
> à la fac.
>
>

bon ok

le xml est un méta format
et que tu le veuilles ou pas ,c'est très puissant
c'est la mise en application du design pattern mcv

J'aurais cru t'avoir fait comprendre ce que je pensais des "design
patterns". En tant que scientifique je laisse la propagande et la pseudo
philosophie aux charlatans.

et pour faire passer la pilule aux vieux râleurs impénitents il
suffirait de leur dire que le xml et le Latext c'est exactement la même
chose ben là subitement cela devient super puissant, super vieux, et
l'on se demande même comment on a pu s'en passer

Tu me le retires de la bouche, j'ai failli le dire la dernière fois,
donc en effet je confirme, le html le xml et autres fadaises, ce n'est
rien d'autre que ce que TeX fait avec des {}, c'est à dire d'un coté tu
as le truc pondu par un génie, de l'autre la version gros plouc pondue
par des nullards.


--

Michel TALON

Le 19 Oct 2010 21:22:15 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :

JKB , dans le message <slrnibrisq.gq8.jkb@rayleigh.systella.fr>, a
écrit :

La structure XML, c'est la structure du XML.

Tu es fatiguant à asséner des platitudes sur des sujets que tu ignores comme
si c'étaient des arguments. La structure du XML, c'est aussi bien :

<convert
input="some_file"
output="some_other_file"
mode="auto"
quality="10"
/>

Que :

<convert:convert xmlns:convert="http://www.example.com/xmlns/convert>
<convert:param>
<convert:param-name>input</convert:param-name>
<convert:param-type>string</convert:param-type>
<convert:param-value>some_file</convert:param-value>
</convert:param>
<convert:param>
<convert:param-name>output</convert:param-name>
<convert:param-type>string</convert:param-type>
<convert:param-value>some_other_file</convert:param-value>
</convert:param>
<convert:param>
<convert:param-name>mode</convert:param-name>
<convert:param-type>enum</convert:param-type>
<convert:param-value>auto</convert:param-value>
</convert:param>
<convert:param>
<convert:param-name>quality</convert:param-name>
<convert:param-type>integer</convert:param-type>
<convert:param-value>10</convert:param-value>
</convert:param>
</convert:convert>

Les deux sont du XML bien formé (à moins d'une erreur de frappe de ma part),
les deux disent la même chose, mais le premier est parfaitement lisible, et
pas le second.

Ça n'engage que toi. Sur un truc trivial, tu as raison. Sur un
fichier de conf standard (comme celui que je t'ai indiqué plus
haut), tu as trivialement tort parce que la structure XML la plus
lisible est la _seconde_, que tu le veuilles ou non, parce que ton
fichier de conf peut être assez long pour ne pas tenir sur ton
écran.

<EOT>

You keep using that word. I do not think it means what you think it means.

Je sais parfaitement ce que ça veut dire. Le seul problème, c'est
que je n'arrive pas à me convaincre de te laisser écrire autant de
conneries en aussi peu de mots. Ton seul but est de toujours avoir
raison en prenant des cas particuliers, mais tu te contrefiches de
savoir qu'en dehors de ces cas particuliers, tes exemples sont des
exemples à la con. J'attends toujours que tu me montres par A+B que
ton exemple de redondance sur une trame réseau est identique à une
redondance d'information dans un fichier modifié par _bloc_. Et je
peux attendre longtemps parce que c'est trivialement faux. Comme
j'attends toujours que tu me calcules la propabilité de fausse
détection sur un encodage de fichier en fonction de la longueur du
texte. Mais en es-tu seulement capable ?

Sortir des exemples à la con, tu sais faire, tu ne sais même faire
que ça lorsqu'on te mouche. Maintenant, soit tu me _démontres_ que
j'ai tort, mais avec une démonstration _générale_ (en tant que
normalien fier de l'être, tu dois connaître ce mot) et non un contre
exemple qui sorti du contexte ne signifie rien, soit tu évites
de te ridiculiser. Parce que si tu n'en as pas encore pris
conscience, je ne te réponds que pour te ridiculiser, ce que tu sais
parfaitement bien faire par toi-même.

Au fait, j'ai un programme aujourd'hui qui m'empêchera certainement
de te mettre le nez dans tes problèmes, donc ne t'étonne surtout pas
que je ne réponde pas.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB , dans le message <slrnibt8uc.gq8.jkb@rayleigh.systella.fr>, a
écrit :

Ça n'engage que toi. Sur un truc trivial, tu as raison. Sur un
fichier de conf standard (comme celui que je t'ai indiqué plus
haut), tu as trivialement tort parce que la structure XML la plus
lisible est la _seconde_,

Preuve ?

que tu le veuilles ou non, parce que ton
fichier de conf peut être assez long pour ne pas tenir sur ton
écran.

Si l'information à exprimer est complexe, le fichier qui l'exprime sera
complexe, quelle que soit la syntaxe. La belle affaire !

J'attends toujours que tu me montres par A+B que
ton exemple de redondance sur une trame réseau est identique à une
redondance d'information dans un fichier modifié par _bloc_.

Ce n'est pas ce que j'ai dit, apprends à lire.

Michel Talon, dans le message <i9m7ub$2h0c$1@asmodee.lpthe.jussieu.fr>,
a écrit :

rien d'autre que ce que TeX fait avec des {}, c'est à dire d'un coté tu
as le truc pondu par un génie, de l'autre la version gros plouc pondue
par des nullards.

À ceci près que pour TeX, on a _une_ implémentation, non-buggée mais dans un
langage pourri, et bourrée de limitations à la con et incapable de gérer
l'internationalisation correctement, tandis que pour XML on a de nombreuses
implémentations dans quasiment tous les langages et mutuellement
compatibles.

Michel Talon a écrit :

remy <remy@fctpas.fr> wrote:

Michel Talon a écrit :

qui n'ont rien de plus pressé que
d'appliquer froidement les dernières fadaises qu'on leur a enseigné es
à la fac.

bon ok

le xml est un méta format
et que tu le veuilles ou pas ,c'est très puissant
c'est la mise en application du design pattern mcv

J'aurais cru t'avoir fait comprendre ce que je pensais des "design
patterns". En tant que scientifique je laisse la propagande et la pseud o
philosophie aux charlatans.

à titre perso je n'aime pas les design patterns tout comme les patates
en maths ,je trouve que cela inhibe complètement toute créativité
mais je suis bien forcé de reconnaître que chaque fois que l'on
veut faire quelque chose de propre, de lisible et robuste
l'on se retrouve à implémenter l'un de ses modèles

au bas mot, il doit y en avoir moins de 10 ,cela fait ch**r
mais c'est comme ça

et pour faire passer la pilule aux vieux râleurs impénitents il
suffirait de leur dire que le xml et le Latext c'est exactement la mê me
chose ben là subitement cela devient super puissant, super vieux, et
l'on se demande même comment on a pu s'en passer

Tu me le retires de la bouche, j'ai failli le dire la dernière fois,
donc en effet je confirme, le html le xml et autres fadaises, ce n'est
rien d'autre que ce que TeX fait avec des {}, c'est à dire d'un coté tu
as le truc pondu par un génie, de l'autre la version gros plouc pondu e
par des nullards.

sauf que le génie en question il n'a fait qu'implémenter un modèle déjà
existant

le TeX est t'il un méta format ? c'est une vraie question, je ne
maitrise pas assez la bête pour répondre à la question

dit différemment permet il (le langage) de créer sa propre police


remy





--
http://remyaumeunier.chez-alice.fr/

Le 20 Oct 2010 08:16:46 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait :

JKB , dans le message <slrnibt8uc.gq8.jkb@rayleigh.systella.fr>, a
écrit :

Ça n'engage que toi. Sur un truc trivial, tu as raison. Sur un
fichier de conf standard (comme celui que je t'ai indiqué plus
haut), tu as trivialement tort parce que la structure XML la plus
lisible est la _seconde_,

Preuve ?

Non. Je n'ai rien à prouver dans le cas général. Je te laisse
seulement imaginer un fichier avec un diagramme de rayonnement 3D
d'une antenne dans les _deux_ structures que tu as toi-même cru bon
d'indiquer.

que tu le veuilles ou non, parce que ton
fichier de conf peut être assez long pour ne pas tenir sur ton
écran.

Si l'information à exprimer est complexe, le fichier qui l'exprime sera
complexe, quelle que soit la syntaxe. La belle affaire !

Encore faux. Arrête de raisonner sur des exemples. Tu peux
parfaitement représenter des informations complexes dans des
structures simples et lisibles. Comme tu es capable de représenter
de façon éhontément complexe des données simples.

J'attends toujours que tu me montres par A+B que
ton exemple de redondance sur une trame réseau est identique à une
redondance d'information dans un fichier modifié par _bloc_.

Ce n'est pas ce que j'ai dit, apprends à lire.

C'est exactement ce que tu as écrit un peu plus haut et ce que tu
t'es dépêché de couper lorsque je t'ai mis le nez dedans. J'ai la flemme
de chercher l'ID du message. Mais honnête comme tu l'es, tu devrais
pouvoir retrouver toi-même ce message.

Ton erreur n'est pas le raisonnement en lui-même mais la cause et la
portée de la modification sur le fichier qui fout le raisonnement
par terre. Je t'ai déjà expliqué en quoi ton raisonnement était
foireux et contrevenait à toutes les règles des communications (tu
peux même commencer ta lecture par les papiers des grands ancêtres
des années 50 histoire de voir jusqu'où tu a été ridicule). Je t'ai
même indiqué des bouquins à lire, bouquins que tu n'as, si tu les as
ouvert un jour, pas ou mal compris.

Par ailleurs, tu m'expliques que tu sais ce qu'est un récepteur
optimal, permets-moi d'en douter. Si tu savais ce qu'étais ce truc,
tu éviterais de raconter des conneries sur les principes de
détection et les probabilités associées. Le récepteur optimal, c'est
quelque chose de parfaitement précis dont on arrive à calculer les
probabilités de fausse décision (ou au moins un majorant). Ce n'est
donc pas, malgré tout ce que tu peux en penser, un truc qui sort de
mon chapeau ou un truc magique. Et tout le mal que tu peux en penser
ne fera pas que ça ne fonctionne pas. En tout cas, dans le cas
_général_, un récepteur optimal se démerdera toujours mieux qu'un
autre récepteur (ton truc avec l'encodage du fichier en tête qui est
largement sous-optimal, et ça, ça peut aussi se démontrer.). C'est
la _théorie_ qui le dit et pas moi. Si ce n'était pas le cas, on
appellerait d'ailleurs ça autrement que récepteur _optimal_.
Et cela n'empêche pas qu'un type intelligent comme toi et qui n'a
rien d'autre à foutre arrive à le mettre en erreur. Ce n'est pas
pour cela que dans le cas _général_, il n'est pas meilleur que tous
les autres systèmes réunis. Encore une fois, tu mélanges le cas général
et le cas particulier. Le cas général étant un fichier de texte normal
(avec une certaine enthropie et une répartition statistique des
caractères), le cas particulier étant un cas pathologique écrit
spécialement par Nicolas George pour montrer qu'il a raison.
Au fait, pour ta gouverne, le mot _général_ a en communications
numériques un sens parfaitement défini. Donc avant de répondre une
connerie, cherche sa définition exacte et essaie de comprendre la
portée du concept dans le cas du récepteur optimal.

Je ne sais pas si tu te rends simplement compte du fait qu'avec ton
raisonnement, il est impossible de faire fonctionner une
communication numérique sans fil de type GSM, Wifi ou UMTS. Je ne vais
pas passer du temps à t'expliquer pourquoi, d'une part ce serait en
pure perte et d'autre part, j'ai un peu de compta à faire aujourd'hui.
Mais cherche un peu ce qui tourne autour des récepteurs aveugles ou
de la démodulation conjointe du (WB)CDMA. Ça risque de t'ouvrir des
horizons nouveaux. Tous ces trucs fonctionnent sur le principe du
récepteur optimal et évitent tous au maximum la redondance d'information.
Même ton OCR fonctionne grâce à un récepteur optimal (enfin, s'il
fonctionne correctement), et il fonctionne grâce à un récepteur
optimal assez proche de celui qui peut analyser l'encodage d'un
fichier.

Et j'ajoute pour terminer que contrairement à ce que tu peux penser,
un récepteur optimal n'est pas un bout de code complexe. C'est même
assez simple. Le récepteur optimal d'un téléphone UMTS est
particulièrement trivial et se contente d'un processeur ridiculement
faiblard. Le problème est que ce récepteur est très peu utilisé en
informatique parce que c'est un truc qui vient en droite ligne des
signaleux et qu'il faut se taper quelques calculs de probabilité qui
ne sont pas du niveau de l'analyste programmeur de base.

Je ne te répondrai que si tu as des arguments et non à un message
contenant 'foutaises' et n'argumentant rien. Lorsque je parle
d'arguments, j'entends une argumentation réelle et non des exemples
particuliers dont je n'ai que faire.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr