Octave 3.1.50 available for ftp

[John W. Eaton]

A new snapshot of Octave is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  2e7ffb7e79a7d9895136987e14ebebd0  octave-3.1.50.tar.bz2
  52ba9e6f736efbeb279945fc4d9eb069  octave-3.1.50.tar.gz

  -rw-r--r-- 1 506 1012 10699800 Jul 18 21:28 octave-3.1.50.tar.bz2
  -rw-r--r-- 1 506 1012 12264734 Jul 18 21:30 octave-3.1.50.tar.gz

The snapshot is tagged in the usual way (ss-3-1-50) in the Mercurial
archive and will be marked as the "development" version of
Octave on the download page of the Octave web site.

I didn't bother to make diffs from any previous version as they would
be quite large.

This snapshot includes the new experimental OpenGL-based graphics
code, but the gnuplot backend is used by default.  Assuming you have
all the required libraries and have built the OpenGL bits properly,
you should be able to switch to the new backend with the commands

  input_event_hook ("__fltk_redraw__");
  __init_fltk__ ();
  set (0, "defaultfigure__backend__", "fltk");

I'm sure there will be a simpler way to do this once the new backend
code is more mature.

jwe

[Bill Denney-5]

John W. Eaton wrote:

> A new snapshot of Octave is now available for ftp from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:
>
>   2e7ffb7e79a7d9895136987e14ebebd0  octave-3.1.50.tar.bz2
>   52ba9e6f736efbeb279945fc4d9eb069  octave-3.1.50.tar.gz
>
>   -rw-r--r-- 1 506 1012 10699800 Jul 18 21:28 octave-3.1.50.tar.bz2
>   -rw-r--r-- 1 506 1012 12264734 Jul 18 21:30 octave-3.1.50.tar.gz
>
> The snapshot is tagged in the usual way (ss-3-1-50) in the Mercurial
> archive and will be marked as the "development" version of
> Octave on the download page of the Octave web site.
>  

To the windows maintainers,

Might there be windows releases that track the development snapshots?

Have a good day,

Bill

[John W. Eaton]

On 18-Jul-2008, Bill Denney wrote:

| John W. Eaton wrote:
| > A new snapshot of Octave is now available for ftp from ftp.octave.org in the
| > directory /pub/octave/bleeding-edge:
| >
| >   2e7ffb7e79a7d9895136987e14ebebd0  octave-3.1.50.tar.bz2
| >   52ba9e6f736efbeb279945fc4d9eb069  octave-3.1.50.tar.gz
| >
| >   -rw-r--r-- 1 506 1012 10699800 Jul 18 21:28 octave-3.1.50.tar.bz2
| >   -rw-r--r-- 1 506 1012 12264734 Jul 18 21:30 octave-3.1.50.tar.gz
| >
| > The snapshot is tagged in the usual way (ss-3-1-50) in the Mercurial
| > archive and will be marked as the "development" version of
| > Octave on the download page of the Octave web site.
| >  
| To the windows maintainers,
|
| Might there be windows releases that track the development snapshots?

To the Windows users,

Might there be a few of you who would be interested in helping to
build those binary packages for Windows to take some of the load off
of the one(!) person doing that job now?

Thanks,

jwe

[Tatsuro MATSUOKA-2]

Hello

> To the Windows users,
>
> Might there be a few of you who would be interested in helping to
> build those binary packages for Windows to take some of the load off
> of the one(!) person doing that job now?
>
> Thanks,
>
> jwe
>

I have just downloaded s source tar.bz2 file.
I will try to build it on mingw platform now.

I will report the results the later whatever it will be successful or not.

Regards

--------------------------------------
Stop! Global Warming ~ Yahoo! JAPAN Earth Project
http://pr.mail.yahoo.co.jp/earthproject/

[Bill Denney-5]

Michael Goffioul wrote:

> On Sat, Jul 19, 2008 at 12:22 AM, Bill Denney <bill@...> wrote:
>  
>> To the windows maintainers,
>>
>> Might there be windows releases that track the development snapshots?
>>    
>
> I was planning to make a development binary package, but this
> may take a while, as our second baby is going to be born in the
> next couple of days.

Congratulations!  And, it's not a rush; I was curious if it was in the
plans or not.  If I can help, let me know how (for either Michael or
Tatsuro).

Have a good day,

Bill

[Rafael Laboissiere]

* John W. Eaton <jwe@...> [2008-07-18 17:44]:

> A new snapshot of Octave is now available for ftp from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:
>
> [snip]

Thanks a lot for this release.  The Debian package built fine.  Three tests
failed and the relevant excerpts of fntests.log are in the file attached
below.

