Re: Error from "make doc"

[Federico Bruni]

Il giorno ven 20 mag 2016 alle 5:10, John Gourlay 
 ha scritto:
I’m trying to set up a new LilyDev development system after some 
kind of VirtualBox error that trashed my old one. I’ve run 
“make” successfully in my ~/lilypond-git/build directory, and 
lilypond runs. When I run “make doc”, however, I get errors. One 
of the messages from make directed me to look at a log file named 
suffix-lyxml.dblatex.log. This file contains the following messages 
about invalid fonts. Have I overlooked something in setting up my 
system?


Install the package lmodern:

sudo apt-get install lmodern

Added to LilyDev only one month ago:
https://github.com/fedelibre/LilyDev/commit/2d4ed72d0d0a5f1b73b71d80489524c624e5727f


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

Error from "make doc"

[John Gourlay]

I’m trying to set up a new LilyDev development system after some kind of 
VirtualBox error that trashed my old one. I’ve run “make” successfully in my 
~/lilypond-git/build directory, and lilypond runs. When I run “make doc”, 
however, I get errors. One of the messages from make directed me to look at a 
log file named suffix-lyxml.dblatex.log. This file contains the following 
messages about invalid fonts. Have I overlooked something in setting up my 
system?

John Gourlay

Build the book set list...
Build the listings...
XSLT stylesheets DocBook - LaTeX 2e (0.3.5-2)
===
Build suffix-lyxml.pdf
kpathsea:make_tex: Invalid fontname `[lmroman10-regular]', contains '['
kpathsea:make_tex: Invalid fontname `[lmromanslant10-regular]', contains '['
kpathsea:make_tex: Invalid fontname `[lmroman10-italic]', contains '['
kpathsea:make_tex: Invalid fontname `[lmroman10-bold]', contains '['
kpathsea:make_tex: Invalid fontname `[lmsans10-regular]', contains '['
xelatex failed
/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty:100: Font 
EU1/lmr/m/n/10=[lmroman10-regular]:mapping=tex-text at 10.0pt not loadable: 
Metric (TFM) file or installed font not found.
/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty:100: leading text: 
\fontencoding\encodingdefault\selectfont
/usr/share/texmf/tex/latex/tipa/t3enc.def:316: Font 
EU1/lmr/m/sl/10=[lmromanslant10-regular]:mapping=tex-text at 10.0pt not 
loadable: Metric (TFM) file or installed font not found.
/usr/share/texmf/tex/latex/tipa/t3enc.def:316: leading text: }{}
/usr/share/texmf/tex/latex/tipa/t3enc.def:316: Font 
EU1/lmr/m/it/10=[lmroman10-italic]:mapping=tex-text at 10.0pt not loadable: 
Metric (TFM) file or installed font not found.
/usr/share/texmf/tex/latex/tipa/t3enc.def:316: leading text: }{}
/usr/share/texmf/tex/latex/tipa/t3enc.def:356: Font 
EU1/lmr/bx/n/10=[lmroman10-bold]:mapping=tex-text at 10.0pt not loadable: 
Metric (TFM) file or installed font not found.
/usr/share/texmf/tex/latex/tipa/t3enc.def:356: leading text: {\bfseries
/usr/share/texmf/tex/latex/tipa/t3enc.def:357: Font 
EU1/lmss/m/n/10=[lmsans10-regular]:mapping=tex-text at 10.0pt not loadable: 
Metric (TFM) file or installed font not found.
/usr/share/texmf/tex/latex/tipa/t3enc.def:357: leading text: {\sffamily

For xetex backend Debian package lmodern is needed

Error: xelatex compilation failed


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

Custom accidental styles

[Dan Eble]

Simon,

When you have time, would you please give me an example of adding a 
user-defined accidental style? (changes in 
https://codereview.appspot.com/280510043/, as far as I can tell)

The latest lilypond doesn’t work on my source where I’ve been using this:

hymnbookCautionaryAccidentalStyle =
#(set-accidentals-properties
  #f
  `(Voice ,(make-accidental-rule 'same-octave 0))
  `(Staff ,(make-accidental-rule 'same-octave 0))
  'Staff)
— 
Dan


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

Re: crash moving DotColumn

[David Kastrup]

Thomas Morley  writes:

> 2016-05-13 12:27 GMT+02:00 David Kastrup :
>
>> This is quite explicitly the case that the assertion is supposed to
>> complain about.  Since obviously this is triggerable by user error (in
>> this case yours), maybe the assertion should be demoted to a programming
>> error.  I don't see that this can trigger except by a callback directly
>> (or indirectly) setting a value and then returning *unspecified*.  In
>> which case there does not seem the danger of recursion unless the
>> callback directly or indirectly reinstated itself.
>
> In earlier versions (<= 2.18)
>
> {
>   \override NoteHead.stencil =
> #(lambda (grob) (ly:grob-set-property! grob 'stencil point-stencil))
>   c''2
> }
>
> used to work without any warnings or errors.

Only when assertions were turned off (which they were by default until
something like 2.19.20, an abuse of the assertion mechanism).  I repeat:
I reproduced the assertion failure with the normal Ubuntu binary for
version 2.18.2.

>> So there does not seem to be much of a point in an assertion failure.
>> It does seem to constitute a programming error in general, however: a
>> callback should likely always return a specific value here in order
>> to let the caching mechanisms work properly.
>>
>> So maybe always complain about value == SCM_UNSPECIFIED here but only
>> on programming_error level?
>
> Well, one could think to make it work as in earlier versions,

No, I don't want to disable assertions by default.

> but I'm absolutely against this route, although I'm pretty sure
> there's a lot of user-code around doing so and likely in the LSR as
> well.
>
> I'd vote for the programming error.

I think that makes most sense.  I'll probably try for an unconditional
programming error with a reasonably illuminating error message.  So we'd
get messages in more situations but no abort.  Hopefully people will
then start fixing their callbacks.  Hopefully we don't have too many of
our own...

-- 
David Kastrup

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

Re: crash moving DotColumn

[Thomas Morley]

2016-05-13 12:27 GMT+02:00 David Kastrup :
> Thomas Morley  writes:
>
>> 2016-05-12 15:51 GMT+02:00 David Kastrup :
>>> Thomas Morley  writes:
>>>
 To get more space between NoteColumn and DotColumn the following used
 to work with 2.18.2

 foo =
 \override Score.DotColumn.before-line-breaking =
   #(lambda (dot-column)
 (ly:grob-set-property! dot-column 'positioning-done
   (lambda (grob)
 (ly:dot-column::calc-positioning-done grob)
 (ly:grob-translate-axis! grob 15 X


 {
   \foo
   4.
 }
>>
>> Thanks a lot for your analysis and findings.
>>
>> \version "2.19.42"
>>
>> foo =
>> \override Score.DotColumn.before-line-breaking =
>>   #(lambda (dot-column)
>> (ly:grob-set-property! dot-column 'positioning-done
>>   (lambda (grob)
>> (ly:dot-column::calc-positioning-done grob)
>> (ly:grob-translate-axis! grob 15 X)
>> #t)))
>>
>> {
>>   \foo
>>   4.
>> }
>>
>> Works indeed.
>> I could have sworn I tested this already...
>>
>> Can't think about further implications right now, too tired.
>
> This is all sort-of shaky.
>
> ly:dot-column::calc-positioning-done does
>
>
>   /*
> Trigger note collision resolution first, since that may kill off
> dots when merging.
>   */
>   if (Grob *collision = unsmob (me->get_object ("note-collision")))
> (void) collision->get_property ("positioning-done");
>
>   me->set_property ("positioning-done", SCM_BOOL_T);
>   [...]
>
> so it rather explicitly sets positioning-done to #t early on instead of
> waiting to return #t regularly (which it also does eventually),
> presumably to avoid mutual recursion.
>
> Now _your_ routine returns *unspecified* even _after_ positioning-done
> has been explicitly set to #t in the callback.
>
> This is quite explicitly the case that the assertion is supposed to
> complain about.  Since obviously this is triggerable by user error (in
> this case yours), maybe the assertion should be demoted to a programming
> error.  I don't see that this can trigger except by a callback directly
> (or indirectly) setting a value and then returning *unspecified*.  In
> which case there does not seem the danger of recursion unless the
> callback directly or indirectly reinstated itself.

In earlier versions (<= 2.18)

{
  \override NoteHead.stencil =
#(lambda (grob) (ly:grob-set-property! grob 'stencil point-stencil))
  c''2
}

used to work without any warnings or errors.
Which is exactly the sort of problem we're talking about, iiuc.

> So there does not seem to be much of a point in an assertion failure.
> It does seem to constitute a programming error in general, however: a
> callback should likely always return a specific value here in order to
> let the caching mechanisms work properly.
>
> So maybe always complain about value == SCM_UNSPECIFIED here but only on
> programming_error level?

Well, one could think to make it work as in earlier versions, but I'm
absolutely against this route, although I'm pretty sure there's a lot
of user-code around doing so and likely in the LSR as well.

I'd vote for the programming error.

Sorry for late reply,
  Harm

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

issue 4857: update doc tarball link (issue 296210043 by fedel...@gmail.com)

[fedelogy]

Reviewers: ,

Description:
issue 4857: update doc tarball link

This completes issue 4833.

Please review this at https://codereview.appspot.com/296210043/

Affected files (+1, -1 lines):
  M scripts/build/create-weblinks-itexi.py


Index: scripts/build/create-weblinks-itexi.py
diff --git a/scripts/build/create-weblinks-itexi.py  
b/scripts/build/create-weblinks-itexi.py
index  
e529ca7327cdd5a6a4ff2a36a861bd7a413a3b7b..e631c27fd8b43a5e7c75792be202237fadfb9d3d  
100644

--- a/scripts/build/create-weblinks-itexi.py
+++ b/scripts/build/create-weblinks-itexi.py
@@ -554,7 +554,7 @@ def make_regtest_links(name, version, lang):
 getTrans("PDF of lilypond-book regtests for ", lang)+version)

 def make_doctarball_links(name, version, lang):
-url = depth + "download/binaries/documentation/lilypond-"
+url = depth + "downloads/binaries/documentation/lilypond-"
 # ugly FIXME, but proper build number support isn't Critical.
 url += version + "-1"
 url += ".documentation.tar.bz2"



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

Re: Whither doc tarballs?

[Federico Bruni]

Thanks, I forgot to update the link in 
scripts/build/create-weblinks-itexi.py

I'll fix it right now

Il giorno gio 19 mag 2016 alle 18:09, Jon Ciesla  
ha scritto:

Here: http://lilypond.org/development.html

Thanks!

On Thu, May 19, 2016 at 9:40 AM, Federico Bruni  
wrote:
Il giorno gio 19 mag 2016 alle 16:33, Federico Bruni 
 ha scritto:
Il giorno gio 19 mag 2016 alle 16:25, Jon Ciesla 
 ha scritto:

http://lilypond.org/download/binaries/documentation/lilypond-2.19.42-1.documentation.tar.bz2

is 404, for all versions.  Have these moved?


Yes, replace download with downloads.

Where did you get that link?
I didn't test if the --doc option of the installer works fine...



Now I remember, you maintain the Fedora package.
Yes, you should change this line:
http://pkgs.fedoraproject.org/cgit/rpms/lilypond-doc.git/tree/lilypond-doc.spec#n9

Why we changed it to downloads:
https://sourceforge.net/p/testlilyissues/issues/4833/








--
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie



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

Re: Whither doc tarballs?

[Jon Ciesla]

Here: http://lilypond.org/development.html

Thanks!

On Thu, May 19, 2016 at 9:40 AM, Federico Bruni  wrote:

> Il giorno gio 19 mag 2016 alle 16:33, Federico Bruni 
> ha scritto:
>
>> Il giorno gio 19 mag 2016 alle 16:25, Jon Ciesla 
>> ha scritto:
>>
>>>
>>> http://lilypond.org/download/binaries/documentation/lilypond-2.19.42-1.documentation.tar.bz2
>>>
>>> is 404, for all versions.  Have these moved?
>>>
>>
>> Yes, replace download with downloads.
>>
>> Where did you get that link?
>> I didn't test if the --doc option of the installer works fine...
>>
>>
> Now I remember, you maintain the Fedora package.
> Yes, you should change this line:
>
> http://pkgs.fedoraproject.org/cgit/rpms/lilypond-doc.git/tree/lilypond-doc.spec#n9
>
> Why we changed it to downloads:
> https://sourceforge.net/p/testlilyissues/issues/4833/
>
>
>
>
>


-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: Whither doc tarballs?

[Federico Bruni]

Il giorno gio 19 mag 2016 alle 16:33, Federico Bruni 
 ha scritto:
Il giorno gio 19 mag 2016 alle 16:25, Jon Ciesla 
 ha scritto:

http://lilypond.org/download/binaries/documentation/lilypond-2.19.42-1.documentation.tar.bz2

is 404, for all versions.  Have these moved?


Yes, replace download with downloads.

Where did you get that link?
I didn't test if the --doc option of the installer works fine...



Now I remember, you maintain the Fedora package.
Yes, you should change this line:
http://pkgs.fedoraproject.org/cgit/rpms/lilypond-doc.git/tree/lilypond-doc.spec#n9

Why we changed it to downloads:
https://sourceforge.net/p/testlilyissues/issues/4833/





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

Re: Whither doc tarballs?

[Federico Bruni]

Il giorno gio 19 mag 2016 alle 16:25, Jon Ciesla  
ha scritto:

http://lilypond.org/download/binaries/documentation/lilypond-2.19.42-1.documentation.tar.bz2

is 404, for all versions.  Have these moved?


Yes, replace download with downloads.

Where did you get that link?
I didn't test if the --doc option of the installer works fine...




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

Whither doc tarballs?

[Jon Ciesla]

http://lilypond.org/download/binaries/documentation/lilypond-2.19.42-1.documentation.tar.bz2

is 404, for all versions.  Have these moved?

Thanks!

-Jon

-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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