octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementation of convn


From: John W. Eaton
Subject: Re: Implementation of convn
Date: Mon, 24 Mar 2008 17:56:59 -0400

On 24-Mar-2008, Søren Hauberg wrote:

| man, 24 03 2008 kl. 16:27 -0400, skrev John W. Eaton:
| > Will you please update according to the following comments and submit
| > this as an hg changeset?
| 
| Sure. In which directories do you want the files to be placed?

I suppose it should go with conv.m in scripts/polynomial.

| > Currently we have a mixture of styles for these, so maybe they should
| > all be fixed to be consistent.
| 
| Don't we have "private" directories now? I would think all __functions__
| should be moved to "private" directories.

We could do that for .m files relatively easily, though it would
require some changes to the Makefiles (and possibly the layout of the
sources).

But doing this for .oct files is not as easy.  The rule for functions
in private directories is that they are only visible to the functions
in the parent directory.  But generally all .oct files live in the
same architecture dependent directory tree, separate from the
architecture independent .m files.  For example,

  /usr/share/octave/3.0.0/m/polynomial
  /usr/lib/octave/3.0.0/oct/x86_64-pc-linux-gnu

If you put your convn.m file in /usr/share/octave/3.0.0/m/polynomial,
functions that are "private" for it belong in

  /usr/share/octave/3.0.0/m/polynomial/private

but that is is an architecture independent directory, so it is not the
right place for a .oct file.

I don't see a good solution for this problem.

| If we do this, then it would
| probably be nice for developers if __functions__ are documented as
| well.

Developers know how to use the source, and since they are usually
internal helper functions, developers are generally not using them
very often anyway.  I'd rather not encourage the use of internal
functions, so I think doc strings should not contain anything more
than argument lists.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]