jy[B]log

Sur son billet "utiliser les regex avec modération", Jérôme explique que substr est plus rapide qu'utiliser preg_match. Mon commentaire sur son billet n'est apparement pas encore passé^[1], je me permet donc de répondre ici, car sa comparaison est faussée.

  $extractedString = substr( $exampleString, 1, -1 );

n'est absolument pas équivalent à

   preg_match( '#^\[(\w+)\]$#', $exampleString, $matches );

En effet, dans le premier cas, il n'y a aucune vérification que le premier caractère est bien [ et le dernier ], ni que la chaine à l'intérieur des crochets ne contient que des caractères alphanumérique, contrairement à ce qui se passe dans le deuxième cas avec l'expression régulière.

Aussi, pour avoir une comparaison équitable, il faudrait faire dans le premier cas, au moins ceci :

  if(substr($exampleString, 0, 1) =='[' &&  substr($exampleString, -1) == ']')
      $extractedString = substr( $exampleString, 1, -1 );

En conséquence, les résultats des temps d'exécution sont tout autre : le premier cas est de 2 à 5 fois plus long que l'usage de l'expression régulière. Et encore, là, je n'ai pas ajouté de vérification sur le contenu de $extractedString, pour s'assurer qu'il s'agit bien uniquement que de caractères alphanumériques (je vous laisse imaginer le code qu'il faudrait développer sans l'usage d'une expression régulière).

À la limite, l'expression régulière équivalente au premier cas, serait

 preg_match( '#^.(.+).$#', $exampleString, $matches );

Et là, effectivement, preg_match est plus lent, mais c'est ici une mauvaise utilisation de preg_match. Pourquoi utiliser une expression régulière si on ne cherche pas à vérifier la syntaxe du contenu ?

Conclusion : n'hésitez pas à utiliser les expressions régulières ^[2] quand vous voulez extraire des données d'une chaîne et en même temps vérifier l'intégrité du contenu ;-).

Je réagis à certains billets comme celui de nexen qui annoncent que in_array est lent, comme si c'était un scoop.

Franchement, tout développeur ayant un minimum d'experience en programmation (niveau IUT première année, premiers cours en algorithmie), sait que faire une recherche séquencielle dans un ensemble de valeur est plus lent que faire une recherche en passant par un index. Ce n'est pas un scoop. C'est mathématique.

Maintenant on n'utilise pas in_array pour faire la même chose qu'avec des isset. C'est comme si on s'aperçevait sur un circuit que la 2CV est plus lente qu'une formule 1. Bah oui mais la 2CV n'est pas conçu pour aller sur un circuit.

Bref, l'auteur du billet original n'a pas choisi les bonnes fonctions pour coder son truc, et il s'étonne ensuite que c'est lent. Normal quoi.

Conclusion : in_array n'est pas lent. Il fait ce qu'il doit faire. Il n'est lent que si on l'utilise dans des situations inadaptées. point.

Allez ! Hop Hop Hop ! Testeurs de tout poils, courrez télécharger Firefox 3.0RC1 ! Dernière ligne droite pour cette version dont le développement dure depuis plus de deux ans. Pleins de nouveautés, tant pour les utilisateurs, que pour les développeurs.

Si vos extensions favorites ne sont pas à jour, harcelez leurs auteurs !

Firefox 3.0 est une belle avancée. Avec quelques bémols :

• gecko 1.9 ne passe pas le test acid3 (mais l'utilisateur "normal" s'en fout comme de sa première chaussette)
• il y a un bug super génant (au moins sous linux) : le scroll de certains sites est affreusement lent, et il semble que ce soit du à certaines utilisations des bordures en CSS (je n'ai plus le numéro du bug en tête, surtout qu'en fait il y en a plusieurs). Et ce bug m'embête profondement, puisqu'il apparait en particulier quand je vais sur linuxfr.org. Je sens que les trolleurs vont s'en donner à coeur joie sur ce site...

Bon mais cela reste une très très bonne version.

