Laurent J a écrit 2938 commentaires

Je connais en effet une boite qui fait de la cartographie à base de SVG. : 3liz.com.

Et ils utilisent Gecko comme plateforme pour leurs applis et pour afficher leurs cartes SVG. Et même si le support SVG n'est pas extraordinaire d'un point de vue performance, ça reste largement utilisable.

Aussi, ceux qui râlent contre firefox + SVG, faudrait d'abord analyser ce qui plombe les perfs dans la page en question. Je n'ai pas regardé, mais si ça se trouve les scripts de cette page sont codés avec les pieds, tant au niveau Javascript, qu'au niveau SVG. En effet, SVG est plutôt riche, et comme dans tout langage, il y a des bonnes et des mauvaises façons pour créer les dessins.

Le temps ?

laisse tomber, on est vendredi...

>Les développeurs d'openoffice sont des bénévoles? Les principaux contributeurs du noyau sont des bénévoles?

Non, c'est pour ça que le logiciel n'est pas gratuit.

M'enfin, Daniel aurait du préciser le contexte : celui de Mozilla. On s'est posé toutes ces questions suite à certaines annonces de Mozilla. Et elles prennent toutes leur sens dans le contexte actuel de la politique de Mozilla.

M'enfin je vais pas développer, pas le temps.

Chez dedibox, tu as 5go de backup gratos..

Et dans thunderbird tu as la possibilité de stocker en local les messages d'une boite imap, pour consultation offline.

Bref, je pense que tu devrais soit changer de client mail, soit regarder plus attentivement la configuration de celui que tu utilises :-p

1) pour le diff, je trouve qu'il est pas tip top : on a pas la différence au niveau caractère, or c'est une fonctionnalité très utile, on voit tout de suite ce qui a été réellement modifié. Donc si tu veux un diff qui soit mieux, tu peux utiliser la classe diff qu'il y a dans jelix (que tu trouveras dans lib/diff/ dans une des archives de jelix, http://jelix.org ), elle provient de phpwiki, mais j'ai fait quelques corrections pour que ça passe dans PHP5 sans problème.

2) Pour le parsing de wiki, tu peux utiliser wikirenderer (http://wikirenderer.berlios.de ) : c'est un parser de syntaxe wiki dont tu peux totalement paramétrer la syntaxe et le comportement sur chaque tag wiki. L'avantage de wikirenderer, c'est que ça produit du code XHTML valide à coup sûr, que c'est hautement configurable (tu peux générer autre chose que du xhtml), et que pour toi, tu n'as pas à réinventer la roue (vu que je vois que ton parser wiki ne supporte pas encore tout).

Bon c'est sûr que tout ça, ça va légèrement augmenter le poids de ton script, mais il n'en sera pas moins simple à utiliser ;-)

Tout à fait

en plus certains hebergeurs proposent non seulement un espace pour le backup, mais aussi un serveur de mail secondaire (qui stocke les mails qui arrivent, au cas où ton serveur de mail crash). (dedibox par exemple).

Linux Weather Forecast indique les évolutions dans un futur proche. Mais qu'en est-il d'une éventuelle version 2.8, voir 3.0 ? Y a t-il de grands changements prévus à l'horizon justifiant la sortie de ces versions majeures ? Ou dans trois ans, en sera-t-on encore sur une 2.6.x, genre 2.6.82 :-) ? (ce n'est pas une critique hein...)

Le départ des 2 dev principaux n'est un drame. Nul n'est irremplacable.

Oui un pisseur de code lambda dans une SSII est remplaçable. Mais ici il ne s'agit pas de deux pisseurs de code, il s'agit de deux types qui connaissent à fond le produit, qui ont dirigé le projet avec leur vision, qui ont permis à thunderbird de devenir ce qu'il est devenu.

Donc non, désolé, ils sont irremplaçables. La preuve : il n'y a personne pour les succéder. Et celui qui va les succéder (un jour...), il va mettre pas mal de temps à "s'approprier" le projet, à en connaitre les moindres recoins. En attendant, l'avancement du projet va beaucoup en souffrir à mon avis. Et dans un cas comme ça, en général un projet prend du retard vis à vis de la concurrence, de l'innovation etc...

Cette affirmation "nul n'est irremplaçable", n'est franchement pas valable sur des projets "pointus".

ah ah bien tenté !

Ayant déjà bossé en environnement Mainframe, et ayant vu ce que pouvait donner du code COBOL sur des applications énormes de plusieurs millions de lignes (applications de l'ex boite d'assurance UAP), c'est à dire avec du code spaghetti de partout à force d'évolutions dans tout les sens et des habitudes des "vieux" codeurs sur les premiers COBOL (hein ? les procédures ? c'est quoi ? vive les GOTO !), je m'interroge beaucoup sur votre transcodeur. Le code COBOL du projet NACA est si propre que ça ? bien structuré et tout ? pour arriver à faire du transcodage parfait ?? Pas un seul GOTO nulle part ? (il me semble qu'on ne peut pas faire des goto en Java)

J'imagine que ça n'a pas du être une mince à faire que de faire ce traducteur de code...

Vivement le prochain n'épisode :-)

> J'ai personnellement beaucoup de facilités avec des langages type SQL, et beaucoup de difficultés avec la manipulation d'arbre de donnés avec des boucles. J'adore jouer avec le premier et déteste me farcir le second exercice.

As-tu déjà jeté un coup d'oeil à la gestion d'arbres par représentation intervallaire ?
http://sql.developpez.com/arborescence/

En clair : plus besoin de faire des boucles dans tous les sens pour récupérer une arborescence. Une seule requête suffit. Seul bémol : la modification de l'arbre (insertion, suppression de noeud) est un poil plus compliqué qu'un simple insert ou delete, mais je trouve que c'est plus supportable que de récupérer une arborescence.

Il me semble aussi qu'il existe une extension pour postgresql qui permet de gérer des arborescences.

> Tu veux dire que les classes sont reconstruites automatiquement dès qu'on modifie le schéma ?

oui

> Même si c'est désactivable, je trouve ça génant dès qu'on travaille à plusieurs.

Je ne vois pas en quoi c'est génant. jDao et en particulier CopixDao (vu la jeunesse de Jelix :-) ), a été utilisé sur de nombreux projets de plusieurs développeurs depuis des années, ça n'a jamais posé de souci.

>Ton dernier argument sur la taille n'est pas un critère pour moi.

Et pourtant, c'est un argument important. Vu que PHP reparse les sources à chaque requête HTTP, ça fait une grosse différente au niveau tenue du serveur en charge. Si tu utilises un cache d'opcode (APC), la différence sera moindre, mais il y en aura quand même une : la quantité de mémoire nécessaire pour stocker l'opcode (plus le programme est gros, plus il prend de la mémoire dans sa version compilé, logique..). Et même si l'utilisation du framework est déstiné à un site à faible trafic, cela peut aussi faire une différence en hébergement mutualisé.

>74 fichiers/681ko pour propel

pardon, cela ne concerne que le générateur de Propel. Il faut donc y ajouter les 37 fichiers/246ko du runtime :-) (parmis les 6 fichiers de jDao, il y a le runtime et le générateur)

Ok, je viens de revoir Propel, je l'ai en effet confondu avec des trucs comme Doctrine. Le principe général de jDao est effectivement similaire à Propel. Bien que jDao soit plus vieux que Propel (c'est une évolution de CopixDao, utilisé dans le projet Copix qui fut l'un des premiers framework PHP), il est un peu moins "puissant" sur certaines choses, comme la gestion des relations n-n. Mais il propose d'autres particularités en contre-partie. Par exemple dans jDao (et si je ne me trompe pas dans ce que j'ai vu dans propel):

* On peut déclarer dans le fichier XML des méthodes et indiquer les critères de ce qu'elles devront récupérer, effacer ou mettre à jour. Cela évite de devoir générer la requête à coup d'objet Criteria comme dans Propel : les requêtes sont donc en dur dans la classe générée.
* jDao suit le design pattern DAO
* Un objet DAO peut être mappé sur plus d'une table
* Pas de génération explicite des classes : dés qu'on modifie le fichier XML, les classes sont regénérées (on peut désactivé cette vérification de mise à jour en prod).
* Un fichier XML par objet mappé, et non pas tout dans un seul fichier. Chaque module contient donc ses propres fichiers XML jDao. Cela facilite l'installation de modules tiers. (peut être qu'il est possible d'avoir plusieurs fichiers avec Propel, mais j'ai pas vu)

Enfin jDao est plus léger que Propel (6 fichiers/81ko, contre 74 fichiers/681ko pour propel), même si il est vrai qu'il a un peu moins de fonctionnalités. Mais ce qu'il permet de faire couvre déjà pas mal des besoins AMHA. Et des améliorations sont prévues dans les versions à venir.

>et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.

pardon, il faut lire "certains traitements de Jelix"

Je ne connais pas très bien symfony, donc difficile de te donner une comparaison complète. De ce que je connais de symfony, il semble que cela soit un framework plus lourd que Jelix (en terme de ligne de code et temps d'execution). M'enfin faudrait faire des benchs sérieux pour voir.

Cependant, il y a quelques points que j'ai regardé, et sur lequel je pense que Jelix est supérieur. Par exemple, propel ou doctrine c'est bien, mais ce sont des trucs énormes, voir bloatware. En effet, les trucs à la activeRecord "redécouvrent" à chaque requête http le schema d'une table ou d'une base de donnée et inclus donc tout un mécanisme pour générer entièrement les requêtes SQL dynamiquement, à chaque fois qu'il faut faire une requête SQL. (bien que les implémentations tentent de mettre des systèmes de cache un peu partout dans leur code, mais c'est à mon sens plus des bouts de scotch qu'autre chose).

Ça a un intérêt en développement, c'est même sexy à utiliser, mais c'est, pour moi, un truc complètement contre productif dans un environnement en production, une fois que le site est en ligne, dans la mesure où à partir de ce moment là, les schemas des tables ne bougent plus. Partant du constat que la façon la plus performante de faire des requêtes est de les écrire en dur dans le code (ou quasi en dur, puisque généralement on a des paramètres), jDao a été crée en ce sens, tout en évitant au développeur d'écrire des trucs rébarbatifs, voir même du code non sécurisé (puisque jDao génère du code qui est tient compte des problèmatique de SQL injection). À partir d'un fichier qui décrit le mapping (fichier qui peut être généré par une ligne de commande), jDao, à la première execution, génère une classe une bonne fois pour toute, avec des requêtes en dur dans le code de cette classe, comme si tu avais fait toi même la classe métier et écris toi même les requêtes. jDao est ainsi plus léger et permet au framework de ne pas avoir à "redécouvrir" à chaque execution de page la structure d'un enregistrement ou autre. À noter cependant que jDao n'est peut être pas encore aussi puissant que doctrine ou propel, mais je pense de toute façon que son principe de fonctionnement est plus interressant au niveau des performances.

Et j'ai essayé d'avoir la même philosophie dans les autres composants de Jelix : tout est fait dans jelix pour que l'application soit performante, et pour éviter autant que possible, d'une part d'avoir des traitements qui sont inutiles dans un context de production comme je viens de l'expliquer, et d'autre part d'avoir du code mort (des trucs jamais utilisé par l'applis mais toujours chargé), y compris du code qui serait propre à une version de PHP (donc qui serait "mort" pour d'autres versions de PHP): tu peux te construire un framework jelix optimisé pour ta version de PHP, tu as même une édition "GOLD" qui inclus une extension PHP à installer sur le serveur, et qui prend en charge certains traitements de PHP, accélérant donc le fonctionnement.

Et je rajouterai que ce n'est pas par hasard si Jelix a été choisi par les développeurs de la plateforme over-blog, sur laquelle plus de 5 millions de pages sont lues par jour (et même plus, ce chiffre est vieux), et hébergeant plus de 630 000 blogs.

Bon après, en dehors des considérations sur la performance, un framework se juge sur les possibilités qu'il offre par rapport à ses propres besoins dans ses projets (il y a aussi une part de "feeling", vis à vis de la manière dont on créer une application avec tel ou tel framework). Et ça, il n'y a que toi qui puisse faire la part des choses, et donc, plutôt que de lire mon argumentation qui pourrait de toute manière toujours être prise comme totalement partiale et subjective :-), le mieux est que tu ailles voir un peu les quelques tutoriaux pour te faire une idée du truc.

Le problème est que j'ai choisi de mettre la doc dans un wiki, pour que des contributeurs puissent aider facilement à la rédaction. Mais j'ai pas trouvé de wiki qui me convienne, et qui permette de générer un PDF à partir de tout une arborescence de pages.

Mais je note ta requête :-)

