Re: broken doc build (orchestra.ly)
David Kastrup writes: [Bisection] >> Commit c1d7bc2217462a63bf5c5c6d6f6df5cb00099180 >> Author: David Kastrup >> Date: Tue May 3 19:11:15 2016 +0200 >> >> Issue 4842/6: Don't special-case Scheme_engraver's acknowledgers >> >> >> /build/Documentation/ly-examples/orchestra.preview.log >> === >> Changing working directory to: `./out-www' >> Processing `/home/knut/sources/lily/Documentation/ly-examples/orchestra.ly' >> Parsing... >> Interpreting music...ERROR: Wrong type (expecting exact integer): (x y) > > Oh wow. The expression with the wrong type is something completely > different here. That makes it likely that we are dealing with an > expression that has been garbage-collected prematurely and is > overwritten with something else randomly before use. So yes, I think there is a problem in that commit regarding garbage-protecting a Scheme_engraver's acknowledgers. But: I don't think that orchestra.ly even uses a Scheme engraver, and the problem would not hit before such an engraver is actually instantiated in some context. Very weird. Nevertheless, I'll see whether this needs fixing, and if it does, follow through with an issue (and push fast once testing confirms no problem). Even though I don't really see how this could trigger in the described manner. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
David Kastrup writes: > David Kastrup writes: > > [Bisection] > >>> Commit c1d7bc2217462a63bf5c5c6d6f6df5cb00099180 >>> Author: David Kastrup >>> Date: Tue May 3 19:11:15 2016 +0200 >>> >>> Issue 4842/6: Don't special-case Scheme_engraver's acknowledgers >>> >>> >>> /build/Documentation/ly-examples/orchestra.preview.log >>> === >>> Changing working directory to: `./out-www' >>> Processing `/home/knut/sources/lily/Documentation/ly-examples/orchestra.ly' >>> Parsing... >>> Interpreting music...ERROR: Wrong type (expecting exact integer): (x y) >> >> Oh wow. The expression with the wrong type is something completely >> different here. That makes it likely that we are dealing with an >> expression that has been garbage-collected prematurely and is >> overwritten with something else randomly before use. > > So yes, I think there is a problem in that commit regarding > garbage-protecting a Scheme_engraver's acknowledgers. Nope, there wasn't. If at all, it is sort of a timing problem where the derived_mark of a Scheme_engraver might be called before the type is fully initialized or it is _not_ called until it is fully initialized and fails to protect the partially constructed type. > But: I don't think that orchestra.ly even uses a Scheme engraver, and > the problem would not hit before such an engraver is actually > instantiated in some context. Very weird. Can you run this under a debugger and place a breakpoint on Scheme_engraver::init_from_scheme or just write abort(); as its first line? I want to know whether the problem is triggered _without_ creating a Scheme_engraver. Or whether I just did not figure out how a Scheme_engraver comes into play here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
James writes: > I don;t know what the lilypond.pot stuff does but could that have been > the problem? Unlikely. I think it may be the distribution of files across parallel builds, where the few snippets using the Scheme_engraver poison the session so that it crashes during an unrelated snippet (or when exiting) later on. That is, if we can show that the Scheme_engraver code actually gets exercised during the runs that crash. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
James Lowe writes: > David, > > On 20/05/16 17:38, David Kastrup wrote: >> James writes: >> >>> I don;t know what the lilypond.pot stuff does but could that have been >>> the problem? >> Unlikely. I think it may be the distribution of files across parallel >> builds, where the few snippets using the Scheme_engraver poison the >> session so that it crashes during an unrelated snippet (or when exiting) >> later on. >> >> That is, if we can show that the Scheme_engraver code actually gets >> exercised during the runs that crash. >> > > Well if you need me to try some 'hacked up' code or try some specific > compilation options etc. to get output for you, let me know. > > All I can say to Knut is that, for the last couple of days anyway, the > 'problem' seems to have gone away. Garbage collection problems are elusive. I was surprised that Knut was able to reproduce them well enough for bisection (though bisection does not employ much redundancy if at all, so if a problem triggers randomly, you'll still end up with a particular commit labelled as culprit). At any rate, Werner had pushed a spelling correction commit that ended up staying in staging for a long time (days I think) but then got passed to master pretty fast once _another_ commit was pushed on top of it. That also reeks a bit of Patchy failure for sort-of random but reproducible conditions. At any rate, I pushed a slightly amended patch for issue 4851 now. _If_ it was a garbage collection issue on some topic I suspected, it might make the problem go away. Let's hear from Knut. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
Werner LEMBERG writes: >> At any rate, Werner had pushed a spelling correction commit that >> ended up staying in staging for a long time (days I think) but >> then got passed to master pretty fast once _another_ commit was >> pushed on top of it. > > I hope it is OK to push such minor tweaks without creating an issue. > Otherwise it would increase the necessary time to apply such fixes by > a factor of 10 at least... The problem with such minor tweaks is that if they break sectioning, they can still block the queue. While our staging process keeps master reasonably clean and compilable, it can still affect staging. So my own metric is that if a change is restricted to non-functional texts (comments, descriptions etc) I don't have much qualms about just pushing. This change, however, affected cross-references and index entries. With regard to the text changes: I don't actually know whether the correct Finnish word is kaksoisappogiatura or kaksoisappoggiatura but am willing to believe the latter. I do find the German "mit einem Schrägstrich durch den Hals, und den Vorhalt (engl. appoggiatura)," at least peculiar since "appoggiatura" is rather an Italian than an English term. While this description originates from before the patch, a review might have been an opportunity for changing this. At the current point of time, patch testing is done completely manually by James. That does make me somewhat less inclined to create issues/patches for trivial stuff. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Custom accidental styles
Dan Eble writes:
> On May 20, 2016, at 05:38 , Simon Albrecht wrote:
>> I was hoping to do further improvements to the code (comments and
>> simplification) such as to make the threshold still lower, but I
>> didn’t get there unfortunately.
>>
>> HTH, Simon
>>
>
> Thank you. That was helpful. This worked for me:
>
> %% Like voice, with additional cautionary cross-voice cancellations
> #(set! accidental-styles (append accidental-styles
> `((hymnbook-cautionary #f
>(Voice ,(make-accidental-rule 'same-octave 0))
>(Staff ,(make-accidental-rule 'same-octave 0))
>Staff
accidental-styles.hymnbook-cautionary =
#`(#f (Voice ,(make-accidental-rule 'same-octave 0))
(Staff ,(make-accidental-rule 'same-octave 0))
Staff)
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Custom accidental styles
Dan Eble writes: > [I dropped lilypond-devel when I replied. Sending David’s reply to the list.] > > From: David Kastrup > Subject: Re: Custom accidental styles > Date: May 21, 2016 at 12:29:05 EDT > To: Dan Eble > > Dan Eble writes: > >>> On May 21, 2016, at 11:00 , David Kastrup wrote: >>> >>> Dan Eble writes: >>> >>>> On May 20, 2016, at 05:38 , Simon Albrecht wrote: >>>>> I was hoping to do further improvements to the code (comments and >>>>> simplification) such as to make the threshold still lower, but I >>>>> didn’t get there unfortunately. >>>>> >>>>> HTH, Simon >>>>> >>>> >>>> Thank you. That was helpful. This worked for me: >>>> >>>> %% Like voice, with additional cautionary cross-voice cancellations >>>> #(set! accidental-styles (append accidental-styles >>>> `((hymnbook-cautionary #f >>>> (Voice ,(make-accidental-rule 'same-octave 0)) >>>> (Staff ,(make-accidental-rule 'same-octave 0)) >>>> Staff >>> >>> accidental-styles.hymnbook-cautionary = >>> #`(#f (Voice ,(make-accidental-rule 'same-octave 0)) >>> (Staff ,(make-accidental-rule 'same-octave 0)) >>> Staff) >> >> It’s prettier, but it isn’t working. With 2.19.42, I get "warning: >> unknown accidental style” and the style is not put into effect. The >> attached file demonstrates both ways. > > Ugh. Wouldn't work with define! instead of set! either I guess (which > is what lily-lexer.cc uses effectively). The variable is defined in a > different module (lily rather than the current lexer). > > From the Guile docs: > > `define' (when it occurs at top level), `scm_define' and >`scm_c_define' all create or set the value of a variable in the top >level environment of the current module. If there was not already a >variable with the specified name belonging to the current module, but a >similarly named variable from another module was visible through having >been imported, the newly created variable in the current module will >shadow the imported variable, such that the imported variable is no >longer visible. > > So for > > xxx.yyy = ... > > we quite likely want set! semantics. How about for > > xxx = ... > > ? Ugh. GNU LilyPond 2.19.43 Processing `input/regression/collision-2.ly' Parsing.../usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: In expression (break pred lst): /usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: Wrong type to apply: #) (break-permission . force))((display-methods #) (name . LineBreakEvent) (types line-break-event break-event event)) > `break' is a procedure (automatically loaded) in (srfi srfi-1). It is also a music expression in ly/declarations-init.ly. Overwriting it does not seem like a good idea... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Custom accidental styles
David Kastrup writes: > Dan Eble writes: > >> From the Guile docs: >> >> `define' (when it occurs at top level), `scm_define' and >>`scm_c_define' all create or set the value of a variable in the top >>level environment of the current module. If there was not already a >>variable with the specified name belonging to the current module, but a >>similarly named variable from another module was visible through having >>been imported, the newly created variable in the current module will >>shadow the imported variable, such that the imported variable is no >>longer visible. >> >> So for >> >> xxx.yyy = ... >> >> we quite likely want set! semantics. How about for >> >> xxx = ... >> >> ? > > Ugh. > > GNU LilyPond 2.19.43 > Processing `input/regression/collision-2.ly' > Parsing.../usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: > In expression (break pred lst): > /usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: > Wrong type to apply: # /usr/local/tmp/lilypond/out/share/lilypond/current/ly/declarations-init.ly:64:9>) > (break-permission . force))((display-methods #) > (name . LineBreakEvent) (types line-break-event break-event event)) > > > `break' is a procedure (automatically loaded) in (srfi srfi-1). It is > also a music expression in ly/declarations-init.ly. > > Overwriting it does not seem like a good idea... So the question is what to do with partial list assignments. The assumption would likely be that the user _knows_ he wants to modify an existing list in its own module when not writing xxx = #'() before assigning to xxx.yyy. But I'm queasy about that. It could result in spacing settings in some \header or \layout to have more global effects than intended. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
"Phil Holmes" writes: > I think it's likely to be what David was guessing at - David's "Issue > 4842/6: Don't special-case Scheme_engraver's acknowledgers" has > affected garbage collection somehow, and this affects different > systems in different ways, because of the way the OS handles memory > allocation. I thought the current master was good enough. > You might try rolling back to before that commit and see whether you > are OK. If so, there's an argument (I think) for Davis to revert it > until we're on firmer ground checking what it happening with make doc. There are a few other commits in that area, so reverting is not all that easy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
James Lowe writes: > My make doc issue has come back :( > > Taking a few more minutes to try and diagnose the problem - it is the > same again, as Knut had. With the same error on processing > orchestra.ly. Bah. Let's try getting a post mortem backtrace from it. Basically, you do ulimit -c 40 # Assuming that a 400MB core is enough then you run the tests. Now when the assertion failure happens, it will leave a file named "core" in the directory where the program was started (probably Documentation/ly-examples). You can probably look for it using find -name core in your LilyPond directory. Then you do gdb out/bin/lilypond Documentation/ly-examples/core and should be able to tell gdb to backtrace Be sure that you don't have an old core file lying around: I think that Linux does not overwrite preexisting core files. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Custom accidental styles
David Kastrup writes: > David Kastrup writes: > >> Dan Eble writes: >> >>> From the Guile docs: >>> >>> `define' (when it occurs at top level), `scm_define' and >>>`scm_c_define' all create or set the value of a variable in the top >>>level environment of the current module. If there was not already a >>>variable with the specified name belonging to the current module, but a >>>similarly named variable from another module was visible through having >>>been imported, the newly created variable in the current module will >>>shadow the imported variable, such that the imported variable is no >>>longer visible. >>> >>> So for >>> >>> xxx.yyy = ... >>> >>> we quite likely want set! semantics. How about for >>> >>> xxx = ... >>> >>> ? >> >> Ugh. >> >> GNU LilyPond 2.19.43 >> Processing `input/regression/collision-2.ly' >> Parsing.../usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: >> In expression (break pred lst): >> /usr/local/tmp/lilypond/out/share/lilypond/current/scm/lily-library.scm:583:32: >> Wrong type to apply: #> /usr/local/tmp/lilypond/out/share/lilypond/current/ly/declarations-init.ly:64:9>) >> (break-permission . force))((display-methods #) >> (name . LineBreakEvent) (types line-break-event break-event event)) > >> >> `break' is a procedure (automatically loaded) in (srfi srfi-1). It is >> also a music expression in ly/declarations-init.ly. >> >> Overwriting it does not seem like a good idea... > > So the question is what to do with partial list assignments. The > assumption would likely be that the user _knows_ he wants to modify an > existing list in its own module when not writing xxx = #'() before > assigning to xxx.yyy. > > But I'm queasy about that. It could result in spacing settings in some > \header or \layout to have more global effects than intended. Ok, just pinned this down by changing session-define-public. Tracker issue: 4858 (https://sourceforge.net/p/testlilyissues/issues/4858/) Rietveld issue: 300110043 (https://codereview.appspot.com/300110043) Issue description: Let define-session-public place variables natively into parser Putting them as native variables in the parser module (rather than using export/import) makes `set!' and `define' equivalent rather than having `define' create a shadowing definition of the session variable. That is important in order to avoid the values of the variable diverging between parser module and `lily'. Your example works fine with that change. It should also allow foregoing the use of ly:parser-lookup/ly:parser-define! in a number of cases since session-export variables are now automatically shared between `lily' module and parser. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
James Lowe writes: > OK I'll give that a go and roll back to the commit just before all the > 4842/* ones - in case I cannot just roll back to before the 4842/6 and > not break something dependent in the other 4842 changes. All of the commits should compile fine (or I'd have put them in a branch of their own). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
James Lowe writes: > No core file was generated, I also upped the ulimit to 1GB. > > So perhaps it isn't the type of 'assertion' or crash you thought it > was after all? Perhaps. Knut's problem, however, sounded like it. If you have different results from Knut, things are even muddier than I thought. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
James writes:
> David
>
> On 24/05/16 18:20, David Kastrup wrote:
>> James Lowe writes:
>>
>>> No core file was generated, I also upped the ulimit to 1GB.
>>>
>>> So perhaps it isn't the type of 'assertion' or crash you thought it
>>> was after all?
>> Perhaps. Knut's problem, however, sounded like it. If you have
>> different results from Knut, things are even muddier than I thought.
>>
> Just in case it isn't obvious :)
>
> Your checkin stuck in staging is because patchy-staging-merge cannot
> complete the make doc so it won't push to staging, not because there
> is necessarily anything wrong with your patch.
I'll run one of my own. It's a nuisance that our results differ. Wait:
my patchy runs with --enable-checking instead of --disable-optimising
because I have the following patch applied:
>From fe1e215b2780a201c8fa85cefe76e894cdfc4a66 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Tue, 19 May 2015 10:21:13 +0200
Subject: [PATCH] Replace --disable-optimising with the faster
--enable-checking
---
patches/compile_lilypond_test/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/patches/compile_lilypond_test/__init__.py b/patches/compile_lilypond_test/__init__.py
index 22b2ff9..4a554f3 100644
--- a/patches/compile_lilypond_test/__init__.py
+++ b/patches/compile_lilypond_test/__init__.py
@@ -296,7 +296,7 @@ class AutoCompile (object):
run ("find %s ! -wholename \"*out-test-baseline*\" -type f -exec rm -f {} \\;"
% self.build_dir, wrapped=True)
self.runner (self.build_dir,
-os.path.join (self.src_build_dir, "configure") + " --disable-optimising",
+os.path.join (self.src_build_dir, "configure") + " --enable-checking",
issue_id, "configure", env=dict (config.items ("configure_environment")))
def patch (self, patch_issue, issue_id):
--
2.7.4
That was the long-term idea for creating --enable-checking in the first
place. I just haven't put everybody on the same footing here.
I'll revert this patch at my end and see whether I get anywhere
different.
Knut, did you use any options to ./configure ? config.log should
mention how configure was called.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
David Kastrup writes: > James writes: > >> David >> >> On 24/05/16 18:20, David Kastrup wrote: >>> James Lowe writes: >>> >>>> No core file was generated, I also upped the ulimit to 1GB. >>>> >>>> So perhaps it isn't the type of 'assertion' or crash you thought it >>>> was after all? >>> Perhaps. Knut's problem, however, sounded like it. If you have >>> different results from Knut, things are even muddier than I thought. >>> >> Just in case it isn't obvious :) >> >> Your checkin stuck in staging is because patchy-staging-merge cannot >> complete the make doc so it won't push to staging, not because there >> is necessarily anything wrong with your patch. > > I'll run one of my own. It's a nuisance that our results differ. Wait: > my patchy runs with --enable-checking instead of --disable-optimising > because I have the following patch applied: [...] > I'll revert this patch at my end and see whether I get anywhere > different. > > Knut, did you use any options to ./configure ? config.log should > mention how configure was called. S. This took longer than I thought because I hibernated the laptop (Doh!) before going to sleep. It completed in the morning. How-e-ver: staging had already been pushed to master previously by someone else. Did someone test manually? Or do other patchies not fail in the manner Knut's setup does? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
Knut Petersen writes: > Am 20.05.2016 um 17:27 schrieb David Kastrup: >> David Kastrup writes: >> >>> Can you run this under a debugger and place a breakpoint on >>> Scheme_engraver::init_from_scheme or just write abort(); as its first >>> line? I want to know whether the problem is triggered _without_ >>> creating a Scheme_engraver. Or whether I just did not figure out how a >>> Scheme_engraver comes into play here. >>> > > Back at the PC again. > > lilypond 0e00ce29: > > > make doc succeeds. > > lilypond c1d7bc22: What about current master? More exactly, did 56a1519b44d1a0a8500c43236ae644053cc1f25b make a difference? > "valgrind -v --track-origins=yes > /home/knut/sources/lily/build/out/bin/lilypond -dpreview -ddebug > -dresolution=150 -o ./out-www > /home/knut/sources/lily/Documentation/ly-examples/orchestra.ly" fails > 10 out of 10 times. > > lilypond c1d7bc22 with "abort();" at start of > Scheme_engraver::init_from_scheme succeeds if called from bash prompt > and fails with valgrind again. Makes little enough sense to me. At any rate, if the changed code does not even get called, it would seem that rather the change in memory layout might be responsible for triggering the problem. I'll try to go through the code with a fine comb and see whether I can find anything that might make a difference when no Scheme_engraver is actually created (which should correspond to init_from_scheme not being called). > "-ddebug" does not work as lilypond tells me that there is no internal > option named debug ;-) Uh, -dverbose it was. > valgrind logs of both versions differ a lot, but they are pretty > big. Shall I send them to the list? I think it could be a good idea to > look at those places that differ ... I'm not sure. valgrind output for code using a conservative garbage collector tends to be of quite limited usefulness. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
Knut Petersen writes: >>>> Knut, did you use any options to ./configure ? config.log should >>>> mention how configure was called. > doit "../configure --prefix=$MYROOT" Ok, so no options at all. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tie properties vs. slur properties.
tisimst writes: > On Wed, May 25, 2016 at 12:19 AM, Werner LEMBERG [via Lilypond] < > ml-node+s1069038n19094...@n5.nabble.com> wrote: > >> >> > The tie interface has height-limit and ratio as part of Tie.details. >> > >> > The slur interface has height-limit and ratio as part of Slur (not >> > embedded in Slur.details). >> > >> > Is there a reason for this difference, or is it just due to never >> > making the two be consistent? >> >> I believe it's the latter. >> >> > If there is no reason for the difference, I think the two should be >> > rationalized, probably by moving Slur.height-limit and Slur.ratio to >> > Slur.details.height-limit and Slur.details.ratio. >> >> This looks ok. >> > > What's the benefit of nesting properties like this? You don't need to list them individually in an interface. You can override the whole set of details with one command without needing to specifically clear properties that are usually never set, but the user and/or some containing context may have set them to special values. If you need to access them as a set anyway, it's faster to get them once and go from there. There may be properties in some "details" that are named identically to properties in some other "details" or at top level. That's what I can currently think of. I'm not particularly enamored with the details either, but if you take a look at stuff like the harp diagram details, they are really a long long list. Overriding all of them individually is effort. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tie properties vs. slur properties.
tisimst writes: > On Thu, May 26, 2016 at 12:50 AM, David Kastrup [via Lilypond] < > ml-node+s1069038n190980...@n5.nabble.com> wrote: >> >> I'm not particularly enamored with the details either, but if you >> take a look at stuff like the harp diagram details, they are really a >> long long list. Overriding all of them individually is effort. >> > > Ah, yes. That makes sense. Thank you for making it possible to do both > Grob.details.property and Grob.details = #'((property . ...)) That one wasn't my idea. I merely reimplemented it in order to make it work reliably with predictable semantics without putting too much of a downer on performance. It wasn't used heavily before partly because it was a bit hit-and-miss once you tried combining it with reverts (and since the default for \override is to revert before setting, this does not exactly happen rarely). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James writes: > Hello, > > I still cannot make doc and so cannot merge staging - and for those > waiting on me to test new patches, I cannot do that with any great > reliability either. Fiddlesticks. I was afraid that this would be the case but it was worth a try. > I am sorry this is incredibly frustrating. Sorry. > I don't have time right now to set up a LilyDev env to try it for > myself and will not have the time until at least Saturday evening. I don't think that the problem can be reduced to a code generation issue (which would explain that it gets seen only on certain systems likely depending on GCC version and/or machine architecture) because the changes of the incriminated patch do not introduce markedly different code from before. If anything, it removes code. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James writes: > Hello, > > I still cannot make doc and so cannot merge staging - and for those > waiting on me to test new patches, I cannot do that with any great > reliability either. > > I am sorry this is incredibly frustrating. > > @Phil would it be possible for you to run Patchy Merge on your system > and see if you can get this to work. I've started one just now on my laptop. It just takes significantly North of one hour to complete. -- David Kastrup ___ 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-27 16:22 GMT+02:00 David Kastrup : >> James writes: >> >>> Hello, >>> >>> I still cannot make doc and so cannot merge staging - and for those >>> waiting on me to test new patches, I cannot do that with any great >>> reliability either. >> >> Fiddlesticks. I was afraid that this would be the case but it was worth >> a try. >> >>> I am sorry this is incredibly frustrating. >> >> Sorry. >> >>> I don't have time right now to set up a LilyDev env to try it for >>> myself and will not have the time until at least Saturday evening. >> >> I don't think that the problem can be reduced to a code generation issue >> (which would explain that it gets seen only on certain systems likely >> depending on GCC version and/or machine architecture) because the >> changes of the incriminated patch do not introduce markedly different >> code from before. If anything, it removes code. >> >> -- >> David Kastrup > > FWIW, I checked out staging with your recent patch, i.e.: > $ git log > commit 193369dddc8adc492d3d98b6f1d00de11a31e9c4 > Author: David Kastrup > Date: Fri May 27 10:20:18 2016 +0200 > > Issue 4863: Protect Grob_interface<>::interface_symbol_ > [...] > > On my host system Ubuntu 16.04 64-bit > make doc > fails with orchestra.ly as before Yes, I reckoned so after James' report. Without some backtrace or core dump or recipe other than "run make doc" I cannot really track this down. It would not be feasible to look at the assembly code for all affected code since this changes header files resulting in differences in all engravers/translators. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Silently depressed keys
Dan Eble writes: > I’m experimenting with an articulation called \silent that uses a > large negative midi-extra-velocity property to add a note with minimum > velocity to the MIDI output. "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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James Lowe writes: > I think this a a completely different issue that you have, perhaps, > self-inflicted here and this is just adding noise to the thread. I disagree that it is just adding noise to the thread: it may well explain why we have outliers regarding the reports concerning architecture: having a different problem responsible there is clarifying things. > Finally, as I cannot make doc still, I cannot test patches, am not > really checking my emails as much as I normally do, other than to drop > by for the patch countdown - which doesn't need me to compile > anything. It also means, as you can all see, that staging is not being > merged and I have both my home and work machines running on a > patchy-staging-merge 2 - 4 hour loop but constantly reporting the same > make doc fail each time they try to merge. > > Someone else is going to have to test patches and merge staging for > now. I hear your frustration and will be running a staging pass presently. Sorry for the bad situation. I am currently rewriting LilyPond's translators in order to make them better debuggable and the code more straightforward. 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. -- 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: > 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. GNOME and GNOME_classic crash on login. MATE appears to start, so I might be able to work with a graphical interface. It's likely that I'll not be able to suspend or hibernate, though. But maybe I can get to where I am able to get a lead on the problem. It's not like I had other plans for my birthday anyway. Ok, I did, but climbing was struck off the list a week ago already because of being incompatible with spontaneous loss of consciousness. Probably just the blood pressure medication doing more than its duty. Sorry, I'm just not good company at the moment. -- 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: > David Kastrup writes: > >> 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. > > GNOME and GNOME_classic crash on login. MATE appears to start, so I > might be able to work with a graphical interface. It's likely that I'll > not be able to suspend or hibernate, though. But maybe I can get to > where I am able to get a lead on the problem. This is going to take a whole lot of time. Lots of library/compilation problems. I think I need to go scything nettles to get a clear head. I hope to get this under control in the course of the day. Bah. Compose Key gone as well. Need to get along with the U.S. keyboard for a while it appears. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
Thomas Morley writes: > James, > > 2016-05-29 13:15 GMT+02:00 James Lowe : >> Thomas, > >> I think this a a completely different issue that you have, perhaps, >> self-inflicted here and this is just adding noise to the thread. >> >> Knut and I do not get these same errors as you and also note that we both >> *can* compile doc prior to the one checkin that David did. > > I disagree. > As soon as I commented every occurance of japanese in all relevant > files I got the error on orchestra.ly with > make LANGS='' doc > > Next I revised orchestra.ly. > - I deleted some custom-context-definitons and put them directly via > \with into the elevant contexts > - multiple settings of \layout were summarized > - numerous uses of \set instrumentName ... etc were put into \with as well > The last point may be the most likely candidate for the problems with > orchestra.ly, but I'm only guessing. > > Anyway, with this I got a successful run of `make LANGS='' doc' > > A diff is attached. > > 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. > > I suspect we have two problems (at least). I manage to compile for amd64 architecture currently. In the process I likely hosed my system to a degree where I will not be able to run it with a 32bit kernel or GNOME any time soon again. On the plus side, I've been able to hibernate a few times (not possible before). But I should be good for testing 64bit compilation now. Not so sure about 32bit. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
Thomas Morley writes: >> Processing `./c0/lily-c236818d.ly' >> Parsing... >> Renaming input to: `/home/hermann/lilypond-git/input/regression/utf-8.ly' >> Interpreting music... >> Preprocessing graphical objects... >> Calculating line breaks... >> Drawing systems... >> Writing header field `texidoc' to `./c0/lily-c236818d.texidoc'... >> Writing ./c0/lily-c236818d-1.signature >> Writing ./c0/lily-c236818d-2.signature >> Layout output to `./c0/lily-c236818d.eps'... >> Converting to `./c0/lily-c236818d.pdf'... >> warning: `(gs -q -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 >> -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite >> -sOutputFile=./c0/lily-c236818d.pdf -c.setpdfwrite >> -f./c0/lily-c236818d.eps)' failed (256) >> >> Every problematic file listed in the log compiles on its own without >> problem. They all deal with fonts in some way, though. I think make doc uses --bigpdf and some sort of PDF postprocessing. Maybe one needs that to reproduce? -- 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: > >>> Processing `./c0/lily-c236818d.ly' >>> Parsing... >>> Renaming input to: `/home/hermann/lilypond-git/input/regression/utf-8.ly' >>> Interpreting music... >>> Preprocessing graphical objects... >>> Calculating line breaks... >>> Drawing systems... >>> Writing header field `texidoc' to `./c0/lily-c236818d.texidoc'... >>> Writing ./c0/lily-c236818d-1.signature >>> Writing ./c0/lily-c236818d-2.signature >>> Layout output to `./c0/lily-c236818d.eps'... >>> Converting to `./c0/lily-c236818d.pdf'... >>> warning: `(gs -q -dNOSAFER -dEPSCrop -dCompatibilityLevel=1.4 >>> -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite >>> -sOutputFile=./c0/lily-c236818d.pdf -c.setpdfwrite >>> -f./c0/lily-c236818d.eps)' failed (256) >>> >>> Every problematic file listed in the log compiles on its own without >>> problem. They all deal with fonts in some way, though. > > I think make doc uses --bigpdf and some sort of PDF postprocessing. > Maybe one needs that to reproduce? --bigpdfs it was. Sorry. Or just -b . -- 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 :(
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: 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 :(
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
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 :(
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: 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: pushing to a new branch on server
Federico Bruni writes: > 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. /dev/fede/doc-it is an absolute path. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Still cannot make doc :(
James writes: > 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. My own LilyPond is now 64bittified so it does not offer anything over yours. Issue 4865 compiles for me (well, it got across ly-examples at least once and I don't care about repeated tries). Mind you: this is a code reorganization and mostly mechanical. It most certainly does _not_ address any potential bug but apparently is enough of a reorganization that garbage collection now triggers at a different point of time where the bug wreaks less havoc. So screw this, I'm pushing that patch to staging out of line. Let's see whether lilypond-patchy-staging then not just gets past the ly-examples but also the rest of the docs. If it does, for whatever misbegotten reason, at least we'll stop wasting your time with regular work and I can get this crap analyzed without time pressure. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
pat...@gnu.org writes:
> 09:14:55 (UTC) Begin LilyPond compile, previous commit at
> dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
> 09:15:08 test-master-lock and PID entry exist but previous Patchy
> run (PID 17333) died, resetting test-master-lock anyway.
> 09:15:10 Merged staging, now at: dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
> 09:15:11 Success:./autogen.sh --noconfigure
> 09:15:19 *** FAILED BUILD ***
> /tmp/lilypond-autobuild/configure --disable-optimising
> Previous good commit: a1467ba6de6240dda93009c907b05794ec9b8d54
> Current broken commit: dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8
> 09:15:19 *** FAILED STEP ***
> merge from staging
> Failed runner: /tmp/lilypond-autobuild/configure --disable-optimising
> See the log file log-staging-configure.txt
> 09:15:19 Traceback (most recent call last):
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 527, in handle_staging
> self.configure (issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 300, in configure
> issue_id, "configure", env=dict (config.items ("configure_environment")))
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: /tmp/lilypond-autobuild/configure
> --disable-optimising
> See the log file log-staging-configure.txt
Ugh, sorry for that. I need to tell my patchy to compile for 64bit or
it will not get along with the libraries. Let's see whether I manage to
do so.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Delay import of `midi' module. (issue 297420043 bylemzw...@googlemail.com)
"Phil Holmes" writes: > - Original Message - > From: > To: > Cc: ; > Sent: Tuesday, May 31, 2016 11:37 AM > Subject: Re: Delay import of `midi' module. (issue 297420043 > bylemzw...@googlemail.com) > >>> > Can you push this right to staging >> >>> Done. >> >> Aargh, I forgot to massage the commit message to mention the issue. >> Sorry for that. > > This causes make test to fail: > > Traceback (most recent call last): > File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line > 1194, in > main () > File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line > 1191, in main > convert_midi (f, o) > File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line > 958, in convert_midi > t.music = t.parse () > File "/home/patchy/patchybuild/autobuild/scripts/midi2ly.py", line > 441, in parse > if (e[1][0] == midi.NOTE_OFF > NameError: global name 'midi' is not defined > make[2]: *** [out-test/key-initial-midi.ly] Error 1 > make[2]: *** Waiting for unfinished jobs > make[1]: *** [local-test] Error 2 > make: *** [test] Error 2 Argl. Removing this commit again. Werner, do you think you can push a fixed version? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
pat...@gnu.org writes:
> 10:35:41 (UTC) Begin LilyPond compile, previous commit at
> def633f7a88fe8950b685adee93165c42299bd5c
> 10:35:55 Merged staging, now at: def633f7a88fe8950b685adee93165c42299bd5c
> 10:35:56 Success:./autogen.sh --noconfigure
> 10:36:13 Success:/tmp/lilypond-autobuild/configure
> --disable-optimising
> 10:36:17 Success:nice make clean
> 10:42:40 Success:nice make -j3 CPU_COUNT=3
> 10:50:35 *** FAILED BUILD ***
> nice make test -j3 CPU_COUNT=3
> Previous good commit: a1467ba6de6240dda93009c907b05794ec9b8d54
> Current broken commit: def633f7a88fe8950b685adee93165c42299bd5c
> 10:50:35 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make test -j3 CPU_COUNT=3
> See the log file log-staging-nice-make-test--j3-CPU_COUNT=3.txt
> 10:50:35 Traceback (most recent call last):
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 528, in handle_staging
> self.build (issue_id=issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 328, in build
> issue_id)
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make test -j3 CPU_COUNT=3
> See the log file log-staging-nice-make-test--j3-CPU_COUNT=3.txt
Ugh. The Python module. If I compile that with 64bit, it won't
cooperate with my 32bit Python2.7. And half the desktop environment
depends on that so I don't want to swap that out.
I have to see whether I can make a clean 64/32 split along the necessary
lines here.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Delay import of `midi' module. (issue 297420043 by lemzw...@googlemail.com)
"Phil Holmes" writes: > Patchy-staging running now. >> >> https://codereview.appspot.com/297420043/ Well, hooray! master has been pushed. Now let's see whether this helps James in any respect (if there is still a Ghostscript problem, it likely won't, but otherwise it might). And I need to stop LilyPond from conflating $(LD) for both C and C++. In fact, it first proceeds to find a good version of LD for C, only to have it stomped over with '$(CXX)' in STEPMAKE_CXX afterwards (commit commit 078703a6ab29f75983a55ac2cc35fe5f315da574 Author: Jan Nieuwenhuizen Date: Wed Oct 19 13:54:23 2005 + * stepmake/stepmake/*: * */GNUmakefile: * config.make.in: * GNUmakefile.in: * stepmake/aclocal.m4: Friendlier --srcdir build, allowing `make' from any directory in build-dir. Cleanups. * make/srcdir.make.in: Remove. * lily/main.cc (setup_paths): Fix and document build-dir hack. ). As I want to have 64bit compilation with C++ and 32bit with C on my personal computer (don't ask), it's important to have the linker distinguished properly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Delay import of `midi' module. (issue 297420043 by lemzw...@googlemail.com)
James writes: > On 31/05/16 13:37, David Kastrup wrote: >> "Phil Holmes" writes: >> >>> Patchy-staging running now. >>>> https://codereview.appspot.com/297420043/ >> Well, hooray! master has been pushed. Now let's see whether this helps >> James in any respect (if there is still a Ghostscript problem, it likely >> won't, but otherwise it might). > > I am running a merge now - it doesn't matter that someone else already > has done it (Patchy just replies that staging has already been pushed > by 'someone else'; I do appreciate those devs that worked on Patchy) - > so if that works, I'll know in about 20 mins from now. > > Then I'll see if I can test a patch - although I fear we may get > failures that have more to do with needing to rebase with current > master ;) > > I'll let you all know. I'm rather interested in issue 4871: that one is necessary for my rather peculiar C++/64 C/32 setup to work. Once I can push that one to staging, I should be able to rejoin the lilypond-patchy-staging crowd. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Delay import of `midi' module. (issue 297420043 by lemzw...@googlemail.com)
James writes: > On 31/05/16 13:56, James wrote: >> >> >> On 31/05/16 13:37, David Kastrup wrote: >>> "Phil Holmes" writes: >>> >>>> Patchy-staging running now. >>>>> https://codereview.appspot.com/297420043/ >>> Well, hooray! master has been pushed. Now let's see whether this helps >>> James in any respect (if there is still a Ghostscript problem, it likely >>> won't, but otherwise it might). >> >> I am running a merge now - it doesn't matter that someone else >> already has done it (Patchy just replies that staging has already >> been pushed by 'someone else'; I do appreciate those devs that >> worked on Patchy) - >> so if that works, I'll know in about 20 mins from now. >> >> Then I'll see if I can test a patch - although I fear we may get >> failures that have more to do with needing to rebase with current >> master ;) >> >> I'll let you all know. > OK that all worked and I was technically able to push. > > \o/ > > Although I hadn't noticed that I had the default values of j3 and it > took nearly an hour to compile the doc =80 (no wonder people hate > doing it, I had forgotten what it was like in the olden days when I > used to do doc work on my 2 CPU iMac running LilyDev in a VM). That sounds like Lilydev and 32bit. I'd be interested to know whether 64bit has improved. > Thanks for the work to all concerned. The frustrating thing is that the commit that broke things was just reorganizing some stuff, and the commit that possibly made things work again was further reorganizing and there is no sane reason for either to have made a difference. But I hope this buys me time for figuring out the insane reasons. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Delay import of `midi' module. (issue 297420043 by lemzw...@googlemail.com)
James writes: > On 31/05/16 16:52, David Kastrup wrote: > >> That sounds like Lilydev and 32bit. I'd be interested to know whether >> 64bit has improved. > > This was 64 bit. Great. > It is just that I still had default setting of the > lilypond-patchy-config file is j3 from my restored build environmenty > when we first had the issue and thought the problem was local to my > machine. > > I can try 32 bit if you like - I still have my lilydev VM around. Let's just wait and see if someone else hollers. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Delay import of `midi' module. (issue 297420043 by lemzw...@googlemail.com)
James writes: > Although I hadn't noticed that I had the default values of j3 and it > took nearly an hour to compile the doc Luxury. https://www.youtube.com/watch?v=VKHFZBUTA4k> > (no wonder people hate doing it, I had forgotten what it was like in > the olden days when I used to do doc work on my 2 CPU iMac running > LilyDev in a VM). 16:55:29 (UTC) Begin LilyPond compile, previous commit at 1b6d6de94a26c3e8b75e1f78f6d0cfc9eec96a89 16:55:43 Merged staging, now at:1b6d6de94a26c3e8b75e1f78f6d0cfc9eec96a89 16:55:44Success:./autogen.sh --noconfigure 16:56:01Success:/tmp/lilypond-autobuild/configure --disable-optimising 16:56:04Success:nice make clean 17:03:03Success:nice make -j3 CPU_COUNT=3 17:18:03Success:nice make test -j3 CPU_COUNT=3 18:32:37Success:nice make doc -j3 CPU_COUNT=3 18:32:54 To ssh://git.sv.gnu.org/srv/git/lilypond.git 905109e..1b6d6de test-staging -> master 18:32:54Success:pushed to master -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Spare SSD anybody?
Hi, my current development SSD, graciously donated by James, currently has the following readings: Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 099 099 ---Pre-fail Always - 13 9 Power_On_Hours 0x0032 094 094 ---Old_age Always - 25748 12 Power_Cycle_Count 0x0032 093 093 ---Old_age Always - 6196 175 Program_Fail_Count_Chip 0x0032 099 099 ---Old_age Always - 9 176 Erase_Fail_Count_Chip 0x0032 100 100 ---Old_age Always - 0 177 Wear_Leveling_Count 0x0013 085 085 ---Pre-fail Always - 545 178 Used_Rsvd_Blk_Cnt_Chip 0x0013 077 077 ---Pre-fail Always - 450 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 079 079 ---Pre-fail Always - 844 180 Unused_Rsvd_Blk_Cnt_Tot 0x0013 079 079 ---Pre-fail Always - 3188 181 Program_Fail_Cnt_Total 0x0032 099 099 ---Old_age Always - 13 182 Erase_Fail_Count_Total 0x0032 100 100 ---Old_age Always - 0 183 Runtime_Bad_Block 0x0013 099 099 ---Pre-fail Always - 13 187 Uncorrectable_Error_Cnt 0x0032 100 100 ---Old_age Always - 0 195 ECC_Error_Rate 0x001a 200 200 ---Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 ---Old_age Offline - 0 199 CRC_Error_Count 0x003e 253 253 ---Old_age Always - 0 232 Available_Reservd_Space 0x0013 077 077 ---Pre-fail Always - 1566 241 Total_LBAs_Written 0x0032 032 032 ---Old_age Always - 2933093682 242 Total_LBAs_Read 0x0032 058 058 ---Old_age Always - 1798843749 In the interest of continuity, it seems like a good idea to replace it soon. I might return to a rotating disk (which has quite less wear but is more sensitive to movement, draws more current, and of course is slower). After changing my kernel to 64bit, I am currently in the situation that the computer will no longer wake successfully from sleep mode (screen stays black), so I have to use hibernation instead. That's nice on the battery but sloshes out gigabytes of memory to disk each time. So it's not really helping with regard to SSD wear. I don't have all that much free capacity either, so what I have is being cycled often. Anybody with something to spare? The current size I have is 120GB. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spare SSD anybody?
David Kastrup writes: > Hi, > > my current development SSD, graciously donated by James, currently has > the following readings: > > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED > WHEN_FAILED RAW_VALUE > 5 Reallocated_Sector_Ct 0x0033 099 099 ---Pre-fail Always > - 13 > 9 Power_On_Hours 0x0032 094 094 ---Old_age Always > - 25748 Ok, I might have been panicking because of all the lines with "Pre-fail" and "Old_age" but they only indicate the _category_ of the respective settings. Sorry for that. I'm still trying to figure out the readings as such though. The "documentation" including online is not much help. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spare SSD anybody?
Michael Hendry writes: >> On 1 Jun 2016, at 10:07, David Kastrup wrote: >> >> David Kastrup writes: >> >>> Hi, >>> >>> my current development SSD, graciously donated by James, currently has >>> the following readings: >>> >>> Vendor Specific SMART Attributes with Thresholds: >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED >>> RAW_VALUE >>> 5 Reallocated_Sector_Ct 0x0033 099 099 --- Pre-fail Always - 13 >>> 9 Power_On_Hours 0x0032 094 094 --- Old_age Always - 25748 >> >> Ok, I might have been panicking because of all the lines with "Pre-fail" >> and "Old_age" but they only indicate the _category_ of the respective >> settings. Sorry for that. >> >> I'm still trying to figure out the readings as such though. The >> "documentation" including online is not much help. > > > Surely an SSD is entirely Solid State, so can’t wear out in the way a > mechanical device does. Seriously? https://en.wikipedia.org/wiki/Wear_leveling>. Which is why SSD drives are great for servers and are put through the mills as swap drive. > Eventually, I suppose, even solid state devices will fail, but I doubt > that SMART monitoring will give you advance warning of this. It can keep track of the individual block wear pretty well, and the average number of reliable block erasures is also known. So failures are not _exceptional_ but predictable. So storage deterioration is predictable as well as monitorable (either CRC errors or uncleared bits directly after erasure). You can get a hint about the bearings of a rotating disk by monitoring its spinup (and noticing irregularities in operation) but actual failures tend to come suddenly as platter damage affecting an area. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spare SSD anybody?
Alexander Kobel writes: > recently I was afraid about my SSD for the same reason, so I asked our > institute's IT service staff who cares for some dozens (hundreds?) of > laptops and desktops with SSDs. > > They say that even power users of hibernation with high rate of data > turnover didn't manage to damage their SSDs lately; the horror stories > for the first generations of SSDs seem not to apply anymore. Well, I am not sure I have significantly later than first generation... === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: SAMSUNG SSD PM810 2.5" 7mm 128GB Serial Number:S0NRNEAB524258 LU WWN Device Id: 5 f0 0 Firmware Version: AXM08D1Q User Capacity:128,035,676,160 bytes [128 GB] Sector Size: 512 bytes logical/physical Rotation Rate:Solid State Device Device is:In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS, ATA/ATAPI-7 T13/1532D revision 1 SATA Version is: SATA 2.6, 3.0 Gb/s (current: 1.5 Gb/s) Local Time is:Wed Jun 1 12:23:20 2016 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled > You still have to take a bit of care (try to have some empty space, > and run fstrim once in a while), but other than that you should be > fine. As you experienced, the SMART information is rather unhelpful > unless you have additional context by the manufacturer; more often > than not, the only semi-reliable source are the manufacturer's own > toolkits (which, unfortunately, are hardly available on Linux). > That being said: which form factor/connector do you need? SATA, 2.5". > I can ask if I can grab something. Many parts from few-year old > machines are sorted out regularly here. Not sure about hard disks, > though - there might be regulations for data protection that prevent > them from giving out old drives. Sure, it would be nice to keep in mind. I'm not really sure what the expected lifetime of the disk I have is. Maybe I just need to keep making backups in sane intervals and otherwise am still fine. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
Thomas Morley writes: > First the good news. > With a build from a checkout of recent staging, I can successfully run > make LANGS='' doc > without any failure for orchestra.ly > ... as soon as I comment/delete all japanese !! Yes, it was pretty obvious that we are talking about two separate problems here. Have you tried the recent patches by Hosoda-san? They would appear to concern Japanese font problems, and there are two on countdown. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: broken doc build (orchestra.ly)
Knut Petersen writes: > "make doc" succeeds again, at least here. > > [newer versions]: make doc succeeds > dbaf1e56e37be0e204231c5bf1adcb14bd8ac3b8: fixes "make doc" failure here Ugh, I forgot to make this a merge commit. The preceding commit does not compile on its own. Let's hope that this does not bite too many people when bisecting. > 4b4a2cae9953cff69159f10763e990f5e4265ddd: lilypond does not build > cccd7f9574c72ccecca00641d7a5ea3e8ce99cfd: still broken "make doc" > [...] > c1d7bc2217462a63bf5c5c6d6f6df5cb00099180: first broken "make doc" > [older versions] The "fixing" commit, like the "breaking" one is a reorganization that should not have caused a difference either way. The purpose of committing the "fix" mainly was to streamline the initialization code such that tracing and debugging of the initialization would become more straightforward. It's not clear to me what even causes somewhat reliably reproducible failure (with or without --disable-optimising, robust against smaller changes, across different computers and setups) when LilyPond is called from the Makefile but not when it is called with the same command line from the shell. I am currently doing a large sequence of tentative fixes to garbage collection/initialization, rebased on the earliest failing commit. So far, no change in result. But it's still stuff useful for avoiding use-before-initialization. Guilev2 might be affected worse, so making things airtight is not a waste of time. Still, I'd want to get a hold on the actual culprit. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc still fails - problem with lilypond-book - was: Still cannot make doc
Masamichi Hosoda writes: > In addition, all fonts of the above without `-dgs-load-fonts' option are fine. > I suggest removing `-dgs-load-fonts' option from lilypond-book. > I think that `--bigpdfs' option is more suitable than > `-dgs-load-fonts'. Either make for particularly large PDF files, don't they? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for June 6th
James Lowe writes: > Hello, > > Here is the current patch countdown list. The next countdown will be on > June 9th. > > A quick synopsis of all patches currently in the review process can be > found here: > > http://philholmes.net/lilypond/allura/ > > Apologies for the huge list in countdown - we had a bit of a logjam a > last week because of some doc compiling issue, so if people want the > countdown to be extended a day or two, just let me know. > > I'll assume no reply means I carry on as normal. I have pushed a number of patches early (cross fingers). So you should particularly update your "New" list in order to avoid testing patches that are already in. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for June 6th
Dan Eble writes: > Also, I submitted a couple patches that do not appear in your list. > Did I miss a step somewhere? > > https://sourceforge.net/p/testlilyissues/issues/2232/ > https://sourceforge.net/p/testlilyissues/issues/3945/ Status "Started" rather than "Accepted". Changed that right now. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for June 6th
Dan Eble writes: > On Jun 6, 2016, at 08:39 , David Kastrup wrote: >> >> Dan Eble writes: >> >>> Also, I submitted a couple patches that do not appear in your list. >>> Did I miss a step somewhere? >>> >>> https://sourceforge.net/p/testlilyissues/issues/2232/ >>> https://sourceforge.net/p/testlilyissues/issues/3945/ >> >> Status "Started" rather than "Accepted". Changed that right now. > > Thanks. Is there a good reason not to let the git-cl upload script > set the status to Started? git-cl already does that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: Countdown for June 6th
Dan Eble writes: >> On Jun 6, 2016, at 16:52 , David Kastrup wrote: >> >> Dan Eble writes: >> >>> On Jun 6, 2016, at 08:39 , David Kastrup wrote: >>>> >>>> Dan Eble writes: >>>> >>>>> Also, I submitted a couple patches that do not appear in your list. >>>>> Did I miss a step somewhere? >>>>> >>>>> https://sourceforge.net/p/testlilyissues/issues/2232/ >>>>> https://sourceforge.net/p/testlilyissues/issues/3945/ >>>> >>>> Status "Started" rather than "Accepted". Changed that right now. >>> >>> Thanks. Is there a good reason not to let the git-cl upload script >>> set the status to Started? >> >> git-cl already does that. > > It didn’t for these two issues. Maybe that happens (not) when uploading to an already existing issue? For newly created issues at least I did not have problems. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spare SSD anybody?
Dr Nicholas Bailey writes: > On Wednesday, 1 June 2016 12:36:02 BST David Kastrup wrote: >> Alexander Kobel writes: >> ... >> >> Sure, it would be nice to keep in mind. I'm not really sure what the >> expected lifetime of the disk I have is. Maybe I just need to keep >> making backups in sane intervals and otherwise am still fine. > > I had cause to look into this recently and came across the following. > Executive summary: everything is fine now and new SSDs last forever. Well, I don't exactly have a new SSD... > http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead > > It's on the internet so it must be true :) (I expect more > authoritative tests are available). > > I'm using a hybrid 1TB in my laptop at the moment with no problems > with Debian Stretch GNU/Linux as the only OS installed. These devices > feature typically 8GB or so of flash with the majority of the storage > being on the whirlydisk. What the flash gets used for is up to the > drive. Well, I'll just stick with what I have until replacement is mandatory or convenient. And then I (or more likely the facts) can decide on the parameters... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub failure
"Phil Holmes" writes: > Attached is a compressed log file. I see lots of warnings but no errors. It does not use the text "error" but there is: make[1]: *** No rule to make target `/home/gub/NewGub/gub/target/darwin-ppc/root/usr/include/freetype2/freetype/ftxf86.h', needed by `out/pango-font.o'. Stop. make[1]: *** Waiting for unfinished jobs The "unfinished jobs" create so much more output afterwards that you probably overlooked this problem. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsvg-view can't display SVG files created by lilypond
Werner LEMBERG writes: >>> >> However, there's still a nasty scaling bug that completely ruins >>> >> text positioning at larger magnification values. Sigh. >>> > >>> > Is *this* a bug in librsvg, or another LilyPond output problem? >>> >>> It's definitely a bug in librsvg AFAICS, cf. >>> >>> https://phabricator.wikimedia.org/T65703 >> >> I see on this page that there is a mention of "Fixed in 2.40.13" > > I think this is only partially correct, cf. > > https://phabricator.wikimedia.org/T65703#1981688 > >> Do you happen to know if we could usefully upgrade Denemo to use >> librsvg 2.40.13 (it always involves quite a bit of work upgrading >> versions so I thought I'd ask first) > > Sorry, I can't help here. Regarding librsvg, I'm an ordinary user, > not acquainted with SVG at all. Well, we are not in the market for SVG compliance testing. If there are reasonably simple changes we can make to LilyPond in order to avoid/sidestep triggering this librsvg bug, then we'll save ourselves a lot of trouble by just doing some change on our side. Blame-shifting tends up to be a lot of work and hassle with _our_ users, never mind that technically we are not at fault at all. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsvg-view can't display SVG files created by lilypond
Richard Shann writes: > On Thu, 2016-06-09 at 12:57 +0200, David Kastrup wrote: >> Werner LEMBERG writes: >> >> >>> >> However, there's still a nasty scaling bug that completely ruins >> >>> >> text positioning at larger magnification values. Sigh. >> >>> > >> >>> > Is *this* a bug in librsvg, or another LilyPond output problem? >> >>> >> >>> It's definitely a bug in librsvg AFAICS, cf. >> >>> >> >>> https://phabricator.wikimedia.org/T65703 >> >> >> >> I see on this page that there is a mention of "Fixed in 2.40.13" >> > >> > I think this is only partially correct, cf. >> > >> > https://phabricator.wikimedia.org/T65703#1981688 >> > >> >> Do you happen to know if we could usefully upgrade Denemo to use >> >> librsvg 2.40.13 (it always involves quite a bit of work upgrading >> >> versions so I thought I'd ask first) >> > >> > Sorry, I can't help here. Regarding librsvg, I'm an ordinary user, >> > not acquainted with SVG at all. >> >> Well, we are not in the market for SVG compliance testing. If there are >> reasonably simple changes we can make to LilyPond in order to >> avoid/sidestep triggering this librsvg bug, > > I don't know about *this* bug, but I did test out replacing currentColor > with "black" (in quotes) in the LilyPond source code and it worked fine; > that seems to me not only a simple but also a fairly sensible change. Except that it would make it impossible to draw in colors other than black. That was the rationale for using currentColor in the first place. It would seem like a better idea to explicitly establish a documentwide default of currentColor to black explicitly somewhere. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsvg-view can't display SVG files created by lilypond
Richard Shann writes: > On Thu, 2016-06-09 at 13:23 +0200, David Kastrup wrote: >> Richard Shann writes: >> >> > I don't know about *this* bug, but I did test out replacing >> > currentColor with "black" (in quotes) in the LilyPond source code >> > and it worked fine; that seems to me not only a simple but also a >> > fairly sensible change. >> >> Except that it would make it impossible to draw in colors other than >> black. That was the rationale for using currentColor in the first >> place. > > Oh, if that is the case then I'm misremembering - I thought I found > that explicitly set colors over-rode the value currentColor (or > "black" or whatever you put at that place in the code). What is "that place"? dak@lola:/usr/local/tmp/lilypond$ git grep currentColor Documentation/misc/ChangeLog-2.10: change black to currentColor everywhere. This fixes color support scm/output-svg.scm: (set-attribute 'fill "currentColor")) scm/output-svg.scm: (set-attribute 'fill "currentColor") scm/output-svg.scm: `(fill . ,(if is-filled "currentColor" "none")) scm/output-svg.scm: `(stroke . "currentColor") scm/output-svg.scm:(stroke . "currentColor") scm/output-svg.scm: `(fill . ,(if is-filled "currentColor" "none")) scm/output-svg.scm: `(stroke . "currentColor") scm/output-svg.scm: `(fill . ,(if fill "currentColor" "none")) scm/output-svg.scm: `(stroke . "currentColor") scm/output-svg.scm: `(fill . ,(if fill "currentColor" "none")) scm/output-svg.scm: `(stroke . "currentColor") scm/output-svg.scm: '(stroke . "currentColor") scm/output-svg.scm:`(fill . ,(if fill? "currentColor" "none")) scm/output-svg.scm: `(fill . ,(if is-filled "currentColor" "none")) scm/output-svg.scm: '(stroke . "currentColor") scm/output-svg.scm: '(fill . "currentColor"))) -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsvg-view can't display SVG files created by lilypond
Werner LEMBERG writes: >> It would seem like a better idea to explicitly establish a >> documentwide default of currentColor to black explicitly somewhere. > > Perhaps a `-dxxx' command-line option? Anything requiring explicit user effort in order to produce expected results is not going to mitigate the damage. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rsvg-view can't display SVG files created by lilypond
Werner LEMBERG writes: >>>> It would seem like a better idea to explicitly establish a >>>> documentwide default of currentColor to black explicitly >>>> somewhere. >>> >>> Perhaps a `-dxxx' command-line option? >> >> Anything requiring explicit user effort in order to produce expected >> results is not going to mitigate the damage. > > Mhmm, `damage' is too big a word IMHO. This problem is already fixed > in the latest release of librsvg (and it wasn't present in some > earlier versions about a year ago; at least I was able to submit an > SVG to Wikipedia without any problems), and I believe that at least > Wikipedia will update within the next few months. So a half-year outage of LilyPond on Wikipedia and a messup of Denemo and a number of other applications is not "damage". > The current default of Lilypond is not wrong, as far as I can see. Shrug. It doesn't matter whether we can nominally justify calling this "somebody else's problem". The fallout still piles up in our backyard. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme question
Phil Holmes writes:
> Can anyone explain why the f in the attached code is 2 octaves above where
> I would expect them?
>
> testy = #(define-music-function (note)
> (ly:music?)
> #{
> \tag #'a { #note }
> \tag #'b { #note }
> #})
>
> \score {
> \keepWithTag #'a {
> \new Staff
> {
> \new Voice { \relative c'' { c d e \testy f } }
> }
> }
> }
Because you let it be shifted two times before selecting your tag? Your
music does not contain two _copies_ of note, but rather contains note
_itself_ two times. So \relative is applied to the same music two times
in succession.
Use #(music-clone note) or #(ly:music-deep-copy note) or $note for your
two uses, and the note will get placed in two separate _copies_ of the
original rather than using the note object itself in two places.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme question
David Kastrup writes:
> Phil Holmes writes:
>
>> Can anyone explain why the f in the attached code is 2 octaves above where
>> I would expect them?
>>
>> testy = #(define-music-function (note)
>> (ly:music?)
>> #{
>> \tag #'a { #note }
>> \tag #'b { #note }
>> #})
>>
>> \score {
>> \keepWithTag #'a {
>> \new Staff
>> {
>> \new Voice { \relative c'' { c d e \testy f } }
>> }
>> }
>> }
>
> Because you let it be shifted two times before selecting your tag? Your
> music does not contain two _copies_ of note, but rather contains note
> _itself_ two times. So \relative is applied to the same music two times
> in succession.
>
> Use #(music-clone note) or #(ly:music-deep-copy note) or $note for your
> two uses, and the note will get placed in two separate _copies_ of the
> original rather than using the note object itself in two places.
By the way: since \relative is applied before \keepWithTag, the result
will still likely suck when writing
\relative c'' { c d e \testy f, c }
since in first iteration it expands to
\relative c'' { c d e \tag #'a f, \tag #'b f, c }
namely
\absolute { c'' d'' e'' \tag #'a f' \tag #'b f c }
so the subsequent c is still likely to be one octave lower than
expected.
So you probably want
testy = #(define-music-function (note)
(ly:music?)
(make-relative (note) note
#{
\tag #'a { $note }
\tag #'b { $note }
#}))
This uses just "note" as the expression affecting \relative, but places
two separate copies of the once-affected note in your tags.
Expressed differently: the whole concept of \relative sucks.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Protected_scm warning: returning reference to temporary
Dan Eble writes: > I noticed these errors building staging in lilydev 3.0: > >> /home/dan/lilypond-git/lily/protected-scm.cc: In member function >> 'Protected_scm::operator scm_unused_struct* const&() const': >> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: warning: >> returning reference to temporary [enabled by default] That sounds bad. The way I read the C++11 standard (but it may not apply to lilydev 3.0) this should work out, but there is no real reason not to use an explicit if/then instead of ? : here in order not to rely on it. >> /home/dan/lilypond-git/lily/protected-scm.cc: In member function >> 'Protected_scm& Protected_scm::operator=(const Protected_scm&)': >> /home/dan/lilypond-git/lily/protected-scm.cc:60:16: warning: >> '' may be used uninitialized in this function >> [-Wuninitialized] >> /home/dan/lilypond-git/lily/protected-scm.cc:75:56: note: >> '' was declared here That's current staging/master? It would likely be issue 4873 that caused the change. I don't remember seeing a similar message on my computer (native Ubuntu environment rather than lilydev 3.0). Anyway, I'll push a fix. Can you check again in 5 minutes? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Mixing music and markup in Scheme
Phil Holmes writes:
> Yet another question about Scheme functions (note - I _do_ try to find the
> answers to my questions by reading the manual and experimenting, and have
> been looking at this for a couple of hours without success).
>
> Background: Renaissance music has a somewhat cavalier attitude to
> placement of accidentals. Sometimes they are conventionally placed to the
> left of the note, and occasionally they are placed above the note, like
> musica ficta in modern transcriptions. If I use \set suggestAccidentals =
> ##t in Mensural music, I get a modern accidental sign, so this doesn't
> help setting these. A long-hand way of getting this effect is:
Ugh.
Being cleverer than LilyPond rarely pays off.
mus = \relative c''
{ c4 d e \once \set suggestAccidentals = ##t fis
}
\score {
\new MensuralStaff \with { \override AccidentalSuggestion.glyph-name-alist =
#alteration-mensural-glyph-name-alist }
{
\new MensuralVoice { \mus }
}
}
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Mixing music and markup in Scheme
"Phil Holmes" writes:
>> mus = \relative c''
>> { c4 d e \once \set suggestAccidentals = ##t fis
>> }
>>
>> \score {
>> \new MensuralStaff \with { \override
>> AccidentalSuggestion.glyph-name-alist =
>> #alteration-mensural-glyph-name-alist }
>>{
>> \new MensuralVoice { \mus }
>>}
>> }
>>
>
> Excellent, as always. Thanks.
Well, not really. Should AccidentalSuggestion.glyph-name-alist be
changed by default here? Or are the ficta signs in mensural music
usually added as well as styled modernly?
Should there be some more obvious interface? And/or documentation?
My basic approach here was "there must be something better" and digging
around in the internals doc for candidates and in the "musica ficta" NR
index and finally looking for something related in default context/grob
properties in the Scheme files.
Approaches that don't work without specialist handholding and/or code
archaeology don't really scale well.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc build failing
Phil Holmes writes: > I thought I'd see how large I get for a doc build and so nuked my build > directory and started from scratch. I get a failed doc build (this with > master). There are a number of xml files which are throwing errors similar > to: > > lilypond-git/input/regression/musicxml/02d-Rests-Multimeasure- > TimeSignatures.xml:7:5: error: syntax error, unexpected end of input > > Always the same line and character number 7:5 > > Has anyone else seen this, or been successful recently? Unexpected end of input? My first guess would be that your disk is full. I mean, obviously we had versions of lilypond-patchy-staging able to build docs. The next guess would be that you need "make test" before doing "make doc" because of missing dependencies: the xml stuff clearly is from the regtests, and it would explain why lilypond-patchy-staging is able to get through with its documentation building. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A regression
Richard Shann writes: > (this happened after inserting a page break). It compiles ok with > 2.18.2. My question is, would it be helpful to anyone to have the file? > (Obviously cutting it down to a minimal example is not an option). \repeat unfold 2000 c'4 is a pretty minimal way to produce lots of pages. While it likely takes considerable effort to replace parts of the file in this manner while producing the same error, that's not the same as "obviously not an option". Debugging such problems tends to be quite a headache on its own: reducing the number of elements that might be involved here will definitely be helpful. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What to do with input/regression/page-spacing.ly
Thomas Morley writes: > Hi, > > in input/regression/page-spacing.ly several commands for > \overrideProperty > Score.NonMusicalPaperColumn.line-break-system-details > ... > are applied, i.e. settings for Y-extent, refpoint-Y-extent, > next-padding, next-space, bottom-space. > > As far as I can tell none of them has any visual effect anymore as > opposed to (far) earlier ly-version. > Attached a cut off from > http://lilypond.org/doc/v2.10/input/regression/collated-files.pdf > page 86 > (In my pdf-viewer every glyph is omitted, incompatlible software for > such an old file I guess, but that's not the point here) > You'll see those settings _had_ an effect with v2.10 > Additionally, the `obsolete-between-system-space` there let me guess > that convert-ly was applied to it at some point of time and since then > nobody touched it. > > Strange enough, the last commit I've found tackling paper-system.scm is Cf. https://lists.gnu.org/archive/html/lilypond-devel/2015-06/msg00068.html> and Trevor's answer. Not that this is overly conclusive about what we should do here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Marc Hohl writes: > Hi list, > > after a recent "git pull", the call "make -j3" fails with > > --- > > In file included from slur-engraver.cc:32:0: > slur-engraver.cc: In static member function 'static void > Slur_engraver::boot()': > ./include/translator.icc:115:40: error: > '&Slur_proto_engraver::listen_slur' is not a valid template argument > for type 'void (Slur_engraver::*)(Stream_event*)' because it is of > type 'void (Slur_proto_engraver::*)(Stream_event*)' > method_finder<&cl::listen_ ## m> (), \ > ^ > slur-engraver.cc:65:3: note: in expansion of macro 'ADD_LISTENER' >ADD_LISTENER (Slur_engraver, slur); >^ > ./include/translator.icc:115:40: note: standard conversions are not > allowed in this context > method_finder<&cl::listen_ ## m> (), \ > ^ > slur-engraver.cc:65:3: note: in expansion of macro 'ADD_LISTENER' >ADD_LISTENER (Slur_engraver, slur); >^ > make[1]: *** [out/slur-engraver.o] Error 1 > make[1]: *** Waiting for unfinished jobs > make[1]: Leaving directory `/home/marc/git/lilypond/lily' > make: *** [all] Fehler 2 > > --- > > The error is reproducable with a fresh git clone > > Any ideas? Well, it got through patchy-staging. So obviously something is different with your setup, and you don't give any information about your setup. What does g++ --version say? You used git pull (rather than git pull -r). That causes a merge rather than a rebase. Recent changes in master happened to be reverts which did not apply cleanly but had to be significantly edited. Adding merge resolution on top might lead to problems. Can you try rebasing on master/origin and see whether that helps? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
"Phil Holmes" writes: > make fails for me. Old Ubuntu 10.04. Nuked build and reran configur > etc. Result is: > > In file included from > /media/IntelSSD/lilypond/lilypond-git/lily/slur-engraver.cc:32:0: > /media/IntelSSD/lilypond/lilypond-git/lily/slur-engraver.cc: In static > member function 'static void Slur_engraver::boot()': > /media/IntelSSD/lilypond/lilypond-git/lily/include/translator.icc:115:40: > error: '&Slur_proto_engraver::listen_slur' is not a valid template > argument for type 'void (Slur_engraver::*)(Stream_event*)' because it > is of type 'void (Slur_proto_engraver::*)(Stream_event*)' > method_finder<&cl::listen_ ## m> (), \ > ^ > /media/IntelSSD/lilypond/lilypond-git/lily/slur-engraver.cc:65:3: > note: in expansion of macro 'ADD_LISTENER' > ADD_LISTENER (Slur_engraver, slur); > ^ > /media/IntelSSD/lilypond/lilypond-git/lily/include/translator.icc:115:40: > note: standard conversions are not allowed in this context > method_finder<&cl::listen_ ## m> (), \ > ^ > /media/IntelSSD/lilypond/lilypond-git/lily/slur-engraver.cc:65:3: > note: in expansion of macro 'ADD_LISTENER' > ADD_LISTENER (Slur_engraver, slur); > ^ > make[1]: *** [out/slur-engraver.o] Error 1 > make[1]: *** Waiting for unfinished jobs > make[1]: Leaving directory > `/media/IntelSSD/lilypond/lilypond-git/build/lily' > make: *** [all] Error 2 > phil@Ubuntu:~/lilypond-git/build$ I don't think we have supported 10.04 for a long time now (and there have been long streaks of time where it definitely failed on other stuff). I am somewhat puzzled at this failure because exactly the _same_ technique has been used for acknowledgers for quite a while now, recently reversed, and later reinstated. So it does not make a whole lot of sense to be that it fails with listeners, and only with some compilers. The responsible commit would likely be commit f7013d65b51f1372dc31973b78bbe04f505ea569 Author: David Kastrup Date: Sat Jun 18 10:20:43 2016 +0200 Issue 4899/1: Let method_finder also find listeners This allows using inherited listeners directly like with acknowledgers and translator methods. However, it is also conceivable that some other commit in the 4899 series pushes your compiler version over the edge. Can you try checking which commits in issue 4899 (if any) make your compilation go bad? Maybe I can figure then out what is unique about them after all and we can figure out how to be more compiler-friendly. Marc, what compiler version do you have? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Knut Petersen writes:
> os / compiler
> ===
>
> os version: linux, openSUSE 13.2 (Harlequin) (x86_64)
> gcc --version: (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
Pretty old as well.
> git bisect log
> =
> git bisect start
> # good: [f4e12f1b0cb5dfb32f193f87e7ca28c406b87771] Issue 2232: fix MIDI
> output of abutting (de)crescendi
> git bisect good f4e12f1b0cb5dfb32f193f87e7ca28c406b87771
> # bad: [a975d6f176453d35367e3fa4808c7061d326a9e7] Issue 4898: Set
> rhythmic-location early in paper-column-engraver
> git bisect bad a975d6f176453d35367e3fa4808c7061d326a9e7
> # good: [f9b2cfebb944a0ea7d7c35a583233c51039486aa] PO: update template.
> git bisect good f9b2cfebb944a0ea7d7c35a583233c51039486aa
> # bad: [f7013d65b51f1372dc31973b78bbe04f505ea569] Issue 4899/1: Let
> method_finder also find listeners
> git bisect bad f7013d65b51f1372dc31973b78bbe04f505ea569
> # good: [f869d8f6ebe878618588036e17971166721de9e0] Release: bump Welcome
> versions.
> git bisect good f869d8f6ebe878618588036e17971166721de9e0
> # good: [5dbaaca80b06fda4b0a3b9cdc67760a2735dbee1] Merge remote branch
> 'origin/release/unstable' into HEAD
> git bisect good 5dbaaca80b06fda4b0a3b9cdc67760a2735dbee1
> # good: [ec6b4cc313dd6a1aa4070080076da54b7f1c0c71] Release: bump VERSION.
> git bisect good ec6b4cc313dd6a1aa4070080076da54b7f1c0c71
> # first bad commit: [f7013d65b51f1372dc31973b78bbe04f505ea569] Issue 4899/1:
> Let method_finder also find listeners
Ok, this is sort of a nuisance because I still have pending stuff in
that exact area (starting with issue 4903) and the same engravers.
At any rate, this implies that TRANSLATOR_INHERIT fails doing its job
when it has to inherit overloaded template functions with a single
"using" instruction. I propose the following patch (to current
master). Does it change something for you?
>From fa45edd4db3d49817425fa7833559f20697c3c74 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Fri, 24 Jun 2016 15:10:44 +0200
Subject: [PATCH] Split overloaded `method_finder' in two
Some older g++ compilers seem unhappy about the mixture of `using'
instructions and overloading in connection with templates, so the
overloaded way of calling `method_finder' is split into `method_finder'
and `listen_finder'.
---
lily/include/translator.hh | 8 +++-
lily/include/translator.icc | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/lily/include/translator.hh b/lily/include/translator.hh
index cd05091..3a13f8a 100644
--- a/lily/include/translator.hh
+++ b/lily/include/translator.hh
@@ -39,6 +39,7 @@
#define TRANSLATOR_INHERIT(BASE)\
using BASE::method_finder;\
+ using BASE::listen_finder;\
using BASE::ack_finder;
#define DECLARE_TRANSLATOR_CALLBACKS(NAME) \
@@ -48,7 +49,7 @@
return Callback0_wrapper::make_smob (); \
} \
template\
- static SCM method_finder () \
+ static SCM listen_finder () \
{ \
return Callback_wrapper::make_smob > (); \
} \
@@ -165,6 +166,11 @@ protected: // should be private.
static SCM
method_finder () { return SCM_UNDEFINED; }
+ // Overriden elsewhere but needed for TRANSLATOR_INHERIT
+ template
+ static SCM
+ listen_finder () { return SCM_UNDEFINED; }
+
// Overriden in Engraver. Don't instantiate.
template
static SCM ack_trampoline (SCM, SCM, SCM);
diff --git a/lily/include/translator.icc b/lily/include/translator.icc
index 3d038b6..cd9fa58 100644
--- a/lily/include/translator.icc
+++ b/lily/include/translator.icc
@@ -112,7 +112,7 @@ void add_acknowledger (SCM ptr,
#define ADD_LISTENER(cl, m) \
listener_list_ = scm_acons\
(event_class_symbol (#m), \
- method_finder<&cl::listen_ ## m> (), \
+ listen_finder<&cl::listen_ ## m> (), \
listener_list_)
#endif /* TRANSLATOR_ICC */
--
2.7.4
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Jan-Peter Voigt writes:
> Hi Nathan, hi Dan,
>
> the "nearest" context might be on Staff level - or, if (for example)
> you have voices switching staves, on StaffGroup level, where a
> StaffGroup also might be a GrandStaff or the like. If the context
> property turns out to complex (I don't see all consequences yet),
> you'll have to use this static engraver member. But you should try the
> "nearest" context.
A static engraver member would be a total disaster. What happens for
stuff like
{ c1-\markup \score { \new Staff { e1 } } }
with global variables like that? What happens when the engraver is
being collected but the static member stays around without protection
from garbage collection? Or if it is protected, will it drag into the
next file to be processed on the command line?
Ids for \= could be specified as a key-list? and if it has two members
(more would be an error) the first should be a context type symbol
indicating the context the separate engravers choose to share their data
over.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Knut Petersen writes:
> Am 24.06.2016 um 15:13 schrieb David Kastrup:
>> At any rate, this implies that TRANSLATOR_INHERIT fails doing its job
>> when it has to inherit overloaded template functions with a single
>> "using" instruction. I propose the following patch (to current
>> master). Does it change something for you?
>
> No:
>
> In file included from /home/knut/sources/lily/lily/slur-engraver.cc:32:0:
> /home/knut/sources/lily/lily/slur-engraver.cc: In static member function
> 'static void Slur_engraver::boot()':
> /home/knut/sources/lily/lily/include/translator.icc:115:40: error:
> '&Slur_proto_engraver::listen_slur' is not a valid template argument for type
> 'void (Translator::*)(Stream_event*)' because it is of type 'void
> (Slur_proto_engraver::*)(Stream_event*)'
> listen_finder<&cl::listen_ ## m> (), \
> ^
> /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of
> macro 'ADD_LISTENER'
>ADD_LISTENER (Slur_engraver, slur);
>^
> /home/knut/sources/lily/lily/include/translator.icc:115:40: error:
> '&Slur_proto_engraver::listen_slur' is not a valid template argument for type
> 'void (Slur_engraver::*)(Stream_event*)' because it is of type 'void
> (Slur_proto_engraver::*)(Stream_event*)'
> listen_finder<&cl::listen_ ## m> (), \
> ^
> /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of
> macro 'ADD_LISTENER'
>ADD_LISTENER (Slur_engraver, slur);
>^
> /home/knut/sources/lily/lily/include/translator.icc:115:40: note: standard
> conversions are not allowed in this context
> listen_finder<&cl::listen_ ## m> (), \
> ^
> /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of
> macro 'ADD_LISTENER'
>ADD_LISTENER (Slur_engraver, slur);
>^
> /home/knut/sources/lily/stepmake/stepmake/c++-rules.make:4: recipe for target
> 'out/slur-engraver.o' failed
> make[1]: *** [out/slur-engraver.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> /home/knut/sources/lily/lily/staff-performer.cc: In member function 'int
> Staff_performer::get_channel(const string&)':
> /home/knut/sources/lily/lily/staff-performer.cc:295:37: warning: conversion
> to 'int' from 'std::map, int>::size_type {aka long
> unsigned int}' may alter its value [-Wconversion]
> : channel_map.size ();
> ^
> make[1]: Leaving directory '/home/knut/sources/lily/build/lily'
> /home/knut/sources/lily/stepmake/stepmake/generic-targets.make:6: recipe for
> target 'all' failed
> make: *** [all] Error 2
Weird. What happens if you swap the adjacent lines
DECLARE_TRANSLATOR_CALLBACKS (NAME); \
TRANSLATOR_INHERIT (Translator); \
in lily/include/translator.hh ?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Ok, next try.
>From 664bdeb25a2ece31bd42774e1c0c7cadb790ebf1 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Fri, 24 Jun 2016 15:10:44 +0200
Subject: [PATCH] TRANSLATOR_INHERIT -> ENGRAVER_INHERIT
In order to accommodate older g++ compilers, inheriting
methods/listeners/acknowledgers is only provided for engravers now, the
main (and so far sole) customer of this technique.
method_finder is split into both method_finder and listen_finder to
avoid trickier forms of overloading.
---
lily/auto-beam-engraver.cc | 2 +-
lily/beam-engraver.cc | 2 +-
lily/include/coherent-ligature-engraver.hh | 2 +-
lily/include/gregorian-ligature-engraver.hh | 2 +-
lily/include/translator.hh | 11 ---
lily/include/translator.icc | 2 +-
lily/kievan-ligature-engraver.cc| 2 +-
lily/mensural-ligature-engraver.cc | 2 +-
lily/phrasing-slur-engraver.cc | 2 +-
lily/slur-engraver.cc | 2 +-
lily/vaticana-ligature-engraver.cc | 2 +-
11 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/lily/auto-beam-engraver.cc b/lily/auto-beam-engraver.cc
index 3f03362..4eea5c9 100644
--- a/lily/auto-beam-engraver.cc
+++ b/lily/auto-beam-engraver.cc
@@ -579,7 +579,7 @@ ADD_TRANSLATOR (Auto_beam_engraver,
class Grace_auto_beam_engraver : public Auto_beam_engraver
{
TRANSLATOR_DECLARATIONS (Grace_auto_beam_engraver);
- TRANSLATOR_INHERIT (Auto_beam_engraver);
+ ENGRAVER_INHERIT (Auto_beam_engraver);
private:
Moment last_grace_start_; // Full starting time of last grace group
diff --git a/lily/beam-engraver.cc b/lily/beam-engraver.cc
index 9b4df64..8065c0d 100644
--- a/lily/beam-engraver.cc
+++ b/lily/beam-engraver.cc
@@ -342,7 +342,7 @@ class Grace_beam_engraver : public Beam_engraver
{
public:
TRANSLATOR_DECLARATIONS (Grace_beam_engraver);
- TRANSLATOR_INHERIT (Beam_engraver);
+ ENGRAVER_INHERIT (Beam_engraver);
protected:
virtual bool valid_start_point ();
diff --git a/lily/include/coherent-ligature-engraver.hh b/lily/include/coherent-ligature-engraver.hh
index 78bfef8..8c457dd 100644
--- a/lily/include/coherent-ligature-engraver.hh
+++ b/lily/include/coherent-ligature-engraver.hh
@@ -26,7 +26,7 @@ class Coherent_ligature_engraver : public Ligature_engraver
public:
// no TRANSLATOR_DECLARATIONS (Coherent_ligature_engraver) needed
// since this class is abstract
- TRANSLATOR_INHERIT (Ligature_engraver);
+ ENGRAVER_INHERIT (Ligature_engraver);
DECLARE_TRANSLATOR_CALLBACKS (Coherent_ligature_engraver);
protected:
diff --git a/lily/include/gregorian-ligature-engraver.hh b/lily/include/gregorian-ligature-engraver.hh
index fcac99c..7076a4f 100644
--- a/lily/include/gregorian-ligature-engraver.hh
+++ b/lily/include/gregorian-ligature-engraver.hh
@@ -29,7 +29,7 @@ public:
// no TRANSLATOR_DECLARATIONS (Gregorian_ligature_engraver) needed
// since this class is abstract
- TRANSLATOR_INHERIT(Coherent_ligature_engraver);
+ ENGRAVER_INHERIT (Coherent_ligature_engraver);
DECLARE_TRANSLATOR_CALLBACKS (Gregorian_ligature_engraver);
protected:
Gregorian_ligature_engraver ();
diff --git a/lily/include/translator.hh b/lily/include/translator.hh
index cd05091..977955b 100644
--- a/lily/include/translator.hh
+++ b/lily/include/translator.hh
@@ -34,11 +34,12 @@
VIRTUAL_COPY_CONSTRUCTOR (Translator, NAME); \
virtual void fetch_precomputable_methods (SCM methods[]); \
DECLARE_TRANSLATOR_CALLBACKS (NAME); \
- TRANSLATOR_INHERIT (Translator); \
+ using Translator::method_finder; \
/* end #define */
-#define TRANSLATOR_INHERIT(BASE)\
+#define ENGRAVER_INHERIT(BASE) \
using BASE::method_finder;\
+ using BASE::listen_finder;\
using BASE::ack_finder;
#define DECLARE_TRANSLATOR_CALLBACKS(NAME) \
@@ -48,7 +49,7 @@
return Callback0_wrapper::make_smob (); \
} \
template\
- static SCM method_finder () \
+ static SCM listen_finder () \
{ \
return Callback_wrapper::make_smob > (); \
} \
@@ -169,10 +170,6 @@ protected: // should be private.
template
static SCM ack_trampoline (SCM, SCM, SCM);
- // Overriden in Engraver. Don't instantiate.
- template
- static SCM ack_finder ();
-
Re: compiling lilypond fails
Marc Hohl writes: > Am 24.06.2016 um 10:33 schrieb David Kastrup: > [...] >> >> Well, it got through patchy-staging. So obviously something is >> different with your setup, and you don't give any information about your >> setup. What does g++ --version say? > > $ g++ --version > g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4 > Copyright (C) 2013 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > >> >> You used git pull (rather than git pull -r). That causes a merge rather >> than a rebase. Recent changes in master happened to be reverts which >> did not apply cleanly but had to be significantly edited. >> >> Adding merge resolution on top might lead to problems. > > As mentioned earlier, I started from scratch just to be on the safe side: > > $ git clone git://git.sv.gnu.org/lilypond.git ./lilypond > $ cd lilypond > $ ./autogen.sh > $ make -j3 > > The error remains. Yeah, it seems to be g++ 4 vs g++ 5 (and g++ 6, according to Federico(?) crashes somewhere else. Great.) Let's see how my last proposal fares. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Knut Petersen writes: > Am 24.06.2016 um 16:43 schrieb David Kastrup: >> Ok, next try. >> > > On top of HEAD: > > In file included from /home/knut/sources/lily/lily/slur-engraver.cc:32:0: > /home/knut/sources/lily/lily/slur-engraver.cc: In static member function > 'static void Slur_engraver::boot()': > /home/knut/sources/lily/lily/include/translator.icc:115:40: error: > '&Slur_proto_engraver::listen_slur' is not a valid template argument for type > 'void (Slur_engraver::*)(Stream_event*)' because it is of type 'void > (Slur_proto_engraver::*)(Stream_event*)' > listen_finder<&cl::listen_ ## m> (), \ > ^ > /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of > macro 'ADD_LISTENER' >ADD_LISTENER (Slur_engraver, slur); >^ > /home/knut/sources/lily/lily/include/translator.icc:115:40: note: standard > conversions are not allowed in this context > listen_finder<&cl::listen_ ## m> (), \ > ^ > /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of > macro 'ADD_LISTENER' >ADD_LISTENER (Slur_engraver, slur); >^ Running out of ideas here. Can you run this with -k (which means keep going upon error) and direct error output to file, like 2>/tmp/make.log ? I have a hard time understanding why this blows up and nothing else, and maybe it's just because it is encountered first? make -k should clear that up. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Knut Petersen writes: > Am 24.06.2016 um 18:15 schrieb David Kastrup: >> Knut Petersen writes: >> >>> Am 24.06.2016 um 16:43 schrieb David Kastrup: >>>> Ok, next try. >>>> >>> On top of HEAD: >>> >>> In file included from /home/knut/sources/lily/lily/slur-engraver.cc:32:0: >>> /home/knut/sources/lily/lily/slur-engraver.cc: In static member function >>> 'static void Slur_engraver::boot()': >>> /home/knut/sources/lily/lily/include/translator.icc:115:40: error: >>> '&Slur_proto_engraver::listen_slur' is not a valid template argument for >>> type 'void (Slur_engraver::*)(Stream_event*)' because it is of type 'void >>> (Slur_proto_engraver::*)(Stream_event*)' >>>listen_finder<&cl::listen_ ## m> (), \ >>> ^ >>> /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of >>> macro 'ADD_LISTENER' >>> ADD_LISTENER (Slur_engraver, slur); >>> ^ >>> /home/knut/sources/lily/lily/include/translator.icc:115:40: note: standard >>> conversions are not allowed in this context >>>listen_finder<&cl::listen_ ## m> (), \ >>> ^ >>> /home/knut/sources/lily/lily/slur-engraver.cc:65:3: note: in expansion of >>> macro 'ADD_LISTENER' >>> ADD_LISTENER (Slur_engraver, slur); >>> ^ >> Running out of ideas here. Can you run this with -k (which means keep >> going upon error) and direct error output to file, like 2>/tmp/make.log ? > > source: 975d6f176453d35367e3fa4... + > 0001-TRANSLATOR_INHERIT-ENGRAVER_INHERIT.patch > > autogen.sh --noconfigure > configure --prefix=/home/knut/sources/lilybisect/ > make -k -j 1 CPU_COUNT=1 all > > Logfile attached. I see a single error. That's ... curious. Have to go to rehearsal now, will investigate later. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
David Kastrup writes: >> autogen.sh --noconfigure >> configure --prefix=/home/knut/sources/lilybisect/ >> make -k -j 1 CPU_COUNT=1 all >> >> Logfile attached. > > I see a single error. That's ... curious. Have to go to rehearsal now, > will investigate later. Ok, I'll just push issue 4903 out right now. Not because I think it will fix the problem: I cannot really imagine that. Merely because it moves the goal posts far enough that I am loath to try finding a solution for a problem that might or might not still apply two days later. I'll try picking up further on the problem in its then current state tomorrow. Sorry for the extra work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
David Kastrup writes: > David Kastrup writes: > >>> autogen.sh --noconfigure >>> configure --prefix=/home/knut/sources/lilybisect/ >>> make -k -j 1 CPU_COUNT=1 all >>> >>> Logfile attached. >> >> I see a single error. That's ... curious. Have to go to rehearsal now, >> will investigate later. > > Ok, I'll just push issue 4903 out right now. Not because I think it > will fix the problem: I cannot really imagine that. Merely because it > moves the goal posts far enough that I am loath to try finding a > solution for a problem that might or might not still apply two days > later. > > I'll try picking up further on the problem in its then current state > tomorrow. > > Sorry for the extra work. Ok, issue 4903 is now in master. What's the news on make -k output now? Does applying the last patch (the one with ENGRAVER_INHERIT in its title) make any difference in the amount of reported errors? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
David Kastrup writes: > David Kastrup writes: > >> David Kastrup writes: >> >>>> autogen.sh --noconfigure >>>> configure --prefix=/home/knut/sources/lilybisect/ >>>> make -k -j 1 CPU_COUNT=1 all >>>> >>>> Logfile attached. >>> >>> I see a single error. That's ... curious. Have to go to rehearsal now, >>> will investigate later. >> >> Ok, I'll just push issue 4903 out right now. Not because I think it >> will fix the problem: I cannot really imagine that. Merely because it >> moves the goal posts far enough that I am loath to try finding a >> solution for a problem that might or might not still apply two days >> later. >> >> I'll try picking up further on the problem in its then current state >> tomorrow. >> >> Sorry for the extra work. > > Ok, issue 4903 is now in master. What's the news on make -k output now? > Does applying the last patch (the one with ENGRAVER_INHERIT in its > title) make any difference in the amount of reported errors? Sigh. I can answer this myself I think. After installing g++-4.8 and using ./configure CXX="g++-4.8 -m64" PYTHON_CONFIG="no" (the -m64 is because I installed 64bit guile libraries since guile does not seem to support multilib, and the PYTHON_CONFIG="no" is because python-config --cflags puts out several flags not supported by g++-4.8) I've been able to reproduce the error from yesterday. But it compiles on the code of today. So 4903 seems to fix this problem as a side effect; I have no good idea why. But it seems somewhat pointless to go hunting after it until it actually reoccurs. I'll test the next few changes in this area with this setup before submitting anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
Knut Petersen writes: > Am 25.06.2016 um 10:36 schrieb David Kastrup: >> Ok, issue 4903 is now in master. What's the news on make -k output >> now? Does applying the last patch (the one with ENGRAVER_INHERIT in >> its title) make any difference in the amount of reported errors? > > knut@golem:~/sources/lily> ../mklily > > Building lilypond 01cf114a7808fb0d519d0619f6f56c524ce60399... this > will take some time ;-) > > exec ./autogen.sh --noconfigure in /home/knut/sources/lily > ... succeeded after 0 seconds > exec ../configure --prefix=/home/knut/sources/lilybisect/ in > /home/knut/sources/lily/build ... succeeded after 5 seconds > exec make -k -j 11 CPU_COUNT=11 all in /home/knut/sources/lily/build > ... succeeded after 71 seconds > exec make -j 11 CPU_COUNT=11 install in /home/knut/sources/lily/build > ... succeeded after 2 seconds > exec make -j 11 CPU_COUNT=11 doc in /home/knut/sources/lily/build > ... succeeded after 795 seconds > exec make -j 11 CPU_COUNT=11 install-doc in > /home/knut/sources/lily/build ... succeeded after 4 seconds > Total lilypond build time: 877 seconds > > So everything looks fine again. Not with my current patch-in-progress. g++-4.8 seems to do some kind of "overloading resolution" by just randomly picking a candidate from several it fails to distinguish and then complaining when it does not fit. The errors I am getting seem sort of arbitrary regarding the failing template argument candidates. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling lilypond fails
David Kastrup writes: > Not with my current patch-in-progress. g++-4.8 seems to do some kind > of "overloading resolution" by just randomly picking a candidate from > several it fails to distinguish and then complaining when it does not > fit. The errors I am getting seem sort of arbitrary regarding the > failing template argument candidates. Ok, I got it. It's Slur_engraver::listen_slur which is available in two overloaded versions. Renaming the two-argument version to something else brings g++-4.8 back into understanding. Gratuitous complexity. I should have known better than that. Admittedly, that was rather ugly. A useful error message would have been nice, but instead GCC resolved something else prematurely and then got stuck. Or so. At any rate, it's reasonably easy to get this out of the way. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Jan-Peter Voigt writes:
> Hi all,
>
> @David: thank you for your "emergency call"!
> @Nathan: sorry, for giving you bad advise in this case!
>
> To summarize, what to do with spanners, tagged with an ID: Use context
> properties to store them "globally". You can consider the Score
> context "global". If there is a context defined with \=Staff.myid,
> store it in a context property of - in this case - the Staff context.
>
> Whenever you are up to using static members, change it to properties
> of the Score context - or look for session global objects.
"Session global" does not work with score markups in music:
>>A static engraver member would be a total disaster. What happens for
>>stuff like
>>
>>{ c1-\markup \score { \new Staff { e1 } } }
>>
>>with global variables like that?
Anything following the progress of typesetting has to run through
engraver-local variables and context properties.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fun with upgrades - not
Phil Holmes writes: > Last week I decided to bite the bullet and upgrade from Ubuntu 10.04 to a > more recent version. I downloaded an upgrade to 12.04, and then used that > to do an online upgrade to 14.04. As a result of this, I lost most of the > applications needed to build LilyPond. I've grabbed a number of then with > the software installer or apt, but gave that up for a while whilst I > needed the machine for another purpose. sudo apt-get build-dep lilypond > This was to run a Windows 7 VM - I use this with Adobe Lightroom 6 > (which won't run on my Vista desktop) for editing my photos. So I > installed the latest Oracle VirtualBox and discovered that 14.04 > mounts its disks in media/username, meaning that VB could not find the > image of my VM. I hacked the set up file by hand, and got the VM > running. Problem is, it runs like a complete drain, taking about two > minutes to move between photos. The VM on 10.04 was instantaneous. > No idea why this should be, but I got so p**sed of with it that I've > ordered a new PC just for my photography. Hope that someone else has useful advice: I never ran on a VM. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fun with upgrades - not
Federico Bruni writes: > Il giorno mar 28 giu 2016 alle 19:27, James ha scritto: >>> I would first try to set up the system and avoid virtual machines >>> for LilyPond development. >>> Installing the dependencies should be as easy as: >>> >>> sudo apt-get build-dep lilypond >> >> Except when it isn't. >> >> I.e. all those extra bits that are documented in the CG. >> >> I did a bit of work on a number of Distributions and have had to >> document those little idiosyncrasies there. >> >> http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#requirements-for-compiling-lilypond > > Ok, but the point is that it usually works quite easily, at least in > my experience. > > BTW, today I've set up a Debian container with debootstrap and > systemd-container, to work around the problem of GCC6 in Fedora. It > seems a very nice way to have a controlled environment for lilypond > development. I think I'll send some notes soon in this list, in case > someone wants to try it out. As soon as GCC6 becomes usefully available for Ubuntu, I'll likely go after the problem if it persists. At the current point of time, particularly with my somewhat weird 32/64-bit setup, that would be a lot of effort. I do think that GCC6 is rather bleeding-edge right now and I doubt you'd find it in RedHat (which uses Fedora as sort of a pretest platform) yet. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Nathan Chou writes: > Hello, > > I have tried the same idea with context properties, and it seems to > work just as well as my previous approach with a static member. (To > summarize: cross voice spanners and the voice they currently belong to > are stored in a property of some context containing both voices, like > Score. Each voice's engraver checks this property in its parent > contexts during an engraving step, and acts on the spanners that > currently belong to its voice.) Thanks again for the suggestion! > > There is a detail I would like to clarify. David suggested allowing \= > to optionally specify the parent context in which a cross-voice > spanner's information is shared (although I am not sure how that would > be done with a key-list, since I think the spanner id itself is a > string). Right. Maybe it should rather be a key? That would also make comparison generally faster than string comparisons. > If this context is not specified, should it default to Score or Staff > (or something else)? Nothing at all? Namely don't look anywhere else unless asked for? > Also, I am trying to implement this by setting a property of the span > event to the indicated context symbol; is that a reasonable approach? Probably. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Urs Liska writes: > Am 30.06.2016 um 11:52 schrieb David Kastrup: >>> There is a detail I would like to clarify. David suggested allowing \= >>> > to optionally specify the parent context in which a cross-voice >>> > spanner's information is shared (although I am not sure how that would >>> > be done with a key-list, since I think the spanner id itself is a >>> > string). >> Right. Maybe it should rather be a key? That would also make >> comparison generally faster than string comparisons. >> > > Please consider keeping that as a string. > When we might start interacting with XML formats (MusicXML, MEI) we'll > have to deal with string xmlid attributes. What forms can they take? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Urs Liska writes: > Am 30.06.2016 um 14:05 schrieb David Kastrup: >> Urs Liska writes: >> >>> Am 30.06.2016 um 11:52 schrieb David Kastrup: >>>>> There is a detail I would like to clarify. David suggested allowing \= >>>>>> to optionally specify the parent context in which a cross-voice >>>>>> spanner's information is shared (although I am not sure how that would >>>>>> be done with a key-list, since I think the spanner id itself is a >>>>>> string). >>>> Right. Maybe it should rather be a key? That would also make >>>> comparison generally faster than string comparisons. >>>> >>> Please consider keeping that as a string. >>> When we might start interacting with XML formats (MusicXML, MEI) we'll >>> have to deal with string xmlid attributes. >> What forms can they take? > > Well, basically whatever a given project may come up with or what an XML > editor may choose to auto-generate or whatever. > The following is from a file on http://verovio.org > > > > > oct="3" dur="8" dots="1" stem.dir="up" accid.ges="f"/> > oct="3" dur="16" stem.dir="up" accid.ges="f"/> > > > oct="3" dur="8" dots="1" stem.dir="up" accid.ges="f"/> > oct="4" dur="16" stem.dir="up"/> > > oct="4" dur="4" stem.dir="up"/> > > Those are rather simple. > but I have also seen some more or less intuitive schemes attributing > some semantic information to them (context, timing etc.). They might as > well be timestamps and/or generated GUIDs. > > So, basically anything that a string can hold. How does that differ from symbols? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Urs Liska writes: > Am 30.06.2016 um 14:37 schrieb David Kastrup: > >> How does that differ from symbols? > > Ah, not in the Scheme domain, of course. But you can't *enter* them as > LilyPond code, isn't it? Can you give an example for symbols "entered as LilyPond code" as opposed to "in the Scheme domain"? Do you mean "without using #" here? Why would it be relevant to XML how you entered a symbol? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Urs Liska writes:
> Am 30.06.2016 um 14:47 schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 30.06.2016 um 14:37 schrieb David Kastrup:
>>>
>>>> How does that differ from symbols?
>>> Ah, not in the Scheme domain, of course. But you can't *enter* them as
>>> LilyPond code, isn't it?
>> Can you give an example for symbols "entered as LilyPond code" as
>> opposed to "in the Scheme domain"?
>
> Ah, I mean
>
> #(define %9sn5@ "a")
> %9sn5@ = "a"
>
> but ...
>
>>
>> Do you mean "without using #" here? Why would it be relevant to XML how
>> you entered a symbol?
>
> of course that doesn't matter here as you can always write
>
> \override NoteHead.id = #'09fjwg@
Well, there are a few strings requiring more complex input:
guile> (string->symbol "()")
#{\(\)}#
guile> (string->symbol "3")
#{3}#
But numbers in particular we'd likely convert to actual number keys.
And it's not like we don't have symbols in a few other places (tags, for
example). So all in all, I think it should not be too much of a
nuisance.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Responsiveness in the next days
Hi folks, it would appear that the graphics card on my laptop died on me. After an hour of black screen, it now managed to shut down and reboot in some low-resolution mode. I don't know how often I'll manage that however. I'll likely need to take this one apart and look for loose connectors and if nothing else works, transfer the working parts into another computer (among two mostly identical laptops, I have one working keyboard, one working fan assembly and so on). Since this seems like a graphics card near-death, an external monitor does not help. Depending on my amount of success here, I might be of little availability in the next days. Sorry for that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Responsiveness in the next days
David Kastrup writes: > Hi folks, > > it would appear that the graphics card on my laptop died on me. After > an hour of black screen, it now managed to shut down and reboot in some > low-resolution mode. I don't know how often I'll manage that however. > I'll likely need to take this one apart and look for loose connectors > and if nothing else works, transfer the working parts into another > computer (among two mostly identical laptops, I have one working > keyboard, one working fan assembly and so on). > > Since this seems like a graphics card near-death, an external monitor > does not help. > > Depending on my amount of success here, I might be of little > availability in the next days. > > Sorry for that. Looks like false alarm right now. Functionality returned. I doubt it was a temperature problem (persisted too long even when switching the computer off). Maybe humidity that had to dissolve? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Nathan Chou writes: > Thanks David and Urs for replying. > >>> There is a detail I would like to clarify. David suggested allowing \= >>> to optionally specify the parent context in which a cross-voice >>> spanner's information is shared (although I am not sure how that would >>> be done with a key-list, since I think the spanner id itself is a >>> string). >> >> Right. Maybe it should rather be a key? That would also make >> comparison generally faster than string comparisons. > > Would I convert a string input to a key, or should I only accept a key > as a valid id? The latter seems more convenient but I imagine would > break backward compatibility. Slightly so. I'd still aim for that. The original approach seems un-Schemish anyway. A symbol as unique identifier is what symbols are intended for. >>> If this context is not specified, should it default to Score or Staff >>> (or something else)? >> >> Nothing at all? Namely don't look anywhere else unless asked for? > > So cross voice spanners should only work if the context to share > information is specified, right? If the context is not specified and > there is no default, the spanner id would only be used within the same > voice and not made known to any other contexts. I think that would provide clear and obvious semantics. That's an advantage. It's also somewhat cumbersome. I think that the expected frequency of occurence is low enough that the overall balance between obviousness and convenience looks favorable to me. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Urs Liska writes: > Am 01.07.2016 um 09:28 schrieb Jan-Peter Voigt: >>> Hm. If this is a limitation required by the implementation then it's >>> acceptable. But from a user perspective I would be very surprised if an >>> ID isn't recognized without an explicitly named context around it. Isn't >>> that the (one) idea of an ID in general, defining an ID and have it >>> addressable from anywhere? >> Well, the spanner-id is used right now to have multiple slurs (or >> other spanners) in the same Voice. So keeping the spanner-ids in the >> current Voice would only preserve the current behaviour, if no other >> context is given. But OTOH (IISC) it wouldn't break the current >> implementation, as long, as IDs are Score-unique and not only >> Voice-unique. My preference would be to place it in the Score-context. > > I think for the given task (freeing spanners from the voice context > limitation) it is clear that we'll require IDs to be unique within the > whole score. But that means that you can no longer let people write individual parts with several spanner ids independently even when there never is even going to be any cross-Voice spanner. Spanner-ids like \=1 \=2 are not likely to be unique when they are needed in independently written parts. So you start trying to make rules which spanner-ids are only supposed to be used locally and which are supposed to be unique at some level. And which level is better? Staff or Score? Lots and lots of decisions which are actually best made in connection with an actual score. And when they are written into the score, you don't need to look them up or second-guess them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Nathan Chou writes:
> On Fri, Jul 1, 2016 at 12:48 AM, David Kastrup wrote:
>> But that means that you can no longer let people write individual parts
>> with several spanner ids independently even when there never is even
>> going to be any cross-Voice spanner. Spanner-ids like \=1 \=2 are not
>> likely to be unique when they are needed in independently written parts.
>> So you start trying to make rules which spanner-ids are only supposed to
>> be used locally and which are supposed to be unique at some level. And
>> which level is better? Staff or Score?
>>
>> Lots and lots of decisions which are actually best made in connection
>> with an actual score. And when they are written into the score, you
>> don't need to look them up or second-guess them.
>
> That is a good point; I might agree with spanner id's not being shared
> across voices if nothing has been indicated. To make this less
> tedious, however: what if after the parent context in which to share
> spanners has been given once, future spanner id's (in the same voice)
> default to share in that context? Or alternatively, perhaps this
> parent share context could be set as a context property, allowing the
> user to indicate a "default"?
How often are you expected to write this?
> Also, since I am accepting a key-list which includes indexes, should I
> treat, for example, the number 1 and the symbol #{1}# as the same id?
I wouldn't. Other key-list uses don't. The symbol #{1}# is more of a
curiosity than anything one wants to use regularly. Basically, I would
change spanner-id to be a key (which does not include symbols). This
would be a deliberate incompatibility and would mean using eqv (or
ly_is_equal) for comparing spanner id's instead of string comparison.
The spanner-id role of "" would be likely be taken over by the default
'() value.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GSoC] spanners project update
Nathan Chou writes: > On Tue, Jul 5, 2016 at 1:54 AM, David Kastrup wrote: >> Nathan Chou writes: >>> That is a good point; I might agree with spanner id's not being shared >>> across voices if nothing has been indicated. To make this less >>> tedious, however: what if after the parent context in which to share >>> spanners has been given once, future spanner id's (in the same voice) >>> default to share in that context? Or alternatively, perhaps this >>> parent share context could be set as a context property, allowing the >>> user to indicate a "default"? >> >> How often are you expected to write this? > > If I understand correctly, my idea was that after you write the shared > parent context *once*, future cross-voice spanners in that voice would > by default share in that context; or alternatively, the shared parent > context would be set *once* as a context property. My question rather was "how often are you expected to use cross-voice spanners that the savings would be worth the trouble?". We don't use a similar address-saving technique for, say, \override. > Although I am now having doubts since it does make sense for the > default blank spanner id (i.e. when no id is given) to not be shared > across voices, regardless of the presence of cross voice spanners. For > now I will never share spanner ids unless the context is indicated > with \=. I think that's sanest. > I am currently working on warnings for unterminated spanners. However, > when I lookup the context property to identify such spanners, and that > property was never set, Context::internal_get_property attempts to > look in higher contexts, which sometimes causes warnings for contexts > that have not actually ended. Does adding an optional argument to > internal_get_property to prevent looking in higher contexts seem > reasonable? Anything wrong with Context::here_defined ? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
