Re: [R-pkg-devel] Linking with software dependencies

[Sameh M. Abdulah]

Thanks Dirk for your answers. However, I am still confuse about the linking 
problem in question (2).  Is there anyway to set the pkg_config_path  instead 
of using the set_env function?

—Sameh


Get Outlook for iOS

From: Dirk Eddelbuettel 
Sent: Saturday, August 24, 2019 9:48 PM
To: Sameh M. Abdulah
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Linking with software dependencies


On 24 August 2019 at 18:16, Sameh M. Abdulah wrote:
| (1) My package requires a pre-installation of Intel MKL. Is there any way to 
include the MKL installation with the package.

This (or a related) question was discussed here (or on a related list ?)
very recently. The recommendation, that I concur with, was NOT to do
that. BLAS and LAPACK are standard interfaces. Strive to support these
standards, and if and only if you find a more performant alternative
installed, use that. In short you need to write `configure` code to sort out
the environment into which your package tries to install. Somewhat
moderately difficult but doable, and there are examples in other packages.

| (2) The package depends on several c-based software which I automatically 
install through the package installation. Linking with these dependencies is a 
necessity. Thus, I did a simple trick for that as follows,
| - I am installing all the software dependencies inside the default 
installation directory of the r-package then I am adding this path to the 
(PKG_CONFIG_PATH env) using this statement,
| 
Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))
| By this way, I will be sure that all libraries are accessible by the package.
| - Then, the installation can be done using install_git(url=" 
https://github.com/ecrc/exageostatR";) for the GitHub repo.
| The problem that I need to avoid the manual setting of the (PKG_CONFIG_PATH) 
so that I can, for example, upload my package to CRAN and simplify the 
installation process. I am doing the dependencies installation using the 
package configure file which can be accessed through 
https://github.com/ecrc/exageostatR/blob/master/configure.

In short, this is a somewhat common but still difficult problem. We are
crossing over from R applications and packages to OS-level library provision.

A recent entry to this debate is an attempt in one CRAN package which (on
some platforms) discovers a YES or NO at installation time and then pivots
between a full and a rather limited installation. To me this follows at best
the letter of the law, but not so much the spirit. Oh well. It's on CRAN so
must be good enough.

Then again, the problem is difficult. I too have two candidate packages based
on solid work with other collaborators which I cannot get onto CRAN for lack
of library support, in particular on one somewhat non-maintained platform.
This is, to put it plainly, somewhat frustrating.

There is another approach which I have used with some packages. Prebuild
libraries (or binaries) and fetch them at installation time. Better than
nothing and results in working package but arguably still not ideal.

| (3) My package is only compatible with Linux and macOS. How to avoid CRAN 
windows checks.

That's easier. Look at the documentation for the "OS_type:" field in the
DESCRIPTION file in the _Writing R Extensions_ manual that is your reference
for all these topics.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

[[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] NAMESPACE issue and grDevices

[Duncan Murdoch]

On 24/08/2019 10:36 a.m., Kevin Coombes wrote:

Hi,

I've been building a package and hit a NAMESPACE issue that took a while
to resolve.

My package implements a (new) generic function, and the method for a
package in the class calls the "smoothScatter" function from the
"graphics" package. I could build and install the package successfully,
and when I used the generic function, it worked just fine.

However, when I ran "R CMD check --as-cran", it threw an error from both
the examples in man pages and a test script. Specifically, the error was
"package KernSmooth not available". I eventually worked around this
problem by changing the DESCRIPTION file to "IMPORT KernSmooth" (even
though I didn't have to actually import anything in "NAMESPACE").

The underlying issue appears to be that
      graphics::smoothScatter
calls a non-exported function from "grDevices"
   grDevices:::.smoothScatterCalcDensity
which in turn calls an explicitly qualified function from "KernSmooth"
      KernSmooth::bkde2D


That looks like a bug in grDevices.  If it suggests KernSmooth, it 
should explicitly check whether it is installed before calling a 
function from it.




To complicate matters
      graphics IMPORTs grDevices
but
      grDevices only SUGGESTs KernSmooth.

Since my package already IMPORTed the graphics package and had
      importFrom("graphics", "smoothScatter")
in the NAMESPACE, I was surprised that I had to track back through the
code to find this dependency and had to make it explicitly known within
the interface to my package.

Is there something else my package should do? Or should "grDevices"
actually IMPORT "KernSmooth"?


It could import it, or it could put in a check and a workaround if it is 
not found.


Now that you know about this bug, you could work around it by suggesting 
KernSmooth, and not calling graphics::smoothScatter unless KernSmooth is 
available.


Duncan Murdoch


Best,
    Kevin

__
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] Linking with software dependencies

[Dirk Eddelbuettel]

On 24 August 2019 at 18:16, Sameh M. Abdulah wrote:
| (1) My package requires a pre-installation of Intel MKL. Is there any way to 
include the MKL installation with the package.

This (or a related) question was discussed here (or on a related list ?)
very recently. The recommendation, that I concur with, was NOT to do
that. BLAS and LAPACK are standard interfaces. Strive to support these
standards, and if and only if you find a more performant alternative
installed, use that.  In short you need to write `configure` code to sort out
the environment into which your package tries to install.  Somewhat
moderately difficult but doable, and there are examples in other packages.
 
| (2) The package depends on several c-based software which I automatically 
install through the package installation. Linking with these dependencies is a 
necessity. Thus, I did a simple trick for that as follows,
| - I am installing all the software dependencies inside the default 
installation directory of the r-package then I am adding this path to the 
(PKG_CONFIG_PATH env) using this statement,
| 
Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))
| By this way, I will be sure that all libraries are accessible by the package.
| - Then, the installation can be done using install_git(url=" 
https://github.com/ecrc/exageostatR";) for the GitHub repo.
| The problem that I need to avoid the manual setting of the (PKG_CONFIG_PATH) 
so that I can, for example, upload my package to CRAN and simplify the 
installation process. I am doing the dependencies installation using the 
package configure file which can be accessed through 
https://github.com/ecrc/exageostatR/blob/master/configure.

In short, this is a somewhat common but still difficult problem. We are
crossing over from R applications and packages to OS-level library provision.

A recent entry to this debate is an attempt in one CRAN package which (on
some platforms) discovers a YES or NO at installation time and then pivots
between a full and a rather limited installation.  To me this follows at best
the letter of the law, but not so much the spirit. Oh well.  It's on CRAN so
must be good enough.

Then again, the problem is difficult. I too have two candidate packages based
on solid work with other collaborators which I cannot get onto CRAN for lack
of library support, in particular on one somewhat non-maintained platform.
This is, to put it plainly, somewhat frustrating.

There is another approach which I have used with some packages.  Prebuild
libraries (or binaries) and fetch them at installation time.  Better than
nothing and results in working package but arguably still not ideal.

| (3) My package is only compatible with Linux and macOS. How to avoid CRAN 
windows checks.

That's easier.  Look at the documentation for the "OS_type:" field in the
DESCRIPTION file in the _Writing R Extensions_ manual that is your reference
for all these topics.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] Linking with software dependencies

[Sameh M. Abdulah]

Hi,

First, I am inviting all of you to try our recent package at 
https://github.com/ecrc/exageostatR. This package involves MLE estimation in 
large scale using leading-edge hardware architectures.

I have multiple questions:

(1) My package requires a pre-installation of Intel MKL. Is there any way to 
include the MKL installation with the package.

(2) The package depends on several c-based software which I automatically 
install through the package installation. Linking with these dependencies is a 
necessity. Thus, I did a simple trick for that as follows,
- I am installing all the software dependencies inside the default installation 
directory of the r-package then I am adding this path to the (PKG_CONFIG_PATH 
env) using this statement,
Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))
By this way, I will be sure that all libraries are accessible by the package.
- Then, the installation can be done using install_git(url=" 
https://github.com/ecrc/exageostatR";) for the GitHub repo.
The problem that I need to avoid the manual setting of the (PKG_CONFIG_PATH) so 
that I can, for example, upload my package to CRAN and simplify the 
installation process. I am doing the dependencies installation using the 
package configure file which can be accessed through 
https://github.com/ecrc/exageostatR/blob/master/configure.

(3) My package is only compatible with Linux and macOS. How to avoid CRAN 
windows checks.



Thanks,


--Sameh Abdulah

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

[bill]

Hi Georgi,

Thank you for the detailed investigation!  It looks like you've found the
issue with the psub() call below.

It looks like a more complex regexp, "(? gsub(pattern="(? 
Sent: Saturday, August 24, 2019 12:28 PM
To: b...@denney.ws; 'Duncan Murdoch' ;
r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

It seems that expansion of \ldots occurs in two different circumstances. 

1) The Rd2XXX converters treat specially \ldots and \dots but in different
ways. tools::Rd2latex() defines in its body texify(), which, when called
with a piece of R code, starts by replacing \ldots and \dots with

 x <- psub("[l]{0,1}dots", "...", as.character(x))

Similarly, Rd2ex(), defines a function remap() which does a similar thing.
The 'html' and 'txt' renderers also treat specially \dots and \ldots but
only in more restricted cases. I didn't find what 'R CMD check' does. 

This might explain the differences between 'html'  and 'text' on the one
hand, and 'pdf' output on the other hand. 
(as Duncan pointed out, he didn't see this in html).

But macros starting with '\l'  seem to be expanded in R code in all formats,
if the backslash is not escaped, example a) below illustrates this. I
redefined '\ldots' to demonstrate that this is  not due to the special
treatment that literally replaces \ldots with '...' as above. I think this
follows from the specification of Rd format p. 8 of the 'parseRd' document
referenced in my previous email. 


For illiustration, I added the following lines before the Usage section in
Bill's file topic_long_table_header.Rd.

\renewcommand{\ldots}{Aaaargh }
\renewcommand{\lmydots}{Uuugh }
\renewcommand{\mydots}{this is mydots }

Here the Usage entry for the shown argument  only is modified (with 3
backslashes)

topic_long_table_header(x, col_names = NULL,
  (not changed)
  subsequent_page_notification = "\\\ldots continued \\\lmydots \\\mydots",
  (not changed)
   )

In the pdf file we see 

subsequent_page_notification = "\Aaaargh continued \Uuugh \\mydots"

\ldots and \lmydots are expanded but \mydots is not. I believe that \lmydots
is expanded since it starts with 'l', see my previous email. In this case,
'R CMD check' gives an additional warning about the unescaped backslash: 

...
subsequent_page_notification = "Aaaargh  continued
\Uuugh  \\mydots"

This seems to happen since an attempt is made later to parse \Aaaargh and
\Uuugh. If the Rd entry in the Usage section contaiin only one backslash, as
in  
 subsequent_page_notification = "\ldots continued \lmydots \\\mydots",

then we get in all renderings: 

subsequent_page_notification = "Aaaargh continued Uuugh \\mydots"

'R CMD check' also shows this text (and complains, since it obviously is not
as in the function deifnition,



b) With proper escaping (using 4, instead of 3 backslashes above) we get (in
the pdf rendering):

subsequent_page_notification = "\... continued \\lmydots \\mydots"

\ldots is expanded but the other macros are not. Note that the expansion of
\ldots here is due is due to the specific rendering for LaTeX, which
replaces \\ldots by three dots (...), and doesn't use my Rd definition for
\ldots, suggesting that  this occurs at a different place.


Georgi Boshnakov

From: b...@denney.ws [b...@denney.ws]
Sent: 24 August 2019 14:46
To: 'Duncan Murdoch'; Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Duncan,

The original Rd generated by roxygen2 had 4 backslashes:

https://github.com/billdenney/TopicLongTableR/blob/master/man/topic_long_tab
le_header.Rd#L9

That generated a similar issue but check showed "\..." (backslash then 3
dots) instead of what is shown in the 2 backslashes case when check showed
just "...".

So, while I agree that 4 backslashes would make the most sense for the .Rd
file, there is still an issue somewhere with that 4 backslashes case.

Thanks,

Bill

-Original Message-
From: Duncan Murdoch 
Sent: Saturday, August 24, 2019 8:37 AM
To: b...@denney.ws; 'Georgi Boshnakov' ;
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:
> On 23/08/2019 1:33 p.m., b...@denney.ws wrote:
>> 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.
>
> It's certainly not a bug in utils:prompt:  that's never called except 
> by the user.

Actually, that's wrong.  utils::prompt() is generating bad code:  you need
to have 4 backslashes in order to display 2.  It is just showing the string
as it would be deparsed for display, it isn't modifying it so that it is
appropriate as Rd source.

Duncan Murdoch


>
> It might be a bug in the .Rd parsing, but I don't think so

Re: [R-pkg-devel] NAMESPACE issue and grDevices

[Jeff Newmiller]

I think yes. If a direct user of graphics opted not to call smoothScatter then 
they would have no need to even install KernSmooth. However, since generics 
automatically trigger loading of class-specific methods, one of which in your 
case includes that dependency, your package cannot avoid at least importing 
KernSmooth.

On August 24, 2019 7:36:44 AM PDT, Kevin Coombes  
wrote:
>Hi,
>
>I've been building a package and hit a NAMESPACE issue that took a
>while 
>to resolve.
>
>My package implements a (new) generic function, and the method for a 
>package in the class calls the "smoothScatter" function from the 
>"graphics" package. I could build and install the package successfully,
>
>and when I used the generic function, it worked just fine.
>
>However, when I ran "R CMD check --as-cran", it threw an error from
>both 
>the examples in man pages and a test script. Specifically, the error
>was 
>"package KernSmooth not available". I eventually worked around this 
>problem by changing the DESCRIPTION file to "IMPORT KernSmooth" (even 
>though I didn't have to actually import anything in "NAMESPACE").
>
>The underlying issue appears to be that
>     graphics::smoothScatter
>calls a non-exported function from "grDevices"
>  grDevices:::.smoothScatterCalcDensity
>which in turn calls an explicitly qualified function from "KernSmooth"
>     KernSmooth::bkde2D
>
>To complicate matters
>     graphics IMPORTs grDevices
>but
>     grDevices only SUGGESTs KernSmooth.
>
>Since my package already IMPORTed the graphics package and had
>     importFrom("graphics", "smoothScatter")
>in the NAMESPACE, I was surprised that I had to track back through the 
>code to find this dependency and had to make it explicitly known within
>
>the interface to my package.
>
>Is there something else my package should do? Or should "grDevices" 
>actually IMPORT "KernSmooth"?
>
>Best,
>   Kevin
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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

It seems that expansion of \ldots occurs in two different circumstances. 

1) The Rd2XXX converters treat specially \ldots and \dots but in different 
ways. tools::Rd2latex() defines in its body texify(), which, when called with a 
piece of R code, starts by replacing \ldots and \dots with

 x <- psub("[l]{0,1}dots", "...", as.character(x))

Similarly, Rd2ex(), defines a function remap() which does a similar thing. The 
'html' and 'txt' renderers also treat specially \dots and \ldots but only in 
more restricted cases. I didn't find what 'R CMD check' does. 

This might explain the differences between 'html'  and 'text' on the one hand, 
and 'pdf' output on the other hand. 
(as Duncan pointed out, he didn't see this in html).

But macros starting with '\l'  seem to be expanded in R code in all formats, if 
the backslash is not escaped, example a) below illustrates this. I redefined 
'\ldots' to demonstrate that this is  not due to the special treatment that 
literally replaces \ldots with '...' as above. I think this follows from the 
specification of Rd format p. 8 of the 'parseRd' document  referenced in my 
previous email. 


For illiustration, I added the following lines before the Usage section in 
Bill's file topic_long_table_header.Rd.

\renewcommand{\ldots}{Aaaargh }
\renewcommand{\lmydots}{Uuugh }
\renewcommand{\mydots}{this is mydots }

Here the Usage entry for the shown argument  only is modified (with 3 
backslashes)

topic_long_table_header(x, col_names = NULL,
  (not changed)
  subsequent_page_notification = "\\\ldots continued \\\lmydots \\\mydots",
  (not changed)
   )

In the pdf file we see 

subsequent_page_notification = "\Aaaargh continued \Uuugh \\mydots"

\ldots and \lmydots are expanded but \mydots is not. I believe that \lmydots is 
expanded since it starts with 'l', see my previous email. In this case, 'R CMD 
check' gives an additional warning about the unescaped backslash: 

...
subsequent_page_notification = "Aaaargh  continued \Uuugh  
\\mydots"

This seems to happen since an attempt is made later to parse \Aaaargh and 
\Uuugh. If the Rd entry in the Usage section contaiin only one backslash, as in 
 
 subsequent_page_notification = "\ldots continued \lmydots \\\mydots",

then we get in all renderings: 

subsequent_page_notification = "Aaaargh continued Uuugh \\mydots"

'R CMD check' also shows this text (and complains, since it obviously is not as 
in the function deifnition,



b) With proper escaping (using 4, instead of 3 backslashes above) we get (in 
the pdf rendering):

subsequent_page_notification = "\... continued \\lmydots \\mydots"

\ldots is expanded but the other macros are not. Note that the expansion of 
\ldots here is due is due to the specific rendering for LaTeX, which replaces 
\\ldots by three dots (...), and doesn't use my Rd definition for \ldots, 
suggesting that  this occurs at a different place.


Georgi Boshnakov

From: b...@denney.ws [b...@denney.ws]
Sent: 24 August 2019 14:46
To: 'Duncan Murdoch'; Georgi Boshnakov; r-package-devel@r-project.org
Subject: RE: [R-pkg-devel] Literal LaTeX Text in Function Arguments

Hi Duncan,

The original Rd generated by roxygen2 had 4 backslashes:

https://github.com/billdenney/TopicLongTableR/blob/master/man/topic_long_table_header.Rd#L9

That generated a similar issue but check showed "\..." (backslash then 3 dots) 
instead of what is shown in the 2 backslashes case when check showed just "...".

So, while I agree that 4 backslashes would make the most sense for the .Rd 
file, there is still an issue somewhere with that 4 backslashes case.

Thanks,

Bill

-Original Message-
From: Duncan Murdoch 
Sent: Saturday, August 24, 2019 8:37 AM
To: b...@denney.ws; 'Georgi Boshnakov' ; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:
> On 23/08/2019 1:33 p.m., b...@denney.ws wrote:
>> 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.
>
> It's certainly not a bug in utils:prompt:  that's never called except
> by the user.

Actually, that's wrong.  utils::prompt() is generating bad code:  you need to 
have 4 backslashes in order to display 2.  It is just showing the string as it 
would be deparsed for display, it isn't modifying it so that it is appropriate 
as Rd source.

Duncan Murdoch


>
> It might be a bug in the .Rd parsing, but I don't think so, because
> I'm not seeing it when I write the .Rd file manually and view it in HTML.
>
> It's most likely a bug in the check code, because I am seeing the same
> "Codoc mismatches" error as you are.  I'm also seeing it in the pdf
> display of the help page, but not in the HTML or text displays.
>
> Duncan Murdoch
>
>>
>> I just did

[R-pkg-devel] NAMESPACE issue and grDevices

[Kevin Coombes]

Hi,

I've been building a package and hit a NAMESPACE issue that took a while 
to resolve.


My package implements a (new) generic function, and the method for a 
package in the class calls the "smoothScatter" function from the 
"graphics" package. I could build and install the package successfully, 
and when I used the generic function, it worked just fine.


However, when I ran "R CMD check --as-cran", it threw an error from both 
the examples in man pages and a test script. Specifically, the error was 
"package KernSmooth not available". I eventually worked around this 
problem by changing the DESCRIPTION file to "IMPORT KernSmooth" (even 
though I didn't have to actually import anything in "NAMESPACE").


The underlying issue appears to be that
    graphics::smoothScatter
calls a non-exported function from "grDevices"
 grDevices:::.smoothScatterCalcDensity
which in turn calls an explicitly qualified function from "KernSmooth"
    KernSmooth::bkde2D

To complicate matters
    graphics IMPORTs grDevices
but
    grDevices only SUGGESTs KernSmooth.

Since my package already IMPORTed the graphics package and had
    importFrom("graphics", "smoothScatter")
in the NAMESPACE, I was surprised that I had to track back through the 
code to find this dependency and had to make it explicitly known within 
the interface to my package.


Is there something else my package should do? Or should "grDevices" 
actually IMPORT "KernSmooth"?


Best,
  Kevin

__
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 Duncan,

The original Rd generated by roxygen2 had 4 backslashes:

https://github.com/billdenney/TopicLongTableR/blob/master/man/topic_long_table_header.Rd#L9

That generated a similar issue but check showed "\..." (backslash then 3 dots) 
instead of what is shown in the 2 backslashes case when check showed just "...".

So, while I agree that 4 backslashes would make the most sense for the .Rd 
file, there is still an issue somewhere with that 4 backslashes case.

Thanks,

Bill

-Original Message-
From: Duncan Murdoch  
Sent: Saturday, August 24, 2019 8:37 AM
To: b...@denney.ws; 'Georgi Boshnakov' ; 
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Literal LaTeX Text in Function Arguments

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:
> On 23/08/2019 1:33 p.m., b...@denney.ws wrote:
>> 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.
> 
> It's certainly not a bug in utils:prompt:  that's never called except 
> by the user.

Actually, that's wrong.  utils::prompt() is generating bad code:  you need to 
have 4 backslashes in order to display 2.  It is just showing the string as it 
would be deparsed for display, it isn't modifying it so that it is appropriate 
as Rd source.

Duncan Murdoch


> 
> It might be a bug in the .Rd parsing, but I don't think so, because 
> I'm not seeing it when I write the .Rd file manually and view it in HTML.
> 
> It's most likely a bug in the check code, because I am seeing the same 
> "Codoc mismatches" error as you are.  I'm also seeing it in the pdf 
> display of the help page, but not in the HTML or text displays.
> 
> Duncan Murdoch
> 
>>
>> 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 Argum

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

[Duncan Murdoch]

On 24/08/2019 7:35 a.m., Duncan Murdoch wrote:

On 23/08/2019 1:33 p.m., b...@denney.ws wrote:

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.


It's certainly not a bug in utils:prompt:  that's never called except by
the user.


Actually, that's wrong.  utils::prompt() is generating bad code:  you 
need to have 4 backslashes in order to display 2.  It is just showing 
the string as it would be deparsed for display, it isn't modifying it so 
that it is appropriate as Rd source.


Duncan Murdoch




It might be a bug in the .Rd parsing, but I don't think so, because I'm
not seeing it when I write the .Rd file manually and view it in HTML.

It's most likely a bug in the check code, because I am seeing the same
"Codoc mismatches" error as you are.  I'm also seeing it in the pdf
display of the help page, but not in the HTML or text displays.

Duncan Murdoch



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

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

[Duncan Murdoch]

On 23/08/2019 1:33 p.m., b...@denney.ws wrote:

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.


It's certainly not a bug in utils:prompt:  that's never called except by 
the user.


It might be a bug in the .Rd parsing, but I don't think so, because I'm 
not seeing it when I write the .Rd file manually and view it in HTML.


It's most likely a bug in the check code, because I am seeing the same 
"Codoc mismatches" error as you are.  I'm also seeing it in the pdf 
display of the help page, but not in the HTML or text displays.


Duncan Murdoch



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

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

[Georgi Boshnakov]

HI Bill, 

I checked this as well, using the package you put on github for this purpose 
(note that the link you gave didn't work for me).
I tried a few variants but the bottom line is that "\ldots" and "\dots" are 
expanded even if the backslash is escaped. 

It is a feature rather than a bug, see towards the bottom of p. 8 in parseRd 
(https://developer.r-project.org/parseRd.pdf). 
In R strings, macros starting with "\l" are expanded (this is how 
\code{\link{sss}} works). 

But '\dots' is also expanded and this seems undocumented. I now recall that I 
have seen similar behaviour for "\dots" in R strings in the Examples section. 

I tried some hacks, such as redefining the '\ldots' but they don't work, since 
the Rd parser works recursively.
 


Georgi Boshnakov   



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

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 copyin