Re: [R-pkg-devel] Package Encoding and Literal Strings

[jo...@jorisgoosen.nl]

David,

Thanks for the response!

So the problem is a bit worse then just setting `encoding="UTF-8"` on
functions like readLines.
I'll describe our setup a bit:
So we run R embedded in a separate executable and through a whole bunch of
C(++) magic get that to the main executable that runs the actual interface.
All the code that isn't R basically uses UTF-8. This works good and we've
made sure that all of our source code is encoded properly and I've verified
that for this particular problem at least my source file is definitely
encoded in UTF-8 (Ive checked a hexdump).

The simplest solution, that we initially took, to get R+Windows to
cooperate with everything is to simply set the locale to "C" before
starting R. That way R simply assumes UTF-8 is native and everything worked
splendidly. Until of course a file needs to be opened in R that contains
some non-ASCII characters. I noticed the problem because a korean user had
hangul in his username and that broke everything. This because R was trying
to convert to a different locale than Windows was using.

The solution I've now been working on is:
I took the sourcecode of R 4.0.3 and changed the backend of "gettext" to
add an `encoding="something something"` option. And a bit of extra stuff
like `bind_textdomain_codeset` in case I need to tweak the codeset/charset
that gettext uses.
I think I've got that working properly now and once I solve the problem of
the encoding in a pkg I will open a bugreport/feature-request and I'll add
a patch that implements it.

The problem I'm stuck with now is simply this:
I have an R pkg here that I want to test the translations with and the code
is definitely saved as UTF-8, the package has "Encoding: UTF-8" in the
DESCRIPTION and it all loads and works. The particular problem I have is
that the R code contains literally: `mathotString <- "Mathôt!"`
The actual file contains the hexadecimal representation of ô as proper
utf-8: "0xC3 0xB4" but R turns it into: "0xf4".
Seemingly on loading the package, because I haven't done anything with it
except put it in my debug c-function to print its contents as
hexadecimals...

The only thing I want to achieve here is that when R loads the package it
keeps those strings in their original UTF-8 encoding, without converting it
to "native" or the strange unicode codepoint it seemingly placed in there
instead. Because otherwise I cannot get gettext to work fully in UTF-8 mode.

Is this already possible in R?

Cheers,
Joris


On Wed, 16 Dec 2020 at 20:15, David Bosak  wrote:

> Joris:
>
>
>
> I’ve fought with encoding problems on Windows a lot.  Here are some
> general suggestions.
>
>
>
>1. Put “@encoding UTF-8” on any Roxygen comments.
>2. Put “encoding = “UTF-8” on any functions like writeLines or
>readLines that read/write to a text file.
>3. This post:
>https://kevinushey.github.io/blog/2018/02/21/string-encoding-and-r/
>
>
>
> If you have a more specific problem, please describe and we can try to
> help.
>
>
>
> David
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *jo...@jorisgoosen.nl
> *Sent: *Wednesday, December 16, 2020 1:52 PM
> *To: *r-package-devel@r-project.org
> *Subject: *[R-pkg-devel] Package Encoding and Literal Strings
>
>
>
> Hello All,
>
>
>
> Some context, I am one of the programmers of a software pkg (
>
> https://jasp-stats.org/) that uses an embedded instance of R to do
>
> statistics. And make that a bit easier for people who are intimidated by R
>
> or like to have something more GUI oriented.
>
>
>
>
>
> We have been working on translating the interface but ran into several
>
> problems related to encoding of strings. We prefer to use UTF-8 for
>
> everything and this works wonderful on unix systems, as is to be expected.
>
>
>
> Windows however is a different matter. Currently I am working on some local
>
> changes to "do_gettext" and some related internal functions of R to be able
>
> to get UTF-8 encoded output from there.
>
>
>
> But I ran into a bit of a problem and I think this mailinglist is probably
>
> the best place to start.
>
>
>
> It seems that if I have an R package that specifies "Encoding: UTF-8" in
>
> DESCRIPTION the literal strings inside the package are converted to the
>
> local codeset/codepage regardless of what I want.
>
>
>
> Is it possible to keep the strings in UTF-8 internally in such a pkg
>
> somehow?
>
>
>
> Best regards,
>
> Joris Goosen
>
> University of Amsterdam
>
>
>
> [[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] Accessing features in R4.0.

[Gábor Csárdi]

On Wed, Dec 16, 2020 at 8:39 PM Henrik Bengtsson
 wrote:
>
> BTW, 'backports' provides a backport for tools::R_user_dir() also for
> R (< 4.0.0), so an alternative solution in this case is:
>
> Imports: backports
>
> and
>
> importFrom(backports, R_user_dir)
>
> The 'backports' package takes the same approach as I did in my previous 
> message.

FWIW, the backports README actually suggests a different approach:
https://github.com/r-lib/backports#in-packages

G.

[...]

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

Re: [R-pkg-devel] Accessing features in R4.0.

[Henrik Bengtsson]

BTW, 'backports' provides a backport for tools::R_user_dir() also for
R (< 4.0.0), so an alternative solution in this case is:

Imports: backports

and

importFrom(backports, R_user_dir)

The 'backports' package takes the same approach as I did in my previous message.

Henrik

On Wed, Dec 16, 2020 at 12:27 PM Henrik Bengtsson
 wrote:
>
> Colin, you can do:
>
> Imports: tools
>
> NAMESPACE:
> if (getRversion() >= 4) importFrom(tools,R_user_dir)
>
>
> R/000.namespace.R:
> ## Create a dummy R_user_dir() for R (< 4.0.0)
> ## to please R CMD check
> if (getRversion() < 4) {
>   R_user_dir <- function(...) NULL
> }
>
> and then use:
>
> if (getRversion() < 4) {
>   # do something
> } else {
>   R_user_dir("oysteR", which = "cache")
> }
>
> An advantage of this approach is that it's clear from Imports: and the
> NAMESPACE file what you're importing and when.  When using Suggests:
> and pkg::fcn() you can't peek at NAMESPACE to see what's actually
> used.
>
>
> Finally, if '#do something' is basically trying to do the same as
> tools::R_user_dir(), you could of course also consider writing your
> own forward-compatible wrapper for R (< 4.0.0), e.g.
>
> if (getRversion() < 4) {
>   R_user_dir <- function(...) {
> # do something
>}
> }
>
> and then use R_user_dir() as if you're running R (>= 4.0.0).  That's
> the cleanest version.
>
> Hope this helps,
>
> Henrik
>
>
> On Wed, Dec 16, 2020 at 11:12 AM Jeff Newmiller
>  wrote:
> >
> > For "obvious" reasons? I don't see this kind of avoidance as "obviously" 
> > correct at all. You have a dependency... it should be declared. There are 
> > various ways to proceed, with Imports or Depends or Suggests or pulling the 
> > code into your package... but trying to subvert the dependency management 
> > is counterproductive.
> >
> > On December 16, 2020 8:28:15 AM PST, Colin Gillespie 
> >  wrote:
> > >Hi,
> > >
> > >I'm planning on using the tools::R_user_dir function in a package. But
> > >for obvious reasons, I don't want to set the dependency on R 4.
> > >
> > >My code is basically
> > >
> > >if (as.numeric(R.version$major) < 4) # do something
> > >else tools::R_user_dir("oysteR", which = "cache")
> > >
> > >When checking on win-builder R3.6 I get the note
> > >
> > >* checking dependencies in R code ... NOTE
> > >Missing or unexported object: 'tools::R_user_dir'
> > >
> > >## Question
> > >
> > >Is my code correct and can I ignore this note?
> > >
> > >Thanks
> > >
> > >Colin
> > >
> > >
> > >Dr Colin Gillespie
> > >http://www.mas.ncl.ac.uk/~ncsg3/
> > >
> > >__
> > >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

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

Re: [R-pkg-devel] Accessing features in R4.0.

[Henrik Bengtsson]

Colin, you can do:

Imports: tools

NAMESPACE:
if (getRversion() >= 4) importFrom(tools,R_user_dir)


R/000.namespace.R:
## Create a dummy R_user_dir() for R (< 4.0.0)
## to please R CMD check
if (getRversion() < 4) {
  R_user_dir <- function(...) NULL
}

and then use:

if (getRversion() < 4) {
  # do something
} else {
  R_user_dir("oysteR", which = "cache")
}

An advantage of this approach is that it's clear from Imports: and the
NAMESPACE file what you're importing and when.  When using Suggests:
and pkg::fcn() you can't peek at NAMESPACE to see what's actually
used.


Finally, if '#do something' is basically trying to do the same as
tools::R_user_dir(), you could of course also consider writing your
own forward-compatible wrapper for R (< 4.0.0), e.g.

if (getRversion() < 4) {
  R_user_dir <- function(...) {
# do something
   }
}

and then use R_user_dir() as if you're running R (>= 4.0.0).  That's
the cleanest version.

Hope this helps,

Henrik


On Wed, Dec 16, 2020 at 11:12 AM Jeff Newmiller
 wrote:
>
> For "obvious" reasons? I don't see this kind of avoidance as "obviously" 
> correct at all. You have a dependency... it should be declared. There are 
> various ways to proceed, with Imports or Depends or Suggests or pulling the 
> code into your package... but trying to subvert the dependency management is 
> counterproductive.
>
> On December 16, 2020 8:28:15 AM PST, Colin Gillespie  
> wrote:
> >Hi,
> >
> >I'm planning on using the tools::R_user_dir function in a package. But
> >for obvious reasons, I don't want to set the dependency on R 4.
> >
> >My code is basically
> >
> >if (as.numeric(R.version$major) < 4) # do something
> >else tools::R_user_dir("oysteR", which = "cache")
> >
> >When checking on win-builder R3.6 I get the note
> >
> >* checking dependencies in R code ... NOTE
> >Missing or unexported object: 'tools::R_user_dir'
> >
> >## Question
> >
> >Is my code correct and can I ignore this note?
> >
> >Thanks
> >
> >Colin
> >
> >
> >Dr Colin Gillespie
> >http://www.mas.ncl.ac.uk/~ncsg3/
> >
> >__
> >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

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

Re: [R-pkg-devel] Used package not updated - needs java < V 11

[Knut Krueger]

Am 15.12.20 um 14:37 schrieb Duncan Murdoch:

thank you for your answer


You should not have

@importFrom XLConnect createSheet writeWorksheet saveWorkbook

in your ROxygen comments; that results in an unconditional import. 
Instead, you should use fully qualified calls each time, i.e.


XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook



#' @importFrom XLConnect::createSheet, XLConnect::writeWorksheet, 
XLConnect::saveWorkbook


This causes the error "there is no package called ‘XLConnect::createSheet,’"

Regards Knut

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

Re: [R-pkg-devel] Used package not updated - needs java < V 11

[Knut Krueger]

Thank you for your answer,

I tested  WriteXLS and openxlsx ... but it is perl based and most of the 
Windows user do not have perl installed.
Therefore I would change the missing XlConnect with missing Perl 
library. And that is more complicated, because the user has to add 
something on operating system level. No chance f.e on University cip 
pools and users unfamiliar with operating systems at all


-> gdata - I will check how to change it

Thank you Knut

Am 15.12.20 um 15:43 schrieb Spencer Graves:
  I suggest NOT using "XLConnect".  "sos" now uses WriteXLS.  
"Ecfun" now uses "openxlsx".



   Also, I received an email from CRAN maintainers months ago saying 
that "gdata" was being obsoleted.  It's still on CRAN with a date of 
2017-06-06 and a huge number of reverse dependencies.  The CRAN 
maintainers may have gotten someone to agree to take it over who just 
hasn't finished fixing whatever deficiencies it has.  However, you might 
see how difficult it might be to do without "gdata" as well.



   Spencer Graves




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

Re: [R-pkg-devel] Accessing features in R4.0.

[Jeff Newmiller]

For "obvious" reasons? I don't see this kind of avoidance as "obviously" 
correct at all. You have a dependency... it should be declared. There are 
various ways to proceed, with Imports or Depends or Suggests or pulling the 
code into your package... but trying to subvert the dependency management is 
counterproductive.

On December 16, 2020 8:28:15 AM PST, Colin Gillespie  
wrote:
>Hi,
>
>I'm planning on using the tools::R_user_dir function in a package. But
>for obvious reasons, I don't want to set the dependency on R 4.
>
>My code is basically
>
>if (as.numeric(R.version$major) < 4) # do something
>else tools::R_user_dir("oysteR", which = "cache")
>
>When checking on win-builder R3.6 I get the note
>
>* checking dependencies in R code ... NOTE
>Missing or unexported object: 'tools::R_user_dir'
>
>## Question
>
>Is my code correct and can I ignore this note?
>
>Thanks
>
>Colin
>
>
>Dr Colin Gillespie
>http://www.mas.ncl.ac.uk/~ncsg3/
>
>__
>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

[R-pkg-devel] Package Encoding and Literal Strings

[jo...@jorisgoosen.nl]

Hello All,

Some context, I am one of the programmers of a software pkg (
https://jasp-stats.org/) that uses an embedded instance of R to do
statistics. And make that a bit easier for people who are intimidated by R
or like to have something more GUI oriented.


We have been working on translating the interface but ran into several
problems related to encoding of strings. We prefer to use UTF-8 for
everything and this works wonderful on unix systems, as is to be expected.

Windows however is a different matter. Currently I am working on some local
changes to "do_gettext" and some related internal functions of R to be able
to get UTF-8 encoded output from there.

But I ran into a bit of a problem and I think this mailinglist is probably
the best place to start.

It seems that if I have an R package that specifies "Encoding: UTF-8" in
DESCRIPTION the literal strings inside the package are converted to the
local codeset/codepage regardless of what I want.

Is it possible to keep the strings in UTF-8 internally in such a pkg
somehow?

Best regards,
Joris Goosen
University of Amsterdam

[[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] Accessing features in R4.0.

[Sebastian Meyer]

Am 16.12.20 um 18:00 schrieb Neal Fultz:
> IIRC some packages use get() instead of double-colon to suppress the NOTE.

I'd discourage from using get() because you could (accidentally) access
even unexported objects from another namespace. There is

getExportedValue(ns, name)

to avoid that. However, its help page describes it as an internal
function, so I'm not sure if that would be any better. "::" access is
also faster, especially as of the next version of R.

Of course, such workarounds should be used with great care as these
checks are usually very valuable to guard against coding errors or warn
about potential changes in the other package's API.

> I would probably ignore it myself.

Yes. FWIW, conditional use of tools::R_user_dir() is allowed according
to the CRAN repository policy:

> For R version 4.0 or later (hence a version dependency is required or only 
> conditional use is possible), packages may store user-specific data, 
> configuration and cache files in their respective user directories obtained 
> from tools::R_user_dir(), provided that by default sizes are kept as small as 
> possible and the contents are actively managed (including removing outdated 
> material). 

Best regards,

Sebastian Meyer


> 
> On Wed, Dec 16, 2020 at 8:29 AM Colin Gillespie  wrote:
>>
>> Hi,
>>
>> I'm planning on using the tools::R_user_dir function in a package. But
>> for obvious reasons, I don't want to set the dependency on R 4.
>>
>> My code is basically
>>
>> if (as.numeric(R.version$major) < 4) # do something
>> else tools::R_user_dir("oysteR", which = "cache")
>>
>> When checking on win-builder R3.6 I get the note
>>
>> * checking dependencies in R code ... NOTE
>> Missing or unexported object: 'tools::R_user_dir'
>>
>> ## Question
>>
>> Is my code correct and can I ignore this note?
>>
>> Thanks
>>
>> Colin
>>
>>
>> Dr Colin Gillespie
>> http://www.mas.ncl.ac.uk/~ncsg3/
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

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

Re: [R-pkg-devel] Accessing features in R4.0.

[Neal Fultz]

IIRC some packages use get() instead of double-colon to suppress the NOTE.

I would probably ignore it myself.

On Wed, Dec 16, 2020 at 8:29 AM Colin Gillespie  wrote:
>
> Hi,
>
> I'm planning on using the tools::R_user_dir function in a package. But
> for obvious reasons, I don't want to set the dependency on R 4.
>
> My code is basically
>
> if (as.numeric(R.version$major) < 4) # do something
> else tools::R_user_dir("oysteR", which = "cache")
>
> When checking on win-builder R3.6 I get the note
>
> * checking dependencies in R code ... NOTE
> Missing or unexported object: 'tools::R_user_dir'
>
> ## Question
>
> Is my code correct and can I ignore this note?
>
> Thanks
>
> Colin
>
>
> Dr Colin Gillespie
> http://www.mas.ncl.ac.uk/~ncsg3/
>
> __
> 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] Accessing features in R4.0.

[brodie gaslam via R-package-devel]

I don't know if this will work in your case (or even if it is a good
or bad thing to do), but backports conditionally exports the function
in question, e.g.:

https://github.com/r-lib/backports/blob/master/R/lengths.R

So in that example their implementation of a function not available
in R < 3.2.0 is presumably only exported for those versions of R.
You could try something similar, although I make no guarantees
on whether this is considered proper or not.  It _seems_ like
a clean solution to me, but I have no experience putting any
logic in the namespace file.

WRE does show something very similar, so this might be okay:

https://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods

Best,

B.



On Wednesday, December 16, 2020, 11:29:08 AM EST, Colin Gillespie 
 wrote: 





Hi,

I'm planning on using the tools::R_user_dir function in a package. But
for obvious reasons, I don't want to set the dependency on R 4.

My code is basically

if (as.numeric(R.version$major) < 4) # do something
else tools::R_user_dir("oysteR", which = "cache")

When checking on win-builder R3.6 I get the note

* checking dependencies in R code ... NOTE
Missing or unexported object: 'tools::R_user_dir'

## Question

Is my code correct and can I ignore this note?

Thanks

Colin


Dr Colin Gillespie
http://www.mas.ncl.ac.uk/~ncsg3/

__
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] Accessing features in R4.0.

[Colin Gillespie]

Hi,

I'm planning on using the tools::R_user_dir function in a package. But
for obvious reasons, I don't want to set the dependency on R 4.

My code is basically

if (as.numeric(R.version$major) < 4) # do something
else tools::R_user_dir("oysteR", which = "cache")

When checking on win-builder R3.6 I get the note

* checking dependencies in R code ... NOTE
Missing or unexported object: 'tools::R_user_dir'

## Question

Is my code correct and can I ignore this note?

Thanks

Colin


Dr Colin Gillespie
http://www.mas.ncl.ac.uk/~ncsg3/

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

Re: [R-pkg-devel] Used package not updated - needs java < V 11

[Duncan Murdoch]

On 16/12/2020 10:21 a.m., Knut Krueger wrote:

Am 15.12.20 um 14:37 schrieb Duncan Murdoch:

thank you for your answer


You should not have

@importFrom XLConnect createSheet writeWorksheet saveWorkbook

in your ROxygen comments; that results in an unconditional import.
Instead, you should use fully qualified calls each time, i.e.

XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook



#' @importFrom XLConnect::createSheet, XLConnect::writeWorksheet,
XLConnect::saveWorkbook

This causes the error "there is no package called ‘XLConnect::createSheet,’"


No, you should drop the @importFrom comment completely, and in your R 
code use those fully qualified forms.


Duncan Murdoch

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

Re: [R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0

[Sebastian Meyer]

In the check log, I see

> * package encoding: UTF-8
> [...]
> * checking PDF version of manual ... WARNING
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> ! Package inputenc Error: Unicode char ‐ (U+2010)
> (inputenc)not set up for use with LaTeX.

I can reproduce this warning with a minimal test package with an Rd file
containing the Unicode hyphen "‐" (U+2010), which is different from
ASCII-compatible hyphen-minus "-" (U+002D), though not visibly ...
>From Wikipedia (https://en.wikipedia.org/wiki/Hyphen):

> In Unicode, the hyphen-minus is encoded as U+002D - so that Unicode remains 
> compatible with ASCII. Unicode also encodes the hyphen and minus separately, 
> as U+2010 ‐ and U+2212 − respectively.

The problematic hyphen probably arose from copy-pasting text from the
browser (which I just did for testing) or an office application into the
package documentation.

You can find non-ASCII characters in your Rd files using, e.g.,
tools::showNonASCIIfile("file.Rd"). For my test file, this gives:

> tools::showNonASCIIfile("test.Rd")
7: \description{test <80><90> test}

In many text editors, the character between "test" and "test" is
displayed just like a standard ASCII hyphen-minus. In my Emacs it is
shown in red, though, and in RStudio it looks slightly different than
the ASCII minus (but hard to recognize if you don't know).

You could apply the above function to all of "man" using, e.g.,

lapply(list.files("man", full.names=TRUE), tools::showNonASCIIfile)

at the root of your package and look for "<80><90>" in the result.

Hope this helps.
Best regards,

Sebastian Meyer


Am 16.12.20 um 08:12 schrieb Kristin Piikki:
> Dear R package developers,
> I have been trying a lot but I do not seem to find a solution to the problems 
> with this new package (please see below and attached). It seems related to 
> the building of the vignette. I would be very grateful if anyone could 
> provide some advice.
> Kind regards,
> Kristin
> 
> -Original Message-
> From: lig...@statistik.tu-dortmund.de 
> Sent: den 15 december 2020 16:21
> To: Kristin Piikki 
> Cc: cran-submissi...@r-project.org
> Subject: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0
> 
> Dear maintainer,
> 
> package valmetrics_1.0.0.tar.gz does not pass the incoming checks 
> automatically, please see the following pre-tests:
> Windows: 
> 
> Status: 1 ERROR, 1 WARNING, 1 NOTE
> Debian: 
> 
> Status: 1 NOTE
> 
> 
> 
> Please fix all problems and resubmit a fixed version via the webform.
> If you are not sure how to fix the problems shown, please ask for help on the 
> R-package-devel mailing list:
> 
> If you are fairly certain the rejection is a false positive, please reply-all 
> to this message and explain.
> 
> More details are given in the directory:
> 
> The files will be removed after roughly 7 days.
> 
> No strong reverse dependencies to be checked.
> 
> Best regards,
> CRAN teams' auto-check service
> ---
> När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
> personuppgifter. För att läsa mer om hur detta går till, klicka här 
> 
> E-mailing SLU will result in SLU processing your personal data. For more 
> information on how this is done, click here 
> 
> 
> 
> __
> 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] R CMD check warning on Solaris

[Akshit Achara]

Dear Duncan,

Thanks for your detailed answer.

Adding a test for checking the pandoc version resolves
the issues. That was precisely what I needed.

I have also added it to the SystemRequirements field,
thanks for the suggestion.

Thanks,
Akshit Achara

[[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] FW: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0

[Ivan Krylov]

On Wed, 16 Dec 2020 07:12:04 +
Kristin Piikki  wrote:

> Check: PDF version of manual, Result: WARNING
>   LaTeX errors when creating PDF version.
>   This typically indicates Rd problems.
>   LaTeX errors found:
>   ! Package inputenc Error: Unicode char ‐ (U+2010)
>   (inputenc)not set up for use with LaTeX.

This means that some of your man/*.Rd files contain UTF-8 characters
that LaTeX isn't ready to accept. Use tools::showNonASCIIfile on those
files to find out where the non-ASCII hyphen is hiding.

Does https://win-builder.r-project.org/ catch this problem when you
submit your package there, too?

-- 
Best regards,
Ivan

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

[R-pkg-devel] FW: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0

[Kristin Piikki]

Dear R package developers,
I have been trying a lot but I do not seem to find a solution to the problems 
with this new package (please see below and attached). It seems related to the 
building of the vignette. I would be very grateful if anyone could provide some 
advice.
Kind regards,
Kristin

-Original Message-
From: lig...@statistik.tu-dortmund.de 
Sent: den 15 december 2020 16:21
To: Kristin Piikki 
Cc: cran-submissi...@r-project.org
Subject: [CRAN-pretest-archived] CRAN submission valmetrics 1.0.0

Dear maintainer,

package valmetrics_1.0.0.tar.gz does not pass the incoming checks 
automatically, please see the following pre-tests:
Windows: 

Status: 1 ERROR, 1 WARNING, 1 NOTE
Debian: 

Status: 1 NOTE



Please fix all problems and resubmit a fixed version via the webform.
If you are not sure how to fix the problems shown, please ask for help on the 
R-package-devel mailing list:

If you are fairly certain the rejection is a false positive, please reply-all 
to this message and explain.

More details are given in the directory:

The files will be removed after roughly 7 days.

No strong reverse dependencies to be checked.

Best regards,
CRAN teams' auto-check service
---
När du skickar e-post till SLU så innebär detta att SLU behandlar dina 
personuppgifter. För att läsa mer om hur detta går till, klicka här 

E-mailing SLU will result in SLU processing your personal data. For more 
information on how this is done, click here 

Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64
Check: CRAN incoming feasibility, Result: NOTE
  Maintainer: 'Kristin Piikki '
  
  New submission
  
  Found the following (possibly) invalid file URI:
URI: original,%20unscaled
  From: inst/doc/notes.html

Flavor: r-devel-windows-ix86+x86_64
Check: PDF version of manual, Result: WARNING
  LaTeX errors when creating PDF version.
  This typically indicates Rd problems.
  LaTeX errors found:
  ! Package inputenc Error: Unicode char ‐ (U+2010)
  (inputenc)not set up for use with LaTeX.
  
  See the inputenc package documentation for explanation.
  Type  H   for immediate help.

Flavor: r-devel-windows-ix86+x86_64
Check: PDF version of manual without hyperrefs or index, Result: ERROR
  
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel