

I've just checked in some changes that replace all uses of the old
libg++ SLList, SLStack, CHMap, DLList, etc. classes with corresponding
standard C++ STL classes. This probably means that g++ 3.2 or some
simlarly capable compiler is now needed to build Octave.
The sparse matrix code in octaveforge will also need the patch below.
In this particular case, all that was required was substituting
std::list for SLList, but it's not always that simple because the
SLList interface is different from std::list.
The mex compatibility code in octaveforge will also have to be
changed because including <octave/SLList.h> will no longer work. For
now, it might be best to just copy the files that are needed from
octave2.1.40. Longer term, we will probably want to switch to STL
containers.
jwe
Index: complex_sparse_ops.cc
===================================================================
RCS file: /cvsroot/octave/octaveforge/main/sparse/complex_sparse_ops.cc,v
retrieving revision 1.10
diff u r1.10 complex_sparse_ops.cc
 complex_sparse_ops.cc 27 Nov 2002 04:46:42 0000 1.10
+++ complex_sparse_ops.cc 6 Dec 2002 19:35:38 0000
@@ 460,7 +460,7 @@
octave_value_list
octave_complex_sparse::subsref( const std::string type,
 const SLList<octave_value_list>& idx,
+ const std::list<octave_value_list>& idx,
int nargout)
{
// octave_value retval;
Index: make_sparse.h
===================================================================
RCS file: /cvsroot/octave/octaveforge/main/sparse/make_sparse.h,v
retrieving revision 1.10
diff u r1.10 make_sparse.h
 make_sparse.h 27 Nov 2002 04:46:42 0000 1.10
+++ make_sparse.h 6 Dec 2002 19:35:38 0000
@@ 183,7 +183,7 @@
octave_value extract (int r1, int c1, int r2, int c2) const ;
octave_value_list subsref (const std::string type,
 const SLList<octave_value_list>& idx,
+ const std::list<octave_value_list>& idx,
int nargout);
octave_value do_index_op ( const octave_value_list& idx);
@@ 242,11 +242,11 @@
octave_value extract (int r1, int c1, int r2, int c2) const ;
octave_value_list subsref (const std::string type,
 const SLList<octave_value_list>& idx,
+ const std::list<octave_value_list>& idx,
int nargout);
#if 0
octave_value subsref( const std::string type,
 const SLList<octave_value_list>& idx);
+ const std::list<octave_value_list>& idx);
#endif
octave_value do_index_op ( const octave_value_list& idx);
Index: sparse_ops.cc
===================================================================
RCS file: /cvsroot/octave/octaveforge/main/sparse/sparse_ops.cc,v
retrieving revision 1.8
diff u r1.8 sparse_ops.cc
 sparse_ops.cc 27 Nov 2002 04:46:42 0000 1.8
+++ sparse_ops.cc 6 Dec 2002 19:35:39 0000
@@ 412,7 +412,7 @@
octave_value_list
octave_sparse::subsref( const std::string type,
 const SLList<octave_value_list>& idx,
+ const std::list<octave_value_list>& idx,
int nargout)
{
// octave_value retval;


Thanks for this work, John.
My only issue is that if we check in these changes now,
then octaveforge will not build with any "released" version
of octave.
I suppose we could always refer people to the released octave
forge packages  but I suspect we'll have many people
writing to the octave mailing list with complaints.
Comments?
Andy

Andy Adler,
Assistant Professor, School of Information Technology and Engineering,
University of Ottawa, Tel:1(613)5625800 X 2345, Email: [hidden email]
On Fri, 6 Dec 2002, John W. Eaton wrote:
> I've just checked in some changes that replace all uses of the old
> libg++ SLList, SLStack, CHMap, DLList, etc. classes with corresponding
> standard C++ STL classes. This probably means that g++ 3.2 or some
> simlarly capable compiler is now needed to build Octave.
>
> The sparse matrix code in octaveforge will also need the patch below.
> In this particular case, all that was required was substituting
> std::list for SLList, but it's not always that simple because the
> SLList interface is different from std::list.
>
> The mex compatibility code in octaveforge will also have to be
> changed because including <octave/SLList.h> will no longer work. For
> now, it might be best to just copy the files that are needed from
> octave2.1.40. Longer term, we will probably want to switch to STL
> containers.
>
> jwe
>
>
>
> Index: complex_sparse_ops.cc
> ===================================================================
> RCS file: /cvsroot/octave/octaveforge/main/sparse/complex_sparse_ops.cc,v
> retrieving revision 1.10
> diff u r1.10 complex_sparse_ops.cc
>  complex_sparse_ops.cc 27 Nov 2002 04:46:42 0000 1.10
> +++ complex_sparse_ops.cc 6 Dec 2002 19:35:38 0000
> @@ 460,7 +460,7 @@
>
> octave_value_list
> octave_complex_sparse::subsref( const std::string type,
>  const SLList<octave_value_list>& idx,
> + const std::list<octave_value_list>& idx,
> int nargout)
> {
> // octave_value retval;
> Index: make_sparse.h
> ===================================================================
> RCS file: /cvsroot/octave/octaveforge/main/sparse/make_sparse.h,v
> retrieving revision 1.10
> diff u r1.10 make_sparse.h
>  make_sparse.h 27 Nov 2002 04:46:42 0000 1.10
> +++ make_sparse.h 6 Dec 2002 19:35:38 0000
> @@ 183,7 +183,7 @@
>
> octave_value extract (int r1, int c1, int r2, int c2) const ;
> octave_value_list subsref (const std::string type,
>  const SLList<octave_value_list>& idx,
> + const std::list<octave_value_list>& idx,
> int nargout);
> octave_value do_index_op ( const octave_value_list& idx);
>
> @@ 242,11 +242,11 @@
>
> octave_value extract (int r1, int c1, int r2, int c2) const ;
> octave_value_list subsref (const std::string type,
>  const SLList<octave_value_list>& idx,
> + const std::list<octave_value_list>& idx,
> int nargout);
> #if 0
> octave_value subsref( const std::string type,
>  const SLList<octave_value_list>& idx);
> + const std::list<octave_value_list>& idx);
> #endif
> octave_value do_index_op ( const octave_value_list& idx);
>
> Index: sparse_ops.cc
> ===================================================================
> RCS file: /cvsroot/octave/octaveforge/main/sparse/sparse_ops.cc,v
> retrieving revision 1.8
> diff u r1.8 sparse_ops.cc
>  sparse_ops.cc 27 Nov 2002 04:46:42 0000 1.8
> +++ sparse_ops.cc 6 Dec 2002 19:35:39 0000
> @@ 412,7 +412,7 @@
>
> octave_value_list
> octave_sparse::subsref( const std::string type,
>  const SLList<octave_value_list>& idx,
> + const std::list<octave_value_list>& idx,
> int nargout)
> {
> // octave_value retval;
>


On 6Dec2002, Andy Adler < [hidden email]> wrote:
 My only issue is that if we check in these changes now,
 then octaveforge will not build with any "released" version
 of octave.

 I suppose we could always refer people to the released octave
 forge packages  but I suspect we'll have many people
 writing to the octave mailing list with complaints.
The patches for the sparse package are fairly small and simple, so I
suppose we could go ahead and make the changes in octaveforge and
then include the reverse set of patches with octaveforge for a while,
so people will know what to do. Or, since the changes are so simple,
I suppose we could put in some kind of #ifdef so that it would work in
either case. I'm not sure exactly what to check for, but if you think
it is important enough, we could probably come up with something.
jwe


What to check for is pretty easy: the octave header that is no longer.
mex doesn't care what it uses since it is not sharing the data with Octave.
Indeed, it should be using a set rather than a list since I want to check
membership, add, remove and clear. There is no inherent ordering to the data.
 Paul
On Fri, Dec 06, 2002 at 04:38:27PM 0600, John W. Eaton wrote:
> On 6Dec2002, Andy Adler < [hidden email]> wrote:
>
>  My only issue is that if we check in these changes now,
>  then octaveforge will not build with any "released" version
>  of octave.
> 
>  I suppose we could always refer people to the released octave
>  forge packages  but I suspect we'll have many people
>  writing to the octave mailing list with complaints.
>
> The patches for the sparse package are fairly small and simple, so I
> suppose we could go ahead and make the changes in octaveforge and
> then include the reverse set of patches with octaveforge for a while,
> so people will know what to do. Or, since the changes are so simple,
> I suppose we could put in some kind of #ifdef so that it would work in
> either case. I'm not sure exactly what to check for, but if you think
> it is important enough, we could probably come up with something.
>
> jwe
>


There is always version number, except of course that version number
isn't an integer. Would you care to define
#define _VERNUM(major,minor,patch) ((major*100 + minor)*1000 + patch)
#define OCTAVE_VERNUM _VERNUM(OCTAVE_MAJOR,OCTAVE_MINOR,OCTAVE_PATCHLEVEL)
Then we can do:
#if OCTAVE_VERNUM > _VERNUM(2,1,40)
...
#else
...
#endif
That allows for a 3 digit patch level, a 2 digit minor version and a
4 digit major version. Room for growth for the next 50k years, no?
That allows us to do simple tests without a configure script. Unfortunately
it interferes with readability: to understand the code you have to know
what was added in which version. Maybe this is not such a good idea.
 Paul
On Fri, Dec 06, 2002 at 09:24:10PM 0600, John W. Eaton wrote:
> On 6Dec2002, Paul Kienzle < [hidden email]> wrote:
>
>  What to check for is pretty easy: the octave header that is no longer.
>
> Sure, I was thinking about some test we could use in the code that
> wouldn't require a configure test.
>
> jwe


On 7Dec2002, Paul Kienzle < [hidden email]> wrote:
 There is always version number, except of course that version number
 isn't an integer. Would you care to define

 #define _VERNUM(major,minor,patch) ((major*100 + minor)*1000 + patch)
 #define OCTAVE_VERNUM _VERNUM(OCTAVE_MAJOR,OCTAVE_MINOR,OCTAVE_PATCHLEVEL)

 Then we can do:

 #if OCTAVE_VERNUM > _VERNUM(2,1,40)
 ...
 #else
 ...
 #endif

 That allows for a 3 digit patch level, a 2 digit minor version and a
 4 digit major version. Room for growth for the next 50k years, no?

 That allows us to do simple tests without a configure script. Unfortunately
 it interferes with readability: to understand the code you have to know
 what was added in which version. Maybe this is not such a good idea.
I think I'd rather avoid making it easy to compare version numbers.
Feature tests would be better, but even then it could easily become a
mess in no time.
It would probably be better to just try to ensure that the latest
versions (even if from CVS) will work together. I don't think we have
the resources available to please everyone's wishes for backward
compatibility.
jwe

