[spip-dev] Version CVS : PHP & [(#FORMULAIRE_INSCRIPTION)]

Bonsoir,

La nouvelle version de ce soir corrige pas mal de problèmes (nottamment les champs URL_SITE et NOM_SITE des articles syndiqués). Par contre j'avais une page qui ne s'affichait pas (le SQUELETTE est visible sur http://www.livres-online.com/SQUELETTES2004/login.html).

En creusant j'ai vu que c'est ce code qui posait problème :

<?php if (!$auteur_session) { ?>
        (...)
        [(#FORMULAIRE_INSCRIPTION)]
<?}?>

En effet cela génère dans le cache :

' (......) ';
        $spip_lang = $GLOBALS["spip_lang"];
$t0 = $t0. (lire_meta("accepter_inscriptions") != "oui") ? "" :
            ("<"."?php include('inc-formulaires.php3'); lang_select(\"$spip_lang\"); formulaire_inscription(\"redac\"); lang_dselect(); ?".">") .
        '

Et du coup la page livrée au navigateur est complètement vide :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY></BODY></HTML>

J'imagine que c'est un problème de coexistence de codes PHP...

Bonne nuit à tous,

Dadoo

Non, c'était un mauvais parenthésage dans une l'expression conditionnelle "c?v:f"
de cette balise.
Fixé sur le CVS.

esj

Non, c'était un mauvais parenthésage dans une l'expression
conditionnelle "c?v:f"
de cette balise.

Genre de choses qui n'arriverait pas si le code respectait certaines
règles de propreté, et le coding style en vigueur.

Si tu avais eu la curiosité de voir précisément de quoi il s'agissait,
au lieu de profiter facilement d'une information que je n'ai pas le temps de peaufiner,
tu aurais vu que ce n'était pas dans le code de Spip que le problème se posait,
mais dans le code généré par le compilateur, dont le rôle est justement de produire du code sale mais efficace.

esj

Emmanuel :

tu aurais vu que ce n'était pas dans le code de Spip que le problème se
posait,
mais dans le code généré par le compilateur, dont le rôle est justement
de produire du code sale mais efficace.

Oui, le code est manifestement sale mais tu n'as toujours pas montré
qu'il est plus efficace que du code propre. Mesures objectives à
l'appui.

(Ceci dit tu noyes le poisson car le code sale ou non conforme aux
conventions d'écriture ne se situe pas uniquement dans le code généré
mais dans une grande partie du code que tu as committé. Ceci bien que la
première remarque à ce sujet t'ait été faite il y a neuf mois (!)... par
ton premier beta-testeur : moi. Et la deuxième très récemment par Fil.)

Comme cette question ouverte date de nos discussions d'il y a plusieurs
mois, et que tu as totalement refusé de prouver tes dires concernant les
performances du nouveau compilateur, on ne peut qu'en déduire qu'il n'y
aucun avantage en performances, ou qu'il est trop petit pour compenser
l'inconvénient d'un code illisible et inmaintenable - et potentiellement
indébuggable : cf. problèmes des messages d'erreur retournés par eval().
(ce qui ne veut pas dire que le compilateur n'ait pas d'autres
avantages, là n'est pas la question.)

Je ne comprends pas pourquoi tu persistes avec cet argument alors que
son caractère infondé a été abondamment discuté il y a plusieurs mois
(cf. forums internes de spip-contrib).

Amicalement

Antoine.

Houla, je sens que ça se tend un peu la, relax !

1) Le boulot d'Emmanuel est énorme et les apports fonctionnels sont
incontestables.
Alors qu'il y ait ou non un gain de perf, mesurable ou non, n'est pas le
plus important : c'est fonctionnellement mieux (enfin, il y a des trucs en
plus et rien en moins)
Ca me parait de toute façons difficile de comparer les perfs : sur quel type
de squelette ?
On trouvera peut être des squelettes sur lesquels l'ancienne version est
plus rapide(ce qui n'est même pas sur), mais forcement d'autre ou le nouveau
compilo a des perfs incomparables (cache du PHP notamment)
L'important étant surtout qu'il n'y ait pas de dégradation de perf notable
(genre 10 fois moins rapide et 2 fois plus de place comme ca s'est vu
lorsque des "professionnels" refondent le code...), et la, ça se saurait.
Il me semble d'ailleurs qu'Emmanuel avait fait des tests qui appuyaient ses
dires mais le mode opératoire étant critiquable, les a laissé dans un
tiroir.

2) ayant aussi suivi les évolutions de la bête, il est assez difficile de
comparer la version actuelle à celle d'il y a quelques mois qui posait le
cache en base de données.
Je trouve que de ce point de vue, le fait d'avoir pu rebasculer en file
system puis finalement d'en remettre un bout en base de donnée devrait
suffire à démontrer la maintenabilité du code.

3) Dans le cas de squelettes contenant du PHP, je ne pense pas qu'une mesure
soit nécessaire : si c'est "cachable", c'est "caché", et la il n'y a pas
photo sur les perf entre rappeler un cache ou réexecuter du code.

4) concernant la lisibilité du code, je regarde SPIP depuis quelques mois et
tout cela s'améliore à chaque version, je ne pense pas que le code actuel
soit vraiment critiquable si on le compare à la 1.6 qui n'est pourtant pas
si vieille.
Les dernières semaines ont été très riches en refontes et modifications et
tout le monde sait que ça n'est pas en phase de debug et dans le speed qu'on
produit du beau code commenté.
La séparation des traitements en plusieurs fichiers améliore nettement la
lisibilité, la maintenabilité et réduit largement les risques de régression,
c'est déjà une belle avancée, reste à bien nettoyer et commenter le code, ça
me parait assez logique d'attendre que le code soit stabilisé pour faire ce
travail (qui pourrait d'ailleurs être fait par qqun d'autre qu'Emmanuel qui
a déjà bien donné je pense).

5) j'ai peut être raté un épisode, mais il me semble que coté
"indebuggable", on a plutôt un gain de clarté au niveau des messages
d'erreur et, si ça mérite encore des améliorations, la structuration du code
permet une bien meilleur remontée d'information, mais la, je m'avance peut
être, car je n'ai pas suffisamment regardé l'ancien compilo (ni le nouveau
depuis quelques jours ...)

Alors quel est le problème de fond qui n'est sans doute pas expliqué ici et
qui nous donne droit à autant de réserves ?

Ce compilo nous apporte une telle souplesse que les contribs vont prendre un
tout autre sens très prochainement, alors soyons constructifs !
Rajouter des champs ou des tables devient une question de minute alors que
sur l'ancienne structure, il fallait tout se recoder et que la normalisation
même des boucle était soumise à de nombreuses exception, on a maintenant un
modèle carré et on peut se permettre de grosses modifs, même coté back
office, sans trembler sur les conséquences d'une mise à jour.

Quel est exactement le problème avec le code ?
As-tu des exemples de ce qui ne te convient pas avec ce que tu verrais à la
place ?
Je n'ai pas l'habitude de juger trop vite la qualité du code, ce qui fait
pourtant parti de mes fonctions, et en général, je dis pas "c'est nul" (ce
qui ne fait pas beaucoup progresser le "nul" en question et a plutôt
tendance à dégrader encore un peu la qualité de son travail, pour lequel il
est pourtant payé), je dis plutôt "tu devrais faire comme ça" (ce qui est
quand même plus constructif, bien que plus risqué ...)

Restons donc constructif et faisons aboutir rapidement ce boulot
d'intégration qui s'est déjà plié, me semble-t-il, à toutes les contraintes
posées par Spip (compatibilité ascendante, versions de PHP et de MySQL, pas
de POO, respect des exceptions de fonctionnement ...)

Encore bravo à tous pour ces derniers jours dont la productivité doit faire
pâlir quelques professionnels ...

@++

Bonjour Stéphane,

Faudrait peut-être lire le message avant de répondre ? Ou même, te
renseigner sérieusement sur le sujet ?

1) Le boulot d'Emmanuel est énorme et les apports fonctionnels sont
incontestables.

