octave-dev — GNU Octave developers' list

Re: [OctDev] Contributing the GPC bindings to octave.sf.net

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

Okay, I'll add you to the group.  Put your files in the octave/non-free
directory.

If I get a chance over the next few weeks I will put some control files
together so that octaveSF can be packaged.  I will probably want to
rearrange some things to make it more convenient.  School is just ending
for the year here in England, so doing this depends how many playdates
I can arrange for the little ones.  Wish me luck.

Paul 

On Wed, Jul 11, 2001 at 10:42:34AM +0200, Rafael Laboissiere wrote:
> Hi, 
> 
> Regarding my last message to octave-dev, if there is any interest, I could
> contribute the Octave bindings for the GCP library to the octave.sf.net
> project.  I am already a registered SF user, login name rlaboiss.
> 
> Please, tell me where the code should go in the CVS tree.  It is composed
> essentially of DLD functions + one .m script for plotting.
>  
> -- 
> Rafael Laboissiere
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/lists/listinfo/octave-dev
> 

[OctDev] Contributing the GPC bindings to octave.sf.net

[Rafael L. <ra...@ic...>]

Hi, 

Regarding my last message to octave-dev, if there is any interest, I could
contribute the Octave bindings for the GCP library to the octave.sf.net
project.  I am already a registered SF user, login name rlaboiss.

Please, tell me where the code should go in the CVS tree.  It is composed
essentially of DLD functions + one .m script for plotting.
 
-- 
Rafael Laboissiere

[OctDev] ITP: gpcl -- General Polygon Clipper Library + Octave bindings

[Rafael L. <ra...@ic...>]

Package: wnpp
Severity: wishlist

[ Note:  I am crossposting this message, originally intented to the Debian
  Bug Tracking System, to the help-octave and octave-dev mailing list. I am
  to busy/lazy to do several announcements. ]

I am in the process of packaging Alan Murta's General Polygon Clipper
Library.  Its web site is the following:

    http://www.cs.man.ac.uk/~amurta/software/index.html#gpc

Unfortunately, the licence terms (non-commercial distribution only) will
prevent the packages from going into main.  It will land on non-free.

I added autoconf/automake/libtool support to the upstream sources, but I am
considering this modification as a Debian specific one (hence the
modifications will appear only in the diff.gz file).

I also generated Octave bindings for the library, allowing easy access to
the polygon clipping routines, as well as plotting, from Octave programs,
like this:

     s = gpc_read ("subj1.gpf");
     c = gpc_read ("clip1.gpf");
 
     r = gpc_clip (s,c);
 
     gpc_plot (s, "r");
     gpc_plot (c, "g");
     gpc_plot (r, "b");

I am planning to contribute the Octave bindings to octave.sf.net.

Here are the descriptions of the Debian packages:

 Package: libgpcl0
 Version: 2.31-1
 Section: non-free/math
 Priority: optional
 Architecture: i386
 Depends: libc6 (>= 2.2.3-1)
 Installed-Size: 88
 Maintainer: Rafael Laboissiere <ra...@ic...>
 Source: gpcl
 Description: A general polygon clipper library
  A flexible and highly robust polygon set operations library for use with C
  applications, as referenced in the comp.graphics.algorithms FAQ and the
  UIUC Computational Geometry Pages.
  .
  Features:
     * Difference, intersection, exclusive-or and union clip operations are
       supported.
     * Polygons may be comprised of multiple disjoint contours.
     * Contour vertices may be given in any order - clockwise or
       anticlockwise.
     * Contours may be convex, concave or self-intersecting.
     * Contours may be nested (i.e. polygons may have holes).
     * Output may take the form of either polygon contours or tristrips.
     * Hole and external contours are differentiated in the result.
     * Coincident edges and degenerate regions are handled correctly.
  .
  For more information see:
     http://www.cs.man.ac.uk/~amurta/software/index.html#gpc


 Package: libgpcl-dev
 Version: 2.31-1
 Section: non-free/math
 Priority: optional
 Architecture: i386
 Depends: libgpcl0 (= 2.31-1), libc6-dev
 Installed-Size: 220
 Maintainer: Rafael Laboissiere <ra...@ic...>
 Source: gpcl
 Description: A general polygon clipper library -- development package
  A flexible and highly robust polygon set operations library for use with C
  applications, as referenced in the comp.graphics.algorithms FAQ and the
  UIUC Computational Geometry Pages.
  .
  This package contains the include files and static library for the GPC
  library.  Also included some example polygons and HTML documentation.
  .
  For more information see :
     http://www.cs.man.ac.uk/~amurta/software/index.html#gpc


 Package: octave-gpc
 Version: 0.1-1
 Section: contrib/math
 Priority: optional
 Architecture: i386
 Depends: octave2.1, libc6 (>= 2.2.3-1), libgpcl0, libstdc++2.10-glibc2.2
 Installed-Size: 188
 Maintainer: Rafael Laboissiere <ra...@ic...>
 Description: Octave bindings for the General Polygon Clipper Library
  GPC is a flexible and highly robust polygon set operations
  library for use with C applications.  This package contains bindings for
  use of the library functions with Octave.
    

-- 
Rafael Laboissiere <ra...@de...>

Re: [OctDev] adding ode solvers to cvs

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

Marc, 

For the moment, maintain your ode functions where I have put them in
octave/contrib/scripts/ode.  The whole CVS tree needs to be periodically
replaced since CVS does not allow you to move or remove directories.
We can move the ode directory when we redo the CVS tree if you want it
somewhere else.

IMHO, any files in the main tree (presently octave/scripts) should use
Octave style.  If you want your functions to work in Matlab then you
should either keep them out of the main tree (which is why I put them
in contrib), or write them in such a way that they can be automatically
converted to Matlab.  I have an oct2mat conversion script which does this,
but you have to be careful how you write your code.

Let me know what you want to do.

The consensus reached by the early adopters of octave.sf.net is the
directory structure presently in place.  I've made a counter-proposal
neither accepted nor rejected by the original team.  In the end, it
doesn't really matter so long as the (as yet non-existing) control files
build and install things correctly, and so long as it is clear where
new files should go.

Matcompat will disappear at the end of July, so you can ignore it.
All the code is at sourceforge, but it is not yet packaged in a form
that can be easily built and installed.  Hopefully it will be packaged
properly before matcompat disappears.

- Paul

On Wed, Jun 06, 2001 at 12:15:29AM -0500, Marc Compere wrote:
> dev,
> 
> 	Ok guys, I'm ready to learn how to maintain the octave ode solvers on 
> sourceforge.  I've read some earlier postings & seen the solvers in two 
> different places.  Before I attempt to barge in and dump them somewhere, I'd 
> like to get some input on where to put and maintain the ode solvers 
> directory.
> 
> 	I'm new to cvs but can figure it out easily enough I'm sure.  Just need to 
> know what the concensus is on a directory name (like ode_solvers) & whether 
> or not they should be incorporated into matcompat (then sourceforge) or if it 
> would be better to maintain them as their own "module" under ./octave.
> 
> 	Any tips? (Paul?)
> 
> Marc
> 
> 
> -- 
> _________________________________________________
>  Marc Compere, The University of Texas at Austin
>  Com...@as..., (512) 826-0729,   <><
>  http://nerdlab.me.utexas.edu/~compere
> _________________________________________________
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/lists/listinfo/octave-dev
> 

[OctDev] adding ode solvers to cvs

[Marc C. <Com...@as...>]

dev,

	Ok guys, I'm ready to learn how to maintain the octave ode solvers on 
sourceforge.  I've read some earlier postings & seen the solvers in two 
different places.  Before I attempt to barge in and dump them somewhere, I'd 
like to get some input on where to put and maintain the ode solvers 
directory.

	I'm new to cvs but can figure it out easily enough I'm sure.  Just need to 
know what the concensus is on a directory name (like ode_solvers) & whether 
or not they should be incorporated into matcompat (then sourceforge) or if it 
would be better to maintain them as their own "module" under ./octave.

	Any tips? (Paul?)

Marc


-- 
_________________________________________________
 Marc Compere, The University of Texas at Austin
 Com...@as..., (512) 826-0729,   <><
 http://nerdlab.me.utexas.edu/~compere
_________________________________________________

Re: [OctDev] Gui for Octave:- lets start designing it now.

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

There is a project called goctave which uses gtk-extras to add a spreadsheet
interface to Octave.  There is a project tkoctave which allows you to create
gui applications with Octave.  Which project do you want to contribute to?

By the way, tcl/tk is available on multiple platforms, so no reason to go
to Java for portability.

Paul Kienzle
pki...@ki...

On Tue, May 29, 2001 at 03:05:55PM +1000, Daniel Mann wrote:
> Hi,
> 
> In reference to the GUI for Octave, I recommend a java interface.
> 
> >From the number of complaints I have read from other people using octave, and
> my own experience with Octave vs Matlab, I dont think octave can remain a 
> relevant program for much longer (more than 1 or 2 more years) without some 
> major improvements in the User Interface.
> 
> Has anyone else begun creating a user interface, or have major design thoughts 
> on it. I have seen some murmurs of tlk / tck or something similar in the 
> archives. I think a platform independent interface such as java would be 
> preferable.
> 
> Or should i just charge blindly ahead with a very basic design document to be 
> posted to this group.?
> 
> lol.
> regards.
> Daniel Mann
> Researcher 
> CSIRO Manufacturing Science and Technology
> 
> As a mechatronics Phd student, I needed some scientific/engineering modelling 
> package. Although Matlab originally wanted to charge me us$4300 for the 
> package, after about a month I talked them into giving me a student license at 
> us$100, @ 2.2% of the cost. I was using octave during those months, and i can 
> see how some definite improvements can be made.
>  
> 
> 
> 
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> http://lists.sourceforge.net/lists/listinfo/octave-dev
> 

[OctDev] Gui for Octave:- lets start designing it now.

[Daniel M. <Dan...@cm...>]

Hi,

In reference to the GUI for Octave, I recommend a java interface.

From the number of complaints I have read from other people using octave, and
my own experience with Octave vs Matlab, I dont think octave can remain a 
relevant program for much longer (more than 1 or 2 more years) without some 
major improvements in the User Interface.

Has anyone else begun creating a user interface, or have major design thoughts 
on it. I have seen some murmurs of tlk / tck or something similar in the 
archives. I think a platform independent interface such as java would be 
preferable.

Or should i just charge blindly ahead with a very basic design document to be 
posted to this group.?

lol.
regards.
Daniel Mann
Researcher 
CSIRO Manufacturing Science and Technology

As a mechatronics Phd student, I needed some scientific/engineering modelling 
package. Although Matlab originally wanted to charge me us$4300 for the 
package, after about a month I talked them into giving me a student license at 
us$100, @ 2.2% of the cost. I was using octave during those months, and i can 
see how some definite improvements can be made.
 

[OctDev] Re: GUI for Octave programs.

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

> #  > 2) ...   Support for independent packaging is not appropriate at
> #  > the moment since the toolboxes are mostly tiny (except signal and
> #  > image) and enthusiasm is low.
> 
>   But dependencies between functions should be checked.

IMO, dependencies should be handled on a package basis.  That is,
the ODE toolbox might have a dependency on the optimization toolbox,
for example.  But, we don't try to figure out which specific
functions from optimization are needed by each ODE function.

At this point, there is only one package (until 5MB as Paul was
saying). 

Matt

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

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

  Hello

From: "Matthew W. Roberts" <ma...@ne...>

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

#  Well, it's not so much that I'm disheartened.  My Committee chair is
#  retiring in December and I'm trying to get my Dissertation cranked
#  out by then.

#  I've been forced to use Matlab, unfortunately, in my research
#  because of some of Octave's limitations with structures (can't save
#  them, can't have arrays of structures).  I was considering trying to
#  finish up `in absentia', but then I found out how much it would cost
#  to get a licensed version of Matlab.  Eeek!  Since then I've been
#  racking my brain trying to figure out a way to start a company based
#  on Octave.  From what I've seen with Eazel, Corel Linux, Stormix, et
#  al, I'm not sure an open source company can survive.

  What about charging some fee for installing and showing the how to
use octave to matlab-addicts (labs, universities). Maybe together w/
maintainance, technical assistance, consulting (for specialized
numerical needs). Your fee would easily beat matlab's bid and you
could contribute a fixed % to octave. I would be tempted by this kind
I scheme.

#  Thanks for your comments.  Some specific replies:

#  > 2) ...   Support for independent packaging is not appropriate at
#  > the moment since the toolboxes are mostly tiny (except signal and
#  > image) and enthusiasm is low.

  But dependencies between functions should be checked.

#  I agree.  However, we should still set up the directory structure
#  with packaging in mind.

#  > How about we put a hard limit of 5 Mb total main tree size before
#  > we worry about separate packaging?

#  Sounds good to me.

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

#  Definitely agree.

#  I like your directory structure.  The main tree is for additions to
#  the standard octave distribution, right?

#  --
#  Matthew W. Roberts


  Cheers, 

  Etienne

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

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

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

Well, it's not so much that I'm disheartened.  My Committee chair is
retiring in December and I'm trying to get my Dissertation cranked
out by then.

