Re: Moving away from make

[olafBuddenhagen]

Hi,

On Sat, Oct 01, 2011 at 01:35:02PM +0100, Graham Percival wrote:

> I found some info on creating loops in gnu make, but it didn't seem
> possible to have loops in pure bsd make.

Well, why would it need to work with BSD Make? Gmake is available as an
optional tool pretty much everywhere -- and as you considered cmake, a
dependency an extra build tool is apparently not a problem...

-antrik-

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ragged-last-bottom should not ignore stretching on the last page

[Keith OHara]

On Sat, 08 Oct 2011 14:57:33 -0700, Xavier Scheuer  wrote:


Maybe this has been already discussed, but I do not like the current
vertical spacing behaviour of the last page when using
ragged-last-bottom (##t by default).


It has been discussed, most recently at 


For now, we can get more space on the last page by adjusting things like
  system-system-spacing #'basic-distance = #18
  page-breaking-system-system-spacing #'basic-distance = #10

Let's enter an enhancement request.

Possibly LilyPond could remember the most recently-used stretching force, and 
use that force or the flush-bottom force on the final page, whichever is less.  
Possibly we want to be able to enter stretchable space by hand in between and 
after \scores, with a variable stretchability, and use that as a more flexible 
replacement for ragged-bottom.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)

[bordage . bertrand]

Thanks Neil, I'll make two commits.  Do you want to see them both on
codereview?
Comment in lily-guile restored.


http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc
File lily/lily-guile.cc (left):

http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc#oldcode72
lily/lily-guile.cc:72: Ugh. this is not very efficient.
This was a mistake, sorry.

http://codereview.appspot.com/5233042/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Graham Percival]

On Sat, Oct 08, 2011 at 06:13:23PM +0100, Phil Holmes wrote:
> OK.  This gives:
> 
> libtool: Version mismatch error.  This is libtool 2.2.6, but the
> libtool: definition of this LT_INIT comes from libtool 2.2.6b.
> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
> libtool: and run autoconf again.
> make: *** [gen-scmconfig] Error 63
> Command barfed: cd 
> /media/IntelSSD/lilypond/git-gub/gub/target/tools/build/guile-1.8.7/libguile

Now we're into screaming and running away territory.

There's either some incompatibilty with your system libtool, or
some part of GUB is calling your system libtool when it should be
calling the GUB libtool instead, or something like that.

The "libguile" is a vitally important part.  That probably means
that we're either looking at a problem in gub/specs/guile*.py.

Nothing in guile.py looks particularly helpful to me, though.  Oh,
what exact package were you building?

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Saturday, October 08, 2011 4:23 PM
Subject: Re: GUB



On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote:
Patch for GUB git to update locations of relevant files that were 
missing.


Thanks, I'll apply it in about 90 minutes.  (I'm making a release
right now and it's doing the regtest comparison, so it needs to
build the docs and upload, then I can safely play with the repo)


make bootstrap now complete.  What next?


I /think/ it's this command you want:

python bin/gib --platform=mingw
--branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond

(all on one line)

but it might be this one instead:

bin/gub --platform=mingw
'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable'

(again, all on one line)

If both of those fail, just do:

bin/gub lilypond

that won't create the installable .exe, but it'll trigger a
download&compile of all the extra tools it needs to build lilypond
(in addition to building lilypond itself), so that'll keep you
busy for another 1-2 hours before the question of the .exe is
actually relevant.  At that point, I'll be done the release build,
so I can play around and find the exact command for a windows .exe
build.

Cheers,
- Graham



OK.  This gives:

libtool: Version mismatch error.  This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6b.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.
make: *** [gen-scmconfig] Error 63
Command barfed: cd 
/media/IntelSSD/lilypond/git-gub/gub/target/tools/build/guile-1.8.7/libguile 
&& make 
LD_LIBRARY_PATH=/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/lib 
CFLAGS='-O2 -I/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/include' 
LDFLAGS='-L/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/lib -Wl,-rpath 
-Wl,\$$ORIGIN/../lib -Wl,-rpath -Wl,/media/IntelSSD/lilypond/git-gub/gub/target/tools/root/usr/lib' 
gen-scmconfig guile_filter_doc_snarfage




--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Graham Percival]

On Sat, Oct 08, 2011 at 05:47:25PM +0100, Neil Puttock wrote:
> On 8 October 2011 17:41, Graham Percival  wrote:
> 
> > It might be nice to determine the "recommended" command to build
> > the installer for a specific binary and a specific platform -- and
> > to easily support giving it a local repository -- but I'm not
> > offering to do that.  Maybe since Phil is new to GUB, he'll be
> > energetic about fixing and documenting usage and bugs for the next
> > couple of weeks until gets jaded like us.  :)
> 
> Haha, can't we just kidnap Jan and get him to tell us? :)

He could tell us what it thinks it was, a few years ago.  I'm
willing to bet that there's at least one bug (like that shallow
clone thing) that would need fixing before it fully works.
Granted, the bugfix would almost certainly be less than 4 lines of
python code... but if I were working on this, I'd budget an hour
to do such a fix.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Neil Puttock]

On 8 October 2011 17:41, Graham Percival  wrote:

> Yeah, that's the point of using one of the other commands; you can
> specify the branch.  There's also some way of specifying the
> branch using the bin/gub method too... it'd be listed in
> lilypond.make... but I don't have it written down handy.

Heh, I couldn't work out any command which would do the same, so just
hacked it instead. :)

> It might be nice to determine the "recommended" command to build
> the installer for a specific binary and a specific platform -- and
> to easily support giving it a local repository -- but I'm not
> offering to do that.  Maybe since Phil is new to GUB, he'll be
> energetic about fixing and documenting usage and bugs for the next
> couple of weeks until gets jaded like us.  :)

Haha, can't we just kidnap Jan and get him to tell us? :)

Cheers,
Neil

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Graham Percival]

On Sat, Oct 08, 2011 at 04:46:58PM +0100, Neil Puttock wrote:
> > bin/gub --platform=mingw
> > 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable'
> 
> bin/gub mingw::lilypond-installer
> 
> is what I use.
> 
> I had to restore shallow cloning and hack specs/lilypond.py to get it
> to fetch changes from the local repository (otherwise it just builds
> master).

Yeah, that's the point of using one of the other commands; you can
specify the branch.  There's also some way of specifying the
branch using the bin/gub method too... it'd be listed in
lilypond.make... but I don't have it written down handy.

It might be nice to determine the "recommended" command to build
the installer for a specific binary and a specific platform -- and
to easily support giving it a local repository -- but I'm not
offering to do that.  Maybe since Phil is new to GUB, he'll be
energetic about fixing and documenting usage and bugs for the next
couple of weeks until gets jaded like us.  :)

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Creates a LeftBarStub that stops lyrics from bumping into the SystemStartBar. (issue 5201043)

[n . puttock]

http://codereview.appspot.com/5201043/diff/3001/scm/output-lib.scm
File scm/output-lib.scm (right):

http://codereview.appspot.com/5201043/diff/3001/scm/output-lib.scm#newcode355
scm/output-lib.scm:355: (if (eq? 0 (ly:item-break-dir grob))
Doesn't this potentially make the function unpure?

If I compare Item::break_visible ()/Item::pure_is_visible (), the main
difference is the latter doesn't call break_status_dir ().

http://codereview.appspot.com/5201043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Graham Percival]

On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote:
> Patch for GUB git to update locations of relevant files that were missing.

Thanks, pushed.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Stem direction wrong for white mensural music?

[Phil Holmes]

If I compile the following code (the start of Dufay's Ave Regina a3) with 
default settings, the stems follow modern style - some up, some down.  For 
ancient music (I'm not sure when this ended, but it certainly applies around 
the period up to 1500) the stems were always up for normal notes; - 
downstems showed other features - e.g. chromatic alteration on German 
tablatures.


It's trivial to fix with a \stemUp, but I'd suggest this is a bug.  Does 
anyone else have a view, before I add it to the tracker?


\paper {
 ragged-right = ##t
}

\score {
 <<
   \new MensuralVoice = "Cantus" {
 \override Score.BarNumber #'transparent = ##t {
   \clef "mensural-c1"
   \time 3/2
   \[ a' \breve \melisma b' \] a'1 \melismaEnd gis' \breve a' g'1 a' 
b'2 \melisma a' g' f' \melismaEnd e' \melisma f' d' c'1 b2 \melismaEnd d' 
\breve

 }
   }
   \new Lyrics \lyricsto "Cantus" {
 A -- ve, Re -- gi -- na cae -- lo -- rum
   }
 >>
}

--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Optimizes note-heads.cc and introduces robust_symbol2string. (issue 5233042)

[n . puttock]

Hi Betrand,

This should be split into two patches: one for the optimization and
another for adding robust_symbol2string lookups outside note-head.cc.

Cheers,
Neil


http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc
File lily/lily-guile.cc (left):

http://codereview.appspot.com/5233042/diff/12001/lily/lily-guile.cc#oldcode72
lily/lily-guile.cc:72: Ugh. this is not very efficient.
why have you removed this comment?

http://codereview.appspot.com/5233042/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Neil Puttock]

On 8 October 2011 16:23, Graham Percival  wrote:

> I /think/ it's this command you want:
>
> python bin/gib --platform=mingw
> --branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond
>
> (all on one line)
>
> but it might be this one instead:
>
> bin/gub --platform=mingw
> 'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable'
>
> (again, all on one line)

bin/gub mingw::lilypond-installer

is what I use.

I had to restore shallow cloning and hack specs/lilypond.py to get it
to fetch changes from the local repository (otherwise it just builds
master).

Cheers,
Neil

PS I've just posted times on the tracker, since I always have an
up-to-date mingw build to test changes.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Saturday, October 08, 2011 4:23 PM
Subject: Re: GUB



On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote:
Patch for GUB git to update locations of relevant files that were 
missing.


Thanks, I'll apply it in about 90 minutes.  (I'm making a release
right now and it's doing the regtest comparison, so it needs to
build the docs and upload, then I can safely play with the repo)


make bootstrap now complete.  What next?


I /think/ it's this command you want:

python bin/gib --platform=mingw
--branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond


Nope.


(all on one line)

but it might be this one instead:

bin/gub --platform=mingw
'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable'


Yep.


(again, all on one line)

If both of those fail, just do:

bin/gub lilypond

that won't create the installable .exe, but it'll trigger a
download&compile of all the extra tools it needs to build lilypond
(in addition to building lilypond itself), so that'll keep you
busy for another 1-2 hours before the question of the .exe is
actually relevant.  At that point, I'll be done the release build,
so I can play around and find the exact command for a windows .exe
build.

Cheers,
- Graham



Stuff doing, as above.

--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Graham Percival]

On Sat, Oct 08, 2011 at 04:03:02PM +0100, Phil Holmes wrote:
> Patch for GUB git to update locations of relevant files that were missing.

Thanks, I'll apply it in about 90 minutes.  (I'm making a release
right now and it's doing the regtest comparison, so it needs to
build the docs and upload, then I can safely play with the repo)

> make bootstrap now complete.  What next?

I /think/ it's this command you want:

python bin/gib --platform=mingw
--branch=lilypond=git.sv.gnu.org--lilypond.git-master lilypond

(all on one line)

but it might be this one instead:

bin/gub --platform=mingw
'git://git.sv.gnu.org/lilypond-doc.git?branch=release/unstable'

(again, all on one line)

If both of those fail, just do:

bin/gub lilypond

that won't create the installable .exe, but it'll trigger a
download&compile of all the extra tools it needs to build lilypond
(in addition to building lilypond itself), so that'll keep you
busy for another 1-2 hours before the question of the .exe is
actually relevant.  At that point, I'll be done the release build,
so I can play around and find the exact command for a windows .exe
build.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Friday, October 07, 2011 7:24 PM
Subject: GUB



On Fri, Oct 07, 2011 at 07:09:57PM +0100, Phil Holmes wrote:

Tail of target/tools/log/perl.log 
   tar: Unexpected EOF in archive
   tar: Unexpected EOF in archive
   tar: Error is not recoverable: exiting now
   Command barfed: tar -C
/media/IntelSSD/lilypond/git-gub/gub/target/tools/src/perl-5.10.0
--strip-component=1 -v -z -xf 
/media/IntelSSD/lilypond/git-gub/gub/downloads/perl/perl-5.10.0.tar.gz


If I try to open perl*.tar.gz I get "unexpected end-of-file".  I get
the same with the re-downloaded version from CPAN.  I'm assuming
it's corrupt. Find another one?


Let's change the subject line here.

I guess we'll need a different one... let's use perl-5.10.1
http://www.cpan.org/src/5.0/perl-5.10.1.tar.gz
since that's the least likely to break stuff that used to work in
5.10.0.

Cheers,
- Graham



Patch for GUB git to update locations of relevant files that were missing.

make bootstrap now complete.  What next?

--
Phil Holmes



0001-Updates-to-locations-of-source-files.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Markup implementation

[David Kastrup]

Not finding a more suitable thread to hook onto.

Nicolas Sceaux  writes:

> Le 17 sept. 2011 à 17:41, m...@apollinemike.com a écrit :
>> 
>> I've been toying with the idea for some time now of making markups
>> at all levels behave more like grobs.  It would require a massive
>> code rewrite, but it'd allow a much more uniform approach to exactly
>> this sort of thing (markups could, for example, issue errors like
>> grobs, which gives the user the place in the code where the bad
>> markup is).  It'd also allow for some code-duping in the footnote
>> code to go away and would allow for object-oriented references
>> between markups (which would help with spacing, advanced
>> inter-markup communication for layout stuff, etc.).
>> 
>> Would anyone be interested in co-taking this on?
>
> Hi Mike,
>
> Just writing quickly, I hope I don't write nonsense.
>
> I see several problems wrt to markups:
>
> 1) the markup / markup-list duality sucks.  I tend to implement every
> markup command twice (with its markup-lines counterparts).
>
> ==> markup and markuplines should be unified, somewhat.

How about letting markup be either, and markup lists are identified by
satisfying the list? predicate?  Seems simple enough.

> ==> it shall be possible to set some characteristics to toplevel markups
> (e.g. before/after padding and spacing stuff.)
>
> 3) mixing several lines of text and music in a single paragraph is just
> not possible.  One or two years ago, someone provided an implementation
> sketch, where a markup is given some extra context when interpreted, to
> figure out where on the current line it appears.

I am currently working with the parser to have scalars possible to be a
number of different things if properly recognizable.  That would allow
wheezing music expressions into a number of things.  For example, it
would be reasonably easy to allow \tempo { c4. [c8 8] } = 56, and have
the tempo command haul any music it encounters through a simplified
rhythmic Staff (\tempoStaff ?) without staffline and in a proper size.

> Currently, the internal representation of a markup is a simple list:
>   (markup-command arg1 arg2 ...)
> And a markup a interpreted by applying the markup-command on the args
> (plus the layout and properties special arguments).
> This is not expressive enough.  A more elaborate data structure shall
> be used.

I'd want that for markups that are not already scalars like integers,
strings, and similar, so that anything satisfying list? is interpreted
like a markup list, and everything else as what we call a "markup" so
far.

> A first step could be to move the internal representation of markups
> to C++, like grobs, music expressions, etc, with similar accessors.
> At this point the functionnality would be unchanged.  Then we could
> add some logics to deal with the mentionned problems.  But this pass
> most probably leads to backward incompatibility at some point.

I think with the changes I am currently plotting to the parser, changes
would remain rather confined.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Errors when doing 'make' for the first time when building the fonts

[Werner LEMBERG]

>> They are problematic, and they have not `always been there' :-)
> 
> Correction: using our official development environment lilydev, they
> *have* always been there.

Hmm.

>> Please use a recent version of FontForge, and please compile it
>> with `--enable-double'.
> 
> This warning is in the installation instructions, but it would be
> nice if we didn't have warnings like that.  ../configure should
> check it.  Fontforge > 20110222 even shows the status of whether you
> used --enable-double in the version string, so it would be an easy
> check to make!

Yep.  If my memory serves right, someone has even written a patch for
that already.  No time to check the archives, sorry.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Errors when doing 'make' for the first time when building the fonts

[Graham Percival]

On Sat, Oct 08, 2011 at 08:05:12AM +0200, Werner LEMBERG wrote:
> 
> > I expect most of them have always been there, but I wondered if they
> > are problematic or not?
> 
> They are problematic, and they have not `always been there' :-)

Correction: using our official development environment lilydev,
they *have* always been there.

> Please use a recent version of FontForge, and please compile it with
> `--enable-double'.

This warning is in the installation instructions, but it would be
nice if we didn't have warnings like that.  ../configure should
check it.  Fontforge > 20110222 even shows the status of whether
you used --enable-double in the version string, so it would be an
easy check to make!
http://code.google.com/p/lilypond/issues/detail?id=1637

Unfortunately we cannot (in good faith) require this until it's in
lilydev.
http://code.google.com/p/lilypond/issues/detail?id=1683

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Errors when doing 'make' for the first time when building the fonts

[David Kastrup]

Werner LEMBERG  writes:

>>> and the version string contains `-D' or `-LD', e.g.
>>>
>>>  Executable based on sources from 23:14 GMT 25-Feb-2011-ML-TtfDb-D.
>>> ^^
>>
>> Unfortunately, Ubuntu Maverick (11.04) only ships a version from 2010:
>>
>> reinhold@eeepc:~$ fontforge --version
>> Copyright (c) 2000-2010 by George Williams.
>>  Executable based on sources from 11:21 GMT 1-May-2010.
>
> At that time the additional configuration flags aren't shown in the
> version string of FontForge; this feature has been added later to the
> source code.  In other words, you have to look up Ubuntu's compilation
> script to find out whether they are using --enable-double or not.

The upcoming Oneiric (11.10) states

fontforge --version
Copyright (c) 2000-2011 by George Williams.
 Executable based on sources from 13:48 GMT 22-Feb-2011-ML.
 Library based on sources from 13:48 GMT 22-Feb-2011.
fontforge 20110222
libfontforge 20110222-ML

So you better file a problem report if you want this changed.  Not
likely for Oneiric, but you may be lucky for 12.04.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Argument scanning, take II

[David Kastrup]

Short of changing the argument syntax of music functions to something
less fuzzy altogether (implying GLISS), one needs a somewhat mixed
approach.  It is clear that something like
\relative c' c'  vs  \relative { c' }
offer some significant challenges with regard to argument parsing.
Something like c' can be interpreted in multiple ways, and Lilypond
can't back up when scanning (and humans are not all too good at double
takes either, so the syntax should not become too complex).

So one thing I'll be doing is to form one syntactic class "item" mostly
a superset of current "scalar".  Its principle characteristic is that it
can be parsed without requiring lookahead.  So something like <>
or {music} or 42 or "string" or even \repeat volta 2 {music} is fine,
but Lilypond can't look for \addlyrics or \alternative or \cm or similar
behind it.  Things like \markup { ... } or \markuplines { ... } are also
fine as well as #something which makes it possible to specify a value as
##{ 4\cm #} or #(* 4 cm) if you really want the value for 4\cm in a
place where only items are acceptable.

Now if we have an item not requiring lookahead, the parser will be able
to back it up and use it for something else as long as it can be
interpreted in the same manner.

Now to the context-dependent interpretation of function arguments: if we
want most function arguments to be grouped into the "item" class where
the parser can consider the implication by calling the predicate of the
argument rather than looking at the predicate and parsing in a specific
manner, we have the following situation:

If we have an optional argument of class "item", the parser must be able
to look at it and decide it does not want it.  But that means that
somebody else has to take it, in the indiscriminate syntactic form of
"item".  Since music lists can accommodate quite other things rather
than items, those can't escape into the surroundings of a function call.
So there is a rule that a _skipped_ optional item will usually have to
be followed by optional or mandatory arguments that can make use of an
item.  In order not to make argument matching all too nonlinear, I want
stay with the decision that once an optional argument is skipped, all
following optional arguments get skipped as well.  So the following
mandatory mandatory argument has to accept the item regardless of its
syntactic class (it may choose to barf at its type, but it can't
delegate the barfing to the parser via the normal course of a syntax
error).

So most of the parser would not bother about distinguishing items but
just take what it gets, leaving the complaints about wrong type to the
semantics.  That would make most of the code in
Lily_lexer::try_special_identifiers trying to sort an expression into
*_IDENTIFIER classes unnecessary.

Of course, some things still have to be sorted out by the parser.
Things like pitches and durations can't easily become items because
their parsing usually requires lookahead (to see whether additional
octave marks or duration dots follow).  You can force them into items by
doing something like
pitch = #(define-scheme-function (parser location p)(ly:pitch?)p)
and then using ##{\pitch c'#}.

Not all that pretty...  Anyway, the main point was that if one wants
reasonable syntactic power in music functions without too many fine
points and breakage, a considerable amount of responsibility for
interpreting material in the typical course of operation has to be
withdrawn from the parser and put into other code.  That's a tricky
challenge when one wants to integrate it with existing uses of the
hard-coded syntax.

On the plus side, things like #"xxx" and "xxx" or #3 and 3 will be
perfectly equivalent in all conceivable circumstances, so one can just
forget about "educating users" about fine points like that.  You want to
use Scheme?  Feel free.  You don't want to?  Feel free.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allows NoteColumns to be skipped over by glissandi. (issue 5242041)

[m...@apollinemike.com]

On Oct 8, 2011, at 7:26 AM, pkx1...@gmail.com wrote:

> passes make and make check only throws out
> 
> @@ -14,9 +14,9 @@
> Writing graph `#f'...digraph G {
> rankdir="LR"
> node [shape=rectangle]
> -41 [label="caching Stem.stencil\n# -> #"]
> +41 [label="caching LedgerLineSpanner.stencil\n# -> #"]
> 40 [label="caching VerticalAxisGroup.stencil\n# -> #f"]
> -39 [label="caching LedgerLineSpanner.stencil\n# -> #"]
> +39 [label="caching Stem.stencil\n# -> #"]
> 38 [label="caching StaffSymbol.stencil\n# -> #"]
> 37 [label="caching Stem.Y-extent\n# -> (-2.812186 . 0.5)"]
> 36 [label="caching Stem.length\n# -> 6.624372"]
> @@ -56,7 +56,7 @@
> 2 [label="NoteHead\n/home/jlowe/lilypond-git/lily/engraver.cc:60\ncause
> <- # 41
> +37 -> 39
> 36 -> 37
> 35 -> 36
> 34 -> 35
> 
> --snip--
> 
> James
> 

I swear that I didn't see this sorta thing before I pushed my first "cosmetic" 
patch - graphviz seems to be going berzerk now.  Are people sure that this 
sorta thing happens often?

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Errors when doing 'make' for the first time when building the fonts

[Werner LEMBERG]

>> and the version string contains `-D' or `-LD', e.g.
>>
>>  Executable based on sources from 23:14 GMT 25-Feb-2011-ML-TtfDb-D.
>> ^^
>
> Unfortunately, Ubuntu Maverick (11.04) only ships a version from 2010:
>
> reinhold@eeepc:~$ fontforge --version
> Copyright (c) 2000-2010 by George Williams.
>  Executable based on sources from 11:21 GMT 1-May-2010.

At that time the additional configuration flags aren't shown in the
version string of FontForge; this feature has been added later to the
source code.  In other words, you have to look up Ubuntu's compilation
script to find out whether they are using --enable-double or not.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Errors when doing 'make' for the first time when building the fonts

[Reinhold Kainhofer]

Am Saturday 08 October 2011, 08:29:22 schrieb Werner LEMBERG:
> If you get this error inspite of using a FontForge version configured
> with `--enable-double', we have a problem in the Metafont code which
> must be fixed.
> 
> You can check this by yourself if you say
> 
>   fontforge --version
> 
> and the version string contains `-D' or `-LD', e.g.
> 
>  Executable based on sources from 23:14 GMT 25-Feb-2011-ML-TtfDb-D.
> ^^

Unfortunately, Ubuntu Maverick (11.04) only ships a version from 2010:

reinhold@eeepc:~$ fontforge --version
Copyright (c) 2000-2010 by George Williams.
 Executable based on sources from 11:21 GMT 1-May-2010.
 Library based on sources from 03:43 GMT 29-Apr-2010.
fontforge 20100501
libfontforge 20100429


Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * Edition Kainhofer Music Publishing, http://www.edition-kainhofer.com/
 * LilyPond music typesetting software, http://www.lilypond.org/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel