liberforce a écrit 4744 commentaires

http://en.wikipedia.org/wiki/Mmap

http://en.wikipedia.org/wiki/Ext3

à la gloire de rachida dati et de tintin ?

Toutes mes confuses, après avoir recommandé l'article, on m'a renvoyé sur la dernière page consultée, et pas sur la première page de l'article comme je le pensais...

Non, mais par contre, ça vulgarise bien les problèmes, et dans un média de masse. Le mettre en avant, c'est faire partager avec un article compréhensible pour tous.

En gros, toi tu n'apprends rien, mais par contre, tu as un bon lien à ressortir le jour où te sort l'excuse habituelle: "pourquoi refuser si t'as rien fait de mal ?" (vous savez, l'excuse qu'on nous sort aussi pour la télésurveillance).

Bin moi je me suis rendu compte y a pas longtemps que je pouvais jouer à Neverwinter Nights avec les pilotes libres pour mon ATI 9800 pro ! Ah, il est où le temps où je perdais ma soirée à installer les pilotes proprio...
Bon, par contre au niveau performances, j'aurais bien voulu comparer, faudrait que je vois comment afficher les FPS du jeu.

s/redirectionne/redirige/
Faut pas déconner quand même...

Pour l'adresse que tu m'avais demandé: nntpserver.tele2.fr , mais je ne sais pas si la qualité de service est là, j'ai pas testé...

Ha, bé je comprends mieux pourquoi une meuf de meetic avec qui j'avais pas parlé depuis deux ans m'a envoyé une invitation pour un site à la con de genre... Je me disais aussi, un geek qui se fait contacter par une fille, c'est louche.

Cherchons où se trouve ce fichier:
[luis@donald ~]$ urpmf libmp3lame.so
liblame0-devel:/usr/lib/libmp3lame.so
liblame0:/usr/lib/libmp3lame.so.0
liblame0:/usr/lib/libmp3lame.so.0.0.0

Donc le fichier que tu veux se trouve dans le package liblame0.

[luis@donald ~]$ urpmq --sources liblame0
ftp ://ftp.free.fr/pub/Distributions_Linux/plf/mandriva/2007.1/free/release/binary/i586/liblame0-3.97-2plf2007.1.i586.rpm
Bon en plus, je peux voir que j'ai ce package disponible parce que j'ai ajouté le média plf-free à ma distrib. Pour cela, comme dit plus haut, il faut passer par http://easyurpmi.zarb.org .

Ensuite: urpmi liblame0.

Tu peux essayer d'installer les smartmontools pour vérifier que ce n'est pas un problème de disque dur. Effectivement, commme toi j'aurais pensé à un problème de RAM, mais si memtest est muet...

De rien :-)
Ah, si tu veux encore plus utiliser la glib, avec les facilités qu'elle propose, tu peux remplacer les fprintf(stdout,...) par g_print par exemple.

Je ne peux que t'enjoindre à lire la documentation de la glib, dont les opérations sur les chaines de caractères, qui fourmillent de fonctions plus agréables que celles de la lib standard du C:
http://developer.gnome.org/doc/API/2.0/glib/glib-String-Util(...)

Mouaip, sachant que là il crée des objets qui n'ont pas tous la même taille (chaine de caratère dont à priori on ne connait pas la taille à l'avance). Si par contre il crée de nombreuses fois le même objet, une structure par exemple, alors il vaut mieux se pencher sur les memory slices, plus performants en terme d'allocation, désallocation: http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slic(...)

Ça n'a rien à voir avec les B-Tree. Tu donnes toujours l'adresse du même emplacement mémoire à placer dans le B-Tree, quel que soit le noeud: intkey et intval. Ils sont créés dans la pile alors que tu devrais les créer dans le tas (donc avec un truc qui *alloue* de la mémoire) ! En plus dès que tu sors de ton "for", tes tableaux n'existent déjà plus (demande à ton prof des détails sur la visibilité d'une variable)!

Ce sera vrai avec des GNode, des GSList, des GList, etc... C'est à toi de créer la mémoire qui stocke tes données, le boulot des GTree, GNode, et. c'est juste de pouvoir retrouver cette mémoire.

Donc commence par installer devhelp qui t'aidera à trouver les fonctions que tu veux.
Ensuite, si tu remplaces tes tableaux de gchar par des gchar * que tu fais pointer à de la mémoire alloué sur le tas (heap) et pas sur la pile (stack) comme tu le faisais, bin ça marchera.


Ainsi par exemple:

gchar intkey[4];
snprintf(intkey,4, "%d", i);

