Toutes mes réponses sur les forums
-
Messages
-
Bonjour Julien,
une idée (que je n’ai pas le courage de tester complètement) pourrait être de faire dépendre les données aléatoires de ton exemple d’un germe que tu contrôles. Par exemple dans DocAide/Document/insertiondeformulaire on explique comment recharger une page avec des germes (en l’occurence les entiers m et n) contrôlés par l’utilisateur. Le formulaire pourrait aussi être caché (sauf le bouton d’envoi) mais prérempli automatiquement avec le germe actuel et dont le bouton va chercher la page avec solution correspondant à ce germe.
Peut-être que cette idée pourra être simplifiée quand l’utilisation de germes d’aléa sera implémentée dans wims.Eric
Ah zut, j’ai fait la même inversion que celle de la doc !
Les paramètres 1 et 2 (x et y) DEPENDENT de l’option. S’il n’y a pas d’option, ce sont les coordonnées mathématiques du point dont on cherche la place en pixels dans l’image. S’il y a l’option pixels, x et y sont des nombres de pixels par rapport au coin origine de l’image et la valeur renvoyée est les coordonnées dans le repère.
Il fallait lire : S’il y a l’option pixels, ce sont les coordonnées mathématiques du point dont on cherche la place en pixels dans l’image. S’il n’y a pas d’option, x et y sont des nombres de pixels par rapport au coin origine de l’image et la valeur renvoyée est les coordonnées dans le repère.
Eric
Bonjour,
Oui, le problème est dans la documentation de la slib. Les formules utilisées sont les suivantes si les paramètres sont x,y,sizex,sizey,x1,x2,y1,y2,b,option :
s’il n’y a pas d’option pixel, on renvoie
(x2-x1)/(sizex) * (x+b) + x1 , -(y2-y1)/sizey * (y+b) + y2s’il y a une option pixel, on renvoie
round(sizex*(x-x1)/(x2-x1)-b) , round(sizey*(-y+y2)/(y2-y1) - b)Donc effectivement, comme tu le dis dans ton N.B.1, l’option pixel convertit des coordonnées du repère mathématique vers les pixels de l’image et non l’inverse.
A noter la petite différence (signe et x1<-->y2) entre le traitement des abscisses et celui des ordonnées, dû au fait que pour l’image les ordonnées vont de haut en bas : l’origine de l’image est en HAUT à gauche.
Les paramètres 3 et 4 (sizex et sizey) sont en pixels.
Les paramètres 5,6,7,8,9 (x1,x2,y1,y2,b) sont dans les coordonnées mathématiques du repère. Le paramètre b est juste un décalage (changement d’origine) de même amplitude en x et en y.Les paramètres 1 et 2 (x et y) DEPENDENT de l’option. S’il n’y a pas d’option, ce sont les coordonnées mathématiques du point dont on cherche la place en pixels dans l’image. S’il y a l’option pixels, x et y sont des nombres de pixels par rapport au coin origine de l’image et la valeur renvoyée est les coordonnées dans le repère.
Je ne réponds pas aux autres questions faute de temps pour l’instant, désolé.
Eric
Bonjour,
Mon validateur n’est pas reconnu.
J’ai installé WebService-Validator-HTML-W3C, j’ai un répertoire
/usr/share/perl5/vendor_perl/WebService/Validator/HTML
qui contient un fichier W3C.pm et un répertoire W3C contenant lui-même Error.pm et Warning.pm.Dans la maintenance du serveur, j’ai ajouté le chemin /usr/share/perl5/vendor_perl et j’ai mis http://validator.w3.org/check comme adresse de validateur.
Et pourtant, si je demande de vérifier les logiciels périphériques, il mentionne dans les programmes non reconnus
WebService::Validator::HTML::W3CEt si j’essaie d’utiliser dans modtool le validateur, il répond :
Demander au gestionnaire du site de vérifier l'installation.Quelqu’un a-t-il des idées ? Le chemin d’accès est-il correct ? Le nom
WebService::Validator::HTML::W3C(avec les ::) doit-il être utilisé dans le chemin d’accès ? Je ne sais pas ce que veulent dire ces :: .Si quelqu’un a une configuration qui fonctionne, je suis preneur des paramètres donnés (chemin…)
Merci
Eric
Il semble que ça marche pour tous les modules (même oef) si on remplace aussi dans filedesc le slash (peut-être tous les caractères spéciaux, je n’ai pas testé ni regardé le code) par le trait de soulignement. Par exemple :
src_monexo_oef=description de mon exo
si le fichier estsrc/monexo.oefEric
Le fait de mettre ce code dans filedesc me donne bien un commentaire dans la table qui décrit la liste des fichiers sur ma machine personnelle (sous Fedora, avec la dernière version svn de wims), MAIS PAS si je mets le même module dans mon compte modtool du serveur de Caen (wims 4.06). Il y a donc un bug technique à régler (peut-être juste faire la mise à jour), c’est un pb des développeurs, pas la faute de l’utilisateur malheureusement victime de ce dysfonctionnement !
Les tests sur d’autres serveurs sont difficiles à faire du fait qu’il faut un compte modtool.Eric
Sur ma machine perso, la carte apparaît bien quand je change la ligne de code qui définit L.tileLayer, en remplaçant le truc avec un numéro compliqué par
L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png', { attribution: '© <a href="http://osm.org/copyright">OpenStreetMap</a> contributors' }).addTo(map);Il n’y a pas de numéro, donc (?) peut-être pas de limite de gratuité ?
Eric
Il semble que ça marche pour tous les modules (même oef) si on remplace aussi dans filedesc le slash (peut-être tous les caractères spéciaux, je n’ai pas testé ni regardé le code) par le trait de soulignement. Par exemple :
src_monexo_oef=description de mon exo
si le fichier estsrc/monexo.oefEric
Thank you Joke,
but I think this fix for\calin mathml doesn’t solve completely the problem.
Unless we want to abandon totally the image mode, the same formula written should give the same result in both mathml and image mode, provided they respect some (maybe restricted, ideally not) wims syntax.I don’t know what mathml syntax is, but latex syntax is the following :
\calis a font change, hence valid for all characters after it inside its group.
\mathcalis a function applied to one argument, which can be one character or a group of characters embraced inside brackets.This is not what directexec gives on Leiden server for mathml :
\cal Agives correctly a calligraphic A in both modes
\cal ABgives a calligraphic AB in image, but in mathml the B is back to roman
\cal {AB}gives a calligraphic AB in image, but not understood in mathml
\mathcal Agives strange result in directexec (the letter A appears 3 times, possibly a bug of directexec). Probably the image mode is correct, not mathml.
\mathcal ABgives a calligraphic A and roman B in image mode, and only roman for mathml (+ same « bug » as above).The other point cannot be tested (at least I don’t know) inside directexec : it is the fact that some « error » in mathml seems to affect later formulas. If you try
\statement{matrice \([1,0;3,-4]), base \(\mathcal B) , matrice \([1,0;3,-4])}
in createxo under mathml mode, the second matrix is presented as an image, while the first is written in mathml, probably because the\(\mathcal B)makes mathml sick.So in my opinion we should first decide which syntax is allowed for calligraphic letters in wims (cal and/or mathcal, brackets or not, acts as font or funtion, …) and then try to make the parser render the formula in both modes as described by the proposed syntax. Since I am used to latex, I would of course prefer taking latex syntax as reference and try to adapt the wims parser for mathml, but you may have good reasons to object to this choice.
Once the choice is done and the technical difficulties overcome, some pedagogical modules may have to be changed (I encountered the problem in the exercise module=U2/geometry/oefgeomeucl.fr&+exo=rotationanti&+cmd=new, which is now ok on your Leiden server).
Eric
On crée, s’il n’existe pas déjà, un fichier nommé
filedescdans le module, et on y met la description des fichiers, avec une égalité par fichier. Exemple :var_proc=fichier principal de calcul filedesc=description des fichiers du moduleA gauche du signe = on met le nom du fichier, dans lequel le caractère « . » est remplacé par « _ » et à droite la description.
Eric
Bonjour,
J’ai un problème avec les modes image/mathml :Si je suis en mode image, le texte suivant fonctionne :
\text{S=pari([Mat([1,0,0;0,3,-4;0,4,3])])} \statement{La base \(\cal B) donne la matrice \(\S)}En mode mathml, la matrice est plus jolie mais l’instruction
\caln’est pas comprise et l’expressioncal Best alors affichée.Si je remplace
\calpar\mathcal, à nouveau le mode image fonctionne (mais avec un caractère B très petit), et en mode mathml on obtient un résultat identique au mode image : le\mathcala été interprété correctement mais transformé en image (peut-être qu’il n’a pas d’équivalent en mathml), et la matrice est écrite aussi en mode image : pourquoi ? Le fait qu’une formule ne puisse pas être écrite en mathml entraîne-t-il le mode image pour toutes les formules de la page ?Autre question liée : doit-on considérer comme erreur de programmation d’écrire
\calplutôt que\mathcaldans les exercices (donc faire corriger les modules publiés ainsi), ou bien wims doit-il s’adapter pour comprendre\calen mode mathml ?Eric
C’est le piège ! Les commandes solve existant à la fois dans wims, maxima, pari, il faut taper solve\( ) pour avoir vraiment le résultat de maxima
….
Où le mettre dans une doc ??
BernadetteIl faudrait le mettre aux endroits où il est dit qu’on peut appeler des logiciels externes (je n’ai pas le temps de vérifier tout de suite où ils sont) et peut-être aussi là où il est question des commandes qui posent ce problème, au moins les plus courantes comme « solve » et « random ». En disant que si une commande a un sens au niveau de wims et du logiciel externe, c’est wims qui prévaut ; et en renvoyant à un endroit unique qui suggérerait quelques astuces comme celle que tu suggères pour contourner le problème. Une difficulté est que j’imagine que les gens qui emploient maxima ou pari depuis wims vont rarement lire à ce moment la doc, mais plutôt imitent un texte source qui fonctionne.
Il faudra peut-être aussi penser à signaler systématiquement cette difficulté lors des séances de formation de toutes sortes.Eric
bernadette a écrit :
2- je ne suis pas arrivé à reproduire le second bogue : qui donne un message de non compréhension (qu'il y ait de nouveau deux signes = est de nouveau un bogue d'affichage du même type que le précédent.
J'essaye encore. Mais si je n'arrive pas à le reproduire, je ne peux pas corriger.
Bernadette
Ca semble très perfide : apparemment ce message de non compréhension n'arrive qu'une seule fois sur un serveur donné (et à condition qu'il soit au moins en 4.04), ce qui limite beaucoup le nombre d'essais possibles (sauf à réinstaller un wims >=4.04 à chaque fois). C'est un peu comme les images TeX qui ne marchaient pas la première fois (temps trop long ?) dans certaines situations puis fonctionaient le coup suivant. Je ne sais pas si le problème est résolu définitivement sur un serveur quand il est arrivé une fois, ou si le fichier manque à nouveau (si c'est ça le problème) après un certain temps (extinction de la session, ou ménage quotidien…). D'après le message de Paul, l'erreur est pourtant arrivée plusieurs fois (sur le même serveur ?)
Eric
