Sebastien a écrit 558 commentaires

ouais... ce site web il est "vie[ux], usé et fatigué" :)

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...

Tout pareil... sauf que je n'ai pas besoin d'HTML pour lire mes mails. :)

Désolé, mais le HTML est nécessaire pour un mail de nos jours, on n'est plus en 1970.

Les mails en HTML sont le mal absolu : y a pas mieux pour le phishing.

doxygen ?
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 :)

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.

Moi j'utiliserais setattr

class toto:
 pass
t = toto()
setattr(t, "boo", 42)
print t.boo == 42

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.

Tu n'es pas alllé voir mes liens ? Avoue. :P

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)/

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.

Une pensee pour les FORTRANeux dyslexiques avant le 'implicit none'...
(j'en connais).

Ok, c'est sous-optimal dans la plupart des cas.
Mais :
- c'est du KISS (Keep it simple stupid).
- il sera toujours temps d'optimiser, apres.
- dans le cas present, il me semble que ce n'est pas judicieux puisque cela fait intervenir un std::vector temporaire plus sa copie. Tout bon compilo devrait pouvoir optimiser cela (je suppose), mais...

De toute facon, saimal d'heriter des conteneurs de la STL.

Il manque la protection contre l'auto-assignement:

template<typename T>
vecteur< T >& vecteur< T >::operator=( const vecteur< T >& rhs )
{
 if ( this != &rhs ) {
   std::vector<T*>::operator=(rhs);
   //... do stuff
 }
 return *this;
}

mais c'est juste pour pinailler. :)

A pinailleur, pinailleur et demi :)

Le photon qui "ricoche" c'ets quand même une approximation plus que grossiére. Un photon ca va tout droit.

Ceci est egalement une approximation grossiere :). Un photon ne va pas tout droit. Il suit les geodesiques de l'espace temps (c'est beau... mais surement inexact, ma relat' G est "un peu" rouillee).
Du coup, un "rayon lumineux" est devie aux environs d'un champ de matiere intense (genre une galaxie, un trou noir,...) qui modifie la courbure de l'espace-temps.
C'est ce qui est appele "lentilles gravitationnelles" ou "anneaux d'Einstein".

Une rapide recherche donne:
http://www.techno-science.net/?onglet=news&news=2035
http://commons.wikimedia.org/wiki/Image:Einstein_rings_zoom.(...)
http://www.futura-sciences.com/news-hubble-observe-lentilles(...)

Woua... si tout ca c'etait juste pour etre sur que les physiciens sont nuls pour expliquer quoi utiliser comme outils sous *nix...
Et je ne parle pas de "comment utiliser les outils sous *nix".

Moi je propose un autre sondage: parmis les etudiants en these devant a un moment ou un autre produire un binaire pour faire leur analyse, combien savent utiliser gcc pour compiler un truc un peu plus compliquer que 'helloworld.cpp' ?
Question subsidiaire pour departager les vainqueurs, combien savent ecrire un Makefile ? (euh, non, efface, combien savent modifier un Makefile existant?)

D'ailleurs, il me semble avoir vu dans un des differents blogs de dev de KDevelop (ou alors un KDE-Commit-digest ?) que Qt Designer avait ete integre dans KDevelop.

Ah voui, c'est la:
http://www.kdedevelopers.org/taxonomy/term/10
http://www.kdedevelopers.org/node/2201

Je suppose qu'un truc de ce genre devrait "faire la rue Michel":

import sys,time,os

sys.stdout.write("downloading kernel.3.0.0 from IPoT ")
sys.stdout.flush()
for i in range(10):
    sys.stdout.write(".")
    sys.stdout.flush()
    time.sleep(0.1)
sys.stdout.write( "".join( [" [OK]", os.linesep] ) )
sys.stdout.flush()

print "You can proceed with installation."

Moi je dis: ThinkPad...
Le support linux est vraiment bon, et il y a un bon site pour toutes les versions de ThinkPads:
http://thinkwiki.org/wiki/ThinkWiki

Un ThinkPad, c'est solide, leger (enfin ca depend, hein) et avec tout plein de petits details sympas (la lampe pour eclairer le clavier, le troisieme bouton pour le touchpad,... par exemple).

Ca s'appelle Boost.

Le plus simple pour ne pas s'embeter avec les tableaux C c'est quand meme d'utiliser les conteneurs de la STL, qui, eux, connaissent leur taille !

Je suis tombe la-dessus (enfin c'est plutot mon aggregateur qui me l'a lance):

http://www.omat.nl/drupal/?q=node/65
http://www.cmake.org/Wiki/HowToBuildKDE4Software

-> plein de petits trucs sympas pour CMake et KDE...

Oui, sauf qu'avec Kate tu peux editer ton fichier sur le serveur depuis ton laptop sous KDE depuis ton jardin avec Wifi: fish power.
Donc: hop, dans la course.

(Oui je sais, on peut faire ca avec les autres, hein)

Ouaip, le probleme c'est qu'apparemment SCons n'arrive pas a gerer une base de code aussi grande que le module kdelibs.

Moi aussi ca me semble plus sein de ne reposer que sur du "bete" code python mais apparemment, il ne faut pas esperer une trop grand reactivite du cote de SCons.

Je suis egalement un peu dubitatif quant a CMake.
Cela ressemble grandement a CMT, qui a lui aussi sa "syntaxe" pour produire des Makefiles (a la volee).
A mon humble avis, utiliser un langage que beaucoup de monde connait est quand meme une idee loin d'etre completement idiote...

Encore un peu plus d'infos dans le CVS-digest de cette semaine:

http://commit-digest.org/issues/2006-04-16/