lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] wx_test_validate_output.cpp


From: Greg Chicares
Subject: Re: [lmi] [PATCH] wx_test_validate_output.cpp
Date: Thu, 12 Mar 2015 00:17:02 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-03-11 18:15, Vadim Zeitlin wrote:
> On Wed, 11 Mar 2015 10:48:41 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> My theory is that both problems reported in this message are related to
> GC> the wx action-simulation code, perhaps in combination with msw-xp.
> 
>  Thank you for your debugging and analysis (I feel bad for missing "#" vs
> "3" myself, now that you pointed it out, it seems totally obvious...), this
> is clearly the root of the problem. The "only" remaining question now is
> why doesn't it work for you when it works just fine for me: even when
> building using gcc 3.4.5 (I had already tested with MSVC, but now I also
> tested with gcc 4.8.2 from MinGW-64 and 3.4.5 additionally) and running
> under Windows XP (with SP3).

Skip this section if you like and go straight to the bad news below--I'm
"grasping at straws" here. [ http://en.wiktionary.org/wiki/grasp_at_straws ]

I'm running xp SP3 "professional" build 2600 in a VM, absolutely unpatched:
no "windows updates" whatsoever have been applied, so it's probably a bit
different from what you're running. I'm using mingw.org's gcc-3.4.5, same
as I have for many years.

There are some funny drivers--my NIC and GPU are Red Hat brand, and I have
a QEMU HDD--but I see nothing there that could account for this. It's almost
conceivable that the 'spice' service that integrates into the msw clipboard
could be a factor, but I have disabled that. Aside from some instability
issues, the VM seems to work correctly.

However, I did see something tenuously reminiscent of this once. That was
a debian-testing VM running in a debian-testing host (as opposed to the
debian-stable host I'm using now for msw). The symptom was that some
characters rendered incorrectly--e.g., '7' displayed as 'p', or something
like that. But that occurred only with certain styles, in particular
whatever iceweasel uses in its alt-D URL bar. And the characters worked
correctly, they just looked wrong--e.g., I'd see http://wx$idgeXs.orP,
but it would take me to the wx website. That's a very unlikely explanation
for the present problem, especially since it was a reported issue that
IIRC had been resolved in debian-unstable. But if it becomes necessary,
with great reluctance I can boot msw native, update wx and lmi there,
and repeat this test; however, msw-xp under qemu is now a primary
platform for lmi, so it's still important to fix this anyway.

BTW, my keyboard is plugged into a jack on the motherboard--not USB.
It's an IBM model M from 1984 which has never malfunctioned in any way
AFAIK. If that's not supported correctly, then it's a sign that the
world we know is about to end.

>  Could I please ask you to do another test? This time I'd like to ask you
> to build the uiaction wxWidgets sample and check if it also exhibits the
> bug? Here are the exact steps, just in case:
> 
>       cd /opt/lmi/wx-scratch/wxWidgets-3.1.0/gcc-345-*

[if my US coworkers want to try this, press Tab after the asterisk]

>       ../regen samples/uiaction/Makefile
>       make -C samples/uiaction -s
>       ./samples/uiaction/uiaction.exe

Very helpful, thanks.

>       # Press Alt-F,T
>       # Enter "#10_" in the message box
>       # What do you see in the text control?

I see: three, one, zero, hyphen.

Just to be sure, I copied it from the wx sample to the msw clipboard,
then ran
  $od -t x1
  [paste from clipboard]
  [manually enter ctrl-D once or twice]
and the bytes were:
  33 31 30 2d
whereas what I copied from your email and pasted into the sample was
  23 31 30 5f




reply via email to

[Prev in Thread] Current Thread [Next in Thread]