Matthieu Moy a écrit 3256 commentaires

L'open source, en soit, n'est pas du tout un modèle de développemement.

Regardes TeX. Il réponds bien à la définition de l'open source. Pourtant, le modèle de développement est totalement fermé. Il n'y a pas eu de nouvelle version depuis plus de 10 ans, Knuth a tout fait tout seul et il a de bonnes raisons de faire comme ça.

Ce dont tu parles, c'est le modèle de développement coopératif, qui est effectivement très lié au fait qu'un soft soit open source ou non.

Maintentant, à l'intérieur du modèle cooperatif, il y a encore pas mal de systèmes. Des cas comme le kernel Linux ou il y a une personne responsable de chaque branche, et ou les autres développeurs soumettent leurs modifications sans garantie qu'elles soient acceptées. D'autres ou il y a plusieurs personnes qui ont le droit de modifier les sources d'une branche. Des projets qui incluent tout et n'importe quoi pour expérimenter des nouvelles fonctionalités, d'autres maniaques de la sécurité et de la fiabilité ou une fonction n'est intégrée qu'après des mois ou des années de tests, ...

Lire http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/cathedra(...)

Pour une base de reflexion.

Ximian a fait une version d'OOo qui utilise GTK justement.

Je n'ai pas suivi toutes les dernières nouvelles, mais si j'ai bien compris, la version 2 de OOo sera en GTK avec possibilité d'utiliser GTK-Qt pour que tout le monde soit content.

sans -O. Pas fou l'autre, le débug de code optimisé, je laisse ça a d'autres ;-)

Oui, enfin, tu peux aussi récupérer le binaire du gcc-stage1.

Les Makefiles ne sont pas trop fait pour, mais mais le compilateur que tu cherche (gcc compilé avec icc) est bien celui qui est utilisé pour compiler stage2.

Par contre, il y a de fortes chances pour que ca ne compile pas du tout (cf. p tramo ci-dessous)

J'ai prèsque jamais utilisé d'autres debuggeurs, mais j'utilise gdb de façon intensive, et je peux t'assurer que quand ça marche, c'est super, mais pour le C++, ça ne marche pas souvent.

J'ai régulièrement des segfaults de gdb, des fois, il passe sans s'arrêter sur un breakpoint (OUI, mon code est compilé avec -g), ... Mais la situation a tendance à s'améliorer avec le temps, alors ... wait&see !

A mon avis, les chiffres sont plutôt biaisés dans l'autre sens.

MSIE t'envoies souvent sur MSN pour faire des recherches. La plupart des FAI te donnent un MSIE configuré avec leur page comme page d'accueil.

L'interface simpliste de google plait beaucoup aux geeks qui sont sous Linux+Mozilla, mais je pense que la mentalité du windowsien "de base" préfèrera souvent un truc avec du flash et des gros boutons de toutes les couleurs.

