/* Topic des codeurs [8] */

grim7reaper · Le 08/04/2013, à 15:50

Epehj a écrit :

Est ce qu'il y a un intérêt à faire ça plutôt que if(!bLoadOk) ?

D’un point de vue technique, les deux sont équivalents.

Epehj · Le 08/04/2013, à 16:06

Ok, merci pour vos réponses !

Elzen · Le 08/04/2013, à 16:55

À vue de nez, je dirais que ça doit être un type habitué à utiliser un langage pour lequel on peut tester autre chose qu'un booléen, avec des résultats différents de faux, mais qui pourtant sont considérés comme faux lors d'un test.

Par exemple, en Python :

~~~> if (None):
 ~~>    print 1
 ~~> else:
 ~~>    print 2
 ~~> 
2
~~~> not None
True
~~~> None == False
False
~~~>

Ce qui pourrait justifier du même coup le fait de mettre « if (false) else » plutôt que « if (true) else », qui me paraîtrait, à moi aussi, beaucoup plus lisible dans le cas classique. Mais comme je ne crois pas que ce genre de cas soit possible en C++, je dirais que ça manque un peu d'élégance d'avoir écrit ça comme ça.

Epehj · Le 09/04/2013, à 09:31

Pour être franc, c'est un dev en poste depuis un certain nombre d'années (>10) dans la même boite, et qui ne s'est jamais mis à jour depuis sa sortie d'école. Il ne fait que du C++…
Il y a beaucoup de chose comme ça, et comme je ne maitrise pas C++, je me demandais s'il y avait une feinte connue des initiés uniquement.

Merci pour vos éclaircissements.

Rolinh · Le 09/04/2013, à 10:29

On en croise tous un jour ou l'autre des développeurs comme ça.
Et souvent, ce sont les mêmes qui réinventent la roue (et bien souvent carrée...) en faisant leur soupe au lieu d'utiliser des libs existantes, connues et éprouvées.
De plus, cela engendre souvent des bugs et autres pertes de temps nuisibles à tout projet.

grim7reaper · Le 10/04/2013, à 13:02

Allez, un petit bout de code : implémentation de la fonction de hachage de Fowler–Noll–Vo (c’est une petite partie de ce qui va sûrement devenir mon prochain projet en Ruby), pour chaque taille supportée.
Utilisation de métaprog’ pour éviter la répétition de code

module FastHash

  FNV_32_INIT   = 2166136261
  FNV_64_INIT   = 14695981039346656037
  FNV_128_INIT  = 144066263297769815596495629667062367629
  FNV_256_INIT  = 100029257958052580907070968620625704837092796014241193945225284501741471925557
  FNV_512_INIT  = 9659303129496669498009435400716310466090418745672637896108374329434462657994582932197716438449813051892206539805784495328239340083876191928701583869517785
  FNV_1024_INIT = 14197795064947621068722070641403218320880622795441933960878474914617582723252296732303717722150864096521202355549365628174669108571814760471015076148029755969804077320157692458563003215304957150157403644460363550505412711285966361610267868082893823963790439336411086884584107735010676915

  FNV_32_PRIME   = 16777619
  FNV_64_PRIME   = 1099511628211
  FNV_128_PRIME  = 309485009821345068724781371
  FNV_256_PRIME  = 374144419156711147060143317175368453031918731002211
  FNV_512_PRIME  = 35835915874844867368919076489095108449946327955754392558399825615420669938882575126094039892345713852759
  FNV_1024_PRIME = 5016456510113118655434598811035278955030765345404790744303017523831112055108147451509157692220295382716162651878526895249385292291816524375083746691371804094271873160484737966720260389217684476157468082573

  MASK_32   = 0xFFFFFFFF
  MASK_64   = 0xFFFFFFFFFFFFFFFF
  MASK_128  = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  MASK_256  = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  MASK_512  = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  MASK_1024 = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

  # Generates the different flavours (32, 64, 128, 256, 512 and 1024 bits) of
  # the FNV hashing algorithm.
  [32, 64, 128, 256, 512, 1024].each do |bit|
    # FNV1.
    define_singleton_method "fnv1_#{bit}".to_s do |key|
      hash = const_get("FNV_#{bit}_INIT")
      key.unpack('C'*key.length).each do |byte|
        hash *= const_get("FNV_#{bit}_PRIME")
        hash ^= byte
      end
      hash & const_get("MASK_#{bit}")
    end
    # FNV1a.
    define_singleton_method "fnv1a_#{bit}".to_s do |key|
      hash = const_get("FNV_#{bit}_INIT")
      key.unpack('C'*key.length).each do |byte|
        hash ^= byte
        hash *= const_get("FNV_#{bit}_PRIME")
      end
      hash & const_get("MASK_#{bit}")
    end
  end
