[Officiel] Python sur MOS
-
Derniere version de Python sous forme d’un paquet MorphUP:
Introduction
Comme je vous l’ai annoncé sur le thread « Blender et Python sur MOS » je split mes 2 dev car l’un et l’autre sont asser important pour avoir leur propre thread.
Ici c’est donc Python uniquement, pour l’autre je demande aux modos de me le fermer, il aura bien vécu (plus de 2600 visites merci
).Et Blender c’est ici le thread.
Rappel:
20/01/2005:
– Python 2.4: V0.4.beta2 dispo sur le Wiki Peg. (binaire inclus)
Historique:
21/01/2005:
– ouverture du thread
02/02/2005:
– ça chauffe.. ça chauuuuuffe
07/02/2005:
– Ah y est !!!!! J’ai le grand plaisir de vous annoncer que ce w.e. j’ai obtenue la première version de Python en .library sur un compatible-Amiga.. est c’est sur Morphos
Donc ça n’a pas était sans un grand mal, j’aurai bossé au moins dans les 80h pour passer de la version statique en dynamique.
Un grand merci à Henes qui m’a expliqué comment marche les bibliothèques en mode « baserelative » et qui est toujours à l’écoute de mes petits pb avec le SDK
(PS: j’ai trouvé des bugs dans la nouvelle mouture de cvinclude.pl, je t’envois bientôt ma correction).Je ne remercie pas Henes pour m’avoir fait voir que j’allais passer mon w.e. à recoder la plus part des fonctions de la stdio et de la stdlib
.Donc Python-Phase 2 = fini… (bien qu’il faut encore que je corrige qq bugs, mais l’appli ne hit pas en tout cas!)
Phase-3 => les modules en bibliothèques aussi, porter le code .py de distutils et faire une release officielle.
Rappel: Phase-4 => finir le port des principaux modules, ça sera normalement la dernière phase avant de passer au port de SCon pour pouvoir compiler Blender (et donc passer à ce dernier).
07/02/2005:
– SCons porté. Mais en attente d’être testé avec Python. Officiellement déclaré auprès des auteurs de SCons.
02/03/2005:
– Phase 3 bientôt finie. Hier j’ai enfin pu lancé un script python (setup.py utilisant distutil) permettant de générer automatiquement un module python.
[edit]Auto-modération: Le texte qu’il y avait ici, n’était plus à jour.[/edit]
17/03/2005:
– Arrêt du développement pour 3 mois. Reprise au mois de Juillet. (non, c’est pas pour des vacances
)27/04/2005:
– j’ai quand même un tout petit peu travaillé sur Python et très bonne nouvelle: un gros bug est résolus je vais enfin pouvoir livrer qq chose.
02/05/2005:
– Première version de la python.library fonctionnelle, vous pouvez la télécharger sur cette page du Wiki Peg.
08/09/2005:
– Nouvelle archive python corrigant un bug pour le lancer depuis Ambient, ainsi qu’un gros pb dans le SDK qui le rendait inutilisable. La référence est 20050908
11/09/2005:
– Nouvelle archive python corrigant une demi-tonnes de pb avec les appli utilisant le SDK (genre blender…). Un vrai bordel ce SDL… Enfin aller chercher tout ça sur mon site comme d’hab
05/03/2006:
– Version 2.4.2 sortie
Aucuns changements majeurs côté MorphOS en faite… juste une synchronisation sur le developpement principal.
Toujours sur mon site
10/03/2006:
– Officialisation du port: Pages officielle des port de Python
29/03/2006:
– Passage de Python sous forme d’un paquet MorphUP: Index pour MorphUP
– Nouvelle version retro-compatible avec la 2.4 pour la bibliotheque python.libray.
05/10/2006:
– Support des modules dynamiques!!
C’est avec une joie non cachee que je vous annonce que le systeme de chargement de module dynamique commence enfin a fonctionner!
Avec les infos de CISC, la libdl de BigFoot et un bonne refonte du code actuelle de la part de votre serviteur, le reve est realite.
Je vous laisse donc profiter d’un premier jet (pollue par plein de debug sur le port serie et dans la console python
) pour authentifier mes dires.[d]L’archive est la[/d]. Jetez-vous dessus.
PS: attention cette version risque de ne plus faire fonctionner Blender (j’ai pas teste, a vos risques et perils!!!! :-p)
Pensez a sauver l’ancienne.
10/10/2006:
– Version officielle de la python.library generation 6 avec support des modules dynamiques.
L’archive est la. Note: meme chose que le 5, il faut que je refasse des binaires Blender car ils ne fonctionnes plus avec cette version.
16/10/2006:
– Encore une autre, mais celle-ci c’est important, vu qu’elle fait fonctionner Blender. Au passage divers fixes comme sur arexxmodule.
07/11/2006:
– Super update avec une bonne gestion des modules dynamiques. Maintenant les CTDT sont geres et si erreur il y a durant leur execution, seul le module n’est pas charge (au lieu d’un exit() complet de l’application). Cela permet en plus de compiler des modules fait pour d’autres platformes, sans ce compilquer a changer le code existant pour ouvrir des bibliotheques comme TinyGL ou PowerSDL.
– Avec cette update je vous propose quelques modules que j’ai compile pour vous:
Numeric: gestion evoluee de tableaux multidimenssionnels et d’operations mathematiques dessus. Remplace par NumPy maintenant, mais je ne l’ai pas compiler
. Demande par PyGame et PUG ;PIL:
Python Imaging Library, manipulations basiques d’image (chargement, sauvegarde, correction chromatographique, dessin, …) ;
PyGame: Le fameux module permettant d’acceder a la lib SDL en Python et faire rapidement des jeux sympathiques.
PGU: Ce module permet de cree des interfaces graphiques (GUI) avec PyGame. Il y a aussi de bon exemples de jeux sur la homepage de PGU.
Tous sont telechargeable dans ce repertoire.
Pour l’installation des modules:
– copier ‘include’ et ‘lib’ dans usr: si ils existent.
– copier tout le reste dans SYS: (Base dir ou ce trouve python normalement, C:, LIBS:, …).
Bonjour à tous, c’est pour pleurer.
Y en a marre des appli nunux qui font chier avec leurs variables globales de partout qui font chier quand on veut faire un lib partagé e sur ‘miga like !
Tous ça pour dire que c’est pas gagné pour avoir Python en .library….
un exemple de ce que je veux dire ? regardez le fichier Objects/object.c par exemple dans l’archive de python. Au tout début il y a un « int Py_DivisionWarningFlag; ».
=> variable globale, si vous utilisez directos ce fichier dans un .library, chaque tâche l’utilisant accéderont à la même zone mémoire en attaquant ce symbole => risque de conflit garantis!
Or sous nunux les variables globales sont en faite des variables locales à un processus, soit privées au processus. 2 processus utilisant la lib ne voit donc pas la même zone de mémoire => pas de conflits (sauf entre thread par contre, qui sont des enfants du processus).
Mais le pire.. c’est que c’est aussi valable pour les variable déclarées ‘static’ ! et là y en a un paquet dans le code.
Et ça c’est juste pour 1 fichier… il faut faire un passe sur tout le code de python et modifié tous les accès à des variables globales (‘static’ ou non).
En résumé et pour se la péter à table: le ‘core’ de python n’est pas ‘Thread-safe’…
PS: merci Henes pour les qq explications hier soir à un mec fatigué
@ACE: merci
entre courage et folie mon coeur balance
—
Mon petit si tu manges pas ta soupe tu finiras développeur plus tard!
Bon j’ai qq chose d’important à dire:
Du faite de mon travail important sur Python, qui me coute pas mal sur ma vie physique/morale/privée/publique/etc… je tiens donc en garder les rennes qq temps. De ce fait seule la version dite ‘statique’ de python sera livrée avec les sources (dernière en date = 0.4.beta2).
La nouvelle version qui sera (si je la termine
) la première à supporter le chargement dynamique des modules et à être elle même sous forme d’une .library n’aura pas son code ouvert.Python en v2.4 est effectivement « GPL-compatible », ce qui implique (lisez le fichier LICENSE) que je peux utiliser le code de Python, le modifier mais pas forcement livrer les sources.
Petit passage du README aussi:
(…)
This Python distribution contains no GNU General Public Licensed
(GPLed) code so it may be used in proprietary projects just like prior
Python distributions. There are interfaces to some GNU code but these
are entirely optional.
(…)
Donc voilà. c’est dit
PS: ne vous inquiétez, si les extra-terrestres doivent m’enlever, le code sera livré à qq1 d’autre (enfin si lui non plus s’est pas fait enlever en même temps que moi…)
Or sous nunux les variables globales sont en faite des variables locales à un processus, soit privées au processus. 2 processus utilisant la lib ne voit donc pas la même zone de mémoire => pas de conflits (sauf entre thread par contre, qui sont des enfants du processus).
Il existe un type de library qui permet ce genre de choses, ce sont les classes Boopsi. M’enfin je pense pas que ce soit très indiqué dans le cas qui t’interesse.
Sinon je dis pitet des couneries, j’ai pas cherché plus loin, mais tu pourrais faire un objet de contexte. Genre une struct PythonContext dont une appli supportant ta lib demanderait l’initialisation juste après l’ouverture de la lib et la libèrerait juste avant la fermeture. Ce qui est chiant c’est que du coup tu risques de devoir la passer en paramètre à chaque appel de fonction.
bientôt ici une très bonne nouvelle pour Python sur morphos
notre OS favoris aura une belle exclusivité face à tous les autres OS…
- Vous devez être connecté pour répondre à ce sujet.
