lovasoa a écrit 158 commentaires

Je viens de vérifier sur l'article que j'ai mis en lien, que j'avais lu trop vite. WINDOWS-1252 n'est pas seulement très proche, il est totalement compatible avec ISO-8859-1, la seule différence se trouvant dans des caractères qui sont "non-imprimables" en ISO-8859-1. Donc n'importe quel texte ISO-8859-1 sera détecté par uchardet comme du WINDOWS-1252, et sera effectivement décodé correctement en tant que WINDOWS-1252.

C'est vrai que ça améliorerait l'empreinte mémoire. Pour l'instant, chez moi, avec 3 dictionnaires, le programme utilise au maximum 100Mo de mémoire.

Pour ce qui est du temps de recherche, je ne pense pas que ce serait mieux… La recherche dans un set python est en O(1), et est en pratique rapide.

À propos de l'algorithme: il est tout bête. On construit des HashMap (des set pythons, ici) contenant tous les mots de chaque langue que l'on veut détecter. En suite, pour chaque codec, on cherche la langue dans laquelle il donne le plus de mots d'un HashMap. On retient ce nombre de mots. À la fin, on cherche le codec qui a donné le plus de mots existants.

Bien sûr, cela implique d'avoir des dictionnaires qui comprennent toutes les formes, déclinées et conjuguées, de tous les mots. Pour certaines langues, ce n'est pas possible…

Effectivement, utiliser un autre langage de programmation devrait permettre d'obtenir de meilleures performances.

On pourrait aussi envisager de ne pas tester les couples langue-encodage qui n'ont pas de sens. Ça devrait permettre de gagner encore du temps.

Chez moi, /usr/share/dict contient aussi d'autres fichiers, qui ne sont pas des dictionnaires. Mais effectivement, il y a mieux que de lister en dur les noms des fichiers :/

Merci de toutes ces précisions et conseils. Je suis très content d'avoir le mainteneur d'uchardet parmi mes lecteurs!

C'est vrai qu'uchardet ne supporte pas ISO-8859-1, mais tu devrais peut-être préciser aux lecteurs qu'il supporte WINDOWS-1252, qui est très très proche, et qui permet donc souvent de décoder ses fichiers texte en français sans problèmes.

Je me réjouis grandement de savoir que bientôt gedit ouvrira naturellement les fichiers textes qui ne sont pas en UTF-8. Merci pour ton travail, il me sera utile!

Effectivement, mon approche est plus complexe algorithmiquement, mais c'est le prix à payer pour des résultats plus fiables. Je pense que mettre uniquement les mots les plus courants ne permettrait pas de surpasser la fiabilité d'uchardet, qui est déjà plutôt bonne. Je voulais surtout avoir un truc dont je suis sûr qu'il marche à tous les coups, et ça ne me dérange pas de perdre systématiquement 2 secondes avant de démarrer un film avec des sous-titres. Mais j'ai conscience que cette approche n'est pas utilisable au sein d'une librairie qui aurait autant d'utilisations différentes qu'uchardet.

Et pour donner un exemple d'un cas où uchardet peut être induit en erreur à cause de sa méthode statistique:

La suite d'octets e0 f0 f4 fb, est détectée par uchardet comme étant du WINDOWS-1255. Or ce n'est même pas une chaîne valide dans ce codec. Simplement, les trois premiers octets correspondent à des lettres fréquentes en hébreux. Je laisse au lecteur le plaisir de découvrir la chaîne de caractères qui se cache vraiment derrière ces octets…

Je me rends compte que j'aurais peut-être dû préciser pourquoi une connaissance de la fréquence des lettres ou d'un dictionnaire est nécessaire.

La plupart des encodages de caractères (à l'exception notable d'UTF8) sauront décoder n'importe quelle suite d'octets que vous lui donnez. Donc on ne peut pas se contenter de vérifier si le codec ne retourne pas d'erreur en décodant le texte, il faut aussi vérifier que ce qu'il retourne est cohérent avec une langue.

