Re: [R-pkg-devel] inappropriate maintainer moniker
Once all the other issues are resolved, I'd suggest e-mailing r-cran-submissions with this explanation and asking for clarification. My interpretation would have been the same as yours (i.e., that this is an appropriate e-mail address, and that CRAN maintainers may have misinterpreted it a mailing list address). On 7/22/20 7:05 PM, brian knaus wrote: Hello R-pkg-devel, Our package vcfR, https://github.com/knausb/vcfR has been removed from CRAN because they asked me to make changes that I have not been able to make before their deadline. One of the issues was that the moniker "briank.lists" is not appropriate and that we should see CRAN policy. I interpret "CRAN policy" here to be the following link. https://cran.r-project.org/web/packages/policies.html I'm struggling with *why* is this inappropriate, so I do not understand how to fix it. My attempt to interpret this issue is that this "moniker" has been interpreted as a "mailing list" by a CRAN member. The policy states that a "single designated maintainer (a person, not a mailing list)" should be included in the DESCRIPTION. However, in vcfR this address is a "single designated maintainer" (me). It's where I receive mail from various mailing lists I've signed up for. For example, mail I receive from "R-pkg-devel" comes to this address. So I feel that this is confusion on the side of CRAN. Does anyone see a reason for *why* this may be considered inappropriate? Thank you! Brian Knaus [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] CAR0 vs. EXTPTR_PTR
On 22 July 2020 at 16:29, William Dunlap via R-devel wrote: | I know that binary packages are R-version specific, but it was a bit | surprising that Rcpp 1.0.5 built with R-4.0.2 cannot be loaded into | R-4.0.0. | | % R-4.0.0 --quiet | > library(Rcpp, lib="lib-4.0.2") | Error: package or namespace load failed for ‘Rcpp’ in dyn.load(file, | DLLpath = DLLpath, ...): | unable to load shared object '/tmp/bill/lib-4.0.2/Rcpp/libs/Rcpp.so': | /tmp/bill/lib-4.0.2/Rcpp/libs/Rcpp.so: undefined symbol: EXTPTR_PTR | In addition: Warning message: | package ‘Rcpp’ was built under R version 4.0.2 | | It looks like R's include/Rinternals.h was rejiggered so the function | EXTPTR_PTR is called when CAR0 used to be. (I think they do the same | thing.) AFAIK it is not so much that you cannot take a 4.0.2 binary "back" to an older R version, it is more that 4.0.0/4.0.1 had an inadvertent change that broke things. This came up a few times already on a few of the lists and on stackoverflow. And simply running R 4.0.2 and building on R 4.0.2 is the safest bet. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CAR0 vs. EXTPTR_PTR
I know that binary packages are R-version specific, but it was a bit surprising that Rcpp 1.0.5 built with R-4.0.2 cannot be loaded into R-4.0.0. % R-4.0.0 --quiet > library(Rcpp, lib="lib-4.0.2") Error: package or namespace load failed for ‘Rcpp’ in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '/tmp/bill/lib-4.0.2/Rcpp/libs/Rcpp.so': /tmp/bill/lib-4.0.2/Rcpp/libs/Rcpp.so: undefined symbol: EXTPTR_PTR In addition: Warning message: package ‘Rcpp’ was built under R version 4.0.2 It looks like R's include/Rinternals.h was rejiggered so the function EXTPTR_PTR is called when CAR0 used to be. (I think they do the same thing.) Bill Dunlap TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[R-pkg-devel] inappropriate maintainer moniker
Hello R-pkg-devel, Our package vcfR, https://github.com/knausb/vcfR has been removed from CRAN because they asked me to make changes that I have not been able to make before their deadline. One of the issues was that the moniker "briank.lists" is not appropriate and that we should see CRAN policy. I interpret "CRAN policy" here to be the following link. https://cran.r-project.org/web/packages/policies.html I'm struggling with *why* is this inappropriate, so I do not understand how to fix it. My attempt to interpret this issue is that this "moniker" has been interpreted as a "mailing list" by a CRAN member. The policy states that a "single designated maintainer (a person, not a mailing list)" should be included in the DESCRIPTION. However, in vcfR this address is a "single designated maintainer" (me). It's where I receive mail from various mailing lists I've signed up for. For example, mail I receive from "R-pkg-devel" comes to this address. So I feel that this is confusion on the side of CRAN. Does anyone see a reason for *why* this may be considered inappropriate? Thank you! Brian Knaus [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] [External] Re: Invisible names problem
On Wed, 22 Jul 2020, Simon Urbanek wrote: Very interesting: .Internal(inspect(k[i])) @10a4bc000 14 REALSXP g0c7 [ATT] (len=2, tl=0) 1,2,3,4,1,... ATTRIB: @7fa24f07fa58 02 LISTSXP g0c0 [REF(1)] TAG: @7fa24b803e90 01 SYMSXP g0c0 [MARK,REF(5814),LCK,gp=0x6000] "names" (has value) @10a4e4000 16 STRSXP g0c7 [REF(1)] (len=2, tl=0) @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(35005),gp=0x61] [ASCII] [cached] "a" @7fa24be24428 09 CHARSXP g0c1 [MARK,REF(35010),gp=0x61] [ASCII] [cached] "b" @7fa24b806ec0 09 CHARSXP g0c1 [MARK,REF(35082),gp=0x61] [ASCII] [cached] "c" @7fa24bcc6af0 09 CHARSXP g0c1 [MARK,REF(35003),gp=0x61] [ASCII] [cached] "d" @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(35005),gp=0x61] [ASCII] [cached] "a" ... .Internal(inspect(unname(k[i]))) @10a50c000 14 REALSXP g0c7 [] (len=2, tl=0) 1,2,3,4,1,... .Internal(inspect(x2)) @7fa24fc692d8 14 REALSXP g0c0 [REF(1)] wrapper [srt=-2147483648,no_na=0] @10a228000 14 REALSXP g0c7 [REF(1),ATT] (len=2, tl=0) 1,2,3,4,1,... ATTRIB: @7fa24fc69850 02 LISTSXP g0c0 [REF(1)] TAG: @7fa24b803e90 01 SYMSXP g0c0 [MARK,REF(5797),LCK,gp=0x4000] "names" (has value) @10a25 16 STRSXP g0c7 [REF(65535)] (len=2, tl=0) @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(10005),gp=0x61] [ASCII] [cached] "a" @7fa24be24428 09 CHARSXP g0c1 [MARK,REF(10010),gp=0x61] [ASCII] [cached] "b" @7fa24b806ec0 09 CHARSXP g0c1 [MARK,REF(10077),gp=0x61] [ASCII] [cached] "c" @7fa24bcc6af0 09 CHARSXP g0c1 [MARK,REF(10003),gp=0x61] [ASCII] [cached] "d" @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(10005),gp=0x61] [ASCII] [cached] "a" ... If you don't assign the intermediate result things are simple as R knows there are no references so the names can be simply removed. However, if you assign the result that is not possible as there is still the reference in x2 at the time when unname() creates its own local temporary variable obj to do what probably most of us would use which is names(obj) <- NULL (i.e. names(x2) <- NULL avoids that problem.since you don't need both x2 and obj). To be precise, when you use unname() on an assigned object, R has to technically keep two copies - one for the existing x2 and a second in unname() for obj so it can call names(obj)<-NULL for the modification. To avoid that R instead creates a wrapper for the original x2 which says "like x2 but names are NULL". The rationale is that for large vector it is better to keep records of metadata changes rather than duplicating the object. This way the vector is stored only once. However, as you blow way the original x2, all that is left is k[I] with the extra information "don't use the names". Unfortunately, R cannot know that you will eventually only keep the version without the names - at which point it could strip the names since they are not referenced anymore. I'm not sure what is the best solution here. In theory, if the wrapper found out that the object it is wrapping has no more references it could remove the names, but I'm sure that would only solve some cases (what if you duplicated the wrapper and thus there were multiple wrappers referencing it?) and not sure if it has a way to find out. The other way to deal with that would be at serialization time if it could be detected such that it can remove the wrapper. Since the intersection of serialization experts and ALTREP experts is exactly one, I'll leave it to that set to comment further ;). Currently the wrapper serialization mechanism just serializes the wrapped object and unserialize re-wraps it at the other end. If there is only one reference to the wrapped value then we know the attributes can't be accessed from the R level anymore, so it would be safe to remove the attributes before passing it off for serializing. Unless I'm missing something that would be an easy change. But it would be good to know if it would really make a difference in realistic situations. [Dropping attributes could be done at other times as well if there is only one reference, e.g. on accessing the data, but that is not likely to be worth while within a single R session.] If there is more than one reference to the wrapped object, then things is more complicated. We could duplicate the payload and send that off for serialization (and install it in the wrapper), but that could be a bad idea of the object is large. A tighter integration of ALTREP serialization with the serialization internals might allow and ALTREP's serialization method to write directly to the serialization stream, but that would make things much harder to maintain. Best, luke Cheers, Simon On Jul 23, 2020, at 07:29, Pan Domu wrote: I ran into strange behavior when removing names. Two ways of removing names: i <- rep(1:4, length.out=2) k <- c(a=1, b=2, c=3, d=4) x1 <- unname(k[i]) x2 <- k[i] x2 <- unname(x2) Are they identical? identical(x1,x2) #
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
On 22/07/2020 5:40 p.m., Helmut Schütz wrote:
Duncan Murdoch wrote on 2020-07-22 21:42:
On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
[...]
The problem is that I cannot reproduce it as well. Only CHECK laments
about dev.off() which I changed to graphics.off() in the meantime.
library(grDevices)
foo <- TRUE # shall we plot?
png.path <- "~/" # user's home folder
png.path <- normalizePath(png.path)
if (foo) {
png(paste0(png.path, "test.png"), width = 480, height = 480,
pointsize = 12)
}
plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
if (foo) {
graphics.off()
}
You don't test whether the call to png() succeeded.
Correct. However,
if (file.exists(paste0(png.path, "test.png"))) graphics.off()
worked in the example but not in the package...
During a check, it probably wouldn't, because you aren't allowed to
write to "~/". Your package should be writing to tempdir(), or a
location entered by the user.
The user is asked to provide a certain path indeed. Only if none is
provided, the fallback is "~/" (which is always writable).
That disqualifies your package from inclusion on CRAN. If no
destination is provided and tempdir() isn't acceptable, you shouldn't
write anything. The user may be keeping an irreplaceable piece of
information in "~/test.png", and your package would destroy it. It's
not your decision to make to trespass on the user's file space.
Duncan Murdoch
The package
is intended for "common" users and not "R-geeks". If I would write to
tempdir(), I guess chances are pretty low that a user will be able to
locate the file.
What I still fail to understand: CHECK laments about
grDevices::dev.off() in a certain man page, where I removed the argument
foo completely in one example (which is within \donttest{}). Hence, the
entire plotting routine is not executed at all. Furthermore, dev.off()
is nowhere used, only graphics.off() - now after file.exists().
Regards,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
ehelmut.schu...@bebac.at
Whttps://bebac.at/
Fhttps://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Duncan Murdoch wrote on 2020-07-22 21:42:
> On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
>> [...]
>> The problem is that I cannot reproduce it as well. Only CHECK laments
>> about dev.off() which I changed to graphics.off() in the meantime.
>>
>> library(grDevices)
>> foo <- TRUE # shall we plot?
>> png.path <- "~/" # user's home folder
>> png.path <- normalizePath(png.path)
>> if (foo) {
>> png(paste0(png.path, "test.png"), width = 480, height = 480,
>> pointsize = 12)
>> }
>> plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
>> if (foo) {
>> graphics.off()
>> }
>
> You don't test whether the call to png() succeeded.
Correct. However,
if (file.exists(paste0(png.path, "test.png"))) graphics.off()
worked in the example but not in the package...
> During a check, it probably wouldn't, because you aren't allowed to
> write to "~/". Your package should be writing to tempdir(), or a
> location entered by the user.
The user is asked to provide a certain path indeed. Only if none is
provided, the fallback is "~/" (which is always writable). The package
is intended for "common" users and not "R-geeks". If I would write to
tempdir(), I guess chances are pretty low that a user will be able to
locate the file.
What I still fail to understand: CHECK laments about
grDevices::dev.off() in a certain man page, where I removed the argument
foo completely in one example (which is within \donttest{}). Hence, the
entire plotting routine is not executed at all. Furthermore, dev.off()
is nowhere used, only graphics.off() - now after file.exists().
Regards,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
E helmut.schu...@bebac.at
W https://bebac.at/
F https://forum.bebac.at/
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Invisible names problem
On 22/07/2020 3:29 p.m., Pan Domu wrote: I ran into strange behavior when removing names. Two ways of removing names: i <- rep(1:4, length.out=2) k <- c(a=1, b=2, c=3, d=4) x1 <- unname(k[i]) x2 <- k[i] x2 <- unname(x2) Are they identical? identical(x1,x2) # TRUE but no identical(serialize(x1,NULL),serialize(x2,NULL)) # FALSE But problem is with serialization type 3, cause: identical(serialize(x1,NULL,version = 2),serialize(x2,NULL,version = 2)) # TRUE It seems that the second one keeps names somewhere invisibly. Some function can lost them, e.g. head: identical(serialize(head(x1, 20001),NULL),serialize(head(x2, 20001),NULL)) # TRUE But not saveRDS (so files are bigger), tibble family keeps them but base data.frame seems to drop them. From my test invisible names are in following cases: x1 <- k[i] %>% unname() x3 <- k[i]; x3 <- unname(x3) x5 <- k[i]; x5 <- `names<-`(x5, NULL) x6 <- k[i]; x6 <- unname(x6) but not in this one x2 <- unname(k[i]) x4 <- k[i]; names(x4) <- NULL What kind of magick is that? It hits us when we upgrade from 3.5 (when serialization changed) and had impact on parallelization (cause serialized objects were bigger). You can use .Internal(inspect(x1)) and .Internal(inspect(x2)) to see that the two objects are not identical: > .Internal(inspect(x1)) @1116b7000 14 REALSXP g0c7 [REF(2)] (len=2, tl=0) 1,2,3,4,1,... > .Internal(inspect(x2)) @7f9c77664ce8 14 REALSXP g0c0 [REF(2)] wrapper [srt=-2147483648,no_na=0] @10e7b7000 14 REALSXP g0c7 [REF(6),ATT] (len=2, tl=0) 1,2,3,4,1,... ATTRIB: @7f9c77664738 02 LISTSXP g0c0 [REF(1)] TAG: @7f9c6c027890 01 SYMSXP g1c0 [MARK,REF(65535),LCK,gp=0x4000] "names" (has value) @10e3ac000 16 STRSXP g0c7 [REF(65535)] (len=2, tl=0) @7f9c6ab531c8 09 CHARSXP g1c1 [MARK,REF(10066),gp=0x61] [ASCII] [cached] "a" @7f9c6ae9a678 09 CHARSXP g1c1 [MARK,REF(10013),gp=0x61] [ASCII] [cached] "b" @7f9c6c0496c0 09 CHARSXP g1c1 [MARK,REF(10568),gp=0x61,ATT] [ASCII] [cached] "c" @7f9c6ad3df40 09 CHARSXP g1c1 [MARK,REF(10029),gp=0x61,ATT] [ASCII] [cached] "d" @7f9c6ab531c8 09 CHARSXP g1c1 [MARK,REF(10066),gp=0x61] [ASCII] [cached] "a" ... It looks as though x2 is a tiny ALTREP object acting as a wrapper on the original k[i], but I might be misinterpreting those displays. I don't know how to force ALTREP objects to standard representation: unserializing the serialized x2 gives something like x2, not like x1. Maybe you want to look at one of the contributed low level packages. The stringfish package has a "materialize" function that is advertised to convert anything to standard format, but it doesn't change x2. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] import 'as' from another package
Following WRE 1.5.6 (Namespaces with S4 classes and methods), you should
have "Depends: methods" in your DESCRIPTION, and "import(methods)" or a
more selective "importFrom(methods, ...)" directive in your NAMESPACE.
Then you would usually use the NAMESPACE directive
importMethodsFrom(package, generic)
to explicitly import S4 methods exported from another package.
However, the raster package does not do
exportMethods(coerce)
so if you try
importMethodsFrom(raster, coerce)
you will get
> Error: object ‘coerce’ is not exported by 'namespace:raster'
when trying to install your package (also during R CMD check, of course).
To solve this problem, you could either
- import raster's entire NAMESPACE via import(raster)
- or ask maintainer("raster") to exportMethods(coerce)
- or do
importClassesFrom(raster, RasterLayer)
which will magically make the corresponding coerce methods available as
well.
HTH!
Sebastian Meyer
Am 21.07.20 um 00:41 schrieb Tim Keitt:
> Thanks for pointing to the bug.
>
> Now I am finding I cannot use the 'as' definitions from 'raster' without
> loading the package. Do I need an @import directive that specifies the
> definitions in the 'raster' package? My understanding is that the
> 'setAs' function generates a 'coerce,...' signature but I'm not sure how
> to import it to my package.
>
> Thanks again.
>
> THK
>
> On Mon, Jul 20, 2020 at 2:25 PM Sebastian Meyer > wrote:
>
> Yes, indeed, it is confusing. You don't need to file a new bug
> report, though. There is one already:
>
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17179
>
> Please feel free to comment there. This thread could serve as
> another confirmation. :-)
>
> Best regards,
> Sebastian
>
> Am 20. Juli 2020 18:36:21 MESZ schrieb Ben Bolker >:
> > I think this is a classic confusing R message. Try adding methods
> >to the Imports: statement in your DESCRIPTION file and see if that
> >helps. (Maybe I should file a bug report about that error message - it
> >confuses me every time.)
> >
> >On 7/20/20 12:34 PM, Tim Keitt wrote:
> >> It works but "check" gives
> >>
> >> > checking package dependencies ... ERROR
> >> Namespace dependency not required: ‘methods’
> >>
> >> THK
> >>
> >> On Mon, Jul 20, 2020 at 11:24 AM Ben Bolker
> >> >> wrote:
> >>
> >> @importFrom methods as
> >>
> >> ?
> >>
> >> On 7/20/20 12:06 PM, Tim Keitt wrote:
> >> > I have
> >> >
> >> > if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")
> >> >
> >> > in a package and its not finding the coerce definition from the
> >> raster
> >> > package. I know I need to add an @import roxygen2 directive of
> >> some kind,
> >> > but I'm not sure the correct syntax. My first try generated a
> >> warning that
> >> > it was not needed.
> >> >
> >> > What is the correct way to do this? Or does raster need to
> >> export this
> >> > definition?
> >> >
> >> > THK
> >> >
> >> > [[alternative HTML version deleted]]
> >> >
> >> > __
> >> > R-package-devel@r-project.org
>
> >> > mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> __
> >> R-package-devel@r-project.org
>
> >> > mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> > [[alternative HTML version deleted]]
> >
> >__
> >R-package-devel@r-project.org
> mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Invisible names problem
Very interesting: > .Internal(inspect(k[i])) @10a4bc000 14 REALSXP g0c7 [ATT] (len=2, tl=0) 1,2,3,4,1,... ATTRIB: @7fa24f07fa58 02 LISTSXP g0c0 [REF(1)] TAG: @7fa24b803e90 01 SYMSXP g0c0 [MARK,REF(5814),LCK,gp=0x6000] "names" (has value) @10a4e4000 16 STRSXP g0c7 [REF(1)] (len=2, tl=0) @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(35005),gp=0x61] [ASCII] [cached] "a" @7fa24be24428 09 CHARSXP g0c1 [MARK,REF(35010),gp=0x61] [ASCII] [cached] "b" @7fa24b806ec0 09 CHARSXP g0c1 [MARK,REF(35082),gp=0x61] [ASCII] [cached] "c" @7fa24bcc6af0 09 CHARSXP g0c1 [MARK,REF(35003),gp=0x61] [ASCII] [cached] "d" @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(35005),gp=0x61] [ASCII] [cached] "a" ... > .Internal(inspect(unname(k[i]))) @10a50c000 14 REALSXP g0c7 [] (len=2, tl=0) 1,2,3,4,1,... > .Internal(inspect(x2)) @7fa24fc692d8 14 REALSXP g0c0 [REF(1)] wrapper [srt=-2147483648,no_na=0] @10a228000 14 REALSXP g0c7 [REF(1),ATT] (len=2, tl=0) 1,2,3,4,1,... ATTRIB: @7fa24fc69850 02 LISTSXP g0c0 [REF(1)] TAG: @7fa24b803e90 01 SYMSXP g0c0 [MARK,REF(5797),LCK,gp=0x4000] "names" (has value) @10a25 16 STRSXP g0c7 [REF(65535)] (len=2, tl=0) @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(10005),gp=0x61] [ASCII] [cached] "a" @7fa24be24428 09 CHARSXP g0c1 [MARK,REF(10010),gp=0x61] [ASCII] [cached] "b" @7fa24b806ec0 09 CHARSXP g0c1 [MARK,REF(10077),gp=0x61] [ASCII] [cached] "c" @7fa24bcc6af0 09 CHARSXP g0c1 [MARK,REF(10003),gp=0x61] [ASCII] [cached] "d" @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(10005),gp=0x61] [ASCII] [cached] "a" ... If you don't assign the intermediate result things are simple as R knows there are no references so the names can be simply removed. However, if you assign the result that is not possible as there is still the reference in x2 at the time when unname() creates its own local temporary variable obj to do what probably most of us would use which is names(obj) <- NULL (i.e. names(x2) <- NULL avoids that problem.since you don't need both x2 and obj). To be precise, when you use unname() on an assigned object, R has to technically keep two copies - one for the existing x2 and a second in unname() for obj so it can call names(obj)<-NULL for the modification. To avoid that R instead creates a wrapper for the original x2 which says "like x2 but names are NULL". The rationale is that for large vector it is better to keep records of metadata changes rather than duplicating the object. This way the vector is stored only once. However, as you blow way the original x2, all that is left is k[I] with the extra information "don't use the names". Unfortunately, R cannot know that you will eventually only keep the version without the names - at which point it could strip the names since they are not referenced anymore. I'm not sure what is the best solution here. In theory, if the wrapper found out that the object it is wrapping has no more references it could remove the names, but I'm sure that would only solve some cases (what if you duplicated the wrapper and thus there were multiple wrappers referencing it?) and not sure if it has a way to find out. The other way to deal with that would be at serialization time if it could be detected such that it can remove the wrapper. Since the intersection of serialization experts and ALTREP experts is exactly one, I'll leave it to that set to comment further ;). Cheers, Simon > On Jul 23, 2020, at 07:29, Pan Domu wrote: > > I ran into strange behavior when removing names. > > Two ways of removing names: > >i <- rep(1:4, length.out=2) >k <- c(a=1, b=2, c=3, d=4) > >x1 <- unname(k[i]) >x2 <- k[i] >x2 <- unname(x2) > > Are they identical? > >identical(x1,x2) # TRUE > > but no > >identical(serialize(x1,NULL),serialize(x2,NULL)) # FALSE > > But problem is with serialization type 3, cause: > >identical(serialize(x1,NULL,version = 2),serialize(x2,NULL,version = > 2)) # TRUE > > It seems that the second one keeps names somewhere invisibly. > > Some function can lost them, e.g. head: > >identical(serialize(head(x1, 20001),NULL),serialize(head(x2, > 20001),NULL)) # TRUE > > But not saveRDS (so files are bigger), tibble family keeps them but base > data.frame seems to drop them. > > From my test invisible names are in following cases: > > x1 <- k[i] %>% unname() > x3 <- k[i]; x3 <- unname(x3) > x5 <- k[i]; x5 <- `names<-`(x5, NULL) > x6 <- k[i]; x6 <- unname(x6) > > but not in this one > x2 <- unname(k[i]) > x4 <- k[i]; names(x4) <- NULL > > What kind of magick is that? > > It hits us when we upgrade from 3.5 (when serialization changed) and had > impact on parallelization (cause serialized objects were bigger). > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list >
[Rd] Invisible names problem
I ran into strange behavior when removing names. Two ways of removing names: i <- rep(1:4, length.out=2) k <- c(a=1, b=2, c=3, d=4) x1 <- unname(k[i]) x2 <- k[i] x2 <- unname(x2) Are they identical? identical(x1,x2) # TRUE but no identical(serialize(x1,NULL),serialize(x2,NULL)) # FALSE But problem is with serialization type 3, cause: identical(serialize(x1,NULL,version = 2),serialize(x2,NULL,version = 2)) # TRUE It seems that the second one keeps names somewhere invisibly. Some function can lost them, e.g. head: identical(serialize(head(x1, 20001),NULL),serialize(head(x2, 20001),NULL)) # TRUE But not saveRDS (so files are bigger), tibble family keeps them but base data.frame seems to drop them. >From my test invisible names are in following cases: x1 <- k[i] %>% unname() x3 <- k[i]; x3 <- unname(x3) x5 <- k[i]; x5 <- `names<-`(x5, NULL) x6 <- k[i]; x6 <- unname(x6) but not in this one x2 <- unname(k[i]) x4 <- k[i]; names(x4) <- NULL What kind of magick is that? It hits us when we upgrade from 3.5 (when serialization changed) and had impact on parallelization (cause serialized objects were bigger). [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
On 22/07/2020 1:25 p.m., Helmut Schütz wrote:
Hi Serguei,
Serguei Sokol wrote on 2020-07-22 15:51:
Hmm... I see 2 possibilities for still getting an error while the
concerned part of code is not supposed to be run:
- either you are running not updated version of your package;
I _can_ built the package and it runs as intended. Only the CHECK throws
the error.
- or the error comes from some other place of the code.
Closing the device is required only _once_ in the entire package.
In my NAMESPACE I have (and had in all previous versions):
importFrom(grDevices, png, graphics.off, dev.list, dev.off)
Sorry but without a minimal reproducible example I cannot help more.
The problem is that I cannot reproduce it as well. Only CHECK laments
about dev.off() which I changed to graphics.off() in the meantime.
library(grDevices)
foo <- TRUE # shall we plot?
png.path <- "~/" # user's home folder
png.path <- normalizePath(png.path)
if (foo) {
png(paste0(png.path, "test.png"), width = 480, height = 480,
pointsize = 12)
}
plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
if (foo) {
graphics.off()
}
You don't test whether the call to png() succeeded. During a check, it
probably wouldn't, because you aren't allowed to write to "~/". Your
package should be writing to tempdir(), or a location entered by the user.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Hi Serguei,
Serguei Sokol wrote on 2020-07-22 15:51:
Hmm... I see 2 possibilities for still getting an error while the
concerned part of code is not supposed to be run:
- either you are running not updated version of your package;
I _can_ built the package and it runs as intended. Only the CHECK throws
the error.
- or the error comes from some other place of the code.
Closing the device is required only _once_ in the entire package.
In my NAMESPACE I have (and had in all previous versions):
importFrom(grDevices, png, graphics.off, dev.list, dev.off)
Sorry but without a minimal reproducible example I cannot help more.
The problem is that I cannot reproduce it as well. Only CHECK laments
about dev.off() which I changed to graphics.off() in the meantime.
library(grDevices)
foo <- TRUE # shall we plot?
png.path <- "~/" # user's home folder
png.path <- normalizePath(png.path)
if (foo) {
png(paste0(png.path, "test.png"), width = 480, height = 480,
pointsize = 12)
}
plot(x = 0:1, y = 0:1, type = "l", xlab = "x", ylab = "y")
if (foo) {
graphics.off()
}
Best,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
T +43 1 2311746
M +43 699 10792458
E helmut.schu...@bebac.at
W https://bebac.at/
C https://bebac.at/Contact.htm
F https://forum.bebac.at/
GIS 24799386, VAT ATU61115625, DUNS 300370568, EORI ATEOS196209
GDPR https://bebac.at/Data-Protection.htm
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
On 22/07/2020 8:36 a.m., Helmut Schütz wrote:
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected in all versions of my package built in R up to
v3.6.3. However, when I CHECK the package in v4.0.2 I get:
> grDevices::dev.off()
Error in grDevices::dev.off() :
cannot shut down device 1 (the null device)
Execution halted
I tried:
if (foo | (foo & bar)) {
Assuming that foo and bar are each length one variables, this test is
logically equivalent to
if (foo) {
Is that really what you intended?
Duncan Murdoch
dev <- dev.list()
if (!is.null(dev)) {
if (dev == 2) invisible(dev.off())
}
}
without success (same error).
Even the more general
if (foo | (foo & bar)) {
graphics.off()
}
did not work.
The plot is called only in an example of one man-page -- though embedded
in \donttest{}.
Even if I set both foo and bar to FALSE (i.e., the respective part of
the code should not be executed at all), I get the same error.
Any ideas/suggestions?
Regards,
Helmut
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
I suspect your foo and bar variables are not logical anymore... insufficient
info. However, why aren't you using short-circuit && and || operators?
On July 22, 2020 5:36:06 AM PDT, "Helmut Schütz"
wrote:
>Dear all,
>
>I have two variables, foo and bar. The first is TRUE if a png should be
>
>created and the second is TRUE if an already existing one should be
>overwritten.
>At the end of the plot I had
>if (foo | (foo & bar)) dev.off()
>This worked as expected in all versions of my package built in R up to
>v3.6.3. However, when I CHECK the package in v4.0.2 I get:
> > grDevices::dev.off()
>Error in grDevices::dev.off() :
> cannot shut down device 1 (the null device)
>Execution halted
>
>I tried:
>if (foo | (foo & bar)) {
> dev <- dev.list()
> if (!is.null(dev)) {
> if (dev == 2) invisible(dev.off())
> }
>}
>without success (same error).
>
>Even the more general
>if (foo | (foo & bar)) {
> graphics.off()
>}
>did not work.
>
>The plot is called only in an example of one man-page -- though
>embedded
>in \donttest{}.
>Even if I set both foo and bar to FALSE (i.e., the respective part of
>the code should not be executed at all), I get the same error.
>
>Any ideas/suggestions?
>
>Regards,
>Helmut
--
Sent from my phone. Please excuse my brevity.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Error in CHECK caused by dev.off()
Le 22/07/2020 à 14:36, Helmut Schütz a écrit :
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected in all versions of my package built in R up to
v3.6.3. However, when I CHECK the package in v4.0.2 I get:
> grDevices::dev.off()
Error in grDevices::dev.off() :
cannot shut down device 1 (the null device)
Execution halted
I tried:
if (foo | (foo & bar)) {
dev <- dev.list()
if (!is.null(dev)) {
if (dev == 2) invisible(dev.off())
}
}
without success (same error).
Even the more general
if (foo | (foo & bar)) {
graphics.off()
}
did not work.
The plot is called only in an example of one man-page -- though embedded
in \donttest{}.
Even if I set both foo and bar to FALSE (i.e., the respective part of
the code should not be executed at all), I get the same error.
Hmm... I see 2 possibilities for still getting an error while the
concerned part of code is not supposed to be run:
- either you are running not updated version of your package;
- or the error comes from some other place of the code.
Sorry but without a minimal reproducible example I cannot help more.
Best,
Serguei.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Error in CHECK caused by dev.off()
Dear all,
I have two variables, foo and bar. The first is TRUE if a png should be
created and the second is TRUE if an already existing one should be
overwritten.
At the end of the plot I had
if (foo | (foo & bar)) dev.off()
This worked as expected in all versions of my package built in R up to
v3.6.3. However, when I CHECK the package in v4.0.2 I get:
> grDevices::dev.off()
Error in grDevices::dev.off() :
cannot shut down device 1 (the null device)
Execution halted
I tried:
if (foo | (foo & bar)) {
dev <- dev.list()
if (!is.null(dev)) {
if (dev == 2) invisible(dev.off())
}
}
without success (same error).
Even the more general
if (foo | (foo & bar)) {
graphics.off()
}
did not work.
The plot is called only in an example of one man-page -- though embedded
in \donttest{}.
Even if I set both foo and bar to FALSE (i.e., the respective part of
the code should not be executed at all), I get the same error.
Any ideas/suggestions?
Regards,
Helmut
--
Ing. Helmut Schütz
BEBAC – Consultancy Services for
Bioequivalence and Bioavailability Studies
Neubaugasse 36/11
1070 Vienna, Austria
W https://bebac.at/
F https://forum.bebac.at/
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] trivial typo in ?Matrix::sparse.model.matrix.Rd
> The *first* package on the Ecfun imports list, is fda, which is *your* > package (technically, contributor), and it has a dependency on the > Matrix package. My post this morning might have come across the wrong way. It's good that you're interested in software for numerical linear algebra. (I only just worked the importance of this, about a year ago). And I may also have a closer look at the Matrix package, in the near future. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
