Le demandeur lui enverra un mail à "adopt-a-geek@kde.org", lui expliquant ce qu'il fait dans KDE (les bêta testeurs ne sont pas concernés). Et là si tout va bien le petit pc va partir en voyage et revenir tout musclé ...
Aller plus loin
- Adopt a Geek (2 clics)
# Re: Gentil KDE
Posté par analogue o/ (site web personnel) . Évalué à 10.
Par demandeur, la nouvelle entends développeur de KDE qui a besoin de Mhz
Donc un utilisateur de KDE qui veut bien donner du matos, l'envoie. Et Scott Wheeler le fait passer à un développeur KDE qui apprécierait plus de puissance et lui en a fait la demande.
# Re: Gentil KDE
Posté par Leroy Frederic (site web personnel) . Évalué à 6.
<troll>
"recompilent-ils tout kde à chaque fois qu'ils changent une ligne ?"
"Le problème ne serait-il pas plutôt du côté de gcc (qui est très lent !) ?"
</troll>
Et puis je crois qu'ils ont des scripts pour prepocesser les sources et eviter de recompiler des sources non modifiées, sont-ils au courant.
Ne pourrait-on pas faire une sorte d'Emmaus pour Gnu/Geek et pas seulement pour Kde/Geek ?
[^] # Re: Gentil KDE
Posté par med . Évalué à 10.
Pour ceux que ça intéresse : http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompi(...)
[^] # Re: Gentil KDE
Posté par Paul Andre . Évalué à -4.
ah oui, du coup c'est la faute à gcc qui est lent ... et c'est pas du tout la faute aux developpeurs qui ont un petit probleme de separation claire des interfaces dans les .h
AMHA, ce genre de fonctions (les pch) ca pousse à faire de la m?rde (c'est une rustine qui couvre un probleme d'organisation)
[^] # Re: Gentil KDE
Posté par kadreg . Évalué à 5.
Il faut aussi voir que c'est surtout pratique pour les librairies standard.
Si j'ai un fichier avec juste un #include <iostream.h>, je récupère 1218 lignes de déclarations diverses et variées. Avec un #include <list> j'ai 5733 lignes riches en templates divers et varié, toujours un peu longuet à compilationner. Ce genre de truc que l'on ne change que tous les 36 du mois, je ne vois pas l'intêret de les recompiler à chaque fichier.
Ou alors tu utilise les durées de compilation pour mouler sur la tribune :°)
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à -1.
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)
[^] # Re: Gentil KDE
Posté par Paul Andre . Évalué à 2.
tout a fait d'accord.
je recopie juste le debut de la page cité plus haut :
"Often large projects have many header files that are included in every source file. " plus loin "For instance, if you have #include "all.h"", bref j'adore ...
Ou alors tu utilise les durées de compilation pour mouler sur la tribune
en fait c'est plutot le contarire :-)
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 7.
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
[^] # Re: Gentil KDE
Posté par Philippe F (site web personnel) . Évalué à 2.
Je confirme aussi que gcc est grave plus lent que Visual. Et pourtant, j'ai une machine qui devrait donner un gros avantage a gcc. Mais non, que dalle. Snif!
[^] # Re: Gentil KDE
Posté par Paul Andre . Évalué à 1.
uh ? tu peux en dire plus ?
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 1.
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)
[^] # Re: Gentil KDE
Posté par ufoot (site web personnel) . Évalué à 4.
Et d'ailleurs je me demande si ça vaudrait pas le coup de faire plus de choses en script au niveau des IHMs. Typiquement, sur une IHM, ce qui doit être rapide, c'est les routines d'affichage, donc ce qui concerne Qt, et puis pour le reste la plupart des choses peuvent se scripter. Genre l'aspect "si je clique sur ce bouton alors ça lance tel bout de programme" peut se faire en script, l'affichage du bouton et le bout de programme étant eux des binaires. C'est à priori le genre de solution retenue par tcl/tk par exemple, et à part le faire que tcl est un peu pas super moderne et que tk est super moche je pense que c'était une bonne idée. Mais les IHMs 100% C++, je pense pas que ce soit une riche idée, entre autres parce que le temps de compilation est rédhibitoire.
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 1.
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, ....
[^] # Re: Gentil KDE
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Emacs, le fait bien mais il faut une machine puissante et de la mémoire.
"La première sécurité est la liberté"
[^] # Re: Gentil KDE
Posté par kadreg . Évalué à 2.
Lorsque j'était sous MSDOG, j'utilisais PCtools qui contenait un editeur de texte qui ne chargeait en mémoire que ce qu'il affichait et ce qui était modifié, ce qui permettait d'éditer des fichiers de plusieurs Méga sur un pov' 8086 avec 640Ko de mémoire (ce qui effectivement suffisait).
Mais depuis, je n'ai jamais revu ce type de comportement.
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 2.
et bizzarrement aucun editeur sous linux ne permet ca ;(
a se demander si il y a jamais eut personne qui s'est plaint des meme problemes
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 1.
j' ai une machine puissante et bcp de mem. et il est inutilisable: impossible de bouger le curseur sans 5-6s de latence ;((
par exemple kate s'en sort nettement mieux que emacs dans ce cas la
# Re: Gentil KDE
Posté par kagouou . Évalué à 10.
C'est pas en travaillant avec un Bi-XEON boosté à 2.8 GHz avec 1 Go de RAM et un DD rapide et silencieux que l'on apprend à faire des softs optimisés.....
[^] # Re: Gentil KDE
Posté par med . Évalué à 9.
[^] # Re: Gentil KDE
Posté par printakilla . Évalué à 0.
^_^
[^] # Re: Gentil KDE
Posté par ufoot (site web personnel) . Évalué à 7.
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 à la gestion de la mémoire. Concrêtement, les erreurs les plus chiantes sont celles "qu'on ne voit pas" mais qui se déclenchent de temps en temps. Et le bug peut ne jamais apparaître sur une config donnée - en général celle du développeur vu que s'il avait vu le bug il l'aurait corrigé. Perso, quand je développe des programmes Windows, j'essaye - quand c'est possible - de les faire tourner sous wine. Si ça passe, c'est bon signe 8-) Pour les programmes UNIX, rien ne vaut un bon test sur plusieurs distribs, plusieurs machines, plusieurs OS (Linux, FreeBSD,...) et idem, si ça passe c'est bon.
J'ai récemment fait le port d'un programme pour FreeBSD, et bien j'ai mis le doigt sur un bug qui arrivait 1 fois sur 10000 sous GNU/Linux. Je savais qu'il existait mais ne pouvait le reproduire facilement sous Linux. Sous BSD, impeccable, taux d'échec de 100% donc j'ai pu cerner le problème et le corriger. Et pour le coup, un valgrind ne m'aurait pas beaucoup aidé vu qu'il n'y avait aucune fuite ni dépassement mémoire ni rien de ce genre. Enfin pas concernant ce problème particulier... Simplement, la génération de nombres aléatoires n'est pas la même sous Linux et sous BSD, et comme sous Linux elle est assez reproductible (!) je ne tombais jamais dans le cas foireux.
[^] # Re: Gentil KDE
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: Gentil KDE
Posté par nigaiden . Évalué à 4.
Sous ma Slackware, j'ai aussi un /dev/random qui doit être utilisable comme un fichier normal (en C, fopen() puis read() pour lire des valeurs aléatoires). Cependant, je ne sais pas ce que ca vaut en terme de qualité de nombres aléatoires et de plus, ce n'est pas une solution très portable.
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 1.
de meme les comportements de random varient bcp en fonction des implementations:
- sur la gnu libc, il commence a etre potable dernierement
- sur les unix pro ils sont assez mauvais a l'exception de sgi et sun (et encore dans certains cas seulement)
en general si tu veux un vrai random potable en terme de mathematiques, il faut utiliser un code fait maison :)
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 3.
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)
[^] # Re: Gentil KDE
Posté par Erwan . Évalué à 1.
Ca, ca veut seulement dire que tu connais mieux un systeme que les autres (comme tout le monde, d'ailleurs).
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 1.
par exemple: sur une station SGI une appli n'e peut allouer qu'au dessus du premier Go jusqu'au deuxieme (le 3eme n'est accessible que par mmap)
apres si tu rajoute des comportements de scheduler differents ... tu pleure
d'ailleurs si qqu'un saurait comment suspendre une thread sous solaris 5.8 en etant certain de ne pas etre dans la libc (donc en n'ayant pas une mutex de la libc prise) :)
[^] # Re: Gentil KDE
Posté par Raphael Junqueira . Évalué à 2.
Juste le cout de valgrind, gprof ca fait supra mal
# Compile distribué
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Genre un make distribué ? Je vérifie la bonne version du compilo, je t'envoie un .tgz de source, j'attend le résultat compilé. Cela serait sans doute plus utile que RC5, non ? Faut "juste" qqun qui décide qui a le droit d'envoyer des demandes de compilation.
"La première sécurité est la liberté"
[^] # Re: Compile distribué
Posté par Prosper . Évalué à 5.
[^] # Re: Compile distribué
Posté par Raphael Junqueira . Évalué à 2.
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)
[^] # Re: Compile distribué
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Mais il faut qu'il fonctionne à "l'envers", comme le client RC5/Seti@home.. Préciser les adresses est un peu délire dans un grand système. Il faut aussi tenir compte de la bande passante internet qui est bien plus faible qu'en réseau local.
"La première sécurité est la liberté"
[^] # Re: Compile distribué
Posté par Erwan . Évalué à 1.
Parce que envoyer une machine toute neuve a un developpeur, je veux bien, mais quand j'aurais monte ma start-up. (On me fais signe dans l'oreille que ce n'est plus la saison des start-up... Tant pis, j'etais pourtant plein de bonne volonte).
# autre info : KDE-Look
Posté par skimmy . Évalué à 1.
http://www.kde-look.org/news/news.php?id=41(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.