Re: [R-pkg-devel] R CMD check "unable to verify current time"

[John Fox]

Dear Dustin,

On 2020-08-27 8:26 p.m., Tracy, Josef wrote:

Hi John,

Duncan explained the cause of the problem, but i'm afraid I didn't 
follow how one solves it.  Did you manage to get a check without that note?


I didn't -- I just disregarded the note assuming that it would go away 
when the time server was back up.


(I've cc'd the R-package-devel list so that others can see your question 
and my response.)


Best,
 John



Thanks You,
Dustin

Dustin Tracy

Postdoctoral Researcher

Economic Science Institute

Chapman University

www.DustinTracy.com 




*From:* R-package-devel  on 
behalf of John Fox 

*Sent:* Thursday, August 27, 2020 11:39 AM
*To:* Duncan Murdoch ; 
r-package-devel@r-project.org 

*Subject:* Re: [R-pkg-devel] R CMD check "unable to verify current time"
External Message


[External Message]

Dear Duncan,

Thank you and the others who responded to my message.

John

On 2020-08-27 2:17 p.m., Duncan Murdoch wrote:

R tries to get the time from

https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fworldtimeapi.org%2Fapi%2Ftimezone%2FUTCdata=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320sdata=GHBn6K9Yl7qaRU6tYzAEzymO3751Uczj51xB9c17Zm4%3Dreserved=0 

or

https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fworldclockapi.com%2Fapi%2Fjson%2Futc%2Fnowdata=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320sdata=psttxEnhMO6MjLyEv%2BchRopHyhLvgCxgqLT0JDPQVys%3Dreserved=0

The first one doesn't accept UTC as a timezone; it appears to want
etc/UTC instead.  The second one is offline.

Duncan Murdoch

If both of those fail, you'll get the message you saw.

On 27/08/2020 1:23 p.m., John Fox wrote:

Dear r-package-devel list members,

I got the following note when checking two different packages today
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and
macOS Catalina systems, and on several platforms on rhub:

 * checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned
this problem recently, in case it's produced by something that I'm
doing. There is a discussion of a similar problem from 2019 at
.

Both packages that I was checking are close to CRAN releases and so I'd
like to know whether I can disregard the note.

Any help would be appreciated.

John





__
R-package-devel@r-project.org mailing list
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-develdata=02%7C01%7Ctracy%40chapman.edu%7Ce1a2215e59904aaee08708d84ab888d0%7C809929af2d2545bf9837089eb9cfbd01%7C1%7C0%7C637341504003489320sdata=rMlgTGg8rp7hxPhaiADuBl4%2FWSqGgx4wbKLIPgPS9o8%3Dreserved=0
- NOTE: This email originated from outside Chapman’s network. Do not 
click links or open attachments unless you recognize the sender and know 
content is safe.


NOTE: This email originated from outside Chapman’s network. Do not click 
links or open attachments unless you recognize the sender and know 
content is safe.




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

Re: [Rd] utils::isS3stdGeneric chokes on primitives and identity

[Gabriel Becker]

Trace adds something to the body of the function, so it does make sense
that it doesn't. Whether traced functions still technically meet the
definition of standard s3 generic or not is, I suppose, up for debate, but
I would say that they should, I think.

As before, if desired I can work on a patch for this if desired, or someone
on R-core can just take care of it if that is easier.

Best,
~G

On Thu, Aug 27, 2020 at 11:22 AM Antoine Fabri 
wrote:

> Should it work on traced functions ?
>
> As it is now it doesn't.
>
> Best,
>
> Antoine
>
> Le jeu. 20 août 2020 à 09:58, Kurt Hornik  a écrit :
>
>> > Gabriel Becker writes:
>>
>> > I added that so I can look at the proposed fix and put it or something
>> > similar in bugzilla for review final review.
>>
>> > Apologies for the oversight.
>>
>> Fixed now with
>>
>> -while(as.character(bdexpr[[1L]]) == "{")
>> +while(is.call(bdexpr) && (as.character(bdexpr[[1L]]) == "{"))
>>
>> (the suggested fix does not work on things like
>> foo <- function(x) {{ x }}
>> ...)
>>
>> Best
>> -k
>>
>> > ~G
>>
>> > On Wed, Aug 19, 2020 at 3:40 PM Antoine Fabri 
>> > wrote:
>>
>> >> Dear R-devel,
>> >>
>> >> utils::isS3stdGeneric tries to subset the body of the function it's
>> fed,
>> >> primitives don't like that because they don't have a body, identity
>> doesn't
>> >> like it either because it's body is a symbol.
>> >>
>> >> According to the doc, any function is a legal input.
>> >>
>> >> See below:
>> >>
>> >> identity
>> >> #> function (x)
>> >> #> x
>> >> #> 
>> >> #> 
>> >>
>> >> max
>> >> #> function (..., na.rm = FALSE)  .Primitive("max")
>> >>
>> >> isS3stdGeneric(identity)
>> >> #> Error in bdexpr[[1L]]: objet de type 'symbol' non indiçable
>> >>
>> >> isS3stdGeneric(max)
>> >> #> Error in while (as.character(bdexpr[[1L]]) == "{") bdexpr <-
>> >> bdexpr[[2L]]: l'argument est de longueur nulle
>> >>
>> >> Here is a simple fix :
>> >>
>> >> isS3stdGeneric <- function(f) {
>> >> {
>> >> bdexpr <- body(f)
>> >> if(is.null(bdexpr) || !is.call(bdexpr)) return(FALSE)
>> >> while (as.character(bdexpr[[1L]]) == "{") bdexpr <- bdexpr[[2L]]
>> >> ret <- is.call(bdexpr) && identical(bdexpr[[1L]], as.name
>> >> ("UseMethod"))
>> >> if (ret)
>> >> names(ret) <- bdexpr[[2L]]
>> >> ret
>> >> }
>> >> }
>> >>
>> >> isS3stdGeneric(identity)
>> >> #> [1] FALSE
>> >> isS3stdGeneric(max)
>> >> #> [1] FALSE
>> >>
>> >> Best,
>> >>
>> >> Antoine
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> __
>> >> R-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>>
>> >   [[alternative HTML version deleted]]
>>
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Ben Bolker]

 It seems to have gotten worse at the moment (package checking on my 
local machine hangs at this step).  Sorry if this is cross-threading.


On 3/19/19 7:11 AM, Rainer M Krug wrote:

Can anyone confirm if this has been fixed? I would like to remove the 
_R_CHECK_SYSTEM_CLOCK_=0 but would like to know in advance.

Thanks

Rainer



On 8 Mar 2019, at 10:03, Gábor Csárdi  wrote:

I think you can put this in appveyor.yml:

environment:
   _R_CHECK_SYSTEM_CLOCK_: 0

before the "build_script" section.

Gabor

On Fri, Mar 8, 2019 at 5:15 AM Marta Karaś  wrote:


I have faced the same problem with using http://worldclockapi.com/. I dealt
with Travis fail (because warnings are changed to errors) after setting
environment variable _R_CHECK_SYSTEM_CLOCK_ to zero, as adviced above.

How I deal with appveyor fail for the same reason? It may be seen in my
built output here (link)
.
I googled but was unable to find the equivalent of

env:
  - _R_CHECK_SYSTEM_CLOCK_=0


for appveyor. Would appreciate any hint a lot - thank you!
Marta

On Thu, Mar 7, 2019 at 2:53 PM Hadley Wickham  wrote:


As of ~7 hours ago, the warning is suppressed:

https://github.com/wch/r-source/commit/31ee14c620eb1b939acd322f3b5617f998aab8e8

(But the service still doesn't work)

Hadley

On Thu, Mar 7, 2019 at 11:03 AM Hadley Wickham 
wrote:


It appears that the code was added by BDR on 2 Sep 2018:


https://github.com/wch/r-source/commit/d839b1e04e173f90b51ad809ef0bdb18095abe6f


I assume we are seeing failing R CMD check results because
http://worldclockapi.com/api/json/utc/now has recently died.

It would be appreciated if someone from R-core could look into this as
it's currently causing all R-devel builds on travis to fail.

Hadley

On Thu, Mar 7, 2019 at 9:32 AM Bob Rudis  wrote:


(a) that's gd news (#ty)
(b) genuine apologies for my confusion
(c) why was the introduction of reliance on a third-party site even

under consideration?



On Mar 7, 2019, at 09:32, peter dalgaard  wrote:

It's not "stealth fixed"! It was never there... (on the release

branch)


The timestamp checking code is still present in R-devel. I presume

something needs to be done about the breakage.


- pd


On 7 Mar 2019, at 14:38 , Bob Rudis  wrote:

It's fixed in the RC that's GA on the 11th.

I think perhaps "stealth fixed" may be more appropro since it's not

in SVN logs, Bugzilla nor noted prominently in any of the various NEWS*
files.


Then there's the "why was the core R installation using a third

party, non-HTTPS site for this to begin with".


And, in other news, there are tests in the R source that rely on a

check of `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar`
is registered. Thankfully there's no current IP address associated with it.
Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might
be a better choice as well since that won't break the reason for the
connectivity checks and won't arbitrarily send telemetry pings to third
parties in the even anyone outside of R Core decides to run the tests (say,
when patching something in R).


-boB


On Mar 7, 2019, at 07:54, Rainer M Krug  wrote:

I can confirm the same when checking on travis with r-devel.

And thanks for the tip with

env:
- _R_CHECK_SYSTEM_CLOCK_=0

In .travis.yml

Seems to be working now

Rainer




On 7 Mar 2019, at 12:48, Ralf Herold 

wrote:


Dear All,

Checking a new package under development produces a warning in a

local R-devel MS Windows environment (output below).


Building it with R-devel on Travis fails (because warnings are

changed to errors), but is successful when setting environment variable
_R_CHECK_SYSTEM_CLOCK_ to zero.


No issue occurs when checking and building with R-stable and

R-oldrel on Travis, or with any R version on win-builder.r-project.org.


The warning concerns using http://worldclockapi.com/, which

however seems out of service ("The web app you have attempted to reach is
currently stopped and does not accept any requests."). This is referenced
in the main function for R CMD check (
https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may
concern more R-devel than R-package-devel. I am posting here to check if
the issue was noticed by other package developers and to check the impact.


Thanks for any suggestions.
Best regards,
Ralf


PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe'

CMD check E:\mypackage_0.1.2.3.tar.gz --as-cran

* using log directory 'C:/Users/username/ctrdata.Rcheck'
* using R Under development (unstable) (2019-03-05 r76200)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* using option '--as-cran'
[...]
* checking package directory ... OK
* checking for future file timestamps ...Warning in file(con,

"r") :

cannot open URL 'http://worldclockapi.com/api/json/utc/now':

HTTP status was '403 Site Disabled'

WARNING
unable to verify current time
* checking 

Re: [R-pkg-devel] R CMD check "unable to verify current time"

[John Fox]

Dear Duncan,

Thank you and the others who responded to my message.

John

On 2020-08-27 2:17 p.m., Duncan Murdoch wrote:

R tries to get the time from

http://worldtimeapi.org/api/timezone/UTC or
http://worldclockapi.com/api/json/utc/now

The first one doesn't accept UTC as a timezone; it appears to want 
etc/UTC instead.  The second one is offline.


Duncan Murdoch

If both of those fail, you'll get the message you saw.

On 27/08/2020 1:23 p.m., John Fox wrote:

Dear r-package-devel list members,

I got the following note when checking two different packages today
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and
macOS Catalina systems, and on several platforms on rhub:

* checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned
this problem recently, in case it's produced by something that I'm
doing. There is a discussion of a similar problem from 2019 at
.

Both packages that I was checking are close to CRAN releases and so I'd
like to know whether I can disregard the note.

Any help would be appreciated.

John





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

Re: [Rd] R 4.0.2 64-bit Windows hangs

[Jeroen Ooms]

On Wed, Aug 26, 2020 at 7:54 PM Tomas Kalibera  wrote:
>
> On 8/25/20 6:14 PM, Tomas Kalibera wrote:
> > On 8/22/20 9:33 PM, Jeroen Ooms wrote:
> >> On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera
> >>  wrote:
> >>> On 8/22/20 8:26 PM, Tomas Kalibera wrote:
>  On 8/22/20 7:58 PM, Jeroen Ooms wrote:
> > On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera
> >  wrote:
> >> On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote:
> >>> Ah yes, this is related. I reported v2010 below, but it looks like
> >>> I was updated to this Insider Build overnight without my knowledge,
> >>> and conflated it with the new installation R v4 this morning.
> >>>
> >>> I will continue to look into the issue with the methods Tomas
> >>> mentioned.
> >> It is interesting that a rare 5 years old problem would re-appear on
> >> current Insider builds. Which build of Windows are you running
> >> exactly?
> >> I've seen another report about a crash on 20190.1000. It'd be
> >> nice to
> >> know if it is present also in newer builds, i.e. in 20197.
> > I installed the latest 20197 build in a vm, and I can indeed
> > reproduce
> > this problem.
> >
> > What seems to be happening is that R triggers an infinite
> > recursion in
> > Windows unwinding mechanism, and eventually dies with a stack
> > overflow. Attached a backtrace of the initial 100 frames of the main
> > thread (the pattern in the top ~30 frames continues forever).
> >
> > The microsoft blog doesn't mention anything related to exception
> > handling has changed in recent versions:
> > https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch
> >
> >
>  Thanks, unfortunately that does not ring any bells (except below), I
>  can't guess from this what is the underlying cause of the problem.
>  There may be something wrong in how we use setjmp/longjmp or how
>  setjmp/longjmp works on Windows.
> 
>  It reminds me of a problem I've been debugging few days ago, when
>  longjump implementation segfaults on Windows 10 (recent but not
>  Insider build) probably soon after unwinding the stack, but only with
>  GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only
>  with -03 (not -O2, not with with -O3 -fno-split-loops). The problem
>  was sensitive to these optimization options interestingly on the call
>  site of long jump (do_abs), even when it was not an immediate caller
>  of the longjump. I've not tracked this down yet, it will require
>  looking at the assembly level, and I was suspecting a compiler error
>  causing the compiler to generate code that messes with the stack or
>  registers in a way that impacts the upcoming jump. But now as we have
>  this other problem with setjmp/logjmp, the compiler may not be the top
>  suspect anymore.
> 
>  I may not be able to work on this in the next few days or a week, so
>  if anyone gets there first, please let me know what you find out.
> >>> Btw could you please try out if the UCRT build of R crashes as well in
> >>> the Insider Windows build ?
> >> Yes, it hangs in exactly the same way, except that the backtrace shows
> >>
> >>   ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll
> >>
> >> Instead of msvcrt!_setjmpex (as expected of course).
> >
> > Thanks. I found what is causing the problem I observed with
> > GCC10/stock Windows 10, I expect this is the same one as in the
> > Insider build.
> > I will investigate further,
> >
> > Tomas
> >
> It seems the problem is between MinGW-W64 and Windows, and really it
> causes both the reported crashes in an Insider build (I tested in 20197)
> and in my GCC 10 builds in a single "no-segfault" test. setjmp is
> implemented using Windows call _setjmpex, which has a second argument
> argument, which is set differently by MinGW based on GCC version. When I
> set this argument as MinGW-W64 did on early versions of GCC,
> mingw_getsp(), it fixes/hides the problems on my systems. Perl5 uses a
> similar workaround, but otherwise there is no solid base (documentation,
> specification, etc) I am aware of for this change, so this may take some
> more time to be properly fixed. Still, if anyone experiments with this
> workaround and finds a problem, please let me know. In particular, I am
> curious whether it works on earlier versions of Windows (at least with
> check-all, including recommended packages).

FYI, the problem has disappeared on Windows dev built 20201 (released
yesterday), so it may have been a Windows bug. That is not to say
there is no bug on the R/mingw side, but at least the current and past
releases of R are working again on the latest versions of Windows,
which is a big relief.

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

Re: [Rd] utils::isS3stdGeneric chokes on primitives and identity

[Antoine Fabri]

Should it work on traced functions ?

As it is now it doesn't.

Best,

Antoine

Le jeu. 20 août 2020 à 09:58, Kurt Hornik  a écrit :

> > Gabriel Becker writes:
>
> > I added that so I can look at the proposed fix and put it or something
> > similar in bugzilla for review final review.
>
> > Apologies for the oversight.
>
> Fixed now with
>
> -while(as.character(bdexpr[[1L]]) == "{")
> +while(is.call(bdexpr) && (as.character(bdexpr[[1L]]) == "{"))
>
> (the suggested fix does not work on things like
> foo <- function(x) {{ x }}
> ...)
>
> Best
> -k
>
> > ~G
>
> > On Wed, Aug 19, 2020 at 3:40 PM Antoine Fabri 
> > wrote:
>
> >> Dear R-devel,
> >>
> >> utils::isS3stdGeneric tries to subset the body of the function it's fed,
> >> primitives don't like that because they don't have a body, identity
> doesn't
> >> like it either because it's body is a symbol.
> >>
> >> According to the doc, any function is a legal input.
> >>
> >> See below:
> >>
> >> identity
> >> #> function (x)
> >> #> x
> >> #> 
> >> #> 
> >>
> >> max
> >> #> function (..., na.rm = FALSE)  .Primitive("max")
> >>
> >> isS3stdGeneric(identity)
> >> #> Error in bdexpr[[1L]]: objet de type 'symbol' non indiçable
> >>
> >> isS3stdGeneric(max)
> >> #> Error in while (as.character(bdexpr[[1L]]) == "{") bdexpr <-
> >> bdexpr[[2L]]: l'argument est de longueur nulle
> >>
> >> Here is a simple fix :
> >>
> >> isS3stdGeneric <- function(f) {
> >> {
> >> bdexpr <- body(f)
> >> if(is.null(bdexpr) || !is.call(bdexpr)) return(FALSE)
> >> while (as.character(bdexpr[[1L]]) == "{") bdexpr <- bdexpr[[2L]]
> >> ret <- is.call(bdexpr) && identical(bdexpr[[1L]], as.name
> >> ("UseMethod"))
> >> if (ret)
> >> names(ret) <- bdexpr[[2L]]
> >> ret
> >> }
> >> }
> >>
> >> isS3stdGeneric(identity)
> >> #> [1] FALSE
> >> isS3stdGeneric(max)
> >> #> [1] FALSE
> >>
> >> Best,
> >>
> >> Antoine
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
>
> >   [[alternative HTML version deleted]]
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] R CMD check "unable to verify current time"

[Duncan Murdoch]

R tries to get the time from

http://worldtimeapi.org/api/timezone/UTC or
http://worldclockapi.com/api/json/utc/now

The first one doesn't accept UTC as a timezone; it appears to want 
etc/UTC instead.  The second one is offline.


Duncan Murdoch

If both of those fail, you'll get the message you saw.

On 27/08/2020 1:23 p.m., John Fox wrote:

Dear r-package-devel list members,

I got the following note when checking two different packages today
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and
macOS Catalina systems, and on several platforms on rhub:

* checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned
this problem recently, in case it's produced by something that I'm
doing. There is a discussion of a similar problem from 2019 at
.

Both packages that I was checking are close to CRAN releases and so I'd
like to know whether I can disregard the note.

Any help would be appreciated.

John



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

Re: [R-pkg-devel] changing maintainer email address

[Michael Dewey]

Dear Josef

From the policy

Explain any change in the maintainer’s email address and if possible 
send confirmation from the previous address (by a separate email to 
cran-submissi...@r-project.org) or explain why it is not possible.


Burned into my cortex since I did it incorrectly a few years back.

Michael

On 27/08/2020 17:45, Tracy, Josef wrote:

Hi,

I submitted a package, "PhysActBedRest" to the CRAN a couple of years ago and 
am trying to update it.  In writing the update, I realized I forgot to update my email 
address when I changed institutions.  As a consequence, when I run CMD check on the 
updated package there is a NOTE that the maintainer has changed.  How to I get my update 
to pass the check and correct my email address?

Thanks,
Dustin

[[alternative HTML version deleted]]

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



--
Michael
http://www.dewey.myzen.co.uk/home.html

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

[R-pkg-devel] R CMD check "unable to verify current time"

[John Fox]

Dear r-package-devel list members,

I got the following note when checking two different packages today 
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and 
macOS Catalina systems, and on several platforms on rhub:


* checking for future file timestamps ... NOTE
unable to verify current time

I'm writing to inquire about the note because no one else has mentioned 
this problem recently, in case it's produced by something that I'm 
doing. There is a discussion of a similar problem from 2019 at 
.


Both packages that I was checking are close to CRAN releases and so I'd 
like to know whether I can disregard the note.


Any help would be appreciated.

John

--
John Fox, Professor Emeritus
McMaster University
Hamilton, Ontario, Canada
web: https://socialsciences.mcmaster.ca/jfox/

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

[R-pkg-devel] changing maintainer email address

[Tracy, Josef]

Hi,

I submitted a package, "PhysActBedRest" to the CRAN a couple of years ago and 
am trying to update it.  In writing the update, I realized I forgot to update 
my email address when I changed institutions.  As a consequence, when I run CMD 
check on the updated package there is a NOTE that the maintainer has changed.  
How to I get my update to pass the check and correct my email address?

Thanks,
Dustin

[[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] Package inputenc Error: Unicode char ‐ (U+2010) during Windows build

[Joshua Harrison]

Hi Uwe,

Thanks for the response and for mentioning the 'tools::' functions. Those
functions were super helpful in identifying a hyphen that I missed in a
supporting file that roxygen used to build the manual.

My package builds without warnings and errors now on a few systems, so I
think I am good to go. Thanks again.

jh

On Thu, Aug 27, 2020 at 6:16 AM Uwe Ligges 
wrote:

> Hyphens that, e.g., get auto generated in MS Word are non ASCII. You
> have to declare an appropriate encoding, or even better, replace by
> regular hypehsn.
>
> See functions
>
> tools:::showNonASCII tools:::showNonASCIIfile
>
> that may help to see where these are...
>
> Best,
> Uwe Ligges
>
> On 25.08.2020 20:39, Joshua Harrison wrote:
> > Hi all,
> >
> > I cannot get my package to correctly build on Windows because of an
> > encoding error that I just can't figure out. The package builds on my Mac
> > (10.14.6) and on a recent Debian release.
> >
> > The source code for the package can be viewed here:
> > https://github.com/JHarrisonEcoEvo/CNVRG
> >
> > The error code thrown by the "check_win_release" function of devtools is:
> >
> > * 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.
> >
> > See the inputenc package documentation for explanation.
> > Type  H   for immediate help.
> > ! 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.
> > * checking PDF version of manual without hyperrefs or index ... ERROR
> > * checking for detritus in the temp directory ... OK
> > * DONE
> > Status: 1 ERROR, 1 WARNING, 1 NOTE
> >
> > FYI the note referenced is because the package is a new submission.
> >
> > I figured the problem was with hyphens (the unicode 2010) and so I went
> > through the manual and vignette and deleted all the hyphens in the
> regular
> > text. There are still hyphen symbols in the assignment operator of the
> > examples ("<-"). Are these the problem?
> >
> > I have spent way too much time trying to figure this out so any help
> would
> > be greatly appreciated. I see that many folks have similar issues with
> > vignettes and manuals but I haven't found a solution that works for me.
> >
> > I am completely fine not having the package build on Windows. Users of
> that
> > system can download the manual or view it in a browser. However, I don't
> > see how I can get the package on CRAN without fixing this.
> >
> > Thanks for your time and assistance!
> >
> > --
> > J. G. Harrison
> > Postdoctoral researcher
> > University of Wyoming
> > jgharrison.weebly.com
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>


-- 
J. G. Harrison
Postdoctoral researcher
University of Wyoming
jgharrison.weebly.com

[[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] Package inputenc Error: Unicode char ‐ (U+2010) during Windows build

[Uwe Ligges]

Hyphens that, e.g., get auto generated in MS Word are non ASCII. You 
have to declare an appropriate encoding, or even better, replace by 
regular hypehsn.


See functions

tools:::showNonASCII tools:::showNonASCIIfile

that may help to see where these are...

Best,
Uwe Ligges

On 25.08.2020 20:39, Joshua Harrison wrote:

Hi all,

I cannot get my package to correctly build on Windows because of an
encoding error that I just can't figure out. The package builds on my Mac
(10.14.6) and on a recent Debian release.

The source code for the package can be viewed here:
https://github.com/JHarrisonEcoEvo/CNVRG

The error code thrown by the "check_win_release" function of devtools is:

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

See the inputenc package documentation for explanation.
Type  H   for immediate help.
! 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.
* checking PDF version of manual without hyperrefs or index ... ERROR
* checking for detritus in the temp directory ... OK
* DONE
Status: 1 ERROR, 1 WARNING, 1 NOTE

FYI the note referenced is because the package is a new submission.

I figured the problem was with hyphens (the unicode 2010) and so I went
through the manual and vignette and deleted all the hyphens in the regular
text. There are still hyphen symbols in the assignment operator of the
examples ("<-"). Are these the problem?

I have spent way too much time trying to figure this out so any help would
be greatly appreciated. I see that many folks have similar issues with
vignettes and manuals but I haven't found a solution that works for me.

I am completely fine not having the package build on Windows. Users of that
system can download the manual or view it in a browser. However, I don't
see how I can get the package on CRAN without fixing this.

Thanks for your time and assistance!

--
J. G. Harrison
Postdoctoral researcher
University of Wyoming
jgharrison.weebly.com

[[alternative HTML version deleted]]

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



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

Re: [Bioc-devel] Request package deprecation

[Levi Waldron]

Gives me some nostalgia because I think simpleaffy was the first
Bioconductor package I used!

Il gio 27 ago 2020, 1:46 PM Shepherd, Lori 
ha scritto:

> Thank you for letting us know.  I will begin the deprecation process for
> the package. Thank you for your contributions.
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Comprehensive Cancer Center
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
> 
> From: Bioc-devel  on behalf of Crispin
> Miller 
> Sent: Thursday, August 27, 2020 5:27 AM
> To: bioc-devel@r-project.org 
> Subject: [Bioc-devel] Request package deprecation
>
> Hi there,
> I’ve moved email address since creation of this package but I would like
> to request deprecation and End of Life for the package: simpleaffy
> It’s been superseded and is out of date.
> Best wishes,
> Crispin Miller
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1S5t_kZfp7KIuKk2nhIwrOOUEOKYE6QnqQllq1o6CuOQPo4D_XAA6tA7BRvH-TBjgPnHJJ1IVX4_2nqN_EEttB75YuGmvUkptBPspTehGflEckX6vtIBR1KOkSBacnc9-Ki8bt1x93TLB4uy4IdLPG20jZmsjh7E8Wbb8seF3PyCY6Y7Y5NlgnvLQ6ieRe5EXgCD9EVw3kE9u1bARizh1P-H6eqi0GlWOu2eDyfVkqfo9N2auYrWoj-6Hu4i6KR_WESJ8Skg3-O6IzNUZmEJlMn4KORk1EIrXCI6KwBF5UEbexI4e0RgisEi-1Vha_EolAawWkIRXzk0Oi5HdVqrq0g/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel
>
>
> This email message may contain legally privileged and/or confidential
> information.  If you are not the intended recipient(s), or the employee or
> agent responsible for the delivery of this message to the intended
> recipient(s), you are hereby notified that any disclosure, copying,
> distribution, or use of this email message is prohibited.  If you have
> received this message in error, please notify the sender immediately by
> e-mail and delete this email message from your computer. Thank you.
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Request package deprecation

[Shepherd, Lori]

Thank you for letting us know.  I will begin the deprecation process for the 
package. Thank you for your contributions.


Lori Shepherd

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Crispin Miller 

Sent: Thursday, August 27, 2020 5:27 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Request package deprecation

Hi there,
I�ve moved email address since creation of this package but I would like to 
request deprecation and End of Life for the package: simpleaffy
It�s been superseded and is out of date.
Best wishes,
Crispin Miller


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1S5t_kZfp7KIuKk2nhIwrOOUEOKYE6QnqQllq1o6CuOQPo4D_XAA6tA7BRvH-TBjgPnHJJ1IVX4_2nqN_EEttB75YuGmvUkptBPspTehGflEckX6vtIBR1KOkSBacnc9-Ki8bt1x93TLB4uy4IdLPG20jZmsjh7E8Wbb8seF3PyCY6Y7Y5NlgnvLQ6ieRe5EXgCD9EVw3kE9u1bARizh1P-H6eqi0GlWOu2eDyfVkqfo9N2auYrWoj-6Hu4i6KR_WESJ8Skg3-O6IzNUZmEJlMn4KORk1EIrXCI6KwBF5UEbexI4e0RgisEi-1Vha_EolAawWkIRXzk0Oi5HdVqrq0g/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

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

[Bioc-devel] Request package deprecation

[Crispin Miller]

Hi there,
I’ve moved email address since creation of this package but I would like to 
request deprecation and End of Life for the package: simpleaffy
It’s been superseded and is out of date.
Best wishes,
Crispin Miller


[[alternative HTML version deleted]]

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