Re: [OctDev] allowing mex to pass in a help string?

[Dan M. <dan...@mc...>]

On Fri, Sep 10, 2004 at 12:38:04AM -0400, Paul Kienzle wrote:
> 
> On Sep 9, 2004, at 8:10 PM, Dan McMahill wrote:
> 
> >With matlab mex, I typically would do something like create
> >
> >myfn.c  -- the C-mex file
> >myfn.m  -- a matlab.m file which is only comments for the help output
> >
> >then when I do 'help myfn' in matlab I get the help text.
> >
> >With the octave mex interface it seems like I can sort of get there
> >by creating the .m file, but what I get for help output is
> >
> >type(file_in_loadpath('myfn.m'))
> >
> >If I execute that, I get the contents of myfn.m including the '%' 
> >comments
> >which means I can't just paste a multi-line example into octave.
> >
> >I guess I can use awk or sed to strip the leading '%' and have the .m
> >file really just be a text help file, but it would seem that it might 
> >be
> >nice to have a more automated way of getting the help to work.
> >
> >Any suggestions?
> >
> >I don't mind hacking on the mex script if thats whats needed.
> 
> Hacking the mex script is going to be the easiest.  I'm guessing
> you know what to do: if myfn.m exists when compiling a mex
> file, pipe it through sed to strip the comment characters and to
> add "\n\" to the end of every line, then put the output in place of
> the "type(file_in_loadpath" text in the cc-file that gets created.

I have a diff of mex (not mex.in) that seems to work.  I guess
there should probably be an autoconf check for awk and in particular
favor nawk over awk for systems such as solaris.

Had to jump through a few escaping hoops to get it to be reliable.

Should I make a patch against mex.in and file a bug report?

> Long term octave should be modified so that it includes mex.cc,
> and can load a precompiled mex file.  When it loads the myfun.mex,
> it can load myfn.m at the same time and populate  the docstring of
> the symbol.

I agree.

-Dan 

--