Par exemple, la chaîne d'octets f3 ec ed fb e9 peut-être décodée par les codecs WINDOWS-1251 (donnant умный), ISO-8859-1 (donnant óìíûé), KOI8-R (donnant СЛМШИ), et beaucoup d'autres. Seul умный a un sens dans une langue (cela signifie intelligent en russe). Mon programme va le détecter en détectant que c'est le seul qui existe dans un dictionnaire. uchardet va le détecter en se rendant compte que les lettres у, м, н, ы, й sont plus fréquentes en russe que n'importe lesquelles des lettres des autres résultats dans n'importe quel langage.

Le cat au début de la commande est inutile!

>,[<++++[->--------<]>[>,--------------------------------]<[>[-]++++[-<++++++++>]<.<]>[-]<++++[->++++++++<]>.[-],]

Le code source n'est pas disponible pour le moment mais c'est à l'étude.

Je ne vais pas donner d'argent pour le moment mais c'est à l'étude.

Je trouve le concept très intéressant, et l'année dernière, j'avais failli participer… Et finalement non.

Parce que travailler gratuitement c'est déjà pas génial, mais bon, dans le domaine du libre, on a l'habitude. Mais payer pour travailler, désolé, ça ne va pas être possible.

Travailler pour un musée, c'est intéressant, et on se sent utile. Mais c'est quand même du travail. Et être payé -50€ pour trois jours de travail, ce n'est pas cool du tout.

En fait, le programme python que tu présentes n’est pas équivalent au javascript dont la vitesse est mesurée dans jsperf.

Dans le jsperf, la base est totalement détruite, et reconstruite, entre chaque requête, mais seul le temps pris par la requête (SELECT ou INSERT) est mesuré.

Dans ton script python, tu mesures le temps pris par l’ensemble du programme (y compris le temps pris pour démarrer l’interpréteur et parser ton script), et toutes les requêtes sont faites à la suite sur la même base. C'est particulièrement dérangeant pour les INSERT, car chaque INSERT est fait sur une base un peu plus grosse. Idem pour le test JSPerf que tu as ajouté.

De manière générale, quel que soit le langage, il vaut mieux éviter d’inventer des méthodes de test de performance si on n’a pas des notions de statistiques. JSPerf fait les choses sérieusement.

Au final, les résultats devraient être encore plus en faveur du SQLite natif de python…

petit JSperf

Tout ce que j’ai pour le moment, c’est cette petite page de jsperf qui indique les performances en lecture et en écriture. Comme je n’ai pas tellement travaillé sur le sujet (à part faire attention aux flags de compilation, et écrire du code propre), je ne l’ai pas mentionné ici.

Pour les gens pressés, spoiler du jsperf ci-dessus: sur ma machine, 2500 SELECTs par seconde, et 500 INSERT par seconde.

Idées pour le futur

Mais l’étude des performances est très intéressante, et je vais certainement travailler dessus. J'avais par exemple envie de réécrire une partie du code de l’interface en C aussi, pour qu’il soit compilé en asm.js, et plus rapide. Dans le moteur js de firefox, les changements de contexte entre du code en asm.js et du code en javascript simple sont coûteux (ou du moins l’étaient la dernière fois que je me suis renseigné dessus). Donc il peut être intéressant d’écrire en C des routines qui vont, par exemple, préparer une requête, y attacher des paramètres, l'exécuter, et récupérer les résultats.

Du côté d’emscripten

En fait, j’ai un peu travaillé sur les performances, mais de manière plus générale, directement dans emscripten. Voire cette pull request, qui a maintenant été fusionnée, et qui contient de jolis graphes de performance.

Le patch consiste à optimiser les fonctions ccall (qui permet d’appeler une fonction C compilée depuis du code javascript) et la fonction cwrap (qui retourne une fonction qui elle-même appelle la fonction C compilée). Ces deux fonctions permettent notamment de convertir les chaînes de caractères javascript en tableau de char alloués sur la pile (la pile virtuelle d’emscripten).

J'ai eu un retour d'un utilisateur qui l'utilisait avec node dans un projet avec node-webkit, pour ne pas avoir à compiler son projet pour chaque plateforme.

Kripken, l’auteur original du projet, m’a finalement ajouté aux contributeurs de sql.js sur son dépôt github, entre le moment ou j’ai écrit cette dépêche et le moment où elle a été publiée. Donc kripken/sql.js contient maintenant le même code que lovasoa/sql.js.

