[Rd] DESCRIPTION: Imports: assertion of version?
Hi, from 'Writing R Extensions' [R version 2.11.0 Under development (unstable) (2010-03-16 r51290)] one can read: The optional `Imports' field lists packages whose name spaces are imported from but which do not need to be attached. [...] Versions can be specified, but will not be checked when the namespace is loaded. Is it a design decision that version specifications are not asserted for packages under Imports:, or is it a lack of implementation? If a design decision, under what use cases do you want to specify the version but not validating it? Is it simply because there is no mechanism for tracking the origin/package of the code importing the other package, and hence we cannot know which DESCRIPTION file to check against? Thanks Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with parse(text=quote(name))
This comes from bolting on srcrefs: as.character() was used for srcrefs, but *not* for coercion (as documented), and quote(myName) was coerced to NULL. The simplest way out is to use text - as.character(text) early on. Maybe coerceVector should handle symbols, though. On Fri, 12 Mar 2010, William Dunlap wrote: Calling parse(text=quote(name)) or text=as.name(name) makes parse() prompt for input from the command line and then it returns a parse of the initial characters of 'name' (depending on how many characters were typed at the prompt). E.g., parse(text=quote(myName)) ?1/3 expression(myN) attr(,srcfile) text parse(text=quote(myName)) ?1/34 expression(myNa) attr(,srcfile) text parse(text=quote(myName)) ?1/345 expression(myNam) attr(,srcfile) text where the ? lines are where parse prompted for input and I typed a valid R expression. I ran into this when starting to convert code that used a deparse/parse cycle to avoid the cycle by storing the expressions themselves and I hadn't yet taken out one of the calls to parse(text=myText). I see it in 2.10.1 and R version 2.11.0 Under development (unstable) (2010-03-07 r51225). Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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
[Rd] Crash of latticeExtra graph with Adobe Acro Pro/Reader/Windows/ during print only (display ok).
I created a report with Sweave today, that displayed perfectly on screen,
but crashed both Adobe Pro 9.3.1 and Adobe Reader 9.0 on Windows 7. Output
with Foxit Reader was flawless.
I was able to reproduce a minimal example, which is not really minimal but
the smallest I could get after 2 hours of wasting paper.
Required:
latticeExtra calling both
panel.xyplot(...) # both lines are required, no problem with only one
of them
panel.smoother(...) #
pch = 16 (lower number were no problem)
At least 300 data points with some overlap; I did bracket it exactly, but
200 did not show the problem. I was not able to generate a runif-based
example, therefore a simplified data set from my original report is
included.
Reproduce: Run the example. sessionInfo see below. Open the created pdf with
Adobe Acrobat Pro/Reader. It displays perfectly.
Print it to any device; I used the virtual Windows XPS printer because after
30 pages I was running out of laser printer toner.
Adobe Displays: Flattening, and hangs after 94%; must be force-restarted
after that.
When using more data points, it hangs after a lower percentage; looks like
flattening has to do with processing of data points, and 300 is just above
the limit.
My workaround is to use something else than pch=16, because I cannot force
customers to install Foxit.
The created pdf file can be downloaded from
http://www.menne-biomed.de/uni/crashedadobe.pdf
Dieter Menne
library(latticeExtra)
d = structure(list(y = c(1, 2, 0, 3, 2, 1, 2, 2, 1, 0, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 1, 2, 1, 2, 1, 0, 2, 2, 2, 2, 2, 1, 1, 2,
2, 3, 0, 2, 3, 1, 2, 2, 2, 2, 1, 0, 2, 1, 2, 4, 2, 1, 1, 0, 0,
1, 2, 2, 3, 1, 1, 2, 2, 2, 2, 1, 2, 0, 2, 0, 2, 2, 1, 1, 1, 1,
2, 1, 8, 2, 5, 3, 2, 2, 0, 1, 0, 2, 0, 2, 0, 2, 4, 2, 2, 2, 2,
2, 1, 2, 5, 1, 1, 2, 0, 1, 2, 2, 2, 2, 1, 2, 2, 0, 1, 2, 0, 2,
2, 2, 2, 1, 0, 2, 0, 1, 2, 1, 2, 2, 0, 0, 2, 2, 2, 3, 2, 2, 2,
2, 2, 1, 2, 1, 2, 2, 2, 2, 2), x = c(1, 2, 3, 13, 1, 14, 14,
4, 4, 0, 1, 1, 4, 2, 5, 3, 4, 13, 2, 5, 12, 1, 4, 0, 1, 2, 0,
2, 5, 2, 3, 3, 3, 1, 5, 4, 5, 0, 4, 2, 5, 4, 12, 3, 3, 5, 0,
3, 4, 4, 14, 5, 2, 1, 0, 0, 1, 3, 4, 2, 14, 1, 2, 2, 12, 1, 3,
4, 0, 5, 2, 5, 2, 2, 3, 5, 5, 2, 5, 13, 2, 4, 12, 2, 4, 1, 4,
0, 1, 0, 1, 0, 4, 5, 4, 5, 2, 2, 13, 3, 4, 13, 1, 12, 3, 1, 0,
2, 5, 3, 14, 4, 2, 2, 0, 0, 4, 0, 2, 12, 13, 3, 2, 1, 4, 2, 3,
1, 1, 3, 3, 0, 0, 3, 5, 3, 13, 3, 13, 3, 13, 3, 1, 1, 4, 2, 1,
4, 12, 5)), .Names = c(y, x),
row.names = c(NA, -150L), class = data.frame)
pdf(crashedadobe.pdf)
p2 = xyplot(y~x,data=d,
pch=16, # required, no problem with pch=1,2,8
panel = function(...) {
panel.xyplot(...) # both lines are required
panel.smoother(...) #
},
)
print(p2)
dev.off()
#R version 2.10.1 (2009-12-14)
#i386-pc-mingw32
#
#locale:
#[1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252
#[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
#[5] LC_TIME=German_Germany.1252
#
#attached base packages:
#[1] stats graphics grDevices datasets utils methods base
#
#loaded via a namespace (and not attached):
#[1] tools_2.10.1
#
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash of latticeExtra graph with Adobe Acro Pro/Reader/Windows/ during print only (display ok).
Flattening usually has to do with converting transparent stuff when
you convert from a format that supports it (pdf) to something like
postscript. At least that is the technical term used in Adobe
Illustrator.
This may be related to the fact the Adobe Illustrator from CS4 creates
bad postscript files from PDF/ai files containing transparency (at
least when they are created using R). I don't think this is a problem
at all with R, rather it seems to be an illustrator problem (which I
think is a pretty amazing bug). What I do with postscript files
produced with Illustrator is to post process them using the following
perl script:
http://tomas.rokicki.com/illbug/fixill.pl
So my workflow is something like
make pdf from R
process the pdf using Illustrator, saving it as eps
./fixill.pl bad.eps good.eps
Come to think of it, all files where I have experience this have had
1000+ points on them.
Kasper
On Fri, Mar 19, 2010 at 3:26 PM, Dieter Menne
dieter.me...@menne-biomed.de wrote:
I created a report with Sweave today, that displayed perfectly on screen,
but crashed both Adobe Pro 9.3.1 and Adobe Reader 9.0 on Windows 7. Output
with Foxit Reader was flawless.
I was able to reproduce a minimal example, which is not really minimal but
the smallest I could get after 2 hours of wasting paper.
Required:
latticeExtra calling both
panel.xyplot(...) # both lines are required, no problem with only one
of them
panel.smoother(...) #
pch = 16 (lower number were no problem)
At least 300 data points with some overlap; I did bracket it exactly, but
200 did not show the problem. I was not able to generate a runif-based
example, therefore a simplified data set from my original report is
included.
Reproduce: Run the example. sessionInfo see below. Open the created pdf with
Adobe Acrobat Pro/Reader. It displays perfectly.
Print it to any device; I used the virtual Windows XPS printer because after
30 pages I was running out of laser printer toner.
Adobe Displays: Flattening, and hangs after 94%; must be force-restarted
after that.
When using more data points, it hangs after a lower percentage; looks like
flattening has to do with processing of data points, and 300 is just above
the limit.
My workaround is to use something else than pch=16, because I cannot force
customers to install Foxit.
The created pdf file can be downloaded from
http://www.menne-biomed.de/uni/crashedadobe.pdf
Dieter Menne
library(latticeExtra)
d = structure(list(y = c(1, 2, 0, 3, 2, 1, 2, 2, 1, 0, 1, 1, 1, 1,
2, 2, 2, 2, 2, 2, 2, 1, 2, 1, 2, 1, 0, 2, 2, 2, 2, 2, 1, 1, 2,
2, 3, 0, 2, 3, 1, 2, 2, 2, 2, 1, 0, 2, 1, 2, 4, 2, 1, 1, 0, 0,
1, 2, 2, 3, 1, 1, 2, 2, 2, 2, 1, 2, 0, 2, 0, 2, 2, 1, 1, 1, 1,
2, 1, 8, 2, 5, 3, 2, 2, 0, 1, 0, 2, 0, 2, 0, 2, 4, 2, 2, 2, 2,
2, 1, 2, 5, 1, 1, 2, 0, 1, 2, 2, 2, 2, 1, 2, 2, 0, 1, 2, 0, 2,
2, 2, 2, 1, 0, 2, 0, 1, 2, 1, 2, 2, 0, 0, 2, 2, 2, 3, 2, 2, 2,
2, 2, 1, 2, 1, 2, 2, 2, 2, 2), x = c(1, 2, 3, 13, 1, 14, 14,
4, 4, 0, 1, 1, 4, 2, 5, 3, 4, 13, 2, 5, 12, 1, 4, 0, 1, 2, 0,
2, 5, 2, 3, 3, 3, 1, 5, 4, 5, 0, 4, 2, 5, 4, 12, 3, 3, 5, 0,
3, 4, 4, 14, 5, 2, 1, 0, 0, 1, 3, 4, 2, 14, 1, 2, 2, 12, 1, 3,
4, 0, 5, 2, 5, 2, 2, 3, 5, 5, 2, 5, 13, 2, 4, 12, 2, 4, 1, 4,
0, 1, 0, 1, 0, 4, 5, 4, 5, 2, 2, 13, 3, 4, 13, 1, 12, 3, 1, 0,
2, 5, 3, 14, 4, 2, 2, 0, 0, 4, 0, 2, 12, 13, 3, 2, 1, 4, 2, 3,
1, 1, 3, 3, 0, 0, 3, 5, 3, 13, 3, 13, 3, 13, 3, 1, 1, 4, 2, 1,
4, 12, 5)), .Names = c(y, x),
row.names = c(NA, -150L), class = data.frame)
pdf(crashedadobe.pdf)
p2 = xyplot(y~x,data=d,
pch=16, # required, no problem with pch=1,2,8
panel = function(...) {
panel.xyplot(...) # both lines are required
panel.smoother(...) #
},
)
print(p2)
dev.off()
#R version 2.10.1 (2009-12-14)
#i386-pc-mingw32
#
#locale:
#[1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252
#[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
#[5] LC_TIME=German_Germany.1252
#
#attached base packages:
#[1] stats graphics grDevices datasets utils methods base
#
#loaded via a namespace (and not attached):
#[1] tools_2.10.1
#
__
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] Crash of latticeExtra graph with Adobe Acro Pro/Reader/Windows/ during print only (display ok).
Kasper Daniel Hansen-2 wrote: Flattening usually has to do with converting transparent stuff when you convert from a format that supports it (pdf) to something like postscript. perl script: http://tomas.rokicki.com/illbug/fixill.pl So my workflow is something like make pdf from R process the pdf using Illustrator, saving it as eps ./fixill.pl bad.eps good.eps This would explain why it only turn up when I combine both many points AND a shaded area from the smoother. Arguments against it: Why is it only a problem with pch=16 (the dot), and everything else works? (or, maybe the error turns up with more points?). Why is it not more frequently observed in ggplot2, where shading is used more often (the algorithm is from ggplot2 anyway). And, strangest of all: I by design tried some integer-overlapping coordinates with rnunif, and could not create a non-working example. And Foxit can do it? I will try on Linux Dieter -- View this message in context: http://n4.nabble.com/Crash-of-latticeExtra-graph-with-Adobe-Acro-Pro-Reader-Windows-during-print-only-display-ok-tp1602907p1605697.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION: Imports: assertion of version?
On 3/19/10 6:13 AM, Henrik Bengtsson wrote: Hi, from 'Writing R Extensions' [R version 2.11.0 Under development (unstable) (2010-03-16 r51290)] one can read: The optional `Imports' field lists packages whose name spaces are imported from but which do not need to be attached. [...] Versions can be specified, but will not be checked when the namespace is loaded. Is it a design decision that version specifications are not asserted for packages under Imports:, or is it a lack of implementation? If a design decision, under what use cases do you want to specify the version but not validating it? Is it simply because there is no mechanism for tracking the origin/package of the code importing the other package, and hence we cannot know which DESCRIPTION file to check against? I'm not aware of any use case in which the current lack of checking is a feature. I would be interested in a patch (with testing) for this. + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Not having to export .conflicts.OK in name spaces
On 3/17/10 9:11 AM, Henrik Bengtsson wrote: Currently library() and attach() fail to locate an existing '.conflicts.OK' in a package wit name space, unless it is exported. Since there should be little interest in exporting '.conflicts.OK' otherwise, one may argue that those methods should look for '.conflicts.OK' even if it is not exported. I guess I agree that there is no real value in forcing .conflicts.OK to be exported. OTOH, this seems like a dubious feature to begin. When is it a good idea to use it? + seth -- Seth Falcon | @sfalcon | http://userprimary.net/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION: Imports: assertion of version?
On 03/19/2010 01:44 PM, Seth Falcon wrote: On 3/19/10 6:13 AM, Henrik Bengtsson wrote: Hi, from 'Writing R Extensions' [R version 2.11.0 Under development (unstable) (2010-03-16 r51290)] one can read: The optional `Imports' field lists packages whose name spaces are imported from but which do not need to be attached. [...] Versions can be specified, but will not be checked when the namespace is loaded. Is it a design decision that version specifications are not asserted for packages under Imports:, or is it a lack of implementation? If a design decision, under what use cases do you want to specify the version but not validating it? Is it simply because there is no mechanism for tracking the origin/package of the code importing the other package, and hence we cannot know which DESCRIPTION file to check against? I'm not aware of any use case in which the current lack of checking is a feature. I would be interested in a patch (with testing) for this. This thread http://tolstoy.newcastle.edu.au/R/e5/devel/08/12/0981.html might provide some context. Martin + seth -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r cmd check in r 2.11 accessing internet
While performing an Rcmd check in R 2.11 (2010-03-14 r51276) on Windows Vista I noticed it was trying to access the internet during this phase: * checking Rd cross-references Is that supposed to happen? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
