[Bioc-devel] Additional developer

[Thomas Girke]

Dear Nitesh,

Could you please add a new developer to my BioC packages systemPipeR and
systemPipeRdata to provide commit/push access for the corresponding git
repositories on git.bioconductor.org. The person's name is Daniela Cassol
(new postdoc in my group) and her email is danicas...@gmail.com.

Please let me know if you require anything else for this change.

Thanks in advance for your help!

Best,

Thomas

[[alternative HTML version deleted]]

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

[Bioc-devel] Aliasing `]` breaks BiocCheck::BiocCheck() version 1.18.0

[Shian Su]

Hi all,

If you put

foo <- `[`

Somewhere in a package, it will trigger

Error in makeUsageCollector(fun, ...) : only works for closures

In BiocCheck::BiocCheck() (version 1.18.0). This comes from

if (typeof(fun) != "closure")
stop("only works for closures")

In codetools::makeUsageCollector(), but

> typeof(`[`)
## "special"

Not that it matters for my use-case because I had discovered magrittr’s extract 
alias, but it might be an edge case worth covering, especially since the error 
message is so cryptic.

Kind regards,
Shian Su

___

The information in this email is confidential and intended solely for the 
addressee.
You must not disclose, forward, print or use it without the permission of the 
sender.

The Walter and Eliza Hall Institute acknowledges the Wurundjeri people of the 
Kulin
Nation as the traditional owners of the land where our campuses are located and
the continuing connection to country and community.
___

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Compilation flags, CHECK errors and BiocNeighbors

[Shian Su]

From what I can see in scPipe, it looks to me like there’s difference in flags 
for tokay1 and tokay2 (release and development).

http://bioconductor.org/checkResults/release/bioc-LATEST/scPipe/tokay1-buildbin.html
-O2 -Wall -mtune=generic

http://bioconductor.org/checkResults/devel/bioc-LATEST/scPipe/tokay2-buildbin.html
-O3 -march=native -mtune=native

On 18 Dec 2018, at 12:05 pm, Aaron Lun 
mailto:infinite.monkeys.with.keyboa...@gmail.com>>
 wrote:

Thanks Val. I don�t think it�s a BiocNeighbors thing, as it doesn�t try to 
customize the compilation flags or have its own Makevars. Moreover, the �-O3 
-mtune=native -mtune=generic� flags seem to show up on all of my packages 
containing C++11 code. Some cursory checks of other packages suggest that the 
correct flags (�-O2 -mtune=generic�) are used for C++98 code.

-A

> On 17 Dec 2018, at 17:47, Obenchain, Valerie 
> mailto:valerie.obench...@roswellpark.org>> 
> wrote:
>
> Hi Aaron,
>
> The only compilation flags that are different for tokay1 (release) and
> tokay2 (devel) are C++14 flags. BiocNeighbors is not using C++14 but
> C++11 so I think the changes we discussed previously actually don't
> apply to your case.
>
> All compilation flags we use are listed at the top of the build report,
> e.g., for tokay2:
>
> https://www.bioconductor.org/checkResults/devel/bioc-LATEST/tokay2-NodeInfo.html
>  
> 
>
> I can look into this further but right now I'm not sure where the '-O3
> -march=native -mtune=native' is coming from in the check output for
> BiocNeighbors. We don't use 'native' on the builders for build/check or
> for creating binaries.
>
> Herve might have more insight on this.
>
> Val
>
>
>
>
>
>
>
> On 12/15/18 10:56 PM, Aaron Lun wrote:
>> Sometime between 6-18 November, BiocNeighbors� BioC-devel builds began 
>> failing on Windows 64-bit, and have continued to fail since:
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/BiocNeighbors/ 
>>  
>> > >
>>
>> The most interesting part is the nature of the failures. They are not 
>> segmentation faults but rather �incorrect� output in the unit tests:
>>
>> - BiocNeighbors uses the Annoy algorithm for approximate nearest neighbor 
>> search, which is provided as a header-only C++ library in the RcppAnnoy 
>> package.
>>
>> - I have compiled the BiocNeighhbors C++ code with an �#include" for these 
>> libraries to use the Annoy routines. For testing, I compared the output of 
>> my C++ code to the output of the code in the RcppAnnoy package.
>>
>> - It is these tests that are failing (i.e., the output does not match up) 
>> during CHECK on Windows 64-bit only, despite the fact that the same library 
>> is being �#include�d in both the BiocNeighbors and RcppAnnoy sources!
>>
>> What makes this particularly intriguing is that the differences between 
>> BiocNeighbors and RcppAnnoy are very minor. Less than 1% of the neighbor 
>> identities differ, and only for some of the scenarios, so it�s not an 
>> obvious bug that would be changing the output en masse. Now, the package 
>> also uses/tests Annoy in BioC-release but builds fine on tokay1:
>>
>> http://bioconductor.org/checkResults/release/bioc-LATEST/BiocNeighbors/ 
>>  
>> > >
>>
>> The major difference between the Bioc-release/devel builds is the 
>> compilation flags, which have changed from �-O2 -mtune=generic� to �-O3 
>> -march=native -mtune=native� in tokay2. I am told (thanks Val) that the 
>> timing of this change is consistent with the start of the BiocNeighbors 
>> build failures on tokay2. I would guess that RcppAnnoy is also compiled with 
>> �-O2 -mtune=generic� on the CRAN build systems, introducing differences in 
>> optimization levels between the BiocNeighbors and RcppAnnoy binaries. These 
>> could be responsible for the discrepancies in the search results.
>>
>> I was able to reproduce this on my Unix cluster (gcc 6.5.0) where setting 
>> �-march=native� with either �-O3� or �-O2� caused a difference in the 
>> calculations. After much trial and error, I eventually narrowed this down to 
>> the �-mfma� flag, which seems to change the precision of multiply-and-add 
>> operations and thus the search results. This occurs even when AVX support is 
>> turned off; I guess the compiler tries to be smart if it detects you are 
>> doing some kind of simultaneous multiply and addition, which is a pretty 
>> common thing to do when computing Euclidean distances.
>>
>> In summary: can we not use �-march=native� on tokay2? 

Re: [Bioc-devel] Compilation flags, CHECK errors and BiocNeighbors

[Aaron Lun]

Thanks Val. I don�t think it�s a BiocNeighbors thing, as it doesn�t try to 
customize the compilation flags or have its own Makevars. Moreover, the �-O3 
-mtune=native -mtune=generic� flags seem to show up on all of my packages 
containing C++11 code. Some cursory checks of other packages suggest that the 
correct flags (�-O2 -mtune=generic�) are used for C++98 code.

-A

> On 17 Dec 2018, at 17:47, Obenchain, Valerie 
>  wrote:
> 
> Hi Aaron,
> 
> The only compilation flags that are different for tokay1 (release) and 
> tokay2 (devel) are C++14 flags. BiocNeighbors is not using C++14 but 
> C++11 so I think the changes we discussed previously actually don't 
> apply to your case.
> 
> All compilation flags we use are listed at the top of the build report, 
> e.g., for tokay2:
> 
> https://www.bioconductor.org/checkResults/devel/bioc-LATEST/tokay2-NodeInfo.html
>  
> 
> 
> I can look into this further but right now I'm not sure where the '-O3 
> -march=native -mtune=native' is coming from in the check output for 
> BiocNeighbors. We don't use 'native' on the builders for build/check or 
> for creating binaries.
> 
> Herve might have more insight on this.
> 
> Val
> 
> 
> 
> 
> 
> 
> 
> On 12/15/18 10:56 PM, Aaron Lun wrote:
>> Sometime between 6-18 November, BiocNeighbors� BioC-devel builds began 
>> failing on Windows 64-bit, and have continued to fail since:
>> 
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/BiocNeighbors/ 
>>  
>> > >
>> 
>> The most interesting part is the nature of the failures. They are not 
>> segmentation faults but rather �incorrect� output in the unit tests:
>> 
>> - BiocNeighbors uses the Annoy algorithm for approximate nearest neighbor 
>> search, which is provided as a header-only C++ library in the RcppAnnoy 
>> package.
>> 
>> - I have compiled the BiocNeighhbors C++ code with an �#include" for these 
>> libraries to use the Annoy routines. For testing, I compared the output of 
>> my C++ code to the output of the code in the RcppAnnoy package.
>> 
>> - It is these tests that are failing (i.e., the output does not match up) 
>> during CHECK on Windows 64-bit only, despite the fact that the same library 
>> is being �#include�d in both the BiocNeighbors and RcppAnnoy sources!
>> 
>> What makes this particularly intriguing is that the differences between 
>> BiocNeighbors and RcppAnnoy are very minor. Less than 1% of the neighbor 
>> identities differ, and only for some of the scenarios, so it�s not an 
>> obvious bug that would be changing the output en masse. Now, the package 
>> also uses/tests Annoy in BioC-release but builds fine on tokay1:
>> 
>> http://bioconductor.org/checkResults/release/bioc-LATEST/BiocNeighbors/ 
>>  
>> > >
>> 
>> The major difference between the Bioc-release/devel builds is the 
>> compilation flags, which have changed from �-O2 -mtune=generic� to �-O3 
>> -march=native -mtune=native� in tokay2. I am told (thanks Val) that the 
>> timing of this change is consistent with the start of the BiocNeighbors 
>> build failures on tokay2. I would guess that RcppAnnoy is also compiled with 
>> �-O2 -mtune=generic� on the CRAN build systems, introducing differences in 
>> optimization levels between the BiocNeighbors and RcppAnnoy binaries. These 
>> could be responsible for the discrepancies in the search results.
>> 
>> I was able to reproduce this on my Unix cluster (gcc 6.5.0) where setting 
>> �-march=native� with either �-O3� or �-O2� caused a difference in the 
>> calculations. After much trial and error, I eventually narrowed this down to 
>> the �-mfma� flag, which seems to change the precision of multiply-and-add 
>> operations and thus the search results. This occurs even when AVX support is 
>> turned off; I guess the compiler tries to be smart if it detects you are 
>> doing some kind of simultaneous multiply and addition, which is a pretty 
>> common thing to do when computing Euclidean distances.
>> 
>> In summary: can we not use �-march=native� on tokay2? (Val, I know we 
>> discussed this, but whatever changes you made to the compilation flags don�t 
>> seem to have propagated to the build machines.) As the case study with 
>> BiocNeighbors shows, this leads to inconsistencies between the CRAN and 
>> BioC-devel binaries for the same code, which unnecessarily complicates 
>> downstream usage and unit tests. I also wonder how binaries specialized for 
>> tokay2�s architecture would behave on other CPUs with different 

Re: [R-pkg-devel] In R package directory, where to put results for some long-taking simulations I want to use in README / vignette?

[Marta Karaś]

Cool, thanks! 100% clear and very helpful, I appreciate your answer a lot!

Bests / Pozdrawiam,
Marta Karas





On Mon, Dec 17, 2018 at 3:58 PM Duncan Murdoch 
wrote:

> On 17/12/2018 12:54 PM, Marta Karaś wrote:
> > For my R package, I want to demonstrate some benchmark results that take
> a
> > while to generate. I want to present the results in both README and
> > vignette.
> >
> > I thought a way to go is to have a README.Rmd code chunk with generates
> the
> > results with `eval = FALSE`, which I run in R console and save the table
> in
> > some place within a package, and then read the saved table and display it
> > in both README.Rmd (in a next chunk) and in the vignette Rmd file.
> >
> > Questions:
> >
> > - What is the proper subdirectory (naming, location) I should save
> > the results into?
>
> either data/ or inst// would be fine.  Use data if you want
> these to be easily available to package users, some private name if you
> don't.
>
> > - Should I out this subdirectory into .gitignore, or rather keep them
> > (i.e., they would be available to anybody who downloads package's
> source
> > files from CRAN?)
>
> What you put in .gitignore is up to you.  Do you want version control on
> these files?  Usually derived objects like your benchmark results aren't
> put in version control, you just put in the code to generate them.  But
> in this case, you might find it interesting to compare current results
> with historical ones, and version control would let you do that.
>
> Duncan Murdoch
>
> >
> > Thank you,
> > Marta
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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: [R-pkg-devel] In R package directory, where to put results for some long-taking simulations I want to use in README / vignette?

[Duncan Murdoch]

On 17/12/2018 12:54 PM, Marta Karaś wrote:

For my R package, I want to demonstrate some benchmark results that take a
while to generate. I want to present the results in both README and
vignette.

I thought a way to go is to have a README.Rmd code chunk with generates the
results with `eval = FALSE`, which I run in R console and save the table in
some place within a package, and then read the saved table and display it
in both README.Rmd (in a next chunk) and in the vignette Rmd file.

Questions:

- What is the proper subdirectory (naming, location) I should save
the results into?


either data/ or inst// would be fine.  Use data if you want 
these to be easily available to package users, some private name if you 
don't.



- Should I out this subdirectory into .gitignore, or rather keep them
(i.e., they would be available to anybody who downloads package's source
files from CRAN?)


What you put in .gitignore is up to you.  Do you want version control on 
these files?  Usually derived objects like your benchmark results aren't 
put in version control, you just put in the code to generate them.  But 
in this case, you might find it interesting to compare current results 
with historical ones, and version control would let you do that.


Duncan Murdoch



Thank you,
Marta

[[alternative HTML version deleted]]

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



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

Re: [Bioc-devel] failling to build vignette

[Martin, Tiphaine]

Thanks! I am working to fix that!

Tiphaine


Tiphaine Martin
Postdoc Fellow
Parsons lab
Department of Oncological Sciences
The Tisch Cancer Institute at Mount Sinai
Icahn School of Medicine at Mount Sinai
Hess Center for Science and Medicine
1470 Madison Ave, 6th Floor
New York, NY 10029
tel: 1- 212-824-8403
Email: tiphaine.mar...@mssm.edu


From: Shepherd, Lori 
Sent: Monday, December 17, 2018 2:41:59 PM
To: Martin, Tiphaine; bioc-devel@r-project.org
Subject: Re: failling to build vignette


Maybe others will have better suggestions for how to debug exactly...

I am able to reproduce the error and just with a trial and error of deleting 
and adding chunks of the vignette ... it first seems to appear with the attempt 
to add the figure


\begin{figure}
<>=
extdata <- system.file("extdata", package="coMET",mustWork=TRUE)
myinfofile <- file.path(extdata, "cyp1b1_infofile_Grch38.txt")
myexpressfile <- file.path(extdata, 
"cyp1b1_infofile_exprGene_region_Grch38.txt")
mycorrelation <- file.path(extdata, "cyp1b1_res37_rawMatrix.txt")
configfile <- file.path(extdata, "config_cyp1b1_zoom_4webserver_Grch38.txt")
comet.web(config.file=configfile, mydata.file=myinfofile,
  cormatrix.file=mycorrelation ,mydata.large.file=myexpressfile,
  print.image=FALSE,verbose=FALSE)
@
%\incfig{fig:cometweb_simple}{\textwidth}{Plot with comet.web function.}
\caption{Plot with \Rfunction{comet.web} function.\label{fig:cometweb_simple}}
\end{figure}


Everything before this seems to R CMD build without this error appearing...



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Martin, 
Tiphaine 
Sent: Monday, December 17, 2018 11:31:49 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] failling to build vignette

Hi,

I need to advise to build my vignette. It seems that my vignette could not 
build under Bioconductor 3.9. I try to find where it fails, but I  don't find 
the bug.
I updated my vignette last February to work with new version of BiocStyle and 
it did well for Bioconductor 3.8, but it seems that my vignette fails again 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/coMET/)
 .
Could you tell me if there is a major update in BiocStyle or how I can find my 
bug?

Thanks,
Tiphaine
---
Tiphaine Martin, PhD
Postdoc Fellow
Parsons lab
Department of Oncological Sciences
The Tisch Cancer Institute at Mount Sinai
Icahn School of Medicine at Mount Sinai
Hess Center for Science and Medicine
1470 Madison Ave, 6th Floor
New York, NY 10029
tel: 1- 212-824-8403
Email: tiphaine.mar...@mssm.edu

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] failling to build vignette

[Shepherd, Lori]

Maybe others will have better suggestions for how to debug exactly...

I am able to reproduce the error and just with a trial and error of deleting 
and adding chunks of the vignette ... it first seems to appear with the attempt 
to add the figure


\begin{figure}
<>=
extdata <- system.file("extdata", package="coMET",mustWork=TRUE)
myinfofile <- file.path(extdata, "cyp1b1_infofile_Grch38.txt")
myexpressfile <- file.path(extdata, 
"cyp1b1_infofile_exprGene_region_Grch38.txt")
mycorrelation <- file.path(extdata, "cyp1b1_res37_rawMatrix.txt")
configfile <- file.path(extdata, "config_cyp1b1_zoom_4webserver_Grch38.txt")
comet.web(config.file=configfile, mydata.file=myinfofile,
  cormatrix.file=mycorrelation ,mydata.large.file=myexpressfile,
  print.image=FALSE,verbose=FALSE)
@
%\incfig{fig:cometweb_simple}{\textwidth}{Plot with comet.web function.}
\caption{Plot with \Rfunction{comet.web} function.\label{fig:cometweb_simple}}
\end{figure}


