[OctDev] Re: octave-forge category index on sourceforge broken

[David Bateman<Dav...@mo...>]

Dapr=E8s Paul Kienzle <pki...@ja...> (le 28/03/2003):
> On Fri, Mar 28, 2003 at 10:55:57AM +0100, David Bateman wrote:
> > With one issue... I changed main/comm/INDEX to include operators (eg
> > "+ - =3D Addition and subtraction in a Galois Field.") and all of the
> > unimplemented Matlab functions. However, only the functions that are
> > either m-files or oct-files are referenced on the webpages. It howeve=
r
> > seems to have worked for the Signal Processing Toolbox. I imagine it
> > is something I have done wrong, but I can't see it...
>=20
> I'm not sure what you mean because it works for me now.

It does!!! Still doesn't from here....

> It might be that you were trying single character functions by themselv=
es.
> When it changed from:
>=20
>    /^\s+(\S+)\s*=3D\s*(\S.*\S)\s*$/
>=20
> to=20
>=20
>    /^\s+(\S.*\S)\s*=3D\s*(\S.*\S)\s*$/
>=20
> the following was no longer recognized:
>=20
>    ! =3D use system("command")
>=20
> This has now been fixed.

What I was trying to do was allow "fn fn =3D some test" to have two funct=
ions
referenced by the same text. It works for "make_index" in my directory, a=
nd
in fact still does, so I thought it would work for the webpages.

> BTW,  Should the categorical index show the latest release or the
> latest CVS?

For me its best if its the CVS so I can see any error I make that prevent=
ing
proper formating rapidly. Is it possible to build the webpages, other tha=
n on
sourceforge?

> There is still a problem with the index in that it does not
> handle overloaded functions.  For example,
>=20
> 	Galois Fields
> 	  ...
> 	  size =3D The size of a Galois array

In fact "size" isn't an overload, since the generic function can work. Th=
e
overloaded functions work fine with their specific name. Forinstance "gro=
ots"
is perfectly referenced.

The reason I wanted to include "size", etc, here was to emphasis that the=
se
functions work in Galois Fields.

> does not do anything since the note is ignored if a
> function by that name is documented.  I now say that the
> note is being ignored.=20

This explains some of the problems, but it doesn't explain why
"vitdec", etc aren't referenced as "not implemented" since these
are the only versions of these functions....

> What we should do is more=20
> complicated.  The category specific note should show
> up in the category list, but all notes should show up
> in the alphabetical list.  The current make_index
> data structures will not handle this so somebody with
> more time than me will have to work on this.

I'm the one who wants it, so I imagine this is a hint...


> There is also a potential issue with combined notes such as the followi=
ng:
>=20
> 	Galois Fields
> 	  ...
> 	  + - =3D Addition and subtraction in a Galois Field.
> 	  * / \ =3D Matrix multiplication and division of Galois arrays.
> 	  .* ./ .\ =3D Element by element multiplication and division of Galoi=
s arrays.
> 	  ** ^ =3D  Matrix exponentiation of Galois arrays.
> 	  .** .^ =3D Element by element matrix exponentiation of Galois arrays.
> 	  ' .' =3D Matrix transpose of Galois arrays.
> 	  =3D=3D ~=3D !=3D > >=3D < <=3D =3D Logical operators on Galois array=
s.

As I said, I made the change to make_index so this works if make_index
is run in a directory.

> All other type extensions (such as Symbolic and Sparse) will want to us=
e
> the same sets with the same spacing and ordering within the set since t=
he
> note is triggered off the entire string.  I don't think anything bad wi=
ll
> happen if the strings are different, so perhaps it won't be a problem.

I suggest that the notes are only in the category index and not the
alphabetically index. This is the case currently. The advantage is that
what you say above becomes a non-problem...

D.

--=20
David Bateman                                Dav...@mo...
Motorola CRM                                 +33 1 69 35 25 00 (Ph)
Espace Technologique, Commune de St Aubin    +33 1 69 35 25 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:=20

[x] General Business Information=20
[ ] Motorola Internal Use Only=20
[ ] Motorola Confidential Proprietary