[Gretl-devel] weird list creation behavior in package GUI (model window context)

Hi all, sorry, this is going to be long and a bit involved. While working on a package, I encountered some weirdness when creating new gretl list objects off of a $model coming from a GUI model window after doing OLS. I do have a stripped-down package test.gfn which I'm attaching for illustration. * Technical aim here: Inside the GUI function (here: GUI_uniFCboot) which is run from the Analysis menu of the OLS model window, I want to look at the regressors $model.xlist and I want to focus only on those terms that are exogenous (not lagged endogenous, and also not the constant). * Example: 1) Install somewhere the test.gfn package, attach it to the menu, load the denmark dataset, and in the GUI regress LRM on IBO, const, and two own lags. 2) Go to the new menu entry Analysis/testtesttest, choose horizon=2 (but that shouldn't matter) and hit OK. 3) I get my debug printout: "We shouldn't have any lags remaining in here: IBO,LRM_1,LRM_2", which obviously *does* contain the LRM lags. * Background: In the function, I'm trying to create a sub-list by doing (where 'mod' is a copy of $model): list Lexo = mod.xlist - lags(mod.maxlag, mod.ylist) - const # all but endo-lags and const and then I'm printing out varname(Lexo), with the result above. Now I can theoretically imagine some reasons why my approach doesn't work, related to the list ID numbers inside bundles and functions and so on. * HOWEVER, the real weirdness comes when I add/uncomment the following lines right before the Lexo creation, namely: bundle br = rhslags($model) # especially this line seems to make a difference #  although it shouldn't! print br.ylagnames (The package version with these lines active is enclosed as test2.gfn.) -- And then everything works, i.e., there aren't any lagged endogenous terms left in the subsequent Lexo creation; result: "We shouldn't have any lags remaining in here: IBO" ! The point here is that the call to the private function rhslags() should be completely redundant and without any effect, shouldn't it? The return bundle br isn't used here, and there are no pointers involved. Instead it magically makes it so that everything falls into place, at least in this example. What's behind all this? Some gretl bug? Or just further mystery with bundled series and lists? And concretely, how can I successfully remove from $model.xlist the lag terms in this context without doing black magic? This is with gretl 2025a on Windows 11. thanks a lot for reading until the end sven