wilk a écrit 1090 commentaires

  • [^] # Re: et python ? :)

    Posté par  . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.

    ton programme prend 10 minutes à se lancer

    Déjà là ça commence mal...

    Je me pose également une question existentielle. Pourquoi les développeurs donnent tant d'importance aux erreurs de typage lorsqu'ils en sont protégés et non ceux qui devraient en être les victimes ? Pour ma part, non plus, la seule fois que je me souvienne d'avoir été embêté avec des erreurs de typage c'est quand je suis passé en unicode. Mis à part ça je ne me souviens pas que ça m'ait posé de problème, quelqu'en soit le langage.

  • [^] # Re: et python ? :)

    Posté par  . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.

    Il faut maintenant regarder du côté de PyPy si on a besoin de performance pure du langage (ce qui est rarement le cas). Les résultats sont considérables dans certains domaines et ça continue à progresser sans arrêt.
    Sur un programme de calcul d'itinéraire on a eu un facteur supérieur à 10 sans changer une ligne de code !
    Ce qui est marrant dans ce projet c'est qu'au départ le programme était écrit en C, il était trop lent et trop complexe, il a été réécrit en Python pour servir de prototype avec d'autres algorithmes. Résultat le prototype est allé 10x plus vite qu'en C car la facilité de programmation à permis de se concentrer sur l'algo, on l'a gardé comme ça en prod pour faciliter la maintenance (qui est finalement nulle). On a été tenté de le transcrire en Java mais des tests sur le même genre d'algo n'ont montré qu'un gain très faible pour une complexité bien supérieure.

    http://speed.pypy.org/

  • [^] # Re: Merci le LTS

    Posté par  . En réponse à la dépêche FreeBSD 8.2 et 7.4 : deux sorties pour le prix d'une. Évalué à 4.

    Une durée longue de release est à double tranchant. D'un côté ça limite le nombre d'upgrade mais d'un autre côté ça les rends plus difficiles, avec d'avantages de changements d'un seul coup. Inversement des releases fréquentes limitent le nombre de changements pour chacune et les rends plus simples, parfois insignifiantes. Je me souviens encore de la migration où on est passé d'exim3 à 4 apache 1 à 2 et iso8859 à utf8 ! une horreur ! En revanche de la lenny à la squeeze pour moi ça a été insignifiant.

  • [^] # Re: Bof ?

    Posté par  . En réponse au sondage Je trouve la nouvelle version de LinuxFr ..... Évalué à 1.

    Bof c'est plutôt un compliment dans le cas d'une migration, ça signifie qu'elle est réussie !

  • [^] # Re: La ruse de cache sur erreur 404 de Templeet est-elle toujours active ?

    Posté par  . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 3.

    De quelles possibilités tu parles ? Comment est géré la purge du cache par ex ?

    L'authentification de l'utilisateur était gérée en javascript + cookies non ?

  • [^] # Re: mode avocat du diable

    Posté par  . En réponse à la dépêche Python 3.2. Évalué à 1.

    Ta calculatrice, quand tu tapes 1/2, elle répond quoi ? Et bien maintenant Python répond pareil.

    Dans ce cas ça n'est pas des flottants qu'il faudrait utiliser mais des décimaux.

    Ma calculatrice ne m'indique pas

    In [2]: 2+.4
    Out[2]: 2.3999999999999999
    
  • [^] # Re: Je suis français donc je râle

    Posté par  . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 1.

    Et textile ? Peut-être pas pour les commentaires, mais pour les dépêches ça pourrait être appréciable.

  • [^] # Re: Pourquoi ne pas utiliser mod_rails ?

    Posté par  . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 3.

    NGINX n'est pas fait que pour les sites avec fort traffic, il est également particulièrement adapté aux petites configs genre serveurs virtuels. C'est peut-être de cette "mode" qu'il s'agit. C'est à dire de passer d'hébergements mutualisés avec php à des hébergement sur serveurs virtuels et des applis web en mode proxy pour utiliser autre chose que du php.

  • [^] # Re: Wow

    Posté par  . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 1.

    Les points que tu mentionnent sont spécifique à Java peut-être ? Car en python par exemple on peut très bien déployer une application web sans avoir à installer de serveur http ni apprendre plusieurs langages. OpenERP en est un exemple il me semble. Personnellement il m'arrive de déployer des applications web sous windows à l'aide d'un simple exe.

    Ceci dit ça n'a pas grande importance, bravo pour le travail et sa diffusion.

  • [^] # Re: Bravo pour la migration !

    Posté par  . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 6.

    Bruno, tu as démontré que tu pouvais faire faire beaucoup mieux que la plupart des boites spécialisées. En tant que vieux briscard de la prog, je suis impressionné et je te tire mon chapeau pour cette mise en production.

  • [^] # Re: Nouveaux commentaires en rouge ?

    Posté par  . En réponse à la dépêche Architecture logicielle de la nouvelle version de LinuxFr.org. Évalué à 6.

    Moi c'est le scrolling d'un commentaire nouveau à l'autre qui me donne le mal de mer...

  • [^] # Re: Et la doc?

    Posté par  . En réponse à la dépêche OpenERP v6.0 est disponible. Évalué à 2.

    Autrement dit il faut aller voir le code ?
  • [^] # Re: Et la doc?

    Posté par  . En réponse à la dépêche OpenERP v6.0 est disponible. Évalué à 1.

    Je préfère pouvoir importer à l'aide d'une API d'une part pour pouvoir comprendre l'outil et aussi parce que j'ai fait beaucoup de spécifs qui en ont besoin (par exemple de la réplication agence/siege, prise de commande à distance etc.) et j'aimerai bien voir ce que ça donnerait avec openerp.
  • [^] # Re: Et la doc?

    Posté par  . En réponse à la dépêche OpenERP v6.0 est disponible. Évalué à 1.

    J'ai également un peu de mal avec la doc développeur (que je n'ai fait que survoler je l'avoue). Par exemple pour commencer j'aimerai importer des données clients, produits, devis, factures etc... Je pensais utiliser xml-rpc, mais où se trouve la liste des fonctions accessibles ? Sinon je pensais taper dans la base postgresql, mais je ne trouve pas non plus de description des tables...
  • # pyexiv2

    Posté par  . En réponse au message Conseil pour lire des données EXIF ?. Évalué à 1.

    Je viens de voir ça passer dans les annonces

    https://launchpad.net/pyexiv2
  • [^] # Re: Excellente nouvelle... qui se lance ?

    Posté par  . En réponse au journal pypy de plus en plus rapide ?. Évalué à 1.

    Merci de t'être intéressé à mon code ! Je viens de l'essayer, sauf erreur ton code est beaucoup plus rapide avec pypy mais moins avec cpython ou psyco. Tu confirmes ?

    ton code
    cpython 124s
    pypy 13s
    psyco 4s

    le mien
    cpython 86s
    pypy 107s
    psyco 1s
  • [^] # Re: Excellente nouvelle... qui se lance ?

    Posté par  . En réponse au journal pypy de plus en plus rapide ?. Évalué à 1.

    J'ai testé sur un petit algo qui recherche les différentes possibilités de déplacement d'un cheval sur un damier sans repasser par la même case... Je ne sais pas si c'est très clair, ça donne par ex sur un damier 3x3

    147
    6X2
    385

    J'ai écrit le code pour python, c, php, java et différentes variations python.

    Avec pypy1.4 il n'y a quasiment pas de différence avec cpython, en revanche il y a énormément de différence avec psyco... (de 3m contre 2s), je trouve curieux que ce genre de code n'ait pas été plus optimisé, il faudra que je leur en parle...
    http://hg.flibuste.net/libre/games/cheval/file

    En revanche je viens d'essayer sur petit programme de calcul d'itinéraires (un vrai programme en prod), c'est impressionnant, le résultat est similaire qu'avec psyco, le rapport est de 1 à 100 ! C'est très prometteur.
  • # Fun

    Posté par  . En réponse au journal Pourquoi Ruby on Rails pour la réécriture de LinuxFr.org ?. Évalué à 4.

    Ruby est un langage bien plus fun que Python : je pense que la communauté Python est trop sérieuse

    En tant que développeur en Python pour le boulot, je confirme tout à fait ton point de vue. J'ai justement choisi Python pour aller droit au but sans me laisser distraire. Pour les loisirs ou r&d ça m'ennuierait sûrement.
  • [^] # Re: .

    Posté par  . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 1.

    Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

    Le typage est un critère de maintenabilité ? Pour un compilateur peut-être, pour un humain c'est déjà moins sûr.

    C'est plutôt la concision et la clarté du code qui compte. (cf l'étude d'IBM qui fait un rapprochement tout bête entre le nombre de lignes et le nombre de bugs).

    La disponibilité d'un IDE potable me semble aussi un minimum si on veut que les développeurs se concentrent plus sur le fond que la forme (autocomplétion, refactoring, affichage des erreurs à la volée)

    De la même manière, plus le code va être concis, explicite et clair, moins l'ide va avoir d'importance.
  • [^] # Re: système de cache

    Posté par  . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 1.

    Oui, c'est un casse tête quand il y a beaucoup de parties dynamiques...

    Une solution que j'utilise maintenant, en complément, c'est de générer (à la volée toujours) un certain nombre de données dans des fichiers html ou json qui sont appelés en javascript/ajax.
  • # le choix de mysql

    Posté par  . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 3.

    Même question pour la base de données. Est-ce un choix technique ou une préférence personnelle ?
  • # système de cache

    Posté par  . En réponse au journal Pourquoi réécrire LinuxFr.org ?. Évalué à 1.

    Si mes souvenirs sont bon, la version actuelle avec templeet utilisait (je ne sais pas si c'est toujours le cas) la redirection des 404 vers l'appli qui générait une page statique pour la fois d'après, page supprimée à la moindre maj. Personnellement j'utilise ce système très souvent, avec nginx et une appli en proxy (python) c'est redoutablement simple et efficace.

    Quel système de cache est utilisé dans cette nouvelle version (et qui devrait rendre caduque les questions sur la rapidité du langage...) ?
  • [^] # Re: Ca existe toujours ça ?

    Posté par  . En réponse à la dépêche Vim 7.3. Évalué à 2.

    C'est justement parce que l'on n'a pas la patience de "tout essayer à taton" que l'on trouve beaucoup plus efficace de ne pas changer d'éditeur au grès des modes.

    Est-ce que les djeuns utilisent les crayons gris ? Il va bien arriver un moment ou ils risquent d'être considérés comme obsolètes, non ? Non.
  • [^] # Re: ocase

    Posté par  . En réponse au message Ou acheter Lenovo T410 ?. Évalué à 1.

    ocase avec un seul C ça fait vraiment moche...
  • # ocase

    Posté par  . En réponse au message Ou acheter Lenovo T410 ?. Évalué à 1.

    On commence à trouver des Txxx d'occasion. Mais je me pose la même question que toi, est-ce que la fiabilité, le bon clavier, l'écran mat etc sont toujours d'actualité sur ces modèles ? Est-ce que dans la concurrence il y a un équivalent aujourd'hui ?