Coucou Abdel, Beau boulot.
Ca avance, certes lentement, mais sûrement. Moi aussi je n'ai pas chômé de mon côté. J'ai avancé sur plusieurs fonctionnalités à la fois et en suis essentiellement à des phases de test et ajustement. Il s'agit de: * la vérification automatique de la syntaxe d'une ligne modifiée juste après une tentative de déplacement à une autre ligne. La vérification de la syntaxe se fait sur plusieurs règles, mais pas toutes. Je suis en train d'étudier l'option de faire prendre en compte les autres règles par l'interpréteur lui-même. Et je n'ai pas encore implémenté la reécriture automatique de certains éléments de la ligne tels que: - le retrait des espaces et tabulation à la fin de la ligne; - l'assurance que la cass des mots clés est bien respecté. * l'ajout et le retrait de balises de fin de block (à la basic) au code corectement indenté. Balises qui sont en réalité des ligne de commentaire (exemple # end if, # end def, etc...). C'est presque fini. J'en suis au tests et ajustements. Devrait être utile aux habitués de codes à balises pour lire des codes très indentés sans trop se prendre la tête. * l'utilisation de la présence de balises de fin de block (à la basic) pour ajuster l'indentation du code python. Ca aussi c'est presque fini. Ainsi lorsque j'en aurait terminé, on pourra taper entièrement son code sans y mettre d'indentation, mais plutôt des balises à la basic. Et à la fin, ajuster l'indentation suivant la présence de ces balises qui je le rappelle ne sont que des commentaires. Et pourquoi pas un mode dans lequel l'indentation s'ajusterait automatiquement suivant la présence de balises de fin de block comme dans le visual basic ? * l'aide et la complétion au mot clé sous le curseur. J'ai commencé par faire simple, et suis en train de prendre en compte les autres cas possibles, et c'est pas évident, car il faut retrouver ou déduire toutes les déclarations liées au mot clé à définir ou compléter. Voilà ! Etant des fonctionnalités assez complexes à implémenter, car touchant à des principes qui ont pas mal d'exception, il convient que je sois méticuleux dans leur programmation. J'ai notamment eu du fil à retordre pour gérer l'éventuelle présence dans le code de chaînes longues ou commentaires longs qui sont délimités par des triples quotes. Ou à la gestion des chaînes string simple. Mais je crois avoir trouvé le bon bout par la création de fonctions qui me simplifient ces taches. Sinon, il sera toujours possible d'optimiser n'est-ce pas ? Et je comptes sur vous ! Maintenant à Abdel quelques préoccupations: Pour ce qui est de la fonction de parsage d'un message d'erreur pour trouver la position de celle-ci et s'y rendre. En fait, ce que j'ai fait dans cette fonction était d'identifier la dernière ligne d'erreur signalée et de m'y rendre. Mais comme je l'ai compris récemment, la dernière erreur signalée peut très bien se trouver dans un fichier pyo de la bibliothèque de python. Par exemple, lorsqu'on n'envoi une chaîne éronnée comme pattern à une regexp du module re, python indique le fichier pyo du module comme contenant la ligne d'erreur. Et c'est vraiment embêtant car la ligne sur laquelle se rendre dans ce cas n'est pas celle de la bibliothèque, mais celle qui vient avant. Pour régler ce problème, deux cas de figures possibles. 1. soit on trouve le moyen de déterminer que l'avant-dernière ligne est celle sur laquelle se rendre; En faisant bien attention de ne pas se louper. 2. soit on affiche les erreurs dans une liste en proposant à l'utilisateur de valider sur l'une d'entre elle afin de se rendre à la ligne qu'elle indique. Ce qui veut dire que la console du 6pad++ ne sera plus employée pour ce cas. J'avoue être indécis car chaque option a ses avantages et ses inconvénients. Qu'est-ce que vous en pensez ? Autre préoccupation. Ayant un peu gros sur la patate à force de fermer et réouvrir à chaque fois les fichiers python pour tester les modifications faites dans les extensions pour le 6pad++, j'ai pensé créer une fonction liée à un raccourci pour raffraîchir ces scripts/extensions. Hé bien, j'arrive bien à recharger les scripts, mais pas à raffraîchir les fonctions liées aux accélérateurs et éléments de menu. Il semble que les anciennes fonctions restent toujours chargées en mémoire et liées à ces objets. J'imagine que c'est probablement le cas pour ce qui est des fonctions liées aux évènements, j'ai pas vérifié. Et je n'ai pas trouvé de moyen d'identifier les accélérateurs et menus qui ne sont pas natifs dans 6pad+ dans l'optique de les éliminer avant de les recréer. Je continue de chercher, mais sèche complètement jusqu'à maintenant. Or, ô combien cette fonctionnalité serait utile. Avoir à raffraîchir les scripts/extensions juste avec un raccourci clavier ! Quelqu'un a une idée ? Ou mieux, quelqu'un aurait-il déja résolu le problème ? Bon je vous laisse ici. Faut que je m'en retourne à mes petites affaires . Yannick Daniel Youalé La programmation est une religion. Aimez-la, ou quittez-la. www.visuweb.net ----- Original Message ----- From: _Abdel_ To: [email protected] Sent: Tuesday, February 23, 2016 11:44 PM Subject: [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Resalut la ML, Je viens d'améliorer le rapport des tracebacks en utilisant les instructions suivantes : lines = traceback.format_exception(etype = sys.exc_info()[0], value = sys.exc_info()[1], tb = sys.exc_info()[2]) print (''.join(line for line in lines)) Les paramètres etype, value et tb de la méthode format_exception du module traceback utilisent respectivement le type de l'erreur pour etype, la valeur du message pour value et le traceback, pour le paramètre tb. Elle se charge ensuite de mettre en forme le message sous la forme d'une liste d'éléments, qui pourra être utilisée dans une boucle. J'ai du recourir à cette méthode uniquement pour traiter les messages d'erreurs générés lors de l'exécution d'un module avec le Python embarqué avec 6pad++, pour offrir plus de facilités pour ceux qui souhaiteraient créer des nouvelles extensions pour 6pad++. Autrement, pour le cas de figure où on utiliserait une version de Python externe, les messages d'erreur sont déjà bien gérés par le module subprocess. Voili voilou, bonne soirée à tous. Bien amicalement, Abdel. ----- Original Message ----- From: _Abdel_ To: [email protected] Sent: Tuesday, February 23, 2016 10:30 PM Subject: [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Resalut la ML ! Alors, c'est la forme? Juste pour vous dire qu'une nouvelle mouture de forPython venait de sortir, apportant les améliorations suivantes : 1. Grâce à la contribution de Yannick, lorsqu'une erreur est détectée dans le module en cours d'exécution, une alerte s'affiche, donnant à l'utilisateur la ligne où se situe l'erreur, et l'invitant à valider sur OK pour l'atteindre directement dans le module concerné. Cette alerte invite également l'utilisateur à consulter la console, ainsi que le fichier logfile.log, pour plus de détails sur l'erreur trouvée. 2. Si le fichier en cours n'est pas sauvegardé lors de son exécution, l'utilisateur sera invité à valider sur OK pour sauvegarder son module dans un fichier tmp.py, figurant dans le même répertoire que l'exécutable de 6pad++. Il devra ensuite relancer son raccourci pour ré exécuter son module. J'ai utilisé le module traceback pour récupérer les messages d'erreur lorsque le Python utilisé est celui de 6pad++, car je n'ai pas pu exécuter ce dernier avec le module subprocess. Cela aurait été beaucoup plus simple car proc.communicate() retourne un tuple comportant le stdout et le stderr. Ce n'est pas bien grave, car cette limitation a bien été contournée en utilisant les fonctions compile et exec du builtin du Python embarqué avec 6pad++. Si vous souhaitez que le message d'erreur soit donné directement lors de l'affichage de l'alerte, ce sera très simple à ajouter. J'ai commenté pas mal de lignes de code, pour une meilleure compréhension des différentes instructions. Je continue cette partie de commentaire, que je juge quand-même importante à ajouter. Cyrille, j'ai bien pris en compte ta préoccupation, je vais d'y réfléchir pour la prochaine version. Merci à toi. Bien amicalement, Abdel. ----- Original Message ----- From: Cyrille To: [email protected] Sent: Sunday, February 21, 2016 4:46 PM Subject: [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Bonjour à tous Merci Abdel et Yannick pour les versions successives du forPython. J'étais en vacance la semaine dernière donc pas d'occasion de tester. Et à présent je fais majoritairement du Matlab au boulot plutôt que du Python. Mais je l'intégrerai à mon 6pad++ et le regarderai à l'occasion. Je peux déjà dire un point que j'avais soulevé : Lecture des indentations Habituellement, j'utilise Jaws avec l'annonce des retraits. Le fait d'avoir défini l'événement onKeyDown/Up ne fait plus lire les lignes par Jaws mais par sixpad.say. Du coup l'annonce des retraits n'est plus faite comme dans Jaws. Ca serait bien d'avoir un mode où l'annonce des indentations ne se fait que lorsque l'indentation de la ligne d'arrivée est différente de celle de départ et pas à chaque changement de ligne. Le reste ça sera pour la semaine prochaine. Bonne journée. Cyrille -------------------------------------------------------------------------- De : [email protected] [mailto:[email protected]] De la part de _Abdel_ Envoyé : mercredi 17 février 2016 21:14 À : [email protected] Objet : [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Coucou Yannick, Début de citation Je l'ai testé sur un de mes ordi (avec Windows 7), et malheureusement, dans le menu, il n'y a que 6pad++ qui apparaît. Mon python27 qui pourtant est directement dans le disque C est ignoré. Tandis que sur un autre avec Windows XP tout apparaît bien (python25 et python27). Quel est ce mystère ? Fin de citation Le mystère vient du fait que la lettre du volume ou du lecteur doit être suivie d'un slash ou d'un anti-slash après le ":". os.path.join(C:", "Python27") retourne C:Python27, ce qui est bien accepté sur un XP, et pas sur les versions supérieures. Ca a été corrigé, tu pourras tester et me dire si ça marche bien chez toi, car ici, j'ai bien testé sur un Windows-8.1 et ça fonctionne très bien. Début de citation Et j'avais une préoccupation quant au choix d'enregistrer les chemins vers les exécutables de python trouvés dans un objet dictionnaire. Les éléments dans le dictionnaire se retrouvent par une clée, qui est sensée être unique. Or dans ton code, la clée est le nom du dossier principal de la version de python. Ce qui risque de poser problème dans les cas où quelqu'un aurait décidé d'avoir plusieurs fois la même version de python sur son ordinateur. Par exemple une version portable et une version installée. Un cas qui est certes rare, mais n'en reste pas moins possible. Fin de citation Tu as raison, cela a été corrigé, le chemin de la version courante de Python a été intégrée dans une variable globale désormais, et ce n'est plus la version du Python qui est considérée, mais le chemin de son exécutable. Début de citation A oui, j'ai vu que tu as inclu un dossier que je n'avais pas compté: le x:/Program Files (x86 Dans mon code, toujours concernant le repérage des pythons installés, tu verras que je te propose une manière plus efficace de parcourir les dossier. il s'agit de faire une itération sur les lettres alphabétiques. Exemple: alphabet="ABCDEFGHIJKL" for e in alphabet: # test d'existence Fin de citation C'est bon, cette éventualité a été ajoutée, on itère sur des volumes allant de C jusqu'à I, ce qui élargit considérablement l'étendu de la recherche. Pour le reste des préoccupations, je suis en train de travailler dessus, je compte intégrer ta méthode de pointage sur la ligne comportant l'erreur lors de l'exécution d'un module. Je trouve également bizarre que la regexp re.match("error", errorMessage, re.I|re.M) retourne None. Mais par contre, je t'invite à tester re.match(".*error", errorMessage, re.S), qui fonctionne très bien. Voilà, Cyrille, si tu pourrais nous donner ton avis dès que tu auras un petit moment, ce serait sympa. En PJ, la toute dernière version du forPython, qui a été testé sur un XP, et Windows-8.1. Mais je pense qu'elle devrait fonctionner aussi bien sur Windows 7. Merci à vous. Bien amicalement, Abdel. ----- Original Message ----- From: _Abdel_ To: [email protected] Sent: Tuesday, February 16, 2016 7:20 PM Subject: [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Salut Yannick, Bravo pour toutes ces idées très constructives. Je viens d'installer ton module "tools.py", voici ce qu'il me donne, après l'ouverture d'un nouveau fichier. Je pense que c'est logique, la fonction CreatePythonTools ne nécessite aucun paramètre, alors que tu l'appelles avec un argument dans la fonction événementielle onPageOpened. Début du message d'erreur Traceback (most recent call last): File "plugins/tools.py", line 235, in onPageOpened CreatePythonTools(newPage) TypeError: CreatePythonTools() takes 0 positional arguments but 1 was given Fin du message d'erreur Sinon, pour tes autres idées, le forPython est à toi, tu peux y ajouter tout ce que tu veux. C'est grâce à toi d'ailleurs que cette nouvelle fonctionnalité de recherche des versions de Python figurant sur le PC a été ajoutée. Pour le PB que tu soulèves avec l'expression régulière, dans ton autre post, je pense qu'il faut ajouter l'option re.MULTILINE dans ton second argument, afin que le multiligne soit bien prise en compte lors du match. Tu peux d'ailleurs cumuler cette option avec l'option re.IGNORECASE, en les séparant par une barre verticale. Voilà, merci à toi. Bien amicalement, Abdel. ----- Original Message ----- From: Yannick Youalé To: [email protected] Sent: Tuesday, February 16, 2016 9:50 AM Subject: [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Coucou Abdel, Débu de citation Pour ma part, j'ai aussi fait avancer un peu le travail, l'extension forPython comporte désormais le nécessaire pour rechercher les versions de Python sur le disque dur, et les afficher dans une liste de sous-menus figurant dans un sous-menu du menu forPython, intitulé "Activer une version de Python installée". Fin de citation Je l'ai testé sur un de mes ordi (avec windows 7), et malheureusement, dans le menu, il n'y a que 6pad++ qui apparaît. Mon python27 qui pourtant est directement dans le disque C est ignoré. Tandis que sur un autre avec windows XP tout apparaît bien (python25 et python27). Quel est ce mystère ? Et j'avais une préoccupation quant au choix d'enregistrer les chemins vers les exécutables de python trouvés dans un objet dictionnaire. Les éléments dans le dictionnaire se retrouvent par une clée, qui est sensée être unique. Or dans ton code, la clée est le nom du dossier principale de la version de python. Ce qui risque de poser problème dans les cas où quelqu'un aurait décidé d'avoir plusieurs fois la même version de python sur son ordinateur. Par exemple une version portable et une version installée. Un cas qui est certes rare, mais n'en reste pas moins possible. A oui, j'ai vu que tu as inclu un dossier que je n'avais pas compté: le x:/Program Files (x86 Dans mon code, toujours concernant le repérage des pythons installés, tu veras que je te propose une manière plus efficace de parcourir les dossier. il s'agit de faire une itération sur les lettres alphabétiques. Exemple: alphabet="ABCDEFGHIJKL" for e in alphabet: # test d'existence Pour ce qui est de l'exécution du module courant, nous avons fait presque parreil. Cependant, une petite subtilité: moi j'ai préféré envoyé les messages d'erreur ou tout ce qui devrait s'afficher en console dans la console de 6pad++. Et pour améliorer encore cela, je prévoit en plus parser les messages d'erreur pour pouvoir repérer le fichier et le numéro de ligne comportant l'erreur, afin de s'y positionner dans l'onglet courant ou dans un nouvel onglet s'il s'avère qu'il ne s'agit pas du document courant. Le fichier logFile est important pour retracer les erreurs, mais ne devrait pas être ouvert dans un nouvel onglet si les erreurs sont sensées apparaître dans la console de 6pad++ à mon humble avis. Début de citation pourquoi ne pas enrichir l'extension pour pouvoir compiler du code et générer un exécutable, du style setup.py py2exe, en supposant bien sûr que Py2exe ou un autre module servant à faire cela sera installé dans notre version de Python? Fin de citation Hé bien mon petit Abdel, figures-toi que j'y pensais déja. Concernant le py2exe, j'ai gardé des notes qui sont sensés m'aider à le faire. Je vous les collerai plus bas. En fait, j'entrevoyais un élément de menu labélisé "Créer un exécutable" qui déclencherait une fonction qui, suivant la présence du py2exe ou du pypi ou même un autre créateur d'exécutable chez la version de python cochée lancerait la génération. Et dans le cas où plusieurs seraient repérés, pourquoi ne pas proposer le choix de l'un d'entre eux dans une liste ? Comme autres améliorations possibles, hormis celles que j'ai déjà cité plus haut, il y a: * la définition du mot clé sous le curseur et l'affichage dans la console de 6pad++ je travaille dessus. Quelques soucis avec les expressions régulières qui sont ma foi assez différentes de celles que j'ai connu dans le vb6. * une véritable intellicence. C'est-à-dire par exemple taper un point, et faire ctrl+j ou ctrl+espace pour que la liste des objets et méthodes de l'objet devant lequel on a mis le point soient proposés dans une liste. Evitera de faire des aller et retour entre l'IDE et la documentation. * la vérification des lignes juste après leur modification et tentative de déplacement à une autre ligne. Il s'agit de vérifier quelques éléments de syntaxe et d'avertir directement en cas d'erreur supposé. Seront vérifiés par exemple: - l'équilibre des accolades, guillemets, appostrophes, parenthèses - la présence des deux points à la fin des lignes qui le nécessitent - la nécessité de ne pas mélanger de type d'indentation au début de la ligne On peut également se servir du même évènement pour s'assurer du respect de la cass pour certains mots clé, variables et nom de fonction. Par exemple les True et False qui doivent avoir la majuscule en premier caractère. Ca peut d'ailleurs se corriger sans que l'utilisateur ne s'en rende compte. * l'insertion automatique de fonctions (constructeur, destructeur, ou autres), de classes (héritées ou non) Cela tout en vérifiant l'emplacement et les niveaux d'indentation. * l'insertion d'imports (modules et classes, etc... * la création dans le menu d'aide d'un item qui ouvrira le fichier chm de la version du python actuellement sélectionnée. * la prise en compte de projets de développement et d'options de sauvegarde. Bon je m'arrête là. Néanmoins c'est déjà assez conséquent comme vous le conviendrez avec moi n'est-ce pas ? Certains sont-ils chaud pour qu'on se partage le boulot ? Maintenant les notes sur comment créer un exécutable en ligne de commande avec le py2exe Début des notes __h2 Créer un programme exécutable avec Py2exe L'extension Py2exe permet de convertir un script Python en un programme exécutable (uniquement pour le système d'exploitation Windows). Ce programme exécutable (fichier avec l'extension .exe) peut ensuite être lancé sur un ordinateur où Python n'est pas installé. __h3 Téléchargement et installation de Py2exe Il faut un ordinateur avec Windows et Python déjà installé (attention : Py2exe ne supporte pas la version 3 de Python). Le programme d'installation de Py2exe est disponible ici : __Link sourceforge.net/projects/py2exe/files/py2exe/0.6.9/ Avec une machine 32 bits et Python version 2.7, vous devez utiliser le fichier suivant : __Link py2exe-0.6.9.win32-py2.7.exe Une fois téléchargé, il suffit d'exécuter ce fichier pour installer Py2exe. __h3 Utilisation de Py2exe A titre d'exemple, voici le script d'un jeu de puissance 4 : __Link jeu_puissance4.py Télécharger et enregistrer ce script dans le répertoire où est installé Python (chez moi, c'est le répertoire C:Python27). Créer le script setup.py : # setup.py from distutils.core import setup import py2exe setup(windows=["jeu_puissance4.py"]) Enregistrer le script setup.py dans le répertoire courant de Python. __h4 Remarques si vous voulez disposer de la console en plus de l'interface graphique (GUI), remplacer setup(windows=["jeu_puissance4.py"]) par setup(console=["jeu_puissance4.py"]) pour traiter plusieurs scripts en même temps, il suffit de compléter la liste :setup(windows=["jeu_puissance4.py","script2.py","script3.py"]) Ouvrir l'interpréteur de commande de Windows (Démarrer Exécuter cmd) Placez-vous dans le répertoire courant de Python (commande cd : change directory) : > cd C:Python27 puis lancer Py2exe : > python setup.py py2exe Un sous répertoire nommé dist est créé (chez moi C:Python27dist). Il contient le fichier exécutable jeu_puissance4.exe ainsi que toutes les ressources nécessaires à un fonctionnement autonome (python27.dll library.zip...). Vous pouvez maintenant copier le répertoire complet dist et le distribuer vers des ordinateurs qui ne possèdent pas Python. Le programme se lancera en exécutant le fichier jeu_puissance4.exe. Fin des notes Amicalement, Yannick Daniel Youalé La programmation est une religion. Aimez-la, ou quittez-la. www.visuweb.net ----- Original Message ----- From: _Abdel_ To: [email protected] Sent: Monday, February 15, 2016 7:03 PM Subject: [progliste] Re: 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Salut Yannick et la ML ! Alors, c'est la forme? Tout d'abord, je tenais à te féliciter Yannick pour ce super travail, tu as bien fait avancer le schmilblick lol ! Pour ma part, j'ai aussi fait avancer un peu le travail, l'extension forPython comporte désormais le nécessaire pour rechercher les versions de Python sur le disque dur, et les afficher dans une liste de sous-menus figurant dans un sous-menu du menu forPython, intitulé "Activer une version de Python installée". Le sous-menu forPython comporte aussi une commande exécuter, activable grâce au raccourci clavier CTRL + F5, qui exécutera, selon la version de Python choisie dans le menu, la version de Python qui sera cochée et l'associera au module en cours d'implémentation. Si on veut utiliser le Python embarqué avec 6pad++, il faudra cocher le premier élément du sous-menu "Activer une version de Python installée", qui est coché par défaut. Il conviendra alors de sélectionner dans le module en cours d'exploration, la partie du code que l'on souhaite voir s'exécuter, avant de lancer le raccourci CTRL + F5, la sortie sera dirigée vers la console. Si on coche une version installée sur le PC, la sélection du code à exécuter ne sera pas indispensable, ce sera tout le module en cours d'exploration ou d'implémentation qui sera exécuté, et la sortie redirigée vers un fichier logFile.log, qui sera ouvert automatiquement. Les autres améliorations sont les suivantes : Les regexps servant à atteindre les classes et fonctions ont été réunies dans un dictionnaire, qui pourra être enrichi par d'autres regexps, au cas où vous souhaiteriez exploiter d'autres langages de programmation, différents du Python. La fonction événementielle onKeyUp a été mise à jour comme cité dans mon précédent post. PS: Pour l'exécution d'un code Python avec le Python embarqué dans 6pad++, 2 pistes sont envisageables, elles sont très simples et ont bien été décrite par notre ami Cyrille, que je salue au passage : Première méthode : # Instruction servant à créer un objet qui pourra être exécuter avec exec. code=compile(sp.window.curPage.selectedText, sp.window.curPage.file, "exec") # Exécution de l'objet. exec(code) Seconde méthode, qui est encore plus simple et qui fonctionne tout aussi bien, elle consiste tout simplement à exécuter directement les lignes de code avec la fonction exec : exec(sp.window.curPage.selectedText) La sortie sera alors redirigée vers la console Python de 6pad++. Les fonctions compile et exec sont des fonctions appartenant au builtin de Python. Les perspectives à venir pour le forPython sont les suivantes : Puisque le module subprocess et ses méthodes Popen et call accepte des arguments dans le premier paramètre servant à définir la séquence de commandes à exécuter, pourquoi ne pas enrichir l'extension pour pouvoir compiler du code et générer un exécutable, du style setup.py py2exe, en supposant bien sûr que Py2exe ou un autre module servant à faire cela sera installé dans notre version de Python? Ce serait super lol ! N'hésitez surtout pas à nous dire ce que vous pensez du travail réalisé, est-ce qu'il y a quelque chose à retoucher, etc. Voilà, merci à vous. Bien amicalement, Abdel. ----- Original Message ----- From: Yannick Youalé To: [email protected] Sent: Monday, February 15, 2016 4:33 PM Subject: [progliste] 6pad++- amélioration au forPython- exécution de fichier et prise en compte de multiples versions de python Salut à tous, Je voudrais vous soumettre aujourd'hui le fruit d'une partie de mon travail de ces dernières semaines. Je l'ai regroupé dans un module temporaire nommé tools, et les prédestine a être intégrés au module forPython. Il s'agit principalement des fonctionnalités suivantes: * le listage comme éléments de sous-menu des versions de pythons repérés sur l'ordinateur courant; Ce qui donne la possibilité de cocher la version pour laquelle on décide de développer dans le 6pad++. Le choix est sauvegardé dans le fichier de configuration. * La création d'un menu "Exécuter CTRL+F5" qui lance l'exécution/la précompilation du module courant par la version du python qui a été préalablement sélectionnée dans les menus. * La création d'un menu "arrêter l'exécution" qui est sensé arrêter de force une exécution qui aurait été lancée par le menu précédent. La version du python choisie est conservée dans une variable globale curPythonPath qui est le chemin vers l'exécutable de ce python. Une liste globale nommée pythonList contient les références des autres pythons qui ont été détectés, et sont ordonnés selon leur position comme éléments du sous-menu "versions de python". Le 6pad++ est considéré comme un exécutable python puisqu'on peut faire des script pour lui. il apparaît d'ailleurs comme premier élément du sous-menu "Versions de python". Mais je dois avouer que je n'ai pas pu jusqu'ici trouver la bonne formulation de ligne de commande pour qu'il renvoi erreur ou succès à l'exécution par ctrl+f5. Peut-être allez-vous m'aider à faire la correction. En m'aidant de l'extension perso.py, de Cyrille, j'ai créé la fonction runCurPythonScript() qui est un exemple de communication par ligne de commande et output entre deux versions de pythons totalement différentes. J'espère que ça vous plaira. Alors, mon petit Abdel, qu'est-ce que tu en dis ? Quoi ? Ne me dis pas que j'arrives en retard et que tu as déja fait tout ça !!! MDR ! A plus ! Yannick Daniel Youalé La programmation est une religion. Aimez-la, ou quittez-la. www.visuweb.net Cet e-mail a été envoyé depuis un ordinateur protégé par Avast. www.avast.com