end

Vive Ruby

Édit : petit exemple de sortie

[1] pry(main)> require 'fnv'
=> true
[2] pry(main)> FastHash.fnv1_32("Hello World!").to_s(16)
=> "12a9a41c"
[3] pry(main)> FastHash.fnv1a_32("Hello World!").to_s(16)
=> "b1ea4872"
[4] pry(main)> FastHash.fnv1_64("Hello World!").to_s(16)
=> "8e59dd02f68c387c"
[5] pry(main)> FastHash.fnv1a_64("Hello World!").to_s(16)
=> "8c0ec8d1fb9e6e32"

Dernière modification par grim7reaper (Le 10/04/2013, à 15:30)

The Uploader · Le 10/04/2013, à 13:35

Très intéressant. (je poste vite, je dois y aller ^^)

grim' a écrit :

Vive Ruby

Rolinh · Le 10/04/2013, à 18:14

Intéressant. Tu as généré comment tes primes seeds ? En ruby aussi?

Ça me fait penser que j'avais prévu de faire un article de blog sur le fonctionnement de RSA avec implémentation en Ruby.
J'ai le code qui traîne quelque part dans mon disque dur depuis 6 mois mais je me rappelle que quand je l'avais implémenté, je m'étais aussi dit "Vive Ruby" .

J'étais tombé sur un article de blog super intéressant dont je m'étais d'ailleurs bien inspiré pour mon implémentation. J'avais trouvé l'idée pour la génération de grand nombres aléatoires juste géniale:

    # Generates a random big number of size +b+ where +b+ represents the number
    # of bits of the number. Note that the generated number is always odd.
    def gen_random_bignum(b)
        m = (1..b-3).map{ rand() > 0.5 ? '1' : '0' }.join
        str = "11" + m + "1"
        str.to_i(2)
    end

Ce qui donne un joli nombre aléatoire de b bits. Après, je fais une vingtaine de passe sur mon implémentation du test de primalité de Miller-Rabin ce qui donne une relativement bonne probabilité que le nombre soit premier.

    # Generates randomly a very large prime number of size +b+ where +b+
    # represents the number of bits of the number (1024 for instance)
    def gen_random_prime(b)
        while true
            v = gen_random_bignum(b)
            # I assume 20 loops is enough to verify primality
            # using higher number would increase accuracy but take a lot
            # more time to compute
            return v if primality_test?(v, 20)
        end
    end

Et le Miller-Rabin:

    # Test if +n+ is prime using Miller-Rabin primality test.
    # +k+ is a number determining confidence. The higher value it has, the
    # higher the accuracy is. Typical reasonnable value would be between 10 and
    # 30.
    def primality_test?(n,k)
        return true if n == 2
        return false if n < 2 or n % 2 == 0
        d = n - 1
        s = 0
        while d % 2 == 0
            d /= 2
            s += 1
        end
        k.times do
            a = 2 + rand(n - 4)
            x = fast_exponent(a, d, n)
            next if x == 1 or x == n - 1
            for r in (1 .. s - 1)
                #x = (x**2) % n
                x = fast_exponent(x, 2, n)
                return false if x == 1
                break if x == n - 1
            end
            return false if x != n - 1
        end
        return true
    end

Bref, Ruby m'avait carrément surpris par ses performances. Je peux filer le code complet si ça intéresse quelqu'un mais dans mes souvenirs il y avait 2-3 trucs que je voulais changer ou qui n'étaient pas top.

grim7reaper · Le 10/04/2013, à 18:55

Rolinh a écrit :

Intéressant. Tu as généré comment tes primes seeds ? En ruby aussi?

Nope, ils sont définis pas les auteurs.
Ce sont des nombres premiers un peu particulier.

Rolinh a écrit :

Je peux filer le code complet si ça intéresse quelqu'un mais dans mes souvenirs il y avait 2-3 trucs que je voulais changer ou qui n'étaient pas top.

Je vais attendre que tu fasses ton article

Dernière modification par grim7reaper (Le 10/04/2013, à 18:57)

The Uploader · Le 10/04/2013, à 18:59

Je viens de (re)voir le code de grim' : J'ai rarement fait de la métaprog' à ce point. Je savais que Ruby pouvait le faire, mais je ne l'ai jamais exploité à ce point. Très joli/élégant.

Dernière modification par The Uploader (Le 10/04/2013, à 19:00)

Rolinh · Le 10/04/2013, à 19:45

@grim: Ok. Vu comme ça dans le code je me demandais d'où ils sortaient et surtout pourquoi ceux-ci. Enfin bon, on est pas dans du hashage cryptographique donc j'imagine que l'intérêt de ces nombres c'est purement de chercher les perfs.
Bon, je vais me motiver à la rédaction de l'article de blog du coup mais ça va sûrement me prendre pas mal de temps. Au moins j'ai une bonne motivation à l'écrire: ça intéresse au moins une personne.

@The Uploader: Ouep, c'est super élégant. En même temps, grim c'est l'élégance même niveau code en général.

grim7reaper · Le 11/04/2013, à 05:30

Rolinh a écrit :

j'imagine que l'intérêt de ces nombres c'est purement de chercher les perfs.

Ça pourrait être le cas, mais là non :

http://www.isthe.com/chongo/tech/comp/fnv/#fnv-prime a écrit :

It is a nice side effect that FNV_prime may be optimized by some compilers for some hardware. On some hardware, replacing the FNV_prime multiply with a set of shifts and adds will improve performance. In other cases where multiply may be pipelined (such as in vector mode), the set of shifts and adds may be sub-optimal. The FNV_prime were not selected for compiler optimization, they were selected for the quality of resulting hash function.

Ici c’est l’algo qui est simple pour être rapide, mais les nombres sont choisis pour favoriser la distribution.

Rolinh a écrit :

Bon, je vais me motiver à la rédaction de l'article de blog du coup mais ça va sûrement me prendre pas mal de temps. Au moins j'ai une bonne motivation à l'écrire: ça intéresse au moins une personne.

C’était le but

The Uploader a écrit :

Je viens de (re)voir le code de grim' : J'ai rarement fait de la métaprog' à ce point. Je savais que Ruby pouvait le faire, mais je ne l'ai jamais exploité à ce point. Très joli/élégant.

Rolinh a écrit :

@The Uploader: Ouep, c'est super élégant. En même temps, grim c'est l'élégance même niveau code en général.

Houlà, c’est trop d’honneur.
Je ne fais que débuter en Ruby, et encore plus en métaprog’ avec Ruby.
Au début j’avais commencé à la coder à la main, et puis j’ai trouvé ça super redondant donc j’ai cherché un moyen de les générer.
Sachant qu’en Ruby la métapgrog’ est simple, je me suis dit que c’était là une bonne occasion de l’utiliser. Du coup j’ai fait quelques recherche pour savoir comment faire, puis j’ai pondu ça en 5-10 min.

Pylades · Le 11/04/2013, à 05:56

Savoir apprendre rapidement est une des principales qualités du programmeur, non ?

grim7reaper · Le 11/04/2013, à 06:43

Oui, en théorie (après, en pratique, tu croises des gens qui vont rester coller à leur langage favori même s’il n’est pas du tout adapté à la tâche).
Et puis, oui, apprendre un langage c’est assez rapide.
Bien apprendre un langage peut demander un peu plus de temps. Et ça, tout le monde ne le fait pas (résultat des gens pondent du Python comme du Java donc c’est illisible, ils font du Haskell avec une approche impérative, …).
Par bien apprendre, j’entends assimiler la culture du langages : ses idiomes, ses spécificités, qu’est ce qui est élégant et qu’est ce qui ne l’est pas, …
Ça, ça demande un peu plus d’effort mais ça apporte bien plus.

The Uploader · Le 11/04/2013, à 09:07

Πυλάδης a écrit :

Savoir apprendre rapidement est une des principales qualités du programmeur, non ?

Yép, c'est juste que dans RoR tu utilises rarement les trucs du genre Object#define_singleton_method ^^
Après dans mes projets persos en Ruby j'ai pas utilisé la métaprog jusqu'à utiliser ce genre de méthodes non plus.
Bref le use case ne s'est jamais présenté.

edit :

grim' sur le topic des Commandes les plus fréquentes a écrit :

Oui je suis repassé à Vim ^^

Pourquoi ?
(en ce moment j'alterne entre Geany et Sulbime Text que j'essaie. Marre de Vim. )

Dernière modification par The Uploader (Le 11/04/2013, à 09:14)

grim7reaper · Le 11/04/2013, à 09:47

The Uploader a écrit :

grim' sur le topic des Commandes les plus fréquentes a écrit :
Oui je suis repassé à Vim ^^

Pourquoi ?

Parce que Vim à un super plugin pour Git, et un plugin pour R qui mets pas trois plombes à se lancer (et qu‘en plus le plugin ESS d’Emacs ne supportent pas l’autoload, donc tu te bouffes 1s de latence à chaque fois tu ouvres un malheureux fichier…).

The Uploader a écrit :

(en ce moment j'alterne entre Geany et Sulbime Text que j'essaie. Marre de Vim. )

SublimeText, 70€… Mouais, ça sera sans moi…
Je reconnais qu‘il semble bien fichu, mais de là à coûter ce prix , si encore il pouvait faire OS comme Emacs

Dernière modification par grim7reaper (Le 11/04/2013, à 09:48)

The Uploader · Le 11/04/2013, à 09:58

Il y a une version gratuite. Même fonctionnalités. C'est du guiltware (si tu l'achète pas et que tu l'utilise beaucoup tu as un reminder de temps en temps) à ce qu'on m'a dit.

edit (sans rapport) : http://www.youtube.com/watch?v=cyHTAGoEuL8

Dernière modification par The Uploader (Le 11/04/2013, à 10:02)

Dr Le Rouge · Le 11/04/2013, à 10:05

@ grim' : traître

Tu lançais un serveur emacs puis ouvrait des clients ?

grim7reaper · Le 11/04/2013, à 10:12

The Uploader a écrit :

Il y a une version gratuite. Même fonctionnalités. C'est du guiltware (si tu l'achète pas et que tu l'utilise beaucoup tu as un reminder de temps en temps) à ce qu'on m'a dit.

Ha, en effet il n’y a pas de limite de temps.

Le Rouge a écrit :

@ grim' : traître

Bah à la base j’étais sur Vim, puis je suis passé sur Emacs (tout en utilisant un peu Vim pour 2-3 trucs), et là je repasse sous Vim (mais je vais sûrement garder Emacs pour 2-3 trucs ^^)

Le Rouge a écrit :

Tu lançais un serveur emacs puis ouvrait des clients ?

Je le faisais à un moment, puis j‘ai eu des soucis avec ce mode de fonctionnement donc j’étais revenu à une utilisation standard.

Rolinh · Le 11/04/2013, à 20:00

grim7reaper a écrit :

Oui, en théorie (après, en pratique, tu croises des gens qui vont rester coller à leur langage favori même s’il n’est pas du tout adapté à la tâche).
Et puis, oui, apprendre un langage c’est assez rapide.
Bien apprendre un langage peut demander un peu plus de temps. Et ça, tout le monde ne le fait pas (résultat des gens pondent du Python comme du Java donc c’est illisible, ils font du Haskell avec une approche impérative, …).
Par bien apprendre, j’entends assimiler la culture du langages : ses idiomes, ses spécificités, qu’est ce qui est élégant et qu’est ce qui ne l’est pas, …
Ça, ça demande un peu plus d’effort mais ça apporte bien plus.

Complètement d'accord avec ça.

grim7reaper a écrit :

Parce que Vim à un super plugin pour Git, et un plugin pour R qui mets pas trois plombes à se lancer

Lesquels? Je me farcis beaucoup de R pour du datamining en ce moment donc ça pourrait me servir.

J'ai commencé sur R tout récemment. Tu penses quoi de ce langage? Pour ma part, à première vue je lui trouve des choses qui ont l'air très intéressantes mais je lui trouve aussi des comportements aberrants. Ceci dit, mon opinion est peut-être biaisé à cause de Matlab...

grim7reaper · Le 11/04/2013, à 20:27

Rolinh a écrit :

grim7reaper a écrit :
Parce que Vim à un super plugin pour Git, et un plugin pour R qui mets pas trois plombes à se lancer
Lesquels? Je me farcis beaucoup de R pour du datamining en ce moment donc ça pourrait me servir.

Vim-R-plugin.
Pour en profiter pleinement, je conseille d'ajouter les packages recommandés : setwidth et colorout (retiré du CRAN à cause des conditions d’utilisation, par ici pour l’installer)

Rolinh a écrit :

J'ai commencé sur R tout récemment.

J’ai commencé il y a quelques mois, je ne pratique pas souvent (je reste sur Python autant que possible) mais cela dit j‘aide pas mal un gars qui l’utilise souvent dans mon bureau.
Donc si tu as des questions, tu peux les poser ici. Je garantis rien mais je pourrai peut-être y répondre

Rolinh a écrit :

Tu penses quoi de ce langage?

Que c’est un langage fait pour des non-informaticiens, et ça se sent. Il est très, comment dire… « permissif » et flexible sur certains trucs. Mais il est limité par rapport à des langages comme Python ou Ruby par exemple, c’en est presque frustrant parfois (de mon point de vue d’informaticien ^^)
Après oui, il y a des trucs intéressants.

Par contre les boucles sont terriblement lente, donc il faut passer pas les fonctions *apply, ce qui sous-entends un style de prog’ fonctionnelle que n’ont pas forcément les utilisateurs (bon ça dépends de leur background).
Un autre point noir : la vitesse des I/O qui n’est pas jojo non plus : à un moment je devais faire un script, j’ai hésité entre partir sur R pour m’entraîner ou rester sur Python. Du coup, j’ai fait un bench et y’avais pas photo au niveau lecture du fichier (fichier ASCII de 21 Mo, j’en avais presque 8000 à traiter donc critère important, d’autant plus que la différence n’était pas minime…)
Y’a aussi le modèle objet qui est très déroutant, surtout le S3. Bon le S4 est un peu mieux, mais ça reste particulier. Paraît qu’une ébauche de S5 est en court, à voir.
Sinon le système de package peut être super-chiant (en tant que dev’, pas utilisateur) car très stricte, c’est assez long et laborieux (car tu dois tout documenter et de préférence tester un max’). Mais l’avantage c’est que ça force à faire des packages de qualité .
[mylife]
Un fois j’ai voulu soumettre un paquet (un petit truc de rien du tout), et puis je suis tombé sur une tête de con qui m’a pourri pour une petite erreur dans le processus de soumission. Du coup, ça m’a refroidi… (même si après je suis tombé sur un autre gus super sympa)
[/mylife]

