Sebastien a écrit 537 commentaires

Il y a aussi Reflex du CERN.

au-dela de pouvoir creer des bindings automatiquement pour des langages de haut niveau, c'est aussi utilise pour automatiquement enregistre sur disque (serialization) n'importe quelle instance de classe qui est connue.

Reflex: http://root.cern.ch/drupal/content/reflex

tiens, je croyais que le format en meteorologie/climatologie etait HDF5...

«m'aurais-je gourrais-je ? »

oui, j'avais remarque la possibilite de faire un import selectif. donc en ooc on peut ecrire:

use math
x := sqrt(100)

import math/[sqrt]
y := sqrt(100)

si je fais le parallele avec python:

import math
x = math.sqrt(100)

from math import sqrt
y = sqrt(100)

donc, si je comprends bien, dans ooc on peut faire les deux mais dans le premier cas, le nom que l'on importe n'est pas completement qualifie...

un truc, ce sont les 'use toto' qui injectent tout le contenu du paquet/module dans le namespace courant. du coup, il n'y a pas vraiment de moyen de savoir que sqrt provient de 'math' dans le code suivant:

use math

x := sqrt(100)

ce qui est tres genant quand on (re)lit du code... bon, ou sinon, c'est un langage qui a l'air d'etre sympa, meme si la concurence est rude (vala/genie, go-lang)

moui...

bon je vois ca depuis ma lunette 'python comme langage pour scientifiques' donc en effet, mon terrain de jeux c'est le bi/quad/octo coeur avec 2Go par coeur.

je n'ai pas les stats (peut-etre que la PSF les a?) mais il serait sans doute interessant de savoir sur quel type de plateforme python est 'le plus' utilise...

surtout si on ne veut pas que les performances mono-thread souffrent au passage.

en meme temps, avec l'ere des multi-cores (et celle des many-cores au tournant), cette contrainte devient de plus en plus archaique.

ceci etant, jython ou ironpython pourrait arriver a la rescousse (puisqu'ils n'ont pas de GIL)

[enfin bon, tant que 'multiprocessing' marche et que cython facilite l'ecriture de modules...]

reversed est un builtin de python, tout comme range. et il retourne un itérateur, pas une nouvelle collection inversée:

assert 'reversed' in __builtin__.__dict__
assert 'range' in __builtin__.__dict__
l=range(5)
rl=reversed(l)
assert l[3]==3
l[3]=2
assert list(rl) == [4, 2, 2, 1, 0]

pour itérer en sens inverse:

for i in reversed(range(10)):
  print i

qui se servent de clang (le frontend pour le C, C++, Objective-C et Objective-C++), pour faire de l'analyse statique de code (chose qui est difficile actuellement avec gcc, qui devrait être un peu plus simple avec le mécanisme de plugin)

les gens de chez mozilla utilisent depuis quelque temps (~6mois ?) ce mecanisme de plugins de gcc pour faire de l'analyse de code, de la re-ecriture de code, et meme un LXR plus intelligent (qui a acces a la "vraie" definition des methodes, qui peut meme donner la liste des thunks,...) : DXR.

tout ca se fait grace a dehydra.

https://wiki.mozilla.org/Static_Analysis
https://developer.mozilla.org/en/Dehydra
http://dxr.proximity.on.ca/dxr/

au niveau espace utilisateur, un truc genre libdispatch devrait faire l'affaire.

en même temps, il y a toujours l'option "qemu plus montage de l'iso"

c'est souvent pratique pour tester un OS sans crader la station de travail :)

intéressant billet résumant le difficile parcours des concepts dans C++0x...

http://cpp-next.com/archive/2009/08/what-happened-in-frankfu(...)

À propos de kdemod, il va servir à quoi maintenant ?

à rester avec kde-3 pour les petites configs ?

pour info, un projet de GC concurrent:

http://code.google.com/p/scarcity/

il devrait être utilise a terme par python (unladen-swallow)

objc-2.0 est intéressant mais l'absence de namespaces est quand même franchement 'rétrograde'...

voui... j'etais surtout interesse par python-ptrace, mais bon, comme c'est demande gentillement :)
http://aur.archlinux.org/packages.php?ID=19629

c'est a dire ici:
http://aur.archlinux.org/packages.php?ID=19609

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

J'avoue que j'ignore ce qui justifie qu'on n'ai qu'un constructeur prenant un "const char*".
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...)

Il "suffit" de passer
-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

oui. moi aussi.

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

- Linux (codé en C) est plus abouti que The Hurd (codé en C), donc le choix du langage n'est pas important.

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

Ca date de python 2.0:
http://www.python.org/dev/peps/pep-0203/
donc grosso merdo 2000~2001.

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

je suppose, vu le contexte, que c'est 'Support Vector Machine':

http://en.wikipedia.org/wiki/Support_vector_machine