Re: [Bioc-devel] set.seed and BiocParallel

[Aaron Lun]

I think Kylie is saying that she wants to use the same seed for each 
feature across different runs, but the seed can be different across 
features - which would make more sense.


Multi-worker reproducibility is an issue that we discussed before (the 
link goes into the middle of the thread):


https://stat.ethz.ch/pipermail/bioc-devel/2019-January/014505.html

The key thing is that, in addition to reproducibility, there is the 
issue of correctness with guaranteed independent streams.


Some food for thought: in the vast majority of my parallelized 
applications, the heavy lifting (including the RNG'ing) is done in C++. 
If this is also the case for you, consider using the dqrng package to 
provide the C++ PRNG. I usually generate all my seeds in the serial part 
of the code, and then distribute seeds to the jobs where each job is set 
to a different "stream" value so that the sequence of random numbers is 
always different, regardless of the seed. As the serial seed generation 
is under the control of set.seed(), this provides correctness and 
reproducibility no matter how the jobs are distributed across workers.


-A

On 12/03/2019 17:42, Kasper Daniel Hansen wrote:

But why do you want the same seed for the different features? That is not
the right way to use stochastic methods.

Best,
Kasper

On Tue, Mar 12, 2019 at 5:20 PM Bemis, Kylie 
wrote:


Hi all,

I remember similar questions coming up before, but couldn’t track any down
that directly pertain to my situation.

Suppose I want to use bplapply() in a function to fit models to many
features, and I am applying over features. The models are stochastic, and I
want the results to be reproducible, and preferably use the same RNG seed
for each feature. So I could do:

fitModels <- function(object, seed=1, BPPARAM=bpparam()) {
bplapply(object, function(x) {
set.seed(seed)
fitModel(x)
}, BPPARAM=BPPARAM)
}

But the BioC guidelines say not to use set.seed() inside function code,
and I’ve seen other questions answered saying not to use “seed” as a
function parameter in this way.

Is it preferable to check and modify .Random.seed directly, or is there
some other standard way of doing this?

Thanks,
Kylie

~~~
Kylie Ariel Bemis
Khoury College of Computer Sciences
Northeastern University
kuwisdelu.github.io









 [[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



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

Re: [Bioc-devel] set.seed and BiocParallel

[Kasper Daniel Hansen]

But why do you want the same seed for the different features? That is not
the right way to use stochastic methods.

Best,
Kasper

On Tue, Mar 12, 2019 at 5:20 PM Bemis, Kylie 
wrote:

> Hi all,
>
> I remember similar questions coming up before, but couldn’t track any down
> that directly pertain to my situation.
>
> Suppose I want to use bplapply() in a function to fit models to many
> features, and I am applying over features. The models are stochastic, and I
> want the results to be reproducible, and preferably use the same RNG seed
> for each feature. So I could do:
>
> fitModels <- function(object, seed=1, BPPARAM=bpparam()) {
> bplapply(object, function(x) {
> set.seed(seed)
> fitModel(x)
> }, BPPARAM=BPPARAM)
> }
>
> But the BioC guidelines say not to use set.seed() inside function code,
> and I’ve seen other questions answered saying not to use “seed” as a
> function parameter in this way.
>
> Is it preferable to check and modify .Random.seed directly, or is there
> some other standard way of doing this?
>
> Thanks,
> Kylie
>
> ~~~
> Kylie Ariel Bemis
> Khoury College of Computer Sciences
> Northeastern University
> kuwisdelu.github.io
>
>
>
>
>
>
>
>
>
> [[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

Re: [R-pkg-devel] CRAN review

[Uwe Ligges]

My fault as I habe not spotted that. Can you pls resubmit as we do no 
longer have your original submission yet?


Best,
Uwe Ligges

On 13.03.2019 00:10, Τόλης Χαλκής wrote:
The name of the package is "volesti". Both checks returned two Notes and 
we "replied to all" to the e-mail

  in order to explain why we believe it were both false positives.

Best,
Chalkis Apostolos

On Wed, 13 Mar 2019 at 00:27, Uwe Ligges 
> wrote:


Not normal, if you tell us which package you are talking about, the
CRAN
team can check what happened in case you did not simply forget to
confirm your submission.

Best,
Uwe Ligges

On 12.03.2019 21:30, Henrik Bengtsson wrote:
 > You can also "follow" your package submission on the CRAN FTP server:
 >
 > ftp://cran.r-project.org/incoming/
 >
 > /Henrik
 >
 > On Tue, Mar 12, 2019 at 1:26 PM Duncan Murdoch
mailto:murdoch.dun...@gmail.com>> wrote:
 >>
 >> On 12/03/2019 2:57 p.m., Τόλης Χαλκής wrote:
 >>> Dear all,
 >>>
 >>> We have submitted a package to CRAN in 25th of February and we
have not got
 >>> a
 >>> positive or a negative answer for the submission since then. Is
this
 >>> normal? Is
 >>> there any way to get informed for the review process?
 >>
 >> Did you get the two messages after submission (one to confirm
that you
 >> are the maintainer, the second to let you know the review has
started)?
 >> They'll both have subject lines like
 >>
 >> CRAN submission 
 >>
 >>
 >> The first one will start out saying something like
 >>>
 >>> Dear Duncan Murdoch
 >>> Someone has submitted the package rgl to CRAN.
 >>> You are receiving this email to confirm the submission as the
maintainer of
 >>> this package.
 >>
 >> and then ask you to confirm submission.
 >>
 >> The second one will start like
 >>
 >>> [This was generated from CRAN.R-project.org/submit.html
]
 >>>
 >>> The following package was uploaded to CRAN:
 >>> ===
 >>>
 >>> Package Information:
 >>> Package: rgl
 >>
 >> A while later you should get a third message about the automatic
checks.
 >>
 >> Duncan Murdoch
 >>
 >> __
 >> 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



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

Re: [R-pkg-devel] CRAN review

[Τόλης Χαλκής]

The name of the package is "volesti". Both checks returned two Notes and we
"replied to all" to the e-mail
 in order to explain why we believe it were both false positives.

Best,
Chalkis Apostolos

On Wed, 13 Mar 2019 at 00:27, Uwe Ligges 
wrote:

> Not normal, if you tell us which package you are talking about, the CRAN
> team can check what happened in case you did not simply forget to
> confirm your submission.
>
> Best,
> Uwe Ligges
>
> On 12.03.2019 21:30, Henrik Bengtsson wrote:
> > You can also "follow" your package submission on the CRAN FTP server:
> >
> > ftp://cran.r-project.org/incoming/
> >
> > /Henrik
> >
> > On Tue, Mar 12, 2019 at 1:26 PM Duncan Murdoch 
> wrote:
> >>
> >> On 12/03/2019 2:57 p.m., Τόλης Χαλκής wrote:
> >>> Dear all,
> >>>
> >>> We have submitted a package to CRAN in 25th of February and we have
> not got
> >>> a
> >>> positive or a negative answer for the submission since then. Is this
> >>> normal? Is
> >>> there any way to get informed for the review process?
> >>
> >> Did you get the two messages after submission (one to confirm that you
> >> are the maintainer, the second to let you know the review has started)?
> >> They'll both have subject lines like
> >>
> >> CRAN submission 
> >>
> >>
> >> The first one will start out saying something like
> >>>
> >>> Dear Duncan Murdoch
> >>> Someone has submitted the package rgl to CRAN.
> >>> You are receiving this email to confirm the submission as the
> maintainer of
> >>> this package.
> >>
> >> and then ask you to confirm submission.
> >>
> >> The second one will start like
> >>
> >>> [This was generated from CRAN.R-project.org/submit.html]
> >>>
> >>> The following package was uploaded to CRAN:
> >>> ===
> >>>
> >>> Package Information:
> >>> Package: rgl
> >>
> >> A while later you should get a third message about the automatic checks.
> >>
> >> Duncan Murdoch
> >>
> >> __
> >> 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
>

[[alternative HTML version deleted]]

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

Re: [Rd] R cairo_pdf function does not respect plotting boundaries

[Paul Murrell]

Hi

I have committed this fix to r-devel (r76226).

Please let me know if this does not fix things for you.

Paul

On 5/03/19 8:22 PM, Lee Steven Kelvin wrote:

Hi Paul,

Great, thank you for looking in to this, and I'm glad that you're able 
to reproduce it at your end too.


 From your reply, I'm happy that it seems like the fix may be fairly 
trivial, but I understand the necessity for caution.


If there's anything else I can do to help, please do let me know.

Thank you again,
Best,
Lee


On Monday, 4 March 2019, Paul Murrell > wrote:


Hi

(cc'ed to r-devel where further discussion should probably take place)

Thanks Lee.  I see that problem.

There is a "+ 1" in the Cairo device code for setting the clipping
region

(https://github.com/wch/r-source/blob/ba600867f2a94e46cf9eb75dc8b37f12b08a4561/src/library/grDevices/src/cairo/cairoFns.c#L156

)


Remove the "+ 1" and the problem goes away (for your example at least).

The comment on the line above that code suggests that the "+ 1" was
modelled on the X11 device code, but X11 deals in integer pixels and
Cairo (at the API level) does not, so it would seem that the "+ 1"
is just unnecessary.

However, I have a slight nagging worry that we have been here
before, so I would like to do some more testing before committing
that change.

Paul

On 1/03/19 8:13 AM, Lee Steven Kelvin wrote:

Hello all,

When producing a plot in R using the cairo_pdf device, the
resultant plot does not respect the plotting boundaries. Lines
and shaded regions will spill over the lower x-axis and the
right-side y-axis (sides 1 and 4). I would like to know if it is
possible to fix this behaviour when using 'cairo_pdf' in R?

As an example, see the image at this web link:
https://i.stack.imgur.com/0lfZd.png


This image is a screenshot of a PDF file constructed using the
following minimum working example code:

cairo_pdf(file="test.pdf", width=0.5, height=0.5)
par("mar"=c(0.25,0.25,0.25,0.25))
plot(NA, xlim=c(0,1), ylim=c(0,1), axes=FALSE)
polygon(x=c(-1,-1,2,2), y=c(-1,2,2,-1), density=5, col="green3",
lwd=10)
abline(h=0.25, col="red", lwd=5)
abline(h=0.75, col="hotpink", lwd=5, lend=1)
abline(v=0.25, col="blue", lwd=5)
abline(v=0.75, col="cyan", lwd=5, lend=1)
box()
dev.off()

Here I'm plotting a shaded region in green using 'polygon', with
boundaries that lie outside the plot. I'm also drawing two sets
of horizontal/vertical lines using 'abline'. The first in each
pair uses standard rounded line caps, whilst the second in each
pair uses butt line caps.

As you can see, the shading lines and the default rounded-end
ablines all extend beyond the plotting region along the lower
and right-hand side axes. Only when using 'lend=1' am I able to
contain the ablines to the plotting region. I know of no such
fix for the shading lines however.

I would naively expect the R plotting region to be respected,
and for it to be impossible to plot outside of this region
unless explicitly specified by the user.

I have tested this on the other cairo devices (SVG and PS), and
also reproduce the same behaviour, indicating that this is an
issue with the cairo graphics API, or its implementation within R.

This behaviour does not occur when using the standard R 'pdf'
graphics device. I would switch to 'pdf' in general, however,
'cairo_pdf' has several advantages over 'pdf', notably, reduced
output file sizes on occasion and support for a larger array of
UTF-8 characters, so ideally I would prefer to use cairo_pdf.

I should note that I have also posted this message on
StackOverflow at this web link:

https://stackoverflow.com/questions/54892809/r-cairo-pdf-function-does-not-respect-plotting-boundaries



Thank you in advance for any insights into this issue.

Sincerely,
Lee Kelvin



--
Dr Lee Kelvin
Department of Physics
UC Davis
One Shields Avenue
Davis, CA 95616
USA

Ph: +1 (530) 752-1500
Fax: +1 (530) 752-4717


         [[alternative HTML version deleted]]

__
r-h...@r-project.org  mailing list
-- To UNSUBSCRIBE and more, see

Re: [R-pkg-devel] CRAN review

[Uwe Ligges]

Not normal, if you tell us which package you are talking about, the CRAN 
team can check what happened in case you did not simply forget to 
confirm your submission.


Best,
Uwe Ligges

On 12.03.2019 21:30, Henrik Bengtsson wrote:

You can also "follow" your package submission on the CRAN FTP server:

ftp://cran.r-project.org/incoming/

/Henrik

On Tue, Mar 12, 2019 at 1:26 PM Duncan Murdoch  wrote:


On 12/03/2019 2:57 p.m., Τόλης Χαλκής wrote:

Dear all,

We have submitted a package to CRAN in 25th of February and we have not got
a
positive or a negative answer for the submission since then. Is this
normal? Is
there any way to get informed for the review process?


Did you get the two messages after submission (one to confirm that you
are the maintainer, the second to let you know the review has started)?
They'll both have subject lines like

CRAN submission 


The first one will start out saying something like


Dear Duncan Murdoch
Someone has submitted the package rgl to CRAN.
You are receiving this email to confirm the submission as the maintainer of
this package.


and then ask you to confirm submission.

The second one will start like


[This was generated from CRAN.R-project.org/submit.html]

The following package was uploaded to CRAN:
===

Package Information:
Package: rgl


A while later you should get a third message about the automatic checks.

Duncan Murdoch

__
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

[Bioc-devel] set.seed and BiocParallel

[Bemis, Kylie]

Hi all,

I remember similar questions coming up before, but couldn’t track any down that 
directly pertain to my situation.

Suppose I want to use bplapply() in a function to fit models to many features, 
and I am applying over features. The models are stochastic, and I want the 
results to be reproducible, and preferably use the same RNG seed for each 
feature. So I could do:

fitModels <- function(object, seed=1, BPPARAM=bpparam()) {
bplapply(object, function(x) {
set.seed(seed)
fitModel(x)
}, BPPARAM=BPPARAM)
}

But the BioC guidelines say not to use set.seed() inside function code, and 
I’ve seen other questions answered saying not to use “seed” as a function 
parameter in this way.

Is it preferable to check and modify .Random.seed directly, or is there some 
other standard way of doing this?

Thanks,
Kylie

~~~
Kylie Ariel Bemis
Khoury College of Computer Sciences
Northeastern University
kuwisdelu.github.io









[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN review

[Henrik Bengtsson]

You can also "follow" your package submission on the CRAN FTP server:

   ftp://cran.r-project.org/incoming/

/Henrik

On Tue, Mar 12, 2019 at 1:26 PM Duncan Murdoch  wrote:
>
> On 12/03/2019 2:57 p.m., Τόλης Χαλκής wrote:
> > Dear all,
> >
> > We have submitted a package to CRAN in 25th of February and we have not got
> > a
> > positive or a negative answer for the submission since then. Is this
> > normal? Is
> > there any way to get informed for the review process?
>
> Did you get the two messages after submission (one to confirm that you
> are the maintainer, the second to let you know the review has started)?
> They'll both have subject lines like
>
> CRAN submission 
>
>
> The first one will start out saying something like
> >
> > Dear Duncan Murdoch
> > Someone has submitted the package rgl to CRAN.
> > You are receiving this email to confirm the submission as the maintainer of
> > this package.
>
> and then ask you to confirm submission.
>
> The second one will start like
>
> > [This was generated from CRAN.R-project.org/submit.html]
> >
> > The following package was uploaded to CRAN:
> > ===
> >
> > Package Information:
> > Package: rgl
>
> A while later you should get a third message about the automatic checks.
>
> Duncan Murdoch
>
> __
> 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] CRAN review

[Duncan Murdoch]

On 12/03/2019 2:57 p.m., Τόλης Χαλκής wrote:

Dear all,

We have submitted a package to CRAN in 25th of February and we have not got
a
positive or a negative answer for the submission since then. Is this
normal? Is
there any way to get informed for the review process?


Did you get the two messages after submission (one to confirm that you 
are the maintainer, the second to let you know the review has started)? 
They'll both have subject lines like


CRAN submission 


The first one will start out saying something like


Dear Duncan Murdoch
Someone has submitted the package rgl to CRAN.
You are receiving this email to confirm the submission as the maintainer of
this package.


and then ask you to confirm submission.

The second one will start like


[This was generated from CRAN.R-project.org/submit.html]

The following package was uploaded to CRAN:
===

Package Information:
Package: rgl 


A while later you should get a third message about the automatic checks.

Duncan Murdoch

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

Re: [R-pkg-devel] CRAN review

[Ben Bolker]

  Sounds like it fell through the cracks somewhere.

  The foghorn package   is a
convenient way to check on CRAN status.

On 2019-03-12 2:57 p.m., Τόλης Χαλκής wrote:
> Dear all,
> 
> We have submitted a package to CRAN in 25th of February and we have not got
> a
> positive or a negative answer for the submission since then. Is this
> normal? Is
> there any way to get informed for the review process?
> 
> Best regards,
> -Chalkis Apostolos
> 
>   [[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

[R-pkg-devel] CRAN review

[Τόλης Χαλκής]

Dear all,

We have submitted a package to CRAN in 25th of February and we have not got
a
positive or a negative answer for the submission since then. Is this
normal? Is
there any way to get informed for the review process?

Best regards,
-Chalkis Apostolos

[[alternative HTML version deleted]]

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

Re: [Rd] Spurious warning from checkReplaceFuns about a non-replacement function

[Kurt Hornik]

> Hugh Parsonage writes:

> If a function contains the pattern `<-` it is (with a few exceptions)
> deemed to be a replacement function and in particular must have second
> argument `value` to pass R CMD check.

> Consider the function %<->% or any other function containing <- within
> grapes. I claim that such functions should not be considered
> replacement functions and thus the R CMD check should not require its
> second argument to be `value`.

I just committed c76224 which drops %xxx% binops from the list of
(probable) replacement functions.

Thanks for spotting this!

Best
-k

> Recommend in the function tools::checkReplaceFuns

> grep("<-", objects_in_code,
> value = TRUE)

> be changed to

> grep("<-$", objects_in_code,
> value = TRUE)


> Hugh.

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

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

Re: [Bioc-devel] Package missing in BiocCredentials app

[Turaga, Nitesh]

Hi Markus,

How about now, I just gave you permissions. You should be able to see it in the 
app, and get access to it.

Best,

Nitesh 

> On Mar 11, 2019, at 6:38 PM, Markus Riester  wrote:
> 
> Hi,
> 
> an old data package of mine (curatedBladderData) is not showing up in my 
> BiocCredentials account (markus.ries...@novartis.com). Is it possible to link 
> this package to my account?
> 
> Thank you,
> Markus
> ___
> 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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Ellipsis and dot-dot-number [Re: Dots are not fixed by make.names()]

[Martin Maechler]

> Kirill Müller 
> on Fri, 8 Mar 2019 22:26:17 +0100 writes:
> Kirill Müller 
> on Fri, 8 Mar 2019 22:26:17 +0100 writes:

> Hi


> In addition to the inconsistency in make.names(), the text in ?Reserved 
> seems incomplete:

>  "Reserved words outside quotes are always parsed to be references to the 
>   objects linked to in the ‘Description’, and hence they are not allowed 
>   as syntactic names (see make.names). They **are** allowed as 
>   non-syntactic names, e.g. inside backtick quotes."

> `..1` and `...` are allowed for assigning, but these symbols cannot be 
> used in the context of a variable. Example:

> `..1` <- 1
> `..13` <- 13
> `...` <- "dots"
> `..1`
> #> Error: ..1 used in an incorrect context, no ... to look in
> `..13`
> #> Error: ..13 used in an incorrect context, no ... to look in
> `...`
> #> Error in eval(expr, envir, enclos): '...' used in an incorrect context

> Does the ?Reserved help page need to mention this oddity, or link to 
> more detailed documentation?

> Best regards
> Kirill

I see

> `..9` <- 999
> get("..9")
[1] 999
> `..9`
Error: ..9 used in an incorrect context, no ... to look in

> `...` <- "3 dots"
> `...`
Error: '...' used in an incorrect context
> get("...")
[1] "3 dots"
> 

> assign("...", "3 DOTS")
> assign("..1", "1st dot arg")


So get() works for these, but `...` does not for getting but for
assignment.
OTOH,  assign() works for all, reserved words or not, so that
should not count.

Honestly, I'm not sure if the current behavior is necessary in
some sense or just a coincidence.

I do see that the C-internal isValidName()  [defined in the
grammar: gram.y (=> gram.c)] does say that "..." and "..1" etc
are valid names and that's what the C code of make.names() uses.

Also, as you know they *are* valid names as one does and should use them
unquoted although only to "get" and only inside functions.

So, no conclusion from here for now for the latter part.

For the first, about your make.names()  "inconsistency", I'd say
it *is* consistent because e.g.  ...  can be used without quotes
and hence is a valid name (mostly ;-).

OTOH,  make.names() being used to construct "valid" data frame
column names, maybe make.names() could be changed, probably via
a new optional logical argument say 'dotsValid = TRUE' which
when set to FALSE would also treat '...' and '..1' etc.

Unfortunately the code changes needed may be a bit ugly
as the consistency between  make.names() and {C level}  isValidName()
would be broken for  'dotsValid = FALSE'.

Martin



> On 05.10.18 11:27, Kirill Müller wrote:
>> Hi
>> 
>> 
>> It seems that names of the form "..#" and "..." are not fixed by 
>> make.names(), even though they are reserved words. The documentation 
>> reads:
>> 
>> > [...] Names such as ".2way" are not valid, and neither are the 
>> reserved words.
>> 
>> > Reserved words in R: [...] ... and ..1, ..2 etc, which are used to 
>> refer to arguments passed down from a calling function, see ?... .
>> 
>> I have pasted a reproducible example below.
>> 
>> I'd like to suggest to convert these to "...#" and "", 
>> respectively. Happy to contribute PR.
>> 
>> 
>> Best regards
>> 
>> Kirill
>> 
>> 
>> make.names(c("..1", "..13", "..."))
>> #> [1] "..1"  "..13" "..."
>> `..1` <- 1
>> `..13` <- 13
>> `...` <- "dots"
>> 
>> mget(c("..1", "..13", "..."))
>> #> $..1
>> #> [1] 1
>> #>
>> #> $..13
>> #> [1] 13
>> #>
>> #> $...
>> #> [1] "dots"
>> `..1`
>> #> Error in eval(expr, envir, enclos): the ... list does not contain 
>> any elements
>> `..13`
>> #> Error in eval(expr, envir, enclos): the ... list does not contain 
>> 13 elements
>> `...`
>> #> Error in eval(expr, envir, enclos): '...' used in an incorrect context
>> 
>> __
>> 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

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

[Bioc-devel] Package missing in BiocCredentials app

[Markus Riester]

Hi,

an old data package of mine (curatedBladderData) is not showing up in my 
BiocCredentials account (markus.ries...@novartis.com). Is it possible to link 
this package to my account?

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