[Rd] R CMD check for glmpath on Windows (PR#10823)
This is a multi-part message in MIME format. --_=_NextPart_001_01C874E6.BBFFB95E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem first appeared in R 2.6.1 and is still there in R 2.6.2 On Windows running R CMD check command for glmpath package fails. The = reason seems to be that when R is running the examples file (glmpath-Ex.R), it = skips about 50 lines and as a result gives a syntax error.=20 I'm working with a modified version of the CRAN glmpath 0.94. My version happens to give a more clear example of a problem than the original one. = Lines 86-89 of glmpath-Ex.R: bootstrap.a <- bootstrap.path(heart.data$x, heart.data$y, B=3D10, method=3D"bic") ## End Don't show bootstrap.a Lines 130-133 of glmpath-Ex.R: ### Name: cv.coxpath ### Title: Computes cross-validated (minus) log-partial-likelihoods for ### coxpath ### Aliases: cv.coxpath The end of glmpath-Ex.Rout: > bootstrap.a <- bootstrap.path(heart.data$x, heart.data$y, + B=3D10, method=3D"bic") > al-likelihoods for Error: unexpected 'for' in "al-likelihoods for" Execution halted I've contacted Mee Young who replied: "It failed for some obscure = reasons, but CRAN admins thought that the issue was Fortran's I/O interfering = with C.=20 However, the glmpath windows binary from any earlier version of R works under the current version of R." We've never observed this problem on LINUX. --please do not edit the information below-- Version: platform =3D i386-pc-mingw32 arch =3D i386 os =3D mingw32 system =3D i386, mingw32 status =3D=20 major =3D 2 minor =3D 6.1 year =3D 2007 month =3D 11 day =3D 26 svn rev =3D 43537 language =3D R version.string =3D R version 2.6.1 (2007-11-26) Windows XP (build 2600) Service Pack 2.0 Locale: LC_COLLATE=3DEnglish_United States.1252;LC_CTYPE=3DEnglish_United States.1252;LC_MONETARY=3DEnglish_United States.1252;LC_NUMERIC=3DC;LC_TIME=3DEnglish_United States.1252 Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, = package:base --_=_NextPart_001_01C874E6.BBFFB95E Content-Type: application/octet-stream; name="glmpath-Ex.Rout" Content-Transfer-Encoding: base64 Content-Description: glmpath-Ex.Rout Content-Disposition: attachment; filename="glmpath-Ex.Rout" DQpSIHZlcnNpb24gMi42LjIgKDIwMDgtMDItMDgpDQpDb3B5cmlnaHQgKEMpIDIwMDggVGhlIFIg Rm91bmRhdGlvbiBmb3IgU3RhdGlzdGljYWwgQ29tcHV0aW5nDQpJU0JOIDMtOTAwMDUxLTA3LTAN Cg0KUiBpcyBmcmVlIHNvZnR3YXJlIGFuZCBjb21lcyB3aXRoIEFCU09MVVRFTFkgTk8gV0FSUkFO VFkuDQpZb3UgYXJlIHdlbGNvbWUgdG8gcmVkaXN0cmlidXRlIGl0IHVuZGVyIGNlcnRhaW4gY29u ZGl0aW9ucy4NClR5cGUgJ2xpY2Vuc2UoKScgb3IgJ2xpY2VuY2UoKScgZm9yIGRpc3RyaWJ1dGlv biBkZXRhaWxzLg0KDQpSIGlzIGEgY29sbGFib3JhdGl2ZSBwcm9qZWN0IHdpdGggbWFueSBjb250 cmlidXRvcnMuDQpUeXBlICdjb250cmlidXRvcnMoKScgZm9yIG1vcmUgaW5mb3JtYXRpb24gYW5k DQonY2l0YXRpb24oKScgb24gaG93IHRvIGNpdGUgUiBvciBSIHBhY2thZ2VzIGluIHB1YmxpY2F0 aW9ucy4NCg0KVHlwZSAnZGVtbygpJyBmb3Igc29tZSBkZW1vcywgJ2hlbHAoKScgZm9yIG9uLWxp bmUgaGVscCwgb3INCidoZWxwLnN0YXJ0KCknIGZvciBhbiBIVE1MIGJyb3dzZXIgaW50ZXJmYWNl IHRvIGhlbHAuDQpUeXBlICdxKCknIHRvIHF1aXQgUi4NCg0KPiAjIyMgKiA8SEVBREVSPg0KPiAj IyMNCj4gYXR0YWNoKE5VTEwsIG5hbWUgPSAiQ2hlY2tFeEVudiIpDQo+IGFzc2lnbigibmFtZUV4 IiwgDQorICAgICAgICBsb2NhbCh7DQorIAkgICBzIDwtICJfX3ttdXN0IHJlbWFrZSBSLWV4Lyou Un1fXyINCisgICAgICAgICAgICBmdW5jdGlvbihuZXcpIHsNCisgICAgICAgICAgICAgICAgaWYo IW1pc3NpbmcobmV3KSkgcyA8PC0gbmV3IGVsc2Ugcw0KKyAgICAgICAgICAgIH0NCisgICAgICAg IH0pLA0KKyAgICAgICAgcG9zID0gIkNoZWNrRXhFbnYiKQ0KPiAjIyBBZGQgc29tZSBob29rcyB0 byBsYWJlbCBwbG90IHBhZ2VzIGZvciBiYXNlIGFuZCBncmlkIGdyYXBoaWNzDQo+IGFzc2lnbigi YmFzZV9wbG90X2hvb2siLA0KKyAgICAgICAgZnVuY3Rpb24oKSB7DQorICAgICAgICAgICAgcHAg PC0gcGFyKGMoIm1mZyIsIm1mY29sIiwib21hIiwibWFyIikpDQorICAgICAgICAgICAgaWYoYWxs KHBwJG1mZ1sxOjJdID09IGMoMSwgcHAkbWZjb2xbMl0pKSkgew0KKyAgICAgICAgICAgICAgICBv dXRlciA8LSAob21hNCA8LSBwcCRvbWFbNF0pID4gMDsgbWFyNCA8LSBwcCRtYXJbNF0NCisgICAg ICAgICAgICAgICAgbXRleHQoc3ByaW50ZigiaGVscChcIiVzXCIpIiwgbmFtZUV4KCkpLCBzaWRl ID0gNCwNCisgICAgICAgICAgICAgICAgICAgICAgbGluZSA9IGlmKG91dGVyKW1heCgxLCBvbWE0 IC0gMSkgZWxzZSBtaW4oMSwgbWFyNCAtIDEpLA0KKyAgICAgICAgICAgICAgIG91dGVyID0gb3V0 ZXIsIGFkaiA9IDEsIGNleCA9IC44LCBjb2wgPSAib3JjaGlkIiwgbGFzPTMpDQorICAgICAgICAg ICAgfQ0KKyAgICAgICAgfSwNCisgICAgICAgIHBvcyA9ICJDaGVja0V4RW52IikNCj4gYXNzaWdu KCJncmlkX3Bsb3RfaG9vayIsDQorICAgICAgICBmdW5jdGlvbigpIHsNCisgICAgICAgICAgICBw dXNoVmlld3BvcnQodmlld3BvcnQod2lkdGg9dW5pdCgxLCAibnBjIikgLSB1bml0KDEsICJsaW5l cyIpLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4PTAsIGp1c3Q9ImxlZnQi KSkNCisgICAgICAgICAgICBncmlkLnRleHQoc3ByaW50ZigiaGVscChcIiVzXCIpIiwgbmFtZUV4 KCkpLA0KKyAgICAgICAgICAgICAgICAgICAgICB4PXVuaXQoMSwgIm5wYyIpICsgdW5pdCgwLjUs ICJsaW5lcyIpLA0KKyAgICAgICAgICAgICAgICAgICAgICB5PXVuaXQoMC44LCAibnBjIiksIHJv dD05MCwNCisgICAgICAgICAgICAgICAgICAgICAgZ3A9Z3Bhcihjb2w9Im9yY2hpZCIpKQ0KKyAg ICAgICAgfSwNCisgICAgICAgIHBvcyA9ICJDaGVja0V4RW52IikNCj4gc2V0SG9vaygicGx
[Rd] Calling R_PreserveObject from embedded R
Hello. This is my first post to the list, so first I'd like to thank everybody for making and mantaining such a great product as R. I'm writting a native binding to R from Dolphin Smalltalk. I've followed up the examples of the documentation showing how to run R embedded, and I got it partially working. However, I have a problem with the reference handling of the R objects. I've followed this strategy: every time I call a function in R and it answers me a SEXP, I called R_PreserveObject(sexp), and wrap it with a Smalltalk object. Whenever the Smalltalk object dies, I release the R object by calling R_ReleaseObject(sexp). This seems to handle well the life cycle, but makes the running process to use a growing and a never ending amount of memory. Actually, after experimenting a while, I isolated the problem to iterate over a loop which all it does is create an expresion for a number, call PreserveObject and call ReleaseObject, and that alone makes the memory to grow indefinitely. I couldn't find any comment about this behaviour. Is there something I'm missing ? I'm running the embedded R-2.6.2 binaries for Windows in a WindowsXP sp2 environment. I've also implemented another strategy, which keeps a global list in R, and instead of calling R_PreserveObject, it inserts the SEXP in the list. This made the memory usage problem to go away, but the performance is noticeably worst compared with the other strategy, and is not as elegant as the first one neither, so I was hoping to be able to use the first strategy. I'll appreciate any comment about what might be going on. Thanks in advance. Best regards. martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies
Here is a demonstration of behaviour that is probably an optimization by
someone far smarter than me that did not anticipate anyone wanting to do
this, but for my purposes it looks more like a bug than a feature.
I have tested this with R2.6.2 on Windows, no additional packages loaded
(beyond the default), I have tested using the default graphics object,
pdf, jpeg, and cairoDevice (ok I loaded a package for that) and all show
the same behavior.
Run the following set of commands:
x <- rnorm(1000)
hist(x, xlim=c(-4,4))
tmp <- par('plt')
box(col='#')
tmp2 <- tmp
tmp2[2] <- tmp2[1] + 0.3
par(xpd = FALSE, plt=tmp2)
hist(x, col='red', add=TRUE)
box(col='#')
tmp3 <- tmp
tmp3[1] <- tmp3[2] - 0.3
par(xpd=FALSE, plt=tmp3)
hist(x, col='blue', add=TRUE)
par(plt=tmp)
This gives me the plot that I want and expect (a histogram with the left
section red, the middle white/background, and the right blue).
Now comment out or delete the 2 box commands and rerun everything. The
clipping does not happen this time and the final result is a full blue
histogram.
Is this a bug? Feature? Something else?
Does anyone have a better work around than drawing transparent boxes?
Thanks,
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clipping using par(plt=..., xpd=FALSE) inconsistencies
I think you misunderstand what par("plt") is supposed to do. The
documentation says
'plt' A vector of the form 'c(x1, x2, y1, y2)' giving the
coordinates of the plot region as fractions of the current
figure region.
You haven't subsequently made a new plot, so why do you expect the
clipping region to be changed to that you indicated for the next plot?
I'd say the bug was that box() changed it, and that happens because it
internally sets xpd and so resetting xpd sets the clipping region next
time it is used. Because of
void GClip(pGEDevDesc dd)
{
if (gpptr(dd)->xpd != gpptr(dd)->oldxpd) {
double x1, y1, x2, y2;
setClipRect(&x1, &y1, &x2, &y2, DEVICE, dd);
GESetClip(x1, y1, x2, y2, dd);
gpptr(dd)->oldxpd = gpptr(dd)->xpd;
}
}
Maybe we should have user-level code to set the clipping region?
On Fri, 22 Feb 2008, Greg Snow wrote:
> Here is a demonstration of behaviour that is probably an optimization by
> someone far smarter than me that did not anticipate anyone wanting to do
> this, but for my purposes it looks more like a bug than a feature.
>
> I have tested this with R2.6.2 on Windows, no additional packages loaded
> (beyond the default), I have tested using the default graphics object,
> pdf, jpeg, and cairoDevice (ok I loaded a package for that) and all show
> the same behavior.
>
> Run the following set of commands:
>
> x <- rnorm(1000)
> hist(x, xlim=c(-4,4))
>
> tmp <- par('plt')
>
> box(col='#')
> tmp2 <- tmp
> tmp2[2] <- tmp2[1] + 0.3
> par(xpd = FALSE, plt=tmp2)
> hist(x, col='red', add=TRUE)
>
> box(col='#')
> tmp3 <- tmp
> tmp3[1] <- tmp3[2] - 0.3
> par(xpd=FALSE, plt=tmp3)
> hist(x, col='blue', add=TRUE)
> par(plt=tmp)
>
>
> This gives me the plot that I want and expect (a histogram with the left
> section red, the middle white/background, and the right blue).
>
> Now comment out or delete the 2 box commands and rerun everything. The
> clipping does not happen this time and the final result is a full blue
> histogram.
>
> Is this a bug? Feature? Something else?
> Does anyone have a better work around than drawing transparent boxes?
>
> Thanks,
>
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
