[Rd] Fwd: warning or error upon type/storage mode coercion?
-- Forwarded message -- From: Karl Forner karl.for...@gmail.com Date: Wed, Sep 15, 2010 at 10:14 AM Subject: Re: [Rd] warning or error upon type/storage mode coercion? To: Stefan Evert stefa...@collocations.de I'm a Perl fan, and I really really miss the use strict feature. IMHO it's very error-prone not to have thios safety net. Best, On Wed, Sep 15, 2010 at 9:54 AM, Stefan Evert stefa...@collocations.dewrote: On 15 Sep 2010, at 03:23, Benjamin Tyner wrote: 2. So, assuming the answer to (1) is a resounding no, does anyone care to state an opinion regarding the philosophical or historical rationale for why this is the case in R/S, whereas certain other interpreted languages offer the option to perform strict type checking? Basically, I'm trying to explain to someone from a perl background why the (apparent) lack of a use strict; use warnings; equivalent is not a hindrance to writing bullet-proof R code. If they're from a Perl background, you might also want to point out to them that (base) Perl doesn't do _any_ type checking at all, and converts types as needed. As in ... $x = 0.0; if ($x) ... # true if ($x+0) ... # false AFAIK, that's one of the main complaints that people have about Perl. use strict will just make sure that all variables have to be declared before they're used, so you can't mess up by mistyping variable names. Which is something I'd very much like to have in R occasionally ... Best, Stefan __ 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] value returned by by()
On 14.09.2010 20:50, Seb wrote: On Tue, 14 Sep 2010 12:02:04 +0200, Uwe Liggeslig...@statistik.tu-dortmund.de wrote: It returns a list with athe class attribut set to by, just use: x- by(.) unclass(x) Thanks Uwe, however, that still returns an array when using the data.frame method for by(): R class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary [1] array It seems as if the only way to really ensure a list: R class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary))), function(x) x)) [1] list but it seems like a waste to call another function just to do this. Then you could still do x - by(.) attributes(x) - NULL Uwe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Add DESCRIPTION 'Date' to R CMD check log header
Martin Maechler writes:
Hi Henrik
HB == Henrik Bengtsson h...@stat.berkeley.edu
on Tue, 14 Sep 2010 18:26:31 -0700 writes:
HB Hi,
HB in R CMD check, the version of the package being checked is reported, e.g.
HB Thu Sep 9 05:02:30 2010: Checking package R.utils (SVN revision 399) ...
HB * using log directory ‘/srv/R/R.check/R-devel/PKGS/R.utils.Rcheck’
HB * using R version 2.12.0 Under development (unstable) (2010-09-07 r52876)
HB * using platform: x86_64-unknown-linux-gnu (64-bit)
HB * using session charset: UTF-8
HB * checking for file ‘R.utils/DESCRIPTION’ ... OK
HB * this is package ‘R.utils’ version ‘1.5.2’
HB ...
HB I'd like to request/suggest that the 'Date' in the DESCRIPTION file is
HB also added, e.g.
HB * this is package ‘R.utils’ version ‘1.5.2’ ('2010-09-14')
HB WHY?
HB This would be particular useful when you work toward sites like
HB R-forge and Bioconductor when you may commit your day's work on
HB package when you update the 'Date' but you do not really want to
HB update the 'Version' because you're going to put in more work
HB tomorrow. With the 'Date' information you'll be able to see what
HB version of your updates have been checked by the servers. I
HB understand that this may be an odd process to follow even for devel
HB branches and you may argue that you should always bump the version
HB number whenever you do an SVN commit (e.g. '1.5.2.1' for temporary
HB commits). Either way, I find it useful to see the date as well.
I agree that this is useful.
Of course, for all those cases, where there's no Date:,
nothing (i.e. no ()) should be written.
If you (or someone) provide patches against R-devel
( https://svn.r-project.org/R/trunk/ )
and they pass 'make check-all', I'd add this feature.
But pls not against the Date field by default:
R-Forge packages record their revision in their package metadata.
CRAN packages record Date/Publication in their metadata.
Not sure about BioC ...
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] list2env( list() )
Hello,
list2env generates an error on empty lists.
l - list()
list2env( l )
Erreur dans list2env(l) : names(x) must be valid character(length(x)).
This is consistent with the requirement that the list must be a
__named__ list, so this works:
names(l) - character(0)
list2env( l )
environment: 0x102b8fbc8
But I was wondering if it would make sense to make a special case of
zero sized lists, with this:
Index: src/main/envir.c
===
--- src/main/envir.c(revision 52910)
+++ src/main/envir.c(working copy)
@@ -1555,7 +1555,7 @@
x = CAR(args); args = CDR(args);
n = LENGTH(x);
xnms = getAttrib(x, R_NamesSymbol);
-if (TYPEOF(xnms) != STRSXP || LENGTH(xnms) != n)
+if (n (TYPEOF(xnms) != STRSXP || LENGTH(xnms) != n) )
error(_(names(x) must be valid character(length(x)).));
envir = CAR(args); args = CDR(args);
if (TYPEOF(envir) == NILSXP) {
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/cCmbgg : Rcpp 0.8.6
|- http://bit.ly/bzoWrs : Rcpp svn revision 2000
`- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] value returned by by()
On Sep 15, 2010, at 10:55 , Uwe Ligges wrote: On 14.09.2010 20:50, Seb wrote: On Tue, 14 Sep 2010 12:02:04 +0200, Uwe Liggeslig...@statistik.tu-dortmund.de wrote: It returns a list with athe class attribut set to by, just use: x- by(.) unclass(x) Thanks Uwe, however, that still returns an array when using the data.frame method for by(): R class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary [1] array It seems as if the only way to really ensure a list: R class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary))), function(x) x)) [1] list but it seems like a waste to call another function just to do this. Then you could still do x - by(.) attributes(x) - NULL Or just use c() instead of unclass(). (The root cause is that even with simplify=FALSE, tapply() will always create an array, in this case a 1d array with dim=3. The _contents_ of the array will be a list, though.) Notice that in the relevant cases, what you get really _is_ a list, and both walks and quacks like one. E.g. L - with(warpbreaks, by(warpbreaks[, 1], tension, mean, simplify=FALSE)) is.list(L) [1] TRUE L$M [1] 26.38889 -- Peter Dalgaard 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] value returned by by()
On Wed, 15 Sep 2010 11:29:23 +0200,
peter dalgaard pda...@gmail.com wrote:
On Sep 15, 2010, at 10:55 , Uwe Ligges wrote:
On 14.09.2010 20:50, Seb wrote:
On Tue, 14 Sep 2010 12:02:04 +0200,
Uwe Liggeslig...@statistik.tu-dortmund.de wrote:
It returns a list with athe class attribut set to by, just use: x-
by(.) unclass(x)
Thanks Uwe, however, that still returns an array when using the
data.frame method for by():
R class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension,
summary
[1] array
It seems as if the only way to really ensure a list:
R class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension,
summary))), function(x) x))
[1] list
but it seems like a waste to call another function just to do this.
Then you could still do
x - by(.)
attributes(x) - NULL
Or just use c() instead of unclass(). (The root cause is that even with
simplify=FALSE, tapply() will always create an array, in this case a 1d array
with dim=3. The _contents_ of the array will be a list, though.)
Notice that in the relevant cases, what you get really _is_ a list, and both
walks and quacks like one. E.g.
L - with(warpbreaks, by(warpbreaks[, 1], tension, mean, simplify=FALSE))
is.list(L)
[1] TRUE
L$M
[1] 26.38889
But if one tries to include this list dressed in 'by' clothes into an S4
class slot declared as a list, then we have problems. In that case, I
propose this simple patch to by.Rd, which simply removes the statement
about the result being *always* a list.
Index: by.Rd
===
--- by.Rd (revision 52375)
+++ by.Rd (working copy)
@@ -36,8 +36,6 @@
}
\value{
An object of class \code{by}, giving the results for each subset.
- This is always a list if \code{simplify} is false, otherwise a list or
- array (see \code{\link{tapply}}).
}
\seealso{\code{\link{tapply}}}
Thanks!
--
Seb
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 method for package listed in suggest/enhance
On 01.09.2010 17:38, Hadley Wickham wrote: Hi all, The profr package provides a method for displaying its output with ggplot: ggplot.print. You don't need this ggplot2 to use profr, so ggplot2 is listed under enhances in the DESCRIPTION file. If I have just S3method(ggplot, profr) in my NAMESPACE, then I get: ** testing if installed package can be loaded Error : object 'ggplot' not found whilst loading namespace 'profr' ERROR: loading failed If I have both S3method(ggplot, profr) and importFrom(ggplot2, ggplot), then I get: * checking package dependencies ... ERROR Namespace dependency not required: ggplot2 What's the correct way of exporting an S3 method for a generic in a suggested package? I think you need to declare it as a Depends, since it has to be available for getting the Namespace directives right. Uwe Thanks, Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] value returned by by()
On 15.09.2010 15:00, Seb wrote:
On Wed, 15 Sep 2010 11:29:23 +0200,
peter dalgaardpda...@gmail.com wrote:
On Sep 15, 2010, at 10:55 , Uwe Ligges wrote:
On 14.09.2010 20:50, Seb wrote:
On Tue, 14 Sep 2010 12:02:04 +0200,
Uwe Liggeslig...@statistik.tu-dortmund.de wrote:
It returns a list with athe class attribut set to by, just use: x-
by(.) unclass(x)
Thanks Uwe, however, that still returns an array when using the
data.frame method for by():
R class(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension, summary
[1] array
It seems as if the only way to really ensure a list:
R class(lapply(unclass(with(warpbreaks, by(warpbreaks[, 1:2], tension,
summary))), function(x) x))
[1] list
but it seems like a waste to call another function just to do this.
Then you could still do
x- by(.)
attributes(x)- NULL
Or just use c() instead of unclass(). (The root cause is that even with
simplify=FALSE, tapply() will always create an array, in this case a 1d array
with dim=3. The _contents_ of the array will be a list, though.)
Notice that in the relevant cases, what you get really _is_ a list, and both
walks and quacks like one. E.g.
L- with(warpbreaks, by(warpbreaks[, 1], tension, mean, simplify=FALSE))
is.list(L)
[1] TRUE
L$M
[1] 26.38889
But if one tries to include this list dressed in 'by' clothes into an S4
class slot declared as a list, then we have problems. In that case, I
propose this simple patch to by.Rd, which simply removes the statement
about the result being *always* a list.
Index: by.Rd
===
--- by.Rd (revision 52375)
+++ by.Rd (working copy)
@@ -36,8 +36,6 @@
}
\value{
An object of class \code{by}, giving the results for each subset.
- This is always a list if \code{simplify} is false, otherwise a list or
- array (see \code{\link{tapply}}).
}
\seealso{\code{\link{tapply}}}
Thanks!
Why? It is still accessible as a list, even with S4 object, at least for
the cases I tried.
Uwe Ligges
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
On 29.08.2010 22:34, Kyle Matoba wrote:
All,
I just finished the process of build a package for the first time and found
it characteristically (for R) very straightforward and well documented.
Whenever I deal with open source software I always endeavor to finish the
task I have in mind, and upon completing this, I then revisit all of the
configurations, customizing as necessary to achieve my goals more fully.
The ability to achieve some minimal level of functionality without the need
for much filling in of configuration files, etc., is, I feel, important to
not scaring off the less technically inclined such as myself.
Based on this heuristic, it is my understanding that a few small suggestions
could make building a warning-free package as easy as running
package.skeleton(), then R CMD check, R CMD build:
- Fill in default titles for each of the '*.Rd' files in /man
- Take out the tildes in the 'examples' section of the '*-package.Rd' main
documentation file for the package (it seems to confuse the latex compiler)
- Put the lines '~~ Optionally other standard keywords, one per line, from
file KEYWORDS in ~~
~~ the R documentation directory ~~' into the \references{} section, there
is presently a warning about all text needing to be in a section.
Dear Kyle,
thanks for the suggestions. Actually, it is intended to generate
warnings / Errors in R CMD check: We want to force package developers to
document their packages probably. This way, package maintainers /
developers have to touch each Rd file and cannot use them as is in order
to pass the checks.
Best wishes,
uwe
Thanks, as always, to everyone for their hard work to keep my statistical
computing free and easy.
Best,
Kyle
[[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] value returned by by()
On Wed, 15 Sep 2010 15:15:27 +0200, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: Why? It is still accessible as a list, even with S4 object, at least for the cases I tried. R wL - with(warpbreaks, by(warpbreaks[, 1:2], tension, summary)) R setClass(Whatever, + representation=representation(A=list)) [1] Whatever R new(Whatever, A=wL) Error in validObject(.Object) : invalid class Whatever object: invalid object for slot A in class Whatever: got class by, should be or extend class list -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Roxygen: question regarding 'use.Rd2' and creation of DESCRIPTION
Dear List,
I ran into the following two problems while using the package 'roxygen':
QUESTION 1
I split the relevant R-Code for my package into the following scripts:
classes.R (S4), functions.R ('standard' functions), generics.R (S4),
methods.R (S4). Function package.skeleton() generates Rd-files for all class
defs, function defs etc. in dir 'pkg/man'. So far, so good. Now, I'd like to
run 'roxygenize()' on dir 'pkg' and face the problem that the argument
'use.Rd2' only works for parts of the Rd-files, no matter how it is
specified. Setting it FALSE works for all non-S4 defs, setting it TRUE works
for all S4-defs ('works' in the sense of ending up with non-empty \title{}
in the Rd-files). However, both types of defs are in 'pkg/man' or 'pkg/R',
respectivley.
I implemented a workaround in which each of the four scripts is addressed
separately by package.skeleton() and roxygenize(). The resulting Rd-files
are stored in temp dirs (e.g. 'pkg/tmp_classes', 'pgk/tmp_functions' etc.)
and are merged to 'pkg/man' at the very end of the process. But I figured
there must be a better or at least more elegant way to do this. Any hints?
I should mention that not all of my defs (be it non-S4 or S4) are already
prepended with roxygen-code (related to this post
http://stackoverflow.com/questions/2316356/can-roxygen-ignore-non-user-funct
ions), yet the workaround creates non-empty \title{} for all Rd-files. Is
this also possible by running package.skelleton() and roxygenize() just
once?
QUESTION 2
Even though I followed the roxygen vignette closely and also had a look at
the webvis package as suggested here
http://stackoverflow.com/questions/3086081/how-do-you-write-your-package-doc
umentation, I still cannot reproduce a DESCRIPTION file that reflects the
specifications I made via the part of the roxygen-code that is related to
stating the package title, author etc. The outcome in the Rd file
'pkg_name-package.Rd' is fine, but the DESCRIPTION file itself still looks
like the dummy created by package.skelleton. Am I doing something wrong
here?
Thanks very much for any suggestions,
Janko
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
From: Uwe Ligges
On 29.08.2010 22:34, Kyle Matoba wrote:
All,
I just finished the process of build a package for the
first time and found
it characteristically (for R) very straightforward and well
documented.
Whenever I deal with open source software I always endeavor
to finish the
task I have in mind, and upon completing this, I then
revisit all of the
configurations, customizing as necessary to achieve my
goals more fully.
The ability to achieve some minimal level of
functionality without the need
for much filling in of configuration files, etc., is, I
feel, important to
not scaring off the less technically inclined such as myself.
Based on this heuristic, it is my understanding that a few
small suggestions
could make building a warning-free package as easy as running
package.skeleton(), then R CMD check, R CMD build:
- Fill in default titles for each of the '*.Rd' files in /man
- Take out the tildes in the 'examples' section of the
'*-package.Rd' main
documentation file for the package (it seems to confuse the
latex compiler)
- Put the lines '~~ Optionally other standard keywords, one
per line, from
file KEYWORDS in ~~
~~ the R documentation directory ~~' into the \references{}
section, there
is presently a warning about all text needing to be in a section.
Dear Kyle,
thanks for the suggestions. Actually, it is intended to generate
warnings / Errors in R CMD check: We want to force package
developers to
document their packages probably. This way, package maintainers /
developers have to touch each Rd file and cannot use them as
is in order
to pass the checks.
Or else it may be possible to have some malicious person write a script
that
automagically generate some large number of bogus packages and submit
them to CRAN...
Andy
Best wishes,
uwe
Thanks, as always, to everyone for their hard work to keep
my statistical
computing free and easy.
Best,
Kyle
[[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
Notice: This e-mail message, together with any attachme...{{dropped:11}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
On Sep 15, 2010, at 17:01 , Liaw, Andy wrote: Or else it may be possible to have some malicious person write a script that automagically generate some large number of bogus packages and submit them to CRAN... Andy Douglas Adams - - There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. -- Peter Dalgaard 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] a small suggestion for improving the building of packages
Uwe,
Yes, this makes good sense. All I am saying is that it is somewhat out of
the open-source, the user is smart and we should not _artificially force_
him or her to jump through some hoop. I do not contend that packages
destined for CRAN should have anything but the fullest documentation
possible: somewhat in the spirit of other open-source projects R should
impose quite stringent requirements for potential contributors, but make it
as easy as possible for someone to play around on their own isolated
projects.
Keep up the good work.
Best,
Kyle
2010/9/15 Uwe Ligges lig...@statistik.tu-dortmund.de
On 29.08.2010 22:34, Kyle Matoba wrote:
All,
I just finished the process of build a package for the first time and
found
it characteristically (for R) very straightforward and well documented.
Whenever I deal with open source software I always endeavor to finish the
task I have in mind, and upon completing this, I then revisit all of the
configurations, customizing as necessary to achieve my goals more fully.
The ability to achieve some minimal level of functionality without the
need
for much filling in of configuration files, etc., is, I feel, important to
not scaring off the less technically inclined such as myself.
Based on this heuristic, it is my understanding that a few small
suggestions
could make building a warning-free package as easy as running
package.skeleton(), then R CMD check, R CMD build:
- Fill in default titles for each of the '*.Rd' files in /man
- Take out the tildes in the 'examples' section of the '*-package.Rd' main
documentation file for the package (it seems to confuse the latex
compiler)
- Put the lines '~~ Optionally other standard keywords, one per line, from
file KEYWORDS in ~~
~~ the R documentation directory ~~' into the \references{} section, there
is presently a warning about all text needing to be in a section.
Dear Kyle,
thanks for the suggestions. Actually, it is intended to generate warnings /
Errors in R CMD check: We want to force package developers to document their
packages probably. This way, package maintainers / developers have to touch
each Rd file and cannot use them as is in order to pass the checks.
Best wishes,
uwe
Thanks, as always, to everyone for their hard work to keep my statistical
computing free and easy.
Best,
Kyle
[[alternative HTML version deleted]]
__
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] a small suggestion for improving the building of packages
On Sep 15, 2010, at 10:14 AM, peter dalgaard wrote: On Sep 15, 2010, at 17:01 , Liaw, Andy wrote: Or else it may be possible to have some malicious person write a script that automagically generate some large number of bogus packages and submit them to CRAN... Andy Douglas Adams - - There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. BTW, that other theory helps to explain some local politicians... ;-) Regards, Marc Schwartz http://www.wolframalpha.com/input/?i=what+is+the+meaning+of+life%3F __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
Yes, well, anyone clever enough to do this will not be stopped by
automatically manipulating some text to fill in the minimal documentation
necessary to pass checks.
On Wed, Sep 15, 2010 at 8:01 AM, Liaw, Andy andy_l...@merck.com wrote:
From: Uwe Ligges
On 29.08.2010 22:34, Kyle Matoba wrote:
All,
I just finished the process of build a package for the
first time and found
it characteristically (for R) very straightforward and well
documented.
Whenever I deal with open source software I always endeavor
to finish the
task I have in mind, and upon completing this, I then
revisit all of the
configurations, customizing as necessary to achieve my
goals more fully.
The ability to achieve some minimal level of
functionality without the need
for much filling in of configuration files, etc., is, I
feel, important to
not scaring off the less technically inclined such as myself.
Based on this heuristic, it is my understanding that a few
small suggestions
could make building a warning-free package as easy as running
package.skeleton(), then R CMD check, R CMD build:
- Fill in default titles for each of the '*.Rd' files in /man
- Take out the tildes in the 'examples' section of the
'*-package.Rd' main
documentation file for the package (it seems to confuse the
latex compiler)
- Put the lines '~~ Optionally other standard keywords, one
per line, from
file KEYWORDS in ~~
~~ the R documentation directory ~~' into the \references{}
section, there
is presently a warning about all text needing to be in a section.
Dear Kyle,
thanks for the suggestions. Actually, it is intended to generate
warnings / Errors in R CMD check: We want to force package
developers to
document their packages probably. This way, package maintainers /
developers have to touch each Rd file and cannot use them as
is in order
to pass the checks.
Or else it may be possible to have some malicious person write a script
that
automagically generate some large number of bogus packages and submit
them to CRAN...
Andy
Best wishes,
uwe
Thanks, as always, to everyone for their hard work to keep
my statistical
computing free and easy.
Best,
Kyle
[[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
Notice: This e-mail message, together with any attach...{{dropped:16}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Add DESCRIPTION 'Date' to R CMD check log header
On 09/15/2010 01:55 AM, Kurt Hornik wrote:
Martin Maechler writes:
Hi Henrik
HB == Henrik Bengtssonh...@stat.berkeley.edu
on Tue, 14 Sep 2010 18:26:31 -0700 writes:
HB Hi,
HB in R CMD check, the version of the package being checked is reported, e.g.
HB Thu Sep 9 05:02:30 2010: Checking package R.utils (SVN revision 399) ...
HB * using log directory ‘/srv/R/R.check/R-devel/PKGS/R.utils.Rcheck’
HB * using R version 2.12.0 Under development (unstable) (2010-09-07 r52876)
HB * using platform: x86_64-unknown-linux-gnu (64-bit)
HB * using session charset: UTF-8
HB * checking for file ‘R.utils/DESCRIPTION’ ... OK
HB * this is package ‘R.utils’ version ‘1.5.2’
HB ...
HB I'd like to request/suggest that the 'Date' in the DESCRIPTION file is
HB also added, e.g.
HB * this is package ‘R.utils’ version ‘1.5.2’ ('2010-09-14')
HB WHY?
HB This would be particular useful when you work toward sites like
HB R-forge and Bioconductor when you may commit your day's work on
HB package when you update the 'Date' but you do not really want to
HB update the 'Version' because you're going to put in more work
HB tomorrow. With the 'Date' information you'll be able to see what
HB version of your updates have been checked by the servers. I
HB understand that this may be an odd process to follow even for devel
HB branches and you may argue that you should always bump the version
HB number whenever you do an SVN commit (e.g. '1.5.2.1' for temporary
HB commits). Either way, I find it useful to see the date as well.
I agree that this is useful.
Of course, for all those cases, where there's no Date:,
nothing (i.e. no ()) should be written.
If you (or someone) provide patches against R-devel
( https://svn.r-project.org/R/trunk/ )
and they pass 'make check-all', I'd add this feature.
But pls not against the Date field by default:
R-Forge packages record their revision in their package metadata.
CRAN packages record Date/Publication in their metadata.
Not sure about BioC ...
For BioC packages, I look at the svn revision number displayed
on the build/check report so I know exactly which version of my
package was built/checked:
http://bioconductor.org/checkResults/2.7/bioc-LATEST/
But I can see Henrik's point to not depend on what a particular
build system does and to have this kind of feature incorporated
in 'R CMD check' itself.
Cheers,
H.
-k
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to manage configuration for openMP support
Thanks a lot, I have implemented the configure stuff and it works perfectly !! Exactly what I was looking for. I just added AC_PREREQ([2.62]) because the AC_OPENMP was only supported from this version, and AC_MSG_WARN([NO OpenMP support detected. You should should use gcc = 4.2 !!!]) when no openmp support was detected. Maybe this could be put into the Writing R Extensions manual. Thanks again, Karl [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Duncan, dear Herve, Thank you both for your help and suggestions. I think that you are both right: In principle I do not want to put these files in the source tarball (and I did not in the past), however because of the way R CMD check works this seems to be the only possibility to get rid of the warning message. I agree that it is weird to get this warning message although these files are not in the source tarball. Since I have a Makefile, as Herve mentions, I can try to remove these files in the clean step, which currently is: clean: rm -f $(MYOBJ) *.a *.d *.rc I will try to change this part but I am not sure if this will solve the problem. Best regards Christian On 9/15/10 1:58 AM, Hervé Pagès wrote: On 09/14/2010 03:30 PM, Duncan Murdoch wrote: On 14/09/2010 6:08 PM, Hervé Pagès wrote: On 09/14/2010 02:58 PM, cstrato wrote: Dear Herve, Thank you for your reply, however maybe I was not quite clear. The files xpsDict.h and xpsDict.cxx are automatically created by the ROOT framework during compilation on every architecture. on every architecture... ok But if they are created during compilation, why do they need to be included in the source tarball? They are just temporary files right? Or I'm missing something... This means they are created on Linux and Mac with LF line endings, but on Windows with CRLF line endings. However, they are created only if they do not already exist, and thus are not in the source tarball. I guess you mean they are not part of the source *tree*. For testing purposes I have just added both files with LF line endings to the source tarball and compiled it on Windows w/o problems. Furthermore, the size of xps_1.9.6.tar.gz increases only from 4MB to 4.3MB. Thus in principle I could upload both files to SVN for BioC 2.7, and this should eliminate the warning message. What is your opinion? I still don't understand why you want to have them in the source tarball. I think he doesn't want to put them in the source tarball, but because of the way R CMD check works, he may have to. It appears that R CMD check builds those files, and then checks for CRLF endings on all files. If it did the CRLF check first, it wouldn't see them and complain. The problem with this change is that some packages might create files with CRLF endings on all platforms, and then check *should* complain about them. I see your point but, on the other hand, and more generally speaking, you expect 'R CMD check' to check the source files i.e. the files that belong to the source tarball, and not temporary compilation/installation products that 'R CMD INSTALL' didn't remove (for whatever reason). It's weird to get a message like: * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/xpsDict.h if there is no such file in the source tarball. My advice would be not to put them in the tarball, and ignore the warning. Or write a Makevars.win that fixes the line endings so that check is happy. Yes and since he already uses a Makefile, it should be easy to remove those files at the end of installation so they don't end up in the tarball anymore. Wouldn't that also be enough to silent 'R CMD check'? Perhaps package authors should really make sure that src/ gets cleaned after the installation step of 'R CMD build' (this step is performed only if the package has vignettes). Then it shouldn't matter whether 'R CMD check' checks for CRLF endings after or before installing the package. Cheers, H. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
On 15 September 2010 at 22:39, cstrato wrote: | Dear Duncan, dear Herve, | | Thank you both for your help and suggestions. I think that you are both | right: | | In principle I do not want to put these files in the source tarball (and | I did not in the past), however because of the way R CMD check works | this seems to be the only possibility to get rid of the warning message. | | I agree that it is weird to get this warning message although these | files are not in the source tarball. | | Since I have a Makefile, as Herve mentions, I can try to remove these If you have a Makefile, then you have implicit rules as well as explicit ones. That is how the file gets created. Now modify the rules and insert another layer which will do the filtering. As the saying goes: there is no problem that cannot be solved by adding another layer of indirection. Instead of requiring the generated file, require the generated and filtered file. | files in the clean step, which currently is: | | clean: | rm -f $(MYOBJ) *.a *.d *.rc | | I will try to change this part but I am not sure if this will solve the | problem. I fear that the clean step runs too late. You want the file filtered at the compile stage. 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
Re: [Rd] Problem with WARNING...headers with CRLF line endings
Dear Dirk,
Thank you for this suggestion, however since I am not very good in
creating Makefiles I would appreciate if you could explain how to filter
at the compile stage.
These are the lines which I think are essential:
xps.dll: $(MYOBJ)
$(LINK) /dll /def:xps.def /out:xps.dll fp10.obj $(SOFLAGS) $(LDFLAGS)
$(GLIBS) *.obj
xpsDict.cxx: $(MYHDR) xpsLinkDef.h
@echo Generating dictionary $...@...
@rootcint -f $@ -c $(MYHDR) xpsLinkDef.h
xpsDict.obj: xpsDict.cxx xpsDict.h
$(CL) /I${ROOTSYS}/include /FIw32pragma.h /MT /EHsc /Ox /D MSVC /D
WIN32 /c xpsDict.cxx
clean:
rm -f $(MYOBJ) *.a *.d *.rc
The line @rootcint creates the xpsLinkDef.h file.
Do I have to add something after the compilation step of xpsDict.obj?
Thank you in advance.
Best regards
Christian
On 9/15/10 10:51 PM, Dirk Eddelbuettel wrote:
On 15 September 2010 at 22:39, cstrato wrote:
| Dear Duncan, dear Herve,
|
| Thank you both for your help and suggestions. I think that you are both
| right:
|
| In principle I do not want to put these files in the source tarball (and
| I did not in the past), however because of the way R CMD check works
| this seems to be the only possibility to get rid of the warning message.
|
| I agree that it is weird to get this warning message although these
| files are not in the source tarball.
|
| Since I have a Makefile, as Herve mentions, I can try to remove these
If you have a Makefile, then you have implicit rules as well as explicit
ones. That is how the file gets created.
Now modify the rules and insert another layer which will do the filtering. As
the saying goes: there is no problem that cannot be solved by adding
another layer of indirection. Instead of requiring the generated file,
require the generated and filtered file.
| files in the clean step, which currently is:
|
| clean:
| rm -f $(MYOBJ) *.a *.d *.rc
|
| I will try to change this part but I am not sure if this will solve the
| problem.
I fear that the clean step runs too late. You want the file filtered at the
compile stage.
Dirk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with WARNING...headers with CRLF line endings
On 09/15/2010 01:51 PM, Dirk Eddelbuettel wrote: On 15 September 2010 at 22:39, cstrato wrote: | Dear Duncan, dear Herve, | | Thank you both for your help and suggestions. I think that you are both | right: | | In principle I do not want to put these files in the source tarball (and | I did not in the past), however because of the way R CMD check works | this seems to be the only possibility to get rid of the warning message. | | I agree that it is weird to get this warning message although these | files are not in the source tarball. | | Since I have a Makefile, as Herve mentions, I can try to remove these If you have a Makefile, then you have implicit rules as well as explicit ones. That is how the file gets created. Now modify the rules and insert another layer which will do the filtering. As the saying goes: there is no problem that cannot be solved by adding another layer of indirection. Instead of requiring the generated file, require the generated and filtered file. | files in the clean step, which currently is: | | clean: | rm -f $(MYOBJ) *.a *.d *.rc | | I will try to change this part but I am not sure if this will solve the | problem. I fear that the clean step runs too late. But shouldn't 'R CMD check' run the clean step (if it runs it at all) right after the 'R CMD INSTALL' step? Cheers, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build cannot create vignettes on Windows if Makefile is used
Oops, sorry for the noise but after looking at today's BioC build/check results, I realize the problem is still here. At least for some of the 8 packages that had an 'R CMD build' timeout because of the Sweave.sty file not being found. I just happened to run 'R CMD build' by hands yesterday on a package for which the problem is gone so I went ahead and started to sing victory... not so fast! I'm gonna post with a new subject and give more details. H. On 09/14/2010 11:48 AM, Duncan Murdoch wrote: On 14/09/2010 2:46 PM, Hervé Pagès wrote: Duncan, On 09/13/2010 11:47 AM, Duncan Murdoch wrote: On 13/09/2010 2:38 PM, Hervé Pagès wrote: [...] Thanks for suggesting workarounds but don't you think there is a real problem? As I said, we don't use TEXINPUTS on Windows, we use the command line version. I didn't write the code, so I don't know why there's the difference, but I assume there's a reason for it, and presumably the reason is that relying on TEXINPUTS doesn't work. This is fixed in current R-devel. That explains my confusion. Duncan Murdoch -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] running 'make' failed during vignette creation ('R CMD build') on Windows
Hi,
This is a follow-up to the problem reported here:
https://stat.ethz.ch/pipermail/r-devel/2010-September/058460.html
After I updated R-2.12 to 2010-09-13 r52905 on the Bioc build system,
some of the packages that have a Makefile in pkg/inst/doc still
don't build on Windows. For example, 'R\bin\R.exe CMD build adSplit'
gives:
* checking for file 'adSplit/DESCRIPTION' ... OK
* preparing 'adSplit':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to re-build vignettes
* creating vignettes ... ERROR
Loading required package: Biobase
Welcome to Bioconductor
Vignettes contain introductory material. To view, type
'openVignette()'. To cite Bioconductor, see
'citation(Biobase)' and for packages 'citation(pkgname)'.
Loading required package: DBI
Loading required package: hu6800.db
Loading required package: AnnotationDbi
Loading required package: org.Hs.eg.db
determining 1000 random DLD-scores with 20 probe sets each (wait for
10 dots)
..
epstopdf splitSet.eps
pdflatex tr_2005_02
This is pdfTeX, Version 3.1415926-1.40.9 (MiKTeX 2.7)
entering extended mode
(tr_2005_02.tex
LaTeX2e 2009/09/24
Babel v3.8l and hyphenation patterns for english, dumylang,
nohyphenation, ge
rman, ngerman, french, loaded.
(C:\Program Files\MiKTeX 2.7\tex\latex\base\report.cls
Document Class: report 2007/10/19 v1.4h Standard LaTeX document class
(C:\Program Files\MiKTeX 2.7\tex\latex\base\size11.clo)) (compdiag.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\ifpdf.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\graphics\graphicx.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\graphics\keyval.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\graphics\graphics.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\graphics\trig.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\00miktex\graphics.cfg)
(C:\Program Files\MiKTeX 2.7\tex\latex\pdftex-def\pdftex.def)))
(C:\Program Files\MiKTeX 2.7\tex\latex\graphics\color.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\00miktex\color.cfg))
(C:\Program Files\MiKTeX 2.7\tex\latex\hyperref\hyperref.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\ltxcmds.sty)
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\kvsetkeys.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\infwarerr.sty)
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\etexcmds.sty))
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\pdfescape.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\pdftexcmds.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\ifluatex.sty)))
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\ifvtex.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\ifxetex\ifxetex.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\oberdiek\hycolor.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\oberdiek\xcolor-patch.sty))
(C:\Program Files\MiKTeX 2.7\tex\latex\oberdiek\letltxmacro.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\hyperref\pd1enc.def)
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\intcalc.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\00miktex\hyperref.cfg)
(C:\Program Files\MiKTeX 2.7\tex\latex\oberdiek\kvoptions.sty)
Implicit mode ON; LaTeX internals redefined
(C:\Program Files\MiKTeX 2.7\tex\latex\ltxmisc\url.sty)
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\bitset.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\bigintcalc.sty))
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\atbegshi.sty))
* hyperref using driver hpdftex *
(C:\Program Files\MiKTeX 2.7\tex\latex\hyperref\hpdftex.def
(C:\Program Files\MiKTeX 2.7\tex\latex\oberdiek\atveryend.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\oberdiek\rerunfilecheck.sty
(C:\Program Files\MiKTeX 2.7\tex\generic\oberdiek\uniquecounter.sty)))
(C:\Program Files\MiKTeX 2.7\tex\latex\ntgclass\a4.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\geometry\geometry.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\geometry\geometry.cfg))
(C:\Program Files\MiKTeX 2.7\tex\latex\tools\theorem.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\tools\thp.sty))
(C:\Program Files\MiKTeX 2.7\tex\latex\tools\thb.sty))
(C:\Program Files\MiKTeX 2.7\tex\latex\ams\math\amsmath.sty
For additional information on amsmath, use the `?' option.
(C:\Program Files\MiKTeX 2.7\tex\latex\ams\math\amstext.sty
(C:\Program Files\MiKTeX 2.7\tex\latex\ams\math\amsgen.sty))
(C:\Program Files\MiKTeX 2.7\tex\latex\ams\math\amsbsy.sty)
(C:\Program Files\MiKTeX 2.7\tex\latex\ams\math\amsopn.sty))
! LaTeX Error: File `Sweave.sty' not found.
Type X to quit or RETURN to proceed,
or enter new name. (Default extension: sty)
Enter file name:
! Emergency stop.
read *
l.39 \begin
{document}
! == Fatal error occurred, no output PDF file produced!
Transcript written on tr_2005_02.log.
make: *** [pdf] Error 1
Error in tools::buildVignettes(dir = .) : running 'make' failed
Execution halted
What's different though with this updated R, it that now I get an
error instead of a timeout. Maybe the code that fires the R subprocess
in charge of running tools::buildVignettes() now does better
Re: [Rd] More strange R CMD build/check errors on Windows
On 09/14/2010 11:23 AM, Hervé Pagès wrote: Hi Uwe, On 09/14/2010 04:49 AM, Uwe Ligges wrote: ... Brian had some ideas that the problems are related to the shell that is used. Is the problem still apparent in a very recent R-devel from few days ago? I am just back from vacations and have not updated yet. I experienced the same problems and I am just iterating automatically if typical problems are apparent from the log files. I hope some if not all parts are solved now and will do some new test runs shortly. Sounds good. I just upgraded to R-2.12 (2010-09-13 r52905) on our 32-bit Windows machine and I'll report here tomorrow after the next build run has completed. I can already see that this new R solves the issue I reported here: https://stat.ethz.ch/pipermail/r-devel/2010-September/058460.html Not true sorry (https://stat.ethz.ch/pipermail/r-devel/2010-September/058530.html) As for the strange R CMD build/check errors on Windows I still see them. A sample of Today's Victims: R\bin\R.exe CMD build AffyCompatible * checking for file 'AffyCompatible/DESCRIPTION' ... OK * preparing 'AffyCompatible': * checking DESCRIPTION meta-information ... OK * installing the package to re-build vignettes * creating vignettes ... ERROR Error: ERROR: no packages specified R\bin\R.exe CMD build ArrayTools * checking for file 'ArrayTools/DESCRIPTION' ... OK * preparing 'ArrayTools': * checking DESCRIPTION meta-information ... OK * installing the package to re-build vignettes --- Warning: unknown option '-l' * checking for file 'E:\biocbld\bbs-2.7-bioc\tmpdir\Rtmpbtur24\Rinst494950ff/DESCRIPTION' ... NO --- ERROR: Installation failed Removing installation dir R\bin\R.exe CMD build baySeq * checking for file 'baySeq/DESCRIPTION' ... OK * preparing 'baySeq': * checking DESCRIPTION meta-information ... OK * installing the package to re-build vignettes * creating vignettes ...Warning in file(con, r) : cannot open file 'E:\biocbld\bbs-2.7-bioc\tmpdir\RtmpKRrdst\xshell4d4a5c70': Permission denied Error in file(con, r) : cannot open the connection Execution halted R\bin\R.exe CMD build beadarray -- produces no output at all and returns code 0. etc... Cheers, H. Thanks! H. Best, Uwe Thanks, H. Antivirus software? I suspect you already ruled that out, but it has been the culprit for problems with mysteriously disappearing intermediate files in several cases, so I thought I'd mention it. Actually I didn't try that yet because we still build BioC release (using R-2.11.1) on these 2 Windows boxes and we don't see any of those problems for the release builds. But I will. Could it be that the fact that 'R CMD build' and 'R CMD check' are R-based in R-2.12 (and not Perl-based anymore) make them more fragile when something like an antivirus is messing around with the filesystem? Thanks for the suggestion, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-forge: Web server down / no space left
FYI and for the R-forge maintainers information: Trying to access http://r-forge.r-project.org/ at this very moment gives: An error occured in the logger. ERROR: could not extend relation 1663/19060/19983: No space left on device HINT: Check free disk space. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-forge: Web server down / no space left
I tried it now and it works. It might have been something momentary. Original message Date: Wed, 15 Sep 2010 19:14:37 -0700 From: r-devel-boun...@r-project.org (on behalf of Henrik Bengtsson h...@stat.berkeley.edu) Subject: [Rd] R-forge: Web server down / no space left To: R-devel r-devel@r-project.org FYI and for the R-forge maintainers information: Trying to access http://r-forge.r-project.org/ at this very moment gives: An error occured in the logger. ERROR: could not extend relation 1663/19060/19983: No space left on device HINT: Check free disk space. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dario Strbenac Research Assistant Cancer Epigenetics Garvan Institute of Medical Research Darlinghurst NSW 2010 Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Lack of consistent cross-platform behaviour of tools:::buildVignettes()
Hi,
On both Unix and Windows there is a mechanism to add variables
to the environment when R is started. I noticed that, on Unix,
this mechanism is not used when R is started normally at the
command line but only when it's started using the 'R CMD' syntax.
One problem with this is some lack of consistent cross-platform
behaviour. For example:
On Linux:
$ echo $TEXINPUTS
$ echo Sys.getenv('TEXINPUTS') | R --slave
TEXINPUTS
But on Windows:
E:\tmpecho %TEXINPUTS%
%TEXINPUTS%
E:\tmpecho Sys.getenv(TEXINPUTS) | R\bin\R.exe --slave
TEXINPUTS
.;;E:/biocbld/bbs-2.7-bioc/R/share/texmf/tex/latex;
So on Linux if I cd to the inst/doc folder of a package source tree
that has a Makefile and run
echo tools:::buildVignettes('pkgname', '.') | R --slave
it fails with error:
! LaTeX Error: File `Sweave.sty' not found.
while doing the same thing on Windows works.
Is there any reason for not setting the environments variables
that are defined in ${R_HOME}/bin/Rcmd (the shell script wrapper
for all R CMD commands) when R is started normally?
Thanks,
H.
BTW, I found this (on both, Unix and Windows):
$ echo Sys.getenv('TEXINPUTS') | R
Fatal error: you must specify '--save', '--no-save' or '--vanilla'
What about --slave? Thanks!
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
