Rappelons que Beagle est un outil d'indexation et de recherche de données dans la philosophie de Google Desktop sous Windows, Spotlight sous Max OS X ou Kat sous KDE. Il peut indexer un grand nombre de types de document (bureautique, courrier, documentation, messages instantanés Gaim et Kopete, meta-données d'images ou de fichiers audio, etc.).
Cette version corrige bien sûr un grand nombre de bugs mais propose surtout de nouvelles interfaces d'interrogation du moteur d'indexation :
- Interface graphique : Holmes en remplacement de l'ancienne interface best
- API : interface en python avec pyBeagle et C avec libbeagle
Beagle supporte les sources de données suivantes :
- Systèmes de fichiers
- Evolution courrier, calendrier et carnet d'adresses
- Messagerie Instantanée Gaim, Kopete et journaux IRC
- Navigateurs Web Firefox, Epiphany et Konqueror
- Lecteur RSS Blam, Liferea et Akregator
- Notes Tomboy
- Client de courrier électronique KMail
et les formats de fichiers suivants :
- Documents de bureautique
- OpenOffice.org (sxw, sxc, sxi et plus)
- OpenDocument (odt, ods, odp)
- Microsoft Office (doc, xls, ppt)
- AbiWord (abw)
- Rich Text Format (rtf)
- Documents textes
- HTML (xhtml, html, htm)
- Source code (C, C++, C#, Fortran, Java, JavaScript, Lisp, Matlab, Pascal, Perl, PHP, Python, Ruby, Scilab et scripts Shell)
- Texte brut (txt, et tout autre fichier texte non géré spécifiquement dans une autre catégorie)
- Documentation et aide
- Texinfo
- Pages man
- Docbook
- Monodoc
- Fichiers d'aide Windows (chm)
- Images (jpeg, png, svg)
- Audio (mp3, ogg, flac)
- Lanceurs d'application
Aller plus loin
- Projet Beagle (3 clics)
- Annonce Beagle 0.2 (2 clics)
- Exemple de recherche avec Holmes (1 clic)
- Dépêche DLFP de la version 0.1 (2 clics)
# Beagle 0.2.1
Posté par Manger sur pattes . Évalué à 6.
Pas grave, avec des news aussi complète que celles de linuxfr, un peu de décalage ne fait de mal à personne ;)
Sinon, mes félicitations à toute les contributeurs du projet, Beagle est tout simplement excellent !
[^] # Re: Beagle 0.2.1
Posté par Victor . Évalué à 5.
http://mail.gnome.org/archives/dashboard-hackers/2006-Januar(...)
[^] # Re: Beagle 0.2.1
Posté par dco . Évalué à 2.
Juste le pourquoi de cette version éclaire (cf lien de kakaouete) :
"The widespread exposure of our new user interface helped us uncover a handfull of bugs which are fixed in this release."
traduction doc(tm):
La grande diffusion de notre nouvelle interface nous a aidés à décourvrir une poignée de bugs qui ont été corrigés dans cette version
# Interessant
Posté par Stibb . Évalué à 10.
Pour l'interface graphique, ok, ça peut se comprendre, développement rapide, en classe, et tout et tout, mais je suis désolé, un mono qui tourne en demon (donc tout le temps, qui te prend beaucoup de mémoire), je trouve que ça pue. Pas que ma puissance CPU est limité, mais j'aimerais pas que mes ressources soient gaspillés. Gaspillé par quoi? Par l'interprétation, par un garbage collector (qui de facto utilise plus de mémoire (je rempli tant que j'ai de la place, je nétoi quand j'ai du temp ou plus de place) qu'un code C/C++ bien développé).
Je veux pas avoir une VM Mono (Java c'est pareil) qui te prend 200Mo parce qu'il a vu que j'avais de la place, et que si je lance un nouveau programme ca commence à swappé... alors que l'espace techniquement utilisé est bien moindre.
Voila, Beagle est un projet très intéressant, dans le principe, mais C# (que je connais bien, j'ai déjà travaillé dessus), si c'est une excélente technologie Front End, je ne l'aurais JAMAIS choisi pour le Back End (surtout un backend qui fait un traitement en tâche de fond en continue).
Pour mieux me comprendre, je ferais la même remarque que l'on fait à Vista : Faut une centrale nucléaire pour le faire tourner?
Vais m'écrire un driver en Visual Basic, tiens, comme ça a l'air d'être la mode. En plus, on peut compiler en .NET ca sera TROP la classe. Suis sur que si un gars nous pond un compilateur qui s'arrange pour fouttre une VM (.NEt, Java, Python) pour un module noyau y a des gens qui seraient capables de l'utiliser en disant que c'est l'avenir...
(Remarque : voir le systeme d'exploitation en C# http://en.wikipedia.org/wiki/Singularity_(operating_system) qui est techniquement intéressant).
Dsl pour le troll
[^] # Re: Interessant
Posté par freeflight00 . Évalué à 2.
Arrete de compter tes mégas perdus et compte le temps que tu gagnes ;)
Quant au choix du langage, le libre, c'est également laisser le choix aux devs d'utiliser les outils qu'ils veulent... y compris ceux qui ne te parraissent pas optimisés.
Néanmoins, c'est en utilisant un langage dans des rôles délicats et critiques qu'il se bonnifie. Si tu le cantonne a faire qu'un rôle, il ne risque pas de s'améliorer.
Enfin, Beagle c'est en partie Nat Friedman et ses joyeux drilles de chez Novell (Icaza, etc...) qui sont les instigateurs de Mono. Ca m'aurait étonné qu'ils utilisent autre chose. Puis Beagle est quand meme un formidable outil de promotion du langage...
[^] # Re: Interessant
Posté par Stibb . Évalué à 2.
Et je comprend pas les insultes des deux autres zigotos qui me prennent de haut. J'ai pas le temps de leur répondre autrement que par mon mépris, s'ils veulent des explications, je me ferais un plaisir de leur expliquer exactement mes connaissances en la matière, certes humble, mais qui couvre comment fonctionne une machine virtuelle (en fait uniquement les VM Java et .NET, certes pas celle de Mono), qu'est ce que la compilation dynamique, qu'est que le MSIL et à quel point c'est tout sauf Natif (c'est natif qu'après la compilation dynamique), ...
Mon (humble) expérience me fait dire ceci: .NET ne me semble pas adapté pour un tel travail. Après je me goure peut être et je retourne à mon champs cultiver mes carottes.
[^] # Re: Interessant
Posté par TImaniac (site web personnel) . Évalué à 3.
Ben voilà t'as l'explication qui fou en l'air tout ton raisonnement : Beagle c'est un daemon, la compile JIT est effectuée pendant les première secondes, voir pas du tout si Beagle est compilé en natif avant (AOT), après le service tourne pendant toute sa vie de service en natif, c'est quand même le principal pour un daemon non ?
[^] # Re: Interessant
Posté par TImaniac (site web personnel) . Évalué à 1.
Pourquoi pseudo compilé ? Pourquoi interprété ? C# n'a pas été conçu pour être interprétable, et Beagle n'est PAS interprété. C'est du code natif qui tourne, aussi vite que ton code écrit en C ou n'importe quoi.
Gaspillé par quoi? Par l'interprétation
Y'a aucune phase d'interprétation. C'est pas du javascript !
, par un garbage collector (
Le GC a des inconvénients, mais aussi des avantages : il est capable de recycler la mémoire, il intervient aux moments opportuns (quand le CPU est peu utilisé par exemple). Tu pourras toujours reproduire le même comportement en C/C++ mais de façon très difficile. Et les projets bien "codés" comme tu dis utilises de plus en plus d'approches similaire, comme Apache qui gère une pile mémoire un peu comme un GC.
qui te prend 200Mo parce qu'il a vu que j'avais de la place, et que si je lance un nouveau programme ca commence à swappé
Ca c'est n'importe quoi. Lorsque les ressources mémoires sont trop faibles, le GC s'active et fait du nettoyage pour éviter justement de swapper inutilement.
Le problème général n'est pas du au GC "qui bouffe de la mémoire" mais à la conception de l'application : en java ou C# on se permet parfois de bouffer inutilement de la mémoire en créant des millions d'objets impossible collecter par le GC : là tu bouffes de la mémoire et tu swappes. Mais tu le dis toi même : faut bien coder. Tu peux avoir exactement le même comportement en C/C++ en allouant plein de mémoire.
Dsl pour le troll
C'est rigolo les trolls, mais pour bien troller faut normalement faire semblant de partir sur des vérités pour ensuite dériver sur des conclusions par un raisonnement volontairement fallacieux. Toi tu pars direct avec des idées reçues déjà mainte et mainte fois tuées : C# n'est pas interprété et le GC ne bouffe pas de ressource, c'est le programmeur qui en demande trop.
Enlève toi de la tête cette idée de machine virtuelle, ce n'est qu'un point de vu des compilateur et du développeur, à l'exécution il n'y a qu'un environnement d'exécution proposant des services (GC, sécurité, etc.) et un programme qui tourne en NATIF.
[^] # Re: Interessant
Posté par gallenza . Évalué à 2.
[^] # Re: Interessant
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Interessant
Posté par gallenza . Évalué à -7.
[^] # Re: Interessant
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Interessant
Posté par boubou (site web personnel) . Évalué à -4.
[^] # Re: Interessant
Posté par Stibb . Évalué à 10.
Je ne donne pas de source expérimentale, certes, car on fait dire ce que l'on veut à des chiffres et surtout à des benchmarks (cf Apple).
J'utilise tous les jours mon ordinateur et je constate pas mal de chose : les applications Java/.NET sont des bouffes mémoires.
Ex: Freemind (programme que j'adore) me prend après une journée d'utilisation 80 Mo. ca te semble normal, toi?
Eclipse, après quelques heures, me prend plus de 500 Mo. Toujours normal? Pourtant eclipse est un programme extraordinaire que j'adore, mais il me faut bien 1Go de ram pour être confortable avec.
Visual Studio n'a jamais atteind une telle occupation en mémoire. A j'oubliais, je travaille aussi bien sous windows que sous linux.
Et je vais pas faire un cour sur le fonctionnement d'une machine virtuelle, sur l'interprétation du byte code. Je suis conscient des avantages et inconvéniant de cette technologie, pour moi (humble avis), elle n'est pas adaptée pour un démon.
Si vous me traitez de pitoyable, je vous execre Boubou, et vous laisse dans votre médiocrité. Soyez poli. Merci
[^] # Re: Interessant
Posté par LeMagicien Garcimore . Évalué à 3.
Dans .NET, le code CIL est compilé en code natif avant l'exécution. C'est donc bien du code natif qui tourne.
http://msdn.microsoft.com/library/default.asp?url=/msdnmag/i(...)
La VM Java de sun est différente, elle compile en natif uniquement le code qui est souvent utilisé, le reste est interpreté.
http://java.sun.com/j2se/1.4.2/docs/guide/vm/index.html
Avant d'envoyer chier tout le monde, renseigne-toi. Un peu d'humilité, ça fait jamais de mal et ça evite de passer pour un couillon.
(J'espère que j'ai pas dit de conneries moi :) )
[^] # Re: Interessant
Posté par boubou (site web personnel) . Évalué à 3.
Pour l'histoire de la mémoire, l'occupation parfois délirante des JVM n'est pas liée à la notion de machine virtuelle, mais à des défauts de Java : comme on ne peut pas créer de types non objet (contrairement à C#), on subit un overhead mémoire important pour tout ce qui n'est pas type fondamentaux (un Integer prend entre 12 et 16 octets, contrairement à 4 pour un int). Cet overhead est aussi lié à la présence d'un verrou dans chaque objet pour la gestion de la concurrence. Ces problèmes n'existent pas en C#.
[^] # Re: Interessant
Posté par Julien Wajsberg . Évalué à 1.
Et je pense pas que ce soit ces quelques différences avec C# qui changent grand chose, à vrai dire...
[^] # Re: Interessant
Posté par TImaniac (site web personnel) . Évalué à 2.
L'intérêt, c'est qu'un type valeur est alloué sur la pile et non sur le tas, ce qui est est beaucoup plus efficace. Enfin faut bien voir que la pile n'a pas une taille infinie et que ces objets sont passés "par valeur", donc à utiliser quand c'est pertinent (ce qui est loin d'être le cas général).
[^] # Re: Interessant
Posté par gnumdk (site web personnel) . Évalué à 4.
>sur l'interprétation du byte code. Je suis conscient des avantages et
>inconvéniant de cette technologie, pour moi (humble avis), elle n'est pas
>adaptée pour un démon.
J'en sais encore moins que toi, mais il me semble quand meme que mono permet d'avoir soit du bytecode interprété soit du natif via un compilateur C# qui genere exactement la meme chose qu'un compilateur C, un gros binaire bien natif...
Et il me semble que .Net permet cela mais la j'en suis encore moins sur...
Voila, peut etre une explication sur le pourquoi tu te fais casser plus haut...
[^] # Re: Interessant
Posté par ecyrbe . Évalué à 9.
Je suis d'accord avec lui, l'occupation mémoire d'un daemon Mono/C# est incroyablement plus élevée que celle d'un daemon en C/C++, à fonctonnalité équivalente. Et même si la théorie nous dit qu'un daemon Mono/C# peut fort bien rivaliser avec un daemon C/C++, la réalité est tout autre.
[^] # Re: Interessant
Posté par boubou (site web personnel) . Évalué à -2.
Voilà, gros pipo, comme toujours. Et au fait, quels exemples réels peux-tu nous donner d'occupation mémoire "incroyablement plus élevée à fonctionnalité équivalente" ? J'attends (un exemple en C#, pas en Java).
[^] # Re: Interessant
Posté par Staz . Évalué à -1.
La réalité? quelle réalité? il n'y aucun deamon C/C++ à fonctionnalité équivalente à Beagle pour prouver tes dire.
[^] # Re: Interessant
Posté par ecyrbe . Évalué à 2.
Entre autre Kat qui est, je te le donne en mille, ... écrit en C++
[^] # Re: Interessant
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Interessant
Posté par Stibb . Évalué à 5.
Maintenant j'ai une question :
Le code généré est-il (attention, je parle du code produit par le compilateur dynamique de Mono ou de .net) aussi performant "algorithmiquement" qu'un code C (donc issu de gcc, avec toutes les optimisation qu'il a jugé nécessaire de faire, quand tu lui donnes un -O2) ?
J'aimerais trouvé un dump (assembleur x86) d'un traitement matématique écrit en C#, compilé en MSIL puis compilé en langage machine par Mono, puis par .NET (sous Windows). Pour voir si le code est aussi optimisé (dans ce cas précis) ...
Juste my 2 cents.
PS : il y a le compilateur Bartok qui compile le bytecode CIL en instruction x86 : http://en.wikipedia.org/wiki/Singularity_(operating_system)
[^] # Re: Interessant
Posté par TImaniac (site web personnel) . Évalué à 6.
C'est quoi le compilateur .NET ?
Dans ces environnements il y a 2 types de compilateurs :
- les compilateurs qui visent la machine virtuelles (C# --> MSIL ou Java -->bytecode)
- les compilateurs qui visent le code natif (MSIL --> x86 ou bytecode --> x86)
GCC fonctionne à peu prêt pareil : il a un frontend et un backend avec un langage intermédiaire propre à GCC. les frontend (ceux qui manipulent du C, du C++ ou jesaispasquoi) produise du code intermédiaire (ce sont des frontend), puis le backend s'occupe d'effectuer la compilation en code natif suivant la machine cible (x86 ou autre).
Comme tu peux le constater sur le papier, c'est exactement le même fonctionnement. D'ailleur c'est pas pour rien que GCC est capable de compiler du Java, techniquement les 2 phases de compilations sont similaires dans leurs objectifs.
Au final le code qui s'exécute EST du code machine x86 (ou autre) quelque soit la technique :
- Pour le compilateur GCC, le code produit est par défaut systématiquement du code machine. Il est cependant possible de lui demander le code intermédiaire.
Pour les environnement Java et .NET, la dernière étape de compilation (code intermédiaire --> code natif) est effectuée par défaut au dernier moment (Just-In-Time), au prix d'un chargement plus long mais d'une plus grande souplesse de déploiement, voir des optimisations supplémentaires : en effet, le runtime connaît exactement la configuration sur laquelle il tourne, il est alors capable d'effectuer des optimisations spécifiques, là où avec un compilateur "classique" comme GCC tu aurais été obligé de générer toute une série de binaire avec toutes les combinaisons d'optimisations possible, ou, plus généralement, t'aurais pondu un binaire optimisé de manière "générique".
Maintenant, de la même manière qu'il est possible de modifier le comportement par défaut de GCC pour qu'il génère son code intermédiaire, il est possible de modifier le comportement par défaut de Java ou .NET/Mono pour qu'il compile directement en natif, bref pour qu'un binaire x86 arrive à la sortie.
Tu sembles en douter, ben fait le test :
Java :
utilises GCJ, c'est son comportement par défaut
Mono :
mono -aot monprog.exe (AOT pour Ahead-Of-Time)
Avec .NET :
ngen monprog.exe
Le code généré est-il (attention, je parle du code produit par le compilateur dynamique de Mono ou de .net) aussi performant "algorithmiquement" qu'un code C (donc issu de gcc, avec toutes les optimisation qu'il a jugé nécessaire de faire, quand tu lui donnes un -O2) ?
Faut bien voir que même algorithmiquement identiques, des programmes écrits dans des langages différents ne peuvent être optimisés de la même façon, bien souvent à cause de la sémantique du langage. Le C est pas forcement le meilleur dans le domaine, puisque bien souvent il autorise tout et n'importe quoi, ne laissant pas vraiment de liberté au compilateur pour spécialiser un morceau de code.
Ensuite un compilateur comme GCC peut très bien te pondre du code super-optimisé sur telle plateforme (x86) et super mal optimisé sur une autre plateforme (PPC) (je dis n'importe quoi c'est pour l'exemple).
Il peut aussi y avoir de grosses différences entre les compilateurs, le compilo d'intel est par exemple beaucoup plus performant que le compilo GCC.
Donc voilà comme tu peux le constater, c'est vraiment difficile de comparer. Mais techniquement, les problèmes d'optimisations sont les mêmes en C ou C#/Java. Ce qui va ralentir ton code, une fois de plus ce n'est pas le fait qu'il y est un code intermédiaire, mais le fait qu'il est des services associés : sercices de reflexion, de gestion de types, d'isolation et plus généralement de sécurité. Ces services fournissent de nombreuses fonctionnalités aux développeurs et peuvent avoir un coup en terme de performance.
Ces services assurent une qualité de code supplémentaire non négligeable.
Mais que va faire un "bon" programmeur C/C++ ? Il va chercher à acquérir les mêmes types de services (réflexion, gestion mémoire, etc.). Comment va-t-il faire ? Il va utiliser des outils pour (GC, etc.) ou alors il va réinventer la roue, avec de forte chances que le tout soit moins bien optimisé et avec autant de bugs potentiels. Quand à certains services, il ne pourra peut être même pas les "émuler", comme tous ceux liés à la sécurité.
L'intérêt de plateformes comme Java ou .NET c'est de proposer ces services "en standard", avec une implémentation largement testée et éprouvée.
Maintenant que certains préfèrent encore se passer de ces services et gagner quelques malheureux % de temps d'exécution au risque de passer un temps fou à réinventer la roue avec des bugs potentiels supplémentaires, ca les regardent, ca peut être parfois justifier (bas niveau), mais d'une manière générale ca l'est rarement. Ou si pour le "fun".
Il faut également bien voir que les plateformes comme Java ou .NET proposent une grande quantité de classes en standards, celle-ci sont bien souvent optimisés et/ou font appels à du code natif quand c'est nécessaire.
'aimerais trouvé un dump (assembleur x86) d'un traitement matématique écrit en C#, compilé en MSIL puis compilé en langage machine par Mono, puis par .NET (sous Windows). Pour voir si le code est aussi optimisé (dans ce cas précis) ...
Si tu veux prendre un exemple "mathématique", j'ai envie de te répondre : plutôt que de passer 3 plombes en C à débugguer un segmentation fault ou autre fuite mémoire, moi je préfères affiner mon algorithme en Java en réduisant sa complexité. Ca c'est autrement plus efficace ;)
Enfin si tu veux vraiment trouver un dump, ben utilise les méthodes que je t'ai expliqué au dessus (gcj, mono -aot et ngen) pour avoir une image native :) Mais bon visiblement t'y crois pas à ce fameux code natif avant exécution :)
[^] # Re: Interessant
Posté par reno . Évalué à 2.
Ta vision des GC est un peu limité, il existe des papiers sur des GC qui dialogueraient avec la VM pour nettoyer suivant les besoins: plus de GC qui perdent des perf en sous-utilisant la mémoire ou pire qui font swapper en utilisant trop de RAM.
Exemple: "Page-Level Cooperative Garbage Collection", maintenant j'ignores s'il existe des GC et des VM qui implémentent ça, je verrais bien ce genre de chose ajoutée à Linux par exemple.
Le probleme dans ce que tu dits pour le C/C++, c'est le "bien développé", un bon exemple ou le C/C++ échoue c'est Mozilla/Firefox qui a tendance a bouffer de la RAM sans jamais diminuer, franchement à partir d'un certain niveau de complexité ne pas faire de fuite mémoire en C/C++ est très dur..
Bien sûr avec un GC on remplace la fuite mémoire par la fuite d'objets si on ne fait pas attention, mais c'est quand même plus facile à gérer..
A partir de la, j'avoue avoir une tres mauvaise experience de Java (même Sun n'est pas fichu de faire des appli Java graphique "legere" cf les outils d'admin dans Solaris9..) ou .Net pour les GUI, mais est-ce du au GC ou aux machines virtuelles?
Difficile à dire, je n'ai jamais eu l'occasion de jouer avec des appli en language compilé avec GC..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.