lionmarron
2011-12-21 21:39:16 UTC
Bonjour
Étant presque sûr de ne pas faire comme il faut, et non moins sûr de ne
pas savoir comment il faudrait faire, je me propose de choisir un
exemple précis pour expliquer non pas comment je fais en général, mais
comment j'ai fait cette fois.
Espérant qu'en retour, au lieu de m'expliquer pourquoi j'ai tord en
général (mais je n'en doute pas), on pourra m'expliquer aussi pourquoi
j'ai eu tord cette fois là (puisque tel est sans doute le cas).
CONTEXTE
Les réponses aux questions qui pourront se poser varient selon les
langages. C'est une chose que j'imagine ou dont je suis sûr (selon les cas).
Toutefois je préférais partir d'un exemple précis, donc le programme est
en Python, même si cela ne m'a pas semblé une raison suffisante pour
mettre le message sur le forum python.
D'une part les questions posées doivent être a priori suffisamment
basiques pour être assez peu spécifique à ce langage. D'autre part il
pourrait arriver que des réponses relatives à d'autres langages soient
plus appropriées.
Le programme choisi comme exemple ne sert pas vraiment à quelque chose,
toutefois ce qu'il fait est non ambigu (on peut savoir assez facilement
si l'objectif est atteint ou non), et cela devrait être a priori
suffisamment compliqué pour qu'on puisse hésiter sur la façon de
procéder, ou pour que le résultat puisse être obtenu par des méthodes
plus ou moins claires.
Ce que fait le programme: dessiner des pièces d'échecs, permettre de les
déplacer, contrôler la légalité des coups. On ne peut pas enregistrer ce
qu'on vient de faire dans un fichier, ni conserver en mémoires des
variantes, mais on peut retourner en arrière ou revenir en avant.
Le script ne présente sans doute pas un grand intérêt et je ne crois pas
qu'il soit nécessaire de le voir pour comprendre la suite du message,
toutefois on peut le trouver ici :
https://sites.google.com/site/andrehetzel/5-programmation/b-python
J'ai cru devoir séparer le script en deux parties, disons A et B, la
seconde appelant la première.
A contrôle la légalité des coups. B dessine les pièces, puis gère leur
déplaceent. Donc la question qui s'est posée, celle qui sera posée ici
tout au moins : comment passer les paramètres ?
Les paramètres gérées par B et utilisés par A sont essentiellement deux
listes de 24 nombres. Elles font partie de deux listes de listes
appelées respectivement posiCNT et posiCT (position de la couleur qui
n'est pas au trait / position de la couleur au trait).
Les paramètres calculés par A et utilisés par B sont essentiellement: --
Une liste appelée depCL (départ coups légaux) ; elle contient 64 nombres
qui peuvent prendre les valeurs 0 ou 1.
-- Une liste appelée arrCL (arrivée coups légaux) ; elle contient 64
listes de 64 nombres qui peuvent prendre les valeurs 0 ou 1.
COMMENT J'AI FAIT ?
Uniquement avec des variables globales.
Dans le premier cas (appel de A), mettre en paramètre les deux listes de
24 nombres n'aurait pas posé de problèmes. Seulement voilà, cela
n'aurait pas non plus changé grand chose : parce que la fonction A
utilise une dizaine de listes de 64 à 123 nombres qui n'ont besoin
d'être initialisées qu'une fois, et dont j'ai fait des variables
globales afin qu'elles ne soient pas réinitialisées à chaque appel de A.
Dans le second cas (retour de A) il y aurait sans doute eu des moyens de
récupérer les paramètres, mais il est déjà moins évident de savoir quels
sont ces moyens. Il est bien possible que le seul que je connaisse
aurait fonctionné (mettre qq chose après return) mais je ne sais pas
s'il aurait été le plus simple. Et là aussi cela semblait ne pas changer
grand chose.
CARACTÉRISTIQUE DU LANGAGE OU DE L'ÉDITEUR
J'ai d'abord essayé de mettre A dans un module séparé mais je n'y suis
pas arrivé, soit parce que je ne sais pas utiliser mon éditeur (ce
serait un autre sujet si j'étais sûr que le problème vienne de là | donc
peut-être pas), soit parce que le principal livre auquel je me suis
référé (Swinnen, O'Reilly 2005) explique seulement comment utiliser des
modules déjà réalisés, ou comment réaliser des modules qui puissent
fonctionner seuls, mais pas comment réaliser un module en le testant
depuis un autre script.
Lorsque le module venait d'être modifié, selon les cas et selon la façon
de procéder, le lancement du script appelant provoquait soit un message
d'erreur, soit l'appel de la version précédente du script, soit encore
un fonctionnement correct (mais en général c'était après avoir fermé
puis réouvert tous les fichiers).
Que cela provienne de l'éditeur ou non, le fonctionnement de Python
semble de toute façon parfois bizarre.
Lorsqu'on lance un script venant d'être modifié (et sauf si on prend la
précaution de fermer puis réouvrir le script), Python continu de faire
comme si des variables ou des fonctions qui ne sont plus déclarées
existaient encore pour lui. Et je ne pense pas que cela vienne de
l'éditeur que j'utilise en ce moment (Emacs) ; j'avais remarqué la même
choses sous IDLE.
LE MEILLEUR DES MONDES
Dans certains cas le fait que les langages de programmation semblent ne
pas proposer ce que je cherche doit s'expliquer par le fait que je ne
sais pas précisément ce qu'ils proposent. Il serait par exemple
surprenant qu'il ne soit pas possible d'initialiser certaines variables
locales seulement lors du premier appel d'une fonction. Ce qu'on appelle
variables statiques permettrait de le faire et la première fois que j'en
ai entendu parler il me semble que c'était à propos de Python. Toutefois
je n'ai pas pu retrouver l'information, et je ne sais pas pourquoi les
ouvrages d'initiation n'en parlent pas alors qu'ils parlent de choses
plus difficile à comprendre.
Dans d'autres cas ce que cherche semble suffisamment différent de ce
dont on entend parler pour que je puisse penser que ça n'existe pas sur
le marcher actuel. Comme par ailleurs mes idées sont relativement
simples ou relativement triviales, je peux raisonnablement penser que ce
qu'on me propose doit être beaucoup mieux.
Autrement dit le meilleur des mondes peut-être ; ce que je peux en dire
est seulement que je n'y vois pas de certitude. Difficile d'être plus
affirmatif si ce qu'on me propose est incompréhensible.
Quant à savoir ce que je cherche, je citerai seulement deux idées et
sans les développer ; d'une part parce que je crois que mon message sera
suffisamment long comme ça ; d'autre part parce que je suppose qu'il
aurait été jugé suffisamment navrant même sans ça.
Première idée : Il devrait y avoir plusieurs niveaux de numéros de
lignes ; c'est-à-dire que, dans le cas de l'écriture d'une fonction, le
rôle joué en Python par l'augmentation de la marge droite devrait être
remplacé par une colonne supplémentaire de numéros de lignes. Cela
obligerait à faire en sorte que les numéros de lignes fasse partie du
script mais ce n'est pas la seule différence. En réalité cela s'inscrit
dans le cadre d'une conception différente de l'éditeur, et, bien que (je
suppose) jusque là un éditeur pourrait être programmé pour le faire, en
réalité ce qu'il s'agit de faire devrait plutôt être réalisé par un
programme qui serve à la fois d'éditeur et d'interpréteur. Je n'explique
pas plus les avantages pour ne pas être trop long mais évidemment il ne
s'agit pas de revenir à GWbasic. Si j'ai choisi cet exemple c'est parce
qu'il est suffisant pour qu'on puisse savoir ou non si un langage
proposant cette possibilité existe actuellement (mais je crois pas).
Deuxième idée : Il devrait exister deux type de scripts. Un type qui
correspond à ce que fait aujourd'hui un script normal ; nous
l'appellerons alpha. Et type qui serve à débugger un script du type
précédent ; nous l'appellerons delta. Alpha et delta fonctionneraient en
même temps, et delta contiendrait des instructions servant à contrôler
ce que fait alpha. Par exemple indiquer quelles sont les valeurs
successives d'une variable dans une zone déterminé du programme, ou à un
moment déterminé de son déroulement. Ce serait bien sûr plus facile à
faire (ou plus adapté) avec un langage interprété qu'avec un langage
compilé, et a priori l'idée ne devrait pas être assez originale pour
qu'elle n'ait pas déjà été utilisée (j'ai lu au moins une fois qq chose
qui irait dans ce sens), mais je ne sais pas si on la trouve implémenté
sur un langage actuel.
FIN DU MESSAGE
Et j'ignore encore si ce sera un troll bien sûr.
Étant presque sûr de ne pas faire comme il faut, et non moins sûr de ne
pas savoir comment il faudrait faire, je me propose de choisir un
exemple précis pour expliquer non pas comment je fais en général, mais
comment j'ai fait cette fois.
Espérant qu'en retour, au lieu de m'expliquer pourquoi j'ai tord en
général (mais je n'en doute pas), on pourra m'expliquer aussi pourquoi
j'ai eu tord cette fois là (puisque tel est sans doute le cas).
CONTEXTE
Les réponses aux questions qui pourront se poser varient selon les
langages. C'est une chose que j'imagine ou dont je suis sûr (selon les cas).
Toutefois je préférais partir d'un exemple précis, donc le programme est
en Python, même si cela ne m'a pas semblé une raison suffisante pour
mettre le message sur le forum python.
D'une part les questions posées doivent être a priori suffisamment
basiques pour être assez peu spécifique à ce langage. D'autre part il
pourrait arriver que des réponses relatives à d'autres langages soient
plus appropriées.
Le programme choisi comme exemple ne sert pas vraiment à quelque chose,
toutefois ce qu'il fait est non ambigu (on peut savoir assez facilement
si l'objectif est atteint ou non), et cela devrait être a priori
suffisamment compliqué pour qu'on puisse hésiter sur la façon de
procéder, ou pour que le résultat puisse être obtenu par des méthodes
plus ou moins claires.
Ce que fait le programme: dessiner des pièces d'échecs, permettre de les
déplacer, contrôler la légalité des coups. On ne peut pas enregistrer ce
qu'on vient de faire dans un fichier, ni conserver en mémoires des
variantes, mais on peut retourner en arrière ou revenir en avant.
Le script ne présente sans doute pas un grand intérêt et je ne crois pas
qu'il soit nécessaire de le voir pour comprendre la suite du message,
toutefois on peut le trouver ici :
https://sites.google.com/site/andrehetzel/5-programmation/b-python
J'ai cru devoir séparer le script en deux parties, disons A et B, la
seconde appelant la première.
A contrôle la légalité des coups. B dessine les pièces, puis gère leur
déplaceent. Donc la question qui s'est posée, celle qui sera posée ici
tout au moins : comment passer les paramètres ?
Les paramètres gérées par B et utilisés par A sont essentiellement deux
listes de 24 nombres. Elles font partie de deux listes de listes
appelées respectivement posiCNT et posiCT (position de la couleur qui
n'est pas au trait / position de la couleur au trait).
Les paramètres calculés par A et utilisés par B sont essentiellement: --
Une liste appelée depCL (départ coups légaux) ; elle contient 64 nombres
qui peuvent prendre les valeurs 0 ou 1.
-- Une liste appelée arrCL (arrivée coups légaux) ; elle contient 64
listes de 64 nombres qui peuvent prendre les valeurs 0 ou 1.
COMMENT J'AI FAIT ?
Uniquement avec des variables globales.
Dans le premier cas (appel de A), mettre en paramètre les deux listes de
24 nombres n'aurait pas posé de problèmes. Seulement voilà, cela
n'aurait pas non plus changé grand chose : parce que la fonction A
utilise une dizaine de listes de 64 à 123 nombres qui n'ont besoin
d'être initialisées qu'une fois, et dont j'ai fait des variables
globales afin qu'elles ne soient pas réinitialisées à chaque appel de A.
Dans le second cas (retour de A) il y aurait sans doute eu des moyens de
récupérer les paramètres, mais il est déjà moins évident de savoir quels
sont ces moyens. Il est bien possible que le seul que je connaisse
aurait fonctionné (mettre qq chose après return) mais je ne sais pas
s'il aurait été le plus simple. Et là aussi cela semblait ne pas changer
grand chose.
CARACTÉRISTIQUE DU LANGAGE OU DE L'ÉDITEUR
J'ai d'abord essayé de mettre A dans un module séparé mais je n'y suis
pas arrivé, soit parce que je ne sais pas utiliser mon éditeur (ce
serait un autre sujet si j'étais sûr que le problème vienne de là | donc
peut-être pas), soit parce que le principal livre auquel je me suis
référé (Swinnen, O'Reilly 2005) explique seulement comment utiliser des
modules déjà réalisés, ou comment réaliser des modules qui puissent
fonctionner seuls, mais pas comment réaliser un module en le testant
depuis un autre script.
Lorsque le module venait d'être modifié, selon les cas et selon la façon
de procéder, le lancement du script appelant provoquait soit un message
d'erreur, soit l'appel de la version précédente du script, soit encore
un fonctionnement correct (mais en général c'était après avoir fermé
puis réouvert tous les fichiers).
Que cela provienne de l'éditeur ou non, le fonctionnement de Python
semble de toute façon parfois bizarre.
Lorsqu'on lance un script venant d'être modifié (et sauf si on prend la
précaution de fermer puis réouvrir le script), Python continu de faire
comme si des variables ou des fonctions qui ne sont plus déclarées
existaient encore pour lui. Et je ne pense pas que cela vienne de
l'éditeur que j'utilise en ce moment (Emacs) ; j'avais remarqué la même
choses sous IDLE.
LE MEILLEUR DES MONDES
Dans certains cas le fait que les langages de programmation semblent ne
pas proposer ce que je cherche doit s'expliquer par le fait que je ne
sais pas précisément ce qu'ils proposent. Il serait par exemple
surprenant qu'il ne soit pas possible d'initialiser certaines variables
locales seulement lors du premier appel d'une fonction. Ce qu'on appelle
variables statiques permettrait de le faire et la première fois que j'en
ai entendu parler il me semble que c'était à propos de Python. Toutefois
je n'ai pas pu retrouver l'information, et je ne sais pas pourquoi les
ouvrages d'initiation n'en parlent pas alors qu'ils parlent de choses
plus difficile à comprendre.
Dans d'autres cas ce que cherche semble suffisamment différent de ce
dont on entend parler pour que je puisse penser que ça n'existe pas sur
le marcher actuel. Comme par ailleurs mes idées sont relativement
simples ou relativement triviales, je peux raisonnablement penser que ce
qu'on me propose doit être beaucoup mieux.
Autrement dit le meilleur des mondes peut-être ; ce que je peux en dire
est seulement que je n'y vois pas de certitude. Difficile d'être plus
affirmatif si ce qu'on me propose est incompréhensible.
Quant à savoir ce que je cherche, je citerai seulement deux idées et
sans les développer ; d'une part parce que je crois que mon message sera
suffisamment long comme ça ; d'autre part parce que je suppose qu'il
aurait été jugé suffisamment navrant même sans ça.
Première idée : Il devrait y avoir plusieurs niveaux de numéros de
lignes ; c'est-à-dire que, dans le cas de l'écriture d'une fonction, le
rôle joué en Python par l'augmentation de la marge droite devrait être
remplacé par une colonne supplémentaire de numéros de lignes. Cela
obligerait à faire en sorte que les numéros de lignes fasse partie du
script mais ce n'est pas la seule différence. En réalité cela s'inscrit
dans le cadre d'une conception différente de l'éditeur, et, bien que (je
suppose) jusque là un éditeur pourrait être programmé pour le faire, en
réalité ce qu'il s'agit de faire devrait plutôt être réalisé par un
programme qui serve à la fois d'éditeur et d'interpréteur. Je n'explique
pas plus les avantages pour ne pas être trop long mais évidemment il ne
s'agit pas de revenir à GWbasic. Si j'ai choisi cet exemple c'est parce
qu'il est suffisant pour qu'on puisse savoir ou non si un langage
proposant cette possibilité existe actuellement (mais je crois pas).
Deuxième idée : Il devrait exister deux type de scripts. Un type qui
correspond à ce que fait aujourd'hui un script normal ; nous
l'appellerons alpha. Et type qui serve à débugger un script du type
précédent ; nous l'appellerons delta. Alpha et delta fonctionneraient en
même temps, et delta contiendrait des instructions servant à contrôler
ce que fait alpha. Par exemple indiquer quelles sont les valeurs
successives d'une variable dans une zone déterminé du programme, ou à un
moment déterminé de son déroulement. Ce serait bien sûr plus facile à
faire (ou plus adapté) avec un langage interprété qu'avec un langage
compilé, et a priori l'idée ne devrait pas être assez originale pour
qu'elle n'ait pas déjà été utilisée (j'ai lu au moins une fois qq chose
qui irait dans ce sens), mais je ne sais pas si on la trouve implémenté
sur un langage actuel.
FIN DU MESSAGE
Et j'ignore encore si ce sera un troll bien sûr.
--
lionmarron
lionmarron