[Bioc-devel] NanoporeRNASeq not found in the devel Bioc3.12 package list

[CHEN Ying]

Hello,

I received an email saying our package bambu built in Bioc3.12 produce errors, 
which I found was due to the dependent ExperimentData package NanoporeRNASeq 
was not built in the Bioc3.12 package list. However, when I check the Bioc3.13 
package list, both bambu and NanoporeRNASeq were built successfully.

I was wondering will NanoporeRNASeq still be included in the Bioc3.12 version? 
If so, when will the status be reflected on Bioc3.12 package list?

Thank you
Regards
CHEN Ying
This e-mail and any attachments are only for the use of the intended recipient 
and may contain material that is confidential, privileged and/or protected by 
the Official Secrets Act. If you are not the intended recipient, please delete 
it or notify the sender immediately. Please do not copy or use it for any 
purpose or disclose the contents to any other person.

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Issue with data() function

[Therneau, Terry M., Ph.D. via R-devel]

I found an issue with the data() command this evening when working on the 
survival package.

1. I have a lot of data sets in the package, almost all used in at least one 
vignette, 
help file, or test.  As a space saving measure, I have bundled many of them 
together, 
i.e., the file data/cancer.rda contains 19 data sets, many of them small. The 
resulting 
file (using xz compression) is quite a bit smaller than the individual ones.  
(I still get 
a warning note about size from R CMD check, but I'm no longer 2x the limit.)

2. Consider the lung data set.  All of these fail:
    data(lung)
    data("lung")
    data(lung, package="survival")

  a. The lung.Rd file had \usage{data(lung)}; that error was not caught by R 
CMD check.  
(Several other .Rd files as well.)

  b. In broader examples for teaching, I sometimes load data from other 
packages, e.g 
data(aidssi, package="mstate").  But this does not work for survival.  (The 
larger 
survival data sets that are in separate .rda files can be found.)

  c. What does work is survival::lung.  Might it be useful to add a comment to 
data.Rd to 
this effect?


3. Creating a separate package 'survivaldata' is of course one route, and is 
suggested in 
the "Writing R Extensions" guide.  But this is not possible since survival is a 
recommended package: it can't load any non-recommended package for it's tests 
or 
vignettes.  Longer term, perhaps there is way around this constraint?

Terry T.

-- 
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
thern...@mayo.edu

"TERR-ree THUR-noh"


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Change to I() in R 4.1

[Pages, Herve]

Hi there,

Is that change in R-devel intentional?

   library(Matrix)
   m <- as(matrix(c(0, 1)), "sparseMatrix")

   isS4(m)
   # [1] TRUE

   x <- I(m)
   # Warning message:
   # In `class<-`(x, unique.default(c("AsIs", oldClass(x :
   #   Setting class(x) to multiple strings ("AsIs", "dgCMatrix", ...); 
result will no longer be an S4 object

   isS4(x)
   # [1] FALSE

This works fine in R 4.0.3 i.e. no warning and I() doesn't turn off the 
S4 bit of the object.

This change breaks 17 Bioconductor packages.

Seems that the culprit is this change in how I() is implemented:

In R 4.0.3:

   > I
   function (x)
   {
 structure(x, class = unique(c("AsIs", oldClass(x
   }

In R devel:

   > I
   function (x)
   `class<-`(x, unique.default(c("AsIs", oldClass(x

Unfortunately there is a bunch of code around that calls I() on S4 
objects, admittedly not necessarily for very good reasons, but it 
happens. Would it be possible that I() has a less destructive effect on 
S4 objects?

Thanks,
H.

 > sessionInfo()
R Under development (unstable) (2020-10-17 r79346)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS

Matrix products: default
BLAS:   /home/biocbuild/bbs-3.13-bioc/R/lib/libRblas.so
LAPACK: /home/biocbuild/bbs-3.13-bioc/R/lib/libRlapack.so

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=en_US.UTF-8   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

other attached packages:
[1] Matrix_1.2-18

loaded via a namespace (and not attached):
[1] compiler_4.1.0  grid_4.1.0  lattice_0.20-41

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] pretest order

[Uwe Ligges]

It will make them run.

Best,
Uwe Ligges

On 23.10.2020 23:52, Roy Mendelssohn - NOAA Federal wrote:

Thanks.  I had a feeling that was the case from looking at the queue.  Does the 
clearing make them run or do they need to be resubmitted?

-Roy



On Oct 23, 2020, at 2:43 PM, Uwe Ligges  wrote:

Generally by submission time, but there is a series of packages unprocessed 
stuck in the queue, will clear that up shortly.


Best,
Uwe

On 23.10.2020 19:17, Roy Mendelssohn - NOAA Federal via R-package-devel wrote:

Just out of curiousity,  how is pretest order determined?  I have a package 
that was submitted yesterday that is still waiting pretest,  while one I 
submitted today was just pretested.   Both are just bug fixes of existing 
packages,  not new packages.
Thanks for the info and the work on CRAN,  Having to deal recently with package 
hell in Python, I appreciate these efforts.
-Roy
**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] pretest order

[Roy Mendelssohn - NOAA Federal via R-package-devel]

Thanks.  I had a feeling that was the case from looking at the queue.  Does the 
clearing make them run or do they need to be resubmitted?

-Roy


> On Oct 23, 2020, at 2:43 PM, Uwe Ligges  
> wrote:
> 
> Generally by submission time, but there is a series of packages unprocessed 
> stuck in the queue, will clear that up shortly.
> 
> 
> Best,
> Uwe
> 
> On 23.10.2020 19:17, Roy Mendelssohn - NOAA Federal via R-package-devel wrote:
>> Just out of curiousity,  how is pretest order determined?  I have a package 
>> that was submitted yesterday that is still waiting pretest,  while one I 
>> submitted today was just pretested.   Both are just bug fixes of existing 
>> packages,  not new packages.
>> Thanks for the info and the work on CRAN,  Having to deal recently with 
>> package hell in Python, I appreciate these efforts.
>> -Roy
>> **
>> "The contents of this message do not reflect any position of the U.S. 
>> Government or NOAA."
>> **
>> Roy Mendelssohn
>> Supervisory Operations Research Analyst
>> NOAA/NMFS
>> Environmental Research Division
>> Southwest Fisheries Science Center
>> ***Note new street address***
>> 110 McAllister Way
>> Santa Cruz, CA 95060
>> Phone: (831)-420-3666
>> Fax: (831) 420-3980
>> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>> "Old age and treachery will overcome youth and skill."
>> "From those who have been given much, much will be expected"
>> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] sum() (and similar methods) should work for zero row data.frames

[Pages, Herve]

Hi,

There are 2 bugs here. The proposed fix to Summary.data.frame() is fine 
but it doesn't address the other problem reported by the OP that 
as.matrix() on a zero-row data.frame doesn't respect the type of its 
columns, like other column-combining operations do:

   df <- data.frame(a=numeric(0), b=numeric(0))

   typeof(as.matrix(df))
   # [1] "logical"

   typeof(unlist(df))
   # [1] "double"

   typeof(do.call(c, df))
   # [1] "double"

I've run myself into this in a couple of occasions (not in the context 
of Summary methods) and worked around it with something like:

   as_matrix_data_frame <- function(df)
   {
 ans <- as.matrix(df)
 if (nrow(df) == 0L)
 storage.mode(ans) <- typeof(unlist(df))
 ans
   }

No reason as.matrix.data.frame() couldn't do something similar.

Cheers,
H.


On 10/20/20 09:36, Martin Maechler wrote:
>> mb706
>>  on Sun, 18 Oct 2020 22:14:55 +0200 writes:
> 
>  >> From my side: it would be great if you (or R core) could prepare a 
> patch, it would probably take me quite a bit longer than you since I don't 
> have experience creating patches for R.
> 
>  > Best, Martin
> 
> Basically, just
> 
> 1.  svn co 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__svn.r-2Dproject.org_R_trunk=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=YAI4LgZvkD5k-tPHUGFX4PEjm72-6j_WxHpkdHfe_3Q=PpmVRjh2Jrg07bLHjlbhdBgWQWAFe6RK_J2SivC74vw=
>R-devel
> 
> 2.  inside the R-devel source tree, find  src/library/base/R/dataframe.R
>  make the *minimal* changes there,
> 
>  (then also add some regression tests and update the help :-)
> 
> 3.  inside R-devel, do
> 
>  svn diff -x -ubw  >  mb706.patch
> 
> 4.  you've got the patch file  mb706.patch  which you could
>  attach to a bug report  on R's bugzilla
> 
>  (once you've got an account there ...
>   As you've asked for that *and* as you've proven your good
>   judgment about "true bug" vs. "not what I expected",
>   I'll create such an account for you now, in spite of the
>   fact that I'd still like to know a bit more than "Martin
>   mb706" about you  ...)
> 
> The changes have been committed to R-devel a quarter of an hour ago.
> We will keep them in R-devel (currently planned to become R
> 4.1.0 in spring 2021), and not port to the R-4.0.z branch, as
> the change is something like an API change, and also because
> nobody had ever reported this as an issue to our knowledge.
> 
> Thank you, Martin B706 for bringing the issue up,  and Gabe and Peter
> for chiming in !!
> 
> Best regards,
> Martin Maechler
> ETH Zurich  and  R core team
>  
> 
>  > On Sun, Oct 18, 2020, at 21:49, Gabriel Becker wrote:
>  >> Peter et al,
>  >>
>  >> I had the same thought, in particular for any() and all(), which in as
>  >> much as they should work on data.frames in the first place (which to 
> be
>  >> perfectly honest i do find quite debatable myself), should certainly
>  >> work on "logical" data.frames if they are going to work on "numeric"
>  >> ones.
>  >>
>  >> I can volunteer to prepare a patch if Martin (the reporter) did not
>  >> want to take a crack at it, and further if it is not already being 
> done
>  >> within R-core.
>  >>
>  >> Best,
>  >> ~G
>  >>
>  >> On Sun, Oct 18, 2020 at 12:19 AM peter dalgaard  
> wrote:
>  >> > Hmm, yes, this is probably wrong. E.g., we are likely to get 
> inconsistencies out of boundary cases like this
>  >> >
>  >> > > a <- na.omit(airquality)
>  >> > > sum(a)
>  >> > [1] 37495.3
>  >> > > sum(a[FALSE,])
>  >> > Error in FUN(X[[i]], ...) :
>  >> >   only defined on a data frame with all numeric variables
>  >> >
>  >> > Or, closer to an actual use case:
>  >> >
>  >> > > sum(subset(a, Ozone>100))
>  >> > [1] 3330.5
>  >> > > sum(subset(a, Ozone>200))
>  >> > Error in FUN(X[[i]], ...) :
>  >> >   only defined on a data frame with all numeric variables
>  >> >
>  >> >
>  >> > However, given that numeric summaries generally treat logicals as 
> 0/1, wouldn't it be easiest just to extend the check inside 
> Summary.data.frame with "&& !is.logical(x)"?
>  >> >
>  >> > > sum(as.matrix(a[FALSE,]))
>  >> > [1] 0
>  >> >
>  >> > -pd
>  >> >
>  >> > > On 17 Oct 2020, at 21:18 , Martin  wrote:
>  >> > >
>  >> > > The "Summary" group generics always throw errors for a data.frame 
> with zero rows, for example:
>  >> > >> sum(data.frame(x = numeric(0)))
>  >> > > #> Error in FUN(X[[i]], ...) :
>  >> > > #>   only defined on a data frame with all numeric variables
>  >> > > Same behaviour for min, max, any, all, ... . I believe this is 
> inconsistent with what these methods do for other empty objects (vectors, 
> matrices), where the return value is chosen to ensure transitivity: 
> sum(numeric(0)) == 0.
>  >> > >
>   

Re: [R-pkg-devel] pretest order

[Uwe Ligges]

Generally by submission time, but there is a series of packages 
unprocessed stuck in the queue, will clear that up shortly.



Best,
Uwe

On 23.10.2020 19:17, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:

Just out of curiousity,  how is pretest order determined?  I have a package 
that was submitted yesterday that is still waiting pretest,  while one I 
submitted today was just pretested.   Both are just bug fixes of existing 
packages,  not new packages.

Thanks for the info and the work on CRAN,  Having to deal recently with package 
hell in Python, I appreciate these efforts.

-Roy

**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[Sebastian Meyer]

Hi Iago,

I think the unlist behaviour is expected. If the list contains a mixture
of character and integer elements, the unlisted object will be a
character vector, similar to what happens when you c()oncatenate
components of different types (see the details in ?c for the hierarchy).
If you only need the numeric POSIXlt components anyway, you could do

unlist("$<-"(x, "zone", NULL))

to ensure that you get a numeric vector.
Alternatively, you can nicely do

as.data.frame(unclass(x))

to get all components in a data frame.

Concerning your second observation: Yes, the documentation of the
"tzone" attribute was wrong until very recently; I stumbled over this
exact trap one week ago and reported to R-core members. It has been
fixed in the development version (c79351) a few days ago and now says:

>   a character vector of length 3 giving the time zone name (from the 'TZ'
>   environment variable or argument 'tz' of functions creating
>   '"POSIXlt"' objects; '""' marks the current time zone)


Best regards,

Sebastian


Am 23.10.20 um 19:27 schrieb IAGO GINÉ VÁZQUEZ:
> ​Hi again,
> 
> I take advantage of my previous mail to ask you a question for which I was 
> looking  for an answer when detected the behaviour I previously told. In the 
> help of DataTimeClasses one can read:
> "POSIXlt" objects will often have an attribute "tzone", a character vector of 
> length 3 giving the time zone name from the TZ environment variable and the 
> names of the base time zone and the alternate (daylight-saving) time zone. 
> Sometimes this may just be of length one, giving the time zone name.
> Then, I asked myself if the element `zone` of POSIXlt could be different of 
> the attribute `tzone`. But I do not get that. I am not sure of understanding 
> what the "time zone name from the TZ environment variable" is if not what I 
> set through `Sys.setenv(TZ = "")`. But the next example does not behave as I 
> would expect:
> 
>> Sys.setenv(TZ = "EDT")
>> x <- as.POSIXlt(Sys.time(), "CET")
> 
>> x[1,"zone"]
> [1] "CEST"
> 
>> attributes(x) $names  [1] "sec""min""hour"   "mday"   "mon"
>> "year"   "wday"   "yday"   "isdst"  "zone"   "gmtoff" $class [1] "POSIXlt" 
>> "POSIXt" $tzone [1] "CET"  "CET"  "CEST"
> 
> So `x[1,"zone"]` is what I expect, but I would expect `attributes(x)$tzone` 
> would be related to `TZ = "EDT"`, and not to `tz = "CET"`. So, what am I 
> understanding wrongly?
> 
> Thank you!
> Stay safe,
> 
> 
> Iago
> 
> 
> De: R-devel  de part de IAGO GINÉ VÁZQUEZ 
> 
> Enviat el: divendres, 23 d’octubre de 2020 19:03
> Per a: r-devel@r-project.org 
> Tema: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone 
> as a cause of possible inconsistences?
> 
> Dear all,
> 
> I have just detected what seems a minor inconsistence with data types. If one 
> unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt 
> list has no `zone` element, while if one unlists a POSIXlt time with a non 
> GMT zone (also non specifying tz if the Sys.timezone is not GMT) gets a 
> character vector due to including the `zone` element.
> 
>> x <- as.POSIXlt(Sys.time(), "GMT")
>> (y <- unlist(x))
>   sec   min  hour  mday   mon  year  wday  
> yday isdst
>  54.99715  26.0  16.0  23.0   9.0 120.0   5.0 
> 296.0   0.0
>> str(y)
>  Named num [1:9] 55 26 16 23 9 ...
>  - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...
> 
>> x <- as.POSIXlt(Sys.time(), "CET")
>> (y <- unlist(x))
>secmin   hour   mday   
>  mon   year   wday   yday
> "19.5111262798309"   "27"   "18"   "23"   
>  "9"  "120""5"  "296"
>  isdst   zone gmtoff
>"1" "CEST" "7200"
>> str(y)
>  Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
> "CEST" "7200"
>  - attr(*, "names")= chr [1:11] "sec" "min" "hour" "mday" ...
> 
> Is it expected? Why do not include always `zone` as an element of POSIXlt? 
> Should POSIXlt objects be unlisted in a different way?
> Thank you!
> Best regards,
> 
> Iago
> 
> PS: I was using R 4.0.3. I don't know if this behaviour already changed in 
> R-devel. Excuse me in that case.
> 
> 
> [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
Dr. Sebastian Meyer
Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU)
Institut für Medizininformatik, Biometrie und 

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Tim Taylor]

I've made an example at https://github.com/tjtnew/newbies that uses
GitHub actions to monitor how many hours a package has been in the
"newbies" queue.  It updates hourly and saves to a csv in the repo.
It's not something I have time to develop more but if someone wants to
pick it up and take it further please do. Disclaimer - hacked together
quite quickly so code could well be a little iffy.
Best
Tim


On Wed, 21 Oct 2020 at 20:47, Henrik Bengtsson
 wrote:
>
> Related to this:
>
> It would be neat to have a dashboard that reports on the current
> latency is on the different CRAN "queues" are, e.g. how long is the
> average waiting time when submitting a new package ("newbies") until
> you get a manual reply or it's on CRAN, submitting an update with all
> OK before it hits CRAN, waiting time for building Windows or macOS
> binaries, etc.  Some, but not all, of this information can already be
> guestimated from the info on ftp://cran.r-project.org/incoming/, on
> easier on https://lockedata.github.io/cransays/articles/dashboard.html.
> I think this could be a great contributor project - it doesn't have to
> be hosted by CRAN.
>
> /Henrik
>
> On Wed, Oct 21, 2020 at 11:08 AM Marc Schwartz  wrote:
> >
> > Hi All,
> >
> > Just thought that I would check to see if there are any known issues/delays 
> > for CRAN in creating R release and devel binaries for Windows for updated 
> > packages.
> >
> > It has been four days since I submitted an update and the other binaries 
> > were created within a couple of days. The two Windows binaries are the only 
> > outstanding updates pending.
> >
> > Thanks!
> >
> > Marc Schwartz
> >
> > __
> > 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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

Hi Uwe,

Thanks for taking the time to reply.

Would you be willing to clarify/confirm the current situation regarding the 
hosting of non-FOSS packages on CRAN, such as those with ACM or Creative 
Commons license variants that have non-commercial use restrictions? 

These are presently included in the license.db file.

Are these on CRAN now because they are acceptable under the current policy, or 
are they on CRAN now, as Duncan posited, because they were acceptable under 
older policies and it would be disruptive to remove them now?

Thanks,

Marc


> On Oct 23, 2020, at 8:57 AM, Uwe Ligges  
> wrote:
> 
> I do not want to make many general comments about licenses in public, as this 
> is a very difficult matter and I am not a lawyer.
> 
> But let me cite from the CRAN policies:
> 
> "Packages with licenses not listed at 
> https://svn.r-project.org/R/trunk/share/licenses/license.db will generally 
> not be accepted. "
> 
> Further, I see in the discussions that you talked about depending on a 
> software with a non-FOSS license. The CRAN team's point of view, for short, 
> is:
> A package with a FOSS license cannot strictly depend on a package/software 
> that is non-FOSS. Obviously, the FOSS package cannot be used under its own 
> license conditions in that case.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> On 23.10.2020 14:25, Ege Rubak wrote:
>> Hi all,
>> My two cents are below Marc's summary here:
>> On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
>>> Right now, the interpretation, without further clarification from
>>> CRAN, would be, it is ok for a package to be on CRAN with license
>>> based usage restrictions included (e.g. for non-commercial use), but
>>> a package on CRAN, irrespective of it's own license, cannot
>>> "interact" with other packages that do have restrictions...which
>>> seems inconsistent.
>> It depends a bit what is meant by "interact". Years ago `spatstat` used
>> `gpclib` with a non-commercial license to do polygonal operations. The
>> solution was to list `gpclib` in `Suggests` and require the user to
>> make an active choice to use this piece of software with a warning
>> about non-commercial use. I find this to be an OK solution in lack of
>> completely free alternatives. These days `gpclib` is still on CRAN and
>> only has reverse `Suggests` and `Enhances`, so that seems fairly
>> consistent.
>> In the long run this was unsatisfatory and our specific problem was
>> solved by Adrian Baddeley by making the `polyclip` package.
>> Kind regards,
>> Ege
>> __
>> 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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[IAGO GINÉ VÁZQUEZ]

​Hi again,

I take advantage of my previous mail to ask you a question for which I was 
looking  for an answer when detected the behaviour I previously told. In the 
help of DataTimeClasses one can read:
"POSIXlt" objects will often have an attribute "tzone", a character vector of 
length 3 giving the time zone name from the TZ environment variable and the 
names of the base time zone and the alternate (daylight-saving) time zone. 
Sometimes this may just be of length one, giving the time zone name.
Then, I asked myself if the element `zone` of POSIXlt could be different of the 
attribute `tzone`. But I do not get that. I am not sure of understanding what 
the "time zone name from the TZ environment variable" is if not what I set 
through `Sys.setenv(TZ = "")`. But the next example does not behave as I would 
expect:

> Sys.setenv(TZ = "EDT")
> x <- as.POSIXlt(Sys.time(), "CET")

> x[1,"zone"]
[1] "CEST"

> attributes(x) $names  [1] "sec""min""hour"   "mday"   "mon""year" 
>   "wday"   "yday"   "isdst"  "zone"   "gmtoff" $class [1] "POSIXlt" "POSIXt" 
> $tzone [1] "CET"  "CET"  "CEST"

So `x[1,"zone"]` is what I expect, but I would expect `attributes(x)$tzone` 
would be related to `TZ = "EDT"`, and not to `tz = "CET"`. So, what am I 
understanding wrongly?

Thank you!
Stay safe,


Iago


De: R-devel  de part de IAGO GINÉ VÁZQUEZ 

Enviat el: divendres, 23 d’octubre de 2020 19:03
Per a: r-devel@r-project.org 
Tema: [Rd] The presence/absence of `zone` in POSIXlt depending on time zone as 
a cause of possible inconsistences?

Dear all,

I have just detected what seems a minor inconsistence with data types. If one 
unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt 
list has no `zone` element, while if one unlists a POSIXlt time with a non GMT 
zone (also non specifying tz if the Sys.timezone is not GMT) gets a character 
vector due to including the `zone` element.

> x <- as.POSIXlt(Sys.time(), "GMT")
> (y <- unlist(x))
  sec   min  hour  mday   mon  year  wday  yday 
isdst
 54.99715  26.0  16.0  23.0   9.0 120.0   5.0 296.0 
  0.0
> str(y)
 Named num [1:9] 55 26 16 23 9 ...
 - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...

> x <- as.POSIXlt(Sys.time(), "CET")
> (y <- unlist(x))
   secmin   hour   mday 
   mon   year   wday   yday
"19.5111262798309"   "27"   "18"   "23" 
   "9"  "120""5"  "296"
 isdst   zone gmtoff
   "1" "CEST" "7200"
> str(y)
 Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
"CEST" "7200"
 - attr(*, "names")= chr [1:11] "sec" "min" "hour" "mday" ...

Is it expected? Why do not include always `zone` as an element of POSIXlt? 
Should POSIXlt objects be unlisted in a different way?
Thank you!
Best regards,

Iago

PS: I was using R 4.0.3. I don't know if this behaviour already changed in 
R-devel. Excuse me in that case.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[R-pkg-devel] pretest order

[Roy Mendelssohn - NOAA Federal via R-package-devel]

Just out of curiousity,  how is pretest order determined?  I have a package 
that was submitted yesterday that is still waiting pretest,  while one I 
submitted today was just pretested.   Both are just bug fixes of existing 
packages,  not new packages. 

Thanks for the info and the work on CRAN,  Having to deal recently with package 
hell in Python, I appreciate these efforts.

-Roy

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 23, 2020, at 8:25 AM, Ege Rubak  wrote:
> 
> Hi all,
> 
> My two cents are below Marc's summary here:
> 
> On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
>> Right now, the interpretation, without further clarification from
>> CRAN, would be, it is ok for a package to be on CRAN with license
>> based usage restrictions included (e.g. for non-commercial use), but
>> a package on CRAN, irrespective of it's own license, cannot
>> "interact" with other packages that do have restrictions...which
>> seems inconsistent.
> 
> It depends a bit what is meant by "interact". Years ago `spatstat` used
> `gpclib` with a non-commercial license to do polygonal operations. The
> solution was to list `gpclib` in `Suggests` and require the user to
> make an active choice to use this piece of software with a warning
> about non-commercial use. I find this to be an OK solution in lack of
> completely free alternatives. These days `gpclib` is still on CRAN and
> only has reverse `Suggests` and `Enhances`, so that seems fairly
> consistent.
> 
> In the long run this was unsatisfatory and our specific problem was
> solved by Adrian Baddeley by making the `polyclip` package.
> 
> Kind regards,
> Ege


Hi Ege,

The use of "Suggests" may be the relevant difference here. My use of the word 
"interact" was focused on the text in the CRAN policy that I quoted in my 
initial reply:

"Such packages are not permitted to require (e.g., by specifying in ‘Depends’, 
‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package or external 
software which restricts users or usage."

As Duncan noted in his reply, there may be time based differences that are 
relevant here, if the CRAN policy had changed at some point, and there was, in 
effect, a grand-fathering of older packages that perhaps would not be accepted 
today under the current policy.

Regards,

Marc

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[Rd] The presence/absence of `zone` in POSIXlt depending on time zone as a cause of possible inconsistences?

[IAGO GINÉ VÁZQUEZ]

Dear all,

I have just detected what seems a minor inconsistence with data types. If one 
unlists a POSIXlt time with GMT zone gets a numeric vector, since the POSIXlt 
list has no `zone` element, while if one unlists a POSIXlt time with a non GMT 
zone (also non specifying tz if the Sys.timezone is not GMT) gets a character 
vector due to including the `zone` element.

> x <- as.POSIXlt(Sys.time(), "GMT")
> (y <- unlist(x))
  sec   min  hour  mday   mon  year  wday  yday 
isdst
 54.99715  26.0  16.0  23.0   9.0 120.0   5.0 296.0 
  0.0
> str(y)
 Named num [1:9] 55 26 16 23 9 ...
 - attr(*, "names")= chr [1:9] "sec" "min" "hour" "mday" ...

> x <- as.POSIXlt(Sys.time(), "CET")
> (y <- unlist(x))
   secmin   hour   mday 
   mon   year   wday   yday
"19.5111262798309"   "27"   "18"   "23" 
   "9"  "120""5"  "296"
 isdst   zone gmtoff
   "1" "CEST" "7200"
> str(y)
 Named chr [1:11] "19.5111262798309" "27" "18" "23" "9" "120" "5" "296" "1" 
"CEST" "7200"
 - attr(*, "names")= chr [1:11] "sec" "min" "hour" "mday" ...

Is it expected? Why do not include always `zone` as an element of POSIXlt? 
Should POSIXlt objects be unlisted in a different way?
Thank you!
Best regards,

Iago

PS: I was using R 4.0.3. I don't know if this behaviour already changed in 
R-devel. Excuse me in that case.


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi Uwe,

Thanks for your reply.

I appreciate all of the efforts by the CRAN team here.

Regards,

Marc


> On Oct 23, 2020, at 8:47 AM, Uwe Ligges  
> wrote:
> 
> Windows binaries may be delayed these days, but they are generated in a bunch 
> R-flavour-wise. They typical delay after a source package publication should 
> be less then 72 hours ideally.
> 
> Best,
> Uwe
> 
> On 23.10.2020 14:05, Marc Schwartz wrote:
>> Hi All,
>> Just a quick note to indicate that one of the two Windows binaries for the 
>> package appeared overnight (EDT). Not sure if this experience is 
>> representative for others, or just a temporary bump in the road.
>> Regards,
>> Marc
>>> On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:
>>> 
>>> Hi All,
>>> 
>>> Just thought that I would check to see if there are any known issues/delays 
>>> for CRAN in creating R release and devel binaries for Windows for updated 
>>> packages.
>>> 
>>> It has been four days since I submitted an update and the other binaries 
>>> were created within a couple of days. The two Windows binaries are the only 
>>> outstanding updates pending.
>>> 
>>> Thanks!
>>> 
>>> Marc Schwartz
>> __
>> 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: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi All,

Just a quick note to indicate that one of the two Windows binaries for the 
package appeared overnight (EDT). Not sure if this experience is representative 
for others, or just a temporary bump in the road.

Regards,

Marc


> On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:
> 
> Hi All,
> 
> Just thought that I would check to see if there are any known issues/delays 
> for CRAN in creating R release and devel binaries for Windows for updated 
> packages.
> 
> It has been four days since I submitted an update and the other binaries were 
> created within a couple of days. The two Windows binaries are the only 
> outstanding updates pending.
> 
> Thanks!
> 
> Marc Schwartz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [EXTERNAL] Re: Pre-test failure

[Hong Ooi via R-package-devel]

My personal opinion is that as long as a package doesn't actually make it on to 
CRAN, you don't need to bump the version. It's worked so far

-Original Message-
From: R-package-devel  On Behalf Of Ben 
Bolker
Sent: Saturday, 24 October 2020 2:23 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] Pre-test failure

Can you share the links to the CRAN pre-test logs? Someone here 
might be able to guess what went wrong ...

(FWIW I always *think* I'm testing very carefully, and I almost 
always get something wrong ...)

On 10/23/20 11:18 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:
> I test my packages very carefully before submission.  Earlier today I 
> submitted a package that passed this morning on both winbuilder_release and 
> winbuilder_devel.  The pre-test submission failed on rebuilding the vignette. 
>  I just tried again on winbuilder_release and winbuilder_devel,  no problems. 
>  There are no problems either on my Mac or a Fedora image. Moreover I tested 
> the specific lines that were flagged,  and they work fine
> 
> So my questions are:
> 
> 1.  Should I just resubmit assuming it was some kind of quirk?
> 
> 2. Do I need to bump up the version to resubmit?
> 
> Thanks,
> 
> -Roy
> 
> 
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pfeg.noaa.gov%2Fdata=04%7C01%7Chongooi%40microsoft.com%7C05d6b3fb72074139cfd508d87767931b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637390634032310385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZhyBMECoZohEfOqkRqz%2BwV6PB560jUKurP3eXyyfugg%3Dreserved=0
> 
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
> 
> __
> R-package-devel@r-project.org mailing list
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=04%7C01%7Chongooi%40microsoft.com%7C05d6b3fb72074139cfd508d87767931b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637390634032310385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CXtC%2FqbZ0B3znnxcTHQb2voADGKPFIhl1jfTrzGl%2Ft0%3Dreserved=0
>

__
R-package-devel@r-project.org mailing list
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=04%7C01%7Chongooi%40microsoft.com%7C05d6b3fb72074139cfd508d87767931b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637390634032310385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CXtC%2FqbZ0B3znnxcTHQb2voADGKPFIhl1jfTrzGl%2Ft0%3Dreserved=0

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Pre-test failure

[Roy Mendelssohn - NOAA Federal via R-package-devel]

https://win-builder.r-project.org/incoming_pretest/plotdap_0.0.8_20201023_155845/Windows/00check.log

my problem is I don't have Windows myself.  So I assume if I can pass both 
winbuilders I should be good.  Here is the link to winbuilder_release I just 
ran:

https://win-builder.r-project.org/exQtKk9TKIeP

As you can see,  that is ok and rebuilt the vignette just fine.  

Thanks,

-Roy


> On Oct 23, 2020, at 8:22 AM, Ben Bolker  wrote:
> 
>   Can you share the links to the CRAN pre-test logs? Someone here might be 
> able to guess what went wrong ...
> 
>   (FWIW I always *think* I'm testing very carefully, and I almost always get 
> something wrong ...)
> 
> On 10/23/20 11:18 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
> wrote:
>> I test my packages very carefully before submission.  Earlier today I 
>> submitted a package that passed this morning on both winbuilder_release and 
>> winbuilder_devel.  The pre-test submission failed on rebuilding the 
>> vignette.  I just tried again on winbuilder_release and winbuilder_devel,  
>> no problems.  There are no problems either on my Mac or a Fedora image. 
>> Moreover I tested the specific lines that were flagged,  and they work fine
>> So my questions are:
>> 1.  Should I just resubmit assuming it was some kind of quirk?
>> 2. Do I need to bump up the version to resubmit?
>> Thanks,
>> -Roy
>> **
>> "The contents of this message do not reflect any position of the U.S. 
>> Government or NOAA."
>> **
>> Roy Mendelssohn
>> Supervisory Operations Research Analyst
>> NOAA/NMFS
>> Environmental Research Division
>> Southwest Fisheries Science Center
>> ***Note new street address***
>> 110 McAllister Way
>> Santa Cruz, CA 95060
>> Phone: (831)-420-3666
>> Fax: (831) 420-3980
>> e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
>> "Old age and treachery will overcome youth and skill."
>> "From those who have been given much, much will be expected"
>> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>> __
>> 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

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Pre-test failure

[Ben Bolker]

   Can you share the links to the CRAN pre-test logs? Someone here 
might be able to guess what went wrong ...


   (FWIW I always *think* I'm testing very carefully, and I almost 
always get something wrong ...)


On 10/23/20 11:18 AM, Roy Mendelssohn - NOAA Federal via R-package-devel 
wrote:

I test my packages very carefully before submission.  Earlier today I submitted 
a package that passed this morning on both winbuilder_release and 
winbuilder_devel.  The pre-test submission failed on rebuilding the vignette.  
I just tried again on winbuilder_release and winbuilder_devel,  no problems.  
There are no problems either on my Mac or a Fedora image. Moreover I tested the 
specific lines that were flagged,  and they work fine

So my questions are:

1.  Should I just resubmit assuming it was some kind of quirk?

2. Do I need to bump up the version to resubmit?

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. Government or 
NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
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

[R-pkg-devel] Pre-test failure

[Roy Mendelssohn - NOAA Federal via R-package-devel]

I test my packages very carefully before submission.  Earlier today I submitted 
a package that passed this morning on both winbuilder_release and 
winbuilder_devel.  The pre-test submission failed on rebuilding the vignette.  
I just tried again on winbuilder_release and winbuilder_devel,  no problems.  
There are no problems either on my Mac or a Fedora image. Moreover I tested the 
specific lines that were flagged,  and they work fine

So my questions are:

1.  Should I just resubmit assuming it was some kind of quirk?

2. Do I need to bump up the version to resubmit?

Thanks,

-Roy


**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

[Uwe Ligges]

I do not want to make many general comments about licenses in public, as 
this is a very difficult matter and I am not a lawyer.


But let me cite from the CRAN policies:

"Packages with licenses not listed at 
https://svn.r-project.org/R/trunk/share/licenses/license.db will 
generally not be accepted. "


Further, I see in the discussions that you talked about depending on a 
software with a non-FOSS license. The CRAN team's point of view, for 
short, is:
A package with a FOSS license cannot strictly depend on a 
package/software that is non-FOSS. Obviously, the FOSS package cannot be 
used under its own license conditions in that case.


Best,
Uwe Ligges




On 23.10.2020 14:25, Ege Rubak wrote:

Hi all,

My two cents are below Marc's summary here:

On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:

Right now, the interpretation, without further clarification from
CRAN, would be, it is ok for a package to be on CRAN with license
based usage restrictions included (e.g. for non-commercial use), but
a package on CRAN, irrespective of it's own license, cannot
"interact" with other packages that do have restrictions...which
seems inconsistent.


It depends a bit what is meant by "interact". Years ago `spatstat` used
`gpclib` with a non-commercial license to do polygonal operations. The
solution was to list `gpclib` in `Suggests` and require the user to
make an active choice to use this piece of software with a warning
about non-commercial use. I find this to be an OK solution in lack of
completely free alternatives. These days `gpclib` is still on CRAN and
only has reverse `Suggests` and `Enhances`, so that seems fairly
consistent.

In the long run this was unsatisfatory and our specific problem was
solved by Adrian Baddeley by making the `polyclip` package.

Kind regards,
Ege

__
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: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Uwe Ligges]

Windows binaries may be delayed these days, but they are generated in a 
bunch R-flavour-wise. They typical delay after a source package 
publication should be less then 72 hours ideally.


Best,
Uwe

On 23.10.2020 14:05, Marc Schwartz wrote:

Hi All,

Just a quick note to indicate that one of the two Windows binaries for the 
package appeared overnight (EDT). Not sure if this experience is representative 
for others, or just a temporary bump in the road.

Regards,

Marc



On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:

Hi All,

Just thought that I would check to see if there are any known issues/delays for 
CRAN in creating R release and devel binaries for Windows for updated packages.

It has been four days since I submitted an update and the other binaries were 
created within a couple of days. The two Windows binaries are the only 
outstanding updates pending.

Thanks!

Marc Schwartz


__
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

[Bioc-devel] Bioc 3.12 Feature Freeze and Deadline for passing R CMD build/check

[Kern, Lori]

Developers,

The release of Bioconductor 3.12 is less than one week out. Please respect the 
'feature freeze' of 3.12 where we ask that all commits are limited to bug fixes 
and documentation (no more API changes).  The deadline to pass R CMD build and 
check on the daily builders is today.  While you will be able to commit to the 
devel branch for release 3.12  up to the code freeze next Tuesday, commits by 
today ensure proper checking and propagation on the build system and accurate 
reflections of code changes on the build report and landing pages.

Thank you for your cooperation.



Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Licenses

[Ege Rubak]

Hi all,

My two cents are below Marc's summary here:

On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
> Right now, the interpretation, without further clarification from
> CRAN, would be, it is ok for a package to be on CRAN with license
> based usage restrictions included (e.g. for non-commercial use), but
> a package on CRAN, irrespective of it's own license, cannot
> "interact" with other packages that do have restrictions...which
> seems inconsistent.

It depends a bit what is meant by "interact". Years ago `spatstat` used
`gpclib` with a non-commercial license to do polygonal operations. The
solution was to list `gpclib` in `Suggests` and require the user to
make an active choice to use this piece of software with a warning
about non-commercial use. I find this to be an OK solution in lack of
completely free alternatives. These days `gpclib` is still on CRAN and
only has reverse `Suggests` and `Enhances`, so that seems fairly
consistent.

In the long run this was unsatisfatory and our specific problem was
solved by Adrian Baddeley by making the `polyclip` package.

Kind regards,
Ege

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Bioc-devel] Regarding installation of bioconductor version 2.13

[Vincent Carey]

You can install the package, using current R, from the source image at
https://bioconductor.org/packages/3.1/bioc/src/contrib/inSilicoDb_2.4.1.tar.gz

I did this

Then I tried to use it

> getPlatformList()

*Error: Webservice not accessible. Please check your internet connection.:
Error in function (type, msg, asError = TRUE) : Failed to connect to
insilicodb.com  port 443: Connection refused*


*Does the service still exist?  If not, the package will be of little use,
I suspect.*

On Fri, Oct 23, 2020 at 6:37 AM Anamika Thalor 
wrote:

> Dear Sir/Madam,
> I am a PhD student in ICGEB, New Delhi and I am working on GEO datasets and
> for that, I need inSilicoDb package of R. This inSilicoDb package needs
> Bioconductor version 2.13 but I tried every thing but still not able to
> install it on my mac. I installed  R of version 3.0.2 which is required for
> Bioconductor version 2.13 but still getting error. I am attaching my error
> file with the email. Kindly help me in this regard.
>
> --
> Anamika
> Pre-doctoral Fellow
> Translational Bioinformatics Group,
> International Centre for Genetic Engineering and Biotechnology,
> Aruna Asaf Ali Marg, New Delhi - 110067
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

-- 
The information in this e-mail is intended only for the ...{{dropped:18}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] timezone tests and R-devel

[Sebastian Meyer]

Yes, you are absolutely right and I'm pretty sure this will be fixed in
one way or another.

IMO, the failing test should simply use all.equal.POSIXt's new argument
check.tzone=FALSE.

Two simple alternatives modifying all.equal.POSIXt behaviour:

- make check.tzone=FALSE the default: this is inconsistent with other
arguments of all.equal methods, always defaulting to stricter checks

- let all.equal.POSIXt generally ignore the tzone difference if tzone is
unset for one of the objects (similar to check_tzones): I think this is
a bad idea because tzone affects how POSIXt objects are printed, and
under check.tzone=TRUE, two objects shouldn't be considered "nearly
equal" if they print differently.

Best regards,

Sebastian


Am 23.10.20 um 10:28 schrieb Kasper Daniel Hansen:
> So let me try to raise this issue once more, and perhaps be more clear
> about what I think the issue is..
> 
> In my opinion there is now a bug in 
>   make check
> in R-development (tested today with r79361). As I see it, I specify a
> reasonable TZ environment variable and this leads to make check emitting
> an error.
> 
> Best,
> Kasper
> 
> On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen
> mailto:kasperdanielhan...@gmail.com>> wrote:
> 
> Yes, the potential issue I see is that 
>   make check 
> fails when I explicitly set TZ. However, I set it to be the same as
> what the system reports when I login.
> 
> Details: The system (RHEL) I am working on has
> $ strings /etc/localtime | tail -n 1
> EST5EDT,M3.2.0,M11.1.0
> $ date +%Z
> EDT
> $ echo $TZ
> US/Eastern
> 
> 
> 
> On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  > wrote:
> 
> Thank you for the report. In R-devel, all.equal.POSIXt() by default
> reports inconsistent time zones. Previously,
> 
> > x <- Sys.time()
> > all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
> 
> would return TRUE. To ignore the time zone attributes in
> R-devel, the
> argument 'check.tzone = FALSE' needs to be used.
> 
> That said, I can reproduce the 'make check' failure in R-devel
> on Ubuntu
> Linux when TZ is set, even if it is set to the system time zone:
> 
> $ export TZ=Europe/Berlin
> $ make check
> [...]
> > running code in '../../tests/reg-tests-2.R' ... OK
> >   comparing 'reg-tests-2.Rout' to
> '../../tests/reg-tests-2.Rout.save' ...7335c7335
> > < [1] "'tzone' attributes are inconsistent ('' and
> 'Europe/Berlin')"
> > ---
> >> [1] TRUE
> 
> 
> Compare the following two sessions:
> 
> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
> Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] TRUE
> 
> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e
> 'Sys.timezone(); x <- Sys.time(); all.equal(x, as.POSIXlt(x))'
> [1] "Europe/Berlin"
> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
> 
> 
> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
> behaviour is not new. Even with old R 3.6.3, I see
> 
> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()),
> "tzone")'
> [1] ""     "CET"  "CEST"
> 
> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
> 'attr(as.POSIXlt(Sys.time()), "tzone")'
> [1] "Europe/Berlin" "CET"           "CEST"
> 
> This might be system-specific.
> 
> I suggest to modify the test as attached for make check to pass
> in this
> setting.
> 
> Best regards,
> 
>         Sebastian
> 
> 
> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
> > The return value of Sys.time() today with a timezone of
> US/Eastern is
> > unchanged between 4.0.3-patched and devel, but on devel the
> following test
> > fails
> >   all.equal(x, as.POSIXlt(x))
> > with
> >   x = Sys.time()
> >
> > This means that devel does not complete make tests (failure on
> > tests/reg-tests-2.R)
> >
> > It is entirely possible that it is an error on my end, I use
> >   export TZ="US/Eastern"
> > but I have been using this for a while, and R-4.0.3-patched
> built today
> > passes make tests.
> >
> > Details below, and I am happy to provide more information.
> >
> > Build platform: inside a conda environment on linux. I have
> been doing this
> > for a while, but it is certainly a non-standard setup. GCC 7.3
> >
> > Best,
> > Kasper
> >
> > On R version 4.0.3 beta (2020-10-01 r79286) I get
> >
> >> x = Sys.time()
> >> attributes(x)
> > $class
> > [1] "POSIXct" "POSIXt"
> 

Re: [Rd] timezone tests and R-devel

[Kasper Daniel Hansen]

So let me try to raise this issue once more, and perhaps be more clear
about what I think the issue is..

In my opinion there is now a bug in
  make check
in R-development (tested today with r79361). As I see it, I specify a
reasonable TZ environment variable and this leads to make check emitting an
error.

Best,
Kasper

On Fri, Oct 2, 2020 at 11:28 AM Kasper Daniel Hansen <
kasperdanielhan...@gmail.com> wrote:

> Yes, the potential issue I see is that
>   make check
> fails when I explicitly set TZ. However, I set it to be the same as what
> the system reports when I login.
>
> Details: The system (RHEL) I am working on has
> $ strings /etc/localtime | tail -n 1
> EST5EDT,M3.2.0,M11.1.0
> $ date +%Z
> EDT
> $ echo $TZ
> US/Eastern
>
>
>
> On Fri, Oct 2, 2020 at 9:48 AM Sebastian Meyer  wrote:
>
>> Thank you for the report. In R-devel, all.equal.POSIXt() by default
>> reports inconsistent time zones. Previously,
>>
>> > x <- Sys.time()
>> > all.equal(x, as.POSIXlt(x, tz = "EST5EDT"))
>>
>> would return TRUE. To ignore the time zone attributes in R-devel, the
>> argument 'check.tzone = FALSE' needs to be used.
>>
>> That said, I can reproduce the 'make check' failure in R-devel on Ubuntu
>> Linux when TZ is set, even if it is set to the system time zone:
>>
>> $ export TZ=Europe/Berlin
>> $ make check
>> [...]
>> > running code in '../../tests/reg-tests-2.R' ... OK
>> >   comparing 'reg-tests-2.Rout' to '../../tests/reg-tests-2.Rout.save'
>> ...7335c7335
>> > < [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>> > ---
>> >> [1] TRUE
>>
>>
>> Compare the following two sessions:
>>
>> > R-devel --vanilla --no-echo -e 'Sys.timezone(); x <- Sys.time();
>> all.equal(x, as.POSIXlt(x))'
>> [1] "Europe/Berlin"
>> [1] TRUE
>>
>> > TZ='Europe/Berlin' R-devel --vanilla --no-echo -e 'Sys.timezone(); x <-
>> Sys.time(); all.equal(x, as.POSIXlt(x))'
>> [1] "Europe/Berlin"
>> [1] "'tzone' attributes are inconsistent ('' and 'Europe/Berlin')"
>>
>>
>> So as.POSIXlt() sets a 'tzone' attribute if TZ is set, but this
>> behaviour is not new. Even with old R 3.6.3, I see
>>
>> > R-3.6.3 --vanilla --slave -e 'attr(as.POSIXlt(Sys.time()), "tzone")'
>> [1] "" "CET"  "CEST"
>>
>> > TZ='Europe/Berlin' R-3.6.3 --vanilla --slave -e
>> 'attr(as.POSIXlt(Sys.time()), "tzone")'
>> [1] "Europe/Berlin" "CET"   "CEST"
>>
>> This might be system-specific.
>>
>> I suggest to modify the test as attached for make check to pass in this
>> setting.
>>
>> Best regards,
>>
>> Sebastian
>>
>>
>> Am 01.10.20 um 20:31 schrieb Kasper Daniel Hansen:
>> > The return value of Sys.time() today with a timezone of US/Eastern is
>> > unchanged between 4.0.3-patched and devel, but on devel the following
>> test
>> > fails
>> >   all.equal(x, as.POSIXlt(x))
>> > with
>> >   x = Sys.time()
>> >
>> > This means that devel does not complete make tests (failure on
>> > tests/reg-tests-2.R)
>> >
>> > It is entirely possible that it is an error on my end, I use
>> >   export TZ="US/Eastern"
>> > but I have been using this for a while, and R-4.0.3-patched built today
>> > passes make tests.
>> >
>> > Details below, and I am happy to provide more information.
>> >
>> > Build platform: inside a conda environment on linux. I have been doing
>> this
>> > for a while, but it is certainly a non-standard setup. GCC 7.3
>> >
>> > Best,
>> > Kasper
>> >
>> > On R version 4.0.3 beta (2020-10-01 r79286) I get
>> >
>> >> x = Sys.time()
>> >> attributes(x)
>> > $class
>> > [1] "POSIXct" "POSIXt"
>> >
>> >> attributes(as.POSIXlt(x))
>> > $names
>> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>>  "yday"
>> >  [9] "isdst"  "zone"   "gmtoff"
>> >
>> > $class
>> > [1] "POSIXlt" "POSIXt"
>> >
>> > $tzone
>> > [1] "US/Eastern" "EST""EDT"
>> >
>> >> all.equal(x, as.POSIXlt(x))
>> > [1] TRUE
>> >
>> > On R Under development (unstable) (2020-10-01 r79286) I get
>> >> x = Sys.time()
>> >> all.equal(x,x)
>> > [1] TRUE
>> >> attributes(as.POSIXlt(x))
>> > $names
>> >  [1] "sec""min""hour"   "mday"   "mon""year"   "wday"
>>  "yday"
>> >  [9] "isdst"  "zone"   "gmtoff"
>> >
>> > $class
>> > [1] "POSIXlt" "POSIXt"
>> >
>> > $tzone
>> > [1] "US/Eastern" "EST""EDT"
>> >
>> >> all.equal(x, as.POSIXlt(x))
>> > [1] "'tzone' attributes are inconsistent ('' and 'US/Eastern')"
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > 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
>>
>
>
> --
> Best,
> Kasper
>


-- 
Best,
Kasper

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel