> First, it was not clear that you are talking about the output of
> traceback(), which is _a representation of_ the call stack and depends on
> the details of deparsing.
Given that there is a substantial delay in one case, and not in the
other, I had assumed (perhaps falsely) that there was something more
fundamental going on that simply the representation of the call stack
by traceback. Perhaps I should have been more clear that the output of
traceback was a symptom of the problem, not what I was really
interested in.
> Second, the difference is I believe not implicit vs explicit printing, but
> of printing an evaluated object vs printing a call. What your subject
> line would correspond to is
>
> x <- ggplot(mtcars, aes(x = cyl, y = -mpg)) + scale_y_log10() + geom_point()
> x vs print(x)
>
> I can't demonstrate (what is aes?), but I expect that would show minimal
> differences.
I don't think that is the case. Using Gabor's reproducible example:
library(lattice)
x <- xyplot(conc ~ uptake, CO2, xlim = Inf)
x
traceback()
print(x)
traceback()
shows the same differences that I reported.
> The issue seems to be whether arguments have been evaluated, and if so
> whether they were promises. Promises can be deparsed back to the symbolic
> representation rather than to their value. When you call print explicitly
> _on the ggplot call_, you have promises to arguments (to support lazy
> evaluation). As far as I know (this is a detail of your code), the object
> ggplot returns has evaluated 'mtcars' and contains the value and not the
> promise, hence the difference in the deparsing of the call stack.
I'm not sure I completely follow, and I don't think your reasoning
holds given the example above. Please correct me if I am wrong. My
code for ggplot.print follows if that helps.
print.ggplot <- function(x, newpage = is.null(vp), vp = NULL, ...) {
if (newpage) grid.newpage()
if (is.null(vp)) {
grid.draw(ggplot_plot(x, ...))
} else {
pushViewport(vp)
grid.draw(ggplot_plot(x, ...))
upViewport()
}
}
>
> You chose to call traceback() without 'max.lines', and the answer would
> seem to be
>
> 1) don't use a buggy print method,
> 2) if you have to (to fix it), use 'max.lines' or do this in two steps.
>
> If you want your end users to see a nicer representation, reconsider what
> you actually return in your object.
I don't really care about the representation in the call stack
(although it is a pain when debugging, even though max.lines helps),
the main problem is the 4-5 second delay after an error before control
returns to the user. This does not occur with an explicit print.
Hadley
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
