Sebastien Binet a écrit 524 commentaires

package RIO de [...]
Ca a pas l'air mal.
L'interface ressemble furieusement a AIDA (ce qui n'a rien d'etonnant puisque G. Barrand fait egalement partie de l'equipe de devs).

Par contre je me demande si la partie dictionnaire est vraiment utile, puisqu'avec ROOT 5 la fusion avec le mecanisme de generation de dictionnaire de LCG/SEAL[1,2] est entamee...
Enfin, ca vaut le coup de garder un oeuil dessus : merci pour le lien :)

[1] http://seal.web.cern.ch/seal/(...)
[2] http://seal-reflex.web.cern.ch/seal-reflex/index.html(...)

Mais franchement à part dans notre secte de physiciens ('HEP') est-ce que ROOT est utilisé ailleurs ?

Et oui... C'est surtout utilise par les gens qui font de l'imagerie medicale. Generalement ce sont des anciens physiciens des particules qui ont senti faiblir la branche sur laquelle ils etaient assis et ont donc operes une conversion...
En fait ce qui est utilise c'est Geant4[1] pour la modelisation des depots d'energie et une surcouche ROOT pour la visualisation ou alors juste pour le stockage des donnees. Exemple : GATE[2]

Sans doute egalement des astrophysiciens (mais ce sont des cousins :P )...

[1] http://geant4.web.cern.ch/geant4/(...)
[2] http://www-lphe.epfl.ch/~PET/research/gate/physics/petbench.html(...)

Pas de probleme, j'y mets ou ? :P

y'aura jamais les column wise ntuple
Ca j'aimerais bien qu'on m'explique pourquoi.
Enfin surtout, pourquoi on les a laisses tomber...

Dans ATLAS on s'en sort grace au framework Gaudi qui nous permet d'avoir un pseudo CWNT (je dis pseudo parce que 1) je n'ai pas regarde exactement comment c'etait fait 2) comme c'est du ROOT derriere...) mais ce serait tellement plus simple si on l'avait directement (surtout dans une session en interactif)

Heureusement, il y a la GSL, GnuPlot, et mathlab (sic !)

Je rajouterais : il y a R et Octave ;)

http://www.r-project.org/(...) (down a l'heure ou j'ecris ces lignes)
http://www.octave.org/(...)

J'annonce la couleur (cf titre).

Au debut j'aimais bien ROOT. C'etait fun, tu penses bien, apres avoir programme en FORTRAN et en KUMACs (langage de script pour PAW, le papa de ROOT), jouer avec le C++ c'etait bien (TM).

Le probleme c'est que ROOT a ete ecrit au debut par l'auteur (R. Brun) de PAW. Comme aux debuts de tout programmeur dans un nouveau langage, la premiere version merite toujours un rm -rf bien senti.
Cependant, cette reorganisation de ROOT n'a pas ete menee.

Du coup on se traine des methodes de programmation qui datent des annees 90 avec un arriere gout Fortraneux des plus desagreable ainsi qu'un design des classes relativement discutable.
D'ailleurs une multitude de choix sont discutable.

Tout d'abord, laisser a un physicien ecrire des macros C++ pour l'interpreteur (CINT) est une grosse boulette. Le profil type du physicien qui va utiliser ces macros est le nouveau switcher depuis FORTRAN/PAW. A force d'essayer de lui faciliter la transition (ce qui est une attention louable en soi) on lui donne de mauvaises habitudes (on peut ecrire des horreurs qui piquent les yeux avec cet interpreteur! du genre double hyp = a**2+b**2;).
Personnellement, je n'utilise jamais cet interpreteur : je prefere de loin utiliser le prompt de python et charger les objets ROOT qui m'interessent.

