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 ;-)
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".
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...
> 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.
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é.
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.
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.
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.
>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.
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...)
Les langages de scripts sont souvent bien plus connu que les langages compilés. Prenons l'exemple de Javascript. Le moindre petit développeur web connait javascript (pas forcément bien mais bon...). Et bien le moindre petit développeur web peut par exemple se faire une petite extension XUL pour Firefox en 2-3 coups de cuillère à pot. Bon j'exagère un poil, mais c'est en tout cas extrêmement plus simple que si il fallait faire l'extension à coup de fonction C/classe C++ (avec tout ce que ça apporte comme lourdeur au dev : installation de X outils de dev, compilation etc.) On en a une preuve flagrante quand on compare IE et Firefox : regardez celui qui a le plus d'extensions disponibles. C'est celui qui peut être étendu avec un simple script.
Et puis je plussois ce que dit pasBillpasGates : un langage de script permet de limiter les dégâts en terme de gestion de mémoire, de limiter l'accés à certaines API internes pour pas faire n'importe quoi, puisque c'est l'interpréteur qui gère ces problémes. Mais ça ne les éradique pas forcément, comme on peut le voir avec certaines extensions Firefox codées avec les pieds, et qui contiennent des leaks dans tous les sens.
>Ce qui prouve qu'il y a eu erreur de la part de Disruptive Innovations de refuser tout développement de la version 1
Ça prouve rien du tout. Et surtout il n'y a eu aucune erreur. Ce sont des circonstances qui ont fait que la poursuite du développement de la version 1 est tombé à l'eau pour nous.
>ce KompoZer mériterait d'avoir le nom nvu-1.7.10
Peut-être, mais NVU est une marque de Linspire, et il n'est pas possible de la réutiliser pour des versions ultérieures de NVU 1.0 sans le consentement de Linspire... (oui je sais c'est dommage mais c'est comme ça et c'est valable même pour nous à DI ).
>vu que toutes les resources de Disruptive Innovations sont maintenant affectées au développement de FullerScreen :(
Je ne sais pas où tu as lu ça, mais sache que c'est totalement faux. J'ai pas l'impression de travailler sur FullerScreen, ou alors serait-ce à l'insu de mon plein grés ? :-). FullerScreen n'est qu'un "petite" extension que Glazou réalise entre deux projets.
En ce qui concerne le développement de Mozilla "nvu2" Composer, c'est vrai que c'est un peu en suspend, mais bon, todo list énorme, clients, autres projets prioritaires, tout ça... (d'ailleurs, au passage, si une entreprise veut bien "sponsoriser" le dev de Composer...).
> Si Firefox est lourd, est-ce à cause de son interface en XUL ?
c'est une cause oui. Mais bon, sur ce genre de machine, il me semble que le opera installé n'est pas la version desktop, mais une version "embarqué", avec une interface spécifique, adaptée pour les petits écrans. Donc au même titre qu'opéra, tu n'utiliseras pas Firefox sur ce genre de machine, mais son accolyte minimo ou maemo (qui n'ont à priori pas d'interfaces en XUL)
>Est-ce que Gecko tout seul est suffisamment léger pour espérer tourner sur une machine lente avec peu de RAM, si on lui fournit une GUI appropriée ?
réponse oui : minimo fonctionne depuis quelques années déjà sur des appareils bien moins puissant que le nokia. (mais le développement de minimo est un peu en suspend depuis quelques mois il me semble).
Mais il est probable tout de même que gecko soit plus lourd que le moteur d'opera.
Je suis pas expert dans lesdits protocoles, mais voila ce qu'il faut faire pour envoyer un message en xmpp à quelqu'un :
<?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
</stream:stream>
Voici le même message envoyé avec IRC :
:expediteur@exemple.com PRIVMSG destinataire@exemple.net :Hello are you receiving this message ?
Quand on calcule le nombre de caractère (je ne compte pas les caractères blanc entre les balises pour xmpp), on a un paquet de 298 caractères pour XMPP contre 97 pour IRC. Soit un facteur 3.
Si on ne compte pas les parties variables (nom des destinataire/expediteur et le message en lui même), on a 214 caractères contre 13, soit un facteur 16 !
Bref, xmpp est beaucoup plus gourmand en bande passante que IRC et demande un peu plus de ressource au niveau du client puisque parser du XML est quand même beaucoup plus compliqué que de parser une commande IRC (m'enfin je chippotte, pour une machine moderne, la différence ne se voit pas, sauf peut être si on est connécté à 20 channels de 150 users en même temps avec des discussions trollesques à gogo).
Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement.
Note: c'est amusant^W delirant aussi de voir l'énorme différence entre un ping en XMPP et un ping IRC (envoyé entre client et serveur pour savoir par l'un si l'autre est alive et vice versa).
# quelques propositions d'améliorations
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche WiKiss 0.3rc2 : appel à testeurs. Évalué à 3.
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 ;-)
[^] # Re: Un serveur dédié ca se backup
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Serveur dédié / IMAP / fetchmail. Évalué à 2.
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).
# Et l'avenir ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie du noyau Linux 2.6.23. Évalué à 2.
[^] # Re: Une réorganisation
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Évolution dans le projet Mozilla Thunderbird. Évalué à 10.
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".
[^] # Re: Economies / dépenses
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 3.
[^] # Re: Maintenance du code Java ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 5.
J'imagine que ça n'a pas du être une mince à faire que de faire ce traducteur de code...
Vivement le prochain n'épisode :-)
# Gestion d'arbres par représentation intervallaire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Création du projet "OQLToLang". Évalué à 5.
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.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 2.
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é.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 2.
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)
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 2.
* 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.
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 1.
pardon, il faut lire "certains traitements de Jelix"
[^] # Re: Quel avantage par rapport à symfony ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 3.
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.
[^] # Re: Documentation
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Jelix 1.0 beta 3. Évalué à 3.
Mais je note ta requête :-)
[^] # Re: Compassion
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ca y est .... Évalué à 4.
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.
[^] # Re: Pour la pilule rouge...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ben Laden, etc.... Évalué à 3.
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.
[^] # Re: Pour la pilule rouge...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Ben Laden, etc.... Évalué à 2.
[^] # Re: décidément
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Décès d'une figure légendaire du cinéma. Évalué à 1.
http://tourtesmagazine.com/dieu/?p=25
[^] # Re: exemple avec firefox/XUL
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité d'un langage de script comme langage d'extension d'un logiciel.. Évalué à 2.
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.
[^] # Re: exemple avec firefox/XUL
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité d'un langage de script comme langage d'extension d'un logiciel.. Évalué à 2.
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é".
[^] # Re: heu ???
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Rigolons un peu avec ODF. Évalué à 4.
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...)
# exemple avec firefox/XUL
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité d'un langage de script comme langage d'extension d'un logiciel.. Évalué à 2.
Et puis je plussois ce que dit pasBillpasGates : un langage de script permet de limiter les dégâts en terme de gestion de mémoire, de limiter l'accés à certaines API internes pour pas faire n'importe quoi, puisque c'est l'interpréteur qui gère ces problémes. Mais ça ne les éradique pas forcément, comme on peut le voir avec certaines extensions Firefox codées avec les pieds, et qui contiennent des leaks dans tous les sens.
[^] # Re: Nvu 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Publication de KompoZer 0.7.10. Évalué à 9.
Ça prouve rien du tout. Et surtout il n'y a eu aucune erreur. Ce sont des circonstances qui ont fait que la poursuite du développement de la version 1 est tombé à l'eau pour nous.
>ce KompoZer mériterait d'avoir le nom nvu-1.7.10
Peut-être, mais NVU est une marque de Linspire, et il n'est pas possible de la réutiliser pour des versions ultérieures de NVU 1.0 sans le consentement de Linspire... (oui je sais c'est dommage mais c'est comme ça et c'est valable même pour nous à DI ).
[^] # Re: Nvu 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Publication de KompoZer 0.7.10. Évalué à 7.
Je ne sais pas où tu as lu ça, mais sache que c'est totalement faux. J'ai pas l'impression de travailler sur FullerScreen, ou alors serait-ce à l'insu de mon plein grés ? :-). FullerScreen n'est qu'un "petite" extension que Glazou réalise entre deux projets.
En ce qui concerne le développement de Mozilla "nvu2" Composer, c'est vrai que c'est un peu en suspend, mais bon, todo list énorme, clients, autres projets prioritaires, tout ça... (d'ailleurs, au passage, si une entreprise veut bien "sponsoriser" le dev de Composer...).
# s/firefox/minimo
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Navigateurs webs et machines lentes. Évalué à 2.
c'est une cause oui. Mais bon, sur ce genre de machine, il me semble que le opera installé n'est pas la version desktop, mais une version "embarqué", avec une interface spécifique, adaptée pour les petits écrans. Donc au même titre qu'opéra, tu n'utiliseras pas Firefox sur ce genre de machine, mais son accolyte minimo ou maemo (qui n'ont à priori pas d'interfaces en XUL)
>Est-ce que Gecko tout seul est suffisamment léger pour espérer tourner sur une machine lente avec peu de RAM, si on lui fournit une GUI appropriée ?
réponse oui : minimo fonctionne depuis quelques années déjà sur des appareils bien moins puissant que le nokia. (mais le développement de minimo est un peu en suspend depuis quelques mois il me semble).
Mais il est probable tout de même que gecko soit plus lourd que le moteur d'opera.
[^] # Re: ou alors...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 3.
<?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
</stream:stream>
Voici le même message envoyé avec IRC :
:expediteur@exemple.com PRIVMSG destinataire@exemple.net :Hello are you receiving this message ?
Quand on calcule le nombre de caractère (je ne compte pas les caractères blanc entre les balises pour xmpp), on a un paquet de 298 caractères pour XMPP contre 97 pour IRC. Soit un facteur 3.
Si on ne compte pas les parties variables (nom des destinataire/expediteur et le message en lui même), on a 214 caractères contre 13, soit un facteur 16 !
Bref, xmpp est beaucoup plus gourmand en bande passante que IRC et demande un peu plus de ressource au niveau du client puisque parser du XML est quand même beaucoup plus compliqué que de parser une commande IRC (m'enfin je chippotte, pour une machine moderne, la différence ne se voit pas, sauf peut être si on est connécté à 20 channels de 150 users en même temps avec des discussions trollesques à gogo).
Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement.
Note: c'est amusant^W delirant aussi de voir l'énorme différence entre un ping en XMPP et un ping IRC (envoyé entre client et serveur pour savoir par l'un si l'autre est alive et vice versa).