We have a report from a user on a change in 1.2.0 of the behavior, when registering a distribution, of checking for an existing "r" function. In 1.2.0, if an object exists in the userEnv with the "r" name corresponding to the "d" name being registered, it must be a nimbleFunction and valid to serve as the "r" function. Thus, if the "r" name exists but has value NULL, we throw an error in 1.2.0. It appears that previously this did not throw an error.
reprex:
rCust <- NULL # if this line is removed, the error below does not occur
dCust <- nimbleFunction(run=function(x=double(), log=integer(0,default=0)) {return(0);returnType(double())})
# next line results in error, only if rCust<-NULL above and only in nimble=1.2.0 (just released)
m <- nimbleModel(nimbleCode({x ~ dCust()}))
The new behavior makes sense, but it can break old code (as a user reported).
Given this, it seems possible there are other subtle changes from nuances of changes in error-trapping behavior in the re-written distribution processing.
Adding additional context after first note: If one defines dCust and then calls nimbleModel both from inside a function, in package code, and then needs to do something with rCust (e.g. move it to the global environment before calling compileNimble) CRAN's checks (static code analysis, I believe) will flag that rCust is accessed without having been created.
We have a report from a user on a change in 1.2.0 of the behavior, when registering a distribution, of checking for an existing "r" function. In 1.2.0, if an object exists in the
userEnvwith the "r" name corresponding to the "d" name being registered, it must be a nimbleFunction and valid to serve as the "r" function. Thus, if the "r" name exists but has valueNULL, we throw an error in 1.2.0. It appears that previously this did not throw an error.reprex:
The new behavior makes sense, but it can break old code (as a user reported).
Given this, it seems possible there are other subtle changes from nuances of changes in error-trapping behavior in the re-written distribution processing.
Adding additional context after first note: If one defines dCust and then calls nimbleModel both from inside a function, in package code, and then needs to do something with rCust (e.g. move it to the global environment before calling compileNimble) CRAN's checks (static code analysis, I believe) will flag that rCust is accessed without having been created.