Re: [Gretl-devel] more function package news
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 of
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?
This is all good, but as with all new code it needs some testing.
So if anyone can find some time over the next few days to beat on
anything to do with editing or calling function packages, I'd be
very grateful. Then we'll get gretl 1.8.4 out.
I think I will have time to test some of these things until tomorrow.
...
* 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
high priority.
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.
thanks,
sven