Re: [OctDev] Re: email not getting through

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

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=20
you have to first configure octave-forge with the packages "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=20
"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 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, you=
r
build process will have to take this into account when finding the versio=
n
of mkoctfile to be used. It can't just do "system('mkoctfile <file>')", b=
ut
rather must reference the version of mkoctfile with an absolute path, tha=
t
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=20
> with an install.m file?
>=20
> Supporting functions would, for example, be
>=20
> add_toolbox(id, description)
> add_category(id, description, parent_toolbox)
> add_function([category1 category2 ...])
> rebuild()
>=20
> The install.m file can then be renamed to <package>-install.m and=20
> stored in a directory -- needed for rebuilding the index from scratch=20
> later on.
>=20
> Every time a function is added the appropriate toolbox contents.m shoul=
d=20
> be rebuilt, using the descriptions extracted by an octave function.=20
> What is the current level of regular expression support?  With regular=20
> expressions this problem becomes a lot simpler.
>=20
> Comments and ideas?
>=20
> Regards
> St=E9fan
>=20
> 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 havin=
g
> >>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 .=
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=
=20
> >>maximum entropy model).
> >>## arch_fit     - Fit an ARCH regression model to the time series Y=20
> >>using the scoring algorithm in Engle's original ARCH paper.
> >>## arch_rnd     - Simulate an ARCH sequence of length T with AR=20
> >>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=20
> >>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=20
> >>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 f=
or
> >>>dispatched functions.
> >>>
> >>>Are you still interested?
> >>>
> >>>My rule lately has been to not do anything too sophisticated otherwi=
se
> >>>nothing ever gets done.  At least that's my excuse for not fixing th=
e
> >>>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 fo=
r
> >>>that type, or if dispatch('name','new','type') returned the old
> >>>dispatch function for that type.
> >>>
> >>>- Paul
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From 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)=20
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)=20
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