Raphael Junqueira a écrit 337 commentaires

c vraiment ca le fond du probleme :(

vu les debit des chekins cvs (d'ou les celebres blagues entre dev kde qu'il est impossible d'avoir une version a jour plus de 5s) tu passe plus de temps a updater, tester apres update (puis si le test est un peu long du doit re-updater, au cas ou, et potentielement retester si qq'un a modifier des fichiers utilises/peripheriques ou meme le meme que toi)

Bon dernierement ca commence a se stabiliser cote kdecore, kdeui donc le soir, lors des updates, je ne pleure plus trop
(quoique j'ai tendance a ne me synchroniser reelement que de temps en temps)

"recompilent-ils tout kde à chaque fois qu'ils changent une ligne ?"


arf, ben essaye: change par example dans kaction.h un peu de code (bon heureusement ils le font tres rarement ... vive les privates datas)
et recompile

Plus serieusement, ce n'est pas la compilation qui les gene (quoique vu le debit de checkins, lors de la phase update-test-checlins tu pleure bien: le nombre de fois ou g du reupdater-retester-rereupdater-reretester... avant de pouvoir envoyer sans de vieilles suprises)
En fait c surtout les couts indirects du au developpement: debuggage, traces, ...

tiens d'ailleurs personne ne connait un visualisateur (editeur je m'en fous) supra supra rapide avec des enormes fichiers (du genre 20-30mo de texte) ... pcque la emacs il scotche pendant presque un heure et tu peut a peine faire une recherche, kate il crashe, kwrite il refuse, ....

en en prime:
http://ccache.samba.org(...)

les deux ensemble ca fait du div bcp dans le temps de compilation :)
(un preference pour ccache qui marche en local)

a croire que du cote de samba c des tordus (bon avec leurs jouets il recompilent les biniaires samba toutes les 40 min)

c'est clair qu'il y a des discussion meta-phys sur la ml de dev .)

mais sur kdepromo ils ont du y aller a la louche de toute facon, pcque c litteralement impossible de connaitre le nombres de personnes ayant directement et indirectement bosser sur kde.

Meme en analysant les comments des checkins cvs ou normallement les dev doivent noter les personnes les ayant aider, ca sera pas precis du au fait que bcp de devs ne le font pas.

De meme pour les "Abouts" qui ne contiennent que souvent les devs principaux (et quelques fois les "trop anciens" se font eclipser)

tiens je me demandait a quoi ca pouvait servir :)

mais il gere unsermake ? pcque si oui ca va ptet me simplifier la vie plutot que mes 5-6 shells scripts tous degeus

c clair

mais ca doit etre ca, car n'oublie pas que c'est reparti sur quelques annees et de plus certains traducteurs donnent reelement de leur personnes (examples des traductions espagnoles et portugaises qui sont dans les top 10 et pourtant ont bcp moins de traducteurs que par examples les allemands)

Mais rien n'empeche d'aider les traducteurs a avoir un peu plus de vie sociale en contribuant un peu, meme 5 min le temps de traduire 2-3 lignes c'est toujours ca (surtout que par example la traduc francaise et pas loin d'etre complete) :)
Surtout qu'avec les outils de traductions de kde (superbes), c rendement maximum.

Raphael

ils parlent pas de "tests", mais de developpement (compile, debugging, ide, ...) la nuance est qd meme enorme.

Juste le cout de valgrind, gprof ca fait supra mal

> Indépendemment de la qualité de Windows, il est 100% vrai que lancer un programme sous différents OS et/ou processeurs permet de bien mettre en évidence certaines erreurs de programmation liés à gestion de la mémoire.

hmmm, j'aimerait que ca soit vrai :(
moi je travaille avec 5-6 os differents sous la main et tu arrive tres rarement a reproduire les problemes. Pire, souvent c memes les os qui te pourrissent la vie.

d'ailleurs pour la detection de fuites memoire le champion et AIX car il gere super mal la memoire (ou linux+valgrind au choix)

lol
moi je moule car j'attend mon visual sur une enorme compil :)

sinon c clair que les headers stl de g++ sont horribles surtout qur gcc il est ignoble sur les templates en terme de temps de compilation (alors que sous visual c juste perceptible a condition de rester raisonnable)

arf

si certains devs kde t'endendait ...
y en a pas mal qui passent une bonne partie de leur temps a mettre des forward declaration dans les headers pour justement eviter ce probleme (accessoirement ca oblige dans les sources a mettre la cinquentaine d'inclusions)

Et honnetement ils ont assez bien separe les headers (meme trop parfois cf kaction). Maintenant, on a beau faire du split, sur un si gros projet que kde on atteint vite les limites du compilo.

Et oui, je confirme gcc est supra lent, a cote visual c++ (en desactivant les precompilations de .h, et autres joyeuseries pour etre reelement equivalent en terme de fonctionnalite a gcc) va enormement plus vite sur les nombreux tests que j'ai effectue. C'est d'autant plus notable que le projet est bien separe (en fait gcc va plus ite que visual dans le cas d'un giganstesque et unique source, c pour ca que kde en --enable-final genere un source qui inclus tous les autres par directory)

