On Thu, 26 Apr 2007, Sven Schreiber wrote:
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
way you describe is worth your effort. People can play around with the
function packages, and documentation can be in the help texts or
Yes, but... If the interface is complex it can be difficult even
to start playing around without an example to refer to. Full
documentation is nice, but does not always get written ;-) A
sample is quite easy to produce, and people can use it as a
template for customizing.
> * 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
> road of trying to accommodate this, but I now think that was a
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.
Least work definitely means not attempting to provide full support
for versioned filenames!
> One symptom is the issue Sven mentioned, that if you upload a
> 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
Yes, I agree; that should be quite easy to arrange.
> Also, version numbers in the filename are redundant from a
> 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
Well, by that logic it's also redundant to name the gretl installer
Yes, it is redundant. The only reason I do that is so the
previous installers get archived on sourceforge, in case anyone
wants to backdate.
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
Yes, it does apply to packages on the server.
Yes I can live with that easily. (But please wait until I have
versions 0.9.2 of the py4gretl files.)
Fine, no hurry.
> * 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?
Urgh, I have to remind myself first!
Couldn't the name of the public interface function be completely
invisible to the package user...
Then you'd only be able to call them from the GUI, not from
scripts. I don't think we want that.