3.2.0 release candidate 5

[Jaroslav Hajek-2]

hi,

the Octave 3.2.0 RC5 tarballs are available at
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

changes since rc4:

changeset:   9273:61abb94f46f4
user:        John W. Eaton <jwe@...>
date:        Wed May 27 06:21:36 2009 -0400
summary:     fix imshow demos

changeset:   9274:6e519bd01615
user:        Jaroslav Hajek <highegg@...>
date:        Wed May 27 15:28:50 2009 +0200
summary:     Fix RGB color construction in __magick_read__.cc

changeset:   9275:86f475d5e7d1
user:        John W. Eaton <jwe@...>
date:        Wed May 27 10:34:59 2009 -0400
summary:     imwrite.m: convert indexed images to RGB before calling
__magick_write__

changeset:   9276:f5e4b5fd1f1e
user:        Rik <rdrider0-list@...>
date:        Wed May 27 10:56:41 2009 -0700
summary:     Update ismember examples to remove incorrect reference to
residue function

changeset:   9277:be84e9654feb
user:        Rik <rdrider0-list@...>
date:        Wed May 27 13:06:38 2009 -0700
summary:     Update axis.m documentation to reflect addition of "tight" option.

changeset:   9278:2b35cb600d50
user:        Radek Salac <salac.r@...>
date:        Thu May 28 07:03:11 2009 +0200
summary:     improve bicgstab and cgs

changeset:   9279:1673a0dc019f
user:        Jaroslav Hajek <highegg@...>
date:        Thu May 28 07:37:13 2009 +0200
summary:     fix & improve preconditioning strategy in cgs & bicgstab

changeset:   9280:40fb718a2e67
user:        Ben Abbott <bpabbott@...>
date:        Thu May 28 03:10:41 2009 -0400
summary:     __go_draw_axes__.m: Add support for ticklabel separator '|'.

changeset:   9281:02b16eeb3167
user:        Ben Abbott <bpabbott@...>
date:        Thu May 28 06:21:01 2009 -0400
summary:     Fix yticklabels for log scale colorbar.

changeset:   9282:2ed8d2d92507
user:        John W. Eaton <jwe@...>
date:        Thu May 28 07:22:59 2009 -0400
summary:     load_path::do_files: avoid shadow warning from GCC

changeset:   9283:38ad8c99d6a2
user:        John W. Eaton <jwe@...>
date:        Fri May 29 17:32:08 2009 -0400
summary:     __gnuplot_get_var__.m: insert missing semicolon

changeset:   9284:567e3e4ab74d
user:        Robert T. Short <octave@...>
date:        Sun May 31 21:11:31 2009 -0700
summary:     fix up examples/@polynomial

changeset:   9285:226f6d001ee2
user:        Jaroslav Hajek <highegg@...>
date:        Tue Jun 02 09:06:49 2009 +0200
summary:     further improve the polynomial example, fix indexing

changeset:   9286:c2248cc4821a
tag:         qparent
tag:         3-2-0-rc5
user:        Jaroslav Hajek <highegg@...>
date:        Tue Jun 02 09:57:44 2009 +0200
summary:     don't crash on assignments like a() = 1


enjoy! (and build... and report success... :)


--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[Rik555]

6/2/09

RC5 builds fine on Ubuntu Hardy Heron (8.04, i386).

'make check' almost passes.

Summary:

  PASS   5577
  FAIL      1


The one failure is the one previously discussed for polyfit.m.

--Rik

[Julian Schnidder-3]

2009/6/2 Jaroslav Hajek <highegg@...>:
> hi,
>
> the Octave 3.2.0 RC5 tarballs are available at
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> [...]
>
> enjoy! (and build... and report success... :)

Builds fine on Ubuntu 9.04 (with reference lapack and blas libraries,
i.e. no atlas).

The scaling test in polyfit.m fails (was ok in 3.1.55)
scripts/polynomial/polyfit.m ........................... PASS    8/9    FAIL 1

More precisely
>>>>> processing /usr/local/src/octave-3.2.0/scripts/polynomial/polyfit.m
  ***** test
 x = [ -1196.4, -1195.2, -1194, -1192.8, -1191.6, -1190.4, -1189.2, -1188, \
       -1186.8, -1185.6, -1184.4, -1183.2, -1182];
 y = [ 315571.7086, 315575.9618, 315579.4195, 315582.6206, 315585.4966,    \
       315588.3172, 315590.9326, 315593.5934, 315596.0455, 315598.4201,    \
       315600.7143, 315602.9508, 315605.1765 ];
 [p1, s1] = polyfit (x, y, 10);
 [p2, s2, mu] = polyfit (x, y, 10);
 assert (2*s2.normr < s1.normr)
!!!!! test failed
assert (2 * s2.normr < s1.normr) failed>>>>> processing
/usr/local/src/octave-3.2.0/scripts/polynomial/polyreduce.m

But I don't know how to fix it.

Kind regards,
Julian

PS: Thanks for your efforts. I am looking forward to the new octave release.

[Jean-Francois Cardoso]

Hello Jaroslav,

I have problem building all 3.2.0 release candidates.
The configure script does not detect properly the
BLAS libraries.  This is happening on two machines of mine:

1) on my MacBook where ./configure spills out:

[...]
checking whether DDOT is called correctly from Fortran... yes
checking whether CDOTU is called correctly from Fortran... no
checking whether ZDOTU is called correctly from Fortran... yes
configure: WARNING: A BLAS library was detected but found incompatible with your Fortran 77 compiler.  
[...]

2) on a Linux/Intel machine when I try to link with Intel's MKL.

Again, BLAS detection fails on CDOTU.


On both machines, I am able to compile successfully the 3.0.xx series,
that is with proper detection of the local multithreaded BLAS libraries.

Cheers, JF

[Robert T. Short]

Jaroslav,

The changes you made are better than mine, but also broke the end
method.  Fix attached.

Thanks.

Bob


# HG changeset patch
# User Robert T. Short <rtshort@...>
# Date 1244001379 25200
# Node ID 74e09577d4ab537364c2b5ef6b625fc440b7811d
# Parent  56ce6a69836fca989f7022ffac3fd9a27d91824e
  * examples/@polynomial/end.m: Fixe end for zero based indexing.

diff -r 56ce6a69836f -r 74e09577d4ab ChangeLog
--- a/ChangeLog Tue Jun 02 16:57:22 2009 -0700
+++ b/ChangeLog Tue Jun 02 20:56:19 2009 -0700
@@ -1,3 +1,7 @@
[phone]  Robert T. Short  <octave@...>
+
+ * examples/@polynomial: Fix end method for zero based indexing.
+
 2009-06-02  Jaroslav Hajek  <highegg@...>
 
  * examples/@polynomial/subsref.m: Allow chained subscripts,
diff -r 56ce6a69836f -r 74e09577d4ab examples/@polynomial/end.m
--- a/examples/@polynomial/end.m Tue Jun 02 16:57:22 2009 -0700
+++ b/examples/@polynomial/end.m Tue Jun 02 20:56:19 2009 -0700
@@ -4,6 +4,6 @@
     error ("polynomial object may only have one index")
   endif
   
-  r = length (obj.poly);
+  r = length (obj.poly) - 1;
 
 endfunction

[Jaroslav Hajek-2]

On Wed, Jun 3, 2009 at 5:59 AM, Robert T. Short
<octave@...> wrote:

> Jaroslav,
>
> The changes you made are better than mine, but also broke the end method.
>  Fix attached.
>
> Thanks.
>
> Bob
>
>
> # HG changeset patch
> # User Robert T. Short <rtshort@...>
> # Date 1244001379 25200
> # Node ID 74e09577d4ab537364c2b5ef6b625fc440b7811d
> # Parent  56ce6a69836fca989f7022ffac3fd9a27d91824e
>  * examples/@polynomial/end.m: Fixe end for zero based indexing.
>
> diff -r 56ce6a69836f -r 74e09577d4ab ChangeLog
> --- a/ChangeLog Tue Jun 02 16:57:22 2009 -0700
> +++ b/ChangeLog Tue Jun 02 20:56:19 2009 -0700
> @@ -1,3 +1,7 @@
> [phone]  Robert T. Short  <octave@...>
> +
> +       * examples/@polynomial: Fix end method for zero based indexing.
> +
>  2009-06-02  Jaroslav Hajek  <highegg@...>
>
>        * examples/@polynomial/subsref.m: Allow chained subscripts,
> diff -r 56ce6a69836f -r 74e09577d4ab examples/@polynomial/end.m
> --- a/examples/@polynomial/end.m        Tue Jun 02 16:57:22 2009 -0700
> +++ b/examples/@polynomial/end.m        Tue Jun 02 20:56:19 2009 -0700
> @@ -4,6 +4,6 @@
>     error ("polynomial object may only have one index")
>   endif
>
> -  r = length (obj.poly);
> +  r = length (obj.poly) - 1;
>
>  endfunction
>
>

