trellis.device in .First (PR#6812)

This is a start of R 1.9.0 in a directory without .RData
options(STERM='iESS', editor='gnuclient.exe')
search()
[1] ".GlobalEnv"       "package:methods"  "package:stats"    "package:graphics"
[5] "package:utils"    "Autoloads"        "package:base"
find(windows)
[1] "package:graphics"

This makes me think that the .First is being processed before some of the other
initializations.  I had been assuming it is the very last thing done before it gives me
control.

This introduces a new problem---both 1.9.0 and 1.8.1.
I did --vanilla as you suggested, in a directory without an existing .RData

/cygdrive/c/HOME/tmp$ Rterm --vanilla

R : Copyright 2004, The R Foundation for Statistical Computing
Version 1.9.0  (2004-04-12), ISBN 3-900051-00-3

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for a HTML browser interface to help.
Type 'q()' to quit R.
date()
date()
[1] "Thu Apr 22 21:52:14 2004"
ls()
ls()
character(0)
nonsense
nonsense
Error: Object "nonsense" not found
Execution halted
/cygdrive/c/HOME/tmp$ 

When I manually start the trellis.device, after a version of my .First that doesn't
start it for me, I get this
.Device
[1] "windows"

on the q() issue, I report it as a continuation of behavior that has been discussed
on this list.  I don't remember when.  It has been an issue for me for a long time.
I am currently on XP HOME, I see this also on NT4.

I normally type just q()
This time I tried q("no").

It still freezes. I have to enter C-G to unfreeze emacs and then use the Task Manager
to kill the Rterm process.

Rich
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.

2) The second point is a long known problem with ESS/Emacs on some 
systems.  There is a PR against it already (I saw a few days ago).  Please 
don't add irrelevant issues to a bug report on another issue.

BDR

This is a start of R 1.9.0 in a directory without .RData

options(STERM='iESS', editor='gnuclient.exe')
search()
[1] ".GlobalEnv"       "package:methods"  "package:stats"    "package:graphics"
[5] "package:utils"    "Autoloads"        "package:base"    
find(windows)
[1] "package:graphics"

This makes me think that the .First is being processed before some of the other
initializations.  I had been assuming it is the very last thing done before it gives me
control.

This introduces a new problem---both 1.9.0 and 1.8.1.
I did --vanilla as you suggested, in a directory without an existing .RData

/cygdrive/c/HOME/tmp$ Rterm --vanilla

R : Copyright 2004, The R Foundation for Statistical Computing
Version 1.9.0  (2004-04-12), ISBN 3-900051-00-3

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for a HTML browser interface to help.
Type 'q()' to quit R.

date()
date()
[1] "Thu Apr 22 21:52:14 2004"
ls()
ls()
character(0)
nonsense
nonsense
Error: Object "nonsense" not found
Execution halted
/cygdrive/c/HOME/tmp$ 

When I manually start the trellis.device, after a version of my .First that doesn't
start it for me, I get this
.Device
[1] "windows"

on the q() issue, I report it as a continuation of behavior that has been discussed
on this list.  I don't remember when.  It has been an issue for me for a long time.
I am currently on XP HOME, I see this also on NT4.

I normally type just q()
This time I tried q("no").

It still freezes. I have to enter C-G to unfreeze emacs and then use the Task Manager
to kill the Rterm process.

Rich

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

Brian D. Ripley,                  ripley@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
Extract from ?Startup

     Next, if a function '.First' is found on the search path, it is
     executed as '.First()'. Finally, function '.First.sys()' in the
     'base' package is run. This calls 'require' to attach the default
     packages specified by 'options("defaultPackages")'.

so again, this was documented in the (to me) obvious place.

Note `windows' is in package `graphics', a default package specified by
'options("defaultPackages")'.

It is a matter for discussion (with the lattice maintainer) whether 
trellis.device should help you out here by importing the devices from 
package graphics.  I think adding (conditionalized on the platform)

importFrom(graphics, windows, postscript, pdf, pictex, win.metafile, 
           win.print, png, jpeg, bmp, xfig, bitmap)

to its NAMESPACE might be worth considering.  Alternatively,
	device.call <- get(device)
could be put in a try call, followed by a try on 
	getFromNamespace("graphics", device).

BDR

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.

Brian D. Ripley,                  ripley@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
"BDR" == Prof Brian Ripley <ripley@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}.

Martin

    BDR> BDR
>> 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@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@stat.math.ethz.ch mailing list
    BDR> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
"BDR" == Prof Brian Ripley <ripley@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?), 
(yes, device is an argument to trellis.device that defaults to 
getOption("device"))
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}.
That sounds like a good argument to go with the second approach. Looks 
like I would need importFrom(utils, getFromNamespace) for that, right ?

I'll release an updated version over the weekend.

Deepayan
Hi
"BDR" == Prof Brian Ripley <ripley@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).

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@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@stat.math.ethz.ch mailing list
    BDR> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@stat.math.ethz.ch 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
paul@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

Hi

Martin Maechler wrote:
"BDR" == Prof Brian Ripley <ripley@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@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@stat.math.ethz.ch mailing list
    BDR> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

Brian D. Ripley,                  ripley@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
Hi
On Mon, 26 Apr 2004, Paul Murrell wrote:

Hi

Martin Maechler wrote:

"BDR" == Prof Brian Ripley <ripley@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).  
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.

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@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@stat.math.ethz.ch mailing list
   BDR> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@stat.math.ethz.ch 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
paul@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/