Et ce n'est pas tout : Firefox 3.1 est prévu pour la fin de l'année (oui, si vite), avec, si tout va bien plein de petits trucs sympas (mais à prendre avec des pincettes, rien n'est figé) :

• XmlHttpRequest cross site
• binding JSON-DOM
• encore des améliorations sur les performances
• encore des améliorations sur la barre url
• la balise <video>
• et des améliorations spécifiques pour la version mobile de Firefox !

Et mon petit doigt me dit qu'il y aurait aussi des améliorations dans CSS. Par contre on ne sait pas encore lesquelles seront incluses dans Firefox 3.1. Ce qui est sûr, c'est qu'ils y travaillent en ce moment et il y a des patchs en cours de réalisation, voir presque prêt, dont par exemple :
** les bordures en images
** le text-shadow
** les pseudo-classes :nth-*(), :first-of-type, :only-of-type, :last-of-type...
** @font-face
** media queries CSS3
** ...

Que du bon !

Vous en avez rêvé ? Daniel et David vont l'ont fait : Les variables CSS. Pour l'instant, ce n'est que le brouillon d'un brouillon d'une future recommandation, mais les commentaires sont les bienvenu. Vous pouvez les faire sur le blog de Daniel ou ici, je transmettrai ;-).

En gros, comment ça fonctionnera (en faisant l'hypothèse que la spec ne changera pas trop :-) ) :

@variables {
 CorporateLogoBGColor: #fe8d12;
}

div.logoContainer {
 background-color: var(CorporateLogoBGColor);
}

Les variables sont définies dans un bloc d'une règle @variables. Ici la variable CorporateLogoBGColor est déclarée avec la valeur #fe8d12. Ensuite, pour l'utiliser dans les propriétés de style, on utilise l'instruction var() avec le nom de cette variable.

Alors attention, il s'agit bien d'une variable, et non pas d'une constante, puisque, cerise sur le gâteau, on peut modifier sa valeur via le DOM style. Vouloir modifier la variable CorporateLogoBGColor reviendra à faire ça :

 document.styleSheets[0].cssRules[0].variables.setVariable('CorporateLogoBGColor', '#000');

PS: je vais proposer à Daniel une manière plus simple de modifier une variable, par exemple :

 document.styleSheets[0].setVariable('CorporateLogoBGColor', '#000');

Ça fait longtemps que je n'ai pas parlé des avancées sur Etna. Donc voici quelques nouvelles.

Le nouveau validateur RelaxNG en C++ est presque terminé. Je suis en train d'implémenter nos extensions relaxng, mais d'une manière qui va être plutôt sympa : sous forme de "plugin" pour le validateur. En effet, je suis en train de rendre le validateur extensible. Ainsi un développeur pourra apporter le support de ses propres extensions RelaxNG, via un simple composant XPCOM.

Bon par contre, entre temps, une envie m'a pris de modifier l'encodeur^[1] XHTML/XML de Gecko. En effet, celui-ci ne permet pas le "pretty printing", comprendre, il ne permet pas de générer le XML de manière lisible, comme le fait l'encodeur HTML. Et c'est bien sûr une chose dont j'ai besoin dans Etna.

Bon, ça ne semble pas si intéressant que ça me direz-vous. Mais en fait si. Car cette modification va avoir quelques répercussions...

Il faut savoir que l'encodeur XML est aussi utilisé pour encoder les documents XHTML qui sont servis avec le type mime application/xml+xhtml. Par contre, pour les documents XHTML servi en text/html, c'est l'encodeur HTML qui est utilisé. En sachant ça, vous comprenez qu'en ce moment, dans Gecko, l'éditeur HTML a un support plutôt bancale de XHTML. En sortie, soit on a du HTML bien présenté, mais forcément, ce n'est plus du XHTML (voir du XHTML invalide), soit on a droit à du XHTML mais présenté brut de fonderie donc on peut avoir des lignes de textes qui font des centaines de caractères si il n'y a pas de saut de ligne dans les noeuds textes. Dans NVu, Daniel avait patché l'encodeur HTML pour que la sortie XHTML soit un minimum potable (patch non porté dans le gecko officiel), mais il était insuffisant (faute de temps) : aucun support des namespaces.

En clair, avec les modifications que je vais faire dans les encodeurs XML et HTML, je vais à la fois permettre d'avoir du pretty printing sur les fichiers XML en général, mais aussi corriger les problèmes de "sérialisation" des documents XHTML. Cela va avoir donc pour effet d'améliorer le support XHTML dans l'éditeur de Gecko.

Qui va en bénéficier me direz vous ? Tout ces petits programmes comme wymeditor, tinyMCE et consorts, qui permettent l'édition WYSIWYG du HTML dans les formulaires, et qui sont actuellement obligés de faire des hacks pourris mais hélas nécessaires quand ils veulent du XHTML, pour transformer les chaînes HTML que leur donne Gecko en XHTML valide.

Bon par contre, je n'ai pas encore terminé, et il ne faut pas s'attendre à ce que ce soit dans Firefox 3 (trop tard). Le ticket correspondant dans bugzilla : 422403.

Depuis le démarrage du développement de Gecko 1.9, les développeurs ont mis en place plusieurs frameworks de tests unitaires. Ceux-ci ont contribué largement à faire de Firefox 3 un navigateur solide, ou en tout cas un navigateur ayant le moins de régressions possible. Il y a un gros 4 types de tests :

• Mochitest, qui est un framework pour des tests nécessitant d'être fait dans une page HTML (ou XUL) chargée par le navigateur.
• reftest. Ce sont des tests sur le moteur de rendu. Le principe est le suivant : pour chaque test, on fourni deux pages HTML écrites différemment. Cependant elles sont censées avoir exactement le même aspect à l'affichage, l'une des pages servant de référence (sur le même principe que pour le test acid2 : une page pour tester, et une autre qui sert de référence^[1]). Aussi ce système compare l'"image" des deux pages, et si il y a le moindre pixel différent, le test n'est pas valide.
• xpcshell tests. Ce type de test est utilisé pour faire des tests de composants XPCOM principalement ou sur le langage javascript, et donc ne nécessitant pas d'être dans le contexte d'une page html chargée.
• stand-alone, pour faire des tests qui ne sont pas possible de faire avec les autres systèmes, donc en général quand il faut tester des classes C++, qu'il faille créer un exécutable.
• crashtests : ce sont des tests qui sont dédiés aux bugs qui causaient des crashs du navigateur. Ils vérifient donc que ces crashs ne se reproduisent plus :-)

Actuellement, pour Firefox 3, il y a plus de 46200 mochitests et 1840 reftests. Pour les autres types, il est difficile de les compter, mais il y en a aussi plusieurs centaines (voire milliers..).

Même si ça peut paraitre beaucoup, ces tests sont très loin de couvrir l'ensemble du code, et surtout de l'ensemble des centaines de composants XPCOM. La principale raison est que ça prendrait des mois à développer tout les tests unitaires, vu la complexité d'un moteur de rendu comme Gecko. Il aurait fallu commencer à construire ces tests dés le début du projet en 1998^[2], mais à cette époque, le développement piloté par les tests unitaires n'était pas une pratique connu dans le monde de l'informatique.

Et puis Firefox ne fonctionne pas si mal :-) Il n'est donc pas forcément urgent de développer des tests sur des parties dont on sait qu'elles fonctionnent bien depuis des lustres. Aussi les tests ajoutés actuellement concernent-ils principalement les corrections de bugs, les nouveautés et les améliorations.

Bonne nouvelle ! Le manager du projet Internet Explorer a annoncé dans le blog IE que IE8 fonctionnera avec le mode standards par défaut. Cela veut dire, plus de balise meta spécifique ou autre artifice pour IE8. Il faudra par contre mettre une meta ou un en-tête http spécifique pour dire que la page a été faite pour le mode "semi-standard" de IE7.

Pendant ce temps là, le test acid3 est annoncé comme stable.

En ce moment, entre les moteurs de rendu web, c'est la course à celui qui passera les tests acid3 au complet le plus tôt possible.

Je viens de voir par exemple que la nightly de Webkit a un score de 86/100 ! Alors qu'il y a quelques jours il n'en était qu'à 79/100 apparement. La nightly de Firefox (future beta4) en est aujourd'hui à 67/100. La beta 3 ayant un score de 59/100.

Quant à IE, son score actuel est... Non rien...

C'etait Laurent, du stand Mozilla, en direct du Fosdem. À vous les studios

Une nouvelle version de l'outils Flickr Uploadr vient de sortir, et elle est basée sur Xulrunner. Dans une interview, le responsable du projet Richard Crowley explique ce choix technique. Ils ont fait une étude pour savoir si ils allaient prendre Adobe Air ou Xulrunner pour cette nouvelle version. Ils ont donc finalement choisi XulRunner parce que :

• XulRunner permet de faire du multi-thread, et pas Air.
• On peut lier des bibliothèques externes avec une application XulRunner, et pas avec Air.
• La haute extensibilité de XulRunner, ce que ne permet pas Air.

Bien sûr, cela ne veut pas dire que Air soit entièrement mauvais^[1], mais XulRunner correspond mieux aux besoins des développeurs de flickr.

(via le blog Mozilla in Asia)

PS: et pendant ce temps-là, Zimbra choisi Prism pour faire un client desktop... Gecko powwaaa !

Vous souvenez-vous de la demo de vladimir, qui avait réécrit en SVG une demo de manipulation d'image fait avec Silverlight ?

Je la trouvais particulièrement lente (sous linux en tout cas). Et en fait, en regardant le code source, j'ai vu qu'il y avait quelques optimisations à faire en javascript. Voici donc une nouvelle version qui s'avère plus réactive dans Firefox 2 et 3, même si ce n'est pas encore d'une fluidité parfaite (il y a des pertes de perfs au niveau du rendu même, donc je peux rien y faire).