En temps de travail, c'est énorme. Les apports fonctionnels sont là. Je
n'ai jamais dit le contraire. Je ne propose pas qu'on revienne à
l'ancien code. (tu peux relire mon message ?)

Alors qu'il y ait ou non un gain de perf, mesurable ou non, n'est pas le
plus important

Merci de le confirmer, c'est ce que je pense aussi. (peux-tu relire mon
message ?)

On trouvera peut être des squelettes sur lesquels l'ancienne version est
plus rapide(ce qui n'est même pas sur), mais forcement d'autre ou le nouveau
compilo a des perfs incomparables (cache du PHP notamment)

As-tu déjà mis le nez dans l'ancien compilateur avant de sortir
n'importe quoi ? Peux-tu me citer un cas *significatif* (pas juste dix
lignes de PHP séquentiel) où le nouveau compilateur cache des choses qui
n'étaient pas cachées dans l'ancien ?

Il me semble d'ailleurs qu'Emmanuel avait fait des tests qui appuyaient ses
dires mais le mode opératoire étant critiquable,

Je n'ai toujours pas lu un argument crédible pour expliquer en quoi le
mode opératoire était critiquable (encore moins une proposition d'un
*autre* mode opératoire). D'ailleurs Emmanuel ne le trouvait pas
critiquable au début, lorsqu'il montrait un gain en performances pour
son compilateur. Je suis bien placé pour le savoir : c'est moi qui l'ai
aidé à réaliser les mesures en question.

Alors voilà il y a trois solutions pour mesurer les performances :
- ce que je fais : utiliser un bench HTTP (type ApacheBench, mais il y
en a d'autres)
- utiliser des "microtime" dans le code PHP (mais le problème est qu'on
oublie les temps de parsing des fichiers inclus en premier lieu)
- lancer le truc en ligne de commande (si c'est possible), style "time
php -q"

La quatrième solution c'est de ne rien mesurer et de prétexter des gains
en performances basés sur des arguments fallacieux.

4) concernant la lisibilité du code, je regarde SPIP depuis quelques mois et
tout cela s'améliore à chaque version,

Moi je développe SPIP depuis trois ans, et je confirme que cela
s'améliore à chaque version. Cependant je ne parle pas du code en
général, je parle du compilateur. Merci de rester dans le sujet.

Les dernières semaines ont été très riches en refontes et modifications et
tout le monde sait que ça n'est pas en phase de debug et dans le speed qu'on
produit du beau code commenté.

Le code en question est tranquillement développé en interne par Emmanuel
depuis neuf mois, que viennent faire les phases de speed et de debug
là-dedans ?

reste à bien nettoyer et commenter le code,

C'est exactement ce que je disais. Tu as lu mon message ?

ça
me parait assez logique d'attendre que le code soit stabilisé pour faire ce
travail

C'est bizarre, moi j'ai plutôt tendance à penser qu'il est beaucoup plus
sain de faire du code propre le plus tôt possible, et que le salir
volontairement pour cause de micro-optimisations doit être 1) remis au
plus tard possible 2) dûment prouvé par des mesures de performances.

Je te laisse choisir laquelle des méthodologies est la plus viable.

(qui pourrait d'ailleurs être fait par qqun d'autre qu'Emmanuel qui
a déjà bien donné je pense).

Et les autres développeurs de SPIP, ils ont pas assez donné ? Si on
t'avait livré un SPIP codé à la porc sous prétexte qu'on a déjà assez
travaillé et que tu n'as qu'à nettoyer le code toi-même, tu dirais quoi
?

Le développement collaboratif ce n'est pas la taylorisation du travail
intellectuel, il n'y a pas un gars qui écrit le code et un autre qui
corrige les fautes d'orthographe derrière. Et surtout, quand on arrive
dans un projet existant, on s'adapte aux conventions établies.

et en général, je dis pas "c'est nul" (ce
qui ne fait pas beaucoup progresser le "nul" en question et a plutôt
tendance à dégrader encore un peu la qualité de son travail, pour lequel il
est pourtant payé), je dis plutôt "tu devrais faire comme ça"

Oui, moi aussi. Seulement la première fois tu expliques gentiment, et
les fois suivantes tu deviens un peu plus laconique, c'est naturel non ?
Emmanuel sait très bien ce qu'il faut faire, il faut principalement :
- éviter les expressions de vingt lignes de long, et autres
constructions illisibles
- nommer les variables et fonctions de façon cohérente avec le reste de
SPIP
- utiliser des tabulations pour l'indentation (une indentation == une
tabulation)

et faisons aboutir rapidement ce boulot
d'intégration qui s'est déjà plié, me semble-t-il, à toutes les contraintes
posées par Spip (compatibilité ascendante, versions de PHP et de MySQL, pas
de POO, respect des exceptions de fonctionnement ...)

Le "pas de POO" n'a jamais été une contrainte de SPIP. Par contre, "pas
de POO dispendieuse et inutile", c'est préférable.

Pour la version de PHP, vu le nombre de foreach que j'ai vu passer ça ne
peut de toute façon pas être compatible PHP3, et côté MySQL certaines
constructions font/faisaient intervenir des sous-requêtes (MySQL > 4.1).
Ce n'est pas forcément un problème redoutable, mais je ne dirais pas que
ces contraintes ont été scrupuleusement respectées...

Pour ce qui est de la compatibilité ascendante, on a frisé la
catastrophe ({doublons} qui change totalement de sémantique). <INCLURE>
a semble-t-il un peu changé mais cela reste mineur.

Quant aux conventions de codage (nommage des variables, indentation du
code, lisibilité, tout ça), le moins qu'on puisse dire est qu'elles ne
sont pas du tout respectées.

Et mon problème à moi c'est que la synchronisation avec spip-lab
implique de backporter les nouveautés importantes (dans un sens comme
dans l'autre) quand elles sont terminées. Or moi je ne peux pas
backporter un code aussi incohérent avec le reste des conventions de
style et de lisibilité ; et je ne jouerai pas le nettoyeur de service.
S'il n'y a pas de backport, les deux branches deviennent incompatibles
et c'est la merde. Tu comprends ?

Amicalement

Antoine.

Merci Stéphane, tu viens de dire le fond de ma pensée sur bien des points,
alors que je n'ai pas le temps de faire.
Je profite néanmoins de ce qu'il n'y ait plus de bug pendant (je crois),
pour prendre le temps de donner qq informations supplémentaires.

1. je reconnais que le message d'erreur sur eval et non plus sur un fichier nommé
est une incommodité que n'avait pas la version précédente.
C'est le prix de l'économie d'un accès en lecture au disque.
Néanmoins, le répertoire des Caches contient le code en question et
son nom est indiqué dans ecrire/data/spip_log, on peut donc s'y retrouver.
De plus, ces erreurs se raréfieront à mesure que le compilateur sera débugué:
pas de quoi en faire un fromage donc.

2. mon style syntaxique est inspiré des langages de la famille de Lisp,
lequel a toujours suscité des passions contradictoires sur sa syntaxe,
mais pas sur sa sémantique, réputée la plus propre qui soit:
pas de variables globales, pas d'affectations, pas de variables indéfinies
(quand on ne recourt pas aux licences de certaines de ses implémentations).
Comme l'a remarqué Stéphane, que j'ai pu changer d'implémentation des caches
a deux reprises en peu de temps (ou proposer 2 sémantiques pour le critère doublons)
prouve une certaine propreté. Ce qui n'est pas acceptable dans ton attitude, Antoine,
c'est que tu te poses en Dieu le père de ce qui est propre et de ce qui ne l'est pas.
N'étant pas xénophobe, j'admets que ma syntaxe soit discutable, mais que dire de ta sémantique ?
Par ses variables globales référencées à tous les coins de fichier, lire ton code oblige à avoir
les yeux partout à la fois (en particulier les références croisées entre le code compilé
et le système de cache m'ont contraint à proposer leurs refontes en seul paquet,
qui lui, justement, permettra à d'autres de ne remplacer que l'un des deux au besoin).
Mon code est peut-etre difficile à lire quand on n'a pas l'habitude de ce style,
mais la difficulté est circonscrite à chaque fonction. Il est aussi abondamment commenté,
ce qui n'était pas le cas du tien.

3. je redis que mon but était d'avoir un compilateur extensible, pas d'améliorer les performances.
Mais comme je devais le réécrire, j'en ai profité pour faire des optimisations standards,
qui n'ont pas besoin de bench pour s'assurer qu'au pire ça ne coutera pas plus cher.
J'ai donc réduit les demandes au serveur SQL aux seuls champs utiles (plutot que le "select *" originel),
je produits une instruction de N arguments plutot que N instructions à un seul argument.
Ca n'est pas fondamental, mais au bout du compte c'est ce qui permet par exemple de voir qu'une boucle
est quasi vide et qu'on peut donc éliminer les N appels au serveur SQL. Et là ça devient intéressant.
Mais tu fais toujours référence à mon premier travail il y a un an, le seul que tu as regardé en détail,
qui évidemment n'était pas encore très concluant puisque je découvrais Spip (et PHP que je ne connaissais
presque pas à l'époque). En particulier, contrairement à ce que tu dis, j'ai décrit dans mes dernières
contrib un autre mode opératoire et nous avons d'ailleurs échangé à ce sujet: tout ce que tu prétendais
c'est que c'était infaisable, alors que je prouve le contraire.

4. envoyer sur la liste des remarques acerbes est une perte de temps et d'énergie pour tous.
Ce qui en ressort in fine c'est que tu cherches à me démotiver,
ce qui, quelqu'en soit le résultat, n'est pas très bon pour ta propre image.
Et je trouve ça dommage, car même si je pense que tu n'es pas un aussi bon codeur que tu le prétends,
tu mérites mieux que de passer ton temps (et celui des autres!) a te déconsidérer de la sorte.

Amicalement,

  Emmanuel

Faudrait peut-être lire le message avant de répondre ? Ou même, te
renseigner sérieusement sur le sujet ?

Comme je le disais, je manque de temps en ce moment, alors je fais ce que je
peux pour apporter mes 2 cents, le soutien moral en fait parti, à defaut de
mieux ...
Ceci dit, j'ai adopter UPMCv2 puis 3 ... en y faisant des modifs, j'ai donc
pas mal mis le nez dans le code jusqu'à ces dernieres semaines ou j'ai du
decrocher par manque de disponibilité.
J'ai fait ce mail car je trouvai le ton un peu acide au vu du boulot fourni,
meme si tu es sans doute un des rares à pouvoir te le permettre ...
qu'est-ce que ca apporte ?

> On trouvera peut être des squelettes sur lesquels l'ancienne version est
> plus rapide(ce qui n'est même pas sur), mais forcement d'autre ou le

nouveau

> compilo a des perfs incomparables (cache du PHP notamment)

As-tu déjà mis le nez dans l'ancien compilateur avant de sortir
n'importe quoi ?

Non, et c'est ce que je disais (tu peux relire mon message ?)

Peux-tu me citer un cas *significatif* (pas juste dix
lignes de PHP séquentiel) où le nouveau compilateur cache des choses qui
n'étaient pas cachées dans l'ancien ?

N'importe quel traitement fait à partir de parametres specifiques passés en
GET ou en POST me semble-t-il.
Alors si le traitement est une usine à gaz, on gagne beaucoup, si il est
petit, on gagne un petit peu.
C'est à mon avis un gain enorme.
La possibilité d'abandonner les extras au profit de champs supplementaires,
indexables et requetables me semble egalement un apport fonctionnel avec des
implications importantes sur les perfs (surtout si on veut faire un tri ou
des filtres sur ces cirteres)

> Il me semble d'ailleurs qu'Emmanuel avait fait des tests qui appuyaient

ses

> dires mais le mode opératoire étant critiquable,

Je n'ai toujours pas lu un argument crédible pour expliquer en quoi le
mode opératoire était critiquable (encore moins une proposition d'un
*autre* mode opératoire). D'ailleurs Emmanuel ne le trouvait pas
critiquable au début, lorsqu'il montrait un gain en performances pour
son compilateur. Je suis bien placé pour le savoir : c'est moi qui l'ai
aidé à réaliser les mesures en question.

Alors voilà il y a trois solutions pour mesurer les performances :
- ce que je fais : utiliser un bench HTTP (type ApacheBench, mais il y
en a d'autres)
- utiliser des "microtime" dans le code PHP (mais le problème est qu'on
oublie les temps de parsing des fichiers inclus en premier lieu)
- lancer le truc en ligne de commande (si c'est possible), style "time
php -q"

La quatrième solution c'est de ne rien mesurer et de prétexter des gains
en performances basés sur des arguments fallacieux.

Je n'ai pas tout suivi de ce coté la non plus, l'important reste à mes yeux
qu'il n'y ait pas de baisse de perf, et les simples tests de debuggage ne
semble pas en faire ressortir.
Ceci dit, les seuls tests non critiquable que j'ai rencontré jusqu'ici ont
été fait par Sun pour un client pour evaluer des environnement J2EE, je n'ai
pas vu la facture, mais ca a pris une semaine à quelques pointures pour y
arriver et ils disposaient d'une belle plateforme bien isolées et des
ressources suffisantes pour que le "coté client" n'entre pas en compte.
Personnellement j'utilise OpenSTA qui a l'avantage de pouvoir observer
séparement les differents processus et de mesurer le temps de reponse
effectif pour N sessions en jouant des scenari en paralelle.
Le probleme est vraiment d'isoler le systeme et de disposer de suffisement
de ressources machine et reseau pour jouer les tests.

> 4) concernant la lisibilité du code, je regarde SPIP depuis quelques

mois et

> tout cela s'améliore à chaque version,

Moi je développe SPIP depuis trois ans, et je confirme que cela
s'améliore à chaque version. Cependant je ne parle pas du code en
général, je parle du compilateur. Merci de rester dans le sujet.

La propeté du code me semble quelque chose de tres relatif ... il faut donc
bien se referer à quelque chose non ?

> Les dernières semaines ont été très riches en refontes et modifications

et

> tout le monde sait que ça n'est pas en phase de debug et dans le speed

qu'on

> produit du beau code commenté.

Le code en question est tranquillement développé en interne par Emmanuel
depuis neuf mois, que viennent faire les phases de speed et de debug
là-dedans ?

Il me semble pourtant qu'il y a eu pas mal de changement recemment, mais je
parle de l'ensemble des fichiers de la contrib, peut etre parles-tu d'un
fichier en particulier, mais tu n'etais pas tres precis ...

> reste à bien nettoyer et commenter le code,

C'est exactement ce que je disais. Tu as lu mon message ?

Et toi tu as lu le mien ?
Faut arreter la parano !
Je dis juste que le code est un peu jeune et mouvementé pour pouvoir exiger
la qualité immediate, c'est tout.

> ça
> me parait assez logique d'attendre que le code soit stabilisé pour faire

ce

> travail

C'est bizarre, moi j'ai plutôt tendance à penser qu'il est beaucoup plus
sain de faire du code propre le plus tôt possible, et que le salir
volontairement pour cause de micro-optimisations doit être 1) remis au
plus tard possible 2) dûment prouvé par des mesures de performances.

Je te laisse choisir laquelle des méthodologies est la plus viable.

Je parle des commentaires et de l'indentation, pas des modif, je ne me
permettrait pas de juger de l'efficacité d'un bout de code, sauf si j'ai
mieux à proposer.

> (qui pourrait d'ailleurs être fait par qqun d'autre qu'Emmanuel qui
> a déjà bien donné je pense).

Et les autres développeurs de SPIP, ils ont pas assez donné ? Si on
t'avait livré un SPIP codé à la porc sous prétexte qu'on a déjà assez
travaillé et que tu n'as qu'à nettoyer le code toi-même, tu dirais quoi
?

Ca depend ce que tu appelles "codé à la porc"...
Mais une chose est sure, je ne serai pas venu gueuler sur la liste que
c'etait mal codé, et si je l'avais fait, tu m'aurais envoyé chier et tu
aurais eu raison.
Est-ce que le code doit etre propre et bien commenté pour avoir le droit
d'atterir sur la beta du CVS ?
Le plus possible, OK, mais une fois la machine lancée, il faut gerer les
urgences.
Il a fallu du temps à Spip pour arriver au niveau de qualité actuel, je
pense qu'on peut laisser un peu de temps à ce nouveau compilo avant de
s'enerver, non ?

Le développement collaboratif ce n'est pas la taylorisation du travail
intellectuel, il n'y a pas un gars qui écrit le code et un autre qui
corrige les fautes d'orthographe derrière. Et surtout, quand on arrive
dans un projet existant, on s'adapte aux conventions établies.

Je ne connais pas les echanges que vous avez eu avant de decider de
l'integration, mais on ne peut pas dire que ce genre d'information soit bien
formalisée quelque part ... ou alors je ne les ai pas trouvé
C'est à mon avis un manque car cette norme n'est du coup pas discutable et
soumise à interpretation (genre si si, j'ai trouvé une fonction nommée comme
ca)

> et en général, je dis pas "c'est nul" (ce
> qui ne fait pas beaucoup progresser le "nul" en question et a plutôt
> tendance à dégrader encore un peu la qualité de son travail, pour lequel

il

> est pourtant payé), je dis plutôt "tu devrais faire comme ça"

Oui, moi aussi. Seulement la première fois tu expliques gentiment, et
les fois suivantes tu deviens un peu plus laconique, c'est naturel non ?

Oui, mais ces echanges n'ont pas eu lieu sur cette liste me semble-t-il...

Emmanuel sait très bien ce qu'il faut faire, il faut principalement :
- éviter les expressions de vingt lignes de long, et autres
constructions illisibles
- nommer les variables et fonctions de façon cohérente avec le reste de
SPIP
- utiliser des tabulations pour l'indentation (une indentation == une
tabulation)

