[Gretl-devel] Belated response to Sven on function packages

Allin Cottrell cottrell at wfu.edu
Thu Apr 26 13:51:40 EDT 2007


Before I try responding to the list of small bugs that has 
appeared on gretl-users, I'd like to come back on some points that 
Sven raised earlier, regarding function packages.

First of all, py4gretl is very cool!  Thanks for making this 
available.  One request: I think it would be very helpful if you 
could put up a few examples of use of the py4gretl functions.  (I 
have this is mind, though it's not yet implemented: allow for a 
.gfn file to contain a complete, runnable sample script.)

Now, on a few design issues.  

* Should we have a standard File Open dialog that allows you to 
open .gfn files from anywhere in the filesystem?  On reflection, 
No, that would likely be confusing for most users.  Unlike regular 
.inp files, .gfn files are supposed to be special.  There are two 
authorized locations for such files: @gretldir/functions and 
@userdir/functions.  If you want to be able to open such a file, 
then put it, copy it, or symlink it into one of those locations.

* Version numbers embedded in gfn filenames.  I started along the 
road of trying to accommodate this, but I now think that was a 
mistake.  

One symptom is the issue Sven mentioned, that if you upload a new 
version of a package to the server, the old one will still hang
around, if it has a different filename, and you can't delete the 
old one.  What's supposed to happen is that when you post an 
update the old file is automatically overwritten, which will 
happen if they have the same name.

Also, version numbers in the filename are redundant from a user's 
point of view (the version is recorded inside the file), and they 
take up space unneccessarily in the function package dialog 
window. [To make the redundancy point more persuasive, I've now 
modified the dialog so that it shows the version number beside the 
name.]

I can see that from the point of view of a function package 
developer, it's convenient to have versioned filenames.  My 
suggestion would be: keep the files with the versioned names in a 
separate directory, and symlink the one you want to use currently 
into @userdir/functions

@userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn

If this sounds reasonable, I can rename the py4gretl files on the 
server accordingly.  

* Which functions appear as available for packaging in gretl? I 
haven't had time to check this fully, but here's what's _supposed_ 
to happen when you load function package P:

- P's public interface (which should have the same name as the 
package) will _not_ appear as packageable.  That's intentional: 
it's already packaged and shouldn't appear as the public interface 
of any other package.

- If there's at least one "free" function available for packaging,
then any helper functions inside P should be available: helper 
function are supposed to be reusable.

- How do you make "free" functions available?  For example, put 
them into an .inp file and run it.

- If you really want to "cannibalize" a package -- that is, steal 
its public interface and use it to make another package, then
you'll have to do some copying and pasting.  Copy the code out of 
the code-editing window in the function packager and paste it into 
an .inp file.  Re-start gretl; load and run the .inp file.

Allin.






More information about the Gretl-devel mailing list