Hi Bertrand, Mike, David, Reinhold and everyone in the \markup rewrite gang,
Here is a bulletin from the Guile V2 migration cave. I am currently brewing a patch for Tracer 1686. The markup facility as written is a major PITA when running with Guile V2, and is currently blocking progress on this patch. 1. The markup facility code needs to be in a Scheme module (scm markup-facility-defs), or (scm markup-macros) or some such for clean backwards compatibility between Guile V1.8 and Guile 2. This is so that lily.scm can load all the things in the current load list using either Guile 1.8 or Guile V2 and can also byte-compile each loaded file using Guile V2 so that the compiled file can be loaded next time LilyPond fires up to gain performance. 2. Using a module for markup exposes brittleness in the markup code when using Guile V2. Basically I have moved all the declarations in markup-macros and markup to markup-macros.scm, which defines the new (scm markup-macros) module. There is a (use-modules (scm markup-macros) call in lily.scm. Guile V2 is fussier about things like forward-referencing macros and syntax forms before you declare them (i.e. using lazy bindings for macros). 2.1 We can fix things with macros declared at Scheme level by moving declarations to other .scm files and juggling the load order in lily.scm. 2.2 However, things get nastier when we get into the define-markup-commands.scm file and using the markup, markup*, define-markup-command and define-markup-command-list macros. Here we are doing on-the-fly parsing and interpreting and things tend to fall over under Guile V2's stricter régime. 2.2.1 Firstly, the commands in the file have to be re-ordered so that the #<markup> forms are not referenced before they are used. E.g. #line form is used internally in procedure calls contained within a define-markup-commmand macro for (define-markup-command draw-line ...) before (define-markup-command line) is declared. There are several more examples within the file. 2.2.2 If things are not in the right order you may get lucky and get a fairly unhelpful message "Not a markup command: <markup>". This is the call to lookup-markup-command failing to return a pair within compile-markup-command, which is called from compile-all-markup-commands, which is called from the markup or markup*, which may or may not have been called recursively from higher-level define-markup-command<mumble> call. 2.2.3 Some of the definitions just give you a gnostic "source expression failed to match any pattern in form <blah>" which may imply we're running into macro hygiene issues. 2.3 We may need think about using using (define-syntax for the macro definitions in the markup facility if hygiene is indeed an issue. This is just to let you know if you're planning on major surgery on the syntax front, the markup module issue needs to be addressed as well. Hope this informs your discussions about changes to markup and if any of you have any insights into what I've found while while working I'd appreciate your input, as I'm getting a bit stuck. I want to be able to concentrate on sorting out the changes to lily.scm and main.cc and validating running up lily under Guile V2. For me the markup facility is a bit of a side issue. Cheers, Ian Hulin On 23/10/11 22:08, bordage.bertr...@gmail.com wrote: > LGTM. You'll be happy to know that Mike and I are currently trying > to get rid of \markuplines, so that there will only be a \markup > command. > > http://codereview.appspot.com/5312050/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel