octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ov-java.cc-tst fails on Lubuntu 14.04


From: Rik
Subject: Re: ov-java.cc-tst fails on Lubuntu 14.04
Date: Tue, 02 Jun 2015 16:12:48 -0700

On 06/02/2015 03:31 PM, Tatsuro MATSUOKA wrote:
> ----- Original Message -----
>> From: Rik 
>> To: Tatsuro MATSUOKA 
>> Date: 2015/6/3, Wed 03:50
>> Subject: Re: ov-java.cc-tst fails on Lubuntu 14.04
>>
>>
>> On 06/01/2015 09:00 AM, address@hidden wrote:
>>
>> Subject:  ov-java.cc-tst fails on octave 4.0.0 on lubuntu 14.04 
>>> From:  Tatsuro MATSUOKA <address@hidden> 
>>> Date:  05/31/2015 11:37 PM 
>>> To:  "address@hidden" <address@hidden> 
>>> List-Post:  <mailto:address@hidden> 
>>> Content-Transfer-Encoding:  quoted-printable 
>>> Precedence:  list 
>>> MIME-Version:  1.0 
>>> Reply-To:  Tatsuro MATSUOKA <address@hidden> 
>>> Message-ID:  <address@hidden> 
>>> Content-Type:  text/plain; charset=iso-8859-1 
>>> Message:  3 
>>>
>>> I have built octave 4.0.0 on Ubuntu 14.04 LTS (amd64) and Lubuntu 14.04. On 
>>> Ubuntu 14.04 LTS (amd64),make check shows no FAIL after workaround 
> $ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so. On  Lubuntu 14.04 
> (32bit), I have met the following FAIL.
> libinterp/octave-value/ov-java.cc-tst ....................... PASS      4/5   
>                                                                   FAIL    1 
>>>>>>>> processing 
>>>>>>>> /home/matsuokalab/work/octave/octave-4.0.0/build/libinterp/octave-value/ov-java.cc-tst
>>>>>>>>  
>>> ***** testif HAVE_JAVA
>  assert (javaMethod ("binarySearch", "java.util.Arrays", [90 100 255], 255), 
> 2);
>  assert (javaMethod ("binarySearch", "java.util.Arrays", uint8 ([90 100 
> 255]), uint8 (255)) < 0);
>  assert (javaMethod ("binarySearch", "java.util.Arrays", uint8 ([90 100 
> 128]), uint8 (128)) < 0);
>  assert (javaMethod ("binarySearch", "java.util.Arrays", uint8 ([90 100 
> 127]), uint8 (127)), 2);
>  assert (javaMethod ("binarySearch", "java.util.Arrays", uint16 ([90 100 
> 128]), uint16 (128)), 2);
> !!!!! test failed
> [java] java.lang.ClassCastException: java.lang.Double cannot be cast to 
> java.lang.Float I have used openjdk-7-jdk, openjdk-7-jre, openjdk-7-headless 
> (7u79-2.5.5-0ubuntu).
>> Tatsuro,
>>
>> Can you run each of the assert lines individually to see which one
>     fails?  
>
>>> assert (javaMethod ("binarySearch", "java.util.Arrays", [90 100 255], 255), 
>>> 2);
> error: [java] java.lang.ClassCastException: java.lang.Double cannot be cast 
> to java.lang.Float
> error: evaluating argument list element number 1
>>> assert (javaMethod ("binarySearch", "java.util.Arrays", uint8 ([90 100 
>>> 255]), uint8 (255)) < 0);
>>> assert (javaMethod ("binarySearch", "java.util.Arrays", uint8 ([90 100 
>>> 128]), uint8 (128)) < 0);
>>> assert (javaMethod ("binarySearch", "java.util.Arrays", uint8 ([90 100 
>>> 127]), uint8 (127)), 2);
>>> assert (javaMethod ("binarySearch", "java.util.Arrays", uint16 ([90 100 
>>> 128]),uint16 (128)), 2);
> The first line gives an error.
>
>> It's pretty hard to see why Ubuntu 14.04 would pass, but
>     Lubuntu 14.04 would fail.  One difference is that the first build is
>     64 bit, while the second is 32 bit.  Is it possible to install a
>     Lubuntu version that is 64 bit?
>
>  I found the thread which reports the same FAIL after I post this one.
>  
> http://octave.1599824.n4.nabble.com/Report-on-my-first-4-0-0-build-on-Ubuntu-14-10-32-bits-td4670563.html
>  
>   
>  Julien Bect uses Ubuntu 14.10 / 32 bits / gcc 4.9.1.
>
>   Perhaps this issue does not depend on whether ubuntu or lubuntu. It seems 
> to depend on whether 32 bit or 64 bit.

Yes, I saw that too.  I was going to wait on the results of your test and
then post to octave-maintainers, but you have beaten me to it.  I'm
convinced that the real issue is whether the JRE is 32-bit or 64-bit. 
Maybe as confirmation, does this work?

assert (javaMethod ("binarySearch", "java.util.Arrays", single ([90 100 255]), 
single (255)), 2);

This tries to keep everything in floats, rather than doubles, when calling
java.

--Rik





reply via email to

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