Re: [Bioc-devel] Forking out modules from existing packages as new packages

[Shian Su]

Hi Koustav,

My opinion on this is to split the visualisations out into a separate package 
but keep the functions in the existing package. Then when the new visualisation 
package is released, depend on it from the existing package.

It’s worth asking: Is the package actually worth splitting up? If the two 
packages are interdependent as a workflow, i.e. if the visualisations apply 
only to data produced by the specific methods, then there’s no reason to split 
them up.

This happens quite often in package development. The goal is to not let users 
of your existing package lose any functionality when installing new versions of 
your package because those functions went to another package.

Kind regards,
Shian

Shian Su
PhD Student, Ritchie Lab, Epigenetics and Development
Walter & Eliza Hall Institute of Medical Research
1G Royal Parade, Parkville VIC 3052, Australia

On 23 Aug 2019, at 10:08 pm, Koustav Pal 
mailto:koustav@ifom.eu>> wrote:

Hi,

I have a curious scenario, I have a package which has some visualisation 
modules. But, as package development progresses, I think that possibly the 
visualisation modules themselves might deserve a package for themselves. This 
would imply,

1. Removing the aforementioned modules from the first package
2. Making a new package for these modules and submitting a new package to 
Bioconductor.

Has this been done before? What are the best practices? To remove the modules 
entirely? Or to preserve the old ones in the package while continuing 
development of the new package?

Is it then possible to create a suite-like package, similar to tidyverse, where 
users say BiocManager::install(“Set_of_bla_bla_packages”)?

Koustav Pal, PhD
Post-Doctoral Fellow in Genome Architecture,
Computational Genomics Group,
IFOM - The FIRC Institute of Molecular Oncology,
Via Adamello 16,
20139 Milano, Italy.
Phone: +393441130157
E-mail: koustav@ifom.eu




[[alternative HTML version deleted]]

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


___

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] Samtools dependency

[Jonathon Hill]

Yes, gladly. Thank you for taking time to help me. Here is the exact line of R 
code where we build the samtools command (the file to be tested is added later):

args <- paste("mpileup -ERI",   #Redo Baq, ignore readgroups, and skip indels
 "-f", refFasta(param),
 "-C 50",
 "--min-MQ", minMapQuality(param),
 "--min-BQ", minBaseQuality(param),
 "--region", as.character(chrRange, ignore.strand=TRUE))

As you can see, we use the BAQ score to filter. We have tried to implement it 
without BAQ (using Rsamtools) and found it negatively affected our results.

> On Aug 23, 2019, at 4:53 PM, Martin Morgan  wrote:
> 
> can you provide an example of the samtools command line that you evaluate?
> 
> On 8/23/19, 6:11 PM, "Bioc-devel on behalf of Jonathon Hill" 
>  wrote:
> 
>I had not until today. I spent the afternoon looking at the possibility, 
> and it looks like it would be beyond my lab’s skills. We do not have anyone 
> comfortable in C, as we do everything in R. The problem is that we need to 
> get the results of the mpileup command with BAQ score. Although it has a 
> pileup command, the Rsamtools implementation does not include the ability to 
> retrieve the BAQ score as far as we can tell, so we had to fall back on 
> making a system call to Rsamtools and reading in the results. Using Rhtslib 
> is intriguing, but it looks like we would need several header files in 
> Samtools as opposed to htslib and then implement our own C function. Again, 
> we do not have anyone that could do this. We are scientists, not programmers. 
> Am I correct on what it would require? Do you know of any other alternatives? 
> 
>Jonathon
> 
>> On Aug 23, 2019, at 12:22 PM, Pages, Herve  wrote:
>> 
>> Hi Jonathon,
>> 
>> Have you considered depending on Rhtslib? See 
>> https://bioconductor.org/packages/Rhtslib
>> 
>> Rsamtools itself is implemented on top of Rhtslib. Note that other 
>> Bioconductor packages (e.g. DiffBind, deepSNV, BitSeq, qrqc, QuasR, 
>> seqbias, TransView, etc...) use Rhtslib internally to implement features 
>> not implemented in Rsamtools.
>> 
>> H.
>> 
>> On 8/23/19 11:05, Jonathon Hill wrote:
>>> Hi,
>>> 
>>> I am working through the process of submitting a new package (MMAPPR2). We 
>>> are having a problem with the build failing, because our package requires 
>>> Samtools installed. We cannot use Rsamtools, as we depend on features not 
>>> implemented in the package. How do we resolve the issue? What is the policy 
>>> for system dependencies? We have samtools listed in the DESCRIPTION and 
>>> installation instructions in our README, but I am sure that is not enough 
>>> to get it installed on the Build and Check servers.
>>> 
>>> Thanks,
>>> 
>>> Jonathon Hill
>>> 
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=AEKZKMjjFTbu5U_zn0bacvzv69lx_S5s7Yb6dSOXbJs=s5EMLCdAbnqgXWs3_-Sxm52Zuc3pqFirWz7z3ymBruU=
>>> 
>> 
>> -- 
>> 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
> 
>___
>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] Samtools dependency

[Martin Morgan]

can you provide an example of the samtools command line that you evaluate?

On 8/23/19, 6:11 PM, "Bioc-devel on behalf of Jonathon Hill" 
 wrote:

I had not until today. I spent the afternoon looking at the possibility, 
and it looks like it would be beyond my lab’s skills. We do not have anyone 
comfortable in C, as we do everything in R. The problem is that we need to get 
the results of the mpileup command with BAQ score. Although it has a pileup 
command, the Rsamtools implementation does not include the ability to retrieve 
the BAQ score as far as we can tell, so we had to fall back on making a system 
call to Rsamtools and reading in the results. Using Rhtslib is intriguing, but 
it looks like we would need several header files in Samtools as opposed to 
htslib and then implement our own C function. Again, we do not have anyone that 
could do this. We are scientists, not programmers. Am I correct on what it 
would require? Do you know of any other alternatives? 

Jonathon

> On Aug 23, 2019, at 12:22 PM, Pages, Herve  wrote:
> 
> Hi Jonathon,
> 
> Have you considered depending on Rhtslib? See 
> https://bioconductor.org/packages/Rhtslib
> 
> Rsamtools itself is implemented on top of Rhtslib. Note that other 
> Bioconductor packages (e.g. DiffBind, deepSNV, BitSeq, qrqc, QuasR, 
> seqbias, TransView, etc...) use Rhtslib internally to implement features 
> not implemented in Rsamtools.
> 
> H.
> 
> On 8/23/19 11:05, Jonathon Hill wrote:
>> Hi,
>> 
>> I am working through the process of submitting a new package (MMAPPR2). 
We are having a problem with the build failing, because our package requires 
Samtools installed. We cannot use Rsamtools, as we depend on features not 
implemented in the package. How do we resolve the issue? What is the policy for 
system dependencies? We have samtools listed in the DESCRIPTION and 
installation instructions in our README, but I am sure that is not enough to 
get it installed on the Build and Check servers.
>> 
>> Thanks,
>> 
>> Jonathon Hill
>> 
>> ___
>> Bioc-devel@r-project.org mailing list
>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=AEKZKMjjFTbu5U_zn0bacvzv69lx_S5s7Yb6dSOXbJs=s5EMLCdAbnqgXWs3_-Sxm52Zuc3pqFirWz7z3ymBruU=
>> 
> 
> -- 
> 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

___
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] Samtools dependency

[Jonathon Hill]

I had not until today. I spent the afternoon looking at the possibility, and it 
looks like it would be beyond my lab’s skills. We do not have anyone 
comfortable in C, as we do everything in R. The problem is that we need to get 
the results of the mpileup command with BAQ score. Although it has a pileup 
command, the Rsamtools implementation does not include the ability to retrieve 
the BAQ score as far as we can tell, so we had to fall back on making a system 
call to Rsamtools and reading in the results. Using Rhtslib is intriguing, but 
it looks like we would need several header files in Samtools as opposed to 
htslib and then implement our own C function. Again, we do not have anyone that 
could do this. We are scientists, not programmers. Am I correct on what it 
would require? Do you know of any other alternatives? 

Jonathon

> On Aug 23, 2019, at 12:22 PM, Pages, Herve  wrote:
> 
> Hi Jonathon,
> 
> Have you considered depending on Rhtslib? See 
> https://bioconductor.org/packages/Rhtslib
> 
> Rsamtools itself is implemented on top of Rhtslib. Note that other 
> Bioconductor packages (e.g. DiffBind, deepSNV, BitSeq, qrqc, QuasR, 
> seqbias, TransView, etc...) use Rhtslib internally to implement features 
> not implemented in Rsamtools.
> 
> H.
> 
> On 8/23/19 11:05, Jonathon Hill wrote:
>> Hi,
>> 
>> I am working through the process of submitting a new package (MMAPPR2). We 
>> are having a problem with the build failing, because our package requires 
>> Samtools installed. We cannot use Rsamtools, as we depend on features not 
>> implemented in the package. How do we resolve the issue? What is the policy 
>> for system dependencies? We have samtools listed in the DESCRIPTION and 
>> installation instructions in our README, but I am sure that is not enough to 
>> get it installed on the Build and Check servers.
>> 
>> Thanks,
>> 
>> Jonathon Hill
>> 
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=AEKZKMjjFTbu5U_zn0bacvzv69lx_S5s7Yb6dSOXbJs=s5EMLCdAbnqgXWs3_-Sxm52Zuc3pqFirWz7z3ymBruU=
>> 
> 
> -- 
> 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

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

[Bioc-devel] Error: DLL 'rgl' not found: maybe not installed for this architecture?

[Venu Thatikonda]

Hi,

During one of my R packages bioc review, I see the following 2 errors,

one:

Error in library.dynam(dynlib, pkg, lib) :
  DLL 'rgl' not found: maybe not installed for this architecture?
Error: .onLoad failed in loadNamespace() for 'rgl', details:
  call: NULL
  error:Loading rgl's DLL failed.
Execution halted
ERROR: lazy loading failed for package 'ALPS'
* removing 
'C:/Users/pkgbuild/packagebuilder/workers/jobs/1215/2a61338/ALPS.buildbin-libdir/ALPS'

I'm not using any functions from 'rgl', not sure why it is a required
dependency. Or is there any key detail am I missing? R CMD build, check
BiocCheck are very clean on my system.

Two:

* ERROR: System Files found that should not be git tracked:
ALPS.Rproj


Based on this discussion (
https://community.rstudio.com/t/should-rproj-files-be-added-to-gitignore/1269),
it is in fact a bit useful not adding PACKAGE.Rproj to .gitignore. Do all
bioc packages require adding *Rproj to gitignore?

Here is the report, if it's helpful.

http://bioconductor.org/spb_reports/ALPS_buildreport_20190823145032.html

Thank you & have a ncie day!

-- 
Best regards
Venu Thatikonda
https://itsvenu.github.io/

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Samtools dependency

[Pages, Herve]

Hi Jonathon,

Have you considered depending on Rhtslib? See 
https://bioconductor.org/packages/Rhtslib

Rsamtools itself is implemented on top of Rhtslib. Note that other 
Bioconductor packages (e.g. DiffBind, deepSNV, BitSeq, qrqc, QuasR, 
seqbias, TransView, etc...) use Rhtslib internally to implement features 
not implemented in Rsamtools.

H.

On 8/23/19 11:05, Jonathon Hill wrote:
> Hi,
> 
> I am working through the process of submitting a new package (MMAPPR2). We 
> are having a problem with the build failing, because our package requires 
> Samtools installed. We cannot use Rsamtools, as we depend on features not 
> implemented in the package. How do we resolve the issue? What is the policy 
> for system dependencies? We have samtools listed in the DESCRIPTION and 
> installation instructions in our README, but I am sure that is not enough to 
> get it installed on the Build and Check servers.
> 
> Thanks,
> 
> Jonathon Hill
> 
> ___
> Bioc-devel@r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIFAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=AEKZKMjjFTbu5U_zn0bacvzv69lx_S5s7Yb6dSOXbJs=s5EMLCdAbnqgXWs3_-Sxm52Zuc3pqFirWz7z3ymBruU=
> 

-- 
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
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] problem with R CMD check

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

For a new release of survival, I normally run  R CMD check for every one of the 
packages 
that depend on survival  (forewarned is forearmed).

I updated R-devel on the test machine this morning, and R CMD check --as-cran 
survival_3.0-9.tar.gz works as desired.

When I run the check routine on any other source file, however, downloaded from 
CRAN, it 
fails nearly immediately with a message like the following.

* installing *source* package ‘addhazard’ ...
** package ‘addhazard’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** data
*** moving datasets to lazyload DB
** byte-compile and prepare package for lazy loading
==5550==ASan runtime does not come first in initial library list; you should eit
her link runtime to your application or manually preload it with LD_PRELOAD.
ERROR: lazy loading failed for package ‘addhazard’
*

---

Here is my Makevars file.  (The commented out lines are from an earlier date 
when I did 
use ASAN to find a memory leak.)
CFLAGS=  -g -O2 -Wall -pedantic -mtune=native

# Use the lines below for ASAN code
#CC= gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer
#CFLAGS=  -fno-omit-frame-pointer -g -O2 -Wall -pedantic -mtune=native
#CXX = g++ -fsanitize=address -fno-omit-frame-pointer

---
Any hints?   If all packages failed I would figure I had a global mistake, but 
why most?

Terry T.

 > sessionInfo()
R Under development (unstable) (2019-08-23 r77061)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.3 LTS

Matrix products: default
BLAS:   /usr/local/src/R-devel/lib/libRblas.so
LAPACK: /usr/local/src/R-devel/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8    LC_COLLATE=C
  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods base

loaded via a namespace (and not attached):
[1] compiler_3.7.0



[[alternative HTML version deleted]]

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

[Bioc-devel] Samtools dependency

[Jonathon Hill]

Hi,

I am working through the process of submitting a new package (MMAPPR2). We are 
having a problem with the build failing, because our package requires Samtools 
installed. We cannot use Rsamtools, as we depend on features not implemented in 
the package. How do we resolve the issue? What is the policy for system 
dependencies? We have samtools listed in the DESCRIPTION and installation 
instructions in our README, but I am sure that is not enough to get it 
installed on the Build and Check servers.

Thanks,

Jonathon Hill

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

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hi Georgi,

Thanks for this pointer.  My guess at this point is that I've found a bug
(or maybe a couple of bugs with 'utils::prompt()' and with the Rd to help
conversion), but let me know if you think otherwise.

I just did that way, and the usage lines that were generated by
'utils::prompt()' and copied into the docs are:

topic_long_table_header(x, col_names = NULL,
  above_col_names = "\\hline", below_col_names = "\\hline",
  subsequent_page_notification = "\\ldots continued",
  latex_header = NULL, verbatim = NULL)

topic_long_table_footer(x, bottom_border = "\\hline",
  bottom_all_pages = NULL, bottom_last_page = NULL,
  subsequent_page_notification = "continued \\ldots",
  verbatim = NULL)

It is giving a very similar error with 'R CMD check' (outside devtools).
The escape of the backslashes appears to be needed, but "\\ldots" continues
to be translated into "...":

Codoc mismatches from documentation object 'topic_long_table_header':
topic_long_table_header
  Code: function(x, col_names = NULL, above_col_names = "\\hline",
 below_col_names = "\\hline",
 subsequent_page_notification = "\\ldots continued",
 latex_header = NULL, verbatim = NULL)
  Docs: function(x, col_names = NULL, above_col_names = "\hline",
 below_col_names = "\hline",
 subsequent_page_notification = "... continued",
 latex_header = NULL, verbatim = NULL)
  Mismatches in argument default values:
Name: 'above_col_names' Code: "\\hline" Docs: "\hline"
Name: 'below_col_names' Code: "\\hline" Docs: "\hline"
Name: 'subsequent_page_notification' Code: "\\ldots continued" Docs:
"... continued"
topic_long_table_footer
  Code: function(x, bottom_border = "\\hline", bottom_all_pages = NULL,
 bottom_last_page = NULL, subsequent_page_notification
 = "continued \\ldots", verbatim = NULL)
  Docs: function(x, bottom_border = "\hline", bottom_all_pages = NULL,
 bottom_last_page = NULL, subsequent_page_notification
 = "continued ...", verbatim = NULL)
  Mismatches in argument default values:
Name: 'bottom_border' Code: "\\hline" Docs: "\hline"
Name: 'subsequent_page_notification' Code: "continued \\ldots" Docs:
"continued ..."

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov  
Sent: Friday, August 23, 2019 11:27 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Bill,

Sorry, I misunderstood the question.

To check if the problem is with R's tools, run
'utils::prompt(topic_long_table_header)" and see the usage section of the
generated file. Presumably, this should be the 'canonical way' to write the
usage entry for the function.
You can copy and paste it in the Rd file generated by roxygen2, then run 'R
CMD build' and 'R CMD check' (outside devtools). 

Georgi


-Original Message-
From: b...@denney.ws [mailto:b...@denney.ws]
Sent: 23 August 2019 15:27
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,
above_col_names="\\hline",
below_col_names="\\hline",
subsequent_page_notification="\\ldots
continued",
latex_header=NULL) {
  # The function body
}
--

So, I'm not trying to use LaTeX in the .Rd file; I'm trying to use it in R,
and I'm then copying it into the .Rd with extra escaping for the backslashes
(well, roxygen2 is doing the extra escaping).

Rd text
--
topic_long_table_header(x, col_names = NULL,
  above_col_names = "hline", below_col_names = "hline",
  subsequent_page_notification = "ldots continued",
  latex_header = NULL)
--

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov 
Sent: Friday, August 23, 2019 9:52 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Rd is not LaTeX, although it resembles it.  You should use only markup
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to 

Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[Georgi Boshnakov]

Hi Bill,

Sorry, I misunderstood the question.

To check if the problem is with R's tools, run 
'utils::prompt(topic_long_table_header)" and see the usage section of the 
generated file. Presumably, this should be the 'canonical way' to write the 
usage entry for the function.
You can copy and paste it in the Rd file generated by roxygen2, then run 'R CMD 
build' and 'R CMD check' (outside devtools). 

Georgi


-Original Message-
From: b...@denney.ws [mailto:b...@denney.ws] 
Sent: 23 August 2019 15:27
To: Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,
above_col_names="\\hline",
below_col_names="\\hline",
subsequent_page_notification="\\ldots
continued",
latex_header=NULL) {
  # The function body
}
--

So, I'm not trying to use LaTeX in the .Rd file; I'm trying to use it in R,
and I'm then copying it into the .Rd with extra escaping for the backslashes
(well, roxygen2 is doing the extra escaping).

Rd text
--
topic_long_table_header(x, col_names = NULL,
  above_col_names = "hline", below_col_names = "hline",
  subsequent_page_notification = "ldots continued",
  latex_header = NULL)
--

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov  
Sent: Friday, August 23, 2019 9:52 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Rd is not LaTeX, although it resembles it.  You should use only markup
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hi Georgi,

I'm not trying to use it as part of my documentation, it is one of my
function arguments.  I want the function argument to be displayed correctly
in the help, but it is not.  I'm curious how I should document the
"subsequent_page_notification" function argument in Rd.

Specifically, the actual function definition (R code) looks like:

R code:
--
topic_long_table_header <- function(x,
col_names=NULL,
above_col_names="\\hline",
below_col_names="\\hline",
subsequent_page_notification="\\ldots
continued",
latex_header=NULL) {
  # The function body
}
--

So, I'm not trying to use LaTeX in the .Rd file; I'm trying to use it in R,
and I'm then copying it into the .Rd with extra escaping for the backslashes
(well, roxygen2 is doing the extra escaping).

