(re) bonjour!
J'ai besoin également dans Qcas de protéger certaines variables contre l'écriture.
C'est à dire que je souhaite que l'utilisateur ne puisse y accéder qu'en lecture seule.
Est-ce déjà inclus dans giac? Sinon, est-ce possible?
Comme vous avez pu le voir, dans QCas, il y plusieurs onglets. Je souhaite que l'utilisateur puisse rappeler, dans l'onglet "calcul formel", les objets géométriques définis depuis la géo 2D pour en analyser éventuellement ceratins aspects. En revanche, je souhaite interdir qu'il écrase un objet géométrique déjà existant depuis l'onglet" calcul formel".
D'où ma requête....
variable en lecture seule
Modérateur : xcasadmin
Re: variable en lecture seule
non, il n'y a pas de protection prévue, et ça ne me parait pas évident du tout d'en ajouter. Par contre, il doit être possible d'éviter les affectations accidentelles depuis l'onglet calcul formel, en testant si on va évaluer un gen de type symbolique et de sommet at_sto dont le 2ème argument est le nom d'un objet géométrique défini. Mais aura-t-on la possibilité de définir ou modifier un objet géométrique en ligne de commande?
Re: variable en lecture seule
Je voulais éviter effectivement de devoir parser la commande utilisateur à la recherche d'un sto...
Je pensais qu'il était facile de rajouter un champs booléen readOnly au type gen et de vérifier au moment de l'affectation si readOnly est vrai.
Mais, je ne connais pas encore suffisamment Giac. Visiblement, ce n'est pas si simple!
Concernant l'onglet de géo 2D, oui, je vais autoriser, à terme, l'utilisateur à saisir une commande mais ... je souhaite l'en dissuader car c'est un gros travail de maîtriser ce qu'il va taper
Je pensais qu'il était facile de rajouter un champs booléen readOnly au type gen et de vérifier au moment de l'affectation si readOnly est vrai.
Mais, je ne connais pas encore suffisamment Giac. Visiblement, ce n'est pas si simple!
Concernant l'onglet de géo 2D, oui, je vais autoriser, à terme, l'utilisateur à saisir une commande mais ... je souhaite l'en dissuader car c'est un gros travail de maîtriser ce qu'il va taper
Re: variable en lecture seule
Effectivement, ce serait facile d'ajouter un champ booléen au type gen, mais cela aurait des conséquences importantes pour la place utilisée et donc sur les performances. Actuellement un gen occupe 8 octets (64 bits), et je dois déjà un peu rogner sur le type double pour l'encapsuler (en limitant la mantisse à 45 bits au lieu de 53, les 8 bits manquants servant à coder le type). Je n'ai aucune place évidente parmi les 64 pour ajouter ne serait-ce qu'un bit.
Et même si la place existait, je ne crois pas que ça marcherait, parce que le gen parsé n'est jamais le même (même s'il peut parfois pointer sur le même identificateur), c'est sur le map qui fait la correspondance entre identificateur et valeur qu'il faudrait agir, ou peut-etre avoir une table d'interdiction d'affectation. Mais ce n'est pas évident à gérer parce que quand on bougera un point sur la figure, il faudra bien changer les affectations...
Tout ça explique ma suggestion de travailler sur l'objet parsé avant de l'évaluer. Et il n'est pas nécessaire à mon avis d'essayer de forcer une interdiction très exhaustive (de toutes façons ça serait coton à écrire), il suffit d'empêcher l'utilisateur de faire une fausse manoeuvre, en ce sens tester simplement une affectation au sommet du gen parsé doit suffire.
Et même si la place existait, je ne crois pas que ça marcherait, parce que le gen parsé n'est jamais le même (même s'il peut parfois pointer sur le même identificateur), c'est sur le map qui fait la correspondance entre identificateur et valeur qu'il faudrait agir, ou peut-etre avoir une table d'interdiction d'affectation. Mais ce n'est pas évident à gérer parce que quand on bougera un point sur la figure, il faudra bien changer les affectations...
Tout ça explique ma suggestion de travailler sur l'objet parsé avant de l'évaluer. Et il n'est pas nécessaire à mon avis d'essayer de forcer une interdiction très exhaustive (de toutes façons ça serait coton à écrire), il suffit d'empêcher l'utilisateur de faire une fausse manoeuvre, en ce sens tester simplement une affectation au sommet du gen parsé doit suffire.
Re: variable en lecture seule
Oui bien sûr, j'y ai réfléchi après. C'est pas sur le gen qu'il faut agir mais sur la map entre identifiant et valeur
En gros, c'est sur le type IDNT qu'il faudrait faire porter cet attribut de lecture seule...
D'ailleurs cela n'a peut-être rien à voir, mais je suppose que "pi" est protégé , non?
Au final, effectivement, s'il n'y a pas la place pour l'intégrer, je me contenterai effectivement d'un parcours du gen entré afin de détecter les sto, ça devrait pas être trop couteux.
En gros, c'est sur le type IDNT qu'il faudrait faire porter cet attribut de lecture seule...
D'ailleurs cela n'a peut-être rien à voir, mais je suppose que "pi" est protégé , non?
Au final, effectivement, s'il n'y a pas la place pour l'intégrer, je me contenterai effectivement d'un parcours du gen entré afin de détecter les sto, ça devrait pas être trop couteux.
Re: variable en lecture seule
Oui, c'est bien sur le map qu'il faudrait agir lorsque le pointeur de contexte est non nul (et sur le type IDNT lorsqu'il est nul).
Et en effet pi (et infini) sont protégés, c'est codé en dur dans la fonction sto dans usual.cc (comparaison des chaines de caractères des noms de variables).
Et en effet pi (et infini) sont protégés, c'est codé en dur dans la fonction sto dans usual.cc (comparaison des chaines de caractères des noms de variables).
Re: variable en lecture seule
j'oubliais, un truc qui peut vous être utile pour détecter les sto, c'est l'instruction lop, qui renvoie la liste des "variables" ayant comme sommet un opérateur donné, ainsi
vecteur v=lop(g,at_sto);
renvoie dans v la liste des sto() de l'expression (ou du vecteur g), il reste ensuite à parcourir v...
vecteur v=lop(g,at_sto);
renvoie dans v la liste des sto() de l'expression (ou du vecteur g), il reste ensuite à parcourir v...