Maintenant avec ccache, ... gcc est plus supportable

Faux :)

c'est exactement la meme chose que tu decrit pour macosx

d'ailleurs pour windows c faux aussi :)
windows (a partir de 2k) peut gerer toutes les langages "europeens" avec la meme version a condition que tu redemmare ta session (pas de reboot). Bon ca reclame une version speciale developpeur (pcque la classique elle n'est fournit qu'avec une langue)

Pour le japonais la c plus dur, fo une version tres specifique (d'ailleurs tres speciale)

Raphael

joli :)

je m'en rappellait plus de ca, je me disait aussi qu'il devait y avoir un moyen "propre" de le faire :)

va ptet falloir que je reapprenne ma table d'attribute

C'est clair que c'est assez enorme bien que l'ensemble kmail et autres doit s'appocher de cette taille (mais bon une bonne partie est maintenant consideree comme appartenant au framework de base de kde)

> Selon mes souvenirs il y a eu jusqu'à 30 personnes à temps complet. A confirmer !

Pour kmail, c'est juste dernierement qu'il y eut des developpeurs a temps complets (le projet de PIM sponsorise par les allemands) et meme comme ca ils doivent etre au max une dizaine. Mais bon ils ont aussi un ou deux ET;)

Pour le debat C/C++, ce n'est pas le langage en tant que tel qui fait gagner du temps et permet la reutilisation, c'est la modelisation. Il m'est souvent arriver de developper du code C aussi vite que du C++, voir plus vite.

Maintenant, il est clair que par example evolution qui a du reimplementer enormement de choses car les api de gnome n'etait pas adaptees et assez dur a generaliser pour repondre au besoins d'evolutions alors que, pour kmail, la demarche de generaliser/adapter les api de kde pour des besoins plus pousses (cf kdelibs/kressources, kdelibs/kdecore, kdelibs/kdeutils, ...) a pu etre faite de facon limpide (de quoi aimer la surcharge, le polymorphisme et hmm des factories).

Et pour moi elle est la l'enorme diff entre un langage OO et le C: la facilite d'evolution/generalisation a condition bien sur que la modelisation soit bien pensee a l'origine (je ne critique pas gnome qui possede une assez bonne modelisation des api, malheureusement difficile a faire evoluer de facon propre du aux limites du c)

L'exemple de mozilla est la preuve que meme en c++ on peut faire des trucs enormes par rapport a ce que ca devrait etre (taille de mozilla > kdelibs 3.0 + kdebase 3.0 !!!) quand on ne fait pas trop attention a la modelisation

Raphael

ben c bien comme je l'avait explique au-dessus.
le seul probleme comme tu l'a souligne vient des surcharges (meme si en general elles sont souvent inutiles cf exemple long/int). Pour le type opaque, je trouve ca normal vu d'un point de vue objet.

Et c'est bien vrai que c'est beaucoup plus interressant d'apprendre le c++.
Mais dans certains cas les contraintes sont telles qu'il faut pouvoir appeler du code c++ a partir du c. Par example: xmms qui est entierement code en c qui doit pouvoir s'interfacer avec sont plugin de sortie son sur le demon arts de kde (qui lui est en c++).

Malheureusement, il en a bcp de cas comme celui-la, donc ces bindings sont tjs necessaires meme si ils sont loins d'etre propre (quoique je les considere personnellement aussi propre/aussi crade que le code c de gnome/gtk)

oki,
comme quoi ;)

je doit trop avoir l'habitude de faire du c++, pour la peine je retourne sur wine ;p

1) c'est pas un mal, car bien qu'il soit assez beau je supportait pas ca vitesse de rafraichissement

2) sympa, enfin si ils en sont qu'a l'integration de qquechose que je considere basique ;( (a quand l'integration native multi-protocoles de shares auto: smb, nfs, rdv, ...)

pour le systray je pensait que la norme freedesktop etait pas encore stabilisee, va falloir que je voit ca. En tout cas si ca marche ca va etre une etape enormement importante de plus pour la cooperation inter-desktop (hmmm le kopete sous mon buro gnome)

;)
enfin pour le "rival d'evolution" c'est encore plus tordu ;)
en clair c'est en voie de se transformer en la creation d'un mega framework de gestions d'emplois du temps, de contraintes, de messagerie, ... chose que seul macosx comme os possede actuellement (bien qu'a mon avis kde a developer l'idee de facon bcp plus poussee).

Moi au debut, j'avait moyennement aprecier l'enorme fusion bourrine, l'apparition de nouvelles libs dans kdelibs, ... mais ayant vu qques capacites de la bete, je commence a apprecier. (bien que cela manque cruellement de stabilite)

Et comme tu le dis si bien, de nombreuses applis en prendront compte (dans les startings blocks: kopete, koffice, ... qui en feront une utilisation specifiques) et d'autres en prendront automatiquement compte (mais de facon generique).

Raphael, qui vient de peter son kopete avec un stupide bug de son xxx de plugin

non ;)
Ils auraient pus, mais en fait le script perl kalyptus parcours tous les headers kde et genere du code de binding pour tous les langages supportes.