Moi perso, quand je peux je reste sur Python/numpy/matplotlib (mais c’est sûrement aussi car je fais pas trop de stat’ avancés pour le moment, donc je ne profite pas trop du point de fort de R). Mais je reconnais que R à des côtés sympa et intéressant

Rolinh a écrit :

Pour ma part, à première vue je lui trouve des choses qui ont l'air très intéressantes mais je lui trouve aussi des comportements aberrants.

C’est quoi les comportements aberrants que tu as rencontré en R ?
Peut-être que c’est juste dû à une incompréhension de R (qui peut parfois avoir une logique déroutante, surtout pour un informaticien ^^)

Dernière modification par grim7reaper (Le 11/04/2013, à 20:35)

Rolinh · Le 11/04/2013, à 21:38

grim7reaper a écrit :

Donc si tu as des questions, tu peux les poser ici. Je garantis rien mais je pourrai peut-être y répondre

Je vais devoir faire un projet en binôme en R. Il se pourrait bien que de l'aide soit utile de tant à autre.

grim7reaper a écrit :

Que c’est un langage fait pour des non-informaticiens, et ça se sent. Il est très, comment dire… « permissif » et flexible sur certains trucs.

C'est la première réflexion que je me suis faite. Une des premières choses qui m'a surpris c'est ça:

> x <- 42
> 56 -> y
> x
[1] 42
> y
[1] 56

Je m'attendais aussi à avoir quelque chose de similaire à Matlab/Octave mais je me suis vite rendu compte, lorsque j'ai voulu manipuler des matrices, que pour ce cas de figure on est bien loin de la facilité qu'apporte Matlab. Et je trouve la syntaxe générale du langage nettement moins claire.

grim7reaper a écrit :

Par contre les boucles sont terriblement lente, donc il faut passer pas les fonctions *apply

Ouep, ça je l'ai vite assimilé. Ça ne me dérange pas plus que ça mais je comprend que ça paraisse moins naturel à certain.

grim7reaper a écrit :

Un autre point noir : la vitesse des I/O qui n’est pas jojo non plus

Je m'en souviendrais.

grim7reaper a écrit :

C’est quoi les comportements aberrants que tu as rencontré en R ?
Peut-être que c’est juste dû à une incompréhension de R (qui peut parfois avoir une logique déroutante, surtout pour un informaticien ^^)

C'est possible vu que je suis encore en train d'essayer de me familiariser avec et qu'effectivement, je le trouve très déroutant par moment.

Le dernier trucs que j'ai trouvé bizarre était en rapport avec une matrice et apply. Je ne me rappelle plus du cas de figure exactement mais j'avais un cas où, si je faisais mon travail en utilisant apply, il fallait que je fasse la transposée après coup et avec une autre méthode, il fallait que je fasse ma transposée avant... Dit comme ça c'est pas très parlant mais je ne retrouve plus le bout de code en question.
La prochaine fois que je trouverais un truc incohérent, je viendrais poster ici, comme ça tu pourras me dire si c'est moi qui ne fait pas de la façon "R"esque ou si toi aussi tu trouves incohérent.

The Uploader · Le 12/04/2013, à 13:57

Joel on Software - Why are the MS Offce file formats so complicated ? (And some workarounds)
Pas mal les détails techniques et l'explication de la dette technologique.

Dernière modification par The Uploader (Le 12/04/2013, à 13:57)

grim7reaper · Le 12/04/2013, à 17:53