Rd text
--
topic_long_table_header(x, col_names = NULL,
  above_col_names = "hline", below_col_names = "hline",
  subsequent_page_notification = "ldots continued",
  latex_header = NULL)
--

Thanks,

Bill

-Original Message-
From: Georgi Boshnakov  
Sent: Friday, August 23, 2019 9:52 AM
To: b...@denney.ws; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Rd is not LaTeX, although it resembles it.  You should use only markup
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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: [R-pkg-devel] Literal LaTeX Text in Function Arguments

[Georgi Boshnakov]

Rd is not LaTeX, although it resembles it.  You should use only markup 
described in WRE.
For example, \dots is for the use case you mention. 

Georgi Boshnakov





-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf 
Of b...@denney.ws
Sent: 23 August 2019 04:15
To: r-package-devel@r-project.org
Subject: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[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] No protocol specified

[Dr. rer. nat. Michael Thrun]

Dear All,
I updated my package DataVisualizations and get a note, only for 
"r-release-osx-x86_64” and “r-oldrel-osx-x86_64”

Checking dependencies in R code ... NOTE
No protocol specified

Can anyone translate this note to me in a way that I know what the issue is?

Best Regards
Michael


Michael Thrun
Postdoctoral Scholar
Databionics AG,
Mathematics and Computer Science

Philipps-Universität Marburg
Hans-Meerwein-Straße 6, 04A28
D-35032 Marburg

Phone +49 6421/ 28 23922
www.uni-marburg.de/fb12/datenbionik/

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

[R-pkg-devel] Literal LaTeX Text in Function Arguments

[bill]

Hello,

 

Does anyone know how to include verbatim \ldots (and maybe other LaTeX) in
an .Rd file correctly? 

 

When LaTeX is in the default arguments for a function, the code is
interpreted which makes the documentation not match the default formal
arguments.

 

An example is:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/R/topic_long_table_header_footer.R#L20

 

Which yields:

https://github.com/billdenney/TopicLongTableR/blob/1338116767d90e8211533cb6e
7db5ef30368dc33/man/topic_long_table_header.Rd#L10

 

Which gives the following warning with `devtools::check()`:

```

checking for code/documentation mismatches ... WARNING

Codoc mismatches from documentation object 'topic_long_table_header':

topic_long_table_header

  Code: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\\ldots continued
 ",

 latex_header = NULL)

  Docs: function(x, col_names = NULL, above_col_names = "\\hline
 ",

 below_col_names = "\\hline  ",

 subsequent_page_notification = "\... continued",

 latex_header = NULL)

```

 

I'm not sure, but I think that the solution is to add more protection to the
\s when generating the roxygen or perhaps wrapping the arguments in some
form of verbatim block (if it's available).

 

Thanks,

 

Bill

 

P.S. This is also discussed in https://github.com/r-lib/roxygen2/issues/837
where it appears to be related to the conversion of .Rd to help files not
the roxygen step.

 


[[alternative HTML version deleted]]

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

[Bioc-devel] Forking out modules from existing packages as new packages

[Koustav Pal]

Hi,

I have a curious scenario, I have a package which has some visualisation 
modules. But, as package development progresses, I think that possibly the 
visualisation modules themselves might deserve a package for themselves. This 
would imply, 

1. Removing the aforementioned modules from the first package
2. Making a new package for these modules and submitting a new package to 
Bioconductor. 

Has this been done before? What are the best practices? To remove the modules 
entirely? Or to preserve the old ones in the package while continuing 
development of the new package? 

Is it then possible to create a suite-like package, similar to tidyverse, where 
users say BiocManager::install(“Set_of_bla_bla_packages”)?

Koustav Pal, PhD
Post-Doctoral Fellow in Genome Architecture,
Computational Genomics Group,
IFOM - The FIRC Institute of Molecular Oncology,
Via Adamello 16,
20139 Milano, Italy.
Phone: +393441130157
E-mail: koustav@ifom.eu




[[alternative HTML version deleted]]

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