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
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
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
@userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn
If this sounds reasonable, I can rename the py4gretl files on the
* 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.