Re: [lmi] Fwd: How did this unit test fail?

[Vadim Zeitlin]

On Wed, 21 Mar 2018 13:31:14 +0000 Greg Chicares <address@hidden> wrote:

GC> [...I never got a copy at my ISP address...]

 I'm sorry, I forgot to cc it again :-( I've restored cc'ing by default to
avoid this problem in the future.

GC> >  I did, using the latest master, i.e. 3d3e2b67916c72c7446f140f2f9864
GC> > 56b1164b1e
GC> > 
GC> >         git checkout 3d3e2b6~ -- bourn_cast_test.cpp
GC> 
GC> I had expected that to give me a detached HEAD, but it didn't

 This is because "git checkout" is one of the most confusing Git commands
because it does several apparently completely unrelated things (which are,
in fact, related if you dive deep into Git implementation, but I definitely
don't think it's a good reason for it to work like this -- nor does anybody
else, AFAIK, but it's too late to change it now...). Without any paths, it
just changes HEAD, i.e. changes the current branch (or puts you in the
detached HEAD state), but with paths it updates their copies in the working
tree to match the specified revision (or, to confuse people even more, the
index) and does _not_ change HEAD.

GC> Suppose I wanted to undo that portion of that commit, and then
GC> commit it to 'master'. Would it be safe to run the command you
GC> gave above, then 'git commit bourn_cast_test.cpp'?

 Yes. This is exactly how "partial" undoing of commits can be done (a
complimentary method is to do "git revert -n" and then undo the changes to
the parts you don't want to revert, which can be more convenient if you
want to revert more than half of the commit).

GC> Or do I need to do something like 'git checkout master' first, and then
GC> apply that change in a more manual way?

 No, you're still on master after this command.

GC> > followed by
GC> > 
GC> >         make bourn_cast_test.exe
GC> >         make bourn_cast_test.exe-run
GC> 
GC> I still reproduce the error.

 And I reproduce it with your binary here, so it's definitely not Wine's
fault. And I expect my binary (which I'll send you in a moment) to work for
you, too, because it would be really strange if it behaved differently. So
the difference must be between compilers used, and I'll cross-compile this
test tomorrow (hopefully) to confirm this.

GC> > (BTW, wouldn't it make sense for "%-run" to depend on "%"?)
GC> 
GC> I would normally do this instead:
GC>   make $coefficiency unit_tests unit_test_targets=regex_test.exe 2>&1 |less 
-S

 Hmm, this works, but "make foo_test.exe-run" is slightly shorter and more
intuitive IMO.

GC> I'm wondering the problem could be that debian's MinGW-w64 package
GC> is missing some upstream fix. I'm using the latest:
GC> 
GC> # apt-get -s install g++-mingw-w64
GC> Reading package lists... Done
GC> Building dependency tree       
GC> Reading state information... Done
GC> g++-mingw-w64 is already the newest version (7.2.0-20+20.2).

 And I'm using i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z downloaded from
SF, which seems to be pretty close, but somehow produces a much smaller
binary which works differently. I'm not sure how could this be explained
but, the worst thing is that I have no idea about what to do to solve the
problem. I guess I could try rebuilding the Debian cross-compiler from the
latest MinGW sources, perhaps?

 Regards,
VZ