On Wed, 26 Aug 2009, Sven Schreiber wrote:
Allin Cottrell schrieb:
> I said I'd have gretl 1.8.4 out by now, but I found that fixing
> problems with the user-function GUI led me further "down the
> rabbit hole" than I expected.
> I discovered quite a lot of code in lib/src/gretl_func.c, and also
> in the associated GUI C files, that was partially duplicated
> and/or not readily comprehensible, which may well count for the
> "flakiness" that Sven mentioned.
let's hope for the best!
> I've therefore done a good deal of clean-up (plus addition
> comments) in those areas. I've also relaxed what I think was the
> most awkward limitation in the function-package design up to gretl
> 1.8.3, namely the fact that a package could only have one public
> interface. Now packages can contain as many public (and private)
> functions as you like.
what about the package name then? It used to be that the file name had
to match the name of the public function. (Which I always found mildly
annoying, but could live with.) what's the situation now?
That limitation is gone. Here's the current situation: for a new
package, the package name is derived from the filename, which must
meet certain criteria. The basename must start with a letter,
contain nothing but ASCII letters, numerals (preferably not), and
the underscore character; and it must be less than 32 characters
in length. It also must have suffix ".gfn".
> * At present you define the list of functions belonging to a
> package at the time of initial construction of the package; and
> there's no way, in the GUI, to add or remove functions from a
> package. I plan to remedy this before long, but probably not for
> the 1.8.4 release.
Actually I dont think this is a big problem. You can always export an
existing package to a flat script and then start a new package by adding
or removing some components. So personally I wouldn't give this feature
I agree, you can do that. But since we have a GUI editor it might
as well be properly functional. Adding or deleting interfaces is
something you may want to do when working on a complex package and
it's a bit of a pain to have to shuttle back and forth between
package-form and script-form.
I think this is also related to the problem of versioning of the
packages on the public server: suppose there's a package written
and uploaded by author A, and used in productive work by user U.
Then author A develops the package further and uploads the new
version to the server, superseding the old one. (Or is the old
version kept on the server parallel to the new one, I don't know
right now?) And user U suddenly is presented with new
interfaces, different APIs and possibly new bugs etc. etc. I
think this problem has to be taken into account if you want to
promote the use of packages.
Yes, I agree this is something we'll have to think about.