Apres il reste plus qu'a linker avec les bibliotheques de bindings ainsi generees.

En fait, dcop comme acces client, n'a un interet direct que dans les langages de scripts (voir interpretes) afin d'envoyer des commandes dcop a kde

Enfin tu peut tjs utiliser les interfaces standards dcop via les bindings classiques vu que dcop fait parti des 3 bindings auto-generes (avec qt et kde)

ben vi c assez simple ;)

et ca je pense que ca marche en pure C non ?

static int dummy_init(void) {
printf("dummy here\n");
}

static int _test_dummy = dummy_init();

int main(int argc, char** argv) {
printf("main here\n");
return 0;
}


Raphael

en fait du point c++ c'est plus facile.
Je m'explique: les plus gros problemes dans les bindings C -> autres langages (surtout interpretes qui pausent des problemes) sont les parametres variables (varargs) et les passages par pile (objets statiques, etc...). Hors en c++, a condition que tu t'oriente vers du code c++ reelement objet propre, tu n'utilise pas (ou tres peu) les vararg et vu que le c++ "t'oblige" a allouer des objets, tu n'a pas (ou peu) d'objets a la C qui trainent

Enfin pour le dernier probleme, les callbacks, normallement en c++ tu n'en utilise que tres peu car redondant en terme de fonctionnalite avec les principes de polymorphisme (meme si Qt les utilise intensement, mais uniquement en interne).

voilou, j'ait faillit ne pas voir ton reply a cause de mon mozilla qui delire (vivement que je rentre chez moi)

kalyptus c le script perl qui genere les bindings c, obj-c et java a partir des headers de kde:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/kalyptus/(...)

pour les autres scripts ils sont dans le coin

C'est un argument,

mais en pratique tu as generalement souvent, a quelques malheureuses exception pres, besoins de collections, de persistance fichier, d'acces reseau, etc...
Au final, bien que souvent une appli au debut de dev ne necessite pas bcp de choses, tu en viendra toujours a utiliser pleins de libs. Donc autant utilsier une lib coherente et dont toutes ses parties sont fort bien integrees (en plus d'etre tres rapide a utilisee) que des libs separees.

Bon pour gtk+, glib et quelques autres bibliotheques autours de gnome sont assez homogene de ce point de vue la. Mais ca me fait assez mal d'avoir a installer n libs de gestion de collections, m libs de gestion reseau, ... juste pacque chaque appli tire un peu sur les libs qu'elle veut :(((

bon un exemple (approximatif) pipo

header c++: ctest.hh

class CTest {
private:
int _test;
pubic:
CTest(int initTest) { _test = initTest;}
int test(void) const { return _test; }
void setTest(int newTest) { _test = newTest; }
};

header binding c: ctest.h

extern "C" {
typedef void* CTest_t;
CTest_t CTest_create(int iniTest);
int CTest_test(CTest_t );
void CTest_setTest(CTest_t, int newTest);
}

source binding c: ctest_binding.cpp (oui c bien un source cpp)

#include "ctest.hh"
#include "ctest.h"
extern "C" CTest_t CTest_create(int iniTest) {
return reinterpret_cast<CTest_t> (new CTest(iniTest))
}

extern "C" int CTest_test(CTest_t obj) {
CTest* this = reinterpret_cast<CTest*> (obj);
return this->test();
}

extern "C" void CTest_setTest(CTest_t obj, int newTest) {
CTest* this = reinterpret_cast<CTest*> (obj);
this->setTest(newTest);
}

voilou

arf ca va troller, enfin bon

En fait Qt est de loin superieur a gtk+ car tout simplement Qt equivaut, en terme de fonctionnalités, a glib, gtk+, <gestion>, ...
et autres joyeuseries :)

Mais j'en convient qu'a part pour le haut niveau d'integration des ces fonctionnalites, gtk+ avec une bonne dizaine d'autres bibliotheques fournis les meme fonctionnalites.

Pour les librairies gnome, la c'est assez different. Kde a un framework largement plus complet au niveau des possibilites (essaye juste de regarde les interfaces kio et kparts ou bien encore le framework d'impression). L'avantage de gnome est que les developpeurs se sont plutot interresses aux applications ce qui a permis d'avoir une bonne base d'appli et un framework de base qui possede ce qui est necessaire pour celles-ci. Pour Kde, le framework a tjs devance les applis.

Maintenant, actuellement en voyant avec quelle facilite et rapidite tu peut utiliser les libs kde pour des applis tout en garantissant des grandes fonctionnalites, je pense que tu peut comprendre pkoi meme si gnome possede "encore plus" d'applications majeures cela ne va plus etre tres vite le cas (on peut le confirmer en voyant le rythme de dev de koffice, kdevelop, quanta, kopete, konqueror, ...)

Raphael (g honte)

y a la meme chose avec bonobo, mais tjs est il que dcop est bcp plus utilisable que bonobo (encore trop proche de corba a mon gout)

sinon l'avantage des bindings kde c'est qu'ils sont "automatiquement" generes pas un script, donc si on veut supporter un nouveau binding il suffit d'adapter le script