Ben voila qui est plus clair !
-Pour les expressions, il me semble qu'il est un peu tard ou qu'il n'y a pas
urgence.
Le debug a l'air de toucher à sa fin, et je pense qu'Emmanuel connait son
code.
Apres, evidement, c'est necessaire pour que ce code puisse etre maintenu,
mais c'est un bon moyen de s'approprier du code, je trouverai donc judicieux
que cela soit fait par qqun d'autre.
- Pour le nommage des fonctions, ca me parait urgent, il faudrait donc
lister ce qui ne convient pas et proposer de nouveaux nommage, ca serit sans
doute plus constructif et chacun pourra defendre objectivement ses opinions.
Les modifications sont ceci dit assez facile à faire (refactoring ou
rechercher remplacer)
- Pour l'indentation, je comprend mieux l'agacement, mais il y a des outils
qui font ca tres bien, c'est quand meme pas si grave ...

> et faisons aboutir rapidement ce boulot
> d'intégration qui s'est déjà plié, me semble-t-il, à toutes les

contraintes

> posées par Spip (compatibilité ascendante, versions de PHP et de MySQL,

pas

> de POO, respect des exceptions de fonctionnement ...)

Le "pas de POO" n'a jamais été une contrainte de SPIP. Par contre, "pas
de POO dispendieuse et inutile", c'est préférable.

Nous sommes d'accord la dessus et je crois que le dernier rappel des
arguments etait convainquant.
Ca n'etait vraiment pas une critique.

Pour la version de PHP, vu le nombre de foreach que j'ai vu passer ça ne
peut de toute façon pas être compatible PHP3, et côté MySQL certaines
constructions font/faisaient intervenir des sous-requêtes (MySQL > 4.1).
Ce n'est pas forcément un problème redoutable, mais je ne dirais pas que
ces contraintes ont été scrupuleusement respectées...

Je n'ai pas regardé les dernieres versions , mais il me semble que les sous
requetes avaient été ecartées au maximum
Quant à PHP3, je croyais que la decision avait été prise d'abandonner la
compatibilité pour la 1.8 avant l'annonce de l'integration du compilo, mais
je me plante peut etre ...

Pour ce qui est de la compatibilité ascendante, on a frisé la
catastrophe ({doublons} qui change totalement de sémantique). <INCLURE>
a semble-t-il un peu changé mais cela reste mineur.

Ca a été reparer en un temps record, ce qui renforce encore l'idée que ce
code est maintenable

Quant aux conventions de codage (nommage des variables, indentation du
code, lisibilité, tout ça), le moins qu'on puisse dire est qu'elles ne
sont pas du tout respectées.

Et mon problème à moi c'est que la synchronisation avec spip-lab
implique de backporter les nouveautés importantes (dans un sens comme
dans l'autre) quand elles sont terminées. Or moi je ne peux pas
backporter un code aussi incohérent avec le reste des conventions de
style et de lisibilité ; et je ne jouerai pas le nettoyeur de service.
S'il n'y a pas de backport, les deux branches deviennent incompatibles
et c'est la merde. Tu comprends ?

Oui beaucoup mieux, mais je pense que le probleme pouvait etre posé
autrement (et je ne suis pas sur que ca soit le seul probleme ...).
Tu pourrais par exemple nous lister les fichiers problematiques et nous dire
ce qu'il faudrait faire pour qu'ils te conviennent, chacun pourra alors
faire un petit bout de nettoyage dans les semaines à venir et tout pourra
rentrer dans l'ordre sans enervement inutile.
Si Spip est bien une communauté comme je le crois, il me semble qu'il faut
permettre à tout le monde de s'impliquer.
Dans cette affaire, tout le monde a découvert du jour au lendemain que
l'integration commencait, sans vraiment avoir les elements, sans connaitre
les raisons du choix, les points de friction ...
beaucoup de discussions ont eu lieu entre vous en amont, nous ne savons pas
tout, ce n'est quand meme pas toi qui va nous le reprocher ???
Je trouve que l'implication generale des derniers jour montre à quel point
le choix est bon, alors maintenant, avancons de facon constructive.

@++

Ce qui n'est pas acceptable dans ton
attitude, Antoine,
c'est que tu te poses en Dieu le père de ce qui est propre et de ce qui
ne l'est pas.

Non.

Je n'ai pas "inventé" ce qui est propre ou pas. Je me suis plié aux
conventions syntaxiques existantes quand j'ai commencé à travailler sur
SPIP. Je n'ai pas cherché à dire que les tabulations étaient mieux ou
moins bien que les espaces, que le MixedCase est préférable à
l'under_score, etc. Tout cela tient de la religion. Ce qui est
important, c'est de suivre les conventions établies pour ne pas embêter
tout le monde.

D'autre part, le fait de ne pas laisser courir une expression sur vingt
lignes, par exemple, n'est pas une règle de mon invention. C'est une
convention acceptée par tout programmeur sérieux. De même qu'en français
on n'écrit pas un paragraphe de vingt lignes sans ponctuation.

Ce que je me tue à t'expliquer, c'est que le travail en groupe sur un
logiciel informatique fait l'objet de règles communément admises, comme
celle de s'adapter au style du code existant quand on arrive sur un
projet.

Un code propre, c'est un code lisible et cohérent. Je ne vois pas
pourquoi je serais "Dieu le père" pour rappeler une vérité aussi simple,
et aussi évidente à quiconque a déjà programmé.

N'étant pas xénophobe, j'admets que ma syntaxe soit discutable, mais
que dire de ta sémantique ?

Ce n'est pas *ma* sémantique, c'est celle du projet. Tu sembles penser
(peut-être parce que cela te rend la réplique commode) que tout
l'existant dans SPIP vient de moi. Non. Il vient, grosso modo à parts
égales, de trois personnes : Arno, moi et Fil. Ces trois personnes ont
suivi au cours des années des conventions plus ou moins tacites.

Mon code est peut-etre difficile à lire quand on n'a pas l'habitude de
ce style,

Ce n'est absolument pas une question d'*habitude* de ton style. C'est :

1. Une question de cohérence. Tu introduis un style de programmation
totalement différent de l'existant. Même s'il était aussi lisible de
l'existant, il serait tout de même totalement différent donc perturbant
quand on passe d'un bout de code à l'autre.

2. Une question de lisibilité générale. Habitude ou non, des expressions
de vingt lignes ne sont pas lisibles : c'est le genre de code qui obligé
à s'y reprendre à trois fois pour savoir comment s'enchaînent les
différents termes de l'expression. (tout de même, tu as dit toi-même
qu'il s'agissait de code "sale")

3. je redis que mon but était d'avoir un compilateur extensible, pas
d'améliorer les performances.
Mais comme je devais le réécrire, j'en ai profité pour faire des
optimisations standards,
qui n'ont pas besoin de bench pour s'assurer qu'au pire ça ne coutera
pas plus cher.

Comme écrit dans mon message, je parlais des micro-optimisations qui te
conduisent, tu l'as dit toi-même, à écrire "du code sale mais efficace".
J'ai rappelé que l'efficacité de ce code n'avait jamais été prouvée,
donc que sa saleté n'avait aucune justification.

J'ai donc réduit les demandes au serveur SQL aux seuls champs utiles
(plutot que le "select *" originel),

Je ne parle pas de cela. C'est une optimisation louable (et
effectivement difficile avec l'ancien compilateur).

je produits une instruction de N arguments plutot que N instructions à
un seul argument.

Ca, c'est une micro-optimisation qui fait partie de cette obfuscation
générale du code. Je t'invite à désactiver temporairement ces
micro-optimisations dans ton code, et à chronométrer la différence. Si
tu ne veux/peux pas le faire, cela veut dire que l'optimisation que tu
allègues pour ce code "sale" n'est aucunement prouvée.

4. envoyer sur la liste des remarques acerbes est une perte de temps et
d'énergie pour tous.

Ce qui est une perte d'énergie, c'est de ne pas comprendre les remarques
d'ordre général sur la lisibilité du code, bien que je les aie émises
plusieurs fois, et Fil aussi (indentation, nom des variables, etc.). Mes
remarques n'étaient pas "acerbes" lorsque je t'ai pointé les mêmes
défauts, il y a des mois.

Ce qui en ressort in fine c'est que tu cherches à me démotiver,

N'importe quoi. Du pur procès d'intention. Par contre, à chaque critique
tu essaies de faire la comparaison avec ce que tu penses être mon code
et mes intentions, comme si transformer les critiques en une
confrontation personnelle pouvait éliminer la validité des critiques
émises.

Du reste, si j'avais voulu te démotiver j'aurais envoyé mes remarques
dès les premiers commits, je n'aurais pas attendu que le debug soit en
bonne voie.

Et je trouve ça dommage, car même si je pense que tu n'es pas un aussi
bon codeur que tu le prétends,

Je n'ai pas "prétendu" être un mauvais ni bon codeur. Je pense par
contre être assez informé pour donner mon avis sur du code contribué à
SPIP... Et encore une fois tout ceci n'a rien à voir avec le cursus ni
les compétences, fabulées ou réelles, de chacun.

Amicalement

Antoine.

Je confirme que le bug est corrigé.

Merci et désolé d'avoir déclenché ce thread :slight_smile: