Re: Problème de compilation

[Philippe Hezaine]

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>