Hi
Paul Murrell wrote:
Prof Brian Ripley wrote:On Mon, 26 Apr 2004, Paul Murrell wrote:Martin Maechler wrote:
"BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> on Fri, 23 Apr 2004 08:21:34 +0100 (BST) writes:
<........>
BDR> It is a matter for discussion (with the lattice BDR> maintainer) whether trellis.device should help you out BDR> here by importing the devices from package graphics. I BDR> think adding (conditionalized on the platform)
BDR> importFrom(graphics, windows, postscript, pdf, pictex,
BDR> win.metafile, win.print, png, jpeg, bmp, xfig, bitmap)
BDR> to its NAMESPACE might be worth considering.
BDR> Alternatively, device.call <- get(device) could be put BDR> in a try call, followed by a try on BDR> getFromNamespace("graphics", device).
That's a very good idea, I'd support quite a bit.
I think I would go with the alternative approach
(where you probably meant to say device <- getOption("device") first?),
since the importFrom(..) approach leeds to a somewhat tedious maintenance
effort to keep up the list of available devices for the different platforms
(For MacOS X one has to include quartz() only in the situations
where it's available) where as Deepayan (the lattice
maintainer) could rely on getOption("device") to be ok
{and as you proposed would be on guard using try() or its newer siblings}.
I probably should have thought of this sooner, but anyway ...
Perhaps a better solution would be to split out another package called "devices". Then both "graphics" and "grid" could require "devices" (so whenever you go to do any graphics you are guaranteed access to the default devices).
I am not sure it is better, but it is not something we can do for a few months (that is, not in a patchlevel release).
Yep, it would have to be only at the next minor release.
It's not quite that simple -- where would you put ps.options? Presumably in devices, and then people would need to change their hooks again ....
Yep (I probably should have thought of it sooner ...).
Incidentally, I think the name `devices' is rather narrow-minded (as is .Devices borrowed from S-PLUS). They are _graphics_ devices and we might one day want audio devices or even devices for other types of visualization such as dynamic graphics.
Yep. Good point.
I think it would be a cleaner design (it would be nicer if "grid" did not have to require (bits of) "graphics"), but it would be a bit disruptive for users.
Could we avoid the user-disruption problem by making a new graphicsDevices package (to contain postscript(), x11(), ps.options(), ...) and have the graphics package import these symbols from graphicsDevices AND export them (this is technically feasible with the current NAMESPACE implementation right?). Then existing users wouldn't have to change their hooks, but grid could import directly from graphicsDevices, not via graphics.
Paul
BDR> On Fri, 23 Apr 2004, Prof Brian Ripley wrote:
>> 1) On the first point, please do read the NEWS file for R >> 1.9.0. >> >> .Rprofile and .First have always been run before the >> default packages are loaded in .First.sys, to allow them >> to be changed. >> >> So this *is* a documented change in behaviour, not a bug. >> If I do >> >> .First <- function() {library(lattice); trellis.device()} >> >> This happens on all platforms. You need >> >> .First <- function() {library(graphics); >> library(lattice); trellis.device()} >> >> That is true of starting any graphics device in .Rprofile >> or .First.
BDR> -- Brian D. Ripley, [EMAIL PROTECTED] Professor of BDR> Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ BDR> University of Oxford, Tel: +44 1865 272861 (self) 1 BDR> South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, BDR> UK Fax: +44 1865 272595
BDR> ______________________________________________ BDR> [EMAIL PROTECTED] mailing list BDR> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
-- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
