Moonz a écrit 3536 commentaires

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" :(

Non, c'est pas bien compliqué, j'ai parfaitement compris ce que toi et TheBreton voulaient dire...
Pour l'encombrement mémoire, je suis d'accord que ce n'est pas forcément un problème, mais il reste le problème que dans le pire des cas je doit écrire 5 Go sur le disque dur :)

Réponse courte: gné ?
Réponse longue:
- Qu'est ce que tail a à faire là dedans ? Aux dernières nouvelles, il sert à obtenir la fin d'un fichier, et ce que je veux supprimer est en plein milieux (et accessoirement, tail ne fonctionne qu'avec des entiers signés sur un 1 octets - des char quoi - alors que le fichier en question est constitué par des entiers ou des flottants, signés comme non signés, et de taille allant de 1 à 4 octets)
- tail dans un prog en C ? je ne suis pas fan de system()... et man 2 tail me dit que ya pas de libtail :)
- je ne veux pas supprimer seulement la fin, sinon ce serait trop facile (et ftruncate serait suffisant)
Donc soit j'ai mal compris, soit tu as mal compris (ou les deux)

En gros, c'est la solution que j'ai citée dans mon post: tout écrire dans un fichier temporaire sauf les octets à supprimer, puis déplacer le fichier temporaire
Je pense pas que ce soit une bonne idée: mettons nous dans le pire des cas: je veux réduire 50 fois un fichier de 100 Mo (taille maximale je pense des fichiers que je veux manipuler). Dans ce pire des cas, je suis obligé de faire appel 50 fois à la fonction (ça, c'est lié à la structure de mon programme, et je ne peux pas changer ce comportement sans faire un hack immonde - et quitte à faire un hack dégueulasse, je préfère encore utiliser ma solution de rechange, qui gaspille de la place dans le fichier mais qui a le mérite d'être extrémement rapide). Donc je dois écrire 50*100 = 5000 = 5 Go sur le disque dur ! Et ça, c'est en comptant que déplacer le fichier ne recopie pas les données - si le répertoire /tmp est sur une partition différente on va devoir écrire 10 Go sur le disque... A contition que la partition /tmp soit assez grande, sinon le programme plante
De plus, soit j'utilise un buffer variable pour stocker les données lues par read (et dans ce cas si l'octet à supprimer est au début ou à la fin du fichier ça bouffera 100 Mo en RAM), soit un buffer constant (et dans ce cas je dois choisir une taille, trop grande, ça bouffe de la mem pour rien, trop petit je devrais faire beaucoup d'appels à read-write sur de petits buffer, et ça dégradera les performances)
Ma question, c'est s'il existe pas un moyen aussi simple pour réduire la taille d'un fichier que O_APPEND pour l'augmenter...

ffmpeg aussi le supporte... par contre, je ne sais pas ce qu'il faut mettre pour l'audio, étant donné que je n'ai aucune expérience de ces logiciels et des caméras...
ffmpeg -i video.avi -acodec le_codec_audio_qui_va_bien -vcodec dvvideo -sameq video_dv.avi

il est extremement simple d'intercepter tous les appels de fonction fait par un executable dans une libraire
Et si cette fonction est inline, ou si c'est une macro ?

How many of them are saying, "I'm so impressed I'm going to switch to a Free Software desktop." Virtually zero.
Etrangement, je suis d'accord avec l'argument mais pas avec la conclusion. Effectivement, personne ne dit "j'ai été tellement impressioné par Firefox que je vais passer à un système libre". Mais si demain Firefox n'existe plus que pour Linux/BSD, ceux qui ont été "impressionés par Firefox" passeront sous IE plutôt que sous Linux/BSD (Linux, c'est compliqué, ya que du mode texte, j'ai pas dreamweaver, mon matos marche pas, j'ai la flemme de l'installer, ya pas de jeux)... Au contraire, Firefox sous Windows permet de réduire les sites "100% compatibles IE - 0% reste du monde". Et ça peut vous paraitre égoiste, mais je préfère pouvoir visionner tous les sites sous mon Firefox sous Linux plutôt que Linux gagne 0.0000001% des parts de marché... (gain par un Firefox uniquement sous Linux). L'argumentation "c'est les logiciels qui font le choix du système d'exploitation" ne fonctionne que dans le cas d'une migration Windows->Linux. Tous les logiciels Linux ont un équivalent Windows (on parle du voisin qui a piraté XP pro, pas d'un admin réseau qui a à gérer quelques centaines de machines), mais pas l'inverse. Je ne pense pas que beaucoup de personnes aient choisies Linux uniquement pour Kopete/Evolution...

> creant ainsi une situation qui n'aurait jamais eu lieu sans l'homme (ex: gene de poisson dans une plante)
Ha... va te promener en forêt et mange tous les fruits pas que tu trouves. Avec un peu de (mal)chance tu peux être très malade.
Bah oui les plantes toxiques ça existait déjà avant les OGMs.
La différence, c'est que pour les OGMs, on ne sait pas à l'avance si c'est toxique ou pas. Et là je suis d'accord avec toi, il faut plus de tests... avec des champs expérimentaux par exemple... (mais s'il n'y avais pas des écolos intaigristes qui n'ont pas pris le temps de chercher la définition d'expérimental...)
Ce qui me fait marrer chez les anti-OGMs, c'est leurs arguments: on connait pas donc c'est peut être dangeureux donc on brûle les champs expérimentaux (la peur de l'inconnu... avec des raisonnements pareils on en serait encore à l'état de manger de la viande crue dans des grottes gelées en hivers. Le feu ? Ca brûle, c'est extrèmement dangeureux ! Et ça peut modifier l'environnement en brulant des forêts entières !). C'est pas bien parce que ça peut se disséminer dans la nature. Comment ça c'est stérile? ben dans ce cas c'est pas bien parce que ça bloque les agriculteurs (en gros c'est pas bien parce que ça peut se reproduire mais comme ça peut pas se reproduire alors c'est pas bien parce que ça peut pas se reproduire... enfin c'est pas bien quoi!)

[X] je n'envoie jamais d'emails
bah quoi ? :p
(la preuve j'allais mettre je ne poste jamais d'emails ;)

C'est SigC, pas sigc (dans la ligne incriminée)...
Et il y a encore pas longtemps (Gtkmm 2.2) c'était SigC::slot et non pas SigC::mem_fun

pourquoi laisser un accès libre à son wiki...
Parce que c'est le but d'un wiki ?