[Gretl-users] recent gretl fixes

Here's an account of some recent fixes in the gretl code base. Some of the issues addressed below were reported on one or other of the gretl lists; some just came up in internal discussion. The bugs in question are somewhat obscure and hopefully will not bite many gretl users. Anyway, they're now fixed in git and the snapshots for Windows and Mac. * Behavior of the int() function (which returns the integer part of its argument): this was producing strange-looking output when fed an argument outside of the range of 32-bit signed integers, namely [-2147483648, 2147483647]. Now it returns NA in that case, which seems reasonable since the return value is supposed to be exactly equal to an "int", which generally means a 32-bit signed integer. * The "print" command, when applied to gretl's $error accessor, was always showing 0 regardless of the error state associated with the last command. Now "print $error" maps internally to "eval $error" and produces the correct value. * The "var", "vecm" and "system" commands all provide a $system bundle following estimation. In the var/vecm case this bundle included the limits of the sample range at estimation time, under the keys "sample_t1" and "sample_t2", but after "system" these elements were not present. Now they're included in all cases. * A bug pertaining to the use of the "catch" modifier in a loop crept in between the 2022b and 2022c releases of gretl. The effect was that on the second and subsequent iterations of the loop "catch" would not work as intended (would fail to block an error) -- unless, oddly enough, "catch" had to deal with an error condition on the first iteration, in which case it would work correctly thereafter. -- Allin Cottrell Department of Economics Wake Forest University