Laurent Morel a écrit 30 commentaires

NE pas confondre mature (adj.) et mâture (nom féminin), qui désigne l'ensemble des mâts d'un navire.
Dans "mûr" il y a un accent circonflexe, de là peut-être la confusion...

La VM est très complexe, certes, mais pas le langage en lui-même : c'est ça qui compte non ?
Concernant les destructeurs, ils n'ont plus lieu d'être si c'est pour libérer la mémoire. Pour les autres ressources (fichiers, etc.), ben vi c'est au programmeur de faire gaffe. Personnellement je n'ai jamais senti le besoin d'un destructeur, ni même vu de destructeurs dans du code java.
Aurais-tu un exemple réaliste ?

Message précédent mal noté car un peu péremptoire probablement...
Pourtant sur le fond je rejoins 'saucisson' : C++ est une accumulation de règles complexes destinées à clarifier ou contourner les problèmes posés par les règles précédentes.
J'avoue, j'ai arrêté le C++ après avoir lu "que seules les personnes en charge de la spécification du langage pouvaient connaître toutes ses arcanes" (en substance).
Effectivement, peu de personnes dans le monde sont capables d'écrire du vrai C++ en comprenant TOUT ce qu'elles écrivent (il y a un piège à chaque point-virgule).
Pour avoir relu du code générique écrit par un vrai "C++ guru", ben... j'ai parcouru, demandé moults explications, puis simplement commenté : "Très (trop ?) bon niveau de codage" : franchement, ce n'était pas maintenable par un mortel normal.

Objectivement, je ne trolle pas, mais vous voyez un avenir à C++ pour les terriens ?

Je me suis posé les mêmes questions.
Il me semble que le DVD n'est pas une mauvaise idée : au moins on a des chances de trouver un lecteur dvd dans 5 ou 10 ans pour les relire et transférer les données sur le nouveau support du jour.
50 Go ~ une vingtaine de DVD, ça peut aller.
Le disque dur (DD), je ne tenterais pas : en imaginant que les données tiennent, comment trouver un ordinateur sur lequel brancher ton DD dans 10 ans ? Ou alors tu gardes aussi l'ordi ?

J'espère que les futures versions de PHP apporteront la possibilité de rendre finale une variable de type complexe (tableau, objet,...).

Si php poursuit son chemin pour rejoindre Java, c'est effectivement possible... :-)
Pari : on verra le "finally { ... } avant le "final" ?
(Par exemple php 5.3 late static binding : permet de faire des appels de méthodes dynamiques, enfin !)

Je n'ai vraiment pas tout suivi, mais ça, ça me paraît osé :

ssh-agent >> "${SSH_AGENT_CACHE}" et SSH_AGENT_CACHE=/tmp/ssh_agent_eval_`whoami`

Autrement dit, tu génères dans /tmp un fichier à nom prédictible ? Ou bien tu es encore au boot et ton /tmp n'est pas encore accessible aux utilisateurs ?

