Étienne a écrit 707 commentaires

  • [^] # Re: Une si bonne API

    Posté par  . En réponse à la dépêche Sortie de Qt 4.6. Évalué à 3.

    D'une part cela ne marche pas, d'autre part le # et le 8 ne sont pas dans des variables.

    Étienne
  • [^] # Re: Une si bonne API

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


    * pour utiliser gettext avec ce magnifique système ? Les défenseurs de C++ ont toujours tendance à considérer ce point comme négligeable et à l’occulter ; en pratique, il ne l’est absolument pas (négligeable)


    On peut utiliser boost format (ou d'autres, loki safeformat, fastformat, ...) qui s'intègrent très bien avec gettext tout en étant typesafe.

    * un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
    Sur ce point on a une bien plus grande souplesse avec les flux de la STL qui sépare bien la partie formatage de la partie lecture/ecriture à travers les streambuf. Ce qui permet de faire des choses comme :
    * écrire dans plusieurs fichiers simultanément
    * fournir un pourcentage de progression au fur et à mesure de la lecture d'un fichier
    * lire depuis/vers un buffer,
    * lire depuis/vers une socket
    * ...

    Il suffit pour cela de fournir son propre streambuf. On peut pour cela s'aider de boost::iostreams qui simplifie bien les choses.

    Pour simplement faire un tee, on peut aussi faire comme en C

    On peut trouver, et à raison, que la STL est un peu complexe à ce niveau, mais on a une souplesse indéniable.

    Étienne
  • [^] # Re: Une si bonne API

    Posté par  . En réponse à la dépêche Sortie de Qt 4.6. Évalué à 4.

    On voit quand même que faire le formatage dans la chaine de format n'est pas la panacée et que ça devient rapidement des incantations chamaniques. Je n'ai pas trouvé comment faire l'équivalent de :
    int num=12, width=8;
    char fillChar='#';
    std::cout << std::setfill(fillChar) << std::setw(width) << num;


    Alors certes c'est parfois un peu verbeux lorsqu'il n'y a aucun formatage à faire mais dès qu'on veut faire la moindre petite chose c'est à la fois puissant, expressif et beaucoup plus souple qu'une chaîne de format.
  • [^] # Re: Une si bonne API

    Posté par  . En réponse à la dépêche Sortie de Qt 4.6. Évalué à 3.

    C++0x vise à simplifier les messages d'erreur des compilateurs.

    Depuis qu'il a été décidé de supprimer les concepts de la prochaine version du C++, ce n'est plus le cas.


    Étienne
  • [^] # Re: pas d'accord

    Posté par  . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 6.

    La vrai question que l'on peut se poser c'est est-ce que Setup est capable de résoudre un Sudoku ? (cf http://algebraicthunk.net/~dburrows/blog/entry/package-manag(...) ).


    Étienne
  • [^] # Re: vim

    Posté par  . En réponse au message Python : editeur qui fait la completion. Évalué à 3.

    Sinon, j'utilise ipython comme shell et interpréteur python et il fait la complétion tout seul comme un grand avec la touche tab.

    Pour avoir la même chose avec cpython, il suffit de mettre dans ton ~/.pythonrc
    try:
        import readline
    except ImportError:
        print ("Module readline not available")
    else:
        import rlcompleter
        readline.parse_and_bind("tab: complete")
  • [^] # Re: Coin

    Posté par  . En réponse au journal Google Wave pour tous (même si vous en voulez pas !). Évalué à 2.

    Tu pourrai être plus précis, ta demande me parait un peu vague.
  • [^] # Re: Le showbiz, c'est fait par des cons pour des cons !!

    Posté par  . En réponse au journal Jocelyn Quivrin bronsonisé. Évalué à 9.

    Personne ne connais le nom de certain [...] développeur J2EE

    Et Pierre Tramo alors ?
  • [^] # Re: Le vrai probleme:

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.

    - bcp plus de socketa à allouer du coté serveur
    Je pense le contraire, ne serait-ce que parce que tu rajoute une sémantique en disant quels sont les flux qui ont besoin de rester ouverts (le flush où il y a du PUSH) et quels sont ceux qui peuvent être fermés. Le problème actuel du keep-alive (et la raison pour laquelle il est désactivé sur un bon nombre de serveur), c'est qu'on ne sait jamais si une connexion doit rester ouverte ou pas, donc tout ce qu'on peut faire c'est avoir un temps d'inactivité au bout duquel on coupe la connexion. En permettant de cibler les flux qui doivent rester ouverts, tu peux déjà fermer toutes les connexions sur lesquels il n'y a pas de flux en PUSH. D'autre part, tu multiplexe ta connexion pour y faire passer plusieurs flux et par là même tu diminue ton nombre de connexions. Si on prend l'exemple de linuxfr :

    Un utilisateur qui ouvre la page d'accueil et la page des journaux

    En SPDY
    On va ouvrir une seule connexion avec 2 flux, pas besoin de PUSH, on peut fermer la connexion après le chargement des 2 pages

    avec du HTTP en Keep-Alive
    On ouvre 2 connexions qui restent ouvertes jusqu'à expiration du timeout.

    Un utilisateur qui ouvre la page d'accueil et la tribune

    En SPDY
    Il ouvre une connexion avec 2 flux dont l'un en PUSH. Lorsque les 2 pages sont chargées, la connexion reste ouverte car il reste un fluxh en PUSH. L'utilisateur n'a pas besoin de solliciter le serveur toute les quelques secondes, le serveur peut envoyer des données seulement lorsqu'un nouveau message arrive.

    En HTTP avec du Keep-Alive
    On ouvre 2 connexions, la première se ferme à expiration du timeout, tandis que l'autre reste ouverte mais le client doit en plus solliciter le serveur toutes les quelques secondes pour récupérer les nouveaux message.


    Je pense que globalement, avec un protocole qui permet de caractériser les flux, le serveur peut faire des choix plus éclairés que de simplement attendre la fin d'un timeout, et par là même mieux gérer ses connexions et ses ressources.



    Quand au problème sur les autres outils, il a bien fallut développer des framework pour faire de l'Ajax depuis quelques années, et on n'a que l'embarras du choix, je ne pense pas qu'il faudra très longtemps si ce protocole (ou un similaire) débarque, pour voir apparaître de nombreuses solutions techniques.
  • [^] # Re: Push

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.

    Seules les connexions avec des flux en PUSH ont besoin de rester ouvertes, pour les connexions sans flux en PUSH, c'est identique au keep-alive du HTTP actuel. Et tu peut toujours configurer du côté serveur la durée d'une connexion sans activité.

    Étienne
  • [^] # Re: FTP

    Posté par  . En réponse au journal Deux petites chose pour vous occuper jusqu'à demain. Évalué à 7.

    FTP c'est pas Fimple Transfert Profocol ?
  • [^] # Re: Push

    Posté par  . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 5.

    Le navigateur ne fait pas à la fois client et serveur, il initie une connexion TCP vers le serveur sur laquelle on ouvre des flux bidirectionnels, le serveur comme le client peut donc envoyer des données. Par rapport au modèle du HTTP qui est du style

    - Le client envoie une requête
    - Le serveur répond
    - Le client envoie une requête
    - Le serveur répond
    - etc.


    En SPDY, le client lit sur la socket en permanence pour que le serveur puisse également être à l'initiative de certaines requête, comme dit plus haut pour éviter d'avoir à poller des changements d'état.

    Une connexion en HTTP est directement liée à la connexion TCP sous-jacente, en SPDY, la connexion HTTP se traduit plutôt par l'ouverture d'un flux sur la connexion TCP. Par exemple si j'ai en permanence 3 onglets ouverts sur https://linuxfr.org/my https://linuxfr.org/journal et https://linuxfr.org/forums il me faut 3 connexion http (voir une par fichier si je ne fait pas de keep-alive qui n'est pas obligatoire), avec SPDY, j'ouvre une connexion TCP sur laquelle j'ouvre 3 flux SPDY.

    Étienne
  • [^] # Re: Ceci n'est pas une critique...

    Posté par  . En réponse à la dépêche Sortie de LLVM 2.6. Évalué à 7.

    J'ai beau me triturer les méninges, je n'arrive pas à voir la plus-value par rapport à un autre compilateur, au hasard gcc...

    L'architecture de LLVM en fait un outil plus versatile. On peut en effet n'utiliser qu'un ensemble des briques de LLVM sans les autres de façon très aisée. A titre d'exemple il y a des projets :
    - qui se servent de LLVM pour faire de la compilation JIT (chose impossible, il me semble, avec GCC)
    - qui se servent de clang (le frontend pour le C, C++, Objective-C et Objective-C++), pour faire de l'analyse statique de code (chose qui est difficile actuellement avec gcc, qui devrait être un peu plus simple avec le mécanisme de plugin)

    Le point important est qu'on peut utiliser LLVM comme une bibliothèque en ne récupérant que les composants nécessaires, contrairement à gcc qui ne permettra que de se greffer sous forme de plugins.

    Au niveau de l'utilisateur, clang permet, selon le site (cf http://clang.llvm.org/features.html#enduser )
    - de meilleurs messages de diagnostique
    - une moins grande consommation mémoire
    - une plus grande rapidité d'analyse du code.


    Étienne
  • # Utiliser TARGET_API

    Posté par  . En réponse au message Macro avec saut de ligne. Évalué à 1.

    Je pense qu'il te suffit de garder le TARGET_API en faisant :

    #ifdef _MSC_VER
    #if defined TARGET_EXPORTS
    #define TARGET_API __declspec( dllexport )
    #else
    #define TARGET_API __declspec( dllimport )
    #endif // _LIB
    #else
    #define TARGET_API
    #endif


    Après tu n'a pas d'autre code à modifier puisque je suppose que toutes tes fonction utilisent TARGET_API.

    Étienne
  • [^] # Re: Pretty printing

    Posté par  . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 2.

    Je pense qu'on va rapidement avoir des scripts python pour afficher de façon plaisante les éléments la STL ou de Qt.

    J'aurai dû vérifier avant mais dans le trunk de gcc[1], on trouve déjà des choses pour la STL. Exemple (elem est un std::string et vect est un vecteur de std::string) :
    (gdb) print elem
    $1 = "bonjour"
    (gdb) print vect
    $2 = std::vector of length 0, capacity 0
    (gdb) next
    (gdb) print vect
    $3 = std::vector of length 1, capacity 1 = {"bonjour"}
    (gdb) next
    (gdb) print
    $4 = std::vector of length 2, capacity 2 = {"bonjour", "toto"}


    [1].http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/python/lib(...)
  • # Pretty printing

    Posté par  . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 6.

    Il n'en est pas fait mention dans le dépêche, mais avec le scripting python arrive une fonctionnalité attendue depuis longtemps : le pretty-printing [1]. Cela permet de définir comment afficher une variable suivant son type. Jusqu'ici, gdb affichait tous les membres de la classe récursivement. On peut maintenant définir une classe qui spécifie comment afficher un objet d'un type particulier. Par exemple au lieu d'afficher les objets de type std::string comme ceci (exemple tiré de la doc) :
    (gdb) print s
    $1 = {
    static npos = 4294967295,
    _M_dataplus = {
    <std::allocator> = {
    <__gnu_cxx::new_allocator> = {<No data fields>}, <No data fields>},
    members of std::basic_string<char, std::char_traits, std::allocator >::_Alloc_hider:
    _M_p = 0x804a014 "abcd"
    }
    }


    On aura :
    (gdb) print s
    $2 = "abcd"


    Je pense qu'on va rapidement avoir des scripts python pour afficher de façon plaisante les éléments la STL ou de Qt.

    [1]. http://sourceware.org/gdb/current/onlinedocs/gdb_24.html#SEC(...)
  • [^] # Re: GlusterFS ?

    Posté par  . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 1.

    2) L'information de mise-à-jour a été reçue, le fichier binaire local a été effacé, mais les mécanismes de réplication asynchrone n'ont pas encore ramené en local la nouvelle version du fichier. Dans ce cas, FineFS va récupérer le fichier auprès de son serveur d'origine, l'enregistrer en local, et le délivrer à l'application qui le demandait.

    Et que se passe-t-il si le fichier est à nouveau en train d'être modifié par le serveur d'origine au moment où l'on souhaite le récupérer ? C'est à dire un scénario comme ceci :

    - serveur1 commence à modifier le fichier
    - serveur1 a fini de modifier le fichier
    - serveur 1 envoie une notification de modification
    - serveur2 a besoin du fichier
    - serveur1 recommence à modifier le fichier
    - serveur2 récupère le fichier
    - serveur1 a fini de modifier le fichier


    Quelle version serveur2 récupère-t-il ? Et surtout est-ce qu'il récupère un fichier cohérent.

    Étienne
  • [^] # Re: Déçu

    Posté par  . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 8.

    je dois donc préciser au compilateur avec un concept que T doit avoir un opérateur '<'?
    Le compilateur n'est pas capable de le faire tout seul à la compilation ? C'est étonnant !


    Il est tout à fait capable de le fait tout seul, l'intérêt des concepts c'est de rendre les messages d'erreur plus explicites, notamment lorsque plusieurs types templates sont imbriqués.

    Par exemple avec un code comme celui-ci :

    class Key {};

    int main()
    {
        std::map<Key, int> myMap;
        myMap[Key()] = 5;
    }


    Actuellement le compilateur te sort :
    error: no match for call to '(std::map<Key,int, std::less, std::allocator<std::pair<const Key, int> > >) (Key)'

    Alors qu'avec les concepts il pourrait sortir:
    error: Type Key doesn't respect concept LessThanComparable

    Étienne
  • # Commentaire de Herb Sutter

    Posté par  . En réponse à la dépêche Retard(s) pour la prochaine version de C++. Évalué à 8.

    Herb Sutter est l'un des guru du C++, auteur de plusieurs livres de référence et il faut partie du comité ISO. Il a fait une petite analyse à la suite de la suppression des concepts : http://herbsutter.wordpress.com/2009/07/21/trip-report/

    Sous forme de questions/réponses, il explique :
    - Que la suppression des concepts s'est fait sur des décisions techniques et pas politiques
    - Que ça ne devrait pas prendre trop de temps de supprimer tout ce qui concerne les concepts du brouillon de la spec
    - Que ce n'était pas le point le plus important de C++0x
    - Que ça n'a qu'une incidence modérée sur l'expressivité du langage
    - Que les templates du C++, même sans concepts, restent très en avance en terme de généricité par rapport à ce qui est fait dans d'autres langage (il prend comme comparaison Ada, Java et .Net), il en a d'ailleurs fait personnellement l'expérience lors du développement de STL.NET
  • [^] # Re: Support de la charge?

    Posté par  . En réponse à la dépêche La billetterie informatisée libre vit ! e-venement 1.7.0 "Morrocan Tea" vient de sortir.. Évalué à 2.

    Il me semblait qu'on parlait plutôt d'un lapsus calami pour le lapsus écrit. Mais ça n'a pas un intérêt énorme.
  • [^] # Re: Générateur matériel?

    Posté par  . En réponse à la dépêche Générer des nombres aléatoires avec Hasard 0.9.6. Évalué à 3.

    Et télécharger par un réseau non fiable ta source d'entropie ?
  • # Il faut protéger les ressources partagées

    Posté par  . En réponse au message Threading : comment faire un sys.stdout sur plusieurs lignes (ou identifier chaque thread) ?. Évalué à 2.

    Lorsqu'on fait de la programmation multi-thread, il faut toujours faire bien attention à identifier et protéger les ressources partagées entre plusieurs threads.

    Dans ton cas, sys.stdout, est une ressources partagée qu'il faut protéger au moyen d'un mutex. Avec le module threading de python, c'est très simple, il te faut une variable partagée entre tous les threads et que tu lock dès que tu veux afficher quelquechose. Par exemple :

    #La variable partagée entre tous les threads
    stdoutlock = threading.Lock()
    [...]
    #lorsqu'on veut afficher :
    try:
        stdoutlock.acquire()
        sys.stdout.write("toto")
        sys.stdout.flush()
    finally:
        stdoutlock.release()


    Le plus simple étant d'encapsuler le acquire(), write(), release() dans une fonction.
  • [^] # Re: Pourquoi Mono ?

    Posté par  . En réponse au journal Utiliser Mono sans peur. Évalué à 2.

    Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).

    C'est déjà le cas via la directive export qui n'est malheureusement implémentée pas quasiment aucun compilateur.

    Sinon pour le fait de ne mettre que des déclarations dans les .h je suis assez d'accord, le problème du C++ c'est de devoir faire pas mal de compromis vis à vis de la compatibilité avec le C.


    Étienne
  • [^] # Re: Pourquoi Mono ?

    Posté par  . En réponse au journal Utiliser Mono sans peur. Évalué à 2.


    euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile

    une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...


    On sait très bien ce qu'on fait parce que la norme garantie que tout objet totalement construit voit son destructeur appelé. Donc dans l'exemple que tu donne, le destructeur des 4 Toto totalement construit seront appelés ainsi que le destructeur des membres du 5ème Toto. Le destructeur du 5ème Toto ne sera pas appelé en revanche. Le tableau ne sera de toute façon pas accessible car pas totalement construit.

    La seule chose à laquelle il faut faire attention c'est à la façon d'écrire le constructeur des classes qui véritablement font la gestion des ressources (smart pointer, classes RAII, handle de ressource, ...).


    Je serai curieux de savoir ce que Java (ou C#) apporte comme garantie supplémentaire à ce niveau là. L'impression que j'ai c'est que là où je me repose sur le finally en Java ou C#, je m'appuie sur l'appel du destructeur en C++.
    D'autre part, en C#, dans le cas de l'utilisation du using(), que se passe-t-il si une exception est levée dans le constructeur ? Et est-ce que la méthode finalize() est appelée (en C# ou en Java) lorsque le constructeur a levé une exception ?
  • [^] # Re: Ah ah ! Trop gros ça ne passera pas !

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

    Cela implique que pour communiquer entre les différents processus ainsi créés, il va falloir utiliser des appels explicites pour envoyer/recevoir des données : Socket BSD, pipe SysV, etc.


    Ce n'est pas tout à fait aussi tranché que cela. Tu peux très bien avoir 2 processus qui partagent une partie de leur espace mémoire (par exemple avec un fichier mappé en mémoire ou un segment de mémoire partagé) et on peut y placer des mutex, des sémaphores, des barrières, ... et donc l'utiliser pour communiquer comme on le ferait avec des threads.


    Étienne