[Rd] embed Sweave driver in .Rnw file
Hello,
Sweave lets you use alternative drivers through the driver argument, and
several packages take advantage of that and define custom Sweave driver
for various purposes. Most of them are listed on the Reproducible
Research CTV:
(http://cran.r-project.org/web/views/ReproducibleResearch.html)
The next natural step is for package developpers to take advantage of
this in their vignettes. In Rcpp we work around the way package building
works and we do:
- let R build a dummy vignette
- then use the inst/doc/Makefile to replace it with a vignette that is
processed by the driver from the highlight package (giving syntax
highlighting).
I played with Sweave so that it would be able to create the driver from
some text included in the text of the .Rnw file:
$ svn diff
Index: src/library/utils/R/Sweave.R
===
--- src/library/utils/R/Sweave.R(revision 53846)
+++ src/library/utils/R/Sweave.R(working copy)
@@ -20,6 +20,16 @@
# We don't need srclines for code, but we do need it for text, and
it's easiest
# to just keep it for everything.
+SweaveGetDriver <- function(file){
+txt <- readLines(file)
+line <- grep( "\\SweaveDriver", txt, value = TRUE )
+if( length(line) ){
+txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
+driver <- try( eval( parse( text = txt ) ), silent = TRUE )
+if( !inherits( driver, "try-error") ) driver
+}
+}
+
Sweave <- function(file, driver=RweaveLatex(),
syntax=getOption("SweaveSyntax"), ...)
{
@@ -28,7 +38,9 @@
else if(is.function(driver))
driver <- driver()
-
+drv <- SweaveGetDriver(file)
+if( !is.null(drv) ) driver <- drv
+
if(is.null(syntax))
syntax <- SweaveGetSyntax(file)
if(is.character(syntax))
This allows one to write something like this in their file:
%\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
So that when calling :
> Sweave( "somefile.Rnw" )
the highlight driver is used instead of the default driver.
Could something like that be added to Sweave ?
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embed Sweave driver in .Rnw file
> On Tue, 14 Dec 2010 12:40:04 +0100,
> Romain Francois (RF) wrote:
> Hello,
> Sweave lets you use alternative drivers through the driver argument, and
> several packages take advantage of that and define custom Sweave driver
> for various purposes. Most of them are listed on the Reproducible
> Research CTV:
> (http://cran.r-project.org/web/views/ReproducibleResearch.html)
> The next natural step is for package developpers to take advantage of
> this in their vignettes. In Rcpp we work around the way package building
> works and we do:
> - let R build a dummy vignette
> - then use the inst/doc/Makefile to replace it with a vignette that is
> processed by the driver from the highlight package (giving syntax
> highlighting).
> I played with Sweave so that it would be able to create the driver from
> some text included in the text of the .Rnw file:
> $ svn diff
> Index: src/library/utils/R/Sweave.R
> ===
> --- src/library/utils/R/Sweave.R(revision 53846)
> +++ src/library/utils/R/Sweave.R(working copy)
> @@ -20,6 +20,16 @@
> # We don't need srclines for code, but we do need it for text, and
> it's easiest
> # to just keep it for everything.
> +SweaveGetDriver <- function(file){
> +txt <- readLines(file)
> +line <- grep( "\\SweaveDriver", txt, value = TRUE )
> +if( length(line) ){
> +txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
> +driver <- try( eval( parse( text = txt ) ), silent = TRUE )
> +if( !inherits( driver, "try-error") ) driver
> +}
> +}
> +
> Sweave <- function(file, driver=RweaveLatex(),
> syntax=getOption("SweaveSyntax"), ...)
> {
> @@ -28,7 +38,9 @@
> else if(is.function(driver))
> driver <- driver()
> -
> +drv <- SweaveGetDriver(file)
> +if( !is.null(drv) ) driver <- drv
> +
> if(is.null(syntax))
> syntax <- SweaveGetSyntax(file)
> if(is.character(syntax))
> This allows one to write something like this in their file:
> %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
> So that when calling :
>> Sweave( "somefile.Rnw" )
> the highlight driver is used instead of the default driver.
> Could something like that be added to Sweave ?
Yes, sure!
Will have a look at the patch later this week and apply it if it
passes the tests. The patch is against a current r-devel?
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embed Sweave driver in .Rnw file
Le 14/12/10 13:21, Friedrich Leisch a écrit :
On Tue, 14 Dec 2010 12:40:04 +0100,
Romain Francois (RF) wrote:
> Hello,
> Sweave lets you use alternative drivers through the driver argument, and
> several packages take advantage of that and define custom Sweave driver
> for various purposes. Most of them are listed on the Reproducible
> Research CTV:
> (http://cran.r-project.org/web/views/ReproducibleResearch.html)
> The next natural step is for package developpers to take advantage of
> this in their vignettes. In Rcpp we work around the way package building
> works and we do:
> - let R build a dummy vignette
> - then use the inst/doc/Makefile to replace it with a vignette that is
> processed by the driver from the highlight package (giving syntax
> highlighting).
> I played with Sweave so that it would be able to create the driver from
> some text included in the text of the .Rnw file:
> $ svn diff
> Index: src/library/utils/R/Sweave.R
> ===
> --- src/library/utils/R/Sweave.R (revision 53846)
> +++ src/library/utils/R/Sweave.R (working copy)
> @@ -20,6 +20,16 @@
># We don't need srclines for code, but we do need it for text, and
> it's easiest
># to just keep it for everything.
> +SweaveGetDriver<- function(file){
> +txt<- readLines(file)
> +line<- grep( "\\SweaveDriver", txt, value = TRUE )
> +if( length(line) ){
> +txt<- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
> +driver<- try( eval( parse( text = txt ) ), silent = TRUE )
> +if( !inherits( driver, "try-error") ) driver
> +}
> +}
> +
>Sweave<- function(file, driver=RweaveLatex(),
> syntax=getOption("SweaveSyntax"), ...)
>{
> @@ -28,7 +38,9 @@
>else if(is.function(driver))
>driver<- driver()
> -
> +drv<- SweaveGetDriver(file)
> +if( !is.null(drv) ) driver<- drv
> +
>if(is.null(syntax))
>syntax<- SweaveGetSyntax(file)
>if(is.character(syntax))
> This allows one to write something like this in their file:
> %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
> So that when calling :
>> Sweave( "somefile.Rnw" )
> the highlight driver is used instead of the default driver.
> Could something like that be added to Sweave ?
Yes, sure!
Will have a look at the patch later this week and apply it if it
passes the tests.
Great. Let me know if I can expand on it (documentation, etc ...)
The patch is against a current r-devel?
yes. rev 53846.
Best,
Fritz
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/fT2rZM : highlight 0.2-5
|- http://bit.ly/gpCSpH : Evolution of Rcpp code size
`- http://bit.ly/hovakS : RcppGSL initial release
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embed Sweave driver in .Rnw file
Another question about Sweave (actually it is more a question
about TeX). Is there a reliable (system-independent) way to
use Sweave.sty without having to place it in the current working
directory? MiKTeX under Windows has dropped the use of
TEXINPUTS, and this complicates the problem.
Furthermore, you cannot refer to Sweave.sty using its full path
as this would obviously not be system-independent.
Yet another small issue: If I configure Sweave to use a
temp directory for its temp files, and if this temp directory
does not exist, TeX fails with error diagnostics that is not
clear at all. Is there a way to have TeX automatically
create the directory if necessary?
Thanks,
Dominick
On Tue, Dec 14, 2010 at 7:21 AM, Friedrich Leisch <
friedrich.lei...@stat.uni-muenchen.de> wrote:
> > On Tue, 14 Dec 2010 12:40:04 +0100,
> > Romain Francois (RF) wrote:
>
> > Hello,
> > Sweave lets you use alternative drivers through the driver argument, and
> > several packages take advantage of that and define custom Sweave driver
> > for various purposes. Most of them are listed on the Reproducible
> > Research CTV:
> > (http://cran.r-project.org/web/views/ReproducibleResearch.html)
>
> > The next natural step is for package developpers to take advantage of
> > this in their vignettes. In Rcpp we work around the way package building
> > works and we do:
> > - let R build a dummy vignette
> > - then use the inst/doc/Makefile to replace it with a vignette that is
> > processed by the driver from the highlight package (giving syntax
> > highlighting).
>
> > I played with Sweave so that it would be able to create the driver from
> > some text included in the text of the .Rnw file:
>
> > $ svn diff
> > Index: src/library/utils/R/Sweave.R
> > ===
> > --- src/library/utils/R/Sweave.R(revision 53846)
> > +++ src/library/utils/R/Sweave.R(working copy)
> > @@ -20,6 +20,16 @@
> > # We don't need srclines for code, but we do need it for text, and
> > it's easiest
> > # to just keep it for everything.
>
> > +SweaveGetDriver <- function(file){
> > +txt <- readLines(file)
> > +line <- grep( "\\SweaveDriver", txt, value = TRUE )
> > +if( length(line) ){
> > +txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
> > +driver <- try( eval( parse( text = txt ) ), silent = TRUE )
> > +if( !inherits( driver, "try-error") ) driver
> > +}
> > +}
> > +
> > Sweave <- function(file, driver=RweaveLatex(),
> > syntax=getOption("SweaveSyntax"), ...)
> > {
> > @@ -28,7 +38,9 @@
> > else if(is.function(driver))
> > driver <- driver()
>
> > -
> > +drv <- SweaveGetDriver(file)
> > +if( !is.null(drv) ) driver <- drv
> > +
> > if(is.null(syntax))
> > syntax <- SweaveGetSyntax(file)
> > if(is.character(syntax))
>
>
>
> > This allows one to write something like this in their file:
>
> > %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
>
> > So that when calling :
>
> >> Sweave( "somefile.Rnw" )
>
> > the highlight driver is used instead of the default driver.
>
> > Could something like that be added to Sweave ?
>
> Yes, sure!
>
> Will have a look at the patch later this week and apply it if it
> passes the tests. The patch is against a current r-devel?
>
> Best,
> Fritz
>
> __
> 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: [Rd] embed Sweave driver in .Rnw file
On 14/12/2010 9:54 AM, Dominick Samperi wrote:
Another question about Sweave (actually it is more a question
about TeX). Is there a reliable (system-independent) way to
use Sweave.sty without having to place it in the current working
directory? MiKTeX under Windows has dropped the use of
TEXINPUTS, and this complicates the problem.
If you run it from R, the right path will be put in place. The
tools::texi2dvi function does this.
Furthermore, you cannot refer to Sweave.sty using its full path
as this would obviously not be system-independent.
Yet another small issue: If I configure Sweave to use a
temp directory for its temp files, and if this temp directory
does not exist, TeX fails with error diagnostics that is not
clear at all. Is there a way to have TeX automatically
create the directory if necessary?
I don't understand this one. Are you talking about a "prefix=somedir/"
option to Sweave? That needs to be there before TeX is run. I
sometimes put a dir.create("somedir", showWarnings=FALSE) call in an
early chunk in the document to create it.
Duncan Murdoch
Thanks,
Dominick
On Tue, Dec 14, 2010 at 7:21 AM, Friedrich Leisch<
friedrich.lei...@stat.uni-muenchen.de> wrote:
> > On Tue, 14 Dec 2010 12:40:04 +0100,
> > Romain Francois (RF) wrote:
>
> > Hello,
> > Sweave lets you use alternative drivers through the driver argument, and
> > several packages take advantage of that and define custom Sweave driver
> > for various purposes. Most of them are listed on the Reproducible
> > Research CTV:
> > (http://cran.r-project.org/web/views/ReproducibleResearch.html)
>
> > The next natural step is for package developpers to take advantage of
> > this in their vignettes. In Rcpp we work around the way package building
> > works and we do:
> > - let R build a dummy vignette
> > - then use the inst/doc/Makefile to replace it with a vignette that is
> > processed by the driver from the highlight package (giving syntax
> > highlighting).
>
> > I played with Sweave so that it would be able to create the driver from
> > some text included in the text of the .Rnw file:
>
> > $ svn diff
> > Index: src/library/utils/R/Sweave.R
> > ===
> > --- src/library/utils/R/Sweave.R(revision 53846)
> > +++ src/library/utils/R/Sweave.R(working copy)
> > @@ -20,6 +20,16 @@
> ># We don't need srclines for code, but we do need it for text, and
> > it's easiest
> ># to just keep it for everything.
>
> > +SweaveGetDriver<- function(file){
> > +txt<- readLines(file)
> > +line<- grep( "\\SweaveDriver", txt, value = TRUE )
> > +if( length(line) ){
> > +txt<- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
> > +driver<- try( eval( parse( text = txt ) ), silent = TRUE )
> > +if( !inherits( driver, "try-error") ) driver
> > +}
> > +}
> > +
> >Sweave<- function(file, driver=RweaveLatex(),
> > syntax=getOption("SweaveSyntax"), ...)
> >{
> > @@ -28,7 +38,9 @@
> >else if(is.function(driver))
> >driver<- driver()
>
> > -
> > +drv<- SweaveGetDriver(file)
> > +if( !is.null(drv) ) driver<- drv
> > +
> >if(is.null(syntax))
> >syntax<- SweaveGetSyntax(file)
> >if(is.character(syntax))
>
>
>
> > This allows one to write something like this in their file:
>
> > %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
>
> > So that when calling :
>
> >> Sweave( "somefile.Rnw" )
>
> > the highlight driver is used instead of the default driver.
>
> > Could something like that be added to Sweave ?
>
> Yes, sure!
>
> Will have a look at the patch later this week and apply it if it
> passes the tests. The patch is against a current r-devel?
>
> Best,
> Fritz
>
> __
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embed Sweave driver in .Rnw file
Both of my questions were not clear, sorry.
What I really want to do is have a customized version of Sweave.sty
(Sweave++.sty)
included automatically from some designated area, like the include directory
of another
package, rather than requiring the user to keep a version in the local
directory. Since
the changes are minor, it might make more sense to solve this by
incorporating
them into Sweave.sty.
On the temp directory, yes, I'm talking about Sweave's prefix option. Your
suggestion
to use dir.create() sounds like a reasonable work-around for the fact that
TeX cannot perform OS-level functions.
Yet another small issue that I'm sure others have encountered is that
TeX processing will fail under Linux when the source files contain DOS CR's,
and
the error diagnostics would leave you in the dark. The only fix that I could
come up with is to remove the CR's manually using tr. Is there a better way?
Thanks,
Dominick
On Tue, Dec 14, 2010 at 10:26 AM, Duncan Murdoch
wrote:
> On 14/12/2010 9:54 AM, Dominick Samperi wrote:
>
>> Another question about Sweave (actually it is more a question
>> about TeX). Is there a reliable (system-independent) way to
>> use Sweave.sty without having to place it in the current working
>> directory? MiKTeX under Windows has dropped the use of
>> TEXINPUTS, and this complicates the problem.
>>
>
> If you run it from R, the right path will be put in place. The
> tools::texi2dvi function does this.
>
>
> Furthermore, you cannot refer to Sweave.sty using its full path
>> as this would obviously not be system-independent.
>>
>> Yet another small issue: If I configure Sweave to use a
>> temp directory for its temp files, and if this temp directory
>> does not exist, TeX fails with error diagnostics that is not
>> clear at all. Is there a way to have TeX automatically
>> create the directory if necessary?
>>
>
> I don't understand this one. Are you talking about a "prefix=somedir/"
> option to Sweave? That needs to be there before TeX is run. I sometimes
> put a dir.create("somedir", showWarnings=FALSE) call in an early chunk in
> the document to create it.
>
> Duncan Murdoch
>
> Thanks,
>> Dominick
>>
>> On Tue, Dec 14, 2010 at 7:21 AM, Friedrich Leisch<
>> friedrich.lei...@stat.uni-muenchen.de> wrote:
>>
>> > > On Tue, 14 Dec 2010 12:40:04 +0100,
>> > > Romain Francois (RF) wrote:
>> >
>> > > Hello,
>> > > Sweave lets you use alternative drivers through the driver
>> argument, and
>> > > several packages take advantage of that and define custom Sweave
>> driver
>> > > for various purposes. Most of them are listed on the Reproducible
>> > > Research CTV:
>> > > (http://cran.r-project.org/web/views/ReproducibleResearch.html)
>> >
>> > > The next natural step is for package developpers to take advantage
>> of
>> > > this in their vignettes. In Rcpp we work around the way package
>> building
>> > > works and we do:
>> > > - let R build a dummy vignette
>> > > - then use the inst/doc/Makefile to replace it with a vignette that
>> is
>> > > processed by the driver from the highlight package (giving syntax
>> > > highlighting).
>> >
>> > > I played with Sweave so that it would be able to create the driver
>> from
>> > > some text included in the text of the .Rnw file:
>> >
>> > > $ svn diff
>> > > Index: src/library/utils/R/Sweave.R
>> > > ===
>> > > --- src/library/utils/R/Sweave.R(revision 53846)
>> > > +++ src/library/utils/R/Sweave.R(working copy)
>> > > @@ -20,6 +20,16 @@
>> > ># We don't need srclines for code, but we do need it for text,
>> and
>> > > it's easiest
>> > ># to just keep it for everything.
>> >
>> > > +SweaveGetDriver<- function(file){
>> > > +txt<- readLines(file)
>> > > +line<- grep( "\\SweaveDriver", txt, value = TRUE )
>> > > +if( length(line) ){
>> > > +txt<- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L]
>> )
>> > > +driver<- try( eval( parse( text = txt ) ), silent = TRUE )
>> > > +if( !inherits( driver, "try-error") ) driver
>> > > +}
>> > > +}
>> > > +
>> > >Sweave<- function(file, driver=RweaveLatex(),
>> > > syntax=getOption("SweaveSyntax"), ...)
>> > >{
>> > > @@ -28,7 +38,9 @@
>> > >else if(is.function(driver))
>> > >driver<- driver()
>> >
>> > > -
>> > > +drv<- SweaveGetDriver(file)
>> > > +if( !is.null(drv) ) driver<- drv
>> > > +
>> > >if(is.null(syntax))
>> > >syntax<- SweaveGetSyntax(file)
>> > >if(is.character(syntax))
>> >
>> >
>> >
>> > > This allows one to write something like this in their file:
>> >
>> > > %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
>> >
>> > > So that when calling :
>> >
>> > >> Sweave( "somefile.Rnw" )
>> >
>> > > the highlight driver i
[Rd] postscript failure manifests in plot.TukeyHSD
Hello R Developers, Dear R-developers, I ran some standard tests with currently (today morning) compiled R release candidate in Linux R 2.12.1 RC (2010-12-13 r53843). Some of these tests used plot.TukeyHSD function. This worked OK on the screen (X11 device), but PostScript file could not be rendered. The following example had the problem with me: postscript(file="tukeyplot.ps") example(plot.TukeyHSD) dev.off() I couldn't view the resulting file with evince in Linux nor in the standard Preview in MacOS. When I compared the generated "tukeyplot.ps" to the same file generated with an older R in my Mac, I found one difference: $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 @@ -172,5 +172,5 @@ 0 setgray 0.00 setlinewidth -[ 3.00 5.00] 0 setdash +[ 0.00 0.00] 0 setdash np 660.06 91.44 m Editing the changed line to its old value "[ 3.00 5.00] 0 setdash" also fixed the problem both in Linux and in Mac. Evidently something has changed, and probably somewhere else than in plot.TukeyHSD (which hasn't changed since r51093 in trunk and never in R-2-12-branch). I know nothing about PostScript so that I cannot say anything more (and I know viewers can fail with standard conforming PostScript but it is a bit disconcerting that two viewers fail when they worked earlier). Cheers, Jari Oksanen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embed Sweave driver in .Rnw file
On 14/12/2010 10:52 AM, Dominick Samperi wrote:
Both of my questions were not clear, sorry.
What I really want to do is have a customized version of Sweave.sty
(Sweave++.sty)
included automatically from some designated area, like the include directory
of another
package, rather than requiring the user to keep a version in the local
directory. Since
the changes are minor, it might make more sense to solve this by
incorporating
them into Sweave.sty.
I don't know a way to refer to package directories from a Sweave
document. It might be possible to write an R function that writes out
system-dependent \usepackage{} commands, and put that in a results=tex
code chunk. However, I'm not certain LaTeX can handle Windows paths in
general (spaces and tildes both seem to cause problems, and I don't know
a way to avoid both), so this might be impossible.
On the temp directory, yes, I'm talking about Sweave's prefix option. Your
suggestion
to use dir.create() sounds like a reasonable work-around for the fact that
TeX cannot perform OS-level functions.
The directory needs to be in place by the time you write out a figure or
concordance from Sweave, so TeX can't be involved in creating it.
Yet another small issue that I'm sure others have encountered is that
TeX processing will fail under Linux when the source files contain DOS CR's,
and
the error diagnostics would leave you in the dark. The only fix that I could
come up with is to remove the CR's manually using tr. Is there a better way?
I think it is most productive to think of the .tex output from Sweave as
system-dependent object files, not portable source. I'm pretty sure
Sweave can read CR/LF files on any system and will write out local line
endings. So it's only a problem when you distribute the .tex output of
Sweave, not when you distribute the .Rnw input. (I understand there are
circumstances where this is unavoidable, but you shouldn't be surprised
when object files aren't portable.)
Duncan Murdoch
Thanks,
Dominick
On Tue, Dec 14, 2010 at 10:26 AM, Duncan Murdoch
wrote:
> On 14/12/2010 9:54 AM, Dominick Samperi wrote:
>
>> Another question about Sweave (actually it is more a question
>> about TeX). Is there a reliable (system-independent) way to
>> use Sweave.sty without having to place it in the current working
>> directory? MiKTeX under Windows has dropped the use of
>> TEXINPUTS, and this complicates the problem.
>>
>
> If you run it from R, the right path will be put in place. The
> tools::texi2dvi function does this.
>
>
> Furthermore, you cannot refer to Sweave.sty using its full path
>> as this would obviously not be system-independent.
>>
>> Yet another small issue: If I configure Sweave to use a
>> temp directory for its temp files, and if this temp directory
>> does not exist, TeX fails with error diagnostics that is not
>> clear at all. Is there a way to have TeX automatically
>> create the directory if necessary?
>>
>
> I don't understand this one. Are you talking about a "prefix=somedir/"
> option to Sweave? That needs to be there before TeX is run. I sometimes
> put a dir.create("somedir", showWarnings=FALSE) call in an early chunk in
> the document to create it.
>
> Duncan Murdoch
>
> Thanks,
>> Dominick
>>
>> On Tue, Dec 14, 2010 at 7:21 AM, Friedrich Leisch<
>> friedrich.lei...@stat.uni-muenchen.de> wrote:
>>
>> > > On Tue, 14 Dec 2010 12:40:04 +0100,
>> > > Romain Francois (RF) wrote:
>> >
>> >> Hello,
>> >> Sweave lets you use alternative drivers through the driver
>> argument, and
>> >> several packages take advantage of that and define custom Sweave
>> driver
>> >> for various purposes. Most of them are listed on the Reproducible
>> >> Research CTV:
>> >> (http://cran.r-project.org/web/views/ReproducibleResearch.html)
>> >
>> >> The next natural step is for package developpers to take advantage
>> of
>> >> this in their vignettes. In Rcpp we work around the way package
>> building
>> >> works and we do:
>> >> - let R build a dummy vignette
>> >> - then use the inst/doc/Makefile to replace it with a vignette that
>> is
>> >> processed by the driver from the highlight package (giving syntax
>> >> highlighting).
>> >
>> >> I played with Sweave so that it would be able to create the driver
>> from
>> >> some text included in the text of the .Rnw file:
>> >
>> >> $ svn diff
>> >> Index: src/library/utils/R/Sweave.R
>> >> ===
>> >> --- src/library/utils/R/Sweave.R(revision 53846)
>> >> +++ src/library/utils/R/Sweave.R(working copy)
>> >> @@ -20,6 +20,16 @@
>> >> # We don't need srclines for code, but we do need it for text,
>> and
>> >> it's easiest
>> >> # to just keep it for everything.
>> >
>> >> +S
Re: [Rd] embed Sweave driver in .Rnw file
On Tue, Dec 14, 2010 at 11:13 AM, Duncan Murdoch
wrote:
> On 14/12/2010 10:52 AM, Dominick Samperi wrote:
>
>> Both of my questions were not clear, sorry.
>>
>> What I really want to do is have a customized version of Sweave.sty
>> (Sweave++.sty)
>> included automatically from some designated area, like the include
>> directory
>> of another
>> package, rather than requiring the user to keep a version in the local
>> directory. Since
>> the changes are minor, it might make more sense to solve this by
>> incorporating
>> them into Sweave.sty.
>>
>
> I don't know a way to refer to package directories from a Sweave document.
> It might be possible to write an R function that writes out
> system-dependent \usepackage{} commands, and put that in a results=tex code
> chunk. However, I'm not certain LaTeX can handle Windows paths in general
> (spaces and tildes both seem to cause problems, and I don't know a way to
> avoid both), so this might be impossible.
>
>
> On the temp directory, yes, I'm talking about Sweave's prefix option. Your
>> suggestion
>> to use dir.create() sounds like a reasonable work-around for the fact that
>> TeX cannot perform OS-level functions.
>>
>
> The directory needs to be in place by the time you write out a figure or
> concordance from Sweave, so TeX can't be involved in creating it.
>
>
> Yet another small issue that I'm sure others have encountered is that
>> TeX processing will fail under Linux when the source files contain DOS
>> CR's,
>> and
>> the error diagnostics would leave you in the dark. The only fix that I
>> could
>> come up with is to remove the CR's manually using tr. Is there a better
>> way?
>>
>
> I think it is most productive to think of the .tex output from Sweave as
> system-dependent object files, not portable source. I'm pretty sure Sweave
> can read CR/LF files on any system and will write out local line endings.
> So it's only a problem when you distribute the .tex output of Sweave, not
> when you distribute the .Rnw input. (I understand there are circumstances
> where this is unavoidable, but you shouldn't be surprised when object files
> aren't portable.)
Here is a small clarification, related to Romain's original post about
highlight. The highlight program (used by Romain't highlight package
the last time I looked) generates .tex files from source files (either R or
C++ source), and if the original .R or .cpp file
contains DOS CR's, so will the generated .tex file, and TeX will choke
(under Linux). Thus in this sense even source files are
system-dependent.
>
>
> Duncan Murdoch
>
> Thanks,
>> Dominick
>>
>> On Tue, Dec 14, 2010 at 10:26 AM, Duncan Murdoch
>> wrote:
>>
>> > On 14/12/2010 9:54 AM, Dominick Samperi wrote:
>> >
>> >> Another question about Sweave (actually it is more a question
>> >> about TeX). Is there a reliable (system-independent) way to
>> >> use Sweave.sty without having to place it in the current working
>> >> directory? MiKTeX under Windows has dropped the use of
>> >> TEXINPUTS, and this complicates the problem.
>> >>
>> >
>> > If you run it from R, the right path will be put in place. The
>> > tools::texi2dvi function does this.
>> >
>> >
>> > Furthermore, you cannot refer to Sweave.sty using its full path
>> >> as this would obviously not be system-independent.
>> >>
>> >> Yet another small issue: If I configure Sweave to use a
>> >> temp directory for its temp files, and if this temp directory
>> >> does not exist, TeX fails with error diagnostics that is not
>> >> clear at all. Is there a way to have TeX automatically
>> >> create the directory if necessary?
>> >>
>> >
>> > I don't understand this one. Are you talking about a "prefix=somedir/"
>> > option to Sweave? That needs to be there before TeX is run. I
>> sometimes
>> > put a dir.create("somedir", showWarnings=FALSE) call in an early chunk
>> in
>> > the document to create it.
>> >
>> > Duncan Murdoch
>> >
>> > Thanks,
>> >> Dominick
>> >>
>> >> On Tue, Dec 14, 2010 at 7:21 AM, Friedrich Leisch<
>> >> friedrich.lei...@stat.uni-muenchen.de> wrote:
>> >>
>> >> > > On Tue, 14 Dec 2010 12:40:04 +0100,
>> >> > > Romain Francois (RF) wrote:
>> >> >
>> >> >> Hello,
>> >> >> Sweave lets you use alternative drivers through the driver
>> >> argument, and
>> >> >> several packages take advantage of that and define custom
>> Sweave
>> >> driver
>> >> >> for various purposes. Most of them are listed on the
>> Reproducible
>> >> >> Research CTV:
>> >> >> (
>> http://cran.r-project.org/web/views/ReproducibleResearch.html)
>> >> >
>> >> >> The next natural step is for package developpers to take
>> advantage
>> >> of
>> >> >> this in their vignettes. In Rcpp we work around the way
>> package
>> >> building
>> >> >> works and we do:
>> >> >> - let R build a dummy vignette
>> >> >> - then use the inst/doc/Makefile to replace it with a
>> vignet
Re: [Rd] postscript failure manifests in plot.TukeyHSD
Jari Oksanen oulu.fi> writes: > > Hello R Developers, > > Dear R-developers, > > I ran some standard tests with currently (today morning) compiled R release > candidate in Linux R 2.12.1 RC (2010-12-13 r53843). Some of these tests used > plot.TukeyHSD function. This worked OK on the screen (X11 device), but > PostScript file could not be rendered. The following example had the problem > with me: > > postscript(file="tukeyplot.ps") > example(plot.TukeyHSD) > dev.off() > > I couldn't view the resulting file with evince in Linux nor in the standard > Preview in MacOS. When I compared the generated "tukeyplot.ps" to the same > file generated with an older R in my Mac, I found one difference: > > $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps > --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 > +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 > @@ -172,5 +172,5 @@ > 0 setgray > 0.00 setlinewidth > -[ 3.00 5.00] 0 setdash > +[ 0.00 0.00] 0 setdash > np > 660.06 91.44 m > > Editing the changed line to its old value "[ 3.00 5.00] 0 setdash" also > fixed the problem both in Linux and in Mac. Evidently something has changed, > and probably somewhere else than in plot.TukeyHSD (which hasn't changed > since r51093 in trunk and never in R-2-12-branch). I know nothing about > PostScript so that I cannot say anything more (and I know viewers can fail > with standard conforming PostScript but it is a bit disconcerting that two > viewers fail when they worked earlier). I must really be avoiding work today ... I can diagnose this (I think) but don't know the best way to solve it. At this point, line widths on PDF devices were allowed to be <1. == r52180 | murrell | 2010-06-02 23:20:33 -0400 (Wed, 02 Jun 2010) | 1 line Changed paths: M /trunk/NEWS M /trunk/src/library/grDevices/src/devPS.c allow lwd less than 1 on PDF device == The behavior of PDF devices (by experiment) is to draw a 0-width line as 1 pixel wide, at whatever resolution is currently being rendered. On the other hand, 0-width lines appear to break PostScript. (with the Linux viewer 'evince' I get warnings about "rangecheck -15" when trying to view such a file). plot.TukeyHSD contains the lines abline(h = yvals, lty = 1, lwd = 0, col = "lightgray") abline(v = 0, lty = 2, lwd = 0, ...) which are presumably meant to render minimum-width lines. I don't know whether it makes more sense to (1) change plot.TukeyHSD to use positive widths (although that may not help: I tried setting lwd=1e-5 and got the line widths rounded to 0 in the PostScript file); (2) change the postscript driver to *not* allow line widths < 1 (i.e., distinguish between PS and PDF and revert to the pre-r52180 behaviour for PS only). On reflection #2 seems to make more sense, but digging through devPS.c it's not immediately obvious to me where/how in SetLineStyle or PostScriptSetLineTexture one can tell whether the current driver is PS or PDF ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
On 2010-12-14 09:27, Ben Bolker wrote: Jari Oksanen oulu.fi> writes: Hello R Developers, Dear R-developers, I ran some standard tests with currently (today morning) compiled R release candidate in Linux R 2.12.1 RC (2010-12-13 r53843). Some of these tests used plot.TukeyHSD function. This worked OK on the screen (X11 device), but PostScript file could not be rendered. The following example had the problem with me: postscript(file="tukeyplot.ps") example(plot.TukeyHSD) dev.off() I couldn't view the resulting file with evince in Linux nor in the standard Preview in MacOS. When I compared the generated "tukeyplot.ps" to the same file generated with an older R in my Mac, I found one difference: $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 @@ -172,5 +172,5 @@ 0 setgray 0.00 setlinewidth -[ 3.00 5.00] 0 setdash +[ 0.00 0.00] 0 setdash np 660.06 91.44 m Editing the changed line to its old value "[ 3.00 5.00] 0 setdash" also fixed the problem both in Linux and in Mac. Evidently something has changed, and probably somewhere else than in plot.TukeyHSD (which hasn't changed since r51093 in trunk and never in R-2-12-branch). I know nothing about PostScript so that I cannot say anything more (and I know viewers can fail with standard conforming PostScript but it is a bit disconcerting that two viewers fail when they worked earlier). I must really be avoiding work today ... I can diagnose this (I think) but don't know the best way to solve it. At this point, line widths on PDF devices were allowed to be<1. == r52180 | murrell | 2010-06-02 23:20:33 -0400 (Wed, 02 Jun 2010) | 1 line Changed paths: M /trunk/NEWS M /trunk/src/library/grDevices/src/devPS.c allow lwd less than 1 on PDF device == The behavior of PDF devices (by experiment) is to draw a 0-width line as 1 pixel wide, at whatever resolution is currently being rendered. On the other hand, 0-width lines appear to break PostScript. (with the Linux viewer 'evince' I get warnings about "rangecheck -15" when trying to view such a file). plot.TukeyHSD contains the lines abline(h = yvals, lty = 1, lwd = 0, col = "lightgray") abline(v = 0, lty = 2, lwd = 0, ...) which are presumably meant to render minimum-width lines. I don't know whether it makes more sense to (1) change plot.TukeyHSD to use positive widths (although that may not help: I tried setting lwd=1e-5 and got the line widths rounded to 0 in the PostScript file); (2) change the postscript driver to *not* allow line widths< 1 (i.e., distinguish between PS and PDF and revert to the pre-r52180 behaviour for PS only). On reflection #2 seems to make more sense, but digging through devPS.c it's not immediately obvious to me where/how in SetLineStyle or PostScriptSetLineTexture one can tell whether the current driver is PS or PDF ... That may not do it. I find the same problem (fixed by Jari's replacement of [ 0.00 0.00] with [ 3.00 5.00]; haven't tried anything else yet) when I use pdf() instead of postscript(). This is on Vista. Peter Ehlers __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] postscript failure manifests in plot.TukeyHSD
On 10-12-14 01:16 PM, Peter Ehlers wrote: > On 2010-12-14 09:27, Ben Bolker wrote: >> Jari Oksanen oulu.fi> writes: >> >>> >>> Hello R Developers, >>> >>> Dear R-developers, >>> >>> I ran some standard tests with currently (today morning) compiled R >>> release >>> candidate in Linux R 2.12.1 RC (2010-12-13 r53843). Some of these >>> tests used >>> plot.TukeyHSD function. This worked OK on the screen (X11 device), but >>> PostScript file could not be rendered. The following example had the >>> problem >>> with me: >>> >>> postscript(file="tukeyplot.ps") >>> example(plot.TukeyHSD) >>> dev.off() >>> >>> I couldn't view the resulting file with evince in Linux nor in the >>> standard >>> Preview in MacOS. When I compared the generated "tukeyplot.ps" to the >>> same >>> file generated with an older R in my Mac, I found one difference: >>> >>> $ diff -U2 oldtukeyplot.ps /Volumes/TIKKU/tukeyplot.ps >>> --- oldtukeyplot.ps2010-12-14 12:06:07.0 +0200 >>> +++ /Volumes/TIKKU/tukeyplot.ps2010-12-14 12:13:32.0 +0200 >>> @@ -172,5 +172,5 @@ >>> 0 setgray >>> 0.00 setlinewidth >>> -[ 3.00 5.00] 0 setdash >>> +[ 0.00 0.00] 0 setdash >>> np >>> 660.06 91.44 m >>> >>> Editing the changed line to its old value "[ 3.00 5.00] 0 setdash" also >>> fixed the problem both in Linux and in Mac. Evidently something has >>> changed, >>> and probably somewhere else than in plot.TukeyHSD (which hasn't changed >>> since r51093 in trunk and never in R-2-12-branch). I know nothing about >>> PostScript so that I cannot say anything more (and I know viewers can >>> fail >>> with standard conforming PostScript but it is a bit disconcerting >>> that two >>> viewers fail when they worked earlier). >> >>I must really be avoiding work today ... >> >>I can diagnose this (I think) but don't know the best way to >> solve it. >> >>At this point, line widths on PDF devices were allowed to be<1. >> >> == >> r52180 | murrell | 2010-06-02 23:20:33 -0400 (Wed, 02 Jun 2010) | 1 line >> Changed paths: >> M /trunk/NEWS >> M /trunk/src/library/grDevices/src/devPS.c >> >> allow lwd less than 1 on PDF device >> == >> >>The behavior of PDF devices (by experiment) is to draw a 0-width >> line as 1 pixel wide, at whatever resolution is currently being >> rendered. On the other hand, 0-width lines appear to break PostScript. >> (with the Linux viewer 'evince' I get warnings about "rangecheck -15" >> when trying to view such a file). >> >>plot.TukeyHSD contains the lines >> >> abline(h = yvals, lty = 1, lwd = 0, col = "lightgray") >> abline(v = 0, lty = 2, lwd = 0, ...) >> >>which are presumably meant to render minimum-width lines. >> >>I don't know whether it makes more sense to (1) change plot.TukeyHSD >> to use positive widths (although that may not help: I tried setting >> lwd=1e-5 and got the line widths rounded to 0 in the PostScript file); >> (2) change the postscript driver to *not* allow line widths< 1 (i.e., >> distinguish between PS and PDF and revert to the pre-r52180 behaviour >> for PS only). >> >>On reflection #2 seems to make more sense, but digging through devPS.c >> it's not immediately obvious to me where/how in SetLineStyle or >> PostScriptSetLineTexture one can tell whether the current driver >> is PS or PDF ... >> > That may not do it. I find the same problem (fixed by > Jari's replacement of [ 0.00 0.00] with [ 3.00 5.00]; > haven't tried anything else yet) when I use pdf() > instead of postscript(). > This is on Vista. > > Peter Ehlers With PDF, I get "invalid value for a dash setting" from evince -- perhaps the dash lengths are being set relative to the line width? (Could investigate but had better continue with other things ...) Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] redesign R.css for HTML help pages
Hi,
I feel the CSS definitions for the HTML help pages are not visually
appealing enough. I admit this is a very subjective matter, so I don't
have strong arguments for this wishlist, although I wrote my version
of R.css with some web design instructions in mind (e.g. use
browser-safe sans-serif fonts).
Anyway, here is what I've done:
https://github.com/yihui/configuration/raw/master/R.css
This CSS file is under file.path(R.home('doc'), 'html') after installation.
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to specify compiler options when using R CMD SHLIB
Hi I've built a dll using Fortran code and can call it by either R or Fortran. Calling by the former gives me the wrong answer and the later gives the correct answer. >From what I've read, it looks like I should use the subroutines DBLEPR, INTPR and REALPR to print to the R console rather than using Fortran standard I/O and that if I use the command R CMD SHLIB source.f that these subroutines will automatically be found (Please correct me if I'm wrong about any of this). The problem is that I have to specify the gfortran compiler option -fno-range-check in order for my code to compile. I've tried setting PKG_FCFLAGS=-fno-range-check in a file named Makevars under the same directory as my Fortran files but this doesn't seem to be the right place because R CMD SHLIB still produces error messages related to integer overflow (the same error as when I run gfortran -c MRPP.f90 as opposed to gfortran -c MRPP.f90 -fno-range-check) when I type R CMD SHLIB MRPP.f90. So I was wondering if anyone could tell me how compiler option should be specified when using R CMD SHLIB? I appreciate the help. Marian K Talbert ASRC Management Servics Contracted To: US Geological Survey Fort Collins Science Center 2150 Centre Ave., Bldg C Fort Collins, CO 80526 Phone: 970-226-9108 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to specify compiler options when using R CMD SHLIB
On 14 December 2010 at 13:25, Marian K Talbert wrote: | Hi | | I've built a dll using Fortran code and can call it by either R or | Fortran. Calling by the former gives me the wrong answer and the later | gives the correct answer. | | >From what I've read, it looks like I should use the subroutines DBLEPR, | INTPR and REALPR to print to the R console rather than using Fortran | standard I/O and that if I use the command | R CMD SHLIB source.f that these subroutines will automatically be found | (Please correct me if I'm wrong about any of this). The problem is that I | have to specify the gfortran compiler option -fno-range-check in order for | my code to compile. I've tried setting PKG_FCFLAGS=-fno-range-check in a | file named Makevars under the same directory as my Fortran files but this | doesn't seem to be the right place because R CMD SHLIB still produces | error messages related to integer overflow (the same error as when I run | gfortran -c MRPP.f90 as opposed to gfortran -c MRPP.f90 -fno-range-check) | when I type | | R CMD SHLIB MRPP.f90. | | So I was wondering if anyone could tell me how compiler option should be | specified when using R CMD SHLIB? I use ~/.R/Makevars where you can set all variables your in in $RHOME/etc/Makeconf Setting the as environment variables will also work by virtue of make (and that is what the inline package does). Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Namespace File
Dear Colleagues,
I am developing a library. However I am having the following problem with the
file NAMESPACE.
My file contains:
useDynLib(Bayesthres, vuA)
export(Bayesthres,
random.effects,
fixed.effects,
)
exportClasses("Bayesthres")
My function is:
Avuall <- function(Zz, Dd, A, Vu, FL)
{
m <- dim(A)[1]
n <- dim(A)[2]
tc <- length(Vu)
ifc <- unlist(lapply(FL$fl, function(x) length(levels(x
il <- 1
ic <- ifc[1]
for(i in 2:tc){
ic[i] <- ifc[i]+ic[i-1]
il[i] <- ic[i]-ifc[i]+1
}
storage.mode(A) <- "double"
Aux <- .Fortran("vuA", as.double(Vu), A=A, as.integer(ic), as.integer(il),
as.integer(m),
as.integer(n), as.integer(tc), PACKAGE="Bayesthres")$A
V <- rbind(Zz, cbind(Dd,Aux))
return(V)
}
The vuA file was written in Fortran95. It's within the src directory.
However the following error appears in R CMD check
Error in .Fortran("vuA", as.double(Vu), A = A, as.integer(ic), as.integer(il),
:
name simbol in Fortran "vua" not is in DLL library "Bayesthres"
Error : unable to load R code in package 'Bayesthres'
ERROR: lazy loading failed for package ‘Bayesthres’
Where can I be wrong?
Thank you very much!
Fábio Mathias Corrêa
Departamento de Estatística
Universidade Estadual de Santa Cruz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
