The Higher Education and Research forge

Home My Page Projects Code Snippets Project Openings Développement de WIMS
Summary Activity Forums Tracker Tasks Docs Surveys News SCM Files Listes Sympa

[#6908] Versions de logiciels annexes

Date:
2010-06-07 11:34
Priority:
3
State:
Open
Submitted by:
Eric Reyssat (reyssat)
Assigned to:
Nobody (None)
Hardware:
none
Operating System:
none
Version:
none
Severity:
none
Resolution:
none
URL:
état:
Summary:
Versions de logiciels annexes

Detailed description
Le fait qu'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d'erreurs.

Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n'étant pas toujours compatibles entre elles.



Exemple :
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
L'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes :

\integer{n= randint(8..25)}
\text{cardinal=pari(a=divisors(\n) ; vector(#a,i,eulerphi(a[i])))}

Dans l'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4).

Résultat : si (une copie de) l'exo est lancé dans createxo, on a un message d'erreur de pari. Mais s'il est appelé comme exo d'un module, l'erreur n'est même pas visible, sauf que les calculs qui suivent sont faux.

Essayer
http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn
qui prétend indûment que le nombre d'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Bien sûr pour cet exercice précis on peut s'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs.

C'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998.


Eric
Message  ↓
Date: 2010-06-09 13:10
Sender: Georges Khaznadar

récapitulons:
- c'est d'accord pour introduire une dépendance explicite entre version de wims et versions de logiciels annexes, pour Wims >= 4.00 ?
- la dépendance entre une version de module et une version de wims existe déjà
- c'est d'accord pour introduire la vérification des dépendances (par rapport aux logiciels annexes) par le module d'administration de Wims ?

Si les points ci-dessus sont actés, nous pourrions ajouter dans un cahier de charge de démarche-qualité, qu'un module publié ou republié dépendant de Wims >= 4.00 doit avoir été testé obligatoirement sur un service Wims où la vérification stricte des dépendances annexes a été validée.

Date: 2010-06-09 05:44
Sender: Eric Reyssat

Une des difficultés qu'on a vient du grand nombre de modules pédagogiques et de la variété des utilisations des logiciels de soutien (à cause de ou grâce à la variation aléatoire des exos).

Même si les versions plus récentes sont en principe plus correctes, les changements de comportement, qui peuvent être des améliorations ou corrections de bug ou nouvelles fonctionalités, induisent des changements de comportement dans wims qui peuvent devenir des bugs. En théorie on devrait donc vérifier tous nos modules pédagogiques dans toutes les situations à chaque changement de version.

C'est une raison qui fait qu'on petu préférer ne pas changer de version. Mais je suis bien d'accord qu'à long terme ce comportement mène plutôt dans l'impasse : il vaut peut-être mieux voir quelques modules wims anciens devenir bugués, ou se payer le boulot de les corriger, que d'empêcher les nouveaux modules de profiter des améliorations des logiciels.

Si la dépendance entre wims et les logiciels est indiquée, c'est bien clair qu'il faut que ce soit précis sinon c'est inutile (pas seulement pour maxima).

Enfin pour la sécurité, oui rien n'assure qu'il n'y a pas de problème avec les anciennes versions ; mais le travail fait pour limiter ces problèmes (le bug que tu signales sur maxima est partiellement pris en compte par wims) est en partie à refaire à chaque nouvelle version des logiciels et freine donc le développement.

Pour répondre à Bernadette, on pourrait dans l'idéal supposer qu'un des serveurs, Nice ou WimsEdu par exemple, serve de référence et "garantisse" des versions compatibles de tous les modules publiés, les autres serveurs n'ayant qu'à s'aligner sur ces versions de logiciels annexes (ou acceptant les risques de bug en cas contraire).

Dernière difficulté qui me vient en tête : la version chmod, mais qui l'utilise vraiment ?

Bien sûr je souligne ici surtout des difficultés, ce n'est pas pour être pessimiste, il y a plein de choses qui marchent bien en pratique même si tout le monde n'adopte pas la même politique de mise à jour des logiciels !

Eric

Date: 2010-06-08 21:57
Sender: Georges Khaznadar

Éric, si Maxima N accepte une syntaxe et que Maxima N+1 refuse cette même syntaxe, et que la syntaxe soit documentée comme correcte dans Maxima N, alors c'est un bug de Maxima N+1 et on est tenu de faire un rapport de bug en direction des développeurs de Maxima.

Quant à la dépendance Wims-> Maxima, celle-ci doit être versionnée avec précision.

Enfin, tu soulèves le problème de la sécurité. hmmm... qu'est-ce qui peut nous assurer qu'une version de Maxima, même utilisée depuis des années sans problème dans Wims, ne pose aucun problème de sécurité ? Exemple, pour une vielle version de Maxima : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431866 , un rapport de bug remonté en direction de l'équipe de développement amont.

Date: 2010-06-08 16:00
Sender: Bernadette Perrin-Riou

J'ai toujours considéré que si le serveur de Nice avait une version d'un logiciel je pouvais utiliser les commances correspondantes. Ainsi, pour publier le module sur l'algèbre linéaire sur Z, j'ai attendu que Nice soit sur une version permettant d'utiliser matsnf sans problème. Cela a dû coincider avec l'introduction de #.
Actuellement Nice est en version de pari GP/PARI CALCULATOR Version 2.2.10 (alpha) .

Remarque : il est marqué dans le README :
pari2.?? (http://pari.math.u-bordeaux.fr/). The most
recent version is recommended.

Cela n'évacue pas le problème. Il faut certainement modifier l'interface de motdool pour pouvoir mettre la version d'un logiciel, mettre quelque part au moment de la compilation un fichier avec les versions des logiciels (ce qui demande d'installer ces logiciels avant wims) et faire tester à l'ouverture des exos.

A savoir si les gens le rempliront. Le problème de pari est à mon avis particulier car il est très employé sans qu'on s'en apercoive. Maxima aussi (mais il est de plus en lent et gourmand, donc il est à déconseiller sauf quand on a vraiment besoin de calcul formel).
Il faut aussi mettre en en tete des types de réponses ou des slib les logiciels requis avec leur version ...


Bernadette


Date: 2010-06-08 15:04
Sender: Eric Reyssat

C'est peut-être une idée à creuser mais qui ne résout pas le problème des exercices qui étaient compatibles avec maxima version x et deviennent incompatible avec la version x+1.

Cette politique entraînerait l'obligation de retirer certains modules pédagogiques qui ne seraient plus compatibles, ou de tous les vérifier puis les corriger (ou en faire des clones modifiés, un par version de wims au pire).

Il y a aussi le problème de sécurité puisque chaque changement de version des logiciels annexes entraîne en principe un examen des failles de sécurité que cela introduit. Si maxima décide que la fonction "integrate" est à partir de la version 5.30 un appel au système permettant de tout détruire (pour être provoquant), on ne peut pas l'en empêcher mais on peut refuser l'installation sur le serveur wims d'une telle version qui rendrait beaucoup de modules pédagogiques dangereux.


Eric

Date: 2010-06-08 13:06
Sender: Georges Khaznadar

À mon avis, nous pouvons résoudre cela en adooptant une politique claire vis-à-vis des dépendances.

Un module dépend de wims-x.yz; c'est la seule dépendance à préciser.

Wims-x.yz dépend de maxima version ... par version ... yacas version ... etc.

À partir de là, on met à jour le vérificateur de adm/manage qui vérifie l'installation *et le numéro de version* des logiciels annexes.

Donc si quelqu'un publie un module, il sait que ce module fonctionnera dans un environnement de logiciels annexes de versions supérieures ou égales à son environnement primitif. Si ça ne fonctionne pas, la vérification des logiciels annexes permet de déceler une anomalie.

No related tasks

No attached documents

Field Old Value Date By
detailsLe fait qu\'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d\'erreurs. Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n\'étant pas toujours compatibles entre elles. Exemple : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% L\'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes : \\integer{n= randint(8..25)} \\text{cardinal=pari(a=divisors(\\n) ; vector(#a,i,eulerphi(a[i])))} Dans l\'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4). Résultat : si (une copie de) l\'exo est lancé dans createxo, on a un message d\'erreur de pari. Mais s\'il est appelé comme exo d\'un module, l\'erreur n\'est même pas visible, sauf que les calculs qui suivent sont faux. Essayer http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn qui prétend indûment que le nombre d\'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Bien sûr pour cet exercice précis on peut s\'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs. C\'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998. Eric 2010-06-09 13:10
detailsLe fait qu\'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d\'erreurs. Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n\'étant pas toujours compatibles entre elles. Exemple : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% L\'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes : \\integer{n= randint(8..25)} \\text{cardinal=pari(a=divisors(\\n) ; vector(#a,i,eulerphi(a[i])))} Dans l\'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4). Résultat : si (une copie de) l\'exo est lancé dans createxo, on a un message d\'erreur de pari. Mais s\'il est appelé comme exo d\'un module, l\'erreur n\'est même pas visible, sauf que les calculs qui suivent sont faux. Essayer http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn qui prétend indûment que le nombre d\'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Bien sûr pour cet exercice précis on peut s\'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs. C\'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998. Eric 2010-06-09 05:44
detailsLe fait qu\'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d\'erreurs. Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n\'étant pas toujours compatibles entre elles. Exemple : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% L\'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes : \\integer{n= randint(8..25)} \\text{cardinal=pari(a=divisors(\\n) ; vector(#a,i,eulerphi(a[i])))} Dans l\'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4). Résultat : si (une copie de) l\'exo est lancé dans createxo, on a un message d\'erreur de pari. Mais s\'il est appelé comme exo d\'un module, l\'erreur n\'est même pas visible, sauf que les calculs qui suivent sont faux. Essayer http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn qui prétend indûment que le nombre d\'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Bien sûr pour cet exercice précis on peut s\'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs. C\'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998. Eric 2010-06-08 21:57
detailsLe fait qu\'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d\'erreurs. Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n\'étant pas toujours compatibles entre elles. Exemple : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% L\'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes : \\integer{n= randint(8..25)} \\text{cardinal=pari(a=divisors(\\n) ; vector(#a,i,eulerphi(a[i])))} Dans l\'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4). Résultat : si (une copie de) l\'exo est lancé dans createxo, on a un message d\'erreur de pari. Mais s\'il est appelé comme exo d\'un module, l\'erreur n\'est même pas visible, sauf que les calculs qui suivent sont faux. Essayer http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn qui prétend indûment que le nombre d\'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Bien sûr pour cet exercice précis on peut s\'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs. C\'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998. Eric 2010-06-08 16:00
detailsLe fait qu\'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d\'erreurs. Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n\'étant pas toujours compatibles entre elles. Exemple : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% L\'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes : \\integer{n= randint(8..25)} \\text{cardinal=pari(a=divisors(\\n) ; vector(#a,i,eulerphi(a[i])))} Dans l\'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4). Résultat : si (une copie de) l\'exo est lancé dans createxo, on a un message d\'erreur de pari. Mais s\'il est appelé comme exo d\'un module, l\'erreur n\'est même pas visible, sauf que les calculs qui suivent sont faux. Essayer http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn qui prétend indûment que le nombre d\'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Bien sûr pour cet exercice précis on peut s\'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs. C\'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998. Eric 2010-06-08 15:04
detailsLe fait qu\'un module pédagogique ne mentionne pas les versions des logiciels annexes utilisés est une source d\'erreurs. Je le considère donc comme un bug de conception (pas de programmation) de wims, mais je ne sais pas comment on peut le résoudre, les versions n\'étant pas toujours compatibles entre elles. Exemple : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% L\'exo orbitezn du module U3/algebra/oefgop.fr contient les lignes suivantes : \\integer{n= randint(8..25)} \\text{cardinal=pari(a=divisors(\\n) ; vector(#a,i,eulerphi(a[i])))} Dans l\'appel à pari, le dièse semble ne pas être pris en compte dans les anciennes versions de pari (le serveur de Caen est en 2.1.4). Résultat : si (une copie de) l\'exo est lancé dans createxo, on a un message d\'erreur de pari. Mais s\'il est appelé comme exo d\'un module, l\'erreur n\'est même pas visible, sauf que les calculs qui suivent sont faux. Essayer http://wims.unicaen.fr/wims/wims.cgi?module=U3/algebra/oefgop.fr&cmd=new&exo=orbitezn qui prétend indûment que le nombre d\'orbites est 0, alors que le même exo fonctionne correctement sur auto.u-psud. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Bien sûr pour cet exercice précis on peut s\'en tirer en le modifiant pour éviter le dièse, mais le problème doit se poser ailleurs. C\'est sans doute plus marqué encore avec maxima, qui a plus évolué depuis 1998. Eric 2010-06-08 13:06