Matthieu Moy a écrit 3251 commentaires

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

...

Les billets de banque ont des bandes réfléchissantes pour éviter la copie trop facile. Si Xerox se met à faire des photocopies spécialement concues pour passer outre cette protection, à mon avis, ils auront aussi des problèmes.

Il y a une limite de ton système, c'est à dire que xargs est capable de construire la commande, mais la commande construite ne peut pas être executée par le système. Par contre,

find . blablabla | xargs -n 100 chmod 655

Te découpera la sortie de find en paquets de 100, et appelera chmod une fois par paquets.

> La vérification au niveau TCP (bit de parité) marche bien
> s'il y a un nombre impaire de bits qui ont été modifiés

Euh, tu confonds. Les checksum TCP sont sur plus de 1 bit, quand même ;-) (Je ne sais plus si c'est 8, 16, ou 32, mais c'est plus qu'un bit de parité)

Pour le FTP, le truc classique, c'est d'être en mode ASCII entre deux machines gérant différament les fins de lignes.

Pour le NFS, bizare bizare ...

tu peux regarder du coté de xdelta pour savoir si les fichiers diffèrent beaucoup ou pas.

> C++ c'est pareil, suffit d'utiliser les bonnes lib (et pas de recompilation)

Lesquelles ?