3:33 p.m.
Allin Cottrell schrieb:
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.)
I'm planning to do that after py4gretl has become reasonably stable.
Since I'm using it myself at least from time to time, that shouldn't
take too long.
Actually, I don't think extending the capabilities of .gfn files in the
way you describe is worth your effort. People can play around with the
function packages, and documentation can be in the help texts or
elsewhere online.
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.
Ok with me! It just seemed to me that gretl could only execute packages
that were packaged by itself or that it downloaded from the server. But
since that is not the case, all is well.
* Version numbers embedded in gfn filenames. I started along the
road of trying to accommodate this, but I now think that was a
mistake.
I'm still not entirely convinced that that's true, but I think the best
way to proceed is to do what causes you the least amount of work.
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.
Yes; however, I do think that the old versions should be archived
somewhere. Imagine somebody relies on a package for serious work. Now
the author accidentally uploads a new version which breaks everything.
In a worst-case scenario, even the author herself does not have a backup
of the old working version. All users of that package would be doomed,
and some of them will blame gretl for it... So maybe the function
package files on the server could somehow be automatically inserted into
the CVS repository as well?
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.]
Well, by that logic it's also redundant to name the gretl installer
gretl-1.6.2.exe... But your solution is nice (haven't seen it yet). Does
it also apply to the dialog showing the packages on the server (IMHO it
should)?
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.
Yes I can live with that easily. (But please wait until I have uploaded
versions 0.9.2 of the py4gretl files.)
* 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.
Can you remind me again why the names should match? Couldn't the name of
the public interface function be completely invisible to the package
user, and then it wouldn't matter what it would be called?
thanks,
sven