Octave 2.1.37 available for ftp

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Octave 2.1.37 available for ftp

John W. Eaton-6
Octave 2.1.37 is now available for ftp from ftp.octave.org in the
directory /pub/octave/bleeding-edge:

  -rw-r--r--  1 ftpadm   ftp   4858297 Oct 23 13:29 octave-2.1.37.tar.gz
  -rw-r--r--  1 ftpadm   ftp   3802708 Oct 23 13:29 octave-2.1.37.tar.bz2

There are no diffs this time because they are quite large.

If your favorite bug is still not fixed, please let me know about it.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Etienne Grossmann-4

  Hello,

I have just installed 2.1.37, but compilation of octave-forge ends
with :

======================================================================
mkoctfile -DHAVE_OCTAVE_21 -v fsolve.cc
g++ -c -fPIC -I/usr/local/include/octave-2.1.37 -I/usr/local/include/octave-2.1.37/octave -I/usr/local/include -mieee-fp -fno-implicit-templates -g -O2 -Wall -DHAVE_OCTAVE_21 fsolve.cc -o fsolve.o
fsolve.cc: In function `class octave_value_list Ffsolve(const octave_value_list &, int)':
fsolve.cc:211: no matching function for call to `NLEqn::set_options (NLEqn_options &)'
make[1]: *** [fsolve.oct] Error 1
make[1]: Leaving directory `/home/cdisk/etienne/prog/octave/octave-forge/octave-forge/FIXES'
make: *** [FIXES/] Error 2
======================================================================

  I would like to check whether the backward compatibility problem
with is_XXX() still exists, and if it does, transform all relevant
sourceforge files.

  Since this is a big step, I guess the procedure is transform, test
and send a patch for people to check, and then commit?

  Cheers,

  Etienne

On Wed, Oct 23, 2002 at 02:30:50PM -0500, John W. Eaton wrote:
# Octave 2.1.37 is now available for ftp from ftp.octave.org in the
# directory /pub/octave/bleeding-edge:
#
#   -rw-r--r--  1 ftpadm   ftp   4858297 Oct 23 13:29 octave-2.1.37.tar.gz
#   -rw-r--r--  1 ftpadm   ftp   3802708 Oct 23 13:29 octave-2.1.37.tar.bz2
#
# There are no diffs this time because they are quite large.
#
# If your favorite bug is still not fixed, please let me know about it.
#
# Thanks,
#
# jwe
#
#
#

--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

John W. Eaton-6
On 23-Oct-2002, Etienne Grossmann <[hidden email]> wrote:

| I have just installed 2.1.37, but compilation of octave-forge ends
| with :
|
| ======================================================================
| mkoctfile -DHAVE_OCTAVE_21 -v fsolve.cc
| g++ -c -fPIC -I/usr/local/include/octave-2.1.37 -I/usr/local/include/octave-2.1.37/octave -I/usr/local/include -mieee-fp -fno-implicit-templates -g -O2 -Wall -DHAVE_OCTAVE_21 fsolve.cc -o fsolve.o
| fsolve.cc: In function `class octave_value_list Ffsolve(const octave_value_list &, int)':
| fsolve.cc:211: no matching function for call to `NLEqn::set_options (NLEqn_options &)'
| make[1]: *** [fsolve.oct] Error 1
| make[1]: Leaving directory `/home/cdisk/etienne/prog/octave/octave-forge/octave-forge/FIXES'
| make: *** [FIXES/] Error 2
| ======================================================================

Change "set_options" to "copy" or try the follwoing patch for Octave.

Thanks,

jwe


2002-10-23  John W. Eaton  <[hidden email]>

        * mk-opts.pl (emit_opt_class_header): Make set_options another
        name for copy.


Index: mk-opts.pl
===================================================================
RCS file: /usr/local/cvsroot/octave/mk-opts.pl,v
retrieving revision 1.8
diff -u -r1.8 mk-opts.pl
--- mk-opts.pl 17 Aug 2002 02:18:18 -0000 1.8
+++ mk-opts.pl 23 Oct 2002 22:01:57 -0000
@@ -406,6 +406,11 @@
   print "      reset = opt.reset;
     }\n";
 
+  ## For backward compatibility and because set_options is probably
+  ## a better name in some contexts:
+
+  print "\n  void set_options (const ${class_name}& opt) { copy (opt); }\n";
+
   print "\n  void set_default_options (void) { init (); }\n";
 
   for ($i = 0; $i < $opt_num; $i++)


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Dirk Eddelbuettel
In reply to this post by John W. Eaton-6

Thanks -- I am currently uploading 2.1.37, incl the small mkopt.pl patch, to
Debian.  

