Re: [R-pkg-devel] new package processing time

2020-02-03 Thread Roy Mendelssohn - NOAA Federal via R-package-devel
Did you check on https://itsalocke.com/cransays/articles/dashboard?  If it is a 
first time submission,  there is a code review and that can take some time.

-Roy

> On Feb 3, 2020, at 3:56 PM, Marcelo Araya Salas  wrote:
> 
> Hi all
> 
> I submitted a new package to CRAN a couple of weeks ago. Does anyone know
> how long does it take for the package to be processed? New package versions
> are usually processed in a few hours so that's why I am wondering if
> everything is fine.
> 
> thanks
> 
> Marcelo
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

**
"The contents of this message do not reflect any position of the U.S. 
Government or NOAA."
**
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected" 
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.

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


[R-pkg-devel] new package processing time

2020-02-03 Thread Marcelo Araya Salas
Hi all

I submitted a new package to CRAN a couple of weeks ago. Does anyone know
how long does it take for the package to be processed? New package versions
are usually processed in a few hours so that's why I am wondering if
everything is fine.

thanks

Marcelo

[[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] finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

2020-02-03 Thread Dirk Eddelbuettel


On 3 February 2020 at 23:58, Ivan Krylov wrote:
| On Mon, 3 Feb 2020 13:30:11 -0600
| Spencer Graves  wrote:
| 
| > logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep 
| > = .Platform$file.sep)
| 
| I wonder whether file.path(R.home('doc'), 'html', 'logo.jpg') would be
| more portable. Are there R installations built without the HTML docs?

It's the only correct form. And of course it finds the desired file:

   R> file.path(R.home('doc'), 'html', 'logo.jpg')
   [1] "/usr/share/R/doc/html/logo.jpg"
   R> 

because it knows about

   R> Sys.getenv("R_SHARE_DIR")
   [1] "/usr/share/R/share"
   R>

because, as Inaki reminded everyone, most distro had non-architecture
dependent files below /usr/share for years.

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


Re: [R-pkg-devel] [EXTERNAL] Re: finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

2020-02-03 Thread Hong Ooi via R-package-devel
I echo this. Relying on something undocumented and platform-specific, like the 
location of a random installation file, is just asking for problems. Instead, 
make a small image of your own and distribute it with your package.

-Original Message-
From: R-package-devel  On Behalf Of Ben 
Bolker
Sent: Tuesday, 4 February 2020 7:16 AM
To: r-package-devel@r-project.org
Subject: [EXTERNAL] Re: [R-pkg-devel] finding "logo.jpg" [was: "try" 
malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]


  Maybe include your own version of logo.jpg in inst/ ?

On 2020-02-03 2:30 p.m., Spencer Graves wrote:
>   Thanks to Iñaki Ucar for identifying a second error that explained
> why I still got an error after wrapping one in "try".
> 
> 
>   That still leaves a question of how to find a file like "logo.jpg"
> in a platform independant way.
> 
> 
>       The following had worked for several years and now broke on rhub
> "Ubuntu Linux 16.04 LTS, R-release, GCC" but not on several other
> computers I tried:
> 
> 
>         logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep =
> .Platform$file.sep)
> 
> 
>   On that Ubuntu platform, "readJPEG(logo.jpg)" stopped with "Error
> in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg".
> 
> 
>   I replaced the above "paste" with the following:
> 
> 
> RdocDir <- dir(R.home(), pattern='^doc$', full.names = TRUE)
> RhtmlDir <- dir(RdocDir, pattern='^html$', full.names=TRUE)
> JPGs <- dir(RhtmlDir, pattern='.jpg$', full.names=TRUE)
> if(length(JPGs)>1){
>   logoJPG <- paste0(.Platform$file.sep, 'logo.jpg$')
>   logo.jpg <- grep(logoJPG, JPGs, value=TRUE)
>   if(length(logo.jpg)>1)logo.jpg <- logo.jpg[1]
>   if(length(logo.jpg)<1)logo.jpg <- JPGs[1]
> } else logo.jpg <- JPGs
> if(length(logo.jpg)<1){
>   cat('logo.jpg not found.\n')
>   print(R.home())
>   print(dir(RdocDir))
>   print(dir(RhtmlDir))
>   if(!fda::CRAN())stop('logo.jpg not found')
> } else {
> # length(logo.jpg)==1 so continue:
>   if(require(jpeg)){
> ##
> ## 1.  Shrink as required
> ##
>     Rlogo <- readJPEG(logo.jpg)
> 
> ...
> 
> 
>       This gave me no error message, which I believe means that either
> length(logo.jpg) == 1 or fda::CRAN() returns TRUE.  Sadly, I could not
> find the standard test file to see which of these is the case.
> 
> 
>   I should proceed to submit the current Ecfun package to CRAN. Then
> I might modify this test sequence to force an error, so I can see more
> what is happening.
> 
> 
>   Suggestions?
>   Thanks,
>   Spencer
> 
> 
> On 2020-02-03 03:06, Iñaki Ucar wrote:
>> On Mon, 3 Feb 2020 at 03:16, Spencer Graves
>>  wrote:
>>> Hello, All:
>>>
>>>
>>>     devtools::check_rhub failed to trap an error wrapped in "try",
>>> per the email below.  This came from running
>>> devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of
>>> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsbgraves237%2FEcfun&data=02%7C01%7Chongooi%40microsoft.com%7C757daa698b0a4830eaa908d7a8e5e496%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637163577651198242&sdata=NW7oju2vYnhaaYnNnP8q%2F5yG1Vqusa21CMnTQtUwPAs%3D&reserved=0";.
>> That's improbable.
>>
>>>     This is the development version of Ecfun, which I want to submit
>>> to CRAN as soon as I can do so without offending the sensibilities of
>>> the overworked CRAN maintainers.
>>>
>>>
>>>     Suggestions?
>>>     Thanks,
>>>     Spencer Graves
>>>
>>>
>>>  Forwarded Message 
>>> Subject:    Ecfun 0.2-2: ERROR
>>> Date:   Sun, 02 Feb 2020 23:27:10 +
>>> From:   R-hub builder 
>>> To: spencer.gra...@effectivedefense.org
>>>
>> 
>>
 ## 2.9.  A more complicated example with elements to eval
 ##
 logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg",
>>> +   sep = .Platform$file.sep)
 if(require(jpeg)){
>>> +   Rlogo <- try(readJPEG(logo.jpg))
>>> +   if(!inherits(Rlogo, 'try-error')){
>>> + # argument list for a call to rasterImage or rasterImageAdj
>>> + RlogoLoc <- list(image=Rlogo,
>>> +   xleft.0 = c(NZ=176.5,CH=172,US=171,
>>> +   CN=177,RU= 9.5,UK= 8),
>>> +   xleft.1 = c(NZ=176.5,CH=  9,US=-73.5,
>>> +   CN=125,RU= 37, UK= 2),
>>> +   ybottom.0=c(NZ=-37,  CH=-34,US=-34,
>>> +   CN=-33,RU= 48, UK=47),
>>> +   ybottom.1=c(NZ=-37,  CH= 47,US= 46,
>>> +   CN= 32,RU=55.6,UK=55),
>>> +   xright=quote(xleft+xinch(0.6)),
>>> +   ytop = quote(ybottom+yinch(0.6)),
>>> +   angle.0 =0,
>>> +   angle.1 =c(NZ=0,CH=3*360,US=5*360,
>>> +  CN=2*360,RU=360,UK=360)
>>> + )
>>> +
>>> + RlogoInterp <- interpPairs(RlogoLoc,
>>> + .proportion=rep(c(0, -1), c(2, 4)) )
>>> + # check
>>> + ## Don't show:
>>> + stopifnot(
>>> + ## End(Don't show)
>>> + all.equal(names(RlogoInterp),
>>> +    c('image', 'xright', 'ytop', 'xleft', 'ybottom', 'angle'))
>>> +

Re: [R-pkg-devel] finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

2020-02-03 Thread Ivan Krylov
On Mon, 3 Feb 2020 13:30:11 -0600
Spencer Graves  wrote:

> logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep 
> = .Platform$file.sep)

I wonder whether file.path(R.home('doc'), 'html', 'logo.jpg') would be
more portable. Are there R installations built without the HTML docs?

-- 
Best regards,
Ivan

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


Re: [R-pkg-devel] finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

2020-02-03 Thread Iñaki Ucar
El lun., 3 feb. 2020 20:30, Spencer Graves <
spencer.gra...@effectivedefense.org> escribió:

>Thanks to Iñaki Ucar for identifying a second error that
> explained why I still got an error after wrapping one in "try".
>
>
>That still leaves a question of how to find a file like
> "logo.jpg" in a platform independant way.
>
>
>The following had worked for several years and now broke on rhub
> "Ubuntu Linux 16.04 LTS, R-release, GCC" but not on several other
> computers I tried:
>
>
>  logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep
> = .Platform$file.sep)
>
>
>On that Ubuntu platform, "readJPEG(logo.jpg)" stopped with "Error
> in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg".


All these years you just got lucky that on CRAN the PNG is in that
location. That's not the location in Fedora, and I'd say that's not the
location in other distributions, because documentation is usually under
/usr/share.

But ultimately the test is faulty, because if the "try" call returns an
error, then later you are trying to use an undefined object.

Iñaki

[[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] [FORGED] Re: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

2020-02-03 Thread Rolf Turner



On 4/02/20 3:03 am, profjohn wrote:





While there are huge benefits to upgrading, there is pain. It's that
pain that keeps people on OS versions that are older but still in the
LTS [1] period.




Fortune nomination!

cheers,

Rolf

[1] Long Term Support

--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276

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


Re: [R-pkg-devel] finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

2020-02-03 Thread Ben Bolker


  Maybe include your own version of logo.jpg in inst/ ?

On 2020-02-03 2:30 p.m., Spencer Graves wrote:
>   Thanks to Iñaki Ucar for identifying a second error that explained
> why I still got an error after wrapping one in "try".
> 
> 
>   That still leaves a question of how to find a file like "logo.jpg"
> in a platform independant way.
> 
> 
>       The following had worked for several years and now broke on rhub
> "Ubuntu Linux 16.04 LTS, R-release, GCC" but not on several other
> computers I tried:
> 
> 
>         logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep =
> .Platform$file.sep)
> 
> 
>   On that Ubuntu platform, "readJPEG(logo.jpg)" stopped with "Error
> in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg".
> 
> 
>   I replaced the above "paste" with the following:
> 
> 
> RdocDir <- dir(R.home(), pattern='^doc$', full.names = TRUE)
> RhtmlDir <- dir(RdocDir, pattern='^html$', full.names=TRUE)
> JPGs <- dir(RhtmlDir, pattern='.jpg$', full.names=TRUE)
> if(length(JPGs)>1){
>   logoJPG <- paste0(.Platform$file.sep, 'logo.jpg$')
>   logo.jpg <- grep(logoJPG, JPGs, value=TRUE)
>   if(length(logo.jpg)>1)logo.jpg <- logo.jpg[1]
>   if(length(logo.jpg)<1)logo.jpg <- JPGs[1]
> } else logo.jpg <- JPGs
> if(length(logo.jpg)<1){
>   cat('logo.jpg not found.\n')
>   print(R.home())
>   print(dir(RdocDir))
>   print(dir(RhtmlDir))
>   if(!fda::CRAN())stop('logo.jpg not found')
> } else {
> # length(logo.jpg)==1 so continue:
>   if(require(jpeg)){
> ##
> ## 1.  Shrink as required
> ##
>     Rlogo <- readJPEG(logo.jpg)
> 
> ...
> 
> 
>       This gave me no error message, which I believe means that either
> length(logo.jpg) == 1 or fda::CRAN() returns TRUE.  Sadly, I could not
> find the standard test file to see which of these is the case.
> 
> 
>   I should proceed to submit the current Ecfun package to CRAN. Then
> I might modify this test sequence to force an error, so I can see more
> what is happening.
> 
> 
>   Suggestions?
>   Thanks,
>   Spencer
> 
> 
> On 2020-02-03 03:06, Iñaki Ucar wrote:
>> On Mon, 3 Feb 2020 at 03:16, Spencer Graves
>>  wrote:
>>> Hello, All:
>>>
>>>
>>>     devtools::check_rhub failed to trap an error wrapped in "try",
>>> per the email below.  This came from running
>>> devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of
>>> "https://github.com/sbgraves237/Ecfun";.
>> That's improbable.
>>
>>>     This is the development version of Ecfun, which I want to submit
>>> to CRAN as soon as I can do so without offending the sensibilities of
>>> the overworked CRAN maintainers.
>>>
>>>
>>>     Suggestions?
>>>     Thanks,
>>>     Spencer Graves
>>>
>>>
>>>  Forwarded Message 
>>> Subject:    Ecfun 0.2-2: ERROR
>>> Date:   Sun, 02 Feb 2020 23:27:10 +
>>> From:   R-hub builder 
>>> To: spencer.gra...@effectivedefense.org
>>>
>> 
>>
 ## 2.9.  A more complicated example with elements to eval
 ##
 logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg",
>>> +   sep = .Platform$file.sep)
 if(require(jpeg)){
>>> +   Rlogo <- try(readJPEG(logo.jpg))
>>> +   if(!inherits(Rlogo, 'try-error')){
>>> + # argument list for a call to rasterImage or rasterImageAdj
>>> + RlogoLoc <- list(image=Rlogo,
>>> +   xleft.0 = c(NZ=176.5,CH=172,US=171,
>>> +   CN=177,RU= 9.5,UK= 8),
>>> +   xleft.1 = c(NZ=176.5,CH=  9,US=-73.5,
>>> +   CN=125,RU= 37, UK= 2),
>>> +   ybottom.0=c(NZ=-37,  CH=-34,US=-34,
>>> +   CN=-33,RU= 48, UK=47),
>>> +   ybottom.1=c(NZ=-37,  CH= 47,US= 46,
>>> +   CN= 32,RU=55.6,UK=55),
>>> +   xright=quote(xleft+xinch(0.6)),
>>> +   ytop = quote(ybottom+yinch(0.6)),
>>> +   angle.0 =0,
>>> +   angle.1 =c(NZ=0,CH=3*360,US=5*360,
>>> +  CN=2*360,RU=360,UK=360)
>>> + )
>>> +
>>> + RlogoInterp <- interpPairs(RlogoLoc,
>>> + .proportion=rep(c(0, -1), c(2, 4)) )
>>> + # check
>>> + ## Don't show:
>>> + stopifnot(
>>> + ## End(Don't show)
>>> + all.equal(names(RlogoInterp),
>>> +    c('image', 'xright', 'ytop', 'xleft', 'ybottom', 'angle'))
>>> + ## Don't show:
>>> + )
>>> + ## End(Don't show)
>>> + }
>>> + # NOTE:  'xleft', and 'ybottom' were created in interpPairs,
>>> + # and therefore come after 'xright' and 'ytop', which were
>>> + # already there.
>>> +
>>> + ##
>>> + ## 2.10.  using envir
>>> + ##
>>> +   RlogoDiag <- list(x0=quote(Rlogo.$xleft),
>>> +   y0=quote(Rlogo.$ybottom),
>>> +   x1=quote(Rlogo.$xright),
>>> +   y1=quote(Rlogo.$ytop) )
>>> +
>>> +   RlogoD <- interpPairs(RlogoDiag, .p=1,
>>> + envir=list(Rlogo.=RlogoInterp) )
>>> + ## Don't show:
>>> + stopifnot(
>>> + ## End(Don't show)
>>> + all.equal(RlogoD, RlogoDiag)
>>> + ## Don't show:
>>> + )
>>> + ## End(Don't show)
>>> + }
>>> Loading required package: jpeg

[R-pkg-devel] finding "logo.jpg" [was: "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC]

2020-02-03 Thread Spencer Graves
  Thanks to Iñaki Ucar for identifying a second error that 
explained why I still got an error after wrapping one in "try".



  That still leaves a question of how to find a file like 
"logo.jpg" in a platform independant way.



      The following had worked for several years and now broke on rhub 
"Ubuntu Linux 16.04 LTS, R-release, GCC" but not on several other 
computers I tried:



        logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg", sep 
= .Platform$file.sep)



  On that Ubuntu platform, "readJPEG(logo.jpg)" stopped with "Error 
in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg".



  I replaced the above "paste" with the following:


RdocDir <- dir(R.home(), pattern='^doc$', full.names = TRUE)
RhtmlDir <- dir(RdocDir, pattern='^html$', full.names=TRUE)
JPGs <- dir(RhtmlDir, pattern='.jpg$', full.names=TRUE)
if(length(JPGs)>1){
  logoJPG <- paste0(.Platform$file.sep, 'logo.jpg$')
  logo.jpg <- grep(logoJPG, JPGs, value=TRUE)
  if(length(logo.jpg)>1)logo.jpg <- logo.jpg[1]
  if(length(logo.jpg)<1)logo.jpg <- JPGs[1]
} else logo.jpg <- JPGs
if(length(logo.jpg)<1){
  cat('logo.jpg not found.\n')
  print(R.home())
  print(dir(RdocDir))
  print(dir(RhtmlDir))
  if(!fda::CRAN())stop('logo.jpg not found')
} else {
# length(logo.jpg)==1 so continue:
  if(require(jpeg)){
##
## 1.  Shrink as required
##
    Rlogo <- readJPEG(logo.jpg)

...


      This gave me no error message, which I believe means that either 
length(logo.jpg) == 1 or fda::CRAN() returns TRUE.  Sadly, I could not 
find the standard test file to see which of these is the case.



  I should proceed to submit the current Ecfun package to CRAN. 
Then I might modify this test sequence to force an error, so I can see 
more what is happening.



  Suggestions?
  Thanks,
  Spencer


On 2020-02-03 03:06, Iñaki Ucar wrote:

On Mon, 3 Feb 2020 at 03:16, Spencer Graves
 wrote:

Hello, All:


devtools::check_rhub failed to trap an error wrapped in "try",
per the email below.  This came from running
devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of
"https://github.com/sbgraves237/Ecfun";.

That's improbable.


This is the development version of Ecfun, which I want to submit
to CRAN as soon as I can do so without offending the sensibilities of
the overworked CRAN maintainers.


Suggestions?
Thanks,
Spencer Graves


 Forwarded Message 
Subject:Ecfun 0.2-2: ERROR
Date:   Sun, 02 Feb 2020 23:27:10 +
From:   R-hub builder 
To: spencer.gra...@effectivedefense.org





## 2.9.  A more complicated example with elements to eval
##
logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg",

+   sep = .Platform$file.sep)

if(require(jpeg)){

+   Rlogo <- try(readJPEG(logo.jpg))
+   if(!inherits(Rlogo, 'try-error')){
+ # argument list for a call to rasterImage or rasterImageAdj
+ RlogoLoc <- list(image=Rlogo,
+   xleft.0 = c(NZ=176.5,CH=172,US=171,
+   CN=177,RU= 9.5,UK= 8),
+   xleft.1 = c(NZ=176.5,CH=  9,US=-73.5,
+   CN=125,RU= 37, UK= 2),
+   ybottom.0=c(NZ=-37,  CH=-34,US=-34,
+   CN=-33,RU= 48, UK=47),
+   ybottom.1=c(NZ=-37,  CH= 47,US= 46,
+   CN= 32,RU=55.6,UK=55),
+   xright=quote(xleft+xinch(0.6)),
+   ytop = quote(ybottom+yinch(0.6)),
+   angle.0 =0,
+   angle.1 =c(NZ=0,CH=3*360,US=5*360,
+  CN=2*360,RU=360,UK=360)
+ )
+
+ RlogoInterp <- interpPairs(RlogoLoc,
+ .proportion=rep(c(0, -1), c(2, 4)) )
+ # check
+ ## Don't show:
+ stopifnot(
+ ## End(Don't show)
+ all.equal(names(RlogoInterp),
+c('image', 'xright', 'ytop', 'xleft', 'ybottom', 'angle'))
+ ## Don't show:
+ )
+ ## End(Don't show)
+ }
+ # NOTE:  'xleft', and 'ybottom' were created in interpPairs,
+ # and therefore come after 'xright' and 'ytop', which were
+ # already there.
+
+ ##
+ ## 2.10.  using envir
+ ##
+   RlogoDiag <- list(x0=quote(Rlogo.$xleft),
+   y0=quote(Rlogo.$ybottom),
+   x1=quote(Rlogo.$xright),
+   y1=quote(Rlogo.$ytop) )
+
+   RlogoD <- interpPairs(RlogoDiag, .p=1,
+ envir=list(Rlogo.=RlogoInterp) )
+ ## Don't show:
+ stopifnot(
+ ## End(Don't show)
+ all.equal(RlogoD, RlogoDiag)
+ ## Don't show:
+ )
+ ## End(Don't show)
+ }
Loading required package: jpeg
Error in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg
Error in interpPairs.list(RlogoDiag, .p = 1, envir = list(Rlogo. = 
RlogoInterp)) :
object 'RlogoInterp' not found
Calls: interpPairs -> interpPairs.list
Execution halted

There it is: "Error in interpPairs.list [...] 'RlogoInterp' not
found". That's the error, not the "try". You see the error message
because you didn't specify "quiet=TRUE", but that doesn't mean that R
is failing to catch the error. So the second error is the one that
fails.

Iñaki


___

Re: [R-pkg-devel] "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

2020-02-03 Thread Dirk Eddelbuettel


On 3 February 2020 at 09:03, profjohn wrote:
| While there are huge benefits to upgrading, there is pain. It's that

We have a dedicated mailing list r-sig-debian for use of R on operating
systems that are .deb based. It is low volume, and has high signal / noise.
So I would cordially invite everybody who thinks he or she could benefit from
asking questions there to sign up.

My question was indirectly answered by Spencer: he actually did not make an
_explicit_ choice to use 16.04. He used a helper function dispatching to a
service still running the rather old release.

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


Re: [R-pkg-devel] "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

2020-02-03 Thread Ben Bolker



> 
> While there are huge benefits to upgrading, there is pain. It's that
> pain that keeps people on OS versions that are older but still in the
> LTS period.

   More or less what I was going to say.
> 
> Best, JN
> 
> 
> On 2/3/20 12:27 AM, Dirk Eddelbuettel wrote:
>>
>> On 2 February 2020 at 21:47, Ben Bolker wrote:
>> |   Maybe an Rhub glitch.  I just ran R CMD check with a recent r-devel
>> | (2019-12-03 r77509) on Ubuntu 16.04 with no problems.
>>
>> Is there a reason that keeps _both_ of you on Ubuntu 16.04 which has been
>> replaced _nearly two years ago_ by the subsequent LTS release 18.04 ?
>>
>> Michael works hard to provide _an awesome_ experience using the current LTS
>> release_ 18.04 that I am really hard-pressed to see why 16.04 would matter.
>>
>> Dirk
>>

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


Re: [R-pkg-devel] "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

2020-02-03 Thread profjohn
Looks like Spencer's issue solved in another post.

And this isn't a criticism of Dirk's contribution, just a partial
explanation of some of the noise that occurs.

I use Linux Mint -- family members are still recovering from Win XP.
But LM 18.x is based on Ubuntu 16.04. So I found recently that the
CRAN check_packages_in_dir() (if I remember the syntax) and Gabor C's
package revdepcheck didn't work. Latter reported as an issue.

On two of my machines I have LM 19.x. However, I'm travelling, and so
I tried upgrading one of my laptops with mintupgrade. Bad idea -- got a
very weird lockup situation -- I could boot to a login screen, but that
would accept the password and return to the login screen. Had to do a
bare metal reinstall. Painful, but revdepcheck now works and revealed a
small but vital typo in one line of my package. Sigh.

While there are huge benefits to upgrading, there is pain. It's that
pain that keeps people on OS versions that are older but still in the
LTS period.

Best, JN


On 2/3/20 12:27 AM, Dirk Eddelbuettel wrote:
> 
> On 2 February 2020 at 21:47, Ben Bolker wrote:
> |   Maybe an Rhub glitch.  I just ran R CMD check with a recent r-devel
> | (2019-12-03 r77509) on Ubuntu 16.04 with no problems.
> 
> Is there a reason that keeps _both_ of you on Ubuntu 16.04 which has been
> replaced _nearly two years ago_ by the subsequent LTS release 18.04 ?
> 
> Michael works hard to provide _an awesome_ experience using the current LTS
> release_ 18.04 that I am really hard-pressed to see why 16.04 would matter.
> 
> Dirk
>

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


Re: [R-pkg-devel] "try" malfunctions on Ubuntu Linux 16.04 LTS, R-release, GCC

2020-02-03 Thread Iñaki Ucar
On Mon, 3 Feb 2020 at 03:16, Spencer Graves
 wrote:
>
> Hello, All:
>
>
>devtools::check_rhub failed to trap an error wrapped in "try",
> per the email below.  This came from running
> devtools::check_rhub(Ecfun_dir), where Ecfun_dir = the path to a copy of
> "https://github.com/sbgraves237/Ecfun";.

That's improbable.

>This is the development version of Ecfun, which I want to submit
> to CRAN as soon as I can do so without offending the sensibilities of
> the overworked CRAN maintainers.
>
>
>Suggestions?
>Thanks,
>Spencer Graves
>
>
>  Forwarded Message 
> Subject:Ecfun 0.2-2: ERROR
> Date:   Sun, 02 Feb 2020 23:27:10 +
> From:   R-hub builder 
> To: spencer.gra...@effectivedefense.org
>



> > ## 2.9.  A more complicated example with elements to eval
> > ##
> > logo.jpg <- paste(R.home(), "doc", "html", "logo.jpg",
> +   sep = .Platform$file.sep)
> > if(require(jpeg)){
> +   Rlogo <- try(readJPEG(logo.jpg))
> +   if(!inherits(Rlogo, 'try-error')){
> + # argument list for a call to rasterImage or rasterImageAdj
> + RlogoLoc <- list(image=Rlogo,
> +   xleft.0 = c(NZ=176.5,CH=172,US=171,
> +   CN=177,RU= 9.5,UK= 8),
> +   xleft.1 = c(NZ=176.5,CH=  9,US=-73.5,
> +   CN=125,RU= 37, UK= 2),
> +   ybottom.0=c(NZ=-37,  CH=-34,US=-34,
> +   CN=-33,RU= 48, UK=47),
> +   ybottom.1=c(NZ=-37,  CH= 47,US= 46,
> +   CN= 32,RU=55.6,UK=55),
> +   xright=quote(xleft+xinch(0.6)),
> +   ytop = quote(ybottom+yinch(0.6)),
> +   angle.0 =0,
> +   angle.1 =c(NZ=0,CH=3*360,US=5*360,
> +  CN=2*360,RU=360,UK=360)
> + )
> +
> + RlogoInterp <- interpPairs(RlogoLoc,
> + .proportion=rep(c(0, -1), c(2, 4)) )
> + # check
> + ## Don't show:
> + stopifnot(
> + ## End(Don't show)
> + all.equal(names(RlogoInterp),
> +c('image', 'xright', 'ytop', 'xleft', 'ybottom', 'angle'))
> + ## Don't show:
> + )
> + ## End(Don't show)
> + }
> + # NOTE:  'xleft', and 'ybottom' were created in interpPairs,
> + # and therefore come after 'xright' and 'ytop', which were
> + # already there.
> +
> + ##
> + ## 2.10.  using envir
> + ##
> +   RlogoDiag <- list(x0=quote(Rlogo.$xleft),
> +   y0=quote(Rlogo.$ybottom),
> +   x1=quote(Rlogo.$xright),
> +   y1=quote(Rlogo.$ytop) )
> +
> +   RlogoD <- interpPairs(RlogoDiag, .p=1,
> + envir=list(Rlogo.=RlogoInterp) )
> + ## Don't show:
> + stopifnot(
> + ## End(Don't show)
> + all.equal(RlogoD, RlogoDiag)
> + ## Don't show:
> + )
> + ## End(Don't show)
> + }
> Loading required package: jpeg
> Error in readJPEG(logo.jpg) : unable to open /usr/lib/R/doc/html/logo.jpg
> Error in interpPairs.list(RlogoDiag, .p = 1, envir = list(Rlogo. = 
> RlogoInterp)) :
>object 'RlogoInterp' not found
> Calls: interpPairs -> interpPairs.list
> Execution halted

There it is: "Error in interpPairs.list [...] 'RlogoInterp' not
found". That's the error, not the "try". You see the error message
because you didn't specify "quiet=TRUE", but that doesn't mean that R
is failing to catch the error. So the second error is the one that
fails.

Iñaki

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