Yann Hodique a écrit 176 commentaires

en fait, c'est plutôt le fait que gcc donne la "bonne" taille dans le main() qui est "surprenant"

sizeof est un operator résolu à la compilation, donc rien d'étonnant à ce que sur des paramètres il ne puisse que donner la taille du pointeur.

Je ne sais pas exactement comment gcc fait, mais il doit se souvenir que v n'est pas n'importe quel int*, mais celui initialisé juste au dessus.
à noter que même dans le main(), un simple sizeof((int*)v) donne bien 4. (ce qui est heureux d'ailleurs :))

En résumé, non il n'est pas possible d'obtenir 40 dans ta fonction sans retenir l'info quelque part.

pour rappel, les arguments de la ligne de commande sont accessibles par $1 ... $9 dans le corps du script.

je ne sais pas ce que tu entends par l'ensemble des fichiers pour un utilisateur, mais il y a des chances que ça fasse intervenir un ls ou un find (voir les pages de man pour les détails), et probablement un grep pour le filtrage, voire même un cut à la fin si besoin de changer le formatage de la sortie. Ces éléments seront vraisemblablement reliés par un pipe (|) à moins que tu ne passes par des fichiers temporaires (moins élégant mais peut-être plus simple à décomposer).

Voilà, en espérant que ça t'aide à te débloquer.

Le gros avantage de vi, c'est que ca se lance en un clin d'oeil et l'édition est ultra-rapide (pratique pour la configuration du systeme). Mon ex-patron (un fanatique emacs, ne code qu'avec lui) s'est mis a apprendre vim, emacs était trop lent :-)

tiens j'en profite pour signaler aux éventuelles personnes intéressées l'existence de zile (http://zile.sourceforge.net/(...) ) qui est un emacs-light très rapide. Justement j'avais le même problème pour éditer les fichiers de config avec mon emacs, qui est assez lent à démarrer, et j'ai enfin pu faire un alias vi='zile'. Ma vie a changé :-)

'spèce de bourrin :-)

à mon avis tout ce qu'il veut c'est:
urpmi gcc-c++

je vois passer de plus en plus de commentaires disant en substance "oui mais l'utilisateur lambda...", ou "en entreprise...", ou encore "dans le monde réel...", suivi d'un certain nombre de récriminations.

Pourquoi vouloir généraliser à tout prix? Dans mon monde réel à moi (qui est finalement très virtuel, il faut l'admettre) de geek complet, bidouilleur fou, programmeur passionné, je ne retrouve rien de ce que tu racontes. Je n'ai pas envie que mes applis aient un look unifié, ed est installé, j'aime la structure du FHS, l'antialisasing me laisse de glace, j'adore compiler mes programmes pour les installer à la main, et je comprends ce que me raconte mon système. Et malgré tout ça, j'existe. (et le "modèle" que tu cites, MacOS X, me donne des crises de nerfs, je ne vais pas clamer qu'il n'est pas prêt pour le desktop pour autant)

Je sais bien que ce n'est pas le cas de tout le monde, et c'est on ne peut plus compréhensible. Néanmoins j'ai bien peur (ceci est uniquement une façon de parler) que la majorité des acteurs du libre soient plutôt comme moi que des professionnels du logiciel "grand public" (je déteste ce terme) qui raisonnent uniquement en termes de parts de marché. Après ça, eh bien si Microsoft a un bel avenir, tant mieux pour eux, c'est qu'ils répondent à une demande. En tant que développeur, je ne cherche pas à concurrencer quiconque, juste à fournir quelque chose qui m'amuse, qui m'est utile, qui marche bien, rien de plus. Pourquoi est-ce que je devrais changer?

Nan, un emacsien n'a pas UNE touche, mais une bonne centaine. Non mais!

Dans la mesure où toute variable de type Object est initialisée par défaut à quelque chose qui n'est pas un objet valide (null), il n'y a évidemment pas que des références (qui sont par définition des pointeurs valides) en Java, donc on peut très bien parler de pointeur, et tout est très clair ainsi.

Une installation qui est à refaire est une mauvaise installation ;-)

Il y a un problème, c'est certain. Je voulais juste faire redescendre sur terre les gens qui pensent que parce qu'il y a marqué unix, ça marche mieux. Je suis persuadé qu'on peut trouver un maximum de gens avec un linux qui plante, un bsd qui plante, un windows qui plante, ou même un amigaos qui plante (argh non je voulais pas dire ça, lachez moi !!)

Je ne dis pas que MacOsX est mauvais techniquement, mais simplement que jusqu'ici je n'ai aucune raison de croire qu'il est bon.

1) Depuis quelques années, MacOS est un UNIX (BSD). Donc pour tout ce qui est plantages etc, tu peux repasser.

le "Donc" me paraît très exagéré, si il suffisait d'être un unix pour ne pas planter, ça se saurait depuis le temps.

Par ailleurs, pour avoir utilisé un MacOsX (dernière upgrade) pendant toutes les vacances de noël (des fois on n'a pas ce qu'on veut sous la main :/), je peux te garantir qu'un plantage est loin d'être impensable. En fait, j'en ai expérimenté en moyenne 1 par jour. Au passage, il arrive que MacOsX plante de façon fort jolie en grisant l'écran, et en affichant un beau message en plusieurs langue demandant gentiment à l'utilisateur de bien vouloir presser le bouton power pendant quelques secondes. Ça fait tout de suite plus pro qu'un bsod, mais ça n'en demeure pas moins un plantage en bonne et due forme (c'est pas systématique hein, il peut aussi se contenter de cracher du binaire sur l'écran)

Tout ça pour dire que MacOs plante comme les autres, et que dans mon expérience personnelle, il plante environ infiniment plus qu'un linux. (encore une fois les linux sont à moi, bidouilleur, le MacOs à un utilisateur lambda qui n'installe que des choses livrées dans des boîtes en carton, ça fait peut-être une différence.....)

On a vraiment une vision très différente des distributions. Pour moi justement, c'est tout à fait un problème de la distribution de gérer l' "applicatif" (au passage je range KDE et GNOME dans l'applicatif pur également, mais je comprends ce que tu veux dire).
La distribution est une entité complète et cohérente (ou du moins devrait l'être), qui garantit à l'utilisateur qu'en n'utilisant rien d'autre que ce qui est fourni, tout marchera (modulo les bugs, of course), et que si ce n'est pas le cas on le préviendra et on lui dira quoi faire pour corriger le tir. D'où l'importance d'avoir une offre logicielle conséquente. Avec le logiciel libre, on a la chance de pouvoir tout centraliser dans un même distributeur, ça serait vraiment du gachis de ne pas le faire.

Telles qu'elles existent actuellement, les distributions mettent bien l'accent sur le fait que si tu t'écartes du chemin tracé (en compilant un truc, ou en installant un package non supporté) c'est ton problème, et ça ne les regarde plus. En agissant ainsi (en contrôlant l'utilisateur donc), on parvient à avoir un système stable.

Maintenant, imaginons qu'une distribution laisse à l'utilisateur l'applicatif (à définir), il n'y a plus de contrat de fiabilité, puisque quoique veuille faire l'utilisateur, il doit sortir de la distribution. Fatalement, l'utilisateur installera tout n'importe comment, ne mettra rien à jour et ses programmes planteront, il y aura des virus. Pour lui, c'est "Linux" qui aura failli, il n'a aucun moyen de réaliser que c'est en grande partie sa faute.

Vraiment j'espère qu'aucune distribution ne fera ce pas pour séduire le public. L'installation de logiciels est un acte d'administration, et c'est important que la personne qui l'exécute en soit consciente. Ça ne la rendra pas plus compétente (quoique c'est même pas dit) mais ça la responsabilisera. La difficulté de la tâche (enfin faut pas exagérer quand même) ne fait que refléter la complexité qu'il y a à garder une cohérence.

Quant au fait de planter son environnement... ça fait 4 ans que j'ai la même Mandrake cooker (avec des softs bien à jour donc), et j'ai eu très peu de problèmes. Mais ces problèmes, je les avais cherchés, c'était les miens, et je savais les résoudre. Je n'ose pas imaginer l'état des forums si on avait mis tous les packages "applicatifs" cooker à la disposition de toute le monde sans avertissement préalable. Ça aurait été un carnage. Tout ça pour dire qu'installer OOo2 dans un environnement qui n'a pas été testé avec est risqué, et qu'il est important d'en avoir conscience.

Désolé, je suis un peu verbeux ce soir :-)

Selon moi, le standard est le seul moyen de communication entre le concepteur et l'utilisateur: si il est violé par le concepteur, l'utilisateur doit s'en remettre à l'interprétation pour s'y retrouver (dans le meilleur des cas). Alors je suis d'accord sur le fait que le standard n'est pas une fin en soi, mais je préfère toujours qu'il y ait un changement dans le standard avant application, question d'organisation. Balancer de la feature à tout va c'est bien mais ça n'a jamais aidé à faire quelque chose qui marche.

Je ne suis pas tout à fait d'accord avec ton exemple de Firefox. Mon argument précédent n'était pas que j'attendais une prise en charge de l'application Firefox, mais plutôt celle de la libpng par exemple (au hasard) : quand la libpng du système est mise à jour, ça m'arrange que toutes les applis qui utilisent du png soient protégées. Tout simplement parce que en tant qu'utilisateur de base je ne suis pas sensé connaître toutes les dépendances d'une appli, ni même réaliser la gravité d'une faille. Alors l'inclusion des mises à jour des libs, très bonne idée, mais on perd exactement tout ce qui semble faire l'intérêt de la chose pour certains, puisque bien sûr pour pouvoir tester l'existence d'une lib, il faut la mettre dans un endroit précis, ou avoir une base de données globale. Et finalement on a réinventé un rpm ou un deb.

Pour ce qui est de l'affrontement des 2 mondes, je dirais juste que les vieux de la vieille, comme tu les appelles, ont probablement de bonnes raisons de s'accrocher à leur système, et que ce n'est pas par pur masochisme qu'ils font des choses "compliquées". Simplicité et fiabilité font rarement bon ménage.
(au passage les vrais hommes restent en console ;))

Je ne dis pas que c'est difficile, je dis juste que c'est non-standard (/usr/local/autoinstall/lib n'est pas un répertoire du fhs).

Un exemple de problème, c'est par exemple l'absence de mise à jour automatique. La bibliothèque installée sur le système recevra une mise à jour de sécurité, qui sera royalement ignorée par ton programme puisqu'il a sa version dans son coin. Il ne faut pas oublier que dans "bibliothèque partagée", il y a quand même... "partagée". Pour faire ça, autant tout compiler en statique, au moins là les choses sont claires.

disons que l'un des principaux avantages d'avoir une distribution avec système de dépendances, c'est justement d'éviter de se retrouver avec X versions de la même lib en des endroits différents parce que les programmes les cherchent en des endroits différents. Après on aime ou on aime pas (parce que les dépendances binaires ça pose des problèmes aussi), mais ça me paraît compréhensible de trouver plus propre d'éviter les doublons.

Accessoirement, installer des lib n'importe où (je me réfère à ton /usr/local/autoinstall/lib), ça implique qu'on n'est pas capable de retrouver les composants d'un programme en se référant au FHS (Filesystem Hierarchy Standard). Même chose que précédemment, on peut se moquer des standards, mais je trouve compréhensible de trouver ça important. Moi par exemple, même en tant que simple utilisateur, ça me gênerait.

Sinon, off-topic, mais t'es quand même sacrément agressif dans tes réponses.

à vue de nez, je perçois 2 possibilités de problème:
- ta config emacs ne gère pas l'utf8 correctement. voir http://www.emacswiki.org/cgi-bin/wiki/UnicodeEncoding(...) pour corriger ça
- ton terminal ne gère pas l'unicode => utiliser uxterm par exemple

si ce n'est ni l'un ni l'autre, je te suggère de passer sur #emacs où tu pourras exposer ton problème un peu plus en détail

A tout hasard, mon .emacs est ici: http://mtpforge.melting-pot.org/projects/dotemacs/file/trunk/dotema(...)
et la section qui t'intéresse est ";;; Charsets & languages"

ça se fait très facilement en écrivant un thème pour sawfish. De manière générale, tu composes le look de ta fenêtre comme tu veux avec des bouts d'image et des classes d'actions.

le binaire de chmod ne reside pas dans /usr/bin

Ça n'a rien d'un hasard, /usr/bin n'est *pas* une partie vitale du système de fichier, une machine doit être fonctionnelle sans (et en particulier bootable). La meilleure raison se trouve dans le cas de systèmes pour lesquels /usr est une partition exportée en nfs par un serveur: il faut bien pouvoir démarrer en cas de panne réseau.
Quand je fais un ls sur /bin et /sbin, j'ai a priori tous les outils de base pour administrer un système unix.

faites un ls /usr/bin .. et dites vous que tout ce qui apparait chez vous, je ne l ai plus : Eterm, xterm, kill, mozilla, *irc*, *ftp*, apt, dpkg ( les deux BASES pour proceder aux installes sous Debian ) ... bref ... plus rien.

Autant pour Eterm, xterm, etc. ça ne me pose pas de souci, autant pour le dpkg je suis surpris. D'accord il y a bien tar, gunzip, cpio et tout ça, mais bon, avoir l'outil de base d'installation de package de sa distrib dans /bin est à mon sens beaucoup plus raisonnable. Ici, sur ma Mandrake, rpm est dans /bin, et urpmi dans /usr/sbin (normal, c'est juste un front-end)... je trouve ça plus confortable quand même. Pour reprendre le scénario du /usr distant, ça sous-entend que sous debian tu ne peux pas installer un package que tu as en local "normalement" en cas de panne réseau.

Pour plus d'info sur la hiérarchie unix: http://www.pathname.com/fhs/(...)
Une lecture très saine, et qui montre bien la place de chaque chose.

P.S.: la prochaine fois que tu veux t'amuser, efface /bin ou /lib, ça c'est du sport ;-)

plutôt que de paraphraser, je te conseille la lecture de cet excellent tutoriel: http://www.reactivated.net/udevrules.php(...)

udev, c'est Bien(tm)

quant au plop, il est fort peu représenté... heureusement que dacode relève un peu le niveau.

je prends le plus facile: les bindings :)

(define-key c-mode-map ">" (lambda (arg)

                               (interactive "P")

                               (c-electric-lt-gt arg)

                               (when (looking-back "->")

                                 (semantic-ia-complete-tip (point)))))

(define-key c-mode-map "." (lambda ()

                               (interactive)

                               (insert ".")

                               (semantic-ia-complete-tip (point))))

Bon faudrait raffiner un peu, notamment, pour éviter les tentatives de completion sur

if(p-->5)

peut-être avec une regexp genre "\\(\\>\\|)\\)->"

Je ne connais pas trop tooltip, mais j'ai bien peur que ce ne soit hardcodé (ce qui est Mal(tm) d'ailleurs, et devrait pouvoir se patcher relativement facilement au niveau C en ajoutant des parametres à x-show-tip() et compute_tip_xy()). La doc de x-show-tip annonce d'ailleurs bien la couleur:

If the list of frame parameters PARAMS contains a `left' parameters,
the tooltip is displayed at that x-position. Otherwise it is
displayed at the mouse position

Enfin, pour le réglage de la fonction d'affichage du tooltip, je sais pas trop, il faudrait sans doute partir de semantic-idle-completions-idle-function

s/à part/surtout/

comme beaucoup de monde, j'avais eu la même idée, et j'ai renoncé (enfin pour l'instant du moins :-))

En tant qu'utilisateur fanatique d'emacs, ce qui me plait, c'est de pouvoir définir les fonctions qui me manquent. C'est pour ça que je ne suis pas convaincu par les tentatives d'émuler les raccourcis "habituels" d'emacs dans d'autres applis (par exemple, je suis extrêmement frustré par le mode "emacs" d'eclipse).
Donc, mon avis, la bonne méthode est de faire une kpart qui embarque un emacs complet, avec interpréteur lisp et tout :-)
Deux soucis majeurs:
- la gestion des raccourcis clavier de kde est assez moyenne et demanderait sans doute pas mal d'assouplissement
- le coeur d'emacs n'est pas très propre, et le linker proprement à kde (avec dcop et compagnie) est déjà un boulot énorme.

Une autre possibilité et de recommencer à zéro, ce qui est déprimant à souhait, mais il y a des gens qui commencent à trouver les limitations d'emacs irritantes (notamment en matière d'extensibilité au niveau C) tout en n'aimant pas xemacs. On peut donc imaginer (espérer?) voir un nouveau clone apparaître un jour ou l'autre.
D'un autre côté, en supposant que le dialect lisp employé soit compatible avec emacs-lisp (avec notamment le scope dynamique des variables qui est pas mal contesté), la réécriture du coeur d'emacs ne devrait pas être si monstrueuse.

Troisième possibilité: passer à vi, kyzis n'étant pas mal du tout (argh, je viens d'être excommunié là :-))

Pour la petite histoire, je n'ai jamais réussi à développer kdevelop dans kdevelop, tellement je suis accro à mon éditeur :-)

en résumé, c'est pas libre surtout parce que "vous, les autres, n'avez pas besoin d'un tel logiciel"?
C'est la plus mauvaise raison qu'on puisse imaginer ! (je dis pas ça méchamment hein :-))
Et malheureusement aussi la plus fréquente.
Peut-être qu'effectivement personne n'a besoin de ce logiciel, mais peut-être aussi que quelqu'un galère pour écrire un truc qui marche chez Lost-Oasis, ou qu'il y a des bouts du projet qui pourraient être réutilisés ailleurs, ou... j'en sais rien moi :-)
Pourquoi ne pas simplement laisser le soin aux utilisateurs potentiels de juger par eux-memes?

P.S.: au passage, spip et phpbb sont sous licence gpl, donc en cas de distribution, la licence de ton logiciel est toute trouvée.

Ma contribution principale restant les 18 mois que j'ai passé à contribuer à KDevelop.
Sinon, beaucoup de projets perso: un serveur de chat à base de plugins, 2 clients pour ce serveur (un en Qt/guile, l'autre dans emacs), quelques contributions à ErBot (le bot principal de #emacs), à sawfish (tabbed windows), des bindings guile pour libxosd, une config emacs de folie :-)
(et un maximum de projets à moitié commencés, qui renaîtront peut-être un jour :-))
j'en oublie sûrement...

je déconseillerais à toute personne allergique aux micro-processeurs de devenir informaticien :-)

Non sérieusement, sans avoir la moindre idée de ce que donnera son code une fois compilé, je vois mal comment écrire un code décent. (par exemple, j'imagine que ça ne choquerait pas une telle personne de passer des structures entières en paramètre, ce qui est tout de même une abomination la plupart du temps)
Ça me paraît important de savoir ce qu'on fait, non?