Compilons la version améliorée de Mozilla Firefox 4.0 pré-beta 6…

Ayant lu un article sur OSNews sur Mozilla qui a annoncé la disponibilité d’une version de test avec le moteur de compilation à la volée de Javascript, j’ai voulu faire compiler la version par moi-même, j’ai récupéré le code source correspondant :

[fred@fredo-arch fox]$ hg clone http://hg.mozilla.org/tracemonkey/ src/

Et ensuite, j’ai utilisé le .mozconfig suivant :

#
# See http://www.mozilla.org/build/ for build instructions.
#

export AUTOCONF=autoconf-2.13

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize
ac_add_options –disable-debug
ac_add_options –disable-tests
ac_add_options –with-ccache

Une fois la version disponible, j’ai comparé la version « classique » compilé ce matin, et la nouvelle version disponible.

Version classique : 1153 points

1153 points dans v8 avec Firefox "classique"

Version expérimentale : 1723 points soit 49,43% de plus.

1723 points dans v8 avec Firefox le compilateur JIT activé

Evidemment, on est loin de Google Chrome qui dépasse largement ce score – 5289 points environ – mais il y a du progrès 🙂

5289 points dans v8 sous chromium

La suite au prochain épisode 😉

Pino 0.3 : Le duke nukem for ever des clients twitter / identi.ca ?

Derrière ce titre volontairement provocateur, je ne fais qu’exprimer le sentiment que j’éprouve envers le coté « moribond » de ce projet. Alors que j’ai encensé de nombreuses fois ce logiciel, l’utilisant dès février 2010 – et m’occupant de la traduction sur de nombreuses versions 0.2.x

Cependant, tous les éléments qui font penser que la version 0.3.x sera – jusqu’à preuve du contraire – un vaporware :

C’est quand même dommage de voir un si bon outil devenir un vaporware… Oui, je sais, je n’ai pas le niveau de perfection dans la capacité de mettre le doigt où cela fait mal d’un certain Cyrille

gImageReader : une interface légère pour Tesseract.

Il est parfois utile d’avoir un outil d’OCR. Il existe le très bon et très puissant moteur tesseract.

