Re: Context regression tests (issue 348760043 by nine.fierce.ball...@gmail.com)

2018-05-12 Thread Carl . D . Sorensen 

On 2018/05/07 23:07:36, Dan Eble wrote:

On 2018/05/07 22:53:29, Dan Eble wrote:
> stop relying on duplicating type+ID



Carl,



I hope that these revisions address your concerns about the tests per

se.

After reviewing the revised tests, I am in favor of moving back to your
original patch, with the exception of keeping the added recommendation
about issuing a warning if there are two potential matches for
descendants of a particular context.

I had not realized that the search for the known ID contexts follows
exactly the same behavior as the search for contexts without given IDs.

I think that having the context ID's helps to make the behavior clearer.

Maybe instead of using "FAIL" and "PASS" for the instrument names, it
would be better to use "ORIGINAL" when the name is first given, and then
"PARENT", "CHILD", "GRANDCHILD", "SIBLING" etc. to identify the context
that is actually found.  Just a thought that might help make the whole
suite of tests easier to understand.

Thanks for your work on this.

Carl


https://codereview.appspot.com/348760043/

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

Re: logging an optional input location

2018-05-12 Thread Dan Eble 
On May 12, 2018, at 16:17, Carl Sorensen  wrote:
> 
> Does our code base use the optional second parameter anywhere?  If not, maybe 
> it would be even simpler to eliminate the optional second parameter, and just 
> call
> 
>  warning (_f (. . .), origin);
> 
> and keep all the testing for a null pointer in the warning function.

Carl,

I’m pretty confident I can enable that syntax, though there is a chance the 
implementation will be perceived as too clever; but since you mention it, I’ll 
give it a try and see how it turns out.

Thanks,
— 
Dan


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

Re: logging an optional input location

2018-05-12 Thread Carl Sorensen 


On 5/12/18, 1:49 PM, "lilypond-devel on behalf of Dan Eble" 
 wrote:

There’s this repetition in context.cc:

  if (origin)
{
  origin->warning (_f ("cannot find or create `%s' called `%s'",
   ly_symbol2string (n).c_str (), id));
}
  else
{
  warning (_f ("cannot find or create `%s' called `%s'",
   ly_symbol2string (n).c_str (), id));
}

I put up with this when it was just one instance, but it’s starting to 
multiply in my work in progress.

I see that ::warning already accepts a location string as an optional 
second parameter, so I am thinking of using that rather than creating yet 
another interface.  I am thinking of defining a helper function 
message_location(const Input*) to be used like this:

  warning (_f (. . .), message_location (origin));

Are there any strong objections to this?  If so, what would you prefer?

It seems like a good idea to eliminate all of these duplications.

Does our code base use the optional second parameter anywhere?  If not, maybe 
it would be even simpler to eliminate the optional second parameter, and just 
call

  warning (_f (. . .), origin);

and keep all the testing for a null pointer in the warning function.

However, I see that this could break existing uses, so it might be better to 
use your helper function.  But maybe the name source_location would be more 
clear than message_location (since we aren't displaying the location of a 
message, but the location in the source file of the bit that caused the 
message, IIUC).

Thanks,

Carl


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

logging an optional input location

2018-05-12 Thread Dan Eble 
There’s this repetition in context.cc:

  if (origin)
{
  origin->warning (_f ("cannot find or create `%s' called `%s'",
   ly_symbol2string (n).c_str (), id));
}
  else
{
  warning (_f ("cannot find or create `%s' called `%s'",
   ly_symbol2string (n).c_str (), id));
}

I put up with this when it was just one instance, but it’s starting to multiply 
in my work in progress.

I see that ::warning already accepts a location string as an optional second 
parameter, so I am thinking of using that rather than creating yet another 
interface.  I am thinking of defining a helper function message_location(const 
Input*) to be used like this:

  warning (_f (. . .), message_location (origin));

Are there any strong objections to this?  If so, what would you prefer?
— 
Dan


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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread Knut Petersen 



I don't think we should update a release last issued 5 years ago - so no 2.18.3.

It also seems that a security problem with no reported problems actually 
happening in 5 years can be so serious to warrant rushing out a new release?


The problem is known, it is published how to exploit the problem, and it is 
really easy to write an exploit.
I really think the problem is severe enough to justify a lilypond 2.18.3 
release.

stable/2.18 does not build on my openSuSE Tumbleweed system without a few 
patches, see issues #4814 and #4965.
Even with those patches make doc fails, but an easy fix is to default 
gs_load_fonts to true:

   diff --git a/scm/lily.scm b/scm/lily.scm
   index 9b0a6d2aad..5f565d8c07 100644
   --- a/scm/lily.scm
   +++ b/scm/lily.scm
   @@ -232,7 +232,7 @@ regression testing.")
  "Pad left edge of the output EPS bounding box by
 given amount (in mm).")
 (gs-load-fonts
   - #f
   + #t
  "Load fonts via Ghostscript.")
 (gs-load-lily-fonts
  #f



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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread Phil Holmes 
- Original Message - 
From: "David Kastrup" 

To: "Knut Petersen" 
Cc: "dondelelcaro" ; "lilypond-devel" 


Sent: Saturday, May 12, 2018 11:27 AM
Subject: Re: [testlilyissues:issues] Moderation action required



Knut Petersen  writes:


Am 12.05.2018 um 09:16 schrieb James Lowe:

Dev team,

Don tacked a patch on the end of an already-fixed issue.


James, they try to fix lilypond 2.18, not 2.20 or master.

2.18 is still insecure.


At this point of time we probably really need to decide to release 2.20,
come hell and high water, including its current faults.

Or pitch out 2.18.3.  At the very least it might make sense to add
purely compilation fixes (for keeping up with more current versions of
compilers etc) to the current stable branch in future even if one does
no proper release.  Possibly even security fixes.  That way there is
some semi-official way of dealing with bit rot.  Also makes it easier to
do regression testing 5 years later.

--
David Kastrup


I don't think we should update a release last issued 5 years ago - so no 
2.18.3.


It also seems that a security problem with no reported problems actually 
happening in 5 years can be so serious to warrant rushing out a new release?


--
Phil Holmes 



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

Re[2]: [testlilyissues:issues] Moderation action required

2018-05-12 Thread Trevor 



David Kastrup wrote 12/05/2018 11:27:40


James, they try to fix lilypond 2.18, not 2.20 or master.

2.18 is still insecure.


At this point of time we probably really need to decide to release 
2.20,

come hell and high water, including its current faults.

Or pitch out 2.18.3.  At the very least it might make sense to add
purely compilation fixes (for keeping up with more current versions of
compilers etc) to the current stable branch in future even if one does
no proper release.  Possibly even security fixes.  That way there is
some semi-official way of dealing with bit rot.  Also makes it easier 
to

do regression testing 5 years later.


"decide to release 2.20"? Yes. Better still: "And" rather than "Or".

If details of the regressions in 2.20.0 are provided alongside the 
improvements

folk can decide which of 2.18.3 and 2.20.0 suits them best.

Trevor


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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread David Kastrup 
Knut Petersen  writes:

> Am 12.05.2018 um 09:16 schrieb James Lowe:
>> Dev team,
>>
>> Don tacked a patch on the end of an already-fixed issue.
>
> James, they try to fix lilypond 2.18, not 2.20 or master.
>
> 2.18 is still insecure.

At this point of time we probably really need to decide to release 2.20,
come hell and high water, including its current faults.

Or pitch out 2.18.3.  At the very least it might make sense to add
purely compilation fixes (for keeping up with more current versions of
compilers etc) to the current stable branch in future even if one does
no proper release.  Possibly even security fixes.  That way there is
some semi-official way of dealing with bit rot.  Also makes it easier to
do regression testing 5 years later.

-- 
David Kastrup

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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread Knut Petersen 

Am 12.05.2018 um 09:16 schrieb James Lowe:

Dev team,

Don tacked a patch on the end of an already-fixed issue.


James, they try to fix lilypond 2.18, not 2.20 or master.

2.18 is still insecure.

Knut

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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread James Lowe 
Don,

On Sat, 12 May 2018 09:24:17 +0200, David Kastrup  wrote:

> "James Lowe"  writes:
> 
> > Dev team,
> >
> > Don tacked a patch on the end of an already-fixed issue.
> >
> > https://sourceforge.net/p/testlilyissues/issues/5243
> >
> > I assume this needs a new issue?
> 
> Basically yes, and definitely with an explanation of why the committed
> fix is not considered sufficient.
> 

If you can add some meat to your comment, I can create a new ticket for your 
proposed patch.

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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread David Kastrup 
"James Lowe"  writes:

> Dev team,
>
> Don tacked a patch on the end of an already-fixed issue.
>
> https://sourceforge.net/p/testlilyissues/issues/5243
>
> I assume this needs a new issue?

Basically yes, and definitely with an explanation of why the committed
fix is not considered sufficient.

-- 
David Kastrup

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

Re: [testlilyissues:issues] Moderation action required

2018-05-12 Thread James Lowe 
Dev team,

Don tacked a patch on the end of an already-fixed issue.

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

I assume this needs a new issue?

Let me know.

James

On Fri, 11 May 2018 16:52:11 -, "Don Armstrong" 
 wrote:

> The following submission requires approval at 
> https://sourceforge.net/p/testlilyissues/issues/_discuss/moderate before it 
> can be approved for posting:
> 
> I have just uploaded a fix to Debian which switches to using `system*` 
> instead of `system`:
> https://salsa.debian.org/debian/lilypond/commit/788b56e4b7f62637481af65b4b2929649c30fe78
> 
> Not sure if this is cross-platform enough, but it solves the issue for 
> systems with a working system* call.
> 
> 
> ---
> 
> Sent from sourceforge.net because you indicated interest in 
> 
> 
> 
> 
> To unsubscribe from further messages, please visit 
> 



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