I said I'd have gretl 1.8.4 out by now, but I found that fixing
problems with the user-function GUI led me further "down the
rabbit hole" than I expected.
I discovered quite a lot of code in lib/src/gretl_func.c, and also
in the associated GUI C files, that was partially duplicated
and/or not readily comprehensible, which may well count for the
"flakiness" that Sven mentioned.
I've therefore done a good deal of clean-up (plus addition of
comments) in those areas. I've also relaxed what I think was the
most awkward limitation in the function-package design up to gretl
1.8.3, namely the fact that a package could only have one public
interface. Now packages can contain as many public (and private)
functions as you like.
This is all good, but as with all new code it needs some testing.
So if anyone can find some time over the next few days to beat on
anything to do with editing or calling function packages, I'd be
very grateful. Then we'll get gretl 1.8.4 out.
Reminder: cleaned-up function packages for use with current CVS
gretl can be found at
http://www.wfu.edu/~cottrell/newgfn/
Two further comments:
* At present you define the list of functions belonging to a
package at the time of initial construction of the package; and
there's no way, in the GUI, to add or remove functions from a
package. I plan to remedy this before long, but probably not for
the 1.8.4 release.
* Now that packages can offer more than one public function
there's a potential ambiguity over the "Help text". I've resolved
this for now by locating the Help at the package level. That is,
suppose you have a package "sfa" that has public functions
"sfa_mod" and "sfa_hetmod" (I'm taking a possible reorganization
of Gordon Hughes's contribution as an example). In that case the
help text that you enter in the GUI package editor should cover
both functions. If the user does "help sfa_mod" or "help
sfa_hetmod", in either case they'll get a redirect to the help
text for the parent package.
Allin.