Re: [Rd] vignette("introduction") causes "Error in sprintf(" (PR#9069)
> On Sun, 09 Jul 2006 19:21:25 +0100,
> Chris Evans (CE) wrote:
> Gabor Grothendieck sent the following at 09/07/2006 19:02:
>> Same for me. Looking through the output of vignette
>> I noticed that both the ggplot and reshape packages have
>> a vignette called "introduction" in my case and either of
>> the following brings up the associated vignette (as opposed
>> to the error message):
>>
>> vignette("introduction", "ggplot")
>> vignette("introduction", "reshape")
> Aha, works for me too. Sorry, I probably should have been able to work
> that out myself.
> So: not so much a bug, more a wish as it might be good if the vignette
> code checked for multiple vignettes with the same name and returned a
> choice or a message warning you that there are multiples.
A simple traceback shows that the bug was actually in code trying
to do exactly what you suggest ;-)
R> vignette("introduction")
Error in sprintf(gettext(fmt, domain = domain), ...) :
use format %s for character objects
R> traceback()
4: sprintf(gettext(fmt, domain = domain), ...)
3: gettextf("vignette '%d' found more than once,\nusing the one found in '%s'",
topic, dirname(pdf[idx]))
2: warning(gettextf("vignette '%d' found more than once,\nusing the one found
in '%s'",
topic, dirname(pdf[idx])), call. = FALSE, domain = NA)
1: vignette("introduction")
Fixed now in both r-patched and r-devel.
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] validObject() -> slow down ?! [was "package:Matrix handling ..."]
[Diverted from R-help to R-devel]
> "roger" == roger koenker <[EMAIL PROTECTED]>
> on Sun, 9 Jul 2006 12:31:16 -0500 writes:
>>
roger> On 7/8/06, Thaden, John J <[EMAIL PROTECTED]>
roger> wrote:
>> As there is nothing inherent in either compressed,
>> sparse, format that would prevent recognition and
>> handling of duplicated index pairs, I'm curious why the
>> dgCMatrix class doesn't also add x values in those
>> instances?
roger> why not multiply them? or take the larger one, or
roger> ...? I would interpret this as a case of user
roger> negligence -- there is no "natural" default behavior
roger> for such cases.
roger> On Jul 9, 2006, at 11:06 AM, Douglas Bates wrote:
>> Your matrix Mc should be flagged as invalid. Martin and
>> I should discuss whether we want to add such a test to
>> the validity method. It is not difficult to add the test
>> but there will be a penalty in that it will slow down all
>> operations on such matrices
hmm, maybe "all operations" is slightly pessimistic.
The issue seems to be *when* (under what exact circumstances)
the 'validity' method for a class will be called, i.e., when the
equivalent of validObject() should be called automatically.
We (those from R-core present) discussed this question a
bit last summer in Seattle, and we had a proposal by Robert Gentleman,
that this should both be better defined and documented and also
slightly changed -- such that validObject() is called less
frequently.
IIRC, one consequence of that is the 'complete = FALSE' default
that validObject() has got in the mean time. But I don't know
about the other issue, of ensuring (or not) that validObject()
is not called too often.
I wonder if we should consider a new optional argument to
new(..) [ well actuallly, initialize() ] :
the default new(., .check.validity = TRUE)
would call {the equivalent of} validObject() after object
creation, but one could always explicitly use
new(., .check.validity = FALSE)
for fast "but dangerous" objet creation.
>> and I'm not sure if we want to pay that price to catch a
>> rather infrequently occuring problem.
roger> Elaborating the validity procedure to flag such
roger> instances seems to be well worth the speed penalty in
roger> my view. Of course, anticipating every such misstep
roger> imposes a heavy burden on developers and constitutes
roger> the real "cost" of more elaborate validity checking.
At the moment I tend to agree with Roger that we (Matrix
authors) should try to add more stringent testing even at some
cost --- particularly if that penalty would only occur at object
creation time. One important "use case" of our sparse matrices
of course are lmer() calls. They shouldn't become slower noticably.
roger> [My 2cents based on experience with SparseM.]
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected difference in Bounding Box of PDF graphics between (PR#9072)
[EMAIL PROTECTED] wrote:
> Full_Name: Wolfgang Huber
> Version: R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
> OS: i686-pc-linux-gnu
> Submission from: (NULL) (62.253.128.15)
>
>
> There appears to be unintentional behaviour in the size of the bounding box
> for
> PDF graphics produced with the current R2.4, compared to 2.3.1. I posted two
> PDF
> files, both produced with the same R script below, but different versions of
> R:
> http://www.ebi.ac.uk/~huber/pub
>
> The code is here:
>
>
> pdf(file=sprintf("test-%s.pdf", version$"svn rev"), width=4, height=4)
> par(mai=par("mai")[rep(1:2,2)])
> x = seq(0, 10*pi, length=3000)
> plot(x*cbind(sin(x),cos(x)), type="l", col="mistyrose", lwd=3)
>
> sink(textConnection("s", "w"))
> options(width=40)
> print(sessionInfo(), width=30)
> sink()
>
> text(-30, 30-4*seq(along=s), s, adj=c(0,0.5), cex=0.7)
> dev.off()
>
>
>
> and one of the differences between the resulting PDF files is:
> test-38323.pdf: /MediaBox [0 0 288 288]
> test-38523.pdf: /MediaBox [0 0 595 841]
>
> The former corresponds to 4x4 inches, the latter to 21cm x 29.67cm.
[0 0 595 842] is A4 size. Probably a default taken from something.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected difference in Bounding Box of PDF graphics between 2.3.1p and 2.4 (PR#9070)
[EMAIL PROTECTED] wrote:
> Full_Name: Wolfgang Huber
> Version: R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
> OS: i686-pc-linux-gnu
> Submission from: (NULL) (62.253.128.15)
>
>
> There appears to be unintentional behaviour in the size of the bounding box
> for
> PDF graphics produced with the current R2.4, compared to 2.3.1. I posted two
> PDF
> files, both produced with the same R script below, but different versions of
> R:
> http://www.ebi.ac.uk/~huber/pub
>
> The code is here:
>
>
> pdf(file=sprintf("test-%s.pdf", version$"svn rev"), width=4, height=4)
> par(mai=par("mai")[rep(1:2,2)])
> x = seq(0, 10*pi, length=3000)
> plot(x*cbind(sin(x),cos(x)), type="l", col="mistyrose", lwd=3)
>
> sink(textConnection("s", "w"))
> options(width=40)
> print(sessionInfo(), width=30)
> sink()
>
> text(-30, 30-4*seq(along=s), s, adj=c(0,0.5), cex=0.7)
> dev.off()
>
>
>
> and one of the differences between the resulting PDF files is:
> test-38323.pdf: /MediaBox [0 0 288 288]
> test-38523.pdf: /MediaBox [0 0 595 841]
>
> The former corresponds to 4x4 inches, the latter to 21cm x 29.67cm.
[0 0 595 842] is A4 size. Probably a default taken from something.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected difference in Bounding Box of PDF graphics between 2.3.1p and 2.4 (PR#9070)
This is already fixed.
There is no such thing as '2.4', nor does PDF have a bounding box!
The issue was that for a short while the paper size of pdf() was
defaulting to "default", the same as postscript() (and this was
intentional). It is now the previous default of "special", and setting
paper="special" always worked.
On Mon, 10 Jul 2006, Hin-Tak Leung wrote:
> [EMAIL PROTECTED] wrote:
>> Full_Name: Wolfgang Huber
>> Version: R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
>> OS: i686-pc-linux-gnu
>> Submission from: (NULL) (62.253.128.15)
>>
>>
>> There appears to be unintentional behaviour in the size of the bounding box
>> for
>> PDF graphics produced with the current R2.4, compared to 2.3.1. I posted two
>> PDF
>> files, both produced with the same R script below, but different versions of
>> R:
>> http://www.ebi.ac.uk/~huber/pub
>>
>> The code is here:
>>
>>
>> pdf(file=sprintf("test-%s.pdf", version$"svn rev"), width=4, height=4)
>> par(mai=par("mai")[rep(1:2,2)])
>> x = seq(0, 10*pi, length=3000)
>> plot(x*cbind(sin(x),cos(x)), type="l", col="mistyrose", lwd=3)
>>
>> sink(textConnection("s", "w"))
>> options(width=40)
>> print(sessionInfo(), width=30)
>> sink()
>>
>> text(-30, 30-4*seq(along=s), s, adj=c(0,0.5), cex=0.7)
>> dev.off()
>>
>>
>>
>> and one of the differences between the resulting PDF files is:
>> test-38323.pdf: /MediaBox [0 0 288 288]
>> test-38523.pdf: /MediaBox [0 0 595 841]
>>
>> The former corresponds to 4x4 inches, the latter to 21cm x 29.67cm.
>
> [0 0 595 842] is A4 size. Probably a default taken from something.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected difference in Bounding Box of PDF graphics between (PR#9072)
Please take great care not to start a new bug report when commenting on an
old one, as you have done here. It really makes a mess of the records on
the repository. (Ensure that the PR# item appears on the first line.)
We do suggest quite strongly that people do not send reports on
R-devel to R-bugs, as it is often `under development' as here. If you
want to comment on R-devel, do make sure you are using the
up-to-the-minute version, and use the R-devel list.
On Mon, 10 Jul 2006, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>> Full_Name: Wolfgang Huber
>> Version: R version 2.4.0 Under development (unstable) (2006-07-09 r38523)
>> OS: i686-pc-linux-gnu
>> Submission from: (NULL) (62.253.128.15)
>>
>>
>> There appears to be unintentional behaviour in the size of the bounding box
>> for
>> PDF graphics produced with the current R2.4, compared to 2.3.1. I posted two
>> PDF
>> files, both produced with the same R script below, but different versions of
>> R:
>> http://www.ebi.ac.uk/~huber/pub
>>
>> The code is here:
>>
>>
>> pdf(file=sprintf("test-%s.pdf", version$"svn rev"), width=4, height=4)
>> par(mai=par("mai")[rep(1:2,2)])
>> x = seq(0, 10*pi, length=3000)
>> plot(x*cbind(sin(x),cos(x)), type="l", col="mistyrose", lwd=3)
>>
>> sink(textConnection("s", "w"))
>> options(width=40)
>> print(sessionInfo(), width=30)
>> sink()
>>
>> text(-30, 30-4*seq(along=s), s, adj=c(0,0.5), cex=0.7)
>> dev.off()
>>
>>
>>
>> and one of the differences between the resulting PDF files is:
>> test-38323.pdf: /MediaBox [0 0 288 288]
>> test-38523.pdf: /MediaBox [0 0 595 841]
>>
>> The former corresponds to 4x4 inches, the latter to 21cm x 29.67cm.
>
> [0 0 595 842] is A4 size. Probably a default taken from something.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] validObject() -> slow down ?! [was "package:Matrix handling ..."]
If you want to avoid checking your objects for validity, create them as
default objects and then set the slots.
validObject is only called if new() gets optional arguments.
and it's not called when a slot is assigned (because in some cases an
invalid intermediate object will exist, between two slot assignments).
> setClass("foo", representation(x="numeric"))
> trace(validObject)
> xx = new("foo", x=pi)
trace: validObject(.Object)
> x = new("foo")
> [EMAIL PROTECTED] = pi
> ## no call to validObject
Martin Maechler wrote:
>[Diverted from R-help to R-devel]
>
>
>
>>"roger" == roger koenker <[EMAIL PROTECTED]>
>>on Sun, 9 Jul 2006 12:31:16 -0500 writes:
>>
>>
>
>>>
>roger> On 7/8/06, Thaden, John J <[EMAIL PROTECTED]>
>roger> wrote:
>
>>> As there is nothing inherent in either compressed,
>>> sparse, format that would prevent recognition and
>>> handling of duplicated index pairs, I'm curious why the
>>> dgCMatrix class doesn't also add x values in those
>>> instances?
>
>roger> why not multiply them? or take the larger one, or
>roger> ...? I would interpret this as a case of user
>roger> negligence -- there is no "natural" default behavior
>roger> for such cases.
>
>roger> On Jul 9, 2006, at 11:06 AM, Douglas Bates wrote:
>
>>> Your matrix Mc should be flagged as invalid. Martin and
>>> I should discuss whether we want to add such a test to
>>> the validity method. It is not difficult to add the test
>>> but there will be a penalty in that it will slow down all
>>> operations on such matrices
>
>hmm, maybe "all operations" is slightly pessimistic.
>The issue seems to be *when* (under what exact circumstances)
>the 'validity' method for a class will be called, i.e., when the
>equivalent of validObject() should be called automatically.
>
>We (those from R-core present) discussed this question a
>bit last summer in Seattle, and we had a proposal by Robert Gentleman,
>that this should both be better defined and documented and also
>slightly changed -- such that validObject() is called less
>frequently.
>
>IIRC, one consequence of that is the 'complete = FALSE' default
>that validObject() has got in the mean time. But I don't know
>about the other issue, of ensuring (or not) that validObject()
>is not called too often.
>
>I wonder if we should consider a new optional argument to
>new(..) [ well actuallly, initialize() ] :
>
>the default new(., .check.validity = TRUE)
>would call {the equivalent of} validObject() after object
>creation, but one could always explicitly use
> new(., .check.validity = FALSE)
>for fast "but dangerous" objet creation.
>
>>> and I'm not sure if we want to pay that price to catch a
>>> rather infrequently occuring problem.
>
>roger> Elaborating the validity procedure to flag such
>roger> instances seems to be well worth the speed penalty in
>roger> my view. Of course, anticipating every such misstep
>roger> imposes a heavy burden on developers and constitutes
>roger> the real "cost" of more elaborate validity checking.
>
>At the moment I tend to agree with Roger that we (Matrix
>authors) should try to add more stringent testing even at some
>cost --- particularly if that penalty would only occur at object
>creation time. One important "use case" of our sparse matrices
>of course are lmer() calls. They shouldn't become slower noticably.
>
>roger> [My 2cents based on experience with SparseM.]
>
>Martin
>
>__
>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] Unexpected difference in Bounding Box of PDF graphics between 2.3.1p and 2.4 (PR#9070)
Dear Prof Ripley, > There is no such thing as '2.4', Can we forward this information to the author of "sessionInfo()", "version", and R's welcome message, this is where I took that from. nor does PDF have a bounding box! Yup, sorry for my imprecise language, I don't understand much of PDF, just noted the different appearance of the plots. Thanks for the quick fix (and all the other contributions), this really helps. Best wishes Wolfgang Huber -- Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected difference in Bounding Box of PDF graphics between 2.3.1p and 2.4 (PR#9070)
On Mon, 10 Jul 2006, Wolfgang Huber wrote: > Dear Prof Ripley, > >> There is no such thing as '2.4', > > Can we forward this information to the author of "sessionInfo()", > "version", and R's welcome message, this is where I took that from. I get R version 2.4.0 Under development (unstable) (2006-07-09 r38523) ^^^ and the R posting guide makes the same point: it is 2.3.0, not 2.3. > nor does PDF have a bounding box! > > Yup, sorry for my imprecise language, I don't understand much of PDF, > just noted the different appearance of the plots. > > Thanks for the quick fix (and all the other contributions), this really > helps. > > Best wishes > Wolfgang Huber > > -- > Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette("introduction") causes "Error in sprintf(" (PR#9069)
Friedrich Leisch sent the following at 10/07/2006 11:28: ... some snipped ... > Fixed now in both r-patched and r-devel. > > Fritz > Wow, wonderful, thanks. My first ever R bug report resolved and closed in a weekend. Stunning. C -- Chris Evans <[EMAIL PROTECTED]> Professor of Psychotherapy, Nottingham University; Consultant Psychiatrist in Psychotherapy, Rampton Hospital; Research Programmes Director, Nottinghamshire NHS Trust; Hon. SL Institute of Psychiatry, Hon. Con., Tavistock & Portman Trust **If I am writing from one of those roles, it will be clear. Otherwise** **my views are my own and not representative of those institutions** __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Add .git to SCM excludes for build and INSTALL scripts
Git is a source code management system like CVS, svn, arch, and
others.
It would be nice to add exclude support to R CMD build and INSTALL so
that the .git subdir of an R package is handled appropriately.
Here is a possible patch:
diff --git a/src/scripts/INSTALL.in b/src/scripts/INSTALL.in
index 75da9db..09e5ab5 100644
--- a/src/scripts/INSTALL.in
+++ b/src/scripts/INSTALL.in
@@ -863,7 +863,7 @@ do_install_source () {
## When installing from a source directory under version control, we
## should really exclude the subdirs CVS, .svn (Subversion) and
## .arch-ids (arch).
- for d in CVS .svn .arch-ids; do
+ for d in CVS .svn .arch-ids .git; do
find "${R_PACKAGE_DIR}" -name ${d} -type d -prune \
-exec rm -rf \{\} \; 2>/dev/null
done
diff --git a/src/scripts/build.in b/src/scripts/build.in
index 15c9e0c..ee880d9 100755
--- a/src/scripts/build.in
+++ b/src/scripts/build.in
@@ -181,6 +181,7 @@ foreach my $pkg (@ARGV) {
print EXCLUDE "$File::Find::name\n" if(-d $_ && /^CVS$/);
print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.svn$/);
print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.arch-ids$/);
+ print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.git$/);
## Windows DLL resource file
push(@exclude_patterns, "^src/" . $pkgname . "_res\\.rc");
my $filename = $File::Find::name;
--
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
