Re: [Rd] problem running test on a system without /etc/localtime

[Kirill Maslinsky]

On Wed, May 17, 2017 at 11:29:16AM +0200, Martin Maechler wrote:

[...]

> 
> 
> > Index: src/library/base/R/datetime.R
> > ===
> > --- src/library/base/R/datetime.R (revision 72684)
> > +++ src/library/base/R/datetime.R (working copy)
> > @@ -23,7 +23,7 @@
> > {
> > tz <- Sys.getenv("TZ", names = FALSE)
> > if(!location || nzchar(tz)) return(Sys.getenv("TZ", unset = 
> NA_character_))
> > -lt <- normalizePath("/etc/localtime") # Linux, macOS, ...
> > +lt <- normalizePath("/etc/localtime", mustWork = FALSE) # Linux, 
> macOS, ...
> > if (grepl(pat <- "^/usr/share/zoneinfo/", lt)) sub(pat, "", lt)
> > else if (lt == "/etc/localtime" && file.exists("/etc/timezone") &&
> > dir.exists("/usr/share/zoneinfo") &&

Done, the patch successfully fixes warning but the test failed in the other way:

$ ../bin/R --vanilla < reg-tests-1d.R

> ## PR#17186 - Sys.timezone() on some Debian-derived platforms
> (S.t <- Sys.timezone())
[1] NA
> if(is.na(S.t) || !nzchar(S.t)) stop("could not get timezone")
Error: could not get timezone
Execution halted

Which is technically correct, timezone is not set on the system, but date
utility assumes UTC in this case:

$ date +%Z
UTC

I'm not sure if R should do the same. 


Probably, setting TZ environment variable is the right way to go in this
build environment, but then another failure should be fixed:

> >> Sure, this can be worked around by setting TZ environment variable, but
> >> that causes tests to fail in another place:
> >> 
> >> [builder@localhost tests]$ TZ="GMT" ../bin/R --vanilla < reg-tests-1d.R
> >> 
> >>> ## format()ing invalid hand-constructed  POSIXlt  objects
> >>> d <- as.POSIXlt("2016-12-06"); d$zone <- 1
> >>> tools::assertError(format(d))
> >> Error: Failed to get error in evaluating format(d)
> >> Execution halted

-- 
KM

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

Re: [Rd] SUGGESTION: R Base Packages

[frederik]

Hello!

Thanks to Juan for his suggestions. I would like to voice my opinion
for and against some of these.

> o   Add in Bugzilla an Area in order to request membership for bug reporting, 
> which shall itself include another area to introduce a little dissertation 
> for justifying "Why someone would like to be a member of Bugzilla" for being 
> able to report proper bugs, and avoid spam.
> 
> o   Now, new R serious members cannot report properly bugs.

I too was annoyed by the state of the bug reporting system when I
first started using R, and that was even before automatic account
creation was disabled. I think the situation could be improved. I
don't think it's a huge burden to tell bug reporters to ask for an
account via the R-devel mailing list. But from what I can see the bug
tracker doesn't make it clear that this has to be done. We should at
least post a message on the main page explaining how people can create
an account. This would be less work than what Juan is suggesting, but
I think sufficient for our needs.

> * That, in the R Base distribution, the following packages are 
> included as default (pre-installed):
> 
> o   ggplot2.
> 
> o   dplyr.
> 
> o   tidyr.

I think this is a terrible idea. I've only been using R for a few
years and while I find these "tidyverse" packages interesting and use
them on occasion, I've also concluded that they change too quickly to
be used in code that I want to stay working for a long time. They are
largely based on experimental concepts. Being able to change and
evolve is part of the strength of these packages. So I think putting
them in the R Base distribution would be bad for all parties.

> * And that, as regards R Project:
> 
> o   Improve the CRAN & R Project web pages, giving them a more modern look 
> and feel (Such as the Python.org webpage), in order to "sell" better R to the 
> everybody.
> 
> o   Improve the basic GUI distributed with R, with some of the core features 
> of RStudio Desktop (GPL). Or even make RStudio Desktop to replace the R 
> default GUI, with another name, in its executable version.
> 
> o   Enable a Suggestion web page / forum in the R Project webpage in order to 
> boost core R Open Innovation.

I think the R project web page looks great. It's simple and it loads
quickly and doesn't try to mesmerize people. I like R's command line
interface. It completes on symbols and files and I can easily use it
with my favorite editor and run it in the terminal of my choice. I
don't think that more effort should be put into developing bloated
GUIs which try to enforce a standard way of interacting with R.

I think a "forum" or bulletin board system would be a detraction from
the project and a distraction for the project leaders. Users have
Stack Exchange - it's better than any forum we could create, and it
takes care of itself.

That's my two cents, more or less.

Thanks,

Frederick

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

[Bioc-devel] invalid PDF version and NULL vector errors in unchanged package

[Sokratis Kariotis]

Hey all,

I maintain 'pathprint', a package added to bioconductor in the last
release. Now the BioC 3.6 BUILD (
http://bioconductor.org/checkResults/3.6/bioc-LATEST/pathprint/)
 is
producing an error in all 3 platforms (despite it used to be error-free and
there were no changes to the code after that). *malbec1* and *tokay1* share
the same error:

Error: processing vignette 'exampleFingerprint.Rnw' failed with diagnostics:
invalid PDF version
Execution halted

while *veracruz1* provides a different error

Error: processing vignette 'exampleFingerprint.Rnw' failed with diagnostics:
 chunk 2 (label = data)
Error in array(x, c(length(x), 1L), if (!is.null(names(x))) list(names(x),  :
  'data' must be of a vector type, was 'NULL'
Execution halted

The two errors seem to be different, the first one appears at the very
beginning and is general,
while the second one is having a problem with the data chuck of the file.

Could any changes in BioC 3.6 be responsible, since the code didnt
change at all? Thanks in advance for any help!

Regards,

Sokratis

[[alternative HTML version deleted]]

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

[Rd] SUGGESTION: R Base Packages

[TELLERIA RUIZ DE AGUIRRE, JUAN]

Dear R Developers,

I am writing for doing the following suggestions:


* Bugs:

o   Add in Bugzilla an Area in order to request membership for bug reporting, 
which shall itself include another area to introduce a little dissertation for 
justifying "Why someone would like to be a member of Bugzilla" for being able 
to report proper bugs, and avoid spam.

o   Now, new R serious members cannot report properly bugs.



* That, in the R Base distribution, the following packages are included 
as default (pre-installed):

o   ggplot2.

o   dplyr.

o   tidyr.



As in 2017, these are essential, in my opinion, in R programming.


* And that, as regards R Project:

o   Improve the CRAN & R Project web pages, giving them a more modern look and 
feel (Such as the Python.org webpage), in order to "sell" better R to the 
everybody.

o   Improve the basic GUI distributed with R, with some of the core features of 
RStudio Desktop (GPL). Or even make RStudio Desktop to replace the R default 
GUI, with another name, in its executable version.

o   Enable a Suggestion web page / forum in the R Project webpage in order to 
boost core R Open Innovation.

Thank you all.



[[alternative HTML version deleted]]

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

Re: [Rd] problem running test on a system without /etc/localtime

[Martin Maechler]

> Henrik Bengtsson 
> on Tue, 16 May 2017 20:49:02 -0700 writes:

> On Tue, May 16, 2017 at 5:35 PM, Kirill Maslinsky  
wrote:
>> Hi all,
>> 
>> A problem with tests while building R.
>> 
>> I'm packaging R for Sisyphus repository and package build environment,
>> by design, doesn't have /etc/localtime file present. This causes failure
>> with Sys.timeone during test run:
>> 
>> [builder@localhost tests]$ ../bin/R --vanilla < reg-tests-1d.R
>> 
>>> ## PR#17186 - Sys.timezone() on some Debian-derived platforms
>>> (S.t <- Sys.timezone())
>> Error in normalizePath("/etc/localtime") :
>> (converted from warning) path[1]="/etc/localtime": No such file or
>> directory
>> Calls: Sys.timezone -> normalizePath
>> Execution halted
>> 
>> This is caused by this code:
>> 
>>> Sys.timezone
>> function (location = TRUE)
>> {
>> tz <- Sys.getenv("TZ", names = FALSE)
>> if (!location || nzchar(tz))
>> return(Sys.getenv("TZ", unset = NA_character_))
 lt <- normalizePath("/etc/localtime")
>> [remainder of the code skkipped]
>> 
>> File /etc/loclatime is optional and is not guaranteed to be present on
>> any platform. And anyway, it is a good idea to first check that file
>> exists before calling normalizePath.

> Looking at the code
> 
(https://github.com/wch/r-source/blob/R-3-4-branch/src/library/base/R/datetime.R#L26),
> could it be that mustWork = FALSE (instead of the default NA) avoids
> the warning causes this check error?

Good idea.

Kirill, could you apply the minimal patch to the sources and
report back ?


> Index: src/library/base/R/datetime.R
> ===
> --- src/library/base/R/datetime.R (revision 72684)
> +++ src/library/base/R/datetime.R (working copy)
> @@ -23,7 +23,7 @@
> {
> tz <- Sys.getenv("TZ", names = FALSE)
> if(!location || nzchar(tz)) return(Sys.getenv("TZ", unset = 
NA_character_))
> -lt <- normalizePath("/etc/localtime") # Linux, macOS, ...
> +lt <- normalizePath("/etc/localtime", mustWork = FALSE) # Linux, 
macOS, ...
> if (grepl(pat <- "^/usr/share/zoneinfo/", lt)) sub(pat, "", lt)
> else if (lt == "/etc/localtime" && file.exists("/etc/timezone") &&
> dir.exists("/usr/share/zoneinfo") &&

> /Henrik

>> 
>> Sure, this can be worked around by setting TZ environment variable, but
>> that causes tests to fail in another place:
>> 
>> [builder@localhost tests]$ TZ="GMT" ../bin/R --vanilla < reg-tests-1d.R
>> 
>>> ## format()ing invalid hand-constructed  POSIXlt  objects
>>> d <- as.POSIXlt("2016-12-06"); d$zone <- 1
>>> tools::assertError(format(d))
>> Error: Failed to get error in evaluating format(d)
>> Execution halted
>> 
>> It seems that the best solution will be to patch Sys.timezone.
>> 
>> --
>> KM
>> 
>> __
>> 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

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