Tramo Piere a écrit 53 commentaires

  • # Quelques gros problèmes

    Posté par  . En réponse à la dépêche Sortie de Tulip 3.4.0. Évalué à 2.

    Ça va être cruel mais bon, Tulip est très bien pour faire de la recherche, mais beaucoup moins pour bosser avec (v3.3.1):

    * Pour pouvoir ouvrir des fichiers autres que ceux de Tulip il faut passer par un sous-menu relativement compliqué (et j'ai mis un moment avant de le trouver)
    * L'import de fichiers .dot ne fonctionne pas très bien (graphviz), ou du moins je n'ai réussi à importer aucun de mes fichiers
    * L'éditeur de nodes/edge est incompréhensible (15 minutes que j'essaye, j'ai toujours pas trouvé)
    * Je finis par trouver les boutons pour ajouter des noeuds de façon graphique, ça marche, par contre le graphe n'est toujours pas éditable dans le "graph editor", ou du moins je ne trouve pas les paramètres
    * La ligne de commande est inexistante ("tulip --help" essaye de m'ouvrir le fichier "--help"), donc pas possible d'exporter les graphes automatiquement comme dot, donc pas moyen de faire des scripts pour intégrer avec latex/pdflatex/asciidoc/docbook/monsiteweb
    * Les fichiers .tlp sont un mélange de lisp et de xml.
    * Le rouge par défaut commence à me faire mal aux yeux (jaune pastel pour les noeuds, avec une forme arrondie pour bien mettre en évidence que c'est bien un noeud, noir pour les liens?)
    * Je finis par trouver la "table view", mais elle est en lecture seule...
    * J'essaye de changer la forme d'un noeud dans les propriétés, le noeud ne change pas
    * Peut-on ajouter des flèches à partir du menu contextuel? faire des sous-graphes? faire des liens entre sous-graphes? avancer sur ma thèse?

    Pour l'instant graphviz (dot) a les quelques bonnes options par défaut, et même s'il est très limité (manque de couleurs, layout s'il veut bien) il peut s'encapsuler facilement, tant par la ligne de commande que par le format de fichier.
  • [^] # Re: Performance de Jython

    Posté par  . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.

    Les threads java ont des fonctionalités en plus comme par exemple le join que les threads python n'ont pas:
    http://aspn.activestate.com/ASPN/Mail/Message/Jython-users/2(...)
    http://blogs.sun.com/sundararajan/entry/java_integration_bea(...)

    Malheureusement, l'utilisation des threads java n'améliore pas les perfomances de waf (testé avec un processeur dual core).
  • [^] # ça passe très mal

    Posté par  . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 1.

    Justement, Waf utilise pas mal de facteurs différents: lancement de processus, lecture de fichiers, analyse syntaxique (préprocesseur), programmation concurrente.

    Pour le moment les profiles obtenus montrent que tout est plus lent que cPython, et pas seulement pour Waf:
    http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)

    Note: l'utilisation des threads java n'améliore pas les performances.
  • # Performance de Jython

    Posté par  . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.

    Pour l'instant, le code python non modifié est plus lent sur Jython:

    http://psycle.svn.sourceforge.net/viewvc/psycle/branches/boh(...)

    Il reste à voir avec l'utilisation des threads Java, par contre on y perd en portabilité :-/
  • [^] # Re: Ant like. A quand un maven like ?

    Posté par  . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à 4.

    J'utilise Maven au boulot, et je le vois surtout comme une surcouche à Ant.

    Pour Maven, on reste toujours avec des fichiers XML qui ne sont pas fait pour écrire du code. Le fait de télécharger les dépendances à partir d'internet est aussi relativement gênant lorsque l'on travaille en local, et la structure imposée n'est pas forcément la plus logique bien qu'elle convienne pour un certain nombre d'applications de gestion en J2EE

    Waf et les autotools possèdent cependant un concept similaire dans l'écriture du code: la configuration, la compilation, l'installation, la vérification (make distcheck), la distribution (make dist).

    Pour ce qui est de la lourdeur du modèle de tâches et de dépendances, je pense qu'il s'agit surtout d'un problème de granularité, par exemple pour des projets en C on se retrouve avec des fichiers objets individuels (.o) alors qu'en java des répertoires entiers sont transformés en même temps, le compilateur java de sun faisant un optimisation globale (avec des fichiers inner class impossibles à prédire avant de compiler les fichiers).

    La diversité des outils et des compilateurs, c'est aussi ce qui fait la richesse des environnements de type Unix, et sur cet aspect, Maven est un peu calqué sur le modèle Windows.
  • [^] # Re: Pour Debian

    Posté par  . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à 1.

    Le support pour fakeroot est présent, ce qui permet de construire des .deb et des .rpm facilement et des commandes équivalentes à "configure; make; DESTDIR=foo make install" sont présentes.

    La redistribution du script Waf sans autre dépendance que Python facilite énormément le travail des packagers.

    La création de packages soi-même n'est pas recommandé (version du système, gestion des dépendances sur d'autres packages, version des scripts, portabilité), même s'il est possible de le faire facilement à travers de quelques fonctions en Python.

    Une commande similaire à "make dist" (waf dist) permet de générer une archive avec les sources de son projet.
  • [^] # Re: Pour GNOME

    Posté par  . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à 2.

    Les technologies gnome sont en effet supportées, le mieux c'est de regarder du côté d'xmms2, mais il y a quelques exemples ici:
    http://code.google.com/p/waf/source/browse/trunk/demos/gnome
  • [^] # Re: Intéressant

    Posté par  . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à 3.

    Pour quelle raison ?

    Linux c'est mieux :-)

    J'aurais du ajouter avec Qt, la detection automatique de Qt4 ne fonctionant que sur les systèmes de type Linux pour le moment.
  • [^] # Re: Intéressant

    Posté par  . En réponse à la dépêche Waf - un système de construction de logiciels. Évalué à 2.

    Il y a un exemple pour qt4:
    http://code.google.com/p/waf/source/browse/trunk/demos/qt4/

    Le support est restreint à l'utilisation du style KDE pour des raisons historiques et de performances:
    #include "foo.moc" en fin de fichier cpp
    Ceci permet des temps de compilation entre 30 et 40% plus rapides, mais diverge un tout petit peu des exemples Qt (où des fichiers _moc.cpp sont générés).

    Des utilisateurs appliquent Waf pour la cross-compilation, il s'agit en général de changer les paramètres de configuration. Le développement d'applications pour Windows n'est cependant pas recommandé.
  • [^] # Re: Autotools vs CMake

    Posté par  . En réponse à la dépêche KDE devient multiplateforme. Évalué à 2.

    "waf distcheck" est en standard depuis waf 1.3.0
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.

    En javascript on peut tout remplacer à chaud (de même en Python, on peut même déclarer de nouveaux modules et on dispose de métaclasses). Pour Java c'est plus difficile, mais avec Groovy on peut y arriver aussi.
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.

    > Ou alors tu utilises le debugger intégré à ton IDE.

    Sauf en production.
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.

    > C# 3 :

    C'est bien, ça s'améliore. Dommage que mono soit encore loin derrière :-)

    > le langage expose plus ou moins de possibilité en fonction de la machine "cible". C'est fortement lié.

    On peut compiler du caml ou du F# en .Net
    Implémentation != language

    > Il est où le serveur d'application en Squeak ou Delphi

    Nulle part, Delphi est mort (les devs sont partis), et Squeak est un framework orienté ihm (il est où le framework IHM en .Net ?).

    Mais pour ce qui est de la consommation de ressources et la fluidité .Net a encore du chemin avant de rattraper le vieux Delphi.
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.

    Un petit mot sur l'aop:
    Lorsque l'on veut débugger sérieusement un algorithme ou du code complexe, on va ajouter des logs en entrée et en sortie, ce qui pollue rapidement le code.
    En remplaçant dynamiquement les fonctions ou les méthodes, on peut ajouter des logs sélectivement. On peut aussi utiliser ce mécanisme pour étendre l'outil avec de nouvelles fonctions, sans pour autant ajouter un arbre de classes supplémentaire.

    J'utilise ces techniques en javascript (affichage de pile des appels de fonctions lors d'une exception), mais on y trouve d'importants usages en java (aspectJ), et dans d'autres langages le mécanisme est immédiat (Python).
    Exemple de projet utilisant ce mécanisme: http://code.google.com/p/waf

    Le Y combinator en haskell/caml se rapproche de ce concept (déboggage/extension des fonctions récursives).
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.

    > Lisp c'est joli pour les mathématiciens, mais ca sert pas à grand chose pour un informaticien
    Ben justement si:
    * inférence des types
    * programmation par contrats (assert est insuffisant)
    * aide au déboggage (aop)
    Des concepts qui existent depuis bien longtemps.

    Il n'y a effectivement pas que les maths, il y a aussi l'histoire de l'informatique. Et c'est bien de connaître un outil, mais c'est beaucoup mieux d'en connaître les limites.


    Quand tu parles de framework, tu t'éloignes du language pour en venir aux bibliothèques. Mais on peut aussi en revenir au pourquoi du framework : le language ne permet pas d'encapsuler les requêtes sql correctement, ou de permettre une implémentation mvc simple et modulaire. Et comme il s'agit de languages bien statiques, on finit par se retrouver avec plus de fichiers xml (que pas mal critiquent pour la lisibilité) que de code (java, c#). Autant pour la lisibilité de Lisp.

    Enfin, J2EE, .Net réinventent la roue (Squeak, Delphi), en moins bien et surtout en beaucoup plus lent et volumineux.
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.

    > Même si beaucoup de tes critiques sont pertinentes, il n'y a pas à l'heure actuelle d'alternative pour leurs segments d'utilisation. Tous les autres langages ont leurs défauts propres qui ne leur permet pas de remplacer Java ou C# pour de nombreuses utilisations.

    Bon, un exemple concret: Lisp:
    SQL est un dérivé de Lisp. Javascript est très similaire à Lisp. Les css peuvent se représenter efficacement en Lisp. Le modèle DOM (html, xhtml) peut se représenter très bien aussi en Lisp (remplacer les tags par des parenthèses, l'arbre reste le même). Et après tout ce temps (faisait déjà tout ça il y a 40 ans) ni java ni c# n'ont toutes les fonctionnalités de Lisp, ni les performances.

    Pourquoi Lisp n'a pas percé ? On peut lui reprocher sa syntaxe (Lissac partage ce problème), l'absence de grandes entreprises derrière (sans Sun, Java serait resté oak, sans Microsoft, pas de C# et sans miguel, à boire), et surtout l'ignorance des programmeurs qui restent dans leur caverne.
  • [^] # Re: sonntag

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.

    C'est sur que lorsque l'on ne connait que java ou c# on a du mal à voir les problèmes.

    Voici quelques exemples: absence de contrats, de closures, aspects dynamiques limités (ou bien il faut des extensions comme Groovy), complexité de la grammaire (et donc lenteur de la compilation), pas de curryfication, pas de tail recursion, ..

    Pour l'utilisation classique des SOA/IHM/Web, la quantité de design patterns et l'apparition de tant de différents languages (Groovy, Jython, ..), et de frameworks (Junit, Aspectj, Hibernate, ..) montrent tout à fait la faiblesse des briques de base qui sont incapables d'évoluer.

    Comme les architectes et programmeurs sont très paresseux, la tendance est d'ajouter des couches d'abstraction. Un exemple sur les Makefiles : au lieu d'améliorer Make (qui n'a pas évolué depuis le début), on fait des générateurs de makefiles, plutôt que de penser globalement on appelle Make récursivement (et pour les performances on n'a qu'à changer le hardware).
  • [^] # license et divers points techniques

    Posté par  . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.

    Ne serait-il pas mieux d'ajouter une exception à la GPLv3 de la bibliothèque (ou changer pour la LGPLv3) afin de permettre le développement de logiciels en licence GPLv2, QPL, propriétaire, etc ?

    Concernant les fonctionnalités:
    * je n'aime vraiment pas du tout la syntaxe smalltalk, n'est-il pas possible d'avoir un préprocesseur intégré (à la camlp5 ou ocaml+twt) ? Avoir quelquechose de ressemblant à Python ou à D (ou même caml) serait un grand plus.
    * Concurrence : les performances sont-elles les mêmes en architecture multi-coeur, multi-processeur ?
    * Interaction avec les bibliothèques existantes : comment lier le code à du c ? Est-t-il possible d'écrire facilement des librairies partagées ?
  • [^] # Re: OOXML is defective by design

    Posté par  . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 3.

    C'est un truc de commercial. En même temps, vu la boîte d'où il vient .. :-)
  • [^] # Re: OOXML is defective by design

    Posté par  . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 2.

    C'est qui qui a voté deux fois pour faire passer son standard OOXML à lui tout seul ? :-)
    http://www.computerworld.com/action/article.do?command=viewA(...)

    Quand on voit l'éthique de certains employés, on ne peut que trembler à l'idée de celle des managers.
  • [^] # Re: OOXML is defective by design

    Posté par  . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 4.

    Non, toutes les infos y sont pas:
    http://ooxmlisdefectivebydesign.blogspot.com/
    genre la partie sur vml

    Ensuite l'intérop, c'est aussi d'utiliser des standards, comme euh par exemple POSIX, afin de faire du logiciel portable. Pas portable -> pas intérop.
  • [^] # Re: OOXML is defective by design

    Posté par  . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 3.

    C'est si dur d'écrire du logiciel portable et interopérable ? :-)
  • [^] # Re: Idée reçue à combattre

    Posté par  . En réponse à la dépêche Les virus sous Linux. Évalué à 2.

    - IE et Firefox ont du etre patche, pas l'OS, c'est pas par hasard que je te dis que tu ne comprend rien au probleme.

    Premièrement, IE fait bien parti de l'OS (excepté pour Vista).

    Ensuite le bug avait bien été corrigé dans l'OS lui-même (SP2) parce qu'il permettait d'exécuter des programmes directement par le système (un peu comme si sous linux firefox permettait l'accès en root).
    http://www.microsoft.com/technet/security/bulletin/ms02-072.(...)
    http://www.ciac.org/ciac/bulletins/n-029.shtml

    Il s'agit bien d'un problème de fonctionnalités, windows permet d'exécuter du code trop facilement et les programmes font copier-coller des erreurs.

    - ce powerpoint qui permettrait de prendre le controle de ma machine ans que je fasse quoi que ce soit de stupide

    Ici par exemple ?
    http://news.bbc.co.uk/2/hi/technology/5195838.stm
  • [^] # Re: mouais

    Posté par  . En réponse à la dépêche Les virus sous Linux. Évalué à 3.

    - Justement non, car personne ne va faire l'effort pour 5% quand il peut faire le meme effort et atteindre 90% du marche

    C'est une affirmation gratuite, et voici exactement l' exemple du contraire:
    http://linuxfr.org/comments/861012.html#861012

    - suffit d'ecrire un soft SOUS windows pour qu'il soit automatiquement mauvais, c'est inne a la plateforme

    Il suffit de copier un mauvais design pour effectivement hériter des mêmes problèmes. Dans ce cas il s'agit de la facilité à lancer du code venant de sources inconnues, et sans suffisamment de validation.

    - t'as deja entendu parler des failles qu'il y avait dans bind, wu_ftpd et sendmail

    On parlait des applications du desktop, pas des serveurs.
  • [^] # Re: mouais

    Posté par  . En réponse à la dépêche Les virus sous Linux. Évalué à 2.

    faut croire qu'il y a un probleme de design dans Unix mon cher

    L'exemple parlait du shell win32 qui a affecté à la fois IE et Firefox. On retrouve une tonne d'exemples liés uniquement aux librairies de windows tels que les curseurs .ani, les fichiers .wmf, le problème de shell win32, les macros office, qui dénotent un problème de design, c'est à dire l'exécution de code arbitraire beaucoup trop facile. Heureusement, cela commence à changer avec Vista.

    - moins de 5% du marche desktop

    On devrait donc s'attendre à voir 5% du nombre de virus de la plateforme la plus populaire ?

    - Windows 2000, XP, 2003 et Vista n'utilisent pas la meme version de compilo et il y a qqe differences dans les options

    On parlait de gcc et des distributions Linux là. Windows utilise un compilateur et des technologies de protections analogues, mais bien différentes.

    - Quand a AppArmor, j'attends toujours de le voir sur un systeme desktop sans hurlements de la part des utilisateurs.

    Tu as quoi à lui reprocher exactement ? Tu voulais un exemple, le voilà.

    - du code antique dans Linux il y en a a la pelle comme dans les autres OS

    Pas vraiment, car Linux n'a pas les mêmes impératifs de compatibilité que windows (16 bit, etc). Les apis changent et les appels systèmes aussi. C'est bien ce que l'exemple de la librairie wmf a montré.

    - le fait qu'il ait existe sous Windows explique tout n'est ce pas ?

    En grande partie oui, lorsque l'on voit à quel point OpenOffice.org s'est inspiré du design de ms-office (macros, etc). OpenOffice.org est aussi un des logiciels qui exporte sa propre librairie plutôt que d'utiliser les standards sous Linux (gtk, Qt, motif), il suffit de voir la taille du fichier d'installation pour Windows et pour Linux (~ 70 vs 100Mb)