[R-sig-ME] installing lme4 and Matrix; getME() in lme4_0.999375-42

[Martin Maechler]

>>>>> Douglas Bates <bates at stat.wisc.edu>
>>>>>     on Mon, 3 Oct 2011 11:25:14 -0500 writes:

    > On Mon, Oct 3, 2011 at 11:10 AM, Yvonnick Noel
    > <yvonnick.noel at free.fr> wrote:
    >> Hello,

    >> I note there is a problem compiling the Matrix and lme4
    >> packages on R-Forge for R-devel (2.14).

    > Which platform?  The Windows platform reports a problem
    > with R-devel (which is now R-2.14.0 (alpha)) but that
    > doesn't appear to be a problem with the package but rather
    > a problem with permissions on their build machine.

    > I'll try the latest SVN versions on Win-builder but I
    > don't think there are problems with the packages.  If they
    > compile and pass their tests on
    > Win-builder.R-forge.R-project.org I'll check with Ben
    > about updating the versions on the archive at
    > lme4.r-forge.r-project.org/repos

Both of these showed now problem on Windows, when Doug submitted
them to Winbuilder.  So he's been right on spot: The problem is
with "Windows build and check on R-forge".

Note that we have released Matrix_1.0-0 to CRAN yesterday,
and -- as source package -- it has been available for ~ 17 hours
now. It will be part of the recommended packages in R 2.14.0
For windows, I'm pretty sure, Matrix_1.0-0 is currently being
built with its many hundreds of dependent packages,
and maybe the city temperature in Dortmund is increasing
measurably because of the CPUs running hot in those servers.

Further, we have also released the R-forge version of lme4,
  0.999375-42 , to CRAN
 (this is *not* "the next version of lme4", but an update of "good ole' lme4"!)
with the notable addition of a function  getME()
which  *the* extractor function for M[ixed] E[ffects],
to be used in lme4() instead of accessing slots directly,
see the topic 'Extractor Functions' (on this list) in
mid-August, e.g.,
  https://stat.ethz.ch/pipermail/r-sig-mixed-models/2011q3/006542.html

In other words: If you write R code, notably R packages, that
use the resulting object from  lmer() [or glmer() ...],
we strongly advise to *not* access the slots of the object
directly, but use getME() instead.
We {lme4-authors} promise to keep getME() working compatibly also for the
next-generation version of lme4 {and its lmer(), glmer(), nlmer(),..},
but we know that the *internal* structure of the result object,
say 'fm' when  'fm <- lmer(...)' will be quite different.

All methods such as  
    fixef(), ranef(), coef(), 
    VarCor(), vcov(), summary(), anova(),....

should of course remain fully compatible.
As some of you currently access parts of [ng]?lmer() results 
directly by slots, e.g.,  fm at Z  
we now provide the function  
   getME()  {get (a part of a) Mixed-Effects (fit}
and so instead of fm at Zt you should rather use
  getME(fm, "Zt")   or   getME(fm, "Z")
and similarly for other important parts,
but *NOT* for all current (or future) slots, of course.
The list of parts accessible by getME()  is explicitly
enumerated and is considerably *smaller* than all possible slots
(and/or sub slots) in such a fm object.
OTOH of course, we will extend the list if you, lme4 useRs,
ask about it and make a convincing case...

For the lme4 - authors (of which Doug Bates is definitely *the* person!),
Martin Maechler