From ripley@stats.ox.ac.uk  Mon Jan 15 10:35:36 2001
From: ripley@stats.ox.ac.uk (ripley@stats.ox.ac.uk)
Date: Mon, 15 Jan 2001 11:35:36 +0100 (MET)
Subject: [Rd] Memory problem 2 (PR#815)
Message-ID: <200101151035.LAA24529@pubhealth.ku.dk>

> From: Z.Barta@bristol.ac.uk
> Date: Mon, 15 Jan 2001 11:22:40 +0100 (MET)
> To: r-devel@stat.math.ethz.ch
> Subject: [Rd] Memory problem 2 (PR#815)
> CC: R-bugs@biostat.ku.dk
> X-Loop: R-bugs@biostat.ku.dk
> 
> 
> Dear R-developer,
> 
> Just some more details on the problem I reported several minutes ago.
> On an NT machine (4.0 SP6) I got the following for the same task:
> 
> > version
>          _              
> platform i386-pc-mingw32
> arch     x86            
> os       Win32          
> system   x86, Win32     
> status                  
> major    1              
> minor    2.0            
> year     2000           
> month    12             
> day      15             
> language R              
> > setwd("d:/ftp")
> NULL
> > source("O.dat.R")
> > F12 <- O.dat("food12")
> Read 92669 lines
> Error: cannot allocate vector of size 723 Kb
> > 
> 
> I hope this help a bit more.

It doesn't.  On Windows, we need to know what you set --max-mem-size
to, and if you did not, what memory.size(max=TRUE) says and what your
physical memory is.

All this tells us is that you ran out of allocatable memory.  That's
not a bug.

-- 
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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

From jens.oehlschlaegel@bbdo-interone.de"
 <jens.oehlschlaegel@bbdo-interone.de  Mon Jan 15 12:58:00 2001
From: jens.oehlschlaegel@bbdo-interone.de"
 <jens.oehlschlaegel@bbdo-interone.de (=?iso-8859-1?Q?=22Dr=2E_Jens_Oehlschl=E4gel=22?=)
Date: Mon, 15 Jan 2001 13:58:00 +0100
Subject: [Rd] AW: par(par()) corrupts devices (PR#807)
Message-ID: <01C07EFB.2C8CA600.jens.oehlschlaegel@bbdo-interone.de>



Dear Prof. Ripley,

I do not insist that features are bugs, so I stop sending this to r-bugs 
and cc r-devel instead

> I am replying to this from the archive: I did not actually receive a 
copy.

But it is right to sent bug reports ONLY to r-bugs, isn't it?
I'am actually using a old version of outlook, and some mails from r-help 
appear as attachments, may it's an outlook problem.

> This is a feature!
> You set par(pin=), and that takes precedence over
> par(pty=).  Same with par(plt=).
>
> To unjam it, you need e.g.  par(mai=old.par$mai)
>
> I think that par(pty=) should revert to a default plot spec, and will
> change this.  But, the problem with restoring lists like that is that
> it depends on exactly the order of the params as they interact.
> It is *not* a good idea.  And no.readonly=T does not help as
> plt and pin are not readonly.  If the user has resized the device before
> restoration, it's pretty chancy what it gets set to.

Thank you for explaining the way it happens. I must admit, that again I am 
baffled things do not work as I expect. WHAT IS THE RECOMMENDED WAY TO 
RESTORE GRAPHICAL PARAMETERS TO EXACTLY WHAT THEY WERE?

I admit, I expected par(par()) not to change anything (I remember vague 
that it worked with the prototype), but in this case it is not (only) a 
problem of restoring a list. Just setting par(pin) and "re-setting" it DOES 
CHANGE the device: subsequent par(pty="s") are ignored.

I am shure I am not the only one who expected the on.exit() stuff within 
the following function to leave the graphical parameters UNCHANGED, but it 
doesn't.

somefunc <- function(){
	oldpin <- par(pin=par("pin"))
	on.exit(par(oldpin))
	plot(1,1)
}

windows(5,3)

par(pty="s")
plot(1,1)
# square
par(pty="m")
plot(1,1)

# which settings do we have before
par1 <- par()

somefunc()

# which settings do we have now
par2 <- par()
# do they differ: yes on plt
all.equal(par1, par2)

# reset plt
par(plt=par1$plt)

# which settings do we have now
par2 <- par()
# do they differ: no
all.equal(par1, par2)

par(pty="s")
plot(1,1)
#still not square
#i.e we have hidden parameters
#because all par() are restored to values where par(pty="s") did work

> if the user has resized the device before restoration, it's pretty chancy 
what it gets set to.

I find it frightening to discover that we obvisously have hidden device 
parameters, and more frigthening that they may be modified by resizing.
Sorry that I can't provide code fix, but this is far to deep within the 
heart of R.

Best regards


Jens Oehlschlgel

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] Memory problem 2 (PR#815)
ripley@stats.ox.ac.uk