Sorry, this is a bit long, but hopefully it will be of interest to
people writing or using gretl function packages. The question of
how to encourage submission of user-contributed functions was one
thing that occupied a fair amount of our time at the 2009 gretl
conference in Bilbao (for which, many thanks to Ignacio
Diaz-Emparanza and Petr Mariel!) so I think this is important.
I'm very grateful to Sven for pointing out a serious bug in the
GUI for calling user-defined functions, in
After that came up I undertook a thorough overhaul of the GUI for
calling functions and also the GUI for working with function
packages, and I've now (in CVS and the snapshots for Windows and
OS X) fixed a large number of issues.
Some of the fixes relate to bugs that were introduced since the
function-package GUI was first written, and that have somehow
passed unnoticed, but many of them relate to things that were not
worked out properly when that interface was initially developed,
and that have just "sat there" ever since.
Anyway, I hope that these fixes (which will of course be in gretl
1.8.4, out soon) will make life more agreeable for anyone trying
to work with function packages. And if anyone's working in that
area right now, I'd strongly advise updating to current
A few things that might not be immediately apparent:
* When you open the window displaying function packages on the
local machine, you should see a directory icon in the toolbar.
If you click on that you can select a directory from which to load
function files. In the past the behavior here has been to load
any _additional_ function files from the chosen directory (not
already found in other places). Now you have the option of
replacing the currently-shown file listing. So if you have a
special directory containing development versions of packages that
you're working on, you can restrict the function-package listing
to just those files.
* You can now do "gretl -p /path/to/gfnfile" on the command line,
to open a specified function package for editing on start-up.
Alternative syntax is "gretl --pkg=/path/to/gfnfile". Give the
full path to the .gfn file.
* If you're updating a package, you can right-click in the package
Date field to get a popup which lets you insert the current date.
As another part of this overhaul I've done something I should have
done a long time ago, namely check carefully all the existing .gfn
package files on the gretl server. I have fixed several of these
and have added sample scripts for most of the cases where these
were missing (but see below). I have also written a test rig
which lets me extract the sample scripts from all packages and
test them for breakage. In some cases my fixes will require gretl
1.8.4, so I won't upload the revised gfn files to the server until
version 1.8.4 is released (as I said, should be soon).
Please note: the Document Type Definition for gfn (gretl function)
packages requires that a sample script be provided. Up till now,
packages that were contributed before this requirement was
introduced have been exempt ("grandfathered", as they say in the
States). But no more. Even with the best intent, documentation
can be a bit obscure, and having a working example to hand is
often the key for a user to get started using a function of
interest; so I think we should enforce this requirement for all
As I mentioned, I've added sample scripts for the simpler
functions. Naturally, it's the more complex (and interesting)
packages that have given me trouble; I'm less sure of what an
adequate example would look like. I'd be very grateful if Ignacio
could add a sample function for the LLTestim package, and if
Gordon Hughes could add one for the sfa_hetmod package. Feel free
to email me samples and I'll add them to the revised packages for
Looking to the future, there are some other things we discussed in
Bilbao that I haven't got to yet, but will start on once gretl
1.8.4 is out. That is, we'd like for gretl function packages to
have these options that are not currently available:
* Include more than one "public interface". (Right now each
package can include only one function that's publicly available.)
* Include properly typeset documentation (i.e. LaTeX -> PDF). (At
present we only support plain text documentation.)
* Include an example dataset, in case no suitable dataset can be
found among those that we distribute with gretl.
* Include more than one example script, if desired.
I have some ideas about how we can add these things without
breaking backward compatibility, but it will take some time to
work those ideas out properly.