Everything before this seems to R CMD build without this error appearing...



Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Martin, 
Tiphaine 
Sent: Monday, December 17, 2018 11:31:49 AM
To: bioc-devel@r-project.org
Subject: [Bioc-devel] failling to build vignette

Hi,

I need to advise to build my vignette. It seems that my vignette could not 
build under Bioconductor 3.9. I try to find where it fails, but I  don't find 
the bug.
I updated my vignette last February to work with new version of BiocStyle and 
it did well for Bioconductor 3.8, but it seems that my vignette fails again 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/coMET/) .
Could you tell me if there is a major update in BiocStyle or how I can find my 
bug?

Thanks,
Tiphaine
---
Tiphaine Martin, PhD
Postdoc Fellow
Parsons lab
Department of Oncological Sciences
The Tisch Cancer Institute at Mount Sinai
Icahn School of Medicine at Mount Sinai
Hess Center for Science and Medicine
1470 Madison Ave, 6th Floor
New York, NY 10029
tel: 1- 212-824-8403
Email: tiphaine.mar...@mssm.edu


[[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] BioC 3.9 devel builds

[Pages, Herve]

Hi Michael,

I don't think we have any package that require C++14 at the moment.

I see 36 software packages that have SystemRequirements: C++11 in devel. I 
agree that package authors should probably stick to that and avoid C++14 for 
now.

The change I made to the build system is just a minor improvement to the 
following pages:

  https://bioconductor.org/checkResults/3.9/bioc-LATEST/malbec2-NodeInfo.html

  https://bioconductor.org/checkResults/3.9/bioc-LATEST/tokay2-NodeInfo.html

  https://bioconductor.org/checkResults/3.9/bioc-LATEST/merida2-NodeInfo.html

Right now the old obsolete CXX1X* config variables are still displayed. With my 
change the new ones (CXX11*) will be displayed. Since I was on it, I also added 
the CXX98* and CXX14* variables, for the sake of completeness/transparency. All 
these new variables should become visible tomorrow.

H.


On 12/17/18 10:09, Michael Lawrence wrote:

Dear Val/Herve:

Does this mean that Bioconductor depends on C++14? Keeping up with the C++
standards is a struggle, at least for those maintaining deployments on
clusters with slow-moving enterprise linux distributions.

It would be helpful if someone could document the minimum C++ standard,
along with the minimum gcc/clang version.

Thanks,
Michael

On Mon, Dec 17, 2018 at 10:03 AM Obenchain, Valerie <
valerie.obench...@roswellpark.org> 
wrote:



Hi,

Just a heads up that we won't have a build report for 3.9 today. Herve
made some changes to the build report to display the C++14 compilation
flags and I messed up the deployment. Tomorrow we should be back on
track with the report and the new C++14 flags.

Sorry for the inconvenience.

Valerie


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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=1cOapRCMuM_U6xw1BIgue3cbftszOZ3MUNfznzsl7iE=ZCpB3AWWMv5G33UJ11s1zJfNw05_kaFCuJeJHgCrTwg=





[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=1cOapRCMuM_U6xw1BIgue3cbftszOZ3MUNfznzsl7iE=ZCpB3AWWMv5G33UJ11s1zJfNw05_kaFCuJeJHgCrTwg=


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


[[alternative HTML version deleted]]

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

[Rd] R is missing log1p(z) etc for complex numbers z.

[Martin Maechler]

Working on my 'Bessel' package, I've re-detected today, that
indeed even C99 standard GLIBC does not contain, a complex
number version of 

   log1p()

Further missing in current R, are, basically these

> z <- 1 + 2i
> log1p(z)
Error in log1p(z) : unimplemented complex function
> expm1(z)
Error in expm1(z) : unimplemented complex function
> gamma(z)
Error in gamma(z) : unimplemented complex function
> lgamma(z)
Error in lgamma(z) : unimplemented complex function
> psigamma(z)
Error in psigamma(z) : unimplemented complex function
> digamma(z)
Error in digamma(z) : unimplemented complex function
> sinpi(z)
Error in sinpi(z) : unimplemented complex function
> cospi(z)
Error in cospi(z) : unimplemented complex function
> floor(z)
Error in floor(z) : unimplemented complex function
> ceiling(z)
Error in ceiling(z) : unimplemented complex function
> 
--

Is anyone aware of Free Software implementations of these,
ideally in C ?

... yes, I think I've found the Julia source code for these,
nicely written in Julia itself...

Martin

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

Re: [Bioc-devel] BioC 3.9 devel builds

[Michael Lawrence]

Dear Val/Herve:

Does this mean that Bioconductor depends on C++14? Keeping up with the C++
standards is a struggle, at least for those maintaining deployments on
clusters with slow-moving enterprise linux distributions.

It would be helpful if someone could document the minimum C++ standard,
along with the minimum gcc/clang version.

Thanks,
Michael

On Mon, Dec 17, 2018 at 10:03 AM Obenchain, Valerie <
valerie.obench...@roswellpark.org> wrote:

> Hi,
>
> Just a heads up that we won't have a build report for 3.9 today. Herve
> made some changes to the build report to display the C++14 compilation
> flags and I messed up the deployment. Tomorrow we should be back on
> track with the report and the new C++14 flags.
>
> Sorry for the inconvenience.
>
> Valerie
>
>
> 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
>
>

[[alternative HTML version deleted]]

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

[Bioc-devel] BioC 3.9 devel builds

[Obenchain, Valerie]

Hi,

Just a heads up that we won't have a build report for 3.9 today. Herve 
made some changes to the build report to display the C++14 compilation 
flags and I messed up the deployment. Tomorrow we should be back on 
track with the report and the new C++14 flags.

Sorry for the inconvenience.

Valerie


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

[R-pkg-devel] In R package directory, where to put results for some long-taking simulations I want to use in README / vignette?

[Marta Karaś]

For my R package, I want to demonstrate some benchmark results that take a
while to generate. I want to present the results in both README and
vignette.

I thought a way to go is to have a README.Rmd code chunk with generates the
results with `eval = FALSE`, which I run in R console and save the table in
some place within a package, and then read the saved table and display it
in both README.Rmd (in a next chunk) and in the vignette Rmd file.

Questions:

   - What is the proper subdirectory (naming, location) I should save
   the results into?
   - Should I out this subdirectory into .gitignore, or rather keep them
   (i.e., they would be available to anybody who downloads package's source
   files from CRAN?)

Thank you,
Marta

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Cairo Error on MacOS on Bioc 3.9

[Obenchain, Valerie]

Hi Christian,

This is a known - there are no Mac binaries for El Capitan for R 3.6 at 
this point. We don't build Cairo from source on the Mac builder, we use 
the binary from CRAN. Once CRAN makes the binary available your package 
will build.

Valerie





On 12/14/18 4:37 AM, Christian Mertes wrote:
> Dear Bioconductor team,
> 
> I noticed that my package OUTRIDER and also some others have an issue
> with the Cairo package.
> 
> The error is:
> 
> .onLoad failed in loadNamespace() for 'Cairo', details:
>     call: dyn.load(file, DLLpath = DLLpath, ...)
>     error: unable to load shared object
> '/Library/Frameworks/R.framework/Versions/3.6/Resources/library/Cairo/libs/Cairo.so':
> dlopen(/Library/Frameworks/R.framework/Versions/3.6/Resources/library/Cairo/libs/Cairo.so,
> 6): Symbol not found: _FcConfigGetCurrent
>     Referenced from:
> /Library/Frameworks/R.framework/Versions/3.6/Resources/library/Cairo/libs/Cairo.so
>     Expected in: flat namespace
>    in
> /Library/Frameworks/R.framework/Versions/3.6/Resources/library/Cairo/libs/Cairo.so
> 
> https://bioc.ism.ac.jp/checkResults/devel/bioc-LATEST/OUTRIDER/merida2-checksrc.html
> https://bioc.ism.ac.jp/checkResults/devel/bioc-LATEST/CATALYST/merida2-checksrc.html
> 
> Also the same error came up in earlier versions already and was then solved.
> 
> https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007643.html
> 
> I guess this is rather an issue of the test server. But if you need more
> information on this, please let me know.
> 
> Best regards,
> 
> Christian Mertes
> 



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

Re: [Bioc-devel] Pushing to upstream master

[Turaga, Nitesh]

I need more information to help you. 

Please check http://bioconductor.org/developers/how-to/git/faq/, #14 
especially.  And any others you may need.

> On Dec 17, 2018, at 12:46 PM, Anand MT  wrote:
> 
> Hi Nitesh,
> 
> Yes, I have pulled from upstream but still the same issue.
> 
> $ git pull upstream master
> From git.bioconductor.org:packages/maftools
> * branchmaster -> FETCH_HEAD
> Already up to date.
> 
> $ git status
> On branch devel
> nothing to commit, working tree clean
> 
> $ git push upstream master
> To git.bioconductor.org:packages/maftools.git
> ! [rejected]master -> master (non-fast-forward)
> error: failed to push some refs to 
> 'g...@git.bioconductor.org:packages/maftools.git'
> hint: Updates were rejected because a pushed branch tip is behind its remote
> hint: counterpart. Check out this branch and integrate the remote changes
> hint: (e.g. 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> 
> 
> 
>> On 17 Dec 2018, at 5:43 PM, Turaga, Nitesh  
>> wrote:
>> 
>> Hi,
>> 
>> Have your tried the command mentioned in the error message 
>> 
>>  git pull 
>> 
>> 
>> This is important. 
>> 
>> Once that is done, “IF” you have merge conflicts, please do
>> 
>>  http://bioconductor.org/developers/how-to/git/resolve-conflicts/
>> 
>> Best,
>> 
>> Nitesh 
>> 
>>> On Dec 17, 2018, at 10:22 AM, Anand MT  wrote:
>>> 
>>> Hi all,
>>> 
>>> I maintain maftools bioconductor package. I recently fixed several bugs 
>>> which had resulted in build fail on devel branch of Bioconductor. However, 
>>> I am unable to push them to upstream master. I have gone through help pages 
>>> on Bioconductor page as well several other solutions online but I am not 
>>> able to fix it. Please accept my apologies in advance if this has been 
>>> already discussed before. 
>>> 
>>> Below are my git commands and error:
>>> 
>>> $ git branch devel
>>> $ git checkout devel
>>> Switched to branch 'devel'
>>> $ git fetch upstream
>>> $ git merge upstream/master
>>> Auto-merging DESCRIPTION
>>> CONFLICT (content): Merge conflict in DESCRIPTION
>>> Automatic merge failed; fix conflicts and then commit the result.
>>> $ vi DESCRIPTION 
>>> Fixed merge conflict
>>> $ git add .
>>> $ git commit -m "bug fixes"
>>> $ git status
>>> On branch devel
>>> nothing to commit, working tree clean
>>> $ git push upstream master
>>> To git.bioconductor.org:packages/maftools.git
>>> ! [rejected]master -> master (non-fast-forward)
>>> error: failed to push some refs to 
>>> 'g...@git.bioconductor.org:packages/maftools.git'
>>> hint: Updates were rejected because a pushed branch tip is behind its remote
>>> hint: counterpart. Check out this branch and integrate the remote changes
>>> hint: (e.g. 'git pull ...') before pushing again.
>>> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>>> 
>>> Could you please suggest me on how to proceed.
>>> 
>>> -Anand. 
>>> ___
>>> 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.
> 



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

Re: [Bioc-devel] Compilation flags, CHECK errors and BiocNeighbors

[Obenchain, Valerie]

Hi Aaron,

The only compilation flags that are different for tokay1 (release) and 
tokay2 (devel) are C++14 flags. BiocNeighbors is not using C++14 but 
C++11 so I think the changes we discussed previously actually don't 
apply to your case.

All compilation flags we use are listed at the top of the build report, 
e.g., for tokay2:

https://www.bioconductor.org/checkResults/devel/bioc-LATEST/tokay2-NodeInfo.html

I can look into this further but right now I'm not sure where the '-O3 
-march=native -mtune=native' is coming from in the check output for 
BiocNeighbors. We don't use 'native' on the builders for build/check or 
for creating binaries.

Herve might have more insight on this.

Val







On 12/15/18 10:56 PM, Aaron Lun wrote:
> Sometime between 6-18 November, BiocNeighbors’ BioC-devel builds began 
> failing on Windows 64-bit, and have continued to fail since:
> 
> http://bioconductor.org/checkResults/devel/bioc-LATEST/BiocNeighbors/ 
> 
> 
> The most interesting part is the nature of the failures. They are not 
> segmentation faults but rather “incorrect” output in the unit tests:
> 
> - BiocNeighbors uses the Annoy algorithm for approximate nearest neighbor 
> search, which is provided as a header-only C++ library in the RcppAnnoy 
> package.
> 
> - I have compiled the BiocNeighhbors C++ code with an “#include" for these 
> libraries to use the Annoy routines. For testing, I compared the output of my 
> C++ code to the output of the code in the RcppAnnoy package.
> 
> - It is these tests that are failing (i.e., the output does not match up) 
> during CHECK on Windows 64-bit only, despite the fact that the same library 
> is being “#include”d in both the BiocNeighbors and RcppAnnoy sources!
> 
> What makes this particularly intriguing is that the differences between 
> BiocNeighbors and RcppAnnoy are very minor. Less than 1% of the neighbor 
> identities differ, and only for some of the scenarios, so it’s not an obvious 
> bug that would be changing the output en masse. Now, the package also 
> uses/tests Annoy in BioC-release but builds fine on tokay1:
> 
> http://bioconductor.org/checkResults/release/bioc-LATEST/BiocNeighbors/ 
> 
> 
> The major difference between the Bioc-release/devel builds is the compilation 
> flags, which have changed from “-O2 -mtune=generic” to “-O3 -march=native 
> -mtune=native” in tokay2. I am told (thanks Val) that the timing of this 
> change is consistent with the start of the BiocNeighbors build failures on 
> tokay2. I would guess that RcppAnnoy is also compiled with “-O2 
> -mtune=generic” on the CRAN build systems, introducing differences in 
> optimization levels between the BiocNeighbors and RcppAnnoy binaries. These 
> could be responsible for the discrepancies in the search results.
> 
> I was able to reproduce this on my Unix cluster (gcc 6.5.0) where setting 
> “-march=native” with either “-O3” or “-O2” caused a difference in the 
> calculations. After much trial and error, I eventually narrowed this down to 
> the “-mfma” flag, which seems to change the precision of multiply-and-add 
> operations and thus the search results. This occurs even when AVX support is 
> turned off; I guess the compiler tries to be smart if it detects you are 
> doing some kind of simultaneous multiply and addition, which is a pretty 
> common thing to do when computing Euclidean distances.
> 
> In summary: can we not use “-march=native” on tokay2? (Val, I know we 
> discussed this, but whatever changes you made to the compilation flags don’t 
> seem to have propagated to the build machines.) As the case study with 
> BiocNeighbors shows, this leads to inconsistencies between the CRAN and 
> BioC-devel binaries for the same code, which unnecessarily complicates 
> downstream usage and unit tests. I also wonder how binaries specialized for 
> tokay2’s architecture would behave on other CPUs with different instruction 
> sets, if they would run at all.
> 
> Cheers,
> 
> Aaron
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Pushing to upstream master

[Anand MT]

Hi Nitesh,

Yes, I have pulled from upstream but still the same issue.

$ git pull upstream master
From git.bioconductor.org:packages/maftools
* branchmaster -> FETCH_HEAD
Already up to date.

$ git status
On branch devel
nothing to commit, working tree clean

$ git push upstream master
To git.bioconductor.org:packages/maftools.git
! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 
'g...@git.bioconductor.org:packages/maftools.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.



> On 17 Dec 2018, at 5:43 PM, Turaga, Nitesh  
> wrote:
> 
> Hi,
> 
> Have your tried the command mentioned in the error message 
> 
>   git pull 
> 
> 
> This is important. 
> 
> Once that is done, “IF” you have merge conflicts, please do
> 
>   http://bioconductor.org/developers/how-to/git/resolve-conflicts/
> 
> Best,
> 
> Nitesh 
> 
>> On Dec 17, 2018, at 10:22 AM, Anand MT  wrote:
>> 
>> Hi all,
>> 
>> I maintain maftools bioconductor package. I recently fixed several bugs 
>> which had resulted in build fail on devel branch of Bioconductor. However, I 
>> am unable to push them to upstream master. I have gone through help pages on 
>> Bioconductor page as well several other solutions online but I am not able 
>> to fix it. Please accept my apologies in advance if this has been already 
>> discussed before. 
>> 
>> Below are my git commands and error:
>> 
>> $ git branch devel
>> $ git checkout devel
>> Switched to branch 'devel'
>> $ git fetch upstream
>> $ git merge upstream/master
>> Auto-merging DESCRIPTION
>> CONFLICT (content): Merge conflict in DESCRIPTION
>> Automatic merge failed; fix conflicts and then commit the result.
>> $ vi DESCRIPTION 
>> Fixed merge conflict
>> $ git add .
>> $ git commit -m "bug fixes"
>> $ git status
>> On branch devel
>> nothing to commit, working tree clean
>> $ git push upstream master
>> To git.bioconductor.org:packages/maftools.git
>> ! [rejected]master -> master (non-fast-forward)
>> error: failed to push some refs to 
>> 'g...@git.bioconductor.org:packages/maftools.git'
>> hint: Updates were rejected because a pushed branch tip is behind its remote
>> hint: counterpart. Check out this branch and integrate the remote changes
>> hint: (e.g. 'git pull ...') before pushing again.
>> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>> 
>> Could you please suggest me on how to proceed.
>> 
>> -Anand. 
>> ___
>> 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

Re: [Bioc-devel] Giving Write Access

[Turaga, Nitesh]

Hi Micheal, 

Please be informed that there can be only one “maintainer”. You may consider 
having more than one collaborator on the package, which is Benjamin Haibe 
Kains. 

Also, the email on file for Benjamin is "bhklab.resea...@gmail.com” with the 
username you have provided. 

I will add the username registered to that email address. Not the one you 
provided.

Please check after 1pm EST today. 

Best,

Nitesh 

> On Dec 17, 2018, at 11:43 AM, michael zon  wrote:
> 
> Hi,
> 
> I would like to add my labs software developer to my current Bioc packages,
> but he says that according to "ssh -T g...@git.bioconductor.org | grep
> Meta"  he does not have write access. Is there a way I can give him write
> access? They want to add the email benjamin.haibe.ka...@utoronto.ca and git
> username b.haibe-kains. Figure I would supply these in case changes cannot
> be made on my end, if they can please just let me know how to provide their
> account with access. I am the maintainer of MetaGxBreast, MetaGxOvarian,
> and MetaGxPancreas and I would like to give my lab member access to all 3
> packages.
> 
> Thanks,
> Michael
> 
>   [[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.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] Giving Write Access

[michael zon]

Hi,

I would like to add my labs software developer to my current Bioc packages,
but he says that according to "ssh -T g...@git.bioconductor.org | grep
Meta"  he does not have write access. Is there a way I can give him write
access? They want to add the email benjamin.haibe.ka...@utoronto.ca and git
username b.haibe-kains. Figure I would supply these in case changes cannot
be made on my end, if they can please just let me know how to provide their
account with access. I am the maintainer of MetaGxBreast, MetaGxOvarian,
and MetaGxPancreas and I would like to give my lab member access to all 3
packages.

Thanks,
Michael

[[alternative HTML version deleted]]

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

Re: [Rd] Documentation examples for lm and glm

[Heinz Tuechler]

Dear John,

fully agreed! In the global environment I always keep my 
"data-variables" in a data.frame. However, if I look in help I like 
examples that start with the particular aspects of a function. It is 
important to know, if a function offers a data argument, but in the 
first line I don't need an example for the use of a data argument each 
time I look in help.


best,
Heinz

Fox, John wrote/hat geschrieben on/am 17.12.2018 16:23:

Dear Heinz,

  --

On Dec 17, 2018, at 10:19 AM, Heinz Tuechler  wrote:

Dear All,

do you think that use of a data argument is best practice in the example below?


No, but it is *normally* or *usually* the best option, in my opinion.

Best,
 John



regards,

Heinz

### trivial example
plotwithline <- function(x, y) {
   plot(x, y)
   abline(lm(y~x)) ## data argument?
}

set.seed(25)
df0 <- data.frame(x=rnorm(20), y=rnorm(20))

plotwithline(df0[['x']], df0[['y']])



Fox, John wrote/hat geschrieben on/am 17.12.2018 15:21:

Dear Martin,

I think that everyone agrees that it’s generally preferable to use the data 
argument to lm() and I have nothing significant to add to the substance of the 
discussion, but I think that it’s a mistake not to add to the current examples, 
for the following reasons:

(1) Relegating examples using the data argument to “see also” doesn’t suggest 
that using the argument is a best practice. Most users won’t bother to click 
the links.

(2) In my opinion, an new initial example using the data argument would more 
clearly suggest that this is the normally the best option.

(3) I think that it would also be desirable to add a remark to the explanation 
of the data argument, something like, “Although the argument is optional, it's 
generally preferable to specify it explicitly.” And similarly on the help page 
for glm().

My two (or three) cents.

John

 -
 John Fox, Professor Emeritus
 McMaster University
 Hamilton, Ontario, Canada
 Web: http::/socserv.mcmaster.ca/jfox


On Dec 17, 2018, at 3:05 AM, Martin Maechler  wrote:


David Hugh-Jones
  on Sat, 15 Dec 2018 08:47:28 +0100 writes:



I would argue examples should encourage good
practice. Beginners ought to learn to keep data in data
frames and not to overuse attach().


Note there's no attach() there in any of these examples!


otherwise at their own risk, but they have less need of
explicit examples.


The glm examples are nice in sofar they show both uses.

I agree the lm() example(s) are  "didactically misleading" by
not using data frames at all.

I disagree that only data frame examples should be shown.
If  lm()  is one of the first R functions a beginneR must use --
because they are in a basic stats class, say --  it may be
*better* didactically to focus on lm()  in the very first
example, and use data frames in a next one ...
 and instead of next one, we have the pretty clear comment

### less simple examples in "See Also" above

I'm not convinced (but you can try more) we should change those
examples or add more there.

Martin


On Fri, 14 Dec 2018 at 14:51, S Ellison
 wrote:



FWIW, before all the examples are changed to data frame
variants, I think there's fairly good reason to have at
least _one_ example that does _not_ place variables in a
data frame.

The data argument in lm() is optional. And there is more
than one way to manage data in a project. I personally
don't much like lots of stray variables lurking about,
but if those are the only variables out there and we can
be sure they aren't affected by other code, it's hardly
essential to create a data frame to hold something you
already have.  Also, attach() is still part of R, for
those folk who have a data frame but want to reference
the contents across a wider range of functions without
using with() a lot. lm() can reasonably omit the data
argument there, too.

So while there are good reasons to use data frames, there
are also good reasons to provide examples that don't.

Steve Ellison



-Original Message- > From: R-devel

[mailto:r-devel-boun...@r-project.org] On Behalf Of Ben >
Bolker > Sent: 13 December 2018 20:36 > To:
r-devel@r-project.org > Subject: Re: [Rd] Documentation
examples for lm and glm



Agree.  Or just create the data frame with those

variables in it > directly ...


On 2018-12-13 3:26 p.m., Thomas Yee wrote: > > Hello,


something that has been on my mind for a decade or

two has > > been the examples for lm() and glm(). They
encourage poor style > > because of mismanagement of data
frames. Also, having the > > variables in a data frame
means that predict() > > is more likely to work properly.


For lm(), the variables should be put into a data

frame.  > > As 2 vectors are assigned first in the
general workspace they > > should be deleted afterwards.


For the glm(), the data frame d.AD is constructed but

not used. Also, > > its 3 components were assigned first
in the general workspace, so they > 

[Bioc-devel] failling to build vignette

[Martin, Tiphaine]

Hi,

I need to advise to build my vignette. It seems that my vignette could not 
build under Bioconductor 3.9. I try to find where it fails, but I  don't find 
the bug.
I updated my vignette last February to work with new version of BiocStyle and 
it did well for Bioconductor 3.8, but it seems that my vignette fails again 
(http://bioconductor.org/checkResults/devel/bioc-LATEST/coMET/) .
Could you tell me if there is a major update in BiocStyle or how I can find my 
bug?

Thanks,
Tiphaine
---
Tiphaine Martin, PhD
Postdoc Fellow
Parsons lab
Department of Oncological Sciences
The Tisch Cancer Institute at Mount Sinai
Icahn School of Medicine at Mount Sinai
Hess Center for Science and Medicine
1470 Madison Ave, 6th Floor
New York, NY 10029
tel: 1- 212-824-8403
Email: tiphaine.mar...@mssm.edu


[[alternative HTML version deleted]]

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

Re: [Rd] Unnecessary apostrophe in English base::summary() NA count output?

[Ben Bolker]

There seem to be a variety of opinions about style in this case; do
you omit the apostrophe ("NAs") because it's not a possessive or a
contraction, or do you include the apostrophe ("NA's") to clearly
distinguish the acronym from the plural form?

 I personally prefer "NAs" to "NA's" but both are defensible.

https://english.stackexchange.com/questions/55970/plurals-of-acronyms-letters-numbers-use-an-apostrophe-or-not
https://brians.wsu.edu/2016/05/16/acronyms-and-apostrophes/ ("many
people object to it")

On Mon, Dec 17, 2018 at 10:20 AM Hernando Cortina  wrote:
>
>  Hello, this is quite a minor issue but as summary() is in all likelihood
> one of the most widely used functions in R I decided to email this list.
> When producing a count of missing values, summary() in English generates an
> unnecessary and grammatically incorrect apostrophe (NA's rather than NAs)
> in its table header.  For example:
>
> > summary(c(1,2,NA,3,4,NA))
>Min. 1st Qu.  MedianMean 3rd Qu.Max.NA's
>1.001.752.502.503.254.00   2
>
> The issue can be traced to this file:
> https://svn.r-project.org/R/trunk/src/library/base/R/summary.R
> Unless this is being done intentionally for some reason, the solution would
> seem to be to replace the string "NA's" with "NAs".  There are 9
> occurrences in the file.
>
> Thank you very much.
>
> [[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

Re: [Rd] Documentation examples for lm and glm

[Fox, John]

Dear Heinz,

  --
> On Dec 17, 2018, at 10:19 AM, Heinz Tuechler  wrote:
> 
> Dear All,
> 
> do you think that use of a data argument is best practice in the example 
> below?

No, but it is *normally* or *usually* the best option, in my opinion.

Best,
 John

> 
> regards,
> 
> Heinz
> 
> ### trivial example
> plotwithline <- function(x, y) {
>plot(x, y)
>abline(lm(y~x)) ## data argument?
> }
> 
> set.seed(25)
> df0 <- data.frame(x=rnorm(20), y=rnorm(20))
> 
> plotwithline(df0[['x']], df0[['y']])
> 
> 
> 
> Fox, John wrote/hat geschrieben on/am 17.12.2018 15:21:
>> Dear Martin,
>> 
>> I think that everyone agrees that it’s generally preferable to use the data 
>> argument to lm() and I have nothing significant to add to the substance of 
>> the discussion, but I think that it’s a mistake not to add to the current 
>> examples, for the following reasons:
>> 
>> (1) Relegating examples using the data argument to “see also” doesn’t 
>> suggest that using the argument is a best practice. Most users won’t bother 
>> to click the links.
>> 
>> (2) In my opinion, an new initial example using the data argument would more 
>> clearly suggest that this is the normally the best option.
>> 
>> (3) I think that it would also be desirable to add a remark to the 
>> explanation of the data argument, something like, “Although the argument is 
>> optional, it's generally preferable to specify it explicitly.” And similarly 
>> on the help page for glm().
>> 
>> My two (or three) cents.
>> 
>> John
>> 
>>  -
>>  John Fox, Professor Emeritus
>>  McMaster University
>>  Hamilton, Ontario, Canada
>>  Web: http::/socserv.mcmaster.ca/jfox
>> 
>>> On Dec 17, 2018, at 3:05 AM, Martin Maechler  
>>> wrote:
>>> 
 David Hugh-Jones
   on Sat, 15 Dec 2018 08:47:28 +0100 writes:
>>> 
 I would argue examples should encourage good
 practice. Beginners ought to learn to keep data in data
 frames and not to overuse attach().
>>> 
>>> Note there's no attach() there in any of these examples!
>>> 
 otherwise at their own risk, but they have less need of
 explicit examples.
>>> 
>>> The glm examples are nice in sofar they show both uses.
>>> 
>>> I agree the lm() example(s) are  "didactically misleading" by
>>> not using data frames at all.
>>> 
>>> I disagree that only data frame examples should be shown.
>>> If  lm()  is one of the first R functions a beginneR must use --
>>> because they are in a basic stats class, say --  it may be
>>> *better* didactically to focus on lm()  in the very first
>>> example, and use data frames in a next one ...
>>>  and instead of next one, we have the pretty clear comment
>>> 
>>> ### less simple examples in "See Also" above
>>> 
>>> I'm not convinced (but you can try more) we should change those
>>> examples or add more there.
>>> 
>>> Martin
>>> 
 On Fri, 14 Dec 2018 at 14:51, S Ellison
  wrote:
>>> 
> FWIW, before all the examples are changed to data frame
> variants, I think there's fairly good reason to have at
> least _one_ example that does _not_ place variables in a
> data frame.
> 
> The data argument in lm() is optional. And there is more
> than one way to manage data in a project. I personally
> don't much like lots of stray variables lurking about,
> but if those are the only variables out there and we can
> be sure they aren't affected by other code, it's hardly
> essential to create a data frame to hold something you
> already have.  Also, attach() is still part of R, for
> those folk who have a data frame but want to reference
> the contents across a wider range of functions without
> using with() a lot. lm() can reasonably omit the data
> argument there, too.
> 
> So while there are good reasons to use data frames, there
> are also good reasons to provide examples that don't.
> 
> Steve Ellison
> 
> 
>> -Original Message- > From: R-devel
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Ben >
> Bolker > Sent: 13 December 2018 20:36 > To:
> r-devel@r-project.org > Subject: Re: [Rd] Documentation
> examples for lm and glm
>> 
>> 
>> Agree.  Or just create the data frame with those
> variables in it > directly ...
>> 
>> On 2018-12-13 3:26 p.m., Thomas Yee wrote: > > Hello,
>>> 
>>> something that has been on my mind for a decade or
> two has > > been the examples for lm() and glm(). They
> encourage poor style > > because of mismanagement of data
> frames. Also, having the > > variables in a data frame
> means that predict() > > is more likely to work properly.
>>> 
>>> For lm(), the variables should be put into a data
> frame.  > > As 2 vectors are assigned first in the
> general workspace they > > should be deleted afterwards.
>>> 
>>> For the glm(), the 

[Rd] Unnecessary apostrophe in English base::summary() NA count output?

[Hernando Cortina]

 Hello, this is quite a minor issue but as summary() is in all likelihood
one of the most widely used functions in R I decided to email this list.
When producing a count of missing values, summary() in English generates an
unnecessary and grammatically incorrect apostrophe (NA's rather than NAs)
in its table header.  For example:

> summary(c(1,2,NA,3,4,NA))
   Min. 1st Qu.  MedianMean 3rd Qu.Max.NA's
   1.001.752.502.503.254.00   2

The issue can be traced to this file:
https://svn.r-project.org/R/trunk/src/library/base/R/summary.R
Unless this is being done intentionally for some reason, the solution would
seem to be to replace the string "NA's" with "NAs".  There are 9
occurrences in the file.

Thank you very much.

[[alternative HTML version deleted]]

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

[R-pkg-devel] CRAN incoming queue closed from Dec 21 to Jan 02

[Uwe Ligges]

Dear package developers,

the CRAN incoming queue will be closed from Dec 21, 2018 to Jan 02, 
2019. Hence package submissions are only possible before and after that 
period.


Best,
Uwe Ligges
(for the CRAN team)

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

[Rd] CRAN incoming queue closed from Dec 21 to Jan 02

[Uwe Ligges]

Dear package developers,

the CRAN incoming queue will be closed from Dec 21, 2018 to Jan 02, 
2019. Hence package submissions are only possible before and after that 
period.


Best,
Uwe Ligges
(for the CRAN team)

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

Re: [Rd] Documentation examples for lm and glm

[Heinz Tuechler]

Dear All,

do you think that use of a data argument is best practice in the example 
below?


regards,

Heinz

### trivial example
plotwithline <- function(x, y) {
plot(x, y)
abline(lm(y~x)) ## data argument?
}

set.seed(25)
df0 <- data.frame(x=rnorm(20), y=rnorm(20))

plotwithline(df0[['x']], df0[['y']])



Fox, John wrote/hat geschrieben on/am 17.12.2018 15:21:

Dear Martin,

I think that everyone agrees that it’s generally preferable to use the data 
argument to lm() and I have nothing significant to add to the substance of the 
discussion, but I think that it’s a mistake not to add to the current examples, 
for the following reasons:

(1) Relegating examples using the data argument to “see also” doesn’t suggest 
that using the argument is a best practice. Most users won’t bother to click 
the links.

(2) In my opinion, an new initial example using the data argument would more 
clearly suggest that this is the normally the best option.

(3) I think that it would also be desirable to add a remark to the explanation 
of the data argument, something like, “Although the argument is optional, it's 
generally preferable to specify it explicitly.” And similarly on the help page 
for glm().

My two (or three) cents.

John

  -
  John Fox, Professor Emeritus
  McMaster University
  Hamilton, Ontario, Canada
  Web: http::/socserv.mcmaster.ca/jfox


On Dec 17, 2018, at 3:05 AM, Martin Maechler  wrote:


David Hugh-Jones
   on Sat, 15 Dec 2018 08:47:28 +0100 writes:



I would argue examples should encourage good
practice. Beginners ought to learn to keep data in data
frames and not to overuse attach().


Note there's no attach() there in any of these examples!


otherwise at their own risk, but they have less need of
explicit examples.


The glm examples are nice in sofar they show both uses.

I agree the lm() example(s) are  "didactically misleading" by
not using data frames at all.

I disagree that only data frame examples should be shown.
If  lm()  is one of the first R functions a beginneR must use --
because they are in a basic stats class, say --  it may be
*better* didactically to focus on lm()  in the very first
example, and use data frames in a next one ...
 and instead of next one, we have the pretty clear comment

 ### less simple examples in "See Also" above

I'm not convinced (but you can try more) we should change those
examples or add more there.

Martin


On Fri, 14 Dec 2018 at 14:51, S Ellison
 wrote:



FWIW, before all the examples are changed to data frame
variants, I think there's fairly good reason to have at
least _one_ example that does _not_ place variables in a
data frame.

The data argument in lm() is optional. And there is more
than one way to manage data in a project. I personally
don't much like lots of stray variables lurking about,
but if those are the only variables out there and we can
be sure they aren't affected by other code, it's hardly
essential to create a data frame to hold something you
already have.  Also, attach() is still part of R, for
those folk who have a data frame but want to reference
the contents across a wider range of functions without
using with() a lot. lm() can reasonably omit the data
argument there, too.

So while there are good reasons to use data frames, there
are also good reasons to provide examples that don't.

Steve Ellison



-Original Message- > From: R-devel

[mailto:r-devel-boun...@r-project.org] On Behalf Of Ben >
Bolker > Sent: 13 December 2018 20:36 > To:
r-devel@r-project.org > Subject: Re: [Rd] Documentation
examples for lm and glm



Agree.  Or just create the data frame with those

variables in it > directly ...


On 2018-12-13 3:26 p.m., Thomas Yee wrote: > > Hello,


something that has been on my mind for a decade or

two has > > been the examples for lm() and glm(). They
encourage poor style > > because of mismanagement of data
frames. Also, having the > > variables in a data frame
means that predict() > > is more likely to work properly.


For lm(), the variables should be put into a data

frame.  > > As 2 vectors are assigned first in the
general workspace they > > should be deleted afterwards.


For the glm(), the data frame d.AD is constructed but

not used. Also, > > its 3 components were assigned first
in the general workspace, so they > > float around
dangerously afterwards like in the lm() example.


Rather than attached improved .Rd files here, they

are put at > > www.stat.auckland.ac.nz/~yee/Rdfiles > >
You are welcome to use them!


Best,

Thomas

__ > >

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


***
This email and any attachments are confidential. Any
u...{{dropped:12}}

Re: [Rd] Documentation examples for lm and glm

[Fox, John]

Dear Steve,

Since this relates as well to the message I posted a couple of minutes before 
yours, I agree that it’s possible to phrase “best practices” too categorically. 
In the current case, I believe that it’s reasonable to say that specifying the 
data argument is “generally” or “usually” the best option. That doesn’t rule 
out exceptions.

Best,
 John

  -
  John Fox, Professor Emeritus
  McMaster University
  Hamilton, Ontario, Canada
  Web: http::/socserv.mcmaster.ca/jfox

> On Dec 17, 2018, at 7:49 AM, S Ellison  wrote:
> 
> 
> 
>> From: Thomas Yee [mailto:t@auckland.ac.nz]
>> 
>> Thanks for the discussion. I do feel quite strongly that
>> the variables should always be a part of a data frame. 
> 
> This seems pretty much a decision for R core, and I think it's useful to have 
> raised the issue.
> 
> But I, er, feel strongly that strong feelings and 'always' are unsafe in a 
> best practice argument. 
> 
> First, other folk with different use-cases or work practice may see 'best 
> practice' quite differently. So I would pretty much always expect exceptions.
> 
> Second, for examples of capability, there are too many exceptions in this 
> instance. For example:
> glm() can take a two-column matrix as a single response variable. 
> lm() can take a matrix as a response variable. 
> lm() can take a complete data frame as a predictor (see ?stackloss)
> 
> None of these work naturally if everything is in a data frame, and some won’t 
> work at all.
> 
> Steve E
> 
> 
> 
> 
> ***
> This email and any attachments are confidential. Any use, copying or
> disclosure other than by the intended recipient is unauthorised. If 
> you have received this message in error, please notify the sender 
> immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com 
> and delete this message and any copies from your computer and network. 
> LGC Limited. Registered in England 2991879. 
> Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
> __
> 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] Undefined slot classes warning

[Martin Morgan]

It seems like you've posted this in several locations -- stackoverflow, slack, 
here. Choose one forum and stick with it, so that people do not waste their 
time duplicating effort. Regardless of forum, provide a minimal reproducible 
example (e.g., a stripped-down github repository) to illustrate the problem -- 
this helps avoid needless speculation and often results, in the process of 
creating the reproducible example, an 'ah ha' moment when the problem becomes 
apparent. Martin

On 12/17/18, 9:09 AM, "Bioc-devel on behalf of Vladimir Kiselev" 
 
wrote:

Hello,

We have a warning related to defining an S4 object:
Warning: undefined slot classes in definition of "MyObject": index(class
"Rcpp_ModuleClass")

More details are here:

https://stackoverflow.com/questions/53814548/rcpp-class-wrapped-in-s4-object-warning

Could anyone please help?

Many thanks,
Vladimir

[[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: [Rd] Documentation examples for lm and glm

[S Ellison]

> From: Thomas Yee [mailto:t@auckland.ac.nz]
> 
> Thanks for the discussion. I do feel quite strongly that
> the variables should always be a part of a data frame. 

This seems pretty much a decision for R core, and I think it's useful to have 
raised the issue.

But I, er, feel strongly that strong feelings and 'always' are unsafe in a best 
practice argument. 

First, other folk with different use-cases or work practice may see 'best 
practice' quite differently. So I would pretty much always expect exceptions.

Second, for examples of capability, there are too many exceptions in this 
instance. For example:
glm() can take a two-column matrix as a single response variable. 
lm() can take a matrix as a response variable. 
lm() can take a complete data frame as a predictor (see ?stackloss)

None of these work naturally if everything is in a data frame, and some won’t 
work at all.

Steve E




***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If 
you have received this message in error, please notify the sender 
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com 
and delete this message and any copies from your computer and network. 
LGC Limited. Registered in England 2991879. 
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Documentation examples for lm and glm

[Fox, John]

Dear Martin,

I think that everyone agrees that it’s generally preferable to use the data 
argument to lm() and I have nothing significant to add to the substance of the 
discussion, but I think that it’s a mistake not to add to the current examples, 
for the following reasons:

(1) Relegating examples using the data argument to “see also” doesn’t suggest 
that using the argument is a best practice. Most users won’t bother to click 
the links.

(2) In my opinion, an new initial example using the data argument would more 
clearly suggest that this is the normally the best option.

(3) I think that it would also be desirable to add a remark to the explanation 
of the data argument, something like, “Although the argument is optional, it's 
generally preferable to specify it explicitly.” And similarly on the help page 
for glm().

My two (or three) cents.

John

  -
  John Fox, Professor Emeritus
  McMaster University
  Hamilton, Ontario, Canada
  Web: http::/socserv.mcmaster.ca/jfox

> On Dec 17, 2018, at 3:05 AM, Martin Maechler  
> wrote:
> 
>> David Hugh-Jones 
>>on Sat, 15 Dec 2018 08:47:28 +0100 writes:
> 
>> I would argue examples should encourage good
>> practice. Beginners ought to learn to keep data in data
>> frames and not to overuse attach(). 
> 
> Note there's no attach() there in any of these examples!
> 
>> otherwise at their own risk, but they have less need of
>> explicit examples.
> 
> The glm examples are nice in sofar they show both uses.
> 
> I agree the lm() example(s) are  "didactically misleading" by
> not using data frames at all.
> 
> I disagree that only data frame examples should be shown.
> If  lm()  is one of the first R functions a beginneR must use --
> because they are in a basic stats class, say --  it may be
> *better* didactically to focus on lm()  in the very first
> example, and use data frames in a next one ...
>  and instead of next one, we have the pretty clear comment
> 
>  ### less simple examples in "See Also" above
> 
> I'm not convinced (but you can try more) we should change those
> examples or add more there.
> 
> Martin
> 
>> On Fri, 14 Dec 2018 at 14:51, S Ellison
>>  wrote:
> 
>>> FWIW, before all the examples are changed to data frame
>>> variants, I think there's fairly good reason to have at
>>> least _one_ example that does _not_ place variables in a
>>> data frame.
>>> 
>>> The data argument in lm() is optional. And there is more
>>> than one way to manage data in a project. I personally
>>> don't much like lots of stray variables lurking about,
>>> but if those are the only variables out there and we can
>>> be sure they aren't affected by other code, it's hardly
>>> essential to create a data frame to hold something you
>>> already have.  Also, attach() is still part of R, for
>>> those folk who have a data frame but want to reference
>>> the contents across a wider range of functions without
>>> using with() a lot. lm() can reasonably omit the data
>>> argument there, too.
>>> 
>>> So while there are good reasons to use data frames, there
>>> are also good reasons to provide examples that don't.
>>> 
>>> Steve Ellison
>>> 
>>> 
 -Original Message- > From: R-devel
>>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Ben >
>>> Bolker > Sent: 13 December 2018 20:36 > To:
>>> r-devel@r-project.org > Subject: Re: [Rd] Documentation
>>> examples for lm and glm
 
 
 Agree.  Or just create the data frame with those
>>> variables in it > directly ...
 
 On 2018-12-13 3:26 p.m., Thomas Yee wrote: > > Hello,
> 
> something that has been on my mind for a decade or
>>> two has > > been the examples for lm() and glm(). They
>>> encourage poor style > > because of mismanagement of data
>>> frames. Also, having the > > variables in a data frame
>>> means that predict() > > is more likely to work properly.
> 
> For lm(), the variables should be put into a data
>>> frame.  > > As 2 vectors are assigned first in the
>>> general workspace they > > should be deleted afterwards.
> 
> For the glm(), the data frame d.AD is constructed but
>>> not used. Also, > > its 3 components were assigned first
>>> in the general workspace, so they > > float around
>>> dangerously afterwards like in the lm() example.
> 
> Rather than attached improved .Rd files here, they
>>> are put at > > www.stat.auckland.ac.nz/~yee/Rdfiles > >
>>> You are welcome to use them!
> 
> Best,
> 
> Thomas
> 
> __ > >
>>> 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
>>> 
>>> 
>>> ***
>>> This email and any attachments are confidential. Any
>>> 

[Bioc-devel] Undefined slot classes warning

[Vladimir Kiselev]

Hello,

We have a warning related to defining an S4 object:
Warning: undefined slot classes in definition of "MyObject": index(class
"Rcpp_ModuleClass")

More details are here:
https://stackoverflow.com/questions/53814548/rcpp-class-wrapped-in-s4-object-warning

Could anyone please help?

Many thanks,
Vladimir

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] ClassifyR Check Error on Linux and MacOS Systems

[Shepherd, Lori]

Thank you.  I thought we had a BiocCheck for browser that would print a clearer 
message.  I will look into this but thank you for correcting your package.


Cheers,


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Dario Strbenac 

Sent: Monday, December 17, 2018 3:00:02 AM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] ClassifyR Check Error on Linux and MacOS Systems

Good day,

Thanks for running it. I found the error you had happens because of an example 
which used random sampling and rarely returned a zero-length result. I have 
made the example deterministic so that it always succeeds.

The error you saw is not related to the problem seen on the build servers, 
though. I found a browser() inside an R function which I forgot to remove 
before committing. After removal and committal, the error on malbec1 and 
merida1 is gone. It is surprising that it did not trigger an error when 
checking the package before committing it and that the error message observed 
on the build servers was not clear about what the problem was.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
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: [Rd] Documentation examples for lm and glm

[Martin Maechler]

> David Hugh-Jones 
> on Sat, 15 Dec 2018 08:47:28 +0100 writes:

> I would argue examples should encourage good
> practice. Beginners ought to learn to keep data in data
> frames and not to overuse attach(). 

Note there's no attach() there in any of these examples!

> otherwise at their own risk, but they have less need of
> explicit examples.

The glm examples are nice in sofar they show both uses.

I agree the lm() example(s) are  "didactically misleading" by
not using data frames at all.

I disagree that only data frame examples should be shown.
If  lm()  is one of the first R functions a beginneR must use --
because they are in a basic stats class, say --  it may be
*better* didactically to focus on lm()  in the very first
example, and use data frames in a next one ...
 and instead of next one, we have the pretty clear comment
 
  ### less simple examples in "See Also" above

I'm not convinced (but you can try more) we should change those
examples or add more there.

Martin

> On Fri, 14 Dec 2018 at 14:51, S Ellison
>  wrote:

>> FWIW, before all the examples are changed to data frame
>> variants, I think there's fairly good reason to have at
>> least _one_ example that does _not_ place variables in a
>> data frame.
>> 
>> The data argument in lm() is optional. And there is more
>> than one way to manage data in a project. I personally
>> don't much like lots of stray variables lurking about,
>> but if those are the only variables out there and we can
>> be sure they aren't affected by other code, it's hardly
>> essential to create a data frame to hold something you
>> already have.  Also, attach() is still part of R, for
>> those folk who have a data frame but want to reference
>> the contents across a wider range of functions without
>> using with() a lot. lm() can reasonably omit the data
>> argument there, too.
>> 
>> So while there are good reasons to use data frames, there
>> are also good reasons to provide examples that don't.
>> 
>> Steve Ellison
>> 
>> 
>> > -Original Message- > From: R-devel
>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Ben >
>> Bolker > Sent: 13 December 2018 20:36 > To:
>> r-devel@r-project.org > Subject: Re: [Rd] Documentation
>> examples for lm and glm
>> >
>> >
>> > Agree.  Or just create the data frame with those
>> variables in it > directly ...
>> >
>> > On 2018-12-13 3:26 p.m., Thomas Yee wrote: > > Hello,
>> > >
>> > > something that has been on my mind for a decade or
>> two has > > been the examples for lm() and glm(). They
>> encourage poor style > > because of mismanagement of data
>> frames. Also, having the > > variables in a data frame
>> means that predict() > > is more likely to work properly.
>> > >
>> > > For lm(), the variables should be put into a data
>> frame.  > > As 2 vectors are assigned first in the
>> general workspace they > > should be deleted afterwards.
>> > >
>> > > For the glm(), the data frame d.AD is constructed but
>> not used. Also, > > its 3 components were assigned first
>> in the general workspace, so they > > float around
>> dangerously afterwards like in the lm() example.
>> > >
>> > > Rather than attached improved .Rd files here, they
>> are put at > > www.stat.auckland.ac.nz/~yee/Rdfiles > >
>> You are welcome to use them!
>> > >
>> > > Best,
>> > >
>> > > Thomas
>> > >
>> > > __ > >
>> 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
>> 
>> 
>> ***
>> This email and any attachments are confidential. Any
>> u...{{dropped:12}}

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

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

Re: [Rd] Function I mean not to export keeps being documented in a manual?

[Thierry Onkelinx via R-devel]

Dear Marta,

Add the @noRd tag to the Roxygen documentation of the function.

Best regards,

ir. Thierry Onkelinx
Statisticus / Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkel...@inbo.be
Havenlaan 88 bus 73, 1000 Brussel
www.inbo.be

///
To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey
///




Op ma 17 dec. 2018 om 08:57 schreef Marta Karaś :

> I am developing an R package which has a function I decided not to export.
> I believe the roxygen information states that the function is not going to
> be exported, yet I still see the function in the manual PDF (as generated
> in command line via `CMD Rd2pdf package_dir`). What is wrong with my
> preamble that the function is still being documented in a manual?
>
> #' Generates plots for demo of package functions which take time series and
> #' window width parameters
> #'
> #' @param func runstats package core function
> #' @param plt.title.vec vector of function-specific plot titles
> #'
> #' @importFrom grDevices rgb
> #' @importFrom graphics abline lines par plot points polygon title
> #'
> #' @return \code{NULL}
> #'
> #' @examples
> #' \dontrun{
> #' func <- RunningMean
> #' vec <- c("black: x\nred: W-width running window",
> #'  "RunningMean(x, W)",
> #'  "RunningMean(x, W, circular = TRUE)")
> #' plot.no.pattern(func, vec)
> #' }
> #'
> #'
> plot.no.pattern <- function(func, plt.title.vec){
> ...
> }
>
> Bests / Pozdrawiam,
> Marta Karas
>
> [[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

Re: [Bioc-devel] ClassifyR Check Error on Linux and MacOS Systems

[Dario Strbenac]

Good day,

Thanks for running it. I found the error you had happens because of an example 
which used random sampling and rarely returned a zero-length result. I have 
made the example deterministic so that it always succeeds.

The error you saw is not related to the problem seen on the build servers, 
though. I found a browser() inside an R function which I forgot to remove 
before committing. After removal and committal, the error on malbec1 and 
merida1 is gone. It is surprising that it did not trigger an error when 
checking the package before committing it and that the error message observed 
on the build servers was not clear about what the problem was.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel