Re: Use a pointer for the output parameter of Lily_lexer::scan_word (issue 577440044 by hanw...@gmail.com)

[Dan Eble]

On Feb 1, 2020, at 09:59, David Kastrup  wrote:
> 
> even with a reference parameter.  Of course this does not "really" give
> an indication about this being in-out, but neither does 

That's an important point.  What indicates that a parameter is _not_ an 
out-parameter is "const".  You might happen to have that near enough to the 
call site to be helpful.

const Foo& foo = ...;
int mp = calc_midpoint (foo);

Where you don't have that, and you want to leave no doubt that a function does 
not modify your object, you can declare a separate const reference and pass 
that, or you can use a convenience function like std::as_const from C++17,

Foo foo;
string s = to_string (ly::as_const (foo));
...
return calc_midpoint (foo); // might modify foo

I hope that that example makes as_const and "might modify foo" look like the 
result of an overabundance of caution.  I don't mean to suggest that as_const 
or comments should be dictated in situations like this anymore than I think 
that passing out-parameters as pointers should be dictated.
--
Dan

Regtest profiling differences

[Dan Eble]

I've noticed a subjective increase in profiling differences in regtests since 
updating to the latest master this morning 
(bc8a3fa7e4f12bf5ac1eb0293bfab658d52c4ae8), even from one run to another on 
unchanged code.

There are also log differences that might be correlated, with some test cases 
having

-
-Writing timing to ./lily-run-total.profile...
-Success: compilation successfully completed

and others having

+
+Writing timing to ./lily-run-total.profile...
+Success: compilation successfully completed

I've only run regtests a couple of times so far, so I'm not sure how repeatable 
this is.  Were there recent changes that might contribute to this?  Nothing 
stands out to me in the headlines.

Thanks,
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Feb 1, 2020, at 06:39, David Kastrup  wrote:
> 
>> You provided a lot of good information in your post, but the
>> conclusion was not entirely clear.
>> Are you suggesting requiring SSE2 at this time?
> 
> Yes.  It appears to get used anyway for 64bit executables, and it seems
> safe enough to demand it for 32bit executables.

+1
far better than inline asm poking control registers
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Feb 1, 2020, at 05:05, David Kastrup  wrote:
> 
> Frankly, I think that it would be better if our Windows executables just
> moved to 64bit but that seems like the more complicated option yet. And
> 32bit systems kept around a whole lot longer even after processors
> became 64bit-capable because they tended to require less memory.

You provided a lot of good information in your post, but the conclusion was not 
entirely clear.
Are you suggesting requiring SSE2 at this time?
— 
Dan

Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by hanw...@gmail.com)

[Dan Eble]

On Jan 31, 2020, at 13:33, hanw...@gmail.com wrote:
> 
> On 2020/01/31 18:22:47, Dan Eble wrote:
>> On 2020/01/31 17:52:45, hanwenn wrote:
>>> you can do a local alias
>>> 
>>>  vector<>  = *vec;
>>> 
>>> to aid readability.
>> 
>> The more I think about banning non-const reference parameters, the
> more I'm
>> against it.  Google's coding standards may work for them, but their
> rationale*
>> for this one is weak.  How can we resolve this disagreement quickly? 
> Do you
>> simply have the final say as the project founder?
> 
> Can we have this discussion on a thread separate from this code review?
> I want this code to go in.

Well, you can't prevent people from replying to their email, but neither can 
their replies prevent you from pushing commits.
— 
Dan

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

[Dan Eble]

On Jan 31, 2020, at 08:31, David Kastrup  wrote:
>   -fexcess-precision=style
>   This option allows further control over excess precision on
>   machines where floating-point operations occur in a format
>   with more precision or range than the IEEE standard and
>   interchange floating-point types.  By default,
>   -fexcess-precision=fast is in effect; this means that
>   operations may be carried out in a wider precision than the
>   types specified in the source if that would result in faster
>   code, and it is unpredictable when rounding to the types
>   specified in the source code takes place.

This sounds promising.

>   -fexcess-precision=standard is not implemented for languages
>   other than C.

Never mind.
— 
Dan

Re: PropertySet with unbound value

[Dan Eble]

On Jan 30, 2020, at 19:28, David Kastrup  wrote:
> 
> It's conceivable that the code was dead afterwards.  I am not sure.

Seems likely to me.
https://codereview.appspot.com/557260047/
— 
Dan

PropertySet with unbound value

[Dan Eble]

Does anyone have an idea of input I could provide to reach the block with the 
TODO below?  I've tried 

#(make-music 'PropertySet 'symbol 'fingeringOrientations)

(note that no value is defined), but it wasn't enough.  TIA.

void
Context::set_property_from_event (SCM sev)
{
  Stream_event *ev = unsmob (sev);

  SCM sym = ev->get_property ("symbol");
  if (scm_is_symbol (sym))
{
  SCM val = ev->get_property ("value");

  if (SCM_UNBNDP (val)) {
// TODO: It looks like this ignores \once.
// Should this be unset_property_from event (sev)?
unset_property (sym);
return;
  }
...
— 
Dan

Re: stable/2.20 branch does not complete "make doc"

[Dan Eble]

On Jan 30, 2020, at 14:57, David Kastrup  wrote:
> 
> os.symlink ("../../../out-baseline/share", 
> "out-www/offline-root/input/regression/out-test-baseline/share")
> 
> What has the test baseline to do with make doc ?


Try cherry-picking this:

commit dbe42f99406cd415c4b7d1f7349cd3e17ed73e69
Author: Dan Eble 
Date:   Wed Oct 23 09:26:24 2019 -0400

Issue 5583: www_post.py: don't mirror regtest baseline

--
Dan

Re: stable/2.20 branch does not complete "make doc"

[Dan Eble]

On Jan 30, 2020, at 13:39, David Kastrup  wrote:
> 
>> I just had a successful mage -j5 doc as of commit
>> 8a05312fd8d2a56ec724a793b313949db0cfe729
> 
> Current stable/2.20 which failed on my system.

I also am not able to reproduce the problem in a clean workspace; but I have 
verified that I want more cores. :)

> Traceback (most recent call last):
>  File "/usr/local/tmp/lilypond/scripts/build/out/www_post", line 101, in 
> 
>os.symlink (p, dest)
> OSError: [Errno 2] No such file or directory
> # clear __builtin__._
> # clear sys.path
> # clear sys.argv
> # clear sys.ps1
> # clear sys.ps2
> 
> in the central portion.  Which does not appear to help at all.  Any idea
> what I could/should do to figure out where stuff goes wrong with my
> system?  One thing I could do is check with current master.

How about editing www_post to print the values of p and dest so we can see for 
which file os.symlink is failing?
— 
Dan

Re: stable/2.20 branch does not complete "make doc"

[Dan Eble]

On Jan 30, 2020, at 11:39, David Kastrup  wrote:
> That's not a new development, so there is no point in me to refrain from
> cherry-picking further material: the last version of the branch I
> checked was from early December and it failed in the same manner.
> Compilation of CPU_COUNT=9 make -j9 doc ends with

I did a bunch of build-related stuff in Oct-Nov, but this doesn't trigger any 
specific memories.  After I eat lunch, I'll try to reproduce the problem and 
see if I can spot anything helpful.
— 
Dan

Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by hanw...@gmail.com)

[Dan Eble]

On Jan 30, 2020, at 04:54, hanw...@gmail.com wrote:
> 
> This may predate you, but the decision to not store references was
> intentional,
> exactly because storing NULL in them is very useful.  If you have a
> reference,
> it has to be initialized in the constructor, and this introduces a lot
> of boilerplate
> because you have to pass the non-null reference across constructors in
> the class
> hierarchy. 

The discussion has turned from (a) passing a required parameter as a reference, 
to (b) using a reference as a member variable.  (a) does not imply (b).  You 
can pass in a T& and store it in a T* to avoid the constraints that (b) would 
place on the use of your class (though they apparently were not previously a 
problem in this case).

> The current code overwhelmingly disavows references. The 2 remaining
> uses (this being one) stand out like a sore thumb.

We must be miscommunicating, because I see a lot more than 2.  For some 
examples,

git grep 'vector<[^>]\+> &'

Please clarify.

Thanks,
— 
Dan

Re: 2.91.84 - windows-only bugs

[Dan Eble]

> On Jan 29, 2020, at 10:17, Masamichi Hosoda  wrote:
> 
>> I ask because, in the german forum Arnold found a method to cure some
>> windows-only bugs., about mis-predicted force and probably several
>> assertion-failures:
>> https://lilypondforum.de/index.php/topic,609.msg3463.html#msg3463
> 
> The patch is very interesting.

+  fprintf(stderr, " X87 FPU setup via asm() ... ");
+  asm(
+  " push %ebp"
+"\n mov  $0x027f, %eax"
+"\n push %eax"
+"\n mov  %esp, %ebp"
+"\n fldcw (%ebp)"
+"\n pop %eax"
+"\n pop %ebp"
+  );
+  fprintf(stderr, "done.\r \r");

What does this do?  Is it something that could be handled portably with these 
C++11 functions?
https://en.cppreference.com/w/cpp/numeric/fenv
— 
Dan

Re: automated formatting

[Dan Eble]

On Jan 28, 2020, at 12:11, Carl Sorensen  wrote:
>Can you provide me with a presubmit hook that applies fixcc? Can you
>guarantee that, if fixcc has run on the code, there will be no further
>remarks on code formatting during review?
> 
> I think that it's a really good idea to have presubmit hooks.  I believe, but 
> can't guarantee, that if all code were automatically reformatted on 
> submission (by either fixcc or clang-format) there would be virtually no 
> comments on formatting.  And you could completely ignore any that were made.

I'm all for making it possible for a contributor to set up something like this 
if he pleases, but I think it's a bad idea to rely on this level of automation 
and integration with a specific source-control tool.

I don't trust restyling programs to do the most desirable thing for readability 
100% of the time, and I especially don't trust them in certain situations, such 
as when I'm checking in incomplete work because of an urgent need to switch to 
another branch.

Also, our basic goal is that none of the cooks poisons the soup, i.e. merges 
badly formatted code to master.  If some of them want to experiment with wild 
mushrooms on the side, micromanaging their commits doesn't guard the soup any 
better than checking when they present their work for integration.

If you build a style check into "make check", then it will happen whenever 
contributors test their code and it will happen during the review countdown.  
If you also build a style check into the final tests before merging staging to 
master, the goal will be achieved.
— 
Dan

Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Jan 27, 2020, at 10:13, David Kastrup  wrote:
> 
> None relevant to GCC and Clang as far as I can see.  Can you clarify for
> which platforms you expect a practical concern?

No.  That would require a level of effort that is a reason I never mentioned 
these things before.
— 
Dan

Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Jan 27, 2020, at 09:33, David Kastrup  wrote:
> 
>> I would like to replace the following with standard types (uint8_t
>> etc.).  The standard types are portable, but these are not.
...
>>  * flower-proto.hh:typedef unsigned U32;
>>  * flower-proto.hh:typedef int I32;
...
> I don't really mind here, but "portable" practically means just portable
> to GCC and Clang which closely follows GCC, so it's not a problem in

I was thinking of differences in data model, e.g. "unsigned" and "int" might 
have as few as 16 bits.  See some examples at 
https://en.cppreference.com/w/cpp/language/types .
— 
Dan

Re: automated formatting

[Dan Eble]

On Jan 27, 2020, at 07:43, David Kastrup  wrote:
> 
> Frankly, I just forgot about either.  I think it would be a good idea to
> take up this practice again.  Regarding Clang: unless Astyle falls apart
> using C++11 constructs that are going to occur more frequently in
> future, I think there is little reason to depart from its use instead of
> reverting to Clang.

I have learned not to fuss about the particulars of required style as long as I 
have the following:

1. a simple way to exclude sections of code manually

2. a style check integrated into "make check"

3. a makefile target that automatically restyles all source so that "make 
check" will pass.  Only the files that need to be modified are touched.  This 
runs only when requested, never as a prerequisite of any other target.
— 
Dan

Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Jan 27, 2020, at 03:26, hanw...@gmail.com wrote:
> 
> LGTM
> 
> Not for this change, but could we do a global 
> 
>  vsize -> size_t
> 
> search & replace.  Do we have a reason to keep our own typedef for this?

I fully support this.  I wasn't going to bring it up yet because I worried that 
it would lead to a lot of discussion and I have bigger fish to fry, but I would 
like to eliminate the following from flower because they reduce clarity.

  * real.hh:typedef double Real;
  * std-string.hh:typedef size_t ssize;
  * std-vector.hh:typedef size_t vsize;

I would like to replace the following with standard types (uint8_t etc.).  The 
standard types are portable, but these are not.

  * flower-proto.hh:typedef unsigned char Byte;
  * flower-proto.hh:typedef long long I64;
  * flower-proto.hh:typedef unsigned char U8;
  * flower-proto.hh:typedef short I16;
  * flower-proto.hh:typedef unsigned short U16;
  * flower-proto.hh:typedef unsigned U32;
  * flower-proto.hh:typedef int I32;
  * flower-proto.hh:typedef unsigned long long U64;
— 
Dan

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Jan 25, 2020, at 07:26, David Kastrup  wrote:
> 
> -  Interval hex = head->extent (common_[X_AXIS], X_AXIS);
> +  Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
...
> 
> That last part applies part of a patch from an unrelated issue of
> Han-Wen.  Please don't do stuff like that, if necessary using

It does not apply a patch from Han-Wen.  It necessarily renames that variable 
prior to a scripted replacement of "hex" with "std::hex".  I wonder whether the 
task would have been easier if I had used a different name for the variable.

> Please don't do stuff like that, if necessary using
> 
> git reset --hard

I don't understand from this description exactly problem you experienced and 
where in my development process you would have wanted me to use that command.
— 
Dan

Re: gub fail/local-build-script/new bug?

[Dan Eble]

On Jan 24, 2020, at 16:19, David Kastrup  wrote:
> 
> It may be enough to call GCC with --std=g++11 (?) option without
> updating GCC itself, but I don't really have an idea.

GUB is using GCC 4.9.4 [1].

I've compiled the following program with Compiler Explorer [2] using that 
version of g++:

#include 

int main()
{
  std::to_string(13);
  return 0;
}

With the default command line, the compiler complains that "'to_string' is not 
a member of 'std'".  After adding the option "-std=c++11", the program compiles.

In stepmake/stepmake/c++-vars.make, EXTRA_CXXFLAGS is defined with "-std=c++11" 
in it, so I don't understand why Harm is having trouble.

Could something in GUB be overriding that option?
— 
Dan

[1] https://lists.gnu.org/archive/html/lilypond-devel/2019-12/msg00072.html
[2] https://godbolt.org

Re: gub fail/local-build-script/new bug?

[Dan Eble]

On Jan 24, 2020, at 15:13, David Kastrup  wrote:
> 
> Thomas Morley mailto:thomasmorle...@gmail.com>> 
> writes:
...
>> In member function 'std::string Interval_t::to_string() const':
>> /home/hermann/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/include/interval.tcc:142:14:
>> error: 'std::to_string' has not been declared
...
>> Probably:
>> 
>> commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d
>> Author: Dan Eble 
>> Date:   Sat Jan 11 08:55:36 2020 -0500
>> 
>>Issue 5659/8: Remove Interval_t::T_to_string ()

This is probably not the root cause, for though this tries to use 
std::to_string(), the reason it does so is because several preceding commits 
that removed ::to_string() overloads that were duplicating the function of 
std::to_string().  I think if you reverted just this commit, you'd hit an 
undefined std::to_string() elsewhere.

> Our current source code assumes more or less C++11 I think, and GUB
> compilers might not be up to it?

This seems likely.  (Have I mentioned how tiresome GUB is?  I know it's been a 
while since anyone complained about it.)

Can we upgrade GUB, or should I start working to restore the global 
::to_string() functions?  Newer systems are better off with things the way they 
are, but I don't see a third option.
— 
Dan

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

[Dan Eble]

On Jan 24, 2020, at 11:11, d...@gnu.org wrote:
>> Don't assume the hash function is perfect: create the table with more
> buckets,
>> say 2*size.
> 
> I'd not do that.  It's second-guessing the implementation.  The size
> should be good as a hint.  In particular if there are actual
> duplicates...

You are right.  I hadn't read the documentation closely enough.  The 
constructor argument is a minimum bucket count.

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[Dan Eble]

On Jan 24, 2020, at 03:49, Han-Wen Nienhuys  wrote:
> The alternative is that we don't cast it, but pass on the 64 bit size_t, but 
> every time we do that, we'll create new call sites where we have to fix up 
> conversions, so that will create more work for ourselves,

I've been trickling in changes of this nature for a few months, and I'm content 
to keep it up if we can agree that it's the right thing to do.
— 
Dan

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

[Dan Eble]

On Jan 24, 2020, at 03:49, Han-Wen Nienhuys  wrote:
> 
> (I think Dan is nine.fierce.ballads?)

sort(Dan.full_name) == sort('ninE Fierce ballaDs')
— 
Dan

Re: packaging lilypond as a docker container?

[Dan Eble]

On Jan 21, 2020, at 11:01, Michael Käppler  wrote:
> 
> Would be happy to try the Dockerfile, since I've never used Docker
> before and find
> the concept interesting.
> Could you push your changes to your LilyDev fork and/or file a pull
> request against
> Federico's repo?

Federico has merged a couple changes already.  This is the last one I have 
planned:
https://github.com/fedelibre/LilyDev/pull/19
— 
Dan

Issue #4550 Avoid "using" directives in included files

[Dan Eble]

Begin forwarded message:
> 
> From: "pkx166h" 
> Subject: [testlilyissues:issues] #4550 Avoid "using" directives in included 
> files
> Date: January 22, 2020 at 10:13:39 EST
> To: "[testlilyissues:issues] " 
> <4...@issues.testlilyissues.p.re.sourceforge.net>
> Reply-To: "[testlilyissues:issues] " 
> <4...@issues.testlilyissues.p.re.sourceforge.net>
> 
> Patch: new --> review
> Comment:
> Passes make, make check and a full make doc.
> 
If there is someone here willing to spend the personal and machine time to test 
this patch in GUB, it would be very helpful.  The first attempts at this change 
(some years ago) were plagued by issues that didn't show up until after the 
changes were pushed.  I expect that they have been fixed, but it would be nice 
to be sure before pushing.

https://codereview.appspot.com/579240043/
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:37, David Kastrup  wrote:
> 
> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2

OK.  It would be an understandable growth on the current face of LilyPond. :)

Questions follow, but I'm not asking you to spend time investigating.

Do you think we could achieve making the quotes optional for some simple IDs, 
and making the whitespace optional?

StaffGroup=organ.Staff=upper.Voice.SubVoice=2

In a situation where the user didn't care to constrain the context types, do 
you think could they be omitted, or would we have to invent a placeholder?

=organ.=upper..=2
X=organ.X=upper.X.X=2

Maybe--MAYBE--I'm not yet advocating it, but maybe we could allow some 
ambiguity when there is no equal sign, and define how LilyPond resolves it; 
like if it is a context type then it is used as the context type, otherwise it 
is used as an ID, which would allow things like this:

organ.upper.Voice.2

> Does this give us a hook into making \set, \override and/or \tempo a
> music function in the long run?  Less than sure about that.
> Particularly \tempo appears rather tricky.

If I ever knew enough about the implementation of those to answer, I've 
forgotten it.
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:02, Carl Sorensen  wrote:
> It seems to me that 
> 
> \context StaffGroup ID1.ID2.ID3.ID4
...
> ID4 must be a bottom context

Please guide me step by step to this conclusion.  All this example speaks to me 
is that ID4 is a great-grandchild of ID1.

Thanks and regards,
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:20, David Kastrup  wrote:
> 
>> Notation borrowed directly from them will not integrate well
>> into LilyPond, but it might be fruitful to ask how we could modify
>> expressions like these to fit in.
...
> The syntax appears not to be a good match to LilyPond even though the
> concept may be considered fitting.

