anaseto a écrit 2229 commentaires

Il manque un bout de code, tu fermes une chaîne de caractères qui n'a jamais été ouverte $k: $param->{$k}\n". Je suppose que c'est juste au copier-coller qu'il s'est passé quelque chose.

Eh bien l'erreur est claire, ou bien $param->{$k} ou bien $data->{$k}->[$i]->[1] n'a pas été défini. Tu est sûr que le ->[1] est bon ? (parce que $data->{$k}->[$i] existe visiblement, mais pour nous pas moyen de savoir de quoi il s'agit, même pas possible de dire que c'est une référence à un tableau). Bref, sans connaître la structure de $data, défini dans un parse_datafile dont on ne sait rien, c'est difficile de t'en dire plus.

$sys_twig->parsefile($sys_file); # a ce niveau est le probleme

Non, le problème n'est pas là : il te dit qu'il ne trouve pas default_sysvalue.xml, alors que dans cette ligne tu ouvres src_sys.xhml (du moins, sur ton bout de code). D'ailleurs, la ligne 37 ne se situe pas là, je pense.

De plus, au lieu d'utiliser un tableau @sys_names, tu devrais utiliser une table de hachage %sys_names (ou alors la créer après à partir du tableau), car c'est plus adapté pour tester l'existence d'une clé.

-Dans le cas ou un fichier-xml qui est entrain d'etre traite possede plus de 'name' que le fichier de depart (src_sys.xml) ignorer le 'name' et continue.

Au moment de parser ton premier fichier, tu pourrais créer une table de hachage %names qui garde en mémoire quels noms sont apparus avec un $names{$attr_name} = 1, puis après dans ton deuxième handler tester avec un if ($names{$attr_name}) où tu récupères $attr_name pareil.

-Dans le cas ou un fichier-xml qui est entrain d'etre traite possede moin de 'name' que le fichier de depart (src_sys.xml) ecrire en desous du 'name' correspondant 'missing'

La c'est similaire : il faudrait que tu fasses une passe préliminaire sur chaque fichier qui répertorie les noms qui apparaissent en utilisant une table de hachage comme avant.

Voilà, j'espère que ça t'aidera.

Il y a un lien entre attr_value et attr_name du premier fichier et des suivants ? Ou les attr_name sont aussi définis pour les suivants, et c'est ceux-là dont tu veux l'existence ? Si c'est le cas, tu veux peut-être juste un

unless (defined $_->{att}{name}) {
    $attr_value = "missing"
}

dans ta deuxième boucle après la ligne my $attr_value = ..., remplaçant $attr_value par « missing » s'il n'y a pas de name, en supposant que c'est dans ce fichier là, que tu veux qu'il existe.

si je ne me trompe pas

Après vérification, en fait python fait une optimisation à ce sujet, en créant un cache des regexps les plus récentes, ce qui doit être suffisant dans les cas pas trop intensifs.

Oui, et maintenant que tu le dis, je crois me souvenir qu'en effet j'avais déjà vu ça en Python et Ruby (par contre je n'ai pas l'impression que ce soit courant dans beaucoup d'autres langages, où souvent il y a même le problème de devoir échapper en double les \).

Un autre détail qui peut avoir son importance d'un point de vue lisibilité est, si je ne me trompe pas, qu'en Python par exemple les expressions régulières doivent êtres compilées préalablement à la main pour des raisons de performance avant une boucle, alors qu'en Perl si c'est une constante c'est compilé qu'une seule fois dès la phase de compilation, donc on peut la mettre directement dans la boucle, ce qui est plus lisible quand l'expression régulière n'est utilisée qu'à un seul point du programme, ou est très simple (ce qui est souvent le cas). Je ne sais pas si ça vaut pour Ruby aussi (a priori, ce serait possible d'optimiser, vu qu'elles sont intégrées au langage de façon similaire qu'avec Perl).

C'est un peu ce qui m'a fait passer de perl à python : la lisibilité

C'est curieux, parce qu'en ce qui me concerne, c'est le contraire. Bien qu'en Perl il est possible d'écrire du code vraiment affreux, et il y a sans doute beaucoup de ce type de code dans la nature (en partie parce qu'il est très facile d'écrire du Perl tout en ne sachant pas programmer, et en partie du fait de one-liners et code golf), la plupart du code que j'ai lu (principalement des modules sur CPAN), me semble particulièrement lisible et vite compréhensible.

Le fait de voir d'un coup d'œil qu'une variable est un tableau, une table de hachage, etc. aide facilement à se repérer. Le fait que la comparaison numérique utilise des opérateurs différents que la comparaison des chaînes, etc. aide aussi, dans la plupart des cas simples, à déduire plus vite de quoi il est question. Savoir si on additionne deux nombres ou concatène deux listes est instantané aussi, par exemple. Et c'est un des principes du langage : les choses courantes qui sont différentes, doivent apparaître visuellement différentes. Alors, bien sûr, c'est un peu le contraire du principe de généralisation qui voudrait que l'on utilise les mêmes opérateurs et les mêmes idées pour des choses totalement différentes dès qu'ils présentent certaines ressemblances mathématiques (comme dans haskell), ce qui est utile parfois, mais souvent on se fiche du parallèle mathématique, et avoir un retour visuel instantané plus concret aide à la compréhension en pratique.

En gros, Perl force syntaxiquement à une certaine redondance dans l'information concernant les types de données utilisés qui rend le code plus lisible (à mon avis).

Les expressions régulières sont aussi plus lisibles que dans la plupart des autres langages (avec coloration syntaxique de l'éditeur possible) du fait qu'elles sont intégrées dans le langage, et peuvent être écrites avec des espaces et des commentaires. Et avec use strict; (utilisé presque partout) il faut déclarer les variables avec my (lexicales à un bloc, pas comme en python qui est assez surprenant à ce sujet), ce qui permet de voir instantanément où est la première occurrence d'une variable, et de savoir qu'elle n'est pas globale, par exemple.

Le pattern matching sur les types sum c'est pour faire du raisonnement disjonctif, ou raisonnement par cas.

Tout à fait, et ce n'est pas du tout ce que permet de faire le given de Perl6, les fonctionnalités offertes sont très différentes, il ne s'agit pas de filtrer sur des types algébriques.

Pour avoir quelque chose de similaire au filtrage sur les regexp en OCaml, il faudrait déjà intégrer les regexp au langage (pour que la compilation des regexp se fasse à la compilation, et pas à l'exécution, et du coup avoir de meilleurs messages d'erreurs et moins tardifs, entre autres), ce qui demanderait d'utiliser camlp4/5 ou les ppx, et probablement s'amuser avec les GADTS comme ça a été fait avec printf (mais je dois dire que je sais pas les utiliser très bien, donc je dis peut-être une bêtise sur ce point).

mais tu peux tout à fait écrire une clause "when" au milieu de ton filtre pour y mettre un test boolean qui soit un appel vers une lib externe type pcre.

Oui, ce qui revient juste à faire des "if" chainés : pas de filtrage sur les types. Je pense que le problème, c'est que le filtrage avec given ressemble à un filtrage par motif OCaml syntaxiquement, mais ils ne représentent pas du tout le même problème.

Si un switch est nécessaire sur un type, c'est qu'il y a un gros problème d'architecture. Le coté polymorphe de ocaml rend ce genre de cas inutile (typique avec des listes utilisant uniquement des types parents).

Ce n'est pas équivalent au polymorphisme d'OCaml, c'est plus flexible (tout en offrant moins de garanties). Après, on peut considérer qu'il y a un problème d'architecture si on a besoin de cette flexibilité, mais c'est une autre histoire.

Je ne connais pas non plus des millions de langages qui sont aussi ouvert sur l'utilisation d'opérateur.

Et il n'y a pas non plus des millions de langages, qui s'excusent quand le programmeur fait une erreur avec un ===SORRY!=== ;)