But even with the patch, building octave-forge fails:

/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.37
-I/usr/include/octave-2.1.37/octave -I/usr/include -mieee-fp
-fno-implicit-templates -O2 -DHAVE_OCTAVE_21 getfield.cc -o getfield.o
getfield.cc: In function class octave_value_list Fgetfield(const
octave_value_list &, int)':
getfield.cc:40: no matching function for call to
octave_value::do_struct_elt_index_op (string &, bool)'
make[3]: *** [getfield.oct] Error 1
make[3]: Leaving directory
/home/edd/src/debian/octave-forge-2002.05.09/main/struct'
make[2]: *** [struct/] Error 2
make[2]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main'
make[1]: *** [main/] Error 2
make[1]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09'
make: *** [build-stamp] Error 2

This is using the 2002.05.09 release of octave-forge. Is there something I
need from CVS to deal with this?

Thanks, Dirk

--
Good judgement comes from experience; experience comes from bad judgement.
                                                            -- Fred Brooks


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

John W. Eaton-6
On 23-Oct-2002, Dirk Eddelbuettel <[hidden email]> wrote:

| Thanks -- I am currently uploading 2.1.37, incl the small mkopt.pl patch, to
| Debian.  
|
| But even with the patch, building octave-forge fails:
|
| /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.37
| -I/usr/include/octave-2.1.37/octave -I/usr/include -mieee-fp
| -fno-implicit-templates -O2 -DHAVE_OCTAVE_21 getfield.cc -o getfield.o
| getfield.cc: In function class octave_value_list Fgetfield(const
| octave_value_list &, int)':
| getfield.cc:40: no matching function for call to
| octave_value::do_struct_elt_index_op (string &, bool)'
| make[3]: *** [getfield.oct] Error 1
| make[3]: Leaving directory
| /home/edd/src/debian/octave-forge-2002.05.09/main/struct'
| make[2]: *** [struct/] Error 2
| make[2]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09/main'
| make[1]: *** [main/] Error 2
| make[1]: Leaving directory /home/edd/src/debian/octave-forge-2002.05.09'
| make: *** [build-stamp] Error 2
|
| This is using the 2002.05.09 release of octave-forge. Is there something I
| need from CVS to deal with this?

There have been a lot of changes to the parts of Octave that handle
indexing and indexed assignment.

I'd like to include this functionality in Octave, but it should
probably wait until structure arrays can be multidimensional.

For now, I think the following patch should make getfield.cc compile
and prevent setfield from creating invalid structures.

jwe


--- getfield.cc~ 2002-10-24 09:48:30.000000000 -0500
+++ getfield.cc 2002-10-24 09:53:29.000000000 -0500
@@ -36,12 +36,14 @@
     for (int i = 1; i<nargin; i++) {
 
       if (args(i).is_string ()) {
- std::string s = args(i).string_value ();
- octave_value tmp = args(0).do_struct_elt_index_op (s, true);
+ octave_value tmp = args(0).subsref (".", args(i));
 
  if (tmp.is_defined ())  retval(i-1) = tmp;
 
- else  error ("structure has no member `%s'", s.c_str ());
+ else {
+  std::string s = args(i).string_value ();
+  error ("structure has no member `%s'", s.c_str ());
+ }
 
       } else
  error ("argument number %i is not a string",i+1);
--- setfield.cc~ 2002-10-24 09:51:26.000000000 -0500
+++ setfield.cc 2002-10-24 10:02:29.000000000 -0500
@@ -57,7 +57,7 @@
     
     if (args(i).is_string ()) {
       std::string s = args(i).string_value ();
-      tmp [s] = args(i+1);
+      tmp.assign (s, args(i+1));
     } else
       error ("argument number %i is not a string",i+1);
   }


Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] Re: Octave 2.1.37 available for ftp

Etienne Grossmann-4
In reply to this post by Etienne Grossmann-4

   Hello,


1) The va_arg() change causes tons of messages (any way to turn them
   off?). On the contrary, the now obsolete is_XXX() cause no fuss at
   first sight.

2) There seem to be a fair amount of broken things

3) I am preparing slides for my PhD next week, so I won't be very
   available for octave-forge until then.

Still, I am doing cvs update and will see if I can fix the main/struct
directory.

  Etienne

On Thu, Oct 24, 2002 at 11:00:12AM -0400, Paul Kienzle wrote:
# On Wed, Oct 23, 2002 at 10:49:04PM +0100, Etienne Grossmann wrote:
# >
# >   Hello,
# >
[snip]
# I say commit directly.  If anything really serious goes wrong we can
# always back out.
#
# Are we abandoning support for 2.1.36?

  Let's get support to 2.137!
 
