Guillaum a écrit 472 commentaires

Et pour les mauvaises langues qui diraient que je suis mauvais car je n'ai pas trouver, je confirme, je n'ai pas trouvé.

Je viens d'installer le evince 2.32 de ubuntu maverick, et ben soit je suis mauvais (c'est fort probable), soit je n'ai pas trouver la façon de faire pour ajouter les annotations.

Bon, je me lance ;)

Sur un fichier de 2 GO, après plusieurs lancements pour être *presque* certain que les deux programmes exploitent de la même façon le cache du système, et en flushant le disque avant/après, bla bla,

En essayant plusieurs taille de *buffer* (ici 16384 Ko), j'obtiens:


time ./test /tmp/big_file /tmp/big_file2 16384
./test /tmp/big_file /tmp/big_file2 16384 0.00s user 1.79s system 14% cpu 12.357 total

time python test.py /tmp/big_file /tmp/big_file3 16384
python test.py /tmp/big_file /tmp/big_file3 16384 0.02s user 2.04s system 21% cpu 9.478 total


Avantage python.

Bon, ce benchmark n'a aucun intérêt, et des fois j'obtiens 11s pour le python et 10 pour le c ;)

C:


#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv)
{
char* file_in = argv[1];
char* file_out = argv[2];
size_t buffsize = atoi(argv[3]) * 1024;

FILE* fr = fopen(file_in, "rb");
FILE* fw = fopen(file_out, "wb");

char *buffer = (char*) malloc(buffsize);

while(1)
{
size_t read = fread(buffer, sizeof(char), buffsize, fr);

if(read == 0)
break;

size_t writed = 0;
while(writed < read)
{
writed += fwrite(buffer + writed, sizeof(char), read - writed, fw);
}
}

free(buffer);
fclose(fr);
fclose(fw);

}


Python :


import sys

file_in, file_out = sys.argv[1:3]
buffsize = int(sys.argv[3]) * 1024

with open(file_in, 'rb') as fr:
with open(file_out, 'wb') as fw:
while True:
data = fr.read(buffsize)
if len(data) == 0:
break
fw.write(data)


Bon, mon code C pue certainement... Compilé avec -march=native -Os -Wall

Sinon, comment on met du code sans pourrir l'indentation sur linuxfr ?

...alors je zoom, et c'est la cata :

- Les titres du haut deviennent portoflitactspace
- Les trois colonnes débordent et le bouton "en savoir plus" est par dessus
- La ligne de "copyright" n'est pas visible, noir sur noir

Après, plus subjectif, si je suis un client qui cherche un artiste 3D, j'ai pas envi qu'il me gave avec "rendu réalisé sous yafaray selon la méthode du pathtracing", cela ne prouve en rien tes compétences et cela fait étalage de mots-clés. C'est des choses qui vont dans les détails si tu veux le mettre (et c'est cool de le mettre, yafaray c'est sympa ;), mais pas dans le premier truc visible.

- J'ai rien pigé à la navigation... Surtout une fois que tu es dans une sous-sous rubrique, comment tu reviens en arrière ?
- Ne fait pas une galerie qui défile si tu as seulement une unique image.

Bon courage !

Bref, tout est dans le titre.

L'extension subrepos me semble permettre de faire tout ce que tu décris, et en plus elle vient de base avec mercurial ?

http://mercurial.selenic.com/wiki/Subrepositories?action=sho(...)

J'ai abandonné dernièrement Epiphany pour Firefox après avoir découvert Vimperator et j'étais bloqué par quelques limitations :

- l'ouverture d'onglets ne conserve pas l'historique (gèré par une extension, donc c'est bon)
- une certaine lenteur au défilement
- la non possibilité de redimensionner les zones de saisie de texte
- le non support des vidéos H.264

Pour la lenteur, la béta corrige principalement pas mal de point (les sites qui me faisaient hurler à cause de cela ne sont plus lents), problème qui était principalement lié au défilement des pages.

Et l'on peut maintenant redimensionner les zones de saisie de texte nativement !!! (Je regrette juste qu'il y ai aussi le support d'une propriété CSS permettant de désactiver ce redimensionnement).

Pour les vidéos, firefox 4 apporte le supporte de Web.M, donc la solution est en train d'arriver, mais c'est pas encore pour demain.

Donc firefox 4.0, testé et adopté en attente d'adoption car vimperator n'a pas encore été porté.

Pour le PDF je veux bien. Parce que autant là j'ai rien pigé...

Et comment tu trouves ce 1/N(N-2)! ?

Bon, alors, ce qui nous interesse c'est l'esperance de la probabilité de tirer au dessus de 1 en exactement n essais.

