Subject: Problème de compilation

From: Philippe Hezaine <[email-masked]>
Date: Mon, 08 Sep 2008 15:59:25 +0200

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? ...?

Cordialement.

-- 
   Phil.
Superbonus-Project (Site principal) <http://superbonus.project.free.fr>

Superbonus-Project (Plate-forme d'échange):
<http://philippe.hezaine.free.fr>

---

From: Nicolas Sceaux <[email-masked]>
Date: Mon, 8 Sep 2008 21:24:35 +0200

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).
> 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.
> 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
> Le code Scheme ne me semble pas en cause. Il compile déjà au moins  
> vingt pages sans problèmes.

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

---

From: Philippe Hezaine <[email-masked]>
Date: Mon, 08 Sep 2008 22:10:57 +0200

Nicolas Sceaux a écrit :

> des gros bouquins, LilyPond peut prendre à lui seul ~1Go. Donc la ram est
> de ram, une compilation ne finisse pas : à partir d'un certain volume de 
> pièces,
> Comme je rencontre également ce problème, j'ai écrit un algo moins complexe
> finit très rapidement. Son désavantage est que le résultat n'est pas des 
> plus
> %% Utilisation de l'algo "minimal-breaking", qui est idiot mais fait son 
> travail

Merci mille fois Nicolas,

avec cette option dans \paper tout fonctionne à merveille même si le 
résultat n'est pas optimum. Pour le cas présent ce n'est pas très grave.
Il s'agit d'une version temporaire.
Oui! Je sais! Le temporaire qui dure ...

> %% Utilisation de l'ancien algo : plus long, mêmes sauts de lignes, mais 
> meilleurs

Par contre avec cette option j'obtiens le message suivant qui concerne 
mon .ily :

book-titling.ily:259:26: In procedure = in expression (= page-number p):
et plus loin
/home/phil/Lilypond-compile/essai-book/book-titling.ily:259:26: Wrong 
type: #f

Dans mon fichier .ily, il s'agit de la ligne:

              (cond ((and (= page-number p) (not display-1st)) #f)

dans les
%%% Markup commands for page headers

> Donc à l'heure actuelle, tu as le choix entre ces deux possibilités pour 
> tenter
> De façon à pouvoir utiliser l'algo qui donne le meilleur résultat ET qui 
> finit,
> finit. Cette nouvelle fonctionnalité marche nickel chez moi, mais je ne 
> l'ai pas
> Quand j'aurai un peu de temps, je réenverrai un patch à faire relire par 
> une
Magnifique! Cela me semble une bonne solution.
Moralité de l'histoire: je vais de ce pas acheter de la RAM pour bien 
sûr ne plus "ramer"

---

From: Nicolas Sceaux <[email-masked]>
Date: Mon, 8 Sep 2008 22:19:21 +0200

Le 8 sept. 08 à 22:10, Philippe Hezaine a écrit :

> Par contre avec cette option j'obtiens le message suivant qui  
> concerne mon .ily :
>
> /home/phil/Lilypond-compile/essai-book/book-titling.ily:259:26:  
> Wrong type: #f
>

Ah, oui, hm, autre désavantage de l'ancien algo, c'est qu'il ne  
supporte pas les
labels, c'est-à-dire il n'est pas possible de faire référence à des  
numéros de pages,
d'utiliser une table des matières, et autres en-têtes sophistiqués  
comme dans le code
que tu utilises.

Nicolas