# - Paul
#

--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne


Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] Re: Octave 2.1.37 available for ftp

John W. Eaton-6
On 24-Oct-2002, Etienne Grossmann <[hidden email]> wrote:

|
|    Hello,
|
|
| 1) The va_arg() change causes tons of messages (any way to turn them
|    off?). On the contrary, the now obsolete is_XXX() cause no fuss at
|    first sight.

You could try

  warning ("off")

but that's a big hammer.  Or you could find the place in Octave where
the warning is issued and remove it.  But I'd rather fix as many of
the va_arg usages as we can now, so that we can delete va_arg
completely from Octave before too long.

| 2) There seem to be a fair amount of broken things

What?

| 3) I am preparing slides for my PhD next week, so I won't be very
|    available for octave-forge until then.

OK.

| Still, I am doing cvs update and will see if I can fix the main/struct
| directory.

I already posted a patch for getfield and setfield.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Paul Kienzle-6
In reply to this post by John W. Eaton-6
For the cygwin build I'm getting the following:

        octave> tic; x=rand(100); toc
        ans = 0.032001
        octave> tic; sprintf("%15g ", x); toc
        ans = 108.51
              ^^^^^^

My slightly faster linux box gives the following:

        octave:4> tic; x=rand(100); toc
        ans = 0.020411
        octave:5> tic; sprintf("%15g ", x); toc
        ans = 0.37612

I can avoid using sprintf for now, but when I get to
it, do you think the problem is more likely in cygwin
itself, or somewhere in the octave layer above cygwin.

Paul Kienzle
[hidden email]

On Wed, Oct 23, 2002 at 02:30:50PM -0500, John W. Eaton wrote:

> Octave 2.1.37 is now available for ftp from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:
>
>   -rw-r--r--  1 ftpadm   ftp   4858297 Oct 23 13:29 octave-2.1.37.tar.gz
>   -rw-r--r--  1 ftpadm   ftp   3802708 Oct 23 13:29 octave-2.1.37.tar.bz2
>
> There are no diffs this time because they are quite large.
>
> If your favorite bug is still not fixed, please let me know about it.
>
> Thanks,
>
> jwe
>


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

John W. Eaton-6
On 24-Oct-2002, Paul Kienzle <[hidden email]> wrote:

| For the cygwin build I'm getting the following:
|
| octave> tic; x=rand(100); toc
| ans = 0.032001
| octave> tic; sprintf("%15g ", x); toc
| ans = 108.51
|      ^^^^^^
|
| My slightly faster linux box gives the following:
|
| octave:4> tic; x=rand(100); toc
| ans = 0.020411
| octave:5> tic; sprintf("%15g ", x); toc
| ans = 0.37612
|
| I can avoid using sprintf for now, but when I get to
| it, do you think the problem is more likely in cygwin
| itself, or somewhere in the octave layer above cygwin.

I think the problem is partially with stringstreams and gcc-2.95.x.
The good news is that it appears to be fixed with g++ 3.2.  But to
make things better for Octave with 2.95.x, I think the following patch
will help.

If you want details, ask.  For now, I'm too tired of looking at this
problem to write up the details.

jwe

liboctave/ChangeLog:

2002-10-24  John W. Eaton  <[hidden email]>

        * lo-sstream.h: Undef HAVE_SSTREAM if using a version of g++
        earlier than 3.0.

src/ChangeLog:

2002-10-24  John W. Eaton  <[hidden email]>

        * cutils.c (octave_vsnprintf): Buffer and buffer size now static.
        * utils.cc (octave_vformat): Don't free buffer returned from
        octave_vsnprintf here.
 

Index: liboctave/lo-sstream.h
===================================================================
RCS file: /usr/local/cvsroot/octave/liboctave/lo-sstream.h,v
retrieving revision 1.1
diff -u -r1.1 lo-sstream.h
--- liboctave/lo-sstream.h 17 Aug 2002 19:38:32 -0000 1.1
+++ liboctave/lo-sstream.h 24 Oct 2002 21:43:56 -0000
@@ -23,6 +23,10 @@
 #if !defined (octave_liboctave_sstream_h)
 #define octave_liboctave_sstream_h 1
 
+#if defined (__GNUG__) && __GNUC__ < 3
+#undef HAVE_SSTREAM
+#endif
+
 #ifdef HAVE_SSTREAM
 
 #include <sstream>
Index: src/cutils.c
===================================================================
RCS file: /usr/local/cvsroot/octave/src/cutils.c,v
retrieving revision 1.10
diff -u -r1.10 cutils.c
--- src/cutils.c 3 Oct 2002 19:08:45 -0000 1.10
+++ src/cutils.c 24 Oct 2002 21:44:03 -0000
@@ -119,13 +119,19 @@
   return strncasecmp (s1, s2, n);
 }
 
+// We manage storage.  User should not free it, and its contents are
+// only valid until next call to vsnprintf.
+
 char *
 octave_vsnprintf (const char *fmt, va_list args)
 {
 #if defined (HAVE_VSNPRINTF)
-  size_t size = 100;
+  static size_t size = 100;
+
+  static char *buf = 0;
 
-  char *buf = malloc (size);
+  if (! buf)
+    buf = malloc (size);
 
   while (1)
     {
Index: src/utils.cc
===================================================================
RCS file: /usr/local/cvsroot/octave/src/utils.cc,v
retrieving revision 1.145
diff -u -r1.145 utils.cc
--- src/utils.cc 8 Oct 2002 23:48:46 -0000 1.145
+++ src/utils.cc 24 Oct 2002 21:44:05 -0000
@@ -717,19 +717,7 @@
 
 #if defined (__GNUG__) && !CXX_ISO_COMPLIANT_LIBRARY
 
-  OSSTREAM buf;
-
-  buf.vform (fmt, args);
-
-  buf << OSSTREAM_ENDS;
-
-  std::string s = OSSTREAM_STR (buf);
-
-  OSSTREAM_FREEZE (buf);
-
-  os << s;
-
-  retval = s.length ();
+  os.vform (fmt, args);
 
 #else
 
@@ -740,8 +728,6 @@
       os << s;
 
       retval = strlen (s);
-
-      free (s);
     }
 
 #endif


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Paul Kienzle-6
On Thu, Oct 24, 2002 at 04:46:51PM -0500, John W. Eaton wrote:

> On 24-Oct-2002, Paul Kienzle <[hidden email]> wrote:
>
> | For the cygwin build I'm getting the following:
> |
> | octave> tic; x=rand(100); toc
> | ans = 0.032001
> | octave> tic; sprintf("%15g ", x); toc
> | ans = 108.51
> |      ^^^^^^
> |
> | My slightly faster linux box gives the following:
> |
> | octave:4> tic; x=rand(100); toc
> | ans = 0.020411
> | octave:5> tic; sprintf("%15g ", x); toc
> | ans = 0.37612
> |
> | I can avoid using sprintf for now, but when I get to
> | it, do you think the problem is more likely in cygwin
> | itself, or somewhere in the octave layer above cygwin.
>
> I think the problem is partially with stringstreams and gcc-2.95.x.
> The good news is that it appears to be fixed with g++ 3.2.  But to
> make things better for Octave with 2.95.x, I think the following patch
> will help.
>
> If you want details, ask.  For now, I'm too tired of looking at this
> problem to write up the details.

Thanks.  I'll try the patch.  Then I'll move to gcc 3.2.

- Paul


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Paul Kienzle-6
In reply to this post by John W. Eaton-6
On Thu, Oct 24, 2002 at 04:46:51PM -0500, John W. Eaton wrote:

> On 24-Oct-2002, Paul Kienzle <[hidden email]> wrote:
>
> | For the cygwin build I'm getting the following:
> |
> | octave> tic; x=rand(100); toc
> | ans = 0.032001
> | octave> tic; sprintf("%15g ", x); toc
> | ans = 108.51
> |      ^^^^^^
> |
> | My slightly faster linux box gives the following:
> |
> | octave:4> tic; x=rand(100); toc
> | ans = 0.020411
> | octave:5> tic; sprintf("%15g ", x); toc
> | ans = 0.37612
> |
> | I can avoid using sprintf for now, but when I get to
> | it, do you think the problem is more likely in cygwin
> | itself, or somewhere in the octave layer above cygwin.
>
> I think the problem is partially with stringstreams and gcc-2.95.x.
> The good news is that it appears to be fixed with g++ 3.2.  But to
> make things better for Octave with 2.95.x, I think the following patch
> will help.
>
> If you want details, ask.  For now, I'm too tired of looking at this
> problem to write up the details.

FYI, without the patch, performance under cygwin using gcc 3.2 is much
more reasonable.  It's down to 0.8s for sprintf("%g ", rand(100)).  Even
though this machine is faster it is not 100x faster.

One more error appears when compiling under Cygwin for gcc 3.2.  This is
the munge-texi problem I mentioned earlier.  Again, #include "Map-s.cc"
plus some diddling in munge-texi.cc hides the problem.

A problem in doc/interpreter/Makefile, cygwin's version of texi2html wants

        texi2html -expandinfo -split_chapter -I ./.. octave.texi

instead of

        texi2html -expand info -split chapter -I ./.. octave.texi

- Paul


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

John W. Eaton-6
On 25-Oct-2002, Paul Kienzle <[hidden email]> wrote:

| FYI, without the patch, performance under cygwin using gcc 3.2 is much
| more reasonable.  It's down to 0.8s for sprintf("%g ", rand(100)).  Even
| though this machine is faster it is not 100x faster.

OK.

| One more error appears when compiling under Cygwin for gcc 3.2.  This is
| the munge-texi problem I mentioned earlier.  Again, #include "Map-s.cc"
| plus some diddling in munge-texi.cc hides the problem.

Does it also work to add -DNO_PRAGMA_INTERFACE_IMPLEMENTATION to the
commands for compiling and linking munge-texi.cc?

| A problem in doc/interpreter/Makefile, cygwin's version of texi2html wants
|
| texi2html -expandinfo -split_chapter -I ./.. octave.texi
|
| instead of
|
| texi2html -expand info -split chapter -I ./.. octave.texi

OK, I made this change in all the doc/*/Makefile.in files.  I noticed
some messages from this problem but forgot to do anything about them.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Paul Kienzle-6
In reply to this post by John W. Eaton-6
I'm getting core dumps when reloading an m-file after editting
in 2.1.37.  Before I start debugging this, is anyone else
getting this behaviour?

- Paul

On Wed, Oct 23, 2002 at 02:30:50PM -0500, John W. Eaton wrote:

> Octave 2.1.37 is now available for ftp from ftp.octave.org in the
> directory /pub/octave/bleeding-edge:
>
>   -rw-r--r--  1 ftpadm   ftp   4858297 Oct 23 13:29 octave-2.1.37.tar.gz
>   -rw-r--r--  1 ftpadm   ftp   3802708 Oct 23 13:29 octave-2.1.37.tar.bz2
>
> There are no diffs this time because they are quite large.
>
> If your favorite bug is still not fixed, please let me know about it.
>
> Thanks,
>
> jwe
>


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

John W. Eaton-6
On 25-Oct-2002, Paul Kienzle <[hidden email]> wrote:

| I'm getting core dumps when reloading an m-file after editting
| in 2.1.37.  Before I start debugging this, is anyone else
| getting this behaviour?

Seems to work for me with the current CVS sources when compiled with
--enable-shared.  But I don't think I've changed anything significant
to dynamic linking, so I would expect the same results with the
sources from the 2.1.37 tar file.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Etienne Grossmann-4
In reply to this post by Paul Kienzle-6
On Fri, Oct 25, 2002 at 04:41:30PM -0400, Paul Kienzle wrote:
# I'm getting core dumps when reloading an m-file after editting
# in 2.1.37.  Before I start debugging this, is anyone else
# getting this behaviour?

  Hello,

I have switched back to 2.1.36 until wednesday : I am presenting my
PhD on tuesday, so until then I would rather have a working setup.

  Starting wednesday, I will look more closely at octave-2.1.37 and
octave-forge.

  Etienne

--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne


Reply | Threaded
Open this post in threaded view
|

Re: Octave 2.1.37 available for ftp

Dirk Eddelbuettel
In reply to this post by Etienne Grossmann-4

For the record, octave-forge built just fine Debian once I applied JWE's
patch to main/struct/{get,set}field.cc.

So as far as Debian is concerned, we have octave-2.1.37 as well as updated
versions of octave-forge and octave-sp in the unstable distribution.

Dirk

--
Good judgement comes from experience; experience comes from bad judgement.
                                                            -- Fred Brooks


Reply | Threaded
Open this post in threaded view
|

dynamic field names for structures

John W. Eaton-6
In reply to this post by John W. Eaton-6
On 25-Oct-2002, Paul Kienzle <[hidden email]> wrote:

| Have you ever considered accepting string indices for structure
| variables so that instead of
|
| eval(["x.",el])
|
| or
|
| getfield(x,el)
|
| You could write
|
| x(el)
|
| ?  I presume for an array of structures, this would be
|
| x(i,j)(el)
|
| Just a thought.

I just checked in some changes to Octave that allow

  x.(el)

and

  x(i,j).(el)

when el is an expression that evaluates to a string.  This syntax
should be compatible with Matlab R13.

This also makes getfield and setfield obsolete, and the Matlab docs
now say that those functions are deprecated.  In any case, I think it
should now be possible to implement Matlab-compatible getfield and
setfield functions in an M-file using the new syntax.  If not, please
let me know what additional features are required to make it work.

Thanks,

jwe