Alors, deja on va poser P(X = i), qui correspond à la probabilité de tirer en n ou moins essais. A ce moment la, la somme de n nombres entre 0 et 1 est comprise uniformement entre [0, n[, d'ou la probabilité d'etre au dessus de 1 c'est la probabilité du sous ensemble ]1, n[, qui est de (n-1) / n, ou 1 - 1/n.

Cela est assez intuitif comme résultat, car pour n = 1, l'on obtient 0 (c'est dur de faire plus de 1 avec un seul essai) et pour n = 2, on obtient 1/2, l'on à une chance sur deux, soit c'est au dessus, soit c'est au dessous.

Ici j'ai juste des doutes sur les bornes.

Bref, P(X=i) = (n-1) / n

Mais ici ce qui nous interesse, c'est la probabilité d'avoir en n essais sachant que l'on ne l'a pas eu en n - 1 essais, d'ou

P'(X = i) = P(X=i) - P(X = i-1) = (n-1) / n - (n-2) / (n-1) = 1 - 1/n - (1 - 1/(n-1))

= 1 / (n-1) - 1/n = (n - (n-1)) / (n(n-1)) = 1 / (n(n-1))

Mais finalement, ce que l'on veut c'est l'esperance de cette variable, d'où

E = \sum _ {i = 2} ^ \infty P'(X = i) * i = \sum _ {i = 2} ^ \infty 1 / (n-1) = \sum _ {i = 1} ^ \infty 1 / (n) = \infty !!!

Bref, cela fait trop... Où est mon erreur ?

Mais de rien ;)

Formulé comme cela oui, mais un sage à certainement dis cela il y a plusieurs siècle de façon plus jolie.

En effet, mais j'avais deja un peu detaillé cela dans mes précedantes dépeches

pour la 2.51
http://linuxfr.org/~Guillaum/29400.html

pour la 2.49 et 2.50 preview
http://linuxfr.org/~Guillaum/28344.html

pour la 2.50

http://linuxfr.org/2009/11/26/26196.html

C'est la même depuis maintenant 10 ans (en Aout). Mais c'est la même ! J'ai compté les changements de version ;)

Merci.

Bon, ca marche bien. Faut que je trouve comment se debarasser de cet héritage que je n'apprécie pas trop, mais sinon cela marche bien.

Je me trouve vraiment con depuis 10 minutes sur l'interface de designer à essayer d'ajouter un slot qui n'existe pas sur ma fenêtre. IL ne me propose que des noms de slots qui existent déjà...

Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…

Tu dois me confondre avec quelqu'un d'autre. Moi j'ai juste dis que le binding était pourris.

Merci pour le code. C'est bizarre (surtout le chose.setupUi(chose), cela me force à faire un héritage ce que je n'aime pas, mais cela à l'air de fonctionner.


Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…

C'est pas ce que j'ai lu dans la doc. Mais cela ne m'empechera pas de restester le jour ou j'aurais à me poser la question (cf le message précedant ou je ne suis vraiment pas beliqueux envers pyQT, juste que à l'époque ou j'ai essayé, cela ne remplissait pas du tout mes besoins)

Ha en fait tu confonds Qt et les bindings Qt pour Python, c'est ça ?

Ha ?

Non... Je parle de PyQT depuis le départ. Je n'ai jamais fait de C++Qt et je ne veut pas en faire (pour pleins de raisons, la première étant que je trouve stupide de s’embêter avec du C++ pour programmer, à mon humble avis, 99.9% des usages actuels du C++ sont non justifiés). La dépêche parlait de python, et ce fil de commentaire de PyQT/PyGTK, donc il n'y a pas trop de problème à ce que je parle de PyQT.


Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html

Ok. Personnellement cela ne m'a jamais posé problème, mais je me sert très peu de la souris. Ce qui me saoul ici avec Gtk c'est que lorsque l'on s’intéresse aux event souris, soit l'on en reçoit une quantité énorme non traitable en temps utile si le traitement prend un peu de temps (genre 100/s) si la souris bouge vite. Soit l'on peut activer le *buffer* (MOTION_HINT_NOTIFY) qui normalement se contente d'envoyer un seul event jusqu'à ce que tu lui dise qu'il peut en envoyer de nouveau, mais pourtant il continue à en envoyer plein.

Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.

Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.

Le binding pygtk est vraiment intégré de façon transparente à python. Apparemment c'est mieux pour le binding pyQT pour python3. En résumé je veux bien faire du QtGui, mais pas du QtList, QTString, QTFile, QtTortue.

Bref, quand python3 sera utilisable pour moi en production (mon attente principale étant numpy) et si quelqu'un me trouve comment faire pour connecter un signal de qt designer sur un slot de mon code, je redonnerais à pyqt sa chance. En attendant, pygtk est bien plus au dessus pour mon besoin à moins en confort de programmation.

http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/pyqt4r(...)

PyQt does not wrap the QUiLoader class but instead includes the uic Python module. Like QUiLoader this module can load .ui files to create a user interface dynamically

Bon, ok, on peut utiliser le module uic en lieu et place, mais je trouve cela bancal.

Aussi, je n'ai jamais réussit à enregistrer des "signals/slots" dans qt designer et à les connecter dans python comme je le ferais avec gtk/gtkbuilder/glade


Au moins Qt a un bon support du buffer souris.

Si tu parles du fait que l'event mouse-move est floodé sans moyen de contrôle, OUI, ce bug/feature me saoul particulièrement depuis un bout de temps.

Globalement je préfère gnome par rapport à kde, mais pour les applications graphiques que je développe, je m'en contrefout que cela soit du gtk ou du qt. Les éléments importants pour moi étant la simplicité de développement et la portabilité (+ facilité d'installation).


A l'époque ou j'avais fait du PyQT, je lui reprochais pleins de trucs, notamment :

- Une gestion de signal/slots dégueulasse avec PyQT. Je fais du python, je n'ai pas envi de déclarer des prototypes de fonction C++ au milieu de mon code python. Je crois que cela s'est largement amélioré depuis, mais je n'aime toujours pas.
- Ce problème de Uic cité avant
- Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt. Gtk ne fait que le toolkit et le fait plutôt pas mal et je n'ai JAMAIS en plusieurs année de pygtk eu a jouer avec la glib.
- Le fait que cela soit un binding d'un truc en C++ fait avec sip. J'aime pas le C++ ;)

Par contre il est vrai que pyQt semble vraiment plus portable (par contre il semble que cela soit aussi la misère que pyGtk à installer sous windows), donc c'est un argument qui penchera en sa faveur le jour ou j'aurais un vrai besoin de multi-plateforme.

J'ai un doute sur la validité de la preuve du (F(X))` = F`(X)

Merci pour la demo. Heureusement que c'est vendredi, parce que mes collegues ont bien apprecié que je passe 30 minutes sur le tableau blanc pour refaire la demo ;)

C'est dingue comme les probas et moi cela ne fonctionnera jamais.

En lisant le journal, j'ai voulu aussi retrouver la demonstration.

Je suis partit sur la construction d'un arbre. Chaque noeud correspond au point "Au tirage P, j'ai i cartes parmis N et j'en veux une de plus". La probabilité de passer au noeud "Au tirage P+1, J'ai i+1 cartes parmis N" est de (n-i) / n. La probabilité de passer au noeud "Au tirage P+1 j'ai i cartes parmis N" est donc de 1 - (n-1) / n.

J'ai donc maintenant un arbre infini et je n'arrive pas à m'en sortir...

Sinon, comment prouves tu que E(i) = n/(n-i). Chez moi j'ai

E(i) = somme(p=0..infini, p * P(i,p)) =
somme(p=0..infini, p * (i/n) ^ (p-1) * (n-i) / n)


et je n'arrive pas à avancer...

Le problème ici c'est c'est que le click sur la barre de metacity d'une fenetre remet le focus sur la précedante fenetre maximisée, rien à voir avec le fait de vouloir deplacer la fenetre.

En changeant le comportement de la barre, on se rend compte que le problème n'arrive qu'avec le maximize vertical (et le maximize qui cumule aussi un maximize vertical).

Hors une chose interessante est que le maximize vertical est la seule action qui change la position de la barre par rapport à la souris.

J'en deduis donc que le problème vient du fait que la souris n'est pas à l'endroit ou elle pense etre pour metacity.

Chose marrante aussi, c'est que si tu essayes de redimensionner une autre fenetre, cela redimensionne la précédante aussi.

Le select windows when the mouse moves over them ne change rien.

Après la question c'est "tu veux commander du Microsoft" où tu veux commander un OS ?

Parce qu'autant, si c'est commander un OS, l'appel d'offre tient la route. Mais si c'est commander du Microsoft Windows, et bien tu auras beau faire un appel d'offre, la seule société qui en vend c'est Microsoft.

Et c'est biencela toute la joie des appels d'offre pour le secteur publique. Je me rappel encore avoir envoyé plusieurs devis comparatif, dont les 3/4 venaient d'entreprise disant qu'ils ne peuvent fournir le produit car le produit était tellement spécifique qu'une seule et unique entreprise en fournissait.

Et bien ceux avec la meilleur note seront pertinants... Cela marche bien sur slashdot et linuxfr, alors pourquoi pas sur la doc python.

C'est une chose que j'aimais et detestait de la doc PHP. Il fallait vraiment faire le tri dans les commentaires et generalement quand l'on ne savait pas trop quoi faire, les mauvais commentaires orientaient dans une mauvaise direction.

J'ajouterais un détail. La tail queue récursion n'est utilisable que pour les algos où l'appel recursif est la dernière chose effectuée dans ce programme. Ce n'est pas le cas de la plupart des algorithmes récursifs. Et pour ceux pour lequel c'est le cas, ils peuvent tous très facilement s'écrire avec une boucle while.


def func(args):
if stop_condition(args):
return stop_value(args)
args = do_something(args)
return func(args)



def func(args):
while not stop_condition(args):
args = do_something(args)
return stop_value(args)


Ce qui donne pour la factorielle :


def fact(n):
accum = 1
while n >= 1:
accum *= n
n -= 1
return accum


voir plus simple ;)


def fact(n):
return reduce(int.__mul__, range(1, n+1))



Après, pour la plupart des algorithmes récursifs non terminaux, et bien tous les langages auront le même problème de stack, sauf les langages/implémentations qui n'utilise pas le C stack et alloue leurs stack sur le tas, ce qui ne fait que repousser le problème plus loin.