pasBill pasGates a écrit 16291 commentaires

C'est un STANDARD !
Tu fais de même avec les fonctions de l'api Windows ?
#define crer_fenetre CreateWindow
main(...)
creer_fenetre(...)

On parle de texte, donnees qui viennent de l'exterieur. Genre pour XML t'as typiquement le nom du schema suivi du nom du tag (bob:michu), tu vas t'amuser la aussi a mettre en dur "bob:michu" ? ou bien tu vas faire la chose intelligente et mettre des variables/const ?

Parce que si tu mets ca en dur mon cher, t'as pas un parser valide.

Ton fichier XML il peut avoir des noms de schema redefinis et il sera toujours un fichier ODF valide, mais ca visiblement tu ne l'as pas compris(c'est exactement ce qui permet a Brian Jones de changer la taille des tags dans le fichier).

Bref, tu es sympa, mais avant de dire aux gens qu'ils sont ridicules, de sortir des conneries sur MS qui ferait ca car ils aiment changer les standards, ... je te propose d'aller prendre qqe cours de programmation et apprendre a faire les choses proprement.
Ca t'apprendra notamment a faire un parser qui fonctionne plutot qu'un parser qui ne lit que des fichiers avec un nom de schema predefini en dur a 403 endroits differents dans ton code.

Et ben ce n'est pas optimisé, c'est tout. Je n'ai jamais dit que OOo était optimisé. J'ai dit que pour OOo l'optimisation n'était pas de ses priorité actuellement.

Tu commences par nous dire que le parsing n'a aucune influence sur le chargement, et quand je te montres le contraire preuve a l'appui tu viens nous sortir que c'est "parce que c'est pas optimise", faut te decider mon cher, et penser a arreter de me traiter de "con" et "mauvaise foi" alors que j'ai raison.

Fais l'essai avec OpenXML/MS-Office et montre que c'est un drame au niveau performance. Là tu nous prouveras quelque chose, puisque l'optimisation est un objectif de MS-Office selon toi.

Moi je te propose de lire le blog de Brian Jones plus regulierement, la tu y apprendras notamment que :

a) Les tags qui sont rarement presents dans le format sont long, car ca n'aura aucun impact sur les perfs
b) Office 2003 avait un format avec des tags longs, et il etait lent a charger les fichiers, raison pour laquelle ils ont change ca pour OpenXML

Je suis percuadé qu'OOo optimisera tout ça en temps utile. Et ce jour là, qu'es-ce que tu va nous inventer pour proner les formats illisibles ?

Ouais, ils vont optimiser en sortant ODF 2.0 qui aura des tags de 1-2 caracteres, et apres ca on rigolera bien.

waitpid te permet d'attendre jusqu'a ce qu'un processus fils se termine.

Il te suffit d'ecrire un petit soft qui lance lui-meme les commandes que tu veux, et qui attend avec waitpid, des qu'un des fils meure tu reprends la main et tu tues tout ce qui reste.

Tu essaies d'expliquer que MS a "sacrifié" ses développeurs pour le bien des utilisateurs ?

Comme je l'ai dit et repete, c'est une _legere_ gene. Mais visiblement tu es incapable de comprendre que quand on developpe un parser pour un format, on doit lire la doc de toute facon histoire de comprendre les subtilites, et que quand on code on ne le fait pas un porc en mettant en dur le texte partout mais en utilisant un #define/const avec la valeur definie en un endroit unique.

Quand a ton lien c'est du n'importe quoi, il s'agit de nouveaux softs, donc nouveaux protocols, donc ajoutes a la liste des protocoles sous licence, rien de bien nouveau.

Si je veux dire "bold", je vais mettre "bold". Point barre.

C'est genial, t'es en train de me dire que le jour ou cette partie de texte devra changer tu devras t'amuser a tout changer plutot que changer un unique #define/const ? T'as des techniques de programmation geniales.

Je parle du coût d'avoir des symbols long au-lieu de symbols cours. Parser un fichier xml, même si les symbols sont longs, le temps passer à lire les symbols et les comparer à une table est ridicule.

http://blogs.msdn.com/brian_jones/archive/2006/10/26/perform(...)

The simplest way to see the impact for yourself is to just take an application like OpenOffice, and get a decent sized spreadsheet (I took a file with just one worksheet, that was 15 columns by 15,000 rows). Save it in ODF and make 2 copies. In one of the copies open content.xml and change some of the namespace prefixes to make them much longer. I aimed to make it so that the resulting content.xml file was about 3 times larger than the original since this helps replicate the size difference you would see if we changed SpreadsheetML so that it's tag length was longer and more descriptive like ODF (it would probably be more than that, but I found that making content.xml 3 times larger was more than enough to get a noticable slowdown in load times). I used namespace prefix approach because it's the easiest way to replicate the effect of a larger element name without changing the actual element names (since that would prevent the file from being readable by OpenOffice). In my test, by essentially tripling the size of the element names, I found that the file went from loading in about 9 seconds to taking about 11 seconds.

