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;
}
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".
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.
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).
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...
* Ce qui serait bien ce serait d'avoir un mode "tutorial" qui lance les demo('toto') de R.
* Est-ce que le passage a Qt4 est envisage ?
* Ah et puis surtout: est-ce que quelque chose comme xgobi[1] est dans les cartons ?
Bien sur que ca arrive qu'une nightly soit cassee de temps en temps. C'est fait pour ca (enfin, c'est fait pour detecter quand ca casse, c'est pas fait pour etre cassee tous les 4 matins).
Ce qui est rageant (vecu inside) c'est:
- quand la nightly est cassee a cause des outils de compilation,
- quand on ne peut pas developper parce que les outils de compilation sont casses,
- quand on perd du temps a reparer les outils de compilation,
- ...
Mais apparemment les gens de CMake sont rapidement sur le coup.
C'est le titre d'un des billets[1] d'Aaron.
Un billet dans lequel il se plaint de CMake.
La n'est pas le plus important, comme il le dit lui-meme, la migration autoTRUC vers CMake est douloureuse mais necessaire.
Non, ce qui est interessant de noter, c'est un des commentaires dans lequel un courageux anonyme se demande pourquoi utiliser CMake alors qu'il existe qmake...
Je trouve que c'est en effet une question qui merite d'etre posee.
Quelqu'un a la reponse ?
ca ne me parait pas 'indispensable' comme fonctionnalité
Je pense au contraire que c'est tres important.
Avoir la tres grande majorite des scripts vim accessibles depuis Yzis est il me semble une condition necessaire pour faire switcher un maximum d'utilisateurs vim...
En tout cas, j'aime bien la philosophie de base de Yzis (une bibliotheque de base que l'on peut integrer un peu n'importe ou)...
Yzis ca a l'air vraiment bon. D'ailleurs, quand j'ai vu la news sur vim7 je suis alle
faire un tour sur votre site, histoire de prendre des nouvelles.
Il y a 2 questions existentielles que je me pose neammoins:
- est-ce que pour les accros au python il est prevu d'avoir une "interface" de scripting pour ce langage (plutot que Lua, je parle pas le Lua tres couramment) ?
- est-ce qu'il est prevu d'avoir un module de compatibilite pour les scripts vim (de sorte qu'il serait possible de reutiliser toute la base deja existante de ces scripts dans Yzis) ?
Voila-voila...
Ou sinon, vu que vous avez fini le portage vers Qt4, quelles sont vos impressions par rapport a cette nouvelle version de Qt ?
Sinon, il y avait les cartes VME [...] Ce fut utilise un temps dans des applications aussi bien industrielles que militaires.
C'est toujours vachement utilise en physique nucleaire et en physique des particules.
Yep.
Mais bon, lisaac c'est combien de personnes ?
GCC c'est quand meme a base de vachement plus de monde [1] meme s'il faut bien sur retrancher toutes les personnes qui ne contribuent pas directement a G++.
[^] # 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.
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.
[^] # 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.
[^] # Re: re
Posté par Sebastien Binet . En réponse au journal printf debugging considered harmful. Évalué à 1.
[^] # Re: re
Posté par Sebastien Binet . En réponse au journal printf debugging considered harmful. Évalué à 1.
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(...)
[^] # Re: Merçi pour les infos
Posté par Sebastien Binet . En réponse au journal gmake sondage. Évalué à 1.
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?)
[^] # Re: Designer ?
Posté par Sebastien Binet . En réponse à la dépêche QIde, un IDE pour Qt4. Évalué à 3.
Ah voui, c'est la:
http://www.kdedevelopers.org/taxonomy/term/10
http://www.kdedevelopers.org/node/2201
[^] # Re: heu...
Posté par Sebastien Binet . En réponse au message retour chariot. Évalué à 1.
[^] # Re: Quelques conseils
Posté par Sebastien Binet . En réponse au journal Achat d'ordinateur portable. Évalué à 1.
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).
[^] # Re: Multiples clients IM
Posté par Sebastien Binet . En réponse à la dépêche Sortie de Kopete 0.12. Évalué à 5.
# stl
Posté par Sebastien Binet . En réponse au message Tableaux en parametres. Évalué à 1.
# CMake, KDE-4: meme combat
Posté par Sebastien Binet . En réponse à la dépêche Sortie de CMake 2.4.1. Évalué à 1.
http://www.omat.nl/drupal/?q=node/65
http://www.cmake.org/Wiki/HowToBuildKDE4Software
-> plein de petits trucs sympas pour CMake et KDE...
[^] # Re: ceci n'est pas un troll ...
Posté par Sebastien Binet . En réponse à la dépêche Sortie de Vim 7. Évalué à 2.
Donc: hop, dans la course.
(Oui je sais, on peut faire ca avec les autres, hein)
[^] # Re: Un manque complet de reaction de la part des dev
Posté par Sebastien Binet . En réponse au journal CMake dans KDE. Évalué à 4.
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...
[^] # Re: Explications de la part du developpeur de BKsys
Posté par Sebastien Binet . En réponse au journal CMake dans KDE. Évalué à 4.
http://commit-digest.org/issues/2006-04-16/
# ArchLinux
Posté par Sebastien Binet . En réponse à la dépêche Vers un logiciel de statistiques facile à utiliser pour KDE. Évalué à 9.
Je viens de faire le paquet pour ArchLinux, si ca interesse des gens:
http://aur.archlinux.org/packages.php?do_Details=1&ID=42(...)
Quelques questions/commentaires en vrac...
* Ce qui serait bien ce serait d'avoir un mode "tutorial" qui lance les demo('toto') de R.
* Est-ce que le passage a Qt4 est envisage ?
* Ah et puis surtout: est-ce que quelque chose comme xgobi[1] est dans les cartons ?
Voila.
[1] http://public.research.att.com/~stat/xgobi/
[^] # Re: CMake sadness
Posté par Sebastien Binet . En réponse au journal CMake dans KDE. Évalué à 3.
Ce qui est rageant (vecu inside) c'est:
- quand la nightly est cassee a cause des outils de compilation,
- quand on ne peut pas developper parce que les outils de compilation sont casses,
- quand on perd du temps a reparer les outils de compilation,
- ...
Mais apparemment les gens de CMake sont rapidement sur le coup.
# CMake sadness
Posté par Sebastien Binet . En réponse au journal CMake dans KDE. Évalué à 4.
Un billet dans lequel il se plaint de CMake.
La n'est pas le plus important, comme il le dit lui-meme, la migration autoTRUC vers CMake est douloureuse mais necessaire.
Non, ce qui est interessant de noter, c'est un des commentaires dans lequel un courageux anonyme se demande pourquoi utiliser CMake alors qu'il existe qmake...
Je trouve que c'est en effet une question qui merite d'etre posee.
Quelqu'un a la reponse ?
[1] http://aseigo.blogspot.com/2006/04/cmake-sadness.html
[^] # Re: Enorme
Posté par Sebastien Binet . En réponse au journal CMake dans KDE. Évalué à 2.
ici:
http://public.kitware.com/pipermail/cmake-promote/2005-Decem(...)
Pour les fana de Lua, il est mentionne dans ce thread le projet Hamster qui est le pendant de SCons pour Python:
http://luaforge.net/projects/hamster/
[^] # Re: Même questionnement
Posté par Sebastien Binet . En réponse au journal Se libérer du plaisir sado-maso de LaTeX. Évalué à 2.
C'est juste le "dharma[1]" qu'il y a dedans qui a fait tiquer le telespectateur avide de la serie Lost...
Soit dit en passant, cette serie est tout bonnement geniale !
J'espere juste que la fin sera a la hauteur...
/!\ Spoilers /!\
[1] http://en.wikipedia.org/wiki/The_Dharma_Initiative
[^] # Re: Yzis, c'est le futur
Posté par Sebastien Binet . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 4.
Oui, mais pas de QtGui...
[^] # Re: Yzis, c'est le futur
Posté par Sebastien Binet . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 6.
ca ne me parait pas 'indispensable' comme fonctionnalité
Je pense au contraire que c'est tres important.
Avoir la tres grande majorite des scripts vim accessibles depuis Yzis est il me semble une condition necessaire pour faire switcher un maximum d'utilisateurs vim...
En tout cas, j'aime bien la philosophie de base de Yzis (une bibliotheque de base que l'on peut integrer un peu n'importe ou)...
[^] # Re: Yzis, c'est le futur
Posté par Sebastien Binet . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 3.
faire un tour sur votre site, histoire de prendre des nouvelles.
Il y a 2 questions existentielles que je me pose neammoins:
- est-ce que pour les accros au python il est prevu d'avoir une "interface" de scripting pour ce langage (plutot que Lua, je parle pas le Lua tres couramment) ?
- est-ce qu'il est prevu d'avoir un module de compatibilite pour les scripts vim (de sorte qu'il serait possible de reutiliser toute la base deja existante de ces scripts dans Yzis) ?
Voila-voila...
Ou sinon, vu que vous avez fini le portage vers Qt4, quelles sont vos impressions par rapport a cette nouvelle version de Qt ?
[^] # Re: Troll
Posté par Sebastien Binet . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 1.
Ah oui ?
Tu parles de vimacs ?
http://www.algorithm.com.au/vimacs/
Ca a l'air un peu mort quand meme, non ?
[^] # Re: Une idée comme ça ...
Posté par Sebastien Binet . En réponse au journal Les PPU !!. Évalué à 3.
C'est toujours vachement utilise en physique nucleaire et en physique des particules.
Voila le catalogue si ca t'interesse:
http://www.caen.it/nuclear/product_list.php?cat=fe
http://www.caen.it/nuclear/short_form.php
[^] # Re: Pffff...
Posté par Sebastien Binet . En réponse au journal Un compte rendu de la conf sur isaac/lisaac. Évalué à 2.
Mais bon, lisaac c'est combien de personnes ?
GCC c'est quand meme a base de vachement plus de monde [1] meme s'il faut bien sur retrancher toutes les personnes qui ne contribuent pas directement a G++.
[1] : http://gcc.gnu.org/onlinedocs/gcc/Contributors.html