Ah, yes, sorry. I shot myself in the foot. Thanks for catching this. Applied.


--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[Jaroslav Hajek-2]

On Tue, Jun 2, 2009 at 10:30 PM, Jean-Francois Cardoso <cardoso@...> wrote:

>
> Hello Jaroslav,
>
> I have problem building all 3.2.0 release candidates.
> The configure script does not detect properly the
> BLAS libraries.  This is happening on two machines of mine:
>
> 1) on my MacBook where ./configure spills out:
>
> [...]
> checking whether DDOT is called correctly from Fortran... yes
> checking whether CDOTU is called correctly from Fortran... no
> checking whether ZDOTU is called correctly from Fortran... yes
> configure: WARNING: A BLAS library was detected but found incompatible with
> your Fortran 77 compiler.
> [...]
>
> 2) on a Linux/Intel machine when I try to link with Intel's MKL.
>
> Again, BLAS detection fails on CDOTU.
>
>
> On both machines, I am able to compile successfully the 3.0.xx series,
> that is with proper detection of the local multithreaded BLAS libraries.
>
> Cheers, JF

This is most likely happening if your Fortran compiler uses a calling
convention incompatible to your BLAS/LAPACK.
For instance, if you try to use gfortran + g77-compiled BLAS or vice
versa. Such an incompatibility can cause mysterious problems, that's
why this check was added.
If you're sure this is not the case, then please supply your config.log.

regards

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[Rob Mahurin]

On Jun 2, 2009, at 4:30 PM, Jean-Francois Cardoso wrote:

> Hello Jaroslav,
>
> I have problem building all 3.2.0 release candidates.
> The configure script does not detect properly the
> BLAS libraries.  This is happening on two machines of mine:
>
> 1) on my MacBook where ./configure spills out:
>
> [...]
> checking whether DDOT is called correctly from Fortran... yes
> checking whether CDOTU is called correctly from Fortran... no
> checking whether ZDOTU is called correctly from Fortran... yes
> configure: WARNING: A BLAS library was detected but found  
> incompatible with
> your Fortran 77 compiler.
> [...]

I had this problem while using the compiler "g95" that shipped with  
OSX 10.5.7.  I got around it by installing gcc44 from macports and  
calling configure with

        ./configure LDFLAGS=-L/opt/local/lib LIBS=-lmetis \
        FFLAGS=-ff2c F77=gfortran-mp-4.4 \
        CC=gcc-mp-4.4 CXX=g++-mp-4.4

>

You seem to be doing something more complicated than I am with BLAS  
libraries, but hopefully this helps anyway.

Cheers,
Rob

--
Rob Mahurin
Department of Physics and Astronomy
University of Tennessee 865 207 2594
Knoxville, TN 37996 rob@...

[Jean-Francois Cardoso]

Rob Mahurin wrote:

On Jun 2, 2009, at 4:30 PM, Jean-Francois Cardoso wrote:
> Hello Jaroslav,
>
> I have problem building all 3.2.0 release candidates.
> The configure script does not detect properly the
> BLAS libraries.  This is happening on two machines of mine:
>
> 1) on my MacBook where ./configure spills out:
>
> [...]
> checking whether DDOT is called correctly from Fortran... yes
> checking whether CDOTU is called correctly from Fortran... no
> checking whether ZDOTU is called correctly from Fortran... yes
> configure: WARNING: A BLAS library was detected but found  
> incompatible with
> your Fortran 77 compiler.
> [...]

I had this problem while using the compiler "g95" that shipped with  
OSX 10.5.7.  I got around it by installing gcc44 from macports and  
calling configure with

        ./configure LDFLAGS=-L/opt/local/lib LIBS=-lmetis \
        FFLAGS=-ff2c F77=gfortran-mp-4.4 \
        CC=gcc-mp-4.4 CXX=g++-mp-4.4

>

You seem to be doing something more complicated than I am with BLAS  
libraries, but hopefully this helps anyway.

Thanks for your reply.  Indeed, the BLAS detection problem is solved
by adding the ff2c switch.   This works on both MacOSX
and on a Linux+MKL system.  No test failures on Linux+MKL
but several on MacOSX, which I will report separately.
I am wondering if the ff2c switch induces some loss
of efficiency.  If not, why is it not "on" by default; if yes,
any idea about the possible loss ?  (this is out of curiosity).

Thanks again, JF

[Jean-Francois Cardoso]

