Bonsoir
Je viens de mettre à jour mon spip 2.1 et j’ai les messages suivant d’afficher dans la partie privés :
Filtre couleur_extreme non défini et Filtre couleur_inverser non défini
La version qui est installer est SPIP 2.1.0-dev SVN [15041]
Merci
Pierre
Ce ne sont pas des plugins externes, justement ?
2010/1/28 Pierre KUHN <pierrekuhn82@gmail.com>
Bonjour Gilles
Les extensions sont visibles ici http://spip21.pierre-kuhn.org/extensions/ et je vois bien les filtres images
Pierre
Afin de présiser ou ce trouve le beug, voir les pages ou je le vois:
/ecrire/?exec=admin_plugin
/ecrire/?exec=cfg
Ainsi que sur les pages de config des plugins avec cfg
A plus
Pierre
* Pierre KUHN tapuscrivait, le 28/01/2010 22:33:
Bonsoir
Je viens de mettre à jour mon spip 2.1 et j'ai les messages suivant
d'afficher dans la partie privés :
Filtre couleur_extreme non défini et Filtre couleur_inverser non définiLa version qui est installer est SPIP 2.1.0-dev SVN [15041]
Essaye avec : Connexion · GitLab
bien vu, un oubli qui date un peu je crois.
Cédric
Tiens, ce serait peut-être pas mal de protéger ce dossier par défaut, non ?
Salut,
Bon, mon site qui est sous SPIP 2.1 a totalement cessé de fonctionner avec la mise à jour du jour, ça venait du passage des fonctions graphiques en extensions.
J'ai dû faire une tripotée de modifs pour que ça refonctionne. Je préviens:
- j'espère ne pas avoir trop salopé le «nouveau» code;
- couleur_extreme est appelée directement depuis les squelettes (et beaucoup: c'est tout l'intérêt des fonctions de traitement des couleurs), du coup je l'ai remise dans images_fonctions et j'ai créé une fonction du même nom pour faire la passerelle;
- le découplage des répertoires SVN, entre la /branche et /zone/_core, ça ne simplifie pas le travail pour l'instant (ça devrait se tasser quand le _core sera stabilisé); j'espère que j'ai bien réussi l'upload qui concerne les deux à la fois.
A*
Hello,
Salut,
Bon, mon site qui est sous SPIP 2.1 a totalement cessé de fonctionner avec la mise à jour du jour, ça venait du passage des fonctions graphiques en extensions.
J'ai dû faire une tripotée de modifs pour que ça refonctionne. Je préviens:
- j'espère ne pas avoir trop salopé le «nouveau» code;
- couleur_extreme est appelée directement depuis les squelettes (et beaucoup: c'est tout l'intérêt des fonctions de traitement des couleurs), du coup je l'ai remise dans images_fonctions et j'ai créé une fonction du même nom pour faire la passerelle;
ah oui mais non
je pense que tu parlais de couleur_extraire que tu as réintroduit.
Mais comme je le précisais dans
http://trac.rezo.net/trac/spip/changeset/13666
le but de la réorganisation etait d'avoir un nommage clair et sans ambiguité.
Du coup il avait été renommé en
extraire_image_couleur()
Je suis conscient qu'on introduit une incompatibilité mais :
- pour ceux qui utilisent beaucoup le filtre et ne veulent pas renommer dans les squelettes il suffit d'inclure image_couleur_extraire
- pour les autres un simple renommage suffit.
Mais au moins on obtient au total un nommage clair des filtres dont on peut comprendre ce qu'ils font rien que par leur nom, et dont l'api et la façon de les écrire pourra être documentée.
Donc je pense qu'il faut revenir sur cette réintroduction de couleur_extaire
Cédric
Il y a deux choses:
- extraire_couleur_image est un nommage inédit, puisqu'on a deux types de filtres graphiques, les «couleur_» et les «image_»; je sais bien que couleur_extraire est à cheval sur les deux (à mon avis, plus nettement un filtre dans la logique des manipulations de couleur), mais il me semble qu'il est plus clair de rester dans les séries couleur_xxx et image_xxx;
- c'est le type d'incompatibilité carrément chiante à corriger, parce que couleur_extraire apparaît à la fois dans les squelettes, dans des fonctions plus élaborées (mes_fonctions) et dans des plugins.
Bref, je ne vois pas l'intérêt d'introduire une incompatibilité pour un nommage qui n'est pas cohérent avec l'existant.
Dans ton changeset, tu indiques «La compatibilite des anciens nommages pourra etre obtenue avec le plugin des filtres images du _core_».
(Cela dit, dans mes corrections, il n'y avait vraiment pas que le fait de réintroduire couleur_extraire. Il y avait surtout le fait que ça tentait d'ouvrir les fichiers avec _image_image... au lieu des imagecreatefrom...; et des filtres de couleur qui ne fonctionnaient plus du tout).
ARNO*
Il y a deux choses:
- extraire_couleur_image est un nommage inédit, puisqu'on a deux types de filtres graphiques, les «couleur_» et les «image_»; je sais bien que couleur_extraire est à cheval sur les deux (à mon avis, plus nettement un filtre dans la logique des manipulations de couleur), mais il me semble qu'il est plus clair de rester dans les séries couleur_xxx et image_xxx;
- c'est le type d'incompatibilité carrément chiante à corriger, parce que couleur_extraire apparaît à la fois dans les squelettes, dans des fonctions plus élaborées (mes_fonctions) et dans des plugins.
Quand c'est le cas, et si tu ne veux pas corriger le code, il suffit d'ajouter
include_spip('inc/filtres_images_compat)
dans ton mes_fonctions.php ou dans le fichier fonctions du plugin concerné.
Bref, je ne vois pas l'intérêt d'introduire une incompatibilité pour un nommage qui n'est pas cohérent avec l'existant.
qui était incohérent, on tourne en rond !
L'intérêt c'est qu'on peut ensuite expliquer que les filtres couleur_xx prennent tous en entrée une couleur et sortent une couleur, idem pour les filtres images_ avec les images.
C'est simple et clair.
Dans le cas des filtres images, ça permet aussi au compilateur de les repérer clairement et sans ambiguité, pour gérer les images temporaires et leur suppression.
Dans ton changeset, tu indiques «La compatibilite des anciens nommages pourra etre obtenue avec le plugin des filtres images du _core_».
oui, j'avais oublié de préciser qu'il fallait faire un inclure pour assurer la compatibilité
(Cela dit, dans mes corrections, il n'y avait vraiment pas que le fait de réintroduire couleur_extraire. Il y avait surtout le fait que ça tentait d'ouvrir les fichiers avec _image_image... au lieu des imagecreatefrom...; et des filtres de couleur qui ne fonctionnaient plus du tout).
oui j'ai vu, et j'en repéré encore une ou deux coquilles restantes.
Je les envoies.
Cédric
Bonsoir
Merci cédric pour ton commit 15044 de spip car ça a résolu mon soucis e filtre images.
Pierre
«Du coup il avait été renommé». Par qui, pourquoi, évidemment ça ne se discute même pas.
Ça me casse les pieds de me faire donner la leçon à chaque fois que je mets le nez dans le code. «ah oui mais non».
=> D'abord, j'ai passé mon après-midi à débugguer du code pourri de chez pourri. C'était tout de même spectaculaire: aucune fonction de traitement des images ne pouvait fonctionner, puisque image_valeur_trans fournissait une mauvaise fonction pour... ouvrir les fichiers graphiques; la moitié des fonctions de traitement des couleurs était également dans les choux (celles qui font la conversion hexadécima-décimal). C'était un énorme commit rigoureusement pas testé que j'ai débuggué. L'intégralité du commit porte sur les filtres graphiques, et aucun filtre graphique ne pouvait fonctionner. Même pas image_reduire. J'ai rien contre les bugs; mais quand un énorme paquet n'a pas _du tout_ été testé, je ne suis pas d'accord. Et quand je passe mon après-midi à débugguer ça, je me fais pas rembarrer à la première ligne: «ah oui mais non je vais te faire la leçon».
=> Je constate qu'on introduit une rupture de compatibilité uniquement dans le but de rendre le code plus joli. En échange de cette perte de compatibilité, donc, l'utilisateur ne gagne aucune fonctionnalité nouvelle ni aucune amélioration des performances. Je suis d'accord pour les ruptures de compatibilité, exceptionnelles, si en face on me donne un véritable bénéfice. Là, c'est juste pour la beauté du code.
=> Me faire la leçon sur le thème «on obtient au total nommage clair des filtres», merci, mais:
- c'est moi qui ai introduit la fonction «image_typo» le 19 mai 2005, et elle s'appelait déjà «image_typo» [4350],
- c'est moi qui ai introduit la série complète de manipulation d'images le 2 novembre 2005 [4954], et elles s'appelaient déjà toutes «image_kekchose» (sauf «reduire_image» qui est très antérieure);
- c'est moi qui ai introduit la série de fonctions de manipulation des couleurs le même jour [4958], et elles s'appelaient déjà toutes «couleur_trucmuche».
Avant que n'arrivent les fonctions sql_xxx, il n'y a jamais eu aucun autre exemple de tentative de créer un nommage cohérent pour une série de fonctions dans SPIP. Et à ma connaissance il n'y en pas d'autres. Même les fonctions de pipeline ne sont pas nommées comme telles.
Alors, oui, merci, je sais pourquoi ces fonctions s'appellent comme ça, c'est moi qui les ai nommées il y a quasiment cinq ans, et elles avaient déjà un nommage «clair». Et je les avais toutes documentées à l'époque, ce qui n'est pas forcément le cas de ce qui se code dans SPIP depuis. M'opposer un beau «nommage clair des filtres» parce qu'on renomme couleur_extraire en autre chose, faut tout de même avoir un sacré toupet.
=> Pour le plaisir de la règle qui dit que «couleur_xxx prend une couleur en entrée et donne une couleur en sortie, et image_xxx prend une image et donne une image», nous voilà avec une fonction «extraire_image_couleur» qui, elle, n'entre plus dans aucune catégorie de nommage. C'est vrai que c'est plus clair comme ça. On peut même l'appeler «extraire_une_couleur_de_l_image» si on veut, d'ailleurs, parce que là on est totalement libre.
J'ajoute que les fonctions qui font trois mots, c'est juste impossible à mémoriser; image_passe_partout, je vais dans la doc à chaque fois. Là, non seulement j'oublierai le nom de la fonction, mais en plus je me demanderai à chaque fois si c'est extraire_image_couleur ou extraire_couleur_image (pourquoi l'un plutôt que l'autre, d'ailleurs?). Mais «couleur_extraire», ça perturbait la beauté intrinsèque du code source de SPIP.
=> Le point important: la structure du code devient carrément top-délire. La perte de temps pour entrer dans ce code, c'est assez dingue.
=> Alors tant qu'à faire, puisqu'on cause des fonctions graphiques, je fais un apparté. Ça n'est pas la première fois que le code de ces fonctions devient compliqué. Il y a depuis un bon bout de temps un système de fichiers «.src» qui chapeaute le système. C'est censé apporter des gains de performances. En théorie, ça me semble très bien. Mais:
- la conséquence première est que je me suis fait éjecter du code que j'ai créé (les fonctions graphiques en particulier); je n'arrive pas à piger le fonctionnement de ce truc, et quand il y a des bugs, je suis totalement incapable de savoir le corriger et je dois attendre la bonne volonté de la seule personne qui sait comment corriger;
- ça ne serait pas gênant si, pour le coup, on avait un vrai gain de performance;
- mais dans la pratique, c'est systématiquement buggué; comme je ne pige pas le système, je ne sais pas si ça vient d'une particularité de GD2 ou de la surcouche des fonctions graphiques; toujours est-il que, dès qu'on enfile les fonctions graphiques, ça déconne totalement: calculs non effectués mais résultat intermédiaire affiché à l'écran, images calculées qui disparaissent purement et simplement lors des recalculs...
- et la seule solution que je connaisse, c'est d'insérer des image_graver toutes les deux, voire une, fonctions graphiques.
Ce qui fait qu'en pratique:
- c'est une des dernières grandes parties cohérentes du code que j'ai créées dans SPIP et on me l'a fermée au nez avec un système que je ne comprends pas;
- en pratique il n'y a pas de gain de performance, puisque la situation théorique (les fonctions graphiques se suivent sans interruption) n'est pas praticable sur les serveurs;
- en pratique je suis obligé de truffer mon code d'insertion d'ordres purement techniques qui n'ont d'autre objet que de faire re-fonctionner le bazar (à certains endroits, où je traite de grosses images, j'ai quasiment besoin d'insérer un image_graver toutes les deux lignes). Je perds en lisibilité et en temps.
Pour la route, je vous donne un bout du code d'un des tout derniers sites que j'ai fait:
[src="(#LOGO_RUBRIQUE_SURVOL||sinon{#LOGO_RUBRIQUE_NORMAL}|image_masque{masques/305x85.png}|image_graver|image_renforcement{0.1}|image_graver|image_aplatir{jpg}|extraire_attribut{src})" ]
J'ai donc trois filtres graphiques et deux image_graver. Et là c'est pour faire un truc absolument rudimentaire.
Je ne sais pas exactement ce que la théorie de l'informatique permet de conclure de ce genre de situation. Mais là, clairement, je ne vois pas ce que l'imposition d'une méthode scientifiquement imparable et théoriquement épatante nous a apporté.
=> Après cet aparté, je reviens au code d'aujourd'hui. Encore une fois, le découpage en une foultitude de fichiers a l'air séduisant intellectuellement, et je pense que même moi je pourrais vous expliquer le pourquoi d'une telle découpe. Sauf que dans la pratique, ça donne le débuggage de la fonction couleur_extraire (pardon: extraire_couleur_image, non: extraire_image_couleur):
- la fonction extraire_image_couleur est installée, presque seule, dans:
/extensions/filtres_images/images_fonctions.php
elle ne fait rien, elle appelle _image_couleur_extraire (notez l'inversion des termes qui doit certainement répondre à une logique géniale), qui se trouve dans:
/extensions/filtres/images_lib.php
qui utilise _image_valeurs_trans, que l'on va trouver là:
/ecrire/inc/filtres_images_lib_mini.php
La fonction d'extraction de couleur fait aussi, par exemple, un appel à la fonction _couleur_dec_to_hex, qui se trouve dans
/ecrire/inc/filtres_images_lib_mini.php
Ouf. Parce que si on utilisait la fonction inverse, _couleur_hex_to_dec, on chargerait la fonction couleur_html_to_hex, qui se trouve dans:
/ecrire/inc/filtres_images_mini.php
(Accessoirement, _couleur_dec_to_hex que j'utilise régulièrement dans mes plugins adopte un underscore initial, mais je dois me souvenir que la fonction couleur_html_to_hex que je n'utilise rigoureusement jamais, elle, n'en prend pas.)
- autre exemple, les couleurs sont logiquement traitées dans:
/extensions/filtres_images/filtres/couleurs.php
Où l'on trouve la fonction couleur_extreme. Cette fonction appelle _couleur_hex_to_dec, qui fait donc nous l'avons vu un passage par
/ecrire/inc/filtres_images_mini.php
Après la conversion de couleurs codées en hexadécimales en couleurs codées en décimal, le filtre convertit le codage RVB de la couleur en HSL avec la fonction _couleur_rgb2hsl; fonction qui se trouve dans un nouveau fichier:
/extensions/filtres_images/inc/filtres_images.php
Tout est à l'avenant. La fonction couleur_foncer_si_claire, dans la version que j'ai sous le nez, fait elle un appel à:
/ecrire/inc/filtres_images_mini.php
parce que c'est là que se trouve la fonction couleur_foncer. Mais auparavant, passage par _couleur_hex_to_dec, qui est ailleurs et qui fait elle-même un détour par un troisième fichier.
Je n'insiste pas trop sur le fait que les fichiers s'appellent:
- images_lib.php
- filtres_images.php
- filtres_images_mini.php
- filtres_images_lib_mini.php
parce que vous risqueriez de trouver cela confusionnant.
Alors je veux bien qu'on rationalise. La séparation entre filtres et filtres_images, oui. La séparation entre filtres_images et filtres_images_mini, pourquoi pas. Mais là, c'est juste pas possible: il y a maintenant 9 fichiers pour faire la même chose que 2 précédemment. Et, avec les petits exemples ci-dessus, on se rend compte que c'est parfaitement artificiel. On passe par la moitié de ces neuf fichiers rien que pour afficher du texte blanc sur une couleur foncée. Si cette couleur foncée est extraite d'une image, on est alors passé par l'autre moitié. Quand au débuggage, c'est juste un chemin de croix.
Ce qui nous vaut cet argument: «un nommage clair des filtres dont on peut comprendre ce qu'ils font rien que par leur nom, et dont l'api et la façon de les écrire pourra être documentée». C'est vrai qu'avant on ne savait pas ce que faisaient les fonctions et l'API ne pouvait pas être documentée. Maintenant encore moins, mais au moins je sais pourquoi.
Arnaud
Dans les réunions à tataouine-les-oies on essaye de progresser ensemble et de s'apprendre des choses.
Pour le debug il y a justement eu une session très instructive
http://www.spip-blog.net/Bug-Debug.html
Cédric
Pourquoi ça repasse sur spip-team? Je repasse sur la dev.
S'lt
Mais à ton commentaire sur l'incohérence, il faut ajouter une critique plus grave: si on n'a pas explicitement sélectionné la méthode de réduction dans l'espace privé, on a les filtres graphiques qui fonctionnent tous, sauf image_reduire.
Ce qui me laisse penser que le choix d'isoler proprement les fonctions
de traitement d'image déjà discuté et abordé depuis un an semble une
bonne piste. Ceci permettrait d'avoir une vraie surcouche pour choisir
le mode de traitement.
Je ne critique pas l'idée de passer les fonctions graphiques dans /extensions. Je critique la façon de structurer ces fichiers. Je ne critique pas la théorie, je critique sa mise en pratique.
- on passe de 2 fichiers à 9 fichiers, avec des intrications dans tous les sens, ce qui rend le débugage lourdingue;
- j'explique que, vue la structure de ces 9 fichiers, la moindre fonction fait qu'on appelle au moins 4 ou 5 fichiers; (si on a des filtres graphiques et des manipulations de couleurs, c'est bon, on a tout chargé à chaque fois); du coup le gain de mémoire est marginal et aléatoire; par ailleurs, il s'agit de fonctions qui ne sont appelées qu'au recalcul et qui, pour les traitements graphiques et typographiques, chargent en mémoire de grosses images, ce qui fait que réduire la longueur des fichiers PHP eux-mêmes est certainement totalement accessoire ici;
- les noms de 4 fichiers sont sources de confusion:
- images_lib.php
- filtres_images.php
- filtres_images_mini.php
- filtres_images_lib_mini.php
et, comme pour le point précédent, c'est fait avec des fonctions très imbriquées, ce qui limite très fortement la cohérence de la ventilation des différentes fonctions dans ces différentes fichiers.
Par ailleurs, je ne suis pas d'accord avec le fait de changer les noms des fonctions, ce qui introduit une foule d'incompatibilités (et, accessoirement, rend obsolète toutes mes documentations qui utilisent ces fonctions) sans aucun gain fonctionnel. Cédric a des arguments sur les fonctions image_xxx, dont je ne suis pas certain qu'ils soient vérifiés pour l'heure, et pour ce qui est des fonctions couleur_xxx, je suis à peu près certain qu'il n'y a rigoureusement aucun automatisme dans le compilateur qui repose sur le nom de ces fonctions.
Par ailleurs, au cas où la question se poserait: non, la structure actuelle ne permet absolument pas d'imaginer faire fonctionner les filtres sur différentes librairies (GD2, imagick) en séparant des fichiers. (Voir la deuxième partie de ce message.)
Le fait de découper les fichiers a plusieurs buts, avec lesquels je suis parfaitement d'accord;
- d'abord, découpler les cycles de développement (c'est la raison principale de l'idée de «déshabiller le core»); on peut mettre à jour certaines parties et sortir des versions intermédiaires plus facilement, sans que ce soit l'intégralité des développements du core qui doivent être pris en compte à chaque fois; là ça marche très partiellement, parce qu'il reste des fonctions vitales dans le core pour manipuler les images et les couleurs; mais bon, disons que c'est un début;
- réduire l'empreinte mémoire; je pense qu'en l'état, la seule chose qu'on gagne, c'est la différence entre les fonctions du core et les autres; dès qu'on utilise des fonctions de /extension, on a une tripotée de fichiers mais qui sont très souvent appelées;
- pouvoir proposer des fonctions pour différentes librairies (cas des fonctions sql_xxx); ici ça n'est pas du tout le cas (et sans intérêt dans qu'il n'existe pas de réelle d'alternative à GD2);
- faciliter la maintenance du code en séparant ventilant clairement les fonctions dans des fichiers clairement identifiés (ce qui avait conduit, déjà et en bien, à créer filtres_images); là j'ai indiqué que l'extrême ventilation est artificielle et pas du tout efficace.
Cela dit, personnellement, je n'ai plus croisé de serveurs dans GD2 depuis des lustres. Si on simplifiait image_reduire pour qu'elle utilise directement GD2 sans rien demander à personne, je n'irais pas pleurer.
Et moi ça me fait pleurer de lire ça, c'est pas parce que Gd2 se
trouve souvent que c'est pareil pour tout le monde. Gd2 ne réponds à
toutes les problématique d'image et je trouve dommage de s'encombrer
avec 2 librairies quand une seule peut suffire et surtout qu'on fait
semblant de donner le choix.
Je ne vois pas bien en quoi on n'est pas d'accord, là. «S'encombrer avec 2 librairies quand une seule peut suffire», c'est mon propos. En réalité, c'est méthodes différentes pour la réduction d'images qu'on propose: GD1, GD2, NetPBM et Convert d'Imagick.
Ce qui explique la différence, c'est la volonté de garantir le plus possible le fonctionnement de image_reduire, parce que réduire les images est une sorte de minimum vital pour pouvoir faire un site Web aujourd'hui. D'où le fait qu'on a proposé 4 méthodes différentes qui couvrent tout ce qu'on a pu rencontrer comme situations sur des serveurs (sachant tout de même que NetPBM et Convert demandent un niveau technique relativement élevé pour pouvoir fonctionner).
Par ailleurs, il ne bien avoir conscience que ce qu'on peut faire avec GD2, c'est-à-dire toutes les autres fonctions de traitement d'images, ne peut pas être réalisé avec les autres librairies, parce que ces fonctions analysent les images en les parcourant pixel par pixel. Et image_typo utilise les fonctions de création d'image à partir de polices de caractères qui n'ont pas d'équivalent en dehors de GD2.
Il y a quelques possibilités avec Imagick, on pourrait bien imaginer tenter de développer des équivalents des fonctions pour cette librairie, mais ça serait sans doute moins puissant, moins problématique et, plus grave, donnerait sans doute des résultats différents. SPIP devrait donner des résultats identiques avec une librairie ou l'autre, mais je pense que ça ne serait pas du tout le cas.