CVS Octave is now Pix-free

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

CVS Octave is now Pix-free

John W. Eaton-6
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 octave-forge 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 octave-forge 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
octave-2.1.40.  Longer term, we will probably want to switch to STL
containers.

jwe



Index: complex_sparse_ops.cc
===================================================================
RCS file: /cvsroot/octave/octave-forge/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/octave-forge/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/octave-forge/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;


Reply | Threaded
Open this post in threaded view
|

Re: CVS Octave is now Pix-free

Andy Adler
Thanks for this work, John.

My only issue is that if we check in these changes now,
then octave-forge 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)562-5800 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 octave-forge 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 octave-forge 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
> octave-2.1.40.  Longer term, we will probably want to switch to STL
> containers.
>
> jwe
>
>
>
> Index: complex_sparse_ops.cc
> ===================================================================
> RCS file: /cvsroot/octave/octave-forge/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/octave-forge/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/octave-forge/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;
>


Reply | Threaded
Open this post in threaded view
|

Re: CVS Octave is now Pix-free

John W. Eaton-6
On  6-Dec-2002, Andy Adler <[hidden email]> wrote:

| My only issue is that if we check in these changes now,
| then octave-forge 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 octave-forge and
then include the reverse set of patches with octave-forge 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


Reply | Threaded
Open this post in threaded view
|

Re: CVS Octave is now Pix-free

Paul Kienzle-2
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  6-Dec-2002, Andy Adler <[hidden email]> wrote:
>
> | My only issue is that if we check in these changes now,
> | then octave-forge 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 octave-forge and
> then include the reverse set of patches with octave-forge 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
>


Reply | Threaded
Open this post in threaded view
|

Re: CVS Octave is now Pix-free

Paul Kienzle-2
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  6-Dec-2002, 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


Reply | Threaded
Open this post in threaded view
|

Re: CVS Octave is now Pix-free

John W. Eaton-6
On  7-Dec-2002, 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