Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
On 14/04/2014, 10:23 AM, Marc Schwartz wrote:
Hi Martin,
Thanks for your confirmation on this.
I normally do not use R CMD Sweave, as I too run under ESS in normal day to day
operations. This finding was a quirk of having a particular Rnw document that I
occasionally run using R CMD Sweave and I had done so over the weekend,
realizing this behavior.
This sounds like an argument for dropping R CMD Sweave, rather than
fixing it. The bug was introduced in July, 2013, and nobody noticed it
because so few people use that feature, and apparently nobody who does
use it bothers to test pre-release versions.
Duncan Murdoch
Thanks again.
Regards,
Marc
On Apr 14, 2014, at 7:28 AM, Martin Maechler wrote:
Marc Schwartz
on Sun, 13 Apr 2014 10:22:55 -0500 writes:
[on the R-SIG-Mac mailing list] :
Hi all,
With R version 3.1.0 on OSX, using either the Snow Leopard or the Mavericks
binary installation on a Mac with fully updated Mavericks, there has been a
change in behavior since 3.0.3.
I've just written to R-core about this:
R CMD Sweave
has *serious* problems also in the very simple case when it
should produce figures: They are not available after the
completion of R CMD Sweave,
confirming your 'deletes non tex files created upon batch mode exit'
So this is not related to OSX only, but also a big problem
at least on other *nix descendent platforms, such as Linux.
In short, failure (no graphic produce in the example below) by
R CMD Sweave foo.Rnw
but all is fine with using Sweave(), as you Marc, noted, and hence with
Rscript -e 'Sweave("foo.Rnw")'
... and to answer your question:
No this was not intended and is probably one of the bigger /
most embarrassing bugs in a newly released version of R
in my view:
Basically 'R CMD Sweave' is partly broken in R 3.1.0.
Yes, this should never have happened.
I had to partially revert the R 3.1.0 installation here (our
statistics dept), by making R 3.0.3 the default 'R'
for now, as we are relying on 'R CMD Sweave ..' in many places.
Personally I've never noticed the problem, as I seem to always
Sweave from ESS (Emacs speaks statistics) which calls Sweave()
in R, and that works fine, also in R 3.1.0, as you've already
noted
Martin Maechler, ETH Zurich
%
\documentclass[12pt]{article}
\usepackage{Sweave}
\begin{document} Just a simple graphic
<>=
qqnorm(rnorm(20))
@
and that's all, folks!
\end{document}
%
I have a master .Rnw file which runs a series of outputs from multiple R code
files, each called in BATCH mode using system() from within the master .Rnw
file. The output of the R code files go to separate text files in order to
catch some of the function call output that would not otherwise be included in
the resultant .tex file due to output redirection.
Those text files are then included in the resultant .tex file using, for
example:
\lstinputlisting[caption={}]{test.out}
directives which are included in the .Rnw source file.
A simple example to replicate the observed behaviors.
The test.Rnw file content:
%% R CMD Sweave test.Rnw
<>=
system("R CMD BATCH test.R test.out")
@
The test.R file content:
options(echo = FALSE)
options(useFancyQuotes = FALSE)
installed.packages()
On version 3.0.3, the file test.out is created, along with test.tex. test.out
contains the output of installed.packages(). I did not include the
aforementioned listing directive in test.Rnw here for simplicity.
On version 3.1.0, the file test.out is created, but when the R CMD Sweave
command exits and returns to the CLI in the console, test.out is deleted,
presumably as part of a post R batch session clean up process. The file
test.tex is retained.
I uninstalled 3.1.0 and reinstalled 3.0.3 and observed the prior behavior. I
then tried clean installs of both the Snow Leopard and Mavericks 3.1.0
binaries, with the new behavior observed in both cases.
In reading the NEWS file for 3.1.0, there are multiple references to Sweave,
but there is nothing explicit about this new behavior.
I should note that when the .Rnw file is run from within an R 3.1.0 interactive
session using:
Sweave("test.Rnw")
the test.out file is created and not deleted upon the function exit, or when
exiting the R session back to the console.
Thus, this new behavior seems to be limited to running Sweave from the CLI
using R CMD. It is not clear to me if this new behavior is by design or perhaps
an unintended consequence of changes elsewhere in Sweave processing or in the
handling of R in BATCH mode.
When watching the folder where the file output activity takes place, I note
that a file .build.timestamp is created and then deleted, which leads me to
believe that the new functions fileSnapshot() and changedFiles() are being used
in the course of processing R in BATCH mode. If that is corre
Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
On 15 Apr 2014, at 13:14 , Duncan Murdoch wrote: > On 14/04/2014, 10:23 AM, Marc Schwartz wrote: >> Hi Martin, >> >> Thanks for your confirmation on this. >> >> I normally do not use R CMD Sweave, as I too run under ESS in normal day to >> day operations. This finding was a quirk of having a particular Rnw document >> that I occasionally run using R CMD Sweave and I had done so over the >> weekend, realizing this behavior. > > This sounds like an argument for dropping R CMD Sweave, rather than fixing > it. The bug was introduced in July, 2013, and nobody noticed it because so > few people use that feature, and apparently nobody who does use it bothers to > test pre-release versions. > I'd say that that cat is out of the bag. There are probably umpteen documents around suggesting "R CMD Sweave". As people use Sweave only sporadically, it could take years before the old usage got stamped out. And anyways, the command format is the obvious way to generate documents in scripts and makefiles, isn't it? -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
On Tue, Apr 15, 2014 at 7:14 AM, Duncan Murdoch wrote: > On 14/04/2014, 10:23 AM, Marc Schwartz wrote: > >> Hi Martin, >> >> Thanks for your confirmation on this. >> >> I normally do not use R CMD Sweave, as I too run under ESS in normal day >> to day operations. This finding was a quirk of having a particular Rnw >> document that I occasionally run using R CMD Sweave and I had done so over >> the weekend, realizing this behavior. >> > > This sounds like an argument for dropping R CMD Sweave, rather than fixing > it. The bug was introduced in July, 2013, and nobody noticed it because so > few people use that feature, and apparently nobody who does use it bothers > to test pre-release versions. > Or they just fix it for themselves, and do not report it. At least I know of one such case Gabor [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
On 15/04/2014 8:12 AM, peter dalgaard wrote: On 15 Apr 2014, at 13:14 , Duncan Murdoch wrote: > On 14/04/2014, 10:23 AM, Marc Schwartz wrote: >> Hi Martin, >> >> Thanks for your confirmation on this. >> >> I normally do not use R CMD Sweave, as I too run under ESS in normal day to day operations. This finding was a quirk of having a particular Rnw document that I occasionally run using R CMD Sweave and I had done so over the weekend, realizing this behavior. > > This sounds like an argument for dropping R CMD Sweave, rather than fixing it. The bug was introduced in July, 2013, and nobody noticed it because so few people use that feature, and apparently nobody who does use it bothers to test pre-release versions. > I'd say that that cat is out of the bag. There are probably umpteen documents around suggesting "R CMD Sweave". As people use Sweave only sporadically, it could take years before the old usage got stamped out. And anyways, the command format is the obvious way to generate documents in scripts and makefiles, isn't it? I use Rscript, and I expect most others do too, but I was wrong about how long this went unreported. Martin Morgan reported it in February in R-devel and I didn't notice. He even gave a link to it in a message in March on another topic; I replied to the March message, but didn't follow the link. We discourage people from using bugs.r-project.org for pre-release issues; perhaps we shouldn't do that. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
> I use Rscript, and I expect most others do too, but I was wrong about how > long this went unreported. Martin Morgan reported it in February in R-devel > and I didn't notice. He even gave a link to it in a message in March on > another topic; I replied to the March message, but didn't follow the link. > > We discourage people from using bugs.r-project.org for pre-release issues; > perhaps we shouldn't do that. Regardless of the venue, the cost for submitting an issue that doesn't turn out to be a bug is quite high - you're likely to get a nasty message. If you want more people to submit bug reports, I think you have to be prepared to receive reports about things that users think are bugs, but developers do not. If you want to encourage people to submit bugs, then you have to make it a pleasant (or at least not unpleasant) experience. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem: Importing two packages which export a function with the same name
Hi all, I am currently updating our package gamboostLSS which depends on package mboost *and* on package gamlss.dist. From mboost we use a lot of the fitting infrastructure and from gamlss.dist we obtain the relevant loss functions (aka families) used for fitting and corresponding quantile functions. Furthermore, we use the Family() function from package mboost. However, if I depend on both packages, mboost::Family is always masked by a function of the same name from package gamlss.dist. I tried to change the order of mboost and gamlss.dist in both my NAMESPACE and my DESCRIPTION file but couldn't see any difference in the result: gamlss.dist is always loaded after mboost and thus it breaks my code. Actually, I would love to use something similar to importFrom() with a pattern that excludes Family, i.e., importFrom(gamlss.dist, exclude_pattern = "Family") or the same with an include pattern designed to exclude Family in my NAMESPACE. Is this possible anyhow? As gamlss.dist keeps evolving over time with more families to be added, I cannot manually importFrom(...) all the relevant families. I would have to change the list of functions all the time. Thanks and all the best, Benjamin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ASCIIfy() - a proposal for package:tools
Hi all,
I would like to propose the attached function ASCIIfy() to be added to the
'tools' package.
Non-ASCII characters in character vectors can be problematic for R
packages, but sometimes they cannot be avoided. To make packages portable
and build without 'R CMD check' warnings, my solution has been to convert
problematic characters in functions and datasets to escaped ASCII, so
plot(1,main="São Paulo") becomes plot(1,main="S\u00e3o Paulo").
The showNonASCII() function in package:tools is helpful to identify R
source files where characters should be converted to ASCII one way or
another, but I could not find a function to actually perform the
conversion to ASCII.
I have written the function ASCIIfy() to convert character vectors to
ASCII. I imagine other R package developers might be looking for a similar
tool, and it seems to me that package:tools is the first place they would
look, where the R Core Team has provided a variety of tools for handling
non-ASCII characters in package development.
I hope the R Core Team will adopt ASCIIfy() into the 'tools' package, to
make life easier for package developers outside the English-speaking
world. I have of course no problem with them renaming or rewriting the
function in any way.
See the attached examples - all in flat ASCII that was prepared using the
function itself! The main objective, though, is to ASCIIfy functions and
datasets, not help pages.
ArniASCIIfy <- function(string, bytes=2, fallback="?")
{
bytes <- match.arg(as.character(bytes), 1:2)
convert <- function(char) # convert to ASCII, e.g. "z", "\xfe", or "\u00fe"
{
raw <- charToRaw(char)
if(length(raw)==1 && raw<=127) # 7-bit
ascii <- char
else if(length(raw)==1 && bytes==1) # 8-bit to \x00
ascii <- paste0("\\x", raw)
else if(length(raw)==1 && bytes==2) # 8-bit to \u
ascii <- paste0("\\u", chartr(" ","0",formatC(as.character(raw),width=4)))
else if(length(raw)==2 && bytes==1) # 16-bit to \x00, if possible
if(utf8ToInt(char) <= 255)
ascii <- paste0("\\x", format.hexmode(utf8ToInt(char)))
else {
ascii <- fallback; warning(char, " could not be converted to 1 byte")}
else if(length(raw)==2 && bytes==2) # UTF-8 to \u
ascii <- paste0("\\u", format.hexmode(utf8ToInt(char),width=4))
else {
ascii <- fallback
warning(char, " could not be converted to ", bytes, " byte")}
return(ascii)
}
if(length(string) > 1)
{
sapply(string, ASCIIfy, bytes=bytes, fallback=fallback, USE.NAMES=FALSE)
}
else
{
input <- unlist(strsplit(string,"")) # "c" "a" "f" "<\'e>"
output <- character(length(input))# "" "" "" ""
for(i in seq_along(input))
output[i] <- convert(input[i]) # "c" "a" "f" "\\u00e9"
output <- paste(output, collapse="") # "caf\\u00e9"
return(output)
}
}
\name{ASCIIfy}
\alias{ASCIIfy}
\title{Convert Characters to ASCII}
\description{
Convert character vector to ASCII, replacing non-ASCII characters with
single-byte (\samp{\x00}) or two-byte (\samp{\u}) codes.
}
\usage{
ASCIIfy(x, bytes = 2, fallback = "?")
}
\arguments{
\item{x}{a character vector, possibly containing non-ASCII
characters.}
\item{bytes}{either \code{1} or \code{2}, for single-byte
(\samp{\x00}) or two-byte (\samp{\u}) codes.}
\item{fallback}{an output character to use, when input characters
cannot be converted.}
}
\value{
A character vector like \code{x}, except non-ASCII characters have
been replaced with \samp{\x00} or \samp{\u} codes.
}
\author{Arni Magnusson.}
\note{
To render single backslashes, use these or similar techniques:
\verb{
write(ASCIIfy(x), "file.txt")
cat(paste(ASCIIfy(x), collapse="\n"), "\n", sep="")}
The resulting strings are plain ASCII and can be used in R functions
and datasets to improve package portability.
}
\seealso{
\code{\link[tools]{showNonASCII}} identifies non-ASCII characters in
a character vector.
}
\examples{
cities <- c("S\u00e3o Paulo", "Reykjav\u00edk")
print(cities)
ASCIIfy(cities, 1)
ASCIIfy(cities, 2)
athens <- "\u0391\u03b8\u03ae\u03bd\u03b1"
print(athens)
ASCIIfy(athens)
}
\keyword{}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0: 'R CMD Sweave' deletes non tex files created upon batch mode exit
I have, at times, been a heavy user of R CMD Sweave and would prefer to see it fixed! I encountered this error while preparing notes for a guest lecture last fall, and was too busy to identify the source of the error, so worked around it (thank goodness for version control, making file restores easy) rather than reporting the bug…. -Greg On Apr 15, 2014, at 10:11 AM, Hadley Wickham wrote: >> I use Rscript, and I expect most others do too, but I was wrong about how >> long this went unreported. Martin Morgan reported it in February in R-devel >> and I didn't notice. He even gave a link to it in a message in March on >> another topic; I replied to the March message, but didn't follow the link. >> >> We discourage people from using bugs.r-project.org for pre-release issues; >> perhaps we shouldn't do that. > > Regardless of the venue, the cost for submitting an issue that doesn't > turn out to be a bug is quite high - you're likely to get a nasty > message. If you want more people to submit bug reports, I think you > have to be prepared to receive reports about things that users think > are bugs, but developers do not. If you want to encourage people to > submit bugs, then you have to make it a pleasant (or at least not > unpleasant) experience. > > Hadley > > -- > http://had.co.nz/ > > __ > 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] duplication regression (?)
This went off-list, but a patch has been submitted to fix the issue.
On Mon, Apr 14, 2014 at 4:12 AM, Scott Kostyshak wrote:
> Below is an example of output that changed as a result of r64970. I
> did not see any NEWS item suggesting this change is expected.
>
> Note that the example is contrived and I don't have a use case for it.
> I stumbled across it when playing with recent changes in R relating to
> duplication. Does the example use undefined syntax?
>
> -
> fn1 <- function(mylist) {
> fn1a <- function() mylist[[c(1,1)]][[1]] <<- 9
> fn1a()
> return(NULL)
> }
>
> fn2 <- function(myarg) fn1(myarg)
>
> test_list <- list(list(list(1)))
> print(test_list[[c(1,1,1)]])
> fn2(test_list)
> print(test_list[[c(1,1,1)]])
> -
>
> Before r64970 the output is
> [1] 1
> [1] 1
>
> After r64970 the output is
> [1] 1
> [1] 9
>
> > sessionInfo()
> R Under development (unstable) (2014-04-10 r65396)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> >
>
> Scott
>
>
> --
> Scott Kostyshak
> Economics PhD Candidate
> Princeton University
>
> __
> 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