Effectivement, je trouve que les fichiers donnés par AMD manquent cruellement d'explications et de commentaires. Deux simples listes de registres, c'est maigre.

M'enfin c'est toujours ça, et probablement que ceux qui ont déjà fait les drivers libres pour ces cartes, ça leur est moins cryptiques qu'à nous. Et que ça va leur permettre au moins de corriger et de compléter un minimum leur code source.

>Son "travail remarquable" est fait en restant conformablement assis dans sa chaise

Ce qui est faux. Et encore moins vrai pour les ouvrages qui ont suivi. En même temps, il ne faut pas oublier que c'est l'un des premiers à avoir réfuter la thèse officielle, quelques mois seulement après l'évènement. Et il faut se rappeler qu'à l'époque, aller enquêter sur ce genre de chose n'étaient pas chose aisé. Ensuite, il ne faut pas oublier non plus le climat émotionnel de l'époque : peu de gens étaient prêt à entendre une autre vérité que celle officielle. Aussi peu de journaliste se sont avancés (à l'époque) à essayer de démêler le vrai du faux, de remettre en cause la thèse officielle (publiquement au moins). C'est moins vrai maintenant. Le problème de Messan c'est d'avoir essayé d'alerter l'opinion publique sur un truc "trop frais". Et tout le monde s'est foutu de sa gueule. Et ce qu'on remarque aujourd'hui, c'est que les avis sont bien plus partagé, que des nouvelles zones d'ombres sur cette affaire sont apparues, et que finalement, globalement, il n'avait pas forcément tord.

