Re: [Rd] Timezone warnings on package install in R-alpha
That doesn't seem to be the case. After rebuilding using the old configure
options, I see
> Sys.getenv("TZDIR")
[1] ""
Jon
On 3 April 2014 14:39, peter dalgaard wrote:
> Thanks to Brian. Yet another thing that zoomed by without me really
> noticing.
>
> However, I'd like to be sure that it isn't a "make dist" issue. We do seem
> to ship the correct files in src/extra/tzone, but could you please check
> Brian's suggestion about TZDIR possibly being set incorrectly?
>
> -pd
>
> On 03 Apr 2014, at 14:47 , Jon Clayden wrote:
>
> > Many thanks, Prof Ripley. The "--without-internal-tzcode" option does
> indeed resolve the problem.
> >
> > Regards,
> > Jon
> >
> >
> > On 3 April 2014 13:38, Prof Brian Ripley wrote:
> > On 03/04/2014 13:27, peter dalgaard wrote:
> > I'm seeing nothing of the sort with the nightly build of 3.1.0RC, also
> on 10.9.2. This is a plain-vanilla Xcode+ancillaries build as per Simon's
> instructions (I think):
> >
> > pd$ more config.site
> > r_arch=${r_arch:=x86_64}
> > CC="gcc -arch $r_arch"
> > CXX="g++ -arch $r_arch"
> > F77="gfortran -arch $r_arch"
> > FC="gfortran -arch $r_arch"
> > OBJC="gcc -arch $r_arch"
> > with_blas="-framework vecLib"
> > with_lapack=yes
> >
> > so either something is up specifically with gcc-4.8, or you managed to
> hose your time zone data base somehow (/usr/share/zoneinfo, I suppose).
> >
> > More likely the one shipping with R, since --with-internal-tzcode is the
> default on OS X [*]. Setting TZDIR incorrectly would do this:
> >
> > > Sys.time()
> > [1] "2014-04-03 12:37:01 GMT"
> > Warning messages:
> > 1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
> > 2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> > 3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'America/New_York'
> >
> > when I do that.
> >
> > You could try --without-internal-tzcode.
> >
> > [*] Although x86_64 OS X has a 64-bit time_t it seems to have a 32-bit
> time-zone database and so wraps around.
> >
> >
> >
> > - Peter D.
> >
> > On 03 Apr 2014, at 13:24 , Jon Clayden wrote:
> >
> > For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
> >
> > Regards,
> > Jon
> >
> >
> > On 24 March 2014 10:40, Jon Clayden wrote:
> >
> > Dear all,
> >
> > As of the current R alpha release, I'm seeing timezone-related warnings
> on
> > installing any package (including the recommended ones), which I haven't
> > seen before. For example,
> >
> > [~/Documents/Source/R-alpha]$ bin/R CMD INSTALL ~/git/tractor/lib/reportr
> > * installing to library '/Users/jon/Documents/Source/R-alpha/library'
> > * installing *source* package 'reportr' ...
> > Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
> > Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> > Warning in as.POSIXlt.POSIXct(x, tz) :
> > unknown timezone 'America/New_York'
> > Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> > Warning in as.POSIXlt.POSIXct(x, tz) :
> > unknown timezone 'America/New_York'
> > ** R
> > ** preparing package for lazy loading
> > ** help
> > *** installing help indices
> > ** building package indices
> > ** testing if installed package can be loaded
> > * DONE (reportr)
> >
> > This is R-alpha r65266, built from source on OS X 10.9.2 using gcc 4.8.2.
> > I ran configure with
> >
> > ./configure --with-blas="-framework Accelerate" --with-lapack
> > --with-system-zlib --enable-memory-profiling
> > --with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh
> > --with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh
> > CC=gcc-4.8 CXX=g++-4.8 OBJC=clang F77=gfortran-4.8 FC=gfortran-4.8
> > CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2"
> > CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2"
> > FCFLAGS="-mtune=native -g -O2"
> >
> > Session info is
> >
> > R version 3.1.0 alpha (2014-03-23 r65266)
> > Platform: x86_64-apple-darwin13.1.0 (64-bit)
> >
> > locale:
> > [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
> >
> > attached base packages:
> > [1] stats graphics grDevices utils datasets methods base
> >
> > I see some related material in the NEWS, but no indication that these
> > warnings are expected. I hope this report is helpful.
> >
> > All the best,
> > Jon
> >
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> >
> > --
> > Brian D. Ripley, rip...@stats.ox.ac.uk
> > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> > University of Oxford, Tel: +44 1865 272861 (self)
> > 1 South Parks Road, +44 1865 272866 (PA)
> > Oxford OX1 3TG, UKFax: +44 1865 272595
> >
>
> --
> Peter Dalgaard, Professor
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phon
Re: [Rd] Timezone warnings on package install in R-alpha
Thanks to Brian. Yet another thing that zoomed by without me really noticing.
However, I'd like to be sure that it isn't a "make dist" issue. We do seem to
ship the correct files in src/extra/tzone, but could you please check Brian's
suggestion about TZDIR possibly being set incorrectly?
-pd
On 03 Apr 2014, at 14:47 , Jon Clayden wrote:
> Many thanks, Prof Ripley. The "--without-internal-tzcode" option does indeed
> resolve the problem.
>
> Regards,
> Jon
>
>
> On 3 April 2014 13:38, Prof Brian Ripley wrote:
> On 03/04/2014 13:27, peter dalgaard wrote:
> I'm seeing nothing of the sort with the nightly build of 3.1.0RC, also on
> 10.9.2. This is a plain-vanilla Xcode+ancillaries build as per Simon's
> instructions (I think):
>
> pd$ more config.site
> r_arch=${r_arch:=x86_64}
> CC="gcc -arch $r_arch"
> CXX="g++ -arch $r_arch"
> F77="gfortran -arch $r_arch"
> FC="gfortran -arch $r_arch"
> OBJC="gcc -arch $r_arch"
> with_blas="-framework vecLib"
> with_lapack=yes
>
> so either something is up specifically with gcc-4.8, or you managed to hose
> your time zone data base somehow (/usr/share/zoneinfo, I suppose).
>
> More likely the one shipping with R, since --with-internal-tzcode is the
> default on OS X [*]. Setting TZDIR incorrectly would do this:
>
> > Sys.time()
> [1] "2014-04-03 12:37:01 GMT"
> Warning messages:
> 1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
> 2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> 3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'America/New_York'
>
> when I do that.
>
> You could try --without-internal-tzcode.
>
> [*] Although x86_64 OS X has a 64-bit time_t it seems to have a 32-bit
> time-zone database and so wraps around.
>
>
>
> - Peter D.
>
> On 03 Apr 2014, at 13:24 , Jon Clayden wrote:
>
> For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
>
> Regards,
> Jon
>
>
> On 24 March 2014 10:40, Jon Clayden wrote:
>
> Dear all,
>
> As of the current R alpha release, I'm seeing timezone-related warnings on
> installing any package (including the recommended ones), which I haven't
> seen before. For example,
>
> [~/Documents/Source/R-alpha]$ bin/R CMD INSTALL ~/git/tractor/lib/reportr
> * installing to library '/Users/jon/Documents/Source/R-alpha/library'
> * installing *source* package 'reportr' ...
> Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
> Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> Warning in as.POSIXlt.POSIXct(x, tz) :
> unknown timezone 'America/New_York'
> Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> Warning in as.POSIXlt.POSIXct(x, tz) :
> unknown timezone 'America/New_York'
> ** R
> ** preparing package for lazy loading
> ** help
> *** installing help indices
> ** building package indices
> ** testing if installed package can be loaded
> * DONE (reportr)
>
> This is R-alpha r65266, built from source on OS X 10.9.2 using gcc 4.8.2.
> I ran configure with
>
> ./configure --with-blas="-framework Accelerate" --with-lapack
> --with-system-zlib --enable-memory-profiling
> --with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh
> --with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh
> CC=gcc-4.8 CXX=g++-4.8 OBJC=clang F77=gfortran-4.8 FC=gfortran-4.8
> CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2"
> CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2"
> FCFLAGS="-mtune=native -g -O2"
>
> Session info is
>
> R version 3.1.0 alpha (2014-03-23 r65266)
> Platform: x86_64-apple-darwin13.1.0 (64-bit)
>
> locale:
> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> I see some related material in the NEWS, but no indication that these
> warnings are expected. I hope this report is helpful.
>
> All the best,
> Jon
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
--
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] summary of lme4.0 model in package
Thierry, did you try to importFrom() in the namespace file? That way you know for sure you have the correct summary function in the namespace of your package. Since namespaces are available, I personally found that using them whenever possible/suitable can prevent a lot of conflicts due to similarly named functions. In this case you notice the difference in search path. If you call a function within a package (package:function), it will look for the summary function in the namespaces and imported namespaces first. If you source it on the other hand, it will look for the summary function in the attached packages first. And in your case, that's 2 different versions of the same function. You will keep on having this problem as long as your package directly or indirectly calls for 2 different versions of the same package. I fail to understand why you would make your package dependent on an old version of lme4 (i.e. lme4.0). Back compatibility between new and old versions of lme4 are not guaranteed. Cheers Joris On Thu, Apr 3, 2014 at 2:55 PM, ONKELINX, Thierry wrote: > An update: I copied the functions from package A into MyPackage instead of > importing them. This avoids lme4_1.1-5 to be loaded via namespace (see > sessionInfo). However, the error remains. Nlme is loaded via namespace by > lme4.0 > > R version 3.0.2 (2013-09-25) > Platform: i386-w64-mingw32/i386 (32-bit) > > locale: > [1] LC_COLLATE=Dutch_Belgium.1252 LC_CTYPE=Dutch_Belgium.1252 > LC_MONETARY=Dutch_Belgium.1252 > [4] LC_NUMERIC=C LC_TIME=Dutch_Belgium.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] sendmailR_1.1-2 base64enc_0.1-1 ABV_0.2-21 > lme4.0_0.99-4 lattice_0.20-28 Matrix_1.1-3 > > loaded via a namespace (and not attached): > [1] colorspace_1.2-4 dichromat_2.0-0digest_0.6.4 > fortunes_1.5-2 ggplot2_0.9.3.1.99 grid_3.0.2 > [7] gridExtra_0.9.1gtable_0.1.2 labeling_0.2 > lubridate_1.3.3MASS_7.3-30memoise_0.1 > [13] multcomp_1.3-2 munsell_0.4.2 mvtnorm_0.9-9997 nlme_3.1-115 > plyr_1.8.1 proto_0.3-10 > [19] RColorBrewer_1.0-5 Rcpp_0.11.1reshape2_1.2.2 RODBC_1.3-10 > sandwich_2.3-0 scales_0.2.3 > [25] splines_3.0.2 stats4_3.0.2 stringr_0.6.2 > survival_2.37-7TH.data_1.0-3 tools_3.0.2 > [31] zoo_1.7-11 > > ir. Thierry Onkelinx > Instituut voor natuur- en bosonderzoek / Research Institute for Nature and > Forest > team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance > Kliniekstraat 25 > 1070 Anderlecht > Belgium > + 32 2 525 02 51 > + 32 54 43 61 85 > thierry.onkel...@inbo.be > www.inbo.be > > To call in the statistician after the experiment is done may be no more > than asking him to perform a post-mortem examination: he may be able to say > what the experiment died of. > ~ Sir Ronald Aylmer Fisher > > The plural of anecdote is not data. > ~ Roger Brinner > > The combination of some data and an aching desire for an answer does not > ensure that a reasonable answer can be extracted from a given body of data. > ~ John Tukey > > > -Oorspronkelijk bericht- > Van: ONKELINX, Thierry > Verzonden: donderdag 3 april 2014 13:44 > Aan: 'Joshua Wiley' > CC: r-devel@r-project.org > Onderwerp: RE: [Rd] summary of lme4.0 model in package > > Dear Joshua, > > Thank you for quick reply. > > Note that my package has Depends: lme4.0 in DESCRIPTION. It imports and > suggests other packages but not lme4. lme4_1.1-5 is attached because my > package imports (via Imports: in DESCRIPTION) functions from package A, > which imports (via Imports: in DESCRIPTION) functions from package B, which > imports (via Imports: in DESCRIPTION) functions from lme4. Neither packages > A nor B import lme4 related functions. > > Should try to import lme4.0 instead of depending on it? > > Best regards, > > Thierry > > ir. Thierry Onkelinx > Instituut voor natuur- en bosonderzoek / Research Institute for Nature and > Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality > Assurance Kliniekstraat 25 > 1070 Anderlecht > Belgium > + 32 2 525 02 51 > + 32 54 43 61 85 > thierry.onkel...@inbo.be > www.inbo.be > > To call in the statistician after the experiment is done may be no more > than asking him to perform a post-mortem examination: he may be able to say > what the experiment died of. > ~ Sir Ronald Aylmer Fisher > > The plural of anecdote is not data. > ~ Roger Brinner > > The combination of some data and an aching desire for an answer does not > ensure that a reasonable answer can be extracted from a given body of data. > ~ John Tukey > > Van: Joshua Wiley [mailto:jwiley.ps...@gmail.com] > Verzonden: donderdag 3 april 2014 12:36 > Aan: ONKELINX, Thierry > CC: r-devel@r-project.org > Onderwerp: Re: [Rd] summary of lme4.0 model in package > > Dear Thierry, > > You have lme4.0_0.99-4 attached and lme4_1.1-5 loaded via a
Re: [Rd] summary of lme4.0 model in package
An update: I copied the functions from package A into MyPackage instead of importing them. This avoids lme4_1.1-5 to be loaded via namespace (see sessionInfo). However, the error remains. Nlme is loaded via namespace by lme4.0 R version 3.0.2 (2013-09-25) Platform: i386-w64-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=Dutch_Belgium.1252 LC_CTYPE=Dutch_Belgium.1252 LC_MONETARY=Dutch_Belgium.1252 [4] LC_NUMERIC=C LC_TIME=Dutch_Belgium.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] sendmailR_1.1-2 base64enc_0.1-1 ABV_0.2-21lme4.0_0.99-4 lattice_0.20-28 Matrix_1.1-3 loaded via a namespace (and not attached): [1] colorspace_1.2-4 dichromat_2.0-0digest_0.6.4 fortunes_1.5-2 ggplot2_0.9.3.1.99 grid_3.0.2 [7] gridExtra_0.9.1gtable_0.1.2 labeling_0.2 lubridate_1.3.3 MASS_7.3-30memoise_0.1 [13] multcomp_1.3-2 munsell_0.4.2 mvtnorm_0.9-9997 nlme_3.1-115 plyr_1.8.1 proto_0.3-10 [19] RColorBrewer_1.0-5 Rcpp_0.11.1reshape2_1.2.2 RODBC_1.3-10 sandwich_2.3-0 scales_0.2.3 [25] splines_3.0.2 stats4_3.0.2 stringr_0.6.2 survival_2.37-7 TH.data_1.0-3 tools_3.0.2 [31] zoo_1.7-11 ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance Kliniekstraat 25 1070 Anderlecht Belgium + 32 2 525 02 51 + 32 54 43 61 85 thierry.onkel...@inbo.be www.inbo.be To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey -Oorspronkelijk bericht- Van: ONKELINX, Thierry Verzonden: donderdag 3 april 2014 13:44 Aan: 'Joshua Wiley' CC: r-devel@r-project.org Onderwerp: RE: [Rd] summary of lme4.0 model in package Dear Joshua, Thank you for quick reply. Note that my package has Depends: lme4.0 in DESCRIPTION. It imports and suggests other packages but not lme4. lme4_1.1-5 is attached because my package imports (via Imports: in DESCRIPTION) functions from package A, which imports (via Imports: in DESCRIPTION) functions from package B, which imports (via Imports: in DESCRIPTION) functions from lme4. Neither packages A nor B import lme4 related functions. Should try to import lme4.0 instead of depending on it? Best regards, Thierry ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance Kliniekstraat 25 1070 Anderlecht Belgium + 32 2 525 02 51 + 32 54 43 61 85 thierry.onkel...@inbo.be www.inbo.be To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey Van: Joshua Wiley [mailto:jwiley.ps...@gmail.com] Verzonden: donderdag 3 april 2014 12:36 Aan: ONKELINX, Thierry CC: r-devel@r-project.org Onderwerp: Re: [Rd] summary of lme4.0 model in package Dear Thierry, You have lme4.0_0.99-4 attached and lme4_1.1-5 loaded via a namespace. I wonder if changes between the versions and which was getting called when are making the difference. In particular, when you source it, I would assume methods from the attached package are used. When you use the function from the package, the methods from the dependencies for the package would be used. Cheers, Josh On Thu, Apr 3, 2014 at 3:09 AM, ONKELINX, Thierry wrote: Dear all, My package has Depends: lme4.0 in the DESCRIPTION. I need to extract the fixed effect of a model and their standard errors. I use coef(summary(model)) inside a function to do that. Model is the output of a call to glmer() from the lme4.0 package. coef(summary(model)) throws an error: $ operator is invalid for atomic vectors I have tracked it down to a problem with summary(model) because str(summary(model)) gives this Classes 'summaryDefault', 'table' Named chr [1:3] "1" "mer" "S4" ..- attr(*, "names")= chr [1:3] "Length" "Class" "Mode" But it should return Formal class 'summary.mer' [package "lme4.0"] with 42 slots ..@ methTitle: chr "Generalized linear mixed model fit by the Laplace approximation" ..@ logLik :Class 'logLik' : -2265 (df=12) --- output snipped --- What puzzles me is that the function
Re: [Rd] Timezone warnings on package install in R-alpha
Many thanks, Prof Ripley. The "--without-internal-tzcode" option does
indeed resolve the problem.
Regards,
Jon
On 3 April 2014 13:38, Prof Brian Ripley wrote:
> On 03/04/2014 13:27, peter dalgaard wrote:
>
>> I'm seeing nothing of the sort with the nightly build of 3.1.0RC, also on
>> 10.9.2. This is a plain-vanilla Xcode+ancillaries build as per Simon's
>> instructions (I think):
>>
>> pd$ more config.site
>> r_arch=${r_arch:=x86_64}
>> CC="gcc -arch $r_arch"
>> CXX="g++ -arch $r_arch"
>> F77="gfortran -arch $r_arch"
>> FC="gfortran -arch $r_arch"
>> OBJC="gcc -arch $r_arch"
>> with_blas="-framework vecLib"
>> with_lapack=yes
>>
>> so either something is up specifically with gcc-4.8, or you managed to
>> hose your time zone data base somehow (/usr/share/zoneinfo, I suppose).
>>
>
> More likely the one shipping with R, since --with-internal-tzcode is the
> default on OS X [*]. Setting TZDIR incorrectly would do this:
>
> > Sys.time()
> [1] "2014-04-03 12:37:01 GMT"
> Warning messages:
> 1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
> 2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> 3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'America/New_York'
>
> when I do that.
>
> You could try --without-internal-tzcode.
>
> [*] Although x86_64 OS X has a 64-bit time_t it seems to have a 32-bit
> time-zone database and so wraps around.
>
>
>
> - Peter D.
>>
>> On 03 Apr 2014, at 13:24 , Jon Clayden wrote:
>>
>> For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
>>>
>>> Regards,
>>> Jon
>>>
>>>
>>> On 24 March 2014 10:40, Jon Clayden wrote:
>>>
>>> Dear all,
As of the current R alpha release, I'm seeing timezone-related warnings
on
installing any package (including the recommended ones), which I haven't
seen before. For example,
[~/Documents/Source/R-alpha]$ bin/R CMD INSTALL
~/git/tractor/lib/reportr
* installing to library '/Users/jon/Documents/Source/R-alpha/library'
* installing *source* package 'reportr' ...
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
Warning in as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'America/New_York'
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
Warning in as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'America/New_York'
** R
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (reportr)
This is R-alpha r65266, built from source on OS X 10.9.2 using gcc
4.8.2.
I ran configure with
./configure --with-blas="-framework Accelerate" --with-lapack
--with-system-zlib --enable-memory-profiling
--with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh
--with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh
CC=gcc-4.8 CXX=g++-4.8 OBJC=clang F77=gfortran-4.8 FC=gfortran-4.8
CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2"
CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2"
FCFLAGS="-mtune=native -g -O2"
Session info is
R version 3.1.0 alpha (2014-03-23 r65266)
Platform: x86_64-apple-darwin13.1.0 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
I see some related material in the NEWS, but no indication that these
warnings are expected. I hope this report is helpful.
All the best,
Jon
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timezone warnings on package install in R-alpha
On 03/04/2014 13:27, peter dalgaard wrote:
I'm seeing nothing of the sort with the nightly build of 3.1.0RC, also on
10.9.2. This is a plain-vanilla Xcode+ancillaries build as per Simon's
instructions (I think):
pd$ more config.site
r_arch=${r_arch:=x86_64}
CC="gcc -arch $r_arch"
CXX="g++ -arch $r_arch"
F77="gfortran -arch $r_arch"
FC="gfortran -arch $r_arch"
OBJC="gcc -arch $r_arch"
with_blas="-framework vecLib"
with_lapack=yes
so either something is up specifically with gcc-4.8, or you managed to hose
your time zone data base somehow (/usr/share/zoneinfo, I suppose).
More likely the one shipping with R, since --with-internal-tzcode is the
default on OS X [*]. Setting TZDIR incorrectly would do this:
> Sys.time()
[1] "2014-04-03 12:37:01 GMT"
Warning messages:
1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'America/New_York'
when I do that.
You could try --without-internal-tzcode.
[*] Although x86_64 OS X has a 64-bit time_t it seems to have a 32-bit
time-zone database and so wraps around.
- Peter D.
On 03 Apr 2014, at 13:24 , Jon Clayden wrote:
For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
Regards,
Jon
On 24 March 2014 10:40, Jon Clayden wrote:
Dear all,
As of the current R alpha release, I'm seeing timezone-related warnings on
installing any package (including the recommended ones), which I haven't
seen before. For example,
[~/Documents/Source/R-alpha]$ bin/R CMD INSTALL ~/git/tractor/lib/reportr
* installing to library '/Users/jon/Documents/Source/R-alpha/library'
* installing *source* package 'reportr' ...
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
Warning in as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'America/New_York'
Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
Warning in as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'America/New_York'
** R
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (reportr)
This is R-alpha r65266, built from source on OS X 10.9.2 using gcc 4.8.2.
I ran configure with
./configure --with-blas="-framework Accelerate" --with-lapack
--with-system-zlib --enable-memory-profiling
--with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh
--with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh
CC=gcc-4.8 CXX=g++-4.8 OBJC=clang F77=gfortran-4.8 FC=gfortran-4.8
CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2"
CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2"
FCFLAGS="-mtune=native -g -O2"
Session info is
R version 3.1.0 alpha (2014-03-23 r65266)
Platform: x86_64-apple-darwin13.1.0 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
I see some related material in the NEWS, but no indication that these
warnings are expected. I hope this report is helpful.
All the best,
Jon
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timezone warnings on package install in R-alpha
On 3 April 2014 at 12:24, Jon Clayden wrote:
| For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
I'm running a beta version on Ubuntu and do not see this, neither on INSTALL
or check during package development nor during normal use:
R> R.version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status beta
major 3
minor 1.0
year 2014
month 03
day28
svn rev65330
language R
version.string R version 3.1.0 beta (2014-03-28 r65330)
nickname Spring Dance
R> format(Sys.time())
[1] "2014-04-03 07:30:17.171488"
R> format(Sys.time(), tz="America/New_York")
[1] "2014-04-03 08:30:28.771662"
R> format(Sys.time(), tz="Europe/Berlin")
[1] "2014-04-03 14:30:41.211835"
R> Sys.getenv("TZ")
[1] ""
R>
As you can see, I do not set a TZ variable and things work here.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timezone warnings on package install in R-alpha
I'm seeing nothing of the sort with the nightly build of 3.1.0RC, also on
10.9.2. This is a plain-vanilla Xcode+ancillaries build as per Simon's
instructions (I think):
pd$ more config.site
r_arch=${r_arch:=x86_64}
CC="gcc -arch $r_arch"
CXX="g++ -arch $r_arch"
F77="gfortran -arch $r_arch"
FC="gfortran -arch $r_arch"
OBJC="gcc -arch $r_arch"
with_blas="-framework vecLib"
with_lapack=yes
so either something is up specifically with gcc-4.8, or you managed to hose
your time zone data base somehow (/usr/share/zoneinfo, I suppose).
- Peter D.
On 03 Apr 2014, at 13:24 , Jon Clayden wrote:
> For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
>
> Regards,
> Jon
>
>
> On 24 March 2014 10:40, Jon Clayden wrote:
>
>> Dear all,
>>
>> As of the current R alpha release, I'm seeing timezone-related warnings on
>> installing any package (including the recommended ones), which I haven't
>> seen before. For example,
>>
>> [~/Documents/Source/R-alpha]$ bin/R CMD INSTALL ~/git/tractor/lib/reportr
>> * installing to library '/Users/jon/Documents/Source/R-alpha/library'
>> * installing *source* package 'reportr' ...
>> Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
>> Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
>> Warning in as.POSIXlt.POSIXct(x, tz) :
>> unknown timezone 'America/New_York'
>> Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
>> Warning in as.POSIXlt.POSIXct(x, tz) :
>> unknown timezone 'America/New_York'
>> ** R
>> ** preparing package for lazy loading
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** testing if installed package can be loaded
>> * DONE (reportr)
>>
>> This is R-alpha r65266, built from source on OS X 10.9.2 using gcc 4.8.2.
>> I ran configure with
>>
>> ./configure --with-blas="-framework Accelerate" --with-lapack
>> --with-system-zlib --enable-memory-profiling
>> --with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh
>> --with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh
>> CC=gcc-4.8 CXX=g++-4.8 OBJC=clang F77=gfortran-4.8 FC=gfortran-4.8
>> CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2"
>> CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2"
>> FCFLAGS="-mtune=native -g -O2"
>>
>> Session info is
>>
>> R version 3.1.0 alpha (2014-03-23 r65266)
>> Platform: x86_64-apple-darwin13.1.0 (64-bit)
>>
>> locale:
>> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> I see some related material in the NEWS, but no indication that these
>> warnings are expected. I hope this report is helpful.
>>
>> All the best,
>> Jon
>>
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Bioc-devel] Conflicting definitions for function redefined as S4 generics
On Thu, Apr 3, 2014 at 4:33 AM, Ulrich Bodenhofer wrote: > On 03/27/2014 06:31 PM, Hervé Pagès wrote: > >> On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote: >> >>> [...] >>> >>> >>> For the time being, it seems I have three options: >>> >>> 1) not supplying the sort() function yet (it is not yet in the release, >>> but only in my internal devel version) >>> 2) including a dependency to BiocGenerics >>> 3) leaving the problem open, mentioning in the documentation that users >>> who want to use apcluster in conjunction with Bioconductor should load >>> BiocGenerics first >>> >> >> 4) define an S3 method, as mentioned in my previous post >> >> H. >> >> After a while, I came back to this suggestion. Thanks, Hervé! I now > tried it and it indeed works smoothly: all problems I mentioned - as you > expected correctly - are resolved. It seems that BiocGenerics screws up my > previously defined S4 generic, but leaves my S3 function untouched. Hmm ... > > The question is whether it is good style to use S3 and S4 together. > Actually I am reluctant to think so, but if it helps and creates no other > problems whatsoever, why not? > > One motivation for defining S3 methods is that the base (and other non-S4) packages define and call S3 generics, so integration with base functionality is easier. Where an S4 generic is also present, one should *additionally* define S4 methods corresponding to the S3 methods, because in that context it is possible for an S4 method to take precedence over the S3 method in a way that violates the dispatch rules regarding inheritance. In other words, if there is a class B that extends A, any S4 method dispatching on A will take precedence over an S3 method dispatching on B. See ?Methods. Cheers, > Ulrich > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] summary of lme4.0 model in package
Dear Joshua,
Thank you for quick reply.
Note that my package has Depends: lme4.0 in DESCRIPTION. It imports and
suggests other packages but not lme4. lme4_1.1-5 is attached because my package
imports (via Imports: in DESCRIPTION) functions from package A, which imports
(via Imports: in DESCRIPTION) functions from package B, which imports (via
Imports: in DESCRIPTION) functions from lme4. Neither packages A nor B import
lme4 related functions.
Should try to import lme4.0 instead of depending on it?
Best regards,
Thierry
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
+ 32 2 525 02 51
+ 32 54 43 61 85
thierry.onkel...@inbo.be
www.inbo.be
To call in the statistician after the experiment is done may be no more than
asking him to perform a post-mortem examination: he may be able to say what the
experiment died of.
~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data.
~ Roger Brinner
The combination of some data and an aching desire for an answer does not ensure
that a reasonable answer can be extracted from a given body of data.
~ John Tukey
Van: Joshua Wiley [mailto:jwiley.ps...@gmail.com]
Verzonden: donderdag 3 april 2014 12:36
Aan: ONKELINX, Thierry
CC: r-devel@r-project.org
Onderwerp: Re: [Rd] summary of lme4.0 model in package
Dear Thierry,
You have lme4.0_0.99-4 attached and lme4_1.1-5 loaded via a namespace. I
wonder if changes between the versions and which was getting called when are
making the difference. In particular, when you source it, I would assume
methods from the attached package are used. When you use the function from the
package, the methods from the dependencies for the package would be used.
Cheers,
Josh
On Thu, Apr 3, 2014 at 3:09 AM, ONKELINX, Thierry
wrote:
Dear all,
My package has Depends: lme4.0 in the DESCRIPTION. I need to extract the fixed
effect of a model and their standard errors. I use coef(summary(model)) inside
a function to do that. Model is the output of a call to glmer() from the lme4.0
package.
coef(summary(model)) throws an error: $ operator is invalid for atomic vectors
I have tracked it down to a problem with summary(model) because
str(summary(model)) gives this
Classes 'summaryDefault', 'table' Named chr [1:3] "1" "mer" "S4"
..- attr(*, "names")= chr [1:3] "Length" "Class" "Mode"
But it should return
Formal class 'summary.mer' [package "lme4.0"] with 42 slots
..@ methTitle: chr "Generalized linear mixed model fit by the Laplace
approximation"
..@ logLik :Class 'logLik' : -2265 (df=12)
--- output snipped ---
What puzzles me is that the function gives the error when called from the
package, but works fine when I source the code of the function manually.
#this fails
MyPackage:MyFunction(model)
#this works
source("MyPackage/R/MyFunction.R")
MyFunction(model)
Any idea on what is going wrong and how to fix this?
sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Dutch_Belgium.1252 LC_CTYPE=Dutch_Belgium.1252
LC_MONETARY=Dutch_Belgium.1252
[4] LC_NUMERIC=C LC_TIME=Dutch_Belgium.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] sendmailR_1.1-2 base64enc_0.1-1 ABV_0.2-21lme4.0_0.99-4
lattice_0.20-28 Matrix_1.1-3
loaded via a namespace (and not attached):
[1] AFLP_0.4.0-66 colorspace_1.2-4dichromat_2.0-0 digest_0.6.4
Epi_1.1.63
[6] fortunes_1.5-2 ggplot2_0.9.3.1.99 grid_3.0.2
gridExtra_0.9.1 gtable_0.1.2
[11] labeling_0.2lme4_1.1-5 lubridate_1.3.3 MASS_7.3-30
memoise_0.1
[16] mgcv_1.7-28 minqa_1.2.3 multcomp_1.3-2 munsell_0.4.2
mvtnorm_0.9-9997
[21] nlme_3.1-115permute_0.8-3 plyr_1.8.1 proto_0.3-10
RColorBrewer_1.0-5
[26] Rcpp_0.11.1 RcppEigen_0.3.2.1.1 reshape_0.8.4 reshape2_1.2.2
RODBC_1.3-10
[31] sandwich_2.3-0 scales_0.2.3seqinr_3.0-9signal_0.7-3
splines_3.0.2
[36] stats4_3.0.2stringr_0.6.2 survival_2.37-7 TH.data_1.0-3
tools_3.0.2
[41] vegan_2.1-41watervogels_0.5-51 xtable_1.7-3zoo_1.7-11
Best regards,
Thierry
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
+ 32 2 525 02 51
+ 32 54 43 61 85
thierry.onkel...@inbo.be
www.inbo.be
To call in the statistician after the experiment is done may be no more than
asking him to perform a post-mortem examination: he may be able to say what the
experiment died of.
~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data.
~ Roge
Re: [Rd] [Bioc-devel] Conflicting definitions for function redefined as S4 generics
On 03/27/2014 06:31 PM, Hervé Pagès wrote: On 03/27/2014 02:13 AM, Ulrich Bodenhofer wrote: [...] For the time being, it seems I have three options: 1) not supplying the sort() function yet (it is not yet in the release, but only in my internal devel version) 2) including a dependency to BiocGenerics 3) leaving the problem open, mentioning in the documentation that users who want to use apcluster in conjunction with Bioconductor should load BiocGenerics first 4) define an S3 method, as mentioned in my previous post H. After a while, I came back to this suggestion. Thanks, Hervé! I now tried it and it indeed works smoothly: all problems I mentioned - as you expected correctly - are resolved. It seems that BiocGenerics screws up my previously defined S4 generic, but leaves my S3 function untouched. Hmm ... The question is whether it is good style to use S3 and S4 together. Actually I am reluctant to think so, but if it helps and creates no other problems whatsoever, why not? Cheers, Ulrich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Timezone warnings on package install in R-alpha
For what it's worth, this issue persists in R-rc_2014-04-02_r65358. Regards, Jon On 24 March 2014 10:40, Jon Clayden wrote: > Dear all, > > As of the current R alpha release, I'm seeing timezone-related warnings on > installing any package (including the recommended ones), which I haven't > seen before. For example, > > [~/Documents/Source/R-alpha]$ bin/R CMD INSTALL ~/git/tractor/lib/reportr > * installing to library '/Users/jon/Documents/Source/R-alpha/library' > * installing *source* package 'reportr' ... > Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London' > Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT' > Warning in as.POSIXlt.POSIXct(x, tz) : > unknown timezone 'America/New_York' > Warning in as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT' > Warning in as.POSIXlt.POSIXct(x, tz) : > unknown timezone 'America/New_York' > ** R > ** preparing package for lazy loading > ** help > *** installing help indices > ** building package indices > ** testing if installed package can be loaded > * DONE (reportr) > > This is R-alpha r65266, built from source on OS X 10.9.2 using gcc 4.8.2. > I ran configure with > > ./configure --with-blas="-framework Accelerate" --with-lapack > --with-system-zlib --enable-memory-profiling > --with-tcl-config=/System/Library/Frameworks/Tcl.framework/tclConfig.sh > --with-tk-config=/System/Library/Frameworks/Tk.framework/tkConfig.sh > CC=gcc-4.8 CXX=g++-4.8 OBJC=clang F77=gfortran-4.8 FC=gfortran-4.8 > CPPFLAGS="-D__ACCELERATE__" CFLAGS="-mtune=native -g -O2" > CXXFLAGS="-mtune=native -g -O2" FFLAGS="-mtune=native -g -O2" > FCFLAGS="-mtune=native -g -O2" > > Session info is > > R version 3.1.0 alpha (2014-03-23 r65266) > Platform: x86_64-apple-darwin13.1.0 (64-bit) > > locale: > [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > I see some related material in the NEWS, but no indication that these > warnings are expected. I hope this report is helpful. > > All the best, > Jon > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] summary of lme4.0 model in package
Dear Thierry,
You have lme4.0_0.99-4 attached and lme4_1.1-5 loaded via a namespace.
I wonder if changes between the versions and which was getting called when
are making the difference. In particular, when you source it, I would
assume methods from the attached package are used. When you use the
function from the package, the methods from the dependencies for the
package would be used.
Cheers,
Josh
On Thu, Apr 3, 2014 at 3:09 AM, ONKELINX, Thierry
wrote:
> Dear all,
>
> My package has Depends: lme4.0 in the DESCRIPTION. I need to extract the
> fixed effect of a model and their standard errors. I use
> coef(summary(model)) inside a function to do that. Model is the output of a
> call to glmer() from the lme4.0 package.
>
> coef(summary(model)) throws an error: $ operator is invalid for atomic
> vectors
>
> I have tracked it down to a problem with summary(model) because
> str(summary(model)) gives this
>
> Classes 'summaryDefault', 'table' Named chr [1:3] "1" "mer" "S4"
> ..- attr(*, "names")= chr [1:3] "Length" "Class" "Mode"
>
> But it should return
>
> Formal class 'summary.mer' [package "lme4.0"] with 42 slots
> ..@ methTitle: chr "Generalized linear mixed model fit by the Laplace
> approximation"
> ..@ logLik :Class 'logLik' : -2265 (df=12)
> --- output snipped ---
>
> What puzzles me is that the function gives the error when called from the
> package, but works fine when I source the code of the function manually.
>
> #this fails
> MyPackage:MyFunction(model)
> #this works
> source("MyPackage/R/MyFunction.R")
> MyFunction(model)
>
> Any idea on what is going wrong and how to fix this?
>
> sessionInfo()
> R version 3.0.2 (2013-09-25)
> Platform: i386-w64-mingw32/i386 (32-bit)
>
> locale:
> [1] LC_COLLATE=Dutch_Belgium.1252 LC_CTYPE=Dutch_Belgium.1252
> LC_MONETARY=Dutch_Belgium.1252
> [4] LC_NUMERIC=C LC_TIME=Dutch_Belgium.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] sendmailR_1.1-2 base64enc_0.1-1 ABV_0.2-21
> lme4.0_0.99-4 lattice_0.20-28 Matrix_1.1-3
>
> loaded via a namespace (and not attached):
> [1] AFLP_0.4.0-66 colorspace_1.2-4dichromat_2.0-0
> digest_0.6.4Epi_1.1.63
> [6] fortunes_1.5-2 ggplot2_0.9.3.1.99 grid_3.0.2
> gridExtra_0.9.1 gtable_0.1.2
> [11] labeling_0.2lme4_1.1-5 lubridate_1.3.3
> MASS_7.3-30 memoise_0.1
> [16] mgcv_1.7-28 minqa_1.2.3 multcomp_1.3-2
> munsell_0.4.2 mvtnorm_0.9-9997
> [21] nlme_3.1-115permute_0.8-3 plyr_1.8.1
> proto_0.3-10RColorBrewer_1.0-5
> [26] Rcpp_0.11.1 RcppEigen_0.3.2.1.1 reshape_0.8.4
> reshape2_1.2.2 RODBC_1.3-10
> [31] sandwich_2.3-0 scales_0.2.3seqinr_3.0-9
> signal_0.7-3splines_3.0.2
> [36] stats4_3.0.2stringr_0.6.2 survival_2.37-7
> TH.data_1.0-3 tools_3.0.2
> [41] vegan_2.1-41watervogels_0.5-51 xtable_1.7-3zoo_1.7-11
>
>
> Best regards,
>
> Thierry
>
>
> ir. Thierry Onkelinx
> Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
> Forest
> team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
> Kliniekstraat 25
> 1070 Anderlecht
> Belgium
> + 32 2 525 02 51
> + 32 54 43 61 85
> thierry.onkel...@inbo.be
> www.inbo.be
>
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of.
> ~ Sir Ronald Aylmer Fisher
>
> The plural of anecdote is not data.
> ~ Roger Brinner
>
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
>
>
> * * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
> Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver
> weer en binden het INBO onder geen enkel beding, zolang dit bericht niet
> bevestigd is door een geldig ondertekend document.
> The views expressed in this message and any annex are purely those of the
> writer and may not be regarded as stating an official position of INBO, as
> long as the message is not confirmed by a duly signed document.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Joshua Wiley
Ph.D. Student, Health Psychology
University of California, Los Angeles
http://joshuawiley.com/
Senior Analyst - Elkhart Group Ltd.
http://elkhartgroup.com
260.673.5518
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] summary of lme4.0 model in package
Dear all,
My package has Depends: lme4.0 in the DESCRIPTION. I need to extract the fixed
effect of a model and their standard errors. I use coef(summary(model)) inside
a function to do that. Model is the output of a call to glmer() from the lme4.0
package.
coef(summary(model)) throws an error: $ operator is invalid for atomic vectors
I have tracked it down to a problem with summary(model) because
str(summary(model)) gives this
Classes 'summaryDefault', 'table' Named chr [1:3] "1" "mer" "S4"
..- attr(*, "names")= chr [1:3] "Length" "Class" "Mode"
But it should return
Formal class 'summary.mer' [package "lme4.0"] with 42 slots
..@ methTitle: chr "Generalized linear mixed model fit by the Laplace
approximation"
..@ logLik :Class 'logLik' : -2265 (df=12)
--- output snipped ---
What puzzles me is that the function gives the error when called from the
package, but works fine when I source the code of the function manually.
#this fails
MyPackage:MyFunction(model)
#this works
source("MyPackage/R/MyFunction.R")
MyFunction(model)
Any idea on what is going wrong and how to fix this?
sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Dutch_Belgium.1252 LC_CTYPE=Dutch_Belgium.1252
LC_MONETARY=Dutch_Belgium.1252
[4] LC_NUMERIC=C LC_TIME=Dutch_Belgium.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] sendmailR_1.1-2 base64enc_0.1-1 ABV_0.2-21lme4.0_0.99-4
lattice_0.20-28 Matrix_1.1-3
loaded via a namespace (and not attached):
[1] AFLP_0.4.0-66 colorspace_1.2-4dichromat_2.0-0 digest_0.6.4
Epi_1.1.63
[6] fortunes_1.5-2 ggplot2_0.9.3.1.99 grid_3.0.2
gridExtra_0.9.1 gtable_0.1.2
[11] labeling_0.2lme4_1.1-5 lubridate_1.3.3 MASS_7.3-30
memoise_0.1
[16] mgcv_1.7-28 minqa_1.2.3 multcomp_1.3-2 munsell_0.4.2
mvtnorm_0.9-9997
[21] nlme_3.1-115permute_0.8-3 plyr_1.8.1 proto_0.3-10
RColorBrewer_1.0-5
[26] Rcpp_0.11.1 RcppEigen_0.3.2.1.1 reshape_0.8.4 reshape2_1.2.2
RODBC_1.3-10
[31] sandwich_2.3-0 scales_0.2.3seqinr_3.0-9signal_0.7-3
splines_3.0.2
[36] stats4_3.0.2stringr_0.6.2 survival_2.37-7 TH.data_1.0-3
tools_3.0.2
[41] vegan_2.1-41watervogels_0.5-51 xtable_1.7-3zoo_1.7-11
Best regards,
Thierry
ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
+ 32 2 525 02 51
+ 32 54 43 61 85
thierry.onkel...@inbo.be
www.inbo.be
To call in the statistician after the experiment is done may be no more than
asking him to perform a post-mortem examination: he may be able to say what the
experiment died of.
~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data.
~ Roger Brinner
The combination of some data and an aching desire for an answer does not ensure
that a reasonable answer can be extracted from a given body of data.
~ John Tukey
* * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en
binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is
door een geldig ondertekend document.
The views expressed in this message and any annex are purely those of the
writer and may not be regarded as stating an official position of INBO, as long
as the message is not confirmed by a duly signed document.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
