[Rd] trellis.device in .First (PR#6812)
Prof Brian Ripley
ripley at stats.ox.ac.uk
Mon Apr 26 08:18:54 CEST 2004
On Mon, 26 Apr 2004, Paul Murrell wrote:
> Hi
>
>
> Martin Maechler wrote:
> >>>>>>"BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk>
> >>>>>> 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). 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 ....
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.
Brian
>
> 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, ripley at stats.ox.ac.uk 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> R-devel at stat.math.ethz.ch mailing list
> > BDR> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > R-devel at stat.math.ethz.ch mailing list
> > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
>
>
>
--
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
More information about the R-devel
mailing list