De plus hoaxbuster réfute (il y a très longtemps tu noteras) les arguments de Messan avec des arguments qui ont été eux aussi largement contre attaqué par d'autres. Y a qu'à voir, depuis, tous les avis divergents de plusieurs scientifiques sur le soit-disant crash d'un boeing sur le pentagone. Qui croire ? C'est plutôt difficile, et finalement, penser que Messan raconte n'importe quoi ou penser que Messan détient la stricte vérité, ce n'est que pure bêtise.

Tu aurais du lire le livre, ça t'aurais éviter d'écrire cette bêtise. Il y a certes pas mal de liens dans le livre, mais il fait aussi ses analyses à partir d'interviews, etc... Après l'adhésion à ses théories est un autre problème. Mais ça en change rien au fait que tu dis n'importe quoi.

Bah il va pas beaucoup en profiter. Dieu l'a foutu dans un logement à l'écart des autres, (juste à coté de celui de la Callas).

http://tourtesmagazine.com/dieu/?p=25

>Simplement hormis FF dédié au Web la cible de javascript me parait limitée

j'ai pris FF et javascript pour un exemple concret d'application qui peut être scriptable. Maintenant embarquer javascript ailleurs, ça te parait peut être limité, mais je ne suis pas de ton avis.

J'ai l'impression que tu confond langage et API. Au niveau langage, javascript est plutôt complet (après on aime ou on aime pas l'objet basé prototype), surtout dans ses dernières versions qui ont des trucs syntaxiques à la python ;-).

Au niveau de l'API, c'est aussi illimité, dans la mesure où, comme avec tout moteur de script embarquables (Python ou autre), tu peux déclarer auprès du moteur, des objets du langage qui seront mappés sur l'API C/c++ interne de ton application, et donc ces objets te paraitront natif du point de vu de ton script. En plus, tu as la liberté de "montrer" ce que tu veux de ton API, donc cela sécurise l'exécution des scripts.

D'ailleurs, il faut faire ce mapping quand on embarque un moteur de script, pour que les scripts puissent interagir avec le logiciel, sinon embarquer un moteur de script n'aurait plus d'intérêt. C'est fait par exemple dans Firefox pour le DOM, l'objet window, xmlhttprequest etc..

(et dans FF, il y a aussi XPCOM/XPConnect pour tout le reste de l'API : cela permet d'étendre l'API javascript très facilement sans toucher à spidermonkey et ce qui l'entoure).

>D'ailleurs il etait question à un moment de pouvoir utiliser python pour étendre FF. C'est tombé aux oubliettes ?

Tu peux faire des XPCOM en python, c'est toujours ça, mais il faut se compiler une version avec le flag qui va bien. Le support n'est pas inclus d'office. (L'IDE Komodo par exemple a toute son API dans des XPCom en Python).

Pour ce qui est de l'utilisation directe de Python dans les pages XUL/HTML, il y avait un travail en cours, mais je crois que ce n'est pas terminé (pas sûr que ce soit très actif en ce moment d'ailleurs). Il me semble que c'est prévu toutefois dans Mozilla 2.

>Tu voulais plaisanter là.

Non. Mais tu ne sembles pas avoir lu ce que j'ai dis. Je parlais des développeurs web.

>Un plugin FF necessite de connaitre le XUL, le js , les CSS et de lier tout ça tant bien que mal sans savoir où on en est.

Ça tombe bien, un développeur web connait le js, le CSS et doit apprendre le XUL qui n'est franchement pas difficile ( pour un bouton, pour un item de menu, oua la vache, c'est compliqué !). Le seul truc sioux, c'est apprendre les API interne, mais heureusement, il y a de la doc.

Maintenant va demander à un développeur web (qui n'a pas forcément voire rarement fait du C++), de faire une extension C++ pour IE par exemple...

>PyQt te permet de créer des applis complètes sans pb sans recourir au c++ par ex.

ouai ouai, c'est beau python. Pas sûr que les applis C++ qui embarquent python intègre PyQT (surtout si elle est pas faite en QT). Relis le sujet du journal, on parle de langage de script "embarqué".

> Pour XHTML, le W3C a virer toute les conneries des versions d'html précédentes (et il y en avait des tonnes).

HUM ! Remplace XHTML par HTML 4.01/strict dans ta phrase, et tu diras la vérité. XHTML 1.0 n'est qu'une simple "XMLisation" de HTML 4.01. (pas de nouvelles balises, ni de nouveaux attributs) et XHTML 1.1 n'apporte que peu de nouveautés.

Par contre l'ex-futur XHTML 2 faisait une remise à plat de la grammaire XML, mais il semblerait que ce soit mort avant même que ce soit terminé : y a des trucs pas cohérent et ça n'intéresse strictement personne, et encore moins les personnes les plus concernées par ce genre de chose : les éditeurs de navigateurs. (aucun ne participe au groupe de travail, sauf MS, et encore, seulement sur le papier, c'est dire...)