Le 14/08/09 04:29, Jean-Baptiste Faure a écrit :
Le 14.08.2009 09:55, PAt a écrit :
Le 14/08/09 02:41, Jean-Baptiste Faure a écrit :
Le 14.08.2009 05:42, PAt a écrit :
Le 13/08/09 23:25, Jean-Baptiste Faure a écrit :
Si qqn le demande, je mettrai ce fichier en téléchargement.
Je suis preneur.
Bonjour Jean-Baptiste,
voilà l'adresse:
http://www.mydisk.se/coco/?user=cubytus
Les deux fichiers "tueurs" sont les deux premiers, pas le .DMG.
Bonjour,
Chez moi (Ubuntu 8.04 et 1 Go de RAM) OOo 3.1.1 RC1 prend pour le plus
petit des 2, jusqu'à 675 Mo pendant le chargement puis environ 500 Mo
une fois le fichier affiché. Je n'ai pas activé les macros.
Avec DEV300_m54 c'est plus fluide et il y a moins de ram occupée.
Il faut dire que 7 Mo compressé, 150 feuilles ça fait vraiment beaucoup.
Qu'est-ce qu'il est censé faire ce fichier ?
Bonne journée
JBF
Bonjour JBF,
c'est une bonne nouvelle toute relative; quelle est la *swap* et la
*RAM* occupée lorsque ces deux fichiers sont chargés simultanément,
que ça ressemble à la situation concrète?
ça je n'ai pas essayé et à mon avis ce n'est pas une bonne idée, le plus
petit prenant déjà 500 Mo de ram.
Est-ce qu'il y a des dépendances entre feuilles dans un même fichier ?
Si ce n'est pas le cas pourquoi ne pas découper les fichiers en paquets
de qq feuilles seulement ? À quoi bon charger 150 feuilles si on
travaille seulement sur un ou deux ?
En chargeant les deux, je suis à 1,02Gio de RAM réelle. C'est un progrès
par rapport aux 1,8Gio que ça prenait lorsque je bossais encore dans la
branche 2.x et le début de la 3.x.
Dans ces fichiers, une des dernières feuilles est liée à toutes les
précédentes, et sert *1-* à combiner aisément les données pour en faire
des graphiques et ultimement les exporter pour être compatibles avec
SPSS / PSPP / Matlab / GNUmeric; le seul format d'export réellement
intercompatible est le CSV; tous les autres créent des problèmes soit à
l'exportation, soit à l'importation. Et *2-* comme toutes ces données
ont été copiées-collées à la main, c'est impossible qu'il n'y ait aucune
erreur dans un ensemble de données aussi large. La page "récapitulative"
est un moyen de plus de détecter les erreurs, avec les sommes de
contrôle appliquées un peu partout. De ces erreurs, il y en a eu plein.
Avoir combiné toutes les données sur une seule feuille aurait rendu la
moindre erreur impossible à trouver facilement. Je conviens qu'il y a
sûrement des moyens plus propres de gérer les erreurs, mais sans
programmation, c'est tout ce que j'ai trouvé. En théorie, sans
considération de poids, les deux fichiers auraient dû être fusionnés.
En soi, les données des 148 premières feuilles, puisqu'elles se répètent
sur la dernière, sont inutiles pour la suite de l'exportation lorsqu'il
n'y a plus d'erreur pour le fichier "4_cat"; par contre, je pourrais
très bien avoir besoin de toutes les données du fichier "20(tt)".
Dans chacun des fichiers pour la prochaine étape, il faudra leur
adjoindre, pour le travail statistique, d'autres données, qui sont
actuellement dans un 3e fichier.
Ce sont des fichiers de données récoltées et calculées, il y a très
peu de formules et de graphiques.
Tu trouves ? J'ai l'impression qu'il y a un graphique sur chaque feuille
(colonne AC), non ? Ce qui en ferait 150.
Quel fichier? Je n'ai pas trouvé de graphique dans les colonnes AC, ni
même à côté.. Sur la dernière feuille des "20(tt) ...", c'est normal, ça
fait partie du boulot à faire dessus
Je dis toute relative, car leur conversion en XLS, une fois sous MS
Office 2008, prend tout de même près de moitié moins de ressources que
sous OOo en ODS; /a priori/, rien ne laisse supposer que les données
mises en XLS soient différentes, mais comme tu le dis si bien, je n'ai
confiance que dans les formats ouverts et documentés. Une corruption
dans un tel ensemble de données peut passer inaperçue jusqu'au dernier
moment. Je n'ai pas essayé de le convertir en XLSX (L'autre format
documenté) et de l'ouvrir dans OOo, qu'est-ce que ça donne?
OOo n'écrit pas le xlsx, il faut donc passer par le xls puis utiliser
MSO pour convertir en xlsx. Et ensuite importer le xlsx dans OOo mais ce
sera encore pire car il faut ajouter le temps et les ressources pour le
filtre d'import.
Autant pour moi, j'avais oublié que la documentation du Office XML était
davantage destinée à tuer la concurrence qu'à fournir une compatibilité
réelle.
D'un autre côté, il y a tellement de "blancs" dans les formats
OpenDocument que la compatibilité n'est pas assurée non plus; quel
logiciel excepté les dérivés de OOo lit le ODS correctement?
Ironie du sort...
Pour mes tests, je désactive aussi les macros; il s'agit d'embryons
qui n'ont pas abouti, mes compétences de programmation étant nulles,
et OOo manquant d'un manuel décent d'introduction à la programmation.
Combien de temps dure le chargement? L'enregistrement d'une modification?
Je n'ai pas fait de modif juste navigué entre feuilles et dans une
feuille. C'est faisable mais long, surtout quand on soupçonne qu'on
pourrait faire mieux autrement. ;-)
Comme ces fichiers ont été montés à la main à partir de données
provenant d'un logiciel extrêmement instable et buggé, c'était bien plus
facile de faire comme ça.
Et puis, dans le fond, proposer un changement de cet ordre n'est pas
répondre à la question, puisque ce même document de travail, en XLS sous
MS Office, est tout à fait exploitable sans une machine surpuissante.
D'après moi, ça serait plutôt un constat d'échec pour OOo. :-)
Comme je travaille tous les jours avec OOo/ NeoOffice, je me sers de cas
réels comme tests, vu qu'il est impossible de tout couvrir avec une
batterie de tests.
Par principe, j'aurais du mal à accepter l'impossibilité de terminer ma
thèse sur autre chose que des logiciels libres.
++
Patrick
