Troy McClure a écrit 2213 commentaires

Sissi c'est bien matlab dont l'IDE est en java; d'ailleurs quand on le lance avec l'option -no-jvm on est réduit à la ligne de commande (et il démarre 3 fois plus vite, c'est formidable). Maple était en un truc qui ressemblait à Motif (pourri, mais rapide) la derniere fois que j'ai testé

je vais faire mon vieux con, mais quel interet ? L'interface graphique de matlab est la honte des interfaces graphiques, un modele de lourdeur et de laideur. D'ailleurs elle est écrite en java.

Ce qui manque encore à octave à mon sens, c'est une vrai bonne emulation des graphiques de matlab (2D *et* 3D). Pour l'instant c'est un truc tout batard qui utilise gnuplot (la honte des grapheurs libres, avec un coefficient souplesse/nombre d'options proche de 0) via des pipes bien lents. Pas que les figures de Matlab soient un modele en matière de rapidité ou de conception, mais ça "juste marche"

d'une part le code d'assert termine normalement par un exit donc ça crash forcément. D'autre part l'assert étant placée pour tester un cas n'apparaissant normalement pas, l'application crachera de toute manière juste après ou un peu plus loin, ou beaucoup plus loin mais on ne saura jamais pourquoi...


Si la fonction assert affiche une belle boite de dialogue (c'est ce qui se passe sous windows par ex) indiquant que "assertion failed dans toto.c ligne 42 sur l'expression prout==0" alors l'utilisateur qui vient de voir son appli exploser en plein vol va t'envoyer un mail ou tout surpris il t'expliquera avoir reçu un message incomprehensible à propos de prout à la ligne 42. Et si t'as de la chance, tu peux identifier le bug sans sortir de logs ou quoi que ce soit. C'est quand même mieux qu'un programme qui crash sans rien dire je trouve

Et ça doit crasher, les asserts doivent crasher pendant le dev et ne seront de toute manière pas compilées (ou seulement le log sera compilé)

ça me laisse toujours un peu perplexe de virer les asserts en production, qu'est ce qui se passe dans l'eventualité ou un bug est passé a travers ? Au lieu d'avoir un plantage bien franc tu auras au mieux un bon crash bien net, au pire des données corrompues difficiles à identifier. Alors pourquoi ne pas toujours laisser les assert ? L'argument du gain de performances me semble très contestable dans l'immense majorité des cas.

si ils sont sûrs du concept, pourquoi ne continuent-ils pas de vendre online en parallèle du CD distribué

Peut etre parce qu'ils ont constaté que la plupart des gens étaient des crevards et ont choisi de telecharger sans rien donner ?

Et quelles sont les situations où tu as besoin de voir simultanement le contenu de deux fenetres ? Moi je n'utilise que des wm classiques, toutes mes applications sont maximisées (à part les trucs multifenetres un peu relou comme the gimp) et je ressens très rarement le besoin d'avoir deux fenetres différentes affichées en même temps

En l'état, sur une machine normalement chargée, je trouve que jack (ou alsa tout court) marche très bien sans recourir à des patchs 'temps reel dur'. De même windows et macos s'en sortent très bien pour faire de l'audio a faible latence et pourtant ils ne sont pas "temps reel dur"

Quelle est l'utilité du temps reel dur sur une distrib orientée desktop ? un temps reel mou ou semi-dur n'est il pas suffisant pour la plus exigeante des madames michu ?

Je pense que si on donnait le même budget à une équipe de développement de jeux libre qu'à une équipe faisant des jeux propriétaires, que si les drivers des cartes graphiques étaient libres et donc de bonnes qualités, alors on aurait des jeux de la "qualité" que tu cherches.

Mais avec des tux.

on tourne en rond, mais y'a plein de détails moches ou ratés dans http://www.kde.org/announcements/announce_4.0-beta3/plasma.p(...)

- les icones baveux dans la taskbar, du texte tronqué à la machette -- bon je ne vais pas reparler de la couleur de la taskbar et de l'horloge mais ça me demange

- le manque d'homogeneite de l'ensemble: des elements sont ombrés, d'autres non. Celui qui détonne le plus c'est la jauge de batterie qui a une charte graphique totalement differente du reste

- le quart de cercle bizarre en haut a gauche est tout aliasé: c'est moche

bah j'ai quand même illustré avec deux images. Alors en effet, elles ne montrent pas une de ces belles toolbars dont kde est friand (bon, microsoft aussi, je l'admets, depuis que j'ai vu office 2007 j'en fais des cauchemards), mais elles illustrent très bien les détails "moches ou ratés":

