[Bioc-devel] About Adding SSH Keys to GitHub Account

[露崎 弘毅]

Hi, All


I'm trying to submit my R/Bioconductor package by Bioconductor/Contributions

https://github.com/Bioconductor/Contributions/issues/787


The process looks properly going well,

but "1. awaiting moderation" label is added,

because the message says

"Add SSH keys to your GitHub account."



Actually, I still added some SSH keys to GitHub.


Is this caused by my some mistake,

or is this caused by the difference between organization account "rikenbit" and 
my account "kokitsuyuzaki"?


Or do I have to wait for the process for some hours?



Koki Tsuyuzaki


[[alternative HTML version deleted]]

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

Re: [Rd] new behavior in model.response

[Berry, Charles]

> On Jun 27, 2018, at 3:58 PM, Achim Zeileis  wrote:
> 
> On Thu, 28 Jun 2018, Therneau, Terry M., Ph.D. via R-devel wrote:
> 
>> I now understand the issue, which leads to a different and deeper issue 
>> which is "how to assign a proper length to Surv objects".
>> 
>> > Surv(c(1,2,3), c(1,0,1))
>> [1] 1  2+ 3
>> 
>> The above prints as 3 elements and is conceptually 3 elements. But if I give 
>> it length method to return a 3 then I need a names method, and names<-  pays 
>> no attention to my defined length. How do we conceive of and manage a vector 
>> whose elements happen to require more than one storage slot for their 
>> representation?  An obvious example is the complex type, but it seems that 
>> had to be baked right down into the core.
> 
> I think you just have to implement all methods required to make it look like 
> a vector even if it is internally a matrix. Thus, you need methods for length 
> and for names and names<-. Internally, the names can be stored as row names.


I think a closer look at model.response() would help. 

IIUC, the reasoning therein is that comparing 

length(data[[1L]]) (aka `length(v)') 

to 

length(attr(data, "row.names")) (aka `nrows') 

is to decide whether names are sensibly assigned to `v'. I think for Surv 
objects they are not.

I suppose you could define

`names<-.Surv` <- function(...) NULL

but that seems so silly I think there must be a better way. 

I am low on coffee right now, but I wonder if having a non-exported version of 
model.response in the survival package would solve this without breaking 
anything else. 

Chuck

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

Re: [Rd] new behavior in model.response

[Achim Zeileis]

On Thu, 28 Jun 2018, Therneau, Terry M., Ph.D. via R-devel wrote:

I now understand the issue, which leads to a different and deeper issue 
which is "how to assign a proper length to Surv objects".


> Surv(c(1,2,3), c(1,0,1))
[1] 1  2+ 3

The above prints as 3 elements and is conceptually 3 elements. But if I 
give it length method to return a 3 then I need a names method, and 
names<-  pays no attention to my defined length. How do we conceive of 
and manage a vector whose elements happen to require more than one 
storage slot for their representation?  An obvious example is the 
complex type, but it seems that had to be baked right down into the 
core.


I think you just have to implement all methods required to make it look 
like a vector even if it is internally a matrix. Thus, you need methods 
for length and for names and names<-. Internally, the names can be stored 
as row names.


Further useful methods for "Surv" objects might include 
- as.double/as.integer (presumably just extracting the "time"),

- c
- str

Possibly also a dedicated summary.

An example for such a class is our "paircomp" in "psychotools". But I'm 
sure there are other/better examples elsewhere.


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

Re: [Rd] new behavior in model.response

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

I now understand the issue, which leads to a different and deeper issue which 
is "how to 
assign a proper length to Surv objects".

 > Surv(c(1,2,3), c(1,0,1))
[1] 1  2+ 3

The above prints as 3 elements and is conceptually 3 elements. But if I give it 
length 
method to return a 3 then I need a names method, and names<-  pays no attention 
to my 
defined length. How do we conceive of and manage a vector whose elements happen 
to require 
more than one storage slot for their representation?  An obvious example is the 
complex 
type, but it seems that had to be baked right down into the core.



[[alternative HTML version deleted]]

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

Re: [Rd] new behavior of model.response

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

Charles Berry pointed out an error in my reasoning.   In the current survival I 
forgot the 
S3method line for length in the NAMESPACE file, so the behavior is really not 
new.  
Nonetheless it remains surprising and non-intuitive.  Why does model.response 
sometimes 
attach spurious names, when the Surv object itself does not have them?

Terry


tmt% R --vanilla
R version 3.4.2 (2017-09-28) -- "Short Summer"

test <- data.frame(time=1:8, status=rep(0:1, 4), age=60:67)
row.names(test) <- letters[1:8]

library(survival)

mf2 <- model.frame(Surv(time, status) ~ age, data=test)
names(mf2[[1]])
# NULL
names(model.response(mf2))
# NULL

length.Surv <- survival:::length.Surv

names(model.response(mf2))
  # [1] "a" "b" "c" "d" "e" "f" "g" "h" NA  NA  NA  NA  NA  NA  NA NA


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Questions about making a database package (Rpolyhedra)

[alejandro baranek]

By now, we are on that situation: +- 150 polyhedra published.
But +800 able to publish and because of package size cannot publish all of
them.

It is not a problem on github, it's a problem on CRAN, with building (fixed
testing timing with simple sample techniques) timing. I would like to hear
more from experienced package developers about this issues, but we seemed
to found a solution.

We decided to make another github repo RpolyhedraDB. When you install the
package, it downloads the database from the correct tag marked in the data
folder of the package in a home directory of the user. So package will be
minimal for CRAN, will be RR and will install database on first use (In
case of TRAVIS or other qa/continuous integration, it will install it of
course). It will be possible to setup different DB size using the TAGS, in
case we find it preferable to the users.


Best, Ale.


2018-03-29 4:43 GMT-03:00 Berry Boessenkool :

>
> I assume you cannot simply reduce the 150 to a few for demonstration
> purposes?
>
>
> I have seen people using DRAT packages on github for data, but gh is
> limited in size restrictions as well...
>
>
> No expert in this, but maybe this helps a little bit...
>
> Berry
>
>
>
> -
>
>
>
>
>
> --
> *From:* R-package-devel  on behalf
> of alejandro baranek 
> *Sent:* Tuesday, March 27, 2018 19:26
> *To:* r-package-devel@r-project.org
> *Subject:* [R-pkg-devel] Questions about making a database package
> (Rpolyhedra)
>
> Hello group:
>
> We released Rpolyhedra V0.2 last month. It is able to scrape +800 polyhedra
> definitions from public sources. At V0.2.4 we are publishing only 150
> because the time needed for scrape all the polyhedra, testing and the
> resulting size of the package. The difference is a configuration in zzz.R,
> very simple to change (Who wants to try it, can build the package for
> themeselves)
> Only the source files of polyhedra definitions are +12MB of size (We are
> including it in the data folder for package self suficience).
>
> But we have doubts about good practices for publishing a database package.
>
> We think the solution is to split the package in an internal
> Rpolyhedra-lib, opensource but not in CRAN, and Rpolyhedra with a catalog
> sewhich enables to connect with that repo for downloading scraped polyhedra
> on-demand.
>
> We have to think further the way of connecting both repositories, but
> before touching any code, want to listen to experienced package developers
> and the community in general, about to do this.
> Do you know any package with analog behavior than this package? We didn't
> find it.
>
> Best, Ale.
> --
>  alejandro baranek
> @ken4rab 
> qbotics  | surferinvaders
>  | algebraic-soundscapes
>  | surfer-shuffle
> 
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>



-- 
 alejandro baranek
@ken4rab 
qbotics  | surferinvaders
 | algebraic-soundscapes
 | surfer-shuffle


[[alternative HTML version deleted]]

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

[Rd] new behavior of model.response

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

I am getting some unexplained changes in the latest version of survival, and 
finally 
traced it down to this: model.response acts differently for Surv objects.
Here is a closed form example using a made up class Durv = diagnose survival.   
I tracked 
it down by removing methods one by one from Surv; I had just added some new 
ones so they 
were my suspects.

test <- data.frame(time=1:8, status=rep(0:1, 4), age=60:67)
row.names(test) <- letters[1:8]

Durv <- function(...) {
     temp <- cbind(...)
     class(temp) <- "Durv"
     temp
}
mf1 <- model.frame(Durv(time, status) ~ age, data=test)
names(model.response(mf1))
#  NULL

length.Durv <- function(x) nrow(x)
names(model.response(mf1))
#  [1] "a" "b" "c" "d" "e" "f" "g" "h" NA  NA  NA  NA  NA  NA NA  NA

The length method for Surv objects has been around for some while, this 
behavior is new.  
It caused the 'time' component of survfit objects to suddenly have names and so 
was 
discovered in my test suite.  I had planned to submit an update today, but now 
need to 
delay it.

The length of the Surv (Durv) object above is 8, BTW; the fact that it's 
representation 
requires either 16 elements (right censored) or 24 (interval censored) is a 
footnote.

Terry Therneau

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.

[Joris Meys]

Correction: In the case of mgcv it was the publication date that changed
for some reason. Our sysadmins keep reaching out to me in the hope to
resolve this. Is there a way they can reach out so this can be clarified?

For reference, the latest issue on mgcv :
https://github.com/easybuilders/easybuild-easyconfigs/issues/6501

Cheers
Joris

On Wed, Jun 27, 2018 at 3:30 PM, Joris Meys  wrote:

> Dear Uwe,
>
> sorry to bother you again with it, but I was wondering if you had some
> more idea about what happened. I just received another one, this time about
> mgcv_1.8-23.tar.gz. It goes beyond my understanding as to why the MD5 sums
> would change without any change to the package. Is there anything I can
> check at this side to make it easier for you?
>
> Cheers
> Joris
>
> On Thu, Jun 14, 2018 at 6:55 PM, Joris Meys  wrote:
>
>> Dear Uwe,
>>
>> Thank you for willing to take a look. In the report it was about the
>> following tarballs :
>>
>> pkgmaker_0.22.tar.gz
>> rngtools_1.2.4.tar.gz
>> RcppProgress_0.4.tar.gz
>>
>> Our sysadmin tried diff -ru, but couldn't find any difference in the text
>> files.
>>
>> Cheers
>> Joris
>>
>> On Thu, Jun 14, 2018 at 5:46 PM, Uwe Ligges <
>> lig...@statistik.tu-dortmund.de> wrote:
>>
>>>
>>>
>>> On 13.06.2018 15:40, Joris Meys wrote:
>>>


 On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges <
 lig...@statistik.tu-dortmund.de >
 wrote:


 When CRAN repacks and changes the DESCRIPTION file, the checksums
 change, of course.

 Best,
 Uwe Ligges


 Dear Uwe,

 I understood that from the previous issue. In this case however, none
 of the files -including the DESCRIPTION file- were changed. Am I right in
 suspecting that a package is repacked when moved to the archive?

>>>
>>> No, we do not repack generally then. Perhaps the package got orphaned?
>>>
>>>
>>> Which package / tarball were you talking about? I can take a look why
>>> that one was changed and inspect why the checksum changed.
>>>
>>> Best,
>>> Uwe Ligges
>>>
>>>
>>>
>>>  I
>>>
 suspect that the tool used to repack the package is using gzip, and it
 is possible to repack without adding a timestamp as explained here :

 https://serverfault.com/questions/110208/different-md5sums-f
 or-same-tar-contents

 I can explain the different checksums when some things are changed to
 our HPC sysadmins, but they have -understandibly- difficulties with
 checksums changing for released source tarballs. Is it possible to adapt
 the archiving so that at least for identical tarballs the md5 sums remain
 the same? Or if you have other suggestions to deal with this without having
 to change hardcoded checksums in the easybuild repos, that would be very
 welcome too.

 Cheers
 Joris

 --
 Joris Meys
 Statistical consultant

 Department of Data Analysis and Mathematical Modelling
 Ghent University
 Coupure Links 653, B-9000 Gent (Belgium)
 

 tel: +32 (0)9 264 61 79
 ---
 Biowiskundedagen 2017-2018
 http://www.biowiskundedagen.ugent.be/

 ---
 Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

>>>
>>
>>
>> --
>> Joris Meys
>> Statistical consultant
>>
>> Department of Data Analysis and Mathematical Modelling
>> Ghent University
>> Coupure Links 653, B-9000 Gent (Belgium)
>>
>> 
>>
>> tel: +32 (0)9 264 61 79
>> ---
>> Biowiskundedagen 2017-2018
>> http://www.biowiskundedagen.ugent.be/
>>
>> ---
>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>
>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> 
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>



-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list

Re: [R-pkg-devel] Checksums changed on CRAN without any visible modifications to files.

[Joris Meys]

Dear Uwe,

sorry to bother you again with it, but I was wondering if you had some more
idea about what happened. I just received another one, this time about
mgcv_1.8-23.tar.gz. It goes beyond my understanding as to why the MD5 sums
would change without any change to the package. Is there anything I can
check at this side to make it easier for you?

Cheers
Joris

On Thu, Jun 14, 2018 at 6:55 PM, Joris Meys  wrote:

> Dear Uwe,
>
> Thank you for willing to take a look. In the report it was about the
> following tarballs :
>
> pkgmaker_0.22.tar.gz
> rngtools_1.2.4.tar.gz
> RcppProgress_0.4.tar.gz
>
> Our sysadmin tried diff -ru, but couldn't find any difference in the text
> files.
>
> Cheers
> Joris
>
> On Thu, Jun 14, 2018 at 5:46 PM, Uwe Ligges  de> wrote:
>
>>
>>
>> On 13.06.2018 15:40, Joris Meys wrote:
>>
>>>
>>>
>>> On Wed, Jun 13, 2018 at 3:16 PM, Uwe Ligges <
>>> lig...@statistik.tu-dortmund.de >
>>> wrote:
>>>
>>>
>>> When CRAN repacks and changes the DESCRIPTION file, the checksums
>>> change, of course.
>>>
>>> Best,
>>> Uwe Ligges
>>>
>>>
>>> Dear Uwe,
>>>
>>> I understood that from the previous issue. In this case however, none of
>>> the files -including the DESCRIPTION file- were changed. Am I right in
>>> suspecting that a package is repacked when moved to the archive?
>>>
>>
>> No, we do not repack generally then. Perhaps the package got orphaned?
>>
>>
>> Which package / tarball were you talking about? I can take a look why
>> that one was changed and inspect why the checksum changed.
>>
>> Best,
>> Uwe Ligges
>>
>>
>>
>>  I
>>
>>> suspect that the tool used to repack the package is using gzip, and it
>>> is possible to repack without adding a timestamp as explained here :
>>>
>>> https://serverfault.com/questions/110208/different-md5sums-f
>>> or-same-tar-contents
>>>
>>> I can explain the different checksums when some things are changed to
>>> our HPC sysadmins, but they have -understandibly- difficulties with
>>> checksums changing for released source tarballs. Is it possible to adapt
>>> the archiving so that at least for identical tarballs the md5 sums remain
>>> the same? Or if you have other suggestions to deal with this without having
>>> to change hardcoded checksums in the easybuild repos, that would be very
>>> welcome too.
>>>
>>> Cheers
>>> Joris
>>>
>>> --
>>> Joris Meys
>>> Statistical consultant
>>>
>>> Department of Data Analysis and Mathematical Modelling
>>> Ghent University
>>> Coupure Links 653, B-9000 Gent (Belgium)
>>> >> ent,%C2%A0Belgium=gmail=g>
>>>
>>> tel: +32 (0)9 264 61 79
>>> ---
>>> Biowiskundedagen 2017-2018
>>> http://www.biowiskundedagen.ugent.be/
>>>
>>> ---
>>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>>>
>>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> 
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>



-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] updating maintainer

[Obenchain, Valerie]

Hi Sam,

As Kasper mentioned, you should update the maintainer field in the DESCRIPTION 
file of your packages. We'll also need this information:

- What packages to you currently maintain
- What is your PI's github account and email
- List of Bioconductor packages you PI currently maintains, if any any

It's a good idea for the email in the DESCRIPTION file to match the email used 
to make the account in the GitApp:

  https://git.bioconductor.org/BiocCredentials

This is not strictly enforced but it make communication easier.

Thanks.
Valerie





On 06/27/2018 12:45 AM, Kasper Daniel Hansen wrote:

You update the maintainer field in devel.  I don't know what to do about
release.

I don't understand the question about github.  There is no "github email",
there is a github username. And that username does not have to be the same
as a maintainer email, because they really have nothing to do with each
other. In the DESCRIPTION field the github address is given as a URL not as
an email, like
  URL: https://github.com/hansenlab/minfi
  BugReports: https://github.com/hansenlab/minfi/issues



On Tue, Jun 26, 2018 at 4:18 PM, Samuel E Zimmerman <
sezim...@einstein.yu.edu> wrote:



Dear bioc-devs,

I will no longer be working at my current university in about a week, and
the email address associated with the bioconductor packages I maintain will
be removed. How should I go about updating my email address to keep
maintaining the packages?

Also, my PI would like to have the github account, where the repos for the
bioconductor packages live, be under her email address instead of mine.
Would it be a problem if the maintainer's email address and the github
email address are different?

Thank you very much.

Best,
Sam

[[alternative HTML version deleted]]

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




[[alternative HTML version deleted]]

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





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: [Bioc-devel] updating maintainer

[Kasper Daniel Hansen]

You update the maintainer field in devel.  I don't know what to do about
release.

I don't understand the question about github.  There is no "github email",
there is a github username. And that username does not have to be the same
as a maintainer email, because they really have nothing to do with each
other. In the DESCRIPTION field the github address is given as a URL not as
an email, like
  URL: https://github.com/hansenlab/minfi
  BugReports: https://github.com/hansenlab/minfi/issues



On Tue, Jun 26, 2018 at 4:18 PM, Samuel E Zimmerman <
sezim...@einstein.yu.edu> wrote:

> Dear bioc-devs,
>
> I will no longer be working at my current university in about a week, and
> the email address associated with the bioconductor packages I maintain will
> be removed. How should I go about updating my email address to keep
> maintaining the packages?
>
> Also, my PI would like to have the github account, where the repos for the
> bioconductor packages live, be under her email address instead of mine.
> Would it be a problem if the maintainer's email address and the github
> email address are different?
>
> Thank you very much.
>
> Best,
> Sam
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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