Devient:

gchar *intkey;
intkey = g_strdup_printf("%d", i);

N'oublie pas que cette mémoire allouée, tu dois dois la désallouer quand tu n'en as plus besoin, pour éviter les "célèbres" fuites mémoire (memory leak). Utilise g_free pour cela.

Un fichier .so n'est pas une archive. Il ne contient pas d'autre fichiers. C'est un objet partagé (Shared Object), d'où son nom. On appelle cela aussi une bibliothèque partagée. Elle contient juste les points d'entrée vers les symboles (fonctions, variables) définies dans la bibliothèque comme étant accessibles de l'extérieur.

Pour t'en convaincre, utilise la commande file.

[luis@donald .libs]$ file -i libgmcontacts.a
libgmcontacts.a: application/x-archive
[luis@donald .libs]$ file -i /lib/libpopt.so.0.0.0
/lib/libpopt.so.0.0.0: application/x-sharedlib, stripped

La commande nm peut te donner des infomations sur un objet les symboles définis à l'intérieur, du moment qu'ils n'ont pas été retirés avec strip. Après il existe peut être un commande ou un programme pour connaitre les points d'entrée d'un .so, mais je ne la connais pas. Et si rien ne marche, il reste la commande strings qui permet d'afficher les chaines de caractères contenues dans le fichier, et permet de retrouver des symboles (parmi bien d'autres choses).

C'est simple: tu ne passes pas 3 plombes à te demander "C'est quoi déjà la commande qui fait ça ? C'est quoi les paramètres ? C'est dans quelle section de l'aide ?". L'outil en lui même n'a aucun problème en terme de fonctionnalité. La preuve en est bien que tous les autres débuggers sont des fontends à gdb. Les problèmes que l'on évoque, c'est ceux de l'interface entre l'utilisateur et outil, les problèmes d'ergonomie.

Si tu t'en sers tous les jours, gdb convient tout à fait. Mais perso je ne sors mon débugger que quand j'ai un problème hors norme que je n'arrive pas à repérer avec du "printf debugging". Résultat: impossible de me rappeler les bonnes commandes gdb vu que je ne l'utilise pas assez souvent. Une IHM te donne beaucoup plus d'information plus rapidement quand tu es un utilisateur occasionnel, et demande moins d'apprentissage.

C'est à l'outil de s'adapter à l'utilisateur et pas l'inverse.

Pour avoir essayé d'apprendre à utiliser gdb et gnuplot, je peux te certifier que le temps d'apprentissage n'en vaut pas la chandelle: si tu t'en sers tous les 36 du mois tu ne retiens pas 1/4 des commandes, alors qu'en comparaison, débugger un programme sous Visual C++ 5 était ultra facile.

La ligne de commande c'est bien, mais quand chacun se met à réinventer son propre langage, ça devient lourd. C'est là qu'une IHM peut te faire gagner beaucoup de temps.

ouaip, pas assez puissant.

Franchement, ddd c'est antédiluvien, et franchement je ne le trouve pas très pratique non plus. Mais c'est toujours mieux que gdb en ligne de commande...

Effectivement, ce qui manque réellement, c'est un bon débuggeur, ou plutôt un bon frontend pour GDB. C'est pour ça que le projet Nemiver a été lancé, et qu'on espère qu'il sera intégré à GNOME un jour.
http://home.gna.org/nemiver/

Anjuta a malheureusement mis tellement de temps à se stabiliser ou même à devenir exploitable qu'il a bien fallu trouver d'autres solutions. Moi je venais du monde Windows + Visual C++, ça m'a fait bizarre quand j'ai cherché l'équivalent sous Linux... Depuis je suis passé à vim+autotools, mais je ne suis plus très sûr qu'un outil unique soit LA solution, tout simplement parce que ça devient un monstre trop lourd à maintenir et à s'adapter aux nouveautés dans ce domaine...

M'enfin ce nouvel anjuta mérite un coup d'oeil (j'y avais touché l'année dernière et il plantait régulièrement sur l'assistant de création de projet, ce qui m'avait pas mal découragé). J'espère que la stabilité s'est améliorée.

26 juin : Un habitant a quitté linuxfr pour trouver un emploi.

Et puis d'abord, linuxfr tu l'aimes ou tu le quittes !

Ne pas perdre 2 heures à mater un navet (+ le temps pour le télécharger) ?

En même temps si c'est nul, les gens sont pas cons, il vont pas le pirater non plus, non ?

Je propose "chenapan numérique": ainsi il n'y aura plus confusion avec un gars avec un gars sapé comme Keith Richards.