Problème de compilation

Général
1

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>

2

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

···

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

3

Nicolas Sceaux a écrit :

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) }

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
%% sauts de pages, par contre pas de stretch vertical
\paper { #(define page-breaking optimal-page-breaks) }

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

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"

···

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

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

4

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

···

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

Nicolas Sceaux a écrit :

%% 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) }

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