Note que ton point de vue n'est pas partagé par RMS: je ne me souviens plus où j'ai lu cela, mais il a dit au début du projet GNU, que les outils GNU ne devait pas limiter artificiellement la taille des données qu'ils traitent.
Vu ce qu'est capable d'ouvrir emacs, ça ne métonne pas :)
En même temps, il me semble que ls est limité en nombre de fichier qu'il peut lister. D'ailleurs y-a t-il une limite de nombre de lignes dans gnumeric ? et puis tant qu'on y est kspread pour un petit run de "qui-a-la-plus-grosse" qu'on rigole un peu ?
Dis de façon, plus pragmatique: il faut utiliser des entiers 32bits plutot que 16bits :-)
Sauf que la mémoire nécessaire sera bien plus importante il me semble => plus lourd, c'est ce que je disais avant.
Mais je pense tout de même que le tableur ne devrait pas limiter la taille des tables gérées, enfin autant que raisonnablement possible, bien sur.
La question est donc : 32000 lignes est-elle une limite raisonnable ? Je pense que oui, pour plus ( et même moins :) = oublier le tableur.
[^] # Re: 32 000 lignes de tableur
Posté par beb . En réponse à la dépêche Sortie d'OpenOffice.org 1.1 finale. Évalué à 1.
Vu ce qu'est capable d'ouvrir emacs, ça ne métonne pas :)
En même temps, il me semble que ls est limité en nombre de fichier qu'il peut lister. D'ailleurs y-a t-il une limite de nombre de lignes dans gnumeric ? et puis tant qu'on y est kspread pour un petit run de "qui-a-la-plus-grosse" qu'on rigole un peu ?
Dis de façon, plus pragmatique: il faut utiliser des entiers 32bits plutot que 16bits :-)
Sauf que la mémoire nécessaire sera bien plus importante il me semble => plus lourd, c'est ce que je disais avant.
Mais je pense tout de même que le tableur ne devrait pas limiter la taille des tables gérées, enfin autant que raisonnablement possible, bien sur.
La question est donc : 32000 lignes est-elle une limite raisonnable ? Je pense que oui, pour plus ( et même moins :) = oublier le tableur.