Laurent J a écrit 2952 commentaires

Le fait que ce soit du raster ou des fichiers complexes n'est en aucun cas une raison de ne pas faire des sauvegardes automatiques, même à intervalle court.

Il suffirait juste d'enregistrer la pile d'undo (dans un fichier à part, "special anti crash"), et donc juste le type des actions avec leurs paramètres. À chaque fois, ça ne serait que quelques dizaines d'octets à sauvegarder dans ce fichier anti-crash (et bien sûr, on n'enregistre que les actions qui n'avaient pas été sauvée)..

Et ainsi à la restauration -> rejouer la pile d'undo sauvegardée.

Et si on veut éviter de se retrouver en sauvegarde avec une pile d'undo énorme, on pourrait sauvegarder le vrai xcf toutes les 10 minutes (ou selon le user), et ça, ça pourrait se faire aussi dans un thread, pour éviter de trop géner le user.

Bref, il y a des solutions qui pourraient être implémentées.

sur le blog d'apache

https://blogs.apache.org/infra/entry/apache_org_downtime_ini(...)

j'ai juste repondu avec le même "tact" que ta question :-p

Une bonne grosse boutade quoi (en plus pas originale, je l'avoue...).


>Donc si je te suis bien, je vais patcher chaque outil que j'utilise qui doit répondre a des besoins que je ne suis pas le seul a avoir

chaque outils, non, bien évidement (ai-je dis ça ?). Mais si une fonctionnalité manquante est est très importante pour toi, pourquoi pas ? Ou même encore, pourquoi pas payer un dev pour le faire ? (ta boite ou toi, si il y a les sous, mais pas le temps ou pas les compétences).

C'est comme ça que fonctionne la grande majorité des projets Open Source.

>Mac OS X qui propose déjà un profiler de code performant

bah à priori, ce profiler n'a pas l'air de convenir à la majorité des dev Mozilla qui bossent sous Mac. Donc ils ont payé un gars pour le faire.

Tu n'as plus qu'à espérer que des dev Mozilla passent sous un BSD en masse pour voir le portage arriver :-)

Mais, euh... je te conseille de trouver une autre solution que d'attendre après Mozilla ;-)

quand tu auras filé ton patch.

"une bonne partie des animations SVG/SMIL"

Tout n'est pas totalement fini c'est tout. Dans ce genre de truc, vaut mieux avoir un truc fini qu'un truc à moitié fini... En fait le coeur est là, mais y a pas tout exposé encore si j'ai bien compris.

Le fait d'utiliser un processus par tab peut jouer au niveau rapidité. Mais il n'y a pas que ça. L'interface de Firefox, c'est du XML + JS. ça demande donc un peu plus de temps à réagir que du pur natif.

Pour le chargement du navigateur, il y a des trucs un peu lourd dans Firefox, et ils sont en train d'améliorer tout les points noirs.

bah si y a beaucoup d'IPC à faire : mise à jour de l'historique, paramètrage du navigateur, communication avec le download manager, le security manager etc etc. Un tout petit exemple : dés que tu ouvre une url, faut que le navigateur aille informer tout les autres tabs, pour que les styles des liens en :visited soient mis à jour. Et des trucs comme ça, il y en a beaucoup.

Bref Il y a beaucoup de communication inter processus. Pour te faire une idée, voir le dev qu'il y a actuellement dans Firefox pour faire un processus par tab: https://wiki.mozilla.org/Content_Processes

Ils réutilisent d'ailleurs la couche IPC de chromium ;-)

Les points manquants de Firefox sur le test acid3 concernent majoritairement le support des animations SVG/SMIL. C'est pas la fin du monde :)

La prochaine version de Firefox fera mieux évidement, car une bonne partie des animations SVG/SMIL sont implémentées, mais pas activé par défaut pour le moment dans le futur Firefox 3.6 qui sortira dans 3 mois. (oui oui, dans 3 mois, en novembre 2009).

La nightly de FF3.6 avec la préférence svg.smil.enable à true : 97/100. sans la pref: 95/100.

un fabricant qui a une capitalisation boursière plus grosse que Google, c'est pas un grand fabricant ?

http://www.generation-nt.com/capitalisation-boursiere-apple-(...)


