[OctDev] Re: email not getting through

[Stefan v. d. W. <st...@su...>]

If we add enough supporting functions, each package can be distributed 
with an install.m file?

Supporting functions would, for example, be

add_toolbox(id, description)
add_category(id, description, parent_toolbox)
add_function([category1 category2 ...])
rebuild()

The install.m file can then be renamed to <package>-install.m and 
stored in a directory -- needed for rebuilding the index from scratch 
later on.

Every time a function is added the appropriate toolbox contents.m should 
be rebuilt, using the descriptions extracted by an octave function. 
What is the current level of regular expression support?  With regular 
expressions this problem becomes a lot simpler.

Comments and ideas?

Regards
Stéfan

Paul Kienzle wrote:
> 
> Here are some features that I consider important:
> 
> (1) distributed description --- adding a package to the system
> should automatically update the indices to reflect the presence
> of that package.   E.g., adding octave forge should add a number
> of functions to Octave's existing string categories, amongst others.
> An install=time step is sufficient --- it doesn't need to happen
> every time a directory is added to the path, though it's okay if it
> does so.  A single function can belong to multiple subcategories in
> different toolboxes.
> 
> (2) easy syntax --- it is hard to get more minimal than the INDEX
> file format that make_index is using.
> 
> (3) minimal tools --- you cannot require python on user
> systems.   For developer systems, the fewer languages
> required the better.  I guess beating Octave's string
> handling into shape so that it is up to the task itself is a bit
> too ambitious.
> 
> (4) multiple output targets, including matlab-style contents.m.
> 
> I'm sure there's others, but not that I can think of tonight.
> 
> - Paul
> 
> 
> On Jun 1, 2004, at 12:20 PM, Stefan van der Walt wrote:
> 
>> Hi Paul
>>
>> I started working on this today.  Wrote a python script similar in
>> functionality to make_index. It uses octave to provide the function
>> descriptions, however -- which means that you can build indeces having
>> only a binary distribution available.
>>
>> An example config file looks like this:
>>
>> ---
>>
>> octave = "/usr/share/octave/2.1.57/m"
>> forge = "/usr/share/octave/2.1.57/site/m/octave-forge/"
>>
>> signal {
>>   name = "Signal Processing Toolbox"
>>   add_dirs = "signal"
>>   add_files = "ifft ifft2"
>>   unsupported = "nosup neithersup"
>>   sub = "numeric"
>> }
>>
>> numeric {
>>   name = "Numerical Games"
>>   add_dirs = "blah"
>> }
>>
>> ---
>>
>> It scans all the directories specified in "add_dirs" directives for .m
>> files and then queries octave for their descriptions, doing some
>> gung-ho parsing to take care of all the different comment formats out
>> there.
>>
>> The generated file signal.m can be generated (note: I havn't included
>> any sub-categories here):
>>
>> ##
>> ## Signal Processing Toolbox
>> ##
>> ## arburg       - fits an AR (p)-model using Burg method (a so called 
>> maximum entropy model).
>> ## arch_fit     - Fit an ARCH regression model to the time series Y 
>> using the scoring algorithm in Engle's original ARCH paper.
>> ## arch_rnd     - Simulate an ARCH sequence of length T with AR 
>> coefficients B and CH coefficients A.
>> ## arch_test    - For a linear regression model
>> ## arma_rnd     - Return a simulation of the ARMA model
>> ## aryule       - fits an AR (p)-model with Yule-Walker estimates.
>> ## autocor      - Return the autocorrelations from lag 0 to H of 
>> vector X.
>> .
>> .
>> .
>> ## zplane       - Plot the poles and zeros.
>> ##
>> ## Unsupported functions:
>> ##
>> ## nosup
>> ## neithersup
>> ##
>>
>> It would also be easy to factor this out into a module so that only
>> the front-end changes with every other method of presentation.  This
>> way you can generate a web page index, category descriptions like
>> signal.m or anything else you want in any format.
>>
>> If the generated category descriptions are in the loadpath, calling
>> "help signal" should do the job.  It will be trivial to generate a
>> toolbox.m for "help toolbox" to get a list of all toolboxes.
>>
>> Also, a toolbox can "contain" any other toolbox.  You can, for
>> example, make an image processing toolbox and include the signal 
>> processing
>> toolbox if you so wish.
>>
>> Is this going in the right direction?  If not, I would appreciate a
>> few pointers!
>>
>> I attach the scripts.
>>
>> Regards
>> Stefan
>>
>> On Sun, May 30, 2004 at 12:00:46AM -0400, Paul Kienzle wrote:
>>
>>> Stefan,
>>>
>>> I've extended dispatch() so that even functions called with no
>>> parameters can be dispatched so octave-forge could now provide
>>> categorical help independent of octave if we so choose.
>>>
>>> There's a small caveat in that dispatch already dispatches on help, so
>>> we need to remove it and call our own
>>>
>>>     ##PKG_ADD: dispatch('help','string')
>>>     ##PKG_ADD: dispatch('help','cathelp','any')
>>>     function cathelp(varargin)
>>>       ...
>>>       dispatch_help(pars{:})
>>>
>>> The call to dispatch_help at the end in order to fill in base help for
>>> dispatched functions.
>>>
>>> Are you still interested?
>>>
>>> My rule lately has been to not do anything too sophisticated otherwise
>>> nothing ever gets done.  At least that's my excuse for not fixing the
>>> problem I just noticed in dispatch which is that dispatches can't
>>> chain.  You could
>>> fake it if dispatch('name','type') returned the dispatch function for
>>> that type, or if dispatch('name','new','type') returned the old
>>> dispatch function for that type.
>>>
>>> - Paul