Cependant, toute sa puissance est exploitable uniquement en ligne de commande :(. Il y a bien un outil comme gscan2pdf, mais il demande un nombre assez important de dépendances lié à Perl.

Même si à une époque lointaine, je l’avais encensé 🙂

En faisant quelques recherches, je suis tombé sur gImageReader, un outil en python, n’ayant que peu de dépendances, en dehors de python et de tesseract :

imagemagick pycairo pygtk python-gtkspell

En m’inspirant de PKGBUILDs déjà existants pour contourner un problème de compilation, j’ai créé un paquet disponible sur AUR : gimagereader.

Le seul hic, c’est qu’il faut définir le chemin pour accéder aux dictionnaires de tesseract. Sur mon archlinux, ces derniers sont à l’endroit suivant :

/usr/share/tessdata

Configuration de gImageReader 0.6

Bien que ce ne soit qu’une version 0.6, l’interaction avec le moteur de tesseract est simple et le résultat (pour peu qu’on ait une image numérisée de qualité – minimum 300 ppp) donne de très bons résultats.

gImageReader 0.6 en action

Un bug cosmétique, c’est que le logiciel ne semble pas apprécier un système en UTF-8 🙂

En tout cas, c’est un logiciel sympa, le genre d’outil dont on a besoin de temps à autres et dont on est content d’avoir sous la souris 😉

Petit message pour Devil505 : libre à toi de t’inspirer de mon PKGBUILD pour faire un Frugalbuild 😉

En vrac’ rapide et libre avant le week-end.

Comme le week-end approche, un petit en vrac’ se justifie.

C’est tout pour aujourd’hui. Bon week-end

Une nouveauté visuelle de Mozilla Firefox 4.0beta6 : un bouton « arrêt, rechargement, chargement » tout-en-un

Alors que la 5ième béta de Mozilla Firefox est prévue pour le 7 septembre, la 6ième béta est en cours, comme l’on peut voir avec l’identifiant d’une compilation effectuée ce matin vers 10 h 30 : Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100903 Firefox/4.0b6pre

Dans cette avant-dernière béta (7 bétas sont prévues), une nouveau graphique va simplifier la barre de tache : un bouton tout en un au niveau de la barre d’adresse, qui permet de lancer le chargement ou le rechargement, voire d’arrêter le chargement d’une page en cours.

Une image valant mieux que mille mots, voici où se trouve ce bouton :

Un aperçu du bouton en fin de barre d'adresse dans Mozilla Minefield 4.0b6pre

Pour info, cet ajout d’icone, c’est le bug 544816. En ce qui concerne le « Bouton » Firefox en haut à gauche de la fenêtre, c’est le bug 585370

Dommage que Pino sente le sapin…

Mis à part le jeu de mots raté, et bien que je n’aime pas trop gwibber, il est désormais obligatoire de passer à sa version 2.31.91 pour accéder à Twitter. En effet, le service demande désormais une authentification.

Voila ce que cela donne :

autorisation pour utiliser gwibber avec Twitter

Quand à Pino, difficile de rester optimiste, lorsque l’on sait que la dernière modification du code source date du 3 juillet, et que celui-ci ne compile pas avec des versions récentes de vala…

Installer Tracker 0.9.18 sur ArchLinux

Tracker, c’est le moteur d’indexation et de recherches de fichiers de l’environnement de bureau Gnome.

Bien qu’une version 0.8.xx soit disponible, la version de développement 0.9.18 (au moment où j’écris cet article) est très facilement récupérable. Attention, comme toute version de développement, elle peut vous exploser à la figure 😉

A noter que depuis la version 0.9.16 – et uniquement en cas d’installation du logiciel en utilisant le code source (ce qui est somme toute assez courante sous des systèmes unix) – il faut installer Vala. Dans mon cas, j’ai utilisé le paquet AUR vala-devel, qui propose la version 0.9.7 du langage. Cf http://git.gnome.org/browse/tracker/tree/NEWS

Le code étant encore en développement, l’indexation semble assez longue, à moins que la lenteur constatée ne soit liée à la compilation d’une version de Minefield en même temps 😉

Un bug assez ennuyeux, pour ne pas dire qu’il facilite franchement le transit intestinal, semble que dans la version stable, tracker semble oublié le contenu qu’il a indexé, dès qu’on ferme la session 🙁

Bref, j’ai récupéré le précédent PKGBUILD, laissé à l’abandon par son créateur, et je l’ai modifié pour qu’il soit à jour, et surtout compilable.

Pour l’installer, il suffit de taper dans une console un petit : yaourt -S tracker-git

Et d’attendre en croisant les doigts 😉

Ce que l’on constate, c’est désormais que bien que l’interface n’ait que peu changé, elle est unifié quand on utilise le clic-droit sur l’icone en forme de loupe. L’entrée « courrier » est grisée. Cela doit être lié à la non-utilisation de ma part du logiciel de courrier Evolution, client officiel de Gnome.

tracker-menu

Sinon, l’interface de recherche est toujours aussi claire. Et aussi complète 😉

une recherche dans tracker

Et comme disait la publicité pour un fabricant de compatible PC dans les années 1980-1990 : « A suivre ! »

Petite astuce pour Xorg-Server 1.9 et les pilotes propriétaires nVidia

La version 1.9 de Xorg-Server vient d’être rendu disponible sur Archlinux. Si on utilise le pilote propriétaie nVidia, il peut y avoir un problème de lancement de Xorg.

En me basant sur des infos trouvé sur le paquet AUR xorg-server-dev, il faut rajouter le fichier 10-ServerFlags.conf dans /etc/X11/xorg.conf.d/ avec le contenu suivant :

Section « ServerFlags »
Option « IgnoreABI » « True »
EndSection

Et normalement, après la mise à jour de Xorg-server en version 1.9, aucun problème 😉

v8 ou Nitro… Lequel des deux est le plus rapide et le plus respectueux de JavaScript et de ses normes ?

Dans un article récent, je parlais du progrès fait par la pré-beta5 de Mozilla Firefox 4.0, alias Minefield.

J’ai voulu voir où en était les deux autres grands noms des moteurs de rendu du logiciel libre, à savoir Chromium (et son moteur de Javascript v8), et Webkit (et son moteur de Javascript Nitro).

J’ai donc fait compilé les deux via AUR, aussi bien pour chromium-browser-svn et webkitgtk-svn. En sachant que pour le second, je ne l’ai pas installé, histoire d’éviter des conflits avec les logiciels de ma machine.

La compilation du code source de Chromium demande pas mal d’espace… 4,5 Go environ…


[fred@fredo-arch chromium-browser-svn]$ pwd
/home/fred/download/chromium-browser-svn
[fred@fredo-arch chromium-browser-svn]$ du -sh src/
4,5G src/

Webkit est quant à lui, largement moins gourmand : à peine 720 Mo.


[fred@fredo-arch webkitgtk-svn]$ pwd
/home/fred/download/webkitgtk-svn
[fred@fredo-arch webkitgtk-svn]$ du -sh src/
722M src/

Une fois les deux logiciels compilés, j’ai utilisé v8 benchmark, sputnik (pour vérifier le niveau de compatibilité avec les normes définies du langage javascript), et html5test, pour finir, histoire de voir le niveau d’avancement de ce nouveau standard du langage html.

Chromium, qui se définit comme une version 7.0.501 (7ième version, déjà, en l’espace de quoi, deux ans ?), explose largement le score au niveau du Javascript… 4961 points, soit 4,45 fois plus rapide que Mozilla Firefox 4.0b5pre… Autant dire que la Fondation Mozilla a de la marge.

Score de v8 avec Chromium

Coté respect des normes javascript, le score est plutôt bon : 5109/5246, soit un niveau de respect de… 97,38%.

Score de Sputnik avec Chromium

Enfin, en ce qui concerne html5test, Chromium fait mieux que Mozilla Firefox, avec un score de 222 points et 10 points de bonus.

Score de html5test avec Chromium

En ce qui concerne Webkit, j’ai utilisé l’outil GtkLauncher, qui offre une interface basique pour Webkit.

[fred@fredo-arch Programs]$ pwd
/homefred/download/webkitgtk-svn/src/webkit-build/Programs
[fred@fredo-arch Programs]$ ./GtkLauncher &

Le score du moteur de Javascript bien que moindre que celui de v8 reste honorable : 2984 points au benchmark v8, soit 2,67 fois le score de Mozilla Firefox 4.0b5pre. On comprend pourquoi la Fondation Mozilla veut intégrer Nitro dans son code source 😉

Score de v8 avec Webkit

Coté sputnik, le score est vraiment bon : 5069/5246, soit un niveau de respect de 96,62%

Score de Sputnik avec Webkit

Enfin, en ce qui concerne html5, le score est inférieur à celui de Mozilla Firefox et de Chromium, avec seulement 195 points et 12 points de bonus.

Score de html5test avec Webkit

J’allais oublier, le score de Mozilla Firefox 4.0b5pre pour sputnik : 4978/5246, soit un niveau de respect de 94,89%

Score de Sputnik avec Mozilla Firefox 4.0b5pre

Mis à part la vitesse d’exécution, le respect du html5 et des normes javascript sont une marque de fabrique de moteurs de rendu libre. Les moteurs de rendus non-libre ? Je ne saurais dire, je ne les utilise pas 😉

Mozilla Firefox 4.0b5pre : encore du progrès ?

Il y a une quinzaine de jours, je parlais d’une préversion de la 4ième béta de Mozilla Firefox 4.0. Désormais, on peut penser que la 4ième béta ne saurait tarder, étant donné que l’identifiant est le suivant :

Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b5pre) Gecko/20100819 Minefield/4.0b5pre

Coté test, n’ayant pas encore eu l’occasion de tester sunspider, je ne ferais que citer les chiffres brut, en faisant une différence entre les deux versions, séparées de 15 jours. La version de Minefield a été compilée environ 15 minutes avant la publication de l’article :

html5test.com : on arrive à un score de… 214 points… 14 points de mieux, ce qui est franchement pas si mal que cela 🙂

214 points au test html5 - Minefield 4.0b5pre

v8, test de vitesse de javascript : on passe de 1035 à 1114… Une progression de… 8%… Pour info, ma machine est propulsée par un AMD Athlon(tm) II X2 215 Processor (qui tourne de 800 à 2700 Mhz).

1118 points à V8 - Minefield 4.0b5pre

Bon, on est loin des scores d’un Chromium, mais le progrès est présent 😉