Re: [OctDev] RE: GUI for Octave programs.

[Paul K. <pki...@ki...>]

Wow!  You exist!  Working on Octave I know can be very disheartening.
Few people join in and collaborate on anything.  Oh, well.

Looking through the archives you point to, here are some random comments:

1) You need an autoconf like facility for the geometry toolbox (which needs
to find libqhull), symbolic toolbox (which needs to find GiNaC among
others), sparse toolbox (which needs SuperLU, but unfortunately a patched 
version),  spline toolbox (which should use ATLAS if available), and
if I get around to it, audio support (which ought to rely on snack and
libsnd).  Kai Habel was going to have a go at it for qhull but he promised
it would take a while.

2) Toolboxes have cross-dependencies which will need to be resolved.
Particularly image/signal, but also splines and things.  Support for
independent packaging is not appropriate at the moment since the toolboxes
are mostly tiny (except signal and image) and enthusiasm is low.  How
about we put a hard limit of 5 Mb total main tree size before we worry
about separate packaging?

3) Links to external packages may be best handled on matlinks.net.
Let the sourceforge repository be an actual repository.  The exception
is if you have made a patch to get the package to work on Octave, in
which case you want to keep around the version which you patched.

4) Could you let the admins in on the mailing list password?  I would
like to confirm that the developers I have been adding are subscribed
to the list, and gently prod them to do so if they are not.

5) I agree that functions should be able to use the latest octave 2.1.x
features if they make the code cleaner, but if 2.0.x can be supported
with only minor hassle, the go for it.  A small flat ver20 directory off
the root can take care of the rest.  Keeping the ver20 functions in sync
with the main tree may be too difficult --- wait until somebody ambitious
decides to take this on.

6) Functions should not require patched versions of Octave or gnuplot to
run.

7) Directory structure should mirror the current Octave directory
structure as far as possible (so no numeric/non-numeric distinction).
Categories not covered could be added as needed.

8) I agree that external libs (qhull, etc.) should not be deep in the tree.

9) All the main toolboxes should go together under one directory, not
hanging off the root.

10) Some scripts rely on external applications.  It would be nice to be
able to test for these at install time, and maybe set some global variables
in the startup scripts to indicate the appropriate application. 

11) Where to put mex and eng interfaces?  contrib?  main?  support?

12) Here's what I propose for the project tree.  Note that I have
included most projects that I know of, though their principals may not
be interested in joining us.  Most people should just need main, and
maybe some of the libraries from lib.

+ main	<mainstream octave toolboxes all using octave conventions>
|   + FIXES <modified octave functions>
|   + audio	<contains scripts and any data required for normal function>
|   |   + doc	<docs giving overview of toolbox>
|   |   + test	<test scripts for all functions in toolbox>
|   |   + demo  <minimal installation may want to exclude demos since 
		 required data files can be large>
|   |   + dld   <C/C++/Fortran code, but not external libs; script 
		 equivalents for the dld challenged>
|   + communications
|   + control
|   + finance
|   + general
|   + identification
|   + image
|   + linear-algebra
|   + miscellaneous
|   + optimization
|   + plot
|   + polynomial
|   + set
|   + signal
|   + sparse
|   + specfun
|   + special-matrix
|   + splines
|   + statistics
|   + strings
|   + struct
|   + symbolic
|   + system
|   + time
+ contrib  <limited interest/experimental toolboxes>
|   + misc
|   + civil
|   + fake-sparse
|   + matcompat <aliases for other functions, provided for compatibility>
|   + testfun	<needs work>
+ extern <toolboxes developed for matlab; link to original;
	  distribute as tarball+patch+build/install/clean scripts>
|   + ode        <until it is converted to octave conventions>
|   + integration <until it is converted to octave conventions> 
|   + tsa        <time series analysis toolbox>
|   + epstk	 <direct to postscript graphing>
+ graphics <various replacements for gnuplot, or for the command line>
|   + tk_octave
|   + plplot
|   + vrml
|   + vtk
|   + superficie
|   + goctave
+ lib	<external libs; distribute as tarball+patch+build/install/clean 
	scripts; link to original>
|   + qhull	<for geometry toolbox>	
|   + SuperLU   <for sparse toolbox>
|   + GiNaC     <for symbolic toolbox>
|   ? GSL	<GNU scientific library>
|   ? snack	<for multi-platform audio support>
|   ...
+ doc
|   + Joao Cardoso's Octave digest
|   + Doug Eck's oct-file FAQ
|   + Christoph Spiel's oct-file tutorial
|   + Paul Kienzle's compatibility database
|   + Various project docs
+ support
|   + mex	<support for matlab mex interface; currently dld/mex>
|   + engine    <use octave as compute engine; currently dld/liboct>
|   + oct2mat	<deoctavate scripts for use in matlab>
|   + Etienne Grossman's dependencies resolver
+ nonfree   <for purists; mirrors top-level structure>
|   + lib
|   + main
|   |   + spline	<noncommercial use only>
|   + contrib
|   + extern
|   |   + wavelab	<wavelet toolbox; must be distributed in its entirety>
|   |   + testmatrix	<test matrices; must be distributed in its entirety>
|   |   + spctools	<speech/signal processing; noncommercial use only>

Paul Kienzle
pki...@sf...

On Thu, May 17, 2001 at 03:54:07PM -0500, Matthew W. Roberts wrote:
> On Wed, May 16, 2001 at 08:52:59AM +0100, Paul Kienzle wrote: 
> > The whole project needs to be purged and a new CVS tree put in
> > place having the structure we want, and clear instructions on
> > where to put new files and directories. ...
> 
> Agreed.  There have been several discussions in the past on the
> directory structure:
> 
> http://www.geocrawler.com/archives/3/3262/2001/2/0/
> http://lists.sourceforge.net/archives/octave-dev/2000-October/thread.html
> http://lists.sourceforge.net/archives/octave-dev/2000-November/thread.html
> 
> Personally, I would prefer to base the directories on a toolbox-type
> layout with each toolbox having its own directory.  That way we can
> easily package toolboxes independently for distribution.
> 
> BTW, for those that may have missed it, sourceforge has secured the
> sf.net domain.  So an easier way to get to the home page is:
> 
> http://octave.sf.net/
> 
> 
> 
> --
> Matthew W. Roberts
> ------------------------------------------------------------------
> Structural Engineering  *  Texas A&M University  *  ma...@ta...
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/lists/listinfo/octave-dev
>