11:18 a.m.
Sven Schreiber schrieb:
> 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?
I noticed that the name can be freely chosen now, apparently.
> 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.
First round of test:
Everything worked as expected during (the first) packaging.
Running the function package produced the error "needs gretl 1.8.4" (I'm
running today's cvs); so I wanted to edit the package and tried lowering
the requirement to 1.8.3 (via the clickable number field" in the GUI).
But when I try to save the changed version, again I get the error
"function needs gretl 1.8.4". This looks like a bug to me.
(BTW, when I click "close" instead of "save", gretl asks "want to
save
the changes?", I click "yes" and gretl gives me the same error dialog,
but when I dismiss this error dialog, the package is closed
nevertheless, so I presume that any other changes that I might have made
would have been lost.)
So I start a new package to incorporate the lowered requirement. But --
gretl complains "no functions available for packaging". Ok, I did delete
the previous package (that had just failed) from my machine via gretl's
package management GUI, but the functions that I had run earlier in
order to make them available for packaging should still be available, no?
So I run the script with the functions again as a prelude to packaging.
This runs without error (well it just contains the functions, no actual
function calls). Then again I want to create a new package, but still
the same error, "no functions available".
In general my impression with the last couple of gretl versions has been
that errors of almost any kind seem to corrupt the function "namespace"
somehow. This does not seem to have been solved completely even now.
Don't get me wrong, I don't think it's a major issue, because the
packaging of functions is not a frequent task and so re-starting gretl
for that is bearable.
Ok, time to re-start gretl. Then running the script with the functions
and packaging works fine (and I remembered to change the requirement to
1.8.3). Saving & starting the package in the CWD works fine via GUI. The
expected results (printed output including ascii graphs and result
matrix) are produced ok.
However -- I open this function package again for editing, and add two
words to the help text. When I click "save" an error window pops up:
"data error". (BTW, all in German re-translated on the spot, hopefully
recognizable.) The same happens when I try to edit the package
description. And then --without deleting any package in between or
anything else-- when I try to create a new package I get the old message
"no functions available."
The "data error" thing also happens when I re-start gretl and then want
to edit a package. (Actually it seems that the old help text was deleted
by gretl after I tried extending it, because the field is empty now
after re-starting gretl and opening the package. Although it appeared
that gretl didn't want to allow an empty help text when I first created
the package.)
Bottom line: editing of existing packages currently still seems
impossible. But when the package is created ok it works fine.
I wonder whether it may be too ambitious to have this GUI thing for
packaging (as opposed to have a GUI for running the package, that's a
great feature). Package authors are probably scripting-savvy enough so
that they could be expected to prepare one special script with a special
package mark-up (like <helper-function-start> ... <helper-function-end>
or whatever, you get the picture), and when this marked-up script is run
a package is produced. Would that help in eradicating the bugs?
thanks,
sven