[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Make Check Failures
From: |
Markus Mützel |
Subject: |
Re: Make Check Failures |
Date: |
Fri, 21 Feb 2020 10:21:47 +0100 |
Am 21. Februar 2020 um 07:38 Uhr schrieb "Markus Mützel":
> Am 20. Februar 2020 um 22:36 Uhr schrieb "John W. Eaton":
> > On 2/20/20 3:40 PM, Thomas D. Dean wrote:
> > > Just updated source, make, and make check shows 10 Failures.
> >
> > I see the same failures if I run make check with LANG=C in the
> > environment but no failures if I use LANG=en_US.UTF-8. I don't think
> > tests should fail based on locale settings, but I'm not sure what the
> > right solution is either. Maybe it would be better to discuss this on
> > the maintainers list or file a bug report about it?
>
> This is probably due to this change:
> https://hg.savannah.gnu.org/hgweb/octave/rev/118606de9359
>
> I'll work on a fix for this.
The following changeset should fix the issue by overwriting the locale for the
test suite:
http://hg.savannah.gnu.org/hgweb/octave/rev/818bd5b42651
There seems to be an additional issue:
If LANG=C, __locale_charset__ returns "ANSI_X3.4-1968". Conversely, Qt's
QTextCodec::codecForLocale returns "UTF-8". I didn't expect to see different
results.
This is probably because we override CodecForLocale in octave-qobject.cc
(base_qobject) on non-Windows systems. I'm not sure why this is done, or why it
is OS specific.
But since this is the case, we cannot rely on QTextCodec::codecForLocale to
return the codec for the locale charset.
I'll try and find the places where QTextCodec::codecForLocale should be
replaced by octave_locale_charset_wrapper.
If you don't work with non-ASCII characters, everything is fine already. If you
do, there are a few possible solutions: Set a UTF-8 locale for your system. Add
'__mfile_encoding__ ("UTF-8")' to your .octaverc. Or if you are using the GUI,
select "UTF-8" in the "Text encoding used for loading and saving" drop down
list in the editor preferences.