- la taskbar du premier: la couleur est juste à vomir, independamment de "les gouts et les couleurs blahblahb" je pense que personne de bonne foi ne pourra dire le contraire. Mais passons. L'horloge (oui je fais un blocage sur les horloges) est juste moche et kitch. Mais le détails qui tue, pour moi, c'est les problèmes d'espacement: le K du menu démarrer est completement collé à l'icone 'systeme settings', y'a 0 pixels de marge !

- deuxième image: y'a plus d'horrible taskbar, donc c'est un peu mieux. Le look est clairement inspiré de vista, perso j'aime pas trop mais c'est une question de goût. Par contre l'icone de la batterie fait juste bizarre, le look ne s'integre pas du tout au reste. Mais le truc qui fait le plus raté c'est bien l'horloge (oui oui), moi ça me fait halluciner: on voit qu'il y eu un temps fou passé à paufiner une belle horloge que j'imagine faite en rendu vectoriel, avec du svg et de l'antialising partout. Et tout ça est gaché par les fontes mal positionnées ou trop grosses, tous les chiffres sont mal placés !

Voilà pourquoi je dis que kde pêche dans les détails.

Et ce ne sont pas deux images prises au hasard, on les a vues partout lors de l'annonce de la beta de kde 4. Moi je ne comprends pas qu'on puisse faire la promotion d'une nouvelle version de kde avec des screenshots aussi mauvais.

franchement c'est un peu gonflé de dire que c'est un aspect macos:
http://wiki.archlinux.fr/_detail/kde:kde_macos.jpg?id=kde%3A(...)

A mon sens tout est dans les détails, et avec kde y'a toujours un détail qui cloche. Là par exemple l'horloge en faux-lcd c'est la faute de gout ultime que jamais Steve Jobs ne commetrait. En plus kde doit la trainer depuis la v1.0 cette horrible horloge

pas tout a fait:
SSE = simple precision seule, flottant ou scalaire, *avec* les operations logiques et les comparaisons. Pour les entiers (64bits max), il faut passer par le mmx.

