Re: [lmi] NDEBUG

[Greg Chicares]

On 2014-12-04 21:22Z, Vadim Zeitlin wrote:
> On Wed, 29 Oct 2014 18:51:49 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2014-10-27 18:32Z, Vadim Zeitlin wrote:
> GC> [...]
> GC> >  We can use wxIsDebuggerRunning(), which is just a wrapper for
> GC> > IsDebuggerPresent(), but doesn't require including <windows.h> directly.
> GC> > 
> GC> >  To summarize, I think setting wxLogStderr as active log target only if
> GC> > wxIsDebuggerRunning() returns false is indeed the best solution.
> GC> 
> GC> Committed 20141029T1839Z, revision 6007.
> 
>  Sorry to return to this, but I'm afraid I was wrong above when I wrote
> that this change was the best solution -- and that it was wrong to make it.

Don't worry too much about it. I calmed down as soon as I got past the
"Subject:" header and understood that you didn't want to have another
discussion about the NDEBUG macro. Users rarely if ever see any wx
diagnostics, so it's not really scary to think that they're blocked
by accident for a month.

Because this was wrong once, let's start by figuring out how to test
it, so that we can be certain it's right after we fix it. Already I'm
lost. I did run this test with the original r6007 change:

/opt/lmi/bin[0]$./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
  Test | Test system command
  x
  OK

and observed these effects, which I guessed were exactly correct:

Messagebox:
  Error | Command 'x' not recognized.
and in the terminal:
  01:52:19: Error: Execution of command 'x' failed (error 2: the system cannot 
find the file specified.)

A similar test uses the command "ls x", which elicits a messagebox:
  Error
  Exit code 2 from command 'ls x'.
  Errors:
  ls: cannot access x: No such file or directory
and writes nothing to the terminal; again, I guessed that this was correct.

Should the outcome of these tests be different? Do we need a different
test? And is there a way to automate a test for whatever GUI phenomena
would be correct? (I'm not sure we should contemplate extending 'wx_test'
to look for phenomena on the console.)

>  In fact, the problem was that I lost from sight the problem we were trying
> to find the solution for. AFAICS it was originally formulated here:
> 
> On Sun, 26 Oct 2014 16:29:58 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> While lmi is running, wx potentially generates diagnostic messages. Only
> GC> the most severe messages are displayed; others aren't by default, because
> GC> they would perplex end users. Yet all these diagnostics are potentially
> GC> helpful to me, as they may indicate latent defects, so I would like to
> GC> be able to see them all myself. And that's the entire goal.
> 
>  I.e. the goal was to see the diagnostic messages not shown by default.

Let me try to express it myself. End users start lmi from an msw "shortcut";
they should continue to see the most severe errors, in messageboxes, as
always. Kim, Wendy, and I normally start lmi from zsh in a mintty terminal;
we want to see what end users see, and in addition we want the less-severe
wx diagnostics (that end users do not see) to display for us on stderr.

Of course, I'm assuming that stderr is effectively /dev/null for end users
because they have no console. I certainly wouldn't want the OS to create a
console for them to display the less-severe messages that we don't want to
bother them with.

> However the effects of the change of r6007 are almost exactly the converse:
> by setting the active log target to wxLogStderr, it ensures that the end
> users do not see even the severe messages any more!

Please tell me how to reproduce this so that I can see it for myself.

>  Somehow this goal has been replaced with the one of finding a way to send
> the messages to stderr only when not running under a debugger later, but
> this doesn't seem to have been intentional.

As I recall it, we made some change that we thought would achieve the
goal I restated above, and then found that it had some undesired effect
for you when you run lmi in the msvc debugger; and that's why we
guarded it with the is-debugger-running condition.

> At least I don't see at any
> point a conscious decision being made about stopping showing the errors
> inside wxWidgets, which are shown using wxLogXXX() functions, to the user.
> Yet, again, this is what r6007 did.
> 
>  So I believe this change was wrong and the correct change would be to
> define a custom log target sending the normally user visible logs (i.e.
> starting from severity wxLOG_Info) to wxLogGui, as usual, while sending the
> debug logs to stderr and/or debugger output under Windows. Do you agree
> with this? If so, I can quickly make a patch implementing this behaviour.

If your analysis of the behavior is correct, then I suppose I should
want to fix it. But that's still hypothetical for me, because I can't
see what's wrong.