je ne connais pas la distribution Drinou. par ailleurs le site officiel indique que Drinou n'est plus maintenue et qu'il vaut mieux utiliser Polux (http://217.109.169.18/polux/pituxbook.htm). à priori, Polux ne propose pas python, mais étant basée sur slackware 7, tu dois pouvoir installer un package python pour slackware.
une DamnSmall ! je comprends mieux.
en fait il n'est pas possible de compiler quoi que ce soit sur cette distribution car elle est très minimaliste, pas de make, pas de compilateur, pas de librairies de développement (d'où les messages d'erreur) -- voir liste des packages http://www.damnsmalllinux.org/packages.html). de plus, c'est plutôt un liveCD même si on peut l'installer sur un disque dur.
par contre, elle est en base knoppix, donc debian; alors il est possible de lui ajouter des repositories pour apt. toutefois, dans la FAQ de DSL, l'installation d'applications par ce biais est peu conseillée (http://www.damnsmalllinux.org/dsl-hd-install.html#apt-get) , ou du moins doit être faite avec précautions pour éviter de casser le système.
je ne sais pas ce que tu cherches à faire avec python au démarrage, mais cela me semble compromis avec une DSL. donc sois tu changes de distribution, soit tu tentes de travailler avec perl (qui semble présent en version de base d'après la liste des packages).
1. cas ardu : ta distribution n'intègre pas python.
dans ce cas, télécharger la dernière version sur http://www.python.org
décompresser l'archive et se lancer dans les sempiternels
./configure
make
make install
évidemment python a un certain nombre de dépendances qu'il faudra gérer.
2. cas simple : ta distribution intègre python
dans ce cas, il est probablement déjà installé.
pour le savoir, il suffit d'ouvrir un terminal et de taper python pour rentrer dans l'interpréteur.
si il n'est pas installé, en fonction de ta distrib, un coup de apt, d'urpmi, de yum ou de emerge devrait installer tout ce qu'il faut
B. exécution simple
une fois python installé, pour exécuter un script
python monscript.py
ou si la première ligne de ton script est
#!/usr/bin/env python
et que le script est exécutable (chmod +x monscript.py)
./monscript.py
C. exécution au démarrage
une fois de plus cela dépend de la distribution, donc là, il nous faut plus d'informations.
je ne crois pas que cela soit possible de changer le user. par contre, si tu as installé postgresql depuis les RPMs de Mandrake, le user postgres doit déjà exister (!! son home n'est pas /home/postgres mais un truc du genre /var/lib/postgres).
d'ailleurs tu ne dois pas pouvoir te connecter directement en postgres, tu es obligé de passer par root puis de faire un su - postgres
dernière chose, pour ne pas ouvrir la console d'administration de la Mandrake, en ligne de commande sous root tu peux faire
service postgresql start
service postgresql stop
service postgresql restart
pour être précis, il existe deux gestionnaires ODBC pour unix/linux
- unixODBC
- iODBC
il existe bien un module dans php pour accéder aux bases ODBC.
quand aux mdbtools, il y a bien un driver ODBC mais je n'ai jamais réussi à le faire fonctionner avec une base access2000. bon c'était il y a un an, ça a peut-être évolué depuis. et c'était avec python/mxODBC, ça aurait peut-être marché en php. à voir.
select * from * ???
je ne crois pas que cela fonctionne. en fait, je suis sûr que cela ne fonctionne pas ! (du moins en version 7.4.5)
dbtest=> select * from *;
ERROR: syntax error at or near "*" at character 15
dbtest=>
par contre, pour obtenir la liste des tables dans une base postgresql, rien ne vaut :
select * from pg_tables
et on peut ajouter une clause where schemaname='public' pour n'avoir que les tables de ce schéma.
en fait c'est une option dans gnome, ce n'est pas lié au window manager.
dans les préférences de la souris, dans l'onglet concernant les curseurs, il y a une option "Localisation du pointeur" qui, lorsqu'elle est cochée, fait que tu as un effet graphique localisant le curseur de la souris en appuyant sur control. ça permet juste de savoir où est le curseur.
merci de m'avoir repris pour le lien, ça m'apprendra à ne pas bien me relire.
par contre, je te serai grès de m'expliquer la différence subtile entre l'utilisation et le support de IPoT. parce que personnellement, je n'en fais pas. je considère que le support est une utilisation facultative.
ça va faire un peu redite avec un de mes commentaires du jour, mais l'IPoT est déjà utilisé par la poudre verte http://www.lapoudreverte.com(...)
à solution révolutionnaire technologie révolutionnaire !
il y a aussi hackerthreads, site sur lequel j'ai acheté quelques tisheurts. il y a une section opensource où j'ai trouvé des exemplaires qui me valent l'admiration de certains (notamment un tshit gnome du meilleur goût -- pour lequel le site reverse une part à la fondation).
self.window est hérité de Widget
>>> help(gtk.Window)
(...)
| Data and other attributes inherited from Widget:
(...)
| window = <attribute 'window' of 'gtk.Widget' objects>
(...)
je suppose que l'utilité est d'avoir un lien direct sur la fenêtre gdk sans passer par get_parent_window, mais il est vrai qu'il n'y a pas trop d'info sur cela dans la documentation. il faudrait peut-être jeter un oeil sur l'API gtk. un volontaire ?
enfin si les informations de la fenêtre gdk font ton bonheur, alors je ne vois pas de manière plus concise de coder que ce que tu proposes.
personnellement je fais du pygtk portable linux/win32 sans changer une ligne de code ...
mais il peut sembler plus naturel de choisir wx ou tk pour du vrai multiplateforme; c'est peut-être aussi une question de goût, j'ai toujours beaucoup de mal à positionner correctement mes widgets avec wx car je suis trop habitué à gtk.
je ne vois pas pourquoi tu travailles sur la fenêtre gdk et pas sur la fenêtre gtk.
c'est aussi simple de prendre directement la fenêtre de ton application et de lui demander sa position et sa taille
il serait notamment très intéressant de laisser à la portée de tous la série de tutoriaux sur les bases de données, qui sont basés sur l'utilisation de postgresql, ils m'ont été d'une grande aide lorsque j'ai voulu aller plus loin avec ce RDBMS.
et il y a sûrement plein d'autres documentations utiles à tous.
les fichiers installés depuis le web par urpmi sont stockés dans
/var/cache/urpmi/rpms
(attention le répertoire est vidé si tu as utilisé l'option --clean)
ensuite sur la machine destination, tu copies les fichiers dans un répertoire, tu crées une nouvelle source de rpms qui pointe sur ce répertoire
urpmi.addmedia local_rpms file:///chemin/vers/mes/rpms
et tes rpms de mise à jour sont disponibles via la source local_rpms
Posté par Brahici .
En réponse au journal Suse 9.3.
Évalué à 1.
mono est libre: oui
mais il ne faut pas oublier que mono (ainsi que dotgnu) sont des implémentations libres d'un framework dont la spécification appartient à micro$oft.
les versions actuelles des spécifications sont actuellement des normes ECMA, tout le monde peut s'en servir pour développer sa propre implémentation. par contre, rien ne dit que dans le futur (plus ou moins proche), m$ sorte de nouvelles spécifications qui seront elles plus fermée, auquel cas, seule l'implémentation de m$ sera légale, les autres devenant hors-la-loi. tu peux alors imaginer la tête des personnes qui auront choisi de construire leurs systèmes sur des implémentations libres de .net ....
Posté par Brahici .
En réponse au journal Suse 9.3.
Évalué à 2.
aucune idée, mais on peut se laisser aller à quelques hypothèses.
Beagle c'est avant tout un ensemble de classes Mono, sur lequel les développeurs ont branché un front-end gtk#.
si on considère que Qt# existe, on peut imaginer qu'il pourrait y avoir une version de Beagle intégrée directement à KDE. je suis un peu l'actualité de Mono et je n'ai pas entendu parlé d'un tel projet (qui toutefois pourrait être interne à Novell et donc plus ou moins caché sur NovellForge).
Posté par Brahici .
En réponse au journal Suse 9.3.
Évalué à 4.
c'est audacieux mais pas surprenant.
audacieux : Beagle est en version 0.0.7
pas surprenant : Beagle est développé par Nat Friedman (co-fondateur de Ximian), et employé de Novell, à qui appartient Suse. la boucle est bouclée.
par ailleurs, je trouve Beagle très prometteur, mais c'est un avis personnel. d'autant que je ne l'ai pas encore testé.
j'ai eu un problème similaire sur un portable. mais ce n'était pas un problème graphique mais plutôt sonore.
la carte son n'était pas gérée et par défaut les sons système sous gnome étaient activés.
gnome n'en finissait jamais de démarrer tant que le démon esd tentait de s'initialiser. finalement, au bout d'un moment je finissais par récupérer la main (cartains aiment attendre, ça leur permet de contempler leur beau splashscreen mais bon on peut se lasser ...).
en désactivant les sons systèmes au démarrage de gnome, ça a été tout de suite beaucoup mieux.
tu peux peut-être tenter cela.
[^] # Re: reponse
Posté par Brahici . En réponse au message installer et executer un script Python. Évalué à 1.
[^] # Re: reponse
Posté par Brahici . En réponse au message installer et executer un script Python. Évalué à 1.
en fait il n'est pas possible de compiler quoi que ce soit sur cette distribution car elle est très minimaliste, pas de make, pas de compilateur, pas de librairies de développement (d'où les messages d'erreur) -- voir liste des packages http://www.damnsmalllinux.org/packages.html). de plus, c'est plutôt un liveCD même si on peut l'installer sur un disque dur.
par contre, elle est en base knoppix, donc debian; alors il est possible de lui ajouter des repositories pour apt. toutefois, dans la FAQ de DSL, l'installation d'applications par ce biais est peu conseillée (http://www.damnsmalllinux.org/dsl-hd-install.html#apt-get) , ou du moins doit être faite avec précautions pour éviter de casser le système.
je ne sais pas ce que tu cherches à faire avec python au démarrage, mais cela me semble compromis avec une DSL. donc sois tu changes de distribution, soit tu tentes de travailler avec perl (qui semble présent en version de base d'après la liste des packages).
# deux cas
Posté par Brahici . En réponse au message installer et executer un script Python. Évalué à 5.
1. cas ardu : ta distribution n'intègre pas python.
dans ce cas, télécharger la dernière version sur http://www.python.org
décompresser l'archive et se lancer dans les sempiternels
./configure
make
make install
évidemment python a un certain nombre de dépendances qu'il faudra gérer.
2. cas simple : ta distribution intègre python
dans ce cas, il est probablement déjà installé.
pour le savoir, il suffit d'ouvrir un terminal et de taper python pour rentrer dans l'interpréteur.
si il n'est pas installé, en fonction de ta distrib, un coup de apt, d'urpmi, de yum ou de emerge devrait installer tout ce qu'il faut
B. exécution simple
une fois python installé, pour exécuter un script
python monscript.py
ou si la première ligne de ton script est
#!/usr/bin/env python
et que le script est exécutable (chmod +x monscript.py)
./monscript.py
C. exécution au démarrage
une fois de plus cela dépend de la distribution, donc là, il nous faut plus d'informations.
# kheops
Posté par Brahici . En réponse au sondage Juste avant mon OS actuel, j'utilisais. Évalué à 1.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Brahici . En réponse au message problème avec postgres. Évalué à 3.
d'ailleurs tu ne dois pas pouvoir te connecter directement en postgres, tu es obligé de passer par root puis de faire un su - postgres
dernière chose, pour ne pas ouvrir la console d'administration de la Mandrake, en ligne de commande sous root tu peux faire
service postgresql start
service postgresql stop
service postgresql restart
[^] # Re: ODBC
Posté par Brahici . En réponse au message Accès à une base Access (MDB) sous Linux. Évalué à 2.
- unixODBC
- iODBC
il existe bien un module dans php pour accéder aux bases ODBC.
quand aux mdbtools, il y a bien un driver ODBC mais je n'ai jamais réussi à le faire fonctionner avec une base access2000. bon c'était il y a un an, ça a peut-être évolué depuis. et c'était avec python/mxODBC, ça aurait peut-être marché en php. à voir.
[^] # Re: select * from *
Posté par Brahici . En réponse au message postgresql. Évalué à 2.
je ne crois pas que cela fonctionne. en fait, je suis sûr que cela ne fonctionne pas ! (du moins en version 7.4.5)
dbtest=> select * from *;
ERROR: syntax error at or near "*" at character 15
dbtest=>
par contre, pour obtenir la liste des tables dans une base postgresql, rien ne vaut :
select * from pg_tables
et on peut ajouter une clause where schemaname='public' pour n'avoir que les tables de ce schéma.
# c'est gnome
Posté par Brahici . En réponse au message Touche control (ctrl) et gnome. Évalué à 7.
dans les préférences de la souris, dans l'onglet concernant les curseurs, il y a une option "Localisation du pointeur" qui, lorsqu'elle est cochée, fait que tu as un effet graphique localisant le curseur de la souris en appuyant sur control. ça permet juste de savoir où est le curseur.
[^] # Re: la poudre verte
Posté par Brahici . En réponse au journal LMI découvre IPOT. Évalué à 2.
par contre, je te serai grès de m'expliquer la différence subtile entre l'utilisation et le support de IPoT. parce que personnellement, je n'en fais pas. je considère que le support est une utilisation facultative.
# la poudre verte
Posté par Brahici . En réponse au journal LMI découvre IPOT. Évalué à 2.
à solution révolutionnaire technologie révolutionnaire !
[^] # Re: C'est même pas vrai, je mange pas de poisson aujourd'hui :-)
Posté par Brahici . En réponse au journal Vos poissons d'avril glanés sur le web. Évalué à 2.
http://www.poudreverte.com/(...)
# tinyerp
Posté par Brahici . En réponse au message Cherche logiciel de gestion commercial. Évalué à 2.
http://www.tinyerp.org(...)
la news sur linuxfr https://linuxfr.org/2005/03/25/18598.html(...)
# os.popen
Posté par Brahici . En réponse au message Lancer une commande shell sous python?. Évalué à 2.
# hackerthreads
Posté par Brahici . En réponse au journal Tee Shirts de geek ?. Évalué à 4.
http://www.hackerthreads.com(...)
[^] # Re: gagné
Posté par Brahici . En réponse au journal A votre avis ... (Mandriva inside). Évalué à 3.
sinon je vote pour avaplu ...
[^] # Re: bizarre
Posté par Brahici . En réponse au message PyGTK, taille et position des fenêtres. Évalué à 2.
>>> help(gtk.Window)
(...)
| Data and other attributes inherited from Widget:
(...)
| window = <attribute 'window' of 'gtk.Widget' objects>
(...)
je suppose que l'utilité est d'avoir un lien direct sur la fenêtre gdk sans passer par get_parent_window, mais il est vrai qu'il n'y a pas trop d'info sur cela dans la documentation. il faudrait peut-être jeter un oeil sur l'API gtk. un volontaire ?
enfin si les informations de la fenêtre gdk font ton bonheur, alors je ne vois pas de manière plus concise de coder que ce que tu proposes.
[^] # Re: re
Posté par Brahici . En réponse au message PyGTK, taille et position des fenêtres. Évalué à 2.
mais il peut sembler plus naturel de choisir wx ou tk pour du vrai multiplateforme; c'est peut-être aussi une question de goût, j'ai toujours beaucoup de mal à positionner correctement mes widgets avec wx car je suis trop habitué à gtk.
# bizarre
Posté par Brahici . En réponse au message PyGTK, taille et position des fenêtres. Évalué à 2.
c'est aussi simple de prendre directement la fenêtre de ton application et de lui demander sa position et sa taille
w=gtk.Window(gtk.WINDOW_TOPLEVEL)
w.get_position()
w.get_size()
ce qui dans ton cas pourrait donner
xml_out += '%d' % w.get_position()[0]
xml_out += '%d' % w.get_position()[1]
xml_out += '%d' % w.get_size()[0]
xml_out += '%d' % w.get_size()[1]
# azureus
Posté par Brahici . En réponse au message Client Bittorrent sous Linux. Évalué à 2.
nécessite java.
http://azureus.sourceforge.net(...)
[^] # Re: Sauvegarde
Posté par Brahici . En réponse à la dépêche LinuxFrench.NET, c'est fini^W^Wça repart !. Évalué à 5.
et il y a sûrement plein d'autres documentations utiles à tous.
# je ferais comme ça
Posté par Brahici . En réponse au message Chalenge : mise a jour sur 2 machines. Évalué à 2.
/var/cache/urpmi/rpms
(attention le répertoire est vidé si tu as utilisé l'option --clean)
ensuite sur la machine destination, tu copies les fichiers dans un répertoire, tu crées une nouvelle source de rpms qui pointe sur ce répertoire
urpmi.addmedia local_rpms file:///chemin/vers/mes/rpms
et tes rpms de mise à jour sont disponibles via la source local_rpms
[^] # Re: piège ?
Posté par Brahici . En réponse au journal Suse 9.3. Évalué à 1.
mais il ne faut pas oublier que mono (ainsi que dotgnu) sont des implémentations libres d'un framework dont la spécification appartient à micro$oft.
les versions actuelles des spécifications sont actuellement des normes ECMA, tout le monde peut s'en servir pour développer sa propre implémentation. par contre, rien ne dit que dans le futur (plus ou moins proche), m$ sorte de nouvelles spécifications qui seront elles plus fermée, auquel cas, seule l'implémentation de m$ sera légale, les autres devenant hors-la-loi. tu peux alors imaginer la tête des personnes qui auront choisi de construire leurs systèmes sur des implémentations libres de .net ....
[^] # Re: audacieux
Posté par Brahici . En réponse au journal Suse 9.3. Évalué à 2.
Beagle c'est avant tout un ensemble de classes Mono, sur lequel les développeurs ont branché un front-end gtk#.
si on considère que Qt# existe, on peut imaginer qu'il pourrait y avoir une version de Beagle intégrée directement à KDE. je suis un peu l'actualité de Mono et je n'ai pas entendu parlé d'un tel projet (qui toutefois pourrait être interne à Novell et donc plus ou moins caché sur NovellForge).
# audacieux
Posté par Brahici . En réponse au journal Suse 9.3. Évalué à 4.
audacieux : Beagle est en version 0.0.7
pas surprenant : Beagle est développé par Nat Friedman (co-fondateur de Ximian), et employé de Novell, à qui appartient Suse. la boucle est bouclée.
par ailleurs, je trouve Beagle très prometteur, mais c'est un avis personnel. d'autant que je ne l'ai pas encore testé.
à propos de Beagle, ce lien est très intéressant
http://nat.org/demos(...)
# peut-être un problème de son
Posté par Brahici . En réponse au message démarrage gnome très lent. Évalué à 2.
la carte son n'était pas gérée et par défaut les sons système sous gnome étaient activés.
gnome n'en finissait jamais de démarrer tant que le démon esd tentait de s'initialiser. finalement, au bout d'un moment je finissais par récupérer la main (cartains aiment attendre, ça leur permet de contempler leur beau splashscreen mais bon on peut se lasser ...).
en désactivant les sons systèmes au démarrage de gnome, ça a été tout de suite beaucoup mieux.
tu peux peut-être tenter cela.