octave-forge -> octave

[Paul Kienzle]

[Continued from bug-octave list]

On Dec 16, 2003, at 10:35 PM, John W. Eaton wrote:
> | Okay.  I can't remove the functions from octave-forge since
> | other octave-forge routines depend on them, so I may include
> | yours instead, or better yet, have a facility to install them only if
> | they are not already present.
>
> Yes, I understand the transition problem, but I hope that if Octave
> starts to include code from octave-forge, that the octave-forge
> routines will eventually be removed (assuming the Octave versions do
> everything we need for octave-forge).

That's what I did for the last big batch (around 2.1.35?)  In future 
though,
I think I will move them to an 'old' directory and make more use of 
configure
to see what needs to be installed.

> At this point, my intent for adopting functions is that if they are in
> octave-forge for compatibility with the base Matlab, I would like to
> see them moved into the core Octave distribution.

There are a number of them.  Particularly the interpolation routines.

I have a small concern that gutting octave-forge may lead to it becoming
irrelevant, but so long as major packages like signal, image,
communications, and maybe one day statistics and control systems
are host there, I guess there is little danger of that.

BTW, you may want to consider vertical rather than horizontal
integration for things like the differential equations solvers.  You 
can't split
them off into a specialized package when they depend on the base
libraries in libcruft, the C++ interface in liboctave, and the glue
layer in src/DLD-FUNCTIONS.  Or to put it another way, how can
liboctave be constructed from a separable components?  Any idea
how much liboctave is used outside of octave itself?

> Likewise, some of
> the current functions in the core Octave distribution should be moved
> out to separate packages.

We are happy to host them.

Paul Kienzle
address@hidden