organisation du dépôt.

homeostasie commented 8 years ago

Les 4000 fichiers en frontal dans un répertoire unique est un frein assez important à la compréhension et la prise en main de ce super projet.

Comment préfères-tu procéder pour qu'on réorganise tout ça ?

On commence par quelques dossiers dans l'ordre de ton plan ?

Introduction
Ensembles de nombres.
Théorie des groupes
Anneaux

...

Ou tu préfères quelques choses de plus pratique.

développement
exo
correction *images

Naereen commented 8 years ago

Je suis assez d'accord...

Une organisation en sous-dossiers par types de fichier me semble une bonne idée, plutôt que de suivre le plan (qui peut être amené à changer).

SnarkBoojum commented 8 years ago

Puis-je aussi suggérer un Makefile ou équivalent pour faciliter les opérations les plus simples?

En fait, pour trouver recompilation.txt, j'ai fait:

ls |grep -v tex|grep -v pdf|grep -v md5|grep -v png|grep -v "\.m" |grep -v "sage"|grep -v "\.py" |grep -v "\.pstricks"

après avoir vainement tenté de mettre la main sur Makefile.

LaurentClaessens commented 8 years ago

Aïe, désolé pour le piège, mais ''recompilation.txt' n'est pas une bonne idée à suivre parce qu'il traite essentiellement de reconstruire les figures, ce qui est tout un truc ... Pour compiler gentillement il y a ceci : http://laurent.claessens-donadello.eu/pdf/readme.pdf

LaurentClaessens commented 8 years ago

ok. Les fichiers d'exerices et de correction sont dans un répertoire séparé. Par contre j'ai du modifier 'exocorr.sty' qu'il faudra donc retélécharger.

LaurentClaessens commented 8 years ago

J'ai essayé de séparer les sources des figures, mais ça ne marche pas aussi simplement que j'espérais. Il faudra que je pense un peu, parce que le scipt qui crée le code tikz a besoin de lire les fichiers aux.

LaurentClaessens commented 8 years ago

QUESTION : est-ce que vous pensez que les fichiers tikzFIG*.md5 et tikzFIG*.pdf sont utiles ?

Sans eux, au moment de la compilation, pdflatex interprète toutes les figures en tikz et ça prend pas mal de temps. Avec eux, il intègre directement le pdf sans interpréter le code tikz. Ça diminue le temps de compilation de façon assez appréciable. Mais ça fait 700 fichiers ...

Par défaut, si les pdf et md5 ne sont pas présents, pdflatex va les créer; et ça, ça prend littéralement deux heures sur mon ordinateur.

Les lignes clefs sont :

\newcounter{useexternal} \setcounter{useexternal}{1}
\ifthenelse{\value{useexternal}=1}{ \usetikzlibrary{external} \tikzexternalize }{ \newcommand{\tikzsetnextfilename}[1]{} }

En mettant useexternal à zéro, pdflatex ne créera pas les pdf à la volée si ils sont absents. Compiler avec

pytex lst_frido.py --no-external

met automatiquement useexternal à 0.

LaurentClaessens commented 8 years ago

Faisons deux seconde l'avocat du diable ...

QUESTION : pourquoi ranger les fichiers ?

À partir du moment où on parvient à compiler un pdf avec --src-specials (ce que pytex fait par défaut), il suffit de cliquer dans le pdf pour arriver dans le bon fichier tex, non ?

Je vais essayer d'écrire un petit quelque chose dans readme.pdf pour expliquer à quelle fonction correspond chacun des types de fichier, et les conventions de nommage. Cela va sans doute déjà aider un peu.

Pour faire un peu de méta-critique auto-récusive je dirais d'ailleurs que les sources de ce readme devraient être séparées ...

Naereen commented 8 years ago

Je crois que la question initiale ne disait pas qu'un si grand nombre de fichiers dans le dossier principal rendait la compilation inefficace ou impossible.

Le problème, il me semble, est plutôt l'affichage de la page principale de GitHub (qui signale qu'elle n'affiche "que" 1000 fichiers parmi ~4000). Plus il y a de fichiers dans le dossier principal, plus la page prend de temps a être affichée (alors qu'un visiteur attend typiquement de voir très vite le contenu du README.md).

Au delà de ce bête soucis d'affichage et de rapidité d'affichage, il me semble que ce serait plus simple et plus cohérent d'avoir un sous-dossier pour chaque typo de fichiers (par exemple tikz_tex/, tikz_pdf/, tikz_md5/ etc). Quitte a bidouiller un peu les scripts.

LaurentClaessens commented 8 years ago

pour tikz_tex, ok je vois plus ou moins comment modifier les scripts. tikz_pdf et tikz_md5 vont dépendre de comment tikz cherche ses fichiers; je ne sais pas si c'est possible à séparer (à part qu'en LaTeX, tout est possible). Par contre, sémantiquement, tikz_pdf et tikz_md5 ne sont pas des "sources" : ce sont des sous-produits de la compilation. Je les fournis parce que les créer soi-même, ça prend plein de temps. En gros : je supprime les tiks_pdf et tiks_md5, ça fait qu'après le premier "git clone", bing on prend une belle compilation de deux heures et ensuite ces fichiers sont créés et on est bon. Ça fait 700 fichiers en moins dans le dépot git. Sémantiquement, ce serait plus correct parce qu'on ne devrait pas mettre dans le dépot git de fichiers sous-produits de la compilation.

LaurentClaessens commented 8 years ago

Réponse à la réplique dans smath

Je n'ai pas adapté le code Python, et notamment celui qui génère les figures.

Mais pour ce dernier, il me semble que ce serait simple. Par exemple, si on est prêt à modifier l'API de pystricks, en ajoutant un paramètre output_path aux figures. Sinon, en modifiant figures-generators/figures_mazhe.py pour changer le CWD à ../figures/ avant de générer les images.

C'est ce à quoi je me suis attaché cette après-midi. Un commit assez gros arrive (toutes les figures, donc tous les tikzFIG*.pdf).

L'endroit où faire le changement est par contre plus subtil que ça. En effet il y a deux moyens de générer une figure

Les faire toutes : ./figures_mazhe.py --all
En faire une :
- lancer Sage
- attach(phystricksFOO.py);FOO()

Les deux méthodes sont indispensables parce que l'on veut pouvoir compiler une figure à la fois lorsqu'on travaille dessus.

Du coup j'ai :

ajouté un fichier Directories.py dans 'figures-generators'
les __init__ de Figure et de Picture vérifient si ce fichier existe, et si oui, il le lit et modifie en fonction les chemins de sortie.
Directories.py contient les lignes

MAIN_TEX=".."
PICTURES_TEX="../pictures_tex"

qui indique que

les fichiers LaTeX principaux sont dans ".." relatif à là où sont les sources des figures
les sorties doivent être faites dans ../pictures_tex, toujours en relatif.

Au niveau du nommage, les répertoires sont :

mazhe/pictures_src
mazhe/pictures_tex

Je ne sais pas si ce sont des super noms, mais ça ne va rien coûter de changer (figures_generators, c'est bien).

Naereen commented 8 years ago

Actuellement, l'organisation me semble bien plus claire.

La page d'accueil du dépôt est parfaitement lisible et claire, au point je ne vois pas comment on pourrait l'améliorer.

Bravo @LaurentClaessens !

LaurentClaessens commented 8 years ago

Je me posais justement une question à ce sujet. Il faudrait une description des fichiers et des contenus des différents répertoires quelque part. Est-ce que c'estmieux de décrire cela dans README.md ou dans le manuel_du_contributeur ?

Naereen commented 8 years ago

Dans le manuel du contributeur je pense.

homeostasie commented 8 years ago

Yep, ça va beaucoup mieux comme ça. Merci pour ce travail.

homeostasie commented 8 years ago

Ça me parait bien maintenant.

LaurentClaessens / mazhe

organisation du dépôt. #14