[Rd] POSIXlt$zone and $gmtoff questions

[William Dunlap via R-devel]

I've been searching for patterns in why some POSIXlt objects have the zone
and gmtoff components and some don't and why gmtoff is sometimes NA when
the zone is known.  Is there a pattern or is it just that the additional
fields and workarounds were added in an ad hoc way?

E.g.,  as.POSIXlt adds the zone and gmtoff components for all strings and
logical NA inputs if the time zone is not GMT or UTC

f <- function (lt)  {
stopifnot(inherits(lt, "POSIXlt"))
cat(format(lt), ", $zone=", deparse(lt$zone), ", $gmtoff=",
deparse(lt$gmtoff), "\n", sep = "")
}
f(as.POSIXlt("2018-03-08 16:31", tz="US/Pacific"))
# 2018-03-08 16:31:00, $zone="PST", $gmtoff=NA_integer_
f(as.POSIXlt(NA, tz="US/Pacific"))
# NA, $zone="", $gmtoff=NA_integer_
f(as.POSIXlt(NA_character_, tz="US/Pacific"))
# NA, $zone="", $gmtoff=NA_integer_


But in GMT or UTF it omits the zone and gmtoff components unless you give
it a single character NA

f(as.POSIXlt("2018-03-08 16:31", tz="GMT"))
# 2018-03-08 16:31:00, $zone=NULL, $gmtoff=NULL
f(as.POSIXlt(NA, tz="GMT"))
# NA, $zone=NULL, $gmtoff=NULL
f(as.POSIXlt(NA_character_, tz="GMT"))
# NA, $zone="", $gmtoff=NA_integer_


Another oddity is that as.POSIXlt(characterData, tz="not-GMT") fills the
gmtoff component with NAs even though the zone and isdst components give
the information required to figure out the gmtoff.  as.POSIXlt(POSIXctData)
does give proper values to gmtoff

f(as.POSIXlt("2019-03-08", tz="US/Pacific"))
# 2019-03-08, $zone="PST", $gmtoff=NA_integer_
f(as.POSIXlt(as.POSIXct("2019-03-08", tz="US/Pacific")))
# 2019-03-08, $zone="PST", $gmtoff=-28800L


Is this last an efficiency issue?

Bill Dunlap
TIBCO Software
wdunlap tibco.com

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] compute pnorm in Fortran subroutine in R package

[Wang, Zhu]

Thanks for the useful tips!

-Original Message-
From: Duncan Murdoch  
Sent: Friday, March 8, 2019 1:32 PM
To: Wang, Zhu ; R-package-devel@r-project.org
Subject: Re: [R-pkg-devel] compute pnorm in Fortran subroutine in R package

On 08/03/2019 12:55 p.m., Wang, Zhu wrote:
> Hello,
> 
> In my R package I would like a Fortran subroutine to compute the same value 
> as pnorm does in R. I didn't find out an existing Fortran pnorm subroutine. 
> Perhaps a Fortran subroutine can somehow call R function pnorm, but I would 
> like advice on how to do this correctly.

This is described in the Writing R Extensions manual, Ch 6, The R API: 
entry points for C code.  As the title suggests, it's mainly written for 
calling things like pnorm() from C, but section 6.6 talks about calling C 
functions from Fortran.

You probably also have the erf() function available in Fortran; it's a linear 
transformation of pnorm().  That is,

   erf(x) = 2*pnorm(x*sqrt(2)) - 1

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

Re: [R-pkg-devel] compute pnorm in Fortran subroutine in R package

[Duncan Murdoch]

On 08/03/2019 12:55 p.m., Wang, Zhu wrote:

Hello,

In my R package I would like a Fortran subroutine to compute the same value as 
pnorm does in R. I didn't find out an existing Fortran pnorm subroutine. 
Perhaps a Fortran subroutine can somehow call R function pnorm, but I would 
like advice on how to do this correctly.


This is described in the Writing R Extensions manual, Ch 6, The R API: 
entry points for C code.  As the title suggests, it's mainly written for 
calling things like pnorm() from C, but section 6.6 talks about calling 
C functions from Fortran.


You probably also have the erf() function available in Fortran; it's a 
linear transformation of pnorm().  That is,


  erf(x) = 2*pnorm(x*sqrt(2)) - 1

Duncan Murdoch

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

[Bioc-devel] Package build failure on RELEASE_3_8. Please fix.

[Turaga, Nitesh]

Hello Bioconductor Maintainers, 

The following packages have issues which need to be fixed by maintainers. The 
issues are listed below, if you are getting a direct email it means your 
package is one of the broken ones. Please take time to fix them as soon as 
possible.

The packages are, 

1. bgx
2. CATALYST
3. dSimer
4. flipflop

The specific error messages are below. 

 1. bgx

Makevars:14: recipe for target 'bgx.o' failed
make: *** [bgx.o] Error 1
ERROR: compilation failed for package ‘bgx’
* removing ‘/root/shared/pkglibs/bgx’

 2. CATALYST

Error : in method for ‘filter’ with signature ‘.data="daFrame"’:  
arguments (‘.preserve’) after ‘...’in the generic must appear in the 
method,   in the same place at the end of the argument list
Error : unable to load R code in package ‘CATALYST’
ERROR: lazy loading failed for package ‘CATALYST’
* removing ‘/root/shared/pkglibs/CATALYST’

 3. dSimer

/usr/local/lib/R/etc/Makeconf:171: recipe for target 'BOG.o' failed
make: *** [BOG.o] Error 1
ERROR: compilation failed for package ‘dSimer’
* removing ‘/root/shared/pkglibs/dSimer’

 4. flipflop

/usr/local/lib/R/etc/Makeconf:171: recipe for target 'align.o' failed
make: *** [align.o] Error 1
ERROR: compilation failed for package ‘flipflop’
* removing ‘/root/shared/pkglibs/flipflop’


Best,

Nitesh Turaga

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

[R-pkg-devel] compute pnorm in Fortran subroutine in R package

[Wang, Zhu]

Hello,

In my R package I would like a Fortran subroutine to compute the same value as 
pnorm does in R. I didn't find out an existing Fortran pnorm subroutine. 
Perhaps a Fortran subroutine can somehow call R function pnorm, but I would 
like advice on how to do this correctly.

Many thanks!

Zhu Wang

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] R CMD check warning from checking for future file timestamps

[Shepherd, Lori]

This is not an issue with your code but with our check so it can be ignored for 
now and the review will be aware and move on with the review process despite 
this appearing.


We are reaching out to try and have it remedied.


Lori Shepherd

Bioconductor Core Team

Roswell Park Cancer Institute

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of Kostka, Dennis 

Sent: Friday, March 8, 2019 11:41:43 AM
To: bioc-devel@r-project.org
Subject: Re: [Bioc-devel] R CMD check warning from checking for future file 
timestamps

Hi,

Replying to this subject from two days ago, we have the same problem.
The scds package we submitted passes no errors & no warnings except the 
following:

* checking for future file timestamps ...Warning in file(con, "r") :
  cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status was 
'403 Forbidden'

See here for the full build report:
http://bioconductor.org/spb_reports/scds_buildreport_20190307142830.html

Not sure what to do about it, and whether the submission process moves on 
regardless.
Also, there was a message with the same subject on

Thanks a lot,

Dennis

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

Re: [Bioc-devel] R CMD check warning from checking for future file timestamps

[Kostka, Dennis]

Hi,

Replying to this subject from two days ago, we have the same problem.
The scds package we submitted passes no errors & no warnings except the 
following:

* checking for future file timestamps ...Warning in file(con, "r") :
  cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status was 
'403 Forbidden'

See here for the full build report: 
http://bioconductor.org/spb_reports/scds_buildreport_20190307142830.html

Not sure what to do about it, and whether the submission process moves on 
regardless. 
Also, there was a message with the same subject on 

Thanks a lot,

Dennis

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

Re: [Rd] package installation needs the file utility on Unix

[Gábor Csárdi]

Thanks! Good point about the compiler toolchain.on Alpine Linux,
which tends to be small, gcc can be less than 100MB, so still might
matter a bit

Gabor

On Fri, Mar 8, 2019 at 1:44 PM Tomas Kalibera  wrote:
>
> Well, this only applies to source installs of packages that have some
> files with the special extension, so on systems where a compiler
> toolchain needs to be installed, so the image cannot be really tiny,
> anyway. But ok, I've made stage install use "file" only when it is
> available. When it isn't and some file with extension sl, so, dylib or
> dll in the package installation is not in fact a shared object, one will
> get a number of error messages from the respective tools, but the
> installation passes. Currently on Linux this is the case of RcppParallel
> and FastRWeb.
>
> Tomas
>
> On 3/7/19 11:57 PM, Gábor Csárdi wrote:
> > The new staged package installation shells out to the 'file' utility
> > on Unix systems:
> > https://github.com/wch/r-source/blob/31ee14c620eb1b939acd322f3b5617f998aab8e8/src/library/tools/R/install.R#L578
> >
> > Although 'file' is usually present on most Unix systems, it might be
> > missing from small Docker containers, where the aim is to make the
> > container as small possible. The magic file of 'file' is about 5MB, so
> > that is significant in this case.
> >
> > R uses 'file' to decide if a .so, .dll, etc. file is indeed a shared
> > library, and (as I understand) if it is, it then goes on to try to fix
> > the hardcoded installation path in it, using an os specific tool.
> >
> > As the second part needs to handle errors anyway, I wonder if it would
> > make sense to skip the 'file' call completely, after all it is quite
> > unlikely that a .dll or .so, etc. file is _not_ a shared library, and
> > even if it is not, the errors will be caught later.
> >
> > Thanks, Gabor
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

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

Re: [Rd] package installation needs the file utility on Unix

[Tomas Kalibera]

Well, this only applies to source installs of packages that have some 
files with the special extension, so on systems where a compiler 
toolchain needs to be installed, so the image cannot be really tiny, 
anyway. But ok, I've made stage install use "file" only when it is 
available. When it isn't and some file with extension sl, so, dylib or 
dll in the package installation is not in fact a shared object, one will 
get a number of error messages from the respective tools, but the 
installation passes. Currently on Linux this is the case of RcppParallel 
and FastRWeb.


Tomas

On 3/7/19 11:57 PM, Gábor Csárdi wrote:

The new staged package installation shells out to the 'file' utility
on Unix systems:
https://github.com/wch/r-source/blob/31ee14c620eb1b939acd322f3b5617f998aab8e8/src/library/tools/R/install.R#L578

Although 'file' is usually present on most Unix systems, it might be
missing from small Docker containers, where the aim is to make the
container as small possible. The magic file of 'file' is about 5MB, so
that is significant in this case.

R uses 'file' to decide if a .so, .dll, etc. file is indeed a shared
library, and (as I understand) if it is, it then goes on to try to fix
the hardcoded installation path in it, using an os specific tool.

As the second part needs to handle errors anyway, I wonder if it would
make sense to skip the 'file' call completely, after all it is quite
unlikely that a .dll or .so, etc. file is _not_ a shared library, and
even if it is not, the errors will be caught later.

Thanks, Gabor

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


__
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

[Gábor Csárdi]

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