I'm glad you agree.
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 14:02, Carl Sorensen  wrote:
> \new ChoirStaff = choir  <<
>\new Staff = choir.upper  <<
>\new Voice = choir.upper.soprano
>\new Voice = choir.upper.alto
>>> 
>   \new Staff = choir.lower <<
>\new Voice = choir.lower.tenor
>\new Voice = choir.lower.bass
>>> 
>>> 
> 
> Or would we prefer
> 
> \new ChoirStaff = choir  <<
>\new Staff = choir.upper  <<
>\new Voice = choir.soprano
>\new Voice = choir.alto
>>> 
>   \new Staff = choir.lower <<
>\new Voice = choir.tenor
>\new Voice = choir.bass
>>> 
>>> 
> 
> The first example is potentially problematic, because Voices can change 
> Staffs (and even StaffGroups), so it seems that having the Voice id include 
> the Staff is not desirable.

I don't think anyone was suggesting that a context ID would include the IDs of 
its parents as a substring.  At least I wasn't trying to suggest that.  The 
idea is that something like this:

\context foo.bar.baz { … }

Could be interpreted as shorthand for this:

\context %{ unspecified %} = foo {
  \context %{ unspecified %} = bar {
\context %{ unspecified %} = baz { … }
  }
}

— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 11:31, Jan-Peter Voigt  wrote:
> 
> \context Voice = choir.soprano
> 
> it would be inconsistent with \new  = "…"

The implied example

   \new Voice = choir.soprano { … }

could be given a consistent interpretation.  For example, it could be 
interpreted as creating \new Voice = soprano { … } within an existing-or-new 
context of unspecified type and ID "choir".

If we decide what we want from \context first, it will probably be pretty 
obvious how \new should work.
— 
Dan

Re: Context paths (and the Edition Engraver)

[Dan Eble]

On Jan 21, 2020, at 11:31, Jan-Peter Voigt  wrote:
> I'd like that, though it would be a quite invasive change.
> And if we stay with the string for the context id and then use
> lists/paths in the \context statement like
> \new Staff = "choir" << \new Voice = "soprano" …
> 
> and then use
> \context Voice = choir.soprano
> 
> it would be inconsistent with \new  = "…"
> 
> I will write down some more text about this topic later.

I see similarities with languages like CSS and XPATH select nodes in a DOM.  
Notation borrowed directly from them will not integrate well into LilyPond, but 
it might be fruitful to ask how we could modify expressions like these to fit 
in.

%% find the voice in the example quoted above, very specifically
\context Staff#choir > Voice#soprano { … } % CSS
\context Staff[@id=choir]/Voice[@id=soprano] { … } % XPATH

%% ditto, but using context type only
\context Staff > Voice { … }   % CSS
\context Staff/Voice { … } % XPATH

%% ditto, but using ID only
\context #choir > #soprano { … }   % CSS
\context [@id=choir]/[@id=soprano] { … }   % XPATH

%% find the context where the rehearsalMark property is defined
\context [rehearsalMark] { … } % CSS
\context [@rehearsalMark] { … }% XPATH
— 
Dan

Re: packaging lilypond as a docker container?

[Dan Eble]

On Jan 20, 2020, at 18:21, Karlin High  wrote:
> 
> There already is a LilyDev Docker image.
> 
> 
> 
> I tried it once, but was unable to get it working. It was my first and only 
> experience with Docker, so that's probably my fault. I was also unmotivated 
> to persevere . . .

I'm the original author and de-facto maintainer of that Dockerfile.  I assume 
I'm also the sole user, based on the lack of questions about it.

My experience is that it's more stable than VirtualBox, and I can more easily 
keep my source backed up (because it's in my host filesystem, not the VM 
filesystem), but the performance of accessing the host filesystem is mightily 
disappointing (unlike on Linux hosts).

If anyone is reading this and thinking of trying it, you might be better off 
encouraging me to publish some of the private changes I've been testing, rather 
than trying what's in Federico's repo.  I tend to slack off in that regard 
because no one is asking.
— 
Dan

Re: github mirror of lilypond?

[Dan Eble]

On Jan 20, 2020, at 11:51, pkx1...@posteo.net wrote:
> 
> On 20/01/2020 16:16, Werner LEMBERG wrote:
>>> Trivial things from a developer with push access can be just pushed.
>>> Complex or otherwise contential things warrant a chance for
>>> developers to take a look at it.  "Half a chance" seems an
>>> unnecessary complication.
>> Anyway, I was misled.  Han-Wen actually *did* create proper SF issues,
>> which I seem to have missed because the gnu.org mailer had again
>> delays, delivering messages in time-reversed order.
>> 
>> 
>>Werner
>> 
> and on of them doesn't 'make/make test-baseline'.


A problem with the policy "trivial things can just be pushed" is that "trivial" 
is open for interpretation.  Even a change that was intended to affect only 
comments could have a bad impact if, say, it inserts an accidental stray 
character and is not tested sufficiently.

James' report demonstrates that even if multiple devs agree that a change is 
trivial, it should still be tested before being pushed.
— 
Dan

Re: github mirror of lilypond?

[Dan Eble]

On Jan 20, 2020, at 11:40, Carl Sorensen  wrote:
> I agree.  And while comments during countdown are annoying and frustrating, 
> it's even more annoying and frustrating to have a commit reverted.  So I 
> prefer countdown to reversion.

+1
— 
Dan

Context paths (and the Edition Engraver)

[Dan Eble]

One of the things in Kieren's intro to the Edition Engraver (EE) that resonated 
with me was the context paths.  His example was something like 
`singwithbach.along.Voice.B`, which was supposed to refer to something like 
this:

  \context Staff = "along" {
\context Voice = "B" {
  ...
}
  }

The ability to refer to contexts this way is a great idea, though IMHO it needs 
some work to reduce ambiguity.  But the point I came here to make is this: if 
an EE using a similar syntax is ever to be a part of LilyPond proper, the 
syntax ought to be consistently supported for other LilyPond commands that 
refer to contexts.  For example,

  \context along.Voice.B { ... }

  \set along.Voice.B.property = #...

  \change Voice = ChoirStaff.A.Staff.B

It would be wise to ask whether there are use cases for any "pronouns" (like 
`.` and `..` in file paths, and `this` in C++) to make it possible to root a 
search very specifically.  The existence of the `descend-only` music property 
suggests that there might be.  I also think I have a pretty good use case for 
finding "the closest enclosing context where a given property is defined," but 
I am not now prepared to elaborate.
— 
Dan

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[Dan Eble]

On Jan 15, 2020, at 09:00, jonas.hahnf...@gmail.com wrote:
> What's causing problems is that the configure (and only that)
> usually lives in the source directory. In fact, I think you can make the
> source directory read-only right after running autoconf, everything else
> should only touch the build directory.

Well, plan to commit the ugly little hack; however, I will experiment with this 
if I have time.
— 
Dan

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[Dan Eble]

On Jan 15, 2020, at 03:08, jonas.hahnf...@gmail.com wrote:
> 
> Maybe I misunderstood your process; aren't you firing up a fresh
> container for every build?

No, I leave the container running, open an interactive shell into it, and use 
it for a relatively long time.  It is quite like how a VM would be used, but 
the container holds just the tools required for building, testing, and 
debugging.  Tasks like source control and editing occur on the host.

> Just as a thought, then you
> could run autogen.sh once on the host in the beginning (or have a second
> container that is allowed to write, but only runs autoconf).

I couldn't run autoconf on the host, because autoconf is not installed on the 
host.
I could define a second service with write access for running autoconf.

But is the root of this problem write permission, or separate source and build 
directories?  Allowing writing to my source tree is something I am willing to 
consider.  Storing 4GB of build output in my source tree is something I have 
good reasons (mentioned earlier) to resist.

> I can
> probably live with the found solution for now, let's see how often it
> causes headaches in the future.

It doesn't seem like the kind of problem that would tend to multiply.

> As my comment already hints to, I'm all in favor to drop (at the least
> the current version number from) VERSION. I have a patch or two that get
> rid of some scripts that rely on VERSION and instead use files generated
> by configure. However I don't understand what "make website" does and
> how it is used in production right now, so the file is not going away in
> the next days. But that's not really the topic of this patch.

I agree that it's wise to avoid disturbing `make website` for now.  My point is 
that, if revising `make website` might eliminate the need for the kludge, then 
it is premature to require me to change my build environment.  I'm not asking 
you to understand it all now, but to understand it before asking me to cope 
with it.  I'm glad to hear that you are willing to live with the kluge for now.
— 
Dan

Savannah push access question

[Dan Eble]

I recently started using a git GUI, GitUp, which sometimes infers that I might 
want to delete origin/staging, and offers to do it for me.  Needless to say, I 
don't want that; and I've suggested in the GitUp issue tracker that even 
prompting me is a defect, in the light of this project's workflow.

My question here is, do I need to maintain extreme caution if I continue using 
this tool?  Would the git server actually delete origin/staging if I hit the 
wrong button by mistake?

Thanks,
— 
Dan

Re: macOS 64-bit

[Dan Eble]

On Jan 11, 2020, at 08:40, Marnen Laibow-Koser  wrote:
> Dammit, I did already fix this error!  I wonder if I left the modified 
> gs.reloc file out of the bundle by mistake, or if something else is going on. 
>  
> 
> Would you post the contents of 
> LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?

$ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc 

prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init
— 
Dan

Re: macOS 64-bit

[Dan Eble]

On Jan 11, 2020, at 07:48, Marnen Laibow-Koser  wrote:
> 
> Could you try it without renaming and see if you get the same results?  
> (Renaming shouldn’t actually matter, but I want to make sure I didn’t do 
> something stupid.)

same result


> There was the usual security problem with running unsigned apps,
> which was solved in the usual way in the Security & Privacy preferences pane.
> 
> What “usual way” is that?  I usually just right-click on the app and open it 
> and ask it to override, although I didn’t need to do that with this app.  
> Perhaps renaming the bundle did something here?

With command-line programs, there's no right-clicking.  When you try to run the 
program, the OS kills it (signal 9).  If you're lucky, it pops up a dialog box 
explaining that it has done so.  Open the Security & Privacy preferences pane, 
where there is a message that such-and-such was prevented from running, and 
click the button to allow it in the future.

> Would you try running LilyPond from the command line in debug mode ( 
> LilyPond.app/Contents/Resources/bin/lilypond --loglevel=debug myfile.ly) and 
> let me know what Ghostscript errors you see?

Converting to `simple.pdf'...
Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-dAutoRotatePages=/None -dPrinted=false -sOutputFile=simple.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-gJjMWd'...

GPL Ghostscript 9.50 (2019-10-15)
Copyright (C) 2019 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.

*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.

  ./base/gsicc_manage.c:1254: gsicc_open_search(): Could not find 
default_gray.icc 
| ./base/gsicc_manage.c:2272: gsicc_init_iccmanager(): cannot find default icc 
profile
 Unable to open the initial device, quitting.
warning: `(gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-dAutoRotatePages=/None -dPrinted=false -sOutputFile=simple.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-gJjMWd)' failed 
(256)

fatal error: failed files: "./simple.ly"
— 
Dan

Re: macOS 64-bit

[Dan Eble]

On Jan 11, 2020, at 01:36, Marnen Laibow-Koser  wrote:
> I'd really appreciate fellow Mac users testing the build and reporting any
> issues you find.  (Karlin? Carl?)  You can download it at
> https://drive.google.com/open?id=18b1nX5nJsBrzDBGqga9T753oCL8ilwqs ; it
> should work on any recent version of Mac OS.  I'm particularly interested
> in reports from Catalina users, but really, at this point, any information
> is useful.

I've never been a LilyPond GUI user, so I first tried to run 
/Applications/LilyPond-2.19.app/Contents/Resources/bin/lilypond from a Makefile 
on macOS 10.15.2 (Catalina).  (Renaming LilyPond.app to include the version 
number has been my practice for a while.)

There was the usual security problem with running unsigned apps, which was 
solved in the usual way in the Security & Privacy preferences pane.

Near startup, there was this message I don't remember having seen before:

Unable to revert mtime: /Library/Fonts

It probably comes from here:

$ (cd /Applications/LilyPond* && grep -r "Unable to revert mtime" .)
Binary file ./Contents/Resources/lib/libfontconfig.1.dylib matches

Next, it looks like gs failed:

warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=612.00 
-dDEVICEHEIGHTPOINTS=792.00 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 
-sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false 
-sOutputFile=ar10_holy_God_behold_my_heart_is_turning.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-zC36CX)' failed 
(256)

I tried processing input/regression/bend-bound.ly in the GUI; the result was 
similar:

Processing `/Users/dan/Music/LilyPond/bend-bound.ly'
Parsing…
Interpreting music…
Preprocessing graphical objects…
Interpreting music…
Preprocessing graphical objects…
Finding the ideal number of pages…
Fitting music on 1 page…
Drawing systems…
Layout output to 
`/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-JXArKN'…
Converting to `bend-bound.pdf'…
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 
-sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false 
-sOutputFile=bend-bound.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-JXArKN)' failed 
(256)

fatal error: failed files: "/Users/dan/Music/LilyPond/bend-bound.ly"
— 
Dan

Re: GUB build error

[Dan Eble]

On Jan 10, 2020, at 16:21, Dan Eble  wrote:
> 
> It seems that this implementation of the standard library declares ::isinf 
> when  is included.  The three solutions I can think of are (a) 
> finish issue 4550, (b) require a version of the library that does not do 
> this, or (c) investigate whether it is possible to avoid including  
> or any other header that triggers the same problem.
> 
> I've been working on issue 4550.

During a much-needed dinner, the most obvious solution occurred to me, which is 
to qualify the calls to std::isinf, std::isnan, etc. everywhere.  This is a 
subset of issue 4550, but I'll try to add it to the patch for issue 5658 in 
time for you to test tomorrow.
— 
Dan

https://sourceforge.net/p/testlilyissues/issues/5658/

Re: GUB build error

[Dan Eble]

On Jan 10, 2020, at 15:52, Michael Käppler  wrote:
> 
> Hi Dan,
> GUB still fails to build lilypond in offset.cc. See attached log.
> Anyone out here using LilyDev1, who can build current master through GUB?
> Now testing, if I can build release/unstable.
> 
> What I would like to understand is why this issue does arise only within
> GUB and
> not for a normal build.
> Could you give me a hint?

/home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/offset.cc:41:25:
 note: candidates are:
In file included from 
/home/dev/gub/target/linux-64/root/usr/cross/lib/gcc/x86_64-linux/4.9.4/include-fixed/features.h:317:0,
 from 
/home/dev/gub/target/linux-64/root/usr/include/assert.h:36,
 from 
/home/dev/gub/target/linux-64/root/usr/cross/x86_64-linux/include/c++/4.9.4/cassert:43,
 from 
/home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/include/axis.hh:23,
 from 
/home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/include/offset.hh:23,
 from 
/home/dev/gub/target/linux-64/src/lilypond-localhost--lilypond.git-issue5658/flower/offset.cc:20:
/home/dev/gub/target/linux-64/root/usr/include/bits/mathcalls.h:202:1: note: 
int isinf(double)

It seems that this implementation of the standard library declares ::isinf when 
 is included.  The three solutions I can think of are (a) finish issue 
4550, (b) require a version of the library that does not do this, or (c) 
investigate whether it is possible to avoid including  or any other 
header that triggers the same problem.

I've been working on issue 4550.
— 
Dan

Re: GUB build error

[Dan Eble]

On Jan 9, 2020, at 10:09, Dan Eble  wrote:
> 
> On Jan 9, 2020, at 07:32, Michael Käppler  wrote:
>> 
>> /home/dev/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/offset.cc:132:23:
>> error: call of overloaded 'isinf(Real&)' is ambiguous
>>   if (isinf (d[X_AXIS]))
> 
> Maybe it's time to take another shot at issue 4550, "Avoid 'using' directives 
> in included files."  I can't say I relish the thought, but I will try to 
> motivate myself.
> https://sourceforge.net/p/testlilyissues/issues/4550/

If you're up to testing it, I'd like to know if this patch solves your problem.
https://codereview.appspot.com/569220043/

Thanks,
— 
Dan

Re: MacOS 64-bit build

[Dan Eble]

On Jan 9, 2020, at 07:00, Erlend Aasland  wrote:
> 
> Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
> lists): a stream pointer has been changed in the declaration to a reference
> without doing it in the code. Reported some years ago on the flex list.

I've been building master with flex 2.6.4 and I have not had any problem.
— 
Dan

Re: GUB build error

[Dan Eble]

On Jan 9, 2020, at 07:32, Michael Käppler  wrote:
> 
> /home/dev/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/offset.cc:132:23:
> error: call of overloaded 'isinf(Real&)' is ambiguous
>if (isinf (d[X_AXIS]))

Maybe it's time to take another shot at issue 4550, "Avoid 'using' directives 
in included files."  I can't say I relish the thought, but I will try to 
motivate myself.
https://sourceforge.net/p/testlilyissues/issues/4550/

IF you are looking for a way to contribute, you could try qualifying the calls 
to isinf() in offset.cc either as ::isinf() or std::isinf(), and report which 
of the two avoid the error.  I expect that either one will work, but it would 
help to see it happen.

Regards,
— 
Dan

Re: The Future

[Dan Eble]

On Jan 8, 2020, at 12:53, Zone Dremik  wrote:
> 
> I'm bound to ask; is this the end of for support of Mac OS?

I suggest checking the lilypond-devel archive, where people have been 
discussing macOS this very day.
https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00052.html
— 
Dan

Re: Weird intermediate context creation

[Dan Eble]

On Jan 7, 2020, at 09:26, Dan Eble  wrote:
> 
> On Jan 6, 2020, at 17:01, David Kastrup  wrote:
>> 
>>>> If I write
>>>> 
>>>> << \new Staff { c' } \new Voice { d' } >>
>>>> 
>>>> should the d' insinuate itself into the same staff as the c' ?
>>> 
>>> You didn't specify a staff for the d', so I don't see grounds for
>>> dissatisfaction if LilyPond were to do that.
>> 
>> It's the same as
>> 
>> << \new StaffGroup { c' } \new Staff { d' } >>
>> 
>> where it clearly seems inappropriate to make the Staff be a part of the
>> StaffGroup.
> 
> The context schema makes these cases different.
> 
> In the new-Voice case, the Score does not accept the Voice directly.  A Staff 
> is required between the Staff and the Voice, so the question "Which Staff?" 
> arises.

Oops: "A Staff is required between the SCORE and the Voice …"

> 
> In the new-Staff case, the Score accepts the Staff.  Placing it in a 
> StaffGroup is not considered.
> 
> (Thanks for the rest of your reply too; I haven't digested it all yet.)
> — 
> Dan
> 

Re: Weird intermediate context creation

[Dan Eble]

On Jan 6, 2020, at 17:01, David Kastrup  wrote:
> 
>>> If I write
>>> 
>>> << \new Staff { c' } \new Voice { d' } >>
>>> 
>>> should the d' insinuate itself into the same staff as the c' ?
>> 
>> You didn't specify a staff for the d', so I don't see grounds for
>> dissatisfaction if LilyPond were to do that.
> 
> It's the same as
> 
> << \new StaffGroup { c' } \new Staff { d' } >>
> 
> where it clearly seems inappropriate to make the Staff be a part of the
> StaffGroup.

The context schema makes these cases different.

In the new-Voice case, the Score does not accept the Voice directly.  A Staff 
is required between the Staff and the Voice, so the question "Which Staff?" 
arises.

In the new-Staff case, the Score accepts the Staff.  Placing it in a StaffGroup 
is not considered.

(Thanks for the rest of your reply too; I haven't digested it all yet.)
— 
Dan

Re: Weird intermediate context creation

[Dan Eble]

On Jan 6, 2020, at 10:57, David Kastrup  wrote:
>> the current result is strange
> 
> Can you explain why you feel that?

I find it strange that this music produces these diverse results:

music = << c' e' >>

\new Score { % Case A: two notes in one voice
  \new Voice \music
}

\new Score { % Case B: two voices in one staff
  \new Staff \music
}

\new Score { % Case C: two staves
  \new StaffGroup \music
}

\new Score { % Case D: two staves
  \music
}

With my experimental changes, cases B, C, and D are rendered as two voices in 
one staff.  They are not rendered like case A (I believe) because I haven't 
touched the code that makes LilyPond create a new bottom context per item in 
\music.

> Implicit context creation is not going away.  Things like Global and
> Score context are created implicitly all the time.

I don't propose eliminating it.  Actually, I'm experimenting with generalizing 
some special handling of Score.  When LilyPond creates the implied intermediate 
contexts required for a new context, the current behavior is to avoid creating 
a new Score context if one already exists.  The question I asked myself is 
"What if LilyPond did the same for other intermediate contexts?"  Then I tried 
it and discovered the impact on the bend-bound test and some others.

> If I write
> 
> << \new Staff { c' } \new Voice { d' } >>
> 
> should the d' insinuate itself into the same staff as the c' ?

You didn't specify a staff for the d', so I don't see grounds for 
dissatisfaction if LilyPond were to do that.  Having said that, my work in 
progress produces the same output as master for this case, so it might not be 
something we need to debate.  I don't understand why yet, and I ought to, so 
thanks for this case.

Regards,
— 
Dan

Weird intermediate context creation

[Dan Eble]

I find it strange that this code in input/regression/bend-bound.ly ends up on 
two staves rather than one:

music = \repeat unfold 16 { c''4\bendAfter #-4 }
sixteens = \repeat unfold 64 { c'16 }

\new Score {
  << \music \sixteens >>
}

I have a pretty good idea of why it is happening, and I am currently testing a 
change that affects 4 layout regtests including this one.

The question is whether changing it is the right thing to do.  On the one hand,

the current result is strange
the NR is not clear as to whether the current result is expected; I lean toward 
reading it as unexpected
the NR advises against relying on implicit context creation anyway

NR section 5.1.2 begins,

LilyPond will create lower-level contexts automatically if a music expression 
is encountered before a suitable context exists, but this is usually successful 
only for simple scores or music fragments like the ones in the documentation.

The NR defines "bottom-level contexts" to include Voice and to exclude Staff, 
but leaves the reader to draw his own conclusion of what  "lower-level 
contexts" are.  I guess it means any required contexts that don't yet exist.

I'm not sure from this whether to expect \music and \sixteens to end up in 
separate Voice contexts.  My intuition is that after a Voice context is created 
for \music, "a suitable context exists" for \sixteens.

On the other hand, changing this would change how existing scores that rely on 
automatic context creation are engraved.  Is a change justified either on the 
grounds that the current behavior is a bug or that the NR gives fair warning 
not to rely on this feature?
— 
Dan

Re: A suggestion: add \rf to built-in dynamics

[Dan Eble]

On Jan 4, 2020, at 06:09, Peter Toye  wrote:
> 
> Thanks for that. As everyone seems to be on all the mailing lists. I sort of 
> assumed that cross-links wouldn't be necessary.

I am subscribed to lilypond-devel only.
— 
Dan

Re: What is holding up 2.20 release?

[Dan Eble]

On Dec 17, 2019, at 13:58, Jonas Hahnfeld  wrote:
> I would also propose to pick the following, more recent commits:
> […]
> 86de0f8f38 Use a stable sort when ordering MIDI items
> 152a281031 Issue 5217: Fix sorting order without outside-staff-priority

Pretty please, pick these.

I support not picking improvements to the development workflow.  A person 
maintaining 2.20 will need to avoid referring to the 2.21 Contributor's Guide, 
but hopefully that's understandable.
— 
Dan

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

[Dan Eble]

On Dec 15, 2019, at 06:31, lilyp...@de-wolff.org wrote:
> It is not the commit title, but I do think that this is not a part of issue 
> 5639: compile with --std=c11
> The reason that I think it is important to keep this separated is that the 
> impact is very different.
> When a commit with only comments is in a separate issue, it is easy to cherry 
> pick it for let say version 2.0.
> Although you make it a separate commit, in rietveld it is still one issue.

The effort of handling a separate ticket and review is not worth it to me for 
this particular typo correction.  I'm willing to revert it and leave it for the 
next person who notices it, if that bothers you less than piggybacking on this 
issue.
— 
Dan

Re: make test-baseline fails

[Dan Eble]

On Dec 7, 2019, at 04:36, Thomas Morley  wrote:
> 
> Btw, to get access to the "flip"-functionality I need to allow it in
> NoScript of my firefox. Intended?

Yes.  It requires JavaScript, as do the filter links at the top.
— 
Dan

Re: make test-baseline fails

[Dan Eble]

On Dec 7, 2019, at 05:43, James  wrote:
> 
> So apart from 'required' things breaking as newer versions come out (e.g 
> Ghostscript), should I be testing patches with required AND non-required 
> components installed? Or should I be testing them with ONLY required 
> components but then we should make patchy-staging use required AND 
> non-required?
> 
> Else we get into a mess with who has what on which system they happen to be 
> building from.

My 5¢ (no more pennies here):

It's enough to test with or without tidy, whichever happens to be the condition 
of your system.

It would be nice if patchy-staging used tidy, but it isn't a high priority.

It is wise for a contributor making changes to output-distance.py to install 
tidy.
— 
Dan

Re: make test-baseline fails

[Dan Eble]

>>> $ tidy --version
>>> HTML Tidy for Linux version 5.2.0
>> 
>> I'll try to get it and fix the issue.

https://codereview.appspot.com/551250043/
— 
Dan

Re: make test-baseline fails

[Dan Eble]

On Dec 6, 2019, at 13:54, Thomas Morley  wrote:
> 
>> This is tidy complaining about index.html.  What version of tidy do you have 
>> (tidy --version)?  My build environment has 5.6.0 and it isn't complaining.
> 
> $ tidy --version
> HTML Tidy for Linux version 5.2.0

I'll try to get it and fix the issue.  I'm not sure if you can work around it 
by some argument to configure.sh, but you should be able to work around it by 
changing TIDY to "false" in config.make in the top-level build directory.
— 
Dan

Re: make test-baseline fails

[Dan Eble]

On Dec 6, 2019, at 12:32, Thomas Morley  wrote:
> 
> Validating 
> /home/hermann/lilypond-git-guile-2.2/build/out/test-results/index.html
> line 73 column 76 - Warning:  attribute "alt/" lacks value
> line 79 column 169 - Warning:  attribute "alt/" lacks value
> line 73 column 76 - Warning:  lacks "alt" attribute
> line 79 column 169 - Warning:  lacks "alt" attribute
> /home/hermann/lilypond-git-guile-2.2/GNUmakefile.in:376: recipe for
> target 'local-check' failed
> make: *** [local-check] Error 1

This is tidy complaining about index.html.  What version of tidy do you have 
(tidy --version)?  My build environment has 5.6.0 and it isn't complaining.
— 
Dan

Re: compiler flag issues

[Dan Eble]

On Nov 28, 2019, at 03:13, Werner LEMBERG  wrote:
> 
> This is very, very non-standard and completely undocumented.

Not completely undocumented.  The CG has said to run configure with 
--disable-optimising for as long as I can remember.

> Any idea how this could be improved?

A good start would be to refer us to the standard.  For some of us, LilyPond is 
our primary or only exposure to autoconf, which naturally leads to the 
when-in-Rome approach to maintenance.  My web searches on CXXFLAGS have led to 
the manual for automake, which I'm not sure is used here, and various disputed 
answers about autoconf on community Q sites.
—
Dan

Re: create code tests

[Dan Eble]

On Nov 29, 2019, at 16:20,   
wrote:
>  
> I am familiar with the use of makefile. So if you can give me directions with 
> some placeholder commands, or comment at the right place in the makefile (s) 

Well, start at the "test" target in the top-level GNUmakefile.in.  It runs make 
in a number of subdirectories.  I would start by adding something like this 
there:

$(MAKE) -C input/regression/ly2musicxml out=test local-test

You're going to need to create that ly2musicxml directory (or another name, if 
you have a better idea) and put a GNUmakefile there.  I would copy a 
GNUmakefile from a nearby directory and figure out what needs to be changed and 
what unnecessary things can be removed.

The target "local-test" should run your scripts.  Ideally, this should involve 
rules that regenerate the files only when they are out of date.  You've said 
that expectations can be tested automatically, so I think that, for now, you 
should do that immediately when the output files are generated, and cause make 
to fail if the expectations are not met.  (Later, we might want to allow all 
tests to run and summarize the failures at the end, but this seems simpler.)  
Arrange the makefile so that if make is run again immediately without fixing 
anything, it will fail again in the same way; test this.

Once a test has passed, no subsequent "make test" should rerun it until either 
its prerequisites are modified or "make test-clean" has been run to remove the 
test results.

The "test-clean" target is defined in the top-level GNUmakefile.in.  It runs 
"make clean" in input/regression, and input/regression/GNUmakefile defines 
SUBDIRS.  If you add your new subdirectory to SUBDIRS there and have placed all 
your output files in $(outdir), the existing infrastructure should then remove 
them automatically.
— 
Dan

Re: create code tests

[Dan Eble]

On Nov 28, 2019, at 19:22, Dan Eble  wrote:
> 
> Well, step one is to avoid intertwining the existing xml->ly test 
> infrastructure with the new ly->xml test infrastructure.  I would put ly->xml 
> test input in a different directory.  I would probably also plan to rename 
> input/regression/musicxml to input/regression/musicxml2ly, but I don't see a 
> good reason to spend time on that until the new tests are established.
> 
> (I have to go now.  I'll continue later.)

How comfortable are you working with makefiles?  I could give you an outline of 
how I would approach adding ly->xml tests, but it would not be very detailed 
and would probably still require some problem solving.  It might be less work 
all around for me to set up makefile rules with placeholder commands that you 
can then modify.
— 
Dan

Re: create code tests

[Dan Eble]

> On Nov 28, 2019, at 18:57, James  wrote:
> 
> hello
> 
> On 28/11/2019 21:00, Dan Eble wrote:
>> On Nov 28, 2019, at 15:07, lilyp...@de-wolff.org wrote:
>> 
>>> Is het possible to do this kind of tests in the current lilypond regression
>>> test environment?
>> Jaap,
>> 
>> I don't have a comprehensive knowledge of LilyPond's tests, but I have 
>> worked on some of the infrastructure recently, so maybe I can help you.
> 
> I also found this:
> 
> ./input/regression/musicxml/book-musicxml-testsuite.py
> 
> I remembered https://sourceforge.net/p/testlilyissues/issues/3607/ and it 
> mentions it there.

Well, step one is to avoid intertwining the existing xml->ly test 
infrastructure with the new ly->xml test infrastructure.  I would put ly->xml 
test input in a different directory.  I would probably also plan to rename 
input/regression/musicxml to input/regression/musicxml2ly, but I don't see a 
good reason to spend time on that until the new tests are established.

(I have to go now.  I'll continue later.)
— 
Dan

Re: create code tests

[Dan Eble]

On Nov 28, 2019, at 15:07, lilyp...@de-wolff.org wrote:

> Is het possible to do this kind of tests in the current lilypond regression
> test environment?

Jaap,

I don't have a comprehensive knowledge of LilyPond's tests, but I have worked 
on some of the infrastructure recently, so maybe I can help you.

Please provide more detail.  What are the inputs and outputs of your tests?  
What steps are involved?  Are expectations coded such that your script can 
detect whether the tests passed or failed, or is human review required? etc.
— 
Dan

Re: Midi block gives errors with bar number checks

[Dan Eble]

On Nov 27, 2019, at 14:19, Dan Eble  wrote:
> 
> On Nov 27, 2019, at 12:06, Carl Sorensen  wrote:
>> 
>> From the user point of view, the ideal solution would be that if a score 
>> that includes bar number checks was handled by  a midi block , the bar 
>> number checks would be ignored.  
> 
> That's probably easily achievable.
> 
> I'm looking at the existing regression tests, and I don't see why we need 
> both of these:
> 
>./input/regression/bar-number-check.ly
>./input/regression/bar-number-check-warning.ly
> 
> Am I overlooking something?

I went ahead and removed one of them.
https://sourceforge.net/p/testlilyissues/issues/5624/
— 
Dan

Re: Midi block gives errors with bar number checks

[Dan Eble]

On Nov 27, 2019, at 12:06, Carl Sorensen  wrote:
> 
> From the user point of view, the ideal solution would be that if a score that 
> includes bar number checks was handled by  a midi block , the bar number 
> checks would be ignored.  

That's probably easily achievable.

I'm looking at the existing regression tests, and I don't see why we need both 
of these:

./input/regression/bar-number-check.ly
./input/regression/bar-number-check-warning.ly

Am I overlooking something?
— 
Dan

Re: Midi block gives errors with bar number checks

[Dan Eble]

On Nov 27, 2019, at 11:35, Carl Sorensen  wrote:
> 
> It’s not bar checks causing the problem, it's bar number checks.

Oh, thanks for the correction.

It doesn't look difficult to add a context property to deactivate bar number 
checks.  Would that be the ideal solution?
— 
Dan

Re: Midi block gives errors with bar number checks

[Dan Eble]

> On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen 
>  wrote:
> 
>> I use MIDI output mainly for proofreading, but at occasions where I need 
>> better MIDI output I always create separate scores for layout{} and 
>> midi{}. In the midi-only version I copy/paste all music in the correct 
>> order instead of using any repeat instructions. Also suitable for complex 
>> Da Capo / Segno / Coda types of repeats. If I arrange my music in blocks 
>> using variables and use my favorite texteditor it really isn't that much 
>> extra work and it is a usable workaround for Lilypond's restrictions.
>> 
>> Sometimes even \unfoldRepeats doesn't do the trick.

I haven't used bar checks.  Have you tried setting the ignoreBarChecks 
property?  If you don't know what that means, and if you are willing to post a 
minimal example of the problem, I am willing to try setting it for you.
— 
Dan

Yaffut

[Dan Eble]

What level of respect should I maintain for the integrity of 
flower/include/yaffut.h?  I think it would be nice to limit the default output 
of the unit test program to errors + summary, and I could achieve that either 
by modifying Yaffut itself or by filtering the output through a script. 
— 
Dan

Re: Cannot build changes.pdf anymore

[Dan Eble]

On Nov 23, 2019, at 08:06, Malte Meyn  wrote:
> 
> Yes, I wanted to save time and build only that single document. For that I 
> followed the CG: 
> http://lilypond.org/doc/v2.19/Documentation/contributor/generating-documentation#building-a-single-document
> 

I ran these commands in my build directory with HEAD at 658a69f548.

  139  rm -rf *
  140  ls -la # showed nothing hidden
  141  ~/lilypond-src/autogen.sh 
  142  make -j3 CPU_COUNT=3
  143  find . -name changes.tely # not found in the build dir
  # 143.5 on the host system, touch ${src}/Documentation/changes.tely
  144  time make -j3 CPU_COUNT=3 -C Documentation out=www out-www/changes.pdf

The last command yielded a readable file in Documentation/out-www/changes.pdf.
— 
Dan

Re: problem with git pull -r

[Dan Eble]

On Nov 21, 2019, at 10:30, Werner LEMBERG  wrote:
> Clone the repository anew, and everything should be fine again.
> 
> Don't forget to `transfer' your old local branches before deleting the
> old repository clone!  I only had two local ones, so it was rather
> easy.  But I guess some of you have much more...
> 
> For good cooperation with Rietveld and Allura you should also transfer
> the corresponding data to `.git/config'.


I would benefit from some specifics.  The only part of the above that I have 
done before is "clone the repository anew."

I guess we're not going to ask Savannah if they can change something on their 
end to make this unnecessary?
— 
Dan

git-cl patch: remove some redundant text from tracker fields

[Dan Eble]

Please review.  This handles a couple of details I'd rather not have to 
remember to do when submitting the patch or fix after the fact.  I've exercised 
these changes for the last few LilyPond patches I've uploaded.

https://github.com/gperciva/git-cl/pull/6

Thanks,
— 
Dan

Re: Can no longer build.

[Dan Eble]

On Nov 8, 2019, at 09:11, David Kastrup  wrote:
> 
> So how come my lilypond-invoke-editor script starts with
> 
> "echo no not found -s"
> 
> as its interpreter?  Note that some underlying problem might not be new:

1. What does "grep -w GUILE config.make" tell you? (Will be the same, I guess.)
2. Does reconfiguring yield a different before this commit?

commit ad3effb7569fcd7182aa7b491b1d44fca3696c38
Author: Jonas Hahnfeld 
Date:   Tue Oct 15 22:00:02 2019 +0200

Check additional names for guile-config

On Arch Linux, the executable is called guile-config1.8 instead of
guile-config-1.8 or guile-1.8-config.

— 
Dan

Re: git-cl upload and existing sf issues

[Dan Eble]

On Nov 2, 2019, at 12:35, Dan Eble  wrote:
> 
>> when uploading a first patch set, git-cl asks for a sourceforge issue 
>> number. If a new issue is created, everything is fine but when you choose an 
>> existing issue, there is some 404 error and the Rietveld link is not added 
>> to the sf issue—resulting in a missing Rietveld link on 
>> www.philholmes.net/lilypond/allura/ Does anybody know why that is happening?
> 
> I'll investigate.  Don't subscribe to this ticket unless you want to be 
> interrupted frequently. :)
> 
> https://sourceforge.net/p/testlilyissues/issues/5591/

Here's the fix.  I'll close the LilyPond ticket after it's pulled.

https://github.com/gperciva/git-cl/pull/5

During testing, I noticed that http://www.philholmes.net/lilypond/allura/ 
presents the link for the first review rather than the latter review. I don't 
think that's desirable, but it's a separate issue.
— 
Dan

Re: git-cl upload and existing sf issues

[Dan Eble]

On Sep 30, 2019, at 16:54, Malte Meyn  wrote:
> 
> when uploading a first patch set, git-cl asks for a sourceforge issue number. 
> If a new issue is created, everything is fine but when you choose an existing 
> issue, there is some 404 error and the Rietveld link is not added to the sf 
> issue—resulting in a missing Rietveld link on 
> www.philholmes.net/lilypond/allura/ Does anybody know why that is happening?

I'll investigate.  Don't subscribe to this ticket unless you want to be 
interrupted frequently. :)

https://sourceforge.net/p/testlilyissues/issues/5591/
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

On Nov 1, 2019, at 02:52, Werner LEMBERG  wrote:
> 
>>> [...] because the `share' tree present in
>>> 
>>> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/
>>> 
>>> is not created by the script in
>>> 
>>> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/
>> 
>> This fixes the lilypond-test stage:
>> https://github.com/gperciva/gub/pull/70
> 
> Thanks a lot!  What patches shall I temporarily apply to current gub
> master to test your latest fixes?