Voila, je te proposes de faire l'essai toi meme...

En tout cas c'est un peu comme la logique d'inciter les éditeurs de jeux à utiliser directx pour la 3D au lieu d'opengl, comme la logique d'inciter les webmestres à utiliser du code html compatible uniquement IE et hors des standards w3c, comme d'utiliser les formats ms office au lieu du format opendocument etc

Ah oui ? Google c'est un standard ? J'etais pas au courant...

Remarque, OpenGL c'est pas vraiment un standard non plus, pas ISO, pas ECMA, pas IEEE, ... quand a OpenDocument, c'est pas plus un standard que OpenXML alors bon si la critique c'est que MS essaie de vendre son truc plutot que celui du voisin, c'est un peu normal je te dirais...

Et tu as vu ou que MS demande d'interdire Google ?

Non pas que je trouve le procede intelligent, bien au contraire, mais MS ne demande pas d'interdire les autres moteurs de recherche.

Il y a des éditeurs xml pour ça. Mais tu fais bien de rappeler que MS et les trucs lisible ça fait deux. D'où les gros blob dans OpenXML. Blob sans documentation...

Des editeurs XML pour quoi ? Pour developper un soft ? Tu me fais bien rire.

Toi tu vas faire ton "wrapeur", un autre va en faire un autre, etc...
Je lis ton code, je dois lire tes #define, puis je dois lire la doc.
Super... Que du bonheur.

Que ton tag soit < bold> ou < b> c'est du pareil au meme, tu vas pas t'amuser a mettre en dur "bold" partout dans ton code ou bien ?

Aucune idée. 200 000 = 5 * 40 000, ça ne veut ABSOLUMENT pas dire que le "gros" fichier va prendre 5 fois plus de temps à traiter.
Si c'est pour le débit (lire les symbols et les comparer avec une table), ne t'inquiète il y a beaucoup de marge. Les cpu base de gamme d'aujourd'hui te bouffent du 1 Go/s les doigts dans le nez. Donc traitement des symbols du gros fichier en moins d'un millième de seconde sans problème. Oui oui.

Wow, t'arrives a parser, valider et representer un fichier ODF de 200Ko en moins d'un millieme de seconde ? Tu devrais penser a aider OOo alors, parce qu'ils ont des problemes de ce cote la.

Mémoire vive : il y a une table de symbol et des pointeurs.
Combien de symbol il y a ?
Imaginons 2000 pour ODF, voyons large.
2000*10 = 20 ko.
2000*2 = 4 ko.

Ah si seulement c'etait si simple qu'une table de symbols et pointeurs...

Et tout ça cas il y a des symbols de 2 caractères au-lieu de 10.
Tu insultes mon intelligence.

Certainement pas, par contre il y a de quoi se demander pourquoi OOo prend 7x plus de temps qu'Office 2003 pour charger un fichier quasi-identique tu crois pas ?

On parle en RAM, pas sur disque, avec les disques de 200Go d'aujourd'hui 1Mo de plus ou de moins est ridicule.

Le parsing du XML lui-meme oui, mais un traitement de texte ca fait legerement plus que charger un fichier XML dans un parser, il doit traverser le contenu pour l'interpreter aussi mon cher.

Quand a la mauvaise foi, t'es libre de me demontrer que les resultats du bench du dessous sont faux.

Ça c'est lisible, t'as pratiquement pas besoin de la doc :

Ah oui ? Alors en voyant ce XML t'es capable de deviner quels sont les attributs facultatifs de chaque tag ? T'es capable de deviner si tel tag peut etre reproduit plusieurs fois voir aucune ? ...

T'es fort, moi il me faut la doc pour ca.

Quand tu programmes, se rappeler de locale::long c'est 50 fois plus facile que h:k .

Non, parce que quand tu programmes t'as pas a te rappeler du texte "h:k" ou de "local:long", tu te rappelles du #define/const que tu lui a donne dans ton code.

C'est ridicule. Quel gain ? T'as un bench ? On gagne combien ?
0,1 % au maximum sur une opération load/save.

Ben tu y reflechis un peu, combien de temps il faut pour parser un fichier de 200'000 caracteres compare a un fichier de 40'000 ? Combien d'espace il faut pour stocker(selon la maniere dont le soft le fait, c'est dependant de ca et pas completement proportionel) 10 caracteres compare a 2 ?

Si le développeur doit passer par un moteur de recherche pour à chaque fois retrouver à quoi correspond quel mnémonique, on est pas rendu !

