Troy McClure a écrit 2213 commentaires

Nan j'ai pas eu le courage d'essayer, pour l'instant le laptop tourne à côté d'un pc suffisament bruyant pour que je n'etende plus ce sifflement ;)

Parmi les quelques liens que j'avais trouvé, celui-là:
http://groups.google.fr/groups?hl=fr&lr=&ie=UTF-8&oe=UT(...)
suggère "apm=idle-threshold=100" .. pas essayé non plus

c'est pas ce que j'ai dit !

pareil sur mon latitude D800 ! d'après ce que j'ai vu, ça serait du au passage du HZ à 1000 sur les 2.6, lié à une histoire d'apm http://kerneltrap.org/node/view/1766(...)

Le bruit du mien n'est perceptible que lorsque la machine est idle, dès que le cpu tourne un peu le sifflement (très aigu) cesse. Et il ne commence que lorsque le serveur X est démarré.

c'est prévu ! http://gcc.gnu.org/ml/gcc/2003-02/msg01911.html(...)

Glorieux Archimède, artiste ingénieux,
Toi de qui Syracuse aime encore la gloire,
Soit ton nom conservé par de savants grimoires !
Jadis, mystérieux, un problème bloquait
Tout l'admirable procédé, l'oeuvre grandiose
Que Pythagore découvrit aux anciens Grecs.
O quadrature ! vieux tourment de philosophe !
Insoluble rondeur, trop longtemps vous avez
Défié Pythagore et ses imitateurs.
Comment intégrer l'espace plan circulaire ?
Former un triangle auquel il équivaudra ?
Nouvelle invention: Archimède inscrira
Dedans un hexagone; appréciera son aire
Fonction du rayon. Pas trop ne s'y tiendra:
Dédoublera chaque élément antérieur;
Toujours de l'orbe calculée approchera;
Définira limite; enfin, l'arc, le limiteur
De cet inquiétant cercle, ennemi trop rebelle !
Professeur, enseignez son problème avec zèle !...

