Sebastien a écrit 537 commentaires

y a un truc bien sympa dans python pour faire ca:

for idx,obj in enumerate(some_list):
  assert( some_list[idx] == obj )

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'

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

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:

C'est par ici:
Boost.Join
http://channel.sourceforge.net

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 !