jeudi 20 novembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

Adopt a Geek (1042 hits)

Dépêche modérée par

Oumph

Articles : Gentil KDE

Posté par madrunner (). Modéré le 30 janvier 2003.

Scott Wheeler, lance un programme nommé "Adopt-a-geek" qui vise à fournir des ordinateurs corrects aux développeurs KDE. (A 500MHz faut 24h pour compiler KDE).

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

Adopt a Geek (1042 hits)

> Lire les commentaires (34 commentaires, moyenne: 3,5).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Re: Gentil KDE

Posté par analogue o/ (page perso, ) le 30/01/2003 à 22:00. (lien). Évalué à 17.

J'avais rien capté à la nouvelle =)

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.

--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.

Re: Gentil KDE

Posté par Leroy Frederic (page perso, ) le 31/01/2003 à 00:25. (lien). Évalué à 6.

C'est une bonne initiative, mais je me pose qd même quelques questions :
<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 (page perso, ) le 31/01/2003 à 04:05. (lien). Évalué à 16.
Pour la vitesse de compilation, un grand pas en avant devrait être gcc 3.4 je pense, avec le support des headers précompilés (quelqu'un veut bien confirmer que ce sera dans le 3.4?). D'après ce que j'avais compris, durant une compilation gcc passe une large partie de son temps à parser les headers ... et toujours les mêmes évidemment. J'attends de voir tout ça en vrai avec grande impatience. Je me demande combien de temps on peut gagner. Pour l'instant il doit me falloir 6-7 heures pour me compiler KDE d'un bout à l'autre. (athlon xp 2000+/256Mo)

Pour ceux que ça intéresse : http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html#Precompi(...)
- [+] [^]Re: Gentil KDE
  
  Posté par Paul Andre () le 31/01/2003 à 08:45. (lien). Évalué à -4.
  durant une compilation gcc passe une large partie de son temps à parser les headers ... et toujours les mêmes évidemment.
  
  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 () le 31/01/2003 à 10:22. (lien). Évalué à 5.
    mé bien sur...
    
    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 (page perso, ) le 31/01/2003 à 10:36. (lien). Évalué à -1.
      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)
    - [^]Re: Gentil KDE
      
      Posté par Paul Andre () le 31/01/2003 à 10:41. (lien). Évalué à 2.
      Il faut aussi voir que c'est surtout pratique pour les librairies standard.
      
      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 (page perso, ) le 31/01/2003 à 10:28. (lien). Évalué à 7.
    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
    - [^]Re: Gentil KDE
      
      Posté par Philippe Fremy (page perso, ) le 31/01/2003 à 12:56. (lien). Évalué à 2.
      cccache, ccdist, headers precompiles, il y a quelques trucs pour gagner un peu de temps. Mais au final, quand tu fais un cvs update et que des fichiers ont ete touches, il faut les recompiler, il n'y a pas le choix. Et tous les developpeurs ont pratiquement le dernier KDE sous la main en permanence, qu'ils compilent a longueur de journee.
      
      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!
      
      --
      phil.freehackers.org
      - [^]Re: Gentil KDE
        
        Posté par Paul Andre () le 31/01/2003 à 13:05. (lien). Évalué à 1.
        Et pourtant, j'ai une machine qui devrait donner un gros avantage a gcc.
        
        uh ? tu peux en dire plus ?
      - [^]Re: Gentil KDE
        
        Posté par Raphael Junqueira (page perso, ) le 31/01/2003 à 13:10. (lien). Évalué à 1.
        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)

[^]Re: Gentil KDE

Posté par ufoot (page perso, ) le 31/01/2003 à 06:56. (lien). Évalué à 4.
> "recompilent-ils tout kde à chaque fois qu'ils changent une ligne ?"
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 (page perso, ) le 31/01/2003 à 12:54. (lien). Évalué à 1.
"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, ....
- [^]Re: Gentil KDE
  
  Posté par Nicolas Boulay () le 01/02/2003 à 15:07. (lien). Évalué à 0.
  Vi ?
  
  Emacs, le fait bien mais il faut une machine puissante et de la mémoire.
  - [^]Re: Gentil KDE
    
    Posté par kadreg () le 02/02/2003 à 12:47. (lien). Évalué à 2.
    Donc il fait pas.
    
    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 (page perso, ) le 02/02/2003 à 16:00. (lien). Évalué à 2.
      c'est clair que c'est ca qu'il me faudrait,
      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 (page perso, ) le 02/02/2003 à 15:58. (lien). Évalué à 1.
    non
    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 (page perso, ) le 31/01/2003 à 05:38. (lien). Évalué à 18.

PENSEE DU MATIN :
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 (page perso, ) le 31/01/2003 à 07:48. (lien). Évalué à 9.
D'un autre côté, c'est pas avec un pentium 200 et 64Mo de RAM que tu vas réussir à faire tourner un programme sous valgrind pour détecter les fuites de mémoire et voir quelles sont les parties à optimiser en priorité ...
- [^]Re: Gentil KDE
  
  Posté par printakilla () le 31/01/2003 à 08:42. (lien). Évalué à 0.
  Je suggère de faire la compilation sur une petite machine (pour apprendre aux développeur à optimiser) et sous Ouindows (les fuites mémoires se verront immédiatement)
  ^_^
  - [^]Re: Gentil KDE
    
    Posté par ufoot (page perso, ) le 31/01/2003 à 08:55. (lien). Évalué à 7.
    > et sous Ouindows (les fuites mémoires se verront immédiatement)
    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 () le 31/01/2003 à 09:21. (lien). Évalué à 0.
      Si tu utilise random() sous linux il utilise toujours 1 comme graine. Il faut explicitement lui donné autre graine (à coup de rdtc ?). C'est pratique pour débugué d'avoir toujours la même graine...
      - [^]Re: Gentil KDE
        
        Posté par nigaiden () le 31/01/2003 à 09:45. (lien). Évalué à 4.
        La commande pour initialiser le générateur de nombres aléatoires est srandom() (voir pages de manuel pour plus de détails). Pour avoir une initialisation aléatoire, le mieux est de faire quelque chose comme srandom(time()); (avec quelques conversions de type me semble-t-il).
        
        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 (page perso, ) le 03/02/2003 à 12:52. (lien). Évalué à 1.
        /dev/random c'est pas vraiment portable.
        
        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 (page perso, ) le 31/01/2003 à 10:40. (lien). Évalué à 3.
      > 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)
      - [^]Re: Gentil KDE
        
        Posté par Erwan (page perso, ) le 03/02/2003 à 11:16. (lien). Évalué à 1.
        Pire, souvent c memes les os qui te pourrissent la vie.
        
        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 (page perso, ) le 03/02/2003 à 12:48. (lien). Évalué à 1.
        j'en suis bien conscient, bien maintenant je commence a bien en connaitre 2-3 mais les differences de comportement sont telles ...
        
        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 (page perso, ) le 31/01/2003 à 10:42. (lien). Évalué à 2.
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

Compile distribué

Posté par Nicolas Boulay () le 31/01/2003 à 09:25. (lien). Évalué à 2.

Question bète, si la compile est un problème, n'est-il pas possible d'écrire une application de distribution de compilation à travers internet ?

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.

[^]Re: Compile distribué

Posté par PasChauve PasOunet () le 31/01/2003 à 09:43. (lien). Évalué à 5.
genre ca : http://distcc.samba.org/(...) ?
- [^]Re: Compile distribué
  
  Posté par Raphael Junqueira (page perso, ) le 31/01/2003 à 12:46. (lien). Évalué à 2.
  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)
- [^]Re: Compile distribué
  
  Posté par Nicolas Boulay () le 01/02/2003 à 15:11. (lien). Évalué à 1.
  Bien ça !
  
  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.

[^]Re: Compile distribué

Posté par Erwan (page perso, ) le 03/02/2003 à 11:19. (lien). Évalué à 1.
Bonne idee, plutot que de gaspiller son temps CPU a ecouter les extra-terrestres ce serait tres bien de pouvoir participer a un kde-thon (ou <projet>-thon) sans debourser un centime.

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 () le 31/01/2003 à 12:14. (lien). Évalué à 1.

Lindows devient sponsor de KDE-Look et affermi ainsi son image aupres de la communauté :

http://www.kde-look.org/news/news.php?id=41(...)

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : Gentil KDE

Re: Gentil KDE

Re: Gentil KDE

[^]Re: Gentil KDE

[+] [^]Re: Gentil KDE

[^]Re: Gentil KDE

[+] [^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

[^]Re: Gentil KDE

Compile distribué

[^]Re: Compile distribué

[^]Re: Compile distribué

[^]Re: Compile distribué

[^]Re: Compile distribué

autre info : KDE-Look