Hi, there's a feature request about a certain type of diagnostic test (see https://sourceforge.net/p/gretl/feature-requests/97/). This message here isn't about this specific request or test, but about a design issue in relation to function packages. It is fairly easy to implement such a test as a function package, but I have "meta request" or suggestion for an interface that would provide a tighter integration and better user experience. AFAICS, if a new diagnostic test such as "newtest" is implemented as a contributed function (and package) 'newtest()', then the use would be as follows: <current> include newtest.gfn ols y 0 x # estimate the model to be tested matrix testresult = newtest($uhat, $xlist, <other needed input>) </current> There's at least two things that bother me here: First the usage is completely different from gretl's built-in "modtest" command. Secondly the user needs to know exactly what arguments the 'newtest()' function needs. This complicates things. Re the first issue, my suggestion is to extend the "modtest" command to also apply to installed function packages. So if gretl finds a "modtest --newtest" line, it would realize that there's no built-in option "--newtest", and then instead of throwing an error right away, it would check whether there's an installed function package "newtest.gfn". And if that's the case, it would execute newtest(...). As a follow-up issue, because "modtest" provides results in the accessors $pvalue and $test (AFAIK), the newtest() function would also be required to return that, presumably wrapped in a bundle. And gretl would make sure that these return values are then copied to the outer-scope $pvalue and $test accessors. Secondly, because "modtest --newtest" wouldn't pass any arguments to the newtest() function explicitly, I think the convention should be that it is invoked as "newtest($modbundle)", where "$modbundle" would be a new accessor that is just a bundle of all the other $-accessors that are made available by gretl after estimating a model. BTW, this automatic $modbundle after estimation would be good irrespective of the specific case of the "modtest" command. OK, I hope I've made myself clear. I know you're all on vacation and this is a lenghty post, but it isn't urgent, just a pretty radical suggestion for the future. thanks, sven