octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Writing 'help' functions as m-files


From: David Bateman
Subject: Re: Writing 'help' functions as m-files
Date: Thu, 27 Mar 2008 11:11:16 +0100
User-agent: Thunderbird 2.0.0.12 (X11/20080306)

Søren Hauberg wrote:
> Yet Another mail from the "Brain Farting Department"... (YABF?)
>   A couple of days ago I started wondering why the help system is
> written in C++ rather then as a set of m-files. Since the help system is
> only used interactively (i.e. not part of any "real" calculations), I
> doubt that speed is the issue.
>   
To support mex-files Octave can have the help text in an m-file and the
function implementation in C or C++ already..

>   I would think that if the following function were available it would
> be fairly simple to write the help system as m-files:
>   
> "get_help_text": given a function name, return the corresponding (raw)
> help text as a string.
>   
This function already exists in Octave (cf src/help.cc) and I wrote the
C++ DLD_DEFUN to get the help text a few years back. See

http://sourceforge.net/mailarchive/message.php?msg_id=20040603104208.GC30468%40zfr01-2089.crm.mot.com

However it doesn't maintain the texinfo, but uses the parsed stream, so
this might not be the best... Otherwise the help code was reorganised
when the lookfor function was added and so if the function

std::string raw_help (const std::string& nm, bool &symbol_found);

in help.cc was also declared in help.h, you might use it to extract the
raw help string.. In any case as this function is not static you might
include the above declaration and just use in the an oct-file without
any modification to Octave (except on windows as it lacks the OCTAVE_API
macro and so isn't exported).

> Let me just tell why I started to think about this. To build the
> Octave-Forge web pages we have a bunch of scripts written in various
> languages. One of the many things these scripts do is to extract help
> texts from each function, such that we can generate a corresponding web
> page. The fact that we have our own implementation of this extraction is
> IMHO a bad thing, since it duplicates the implementation in the help
> system. Things would be more simple if we had the above-mentioned
> "get_help_string" function in Octave. Also, doesn't the 'munge-texi'
> program in 'doc/interpreter' reimplement this functionality as well?
>   
Parsing the DOCSTRING files will be faster than getting Octave to give
us the help text, so I'm not sure this is a bad thing.. The build of
octave-forge wbe-pages takes a significant amount of time and anything
that slows it up will be a bad thing..

D.




> Søren
>
>
>
>   


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]