Re: file-io.cc-tst failures

[Rik]

On 11/13/2013 02:13 AM, address@hidden wrote:
> Message: 8
> Date: Wed, 13 Nov 2013 11:13:23 +0100
> From: Julien Bect <address@hidden>
> To: Octave Maintainers <address@hidden>
> Subject: Failure in file-io.cc-tst
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Dear Maintainers,
>
> I get the following error in make check (changeset b5bf26a054bd):
>
>  >>>>> processing 
> /media/data/sources/octave/core/libinterp/interpfcn/file-io.cc-tst
>    ***** test
>   assert (sscanf ("1,2", "%f", "C"), 1)
>   assert (sscanf ("1,2", "%f", "fr_FR"), 1.2)
> !!!!! test failed
> ASSERT errors for:  assert (sscanf ("1,2", "%f", "fr_FR"),1.2)
>
>    Location  |  Observed  |  Expected  |  Reason
>       ()           1           1.2        Abs err 0.2 exceeds tol 0
>
>
> I didn't notice it before, but I can't tell when it started to appear (I 
> can bisect later, if that's useful).
>
> Is anyone else but me having this failure ?
>
> I have found two related posts:
>
> http://octave.1599824.n4.nabble.com/New-test-fail-td4310273.html
> http://octave.1599824.n4.nabble.com/One-fail-file-io-td4357014.html
>
> but they are more than one year old, with no mention of how the problem 
> was solved, and also one (closed) bug report :
>
> https://savannah.gnu.org/bugs/?35364
>
> Let me know if I can help with further testing.
>
> @++
> Julien
11/13/13

Julien,

You have left-over cruft on your system.  There used to be %!tests in
file-io.cc and so Octave would generate a file-io.cc-tst file.  But, those
tests were removed.  The simplest way to get a clean tree is to hg clone a
new copy.  I often have lots of small projects and files that I am working
on so I don't use hg clone.  Instead, to avoid the cruft build-up I
periodically weed the directory tree.  Try 'hg stat -u > u.list' which will
produce a list of files which are not under Mercurial control, and then
delete any that don't belong to you.  I also do 'hg stat -i > i.list' from
time to time because certain suffixes, like .o, are ignored rather than
unknown.  When the build system changes a lot, as it has been doing, you
often end up with orphaned object files.

--Rik