Re: [Rd] cannot build R-devel (>= r49747)
Romain Francois wrote: Hello, I've tried several times yesterday to build R-devel and I consistently get this error when I "make" : mkdir -p -- ../../../library/base/R make[3]: Leaving directory `/tmp/R-devel/src/library/profile' make[3]: Entering directory `/tmp/R-devel/src/library/base' building package 'base' make[4]: Entering directory `/tmp/R-devel/src/library/base' mkdir -p -- ../../../library/base/demo mkdir -p -- ../../../library/base/po make[4]: Leaving directory `/tmp/R-devel/src/library/base' Error: unprotect_ptr: pointer not found Execution halted make[3]: *** [all] Error 1 make[3]: Leaving directory `/tmp/R-devel/src/library/base' make[2]: *** [R] Error 1 make[2]: Leaving directory `/tmp/R-devel/src/library' make[1]: *** [R] Error 1 make[1]: Leaving directory `/tmp/R-devel/src' make: *** [R] Error 1 I tried this morning to step down and I believe this has been introduced by rev 49747: - r49747 | murdoch | 2009-09-18 14:10:55 -0400 (Fri, 18 Sep 2009) | 1 line Changed paths: M /trunk/src/include/Defn.h M /trunk/src/include/Parse.h M /trunk/src/main/gram.c M /trunk/src/main/gram.y M /trunk/src/main/main.c M /trunk/src/main/memory.c Allow parsing in the middle of a REPL on a file, without messing up the source record for the file. - ... which makes sense since it looks like a parser issue. I can build revision 49746. This is a fedora 11 : $ uname -a Linux santorini 2.6.29.6-217.2.16.fc11.i686.PAE #1 SMP Mon Aug 24 17:16:21 EDT 2009 i686 i686 i386 GNU/Linux I'm not sure what I can do to help fixing this. Can someone else with a fedora replicate this ? Romain This could be pretty serious. unprotect_ptr is used where the usual PROTECT/UNPROTECT mechanisms don't work because things do not follow strict stack discipline. The main spot is when the parser uses lookahead to distinguish different constructs. I don't think I have ever seen it fail like that, but a possible reason could be that the wrong pointer got removed from the protection stack. Or memory corruption in the stack itself of course. A bit odd if the former sort of bug should be unportable, though. It is not happening for me on 32bit fedora 9. It could be useful if you could drill a little further down to see exactly how R is invoked at the failure, incl content input file(s), and maybe redo the run with debugging turned on so that we can see who is trying to unprotect what. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
On 09/22/2009 09:17 AM, Peter Dalgaard wrote: Romain Francois wrote: Hello, I've tried several times yesterday to build R-devel and I consistently get this error when I "make" : mkdir -p -- ../../../library/base/R make[3]: Leaving directory `/tmp/R-devel/src/library/profile' make[3]: Entering directory `/tmp/R-devel/src/library/base' building package 'base' make[4]: Entering directory `/tmp/R-devel/src/library/base' mkdir -p -- ../../../library/base/demo mkdir -p -- ../../../library/base/po make[4]: Leaving directory `/tmp/R-devel/src/library/base' Error: unprotect_ptr: pointer not found Execution halted make[3]: *** [all] Error 1 make[3]: Leaving directory `/tmp/R-devel/src/library/base' make[2]: *** [R] Error 1 make[2]: Leaving directory `/tmp/R-devel/src/library' make[1]: *** [R] Error 1 make[1]: Leaving directory `/tmp/R-devel/src' make: *** [R] Error 1 I tried this morning to step down and I believe this has been introduced by rev 49747: - r49747 | murdoch | 2009-09-18 14:10:55 -0400 (Fri, 18 Sep 2009) | 1 line Changed paths: M /trunk/src/include/Defn.h M /trunk/src/include/Parse.h M /trunk/src/main/gram.c M /trunk/src/main/gram.y M /trunk/src/main/main.c M /trunk/src/main/memory.c Allow parsing in the middle of a REPL on a file, without messing up the source record for the file. - ... which makes sense since it looks like a parser issue. I can build revision 49746. This is a fedora 11 : $ uname -a Linux santorini 2.6.29.6-217.2.16.fc11.i686.PAE #1 SMP Mon Aug 24 17:16:21 EDT 2009 i686 i686 i386 GNU/Linux I'm not sure what I can do to help fixing this. Can someone else with a fedora replicate this ? Romain This could be pretty serious. unprotect_ptr is used where the usual PROTECT/UNPROTECT mechanisms don't work because things do not follow strict stack discipline. The main spot is when the parser uses lookahead to distinguish different constructs. Yes. This makes sense since rev 49747 was a fix to another bug when R reenters the parser. See the thread : "[Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built segfaults on Debian Squeeze" I don't think I have ever seen it fail like that, but a possible reason could be that the wrong pointer got removed from the protection stack. Or memory corruption in the stack itself of course. A bit odd if the former sort of bug should be unportable, though. It is not happening for me on 32bit fedora 9. Thanks for this. I'll digg a little deeper It could be useful if you could drill a little further down to see exactly how R is invoked at the failure, incl content input file(s), and maybe redo the run with debugging turned on so that we can see who is trying to unprotect what. -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/yw8E : New R package : sos |- http://tr.im/y8y0 : search the graph gallery from R `- http://tr.im/y8wY : new R package : ant __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Ubuntu Hardy python-rpy package missing _rpy2092 (PR#13962)
Full_Name: Dennis Ristuccia Version: R version 2.9.2 (2009-08-24) OS: Ubuntu Hardy 8.04 Submission from: (NULL) (18.157.249.21) Hi guys, I'm running into an issue with the python-rpy ubuntu hardy package. Heres the output: r...@tak ~# python Python 2.5.2 (r252:60911, Jul 22 2009, 15:35:03) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import rpy Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/site-packages/rpy.py", line 134, in """ % RVERSION) RuntimeError: No module named _rpy2092 RPy module can not be imported. Please check if your rpy installation supports R 2.9.2. If you have multiple R versions installed, you may need to set RHOME before importing rpy. For example: >>> from rpy_options import set_options >>> set_options(RHOME='c:/progra~1/r/rw2011/') >>> from rpy import * >>> I checked in /usr/lib/python2.5/site-packages/ and there is only _rpy2091.so - _rpy2092.so is missing. I experienced the same issue the last time I upgraded R from the hardy mirror you guys have. I ended up doing some hackery by using the debian lenny python-rpy package, I'd rather avoid that this time around. Thanks -- DennisR __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Random.seed not found (PR#13963)
R 2.9.1 and 2.9.2 report "not found" when I try to save .Random.seed for later restore, however, the manual ?.Random.seed says that it still exists. -- Andreas Westfeld, 0432 01CC F511 9E2B 0B57 5993 0B22 98F8 4AD8 EEEA HTW Dresden, Fakultät Informatik/Mathematik Informatikrecht/Informationssicherheit, Zimmer Z337 Tel. +49-351-462-3372, http://www.htw-dresden.de/~westfeld __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A couple of suggestions: source function (package base)
Hi,
I've been calling the function "source" (package base) from Tinn-R editor to
send files, marked blocks and selections to R interpreter because it avoids a
lot of problems related with input/output synchronization in the Rgui output!
The new RGedit plugin is also using this function in this way, and we are
finishing a new version of a plugin to Vim (Vim-R-plugin2) which uses
also source().
So, I would like to propose two small changes in this function:
1. The "max.deparse" parameter could be a global option with 150 as
the default value.
Why? It will avoid the need to send this parameter repeatedly,
which causes visual pollution in the console.
2. A new parameter (for example: "new.line") to allow the user to
define whether a new blank line between the output and the subsequent
input is desired when "echo=T".
Example, suppose I have in the editor the three lines below:
a=rnorm(10)
a
sort(a)
and I would like to send it to R interpreter (file, block or selection).
The current output is (using Vim-R-plugin2):
---
> source('/tmp/.Rsource-jcfaria', echo=TRUE, max.deparse=50)
> a=rnorm(10)
> a
[1] 0.08648104 -1.74996635 0.61027538 0.42042031 -0.02025884 -0.39891256
[7] -0.30219635 -0.84476668 1.06341674 -0.12030620
> sort(a)
[1] -1.74996635 -0.84476668 -0.39891256 -0.30219635 -0.12030620 -0.02025884
[7] 0.08648104 0.42042031 0.61027538 1.06341674
>
How it could be (desired):
-
> source('/tmp/.Rsource-jcfaria', echo=TRUE)
> a=rnorm(10)
> a
[1] 0.08648104 -1.74996635 0.61027538 0.42042031 -0.02025884 -0.39891256
[7] -0.30219635 -0.84476668 1.06341674 -0.12030620
> sort(a)
[1] -1.74996635 -0.84476668 -0.39891256 -0.30219635 -0.12030620 -0.02025884
[7] 0.08648104 0.42042031 0.61027538 1.06341674
>
I think that both "new.line" and "max.deparse" could be both global options.
max.deparse = 150 (default)
new.line= FALSE (default)
Why? To get a clearer output.
In this way the args of this function would become:
---
function (file, local = FALSE, echo = verbose, print.eval = echo,
verbose = getOption("verbose"), prompt.echo = getOption("prompt"),
-> max.deparse.length = getOption("max.deparse"), new.line =
getOption("new.line"), <-
chdir = FALSE, encoding = getOption("encoding"), continue.echo =
getOption("continue"),
skip.echo = 0, keep.source = getOption("keep.source"))
For GUI/Editor developers this changes will allow to send simpler
instructions and
make nice and standard interfaces.
Is it possible to create the "new.line" argument and to put it and
"max.deparse" between the global options?
I would prefer not creating a custom version of source() because I
think that these changes would be of
benefit to other people and projects.
Thanks,
--
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
Jose Claudio Faria
Estatistica - prof. Titular
UESC/DCET/Brasil
joseclaudio.fa...@gmail.com
joseclaudio.fa...@terra.com.br
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in r-devel/R/src/library/base/man/files.Rd
files.Rd has the following typo, line 57: LIBK points to an actual file ... should be LINK Stephen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
Romain Francois wrote: > However, this might be relevant about my setting, I have the > "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it > to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
On 09/22/2009 11:25 AM, Peter Dalgaard wrote: Romain Francois wrote: However, this might be relevant about my setting, I have the "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). I can now track this down to these lines in gram.(y|c) if (!isNull(ParseState.SrcFile)) UNPROTECT_PTR(ParseState.SrcFile); The error occurs the first time ParseState.SrcFile is not null. -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/yw8E : New R package : sos |- http://tr.im/y8y0 : search the graph gallery from R `- http://tr.im/y8wY : new R package : ant __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
On 22/09/2009 5:30 AM, Romain Francois wrote: On 09/22/2009 11:25 AM, Peter Dalgaard wrote: Romain Francois wrote: However, this might be relevant about my setting, I have the "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). I can now track this down to these lines in gram.(y|c) if (!isNull(ParseState.SrcFile)) UNPROTECT_PTR(ParseState.SrcFile); The error occurs the first time ParseState.SrcFile is not null. Thanks for this info. I can track it down now. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
On 09/22/2009 11:41 AM, Duncan Murdoch wrote: On 22/09/2009 5:30 AM, Romain Francois wrote: On 09/22/2009 11:25 AM, Peter Dalgaard wrote: Romain Francois wrote: However, this might be relevant about my setting, I have the "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). I can now track this down to these lines in gram.(y|c) if (!isNull(ParseState.SrcFile)) UNPROTECT_PTR(ParseState.SrcFile); The error occurs the first time ParseState.SrcFile is not null. Thanks for this info. I can track it down now. Duncan Murdoch Good. You'll probably be able to fix it much faster. My only guess is that some extra care is needed when UNPROTECT_PTR'ing environments, because if I comment this, then the same problem occurs in R_FinalizeSrcRefState(SrcRefState *state) at the end of the parse. Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/yw8E : New R package : sos |- http://tr.im/y8y0 : search the graph gallery from R `- http://tr.im/y8wY : new R package : ant __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
On 22/09/2009 5:50 AM, Romain Francois wrote: On 09/22/2009 11:41 AM, Duncan Murdoch wrote: On 22/09/2009 5:30 AM, Romain Francois wrote: On 09/22/2009 11:25 AM, Peter Dalgaard wrote: Romain Francois wrote: However, this might be relevant about my setting, I have the "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). I can now track this down to these lines in gram.(y|c) if (!isNull(ParseState.SrcFile)) UNPROTECT_PTR(ParseState.SrcFile); The error occurs the first time ParseState.SrcFile is not null. Thanks for this info. I can track it down now. Duncan Murdoch Good. You'll probably be able to fix it much faster. My only guess is that some extra care is needed when UNPROTECT_PTR'ing environments, because if I comment this, then the same problem occurs in R_FinalizeSrcRefState(SrcRefState *state) at the end of the parse. I doubt if it has to do with the type of that object, but that object is treated specially, because it is a global value that can change during the parse. At some point I'd guess I unprotected it twice, or failed to initialize it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Random.seed not found (PR#13963)
On 21/09/2009 1:25 PM, andreas.westf...@htw-dresden.de wrote: R 2.9.1 and 2.9.2 report "not found" when I try to save .Random.seed for later restore, however, the manual ?.Random.seed says that it still exists. .Random.seed is created the first time you use the random number generators. I'm guessing you're attempting to save it before using it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A couple of suggestions: source function (package base)
I would find that useful too particularly for running long output from Stangle.
On Mon, Sep 21, 2009 at 9:22 PM, Jose Claudio Faria
wrote:
> Hi,
>
> I've been calling the function "source" (package base) from Tinn-R editor to
> send files, marked blocks and selections to R interpreter because it avoids a
> lot of problems related with input/output synchronization in the Rgui output!
>
> The new RGedit plugin is also using this function in this way, and we are
> finishing a new version of a plugin to Vim (Vim-R-plugin2) which uses
> also source().
>
> So, I would like to propose two small changes in this function:
>
> 1. The "max.deparse" parameter could be a global option with 150 as
> the default value.
>
> Why? It will avoid the need to send this parameter repeatedly,
> which causes visual pollution in the console.
>
> 2. A new parameter (for example: "new.line") to allow the user to
> define whether a new blank line between the output and the subsequent
> input is desired when "echo=T".
>
> Example, suppose I have in the editor the three lines below:
>
> a=rnorm(10)
> a
> sort(a)
>
> and I would like to send it to R interpreter (file, block or selection).
>
> The current output is (using Vim-R-plugin2):
> ---
>> source('/tmp/.Rsource-jcfaria', echo=TRUE, max.deparse=50)
>
>> a=rnorm(10)
>
>> a
> [1] 0.08648104 -1.74996635 0.61027538 0.42042031 -0.02025884 -0.39891256
> [7] -0.30219635 -0.84476668 1.06341674 -0.12030620
>
>> sort(a)
> [1] -1.74996635 -0.84476668 -0.39891256 -0.30219635 -0.12030620 -0.02025884
> [7] 0.08648104 0.42042031 0.61027538 1.06341674
>
>>
>
>
> How it could be (desired):
> -
>> source('/tmp/.Rsource-jcfaria', echo=TRUE)
>> a=rnorm(10)
>> a
> [1] 0.08648104 -1.74996635 0.61027538 0.42042031 -0.02025884 -0.39891256
> [7] -0.30219635 -0.84476668 1.06341674 -0.12030620
>> sort(a)
> [1] -1.74996635 -0.84476668 -0.39891256 -0.30219635 -0.12030620 -0.02025884
> [7] 0.08648104 0.42042031 0.61027538 1.06341674
>>
>
> I think that both "new.line" and "max.deparse" could be both global options.
>
> max.deparse = 150 (default)
> new.line = FALSE (default)
>
> Why? To get a clearer output.
>
> In this way the args of this function would become:
> ---
> function (file, local = FALSE, echo = verbose, print.eval = echo,
> verbose = getOption("verbose"), prompt.echo = getOption("prompt"),
> -> max.deparse.length = getOption("max.deparse"), new.line =
> getOption("new.line"), <-
> chdir = FALSE, encoding = getOption("encoding"), continue.echo =
> getOption("continue"),
> skip.echo = 0, keep.source = getOption("keep.source"))
>
> For GUI/Editor developers this changes will allow to send simpler
> instructions and
> make nice and standard interfaces.
>
> Is it possible to create the "new.line" argument and to put it and
> "max.deparse" between the global options?
>
> I would prefer not creating a custom version of source() because I
> think that these changes would be of
> benefit to other people and projects.
>
> Thanks,
> --
> ///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
> Jose Claudio Faria
> Estatistica - prof. Titular
> UESC/DCET/Brasil
> joseclaudio.fa...@gmail.com
> joseclaudio.fa...@terra.com.br
> ///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rcmdr package dependencies
Dear r-devel members,
My Rcmdr package "depends" on several other packages (tcltk, grDevices,
utils, and car) and "suggests" a number of others (abind, aplpack,
colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
distinction is that I don't want all of these packages to load when the
Rcmdr loads; rather, the "suggested" packages are loaded as they're needed.
But all of the packages -- both those under "depends" and those under
"suggests" -- really are necessary for all of the features of the Rcmdr to
work. For example, if the "leaps" package is absent, then the "Subset model
selection" item in the "Models" menu is suppressed.
This arrangement works reasonably well, but it makes it awkward to install
the Rcmdr. If the user issues the command install.packages("Rcmdr"), then
the "suggested" packages aren't installed. On the other hand, if the user
issues the command install.packages("Rcmdr", dependencies=TRUE), which is
what I currently recommend, then "suggested" packages are installed
recursively, causing dozens of packages, most of them actually unnecessary,
to be installed. This issue has been growing more acute, and at this point
even with a fast Internet connection it takes quite a while for all of the
dependencies to download and install.
I wonder whether I've missed something. Is there a way for me to arrange the
Rcmdr package dependencies so that only the necessary packages (those
currently listed under both "depends" and "suggests" and the packages on
which they "depend") are installed along with the Rcmdr, but the currently
"suggested" packages aren't loaded when the Rcmdr loads?
Any help would be appreciated.
John
--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] odd (erroneous?) results from gls
A couple weeks ago I posted a message on this topic to r-help, the response was that this seemed like odd behavior, and that I ought to post it to one of the developer lists. I posted to r-sig-mixed-models, but didn't get any response. So, with good intentions, I decided to try posting once more, but to this more general list. The goal is (1) FYI, to make you aware of this issue, in case it is an error in gls (2) For my information, in case I have made an error, in the hope that one of you folks might be able to correct me. Thanks in advance for your time. The issue is in 2 parts. (A) I've used gls to fit a model with two fixed effects and a corExp object. By my count, this fitting process estimates 5 parameters: (Intercept), l10area, newx, range, and nugget. With 118 total df, there should be 118 - 5 = 113 residual df. However, the output from summary.gls reports 115 residual degrees of freedom. Is this an error in summary or gls, or is there an error in my count? (B) Summary.gls reports logLik=-273.6. Using my count of 5 estimated parameters, the AIC should be -2*(-273.6) + 2*5 = 557.2. However, summary.gls reports an AIC of 559.2. If one works backwards from the reported AIC of 559.2, it seems that gls believes it has estimated 6 parameters in the fitting process. Again, is this an error in gls, or an error on my part? Copied from R terminal: > > summary(sppl.i.ex) Generalized least squares fit by maximum likelihood Model: all.all.rch ~ l10area + newx Data: gtemp AIC BIClogLik 559.167 575.7911 -273.5835 Correlation Structure: Exponential spatial correlation Formula: ~x + y | area Parameter estimate(s): range nugget 15.4448835 0.3741476 Coefficients: Value Std.Error t-value p-value (Intercept) 7.621306 0.7648135 9.964921 0. l10area 6.332931 0.5589199 11.330659 0. newx0.066535 0.0204417 3.254857 0.0015 Correlation: (Intr) l10are l10area -0.605 newx 0.358 -0.024 Standardized residuals: Min Q1Med Q3Max -3.0035983 -0.5990432 -0.2226852 0.5113270 2.263 Residual standard error: 2.820337 Degrees of freedom: 118 total; 115 residual Tim Handley Fire Effects Monitor Santa Monica Mountains National Recreation Area 401 W. Hillcrest Dr. Thousand Oaks, CA 91360 805-370-2347 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
I believe this is fixed now (as of r49786). The problem is that the parse code does bad things with the protection stack -- rather than pairing PROTECT with UNPROTECT, it does bulk unprotects by saving and restoring the stack pointer -- and in the new code the ParseState.SrcFile ended up getting released more than once. Duncan Murdoch On 9/22/2009 5:50 AM, Romain Francois wrote: On 09/22/2009 11:41 AM, Duncan Murdoch wrote: On 22/09/2009 5:30 AM, Romain Francois wrote: On 09/22/2009 11:25 AM, Peter Dalgaard wrote: Romain Francois wrote: However, this might be relevant about my setting, I have the "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). I can now track this down to these lines in gram.(y|c) if (!isNull(ParseState.SrcFile)) UNPROTECT_PTR(ParseState.SrcFile); The error occurs the first time ParseState.SrcFile is not null. Thanks for this info. I can track it down now. Duncan Murdoch Good. You'll probably be able to fix it much faster. My only guess is that some extra care is needed when UNPROTECT_PTR'ing environments, because if I comment this, then the same problem occurs in R_FinalizeSrcRefState(SrcRefState *state) at the end of the parse. Romain __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot build R-devel (>= r49747)
Thanks. Works for me also now. On 09/22/2009 06:17 PM, Duncan Murdoch wrote: I believe this is fixed now (as of r49786). The problem is that the parse code does bad things with the protection stack -- rather than pairing PROTECT with UNPROTECT, it does bulk unprotects by saving and restoring the stack pointer -- and in the new code the ParseState.SrcFile ended up getting released more than once. Duncan Murdoch On 9/22/2009 5:50 AM, Romain Francois wrote: On 09/22/2009 11:41 AM, Duncan Murdoch wrote: On 22/09/2009 5:30 AM, Romain Francois wrote: On 09/22/2009 11:25 AM, Peter Dalgaard wrote: Romain Francois wrote: However, this might be relevant about my setting, I have the "R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it to "no" it builds correctly. AHA! Yes, that makes sense R_KEEP_PKG_SOURCE=yes make breaks for me too with the unprotect_ptr message (SUSE 64bit this time). I can now track this down to these lines in gram.(y|c) if (!isNull(ParseState.SrcFile)) UNPROTECT_PTR(ParseState.SrcFile); The error occurs the first time ParseState.SrcFile is not null. Thanks for this info. I can track it down now. Duncan Murdoch Good. You'll probably be able to fix it much faster. My only guess is that some extra care is needed when UNPROTECT_PTR'ing environments, because if I comment this, then the same problem occurs in R_FinalizeSrcRefState(SrcRefState *state) at the end of the parse. Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/yw8E : New R package : sos |- http://tr.im/y8y0 : search the graph gallery from R `- http://tr.im/y8wY : new R package : ant __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] odd (erroneous?) results from gls
timothy_hand...@nps.gov wrote:
A couple weeks ago I posted a message on this topic to r-help, the response
was that this seemed like odd behavior, and that I ought to post it to one
of the developer lists. I posted to r-sig-mixed-models, but didn't get any
response. So, with good intentions, I decided to try posting once more, but
to this more general list.
The goal is (1) FYI, to make you aware of this issue, in case it is an
error in gls (2) For my information, in case I have made an error, in the
hope that one of you folks might be able to correct me. Thanks in advance
for your time.
The issue is in 2 parts.
(A) I've used gls to fit a model with two fixed effects and a corExp
object. By my count, this fitting process estimates 5 parameters:
(Intercept), l10area, newx, range, and nugget. With 118 total df, there
should be 118 - 5 = 113 residual df. However, the output from summary.gls
reports 115 residual degrees of freedom. Is this an error in summary or
gls, or is there an error in my count?
Those for the correlation structure are not counted for these residuals
as you can find in
nlme:::print.summary.gls
that contains the line
cat("Degrees of freedom:", dd[["N"]], "total;", dd[["N"]] -
dd[["p"]], "residual\n")
(B) Summary.gls reports logLik=-273.6. Using my count of 5 estimated
parameters, the AIC should be -2*(-273.6) + 2*5 = 557.2. However,
summary.gls reports an AIC of 559.2. If one works backwards from the
reported AIC of 559.2, it seems that gls believes it has estimated 6
parameters in the fitting process. Again, is this an error in gls, or an
error on my part?
1 additional was used for the estimation of the variance. Accordingly
nlme:::logLik.gls
contains the line
attr(val, "df") <- p + length(coef(object[["modelStruct"]])) + 1
The AICs should be comparable at least within R and if others think 5
rather than 6 should be used its still fine since the difference will be
there in all models to be compared.
Best wishes,
Uwe Ligges
Copied from R terminal:
summary(sppl.i.ex)
Generalized least squares fit by maximum likelihood
Model: all.all.rch ~ l10area + newx
Data: gtemp
AIC BIClogLik
559.167 575.7911 -273.5835
Correlation Structure: Exponential spatial correlation
Formula: ~x + y | area
Parameter estimate(s):
range nugget
15.4448835 0.3741476
Coefficients:
Value Std.Error t-value p-value
(Intercept) 7.621306 0.7648135 9.964921 0.
l10area 6.332931 0.5589199 11.330659 0.
newx0.066535 0.0204417 3.254857 0.0015
Correlation:
(Intr) l10are
l10area -0.605
newx 0.358 -0.024
Standardized residuals:
Min Q1Med Q3Max
-3.0035983 -0.5990432 -0.2226852 0.5113270 2.263
Residual standard error: 2.820337
Degrees of freedom: 118 total; 115 residual
Tim Handley
Fire Effects Monitor
Santa Monica Mountains National Recreation Area
401 W. Hillcrest Dr.
Thousand Oaks, CA 91360
805-370-2347
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
John Fox wrote:
Dear r-devel members,
My Rcmdr package "depends" on several other packages (tcltk, grDevices,
utils, and car) and "suggests" a number of others (abind, aplpack,
colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
distinction is that I don't want all of these packages to load when the
Rcmdr loads; rather, the "suggested" packages are loaded as they're needed.
But all of the packages -- both those under "depends" and those under
"suggests" -- really are necessary for all of the features of the Rcmdr to
work. For example, if the "leaps" package is absent, then the "Subset model
selection" item in the "Models" menu is suppressed.
This arrangement works reasonably well, but it makes it awkward to install
the Rcmdr. If the user issues the command install.packages("Rcmdr"), then
the "suggested" packages aren't installed. On the other hand, if the user
issues the command install.packages("Rcmdr", dependencies=TRUE), which is
what I currently recommend, then "suggested" packages are installed
recursively, causing dozens of packages, most of them actually unnecessary,
to be installed. This issue has been growing more acute, and at this point
even with a fast Internet connection it takes quite a while for all of the
dependencies to download and install.
I wonder whether I've missed something. Is there a way for me to arrange the
Rcmdr package dependencies so that only the necessary packages (those
currently listed under both "depends" and "suggests" and the packages on
which they "depend") are installed along with the Rcmdr, but the currently
"suggested" packages aren't loaded when the Rcmdr loads?
Dear John,
no, this is not possible.
Consider your package A (or Rcmdr) suggests B that suggests C.
Then A::foo uses the function B::bar which only works if C::dep is
present. B works essentially without C but it requires C just to make
bar work. Then this means your A::foo won't work if C is not installed
and you won't get it with the setup mentioned above.
In summary, I fear what you want might work well *now* (by chance), but
it does not work in general.
Best wishes,
Uwe
Any help would be appreciated.
John
--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
Create a package called RcmdrInstall, say, with no content and have it
depend on Rcmdr. RcmdrInstall would have all packages as dependencies
while Rcmdr would only have the essential packages as dependencies.
Install RcmdrInstall. That would also force Rcmdr to be installed.
Now issue:
library(Rcmdr)
as before and the non-essentials won't be loaded.
Thus the only difference between the current procedure and the new
procedure as far as the user is concerned is that they install
RcmdrInstall rather than Rcmdr. They load and run Rcmdr in the same
way.
On Tue, Sep 22, 2009 at 9:15 AM, John Fox wrote:
> Dear r-devel members,
>
> My Rcmdr package "depends" on several other packages (tcltk, grDevices,
> utils, and car) and "suggests" a number of others (abind, aplpack,
> colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
> mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
> distinction is that I don't want all of these packages to load when the
> Rcmdr loads; rather, the "suggested" packages are loaded as they're needed.
> But all of the packages -- both those under "depends" and those under
> "suggests" -- really are necessary for all of the features of the Rcmdr to
> work. For example, if the "leaps" package is absent, then the "Subset model
> selection" item in the "Models" menu is suppressed.
>
> This arrangement works reasonably well, but it makes it awkward to install
> the Rcmdr. If the user issues the command install.packages("Rcmdr"), then
> the "suggested" packages aren't installed. On the other hand, if the user
> issues the command install.packages("Rcmdr", dependencies=TRUE), which is
> what I currently recommend, then "suggested" packages are installed
> recursively, causing dozens of packages, most of them actually unnecessary,
> to be installed. This issue has been growing more acute, and at this point
> even with a fast Internet connection it takes quite a while for all of the
> dependencies to download and install.
>
> I wonder whether I've missed something. Is there a way for me to arrange the
> Rcmdr package dependencies so that only the necessary packages (those
> currently listed under both "depends" and "suggests" and the packages on
> which they "depend") are installed along with the Rcmdr, but the currently
> "suggested" packages aren't loaded when the Rcmdr loads?
>
> Any help would be appreciated.
>
> John
>
> --
> John Fox, Professor
> Department of Sociology
> McMaster University
> Hamilton, Ontario, Canada
> web: socserv.mcmaster.ca/jfox
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
Dear Uwe,
> -Original Message-
> From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de]
> Sent: September-22-09 2:17 PM
> To: John Fox
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Rcmdr package dependencies
>
>
>
> John Fox wrote:
> > Dear r-devel members,
> >
> > My Rcmdr package "depends" on several other packages (tcltk, grDevices,
> > utils, and car) and "suggests" a number of others (abind, aplpack,
> > colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
> > mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
> > distinction is that I don't want all of these packages to load when the
> > Rcmdr loads; rather, the "suggested" packages are loaded as they're
needed.
> > But all of the packages -- both those under "depends" and those under
> > "suggests" -- really are necessary for all of the features of the Rcmdr
to
> > work. For example, if the "leaps" package is absent, then the "Subset
model
> > selection" item in the "Models" menu is suppressed.
> >
> > This arrangement works reasonably well, but it makes it awkward to
install
> > the Rcmdr. If the user issues the command install.packages("Rcmdr"),
then
> > the "suggested" packages aren't installed. On the other hand, if the
user
> > issues the command install.packages("Rcmdr", dependencies=TRUE), which
is
> > what I currently recommend, then "suggested" packages are installed
> > recursively, causing dozens of packages, most of them actually
unnecessary,
> > to be installed. This issue has been growing more acute, and at this
point
> > even with a fast Internet connection it takes quite a while for all of
the
> > dependencies to download and install.
> >
> > I wonder whether I've missed something. Is there a way for me to arrange
> the
> > Rcmdr package dependencies so that only the necessary packages (those
> > currently listed under both "depends" and "suggests" and the packages on
> > which they "depend") are installed along with the Rcmdr, but the
currently
> > "suggested" packages aren't loaded when the Rcmdr loads?
>
>
>
> Dear John,
>
> no, this is not possible.
>
> Consider your package A (or Rcmdr) suggests B that suggests C.
> Then A::foo uses the function B::bar which only works if C::dep is
> present. B works essentially without C but it requires C just to make
> bar work. Then this means your A::foo won't work if C is not installed
> and you won't get it with the setup mentioned above.
>
> In summary, I fear what you want might work well *now* (by chance), but
> it does not work in general.
I agree that what I want to do isn't bullet-proof. I think, however, that in
most, if not all, cases, the Rcmdr dialogs will work even if packages
suggested by currently directly suggested packages were not installed. In
fact, this is what happens when a package is installed with the default
dependencies=FALSE. If it turns out that some such indirect dependency is
actually necessary, I could add that package to those directly suggested
(were such a mechanism possible). I'd save users a lot of downloads at the
price of occasionally having to specify a dependency explicitly.
Thanks,
John
>
> Best wishes,
> Uwe
>
>
>
>
>
>
> > Any help would be appreciated.
> >
> > John
> >
> > --
> > John Fox, Professor
> > Department of Sociology
> > McMaster University
> > Hamilton, Ontario, Canada
> > web: socserv.mcmaster.ca/jfox
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
Dear Gabor,
I thought of this solution but rejected it, perhaps too hastily, because it
seemed awkward. I suppose, however, that since the Rcmdr package would be
unchanged, a user could choose to install it as at present with
dependencies=TRUE, or alternatively install the RcmdrInstall package and
avoid the recursive installation of suggested packages. Maybe the idea is a
good one after all.
Thank you,
John
> -Original Message-
> From: Gabor Grothendieck [mailto:ggrothendi...@gmail.com]
> Sent: September-22-09 2:32 PM
> To: John Fox
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Rcmdr package dependencies
>
> Create a package called RcmdrInstall, say, with no content and have it
> depend on Rcmdr. RcmdrInstall would have all packages as dependencies
> while Rcmdr would only have the essential packages as dependencies.
>
> Install RcmdrInstall. That would also force Rcmdr to be installed.
>
> Now issue:
>
>library(Rcmdr)
>
> as before and the non-essentials won't be loaded.
>
> Thus the only difference between the current procedure and the new
> procedure as far as the user is concerned is that they install
> RcmdrInstall rather than Rcmdr. They load and run Rcmdr in the same
> way.
>
> On Tue, Sep 22, 2009 at 9:15 AM, John Fox wrote:
> > Dear r-devel members,
> >
> > My Rcmdr package "depends" on several other packages (tcltk, grDevices,
> > utils, and car) and "suggests" a number of others (abind, aplpack,
> > colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
> > mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
> > distinction is that I don't want all of these packages to load when the
> > Rcmdr loads; rather, the "suggested" packages are loaded as they're
needed.
> > But all of the packages -- both those under "depends" and those under
> > "suggests" -- really are necessary for all of the features of the Rcmdr
to
> > work. For example, if the "leaps" package is absent, then the "Subset
model
> > selection" item in the "Models" menu is suppressed.
> >
> > This arrangement works reasonably well, but it makes it awkward to
install
> > the Rcmdr. If the user issues the command install.packages("Rcmdr"),
then
> > the "suggested" packages aren't installed. On the other hand, if the
user
> > issues the command install.packages("Rcmdr", dependencies=TRUE), which
is
> > what I currently recommend, then "suggested" packages are installed
> > recursively, causing dozens of packages, most of them actually
unnecessary,
> > to be installed. This issue has been growing more acute, and at this
point
> > even with a fast Internet connection it takes quite a while for all of
the
> > dependencies to download and install.
> >
> > I wonder whether I've missed something. Is there a way for me to arrange
> the
> > Rcmdr package dependencies so that only the necessary packages (those
> > currently listed under both "depends" and "suggests" and the packages on
> > which they "depend") are installed along with the Rcmdr, but the
currently
> > "suggested" packages aren't loaded when the Rcmdr loads?
> >
> > Any help would be appreciated.
> >
> > John
> >
> > --
> > John Fox, Professor
> > Department of Sociology
> > McMaster University
> > Hamilton, Ontario, Canada
> > web: socserv.mcmaster.ca/jfox
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
To make it foolproof at Rcmdr's load time (i.e. in the .onLoad
function) you could check whether RcmdrInstall was available (not
necessarily loaded, just available). If not, then you could issue a
message asking the user to install it. This would help the user avoid
the situation where they install Rcmdr without RcmdrInstall and
thereby not have the other packages available.
On Tue, Sep 22, 2009 at 2:54 PM, John Fox wrote:
> Dear Gabor,
>
> I thought of this solution but rejected it, perhaps too hastily, because it
> seemed awkward. I suppose, however, that since the Rcmdr package would be
> unchanged, a user could choose to install it as at present with
> dependencies=TRUE, or alternatively install the RcmdrInstall package and
> avoid the recursive installation of suggested packages. Maybe the idea is a
> good one after all.
>
> Thank you,
> John
>
>
>> -Original Message-
>> From: Gabor Grothendieck [mailto:ggrothendi...@gmail.com]
>> Sent: September-22-09 2:32 PM
>> To: John Fox
>> Cc: r-devel@r-project.org
>> Subject: Re: [Rd] Rcmdr package dependencies
>>
>> Create a package called RcmdrInstall, say, with no content and have it
>> depend on Rcmdr. RcmdrInstall would have all packages as dependencies
>> while Rcmdr would only have the essential packages as dependencies.
>>
>> Install RcmdrInstall. That would also force Rcmdr to be installed.
>>
>> Now issue:
>>
>> library(Rcmdr)
>>
>> as before and the non-essentials won't be loaded.
>>
>> Thus the only difference between the current procedure and the new
>> procedure as far as the user is concerned is that they install
>> RcmdrInstall rather than Rcmdr. They load and run Rcmdr in the same
>> way.
>>
>> On Tue, Sep 22, 2009 at 9:15 AM, John Fox wrote:
>> > Dear r-devel members,
>> >
>> > My Rcmdr package "depends" on several other packages (tcltk, grDevices,
>> > utils, and car) and "suggests" a number of others (abind, aplpack,
>> > colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
>> > mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
>> > distinction is that I don't want all of these packages to load when the
>> > Rcmdr loads; rather, the "suggested" packages are loaded as they're
> needed.
>> > But all of the packages -- both those under "depends" and those under
>> > "suggests" -- really are necessary for all of the features of the Rcmdr
> to
>> > work. For example, if the "leaps" package is absent, then the "Subset
> model
>> > selection" item in the "Models" menu is suppressed.
>> >
>> > This arrangement works reasonably well, but it makes it awkward to
> install
>> > the Rcmdr. If the user issues the command install.packages("Rcmdr"),
> then
>> > the "suggested" packages aren't installed. On the other hand, if the
> user
>> > issues the command install.packages("Rcmdr", dependencies=TRUE), which
> is
>> > what I currently recommend, then "suggested" packages are installed
>> > recursively, causing dozens of packages, most of them actually
> unnecessary,
>> > to be installed. This issue has been growing more acute, and at this
> point
>> > even with a fast Internet connection it takes quite a while for all of
> the
>> > dependencies to download and install.
>> >
>> > I wonder whether I've missed something. Is there a way for me to arrange
>> the
>> > Rcmdr package dependencies so that only the necessary packages (those
>> > currently listed under both "depends" and "suggests" and the packages on
>> > which they "depend") are installed along with the Rcmdr, but the
> currently
>> > "suggested" packages aren't loaded when the Rcmdr loads?
>> >
>> > Any help would be appreciated.
>> >
>> > John
>> >
>> > --
>> > John Fox, Professor
>> > Department of Sociology
>> > McMaster University
>> > Hamilton, Ontario, Canada
>> > web: socserv.mcmaster.ca/jfox
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
Dear Gabor,
At present, the Rcmdr package checks whether its dependencies are present
and offers to install them if they are not. Also at present, it installs its
dependencies with dep=TRUE, but that could be changed. I suppose that I
could simply rely on this mechanism rather than have a separate RcmdrInstall
package or advise users to install the Rcmdr itself with dep=TRUE.
Best,
John
> -Original Message-
> From: Gabor Grothendieck [mailto:ggrothendi...@gmail.com]
> Sent: September-22-09 3:09 PM
> To: John Fox
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Rcmdr package dependencies
>
> To make it foolproof at Rcmdr's load time (i.e. in the .onLoad
> function) you could check whether RcmdrInstall was available (not
> necessarily loaded, just available). If not, then you could issue a
> message asking the user to install it. This would help the user avoid
> the situation where they install Rcmdr without RcmdrInstall and
> thereby not have the other packages available.
>
> On Tue, Sep 22, 2009 at 2:54 PM, John Fox wrote:
> > Dear Gabor,
> >
> > I thought of this solution but rejected it, perhaps too hastily, because
it
> > seemed awkward. I suppose, however, that since the Rcmdr package would
be
> > unchanged, a user could choose to install it as at present with
> > dependencies=TRUE, or alternatively install the RcmdrInstall package and
> > avoid the recursive installation of suggested packages. Maybe the idea
is a
> > good one after all.
> >
> > Thank you,
> > John
> >
> >
> >> -Original Message-
> >> From: Gabor Grothendieck [mailto:ggrothendi...@gmail.com]
> >> Sent: September-22-09 2:32 PM
> >> To: John Fox
> >> Cc: r-devel@r-project.org
> >> Subject: Re: [Rd] Rcmdr package dependencies
> >>
> >> Create a package called RcmdrInstall, say, with no content and have it
> >> depend on Rcmdr. RcmdrInstall would have all packages as dependencies
> >> while Rcmdr would only have the essential packages as dependencies.
> >>
> >> Install RcmdrInstall. That would also force Rcmdr to be installed.
> >>
> >> Now issue:
> >>
> >> library(Rcmdr)
> >>
> >> as before and the non-essentials won't be loaded.
> >>
> >> Thus the only difference between the current procedure and the new
> >> procedure as far as the user is concerned is that they install
> >> RcmdrInstall rather than Rcmdr. They load and run Rcmdr in the same
> >> way.
> >>
> >> On Tue, Sep 22, 2009 at 9:15 AM, John Fox wrote:
> >> > Dear r-devel members,
> >> >
> >> > My Rcmdr package "depends" on several other packages (tcltk,
grDevices,
> >> > utils, and car) and "suggests" a number of others (abind, aplpack,
> >> > colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest,
MASS,
> >> > mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for
the
> >> > distinction is that I don't want all of these packages to load when
the
> >> > Rcmdr loads; rather, the "suggested" packages are loaded as they're
> > needed.
> >> > But all of the packages -- both those under "depends" and those under
> >> > "suggests" -- really are necessary for all of the features of the
Rcmdr
> > to
> >> > work. For example, if the "leaps" package is absent, then the "Subset
> > model
> >> > selection" item in the "Models" menu is suppressed.
> >> >
> >> > This arrangement works reasonably well, but it makes it awkward to
> > install
> >> > the Rcmdr. If the user issues the command install.packages("Rcmdr"),
> > then
> >> > the "suggested" packages aren't installed. On the other hand, if the
> > user
> >> > issues the command install.packages("Rcmdr", dependencies=TRUE),
which
> > is
> >> > what I currently recommend, then "suggested" packages are installed
> >> > recursively, causing dozens of packages, most of them actually
> > unnecessary,
> >> > to be installed. This issue has been growing more acute, and at this
> > point
> >> > even with a fast Internet connection it takes quite a while for all
of
> > the
> >> > dependencies to download and install.
> >> >
> >> > I wonder whether I've missed something. Is there a way for me to
arrange
> >> the
> >> > Rcmdr package dependencies so that only the necessary packages (those
> >> > currently listed under both "depends" and "suggests" and the packages
on
> >> > which they "depend") are installed along with the Rcmdr, but the
> > currently
> >> > "suggested" packages aren't loaded when the Rcmdr loads?
> >> >
> >> > Any help would be appreciated.
> >> >
> >> > John
> >> >
> >> > --
> >> > John Fox, Professor
> >> > Department of Sociology
> >> > McMaster University
> >> > Hamilton, Ontario, Canada
> >> > web: socserv.mcmaster.ca/jfox
> >> >
> >> > __
> >> > R-devel@r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >> >
> >
> >
> >
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
John Fox wrote:
Dear Uwe,
-Original Message-
From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de]
Sent: September-22-09 2:17 PM
To: John Fox
Cc: r-devel@r-project.org
Subject: Re: [Rd] Rcmdr package dependencies
John Fox wrote:
Dear r-devel members,
My Rcmdr package "depends" on several other packages (tcltk, grDevices,
utils, and car) and "suggests" a number of others (abind, aplpack,
colorspace, effects, foreign, grid, Hmisc, lattice, leaps, lmtest, MASS,
mgcv, multcomp, nlme, nnet, relimp, rgl, and RODBC). The reason for the
distinction is that I don't want all of these packages to load when the
Rcmdr loads; rather, the "suggested" packages are loaded as they're
needed.
But all of the packages -- both those under "depends" and those under
"suggests" -- really are necessary for all of the features of the Rcmdr
to
work. For example, if the "leaps" package is absent, then the "Subset
model
selection" item in the "Models" menu is suppressed.
This arrangement works reasonably well, but it makes it awkward to
install
the Rcmdr. If the user issues the command install.packages("Rcmdr"),
then
the "suggested" packages aren't installed. On the other hand, if the
user
issues the command install.packages("Rcmdr", dependencies=TRUE), which
is
what I currently recommend, then "suggested" packages are installed
recursively, causing dozens of packages, most of them actually
unnecessary,
to be installed. This issue has been growing more acute, and at this
point
even with a fast Internet connection it takes quite a while for all of
the
dependencies to download and install.
I wonder whether I've missed something. Is there a way for me to arrange
the
Rcmdr package dependencies so that only the necessary packages (those
currently listed under both "depends" and "suggests" and the packages on
which they "depend") are installed along with the Rcmdr, but the
currently
"suggested" packages aren't loaded when the Rcmdr loads?
Dear John,
no, this is not possible.
Consider your package A (or Rcmdr) suggests B that suggests C.
Then A::foo uses the function B::bar which only works if C::dep is
present. B works essentially without C but it requires C just to make
bar work. Then this means your A::foo won't work if C is not installed
and you won't get it with the setup mentioned above.
In summary, I fear what you want might work well *now* (by chance), but
it does not work in general.
I agree that what I want to do isn't bullet-proof. I think, however, that in
most, if not all, cases, the Rcmdr dialogs will work even if packages
suggested by currently directly suggested packages were not installed. In
fact, this is what happens when a package is installed with the default
dependencies=FALSE. If it turns out that some such indirect dependency is
actually necessary, I could add that package to those directly suggested
(were such a mechanism possible). I'd save users a lot of downloads at the
price of occasionally having to specify a dependency explicitly.
Thanks for the explanation. Unfortunately the current infrastructure
works with recursive calling with the same arguments. In this case we'd
need some code that allows to have the first level different from the
rest of the recursion.
Perhaps one way to go would be to install Rcmdr including its
dependencies (only) and provide some simple function that installs its
suggests and their dependencies afterwards if not available. Hmmm, on he
other hand I do now want to suggest to have yet another mechanism such
as the biocLite function that I still dislike.
Just some thoughts, best wishes,
Uwe
Thanks,
John
Best wishes,
Uwe
Any help would be appreciated.
John
--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
* On 2009-09-22 at 20:16 +0200 Uwe Ligges wrote:
> no, this is not possible.
>
> Consider your package A (or Rcmdr) suggests B that suggests C.
> Then A::foo uses the function B::bar which only works if C::dep is
> present. B works essentially without C but it requires C just to
> make bar work. Then this means your A::foo won't work if C is not
> installed and you won't get it with the setup mentioned above.
>
> In summary, I fear what you want might work well *now* (by chance),
> but it does not work in general.
In general, one would expect a given package to function when its
suggested packages are not available. As such, it seems quite
reasonable to install a package, its Depends, Imports, and Suggests,
but not install Suggests recursively.
I think you could achieve such an installation using two calls to
install.packages:
install.packages("Rcmdr")
Rcmdr.Suggests <- strsplit(packageDescription("Rcmdr")$Suggests, ",\\s?")[[1]]
## need extra cleanup since packageDescription("blah")$Suggests
## Returns package names with versions as strings
wantPkgs <- sub("^([^ ]+).*", "\\1", Rcmdr.Suggests)
havePkgs <- installed.packages()[, "Package"]
wantPkgs <- wantPkgs[!(wantPkgs %in% havePkgs)]
install.packages(wantPkgs)
+ seth
--
Seth Falcon | @sfalcon | http://userprimary.net/user
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
Dear Seth,
> -Original Message-
> From: Seth Falcon [mailto:s...@userprimary.net]
> Sent: September-22-09 5:13 PM
> To: Uwe Ligges
> Cc: John Fox; r-devel@r-project.org
> Subject: Re: [Rd] Rcmdr package dependencies
>
> * On 2009-09-22 at 20:16 +0200 Uwe Ligges wrote:
> > no, this is not possible.
> >
> > Consider your package A (or Rcmdr) suggests B that suggests C.
> > Then A::foo uses the function B::bar which only works if C::dep is
> > present. B works essentially without C but it requires C just to
> > make bar work. Then this means your A::foo won't work if C is not
> > installed and you won't get it with the setup mentioned above.
> >
> > In summary, I fear what you want might work well *now* (by chance),
> > but it does not work in general.
>
> In general, one would expect a given package to function when its
> suggested packages are not available. As such, it seems quite
> reasonable to install a package, its Depends, Imports, and Suggests,
> but not install Suggests recursively.
>
> I think you could achieve such an installation using two calls to
> install.packages:
>
> install.packages("Rcmdr")
> Rcmdr.Suggests <- strsplit(packageDescription("Rcmdr")$Suggests,
> ",\\s?")[[1]]
> ## need extra cleanup since packageDescription("blah")$Suggests
> ## Returns package names with versions as strings
> wantPkgs <- sub("^([^ ]+).*", "\\1", Rcmdr.Suggests)
> havePkgs <- installed.packages()[, "Package"]
> wantPkgs <- wantPkgs[!(wantPkgs %in% havePkgs)]
> install.packages(wantPkgs)
The Rcmdr maintains a list of its dependencies, so it already does something
similar to this, but I like your version better because it queries the
Description file directly. I can't really expect a user to issue a command
like this, so I suppose that the best solution is, as at present, to have
the Rcmdr package do the checking and installation at start-up but to
install with dep=FALSE.
Thanks,
John
>
> + seth
>
> --
> Seth Falcon | @sfalcon | http://userprimary.net/user
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcmdr package dependencies
John Fox wrote:
Dear Seth,
-Original Message-
From: Seth Falcon [mailto:s...@userprimary.net]
Sent: September-22-09 5:13 PM
To: Uwe Ligges
Cc: John Fox; r-devel@r-project.org
Subject: Re: [Rd] Rcmdr package dependencies
* On 2009-09-22 at 20:16 +0200 Uwe Ligges wrote:
no, this is not possible.
Consider your package A (or Rcmdr) suggests B that suggests C.
Then A::foo uses the function B::bar which only works if C::dep is
present. B works essentially without C but it requires C just to
make bar work. Then this means your A::foo won't work if C is not
installed and you won't get it with the setup mentioned above.
In summary, I fear what you want might work well *now* (by chance),
but it does not work in general.
In general, one would expect a given package to function when its
suggested packages are not available. As such, it seems quite
reasonable to install a package, its Depends, Imports, and Suggests,
but not install Suggests recursively.
I think you could achieve such an installation using two calls to
install.packages:
install.packages("Rcmdr")
Rcmdr.Suggests <- strsplit(packageDescription("Rcmdr")$Suggests,
",\\s?")[[1]]
## need extra cleanup since packageDescription("blah")$Suggests
## Returns package names with versions as strings
wantPkgs <- sub("^([^ ]+).*", "\\1", Rcmdr.Suggests)
Nice suggestion, indeed! I think there is some code in package "tools"
that help to resolve these issues even more convenient:
wantPkgs <- package.dependencies(available.packages()["Rcmdr",],
depLevel = "Suggests")[["Rcmdr"]][,1]
so you do not need to have Rcmdr already installed and can rely on the R
internal code that can strip all that version information.
Best wishes,
Uwe
havePkgs <- installed.packages()[, "Package"]
wantPkgs <- wantPkgs[!(wantPkgs %in% havePkgs)]
install.packages(wantPkgs)
The Rcmdr maintains a list of its dependencies, so it already does something
similar to this, but I like your version better because it queries the
Description file directly. I can't really expect a user to issue a command
like this, so I suppose that the best solution is, as at present, to have
the Rcmdr package do the checking and installation at start-up but to
install with dep=FALSE.
Thanks,
John
+ seth
--
Seth Falcon | @sfalcon | http://userprimary.net/user
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Snow leopard ./configure "cannot compile a simple Fortran program"
I hope this is the place for this... I have to rebuild from scratch under Snow Leopard, and when I attempted to build R-2.9.1, I get the following results from ./ configure: checking how to get verbose linking output from fc... configure: WARNING: compilation failed checking for Fortran 77 libraries of fc... checking how to get verbose linking output from gcc -std=gnu99... -v checking for C libraries of gcc -std=gnu99... -lcrt1.10.6.o -L/usr/ local/lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/ i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/ usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple- darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. - lSystem checking for dummy main to link with Fortran 77 libraries... rm: conftest.dSYM: is a directory none checking for Fortran 77 name-mangling scheme... configure: error: cannot compile a simple Fortran program See `config.log' for more details. Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj Since this seems to be a 'fortran thing' methinks I should send this to Apple as well? Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj$ uname -a Darwin Jeff-Hamanns-MacBook-Pro.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/ RELEASE_I386 i386 Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj$ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snow leopard ./configure "cannot compile a simple Fortran program"
Jeff, On Sep 22, 2009, at 6:12 PM, Jeff Hamann wrote: I hope this is the place for this... Yes, indeed. I have to rebuild from scratch under Snow Leopard, and when I attempted to build R-2.9.1, I get the following results from ./ configure: checking how to get verbose linking output from fc... configure: WARNING: compilation failed checking for Fortran 77 libraries of fc... ^^--- I think you don't have a Fortran compiler. fc is a utility on SL that has nothing to do with Fortran and Xcode doesn't include Fortran, either. Please install GNU Fortran either from CRAN http://cran.r-project.org/bin/macosx/tools/ or if you feel brave take the Xcode 3.2 add on from http://r.research.att.com/gfortran-42-5646.pkg Also please don't forget to add -arch i386 or -arch x86_64 to the compilers when configuring R (see R for Mac FAQ) - the defaults are different between gcc (64-bit) and gfortran (32-bit)! Cheers, Simon PS: There is usually no need to compile R from sources on OS X - see http://r.research.att.com/ for the latest R release in both 32 and 64-bit for Leopard/Snow Leopard. checking how to get verbose linking output from gcc -std=gnu99... -v checking for C libraries of gcc -std=gnu99... -lcrt1.10.6.o -L/usr/ local/lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/ i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 - L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple- darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. - lSystem checking for dummy main to link with Fortran 77 libraries... rm: conftest.dSYM: is a directory none checking for Fortran 77 name-mangling scheme... configure: error: cannot compile a simple Fortran program See `config.log' for more details. Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj Since this seems to be a 'fortran thing' methinks I should send this to Apple as well? Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj$ uname -a Darwin Jeff-Hamanns-MacBook-Pro.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/ RELEASE_I386 i386 Jeff-Hamanns-MacBook-Pro:R-2.9.1 hamannj$ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
