Re: Issue 5590: Remove dead code from Dot_formatting_problem (issue 583100043 by nine.fierce.ball...@gmail.com)

2019-11-01 Thread Carl . D . Sorensen

On 2019/11/01 17:18:34, Dan Eble wrote:

On 2019/10/29 19:38:23, Carl wrote:
> My bottom line is that the current system is definitely broken.



Yes, and the thing that bugs me most is that it reallocates memory per
candidate, for no benefit.



> I will look into my code tonight when I get home and see how I
> handled the "best" issue.



If you need more time, I won't be offended if we keep this patch in

"countdown"

a bit longer; however, I don't want the best to become the enemy of

the good.

If someone later wants to return to this, it's not hard to revert it

in git, nor

is it hard to reimplement a loop to find the best of a series of

things

properly.


OK. let's move ahead with the patch as proposed.  If I have stuff that
uses "best", it's already not in master, and my patch can add it.

If not, it's really not doing much  (if any) good to have NOP code
hanging around.





https://codereview.appspot.com/583100043/



Re: Issue 5590: Remove dead code from Dot_formatting_problem (issue 583100043 by nine.fierce.ball...@gmail.com)

2019-11-01 Thread nine . fierce . ballads

On 2019/10/29 19:38:23, Carl wrote:

My bottom line is that the current system is definitely broken.


Yes, and the thing that bugs me most is that it reallocates memory per
candidate, for no benefit.


I will look into my code tonight when I get home and see how I
handled the "best" issue.


If you need more time, I won't be offended if we keep this patch in
"countdown" a bit longer; however, I don't want the best to become the
enemy of the good.  If someone later wants to return to this, it's not
hard to revert it in git, nor is it hard to reimplement a loop to find
the best of a series of things properly.

https://codereview.appspot.com/583100043/



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

2019-11-01 Thread 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: can't update makeinfo from 5.1

2019-11-01 Thread David Nalesnik
On Fri, Nov 1, 2019 at 5:12 AM Werner LEMBERG  wrote:
>
>
> > When I run configure, an error is returned saying that makeinfo is
> > too old (5,2).  When I run sudo apt-get install texinfo, I'm told
> > that I have the latest version.  makeinfo --version still returns
> > 5.2.
>
> Ouch.  `makeinfo` is part of texinfo.  Version 5.2 was published
> September 2013!
>
> The current version is 6.6, published February 2019.
>
> So please either use an add-on repository for your GNU/Linux
> distribution to get a newer texinfo version, or install it directly
> from the tarball.
>

Will try and report back.

Thanks!



Re: can't update makeinfo from 5.1

2019-11-01 Thread Werner LEMBERG


> When I run configure, an error is returned saying that makeinfo is
> too old (5,2).  When I run sudo apt-get install texinfo, I'm told
> that I have the latest version.  makeinfo --version still returns
> 5.2.

Ouch.  `makeinfo` is part of texinfo.  Version 5.2 was published
September 2013!

The current version is 6.6, published February 2019.

So please either use an add-on repository for your GNU/Linux
distribution to get a newer texinfo version, or install it directly
from the tarball.


Werner



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

2019-11-01 Thread Werner LEMBERG


>> [...] 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?


Werner