Intéressant en effet.
Cela dit, je ne comprends pas leur choix. Pourquoi rester sur le même format et en faire un gigantesque fourre-tout d’une complexité pas possible ?
Je pense que ça aurait été plus judicieux de sortir d’autres formats au fur et à mesure, tout en gardant le support des anciens bien entendu.
Il y aurait eu certes plus de format, mais avec une complexité bien moindre. Et tant que tout les formats était supportés par l’utilisateur, ça aurait été transparent.
En gros, pour faire une analogie avec la programmation : découper en fonctions plutôt que de tout mettre dans le main…

The Uploader · Le 12/04/2013, à 18:03

Je crois que ça leur permettait de garder les anciennes versions de Word/Office plus ou moins compatible avec le "nouveau" format (d'où le nom du format dans le sélecteur de fichiers pour l'enregistrement : Microsoft Word 97/2000/XP). Je n'ai pas testé cependant (par exemple ouvrir avec Word 97 un fichier .DOC fait avec Word 2002)

Mais ils ont fini par le faire pour Office 2007 en passant aux DOCX (XMLX pour Excel, .PPTX pour Powerpint, etc...), soit Office OpenXML.

Mais ça a cassé la rétro-compatibilité, évidemment (d'où la sortie de convertisseurs vers le Office XP/2003 : http://www.microsoft.com/fr-fr/download … .aspx?id=3 ).

Enfin ce que j'ai aimé le plus dans le lien c'est que les premières versions de Word devaient tourner sur des ordis avec 8 Mo de RAM et être super rapides. Ça met en perspective l'âge de MS Office.

Dernière modification par The Uploader (Le 12/04/2013, à 18:05)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1051 Le 08/04/2013, à 15:50

Re : /* Topic des codeurs [8] */

#1052 Le 08/04/2013, à 16:06

Re : /* Topic des codeurs [8] */

#1053 Le 08/04/2013, à 16:55

Re : /* Topic des codeurs [8] */

#1054 Le 09/04/2013, à 09:31

Re : /* Topic des codeurs [8] */

#1055 Le 09/04/2013, à 10:29

Re : /* Topic des codeurs [8] */

#1056 Le 10/04/2013, à 13:02

Re : /* Topic des codeurs [8] */

#1057 Le 10/04/2013, à 13:35

Re : /* Topic des codeurs [8] */

#1058 Le 10/04/2013, à 18:14

Re : /* Topic des codeurs [8] */

#1059 Le 10/04/2013, à 18:55

Re : /* Topic des codeurs [8] */

#1060 Le 10/04/2013, à 18:59

Re : /* Topic des codeurs [8] */

#1061 Le 10/04/2013, à 19:45

Re : /* Topic des codeurs [8] */

#1062 Le 11/04/2013, à 05:30

Re : /* Topic des codeurs [8] */

#1063 Le 11/04/2013, à 05:56

Re : /* Topic des codeurs [8] */

#1064 Le 11/04/2013, à 06:43

Re : /* Topic des codeurs [8] */

#1065 Le 11/04/2013, à 09:07

Re : /* Topic des codeurs [8] */

#1066 Le 11/04/2013, à 09:47

Re : /* Topic des codeurs [8] */

#1067 Le 11/04/2013, à 09:58

Re : /* Topic des codeurs [8] */

#1068 Le 11/04/2013, à 10:05

Re : /* Topic des codeurs [8] */

#1069 Le 11/04/2013, à 10:12

Re : /* Topic des codeurs [8] */

#1070 Le 11/04/2013, à 20:00

Re : /* Topic des codeurs [8] */

#1071 Le 11/04/2013, à 20:27

Re : /* Topic des codeurs [8] */

#1072 Le 11/04/2013, à 21:38

Re : /* Topic des codeurs [8] */

#1073 Le 12/04/2013, à 13:57

Re : /* Topic des codeurs [8] */

#1074 Le 12/04/2013, à 17:53

Re : /* Topic des codeurs [8] */

#1075 Le 12/04/2013, à 18:03

Re : /* Topic des codeurs [8] */

Pied de page des forums