Le developpeur il passe par la doc, pas par un moteur de recherche, c'est a ca qu'elle sert.

Voir un tag qui s'appelle "bold" ne signifie rien, il faut lire la doc pour savoir exactement ce que ce tag fait, quels sont les effets de bord,... si tu te referes simplement au contenu XML tu ne fais rien d'autre que du reverse-engineering et c'est une maniere assuree d'avoir des bugs.

Quand aux performances, je dirais rien, je laisse les chiffres parler : http://blogs.zdnet.com/Ou/?p=120

Oui ca c'est la theorie, mais la theorie on s'en fout, ce qui importe c'est la pratique, et en pratique quasiment personne ne va editer ces fichiers la main.

Alors apres on peut rendre son format arbitrairement gros pour satisfaire 0.1% des gens, mais c'est legerement inutile et a un impact negatif(temps de chargement,...) sur 99.9% des gens,

Si XML est illisible, ça influe sur le développement (toujours avoir le nez dans la doc, problèmes de communication, etc...) et négativement.

Ca influe legerement sur le developpement, ca influerait bcp si les gens lisaient constamment du XML, ce qui n'est pas du tout le cas vu qu'a 99% c'est des softs qui les lisent.
Les developpeurs que le tag soit < b> ou < bold> ils doivent se referer a la doc pour savoir exactement ce que le tag implique, bref, legere gene mais sans plus.

Quand tu codes, que t'utilises des noms cours ou des noms longs, la compilation n'est pas significativement plus courte ou plus longue.

Tout a fait, alors qu'avec XML c'est different, raison pour laquelle MS le fait.

Parce que ce n'est pas la meme chose qu'XML

Ton API, que le nom fasse 20 caracteres ou 2, ca ne change rien au code final(il est identique) et il est donc stupide de rendre la chose illisible.

XML par contre, la taille des balises influe sur le resultat final en terme de vitesse et espace.

Faux dans les deux cas. Avant la percée de firefox, le web dérivait de plus en plus vers quelque chose de visionable uniquement sous IE.

IE c'est du W3C, qu'il ne respecte pas 100% les normes n'y change rien, Firefox ne les respecte pas completement non plus.

Tout le monde a déjà oublié la nature de MSN (MicroSoft Network) à sa sortie ? Un protocole internet propriétaire et concurrent de TCP/IP !

Perdu, c'etait un ISP a la AOL(partie du contenu limite aux membres), mais ca tournait sur TCP/IP

C'est être naïf de croire que Microsoft respecte les standards qu'ils mettent ou participent à mettre en place. S'ils peuvent faire passer en force un de leurs standards propriétaires ils n'hésitent pas : Microsoft siège au W3C depuis longtemps, même à la grande époque des sites IE-only.

Tout comme Netscape a l'epoque, mais tout le monde considere Netscape comme un heros, rigolo quand meme.

100% d'accord, mais le nom de balise est vraiment pas important.

Si je te mets :

<OOo:bold attr="sds">mme michu</OOo:bold>

ou

<OOo:b a="sds">mme michu</OOo:b>

et la doc dit clairement ce que b et a sont, c'est du pareil au meme quasiment pour le developpeur, il met le define qu'il faut dans son code et c'est tout.

Le code il s'en fout que la balise fasse un caractere ou 10, tu vas pas mettre le nom de la balise en explicite partout dans ton code mais une variable ou un #define qui la represente.

Pour la compression c'est en partie vrai, par contre au parsing ton parser devra se taper toute la balise, et la avoir une petite balise accelere les choses.

XML permet des choses faciles genre XSLT et autres, XML est simple a parser / utiliser, XML est dans le pire des cas lisible par un humain avec un peu d'effort,...

C'est ca l'avantage d'XML, et c'est pour ca qu'il est utilise, mais ca n'a jamais ete prevu pour etre un format modifiable par un humain.

Le fait qu'une balise soit d'un seul caractere est franchement totalement sans importance.

Tu vas t'amuser a editer un fichier OpenXML ou ODF de 200Ko a la main ? Moi non.

Les balises, elles seront traitees par des softs dans 99% des cas, et ces softs ils s'en foutent que la balise fasse 1 ou 10 caracteres ou que la balise ait un nom explicite ou pas.

Que qqe developpeurs soient legerement genes car les balises sont courtes et non-explicites et reellement sans importance, ils seront legerement embetes une fois lors du dev. initial(devront jeter un oeil a la doc plus souvent) et c'est tout , en retour ca donne des fichiers plus legers et qui se chargent plus rapidement pour 100 millions de personnes sur la duree de vie du format.

