pushing to a new branch on server
Hi all Last week I've worked on updating the italian translation. I always work on the translation branch and push to the translation branch. Sometimes I need to push my changes to a temporary branch on the server (because I want to make a backup before the weekend or finish the work at home during the weekend). I could not push to a /dev/name/branch name. I had to use a short name without slashes: git push origin translation:fedelibre-doc-it while the following did not work: git push origin translation:/dev/fede/doc-it Not a big deal.. but I'd be curious to know what's the mistake. Thanks Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for May 31st
Hello, Here is the current patch countdown list. The next countdown will be on June 2nd. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ __ Push: 4858 Let define-session-public place variables natively into parser - David Kastrup https://sourceforge.net/p/testlilyissues/issues/4858 http://codereview.appspot.com/300110043 4854 Set minimum size dots for text spanner to be round. - Carl Sorensen https://sourceforge.net/p/testlilyissues/issues/4854 http://codereview.appspot.com/295210043 Countdown: 4861 Update texinfo.tex from upstream - Masamichi Hosoda https://sourceforge.net/p/testlilyissues/issues/4861 http://codereview.appspot.com/300820043 Review: No patches in review at this time. New: 4870 Delay import of `midi' module - Werner Lemberg https://sourceforge.net/p/testlilyissues/issues/4870 http://codereview.appspot.com/297420043 4869 Added non-default property to KeySignature grob - Steven Weber https://sourceforge.net/p/testlilyissues/issues/4869 http://codereview.appspot.com/300850043 4868 Add limited embedding support for OpenType/CFF Collection (OTC) fonts - Masamichi Hosoda https://sourceforge.net/p/testlilyissues/issues/4868 http://codereview.appspot.com/301820043 4867 Ignore some major OpenType/CFF Collection (OTC) fonts - Masamichi Hosoda https://sourceforge.net/p/testlilyissues/issues/4867 http://codereview.appspot.com/298320043 4865 Move translator initializations to X::boot () - David Kastrup https://sourceforge.net/p/testlilyissues/issues/4865 http://codereview.appspot.com/294650043 4862 Merge get_acknowledger and get_end_acknowledger - David Kastrup https://sourceforge.net/p/testlilyissues/issues/4862 http://codereview.appspot.com/296260043 4860 Add halfopenvertical to script.scm - Carl Sorensen https://sourceforge.net/p/testlilyissues/issues/4860 http://codereview.appspot.com/297340043 4751 Import Philomelos enhancements to musicxml2ly - John Gourlay https://sourceforge.net/p/testlilyissues/issues/4751 http://codereview.appspot.com/295120043 Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
On 16-05-30 01:31 AM, Knut Petersen wrote: Is there anybody out there who succeeds to build the current lilypond documentation on a 64 bit linux machine with a 64 bit toolchain? Please report cpu as well as versions of gcc and guile. Linux Sherlock 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux colin@Sherlock ~$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) colin@Sherlock ~$ guile -v Guile 1.8.8 To those who see "make doc" fail at orchestra.ly: Please report cpu as well as versions of gcc and guile. Please also send the output of After a bit of poking around, I find that orchestra.ly needs "\time 6/8" added at line 327 harplh and at line 334 dynamics. With those edits, make QUIET_BUILD=1 -j3 LANGS='' WEB_LANGS='' doc succeeds reliably, and without them it fails reliably. HTH, and if not, apologies for the noise Colin -- The man who is a pessimist before forty-eight knows too much; if he is an optimist after it, he knows too little. -Mark Twain, author (1835-1910) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Silently depressed keys
On May 29, 2016, at 03:53 , David Kastrup wrote: > > "minimum velocity" is 0. Midi implementations use this as an alternate > representation of key release since this leads to shorter Midi messages > and faster transmission than the "proper" key release event. > > You need at least 1 to make a distinctive event. That is helpful. Here’s something else I could use help with. The person who wrote Midi_note decided that a negative (“unknown”?) Audio_dynamic should be treated as 90/127, whereas the person who wrote Midi_dynamic decided that a negative Audio_dynamic should be treated as 100/127. Unless there is a good reason for this inconsistency, I would like to move the default into Audio_dynamic itself; but I’m not sure which value to use. Are these specific values important, or are they just two individuals’ fingers in the wind? Apart from that, I think it would be a good idea to rename the music property midi-extra-velocity to relative-volume and change its range to [-1,1] to match the scale of the context property dynamicAbsoluteVolumeFunction instead of being MIDI-specific. Are there any objections? — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Make additional changes to the new version of musicxml2ly (issue 297370043 by j...@weathervanefarm.net)
Reviewers: , Message: A few days a go I uploaded a new patch for issue 4751, "Import Philolelos enhancements to musicxml2ly", the first patch for which had been flagged as needing work. I hope this version works better. Description: Make additional changes to the new version of musicxml2ly imported from the Philomelos project. The changes are also uploaded to the branch dev/johngourlay/issue-4751. After these changes I can run the following build commands without error: make make test-clean make test make check The problems with the earlier patch were due to my misunderstanding of the make test dependencies. I did not run make test-clean, and so I did not see that some musicxml regression tests did not run. Please review this at https://codereview.appspot.com/297370043/ Affected files (+3760, -2169 lines): M python/musicexp.py M python/musicxml.py A python/musicxml2ly_conversion.py A python/utilities.py M scripts/musicxml2ly.py ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4868: Add limited embedding support for OpenType/CFF Collection (OTC) fonts (issue 301820043 by truer...@gmail.com)
LGTM, thanks! https://codereview.appspot.com/301820043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James writes: > David if you need anything from any of these outputs on my machines > here at work, let me know and I'll do whatever tests or output that > you think might be helpful. > > Hope the Nettle-reaping was successful. Scything. There is nothing to reap, they just have to be kept from proliferating within the meadows. Somewhat annoyingly, when scything on an active meadow, some horses will indeed get behind you and start short work on the results. Apparently detaching them from the ground is the most tedious part of eating them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
On 30/05/16 16:59, David Kastrup wrote: James writes: Hello On 30/05/16 15:06, David Kastrup wrote: James writes: Zipped Valgrind output of both OSes is attached to this email or can be obtained here: https://drive.google.com/file/d/0B9nZ5LHV2Ds6dGU5VTJjOGNlSm8/view?usp=sharing By far most complaints are in the GC marking phase and complain about uninitialized values in stack allocations. That's perfectly to be expected with a conservative garbage collector, however. I'm taking a look at the heap-related complaints though since on the heap, GC should not occur conservatively (not in Guile-1 at least). In the meantime I have installed 32bit LilyDev at work and am currently setting all that up and will run a 'staging merge' now - this will bring staging and master up to date hopefully, verify that LilyDev works for me (i.e. I have it all configured properly - nice job by the way Federico, I haven't used LD for a while). If it does then I guess I can get some of these new patches tested and moved along - but that may be tomorrow, it just depends how much time I get today. Oh Well, Lilydev complains about the same make doc error when (I use -j5) - I am 99% sure, I haven't time now to look at the full output, but the messages generated on the console are so familiar that I am almost sure it is the same thing. I have to leave now for Home. To all those waiting on their patches I guess you'll have to be patient a bit more. I'll do the countdown as promised tomorrow but I still cannot push - at least not reliably. David if you need anything from any of these outputs on my machines here at work, let me know and I'll do whatever tests or output that you think might be helpful. Hope the Nettle-reaping was successful. James Ok, ==15261== 3774 errors in context 100 of 100: ==15261== Conditional jump or move depends on uninitialised value(s) ==15261==at 0x4E923D3: scm_i_sweep_card (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E91255: scm_i_sweep_some_cards (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E916EC: scm_i_sweep_some_segments (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E907AE: scm_gc_for_newcell (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4EDDF3E: scm_c_make_vector (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E9C62C: ??? (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x59D525: Scheme_hash_table::make_smob() (scm-hash.cc:29) ==15261==by 0x643B51: add_acknowledger(scm_unused_struct*, char const*, Protected_scm&) (translator.cc:238) ==15261==by 0x72DEAD: Dots_engraverrhythmic_head_ack_adder() (dots-engraver.cc:59) ==15261==by 0x4DDEF8: ly_init_ly_module() (guile-init.cc:57) ==15261==by 0x76710E: call_trampoline(void*) (lily-modules.cc:61) ==15261==by 0x4E8DC01: scm_c_with_fluid (in /usr/lib/libguile.so.17.4.0) ==15261== Uninitialised value was created by a stack allocation ==15261==at 0x4EDC7C4: scm_c_catch (in /usr/lib/libguile.so.17.4.0) looks like a red flag concerning the relation to the patch in question.. It's a bit strange that all reported calls seem to be from the same Dots_engraverrhythmic_head_ack_adder but then this may not mean more than garbage collection being triggered inside of Dots_engraverrhythmic_head_ack_adder coincidentally during startup and it is just bad/good luck that this happens/not at this location on 64/32 bit. But when it happens, we may have a problem. Now on to disassembly and/or code analysis. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James writes: > Hello > > On 30/05/16 15:06, David Kastrup wrote: >> James writes: >> >>> Zipped Valgrind output of both OSes is attached to this email or can >>> be obtained here: >>> >>> https://drive.google.com/file/d/0B9nZ5LHV2Ds6dGU5VTJjOGNlSm8/view?usp=sharing >> By far most complaints are in the GC marking phase and complain about >> uninitialized values in stack allocations. That's perfectly to be >> expected with a conservative garbage collector, however. I'm taking a >> look at the heap-related complaints though since on the heap, GC should >> not occur conservatively (not in Guile-1 at least). >> > In the meantime I have installed 32bit LilyDev at work and am > currently setting all that up and will run a 'staging merge' now - > this will bring staging and master up to date hopefully, verify that > LilyDev works for me (i.e. I have it all configured properly - nice > job by the way Federico, I haven't used LD for a while). > > If it does then I guess I can get some of these new patches tested and > moved along - but that may be tomorrow, it just depends how much time > I get today. Ok, ==15261== 3774 errors in context 100 of 100: ==15261== Conditional jump or move depends on uninitialised value(s) ==15261==at 0x4E923D3: scm_i_sweep_card (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E91255: scm_i_sweep_some_cards (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E916EC: scm_i_sweep_some_segments (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E907AE: scm_gc_for_newcell (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4EDDF3E: scm_c_make_vector (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x4E9C62C: ??? (in /usr/lib/libguile.so.17.4.0) ==15261==by 0x59D525: Scheme_hash_table::make_smob() (scm-hash.cc:29) ==15261==by 0x643B51: add_acknowledger(scm_unused_struct*, char const*, Protected_scm&) (translator.cc:238) ==15261==by 0x72DEAD: Dots_engraverrhythmic_head_ack_adder() (dots-engraver.cc:59) ==15261==by 0x4DDEF8: ly_init_ly_module() (guile-init.cc:57) ==15261==by 0x76710E: call_trampoline(void*) (lily-modules.cc:61) ==15261==by 0x4E8DC01: scm_c_with_fluid (in /usr/lib/libguile.so.17.4.0) ==15261== Uninitialised value was created by a stack allocation ==15261==at 0x4EDC7C4: scm_c_catch (in /usr/lib/libguile.so.17.4.0) looks like a red flag concerning the relation to the patch in question.. It's a bit strange that all reported calls seem to be from the same Dots_engraverrhythmic_head_ack_adder but then this may not mean more than garbage collection being triggered inside of Dots_engraverrhythmic_head_ack_adder coincidentally during startup and it is just bad/good luck that this happens/not at this location on 64/32 bit. But when it happens, we may have a problem. Now on to disassembly and/or code analysis. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Added property non-default to KeySignature (issue 300840043 by pant...@gmail.com)
On 2016/05/30 15:29:42, panteck wrote: Are you recommending that I close this issue, apply my patch to a development branch in git, and try again? "apply my patch to a development branch in git" may be as easy as git checkout -b non-default-prop master git branch --set-upstream-to=origin/master Since there isn't a SourceForge issue yet, nobody really has taken action on the patch. So it's probably easiest to do that and start over. https://codereview.appspot.com/300840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Added property non-default to KeySignature (issue 300840043 by pant...@gmail.com)
On 2016/05/30 05:09:54, dak wrote: On 2016/05/29 21:44:42, panteck wrote: > On 2016/05/29 20:09:52, dak wrote: > > On 2016/05/29 20:03:03, panteck wrote: > > > On 2016/05/29 19:03:56, dak wrote: > > > > On 2016/05/29 18:17:58, panteck wrote: > > > > > On 2016/05/29 17:39:39, dak wrote: > > > > > > > > > > Which git-cl are you using? The one used by LilyPond puts up an issue > > > > > (assuming > > > > > > correct configuration and pressing ENTER when asked for an issue > > number). > > > > > > > > > > I'm assuming newest - I did a git pull prior in the git-cl folder prior > to > > > > > running it. That's not to say I didn't screw up something else along > the > > > way. > > > > > > > > Which repository? > > > > > > git://github.com/gperciva/git-cl.git > > > > Ok, that's correct. Sorry for the noise. What does > > > > git cl status > > > > state in your LilyPond work directory? > > Branches associated with reviews: > dev/local_working: None > master: 300840043 > > Current branch: master > Tracker issue: None > Rietveld issue: 300840043 (https://codereview.appspot.com/300840043) > Issue description: > Added property non-default to KeySignature Added the property non- > default to the KeySignature grob, and updated the grob definition to > indicate that it works for both Clefs and KeySignatures now. Well, be sure to disassociate your master branch with this issue before your next submission or it will end up in the same place. You should submit from a branch of its own. Anyway, I can only guess that your command did not complete, either because you did not answer the prompt for the issue number or it wasn't able to contact Sourceforge successfully. Are you recommending that I close this issue, apply my patch to a development branch in git, and try again? https://codereview.appspot.com/300840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
Hello On 30/05/16 15:06, David Kastrup wrote: James writes: Zipped Valgrind output of both OSes is attached to this email or can be obtained here: https://drive.google.com/file/d/0B9nZ5LHV2Ds6dGU5VTJjOGNlSm8/view?usp=sharing By far most complaints are in the GC marking phase and complain about uninitialized values in stack allocations. That's perfectly to be expected with a conservative garbage collector, however. I'm taking a look at the heap-related complaints though since on the heap, GC should not occur conservatively (not in Guile-1 at least). In the meantime I have installed 32bit LilyDev at work and am currently setting all that up and will run a 'staging merge' now - this will bring staging and master up to date hopefully, verify that LilyDev works for me (i.e. I have it all configured properly - nice job by the way Federico, I haven't used LD for a while). If it does then I guess I can get some of these new patches tested and moved along - but that may be tomorrow, it just depends how much time I get today. regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James writes: > Zipped Valgrind output of both OSes is attached to this email or can > be obtained here: > > https://drive.google.com/file/d/0B9nZ5LHV2Ds6dGU5VTJjOGNlSm8/view?usp=sharing By far most complaints are in the GC marking phase and complain about uninitialized values in stack allocations. That's perfectly to be expected with a conservative garbage collector, however. I'm taking a look at the heap-related complaints though since on the heap, GC should not occur conservatively (not in Guile-1 at least). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
David Kastrup writes: > Thomas Morley writes: > >> 2016-05-29 21:03 GMT+02:00 Thomas Morley : >> >>> I'll now checkout a fresh branch from master, apply Hosoda-san's patch from >>> https://codereview.appspot.com/298320043/ >>> change orchestra.ly as before. >>> Try a full `make doc' and report back later. >> >> >> This failed quite early in the regtest with the already mentioned files, >> namely: >> typography-demo.ly >> utf-8.ly >> profile-property-access.ly >> one-line-breaking.ly >> one-line-auto-height-breaking.ly >> one-line-breaking.ly >> >> All using japanese or including typography-demo.ly, although >> Hosoda-san's patch was applied. >> >> But again, I've a successful run for the english-only doc with all >> japenese commented and a changed orchestra.ly. >> I attach the revised orchestra.ly if someone wans to try. Maybe it >> even helps to track down the problem. > > I could just tear out my hairs here. I have little doubt that you are > onto something (and it seems like Werner has a lead on how to fix it) > but it just does not make sense in connection with the exact commit Knut > pinpointed as starting his problems. > > It may or may not be the blocker for James, either. At any rate, I am > currently going through the C++ standard with respect of initialization > orders and stuff, and I hope to get to tackle the problem Knut has been > focusing on eventually. > > It does seem utterly strange that both failures should occur on the same > file of documentation building. Does it happen early in the build? Ok, I manage to get Changing working directory to: `./out-www' Processing `orchestra.ly' Parsing... Interpreting music...ERROR: Wrong type (expecting exact integer): (denies Voice) now. That clearly is not font-related. It also clearly is garbage collection related: (denies Voice) is part of a context modification. The interesting thing is that a) most exact integers (as well as '() and #f) in ranges interesting to LilyPond are immediate values. So why is garbage collection even involved? Most likely, we have a _callback_ here (or an unpure/pure-container) that is being overwritten. b) \denies Voice is only present in dak@lola:/usr/local/tmp/lilypond$ git grep '\\denies "\?Voice"\?' ly/engraver-init.ly: \denies "Voice" ly/engraver-init.ly: \denies "Voice" ly/engraver-init.ly: \denies "Voice" ly/engraver-init.ly: \denies "Voice" ly/engraver-init.ly: \denies "Voice" ly/engraver-init.ly: \denies "Voice" ly/engraver-init.ly: \denies "Voice" ly/performer-init.ly: \denies Voice ly/performer-init.ly: \denies Voice ly/performer-init.ly: \denies Voice ly/performer-init.ly: \denies Voice ly/performer-init.ly: \denies Voice ly/performer-init.ly: \denies Voice ly/performer-init.ly: \denies Voice which likely is read in before any problem is triggered. It does not appear like the context definition is copied around a lot in orchestra.ly but there are several \layout blocks which create a copy of the current default layout. I don't see anything obvious otherwise which could steal an allocated block. Unfortunately, the error message is essentially useless for figuring out the source of the problem. valgrind might be more fruitful. Sigh. I think I have a lead on the problem, and at least I get the same failure now, so I can check. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Warn on solitary \! ?
Hello,
I was just wondering if we might want to emit a warning if there is a \!
without a (de)crescendo before. It’s likely that the latter has only
been forgotten.
\version "2.19.42"
\displayMusic {
2 4\!
}
=>
(make-music
'SequentialMusic
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 1))
(make-music
'NoteEvent
'articulations
(list (make-music
'CrescendoEvent
'span-direction
1))
'duration
(ly:make-duration 2
Happy to hear your opinions,
Simon
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
> Is there anybody out there who succeeds to build the current lilypond > documentation on a 64 bit linux machine with a 64 bit toolchain? > Please report cpu as well as versions of gcc and guile. Although my environment is not linux, I've succeeded `make doc' by HEAD of master branch. Of course, Japanese documents are also fine. Here's my environment. Cygwin 64 bit gcc 5.3.0 Guile 1.8.8 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: OTC support
>> I've opened a bug report to discuss whether ghostscript will add OTC >> support, and whether the gs team is going to extend Type42 support >> to cover generic SFNTs (i.e., CFF flavour also). >> >> http://bugs.ghostscript.com/show_bug.cgi?id=696808 > > And there's a quick reply: No OTC support in gs, instead we should > rather extract the `CFF ' table from the OTC subfont and embed it as a > Type 2 font as we already do for normal OTFs. I've created limited OTC support. https://sourceforge.net/p/testlilyissues/issues/4868/ It adds limited embedding support for OTC fonts which have `*.otc' filename extension. It only supports `*.otc' filenames. So if you would like to try it, you can create symlinks like followings. $ ln -s NotoSansCJK.ttc NotoSansCJK.otc $ fc-cache -v ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
Thomas Morley writes: > 2016-05-29 21:03 GMT+02:00 Thomas Morley : > >> I'll now checkout a fresh branch from master, apply Hosoda-san's patch from >> https://codereview.appspot.com/298320043/ >> change orchestra.ly as before. >> Try a full `make doc' and report back later. > > > This failed quite early in the regtest with the already mentioned files, > namely: > typography-demo.ly > utf-8.ly > profile-property-access.ly > one-line-breaking.ly > one-line-auto-height-breaking.ly > one-line-breaking.ly > > All using japanese or including typography-demo.ly, although > Hosoda-san's patch was applied. > > But again, I've a successful run for the english-only doc with all > japenese commented and a changed orchestra.ly. > I attach the revised orchestra.ly if someone wans to try. Maybe it > even helps to track down the problem. I could just tear out my hairs here. I have little doubt that you are onto something (and it seems like Werner has a lead on how to fix it) but it just does not make sense in connection with the exact commit Knut pinpointed as starting his problems. It may or may not be the blocker for James, either. At any rate, I am currently going through the C++ standard with respect of initialization orders and stuff, and I hope to get to tackle the problem Knut has been focusing on eventually. It does seem utterly strange that both failures should occur on the same file of documentation building. Does it happen early in the build? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
2016-05-29 21:03 GMT+02:00 Thomas Morley :
> I'll now checkout a fresh branch from master, apply Hosoda-san's patch from
> https://codereview.appspot.com/298320043/
> change orchestra.ly as before.
> Try a full `make doc' and report back later.
This failed quite early in the regtest with the already mentioned files, namely:
typography-demo.ly
utf-8.ly
profile-property-access.ly
one-line-breaking.ly
one-line-auto-height-breaking.ly
one-line-breaking.ly
All using japanese or including typography-demo.ly, although
Hosoda-san's patch was applied.
But again, I've a successful run for the english-only doc with all
japenese commented and a changed orchestra.ly.
I attach the revised orchestra.ly if someone wans to try. Maybe it
even helps to track down the problem.
Cheers,
Harm
\version "2.19.21"
\header {
tagline = ##f
title = "Violent Dance For Orchestra"
composer = "Hu Haipeng"
% arranger = "July 5, 2009"
% poet = " I'm writing this piece because I'm terribly frustrated, facing a task which will seriously stain my aesthetics and conviction to the true art. It consists of all kinds of devils, dancing and whirling violently, turning the world into an abyss of darkness. Although the main melodies are derived from folk music, these are only a beautiful skin, and the essence of this piece is violent and evil, full of my 10 years' pain and rage. It's a large volcano of my long repressed heart!"
}
\paper{
line-width = 158\mm
}
%% text defs
presto = \markup { \bold \italic "Presto" }
div = \markup { \bold "Div." }
nondiv = \markup { \bold "Non div." }
unis = \markup { \bold "Unis." }
piz = \markup { \bold "Pizz." }
arc = \markup { \bold "Arco" }
pizz = \set Staff.midiInstrument = "pizzicato strings"
arco = \set Staff.midiInstrument = "string ensemble 1"
pont = \markup { \bold \italic "Sul ponticello" }
naturale = \markup { \bold \italic "Naturale" }
moltocr = {
\set crescendoText = \markup { \italic "Molto cresc." }
\set crescendoSpanner = #'text
\override DynamicTextSpanner.style = #'dotted-line
}
offCr = {
\unset crescendoText
\unset crescendoSpanner
\revert DynamicTextSpanner.style
}
modern =
#`(Staff ,(make-accidental-rule 'same-octave 0)
,(make-accidental-rule 'any-octave 0)
,(make-accidental-rule 'same-octave 1))
marks = \relative c' {
\set markFormatter = #format-mark-box-numbers
\tempo \presto 4.=112
\set Score.currentBarNumber = #11
s2.*4 |
s1*9/8 |
}
piccolo = \relative c {
\clef treble \key ees \minor \time 6/8
\transposition c''
R2.
ges,16(\mf\< ees c ees ges bes) c( bes ges bes c ees) |
ges8-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
flutes = \relative {
\clef treble \key ees \minor \time 6/8
R2.
16(\mf\< ) ( ) |
8-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
oboes = \relative {
\clef treble \key ees \minor \time 6/8
R2. |
4(\mf\< 8 4 8) |
-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
clarinets = \relative c' {
\clef treble \key f \minor \time 6/8
\transposition bes
4(\p\< 8) 4( 8) |
4( 8) 4( 8) |
-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
bassoons = \relative {
\clef bass \key ees \minor \time 6/8
4.\pp\< c'^"a2" |
bes8-. bes-. bes-. ges-. ges-. ges-. |
ees-.->\!\ff \offCr 4\pp ~ 4. ~ | 2. |
\time 9/8
ges4\p^"I" aes8 aes ees ges ges4 aes16( ges) |
}
hornI = \relative c'' {
\clef treble \key bes \minor \time 6/8
\transposition f
r4 r8 4.\p\< ~ |
8-. -. -. -. -. -. |
-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
r4 r8 2.\pp |
}
hornII = \relative c'' {
\clef treble \key bes \minor \time 6/8
\transposition f
\moltocr 2.\pp\< ~ |
8-. -. -. -. -. -. |
-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
2.\pp 4. ~ |
}
trumpetI = \relative c''' {
\clef treble \key f \minor \time 6/8
\transposition bes
R2. |
r4 r8 -.\f\< -. -. |
-.->\!\ff r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
trumpetII = \relative c'' {
\clef treble \key f \minor \time 6/8
\transposition bes
R2. |
r8 d-.\mf\< d-. d-. d-. d-. |
d-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
trombones = \relative {
\clef tenor \key ees \minor \time 6/8
r4 r8 4.\mp\< ~ |
8-. -. -. -. -. -. |
-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
tuba = \relative {
\clef bass \key ees \minor \time 6/8
4.(\pp\< |
8-.) -. -. -. -. -. |
-.->\!\ff \offCr r r r4 r8 | R2. |
\time 9/8
R1*9/8 |
}
timpani = \relative {
\clef bass \key ees \minor \time 6/8
ees8\< ees ees ees ees ees |
bes bes bes bes bes bes |
ees,->\!\f \offCr ees'\pp ees ees ees ees |
ees ees ees ees ees ees |
\time 9/8
ees r r r4 r8 r4 r8 |
}
trian = {
\clef percussion \time 6/8
R2.*4 |
\time 9/8
R1*9/8
Re: Still cannot make doc :(
Knut Petersen writes: > Am 29.05.2016 um 13:52 schrieb David Kastrup: >> I have to see whether I have a chance to run a 64 bit kernel on my >> system: I used to for a few years (and consequently was able to look >> at 64 bit code), but the current laptop has an Nvidia card and >> Ubuntu's kernel/library setup did not manage to integrate the Nvidia >> proprietary driver stuff into a 64 bit kernel running on a 32bit >> userland and the free drivers did not work reasonably. Maybe the >> situation has improved. > > On my i7-4790K valgrind reports 23179 "Conditional jump or move > depends on uninitialised value(s)" > and "Use of uninitialised value of size 8" errors from 121 contexts. I > suspect that the patch that breaks > "make doc" only exposes an older problem. But 121 context ... that's a > lot of code to inspect. The commit in question _does_ change some engraver/translator memory layouts/sizes. It is conceivable that some uninitialized memory previously was reliably stomped over with somewhat-ok values. And what might be at bay here is that garbage collection triggers while the constructor of the Engraver base class is running, and derived_mark marks values that have not yet been initialized by the constructor of the derived class. I don't think we need to inspect all contexts here: the commit in question changed the engraver/translator _infrastructure_ so it is not surprising that if there is a problem, it occurs often. So the 121 contexts will not likely be of more than a few different kinds. Can I get some pointers to the routine where the jump occurs, together with a bit of disassembly for figuring out the actual corresponding source code? Or was that information already in one of your reports? > To those who see "make doc" fail at orchestra.ly: Please report cpu as > well as versions of gcc and guile. Please also send the output of I'll start a make doc. But I suspect we might also have some Ghostscript problem responsible for some of our problems. Conveniently, my Ghostscript is a 32bit version... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC spanners project
Nathan Chou writes: > Hello, > > Thank you for the information! I have been thinking more and a few > questions have come to mind: > > * However the cross voice Spanner object is created, is it expected to > be identical to the object currently created by the hidden voice > workaround? Just to make sure, Spanners are Grobs, which only contain > graphical information and aren't associated with a context, right? Spanners are Grobs. Grobs contain a whole lot more than only graphical information (the graphical part is their stencil) but are employed only during graphical typesetting (the one governed by \layout blocks). Spanners tend to split into separate quasi-items at line breaking, with each such item covering one line. They aren't themselves associated with contexts, but the _announcements_ (or rather "acknowledgments") of grobs mention the engraver originating the announcement. That engraver is hosted by a particular (and queryable) context. > * Although it is possible to deliver the STOP spanner event to the > engraver of the corresponding START event (e.g. if the spanner has an > ID to match the START and STOP events), is this an undesirable > solution because it basically does the same thing as the hidden voice > workaround? There is no need to base the implementation on workarounds. At the current point of time, slurs and phrasing slurs have ways of dealing with multiple spanners. That has not much of a user interface and it requires putting up engravers in some context where it will see the announcements of both starting and ending slur. The mechanism is also tied rather hard into the engravers themselves without a good way to generalize this into other engravers. Currently engravers listen to events and acknowledgments only in their dedicated context but can announce anywhere. It's possible to move the listeners around independently if that opens a viable solution. Of course, the lifetime of an engraver is tied to its hosting context, however. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
Am 29.05.2016 um 13:52 schrieb David Kastrup: I have to see whether I have a chance to run a 64 bit kernel on my system: I used to for a few years (and consequently was able to look at 64 bit code), but the current laptop has an Nvidia card and Ubuntu's kernel/library setup did not manage to integrate the Nvidia proprietary driver stuff into a 64 bit kernel running on a 32bit userland and the free drivers did not work reasonably. Maybe the situation has improved. On my i7-4790K valgrind reports 23179 "Conditional jump or move depends on uninitialised value(s)" and "Use of uninitialised value of size 8" errors from 121 contexts. I suspect that the patch that breaks "make doc" only exposes an older problem. But 121 context ... that's a lot of code to inspect. Workaround I installed an additional 32-bit build environment on my PC and chrooted to that environment (after "mount -o bind /dev /32bitenv/dev") In this environment "make doc" succeeds. A few questions Is there anybody out there who succeeds to build the current lilypond documentation on a 64 bit linux machine with a 64 bit toolchain? Please report cpu as well as versions of gcc and guile. To those who see "make doc" fail at orchestra.ly: Please report cpu as well as versions of gcc and guile. Please also send the output of valgrind -v --track-origins=yes /lilysourcedir/build/out/bin/lilypond -dpreview -dverbose -dresolution=150 \ -o ./out-www /lilysourcedir/Documentation/ly-examples/orchestra.ly &> logfile after a failed "make doc" of lilypond version c1d7bc2217 to me (obviously "lilysourcedir" has to be adapted). cu, Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: OTC support
> I've opened a bug report to discuss whether ghostscript will add OTC > support, and whether the gs team is going to extend Type42 support > to cover generic SFNTs (i.e., CFF flavour also). > > http://bugs.ghostscript.com/show_bug.cgi?id=696808 And there's a quick reply: No OTC support in gs, instead we should rather extract the `CFF ' table from the OTC subfont and embed it as a Type 2 font as we already do for normal OTFs. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
