Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failure to unload cleanly ("could not find superclass mMatrix") #16

Closed
bbolker opened this issue Nov 21, 2012 · 7 comments
Closed

failure to unload cleanly ("could not find superclass mMatrix") #16

bbolker opened this issue Nov 21, 2012 · 7 comments

Comments

@bbolker
Copy link
Member

bbolker commented Nov 21, 2012

library(lme4); detach("package:lme4",unload=TRUE) produces

Warning message:
In .removeSuperclassBackRefs(cl, cldef, searchWhere) :
could not find superclass "mMatrix" to clean up when removing subclass references to class "lmList.confint"

@bbolker
Copy link
Member Author

bbolker commented Nov 22, 2012

It looks very much like this is an exporting issue in Matrix: adding "mMatrix" to the exportClass in Matrix's NAMESPACE file appears to solve the problem.

@mmaechler
Copy link
Member

Hmm,
that (exporting it) would not be a nice thing.

It is defined as

setClassUnion("mMatrix", members = c("matrix", "Matrix"))

and I really only want to use it define methods and such things for the
class.
It should not be user visible in principle. That's why I did not export it
on purpose.

Hmm..

On Thu, Nov 22, 2012 at 10:18 PM, Ben Bolker notifications@github.comwrote:

It looks very much like this is an exporting issue in Matrix: adding
"mMatrix" to the exportClass in Matrix's NAMESPACE file appears to solve
the problem.


Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-10645232.

@RossBoylan
Copy link

I'm not sure if this error is the cause, but it seems the DLL is still in use after the unload. When I try to install a new version the old one gets deleted except for the DLL and installation fails. It's possible this is simply general behavior of R, or R under emacs/ess.

I had the version from CRAN loaded. R version 2.15.2 (2012-10-26)
Platform: i386-w64-mingw32/i386 (32-bit) (windows 7)

detach("package:lme4", unload=TRUE)
Warning message:
In .removeSuperclassBackRefs(cl, cldef, searchWhere) :
could not find superclass "mMatrix" to clean up when removing subclass references to class "lmList.confint"
install.packages("lme4",repos=c("http://r-forge.r-project.org", getOption("repos")))
Installing package(s) into 'c:/Users/rdboylan/Documents/R/R-2.15.2/site-library'
(as 'lib' is unspecified)
trying URL 'http://cran.cnr.berkeley.edu/bin/windows/contrib/2.15/lme4_0.999999-0.zip'
Content type 'application/zip' length 1422897 bytes (1.4 Mb)
opened URL
downloaded 1.4 Mb

package 'lme4' successfully unpacked and MD5 sums checked
Warning: cannot remove prior installation of package 'lme4'

@mmaechler
Copy link
Member

Ben Bolker notifications@github.com
on Thu, 22 Nov 2012 13:18:26 -0800 writes:

> It looks very much like this is an exporting issue in
> `Matrix`: adding `"mMatrix"` to the `exportClass` in
> Matrix's `NAMESPACE ` file appears to solve the problem.

Yes, but that is not a bug, it has not been the intent of the
Matrix authors: Rather, the intent had been to have 'mMatrix' be
a "private class".
If we'd export it, we'd have to document it, etc, and their's no
strong reason for all that.

I think I remember that John Chambers never liked the idea of
"private classes" when the whole
NAMESPACE <--> S4
had been discussed "back then".

But I agree the current situation is unpleasant.

  • you cannot unload the Matrix namespace as lme4 depends on it
  • you cannot unload lme4 cleanly, because of the above.

To me, at the moment, it seems a rather a bug in R:
It should not barf when 'mMatrix' is not found in that way, but
it should rather ``search better'' (i.e. find 'mMatrix' hidden
in Matrix name space).

Patches to R are welcome .. (;-)
Martin

@bbolker
Copy link
Member Author

bbolker commented Mar 1, 2013

I'm at the very edge of my competence here, so I don't think I'm going to be able to supply a patch to R. What are the chances that John Chambers could be brought into this conversation and that the problem could be identified clearly enough that he would take a shot at fixing it?

If not ... I can see the "solutions" (neither satisfactory) as

  1. violating your principles, exporting mMatrix and making a stub documentation page for it
  2. living with the error message (and documenting it somewhere in the lme4 help pages)

Are we sure that this failure to unload has no potential harmful consequences beyond the one identified here (inability to properly unload the DLL)?

@bbolker
Copy link
Member Author

bbolker commented May 10, 2013

this may ?? be fixed in R 3.0.+? I don't see it with R Under development (unstable) (2013-04-25 r62670), Matrix 1.0-12 ...

@bbolker
Copy link
Member Author

bbolker commented May 22, 2013

no longer reproducible by me (R 3.0.1 under MacOS, R (2013-05-22 r62774) under Linux), so I'm going to assume the underlying issue got fixed and close this.

@bbolker bbolker closed this as completed May 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants