Re: [lmi] [PATCH] C++ m11n: range-based for loops

[Greg Chicares]

On 2017-01-13 15:32, Vadim Zeitlin wrote:
> On Fri, 13 Jan 2017 13:53:45 +0000 Greg Chicares <address@hidden> wrote:
> 
> [... debugging discussion mostly snipped ...]
> GC> Maybe I have gdb in this chroot:
> GC>   $whence gdb
> GC> No, I don't; and no 'i686-w64-mingw32-gdb' either.
> 
>  But why not? It's part of gdb-mingw-w64 package which can be easily
> installed and I had no trouble using it in remote debugging mode.

Then I guess I should add that to 'README.schroot' and install it.
I just kind of figured that if the MinGW-w64 project provided it,
I'd have gotten it by installing g++-mingw-w64-i686. And I use gdb
so rarely that I hadn't noticed its absence previously.

> [... skipping to successful conclusion ...]

[... I needed the following crucial hunk from the second patch...]

> GC> 
> https://github.com/vadz/lmi/commit/6afb131f2d5d16aadb3b00dfc852d0cfba6949b6.patch
> GC>          for(auto& cell_value: cell_values)
> GC>              {
> GC>              cell_value->InitializeLife(run_basis);
> GC> -            MaxYr = std::max(MaxYr, (*i)->GetLength());
> GC> +            MaxYr = std::max(MaxYr, cell_value->GetLength());
> GC>              }
> GC> 
> GC> where Vadim manually corrected the problem...and I was wondering how
> GC> 'patch' could have failed to apply that, without giving any warning.
> GC> 
> GC> I had thought that the first patch, being mostly generated by clang-tidy,
> GC> would be the safer of the two. I didn't realize that the second corrects
> GC> the first (at least in this hunk) as well as introducing more changes.
> 
>  Sorry, I'm afraid I mangled my commits here :-( Rerunning clang-tidy on
> just group_values.cpp now I see that it didn't touch this loop at all
> (probably because the iterator variable scope is not limited to the loop)
> and so the change above must have been done manually by me, yet somehow
> half-committed as part of the automatic changes. Really sorry for wasting
> your time, it would probably be better to apply both commits before testing
> further as if I made such a mistake here, I could have done it elsewhere as
> well.

No, I think the first patch (with that one extra change, above) is
okay: it passes all my tests. However, I reverted all changes and
applied both patches in order, and they both applied perfectly, but
now I seem to have a problem already with the smallest test, as
follows; did you have the same problem, or have I broken something?
I'm quite sure I haven't removed the chroot's /opt directory.

/opt/lmi/src/lmi[0]$make $coefficiency cgi_tests cli_tests              
Test common gateway interface:
make[2]: warning: -jN forced in submake: disabling jobserver mode.
Test command line interface:
boost::filesystem::is_directory: "opt": File not found.
  172 errors
/opt/lmi/src/lmi/workhorse.make:1176: recipe for target 'cli_selftest' failed
make[2]: *** [cli_selftest] Error 1
Test sample.cns:
boost::filesystem::is_directory: "opt": File not found.
boost::filesystem::is_directory: "opt": File not found.
/opt/lmi/src/lmi/workhorse.make:1186: recipe for target 'cli_test-sample.cns' 
failed
make[2]: *** [cli_test-sample.cns] Error 1
Test sample.ill:
boost::filesystem::is_directory: "opt": File not found.
boost::filesystem::is_directory: "opt": File not found.
/opt/lmi/src/lmi/workhorse.make:1186: recipe for target 'cli_test-sample.ill' 
failed
make[2]: *** [cli_test-sample.ill] Error 1
/opt/lmi/src/lmi/workhorse.make:1163: recipe for target 'cli_tests' failed
make[1]: *** [cli_tests] Error 2
GNUmakefile:162: recipe for target 
'/opt/lmi/src/lmi/../build/lmi/Linux/gcc/ship' failed
make: *** [/opt/lmi/src/lmi/../build/lmi/Linux/gcc/ship] Error 2
make: Target 'cgi_tests' not remade because of errors.
make: Target 'cli_tests' not remade because of errors.
/opt/lmi/src/lmi[2]$