mais il a aussi des avantages, bien sur la portabilité, le fait que ce soit une suite de compilateurs (c,c++,ada,fortran,objC,..). C'est aussi un des rares compilos c++ à fournir des messages d'erreurs complets (i.e. qui permettent après 10 minutes de reflexion et de recherche dans un message de 500 lignes de trouver à quel endroit se situe le probleme), icpc par exemple est bien moins loquace. Pareil pour les warnings, ceux de g++ sont judicieux alors que ceux de icpc (ou cxx, ou le mipspro..) sont soit trop nombreux et inutiles, soit trop peu nombreux. Il est aussi (pour ce que j'en ai vu) moins buggué que icpc. ET il est internationalisé ! (ok ça c'est plus une connerie qu'autre chose)

Et la prochaine version apportera le tree-SSA, j'aurais bien du mal à expliquer le pourquoi du comment, mais visiblement les dev de gcc ont beaucoup d'espoir dans ce truc qui devrait permettre plein de choses, entre autres de faire des optimisations impossibles à l'heure actuelle

http://open64.sourceforge.net/(...)
(version open-source des compilos sgi pour ia64)

sapusaipaslibre :o

La lenteur de g++ est effectivement un gros problème. D'après les benchs publiés sur la ml de gcc ( http://gcc.gnu.org/ml/gcc/2004-04/msg00913.html(...) par ex) il y a eu de gros progrès avec la 3.4, en particulier pour l'edition de lien en '-g' (faut dire que la 3.3 partait de loin..)

Par contre icpc (le compilo c++ d'intel) reste encore 2 fois plus rapide à compiler, genere un code 15% plus performant en moyenne, et des executables sensiblement plus petits. La future version de gcc (3.5 ou 4.0 c'est pas encore décidé) changera peut-etre la donne..

> Est tu sur que opendx ne fait pas de sortie postscript ?
Ouais, j'avais posé la question sur la mailing list il y a quelques années. Ils l'ont peut etre rajouté depuis, mais j'en doute. J'imagine qu'il faudrait pouvoir brancher gl2ps sur opendx

Pour la doc d'opendx je suis d'accord, elle est pas si mal que ça.

Mais il n'est pas utilisable de façon automatique, non ? (mettre toutes les commandes à executer dans un script et lancer le script pour obtenir la courbe)

Pas à ma connaissance.. python + numeric est assez sympa. Lush ( http://lush.sourceforge.net/(...) ) aussi, mais j'ai jamais essayé et le lisp ça fait peur

opendx est pas mal du tout, tu l'as déjà essayé ? contrairement à vtk, c'est juste une appli, pas une bibliothèque, et il a un milliard de fonctionnalités de plus que mayavi par exemple. Moi j'aime bien, mais on s'éloigne de plus en plus de gnuplot, parce que ni lui, ni vtk (sauf avec gl2ps) ne font des sorties en postscript ou tout autre format purement vectoriel, ce qui est la moindre des choses que je demande quand je plotte y=f(x) !

Et lui au moins il propose autre chose qu'une doc doxygen bien indigeste pour le pékin qui veut juste essayer le bousin :P

le probleme de vtk c'est qu'il faut payer pour avoir la doc :-/ et c'est quand même nettement plus complexe qu'un simple traceur de courbes

Je crois que c'est pas une macro classique mais un truc geré par moc, comme pour les histoires de signaux et slots dans qt (enfin c'est juste une hypothèse)

Sinon en termes de lisibilité (et de simplicité) je préfere quand même un foreach, même si c'est une sale macro :)

\o/ des ameliorations pour la couleur ! Si ça veut dire qu'on va enfin pouvoir éviter les couleur vga, et en particulier la courbe jaune et la courbe verte qui apparaissent dès qu'on a plus de 2 courbes sur le même graphique, alors ça roxor. Parce que c'est un grand classique, le graphique gnuplot qu'on presente en s'excusant "ah ben on voit pas très bien la courbe jaune, mais elle est là"

nan, il y a std::for_each, mais c'est lourdissime à utiliser (il faut lui passer en argument la fonction à appliquer à chaque element du conteneur). Et si on veut faire une boucle for (;;) classique, alors il faut pouvoir declarer des iterateurs sur le conteneur, et leur type est bien souvent un truc monstrueusement long. Le foreach à la Qt permet d'eviter ces deux problèmes.

Le coup du foreach de Qt4 pour faire des choses du genre

foreach (QString s, list)
sum += s.length();

est bien sympathique aussi, c'est vraiment dommage que le c++ (standard) ne permette pas de faire ça.
Dans les commentaires de slashdot, j'avais quand même reperé un lien vers http://www.nwcpp.org/Meetings/2004/01.html(...) qui a l'air de décrire un moyen de faire le foreach sans passer par typeof (avec de grosses gruikeries sur les templates).

ok, je change "ils auraient pu" par "c'est dommage que"
Mais la critique sur le choix des noms reste tout à fait valable, à mon avis.

par contre en terme d'ergonomie il fait un peu peur "display" et je le trouve monstrueusement lent. J'aime pas du tout ce truc en fait. Puisque j'en suis à raler, j'aime pas du tout non plus ces noms débiles: "display", "convert", "import", "animate", etc. (à part mogrify, ça veut dire quoi ça ?), ils auraient pu faire l'effort de choisir des noms d'utilitaires un peu plus cohérents et un peu moins génériques, ça me fait penser à ce thread d'ailleurs:
http://lists.debian.org/debian-devel/2004/debian-devel-200403/msg01(...)

si tu ne recuperais que le pointeur renvoyé par localtime ou gmtime, c'est un pointeur sur une variable statique quelque part dans la glibc, donc si il y a d'autres appels à ces fonctions dans ton code ou dans une lib, le contenu du bouzin sera modifié, il faut que tu recopies tout dans une struct tm locale à ton programme (par ex. en utilisant localtime_r ou gmtime_r)

c'est vrai que c'est pas mal du tout, mais la completion déconne dans mon xemacs :-/

Sinon gdb 6.1 vient d'arriver dans ma deb. unstable et il contient un 'gdbtui' qui a tout l'air d'être une interface curses :) (et qui était auparavant dans le package de insight, donc c'est pas vraiment une nouveauté)

Pareil, gdb reste quand même plus commode (et demarre plus vite) pour chasser un petit bug vite fait, qui se résume souvent à

gdb --args toto -plop
(gdb) r
prouf segv
(gdb) w
(gdb) p le_truc_suspect
(gdb) q

D'autant que les interfaces ont quand même une petite tendance à exploser en vol: c'est bien pratique d'afficher la valeur d'une variable ou expression qu'on survole à la souris dans une petite bulle, mais quand ça declenche l'évaluation d'une fonction qui crash, cl'interface part bien souvent avec.

Sinon j'aime bien insight, quand il marche. Mais gdb+insight est quand même un des softs qui a le plus de "variations de bugs" entre les releases.. y'a toujours un petit truc qui cloche. Un coup c'est valgrind qui n'arrive plus à attacher gdb, un coup les exceptions du c++ le font planter, un coup il marche avec icc, ou pas.

Finalement c'est une interface curses pour gdb qui me plairait, je crois que j'en avais vu une en version 0.0.1 il y a quelques temps

Et attention c'est pas fini, accroche toi bien au pinceau: wmhdplop 0.9.4 fout un gros coup de pied au cul de wmhdplop 0.9.3 comme expliqué issite: http://hules.free.fr/wmhdplop/(...)

Bonjour,
J'utilise moi-même wmhdplop depuis près de 15 ans (à l'époque, le core était écrit en COBOL avec une interface FORTRAN 66). Il tourne actuellement sur mon cluster heterogene haute performance z80-ia64-amiga (piloté par la SuSE Linux Standard Server 8 TrialWare Edition) et j'en suis entièrement satisfait. Depuis que j'ai upgradé en version 0.9.2 ma femme est revenue, la gauche a remporté les elections, et mon chien n'essaye plus de me sauter à la gorge.

J'encourage tous les jeunes de notre pays à essayer ce logiciel aux vertus multiples.