1 @c -*- coding: us-ascii; mode: texinfo; -*-
3 @chapter Programming work
6 * Overview of LilyPond architecture::
7 * LilyPond programming languages::
8 * Programming without compiling::
11 * Debugging LilyPond::
12 * Adding or modifying features::
19 @node Overview of LilyPond architecture
20 @section Overview of LilyPond architecture
22 LilyPond processes the input file into graphical and musical output in a
23 number of stages. This process, along with the types of routines that
24 accomplish the various stages of the process, is described in this section. A
25 more complete description of the LilyPond architecture and internal program
26 execution is found in Erik Sandberg's
27 @uref{http://lilypond.org/web/images/thesis-erik-sandberg.pdf, master's
31 The first stage of LilyPond processing is @emph{parsing}. In the parsing
32 process, music expressions in LilyPond input format are converted to music
33 expressions in Scheme format. In Scheme format, a music expression is a list
34 in tree form, with nodes that indicate the relationships between various music
35 events. The LilyPond parser is written in Bison.
37 The second stage of LilyPond processing is @emph{iterating}. Iterating
38 assigns each music event to a context, which is the environment in which the
39 music will be finally engraved. The context is responsible for all further
40 processing of the music. It is during the iteration stage that contexts are
41 created as necessary to ensure that every note has a Voice type context (e.g.
42 Voice, TabVoice, DrumVoice, CueVoice, MensuralVoice, VaticanaVoice,
43 GregorianTranscriptionVoice), that the Voice type contexts exist in
44 appropriate Staff type contexts, and that parallel Staff type contexts exist
45 in StaffGroup type contexts. In addition, during the iteration stage each
46 music event is assigned a moment, or a time in the music when the event
49 Each type of music event has an associated iterator. Iterators are defined in
50 *-iterator.cc. During iteration, an
51 event's iterator is called to deliver that music event to the appropriate
54 The final stage of LilyPond processing is @emph{translation}. During
55 translation, music events are prepared for graphical or midi output. The
56 translation step is accomplished by the polymorphic base class Translator
57 through its two derived classes: Engraver (for graphical output) and
58 Performer (for midi output).
60 Translators are defined in C++ files named *-engraver.cc and *-performer.cc.
61 Much of the work of translating is handled by Scheme functions,
62 which is one of the keys to LilyPond's exceptional flexibility.
64 @sourceimage{architecture-diagram,,,png}
67 @node LilyPond programming languages
68 @section LilyPond programming languages
70 Programming in LilyPond is done in a variety of programming languages. Each
71 language is used for a specific purpose or purposes. This section describes
72 the languages used and provides links to reference manuals and tutorials for
73 the relevant language.
77 The core functionality of LilyPond is implemented in C++.
79 C++ is so ubiquitous that it is difficult to identify either a reference
80 manual or a tutorial. Programmers unfamiliar with C++ will need to spend some
81 time to learn the language before attempting to modify the C++ code.
83 The C++ code calls Scheme/GUILE through the GUILE interface, which is
85 @uref{http://www.gnu.org/software/guile/manual/html_node/index.html, GUILE
90 The LilyPond lexer is implemented in Flex, an implementation of the Unix lex
91 lexical analyser generator. Resources for Flex can be found
92 @uref{http://flex.sourceforge.net/, here}.
96 The LilyPond parser is implemented in Bison, a GNU parser generator. The
97 Bison homepage is found at @uref{http://www.gnu.org/software/bison/,
98 gnu.org}. The manual (which includes both a reference and tutorial) is
99 @uref{http://www.gnu.org/software/bison/manual/index.html, available} in a
104 GNU Make is used to control the compiling process and to build the
105 documentation and the website. GNU Make documentation is available at
106 @uref{http://www.gnu.org/software/make/manual/, the GNU website}.
108 @subsection GUILE or Scheme
110 GUILE is the dialect of Scheme that is used as LilyPond's extension language.
111 Many extensions to LilyPond are written entirely in GUILE. The
112 @uref{http://www.gnu.org/software/guile/manual/html_node/index.html,
113 GUILE Reference Manual} is available online.
115 @uref{http://mitpress.mit.edu/sicp/full-text/book/book.html, Structure and
116 Interpretation of Computer Programs}, a popular textbook used to teach
117 programming in Scheme is available in its entirety online.
119 An introduction to Guile/Scheme as used in LilyPond can be found in the
120 Learning Manual, see @rlearning{Scheme tutorial}.
124 MetaFont is used to create the music fonts used by LilyPond. A MetaFont
125 tutorial is available at @uref{http://metafont.tutorial.free.fr/, the
126 METAFONT tutorial page}.
128 @subsection PostScript
130 PostScript is used to generate graphical output. A brief PostScript tutorial
131 is @uref{http://local.wasp.uwa.edu.au/~pbourke/dataformats/postscript/,
132 available online}. The
133 @uref{http://www.adobe.com/devnet/postscript/pdfs/PLRM.pdf, PostScript Lanugage
134 Reference} is available online in PDF format.
138 Python is used for XML2ly and is used for buillding the documentation and the
141 Python documentation is available at @uref{http://www.python.org/doc/,
144 @node Programming without compiling
145 @section Programming without compiling
147 Much of the development work in LilyPond takes place by changing *.ly or
148 *.scm files. These changes can be made without compiling LilyPond. Such
149 changes are described in this section.
152 @subsection Modifying distribution files
154 Much of LilyPond is written in Scheme or LilyPond input files. These
155 files are interpreted when the program is run, rather than being compiled
156 when the program is built, and are present in all LilyPond distributions.
157 You will find .ly files in the ly/ directory and the Scheme files in the
158 scm/ directory. Both Scheme files and .ly files can be modified and
159 saved with any text editor. It's probably wise to make a backup copy of
160 your files before you modify them, although you can reinstall if the
161 files become corrupted.
163 Once you've modified the files, you can test the changes just by running
164 LilyPond on some input file. It's a good idea to create a file that
165 demonstrates the feature you're trying to add. This file will eventually
166 become a regression test and will be part of the LilyPond distribution.
168 @subsection Desired file formatting
170 Files that are part of the LilyPond distribution have Unix-style line
171 endings (LF), rather than DOS (CR+LF) or MacOS 9 and earlier (CR). Make
172 sure you use the necessary tools to ensure that Unix-style line endings are
173 preserved in the patches you create.
175 Tab characters should not be included in files for distribution. All
176 indentation should be done with spaces. Most editors have settings to
177 allow the setting of tab stops and ensuring that no tab characters are
178 included in the file.
180 Scheme files and LilyPond files should be written according to standard
181 style guidelines. Scheme file guidelines can be found at
182 @uref{http://community.schemewiki.org/?scheme-style}. Following these
183 guidelines will make your code easier to read. Both you and others that
184 work on your code will be glad you followed these guidelines.
186 For LilyPond files, you should follow the guidelines for LilyPond snippets
187 in the documentation. You can find these guidelines at
188 @ref{Texinfo introduction and usage policy}.
190 @node Finding functions
191 @section Finding functions
193 When making changes or fixing bugs in LilyPond, one of the initial
194 challenges is finding out where in the code tree the functions to
195 be modified live. With nearly 3000 files in the source tree,
196 trial-and-error searching is generally ineffective. This section
197 describes a process for finding interesting code.
199 @subsection Using the ROADMAP
201 The file ROADMAP is located in the main directory of the lilypond source.
202 ROADMAP lists all of the directories in the LilPond source tree, along
203 with a brief description of the kind of files found in each directory.
204 This can be a very helpful tool for deciding which directories to search
205 when looking for a function.
208 @subsection Using grep to search
210 Having identified a likely subdirectory to search, the grep utility can
211 be used to search for a function name. The format of the grep command is
214 grep -i functionName subdirectory/*
217 This command will search all the contents of the directory subdirectory/
218 and display every line in any of the files that contains
219 functionName. The @code{-i} option makes @command{grep} ignore
220 case -- this can be very useful if you are not yet familiar with
221 our capitalization conventions.
223 The most likely directories to grep for function names are scm/ for
224 scheme files, ly/ for lilypond input (*.ly) files, and lily/ for C++
228 @subsection Using git grep to search
230 If you have used git to obtain the source, you have access to a
231 powerful tool to search for functions. The command:
234 git grep functionName
237 will search through all of the files that are present in the git
238 repository looking for functionName. It also presents the results
239 of the search using @code{less}, so the results are displayed one page
242 @subsection Searching on the git repository at Savannah
244 You can also use the equivalent of git grep on the Savannah server.
249 Go to http://git.sv.gnu.org/gitweb/?p=lilypond.git
252 In the pulldown box that says commit, select grep.
255 Type functionName in the search box, and hit enter/return
259 This will initiate a search of the remote git repository.
268 @subsection Handling errors
270 As a general rule, you should always try to continue computations,
271 even if there is some kind of error. When the program stops, it
272 is often very hard for a user to pinpoint what part of the input
273 causes an error. Finding the culprit is much easier if there is
274 some viewable output.
276 So functions and methods do not return errorcodes, they never
277 crash, but report a programming_error and try to carry on.
279 @subsection Languages
281 C++ and Python are preferred. Python code should use PEP 8.
283 @subsection Filenames
285 Definitions of classes that are only accessed via pointers (*) or
286 references (&) shall not be included as include files.
292 ".cc" Implementation files
293 ".icc" Inline definition files
294 ".tcc" non inline Template defs
298 (setq auto-mode-alist
299 (append '(("\\.make$" . makefile-mode)
300 ("\\.cc$" . c++-mode)
301 ("\\.icc$" . c++-mode)
302 ("\\.tcc$" . c++-mode)
303 ("\\.hh$" . c++-mode)
304 ("\\.pod$" . text-mode)
309 The class Class_name is coded in @q{class-name.*}
311 @subsection Indentation
313 Standard GNU coding style is used. In emacs:
316 (add-hook 'c++-mode-hook
317 '(lambda() (c-set-style "gnu")
321 If you like using font-lock, you can also add this to your
325 (setq font-lock-maximum-decoration t)
326 (setq c++-font-lock-keywords-3
328 c++-font-lock-keywords-3
329 '(("\\b\\(a-zA-Z_?+_\\)\\b" 1 font-lock-variable-name-face) ("\\b\\(A-Z?+a-z_?+\\)\\b" 1 font-lock-type-face))
333 Some source files may not currently have proper indenting. If this
334 is the case, it is desirable to fix the improper indenting when the
335 file is modified, with the hope of continually improving the code.
337 @subsection Indenting files with emacs in script mode
339 @c email to wl@gnu.org when I get here.
341 @warning{this is pending some confirmation on -devel. July 2009 -gp}
343 Command-line script to format stuff with emacs:
347 emacs $1 -batch --eval '(indent-region (point-min) (point-max) nil)' -f save-buffer
350 (that's all on one line)
352 Save it as a shell script, then run on the file(s) you modified.
354 @subsection Indenting with vim
356 Although emacs indentation is the LilyPond standard, acceptable
357 indentation can usually be accomplished with vim. Some hints for
369 filetype plugin indent on
371 set ignorecase smartcase
374 set statusline=%F%m%r%h%w\ %{&ff}\ %Y\ [ASCII=\%03.3b]\ [HEX=\%02.2B]\ %04l,%04v\ %p%%\ [LEN=%L]
377 " Remove trailing whitespace on write
378 autocmd BufWritePre * :%s/\s\+$//e
381 With this .vimrc, files can be reindented automatically by highlihting
382 the lines to be indented in visual mode (use V to enter visual mode)
385 A scheme.vim file will help improve the indentation. This one
386 was suggested by Patrick McCarty. It should be saved in
387 ~/.vim/after/syntax/scheme.vim.
390 " Additional Guile-specific 'forms'
391 syn keyword schemeSyntax define-public define* define-safe-public
392 syn keyword schemeSyntax use-modules define-module
393 syn keyword schemeSyntax defmacro-public define-macro
394 syn keyword schemeSyntax define-builtin-markup-command
395 syn keyword schemeSyntax define-markup-command
396 syn keyword schemeSyntax define-builtin-markup-list-command
397 syn keyword schemeSyntax let-keywords* lambda* define*-public
398 syn keyword schemeSyntax defmacro* defmacro*-public
400 " All of the above should influence indenting too
401 set lw+=define-public,define*,define-safe-public,use-modules,define-module
402 set lw+=defmacro-public,define-macro,define-builtin-markup-command
403 set lw+=define-markup-command,define-builtin-markup-list-command
404 set lw+=let-keywords*,lambda*,define*-public,defmacro*,defmacro*-public
406 " These forms should not influence indenting
410 " Try to highlight all ly: procedures
411 syn match schemeFunc "ly:[^) ]\+"
414 @subsection Classes and Types
423 Member variable names end with an underscore:
432 Macro names should be written in uppercase completely.
435 @subsection Broken code
437 Do not write broken code. This includes hardwired dependencies,
438 hardwired constants, slow algorithms and obvious limitations. If
439 you can not avoid it, mark the place clearly, and add a comment
440 explaining shortcomings of the code.
442 We reject broken-in-advance on principle.
446 Variable names should be complete words, rather than abbreviations.
447 For example, it is preferred to use @code{thickness} rather than
448 @code{th} or @code{t}.
450 Multi-word variable names in C++ should have the words separated
451 by the underscore character (@q{_}).
453 Multi-word variable names in Scheme should have the words separated
458 Comments may not be needed if descriptive variable names are used
459 in the code and the logic is straightforward. However, if the
460 logic is difficult to follow, and particularly if non-obvious
461 code has been included to resolve a bug, a comment describing
462 the logic and/or the need for the non-obvious code should be included.
464 There are instances where the current code could be commented better.
465 If significant time is required to understand the code as part of
466 preparing a patch, it would be wise to add comments reflecting your
467 understanding to make future work easier.
471 Messages need to follow Localization.
474 @subsection Localization
476 This document provides some guidelines for programmers write user
477 messages. To help translations, user messages must follow
478 uniform conventions. Follow these rules when coding for LilyPond.
479 Hopefully, this can be replaced by general GNU guidelines in the
480 future. Even better would be to have an English (en_BR, en_AM)
481 guide helping programmers writing consistent messages for all GNU
484 Non-preferred messages are marked with `+'. By convention,
485 ungrammatical examples are marked with `*'. However, such ungrammatical
486 examples may still be preferred.
491 Every message to the user should be localized (and thus be marked
492 for localization). This includes warning and error messages.
495 Do not localize/gettextify:
499 `programming_error ()'s
502 `programming_warning ()'s
508 output strings (PostScript, TeX, etc.)
513 Messages to be localized must be encapsulated in `_ (STRING)' or
514 `_f (FORMAT, ...)'. E.g.:
517 warning (_ ("need music in a score"));
518 error (_f ("cannot open file: `%s'", file_name));
521 In some rare cases you may need to call `gettext ()' by hand. This
522 happens when you pre-define (a list of) string constants for later
523 use. In that case, you'll probably also need to mark these string
524 constants for translation, using `_i (STRING)'. The `_i' macro is
525 a no-op, it only serves as a marker for `xgettext'.
528 char const* messages[] = @{
529 _i ("enable debugging output"),
530 _i ("ignore lilypond version"),
537 puts (gettext (messages i));
541 See also `flower/getopt-long.cc' and `lily/main.cc'.
544 Do not use leading or trailing whitespace in messages. If you need
545 whitespace to be printed, prepend or append it to the translated
549 message ("Calculating line breaks..." + " ");
553 Error or warning messages displayed with a file name and line
554 number never start with a capital, eg,
557 foo.ly: 12: not a duration: 3
560 Messages containing a final verb, or a gerund (`-ing'-form) always
561 start with a capital. Other (simpler) messages start with a
567 Not declaring: `foo'.
571 Avoid abbreviations or short forms, use `cannot' and `do not'
572 rather than `can't' or `don't'
573 To avoid having a number of different messages for the same
574 situation, well will use quoting like this `"message: `%s'"' for all
575 strings. Numbers are not quoted:
578 _f ("cannot open file: `%s'", name_str)
579 _f ("cannot find character number: %d", i)
583 Think about translation issues. In a lot of cases, it is better to
584 translate a whole message. The english grammar must not be imposed
585 on the translator. So, instead of
588 stem at + moment.str () + does not fit in beam
594 _f ("stem at %s does not fit in beam", moment.str ())
598 Split up multi-sentence messages, whenever possible. Instead of
601 warning (_f ("out of tune! Can't find: `%s'", "Key_engraver"));
602 warning (_f ("cannot find font `%s', loading default", font_name));
608 warning (_ ("out of tune:"));
609 warning (_f ("cannot find: `%s', "Key_engraver"));
610 warning (_f ("cannot find font: `%s', font_name));
611 warning (_f ("Loading default font"));
615 If you must have multiple-sentence messages, use full punctuation.
616 Use two spaces after end of sentence punctuation. No punctuation
617 (esp. period) is used at the end of simple messages.
620 _f ("Non-matching braces in text `%s', adding braces", text)
621 _ ("Debug output disabled. Compiled with NPRINT.")
622 _f ("Huh? Not a Request: `%s'. Ignoring.", request)
626 Do not modularize too much; words frequently cannot be translated
627 without context. It is probably safe to treat most occurences of
628 words like stem, beam, crescendo as separately translatable words.
631 When translating, it is preferable to put interesting information
632 at the end of the message, rather than embedded in the middle.
633 This especially applies to frequently used messages, even if this
634 would mean sacrificing a bit of eloquency. This holds for original
635 messages too, of course.
638 en: cannot open: `foo.ly'
639 + nl: kan `foo.ly' niet openen (1)
640 kan niet openen: `foo.ly'* (2)
641 niet te openen: `foo.ly'* (3)
645 The first nl message, although grammatically and stylistically
646 correct, is not friendly for parsing by humans (even if they speak
647 dutch). I guess we would prefer something like (2) or (3).
650 Do not run make po/po-update with GNU gettext < 0.10.35
656 @node Debugging LilyPond
657 @section Debugging LilyPond
659 The most commonly used tool for debugging LilyPond is the GNU debugger
660 gdb. Use of gdb is described in this section.
662 @subsection Debugging overview
664 Using a debugger simplifies troubleshooting in at least two ways.
666 First, breakpoints can be set to pause execution at any desired point.
667 Then, when execution has paused, debugger commands can be issued to
668 explore the values of various variables or to execute functions.
670 Second, the debugger allows the display of a stack trace, which shows
671 the sequence in which functions are called and the arguments to the
672 various function calls.
675 @subsection Compiling with debugging information
677 In order to use a debugger with LilyPond, it is necessary to compile
678 LilyPond with debugging information. This is accomplished by running
679 the following commands in the main LilyPond source directory.
682 ./configure --disable-optimising
687 This will create a version of LilyPond that contains the debugging
688 information that will allow the debugger to tie the source code
689 to the compiled code.
691 You should not do @var{make install} if you want to use a debugger
692 with LilyPond. @var{make install} will strip the debugging information
693 from the LilyPond binary.
695 To set breakpoints in Scheme functions, put
698 \include "guile-debugger.ly"
701 in your input file after any scheme procedures you have defined in
702 that file. When your input file is processed, a guile prompt
703 will be displayed. At the guile prompt, you can set breakpoints with
704 the @code{break!} procedure:
707 guile> (break! my-scheme-procedure)
710 Once you have set the desired breakpoints, you exit the guile repl frame
717 When one of the scheme routines for which you have set breakpoints is
718 entered, guile will interrupt execution in a debug frame. At this point,
719 you will have access to guile debugging commands. For a listing of these
726 @subsection Typical gdb usage
728 @subsection Typical .gdbinit files
730 The behavior of gdb can be readily customized through the use of
731 @var{.gdbinit} files. A @var{.gdbinit} file is a file named
732 @var{.gdbinit} (notice the @qq{.} at the beginning of the file name)
733 that is placed in a user's home directory.
735 The @var{.gdbinit} file below is from Han-Wen. It sets breakpoints
736 for all errors and defines functions for displaying scheme objects
737 (ps), grobs (pgrob), and parsed music expressions (pmusic).
740 file lily/out/lilypond
742 b Grob::programming_error
745 print ly_display_scm($arg0)
748 print ly_display_scm($arg0->self_scm_)
749 print ly_display_scm($arg0->mutable_property_alist_)
750 print ly_display_scm($arg0->immutable_property_alist_)
751 print ly_display_scm($arg0->object_alist_)
754 print ly_display_scm($arg0->self_scm_)
755 print ly_display_scm($arg0->mutable_property_alist_)
756 print ly_display_scm($arg0->immutable_property_alist_)
760 @subsection Using Guile interactively with LilyPond
762 In order to experiment with Scheme programming in the LilyPond
763 environment, it is convenient to have a Guile interpreter that
764 has all the LilyPond modules loaded. This requires the following
767 First, define a Scheme symbol for the active module
771 #(module-define! (resolve-module '(guile-user))
772 'lilypond-module (current-module))
775 Second, place a Scheme function in the .ly file that gives an interactive Guile
782 When the .ly file is compiled, this causes the compilation to be interrupted
783 and an interactive guile prompt to appear. When the guile prompt appears,
784 the LilyPond active module must be set as the current guile module:
787 guile> (set-current-module lilypond-module)
790 Proper operation of these commands can be demonstrated by typing the name
791 of a LilyPond public scheme function to see if it's properly defined:
794 guile> fret-diagram-verbose-markup
795 #<procedure fret-diagram-verbose-markup (layout props marking-list)>
798 If the LilyPond module has not been correctly loaded, an error
799 message will be generated:
802 guile> fret-diagram-verbose-markup
803 ERROR: Unbound variable: fret-diagram-verbose-markup
804 ABORT: (unbound-variable)
807 Once the module is properly loaded, any valid LilyPond Scheme expression
808 can be entered at the interactive prompt.
810 After the investigation is complete, the interactive guile interpreter
817 The compilation of the .ly file will then continue.
819 @node Adding or modifying features
820 @section Adding or modifying features
822 When a new feature is to be added to LilyPond, it is necessary to
823 ensure that the feature is properly integrated to maintain
824 its long-term support. This section describes the steps necessary
825 for feature addition and modification.
827 @subsection Write the code
829 You should probably create a new git branch for writing the code, as that
830 will separate it from the master branch and allow you to continue
831 to work on small projects related to master.
833 Please be sure to follow the rules for programming style discussed
834 earlier in this chapter.
836 @subsection Write regression tests
838 In order to demonstrate that the code works properly, you will
839 need to write one or more regression tests. These tests are
840 typically .ly files that are found in input/regression.
842 Regression tests should be as brief as possible to demonstrate the
843 functionality of the code.
845 Regression tests should generally cover one issue per test. Several
846 short, single-issue regression tests are preferred to a single, long,
847 multiple-issue regression test.
849 Use existing regression tests as templates to demonstrate the type of
850 header information that should be included in a regression test.
852 @subsection Write convert-ly rule
854 If the modification changes the input syntax, a convert-ly rule
855 should be written to automatically update input files from older
858 convert-ly rules are found in python/convertrules.py
860 If possible, the convert-ly rule should allow automatic updating
861 of the file. In some cases, this will not be possible, so the
862 rule will simply point out to the user that the feature needs
865 @subsection Automatically update documentation, snippets, and regtests
867 convert-ly should be used to update the documentation, the snippets,
868 and the regression tests. This not only makes the necessary syntax
869 changes, it also tests the convert-ly rules.
871 The automatic updating is a three step process. First, be sure you
872 are in the top-level source directory. Then, for the
876 find Documentation/ -name '*.itely' | xargs convert-ly -e --from @qq{@var{X.Y.Z}}
880 where @var{X.Y.Z} is the version number of the last released development
883 Next, for the snippets, do:
886 find Documentation/snippets/ -name '*.ly' | xargs convert-ly -e --from @qq{@var{X.Y.Z}}
889 Finally, for the regression tests, do:
892 find input/regression/ -name '*.ly' | xargs convert-ly -e --from @qq{@var{X.Y.Z}}
896 @subsection Manually update documentation, snippets, and regtests
898 Where the convert-ly rule is not able to automatically update the inline
899 lilypond code in the documentation (i.e. if a NOT_SMART rule is used), the
900 documentation must be manually updated. The inline snippets that require
901 changing must be changed in the English version of the docs and all
902 translated versions. If the inline code is not changed in the
903 translated documentation, the old snippets will show up in the
904 English version of the documentation.
906 Where the convert-ly rule is not able to automatically update snippets
907 in Documentation/snippets/, those snippets must be manually updated.
908 Those snippets should be copied to Documentation/snippets/new. The
909 comments at the top of the snippet describing its automatice generation
910 should be removed. All translated texidoc strings should be removed.
911 The comment @qq{% begin verbatim} should be removed. The syntax of
912 the snippet should then be manually edited.
914 Where snippets in Documentation/snippets are made obsolete, the snippet
915 should be copied to Documentation/snippets/new. The comments and
916 texidoc strings should be removed as described above. Then the body
917 of the snippet should be changed to:
921 This snippet is deprecated as of version X.Y.Z and
922 will be removed from the documentation.
927 where X.Y.Z is the version number for which the convert-ly rule was
930 Update the snippet files by running:
933 scripts/auxiliar/makelsr.py
936 Where the convert-ly rule is not able to automatically update regression
937 tests, the regression tests in input/regression should be manually
940 Although it is not required, it is helpful if the developer
941 can write relevant material for inclusion in the Notation
942 Reference. If the developer does not feel qualified to write
943 the documentation, a documentation editor will be able to
944 write it from the regression tests. The text that is added to
945 or removed from the documentation should be changed only in
948 @subsection Edit changes.tely
950 An entry should be added to Documentation/changes.tely to describe
951 the feature changes to be implemented. This is especially important
952 for changes that change input file syntax.
954 Hints for changes.tely entries are given at the top of the file.
956 New entries in changes.tely go at the top of the file.
958 The changes.tely entry should be written to show how the new change
959 improves LilyPond, if possible.
961 @subsection Verify successful build
963 When the changes have been made, successful completion must be
971 When these commands complete without error, the patch is
972 considered to function successfully.
974 Developers on Windows who are unable to build LilyPond should
975 get help from a Linux or OSX developer to do the make tests.
977 @subsection Verify regression test
979 In order to avoid breaking LilyPond, it is important to verify that
980 the regression tests all succeed. This process is described in
981 @ref{Regression tests}.
983 @subsection Post patch for comments
985 For any change other than a minor change, a patch set should be
986 posted on @uref{http://codereview.appspot.com/, Rietveld} for comment.
987 This requires the use of an external package, git-cl, and an email
990 git-cl is installed by:
993 git clone git://neugierig.org/git-cl.git
996 Then, add the git-cl directory to your PATH, or create a
997 symbolic link to the git-cl and upload.py in one of your
998 PATH directories (like usr/bin). git-cl is then
999 configured by entering the command
1006 in the LilyPond git directory and answering the questions that
1007 are asked. If you do not understand the question answer with just
1010 The patch set is posted to Rietveld as follows. Ensure your changes
1011 are committed in a separate branch, which should differ from the
1012 reference branch to be used by just the changes to be uploaded.
1013 If the reference branch is to be origin/master, ensure this is
1014 up-to-date. If necessary, use git rebase to rebase the branch
1015 containing the changes to the head of origin/master. Finally,
1016 check out branch with the changes and enter the command:
1019 git cl upload <reference SHA1 ID>
1023 where <reference SHA1 ID> is the SHA1 ID of the commit to be used
1024 as a reference source for the patch. Generally, this will be the
1025 SHA1 ID of origin/master, and in that case the command
1028 git cl upload origin/master
1034 After prompting for your Google email address and password, the
1035 patch set will be posted to Rietveld.
1037 You should then announce the patch by sending
1038 an email to lilypond-devel, with a subject line
1039 starting with PATCH:, asking for comments on the patch.
1041 As revisions are made in response to comments, successive patch sets
1042 for the same issue can be uploaded by reissuing the git-cl command
1043 with the modified branch checked out.
1045 @subsection Push patch
1047 Once all the comments have been addressed, the patch can be pushed.
1049 If the author has push privileges, the author will push the patch.
1050 Otherwise, a developer with push privileges will push the patch.
1052 @subsection Closing the issues
1054 Once the patch has been pushed, all the relevant issues should be
1057 On Rietveld, the author should log in an close the issue either by
1058 using the @q{Edit Issue} link, or by clicking the circled x icon
1059 to the left of the issue name.
1061 If the changes were in response to a feature request on the Google
1062 issue tracker for LilyPond, the author should change the status to
1063 @q{Fixed_x_y_z} where the patch was fixed in version x.y.z. If
1064 the author does not have privileges to change the status, an email
1065 should be sent to bug-lilypond requesting the BugMeister to change
1068 @node Iterator tutorial
1069 @section Iterator tutorial
1071 FIXME -- this is a placeholder for a tutorial on iterators
1073 Iterators are routines written in C++ that process music expressions
1074 and sent the music events to the appropriate engravers and/or
1077 @node Engraver tutorial
1078 @section Engraver tutorial
1080 FIXME -- This is a placeholder for a tutorial on how engravers work.
1082 Engravers are C++ classes that catch music events and
1083 create the appropriate grobs for display on the page. Though the
1084 majority of engravers are responsible for the creation of a single grob,
1085 in some cases (e.g. @code{New_fingering_engraver}), several different grobs
1088 @subsection Useful methods for information processing
1090 An engraver inherits the following public methods from the Translator
1091 base class, which can be used to process listened events and acknowledged
1095 @item @code{virtual void initialize ()}
1096 @item @code{void start_translation_timestep ()}
1097 @item @code{void process_music ()}
1098 @item @code{void process_acknowledged ()}
1099 @item @code{void stop_translation_timestep ()}
1100 @item @code{virtual void finalize ()}
1103 These methods are listed in order of translation time, with
1104 @code{initialize ()} and @code{finalize ()} bookending the whole
1105 process. @code{initialize ()} can be used for one-time initialization
1106 of context properties before translation starts, whereas
1107 @code{finalize ()} is often used to tie up loose ends at the end of
1108 translation: for example, an unterminated spanner might be completed
1109 automatically or reported with a warning message.
1111 @subsection Translation process
1113 At each timestep in the music, translation proceeds by calling the
1114 following methods in turn:
1116 @code{start_translation_timestep ()} is called before any user information enters
1117 the translators, i.e., no property operations (\set, \override, etc.) or events
1118 have been processed yet.
1120 @code{process_music ()} and @code{process_acknowledged ()} are called after events
1121 have been heard, or grobs have been acknowledged. The latter tends to be used
1122 exclusively with engravers which only acknowledge grobs, whereas the former is
1123 the default method for main processing within engravers.
1125 @code{stop_translation_timestep ()} is called after all user information has been
1126 processed prior to beginning the translation for the next timestep.
1128 @subsection Preventing garbage collection for SCM member variables
1130 In certain cases, an engraver might need to ensure private Scheme variables
1131 (with type SCM) do not get swept away by Guile's garbage collector: for example,
1132 a cache of the previous key signature which must persist persist between timesteps.
1133 The method @code{virtual derived_mark () const} can be used in such cases to mark
1134 such objects as follows:
1137 Engraver_name::derived_mark ()
1139 scm_gc_mark (private_scm_member_)
1144 @subsection Listening to music events
1146 External interfaces to to the engraver are implemented by protected
1147 macros including one or more of the following:
1150 @item @code{DECLARE_TRANSLATOR_LISTENER (event_name)}
1151 @item @code{IMPLEMENT_TRANSLATOR_LISTENER (Engraver_name, event_name)}
1155 where @var{event_name} is the type of event required to provide the
1156 input the engraver needs and @var{Engraver_name} is the name of the
1159 Following declaration of a listener, the method is implemented as follows:
1162 IMPLEMENT_TRANSLATOR_LISTENER (Engraver_name, event_name)
1164 Engraver_name::listen_event_name (Stream event *event)
1166 ...body of listener method...
1170 @subsection Acknowledging grobs
1172 Some engravers also need information from grobs as they are created
1173 and as they terminate. The mechanism and methods to obtain this
1174 information are set up by the macros:
1177 @item @code{DECLARE_ACKNOWLEDGER (grob_interface)}
1178 @item @code{DECLARE_END_ACKNOWLEDGER (grob_interface)}
1181 where @var{grob_interface} is an interface supported by the
1182 grob(s) which should be acknowledged. For example, the following
1183 code would declare acknowledgers for a @code{NoteHead} grob (via the
1184 @code{note-head-interface}) and any grobs which support the
1185 @code{side-position-interface}:
1188 @code{DECLARE_ACKNOWLEDGER (note_head)}
1189 @code{DECLARE_ACKNOWLEDGER (side_position)}
1192 The @code{DECLARE_END_ACKNOWLEDGER ()} macro sets up a spanner-specific
1193 acknowledger which will be called whenever a spanner ends.
1195 Following declaration of an acknowledger, the method is coded as follows:
1199 Engraver_name::acknowledge_interface_name (Grob_info info)
1201 ...body of acknowledger method...
1205 @subsection Engraver declaration/documentation
1207 An engraver must have a public macro
1210 @item @code{TRANSLATOR_DECLARATIONS (Engraver_name)}
1214 where @code{Engraver_name} is the name of the engraver. This
1215 defines the common variables and methods used by every engraver.
1217 At the end of the engraver file, one or both of the following
1218 macros are generally called to document the engraver in the
1219 Internals Reference:
1222 @item @code{ADD_ACKNOWLEDGER (Engraver_name, grob_interface)}
1223 @item @code{ADD_TRANSLATOR (Engraver_name, Engraver_doc,
1224 Engraver_creates, Engraver_reads, Engraver_writes)}
1228 where @code{Engraver_name} is the name of the engraver, @code{grob_interface}
1229 is the name of the interface that will be acknowledged,
1230 @code{Engraver_doc} is a docstring for the engraver,
1231 @code{Engraver_creates} is the set of grobs created by the engraver,
1232 @code{Engraver_reads} is the set of properties read by the engraver,
1233 and @code{Engraver_writes} is the set of properties written by
1236 @node Callback tutorial
1237 @section Callback tutorial
1239 FIXME -- This is a placeholder for a tutorial on callback functions.
1241 @node LilyPond scoping
1242 @section LilyPond scoping
1244 The Lilypond language has a concept of scoping, ie you can do
1250 (display (+ foo 2)))
1253 @noindent with @code{\paper}, @code{\midi} and @code{\header} being
1254 nested scope inside the .ly file-level scope. @w{@code{foo = 1}} is
1255 translated in to a scheme variable definition.
1257 This implemented using modules, with each scope being an anonymous
1258 module that imports its enclosing scope's module.
1260 The reason to put some functions (@qq{builtin}) outside the .ly level,
1268 we want to reuse the built-in definitions, without changes
1269 effected in a.ly leaking into the processing of b.ly.
1271 Maintaining this scoping when one .ly file can be included in another
1272 .ly file can be challenging. A @code{define-public-toplevel} macro
1273 has been created in order to handle a difficulty caused by the modules
1274 being not the same when a .ly file is included into another.
1275 This provided a way to define all markup commands in the same module.
1276 At this time, we have found no easier way to define a function in a given
1277 module (not the current one) than to define this macro.
1279 With this architecture, the guile module system is not bypassed:
1280 module-define!, module-export! and module-ref are all guile module
1283 A second reason for using this current architecture is to avoid memory
1284 leaks that could occur when running multiple files if toplevel
1285 functions were registered permanently.