La boucle regarde s'il y a un quatrième article avec un certain mot-clé. S'il y a effectivement un article, je n'affiche rien _dans_ la boucle, mais je balance une tripotée de choses dans la partie conditionnelle de la boucle. J'ai une tripotée de choses plus ou moins complexes qui s'imbriquent ainsi.
=> Sauf qu'avec la SVN actuelle, et c'est tout récent, ça ne marche plus: tant que je n'ai rien à l'intérieur de la boucle, même si la boucle a un résultat, ça n'affiche plus la partie conditionnelle de la boucle. Le seul moyen, c'est d'ajouter un machin bidon à l'intérieur de la boucle.
avec la SVN actuelle, et c'est tout récent, ça ne marche plus: tant que je n'ai rien à l'intérieur de la boucle, même si la boucle a un résultat, ça n'affiche plus la partie conditionnelle de la boucle. Le seul moyen, c'est d'ajouter un machin bidon à l'intérieur de la boucle.
L'explication est dans cette différence de type de résultat par MySQL, c'est assez surprenant:
SELECT count(*) FROM spip_articles AS `articles` INNER JOIN
spip_mots_articles AS L1 ON ( L1.id_article = articles.id_article ) WHERE (articles.statut = 'publie') AND (articles.date <= NOW()) AND (L1.id_mot = 0) ;
Ce me répondait bien OUI. Avec la dernière SVN, ça ne répond plus rien. Je suppose que ça me balancerait le conditionnel alternatif s'il y en avait un.
Pour corriger, j'ai bien essayé d'ajouter une ligne vide à l'intérieur de la boucle, mais ça ne fonctionne pas non plus.
Ce me répondait bien OUI. Avec la dernière SVN, ça ne répond plus rien. Je
suppose que ça me balancerait le conditionnel alternatif s'il y en avait un.
Pour corriger, j'ai bien essayé d'ajouter une ligne vide à l'intérieur de la
boucle, mais ça ne fonctionne pas non plus.
Non mais attends, ne touche pas à tes squelettes !
C'est le compilo qu'il faut corriger : il buggue dans ce cas précis
parce qu'Emmanuel a introduit une optimisation pour les boucles qui
n'ont besoin que du COUNT(*), sans penser que le LIMIT n'allait pas
suivre.
Par contre c'est probablement une boucle test qui mérite d'entrer dans
les tests unitaires, de manière à ne pas se faire optimiser
sauvagement la prochaine fois -- car tout le monde vérifie les tests
unitaires avant de commit, n'est-ce pas
Je ne vois pas bien ce que tu testes: il faut passer un id_mot qui contient des articles dans cet exemple (genre: {id_mot=3}).
Le pb n'est pas là et a bien été résumé par Fil, c'est LIMIT+COUNT qui ne va pas.
Pour corriger, j'ai bien essayé d'ajouter une ligne vide à l'intérieur de la
boucle, mais ça ne fonctionne pas non plus.
Non mais attends, ne touche pas à tes squelettes !
C'est le compilo qu'il faut corriger
oui, et c'est fait avec la 12160.
car tout le monde vérifie les tests
unitaires avant de commit, n'est-ce pas
J'ai toujours mon casse-noisettes de l'époque de mon premier compilateur comme test.
Mais les tests de la zone, c'est une belle animation mais je n'arrive pas à comprendre ce qu'il faut regarder.
Pour moi c'est au niveau de Trac/SVN qu'il faudrait agir: je mets dans le message du dépot les tests qui montrent les différences, c'est très important de pouvoir relier un test avec le code qui a été conçu pour lui.
Mais les tests de la zone, c'est une belle animation mais je n'arrive pas à
comprendre ce qu'il faut regarder.
Comment ça ? Il y a un fichier par test, qui répond :
- OK => et c'est vert
- NA => non applicable
- autre chose => et c'est rouge
il a des petites subtilités complémentaires mais ce sont des détails
négligeables dans une première approche.
Un test hello_world, pour vérifier si "spip fonctionne", se résume à ça :
<BOUCLE_hello_world(ARTICLES){0,1}>OK</BOUCLE_hello_world>
Pour moi c'est au niveau de Trac/SVN qu'il faudrait agir: je mets dans le
message du dépot les tests qui montrent les différences, c'est très
important de pouvoir relier un test avec le code qui a été conçu pour lui.
On peut aussi faire des tests qui ne sont pas liés à des dépots... et
l'autre avantage c'est que tests/ fonctionne dès aujourd'hui ... si on
veut bien se donner la peine d'y déposer les squelettes qui vont bien.
Mais je ne dis pas que ce serait forcément à toi de le faire : chacun
peut participer, plus on a de tests mieux on se porte. A chacun de
voir ce qu'il peut faire. Ca a aussi un côté ludique d'essayer de
deviner ce qui peut piéger SPIP.
Et bien moi, quand je fais tourner spip/tests TOUT est en rouge avec marqué "erreur" et quand je clique sur une ligne rouge il y a une ligne noire qui apparait avec marqué "ok". Alors je dis que c'est incompréhensible.
J'ai sans doute eu un pb d'installation, mais en l'état ça m'est nettement moins utile que la bardée de tests que j'a construit progressivement en développant le compilateur.
Et bien moi, quand je fais tourner spip/tests TOUT est en rouge avec marqué
"erreur" et quand je clique sur une ligne rouge il y a une ligne noire qui
apparait avec marqué "ok". Alors je dis que c'est incompréhensible.
En effet c'est pas comme ça que c'est censé marcher
J'ai sans doute eu un pb d'installation, mais en l'état ça m'est nettement
moins utile
ben oui comme un vélo cassé... ça marche pas
que la bardée de tests que j'a construit progressivement en
développant le compilateur.
Et bien moi, quand je fais tourner spip/tests TOUT est en rouge avec marqué
"erreur" et quand je clique sur une ligne rouge il y a une ligne noire qui
apparait avec marqué "ok". Alors je dis que c'est incompréhensible.
En effet c'est pas comme ça que c'est censé marcher
sans blague ?
la bardée de tests que j'a construit progressivement en
développant le compilateur.
mais qui ne sont pas partagés
Je les avais déposés à l'époque du CVS, ils doivent être quelque part, avec les limitations du compilateur du moment évidemment.
Mais ces 2 exemples montrent que si ce n'est pas intégré à l'acte de dépot, ça périclite et on remet à plus tard la réparation. C'est en ça que je dis qu'il faut plutot qqch de fondé sur l'analyse automatique des dépots.
En effet c'est pas comme ça que c'est censé marcher
sans blague ?
ben je sais pas pourquoi ça buggue chez toi, c'est la première fois
qu'on remonte un tel problème
qu'il faut plutot qqch de fondé sur l'analyse automatique des dépots.
vazy si tu veux ! mais là on a déjà développé un truc qui marche
(sauf chez toi, certes), ça paraît plus simple d'essayer de le faire
marcher chez toi que de développer tout un système compliqué autour de
svn.
ça pourrait être un mixte : si on couple le site de test à un répertoire du svn spip , il suffirait d’ajouter / modifier le squelette de test lie au commit comme ça on garde le couplage,
avec un cron pour mettre à jour régulièrement
mais faut garder aussi la possibiliter d’envoyer des tests depuis la zone pour ne pas limiter aux seuls commiteurs de spipdev.
