R 3.0, lme4, and the oft unloved Mac OS

12 messages · Jorge I Velez, R. Michael Weylandt, Duncan Murdoch +3 more

Original

1

12

flip

Wed, Apr 10, 2013 6:32 AM #

Greetings-

I've noticed that lme4 isn't available for Mac under R 3.

Looks like its throwing errors at compile time, according to the logs. 
I'm tempted to just pull it down and build it myself, but thought I'd let the list / Simon know too.

www.skidmore.edu/flip
www.flipphillips.com

Wed, Apr 10, 2013 6:37 AM #

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20130410/0d0c4477/attachment.pl>

flip

Wed, Apr 10, 2013 6:51 AM #

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20130410/e6965978/attachment.pl>

Wed, Apr 10, 2013 6:55 AM #

On Apr 10, 2013, at 9:32 AM, flip wrote:

More precisely, if fails checks:

checking tests ... ERROR
Running the tests in 'tests/simulate.R' failed.
Last 13 lines of output:

+ sapply(s4,nrow) == nrow(cbpp))

Time elapsed: 0.232 0.002 0.234

Error in logLik(refit(m1, s)) : 
error in evaluating the argument 'object' in selecting a method for function 'logLik': Error in mer_finalize(object) : 
Downdated X'X is not positive definite, 1.
Calls: refit -> refit -> mer_finalize -> .Call
Calls: pboot -> apply -> FUN -> logLik
Execution halted

that's why it's not available. I tried two different compilers just to make sure it's not a compiler issue and it throws the same error, so I fear this is over to the maintainers.

Cheers,
Simon

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

R. Michael Weylandt

Wed, Apr 10, 2013 6:58 AM #

On Wed, Apr 10, 2013 at 8:55 AM, Simon Urbanek

<simon.urbanek at r-project.org> wrote:

It looks like Ben is aware of the issue and fixing it:
https://stat.ethz.ch/pipermail/r-sig-mixed-models/2013q2/020170.html

Cheers,
Michael

flip

Wed, Apr 10, 2013 7:02 AM #

Ah hah!
OK- that's good to know (sorry for na?vet?, just learning how to build things in the R-ecosphere).

Realize this isn't r-mac specific, but, is there a way to run package tests post 

install.packages("lme4", type = 'source')

sorts of procedures? I tried things like lme4.test() et alia...

On Apr 10, 2013, at 9:55 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote:

www.skidmore.edu/flip
www.flipphillips.com

Wed, Apr 10, 2013 7:07 AM #

On 10/04/2013 10:02 AM, flip wrote:

See ?tools::testInstalledPackage.  You can do better tests on a tarball 
because some test material is not installed by default.

And you can find things like this from the R command prompt by ??tests, 
or using the sos package and ???tests.

Duncan Murdoch

flip

Wed, Apr 10, 2013 8:41 AM #

Ok thanks all- so many sigs, so little time!

via iOS
www.flipphillips.com


On Apr 10, 2013, at 9:58 AM, "R. Michael Weylandt" <michael.weylandt at gmail.com> wrote:

> On Wed, Apr 10, 2013 at 8:55 AM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> On Apr 10, 2013, at 9:32 AM, flip wrote:
>> 
>>> 
>>> Greetings-
>>> 
>>> I've noticed that lme4 isn't available for Mac under R 3.
>>> 
>>> Looks like its throwing errors at compile time, according to the logs.
>> 
>> More precisely, if fails checks:
>> 
>> checking tests ... ERROR
>> Running the tests in 'tests/simulate.R' failed.
>> Last 13 lines of output:
>>> s4 <- simulate(gm1,10)
>>> stopifnot(is.list(s4), sapply(s4,ncol)==2,
>> + sapply(s4,nrow) == nrow(cbpp))
>>> showProc.time()
>> Time elapsed: 0.232 0.002 0.234
>>> 
>>> r1 <- pboot(gm0,gm1, 10)
>> Error in logLik(refit(m1, s)) :
>> error in evaluating the argument 'object' in selecting a method for function 'logLik': Error in mer_finalize(object) :
>> Downdated X'X is not positive definite, 1.
>> Calls: refit -> refit -> mer_finalize -> .Call
>> Calls: pboot -> apply -> FUN -> logLik
>> Execution halted
>> 
>> that's why it's not available. I tried two different compilers just to make sure it's not a compiler issue and it throws the same error, so I fear this is over to the maintainers.
>> 
>> Cheers,
>> Simon
> 
> It looks like Ben is aware of the issue and fixing it:
> https://stat.ethz.ch/pipermail/r-sig-mixed-models/2013q2/020170.html
> 
> Cheers,
> Michael
>

Ian Fellows

Wed, Apr 10, 2013 12:26 PM #

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20130410/bb26d125/attachment.pl>

Ian Fellows

Wed, Apr 10, 2013 12:53 PM #

[Previous version was not plain text. Sorry, plain text this time?]

On a related note to the lme4 query? There was a glorious period of time where rgdal binaries (with it's external dependancies) were available on CRAN for the mac. Unfortunately, with the introduction of R 3.0 this is no longer the case. It now requires a rather protracted install process (installing GDAL, then PROJ4, then installing rgdal from source using the proper configuration arguments). I understand that this is a known issue https://stat.ethz.ch/pipermail/r-sig-geo/2013-April/017989.html, and was wondering whether CRAN is planning on supporting a binary distribution in the future. If not, is CRAN Extras planning on hosting it?

I'm currently in the process of updating the OpenStreetMap package, and was planning on moving rgdal from a suggest to a depends, but would like to know the lay of the land before proceeding.

Best,
Ian

Thu, Apr 11, 2013 6:55 AM #

On Apr 10, 2013, at 3:26 PM, Ian Fellows wrote:

rgdal fails the checks, it segfaults:
http://www.R-project.org/nosvn/R.check/r-release-macosx-x86_64/rgdal-00check.html

Here is the output of valgrind:

==41210== Syscall param sigprocmask(set) points to uninitialised byte(s)
==41210==    at 0x41D0FA: sigprocmask (in /usr/lib/libSystem.B.dylib)
==41210==    by 0x75756E1: jpeg_CreateDecompress (jdapimin.c:38)
==41210==    by 0x6FBFAA1: JPGDataset::Open(GDALOpenInfo*) (jpgdataset.cpp:1833)
==41210==    by 0x70EF3F5: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2236)
==41210==    by 0x70EF5C0: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2208)
==41210==    by 0x6E731A0: RGDAL_OpenDataset (gdal-bindings.cpp:574)
==41210==    by 0x89032: do_dotcall (dotcode.c:585)
==41210==    by 0xB1D66: Rf_eval (eval.c:612)
==41210==    by 0xBFACF: do_begin (eval.c:1534)
==41210==    by 0xB1BD5: Rf_eval (eval.c:584)
==41210==    by 0xBED3C: applydefine (eval.c:1689)
==41210==    by 0xB1BD5: Rf_eval (eval.c:584)
==41210==  Address 0x7fff5fbfb870 is on thread 1's stack
==41210== 
--41210:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
==41210== Warning: client switching stacks?  SP change: 0x7fff5fbfb888 --> 0x100207c48
==41210==          to suppress, use: --max-stackframe=140730502691904 or greater
==41210== Conditional jump or move depends on uninitialised value(s)
==41210==    at 0x41D1A9: _longjmp (in /usr/lib/libSystem.B.dylib)
==41210==    by 0x1000BBDC7: ???
==41210==    by 0x100207C17: ???
==41210==    by 0x100F6C7E7: ???
==41210== 

.. followed by a crash. Possibly some incompatibility between jpeg and gdal? I may have a look later unless the maintainers have some insight...

Cheers,
Simon

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Thu, Apr 11, 2013 8:13 AM #

It seems that gdal gets confused with internal and external libraries in a static build - likely causing API mismatch which demonstrated itself in the crash. After re-building gdal with minimal dependencies it seems to work. The rgdal binary is up.

Cheers,
Simon

On Apr 11, 2013, at 9:55 AM, Simon Urbanek wrote:

On Apr 10, 2013, at 3:26 PM, Ian Fellows wrote:

On a related note to the lme4 query? There was a glorious period of time where rgdal binaries (with it's external dependancies) were available on CRAN for the mac. Unfortunately, with the introduction of R 3.0 this is no longer the case. It now requires a rather protracted install process (installing GDAL, then PROJ4, then installing rgdal from source using the proper configuration arguments). I understand that this is a known issue https://stat.ethz.ch/pipermail/r-sig-geo/2013-April/017989.html, and was wondering whether CRAN is planning on supporting a binary distribution in the future. If not, is CRAN Extras planning on hosting it?

rgdal fails the checks, it segfaults:
http://www.R-project.org/nosvn/R.check/r-release-macosx-x86_64/rgdal-00check.html

Here is the output of valgrind:

logo <- system.file("pictures/logo.jpg", package="rgdal")[1]
x <- new("GDALReadOnlyDataset", logo)

==41210== Syscall param sigprocmask(set) points to uninitialised byte(s)
==41210==    at 0x41D0FA: sigprocmask (in /usr/lib/libSystem.B.dylib)
==41210==    by 0x75756E1: jpeg_CreateDecompress (jdapimin.c:38)
==41210==    by 0x6FBFAA1: JPGDataset::Open(GDALOpenInfo*) (jpgdataset.cpp:1833)
==41210==    by 0x70EF3F5: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2236)
==41210==    by 0x70EF5C0: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2208)
==41210==    by 0x6E731A0: RGDAL_OpenDataset (gdal-bindings.cpp:574)
==41210==    by 0x89032: do_dotcall (dotcode.c:585)
==41210==    by 0xB1D66: Rf_eval (eval.c:612)
==41210==    by 0xBFACF: do_begin (eval.c:1534)
==41210==    by 0xB1BD5: Rf_eval (eval.c:584)
==41210==    by 0xBED3C: applydefine (eval.c:1689)
==41210==    by 0xB1BD5: Rf_eval (eval.c:584)
==41210==  Address 0x7fff5fbfb870 is on thread 1's stack
==41210== 
--41210:0:syswrap- WARNING: Ignoring sigreturn( ..., UC_RESET_ALT_STACK );
==41210== Warning: client switching stacks?  SP change: 0x7fff5fbfb888 --> 0x100207c48
==41210==          to suppress, use: --max-stackframe=140730502691904 or greater
==41210== Conditional jump or move depends on uninitialised value(s)
==41210==    at 0x41D1A9: _longjmp (in /usr/lib/libSystem.B.dylib)
==41210==    by 0x1000BBDC7: ???
==41210==    by 0x100207C17: ???
==41210==    by 0x100F6C7E7: ???
==41210== 

.. followed by a crash. Possibly some incompatibility between jpeg and gdal? I may have a look later unless the maintainers have some insight...

Cheers,
Simon

I'm currently in the process of updating the OpenStreetMap package, and was planning on moving rgdal from a suggest to a depends, but would like to know the lay of the land before proceeding.

Best,
Ian
	[[alternative HTML version deleted]]

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac