Re: Problème de compilation

[Nicolas Sceaux]

Le 8 sept. 08 à 15:59, Philippe Hezaine a écrit :

> Bonjour à tous,
>
> Voulant regrouper dans un fascicule un bon nombre de partitions, je  
> me lance dans le "book-titling.ily" que Nicolas Sceaux a posté il y  
> a quelques temps sur la liste.
> Après avoir personnalisé certains paramètres et effectué plusieurs  
> tests plus ou moins volumineux (jusqu'à 20 pages), tout me semble  
> alors parfait.
> Donc je compile le projet actuel que Lilypond évalue à une  
> soixantaine de pages... et la compilation s'embourbe en un marathon  
> interminable (jusqu'à 2h sans résultats).
> Je suis sur Gentoo en version 2.11.56. avec 512 Mo de mémoire vive.
> Ayant lancé un "top" pendant la compilation, j'ai crois alors qu'il  
> s'agit d'un problème avec la mémoire: en fait, au bout d'un certain  
> temps Lilypond semble passer une partie de la mémoire en swap et  
> c'est à partir de ce moment là que les choses s'éternisent.
> Ayant l'occasion de pouvoir compiler le même fichier sur une Gentoo  
> 64 bits avec 1Go de mémoire, le problème persiste encore.
> Plus qu'intrigué par un problème que je n'ai jamais connu avec  
> Lilypond,
> je lui fais alors compiler, comme je l'ai souvent fait pour des  
> mises à jour, un répertoire entier de fichiers ly avec la commande:
>   lilypond *.ly
> Et là le problème est le même. Si le répertoire est assez chargé,  
> Lily démarre sur les chapeaux de roues, puis continue son bonhomme  
> de chemin
> jusqu'à une certaine limite où le problème précédent ressurgit.
> Je suis totalement incapable de dire de quoi il s'agit.
> Le code Scheme ne me semble pas en cause. Il compile déjà au moins  
> vingt pages sans problèmes.
> Alors? Une erreur de ma part? La mémoire? La compilation Gentoo? ...?


512 Mo, même 1 Go c'est un peu jeune pour des gros projets. Quand je  
compile
des gros bouquins, LilyPond peut prendre à lui seul ~1Go. Donc la ram  
est
certainement un problème dans ton cas. Mais il arrive que même avec  
beaucoup
de ram, une compilation ne finisse pas : à partir d'un certain volume  
de pièces,
la compilation peut s'embourber au niveau du calcul de sauts de lignes  
et de
pages.

Comme je rencontre également ce problème, j'ai écrit un algo moins  
complexe
(et qui traite mieux les passages textuels). Son avantage est que la  
compilation
finit très rapidement. Son désavantage est que le résultat n'est pas  
des plus
gracieux. Autre possibilité, essayer avec l'ancien algo.

%% Utilisation de l'algo "minimal-breaking", qui est idiot mais fait  
son travail
\paper { #(define page-breaking ly:minimal-breaking) }

%% Utilisation de l'ancien algo : plus long, mêmes sauts de lignes,  
mais meilleurs
%% sauts de pages, par contre pas de stretch vertical
\paper { #(define page-breaking optimal-page-breaks) }

Donc à l'heure actuelle, tu as le choix entre ces deux possibilités  
pour tenter
de résoudre logiciellement ton problème. Il faut essayer pour voir ce  
qui convient
le mieux.

De façon à pouvoir utiliser l'algo qui donne le meilleur résultat ET  
qui finit,
j'ai implémenté dans LilyPond un moyen de découper le bouquin en  
parties, et
ainsi l'algo est appliqué sur un sous-ensemble, plus petit, et donc la  
compilation
finit. Cette nouvelle fonctionnalité marche nickel chez moi, mais je  
ne l'ai pas
encore "poussé" dans la référence git. J'ai pu compiler des gros  
bouquins, avec
le bel algo. Ca marche de la façon suivante :

\bookpart {
  %% ... pièces de l'acte 1
}
%% ici ça met nécessairement un saut de page
\bookpart {
  %% ... pièces de l'acte 2
}

Quand j'aurai un peu de temps, je réenverrai un patch à faire relire  
par une
bonne âme, et si c'est accepté, ce sera un jour dans une version  
officielle de
LilyPond.

Nicolas