liberforce a écrit 4730 commentaires

Hum... Quel est l'intérêt d'un B-tree par rapport à une table de hachage dans ce cas ? Tu peux faire une table de hachage contenant tes listes de paquets correspondant à ta connnexion.
http://developer.gnome.org/doc/API/2.0/glib/glib-Hash-Tables(...)

Si l'ordre d'arrivée des paquets est important, tu peux même utiliser les files.
http://developer.gnome.org/doc/API/2.0/glib/glib-Double-ende(...)
L'avantage est que tu peux rajouter un élément à la fin en temps constant. Tu n'as pas besoin de parcourir la liste entière pour rajouter cet élément à la fin. En tout cas vu ce que tu veux faire, c'est la solution que j'adopterais, à moins qu'il n'y ait une bonne raison (que je ne vois pas) pour utiliser un B-tree...

Hum... Tu es sûr que c'est bien une liste que tu dois utiliser ? Tu es sûr que ce n'est pas juste un nouveau noeud dans le btree ? Sinon, pour les listes, oui la GLib en a: GSList pour les listes simplement chainées, et GList pour les listes doublement chainées. Pour connaitre tous les types d'éléments fournis par la GLib, regarde la doc: http://developer.gnome.org/doc/API/2.0/glib/glib-data-types.(...)

Mais qu'est ce que tu essaie de faire au juste ?

Ah, pour les g_slice_*, ce n'est intéressant que si tous les objets ont la même taille. Donc si tu veux allouer/désallouer plein d'objets de 15000 octets, c'est ce qu'il faut utiliser. Mais là dans ton cas, vu que la taille des données est variable, ce n'est pas indiqué: autant ne stocker que ce dont tu as besoin.

GArray est fait pour stocker plein d'objets de taille fixe, pour ne pas avoir besoin d'allocation dynamique. Pour toi ce n'est pas possible, car tes objets ne font pas tous la même taille. Tu pourrais dans ce cas utiliser GPtrArray qui est fait pour stocker un pointeur vers des données (que tu allouerais dynamiquement), mais dans ce cas aussi, tu perds la taille de tes données.

Conclusion: si tu veux pouvoir accéder à tes données sans risquer d'aller lire en dehors des limites du buffer où elles se trouvent, tu dois utiliser une structure qui contient:
- la taille de ton buffer
- un pointeur vers ton buffer de données

Tu peux le faire à la main, c'est simple, mais si tu n'as pas envie de te prendre la tête, tu utilise une GString, qui le fait à ta place . Si tu la crées avec g_string_new_len, tu peux spécifier la taille de tes données, et dans ce cas là, la chaine à copier est autorisée à contenir des caractères '\0'. Ton code ressemblera alors à :
value = g_string_new_len(m->payload, m->data_len);
g_tree_insert(Storing_B_Tree, key_one->str, value);

Tu accèdes ensuite à ton buffer avec value->str et tu en connais la taille grâce à value->len. Avec ça tu ne consommes juste ce qu'il faut de mémoire, pas plus, et connais toujours la longueur de tes données.

Quoi, tu voudrais dire que dans "Alias", ils ont recompilé échelon avec CMake ?
~~~~> [ ]

Ah, en plus pour copier tes 52 octets, tu en lis 1500 (donc que tu lis n'importe qui dans la mémoire).

Pourquoi utilises tu un GArray si c'est pour y mettre un seul élément ? Fais juste un g_new/g_new0, ou mieux, un g_slice_alloc/g_slice_alloc0.

Wouah, ça a l'air compliqué son métier :-)

News très claire et très bien rédigée, il fallait bien ça vu les nouveautés dont regorge à chaque version le noyau !

http://wiki.mandriva.com/fr/Accueil
http://wiki.mandriva.com/fr/Choisir_la_bonne_version

.

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.