SSE2 ajoute les entiers (on n'a plus besoin de mmx) , et la double precision

SSE3 ne sert à rien, ni SSSE3, SSE4a, ... (intel a un certain talent pour empiler les multiples revisions qui n'apportent à chaque fois quasiment rien de nouveau mis a part des trucs hyper specialisés pour decoder du h264 ou je ne sais quoi)

Pour moi, SSE et x87 n'ont pas du tout la même finalité. En SSE, tu manipules des blocs de 128 bits, sur lesquels tu effectues des opérations « vectorielles ».

Mais pas seulement, toutes les instructions sse vectorielles ont un pendant scalaire (qui ne manipule que le premier element de ton petit vecteur, et qui n'a pas les contraintes d'alignement mêmoire des instructions vectorielles), on peut donc se passer totalement du x87 sans avoir de penalité de performance (c'est d'ailleurs ce que fait gcc quand on lui indique fpmath=sse : il remplace les instructions x87 par du SSE scalaire , il ne vectorise rien). Sur x86_64 , et sur darwin/intel, le x87 est d'ailleurs banni.

C'est encore la supériorité de la fpu x87 par rapport à SSE. Le x87 contient toute la trigo en hardware, contrairement à SSE. D'ailleurs, AMD était connu pour avoir une implémentation x87 musclé par rapport au processeur Intel qui favorisait plutot le SSE. Cela se voyait dans certain tests "scientifiques".

Elle est quand même très relative cette supériorité: les instructions trigo hardware sont plus lentes que les implémentations equivalentes SSE (et elles n'ont pas la précision ieee)
(moment pub: http://gruntthepeon.free.fr/ssemath/ )

rassure toi, je suis persuadé qu'à l'arrivée tu auras tes 5 rangées de quarante-deux icones dans les barres d'outils, comme savent si bien le faire les devs kde :). Entre les interfaces fouillies et sur-remplies d'icones, et les détails moches ou ratés qui traduisent un mauvais-gout assez omnipresent y'a des choses qui ne changent pas (cf par exemple la taskbar en bas de http://upload.wikimedia.org/wikipedia/commons/5/54/KDE_4.png ou bien l'horloge de http://upload.wikimedia.org/wikipedia/commons/4/42/Kdebeta2_(...) )

Justement c'est quand il n'y arrive plus que ces nombres arrivent, cad quand l'exposant est déjà à sa valeur minimum: ieee impose de pouvoir representer ces nombres très petits (cad ceux compris entre 1e-39 (2^-127) et 1e-46 (2^(-127-23))). En pratique ils ne servent à rien, à part à faire des "bugs" bizarres parce que les fpu ne sont pas du tout optimisés pour manipuler ces nombres (voire c'est gérè en soft), ça fait des ralentissements typiquement d'un facteur 1000 (mais comme tu le disais dans le journal, c'est souvent pareil pour les Nan et les inf)

Juste pour préciser, dans mon post je ne voulais pas dire qu'on peut ignorer les erreurs d'arrondi, je parlais juste des "rounding mode" du fpu, tel que décrit ici http://en.wikipedia.org/wiki/IEEE_754#Rounding_floating-poin(...)

D'ailleurs Java ne supporte que le "round toward zero", ce qui suggère que peu de gens ont besoin des 4 prescrits par la norme ieee

Si on reste sur PC x86, il y a les instructions x87, le SEE et les nombres sur 32, 64 et 80 bits, tout sachant que Intel calcule en interne sur 80 et non 64 bits pour les double au contraire de AMD.

les 80 bits du fpu ont du plomb dans l'aile puisque sur x86_64, tous les calculs se font en SSE2, cad en 64 bits maxi. Je ne sais pas historiquement quelle était la raison pour intel d'avoir 80 bits dans ses copro, mais en pratique ça a causé beaucoup plus d'emmerdes que ça n'a résolu de problèmes ( c'est bien pour ça qu'il y a une option -ffloat-store dans gcc pour les gens qui veulent des calculs conformes ieee)

J'imagine que c'est la démarche des codes scientifiques pour éviter d'utiliser des nombres étendus plus lent.

En général c'est double précision pour tout le monde, si cette précision ne suffit pas alors la bonne approche est de modifier l'algo plutot qu'utiliser des nombres avec une plus grande precision.

D'ailleurs comment choisi-t-on d'utiliser un type d'arrondi plutôt qu'un autre ?

Franchement je crois que tout le monde s'en fout mis à part deux trois psychopathes obsedés par ieee :)

Quel est l'intérêt de gérer les NaN ou les infinis qui ralentissent tellement un code c ?

Clairement detecter les erreurs de programmation, les divisions par 0, les sqrt(-1e-16) etc. Un autre truc qui ralentit monstrueusement le code c'est les nombres denormalisés, tous ceux qui font du traitement du signal avec des filtres récursifs en font l'experience un jour ou l'autre.

> Par rapport à ton cahier des charges, c'est simple : BSD.
Tu n'aurais pas eu de question de Novel, personne pour t'emmerder puisque tu donnes tous les droits.

Non. C'est n'est PAS simple. C'est bien ce que je reproche (et relis, ça ne correspond pas à mon cahier des charges).

> Désolé, mais sans mise par écrit, point de connaissance sur ce que tu veux faire.

Oui merci j'avais bien compris. Je râle contre la complexité des questions de licenses mais je n'ai jamais nié leur necessité.

> "GPL2 or later". (Ou BSD suivant tes convictions)

ou LGPL si tu fais une lib et que la GPL te semble un peu overkill... ou LGPL + exception si tu fais une lib c++ parce qu'il y a du code dans les headers.. Donc non ça n'est pas simple. Et oui ça fait chier. Quand je fais du code libre je n'ai pas envie de passer des jour à peser le pour et le contre, et je n'ai pas envie qu'on revienne me gonfler 3 ans plus tard parce que la license que j'avais choisi n'est pas compatible avec trucmuche-license et que ça embete Toto qui voudrait utiliser mon code.

Faut pas se leurrer , tout le monde n'est pas parfaitement informé au moment où il choisit la license du logiciel qu'il va diffuser. C'est souvent un choix par défaut "allez hop on va prendre la GPL", on n'apprend tous les effets de bords un peu subtils après (quoi la LGPL nécessite une close d'exception pour le code contenu dans les .h sinon elle equivaut a la GPL ?)

Quand je distribue du code libre c'est dans l'espoir que des gens le trouvent utile et que ça leur fasse gagner du temps. Je le redis: ça ne m'interesse pas de lire ces trucs compliqués et indigestes que sont les licenses.

Un exemple: avec un collègue on avait fait une lib qui se trouvait etre diffusée sous LGPL 2 (sans le "later"). Je n'ai absolument aucun souvenir de la discussion qui nous avait ammené à ne pas mettre le "or later", c'est peut etre une erreur de copier-coller , ou une mauvaise compréhension, j'en sais rien. On voulait juste la distribuer librement, et que si des gens font des modifs, qu'on puisse en profiter. Un type de novell (qui visiblement passe ses journées à chasser les bugs de licenses) nous a contacté il y a une semaine pour nous demander d'expliciter la license qui était LGPL 2.1 dans les sources, alors que la page web pointait vers lhttp://www.gnu.org/licenses/lgpl.html . Il nous a ensuite demandé si on souhaitait ajouter le "or later" parce qu'un soft KDE dépendait de la lib, et donc ça foutait la merde. Résultat tout le monde a perdu du temps, on a fait le changement de license parce qu'on a peu de contributeurs et qu'ils ne sont pas morts, mais franchement, c'est lourd et chiant.

Ben j'en ai pas (a part BSD pour tout le monde). Comme il y a ici beaucoup de gens qui semblent prendre un immense plaisir à pinailler pendant des heures sur les vertus de telle ou telle license, c'était juste l'occasion de rappeller que pour d'autres, la multiplicité des licenses et la complexité de leur interaction n'est pas une source de joie et félicité, mais plutot d'emmerdes et de mal de crâne.

Comme peu de monde semble abonder dans le sens de l'auteur de ce journal, je me permet moi aussi de manifester mon ras-le-bol sur le sujet des licenses libres.

C'est peut etre un mal necessaire, mais c'est un sujet incroyablement chiant, complexe, et bien trop omniprésent ces derniers temps. Moi ça me gonfle de passer du temps à lire la GPL3, l'AGPL3 etc pour comprendre ce que je peux faire et ne pas faire.

Ce genre de sujet c'est vraiment un "tue-l'amour" pour les gens qui ont envie de faire, ou d'utiliser du logiciel libre.

Impressionnant comme document, j'ose pas imaginer le temps que ça lui a pris à réaliser. Il utilise oprofile pour faire les profils, est-ce que beaucoup de gens arrivent à l'utiliser et à en sortir des choses interessantes ? A chaque fois que j'ai essayé ça a été un lamentable echec, c'est vraiment loin de marcher "en dehors de la boite".. Dommage qu'il n'y ait pas d'outil de profiling du niveau de Shark ( http://developer.apple.com/tools/sharkoptimize.html ) sous Linux, c'est vraiment un must en matière de puissance et de simplicité d'usage.

Un exemple simple : un gros sujet d'actualité tombe. 3 dépêches arrivent dans un intervalle de quelques heures.

Le problème c'est que ça n'arrive plus, justement :)