I don't understand what you're asking for other than the commits in the pull 
request.

A few minutes ago, I pushed revisions in response to your review, after 
verifying that a clean build still got beyond lilypond-test stage.  Note that I 
did reorder and "fixup" some commits after testing.

Regards,
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

On Oct 28, 2019, at 05:32, Werner LEMBERG  wrote:
> 
> Operand stack:
>   
> (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf)
>(r)
> Execution stack: [...]
> Last OS error: No such file or directory
> 
> because the `share' tree present in
> 
> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/
> 
> is not created by the script in
> 
> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/


This fixes the lilypond-test stage: https://github.com/gperciva/gub/pull/70

The lilypond-doc stage fails for me, but I don't think it's related.  There are 
messages about shared library versions not being found.
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

On Oct 28, 2019, at 05:32, Werner LEMBERG  wrote:
> 
>  Operand stack:
>
> (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf)
>(r)
>  Execution stack: [...]
>  Last OS error: No such file or directory
> 
> because the `share' tree present in
> 
>  gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/
> 
> is not created by the script in
> 
>  gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/

Well, I think that this change fixes the 'share' symlink; however, the otf file 
is still not there, so the investigation will continue.
https://github.com/gperciva/gub/compare/master...DanEble:dev
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

On Oct 28, 2019, at 05:32, Werner LEMBERG  wrote:
> A good test for those things IMHO is to clone the gub repository, then
> saying
> 
>  make lilypond

I installed Ubuntu 19.10 on a spare computer, installed some necessary 
packages, cloned https://github.com/gperciva/gub.git, and ran "time make -j7 
PLATFORMS=‘linux-64’ lilypond".  This got as far as package linux-64::lilypond, 
stage pkg_install, and then exited with error 2.  The last line of 
target/linux-64/log/lilypond.log is just this:

 *** Stage: pkg_install (lilypond, linux-64)

I don't know where to go from here.  Maybe tomorrow I'll look for other logs or 
start learning about the makefile.
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

On Oct 28, 2019, at 08:12, David Kastrup  wrote:
> 
>> I request some help to understand how I can improve my pre-commit
>> testing procedures, and where my responsibilities begin and end.
> 
> Responsibilities don't end.

Fine.  When a patch is submitted for review, there ends the opportunity to 
fulfill one's responsibility to test before submitting it.  My question was how 
much is enough.

> We don't have as comprehensive tests as that and don't really demand
> it.  One should just be conservative.  The cost of a mistake in that
> regard may well be a revert or a timely followup patch.

This is an answer to my question, though my recent perception (which is 
possibly incorrect) was that receiving some public heat was included in the 
cost.  Anyway, I'm sorry that my recent contributions haven't worked for 
everyone; it's not for lack of trying.

Regards,
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

On Oct 28, 2019, at 05:32, Werner LEMBERG  wrote:
>  Last OS error: No such file or directory
> 
> because the `share' tree present in
> 
>  gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/
> 
> is not created by the script in
> 
>  gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/
> 
> I seem to remember that this has worked the last time I worked on gub
> (in January) …


My change that made 'share' a symlink seems a likely candidate, but I hope we 
can avoid simply reverting that, lest it require everyone to wipe their build 
directories and rebuild from scratch to avoid weird side effects.  I took pains 
to keep "make check" working with older baselines across that change, but I put 
no effort (or thought) into supporting a move back to the past.

I will attempt to build gub to reproduce and diagnose this issue.  If you think 
my time would be better spent preparing a patch that cleanly undoes the 'share' 
change, I'm open to hearing it.
— 
Dan

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

In the past month, I've devoted many hours to testing my submissions, but 
clearly the effort is not achieving the goal.  I request some help to 
understand how I can improve my pre-commit testing procedures, and where my 
responsibilities begin and end.  I enjoy having my commits reverted as much as 
others enjoy having their build broken--it is a big waste of pro-bono time--so 
I want to understand the issues clearly.

How are build-breaking changes getting into the master branch? CG section 
3.4.10 says that the reason for pushing to staging is that automated tests are 
run before changes are moved to master.  What specifically is being tested?

And days before that happens, patches are announced as having been tested with 
the feedback "Passes make. make check and a full make doc."  The evidence 
suggests that that does not include running autogen, otherwise it should have 
caught the problem with "tidy" that my own testing failed to catch.

Should things such as missing optional programs and new-ish Python syntax be 
rejected at either of these stages?  If not, then it would seem to fall to the 
submitter to set up an alternate development environment with Python 2.4, GCC 
3.4, and similarly aged versions of other tools, and run additional tests in 
that environment.

Thanks,
— 
Dan

Re: make test-redo

[Dan Eble]

On Oct 14, 2019, at 21:59, Dan Eble  wrote:
> 
> On Oct 14, 2019, at 18:27, Carl Sorensen  wrote:
>> 
>> What is the defect you are seeing?  The last time I tried it, it worked as 
>> described in the CG.
> 
> I wiped my build directory and ran these commands with master @ fa6c70e39a.
> […]

I think I've fixed the problems.
https://sourceforge.net/p/testlilyissues/issues/5584/
— 
Dan


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

Re: Issue 5583: www_post.py: don't mirror regtest baseline (issue 565170043 by nine.fierce.ball...@gmail.com)

[Dan Eble]

> On Oct 23, 2019, at 12:36, David Kastrup  wrote:
> 
> "James Lowe"  writes:
> 
> Fixes should always be to staging rather than master but I guess that's
> what you meant.  It depends on just how old the problem is whether one
> tries to hotfix it.

Baselines created after this commit (a few back from the current tip of master) 
will create out-test-baseline/share as a symlink.

0d7744aad0 Issue 5572/1: Compile modified C++ files automatically before 
testing
— 
Dan


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

Regression test flip feature

[Dan Eble]

Live demo:

http://faithful.be/tmp/test-results

Go to the images for rest-dot-position and press the "Flip" button under the 
right-hand image.  The new image should change to the old image while the 
button is held.  I've only tested it with the latest Safari for macOS, but I 
hope it works with other recent browsers.

My question for the developers is would you use this if it were available?
— 
Dan


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

Re: make test-redo

[Dan Eble]

On Oct 14, 2019, at 18:27, Carl Sorensen  wrote:
> 
> What is the defect you are seeing?  The last time I tried it, it worked as 
> described in the CG.

I wiped my build directory and ran these commands with master @ fa6c70e39a.

../lilypond-src/autogen.sh
make -j3 CPU_COUNT=3
make -j3 CPU_COUNT=3 test-baseline
make -j3 CPU_COUNT=3 check

It found some mismatches:

$ cat out/test-results/changed.txt 
input/regression/out-test/test-output-distance
input/regression/out-test/rest-dot-position
input/regression/out-test/merge-rests-engraver

Then I ran these commands:

make -j3 CPU_COUNT=3 # for good measure
make -j3 CPU_COUNT=3 test-redo

This is the output of test-redo:

removing input/regression/out-test/test-output-distance-1.eps 
input/regression/out-test/test-output-distance-1.signature 
input/regression/out-test/test-output-distance-systems.count 
input/regression/out-test/test-output-distance-systems.tex 
input/regression/out-test/test-output-distance-systems.texi 
input/regression/out-test/test-output-distance.eps 
input/regression/out-test/test-output-distance.log 
input/regression/out-test/test-output-distance.ly 
input/regression/out-test/test-output-distance.profile 
input/regression/out-test/test-output-distance.texidoc 
input/regression/out-test/test-output-distance.txt
removing input/regression/out-test/rest-dot-position-1.eps 
input/regression/out-test/rest-dot-position-1.signature 
input/regression/out-test/rest-dot-position-2.eps 
input/regression/out-test/rest-dot-position-2.signature 
input/regression/out-test/rest-dot-position-3.eps 
input/regression/out-test/rest-dot-position-3.signature 
input/regression/out-test/rest-dot-position-4.eps 
input/regression/out-test/rest-dot-position-4.signature 
input/regression/out-test/rest-dot-position-systems.count 
input/regression/out-test/rest-dot-position-systems.tex 
input/regression/out-test/rest-dot-position-systems.texi 
input/regression/out-test/rest-dot-position.eps 
input/regression/out-test/rest-dot-position.log 
input/regression/out-test/rest-dot-position.ly 
input/regression/out-test/rest-dot-position.profile 
input/regression/out-test/rest-dot-position.texidoc 
input/regression/out-test/rest-dot-position.txt
removing input/regression/out-test/merge-rests-engraver-1.eps 
input/regression/out-test/merge-rests-engraver-1.signature 
input/regression/out-test/merge-rests-engraver-2.eps 
input/regression/out-test/merge-rests-engraver-2.signature 
input/regression/out-test/merge-rests-engraver-3.eps 
input/regression/out-test/merge-rests-engraver-3.signature 
input/regression/out-test/merge-rests-engraver-systems.count 
input/regression/out-test/merge-rests-engraver-systems.tex 
input/regression/out-test/merge-rests-engraver-systems.texi 
input/regression/out-test/merge-rests-engraver.eps 
input/regression/out-test/merge-rests-engraver.log 
input/regression/out-test/merge-rests-engraver.ly 
input/regression/out-test/merge-rests-engraver.profile 
input/regression/out-test/merge-rests-engraver.texidoc 
input/regression/out-test/merge-rests-engraver.txt
For tracking crashes: use

grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed 
s/log/ly/g`

Warning: No such file: merge-rests-engraver-systems.texi (search path: 
.:./out-test:/home/user/lilypond-src/input/regression)
Warning: No such file: rest-dot-position-systems.texi (search path: 
.:./out-test:/home/user/lilypond-src/input/regression)
Warning: No such file: test-output-distance-systems.texi (search path: 
.:./out-test:/home/user/lilypond-src/input/regression)

Please check the logfile

  /home/user/lilypond-build/input/regression/collated-files.texilog.log

for errors

/home/user/lilypond-src/stepmake/stepmake/texinfo-rules.make:55: recipe for 
target 'out-test/collated-files.html' failed
make[3]: *** [out-test/collated-files.html] Error 2
/home/user/lilypond-src/./make/lysdoc-targets.make:12: recipe for target 
'local-test' failed
make[2]: *** [local-test] Error 2
/home/user/lilypond-src/GNUmakefile.in:319: recipe for target 'test' failed
make[1]: *** [test] Error 2
/home/user/lilypond-src/GNUmakefile.in:357: recipe for target 'test-redo' failed
make: *** [test-redo] Error 2

$ cat /home/user/lilypond-build/input/regression/collated-files.texilog.log
*** Can't find merge-rests-engraver.texidoc, skipping (l. 25250)
Max error number exceeded
— 
Dan



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

make test-redo

[Dan Eble]

"make test-redo" seems to be defective, so I’m thinking of removing it and 
simplifying the Contributor’s Guide.  The last discussion I can find of it in 
the lilypond-devel archive is from 7 years ago, but I thought it would be good 
to ask if anyone here has used it successfully recently, just in case I’m doing 
something wrong.

Thanks,
— 
Dan


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

make clean after mf changes

[Dan Eble]

The Contributor’s Guide says,

> Also, if you modify any font definitions in the mf/ directory then you must 
> run make clean and make before running make test-redo. This will recompile 
> everything, whether modified or not, and takes a lot longer. 

I assume the superficial explanation for requiring “make clean" here is that 
the makefile dependencies are (or were) incomplete.  If you have deeper 
knowledge, I’d appreciate being told anything that would shorten my 
investigation into it.  “That’s old and shouldn’t be required anymore” or 
“Fixing it is hopeless!” would also be helpful.

Thanks in advance,
— 
Dan


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

Re: make distclean now posts warning since commit b7532cf6e6d9

[Dan Eble]

On Oct 13, 2019, at 04:11, James  wrote:
> 
> I get the following messages - that I never used to get - when I run a make 
> distclean
> 

I checked out the previous commit (5674d4570d), wiped my build directory, ran 
autogen, and then this:

make -j3 CPU_COUNT=3 test-baseline 2>&1 | tee make_output.txt

And I conclude from the following that those warnings were there before.  
They’re probably more noticeable now that the output isn’t so profuse.

$ grep "overriding recipe" make_output.txt 
/home/user/lilypond-src/./input/regression/lilypond-book/GNUmakefile:22: 
warning: overriding recipe for target 'local-test’
/home/user/lilypond-src/./input/regression/lilypond-book/GNUmakefile:25: 
warning: overriding recipe for target 'out/collated-files.list’
. . .

I’ve been working on improving the regression test process.  I think I can fix 
the local-test warning at the same time.  The collated-files.list warning is 
possibly too involved to tackle now.

Regards,
— 
Dan


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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Dan Eble]

> On Oct 8, 2019, at 12:04, Dan Eble  wrote:
> 
> On Oct 8, 2019, at 11:09, Carl Sorensen  wrote:
>> Federico Bruno says the latest LilyDev includes a Docker container. 
>> http://lilypond.1069038.n5.nabble.com/LilyDev-0-3-released-td217945.html 
>> <http://lilypond.1069038.n5.nabble.com/LilyDev-0-3-released-td217945.html>
> 
> FYI, I’m working on extending that to provide a separate container in which 
> to run lilypond after it has been built from source, which maps the user’s 
> LilyPond scores and host fonts into the container.  This will make it easier 
> for contributors who are macOS users to test their own scores before posting 
> changes for review.
> 
> This is not intended to satisfy “normal” users, but it will be a part of my 
> own composing workflow until another solution is available.

It's now in usable condition in Federico’s master branch.
https://github.com/fedelibre/LilyDev/tree/master/docker
— 
Dan


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

The behavior of "make check"

[Dan Eble]

Begin forwarded message:
> 
> Subject: [testlilyissues:issues] Re: #5564 Fix conversion warnings in beaming 
> code
> Date: October 10, 2019 at 12:08:48 EDT
> I'm sorry to contribute to your frustration. I can see what the process is, 
> but my question (which I direct to LilyPond developers in general) is whether 
> it is justified that make check run to completion using an out-of-date 
> lilypond rather than either rebuilding it first or raising some kind of 
> alarm. Must we continue to put up with it?
> 
> The purpose of make is to follow dependencies and do exactly what needs to be 
> done. The difference in behavior between these cases seems contrary to that:
> 
> make && make check
> make check
— 
Dan

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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Dan Eble]

On Oct 10, 2019, at 12:15, Hans Åberg  wrote:
> On 10 Oct 2019, at 17:55, Eric Benson  wrote:
>> 
>>> This is good, but I think GCC 8 was kept deliberately as it was unclear if 
>>> GCC 9 would work.
>> 
>> gcc8 failed to build on MacPorts on Catalina on the latest Xcode. Rather 
>> than try to understand why, I switched to gcc9 and it seems to work fine.
> 
> I do not have objection to that. :-)

And I’ve been building LilyPond with gcc 9 in a pre-release Ubuntu 19.10 
container for about a week with no surprises yet.
— 
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: better LSR to lilypond snippet conversion tool

[Dan Eble]

On Oct 8, 2019, at 16:21, Werner LEMBERG  wrote:
> I'm not sure how to proceed.  Shall I adapt `makelsr.py' to start
> where this script stops?

I can't contribute much to an answer, but I want to say that the last time I 
tried updating snippets (probably over a year ago), the documented process 
failed because my source tree is read-only in my build environment and the 
script tries to rewrite source files.

I’ve been expecting to have to do one of the following (from most to least 
preferred) in order to make it work for me.

1. Add an option to create snippets in the build directory and stop.  Copy them 
to the source directory manually in the host environment.

2. Grant my build environment write access to the source directory when I want 
to import snippets.

3. Never run the script.  Ask others to do it.

4. Run the script in the host environment.

I humbly request that as you are working on this process, you try to avoid 
making (1) more difficult.

Regards,
— 
Dan


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

Re: lilypond does not work with Mac OS 10.15 (Catalina)

[Dan Eble]

On Oct 8, 2019, at 11:09, Carl Sorensen  wrote:
> Federico Bruno says the latest LilyDev includes a Docker container. 
> http://lilypond.1069038.n5.nabble.com/LilyDev-0-3-released-td217945.html 
> 


FYI, I’m working on extending that to provide a separate container in which to 
run lilypond after it has been built from source, which maps the user’s 
LilyPond scores and host fonts into the container.  This will make it easier 
for contributors who are macOS users to test their own scores before posting 
changes for review.

This is not intended to satisfy “normal” users, but it will be a part of my own 
composing workflow until another solution is available.
— 
Dan

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

Re: PATCHES - Countdown for October 8th

[Dan Eble]

Issue 5564 is being neglected.  I need some help understanding how to reproduce 
the test failures.
https://sourceforge.net/p/testlilyissues/issues/5564/ 
<https://sourceforge.net/p/testlilyissues/issues/5564/>
— 
Dan

> On Oct 8, 2019, at 07:05, James Lowe  wrote:
> 
> Hello,
> 
> Here is the current patch countdown list. The next countdown will be on
> October 10th.
> 
> 
> A quick synopsis of all patches currently in the review process can be
> found here:
> 
> http://philholmes.net/lilypond/allura/
> 
> 
> 
> 
> Push:
> 
> 5566 Update python headers to match surrounding files - masterodin
> https://sourceforge.net/p/testlilyissues/issues/5566
> http://codereview.appspot.com/565080043
> 
> 5565 simplify python-related makefiles - Dan Eble
> https://sourceforge.net/p/testlilyissues/issues/5565
> http://codereview.appspot.com/581080044
> 
> 5559 Add user-definable ottavation markups - Malte Meyn
> https://sourceforge.net/p/testlilyissues/issues/5559
> http://codereview.appspot.com/568970043
> 
> 
> Countdown:
> 
> 5568 Make build output terse by default - Dan Eble
> https://sourceforge.net/p/testlilyissues/issues/5568
> http://codereview.appspot.com/557080043
> 
> 
> Review:
> 
> 5570 Fix header variables from musicxml2ly on Windows - hahnjo
> https://sourceforge.net/p/testlilyissues/issues/5570
> http://codereview.appspot.com/545040043
> 
> 5569 Drop requirement for python-devel - hahnjo
> https://sourceforge.net/p/testlilyissues/issues/5569
> http://codereview.appspot.com/566870043
> 
> 
> New:
> 
> 5567 Allow slurs instead of brackets with tuplets - Werner LEMBERG
> https://sourceforge.net/p/testlilyissues/issues/5567
> http://codereview.appspot.com/581110043
> 
> 
> ***
> 
> Regards,
> 
> 
> James
> 
> - End Forwarded Message -
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

Default make output

[Dan Eble]

Who would cheer/object if I started working on changes to make the build output 
less verbose by default, which would require saying

make VERBOSE=1 …

when you actually wanted to see all the commands?

By “less verbose,” I mean ideally logging one short line per interesting target 
at the start of its recipe.
— 
Dan


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

Re: Python 3

[Dan Eble]

On Sep 30, 2019, at 19:46, Matthew Peveler  wrote:
>  
> I've been maintaining my work in 
> https://github.com/MasterOdin/lilypond/tree/py3_future2
> . . .
> … but I do not know one would approach making it work on both Python 2 and 
> Python3.7 (and potentially other Python3 targets) and that I think it would 
> be something in if statements in python-module-vars.make to be in pseudo-code:

That’s what I needed to know.  I’ll investigate.

Thanks,
— 
Dan


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

Re: Python 3

[Dan Eble]

On Sep 30, 2019, at 17:05, Matthew Peveler  wrote:
> 
> Please see attached for [ten] patches, which given the work done prior by 
> Jonas, allows for running the various make targets under both python2&3 
> (assuming application of my other two patches for py3)

The thought that gave rise to my question was that I would be more comfortable 
collaborating if these changes were in git rather than a dozen patches in 
multiple messages in the mailing list archive.  (I don’t intend that to sound 
mean.)

> my principle test was that the targets finished without error
> . . .
> The stepmake stuff though is were I have no idea how to handle as I am not 
> sure exactly what its purpose/doing is.

Is that pessimism?

If you want to discover whether the targets you are testing exercise the rules 
in python-module-rules.make, you can insert a command that will fail when you 
get there, e.g.

$(outdir)/%.pyo: $(outdir)/%.py
false # DO NOT COMMIT
$(PYTHON) -O -c 'import py_compile; py_compile.compile ("$<")'

If your tests are exercising those rules and nothing else seems to go wrong, 
that should reduce your concern.

Regards,
— 
Dan


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

Re: Python 3

[Dan Eble]

On Sep 30, 2019, at 14:22, David Kastrup  wrote:
> 
> But I don't see
> that a clean cut from Python2 to Python3 in a single step is easily
> feasible and testable for all targets at once including all GUB targets.

OK.

On Sep 27, 2019, at 16:34, Matthew Peveler  wrote:
> The primary thing missing is making
> the stepmake/stepmake/python-module-*.make files work for the range of
> versions, but I'm afraid that is out of my wheel house of ability.

Matt, I might be able to help with this, but can you describe more specifically 
what is lacking?  When your py changes are done, will the current makefiles 
continue to work in environments with Python 2, but require updates to work in 
environments with Python 3?

Regards,
— 
Dan


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