David Kastrup [Tue, 7 Jul 2015 12:38:26 +0000 (14:38 +0200)]
Issue 4419: Engraving ends too early
This is a followup on the solution for issue 2010 that was too eager
killing off unrelated iterators when an iterator in the vicinity of a
Lyric_combine_music_iterator died.
The salient point is to have Simultaneous_music_iterator::process_music
check for pending_moment () going from finite to infinite when
iterating, signifying the loss of an iterator defining an end point.
David Kastrup [Thu, 25 Jun 2015 16:08:34 +0000 (18:08 +0200)]
Issue 4474/3: Make all of ly-syntax-constructors.scm a separate module
That allows putting all the constructors into exported symbols while
keeping local definitions private. Since we access this module only
from C++, not even the exported symbols appear in a normal LilyPond
session.
David Kastrup [Wed, 1 Jul 2015 20:49:30 +0000 (22:49 +0200)]
Issue 4472: Let \mark and Mark_engraver act consistently
Both will now accept a label meeting the number-or-markup? predicate.
Previously, \mark accepted any expression and Mark_engraver dealt only
partly with them.
David Kastrup [Mon, 6 Jul 2015 16:27:50 +0000 (18:27 +0200)]
Fix wrong-number-of-args error in Music_function::call
When a music function called via Scheme wanted to report a bad argument
type, it instead triggered a Scheme error wrong-number-of-args because
of a spurious `location' argument. This was an oversight in issue 4455
and was converted into equivalently bad code by several other issues
touching this code.
James Lowe [Sun, 28 Jun 2015 12:16:56 +0000 (13:16 +0100)]
Doc: NR Update information for modern-cautionary
Issue 4437
Reworded section on modern-cautionary
accidental style. The 'cautionary-style'
property was deprecated in version 2.11.5
but the manual had not been updated.
Also added similar note to
neo-modern-cautionary as it applies
there too.
Dan Eble [Mon, 22 Jun 2015 14:58:27 +0000 (10:58 -0400)]
Issue 3605: bagpipe corrections and additions
Contributed by Julia Meihoefer and Oliver Briede:
Our corrections are based on research we did for Julia's Bachelor
Thesis in computer engineering 'Identification, notation and
reproduction of the Great Highland Bagpipe sound' in August 2014.
This change does NOT include any conversion rules for the the
following noteworthy changes:
* remove \gcatcha, \gcatchb ... \gcatche
* rename \dgrip to \bgrip
* rename \dtaor to \btaor
David Kastrup [Sun, 28 Jun 2015 13:50:29 +0000 (15:50 +0200)]
Issue 4466: Provide a-natural etc in english notenames
This complements the existing long note names a-sharp etc. While the
diff appears like invalidating notenames a b c ..., the redefined
entries were duplicates previously, so a b c remain valid (and are the
principal version printed by \displayLilyMusic).
David Kastrup [Tue, 30 Jun 2015 09:44:50 +0000 (11:44 +0200)]
Issue 4468/2: Avoid skyline interruptions at line caps
Line caps are made to slightly overhang into their corresponding line in
order to avoid numerics causing a gap. Such a gap is unlikely to be
relevant for positioning but is ungainly when using -ddebug-skylines.
David Kastrup [Mon, 29 Jun 2015 22:04:49 +0000 (00:04 +0200)]
Issue 4468/1: stencil-integrate.cc: root out "slopes"
They are quite unsuitable for the computational geometry performed here.
Their use rendered the code inefficient, obtuse, and unreliable.
Contains several other fixes like removing duplicate calculations and
wrong values. The C++ <complex> module is no longer used. It had only
been used for calculating sin and cos in an obscure manner.
David Kastrup [Thu, 25 Jun 2015 11:04:50 +0000 (13:04 +0200)]
Issue 4462/1: Create a module variable access system for C++
This replaces the previous "memoizing" ly_lily_module_constant with a
rather rigid system for importing/exporting/accessing module variables.
As opposed to the system used by ly_lily_module_constant, access will
continue to go through the respective module variables, making it
possible to also write to the respective variables. In addition, this
ensures that any changes to the variables from the Scheme side will get
properly reflected in the C++ side, allowing for redefinitions when
debugging.
In a nutshell, ly_lily_module_constant ("ly:music?") would generally be
replaced with Lily::ly_music_p, a declaration of it looking like
extern Variable ly_music_p;
would be placed in namespace Lily in lily/include/lily-imports.hh, and a
corresponding definition
Variable ly_music_p ("ly:music?");
in namespace Lily in lily/lily-imports.cc . The type Scm_module where
variables are organized can use pre-existing modules (in which case it
is initialized by calling the member function import ()) or are can
bring up a fresh module (in which case it is initialized by calling the
member function boot ()). The startup is done in lily/guile-init.cc .
Since one of the most frequent uses of imported variables is for
function calls, the Scm_variable type (underlying the module-local
Variable type) has operator () defined to allow calling as a function.
David Kastrup [Fri, 26 Jun 2015 10:20:01 +0000 (12:20 +0200)]
Issue 4463: Fix regression with -ddebug-parser
Running
lilypond -ddebug-parser scheme-sandbox
led to the error message
scm/lily.scm:1056:21: In procedure value->lily-string in expression (ly:parse-file file-name):
scm/lily.scm:1056:21: Wrong number of arguments to #<procedure value->lily-string (arg)>
This was an obvious oversight in the implementation of issue 4442.
Paul Morris [Wed, 10 Jun 2015 04:16:16 +0000 (00:16 -0400)]
Issue 4418/2 add and use new whiteout function
scm/stencil.scm: redefine the whiteout function
so that it approximates the stencil's outline by
creating multiple displaced copies of the stencil.
Rename the previous whiteout function 'whiteout-box'.
scm/define-grob-properties.scm: define two
properties to go with the two whiteout functions.
lily/grob.cc: use the new whiteout functions and
properties.
scm/define-markup-commands.scm: define markup
commands to go with the two whiteout functions.
David Kastrup [Fri, 12 Jun 2015 07:51:40 +0000 (09:51 +0200)]
Issue 4443: Don't pass current parser/location into #{...#} call
The construct #{...#} generates a call to a function embedded-lilypond.
After issue 4422, this call passed (*parser*)/(*location*) arguments
instead of the previous parser/location arguments needed for accessing
the respective values in a different lexical environment. But since the
respective values are stored in GUILE fluids rather than in lexical
variables now, they are already passed implicitly and unnecessary as
function parameters.
David Kastrup [Fri, 12 Jun 2015 11:41:11 +0000 (13:41 +0200)]
Issue 4442/7: Stop maintaining "parser" variable
When invoking a parser, the global "parser" variable was temporarily
pointing to the parser. This mechanism was somewhat awkward and with
problems of its own. Since an active parser maintains the %parser fluid
now, we can forego maintaining the "parser" variable altogether.