Amine Mokhtari a écrit 28 commentaires

  • # y'a ti'il un produit équivalent pour le C/C++ ?

    Posté par  . En réponse à la dépêche Sortie de la version 1.12 de Sonar. Évalué à 2.

    Intéressant :-D.

    y'a ti'il un produit équivalent pour le C/C++ ?
  • [^] # Une approche très prometteuse

    Posté par  . En réponse au journal Javascript côté serveur, intéressant ou pas ?. Évalué à 2.

    Avant de me lancer, je tiens à te remercier Frédéric pour ce journal très instructif.


    Pour le reste, l'approche utilisée par Opera Mini, me semble très prometteuse. Elle permet d'éviter beaucoup de problèmes (de sécurité notamment) dès le départ. Sans compter les autres avantages qu'elle véhicule et que tu as cité.

    indéniablement, cela donne un avantage incontestable au JS par rapport aux autres langages PHP et compagnies.

    Cela simplifiera énormément les usines à gaze qui servent actuellement d'application Web+ serveur Web. En terme d'architecture cela se simplifiera grandement.
  • [^] # Re: Troll spotted

    Posté par  . En réponse au journal Le labo commun Inria-Microsoft. Évalué à 1.

    Je suis d’accord avec toi Ontologia, même si pour l'instant l'INRIA donne l'impression d'être transversale à ce que tu décris. Mais ce qui est amusant c'est que tu as oublié l'université.

    Tu la mettrais dans quelles couches, toi ? :-D
  • # writer2latex: un seul reproche, regarde du coté de XSLT

    Posté par  . En réponse au journal De "OpenDocument Text" vers "X/HTML" dynamiquement.... Évalué à 1.

    Je ne reproche à writer2latex qu'une seule chose : le fait qu'il ne sépare pas ce qui concerne la mise en page et le contenu. Pour l'instant (à ma connaissance), il génère un seul fichier dans lequel il met tout, et des fois c'est un peu n'importe quoi dedans. Mais bon tu peu tjrs lui demander de le convertir sans prendre en compte la forme, mais je ne pense pas que cela soit ce que tu veux faire.

    Independement de cela, odt et xhtml sont tous deux des langages de balisages basés sur XML, il est donc possible d'utiliser directement XSL (ou XSLT directement) sans passer par un langage tel que PHP ou autres. Essaye de creuser de ce côté là aussi.

    Références :
    XSLT : http://fr.wikipedia.org/wiki/Extended_stylesheet_language_tr(...)
  • [^] # Re: Le code, le code...

    Posté par  . En réponse au journal Quelle est la valeur d'une distribution Linux ?. Évalué à 2.

    Totalement d'accord avec toi. Le code n'est que le dernier maillon de la chaine. Le vrai boulot se fait en amont : sur les listes de discussions.
  • [^] # Re: Pas mal de choses

    Posté par  . En réponse au journal OpenOffice 3.0 : lacunes & améliorations possibles. Évalué à 1.

    Tout à fait d'accord avec toi. Synphony répond en partie à ta vision. IBM a repris beaucoup de composants à openOffice, mais réassemblés de manière plus intelligente. Ils ont rebâti le bazar sur le socle d'eclipse (RCP). Je pense qu'ils ont repris ces derniers, afin de gagner du temps en occupant un peu le terrain le temps de développer les composants qui leur manquaient. La preuve en est qu'ils n'ont pas repris l'éditeur d'équation d'openOffice.
  • [^] # Re: Les gouts et les couleurs

    Posté par  . En réponse au journal OpenOffice 3.0 : lacunes & améliorations possibles. Évalué à 2.

    Ce n'est pas une solution intégrée (color scheme 2 : http://www.wellstyled.com/tools/colorscheme2/index-en.html#)(...) J'utilise ce petit utilitaire quand je veux faire un graphique tape à l'oeil. Apparement les inforgraphiste utilise de tel logiciels (Algorithme) pour avoir une palette de couleur bien homogène (et moi qui croyais qu'il avait très bon goût :-p).
  • [^] # Re: j'hésitais pour le journal

    Posté par  . En réponse au message OpenOffice 3.0 : lacunes & améliorations possibles. Évalué à 0.

    Tiens je vais en faire un journal tout de suite. :-p
  • # j'hésitais pour le journal

    Posté par  . En réponse au message OpenOffice 3.0 : lacunes & améliorations possibles. Évalué à 0.

    Je ne pensais pas que mon poste avait suffisement de consitance pour être publié dans le journal. En toute sincérité, j'hésitais à le poster dans le journal, je me suis dis, que cela ne valais pas le coup et que je ne ferai que bruité ce dernier.

    La prochaine fois, promis. quand je critiquerai un logiciel sa sera dans le journal.
  • [^] # Re: Trap

    Posté par  . En réponse au message [bash] block transactionnel (atomique). Évalué à 1.

    JE pense que sa devrai faire l'affaire.

    merci.
  • [^] # Re: mauvaise démarche.

    Posté par  . En réponse au message autotools project to Cmake project. Évalué à 1.

    Merci pour ta réponse Barnabé.

    Ton titre (mauvaise méthode) affiche déjà la couleur :-). Le problème est que le make est dispatché en une centaine de make (1 par répertoire) et comme il y' a bcp d'inclusion j'ai essayé de lire afin de comprendre un peu, mais je me suis très vite mêlé les pinceaux. De plus, le fichier configure est le top de la complexité pour moi. Rien que le script configure est un programme à lui tout seul digne de ce nom.

    Apparemment tu as l'air de quelqu'un qui sait de quoi il parle. Je vais donc m'efforcer de suivre la voie que tu me recommandes.
  • [^] # Re : Pas convaincu

    Posté par  . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à -1.

    voilà leur réponse (http://code.google.com/apis/protocolbuffers/docs/overview.ht(...)
    ---------------------------------------------------------------------------------------------------------------
    Why not just use XML?

    Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

    * are simpler
    * are 3 to 10 times smaller
    * are 20 to 100 times faster
    * are less ambiguous
    * generate data access classes that are easier to use programmatically
    -----------------------------------------------------------------------------------------------------------

    Apparemment c'est juste un problème de performance. Avec leurs formats ça va plus vite. Forcement si c'est un binaire (plus besoin d'interpréteur).

    Je n'y crois pas tellement. S’ils veulent des échanges rapides en XML, ils n'ont qu'à optimiser une librairie existante ; non!!!!!!
  • [^] # Re: Pas de titre cette fois

    Posté par  . En réponse au message FETCH : comment sa marche ?!!!. Évalué à 1.

    y'a t'il un moyen de fair en sorte que le curseur laisse les données en mémoire et à chaque exécution de la commande Fetch qu'il ne fasse que les lires ?
  • [^] # Re: Pas de titre cette fois

    Posté par  . En réponse au message FETCH : comment sa marche ?!!!. Évalué à 1.

    Je me suis amusé entre temps à mesurer le temps d'exécution d'une requête Q1 avec et sans indexe sur au moins un critère de la close WHERE de Q1.

    Je pensais qu'en mettant un indexe sur un des critères de Q1 j'améliorerai le temps d'exécution de la commande FETCH, mais ils n'ont n"ai rien. Il apparait que seul un scan séquentiel est admis. Aucune optimisation par la prise en compte des indexes n'est autorisée!!!!!!

    Je suis vraiment curieux de savoir comment un Curseur ainsi que FETCH marchent (le principe de base au moins).
  • # curieux d'entendre tes remarques

    Posté par  . En réponse à la dépêche Sortie de Eclipse 3.4 - Ganymede. Évalué à 3.

    Je suis aussi curieux d'entendre des remarque sur son interface.

    certes il donne l'impression d'être relativement chargé niveau interface ce qu ipeut être assimilé à du bruit visuel (je ne suis pas expert en IHM :-D), mais cela est très facilement configurable. !!!!

    mais d'un point de vue pratique je trouve qu'il est très bien fait.
  • [^] # Re: clock_gettime

    Posté par  . En réponse au message Mesurer le temps d'exécution d'un fragment de code. Évalué à 1.

    La fonction clock_gettime() m'a l'air très intéressante (comment j'ai pu passer à côté).

    corriger moi si je me trompe :

    CLOCK_PROCESS_CPUTIME_ID définie une horloge propre à mon processus qui prend en compte que le temps où mon processus est actif et ne prend pas en compte le temps où l'ordonnanceur le met en attente afin de faire tourner d'autres processus.

    Par contre, CLOCK_REALTIME s'appuie sur l'horloge physique globale et donc comptabilise tout ce qui se passe entre deux appels à clock_gettime.

    C’est ça ?
  • [^] # Re: Posix time API ?

    Posté par  . En réponse au message Mesurer le temps d'exécution d'un fragment de code. Évalué à 1.

    Ce n'est pas une optimisation de mon application que je fais. mais uniquement des mesures expérimentales.

    voilà les temps d'exécution que me renvoi times().

    0,09
    0,08
    0,1
    0,1
    0,09
    0,07
    0,09
    0,09
    0,11
    0,1
    0,1
    0,08
    0,09
    0,09
    0,1
    0,1
    0,08
    0,12
    0,09

    des différences allant jusqu'à 5ms !!! de me meilleure cas . ce qui n'est pas acceptable pour moi (voir mon poste précedent).
  • # Une solution à l'ancienne (en assembleur)

    Posté par  . En réponse au message Mesurer le temps d'exécution d'un fragment de code. Évalué à 1.

    D'abord merci pour vos réponses rapides.

    Pour réponde à ta question Kerro, j'ai en fait besoin de faire quelques mesures expérimentales pour des recherches scientifiques dans le domaine des bases de données.

    Le principe de cette expérience et de mesurer le temps d'exécution d'une requête (floue) avec et sans index sur certain champs d'une table.

    En utilisant times et getrusage je me retrouve avec des résultats qui me disent qu'une requête sur une base de données sans index sur les champs intérogés est relativement (de quelque milliseconde) meilleure qu'une base de données (la même) sans index. Ce qui est aberrant. L’intérêt des index est bien d'accélérer le temps d'exécution et non le ralenti.

    Je ne demande pas le temps d'exécution exacte (à la nanoseconde près), mais des temps qui ne défient pas le bon sens.

    getrusage me semble intéressante, mais ne renvoie que le temps d'exécution que du programme au complet et non d'un fragment comme j'ai besoin.

    comme il l'a si bien résumé le document que Damien nous a déniché (page 5)

    Temps d'exécution d'un programme = temps d'exec des appels système + temps d'exec des appels utilisateurs + autres.

    Sachant que autres représente le temps où d'autres processus sont exécuter autres que celui qui nous intéresse. J’ai bien essayé getrusage avant est après le bout de code qui m'intéresse dans l'espoir en faisant la soustraction d'avoir ce que je voulais, mais sa ne marchais pas. Il me donne les mêmes valeurs comme si le bout de code que j'avais entre les deux ne consommait rien du tout. Ce qui n'est pas le cas.

    Je suis tombé il y'a de sa quelque instant sur un article de chez ces messieurs de Intel(http://softwarecommunity.intel.com/articles/eng/2589.htm). Je pense qu'il apporte beaucoup d'explications sur des zones d'ombres. D'après ces messieurs de chez Intel, une mesure du temps d'exécution basée sur l'horloge système possède une précision de l'ordre de +/-10 ms~ dans la meilleure des cas. « The system timer can be used to measure events with an accuracy of 10 ms. » ; la fonction time() sous C possède une précision de l'ordre de -/+1 s ; les fonctions en rapport avec le temps qui existe dans les bibliothèques pour le traitement multimédia (ils parlent de la fonction timeGetTime qui existe sous Windows Plus exactement) de l'ordre de +-/10 ms.

    En s'appuyant sur les cycles du processeur grâce à l'instruction Read Time Stamp Counter (RDTSC) pour les processeurs Intel (je pense qu'il existe aussi qlq chose de similaires sous les processeurs AMD) on peut atteindre une précision de 0.33 nanoseconde pour un processeur de 3 GHz. ce qui me convient parfaitement :-p.

    Je vais donc me pencher sur la solution proposée par Damien (que je remercie). Pas de bolle je suis sur une machine possédant un processeur centrions double coeur (SMP). Pas le choix on fera avec.

    Je pense qu'il est possible de désactiver le SpeedStep Technology et Enhanced Intel® SpeedStep Technology sous le Biois. Enfin, je l'espère.
  • [^] # Re: GSL est vraiment pas mal

    Posté par  . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 1.

    la lenteur de /dev/urandom n'est pas la seule raison (mais la première). la portabilité aussi. même si un équivalent existe sous la plupart des systèmes. la plupart nécessite une implémentation spécifique.

    enfin bon. on peut en débattre encore et encore.
  • # GSL est vraiment pas mal

    Posté par  . En réponse au journal Sortie de la bibliothèque Hasard version 0.2. Évalué à 3.

    Slt,

    Par expérience je me demande si tu as conscience Victor à ce que tu t'attaques. Non pas pour te démoraliser ou autres choses, mais j'ai l'impression que tu as une vision simpliste sur laquelle tu t'attaques.

    Récemment je me suis posé la même question que toi. J’avais besoin de faire quelques simulations pour valider quelques travaux de recherches (dans le domaine des bases de données). J’avais besoin d'un volume important de données non corrélé (sinon très très peu).

    Il est vrai que pour qlq'un qui recherche un générateur de nombre aléatoire, le premier réflexe est d'utiliser Rand() qu'on a par défaut sous c (et C++) dans différentes bibliothèques (glibc entre autres). Mais des qu'on cherche qlq chose de plus sophistiquée on n'a pas systématiquement le reflète de ce dire qu'il y' a forcement une bibliothèque pour cela. Je me disais avec une naïfté qui n'a pour égale que mon... ; que c'était qlq chose de ne pas si compliqué que sa. Mais rapidement j'ai déchanté. Car un bon générateur, bien implémenté doit vérifier certaines propriétés mathématiques (non corrélation, périodicité grande, etc.). Les labiraintes théoriques ont eu raison de ma volonté. Surtout au niveau de la validation d'une implémentation.

    Puis je suis tombé sur GSL. Et je dois dire qu'elle est très bien foutue (conception très factorisée en autres).

    Donc, je n'aurais qu'une chose à dire à Victor. Ta démarche est louable, mais tu as le choix entre une contribution intégré à GSL qui sera directement utile à une communauté déjà établie. Ou la grande traversée nécessitant environ une décennie pour avoir une bibliothèque mature et reconnue.
  • [^] # Re: Limites de la finesse de gravure

    Posté par  . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 3.

    Je suis d'accord avec les propos de Mathieu.

    et pour cause, des travaux de recherche sont menés afin de réaliser des nano-transistors à la chaine (On sait les faires en petite contité mais il ya des problème lors du passage à l'echelle. on ne controle pas totalement le processus).

    Voilà un liens qui en dit plus: Les nanotransistors, être ou ne pas être en CMOS sur silicium ? (http://www.cea.fr/var/plain/storage/original/application/223(...)

    mais sa avance, y'a qu'à voir les progrès faits ces derniers temps :IBM fait un nouveau pas vers la production de nanotransistors (http://www.vnunet.fr/fr/news/2008/03/11/ibm_fait_un_nouveau_(...)
  • # Une bataille de perdu mais une expérience de gagnée

    Posté par  . En réponse au journal Le projet OLPC va virer Linux pour ne tourner que sous Windows.. Évalué à 4.

    Il est bien connu que l'histoire ne retient que les gagnants et c'est dommage pour le monde du libre. Mais tout espoir n'est pas perdu. C’est une expérience de gagner pour le monde du libre.

    La démarche OLPC est noble, mais à mon humble avis, toute démarche de ce type converge vers un échec si elle est minée comme OLPC l'est par des intérêts commerciaux. Le lobbying à fait son taf. c'est une tumeur maligne qui ne laisse guerre d'espoir. « Accepte le lobby ou meurs ».

    Le libre est un état d'esprit qui transcende les démarches commerciales.

    J’ai l'impression que certains dirigeants de cette organisation n'ont rien compris du libre. Pour eux ce n'est qu'un composant à bas coût. Pour les connaisseurs c'est une philosophie. Un art de vivre.

    Après l'invention du zéro, le monde du libre est indéniablement ce que l'homme a créé de meilleur.
  • [^] # Re: Peut être une explication

    Posté par  . En réponse au journal Fedora@home. Évalué à 1.

    Ton argumentation tient la route (Zut, j'aime pas admettre mes tors :-)).

    Alors, à quoi pourrait servir se cluster made in Fedora ?
    En faite, l'explication était fourni dans le lien (http://www.redhat.com/archives/fedora-advisory-board/2008-Ma(...)
    "... I'd like to create a Fedora Home project where Fedora hosts a MRG grid scheduler, people can donate CPU time on their computers for computations, and we schedule meaningful or useful work to these people's computers... It would also be a great marketing showcase for Fedora by showing our leadership in grid technology and in the power of our community. ... Red Hat and the University of Wisconsin recently signed a partnership
    that makes available the Condor source code under an OSI-approved open
    source license (mostly ASL). We have packaged Condor, submitted it to
    the F9 development branch, and are maintaining it there. The University
    of Wisconsin's Condor project remains our upstream code base and
    community. So, from a technology perspective, we should be able to
    build Fedora Home using technologies that will all be in Fedora.". En somme, l'université du Wisconsin en partenariat avec RedHat cherche à développer une communauté autour de ces outils.

    Néanmoins je pense que la délégation de calcul dans un environnement hostile, comme tu dis, est quelque chose qui viendra. sûrement pas tout de suite (bcp de problèmes à résoudre encore), mais ...

    j'aimerai bien avoir ton avis sur ce point. :-p
  • [^] # Re: Peut être une explication

    Posté par  . En réponse au journal Fedora@home. Évalué à 0.

    Il n'ya pas que les grosses boites qui ont besoin de faire des simulations. et puis elles n'ont pas que des données sensibles (même si en grande partie c'est le cas pour des entreprise comme EADS). Tu as pris les cas les plus sensibles. et sur ce type d'entreprise je suis d'accord avec toi.

    Néanmoins, pour le calcul des prévisions météo par exemple. ce n'est pas un secret de polichinelle à première abord, c'est un calcul utiles pour une entreprise tel que Air france ou la NASA. donc si le portage totale ou de manière partielle sur d'autres machine externe peut leurs faire gagner en précision/prévision, je ne pense pas qu'elles cracheront dessus.

    Prend l'exemple de la Grid community (http://www.worldcommunitygrid.org/) c'est bien un super ordinateur qui a été formé par un ensemble de PC connecté au Web. La World Community Grid met sa technologie (fournis par IBM principalement) à disposition des seules organisations publiques ou à but non lucratif pour qu'elles l'utilisent dans des recherches humanitaires qui, autrement, risqueraient de ne pas aboutir en raison du coût élevé de l'infrastructure informatique nécessaire en l'absence d'infrastructure publique.

    porter des simulation ou analyser de données non sensible sur une grid/Cluster ouvert(e), est toujours bon à prendre à mon avis.

    l'avenir est dans les calculs/traitement distribués. qu'on le veuille ou pas. y'a qu'à voir du coté des laboratoires de recherches. les réseaux totalement ad hoc pour le calcul et la transmission des données ont la cote. On investit dans ce type de R&D de manière massive, sur tout les plans: sécurité, optimisation des réseaux, fiabilité, robustesse, coût, etc.
  • [^] # Re: Peut être une explication

    Posté par  . En réponse au journal Fedora@home. Évalué à 1.

    Il est clair, que pour données/calcul sensibles, cela n'est pas très intéressant. mais pour des simulation/des calcul scientifiques, cela ne pose pas de réel problème de sécurité.