D'ailleurs, du point de vue des erreurs de syntaxes, les messages d'erreurs sont excellents, du fait d'une grammaire minutieusement étudiée, ce qui rend Perl6 très accessible aux débutants, je trouve, malgré le côté colossal du langage. Oublier un point virgule donnera un message d'erreur très précis (en pratique toujours pile à l'endroit où il faut le mettre) du type Two terms in a row across lines (missing semicolon or comma?) en montrant aussi le bout de code fautif, et mettant du rouge à l'endroit où le problème a été détecté, ce qui comparé à Perl5 est très bien, mais aussi comparé à d'autres langages comme OCaml (tu reçois comme message d'erreur que tu passes trop d'arguments à une fonction en général, dans ce cas, ce qui est compréhensible que pour celui qui connaît déjà bien le langage, mais totalement abscons pour le débutant).

Le filtrage des type sum de Ocaml, propose bien mieux depuis bien plus longtemps, par exemple.

Il propose différent, mais mieux ou non c'est une question de point de vue et de contexte. Parce que le filtrage de types en Caml te permet pas de matcher des chaînes sur des expressions régulières (même si je connais une extension qui essaie de faire un truc similaire). En Perl6, un seul mécanisme permet de faire beaucoup de choses : matcher suivant le type (ce qui donne beaucoup de flexibilité à faible coût intellectuel), suivant une expression régulière, matcher contre une jonction (donc tester l'appartenance à une liste, ou qu'une propriété est vraie pour tous les éléments d'une liste par exemple), etc. Mais il n'y a en effet pas de types algébriques (encore, en tous cas).

En effet, il leur manque un artiste du web dans l'équipe :)

Possible, mais la différence fondamentale entre les deux dangers est que, dans le cas du charbon, si on trouve quelque chose de mieux, on peut y passer sans dommages durables (en gros, ça fait des morts maintenant, mais si on arrête ça n'en fera plus au bout d'un temps raisonnable), tandis que dans le cas du nucléaire, si on trouve quelque chose de mieux à côté, ça veut pas dire qu'on peut oublier le nucléaire (il faudra s'occuper de neutraliser le méchant bébé pendant « longtemps », sauf quand il y a des accidents, comme à Fukushima, car alors impossible même d'essayer de neutraliser les dégâts faute de moyens techniques de le faire de nos jours).

Tout est en lien avec les chiffres issus du GIEC, et l'auteur met les graphiques et la valeurs à jours au fil du temps, ce qui fait que les articles restent bien d'actualité.

Un autre site, tenu par un ancien du CNRS, qui présente aussi beaucoup d'analyses à partir de données issues du GIEC, qui met des liens vers beaucoup d'articles de recherche, et est régulièrement mis à jour, est celui de pensee-unique. Les conclusions sont par contre souvent sensiblement différentes.

Il fait probablement référence à des petites périodes chaudes (comme l'optimum médiéval avec des températures semblables à aujourd'hui, et qui a vu la population augmenter significativement), comparée à des petites périodes plus froides (comme par exemple la petite période plus froide après l'optimum médiéval qui, accompagnée de la peste, a fait des ravages, ou encore la période plus froide du XVII et débordant sur le siècle suivant). Je pense pas qu'il faisait référence à des périodes vraiment chaudes ou des glaciations (que l'homme n'a pas vécu les derniers milliers d'années).

Ce n'est pas avec cela que la Russie sera étouffée surtout que l'UE n'a pas enterré le gazoduc entre la Russie et ses États membres.

Elle ne peut évidemment pas se le permettre actuellement, et comme j'ai dit, je pense pas que ça change vu l'état des choses.

EDIT : parce que bon, l'oléoduc rapportera bien moins à ses hypothétiques exploitants que les manœuvres militaires.

J'entendais de la stratégie économique à long terme : être en mesure d'isoler la Russie, ou de la menacer d'isolement, et pour cela contrôler cette zone, et ce même s'il faut que l'Europe et les États Unis en payent le prix maintenant (donc pas rentable pour nous en effet). L'idée n'est pas celle de la rentabilité économique pour les pays (sinon gêner les échanges avec la Russie serait ridicule), mais d'étouffer l'autre, même s'il faut s'étouffer un peu aussi pour ce faire : c'est une résistance au changement. Ceci dit à mon avis, vu l'état des choses, c'est peu probable qu'ils y arrivent (leurs diverses interventions sont pas des réussites, et puis la Russie n'est pas toute seule, et pas mal de monde veut du gaz, d'où qu'il vienne).

La Syrie n'est pas vraiment un grand producteur et ce depuis longtemps. Contrairement à la Libye ou l'Irak (la Syrie produisait en 2005 5 fois moins de pétrole de l'Irak).

En effet, mais, par contre, deux pipelines très conséquents étaient censés passer un jour par là pour approvisionner l'Europe, et du coup dépendre moins de la Russie. Il y a donc ceux qui veulent de ces pipelines (Europe, États-Unis, Turquie?), ceux qui posent des difficultés (gouvernement Syrien), divers groupes terroristes plus ou moins « modérés » (qui ont pour caractéristique commune d'être contre le gouvernement Syrien), et ceux qui n'en veulent pas (la Russie). Du coup, d'un côté, Europe et États-Unis appuient les groupes de terroristes « modérés » (mais en y regardant pas de trop près) pour affaiblir le gouvernement Syrien peu coopératif, et de l'autre, la Russie (et l'Iran, avec appui —principalement moral— de la Chine), qui va faire son possible pour éviter que le camp occidental arrive à ses fins. Bref, que des intérêts économiques dans l'histoire des côtés des deux grands blocs, et aucune bonne intention pour le peuple syrien de la part d'aucun des deux.

D'un autre côté, faut faire attention avec each parfois : faut s'assurer que le même hash n'est pas reparcouru à l'intérieur de la boucle, ou dans un appel de fonction à l'intérieur de la boucle, sous peine d'avoir des surprises. Faut aussi éviter d'ajouter ou supprimer de nouvelles clés à l'intérieur de la boucle (sauf la clé courante comme exception). Du coup, parfois utiliser keys est plus reposant.

Ici par détail insignifiant, dans le contexte, j'entendais le fait d'accorder beaucoup d'importance à un idiotisme (« langue de Molière » par exemple ici), que ce soit pour le critiquer ou le défendre, car un idiotisme ne fait pas partie des fondements logiques grammaticaux et sémantiques de la langue.

Pour revenir à la comparaison, pense que même le langage de programmation avec le plus d'idiotismes en a (heureusement probablement) beaucoup moins que la plus simple des langues naturelles. Un idiotisme par définition est une expression figée, très souvent non compréhensible par un non initié. Parfois, ça ajoute une nuance dans un certain contexte qui apporte un ressenti différent pour ceux qui la connaissent (peut-être le cas ici avec « langue de Molière », mais je ne saurais pas trop dire sur ce cas particulier si je ressens quelque chose de différent qu'avec juste « langue française »), d'autres fois ça permet d'être plus concis, ironique etc. Mais cet effet n'est effectif, que si le lecteur connaît l'expression ; autrement, plutôt que d'apporter un ressenti spécial, l'idiotisme rend le texte juste moins fluide. Dans le cas de « langue de Molière » on peut raisonnablement espérer que cela n'affecte presque que des étrangers qui apprendraient le français, mais j'en mettrais pas ma main au feu non plus.