Le libre ira vers ODF. Il faut "tout faire" pour que MS aille aussi vers ODF comme il est allé version tcp/ip, comme il est allé (en trainant des pieds) vers les normes w3c.

Le probleme avec ca c'est que MS n'avait pas d'autre choix que TCP/IP et les normes W3C, il n'existait rien d'autre qui offre les memes possibilites.
La, MS domine le marche et a son propre format. Les faire aller vers ODF c'est un peu une utopie. A long terme(>5 ans) qui sait vu la vitesse des changements en informatique, mais d'ici la aucune chance.

A part ca, tout a fait d'accord avec ton post.

Ce sont des images toutes prêtes qu'on lance, on modifie le nom, et hop, au suivant. Pourquoi ne pas faire pareil avec Ubuntu?

Installer l'image c'est pas le probleme, le probleme c'est qu'il faut preparer cette image.

Quels patchs avoir dans cette image ? Sont ils compatible avec tous les HW sur lesquels l'image sera dispo ? Quid de la compatibilite avec les applis existantes ? Qui va garantir un minimum de compatibilite ? ...

Avec Windows, Dell installe les patchs de securite, les drivers, ainsi que qqe autres patchs specifiques, tester une nouvelle image leur prend un temps qui est tres loin d'etre negligeable, ca coute cher.

De nouveaux patchs de securite sortent, ben il faut refaire l'image, et hop on repart dans la phase de test...

Alors oui, ajouter une image ca ne coute rien, le probleme c'est que Dell doit s'assurer que cette image fonctionne, et ca ca coute.

Pour etre meme plus precis, entrer aux USA comme touriste et bosser pour Google USA, c'est l'assurance de te faire expulser si ils t'attrapent, c'est totalement illegal.

Je te demandes pas de montrer qu'il y a des APIs non documentes, il y en a plein pour un tas de raisons valides (on se reserve le droit de les modifier notamment)

Ce que je te demandes c'est une preuve que Office / Visual C++ les utilisaient ces APIs non documentes.

Et ca comme par magie, tu vas pas y arriver.

Et tu crois que c'est une coïncidence que Fahrenheit se soit planté alors qu'en même temps MS travaillais sur DirectX ? Ça a toujours été la technique de MS, soit on adopte un standard et on le pourri, soit on le rachète et on le coule.

Tu m'expliqueras pourquoi est-ce que MS a commence a bosser avec SGI sur qqe chose de different d'opengl si ils n'avaient absolument aucune intention d'aller de l'avant, tu crois qu'ils aiment jeter du fric en l'air ?

Quant à l'histoire du choix, forcément, quand tu te bases sur l'ignorance des gens pour imposer un choix qui ne leur laisse en fait pas vraiment de possibilité (D3D était meilleur techniquement, du point de vue du consommateur, mais complètement fermé), alors forcément on peut faire dire ce qu'on veut au "marché".

Ignorance ? Bien sur voyons, les editeurs de jeux sont ignorants et ne connaissent rien a l'informatique voyons !
Qu'il soit completement ferme est peut-etre un probleme de ton point de vue, ca veut pas dire que c'est un probleme pour tout le monde.

Microsoft ne s'est jamais fait l'avocat de standards ouverts car ils savent très bien qu'il y aurait alors plus de concurrence et qu'ils auraient du mal à s'imposer. Ils attribuent beaucoup de ressources, à mon avis (si tu pouvais confirmer), à l'aide au développement auprès des constructeurs pour les drivers D3D, alors que pour OpenGL, rien.

Windows avait a la fois OpenGL et Direct 3D, les 2 avec la meme facilite d'acces et de developpement, tu veux quoi de plus niveau concurrence ?
Quand a attribuer des ressources, je ne vois pas la difference, il y a toujours eu des drivers opengl / d3d pour a peu pres toutes les cartes, ca n'a jamais ete le probleme. Le probleme pour OpenGL c'est que les editeurs de jeux ont massivement choisi D3D.

Je ne reproche pas à D3D d'être meilleur techniquement, mais le fait est que si MS avait poussé à un standard ouvert, il y aurait pu avoir beaucoup plus de concurrence et d'améliorations apportées à un standard comme OpenGL.

Ton probleme en fait c'est que tu crois que MS aime controler pour controler. La maniere dont ca marche en interne est en fait tres simple : si il y a un standard qui fait ce qu'on veut, on l'utilise, si le standard ne repond pas aux besoins on essaie de le faire aller dans la direction qu'on veut, et si c'est pas possible on cree ce dont on a besoin nous meme.

Croire que MS a jete OpenGL juste pour lancer D3D n'a aucun sens, MS ne gagne pas plus d'argent avec D3D qu'il en gagnerait avec OpenGL si OpenGL faisait ce que MS veut.