I've been forced to use Matlab, unfortunately, in my research
because of some of Octave's limitations with structures (can't save
them, can't have arrays of structures).  I was considering trying to
finish up `in absentia', but then I found out how much it would cost
to get a licensed version of Matlab.  Eeek!  Since then I've been
racking my brain trying to figure out a way to start a company based
on Octave.  From what I've seen with Eazel, Corel Linux, Stormix, et
al, I'm not sure an open source company can survive.

Thanks for your comments.  Some specific replies:

> 2) ...   Support for independent packaging is not appropriate at
> the moment since the toolboxes are mostly tiny (except signal and
> image) and enthusiasm is low.

I agree.  However, we should still set up the directory structure
with packaging in mind.

> How about we put a hard limit of 5 Mb total main tree size before
> we worry about separate packaging?

Sounds good to me.

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

Definitely agree.

I like your directory structure.  The main tree is for additions to
the standard octave distribution, right?

--
Matthew W. Roberts
------------------------------------------------------------------
Structural Engineering  *  Texas A&M University  *  ma...@ta...

Re: [OctDev] FW: Cell array support

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

I collected some patches in matcompat.  I don't know if it was worth the
trouble though.  I suppose it wouldn't hurt to create a new top level
directory /patches, just so long as nothing in main depends upon them.

	- Paul

On Tue, May 16, 2000 at 10:46:23PM -0400, Julian A. de Marchi, Ph.D wrote:
> I've been watching patches & usage tips float past it seems forever now.
> Do y'all not fancy we could compile these @SF in a way that's easier to
> use than troving through the octave.org mailing list archives?
> 
> Another unsolicited, obvious, back-seat remark from
> joolean
> 
> 
> -----Original Message-----
> From: oct...@be...
> [mailto:oct...@be...]On Behalf Of Jianming
> Sent: Thursday, May 17, 2001 6:47 AM
> To: Paul Kienzle; octave-sources
> Cc: John W. Eaton
> Subject: Re: Cell array support
> 
> 
> Hi,
>     Attached are the new patches for cell array support with octave
> (2.1.34). After experimenting with various implementations, I've taken most
> of your advices regarding the following:
>     1. Using () to access cell elements should not narrow down to the base
> type automatically. This will reduce confusion. I.E, narrowing conversion is
> removed.
>     2. Using ASSIGNANYOP in op-cell.cc
> 
>     Attached also is a sample session with the patch. Some comments on the
> (incomplete) patch:
> 
>     1. Some features with Paul mentioned in the previous email are missing:
>         a) {} producing multi-valued output
>         b) {} receive multi-valued output,
>         c) splice cell arrays into an argument list à la Matlab:
>     2. As shown in the sample session, assigning cell elements to an
> undefined indexed variable will give an error. To overcome this, cell(0,0)
> must be used first to "declare" the variable as a cell. There is no problem
> assigning cell elements to an undefined variable in it's entirety though.
>     3. Increasing the size of a cell array will not give unassigned elements
> as empty matrices as Matlab does. Instead, the undefined elements will have
> undefined type until assigned a value.
>     4. Removing elements from a cell is done using {} instead of []. This is
> simpler to implement. In fact, there is no need for any code for this. If we
> want to use [], I believe we have to delibrately check the type of the left
> hand side first. I don't really like this hack.
> 
>     Any comments, improvements are welcomed. Thanks Paul for your comments
> in the previous emails. I hope this gets into 2.1.35 together with some of
> your patches for cell functions.
> 
> Regards,
> Jianming







> octave:1> A(1,1) = {[1 4 3; 0 5 8; 7 2 9]};
> error: operator =: no conversion for assignment of `cell' to indexed `<unknown type>'
> error: evaluating assignment expression near line 1, column 8
> octave:1> A{1,1} = [1 4 3; 0 5 8; 7 2 9];
> error: A(I, J) = X: X must be a scalar or the number of elements in I must
> error: match the number of rows in X and the number of elements in J must
> error: match the number of columns in X
> error: evaluating assignment expression near line 1, column 8
> octave:1> A=cell(0,0);
> octave:2> A(1,1) = {[1 4 3; 0 5 8; 7 2 9]};
> octave:3> A{1,2} = 'Anne Smith'
> A =
> 
> {[1,1] =
> 
>   1  4  3
>   0  5  8
>   7  2  9
> 
> [1,2] = Anne Smith
> }
> 
> octave:4> A{2,2} = -pi:pi/10:pi
> A =
> 
> {[1,1] =
> 
>   1  4  3
>   0  5  8
>   7  2  9
> 
> [2,1] =
> 
> error: octave_base_value::print (): wrong type argument `<unknown type>'
> 
> [1,2] = Anne Smith
> [2,2] =
> 
>  Columns 1 through 8:
> 
>   -3.1416  -2.8274  -2.5133  -2.1991  -1.8850  -1.5708  -1.2566  -0.9425
> 
> 
>  Columns 9 through 16:
> 
>   -0.6283  -0.3142   0.0000   0.3142   0.6283   0.9425   1.2566   1.5708
> 
> 
>  Columns 17 through 21:
> 
>    1.8850   2.1991   2.5133   2.8274   3.1416
> 
> }
> 
> octave:5> C = {[1 2], [3 4]; [5 6], [7 8]}
> C =
> 
> {[1,1] =
> 
>   1  2
> 
> [2,1] =
> 
>   5  6
> 
> [1,2] =
> 
>   3  4
> 
> [2,2] =
> 
>   7  8
> 
> }
> 
> octave:6> C=A{1,1}
> C =
> 
>   1  4  3
>   0  5  8
>   7  2  9
> 
> octave:7> d=A{1,1}(2,2)
> d = 5
> 
> octave:8> A(1,:)
> ans =
> 
> {[1,1] =
> 
>   1  4  3
>   0  5  8
>   7  2  9
> 
> [1,2] = Anne Smith
> }
> 
> octave:9> A(2,:)=[]
> A =
> 
> {[1,1] =
> 
>   1  4  3
>   0  5  8
>   7  2  9
> 
> [2,1] = [](0x0)
> [1,2] = Anne Smith
> [2,2] = [](0x0)
> }
> 
> octave:10> A(2,:)={}
> A =
> 
> {[1,1] =
> 
>   1  4  3
>   0  5  8
>   7  2  9
> 
> [1,2] = Anne Smith
> }

[OctDev] FW: save file

[Julian A. de M. Ph.D <ju...@ma...>]

...and I should've said, bug reports too.  SF has a mechanism for
this that's a little more formal than email; maybe more useful to
keep track of things.

not trying to be facetious or anything, honest...
- JD

 

-----Original Message-----
From: hel...@be...
[mailto:hel...@be...]On Behalf Of Daniel
Heiserer
Sent: Thursday, May 17, 2001 3:04 AM
To: hel...@be...
Subject: bug: save file


Hi,
there is a problem with 2.1.34:

when I have a file descriptor:

fid=fopen('foo',w');

and your try to save the data using

save allstuff.mat

Then octaves issues an error because he doesn't know
how to save the type "file":

warning: save: wrong type argument `file'

reading the then stored data leads to an error:
 
error: load: failed to extract keyword specifying value type
error: load: reading file foo

-- dh



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------

[OctDev] FW: Cell array support

[Julian A. de M. Ph.D <ju...@ma...>]

I've been watching patches & usage tips float past it seems forever now.
Do y'all not fancy we could compile these @SF in a way that's easier to
use than troving through the octave.org mailing list archives?

Another unsolicited, obvious, back-seat remark from
joolean


-----Original Message-----
From: oct...@be...
[mailto:oct...@be...]On Behalf Of Jianming
Sent: Thursday, May 17, 2001 6:47 AM
To: Paul Kienzle; octave-sources
Cc: John W. Eaton
Subject: Re: Cell array support


Hi,
    Attached are the new patches for cell array support with octave
(2.1.34). After experimenting with various implementations, I've taken mo=
st
of your advices regarding the following:
    1. Using () to access cell elements should not narrow down to the bas=
e
type automatically. This will reduce confusion. I.E, narrowing conversion=
 is
removed.
    2. Using ASSIGNANYOP in op-cell.cc

    Attached also is a sample session with the patch. Some comments on th=
e
(incomplete) patch:

    1. Some features with Paul mentioned in the previous email are missin=
g:
        a) {} producing multi-valued output
        b) {} receive multi-valued output,
        c) splice cell arrays into an argument list =E0 la Matlab:
    2. As shown in the sample session, assigning cell elements to an