J'aimerai bien alors diriger une petite boite comme Apple...

> Il s'applique à tous les fichiers dont le format comprend des marqueurs (métacodes), donc XML mais aussi HTML et bien d'autres formats.


ben non justement, si j'ai bien compris le procédé. Le brevet explique une technique où le contenu est séparé de la structure. Tu le dis toi même : content et map sont séparés. Or en XML/HTML, le contenu est à l'intérieur même de ce qui décrit la structure (les balises formant la structure).

Et cela semble être confirmé par ce que je viens de lire un peu partout : ce n'est pas l'utilisation du format XML qui est remis en cause, mais la manière dont sont stockées certaines données dans le format XML de Microsoft (avec j'imagine, un truc du genre des données brutes dans une balise, et une map dans une autre).

Ce brevet n'en reste pas moins totalement ridicule.

note : je bosse une boite qui fait de la techno sur le zoom de document et d'images.

les niveaux de zooms sont prédéfinies ok, les tuiles sont bien entendu précalculés. Mais quand tu veux faire du zoom linéaire et non incrémentale, (donc, il faut étirer/rapetisser les tuiles au finale, quand le zoom est entre deux niveau de zoom), comme c'est le cas pour notre outils, bah tu as forcément à un moment ou à un autre des tuiles disjointes à l'affichage, à cause des arrondis. Il faut donc toujours qu'une tuile puisse déborder sur une autre, ne serait-ce que d'un pixel ou deux.

Quand tu as un affichage de zoom à des niveaux prédéfinis (on ne peux pas zoomer entre deux niveaux de zoom), oui, tu n'a pas besoin que les tuiles se chevauchent, puisque tu affiches alors les tuiles telles quel (même si tu fais une jolie transition quand tu passes d'un niveau de zoom à un autre, en étirant/rapetissant les tuiles temporairement. si il n'y a pas de jointure parfaite durant la transition, c'est pas grave, ça ne se verra pas.

Ben si, c'est du flash. les boutons sont en HTML, mais le player en lui même est bien en flash.. (ils pourraient utiliser la balise quand même...)

Et sinon, franchement, je ne suis pas fier que ce soit français. Vu la gueule du HTML (via firebug), à la place des développeurs, je me cacherai. Parce que par exemple, imbriquer neuf DIV pour enfin afficher le contenu principal de la page, avec en plus du style inline et des classes (les mêmes en plus) dans tout les sens, ça craint du boudin... Je plains ceux qui doivent le maintenir (quoique, si c'est ceux qui l'ont développé...)

Bref, leurs pages pourraient être bien plus light et compréhensibles... Deezer, au moins, le code est un peu mieux organisé.


(désolé, c'est mon coté critique dev web qui ressort)

LOL.


(ouai, je sais, avec ce LOL, je me grille encore plus, mais que voulez vous...)

non, pas comme des pavés. Parce que des pavés, ça se chevauche pas. Des tuiles, ça se chevauche. Et justement, dans le domaine du zoom, en général, on fait légèrement chevauché les images, pour compenser les arrondis dans les calculs de zoom/taille. bon, peut être pas sur google map ou mappy, vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails). Mais quand on a un système de zoom sans "échelons", on est obligé de les faire chevaucher sinon on peut avoir des images disjointes à certains niveau de zoom, et ça c'est moche :-).

Bref, des tuiles quoi..

Il n'y a plus de flash.

Mais il n'y a absolument pas une once de balise SVG. Ou alors va falloir me dire où tu en as vu.

En explorant l'arbre DOM avec Firebug, je n'ai vu que des images. La carte est découpée en plusieurs images (qu'on appelle des tuiles dans le jargon du domaine du zoom). Bref, une technique similaire à Google, open street map et cie. Que du JS (avec jQuery), et des balises html img. Pas de SVG.

>Et vous qu'en pensez-vous?

rien.

Sous linux chez moi, ça fonctionne très bien.... (que ce soit des binaires vanilla ou compilé maison)

bah, avec Firefox 3.5 et des videos Theora, j'arrive à aller directement où je veux sans tout télécharger...

Tu as essayé avant de poser la question ?

de toute façon, il n'y a pas besoin de patcher soit même chez Mozilla. à partir du moment où le patch est inclus dans le dépôt mercurial, tu as des builds à ta disposition qui comportent la correction (que ce soit des builds des branches stables ou du trunk).

utiliser des triggers, c'est pas moins performant que de faire soit même les requêtes à partir du programme. Il faut bien évidement faire attention aux cascades que cela peut entrainer.

Mais utiliser un trigger pour mettre à jour une table après la modification d'une autre table, je ne vois pas en quoi c'est moins performant que de faire les deux requetes à la suite en php par exemple.


bon sinon, comme ton commentaire précédent, je n'ai pas tout compris, il manque des mots dans ta phrase. "et niveau maintenant " : tu voulais dire quoi ?

non, parce que ça veut dire que pour inserer les elements il faille explicitement appeler cette procédure stockée. Et ça veut donc dire que si, pour une raison ou une autre, à un moment il soit fait directement un insert dans la table, la procédure n'est pas appelée. Du coup, cohérence des données cassée.

L'intérêt des triggers c'est que ça permet une implémentation beaucoup plus transparente de tes règles de gestion. Un développeur n'a pas à connaitre des dizaines de procédures stockées, et savoir quand il doit appeler une procédure ou quand il peut faire une requête directe sur la table. Avec un triigger, il fait son insert sans se soucier de rien du tout, et tout se fait automatiquement.

Et on peut mettre aussi les applications au même plan que le développeur. Imagine plusieurs applications qui attaquent la même base (ça arrive très souvent dans les moyennes et grosses boites). Imaginons donc que l'on ait, en reprenant mon exemple, à ajouter un champs qui est calculé à l'insertion ou modification d'un enregistrement. Si je fais ça dans une procédure stockée, je vais devoir modifier aussi toutes les applis pour qu'elles appellent la procédure stockée plutôt que de faire leur insert. Avec un trigger, pas besoin, ça sera transparent pour elles.

Note qu'un trigger peut appeler une procédure stockée. Et qu'une procédure stockée reste toutefois utile pour les problèmes plus complexe que de simple opération à exécuter sur des changements sur une table ou autre.

On peut aussi optimiser en rassemblant les requêtes. Si par exemple on doit faire 3 insert à la suite sur la même table, rassembler tout ça en un seul insert.

On peut aussi faire de la duplication d'informations (mais pas trop :-)). Par exemple, on affiche une liste de discussions, et on veut afficher pour chacune d'elles le nombre de reponses. Plutôt que de faire un count pour chaque discussion et/ou des group by , on pourrait mettre un champs qui contient le nombre de réponse, ça évite d'avoir à le "calculer" à chaque fois, ça évite les jointures. Certes, ça fait pas très propre pour un puriste, mais d'un point de vue pragmatique, ça permet d'améliorer les perfs.

Et puis en mysql 5, on peut aussi utiliser les triggers. Alors si on doit effectuer des modifications sur d'autres tables quand on en modifie une, utiliser les triggers. ça évite de faire X requetes "à la main", et sera bien plus optimisé au niveau execution (et puis le code client sera plus propre). les triggers ça permet aussi de garder une cohérence dans le schema sans avoir toutes les rêgles de gestion en tête. Par exemple, lors de l'insertion d'une réponse dans la base, le trigger ira faire un update du champs "nombre de reponse" sur la discussion ;-).

Bref, essayer d'optimiser au mieux le sql.

Ouai, je viens de regarder ça aussi. C'est en fait juste un moteur de template dédié à ODT, avec deux trois fonctions pour faciliter l'injection de texte et d'image, et qui sait ouvrir/enregistrer un zip...

Dommage, ils auraient pu developper des plugins pour un moteur de template existant (au hasard, jtpl ou smarty), cela leur aurait fait un peu moins de boulot, tout en profitant des fonctionnalités de ces moteurs (parce que bon, leur langage de templating est plutôt super limité, pas de gestion de cache etc...).

non ce n'est pas du vandalisme, il y aurait effectivement une annulation à cause d'un problème logistique. Je n'en sais pas plus pour le moment

oui, les contributeurs. Sonny contribue à sa manière : il est l'un des organisateurs de cette soirée :-)