Par contre, un truc qu'ils ne disent pas dans leurs stats, c'est si c'est au nombre de hits, ou au nombre d'utilisateurs (Ils disposent en interne des deux chiffres vu qu'ils suivent les utilsateurs avec des cookies)

Tu veux aller voir le rapport de bug ?

http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00449.html(...)

J'arrive plus à décoder l'attachement en base64, mais il y avait 17 lignes si mes souvenirs sont bons. Le truc qui n'avait pas plu à gcc, c'est la présence d'un "unsigned char" dans une boucle for ou un truc du genre.

J'ai aussi déjà vu GCC partir en vrille (100% de CPU, 500Mo de RAM) sur un programme C++ de moins de 20 lignes. Mais là, c'est de la triche, il y avait des templates.

Maintenant, devines quoi : Quand un programmeur tombe sur un cas comme ça, devines ce qu'il fait ... Il change son code, et il met un truc qui compile. Du coup, oh, miracle, à la fin, il a un programme qui compile. C'est dingue, non ?

Tu sais, elle marche aussi sous Emacs ...

Et de toutes façons, elle est trop loin de mes doigts, donc, C-a est plus rapide.

En fait, le cas arch est un peu particulier: Il n'y a pas de serveur. Tout est géré coté client, et le serveur peut être un bête serveur ftp/sftp/http ... et en général, chaque développeur a sa propre archive dans son coin.

Ceci dit, avoir une interface pour donner à la fois les changements du wiki, les nouveaux bugs, et les nouvelles revisions arch, ça serait bien quand même.

Je crois en effet que tu avais zappé le smiley à la fin.

Le truc, c'est qu'en général, quand on compare deux softs, on zappe une partie des étapes pour l'un et on n'est plus trop objectif.

Mais pour en revenir à la question d'origine, oui, la ligne de commande est plus rapide pour beaucoup de choses quand on en a l'habidude, mais non, je ne l'impose à personne ;-)

> - debut de phrase: vi=0, emacs=C-A soit 1 vs 2

D'ailleurs, c'est marrant, moi, quand je suis en train d'éditer sous vi, si je tappe '0', ça écrit 0. Pour aller au début de la ligne, il faut que je tappe ESC 0 i, soit 3 touches.

Comme quoi, c'est toujours marrant de comparer des actions faites avec des logiciels différents si on ne part pas des mêmes conditions.

Ca ressemble aux trolls ligne de commande Vs GUI :

Bah, avec une gui, pour faire l'action X, j'ai juste un clic (Sous entendu: Une fois que j'ai ouvert la fenêtre appropriée), alors qu'en ligne de commande, il faut tapper pleins de lignes (Sous entendu: en partant de rien, il faut même ouvrir un nouveau terminal)


Mais ceci dit, les raccourcis claviers de vi par défaut sont très bien foutus.

T'inquiètes, un segfault de g++, j'en ai déjà vu.

Ce monsieur n'avait pas apprécié qu'on mette un unsigned int à la place d'un int.

J'ai déjà réussi à faire générer du code incorrect a gcc avec un code parfaitement banal de C pur, de moins de 20 lignes.

La prochaine version d'Emacs proposera gtk 2 comme toolkit. (Mais on pourra encore choisir xaw3d dans le ./configure)

Toi, tu n'as jamais entendu parler de viper.

Allez, qu'on rigole un peu : Le vi torturial

http://www.dina.kvl.dk/~abraham/religion/vi-tutorial.html(...)

Bien évidemment, il fallait lire

#include < string >
string ma_fonction(int x);

C'est encore templeet le méchant qui m'a bouffé une balise ...

C'est simplement que ça n'est pas possible de faire autrement ... dans

#define printf autrechose
#include <stdio.h>

la sémantique du #include est completement modifiée par le #define au dessus.

Donc, tu te fais un all.h avec tout les trucs que tu utilises souvent, et tu le précompile.

Code 5 minutes en Ada avec GNAT, et tu comprendras ce que c'est qu'un message d'erreur explicite.

Sur

#include
string ma_fonction(int x);

g++ 3.2 donne

errmsg.cpp:2: parse error before `)' token


Bon, il était pas obligé de me dire

"string should be std::string"

mais si il me disais

"string: identifier not declared"

Je serais déjà content.

En principe, l'ABI ne devait plus changer à partir de la 3.2.

Est-ce que ça veut dire que finalement, la 3.4 a encore cassé la compatibilité ?

> * Une réécriture complète du moteur de parsing du C++

Est-ce que ça veut dire que c'est la fin des "Parse error before '('" et qu'on aura enfin des vrais messages d'erreur ?

Tu es sur que c'est le /préprocesseur/ ?

Le préprocesseur, c'est un algo super con, ça traite juste les lignes qui commencent par '#' et les macros.

Tu ne confonds pas avec /front-end/ plutôt ?

(Un petit exemple pour débloquer le tout ?)

Je ne crois pas que le préprocesseur ai vraiment changé entre le 3.1 et le 3.3.

Ce qui change plus, c'est les fichiers d'en tête. Tu peux toujours essayer d'utiliser les .h de 3.1 avec un compilo en 3.3, mais c'est gore ...

Il faut savoir que GCC va en se rapprochant du standard C++, donc, porter ton code vers un GCC plus récent, dans 95% des cas, c'est corriger des trucs qui n'étaient pas du vrai C++ à la base.

C'est marrant ta vision de la ligne de commande, parce que moi, je préfère

targz monrepertoire

(Ou targz est un script de ... fou là là ... 1 ligne)

A

Allumer ma machine
Lancer KDE
Cliquer sur l'icône HOME
Chercher dans tout ce foutoire le répertoire "xxy"
Cliquer sur le répertoire "xxy"
cliquer sur le sous répertoire "zzt"
clic droit
descendre la souris
cliquer sur l'entrée de menu correspondante.


Comme quoi, quand on ne considère qu'une partie des étapes nécessaires à une tache, on n'est pas toujours objectif. ;-)

Nan, sous SuSE, c'est pas la peine, c'est tout intégré dans la distrib.

Ah, non, je confonds avec MultideskOS !

> a refusé de rendre publiques les sources,

Ce n'est pas ça qui est demandé par la GPL. Ce que Sitecom doit faire, c'est founir les sources aux gens à qui elle a fourni les binaires, pas à tout le monde. (Ca serait cool de corriger la news ...)

Par contre, si on regarde l'annonce :

In particular, Sitecom did not make any source code offering or include the GPL license terms with their products.

Donc, visiblement ils n'ont même pas dit qu'il y avait du code GPL dans leurs produits.

$ man alias
No manual entry for alias

...