Dugland Bob a écrit 640 commentaires

  • [^] # Re: threads/process

    Posté par  . En réponse à la dépêche Caudium v/s Apache. Évalué à 1.

    2 remarques :
    Sous Linux, la différence est faible (voir clone(2))
    "Les variables sont les même" : avec la portée, tu t'en sort

    le multi proc, les nouvelles (pas très fraîches) que j'en ai c'est :
    le coût de migration d'un thread sur un autre proc n'est pas toujours inférieur au fait de le garder sur place (à cause des caches, entre autres)

    le 2ème proc peut servir au noyeau ou aux autres démons.
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    en C aussi tu peux le faire :
    avec la méthode Electric fence (sous UNIX)

    tu réserve un truc plus long que nécessaire, tu le mmap(1) dans un fichier, tu vire l'accès en lecture au fichier, tu catche le signal SIGSEGV (signal(1)) et tu parcours le truc j'usqu'au signal.

    2 petits problèmes :
    BSD et Linux n'ont pas le même comportement de signal(1)
    Certains proc ne peuvent accéder qu'a des frontières de mot.

    Trop facile !
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Le cisc est un plaisir chaque jour renouvelé.
    Tous les jours je découvre une instruction !

    Pour le café, ils ont rien chez Intel ?
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    >Va peut-être falloir que tu relise ton C++.

    T'inquiète pas, je relis régulièrement !
    surtout en ce moment.
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    >mais pas du polymorphisme
    Je doit me planter de terme, je parle de 2 classes ayant une fonction portant le même nom mais une implémentation différente, ça y'a beaucoup de cas ou c'est faisable à la compilation (entre autre pour les feuilles de l'arbre d'héritage).

    J'évite de faire générer des pointeurs sur les fonctions membres dans mes champs de pixels.
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Si t'as envie de programmer comme une merde, tu peux le faire avec n'importe quel language.
    Simplement, si tu veux programmer proprement (définition libre), y'a des langages qui t'aident plus que d'autres.

    Consernant la synchro, la notion de "monitor" est TRES loin d'un mutex posix.
  • [^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Ca n'est PAS un gage de qualité.

    Pourquoi tout le monde utilise Windows ?
    Pourquoi IBM parle de Linux ?
    Pourquoi on parle de l'UMTS ?

    Parce-que c'est la mode.
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à -1.

    Quoi un troll ?
    Java ça pue, c'est indiscutable, un point c'est tout !
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    <troll>
    MMMMMmmmmmh le tueur, pour gagner un demi (peut-être même moins) cycle d'horloge tu programme tes boucles vers zéro.
    On t'a pas parlé d'architecture superscalaire où que ton proc il aurait rien foutu de toute manière (d'où le moins d'un demi) ?
    On t'as pas non plus dit que x86 est un des derniers jeu d'instruction cisc (et encore, l'architecture en dessous est de plus en plus risc)?

    Commence par travailler sur la complexité, vire tes accès mémoire (1cache miss=200 cmp), tes divisions et modulos (40cmp).

    Là tu auras du gain. mais les boucles à l'envers ... j'ai du mal !
    </troll>
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Ouais, la subtilité, c'est de virer le typage dynamique discrètement (en fait je sais pas bien le faire).

    Mais le polymorphisme est vachement pratique en C!

    Le problème du inline vient du C, je te le rappelle. Quand tu a du code dans un .h, tu le compile où ? Le même problème se pose avec les templates.

    Le problème est résolu en JAVA (un seul fichier par classe) et dans les trucs monolythiques (genre SmallTalk) où tout le code est en vrac dans le fichier.
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Ce n'est pas ce que j'ai voulu dire, avec un peu de culture, tu peux faire générer à C++ du C tel que tu l'aurais codé mais sans te prendre la tête (inline automatique, héritage, etc ...).

    Il faut voir le C++ comme une série de Macro évoluées au dessus du C.

    <ma vie>
    Personellement, j'ai du inline asm (deconnectable) au milieu de C++ (pour certains opérateur MMX) et ça marche très vite.
    </ma vie>

    Il ne faut pas oublier que le C atteint ses limites avec les architectures superscalaire et les instructions SIMD. Le gros problème : il n'a pas de remplaçant.
  • [^] # Re: Bonne nouvelle :-)

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    sur une boucle qui incrémente un compteur ?
  • [^] # Re: c'etait quoi ton probleme avec Eiffel?

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    J'écris mal.
    Je parlais d'héritage multiple, en y pensant, j'ai pensé à ce vieux bout d'article lu. Je ne veux PAS dire qu'il y a un problème avec Eiffel, je me souvenais que Eiffel avait traité le problème d'une manière ou d'une autre, sans jugement de valeur.

    Je ne veux pas tuer Eiffel (pas avant d'avoir fait connaissance du moins ... on verra après).
  • [^] # Re: Ruby, c'est bien. si c'est vrai d'abord !

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    et je sais pas écrire
  • [^] # Re: en JAVA????

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Ah ouais ?

    Ils ont quelle tête les investisseurs d'i2bp maintenant ?
  • [^] # Re: Ruby, c'est bien. si c'est vrai d'abord !

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Je suis mieux que chercheur à la fac ...
    Je suis ETUDINAT à la fac !

    j'ai encore plus de temps libre qu'eux !
  • [^] # Re: Vraiment impressionant ... (explication sur java A LIRE!)

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Nan, c'est la JVM qui fait ça !
    Natif->JVM (ou JNI, mais pas dans les classes natives)
    Sun ne donne pas les source de sa JVM
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Il me semble qu'il y a qqun qui maîtrise Eiffel ici.

    Je crois me souvenir (j'ai juste lu une intro y'a 1 ou 2 ans) que lors d'un héritage en diamant (c'est de ça qu'on parle depuis tout-à-l'heure) tu choisi pour chaque symbole l'implémentation que tu veux (classe de gauche ou classe de droite).
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Là où je suis actuellement (jusqu'à vendredi prochain) ils développent sous win2k.

    Comme je suis en recherche, je suis indépendant (donc sous linux).
    J'ai du faire une démo sous win pour un salon :
    la misère. J'ai développé sous Linux avec 3 #ifdef
    et j'ai porté au dernier moment.

    Le débugger de mémoire (Purify de Rationnal) :5000F, le profiler : pareil, pour la couverture ils ont pas ! Evidemment, ils m'ont pas filé de license temporaire (c'est la misère à désinstaller parraît-il)

    Le MsDEV ne suit pas les pointeurs sur fonction (dommage, j'utilise GLUT)

    J'ai utilisé gcc, gdb, gprof,gmake,gcov et electric fence (gdb bloque le sigsegv et rend la main). Moyenne en quoi pour 0 francs j'avais mieux qu'eux.

    C'était la première fois que je faisait une couverture, j'incite tout le mond à en faire, ontrouve des bugs insoupsonnables avec ça !
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à -1.

    Génie logiciel !

    J'ai bon ?
    Je peux faire consultant à une brique la journée maintenant?
    Bouge pas :

    start-up
    Internet
    Architecture logicielle
    B2B
    B2P
    CRM
    intranet
    extranet
    bob Ricard (oops!)
    workgrouping (en ing ça marke plus de points)


    www.kitetoa.com
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Va peut-être falloir que tu relise ton C++.

    Si tu sait l'utiliser, c'est aussi rapide que du C (vu que ton C++ est traduit en C avant compilation).

    Par contre pour l'apprentissage, c'est la misère (gérer le inline, le volatile).

    J'ai été obligé d'arrêter le trip quand je me suis noyé dans les templates (un jour j'y arriverais).
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    Tu évite de mélanger les torchons et les serviettes (conceptuellement), c'est du génie log.

    En plus tu vire la partie problématique de l'héritage multiple (j'ai un vieux souvenir de Eiffel qui me reviens en tête à ce propos).
  • [^] # Re: Et Ruby, hein ?

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    C'est lourd, je connait une dizaine de langages (heum des fois j'oublie un peu) mais j'ai jammais trouvé le bon.

    Je vais m'intéresser à eiffel, ruby et python bientôt, le problème c'est qu'on passe sa vie à apprendre des languages (et souvent les bibliothèque qui vont avec) mais : on fout rien de sa vie, on repasse au C au moindre problème, aucun n'est satisfaisant.

    Récement, j'ai repris un truc en Smalltalk, c'est sympa (y'a rien comme syntaxe, super objet, packages), un peu déroutant au début (expression exécutées de gauche à droite, 3 niveaux de priorité) mais c'est super lent, et c'est limite monolythique (ça c'est une impression).
  • [^] # Re: Quel avenir pour JAVA

    Posté par  . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 1.

    En dehors de la portabilité (très discutable de plus) JAVA apporte une maintenabilité impressionnante face au C++, ceux qui connaissent le nom "génie logiciel" savent de quoi je parle.

    1 fichier par classe
    la notion (explicite) de package
    pas de pointeur (ça ne résout pas tout, mais ça aide)
    la notion d'INTERFACE
    la notion de SYNCHRONISATION (implémentez un monitor en C++, vous m'en direz des nouvelles)


    Y'en a d'autres mais ça fait longtemps ...
    Actuellement je suis au C (plus ou moins ++)... pour la vitesse (traitement de l'image en temps réel).
  • [^] # Re: www.telecom.gouv.fr

    Posté par  . En réponse à la dépêche Réaction au rapport Carcenac : oui, MAIS. Évalué à 1.

    Sincèrement ?
    heuu non, je peux pas imprimer (avec une OKI 7200, achetez pas OKI, ça marche pas sous Linux, ça imprime même pas en TCP/IP, que en NetMachin).

    Et rebooter sous Win2K ça prend au moins 15min (en comptant le login).