[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OctDev] listing functions in a package
From: |
David Bateman |
Subject: |
Re: [OctDev] listing functions in a package |
Date: |
Tue, 19 Feb 2008 16:00:13 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070914) |
c. wrote:
>
> After thinking about this for a while I believe that parsing the INDEX
> file is still the way to go...
> The INDEX file is optional, if it is not there it is generated
> automatically by scanning the package directory,
> so there are two cases:
>
> 1) The package developer didn't bother to write an INDEX, his package
> is just a set of functions that he believes do not need to be
> organized into categories or distinguished one from the other.
>
> in this case the package directory is scanned for a list of functions
> at the time of install (or rebuild) so to get the list of functions
> one can parse the INDEX. If the INDEX is missing or corrupted throw an
> error prompting the user to run 'pkg rebuild'
>
> 2) The package developer chose to list only some specific functions in
> the INDEX file and to organize them into categories. In this case I
> think the choice of which functions deserve to be listed should be
> left to the package developer ( non indexed functions may be just for
> internal use for example), so again parsing the INDEX should be the
> correct way to get the list of functions.
>
> The attached patch solves the issue with the hiccup on 'pkg describe
> signal' and implements the behavior described above (which is that
> intended in the previous version).
>
> What do you think about this?
> c.
>
This is looking good, however I have one issue with it. The signal INDEX
file contains the following snippet
signal >> Signal processing
Signals
diric
gauspuls
gmonopuls
However the diric function etc end up classified into an "Unclassified"
section rather than a "Signals" section. I therefore think that there is
still a slight error in your parsing code.. How robust is the parsing
code? Have you tested it on other octave-forge packages?
Regards
David
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
- listing functions in a package, Carlo de Falco, 2008/02/14
- listing functions in a package, c., 2008/02/14
- Re: listing functions in a package, Søren Hauberg, 2008/02/15
- Re: listing functions in a package, David Bateman, 2008/02/15
- Re: listing functions in a package, c., 2008/02/18
- Re: listing functions in a package, David Bateman, 2008/02/18
- Re: listing functions in a package, c., 2008/02/18
- Re: [OctDev] listing functions in a package, David Bateman, 2008/02/18
- Re: [OctDev] listing functions in a package, c., 2008/02/19
- Re: [OctDev] listing functions in a package,
David Bateman <=
- Re: [OctDev] listing functions in a package, c., 2008/02/19
- Re: [OctDev] listing functions in a package, John W. Eaton, 2008/02/19
- Re: [OctDev] listing functions in a package, c., 2008/02/19
- Re: [OctDev] listing functions in a package, John W. Eaton, 2008/02/19
- Re: [OctDev] listing functions in a package, c., 2008/02/19
- Re: [OctDev] listing functions in a package, John W. Eaton, 2008/02/19
- Re: [OctDev] listing functions in a package, David Bateman, 2008/02/19
- Re: [OctDev] listing functions in a package, John W. Eaton, 2008/02/19
- Re: [OctDev] listing functions in a package, c., 2008/02/19
- Re: [OctDev] listing functions in a package, c., 2008/02/19