Jaroslav Hajek-2 wrote:

On Tue, Jun 2, 2009 at 10:30 PM, Jean-Francois Cardoso <[e-mail]> wrote:
>
> Hello Jaroslav,
>
> I have problem building all 3.2.0 release candidates.
> The configure script does not detect properly the
> BLAS libraries.  This is happening on two machines of mine:
>
> 1) on my MacBook where ./configure spills out:
>
> [...]
> checking whether DDOT is called correctly from Fortran... yes
> checking whether CDOTU is called correctly from Fortran... no
> checking whether ZDOTU is called correctly from Fortran... yes
> configure: WARNING: A BLAS library was detected but found incompatible with
> your Fortran 77 compiler.
> [...]
>
> 2) on a Linux/Intel machine when I try to link with Intel's MKL.
>
> Again, BLAS detection fails on CDOTU.
>
>
> On both machines, I am able to compile successfully the 3.0.xx series,
> that is with proper detection of the local multithreaded BLAS libraries.
>
> Cheers, JF

This is most likely happening if your Fortran compiler uses a calling
convention incompatible to your BLAS/LAPACK.
For instance, if you try to use gfortran + g77-compiled BLAS or vice
versa. Such an incompatibility can cause mysterious problems, that's
why this check was added.
If you're sure this is not the case, then please supply your config.log.

Thanks for your reply.
The blas detection problem is solved by adding a -ff2c switch.
I have unfortunately no idea how my libraries are compiled.
On Linux, I try to link to a prebuilt MKL library.
On MacOSX, I try to link to the native BLAS (Veclib, in Mac speech).
On both systems, I had no problems with octave 3.0.xx.
Now, with ff2c, Linux+MKL seems to work fine.  However,
on MacOSX, the build completes but there are several test failures
which appear in sections unrelated to the BLAS.  Those are:

  src/ov-struct.cc ....................................... PASS    9/16   FAIL 7
  src/pt-idx.cc .......................................... PASS    3/5    FAIL 2
  scripts/miscellaneous/getfield.m ....................... PASS    1/2    FAIL 1
  scripts/miscellaneous/orderfields.m .................... PASS    0/5    FAIL 5
  scripts/miscellaneous/setfield.m ....................... PASS    1/2    FAIL 1
  test_struct.m .......................................... PASS   38/44   FAIL 6

The build script is as follows:
================================
export CPPFLAGS="-I/usr/local/include/readline"
export LDFLAGS="-L/usr/local/lib"
export FFLAGS="-ff2c" ; ## for octave 3.2.0
###   Where has gcc_select gone ?
export CC=gcc-4.2
export CPP=cpp-4.2
export CXX=g++-4.2
export CXXCPP=cpp-4.2 ##  
./configure
make -j2
================================
The fortran compiler is gfortran 4.4.0
All libraries are native (except a locally compiled readline)
to an uptodate OSX 10.5.7 system.

Let me know if I can help by providing (portions of) log files
for the above test failures (I am reluctant to post
fntests.log or config.log which are large files).

Cheers, JF

[John W. Eaton-3]

On  3-Jun-2009, Jean-Francois Cardoso wrote:

| The blas detection problem is solved by adding a -ff2c switch.
| I have unfortunately no idea how my libraries are compiled.

Probably in a way that is compatible with f2c, but not with the new
gfortran calling convention.  I think that's what the configure test
is trying to tell you.

| On Linux, I try to link to a prebuilt MKL library.
| On MacOSX, I try to link to the native BLAS (Veclib, in Mac speech).
| On both systems, I had no problems with octave 3.0.xx.

Things change, and in any case, just because there wasn't a configure
test failure in the past doesn't mean that things were working 100%
correctly for you then if you happened to be using a Fortran compiler
that used a different calling convention than the libraries that you
were linking with...

| Let me know if I can help by providing (portions of) log files
| for the above test failures (I am reluctant to post
| fntests.log or config.log which are large files).

Posting the parts that fail for you might help, but unless someone
else can reproduce the problems you are seeing, simpply seeing the log
of the test failures is unlikely to help much.  If you are the only
person seeing the failures, you will probably have to do some
debugging yourself.

jwe

[Jaroslav Hajek-2]

On Thu, Jun 4, 2009 at 12:38 AM, Jean-Francois Cardoso <cardoso@...> wrote:

>
>
> Jaroslav Hajek-2 wrote:
>>
>> On Tue, Jun 2, 2009 at 10:30 PM, Jean-Francois Cardoso <cardoso@...>
>> wrote:
>>>
>>> Hello Jaroslav,
>>>
>>> I have problem building all 3.2.0 release candidates.
>>> The configure script does not detect properly the
>>> BLAS libraries.  This is happening on two machines of mine:
>>>
>>> 1) on my MacBook where ./configure spills out:
>>>
>>> [...]
>>> checking whether DDOT is called correctly from Fortran... yes
>>> checking whether CDOTU is called correctly from Fortran... no
>>> checking whether ZDOTU is called correctly from Fortran... yes
>>> configure: WARNING: A BLAS library was detected but found incompatible
>>> with
>>> your Fortran 77 compiler.
>>> [...]
>>>
>>> 2) on a Linux/Intel machine when I try to link with Intel's MKL.
>>>
>>> Again, BLAS detection fails on CDOTU.
>>>
>>>
>>> On both machines, I am able to compile successfully the 3.0.xx series,
>>> that is with proper detection of the local multithreaded BLAS libraries.
>>>
>>> Cheers, JF
>>
>> This is most likely happening if your Fortran compiler uses a calling
>> convention incompatible to your BLAS/LAPACK.
>> For instance, if you try to use gfortran + g77-compiled BLAS or vice
>> versa. Such an incompatibility can cause mysterious problems, that's
>> why this check was added.
>> If you're sure this is not the case, then please supply your config.log.
>>
>>
>
> Thanks for your reply.
> The blas detection problem is solved by adding a -ff2c switch.

It's obvious, then. Your BLAS is f2c-compatible (for g77 or older compilers).

> I have unfortunately no idea how my libraries are compiled.

You can usually tell by dumping out the dynamic dependencies of the
library. For instance, libgfortran is gfortran, libg2c is g77, libf2c
is f2c, etc.

> On Linux, I try to link to a prebuilt MKL library.

MKL comes in a number of flavors for most major compilers, including
gfortran. If you pick a compatible one, you won't need the switch.
IIRC, the ifort (native) version is also compatible with gfortran, but
you need to link in the ifort rtl explicitly.

> On MacOSX, I try to link to the native BLAS (Veclib, in Mac speech).
> On both systems, I had no problems with octave 3.0.xx.

In fact, the problems were identical, 3.0.x was just ignoring them.
Also, in some key places calls, 3.0.x was bypassing BLAS to avoid the
problems. Otherwise, things were mostly working, except mysterious
crashes when installing certain packages. 3.2.x does no longer bypass
the BLAS, so it simply wouldn't work OK with the incompatible
configuration. That's why configure provides no option to suppress
this test.
It's your configuration that is wrong, Octave is just detecting it.
BLAS and LAPACK are Fortran libraries (or at least
Fortran-compatible), and if they come pre-installed with the system,
they should be compatible with the system's Fortran compiler.

> Now, with ff2c, Linux+MKL seems to work fine.  However,
> on MacOSX, the build completes but there are several test failures
> which appear in sections unrelated to the BLAS.  Those are:
>
>  src/ov-struct.cc ....................................... PASS    9/16
> FAIL 7
>  src/pt-idx.cc .......................................... PASS    3/5
> FAIL 2
>  scripts/miscellaneous/getfield.m ....................... PASS    1/2
> FAIL 1
>  scripts/miscellaneous/orderfields.m .................... PASS    0/5
> FAIL 5
>  scripts/miscellaneous/setfield.m ....................... PASS    1/2
> FAIL 1
>  test_struct.m .......................................... PASS   38/44
> FAIL 6
>
> The build script is as follows:
> ================================
> export CPPFLAGS="-I/usr/local/include/readline"
> export LDFLAGS="-L/usr/local/lib"
> export FFLAGS="-ff2c" ; ## for octave 3.2.0
> ###   Where has gcc_select gone ?
> export CC=gcc-4.2
> export CPP=cpp-4.2
> export CXX=g++-4.2
> export CXXCPP=cpp-4.2 ##
> ./configure
> make -j2
> ================================
> The fortran compiler is gfortran 4.4.0
> All libraries are native (except a locally compiled readline)
> to an uptodate OSX 10.5.7 system.
>
> Let me know if I can help by providing (portions of) log files
> for the above test failures (I am reluctant to post
> fntests.log or config.log which are large files).
>
> Cheers, JF
>

Well you can maybe upload them somewhere and post a link? In any case,
if you use "test verbose", Octave will dump the code blocks that are
failing, so that you can quickly isolate a failing testcase.

regards

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz