I'm puzzled by the fact that the sample script of the LocalProjection package produces an error "invalid option --time-series". And indeed that option is appended to a "plot" command, which is not supported as per the doc. However, the package was moderated in August, and I'm assuming that the sample script ran fine at that time. So, has something changed in gretl since then? (Either 2024a, or 2023c, or post-2024a.) Or actually, I tend to think that it still worked around March or so.

Am 08.05.2024 um 19:49 schrieb Cottrell, Allin: > On Wed, May 8, 2024 at 11:32 AM Sven Schreiber > <sven.schreiber(a)fu-berlin.de&gt; wrote: >> I'm puzzled by the fact that the sample script of the LocalProjection >> package produces an error "invalid option --time-series". And indeed >> that option is appended to a "plot" command, which is not supported as >> per the doc. >> >> However, the package was moderated in August, and I'm assuming that the >> sample script ran fine at that time. So, has something changed in gretl >> since then? (Either 2024a, or 2023c, or post-2024a.) Or actually, I tend >> to think that it still worked around March or so. > Yes, it stopped working after March 29. > > I've checked all the gfns, and LocalProjection is the only one to > append an option to the first line of a plot block. I can't find any > that attach options to "end plot" other than the ones that are > officially recognized for that context. I don't think that we should > add a workaround for the usage in LocalProjection. Agreed, this needs to be fixed in the package. However, from the timeline of the release of gretl 2024a on April 5th, it would mean that the package should have failed already in the run-up to the release. My question then is, why didn't we notice? I thought it's a standard part of the testing parcours to check the sample scripts of all packages.

You're right. I'm afraid there was a testing failure in this case. All the gfns had been tested probably a day before the March 29 change, and at the time it didn't seem that anything "significant" had changed between then and the April 5 release. But that's a risky assumption, and not one I'll make in future. Obviously, it would be good if I were not the only person testing all the gfns' sample scripts in the run-up to a release. It is not difficult to setup automatically to run the tests. We have the

Am 09.05.24 um 02:20 schrieb Cottrell, Allin: > Thanks, Helio. What you reference via the link below is my "personal" > collection of test scripts (which has evolved since then). Of course > anyone is welcome to run these tests, but I haven't made a serious > effort to make them portable for others.

> > But what Sven and I were talking about is a bit different: it's an > apparatus for downloading all the current publicly-available gretl > function packages (.gfn or .zip files) from sourceforge, and checking > that the "sample script" inside each of the packages runs > successfully. Any failures on this test will (or should!) > automatically hold up a planned gretl release until they're fixed. > > This apparatus can be found at > https://sourceforge.net/p/gretl/workspace/ci/master/tree/testgfn/ i'll > be happy to try answering any questions you may have.

it would be useful, if we could also automatically run those sample scripts via github-actions each time a new commit gets pushed. @Helio: Do you think, you have time to set this up on github? I could assist you if you need any help.

Am 09.05.24 um 12:08 schrieb Sven Schreiber: > Am 09.05.2024 um 11:34 schrieb Artur T.: >> Am 09.05.24 um 02:20 schrieb Cottrell, Allin: >>> Thanks, Helio. What you reference via the link below is my "personal" >>> collection of test scripts (which has evolved since then). Of course >>> anyone is welcome to run these tests, but I haven't made a serious >>> effort to make them portable for others. > Weren't those test scripts integrated into the git source tree in the > meantime? Specifically, what does /unittests contain? (Not to be > confused with /tests !) In the gretl source, to be more concrete under ./gretl/unittest one can find a collection of -- as the name says -- unit-test for gretl-built functions and commands. In the workspace under ./gretl-workspace/testgfn you can find a mechanism to download and run sample scripts. And then there exists ./gretl/tests. But I don't know anything about this. Artur >>> But what Sven and I were talking about is a bit different: it's an >>> apparatus for downloading all the current publicly-available gretl >>> function packages (.gfn or .zip files) from sourceforge, and checking >>> that the "sample script" inside each of the packages runs >>> successfully. Any failures on this test will (or should!) >>> automatically hold up a planned gretl release until they're fixed. >>> >>> This apparatus can be found at >>> https://sourceforge.net/p/gretl/workspace/ci/master/tree/testgfn/ i'll >>> be happy to try answering any questions you may have. > Not sure whether the workspace is open for everybody. Hélio, if you run > into problems while accessing it, please tell us. >> >> >> it would be useful, if we could also automatically run those sample >> scripts via github-actions each time a new commit gets pushed. >> >> @Helio: Do you think, you have time to set this up on github? I could >> assist you if you need any help. > > Yes, it would be great if this could be automated, so this would be very > welcome. However, I would suggest not to trigger it on every commit, for > reasons of sustainability and energy savings. Maybe once per day would > be enough. Not sure if this can be set up this way. Needs to be checked. Usually, you develop on a dev-branch, and you run the whole test-suit when or before pushing to master. Artur _______________________________________________ Gretl-devel mailing list -- gretl-devel(a)gretlml.univpm.it To unsubscribe send an email to gretl-devel-leave(a)gretlml.univpm.it Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/

No, my collection of test scripts is not in git. As Artur says, "unittests" contains just unit tests, not full-scale scripts. With the unit tests, the point is to check that they don't fail, and that assertions are satisfied. In my script collection, the results are all stored and compared, so one can also see if there's been any change in the output relative to a "known good" baseline.