Re: [Rd] bug + insufficient doc in R CMD INSTALL (PR#5703)
dpierce writes: Hello, I believe I have found a bug in the R INSTALL script (src/scripts/INSTALL.in). The problem comes up when a user tries to specify more than one --config-args (or, I imagine, --config-vars) on the R CMD INSTALL line. In such a case, no error message is generated, but the first specification is silently overwritten by the second specification. The process therefore fails. So for instance, a user contacted me after typing this: R CMD INSTALL --configure-args=-with-netcdf_incdir=/usr/local/netcdf/include --configure-args=-with-netcdf_libdir=/usr/local/netcdf/lib ncdf_1.1.tar.gz and it failed (they contacted me because I'm the maintainer of the ncdf package). I would say that this is both a bug and something that needs more documentation. It's a bug because it accepts the incorrect line without giving an error message, but does not parse it as expected. And I would say it needs more documentation because I looked through the R docs on this, and could find no place where the correct syntax is given. You probably already know (I didn't), but the syntax should be this instead: R CMD INSTALL --configure-args=-with-netcdf_incdir=/usr/local/netcdf/include -with-netcdf_libdir=/usr/local/netcdf/lib ncdf_1.1.tar.gz and, of course, although I'm using the ncdf package as an example for concreteness, this is a general problem for any R package. The place in INSTALL.in that seems to be problematic is this bit: ... I would have thought that the current behavior is what everyone would expect to happen: I don't recall having come across a program where command line options accumulate. If really necessary, we can of course say so. I don't think we should change the code, as then we would need to handle *all* command line arguments accordingly, or, even worse, special-case some command line args ... -k __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] legend() graphics output bug (PR#5725)
Full_Name: Daniel Gasser Version: 1.8.1 OS: Win XP Submission from: (NULL) (130.60.20.92) The legend()-Function shows a different behaviour than it did in Version 1.6.1. It plots a black box left of the legend lines on each legend row. In 1.6.1 there was just the line in appropriate color for each row in the legend (i was using exactly the same legend statement and same plot function). My legend statement is: legend(x=(daysold+2), y=0.95*maxy.j, legend=leg.txt, col = leg.col, lty=1,angle = NULL, density = NULL, bty = o, xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, ncol = 1, horiz = FALSE) If i write the statement as follows: legend(x=(daysold+2), y=0.95*maxy.j, legend=leg.txt, col = leg.col, lty=1,angle = NULL, density = NULL, bty = o, xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, ncol = 1, horiz = FALSE, merge = TRUE) The merge = TRUE statemen merges the black boxes (one for each row) and the colored lines in the legend, but the boxes remain there. __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in pbinom? (PR#5727)
Dear colleagues, the command pbinom(size=1.95*10^10,prob=seq(1.02,1.03,10^-3)*10^-10,q=1,lower=F,log=T) produced the output [1] -46.0120973 -46.0101369 -46.0081784 -46.0062239 -46.0042692 -46.0023165 [7] -0.5205666 -0.5196801 -0.5187944 -0.5179102 -0.5170278 what seems strange. Has this survived in newer versions? Best regards, Volkmar Liebscher -- Dr. Volkmar Liebscher Institute of Biomathematics and Biometry GSF - National Research Centre for Environment and Health Ingolstädter Landstr.1 D--85758 Neuherberg Germany E-mail: [EMAIL PROTECTED] URL:http://www.gsf.de/ibb/homepages/liebscher phone: +49 89 3187 2907 Fax:+49 89 3187 3369 --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = major = 1 minor = 7.1 year = 2003 month = 06 day = 16 language = R Search Path: .GlobalEnv, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() graphics output bug (PR#5725)
[EMAIL PROTECTED] wrote: Full_Name: Daniel Gasser Version: 1.8.1 OS: Win XP Submission from: (NULL) (130.60.20.92) The legend()-Function shows a different behaviour than it did in Version 1.6.1. It plots a black box left of the legend lines on each legend row. In 1.6.1 there was just the line in appropriate color for each row in the legend (i was using exactly the same legend statement and same plot function). My legend statement is: legend(x=(daysold+2), y=0.95*maxy.j, legend=leg.txt, col = leg.col, lty=1,angle = NULL, density = NULL, bty = o, xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, ncol = 1, horiz = FALSE) If i write the statement as follows: legend(x=(daysold+2), y=0.95*maxy.j, legend=leg.txt, col = leg.col, lty=1,angle = NULL, density = NULL, bty = o, xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, ncol = 1, horiz = FALSE, merge = TRUE) The merge = TRUE statemen merges the black boxes (one for each row) and the colored lines in the legend, but the boxes remain there. Don't specify density which implies that you are requesting the boxes. Looks like there was a bug in R-1.6.1 that has been fixed. Uwe Ligges __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legend() graphics output bug (PR#5725)
On Fri, 12 Dec 2003 [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Full_Name: Daniel Gasser Version: 1.8.1 OS: Win XP Submission from: (NULL) (130.60.20.92) The legend()-Function shows a different behaviour than it did in Version 1.6.1. It plots a black box left of the legend lines on each legend row. In 1.6.1 there was just the line in appropriate color for each row in the legend (i was using exactly the same legend statement and same plot function). My legend statement is: legend(x=(daysold+2), y=0.95*maxy.j, legend=leg.txt, col = leg.col, lty=1,angle = NULL, density = NULL, bty = o, xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, ncol = 1, horiz = FALSE) If i write the statement as follows: legend(x=(daysold+2), y=0.95*maxy.j, legend=leg.txt, col = leg.col, lty=1,angle = NULL, density = NULL, bty = o, xjust = 0, yjust = 1, x.intersp = 1, y.intersp = 1, ncol = 1, horiz = FALSE, merge = TRUE) The merge = TRUE statemen merges the black boxes (one for each row) and the colored lines in the legend, but the boxes remain there. Don't specify density which implies that you are requesting the boxes. Looks like there was a bug in R-1.6.1 that has been fixed. Several, with o legend() allows shading without filling again. being the critical one. -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in pbinom? (PR#5727)
Oh, come on: have you never heard of the Poisson approximation? ppois(1, 1.95*seq(1.02,1.03,10^-3), lower=F,log=T) [1] -0.5259247 -0.5250276 -0.5241321 -0.5232383 -0.5223462 -0.5214557 [7] -0.5205669 -0.5196798 -0.5187943 -0.5179104 -0.5170282 Probably you believe that computers never make errors too. On Fri, 12 Dec 2003 [EMAIL PROTECTED] wrote: Dear colleagues, the command pbinom(size=1.95*10^10,prob=seq(1.02,1.03,10^-3)*10^-10,q=1,lower=F,log=T) produced the output [1] -46.0120973 -46.0101369 -46.0081784 -46.0062239 -46.0042692 -46.0023165 [7] -0.5205666 -0.5196801 -0.5187944 -0.5179102 -0.5170278 what seems strange. Has this survived in newer versions? Best regards, Volkmar Liebscher -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Failed installation on Mac OSX 10.3 (PR#5697)
I did read the readme.txt but it said you 'should' install the libreadline so my impression was that it was recommended but not necessary. Undoubtedly, an oversight on my part. Brian On Fri, 12 Dec 2003, stefano iacus wrote: You should read the readme.txt file which says that you have to install the libreadline with the provided .pkg archive that comes with RAqua.dmg. stefano On Giovedì, dic 11, 2003, at 16:39 Europe/Rome, [EMAIL PROTECTED] wrote: I've installed R 1.8.1 on OSX 10.3 (Panther) using the RAqua.pkg and all indications were that the installation was successful. However, after double clicking the R icon in the Applications folder, nothing appears to happen. The following message appears on the console: Mac OS X Version 10.3 (Build 7B85) 2003-12-11 08:45:31 -0500 prefs written dyld: /Applications/StartR.app/RAqua.app/Contents/MacOS/RAqua can't open library: /usr/local/lib/libreadline.4.3.dylib (No such file or directory, errno = 2) When I check /usr/local/ there is no 'lib' folder, only the 'bin' folder. I checked the FAQ's and the bug reports and this problem was reported by at least one other person (bug report id 5529) but no solution has been put forward that I could find. Do the other packages that come with the download (e.g., j_libreadlne.pkg, j_tcltk.pkg, j_libxml2.pkg) need to be installed? Any suggestions are appreciated. Thanks for your help, Brian -- * Brian Beckage Department of Botany University of Vermont Marsh Life Science Building Burlington, VT 05405 Phone: 802 656-0197 Fax : 802 656-0440 email: [EMAIL PROTECTED] web : www.uvm.edu/~bbeckage __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Failed installation on Mac OSX 10.3 (PR#5697)
We are probably both right as the readme.txt file says You should also install the other three packages: 1. libreadline (unless you have this package already installed) 2. tcltk (this is a must if you want to use tcltk) 3. libxml2 (if you want to use the XML package) stefano On Venerdì, dic 12, 2003, at 12:41 Europe/Rome, Brian Beckage wrote: I did read the readme.txt but it said you 'should' install the libreadline so my impression was that it was recommended but not necessary. Undoubtedly, an oversight on my part. Brian On Fri, 12 Dec 2003, stefano iacus wrote: You should read the readme.txt file which says that you have to install the libreadline with the provided .pkg archive that comes with RAqua.dmg. stefano On Giovedì, dic 11, 2003, at 16:39 Europe/Rome, [EMAIL PROTECTED] wrote: I've installed R 1.8.1 on OSX 10.3 (Panther) using the RAqua.pkg and all indications were that the installation was successful. However, after double clicking the R icon in the Applications folder, nothing appears to happen. The following message appears on the console: Mac OS X Version 10.3 (Build 7B85) 2003-12-11 08:45:31 -0500 prefs written dyld: /Applications/StartR.app/RAqua.app/Contents/MacOS/RAqua can't open library: /usr/local/lib/libreadline.4.3.dylib (No such file or directory, errno = 2) When I check /usr/local/ there is no 'lib' folder, only the 'bin' folder. I checked the FAQ's and the bug reports and this problem was reported by at least one other person (bug report id 5529) but no solution has been put forward that I could find. Do the other packages that come with the download (e.g., j_libreadlne.pkg, j_tcltk.pkg, j_libxml2.pkg) need to be installed? Any suggestions are appreciated. Thanks for your help, Brian -- * Brian Beckage Department of Botany University of Vermont Marsh Life Science Building Burlington, VT 05405 Phone: 802 656-0197 Fax : 802 656-0440 email: [EMAIL PROTECTED] web : www.uvm.edu/~bbeckage __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reorganization of packages in the R distribution
Prof Brian Ripley wrote: There are a small number of CRAN packages that attempt to modify system functions and so will need updating. (Known examples are in dse:tframe, gregmisc and mclust and some testing code elsewhere.) Brian What do you mean by updating? In tframe I modify a few functions like start - function (x, ...) if (is.Ttframed(x)) start(tframe(x), ...) else UseMethod(start) If that can no longer be done then this is a serious fundamental change that breaks all my code. I hope that is not what you mean. I'm just going away for a week, but will follow up when I return. Paul __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reorganization of packages in the R distribution
Prof Brian Ripley wrote: On Fri, 12 Dec 2003, Paul Gilbert wrote: Prof Brian Ripley wrote: There are a small number of CRAN packages that attempt to modify system functions and so will need updating. (Known examples are in dse:tframe, gregmisc and mclust and some testing code elsewhere.) Brian What do you mean by updating? In tframe I modify a few functions like start - function (x, ...) if (is.Ttframed(x)) start(tframe(x), ...) else UseMethod(start) If that can no longer be done then this is a serious fundamental change that breaks all my code. I hope that is not what you mean. I'm just going away for a week, but will follow up when I return. It's always been incorrect code, and it no longer works. You should not be masking system generics, as the namespace registration mechanism does not work on your version. So what would be the proper mechanism for doing something like this? Basically I need to do something that I believe is like multiple inheritance. I need to dispatch on the class of a certain part of an object rather than on the object itself. (BTW, this code has worked for about ten years and I believe predates your definition of corrrect.) Paul __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reorganization of packages in the R distribution
Henrik Thanks for the suggestion. I am not sure that I have sufficient control over the functions that make an object Ttframed. I will have to explore a bit further to know that, and I am about to get on a plane so it will be awhile before I have a chance to do that. My first reaction is to agree with the can get messy observation. Paul Henrik Bengtsson wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilbert Sent: den 12 december 2003 16:20 To: Prof Brian Ripley Cc: Paul Gilbert; [EMAIL PROTECTED] Subject: Re: [Rd] Reorganization of packages in the R distribution Prof Brian Ripley wrote: On Fri, 12 Dec 2003, Paul Gilbert wrote: Prof Brian Ripley wrote: There are a small number of CRAN packages that attempt to modify system functions and so will need updating. (Known examples are in dse:tframe, gregmisc and mclust and some testing code elsewhere.) Brian What do you mean by updating? In tframe I modify a few functions like start - function (x, ...) if (is.Ttframed(x)) start(tframe(x), ...) else UseMethod(start) If that can no longer be done then this is a serious fundamental change that breaks all my code. I hope that is not what you mean. I'm just going away for a week, but will follow up when I return. It's always been incorrect code, and it no longer works. You should not be masking system generics, as the namespace registration mechanism does not work on your version. So what would be the proper mechanism for doing something like this? Basically I need to do something that I believe is like multiple inheritance. I need to dispatch on the class of a certain part of an object rather than on the object itself. (BTW, this code has worked for about ten years and I believe predates your definition of corrrect.) Paul Hi, not knowing yours details, but here's an idea that might work. Under S3/UseMethod() you can emulate multiple inheritance by adding one superclass in front of the other to the class attribute. For instance, if ClassAA inherits from ClassA and ClassBB inherits from ClassB and MyClass inherits from ClassAA and ClassBB, then you'll get class(x) - c(MyClass, ClassAA, ClassBB, ClassA, ClassB) Of course, it is important to get the order correct, and things can get messy if you're not careful. So, whatever function makes your object 'x' Ttframed, couldn't that function at the same time add the superclass TtframedClass in front of the class vector before returning the object?! However, I see a real problem if you do not control/own the functions that makes an object Ttframed. Best wishes Henrik Bengtsson Lund University __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] A christmas gift for you rtfeb ybksj (PR#5734)
--76_91.FB28F_3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 DQpIaSwNCg0KR3JlYXQgcmF0ZXMgZm9yIHRoZSBob2xpZGF5cyEgDQoNClJlZmluYW5jZSB0 b2RheSB0byBhcyBsb3cgYXMgMi45NSUhDQpTYXZlIHRob3VzYW5kcyBvZiBkb2xsYXJzIG9y IGJ1eSB0aGUgDQpob21lIG9mIHlvdXIgZHJlYW1zIQ0KDQpBcHBseSB0b2RheSEgSXQgb25s eSB0YWtlcyAyIG1pbnV0ZXMuIA0KDQp3d3cuYmVzdC1sb2FuLXNlYXJjaC5iaXoNCg0KVGhh bmtzLA0KVHJhY3kgSmVuc2VuIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0Kcm12OiB3d3cu YmVzdC1sb2FuLXNlYXJjaC5iaXovZ28gcyB4eiAgZnloIHN4c3VnZ3ENCmRtDQpibyBkdWhq dXJpd3UgcXFmZnVjY2J4aXNmYw0KbmlxZXNkIHV0ZHdhdWZzYiB2cnogcyBvbXA= --76_91.FB28F_3C-- __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reorganization of packages in the R distribution
On Fri, 12 Dec 2003, Paul Gilbert wrote:
If I understand this change correctly, I think is wrong for R-core to
think it is a small change. It has much more serious consequences for me
than any changes introduced R 1.0. It definitely should not be
introduced at a dot level release unless there is a fairly simple
mechanism to deal with the implications. It breaks 6 of my 9 packages
on CRAN at a fairly fundamental level, 2 more at a less serious level,
and some packages I have not yet release.
Perhaps my programming technique is not correct. I always considered
this trick to be a work-around for a short coming in R/S. The issue is
that the correct way to do this needs to be implemented before the trick
that allows a work-around is eliminated.
Paul Gilbert
Prof Brian Ripley wrote:
On Fri, 12 Dec 2003, Paul Gilbert wrote:
Prof Brian Ripley wrote:
There are a small number of CRAN packages that attempt to modify system
functions and so will need updating. (Known examples are in dse:tframe,
gregmisc and mclust and some testing code elsewhere.)
Brian
What do you mean by updating? In tframe I modify a few functions like
start - function (x, ...) if (is.Ttframed(x)) start(tframe(x),
...) else UseMethod(start)
If that can no longer be done then this is a serious fundamental change
that breaks all my code. I hope that is not what you mean. I'm just
going away for a week, but will follow up when I return.
It's always been incorrect code, and it no longer works. You should not
be masking system generics, as the namespace registration mechanism does
not work on your version.
There are a number of options, depending on what you are trying to do.
If you want to make a definition of how the function `start' should
handle a TtFramed object in a way that should be visible to functions
defined in other packages that use the function start from the R core
packages (formarly base, not stats), then you can do that one of two
ways. The first is the disciplined and supported way: use the fact
that `start` is a generic and define a method for it, as was already
suggested. That is the point of defining `start' as a generics. The
undisciplined way it to change the definition in the stats package.
This can be done. It is hard to do, and that is deliberate.
If your intent is to define a function of your own for use in your
packages that does something you want in one particular case but
otherwise defers to the function `start' in base then you can do that
too. If this is what you want then things would be clearer if you
used a different name, like
pgStart - function (x, ...) {
if (is.Ttframed(x)) start(tframe(x), ...)
else start(x, ...)
}
If for some reason you must use the smae name, even though that may
not be doing what you think it is doing, then you can explicitly defer
to the version in stats with
start - function (x, ...) {
if (is.Ttframed(x)) stats::start(tframe(x), ...)
else stats::start(x, ...)
}
So we have infact implemented several nice pieces of rope for your use ...
Best,
luke
--
Luke Tierney
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