undefined indexed variable will give an error. To overcome this, cell(0,0=
)
must be used first to "declare" the variable as a cell. There is no probl=
em
assigning cell elements to an undefined variable in it's entirety though.
    3. Increasing the size of a cell array will not give unassigned eleme=
nts
as empty matrices as Matlab does. Instead, the undefined elements will ha=
ve
undefined type until assigned a value.
    4. Removing elements from a cell is done using {} instead of []. This=
 is
simpler to implement. In fact, there is no need for any code for this. If=
 we
want to use [], I believe we have to delibrately check the type of the le=
ft
hand side first. I don't really like this hack.

    Any comments, improvements are welcomed. Thanks Paul for your comment=
s
in the previous emails. I hope this gets into 2.1.35 together with some o=
f
your patches for cell functions.

Regards,
Jianming

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

[Julian A. de M. Ph.D <ju...@ma...>]

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.

>> I totally agree with you 100%. - Jules

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
> 

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

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

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...

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

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

On Tue, May 15, 2001 at 07:11:42PM -0400, Julian A. de Marchi, Ph.D wrote:
> Hey, what a crazy name you have (pronunciation please?)!
> 
> So...
> 
> re: the CVS, yes, it's a hairball and I brought that up with Paul K;
> partly it's a matter of where the matcompat (biggest/only upload so far)
> got situated.  My own feeling is that each "PROJECT" should have its own
> parent folder in the CVS.  So
> 
> 	/matcompat/...
> 	/tk_octave/...
> 
> for starters.  This should clear up any mess, at least from a high-level
> perspective it will keep any hairballs localised.  Let me see what the
> other devs thinks.

As you say, the only thing on the site is matcompat, it just happens to
be in /octave/... instead.  That suits me fine since many of the routines
are useful to the wider octave community, not just those who want to
run existing matlab code.

The confusion in the present tree has two sources.  One is the CVS
download instructions.  They should tell you how to grab the entire
tree rather than just a single "module".   The following seems to work:

  cvs -z3 -d:ext:dev...@cv...:/cvsroot/octave co .

The other source of confusion is that CVS does not control directory
structure, and does not allow you to remove empty directories.
Rearrangements to accomodate the first problem left vestiges of the old
organization and the confusing structure we have today.  

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.  This may need to be done periodically,
especially if routines are sucked off into the main Octave distribution
with any regularity.

Before putting the new tree is in place, feel free to rearrange the
/octave/... subdirectory.  I used the structure that was already in place
since changing it would have made the tree even more confusing.  I would
particularly like the numeric/nonnumeric distinction to go away, and have
the scripts tree be one level flatter.  I would also prefer all the parts
to a package together (scripts, dld, documentation, tests, demos, sample
data) rather than in separate trees, but the current organization is
closer to Octave's organization, so there are grounds for keeping things
as they are. 

> 
> re: JWE, yes, he's reluctant about anything GUI-related (he doesn't even
> use X-Windows, strictly a command-line dude as far as I know).  But as
> I said before, I think once the code carries its own weight any lead will
> naturally turn into gold.  There's still no FORMAL arrangement about
> pulling SF work into the main dist, but again I think that if the code
> proves itself it will happen one way or another.  JWE runs a tight ship.
> SF provides a popular means within the Octave community for parallel
> efforts, and is thereby popularly de-facto legit.  TCL/TK is the best
> proposition I've ever gleaned from the octave discussion archives on the
> GUI issue.

There is a strong argument for not moving code into Octave proper.
As long as OctaveSF contains useful routines people will continue to
use it and any new contributions will immediately have a wide audience.
If on the other hand you regular pick off the great and the good, then the
only people who will bother with it are the hard core developers of which
there are very few.  Also, once the code is in Octave proper it is harder
to maintain since all changes then have to be done through bug reports.
Whether or not those bug reports receive action depends on John's level
of interest.  

> 
> Let me know when you get your SF handles registered.  Be sure to check the
> SF HOW-TOs on CVS before you start uploading.
> 
> =jo...@us...
> 
> -----Original Message-----
> From: Przemek Klosowski [mailto:pr...@ja...]
> Sent: Tuesday, May 15, 2001 1:15 PM

<snip>

> John wasn't enthusiastic about Tcl as a vehicle for GUI building when I
> talked to him
> last, but I think it's an attractive proposition and I am looking forward to
> having
> people try it.

It strikes me as wasteful to invoke another interpreter for a different
language when we already have an interpreter available to us.  For one
thing, that requires your users to learn another language before being
able to develop their own GUI.  Is it feasible to control TK directly
from Octave and avoid any TCL?  Either way, your TK controls will need
to be able to trigger Octave callbacks, so it would be nice to cut out
the middle man.

Paul Kienzle
pki...@ki...

[OctDev] RE: GUI for Octave programs.

[Julian A. de M. Ph.D <ju...@ma...>]

Hey, what a crazy name you have (pronunciation please?)!

So...

re: the CVS, yes, it's a hairball and I brought that up with Paul K;
partly it's a matter of where the matcompat (biggest/only upload so far)
got situated.  My own feeling is that each "PROJECT" should have its own
parent folder in the CVS.  So

	/matcompat/...
	/tk_octave/...

for starters.  This should clear up any mess, at least from a high-level
perspective it will keep any hairballs localised.  Let me see what the
other devs thinks.

re: JWE, yes, he's reluctant about anything GUI-related (he doesn't even
use X-Windows, strictly a command-line dude as far as I know).  But as
I said before, I think once the code carries its own weight any lead will
naturally turn into gold.  There's still no FORMAL arrangement about
pulling SF work into the main dist, but again I think that if the code
proves itself it will happen one way or another.  JWE runs a tight ship.
SF provides a popular means within the Octave community for parallel
efforts, and is thereby popularly de-facto legit.  TCL/TK is the best
proposition I've ever gleaned from the octave discussion archives on the
GUI issue.

Let me know when you get your SF handles registered.  Be sure to check the
SF HOW-TOs on CVS before you start uploading.

=jo...@us...

-----Original Message-----
From: Przemek Klosowski [mailto:pr...@ja...]
Sent: Tuesday, May 15, 2001 1:15 PM
To: ju...@ma...
Cc: jo...@ja...; pr...@ja...
Subject: Re: GUI for Octave programs.


   You'd get full co-dev access to CVS etc.
   All code @ octave.sourceforge.net is meant for eventual absorption into
the
   main dist.  Details are actually being worked out, but generally folks
agree
   that candidate code ought first demonstrate its worth before
consideration.
   The SF site is the community-preferred place for doing so.  If it seems
scant
   right now that's only b/c we've just gotten it off the ground again
following
   a big hiatus on the part of the original SF folks (had to pry the
passcodes
   out of their hands! -- just kidding).