Avec ROOT 5, on commence a avoir un support a peu pret correct de la STL.
Cependant, dans la majeur partie des cas (remplissage de tuples par exemple) il faut toujours passer par des tableaux "a la C", je pense que la perte de performances (combien d'ailleurs?) ou l'overhead induit par les conteneurs de la STL sont un compromis plutot honnete par rapport au gain en "sûreté"!

Design objet : ben, oui parce que ROOT ca veut dire "the Root of all Objects : an object oriented data analysis framework".
Le probleme ici c'est que certains choix de l'arbre d'heritage me laissent dubitatif : est-ce qu'un histogramme 2D est vraiment une specialisation d'un histogramme 1D ? Ou dit autrement, est-ce qu'un cercle est vraiment une sorte d'ellipse[1] ?

Un autre gros probleme : la separation du stockage des donnees et de leur representation. Dans le cas general, ca n'existe pas. L'objet servant a representer les donnees, contient egalement ces memes donnees. Du coup on est un peu gene aux entournures.
Ex: si je veux etre absolument sur que les donnees de mon histogramme ne seront jamais modifiees, je vais mettre mon histo const. Mais alors je ne pourrai pas changer le style de mes points ou la couleur des barres de d'histogramme !
On se retrouve alors a faire des copies d'histogrammes completement superflues !
Corrollaire: la constness de ROOT est une notion vaguement saupoudree dans les classes.

Et le grand final : les options que l'on peut passer aux objets.
C'est simple, tout se fait avec des chaines de caracteres :
histo->Draw("b,s,p");
Detail : ces options ne sont pas documentees (ou tres mal : use the source Luke!)

Bref, mon avis personnel est que ROOT est une usine a gaz dont le design complet est a revoir, meme s'il faut reconnaitre que les bibliotheques mathematiques n'ont pas a rougir face a GSL.

Des solutions comme HippoDraw[2] ou AIDA[3] me semblent avoir des bases plus solides et reposer sur des concepts plus robustes pour faire ce qu'on leur demande de faire.

Heureusement qu'il y a PyROOT pour faire passer la pillule.

PS : il existe aussi un module Ruby pour ROOT
http://root.cern.ch/root/HowtoRuby.html(...) [En]

PS2: un site qui detaille un peu plus les faiblesses de ROOT
http://www.insectnation.org/howto/living-without-root(...) [En]

[1] http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-2(...) [En]
[2] http://www.slac.stanford.edu/grp/ek/hippodraw/index.html(...) [En]
[3] http://aida.freehep.org/index.thtml(...) [En]

Pour slot/signal il y a aussi Boost.Signals [1].
Il me semble d'ailleurs avoir vu quelque part (a confirmer) que ca allait etre integre dans C0x...

[1] http://www.boost.org/doc/html/signals.html(...)

Non, tu n'y es pas.
C'est a cause de ce que le monsieur il a une super connection internet de fou (CERN).
Le probleme c'est que ca va tellement vite que des fois y a des bouts qui tombent...

Apres un jeu de mot debile, voila un lien vers un article relativement interessant du Monde : [Petrole] Une nouvelle ere commence.

http://www.lemonde.fr/web/article/0,1-0%402-3230,36-686145,0.html(...)

je me rends compte qu'il y a énormément d'articles qui ne sont plus présents sur le site de M$.
Ben je pense que ceci devrait aider a en retrouver...
http://web.archive.org/web/*/http://www.microsoft.com/(...)

Bon par contre, au vu du nombre de pages, ca doit faire du boulot. Le mieux ce serait de trouver un thesard pour le faire :P ou alors un script.

En fait, RuDi va scripter les desktops de maniere homogene.
J'ai bon ?

D'ailleurs, si j'ai bien tout compris, BKsys a été choisi comme système de compilation officiel pour KDE4 : niveau pérennité on a fait pire ;)

La présentation : http://conference2005.kde.org/slides/software-construction-tools-ta(...)

Annonce officieuse:
http://ervin.ipsquad.net/index.php/2005/09/01/27-d5-meeting-day(...)

Résumé sur la page WiKi:
http://wiki.kdenews.org/tiki-index.php?page=KDE+4+Build+Systems+Fea(...)

Et bien sûr, le site officiel:
http://freehackers.org/~tnagy/bksys.html(...)

En effet, sa conclusion n'est pas folichonne.
Je n'ai ni ma boule de cristal sur moi, ni l'expérience de ce monsieur, mais je suppose néammoins qu'avec la sortie de X11R7 qui apportera la modularisation des paquets, on devrait voir la base de développeurs X s'élargir. Il ne faut pas oublier que le joli effet de bord de la modularisation est de changer d'infrastructure de compilation : les autotools, même s'ils ont des défauts, ont l'avantage d'être relativement bien connus des développeurs open source...
X.org peut tirer son épingle du jeu s'ils communiquent bien (genre ce que fait KDE avec KDE4) : du marketing pour geeks[1] en somme.

[1] http://conference2005.kde.org/slides/marketing-for-geeks--aaron-sei(...)

Quand je disais que c'etait hype :)
Cette video est tout bonnement bluffante !

Je suppose que cela vient justement du fait que ta partition est pleine.
Il me semble qu'il est de bon usage de ne jamais depasser les 80-90% d'utilisation d'une partition afin de garder des performances optimales...

Ici[1] il est recommande de laisser 5% d'espace libre...

[1] http://www.linuxplanet.com/linuxplanet/tutorials/3174/8/(...)

Bof... Je me suis toujours laisse dire que la defragmentation etait une manie qu'avaient attrapee les Windows switcheurs [attention: pas de dedain, juste une constatation...].
Et qu'a la longue ca devenait obsessionnellement compulsif de regarder le petit curseur qui change les blocs de place ainsi que le pourcentage de fragmentation qui diminue et finalement gagner un pouillème sur la lecture de ses fichiers (apres avoir defragmente son demi-tera de donnees)...

Je me suis d'ailleurs egalement laisse dire qu'ext2 avait un meilleur algorithme d'allocation de blocs (que FATxy).

http://lwn.net/Articles/81357/(...)
http://linuxfinances.info/info/defrag.html(...)

il est beaucoup plus difficile de "binder" ce langage [le C++] dans d'autres langages.

Ah bon ?
Moi j'utilise ceci : Reflex[1] qui permet automatiquement de generer des bindings en python de mes classes favorites.
Bon quand je dis automatiquement, il faut bien fournir un fichier xml pour specifier les differentes classes pour lesquelles je veux generer un dictionnaire (qui ensuite servira a binder le tout) et aussi accessoirement specifier les donnees membres que je veux "persistifier" (si besoin est).

Une fois que l'introspection pour les differentes classes est realisee, c'est facile (TM) et cégagné(re-TM).
Et ce, sans instrumentation du code C++.

[1] http://seal-reflex.web.cern.ch/seal-reflex/index.html(...)

Pour Java je ne sais pas, mais...
Ne peut-on pas parier sur l'avenir et se dire que des projets comme PsyCo[1], PyPy[2], Weave[3] et autres Pyrex[4] ne peuvent qu'ameliorer les performances de ce langage ?
(Sans parler des eventuelles amelioration du compilo python : pyc[5])

[1] http://psyco.sourceforge.net/(...)
[2] http://codespeak.net/pypy(...)
[3] http://www.scipy.org/documentation/weave/(...)
[4] http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/(...)
[5] http://students.ceid.upatras.gr/~sxanth/pyc/(...)

Bilan si on veut un toolkit léger et cross-plateforme il va falloir se tourner vers autre chose.

J'me lance ?
Heuu... Qt ?

Je n'ai encore jamais utilise Qt, ni GTK d'ailleurs, mais est-ce que ca parait plausible (comme remplacement) ou bien est-ce que Qt est deja une (un ensemble de) bibliotheque(s) trop volumineuse(eux) ?

Cela etant dit, j'ai cru comprendre qu'avec Qt4, il y avait un decoupage plus fin (mieux pense?) des differentes bibliotheques...

Il est sans doute utile de noter que ca bouge aussi du cote de l'integration d'Eclipse dans KDE (ou devrais-je dire Eklipse ? ;) ).

Apparemment, un developpeur de KDevelop[0] s'est mis un peu a Eclipse[1] (pour un Google Summer of Code), ca l'a emballe[2] et ca donne donc ca[3].

Je n'ai jamais vraiment utilise aucun de ces deux IDE (KDevelop et Eclipse), sans doute parce que je suis trop intoxique par les raccourcis claviers "a la Emacs", mais je me demandais si, entre ces deux IDE, et avec la recente nouvelle version de CDT, lequel serait le plus a meme de recueillir les louanges des programmeurs C++.

[ Et au passage, sent-on la difference lorsque l'on compile Eclipse avec gcc-4 ? ]

[0] http://www.kdevelop.org/(...)
[1] http://adymo.blogspot.com/2005/08/eclipse-hacking-experience.html(...)
[2] http://adymo.blogspot.com/2005/08/kde-eclipse.html(...)
[3] http://kde-eclipse.pwsp.net(...)

C'est ici :
http://lkml.org/lkml/2005/8/20/95(...)

Ou comment remettre les choses en ordre :)

a tes souhaits...

Si j'ai bien tout compris, ca[1] devrait etre integre et marcher out-of-ze-box dans la prochaine Ubuntu (Breezy)[2,3].
Y a-t-il quelqu'un dans l'assistance qui a deja essaye ?

[1] http://divmod.org/projects/shtoom(...)
[2] https://wiki.ubuntu.com/BreezyGoals(...)
[3] https://wiki.ubuntu.com/ShtoomVoip(...)

Tu vas ici:
http://ftp.scarlet.be/pub/openoffice/localized/fr/1.1.4/OOo_1.1.4_W(...)

Mauvais exemple, changer exemple :)
Et puis, appliquer l'argument de la prise en otage par un format de document a propos d'un format ouvert, je trouve ca assez gonfle soit dit en passant...

Une classification plus juste serait entre utilisateurs et bricoleurs perfectionnistes
En quoi est-ce une classification plus juste ?
Il y a tout autant (je suppose ou en tout cas je ne vois rien qui s'y oppose) de debutants utilisateurs et de debutants bricoleurs que d'utilisateurs debutants et utilisateurs experimentes.

Quel est le critere d'une classification plus juste ? Et plus juste envers qui ?
De plus je ne vois rien de pejoratif a dire de quelqu'un qu'il est debutant.
Par contre je vois bien un soupcon d'a priori negatif lorsque l'on traite telle ou telle distribution de "pour les bricoleurs etc..." (j'ai les noms !)

amical à l'utilisateur (je ne trouve pas le mot francais...
Ben en francais c'est user friendly, non ?

~~~~> [ ]