Moonz a écrit 3621 commentaires

> "Au final, notre objectif est de combiner Flash et PDF"
ben ça promet :)

Dans les gagnants de l'IOCCC, il y a quelqu'un qui a fait un serveur HTTP ultra light (supporte en partie CGI, mais pas entièrement et c'est tout... Mais en quelques centaines de lignes de code seulement :o))

Et en python, tu peux faire les deux :)
(cad à la fois gtk.VBox(homogeneous=True, spacing=5) et gtk.HBox(True, 5))

Le langage Boo n'est pas mal, mais l'API est comment dire... horriblement trop complexe pour faire des trucs basiques (compare le module httplib de python et essaie de faire aussi simple avec Mono...). A l'époque où j'ai essayé (il y a 2-3 mois), ça m'a vraiment donné l'impression d'utiliser une bombe H contre un moustique...

C'est pas non plus la mer à boire hein... T'as juste à tester os.name... La vraie critique qu'on pourrait faire, c'est qu'on doit préciser le chemin entier, et encore... c'est pas plus difficile de chercher automatiquement dans $LD_LIBRARY_PATH, /usr/lib et /lib... Ca se fait en quelques lignes de codes. Tiens, juste pour m'amuser:

def LoadLibraryPath(lib):
	search_path = os.getenv("LD_LIBRARY_PATH")
	
	if search_path is not None:
		search_path = search_path.split(os.path.pathsep)
	else:
		search_path = []
	
	for p in ["/lib", "/usr/lib"]+search_path:
		if os.path.exists(os.path.join(p, lib+".so")):
			return LoadLibrary(os.path.join(p, lib+".so"))

Maintenant, il n'y a plus qu'à tester os.name et agir en conséquence (j'avoue que je 'lai pas fait parce que je connais pas trop RiscOS, OS/2 et autres systèmes gérés par Python...). Ca m'a pris plus de temps taper le message que le code :) (c'est la faute à templeet...)

D'ailleurs, ça marche pas non plus avec QtParted sous KDE par exemple ;)

Non, sur http://starship.python.net/crew/theller/ctypes/ il est bien écrit:
> ctypes allows to call functions exposed from dlls/shared libraries
(sous-entendu: n'importe quelle librairie)

Dans le tutorial, tu as un exemple avec /lib/libc.so.6... Rien à voir avec COM ou ActiveX ;)

> [DllImport("opengl")]
> public static extern void FonctionNative(string arg1, int arg2);
> C'est intégré au langage, c'est compilé en code managé, c'est donc portable sans modification et sans avoir à utiliser le langage intermédiaire.

http://wikipython.flibuste.net/moin.py/CodeWindows#head-3508(...)
Contrairement à ce qui est annoncé, c'est pas limité à l'API Windows. C'est pas véritablement intégré au langage, mais c'est pas non plus plus complexe que ton truc ;) (je trouve même là syntaxe plus propre - mais c'est strictement subjectif, c'est juste que j'ai été traumatisé à vie par la syntaxe [Truc(bidule)] par l'API windows ;)...)

C'est un binding ça, non ? Je pense que les langages ne supportant pas ça sont plus rares que ceux qui les supportent ;)

>>> Appels bibliothèques natives multi-plateforme et intégré au langage
>>> en python aussi ... non ? ;-)
>> Non. Ou alors j'ai jamais vu. ...
>os, string, ... bref toutes les libs faisant partie de "python" (les batteries included, et il y en a pas mal ...)

Je pense qu'il pensait plutôt à une sorte de dlopen. Et oui, c'est possible (à tout hasard, le module dl ? :)). Par contre multiplatforme je vois pas comment c'est possible, vu que les libs natives ne le sont pas... Oui alors c'est moi qui n'ait rien compris ;)

Si tu veux VRAIMENT un dico, un petit assert(type(dico) == dict) au début de la fonction devrait faire l'affaire ;)

J'ai pas mon prog sous la main (je l'ai pas avant Noel d'ailleurs), donc me demande pas de me souvenir des fonctions de GTK que j'utilisais ;)
Pour le principe, c'était simplement que lorsque la fenêtre intérieure bougeait, les coordonnée actives du treeview changeaient aussi (j'utilise surement pas le bon vocabulaire, désolé...). Il y a un callback pour surveiller cet événement. Dès que ces coordonnées changent:
- je retire le premier élément (il y a une fonction pour obtenir un élément à partir de ses coordonnées), et le replit
- je remplit l'élement suivant tant qu'il est dans la zone d'affichage (en calculant ses coordonnées)
Ca nécessite uniquement de connaitre la position de l'élément. Je dois l'avouer que ça, je l'ai fait "à l'arrache" (j'ai fais une colonne invisible "position" et je la remplissait dès le dépliage de l'élément parent). Il y avait sûrement plus rapide avec les fonctions de GTK, mais je venais de passer deux jours dans la doc pour réaliser ce que je te décrit, j'en avais marre ;)

Tu peux compiler un script python en bytecode Java (Jython) ou .Net (utilisable avec Mono bien sûr) avec IronPython (qui me semble légèrement mort en passant), mais je vois pas l'intérêt sous un système d'exploitation correct. Pour le système d'exploitation pas correct (désolé, la fatigue, toussa, on fait plus attention aux trolls), ya py2exe. Je sais que pygtk fonctionne avec py2exe, je crois que wxpython aussi (donc logiquement pyqt aussi), mais je sais pas comment ça se passe avec IronPython/Jython (tu peux bien sûr utiliser respectivement Swing/AWT/SWT et GTK#/WinForms, mais dans ce cas tu pourras plus utiliser ton programme dans un autre envitonnement comme CPytohn (le standard). Si tu fais du Swing/AWT/SWT, t'obliges l'utilisation de Jython, idem pour GTK# et IronPython. Quoique GTK# et pygtk ont peut être une API semblable, j'ai jamais touché à GTK#)

Mon avis personnel: Python + PyGTK permet de faire des chose vraiment étonnantes en quelques lignes de code avec un peu d'entraînement. Sous Linux, c'est relativement rapide (tu vas pas faire une application de calculs dessus, mais pour une application "normale", c'est largement suffisant). Sous Windows, tu as py2exe pour failiter la distribution. Bref, c'est le pied
J'ai également pendant un moment fait du GTK(mm/+)/C++, mais une fois que tu as goûté à la souplesse du python, tu ne peux plus t'en passer.

Pour être totalement subjectif, je vais te raconter mon expérience. J'ai eu à faire (pour besoins personnels) une application qui comportait un TreeView structuré de cette manière: 4-5 éléments de base qui contient chacun 1000 éléments fils qui contienent chacun 10 éléments fils. Soient 50 000 élements. J'ai commencé en GTK+/C++ par la méthode bourrin: on remplit tout d'un coup, et on laisse GTK+ se débrouiller avec le dépliage et toussa. Ca ramait à mort, et ça bouffait toute la RAM. Je me suis dit que je devrais calculer uniquement les éléments fils lors du dépliage. Ca ramait environ 2-3 secondes pour les gros dépliages (quand je dit que chaque racine à 1000 éléments, c'est très hétérogène: une en a 500, une autre 3000), mais c'était correct. Mais c'était ingérable en fait. Puis je suis passé en Python+PyGTK et je me suis dit "vu comment ça rame en C++, ça va pas être utlisable". Mais j'ai quand même essayé. Et là ça a été la révélation: grâce à la souplesse de Python, j'ai pu faire en sort que le calcul des sous-éléments se fasse uniquement lors de l'affichage [1]. En fait, contre la lenteur de Python, j'ai largement gagné par le fait que sa souplesse me permettait une architecture très peformante (en C++, ça aurait été facilement 5x plus de classes, méthodes, lignes de codes et erreurs possibles; en C, n'en parlons pas ;)). Ca ne ramait pas au démarrage, quelques millisecondes (à peine visble) aux énormes dépliages (en fait, je me suis permis 10 000 sous éléments et ça a pas ramé plus d'une demi-seconde). Ca saccadait légèrement lorsqu'on descendait rapidement, mais c'était tout.


[1] En entrant dans les détails techniques, je possédais un fichier XML à parser, possédant 5 gros éléments, qui possédaient quelques milliers de sous éléments (variable, de 500 à 10 000 en fait ;)) (qui eux même possédaient des sous éléments, mais ça n'a pas grande importance).
Première architecure: on parse tout, on fait tout dans le TreeView, et basta (ça rame horriblement au démarrage, et je vous explique pas l'occupation mémore...)
Seconde (C++): dès qu'on déplie on élément, alors seulement on crée ses éléments fils. Lorsqu'il y a 500 elems ça va, mais dès qu'on dépasse les 2000, ça rame. Et c'est déjà "lourd" de faire comme ça en C++
Troisième (Python): on dépliant un élément, on lui ajoute le nombre de fils qu'il possède (connus), mais vides: pas la peine de parser et de tout replir. On remplit que ce qui n'est visible, et lorsque la vue change (on scrolle, on redimensionne la fe,être), on renseigne les éventuels nouveaux éléments. Inmaintenanble en C++, une 100aine de lignes en Python, et drolement efficace pour un langage interprété...


Bon, j'arrête là de m'étaler

ls | grep -v '^mon_fichier.txt$' | xargs rm
Ca résoud pas le pb de l'espace, mais ça marche pour .mon_fichier.txt~ ^^

Quand on pense que c'est parti d'une discussion sur Gaim...
Yen a qui devraient faire trolleur comme métier...

Et tu viens d'augmenter le google rank de cette page en mettant le lien sur un site comme linuxfr :)

Je viens de regarder le code source de FontConfig, et effectivement FontConfig initialise correctement la variable result lors d'une erreur, mais pas lors d'un succès... Et à première vue, c'est une ligne de code à changer dans le code...
A votre avis, c'est un bug que je devais reporter+corriger, ou j'ai mal lu la documentation quelque part ? (parce que quand même, si c'était un bug, c'est assez gros, ça m'étonnerais que personne l'ai trouvé avant... Et j'ai beau relire la doc de la fonction FcFontMatch, il ne dit pas qu'on doit affecter la variable result à FcMatch avant l'appel à la fonction...)

Ca marche pas beaucoup mieux


import sys, gtk, threading

def test(*args):
dialog = gtk.MessageDialog(None, gtk.DIALOG_MODAL, gtk.MESSAGE_INFO, gtk.BUTTONS_OK, "Plop")
dialog.run()
dialog.destroy()

class Thread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)

def run(self):
gtk.gdk.threads_enter()
test()
gtk.gdk.threads_leave()

return

class Main(gtk.Window):
def __init__(self):
gtk.gdk.threads_init()

gtk.Window.__init__(self, gtk.WINDOW_TOPLEVEL)
b1 = gtk.Button("gtk.Dialog dans le thread principal")
b2 = gtk.Button("gtk.Dialog dans un autre thread")
h = gtk.HButtonBox()

b1.connect("clicked", test)
b2.connect("clicked", self.thread)

h.pack_start(b1)
h.pack_start(b2)

self.add(h)
self.show_all()

gtk.main()

def thread(self, btn):
t = Thread()
t.start()

Main()



Le plus étrange, c'est que ça fonctionne la première fois, mais pas la deuxième.

Merci quand même :)

Euh il me semble bien que error_reporting(E_ALL) t'affiche un message pour ça

J'ai relu pour corriger mes fautes d'orthographe, mais j'ai pas vu une petite coquille: il ne faut pas lire http://localhost/lst/k-k+(...) mais http://localhost/lst/k-k%2b(...)

Je connais pas Ruby, mais Python lève une exception lorsqu'une variable non déclarée est utilisée. Et pour déclarer une variable sans l'initialiser, un var = None devrait suffire. En ce qui concerne PHP, un error_reporting(E_ALL) fait apparaître un message lors de l'utilisation d'une variable non déclarée

Un lien symbolique sur du FAT ou du NTFS ? :)

Faisons une bonne comparaison, c'est plutôt comme un gagnant de l'OCCC :)

Le monsieur ne critique pas le fait de parler politique française, mais de faire 15 journaux la dessus. Et je suis d'accord avec lui
Actuellement visible sur la page des journaux, journaux ayant un rapport avec le TCE:
http://linuxfr.org/~smorico/18320.html(...)
http://linuxfr.org/~Duncan_Idaho/18319.html(...)
http://linuxfr.org/~nayco/18312.html(...)
http://linuxfr.org/~patatorz/18311.html(...)
http://linuxfr.org/~ccomb/18304.html(...)
http://linuxfr.org/~ahuillet/18301.html(...)
http://linuxfr.org/~PieD/18298.html(...)
http://linuxfr.org/~Sam_from_MS/18293.html(...)
http://linuxfr.org/~Cooker/18284.html(...)
http://linuxfr.org/~Lefuneste/18280.html(...)
http://linuxfr.org/~patrick_g/18263.html(...)
http://linuxfr.org/~Ragnagna/18279.html(...)
http://linuxfr.org/~BlueTak/18285.html(...)
http://linuxfr.org/~fab97/18288.html(...)
http://linuxfr.org/~TyrandO/18306.html(...)
(sans compter http://linuxfr.org/~LiNuCe/18296.html(...) hein :))

Alors franchement, les journaux sur la constitution européenne, c'est NON !

Je ne parle pas de la consommation disque, mais de la quantité écrite sur le disque: si je fais 50 fois appel à la fonction sur un fichier de 100 Mo, je devrais réecrire entièrement le fichier sur le disque 50 fois, donc 50x100 = 5000 Mo = 5 Go... Et écrire 5Go sur le disque, ça se sent
Un moyen serait de ne pas faire de fichier temporaire, et ainsi ce n'est pas la peine de réécrire tout ce qui est avant p (à partir de p on décale toutes les données de n octets vers le début). Si les données à supprimer sont vers la fin, ce sera rapide, mais si elles sont au début, on aura le même problème.. Je pense que je vais faire comme ça, sauf si c'est trop lent... Si ça intéresse quelqu'un, voilà ma fonction:

void fshrink(int fd, off_t start, size_t len) {
struct stat st;
size_t buf_size = COPY_BUFFER_SIZE, read_size;
uint8_t buf[buf_size];

lseek(fd, start, SEEK_SET);

do {
lseek(fd, len, SEEK_CUR);
read_size = read(fd, buf, buf_size);
lseek(fd, -len-read_size, SEEK_CUR);
write(fd, buf, read_size);
lseek(fd, buf_size, SEEK_CUR);
} while(read_size == buf_size);

fstat(fd, &st);
ftruncate(fd, st.st_size - len);
}

Bon, si ça marche pas, j'ai plus qu'à faire le "hack immonde" :(