Bref, les idiotismes ont leur utilité parfois, apparaissent spontanément dans toutes les langues naturelles et permettent d'ajouter un peu de piment et certaines nuances, mais on ne peut pas les défendre comme quelque chose de vraiment carré, généralisable (impossible c'est une locution propre par définition) et qui s'intègre en toute logique avec le reste de la langue et dont un abus serait raisonnable : il faut les apprendre par cœur, car leur sens la plupart du temps ne découle pas de façon non ambiguë et intuitive des mots qui les composent (je pense que quand j'étais petit, au début « langue de Molière » signifiait pour moi « la façon d'utiliser la langue française de Molière » ou quelque chose comme ça).

Ceci dit, tu semblais plutôt penser à des règles comme les accords ou les accents (que je ne visais pas spécialement), mais même à ce niveau, la langue française a bien des irrégularités (« chacals » mais « chevaux », etc.), qui complexifient la langue inutilement sans apporter aucune nuance ni amélioration de l'expression. Donc si les langages de programmation c'est de l'orthographe et de la grammaire, les langues naturelles (et particulièrement le français), c'est de l'orthographe, de la grammaire, des idiotismes et des exceptions, ce qui n'est pas tout à fait la même chose. Si les langages de programmation évoluent pour faciliter le plus possible la vie du développeur, et éliminer le plus possible d'obstacles à son activité, on est en droit d'attendre la même chose des langues.

Nan mais sérieux ça commence à faire chi… d'avoir des commentaires sur le français, sur l'ortografe et Jean passe aidé meilleur (oui c'est de l'humour je sais comment cela s'écrit).

C'est un truc qui m'a toujours étonné aussi : pourquoi, même dans des milieux non littéraires, la langue française est l'objet d'autant de réactions passionnées sur des détails insignifiants. Je ne sais pas si c'est un problème juste culturel (traumatisme ou je ne sais quoi), ou alors un problème de la langue elle-même ou les deux, mais c'est médusant. Et je trouve que c'est encore plus marqué dans les milieux d'informaticiens qu'ailleurs, peut-être parce qu'ils sont habitués à défendre même avec les dents s'il le faut leur langage de programmation préféré et critiquer les autres, et que langage de programmation et langue c'est un peu lié, je sais pas, même si j'aurais plutôt pensé le contraire, vu comment beaucoup d'informaticiens se plaignent de la moindre imperfection dans un langage de programmation, mais défendent les irrégularités et tournures étranges dans la langue parlée, même si elles rendent l'outil plus difficile à utiliser.

Cool ! Et puis ça me fait réviser un peu aussi. Après, c'est pas forcément très apétissant ce genre de signatures :)

Peut-être en écrivant une signature différente, où c'est pas le même a pour la dernière opération (peut-être qu'il faut des quantifieurs du coup, je sais pas). Ou alors, enlever la signature, et voir ce que décide Haskell (peut-être qu'il faut -XNoMonomorphismRestriction [plus sûr du nom] pour qu'il fasse un truc général et pas le contraire). Faut dire que haskell c'est plus trop frais dans ma mémoire :)

C'est d'ailleurs ce petit genre de difficultés à répétition qui m'ont un peu agacé avec ce langage (plus le jour où je crois que je commence à comprendre comment ça marche, et puis je tombe sur des modules qui utilisent les Lens ou les Arrows et sont documentés à l'aide quasiment des seules signatures des fonctions, et là je reviens à mon Perl ;) ).

car à l'entendre son code fonctionne mais ne fait pas ce qu'il veut.

En même temps, avant qu'il ajoute ces lignes au début, peut-être que ça faisait quelque chose, c'est sans doute ce qu'il veut dire, j'imagine.

Je comprend ta démarche pédagogique, mais je pense que le mieux ce serait qu'henri lise un tutoriel en français qui reprend les bases de la programmation en Perl dans l'ordre, parce que sinon, forcément, on bloque sur des trucs de base.

open my @files = glob $MYDIR.'*.xml';

Juste une remarque par rapport à une erreur qui se propage depuis tout à l'heure : faut enlever le open en trop ici, et ouvrir ensuite chaque fichier séparément dans une boucle sur @files (si c'est vraiment le but de la manœuvre).