je crois surtout que la grande peur c'est de ne rien trouver ou alors de trouver le higgs _exactement_ la ou on pensait le trouver: ce serait tellement... ennuyant et meme p-e ennuyeux.
Trouver quelque chose de completement different de ce que l'on attend: _ca_ ce serait excitant (et renvoyer les theoriciens a leur tableaux noirs ;) )
Concernant les mini trous noirs, la derniere fois que j'avais assiste a une "atlas-week" il me semblait avoir retiendu que la signature d'un de ces evenements etait particulierement caracteristique (en gros: plein de particules partout dans les 4-pi du detecteur: l'evenement arbre de noel, quoi) vu qu'ils couplent a tout via rayonnement de Hawking.
Au dela de l'analyse de physique de ces evenements, on a une methode super rapide pour les identifier au niveau software ces temps-ci: ca lance des std::bad_alloc. Des qu'un job de reconstruction/analyse tourne sur ces evenements (simules) on depasse les 3Gb de vmem et kaboom. Imparable. 100% d'efficacite de detection :P
Ce que j'attends surtout, c'est de pouvoir generer facilement des bindings pour differents langages dynamiques (ie: python quoi).
Je trouve que c'est vraiment-vraiment dommage que GCC ne soit pas plus modulaire... Un systeme de greffons/plugins pour extraire les informations (que l'on juge) pertinentes de son code serait vraiment pas du luxe.
Oui, il y a gccxml. Ok. Mais le developpement laisse a desirer, je trouve.
J'ai envisagé de me mettre à Python (pour écrire du code un peu plus abordable pour le commun des mortels, en particulier pour mes collègues), mais l'idée de devoir écrire du code genre
variable_avec_un_nom_significatif = variable_avec_un_nom_significatif + 1
parce que le concepteur estime que l'opérateur ++ est une complexité superflue, ça me bloque.
Bah, tu peux utiliser la methode __iadd__ :
variable_avec_un_nom_significatif += 1
Enfin le nouvel ordonnanceur CFS d'Ingo Molnar (évoqué lors de la dépêche sur le noyau 2.6.21) en est à sa dix-neuvième version et le temps de l'inclusion dans la branche principale approche à grands pas !
On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.
Tiens, j'ai vu passer sur la mailing liste de boost un embryon de bibliotheque inspiree de C-omega:
Hummm...
D'apres le constructeur de ColDefs, le seul cas ou self._nfields n'est pas directement cree est lorsque l'objet en entree est du type BinTableHDU .
Dans ce cas la, toutes les donnees membres de input.columns sont copiees dans self.
Je dirais donc que le probleme se situe lors de la creation listcolumns...
Mais bon, sans le code sous la main, hein...
C'est la raison pour laquelle Root est passé de GPL en LGPL.
Mouhahahah ! ROOT en GPL !
Si tu pouvais me donner le lien vers la version de ROOT qui etait en GPL...
Pour info, ce n'est que lorsque ROOT est passe en LGPL (ROOT 5, et parce qu'il integrait du code sous LGPL et utilisait gccxml pour generer des dictionaires des classes C++ - pour l'introspection) qu'il a pu etre accepte pour etre distribue par Debian.
Un extrait de la license originale:
Additionally, the authors grant
permission to modify this software and its documentation for any purpose,
provided that such modifications are not distributed without the explicit
consent of the authors and that existing copyright notices are retained in
all copies.
Pour le PS: je n'ai pas encore investi dans la 3ed du EC++. Qu'entends-tu pas "lagguer" ?
Nan... rien...
Je suis le capitaine bigleux.
Tout petit deja, j'avais ce probleme...
Tout ca pour dire, que, oui, dans son Item 11, S. Meyers recommande en effet d'utiliser la methode decrite plus haut pour gerer l'auto-assignement.
Par contre, j'etais en effet passe un peu (trop) vite sur les aspects d'exception-safety...
Garantir la condition de base (pour avoir du code exception-safe), c'est toujours bon a prendre.
Je vais essayer de m'astreindre a suivre cette implementation dans l'avenir.
PS: je viens de relire mon "Effective C++" de S.Meyers (3eme Ed.): il laggue un peu :)
PPS: et je suppose que tu veux dire: s/swap(rhs)/swap(temp)/
puisque les methodes ne sont pas virtuelles, à commencer [par] les destructeurs
Ben voila, t'as la reponse :)
Puisque tu ne peux/dois pas surcharger les methodes du conteneur, et que son destructeur n'est pas virtuel, ca fait 2 bonnes raisons pour avoir une classe qui soit implementee par aggregation/composition plutot que par heritage.
[^] # Re: et aussi dans archlinux
Posté par Sebastien Binet . En réponse au journal Sortie de Fusil le fuzzer en version 1.0beta3. Évalué à 1.
http://aur.archlinux.org/packages.php?ID=19629
# et aussi dans archlinux
Posté par Sebastien Binet . En réponse au journal Sortie de Fusil le fuzzer en version 1.0beta3. Évalué à 1.
http://aur.archlinux.org/packages.php?ID=19609
[^] # Re: La suite
Posté par Sebastien Binet . En réponse au journal Le quinzième anniversaire et Atlas. Évalué à 6.
Trouver quelque chose de completement different de ce que l'on attend: _ca_ ce serait excitant (et renvoyer les theoriciens a leur tableaux noirs ;) )
Concernant les mini trous noirs, la derniere fois que j'avais assiste a une "atlas-week" il me semblait avoir retiendu que la signature d'un de ces evenements etait particulierement caracteristique (en gros: plein de particules partout dans les 4-pi du detecteur: l'evenement arbre de noel, quoi) vu qu'ils couplent a tout via rayonnement de Hawking.
Au dela de l'analyse de physique de ces evenements, on a une methode super rapide pour les identifier au niveau software ces temps-ci: ca lance des std::bad_alloc. Des qu'un job de reconstruction/analyse tourne sur ces evenements (simules) on depasse les 3Gb de vmem et kaboom. Imparable. 100% d'efficacite de detection :P
[^] # Re: C & Cie
Posté par Sebastien Binet . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 1.
Rien, a part la compatibilite avec des bibliotheques C.
Mais ca devrait etre rectifie avec C++09:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n190(...)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n236(...)
(PDF de 8Mb...)
# as-needed
Posté par Sebastien Binet . En réponse au message Determiner les lib linkés inutiles. Évalué à 1.
-Wl,--as-needed
a l'edition des liens pour degraisser le nombre de bibliotheques contre lesquelles on linke.
La doc de Gentoo est pas mal foutue:
http://www.gentoo.org/proj/en/qa/asneeded.xml
[^] # Re: clan/llvm
Posté par Sebastien Binet . En réponse au journal Qu'est-ce qu'un outils de développement de rève ?. Évalué à 2.
Ce que j'attends surtout, c'est de pouvoir generer facilement des bindings pour differents langages dynamiques (ie: python quoi).
Je trouve que c'est vraiment-vraiment dommage que GCC ne soit pas plus modulaire... Un systeme de greffons/plugins pour extraire les informations (que l'on juge) pertinentes de son code serait vraiment pas du luxe.
Oui, il y a gccxml. Ok. Mais le developpement laisse a desirer, je trouve.
Il y avait un article a propos de ca sur LWN "recemment":
http://lwn.net/Articles/258700/
http://blog.mozilla.com/tglek/2007/11/29/gcc-plugins-under-m(...)
Que d'efforts dupliques pour un vrai (et complet) parser de code pour C/C++...
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Sebastien Binet . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
euh... je vais peut-etre dire une connerie, mais il me semblait que GNU/Hurd-L4 est/etait (sera... un jour...) code en C++.
En tout cas, L4, c'est du C++.
http://hg.l4ka.org/l4ka-pistachio/file/22f8bbd4984e/kernel/s(...)
On en deduira ce que l'on voudra bien en deduire :P
[^] # Re: À propos de Python
Posté par Sebastien Binet . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
http://www.python.org/dev/peps/pep-0203/
donc grosso merdo 2000~2001.
[^] # Re: Aors ? enfin des destructeurs ???
Posté par Sebastien Binet . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 2.
J'ai envisagé de me mettre à Python (pour écrire du code un peu plus abordable pour le commun des mortels, en particulier pour mes collègues), mais l'idée de devoir écrire du code genre
variable_avec_un_nom_significatif = variable_avec_un_nom_significatif + 1
parce que le concepteur estime que l'opérateur ++ est une complexité superflue, ça me bloque.
Bah, tu peux utiliser la methode __iadd__ :
variable_avec_un_nom_significatif += 1
[^] # Re: sonntag
Posté par Sebastien Binet . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
http://en.wikipedia.org/wiki/Support_vector_machine
[^] # Re: Correction
Posté par Sebastien Binet . En réponse au message Problème utilisation programmes externes (via shell). Évalué à 1.
# LLVM & OpenGL/Mesa
Posté par Sebastien Binet . En réponse à la dépêche Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0. Évalué à 4.
Apple utilise cette approche pour OpenGL dans Leopard
J'avais lu recemment un billet de Zack Rusin a propos de LLVM et MESA:
http://zrusin.blogspot.com/2007/05/mesa-and-llvm.html
Interessant, comme d'hab'
# CFS dans 2.6.23 !
Posté par Sebastien Binet . En réponse à la dépêche Sortie du noyau Linux 2.6.22. Évalué à 7.
Enfin le nouvel ordonnanceur CFS d'Ingo Molnar (évoqué lors de la dépêche sur le noyau 2.6.21) en est à sa dix-neuvième version et le temps de l'inclusion dans la branche principale approche à grands pas !
Ca y est, il est dans la branche principale:
http://lwn.net/Articles/241085/rss
[^] # Re: Concurrence et OpenMP
Posté par Sebastien Binet . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 1.
Tiens, j'ai vu passer sur la mailing liste de boost un embryon de bibliotheque inspiree de C-omega:
C'est par ici:
Boost.Join
http://channel.sourceforge.net
[^] # Re: Le nouveau nouveau chef de projet...
Posté par Sebastien Binet . En réponse à la dépêche Debian GNU/Linux 4.0 : Etch sort de l'oeuf. Évalué à 1.
[^] # Re: Un piste ???
Posté par Sebastien Binet . En réponse au message librairie pyfits: problème avec del_col. Évalué à 1.
D'apres le constructeur de ColDefs, le seul cas ou self._nfields n'est pas directement cree est lorsque l'objet en entree est du type BinTableHDU .
Dans ce cas la, toutes les donnees membres de input.columns sont copiees dans self.
Je dirais donc que le probleme se situe lors de la creation listcolumns...
Mais bon, sans le code sous la main, hein...
[^] # Re: KMail et l'HTML
Posté par Sebastien Binet . En réponse au journal KDE roXXor décidement!. Évalué à 5.
[^] # Re: KMail et l'HTML
Posté par Sebastien Binet . En réponse au journal KDE roXXor décidement!. Évalué à 6.
Les mails en HTML sont le mal absolu : y a pas mieux pour le phishing.
[^] # Re: avec gccxml ?
Posté par Sebastien Binet . En réponse au message Analyse de code C++. Évalué à 1.
LXR +Glimpse ?
LXR +Swish-e ?
Reflex c'est bien mais c'est lourd a mettre en place et le jour n'est pas loin ou il sera completement phagocyte par ROOT.
Je connaissais pas Dwarf... Merki :)
[^] # Re: Recherche publique bridé
Posté par Sebastien Binet . En réponse à la dépêche Numpy, extension C-Python pour le calcul scientifique. Évalué à 2.
Mouhahahah ! ROOT en GPL !
Si tu pouvais me donner le lien vers la version de ROOT qui etait en GPL...
Pour info, ce n'est que lorsque ROOT est passe en LGPL (ROOT 5, et parce qu'il integrait du code sous LGPL et utilisait gccxml pour generer des dictionaires des classes C++ - pour l'introspection) qu'il a pu etre accepte pour etre distribue par Debian.
Un extrait de la license originale:
# setattr
Posté par Sebastien Binet . En réponse au message variable <-> objet avec QT. Évalué à 1.
[^] # Re: Appels surchargés
Posté par Sebastien Binet . En réponse au message Surcharge d'opérateur : appel de l'opérateur de la classe mère. Évalué à 0.
Nan... rien...
Je suis le capitaine bigleux.
Tout petit deja, j'avais ce probleme...
Tout ca pour dire, que, oui, dans son Item 11, S. Meyers recommande en effet d'utiliser la methode decrite plus haut pour gerer l'auto-assignement.
[^] # Re: Appels surchargés
Posté par Sebastien Binet . En réponse au message Surcharge d'opérateur : appel de l'opérateur de la classe mère. Évalué à 1.
Si-si, mais je prefere celui-la :)
http://www.parashift.com/c++-faq-lite/assignment-operators.h(...)
Par contre, j'etais en effet passe un peu (trop) vite sur les aspects d'exception-safety...
Garantir la condition de base (pour avoir du code exception-safe), c'est toujours bon a prendre.
Je vais essayer de m'astreindre a suivre cette implementation dans l'avenir.
PS: je viens de relire mon "Effective C++" de S.Meyers (3eme Ed.): il laggue un peu :)
PPS: et je suppose que tu veux dire:
s/swap(rhs)/swap(temp)/
[^] # Re: Appels surchargés
Posté par Sebastien Binet . En réponse au message Surcharge d'opérateur : appel de l'opérateur de la classe mère. Évalué à 1.
Ben voila, t'as la reponse :)
Puisque tu ne peux/dois pas surcharger les methodes du conteneur, et que son destructeur n'est pas virtuel, ca fait 2 bonnes raisons pour avoir une classe qui soit implementee par aggregation/composition plutot que par heritage.
[^] # Re: Conjonction de coordination
Posté par Sebastien Binet . En réponse à la dépêche Release Candidate 1 de XCB. Évalué à -1.
(j'en connais).