Sebastien a écrit 537 commentaires

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/

Plop,

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/

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 ?

[1] http://aseigo.blogspot.com/2006/04/cmake-sadness.html

Il me semble d'ailleurs avoir vu sur la mailing liste de CMake un gars qui demandait si c'etait possible d'avoir Python comme langage de script.

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/

ils ont quoi mes liens ?
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

nyzis dépend de QT?
Oui, mais pas de QtGui...

Ok, merci pour ces infos...

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 ?

Dans vim, on peut mapper toutes les touches de raccourcis emacs de tel sorte que tu utilises vim tel un emacs.

Ah oui ?
Tu parles de vimacs ?
http://www.algorithm.com.au/vimacs/

Ca a l'air un peu mort quand meme, non ?

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.

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

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

[1] : http://gcc.gnu.org/onlinedocs/gcc/Contributors.html

C++ est inommable. La STL en particulier. C'est un plaisir pour touver la source d'un bug. Les infos du compilateur et de gdb sont absolument incompréhensible pour un humain.

Est-ce que ca ne met pas en lumiere les manques du compilo et du debugguer plutot que la STL ?
Parce qu'a mon avis, si tu te plains de la STL et des erreurs a la compilation que l'on peut rencontrer au cours de son utilisation... ne va _jamais_ voir du cote de Boost ;)

Expanser 2000 lignes de code à chaque usage, c'est du délire.
Je suppose que la encore c'est un manque provenant du compilateur et, supposition encore, ca devrait_etre/est resolu avec les headers precompiles.

En fait j'ai l'impression que ce que tu n'aimes pas dans le C++ ce sont les templates.
Serais-tu le fils cache a Rene Brun (HEP private joke inside) ?
Il me semble que C++0x devrait resoudre la plupart de tes griefs a l'encontre des templates[*].
Cela se resume a: "make templates a first class citizen".

[*] encore faut-il que les compilos suivent derriere, je le concede volontiers.

Moi j'aurais plutot dit:
"J'espere que FC5 sera un bon cru"

A la mienne.

vous pouvez comme moi titiller NEC a propos de debian qui a le marché serveur au CNRS

A comprend pas (il dit qu'il a plus de genou)...
C'est quoi la private joke ?

J'espère que ca aboutira à de belles choses libres.
Moi aussi.
Ca a l'air vraiment interessant, mais pour l'instant la licence n'a pas encore ete
choisie, donc... prudence ?

En tout cas, j'ai appris pleins de pitites choses en parcourant le Wiki et la mailing-liste.

Ex:
Je connaissais le Model View Controller (MVC[1]) mais je connaissais pas le Model View Presenter [2,3].

[1] http://en.wikipedia.org/wiki/Model-view-controller
[2] ftp://www6.software.ibm.com/software/developer/library/mvp.p(...)
[3] http://www.martinfowler.com/eaaDev/ModelViewPresenter.html

En meme temps les ponts sont pas completement coupes: regarde l'icone de l'article LinuxFr sur Ekiga...
On voit tres distinctement un pied a 4 orteils.

J'ai decouvert recemment les joies de la compilation native de classes Java et je dois dire que ca m'a fait reviser mon jugement (surement hatif et a l'emporte-piece) sur ce langage.

Avec GCJ et Classpath (et sans doute d'autres projets, je sais pas, je debute) il me semble que Java est maintenant pret pour le libre (ou l'inverse).

Utiliser classpath avec Eclipse
Et il y a aussi l'inverse.
Utiliser Eclipse avec classpath:
http://developer.classpath.org/mediation/ClasspathShowcase
-> Native Eclipse - The Fast and the Furious IDE

Martin Pfeiffer est donc un futur utilisateur des libs KDE sous Windows alors...
J'ai bon ?

Mouais...
Faut pas voir le mal partout, hein...
Je crois surtout que c'est une histoire de manpower.

Apparemment, Stroustrup est tout seul a implementer/developper cette librairie...
Donc normal que cela prenne du temps.

Moi, le seul reproche que je ferais ce serait: "mais pourquoi diantre ne pousse-t-il pas cette lib dans Boost comme ca pleins de gens (talentueux) s'y mettraient et contribueraient !?".

Quand on voit le nombre d'applications dans la vraie vie (TM) qu'aurait XTI, je suis sur que ce n'est pas une question du probleme de la "tour d'ivoire".
Juste un bete probleme de manpower (parce que BS, il a quand meme un vrai boulot aussi a cote).

C'est un peu off-topic (enfin pas temps que ca puisque ca sera surement interessant pour les futures-futures-... versions de GCC), mais je suis tombe par hasard sur un enieme article[1,2] de BS expliquant les nouveautes de la prochaine norme pour le C++.

J'ai trouve que ce concept de "concept" etait vraiment tres interessant et devrait permettre de plus facilement resoudre certains problemes du C++ (notamment les collections d'objets polymorphiques qui devraient pouvoir etre vues comme des collections d'objets a n'importe quel endroit de l'arbre d'heritage)

Par contre je n'ai pas trouve de mention concernant XTI (eXtended Type Information) [3] qui aurait du/pu resoudre les problemes de persistence des donnees (entre autre!).

Quelqu'un a de plus amples informations concernant XTI ?

[1] la version light
http://www.artima.com/cppsource/cpp0x.html

[2] la version poussee
http://www.research.att.com/~bs/popl06.pdf

[3] http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf

Comme dit ailleurs plus haut (mais comme j'aime bien me lire, j'en rajoute une couche), l'aspect positif de ce portage que je vois personnellement moi-meme, au-dela d'avoir un jour un splash-screen KDE au demarrage de Windows, c'est surtout la possibilite d'avoir tout le catalogue de bibliotheques KDE sous Windows.

Ca ouvre des possibilites interessantes, telles que:
- remplacer NotePad par Kate
- remplacer UltraEdit par KDevelop
- avoir une Konsole ?
- avoir acces aux KIOSlaves ? (en fait, surtout fish, mais je ne cracherais pas sur les autres)
- K3b, Amarok, Kopete,...

En fait je verrais bien le portage des bibliotheques de KDE comme la premiere etape pour obtenir une plateforme portable (trans-OS) en C++ pour le developpement d'un truc genre Eclipse. Mais en C++ donc. Master plan to conquer the desktop/World.

Un autre aspect: la diffusion de technologies libre compliant via les KDELibs (et Qt4 en sous main), genre SVG, OpenGL (Qt4), OGG/Vorbis (Amarok)... (NB: qu'est ce que ca donnerait au niveau des libs comme Phonon, Solid et autres Plasma ?)
Bon, ca, c'est peut-etre un peu trop du reve.

Mais deja, avoir une plateforme a la Eclipse en C++, basee sur Qt4/KDELibs/KPart/KDevelop, ca... Ca serait du bonheur!