[Rd] R CMD check fails in R-devel r63910
Hi,
The R CMD check is successful in R 3.0.1 but fails to install package
lmerTest under R-devel r63910,
Here is what I get:
** preparing package for lazy loading
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
no definition was found for superclass "merMod" in the specification of
class "merModLmerTest"
In DESCRIPTION file I have:
Depends: Matrix, stats, methods, lme4
Imports: numDeriv, MASS, Hmisc, gplots, pbkrtest
I have classes.R file where I specify that "merModLmerTest" class should
inherit "merMod":
merModLmerTest <- setClass("merModLmerTest", contains = "merMod")
But it seems like in R devel r63910 this line cannot be seen...
This error I have seen for a few days
Alexandra
--
View this message in context:
http://r.789695.n4.nabble.com/R-CMD-check-fails-in-R-devel-r63910-tp4676046.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check fails in R-devel r63910
On Sep 13, 2013, at 7:44, alku wrote:
> Hi,
>
> The R CMD check is successful in R 3.0.1 but fails to install package
> lmerTest under R-devel r63910,
> Here is what I get:
>
> ** preparing package for lazy loading
> Error in reconcilePropertiesAndPrototype(name, slots, prototype,
> superClasses, :
> no definition was found for superclass "merMod" in the specification of
> class "merModLmerTest"
The line you point out below isn't relevant to this error: it's saying it can't
find a definition of merMod and that it knows you meant to define one since
it's part of merModLmerTest.
>
> In DESCRIPTION file I have:
> Depends: Matrix, stats, methods, lme4
> Imports: numDeriv, MASS, Hmisc, gplots, pbkrtest
>
> I have classes.R file where I specify that "merModLmerTest" class should
> inherit "merMod":
>
> merModLmerTest <- setClass("merModLmerTest", contains = "merMod")
Which would be trouble if you don't define "merMod" elsewhere.
M
>
> But it seems like in R devel r63910 this line cannot be seen...
>
> This error I have seen for a few days
>
> Alexandra
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/R-CMD-check-fails-in-R-devel-r63910-tp4676046.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> 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] declaring package dependencies
On 9/12/2013 1:37 PM, Duncan Murdoch wrote: I think this one would be fine if you had library(MASS) or require(MASS) or (probably best) used MASS::loglm explicitly. It may be that in the past some other package put MASS on the search list, and that's why it worked before. The distinction is between "loading" and "attaching" a package. Loading it (which would be done if you had MASS::loglm, or imported it) guarantees that the package is initialized and in memory, but doesn't make it visible to the user without the explicit MASS:: prefix. Attaching it first loads it, then modifies the user's search list so the user can see it. Loading is less intrusive, so it's preferred over attaching. Both library() and require() would attach it. Thanks for this explanation, but I'm still confused about how to avoid the wrath of the CRAN-devel daemon, whose appetite for new morsels of developer flesh seems ever increasing and makes keeping even a stable package up-to-date a moving target. Perhaps such changes in R devel should be announced on this list for public comment before they are enforced in R CMD check. In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also provide R code that extends *.loglm methods. All of this previously worked by including Suggests: MASS, ... Changing this to Imports: MASS seems rather heavy-handed; I don't really want/need all of MASS in my namespace, and using MASS::loglm in examples seems ugly. For now, I'll use require(MASS) in each example. Attaching it first loads it, then modifies the user's search list so the user can see it. Which directive does this? -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. & Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check fails in R-devel r63910
This seems to be nothing to do with R-devel, which has none of those
classes.
Note that the versions of lme4 currently offered by CRAN for R 3.0.1 and
R-devel are different. I expect that is the root of the confusion,
although as far as I know the one with class "merMod" is the one for
R-devel.
But the posting guide applies: you have not supplied the 'at a minimum'
information asked for nor a reproducible example.
n 13/09/2013 12:44, alku wrote:
Hi,
The R CMD check is successful in R 3.0.1 but fails to install package
lmerTest under R-devel r63910,
Here is what I get:
** preparing package for lazy loading
Error in reconcilePropertiesAndPrototype(name, slots, prototype,
superClasses, :
no definition was found for superclass "merMod" in the specification of
class "merModLmerTest"
In DESCRIPTION file I have:
Depends: Matrix, stats, methods, lme4
Imports: numDeriv, MASS, Hmisc, gplots, pbkrtest
I have classes.R file where I specify that "merModLmerTest" class should
inherit "merMod":
merModLmerTest <- setClass("merModLmerTest", contains = "merMod")
But it seems like in R devel r63910 this line cannot be seen...
This error I have seen for a few days
Alexandra
--
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] declaring package dependencies
On 13/09/2013 8:31 AM, Michael Friendly wrote:
On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
>
> I think this one would be fine if you had library(MASS) or
> require(MASS) or (probably best) used MASS::loglm explicitly. It may
> be that in the past some other package put MASS on the search list,
> and that's why it worked before.
>
> The distinction is between "loading" and "attaching" a package.
> Loading it (which would be done if you had MASS::loglm, or imported
> it) guarantees that the package is initialized and in memory, but
> doesn't make it visible to the user without the explicit MASS::
> prefix. Attaching it first loads it, then modifies the user's search
> list so the user can see it.
>
> Loading is less intrusive, so it's preferred over attaching. Both
> library() and require() would attach it.
>
Thanks for this explanation, but I'm still confused about how to avoid
the wrath of the CRAN-devel
daemon, whose appetite for new morsels of developer flesh seems ever
increasing and makes
keeping even a stable package up-to-date a moving target. Perhaps such
changes in R devel
should be announced on this list for public comment before they are
enforced in R CMD check.
Changes are generally announced in the NEWS.Rd file long before release,
but R-devel is an unreleased version, so you won't see the news until it
is there. Announcing things that nobody can try leads to fewer useful
comments than putting them into R-devel where at least people can see
what is really happening.
In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
provide R code that
extends *.loglm methods. All of this previously worked by including
Suggests: MASS, ...
Changing this to Imports: MASS seems rather heavy-handed; I don't really
want/need all of MASS
in my namespace, and using MASS::loglm in examples seems ugly. For now,
I'll use
require(MASS) in each example.
If you need a small number of things from MASS in your package code,
then importing them explicitly is definitely the way to go, e.g.
importFrom(MASS, loglm). If you only use them in examples, I wouldn't
do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
is ugly is a matter of taste: it makes it clear to a user where that
function came from, and doesn't potentially hide objects from other
packages later in the search path.
On the other hand, require(pkg) is really simple; we have no equivalent
function that only does the loading, without attaching.
So it's hard to write
if (requireLoadable(MASS)) {
MASS::loglm( ... )
}
> Attaching it first loads it, then modifies the user's search list so
> the user can see it.
Which directive does this?
library() and require() both do it.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] numerical issue in contour.default?
Dear R developers, I found a small issue while plotting contours of data containing both "usual" and "very small" numbers. It appeared with both R 3.0.1 and R-Devel on Windows, and I could reproduce it on Linux. Would it be possible to solve this before the upcoming release? Thanks a lot for developing this great software! Thomas Example: set.seed(357) z1 <- matrix(runif(100, -1e-180, 1e-180), nrow = 10) contour(z1)# ok z2 <- matrix(c(runif(50, -1, 1), runif(50, -1e-180, 1e-180)), nrow = 10) contour(z2) # Error in contour.default(z) : k != 2 or 4 contour(z2 * 1e20)# 20 worked, 19 produced error contour(round(z2, 179)) # rounding to 179 digits works but not 180 sessionInfo() R Under development (unstable) (2013-09-11 r63910) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252 [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C [5] LC_TIME=German_Germany.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base -- Dr. Thomas Petzoldt Technische Universitaet Dresden Faculty of Environmental Sciences Institute of Hydrobiology 01062 Dresden, Germany E-Mail: thomas.petzo...@tu-dresden.de http://tu-dresden.de/Members/thomas.petzoldt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fortune! (Re: declaring package dependencies)
On 13 September 2013 at 08:31, Michael Friendly wrote: | Thanks for this explanation, but I'm still confused about how to avoid | the wrath of the CRAN-devel daemon, whose appetite for new morsels of | developer flesh seems ever increasing and makes keeping even a stable | package up-to-date a moving target. _Obviously_ a fortunes candidate. CCing Achim. [ And I informed my first-born that her time with us will surely be limited as I expect CRAN to demand every submitters first child any day now ... ] | Perhaps such changes in R devel should be announced on this list for public | comment before they are enforced in R CMD check. Many of us have suggested that many times before, but CRAN has the longer stick and simply refuses to play along. "Eventually" the tides will turn and some of us will be fed up enough and stop uploading. But so far we still have an (uneasy?) truce, and everybody is playing (fighting?) along. And don't even get me started on the state of r-forge build services... 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] numerical issue in contour.default?
On 13/09/2013 10:01 AM, Thomas Petzoldt wrote: Dear R developers, I found a small issue while plotting contours of data containing both "usual" and "very small" numbers. It appeared with both R 3.0.1 and R-Devel on Windows, and I could reproduce it on Linux. Would it be possible to solve this before the upcoming release? I don't see the error in 32 bits, but I do see it in 64 bits. I think it's really unlikely this will be fixed before 3.0.2, unless you send a well tested patch in the next few days. Code freeze is on Wednesday. Duncan Murdoch Thanks a lot for developing this great software! Thomas Example: set.seed(357) z1 <- matrix(runif(100, -1e-180, 1e-180), nrow = 10) contour(z1)# ok z2 <- matrix(c(runif(50, -1, 1), runif(50, -1e-180, 1e-180)), nrow = 10) contour(z2) # Error in contour.default(z) : k != 2 or 4 contour(z2 * 1e20)# 20 worked, 19 produced error contour(round(z2, 179)) # rounding to 179 digits works but not 180 > sessionInfo() R Under development (unstable) (2013-09-11 r63910) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252 [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C [5] LC_TIME=German_Germany.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13 September 2013 at 09:51, Duncan Murdoch wrote: | Changes are generally announced in the NEWS.Rd file long before release, | but R-devel is an unreleased version, so you won't see the news until it | is there. Announcing things that nobody can try leads to fewer useful | comments than putting them into R-devel where at least people can see | what is really happening. That comment makes sense _in theory_. Yet _in practice_ it does not as many of us have been shot down by tests in R-devel which had been implemented within a 48 hour window of the package submission. Absent a time machine or psychic powers, I do not see how package developers can reasonably be expected to cope with this. I am not close to Python, but the little I know about their PEP system makes me think that a process in which changes are first announced as concepts, then discussed and refined and only thereafter implemented seems somewhat appealing. 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] declaring package dependencies
On 13/09/2013 14:51, Duncan Murdoch wrote:
On 13/09/2013 8:31 AM, Michael Friendly wrote:
On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
>
> I think this one would be fine if you had library(MASS) or
> require(MASS) or (probably best) used MASS::loglm explicitly. It may
> be that in the past some other package put MASS on the search list,
> and that's why it worked before.
>
> The distinction is between "loading" and "attaching" a package.
> Loading it (which would be done if you had MASS::loglm, or imported
> it) guarantees that the package is initialized and in memory, but
> doesn't make it visible to the user without the explicit MASS::
> prefix. Attaching it first loads it, then modifies the user's search
> list so the user can see it.
>
> Loading is less intrusive, so it's preferred over attaching. Both
> library() and require() would attach it.
>
Thanks for this explanation, but I'm still confused about how to avoid
the wrath of the CRAN-devel
daemon, whose appetite for new morsels of developer flesh seems ever
increasing and makes
keeping even a stable package up-to-date a moving target. Perhaps such
changes in R devel
should be announced on this list for public comment before they are
enforced in R CMD check.
Changes are generally announced in the NEWS.Rd file long before release,
but R-devel is an unreleased version, so you won't see the news until it
is there. Announcing things that nobody can try leads to fewer useful
comments than putting them into R-devel where at least people can see
what is really happening.
In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
provide R code that
extends *.loglm methods. All of this previously worked by including
Suggests: MASS, ...
Changing this to Imports: MASS seems rather heavy-handed; I don't really
want/need all of MASS
in my namespace, and using MASS::loglm in examples seems ugly. For now,
I'll use
require(MASS) in each example.
If you need a small number of things from MASS in your package code,
then importing them explicitly is definitely the way to go, e.g.
importFrom(MASS, loglm). If you only use them in examples, I wouldn't
do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
is ugly is a matter of taste: it makes it clear to a user where that
function came from, and doesn't potentially hide objects from other
packages later in the search path.
On the other hand, require(pkg) is really simple; we have no equivalent
function that only does the loading, without attaching.
So it's hard to write
if (requireLoadable(MASS)) {
MASS::loglm( ... )
}
?requireNamespace.
> Attaching it first loads it, then modifies the user's search list so
> the user can see it.
Which directive does this?
library() and require() both do it.
Duncan Murdoch
__
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] declaring package dependencies
On 13/09/2013 10:18 AM, Dirk Eddelbuettel wrote: On 13 September 2013 at 09:51, Duncan Murdoch wrote: | Changes are generally announced in the NEWS.Rd file long before release, | but R-devel is an unreleased version, so you won't see the news until it | is there. Announcing things that nobody can try leads to fewer useful | comments than putting them into R-devel where at least people can see | what is really happening. That comment makes sense _in theory_. Yet _in practice_ it does not as many of us have been shot down by tests in R-devel which had been implemented within a 48 hour window of the package submission. It sounds as though you are talking about CRAN here, not R. I can't speak for CRAN. Absent a time machine or psychic powers, I do not see how package developers can reasonably be expected to cope with this. I'm a CRAN user as a package developer, and I do get emails about changes, but I don't find them overwhelming, and I don't recall receiving any that were irrational. Generally the package is improved when I follow their advice. It has happened that I have been slower than they liked in responding, but the world didn't end. I imagine Rcpp pushes the limits more than my packages do, but I think most developers can cope. After all, the number of packages on CRAN is increasing, not decreasing. Duncan Murdoch I am not close to Python, but the little I know about their PEP system makes me think that a process in which changes are first announced as concepts, then discussed and refined and only thereafter implemented seems somewhat appealing. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] numerical issue in contour.default?
On 13/09/2013 15:14, Duncan Murdoch wrote: On 13/09/2013 10:01 AM, Thomas Petzoldt wrote: Dear R developers, I found a small issue while plotting contours of data containing both "usual" and "very small" numbers. It appeared with both R 3.0.1 and R-Devel on Windows, and I could reproduce it on Linux. Would it be possible to solve this before the upcoming release? I don't see the error in 32 bits, but I do see it in 64 bits. I think it's really unlikely this will be fixed before 3.0.2, unless you send a well tested patch in the next few days. Code freeze is on Wednesday. And not even then: we would not have time to do sufficiently extensive checking. Reporting to bugs.r-project.org with a patch would get the process rolling. Duncan Murdoch Thanks a lot for developing this great software! Thomas Example: set.seed(357) z1 <- matrix(runif(100, -1e-180, 1e-180), nrow = 10) contour(z1)# ok z2 <- matrix(c(runif(50, -1, 1), runif(50, -1e-180, 1e-180)), nrow = 10) contour(z2) # Error in contour.default(z) : k != 2 or 4 contour(z2 * 1e20)# 20 worked, 19 produced error contour(round(z2, 179)) # rounding to 179 digits works but not 180 > sessionInfo() R Under development (unstable) (2013-09-11 r63910) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252 [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C [5] LC_TIME=German_Germany.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ 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] declaring package dependencies
On 13/09/2013 10:37 AM, Prof Brian Ripley wrote:
On 13/09/2013 14:51, Duncan Murdoch wrote:
> On 13/09/2013 8:31 AM, Michael Friendly wrote:
>> On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
>> >
>> > I think this one would be fine if you had library(MASS) or
>> > require(MASS) or (probably best) used MASS::loglm explicitly. It may
>> > be that in the past some other package put MASS on the search list,
>> > and that's why it worked before.
>> >
>> > The distinction is between "loading" and "attaching" a package.
>> > Loading it (which would be done if you had MASS::loglm, or imported
>> > it) guarantees that the package is initialized and in memory, but
>> > doesn't make it visible to the user without the explicit MASS::
>> > prefix. Attaching it first loads it, then modifies the user's search
>> > list so the user can see it.
>> >
>> > Loading is less intrusive, so it's preferred over attaching. Both
>> > library() and require() would attach it.
>> >
>> Thanks for this explanation, but I'm still confused about how to avoid
>> the wrath of the CRAN-devel
>> daemon, whose appetite for new morsels of developer flesh seems ever
>> increasing and makes
>> keeping even a stable package up-to-date a moving target. Perhaps such
>> changes in R devel
>> should be announced on this list for public comment before they are
>> enforced in R CMD check.
> Changes are generally announced in the NEWS.Rd file long before release,
> but R-devel is an unreleased version, so you won't see the news until it
> is there. Announcing things that nobody can try leads to fewer useful
> comments than putting them into R-devel where at least people can see
> what is really happening.
>>
>> In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and also
>> provide R code that
>> extends *.loglm methods. All of this previously worked by including
>> Suggests: MASS, ...
>> Changing this to Imports: MASS seems rather heavy-handed; I don't really
>> want/need all of MASS
>> in my namespace, and using MASS::loglm in examples seems ugly. For now,
>> I'll use
>> require(MASS) in each example.
>
> If you need a small number of things from MASS in your package code,
> then importing them explicitly is definitely the way to go, e.g.
> importFrom(MASS, loglm). If you only use them in examples, I wouldn't
> do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
> is ugly is a matter of taste: it makes it clear to a user where that
> function came from, and doesn't potentially hide objects from other
> packages later in the search path.
>
> On the other hand, require(pkg) is really simple; we have no equivalent
> function that only does the loading, without attaching.
> So it's hard to write
>
> if (requireLoadable(MASS)) {
>MASS::loglm( ... )
> }
?requireNamespace.
Thanks. I'll switch my packages to use that.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] numerical issue in contour.default?
On 13.09.2013 16:44, Prof Brian Ripley wrote:
On 13/09/2013 15:14, Duncan Murdoch wrote:
On 13/09/2013 10:01 AM, Thomas Petzoldt wrote:
Dear R developers,
I found a small issue while plotting contours of data containing both
"usual" and "very small" numbers. It appeared with both R 3.0.1 and
R-Devel on Windows, and I could reproduce it on Linux. Would it be
possible to solve this before the upcoming release?
I don't see the error in 32 bits, but I do see it in 64 bits. I think
it's really unlikely this will be fixed before 3.0.2, unless you send a
well tested patch in the next few days. Code freeze is on Wednesday.
You are right, I can reproduce it only on 64 bit.
And not even then: we would not have time to do sufficiently extensive
checking.
Agreed, so I'll put a workaround in my package for now.
Reporting to bugs.r-project.org with a patch would get the process rolling.
O.K., I will report it. After a look in the sources I would guess that
it may be in:
src/main/contour-common.h
static int ctr_intersect(double z0, double z1, double zc, double *f)
{
if ((z0 - zc) * (z1 - zc) < 0.0) {
*f = (zc - z0) / (z1 - z0);
return 1;
}
return 0;
}
... but you are right, too many things depend on it.
Many thanks for the immediate feedback!
Thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13 September 2013 at 10:38, Duncan Murdoch wrote: | On 13/09/2013 10:18 AM, Dirk Eddelbuettel wrote: | > On 13 September 2013 at 09:51, Duncan Murdoch wrote: | > | Changes are generally announced in the NEWS.Rd file long before release, | > | but R-devel is an unreleased version, so you won't see the news until it | > | is there. Announcing things that nobody can try leads to fewer useful | > | comments than putting them into R-devel where at least people can see | > | what is really happening. | > | > That comment makes sense _in theory_. | > | > Yet _in practice_ it does not as many of us have been shot down by tests in | > R-devel which had been implemented within a 48 hour window of the package | > submission. | | It sounds as though you are talking about CRAN here, not R. I can't | speak for CRAN. Hah :) -- in practive you actually do as the service you built to create RSS summaries of R NEWS changes (ie R Core) is one good way to learn about CRAN changes as the CRAN folks use the R Core access to R itself (via R CMD check) to effect change. And yes: we all want change for the better. But we also want a more grown-up process. | > Absent a time machine or psychic powers, I do not see how package developers | > can reasonably be expected to cope with this. | | I'm a CRAN user as a package developer, and I do get emails about | changes, but I don't find them overwhelming, and I don't recall | receiving any that were irrational. Generally the package is improved | when I follow their advice. It has happened that I have been slower | than they liked in responding, but the world didn't end. Of course they improve. The long arc of history points to progress. Packages are better than they used to be (cf NAMESPACE discussion). Nobody disputes that. But what we take excpetion with is the _process_ and the matter in which changes are (NOT REALLY) communicated, or even announced with a windows. | I imagine Rcpp pushes the limits more than my packages do, but I think | most developers can cope. After all, the number of packages on CRAN is | increasing, not decreasing. It's not so much Rcpp itself or my 20-ish packages but the fact that we (as in the Rcpp authors) now stand behind an API that also has to accomodate changes in R CMD check. Case in point is current (unannounced) change that makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks. Yet I cannot really talk to 135 packages using Rcpp as I have CRAN Policy document to point to. 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] declaring package dependencies
On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote: On 13 September 2013 at 10:38, Duncan Murdoch wrote: | On 13/09/2013 10:18 AM, Dirk Eddelbuettel wrote: | > On 13 September 2013 at 09:51, Duncan Murdoch wrote: | > | Changes are generally announced in the NEWS.Rd file long before release, | > | but R-devel is an unreleased version, so you won't see the news until it | > | is there. Announcing things that nobody can try leads to fewer useful | > | comments than putting them into R-devel where at least people can see | > | what is really happening. | > | > That comment makes sense _in theory_. | > | > Yet _in practice_ it does not as many of us have been shot down by tests in | > R-devel which had been implemented within a 48 hour window of the package | > submission. | | It sounds as though you are talking about CRAN here, not R. I can't | speak for CRAN. Hah :) -- in practive you actually do as the service you built to create RSS summaries of R NEWS changes (ie R Core) is one good way to learn about CRAN changes as the CRAN folks use the R Core access to R itself (via R CMD check) to effect change. And yes: we all want change for the better. But we also want a more grown-up process. | > Absent a time machine or psychic powers, I do not see how package developers | > can reasonably be expected to cope with this. | | I'm a CRAN user as a package developer, and I do get emails about | changes, but I don't find them overwhelming, and I don't recall | receiving any that were irrational. Generally the package is improved | when I follow their advice. It has happened that I have been slower | than they liked in responding, but the world didn't end. Of course they improve. The long arc of history points to progress. Packages are better than they used to be (cf NAMESPACE discussion). Nobody disputes that. But what we take excpetion with is the _process_ and the matter in which changes are (NOT REALLY) communicated, or even announced with a windows. | I imagine Rcpp pushes the limits more than my packages do, but I think | most developers can cope. After all, the number of packages on CRAN is | increasing, not decreasing. It's not so much Rcpp itself or my 20-ish packages but the fact that we (as in the Rcpp authors) now stand behind an API that also has to accomodate changes in R CMD check. Case in point is current (unannounced) change that makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks. I am a bit confused by this Dirk, so maybe I am missing something. I think this is still a "Note" in R-devel so you do have some time to make the change, at least several months, maybe more. It is not quite what I think of as an "announcement", more like a shot across the bow, but it is also not "unannounced". More importantly, I don't think that the requirement is necessarily to change Depends: Rcpp to Imports: Rcpp, the requirement is to put imports(Rcpp) in the NAMESPACE file. I think this is so that the package continues to work even if the user does something with the search path. The decision to change Depends: Rcpp to Imports: Rcpp really depends on whether the package author wants Rcpp functions to be available directly by users without them needing to specifically attach Rcpp. They are available with Depends but with Imports they are just used internally in the package. So, one of us is confused. Usually it is me. Paul Yet I cannot really talk to 135 packages using Rcpp as I have CRAN Policy document to point to. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
On 13 September 2013 at 11:42, Paul Gilbert wrote: | On 13-09-13 11:02 AM, Dirk Eddelbuettel wrote: | > It's not so much Rcpp itself or my 20-ish packages but the fact that we (as | > in the Rcpp authors) now stand behind an API that also has to accomodate | > changes in R CMD check. Case in point is current (unannounced) change that | > makes all Depends: Rcpp become Imports: Rcpp because of the NAMESPACE checks. | | I am a bit confused by this Dirk, so maybe I am missing something. I | think this is still a "Note" in R-devel so you do have some time to make | the change, at least several months, maybe more. It is not quite what I | think of as an "announcement", more like a shot across the bow, but it | is also not "unannounced". One package author [as in user of Rcpp and not an author of it] was told by CRAN this week to change his package and came to me for help -- so in that small way the CRAN "non-communication policy" is already creating more work for me, and makes me look silly as "I don't document what Rcpp-using packages need" as I sadly still lack the time machine or psychic powers to infer what may get changed this weekend. | More importantly, I don't think that the requirement is necessarily to | change Depends: Rcpp to Imports: Rcpp, the requirement is to put | imports(Rcpp) in the NAMESPACE file. I think this is so that the package | continues to work even if the user does something with the search path. | The decision to change Depends: Rcpp to Imports: Rcpp really depends on | whether the package author wants Rcpp functions to be available directly Rcpp is a bit of an odd-ball as you mostly need it at compile-time, and you require very few R-level functions (but there is package initialization etc pp). We also only about two handful of functions, and those are for functionality not all 135 packages use (eg Modules etc). But the focus here should not be on my hobby package. The focus needs to be on how four CRAN maintainers (who do a boatload of amazing work which is _truly_ appreciated in its thoroughness and reach) could make the life of authors of 4800+ packages easier by communicating and planning a tad more. | by users without them needing to specifically attach Rcpp. They are | available with Depends but with Imports they are just used internally in | the package. | | So, one of us is confused. Usually it is me. No, no, I usually keep you company. 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] declaring package dependencies
John Fox: (12:15PM on Fri, Sep 13)
[...cut...]
I think that most users --
as opposed to R developers -- will find the package::function( ... ) syntax
in examples not so much ugly as cryptic. I think that we have ample recent
evidence on this list that even developers (I don't exempt myself) are
confused by namespace issues. On balance, I prefer
if (require(MASS)) {
loglm( ...)
}
which tells the user that it's necessary to load MASS before using loglm().
It would be nice if examples ran in a "sandbox," so that an example could
read something like
library(MASS)
loglm( ... )
. . .
without affecting the path in the current session, and fail gracefully if
the MASS package weren't available (unlikely, of course, in the case of
MASS, but not more generally).
Does assigning
loglm <- MASS::loglm
loglm( ... )
not work in examples anymore? (with MASS listed under 'Suggests'.)
That seems like it could address both concerns, but it would mask
loglm if it were already defined.
--
Gray Calhoun, Assistant Professor of Economics at Iowa State
http://gray.clhn.co // (515) 294-6271 // 467 Heady Hall
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] declaring package dependencies
Dear Duncan and Michael,
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
> project.org] On Behalf Of Duncan Murdoch
> Sent: Friday, September 13, 2013 9:51 AM
> To: Michael Friendly
> Cc: r-devel
> Subject: Re: [Rd] declaring package dependencies
>
> On 13/09/2013 8:31 AM, Michael Friendly wrote:
> > On 9/12/2013 1:37 PM, Duncan Murdoch wrote:
> > >
> > > I think this one would be fine if you had library(MASS) or
> > > require(MASS) or (probably best) used MASS::loglm explicitly. It
> may
> > > be that in the past some other package put MASS on the search list,
> > > and that's why it worked before.
> > >
> > > The distinction is between "loading" and "attaching" a package.
> > > Loading it (which would be done if you had MASS::loglm, or imported
> > > it) guarantees that the package is initialized and in memory, but
> > > doesn't make it visible to the user without the explicit MASS::
> > > prefix. Attaching it first loads it, then modifies the user's
> search
> > > list so the user can see it.
> > >
> > > Loading is less intrusive, so it's preferred over attaching. Both
> > > library() and require() would attach it.
> > >
> > Thanks for this explanation, but I'm still confused about how to
> avoid
> > the wrath of the CRAN-devel
> > daemon, whose appetite for new morsels of developer flesh seems ever
> > increasing and makes
> > keeping even a stable package up-to-date a moving target. Perhaps
> such
> > changes in R devel
> > should be announced on this list for public comment before they are
> > enforced in R CMD check.
> Changes are generally announced in the NEWS.Rd file long before
> release,
> but R-devel is an unreleased version, so you won't see the news until
> it
> is there. Announcing things that nobody can try leads to fewer useful
> comments than putting them into R-devel where at least people can see
> what is really happening.
> >
> > In vcdExtra, I use MASS::loglm in ~ 6 .Rd examples, a vignette, and
> also
> > provide R code that
> > extends *.loglm methods. All of this previously worked by including
> > Suggests: MASS, ...
> > Changing this to Imports: MASS seems rather heavy-handed; I don't
> really
> > want/need all of MASS
> > in my namespace, and using MASS::loglm in examples seems ugly. For
> now,
> > I'll use
> > require(MASS) in each example.
>
> If you need a small number of things from MASS in your package code,
> then importing them explicitly is definitely the way to go, e.g.
> importFrom(MASS, loglm). If you only use them in examples, I wouldn't
> do that, I'd recommend Suggests and use the MASS:: prefix. Whether that
> is ugly is a matter of taste: it makes it clear to a user where that
> function came from, and doesn't potentially hide objects from other
> packages later in the search path.
>
If I understand this thread, Michael's package doesn't use loglm() -- it
provides methods for objects produced by loglm() and hence "Enhances" the
package.
> On the other hand, require(pkg) is really simple; we have no equivalent
> function that only does the loading, without attaching.
> So it's hard to write
>
> if (requireLoadable(MASS)) {
>MASS::loglm( ... )
> }
>
I understand why one would want to do this sort of thing (say, using
requireNamespace), to avoid attaching the MASS package to the search path
and possibly shadowing objects on the path, but I think that most users --
as opposed to R developers -- will find the package::function( ... ) syntax
in examples not so much ugly as cryptic. I think that we have ample recent
evidence on this list that even developers (I don't exempt myself) are
confused by namespace issues. On balance, I prefer
if (require(MASS)) {
loglm( ...)
}
which tells the user that it's necessary to load MASS before using loglm().
It would be nice if examples ran in a "sandbox," so that an example could
read something like
library(MASS)
loglm( ... )
. . .
without affecting the path in the current session, and fail gracefully if
the MASS package weren't available (unlikely, of course, in the case of
MASS, but not more generally).
Best,
John
> >
> > > Attaching it first loads it, then modifies the user's search list
> so
> > > the user can see it.
> > Which directive does this?
>
> library() and require() both do it.
>
> Duncan Murdoch
> >
>
> __
> 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] inconsistency/bug in recordPlot/replayPlot
Hey all,
I've run accross what seems to be a bug in the recordPlot/replayPlot
functionality (or at least the lack of a feature which seems pretty
reasonable to expect to be there)
When drawing to a file-based graphics device (I tested with png()), the
file resulting from calling replayPlot on a recordedplot object does not
contain an identical image to that captured by the same graphics device
when used on the plot that was recorded.
Reproducible (at least for me on linux) example:
png("noreplay.png")
plot(1:10)
dev.off()
plot(1:10)
recplot = recordPlot()
png("withreplay.png")
replayPlot(recplot)
dev.off()
The resulting png files are attached. You'll notice that the noreplay.png
has the expected white background, while withoutreplay.png has no/a
transparent background.
This seems likely to be related to the note in ?dev.print :
"
Note that these functions copy the _device region_ and not a plot:
the background colour of the device surface is part of what is
copied. Most screen devices default to a transparent background,
which is probably not what is needed when copying to a device such
as ‘png’.
"
Now this may be as intended because it is "not allowed" to draw
recordedplot objects to devices other than the one they were recorded on
(AFAIK the primary purpose of recordedplot objects is fast redraws
internally), but alas that is what my use-case calls for. Furthermore, I
don't think I'm alone in thinking wistfully about how useful it would be to
have an actual, transportable object class which can fully represent an R
plot in any R-based context.
I'm pretty sure I can compile a patch which does this if it would be
considered, though there would be a delay of a week or two before I could
burrow out from under the mound of other stuff I currently need to be doing
sessionInfo below, and I have also confirmed that the behavior remains
unchanged in the current trunk.
Thanks,
~G
> sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.0.1 tools_3.0.1
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
<><>__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
