Re: [OctDev] Re: email not getting through

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

David,

I think rebuild() is referring just to rebuilding the doc tie-ins.

Keep it simple for now (adding just categorical help to
octave-forge), but leave room for growth into independent
packages which can be built from source.

- Paul

On Jun 2, 2004, at 5:12 AM, David Bateman wrote:

> Stefan,
>
> If I get this right your function "rebuild()" would build the =
oct-files
> in a particular package? At the moment this is rather complex, since
> you have to first configure octave-forge with the packages=20
> "configure.add"
> taken into account, then build the oct-files.
>
> One advantage you'll have running from within octave is that you'll
> have access to a number of built-in variables with lots of the
> necessary information. You might also like to have a support function
> "configure()" that does something similar to the current octave-forge
> configure.base autoconf code, then calls a toolbox specific configure
> function, and then finally writes out a file that the build process
> can find (perhaps Makeconf).
>
> One problem I see that you'll have is a case like mine where I have=20
> three
> versions of octave installed. At the moment I have
>
> /usr/bin/octave                (2.1.57)
> /opt/octave/bin/octave         (CVS)
> /opt/octave-2.1.50/bin/octave  (2.1.50)
>
> In general I have the /usr/bin/octave first in my path, and if I want
> to work with the CVS I call /opt/octave/bin/octave directly. However,=20=

> your
> build process will have to take this into account when finding the=20
> version
> of mkoctfile to be used. It can't just do "system('mkoctfile=20
> <file>')", but
> rather must reference the version of mkoctfile with an absolute path,=20=

> that
> it must find out somehow..
>
> Regards
> David
>
>
>
> According to Stefan van der Walt <st...@su...> (on 06/02/04):
>> 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=20
>> 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=E9fan
>>
>> 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=3Dtime 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=20
>>>> having
>>>> only a binary distribution available.
>>>>
>>>> An example config file looks like this:
>>>>
>>>> ---
>>>>
>>>> octave =3D "/usr/share/octave/2.1.57/m"
>>>> forge =3D "/usr/share/octave/2.1.57/site/m/octave-forge/"
>>>>
>>>> signal {
>>>>  name =3D "Signal Processing Toolbox"
>>>>  add_dirs =3D "signal"
>>>>  add_files =3D "ifft ifft2"
>>>>  unsupported =3D "nosup neithersup"
>>>>  sub =3D "numeric"
>>>> }
>>>>
>>>> numeric {
>>>>  name =3D "Numerical Games"
>>>>  add_dirs =3D "blah"
>>>> }
>>>>
>>>> ---
>>>>
>>>> It scans all the directories specified in "add_dirs" directives for=20=

>>>> .m
>>>> files and then queries octave for their descriptions, doing some
>>>> gung-ho parsing to take care of all the different comment formats=20=

>>>> out
>>>> there.
>>>>
>>>> The generated file signal.m can be generated (note: I havn't=20
>>>> included
>>>> any sub-categories here):
>>>>
>>>> ##
>>>> ## Signal Processing Toolbox
>>>> ##
>>>> ## arburg       - fits an AR (p)-model using Burg method (a so=20
>>>> 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=20
>>>>> 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=20=

>>>>> for
>>>>> dispatched functions.
>>>>>
>>>>> Are you still interested?
>>>>>
>>>>> My rule lately has been to not do anything too sophisticated=20
>>>>> otherwise
>>>>> nothing ever gets done.  At least that's my excuse for not fixing=20=

>>>>> 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=20=

>>>>> for
>>>>> that type, or if dispatch('name','new','type') returned the old
>>>>> dispatch function for that type.
>>>>>
>>>>> - Paul
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the new InstallShield X.
>>> =46rom Windows to Linux, servers to mobile, InstallShield X is the =
one
>> installation-authoring solution that does it all. Learn more and
>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>> _______________________________________________
>> Octave-dev mailing list
>> Oct...@li...
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>
> --=20
> David Bateman                                =
Dav...@mo...
> Motorola CRM                                 +33 1 69 35 48 04 (Ph)
> Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
> 91193 Gif-Sur-Yvette FRANCE
>
> The information contained in this communication has been classified =
as:
>
> [x] General Business Information
> [ ] Motorola Internal Use Only
> [ ] Motorola Confidential Proprietary
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> =46rom Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>