Re: More octave-forge functions!!!

[Søren Hauberg]

man, 29 05 2006 kl. 21:41 +0200, skrev David Bateman:
> > <brainfarting>
> > It seems to me that you put alot of thought into portability (edit,
> > ginput, sound, ...) which is great. My impression is that portability is
> > very hard to achieve without using libraries designed with portability
> > in mind. Such libraries do exist for things like sound, image reading,
> > etc. but that drags in some dependencies. So I guess my question is what
> > is the strategy with regard to portability?
> > 1) Will functionality be left out due to the lack of portable libraries?
> > 2) Will some platforms (i.e. Windows) be left behind due to the lack of
> > portable libraries?
> > 3) Should such hard stuff be left to system-specific packages?
> > 4) ???
> > </brainfarting>
> 
> This is in fact just the type of discussion I was hoping to promote (as
> well as trying to get some help). Where do we draw the line of what
> dependencies we are willing to accept in the core of octave? qhull? gsl?
> libjpg/libpng? Imagemagick? It seems that to get octave duplicating all
> of matlab core functions would require a significant number of
> additional dependencies, and that these should be chosen with care. What
> is the best subset of additional dependent libraries to get the maximum
> compatibility and portability?
I really like the way the R people are doing things. They essentially
supply a base system, that only gives the most basic functionality. In
fact if you only install the base system, you won't be able to much
work. What the R people do next, is to have a rather large amount of
packages that depends on external libraries. To help new users the R
people have created a meta-package that depends on the recommended
packages.

Would this be an option for Octave? That is, make the basic Octave
fairly stripped down, with only the most essential dependencies. The
provide one package that depends on qhull, one that depends on
ImageMagick, etc. And then have a package called something like
octave-matlab-compat that depends on all the packages needed to provide
compatibility with core matlab.

Did that make any sense?

> BTW, my efforts to strip octave-forge of octave core functions has the
> goal of making repackaging octave-forge with the package manager easier.
> Basically there is no point packaging octave-forge functions that should
> be in octave, so better to move them first. What is the status of the
> package manager in octave? Have you rechecked it? Are there any missing
> features (gzipped tar files, I believe were stripped by John)? What
> about cross platform support. Does it work on Mac OS (both flavours),
> cygwin and mingw?

Like everybody else on this list I'm busy-at-the-moment (TM), so I
haven't checked the status of the package system. However, most of the
functionality should be implemented (I can't think of what's missing).
It is not entirely platform independent, but I only think minor changes
need to be made. I also believe that most of the platform dependent code
is factored out in seperate function that does fairly simple things. So,
I'm guessing that platform issues should be minor.

Soren