lmi
[Top][All Lists]
Advanced

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

Re: [lmi] What encoding does wx_test console output use?


From: Vadim Zeitlin
Subject: Re: [lmi] What encoding does wx_test console output use?
Date: Sat, 15 Sep 2018 00:48:26 +0200

On Fri, 14 Sep 2018 18:30:30 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-09-08 14:28, Greg Chicares wrote:
GC> > On 2018-09-08 12:36, Vadim Zeitlin wrote:
GC> >> On Sat, 8 Sep 2018 09:57:24 +0000 Greg Chicares <address@hidden> wrote:
GC> >> 
GC> >> GC> $wine ./wx_test --ash_nazg --data_path=/opt/lmi/data 
--pyx=only_new_pdf >../src/lmi/wx_test_output
GC> >> GC> $file -bi wx_test_output
GC> >> GC> application/octet-stream; charset=binary
GC> >> GC> 
GC> >> GC> I'd like to filter this, removing expected lines and leaving only
GC> >> GC> unexpected--much as 'nychthemeral_test.sh' does for other tests
GC> >> GC> with its '_clutter' sed scripts. I suppose
GC> >> GC>   iconv -t UTF-8 -f SOME_ENCODING wx_test_output
GC> >> GC> might work, for some value (what?) of SOME_ENCODING.
GC> >> 
GC> >>  Under "genuine" MSW it would be UTF-16, but I didn't test if it was the
GC> >> same thing under Wine. I'd expect it to be...
GC> > 
GC> > Yes, thanks, this converts it:
GC> >   iconv -t UTF-8 -f UTF-16
GC> 
GC> Unfortunately, some output converted to Chinese characters. I figured out
GC> that the source must be 'wine', because what I saw closely matched this:
GC> 
GC> $echo "In file /cache_for_lmi/vcs/wxWidgets/src/msw/mdi.cpp at line 1488: 
'SendMessage(WM_MDISETMENU)' failed with error 0x00000578 (Invalid window 
handle.)." |iconv -f UTF-16 -t UTF-8
GC> 湉映汩⁥振捡敨晟牯江業瘯獣眯坸摩敧獴猯捲洯睳洯楤挮灰愠⁴楬敮ㄠ㠴㨸✠敓摮敍獳条⡥䵗䵟䥄䕓䵔久⥕‧慦汩摥眠瑩⁨牥潲⁲砰〰〰㔰㠷⠠湉慶楬⁤楷摮睯栠湡汤⹥⸩

 I don't understand at all how could this message be output in ASCII. It
should have gone through the same channel as the other wxLog messages...

GC> This isn't the first problem that 'wide' characters have caused us:
GC>   https://lists.nongnu.org/archive/html/lmi/2016-02/msg00022.html

 Well, this was rather different as it was just a bug in wxWidgets
(facilitated by the variety of different MinGW versions that it needs to
support).

GC> so I changed the tests to emit ASCII.

 Honestly, I don't think it's a good idea. Using wxPrintf() should work and
even if we don't use it in the tests code, the library can still use it
internally. So now under MSW you would get a not easily decipherable mix of
ASCII and UTF-16 and under Unix you will just silently not get some output
at all (because of the great design of the wide mode). I'd like to ask you
to reconsider and let me try to reproduce the original problem and fix it.
But I won't do unless you explicitly agree to it, as this would require
reverting your recent changes.

 Please let me know,
VZ


reply via email to

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