C'est en mémoire, mais pas read only. Tu peux exporter ta base après coup.
C'est ACID, parce que SQLite respecte les propriétés acid. C'est thread safe, pour la simple raison que le seul moyen de faire des threads en js dans le navigateur, ce sont les web workers, et qu'ils ne permettent pas de partager la mémoire.

Si la base est déjà en SQLite côté serveur, et qu'elle ne contient pas de données sensibles, ça peut valoir le coup de l'envoyer direct vers le client.

Le système de types de sqlite est tout de même un peu plus fin que juste "démerdez-vous" : http://www.sqlite.org/datatype3.html

il n'y a pas besoin de tout le code de SQLite4 (converti donc en asm.js) pour avoir au final qu'un interpreteur SQL.

Quelle partie de SQLite serait inutile? Toute la partie concernant le stockage de données serait implémentée en js avec un binding vers localStorage. Le code compilé contiendrait toute la logique de la base de données relationnelle, et ça, c'est utile. Et pour les performances, je pense qu’on a de la marge.

J’ai envie de dire: C'est vous qui voyez!

Ça peut être utile pour des applications qui traitent des bases de données de quelques milliers d’enregistrements, et qui peuvent faire des requêtes diverses sur les données. Par exemple: afficher des graphes. Cela permet de soulager le serveur, et de gagner en performances (plus besoin d’une requête réseau par requête à la BDD).

Bien sûr, le fait que la base de données doive-t-être téléchargée entièrement côté client exige qu’elle ne contienne pas de données sensibles. Le fait qu’elle soit stockée intégralement en mémoire exige qu’elle ne soit pas trop grosse.

J’ai eu quelques retours d’utilisateurs, apparemment la plupart cherchent à faire des systèmes de visualisation de données: leurs données sont déjà dans des bases SQLite, et ils veulent utiliser des bibliothèques javascript comme d3 pour les visualiser.

En fait, la base de données est stockée intégralement en mémoire. L'avantage, c'est que c'est rapide (du moins, pas trop lent).

L'inconvénient, c'est qu'on se limite à de petites bases de données.

C'est aussi pour ça que j'attends beaucoup de sqlite4. Il permettra de faire assez simplement le lien entre SQLite et les mécanismes qui permettent de stocker des données sur le disque en JavaScript, comme localStorage.

J'y ai pensé au moment de l'écrire, mais comme je raconte un peu ma vie, j'ai finalement décidé de proposer un journal.

Mais comme tu le proposes, je vais poster ce contenu en tant que dépêche aussi…

Je ne pense pas que le fait de ne pas avoir de titre d'ingénieur soit un obstacle.

Est-ce que vous pouvez me donner une adresse mail sur laquelle je pourrais vous contacter, ou m’écrire sur ophir point lojkine arobase eleves point ec-nantes.fr ? Nous pourrons alors nous mettre d’accord sur un rendez-vous.

Oui, je crois que c’est ça!
Toutes nos matières ont des noms imprononçables, alors parfois en ne sait même plus ce que ça veut dire…

Exactement. Je me disais que c'était l'occasion de découvrir un peu le monde réel en dehors des murs de l'école.
Mais je ne pense pas que je serais moins bien noté…

Et surtout les problèmes de connexion si ça capte pas ou mal. En revanche, l'idée de le faire en web avec serveur sur la tablette nous a traversé l'esprit. Restait à savoir quoi mettre derrière le HTML.

En fait, on peut aussi tout faire en HTML avec du code seulement en Javascript, et pas de serveur derrière (enfin, juste un serveur tout bête qui va servir les fichiers html, css et js). Et pour le problème de l'accès à internet intermittent, HTML5 permet la création d'applications persistantes, qui sont mises en cache à la première connexion, et ne nécessitent pas d'accès à internet pour être utilisées ensuite: http://diveintohtml5.info/offline.html .

Quand on ouvre le .deb sous ubuntu, il ouvre le software center, qui affiche "Paquet de mauvaise qualité", et qui dit quelque-chose comme "bad package name"…