TImaniac a écrit 6420 commentaires

10 millions ca passe pas :
"Le fichier contient plus de 1 048 576 lignes ou 16 384 colonnes. "
J'ai fini par killer Calc qui n'avait toujours pas réussi à ouvrir 1 million de ligne au bout de 20 minutes.

vi c'est Excel 2007. Quand Calc aura réussi à ouvrir le million de lignes je m'attaquerait au 10 millions :)

Que se passe-t-il si tu ajoute des tableaux croisés dynamiques ? Est-ce que les performances se maintiennent ?
Euh, je suis très mauvais en tableur :) on sort du scénario initial là :)

Mais bon comme quoi votre jugement sur le fait qu'un tableur n'est pas adapté était surtout dû à des (mauvaises) expériences vécues en terme de performance et que c'est pas parcque OOo a de mauvaises performances (ca fait 5 minutes que Calc essai d'ouvrir mon fichier et il bouffe 100% de CPU... j'attend toujours :) ) qu'il faut généraliser en disant que les tableurs c'est pas adapté.

On peut très bien avoir des préjugés sur les clio et que la réalité et tout autre, et qu'elle tient très bien 300000km.

avec 1 million de lignes :
temps d'ouverture de 24 secondes
Consommation mémoire : + 60 Mo.
Rien d'extraordinaire.
Allez j'attend ton bench.

Alors je viens de faire un test, j'ai créé un fichier CSV avec 5 colonnes (texte, entier, flottant, date, texte) et 100 000 lignes.
Etapes :
- Fichier > ouvrir
- petit wizard d'import d'un CSV qui s'affiche (info de typage sur les colonnes, séparateur des colonnes)
Excel :
- temps d'ouverture après wizard : 3 secondes
- parsing des colonnes : ok
- naviguation : fluide
- somme automatique de la colonne des entiers : instantanée

Où est le putain de problème d'utiliser un tableur avec 100 000 lignes là où ca n'aurait posé de problème à personne avec 100 lignes ???

Alors vas-y, fait le coup avec ton outil "plus aproprié".

La roadmap a toujours ete clair et net sur le sujet.
Mais personne ne dit le contraire, et perso je ne juge pas. Je constate juste que Novell trouve cette Roadmap trop rigide, trop dictée par Sun, que ca n'avance pas assez vite à leur goût et qu'ils font go-oo pour proposer leur vision.

Bouton droit, "Ouvrir avec...", MIcrosoft Access...
oups. ca marche pas.
Evidemment qu'il est possible d'importer relativement facilement des données csv dans MS Access... encore faut-il connaître les manipulations. Après t'as une jolie table, tu veux faire 2 ou 3 calculs... je fais comments ?
Et ca va m'apporter quoi de plus que mon Excel au final ? Je peux pas faire le test là tout de suite, mais je mets ma main à couper qu'ouvrir le CSV sous Excel est pas plus lent que d'importer des données CSV dans MS Access... c'est donc pas un problème de rapidité... Je sens que je vais également avoir plus de mal à faire comprendre à MS Access c'est quoi le type des données dans mon MS Access, le gain ne sera donc pas à la manipulation non plus... Ah oui je vais pouvoir faire des requêtes SQL dans le designer intégrer, youpi mais je sais toujours pas comment faire mes 2/3 calculs... c'est pas un gain fonctionnel immédiat non plus...
A part dire : oua j'ai utiliser un SGBD pour afficher des données CSV que j'ai dû importer parcque ca s'ouvre pas de base, en quoi MS Access est plus pertinent ?

je suis fatigué d'expliquer
ou fatiguer d'argumenter ?
Alors si je prends ta référence Wikipedia :
"À l'origine destinés au traitement automatisé des données financières, les logiciels tableurs sont maintenant utilisés pour effectuer des tâches variées, de la gestion de bases de données simples à la production de graphiques, en passant par diverses analyses statistiques."
pour moi un CSV c'est rien d'autres qu'un base de données simples avec une seule table sans typage (ce que propose de résoudre un assistant à l'ouverture d'un csv sous Excel). On peut très bien imaginer vouloir faire des analyses statistiques sur des données contenues dans un CSV par exemple, ca rentre donc parfaitement dans les cadres d'utilisation "courant" d'un tableur tel que défini par Wikipedia. Aucune notion de volumétrie de données n'est indiquée.

CSV est un format bâtard, on a sorti une espèce de RFC juste parce que c'était nécessaire pour valider le type mime
On est d'accord : CSV c'est pas la panacée, c'est plutôt le dernier recours en terme d'interopérabilité, mais le fait est qu'on doit souvent y faire face, et qu'on est parfois bien content de trouver ce format d'export/import simple. Tiens pas plus tard que cet aprem, j'ai voulu analyser l'écart moyen entre les GOPs contenues dans une vidéo H264, j'avais un outil d'analyse sous la main qui m'a proposé un export... en CSV uniquement. J'étais très content de pouvoir l'ouvrir dans Excel et de faire un rapide calcul pour avoir l'écart moyen entre les valeurs.

en fait, c'est du texte : donc le logiciel fait pour l'ouvrir, c'est l'éditeur de texte.
Et tu trouves ca mieux adapté pour l'utilisateur... On sent l'informaticien : on s'adapte pas aux besoins des utilisateurs mais aux contraintes techniques du format utilisé : c'est un fichier texte, donc on l'ouvre avec un éditeur de texte. Cool. Je fais pareil avec des données encodées en bin64 ?

Ben si justement c'est le bon exemple, le tableur n'est qu'un pauvre petit porte-avion perdu au milieu de la mer.
Franchement je préfères mon exemple, qui montre clairement que la longueur de la piste ne correspond à aucune limite technique valide.

Franchement, si j'arrive à naviguer sur internet avec Word, pourquoi j'irai chercher autre chose (genre un navigateur internet).
La différence, c'est que jusqu'à présent, je vois pas ce qu'il y a de mieux qu'un tableur pour ouvrir la plupart des CSV. Tu me proposes un éditeur de texte : génial. D'autres proposes un SGBD, en oubliant que c'est hors de porté de n'importe quel utilisateur (perso j'ai les compétences mais ca me paraît totalement débile).
MS Access et OOo Base, même combat, hors de portée de l'utilisateur lambda, et ne propose de toute façon pas d'ouvrir un CSV comme ca pif paf poum.
Donc y'a toujours pas mieux que le tableur.

Ca voudrait dire que toute la news (en tout cas sur le point semble t'il fondamental de l'import des documents docx) est completement fausse?
Ca veut surtout dire que tes affirmations sont complètement fausses. Le support des formats MS est plutôt un bon exemple de la position de Novell : c'est toujours pas dispo dans OOo, ca avance pas assez vite, ils font "leur" OOo du coup. On aime ou on aime pas (c'est, mais c'est complètement dans l'esprit de la news et du projet go-oo.

, en aucun cas pour afficher des "données" statiques sur 300000 lignes.
tu ne dis toujours pas pourquoi.

Il n'y a pas pire conteneur fourre tout que le CSV
On s'en fou, le fait est que notre utilisateur a reçu ce document, et qu'il doit faire avec.

Le seul outil qui puisse être "universel" pour ouvrir du CSV, c'est un éditeur de texte.
Tiens et lui il a pas des limitations de taille ? Pourquoi serait-il plus à même de gérer des gros fichiers ?

L'outil adapté dépendra donc de la nature des données, pas de leur conteneur.
Oui enfin s'il n'a pas accès au contenu parcqu'il ne sait pas lire le contenant...

Si je me présente avec mon 747 devant un porte-avion en disant que les contraintes techniques internes ne me regardent pas en tant qu'utilisateur qu'ils ont qu'a en faire un plus gros, tu ne crois pas qu'il y en a 2 ou 3 qui vont se marrer ?
Mauvais exemple, là c'est plutôt j'arrive avec mon 747 devant la piste d'un aéroport mais la piste est trop courte, et toi tu vas continuer à me dire que c'est n'importe quoi, un aéroport c'était conçu à la base pour faire atterir un petit aéroplane, fournir un abri aux voyageur, pas gérer un traffic de millions de passager dans des gros engins à 2 étages et qu'il faut mieux utiliser pour ca des trains de voyageurs, beaucoup plus adaptés à ma situation, même si je suis toujours avec mon 747 sur les bras et que ma gare de trains ne sait pas acceuillir un 747, mais qu'en théorie mes passagers seraient mieux gérés dans mon système ferroviaire.

Franchement, si j'arrive à ouvrir un document CSV contenant 100000 lignes dans Excel, que ca répond à mon besoin, pourquoi j'irai chercher autre chose ? (en l'occurence tu me propose un éditeur de texte, hem.)

Si c'est de la manipulation de données (aggrégation de données disparates), un ETL tel que Talend Studio https://linuxfr.org//2008/06/12/24207.html (version 2.4.0) pourra aider et ensuite un "requêteur" à la OOo base ou Kexi pourra fournir un cliquodrome à la Access.
Ca permet d'ouvrir un CSV dans mon explorateur de document ?

Blablabla.
Le fait que mono n'est pas nécessaire pour go-oo tel que distribué actuellement.

L'outil adapté, c'est l'outil adapté, que se soit un SGBD ou un "Frontend" de db qui lit du csv
et il est où cet outil ? nan parcque je me met à la place de monsieur tout le monde, je reçois un tel document, la première idée qui me passe par la tête c'est de l'ouvrir avec un tableur.

Arrête avec tes 32000 lignes, ça fait perpète que Calc gère 65000 lignes comme Excel.
j'en sais strictement rien, c'est pas moi qui est fait le retour utilisateur mettant en avant ce problème. Ce que je vois c'est qu'un tableur est fait pour gérer des données tabulaires, et un CSV contient des données tabulaires. La taille ne doit pas être mon problème d'utilisateur.

Tu ne me proposes toujours aucune solution concrête et simple pour ouvrir n'importe quel CSV, quelque soit sa taille.

Tu ne me donnes toujours aucune bonne raison pour laquelle un tableur n'est pas un bon candidat pour afficher ce type de document, à part que ton logiciel favori a des limitations liées à des contraintes techniques internes, qui une fois de plus ne me regarde pas en tant qu'utilisateur.

Ce n'est pas parce que l'utilisation d'un outil adapté demande un investissement et/ou une formation qu'on peut excuser qu'une feignasse vienne pleurer que son outil pourri il marche pas.
Attend, t'es en train de dire que l'outil adapté c'est le SGBD pour une seule et unique raison : d'après toi, si on dépasse le seuil de 32000 lignes, c'est un SGBD qu'il faut utiliser. Pourquoi ? (sachant que MS Office n'a pas cette limitation)
Jusqu'à preuve du contraire, un CSV, c'est des données tabulaires. Et un tableur me semble tout à fait approprié (ca dépend ce qu'on veut faire avec les données bien sûr), notamment pour consulter le document.
Que OOo est des limitations à la con que les concurrents n'ont pas et que ca frustre certains utilisateur ne doit conduire à insulter l'ignorance ou la feignantise de l'utilisateur.
Faut adapter les outils aux besoins de l'utilisateur et non l'inverse ! L'utilisateur il a peut être pas du tout besoin d'un SGBD pour consulter un CSV quand même !
C'est même totalement débile, faut commencer par créer une base, l'importer, créer une requête, tout ca pour simplement afficher des données... le tableur est fait pour ca !

les sources : http://lxr.go-oo.org/source/sw/writerfilter/source/ooxml/

En mattant rapidement les sources, on dirait un mix de XSLT et de C++.

Franchement t'as vu tous les concepts qu'il y a derrière un SGBD ? tu crois franchement que c'est à la portée de l'utilisateur bureautique de OOo ? Franchement si c'est juste pour de la consultation ou des opérations basiques d'un CSV, un tableur est peut être même beaucoup plus indiqué. J'ai même envie de dire que c'est fait pour ! Après si OOo ne gère "que" 32000 lignes, c'est un autre problème. Mais c'est pas parcque l'outil a des limitations qu'il faut engueuler l'utilisateur parcqu'il se trompe d'outil !

oué mais le tableur, il a une IHM que même le non informaticien peut manipuler, alors que ton berkeley db, il sait même pas ce que c'est l'utilisateur lambda. C'est pas le tout de d'avoir le bon outil, encore faut-il qu'on sache s'en servir.

Alors que c'est tellement mieux de laisser Sun ne mettre que le support de .NET...
Le but n'est pas d'inclure des fonctionnalités dans OOo se basant sur Mono (comme le fait Sun avec Java), mais de permettre à des applications basées sur Mono de piloter OOo comme si c'était une lib.
Sun qui s'y était collé en premier en proposant le support de .NET, comme y'a d'ailleur le support du pilotage en Java C++ ou Python.

Mono a implémenté avec plus de 8 mois de retard sur Microsoft le langage C# 3 !
Franchement c'est lamentable, tous les daïssideurs doivent bien comprendre que Mono est une folie.

Ah on me souffle à l'oreil que GCJ supporte officiellement toutes les fonctionnalités du langage Java 1.5 (sorti en 2004) depuis mars 2008...

2) Mono/C#/.NET propose (comme la plupart des plateformes) d'appeler des composants écrits en "natif" (C/C++). Bref, il est virtuellement possible d'utiliser tout et n'importe quoi. D'ailleur on a GTK#, Gnome#, dbus-sharp, Mono.Unix, etc.

3) Là c'est un problème qui n'a pas grand chose à voir avec C# en soit. Les premiers draft de specs sortent bien avant l'implémentation finale de MS.

4) .NET propose de toute façon depuis sa création un mécanisme de "profile" permettant d'installer côte à côte plusieurs versions du framework. L'histoire montre que les quelques incompatibilités qu'il y a entre versions sont liées essentiellement à des contraintes de sécurité. Très peut de comportement différent, et seulement dans des libs.
De plus, il faut bien différencier langage, plateforme, et lib.
.NET 2.0, .NET 3.0 et .NET 3.5 ne sont que des (grosses)"upgrades" de libs et de langages, la plateforme n'a pas bougée, c'est le même environnement d'exécution, et ca Mono l'a et ca marche toujours.

Le nerf de la guerre, c'est les libs. Mono sera toujours en retard sur la stack Microsoft, mais ils proposent aussi une stack indépendante et orientée logiciels libres, qui n'a pas grand chose à voir avec ce que propose Microsoft. Bref, on peut faire abstraction de Microsoft (si ca gène certains) et ne garder que la plateforme Mono, qui propose des technos libres (GTK, Gnome, DBus, etc.).

Effectivement, la situation est identique dans la mienne.

C'est vrai que casser la compatibilité avec les millions/milliards de lignes de code déjà écrites, ca va leur faire de la bonne pub...

Dans le second cas, il y a la GPLv3 qui est un bel outil contre les brevets tout de même...
Ca c'est une vaste connerie... C'est pas parcque tu mets l'étiquette GPLv3 sur ton soft qu'il va se trouver à l'abris par magie.