octave-dev

[OctDev] Repository

[<Kai...@t-...>]

Hello,

So, we are a few registered developers now, what are our next steps? I
have reread the recent thread 'User Functions' on octave-help (~ 10.
october). All seems to agree to move the matcompat scripts (assembled by
Paul) to sourceforge, right?

First we have to setup a cvs archive structure, Here is my suggestion

+ matcompat
|    + m
|    | + audio
|    | + general
|    | + ...
|    |
|    + dld
|    |   + audio ???
|    |   + ...
|    |
|    + libs ???
|
+ contrib
     + m
     | + audio
     | + ...
     |
     + dld
     |  + audio ???
     |  + ...
     |
     + libs ???

As you can see I would like to separate the functions in matlab
compatible and noncompatible. Comments?

When we have the structure, I would like to start commiting with new
versions of my own scripts to get familiar with cvs.

Bye Kai
-- 
Kai Habel
mailto:kai...@gm...

[OctDev] Repository

[Etienne G. <et...@an...>]

Hello,

From: Kai...@t-... (Kai Habel)
#  So, we are a few registered developers now, what are our next steps? I
#  have reread the recent thread 'User Functions' on octave-help (~ 10.
#  october). All seems to agree to move the matcompat scripts (assembled by
#  Paul) to sourceforge, right?

#  First we have to setup a cvs archive structure, Here is my suggestion

#  + matcompat
#  |    + m
#  |    | + audio
#  |    | + general
#  |    | + ...
#  |    |
#  |    + dld
#  |    |   + audio ???
#  |    |   + ...
#  |    |
#  |    + libs ???
#  |
#  + contrib
#       + m
#       | + audio
#       | + ...
#       |
#       + dld
#       |  + audio ???
#       |  + ...
#       |
#       + libs ???
#
#  As you can see I would like to separate the functions in matlab
#  compatible and noncompatible. Comments?
#
#  When we have the structure, I would like to start commiting with new
#  versions of my own scripts to get familiar with cvs.

  You mean we should decide what the subdirs are? I have something
like this (where I omit some directories that are of interest just for
me, and directories containing test functions). 

./general
./......./optim
./......./rot
./tools
./...../dumper
./...../graphics
./...../imgio
./...../...../images.all
./...../...../test_images
./...../matcompat
./...../misc
./...../strings
./...../struct
./...../vrml

  I agree that "tools" (not numeric stuff; well, graphics is numeric)
is not a pretty name, but it means what it means. Another possibility
is to clone octave's structure, which has a lot (too many?) "root"
directories :

./audio
./control
./......./base
./......./hinf
./......./obsolete
./......./system
./......./util
./elfun
./finance
./general
./image
./io
./linear-algebra
./miscellaneous
./plot
./polynomial
./quaternion
./set
./signal
./specfun
./special-matrix
./startup
./statistics
./........../base
./........../distributions
./........../models
./........../tests
./strings
./time

  Maybe a ad-hoc classification in numeric/non-numeric and in
general/specific?

                     general                      specific

  numeric            polynomials                  finance
                     optimization                 computer-vision
                     statistics                   graphics
                     elfun                        signal
                     specfun                      
                     linear-algebra
                     misc

  non-numeric        strings                      vrml
                     plot
                     img-io
                     io
                     misc
                     time

  
  and the same for dlds? 

  Cheers,

  Etienne

[OctDev] Directory Structure

[<Kai...@t-...>]

Hello Etienne,

I like your classification in numeric / non-numeric but I wouldn't use
another level for general/specific. If we have to many subdirs in the
future we could put the most specific in a separate subdir. For the dlds
the same structure should be used, if needed. Ok we have so far.

scripts
   +numeric
       +elfun
       +....
   +nonnumeric
       +strings
       +io

dld
   +numeric
       +elfun
       +....
   +nonnumeric
       +strings
       +io
  

If that's ok for you, I'll start setting it up and commiting.

Bye Kai
-- 
Kai Habel
mailto:kai...@gm...

[OctDev] Re: Directory Structure

[Matthew W. R. <ma...@le...>]

A few questions on the CVS directory structure.  As I understand it,
contrib and dld at the top level are dead, right?  If so, I'll try
and get them deleted.

Also, under octave there is a contrib directory.  Originally, my
plan was to put all user-contributed scripts that are not part of
the official octave under contrib.  This does not appear to be the
case anymore.  Do we still need the contrib directory?

One more thing -- are we still planning on setting up a separate
matcompat directory?  I'd like to upload Paul Kienzle's scripts into
the repository.

Thanks, 

Matt

On Oct 29, 2000 at 10:28:21AM, Kai Habel wrote:
> Hello Etienne,
> 
> I like your classification in numeric / non-numeric but I wouldn't use
> another level for general/specific. If we have to many subdirs in the
> future we could put the most specific in a separate subdir. For the dlds
> the same structure should be used, if needed. Ok we have so far.
> 
> scripts
>    +numeric
>        +elfun
>        +....
>    +nonnumeric
>        +strings
>        +io
> 
> dld
>    +numeric
>        +elfun
>        +....
>    +nonnumeric
>        +strings
>        +io
>   
> 
> If that's ok for you, I'll start setting it up and commiting.
> 
> Bye Kai
> -- 
> Kai Habel
> mailto:kai...@gm...
> 
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/mailman/listinfo/octave-dev

Re: [OctDev] Re: Directory Structure

[<Kai...@t-...>]

"Matthew W. Roberts" wrote:
> 
> A few questions on the CVS directory structure.  As I understand it,
> contrib and dld at the top level are dead, right?  If so, I'll try
> and get them deleted.
> 

Yes, that would be great.

> Also, under octave there is a contrib directory.  Originally, my
> plan was to put all user-contributed scripts that are not part of
> the official octave under contrib.  This does not appear to be the
> case anymore.  Do we still need the contrib directory?

I don't think it is needed anymore. 

> 
> One more thing -- are we still planning on setting up a separate
> matcompat directory?  I'd like to upload Paul Kienzle's scripts into
> the repository.

I wouldn't use a separate subdirectory, we should merge the files in our
directory structure.
If we want to release a matcompat package we can use some Makefile magic
to bundle the appropriate files. 
Have you talked with Paul about that?

Bye Kai

-- 
Kai Habel
mailto:kai...@gm...

[OctDev] Re: Directory Structure

[Matthew W. R. <ma...@ne...>]

I know this is a bit old...

> > One more thing -- are we still planning on setting up a separate
> > matcompat directory?  I'd like to upload Paul Kienzle's scripts into
> > the repository.
> 
> I wouldn't use a separate subdirectory, we should merge the files in our
> directory structure.

The problem with this is that when a new version of matcompat is
released (as just happened last month) we have to go back and figure
out again where we put the files.

> If we want to release a matcompat package we can use some Makefile magic
> to bundle the appropriate files. 

Sure, but it seems that it would be a lot easier to just keep them
in a separate directory.

> Have you talked with Paul about that?

No, but I will contact him.

[OctDev] Repository

[Etienne G. <et...@an...>]

 Hello again

From: Kai...@t-... (Kai Habel)
#  Hello,
#
#  So, we are a few registered developers now, what are our next steps? I
#  have reread the recent thread 'User Functions' on octave-help (~ 10.
#  october). All seems to agree to move the matcompat scripts (assembled by
#  Paul) to sourceforge, right?
#
#  First we have to setup a cvs archive structure, Here is my suggestion
[snip]

  On that subject

1) It would be good to offer an easy way of getting parts of the
   repository would be useful for people who don't have CVS or don't
   want to check out the whole repository. Like tarballs, for m-files.
   Tarballs + Makefile for DLD functions? (I don't know how to install
   them, except "by hand").

2) On-line documentation : Could use oct2html and friends.

3) 2.1 vs 2.0 : one directory tree for each? I use only 2.1 and don't
   know what would run with 2.0.

4) Test functions : there is Paul's "ftest" function. Nowadays, I use
   scripts "test_function_name", which set an "ok" variable to 1 or 0
   and can be more or less verbose depending on the presence of a
   "verbose" variable. This can help make sure that changes don't
   break things.

  Cheers,

  Etienne

Re: [OctDev] Repository

[<Kai...@t-...>]

Etienne Grossmann wrote:
> 
>  Hello again
> 
> From: Kai...@t-... (Kai Habel)
> #  Hello,
> #
> #  So, we are a few registered developers now, what are our next steps? I
> #  have reread the recent thread 'User Functions' on octave-help (~ 10.
> #  october). All seems to agree to move the matcompat scripts (assembled by
> #  Paul) to sourceforge, right?
> #
> #  First we have to setup a cvs archive structure, Here is my suggestion
> [snip]
> 
>   On that subject
> 
> 1) It would be good to offer an easy way of getting parts of the
>    repository would be useful for people who don't have CVS or don't
>    want to check out the whole repository. Like tarballs, for m-files.
>    Tarballs + Makefile for DLD functions? (I don't know how to install
>    them, except "by hand").

Sourceforge provides a daily snapshot of the cvs archive. Our address is
http://cvs.sourceforge.net/cvstarballs/octave-cvsroot.tar.gz
We can release complete tarballs from time to time. If there is demand
we can split the tarball up. For the installation we can use some
autotools magic.

> 2) On-line documentation : Could use oct2html and friends.

I would like to use texinfo, that we can easily merge scripts into
octaves main tree.
 
> 
> 3) 2.1 vs 2.0 : one directory tree for each? I use only 2.1 and don't
>    know what would run with 2.0.

Same here. I don't think we have the capacity to support both trees, so
we should focus our efforts on 2.1.

 
> 4) Test functions : there is Paul's "ftest" function. Nowadays, I use
>    scripts "test_function_name", which set an "ok" variable to 1 or 0
>    and can be more or less verbose depending on the presence of a
>    "verbose" variable. This can help make sure that changes don't
>    break things.
>

I will look at this

>   Cheers,
> 
>   Etienne
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/mailman/listinfo/octave-dev

-- 
Kai Habel
mailto:kai...@gm...