Ce genre de teste permet de rapidement savoir ce qui pose problème.
On dirait un message de commercial chargé de la vente des produits...
Attention, pour avoir utilisé jmeter, je puis témoigner :
- qu'il peut être long de faire un plan de test réaliste
- qu'il est encore plus long de le rendre 'dynamique' (histoire que tous les pseudo-clients ne fassent pas toujours les mêmes recherches, etc. sinon on voit bien que cela va biaiser les résultats)
- que l'interprétation des résultats n'est pas immédiate (surtout si on souhaite agréger, comme tu le proposes, d'autres informations intéressantes : charges serveurs, etc.)
- qu'il subsiste un certain nombre de bogues et de limitations

Donc OK pour les tests de performance, mais c'est un mini-projet en soi.

rename(MonFichier.temp, MonFichier).
Et si c'est lent il faut le mettre dans un thread.

OK dans un thread tu auras la main pour faire autre chose (cas d'un éditeur : sauvegarde temporaire par exemple). Mais dans le cas général où tu souhaite enregistrer un fichier et sortir du processus, le thread ne changera pas le problème de fond qui est que l'opération fsync() prend du temps : il ne paraît pas sain de terminer le processus avant que le fsync() n'ait rendu la main, donc avant que le thread n'ait terminé son travail ; donc on ne gagne pas temps dans ce cas là.

À noter que le rename() final effectue deux opérations d'un coup :
1 - effacer le fichier MonFichier
2 - renommer
Même si 1 et 2 sont atomiques (comme dit plus haut, vu du système, si rien ne crashe), l'opération 1 peut prendre un certain temps selon la taille du fichier et le système de fichiers.

Sauf les plus grands, beaucoup de logiciels libres sont développés sur du temps libre, souvent plus par passion technique que par altruisme et goût des études ergonomiques.
Dans ces conditions, n'exigez pas des développeurs de soigner l'accessibilité, la cohérence, les tests, de traduire les documentations, etc. : tout cela représente une quantité énorme de travail, souvent hors de portée (et de volonté) de la communauté.
Les logiciels propriétaires n'ont pas les même moyens humains et financiers : si le manuel n'est pas traduit, si le logiciel est insuffisant, trop compliqué, bogué, le produit ne se vendra pas (du moins en théorie).
Le logiciel libre est conçu par des techniciens, et c'est vrai, pas toujours orienté vers ses utilisateurs. Mais "à cheval donné, on ne regarde pas les dents". Si vous n'aimez pas les documentations en anglais, il n'y a pas d'autre solution que de les traduire vous-même.

Concernant les pages de man, je les trouve comme tout le monde, indigestes : les options sont placées toutes au même niveau, classées par ordre alphabétique. On doit donc tout lire pour savoir lesquelles employer (alors qu'en général les deux ou trois principales suffisent). Il faut prendre ces pages comme une sorte d'antiquité de référence, pas comme des "how-to". Il vaut mieux connaître déjà la commande avant de lire une page de man... De toute façon, taper "man wget", c'est déjà connaître wget.

Ici Plasma consome rien en cpu sans les effets et pareil une fois les effets activés. Il passe autour de 2% pendant un effet comme exposé puis revient tout de suite autour de 0.

Pendant un effet, c'est plutôt le processus serveur X qui doit consommer du cpu non ?
C'est comme au taf, Il faut pas trop regarder l'application qui commande, mais celle qui bosse :)

À ce propos, quelqu'un connaît-il un moteur de surveillance d'annonces immobilières ?
Des méta-moteurs, on en trouve ; mais des qui gardent l'historique des publications, des prix, etc. je n'en ai pas vu.
Ayant un peu réfléchi au problème, ce n'est pas bien simple.
Si quelqu'un est intéressé par un développement de ce genre...

C'est fini là aussi : subversion en est revenu de bdb, qui nécessitait l'accès en écriture pour faire un check-out, laissait des locks un peu partout, etc.
Il existe encore un flag pour créer un dépôt bdb, mais depuis déjà un bon moment Subversion a inventé sa propre architecture de stockage de dépôt (FSFS), qui fonctionne même sur un système de fichiers NFS.

Quitte à troller, je déclare frozen-bubble largement inférieur à l'excellentissime pengupop : http://junoplay.com
Les deux grosses différences par rapport à fb :
- on peut lancer plusieurs balles en même temps (le jeu devient carrément plus rapide, avec parfois un effet pervers sur le style de jeu)
- le plafond ne descend pas (ce qui génère parfois des parties interminables et épuisantes)

L'autre truc sympa c'est que les parties sont sauvegardées (si au moins un des deux joueurs en enregistré) et peuvent être revus en flash.

D'expérience, on a du mal à revenir à la vitesse lente fb quand on joue bien à pengu.
Il y a probablement moins de joueurs pengu, donc parfois on attend un adversaire un moment...

Justement, il ne faut pas tamponner dans ce cas, mais opérer directement avec les appels système open / write (puisqu'on dispose déjà d'une grande quantité de données).
L'utilisation de open(O_DIRECT) a de multiples contraintes, mais pourrait être envisageable (à voir, économise une copie mémoire...).

Pour "flusher" un fichier ouvert avec fopen(), c'est plutôt fflush() que sync. flush() envoie les données de l'espace utilisateur vers le noyau.

"sync" n'est pas flush : sync écrit les données encore en RAM sur le support physique, pour TOUS les systèmes de fichiers : c'est très lourd (il existe fsync() pour faire cela par fichier). En l'occurrence, je ne sais pas si c'est ce que cherche à faire fabricius ?

Deux threads suffisent : un premier qui fait select() ou epoll() sur les sockets + remplit la ram, et un second qui vide la ram sur le disque (modèle classique producteur / consommateur).
Sauf architecture SMP, je ne pense pas que davantage de threads permettent de gagner en performance...

Ben justement la version 1.5 était attendue depuis longtemps pour cela, simplifier les merges en conservant des informations sur ce qui a déjà été intégré.
Comme c'est très complexe (et qu'ils ont placé la barre très haute je crois) il n'ont pas pu tout faire encore. Mais dans les cas standard, c'est simple :
http://blog.red-bean.com/sussman/?p=92

J'ai écrit 2 scripts pour faire cela :
saveToKey.sh et keyToDisk.sh

Ils utilisent rsync et marchent assez bien, mais pas aussi bien que tu le demandes. Car tu cherches à synchroniser les choses dans les deux sens, ce qui paraît difficile à faire en cas de suppression/ajout de fichiers (il y aussi le projet unison je crois qui est censé faire cela)
En pratique, il faut penser à :
- lancer keyToDisk lorsqu'on se loggue sur une machine et récupérer localement les dernière modifs qui sont sur la clé
- lancer saveToKey lorsqu'on a fini de travailler, pour tout sauver sur la clé.

rsync fait des sauvegardes incrémentales donc c'est en général rapide, on peut exclure des fichiers d'après certains noms, etc.

Ils sont un peu longs pour être postés ici, mais je peux les envoyer à qui est intéressé...

Bonjour,

Moi aussi j'ai fusillé un écran crt "récent" (2003) peu après avoir installé (je me demande encore pourquoi !) le driver propriétaire nvidia. L'image était correcte, les fréquences également. Mais après environ une ou deux semaines, elle était déformée et violette. Était-ce une coïncidence ?
Heureusement j'ai pu faire jouer la garantie (l'écran avait 12 mois d'âge), et j'ai vite remis mon driver standard dans xorg.conf (ou XFree86Config à l'époque).

farvadin : "Par contre ce que je reproche un peu à digikam c'est qu'il ne semble pas possible de faire des albums virtuels..."
Je connais peu digikam, mais comme tu dis ça doit être faisable par des étiquettes (un peu bidouille quand même).

Je voulais vous parler d'un script que j'utilise pour faire tirer mes photos (environ 1 photo sur 10) : j'ai créé des étiquettes 'aTirer' et 'aTirer2Fois' dans digikam, et ces tags se retrouvent dans la base sqlite. Ensuite un simple script python permet de "sortir" (copier) les images ayant un tag donné dans un répertoire temporaire qui contient in fine toutes les photos à tirer (avec des doublons pour aTirer2Fois).
Le script est peut-être un peu long pour être posté ici, les curieux peuvent me le demander. C'est plutôt pratique je trouve... Après la copie, je préfère revenir sous digikam pour filtrer les images à tirer, leur enlever le tag, et le remplacer par le tag 'tirée' (ceci devrait être fait fonctionnellement par le script, mais je n'ai pas osé écrire dans la base ; en outre l'opération est rapide sous digikam)

Ce ne serait pas plutôt : (en étant actuellement à la rev 907)
svn merge -r 907:906 . (dans l'ordre inverse)
puis commit
??

Je me réfère l'incontournable, ici :
http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuse(...)

Vérifie que tu as bien #include <pthread.h> et <signal.h>, dans cet ordre.
Essaie de linker également avec l'option -lrt : je crois que pthread_kill() fait partie des extensions temps-réel de posix qui, dans le domaine des signaux multithreadés, sont ce qu'il se conçoit de plus simple -- pour placer des bugs dans le code s'entend.
Sinon je ne vois pas d'autres pistes ? Le fait que ton linker connaisse le type des arguments de la fonction manquante me fait penser à un problème de C/C++. pthread_kill() ne serait pas déclarée extern "C" ??

Enfin si : supprimer les appels à pthread_kill() et pthread_cancel() de ton code : en plus de lier correctement, tu enlèveras des bugs. Ou alors, sois paranoïaque et relis cinq fois la documentation. Le livre "Programmation système en C sous Linux" de Blaess (une référence) décrit très bien les problèmes auxquels on s'expose avec ces p*** de fonctions, et comment les éviter (c'est quasi impossible).

Concernant l'OCR, il faut signaler deux projets relativement nouveaux en libre qui changent la donne :
ocropus : http://code.google.com/p/ocropus/
signalé ici sur linuxfr : http://linuxfr.org/2007/05/18/22513.html
Le moteur d'ocropus est temporairement tesseract :
http://sourceforge.net/projects/tesseract-ocr
sur linuxfr : http://linuxfr.org/2006/10/07/21437.html

On ne rêve donc pas, ça bouge dans le domaine...

Attention aux caractères foireux dans les noms de fichiers (espaces, guillemets, etc. -- enfin pour pas être malin pour mettre des guillemets hein, mais sur des partages samba tout peut arriver :) !

Pour utiliser xargs de manière plus robuste, il faut demander à ls de quoter/échapper les noms avec -Q (sinon xargs peut couper le nom en deux et rechercher deux fichiers distincts) :
ls -Q | grep A | grep -v B | grep .C | xargs rm --

Si on fait un find (cas plus général ?), alors :
find . -name "toto" -print0 | xargs -0 do_something --

La doc de xargs indique bien ce problème potentiel [ avec une typo dans ma version, ils parlent de l'option -O mais c'est bien -0 (zéro) ]

Quand au script avec la boucle 'for' quelques message plus haut, il souffre du même problème et ne fonctionne pas si un nom de fichier contient un espace : le for va faire deux boucles avec les portions de nom...
Ah les joies du shell ! :(

On m'en avait dit du bien, je l'ai acheté mais pas trop lu en fait (!).
Ce livre est connu, mais plutôt orienté "mise en pratique" que théorie UML pure.
Une nouvelle édition parle de UML 2.

la syntaxe est similaire, mais pas toujours l'effet :
en C sur archi 32 bits 1<<31 vaut -2147483648
en python : 1<<31 = 2147483648L
et aussi 1<<128 = 340282366920938463463374607431768211456L en python, ce qui est tout de même beaucoup plus sympathique qu'en C : 1<<128=0 :)
Je crois que depuis un moment en python, les entiers ne peuvent pas déborder : ils sont étendus au besoin. C'est pratique, mais tout dépend de ce qu'on veut faire : des maths ou de l'informatique...

Oui, si j'ai bien compris aussi, clamAV échouerait à détecter de tels virus polymorphes (puisque la signature change potentiellement à chaque infection).
Pour ce genre de bestioles, il semblerait que les anti-virus "récents" (depuis Kaspersky, qui a inventé le concept) utilisent l'émulation de code et fassent un "profilage" sur l'utilisation mémoire, les JMP, la détection de déchiffrage de code, etc. : tout cela est très coûteux en cpu.

Mon avis sur le magazine ; si vous avez déjà une petite culture sur les virus, cela ne vaut peut-être pas l'achat. Je suis personnellement un peu resté sur ma faim. Seul l'article sur le polymorphisme vaut le détour (description du virus MetaPHOR). Après sa lecture on est tenté de penser que les virus ont encore une belle carrière devant eux... Je cite même :
"En somme, si les créateurs de virus étaient moins pressés et peaufinaient leurs techniques, la communauté antivirale pourrait être vite dépassée. Une utilisation avancée des techniques de polymorphisme (...) peut théoriquement rendre le problème de la détection d'une complexité rédhibitoire, voire indécidable."
Brrr...