tobithetm.gfn 1 robust_RESET.gfn 1

For package authors: here's a listing of deprecation warnings produced by packages currently on the server. If you can find time to update your package(s) that would be much appreciated! Note that the warning for using '=' as an equality test is very explicit so it should be easy to find the location in the code. * Missing "include" in sample script: DHF_test.gfn plot_scatter_label.gfn * Use of "catch" on calls to user-defined functions (generates a warning, really should be an error by now): coint2rec.gfn GHegy.gfn * Use of '=' as test for equality (count of warnings from running sample script): ADFGLSTest.gfn 2 a_eff.gfn 34425 armax.gfn 9 bartlett.gfn 10 BMA.gfn 18000 BreitungCandelonTest.gfn 2 BSMestim.gfn 359 buys_ballot.gfn 1 Canova_Hansen.gfn 2 carr.gfn 49 cffilt.gfn 1 coint2rec.gfn 7 DiebMar.gfn 11 DIF_panelcoint.gfn 1003 dynMultipl.gfn 1 genr_dates.gfn 7 getQuandl.gfn 45 GJR-garchm.gfn 69 hetero.gfn 2 lagreg.gfn 12109 levene.gfn 2 LLTestim.gfn 427 margeff_el.gfn 13872 MGARCH.gfn 5 mwu.gfn 1 Robinson.gfn 1 robust_RESET.gfn 1 RVNR.gfn 2 SB.gfn 200 SETAR.gfn 50 sfa_mod.gfn 9 ShapleyCont.gfn 1 sparse.gfn 102 StrucBreak.gfn 1 summary_xy.gfn 191 tobithetm.gfn 1 tramolin.gfn 1 var_chow.gfn 2 VARrec.gfn 1 waldTest.gfn 26 Wilcoxon.gfn 1 Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Am 10.02.2017 um 16:18 schrieb Allin Cottrell: > For package authors: here's a listing of deprecation warnings produced > by packages currently on the server. If you can find time to update your > package(s) that would be much appreciated! > > Note that the warning for using '=' as an equality test is very explicit > so it should be easy to find the location in the code. The list is much longer than expected... Seriously, I don't think a message to gretl-devel is enough. We have to use the email adresses given in the packages, too.

Also, I think we should offer a little more support. A script that catches and perhaps even autocorrects the most common occurrences for example. As Oleh indicated, a "=" in the same line as an "if" for example can only mean "==" I think (right?). (... outside of a foreign block, that is....)

> * Use of "catch" on calls to user-defined functions > (generates a warning, really should be an error by now): > coint2rec.gfn OK, this one concerns me myself. What again was the suggested alternative? Re-write the function to provide an error code?

On Fri, 10 Feb 2017, Allin Cottrell wrote: > On Fri, 10 Feb 2017, Sven Schreiber wrote: > >> Also, I think we should offer a little more support. A script that catches >> and perhaps even autocorrects the most common occurrences for example. As >> Oleh indicated, a "=" in the same line as an "if" for example can only >> mean "==" I think (right?). (... outside of a foreign block, that is....) > > The hansl parser knows what cases need fixing, but it doesn't have the > facility to change its input (or at least not so the change will be saved). > Hmm, may be worth investigating though. Having now looked into this, the answer's Sorry, no, far too complicated. The human brain and eyeball are the best tools for the job. There were huge warning counts for some packages, but that's because of iteration...

On Fri, 10 Feb 2017, Allin Cottrell wrote: > On Fri, 10 Feb 2017, Sven Schreiber wrote: > >> Also, I think we should offer a little more support. A script >> that catches and perhaps even autocorrects the most common >> occurrences for example. As Oleh indicated, a "=" in the same >> line as an "if" for example can only mean "==" I think (right?). >> (... outside of a foreign block, that is....) > > The hansl parser knows what cases need fixing, but it doesn't > have the facility to change its input (or at least not so the > change will be saved). Hmm, may be worth investigating though. Having now looked into this, the answer's Sorry, no, far too complicated.

On Sun, 12 Feb 2017, Allin Cottrell wrote: > I'm therefore in a position to auto-correct the packages that are affected, > but I don't want to tread on anyone's toes. If you're the author of a > package noted at > > http://lists.wfu.edu/pipermail/gretl-devel/2017-February/007411.html > > and you haven't already fixed your package(s), and you want to do that > yourself (that is, you do _not_ want to have auto-correction applied), > please let me know. I believe the version of MGARCH I uploaded a few days ago sould be ok.

Have you checked the addons too (gig, ivpanel, SVAR)?

On Mon, 13 Feb 2017, Allin Cottrell wrote: >> Have you checked the addons too (gig, ivpanel, SVAR)? > > There are a few instances to be fixed in gig, HIP and SVAR; they seem to be > caught correctly by the auto-checker as applied to the source .inp files > (but note that fixeq.c has been updated to handle plain hansl at > https://sourceforge.net/projects/gretl/files/misc/ ). > > I could commit the fixes if you like, or if you'd prefer to do it that's > fine. No, it's ok, I can see to it.

On Fri, 10 Feb 2017, Allin Cottrell wrote: > On Fri, 10 Feb 2017, Allin Cottrell wrote: > >> On Fri, 10 Feb 2017, Sven Schreiber wrote: >> >>> Also, I think we should offer a little more support. A script that >>> catches and perhaps even autocorrects the most common occurrences >>> for example. As Oleh indicated, a "=" in the same line as an "if" >>> for example can only mean "==" I think (right?). (... outside of a >>> foreign block, that is....) >> >> The hansl parser knows what cases need fixing, but it doesn't have >> the facility to change its input (or at least not so the change will >> be saved). Hmm, may be worth investigating though. > > Having now looked into this, the answer's Sorry, no, far too complicated. I gave up too soon. A fully rigorous checker would indeed be too complicated, but all we really need is a program armed with sufficient heuristics to catch all the problems with existing gfn files, and it turns out that wasn't too hard to write. There's source code and binaries for Windows and Mac at https://sourceforge.net/projects/gretl/files/misc/ where you can also find a README that describes the program. In my testing, this catches all the issues with current packages, with no false positives or false negatives. I'm therefore in a position to auto-correct the packages that are affected, but I don't want to tread on anyone's toes. If you're the author of a package noted at http://lists.wfu.edu/pipermail/gretl-devel/2017-February/007411.html and you haven't already fixed your package(s), and you want to do that yourself (that is, you do _not_ want to have auto-correction applied), please let me know. Just to be clear: auto-correction would involve: * replacing "=" with "==" wherever the latter is correct; * incrementing the package version by the minimal increment; * setting the package date to the current date; and * nothing else. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

For package authors: here's a listing of deprecation warnings produced by packages currently on the server. If you can find time to update your package(s) that would be much appreciated!