OK, we'd be honored to work with you. I understand that this is what we'd
be doing:

  export CVS_RSH=ssh
  cvs -z3 -d:ext:dev...@cv...:/cvsroot/octave co
modulename

after we get the accounts and passwords (we'd ask for 'przemek' and 'johnc').

I had a little trouble figuring out the layout of the CVS tree

   contrib                       dld
Attic  scripts       Attic contrib dld scripts
      civil ode            scripts     numeric
    Attic   Attic        civil ode     image
 (newmark)  (ode)                      Attic
                                       (colormaps)

and finally:

                                     octave
Attic Fixes contrib           dld           nodld   non-free        scripts
ver20
            scripts   au/grph/libo/mex/..                     nonnumeric
numeric

so I take it that the correct path for our stuff might be something like

	cvsroot/octave/octave/dld/tk_octave

unless you are planning to move things around there.

Is it possible to collapse the tree by pulling out stuff from under
cvsroot/octave/octave into
cvsroot/octave/{Attic,Fixes,...}

We asked Joao Cardoso, and he responded that he isn't planning to further
develop tk_octave
and basically gave us the permission to carry on with the development (we
have to sort out
if our changes didn't take away any functionality---if not, we agreed that he
will repoint
his own page to sourceforge).

   All code @ octave.sourceforge.net is meant for eventual absorption into
the
   main dist.  Details are actually being worked out, but generally folks
agree
   that candidate code ought first demonstrate its worth before
consideration.

What's the latest on JWE's plans---I take it that he's not planning to have
octave's
sources on sourceforge, but is willing to pull out the most popular pieces
off
octave.sourceforge.net into the mainline release; am I close?

John wasn't enthusiastic about Tcl as a vehicle for GUI building when I
talked to him
last, but I think it's an attractive proposition and I am looking forward to
having
people try it.

			przemek

[OctDev] Re: bug in __plt3__.m

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

On Sat, Apr 28, 2001 at 08:52:30AM +0000, Kai Habel wrote:
> I just noticed, that plot3.m doesn't work anymore. The problem is in 
> __plt3__.m where cx is not known. I had to add a line
> cx = columns(x)
> to make it work here locally. 

I was doing things rather in a panic to prepare for a talk mid-April.
Sorry!

Feel free to update my code on sourceforge as you see fit.  That's why
it is there.  

Note that I prefer to place the change notices in the files themselves
rather than the Changelog file one or two levels up the tree.  It makes
it easier to see how a particular function has changed, and it makes it
less likely that conflicts will need resolving on update.  The shared
Changelog almost guarantees conflicts on every update for an active
project.  If we use a standard yyyy-mm-dd numbered date format, then
we can generate the high level Changelog automatically with a simple
perl script.  Only thing we lose is the ability to tag changes across
several files with the same Changelog entry.

Also, the GPL requires the change notice in the file itself:

    2. a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

This only applies if you redistribute the file, not if you post the
changes back into the main distribution so Octave is not in breach of the
GPL.  Matcompat, and by extension octave.sourceforge, gathers files from
many sources, and many of them must be considered to be redistributed.
So rather than figuring out which ones need explicit change notices
in the file and which ones don't, let's just put the change notices
in the individual files and not think about it.

	- Paul

Re: [OctDev] matcompat added to sourceforge

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

Am Sonntag, 22. April 2001 08:58 schrieben Sie:
> Hi, all!
>
> I've finally added matcompat to sourceforge.  There is still a lot
> of work to be done to turn it into a product though.  In particular,
> the make files have to be constructed along with an install script.
> autoconf would be nice.  That way we can search for libraries like
> qhull and GiNaC, and if they are available, install the geometry or
> symbolic algebra interfaces.  Any volunteers?

Ok,

I'll bite. I will try to 'autoconfigure' the geometry package which uses the 
qhull library. But I have never used the autotools before, so I expect this 
takes some time. In the meantime we should use a 'simple' makefile, as you 
did in matcompat.
By the way there exists the book 'Autoconf, Automake, and Libtool' with a
Open Source licence. You can download it here:

http://sources.redhat.com/autobook/

> ....
>
> We also need to write test and demo scripts for each function.  I've got
> some already in a special comment form
>
> 	%!test
> 	%! blah
>
> 	%!demo
> 	%! blah
>
> which keeps them tightly coupled with the code, but we could also use
> the more conservative
>
> 	test_fn.m
> 	demo_fn.m
>
> Any preferences?

No, but I would leave it the way you are doing the tests.

Bye Kai

P.S. thanks for the fixes.

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

[OctDev] matcompat added to sourceforge

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

Hi, all!  

I've finally added matcompat to sourceforge.  There is still a lot
of work to be done to turn it into a product though.  In particular,
the make files have to be constructed along with an install script.
autoconf would be nice.  That way we can search for libraries like
qhull and GiNaC, and if they are available, install the geometry or
symbolic algebra interfaces.  Any volunteers?

I've added a top level README describing the directory structure.
I'm not convinced separating the dld's from the scripts is a good
idea, but that's the structure that Octave uses and that's what
was in place already, so that's what I've used.

I've added a TODO list at the toplevel as well.  I've put a few
function-specific items in there, but it would be better to distribute
those about the tree.  In the past I've used:

	## TODO: blah

but it would be better to use what Octave uses:

	## XXX FIXME XXX

There are a number of things that need to be done for all functions.  For
example, the function headers should all be using texinfo rather than
plain text.  And some unifying documentation is need saying how the
functions relate to each other.  Matcompat could get away without it
since matlab is well documented, but this is not matcompat.

We also need to write test and demo scripts for each function.  I've got
some already in a special comment form

	%!test
	%! blah

	%!demo
	%! blah

which keeps them tightly coupled with the code, but we could also use
the more conservative

	test_fn.m
	demo_fn.m

Any preferences?

Happy hacking!

Paul Kienzle
pki...@ki...

[OctDev] Re: Directory Structure

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

>   What are the claim of the Sourceforge Octave repository?I feel
>   it is caught between the Octave distro and individual
>   developers. How should a endish-user look at it?

Eventually I want the repository to provide Octave "toolkits" that
users can easily install on their system.

Another key part of the repository will be maintaining documentation
so that users will know how to use the toolkits, and find the one
that fits their needs.

> 
>   The official distro is stable and installs through 'make
>   install', or by installing a binary package. Functions are
>   accessible through the command line, doc through html/texi/ps. 
> 
>   This way of installing is simple to understand.

I like what Dirk Eddelbuettel has done with Octave on Debian/Linux.
Eventually, I want to have RPMs, DEBs, Win32 installers, etc. for
the "toolkits" to make installing and upgrading easy.

>   One possible claim could be : "Allow end-users to get a desired
>   functionality easily". Another could be "Provide links / archive
>   of all contributed octave development". Or is it something else?

My immediate goal is the second option, since that is the easiest.
I want to move gradually to the first option. 

--
Matthew W. Roberts
------------------------------------------------------------------
Structural Engineering  *  Texas A&M University  *  ma...@ta...

Re: [OctDev] Re: Directory Structure

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

  Hello,

From: "Matthew W. Roberts" <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.

  I was writing a paper lately and the first question was : "what are
the claims?" Once this is settled things are straightforward.

  What are the claim of the Sourceforge Octave repository?I feel it
is caught between the Octave distro and individual developers. How
should a endish-user look at it?

  The official distro is stable and installs through 'make install',
  or by installing a binary package. Functions are accessible through
  the command line, doc through html/texi/ps. 

  This way of installing is simple to understand.


  Individual developers produce extra m-files, .cc files, patches,
  usually without a Makefile or any installation procedure. In the
  best of case, the user just puts the m-files within his LOADPATH.
  Otherwise, he produces a .oct file and puts it within LOADPATH
  (right?).  Or else, patches the source octave tree and re-does "make
  install".

  This requires more work from the user.

  One possible claim could be : "Allow end-users to get a desired
functionality easily". Another could be "Provide links / archive of
all contributed octave development". Or is it something else?


  Cheers,


  Etienne

[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 priorities

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

Well, I guess it's time to start trying to get the repository moving
again. :)


Here's what I've done lately:

1) Cut a lot of the garbage and dated stuff out of the home page.

BTW, I found out that sourceforge has archives up now:

http://lists.sourceforge.net/archives/octave-dev/

It should help those of you (like me) who need to remember where the
development state is.

2) Started working on a perl script to allow "easy" browsing of the
CVS tree.  You can the see output here:

http://octave.sourceforge.net/afunclist.html

The script is in CVS now (cvs-tree).  One problem I had was robustly
extracting the "help" text from the script files.  If anyone has any
suggestions I'd appreciate it.

Also, as you can see, I did some very simple TeXinfo formatting,
just to make the descriptions readable.  I don't think trying to
write a perl Texinfo parser is the way to go.  Anyone have any ideas
how to translate the texinfo help into html text that could be used
in a script?

Lastly, I want to do more than just an alphabetical listing.  I'd
like to do some sort of categorizing.  My initial idea is to put
description files in each of the active directories.  The file
should be named the same thing in each directory.  Then I can walk
the CVS tree and build a nice "manual" with sections.  Thoughts?

Future Plans:

I'd like to upload it into CVS unless someone else wants to take that on.

Also, I'd like to start working on a Makefile.  I don't think I need
to go the autoconf route -- it seems we just need to have something
that will copy script files into the right directories.  Any ideas
how the configuration should work?

Thanks,  

--
Matthew W. Roberts
------------------------------------------------------------------
Structural Engineering  *  Texas A&M University  *  ma...@ta...