The package has been uploaded to the experimental distribution and is
sitting now in the NEW queue waiting for ftp-admin approval [1].  I have
also put the package in a apt-getable repository [2].

[1] http://ftp-master.debian.org/new/octave3.1_3.1.50-1.html
[2] http://people.debian.org/~rafael/octave3.1/

--
Rafael

[snip]
>>>>> processing /home/rafael/devel/debian/PKGS/octave/octave-3.1.50/src/DLD-FUNCTIONS/dispatch.cc
  ***** test # replace base m-file
 echo_to_file ('function a=dispatch_x(a)', "dispatch_x.m");
 dispatch('dispatch_x','length','string')
 assert(dispatch_x(3),3)
 assert(dispatch_x("a"),1)
 sleep (2);
 echo_to_file ('function a=dispatch_x(a),++a;', "dispatch_x.m");
 rehash();
 assert(dispatch_x(3),4)
 assert(dispatch_x("a"),1)
!!!!! test failed
`dispatch_x' undefined near line 0 column 9
[snip]
>>>>> processing /home/rafael/devel/debian/PKGS/octave/octave-3.1.50/src/mappers.cc
  ***** assert(isna (single(NA)));
!!!!! test failed
assert (isna (single (NA))) failed
***** assert(isna(single([NaN -Inf -1 0 1 Inf NA])), [false, false, false, false, false, false, true]);
!!!!! test failed
assert (isna (single ([NaN, -Inf, -1, 0, 1, Inf, NA])),[false, false, false, false, false, false, true]) expected
   0   0   0   0   0   0   1
but got
   0   0   0   0   0   0   0
values do not match
[snip]

[John W. Eaton]

On 20-Jul-2008, Rafael Laboissiere wrote:

| * John W. Eaton <jwe@...> [2008-07-18 17:44]:
|
| > A new snapshot of Octave is now available for ftp from ftp.octave.org in the
| > directory /pub/octave/bleeding-edge:
| >
| > [snip]
|
| Thanks a lot for this release.

Again, I do not consider these snapshots to be "releases".  They are
simply meant for testing, for people who would rather not bother with
grabbing sources from the Mercurial archive at random times.

jwe

[Rafael Laboissiere]

* John W. Eaton <jwe@...> [2008-07-20 10:20]:

> On 20-Jul-2008, Rafael Laboissiere wrote:
>
> | * John W. Eaton <jwe@...> [2008-07-18 17:44]:
> |
> | > A new snapshot of Octave is now available for ftp from ftp.octave.org in the
> | > directory /pub/octave/bleeding-edge:
> | >
> | > [snip]
> |
> | Thanks a lot for this release.
>
> Again, I do not consider these snapshots to be "releases".
> [snip]

Okay, thanks a lot for this snapshot :-)

--
Rafael

[Dmitri A. Sergatskov]

On Fri, Jul 18, 2008 at 4:44 PM, John W. Eaton <jwe@...> wrote:

> This snapshot includes the new experimental OpenGL-based graphics
> code, but the gnuplot backend is used by default.  Assuming you have
> all the required libraries and have built the OpenGL bits properly,
> you should be able to switch to the new backend with the commands
>
>  input_event_hook ("__fltk_redraw__");
>  __init_fltk__ ();
>  set (0, "defaultfigure__backend__", "fltk");
>
> I'm sure there will be a simpler way to do this once the new backend
> code is more mature.
>
> jwe
>

octave:1> input_event_hook ("__fltk_redraw__");
octave:2> error: /home/dima/src/octave-3.1.50/src/fltk_backend.oct:
undefined symbol: _ZTV15opengl_renderer
terminate called after throwing an instance of 'octave_execution_exception'
panic: Aborted -- stopping myself...
Aborted

Do I need a special FLTK  - GL library? configure did not complain....

I have
mesa-libGL-devel-7.1-0.37.fc9.x86_64
and
fltk-devel-1.1.8-1.fc9.x86_64
fltk-1.1.8-1.fc9.x86_64

Any ideas?

Dmitri.
--

[Michael Goffioul-2]

On Sun, Jul 20, 2008 at 9:32 PM, Dmitri A. Sergatskov
<dasergatskov@...> wrote:
> octave:1> input_event_hook ("__fltk_redraw__");
> octave:2> error: /home/dima/src/octave-3.1.50/src/fltk_backend.oct:
> undefined symbol: _ZTV15opengl_renderer
> terminate called after throwing an instance of 'octave_execution_exception'
> panic: Aborted -- stopping myself...
> Aborted
>
> Do I need a special FLTK  - GL library? configure did not complain....

No. I think the problem is simply that the octave package does not
contain the source file gl-render.cc. However, you also need FTGL
and because of this missing dependency, the configure script just
didn't include the OpenGL renderer in the compilation.

Michael.

[Dmitri A. Sergatskov]

On Sun, Jul 20, 2008 at 2:43 PM, Michael Goffioul
<michael.goffioul@...> wrote:

> On Sun, Jul 20, 2008 at 9:32 PM, Dmitri A. Sergatskov
> <dasergatskov@...> wrote:
>> octave:1> input_event_hook ("__fltk_redraw__");
>> octave:2> error: /home/dima/src/octave-3.1.50/src/fltk_backend.oct:
>> undefined symbol: _ZTV15opengl_renderer
>> terminate called after throwing an instance of 'octave_execution_exception'
>> panic: Aborted -- stopping myself...
>> Aborted
>>
>> Do I need a special FLTK  - GL library? configure did not complain....
>
> No. I think the problem is simply that the octave package does not
> contain the source file gl-render.cc. However, you also need FTGL
> and because of this missing dependency, the configure script just
> didn't include the OpenGL renderer in the compilation.

I do have FTGL, but I noticed that configure cannot find OpenGL libraries.
Here is config.log

configure:10698: checking for GL/gl.h
configure:10722: gcc -c -g -O2   conftest.c >&5
configure:10728: $? = 0
configure:10744: result: yes
configure:10756: checking for GL/glu.h
configure:10780: gcc -c -g -O2   conftest.c >&5
configure:10786: $? = 0
configure:10802: result: yes
configure:10698: checking for OpenGL/gl.h
configure:10722: gcc -c -g -O2   conftest.c >&5
conftest.c:46:23: error: OpenGL/gl.h: No such file or directory
configure:10728: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define OCTAVE_SOURCE 1
| #define _GNU_SOURCE 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define SEPCHAR ':'
| #define SEPCHAR_STR ":"
| #define __NO_MATH_INLINES 1
| #define CXX_NEW_FRIEND_TEMPLATE_DECL 1
| #define CXX_ISO_COMPLIANT_LIBRARY 1
| #define CXX_ABI gnu_v3
| #define HAVE_LIBM 1
| #define HAVE_QHULL 1
| #define HAVE_PCRE 1
| #define HAVE_REGEXEC 1
| #define HAVE_REGEX 1
| #define HAVE_ZLIB_H 1
| #define HAVE_ZLIB 1
| #define HAVE_FFTW3 1
| #define HAVE_GLPK_GLPK_H 1
| #define HAVE_GLPK 1
| #define HAVE_CURL_CURL_H 1
| #define HAVE_CURL 1
| #define HAVE_MAGICK 1
| #define HAVE_GL_GL_H 1
| #define HAVE_GL_GLU_H 1
| /* end confdefs.h.  */
|
| #ifdef HAVE_WINDOWS_H
| # include <windows.h>
| #endif
|
| #include <OpenGL/gl.h>
configure:10744: result: no
....

And the output of configure:

Octave is now configured for x86_64-unknown-linux-gnu

  Source directory:     .
  Installation prefix:  /usr/local
  C compiler:           gcc   -Wall -W -Wshadow -g -O2
  C++ compiler:         g++   -Wall -W -Wshadow -Wold-style-cast -g -O2
  Fortran compiler:     gfortran -O
  Fortran libraries:     -L/usr/lib/gcc/x86_64-redhat-linux/4.3.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../.. -lz -lgfortranbegin
-lgfortran -lm
  BLAS libraries:       -llapack -lblas
  FFTW libraries:       -lfftw3 -lfftw3f
  GLPK libraries:       -lglpk
  UMFPACK libraries:    -lumfpack
  AMD libraries:        -lamd
  CAMD libraries:       -lcamd
  COLAMD libraries:     -lcolamd
  CCOLAMD libraries:    -lccolamd
  CHOLMOD libraries:    -lcholmod
  CXSPARSE libraries:   -lcxsparse
  HDF5 libraries:
  CURL libraries:       -lcurl
  REGEX libraries:      -lpcre
  QHULL libraries: -lqhull
  LIBS:                 -lreadline  -lncurses -ldl -lblas -lz -lm
  Default pager:        less
  gnuplot:              gnuplot
  OPENGL libraries:
  FLTK backend libs:    -L/usr/lib64 -lfltk_gl -lGLU -lGL -lfltk
  Magick config:        GraphicsMagick++-config

  Do internal array bounds checking:  false
  Build static libraries:             false
  Build shared libraries:             true
  Dynamic Linking:                    true (dlopen)
  Include support for GNU readline:   true
  64-bit array dims and indexing:     false


>
> Michael.
>

Dmitri.
--

[John W. Eaton]

On 20-Jul-2008, Dmitri A. Sergatskov wrote:

| On Sun, Jul 20, 2008 at 2:43 PM, Michael Goffioul
| <michael.goffioul@...> wrote:
| > On Sun, Jul 20, 2008 at 9:32 PM, Dmitri A. Sergatskov
| > <dasergatskov@...> wrote:
| >> octave:1> input_event_hook ("__fltk_redraw__");
| >> octave:2> error: /home/dima/src/octave-3.1.50/src/fltk_backend.oct:
| >> undefined symbol: _ZTV15opengl_renderer
| >> terminate called after throwing an instance of 'octave_execution_exception'
| >> panic: Aborted -- stopping myself...
| >> Aborted
| >>
| >> Do I need a special FLTK  - GL library? configure did not complain....
| >
| > No. I think the problem is simply that the octave package does not
| > contain the source file gl-render.cc. However, you also need FTGL
| > and because of this missing dependency, the configure script just
| > didn't include the OpenGL renderer in the compilation.
|
| I do have FTGL, but I noticed that configure cannot find OpenGL libraries.
| Here is config.log

I think this problem is fixed in my Mercurial archive now, so it
should be fixed in the 3.1.51 snapshot.

jwe

[Michael Goffioul-2]

On Mon, Jul 21, 2008 at 5:52 PM, John W. Eaton <jwe@...> wrote:
> I think this problem is fixed in my Mercurial archive now, so it
> should be fixed in the 3.1.51 snapshot.

Does the FTGLTextureFont test work for you? On my system with
ftgl-2.12, ftgl.h does not include FTGLTextureFont.h (ftgl-2.13 does
include it).

Michael.

[John W. Eaton]

On 21-Jul-2008, Michael Goffioul wrote:

| On Mon, Jul 21, 2008 at 5:52 PM, John W. Eaton <jwe@...> wrote:
| > I think this problem is fixed in my Mercurial archive now, so it
| > should be fixed in the 3.1.51 snapshot.
|
| Does the FTGLTextureFont test work for you? On my system with
| ftgl-2.12, ftgl.h does not include FTGLTextureFont.h (ftgl-2.13 does
| include it).

The ftgl.h header from FTGL 2.1.3 includes FTGL/FTGLTextureFont.h.

So I guess we need a change like the attached?  Will this fail on a
system with case-insensitive filenames?  Does it need to be more
complex, or should we just require FTGL 2.1.3 once it is officially
released?

jwe


# HG changeset patch
# User John W. Eaton <jwe@...>
# Date 1216668442 14400
# Node ID 9939bb6332a395818b081b79c5d8a9207757c826
# Parent  ba2e00a216e8baadd7e26be233813c4034611b15
FTGL configure test fix

diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
[phone]  John W. Eaton  <jwe@...>
+
+ * configure.in: If FTGL.h is found, then also include
+ FTGLTextureFont.h in test code.
+
 2008-07-21  Michael Goffioul  <michael.goffioul@...>
 
  * configure.in: Remove GRAPHICS_OPENGL variable.
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -677,12 +677,14 @@
 #ifdef HAVE_FTGL_FTGL_H
 #ifdef HAVE_FTGL_UPPERCASE
 #include <FTGL/FTGL.h>
+#include <FTGL/FTGLTextureFont.h>
 #else
 #include <FTGL/ftgl.h>
 #endif
 #elif HAVE_FTGL_H
 #ifdef HAVE_FTGL_UPPERCASE
 #include <FTGL.h>
+#include <FTGLTextureFont.h>
 #else
 #include <ftgl.h>
 #endif

[Michael Goffioul-2]

On Mon, Jul 21, 2008 at 9:28 PM, John W. Eaton <jwe@...> wrote:
> The ftgl.h header from FTGL 2.1.3 includes FTGL/FTGLTextureFont.h.
>
> So I guess we need a change like the attached?

Yes.

> Will this fail on a
> system with case-insensitive filenames?  Does it need to be more
> complex, or should we just require FTGL 2.1.3 once it is officially
> released?

I think it's enough like that. This covers 2.1.2 and 2.1.3.

Michael.

[dbateman]

Rafael Laboissiere wrote:

Thanks a lot for this release.  The Debian package built fine.  Three tests
failed and the relevant excerpts of fntests.log are in the file attached
below.

i don't know about the dispatch failure, but the isna failure is due to the issue of single to double conversion. I've sent a few e-mails to the R mailing as Octave chose the NA value for compatiility with R, but without response. I'll send an e-mail about this in the next few days to the maintainers list.

D.