Discussion :

[rambc]

Bonjour,
je travaille actuellement sur une appli. pour m'aider à taper des documents scientifiques et/ou des tutos.
Il faut donc que j'analyse du texte qui aura été tapé par l'utilisateur dans un fichier de type TEXT.

Je me pose la question de savoir comment traiter ce texte qui ressemble un peu à du Restructured Text. J'ai deux possibilités :

1. Créer une liste Python où je stocke les informations relatives au texte (comme par exemple les mises en forme).
2. Utiliser un flux qui analyse le fichier pour en créer un 2nd dans lequel je stocke les infos dans un format proche de xml, lequel fichier sera ensuite lu suivant d'autres flux pour des exports aux formats HTML, PDF via LaTeX, entre autres choses.

La 1ère méthode est vite mise en place mais la 2nde me parait plus sure mais inutile si la réponse à ma question de départ est non.

Quelqu'un aurait-il une suggestion (même si ma question est vague, peut-être que certains d'entre vous ont une expérience pouvant m'aider) ?

[wiztricks]

Bonsoir,
Je n'ai pas trop compris la question de départ: est-ce qu'il s'agit du volume des textes à traiter?
Pour le reste, convertir le fichier en XML (a défaut de le générer directement en XML à partir de l'éditeur) permet 'potentiellement' de le transformer dans tous les autres formats avec le convertisseur ad hoc - qui existe sans doute déjà.
Reste à comparer 1 a 2... Autrement dit quitte à analyser le texte pour connaître des informations sur sa structure pour quoi en profiter pour générer la version XML.
-W

[DelphiManiac]

Pas sûr que je réponde bien à la question aussi.

Si l'on part du principe :

Un mot en moyenne contient 8 lettres
Une ligne, en moyenne : 15 mots
Une page : 40 lignes
Un livre : 500 pages

Cela fais : 2 700 000 caractères (en comptant 1 espace de plus par mot) soit environ 2,5Mo

Même en multipliant toutes ces valeurs par 2, ce qui me paraît très large, on arrive à environ 40Mo.

Vu la taille mémoire des PC actuellement, je pense que tu peux traiter ça en mémoire sans problème.

[rambc]

Réponse convaincante.

Merci.

[wiztricks]

Au nombre de mots, il faut ajouter nombre de méta données qui ne sont pas nécessairement négligeables en entrée comme en sortie (surtout si on XMLIfie)

En plus rien n'indique que les traitements à effectuer sur le bouquin demande à ce qu'il soit complètement en mémoire.

Si on XMLifie (oops) le contenu, les unités d'informations titres, paragraphes, ... à conserver en mémoire sont relativement petits et une lecture/écriture au fil de l'eau est possible.

Fait de façon bestiale, lire 40Mo, puis les parcourir recopiant ces 40Mo dans un espace équivalent en remplaçant des tags par d'autres tags et écrire le résultat... donne un temps de calcul relativement petit (copie de mémoire à mémoire) par rapport aux temps de lecture/écriture disques.
En procédant ainsi impossible de paralléliser lectures et écritures: la durée de traitement total double.

Ensuite on pourra vouloir lancer plusieurs conversions en parallèle... La le gag sera qu'on va peut être utiliser trop de mémoire et constater des dégradations de performances importantes car...
L'OS a bout de mémoire physique va récupérer de la mémoire: comme le contenu du bouquin en entrée comme en sortie est accédé séquentiellement, ses pages iront dans le fichier de pagination et on va encore multiplier par 2 la durée à cause des IO disques: écriture de 40Mo dans le fichier de pagination, puis relecture et écriture dans le fichier de sortie.
Note: on peut éviter cela en mmappant le fichier en mémoire.

Trouvez vous toujours cela génial?
- W

[rambc]

wiztricks, j'ai décidé de passer à un traitement ligne par ligne de mes fichiers même si je ne suis pas totalement convaincu de l'utilité malgré tes arguments. Je doute d'autant plus que je me suis souvenu que David Mertz, l'auteur de "Text Processing in Python", indique qu'il n'a jamais eu besoin pour ces livres de faire un traitement ligne par ligne des fichiers sources.