octave-maintainers
[Top][All Lists]
Advanced

[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 11:36:46 +0100

Am 21. Februar 2020 um 10:21 Uhr schrieb "Markus Mützel":
> 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.

This changeset makes these changes:
http://hg.savannah.gnu.org/hgweb/octave/rev/f2789cae04f3

Also, moving the thread over to the maintainers mailing list.

> 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.

Markus




reply via email to

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