Ensure OpenMx is the package associated with MxRAMModel objects about openmx HOT 18 CLOSED

I'm reopening this issue, because I think I finally have a fix for it. Today, I read the R Internals manual, concerning S4 classes (plus another document to which the manual links). Based on what it said, I began to suspect that this issue is caused by MxRAMModels never being initialize()d as instances of that class. Instead, they are only ever initialize()d as instances of the base class, "MxModel". Then, what happens to turn them into MxRAMModels is that a function called by mxModel() uses class()<- to change their class to "MxRAMModel" per the value of mxModel() argument type. That does not suffice to give them the "package" attribute, set to "OpenMx"; that's because S4 classes are defined within the context of a package, whereas the end user's R script can use class()<- to change an object's class arbitrarily (even to an undefined class!).

As a proof of concept, I attach summary.MxRAMModel.diff.txt, which is a git diff relative to 7ebcc10 . If I rebuild OpenMx after making the changes reflected in the diff, I can run loadtest--181129.R, save R's workspace, restart R, and load the saved workspace, and OpenMx is automatically loaded into R's workspace with it. That is the current behavior for objects of class "MxModel", but that is new behavior for objects of class "MxRAMModel". I'm running R in RStudio, FYI.

For reference, this is the forums thread about this issue: https://openmx.ssri.psu.edu/thread/4199 .

from openmx.

The changes reflected in that diff are just proof-of-concept. The actual implementation of the bug-fix will have to be less crude. We should probably discuss it at a meeting. And we should implement analogous changes for MxLISRELModels, too.

from openmx.

Wow, Rob, accolades to your tenacity on solving this one!

from openmx.

I'm going to close this issue. We can reopen it if it turns out my fix doesn't work.

from openmx.

FYI, teaching a class, about 5/50 people had this error last week. It seemed to have something to do with package order. Went away with reinstall package, restart R.

from openmx.

No idea how to reproduce this or whether it's even an OpenMx problem. Closing until we receive a better bug report.

from openmx.

I wonder if this issue is worth revisiting in light of thread 4311?

from openmx.

from openmx.

But upgrading didn't resolve the issue. What did was krzysiek re-running his MxModels anew, instead of loading them from a saved workspace.

from openmx.

Should we revisit this issue? It's still tripping users up.

from openmx.

from openmx.

from openmx.

from openmx.

N.B. that we DO warn the user if s/he is running an MxModel that was created with a version of OpenMx different from the one currently loaded. See line 72 in R/MxModel.R and line 21 in R/MxRun.R .

from openmx.

@jpritikin Thanks!

from openmx.

Oh, ba80a3f , for Pete's sake! Can it be that the bug-fix that has eluded us all this time IS A SINGLE LINE OF CODE?!

Fingers crossed that travis and the nightly run both pass.

Edit: well, travis failed, but that wasn't my fault.

from openmx.

If class() is allowed to change the class identifier of an object to an arbitrary string, then it's allowed to change the class identifier of an object into a string with an arbitrary attribute: https://openmx.ssri.psu.edu/comment/8122#comment-8122

from openmx.

Well, it looks like the fix for this issue was much simpler than I thought. Contrary to my initial suspicion, it's not actually necessary for objects of class "MxRAMModel" to be initialize()d as such, and unlike the diff I posted upthread, implementing the repair required only one line of code.

The nightly run passed all tests. Could someone please independently verify that it works? You should be able to build R from the head of the master branch, run loadtest--181129.R, let it save R's workspace, restart R, load the saved workspace, and see OpenMx get automatically loaded into R's workspace with it.

Once someone confirms that it works, this issue can be closed.

from openmx.