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