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 http://lists.wfu.edu/pipermail/gretl-devel/2009-August/002053.html 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 CVS/snapshot. 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 packages. 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 gretl 1.8.4. 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. Allin.