I checked in a change here which lookt at the returned Java version and splits it into new or old style before processing. I also marked the bug with Integer.compareTo with report number 51804. See http://hg.savannah.gnu.org/hgweb/octave/rev/5aa9c885ea18.
|
Sorry, I missed report #51804. However, could you mark this test as a known bug?
Bye
Sebastian
|
I agree with Mike. The compareTo is something deep in the Octave<->Java interface and beyond my understanding.
I don't mind making the change on the version. I think that was there mostly to make sure the interface is working at all.
|
The compareTo bug is already reported, see bug #51804. Needs someone with a deeper understanding of the Java API and maybe a rewrite for how Octave inspects and searches for matching method overloads.
|
Thanks Rik! Your fix for TMP works... the last issues that I see are in ov-java.cc-tst:
This is due to Java 9 calling itself "9" instead of "1.9". We could do
Furthermore
fails but
would work. Not sure why this was no issue before.
|
I checked in a change to save, clear, and then restore the environment variables TMPDIR and TMP when running certain BIST tests (http://hg.savannah.gnu.org/hgweb/octave/rev/276eca875721).
|
I guess the test was written under the assumption that no one would set TMP on any GNU or Unix system because it doesn't normally do anything. But Octave does use TMP as an override for the P_tmpdir compile-time constant if it is set regardless of OS.
|
Arrgh. Even Linux pays attention to both TMP and TMPDIR. I think that particular test needs to be re-coded. Re-opening this report and marking as "In Progress".
|
@Rik: It's quite complicated to understand what is going on because this problem occurs mainly when using homebrew as a package manager. Homebrew calls configure and make from its own environment (using ruby). The code
if (ispc ())
envname = "TMP";
else
envname = "TMPDIR";
endif
envdir = getenv (envname);
unsetenv (envname);
## Strip trailing file separators from P_tmpdir
def_tmpdir = P_tmpdir;
while (length (def_tmpdir) > 2 && strfind (filesep ("all"), def_tmpdir(end)))
def_tmpdir(end) = [];
endwhile
## Test 0-argument form
fname = tempname ();
[tmpdir, tmpfname] = fileparts (fname);
assert (tmpdir, def_tmpdir);
fails with
error: ASSERT errors for: assert (tmpdir,def_tmpdir)
Location | Observed | Expected | Reason
[] /tmp /var/tmp Strings don't match
and experiments in that environment show
octave:1> fname = tempname ()
fname = /var/tmp/oct-ynlTG9
octave:2> setenv("TMPDIR","/tmp")
octave:3> fname = tempname ()
fname = /var/tmp/oct-LmECe5
octave:4> setenv("TMP","/tmp")
octave:5> fname = tempname ()
fname = /tmp/oct-zFVL0A
and in my user environment
octave:1> fname = tempname ()
fname = /var/folders/yr/0kxqs6ns5_ncvr7v_sg568ww0000gp/T/oct-vpF8Ub
octave:2> setenv("TMPDIR","/tmp")
octave:3> fname = tempname ()
fname = /var/tmp/oct-e4Moqt
octave:4> setenv("TMP","/tmp")
octave:5> fname = tempname ()
fname = /tmp/oct-yIW2Zw
However, in either case "TMP" seems to have preference over "TMPDIR".
Bye
Sebastian
|
@Sebastian: Could you post the failing test to this bug report so I can take a look? According to multiple Google hits, TMPDIR is supposed to be the environment variable that sets the temporary directory, not TMP. It may be that Mac OSX has a hierarchy of values with TMPDIR first, TMP second, etc.
|
I observe a test failure in "file-io.cc-tst" on macOS if the environment variable "TMP" is set. It's easily fixed by replacing "if (ispc ())" by "if (ispc () || ismac())" which makes sense since the tmp-environment-variable on macOS is indeed "TMP". However, if "tempname()" should be independent of the environment variables then this might also be a bug.
|
I changed some tolerances to as much as 5 eps and now the acos BIST tests pass. There are real problems with the hyperbolic inverse functions. They are provide by whatever math library Apple is using, but they are pretty innacurate when compared to gcc's libm or to Mathematica's variable precision. Since this is a known issue, and not really Octave's problem, I marked the failing tests as xtests only for the Mac platform (http://hg.savannah.gnu.org/hgweb/octave/rev/a6753fc10731).
|
I changed the errors related to bug #47413 (a bad libc++ implementation of iostream library) into xtests on the Mac platform. The buildbot confirms this (http://buildbot.octave.org:8010/builders/clang-osx/builds/793/steps/test/logs/stdio).
The remaining errors are due to differences in the inverse trigonometric functions. Any ideas on how to resolve those? Do we run the results in a variable precision calculator and determine what the true results should be and whose implementation is off? Do we just relax the tolerances?
|
I fixed the errors with sorting of complex numbers on Mac platforms here (http://hg.savannah.gnu.org/hgweb/octave/rev/138c2380521c). It is confirmed by the buildbot results: http://buildbot.octave.org:8010/builders/clang-osx/builds/770/steps/test/logs/stdio which now have 7/7 passing for complex.tst.
|
@Ben: No, I'm leaving their libraries alone. I've interacted with some Mac zealots before and my life is too short to want to do that again. They believe they are right and won't be convinced otherwise.
My plan was to add a separate code template just for floats and just for the Mac platform using #if defined. In that template I would calculate the value of PI according to their library. That value would be calculated just once and stored in a static variable. Thereafter I would use that new value for the PI constant in all comparisons.
|
@Rik, silly question, but .... you're thinking about patching atan2 on MacOS? rather than redefining PI to match the atan2 result?
|
Thank you Ben! And just as expected, everything is mostly good except for std::arg of -1 + 0i.
Mac: 3.1415925025939941
Linux: 3.1415927410125732
Clearly they are both approximately PI to 7 digits, but the math lib constant for PI does not match the atan2 result for PI which leads to problems.
I think I can code around that by using a static variable on Macs to hold the value of whatever they think PI is.
|
Thanks Dimitri, I should have been able to figure that our ;-)
MacOS results
|
You probably need to compile it with "clang++"
Try
and
Dmitri.
--
|
@Rik, I get errors on MacOS (10.13.2)
|
Does anyone have access to a mac to test the C++ programe in comment #13? Should I ask on the maintainer's list?
|
@Mike: I was working from your list. I knocked off the issue in fileattrib.m and the issue in camzoom.m. I'm not sure I want to tackle the issues in the math libraries.
For the sorting issue, I'm pretty sure that the problem is a cast to float on the constant M_PI. Could someone with access to a Mac try this C++ program and report the results?
The file is attached as tst_arg.cc. One should be able to compile it with
The results on my Linux machine are
If it turns out to be the problem with casting then we could always override the generic templated code in liboctave/util/oct-cmplx.h with a specialization for floats on Mac platforms.
|
I see the same problems with trig and hyperbolic functions
on linux. E.g.:
(clang/libc++)
I do NOT see sort problems on linux.
Dmitri.
--
|
I summarized all of the macOS test failures earlier: https://lists.gnu.org/archive/html/octave-maintainers/2017-11/msg00071.html
The complex sorting is a distinct issue from the LLVM numeric string parsing, I don't know what the cause is, may be a macOS system math library issue.
|
@Dmitri: that probably indicates that std::arg for floats isn't returning the same values as everybody else. I'm not surprised because their atan2 function for floats is different.
|
FWIW it does pass on Fedora/clang/libc++
Dmitri.
--
|
The sort code for this special case is in liboctave/util/oct-cmplx.h. I suspect what is going on is that the arg() function for floats is computed slightly differently with clang's libc++. And static_cast<float> (M_PI) probably doesn't match this value.
Example code:
|
@Mike: Since you're quite familiar with the tests, do you know quickly why this one in complex.tst is failing?
It's obvious that the results aren't sorted according to the special sequence that Octave uses of magnitude followed by phase angle, but we ship our own sort routine as far as I know.
|
I compiled dev on Fedora with clang and libc++.
I had to disable arpack and magick
Summary:
PASS 15744
FAIL 13
REGRESSION 5
XFAIL (expected failure) 5
XFAIL (reported bug) 34
SKIPPED (feature) 239
If there is an interest we could add a fedora-clang-libcxx
buildbot slave to separate MacOS's problems from other issues.
Dmitri.
--
|
It seems like those defaults are bound to persist at an operating system level--Linux systems will continue to link against GCC's libstdc++ and macOS wil link against clang's libc++.
I think that is enough of a positive correlation to place guard's around these tests. Even if the clang library is changed, the future of when that change is very uncertain. The last comment in the link you sent is from February, 2017. 10 months and no mention of forward progress are not confidence inspiring.
|
Sorry, it's actually a bug with the LLVM project's implementation of the C++ runtime, not the compiler itself. The clang compiler can be configured to build with either GCC's libstdc++ or with LLVM's own libc++ library.
On GNU/Linux systems the default is to use GCC's libstdc++, and the error does not occur. On macOS the default is to use clang's own libc++.
One can reproduce this on any operating system by building with "-stdlib=libc++" added to CXXFLAGS, assuming you have the clang libc++ library and headers installed.
|
For the record -- on Fedora buildbot clang (at the moment) is:
lang -v
clang version 4.0.1 (tags/RELEASE_401/final)
Dmitri.
--
|
But isn't it the case that it is only the clang version that is shipped with Mac OS X that actually has the problem. Looking at the buildbots, clang4 and clang5 on debian, and clang on Fedora, all pass this test.
If this is reliably correlated with operating system, can we use "! ismac ()" as a guard around the failing tests?
|
See bug #47413.
This is a clang compiler bug, not a macOS operating system bug.
The clang compiler does not handle numeric parsing correctly.
See the open clang bug https://bugs.llvm.org/show_bug.cgi?id=17782, in which the devs seem to be open to fixing this behavior, pending some clarification in the C++ specifications.
|
There is an automatic buildbot which compiles the latest Octave development version and then runs the test suite. See http://buildbot.octave.org:8010/waterfall.
I've resolved two of the errors by inspecting the logfiles. But for the others I need some help because I don't have a Mac computer.
I'm hoping someone who can build on Mac OS X can be a partner for me on this bug report and run tests as I need them so we can reduce the number of failing tests from 15, to potentially 0.
The first function I want to try and fix is str2double which I think is causing several other failures.
Could someone run the following code on a Mac with a newly compiled version of the Octave development code?
Upload the diary file "diary1.txt" to this bug report and I'll investigate.
|